<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   hverkuil: <u>prabhakarlad</u>: ping
   prabhakarlad: <u>hverkuil</u>: pong
   hverkuil: <u>prabhakarlad</u>: does the rcar-vin have a scaler?
   prabhakarlad: Yes it does support scaling.
   hverkuil: So it will scale from the crop rectangle to the compose rectangle?
   <br> (just checking)
   sailus: <u>prabhakarlad</u>: Pong.
   prabhakarlad: <u>hverkuil</u>: let me dig through it, im not completely sure.
   <br> <u>sailus</u>: with the current fwnode parsing if an invalid bus-type (say 9) is passed in DT v4l2_fwnode_endpoint_alloc_parse(.bus_type = V4L2_MBUS_PARALLEL) returns success with bus-type set to V4L2_MBUS_PARALLEL. is this the expected behavior ?
   sailus: <u>prabhakarlad</u>: Does it?
   prabhakarlad: Yes :)
   sailus: -ENXIO should be returned.
   <br> Looking at the code, that's what it seems to do.
   <br> But I haven't tested it for quite a while. :-)
   <br> The problem seems to be in v4l2_fwnode_bus_type_to_mbus().
   <br> We should add an invalid MBUS type and v4l2_fwnode_bus_type_to_mbus() should return that if there's no valid bus type.
   <br> Would you like to write a patch? :-)
   prabhakarlad: Sure will do that :)
   <br> V4L2_MBUS_INVALID sounds good ?
   sailus: Yeah.
   prabhakarlad: <u>hverkuil</u>: Yes it does https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/rcar-vin/rcar-dma.c#n532
   hverkuil: <u>prabhakarlad</u>: ok, good to know.
   <br> <u>arnd</u>: I looked at your proposed patch, and I really don't like how the compat code now pollutes the main v4l2-ioctl.c source.
   <br> This should remain as much as possible in v4l2-compat-ioctl32.c. The 32 bit structs can be added in a v4l2-compat-ioctl32.h header so v4l2-ioctl.c can include it, and helper functions can be placed in v4l2-compat-ioctl32.c.
   <br> So v4l2-ioctl.c can have the 'case's for the compat ioctls, but those should call helper functions from v4l2-compat-ioctl32.c instead of keeping it all in v4l2-ioctl.c.
   arnd: <u>hverkuil</u>: ok, I'll try that then
   hverkuil: <u>arnd</u>: I so wish I could step in a time machine and go back in time to tell the V4L2 designers about future 64 bit architectures :-)
   arnd: <u>hverkuil</u>: the one part I can't figure out how to do yet is the v4l2_format32 conversion for V4L2_BUF_TYPE_VIDEO_OVERLAY, is there a reason why this one doesn't already get copied using check_array_args() ?
   <br> (the v4l2_clip array)
   hverkuil: Probably because v4l2_clip has a different size for 32 vs 64 bit architectures, so you can't just copy it as an array.
   <br> The sad thing is that the 'next' 'pointer' is just discarded and never actually used.
   arnd: <u>hverkuil</u>: I don't think the reason is compat mode, as that would be the same for the arrays in v4l2_buffer and v4l2_ext_controls
   hverkuil: <u>arnd</u>: ah yes. Then I think it is simply that this already worked and nobody bothered to switch it over to check_array_args(). The check_array_args() function was created much, much later than the overlay support.
   <br> I have no objection to switch over to check_array_args() for overlays.
   arnd: ok, thanks for confirming, now I just need to figure out which drivers actually access the v4l2_clip array
   <br> I suppose anything that implements either vidioc_g_fmt_vid_out_overlay or vidioc_g_fmt_vid_overlay
   hverkuil: Yup. I count 7 drivers.
   <br> <u>arnd</u>: actually 8 drivers: drivers/staging/vc04_services/bcm2835-camera uses it as well.
   arnd: <u>hverkuil</u>: what about users of vidioc_create_bufs? I see that the compat code does the conversion for those as well, but they all end up in vb2_ioctl_create_bufs, which does not support the overlay version
   <br> is that a coincidence or by design?
   hverkuil: by design: overlays do not use buffers. Capture overlays write directly into a framebuffer, output overlays can be used to mix in a framebuffer (containing an OSD) into the output video signal.
   arnd: ok, good, then VIDIOC_CREATE_BUFS32 compat support can be much simpler than it is today
   hverkuil: For modern drivers this is never used, it's for old hardware only. I wish we could drop it altogether, but some of this HW is still in use, I'm pretty certain of that.
   ***: kbingham has quit IRC (Ping timeout: 272 seconds)
   arnd: hverkuil-: I've completed a first pass, with 9 files changed, 720 insertions(+), 1242 deletions(-)
   <br> have not tried compiling yet...