Re: How to express planar formats with mediabus format code?
Hi Sakari, On Thu, Aug 22, 2013 at 7:29 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Jiaquan, On Wednesday 21 August 2013 18:14:50 Su Jiaquan wrote: On Tue, Aug 20, 2013 at 8:53 PM, Laurent Pinchart wrote: Hi Jiaquan, I'm not sure if that's needed here. Vendor-specific formats still need to be documented, so we could just create a custom YUV format for your case. Let's start with the beginning, could you describe what gets transmitted on the bus when that special format is selected ? For YUV420P format, the data format sent from IPC is similar to V4L2_MBUS_FMT_YUYV8_1_5X8, but the content for each line is different: For odd line, it's YYU YYU YYU... For even line, it's YYV YYV YYV... then DMA engine send them to RAM in planar format. For YUV420SP format, the data format sent from IPC is YYUV YYUV YYUV(maybe called V4L2_MBUS_FMT_YYUV8_2X8?), but DMA engine drop UV every other line, then send them to RAM as semi-planar. V4L2_MBUS_FMT_YYUV8_2X8 looks good to me. Well, the first data format is too odd, I don't have a clue how to call it, do you have suggestion? Maybe V4L2_MBUS_FMT_YU8_YV8_1_5X8 ? I've CC'ed Sakari Ailus, he's often pretty creative for these issues. -- Regards, Laurent Pinchart Does the format V4L2_MBUS_FMT_YU8_YV8_1_5X8 sounds good to you? Do you have better idea how we should describe this format? If there is no further concern, I'll prepare a patch Thanks -- 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
Re: How to express planar formats with mediabus format code?
Hi Laurent, Thanks for the replay, I've removed earlier mail content and only keep you question: On Tue, Aug 20, 2013 at 8:53 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Jiaquan, I'm not sure if that's needed here. Vendor-specific formats still need to be documented, so we could just create a custom YUV format for your case. Let's start with the beginning, could you describe what gets transmitted on the bus when that special format is selected ? -- Regards, Laurent Pinchart For YUV420P format, the data format sent from IPC is similar to V4L2_MBUS_FMT_YUYV8_1_5X8, but the content for each line is different: For odd line, it's YYU YYU YYU... For even line, it's YYV YYV YYV... then DMA engine send them to RAM in planar format. For YUV420SP format, the data format sent from IPC is YYUV YYUV YYUV(maybe called V4L2_MBUS_FMT_YYUV8_2X8?), but DMA engine drop UV every other line, then send them to RAM as semi-planar. Well, the first data format is too odd, I don't have a clue how to call it, do you have suggestion? Thanks a lot! Jiaquan -- 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
Re: A false alarm for recursive lock in v4l2_ctrl_add_handler
Hi Hans, On Wed, Aug 21, 2013 at 7:47 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Wed 21 August 2013 12:56:21 Su Jiaquan wrote: Hi Hans, Recently when we enable LOCKDEP in our kernel, it detected a possible recursive locking. As we check the code, we found that it's just a false alarm, the conceived scenario should never happen. Shell I submit a patch to suppress it? A patch went in for 3.10 that suppresses this false alarm. Regards, Hans Sorry I didn't notice the fix, Is it this one? commit 6cd247ef22e493e1884e576c01538b031981 Author: Andy Walls awa...@md.metrocast.net Date: Sat Mar 9 05:55:11 2013 -0300 [media] v4l2-ctrls: eliminate lockdep false alarms for struct v4l2_ctrl_handler.lock Thanks! Jiaquan -- 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
Re: OMAP3 ISP DQBUF hangs
Hi Tom you are right. it seems that the list of the ccdc has no buffer left, because the printk(TOM ccdc_isr_buffer ERROR 1 ##\n); is shown in my log. But I don't understand what I need to do to solve the problem. What I do is: - configure the pipeline - open the video device - do ioctl VIDIOC_REQBUFS (with memory = V4L2_MEMORY_MMAP and type = V4L2_BUF_TYPE_VIDEO_CAPTURE) - do ioctl VIDIOC_QUERYBUF - do ioctl VIDIOC_STREAMON - do ioctl VIDIOC_QBUF without fail. and when I do ioctl VIDIOC_DQBUF. I get my problem. Does anyone have an idea what I need to do to solve this problem? Well, for our practice, we QBUF before STREAMON (not on omap3 isp). You can try that and see what happens. As I check the omap3 code, you sequence maybe OK. Coz there is a restart mechanism in the code to restart CCDC hardware after buffer underrun. But for you sequence, if the interrupt comes before you QBUF, then the hardware is running in underrun state ever from the STREAMON. Not sure the restart mechanism works in this scenario. Let's wait for answers from the professional :-) Jiaquan -- 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
Re: OMAP3 ISP DQBUF hangs
Hi Tom, On Thu, Aug 15, 2013 at 10:15 PM, Tom bassai_...@gmx.net wrote: Hello, I'm working with an OMAP3 DM3730 processor module with a ov3640 camera module attached on parallel interface. I'm using Linux 3.5 and an application which builds the pipeline and grabs an image like the media-ctl and the yavta tools. I configured the pipeline to: sensor-ccdc-memory When I call ioctl with DQBUF the calling functions are: isp_video_dqbuf - omap3isp_video_queue_dqbuf - isp_video_buffer_wait - wait_event_interruptible The last function waits until the state of the buffer will be reseted somehow. Can someone tell my which function sets the state of the buffer? Am I missing an interrupt? Best Regards, Tom I'm not familar with omap3isp, but from the code, the wait queue is released by function ccdc_isr_buffer-omap3isp_video_buffer_next. You are either missing a interrupt, or running out of buffer, or found a buffer under run. Jiaquan -- 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 -- 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
Re: How to express planar formats with mediabus format code?
Hi Laurent / Guennadi,
On Sat, Aug 10, 2013 at 1:06 AM, Su Jiaquan jiaquan@gmail.com wrote:
Hi Laurent / Guennadi,
On Fri, Aug 9, 2013 at 5:12 AM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi,
On Tuesday 06 August 2013 17:18:14 Su Jiaquan wrote:
Hi Guennadi,
Thanks for the reply! Please see my description inline.
On Mon, Aug 5, 2013 at 5:02 AM, Guennadi Liakhovetski wrote:
On Sun, 4 Aug 2013, Su Jiaquan wrote:
Hi,
I know the title looks crazy, but here is our problem:
In our SoC based ISP, the hardware can be divide to several blocks.
Some blocks can do color space conversion(raw to YUV interleave/planar),
others can do the pixel re-order(interleave/planar/semi-planar
conversion, UV planar switch). We use one subdev to describe each of
them, then came the problem: How can we express the planar formats with
mediabus format code?
Could you please explain more exactly what you mean? How are those your
blocks connected? How do they exchange data? If they exchange data over a
serial bus, then I don't think planar formats make sense, right? Or do
your blocks really output planes one after another, reordering data
internally? That would be odd... If OTOH your blocks output data to RAM,
and the next block takes data from there, then you use V4L2_PIX_FMT_*
formats to describe them and any further processing block should be a
mem2mem device. Wouldn't this work?
These two hardware blocks are both located inside of ISP, and is connected
by a hardware data bus.
Actually, there are three blocks inside ISP: One is close to sensor, and can
do color space conversion(RGB-YUV), we call it IPC; The other two are at
back end, which are basically DMA Engine, and they are identical. When data
flow out of IPC, it can go into each one of these DMA Engines and finally
into RAM. Whether the DMA Engine is turned on/off and the output format can
be controlled independently. Since they are DMA Engines, they have some
basic pixel reordering ability(i.e. interleave-planar/semi-planar).
In our H/W design, when we want to get YUV semi-planar format, the IPC
output should be configured to interleave, and the DMA engine will do the
interleave-semi-planar job. If we want planar / interleave format, the IPC
will output planar format directly, DMA engine simply send the data to RAM,
and don't do any re-order. So in the planar output case, media-bus formats
can't express the format of the data between IPC and DMA Engine, that's the
problem we meet.
If the format between the two subdevs is really planar, I don't see any
problem defining a media bus pixel code for it. You will have to properly
document the format of course.
I'm a bit surprised that the IPC could output planar data. It would need to
buffer a whole image to do so, do you need to give it a temporary system RAM
buffer ?
We want to adopt a formal solution before we send our patch to the
community, that's where our headache comes.
--
Regards,
Laurent Pinchart
Thanks for the reply!
Actually, we don't need to buffer the frame inside IPC, there are
three channels in the data bus. When transfering interleave format,
only one channel is used, for planar formats, three channels send one
planar each, and to difference address(Let me confirm this with our
H/W team and get back to you later). So the planars is not sent one
after an other, but in parallel.
This may be a bit different from the planar formats as people think it
should be. Can we use planar format to describe it? Since this won't
cause any misunderstanding given it's used in this special case.
Please advice.
Thanks a lot!
Jiaquan
I have to say I'm sorry for the wrong information. I just double
checked with hardware team, and turns out there is only one channel
for the data bus between IPC and ispdma.
If ispdma output planar format, the data format between IPC and ispdma
should be configured to a special format, that is not the same with
any know media-bus format.
So I think what we need is to define vendor-specific media-bus code.
Since others any want to do the same thing, shall we define a base
address for the vendor specific formats? For example:
enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_FIXED = 0x0001,
...
/* JPEG compressed formats - next is 0x4002 */
V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
+ V4L2_MBUS_FMT_PRIVATE_BASE = 0xF001,
};
If you are OK with this, I'll prepare a patch to add it
Thanks!
Jiaquan
--
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
Re: How to express planar formats with mediabus format code?
Hi Laurent / Guennadi, On Fri, Aug 9, 2013 at 5:12 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi, On Tuesday 06 August 2013 17:18:14 Su Jiaquan wrote: Hi Guennadi, Thanks for the reply! Please see my description inline. On Mon, Aug 5, 2013 at 5:02 AM, Guennadi Liakhovetski wrote: On Sun, 4 Aug 2013, Su Jiaquan wrote: Hi, I know the title looks crazy, but here is our problem: In our SoC based ISP, the hardware can be divide to several blocks. Some blocks can do color space conversion(raw to YUV interleave/planar), others can do the pixel re-order(interleave/planar/semi-planar conversion, UV planar switch). We use one subdev to describe each of them, then came the problem: How can we express the planar formats with mediabus format code? Could you please explain more exactly what you mean? How are those your blocks connected? How do they exchange data? If they exchange data over a serial bus, then I don't think planar formats make sense, right? Or do your blocks really output planes one after another, reordering data internally? That would be odd... If OTOH your blocks output data to RAM, and the next block takes data from there, then you use V4L2_PIX_FMT_* formats to describe them and any further processing block should be a mem2mem device. Wouldn't this work? These two hardware blocks are both located inside of ISP, and is connected by a hardware data bus. Actually, there are three blocks inside ISP: One is close to sensor, and can do color space conversion(RGB-YUV), we call it IPC; The other two are at back end, which are basically DMA Engine, and they are identical. When data flow out of IPC, it can go into each one of these DMA Engines and finally into RAM. Whether the DMA Engine is turned on/off and the output format can be controlled independently. Since they are DMA Engines, they have some basic pixel reordering ability(i.e. interleave-planar/semi-planar). In our H/W design, when we want to get YUV semi-planar format, the IPC output should be configured to interleave, and the DMA engine will do the interleave-semi-planar job. If we want planar / interleave format, the IPC will output planar format directly, DMA engine simply send the data to RAM, and don't do any re-order. So in the planar output case, media-bus formats can't express the format of the data between IPC and DMA Engine, that's the problem we meet. If the format between the two subdevs is really planar, I don't see any problem defining a media bus pixel code for it. You will have to properly document the format of course. I'm a bit surprised that the IPC could output planar data. It would need to buffer a whole image to do so, do you need to give it a temporary system RAM buffer ? We want to adopt a formal solution before we send our patch to the community, that's where our headache comes. -- Regards, Laurent Pinchart Thanks for the reply! Actually, we don't need to buffer the frame inside IPC, there are three channels in the data bus. When transfering interleave format, only one channel is used, for planar formats, three channels send one planar each, and to difference address(Let me confirm this with our H/W team and get back to you later). So the planars is not sent one after an other, but in parallel. This may be a bit different from the planar formats as people think it should be. Can we use planar format to describe it? Since this won't cause any misunderstanding given it's used in this special case. Please advice. Thanks a lot! Jiaquan -- 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
Re: How to express planar formats with mediabus format code?
Hi Guennadi, Thanks for the reply! Please see my description inline. On Mon, Aug 5, 2013 at 5:02 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Su Jiaquan On Sun, 4 Aug 2013, Su Jiaquan wrote: Hi, I know the title looks crazy, but here is our problem: In our SoC based ISP, the hardware can be divide to several blocks. Some blocks can do color space conversion(raw to YUV interleave/planar), others can do the pixel re-order(interleave/planar/semi-planar conversion, UV planar switch). We use one subdev to describe each of them, then came the problem: How can we express the planar formats with mediabus format code? Could you please explain more exactly what you mean? How are those your blocks connected? How do they exchange data? If they exchange data over a serial bus, then I don't think planar formats make sense, right? Or do your blocks really output planes one after another, reordering data internally? That would be odd... If OTOH your blocks output data to RAM, and the next block takes data from there, then you use V4L2_PIX_FMT_* formats to describe them and any further processing block should be a mem2mem device. Wouldn't this work? These two hardware blocks are both located inside of ISP, and is connected by a hardware data bus. Actually, there are three blocks inside ISP: One is close to sensor, and can do color space conversion(RGB-YUV), we call it IPC; The other two are at back end, which are basically DMA Engine, and they are identical. When data flow out of IPC, it can go into each one of these DMA Engines and finally into RAM. Whether the DMA Engine is turned on/off and the output format can be controlled independently. Since they are DMA Engines, they have some basic pixel reordering ability(i.e. interleave-planar/semi-planar). In our H/W design, when we want to get YUV semi-planar format, the IPC output should be configured to interleave, and the DMA engine will do the interleave-semi-planar job. If we want planar / interleave format, the IPC will output planar format directly, DMA engine simply send the data to RAM, and don't do any re-order. So in the planar output case, media-bus formats can't express the format of the data between IPC and DMA Engine, that's the problem we meet. We want to adopt a formal solution before we send our patch to the community, that's where our headache comes. Thanks Guennadi I understand at beginning, media-bus was designed to describe the data link between camera sensor and camera controller, where sensor is described in subdev. So interleave formats looks good enough at that time. But now as Media-controller is introduced, subdev can describe a much wider range of hardware, which is not limited to camera sensor. So now planar formats are possible to be passed between subdevs. I think the problem we meet can be very common for SoC based ISP solutions, what do you think about it? there are many possible solution for it: 1 change the definition of v4l2_subdev_format::format, use v4l2_format; 2 extend the mediabus format code, add planar format code; 3 use a extra bit to tell the meaning of v4l2_mbus_framefmt::code, is it in mediabus-format or in fourcc Do you have any suggestions? Thanks a lot! -- 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 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Thanks! Jiaquan -- 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
How to express planar formats with mediabus format code?
Hi, I know the title looks crazy, but here is our problem: In our SoC based ISP, the hardware can be divide to several blocks. Some blocks can do color space conversion(raw to YUV interleave/planar), others can do the pixel re-order(interleave/planar/semi-planar conversion, UV planar switch). We use one subdev to describe each of them, then came the problem: How can we express the planar formats with mediabus format code? I understand at beginning, media-bus was designed to describe the data link between camera sensor and camera controller, where sensor is described in subdev. So interleave formats looks good enough at that time. But now as Media-controller is introduced, subdev can describe a much wider range of hardware, which is not limited to camera sensor. So now planar formats are possible to be passed between subdevs. I think the problem we meet can be very common for SoC based ISP solutions, what do you think about it? there are many possible solution for it: 1 change the definition of v4l2_subdev_format::format, use v4l2_format; 2 extend the mediabus format code, add planar format code; 3 use a extra bit to tell the meaning of v4l2_mbus_framefmt::code, is it in mediabus-format or in fourcc Do you have any suggestions? Thanks a lot! -- 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
[no subject]
Hi Guennadi, I found in soc_camera when video device is opened, default format is applied sensor. I think this is the right thing to do, be it also means a lot of i2c transactions. I think in case of app wants to query drivers capability, it do a quick open-query-close, expecting only to get some information rather than really configuring camera. So maybe this is a point that can be optimize. Have you consider postpone it to some point later, how about, say, before stream_on? At that point we can check if VIDIOC_S_FMT is called, if yes, we do nothing, if no, we can configure the default format. I simply move some code from soc_camera_open() to soc_camera_set_fmt(), just a few changes, do you think it OK to make this adjustment? Thanks! Jiaquan -- 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
[media] soc_camera: suggest to postpone applying default format
Hi Guennadi, I found in soc_camera when video device is opened, default format is applied sensor. I think this is the right thing to do, be it also means a lot of i2c transactions. I think in case of app wants to query drivers capability, it do a quick “open-query-close”, expecting only to get some information rather than really configuring camera. So maybe this is a point that can be optimize. Have you consider postpone it to some point later, how about, say, before stream_on? At that point we can check if VIDIOC_S_FMT is called, if yes, we do nothing, if no, we can configure the default format. I simply move some code from soc_camera_open() to soc_camera_set_fmt(), just a few changes, do you think it OK to make this adjustment? Thanks! Jiaquan -- 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
