ARM: OMAP5: DRA7xx: Enable I2C4 and I2C5 usage on the J6Eco EVM

On the J6Eco EVM we have two on-board devices on the I2C5 bus; this bus is also routed to the camera and expansion connectors. I2C4 is routed to one of the expansion connectors. This patch enables usage of these two buses.

For I2C5 to work, the 'ARM: OMAP5: DRA7xx: Enable I2C5 operation' patch is required as a prerequisite.

Tested on a J6 ECO EVM rev.B with a DRA726 ES1.0.

---
 board/ti/dra7xx/evm.c      |    7 +++++++
 board/ti/dra7xx/mux_data.h |    8 ++++++++
 2 files changed, 15 insertions(+)

index 37df7b2..25dae8e 100644
@@ -124,6 +124,13 @@ void set_muxconf_regs_essential(void)
 		     core_padconf_array_essential,
 		     sizeof(core_padconf_array_essential) /
 		     sizeof(struct pad_conf_entry));
+
+	if (omap_revision() == DRA722_ES1_0) {
+		do_set_mux32((*ctrl)->control_padconf_core_base,
+			     core_padconf_array_j6ecoevm,
+			     sizeof(core_padconf_array_j6ecoevm) /
+			     sizeof(struct pad_conf_entry));
+	}
 }
 
 #if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_GENERIC_MMC)

index 4824077..f155f65 100644
@@ -141,4 +141,12 @@ const struct pad_conf_entry core_padconf_array_essential[] = {
 	{USB2_DRVVBUS, (M0 | IEN | FSC) },
 	{SPI1_CS1, (PEN | IDIS | M14) },
 };
+
+const struct pad_conf_entry core_padconf_array_j6ecoevm[] = {
+	{MCASP1_AXR0, (IEN | PTU | PDIS | M10)},/* I2C5_SDA */
+	{MCASP1_AXR1, (IEN | PTU | PDIS | M10)},/* I2C5_SCL */
+
+	{MCASP4_ACLKX, (IEN | PTU | PDIS | M4)},/* I2C4_SDA */
+	{MCASP4_FSX, (IEN | PTU | PDIS | M4)},	/* I2C4_SCL */
+};
 #endif /* _MUX_DATA_DRA7XX_H_ */

1.7.9.5

OK, but what's the usecase for enabling these in U-Boot? Are we using things on these buses?

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141117/b0fb913a/attachment.pgp>

Hi Tom,

Both I2C4 and I2C5 are routed to expansion connectors on the J6Eco board. If a customer has some add-on hardware with I2C devices attached through these connectors, it seems useful to have the buses functional for bring- up/debug. Moreover, the board itself has two devices on I2C5, one of them being a GPIO expander driving some system configuration signals (e.g. for override of the boot settings), and being able to control it could be useful as well.

Best regards,
Lubo

Tom,

Even if this patch is not applied if considered useless, the one fixing the clocks (http://patchwork.ozlabs.org/patch/410834/) should be, in my opinion, as it is essentially a bug fix. Now, for the DRA7xx SoCs,
1) a write to a undefined (or zero) register address is occurring since struct member .cm_l4per_i2c5_clkctrl is not initialized, and
2) a 'data abort' exception shall happen if access to I2C5 is tried due to lack of the functional clock.

Best regards,
Lubo