Hi Loic,
I don’t find this function into camss-csiphy.c, I am using a version of the driver for kernel 4.9.56.
Where could I find a recent version of the driver ?
The current DB410C kernel is 4.14, you can find kernel build instruction in last release note: https://releases.linaro.org/96boards/dragonboard410c/linaro/debian/latest/ or in 96B documentation:https://www.96boards.org/documentation/consumer/dragonboard410c/build/kernel.md.html.
Even in the latest kernel I can’t find this function.
Today I have checked the MIPI clock and data lanes through the oscilloscope and it seems that the sensor sends data and the clock pulses correctly. But I still can’t figure out why it does not work.
Maybe it comes from the camss driver ? I already put some debug messages and the video_start_streaming function from the video node is called. Is the venus driver from Qualcomm implicated ?
Also, I am using the V4L2_PIX_FMT_SBGGR10P pixel format with a resolution of 2688x1520 (sensor highest res), I am not sure if it is the source of the problem (could you tell us more @todortomov ?)
Regards,
Mathieu
Hi Mathieu,
As you are trying on 410c branch, “lane_enable” function is not present there. It is present in 820c 4.14 branch. For 410c you can check “static int csiphy_stream_on(struct csiphy_device *csiphy)” function which contain all the functions in “lane_enable”.
Give a try by changing the “settle count”.
Best Regards,
Jox
No venus is a different component (video encoder/decoder).
Relatively good news, is it because you changed kernel version ?
Now I think the next thing to check is the ISPIF/VFE interrupt, which is triggered for several reasons, including start of frame: camss-vfe-4-1.c « camss « qcom « platform « media « drivers - working/qualcomm/kernel.git - Qualcomm Landing Team kernel
Could you please give command you are running? why using csid1?, this should be something like this:
media-ctl -d /dev/media0 -l \
'"msm_csiphy0":1->"msm_csid0":0[1],"msm_csid0":1->"msm_ispif0":0[1],"msm_ispif0":1->"msm_vfe0_pix":0[1]';Hi Mathieu,
Please check the points by Loic above and share info on them.
I didn’t change the kernel version for now (I tried to flash on the board but it didn’t work, trying again later this day).
sudo media-ctl -d /dev/media0 -l '"msm_csiphy0":1->"msm_csid0":0[1],"msm_csid0":1->"msm_ispif0":0[1],"msm_ispif0":1->"msm_vfe0_rdi0":0[1]'
sudo media-ctl -d /dev/media0 -V '"ov4689 4-0042":0[fmt:SBGGR10_1X10/2688x1520 field:none],"msm_csiphy0":0[fmt:SBGGR10_1X10/2688x1520 field:none],"msm_csid0":0[fmt:SBGGR10_1X10/2688x1520 field:none],"msm_ispif0":0[fmt:SBGGR10_1X10/2688x1520 field:none],"msm_vfe0_rdi0":0[fmt:SBGGR10_1X10/2688x1520 field:none]'
As you can see, I’m using rdi0 since the sensor sends 10-bit RAW data (I’m using V4L2_PIX_FMT_SBGGR10P pixel format)
Also, here is there output using yavta :
yavta -B capture-mplane -c1 -I -n 1 -f SBGGR10P -s 2688x1520 /dev/video0
[ 342.583887] ov4689 4-0042: powering up OV4689 sensor
[ 342.633095] qcom-camss 1b0ac00.camss: timer_clk_rate value: 100000000
[ 342.641714] qcom-camss 1b0ac00.camss: vfe_isr interrupt handler is called
Device /dev/video0 opened.
Device `Qualcomm Camera Subsystem' on `platform:1b0ac00.camss' (driver 'qcom-camss') supports video, capture, with mplanes.
Video format set: S[ 342.650834] qcom-camss 1b0ac00.camss: video_buf_init
BGGR10P (41414270) 2688x1520 field none, 1 planes:
* Stride 3360, buffer size 5107200
Video format: SBGGR10P (41414270) 2688x1520 field none, 1 planes:
* Stride 3360, buffer size 5107200
1 buffers requested.
length: 1 offset: 4227546768 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0xffff9fa9b000.
[ 342.674166] qcom-camss 1b0ac00.camss: video_buf_prepare
[ 342.702218] qcom-camss 1b0ac00.camss: csiphy_settle_cnt_calc: ui value: 3190
[ 342.702241] qcom-camss 1b0ac00.camss: csiphy_settle_cnt_calc: timer_clk_rate value: 100000000
[ 342.708366] qcom-camss 1b0ac00.camss: csiphy_settle_cnt_calc: settle_cnt value: 14
[ 342.716762] qcom-camss 1b0ac00.camss: csiphy_stream_on: cfg->csid_id value: 0
[ 342.724252] ov4689 4-0042: [ov4689] ov4689_s_stream with status: 1
[ 342.733820] ov4689 4-0042: sensor streaming mode (reg 0x0100) : 0x01
As you can see in the log, the vfe_isr interruption does not seem to be called when streaming mode starts.
EDIT:
I receive CSID interruption only right after the sensor is powered up and right before the video node is opened, and only at this moment. Would it mean that there would be a conflict between the settle calculated by the driver and the one set in the registers ?
EDIT2: does the sensor driver need to be launched before qcom-camss driver ? Because I insmod my driver after boot manually
It doesn’t matter that you insert it after boot.
Your commands seem correct.
The first CSID interrupt happens when CSID reset is done.
The settle count value could be your problem. The settle time can be calculated or measured with an oscilloscope. Then the settle count could be calculated. Or you can start with the value calculated by the driver and try different values (lower or higher) and see what happens. Although we have adjusted the settle count calculation several times, there are some inconsistencies when using different sensors. Try to play with this value and see if you start to receive the video data
May I ask what is this value used for ? (not in general, I mean in the driver) It seems that this value is used to write something… What is the difference between the effective settle time of the CSI-2 transmitter and the “settle count” ?
Regards,
Mathieu
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
