I’m not sure that I understand the question. In general, the settle time is time that the CSI2 receiver will wait for HS-0 mode and after that will start looking for the Leader-Sequence. So the driver has to configure the CSI2 receiver for that - it writes the settle count value to the registers. The settle count is the parameter, which hardware is able to understand - it is calculated from the settle time. You can check the calculation in the latest version: camss-csiphy-2ph-1-0.c « camss « qcom « platform « media « drivers - working/qualcomm/kernel.git - Qualcomm Landing Team kernel
I don’t understand what is a settle count. I know that the settle time is the time the data lanes need to prepare for sending data (which consist of hs_prepare time with some hs_zero time I guess), and that this value is expressed in nanoseconds. But I can’t figure out what is the settle count. I can’t find the definition.
Hi ,
Even I am facing similar kind of issue but in my case I am able to dump 2 frames using yavta but when I tired to dump 3 frames from yavta I am facing “Unable to dequeue buffer at end: Broken pipe (32).”
Any clue!?
Note: Its on Qualcomm platform only
Settle count is a parameter specific for this Qualcomm platform. It is just a way to represent the settle time - for this specific hardware.
Hi,
I’d recommend to start a separate thread and describe your problem in details there.
My current settle count is 14 for a pixel clock of 125370000 Hz, I will try to put others settle count value manually.
UPDATE: Thanks to @Loic, I managed to “receive” something from the camera to the driver.
I have set the sensor to 2-lanes and configured the device tree as well. The settle-count calculated by the driver is 12 and now - with yavta - I can see that the vfe_isr interrupt is called many (many) times.
The strange thing now is that I just ask for a single frame with yavta and the interrupt keeps being called and the program never returns. So the thing that changes from before is that this time the interrupt is called massively.
If you have any idea @todortomov , I’m in ! 
EDIT: also, what is the difference between the camss-csiphy file called “2phase” and the one called “3phase” in the latest release ?
EDIT2: solved the above EDIT by myself: 2phase is for 8x16 processors and 3phase is for 8x96 processors (link here)
After off debug/discussion with Matthieu, it appears that vfe correctly triggers interrupt on RDI0 frame starting (VFE_0_IRQ_STATUS_1_RDIn_SOF), every 11ms (90frame/s). Problem is that the frames are never completed because ‘buffer complete’ interrupt (VFE_0_IRQ_STATUS_0_IMAGE_MASTER_n_PING_PONG) is not raised.
@todortomov, any idea what can lead to such behavior ? I assume VFE waits for a certain amount of data OR maybe it’s only driven by CSI signal (Frame end packet)…
Hi Loic,
When RDI is used, the VFE works in so-called “frame based” mode - frame end packet is used to indicate end of the frame. When PIX interface is used, the VFE works in “line based” mode - it waits for certain amount of data. Then (in both cases) it triggers the PING-PONG interrupt which indicates that the frame has been written to memory.
The SOF interrupt is more like a strobe signal, it doesn’t mean that writing to memory is really started.
Debugging such problems can be quite complex and the lack of public documentation of the camera doesn’t help at all.
I’ve advised Matthieu to check with the oscilloscope that the sensor really streams on the expected CSI2 lanes.
Best regards,
Todor
1 Like
I have checked the data lanes through the oscilloscope and the sensor streams well on the correct lanes.
However, I have tried to modify some registers in the driver for OV5645 (this one). Since the OV5645 works on my configuration, I set the pixel format of this sensor to 10-bit BGGR and I used the same process as I use for my OV4689 sensor - which is leading the media pipeline to vfe_rdi0 and using yavta with SBGGR10P capture. (I have modified registers 0x4300 and 0x501f @todortomov) and I get the exact same behavior as with my sensor !
I tend to think that something is coming from the camss driver with RDI pipeline, what do you think ?
Hi Mathieu,
I have modified reg 0x4300 to 0xf8 and media bus format to MEDIA_BUS_FMT_SBGGR8_1X8 and I’m able to capture 8-bit raw from OV5645.
1 Like
Hi everyone,
I’ve managed to make the driver OV4689 work for a DB410C (and also a Variscite SD410), working on a 4.9.56 kernel. Right now, the code is ugly and the MIPI camera is only working on 2 lanes (instead of 4).
I may post the code further when I will develop a release about it.
Thanks a lot to @Loic and @todortomov who helped me during few days through IRC !
1 Like
