410C Linaro debian latest Version VFE halt timeout

Products Support DragonBoard410c
#1

Hi All,

I found that 410C use linaro debian latest version VFE halt timeout when probe CAMSS.
Anyone fixed this? any suggestion?
Thanks a lot.

BRs

#2

hi,

can you please be more specific about the release number you are using, which kernel commit/patches and any local patches that you have. CAMSS is disabled by default in the latest release.

thx

#3

Hi ndec,

Thanks for your reply, I used:
git checkout -b kernel-16.09 debian-qcom-dragonboard410c-16.09
and then, I added an endpoint to camss in msm8916.dtsi:
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 551c12a…b3a6a6a6 100644
— a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -392,6 +392,20 @@
ports {
#address-cells = <1>;
#size-cells = <0>;

  •                           port@0 {

  •                                   reg = &lt;0&gt;;

  •                                   csiphy0_ep: endpoint {

  •                                   //      clock-lanes = &lt;1&gt;;

  •                                   //      data-lanes = &lt;0 2&gt;;

  •                                           qcom,settle-cnt = &lt;0xe&gt;;

  •                                   //      remote-endpoint = &lt;&amp;ov5645_ep&gt;;

  •                                           data-lanes = &lt;1 2 3 4&gt;;

  •                                           clock-lanes = &lt;0&gt;;

  •                                           clock-noncontinuous;

  •                                           link-frequencies = /bits/ 64 &lt;297000000&gt;;

  •                                           remote-endpoint = &lt;&amp;testcam_out&gt;;                                      

  •                                   };

  •                           };
                  };
          };

