Hi Laura, I went through your changes and tried to make a sense out of them. Good job finding them out!
On Mon, Jul 22, 2019 at 05:50:35PM +0200, Laura Nao wrote: > Thanks Fabio! > > I tried tweaking the PLL configuration in the driver and did some further > tests on 5.2 kernel. > > I was finally able to capture RAW frames that match the test pattern for > 1280x720 and 1920x1080 resolutions. The 2592x1944 frame is still not > perfectly aligned, but it looks much closer to the test pattern. > > I uploaded the images here: > > https://imgur.com/a/ywHokMf > > The changes I made in the driver are below. Not sure these changes make much > sense, but they seem to fix 1280x720 and 1920x1080 frames. > As you have reported I have no good images for resolutions < 1280x720 too. > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c > index 759d60c6..cfa678e 100644 > --- a/drivers/media/i2c/ov5640.c > +++ b/drivers/media/i2c/ov5640.c > @@ -795,13 +795,13 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, > u16 reg, > * FIXME: to be re-calcualted for 1 data lanes setups > */ > #define OV5640_MIPI_DIV_PCLK 2 > -#define OV5640_MIPI_DIV_SCLK 1 > +#define OV5640_MIPI_DIV_SCLK 2 > With this change we're now basically always setting MIPI DIV to 2, in both the cases marked in the driver as "scaler" or "non scaler" The best explanation I could give, based on what reported by Sam here and in the follow up email [1] is that when capturing in RAW mode we're always bypassing the ISP scaler, and we're thus acting always in "non-scaler" mode. Recalling the "non verified constraints" mentioned in the past emails: Non-ISP-scaler: MIPI_CLK = 4 ; PCLK = 2; SCLK = 1 ISP-scaler: MIPI_CLK = 8 ; PCLK = 2; SCLK = 1 Your above change makes the system work in Non-ISP-scaler mode for RAW formats. The fact we still have troubles capturing resolution < 1280x720 (the ones described as going through the scaler) makes me suspect my explanation is only not totally correct though. I tried playing a bit around with the dividers in the clock tree without getting much at the moment... I'll keep working on this in the next days and i you have any idea to share I'm all hears... https://www.spinics.net/lists/linux-media/msg141854.html > /* > * 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_ROOT_DIV 1 This is not relevant for MIPI, but only for DVP mode. If you want to bypass the PLL ROOT DIVIDER for MIPI you should change this line: ret = ov5640_mod_reg(sensor, OV5640_REG_SC_PLL_CTRL3, 0x1f, OV5640_PLL_CTRL3_PLL_ROOT_DIV_2 | prediv); and set bit 0x10 to 0 according to the manual. > #define OV5640_PLL_CTRL3_PLL_ROOT_DIV_2 BIT(4) > > /* > @@ -836,8 +836,8 @@ static unsigned long ov5640_compute_sys_clk(struct > ov5640_dev *sensor, > unsigned long sysclk = sensor->xclk_freq / pll_prediv * pll_mult; > > /* PLL1 output cannot exceed 1GHz. */ > - if (sysclk / 1000000 > 1000) > - return 0; > + // if (sysclk / 1000000 > 1000) > + // return 0; This is weird :) I've seen it making a difference sometime, but most of the time it did not. I printed out the PLL1 output configuration at the end of "ov5640_calc_sys_clk()" with: @@ -899,6 +899,9 @@ static unsigned long ov5640_calc_sys_clk(struct ov5640_dev *sensor, *sysdiv = best_sysdiv; *pll_prediv = OV5640_PLL_PREDIV; *pll_mult = best_mult; + pr_err("%s:%d rate %ld - best %ld - PLL1 out %ld - prediv %u - mult %u - sysdiv %u \n", + __func__, __LINE__, rate, best, (best * best_sysdiv), *pll_prediv, *pll_mult, best_sysdiv); + return best; } and with this part commented out I get (for 1280x720) ov5640_calc_sys_clk:902 rate 336019200 - best 338666666 - PLL1 out 1015999998 - prediv 3 - mult 127 - sysdiv 3 While if I keep the 1GHz limit in place I sometimes have half-crippled images and the PLL gets configured as: ov5640_calc_sys_clk:902 rate 336019200 - best 340000000 - PLL1 out 680000000 - prediv 3 - mult 85 - sysdiv 2 Apparently the PLL gets configured with a too fast clock if we remove the limit. Ironic :) There might be some tolerance in the 1GHz limit, or we're hitting a corner case maybe... How often does capture fails for you without this change in and for which resolution... Sorry for not being able to go much further but resurrecting my testing setup took quite some time :) Thanks j > > return sysclk / sysdiv; > } > @@ -1818,7 +1824,7 @@ static int ov5640_set_mode(struct ov5640_dev *sensor) > * All the formats we support have 16 bits per pixel, seems to require > * the same rate than YUV, so we can just use 16 bpp all the time. > */ > - rate = mode->vtot * mode->htot * 16; > + rate = mode->vtot * mode->htot * 8; > rate *= ov5640_framerates[sensor->current_fr]; > if (sensor->ep.bus_type == V4L2_MBUS_CSI2_DPHY) { > rate = rate / sensor->ep.bus.mipi_csi2.num_data_lanes; > > Thanks, > > Best, > > Laura > > On 7/22/19 2:45 PM, Fabio Estevam wrote: > > [Adding Steve and Philipp] > > > > On Thu, Jul 18, 2019 at 10:06 AM Laura Nao <laura....@kynetics.com> wrote: > > > > > > Hello Loic, > > > > > > I'm having some issues with RAW8 mode on the OV5640 camera and I'd like > > > to kindly ask for your advice, as I saw that you added support for RAW > > > mode in the mainline kernel driver. > > > > > > I'm trying to capture some raw images on a i.MX6Q based board. I > > > configured the pipeline as follows: > > > > > > media-ctl -l "'ov5640 1-003c':0 -> 'imx6-mipi-csi2':0[1]" > > > media-ctl -l "'imx6-mipi-csi2':2 -> 'ipu1_csi1':0[1]" > > > media-ctl -l "'ipu1_csi1':2 -> 'ipu1_csi1 capture':0[1]" > > > media-ctl -V "'ov5640 1-003c':0 [fmt:SBGGR8_1X8/2592x1944 field:none]" > > > media-ctl -V "'imx6-mipi-csi2':2 [fmt:SBGGR8_1X8/2592x1944 field:none]" > > > > > > I'm capturing the frame using v4l-utils: > > > > > > v4l2-ctl -d /dev/video5 --verbose --set-fmt > > > video=width=2592,height=1944,pixelformat=BA81 --stream-mmap > > > --stream-count=1 --stream-to=bggr_2592x1944.raw > > > > > > The images I'm obtaining are completely garbled. I tried both 5.2 > > > mainline and 5.1.18 kernels. > > > > > > I'm able to correctly capture YUV frames in all resolutions with the > > > same driver (with the pipeline configured to go through the > > > ipu1_ic_prpenc node first). > > > > > > Do you have any insight on what might be causing these issues? Is the > > > PLL configuration supposed to be changed when RAW8 format is selected? > > > > > > Thanks for your help, > > > > > > Best regards, > > > > > > Laura
signature.asc
Description: PGP signature
