public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Sylwester Nawrocki <snjw23@gmail.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>,
	linux-media@vger.kernel.org, g.liakhovetski@gmx.de,
	sakari.ailus@iki.fi, m.szyprowski@samsung.com,
	riverful.kim@samsung.com, sw0312.kim@samsung.com,
	Kyungmin Park <kyungmin.park@samsung.com>
Subject: Re: [RFC/PATCH 3/6] V4L: Add g_embedded_data subdev callback
Date: Sat, 18 Feb 2012 16:18:16 +0100	[thread overview]
Message-ID: <4F3FC138.4010407@gmail.com> (raw)
In-Reply-To: <4603092.UUnjJ05PXI@avalon>

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

  parent reply	other threads:[~2012-02-18 15:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-16 18:23 [RFC/PATCH 0/6] Interleaved image data on media bus Sylwester Nawrocki
2012-02-16 18:23 ` [RFC/PATCH 1/6] V4L: Add V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 media bus format Sylwester Nawrocki
2012-02-16 19:46   ` Sakari Ailus
2012-02-17 14:26     ` Sylwester Nawrocki
2012-02-17 18:15       ` Sakari Ailus
2012-02-18 15:51         ` Sylwester Nawrocki
2012-02-26 22:25           ` Sakari Ailus
2012-02-27 21:25             ` Sylwester Nawrocki
2012-02-17 23:22       ` Laurent Pinchart
2012-02-16 18:23 ` [RFC/PATCH 2/6] V4L: Add V4L2_PIX_FMT_JPG_YUV_S5C fourcc definition Sylwester Nawrocki
2012-02-16 18:23 ` [RFC/PATCH 3/6] V4L: Add g_embedded_data subdev callback Sylwester Nawrocki
2012-02-17 23:23   ` Laurent Pinchart
2012-02-17 23:33     ` Sylwester Nawrocki
2012-02-18  1:43       ` Laurent Pinchart
2012-02-18  2:20         ` Sakari Ailus
2012-02-18 15:18         ` Sylwester Nawrocki [this message]
2012-02-16 18:23 ` [RFC/PATCH 4/6] V4L: Add get/set_frame_config subdev callbacks Sylwester Nawrocki
2012-02-16 22:44   ` Sakari Ailus
2012-02-17 10:48     ` Sylwester Nawrocki
2012-02-16 18:23 ` [RFC/PATCH 5/6] s5p-fimc: Add support for V4L2_PIX_FMT_JPG_YUYV_S5C fourcc Sylwester Nawrocki
2012-02-16 18:23 ` [RFC/PATCH 6/6] s5p-csis: Add support for non-image data packets capture Sylwester Nawrocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F3FC138.4010407@gmail.com \
    --to=snjw23@gmail.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=kyungmin.park@samsung.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=riverful.kim@samsung.com \
    --cc=s.nawrocki@samsung.com \
    --cc=sakari.ailus@iki.fi \
    --cc=sw0312.kim@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox