Hi Clemens, Quoting Clemens Arth (2022-02-23 18:36:28) > Hi everyone, > > + Ricardo and Heiko in CC as the driver originators and rockchip pros... > > I'm reaching out to you based on a discussion with Sebastian Fricke, who > was working on the OV13850 driver for the v5 kernel. I tried getting the > IMX214 finally to work on the RockPro64 from Pine64, which only works on > Android so far and I need to get that done on Mainline Linux (I did not > find anyone who managed that and reported about it). However, I'm also > totally stuck. > > The RockPro64 runs Dietpi, which is essentially Armbian + a few tweaks. > I'm using the Armbian 5.15.18 kernel, so mainline, with a custom device > tree, which in the first place powers the MIPI ports. I suspect it is a > bad idea to have one pinctrl as a placeholder for 4 converters, however, > I'm not too deep into proxying in the devicetree, so here's the current > status: > > https://pastebin.com/vs277ex0 Your regulators are all listed as fixed-regulators. Are you sure there's nothing else to turn on ? I expect this was from another fragement for the same platform? So I hope it's consistent. Can you validate that the enable-gpios definition is to the correct GPIO to enable the camera ? > The camera is connected to the first MIPI port. The kernel boot logs > look ok to me (except for the cyclic dependency issue, but I think that > does not matter much). > > https://pastebin.com/hvhdEfxm > > Without the camera configured in the device tree, it shows up as 0x0c > device on the #1 I2C bus, which is a bit suspicious to me given the > addresses in the documentation and the info given in the kernel > documentation. > > However, I essentially followed the description according to this guide > to set up the RKISP: > > https://linuxtv.org/downloads/v4l-dvb-apis/admin-guide/rkisp1.html > > using this: > > https://pastebin.com/ZqWC5vhC > > It looks like this (see also png attached). > > https://pastebin.com/MfTNp5Pd > > However, the IMX214 driver does not complain until that point and seems > to do right. I expected that at least something happens, however it does > not. The last command does this: > > VIDIOC_STREAMON returned -1 (No such device or address) and this is the > kernel output > > [1509.435228] imx214 1-000c: write_table error: -6 > [1509.435868] imx214 1-000c: could not sent common table -6 -6 is ENXIO 6 No such device or address. So I expect the device isn't responding to the I2C controller. What shows up with i2c-detect -r -y 1 ? > There is no more info given, even if I do some "echo 0x3F > > /sys/class/video4linux/v4l-subdev0/dev_debug" to the subdevs. > > Here's the IMX214 documentation btw. that I got through a detour from CSDN. > > https://www.dropbox.com/sh/5d3mp2akr3kmu7t/AADaAsSxZu2kVSIfEceStwuoa?dl=0 > > I'm not entirely sure, but there is something wrong somewhere and I > can't find out if it is with the driver, the RKISP or anything else. > Here's what "v4l2-ctl -d /dev/v4l-subdev3 --all" gives - not sure but > shouldn't it show supported resolutions or something? > > https://pastebin.com/ckAFPbAs You might find it useful to check what is missing to support libcamera with this sensor, then you can use cam/qcam to test it too. The RKISP1 pipeline handler in libcamera will handle all the media controller configuration, and identifying the available formats for you, but we haven't had an IMX214 sensor added yet, so you might need to add a mapping to the src/libcamera/camera_sensor_properties.cpp sensor database, and the driver is missing at least V4L2_CID_HBLANK and V4L2_CID_VBLANK that are required for libcamera. So it might not be as straightforward as I'd like, but it would be helpful I expect. But ... I think your issues are more likely underlying hardware or DT issues, as the device sounds like it's not responding on the i2c address. Sometimes I2C devices have a configurable address, can you check if this really is the correct I2C address for your camera? > Any help would be appreciated. Regards Kieran > > Best > Clemens
