MicroZed PMOD Zynq PS MIO I2C controller registers unmapped

Hi James,

Correct me if I am wrong, but I assume that you are adding one or more slave devices to MicroZed via the PS Pmod and that this is not a multi-master configuration.

If this case, the recommended approach would be to use the Cadence driver and register I2C slave devices under it within the device tree.  Once they are registered, then the slave device drivers can be used to communicate with the slaves and the cadence driver then becomes mostly transparent for you.

In your top level DTS all of the lower level dtsi files can be overridden with additional parameters.  In the top level DTS (where the status = "okay" is found) that is where you should start adding definitions for each of the slave devices.

Here is an example device tree entry from one of the reference designs for our MicroZed EMBV which also uses PS I2C controller:

&i2c0 {

     status = "okay";

     i2cswitch@70 {

           compatible = "nxp,pca9548";

           #address-cells = <1>;

           #size-cells = <0>;

           reg = <0x70>;

           i2c@0 {

                #address-cells = <1>;

                #size-cells = <0>;

                reg = <0>;

                pca9354_0: gpio@20 {

                     compatible = "nxp,pca9534";

                     reg = <0x20>;

                     gpio-controller;

                     #gpio-cells = <2>;

                     /*

                     gpio_hdmii_reset_b {

                           gpio-hog;

                           gpios = <0 1>;

                           output-high;

                     };

                     */

                };

           };

           i2c@1 {

                #address-cells = <1>;

                #size-cells = <0>;

                reg = <1>;

                adv7611: hdmi-rx@4c {

                     compatible = "adi,adv7611";

                     reg = <0x4c>;

                     reset-gpios = <&pca9354_0 0 1>;

                     hpd-gpios = <&pca9354_0 2 0>;

                     adi,default-input = <0>;

                     #address-cells = <1>;

                     #size-cells = <0>;

                     port@0 {

                           reg = <0>;

                     };

                     port@1 {

                           reg = <1>;

                           embv_adv7611_out: endpoint {

                                remote-endpoint = <&embv_vcap_hdmi_in>;

                           };

                     };

                };

           };

           i2c@2 {

                #address-cells = <1>;

                #size-cells = <0>;

                reg = <2>;

                embv_adv7511: adv7511@39 {

                     compatible = "adi,adv7511";

                     reg = <0x39>;

                     pd-gpios = <&pca9354_0 4 0>;

                     adi,input-depth = <8>;

                     adi,input-colorspace = "yuv422";

                     adi,input-clock = "1x";

                     adi,input-style = <2>;

                     adi,input-justification = "left";

                     adi,clock-delay = <0x06>;

                     adi,embedded-sync = "true";

                };

           };

           /*

           i2c@4 {

                #address-cells = <1>;

                #size-cells = <0>;

                reg = <4>;

                adau1761: adau1761@3b {

                     compatible = "adi,adau1761";

                     reg = <0x3b>;

                };

           };

           */

           /* PYTHON-1300-C camera module */

           i2c@5 {

                #address-cells = <1>;

                #size-cells = <0>;

                reg = <5>;

                /* prototype hardware : PCA9554 at address 0x3C */

                /*

                pca9554_0: gpio@3c {

                      compatible = "nxp,pca9554";

                     reg = <0x3c>;

                     gpio-controller;

                     #gpio-cells = <2>;

                };

                */

                /* production hardware : PCA9554 at address 0x24 */

                pca9554_0: gpio@24 {

                     compatible = "nxp,pca9554";

                     reg = <0x24>;

                     gpio-controller;

                      #gpio-cells = <2>;

                };

           };

     };

From this MZEMBV specific mzembv-top-sdsoc.dts file, we can see that the following devices are being controlled by the above PS I2C driver:

•   PCA9548 (I2C mux)
•   PCA9534 (I2C I/O expander)
•   ADV7611 (HDMI input)
•   ADV7511 (HDMI output)
•   PCA9554 (I2C I/O expander, on PYTHON camera module)

My recommendation would be to use one of those slave device drivers as an example starting point for the I2C slave device you are prototyping up right now.  Again, this is all assuming that you are using a single master to multiple slave I2C bus architecture.

Regards,

-Kevin

Hi Kevin,

Thanks again for your help. I really appreciate it.

Actually there is only one I2C slave device attached to the PMOD. I tried the DTS approach with a slave that you describe, without effect.

In the ZedBoard I had used the PL based axi_iic core as I2C0, but just used the dev-i2c0 to access it, so I used the same approach under Petalinux and the generated DTS and DTSI sustained this configuration.

For this EEPROM fixture, I did encounter a problem where the driver missed the end of send interrupt, so I modified it to use a poll on the isr status register to complete the message process.

So I presumed that I may be encountering a similar problem here on the MicroZed SOM. But what I found was not the case. I don't see anything in your reply that would lead to thining that the DTSI is superseding the 0xe0004000 address for the bank of registers. And I don't see anything in my design. But the kernel debug trace revealed that the registers somehow were not actually mapped and writing to the register address was like to a floating memory address. The written data for R/W registers did not read back.

I can't find anything in the design whether Vivado or Petalinux in the device tree that would lead to this failure to map the addresses. The driver sees the 0xe0004000 and does the IO resource remap, but obviously it doesn't work.

I guess this part of the design will remain TBD until the main board is available.

BTW, what they asked also is to look into using the same PMOD with 2 devices attached. I.E., with the I2c on 4 Pmod pins of the bottom row  pins 7-12  and a gpio on the top row 0-6, using the appropriate MIO to connect to the PS controllers, but I hadn't even gotten to testing this. When I looked at the GPIO alone under sysfs I was unable to effect a change in the 0/1 status of the inputs. Again as if the register ports were not mapped. Do you think there is some Linux .config setting that I am missing?

But thanks for trying. If something occurs to me I will be sure to post

Sincerely,

James

Hi Kevin,

Thanks again for your help. I really appreciate it.

Actually there is only one I2C slave device attached to the PMOD. I tried the DTS approach with a slave that you describe, without effect.

In the ZedBoard I had used the PL based axi_iic core as I2C0, but just used the dev-i2c0 to access it, so I used the same approach under Petalinux and the generated DTS and DTSI sustained this configuration.

For this EEPROM fixture, I did encounter a problem where the driver missed the end of send interrupt, so I modified it to use a poll on the isr status register to complete the message process.

So I presumed that I may be encountering a similar problem here on the MicroZed SOM. But what I found was not the case. I don't see anything in your reply that would lead to thining that the DTSI is superseding the 0xe0004000 address for the bank of registers. And I don't see anything in my design. But the kernel debug trace revealed that the registers somehow were not actually mapped and writing to the register address was like to a floating memory address. The written data for R/W registers did not read back.

I can't find anything in the design whether Vivado or Petalinux in the device tree that would lead to this failure to map the addresses. The driver sees the 0xe0004000 and does the IO resource remap, but obviously it doesn't work.

I guess this part of the design will remain TBD until the main board is available.

BTW, what they asked also is to look into using the same PMOD with 2 devices attached. I.E., with the I2c on 4 Pmod pins of the bottom row  pins 7-12  and a gpio on the top row 0-6, using the appropriate MIO to connect to the PS controllers, but I hadn't even gotten to testing this. When I looked at the GPIO alone under sysfs I was unable to effect a change in the 0/1 status of the inputs. Again as if the register ports were not mapped. Do you think there is some Linux .config setting that I am missing?

But thanks for trying. If something occurs to me I will be sure to post

Sincerely,

James