Hans, On 11/10/23 8:04 PM, Hans de Goede wrote: > Hi, > > On 11/8/23 12:59, Hans de Goede wrote: >> Hi Bingbu, >> >> On 10/24/23 13:29, bingbu.cao@xxxxxxxxx wrote: >>> From: Bingbu Cao <bingbu.cao@xxxxxxxxx> >>> >>> This patch series adds a driver for Intel IPU6 input system. >>> IPU6 is the sixth generation of Imaging Processing Unit, it is a PCI >>> device which can be found in some Intel Client Platforms. User can use >>> IPU6 to capture images from MIPI camera sensors. >>> >>> IPU6 has its own firmware which exposes ABIs to driver, and communicates >>> with CSE to do firmware authentication. IPU6 has its MMU hardware, so >>> the driver sets up a page table to allow IPU6 DMA to access the system >>> memory. >>> >>> IPU6 input system driver uses MC and V4L2 sub-device APIs besides V4L2. >> >> I have been testing this on a TigerLake system, a Dell Latitude 9420 >> with ov01a1s and the packed 10 bit bayer pixel fmt: V4L2_PIX_FMT_SGRBG10P, >> which libcamera together with (WIP) software debayer support picks >> by default does not work. There are many many CSI errors in dmesg >> and only the first 10 or so lines of the image show. >> >> Disabling the packed format by removing it from ipu6_isys_pfmts[], >> making libcamera pick the unpacked (every 10 bits per pixel data >> stored in a 16 bit word in output buffer) fixes this. >> >> Are the packed bayer formats supposed to work on Tiger Lake, or >> is this a known issue which Intel's own userspace stack avoids >> by always picking the unpacked format ? > > Bingbu, so we've been trying to get software debayering to work > on the Dell Latitude 9420 with ov01a1s and I have just learned > that this sensor has a non standard bayer grid. > > https://github.com/intel/ipu6-camera-hal/blob/9fa05a90886d399ad3dda4c2ddc990642b3d20c9/config/linux/ipu6/gcss/graph_settings_ov01a1s.xml#L17 > > bayer_order="GRGB_IGIG_GBGR_IGIG" The IR is not enabled in Linux camera stack yet if I remember correctly. Current IPU6 processing system have a single hardware block extract the RGB and IR separately - "rgb_ir_2_0" in xml. > > I'm wondering how to interpret these 4 pixel orders? For the OV2740 > this just says: > > bayer_order="GRBG" > > and this single quartet of letters describes a 2x2 block like this: > > GR > BG > > but now there are 4 quartets so how to interpret this, > I guess this is the correct way to interpret this? : > > GRGB > IGIG > GBGR > IGIG I have no idea how to interpret the output of ov01a1s. Maybe you can try to zero(bypass) the IR data and interpret as SGRBG10. > > Regards, > > Hans > > > -- Best regards, Bingbu Cao
