Re: [PATCH 2/2] media: ov5640: make MIPI clock depend on mode
Hi Adam, thanks for testing On Mon, Dec 03, 2018 at 10:28:04AM -0600, Adam Ford wrote: > On Thu, Nov 29, 2018 at 8:49 AM Jacopo Mondi > wrote: > > > > The MIPI clock generation tree uses the MIPI_DIV divider to generate both > > the > > MIPI SCALER CLOCK and the PIXEL_CLOCK. It seems the MIPI BIT CLK frequency > > is > > generated by either the MIPI SCALER or the PIXEL CLOCK, depending if the > > currently applied image mode uses the scaler or not. > > > > Make the MIPI_DIV selection value depend on the subsampling mode used by the > > currently applied image mode. > > > > Tested with: > > 172x144 320x240, 640x480, 1024x756, 1024x768, 1280x720, 1920x1080 in YUYV > > mode > > at 10, 15, 20, and 30 FPS with MIPI CSI-2 2 lanes mode. > > > > Signed-off-by: Jacopo Mondi > > I am not able to apply this patch to 4.19.6, 4.19-RC5, or Linux-media master > [1] > > Is there a specific branch/repo somewhere I can pull? I was able to > apply patch 1/2 just fine, but 2/2 wouldn't apply Reading the cover letter: "these two patches should be applied on top of Maxime's clock tree rework v5" Maxime has included those 2 in his v6. You may want to test that one :) Thanks j > > [1] - git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media.git > > adam > > --- > > Maxime, > >this patch is not just a cosmetic updates to the 'set_mipi_pclk()' > > comment block as I anticipated, but it actually fix the framerate handling > > compared for CSI-2, which in you v5 results halved for most modes. I have > > not included any "Fixes:" tag, as I hope this patch will get in with your > > v5. > > > > That's my bad, as in the patches I sent to be applied on top of your v4 I > > forgot to add a change, and the requested SCLK rate was always half of what > > it was actually required. > > > > Also, I have left out from this patches most of Sam's improvements (better > > SCLK > > selection policies, and programming of register OV5640_REG_PCLK_PERIOD as > > for > > from testing they're not required, and I don't want to pile more patches > > than > > necessary for the next merge window, not to slow down the clock tree rework > > inclusion. We can get back to it after it got merged. > > > > This are the test result obtained by capturing 100 frames with yavta and > > inspecting the reported fps results. > > > > Results are pretty neat, 2592x1944 mode apart, which runs a bit slow. > > > > capturing 176x144 @ 10FPS > > Captured 100 frames in 10.019398 seconds (9.980640 fps, 505898.657683 B/s). > > capturing 176x144 @ 15FPS > > Captured 100 frames in 6.681860 seconds (14.965892 fps, 758591.132803 B/s). > > capturing 176x144 @ 20FPS > > Captured 100 frames in 5.056204 seconds (19.777683 fps, 1002491.196755 B/s). > > capturing 176x144 @ 30FPS > > Captured 100 frames in 3.357204 seconds (29.786686 fps, 1509827.521040 B/s). > > > > capturing 320x240 @ 10FPS > > Captured 100 frames in 10.015432 seconds (9.984591 fps, 1533633.245951 B/s). > > capturing 320x240 @ 15FPS > > Captured 100 frames in 6.684035 seconds (14.961021 fps, 2298012.872049 B/s). > > capturing 320x240 @ 20FPS > > Captured 100 frames in 5.019164 seconds (19.923635 fps, 3060270.391218 B/s). > > capturing 320x240 @ 30FPS > > Captured 100 frames in 3.352991 seconds (29.824115 fps, 4580984.103432 B/s). > > > > capturing 640x480 @ 10FPS > > Captured 100 frames in 9.990389 seconds (10.009620 fps, 6149910.678538 B/s). > > capturing 640x480 @ 15FPS > > Captured 100 frames in 6.856242 seconds (14.585249 fps, 8961176.838123 B/s). > > capturing 640x480 @ 20FPS > > Captured 100 frames in 5.030264 seconds (19.879670 fps, 12214069.053476 > > B/s). > > capturing 640x480 @ 30FPS > > Captured 100 frames in 3.364612 seconds (29.721103 fps, 18260645.750580 > > B/s). > > > > capturing 720x480 @ 10FPS > > Captured 100 frames in 10.022488 seconds (9.977562 fps, 6896491.169279 B/s). > > capturing 720x480 @ 15FPS > > Captured 100 frames in 6.891968 seconds (14.509643 fps, 10029065.232208 > > B/s). > > capturing 720x480 @ 20FPS > > Captured 100 frames in 5.234133 seconds (19.105360 fps, 13205624.616211 > > B/s). > > capturing 720x480 @ 30FPS > > Captured 100 frames in 3.602298 seconds (27.760055 fps, 19187750.044688 > > B/s). > > > > capturing 720x576 @ 10FPS > > Captured 100 frames in 10.197244 seconds (9.806571 fps, 8133961.937805 B/s). > > capturing 720x576 @ 15FPS > > Captured 100 frames in 6.92
[PATCH 2/2] media: ov5640: make MIPI clock depend on mode
The MIPI clock generation tree uses the MIPI_DIV divider to generate both the MIPI SCALER CLOCK and the PIXEL_CLOCK. It seems the MIPI BIT CLK frequency is generated by either the MIPI SCALER or the PIXEL CLOCK, depending if the currently applied image mode uses the scaler or not. Make the MIPI_DIV selection value depend on the subsampling mode used by the currently applied image mode. Tested with: 172x144 320x240, 640x480, 1024x756, 1024x768, 1280x720, 1920x1080 in YUYV mode at 10, 15, 20, and 30 FPS with MIPI CSI-2 2 lanes mode. Signed-off-by: Jacopo Mondi --- Maxime, this patch is not just a cosmetic updates to the 'set_mipi_pclk()' comment block as I anticipated, but it actually fix the framerate handling compared for CSI-2, which in you v5 results halved for most modes. I have not included any "Fixes:" tag, as I hope this patch will get in with your v5. That's my bad, as in the patches I sent to be applied on top of your v4 I forgot to add a change, and the requested SCLK rate was always half of what it was actually required. Also, I have left out from this patches most of Sam's improvements (better SCLK selection policies, and programming of register OV5640_REG_PCLK_PERIOD as for from testing they're not required, and I don't want to pile more patches than necessary for the next merge window, not to slow down the clock tree rework inclusion. We can get back to it after it got merged. This are the test result obtained by capturing 100 frames with yavta and inspecting the reported fps results. Results are pretty neat, 2592x1944 mode apart, which runs a bit slow. capturing 176x144 @ 10FPS Captured 100 frames in 10.019398 seconds (9.980640 fps, 505898.657683 B/s). capturing 176x144 @ 15FPS Captured 100 frames in 6.681860 seconds (14.965892 fps, 758591.132803 B/s). capturing 176x144 @ 20FPS Captured 100 frames in 5.056204 seconds (19.777683 fps, 1002491.196755 B/s). capturing 176x144 @ 30FPS Captured 100 frames in 3.357204 seconds (29.786686 fps, 1509827.521040 B/s). capturing 320x240 @ 10FPS Captured 100 frames in 10.015432 seconds (9.984591 fps, 1533633.245951 B/s). capturing 320x240 @ 15FPS Captured 100 frames in 6.684035 seconds (14.961021 fps, 2298012.872049 B/s). capturing 320x240 @ 20FPS Captured 100 frames in 5.019164 seconds (19.923635 fps, 3060270.391218 B/s). capturing 320x240 @ 30FPS Captured 100 frames in 3.352991 seconds (29.824115 fps, 4580984.103432 B/s). capturing 640x480 @ 10FPS Captured 100 frames in 9.990389 seconds (10.009620 fps, 6149910.678538 B/s). capturing 640x480 @ 15FPS Captured 100 frames in 6.856242 seconds (14.585249 fps, 8961176.838123 B/s). capturing 640x480 @ 20FPS Captured 100 frames in 5.030264 seconds (19.879670 fps, 12214069.053476 B/s). capturing 640x480 @ 30FPS Captured 100 frames in 3.364612 seconds (29.721103 fps, 18260645.750580 B/s). capturing 720x480 @ 10FPS Captured 100 frames in 10.022488 seconds (9.977562 fps, 6896491.169279 B/s). capturing 720x480 @ 15FPS Captured 100 frames in 6.891968 seconds (14.509643 fps, 10029065.232208 B/s). capturing 720x480 @ 20FPS Captured 100 frames in 5.234133 seconds (19.105360 fps, 13205624.616211 B/s). capturing 720x480 @ 30FPS Captured 100 frames in 3.602298 seconds (27.760055 fps, 19187750.044688 B/s). capturing 720x576 @ 10FPS Captured 100 frames in 10.197244 seconds (9.806571 fps, 8133961.937805 B/s). capturing 720x576 @ 15FPS Captured 100 frames in 6.925244 seconds (14.439924 fps, 11977050.339261 B/s). capturing 720x576 @ 20FPS Captured 100 frames in 4.68 seconds (20.000127 fps, 16588905.060854 B/s). capturing 720x576 @ 30FPS Captured 100 frames in 3.487568 seconds (28.673276 fps, 23782762.085212 B/s). capturing 1024x768 @ 10FPS Captured 100 frames in 10.107128 seconds (9.894007 fps, 15561928.174298 B/s). capturing 1024x768 @ 15FPS Captured 100 frames in 6.810568 seconds (14.683062 fps, 23094459.169337 B/s). capturing 1024x768 @ 20FPS Captured 100 frames in 5.012039 seconds (19.951960 fps, 31381719.096759 B/s). capturing 1024x768 @ 30FPS Captured 100 frames in 3.346338 seconds (29.883407 fps, 47002534.905114 B/s). capturing 1280x720 @ 10FPS Captured 100 frames in 9.957613 seconds (10.042567 fps, 18510459.665283 B/s). capturing 1280x720 @ 15FPS Captured 100 frames in 6.597751 seconds (15.156679 fps, 27936790.986673 B/s). capturing 1280x720 @ 20FPS Captured 100 frames in 4.946115 seconds (20.217888 fps, 37265611.495083 B/s). capturing 1280x720 @ 30FPS Captured 100 frames in 3.301329 seconds (30.290825 fps, 55832049.080847 B/s). capturing 1920x1080 @ 10FPS Captured 100 frames in 10.024745 seconds (9.975316 fps, 41369629.470131 B/s). capturing 1920x1080 @ 15FPS Captured 100 frames in 6.674363 seconds (14.982702 fps, 62136260.577244 B/s). capturing 1920x1080 @ 20FPS Captured 100 frames in 5.102174 seconds (19.599488 fps, 81282998.172684 B/s). capturing 1920x1080 @ 30FPS Captured 100 frames in 3.341157 seconds (29.929746 fps, 124124642.214916 B/s). capturing 2592x1944 @ 10FPS Captured
[PATCH 0/2] media: ov5640: MIPI fixes on top of Maxime's v5
Hello ov5640-ers, these two patches should be applied on top of Maxime's clock tree rework v5 and 'fix' MIPI CSI-2 clock tree configuration. The first patch is a fix that appeard in various forms on the list several times: if the image sizes gets updated but not the image format, the size update gets ignored. I had to fix this to run my FPS tests, and thus I'm sending the two together. I wish in future a re-work of the image format handling part, but for now, let's just fix it for v4.21. The second patch slightly reworks the MIPI clock tree configuration, based on inputs from Sam. The currently submitted v5 in which Maxime squashed my previous changes is 'broken'. That's my bad, as explained in the patch change log. Test results are attacched to patch [2/2]. Changelog for [2/2] is included in the patch itself. I wish these patches to go in with Maxime awesome clock tree re-work, pending his ack. Also, I have tested with an i.MX6Q board, with a CSI-2 2 data lanes setup. There are still a few things not clear to me in the MIPI clock tree, and I welcome more testing, preferibly with 1-lanes setups. Also, I had to re-apply Maxime's series and latest ov5640 patches on v4.19, as my test board is sort of broken with v4.20-rcX (it shouldn't make any difference in regard to this series, but I'm pointing it out anyhow). Recently Adam has been testing quite some ov5640 patches, if you fill like testing these as well on your setup (which I understand is a MIPI CSI-2 one) please report the results. Same for all other interested ones :) Thanks j Jacopo Mondi (2): media: i2c: ov5640: Fix set format regression media: ov5640: make MIPI clock depend on mode drivers/media/i2c/ov5640.c | 110 ++--- 1 file changed, 54 insertions(+), 56 deletions(-) -- 2.7.4
[PATCH 1/2] media: ov5640: Fix set format regression
The set_fmt operations updates the sensor format only when the image format
is changed. When only the image sizes gets changed, the format do not get
updated causing the sensor to always report the one that was previously in
use.
Without this patch, updating frame size only fails:
[fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb ...]
With this patch applied:
[fmt:UYVY8_2X8/1024x768@1/30 field:none colorspace:srgb xfer:srgb ...]
Fixes: 6949d864776e ("media: ov5640: do not change mode if format or frame
interval is unchanged")
Signed-off-by: Jacopo Mondi
---
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 03a031a42b3e..c659efe918a4 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2160,6 +2160,7 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
struct ov5640_dev *sensor = to_ov5640_dev(sd);
const struct ov5640_mode_info *new_mode;
struct v4l2_mbus_framefmt *mbus_fmt = >format;
+ struct v4l2_mbus_framefmt *fmt;
int ret;
if (format->pad != 0)
@@ -2177,22 +2178,20 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
if (ret)
goto out;
- if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
- struct v4l2_mbus_framefmt *fmt =
- v4l2_subdev_get_try_format(sd, cfg, 0);
+ if (format->which == V4L2_SUBDEV_FORMAT_TRY)
+ fmt = v4l2_subdev_get_try_format(sd, cfg, 0);
+ else
+ fmt = >fmt;
- *fmt = *mbus_fmt;
- goto out;
- }
+ *fmt = *mbus_fmt;
if (new_mode != sensor->current_mode) {
sensor->current_mode = new_mode;
sensor->pending_mode_change = true;
}
- if (mbus_fmt->code != sensor->fmt.code) {
- sensor->fmt = *mbus_fmt;
+ if (mbus_fmt->code != sensor->fmt.code)
sensor->pending_fmt_change = true;
- }
+
out:
mutex_unlock(>lock);
return ret;
--
2.7.4
Re: [PATCH v5 01/11] media: ov5640: Adjust the clock based on the expected rate
Hi Maxime,
On Tue, Nov 20, 2018 at 10:48:39AM +0100, Maxime Ripard wrote:
> 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 and every mode.
> > >
> > > This is troublesome, since we cannot adjust it at runtime based on other
> > > parameters (such as the number of bytes per pixel), and we can't support
> > > either framerates that have not been used by the various vendors, since we
> > > don't have the needed initialization sequence.
> > >
> > > We can however understand how the clock tree works, and then implement
> > > some
> > > functions to derive the various parameters from a given rate. And now that
> > > those parameters are calculated 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
> >
> > As you've squashed in my MIPI CSI-2 fixes, do you think it is
> > appropriate adding my So-b tag here?
>
> Yeah, I'll add your co-developped-by tag as well, if that's ok.
>
Yeah, whatever works for you here... Thanks ;)
> > > +/*
> > > + * This is supposed to be ranging from 1 to 16, but the value is
> > > + * always set to either 1 or 2 in the vendor kernels.
> > > + */
> >
> > I forgot to fix this comment in my patches you squahed in here (the
> > value now ranges from 1 to 16
>
> Ok.
>
> > > +#define OV5640_SYSDIV_MIN1
> > > +#define OV5640_SYSDIV_MAX16
> > > +
> > > +/*
> > > + * This is supposed to be ranging from 1 to 16, but the value is always
> > > + * set to 2 in the vendor kernels.
> > > + */
> > > +#define OV5640_MIPI_DIV 2
> > > +
> > > +/*
> > > + * This is supposed to be ranging from 1 to 2, but the value is always
> > > + * set to 2 in the vendor kernels.
> > > + */
> > > +#define OV5640_PLL_ROOT_DIV 2
> > > +#define OV5640_PLL_CTRL3_PLL_ROOT_DIV_2 BIT(4)
> > > +
> > > +/*
> > > + * We only supports 8-bit formats at the moment
> > > + */
> > > +#define OV5640_BIT_DIV 2
> > > +#define OV5640_PLL_CTRL0_MIPI_MODE_8BIT 0x08
> > > +
> > > +/*
> > > + * This is supposed to be ranging from 1 to 8, but the value is always
> > > + * set to 2 in the vendor kernels.
> > > + */
> > > +#define OV5640_SCLK_ROOT_DIV 2
> > > +
> > > +/*
> > > + * This is hardcoded so that the consistency is maintained between SCLK
> > > and
> > > + * SCLK 2x.
> > > + */
> > > +#define OV5640_SCLK2X_ROOT_DIV (OV5640_SCLK_ROOT_DIV / 2)
> > > +
> > > +/*
> > > + * This is supposed to be ranging from 1 to 8, but the value is always
> > > + * set to 1 in the vendor kernels.
> > > + */
> > > +#define OV5640_PCLK_ROOT_DIV 1
> > > +#define OV5640_PLL_SYS_ROOT_DIVIDER_BYPASS 0x00
> > > +
> > > +static unsigned long ov5640_compute_sys_clk(struct ov5640_dev *sensor,
> > > + u8 pll_prediv, u8 pll_mult,
> > > + u8 sysdiv)
> > > +{
> > > + unsigned long sysclk = sensor->xclk_freq / pll_prediv * pll_mult;
> > > +
> > > + /* PLL1 output cannot exceed 1GHz. */
> > > + if (sysclk / 100 > 1000)
> > > + return 0;
> > > +
> > > + return sysclk / sysdiv;
> > > +}
> >
> > That's better, but Sam's version is even better. I plan to pick some
> > part of his patch and apply them on top of this (for this and a few
> > other things I'm pointing out a here below). How would you like to
> > have those updates? Incremental patches on top of this series once it
> > gets merged (and it can now be merged, since it works for both CSI-2
> > and DVP), or would you like to receive those patches, squash them in
> > and re-send?
>
> The first solution would be better, having to constantly piling u
Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset
Hi Sakari, On Wed, Nov 14, 2018 at 09:40:50AM +0200, Sakari Ailus wrote: > Hi Jacopo, > > On Wed, Nov 14, 2018 at 01:25:11AM +0100, jacopo mondi wrote: > > On Mon, Oct 29, 2018 at 03:22:54PM -0700, Yong Zhi wrote: > > > Hi, > > > > > > This series adds support for the Intel IPU3 (Image Processing Unit) > > > ImgU which is essentially a modern memory-to-memory ISP. It implements > > > raw Bayer to YUV image format conversion as well as a large number of > > > other pixel processing algorithms for improving the image quality. > > > > > > Meta data formats are defined for image statistics (3A, i.e. automatic > > > white balance, exposure and focus, histogram and local area contrast > > > enhancement) as well as for the pixel processing algorithm parameters. > > > The documentation for these formats is currently not included in the > > > patchset but will be added in a future version of this set. > > > > > > The algorithm parameters need to be considered specific to a given frame > > > and typically a large number of these parameters change on frame to frame > > > basis. Additionally, the parameters are highly structured (and not a flat > > > space of independent configuration primitives). They also reflect the > > > data structures used by the firmware and the hardware. On top of that, > > > the algorithms require highly specialized user space to make meaningful > > > use of them. For these reasons it has been chosen video buffers to pass > > > the parameters to the device. > > > > > > On individual patches: > > > > > > The heart of ImgU is the CSS, or Camera Subsystem, which contains the > > > image processors and HW accelerators. > > > > > > The 3A statistics and other firmware parameter computation related > > > functions are implemented in patch 11. > > > > > > All IPU3 pipeline default settings can be found in patch 10. > > > > > > > Seems to me that patch 10 didn't make it to the mailing list, am I > > wrong? > > > > I'm pointing it out as the same happened on your v6. > > Thanks for pointing this out. I've uploaded the entire set here: > > https://git.linuxtv.org/sailus/media_tree.git/log/?h=ipu3-v7> > > including the 10th patch: > > https://git.linuxtv.org/sailus/media_tree.git/commit/?h=ipu3-v7=41e2f0d114dbc195efed079202d22748ddedbe83> > > It's too big to get through the list server. :-( > > Luckily, it's mostly tables so there's not much to review there. Default > settings, effectively. Thanks, I've now received all patches. Thanks j > > -- > Regards, > > Sakari Ailus > sakari.ai...@linux.intel.com signature.asc Description: PGP signature
Re: [PATCH v5 01/11] media: ov5640: Adjust the clock based on the expected rate
Hi Maxime,
many thanks for re-sending this updated version
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 and every mode.
>
> This is troublesome, since we cannot adjust it at runtime based on other
> parameters (such as the number of bytes per pixel), and we can't support
> either framerates that have not been used by the various vendors, since we
> don't have the needed initialization sequence.
>
> We can however understand how the clock tree works, and then implement some
> functions to derive the various parameters from a given rate. And now that
> those parameters are calculated 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
As you've squashed in my MIPI CSI-2 fixes, do you think it is
appropriate adding my So-b tag here?
> ---
> drivers/media/i2c/ov5640.c | 366 -
> 1 file changed, 365 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index eaefdb58653b..8476f85bb8e7 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -175,6 +175,7 @@ struct ov5640_mode_info {
> u32 htot;
> u32 vact;
> u32 vtot;
> + u32 pixel_clock;
> const struct reg_value *reg_data;
> u32 reg_data_size;
> };
> @@ -700,6 +701,7 @@ static const struct reg_value
> ov5640_setting_15fps_QSXGA_2592_1944[] = {
> /* power-on sensor init reg table */
> static const struct ov5640_mode_info ov5640_mode_init_data = {
> 0, SUBSAMPLING, 640, 1896, 480, 984,
> + 5600,
> ov5640_init_setting_30fps_VGA,
> ARRAY_SIZE(ov5640_init_setting_30fps_VGA),
> };
> @@ -709,74 +711,91 @@
> ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = {
> {
> {OV5640_MODE_QCIF_176_144, SUBSAMPLING,
>176, 1896, 144, 984,
> + 2800,
>ov5640_setting_15fps_QCIF_176_144,
>ARRAY_SIZE(ov5640_setting_15fps_QCIF_176_144)},
> {OV5640_MODE_QVGA_320_240, SUBSAMPLING,
>320, 1896, 240, 984,
> + 2800,
>ov5640_setting_15fps_QVGA_320_240,
>ARRAY_SIZE(ov5640_setting_15fps_QVGA_320_240)},
> {OV5640_MODE_VGA_640_480, SUBSAMPLING,
>640, 1896, 480, 1080,
> + 2800,
>ov5640_setting_15fps_VGA_640_480,
>ARRAY_SIZE(ov5640_setting_15fps_VGA_640_480)},
> {OV5640_MODE_NTSC_720_480, SUBSAMPLING,
>720, 1896, 480, 984,
> + 2800,
>ov5640_setting_15fps_NTSC_720_480,
>ARRAY_SIZE(ov5640_setting_15fps_NTSC_720_480)},
> {OV5640_MODE_PAL_720_576, SUBSAMPLING,
>720, 1896, 576, 984,
> + 2800,
>ov5640_setting_15fps_PAL_720_576,
>ARRAY_SIZE(ov5640_setting_15fps_PAL_720_576)},
> {OV5640_MODE_XGA_1024_768, SUBSAMPLING,
>1024, 1896, 768, 1080,
> + 2800,
>ov5640_setting_15fps_XGA_1024_768,
>ARRAY_SIZE(ov5640_setting_15fps_XGA_1024_768)},
> {OV5640_MODE_720P_1280_720, SUBSAMPLING,
>1280, 1892, 720, 740,
> + 2100,
>ov5640_setting_15fps_720P_1280_720,
>ARRAY_SIZE(ov5640_setting_15fps_720P_1280_720)},
> {OV5640_MODE_1080P_1920_1080, SCALING,
>1920, 2500, 1080, 1120,
> + 4200,
>ov5640_setting_15fps_1080P_1920_1080,
>ARRAY_SIZE(ov5640_setting_15fps_1080P_1920_1080)},
> {OV5640_MODE_QSXGA_2592_1944, SCALING,
>2592, 2844, 1944, 1968,
> + 8400,
>ov5640_setting_15fps_QSXGA_2592_1944,
>ARRAY_SIZE(ov5640_setting_15fps_QSXGA_2592_1944)},
> }, {
> {OV5640_MODE_QCIF_176_144, SUBSAMPLING,
>176, 1896, 144, 984,
> + 5600,
>ov5640_setting_30fps_QCIF_176_144,
>ARRAY_SIZE(ov5640_setting_30fps_QCIF_176_144)},
> {OV5640_MODE_QVGA_320_240, SUBSAMPLING,
>320, 1896, 240, 984,
> + 5600,
>ov5640_setting_30fps_QVGA_320_240,
>ARRAY_SIZE(ov5640_setting_30fps_QVGA_320_240)},
> {OV5640_MODE_VGA_640_480, SUBSAMPLING,
>640, 1896, 480, 1080,
> + 5600,
>ov5640_setting_30fps_VGA_640_480,
>
Re: [PATCH v7 00/16] Intel IPU3 ImgU patchset
On Mon, Oct 29, 2018 at 03:22:54PM -0700, Yong Zhi wrote: > Hi, > > This series adds support for the Intel IPU3 (Image Processing Unit) > ImgU which is essentially a modern memory-to-memory ISP. It implements > raw Bayer to YUV image format conversion as well as a large number of > other pixel processing algorithms for improving the image quality. > > Meta data formats are defined for image statistics (3A, i.e. automatic > white balance, exposure and focus, histogram and local area contrast > enhancement) as well as for the pixel processing algorithm parameters. > The documentation for these formats is currently not included in the > patchset but will be added in a future version of this set. > > The algorithm parameters need to be considered specific to a given frame > and typically a large number of these parameters change on frame to frame > basis. Additionally, the parameters are highly structured (and not a flat > space of independent configuration primitives). They also reflect the > data structures used by the firmware and the hardware. On top of that, > the algorithms require highly specialized user space to make meaningful > use of them. For these reasons it has been chosen video buffers to pass > the parameters to the device. > > On individual patches: > > The heart of ImgU is the CSS, or Camera Subsystem, which contains the > image processors and HW accelerators. > > The 3A statistics and other firmware parameter computation related > functions are implemented in patch 11. > > All IPU3 pipeline default settings can be found in patch 10. > Seems to me that patch 10 didn't make it to the mailing list, am I wrong? I'm pointing it out as the same happened on your v6. Thanks j > To access DDR via ImgU's own memory space, IPU3 is also equipped with > its own MMU unit, the driver is implemented in patch 6. > > Patch 7 uses above driver for DMA mapping operation. > > The communication between IPU3 firmware and driver is implemented with > circular > queues in patch 8. > > Patch 9 provide some utility functions and manage IPU3 fw download and > install. > > The firmware which is called ipu3-fw.bin can be downloaded from: > > git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git > (commit 2c27b0cb02f18c022d8378e0e1abaf8b7ae8188f) > > Firmware ABI is defined in patches 4 and 5. > > Patches 12 and 13 are of the same file, the former contains all h/w > programming > related code, the latter implements interface functions for access fw & hw > capabilities. > > Patch 14 has a dependency on Sakari's V4L2_BUF_TYPE_META_OUTPUT work: > > https://patchwork.kernel.org/patch/9976295/> > > Patch 15 represents the top level that glues all of the other components > together, > passing arguments between the components. > > Patch 16 is a recent effort to extend v6 for advanced camera features like > Continuous View Finder (CVF) and Snapshot During Video(SDV) support. > > Link to user space implementation: > > git clone https://chromium.googlesource.com/chromiumos/platform/arc-camera > > ImgU media topology print: > > # media-ctl -d /dev/media0 -p > Media controller API version 4.19.0 > > Media device information > > driver ipu3-imgu > model ipu3-imgu > serial > bus infoPCI::00:05.0 > hw revision 0x80862015 > driver version 4.19.0 > > Device topology > - entity 1: ipu3-imgu 0 (5 pads, 5 links) > type V4L2 subdev subtype Unknown flags 0 > device node name /dev/v4l-subdev0 > pad0: Sink > [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown >crop:(0,0)/1920x1080 >compose:(0,0)/1920x1080] > <- "ipu3-imgu 0 input":0 [] > pad1: Sink > [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > <- "ipu3-imgu 0 parameters":0 [] > pad2: Source > [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > -> "ipu3-imgu 0 output":0 [] > pad3: Source > [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > -> "ipu3-imgu 0 viewfinder":0 [] > pad4: Source > [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > -> "ipu3-imgu 0 3a stat":0 [] > > - entity 7: ipu3-imgu 1 (5 pads, 5 links) > type V4L2 subdev subtype Unknown flags 0 > device node name /dev/v4l-subdev1 > pad0: Sink > [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown >crop:(0,0)/1920x1080 >compose:(0,0)/1920x1080] > <- "ipu3-imgu 1 input":0 [] > pad1: Sink > [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > <- "ipu3-imgu 1 parameters":0 [] > pad2: Source > [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown] > -> "ipu3-imgu 1 output":0 [] > pad3: Source >
Re: [PATCH 0/7] media: i2c: small enhancements for camera sensor drivers
Hello Mita-san, thanks for the patches On Tue, Nov 13, 2018 at 01:00:47AM +0900, Akinobu Mita wrote: > This patchset addds relatively small enhancements (log_status ioctl, event > interface, V4L2_CID_TEST_PATTERN control, and V4L2_CID_COLORFX control) for > mt9m111, ov2640, ov5640, ov7670, and ov772x drivers. I have these devices > so these patches are tested with real devices. > For the ov772x part: Acked-by: Jacopo Mondi Thanks j > Akinobu Mita (7): > media: mt9m111: support log_status ioctl and event interface > media: mt9m111: add V4L2_CID_COLORFX control > media: ov2640: add V4L2_CID_TEST_PATTERN control > media: ov2640: support log_status ioctl and event interface > media: ov5640: support log_status ioctl and event interface > media: ov7670: support log_status ioctl and event interface > media: ov772x: support log_status ioctl and event interface > > drivers/media/i2c/mt9m111.c | 44 ++-- > drivers/media/i2c/ov2640.c | 21 +++-- > drivers/media/i2c/ov5640.c | 7 ++- > drivers/media/i2c/ov7670.c | 6 +- > drivers/media/i2c/ov772x.c | 7 ++- > 5 files changed, 78 insertions(+), 7 deletions(-) > > Cc: Steve Longerbeam > Cc: Jonathan Corbet > Cc: Jacopo Mondi > Cc: Sakari Ailus > Cc: Mauro Carvalho Chehab > -- > 2.7.4 > signature.asc Description: PGP signature
Re: i.MX6: can't capture on MIPI-CSI2 with DS90UB954
Hi Jean-Michel,
On Fri, Nov 02, 2018 at 09:09:42AM +0100, Jean-Michel Hautbois wrote:
> Hi Steve,
>
> Le mer. 31 oct. 2018 à 22:52, Steve Longerbeam a
> écrit :
> >
> > Hi Jean-Michel,
> >
> > We've done some work with another FPD-Link de-serializer (ds90ux940) and
> > IIRC we had some trouble figuring out how to coax the lanes into LP-11
> > state. But on the ds90ux940 it can be done by setting bit 7 in the CSI
> > Enable Port registers (offsets 0x13 and 0x14). But the "imx6-mipi-csi2:
> > clock lane timeout" message is something else and indicates the
> > de-serializer is not activating the clock lane during its s_stream(ON)
> > subdev call.
>
> I have been doing more work on the driver I have, and I had CSI
> enabled before the csi2_dphy_wait_stopstate() call for instance. Now,
> LP-11 state is ok.
> Then, in the s_stream subcall, I added a delay after enabling CSI (and
> the continuous clock) and it is better too, as the clock is seen
> correctly each time.
> But I still get into a EOF timeout, which sounds like another issue.
>
> FYI, I added the NFACK interrupt support in my local kernel just to
> see if New Frames are detected, and it is not the case either.
> Any reason for not using this interrupt (maybe in "debug" mode) ?
>
> Now, I used a scope (not very fast so I can't get into the very fast
> signals) and I can see some weird things.
> In a 1-lane configuration, and a 400MHz clock, I can get the following
> when looking at D0N and D0P (yellow and green, can't remember which
> color is which) :
> https://framapic.org/H65QXHvaWmao/qdyoARz12dNi.png
>
> The purple is the diff result.
>
> First I thought it was a start sequence (but with very bizarre things
> at the very beginning of the sequence) like described here :
> https://cms.edn.com/ContentEETimes/Images/EDN/Design%20How-To/MIPI_Sync-Sequence-in-the-transmitted-pattern.jpg
>
> But Jacopo remarked that the 'starting sequence' is actually sent in
> HS mode, so we should not be able to see it at all.
> He thinks that what we are looking at is actually a bad LP-11 -> LP01
> -> LP00 transition.
>
> And it could be the "HS ZERO" :
> https://cms.edn.com/ContentEETimes/Images/EDN/Design%20How-To/MIPI_HS-Burst-on-Data-Lane.jpg
Sorry, my wording was confusing maybe. I think that what we see in
your trace looks very similar to what the image above reports as "HS
ZERO" followed by "HS DATA". This confused me intially as I thought I
was looking at an "HS Sync Sequence" (as defined by D-PHY specs), while
as you reported, my understanding is that your trace shows LP signals,
before any HS data transmission happens (in the right
side of your trace, if I got this rigth) and we should see a stable
LP-11 state transitioning to LP01 and then LP00.
From my experience with ov5640 the i.MX6 seems more picky than other
devices on this. The ov5640 driver before commit:
aa4bb8b ("media: ov5640: Re-work MIPI startup sequence")
used to work fine on other platforms, while it failed on i.MX6 and
thus that patch.
This contrast with the fact that you now passes the:
imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0200
error you had reported in your initial email though :/
So please take my interpreation of that traces with a grain of salt, I
really don't want to mis-lead you to chase things that might actually
be correct.
Thanks
j
>
> What do you think of this ?
> We will conduce more complex measurements, with high speed analyzers
> in order to check everything, and we are right now focusing on a
> possible hardware issue (coule be the custom PCB which embeds the
> DS90UB954).
>
> Thanks,
> JM
signature.asc
Description: PGP signature
Re: [PATCH 3/4] SoC camera: Remove the framework and the drivers
On Tue, Oct 30, 2018 at 05:35:23PM -0300, Mauro Carvalho Chehab wrote: > Em Tue, 30 Oct 2018 21:28:57 +0100 > jacopo mondi escreveu: > > > Hi Mauro, > > > > On Tue, Oct 30, 2018 at 09:14:09AM -0300, Mauro Carvalho Chehab wrote: > > > Em Tue, 30 Oct 2018 01:21:34 +0200 > > > Sakari Ailus escreveu: > > > > > > > The SoC camera framework has been obsolete for some time and it is no > > > > longer functional. A few drivers have been converted to the V4L2 > > > > sub-device API but for the rest the conversion has not taken place yet. > > > > > > > > In order to keep the tree clean and to avoid keep maintaining > > > > non-functional and obsolete code, remove the SoC camera framework as > > > > well > > > > as the drivers that depend on it. > > > > > > > > Signed-off-by: Sakari Ailus > > > > --- > > > > Resending, this time with git format-patch -D . > > > > > > > > MAINTAINERS|8 - > > > > drivers/media/i2c/Kconfig |8 - > > > > drivers/media/i2c/Makefile |1 - > > > > drivers/media/i2c/soc_camera/Kconfig | 66 - > > > > drivers/media/i2c/soc_camera/Makefile | 10 - > > > > drivers/media/i2c/soc_camera/ov9640.h | 208 -- > > > > drivers/media/i2c/soc_camera/soc_mt9m001.c | 757 --- > > > > drivers/media/i2c/soc_camera/soc_mt9t112.c | 1157 --- > > > > drivers/media/i2c/soc_camera/soc_mt9v022.c | 1012 - > > > > drivers/media/i2c/soc_camera/soc_ov5642.c | 1087 -- > > > > drivers/media/i2c/soc_camera/soc_ov772x.c | 1123 -- > > > > drivers/media/i2c/soc_camera/soc_ov9640.c | 738 --- > > > > drivers/media/i2c/soc_camera/soc_ov9740.c | 996 - > > > > drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c | 1415 - > > > > drivers/media/i2c/soc_camera/soc_tw9910.c | 999 - > > > > > > I don't see why we should remove those. I mean, Jacopo is > > > actually converting those drivers to not depend on soc_camera, > > > and it is a way better to review those patches with the old > > > code in place. > > > > I have converted a few drivers used by some SH boards where I dropped > > dependencies on soc_camera, not to remove camera support from those. For > > others I don't have cameras to test with, nor I know about boards in > > mainline using them. > > > > From my side, driver conversion is done. > > > > > > > > So, at least while Jacopo is keep doing this work, I would keep > > > at Kernel tree, as it helps to see a diff when the driver changes > > > when getting rid of soc_camera dependencies. > > > > > > So, IMO, the best would be to move those to /staging, eventually > > > depending on BROKEN. > > > > However, somebody with a (rather old) development setup using those camera > > sensor may wants to see if mainline supports them. We actually had a > > few patches coming lately (for ov. I understand Sakari's argument that those > > could be retrieved from git history, but a few people will notice imo. > > I also understand the additional maintainership burden of keeping them > > around, so I'm fine with either ways ;) > > > > This is a list of the current situation in mainline, to have a better > > idea: > > > > $for i in `seq 1 9`; do CAM=$(head -n $i /tmp/soc_cams | tail -n 1); echo > > $CAM; find drivers/media/ -name $CAM; done > > t9m001.c > > drivers/media/i2c/soc_camera/mt9m001.c > > mt9t112.c > > drivers/media/i2c/mt9t112.c > > drivers/media/i2c/soc_camera/mt9t112.c > > mt9v022.c > > drivers/media/i2c/soc_camera/mt9v022.c > > ov5642.c > > drivers/media/i2c/soc_camera/ov5642.c > > ov772x.c > > drivers/media/i2c/ov772x.c > > drivers/media/i2c/soc_camera/ov772x.c > > ov9640.c > > drivers/media/i2c/soc_camera/ov9640.c > > ov9740.c > > drivers/media/i2c/soc_camera/ov9740.c > > rj54n1cb0c.c > > drivers/media/i2c/rj54n1cb0c.c > > drivers/media/i2c/soc_camera/rj54n1cb0c.c > > tw9910.c > > drivers/media/i2c/tw9910.c > > drivers/media/i2c/soc_camera/tw9910.c > > > > So it seems to me only the following sensor do not have a > > non-soc_camera driver at the moment: > > > > mt9m001.c > > mt9v022.c > > ov5642.c > > ov9640.c > > ov9740.c For a few of them (mt9m001, ov5642) there are cheap modules available online. The others ones have public documentation. I know they are old and dusty, supporting only parallel video interface. > > Ok. So, what about keeping just those 5 drivers at staging? If, after an > year, people won't do conversions, we can just drop them. > Let's see what Sakari and Hans think. Again, I'm fine with both ways ;) Thanks j > In any case, if we're ripping off soc_camera from the main tree, > moving to staging, no dependencies for soc_camera.h should be > kept at main tree. If any driver requires it, it should also be > moved to staging. > > Thanks, > Mauro signature.asc Description: PGP signature
Re: [PATCH 3/4] SoC camera: Remove the framework and the drivers
Hi Mauro, On Tue, Oct 30, 2018 at 09:14:09AM -0300, Mauro Carvalho Chehab wrote: > Em Tue, 30 Oct 2018 01:21:34 +0200 > Sakari Ailus escreveu: > > > The SoC camera framework has been obsolete for some time and it is no > > longer functional. A few drivers have been converted to the V4L2 > > sub-device API but for the rest the conversion has not taken place yet. > > > > In order to keep the tree clean and to avoid keep maintaining > > non-functional and obsolete code, remove the SoC camera framework as well > > as the drivers that depend on it. > > > > Signed-off-by: Sakari Ailus > > --- > > Resending, this time with git format-patch -D . > > > > MAINTAINERS|8 - > > drivers/media/i2c/Kconfig |8 - > > drivers/media/i2c/Makefile |1 - > > drivers/media/i2c/soc_camera/Kconfig | 66 - > > drivers/media/i2c/soc_camera/Makefile | 10 - > > drivers/media/i2c/soc_camera/ov9640.h | 208 -- > > drivers/media/i2c/soc_camera/soc_mt9m001.c | 757 --- > > drivers/media/i2c/soc_camera/soc_mt9t112.c | 1157 --- > > drivers/media/i2c/soc_camera/soc_mt9v022.c | 1012 - > > drivers/media/i2c/soc_camera/soc_ov5642.c | 1087 -- > > drivers/media/i2c/soc_camera/soc_ov772x.c | 1123 -- > > drivers/media/i2c/soc_camera/soc_ov9640.c | 738 --- > > drivers/media/i2c/soc_camera/soc_ov9740.c | 996 - > > drivers/media/i2c/soc_camera/soc_rj54n1cb0c.c | 1415 - > > drivers/media/i2c/soc_camera/soc_tw9910.c | 999 - > > I don't see why we should remove those. I mean, Jacopo is > actually converting those drivers to not depend on soc_camera, > and it is a way better to review those patches with the old > code in place. I have converted a few drivers used by some SH boards where I dropped dependencies on soc_camera, not to remove camera support from those. For others I don't have cameras to test with, nor I know about boards in mainline using them. From my side, driver conversion is done. > > So, at least while Jacopo is keep doing this work, I would keep > at Kernel tree, as it helps to see a diff when the driver changes > when getting rid of soc_camera dependencies. > > So, IMO, the best would be to move those to /staging, eventually > depending on BROKEN. However, somebody with a (rather old) development setup using those camera sensor may wants to see if mainline supports them. We actually had a few patches coming lately (for ov. I understand Sakari's argument that those could be retrieved from git history, but a few people will notice imo. I also understand the additional maintainership burden of keeping them around, so I'm fine with either ways ;) This is a list of the current situation in mainline, to have a better idea: $for i in `seq 1 9`; do CAM=$(head -n $i /tmp/soc_cams | tail -n 1); echo $CAM; find drivers/media/ -name $CAM; done t9m001.c drivers/media/i2c/soc_camera/mt9m001.c mt9t112.c drivers/media/i2c/mt9t112.c drivers/media/i2c/soc_camera/mt9t112.c mt9v022.c drivers/media/i2c/soc_camera/mt9v022.c ov5642.c drivers/media/i2c/soc_camera/ov5642.c ov772x.c drivers/media/i2c/ov772x.c drivers/media/i2c/soc_camera/ov772x.c ov9640.c drivers/media/i2c/soc_camera/ov9640.c ov9740.c drivers/media/i2c/soc_camera/ov9740.c rj54n1cb0c.c drivers/media/i2c/rj54n1cb0c.c drivers/media/i2c/soc_camera/rj54n1cb0c.c tw9910.c drivers/media/i2c/tw9910.c drivers/media/i2c/soc_camera/tw9910.c So it seems to me only the following sensor do not have a non-soc_camera driver at the moment: mt9m001.c mt9v022.c ov5642.c ov9640.c ov9740.c Thanks j > > Thanks, > Mauro signature.asc Description: PGP signature
Re: [PATCH] media: rename soc_camera I2C drivers
Hi Mauro, Hans, Sakari, On Fri, Oct 19, 2018 at 03:58:51PM +0300, Sakari Ailus wrote: > Hi Hans, Mauro, > > On Fri, Oct 19, 2018 at 02:39:27PM +0200, Hans Verkuil wrote: > > On 10/19/18 14:31, Mauro Carvalho Chehab wrote: > > > Em Fri, 19 Oct 2018 13:45:32 +0200 > > > Hans Verkuil escreveu: > > > > > >> On 10/19/18 13:43, Mauro Carvalho Chehab wrote: > > >>> Those drivers are part of the legacy SoC camera framework. > > >>> They're being converted to not use it, but sometimes we're > > >>> keeping both legacy any new driver. > > >>> > > >>> This time, for example, we have two drivers on media with > > >>> the same name: ov772x. That's bad. > > >>> > > >>> So, in order to prevent that to happen, let's prepend the SoC > > >>> legacy drivers with soc_. > > >>> > > >>> No functional changes. > > >>> > > >>> Signed-off-by: Mauro Carvalho Chehab > > >> > > >> Acked-by: Hans Verkuil > > > > > > For now, let's just avoid the conflict if one builds both modules and > > > do a modprobe ov772x. > > > > > >> Let's kill all of these in the next kernel. I see no reason for keeping > > >> them around. > > > > > > While people are doing those SoC conversions, I would keep it. We > > > > Which people are doing SoC conversions? Nobody is using soc-camera anymore. > > It is a dead driver. The only reason it hasn't been removed yet is lack of > > time since it is not just removing the driver, but also patching old board > > files that use soc_camera headers. Really left-overs since the corresponding > > soc-camera drivers have long since been removed. > > > > > could move it to staging, to let it clear that those drivers require > > > conversion, and give people some time to work on it. > > > > There is nobody working on it. These are old sensors, and few will have > > the hardware to test it. If someone needs such a sensor driver, then they > > can always look at an older kernel version. It's still in git after all. > > > > Just kill it rather then polluting the media tree. > > I remember at least Jacopo has been doing some. There was someone else as > well, but I don't remember right now who it was. That said, I'm not sure if > there's anything happening to the rest. Yes, I did port a few drivers and there are patches for others coming. [PATCH v2 0/4] media: soc_camera: ov9640: switch driver to v4l2_async from Peter Cvek (now in Cc) > > Is there something that prevents removing these right away? As you said > it's not functional and people can always check old versions if they want > to port the driver to V4L2 sub-device framework. All dependencies should have been solved so far, but given that someone might want to do the porting at some point, I don't see how bad would it be to have them in staging, even if people could look into the git history... > > -- > Regards, > > Sakari Ailus > sakari.ai...@linux.intel.com signature.asc Description: PGP signature
Re: [RFC PATCH] media: ov5640: calculate PLL settings for modes
Hi Sam,
some comments and questions.
I still hope we find a way to merge our changes, but I need to
understand something before.
On Wed, Oct 17, 2018 at 10:31:48AM -0700, Sam Bobrowicz wrote:
> Remove the PLL settings from the register blobs and
> calculate them based on required clocks. This allows
> more mode and input clock (xclk) configurations.
>
> Also ensure that PCLK PERIOD register 0x4837 is set
> so that MIPI receivers are not broken by this patch.
>
> Last, a change to the init register blob that helps
> ensure the following DPHY spec requirement is met:
>
> MIN HS_ZERO + MIN HS_PREPARE > 145 + t_UI * 10
>
> Signed-off-by: Sam Bobrowicz
> ---
>
> This is a modified version of Maxime's patch that works on my platform.
> My platform is a dual-lane MIPI CSI2 module with xclk=24MHz connected
> to a Xilinx Zynq Ultrascale+.
>
> One issue I am currently experiencing with this patch is that some
> 15Hz framerates are not working. This seems to be due to the slower
> clocks which are generated, and may be caused by the large ADC clock
> to SCLK ratio. I will be exploring some fixes this weekend. Thoughts on
> this would be appreciated.
>
> I am submitting this so that it can be compared to Maxime's, which has
> been reported to not be functional on MIPI platforms. I do a number of
> things differently, and I hope that those which are useful will be
> integrated into his patch.
>
> I think this patch (or the modified version of Maxime's patch) should
> be tested under the following conditions:
>
> 1) MIPI mode, xclk=24MHz
> 2) MIPI mode, xclk!=24MHz
> 3) DVP mode
> 4) JPEG format
>
> I'm setup to test the first two, but don't have the hardware/software
> to test 3 and 4.
I could test with 1) and 2) with xvclk at 26MHz
>
> This patch is based on the current master of media_linux
> "media: ov5640: fix framerate update".
>
> drivers/media/i2c/ov5640.c | 332
> ++---
> 1 file changed, 281 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index eaefdb5..c076955 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -85,6 +85,7 @@
> #define OV5640_REG_POLARITY_CTRL00 0x4740
> #define OV5640_REG_MIPI_CTRL00 0x4800
> #define OV5640_REG_DEBUG_MODE0x4814
> +#define OV5640_REG_PCLK_PERIOD 0x4837
> #define OV5640_REG_ISP_FORMAT_MUX_CTRL 0x501f
> #define OV5640_REG_PRE_ISP_TEST_SET1 0x503d
> #define OV5640_REG_SDE_CTRL0 0x5580
> @@ -94,9 +95,6 @@
> #define OV5640_REG_SDE_CTRL5 0x5585
> #define OV5640_REG_AVG_READOUT 0x56a1
>
> -#define OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT 1
> -#define OV5640_SCLK_ROOT_DIVIDER_DEFAULT 2
> -
> enum ov5640_mode_id {
> OV5640_MODE_QCIF_176_144 = 0,
> OV5640_MODE_QVGA_320_240,
> @@ -171,6 +169,7 @@ struct reg_value {
> struct ov5640_mode_info {
> enum ov5640_mode_id id;
> enum ov5640_downsize_mode dn_mode;
> + bool scaler; /* Mode uses ISP scaler (reg 0x5001,BIT(5)=='1') */
> u32 hact;
> u32 htot;
> u32 vact;
> @@ -291,7 +290,7 @@ static const struct reg_value
> ov5640_init_setting_30fps_VGA[] = {
> {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
> {0x501f, 0x00, 0, 0}, {0x4713, 0x03, 0, 0}, {0x4407, 0x04, 0, 0},
> {0x440e, 0x00, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
> - {0x4837, 0x0a, 0, 0}, {0x3824, 0x02, 0, 0},
> + {0x3824, 0x02, 0, 0}, {0x482a, 0x06, 0, 0},
> {0x5000, 0xa7, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x5180, 0xff, 0, 0},
> {0x5181, 0xf2, 0, 0}, {0x5182, 0x00, 0, 0}, {0x5183, 0x14, 0, 0},
> {0x5184, 0x25, 0, 0}, {0x5185, 0x24, 0, 0}, {0x5186, 0x09, 0, 0},
> @@ -345,7 +344,7 @@ static const struct reg_value
> ov5640_init_setting_30fps_VGA[] = {
> };
>
> static const struct reg_value ov5640_setting_30fps_VGA_640_480[] = {
> - {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
> + {0x3c07, 0x08, 0, 0},
> {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
> {0x3814, 0x31, 0, 0},
> {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
> @@ -364,7 +363,7 @@ static const struct reg_value
> ov5640_setting_30fps_VGA_640_480[] = {
> };
>
> static const struct reg_value ov5640_setting_15fps_VGA_640_480[] = {
> - {0x3035, 0x22, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
> + {0x3c07, 0x08, 0, 0},
> {0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
> {0x3814, 0x31, 0, 0},
> {0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
> @@ -383,7 +382,7 @@ static const struct reg_value
> ov5640_setting_15fps_VGA_640_480[] = {
> };
>
> static const struct reg_value ov5640_setting_30fps_XGA_1024_768[] = {
> - {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
> + {0x3c07, 0x08, 0, 0},
> {0x3c09,
Re: [PATCH v4 01/12] media: ov5640: Adjust the clock based on the expected rate
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 +0200, jacopo mondi wrote:
> > > +static unsigned long ov5640_compute_sys_clk(struct ov5640_dev *sensor,
> > > + u8 pll_prediv, u8 pll_mult,
> > > + u8 sysdiv)
> > > +{
> > > + unsigned long rate = clk_get_rate(sensor->xclk);
> >
> > The clock rate is stored in sensor->xclk at probe time, no need to
> > query it every iteration.
>
> From a clk API point of view though, there's nothing that guarantees
> that the clock rate hasn't changed between the probe and the time
> where this function is called.
Correct, bell, it can be queried in the caller and re-used here :)
>
> I appreciate that we're probably connected to an oscillator, but even
> then, on the Allwinner SoCs we've had the issue recently that one
> oscillator feeding the BT chip was actually had a muxer, with each
> option having a slightly different rate, which was bad enough for the
> BT chip to be non-functional.
>
> I can definitely imagine the same case happening here for some
> SoCs. Plus, the clock framework will cache the rate as well when
> possible, so we're not losing anything here.
I see, so please ignore this comment :)
>
> > > +
> > > + return rate / pll_prediv * pll_mult / sysdiv;
> > > +}
> > > +
> > > +static unsigned long ov5640_calc_sys_clk(struct ov5640_dev *sensor,
> > > + unsigned long rate,
> > > + u8 *pll_prediv, u8 *pll_mult,
> > > + u8 *sysdiv)
> > > +{
> > > + unsigned long best = ~0;
> > > + u8 best_sysdiv = 1, best_mult = 1;
> > > + u8 _sysdiv, _pll_mult;
> > > +
> > > + for (_sysdiv = OV5640_SYSDIV_MIN;
> > > + _sysdiv <= OV5640_SYSDIV_MAX;
> > > + _sysdiv++) {
> > > + for (_pll_mult = OV5640_PLL_MULT_MIN;
> > > + _pll_mult <= OV5640_PLL_MULT_MAX;
> > > + _pll_mult++) {
> > > + unsigned long _rate;
> > > +
> > > + /*
> > > + * The PLL multiplier cannot be odd if above
> > > + * 127.
> > > + */
> > > + if (_pll_mult > 127 && (_pll_mult % 2))
> > > + continue;
> > > +
> > > + _rate = ov5640_compute_sys_clk(sensor,
> > > +OV5640_PLL_PREDIV,
> > > +_pll_mult, _sysdiv);
> >
> > I'm under the impression a system clock slower than the requested one, even
> > if more accurate is not good.
> >
> > I'm still working on understanding how all CSI-2 related timing
> > parameters play together, but since the system clock is calculated
> > from the pixel clock (which comes from the frame dimensions, bpp, and
> > rate), and it is then used to calculate the MIPI BIT clock frequency,
> > I think it would be better to be a little faster than a bit slower,
> > otherwise the serial lane clock wouldn't be fast enough to output
> > frames generated by the sensor core (or maybe it would just decrease
> > the frame rate and that's it, but I don't think it is just this).
> >
> > What do you think of adding the following here:
> >
> > if (_rate < rate)
> > continue
>
> I really don't know MIPI-CSI2 enough to be able to comment on your
> concerns, but when reaching the end of the operating limit of the
> clock, it would prevent us from having any rate at all, which seems
> bad too.
Are you referring to the 1GHz limit of the (xvlkc / pre_div * mult)
output here? If that's your concern we should adjust the requested
SYSCLK rate then (and I added a check for that in my patches on top of
yours, but it could be improved to be honest, as it just refuses the
current rate, while it should increment the pre_divider instead, now
that I think better about that).
>
> > > + if (abs(rate - _rate) < abs(rate - best)) {
> > > + best = _rate;
> > > + best_sysdiv = _sysdiv;
> > > + best_mult = _pll_mult;
> > > + }
> > > +
> > > + if (_rate == rate)
> > > +
Re: [PATCH 1/2] media: ov5640: Add check for PLL1 output max frequency
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 exceed the maximum allowed
> > 1GHz
> > frequency.
> >
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/media/i2c/ov5640.c | 23 +++
> > 1 file changed, 19 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> > index e098435..1f2e72d 100644
> > --- a/drivers/media/i2c/ov5640.c
> > +++ b/drivers/media/i2c/ov5640.c
> > @@ -770,7 +770,7 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor,
> > u16 reg,
> > * always set to either 1 or 2 in the vendor kernels.
> > */
> > #define OV5640_SYSDIV_MIN 1
> > -#define OV5640_SYSDIV_MAX 2
> > +#define OV5640_SYSDIV_MAX 16
> >
> > /*
> > * This is supposed to be ranging from 1 to 16, but the value is always
> > @@ -806,15 +806,20 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor,
> > u16 reg,
> > * This is supposed to be ranging from 1 to 8, but the value is always
> > * set to 1 in the vendor kernels.
> > */
> > -#define OV5640_PCLK_ROOT_DIV 1
> > +#define OV5640_PCLK_ROOT_DIV 1
> > +#define OV5640_PLL_SYS_ROOT_DIVIDER_BYPASS 0x00
> >
> > static unsigned long ov5640_compute_sys_clk(struct ov5640_dev *sensor,
> > u8 pll_prediv, u8 pll_mult,
> > u8 sysdiv)
> > {
> > - unsigned long rate = clk_get_rate(sensor->xclk);
> > + unsigned long sysclk = sensor->xclk_freq / pll_prediv * pll_mult;
> >
> > - return rate / pll_prediv * pll_mult / sysdiv;
> > + /* PLL1 output cannot exceed 1GHz. */
> > + if (sysclk / 100 > 1000)
> > + return 0;
> > +
> > + return sysclk / sysdiv;
> > }
> >
> > static unsigned long ov5640_calc_sys_clk(struct ov5640_dev *sensor,
> > @@ -844,6 +849,16 @@ static unsigned long ov5640_calc_sys_clk(struct
> > ov5640_dev *sensor,
> > _rate = ov5640_compute_sys_clk(sensor,
> >OV5640_PLL_PREDIV,
> >_pll_mult, _sysdiv);
> > +
> > + /*
> > +* We have reached the maximum allowed PLL1 output,
> > +* increase sysdiv.
> > +*/
> > + if (rate == 0) {
> > + _pll_mult = OV5640_PLL_MULT_MAX + 1;
> > + continue;
> > + }
> > +
>
> Both your patches look sane to me. However, 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?
Yes, it's much cleaner indeed. Not sure why I thought this was a good
idea tbh.
Would you like me to send a v2, or can you take care of this when
re-sending v5?
Thanks
j
>
> Thanks!
> 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
On Thu, Oct 18, 2018 at 11:31:52AM +0200, Maxime Ripard wrote: > On Wed, Oct 17, 2018 at 09:51:43PM +0200, jacopo mondi wrote: > > Hello Sam and Maxime (and other ov5640-ers :) > > > > On Wed, Oct 17, 2018 at 10:54:01AM -0700, Sam Bobrowicz wrote: > > > Hello Maxime and Jacopo (and other ov5640-ers), > > > > > > I just submitted my version of this patch to the mailing list as RFC. > > > It is working on my MIPI platform. Please try it if you have time. > > > Hopefully we can merge these two into a single patch that doesn't > > > break any platforms. > > > > Thanks, I have seen your patch but it seems to contain a lot of things > > already part of Maxime's series. Was this intentional? > > > > Now the un-pleaseant part: I have just sent out my re-implementation > > of the MIPI clock tree configuration, based on top of Maxime's series. > > Both you and me have spent a looot of time on this I'm sure, and now > > we have two competing implementations. > > > > I had a quick look at yours, and for sure there are things I am not > > taking care of (I'm thinking about the 0x4837 register that seems to > > be important for your platform), so I think both our implementations > > can benefits from a comparison. What is important to me is that both > > you and me don't feel like our work has been wasted, so let's try to > > find out a way to get the better of the two put together, and possibly > > applied on top of Maxime's series, so that a v5 of this will work for > > both MIPI and DVP interfaces. How to do that I'm not sure atm, I think > > other reviewers might help in that if they want to have a look at both > > our series :) > > IIRC, Sam's system has never worked with the ov5640 driver, and his > patches now make it work. > > Your patches on the other hand make sure that the current series > 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? It does for me, but it puts the burden on Sam to re-apply his work on top of [yours+mine] (which is something he would have had to do anyhow to have his patches accepted, as he would have had to rebase on top of your series). I hope to find some more time to look into his series and find out how hard it would be to add his changes on top of mine, and hopefully help with this. Also, testing my patches with DVP would be nice (it should not be affected at all, but still...) Thanks j > > 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
Hello Sam and Maxime (and other ov5640-ers :)
On Wed, Oct 17, 2018 at 10:54:01AM -0700, Sam Bobrowicz wrote:
> Hello Maxime and Jacopo (and other ov5640-ers),
>
> I just submitted my version of this patch to the mailing list as RFC.
> It is working on my MIPI platform. Please try it if you have time.
> Hopefully we can merge these two into a single patch that doesn't
> break any platforms.
Thanks, I have seen your patch but it seems to contain a lot of things
already part of Maxime's series. Was this intentional?
Now the un-pleaseant part: I have just sent out my re-implementation
of the MIPI clock tree configuration, based on top of Maxime's series.
Both you and me have spent a looot of time on this I'm sure, and now
we have two competing implementations.
I had a quick look at yours, and for sure there are things I am not
taking care of (I'm thinking about the 0x4837 register that seems to
be important for your platform), so I think both our implementations
can benefits from a comparison. What is important to me is that both
you and me don't feel like our work has been wasted, so let's try to
find out a way to get the better of the two put together, and possibly
applied on top of Maxime's series, so that a v5 of this will work for
both MIPI and DVP interfaces. How to do that I'm not sure atm, I think
other reviewers might help in that if they want to have a look at both
our series :)
Thanks everyone for the hard work on this sensor for now!
Thanks
j
>
> Thanks,
> Sam
>
> Additional notes below.
>
> On Tue, Oct 16, 2018 at 9:54 AM jacopo mondi wrote:
> >
> > Hello Maxime,
> >a few comments I have collected while testing the series.
> >
> > Please see below.
> >
> > On Thu, Oct 11, 2018 at 11:20:56AM +0200, Maxime Ripard wrote:
> > > The clock structure for the PCLK is quite obscure in the documentation,
> > > and
> > > was hardcoded through the bytes array of each and every mode.
> > >
> > > This is troublesome, since we cannot adjust it at runtime based on other
> > > parameters (such as the number of bytes per pixel), and we can't support
> > > either framerates that have not been used by the various vendors, since we
> > > don't have the needed initialization sequence.
> > >
> > > We can however understand how the clock tree works, and then implement
> > > some
> > > functions to derive the various parameters from a given rate. And now that
> > > those parameters are calculated 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/i2c/ov5640.c | 289 -
> > > 1 file changed, 288 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> > > index 30b15e91d8be..88fb16341466 100644
> > > --- a/drivers/media/i2c/ov5640.c
> > > +++ b/drivers/media/i2c/ov5640.c
> > > @@ -175,6 +175,7 @@ struct ov5640_mode_info {
> > > u32 htot;
> > > u32 vact;
> > > u32 vtot;
> > > + u32 pixel_clock;
> > > const struct reg_value *reg_data;
> > > u32 reg_data_size;
> > > };
> > > @@ -700,6 +701,7 @@ static const struct reg_value
> > > ov5640_setting_15fps_QSXGA_2592_1944[] = {
> > > /* power-on sensor init reg table */
> > > static const struct ov5640_mode_info ov5640_mode_init_data = {
> > > 0, SUBSAMPLING, 640, 1896, 480, 984,
> > > + 5600,
> > > ov5640_init_setting_30fps_VGA,
> > > ARRAY_SIZE(ov5640_init_setting_30fps_VGA),
> > > };
> > > @@ -709,74 +711,91 @@
> > > ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = {
> > > {
> > > {OV5640_MODE_QCIF_176_144, SUBSAMPLING,
> > >176, 1896, 144, 984,
> > > + 2800,
> > >ov5640_setting_15fps_QCIF_176_144,
> > >ARRAY_SIZE(ov5640_setting_15fps_QCIF_176_144)},
> > > {OV5640_MODE_QVGA_320_240, SUBSAMPLING,
> > >320, 1896, 240, 984,
> > > + 2800,
> > >ov5640_setting_15fps_QVGA_320_240,
> > >ARRAY_SIZE(ov5640_setting_15fps_QVGA_320_240)},
&
[PATCH 2/2] media: ov5640: Re-implement MIPI clock configuration
Modify the MIPI clock tree calculation procedure.
The implemented function receives the total bandwidth required in bytes
and calculate the sample rate and the MIPI clock rate accordingly.
Tested with capture at 1080p, 720p, VGA and QVGA.
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/ov5640.c | 101 +++--
1 file changed, 80 insertions(+), 21 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 1f2e72d..8a0ead9 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -720,6 +720,9 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, u16
reg,
* +->| MIPI Divider | - reg 0x3035, bits 0-3
* | +-++
* |+> MIPI SCLK
+ * |+ +-+
+ * |+->| / 2 |---> MIPI BIT CLK
+ * | +-+
* | +--+
* +->| PLL Root Div | - reg 0x3037, bit 4
* +-++
@@ -782,13 +785,14 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, u16
reg,
* This is supposed to be ranging from 1 to 2, but the value is always
* set to 2 in the vendor kernels.
*/
-#define OV5640_PLL_ROOT_DIV2
+#define OV5640_PLL_ROOT_DIV2
+#define OV5640_PLL_CTRL3_PLL_ROOT_DIV_2BIT(4)
/*
- * This is supposed to be either 1, 2 or 2.5, but the value is always
- * set to 2 in the vendor kernels.
+ * We only supports 8-bit formats at the moment
*/
-#define OV5640_BIT_DIV 2
+#define OV5640_BIT_DIV 2
+#define OV5640_PLL_CTRL0_MIPI_MODE_8BIT0x08
/*
* This is supposed to be ranging from 1 to 8, but the value is always
@@ -874,32 +878,81 @@ static unsigned long ov5640_calc_sys_clk(struct
ov5640_dev *sensor,
*sysdiv = best_sysdiv;
*pll_prediv = OV5640_PLL_PREDIV;
*pll_mult = best_mult;
+
return best;
}
-static unsigned long ov5640_calc_mipi_clk(struct ov5640_dev *sensor,
- unsigned long rate,
- u8 *pll_prediv, u8 *pll_mult,
- u8 *sysdiv, u8 *mipi_div)
+/*
+ * ov5640_set_mipi_pclk() - Calculate the clock tree configuration values
+ * for the MIPI CSI-2 output.
+ *
+ * @rate: The requested bandwidth in bytes per second.
+ * It is calculated as: HTOT * VTOT * FPS * bpp
+ *
+ * This function use the requested bandwidth to calculate:
+ * - sample_rate = bandwidth / bpp;
+ * - mipi_clk = bandwidth / num_lanes / 2; ( / 2 for CSI-2 DDR)
+ *
+ * The bandwidth corresponds to the SYSCLK frequency generated by the
+ * PLL pre-divider, the PLL multiplier and the SYS divider (see the clock
+ * tree documented here above).
+ *
+ * From the SYSCLK frequency, the MIPI CSI-2 clock tree generates the
+ * pixel clock and the MIPI BIT clock as follows:
+ *
+ * MIPI_BIT_CLK = SYSCLK / MIPI_DIV / 2;
+ * PIXEL_CLK = SYSCLK / PLL_RDVI / BIT_DIVIDER / PCLK_DIV / MIPI_DIV
+ *
+ * with this fixed parameters:
+ * PLL_RDIV= 2;
+ * BIT_DIVIDER = 2; (MIPI_BIT_MODE == 8 ? 2 : 2,5);
+ * PCLK_DIV= 1;
+ *
+ * With these values we have:
+ *
+ * pixel_clock = bandwidth / bpp
+ *= bandwidth / 4 / MIPI_DIV;
+ *
+ * And so we can calculate MIPI_DIV as:
+ * MIPI_DIV = bpp / 4;
+ */
+static int ov5640_set_mipi_pclk(struct ov5640_dev *sensor,
+ unsigned long rate)
{
- unsigned long _rate = rate * OV5640_MIPI_DIV;
+ const struct ov5640_mode_info *mode = sensor->current_mode;
+ u8 mipi_div = OV5640_MIPI_DIV;
+ u8 prediv, mult, sysdiv;
+ int ret;
- _rate = ov5640_calc_sys_clk(sensor, _rate, pll_prediv, pll_mult,
- sysdiv);
- *mipi_div = OV5640_MIPI_DIV;
+ /* FIXME:
+* Practical experience shows we get a correct frame rate by
+* halving the bandwidth rate by 2, to slow down SYSCLK frequency.
+* Divide both SYSCLK and MIPI_DIV by two (with OV5640_MIPI_DIV
+* currently fixed at value '2', while according to the above
+* formula it should have been = bpp / 4 = 4).
+*
+* So that:
+* pixel_clock = bandwidth / 2 / bpp
+* = bandwidth / 2 / 4 / MIPI_DIV;
+* MIPI_DIV = bpp / 4 / 2;
+*/
+ rate /= 2;
- return _rate / *mipi_div;
-}
+ /* FIXME:
+* High resolution modes (1280x720, 1920x1080) requires an higher
+* clock speed. Half the MIPI_DIVIDER value to double the output
+* pixel clock and MIPI_CLK speeds.
+*/
+ if (mode->hact > 1024)
+ mipi_div /= 2;
-static int ov5640_set_mipi_pclk(struct ov5640_dev *sensor, unsigned long rate)
-{
- u8 prediv, mult, sysdiv, mipi_div;
- int ret;
+ ov5640_c
[PATCH 1/2] media: ov5640: Add check for PLL1 output max frequency
Check that the PLL1 output frequency does not exceed the maximum allowed 1GHz
frequency.
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/ov5640.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index e098435..1f2e72d 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -770,7 +770,7 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, u16
reg,
* always set to either 1 or 2 in the vendor kernels.
*/
#define OV5640_SYSDIV_MIN 1
-#define OV5640_SYSDIV_MAX 2
+#define OV5640_SYSDIV_MAX 16
/*
* This is supposed to be ranging from 1 to 16, but the value is always
@@ -806,15 +806,20 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, u16
reg,
* This is supposed to be ranging from 1 to 8, but the value is always
* set to 1 in the vendor kernels.
*/
-#define OV5640_PCLK_ROOT_DIV 1
+#define OV5640_PCLK_ROOT_DIV 1
+#define OV5640_PLL_SYS_ROOT_DIVIDER_BYPASS 0x00
static unsigned long ov5640_compute_sys_clk(struct ov5640_dev *sensor,
u8 pll_prediv, u8 pll_mult,
u8 sysdiv)
{
- unsigned long rate = clk_get_rate(sensor->xclk);
+ unsigned long sysclk = sensor->xclk_freq / pll_prediv * pll_mult;
- return rate / pll_prediv * pll_mult / sysdiv;
+ /* PLL1 output cannot exceed 1GHz. */
+ if (sysclk / 100 > 1000)
+ return 0;
+
+ return sysclk / sysdiv;
}
static unsigned long ov5640_calc_sys_clk(struct ov5640_dev *sensor,
@@ -844,6 +849,16 @@ static unsigned long ov5640_calc_sys_clk(struct ov5640_dev
*sensor,
_rate = ov5640_compute_sys_clk(sensor,
OV5640_PLL_PREDIV,
_pll_mult, _sysdiv);
+
+ /*
+* We have reached the maximum allowed PLL1 output,
+* increase sysdiv.
+*/
+ if (rate == 0) {
+ _pll_mult = OV5640_PLL_MULT_MAX + 1;
+ continue;
+ }
+
if (abs(rate - _rate) < abs(rate - best)) {
best = _rate;
best_sysdiv = _sysdiv;
--
2.7.4
[PATCH 0/2] media: ov5640: Re-implement MIPI clock tree configuration
Hello ov5640 people, this small series based on top of Maxime's v4 "media: ov5640: Misc cleanup and improvements" which fixes configuration of the MIPI clock tree which I have found not working in Maxime's series. As the aforementioned series containes a lot of useful things, I based my work on top of it with the hope this can be included in Maxime's next v5. I have tested capture with a MIPI CSI-2 2 lane interface, with the following results (frame rates reported by yavta) 1920x1080 Captured 100 frames in 6.696864 seconds (14.932362 fps, 61927490.138103 B/s). Captured 100 frames in 3.355459 seconds (29.802182 fps, 123595609.386497 B/s). Captured 100 frames in 1.656115 seconds (60.382280 fps, 37098872.964740 B/s). 1024x768 Captured 100 frames in 7.425156 seconds (13.467729 fps, 21182906.577451 B/s). Captured 100 frames in 3.431391 seconds (29.142700 fps, 45837504.382334 B/s). Captured 100 frames in 1.667302 seconds (59.977113 fps, 36849938.056268 B/s). 640x480 Captured 100 frames in 6.656321 seconds (15.023312 fps, 9230323.152105 B/s). Captured 100 frames in 3.323515 seconds (30.088620 fps, 18486448.133840 B/s). Captured 100 frames in 1.665959 seconds (60.025487 fps, 36879659.103255 B/s). 320x240 Captured 100 frames in 6.660575 seconds (15.013718 fps, 2306107.089817 B/s). Captured 100 frames in 3.333978 seconds (29.994199 fps, 4607108.983740 B/s). Captured 100 frames in 1.666797 seconds (59.995308 fps, 36861117.460615 B/s). I have also verified images are good in all resolutions. Sam has just shared his fixes for MIPI CSI-2 which are indeed different from these ones. My dream now would be to unify all of our changes in next Maxime's series iteration and have this merged. Please note that once this gets in, we could then get rid of fixed framerates, and hopefully improve mode settings and configuration \o/. I'll try to look into Sam's series next, and see if conflicts with this, or those can be merged together. A lot of interesting stuff happening on this driver! Thanks j Jacopo Mondi (2): media: ov5640: Add check for PLL1 output max frequency media: ov5640: Re-implement MIPI clock configuration drivers/media/i2c/ov5640.c | 124 - 1 file changed, 99 insertions(+), 25 deletions(-) -- 2.7.4
Re: [PATCH v4 01/12] media: ov5640: Adjust the clock based on the expected rate
Hello Maxime,
a few comments I have collected while testing the series.
Please see below.
On Thu, Oct 11, 2018 at 11:20:56AM +0200, Maxime Ripard wrote:
> The clock structure for the PCLK is quite obscure in the documentation, and
> was hardcoded through the bytes array of each and every mode.
>
> This is troublesome, since we cannot adjust it at runtime based on other
> parameters (such as the number of bytes per pixel), and we can't support
> either framerates that have not been used by the various vendors, since we
> don't have the needed initialization sequence.
>
> We can however understand how the clock tree works, and then implement some
> functions to derive the various parameters from a given rate. And now that
> those parameters are calculated 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/i2c/ov5640.c | 289 -
> 1 file changed, 288 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 30b15e91d8be..88fb16341466 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -175,6 +175,7 @@ struct ov5640_mode_info {
> u32 htot;
> u32 vact;
> u32 vtot;
> + u32 pixel_clock;
> const struct reg_value *reg_data;
> u32 reg_data_size;
> };
> @@ -700,6 +701,7 @@ static const struct reg_value
> ov5640_setting_15fps_QSXGA_2592_1944[] = {
> /* power-on sensor init reg table */
> static const struct ov5640_mode_info ov5640_mode_init_data = {
> 0, SUBSAMPLING, 640, 1896, 480, 984,
> + 5600,
> ov5640_init_setting_30fps_VGA,
> ARRAY_SIZE(ov5640_init_setting_30fps_VGA),
> };
> @@ -709,74 +711,91 @@
> ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = {
> {
> {OV5640_MODE_QCIF_176_144, SUBSAMPLING,
>176, 1896, 144, 984,
> + 2800,
>ov5640_setting_15fps_QCIF_176_144,
>ARRAY_SIZE(ov5640_setting_15fps_QCIF_176_144)},
> {OV5640_MODE_QVGA_320_240, SUBSAMPLING,
>320, 1896, 240, 984,
> + 2800,
>ov5640_setting_15fps_QVGA_320_240,
>ARRAY_SIZE(ov5640_setting_15fps_QVGA_320_240)},
> {OV5640_MODE_VGA_640_480, SUBSAMPLING,
>640, 1896, 480, 1080,
> + 2800,
>ov5640_setting_15fps_VGA_640_480,
>ARRAY_SIZE(ov5640_setting_15fps_VGA_640_480)},
> {OV5640_MODE_NTSC_720_480, SUBSAMPLING,
>720, 1896, 480, 984,
> + 2800,
>ov5640_setting_15fps_NTSC_720_480,
>ARRAY_SIZE(ov5640_setting_15fps_NTSC_720_480)},
> {OV5640_MODE_PAL_720_576, SUBSAMPLING,
>720, 1896, 576, 984,
> + 2800,
>ov5640_setting_15fps_PAL_720_576,
>ARRAY_SIZE(ov5640_setting_15fps_PAL_720_576)},
> {OV5640_MODE_XGA_1024_768, SUBSAMPLING,
>1024, 1896, 768, 1080,
> + 2800,
>ov5640_setting_15fps_XGA_1024_768,
>ARRAY_SIZE(ov5640_setting_15fps_XGA_1024_768)},
> {OV5640_MODE_720P_1280_720, SUBSAMPLING,
>1280, 1892, 720, 740,
> + 2100,
>ov5640_setting_15fps_720P_1280_720,
>ARRAY_SIZE(ov5640_setting_15fps_720P_1280_720)},
> {OV5640_MODE_1080P_1920_1080, SCALING,
>1920, 2500, 1080, 1120,
> + 4200,
>ov5640_setting_15fps_1080P_1920_1080,
>ARRAY_SIZE(ov5640_setting_15fps_1080P_1920_1080)},
> {OV5640_MODE_QSXGA_2592_1944, SCALING,
>2592, 2844, 1944, 1968,
> + 8400,
>ov5640_setting_15fps_QSXGA_2592_1944,
>ARRAY_SIZE(ov5640_setting_15fps_QSXGA_2592_1944)},
> }, {
> {OV5640_MODE_QCIF_176_144, SUBSAMPLING,
>176, 1896, 144, 984,
> + 5600,
>ov5640_setting_30fps_QCIF_176_144,
>ARRAY_SIZE(ov5640_setting_30fps_QCIF_176_144)},
> {OV5640_MODE_QVGA_320_240, SUBSAMPLING,
>320, 1896, 240, 984,
> + 5600,
>ov5640_setting_30fps_QVGA_320_240,
>ARRAY_SIZE(ov5640_setting_30fps_QVGA_320_240)},
> {OV5640_MODE_VGA_640_480, SUBSAMPLING,
>640, 1896, 480, 1080,
> + 5600,
>ov5640_setting_30fps_VGA_640_480,
>ARRAY_SIZE(ov5640_setting_30fps_VGA_640_480)},
> {OV5640_MODE_NTSC_720_480, SUBSAMPLING,
>
Re: [PATCH v4 00/12] media: ov5640: Misc cleanup and improvements
Hello Maxime, On Thu, Oct 11, 2018 at 11:20:55AM +0200, Maxime Ripard wrote: > Hi, > > Here is a "small" series that mostly cleans up the ov5640 driver code, > slowly getting rid of the big data array for more understandable code > (hopefully). > > The biggest addition would be the clock rate computation at runtime, > instead of relying on those arrays to setup the clock tree > properly. As a side effect, it fixes the framerate that was off by > around 10% on the smaller resolutions, and we now support 60fps. > > This also introduces a bunch of new features. > > Let me know what you think, I'm sorry to report this breaks CSI-2 capture on my i.MX6 testing platform. I have been testing the whole afternoon with different configurations, but I have not been able yet to find out the root of the problem. In the meantime, I have some comments on the patches, and I'll reply to them singularly. Thanks j > Maxime > > Changes from v3: > - Rebased on current Sakari tree > - Fixed an error when changing only the framerate > > Changes from v2: > - Rebased on latest Sakari PR > - Fixed the issues reported by Hugues: improper FPS returned for > formats, improper rounding of the FPS, some with his suggestions, > some by simplifying the logic. > - Expanded the clock tree comments based on the feedback from Samuel > Bobrowicz and Loic Poulain > - Merged some of the changes made by Samuel Bobrowicz to fix the > MIPI rate computation, fix the call sites of the > ov5640_set_timings function, the auto-exposure calculation call, > etc. > - Split the patches into smaller ones in order to make it more > readable (hopefully) > > Changes 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 (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 at runtime > media: ov5640: Remove pixel clock rates > media: ov5640: Enhance FPS handling > media: ov5640: Make the return rate type more explicit > media: ov5640: Make the FPS clamping / rounding more extendable > media: ov5640: Add 60 fps support > media: ov5640: Remove duplicate auto-exposure setup > ov5640: Enforce a mode change when changing the framerate > > drivers/media/i2c/ov5640.c | 679 - > 1 file changed, 374 insertions(+), 305 deletions(-) > > -- > 2.19.1 > signature.asc Description: PGP signature
Re: [PATCH 1/4] media: ov5640: fix resolution update
Hi Hugues,
On Mon, Oct 15, 2018 at 03:13:12PM +, Hugues FRUCHET wrote:
> Hi Laurent, Jacopo, Sam,
>
> I'm also OK to change to a simpler alternative;
> - drop the "restore" step
Do you mean the restore step at the end of 'ov5640_restore_mode()' ?
I agree, I've been carrying this one [1] in my tree for some time now.
I just didn't send it because of the too many issues in flight on this
driver.
> - send the whole init register sequence + mode changes + format changes
> at streamon
>
This might be a first step in my opinion too, yes.
> is this what you have in mind Laurent ?
I know Laurent does not fully agree with me on this, but I would like
to have Maxime's series on clock tree handling merged and tested on
CSI-2 first before adding more patches to the pile of pending items on
ov5640. I hope to have time to test them on CSI-2 this week before
ELC-E.
Steve, you're the driver maintainer do you have preferences here?
Also, if this might be useful, I would like to help co-maintaining the
driver (with possibily other people, possibly with the sensor wired in
DVP mode), and help establishing priorities, as this driver needs some
love, but one item at the time to avoid getting lost in too many
pending changes as it happened recently :)
Thanks
j
[1]
media: ov5640: Do not restore format at power up
Do not force restoring the last applied capture format during sensor power
up
as it will be re-set at s_stream time.
Signed-off-by: Jacopo Mondi
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index b226946..17ee55b 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -1737,12 +1737,10 @@ static int ov5640_restore_mode(struct ov5640_dev
*sensor)
if (ret)
return ret;
- /* now restore the last capture mode */
- ret = ov5640_set_mode(sensor, _mode_init_data);
- if (ret < 0)
- return ret;
+ sensor->pending_mode_change = true;
+ sensor->pending_fmt_change = true;
- return ov5640_set_framefmt(sensor, >fmt);
+ return 0;
}
static void ov5640_power(struct ov5640_dev *sensor, bool enable)
>
> On 10/10/2018 02:41 PM, Laurent Pinchart wrote:
> > Hi Jacopo,
> >
> > On Wednesday, 10 October 2018 13:58:04 EEST jacopo mondi wrote:
> >> Hi Sam,
> >> thanks for the patch, I see the same issue you reported, but I
> >> think this patch can be improved.
> >>
> >> (expanding the Cc list to all people involved in recent ov5640
> >> developemts, not just for this patch, but for the whole series to look
> >> at. Copying names from another series cover letter, hope it is
> >> complete.)
> >>
> >> On Mon, Oct 08, 2018 at 11:47:59PM -0700, Sam Bobrowicz wrote:
> >>> set_fmt was not properly triggering a mode change when
> >>> a new mode was set that happened to have the same format
> >>> as the previous mode (for example, when only changing the
> >>> frame dimensions). Fix this.
> >>>
> >>> Signed-off-by: Sam Bobrowicz
> >>> ---
> >>>
> >>> drivers/media/i2c/ov5640.c | 8
> >>> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> >>> index eaefdb5..5031aab 100644
> >>> --- a/drivers/media/i2c/ov5640.c
> >>> +++ b/drivers/media/i2c/ov5640.c
> >>> @@ -2045,12 +2045,12 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
> >>>
> >>> goto out;
> >>>
> >>> }
> >>>
> >>> - if (new_mode != sensor->current_mode) {
> >>> +
> >>> + if (new_mode != sensor->current_mode ||
> >>> + mbus_fmt->code != sensor->fmt.code) {
> >>> + sensor->fmt = *mbus_fmt;
> >>>
> >>> sensor->current_mode = new_mode;
> >>> sensor->pending_mode_change = true;
> >>>
> >>> - }
> >>> - if (mbus_fmt->code != sensor->fmt.code) {
> >>> - sensor->fmt = *mbus_fmt;
> >>>
> >>> sensor->pending_fmt_change = true;
> >>>
> >>> }
> >>
> >> How I did reproduce the issue:
> >>
> >> # Set 1024x768 on ov5640 without changing the image format
> >> # (default image size at startup is 640x480)
> >> $ media-ctl --set-v4l2 "'ov5640 2-003c':0[fmt:UYVY2X8/1024x768 field:none]"
> >>sensor->pending_mode_change = true; //verified this fl
Re: [PATCH 1/4] media: ov5640: fix resolution update
Hi Sam,
thanks for the patch, I see the same issue you reported, but I
think this patch can be improved.
(expanding the Cc list to all people involved in recent ov5640
developemts, not just for this patch, but for the whole series to look
at. Copying names from another series cover letter, hope it is
complete.)
On Mon, Oct 08, 2018 at 11:47:59PM -0700, Sam Bobrowicz wrote:
> set_fmt was not properly triggering a mode change when
> a new mode was set that happened to have the same format
> as the previous mode (for example, when only changing the
> frame dimensions). Fix this.
>
> Signed-off-by: Sam Bobrowicz
> ---
> drivers/media/i2c/ov5640.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index eaefdb5..5031aab 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -2045,12 +2045,12 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
> goto out;
> }
>
> - if (new_mode != sensor->current_mode) {
> +
> + if (new_mode != sensor->current_mode ||
> + mbus_fmt->code != sensor->fmt.code) {
> + sensor->fmt = *mbus_fmt;
> sensor->current_mode = new_mode;
> sensor->pending_mode_change = true;
> - }
> - if (mbus_fmt->code != sensor->fmt.code) {
> - sensor->fmt = *mbus_fmt;
> sensor->pending_fmt_change = true;
> }
How I did reproduce the issue:
# Set 1024x768 on ov5640 without changing the image format
# (default image size at startup is 640x480)
$ media-ctl --set-v4l2 "'ov5640 2-003c':0[fmt:UYVY2X8/1024x768 field:none]"
sensor->pending_mode_change = true; //verified this flag gets set
# Start streaming, after having configured the whole pipeline to work
# with 1024x768
$ yavta -c10 -n4 -f UYVY -s 1024x768 /dev/video4
Unable to start streaming: Broken pipe (32).
# Inspect which part of pipeline validation went wrong
# Turns out the sensor->fmt field is not updated, and when get_fmt()
# is called, the old one is returned.
$ media-ctl -e "ov5640 2-003c" -p
...
[fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb ycbcr:601
quantization:full-range]
^^^ ^^^
So yes, sensor->fmt is not udapted as it should be when only image
resolution is changed.
Although I still see value in having two separate flags for the
'mode_change' (which in ov5640 lingo is resolution) and 'fmt_change' (which
in ov5640 lingo is the image format), and write their configuration to
registers only when they get actually changed.
For this reasons I would like to propse the following patch which I
have tested by:
1) changing resolution only
2) changing format only
3) change both
What do you and others think?
Thanks
j
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index eaefdb5..e392b9d 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2020,6 +2020,7 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
struct ov5640_dev *sensor = to_ov5640_dev(sd);
const struct ov5640_mode_info *new_mode;
struct v4l2_mbus_framefmt *mbus_fmt = >format;
+ struct v4l2_mbus_framefmt *fmt;
int ret;
if (format->pad != 0)
@@ -2037,22 +2038,19 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
if (ret)
goto out;
- if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
- struct v4l2_mbus_framefmt *fmt =
- v4l2_subdev_get_try_format(sd, cfg, 0);
+ if (format->which == V4L2_SUBDEV_FORMAT_TRY)
+ fmt = v4l2_subdev_get_try_format(sd, cfg, 0);
+ else
+ fmt = >fmt;
- *fmt = *mbus_fmt;
- goto out;
- }
+ *fmt = *mbus_fmt;
if (new_mode != sensor->current_mode) {
sensor->current_mode = new_mode;
sensor->pending_mode_change = true;
}
- if (mbus_fmt->code != sensor->fmt.code) {
- sensor->fmt = *mbus_fmt;
+ if (mbus_fmt->code != sensor->fmt.code)
sensor->pending_fmt_change = true;
- }
out:
mutex_unlock(>lock);
return ret;
> out:
> --
> 2.7.4
>
signature.asc
Description: PGP signature
Re: [PATCH 2/4] media: ov5640: fix get_light_freq on auto
Hi Sam,
On Mon, Oct 08, 2018 at 11:48:00PM -0700, Sam Bobrowicz wrote:
> Light frequency was not properly returned when in auto
> mode and the detected frequency was 60Hz. Fix this.
>
> Signed-off-by: Sam Bobrowicz
This is indeed a bugfix
Acked-by: Jacopo Mondi
Thanks
j
> ---
> drivers/media/i2c/ov5640.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 5031aab..f183222 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -1295,6 +1295,7 @@ static int ov5640_get_light_freq(struct ov5640_dev
> *sensor)
> light_freq = 50;
> } else {
> /* 60Hz */
> + light_freq = 60;
> }
> }
>
> --
> 2.7.4
>
signature.asc
Description: PGP signature
Re: [PATCH 3/4] media: ov5640: Don't access ctrl regs when off
Hi Sam,
thanks for the patch.
On Mon, Oct 08, 2018 at 11:48:01PM -0700, Sam Bobrowicz wrote:
> Add a check to g_volatile_ctrl to prevent trying to read
> registers when the sensor is not powered.
>
> Signed-off-by: Sam Bobrowicz
I've been carrying a similar patch in my tree. I found it is required
when the sensor control handler is add to the receiver driver control
handler, and thus g_voltaile_ctrl can be called when the sensor is
powered off.
Please add my:
Acked-by: Jacopo Mondi
Thanks
j
> ---
> drivers/media/i2c/ov5640.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index f183222..a50d884 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -2336,6 +2336,13 @@ static int ov5640_g_volatile_ctrl(struct v4l2_ctrl
> *ctrl)
>
> /* v4l2_ctrl_lock() locks our own mutex */
>
> + /*
> + * If the sensor is not powered up by the host driver, do
> + * not try to access it to update the volatile controls.
> + */
> + if (sensor->power_count == 0)
> + return 0;
> +
> switch (ctrl->id) {
> case V4L2_CID_AUTOGAIN:
> val = ov5640_get_gain(sensor);
> --
> 2.7.4
>
signature.asc
Description: PGP signature
Re: [PATCH 1/1] v4l: Remove support for crop default target in subdev drivers
Hi Helmut, On Tue, Sep 25, 2018 at 08:33:29AM +0200, Helmut Grohne wrote: > On Mon, Sep 24, 2018 at 04:42:27PM +0200, Sakari Ailus wrote: > > --- a/drivers/media/i2c/mt9t112.c > > +++ b/drivers/media/i2c/mt9t112.c > > @@ -888,12 +888,6 @@ static int mt9t112_get_selection(struct v4l2_subdev > > *sd, > > sel->r.width = MAX_WIDTH; > > sel->r.height = MAX_HEIGHT; > > return 0; > > - case V4L2_SEL_TGT_CROP_DEFAULT: > > - sel->r.left = 0; > > - sel->r.top = 0; > > - sel->r.width = VGA_WIDTH; > > - sel->r.height = VGA_HEIGHT; > > - return 0; > > case V4L2_SEL_TGT_CROP: > > sel->r = priv->frame; > > return 0; > > Together with the change in soc_scale_crop.c, this constitutes an > (unintentional?) behaviour change. It was formerly reporting 640x480 and > will now be reporting 2048x1536. I cannot tell whether that is > reasonable. > > > --- a/drivers/media/i2c/soc_camera/mt9t112.c > > +++ b/drivers/media/i2c/soc_camera/mt9t112.c > > @@ -884,12 +884,6 @@ static int mt9t112_get_selection(struct v4l2_subdev > > *sd, > > sel->r.width = MAX_WIDTH; > > sel->r.height = MAX_HEIGHT; > > return 0; > > - case V4L2_SEL_TGT_CROP_DEFAULT: > > - sel->r.left = 0; > > - sel->r.top = 0; > > - sel->r.width = VGA_WIDTH; > > - sel->r.height = VGA_HEIGHT; > > - return 0; > > case V4L2_SEL_TGT_CROP: > > sel->r = priv->frame; > > return 0; > > This one looks duplicate. Is there a good reason to have two drivers for > mt9t112? This is lilely out of scope for the patch. Cced Jacopo Mondi as > he introduced the copy. > This version is the one using te soc_camera framework which is targeted for deprecation. The soc_camera based sensor drivers are being ported to be regular v4l2 sensor drivers, hence the copy in drivers/media/i2c/. The original versions in drivers/media/i2c/soc_camera will be around for a little longer and then possibly moved to staging or later removed. Hope this clarifies. Thanks j > Other than your patch looks fine to me. > > Helmut signature.asc Description: PGP signature
Re: [PATCH v3 0/5] Fix OV5640 exposure & gain
Hi Sakari, thanks for handling this On Sun, Sep 16, 2018 at 02:02:30AM +0300, Sakari Ailus wrote: > Hi Jacopo, Hugues, > > On Fri, Sep 14, 2018 at 06:07:12PM +0200, jacopo mondi wrote: > > Hi Sakari, > > > > On Tue, Sep 11, 2018 at 03:48:16PM +0200, Hugues Fruchet wrote: > > > This patch serie fixes some problems around exposure & gain in OV5640 > > > driver. > > > > As you offered to collect this series and my CSI-2 fixes I have just > > re-sent, you might be interested in this branch: > > > > git://jmondi.org/linux > > engicam-imx6q/media-master/ov5640/csi2_init_v4_exposure_v3 > > > > I have there re-based this series on top of mine, which is in turn > > based on latest media master, where this series do not apply as-is > > afaict. > > > > I have added to Hugues' patches my reviewed-by and tested-by tags. > > If you prefer to I can send you a pull request, or if you want to have > > a chance to review the whole patch list please refer to the above > > branch. > > > > Let me know if I can help speeding up the inclusion of these two > > series as they fix two real issues of MIPI CSI-2 capture operations > > for this sensor. > > I've pushed the patches here: > > https://git.linuxtv.org/sailus/media_tree.git/log/?h=for-4.20-5> > > There was a merge commit and a few extra patches in your tree; I threw them > out. :-) Yeah, those are a few patches I need for my testing platform... Forgot to remove them, hope you didn't spend too much time on this. > > I also edited the commit messages slightly (format; no change in content) > --- the patches are as-is. I'll still check they look right before sending > a pull request, likely on Monday. Thanks, let me now if I can help. Cheers j > > -- > Regards, > > Sakari Ailus > sakari.ai...@linux.intel.com signature.asc Description: PGP signature
Re: [PATCH v3 0/5] Fix OV5640 exposure & gain
Hi Sakari, On Tue, Sep 11, 2018 at 03:48:16PM +0200, Hugues Fruchet wrote: > This patch serie fixes some problems around exposure & gain in OV5640 driver. As you offered to collect this series and my CSI-2 fixes I have just re-sent, you might be interested in this branch: git://jmondi.org/linux engicam-imx6q/media-master/ov5640/csi2_init_v4_exposure_v3 I have there re-based this series on top of mine, which is in turn based on latest media master, where this series do not apply as-is afaict. I have added to Hugues' patches my reviewed-by and tested-by tags. If you prefer to I can send you a pull request, or if you want to have a chance to review the whole patch list please refer to the above branch. Let me know if I can help speeding up the inclusion of these two series as they fix two real issues of MIPI CSI-2 capture operations for this sensor. Thanks j > > The 4th patch about autocontrols requires also a fix in v4l2-ctrls.c: > https://www.mail-archive.com/linux-media@vger.kernel.org/msg133164.html > > Here is the test procedure used for exposure & gain controls check: > 1) Preview in background > $> gst-launch-1.0 v4l2src ! "video/x-raw, width=640, Height=480" ! queue ! > waylandsink -e & > 2) Check gain & exposure values > $> v4l2-ctl --all | grep -e exposure -e gain | grep "(int)" >exposure (int): min=0 max=65535 step=1 default=0 > value=330 flags=inactive, volatile >gain (int): min=0 max=1023 step=1 default=0 > value=19 flags=inactive, volatile > 3) Put finger in front of camera and check that gain/exposure values are > changing: > $> v4l2-ctl --all | grep -e exposure -e gain | grep "(int)" >exposure (int): min=0 max=65535 step=1 default=0 > value=660 flags=inactive, volatile >gain (int): min=0 max=1023 step=1 default=0 > value=37 flags=inactive, volatile > 4) switch to manual mode, image exposition must not change > $> v4l2-ctl --set-ctrl=gain_automatic=0 > $> v4l2-ctl --set-ctrl=auto_exposure=1 > Note the "1" for manual exposure. > > 5) Check current gain/exposure values: > $> v4l2-ctl --all | grep -e exposure -e gain | grep "(int)" >exposure (int): min=0 max=65535 step=1 default=0 > value=330 >gain (int): min=0 max=1023 step=1 default=0 > value=20 > > 6) Put finger behind camera and check that gain/exposure values are NOT > changing: > $> v4l2-ctl --all | grep -e exposure -e gain | grep "(int)" >exposure (int): min=0 max=65535 step=1 default=0 > value=330 >gain (int): min=0 max=1023 step=1 default=0 > value=20 > 7) Update exposure, check that it is well changed on display and that same > value is returned: > $> v4l2-ctl --set-ctrl=exposure=100 > $> v4l2-ctl --get-ctrl=exposure > exposure: 100 > > 9) Update gain, check that it is well changed on display and that same value > is returned: > $> v4l2-ctl --set-ctrl=gain=10 > $> v4l2-ctl --get-ctrl=gain > gain: 10 > > 10) Switch back to auto gain/exposure, verify that image is correct and > values returned are correct: > $> v4l2-ctl --set-ctrl=gain_automatic=1 > $> v4l2-ctl --set-ctrl=auto_exposure=0 > $> v4l2-ctl --all | grep -e exposure -e gain | grep "(int)" >exposure (int): min=0 max=65535 step=1 default=0 > value=330 flags=inactive, volatile >gain (int): min=0 max=1023 step=1 default=0 > value=22 flags=inactive, volatile > Note the "0" for auto exposure. > > === > = history = > === > version 3: > - Change patch 5/5 by removing set_mode() orig_mode parameter as per > jacopo' suggestion: > https://www.spinics.net/lists/linux-media/msg139457.html > > version 2: > - Fix patch 3/5 commit comment and rename binning function as per jacopo' > suggestion: > https://www.mail-archive.com/linux-media@vger.kernel.org/msg133272.html > > Hugues Fruchet (5): > media: ov5640: fix exposure regression > media: ov5640: fix auto gain & exposure when changing mode > media: ov5640: fix wrong binning value in exposure calculation > media: ov5640: fix auto controls values when switching to manual mode > media: ov5640: fix restore of last mode set > > drivers/media/i2c/ov5640.c | 128 > ++--- > 1 file changed, 73 insertions(+), 55 deletions(-) > > -- > 2.7.4 > signature.asc Description: PGP signature
Re: [PATCH v3 0/5] Fix OV5640 exposure & gain
Hi Hugues, thanks for the patches On Tue, Sep 11, 2018 at 03:48:16PM +0200, Hugues Fruchet wrote: > This patch serie fixes some problems around exposure & gain in OV5640 driver. > > The 4th patch about autocontrols requires also a fix in v4l2-ctrls.c: > https://www.mail-archive.com/linux-media@vger.kernel.org/msg133164.html > > Here is the test procedure used for exposure & gain controls check: > 1) Preview in background > $> gst-launch-1.0 v4l2src ! "video/x-raw, width=640, Height=480" ! queue ! > waylandsink -e & > 2) Check gain & exposure values > $> v4l2-ctl --all | grep -e exposure -e gain | grep "(int)" >exposure (int): min=0 max=65535 step=1 default=0 > value=330 flags=inactive, volatile >gain (int): min=0 max=1023 step=1 default=0 > value=19 flags=inactive, volatile > 3) Put finger in front of camera and check that gain/exposure values are > changing: > $> v4l2-ctl --all | grep -e exposure -e gain | grep "(int)" >exposure (int): min=0 max=65535 step=1 default=0 > value=660 flags=inactive, volatile >gain (int): min=0 max=1023 step=1 default=0 > value=37 flags=inactive, volatile > 4) switch to manual mode, image exposition must not change > $> v4l2-ctl --set-ctrl=gain_automatic=0 > $> v4l2-ctl --set-ctrl=auto_exposure=1 > Note the "1" for manual exposure. > > 5) Check current gain/exposure values: > $> v4l2-ctl --all | grep -e exposure -e gain | grep "(int)" >exposure (int): min=0 max=65535 step=1 default=0 > value=330 >gain (int): min=0 max=1023 step=1 default=0 > value=20 > > 6) Put finger behind camera and check that gain/exposure values are NOT > changing: > $> v4l2-ctl --all | grep -e exposure -e gain | grep "(int)" >exposure (int): min=0 max=65535 step=1 default=0 > value=330 >gain (int): min=0 max=1023 step=1 default=0 > value=20 > 7) Update exposure, check that it is well changed on display and that same > value is returned: > $> v4l2-ctl --set-ctrl=exposure=100 > $> v4l2-ctl --get-ctrl=exposure > exposure: 100 > > 9) Update gain, check that it is well changed on display and that same value > is returned: > $> v4l2-ctl --set-ctrl=gain=10 > $> v4l2-ctl --get-ctrl=gain > gain: 10 > > 10) Switch back to auto gain/exposure, verify that image is correct and > values returned are correct: > $> v4l2-ctl --set-ctrl=gain_automatic=1 > $> v4l2-ctl --set-ctrl=auto_exposure=0 > $> v4l2-ctl --all | grep -e exposure -e gain | grep "(int)" >exposure (int): min=0 max=65535 step=1 default=0 > value=330 flags=inactive, volatile >gain (int): min=0 max=1023 step=1 default=0 > value=22 flags=inactive, volatile > Note the "0" for auto exposure. > I've tested on my side and I can confirm the exposure and gain when in auto-mode changes as expected, and it is possible to switch back and forth between auto and manual modes. The patches also fixes an issue when capturing frames, as the first two/three frames where always black in my setup before this series. (While streaming to gstreamers' fakesink) # v4l2-ctl --get-ctrl "exposure" --get-ctrl "gain" -d /dev/video4 exposure: 885 gain: 50 (Point a light in front of the sensor) # v4l2-ctl --get-ctrl "exposure" --get-ctrl "gain" -d /dev/video4 exposure: 17 gain: 19 (Disable auto-gain and auto-exposure) # v4l2-ctl -d /dev/video4 --set-ctrl=auto_exposure=1 # v4l2-ctl -d /dev/video4 --set-ctrl=gain_automatic=0 # v4l2-ctl -d /dev/video4 --set-ctrl=exposure=100 # v4l2-ctl --get-ctrl "exposure" --get-ctrl "gain" -d /dev/video4 exposure: 100 gain: 46 (Re-enable auto-exp and auto-gain) # v4l2-ctl -d /dev/video4 --set-ctrl=auto_exposure=0 # v4l2-ctl -d /dev/video4 --set-ctrl=gain_automatic=1 # v4l2-ctl --get-ctrl "exposure" --get-ctrl "gain" -d /dev/video4 exposure: 885 gain: 46 (Finger on the sensor) # v4l2-ctl --get-ctrl "exposure" --get-ctrl "gain" -d /dev/video4 exposure: 885 gain: 248 (Point a light on the sensor) exposure: 16 gain: 19 So please add my Tested-by: Jacopo Mondi to this series. Thanks j > === > = history = > === > version 3: > - Change patch 5/5 by removing set_mode() orig_mode parameter as per > jacopo' suggestion: > https://www.spinics.net/lists/linux-media/msg139457.html > > version 2: > - Fix patch 3/5 commit comment and rename binning functio
[PATCH v4 0/2] media: i2c: ov5640: Re-work MIPI startup sequence
Hello ov5640 people, this driver has received a lot of attention recently, and this series aims to fix the CSI-2 interface startup on i.Mx6Q platforms. Please refer to the v2 cover letters for more background informations: https://www.mail-archive.com/linux-media@vger.kernel.org/msg133420.html This two patches alone allows the MIPI interface to startup properly, but in order to capture good images (good as in 'not completely black') exposure and gain handling should be fixed too. Hugues Fruchet has a series in review that fixes that issues: [PATCH v3 0/5] Fix OV5640 exposure & gain I have re-based Hugues' one this two patches and the latest media-tree master at git://jmondi.org/linux engicam-imx6q/media-master/ov5640/csi2_init_v4_exposure_v3 For the interested to test. Compared to previous version, the series has been tested by Loic on Dragonboard-410c and he helped finding out a discrepancy between the (working) implementation and the sensor manual I have now add a comment on. Testing so far has been done with only 2 data lanes, anyone with a 1-data lane setup willing to test would be great. Thanks j v3 -> v4: - Add Loic's tested by tag - Add comment on register 0x300e[7:5] discrepancy between implementation and sensor manual (thanks Loic) v2 -> v3: - patch [2/2] was originally sent in a different series, compared to v2 it removes entries from the blob array instead of adding more. Jacopo Mondi (2): media: ov5640: Re-work MIPI startup sequence media: ov5640: Fix timings setup code drivers/media/i2c/ov5640.c | 149 ++--- 1 file changed, 100 insertions(+), 49 deletions(-) -- 2.7.4
[PATCH v4 2/2] media: ov5640: Fix timings setup code
From: Jacopo Mondi
As of:
commit 476dec012f4c ("media: ov5640: Add horizontal and vertical totals")
the timings parameters gets programmed separately from the static register
values array.
When changing capture mode, the vertical and horizontal totals gets inspected
by the set_mode_exposure_calc() functions, and only later programmed with the
new values. This means exposure, light banding filter and shutter gain are
calculated using the previous timings, and are thus not correct.
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")
Tested-by: Steve Longerbeam
on i.MX6q SabreSD with MIPI CSI-2 OV5640 module
Tested-by: Loic Poulain
on Dragonboard-410c with MIPI CSI-2 OV5640 module
Signed-off-by: Samuel Bobrowicz
Signed-off-by: Maxime Ripard
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/ov5640.c | 50 +++---
1 file changed, 21 insertions(+), 29 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 7ade416..2b9e84f 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -908,6 +908,26 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, u16
reg,
}
/* download ov5640 settings to sensor through i2c */
+static int ov5640_set_timings(struct ov5640_dev *sensor,
+ const struct ov5640_mode_info *mode)
+{
+ int ret;
+
+ ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_DVPHO, mode->hact);
+ if (ret < 0)
+ return ret;
+
+ ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_DVPVO, mode->vact);
+ if (ret < 0)
+ return ret;
+
+ ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_HTS, mode->htot);
+ if (ret < 0)
+ return ret;
+
+ return ov5640_write_reg16(sensor, OV5640_REG_TIMING_VTS, mode->vtot);
+}
+
static int ov5640_load_regs(struct ov5640_dev *sensor,
const struct ov5640_mode_info *mode)
{
@@ -935,7 +955,7 @@ static int ov5640_load_regs(struct ov5640_dev *sensor,
usleep_range(1000 * delay_ms, 1000 * delay_ms + 100);
}
- return ret;
+ return ov5640_set_timings(sensor, mode);
}
/* read exposure, in number of line periods */
@@ -1398,30 +1418,6 @@ static int ov5640_set_virtual_channel(struct ov5640_dev
*sensor)
return ov5640_write_reg(sensor, OV5640_REG_DEBUG_MODE, temp);
}
-static int ov5640_set_timings(struct ov5640_dev *sensor,
- const struct ov5640_mode_info *mode)
-{
- int ret;
-
- ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_DVPHO, mode->hact);
- if (ret < 0)
- return ret;
-
- ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_DVPVO, mode->vact);
- if (ret < 0)
- return ret;
-
- ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_HTS, mode->htot);
- if (ret < 0)
- return ret;
-
- ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_VTS, mode->vtot);
- if (ret < 0)
- return ret;
-
- return 0;
-}
-
static const struct ov5640_mode_info *
ov5640_find_mode(struct ov5640_dev *sensor, enum ov5640_frame_rate fr,
int width, int height, bool nearest)
@@ -1665,10 +1661,6 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
if (ret < 0)
return ret;
- ret = ov5640_set_timings(sensor, mode);
- if (ret < 0)
- return ret;
-
ret = ov5640_set_binning(sensor, dn_mode != SCALING);
if (ret < 0)
return ret;
--
2.7.4
[PATCH v4 1/2] media: ov5640: Re-work MIPI startup sequence
From: Jacopo Mondi
Rework the MIPI interface startup sequence with the following changes:
- Remove MIPI bus initialization from the initial settings blob
- At set_power(1) time power up MIPI Tx/Rx and set data and clock lanes in
LP11 during 'sleep' and 'idle' with MIPI clock in non-continuous mode.
- At s_stream time enable/disable the MIPI interface output.
- Restore default settings at set_power(0) time.
Before this commit the sensor MIPI interface was initialized with settings
that require a start/stop sequence at power-up time in order to force lanes
into LP11 state, as they were initialized in LP00 when in 'sleep mode',
which is assumed to be the sensor manual definition for the D-PHY defined
stop mode.
The stream start/stop was performed by enabling disabling clock gating,
and had the side effect to change the lanes sleep mode configuration when
stream was stopped.
Clock gating/ungating:
- ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
-on ? 0 : BIT(5));
- if (ret)
Set lanes in LP11 when in 'sleep mode':
- ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
- on ? 0x00 : 0x70);
This commit fixes an issue reported by Jagan Teki on i.MX6 platforms that
prevents the host interface from powering up correctly:
https://lkml.org/lkml/2018/6/1/38
It also improves MIPI capture operations stability on my testing platform
where MIPI capture often failed and returned all-purple frames.
fixes: f22996db44e2 ("media: ov5640: add support of DVP parallel interface")
Tested-by: Steve Longerbeam
on i.MX6q SabreSD with MIPI CSI-2 OV5640 module
Tested-by: Loic Poulain
on Dragonboard-410c with MIPI CSI-2 OV5640 module
Reported-by: Jagan Teki
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/ov5640.c | 99 --
1 file changed, 79 insertions(+), 20 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 071f4bc..7ade416 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -286,10 +286,10 @@ static const struct reg_value
ov5640_init_setting_30fps_VGA[] = {
{0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
{0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x3000, 0x00, 0, 0},
{0x3002, 0x1c, 0, 0}, {0x3004, 0xff, 0, 0}, {0x3006, 0xc3, 0, 0},
- {0x300e, 0x45, 0, 0}, {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
+ {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
{0x501f, 0x00, 0, 0}, {0x4713, 0x03, 0, 0}, {0x4407, 0x04, 0, 0},
{0x440e, 0x00, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
- {0x4837, 0x0a, 0, 0}, {0x4800, 0x04, 0, 0}, {0x3824, 0x02, 0, 0},
+ {0x4837, 0x0a, 0, 0}, {0x3824, 0x02, 0, 0},
{0x5000, 0xa7, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x5180, 0xff, 0, 0},
{0x5181, 0xf2, 0, 0}, {0x5182, 0x00, 0, 0}, {0x5183, 0x14, 0, 0},
{0x5184, 0x25, 0, 0}, {0x5185, 0x24, 0, 0}, {0x5186, 0x09, 0, 0},
@@ -1102,12 +1102,25 @@ static int ov5640_set_stream_mipi(struct ov5640_dev
*sensor, bool on)
{
int ret;
- ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
-on ? 0 : BIT(5));
- if (ret)
- return ret;
- ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
- on ? 0x00 : 0x70);
+ /*
+* Enable/disable the MIPI interface
+*
+* 0x300e = on ? 0x45 : 0x40
+*
+* FIXME: the sensor manual (version 2.03) reports
+* [7:5] = 000 : 1 data lane mode
+* [7:5] = 001 : 2 data lanes mode
+* But this settings do not work, while the following ones
+* have been validated for 2 data lanes mode.
+*
+* [7:5] = 010 : 2 data lanes mode
+* [4] = 0 : Power up MIPI HS Tx
+* [3] = 0 : Power up MIPI LS Rx
+* [2] = 1/0: MIPI interface enable/disable
+* [1:0] = 01/00: FIXME: 'debug'
+*/
+ ret = ov5640_write_reg(sensor, OV5640_REG_IO_MIPI_CTRL00,
+ on ? 0x45 : 0x40);
if (ret)
return ret;
@@ -1786,23 +1799,69 @@ static int ov5640_set_power(struct ov5640_dev *sensor,
bool on)
if (ret)
goto power_off;
+ /* We're done here for DVP bus, while CSI-2 needs setup. */
+ if (sensor->ep.bus_type != V4L2_MBUS_CSI2)
+ return 0;
+
+ /*
+* Power up MIPI HS Tx and LS Rx; 2 data lanes mode
+*
+* 0x300e = 0x40
+* [7:5] = 010 : 2 data lanes mode (see FIXME note in
+*"ov5640_set_stream_mipi()")
+* [4] = 0 : Power up MIPI HS Tx
+* [3] = 0 : Power up MIPI LS Rx
+* [2] = 0 :
Re: [PATCH v3 1/2] media: ov5640: Re-work MIPI startup sequence
Hello Loic,
On Thu, Sep 06, 2018 at 10:13:53AM +0200, Loic Poulain wrote:
> On 6 September 2018 at 09:48, jacopo mondi wrote:
> > Hello Loic,
> >thanks for looking into this
> >
> > On Tue, Sep 04, 2018 at 07:22:50PM +0200, Loic Poulain wrote:
> >> Hi Jacopo,
> >>
> >> > - ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
> >> > -on ? 0 : BIT(5));
> >> > - if (ret)
> >> > - return ret;
> >> > - ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
> >> > - on ? 0x00 : 0x70);
> >> > + /*
> >> > +* Enable/disable the MIPI interface
> >> > +*
> >> > +* 0x300e = on ? 0x45 : 0x40
> >> > +* [7:5] = 001 : 2 data lanes mode
> >>
> >> Does 2-Lanes work with this config?
> >> AFAIU, if 2-Lanes is bit 5, value should be 0x25 and 0x20.
> >>
> >
> > Yes, confusing.
> >
> > The sensor manual reports
> > 0x300e[7:5] = 000 one lane mode
> > 0x300e[7:5] = 001 two lanes mode
> >
> > Although this configuration works with 2 lanes, and the application
> > note I have, with the suggested settings for MIPI CSI-2 2 lanes
> > reports 0x40 to be the 2 lanes mode...
> >
> > I used that one, also because the removed entry from the settings blob
> > is:
> > - {0x300e, 0x45, 0, 0}, {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
> > + {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
> >
> > So it was using BIT(6) already.
>
> Yes, it was setting BIT(6) from static config and BIT(5) from the
> ov5640_set_stream_mipi function. In your patch you don't set
> BIT(5) anymore.
I've resumed looking into this series.
Just FYI, the snippet you refer to is:
- ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
-on ? 0 : BIT(5));
- if (ret)
- return ret;
- ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
- on ? 0x00 : 0x70);
+ /*
+* Enable/disable the MIPI interface
+*
+* 0x300e = on ? 0x45 : 0x40
+* [7:5] = 001 : 2 data lanes mode
+* [4] = 0 : Power up MIPI HS Tx
+* [3] = 0 : Power up MIPI LS Rx
+* [2] = 1/0: MIPI interface enable/disable
+* [1:0] = 01/00: FIXME: 'debug'
+*/
+ ret = ov5640_write_reg(sensor, OV5640_REG_IO_MIPI_CTRL00,
+ on ? 0x45 : 0x40)
As you can see (it took me a while) the old code was indeed setting
BIT(5) as you mentioned, but on OV5640_REG_MIPI_CTRL00 (0x4800) and
not on OV5640_REG_IO_MIPI_CTRL00 (0x300e) as mine does. So the lane
configuration mode was set to 0x45 and never changed later.
>
> So it's not clear to me why it is still working, and the datasheet does
> not help a lot on this (BIT(6) is for debug modes).
> FYI I tried with BIT(5) only but it does not work (though I did not
> investigate a lot).
I'll keep BIT(6) set, point out the discrepancy with the datasheet,
and point out it has been tested with 2 lanes, until someone can
confirm it works with 1 lane too.
Thanks
j
>
> > Anyway, it works for me with 2 lanes (and I assume Steve), you have tested
> > too, with how many lanes are you working with?
> >
> > Anyway, a comment there might be nice to have... Will add in next
> > version
>
> Definitely.
>
> Regards,
> Loic
signature.asc
Description: PGP signature
Re: [PATCH v2 18/23] v4l: fwnode: Use media bus type for bus parser selection
Hi Sakari,
On Mon, Aug 27, 2018 at 12:29:55PM +0300, Sakari Ailus wrote:
> Use the media bus types instead of the fwnode bus types internally. This
> is the interface to the drivers as well, making the use of the fwnode bus
> types more localised to the V4L2 fwnode framework.
>
So basically now "v4l2_fwnode_bus_type" it is only used in a few
places in v4l2-fwnode and has to be kept in sync with the bus types
listed in the devicetree bindings documentation?
Do you think it is still worth to keep around functions dealing with
that enum type as "v4l2_fwnode_bus_type_to_string()" ?
It is only used by a debug printout (without that much value added, as
we can print out the integer parsed from the DT). In all other cases
it can be converted to the corresponing v4l2_mbus_type immediately.
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/v4l2-core/v4l2-fwnode.c | 100
> +++---
> 1 file changed, 80 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c
> b/drivers/media/v4l2-core/v4l2-fwnode.c
> index 6c5a76442667..d502abd7406b 100644
> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> @@ -42,9 +42,66 @@ enum v4l2_fwnode_bus_type {
> NR_OF_V4L2_FWNODE_BUS_TYPE,
> };
>
> +static const struct v4l2_fwnode_bus_conv {
> + enum v4l2_fwnode_bus_type fwnode_bus_type;
> + enum v4l2_mbus_type mbus_type;
> + const char *name;
> +} busses[] = {
> + {
> + V4L2_FWNODE_BUS_TYPE_GUESS,
> + V4L2_MBUS_UNKNOWN,
> + "not specified",
> + }, {
> + V4L2_FWNODE_BUS_TYPE_CSI2_CPHY,
> + V4L2_MBUS_CSI2_CPHY,
> + "MIPI CSI-2 C-PHY",
> + }, {
> + V4L2_FWNODE_BUS_TYPE_CSI1,
> + V4L2_MBUS_CSI1,
> + "MIPI CSI-1",
> + }, {
> + V4L2_FWNODE_BUS_TYPE_CCP2,
> + V4L2_MBUS_CCP2,
> + "compact camera port 2",
> + }, {
> + V4L2_FWNODE_BUS_TYPE_CSI2_DPHY,
> + V4L2_MBUS_CSI2_DPHY,
> + "MIPI CSI-2 D-PHY",
> + }, {
> + V4L2_FWNODE_BUS_TYPE_PARALLEL,
> + V4L2_MBUS_PARALLEL,
> + "parallel",
> + }, {
> + V4L2_FWNODE_BUS_TYPE_BT656,
> + V4L2_MBUS_BT656,
> + "Bt.656",
> + }
> +};
> +
> +static const struct v4l2_fwnode_bus_conv *
> +get_v4l2_fwnode_bus_conv_by_fwnode_bus(enum v4l2_fwnode_bus_type type)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(busses); i++)
> + if (busses[i].fwnode_bus_type == type)
> + return [i];
> +
> + return NULL;
> +}
> +
> +static enum v4l2_mbus_type
> +v4l2_fwnode_bus_type_to_mbus(enum v4l2_fwnode_bus_type type)
> +{
> + const struct v4l2_fwnode_bus_conv *conv =
> + get_v4l2_fwnode_bus_conv_by_fwnode_bus(type);
> +
> + return conv ? conv->mbus_type : V4L2_MBUS_UNKNOWN;
> +}
> +
> static int v4l2_fwnode_endpoint_parse_csi2_bus(struct fwnode_handle *fwnode,
> struct v4l2_fwnode_endpoint *vep,
> -enum v4l2_fwnode_bus_type
> bus_type)
> +enum v4l2_mbus_type bus_type)
> {
> struct v4l2_fwnode_bus_mipi_csi2 *bus = >bus.mipi_csi2;
> bool have_clk_lane = false, have_data_lanes = false,
> @@ -58,7 +115,7 @@ static int v4l2_fwnode_endpoint_parse_csi2_bus(struct
> fwnode_handle *fwnode,
> u32 v;
> int rval;
>
> - if (bus_type == V4L2_FWNODE_BUS_TYPE_CSI2_DPHY) {
> + if (bus_type == V4L2_MBUS_CSI2_DPHY) {
> use_default_lane_mapping = true;
>
> num_data_lanes = min_t(u32, bus->num_data_lanes,
> @@ -134,7 +191,7 @@ static int v4l2_fwnode_endpoint_parse_csi2_bus(struct
> fwnode_handle *fwnode,
> flags |= V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
> }
>
> - if (bus_type == V4L2_FWNODE_BUS_TYPE_CSI2_DPHY || lanes_used ||
> + if (bus_type == V4L2_MBUS_CSI2_DPHY || lanes_used ||
> have_clk_lane || (flags & ~V4L2_MBUS_CSI2_CONTINUOUS_CLOCK)) {
> bus->flags = flags;
> vep->bus_type = V4L2_MBUS_CSI2_DPHY;
> @@ -177,7 +234,7 @@ static int v4l2_fwnode_endpoint_parse_csi2_bus(struct
> fwnode_handle *fwnode,
>
> static void v4l2_fwnode_endpoint_parse_parallel_bus(
> struct fwnode_handle *fwnode, struct v4l2_fwnode_endpoint *vep,
> - enum v4l2_fwnode_bus_type bus_type)
> + enum v4l2_mbus_type bus_type)
> {
> struct v4l2_fwnode_bus_parallel *bus = >bus.parallel;
> unsigned int flags = 0;
> @@ -274,11 +331,11 @@ static void v4l2_fwnode_endpoint_parse_parallel_bus(
> else
> vep->bus_type = V4L2_MBUS_BT656;
> break;
> - case V4L2_FWNODE_BUS_TYPE_PARALLEL:
> + case V4L2_MBUS_PARALLEL:
> vep->bus_type = V4L2_MBUS_PARALLEL;
>
Re: [PATCH v2 07/23] v4l: fwnode: Let the caller provide V4L2 fwnode endpoint
Hi Sakari,
On Mon, Aug 27, 2018 at 12:29:44PM +0300, Sakari Ailus wrote:
> Instead of allocating the V4L2 fwnode endpoint in
> v4l2_fwnode_endpoint_alloc_parse, let the caller to do this. This allows
> setting default parameters for the endpoint which is a very common need
> for drivers.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/i2c/ov2659.c | 14 +-
> drivers/media/i2c/smiapp/smiapp-core.c | 26 +-
> drivers/media/i2c/tc358743.c | 26 +-
> drivers/media/v4l2-core/v4l2-fwnode.c | 49
> +-
> include/media/v4l2-fwnode.h| 10 ---
> 5 files changed, 60 insertions(+), 65 deletions(-)
>
[snip]
> -struct v4l2_fwnode_endpoint *v4l2_fwnode_endpoint_alloc_parse(
> - struct fwnode_handle *fwnode)
> +int v4l2_fwnode_endpoint_alloc_parse(
> + struct fwnode_handle *fwnode, struct v4l2_fwnode_endpoint *vep)
Looking at the resulting implementation of
"v4l2_fwnode_endpoint_alloc_parse" and "v4l2_fwnode_endpoint_parse" I
wonder if there's still value in keeping them separate... Now that in
both cases the caller has to provide an v4l2_fwnode_endpoint, isn't it
worth making a single function out of them, that behaves like
"alloc_parse" is doing nowadays (allocates vep->link_frequencies
conditionally on the presence of the "link-frequencies" property) ?
Or is the size of the allocated vep relevant in the async subdevice
matching or registration process? I guess not, but I might be missing
something...
Thanks
j
> {
> - struct v4l2_fwnode_endpoint *vep;
> int rval;
>
> - vep = kzalloc(sizeof(*vep), GFP_KERNEL);
> - if (!vep)
> - return ERR_PTR(-ENOMEM);
> -
> rval = __v4l2_fwnode_endpoint_parse(fwnode, vep);
> if (rval < 0)
> - goto out_err;
> + return rval;
>
> rval = fwnode_property_read_u64_array(fwnode, "link-frequencies",
> NULL, 0);
> @@ -316,18 +310,18 @@ struct v4l2_fwnode_endpoint
> *v4l2_fwnode_endpoint_alloc_parse(
> vep->link_frequencies =
> kmalloc_array(rval, sizeof(*vep->link_frequencies),
> GFP_KERNEL);
> - if (!vep->link_frequencies) {
> - rval = -ENOMEM;
> - goto out_err;
> - }
> + if (!vep->link_frequencies)
> + return -ENOMEM;
>
> vep->nr_of_link_frequencies = rval;
>
> rval = fwnode_property_read_u64_array(
> fwnode, "link-frequencies", vep->link_frequencies,
> vep->nr_of_link_frequencies);
> - if (rval < 0)
> - goto out_err;
> + if (rval < 0) {
> + v4l2_fwnode_endpoint_free(vep);
> + return rval;
> + }
>
> for (i = 0; i < vep->nr_of_link_frequencies; i++)
> pr_info("link-frequencies %u value %llu\n", i,
> @@ -336,11 +330,7 @@ struct v4l2_fwnode_endpoint
> *v4l2_fwnode_endpoint_alloc_parse(
>
> pr_debug("= end V4L2 endpoint properties\n");
>
> - return vep;
> -
> -out_err:
> - v4l2_fwnode_endpoint_free(vep);
> - return ERR_PTR(rval);
> + return 0;
> }
> EXPORT_SYMBOL_GPL(v4l2_fwnode_endpoint_alloc_parse);
>
> @@ -392,9 +382,9 @@ static int v4l2_async_notifier_fwnode_parse_endpoint(
> struct v4l2_fwnode_endpoint *vep,
> struct v4l2_async_subdev *asd))
> {
> + struct v4l2_fwnode_endpoint vep = { .bus_type = V4L2_MBUS_UNKNOWN };
> struct v4l2_async_subdev *asd;
> - struct v4l2_fwnode_endpoint *vep;
> - int ret = 0;
> + int ret;
>
> asd = kzalloc(asd_struct_size, GFP_KERNEL);
> if (!asd)
> @@ -409,23 +399,22 @@ static int v4l2_async_notifier_fwnode_parse_endpoint(
> goto out_err;
> }
>
> - vep = v4l2_fwnode_endpoint_alloc_parse(endpoint);
> - if (IS_ERR(vep)) {
> - ret = PTR_ERR(vep);
> + ret = v4l2_fwnode_endpoint_alloc_parse(endpoint, );
> + if (ret) {
> dev_warn(dev, "unable to parse V4L2 fwnode endpoint (%d)\n",
>ret);
> goto out_err;
> }
>
> - ret = parse_endpoint ? parse_endpoint(dev, vep, asd) : 0;
> + ret = parse_endpoint ? parse_endpoint(dev, , asd) : 0;
> if (ret == -ENOTCONN)
> - dev_dbg(dev, "ignoring port@%u/endpoint@%u\n", vep->base.port,
> - vep->base.id);
> + dev_dbg(dev, "ignoring port@%u/endpoint@%u\n", vep.base.port,
> + vep.base.id);
> else if (ret < 0)
> dev_warn(dev,
>"driver could not parse port@%u/endpoint@%u (%d)\n",
> - vep->base.port, vep->base.id, ret);
> - v4l2_fwnode_endpoint_free(vep);
> +
Re: [PATCH 2/2] media: ov5640: Fix auto-exposure disabling
HI Laurent,
On Thu, Sep 06, 2018 at 08:08:50PM +0300, Laurent Pinchart wrote:
> Hello,
>
> On Tuesday, 14 August 2018 18:45:25 EEST jacopo mondi wrote:
> > On Tue, Aug 07, 2018 at 08:53:23AM +, Hugues FRUCHET wrote:
> > > Hi Jacopo,
> > >
> > > In serie "[PATCH 0/5] Fix OV5640 exposure & gain"
> > > https://www.mail-archive.com/linux-media@vger.kernel.org/msg133269.html
> > > I've tried to collect fixes around exposure/gain, not only the exposure
> > > regression and I would prefer to keep it consistent with the associated
> > > procedure test.
> >
> > You're right. Please see my other reply, I mixed two different issues
> > in this series probably.
> >
> > > Moreover I dislike the internal use of control framework functions to
> > > disable/enable exposure/gain, on my opinion this has to be kept simpler
> > > by just disabling/enabling the right registers.
> >
> > Why that? I thought changing parameters exposed as controls should go
> > through the control framework to ensure consistency. Maybe I'm wrong.
>
> If I understand the driver correctly, auto-exposure has to be disabled
> temporarily when changing format and size, due to internal hardware
> requirements. The sequence should more or less be
>
> 1. Disable auto-exposure
> 2. Configure the format and size
> 3. Restore auto-exposure
>
> This sequence is internal to the driver, and should thus not be visible to
> userspace. Going through the control framework to disable and restore auto-
> exposure would generate control events that would just confuse userspace. For
> that reason I'd keep all this internal with direct register access instead of
> going through the control framework.
Thanks for the clarification.
Please note this series is superseded by Hugues' exposure and gain
fixes one, and my MIPI CSI-2 startup one (as it includes the timings
fix also sent there).
Thanks
j
>
> > > Would it be possible that you test my 5 patches serie on your side ?
> >
> > I did. I re-based the series on top of my MIPI and timings fixes and
> > it actually solves the exposure issues I didn't know I had :)
> >
> > I'll comment on v2 as well as soon as I'll get an answer from Steve on
> > the CSI-2 issue.
> >
> > > On 07/18/2018 03:04 PM, jacopo mondi wrote:
> > > > Hi again,
> > > >
> > > > On Wed, Jul 18, 2018 at 01:19:03PM +0200, Jacopo Mondi wrote:
> > > >> As of:
> > > >> commit bf4a4b518c20 ("media: ov5640: Don't force the auto exposure
> > > >> state at
> > > >> start time") auto-exposure got disabled before programming new capture
> > > >> modes to the sensor. Unfortunately the function used to do that
> > > >> (ov5640_set_exposure()) does not enable/disable auto-exposure engine
> > > >> through register 0x3503[0] bit, but programs registers [0x3500 -
> > > >> 0x3502] which represent the desired exposure time when running with
> > > >> manual exposure. As a result, auto-exposure was not actually disabled
> > > >> at all.
> > > >>
> > > >> To actually disable auto-exposure, go through the control framework
> > > >> instead of calling ov5640_set_exposure() function directly.
> > > >>
> > > >> Also, as auto-gain and auto-exposure are disabled un-conditionally but
> > > >> only
> > > >> restored to their previous values in ov5640_set_mode_direct() function,
> > > >> move controls restoring so that their value is re-programmed
> > > >> opportunely after either ov5640_set_mode_direct() or
> > > >> ov5640_set_mode_exposure_calc() have been executed.
> > > >>
> > > >> Fixes: bf4a4b518c20 ("media: ov5640: Don't force the auto exposure
> > > >> state at start time") Signed-off-by: Jacopo Mondi
> > > >>
> > > >> ---
> > > >> Is it worth doing with auto-gain what we're doing with auto-exposure?
> > > >> Cache the value and then re-program it instead of unconditionally
> > > >> disable/enable it?> >
> > > > I have missed this patch from Hugues that address almost the same
> > > > issue
> > > > https://www.mail-archive.com/linux-media@vger.kernel.org/msg133264.html
> > > >
> > > > I feel this new one is simpler, and unless we want to avoid going
> > > > through the control framework, it is not worth adding new functions to
> > > >
Re: [PATCH v3 1/2] media: ov5640: Re-work MIPI startup sequence
Hello Loic,
On Thu, Sep 06, 2018 at 10:13:53AM +0200, Loic Poulain wrote:
> On 6 September 2018 at 09:48, jacopo mondi wrote:
> > Hello Loic,
> >thanks for looking into this
> >
> > On Tue, Sep 04, 2018 at 07:22:50PM +0200, Loic Poulain wrote:
> >> Hi Jacopo,
> >>
> >> > - ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
> >> > -on ? 0 : BIT(5));
> >> > - if (ret)
> >> > - return ret;
> >> > - ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
> >> > - on ? 0x00 : 0x70);
> >> > + /*
> >> > +* Enable/disable the MIPI interface
> >> > +*
> >> > +* 0x300e = on ? 0x45 : 0x40
> >> > +* [7:5] = 001 : 2 data lanes mode
> >>
> >> Does 2-Lanes work with this config?
> >> AFAIU, if 2-Lanes is bit 5, value should be 0x25 and 0x20.
> >>
> >
> > Yes, confusing.
> >
> > The sensor manual reports
> > 0x300e[7:5] = 000 one lane mode
> > 0x300e[7:5] = 001 two lanes mode
> >
> > Although this configuration works with 2 lanes, and the application
> > note I have, with the suggested settings for MIPI CSI-2 2 lanes
> > reports 0x40 to be the 2 lanes mode...
> >
> > I used that one, also because the removed entry from the settings blob
> > is:
> > - {0x300e, 0x45, 0, 0}, {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
> > + {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
> >
> > So it was using BIT(6) already.
>
> Yes, it was setting BIT(6) from static config and BIT(5) from the
> ov5640_set_stream_mipi function. In your patch you don't set
> BIT(5) anymore.
>
> So it's not clear to me why it is still working, and the datasheet does
> not help a lot on this (BIT(6) is for debug modes).
> FYI I tried with BIT(5) only but it does not work (though I did not
> investigate a lot).
Thanks. Is your setup using 1 or 2 lanes? (I assume 2...)
Another question, unrelated to this specific issue: was the ov5640
working with dragonboard before this patch? I'm asking as I've seen
different behaviors between different platforms, and knowing this
fixes a widespread one like dragonboard is, would help getting this
patches in faster :)
Thanks
j
>
> > Anyway, it works for me with 2 lanes (and I assume Steve), you have tested
> > too, with how many lanes are you working with?
> >
> > Anyway, a comment there might be nice to have... Will add in next
> > version
>
> Definitely.
>
> Regards,
> Loic
signature.asc
Description: PGP signature
Re: [PATCH v3 1/2] media: ov5640: Re-work MIPI startup sequence
Hello Loic,
thanks for looking into this
On Tue, Sep 04, 2018 at 07:22:50PM +0200, Loic Poulain wrote:
> Hi Jacopo,
>
> > - ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
> > -on ? 0 : BIT(5));
> > - if (ret)
> > - return ret;
> > - ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
> > - on ? 0x00 : 0x70);
> > + /*
> > +* Enable/disable the MIPI interface
> > +*
> > +* 0x300e = on ? 0x45 : 0x40
> > +* [7:5] = 001 : 2 data lanes mode
>
> Does 2-Lanes work with this config?
> AFAIU, if 2-Lanes is bit 5, value should be 0x25 and 0x20.
>
Yes, confusing.
The sensor manual reports
0x300e[7:5] = 000 one lane mode
0x300e[7:5] = 001 two lanes mode
Although this configuration works with 2 lanes, and the application
note I have, with the suggested settings for MIPI CSI-2 2 lanes
reports 0x40 to be the 2 lanes mode...
I used that one, also because the removed entry from the settings blob
is:
- {0x300e, 0x45, 0, 0}, {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
+ {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
So it was using BIT(6) already.
I do not remember if I tested BIT(5) or not, it would be interesting
if someone using a 1-lane interface could try '000' and '001' maybe.
Anyway, it works for me with 2 lanes (and I assume Steve), you have tested
too, with how many lanes are you working with?
Anyway, a comment there might be nice to have... Will add in next
version
Thanks
j
> > +* [4] = 0 : Power up MIPI HS Tx
> > +* [3] = 0 : Power up MIPI LS Rx
> > +* [2] = 1/0: MIPI interface enable/disable
> > +* [1:0] = 01/00: FIXME: 'debug'
> > +*/
> > + ret = ov5640_write_reg(sensor, OV5640_REG_IO_MIPI_CTRL00,
> > + on ? 0x45 : 0x40);
>
> Regards,
> Loic
signature.asc
Description: PGP signature
Re: [PATCH 3/3] media: imx-pxp: add i.MX Pixel Pipeline driver
Hi Philipp,
On Fri, Aug 10, 2018 at 05:18:22PM +0200, Philipp Zabel wrote:
> Add a V4L2 mem-to-mem scaler/CSC driver for the Pixel Pipeline (PXP)
> version found on i.MX6ULL SoCs. A similar variant is used on i.MX7D.
>
> Since this driver only uses the legacy pipeline, it should be reasonably
> easy to extend it to work with the older PXP versions found on i.MX6UL,
> i.MX6SX, i.MX6SL, i.MX28, and i.MX23.
>
> The driver supports scaling and colorspace conversion. There is
> currently no support for rotation, alpha-blending, and the LUTs.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/media/platform/Kconfig |9 +
> drivers/media/platform/Makefile |2 +
> drivers/media/platform/imx-pxp.c | 1455 ++
> drivers/media/platform/imx-pxp.h | 1685 ++
> 4 files changed, 3151 insertions(+)
> create mode 100644 drivers/media/platform/imx-pxp.c
> create mode 100644 drivers/media/platform/imx-pxp.h
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index b25c8d3c1c31..ae1c025c14de 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -181,6 +181,15 @@ config VIDEO_CODA
> config VIDEO_IMX_VDOA
> def_tristate VIDEO_CODA if SOC_IMX6Q || COMPILE_TEST
>
> +config VIDEO_IMX_PXP
> + tristate "i.MX Pixel Pipeline (PXP)"
> + depends on VIDEO_DEV && VIDEO_V4L2 && (ARCH_MXC || COMPILE_TEST)
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_MEM2MEM_DEV
> + help
> + The i.MX Pixel Pipeline is a memory-to-memory engine for scaling,
> + color space conversion, and rotation.
> +
> config VIDEO_MEDIATEK_JPEG
> tristate "Mediatek JPEG Codec driver"
> depends on MTK_IOMMU_V1 || COMPILE_TEST
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 08640ba87fc2..0c2714c2bb05 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -25,6 +25,8 @@ obj-$(CONFIG_VIDEO_TI_CAL) += ti-vpe/
> obj-$(CONFIG_VIDEO_MX2_EMMAPRP) += mx2_emmaprp.o
> obj-$(CONFIG_VIDEO_CODA) += coda/
>
> +obj-$(CONFIG_VIDEO_IMX_PXP) += imx-pxp.o
> +
> obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
>
> obj-$(CONFIG_CEC_GPIO) += cec-gpio/
> diff --git a/drivers/media/platform/imx-pxp.c
> b/drivers/media/platform/imx-pxp.c
> new file mode 100644
> index ..c9e3ef0f92b4
> --- /dev/null
> +++ b/drivers/media/platform/imx-pxp.c
> @@ -0,0 +1,1455 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * i.MX Pixel Pipeline (PXP) mem-to-mem scaler/CSC/rotator driver
> + *
> + * Copyright (c) 2018 Pengutronix, Philipp Zabel
> + *
> + * based on vim2m
> + *
> + * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
> + * Pawel Osciak,
> + * Marek Szyprowski,
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "imx-pxp.h"
> +
> +static unsigned int debug;
> +module_param(debug, uint, 0644);
> +MODULE_PARM_DESC(debug, "activates debug info");
> +
> +#define MIN_W 8
> +#define MIN_H 8
> +#define MAX_W 4096
> +#define MAX_H 4096
> +#define ALIGN_W 3 /* 8x8 pixel blocks */
> +#define ALIGN_H 3
> +
> +/* Flags that indicate a format can be used for capture/output */
> +#define MEM2MEM_CAPTURE (1 << 0)
> +#define MEM2MEM_OUTPUT (1 << 1)
> +
> +#define MEM2MEM_NAME "pxp"
> +
> +/* Per queue */
> +#define MEM2MEM_DEF_NUM_BUFS VIDEO_MAX_FRAME
> +/* In bytes, per queue */
> +#define MEM2MEM_VID_MEM_LIMIT(16 * 1024 * 1024)
> +
> +/* Flags that indicate processing mode */
> +#define MEM2MEM_HFLIP(1 << 0)
> +#define MEM2MEM_VFLIP(1 << 1)
> +
> +#define dprintk(dev, fmt, arg...) \
> + v4l2_dbg(1, debug, >v4l2_dev, "%s: " fmt, __func__, ## arg)
> +
> +struct pxp_fmt {
> + u32 fourcc;
> + int depth;
> + /* Types the format can be used for */
> + u32 types;
> +};
> +
> +static struct pxp_fmt formats[] = {
> + {
> + .fourcc = V4L2_PIX_FMT_XBGR32,
> + .depth = 32,
> + /* Both capture and output format */
> + .types = MEM2MEM_CAPTURE | MEM2MEM_OUTPUT,
> + }, {
> + .fourcc = V4L2_PIX_FMT_ABGR32,
> + .depth = 32,
> + /* Capture-only format */
> + .types = MEM2MEM_CAPTURE,
> + }, {
> + .fourcc = V4L2_PIX_FMT_BGR24,
> + .depth = 24,
> + .types = MEM2MEM_CAPTURE,
> + }, {
> + .fourcc = V4L2_PIX_FMT_RGB565,
> + .depth = 16,
> + .types = MEM2MEM_CAPTURE | MEM2MEM_OUTPUT,
> + }, {
> + .fourcc = V4L2_PIX_FMT_RGB555,
> + .depth = 16,
> + .types = MEM2MEM_CAPTURE | MEM2MEM_OUTPUT,
> +
Re: [PATCH v3 0/2] media: i2c: ov5640: Re-work MIPI startup sequence
Hello Loic, On Tue, Aug 28, 2018 at 05:08:07PM +0200, Loic Poulain wrote: > On 15 August 2018 at 12:28, Jacopo Mondi wrote: > > Hello ov5640 people, > >this driver has received a lot of attention recently, and this series > > aims > > to fix the CSI-2 interface startup on i.Mx6Q platforms. > > > > Please refer to the v2 cover letters for more background informations: > > https://www.mail-archive.com/linux-media@vger.kernel.org/msg133420.html > > > > This two patches alone allows the MIPI interface to startup properly, but in > > order to capture good images (good as in 'not completely black') exposure > > and > > gain handling should be fixed too. > > Hugues Fruchet has a series in review that fixes that issues: > > [PATCH v2 0/5] Fix OV5640 exposure & gain > > > > And I have re-based it on top of this two fixes here: > > git://jmondi.org/linux ov5640/timings_exposure > > > > Steve Longerbeam tested that branch on his I.MX6q SabreSD board and > > confirms he > > can now capture frames (I added his Tested-by tag to this patches). I have > > verified the same on Engicam iCore I.MX6q and an Intel Atom based board. > > > > Ideally I would like to have these two fixes merged, and Hugues' ones then > > applied on top. Of course, more testing on other platforms using CSI-2 is > > very > > welcome. > > > > Thanks > > j > > > > v2 -> v3: > > - patch [2/2] was originally sent in a different series, compared to v2 it > > removes entries from the blob array instead of adding more. > > > > Jacopo Mondi (2): > > media: ov5640: Re-work MIPI startup sequence > > media: ov5640: Fix timings setup code > > > > drivers/media/i2c/ov5640.c | 141 > > + > > 1 file changed, 92 insertions(+), 49 deletions(-) > > > > -- > > 2.7.4 > > > > Thanks for this work. > I've just tested this with a dragonboard-410c (MICPI/CSI) + OV5640 sensor. > It works on my side for 1280*720, 1920*1080 and 2592*1944 formats. > > Tested-by: Loic Poulain Thanks for testing! Just out of curiosity, did the dragonboard-410c CSI-2 interface had issues poperly starting up before this series like the i.MX6q did? Thanks j signature.asc Description: PGP signature
Re: [PATCH] media: ov5640: fix mode change regression
On Tue, Aug 28, 2018 at 02:57:11PM +0200, jacopo mondi wrote:
> Hi Hugues,
>thanks for the patch
>
> On Thu, Aug 16, 2018 at 11:46:53AM +0200, Hugues Fruchet wrote:
> > fixes: 6949d864776e ("media: ov5640: do not change mode if format or frame
> > interval is unchanged").
> >
> > Symptom was fuzzy image because of JPEG default format
> > not being changed according to new format selected, fix this.
> > Init sequence initialises format to YUV422 UYVY but
> > sensor->fmt initial value was set to JPEG, fix this.
> >
> > Signed-off-by: Hugues Fruchet
> > ---
> > drivers/media/i2c/ov5640.c | 21 -
> > 1 file changed, 16 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> > index 071f4bc..2ddd86d 100644
> > --- a/drivers/media/i2c/ov5640.c
> > +++ b/drivers/media/i2c/ov5640.c
> > @@ -223,6 +223,7 @@ struct ov5640_dev {
> > int power_count;
> >
> > struct v4l2_mbus_framefmt fmt;
> > + bool pending_fmt_change;
>
> The foundamental issue here is that 'struct ov5640_mode_info' and
> associated functions do not take the image format into account...
> That would be the real fix, but I understand it requires changing and
> re-testing a lot of stuff :(
>
> But what if instead of adding more flags, don't we use bitfields in a single
> "pending_changes" field? As when, and if, framerate will be made more
> 'dynamic' and we remove the static 15/30FPS configuration from
> ov5640_mode_info, we will have the same problem we have today with
> format with framerate too...
>
> Something like:
>
> struct ov5640_dev {
> ...
> - bool pending_mode_change;
> + #define MODE_CHANGE BIT(0)
> + #define FMT_CHANGE BIT(1)
> + u8 pending;
> ...
> }
>
> >
> > const struct ov5640_mode_info *current_mode;
> > enum ov5640_frame_rate current_fr;
> > @@ -255,7 +256,7 @@ static inline struct v4l2_subdev *ctrl_to_sd(struct
> > v4l2_ctrl *ctrl)
> > * should be identified and removed to speed register load time
> > * over i2c.
> > */
> > -
> > +/* YUV422 UYVY VGA@30fps */
> > static const struct reg_value ov5640_init_setting_30fps_VGA[] = {
> > {0x3103, 0x11, 0, 0}, {0x3008, 0x82, 0, 5}, {0x3008, 0x42, 0, 0},
> > {0x3103, 0x03, 0, 0}, {0x3017, 0x00, 0, 0}, {0x3018, 0x00, 0, 0},
> > @@ -1968,9 +1969,12 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
> >
> > if (new_mode != sensor->current_mode) {
> > sensor->current_mode = new_mode;
> > - sensor->fmt = *mbus_fmt;
> > sensor->pending_mode_change = true;
> > }
> > + if (mbus_fmt->code != sensor->fmt.code) {
> > + sensor->fmt = *mbus_fmt;
> > + sensor->pending_fmt_change = true;
> > + }
>
> That would make this simpler
>
> sensor->current_mode = new_mode;
> sensor->fmt = *mbus_fmt;
>
> if (new_mode != sensor->current_mode)
> sensor->pending |= MODE_CHANGE;
> if (mbus_fmt->code != sensor->fmt.code) {
> sensor->pending |= FMT_CHANGE;
>
Yeah, well, this is in wrong order of course :)
signature.asc
Description: PGP signature
Re: [PATCH] media: ov5640: fix mode change regression
Hi Hugues,
thanks for the patch
On Thu, Aug 16, 2018 at 11:46:53AM +0200, Hugues Fruchet wrote:
> fixes: 6949d864776e ("media: ov5640: do not change mode if format or frame
> interval is unchanged").
>
> Symptom was fuzzy image because of JPEG default format
> not being changed according to new format selected, fix this.
> Init sequence initialises format to YUV422 UYVY but
> sensor->fmt initial value was set to JPEG, fix this.
>
> Signed-off-by: Hugues Fruchet
> ---
> drivers/media/i2c/ov5640.c | 21 -
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 071f4bc..2ddd86d 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -223,6 +223,7 @@ struct ov5640_dev {
> int power_count;
>
> struct v4l2_mbus_framefmt fmt;
> + bool pending_fmt_change;
The foundamental issue here is that 'struct ov5640_mode_info' and
associated functions do not take the image format into account...
That would be the real fix, but I understand it requires changing and
re-testing a lot of stuff :(
But what if instead of adding more flags, don't we use bitfields in a single
"pending_changes" field? As when, and if, framerate will be made more
'dynamic' and we remove the static 15/30FPS configuration from
ov5640_mode_info, we will have the same problem we have today with
format with framerate too...
Something like:
struct ov5640_dev {
...
- bool pending_mode_change;
+ #define MODE_CHANGE BIT(0)
+ #define FMT_CHANGE BIT(1)
+ u8 pending;
...
}
>
> const struct ov5640_mode_info *current_mode;
> enum ov5640_frame_rate current_fr;
> @@ -255,7 +256,7 @@ static inline struct v4l2_subdev *ctrl_to_sd(struct
> v4l2_ctrl *ctrl)
> * should be identified and removed to speed register load time
> * over i2c.
> */
> -
> +/* YUV422 UYVY VGA@30fps */
> static const struct reg_value ov5640_init_setting_30fps_VGA[] = {
> {0x3103, 0x11, 0, 0}, {0x3008, 0x82, 0, 5}, {0x3008, 0x42, 0, 0},
> {0x3103, 0x03, 0, 0}, {0x3017, 0x00, 0, 0}, {0x3018, 0x00, 0, 0},
> @@ -1968,9 +1969,12 @@ static int ov5640_set_fmt(struct v4l2_subdev *sd,
>
> if (new_mode != sensor->current_mode) {
> sensor->current_mode = new_mode;
> - sensor->fmt = *mbus_fmt;
> sensor->pending_mode_change = true;
> }
> + if (mbus_fmt->code != sensor->fmt.code) {
> + sensor->fmt = *mbus_fmt;
> + sensor->pending_fmt_change = true;
> + }
That would make this simpler
sensor->current_mode = new_mode;
sensor->fmt = *mbus_fmt;
if (new_mode != sensor->current_mode)
sensor->pending |= MODE_CHANGE;
if (mbus_fmt->code != sensor->fmt.code) {
sensor->pending |= FMT_CHANGE;
> out:
> mutex_unlock(>lock);
> return ret;
> @@ -2544,10 +2548,13 @@ static int ov5640_s_stream(struct v4l2_subdev *sd,
> int enable)
> ret = ov5640_set_mode(sensor, sensor->current_mode);
> if (ret)
> goto out;
> + }
>
> + if (enable && sensor->pending_fmt_change) {
> ret = ov5640_set_framefmt(sensor, >fmt);
> if (ret)
> goto out;
> + sensor->pending_fmt_change = false;
> }
>
And that would be accordingly:
if (sensor->pending & MODE_CHANGE) {
ret = ov5640_set_mode(sensor, sensor->current_mode);
}
if (sensor->pending & FMT_CHANGE) {
ret = ov5640_set_framefmt(sensor, >fmt);
...
}
What do you (and others) think?
Thanks
j
> if (sensor->ep.bus_type == V4L2_MBUS_CSI2)
> @@ -2642,9 +2649,14 @@ static int ov5640_probe(struct i2c_client *client,
> return -ENOMEM;
>
> sensor->i2c_client = client;
> +
> + /*
> + * default init sequence initialize sensor to
> + * YUV422 UYVY VGA@30fps
> + */
> fmt = >fmt;
> - fmt->code = ov5640_formats[0].code;
> - fmt->colorspace = ov5640_formats[0].colorspace;
> + fmt->code = MEDIA_BUS_FMT_UYVY8_2X8;
> + fmt->colorspace = V4L2_COLORSPACE_SRGB;
> fmt->ycbcr_enc = V4L2_MAP_YCBCR_ENC_DEFAULT(fmt->colorspace);
> fmt->quantization = V4L2_QUANTIZATION_FULL_RANGE;
> fmt->xfer_func = V4L2_MAP_XFER_FUNC_DEFAULT(fmt->colorspace);
> @@ -2656,7 +2668,6 @@ static int ov5640_probe(struct i2c_client *client,
> sensor->current_fr = OV5640_30_FPS;
> sensor->current_mode =
> _mode_data[OV5640_30_FPS][OV5640_MODE_VGA_640_480];
> - sensor->pending_mode_change = true;
>
> sensor->ae_target = 52;
>
>
Re: [PATCH v2 5/5] media: ov5640: fix restore of last mode set
Hi Hugues,
one more comment on this patch..
On Mon, Aug 13, 2018 at 12:19:46PM +0200, Hugues Fruchet wrote:
> Mode setting depends on last mode set, in particular
> because of exposure calculation when downscale mode
> change between subsampling and scaling.
> At stream on the last mode was wrongly set to current mode,
> so no change was detected and exposure calculation
> was not made, fix this.
>
> Signed-off-by: Hugues Fruchet
> ---
> drivers/media/i2c/ov5640.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index c110a6a..923cc30 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -225,6 +225,7 @@ struct ov5640_dev {
> struct v4l2_mbus_framefmt fmt;
>
> const struct ov5640_mode_info *current_mode;
> + const struct ov5640_mode_info *last_mode;
> enum ov5640_frame_rate current_fr;
> struct v4l2_fract frame_interval;
>
> @@ -1628,6 +1629,9 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
> bool auto_exp = sensor->ctrls.auto_exp->val == V4L2_EXPOSURE_AUTO;
> int ret;
>
> + if (!orig_mode)
> + orig_mode = mode;
> +
Am I wrong or with the introduction of last_mode we could drop the
'orig_mode' parameter (which has confused me already :/ ) from the
set_mode() function?
Just set here 'orig_mode = sensor->last_mode' and make sure last_mode
is intialized properly at probe time...
Or is there some other value in keeping the orig_mode parameter here?
Thanks
j
> dn_mode = mode->dn_mode;
> orig_dn_mode = orig_mode->dn_mode;
>
> @@ -1688,6 +1692,7 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
> return ret;
>
> sensor->pending_mode_change = false;
> + sensor->last_mode = mode;
>
> return 0;
>
> @@ -2551,7 +2556,8 @@ static int ov5640_s_stream(struct v4l2_subdev *sd, int
> enable)
>
> if (sensor->streaming == !enable) {
> if (enable && sensor->pending_mode_change) {
> - ret = ov5640_set_mode(sensor, sensor->current_mode);
> + ret = ov5640_set_mode(sensor, sensor->last_mode);
> +
> if (ret)
> goto out;
>
> --
> 2.7.4
>
signature.asc
Description: PGP signature
Re: [PATCH v2 5/5] media: ov5640: fix restore of last mode set
Hi Hugues,
On Thu, Aug 16, 2018 at 03:07:54PM +, Hugues FRUCHET wrote:
> Hi Jacopo,
>
> On 08/16/2018 12:10 PM, jacopo mondi wrote:
> > Hi Hugues,
> > thanks for the patch
> >
> > On Mon, Aug 13, 2018 at 12:19:46PM +0200, Hugues Fruchet wrote:
> >> Mode setting depends on last mode set, in particular
> >> because of exposure calculation when downscale mode
> >> change between subsampling and scaling.
> >> At stream on the last mode was wrongly set to current mode,
> >> so no change was detected and exposure calculation
> >> was not made, fix this.
> >
> > I actually see a different issue here...
>
> Which problem do you have exactly, you got a VGA JPEG instead of a QVGA
> YUYV ?
>
Not a matter of image format but sizes. I printed out the format
applied and it seems to me it was always the initial one.
On a second thought, a pipeline with a mis-configuration would not
have ever started streaming, so I should have investigated better.
> >
> > The issue I see here depends on the format programmed through
> > set_fmt() never being applied when using the sensor with a media
> > controller equipped device (in this case an i.MX6 board) through
> > capture sessions, and the not properly calculated exposure you see may
> > be a consequence of this.
> >
> > I'll try to write down what I see, with the help of some debug output.
> >
> > - At probe time mode 640x460@30 is programmed:
> >[1.651216] ov5640_probe: Initial mode with id: 2
> >
> > - I set the format on the sensor's pad and it gets not applied but
> >marked as pending as the sensor is powered off:
> >
> >#media-ctl --set-v4l2 "'ov5640 2-003c':0[fmt:UYVY2X8/320x240 field:none]"
> > [ 65.611983] ov5640_set_fmt: NEW mode with id: 1 - PENDING
>
> So here sensor->current_mode is set to <1>;//QVGA
> and sensor->pending_mode_change is set to true;
>
> >
> > - I start streaming with yavta, and the sensor receives a power on;
> >this causes the 'initial' format to be re-programmed and the pending
> >change to be ignored:
> >
> >#yavta -c10 -n4 -f YUYV -s $320x240 -F"../frame-#.yuv" /dev/video4
> > [ 69.395018] ov5640_set_power:1805 - on
> > [ 69.431342] ov5640_restore_mode:1711
> > [ 69.996882] ov5640_set_mode: Apply mode with id: 0
> >
> >The 'ov5640_set_mode()' call from 'ov5640_restore_mode()' clears the
> >sensor->pending flag, discarding the newly requested format, for
> >this reason, at s_stream() time, the pending flag is not set
> >anymore.
>
> OK but before clearing sensor->pending_mode_change, set_mode() is
> loading registers corresponding to sensor->current_mode:
> static int ov5640_set_mode(struct ov5640_dev *sensor,
> const struct ov5640_mode_info *orig_mode)
> {
> ==> const struct ov5640_mode_info *mode = sensor->current_mode;
> ...
> ret = ov5640_set_mode_direct(sensor, mode, exposure);
>
> => so mode <1> is expected to be set now, so I don't understand your trace:
> "> [ 69.996882] ov5640_set_mode: Apply mode with id: 0"
> Which variable do you trace that shows "0" ?
>
>
> >
> > Are you using a media-controller system? I suspect in non-mc cases,
> > the set_fmt is applied through a single power_on/power_off session, not
> > causing the 'restore_mode()' issue. Is this the case for you or your
> > issue is differnt?
> >
> > Edit:
> > Mita-san tried to address the issue of the output pixel format not
> > being restored when the image format was restored in
> > 19ad26f9e6e1 ("media: ov5640: add missing output pixel format setting")
> >
> > I understand the issue he tried to fix, but shouldn't the pending
> > format (if any) be applied instead of the initial one unconditionally?
>
> This is what does the ov5640_restore_mode(), set the current mode
> (sensor->current_mode), that is done through this line:
> /* now restore the last capture mode */
> ret = ov5640_set_mode(sensor, _mode_init_data);
> => note that the comment above is weird, in fact it is the "current"
> mode that is set.
> => note also that the 2nd parameter is not the mode to be set but the
> previously applied mode ! (ie loaded in ov5640 registers). This is used
> to decide if we have to go to the "set_mode_exposure_calc" or
> "set_mode_direct".
This is where I got lost... Sorry for the sloppy comment, now I get
what your patch was for :)
>
> the ov5640_restore_
Re: [PATCH v2 1/4] media: soc_camera: ov9640: move ov9640 out of soc_camera
Hi Petr, On Wed, Aug 15, 2018 at 03:35:39PM +0200, Petr Cvek wrote: > BTW from the v1 discussion: > > Dne 10.8.2018 v 09:32 jacopo mondi napsal(a): > > When I've been recently doing the same for ov772x and other sensor > > driver I've been suggested to first copy the driver into > > drivers/media/i2c/ and leave the original soc_camera one there, so > > they can be bulk removed or moved to staging. I'll let Hans confirm > > this, as he's about to take care of this process. > > I would rather used git mv for preserve the git history, but if a simple > copy is fine then I'm fine too ;-). Well, 'git mv' removes the soc_camera version of this driver, and my understanding was that when those driver will be obsoleted they will be bulk removed or moved to staging by Hans. Also, I feel this is trivial and I'm not getting something but: $ git mv drivers/media/i2c/soc_camera/ov9640.c drivers/media/i2c/ $ git commit -s -m "test" $ git log --oneline drivers/media/i2c/ov9640.c | wc -l 1 Hence, I don't see history be preserved (which makes sense, as git mv is actually a shortcut for 'mv $old $new; git add $new; git add $old') Am I missing something maybe? Thanks j > > Petr signature.asc Description: PGP signature
Re: [PATCH v2 5/5] media: ov5640: fix restore of last mode set
Hi Hugues,
thanks for the patch
On Mon, Aug 13, 2018 at 12:19:46PM +0200, Hugues Fruchet wrote:
> Mode setting depends on last mode set, in particular
> because of exposure calculation when downscale mode
> change between subsampling and scaling.
> At stream on the last mode was wrongly set to current mode,
> so no change was detected and exposure calculation
> was not made, fix this.
I actually see a different issue here...
The issue I see here depends on the format programmed through
set_fmt() never being applied when using the sensor with a media
controller equipped device (in this case an i.MX6 board) through
capture sessions, and the not properly calculated exposure you see may
be a consequence of this.
I'll try to write down what I see, with the help of some debug output.
- At probe time mode 640x460@30 is programmed:
[1.651216] ov5640_probe: Initial mode with id: 2
- I set the format on the sensor's pad and it gets not applied but
marked as pending as the sensor is powered off:
#media-ctl --set-v4l2 "'ov5640 2-003c':0[fmt:UYVY2X8/320x240 field:none]"
[ 65.611983] ov5640_set_fmt: NEW mode with id: 1 - PENDING
- I start streaming with yavta, and the sensor receives a power on;
this causes the 'initial' format to be re-programmed and the pending
change to be ignored:
#yavta -c10 -n4 -f YUYV -s $320x240 -F"../frame-#.yuv" /dev/video4
[ 69.395018] ov5640_set_power:1805 - on
[ 69.431342] ov5640_restore_mode:1711
[ 69.996882] ov5640_set_mode: Apply mode with id: 0
The 'ov5640_set_mode()' call from 'ov5640_restore_mode()' clears the
sensor->pending flag, discarding the newly requested format, for
this reason, at s_stream() time, the pending flag is not set
anymore.
Are you using a media-controller system? I suspect in non-mc cases,
the set_fmt is applied through a single power_on/power_off session, not
causing the 'restore_mode()' issue. Is this the case for you or your
issue is differnt?
Edit:
Mita-san tried to address the issue of the output pixel format not
being restored when the image format was restored in
19ad26f9e6e1 ("media: ov5640: add missing output pixel format setting")
I understand the issue he tried to fix, but shouldn't the pending
format (if any) be applied instead of the initial one unconditionally?
Thanks
j
>
> Signed-off-by: Hugues Fruchet
> ---
> drivers/media/i2c/ov5640.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index c110a6a..923cc30 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -225,6 +225,7 @@ struct ov5640_dev {
> struct v4l2_mbus_framefmt fmt;
>
> const struct ov5640_mode_info *current_mode;
> + const struct ov5640_mode_info *last_mode;
> enum ov5640_frame_rate current_fr;
> struct v4l2_fract frame_interval;
>
> @@ -1628,6 +1629,9 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
> bool auto_exp = sensor->ctrls.auto_exp->val == V4L2_EXPOSURE_AUTO;
> int ret;
>
> + if (!orig_mode)
> + orig_mode = mode;
> +
> dn_mode = mode->dn_mode;
> orig_dn_mode = orig_mode->dn_mode;
>
> @@ -1688,6 +1692,7 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
> return ret;
>
> sensor->pending_mode_change = false;
> + sensor->last_mode = mode;
>
> return 0;
>
> @@ -2551,7 +2556,8 @@ static int ov5640_s_stream(struct v4l2_subdev *sd, int
> enable)
>
> if (sensor->streaming == !enable) {
> if (enable && sensor->pending_mode_change) {
> - ret = ov5640_set_mode(sensor, sensor->current_mode);
> + ret = ov5640_set_mode(sensor, sensor->last_mode);
> +
> if (ret)
> goto out;
>
> --
> 2.7.4
>
signature.asc
Description: PGP signature
[PATCH v3 2/2] media: ov5640: Fix timings setup code
From: Jacopo Mondi
As of:
commit 476dec012f4c ("media: ov5640: Add horizontal and vertical totals")
the timings parameters gets programmed separately from the static register
values array.
When changing capture mode, the vertical and horizontal totals gets inspected
by the set_mode_exposure_calc() functions, and only later programmed with the
new values. This means exposure, light banding filter and shutter gain are
calculated using the previous timings, and are thus not correct.
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")
Tested-by: Steve Longerbeam
on i.MX6q SabreSD with MIPI CSI-2 OV5640 module
Signed-off-by: Samuel Bobrowicz
Signed-off-by: Maxime Ripard
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/ov5640.c | 50 +++---
1 file changed, 21 insertions(+), 29 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 7bbd1d7..c81a2a7 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -908,6 +908,26 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, u16
reg,
}
/* download ov5640 settings to sensor through i2c */
+static int ov5640_set_timings(struct ov5640_dev *sensor,
+ const struct ov5640_mode_info *mode)
+{
+ int ret;
+
+ ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_DVPHO, mode->hact);
+ if (ret < 0)
+ return ret;
+
+ ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_DVPVO, mode->vact);
+ if (ret < 0)
+ return ret;
+
+ ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_HTS, mode->htot);
+ if (ret < 0)
+ return ret;
+
+ return ov5640_write_reg16(sensor, OV5640_REG_TIMING_VTS, mode->vtot);
+}
+
static int ov5640_load_regs(struct ov5640_dev *sensor,
const struct ov5640_mode_info *mode)
{
@@ -935,7 +955,7 @@ static int ov5640_load_regs(struct ov5640_dev *sensor,
usleep_range(1000 * delay_ms, 1000 * delay_ms + 100);
}
- return ret;
+ return ov5640_set_timings(sensor, mode);
}
/* read exposure, in number of line periods */
@@ -1391,30 +1411,6 @@ static int ov5640_set_virtual_channel(struct ov5640_dev
*sensor)
return ov5640_write_reg(sensor, OV5640_REG_DEBUG_MODE, temp);
}
-static int ov5640_set_timings(struct ov5640_dev *sensor,
- const struct ov5640_mode_info *mode)
-{
- int ret;
-
- ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_DVPHO, mode->hact);
- if (ret < 0)
- return ret;
-
- ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_DVPVO, mode->vact);
- if (ret < 0)
- return ret;
-
- ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_HTS, mode->htot);
- if (ret < 0)
- return ret;
-
- ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_VTS, mode->vtot);
- if (ret < 0)
- return ret;
-
- return 0;
-}
-
static const struct ov5640_mode_info *
ov5640_find_mode(struct ov5640_dev *sensor, enum ov5640_frame_rate fr,
int width, int height, bool nearest)
@@ -1658,10 +1654,6 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
if (ret < 0)
return ret;
- ret = ov5640_set_timings(sensor, mode);
- if (ret < 0)
- return ret;
-
ret = ov5640_set_binning(sensor, dn_mode != SCALING);
if (ret < 0)
return ret;
--
2.7.4
[PATCH v3 1/2] media: ov5640: Re-work MIPI startup sequence
From: Jacopo Mondi
Rework the MIPI interface startup sequence with the following changes:
- Remove MIPI bus initialization from the initial settings blob
- At set_power(1) time power up MIPI Tx/Rx and set data and clock lanes in
LP11 during 'sleep' and 'idle' with MIPI clock in non-continuous mode.
- At s_stream time enable/disable the MIPI interface output.
- Restore default settings at set_power(0) time.
Before this commit the sensor MIPI interface was initialized with settings
that require a start/stop sequence at power-up time in order to force lanes
into LP11 state, as they were initialized in LP00 when in 'sleep mode',
which is assumed to be the sensor manual definition for the D-PHY defined
stop mode.
The stream start/stop was performed by enabling disabling clock gating,
and had the side effect to change the lanes sleep mode configuration when
stream was stopped.
Clock gating/ungating:
- ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
-on ? 0 : BIT(5));
- if (ret)
Set lanes in LP11 when in 'sleep mode':
- ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
- on ? 0x00 : 0x70);
This commit fixes an issue reported by Jagan Teki on i.MX6 platforms that
prevents the host interface from powering up correctly:
https://lkml.org/lkml/2018/6/1/38
It also improves MIPI capture operations stability on my testing platform
where MIPI capture often failed and returned all-purple frames.
fixes: f22996db44e2 ("media: ov5640: add support of DVP parallel interface")
Tested-by: Steve Longerbeam
on i.MX6q SabreSD with MIPI CSI-2 OV5640 module
Reported-by: Jagan Teki
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/ov5640.c | 91 --
1 file changed, 71 insertions(+), 20 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 1ecbb7a..7bbd1d7 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -286,10 +286,10 @@ static const struct reg_value
ov5640_init_setting_30fps_VGA[] = {
{0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
{0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x3000, 0x00, 0, 0},
{0x3002, 0x1c, 0, 0}, {0x3004, 0xff, 0, 0}, {0x3006, 0xc3, 0, 0},
- {0x300e, 0x45, 0, 0}, {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
+ {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
{0x501f, 0x00, 0, 0}, {0x4713, 0x03, 0, 0}, {0x4407, 0x04, 0, 0},
{0x440e, 0x00, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
- {0x4837, 0x0a, 0, 0}, {0x4800, 0x04, 0, 0}, {0x3824, 0x02, 0, 0},
+ {0x4837, 0x0a, 0, 0}, {0x3824, 0x02, 0, 0},
{0x5000, 0xa7, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x5180, 0xff, 0, 0},
{0x5181, 0xf2, 0, 0}, {0x5182, 0x00, 0, 0}, {0x5183, 0x14, 0, 0},
{0x5184, 0x25, 0, 0}, {0x5185, 0x24, 0, 0}, {0x5186, 0x09, 0, 0},
@@ -1102,12 +1102,18 @@ static int ov5640_set_stream_mipi(struct ov5640_dev
*sensor, bool on)
{
int ret;
- ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
-on ? 0 : BIT(5));
- if (ret)
- return ret;
- ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
- on ? 0x00 : 0x70);
+ /*
+* Enable/disable the MIPI interface
+*
+* 0x300e = on ? 0x45 : 0x40
+* [7:5] = 001 : 2 data lanes mode
+* [4] = 0 : Power up MIPI HS Tx
+* [3] = 0 : Power up MIPI LS Rx
+* [2] = 1/0: MIPI interface enable/disable
+* [1:0] = 01/00: FIXME: 'debug'
+*/
+ ret = ov5640_write_reg(sensor, OV5640_REG_IO_MIPI_CTRL00,
+ on ? 0x45 : 0x40);
if (ret)
return ret;
@@ -1786,23 +1792,68 @@ static int ov5640_set_power(struct ov5640_dev *sensor,
bool on)
if (ret)
goto power_off;
+ /* We're done here for DVP bus, while CSI-2 needs setup. */
+ if (sensor->ep.bus_type != V4L2_MBUS_CSI2)
+ return 0;
+
+ /*
+* Power up MIPI HS Tx and LS Rx; 2 data lanes mode
+*
+* 0x300e = 0x40
+* [7:5] = 001 : 2 data lanes mode
+* [4] = 0 : Power up MIPI HS Tx
+* [3] = 0 : Power up MIPI LS Rx
+* [2] = 0 : MIPI interface disabled
+*/
+ ret = ov5640_write_reg(sensor,
+ OV5640_REG_IO_MIPI_CTRL00, 0x40);
+ if (ret)
+ goto power_off;
+
+ /*
+* Gate clock and set LP11 in 'no packets mode' (idle)
+*
+* 0x4800 = 0x24
+* [5] = 1 : Gate clock when 'no packets'
+* [2] = 1
[PATCH v3 0/2] media: i2c: ov5640: Re-work MIPI startup sequence
Hello ov5640 people, this driver has received a lot of attention recently, and this series aims to fix the CSI-2 interface startup on i.Mx6Q platforms. Please refer to the v2 cover letters for more background informations: https://www.mail-archive.com/linux-media@vger.kernel.org/msg133420.html This two patches alone allows the MIPI interface to startup properly, but in order to capture good images (good as in 'not completely black') exposure and gain handling should be fixed too. Hugues Fruchet has a series in review that fixes that issues: [PATCH v2 0/5] Fix OV5640 exposure & gain And I have re-based it on top of this two fixes here: git://jmondi.org/linux ov5640/timings_exposure Steve Longerbeam tested that branch on his I.MX6q SabreSD board and confirms he can now capture frames (I added his Tested-by tag to this patches). I have verified the same on Engicam iCore I.MX6q and an Intel Atom based board. Ideally I would like to have these two fixes merged, and Hugues' ones then applied on top. Of course, more testing on other platforms using CSI-2 is very welcome. Thanks j v2 -> v3: - patch [2/2] was originally sent in a different series, compared to v2 it removes entries from the blob array instead of adding more. Jacopo Mondi (2): media: ov5640: Re-work MIPI startup sequence media: ov5640: Fix timings setup code drivers/media/i2c/ov5640.c | 141 + 1 file changed, 92 insertions(+), 49 deletions(-) -- 2.7.4
Re: [PATCH v2 0/2] media: i2c: ov5640: Re-work MIPI startup sequence
Hi Steve, On Tue, Aug 14, 2018 at 04:53:26PM -0700, Steve Longerbeam wrote: > > > On 08/14/2018 10:38 AM, jacopo mondi wrote: > >Hi Steve, > > > >On Tue, Aug 14, 2018 at 09:51:04AM -0700, Steve Longerbeam wrote: > >>Hi Jacopo, > >> > >> > >>On 08/14/2018 08:35 AM, jacopo mondi wrote: > >>>Hi Steve, > >>>sorry for resurecting this. > >>> > >>> > >>>>>I'm sorry I'm not sur I'm following. Does this mean that with that bug > >>>>>you are referring to up here fixed by my last patch you have capture > >>>>>working? > >>>>No, capture still not working for me on SabreSD, even after fixing > >>>>the bug in 476dec0 "media: ov5640: Add horizontal and vertical totals", > >>>>by either using your patchset, or by running version 476dec0 of ov5640.c > >>>>with the call to ov5640_set_timings() moved to the correct places as > >>>>described below. > >>>> > >>>I've been reported a bug on exposure handling that makes the first > >>>captured frames all black. Both me and Hugues have tried to fix the > >>>issue (him with a more complete series, but that's another topic). > >>>See [1] and [2] > >>> > >>>It might be possible that you're getting blank frames with this series > >>>applied? I never seen them as I'm skipping the first frames when > >>>capturing, but I've now tested and without the exposure fixes (either > >>>[1] or [2]) I actually have blank frames. > >>> > >>>If that's the case for you too (which I hope so much) would you be > >>>available to test again this series with exposure fixes on top? > >>>On my platform that actually makes all frames correct. > >>> > >>>Thanks > >>>j > >>> > >>>[1] [PATCH 0/2] media: ov5640: Fix set_timings and auto-exposure > >>>[2] [PATCH v2 0/5] Fix OV5640 exposure & gain > >>> > >>It's not clear to me which patch sets you would like me to test. > >>Just [1] and [2], or [1], [2], and "media: i2c: ov5640: Re-work MIPI startup > >>sequence"? > >> > >I have tested on my board the following: > >v4.18-rc2 + MIPI Fix + Timings + Hugues' exposure fix > > > >Without Hugues' patches I get blank frames (the first ones at least) > >Without MIPI startup reowkr and timings I get the LP-11 error on the > >CSI-2 bus. > > > >As Hugues' series has to be rebased on mine, I have prepared a branch > >here for you if you feel like testing it: > >git://jmondi.org/linux ov5640/timings_exposure > > Hi Jacopo, that branch works on SabreSD! > YEAH! I'm so happy about this (and not to having asked you to test yet-another-broken-patchset for no reason :) > Feel free to add > > Tested-by: Steve Longerbeam > on i.MX6q SabreSD with MIPI CSI-2 OV5640 module > > to whichever ov5640 patches are appropriate. Great, I'll send a v3 now collecting your tags and the most recent version of the timings fix that was not included in v2 (but in the branch you have tested). My ideal plan would be to have these two patches merged, then Hugues' series to fix exposure handling merged on top. This would, in my mind make capture on CSI-2 work properly. Of course, more testing is very welcome. Thanks again j > > Steve > > signature.asc Description: PGP signature
Re: [PATCH v2 0/2] media: i2c: ov5640: Re-work MIPI startup sequence
Hi Steve, On Tue, Aug 14, 2018 at 09:51:04AM -0700, Steve Longerbeam wrote: > Hi Jacopo, > > > On 08/14/2018 08:35 AM, jacopo mondi wrote: > >Hi Steve, > >sorry for resurecting this. > > > > > >>>I'm sorry I'm not sur I'm following. Does this mean that with that bug > >>>you are referring to up here fixed by my last patch you have capture > >>>working? > >>No, capture still not working for me on SabreSD, even after fixing > >>the bug in 476dec0 "media: ov5640: Add horizontal and vertical totals", > >>by either using your patchset, or by running version 476dec0 of ov5640.c > >>with the call to ov5640_set_timings() moved to the correct places as > >>described below. > >> > >I've been reported a bug on exposure handling that makes the first > >captured frames all black. Both me and Hugues have tried to fix the > >issue (him with a more complete series, but that's another topic). > >See [1] and [2] > > > >It might be possible that you're getting blank frames with this series > >applied? I never seen them as I'm skipping the first frames when > >capturing, but I've now tested and without the exposure fixes (either > >[1] or [2]) I actually have blank frames. > > > >If that's the case for you too (which I hope so much) would you be > >available to test again this series with exposure fixes on top? > >On my platform that actually makes all frames correct. > > > >Thanks > >j > > > >[1] [PATCH 0/2] media: ov5640: Fix set_timings and auto-exposure > >[2] [PATCH v2 0/5] Fix OV5640 exposure & gain > > > > It's not clear to me which patch sets you would like me to test. > Just [1] and [2], or [1], [2], and "media: i2c: ov5640: Re-work MIPI startup > sequence"? > I have tested on my board the following: v4.18-rc2 + MIPI Fix + Timings + Hugues' exposure fix Without Hugues' patches I get blank frames (the first ones at least) Without MIPI startup reowkr and timings I get the LP-11 error on the CSI-2 bus. As Hugues' series has to be rebased on mine, I have prepared a branch here for you if you feel like testing it: git://jmondi.org/linux ov5640/timings_exposure Thanks j > Steve > > > signature.asc Description: PGP signature
Re: [PATCH 2/2] media: ov5640: Fix auto-exposure disabling
Hi Hugues,
On Tue, Aug 07, 2018 at 08:53:23AM +, Hugues FRUCHET wrote:
> Hi Jacopo,
>
> In serie "[PATCH 0/5] Fix OV5640 exposure & gain"
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg133269.html
> I've tried to collect fixes around exposure/gain, not only the exposure
> regression and I would prefer to keep it consistent with the associated
> procedure test.
You're right. Please see my other reply, I mixed two different issues
in this series probably.
> Moreover I dislike the internal use of control framework functions to
> disable/enable exposure/gain, on my opinion this has to be kept simpler
> by just disabling/enabling the right registers.
Why that? I thought changing parameters exposed as controls should go
through the control framework to ensure consistency. Maybe I'm wrong.
> Would it be possible that you test my 5 patches serie on your side ?
I did. I re-based the series on top of my MIPI and timings fixes and
it actually solves the exposure issues I didn't know I had :)
I'll comment on v2 as well as soon as I'll get an answer from Steve on
the CSI-2 issue.
Thanks
j
>
> Best regards,
> Hugues.
>
> On 07/18/2018 03:04 PM, jacopo mondi wrote:
> > Hi again,
> >
> > On Wed, Jul 18, 2018 at 01:19:03PM +0200, Jacopo Mondi wrote:
> >> As of:
> >> commit bf4a4b518c20 ("media: ov5640: Don't force the auto exposure state at
> >> start time") auto-exposure got disabled before programming new capture
> >> modes to
> >> the sensor. Unfortunately the function used to do that
> >> (ov5640_set_exposure())
> >> does not enable/disable auto-exposure engine through register 0x3503[0]
> >> bit, but
> >> programs registers [0x3500 - 0x3502] which represent the desired exposure
> >> time
> >> when running with manual exposure. As a result, auto-exposure was not
> >> actually
> >> disabled at all.
> >>
> >> To actually disable auto-exposure, go through the control framework
> >> instead of
> >> calling ov5640_set_exposure() function directly.
> >>
> >> Also, as auto-gain and auto-exposure are disabled un-conditionally but only
> >> restored to their previous values in ov5640_set_mode_direct() function,
> >> move
> >> controls restoring so that their value is re-programmed opportunely after
> >> either ov5640_set_mode_direct() or ov5640_set_mode_exposure_calc() have
> >> been
> >> executed.
> >>
> >> Fixes: bf4a4b518c20 ("media: ov5640: Don't force the auto exposure state
> >> at start time")
> >> Signed-off-by: Jacopo Mondi
> >>
> >> ---
> >> Is it worth doing with auto-gain what we're doing with auto-exposure?
> >> Cache the
> >> value and then re-program it instead of unconditionally disable/enable it?
> >
> > I have missed this patch from Hugues that address almost the same
> > issue
> > https://www.mail-archive.com/linux-media@vger.kernel.org/msg133264.html
> >
> > I feel this new one is simpler, and unless we want to avoid going
> > through the control framework, it is not worth adding new functions to
> > handle auto-exposure as Hugues' patch is doing.
> >
> > Hugues, do you have comments? Feel free to add your sob or rb tags if
> > you like to.
> >
> > Thanks
> > j
> >
> >>
> >> Thanks
> >>j
> >> ---
> >> ---
> >> drivers/media/i2c/ov5640.c | 29 +
> >> 1 file changed, 13 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> >> index 12b3496..bc75cb7 100644
> >> --- a/drivers/media/i2c/ov5640.c
> >> +++ b/drivers/media/i2c/ov5640.c
> >> @@ -1588,25 +1588,13 @@ static int ov5640_set_mode_exposure_calc(struct
> >> ov5640_dev *sensor,
> >>* change mode directly
> >>*/
> >> static int ov5640_set_mode_direct(struct ov5640_dev *sensor,
> >> -const struct ov5640_mode_info *mode,
> >> -s32 exposure)
> >> +const struct ov5640_mode_info *mode)
> >> {
> >> - int ret;
> >> -
> >>if (!mode->reg_data)
> >>return -EINVAL;
> >>
> >>/* Write capture setting */
> >> - ret = ov5640_load_regs(sensor, mode);
> >> - if (ret < 0)
> >> - return ret;
> >> -
> >> - /* turn auto g
Re: [PATCH 1/2] media: ov5640: Fix timings setup code
Hi Hugues, I'll reply to your v2 series shortly, but let me point out one thing before. +steve On Tue, Aug 07, 2018 at 08:53:53AM +, Hugues FRUCHET wrote: > Hi Jacopo, > > Thanks for this patch, when testing on my side I don't see special > regression or enhancement with that fix, particularly on image quality > (exposure, ...), On imx.6 platforms I need this patch along with the MIPI interface setup fixes sent here [1] to have capture working. I messed up a bit, as I've sent the "timings fixes" in two series, this one I'm replying to and the one I've pasted the link of, even if those series had two different purposes. So, this patch in my setup does not fixes an image quality issues, but instead takes part in solving a problems with MIPI CSI-2 on imx.6 platforms. I asked Steve Longerbeam to test on his imx.6 platform and he reported his issues was not fixed and he got blank frames ( I was very disappointed by the different results we had, but moved on and kept carrying those patches in my tree, as otherwise MIPI interface failed to startup). Now I have asked Steve if he might have blank frames, which might be an exposure related issue, I never had as I skept the first frames, which are usually the blank one (you're cc-ed). I believe too your exposure+gain series should be applied and should supersed [2/2] of this series, but this timing fix is necessary for me, and I hope Steve's problem are related to exposure handling issues your series might fix as it did for me. > do you have a test procedure that underline the issue ? > For example on my side when I do 5Mp then QVGA capture, pictures are > overexposed/greenish: I do capture with yavta, I usually skept the first 7 frames and then captured 3. Without exposure fix (my patch or your series) the first frames are black. This driver is making our life miserable, isn't it? :) Thanks j [1] https://www.spinics.net/lists/linux-media/msg137557.html signature.asc Description: PGP signature
Re: [PATCH v2 0/2] media: i2c: ov5640: Re-work MIPI startup sequence
Hi Steve, sorry for resurecting this. On Mon, Jul 16, 2018 at 09:26:13AM -0700, Steve Longerbeam wrote: > > > On 07/16/2018 01:29 AM, jacopo mondi wrote: > >Hi Steve, > >thanks for keep testing it > > > >On Sat, Jul 14, 2018 at 01:02:32PM -0700, Steve Longerbeam wrote: > >> > >>On 07/14/2018 12:41 PM, Steve Longerbeam wrote: > >>>Hi Jacopo, > >>> > >>> > >>>On 07/14/2018 11:57 AM, Steve Longerbeam wrote: > >>>>Hi Jacopo, > >>>> > >>>>Pardon the late reply, see below. > >>>> > >>>>On 07/11/2018 12:21 AM, jacopo mondi wrote: > >>>>>Hi Steve, > >>>>> > >>>>>On Tue, Jul 10, 2018 at 02:10:54PM -0700, Steve Longerbeam wrote: > >>>>>>Hi Jacopo, > >>>>>> > >>>>>>Sorry to report my testing on SabreSD has same result > >>>>>>as last time. This series fixes the LP-11 timeout at stream > >>>>>>on but captured images are still blank. I tried the 640x480 > >>>>>>mode with UYVY2X8. Here is the pad config: > >>>>>This saddens me :( > >>>>> > >>>>>I'm capturing with the same format and sizes... this shouldn't be the > >>>>>issue > >>>>> > >>>>>Could you confirm this matches what you have in your tree? > >>>>>5dc2c80 media: ov5640: Fix timings setup code > >>>>>b35e757 media: i2c: ov5640: Re-work MIPI startup sequence > >>>>>3c4a737 media: ov5640: fix frame interval enumeration > >>>>>41cb1c7 media: ov5640: adjust xclk_max > >>>>>c3f3ba3 media: ov5640: add support of module orientation > >>>>>ce85705 media: ov5640: add HFLIP/VFLIP controls support > >>>>>8663341 media: ov5640: Program the visible resolution > >>>>>476dec0 media: ov5640: Add horizontal and vertical totals > >>>>>dba13a0 media: ov5640: Change horizontal and vertical resolutions name > >>>>>8f57c2f media: ov5640: Init properly the SCLK dividers > >>>>Yes, I have that commit sequence. > >>>> > >>>>FWIW, I can verify what Jagan Teki reported earlier, that the driver > >>>>still > >>>>works on the SabreSD platform at: > >>>> > >>>>dba13a0 media: ov5640: Change horizontal and vertical resolutions name > >>>> > >>>>and is broken at: > >>>> > >>>>476dec0 media: ov5640: Add horizontal and vertical totals > >>>> > >>>>with LP-11 timeout at the mipi csi-2 receiver: > >>>> > >>>>[ 80.763189] imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0230 > >>>>[ 80.769599] ipu1_csi1: pipeline start failed with -110 > >>>And I discovered the bug in 476dec0 "media: ov5640: Add horizontal and > >>>vertical totals". The call to ov5640_set_timings() needs to be moved > >>>before the > >>>calls to ov5640_get_vts() and ov5640_get_hts(). But I see you have > >>>discovered > >>>that as well, and fixed in the second patch in your series. > >>> > >I'm sorry I'm not sur I'm following. Does this mean that with that bug > >you are referring to up here fixed by my last patch you have capture > >working? > > No, capture still not working for me on SabreSD, even after fixing > the bug in 476dec0 "media: ov5640: Add horizontal and vertical totals", > by either using your patchset, or by running version 476dec0 of ov5640.c > with the call to ov5640_set_timings() moved to the correct places as > described below. > I've been reported a bug on exposure handling that makes the first captured frames all black. Both me and Hugues have tried to fix the issue (him with a more complete series, but that's another topic). See [1] and [2] It might be possible that you're getting blank frames with this series applied? I never seen them as I'm skipping the first frames when capturing, but I've now tested and without the exposure fixes (either [1] or [2]) I actually have blank frames. If that's the case for you too (which I hope so much) would you be available to test again this series with exposure fixes on top? On my platform that actually makes all frames correct. Thanks j [1] [PATCH 0/2] media: ov5640: Fix set_timings and auto-exposure [2] [PATCH v2 0/5] Fix OV5640 exposure & gain > Steve > > >>But strangely, if I revert to 476dec0, and then move the call to > >>ov5640_set_timings() > >>to just after ov5640_load_regs() in ov5640_set_mode_exposure_calc() and > >>ov5640_set_mode_direct(), the LP-11 timeouts are still present. So I can > >>confirm > >>this strangeness which you already pointed out below [1]. > >> > >> > >>>>>>>The version I'm sending here re-introduces some of the timings > >>>>>>>parameters in the > >>>>>>>initial configuration blob (not in the single mode ones), which > >>>>>>>apparently has > >>>>>>>to be at least initially programmed to allow the driver to later > >>>>>>>program them > >>>>>>>singularly in the 'set_timings()' function. Unfortunately I do not > >>>>>>>have a real > >>>>>>>rationale behind this which explains why it has to be done this > >>>>>>>way :( > >>>>>>> > >>[1] here :) > >> > >>Steve > >> > >> > signature.asc Description: PGP signature
Re: [PATCH v1 4/5] [media] i2c: drop soc_camera code from ov9640 and switch to v4l2_async
Hi Petr,
On Sun, Aug 12, 2018 at 03:13:39PM +0200, Petr Cvek wrote:
> Dne 10.8.2018 v 09:51 jacopo mondi napsal(a):
> > Hi Petr,
> >
> > On Thu, Aug 09, 2018 at 03:39:48AM +0200, petrcve...@gmail.com wrote:
> >> From: Petr Cvek
> >>
> >> This patch removes the dependency on an obsoleted soc_camera from ov9640
> >> driver and changes the code to be a standalone v4l2 async subdevice.
> >> It also adds GPIO allocations for power and reset signals (as they are not
> >> handled by soc_camera now).
> >>
> >> The patch should make ov9640 again compatible with the pxa_camera driver.
> >
> > Are there board files using this driverin mainline ? (git grep says so)
> > Care to port them to use the new driver if necessary? You can have a
> > look at the SH4 Migo-R board, which recently underwent the same
> > process (arch/sh/boards/mach-migor/setup.c)
> >
>
> Yes there are Magician and Palm Zire72 which are directly using ov9640
> (and few others which are using pxa_camera with a different sensor). I'm
> working on HTC magician (pxa_camera is not a soc_camera subdev anymore,
> ov9640 still is).
>
> > I also suggest to adjust the build system in a single patch with this
> > changes, but that's not a big deal...
> >
>
> OK (at the end of the patchset I suppose?)
>
When I did the same soc_camera removal process on other drivers, I
adjusted the build system in the same patch that removed soc_camera
dependencies in the driver.
The process looked like:
01: copy the driver from drivers/media/i2c/soc_camera to
drivers/media/i2c/
02: Remove soc_camera dependencies from the driver and adjust
drivers/media/i2c/Kconfg drivers/media/i2c/Makefile accordingly
03: Port existing users of the soc_camera driver to use the new one
I guess patch ordering is not a big deal though ;)
Thanks
j
> >
> >> + ret = v4l2_clk_enable(priv->clk);
> >
> > Is this required by the pxa camera driver using v4l2_clk_ APIs?
> > Otherwise you should use the clk API directly.
> >
>
> Yes the clock is registered by pxa camera with v4l2_clk_register(). I
> will probably get to that in the future, but there is stuff (bugs, dead
> code from soc_camera removal, ...) with more priority in the driver for now.
>
>
> >> + mdelay(1);
> >> + gpiod_set_value(priv->gpio_reset, 0);
> >> + } else {
> >> + gpiod_set_value(priv->gpio_reset, 1);
> >> + mdelay(1);
> >> + v4l2_clk_disable(priv->clk);
> >> + mdelay(1);
> >> + gpiod_set_value(priv->gpio_power, 0);
> >> + }
> >> + return ret;
> >> }
> >>
> >> /* select nearest higher resolution for capture */
> >> @@ -631,14 +648,10 @@ static const struct v4l2_subdev_core_ops
> >> ov9640_core_ops = {
> >> static int ov9640_g_mbus_config(struct v4l2_subdev *sd,
> >>struct v4l2_mbus_config *cfg)
> >
> > g_mbus/s_mbus are deprecated. Unless the pxa camera driver wants them
> > all format negotiation should go through s_fmt/g_fmt pad operations
> >
>
> Yeah it does:
>
> ret = sensor_call(pcdev, video, g_mbus_config, );
>
>
> >> {
> >> - struct i2c_client *client = v4l2_get_subdevdata(sd);
> >> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> >> -
> >>cfg->flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
> >>V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
> >>V4L2_MBUS_DATA_ACTIVE_HIGH;
> >>cfg->type = V4L2_MBUS_PARALLEL;
> >> - cfg->flags = soc_camera_apply_board_flags(ssdd, cfg);
> >>
> >>return 0;
> >> }
> >> @@ -667,18 +680,27 @@ static int ov9640_probe(struct i2c_client *client,
> >>const struct i2c_device_id *did)
> >> {
> >>struct ov9640_priv *priv;
> >> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> >>int ret;
> >>
> >> - if (!ssdd) {
> >> - dev_err(>dev, "Missing platform_data for driver\n");
> >> - return -EINVAL;
> >> - }
> >> -
> >> - priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> >> + priv = devm_kzalloc(>dev, sizeof(*priv),
> >> + GFP_KERNEL);
> >>if (!priv)
> >>return -ENOMEM;
> >>
> >> + priv->gpio_power = devm_gpiod_get(&
Re: [PATCH 00/21] V4L2 fwnode rework; support for default configuration
Hi Sakari, thanks for this nice rework On Mon, Jul 23, 2018 at 04:46:45PM +0300, Sakari Ailus wrote: > Hello everyone, > > I've long thought the V4L2 fwnode framework requires some work (it's buggy > and it does not adequately serve common needs). This set should address in > particular these matters: > > - Most devices support a particular media bus type but the V4L2 fwnode > framework was not able to use such information, but instead tried to > guess the bus type with varying levels of success while drivers > generally ignored the results. This patchset makes that possible --- > setting a bus type enables parsing configuration for only that bus. > Failing that check results in returning -ENXIO to be returned. > > - Support specifying default configuration. If the endpoint has no > configuration, the defaults set by the driver (as documented in DT > bindings) will prevail. Any available configuration will still be read > from the endpoint as one could expect. A common use case for this is > e.g. the number of CSI-2 lanes. Few devices support lane mapping, and > default 1:1 mapping is provided in absence of a valid default or > configuration read OF. > > - Debugging information is greatly improved. > > - Recognition of the differences between CSI-2 D-PHY and C-PHY. All > currently supported hardware (or at least drivers) is D-PHY only, so > this change is still easy. > > The smiapp driver is converted to use the new functionality. This patchset > does not address remaining issues such as supporting setting defaults for > e.g. bridge drivers with multiple ports, but with Steve Longerbeam's > patchset we're much closer with that goal. I've rebased this set on top of > Steve's. Albeit the two deal with the same files, there were only a few > trivial conflicts. > > Note that I've only tested parsing endpoints for the CSI-2 bus (no > parallel IF hardware). Testing in general would be beneficial: the code > flows are rather convoluted and different hardware tends to excercise > different flows while the use of the use of defaults has a similar > effect. > I have tested on a parallel device, and so far it's all good. I would like to test default settings next, and see how they behave. > Comments are welcome. > In the meantine, looking at your (anticipated) v2, and in particular to this commit https://git.linuxtv.org/sailus/media_tree.git/commit/?h=v4l2-fwnode-next=077d73a3e1b66f9fbb1227245b1332cc1c7871d4 I'm wondering if introducing an API to query the bus type from the firmware wouldn't be beneficial for bridge drivers (and possibly for sensor drivers too). I see in that commit most drivers will set the bus type to 0 and rely on autoguessing, which is fine, but I'm thinking at peripheral that can support two different media busses (eg. Parallel and BT.656) or sensor that can work with parallel or CSI-2 interface, and in that case would you consider something like: static int bridge_driver_parse_of(struct device_node *np): struct v4l2_fwnode_endpoint bus_cfg ; bus_type = v4l2_fwnode_get_bus_type(fwnode_handle(np); if (bus_type != V4L2_MBUS_PARALLEL && bus_type != V4L2_MBUS_BT656) return -ENXIO; bus_cfg.bus_type = bus_type; v4l2_fwnode_endpoint_parse(of_fwnode_handle(np), _cfg); Adding a function to retrieve the bus type specified in firmware would make easier for drivers to check if the configuration is acceptable (as this is a device specific decision) and use this information later to provide to v4l2_fwnode_endpoint_parse() a v4l2_fwnode_endpoint with the bus_type initialized, so it does not need to rely on autoguessing. Otherwise, if I got this right, the only way not to go with autoguessing is to restrict the supported media bus type to a single one, which for some devices is a limitation. Does this makes sense to you? Thanks j > I've pushed the patches (including Steve's) here: > > https://git.linuxtv.org/sailus/media_tree.git/log/?h=v4l2-fwnode> > > Sakari Ailus (21): > v4l: fwnode: Add debug prints for V4L2 endpoint property parsing > v4l: fwnode: Use fwnode_graph_for_each_endpoint > v4l: fwnode: Detect bus type correctly > v4l: fwnode: The CSI-2 clock is continuous if it's not non-continuous > dt-bindings: media: Specify bus type for MIPI D-PHY, others, > explicitly > v4l: fwnode: Add definitions for CSI-2 D-PHY, parallel and Bt.656 > busses > v4l: mediabus: Recognise CSI-2 D-PHY and C-PHY > v4l: fwnode: Make use of newly specified bus types > v4l: fwnode: Read lane inversion information despite lane numbering > v4l: fwnode: Only assign configuration if there is no error > v4l: fwnode: Support driver-defined lane mapping defaults > v4l: fwnode: Support default CSI-2 lane mapping for drivers > v4l: fwnode: Parse the graph endpoint as last > v4l: fwnode: Use default parallel flags > v4l: fwnode: Allow setting default parameters > v4l: fwnode: Use media bus
Re: [PATCH v1 4/5] [media] i2c: drop soc_camera code from ov9640 and switch to v4l2_async
Hi Petr,
On Thu, Aug 09, 2018 at 03:39:48AM +0200, petrcve...@gmail.com wrote:
> From: Petr Cvek
>
> This patch removes the dependency on an obsoleted soc_camera from ov9640
> driver and changes the code to be a standalone v4l2 async subdevice.
> It also adds GPIO allocations for power and reset signals (as they are not
> handled by soc_camera now).
>
> The patch should make ov9640 again compatible with the pxa_camera driver.
Are there board files using this driverin mainline ? (git grep says so)
Care to port them to use the new driver if necessary? You can have a
look at the SH4 Migo-R board, which recently underwent the same
process (arch/sh/boards/mach-migor/setup.c)
I also suggest to adjust the build system in a single patch with this
changes, but that's not a big deal...
>
> Signed-off-by: Petr Cvek
> ---
> drivers/media/i2c/ov9640.c | 76 ++
> drivers/media/i2c/ov9640.h | 2 +
> 2 files changed, 55 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/media/i2c/ov9640.c b/drivers/media/i2c/ov9640.c
> index c63948989688..44129c60c524 100644
> --- a/drivers/media/i2c/ov9640.c
> +++ b/drivers/media/i2c/ov9640.c
> @@ -9,6 +9,7 @@
> * Kuninori Morimoto
> *
> * Based on ov7670 and soc_camera_platform driver,
> + * transition from soc_camera to pxa_camera based on mt9m111
> *
> * Copyright 2006-7 Jonathan Corbet
> * Copyright (C) 2008 Magnus Damm
While at there, drop the license text and add SPDX identifier please
> @@ -27,10 +28,14 @@
> #include
> #include
>
> -#include
> +#include
> #include
> #include
> #include
> +#include
> +#include
> +
> +#include
>
> #include "ov9640.h"
>
> @@ -323,11 +328,23 @@ static int ov9640_set_register(struct v4l2_subdev *sd,
>
> static int ov9640_s_power(struct v4l2_subdev *sd, int on)
> {
> - struct i2c_client *client = v4l2_get_subdevdata(sd);
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> struct ov9640_priv *priv = to_ov9640_sensor(sd);
> -
> - return soc_camera_set_power(>dev, ssdd, priv->clk, on);
> + int ret = 0;
> +
> + if (on) {
> + gpiod_set_value(priv->gpio_power, 1);
> + mdelay(1);
mdelay() is backed by a busy-waiting loop, according to
timers-howto.txt and for milliseconds-long sleeps is not suggested.
Please try to quantify the required delay and use msleep_range().
> + ret = v4l2_clk_enable(priv->clk);
Is this required by the pxa camera driver using v4l2_clk_ APIs?
Otherwise you should use the clk API directly.
> + mdelay(1);
> + gpiod_set_value(priv->gpio_reset, 0);
> + } else {
> + gpiod_set_value(priv->gpio_reset, 1);
> + mdelay(1);
> + v4l2_clk_disable(priv->clk);
> + mdelay(1);
> + gpiod_set_value(priv->gpio_power, 0);
> + }
> + return ret;
> }
>
> /* select nearest higher resolution for capture */
> @@ -631,14 +648,10 @@ static const struct v4l2_subdev_core_ops
> ov9640_core_ops = {
> static int ov9640_g_mbus_config(struct v4l2_subdev *sd,
> struct v4l2_mbus_config *cfg)
g_mbus/s_mbus are deprecated. Unless the pxa camera driver wants them
all format negotiation should go through s_fmt/g_fmt pad operations
> {
> - struct i2c_client *client = v4l2_get_subdevdata(sd);
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> -
> cfg->flags = V4L2_MBUS_PCLK_SAMPLE_RISING | V4L2_MBUS_MASTER |
> V4L2_MBUS_VSYNC_ACTIVE_HIGH | V4L2_MBUS_HSYNC_ACTIVE_HIGH |
> V4L2_MBUS_DATA_ACTIVE_HIGH;
> cfg->type = V4L2_MBUS_PARALLEL;
> - cfg->flags = soc_camera_apply_board_flags(ssdd, cfg);
>
> return 0;
> }
> @@ -667,18 +680,27 @@ static int ov9640_probe(struct i2c_client *client,
> const struct i2c_device_id *did)
> {
> struct ov9640_priv *priv;
> - struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
> int ret;
>
> - if (!ssdd) {
> - dev_err(>dev, "Missing platform_data for driver\n");
> - return -EINVAL;
> - }
> -
> - priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
> + priv = devm_kzalloc(>dev, sizeof(*priv),
> + GFP_KERNEL);
> if (!priv)
> return -ENOMEM;
>
> + priv->gpio_power = devm_gpiod_get(>dev, "Camera power",
> + GPIOD_OUT_LOW);
> + if (IS_ERR_OR_NULL(priv->gpio_power)) {
> + ret = PTR_ERR(priv->gpio_power);
> + return ret;
> + }
> +
> + priv->gpio_reset = devm_gpiod_get(>dev, "Camera reset",
> + GPIOD_OUT_HIGH);
> + if (IS_ERR_OR_NULL(priv->gpio_reset)) {
> + ret = PTR_ERR(priv->gpio_reset);
> + return ret;
> + }
> +
> v4l2_i2c_subdev_init(>subdev, client, _subdev_ops);
>
>
Re: [PATCH v1 1/5] [media] soc_camera: ov9640: move ov9640 out of soc_camera
Hi Petr,
thanks for the patches,
On Thu, Aug 09, 2018 at 03:39:45AM +0200, petrcve...@gmail.com wrote:
> From: Petr Cvek
>
> Initial part of ov9640 transition from soc_camera subsystem to a standalone
> v4l2 subdevice.
>
> Signed-off-by: Petr Cvek
> ---
> drivers/media/i2c/{soc_camera => }/ov9640.c | 0
> drivers/media/i2c/{soc_camera => }/ov9640.h | 0
> 2 files changed, 0 insertions(+), 0 deletions(-)
> rename drivers/media/i2c/{soc_camera => }/ov9640.c (100%)
> rename drivers/media/i2c/{soc_camera => }/ov9640.h (100%)
>
> diff --git a/drivers/media/i2c/soc_camera/ov9640.c
> b/drivers/media/i2c/ov9640.c
> similarity index 100%
> rename from drivers/media/i2c/soc_camera/ov9640.c
> rename to drivers/media/i2c/ov9640.c
> diff --git a/drivers/media/i2c/soc_camera/ov9640.h
> b/drivers/media/i2c/ov9640.h
> similarity index 100%
> rename from drivers/media/i2c/soc_camera/ov9640.h
> rename to drivers/media/i2c/ov9640.h
When I've been recently doing the same for ov772x and other sensor
driver I've been suggested to first copy the driver into
drivers/media/i2c/ and leave the original soc_camera one there, so
they can be bulk removed or moved to staging. I'll let Hans confirm
this, as he's about to take care of this process.
Thanks
j
> --
> 2.18.0
>
signature.asc
Description: PGP signature
[PATCH] media: mt9v111: Fix build error with no VIDEO_V4L2_SUBDEV_API
The v4l2_subdev_get_try_format() function is only defined if the
VIDEO_V4L2_SUBDEV_API Kconfig option is enabled. Builds configured
without that symbol fails with:
drivers/media/i2c/mt9v111.c:801:10: error: implicit declaration of function
'v4l2_subdev_get_try_format';
Fix this by protecting the function call by testing for the right symbol.
Fixes: aab7ed1c ("media: i2c: Add driver for Aptina MT9V111")
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/mt9v111.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/mt9v111.c b/drivers/media/i2c/mt9v111.c
index da8f6ab..68fa39f 100644
--- a/drivers/media/i2c/mt9v111.c
+++ b/drivers/media/i2c/mt9v111.c
@@ -797,7 +797,7 @@ static struct v4l2_mbus_framefmt *__mt9v111_get_pad_format(
{
switch (which) {
case V4L2_SUBDEV_FORMAT_TRY:
-#if IS_ENABLED(CONFIG_MEDIA_CONTROLLER)
+#if IS_ENABLED(CONFIG_VIDEO_V4L2_SUBDEV_API)
return v4l2_subdev_get_try_format(>sd, cfg, pad);
#else
return >try_fmt;
--
2.7.4
Re: [ragnatech:media-tree 273/382] drivers/media/i2c/mt9v111.c:801:10: error: implicit declaration of function 'v4l2_subdev_get_try_format'; did you mean 'v4l2_subdev_notify_event'?
Hi Mauro,
On Sun, Aug 05, 2018 at 10:55:43AM -0300, Mauro Carvalho Chehab wrote:
> Em Sun, 5 Aug 2018 12:09:23 +0200
> jacopo mondi escreveu:
>
> > Hi Hans,
> >
> > On Sun, Aug 05, 2018 at 11:59:33AM +0200, Hans Verkuil wrote:
> > > On 08/05/2018 11:36 AM, jacopo mondi wrote:
> > > > On Sun, Aug 05, 2018 at 01:14:58AM +0800, kbuild test robot wrote:
> > > >> tree: git://git.ragnatech.se/linux media-tree
> > > >> head: 12f336c88090fb8004736fd4329184326a49673b
> > > >> commit: aab7ed1c392703604fbdc5bd5005dfb61a0b32f9 [273/382] media: i2c:
> > > >> Add driver for Aptina MT9V111
> > > >> config: x86_64-randconfig-x010-201831 (attached as .config)
> > > >> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> > > >> reproduce:
> > > >> git checkout aab7ed1c392703604fbdc5bd5005dfb61a0b32f9
> > > >> # save the attached .config to linux build tree
> > > >> make ARCH=x86_64
> > > >>
> > > >> All error/warnings (new ones prefixed by >>):
> > > >>
> > > >>drivers/media/i2c/mt9v111.c: In function '__mt9v111_get_pad_format':
> > > >>>> drivers/media/i2c/mt9v111.c:801:10: error: implicit declaration of
> > > >>>> function 'v4l2_subdev_get_try_format'; did you mean
> > > >>>> 'v4l2_subdev_notify_event'? [-Werror=implicit-function-declaration]
> > > >> return v4l2_subdev_get_try_format(>sd, cfg, pad);
> > > >> ^~
> > > >
> > > > I have received this notification a few times now, and it comes from
> > > > the test build being run a kernel configured without the
> > > > CONFIG_VIDEO_V4L2_SUBDEV_API symbol.
> > > >
> > > > The mt9v111 driver does not list CONFIG_VIDEO_V4L2_SUBDEV_API as a
> > > > Kconfig dependency and the option does not get selected by the config
> > > > generated by kbuild, I guess.
> > > >
> > > > Should I list CONFIG_VIDEO_V4L2_SUBDEV_API as an mt9v111 dependency
> > > > with an incremental patch?
> > >
> > > Yes please. While you're at it, I'm also getting this warning during the
> > > daily build:
> > >
> >
> > On a second thought, the issue here is thatv4l2_subdev_get_try_format() is
> > protected by:
> > #if IS_ENABLED(CONFIG_MEDIA_CONTROLLER)
> >
> > but that function is only defined if CONFIG_VIDEO_V4L2_SUBDEV_API is
> > enabled (see
> > https://elixir.bootlin.com/linux/latest/source/include/media/v4l2-subdev.h#L915)
> >
> > As the mt9v111 can work without VIDEO_V4L2_SUBDEV_API selected, I
> > would change the following bit, instead of listing V4L2_SUBDEV as a
> > Kconfig dependency:
> >
> > @@ -797,7 +797,7 @@ static struct v4l2_mbus_framefmt
> > *__mt9v111_get_pad_format(
> > {
> > switch (which) {
> > case V4L2_SUBDEV_FORMAT_TRY:
> > -#if IS_ENABLED(CONFIG_MEDIA_CONTROLLER)
> > +#if IS_ENABLED(CONFIG_VIDEO_V4L2_SUBDEV_API)
> > return v4l2_subdev_get_try_format(>sd, cfg, pad);
> > #else
> > return >try_fmt;
>
> Yeah, this is a way better!
>
I had that patch ready before Hans suggested to go with the other
solution, I'll send it anyhow and let you two decide which one to pick
:)
> Btw, if this is always the case, perhaps we could, instead, add a
> stub for v4l2_subdev_get_try_format() that would return >try_fmt.
>
Or if you want to wait until next week I can take care of this.
Thanks
j
> A patch for tvp5150 had the same issue (and it is also used outside
> subdev-based devices).
>
> Perhaps it is time to have stubs for things like that and get
> rid on those ugly ifs in the middle of the drivers.
>
> >
> > With you ack I'll send a patch, sorry but this will probably require another
> > pull request (or Mauro could collect it directly?)
> >
> >
> > > linux-git-x86_64: WARNINGS
> > >
> > > /home/hans/work/build/media-git/drivers/media/i2c/mt9v111.c: In function
> > > 'mt9v111_set_format':
> > > /home/hans/work/build/media-git/drivers/media/i2c/mt9v111.c:887:15:
> > > warning: 'idx' may be used uninitialized in this function
> > > [-Wmaybe-uninitialized]
> > > unsigned int idx;
> > >^~~
> > >
> > > There may be a patch for that already (I haven't checked), but if not,
> > > c
[PATCH] media: i2c: mt9v111: Add VIDEO_V4L2_SUBDEV_API dependency
Fix build error caused by the VIDEO_V4L2_SUBDEV_API symbol not being enabled
in Kconfig option by making the driver depend on it.
Builds configured without the VIDEO_V4L2_SUBDEV_API symbol fail with:
drivers/media/i2c/mt9v111.c:801:10: error: implicit declaration of function
'v4l2_subdev_get_try_format';
Fixes: aab7ed1c ("media: i2c: Add driver for Aptina MT9V111")
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 82af974..422c586 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -876,7 +876,7 @@ config VIDEO_MT9V032
config VIDEO_MT9V111
tristate "Aptina MT9V111 sensor support"
depends on I2C && VIDEO_V4L2
- depends on MEDIA_CAMERA_SUPPORT
+ depends on MEDIA_CAMERA_SUPPORT && VIDEO_V4L2_SUBDEV_API
help
This is a Video4Linux2 sensor driver for the Aptina/Micron
MT9V111 sensor.
--
2.7.4
Re: [ragnatech:media-tree 273/382] drivers/media/i2c/mt9v111.c:801:10: error: implicit declaration of function 'v4l2_subdev_get_try_format'; did you mean 'v4l2_subdev_notify_event'?
Hi Hans,
On Sun, Aug 05, 2018 at 11:59:33AM +0200, Hans Verkuil wrote:
> On 08/05/2018 11:36 AM, jacopo mondi wrote:
> > On Sun, Aug 05, 2018 at 01:14:58AM +0800, kbuild test robot wrote:
> >> tree: git://git.ragnatech.se/linux media-tree
> >> head: 12f336c88090fb8004736fd4329184326a49673b
> >> commit: aab7ed1c392703604fbdc5bd5005dfb61a0b32f9 [273/382] media: i2c: Add
> >> driver for Aptina MT9V111
> >> config: x86_64-randconfig-x010-201831 (attached as .config)
> >> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> >> reproduce:
> >> git checkout aab7ed1c392703604fbdc5bd5005dfb61a0b32f9
> >> # save the attached .config to linux build tree
> >> make ARCH=x86_64
> >>
> >> All error/warnings (new ones prefixed by >>):
> >>
> >>drivers/media/i2c/mt9v111.c: In function '__mt9v111_get_pad_format':
> >>>> drivers/media/i2c/mt9v111.c:801:10: error: implicit declaration of
> >>>> function 'v4l2_subdev_get_try_format'; did you mean
> >>>> 'v4l2_subdev_notify_event'? [-Werror=implicit-function-declaration]
> >> return v4l2_subdev_get_try_format(>sd, cfg, pad);
> >> ^~
> >
> > I have received this notification a few times now, and it comes from
> > the test build being run a kernel configured without the
> > CONFIG_VIDEO_V4L2_SUBDEV_API symbol.
> >
> > The mt9v111 driver does not list CONFIG_VIDEO_V4L2_SUBDEV_API as a
> > Kconfig dependency and the option does not get selected by the config
> > generated by kbuild, I guess.
> >
> > Should I list CONFIG_VIDEO_V4L2_SUBDEV_API as an mt9v111 dependency
> > with an incremental patch?
>
> Yes please. While you're at it, I'm also getting this warning during the
> daily build:
>
On a second thought, the issue here is thatv4l2_subdev_get_try_format() is
protected by:
#if IS_ENABLED(CONFIG_MEDIA_CONTROLLER)
but that function is only defined if CONFIG_VIDEO_V4L2_SUBDEV_API is
enabled (see
https://elixir.bootlin.com/linux/latest/source/include/media/v4l2-subdev.h#L915)
As the mt9v111 can work without VIDEO_V4L2_SUBDEV_API selected, I
would change the following bit, instead of listing V4L2_SUBDEV as a
Kconfig dependency:
@@ -797,7 +797,7 @@ static struct v4l2_mbus_framefmt *__mt9v111_get_pad_format(
{
switch (which) {
case V4L2_SUBDEV_FORMAT_TRY:
-#if IS_ENABLED(CONFIG_MEDIA_CONTROLLER)
+#if IS_ENABLED(CONFIG_VIDEO_V4L2_SUBDEV_API)
return v4l2_subdev_get_try_format(>sd, cfg, pad);
#else
return >try_fmt;
With you ack I'll send a patch, sorry but this will probably require another
pull request (or Mauro could collect it directly?)
> linux-git-x86_64: WARNINGS
>
> /home/hans/work/build/media-git/drivers/media/i2c/mt9v111.c: In function
> 'mt9v111_set_format':
> /home/hans/work/build/media-git/drivers/media/i2c/mt9v111.c:887:15: warning:
> 'idx' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> unsigned int idx;
>^~~
>
> There may be a patch for that already (I haven't checked), but if not, can
> you fix
> this too?
This has been fixed by a patch from Jasmin and pull request sent by
Sakari.
>
> I actually wondered if you shouldn't use the v4l2_find_nearest_size() helper
> for this
> (v4l2-common.h).
>
Possibly. I won't be able to look into that now and I'll be away
next week, so it might slip to the next cycle though.
Thanks
j
> Thanks,
>
> Hans
>
> >
> >> v4l2_subdev_notify_event
> >>>> drivers/media/i2c/mt9v111.c:801:10: warning: return makes pointer from
> >>>> integer without a cast [-Wint-conversion]
> >> return v4l2_subdev_get_try_format(>sd, cfg, pad);
> >> ^~
> >>drivers/media/i2c/mt9v111.c: In function 'mt9v111_set_format':
> >>drivers/media/i2c/mt9v111.c:887:15: warning: 'idx' may be used
> >> uninitialized in this function [-Wmaybe-uninitialized]
> >> unsigned int idx;
> >> ^~~
> >>cc1: some warnings being treated as errors
> >>
> >> vim +801 drivers/media/i2c/mt9v111.c
> >>
> >>791
> >>792 static struct v4l2_mbus_framefmt *__mt9v111_get_pad_format(
> >>793 struct mt9v111_dev
> >> *mt9v111,
> >>794 struct
> >> v4l2_subdev_pad_config *cfg,
> >>795 unsigned int
Re: [ragnatech:media-tree 273/382] drivers/media/i2c/mt9v111.c:801:10: error: implicit declaration of function 'v4l2_subdev_get_try_format'; did you mean 'v4l2_subdev_notify_event'?
On Sun, Aug 05, 2018 at 01:14:58AM +0800, kbuild test robot wrote:
> tree: git://git.ragnatech.se/linux media-tree
> head: 12f336c88090fb8004736fd4329184326a49673b
> commit: aab7ed1c392703604fbdc5bd5005dfb61a0b32f9 [273/382] media: i2c: Add
> driver for Aptina MT9V111
> config: x86_64-randconfig-x010-201831 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> git checkout aab7ed1c392703604fbdc5bd5005dfb61a0b32f9
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All error/warnings (new ones prefixed by >>):
>
>drivers/media/i2c/mt9v111.c: In function '__mt9v111_get_pad_format':
> >> drivers/media/i2c/mt9v111.c:801:10: error: implicit declaration of
> >> function 'v4l2_subdev_get_try_format'; did you mean
> >> 'v4l2_subdev_notify_event'? [-Werror=implicit-function-declaration]
> return v4l2_subdev_get_try_format(>sd, cfg, pad);
> ^~
I have received this notification a few times now, and it comes from
the test build being run a kernel configured without the
CONFIG_VIDEO_V4L2_SUBDEV_API symbol.
The mt9v111 driver does not list CONFIG_VIDEO_V4L2_SUBDEV_API as a
Kconfig dependency and the option does not get selected by the config
generated by kbuild, I guess.
Should I list CONFIG_VIDEO_V4L2_SUBDEV_API as an mt9v111 dependency
with an incremental patch?
> v4l2_subdev_notify_event
> >> drivers/media/i2c/mt9v111.c:801:10: warning: return makes pointer from
> >> integer without a cast [-Wint-conversion]
> return v4l2_subdev_get_try_format(>sd, cfg, pad);
> ^~
>drivers/media/i2c/mt9v111.c: In function 'mt9v111_set_format':
>drivers/media/i2c/mt9v111.c:887:15: warning: 'idx' may be used
> uninitialized in this function [-Wmaybe-uninitialized]
> unsigned int idx;
> ^~~
>cc1: some warnings being treated as errors
>
> vim +801 drivers/media/i2c/mt9v111.c
>
>791
>792static struct v4l2_mbus_framefmt *__mt9v111_get_pad_format(
>793struct mt9v111_dev
> *mt9v111,
>794struct
> v4l2_subdev_pad_config *cfg,
>795unsigned int pad,
>796enum
> v4l2_subdev_format_whence which)
>797{
>798switch (which) {
>799case V4L2_SUBDEV_FORMAT_TRY:
>800#if IS_ENABLED(CONFIG_MEDIA_CONTROLLER)
> > 801return v4l2_subdev_get_try_format(>sd,
> cfg, pad);
>802#else
>803return >try_fmt;
>804#endif
>805case V4L2_SUBDEV_FORMAT_ACTIVE:
>806return >fmt;
>807default:
>808return NULL;
>809}
>810}
>811
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
signature.asc
Description: PGP signature
[PATCH] media: i2c: mt9v111: Fix v4l2-ctrl error handling
Fix error handling of v4l2_ctrl creation by inspecting the ctrl.error flag
instead of testing for each returned value correctness.
As reported by Dan Carpenter returning PTR_ERR() on the v4l2_ctrl_new_std()
return value is also wrong, as that function return NULL on error.
While at there re-order the cleanup path to respect the operation inverse
order.
Fixes: aab7ed1c "media: i2c: Add driver for Aptina MT9V111"
Reported-by: Dan Carpenter
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/mt9v111.c | 41 +
1 file changed, 13 insertions(+), 28 deletions(-)
diff --git a/drivers/media/i2c/mt9v111.c b/drivers/media/i2c/mt9v111.c
index da8f6ab..2b87bf9 100644
--- a/drivers/media/i2c/mt9v111.c
+++ b/drivers/media/i2c/mt9v111.c
@@ -1159,41 +1159,21 @@ static int mt9v111_probe(struct i2c_client *client)
V4L2_CID_AUTO_WHITE_BALANCE,
0, 1, 1,
V4L2_WHITE_BALANCE_AUTO);
- if (IS_ERR_OR_NULL(mt9v111->auto_awb)) {
- ret = PTR_ERR(mt9v111->auto_awb);
- goto error_free_ctrls;
- }
-
mt9v111->auto_exp = v4l2_ctrl_new_std_menu(>ctrls,
_ctrl_ops,
V4L2_CID_EXPOSURE_AUTO,
V4L2_EXPOSURE_MANUAL,
0, V4L2_EXPOSURE_AUTO);
- if (IS_ERR_OR_NULL(mt9v111->auto_exp)) {
- ret = PTR_ERR(mt9v111->auto_exp);
- goto error_free_ctrls;
- }
-
- /* Initialize timings */
mt9v111->hblank = v4l2_ctrl_new_std(>ctrls, _ctrl_ops,
V4L2_CID_HBLANK,
MT9V111_CORE_R05_MIN_HBLANK,
MT9V111_CORE_R05_MAX_HBLANK, 1,
MT9V111_CORE_R05_DEF_HBLANK);
- if (IS_ERR_OR_NULL(mt9v111->hblank)) {
- ret = PTR_ERR(mt9v111->hblank);
- goto error_free_ctrls;
- }
-
mt9v111->vblank = v4l2_ctrl_new_std(>ctrls, _ctrl_ops,
V4L2_CID_VBLANK,
MT9V111_CORE_R06_MIN_VBLANK,
MT9V111_CORE_R06_MAX_VBLANK, 1,
MT9V111_CORE_R06_DEF_VBLANK);
- if (IS_ERR_OR_NULL(mt9v111->vblank)) {
- ret = PTR_ERR(mt9v111->vblank);
- goto error_free_ctrls;
- }
/* PIXEL_RATE is fixed: just expose it to user space. */
v4l2_ctrl_new_std(>ctrls, _ctrl_ops,
@@ -1201,6 +1181,10 @@ static int mt9v111_probe(struct i2c_client *client)
DIV_ROUND_CLOSEST(mt9v111->sysclk, 2), 1,
DIV_ROUND_CLOSEST(mt9v111->sysclk, 2));
+ if (mt9v111->ctrls.error) {
+ ret = mt9v111->ctrls.error;
+ goto error_free_ctrls;
+ }
mt9v111->sd.ctrl_handler = >ctrls;
/* Start with default configuration: 640x480 UYVY. */
@@ -1226,26 +1210,27 @@ static int mt9v111_probe(struct i2c_client *client)
mt9v111->pad.flags = MEDIA_PAD_FL_SOURCE;
ret = media_entity_pads_init(>sd.entity, 1, >pad);
if (ret)
- goto error_free_ctrls;
+ goto error_free_entity;
#endif
ret = mt9v111_chip_probe(mt9v111);
if (ret)
- goto error_free_ctrls;
+ goto error_free_entity;
ret = v4l2_async_register_subdev(>sd);
if (ret)
- goto error_free_ctrls;
+ goto error_free_entity;
return 0;
-error_free_ctrls:
- v4l2_ctrl_handler_free(>ctrls);
-
+error_free_entity:
#if IS_ENABLED(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(>sd.entity);
#endif
+error_free_ctrls:
+ v4l2_ctrl_handler_free(>ctrls);
+
mutex_destroy(>pwr_mutex);
mutex_destroy(>stream_mutex);
@@ -1259,12 +1244,12 @@ static int mt9v111_remove(struct i2c_client *client)
v4l2_async_unregister_subdev(sd);
- v4l2_ctrl_handler_free(>ctrls);
-
#if IS_ENABLED(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(>entity);
#endif
+ v4l2_ctrl_handler_free(>ctrls);
+
mutex_destroy(>pwr_mutex);
mutex_destroy(>stream_mutex);
--
2.7.4
Re: [bug report] media: i2c: Add driver for Aptina MT9V111
Hi Dan,
thanks for noticing this,
On Tue, Jul 31, 2018 at 09:35:54PM +0300, Dan Carpenter wrote:
> Hello Jacopo Mondi,
>
> The patch aab7ed1c3927: "media: i2c: Add driver for Aptina MT9V111"
> from Jul 25, 2018, leads to the following static checker warning:
>
> drivers/media/i2c/mt9v111.c:1163 mt9v111_probe() warn: passing zero to
> 'PTR_ERR'
> drivers/media/i2c/mt9v111.c:1173 mt9v111_probe() warn: passing zero to
> 'PTR_ERR'
> drivers/media/i2c/mt9v111.c:1184 mt9v111_probe() warn: passing zero to
> 'PTR_ERR'
> drivers/media/i2c/mt9v111.c:1194 mt9v111_probe() warn: passing zero to
> 'PTR_ERR'
>
> drivers/media/i2c/mt9v111.c
> 1155 v4l2_ctrl_handler_init(>ctrls, 5);
> 1156
> 1157 mt9v111->auto_awb = v4l2_ctrl_new_std(>ctrls,
> 1158_ctrl_ops,
> 1159
> V4L2_CID_AUTO_WHITE_BALANCE,
> 11600, 1, 1,
> 1161
> V4L2_WHITE_BALANCE_AUTO);
> 1162 if (IS_ERR_OR_NULL(mt9v111->auto_awb)) {
> 1163 ret = PTR_ERR(mt9v111->auto_awb);
>
> This just returns success because v4l2_ctrl_new_std() only return NULL
Correct, sorry, I didn't notice that.
> on error, it never returns error pointers. I guess we should set ret to
> EINVAL?
>
> if (!mt9v111->auto_awb) {
> ret = -EINVAL;
> goto error_free_ctrls;
> }
>
We can do even better than that.
The v4l2 control handler retains errors in a flag I can inspect after
having added/created all controls here and here below.
I can return that error flag if something goes wrong.
Thanks
j
> 1164 goto error_free_ctrls;
> 1165 }
> 1166
> 1167 mt9v111->auto_exp = v4l2_ctrl_new_std_menu(>ctrls,
> 1168 _ctrl_ops,
> 1169
> V4L2_CID_EXPOSURE_AUTO,
> 1170
> V4L2_EXPOSURE_MANUAL,
> 1171 0,
> V4L2_EXPOSURE_AUTO);
> 1172 if (IS_ERR_OR_NULL(mt9v111->auto_exp)) {
> 1173 ret = PTR_ERR(mt9v111->auto_exp);
> 1174 goto error_free_ctrls;
> 1175 }
> 1176
> 1177 /* Initialize timings */
> 1178 mt9v111->hblank = v4l2_ctrl_new_std(>ctrls,
> _ctrl_ops,
> 1179 V4L2_CID_HBLANK,
> 1180
> MT9V111_CORE_R05_MIN_HBLANK,
> 1181
> MT9V111_CORE_R05_MAX_HBLANK, 1,
> 1182
> MT9V111_CORE_R05_DEF_HBLANK);
> 1183 if (IS_ERR_OR_NULL(mt9v111->hblank)) {
> 1184 ret = PTR_ERR(mt9v111->hblank);
> 1185 goto error_free_ctrls;
> 1186 }
> 1187
> 1188 mt9v111->vblank = v4l2_ctrl_new_std(>ctrls,
> _ctrl_ops,
> 1189 V4L2_CID_VBLANK,
> 1190
> MT9V111_CORE_R06_MIN_VBLANK,
> 1191
> MT9V111_CORE_R06_MAX_VBLANK, 1,
> 1192
> MT9V111_CORE_R06_DEF_VBLANK);
> 1193 if (IS_ERR_OR_NULL(mt9v111->vblank)) {
> 1194 ret = PTR_ERR(mt9v111->vblank);
> 1195 goto error_free_ctrls;
> 1196 }
> 1197
> 1198 /* PIXEL_RATE is fixed: just expose it to user space. */
> 1199 v4l2_ctrl_new_std(>ctrls, _ctrl_ops,
>
> regards,
> dan carpenter
signature.asc
Description: PGP signature
Re: [PATCH] media: i2c: fix warning in Aptina MT9V111
Hi Jasmin, On Sat, Jul 28, 2018 at 03:54:49PM +0200, Jasmin J. wrote: > From: Jasmin Jessich > > This fixes the "'idx' may be used uninitialized in this function" > warning. > > Cc: Jacopo Mondi > Signed-off-by: Jasmin Jessich Thanks for the patch Acked-by: Jacopo Mondi Thanks j > --- > drivers/media/i2c/mt9v111.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/i2c/mt9v111.c b/drivers/media/i2c/mt9v111.c > index da8f6ab..58d5f22 100644 > --- a/drivers/media/i2c/mt9v111.c > +++ b/drivers/media/i2c/mt9v111.c > @@ -884,7 +884,7 @@ static int mt9v111_set_format(struct v4l2_subdev *subdev, > struct v4l2_mbus_framefmt new_fmt; > struct v4l2_mbus_framefmt *__fmt; > unsigned int best_fit = ~0L; > - unsigned int idx; > + unsigned int idx = 0; > unsigned int i; > > mutex_lock(>stream_mutex); > -- > 2.7.4 > signature.asc Description: PGP signature
Re: [PATCH 1/1] mt9v111: Fix compiler warning by initialising a variable
Hi Sakari, On Mon, Jul 30, 2018 at 10:26:27AM +0300, Sakari Ailus wrote: > While this isn't a bug, initialise the variable to quash the warning. > > Reported-by: Stephen Rothwell > Signed-off-by: Sakari Ailus > --- > drivers/media/i2c/mt9v111.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/i2c/mt9v111.c b/drivers/media/i2c/mt9v111.c > index da8f6ab91307..58d5f2224bff 100644 > --- a/drivers/media/i2c/mt9v111.c > +++ b/drivers/media/i2c/mt9v111.c > @@ -884,7 +884,7 @@ static int mt9v111_set_format(struct v4l2_subdev *subdev, > struct v4l2_mbus_framefmt new_fmt; > struct v4l2_mbus_framefmt *__fmt; > unsigned int best_fit = ~0L; > - unsigned int idx; > + unsigned int idx = 0; > unsigned int i; > Thanks for this, but there is already a patch sent on Friday by Jasmin addressing the warning https://patchwork.kernel.org/patch/10547983/ > mutex_lock(>stream_mutex); > -- > 2.11.0 > signature.asc Description: PGP signature
[v2 0/2] media: i2c: mt9v111 sensor driver
Hello, this is a sensor level driver for Aptina MT9V111. Compared to v1 the biggest difference is that now auto-exposure and auto-white-balancing are exposed through the v4l2-ctrl framework, and can be activated/deactivated by the user. For this reason, while auto-exposure algorithm still controls the frame rate in low light conditions, the driver now enables it by default and let the user disable it to more precisely control the framerate. (Most of the) comments from Sakari and Kieran have been addressed, see changelog for a more precise list. Tested VGA, QVGA QQVGA resolutions at 5, 10, 15 and 30 frame per second. v4l2-compliance fails on some tests, and I've not been able to identify what's wrong with the driver. Copy of the failures reported here below: fail: v4l2-test-subdevs.cpp(69): doioctl(node, VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL, ) != EINVAL fail: v4l2-test-subdevs.cpp(180): ret && ret != ENOTTY fail: v4l2-test-subdevs.cpp(248): ret && ret != ENOTTY test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: FAIL I've found no mention of ENOTTY to be reported by enum_frame_interval in the documentation, but apparently v4l2-compliance checks for that. v1: https://lkml.org/lkml/2018/6/11/467 Thanks j v1 -> v2: - Addressed syntax mistakes pointed out by Kieran - Drop spinlock around address space change - Extend mutex to cover frame rate and format get/set operations - Add controls for auto-exposure and auto-white-balancing - Move MAINTAINERS modifications to bindings patch - Fix resolution in bindings document - Drop dependency on OF - Drop subdev 'open' function in favour of pad operation init_cfg and use a default configuration to initialize the sensor - Turn off power if sensor identification fails Jacopo Mondi (2): dt-bindings: media: i2c: Document MT9V111 bindings media: i2c: Add driver for Aptina MT9V111 .../bindings/media/i2c/aptina,mt9v111.txt | 46 + MAINTAINERS|8 + drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/mt9v111.c| 1299 5 files changed, 1365 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt create mode 100644 drivers/media/i2c/mt9v111.c -- 2.7.4
[v2 1/2] dt-bindings: media: i2c: Document MT9V111 bindings
From: Jacopo Mondi
Add documentation for Aptina MT9V111 image sensor.
Reviewed-by: Rob Herring
Signed-off-by: Jacopo Mondi
---
.../bindings/media/i2c/aptina,mt9v111.txt | 46 ++
MAINTAINERS| 8
2 files changed, 54 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
new file mode 100644
index 000..bd896e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
@@ -0,0 +1,46 @@
+* Aptina MT9V111 CMOS sensor
+
+
+The Aptina MT9V111 is a 1/4-Inch VGA-format digital image sensor with a core
+based on Aptina MT9V011 sensor and an integrated Image Flow Processor (IFP).
+
+The sensor has an active pixel array of 640x480 pixels and can output a number
+of image resolution and formats controllable through a simple two-wires
+interface.
+
+Required properties:
+
+
+- compatible: shall be "aptina,mt9v111".
+- clocks: reference to the system clock input provider.
+
+Optional properties:
+
+
+- enable-gpios: output enable signal, pin name "OE#". Active low.
+- standby-gpios: low power state control signal, pin name "STANDBY".
+ Active high.
+- reset-gpios: chip reset signal, pin name "RESET#". Active low.
+
+The device node must contain one 'port' child node with one 'endpoint' child
+sub-node for its digital output video port, in accordance with the video
+interface bindings defined in:
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+
+ {
+camera@48 {
+compatible = "aptina,mt9v111";
+reg = <0x48>;
+
+clocks = <_clk>;
+
+port {
+mt9v111_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index bbd9b9b..4ab113c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9651,6 +9651,14 @@ F:
Documentation/devicetree/bindings/media/i2c/mt9v032.txt
F: drivers/media/i2c/mt9v032.c
F: include/media/i2c/mt9v032.h
+MT9V111 APTINA CAMERA SENSOR
+M: Jacopo Mondi
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
+F: drivers/media/i2c/mt9v111.c
+
MULTIFUNCTION DEVICES (MFD)
M: Lee Jones
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
--
2.7.4
[v2 2/2] media: i2c: Add driver for Aptina MT9V111
From: Jacopo Mondi Add V4L2 sensor driver for Aptina MT9V111 CMOS image sensor. The MT9V111 is a 1/4-Inch CMOS image sensor based on MT9V011 with an integrated Image Flow Processor. Reviewed-by: Kieran Bingham Signed-off-by: Jacopo Mondi --- drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/mt9v111.c | 1298 +++ 3 files changed, 1310 insertions(+) create mode 100644 drivers/media/i2c/mt9v111.c diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 8669853..b6fea81 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -861,6 +861,17 @@ config VIDEO_MT9V032 This is a Video4Linux2 sensor-level driver for the Micron MT9V032 752x480 CMOS sensor. +config VIDEO_MT9V111 + tristate "Aptina MT9V111 sensor support" + depends on I2C && VIDEO_V4L2 + depends on MEDIA_CAMERA_SUPPORT + help + This is a Video4Linux2 sensor driver for the Aptina/Micron + MT9V111 sensor. + + To compile this driver as a module, choose M here: the + module will be called mt9v111. + config VIDEO_SR030PC30 tristate "Siliconfile SR030PC30 sensor support" depends on I2C && VIDEO_V4L2 diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 837c428..ba9a1e4 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -86,6 +86,7 @@ obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o obj-$(CONFIG_VIDEO_MT9T112) += mt9t112.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o +obj-$(CONFIG_VIDEO_MT9V111) += mt9v111.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_RJ54N1) += rj54n1cb0c.o diff --git a/drivers/media/i2c/mt9v111.c b/drivers/media/i2c/mt9v111.c new file mode 100644 index 000..da8f6ab --- /dev/null +++ b/drivers/media/i2c/mt9v111.c @@ -0,0 +1,1298 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * V4L2 sensor driver for Aptina MT9V111 image sensor + * Copyright (C) 2018 Jacopo Mondi + * + * Based on mt9v032 driver + * Copyright (C) 2010, Laurent Pinchart + * Copyright (C) 2008, Guennadi Liakhovetski + * + * Based on mt9v011 driver + * Copyright (c) 2009 Mauro Carvalho Chehab + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +/* + * MT9V111 is a 1/4-Inch CMOS digital image sensor with an integrated + * Image Flow Processing (IFP) engine and a sensor core loosely based on + * MT9V011. + * + * The IFP can produce several output image formats from the sensor core + * output. This driver currently supports only YUYV format permutations. + * + * The driver allows manual frame rate control through s_frame_interval subdev + * operation or V4L2_CID_V/HBLANK controls, but it is known that the + * auto-exposure algorithm might modify the programmed frame rate. While the + * driver initially programs the sensor with auto-exposure and + * auto-white-balancing enabled, it is possible to disable them and more + * precisely control the frame rate. + * + * While it seems possible to instruct the auto-exposure control algorithm to + * respect a programmed frame rate when adjusting the pixel integration time, + * registers controlling this feature are not documented in the public + * available sensor manual used to develop this driver (09005aef80e90084, + * MT9V111_1.fm - Rev. G 1/05 EN). + */ + +#define MT9V111_CHIP_ID_HIGH 0x82 +#define MT9V111_CHIP_ID_LOW0x3a + +#define MT9V111_R01_ADDR_SPACE 0x01 +#define MT9V111_R01_IFP0x01 +#define MT9V111_R01_CORE 0x04 + +#define MT9V111_IFP_R06_OPMODE_CTRL0x06 +#defineMT9V111_IFP_R06_OPMODE_CTRL_AWB_EN BIT(1) +#defineMT9V111_IFP_R06_OPMODE_CTRL_AE_EN BIT(14) +#define MT9V111_IFP_R07_IFP_RESET 0x07 +#defineMT9V111_IFP_R07_IFP_RESET_MASK BIT(0) +#define MT9V111_IFP_R08_OUTFMT_CTRL0x08 +#defineMT9V111_IFP_R08_OUTFMT_CTRL_FLICKER BIT(11) +#defineMT9V111_IFP_R08_OUTFMT_CTRL_PCLKBIT(5) +#define MT9V111_IFP_R3A_OUTFMT_CTRL2 0x3a +#defineMT9V111_IFP_R3A_OUTFMT_CTRL2_SWAP_CBCR BIT(0) +#defineMT9V111_IFP_R3A_OUTFMT_CTRL2_SWAP_YCBIT(1) +#defineMT9V111_IFP_R3A_OUTFMT_CTRL2_SWAP_MASK GENMASK(2, 0) +#define MT9V111_IFP_RA5_HPAN 0xa5 +#define MT9V111_IFP_RA6_HZOOM 0xa6 +#define MT9V111_IFP_RA7_HOUT 0xa7 +#define MT9V111_IFP_RA8_VPAN
Re: [GIT PULL FOR v4.19] Various fixes
Hi Mauro, I understand, and I failed to cc the SH people initially. Roping in Sato-san, Rich and the SH list. Could you guys please have a look here? I've gone through the media tree as all these changes sparkled from soc_camera removal, and while I was there I updated the defconfigs before enabling CEU and disabling soc_camera. How long before we miss v4.19 Mauro? Thanks j On Tue, Jul 24, 2018 at 07:04:13PM -0300, Mauro Carvalho Chehab wrote: > Em Wed, 18 Jul 2018 12:38:58 +0200 > Hans Verkuil escreveu: > > > Hi Mauro, > > > > Various fixes. Please note that I re-added the 'Add support for STD ioctls > > on subdev nodes' > > patch. It really is needed. > > > > Regards, > > > > Hans > > > > > Jacopo Mondi (9): > > sh: defconfig: migor: Update defconfig > > sh: defconfig: migor: Enable CEU and sensor drivers > > sh: defconfig: ecovec: Update defconfig > > sh: defconfig: ecovec: Enable CEU and video drivers > > sh: defconfig: se7724: Update defconfig > > sh: defconfig: se7724: Enable CEU and sensor driver > > sh: defconfig: ap325rxa: Update defconfig > > sh: defconfig: ap325rxa: Enable CEU and sensor driver > > I didn't apply the above ones. I understand you want to enable > the sensor drivers there, but It should either go via SUPERH > tree or we would need his ack to merge on our tree. > > > sh: migor: Remove stale soc_camera include > > It caused me lots of doubts if we should either apply this one > via the media tree or not. I ended by applying, as we're maintaining > the soc_camera stuff, with are being removed. So, it makes more sense > to merge it via our tree. > > Still, it would be nicer if we had the SUPERH maintainer's ack on > it. > > > Thanks, > Mauro signature.asc Description: PGP signature
Re: [PATCH 2/2] media: ov5640: Fix auto-exposure disabling
Hi again,
On Wed, Jul 18, 2018 at 01:19:03PM +0200, Jacopo Mondi wrote:
> As of:
> commit bf4a4b518c20 ("media: ov5640: Don't force the auto exposure state at
> start time") auto-exposure got disabled before programming new capture modes
> to
> the sensor. Unfortunately the function used to do that (ov5640_set_exposure())
> does not enable/disable auto-exposure engine through register 0x3503[0] bit,
> but
> programs registers [0x3500 - 0x3502] which represent the desired exposure time
> when running with manual exposure. As a result, auto-exposure was not actually
> disabled at all.
>
> To actually disable auto-exposure, go through the control framework instead of
> calling ov5640_set_exposure() function directly.
>
> Also, as auto-gain and auto-exposure are disabled un-conditionally but only
> restored to their previous values in ov5640_set_mode_direct() function, move
> controls restoring so that their value is re-programmed opportunely after
> either ov5640_set_mode_direct() or ov5640_set_mode_exposure_calc() have been
> executed.
>
> Fixes: bf4a4b518c20 ("media: ov5640: Don't force the auto exposure state at
> start time")
> Signed-off-by: Jacopo Mondi
>
> ---
> Is it worth doing with auto-gain what we're doing with auto-exposure? Cache
> the
> value and then re-program it instead of unconditionally disable/enable it?
I have missed this patch from Hugues that address almost the same
issue
https://www.mail-archive.com/linux-media@vger.kernel.org/msg133264.html
I feel this new one is simpler, and unless we want to avoid going
through the control framework, it is not worth adding new functions to
handle auto-exposure as Hugues' patch is doing.
Hugues, do you have comments? Feel free to add your sob or rb tags if
you like to.
Thanks
j
>
> Thanks
> j
> ---
> ---
> drivers/media/i2c/ov5640.c | 29 +
> 1 file changed, 13 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 12b3496..bc75cb7 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -1588,25 +1588,13 @@ static int ov5640_set_mode_exposure_calc(struct
> ov5640_dev *sensor,
> * change mode directly
> */
> static int ov5640_set_mode_direct(struct ov5640_dev *sensor,
> - const struct ov5640_mode_info *mode,
> - s32 exposure)
> + const struct ov5640_mode_info *mode)
> {
> - int ret;
> -
> if (!mode->reg_data)
> return -EINVAL;
>
> /* Write capture setting */
> - ret = ov5640_load_regs(sensor, mode);
> - if (ret < 0)
> - return ret;
> -
> - /* turn auto gain/exposure back on for direct mode */
> - ret = __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_gain, 1);
> - if (ret)
> - return ret;
> -
> - return __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_exp, exposure);
> + return ov5640_load_regs(sensor, mode);
> }
>
> static int ov5640_set_mode(struct ov5640_dev *sensor,
> @@ -1626,7 +1614,7 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
> return ret;
>
> exposure = sensor->ctrls.auto_exp->val;
> - ret = ov5640_set_exposure(sensor, V4L2_EXPOSURE_MANUAL);
> + ret = __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_exp, V4L2_EXPOSURE_MANUAL);
> if (ret)
> return ret;
>
> @@ -1642,12 +1630,21 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
>* change inside subsampling or scaling
>* download firmware directly
>*/
> - ret = ov5640_set_mode_direct(sensor, mode, exposure);
> + ret = ov5640_set_mode_direct(sensor, mode);
> }
>
> if (ret < 0)
> return ret;
>
> + /* Restore auto-gain and auto-exposure after mode has changed. */
> + ret = __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_gain, 1);
> + if (ret)
> + return ret;
> +
> + ret = __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_exp, exposure)
> + if (ret)
> + return ret;
> +
> ret = ov5640_set_binning(sensor, dn_mode != SCALING);
> if (ret < 0)
> return ret;
> --
> 2.7.4
>
signature.asc
Description: PGP signature
[PATCH 0/2] media: ov5640: Fix set_timings and auto-exposure
Hello, the ov5640 driver has received a lot of attentions recently. Maxime and Sam tackled the clock tree handling and I tried to fix the MIPI capture on i.MX6 platforms, but none of those patches ever made it to inclusion. Although a few fixes have been circulating around those series, and it's my opinion it is worth including them before any other developments takes place. I'm sending here a re-work of a patch from Sam and Maxime to fix timings setup, and a small fix for auto-exposure enabling/disabling operations. Each patch has a comment, on which I would like to have some feedback on. [1/1] has already received several acks on the mailing list, but never a formal Reviewed-by or Tested-by, while [2/2] is new. Thanks j Jacopo Mondi (2): media: ov5640: Fix timings setup code media: ov5640: Fix auto-exposure disabling drivers/media/i2c/ov5640.c | 75 -- 1 file changed, 32 insertions(+), 43 deletions(-) -- 2.7.4
[PATCH 2/2] media: ov5640: Fix auto-exposure disabling
As of:
commit bf4a4b518c20 ("media: ov5640: Don't force the auto exposure state at
start time") auto-exposure got disabled before programming new capture modes to
the sensor. Unfortunately the function used to do that (ov5640_set_exposure())
does not enable/disable auto-exposure engine through register 0x3503[0] bit, but
programs registers [0x3500 - 0x3502] which represent the desired exposure time
when running with manual exposure. As a result, auto-exposure was not actually
disabled at all.
To actually disable auto-exposure, go through the control framework instead of
calling ov5640_set_exposure() function directly.
Also, as auto-gain and auto-exposure are disabled un-conditionally but only
restored to their previous values in ov5640_set_mode_direct() function, move
controls restoring so that their value is re-programmed opportunely after
either ov5640_set_mode_direct() or ov5640_set_mode_exposure_calc() have been
executed.
Fixes: bf4a4b518c20 ("media: ov5640: Don't force the auto exposure state at
start time")
Signed-off-by: Jacopo Mondi
---
Is it worth doing with auto-gain what we're doing with auto-exposure? Cache the
value and then re-program it instead of unconditionally disable/enable it?
Thanks
j
---
---
drivers/media/i2c/ov5640.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 12b3496..bc75cb7 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -1588,25 +1588,13 @@ static int ov5640_set_mode_exposure_calc(struct
ov5640_dev *sensor,
* change mode directly
*/
static int ov5640_set_mode_direct(struct ov5640_dev *sensor,
- const struct ov5640_mode_info *mode,
- s32 exposure)
+ const struct ov5640_mode_info *mode)
{
- int ret;
-
if (!mode->reg_data)
return -EINVAL;
/* Write capture setting */
- ret = ov5640_load_regs(sensor, mode);
- if (ret < 0)
- return ret;
-
- /* turn auto gain/exposure back on for direct mode */
- ret = __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_gain, 1);
- if (ret)
- return ret;
-
- return __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_exp, exposure);
+ return ov5640_load_regs(sensor, mode);
}
static int ov5640_set_mode(struct ov5640_dev *sensor,
@@ -1626,7 +1614,7 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
return ret;
exposure = sensor->ctrls.auto_exp->val;
- ret = ov5640_set_exposure(sensor, V4L2_EXPOSURE_MANUAL);
+ ret = __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_exp, V4L2_EXPOSURE_MANUAL);
if (ret)
return ret;
@@ -1642,12 +1630,21 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
* change inside subsampling or scaling
* download firmware directly
*/
- ret = ov5640_set_mode_direct(sensor, mode, exposure);
+ ret = ov5640_set_mode_direct(sensor, mode);
}
if (ret < 0)
return ret;
+ /* Restore auto-gain and auto-exposure after mode has changed. */
+ ret = __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_gain, 1);
+ if (ret)
+ return ret;
+
+ ret = __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_exp, exposure)
+ if (ret)
+ return ret;
+
ret = ov5640_set_binning(sensor, dn_mode != SCALING);
if (ret < 0)
return ret;
--
2.7.4
[PATCH 1/2] media: ov5640: Fix timings setup code
As of:
commit 476dec012f4c ("media: ov5640: Add horizontal and vertical totals")
the timings parameters gets programmed separately from the static register
values array.
When changing capture mode, the vertical and horizontal totals gets inspected
by the set_mode_exposure_calc() functions, and only later programmed with the
new values. This means exposure, light banding filter and shutter gain are
calculated using the previous timings, and are thus not correct.
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: Maxime Ripard
Signed-off-by: Jacopo Mondi
---
This fix has been circulating around for quite some time now, in Maxime clock
tree patches, in Sam dropbox patches and in my latest MIPI fixes patches.
While the rest of the series have not yet been accepted, there is general
consensus this is an actual fix that has to be collected.
I've slightly modified Sam's and Maxime's version I previously sent,
programming timings directly in ov5640_load_regs() function.
You can find Sam's previous version here:
https://www.mail-archive.com/linux-media@vger.kernel.org/msg131654.html
and mine here, with an additional change that aimed to fix MIPI mode, which
I've left out in this version:
https://www.mail-archive.com/linux-media@vger.kernel.org/msg133422.html
Sam, Maxime, I took the liberty of taking your Signed-off-by from the previous
patch, as this was spotted by you first. Is this ok with you?
Thanks
j
---
---
drivers/media/i2c/ov5640.c | 50 +++---
1 file changed, 21 insertions(+), 29 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 1ecbb7a..12b3496 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -908,6 +908,26 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, u16
reg,
}
/* download ov5640 settings to sensor through i2c */
+static int ov5640_set_timings(struct ov5640_dev *sensor,
+ const struct ov5640_mode_info *mode)
+{
+ int ret;
+
+ ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_DVPHO, mode->hact);
+ if (ret < 0)
+ return ret;
+
+ ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_DVPVO, mode->vact);
+ if (ret < 0)
+ return ret;
+
+ ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_HTS, mode->htot);
+ if (ret < 0)
+ return ret;
+
+ return ov5640_write_reg16(sensor, OV5640_REG_TIMING_VTS, mode->vtot);
+}
+
static int ov5640_load_regs(struct ov5640_dev *sensor,
const struct ov5640_mode_info *mode)
{
@@ -935,7 +955,7 @@ static int ov5640_load_regs(struct ov5640_dev *sensor,
usleep_range(1000 * delay_ms, 1000 * delay_ms + 100);
}
- return ret;
+ return ov5640_set_timings(sensor, mode);
}
/* read exposure, in number of line periods */
@@ -1385,30 +1405,6 @@ static int ov5640_set_virtual_channel(struct ov5640_dev
*sensor)
return ov5640_write_reg(sensor, OV5640_REG_DEBUG_MODE, temp);
}
-static int ov5640_set_timings(struct ov5640_dev *sensor,
- const struct ov5640_mode_info *mode)
-{
- int ret;
-
- ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_DVPHO, mode->hact);
- if (ret < 0)
- return ret;
-
- ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_DVPVO, mode->vact);
- if (ret < 0)
- return ret;
-
- ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_HTS, mode->htot);
- if (ret < 0)
- return ret;
-
- ret = ov5640_write_reg16(sensor, OV5640_REG_TIMING_VTS, mode->vtot);
- if (ret < 0)
- return ret;
-
- return 0;
-}
-
static const struct ov5640_mode_info *
ov5640_find_mode(struct ov5640_dev *sensor, enum ov5640_frame_rate fr,
int width, int height, bool nearest)
@@ -1652,10 +1648,6 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
if (ret < 0)
return ret;
- ret = ov5640_set_timings(sensor, mode);
- if (ret < 0)
- return ret;
-
ret = ov5640_set_binning(sensor, dn_mode != SCALING);
if (ret < 0)
return ret;
--
2.7.4
Re: [PATCH v2 0/2] media: i2c: ov5640: Re-work MIPI startup sequence
Hi Steve, thanks for keep testing it On Sat, Jul 14, 2018 at 01:02:32PM -0700, Steve Longerbeam wrote: > > > On 07/14/2018 12:41 PM, Steve Longerbeam wrote: > >Hi Jacopo, > > > > > >On 07/14/2018 11:57 AM, Steve Longerbeam wrote: > >>Hi Jacopo, > >> > >>Pardon the late reply, see below. > >> > >>On 07/11/2018 12:21 AM, jacopo mondi wrote: > >>>Hi Steve, > >>> > >>>On Tue, Jul 10, 2018 at 02:10:54PM -0700, Steve Longerbeam wrote: > >>>>Hi Jacopo, > >>>> > >>>>Sorry to report my testing on SabreSD has same result > >>>>as last time. This series fixes the LP-11 timeout at stream > >>>>on but captured images are still blank. I tried the 640x480 > >>>>mode with UYVY2X8. Here is the pad config: > >>>This saddens me :( > >>> > >>>I'm capturing with the same format and sizes... this shouldn't be the > >>>issue > >>> > >>>Could you confirm this matches what you have in your tree? > >>>5dc2c80 media: ov5640: Fix timings setup code > >>>b35e757 media: i2c: ov5640: Re-work MIPI startup sequence > >>>3c4a737 media: ov5640: fix frame interval enumeration > >>>41cb1c7 media: ov5640: adjust xclk_max > >>>c3f3ba3 media: ov5640: add support of module orientation > >>>ce85705 media: ov5640: add HFLIP/VFLIP controls support > >>>8663341 media: ov5640: Program the visible resolution > >>>476dec0 media: ov5640: Add horizontal and vertical totals > >>>dba13a0 media: ov5640: Change horizontal and vertical resolutions name > >>>8f57c2f media: ov5640: Init properly the SCLK dividers > >> > >>Yes, I have that commit sequence. > >> > >>FWIW, I can verify what Jagan Teki reported earlier, that the driver > >>still > >>works on the SabreSD platform at: > >> > >>dba13a0 media: ov5640: Change horizontal and vertical resolutions name > >> > >>and is broken at: > >> > >>476dec0 media: ov5640: Add horizontal and vertical totals > >> > >>with LP-11 timeout at the mipi csi-2 receiver: > >> > >>[ 80.763189] imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0230 > >>[ 80.769599] ipu1_csi1: pipeline start failed with -110 > > > >And I discovered the bug in 476dec0 "media: ov5640: Add horizontal and > >vertical totals". The call to ov5640_set_timings() needs to be moved > >before the > >calls to ov5640_get_vts() and ov5640_get_hts(). But I see you have > >discovered > >that as well, and fixed in the second patch in your series. > > I'm sorry I'm not sur I'm following. Does this mean that with that bug you are referring to up here fixed by my last patch you have capture working? Thanks j > > But strangely, if I revert to 476dec0, and then move the call to > ov5640_set_timings() > to just after ov5640_load_regs() in ov5640_set_mode_exposure_calc() and > ov5640_set_mode_direct(), the LP-11 timeouts are still present. So I can > confirm > this strangeness which you already pointed out below [1]. > > > > > >> > >>> > >>>> > >>>>> > >>>>>The version I'm sending here re-introduces some of the timings > >>>>>parameters in the > >>>>>initial configuration blob (not in the single mode ones), which > >>>>>apparently has > >>>>>to be at least initially programmed to allow the driver to later > >>>>>program them > >>>>>singularly in the 'set_timings()' function. Unfortunately I do not > >>>>>have a real > >>>>>rationale behind this which explains why it has to be done this > >>>>>way :( > >>>>> > > [1] here :) > > Steve > > signature.asc Description: PGP signature
Re: [PATCH v2 0/2] media: i2c: ov5640: Re-work MIPI startup sequence
Hi Steve, On Tue, Jul 10, 2018 at 02:10:54PM -0700, Steve Longerbeam wrote: > Hi Jacopo, > > Sorry to report my testing on SabreSD has same result > as last time. This series fixes the LP-11 timeout at stream > on but captured images are still blank. I tried the 640x480 > mode with UYVY2X8. Here is the pad config: This saddens me :( I'm capturing with the same format and sizes... this shouldn't be the issue Could you confirm this matches what you have in your tree? 5dc2c80 media: ov5640: Fix timings setup code b35e757 media: i2c: ov5640: Re-work MIPI startup sequence 3c4a737 media: ov5640: fix frame interval enumeration 41cb1c7 media: ov5640: adjust xclk_max c3f3ba3 media: ov5640: add support of module orientation ce85705 media: ov5640: add HFLIP/VFLIP controls support 8663341 media: ov5640: Program the visible resolution 476dec0 media: ov5640: Add horizontal and vertical totals dba13a0 media: ov5640: Change horizontal and vertical resolutions name 8f57c2f media: ov5640: Init properly the SCLK dividers Thanks j > > # media-ctl --get-v4l2 "'ov5640 1-003c':0" > [fmt:UYVY8_2X8/640x480@1/30 field:none colorspace:srgb xfer:srgb > ycbcr:601 quantization:full-range] > > Steve > > On 07/10/2018 11:36 AM, Jacopo Mondi wrote: > >Hello, > >this series fixes capture operations on i.MX6Q platforms (and possible > > other > >platforms reported not working) using MIPI CSI-2 interface. > > > >This iteration expands the v1 version with an additional fix, initially > >submitted by Maxime in his series: > >[PATCH v3 00/12] media: ov5640: Misc cleanup and improvements > >https://www.spinics.net/lists/linux-media/msg134436.html > > > >The original patch has been reported not fully fixing the issues by Daniel > >Mack > >in his comment here below (on a Qualcomm platform if I'm not wrong): > >https://www.spinics.net/lists/linux-media/msg134524.html > >On my i.MX6Q testing platform that patch alone does not fix MIPI capture > >neither. > > > >The version I'm sending here re-introduces some of the timings parameters in > >the > >initial configuration blob (not in the single mode ones), which apparently > >has > >to be at least initially programmed to allow the driver to later program them > >singularly in the 'set_timings()' function. Unfortunately I do not have a > >real > >rationale behind this which explains why it has to be done this way :( > > > >For the MIPI startup sequence re-work patch, no changes compared to v1. > >Steve reported he has verified the LP-11 timout issue is solved on his > >testing > >platform too. For more details, please refer to the v1 cover letter: > >https://www.mail-archive.com/linux-media@vger.kernel.org/msg133352.html > > > >Thanks > >j > > > >Jacopo Mondi (1): > > media: i2c: ov5640: Re-work MIPI startup sequence > > > >Samuel Bobrowicz (1): > > media: ov5640: Fix timings setup code > > > > drivers/media/i2c/ov5640.c | 107 > > ++--- > > 1 file changed, 82 insertions(+), 25 deletions(-) > > > >-- > >2.7.4 > > > signature.asc Description: PGP signature
[PATCH v2 1/2] media: i2c: ov5640: Re-work MIPI startup sequence
Rework the MIPI interface startup sequence with the following changes:
- Remove MIPI bus initialization from the initial settings blob
- At set_power(1) time power up MIPI Tx/Rx and set data and clock lanes in
LP11 during 'sleep' and 'idle' with MIPI clock in non-continuous mode.
- At s_stream time enable/disable the MIPI interface output.
- Restore default settings at set_power(0) time.
Before this commit the sensor MIPI interface was initialized with settings
that require a start/stop sequence at power-up time in order to force lanes
into LP11 state, as they were initialized in LP00 when in 'sleep mode',
which is assumed to be the sensor manual definition for the D-PHY defined
stop mode.
The stream start/stop was performed by enabling disabling clock gating,
and had the side effect to change the lanes sleep mode configuration when
stream was stopped.
Clock gating/ungating:
- ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
-on ? 0 : BIT(5));
- if (ret)
Set lanes in LP11 when in 'sleep mode':
- ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
- on ? 0x00 : 0x70);
This commit fixes an issue reported by Jagan Teki on i.MX6 platforms that
prevents the host interface from powering up correctly:
https://lkml.org/lkml/2018/6/1/38
It also improves MIPI capture operations stability on my testing platform
where MIPI capture often failed and returned all-purple frames.
fixes: f22996db44e2 ("media: ov5640: add support of DVP parallel interface")
Reported-by: Jagan Teki
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/ov5640.c | 91 --
1 file changed, 71 insertions(+), 20 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 1ecbb7a..7bbd1d7 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -286,10 +286,10 @@ static const struct reg_value
ov5640_init_setting_30fps_VGA[] = {
{0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
{0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x3000, 0x00, 0, 0},
{0x3002, 0x1c, 0, 0}, {0x3004, 0xff, 0, 0}, {0x3006, 0xc3, 0, 0},
- {0x300e, 0x45, 0, 0}, {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
+ {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
{0x501f, 0x00, 0, 0}, {0x4713, 0x03, 0, 0}, {0x4407, 0x04, 0, 0},
{0x440e, 0x00, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
- {0x4837, 0x0a, 0, 0}, {0x4800, 0x04, 0, 0}, {0x3824, 0x02, 0, 0},
+ {0x4837, 0x0a, 0, 0}, {0x3824, 0x02, 0, 0},
{0x5000, 0xa7, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x5180, 0xff, 0, 0},
{0x5181, 0xf2, 0, 0}, {0x5182, 0x00, 0, 0}, {0x5183, 0x14, 0, 0},
{0x5184, 0x25, 0, 0}, {0x5185, 0x24, 0, 0}, {0x5186, 0x09, 0, 0},
@@ -1102,12 +1102,18 @@ static int ov5640_set_stream_mipi(struct ov5640_dev
*sensor, bool on)
{
int ret;
- ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
-on ? 0 : BIT(5));
- if (ret)
- return ret;
- ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
- on ? 0x00 : 0x70);
+ /*
+* Enable/disable the MIPI interface
+*
+* 0x300e = on ? 0x45 : 0x40
+* [7:5] = 001 : 2 data lanes mode
+* [4] = 0 : Power up MIPI HS Tx
+* [3] = 0 : Power up MIPI LS Rx
+* [2] = 1/0: MIPI interface enable/disable
+* [1:0] = 01/00: FIXME: 'debug'
+*/
+ ret = ov5640_write_reg(sensor, OV5640_REG_IO_MIPI_CTRL00,
+ on ? 0x45 : 0x40);
if (ret)
return ret;
@@ -1786,23 +1792,68 @@ static int ov5640_set_power(struct ov5640_dev *sensor,
bool on)
if (ret)
goto power_off;
+ /* We're done here for DVP bus, while CSI-2 needs setup. */
+ if (sensor->ep.bus_type != V4L2_MBUS_CSI2)
+ return 0;
+
+ /*
+* Power up MIPI HS Tx and LS Rx; 2 data lanes mode
+*
+* 0x300e = 0x40
+* [7:5] = 001 : 2 data lanes mode
+* [4] = 0 : Power up MIPI HS Tx
+* [3] = 0 : Power up MIPI LS Rx
+* [2] = 0 : MIPI interface disabled
+*/
+ ret = ov5640_write_reg(sensor,
+ OV5640_REG_IO_MIPI_CTRL00, 0x40);
+ if (ret)
+ goto power_off;
+
+ /*
+* Gate clock and set LP11 in 'no packets mode' (idle)
+*
+* 0x4800 = 0x24
+* [5] = 1 : Gate clock when 'no packets'
+* [2] = 1 : MIPI bus in LP11 when 'no packets'
+*/
+ ret = ov5640_wri
[PATCH v2 2/2] media: ov5640: Fix timings setup code
From: Samuel Bobrowicz
The current code, when changing the mode and changing the scaling or
sampling parameters, will look at the horizontal and vertical total size,
which, since 5999f381e023 ("media: ov5640: Add horizontal and vertical
totals") has been moved from the static register initialization to after
the mode change.
That means that the values are no longer set up before the code retrieves
them, which is obviously a bug.
In addition, restore timings settings in the initial configuration register
blob only, to have MIPI capture operations work again.
Fixes: 5999f381e023 ("media: ov5640: Add horizontal and vertical totals")
Signed-off-by: Samuel Bobrowicz
Signed-off-by: Maxime Ripard
[re-introduce timing parameters in initial configuration blob]
Signed-off-by: Jacopo Mondi
---
Compared to Maxime's and Sam's original version, this one re-introduces timing
configuration parameters in the init_settings configuration blob.
On my testing platform this fixes MIPI capture operations, that with the
original patch version applied was failing anyway.
Thanks
j
---
drivers/media/i2c/ov5640.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 7bbd1d7..bbcb908 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -277,7 +277,9 @@ static const struct reg_value
ov5640_init_setting_30fps_VGA[] = {
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
{0x3802, 0x00, 0, 0}, {0x3803, 0x04, 0, 0}, {0x3804, 0x0a, 0, 0},
{0x3805, 0x3f, 0, 0}, {0x3806, 0x07, 0, 0}, {0x3807, 0x9b, 0, 0},
- {0x3810, 0x00, 0, 0},
+ {0x3808, 0x02, 0, 0}, {0x3809, 0x80, 0, 0}, {0x380a, 0x01, 0, 0},
+ {0x380b, 0xe0, 0, 0}, {0x380c, 0x07, 0, 0}, {0x380d, 0x68, 0, 0},
+ {0x380e, 0x03, 0, 0}, {0x380f, 0xd8, 0, 0}, {0x3810, 0x00, 0, 0},
{0x3811, 0x10, 0, 0}, {0x3812, 0x00, 0, 0}, {0x3813, 0x06, 0, 0},
{0x3618, 0x00, 0, 0}, {0x3612, 0x29, 0, 0}, {0x3708, 0x64, 0, 0},
{0x3709, 0x52, 0, 0}, {0x370c, 0x03, 0, 0}, {0x3a02, 0x03, 0, 0},
@@ -1484,6 +1486,10 @@ static int ov5640_set_mode_exposure_calc(struct
ov5640_dev *sensor,
if (ret < 0)
return ret;
+ ret = ov5640_set_timings(sensor, mode);
+ if (ret < 0)
+ return ret;
+
/* read capture VTS */
ret = ov5640_get_vts(sensor);
if (ret < 0)
@@ -1611,6 +1617,10 @@ static int ov5640_set_mode_direct(struct ov5640_dev
*sensor,
if (ret < 0)
return ret;
+ ret = ov5640_set_timings(sensor, mode);
+ if (ret < 0)
+ return ret;
+
/* turn auto gain/exposure back on for direct mode */
ret = __v4l2_ctrl_s_ctrl(sensor->ctrls.auto_gain, 1);
if (ret)
@@ -1658,10 +1668,6 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
if (ret < 0)
return ret;
- ret = ov5640_set_timings(sensor, mode);
- if (ret < 0)
- return ret;
-
ret = ov5640_set_binning(sensor, dn_mode != SCALING);
if (ret < 0)
return ret;
--
2.7.4
Re: [PATCH] media: i2c: ov5640: Re-work MIPI startup sequence
Hi Steve,
I've done some more testing, and finally got MIPI capture work
properly on the i.MX6Q platform I'm testing on.
Apparently commit:
476dec012f4c6545b0b7599cd9adba2ed819ad3b
("media: ov5640: Add horizontal and vertical totals")
which several people, Jagan included, has reported introducing
regressions on MIPI actually breaks image capture.
I have a fix based on Maxime's and Sam's
[PATCH v3 01/12] media: ov5640: Fix timings setup code
I will send the two patches out soon.
If you and other people are eager to test them it would be awesome to
have a confirmation MIPI capture works for you too.
Thanks
j
On Tue, Jul 10, 2018 at 09:33:31AM +0200, jacopo mondi wrote:
> Hi Steve,
>thanks for testing!
>
> On Mon, Jul 09, 2018 at 02:52:09PM -0700, Steve Longerbeam wrote:
> > Hi Jacopo,
> >
> > I tested this patch on the i.MX6Q SabreSD with the OV5640 module.
> > It fixes the LP-11 timeout at stream on, but the captured images
> > are completely blank/black.
>
> Intersting that the module was not starting up properly on other
> (all?) i.MX6Q platforms, not only on Engicam's one. I didn't get this
> initially.
>
> Ok, so that's a step forward, but not enough probably. I'll keep
> looking into this and get back!
>
> Thanks
>j
>
> >
> > Steve
> >
> >
> > On 07/06/2018 04:00 AM, Jacopo Mondi wrote:
> > >From: Jacopo Mondi
> > >
> > >Rework the MIPI interface startup sequence with the following changes:
> > >
> > >- Remove MIPI bus initialization from the initial settings blob
> > >- At set_power(1) time power up MIPI Tx/Rx and set data and clock lanes in
> > > LP11 during 'sleep' and 'idle' with MIPI clock in non-continuous mode.
> > >- At s_stream time enable/disable the MIPI interface output.
> > >- Restore default settings at set_power(0) time.
> > >
> > >Before this commit the sensor MIPI interface was initialized with settings
> > >that require a start/stop sequence at power-up time in order to force lanes
> > >into LP11 state, as they were initialized in LP00 when in 'sleep mode',
> > >which is assumed to be the sensor manual definition for the D-PHY defined
> > >stop mode.
> > >
> > >The stream start/stop was performed by enabling disabling clock gating,
> > >and had the side effect to change the lanes sleep mode configuration when
> > >stream was stopped.
> > >
> > >Clock gating/ungating:
> > >- ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
> > >-on ? 0 : BIT(5));
> > >- if (ret)
> > >
> > >Set lanes in LP11 when in 'sleep mode':
> > >- ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
> > >- on ? 0x00 : 0x70);
> > >
> > >This commit fixes an issue reported by Jagan Teki on i.MX6 platforms that
> > >prevents the host interface from powering up correctly:
> > >https://lkml.org/lkml/2018/6/1/38
> > >
> > >It also improves MIPI capture operations stability on my testing platform
> > >where MIPI capture often (silently) failed and returned all-purple frames.
> > >
> > >fixes: f22996db44e2 ("media: ov5640: add support of DVP parallel
> > >interface")
> > >Reported-by: Jagan Teki
> > >Signed-off-by: Jacopo Mondi
> > >
> > >---
> > >
> > >Hello,
> > > I'm sending this one as new patch instead of a v2 of the previously sent
> > >series "media: i2c: ov5640: Re-work MIPI interface configuration" as the
> > >previous one was not working on the Engicam i.Mx6 platform where Jagan
> > >initially reported issues on.
> > >
> > >I've been able to test that capture now starts on said platform, but I've
> > >not
> > >been able to visually verify any of the image content as I have no way yet
> > >to
> > >transfer the raw images to my development host and verify their content
> > >(network
> > >still not working for me on that platform :/ )
> > >
> > >On my other testing platform images are correct, but they already were
> > >with the
> > >previous version of this patches too, so I assume the CSI-2 receiver is
> > >far more
> > >tolerant there.
> > >
> > >Jagan, is there any way you could verify images? I would appreciate your
> > >Tested-by tag in case they're correct.
> > >
> > >Also, as there seems to be a lot of people interested in ov5640 these
> > >days, I
&g
[PATCH v2 0/2] media: i2c: ov5640: Re-work MIPI startup sequence
Hello, this series fixes capture operations on i.MX6Q platforms (and possible other platforms reported not working) using MIPI CSI-2 interface. This iteration expands the v1 version with an additional fix, initially submitted by Maxime in his series: [PATCH v3 00/12] media: ov5640: Misc cleanup and improvements https://www.spinics.net/lists/linux-media/msg134436.html The original patch has been reported not fully fixing the issues by Daniel Mack in his comment here below (on a Qualcomm platform if I'm not wrong): https://www.spinics.net/lists/linux-media/msg134524.html On my i.MX6Q testing platform that patch alone does not fix MIPI capture neither. The version I'm sending here re-introduces some of the timings parameters in the initial configuration blob (not in the single mode ones), which apparently has to be at least initially programmed to allow the driver to later program them singularly in the 'set_timings()' function. Unfortunately I do not have a real rationale behind this which explains why it has to be done this way :( For the MIPI startup sequence re-work patch, no changes compared to v1. Steve reported he has verified the LP-11 timout issue is solved on his testing platform too. For more details, please refer to the v1 cover letter: https://www.mail-archive.com/linux-media@vger.kernel.org/msg133352.html Thanks j Jacopo Mondi (1): media: i2c: ov5640: Re-work MIPI startup sequence Samuel Bobrowicz (1): media: ov5640: Fix timings setup code drivers/media/i2c/ov5640.c | 107 ++--- 1 file changed, 82 insertions(+), 25 deletions(-) -- 2.7.4
Re: [PATCH] media: i2c: ov5640: Re-work MIPI startup sequence
Hi Steve,
thanks for testing!
On Mon, Jul 09, 2018 at 02:52:09PM -0700, Steve Longerbeam wrote:
> Hi Jacopo,
>
> I tested this patch on the i.MX6Q SabreSD with the OV5640 module.
> It fixes the LP-11 timeout at stream on, but the captured images
> are completely blank/black.
Intersting that the module was not starting up properly on other
(all?) i.MX6Q platforms, not only on Engicam's one. I didn't get this
initially.
Ok, so that's a step forward, but not enough probably. I'll keep
looking into this and get back!
Thanks
j
>
> Steve
>
>
> On 07/06/2018 04:00 AM, Jacopo Mondi wrote:
> >From: Jacopo Mondi
> >
> >Rework the MIPI interface startup sequence with the following changes:
> >
> >- Remove MIPI bus initialization from the initial settings blob
> >- At set_power(1) time power up MIPI Tx/Rx and set data and clock lanes in
> > LP11 during 'sleep' and 'idle' with MIPI clock in non-continuous mode.
> >- At s_stream time enable/disable the MIPI interface output.
> >- Restore default settings at set_power(0) time.
> >
> >Before this commit the sensor MIPI interface was initialized with settings
> >that require a start/stop sequence at power-up time in order to force lanes
> >into LP11 state, as they were initialized in LP00 when in 'sleep mode',
> >which is assumed to be the sensor manual definition for the D-PHY defined
> >stop mode.
> >
> >The stream start/stop was performed by enabling disabling clock gating,
> >and had the side effect to change the lanes sleep mode configuration when
> >stream was stopped.
> >
> >Clock gating/ungating:
> >- ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
> >-on ? 0 : BIT(5));
> >- if (ret)
> >
> >Set lanes in LP11 when in 'sleep mode':
> >- ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
> >- on ? 0x00 : 0x70);
> >
> >This commit fixes an issue reported by Jagan Teki on i.MX6 platforms that
> >prevents the host interface from powering up correctly:
> >https://lkml.org/lkml/2018/6/1/38
> >
> >It also improves MIPI capture operations stability on my testing platform
> >where MIPI capture often (silently) failed and returned all-purple frames.
> >
> >fixes: f22996db44e2 ("media: ov5640: add support of DVP parallel interface")
> >Reported-by: Jagan Teki
> >Signed-off-by: Jacopo Mondi
> >
> >---
> >
> >Hello,
> > I'm sending this one as new patch instead of a v2 of the previously sent
> >series "media: i2c: ov5640: Re-work MIPI interface configuration" as the
> >previous one was not working on the Engicam i.Mx6 platform where Jagan
> >initially reported issues on.
> >
> >I've been able to test that capture now starts on said platform, but I've not
> >been able to visually verify any of the image content as I have no way yet to
> >transfer the raw images to my development host and verify their content
> >(network
> >still not working for me on that platform :/ )
> >
> >On my other testing platform images are correct, but they already were with
> >the
> >previous version of this patches too, so I assume the CSI-2 receiver is far
> >more
> >tolerant there.
> >
> >Jagan, is there any way you could verify images? I would appreciate your
> >Tested-by tag in case they're correct.
> >
> >Also, as there seems to be a lot of people interested in ov5640 these days, I
> >have expanded the receivers list. Anyone that could give these patches a
> >spin?
> >(ie. Sam reported issues too with the current MIPI startup sequence in a
> >patch
> >series he shared on dropbox iirc...)
> >
> >Thanks
> >j
> >---
> > drivers/media/i2c/ov5640.c | 91
> > --
> > 1 file changed, 71 insertions(+), 20 deletions(-)
> >
> >diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> >index 1ecbb7a..7bbd1d7 100644
> >--- a/drivers/media/i2c/ov5640.c
> >+++ b/drivers/media/i2c/ov5640.c
> >@@ -286,10 +286,10 @@ static const struct reg_value
> >ov5640_init_setting_30fps_VGA[] = {
> > {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
> > {0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x3000, 0x00, 0, 0},
> > {0x3002, 0x1c, 0, 0}, {0x3004, 0xff, 0, 0}, {0x3006, 0xc3, 0, 0},
> >-{0x300e, 0x45, 0, 0}, {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
> >+{0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
> > {0x501f, 0x00, 0, 0}, {0x47
[PATCH] media: i2c: ov5640: Re-work MIPI startup sequence
From: Jacopo Mondi
Rework the MIPI interface startup sequence with the following changes:
- Remove MIPI bus initialization from the initial settings blob
- At set_power(1) time power up MIPI Tx/Rx and set data and clock lanes in
LP11 during 'sleep' and 'idle' with MIPI clock in non-continuous mode.
- At s_stream time enable/disable the MIPI interface output.
- Restore default settings at set_power(0) time.
Before this commit the sensor MIPI interface was initialized with settings
that require a start/stop sequence at power-up time in order to force lanes
into LP11 state, as they were initialized in LP00 when in 'sleep mode',
which is assumed to be the sensor manual definition for the D-PHY defined
stop mode.
The stream start/stop was performed by enabling disabling clock gating,
and had the side effect to change the lanes sleep mode configuration when
stream was stopped.
Clock gating/ungating:
- ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
-on ? 0 : BIT(5));
- if (ret)
Set lanes in LP11 when in 'sleep mode':
- ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
- on ? 0x00 : 0x70);
This commit fixes an issue reported by Jagan Teki on i.MX6 platforms that
prevents the host interface from powering up correctly:
https://lkml.org/lkml/2018/6/1/38
It also improves MIPI capture operations stability on my testing platform
where MIPI capture often (silently) failed and returned all-purple frames.
fixes: f22996db44e2 ("media: ov5640: add support of DVP parallel interface")
Reported-by: Jagan Teki
Signed-off-by: Jacopo Mondi
---
Hello,
I'm sending this one as new patch instead of a v2 of the previously sent
series "media: i2c: ov5640: Re-work MIPI interface configuration" as the
previous one was not working on the Engicam i.Mx6 platform where Jagan
initially reported issues on.
I've been able to test that capture now starts on said platform, but I've not
been able to visually verify any of the image content as I have no way yet to
transfer the raw images to my development host and verify their content (network
still not working for me on that platform :/ )
On my other testing platform images are correct, but they already were with the
previous version of this patches too, so I assume the CSI-2 receiver is far more
tolerant there.
Jagan, is there any way you could verify images? I would appreciate your
Tested-by tag in case they're correct.
Also, as there seems to be a lot of people interested in ov5640 these days, I
have expanded the receivers list. Anyone that could give these patches a spin?
(ie. Sam reported issues too with the current MIPI startup sequence in a patch
series he shared on dropbox iirc...)
Thanks
j
---
drivers/media/i2c/ov5640.c | 91 --
1 file changed, 71 insertions(+), 20 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 1ecbb7a..7bbd1d7 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -286,10 +286,10 @@ static const struct reg_value
ov5640_init_setting_30fps_VGA[] = {
{0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
{0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x3000, 0x00, 0, 0},
{0x3002, 0x1c, 0, 0}, {0x3004, 0xff, 0, 0}, {0x3006, 0xc3, 0, 0},
- {0x300e, 0x45, 0, 0}, {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
+ {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
{0x501f, 0x00, 0, 0}, {0x4713, 0x03, 0, 0}, {0x4407, 0x04, 0, 0},
{0x440e, 0x00, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
- {0x4837, 0x0a, 0, 0}, {0x4800, 0x04, 0, 0}, {0x3824, 0x02, 0, 0},
+ {0x4837, 0x0a, 0, 0}, {0x3824, 0x02, 0, 0},
{0x5000, 0xa7, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x5180, 0xff, 0, 0},
{0x5181, 0xf2, 0, 0}, {0x5182, 0x00, 0, 0}, {0x5183, 0x14, 0, 0},
{0x5184, 0x25, 0, 0}, {0x5185, 0x24, 0, 0}, {0x5186, 0x09, 0, 0},
@@ -1102,12 +1102,18 @@ static int ov5640_set_stream_mipi(struct ov5640_dev
*sensor, bool on)
{
int ret;
- ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
-on ? 0 : BIT(5));
- if (ret)
- return ret;
- ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
- on ? 0x00 : 0x70);
+ /*
+* Enable/disable the MIPI interface
+*
+* 0x300e = on ? 0x45 : 0x40
+* [7:5] = 001 : 2 data lanes mode
+* [4] = 0 : Power up MIPI HS Tx
+* [3] = 0 : Power up MIPI LS Rx
+* [2] = 1/0: MIPI interface enable/disable
+* [1:0] = 01/00: FIXME: 'debug'
+*/
+ ret = ov5640_write_reg(sensor, OV5640_REG_IO_MIPI_CTRL00,
+ on ? 0x45 : 0x40);
if (ret)
return ret;
@@ -1786,23 +1792,68 @@ static int ov5640_set_power(struct ov564
Re: [PATCH 3/5] media: ov5640: fix wrong binning value in exposure calculation
Hi Hugues,
On Wed, Jul 04, 2018 at 03:29:56PM +, Hugues FRUCHET wrote:
> Hi Jacopo,
>
> Many thanks for you valuable comments, I hardly understand this exposure
> code, and still some wrongly exposed images are observed switching from
> subsampling to scaling modes.
Thank you for the patches...
Just out of curiosity, have you ever been able to get images in 1280x720
and 1920x1080 mode? I assume so if you're able to switch between two
subsampling modes...
> Steve, do you have more insight to share with us on this code ?
>
> On 07/04/2018 04:38 PM, jacopo mondi wrote:
> > Hi Hugues,
> >
> > On Wed, Jul 04, 2018 at 02:58:41PM +0200, Hugues Fruchet wrote:
> >> ov5640_set_mode_exposure_calc() is checking binning value but
> >> binning value read is buggy and binning value set is done
> >> after calling ov5640_set_mode_exposure_calc(), fix all of this.
> >
> > The ov5640_binning_on() function was indeed wrong (side note: that
> > name is confusing, it should be 0v5640_get_binning() to comply with
> > others..) and always returned 0, but I don't see a fix here for the
> > second part of the issue.
> Mistake from me here, I should have removed "and binning value set is
> done after calling ov5640_set_mode_exposure_calc()" in commit message.
>
> > In facts, during the lenghty exposure
> > calculation process, binning is checked to decide if the preview
> > shutter time should be doubled or not
> >
> > static int ov5640_set_mode_exposure_calc(struct ov5640_dev *sensor,
> > const struct ov5640_mode_info *mode)
> > {
> > ...
> >
> > /* read preview shutter */
> > ret = ov5640_get_exposure(sensor);
> > if (ret < 0)
> > return ret;
> > prev_shutter = ret;
> > ret = ov5640_binning_on(sensor);
> > if (ret < 0)
> > return ret;
> > if (ret && mode->id != OV5640_MODE_720P_1280_720 &&
> > mode->id != OV5640_MODE_1080P_1920_1080)
> > prev_shutter *= 2;
> > ...
> > }
> >
> > My understanding is that reading the value from the register returns
> > the binning settings for the previously configured mode, while the >
> > binning value is later updated for the current mode in
> > ov5640_set_mode(), after 'ov5640_set_mode_exposure_calc()' has already
> > been called. Is this ok?
>
> This is also my understanding.
>
Thanks. This is probably worth fixing. Maybe your exposure issues
depend on this..
> >
> > Also, I assume the code checks for mode->id to figure out if the mode
> > uses subsampling or scaling. Be aware that for 1280x720 mode, the
> > selected scaling mode depends on the FPS, not only on the mode id as
> > it is assumed here.
>
> This is not what I understand from this array:
> static const struct ov5640_mode_info
> ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = {
> [15fps]
> {OV5640_MODE_720P_1280_720, SUBSAMPLING,
>1280, 1892, 720, 740,
>ov5640_setting_15fps_720P_1280_720,
>ARRAY_SIZE(ov5640_setting_15fps_720P_1280_720)},
> [30fps]
> {OV5640_MODE_720P_1280_720, SUBSAMPLING,
>1280, 1892, 720, 740,
>ov5640_setting_30fps_720P_1280_720,
>ARRAY_SIZE(ov5640_setting_30fps_720P_1280_720)},
>
> => both modes uses subsampling here
You are right, I counted the array entries and 30FPS has a -1
specified as downsizing mode in the last one, so I overlooked it, sorry!
So what is mode->id checked for, if 720p and 1080p modes use different
downsizing modes? Confused
>
> >
> > A final note, the 'ov5640_set_mode_exposure_calc()' also writes VTS to
> > update the shutter time to the newly calculated value.
> >
> > /* write capture shutter */
> > if (cap_shutter > (cap_vts - 4)) {
> > cap_vts = cap_shutter + 4;
> > ret = ov5640_set_vts(sensor, cap_vts);
> > if (ret < 0)
> > return ret;
> > }
> >
> > Be aware again that VTS is later restored to the mode->vtot value by
> > the 'ov5640_set_timings()' functions, which again, is called later
> > than 'ov5640_set_mode_exposure_calc()'.
> >
> > Wouldn't it be better to postpone exposure calculation after timings
> > and binnings have been set ?
>
> As said, I'm new on all of this but I can give it a try.
Thanks, I also see banding filter being calculated twice, and I'm sure
there are some other things I'm missing. Th
Re: [PATCH 3/5] media: ov5640: fix wrong binning value in exposure calculation
Hi Hugues,
On Wed, Jul 04, 2018 at 02:58:41PM +0200, Hugues Fruchet wrote:
> ov5640_set_mode_exposure_calc() is checking binning value but
> binning value read is buggy and binning value set is done
> after calling ov5640_set_mode_exposure_calc(), fix all of this.
The ov5640_binning_on() function was indeed wrong (side note: that
name is confusing, it should be 0v5640_get_binning() to comply with
others..) and always returned 0, but I don't see a fix here for the
second part of the issue. In facts, during the lenghty exposure
calculation process, binning is checked to decide if the preview
shutter time should be doubled or not
static int ov5640_set_mode_exposure_calc(struct ov5640_dev *sensor,
const struct ov5640_mode_info *mode)
{
...
/* read preview shutter */
ret = ov5640_get_exposure(sensor);
if (ret < 0)
return ret;
prev_shutter = ret;
ret = ov5640_binning_on(sensor);
if (ret < 0)
return ret;
if (ret && mode->id != OV5640_MODE_720P_1280_720 &&
mode->id != OV5640_MODE_1080P_1920_1080)
prev_shutter *= 2;
...
}
My understanding is that reading the value from the register returns
the binning settings for the previously configured mode, while the
binning value is later updated for the current mode in
ov5640_set_mode(), after 'ov5640_set_mode_exposure_calc()' has already
been called. Is this ok?
Also, I assume the code checks for mode->id to figure out if the mode
uses subsampling or scaling. Be aware that for 1280x720 mode, the
selected scaling mode depends on the FPS, not only on the mode id as
it is assumed here.
A final note, the 'ov5640_set_mode_exposure_calc()' also writes VTS to
update the shutter time to the newly calculated value.
/* write capture shutter */
if (cap_shutter > (cap_vts - 4)) {
cap_vts = cap_shutter + 4;
ret = ov5640_set_vts(sensor, cap_vts);
if (ret < 0)
return ret;
}
Be aware again that VTS is later restored to the mode->vtot value by
the 'ov5640_set_timings()' functions, which again, is called later
than 'ov5640_set_mode_exposure_calc()'.
Wouldn't it be better to postpone exposure calculation after timings
and binnings have been set?
Thanks
j
>
> Signed-off-by: Hugues Fruchet
> ---
> drivers/media/i2c/ov5640.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> index 7c569de..f9b256e 100644
> --- a/drivers/media/i2c/ov5640.c
> +++ b/drivers/media/i2c/ov5640.c
> @@ -1357,8 +1357,8 @@ static int ov5640_binning_on(struct ov5640_dev *sensor)
> ret = ov5640_read_reg(sensor, OV5640_REG_TIMING_TC_REG21, );
> if (ret)
> return ret;
> - temp &= 0xfe;
> - return temp ? 1 : 0;
> +
> + return temp & BIT(0);
> }
>
> static int ov5640_set_binning(struct ov5640_dev *sensor, bool enable)
> --
> 1.9.1
>
signature.asc
Description: PGP signature
Re: [PATCH v7 1/2] media: ov2680: dt: Add bindings for OV2680
Hi Rui,
sorry, I'm a bit late, you're already at v7 and I don't want to
slow down inclusion with a few minor comments.
Please bear with me and see below...
On Tue, Jul 03, 2018 at 03:08:02PM +0100, Rui Miguel Silva wrote:
> Add device tree binding documentation for the OV2680 camera sensor.
>
> CC: devicet...@vger.kernel.org
> Signed-off-by: Rui Miguel Silva
> ---
> .../devicetree/bindings/media/i2c/ov2680.txt | 46 +++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2680.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov2680.txt
> b/Documentation/devicetree/bindings/media/i2c/ov2680.txt
> new file mode 100644
> index ..11e925ed9dad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov2680.txt
> @@ -0,0 +1,46 @@
> +* Omnivision OV2680 MIPI CSI-2 sensor
> +
> +Required Properties:
> +- compatible: should be "ovti,ov2680".
> +- clocks: reference to the xvclk input clock.
> +- clock-names: should be "xvclk".
Having a single clock source I think you can omit 'clock-names' (or at
least not marking it as required)
> +- DOVDD-supply: Digital I/O voltage supply.
> +- DVDD-supply: Digital core voltage supply.
> +- AVDD-supply: Analog voltage supply.
> +
> +Optional Properties:
> +- reset-gpios: reference to the GPIO connected to the powerdown/reset pin,
> + if any. This is an active low signal to the OV2680.
> +
> +The device node must contain one 'port' child node for its digital output
> +video port, and this port must have a single endpoint in accordance with
> + the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Endpoint node required properties for CSI-2 connection are:
> +- remote-endpoint: a phandle to the bus receiver's endpoint node.
> +- clock-lanes: should be set to <0> (clock lane on hardware lane 0).
> +- data-lanes: should be set to <1> (one CSI-2 lane supported).
What is the value of marking as required two properties which can only have
default values (the sensor does not support clock on different lanes,
nor it supports more than 1 data lane) ?
Thanks
j
> +
> +Example:
> +
> + {
> + ov2680: camera-sensor@36 {
> + compatible = "ovti,ov2680";
> + reg = <0x36>;
> + clocks = <>;
> + clock-names = "xvclk";
> + reset-gpios = < 3 GPIO_ACTIVE_LOW>;
> + DOVDD-supply = <_reg>;
> + DVDD-supply = <_reg>;
> + AVDD-supply = <_peri_3p15v>;
> +
> + port {
> + ov2680_to_mipi: endpoint {
> + remote-endpoint = <_from_sensor>;
> + clock-lanes = <0>;
> + data-lanes = <1>;
> + };
> + };
> + };
> +};
> --
> 2.18.0
>
signature.asc
Description: PGP signature
[PATCH 2/2] media: i2c: ov5640: Remove start/stop sequence
From: Jacopo Mondi
Now that data and clock lanes start in LP11 no need to issue a start/stop
sequence at power on time to 'coax the lanes in LP11 state'.
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/ov5640.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 465acce..96d0203 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -1796,20 +1796,6 @@ static int ov5640_set_power(struct ov5640_dev *sensor,
bool on)
if (ret)
goto power_off;
- if (sensor->ep.bus_type == V4L2_MBUS_CSI2) {
- /*
-* start streaming briefly followed by stream off in
-* order to coax the clock lane into LP-11 state.
-*/
- ret = ov5640_set_stream_mipi(sensor, true);
- if (ret)
- goto power_off;
- usleep_range(1000, 2000);
- ret = ov5640_set_stream_mipi(sensor, false);
- if (ret)
- goto power_off;
- }
-
return 0;
}
--
2.7.4
[PATCH 0/2] media: i2c: ov5640: Re-work MIPI interface configuration
The sensor MIPI interface is initialized with settings that require a start/stop sequence at power-up time in order to force lanes into LP11 state, as they are initialized in LP00 when in 'sleep mode' which I assume to be the sensor manual definition for the D-PHY stop mode. The stream start/stop was performed by enabling disabling clock gating, and had the side effect to change the lanes sleep mode configuration when stream was stopped. Clock gating/ungating: - ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5), -on ? 0 : BIT(5)); - if (ret) Set lanes in LP11 when in 'sleep mode': - ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00, - on ? 0x00 : 0x70); As some failing streaming start sequence have been observed on my testing platform, the initialization sequence has been re-worked to the following one: - 0x3019 = 0x70 Configure data lanes and clock lane to LP11 when in 'sleep mode' (assuming this is D-PHY stop state) - 0x4800 = 0x20 Gate clock when non transmitting packets, MIPI bus in LP00 when non transmitting packets (assuming this is D-PHY LPDT) - 0x300e = 0x58 Select 2 lanes mode, power off TX and RX, disable MIPI interface At stream on time: - 0x300e = 0x4c: power TX up, enable MIPI interface At stream off time - 0x300e = 0x58: power TX down, disable MIPI interface. Sam Bobrowicz has shared a patch to disable the single lanes at stream off time and force them in LP00 state to prevent the sensor from "transmit bad packets during configuration". Sam could you please test this two patches and verify if you still have to manually disable the single lanes? It would help validate the theory that 'sleep state' is actually 'stop state' and having lanes in LP00 instead of LP11 prevents the receiver to detect when to exit from high-speed mode. Thanks j Jacopo Mondi (2): media: i2c: ov5640: Re-work MIPI start sequence media: i2c: ov5640: Remove start/stop sequence drivers/media/i2c/ov5640.c | 40 ++-- 1 file changed, 18 insertions(+), 22 deletions(-) -- 2.7.4
[PATCH 1/2] media: i2c: ov5640: Re-work MIPI start sequence
From: Jacopo Mondi
Change the MIPI CSI-2 interface startup sequence to the following:
Initialization:
0x3019 = 0x70 : Lane1, Lane2 and clock in LP11 when in 'sleep mode'
0x300e = 0x58 : 2 lanes mode, power down TX and RX, MIPI CSI-2 off
0x4800 = 0x20 : Gate clock when not transmitting, LP00 when not transmitting
Stream on:
0x300e = 0x4c : 2 lanes mode, power up TX and enable MIPI
Stream off:
0x300e = 0x58 : 2 lanes mode, power down TX and RX, MIPI CSI-2 off
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/ov5640.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 1ecbb7a..465acce 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -259,6 +259,7 @@ static inline struct v4l2_subdev *ctrl_to_sd(struct
v4l2_ctrl *ctrl)
static const struct reg_value ov5640_init_setting_30fps_VGA[] = {
{0x3103, 0x11, 0, 0}, {0x3008, 0x82, 0, 5}, {0x3008, 0x42, 0, 0},
{0x3103, 0x03, 0, 0}, {0x3017, 0x00, 0, 0}, {0x3018, 0x00, 0, 0},
+ {0x3019, 0x70, 0, 0},
{0x3034, 0x18, 0, 0}, {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0},
{0x3037, 0x13, 0, 0}, {0x3630, 0x36, 0, 0},
{0x3631, 0x0e, 0, 0}, {0x3632, 0xe2, 0, 0}, {0x3633, 0x12, 0, 0},
@@ -286,10 +287,10 @@ static const struct reg_value
ov5640_init_setting_30fps_VGA[] = {
{0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
{0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x3000, 0x00, 0, 0},
{0x3002, 0x1c, 0, 0}, {0x3004, 0xff, 0, 0}, {0x3006, 0xc3, 0, 0},
- {0x300e, 0x45, 0, 0}, {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
+ {0x300e, 0x58, 0, 0}, {0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
{0x501f, 0x00, 0, 0}, {0x4713, 0x03, 0, 0}, {0x4407, 0x04, 0, 0},
{0x440e, 0x00, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
- {0x4837, 0x0a, 0, 0}, {0x4800, 0x04, 0, 0}, {0x3824, 0x02, 0, 0},
+ {0x4837, 0x0a, 0, 0}, {0x4800, 0x20, 0, 0}, {0x3824, 0x02, 0, 0},
{0x5000, 0xa7, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x5180, 0xff, 0, 0},
{0x5181, 0xf2, 0, 0}, {0x5182, 0x00, 0, 0}, {0x5183, 0x14, 0, 0},
{0x5184, 0x25, 0, 0}, {0x5185, 0x24, 0, 0}, {0x5186, 0x09, 0, 0},
@@ -1102,12 +1103,21 @@ static int ov5640_set_stream_mipi(struct ov5640_dev
*sensor, bool on)
{
int ret;
- ret = ov5640_mod_reg(sensor, OV5640_REG_MIPI_CTRL00, BIT(5),
-on ? 0 : BIT(5));
- if (ret)
- return ret;
- ret = ov5640_write_reg(sensor, OV5640_REG_PAD_OUTPUT00,
- on ? 0x00 : 0x70);
+ /*
+* powerup MIPI TX PHY & enable MIPI
+*
+* 0x4c: [7:5] 010 two lanes MIPI (FIXME: 'debug mode' in manual)
+* [4] 0 power on MIPI TX
+* [3] 1 power off MIPI RX
+* [2] 1 enable MIPI
+*
+* 0x58: [7:5] 010 two lanes MIPI (FIXME: 'debug mode' in manual)
+* [4] 1 power off MIPI TX
+* [3] 1 power off MIPI RX
+* [2] 0 disable MIPI
+*/
+ ret = ov5640_write_reg(sensor,
+ OV5640_REG_IO_MIPI_CTRL00, on ? 0x4c : 0x58);
if (ret)
return ret;
--
2.7.4
Re: [PATCH v3 03/12] media: ov5640: Remove the clocks registers initialization
Hi ov5640 people,
I'm happy to finally jump on the bandwagon...
I had a few days to test the sensor driver (on 2 platforms) and unfortunately
this series breaks MIPI capture for me as well..
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:35 AM, Daniel Mack wrote:
> On Thursday, May 17, 2018 10:53 AM, Maxime Ripard wrote:
>
> 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
> ---
> >>>
> >>>
> >>> [...]
> >>>
> @@ -625,8 +623,8 @@ static const struct reg_value
> ov5640_setting_30fps_1080P_1920_1080[] = {
> {0x3a0d, 0x04, 0, 0}, {0x3a14, 0x03, 0, 0}, {0x3a15, 0xd8, 0, 0},
> {0x4001, 0x02, 0, 0}, {0x4004, 0x06, 0, 0}, {0x4713, 0x03, 0, 0},
> {0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
> - {0x3824, 0x02, 0, 0}, {0x5001, 0x83, 0, 0}, {0x3035, 0x11, 0, 0},
> - {0x3036, 0x54, 0, 0}, {0x3c07, 0x07, 0, 0}, {0x3c08, 0x00, 0, 0},
> + {0x3824, 0x02, 0, 0}, {0x5001, 0x83, 0, 0},
> + {0x3c07, 0x07, 0, 0}, {0x3c08, 0x00, 0, 0},
> >>>
> >>>
> >>> This is the mode that I'm testing with. Previously, the hard-coded
> >>> registers
> >>> here were:
> >>>
> >>> OV5640_REG_SC_PLL_CTRL1 (0x3035) = 0x11
> >>> OV5640_REG_SC_PLL_CTRL2 (0x3036) = 0x54
> >>> OV5640_REG_SC_PLL_CTRL3 (0x3037) = 0x07
> >>>
> >>> Your new code that calculates the clock rates dynamically ends up with
> >>> different values however:
> >>>
> >>> OV5640_REG_SC_PLL_CTRL1 (0x3035) = 0x11
> >>> OV5640_REG_SC_PLL_CTRL2 (0x3036) = 0xa8
> >>> OV5640_REG_SC_PLL_CTRL3 (0x3037) = 0x03
> >>>
> >>> Interestingly, leaving the hard-coded values in the array *and* letting
> >>> ov5640_set_mipi_pclk() do its thing later still works. So again it seems
> >>> that writes to registers after 0x3035/0x3036/0x3037 seem to depend on the
> >>> values of these timing registers. You might need to leave these values as
> >>> dummies in the array. Confusing.
> >>>
> >>> Any idea?
> >>>
> >>>
> >>> Thanks,
> >>> Daniel
> >>
> >> This set of patches is also not working for my MIPI platform (mine has
> >> a 12 MHz external clock). I am pretty sure is isn't working because it
> >> does not include the following, which my tests have found to be
> >> necessary:
> >>
> >> 1) Setting pclk period reg in order to correct DPHY timing.
> >> 2) Disabling of MIPI lanes when streaming not enabled.
> >> 3) setting mipi_div to 1 when the scaler is disabled
> >> 4) Doubling ADC clock on faster resolutions.
> >
> > Yeah, I left them out because I didn't think this was relevant to this
> > patchset but should come as future improvements. However, given that
> > it works with the parallel bus, maybe the two first are needed when
> > adjusting the rate.
> >
> I agree that 1-4 are separate improvements to MIPI mode that may not
> affect all modules. They do break mine, but that has been true since
> the driver was released (mainly because of my 12 MHz clock and more
> stringent CSI RX requirements). So it makes sense for me to address
> them in a follow-up series. But I do think that we should get the
> clock generation a little closer to what I know works for MIPI so we
> don't break things for people that do have MIPI working.
>
> > The mipi divider however seems to be a bit more complicated than you
> > report here. It is indeed set to 1 when the scaler is enabled (all
> > resolutions > 1280 * 960), but it's also set to 4 in some cases
> > (640x480@30, 320x240@30, 176x144@30). I couldn't really find any
> > relationship between the resolution/framerate and whether to use a
> > divider of 2 or 4.
>
> I didn't notice the divide by 4, interesting. I have a theory
> though... it could be that the constraint of PCLK relative to SCLK is:
>
> SCLK*(cpp/scaler ratio)<=PCLK<= ?
> cpp=Components/pixel (1 for JPEG, 2 for YUV, e.g.)
>
> Since the scaler is in auto mode, the scaler ratio might automatically
> change depending on the resolution selected, something like (using int
> math):
>
> (hTotal/hActive) * (vTotal/vActive) = scaler ratio
>
> If SCLK is responsible for reading the data into the scaler, and PCLK
> is responsible for reading data out to the physical interface, this
> would make sense. It will require more experiments to verify any of
> this, though, and unfortunately I don't have a lot of time to put into
> this right now.
>
> On my platform I have also run into an upper bound for PCLK, where it
> seems that PCLK must be <= SCLK when the scaler is enabled. I think
> this may have to do with some of my platform's idiosyncrasies, so I'm
> not
Re: [PATCH] media: soc_camera: ov772x: correct setting of banding filter
Hi Mita-san,
On Mon, Jun 11, 2018 at 12:42:26AM +0900, Akinobu Mita wrote:
> The banding filter ON/OFF is controlled via bit 5 of COM8 register. It
> is attempted to be enabled in ov772x_set_params() by the following line.
>
> ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, 1);
>
> But this unexpectedly results disabling the banding filter, because the
> mask and set bits are exclusive.
>
> On the other hand, ov772x_s_ctrl() correctly sets the bit by:
>
> ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, BNDF_ON_OFF);
>
> The same fix was already applied to non-soc_camera version of ov772x
> driver in the commit commit a024ee14cd36 ("media: ov772x: correct setting
> of banding filter")
This driver is aimed for removal, but until it's there, as per the
patch you mentioned:
Acked-by: Jacopo Mondi
Thanks
j
>
> Cc: Jacopo Mondi
> Cc: Laurent Pinchart
> Cc: Hans Verkuil
> Cc: Sakari Ailus
> Cc: Mauro Carvalho Chehab
> Signed-off-by: Akinobu Mita
> ---
> drivers/media/i2c/soc_camera/ov772x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/soc_camera/ov772x.c
> b/drivers/media/i2c/soc_camera/ov772x.c
> index 8063835..14377af 100644
> --- a/drivers/media/i2c/soc_camera/ov772x.c
> +++ b/drivers/media/i2c/soc_camera/ov772x.c
> @@ -834,7 +834,7 @@ static int ov772x_set_params(struct ov772x_priv *priv,
>* set COM8
>*/
> if (priv->band_filter) {
> - ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, 1);
> + ret = ov772x_mask_set(client, COM8, BNDF_ON_OFF, BNDF_ON_OFF);
> if (!ret)
> ret = ov772x_mask_set(client, BDBASE,
> 0xff, 256 - priv->band_filter);
> --
> 2.7.4
>
signature.asc
Description: PGP signature
[PATCH 0/2] media: i2c: mt9v111 sensor driver
Hello, this is a sensor level driver for Aptina MT9V111. The driver supports YUYV_2X8 output formats and VGA,QVGA,QQVGA,CIF and QCIF resolution. The driver allows control of frame rate through s_frame_interval or V4L2_CID_H/VBLANK control. In order to allow manual frame control, the chip is initialized with auto-exposure control, auto white balancing and flickering control disabled. Tested VGA, QVGA QQVGA resolutions at 5, 10, 15 and 30 frame per second. Thanks j Jacopo Mondi (2): dt-bindings: media: i2c: Document MT9V111 bindings media: i2c: Add driver for Aptina MT9V111 .../bindings/media/i2c/aptina,mt9v111.txt | 46 + MAINTAINERS|8 + drivers/media/i2c/Kconfig | 12 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/mt9v111.c| 1297 5 files changed, 1364 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt create mode 100644 drivers/media/i2c/mt9v111.c -- 2.7.4
[PATCH 1/2] dt-bindings: media: i2c: Document MT9V111 bindings
Add documentation for Aptina MT9V111 image sensor.
Signed-off-by: Jacopo Mondi
---
.../bindings/media/i2c/aptina,mt9v111.txt | 46 ++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
new file mode 100644
index 000..bac4bf0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt
@@ -0,0 +1,46 @@
+* Aptina MT9V111 CMOS sensor
+
+
+The Aptina MT9V111 is a 1/4-Inch VGA-format digital image sensor with a core
+based on Aptina MT9V011 sensor and an integrated Image Flow Processor (IFP).
+
+The sensor has an active pixel array of 649x489 pixels and can output a number
+of image resolution and formats controllable through a simple two-wires
+interface.
+
+Required properties:
+
+
+- compatible: shall be "aptina,mt9v111".
+- clocks: reference to the system clock input provider.
+
+Optional properties:
+
+
+- enable-gpios: output enable signal, pin name "OE#". Active low.
+- standby-gpios: low power state control signal, pin name "STANDBY".
+ Active high.
+- reset-gpios: chip reset signal, pin name "RESET#". Active low.
+
+The device node must contain one 'port' child node with one 'endpoint' child
+sub-node for its digital output video port, in accordance with the video
+interface bindings defined in:
+Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+
+
+ {
+camera@48 {
+compatible = "aptina,mt9v111";
+reg = <0x48>;
+
+clocks = <_clk>;
+
+port {
+mt9v111_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
--
2.7.4
[PATCH 2/2] media: i2c: Add driver for Aptina MT9V111
Add V4L2 sensor driver for Aptina MT9V111 CMOS image sensor. The MT9V111 is a 1/4-Inch CMOS image sensor based on MT9V011 with an integrated Image Flow Processor. Signed-off-by: Jacopo Mondi --- MAINTAINERS |8 + drivers/media/i2c/Kconfig | 12 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/mt9v111.c | 1297 +++ 4 files changed, 1318 insertions(+) create mode 100644 drivers/media/i2c/mt9v111.c diff --git a/MAINTAINERS b/MAINTAINERS index a38e24a..2c2fe60 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9523,6 +9523,14 @@ F: Documentation/devicetree/bindings/media/i2c/mt9v032.txt F: drivers/media/i2c/mt9v032.c F: include/media/i2c/mt9v032.h +MT9V111 APTINA CAMERA SENSOR +M: Jacopo Mondi +L: linux-media@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +S: Maintained +F: Documentation/devicetree/bindings/media/i2c/aptina,mt9v111.txt +F: drivers/media/i2c/mt9v111.c + MULTIFUNCTION DEVICES (MFD) M: Lee Jones T: git git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 341452f..0bd867d 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -841,6 +841,18 @@ config VIDEO_MT9V032 This is a Video4Linux2 sensor-level driver for the Micron MT9V032 752x480 CMOS sensor. +config VIDEO_MT9V111 + tristate "Aptina MT9V111 sensor support" + depends on I2C && VIDEO_V4L2 + depends on MEDIA_CAMERA_SUPPORT + depends on OF + help + This is a Video4Linux2 sensor-level driver for the Aptina/Micron + MT9V111 sensor. + + To compile this driver as a module, choose M here: the + module will be called mt9v111. + config VIDEO_SR030PC30 tristate "Siliconfile SR030PC30 sensor support" depends on I2C && VIDEO_V4L2 diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index d679d57..f0e8618 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -84,6 +84,7 @@ obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o obj-$(CONFIG_VIDEO_MT9T112) += mt9t112.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o +obj-$(CONFIG_VIDEO_MT9V111) += mt9v111.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o diff --git a/drivers/media/i2c/mt9v111.c b/drivers/media/i2c/mt9v111.c new file mode 100644 index 000..36e7424 --- /dev/null +++ b/drivers/media/i2c/mt9v111.c @@ -0,0 +1,1297 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * V4L2 sensor driver for Aptina MT9V111 image sensor + * Copyright (C) 2018 Jacopo Mondi + * + * Based on mt9v032 driver + * Copyright (C) 2010, Laurent Pinchart + * Copyright (C) 2008, Guennadi Liakhovetski + * + * Base on mt9v011 driver + * Copyright (c) 2009 Mauro Carvalho Chehab + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +/* + * MT9V111 is a 1/4-Inch CMOS digital image sensor with an integrated + * Image Flow Processing (IFP) engine and a sensor core loosely based on + * MT9V011. + * + * The IFP can produce several output image formats from the sensor core + * output, this driver currently supports only YUYV format permutations. + * + * As the auto exposure algorithms controls exposure time and modifies the + * frame rate, this driver disables auto exposure control, auto white balancing + * and auto flickering avoidance to allow manual frame rate control through + * s_frame_interval subdev operation or V4L2_CID_V/HBLANK controls. + * + * While it seems possible to instruct the auto-exposure control algorithm to + * respect a programmed frame rate when adjusting the pixel integration time, + * registers controlling this feature are not documented in the public + * available sensor manual used to develop this driver (09005aef80e90084, + * MT9V111_1.fm - Rev. G 1/05 EN). + */ + +#define MT9V111_CHIP_ID_HIGH 0x82 +#define MT9V111_CHIP_ID_LOW0x3a + +#define MT9V111_R01_ADDR_SPACE 0x01 +#define MT9V111_R01_IFP0x01 +#define MT9V111_R01_CORE 0x04 + +#define MT9V111_IFP_R06_OPMODE_CTRL0x06 +#defineMT9V111_IFP_R06_OPMODE_CTRL_AWB_EN BIT(1) +#defineMT9V111_IFP_R06_OPMODE_CTRL_AE_EN BIT(14) +#define MT9V111_IFP_R07_IFP_RESET 0x07 +#defineMT9V111_IFP_R07_IFP_RESET_MASK BIT(0) +#define MT9V111_IFP_R08_OUTFMT_CTRL0x08 +#defineMT9V111_IFP_R08_OUTFMT_CTRL_FLICKER BIT(11) +#defineMT9V111_I
Re: [ANN v2] Complex Camera Workshop - Tokyo - Jun, 19
Hi Mauro, On Mon, Jun 04, 2018 at 10:33:03AM -0300, Mauro Carvalho Chehab wrote: > Hi all, [snip] > 4.1 Physical Attendees > == > > Tomasz Figa > Mauro Carvalho Chehab > Kieran Bingham > Laurent Pinchart > Niklas Söderlund > Zheng, Jian Xu Zheng > > Anywone else? Sorry, I've not listed myself in reply to the previous email. As I'll be in Tokyo for OSS, I would like to join you for the meeting. Thanks j signature.asc Description: PGP signature
[PATCH] media: i2c: ov7670: Put ep fwnode after use
The just parsed endpoint fwnode has to be put after use.
Currently this is done only in error handling path. Fix that by putting node
unconditionally after use.
Fixes: 01b8444828fc ("media: v4l2: i2c: ov7670: Implement OF mbus
configuration")
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/ov7670.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 3474ef83..31bf577 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1744,14 +1744,12 @@ static int ov7670_parse_dt(struct device *dev,
return -EINVAL;
ret = v4l2_fwnode_endpoint_parse(ep, _cfg);
- if (ret) {
- fwnode_handle_put(ep);
+ fwnode_handle_put(ep);
+ if (ret)
return ret;
- }
if (bus_cfg.bus_type != V4L2_MBUS_PARALLEL) {
dev_err(dev, "Unsupported media bus type\n");
- fwnode_handle_put(ep);
return ret;
}
info->mbus_config = bus_cfg.bus.parallel.flags;
--
2.7.4
[PATCH 0/5] Remove sh_mobile_ceu_camera from arch/sh
Hello, this series removes dependencies on the soc_camera based sh_mobile_ceu_camera driver from 3 board files in arch/sh and from one sensor driver used by one of those boards. Hans, this means there are no more user of the soc_camera framework that I know of in Linux, and I guess we can now plan of to remove that framework. A note on the sensor driver: I haven't been able to find any documentation for the SHARP RJ54N1CB0C sensor and so I inferred as much as possible from the existing code. It seems to me that the sensor needs to power-up/enable gpios (both active high) and I have registered them from the kfr2r09 board file, assuming this was not a platform-specific design, but something the sensor requires. As per the previous drivers ported away from soc_camera, I'm in favour of moving them to staging if they do not match the quality expected from a modern V4L2 sensor driver. Ie. framerate control is missing, and I know this has been a blocker for other drivers in the past. What I've done to three board files closely resembles what I done already for Migo-R and Ecovec, and it listed in the single commit messages. The only tough one is probably ap325rxa, which had an additional sensor registered but controlled from i2c transaction of magic blobs from the board file. I dare to remove that sensor registration completely as it seems to me there is no diver for that at all in mainline. Last, this patch is based on the media tree master branch, with Akinobu Mita's patches on ov772x driver on top, which I strangely see only partially applied to the media master tree [1] Hans, as this is mostly media-related work, but mostly on SH architecture, I would like to ask if these should go through you or SH tree. All of that has only been compile tested. It's pretty hard to find this platforms around and testing would be awesome if somebody happens to have one of these. Thanks j [1] https://patchwork.linuxtv.org/patch/49318/ https://patchwork.linuxtv.org/patch/49317/ https://patchwork.linuxtv.org/patch/49312/ Jacopo Mondi (5): media: i2c: Copy rj54n1cb0c soc_camera sensor driver media: i2c: rj54n1: Remove soc_camera dependencies arch: sh: kfr2r09: Use new renesas-ceu camera driver arch: sh: ms7724se: Use new renesas-ceu camera driver arch: sh: ap325rxa: Use new renesas-ceu camera driver arch/sh/boards/mach-ap325rxa/setup.c | 282 ++- arch/sh/boards/mach-kfr2r09/setup.c| 216 +++-- arch/sh/boards/mach-se/7724/setup.c| 120 ++- arch/sh/kernel/cpu/sh4a/clock-sh7723.c |2 +- drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/rj54n1cb0c.c | 1437 7 files changed, 1710 insertions(+), 359 deletions(-) create mode 100644 drivers/media/i2c/rj54n1cb0c.c -- 2.7.4
[PATCH 3/5] arch: sh: kfr2r09: Use new renesas-ceu camera driver
Use the new renesas-ceu camera driver in kfr2r09 board file instead of
the soc_camera based sh_mobile_ceu_camera driver.
Get rid of soc_camera specific components, and move clk and gpio handling
away from board file, registering the clock source and the enable gpios
for driver consumption.
Memory for the CEU video buffers is now reserved with membocks APIs,
and need to be declared as dma_coherent during machine initialization to
remove that architecture specific part from CEU driver.
While at there update license to SPDX header and sort headers alphabetically.
No need to udapte the clock source names, as
commit c2f9b05fd5c1 ("media: arch: sh: ecovec: Use new renesas-ceu camera
driver")
already updated it to the new ceu driver name for all SH7724 boards (possibly
breaking kfr2r09 before this commit).
Compile tested only.
Signed-off-by: Jacopo Mondi <jacopo+rene...@jmondi.org>
---
arch/sh/boards/mach-kfr2r09/setup.c | 217 +---
1 file changed, 103 insertions(+), 114 deletions(-)
diff --git a/arch/sh/boards/mach-kfr2r09/setup.c
b/arch/sh/boards/mach-kfr2r09/setup.c
index 6af..e59c577 100644
--- a/arch/sh/boards/mach-kfr2r09/setup.c
+++ b/arch/sh/boards/mach-kfr2r09/setup.c
@@ -1,41 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* KFR2R09 board support code
*
* Copyright (C) 2009 Magnus Damm
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
*/
-#include
-#include
-#include
-#include
-#include
-#include
-#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include
#include
-#include
+#include
#include
+#include
+#include
+#include
#include
#include
-#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
+#include
#include
#include
+#include
#include
#include
-#include
+
+#include
+
+#include
#include
-#include
-#include
+
#include
-#include
-#include
-#include
-#include
-#include
-#include
+
+#define CEU_BUFFER_MEMORY_SIZE (4 << 20)
+static phys_addr_t ceu_dma_membase;
+
+/* set VIO_CKO clock to 25MHz */
+#define CEU_MCLK_FREQ 2500
+#define DRVCRB 0xA405018C
static struct mtd_partition kfr2r09_nor_flash_partitions[] =
{
@@ -230,8 +242,17 @@ static struct platform_device kfr2r09_usb0_gadget_device =
{
.resource = kfr2r09_usb0_gadget_resources,
};
-static struct sh_mobile_ceu_info sh_mobile_ceu_info = {
- .flags = SH_CEU_FLAG_USE_8BIT_BUS,
+static struct ceu_platform_data ceu_pdata = {
+ .num_subdevs= 1,
+ .subdevs = {
+ { /* [0] = rj54n1cb0c */
+ .flags = 0,
+ .bus_width = 8,
+ .bus_shift = 0,
+ .i2c_adapter_id = 1,
+ .i2c_address= 0x50,
+ },
+ },
};
static struct resource kfr2r09_ceu_resources[] = {
@@ -246,109 +267,35 @@ static struct resource kfr2r09_ceu_resources[] = {
.end= evt2irq(0x880),
.flags = IORESOURCE_IRQ,
},
- [2] = {
- /* place holder for contiguous memory */
- },
};
static struct platform_device kfr2r09_ceu_device = {
- .name = "sh_mobile_ceu",
+ .name = "renesas-ceu",
.id = 0, /* "ceu0" clock */
.num_resources = ARRAY_SIZE(kfr2r09_ceu_resources),
.resource = kfr2r09_ceu_resources,
.dev= {
- .platform_data = _mobile_ceu_info,
+ .platform_data = _pdata,
},
};
-static struct i2c_board_info kfr2r09_i2c_camera = {
- I2C_BOARD_INFO("rj54n1cb0c", 0x50),
-};
-
-static struct clk *camera_clk;
-
-/* set VIO_CKO clock to 25MHz */
-#define CEU_MCLK_FREQ 2500
-
-#define DRVCRB 0xA405018C
-static int camera_power(struct device *dev, int mode)
-{
- int ret;
-
- if (mode) {
- long rate;
-
- camera_clk = clk_get(NULL, "video_clk");
- if (IS_ERR(camera_clk))
- return PTR_ERR(camera_clk);
-
- rate = clk_round_rate(camera_clk, CEU_MCLK_FREQ);
- ret = clk_set_rate(camera_clk, rate);
- if (ret < 0)
- goto eclkrate;
-
- /* set DRVCRB
-*
-* use 1.8 V for VccQ_VIO
-* use 2.85V for VccQ_SR
-*/
- __raw_writew((__raw_readw(DRVCRB) & ~0x0003) | 0x0001, DRVCRB);
-
- /* reset clear */
- ret = gpio_request(GPIO_PTB4, NULL);
- if (ret < 0)
- goto eptb4;
- ret = gp
