On 22-07-06 16:51:26, Laurent Pinchart wrote: > Hi Petko, > > On Wed, Jul 06, 2022 at 04:07:16PM +0300, Petko Manolov wrote: > > On 22-07-06 08:18:20, Alexander Stein wrote: > > > > > > Thanks! Indeed at a first glance it looks straight forward. I was trying > > > to get an imx327 running on a imx8mm, called TQMa8MxML. See [1] for some > > > details. The cover letter describes the config setup. The media-ctl > > > commands might help your setup. Note the settle times are an ugly bitch > > > and are crucial to be set on my board, but I'm not sure why they have to > > > be that way. Patch 1-8 are obsolete by now with the updates to > > > drivers/media/platform/nxp/ imx-mipi-csis.c. Patch 9 might help you > > > configure the DT. > > > > Right, media-ctl is it. In fact the pipelines have been properly set up so > > i only had to change the format. The attached media graph is below > > > > Now, there are two problems i'm stumbling upon. One is related to the > > capture device not actually supporting imx492 format(s), which are: > > > > MEDIA_BUS_FMT_SGBRG10_1X10 MEDIA_BUS_FMT_SGBRG12_1X12 > > > > which i guess is why i am being greeted with (when using v4l2-ctl): > > > > imx7-csi 32e20000.csi: capture format not valid > > > > When i manually force it to something that is actually supported, > > MEDIA_BUS_FMT_SGBRG16_1X16, i get: > > > > imx7-csi 32e20000.csi: pipeline start failed with -67 > > > > Since this isn't one of the usual error numbers i guess it comes from within > > the driver code. I might be getting this error because the source is 12 bit > > while the sink is 16 and i am breaking something, dunno. > > > > Shall i go ahead and add MEDIA_BUS_FMT_SGBRG12_1X12 to the capture driver or > > i am missing something here? > > I had a quick look at the imx7-media-csi driver, and I think it supports 1-bit > bayer correctly. You need to use the MEDIA_BUS_FMT_SGBRG10_1X10 or > MEDIA_BUS_FMT_SGBRG12_1X12 media bus formats through the pipeline, and the > V4L2_PIX_FMT_SGBRG16 pixel format on the video captude node. If that doesn't Well, it does work, but is there a reason MEDIA_BUS_FMT_SGBRG12_1X12 can't be used instead of V4L2_PIX_FMT_SGBRG16? I can see the capture node does not support the former, but don't understand the logic behind. Again, i'm no expert in the field... > > The other problem is when v4l2 tries to allocate buffer for even a single > > frame. This is 8192x5556 10/12bit bayer sensor and, maybe not surprisingly > > i get "buffer allocation failed". Is it possible that i'm the first to step > > on this issue on imx8m-mini or in general? > > You may want to increase the size of the CMA in the kernel configuration (or > on the kernel command line). Well, this one was some sort of fun. After debugging videobuf2-core.c it turned out the culprit is in imx-media-capture.c (via call_qop(q, queue_setup, ...)) calls. VID_MEM_LIMIT is only 64MB while the image is ~90MB, but it looks like four of those are required. I increased the CMA to 640MB, defined VID_MEM_LIMIT to 512MB and got something that look like it's working. I am yet to convert the raw image to something pleasant for human eye... I am not entirely convinced the above approach is the correct one. OTOH, something needs to be done for large resolution sensors. Ideas? cheers, Petko
