| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <72903fa4-be78-48e1-88e1-7c6b2146bc1b@ideasonboard.com>
Date: Fri, 8 Mar 2024 11:07:16 +0530
From: Umang Jain <umang.jain@...asonboard.com>
To: Dave Stevenson <dave.stevenson@...pberrypi.com>
Cc: linux-media@...r.kernel.org,
Alexander Shiyan <eagle.alexander923@...il.com>,
Kieran Bingham <kieran.bingham@...asonboard.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/5] media: imx335: Support 2 or 4 lane operation modes
Hi Dave
On 06/03/24 10:12 pm, Dave Stevenson wrote:
> Hi Umang and Kieran
>
> On Wed, 6 Mar 2024 at 08:11, Umang Jain <umang.jain@...asonboard.com> wrote:
>> From: Kieran Bingham <kieran.bingham@...asonboard.com>
>>
>> The IMX335 can support both 2 and 4 lane configurations.
>> Extend the driver to configure the lane mode accordingly.
>> Update the pixel rate depending on the number of lanes in use.
>>
>> Signed-off-by: Kieran Bingham <kieran.bingham@...asonboard.com>
>> Signed-off-by: Umang Jain <umang.jain@...asonboard.com>
>> ---
>> drivers/media/i2c/imx335.c | 46 +++++++++++++++++++++++++++++++-------
>> 1 file changed, 38 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/media/i2c/imx335.c b/drivers/media/i2c/imx335.c
>> index dab6d080bc4c..a42f48823515 100644
>> --- a/drivers/media/i2c/imx335.c
>> +++ b/drivers/media/i2c/imx335.c
>> @@ -21,6 +21,11 @@
>> #define IMX335_MODE_STANDBY 0x01
>> #define IMX335_MODE_STREAMING 0x00
>>
>> +/* Data Lanes */
>> +#define IMX335_LANEMODE 0x3a01
>> +#define IMX335_2LANE 1
>> +#define IMX335_4LANE 3
>> +
>> /* Lines per frame */
>> #define IMX335_REG_LPFR 0x3030
>>
>> @@ -67,8 +72,6 @@
>> #define IMX335_LINK_FREQ_594MHz 594000000LL
>> #define IMX335_LINK_FREQ_445MHz 445500000LL
>>
>> -#define IMX335_NUM_DATA_LANES 4
>> -
>> #define IMX335_REG_MIN 0x00
>> #define IMX335_REG_MAX 0xfffff
>>
>> @@ -115,7 +118,6 @@ static const char * const imx335_supply_name[] = {
>> * @vblank: Vertical blanking in lines
>> * @vblank_min: Minimum vertical blanking in lines
>> * @vblank_max: Maximum vertical blanking in lines
>> - * @pclk: Sensor pixel clock
>> * @reg_list: Register list for sensor mode
>> */
>> struct imx335_mode {
>> @@ -126,7 +128,6 @@ struct imx335_mode {
>> u32 vblank;
>> u32 vblank_min;
>> u32 vblank_max;
>> - u64 pclk;
>> struct imx335_reg_list reg_list;
>> };
>>
>> @@ -147,6 +148,7 @@ struct imx335_mode {
>> * @exp_ctrl: Pointer to exposure control
>> * @again_ctrl: Pointer to analog gain control
>> * @vblank: Vertical blanking in lines
>> + * @lane_mode Mode for number of connected data lanes
>> * @cur_mode: Pointer to current selected sensor mode
>> * @mutex: Mutex for serializing sensor controls
>> * @link_freq_bitmap: Menu bitmap for link_freq_ctrl
>> @@ -171,6 +173,7 @@ struct imx335 {
>> struct v4l2_ctrl *again_ctrl;
>> };
>> u32 vblank;
>> + u32 lane_mode;
>> const struct imx335_mode *cur_mode;
>> struct mutex mutex;
>> unsigned long link_freq_bitmap;
>> @@ -377,7 +380,6 @@ static const struct imx335_mode supported_mode = {
>> .vblank = 2560,
>> .vblank_min = 2560,
>> .vblank_max = 133060,
>> - .pclk = 396000000,
>> .reg_list = {
>> .num_of_regs = ARRAY_SIZE(mode_2592x1940_regs),
>> .regs = mode_2592x1940_regs,
>> @@ -936,6 +938,11 @@ static int imx335_start_streaming(struct imx335 *imx335)
>> return ret;
>> }
>>
>> + /* Configure lanes */
>> + ret = imx335_write_reg(imx335, IMX335_LANEMODE, 1, imx335->lane_mode);
>> + if (ret)
>> + return ret;
>> +
>> /* Setup handler will write actual exposure and gain */
>> ret = __v4l2_ctrl_handler_setup(imx335->sd.ctrl_handler);
>> if (ret) {
>> @@ -1096,7 +1103,14 @@ static int imx335_parse_hw_config(struct imx335 *imx335)
>> if (ret)
>> return ret;
>>
>> - if (bus_cfg.bus.mipi_csi2.num_data_lanes != IMX335_NUM_DATA_LANES) {
>> + switch (bus_cfg.bus.mipi_csi2.num_data_lanes) {
>> + case 2:
>> + imx335->lane_mode = IMX335_2LANE;
>> + break;
>> + case 4:
>> + imx335->lane_mode = IMX335_4LANE;
>> + break;
>> + default:
>> dev_err(imx335->dev,
>> "number of CSI2 data lanes %d is not supported\n",
>> bus_cfg.bus.mipi_csi2.num_data_lanes);
>> @@ -1209,6 +1223,9 @@ static int imx335_init_controls(struct imx335 *imx335)
>> struct v4l2_ctrl_handler *ctrl_hdlr = &imx335->ctrl_handler;
>> const struct imx335_mode *mode = imx335->cur_mode;
>> u32 lpfr;
>> + u64 pclk;
>> + s64 link_freq_in_use;
>> + u8 bpp;
>> int ret;
>>
>> ret = v4l2_ctrl_handler_init(ctrl_hdlr, 7);
>> @@ -1252,11 +1269,24 @@ static int imx335_init_controls(struct imx335 *imx335)
>> 0, 0, imx335_tpg_menu);
>>
>> /* Read only controls */
>> +
>> + /* pixel rate = link frequency * lanes * 2 / bits_per_pixel */
>> + switch (imx335->cur_mbus_code) {
>> + case MEDIA_BUS_FMT_SRGGB10_1X10:
>> + bpp = 10;
>> + break;
>> + case MEDIA_BUS_FMT_SRGGB12_1X12:
>> + bpp = 12;
>> + break;
>> + }
>> +
>> + link_freq_in_use = link_freq[__ffs(imx335->link_freq_bitmap)];
>> + pclk = link_freq_in_use * (imx335->lane_mode + 1) * 2 / bpp;
>> imx335->pclk_ctrl = v4l2_ctrl_new_std(ctrl_hdlr,
>> &imx335_ctrl_ops,
>> V4L2_CID_PIXEL_RATE,
>> - mode->pclk, mode->pclk,
>> - 1, mode->pclk);
>> + pclk, pclk,
>> + 1, pclk);
> Is this actually correct?
> A fair number of the sensors I've encountered have 2 PLL paths - one
> for the pixel array, and one for the CSI block. The bpp will generally
> be fed into the CSI block PLL path, but not into the pixel array one.
> The link frequency will therefore vary with bit depth, but
> V4L2_CID_PIXEL_RATE doesn't change.
>
> imx290 certainly has a disjoin between pixel rate and link freq
> (cropping reduces link freq, but not pixel rate), and we run imx477 in
> 2 lane mode with the pixel array at full tilt (840MPix/s) but large
> horizontal blanking to allow CSI2 enough time to send the data.
>
> If you've validated that for a range of frame rates you get the
> correct output from the sensor in both 10 and 12 bit modes, then I
I've not validated in such cases. Computing from pixel rate from the
link_freq and lane mode came out to be the same as the value currently
hardcoded in the mode structure hence I introduced this change. However,
I am inclined to dropping it after reading your review ;-)
> don't object. I just have an instinctive tick whenever I see drivers
> computing PIXEL_RATE from LINK_FREQ or vice versa :)
Having said that, I do know, the reporting is not perfect since the bpp
can be changed and it would change the link-frequency.
> If you get the right frame rate it may also imply that the link
> frequency isn't as configured, but that rarely has any negative
Indeed ;-)
> effects. You need a reasonably good oscilloscope to be able to measure
> the link frequency.
AH, I see.
>
> Dave
>
>> imx335->link_freq_ctrl = v4l2_ctrl_new_int_menu(ctrl_hdlr,
>> &imx335_ctrl_ops,
>> --
>> 2.43.0
>>
>>
Powered by blists - more mailing lists