Re: RockPro65 RK3399 chipset, ISP and IMX214 camera

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxx> 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





[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux