> > I think I get it, but just to clarify...currently, I'm going with the
> > patch in [1], and I currently have multiple subdevs (sensors) hooked
> > up and working with my soc-camera host driver. [2] was an alternate
> > implementation, right? (as in, I don't need it).
>
> No. [1] you don't nee
> On Tue, 4 Nov 2014, Andrew Chew wrote:
>
> > Hello, Guennadi
> >
> > I was wondering if you can provide some advice as to how focuser vcm
> > devices would fit into the soc-camera framework. We have a raw sensor
> > (an IMX219) with an AD5823 VCM (it's
> > A simpler approach seems to be to only load the driver,
> when streaming is
> > required. Yes, it would add a (considerable) delay to
> streaming begin, but
> > you'd be completely honest to your user and privacy would
> be guaranteed.
>
> The delay will likely be close to the one introdu
> > One way to solve this can be to defer these I2C
> transactions in the image sensor driver all the way up
> > to the time the image sensor is asked to start streaming
> frames. However, it seems to me that this breaks
> > the spirit of the probe; applications will successfully
> probe for c
I'm looking for some guidance regarding a clean way to support a certain camera
module.
We are using the soc_camera framework, and in particular, the ov9740.c image
sensor driver.
This camera module has the camera activity status LED tied to the image
sensor's power. This is meant as a securi
> > + ret = ov9740_reg_write(client, OV9740_ISP_CTRL1E,
> scale_input_x >> 8);
> > + if (ret)
> > + goto done;
> > + ret = ov9740_reg_write(client, OV9740_ISP_CTRL1F,
> scale_input_x & 0xff);
> > + if (ret)
> > + goto done;
> > + ret = ov9740_reg_write(client, OV9740
> > + /* For suspend/resume. */
> > + struct v4l2_mbus_framefmt current_mf;
> > + int current_enable;
>
> bool?
Are you sure you want this to be a bool? This thing is trying to shadow the
"enable" parameter of the s_stream() callback, and that enable para
> > + /* Width must be a multiple of 4 pixels. */
> > + *width += *width % 4;
>
> No, this doesn't make it a multiple of 4, unless it was
> even;) Just take 5
> as an example. What you really want here is
Geez, you're right. Not sure what was going on in my head when I did this.
Thanks f
> > + { OV9740_MIPI_CTRL00, 0x64 }, /* 0x44 for
> continuous clock */
>
> I think, the choice between continuous and discontinuous CSI-2 clock
> should become configurable. You can only use discontinuous clock with
> hosts, that support it, right? Whereas all hosts must support
> c
> This looks good now, thanks, I'll queue it for 2.6.39. Just
> one question:
>
> On Thu, 17 Feb 2011, ac...@nvidia.com wrote:
>
> > From: Andrew Chew
> >
> > This soc_camera driver is for Omnivision's OV9740 sensor.
> This initial
> &
Reposting. Sorry for the rich text in my previous email.
I'm looking at the videobuf2 stuff, and would like to use it because it solves
a bunch of problems for me that were in videobuf (for example, I'm writing a
variant of videobuf-dma-contig, and there's some private memory allocator state
I
I'm looking at drivers/media/video/videobuf-dma-contig.c's __videobuf_alloc()
routine. We call kzalloc() to allocate the videobuf_buffer. However, I don't
see where the two lists (vb->stream and vb->queue) that are a part of struct
videobuf_buffer get initialized (with, say, INIT_LIST_HEAD).
12 matches
Mail list logo
