On Fri, Apr 20, 2018 at 04:29:42PM +0200, Daniel Mack wrote:
> Hi,
>
> On Friday, April 20, 2018 04:15 PM, Maxime Ripard wrote:
> > On Fri, Apr 20, 2018 at 11:44:18AM +0200, Daniel Mack wrote:
>
> >> struct ov5640_ctrls {
> >> struct v4l2_ctrl_handler handler;
> >> + struct {
> >> + struct v4l2_ctrl *link_freq;
> >> + struct v4l2_ctrl *pixel_rate;
> >> + };
> >> struct {
> >> struct v4l2_ctrl *auto_exp;
> >> struct v4l2_ctrl *exposure;
> >> @@ -732,6 +752,8 @@ static const struct ov5640_mode_info ov5640_mode_init_data = {
> >> .dn_mode = SUBSAMPLING,
> >> .width = 640,
> >> .height = 480,
> >> + .pixel_rate = 27766666,
> >> + .link_freq_idx = OV5640_LINK_FREQ_111,
> >
> > I'm not sure where this is coming from, but on a parallel sensor I
> > have a quite different pixel rate.
>
> Ah, interesting. What exactly do you mean by 'parallel'? What kind of
> module is that, and what are your pixel rates?
An RGB bus, or MIPI-DPI, or basically a pixel clock + 1 line for each
bit. The sensor can operate using both that bus and a MIPI-CSI2 one.
You have the list of pixel rates in the patch I've linked before:
https://patchwork.linuxtv.org/patch/48710/
There's one pixel sent per clock cycle, so the pixel rate is the same
than the clock rate.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
