[PATCH v6 07/12] media: ov5640: Remove pixel clock rates

The pixel clock rates were introduced to report the initially static clock rate. Since this is now handled dynamically, we can remove them entirely. Signed-off-by: Maxime Ripard Tested-by: Adam Ford #imx6dq --- drivers/media/i2c/ov5640.c | 21 + 1 file changed, 1 insertion

[PATCH v6 11/12] media: ov5640: Add 60 fps support

Now that we have everything in place to compute the clock rate at runtime, we can enable the 60fps framerate for the mode we tested it with. Signed-off-by: Maxime Ripard Tested-by: Adam Ford #imx6dq --- drivers/media/i2c/ov5640.c | 20 1 file changed, 16 insertions(+), 4

[PATCH v6 08/12] media: ov5640: Enhance FPS handling

Now that we have moved the clock generation logic out of the bytes array, these arrays are identical between the 15fps and 30fps variants. Remove the duplicate entries, and convert the code accordingly. Signed-off-by: Maxime Ripard Tested-by: Adam Ford #imx6dq --- drivers/media/i2c/ov5640.c

[PATCH v6 09/12] media: ov5640: Make the return rate type more explicit

In the ov5640_try_frame_interval function, the ret variable actually holds the frame rate index to use, which is represented by the enum ov5640_frame_rate in the driver. Make it more obvious. Signed-off-by: Maxime Ripard Tested-by: Adam Ford #imx6dq --- drivers/media/i2c/ov5640.c | 8

[PATCH v6 03/12] media: ov5640: Remove the clocks registers initialization

Part of the hardcoded initialization sequence is to set up the proper clock dividers. However, this is now done dynamically through proper code and as such, the static one is now redundant. Let's remove it. Signed-off-by: Maxime Ripard Tested-by: Adam Ford #imx6dq --- drivers/media/i2c/ov5640

[PATCH v6 02/12] media: ov5640: Adjust the clock based on the expected rate

-by: Jacopo Mondi Signed-off-by: Jacopo Mondi Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 365 +- 1 file changed, 364 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index 807bd0e386a4..4254ac958424

[PATCH v6 00/12] media: ov5640: Misc cleanup and improvements

he control value - Rebased on top of 4.17 Jacopo Mondi (1): media: ov5640: Fix set format regression Maxime Ripard (11): media: ov5640: Adjust the clock based on the expected rate media: ov5640: Remove the clocks registers initialization media: ov5640: Remove redundant defines media: ov56

[PATCH v6 04/12] media: ov5640: Remove redundant defines

The OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT and OV5640_SCLK_ROOT_DIVIDER_DEFAULT defines represent exactly the same setup, and are at the same value, than the more consistent with the rest of the driver OV5640_SCLK2X_ROOT_DIV and OV5640_SCLK_ROOT_DIV. Remove them. Signed-off-by: Maxime Ripard Tested

[PATCH v6 01/12] media: ov5640: Fix set format regression

by: Jacopo Mondi Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index a91d91715d00..807bd0e386a4 100644 --- a/drivers/media/i2c/ov5640.c +++

[PATCH v6 10/12] media: ov5640: Make the FPS clamping / rounding more extendable

The current code uses an algorithm to clamp the FPS values and round them to the closest supported one that isn't really allows to be extended to more than two values. Rework it a bit to make it much easier to extend the amount of FPS options we support. Signed-off-by: Maxime Ripard Tested

[PATCH v6 05/12] media: ov5640: Remove redundant register setup

The MIPI divider is also cleared as part of the clock setup sequence, so we can remove that code. Signed-off-by: Maxime Ripard Tested-by: Adam Ford #imx6dq --- drivers/media/i2c/ov5640.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media

[PATCH v6 06/12] media: ov5640: Compute the clock rate at runtime

with the new clock setup actually fix that error, and data are now sent at around 30fps. 2592x1944, on the other hand, is probably due to the fact that this mode can only be used using MIPI-CSI2, in a two lane mode, and never really tested with a DVP bus. Signed-off-by: Maxime Ripard Tested-by: Adam Ford

[PATCH v6 12/12] media: ov5640: Remove duplicate auto-exposure setup

