On 2/8/19 1:23 PM, Tim Harvey wrote:
On Thu, Feb 7, 2019 at 5:54 PM Steve Longerbeam <slongerbeam@xxxxxxxxx> wrote:
<snip>
Ok there is definitely something wrong when using the IC with
UYVY8_1X16 (passthrough) which works with UYVY8_2X8. It looks to me
like the ipu1_ic_prp isn't negotiating its format properly. You can't
re-create this because you don't have any UYVY8_1X16 (passthrough)
sensors right?
Sorry, maybe I didn't mention this, but passthrough cannot go though the
IPU, you can only send passthrough pixels out the CSI directly to
/dev/videoN interface (the ipu_csi:2 pad).
crud... this has been my issue all along with that set of UYVY8_1X16
pipelines then. So this means the mem2mem driver also won't be able to
handle 16bit pixel formats as well.
Ugh, let me rephrase. UYVY8_1X16 incoming on a parallel bus (not MIPI
CSI-2) to the CSI cannot be sent through the IPU, those pixels must be
sent directly to the ipu_csi:2 pad to /dev/videoN. At least according
the the imx6 register manual.
But that's not a limitation of the mem2mem driver because the pixels are
coming from a memory buffer and not a 16-bi parallel bus via the CSI
(and in any case mem2mem does not deal in media bus codes, it speaks
V4L2_PIX_FMT_* which contains no bus info). So yes, you can receive
UYVY8_1X16 on the CSI parallel bus, routed to ipu_csi:2 pad to
/dev/videoN, and then pipe that to mem2mem v4l2convertN element in a
gstreamer pipeline.
So while I can downscale this by
multiples of 2 (independent width/height), CSC convert it from
srgb/bt.601 to yuv/bt.709, and even pixel reorder it within YUV via
the ipu_csi entitty I'll never be able to deinterlace,
that's true, currently you can't use the VDIC to do motion compensated
de-interlacing, but you can still make use of the IDMAC interweave
feature to deinterlace without motion compensation.
scale with
flexibility, flip/rotate or do a RGB->YUV CSC on it as those are all
features of the IC path.
mem2mem v4l2convertN element will do those for you (flexible up/down
scaling, flip/rotate, and CSC).
Steve
I'm still struggling with what mbus format to configure the
sensor<->csi interconnect in the device-tree. I was leaning towards
16bit but now that I realize that can't be used with the IPU I'm
thinking the bt656 is more flexible (accept it has the limitation of
not being able to do 1080p60 due to pixel clock and also can't handle
interlaced due bt656 codes). If I end up wanting to switch between
tda1997x sensor bus formats I'm not even sure the best way to deal
with that (two dts I suppose and allowing user to select which one
they use).
Tim
