Re: [PATCH v4 01/12] media: ov5640: Adjust the clock based on the expected rate
Hi! On Thu, Oct 18, 2018 at 03:46:05PM +0200, jacopo mondi wrote: > Hello Maxime, > > On Thu, Oct 18, 2018 at 11:29:12AM +0200, Maxime Ripard wrote: > > Hi Jacopo, > > > > Thanks for reviewing this patch > > > > On Tue, Oct 16, 2018 at 06:54:50PM +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). I meant to the limits of the PCLK / MIPI bit clock, so the rate we are expected to reach. But I really don't have any opinion on this, so I'll just merge your suggestion for the next version. > > > > > > + if (abs(rate - _rate) < abs(rate - best)) { > > > > + best = _rate; > > > > + best_sysdiv = _sysdiv; > > > > + best_mult = _pll_mult; > > > > + } > > > > + > > > > +
Re: [PATCH v4 01/12] media: ov5640: Adjust the clock based on the expected rate
> On Oct 18, 2018, at 3:03 AM, jacopo mondi wrote: > >> 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). > Don’t worry about it :) > 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 > > I’m fine with this approach, but it takes my ability to easily test your changes on my MIPI platform off the table. I will be around to run some manual tests on your algorithms and answer tech details about my experiments with the sensor, but it will fall on Jacobi to ensure that whatever patch you land on doesn’t introduce a regression for MIPI platforms. I can then submit a PCLK period patch on top of what you end up with, which will then put my platform in the game. Sam
Re: [PATCH v4 01/12] media: ov5640: Adjust the clock based on the expected rate
Hey Jacobi, Not a lot of time to respond right now, these days I’m bouncing around between a couple jobs. I’ll be trying your and Maximes patches and responding to tech details this weekend. Just want to say that as long as we get the driver working I’m happy :) The VAST majority of time put into this has been the reverse engineering effort to understand how the part works. Iterating through various versions takes time as we get on the same page, but will be necessary to make sure we don’t introduce any regressions on any platforms. I don’t think it is time wasted. I don’t think my patch is competing, submitting it was just the best way to communicate what works on my platform. I don’t expect the final patch we land on to be designated as “authored by” me, especially since it was copied mostly from Maximes patch. Also, FYI, I’ve put my other patch series about the ov5640 on hold until we figure this out. Sam Sent from my iPhone > On Oct 17, 2018, at 12:51 PM, 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 :) > > 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, +
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) > > > + goto out; > > > + } > > > + } > > > + > > > +out: > > > + *sysdiv = best_sysdiv; > > > + *pll_prediv = OV5640_PLL_PREDIV; > > > + *pll_mult = best_mult; > > > + return best; > > > +} > > > > These function gets called at s_stream time, and cycle for a while, > > and I'm under the impression the MIPI state machine doesn't like > > delays too much, as I see timeouts on the receiver side. > > > > I have tried to move this function at set_fmt() time, every time a new > > mode is selected, sysdiv, pll_prediv and pll_mult gets recalculated > > (and stored in the ov5640_dev structure). I now have other timeouts on > > mis
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
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? 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
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. 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. > > + > > + 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. > > + if (abs(rate - _rate) < abs(rate - best)) { > > + best = _rate; > > + best_sysdiv = _sysdiv; > > + best_mult = _pll_mult; > > + } > > + > > + if (_rate == rate) > > + goto out; > > + } > > + } > > + > > +out: > > + *sysdiv = best_sysdiv; > > + *pll_prediv = OV5640_PLL_PREDIV; > > + *pll_mult = best_mult; > > + return best; > > +} > > These function gets called at s_stream time, and cycle for a while, > and I'm under the impression the MIPI state machine doesn't like > delays too much, as I see timeouts on the receiver side. > > I have tried to move this function at set_fmt() time, every time a new > mode is selected, sysdiv, pll_prediv and pll_mult gets recalculated > (and stored in the ov5640_dev structure). I now have other timeouts on > missing EOF, but not anymore at startup time it seems. I have no objection caching the values if it solves issues with CSI :) Can you send that patch? 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
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)}, > > > {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,
Re: [PATCH v4 01/12] media: ov5640: Adjust the clock based on the expected rate
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, 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)}, > > {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(ov564
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 01/12] media: ov5640: Adjust the clock based on the expected rate
Hi Maxime, I've recently found a problem around JPEG framerate, see below: On 10/11/2018 11:20 AM, 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, >720, 1896, 480, 9
[PATCH v4 01/12] media: ov5640: Adjust the clock based on the expected rate
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, 720, 1896, 480, 984, +5600, ov5640_setting_30fps_NTSC_720_480, ARRAY_SIZE(ov5640_setting_30fps_NTSC_720_480)}, {OV5640_MODE_PAL_720_576, SUBSAMPL