The autoexposure setup in the 1080p init array is redundant with the default value of the sensor. Remove it. Signed-off-by: Maxime Ripard Tested-by: Adam Ford #imx6dq --- drivers/media/i2c/ov5640.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov5640.c

Re: [PATCH 2/2] media: sun6i-csi: manually fix other coding style issues

On Fri, Nov 23, 2018 at 05:13:23AM -0500, Mauro Carvalho Chehab wrote: > There are a few other coding style issues reported by checkpatch > while in --strict mode. Fix the ones that make sense. > > Signed-off-by: Mauro Carvalho Chehab For both patches, Acked-by: Maxime Ripard Th

Re: [PATCH v2 4/4] [DO NOT MERGE] ARM: dts: sun8i: Add CAM500B camera module to the Nano Pi M1+

On Fri, Nov 23, 2018 at 11:51:38AM +0530, Jagan Teki wrote: > On Wed, Nov 14, 2018 at 8:29 PM Maxime Ripard > wrote: > > From: Mylène Josserand > > > > The Nano Pi M1+ comes with an optional sensor based on the ov5640 from > > Omnivision. Enable the support for it

Re: [PATCH v5 01/11] media: ov5640: Adjust the clock based on the expected rate

Hi Jacopo, On Wed, Nov 14, 2018 at 08:48:47PM +0100, jacopo mondi wrote: > On Tue, Nov 13, 2018 at 02:03:15PM +0100, Maxime Ripard wrote: > > The clock structure for the PCLK is quite obscure in the documentation, and > > was hardcoded through the bytes array of each

Re: [PATCH v2 0/2] media: cedrus: Add H264 decoding support

. Your driver would > always use the lists in v4l2_ctrl_h264_slice_param, while the Rockchip > VPU would ignore them, use the ones in v4l2_ctrl_h264_decode_param and > perform the per-slice modifications on its own. I guess that would work, yep Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature

[PATCH v2 4/4] [DO NOT MERGE] ARM: dts: sun8i: Add CAM500B camera module to the Nano Pi M1+

From: Mylène Josserand The Nano Pi M1+ comes with an optional sensor based on the ov5640 from Omnivision. Enable the support for it in the DT. Signed-off-by: Mylène Josserand Signed-off-by: Maxime Ripard --- arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts | 85 +++ 1 file

[PATCH v2 3/4] ARM: dts: sun8i: Add the H3/H5 CSI controller

From: Mylène Josserand The H3 and H5 features the same CSI controller that was initially found on the A31. Add a DT node for it. Signed-off-by: Mylène Josserand Signed-off-by: Maxime Ripard --- arch/arm/boot/dts/sunxi-h3-h5.dtsi | 22 ++ 1 file changed, 22 insertions

[PATCH v2 0/4] media: sun6i: Add support for the H3 CSI controller

s CSI Support" by Yong Deng. Let me know what you think, Maxime Changes from v1: - Rebased on top of latest Yong's series Maxime Ripard (2): dt-bindings: media: sun6i: Add A31 and H3 compatibles media: sun6i: Add A31 compatible Mylène Josserand (2): ARM: dts: sun8i: Add the H3/H5 CSI

[PATCH v2 2/4] media: sun6i: Add A31 compatible

The first device that used that IP was the A31. Add it to our list of compatibles. Signed-off-by: Maxime Ripard --- drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c b/drivers/media/platform

[PATCH v2 1/4] dt-bindings: media: sun6i: Add A31 and H3 compatibles

The H3 has a slightly different CSI controller (no BT656, no CCI) which looks a lot like the original A31 controller. Add a compatible for the A31, and more specific compatible the for the H3 to be used in combination for the A31. Reviewed-by: Rob Herring Signed-off-by: Maxime Ripard

[PATCH v5 10/11] media: ov5640: Add 60 fps support

Now that we have everything in place to compute the clock rate at runtime, we can enable the 60fps framerate for the mode we tested it with. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 20 1 file changed, 16 insertions(+), 4 deletions(-) diff --git

[PATCH v5 05/11] media: ov5640: Compute the clock rate at runtime

with the new clock setup actually fix that error, and data are now sent at around 30fps. 2592x1944, on the other hand, is probably due to the fact that this mode can only be used using MIPI-CSI2, in a two lane mode, and never really tested with a DVP bus. Signed-off-by: Maxime Ripard --- drivers/media

[PATCH v5 06/11] media: ov5640: Remove pixel clock rates

The pixel clock rates were introduced to report the initially static clock rate. Since this is now handled dynamically, we can remove them entirely. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 21 + 1 file changed, 1 insertion(+), 20 deletions(-) diff

[PATCH v5 04/11] media: ov5640: Remove redundant register setup

The MIPI divider is also cleared as part of the clock setup sequence, so we can remove that code. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index 1b295d07aa15

[PATCH v5 03/11] media: ov5640: Remove redundant defines

The OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT and OV5640_SCLK_ROOT_DIVIDER_DEFAULT defines represent exactly the same setup, and are at the same value, than the more consistent with the rest of the driver OV5640_SCLK2X_ROOT_DIV and OV5640_SCLK_ROOT_DIV. Remove them. Signed-off-by: Maxime Ripard

[PATCH v5 09/11] media: ov5640: Make the FPS clamping / rounding more extendable

The current code uses an algorithm to clamp the FPS values and round them to the closest supported one that isn't really allows to be extended to more than two values. Rework it a bit to make it much easier to extend the amount of FPS options we support. Signed-off-by: Maxime Ripard

[PATCH v5 07/11] media: ov5640: Enhance FPS handling

Now that we have moved the clock generation logic out of the bytes array, these arrays are identical between the 15fps and 30fps variants. Remove the duplicate entries, and convert the code accordingly. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 306

[PATCH v5 02/11] media: ov5640: Remove the clocks registers initialization

Part of the hardcoded initialization sequence is to set up the proper clock dividers. However, this is now done dynamically through proper code and as such, the static one is now redundant. Let's remove it. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 46

[PATCH v5 08/11] media: ov5640: Make the return rate type more explicit

In the ov5640_try_frame_interval function, the ret variable actually holds the frame rate index to use, which is represented by the enum ov5640_frame_rate in the driver. Make it more obvious. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 8 1 file changed, 4 insertions

[PATCH v5 01/11] media: ov5640: Adjust the clock based on the expected rate

at runtime, we can remove them from the initialization sequence. The modes also gained a new parameter which is the clock that they are running at, from the register writes they were doing, so for now the switch to the new algorithm should be transparent. Signed-off-by: Maxime Ripard --- drivers/media

[PATCH v5 00/11] media: ov5640: Misc cleanup and improvements

es from v1: - Integrated Hugues' suggestions to fix v4l2-compliance - Fixed the bus width with JPEG - Dropped the clock rate calculation loops for something simpler as suggested by Sakari - Cache the exposure value instead of using the control value - Rebased on top of 4.17 Maxime Ripard (11

[PATCH v5 11/11] media: ov5640: Remove duplicate auto-exposure setup

The autoexposure setup in the 1080p init array is redundant with the default value of the sensor. Remove it. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c

Re: [PATCH] cedrus: check if kzalloc() fails

'ctx->ctrls'. (kzalloc returns null) > > The problem is that it assumes that kzalloc() will always > succeed. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com

Re: [PATCH 1/2] media: ov5640: Add check for PLL1 output max frequency

Hi, On Thu, Oct 18, 2018 at 03:35:25PM +0200, jacopo mondi wrote: > Hi Maxime, > > On Thu, Oct 18, 2018 at 11:15:50AM +0200, Maxime Ripard wrote: > > On Wed, Oct 17, 2018 at 09:37:17PM +0200, Jacopo Mondi wrote: > > > Check that the PLL1 output frequency does not ex

Re: [PATCH v4 01/12] media: ov5640: Adjust the clock based on the expected rate

Hi! On Thu, Oct 18, 2018 at 03:46:05PM +0200, jacopo mondi wrote: > Hello Maxime, > > On Thu, Oct 18, 2018 at 11:29:12AM +0200, Maxime Ripard wrote: > > Hi Jacopo, > > > > Thanks for reviewing this patch > > > > On Tue, Oct 16, 2018 at 06:54:50PM +02

Re: [PATCH v4 01/12] media: ov5640: Adjust the clock based on the expected rate

