Re: RockPro65 RK3399 chipset, ISP and IMX214 camera

[Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>]

Hi

I think Heiko and Kieran have already given you a lot of clues.

I would recommend to start looking at i2c communication with i2c
tools: i2cget, i2set, i2cdetect.... before trying any video operation.

Your life will be much easier if you get your hands into a logic
analyser like this one https://www.saleae.com/

Regarding the i2c address, bear in mind that vendors and Linux might
use different nomenclature (7 bits to 8 bits).

Good luck!

On Thu, Feb 24, 2022 at 6:03 PM Heiko Stuebner <heiko@sntech.de> wrote:
>
> Am Donnerstag, 24. Februar 2022, 16:10:06 CET schrieb Clemens Arth:
> > Hi Kieran,
> >
> > Thx, I’m on my mobile now so I hope copy pasting works… apologies for typos…
> >
> > Kieran Bingham <kieran.bingham@ideasonboard.com> schrieb am Do. 24. Feb.
> > 2022 um 13:49:
> >
> > > 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.
> > >
> >
> > The schematics are here, from which I took the regulator and gpio config.
> > The regulators all seem to be fixed ones. There is just one pin that pulls
> > up all the regulators (DVP_PWR).
> >
> > https://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf
> >
> > The IMX214 driver has only one pin, the enable_pin, but it is somewhat
> > different from the IMX219 for example. Looking at both driver's code I
> > believe what is the reset_pin with the IMX219 is the enable_pin with the
> > IMX214, but I am not sure about that. There is no MIPI reset on the
> > RockPro64 afaik. Therefore I think it needs to be wired to the DVP_PDN0_H
> > pin, but other drivers define that one specifically and it apparently does
> > something different.
>
> For the pins also check the direction (active_low / active_high).
> I remember having fun somewhere when changing between the vendor
> kernel and mainline.
>
>
> > > 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 ?
> > >
> >
> > From the top of my head, it shows 1c on the 0x0c address iirc, but only if
> > I remove the IMX from the DT. Otherwise the driver takes over and it shows
> > UU. I removed the camera physically and it was gone on i2cdetect, so I
> > suspect that it indeed is the camera. From the driver and the documentation
> > I need to configure it 4-lane, as it is hardcoded in the driver (compared
> > to the application notes for registers for the ImX214).
> >
> >
> > >
> > > > 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.
> >
> >
> > I tried that at an earlier stage, to no avail unfortunately. But I will try
> > again as soon as I get back to my desk.
> >
> > >
> > >
> > > 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?
> > >
> > > That’s one of the issues. Ricardo wrote about iirc 0x10 and 0x1a, but the
> > app note says something entirely different (forgot), and my camera appears
> > to be on yet another address…
>
> not specific to cameras, but in the past I had i2c devices that set the
> address depending on the state of a gpio during powerup - which was
> floating in my old case, producing random settings ;-) .
>
>
> Heiko
>
>


-- 
Ricardo Ribalda