Jack, All, On Mon, Jun 20, 2016 at 10:44:44AM +0100, Jack Mitchell wrote: > <snip> > > I've tried that patch have a some comments: > > - When applied, no capture shows up any more, instead I have two m2m > > v4l2 devices [1]. > > - OV5640 Mipi is assigned the same address as OV5642, therefore both > > Yes, I only have one device attached in my scenario.
Thanks for confirming. > > can't work at the same time right now. There's a register in the > > camera that allows to modify its I2C address, see this patch [2]. > > - How is the mclk working in this patch? It should be using the PWM3 > > As mentioned I have an eCon sensor board [1] which generates it's own clock > on the board and as such I don't need the PWM signal, just the two GPIOs. Oh ok, thanks I didn't this sensor board was different than ours [1]. But in your patch, you specifically disable pwm3, what's the reason for it? > > output to generate a ~22MHz clock. I would expect the use of a > > pwm-clock node [3]. > > > > Also another remark on both OV5642 and OV5640 patches, is it recommended > > to use 0x80000000 pin muxing value? This leaves it to the bootloader to > > I also wondered about this, but didn't know if the pinmux driver did this > based on the define name? I tried it both ways and it worked so I just left > it as it was. Actually my phrasing is wrong, the muxing is ok. Yes depending on the name a pin will be muxed to one function or another. The problem is the pad configuration (pull-up, pull-down etc..). I am not surprised that it works, because the bootloader should properly set those. But it would be safer IMO not to rely on it. Regards, Gary [1] https://boundarydevices.com/product/nit6x_5mp_mipi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