doesn't break existing users. So I guess we could merge your current patches into the v5 of my rework, and have Sam send his work on top of that. Does that make sense? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature

Re: [PATCH v4 01/12] media: ov5640: Adjust the clock based on the expected rate

_prediv = OV5640_PLL_PREDIV; > > + *pll_mult = best_mult; > > + return best; > > +} > > These function gets called at s_stream time, and cycle for a while, > and I'm under the impression the MIPI state machine doesn't like > delays too much, as I see timeouts on the rece

Re: [PATCH 1/2] media: ov5640: Add check for PLL1 output max frequency

r, I guess here you're setting _pll_mult at this value so that you won't reach the for condition on the next iteration? Wouldn't it be cleaner to just use a break statement here? Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature

Re: [PATCH v4 12/12] ov5640: Enforce a mode change when changing the framerate

Hi Hugues, On Mon, Oct 15, 2018 at 01:57:40PM +, Hugues FRUCHET wrote: > This is already fixed in media tree: > 0929983e49c81c1d413702cd9b83bb06c4a2555c media: ov5640: fix framerate update My bad then, I missed it, thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and

[PATCH v4 09/12] media: ov5640: Make the FPS clamping / rounding more extendable

The current code uses an algorithm to clamp the FPS values and round them to the closest supported one that isn't really allows to be extended to more than two values. Rework it a bit to make it much easier to extend the amount of FPS options we support. Signed-off-by: Maxime Ripard

[PATCH v4 12/12] ov5640: Enforce a mode change when changing the framerate

will be old or default one. Fix this by requiring that ov5640_set_mode is called when the frame interval is changed as well. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b

[PATCH v4 08/12] media: ov5640: Make the return rate type more explicit

In the ov5640_try_frame_interval function, the ret variable actually holds the frame rate index to use, which is represented by the enum ov5640_frame_rate in the driver. Make it more obvious. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 8 1 file changed, 4 insertions

[PATCH v4 11/12] media: ov5640: Remove duplicate auto-exposure setup

The autoexposure setup in the 1080p init array is redundant with the default value of the sensor. Remove it. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c

[PATCH v4 06/12] media: ov5640: Remove pixel clock rates

The pixel clock rates were introduced to report the initially static clock rate. Since this is now handled dynamically, we can remove them entirely. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 21 + 1 file changed, 1 insertion(+), 20 deletions(-) diff

[PATCH v4 07/12] media: ov5640: Enhance FPS handling

Now that we have moved the clock generation logic out of the bytes array, these arrays are identical between the 15fps and 30fps variants. Remove the duplicate entries, and convert the code accordingly. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 306

[PATCH v4 01/12] media: ov5640: Adjust the clock based on the expected rate

at runtime, we can remove them from the initialization sequence. The modes also gained a new parameter which is the clock that they are running at, from the register writes they were doing, so for now the switch to the new algorithm should be transparent. Signed-off-by: Maxime Ripard --- drivers/media

[PATCH v4 04/12] media: ov5640: Remove redundant register setup

The MIPI divider is also cleared as part of the clock setup sequence, so we can remove that code. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index 481406de8c55

[PATCH v4 10/12] media: ov5640: Add 60 fps support

Now that we have everything in place to compute the clock rate at runtime, we can enable the 60fps framerate for the mode we tested it with. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 20 1 file changed, 16 insertions(+), 4 deletions(-) diff --git

[PATCH v4 02/12] media: ov5640: Remove the clocks registers initialization

Part of the hardcoded initialization sequence is to set up the proper clock dividers. However, this is now done dynamically through proper code and as such, the static one is now redundant. Let's remove it. Signed-off-by: Maxime Ripard --- drivers/media/i2c/ov5640.c | 46

[PATCH v4 05/12] media: ov5640: Compute the clock rate at runtime

with the new clock setup actually fix that error, and data are now sent at around 30fps. 2592x1944, on the other hand, is probably due to the fact that this mode can only be used using MIPI-CSI2, in a two lane mode, and never really tested with a DVP bus. Signed-off-by: Maxime Ripard --- drivers/media

[PATCH v4 00/12] media: ov5640: Misc cleanup and improvements

trol value - Rebased on top of 4.17 Maxime Ripard (12): media: ov5640: Adjust the clock based on the expected rate media: ov5640: Remove the clocks registers initialization media: ov5640: Remove redundant defines media: ov5640: Remove redundant register setup media: ov5640: Compute the clock rate

[PATCH v4 03/12] media: ov5640: Remove redundant defines

The OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT and OV5640_SCLK_ROOT_DIVIDER_DEFAULT defines represent exactly the same setup, and are at the same value, than the more consistent with the rest of the driver OV5640_SCLK2X_ROOT_DIV and OV5640_SCLK_ROOT_DIV. Remove them. Signed-off-by: Maxime Ripard

Re: [RFC] Informal meeting during ELCE to discuss userspace support for stateless codecs

d I have no strong preference there, both work for me. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature

Re: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements

e always set the mode to auto and divider to 1, even for the > > lower resolutions? > > This is breaking 176x144@30fps on my side, because of pixel clock too > high (112MHz vs 70 MHz max). Ok. > Instead of using auto mode, my proposal was the inverse: use manual mode > with the proper divider to fit the max pixel clock constraint. Oh. That would work for me too yeah. How do you want to deal with it? Should I send your rebased patches, and you add that change as a subsequent patch? Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature

Re: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements

the PCLK divider while in auto-mode? IIRC, I did that and it was affecting the PCLK rate on my scope, but I wouldn't be definitive about it. Can we always set the mode to auto and divider to 1, even for the lower resolutions? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com

Re: [PATCH 3/4] media: dt-bindings: media: Document pclk-max-frequency property

ock frequency admissible by video > + host interface. That seems to be a property of the capture device, not the camera itself. Can't that be negotiated through the media API? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com

[PATCH v10 1/5] media: videobuf2-core: Rework and rename helper for request buffer count

of the helper don't need particular adaptation since the meaning of zero/non-zero remains consistent. Signed-off-by: Paul Kocialkowski Signed-off-by: Maxime Ripard --- .../media/common/videobuf2/videobuf2-core.c| 18 -- .../media/common/videobuf2/videobuf2-v4l2.c| 2 +- include

[PATCH v10 2/5] media: v4l: Add definitions for MPEG-2 slice format and metadata

passing the frame metadata to drivers. This is based on work from both Florent Revest and Hugues Fruchet. Signed-off-by: Paul Kocialkowski Signed-off-by: Maxime Ripard --- .../media/uapi/v4l/extended-controls.rst | 176 ++ .../media/uapi/v4l/pixfmt-compressed.rst | 16

[PATCH v10 5/5] media: platform: Add Cedrus VPU decoder driver

by the linux-sunxi community in the interest of reverse engineering, documenting and implementing support for the Allwinner VPU. Signed-off-by: Paul Kocialkowski Acked-by: Maxime Ripard Signed-off-by: Hans Verkuil [hans.verk...@cisco.com: dropped obsolete MEDIA_REQUEST_API from Kconfig

[PATCH v10 0/5] Cedrus driver for the Allwinner Video Engine, using media requests

to version 13 of the media request API; * integrated various changes from Maxime Ripard; * reworked memory reservation to use CMA, dynamic allocation and allow DMABUF; * removed reserved memory binding since the CMA pool is the default one (and allow ENODEV in the driver, for that use case); * added

[PATCH v10 4/5] dt-bindings: media: Document bindings for the Cedrus VPU driver

From: Paul Kocialkowski This adds a device-tree binding document that specifies the properties used by the Cedrus VPU driver, as well as examples. Signed-off-by: Paul Kocialkowski Reviewed-by: Rob Herring Acked-by: Maxime Ripard Signed-off-by: Maxime Ripard --- .../devicetree/bindings

[PATCH v10 3/5] media: v4l: Add definition for the Sunxi tiled NV12 format

to bottom). This tiled NV12 format is used by the video engine on Allwinner platforms: it is the default format for decoded frames (and the only one available in the oldest supported platforms). Signed-off-by: Paul Kocialkowski Signed-off-by: Maxime Ripard --- Documentation/media/uapi/v4l/pixfmt

[PATCH RESEND v2] staging: cedrus: Fix checkpatch issues

