[PATCH v2 0/3] Use INTEGER64 type for MEI CSI LINK_FREQ control

[PATCH v2 0/3] Use INTEGER64 type for MEI CSI LINK_FREQ control

[Sakari Ailus]

Hi folks,

An integer menu isn't a useful control type for conveying the frequency
depending on an external device to the receiver. Instead, in the MEI CSI
driver, just obtain the link frequency from the upsteam sub-device and
pass it on to the receiver.

The v4l2_get_link_freq() is changed to add support for this and it's
documented as well.

since v1:

- Add a new 64-bit integer control V4L2_CID_CUR_LINK_FREQ instead of
  re-using V4L2_CID_LINK_FREQ.

Sakari Ailus (3):
  media: Documentation: v4l: Add CUR_LINK_FREQ control
  media: v4l: Support obtaining link frequency from CUR_LINK_FREQ
    control
  media: ivsc: csi: Fix link frequency control behaviour

 .../media/v4l/ext-ctrls-image-process.rst     |  4 ++++
 drivers/media/pci/intel/ivsc/mei_csi.c        | 24 ++++++-------------
 drivers/media/v4l2-core/v4l2-common.c         |  6 ++++-
 drivers/media/v4l2-core/v4l2-ctrls-defs.c     |  5 ++++
 include/uapi/linux/v4l2-controls.h            |  1 +
 5 files changed, 22 insertions(+), 18 deletions(-)


base-commit: 6612d1ae37b52d37d1d515d7c5110b9f3afe94d2
-- 
2.39.2

[PATCH v2 1/3] media: Documentation: v4l: Add CUR_LINK_FREQ control

[Sakari Ailus]

Add a 64-bit integer control for devices that are passing through CSI-2
(or other) data, to signal the link frequency used by also the upstream
sub-device. The control is volatile and read-only.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
 .../userspace-api/media/v4l/ext-ctrls-image-process.rst      | 4 ++++
 drivers/media/v4l2-core/v4l2-ctrls-defs.c                    | 5 +++++
 include/uapi/linux/v4l2-controls.h                           | 1 +
 3 files changed, 10 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst
index b1c2ab2854af..31d5045f32e7 100644
--- a/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst
+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-image-process.rst
@@ -55,3 +55,7 @@ Image Process Control IDs
     control value divided by e.g. 0x100, meaning that to get no
     digital gain the control value needs to be 0x100. The no-gain
     configuration is also typically the default.
+
+``V4L2_CID_CUR_LINK_FREQ (64-bit integer)``
+    The current link frequency on a data interface (e.g. parallel or
+    CSI-2). This control is read-only.
diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
index 8696eb1cdd61..1e8e02818f9f 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
@@ -1163,6 +1163,7 @@ const char *v4l2_ctrl_get_name(u32 id)
 	case V4L2_CID_TEST_PATTERN:		return "Test Pattern";
 	case V4L2_CID_DEINTERLACING_MODE:	return "Deinterlacing Mode";
 	case V4L2_CID_DIGITAL_GAIN:		return "Digital Gain";
+	case V4L2_CID_CUR_LINK_FREQ:		return "Link Frequency";
 
 	/* DV controls */
 	/* Keep the order of the 'case's the same as in v4l2-controls.h! */
@@ -1425,6 +1426,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
 	case V4L2_CID_LINK_FREQ:
 		*type = V4L2_CTRL_TYPE_INTEGER_MENU;
 		break;
