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. 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, scale with flexibility, flip/rotate or do a RGB->YUV CSC on it as those are all features of the IC path. 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