Checkpatch, when used with --strict, reports a number of issues on the cedrus driver. Fix those warnings, except for a few, minor, lines too long warnings. Signed-off-by: Maxime Ripard --- Resent since some changes were left uncommitted. Changes from v1: - Removed the find_control wrapping

[PATCH v2] staging: cedrus: Fix checkpatch issues

Checkpatch, when used with --strict, reports a number of issues on the cedrus driver. Fix those warnings, except for a few, minor, lines too long warnings. Signed-off-by: Maxime Ripard --- Changes from v1: - Removed the find_control wrapping - Added the bit length to the required variable

[PATCH] staging: cedrus: Fix checkpatch issues

Checkpatch, when used with --strict, reports a number of issues on the cedrus driver. Fix those warnings, except for a few, minor, lines too long warnings. Signed-off-by: Maxime Ripard --- drivers/staging/media/sunxi/cedrus/cedrus.c | 10 +- drivers/staging/media/sunxi/cedrus

Re: [GIT PULL FOR v4.20 (request_api branch)] Add Allwinner cedrus decoder driver

through arm-soc, to reduce the merge conflicts. I guess we can do it through several ways, depending on what's the most convenient for you: - Drop the patches in your PR, - Send a revert patch as an additional patch on top of your current PR - Or just merge the same patches in our tree and let git figure it out. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature

Re: [RFP] Stateless Codec Userspace Support

rds testing and less a 'proper' implementation. While the first one is definitely a test tool, I wouldn't consider the latter as such. We have Kodi and VLC running with it, and we started to work on using gstreamer on top of it, so it's definitely something I would consider for real world use cas

Re: [PATCH 1/2] media: ov5640: Fix timings setup code

Fix this by programming timings right after the static register value table > has been sent to the sensor in the ov5640_load_regs() function. > > Fixes: 476dec012f4c ("media: ov5640: Add horizontal and vertical totals") > Signed-off-by: Samuel Bobrowicz > Signed-off-by: M

Re: [PATCH 1/2] media: i2c: ov5640: Re-work MIPI start sequence

0x42, 0, 0}, > {0x3103, 0x03, 0, 0}, {0x3017, 0x00, 0, 0}, {0x3018, 0x00, 0, 0}, > + {0x3019, 0x70, 0, 0}, I'd really prefer to remove parts of that array, instead of adding more to that unmaintainable blob. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature

Re: [PATCH 0/4] media: sun6i: Add support for the H3 CSI controller

On Tue, Jun 26, 2018 at 02:42:11PM +0530, Jagan Teki wrote: > On Tue, Jun 26, 2018 at 1:53 PM, Maxime Ripard > wrote: > > Hi, > > > > On Tue, Jun 26, 2018 at 11:41:56AM +0530, Jagan Teki wrote: > >> On Mon, Mar 5, 2018 at 3:34 PM, Maxime Ripard > >&

Re: [PATCH 0/4] media: sun6i: Add support for the H3 CSI controller

Hi, On Tue, Jun 26, 2018 at 11:41:56AM +0530, Jagan Teki wrote: > On Mon, Mar 5, 2018 at 3:34 PM, Maxime Ripard > wrote: > > The H3 and H5 have a CSI controller based on the one previously found > > in the A31, that is currently supported by the sun6i-csi driver. > >

Re: [PATCH -next] media/platform/cadence: add to fix build error

tion 'kfree' [-Werror=implicit-function-declaration] > kfree(csi2rx); > > Signed-off-by: Randy Dunlap > Cc: Maxime Ripard Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature

Re: "media: ov5640: Add horizontal and vertical totals" regression issue on i.MX6QDL

On Thu, Jun 07, 2018 at 08:02:28PM +0530, Jagan Teki wrote: > Hi, > > ov5640 camera is breaking with below commit on i.MXQDL platform. > > commit 476dec012f4c6545b0b7599cd9adba2ed819ad3b > Author: Maxime Ripard > Date: Mon Apr 16 08:36:55 2018 -0400 >

Re: [PATCH v3 03/12] media: ov5640: Remove the clocks registers initialization