+	case V4L2_CID_CUR_LINK_FREQ:
+		*flags |= V4L2_CTRL_FLAG_VOLATILE | V4L2_CTRL_FLAG_READ_ONLY;
+		*type = V4L2_CTRL_TYPE_INTEGER64;
+		break;
 	case V4L2_CID_RDS_TX_PS_NAME:
 	case V4L2_CID_RDS_TX_RADIO_TEXT:
 	case V4L2_CID_RDS_RX_PS_NAME:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 99c3f5e99da7..1c63d2e51e8d 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -1223,6 +1223,7 @@ enum v4l2_jpeg_chroma_subsampling {
 #define V4L2_CID_TEST_PATTERN			(V4L2_CID_IMAGE_PROC_CLASS_BASE + 3)
 #define V4L2_CID_DEINTERLACING_MODE		(V4L2_CID_IMAGE_PROC_CLASS_BASE + 4)
 #define V4L2_CID_DIGITAL_GAIN			(V4L2_CID_IMAGE_PROC_CLASS_BASE + 5)
+#define V4L2_CID_CUR_LINK_FREQ			(V4L2_CID_IMAGE_PROC_CLASS_BASE + 6)
 
 /*  DV-class control IDs defined by V4L2 */
 #define V4L2_CID_DV_CLASS_BASE			(V4L2_CTRL_CLASS_DV | 0x900)
-- 
2.39.2

[PATCH v2 2/3] media: v4l: Support obtaining link frequency from CUR_LINK_FREQ control

[Sakari Ailus]

Support V4L2_CID_CUR_LINK_FREQ INTEGER64 control in v4l2_get_link_freq().

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
 drivers/media/v4l2-core/v4l2-common.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
index 4165c815faef..bf1923314d15 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -483,6 +483,10 @@ s64 v4l2_get_link_freq(struct v4l2_ctrl_handler *handler, unsigned int mul,
 
 		freq = qm.value;
 	} else {
+		ctrl = v4l2_ctrl_find(handler, V4L2_CID_CUR_LINK_FREQ);
+		if (ctrl)
+			return v4l2_ctrl_g_ctrl_int64(ctrl);
+
 		if (!mul || !div)
 			return -ENOENT;
 
@@ -494,7 +498,7 @@ s64 v4l2_get_link_freq(struct v4l2_ctrl_handler *handler, unsigned int mul,
 
 		pr_warn("%s: Link frequency estimated using pixel rate: result might be inaccurate\n",
 			__func__);
-		pr_warn("%s: Consider implementing support for V4L2_CID_LINK_FREQ in the transmitter driver\n",
+		pr_warn("%s: Consider implementing support for V4L2_CID_LINK_FREQ or V4L2_CID_CUR_LINK_FREQ in the transmitter driver\n",
 			__func__);
 	}
 
-- 
2.39.2

[PATCH v2 3/3] media: ivsc: csi: Fix link frequency control behaviour

[Sakari Ailus]

The link frequency control was an integer menu control the value of which
was hard-coded in the MEI CSI driver itself. Instead obtain the control
value from the upstream sub-device and use the CUR_LINK_FREQ INTEGER64
control type for the purpose.

Fixes: 29006e196a56 ("media: pci: intel: ivsc: Add CSI submodule")
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
 drivers/media/pci/intel/ivsc/mei_csi.c | 24 +++++++-----------------
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/drivers/media/pci/intel/ivsc/mei_csi.c b/drivers/media/pci/intel/ivsc/mei_csi.c
index 55e0c60c420c..4a35932f1cd3 100644
--- a/drivers/media/pci/intel/ivsc/mei_csi.c
+++ b/drivers/media/pci/intel/ivsc/mei_csi.c
@@ -15,6 +15,7 @@
 #include <linux/completion.h>
 #include <linux/delay.h>
 #include <linux/kernel.h>
+#include <linux/limits.h>
 #include <linux/math64.h>
 #include <linux/mei_cl_bus.h>
 #include <linux/module.h>
@@ -32,8 +33,6 @@
 
 #define MEI_CSI_ENTITY_NAME "Intel IVSC CSI"
 
-#define MEI_CSI_LINK_FREQ_400MHZ 400000000ULL
-
 /* the 5s used here is based on experiment */
 #define CSI_CMD_TIMEOUT (5 * HZ)
 /* to setup CSI-2 link an extra delay needed and determined experimentally */
@@ -145,10 +144,6 @@ static const struct v4l2_mbus_framefmt mei_csi_format_mbus_default = {
 	.field = V4L2_FIELD_NONE,
 };
 
-static s64 link_freq_menu_items[] = {
-	MEI_CSI_LINK_FREQ_400MHZ
-};
-
 static inline struct mei_csi *notifier_to_csi(struct v4l2_async_notifier *n)
 {
 	return container_of(n, struct mei_csi, notifier);
@@ -470,7 +465,7 @@ static int mei_csi_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
 	struct mei_csi *csi = ctrl_to_csi(ctrl);
 	s64 freq;
 
-	if (ctrl->id == V4L2_CID_LINK_FREQ) {
+	if (ctrl->id == V4L2_CID_CUR_LINK_FREQ) {
 		if (!csi->remote)
 			return -EINVAL;
 
@@ -481,8 +476,7 @@ static int mei_csi_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
 			return -EINVAL;
 		}
 
-		link_freq_menu_items[0] = freq;
-		ctrl->val = 0;
+		ctrl->p_new.p_s64[0] = csi->link_freq = freq;
 
 		return 0;
 	}
@@ -553,7 +547,6 @@ static const struct v4l2_async_notifier_operations mei_csi_notify_ops = {
 
 static int mei_csi_init_controls(struct mei_csi *csi)
 {
-	u32 max;
 	int ret;
 
 	ret = v4l2_ctrl_handler_init(&csi->ctrl_handler, 2);
@@ -562,13 +555,10 @@ static int mei_csi_init_controls(struct mei_csi *csi)
 
 	csi->ctrl_handler.lock = &csi->lock;
 
-	max = ARRAY_SIZE(link_freq_menu_items) - 1;
-	csi->freq_ctrl = v4l2_ctrl_new_int_menu(&csi->ctrl_handler,
-						&mei_csi_ctrl_ops,
-						V4L2_CID_LINK_FREQ,
-						max,
-						0,
-						link_freq_menu_items);
+	csi->freq_ctrl = v4l2_ctrl_new_std(&csi->ctrl_handler,
+					   &mei_csi_ctrl_ops,
+					   V4L2_CID_CUR_LINK_FREQ, 1, S64_MAX,
+					   1, 1);
 	if (csi->freq_ctrl)
 		csi->freq_ctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY |
 					 V4L2_CTRL_FLAG_VOLATILE;
-- 
2.39.2

RE: [PATCH v2 3/3] media: ivsc: csi: Fix link frequency control behaviour

[Wu, Wentong]

> From: Sakari Ailus <sakari.ailus@linux.intel.com>
> 
> The link frequency control was an integer menu control the value of which
> was hard-coded in the MEI CSI driver itself. Instead obtain the control value
> from the upstream sub-device and use the CUR_LINK_FREQ INTEGER64
> control type for the purpose.
> 
> Fixes: 29006e196a56 ("media: pci: intel: ivsc: Add CSI submodule")
> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>

Acked-by:  Wentong Wu <wentong.wu@intel.com>

> ---
>  drivers/media/pci/intel/ivsc/mei_csi.c | 24 +++++++-----------------
>  1 file changed, 7 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/media/pci/intel/ivsc/mei_csi.c
> b/drivers/media/pci/intel/ivsc/mei_csi.c
> index 55e0c60c420c..4a35932f1cd3 100644
> --- a/drivers/media/pci/intel/ivsc/mei_csi.c
> +++ b/drivers/media/pci/intel/ivsc/mei_csi.c
> @@ -15,6 +15,7 @@
>  #include <linux/completion.h>
>  #include <linux/delay.h>
>  #include <linux/kernel.h>
> +#include <linux/limits.h>
>  #include <linux/math64.h>
>  #include <linux/mei_cl_bus.h>
>  #include <linux/module.h>
> @@ -32,8 +33,6 @@
> 
>  #define MEI_CSI_ENTITY_NAME "Intel IVSC CSI"
> 
> -#define MEI_CSI_LINK_FREQ_400MHZ 400000000ULL
> -
>  /* the 5s used here is based on experiment */  #define CSI_CMD_TIMEOUT
> (5 * HZ)
>  /* to setup CSI-2 link an extra delay needed and determined experimentally
> */ @@ -145,10 +144,6 @@ static const struct v4l2_mbus_framefmt
> mei_csi_format_mbus_default = {
>  	.field = V4L2_FIELD_NONE,
>  };
> 
> -static s64 link_freq_menu_items[] = {
> -	MEI_CSI_LINK_FREQ_400MHZ
> -};
> -
>  static inline struct mei_csi *notifier_to_csi(struct v4l2_async_notifier *n)  {
>  	return container_of(n, struct mei_csi, notifier); @@ -470,7 +465,7
> @@ static int mei_csi_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
>  	struct mei_csi *csi = ctrl_to_csi(ctrl);
>  	s64 freq;
> 
> -	if (ctrl->id == V4L2_CID_LINK_FREQ) {
> +	if (ctrl->id == V4L2_CID_CUR_LINK_FREQ) {
>  		if (!csi->remote)
>  			return -EINVAL;
> 
> @@ -481,8 +476,7 @@ static int mei_csi_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
>  			return -EINVAL;
>  		}
> 
> -		link_freq_menu_items[0] = freq;
> -		ctrl->val = 0;
> +		ctrl->p_new.p_s64[0] = csi->link_freq = freq;
> 
>  		return 0;
>  	}
> @@ -553,7 +547,6 @@ static const struct v4l2_async_notifier_operations
> mei_csi_notify_ops = {
> 
>  static int mei_csi_init_controls(struct mei_csi *csi)  {
> -	u32 max;
>  	int ret;
> 
>  	ret = v4l2_ctrl_handler_init(&csi->ctrl_handler, 2); @@ -562,13
> +555,10 @@ static int mei_csi_init_controls(struct mei_csi *csi)
> 
>  	csi->ctrl_handler.lock = &csi->lock;
> 
> -	max = ARRAY_SIZE(link_freq_menu_items) - 1;
> -	csi->freq_ctrl = v4l2_ctrl_new_int_menu(&csi->ctrl_handler,
> -						&mei_csi_ctrl_ops,
> -						V4L2_CID_LINK_FREQ,
> -						max,
> -						0,
> -						link_freq_menu_items);
> +	csi->freq_ctrl = v4l2_ctrl_new_std(&csi->ctrl_handler,
> +					   &mei_csi_ctrl_ops,
> +					   V4L2_CID_CUR_LINK_FREQ, 1,
> S64_MAX,
> +					   1, 1);
>  	if (csi->freq_ctrl)
>  		csi->freq_ctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY |
>  					 V4L2_CTRL_FLAG_VOLATILE;
> --
> 2.39.2

Re: [PATCH v2 0/3] Use INTEGER64 type for MEI CSI LINK_FREQ control

[Laurent Pinchart]

Hi Sakari,

Thank you for the patches.

On Fri, Apr 26, 2024 at 05:55:35PM +0300, Sakari Ailus wrote:
> Hi folks,
> 
> An integer menu isn't a useful control type for conveying the frequency
> depending on an external device to the receiver. Instead, in the MEI CSI
> driver, just obtain the link frequency from the upsteam sub-device and
> pass it on to the receiver.
> 
> The v4l2_get_link_freq() is changed to add support for this and it's
> documented as well.

Using a control for this seems to be a bit of a hack :-S Wouldn't it fit
more nicely in the .get_mbus_config() operation ? That would avoid
exposing this to userspace, and would also have the nice advantage that
the value could be queried per pad.

> since v1:
> 
> - Add a new 64-bit integer control V4L2_CID_CUR_LINK_FREQ instead of
>   re-using V4L2_CID_LINK_FREQ.
> 
> Sakari Ailus (3):
>   media: Documentation: v4l: Add CUR_LINK_FREQ control
>   media: v4l: Support obtaining link frequency from CUR_LINK_FREQ
>     control
>   media: ivsc: csi: Fix link frequency control behaviour
> 
>  .../media/v4l/ext-ctrls-image-process.rst     |  4 ++++
>  drivers/media/pci/intel/ivsc/mei_csi.c        | 24 ++++++-------------
>  drivers/media/v4l2-core/v4l2-common.c         |  6 ++++-
>  drivers/media/v4l2-core/v4l2-ctrls-defs.c     |  5 ++++
>  include/uapi/linux/v4l2-controls.h            |  1 +
>  5 files changed, 22 insertions(+), 18 deletions(-)
> 
> 
> base-commit: 6612d1ae37b52d37d1d515d7c5110b9f3afe94d2

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 0/3] Use INTEGER64 type for MEI CSI LINK_FREQ control

[Sakari Ailus]

Hi Laurent,

On Mon, Apr 29, 2024 at 02:20:28AM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> Thank you for the patches.
> 
> On Fri, Apr 26, 2024 at 05:55:35PM +0300, Sakari Ailus wrote:
> > Hi folks,
> > 
> > An integer menu isn't a useful control type for conveying the frequency
> > depending on an external device to the receiver. Instead, in the MEI CSI
> > driver, just obtain the link frequency from the upsteam sub-device and
> > pass it on to the receiver.
> > 
> > The v4l2_get_link_freq() is changed to add support for this and it's
> > documented as well.
> 
> Using a control for this seems to be a bit of a hack :-S Wouldn't it fit
> more nicely in the .get_mbus_config() operation ? That would avoid
> exposing this to userspace, and would also have the nice advantage that
> the value could be queried per pad.

Works for me. I also think it's better than using a new control for this
actually.

> 
> > since v1:
> > 
> > - Add a new 64-bit integer control V4L2_CID_CUR_LINK_FREQ instead of
> >   re-using V4L2_CID_LINK_FREQ.
> > 
> > Sakari Ailus (3):
> >   media: Documentation: v4l: Add CUR_LINK_FREQ control
> >   media: v4l: Support obtaining link frequency from CUR_LINK_FREQ
> >     control
> >   media: ivsc: csi: Fix link frequency control behaviour
> > 
> >  .../media/v4l/ext-ctrls-image-process.rst     |  4 ++++
> >  drivers/media/pci/intel/ivsc/mei_csi.c        | 24 ++++++-------------
> >  drivers/media/v4l2-core/v4l2-common.c         |  6 ++++-
> >  drivers/media/v4l2-core/v4l2-ctrls-defs.c     |  5 ++++
> >  include/uapi/linux/v4l2-controls.h            |  1 +
> >  5 files changed, 22 insertions(+), 18 deletions(-)
> > 
> > 
> > base-commit: 6612d1ae37b52d37d1d515d7c5110b9f3afe94d2
> 

-- 
Regards,

Sakari Ailus

Re: [PATCH v2 0/3] Use INTEGER64 type for MEI CSI LINK_FREQ control

[Hans Verkuil]

On 29/04/2024 09:28, Sakari Ailus wrote:
> Hi Laurent,
> 
> On Mon, Apr 29, 2024 at 02:20:28AM +0300, Laurent Pinchart wrote:
>> Hi Sakari,
>>
>> Thank you for the patches.
>>
>> On Fri, Apr 26, 2024 at 05:55:35PM +0300, Sakari Ailus wrote:
>>> Hi folks,
>>>
>>> An integer menu isn't a useful control type for conveying the frequency
>>> depending on an external device to the receiver. Instead, in the MEI CSI
>>> driver, just obtain the link frequency from the upsteam sub-device and
>>> pass it on to the receiver.
>>>
>>> The v4l2_get_link_freq() is changed to add support for this and it's
>>> documented as well.
>>
>> Using a control for this seems to be a bit of a hack :-S Wouldn't it fit
>> more nicely in the .get_mbus_config() operation ? That would avoid
>> exposing this to userspace, and would also have the nice advantage that
>> the value could be queried per pad.
> 
> Works for me. I also think it's better than using a new control for this
> actually.

Same for me. As you gathered, I was not very enthusiastic about using a
control for this either.

Regards,

	Hans

> 
>>
>>> since v1:
>>>
>>> - Add a new 64-bit integer control V4L2_CID_CUR_LINK_FREQ instead of
>>>   re-using V4L2_CID_LINK_FREQ.
>>>
>>> Sakari Ailus (3):
>>>   media: Documentation: v4l: Add CUR_LINK_FREQ control
>>>   media: v4l: Support obtaining link frequency from CUR_LINK_FREQ
>>>     control
>>>   media: ivsc: csi: Fix link frequency control behaviour
>>>
>>>  .../media/v4l/ext-ctrls-image-process.rst     |  4 ++++
>>>  drivers/media/pci/intel/ivsc/mei_csi.c        | 24 ++++++-------------
>>>  drivers/media/v4l2-core/v4l2-common.c         |  6 ++++-
>>>  drivers/media/v4l2-core/v4l2-ctrls-defs.c     |  5 ++++
>>>  include/uapi/linux/v4l2-controls.h            |  1 +
>>>  5 files changed, 22 insertions(+), 18 deletions(-)
>>>
>>>
>>> base-commit: 6612d1ae37b52d37d1d515d7c5110b9f3afe94d2
>>
> 

Re: [PATCH v2 0/3] Use INTEGER64 type for MEI CSI LINK_FREQ control

[Sakari Ailus]

Hi Hans,

On Mon, Apr 29, 2024 at 09:30:37AM +0200, Hans Verkuil wrote:
> On 29/04/2024 09:28, Sakari Ailus wrote:
> > Hi Laurent,
> > 
> > On Mon, Apr 29, 2024 at 02:20:28AM +0300, Laurent Pinchart wrote:
> >> Hi Sakari,
> >>
> >> Thank you for the patches.
> >>
> >> On Fri, Apr 26, 2024 at 05:55:35PM +0300, Sakari Ailus wrote:
> >>> Hi folks,
> >>>
> >>> An integer menu isn't a useful control type for conveying the frequency
> >>> depending on an external device to the receiver. Instead, in the MEI CSI
> >>> driver, just obtain the link frequency from the upsteam sub-device and
> >>> pass it on to the receiver.
> >>>
> >>> The v4l2_get_link_freq() is changed to add support for this and it's
> >>> documented as well.
> >>
> >> Using a control for this seems to be a bit of a hack :-S Wouldn't it fit
> >> more nicely in the .get_mbus_config() operation ? That would avoid
> >> exposing this to userspace, and would also have the nice advantage that
> >> the value could be queried per pad.
> > 
> > Works for me. I also think it's better than using a new control for this
> > actually.
> 
> Same for me. As you gathered, I was not very enthusiastic about using a
> control for this either.

Ack.

I guess these are fine to be merged for 6.11 but still backporting to 6.10
should be done. Nothing breaks now as there's a single frequency used right
now and that's 400 MHz.

-- 
Regards,

Sakari Ailus