On 02/08/18 12:56, Hans Verkuil wrote: > On 02/08/18 11:46, Philipp Zabel wrote: >> On Wed, 2018-02-07 at 23:19 +0100, Hans Verkuil wrote: >>> On 02/07/2018 11:05 PM, Tim Harvey wrote: >>>> On Wed, Feb 7, 2018 at 1:09 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >>>>> On 02/07/18 09:22, Hans Verkuil wrote: >>>>>> On 02/07/2018 12:29 AM, Tim Harvey wrote: >>>>>>> Media Controller ioctls: >>>>>>> fail: v4l2-test-media.cpp(141): ent.function == >>>>>>> MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN >>>>>> >>>>>> Weird, this shouldn't happen. I'll look into this a bit more. >>>>> >>>>> Can you run 'mc_nextgen_test -e -i' and post the output? >>>>> >>>>> It's found in contrib/test. >>>>> >>>> >>>> root@ventana:~# ./v4l-utils/contrib/test/mc_nextgen_test -e -i >>>> Device: imx-media (driver imx-media) >>>> Bus: >>>> version: 0 >>>> number of entities: 24 >>>> number of interfaces: 24 >>>> number of pads: 48 >>>> number of links: 50 >>>> entity entity#1: 'unknown entity type' adv7180 2-0020, 1 pad(s), 1 source(s) >>>> entity entity#3: 'unknown entity type' tda19971 2-0048, 1 pad(s), 1 source(s) >>>> entity entity#5: 'unknown entity type' ipu1_vdic, 3 pad(s), 2 sink(s), >>>> 1 source(s) >>>> entity entity#9: 'unknown entity type' ipu2_vdic, 3 pad(s), 2 sink(s), >>>> 1 source(s) >>>> entity entity#13: 'unknown entity type' ipu1_ic_prp, 3 pad(s), 1 >>>> sink(s), 2 source(s) >>>> entity entity#17: 'unknown entity type' ipu1_ic_prpenc, 2 pad(s), 1 >>>> sink(s), 1 source(s) >>>> entity entity#20: 'V4L I/O' ipu1_ic_prpenc capture, 1 pad(s), 1 sink(s) >>>> entity entity#26: 'unknown entity type' ipu1_ic_prpvf, 2 pad(s), 1 >>>> sink(s), 1 source(s) >>>> entity entity#29: 'V4L I/O' ipu1_ic_prpvf capture, 1 pad(s), 1 sink(s) >>>> entity entity#35: 'unknown entity type' ipu2_ic_prp, 3 pad(s), 1 >>>> sink(s), 2 source(s) >>>> entity entity#39: 'unknown entity type' ipu2_ic_prpenc, 2 pad(s), 1 >>>> sink(s), 1 source(s) >>>> entity entity#42: 'V4L I/O' ipu2_ic_prpenc capture, 1 pad(s), 1 sink(s) >>>> entity entity#48: 'unknown entity type' ipu2_ic_prpvf, 2 pad(s), 1 >>>> sink(s), 1 source(s) >>>> entity entity#51: 'V4L I/O' ipu2_ic_prpvf capture, 1 pad(s), 1 sink(s) >>>> entity entity#57: 'unknown entity type' ipu1_csi0, 3 pad(s), 1 >>>> sink(s), 2 source(s) >>>> entity entity#61: 'V4L I/O' ipu1_csi0 capture, 1 pad(s), 1 sink(s) >>>> entity entity#67: 'unknown entity type' ipu1_csi1, 3 pad(s), 1 >>>> sink(s), 2 source(s) >>>> entity entity#71: 'V4L I/O' ipu1_csi1 capture, 1 pad(s), 1 sink(s) >>>> entity entity#77: 'unknown entity type' ipu2_csi0, 3 pad(s), 1 >>>> sink(s), 2 source(s) >>>> entity entity#81: 'V4L I/O' ipu2_csi0 capture, 1 pad(s), 1 sink(s) >>>> entity entity#87: 'unknown entity type' ipu2_csi1, 3 pad(s), 1 >>>> sink(s), 2 source(s) >>>> entity entity#91: 'V4L I/O' ipu2_csi1 capture, 1 pad(s), 1 sink(s) >>>> entity entity#97: 'unknown entity type' ipu1_csi0_mux, 3 pad(s), 2 >>>> sink(s), 1 source(s) >>>> entity entity#101: 'unknown entity type' ipu2_csi1_mux, 3 pad(s), 2 >>>> sink(s), 1 source(s) >>> >>> Yuck. So nobody in imx (and adv7180!) is setting a valid function. >>> And I see the mc_nextgen_test.c doesn't know all the latest functions >>> anyway. >> >> That's probably because for most of the entities it's a bit unclear >> which function should be assigned. > > Well, that's one reason. The other is that there never was a utility > to test this :-) > >> ipu[12]_csi[01]_mux are video multiplexers, so MEDIA_ENT_F_VID_MUX. I >> thought those should already be set correctly in the video-mux driver. > > They are. The mc_nextgen_test, media-ctl and now v4l2-ctl/v4l2-compliance > all have their own list of functions that they know about and it's all > different. It's one of the things I want to fix. > >> ipu[12]_csi[01] are the interfaces to the outside parallel busses, but >> they can also 'downscale' by skipping, skip frames and pack or expand >> pixels from the bus into the internal FIFOs that lead to the next >> element. These are not MEDIA_ENT_F_VID_IF_BRIDGE, are they? > > Yes, they are. One limitation of the current API is that you cannot > represent correctly devices with multiple functions. This is planned for > a long time now, but nobody actually did the work. So for now just fill > in the primary function with a comment that in the future other functions > should be set as well. > >> ipu[12]_vdic are mainly deinterlacers, so a new function >> MEDIA_ENT_F_PROC_VIDEO_DEINTERLACER ? These entities could also be used >> as composers in a mem2mem scenario (MEDIA_ENT_F_PROC_VIDEO_COMPOSER ?), >> but this is currently not supported. > > Yes, we need a PROC_VIDEO_DEINTERLACER function. > >> >> ipu[12]_ic_prp is just a tee element that feeds both ipu[12]_ic_prpenc >> and ipu[12]_ic_prpvf. These are both scalers and colorspace converters. >> MEDIA_ENT_F_PROC_VIDEO_SCALER ? >> MEDIA_ENT_F_PROC_VIDEO_PIXEL_ENC_CONV ? > > The tee element would be a new PROC_VIDEO_SPLITTER function. > > The other two would be scalers, but should add the VIDEO_PIXEL_ENC_CONV > function once it is possible to do so. > >> >> "ipu[12]_csi[01] capture" are the DMA elements writing to memory, so >> MEDIA_ENT_F_PROC_VIDEO_PIXEL_FORMATTER ? > > These are likely to be filled correctly already. I've just added a commit > to v4l2-compliance to make it easier to see what function is used: > > v4l2-compliance -m0 -v Actually, can you run this using the latest v4l-utils version for the imx and post the output? Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
