• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 100 subscribers
  • Views 887 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

I2C[2] pinmux issue on DM8148

Jean-Michel CAPITAN
Prodigy 160 points

HI,

On our design, we use the 4x I2C controlers. Using the PINMUX tool, we have placed I2C[0] signals on AC4/AB6, I2C[1] on AF24/AG24, I2C[2] on AA21/AE17 and I2C[3] on AH6/AG6. Both I2C[0], I2C[1] and I2C[3] work fine, but not I2C[2]. We never observe any activity on SCL or SDA. Are there special registers to be set to activate I2C[2] on this pinset ? I can email the PINMUX file if it can help.

Thanks in advance for your support.

  • 0
    Intellectual 505 points

    Jean-Michel,

    Take a look at kernel/arch/arm/mach-omap2/omap_hwmod_81xx_data.c. In ti816x_i2c2_hwmod, change .omap_chip from OMAP_CHIP_INIT(CHIP_IS_TI816X) to OMAP_CHIP_INIT(CHIP_IS_TI814X | CHIP_IS_TI816X).

    You'll also have to fix kernel/arch/arm/mach-omap2/i2c.c omap2_i2c_mux_pins() to whatever matches your board.

    Regards,
    Chris

  • 0
    Intellectual 420 points

    Jean-Michel

    I have not had the luck you have had. Though, I am able to see all four dev nodes (after updating omap_hwmod_81xx_data.c). However, only I2C[0] (bus 1) works for me. Can you send me the following files from your working build? As well as any other files that you think you had to modify to get it working?

    1) omap_hwmod_81xx_data.c

    2) i2c.c

    3) board-ti8148evm.c

    Did you change the pinmux of any other pins?

    Other posts suggest clock issues. Did you have to set any registers to enable I2C clocks?

    Thanks!

  • 0 in reply to Joseph Waclawski
    Prodigy 160 points

    Hi,

    Our initial pinmux was OK, no change required on this side.

    We got I2C[0] working immediatly.  But for I2C[1], we have had to apply a TI patch (to non-documented registers).

    For the I2C[2],  we found that after the end of Linux boot, some of our initial pinmux settings was overwritten by some code (like PINCNTL135 set to 0s)

    You can find our updated file, and associated patches in the following zip file : http://dl.free.fr/iRZgvxq4O

    If it can help you or others...

  • 0 in reply to Jean-Michel CAPITAN
    Intellectual 420 points

    Jean-Michel

    The site is en francais, and I cannot understand how to access the .zip file. From my point of view, the link you provided takes me to an advertisement for some free service. But, it's mostly en francais, so I don't understand it. Is there an alternative way you can provide me this file? Can you attach the .zip file directly to a post (select Options, and you can attach a file to the post).

    Thanks

  • 0 in reply to Jean-Michel CAPITAN
    Intellectual 420 points

    Thanks

    Can you tell me when the functions in board-adp2.c are invoked? I see there is some duplication with board-ti8148evm.c. What's up with that?

    But looking at what you provided, it's not clear to me that I am not already doing all these things. Can you provide details regarding:

    1) Significance of your uboot/pinmux.c. Is it specific to I2C or GPIO? Is it necessary. What is it doing?

    2) Can you point out in your files specifically what the changes were to get I2C[1], I2C[2] and I2C[3] working?

    I cannot find the significant difference in what I have versus what you have.

    Also, if you would like to take this conversation offline, I can provide you with my direct email address.

    Thanks

  • 0 in reply to Joseph Waclawski
    Intellectual 420 points

    To whom is interested.

    I have been able to update my kernel to set up the proper operation of the I2C busses. Therefore my problem is solved. In the end, the solution was simple with minor updates to the 8148 EZSDK files. I will post my actual solution at a later time when I have cleaned up my work, and have a concise set of files that comprise the solution. In the meantime, if you need more immediate details, feel free to reply to this post and I will respond in kind.

    Cheers

  • 0 in reply to Joseph Waclawski
    Expert 1015 points

    Hi, Joseph.

    I also cannot get response on i2c[2] (which is i2c-3 in linux). In fact i can see activity on sda and scl lines. But the i2c controller cannot see ack from the external device.

    Have you seen the same behavior?

    Best regards,

    Alexander Vasiljev.

  • 0 in reply to Alexander Vasiljev
    Intellectual 420 points

    We currently have nothing attached to that bus in our hardware (but we eventually will). I have no visibility into that bus yet, so I cannot say for certain. But, when I probe that bus for devices, I get random responses back, suggesting that the bus is operational, but given that I do not currently know the state of the lines on the bus (i.e. they may be floating) the behavior may be as expected.

    When I know for certain what is going on, I will repost.

  • 0 in reply to Joseph Waclawski
    Intellectual 420 points

    Alexander,

    I, too, could not get response on the I2C[2] bus. Turns out that the firmware load was overwriting certain I2C mux assignments. I have updated /etc/init.d/load-hd-firmware.sh as follows, which precludes the firmware load from modifying i2c configuration:

    firmware_loader $HDVICP2_ID /usr/share/ti/ti-media-controller-utils/dm814x_hdvicp.xem3 start -i2c 0

    firmware_loader $HDVPSS_ID /usr/share/ti/ti-media-controller-utils/dm814x_hdvpss_v4l2.xem3 start -i2c 0


    Now, all 4 I2C buses are working fine. You have to be aware of what software initializes what hardware (especially pinmux changes) in the Linux boot sequence. We are currently setting up the pinmux at the very beginning of the ti8148_evm_init() function in board-ti8148evm.c. We have found that other functions in the boot sequence override our hardware pinmux, and we take care of those cases as we find them.

    Hope this helps.