Hi Sam, On Fri, Jun 01, 2018 at 04:05:58PM -0700, Sam Bobrowicz wrote: > >> On May 21, 2018, at 12:39 AM, Maxime Ripard > >> wrote: > >> > >>> On Fri, May 18, 2018 at 07:42:34PM -0700, Sam Bobrowicz wrote: > >>>> On Fri, May 18, 2018 at 3

Re: [PATCH 2/5] media: v4l: cadence: include linux/slab.h

river") > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Maxime Ripard <maxime.rip...@bootlin.com> Thanks! Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature

Re: [PATCH v3 03/12] media: ov5640: Remove the clocks registers initialization

On Wed, May 23, 2018 at 11:31:58AM +0200, Daniel Mack wrote: > Hi Maxime, > > On Tuesday, May 22, 2018 09:54 PM, Maxime Ripard wrote: > > On Mon, May 21, 2018 at 09:39:02AM +0200, Maxime Ripard wrote: > > > On Fri, May 18, 2018 at 07:42:34PM -0700, Sam Bobrowicz wr

Re: [PATCH v3 03/12] media: ov5640: Remove the clocks registers initialization

On Mon, May 21, 2018 at 09:39:02AM +0200, Maxime Ripard wrote: > On Fri, May 18, 2018 at 07:42:34PM -0700, Sam Bobrowicz wrote: > > On Fri, May 18, 2018 at 3:35 AM, Daniel Mack <dan...@zonque.org> wrote: > > > On Thursday, May 17, 2018 10:53 AM, Maxime Ripard w

Re: [PATCH v3 03/12] media: ov5640: Remove the clocks registers initialization

On Fri, May 18, 2018 at 07:42:34PM -0700, Sam Bobrowicz wrote: > On Fri, May 18, 2018 at 3:35 AM, Daniel Mack <dan...@zonque.org> wrote: > > On Thursday, May 17, 2018 10:53 AM, Maxime Ripard wrote: > >> > >> Part of the hardcoded initialization sequence i

Re: [PATCH v3 01/12] media: ov5640: Fix timings setup code

Hi Daniel, On Fri, May 18, 2018 at 10:32:43AM +0200, Daniel Mack wrote: > On Thursday, May 17, 2018 10:53 AM, Maxime Ripard wrote: > > From: Samuel Bobrowicz <s...@elite-embedded.com> > > > > The current code, when changing the mode and changing the scaling or > &g

Re: [PATCH v2 11/12] media: ov5640: Add 60 fps support

ce one. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature

Re: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements

Hi, On Thu, May 17, 2018 at 11:24:04AM +0200, Daniel Mack wrote: > Hi, > > On Thursday, May 17, 2018 10:53 AM, Maxime Ripard wrote: > > Here is a "small" series that mostly cleans up the ov5640 driver code, > > slowly getting rid of the big data array for more und

[PATCH v3 00/12] media: ov5640: Misc cleanup and improvements

compliance - Fixed the bus width with JPEG - Dropped the clock rate calculation loops for something simpler as suggested by Sakari - Cache the exposure value instead of using the control value - Rebased on top of 4.17 Maxime Ripard (11): media: ov5640: Adjust the clock based on the exp

[PATCH v3 01/12] media: ov5640: Fix timings setup code

z <s...@elite-embedded.com> Signed-off-by: Maxime Ripard <maxime.rip...@bootlin.com> --- drivers/media/i2c/ov5640.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c index e480e53b369b..4bd968b478db 100644

[PATCH v3 03/12] media: ov5640: Remove the clocks registers initialization

Part of the hardcoded initialization sequence is to set up the proper clock dividers. However, this is now done dynamically through proper code and as such, the static one is now redundant. Let's remove it. Signed-off-by: Maxime Ripard <maxime.rip...@bootlin.com> --- drivers/media/i2c/ov

[PATCH v3 02/12] media: ov5640: Adjust the clock based on the expected rate

at runtime, we can remove them from the initialization sequence. The modes also gained a new parameter which is the clock that they are running at, from the register writes they were doing, so for now the switch to the new algorithm should be transparent. Signed-off-by: Maxime Ripard <maxime.

[PATCH v3 07/12] media: ov5640: Remove pixel clock rates

