Set DTS for I2C2 as a normal i2c device

Products Support DragonBoard410c
#1

Hello everyone,

As you known, I2C2 (APQ_GPIO_29 & APQ_GPIO_30) is designed for CCI function.
However, if I want to use it as a normal I2C device (/dev/i2c-x), is it possible?
How to configure the dts to achieve this?

Currently, the dts settings for I2C2 in 16.09 is as below.
But, it does not generate the I2C device in /dev/i2c-x.


cci: qcom,cci@1b0c000 {
 cell-index = <0>;
 compatible = "qcom,cci";
 reg = <0x1b0c000 0x1000>;
 #address-cells = <1>;
 #size-cells = <0>;
 reg-names = "cci";
 interrupts = <GIC_SPI 50 0>;
 interrupt-names = "cci";
 clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
      <&gcc CCI_CLK_SRC>,
      <&gcc GCC_CAMSS_CCI_AHB_CLK>,
      <&gcc GCC_CAMSS_CCI_CLK>,
      <&gcc GCC_CAMSS_AHB_CLK>;
 clock-names = "camss_top_ahb_clk",
         "cci_src_clk",
                "cci_ahb_clk",
                "cci_clk",
                "camss_ahb_clk";
  qcom,clock-rates = <0 19200000 80000000 0 0>;
  pinctrl-names = "default", "sleep";
  pinctrl-0 = <&cci0_default>;
  pinctrl-1 = <&cci0_sleep>;
 ...

The normal I2C devices should set “qcom,i2c-qup-v2.2.1” compatible and corresponding “iface” & “core” clocks.


 blsp_i2c2: i2c@78b6000 {
 compatible = "qcom,i2c-qup-v2.2.1";
 reg = <0x78b6000 0x1000>;
 interrupts = <GIC_SPI 96 0>;
 clocks = <&gcc GCC_BLSP1_AHB_CLK>,
           <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
 clock-names = "iface", "core";

Badly, I don’t know what clock source I should set for I2C2.
Anyone can help for this?

Thanks,
Daniel

#2

Hi Daniel,

The “qcom,cci” vs “qcom,i2c-qup” relates to which hardware block that implements the i2c adapter. The i2c you’re looking at is hooked up to the cci block and as such a driver for that block needs to be used (not the QUP)

I do believe that the cci specification share enough with the i2c specification that you should be able to hook up non-camera related i2c clients on the CCI bus (but I’m not a HW guy). The current cci driver is however not implemented as a standard i2c adapter driver, so you will not be able to use your standard drivers or interfaces.

I do see reasons for implementing a proper i2c adapter driver for the cci block, if this happens you should be able to access your i2c clients through i2c-dev.

Regards,
Bjorn