@@ -622,7 +636,39 @@
pinctrl-1 = <&i2c2_sleep>;
#address-cells = <1>;
#size-cells = <0>;

  •                   status = "disabled";

  •                   status = "enabled";

  •                   testcam@0f {

  •                           compatible = "testcam";

  •                           reg = &lt;0x0f&gt;;

  •                           clocks = &lt;&amp;gcc GCC_CAMSS_CSI0PHYTIMER_CLK&gt;;

  •                           clock-frequency = &lt;48000000&gt;; 

  •                           clock-names = "refclk";

  •                           //reset-gpios = &lt;&amp;msmgpio 36 0&gt;;

  •                           //interrupt-parent = &lt;&amp;msmgpio 0 2&gt;;

  •                           //interrupts = &lt;5 IRQ_TYPE_LEVEL_HIGH&gt;;

  •                           reset-gpios = &lt;&amp;msmgpio 36 0&gt;;

  •                           //interrupt-parent = &lt;&amp;msmgpio&gt;;

  •                           interrupts = &lt;GIC_SPI 13 IRQ_TYPE_EDGE_RISING&gt;;

  •                           interrupt-names = "testcam";

  •                           pinctrl-names = "default";

  •                           pinctrl-0 = &lt;&amp;camera_rear_default&gt;;

  •                           port {

  •                                   testcam_out: endpoint {

  •                                           remote-endpoint = &lt;&amp;csiphy0_ep&gt;;

Is it possible use Linaro debian on 410C board to support highspeed connector MIPI-CSI source?
Thanks so much.

BRs

#4

Hi Amy,

This warning “Vfe halt timeout” appears when the VFE has been powered up, no streaming was done, and then the VFE is powered down. In this case it is harmless - no need to fix anything and you can just ignore the warning.

#5

Hi Todor Tomov，

I igonored this warning, and continue to configure the v4l2 pipeline:
sudo media-ctl -d /dev/media1 -l ‘“msm_csiphy0”:1->“msm_csid0”:0[1],“msm_csid0”:1->“msm_ispif”:0[1]’
and got the failed: Invalid Arguments(22)
Does Linaro Debian SW: kernel-16.09 debian-qcom-dragonboard410c-16.09 ensure implemented MIPI-CSI camera and worked?

I found in kernel-16.06 version csiphy_reset(phy0) called in function:csiphy_set_power() will resulted in 410C board reboot and no any exception, Any suggestion?
I connect a CSI source to HighSpeed connector MIPI-CSI0 and used I2C0 on LowSpeed connector.
Checked CSI source clk and data lane use oscilloscope are correct.

Thanks so much for your reply.

Best Regards

#6

Hi Amy,

Yes, the 16.09 version implements the driver for the MIPI CSI2 interface and it works. Please use this version as it is the latest.

The instructions about using it however need an update.

Please use these (or derived from them) lines to link and configure the subdevices:

media-ctl -d /dev/media1 -l ‘“msm_csiphy0”:1->“msm_csid0”:0[1],“msm_csid0”:1->“msm_ispif0”:0[1],“msm_ispif0”:1->“msm_vfe0_rdi0”:0[1]’

media-ctl -d /dev/media1 -V ‘“ov5645 1-0076”:0[fmt:UYVY2X8/1920x1080],“msm_csiphy0”:0[fmt:UYVY2X8/1920x1080],“msm_csid0”:0[fmt:UYVY2X8/1920x1080],“msm_ispif0”:0[fmt:UYVY2X8/1920x1080],“msm_vfe0_rdi0”:0[fmt:UYVY2X8/1920x1080]’

You can also add a “-v” switch to enable verbose output from these commands which can help if there is any problem. But these commands should work.

#7

Hi Todor,

Thanks so much for your help.
I used the command you provided and link and configure subdevices, yes, the command worked.
But when I used “sudo gst-launch-1.0 v4l2src ! glimagesink”, the board reboot directly.
I configure the format as:UYVY/640x480 for all subdevices.
gstreamer pileline make command should be changed also?
I wille continue to check is there any issue in my source code or HW too, thansk a lot.

Best Regards

#8

Hi Amy,

The gstreamer command is correct I think, you can point explicitly the video device which you use but the default is probably the same:

gst-launch-1.0 v4l2src device=/dev/video0 ! glimagesink

If the board just reboots with no prior errors, this can be a sign that some resources were not enabled. You can check that the dtsi files that you have describe all the regulators and clocks as in the Linaro release.

Best regards,
Todor

#9

Hi Todor，

Yes, point explicitly the video device is useless, reboot with no prior errors.
I will check related resources. if there is any reference document or source code for HighSpeed MIPI-CSI0
worked please let me know, Thanks so much for you reply.

Best Regards.

#10

Hi Todor,

Ifound it is reboot at: csiphy_set_power->csiphy_reset, this issue is same as Linaro debian version 16.06
If I cancelled the csiphy_reset it will reboot at: hw_version = readl_relaxed(csiphy->base + CAMSS_CSI_PHY_HW_VERSION);
If also cancelled version read, reboot disappearred. But I think csiphy should be reset first.

in 16.06 version, “gst-launch-1.0 v4l2src ! glimagesink” will call subdevices’ .s_power, and then call .s_stream
so I triggered CSI TX0 transfer in out CAMSS endpoint device driver’s .s_stream.
Now in l6.09 version the .s_stream will not be called anymore, what should I do to match the new timesequence?

Any suggestions? Thanks so much for your help.

Best Regards

#11

Hi Todor and All

I found all the camss drivers addedd a list of formats supported:
MEDIA_BUS_FMT_UYVY8_2X8,
MEDIA_BUS_FMT_VYUY8_2X8,
MEDIA_BUS_FMT_YUYV8_2X8,
MEDIA_BUS_FMT_YVYU8_2X8,
MEDIA_BUS_FMT_SBGGR8_1X8,
MEDIA_BUS_FMT_SGBRG8_1X8,
MEDIA_BUS_FMT_SGRBG8_1X8,
MEDIA_BUS_FMT_SRGGB8_1X8,
MEDIA_BUS_FMT_SBGGR10_1X10,
MEDIA_BUS_FMT_SGBRG10_1X10,
MEDIA_BUS_FMT_SGRBG10_1X10,
MEDIA_BUS_FMT_SRGGB10_1X10,
MEDIA_BUS_FMT_SBGGR12_1X12,
MEDIA_BUS_FMT_SGBRG12_1X12,
MEDIA_BUS_FMT_SGRBG12_1X12,
MEDIA_BUS_FMT_SRGGB12_1X12,
MEDIA_BUS_FMT_SBGGR10_DPCM8_1X8,
MEDIA_BUS_FMT_SGBRG10_DPCM8_1X8,
MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8,
MEDIA_BUS_FMT_SRGGB10_DPCM8_1X8

but my CSI output format is: MEDIA_BUS_FMT_RGB888_1X24 or MEDIA_BUS_FMT_UYVY8_1X16
Is there anyway to adapt this issue?

In Addition:
csiphy0 reset caused board reboot I added camss_top_ahb_clk and camss_ahb_clk into csiphy_res[] to avoid but the HW version read out is 0x00, it looks like wrong version.
Is it possible that the root cause of the reboot is pixel format not match?

Thanks so much for any help.

Best Regards.
Amy.

#12

Hi Amy,

  • your reboot was most likely caused by the missing ahb clocks which you have added. Keep them in your configuration. This issue will be investigated.

  • the hw version 0x00 will also be investigated but it is not an issue for you to worry about.

  • MEDIA_BUS_FMT_UYVY8_1X16 (which you use) and MEDIA_BUS_FMT_UYVY8_2X8 (which driver supports) differ in the way the data is transfered on a bus but both are stored in memory the same way - the pixel format for both is V4L2_PIX_FMT_UYVY. The data transfer in the hw is hidden from us and the short answer is that for your case you can modify the driver to use MEDIA_BUS_FMT_UYVY8_1X16 instead of MEDIA_BUS_FMT_UYVY8_2X8 (just search and replace for that in the format arrays or everywhere) and it should work.

Thank you for your feedback on using the driver and please continue to keep us informed about your progress :slight_smile:

Best regards,
Todor

#13

Hi Todor,

Thanks a lot for your help.
I will try to modify the csiphy csid ispif and vfe drivers to support MEDIA_BUS_FMT_UYVY8_1X16.
I have a question:
{
MEDIA_BUS_FMT_UYVY8_2X8,
MEDIA_BUS_FMT_UYVY8_2X8,
DATA_TYPE_YUV422_8BIT,
DECODE_FORMAT_UNCOMPRESSED_8_BIT,
16
}
the data_type and uncompressed bits should be set as which value? keep same with MEDIA_BUS_FMT_UYVY8_2X8?

In addition:
camss.c probe function will return directly when camss_init_subdevices() failed(vfe msm_iommu_get_ctx() failed), and will be re-probed then successed.
I’m afraid of there may be a memory leak in this code:camss = devm_kzalloc(dev, sizeof(*camss), GFP_KERNEL);

Thanks for helping all the time.

Best Regards.

#14

Hi Amy,

I assume that your data type is YUV422 8-bit as defined by the MIPI spec for CSI2. If this is the case, then this format can be transfered over a 8 lane bus as MEDIA_BUS_FMT_UYVY8_2X8 or over 16 lane bus as MEDIA_BUS_FMT_UYVY8_1X16 but the data is still the same. So you leave data_type the same. Set uncompressed to MEDIA_BUS_FMT_UYVY8_1X16.

#15

As for the memory allocation, devm is used so it will be deallocated in case of failure.

#16

Hi Todor,

I changed MEDIA_BUS_FMT_UYVY8_2X8 to MEDIA_BUS_FMT_UYVY8_1X16 in csiphy csid ispif vfe video files.
then link and configure all the subdevices as we discussed but use format: UYVY/1920X1080
and use “gst-launch-1.0 v4l2src ! glimagesink”, there is no any data output even no any logs.
Is there any way to check csiphy or csid worked?
we checked the MIPI-CSI0 data line(4 lane) use oscilloscope, they are looks like right.
so we think 410C MIPI-CSI0 receiver may be has some issues.

thanks a lot.

Best Regards
Amy

#17

Hi Todor,

I’a so thankful for you support.
now how could I check csiphy csid status when MIPI-CSI input data lane have right wave?
I found the csiphy_isr will be called about 40 seconds after begin transfer data,
and about 100 seconds later will be called again.
can this be any sign for this issue? thanks.

Best Regards
Amy

#18

Hi Amy,

Good progress so far but now begins a harder part. There isn’t a lot of public information from QC how to debug this kind of problems.

One thing that you can try to do is to try to capture a CSI2 short packet - as they do in their downstream kernel driver.
Go in CSID part of the driver and in irq mask register enable interrupt (1 << 9).
Then if this interrupt fires (you check the same bit in irq status register) when you run your CSI2 transmitter, a short packet from the stream was captured and you can read this captured packet from register address (base + 0x74). Then you can check whether the packet is correct. Do this for test only, if you can capture the packet, do not leave this in your working system.

If no short packet is captured, then the CSID (CSI Decoder) couldn’t recognize and decode your stream. One possible reason is the Ths-settle time parameter as per the MIPI spec for CSI2. You may (or almost certainly will) need to play with this value to get it right so the CSID recognizes the HS transmission. You can check this topic about it:
http://www.96boards.org/forums/topic/mipi-csi-interface-support-for-interfacing-image-sensor/

Other problem even earlier could be if the CSIPHY does not recognize the communication. You can check that the data and clock lanes are correctly described in the endpoint configurations in the dtsi file.

Best regards,
Todor

#19

Hi Todor，

Thanks so much for your help. I have checked the CSID interrupt, there is no interrupt fires after start stream.
Only csiphy isr be triggered some times, I will follow your suggestion check the data and clock setting.
if any further progeress I will update here.

Best Regards
Amy

#20

Hi Todor,

I enbaled interrupt (1 << 9), there is no any interrupt fires after start stream.
and checked dtsi configure for data lanes and clock lane, do not get any effect。
Is there CSIPHY public document can shared to me?
I will continue to try modify camss configure.

Thanks for your help.

Best Regards
Amy