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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote on Fri [2019-Feb-22 15:39:59 +0100]:
> On Thu, Feb 21, 2019 at 10:20:20AM -0600, Benoit Parrot wrote:
> > Hi Maxime,
> > 
> > A couple of questions,
> > 
> > Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote on Thu [2018-Oct-11 04:21:00 -0500]:
> > > The clock rate, while hardcoded until now, is actually a function of the
> > > resolution, framerate and bytes per pixel. Now that we have an algorithm to
> > > adjust our clock rate, we can select it dynamically when we change the
> > > mode.
> > > 
> > > This changes a bit the clock rate being used, with the following effect:
> > > 
> > > +------+------+------+------+-----+-----------------+----------------+-----------+
> > > | Hact | Vact | Htot | Vtot | FPS | Hardcoded clock | Computed clock | Deviation |
> > > +------+------+------+------+-----+-----------------+----------------+-----------+
> > > |  640 |  480 | 1896 | 1080 |  15 |        56000000 |       61430400 | 8.84 %    |
> > > |  640 |  480 | 1896 | 1080 |  30 |       112000000 |      122860800 | 8.84 %    |
> > > | 1024 |  768 | 1896 | 1080 |  15 |        56000000 |       61430400 | 8.84 %    |
> > > | 1024 |  768 | 1896 | 1080 |  30 |       112000000 |      122860800 | 8.84 %    |
> > > |  320 |  240 | 1896 |  984 |  15 |        56000000 |       55969920 | 0.05 %    |
> > > |  320 |  240 | 1896 |  984 |  30 |       112000000 |      111939840 | 0.05 %    |
> > > |  176 |  144 | 1896 |  984 |  15 |        56000000 |       55969920 | 0.05 %    |
> > > |  176 |  144 | 1896 |  984 |  30 |       112000000 |      111939840 | 0.05 %    |
> > > |  720 |  480 | 1896 |  984 |  15 |        56000000 |       55969920 | 0.05 %    |
> > > |  720 |  480 | 1896 |  984 |  30 |       112000000 |      111939840 | 0.05 %    |
> > > |  720 |  576 | 1896 |  984 |  15 |        56000000 |       55969920 | 0.05 %    |
> > > |  720 |  576 | 1896 |  984 |  30 |       112000000 |      111939840 | 0.05 %    |
> > > | 1280 |  720 | 1892 |  740 |  15 |        42000000 |       42002400 | 0.01 %    |
> > > | 1280 |  720 | 1892 |  740 |  30 |        84000000 |       84004800 | 0.01 %    |
> > > | 1920 | 1080 | 2500 | 1120 |  15 |        84000000 |       84000000 | 0.00 %    |
> > > | 1920 | 1080 | 2500 | 1120 |  30 |       168000000 |      168000000 | 0.00 %    |
> > > | 2592 | 1944 | 2844 | 1944 |  15 |        84000000 |      165862080 | 49.36 %   |
> > > +------+------+------+------+-----+-----------------+----------------+-----------+
> > 
> > Is the computed clock above the same for both parallel and CSI2?
> > 
> > I want to add controls for PIXEL_RATE and LINK_FREQ, would you have any
> > quick pointer on taking the computed clock and translating that into the
> > PIXEL_RATE and LINK_FREQ values?
> > 
> > I am trying to use this sensor with TI CAL driver which at the moment uses
> > the PIXEL_RATE values in order to compute ths_settle and ths_term values
> > needed to program the DPHY properly. This is similar in behavior as the way
> > omap3isp relies on this info as well.
> 
> I haven't looked that much into the csi-2 case, but the pixel rate
> should be the same at least.

I'll have to study the way the computed clock is actually calculated for
either case, but if they yield the same number then I would be surprised
that the pixel rate would be the same as in parallel mode you get 8 data
bits per clock whereas in CSI2 using 2 data lanes you get 4 data bits per
clock.

So just to be certain here the "Computed clock" column above would be the
pixel clock frequency?

Benoit

> 
> Maxime
> 
> -- 
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com





[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux