All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Su Jiaquan <jiaquan.lnx@gmail.com>
Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
	linux-media <linux-media@vger.kernel.org>,
	jqsu@marvell.com, xzhao10@marvell.com
Subject: Re: How to express planar formats with mediabus format code?
Date: Thu, 08 Aug 2013 23:12:30 +0200	[thread overview]
Message-ID: <8999977.SY9Wm17vy3@avalon> (raw)
In-Reply-To: <CALxrGmV-SCDntaJGeaCDkuqmdzgk3VEYZG+koj9em+Z4PSG0XQ@mail.gmail.com>

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


  parent reply	other threads:[~2013-08-08 21:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-04  2:32 How to express planar formats with mediabus format code? Su Jiaquan
2013-08-04 21:02 ` Guennadi Liakhovetski
2013-08-06  9:18   ` Su Jiaquan
2013-08-06  9:40     ` Guennadi Liakhovetski
2013-08-08 21:12     ` Laurent Pinchart [this message]
2013-08-09 17:06       ` Su Jiaquan
2013-08-15  8:27         ` Su Jiaquan
2013-08-20 12:53           ` Laurent Pinchart
2013-08-21 10:14             ` Su Jiaquan
2013-08-22 11:29               ` Laurent Pinchart
2013-08-30  7:57                 ` Su Jiaquan
2013-09-01 14:38                   ` Sakari Ailus

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=8999977.SY9Wm17vy3@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=g.liakhovetski@gmx.de \
    --cc=jiaquan.lnx@gmail.com \
    --cc=jqsu@marvell.com \
    --cc=linux-media@vger.kernel.org \
    --cc=xzhao10@marvell.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.