Message ID | 20240516122539.30787-3-sakari.ailus@linux.intel.com (mailing list archive) |
---|---|
State | New |
Headers |
Received: from sv.mirrors.kernel.org ([139.178.88.99]) by linuxtv.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <linux-media+bounces-11554-patchwork=linuxtv.org@vger.kernel.org>) id 1s7aEn-0003l6-09 for patchwork@linuxtv.org; Thu, 16 May 2024 12:29:34 +0000 Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id EC54E285AF1 for <patchwork@linuxtv.org>; Thu, 16 May 2024 12:29:29 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DF43C14D71F; Thu, 16 May 2024 12:25:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Idtgcf2c" X-Original-To: linux-media@vger.kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C79BE1465A7 for <linux-media@vger.kernel.org>; Thu, 16 May 2024 12:25:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.7 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715862349; cv=none; b=leT05RZi/iedqUseGGtB1vrieqme5zqmaJ8rJsXFFIwkhnIjrSOciP28FE88M4qsHNIq+18N/RtGhlNCUT+Oo9HgttDYt5eC0gMQolzjPLKHQtxkJybA/dc/06nHIT47C5Jf8SIaNE5WXSL9yeIze9RpC1ZEVAmyShhMwKT1OuQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715862349; c=relaxed/simple; bh=64y+LNXtPE6IRjNRZAQADhQ74oRVlheAoCp3oZ9Yyj0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=k4SSrijyeyN6p6a+vfubX6IVA2tQ+kWuPA1nzWoKrLMl3nHwlT4AjPeMKkK7Qewp2k0qNE4UuObD3iZTcgzJk6iRP+ZzW+NkNza5XV0rthn5xC8CLYAee6dZPmVsakt2ZV0hatEiMFGPYmADO2jbO1/YNnhQSMEQ8bmHEBAuIgM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Idtgcf2c; arc=none smtp.client-ip=192.198.163.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1715862348; x=1747398348; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=64y+LNXtPE6IRjNRZAQADhQ74oRVlheAoCp3oZ9Yyj0=; b=Idtgcf2cfPNFW2Mg/i23MnusYb4H9M9VW2VY5WyywdnYBdOtxAiPcv49 +M7cmb5qWdvB0kEUu98tkVJCoZbrJOqLlHmZULRU6az4yo7BDdDU92q/S HxV+r+qPJmF6cNy9c212Ys0HWCZRUAAWNae26+lssr2tjcy9CYl6uH+or ZlKo3i2CFEXGx0LsHHbkfW7lbRZgZyCfd3NOVz5GzpuFV7AkmPeN+8HoX 9f7f/CmmfNtd1LqA9Yr3aDKGbmAZ0dM//+AvZxVEDhsM3ogK3yaYVJFV2 MLkBB7gmTAdVa2fqi9NWytskYjtpalFk7ba3CyCaRv5lU+rdG9efWiftj A==; X-CSE-ConnectionGUID: ccEZr7RUT5m0Qqqr4IksSA== X-CSE-MsgGUID: qfz81XrwQniS4QNiePso7g== X-IronPort-AV: E=McAfee;i="6600,9927,11074"; a="37345818" X-IronPort-AV: E=Sophos;i="6.08,164,1712646000"; d="scan'208";a="37345818" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2024 05:25:46 -0700 X-CSE-ConnectionGUID: 9m1vB0CTQg6ny9okDHWTMg== X-CSE-MsgGUID: wQ2F7RvJQlKUSE0ZjytjBg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,164,1712646000"; d="scan'208";a="36290258" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2024 05:25:45 -0700 Received: from svinhufvud.ger.corp.intel.com (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id AD17E120D1D; Thu, 16 May 2024 15:25:41 +0300 (EEST) From: Sakari Ailus <sakari.ailus@linux.intel.com> To: linux-media@vger.kernel.org Cc: Jacopo Mondi <jacopo.mondi@ideasonboard.com>, hverkuil@xs4all.nl, laurent.pinchart@ideasonboard.com, Wentong Wu <wentong.wu@intel.com> Subject: [PATCH v6 2/4] media: v4l: Support obtaining link frequency via get_mbus_config Date: Thu, 16 May 2024 15:25:37 +0300 Message-Id: <20240516122539.30787-3-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240516122539.30787-1-sakari.ailus@linux.intel.com> References: <20240516122539.30787-1-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: <linux-media.vger.kernel.org> List-Subscribe: <mailto:linux-media+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-media+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-LSpam-Score: -5.8 (-----) X-LSpam-Report: No, score=-5.8 required=5.0 tests=ARC_SIGNED=0.001,ARC_VALID=-0.1,BAYES_00=-1.9,DKIMWL_WL_HIGH=-1,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DMARC_PASS=-0.001,HEADER_FROM_DIFFERENT_DOMAINS=0.5,MAILING_LIST_MULTI=-1,RCVD_IN_DNSWL_MED=-2.3,SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=ham autolearn_force=no |
Series |
Use V4L2 mbus config for conveying MEI CSI link frequency
|
|
Commit Message
Sakari Ailus
May 16, 2024, 12:25 p.m. UTC
Add link_freq field to struct v4l2_mbus_config in order to pass the link
frequency to the receiving sub-device.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
drivers/media/v4l2-core/v4l2-common.c | 11 ++++++++---
include/media/v4l2-mediabus.h | 2 ++
2 files changed, 10 insertions(+), 3 deletions(-)
Comments
On Thu, May 16, 2024 at 03:25:37PM GMT, Sakari Ailus wrote: > Add link_freq field to struct v4l2_mbus_config in order to pass the link > frequency to the receiving sub-device. > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > --- > drivers/media/v4l2-core/v4l2-common.c | 11 ++++++++--- > include/media/v4l2-mediabus.h | 2 ++ > 2 files changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c > index 01650aed7c30..ff859a340c5d 100644 > --- a/drivers/media/v4l2-core/v4l2-common.c > +++ b/drivers/media/v4l2-core/v4l2-common.c > @@ -506,13 +506,18 @@ EXPORT_SYMBOL_GPL(__v4l2_get_link_freq_ctrl); > s64 __v4l2_get_link_freq_pad(struct media_pad *pad, unsigned int mul, > unsigned int div) > { > + struct v4l2_mbus_config mbus_config = {}; > struct v4l2_subdev *sd; > + int ret; > > sd = media_entity_to_v4l2_subdev(pad->entity); > - if (!sd) > - return -ENODEV; > + ret = v4l2_subdev_call(sd, pad, get_mbus_config, pad->index, > + &mbus_config); > + if (ret < 0 && ret != -ENOIOCTLCMD) > + return ret; Should we do like what we did with endpoint matching ? (let alone the fact we then backtracked on that.. :) WARN to encourage tx drivers to implement get_mbus_config and advertise the link freq through it ? > > - return __v4l2_get_link_freq_ctrl(sd->ctrl_handler, mul, div); > + return mbus_config.link_freq ?: > + __v4l2_get_link_freq_ctrl(sd->ctrl_handler, mul, div); > } > EXPORT_SYMBOL_GPL(__v4l2_get_link_freq_pad); > #endif /* CONFIG_MEDIA_CONTROLLER */ > diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h > index 5bce6e423e94..cc5f776dc662 100644 > --- a/include/media/v4l2-mediabus.h > +++ b/include/media/v4l2-mediabus.h > @@ -148,6 +148,7 @@ enum v4l2_mbus_type { > /** > * struct v4l2_mbus_config - media bus configuration > * @type: interface type > + * @link_freq: The link frequency. See also V4L2_CID_LINK_FREQ control. > * @bus: bus configuration data structure > * @bus.parallel: embedded &struct v4l2_mbus_config_parallel. > * Used if the bus is parallel or BT.656. > @@ -162,6 +163,7 @@ enum v4l2_mbus_type { > */ > struct v4l2_mbus_config { > enum v4l2_mbus_type type; > + u64 link_freq; I will retaliate that link_freq has different meaning for serial and parallel busses, and it would feel more natural having something like mipi_csi2.link_freq parallel.pixel_clock or do you think it's an overkill ? > union { > struct v4l2_mbus_config_parallel parallel; > struct v4l2_mbus_config_mipi_csi1 mipi_csi1; > -- > 2.39.2 >
Hi Jacopo, On Fri, May 17, 2024 at 12:31:43PM +0200, Jacopo Mondi wrote: > On Thu, May 16, 2024 at 03:25:37PM GMT, Sakari Ailus wrote: > > Add link_freq field to struct v4l2_mbus_config in order to pass the link > > frequency to the receiving sub-device. > > > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > --- > > drivers/media/v4l2-core/v4l2-common.c | 11 ++++++++--- > > include/media/v4l2-mediabus.h | 2 ++ > > 2 files changed, 10 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c > > index 01650aed7c30..ff859a340c5d 100644 > > --- a/drivers/media/v4l2-core/v4l2-common.c > > +++ b/drivers/media/v4l2-core/v4l2-common.c > > @@ -506,13 +506,18 @@ EXPORT_SYMBOL_GPL(__v4l2_get_link_freq_ctrl); > > s64 __v4l2_get_link_freq_pad(struct media_pad *pad, unsigned int mul, > > unsigned int div) > > { > > + struct v4l2_mbus_config mbus_config = {}; > > struct v4l2_subdev *sd; > > + int ret; > > > > sd = media_entity_to_v4l2_subdev(pad->entity); > > - if (!sd) > > - return -ENODEV; > > + ret = v4l2_subdev_call(sd, pad, get_mbus_config, pad->index, > > + &mbus_config); > > + if (ret < 0 && ret != -ENOIOCTLCMD) > > + return ret; > > Should we do like what we did with endpoint matching ? (let alone the > fact we then backtracked on that.. :) Hmm. What exactly are you suggesting? > > WARN to encourage tx drivers to implement get_mbus_config and > advertise the link freq through it ? Why? If the value is conveyed by the control, there's no reason to copy it here, is it? > > > > > - return __v4l2_get_link_freq_ctrl(sd->ctrl_handler, mul, div); > > + return mbus_config.link_freq ?: > > + __v4l2_get_link_freq_ctrl(sd->ctrl_handler, mul, div); > > } > > EXPORT_SYMBOL_GPL(__v4l2_get_link_freq_pad); > > #endif /* CONFIG_MEDIA_CONTROLLER */ > > diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h > > index 5bce6e423e94..cc5f776dc662 100644 > > --- a/include/media/v4l2-mediabus.h > > +++ b/include/media/v4l2-mediabus.h > > @@ -148,6 +148,7 @@ enum v4l2_mbus_type { > > /** > > * struct v4l2_mbus_config - media bus configuration > > * @type: interface type > > + * @link_freq: The link frequency. See also V4L2_CID_LINK_FREQ control. > > * @bus: bus configuration data structure > > * @bus.parallel: embedded &struct v4l2_mbus_config_parallel. > > * Used if the bus is parallel or BT.656. > > @@ -162,6 +163,7 @@ enum v4l2_mbus_type { > > */ > > struct v4l2_mbus_config { > > enum v4l2_mbus_type type; > > + u64 link_freq; > > I will retaliate that link_freq has different meaning for serial and > parallel busses, and it would feel more natural having something like > > mipi_csi2.link_freq > parallel.pixel_clock > > or do you think it's an overkill ? How is the meaning different? The value reflects the frequency on both buses. > > > union { > > struct v4l2_mbus_config_parallel parallel; > > struct v4l2_mbus_config_mipi_csi1 mipi_csi1;
Hi Sakari On Tue, May 28, 2024 at 06:09:12AM GMT, Sakari Ailus wrote: > Hi Jacopo, > > On Fri, May 17, 2024 at 12:31:43PM +0200, Jacopo Mondi wrote: > > On Thu, May 16, 2024 at 03:25:37PM GMT, Sakari Ailus wrote: > > > Add link_freq field to struct v4l2_mbus_config in order to pass the link > > > frequency to the receiving sub-device. > > > > > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > > --- > > > drivers/media/v4l2-core/v4l2-common.c | 11 ++++++++--- > > > include/media/v4l2-mediabus.h | 2 ++ > > > 2 files changed, 10 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c > > > index 01650aed7c30..ff859a340c5d 100644 > > > --- a/drivers/media/v4l2-core/v4l2-common.c > > > +++ b/drivers/media/v4l2-core/v4l2-common.c > > > @@ -506,13 +506,18 @@ EXPORT_SYMBOL_GPL(__v4l2_get_link_freq_ctrl); > > > s64 __v4l2_get_link_freq_pad(struct media_pad *pad, unsigned int mul, > > > unsigned int div) > > > { > > > + struct v4l2_mbus_config mbus_config = {}; > > > struct v4l2_subdev *sd; > > > + int ret; > > > > > > sd = media_entity_to_v4l2_subdev(pad->entity); > > > - if (!sd) > > > - return -ENODEV; > > > + ret = v4l2_subdev_call(sd, pad, get_mbus_config, pad->index, > > > + &mbus_config); > > > + if (ret < 0 && ret != -ENOIOCTLCMD) > > > + return ret; > > > > Should we do like what we did with endpoint matching ? (let alone the > > fact we then backtracked on that.. :) > > Hmm. What exactly are you suggesting? > See below > > > > WARN to encourage tx drivers to implement get_mbus_config and > > advertise the link freq through it ? > > Why? If the value is conveyed by the control, there's no reason to copy it > here, is it? > My understanding is that using get_mbus_config() is preferred, but yes, if the control is in place the same value should be propagated through both path, which is probably a biy silly, yeah. Ok, ignore the suggestion then > > > > > > > > - return __v4l2_get_link_freq_ctrl(sd->ctrl_handler, mul, div); > > > + return mbus_config.link_freq ?: > > > + __v4l2_get_link_freq_ctrl(sd->ctrl_handler, mul, div); > > > } > > > EXPORT_SYMBOL_GPL(__v4l2_get_link_freq_pad); > > > #endif /* CONFIG_MEDIA_CONTROLLER */ > > > diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h > > > index 5bce6e423e94..cc5f776dc662 100644 > > > --- a/include/media/v4l2-mediabus.h > > > +++ b/include/media/v4l2-mediabus.h > > > @@ -148,6 +148,7 @@ enum v4l2_mbus_type { > > > /** > > > * struct v4l2_mbus_config - media bus configuration > > > * @type: interface type > > > + * @link_freq: The link frequency. See also V4L2_CID_LINK_FREQ control. > > > * @bus: bus configuration data structure > > > * @bus.parallel: embedded &struct v4l2_mbus_config_parallel. > > > * Used if the bus is parallel or BT.656. > > > @@ -162,6 +163,7 @@ enum v4l2_mbus_type { > > > */ > > > struct v4l2_mbus_config { > > > enum v4l2_mbus_type type; > > > + u64 link_freq; > > > > I will retaliate that link_freq has different meaning for serial and > > parallel busses, and it would feel more natural having something like > > > > mipi_csi2.link_freq > > parallel.pixel_clock > > > > or do you think it's an overkill ? > > How is the meaning different? The value reflects the frequency on both > buses. The meaning is slightly different. For a parallel bus the "link_freq" is actually the pixel clock (and thus "link_freq" is an ill-defined concept for parallel busses ?). For serial busses there actually is a "link frequency" which corresponds to the clock lane frequency. In general, however we define it, the link_freq is a bus property and feels better placed inside the per-bus structures to me. Up to you > > > > > > union { > > > struct v4l2_mbus_config_parallel parallel; > > > struct v4l2_mbus_config_mipi_csi1 mipi_csi1; > > -- > Kind regards, > > Sakari Ailus
Hi Jacopo, On Tue, May 28, 2024 at 09:16:06AM +0200, Jacopo Mondi wrote: > Hi Sakari > > On Tue, May 28, 2024 at 06:09:12AM GMT, Sakari Ailus wrote: > > Hi Jacopo, > > > > On Fri, May 17, 2024 at 12:31:43PM +0200, Jacopo Mondi wrote: > > > On Thu, May 16, 2024 at 03:25:37PM GMT, Sakari Ailus wrote: > > > > Add link_freq field to struct v4l2_mbus_config in order to pass the link > > > > frequency to the receiving sub-device. > > > > > > > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > > > > --- > > > > drivers/media/v4l2-core/v4l2-common.c | 11 ++++++++--- > > > > include/media/v4l2-mediabus.h | 2 ++ > > > > 2 files changed, 10 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c > > > > index 01650aed7c30..ff859a340c5d 100644 > > > > --- a/drivers/media/v4l2-core/v4l2-common.c > > > > +++ b/drivers/media/v4l2-core/v4l2-common.c > > > > @@ -506,13 +506,18 @@ EXPORT_SYMBOL_GPL(__v4l2_get_link_freq_ctrl); > > > > s64 __v4l2_get_link_freq_pad(struct media_pad *pad, unsigned int mul, > > > > unsigned int div) > > > > { > > > > + struct v4l2_mbus_config mbus_config = {}; > > > > struct v4l2_subdev *sd; > > > > + int ret; > > > > > > > > sd = media_entity_to_v4l2_subdev(pad->entity); > > > > - if (!sd) > > > > - return -ENODEV; > > > > + ret = v4l2_subdev_call(sd, pad, get_mbus_config, pad->index, > > > > + &mbus_config); > > > > + if (ret < 0 && ret != -ENOIOCTLCMD) > > > > + return ret; > > > > > > Should we do like what we did with endpoint matching ? (let alone the > > > fact we then backtracked on that.. :) > > > > Hmm. What exactly are you suggesting? > > > > See below > > > > > > > WARN to encourage tx drivers to implement get_mbus_config and > > > advertise the link freq through it ? > > > > Why? If the value is conveyed by the control, there's no reason to copy it > > here, is it? > > > > My understanding is that using get_mbus_config() is preferred, but > yes, if the control is in place the same value should be propagated > through both path, which is probably a biy silly, yeah. The problem is that few drivers implement get_mbus_config() and they actually shouldn't if the configuration is fixed. I've actually thought of adding a helper to obtain the information in struct v4l2_mbus_config from the V4L2 fwnode endpoint but it's not implemented. > > Ok, ignore the suggestion then > > > > > > > > > > > > - return __v4l2_get_link_freq_ctrl(sd->ctrl_handler, mul, div); > > > > + return mbus_config.link_freq ?: > > > > + __v4l2_get_link_freq_ctrl(sd->ctrl_handler, mul, div); > > > > } > > > > EXPORT_SYMBOL_GPL(__v4l2_get_link_freq_pad); > > > > #endif /* CONFIG_MEDIA_CONTROLLER */ > > > > diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h > > > > index 5bce6e423e94..cc5f776dc662 100644 > > > > --- a/include/media/v4l2-mediabus.h > > > > +++ b/include/media/v4l2-mediabus.h > > > > @@ -148,6 +148,7 @@ enum v4l2_mbus_type { > > > > /** > > > > * struct v4l2_mbus_config - media bus configuration > > > > * @type: interface type > > > > + * @link_freq: The link frequency. See also V4L2_CID_LINK_FREQ control. > > > > * @bus: bus configuration data structure > > > > * @bus.parallel: embedded &struct v4l2_mbus_config_parallel. > > > > * Used if the bus is parallel or BT.656. > > > > @@ -162,6 +163,7 @@ enum v4l2_mbus_type { > > > > */ > > > > struct v4l2_mbus_config { > > > > enum v4l2_mbus_type type; > > > > + u64 link_freq; > > > > > > I will retaliate that link_freq has different meaning for serial and > > > parallel busses, and it would feel more natural having something like > > > > > > mipi_csi2.link_freq > > > parallel.pixel_clock > > > > > > or do you think it's an overkill ? > > > > How is the meaning different? The value reflects the frequency on both > > buses. > > The meaning is slightly different. For a parallel bus the "link_freq" > is actually the pixel clock (and thus "link_freq" is an ill-defined concept > for parallel busses ?). For serial busses there actually is a "link > frequency" which corresponds to the clock lane frequency. It's not different on parallel buses: there's a clock signal, too, and the data lines do use the same frequency. The frequency of that clock is the link frequency. The pixel clock can be different still as multiple samples on the bus may be required to obtain a single pixel. > > In general, however we define it, the link_freq is a bus property and > feels better placed inside the per-bus structures to me. > > Up to you > > > > > > > > > > union { > > > > struct v4l2_mbus_config_parallel parallel; > > > > struct v4l2_mbus_config_mipi_csi1 mipi_csi1; > >
diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c index 01650aed7c30..ff859a340c5d 100644 --- a/drivers/media/v4l2-core/v4l2-common.c +++ b/drivers/media/v4l2-core/v4l2-common.c @@ -506,13 +506,18 @@ EXPORT_SYMBOL_GPL(__v4l2_get_link_freq_ctrl); s64 __v4l2_get_link_freq_pad(struct media_pad *pad, unsigned int mul, unsigned int div) { + struct v4l2_mbus_config mbus_config = {}; struct v4l2_subdev *sd; + int ret; sd = media_entity_to_v4l2_subdev(pad->entity); - if (!sd) - return -ENODEV; + ret = v4l2_subdev_call(sd, pad, get_mbus_config, pad->index, + &mbus_config); + if (ret < 0 && ret != -ENOIOCTLCMD) + return ret; - return __v4l2_get_link_freq_ctrl(sd->ctrl_handler, mul, div); + return mbus_config.link_freq ?: + __v4l2_get_link_freq_ctrl(sd->ctrl_handler, mul, div); } EXPORT_SYMBOL_GPL(__v4l2_get_link_freq_pad); #endif /* CONFIG_MEDIA_CONTROLLER */ diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 5bce6e423e94..cc5f776dc662 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -148,6 +148,7 @@ enum v4l2_mbus_type { /** * struct v4l2_mbus_config - media bus configuration * @type: interface type + * @link_freq: The link frequency. See also V4L2_CID_LINK_FREQ control. * @bus: bus configuration data structure * @bus.parallel: embedded &struct v4l2_mbus_config_parallel. * Used if the bus is parallel or BT.656. @@ -162,6 +163,7 @@ enum v4l2_mbus_type { */ struct v4l2_mbus_config { enum v4l2_mbus_type type; + u64 link_freq; union { struct v4l2_mbus_config_parallel parallel; struct v4l2_mbus_config_mipi_csi1 mipi_csi1;