On Tue, 2023-08-22 at 17:22 +0300, Laurent Pinchart wrote: > Hi Claus, > > On Tue, Aug 22, 2023 at 02:52:35PM +0200, > claus.stovgaard@xxxxxxxxx wrote: > > > > Hi Laurent. > > > > Thanks for your offer - it might come in handy to have libcamera > > support, but I don't need it right now. > > > > My use case is a bit special. I am working as Embedded Engineer for > > Ambu A/S, where we have 2 display units, named aView2 and aBox2, > > for > > single use endoscopy. > > > > https://youtu.be/eDcSrHxzZ70?t=14 > > > > Those units is based on the intel Apollo Lake with IPU4, where only > > the > > isys part of IPU4 is used, as a FPGA in front of the Apollo Lake is > > used for image processing. So the image stream is sent to the > > Apollo > > Lake as RGB data - and is using the IPU4 isys as DMA. E.g. like > > below. > > > > scope -> FPGA -> tc358748 -> IPU4-> memory > > Out of curiosity, is this because the image processing requirements > are > very device-specific, or was that done to work around the fact that > the > IPU4 doesn't provide a good ISP driver ? The hardware was created with this architecture before I started at Ambu, so I don't know the details around the original design process. Though I would say device-specific , because we are used for medical procedures you want to have a mitigation for any failure. The display is also connected to the FPGA, so when it is powered on, before the Apollo Lake starts, a basic video pipeline is already running. E.g. instant on, and showing video from the scopes. If a code error happens on the Apollo Lake and the watchdog kicks it, it always fall back to this FPGA view. This FPGA view is of cause missing features and information present when the complete system is running. Features like patient information, video recording, voice recording, printing, data export etc. but the FPGA view makes sure the doctor always is able to see what happens when the scope is inserted in the body, even if any bug is hit in the software. So think device-specific risk mitigation. > > > We need to support this for newer kernels, then provided from intel > > (4.14 / 4.19) > > *OUCH*. Seriously ?? :-( Ohh yes.. So I think we have plenty of work for quite some time... But a good option for learning this part of the kernel. > > > and looking at the code, it seems like a better option to > > base it on this IPU6 isys driver and extend it to cover IPU4 isys > > also. > > > > So we are being inspired by the provided 4.14 / 4.19 kernel, and > > then > > work on the IPU6 codebase. > > > > Our current status is that my coworker has the Buttress to load the > > firmware on IPU4, and we will continue work from there. > > > > My end goal would be that an upstream vanilla kernel is able to > > support > > the isys part of IPU4, and the complete IPU6. > > It would be very nice to have an upstream driver for the IPU4 CSI-2 > receivers indeed. Looking forward to seeing one :-) > We will do our very best. Regards Claus
