Hi Laurent,
On 02/18/2012 02:43 AM, Laurent Pinchart wrote:
> On Saturday 18 February 2012 00:33:23 Sylwester Nawrocki wrote:
>> On 02/18/2012 12:23 AM, Laurent Pinchart wrote:
>>>> config); @@ -321,6 +329,8 @@ struct v4l2_subdev_video_ops {
>>>>
>>>> struct v4l2_mbus_config *cfg);
>>>>
>>>> int (*s_mbus_config)(struct v4l2_subdev *sd,
>>>>
>>>> const struct v4l2_mbus_config *cfg);
>>>>
>>>> + int (*g_embedded_data)(struct v4l2_subdev *sd, unsigned int *size,
>>>> + void **buf);
>>>>
>>>> };
>>>
>>> How is the embedded data transferred from the sensor to the host in your
>>> case ? Over I2C ?
>>
>> It's transferred over MIPI-CSI2 bus and is intercepted by the MIPI-CSI2
>> receiver, before the image data DMA. The MIPI-CSI2 doesn't have its own
>> DMA engine. More details can be found in patch 6/6.
>
> As the data is transmitted by the device without any polling from the host,
> shouldn't it just go to a metadata plane in the V4L2 buffer ?
That would be more correct and more optimal from performance perspective.
However I was a bit concerned about synchronization between two interrupt
handlers and over complicating subdev-host interface.
On the other hand even now I do rely on proper interrupts' sequence and
it shouldn't be difficult to make the subdev write directly to the metadata
plane.
As far as the timing is concerned, in my case it was taking about 300 us
to copy metadata from the MIPI-CSI receiver IO memory to the subdev's
internal buffer and about 5 us to copy it again from that buffer to V4L2
buffer metadata plane. So I wasn't concerned much about the additional
latency. Nevertheless the numbers may be different in other cases.
As I really don't consider exposing a video node by the MIPI-CSIS driver
I'm wondering if we need some kind of buffer operations at v4l2_subdev
interface, that would be used only in kernel space ?
For example queue_buffer/dequeue_buffer callbacks, what do you think about
it ?
--
Regards,
Sylwester
--
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
