Re: [PATCH v4 33/36] media: imx: redo pixel format enumeration and negotiation
On 02/23/2017 01:10 AM, Philipp Zabel wrote: Hi Steve, On Wed, 2017-02-22 at 15:52 -0800, Steve Longerbeam wrote: Hi Philipp, On 02/16/2017 03:32 AM, Philipp Zabel wrote: On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote: The previous API and negotiation of mbus codes and pixel formats was broken, and has been completely redone. The negotiation of media bus codes should be as follows: CSI: sink pad direct src pad IDMAC src pad - RGB (any)IPU RGB RGB (any) YUV (any)IPU YUV YUV (any) Bayer N/A must be same bayer code as sink The IDMAC src pad should also use the internal 32-bit RGB / YUV format, except if bayer/raw mode is selected, in which case the attached capture video device should only allow a single mode corresponding to the output pad media bus format. The IDMAC source pad is going to memory, so it has left the IPU. Are you sure it should be an internal IPU format? I realize it is linked to a capture device node, and the IPU format could then be translated to a v4l2 fourcc by the capture device, but IMHO this pad is external to the IPU. The CSI IDMAC source pad should describe the format at the connection between the CSI and the IDMAC, just as the icprpvf and icprpenc source pads. The format outside of the IPU is the memory format written by the IDMAC, but that is a memory pixel format and not a media bus format at all. True, it is a memory format. I don't really mind if the CSI and PRP ENC/VF source pads are characterized as IPU internal formats, since they are only used to indicate the colorspace to the capture device. And yes it did simplify the enumeration and try_fmt code a bit. So I went ahead and made the change. Steve That would also make it more straightforward to enumerate the memory pixel formats in the capture device: If the source pad media bus format is 32-bit YUV, enumerate all YUV formats, if it is 32-bit RGB or RGB565, enumerate all rgb formats, otherwise (bayer/raw mode) only allow the specific memory format matching the bus format.
Re: [PATCH v4 33/36] media: imx: redo pixel format enumeration and negotiation
Hi Steve, On Wed, 2017-02-22 at 15:52 -0800, Steve Longerbeam wrote: > Hi Philipp, > > > On 02/16/2017 03:32 AM, Philipp Zabel wrote: > > On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote: > >> The previous API and negotiation of mbus codes and pixel formats > >> was broken, and has been completely redone. > >> > >> The negotiation of media bus codes should be as follows: > >> > >> CSI: > >> > >> sink pad direct src pad IDMAC src pad > >> - > >> RGB (any)IPU RGB RGB (any) > >> YUV (any)IPU YUV YUV (any) > >> Bayer N/A must be same bayer code as sink > > > > The IDMAC src pad should also use the internal 32-bit RGB / YUV format, > > except if bayer/raw mode is selected, in which case the attached capture > > video device should only allow a single mode corresponding to the output > > pad media bus format. > > The IDMAC source pad is going to memory, so it has left the IPU. > Are you sure it should be an internal IPU format? I realize it > is linked to a capture device node, and the IPU format could then > be translated to a v4l2 fourcc by the capture device, but IMHO this > pad is external to the IPU. The CSI IDMAC source pad should describe the format at the connection between the CSI and the IDMAC, just as the icprpvf and icprpenc source pads. The format outside of the IPU is the memory format written by the IDMAC, but that is a memory pixel format and not a media bus format at all. That would also make it more straightforward to enumerate the memory pixel formats in the capture device: If the source pad media bus format is 32-bit YUV, enumerate all YUV formats, if it is 32-bit RGB or RGB565, enumerate all rgb formats, otherwise (bayer/raw mode) only allow the specific memory format matching the bus format. regards Philipp
Re: [PATCH v4 33/36] media: imx: redo pixel format enumeration and negotiation
Hi Philipp, On 02/16/2017 03:32 AM, Philipp Zabel wrote: On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote: The previous API and negotiation of mbus codes and pixel formats was broken, and has been completely redone. The negotiation of media bus codes should be as follows: CSI: sink pad direct src pad IDMAC src pad - RGB (any)IPU RGB RGB (any) YUV (any)IPU YUV YUV (any) Bayer N/A must be same bayer code as sink The IDMAC src pad should also use the internal 32-bit RGB / YUV format, except if bayer/raw mode is selected, in which case the attached capture video device should only allow a single mode corresponding to the output pad media bus format. The IDMAC source pad is going to memory, so it has left the IPU. Are you sure it should be an internal IPU format? I realize it is linked to a capture device node, and the IPU format could then be translated to a v4l2 fourcc by the capture device, but IMHO this pad is external to the IPU. Steve
Re: [PATCH v4 33/36] media: imx: redo pixel format enumeration and negotiation
On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote: > The previous API and negotiation of mbus codes and pixel formats > was broken, and has been completely redone. > > The negotiation of media bus codes should be as follows: > > CSI: > > sink pad direct src pad IDMAC src pad > - > RGB (any)IPU RGB RGB (any) > YUV (any)IPU YUV YUV (any) > Bayer N/A must be same bayer code as sink The IDMAC src pad should also use the internal 32-bit RGB / YUV format, except if bayer/raw mode is selected, in which case the attached capture video device should only allow a single mode corresponding to the output pad media bus format. regards Philipp