On 20/06/16 11:16, Gary Bisson wrote:
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?
Yes, it uses the GPIO on the PWM3 pin (beats me why...) so I had to
specifically disable it to stop the pin muxing clash.
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.
Ah ok, makes sense.
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