The pixel clock rates were introduced to report the initially static clock rate. Since this is now handled dynamically, we can remove them entirely. Signed-off-by: Maxime Ripard <maxime.rip...@bootlin.com> --- drivers/media/i2c/ov5640.c | 21 + 1 file changed, 1 ins

[PATCH v3 08/12] media: ov5640: Enhance FPS handling

Now that we have moved the clock generation logic out of the bytes array, these arrays are identical between the 15fps and 30fps variants. Remove the duplicate entries, and convert the code accordingly. Signed-off-by: Maxime Ripard <maxime.rip...@bootlin.com> --- drivers/media/i2c/ov

[PATCH v3 06/12] media: ov5640: Compute the clock rate at runtime

with the new clock setup actually fix that error, and data are now sent at around 30fps. 2592x1944, on the other hand, is probably due to the fact that this mode can only be used using MIPI-CSI2, in a two lane mode, and never really tested with a DVP bus. Signed-off-by: Maxime Ripard <maxime.

[PATCH v3 09/12] media: ov5640: Make the return rate type more explicit

In the ov5640_try_frame_interval function, the ret variable actually holds the frame rate index to use, which is represented by the enum ov5640_frame_rate in the driver. Make it more obvious. Signed-off-by: Maxime Ripard <maxime.rip...@bootlin.com> --- drivers/media/i2c/ov5640.c | 8 -

[PATCH v3 12/12] media: ov5640: Remove duplicate auto-exposure setup

The autoexposure setup in the 1080p init array is redundant with the default value of the sensor. Remove it. Signed-off-by: Maxime Ripard <maxime.rip...@bootlin.com> --- drivers/media/i2c/ov5640.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov56

[PATCH v3 11/12] media: ov5640: Add 60 fps support

Now that we have everything in place to compute the clock rate at runtime, we can enable the 60fps framerate for the mode we tested it with. Signed-off-by: Maxime Ripard <maxime.rip...@bootlin.com> --- drivers/media/i2c/ov5640.c | 30 -- 1 file changed, 24 inse

[PATCH v3 05/12] media: ov5640: Remove redundant register setup

The MIPI divider is also cleared as part of the clock setup sequence, so we can remove that code. Signed-off-by: Maxime Ripard <maxime.rip...@bootlin.com> --- drivers/media/i2c/ov5640.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/drivers/media/i2c/ov5640.c b/drivers/med

[PATCH v3 10/12] media: ov5640: Make the FPS clamping / rounding more extendable

The current code uses an algorithm to clamp the FPS values and round them to the closest supported one that isn't really allows to be extended to more than two values. Rework it a bit to make it much easier to extend the amount of FPS options we support. Signed-off-by: Maxime Ripard <maxime.

[PATCH v3 04/12] media: ov5640: Remove redundant defines

The OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT and OV5640_SCLK_ROOT_DIVIDER_DEFAULT defines represent exactly the same setup, and are at the same value, than the more consistent with the rest of the driver OV5640_SCLK2X_ROOT_DIV and OV5640_SCLK_ROOT_DIV. Remove them. Signed-off-by: Maxime Ripard

Re: [PATCH v2 11/12] media: ov5640: Add 60 fps support

k needed in the v4l2 device for it to work? Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature

Re: [PATCH v2 00/12] media: ov5640: Misc cleanup and improvements

ped the clock rate calculation loops for something simpler as > > suggested by Sakari > > - Cache the exposure value instead of using the control value > > - Rebased on top of 4.17 > > > > Maxime Ripard (10): > > media: ov5640: Don't force the auto exposure

Re: [PATCH v15 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

Driver is based on a prototype by Koji Matsuoka in the Renesas BSP. > > Signed-off-by: Niklas Söderlund <niklas.soderlund+rene...@ragnatech.se> Reviewed-by: Maxime Ripard <maxime.rip...@bootlin.com> Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kerne

Re: [PATCH 1/1] cadence: csi2rx: Fix csi2rx_start error handling

unsigned expression >= 0 is always true [-Wtype-limits] > > drivers/media/platform/cadence/cdns-csi2rx.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) That works for me :) Feel free to add my Acked-by: Maxime Ripard <maxime.rip...@bootlin.com> Thanks! Maxime --

  1   2   3   4   >