HDMI I2C Master Error

Anyone else have this error? The system cannot detect the proper resolutions to run, so it defaults to safe values.

Image: bbx15-eMMC-flasher-debian-8.1-lxqt-4gb-armhf-2015-09-06-4gb
Monitor: Asus 22" IPS HDMI Monitor (Ubuntu shows device as ‘Ancor Communications Inc 22"’)
Cable: Amazon 6’ “High Speed with Ethernet” HDMI cable

I was going to do a little poking around, but didn’t want to duplicate any effort.


Hi Louis,

No I2C interface on the eMMC.


Tomi ^^ ?

Can you dump the I2C from the terminal and see what you get?


Here's what i have..


same kernel/rootfs on microSD/eMMC (microSD works), cleaned the
*.dmesg for printk differences..

kernel is based on ti's v4.1.x as of last thursday morning...


I’ve done a little digging in the TRM. On pages 4714-4715 I found a pinmux configuration for i2c2 and HDMI DDC. It would appear that SDA and SCL are swapped for DDC vs i2c2. Maybe we could check the register values (CTRL_CORE_PAD_I2C2_SDA and CTRL_CORE_PAD_I2C2_SCL) on eMMC boot vs SD boot?

That was an issue we had on the first version of the board way back when. It was swapped in the processor.


I haven’t verified the addresses, but here is what a devmem2 read outputs:

debian@BeagleBoard-X15:~$ sudo ./devmem2 0x4A003808 /dev/mem opened. Memory mapped at address 0xb6f83000. Value at address 0x4A003808 (0xb6f83808): 0x50001 debian@BeagleBoard-X15:~$ sudo ./devmem2 0x4A00380C /dev/mem opened. Memory mapped at address 0xb6f68000. Value at address 0x4A00380C (0xb6f6880c): 0x50001


I'll try to reproduce this tomorrow when I get back to office.


While talking to Gerald/Jason...

After u-boot loads on the eMMC, shove in a microSD, i2c master works again...


And if I boot from microsd, and remove the card, HDMI i2c breaks.

I think the culprit is ldo1 regulator (VDD_SD). Set that to
regulator-always-on, and HDMI works.

Why this happens is that the tpd12s015 (HDMI level shifter/ESD
protection chip) has LS_OE GPIO input, which needs to be enabled for the
HDMI i2c to work. LS_OE comes from gpio6_28. The pin that provides
gpio6_28 is powered by vddshv8 (Table 4-2. Ball Characteristics in data
manual), and vddshv8 comes from VDD_SD.

So when VDD_SD is off, all pins powered by vddshv8 (no matter what the
muxing is), are disabled.

I remember complaining about this already years back on linux-omap, that
(at least at that time) there was no way to define the regulators needed
for pins.

Nishanth, any idea how to fix this?


Uggh.. you are right..
gives documentation pointers that mandates that all supplies to AM57xx
must remain always-on.

Could you submit a patch upstream fixing this?
Looking through the dts, this seems to be the only miss I did :frowning: