Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

I am using MityDSP-L138F board.

What are you using for your baseboard?

The problem is that if we enable both I2C interfaces by changing the linux source code by adding the following lines at the "arch/arm/mach-davinci/board-mityomapl138.c"

ret = da8xx_register_i2c(1, &mityomap_i2c_1_pdata);
       if (ret)
             pr_warning("mityomapl138_init: i2c1 registration failed: %d\n",
                         ret);

Then, writes at the i2c-1 driver fail and the system halts. We have found that if we firstly run any of the following commands:

i2cdetect -y 1 0x8
or
i2cset -y 1 0x8 0
or
i2cset -y 1 0x8 1

then from that point onwards the I2C read / writes succeed and the linux OS doesn't get stuck.

Did you set the pin-mux settings for the I2C1 lines on the second device in the kernel as well? For the devkit baseboard, they are set to UART2_TXD and RXD to support the RS485 port on J504.

Both the I2C0 and I2C1 ports are exposed on the edge connector. If you are seeing something on address 0x8 of I2C0, then there is likely something on your baseboard reporting at that ID.

-Mike

We use a custom baseboard, but the address 0x8 is at the the industrial IO development kit as well:

root@PureVLC:~# i2cdetect y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: - -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
50: UU 51 52 53 54 55 56 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Our PINMUX configuration is displayed at the following function:

347 static int init baseboard_init(void)
348 {
349 pr_info("%s [%s]...\n", __func, BASEBOARD_NAME);
350
351 da8xx_pinmux_setup(baseboard_gpio_pins);
352
353 da8xx_pinmux_setup(da850_i2c1_pins);
354
355 baseboard_setup_lcd();
356
357 baseboard_setup_mmc();
358
359 baseboard_setup_spi();
360
361 baseboard_setup_mcasp();
362
363 return 0;
364 }

Well at the least I can identify the others. 0x38 is the dvi chip, 0x48 is the pmic, and 0x50-58 is the eeprom. When I try to read from the 0x08 address I get all sorts of i2c error messages.

Also on a devkit where the dvi chip was removed the 0x08 address still appears.

root@mityomapl138:~# i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- 08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
50: UU 51 52 53 54 55 56 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

OK. So is it a defect on the MityDSP-L138F board, or is it the address of the OMAP I2C bus?

Source : System Management Bus (SMBus) Specification Version 2.0 August 3, 2000 :Appendix C – SMBus device address assignments:

0001 000 SMBus Host System Management Bus Specification v 1.1 December 1998

Does this mean that it is a reserved address for the SMBus host?

We're looking at it now. I think that the i2c-tools may be emulating SMBus and trying to run the arbitration scheme at 0x08. We note that the u-Boot utility does not detected at address 0x08 and only sees the PMIC at 0x48 and the EEPROM at 0x50-0x57. Sorry for the delay.

-Mike

No worries. I don't think i2c-detect does anything strange with this address. By looking at the code, I don't see any provision for this. It just writes to all the addresses and see what comes back.

I think the transition of the 0x8 image from u-boot to linux is happenning at the following code. I don't completely understand where the 0x8 value is written though... Any ideas?

237 /*
238  * This function configures I2C and brings I2C out of reset.
239  * This function is called during I2C init function. This function
240  * also gets called if I2C encounters any errors.
241  */
242 static int i2c_davinci_init(struct davinci_i2c_dev *dev)
243 {
244       struct davinci_i2c_platform_data *pdata = dev->dev->platform_data;
245 
246       if (!pdata)
247             pdata = &davinci_i2c_platform_data_default;
248 
249       /* put I2C into reset */
250       davinci_i2c_reset_ctrl(dev, 0);
251 
252       /* compute clock dividers */
253       i2c_davinci_calc_clk_dividers(dev);
254 
255       /* Respond at reserved "SMBus Host" slave address" (and zero);
256        * we seem to have no option to not respond...
257        */
258       davinci_i2c_write_reg(dev, DAVINCI_I2C_OAR_REG, 0x08);                                                                                                                                                                               
259 
260       dev_dbg(dev->dev, "PSC  = %d\n",
261             davinci_i2c_read_reg(dev, DAVINCI_I2C_PSC_REG));
262       dev_dbg(dev->dev, "CLKL = %d\n",
263             davinci_i2c_read_reg(dev, DAVINCI_I2C_CLKL_REG));
264       dev_dbg(dev->dev, "CLKH = %d\n",
265             davinci_i2c_read_reg(dev, DAVINCI_I2C_CLKH_REG));
266       dev_dbg(dev->dev, "bus_freq = %dkHz, bus_delay = %d\n",
267             pdata->bus_freq, pdata->bus_delay);
268 
269       /* Take the I2C module out of reset: */
270       davinci_i2c_reset_ctrl(dev, 1);
271 
272       /* Enable interrupts */
273       davinci_i2c_write_reg(dev, DAVINCI_I2C_IMR_REG, I2C_DAVINCI_INTR_ALL);
274 
275       return 0;
276 }

Looks like the kernel is configuring the OMAP-L138 I2C slave address as 0x08 (by default, it is 0x00 - illegal - in the TRM).

As the comments and the TRM suggest, it doesn't look like you can disable slave response mode in the OMAP-L138 I2C peripheral...

So my guess is that when you try to access it, the device is generating a slave interrupt and stalls because in slave mode it's waiting for an external source to drive the clock (SCL) line.

So not a problem with the module, but a problem with the peripheral and/or a combination of the peripheral and the driver.

If you don't hit 0x08, I don't think you should have a problem. We have a lot of customers using the I2C ports with this module without and issues...

-Mike

Hi Mike, actually our experience is the opposite:

1. Enable I2C1, flash the new kernel and reboot
2. Immediately after reboot, attempt to use I2C0 by setting the processor clock: "echo 456000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed"
3. Process blocks

However, if we do the following:

1. Enable I2C1, flash the new kernel and reboot
2. Immediately after reboot, run: "i2cdetect -y 2 0x08 0x08" or just "i2cdetect -y 2"
3. Then run: "echo 456000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed"
4. Command succeeds

This would seem to imply that the bus is already stalled on boot and running i2cdetect on I2C1 "unsticks" it? Why would enabling I2C1 cause a stall on I2C0?

This is all on the IndustrialIO baseboard. We observe the same on our custom baseboard which has 20k pullups to 3V3 for both the I2C0 and I2C1 bus.

Here's the kernel hung task stack trace in case it helps:

INFO: task sh:1428 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
sh D c026dc74 0 1428 1426 0x00000000
[<c026dc74>] (schedule+0x2a8/0x334) from [<c026e2e0>] (schedule_timeout+0x1c/0x218)
[<c026e2e0>] (schedule_timeout+0x1c/0x218) from [<c026e164>] (wait_for_common+0xf0/0x1b8)
[<c026e164>] (wait_for_common+0xf0/0x1b8) from [<c019ca1c>] (i2c_davinci_cpufreq_transition+0x18/0x50)
[<c019ca1c>] (i2c_davinci_cpufreq_transition+0x18/0x50) from [<c00599a4>] (notifier_call_chain+0x38/0x68)
[<c00599a4>] (notifier_call_chain+0x38/0x68) from [<c0059a80>] (__srcu_notifier_call_chain+0x40/0x58)
[<c0059a80>] (__srcu_notifier_call_chain+0x40/0x58) from [<c0059aac>] (srcu_notifier_call_chain+0x14/0x18)
[<c0059aac>] (srcu_notifier_call_chain+0x14/0x18) from [<c019dd78>] (cpufreq_notify_transition+0xc8/0xfc)
[<c019dd78>] (cpufreq_notify_transition+0xc8/0xfc) from [<c00373ac>] (davinci_target+0x144/0x154)
[<c00373ac>] (davinci_target+0x144/0x154) from [<c019d404>] (__cpufreq_driver_target+0x28/0x38)
[<c019d404>] (__cpufreq_driver_target+0x28/0x38) from [<c019f260>] (cpufreq_set+0x54/0x70)
[<c019f260>] (cpufreq_set+0x54/0x70) from [<c019d698>] (store_scaling_setspeed+0x58/0x6c)
[<c019d698>] (store_scaling_setspeed+0x58/0x6c) from [<c019e3d0>] (store+0x58/0x74)
[<c019e3d0>] (store+0x58/0x74) from [<c00d8854>] (sysfs_write_file+0x108/0x140)
[<c00d8854>] (sysfs_write_file+0x108/0x140) from [<c009512c>] (vfs_write+0xb0/0x118)
[<c009512c>] (vfs_write+0xb0/0x118) from [<c0095244>] (sys_write+0x3c/0x68)
[<c0095244>] (sys_write+0x3c/0x68) from [<c002bea0>] (ret_fast_syscall+0x0/0x28)
Kernel panic - not syncing: hung_task: blocked tasks
[<c003069c>] (unwind_backtrace+0x0/0xd0) from [<c026d810>] (panic+0x44/0xc8)
[<c026d810>] (panic+0x44/0xc8) from [<c006aa7c>] (watchdog+0x1d4/0x21c)
[<c006aa7c>] (watchdog+0x1d4/0x21c) from [<c0054670>] (kthread+0x78/0x80)
[<c0054670>] (kthread+0x78/0x80) from [<c002c8dc>] (kernel_thread_exit+0x0/0x8)
Rebooting in 1 seconds..


Ok, you didn't mention you are trying to adjust the CPU speed (or I missed it) as your I2C0 access method. That's not quite the same as using I2C0 from the command line via i2c-utils or some other driver access (e.g., the EEPROM). Are you seeing issues doing an i2c-get or set on I2C0 or reading the PROM, or just via the cpu speed selection?

When you adjust the CPU frequency, there are callbacks to all the drivers that need to adjust their internal clock divisors to handle changes in the clock tree (e.g., to ensure that the I2C1 clock is either 100 or 400 Khz after a PLL clock change has occurred). That is where your stack trace is pointing (cpufreq_notify_transition...). I am wondering if the I2C1 device is not yet powered up / enabled after the kernel boots because nothing has needed to access it (no registered devices, etc.). If the I2C1 is not powered up or a clock in it's tree is not enabled, then perhaps the kernel hanging in these device callbacks - this would be a bug in the I2C driver PM code, and it would need to be addressed.

I2C0 is enabled / powered in the kernel because the PMIC and factory I2C prom is attached to it and the kernel uses it during startup.

To confirm, you don't see this issue with I2C1 not enabled in you kernel (the "stock" dev kit kernel), correct?

Also, are you configuring the pin mux in the kernel baseboard file to change DA850_UART2_RXD/DA850_UART2_TXD to the I2C1 functions DA850_I2C1_SCL/DA850_I2C1_SDA (see line 465 of baseboard-industrialio.c)? The driver may be hanging waiting on SCL being released or something.

-Mike

Hi Mike,

To confirm, you don't see this issue with I2C1 not enabled in you kernel (the "stock" dev kit kernel), correct?

Correct, no such issues with the stock kernel config.

Also, are you configuring the pin mux in the kernel baseboard file to change DA850_UART2_RXD/DA850_UART2_TXD to the I2C1 functions DA850_I2C1_SCL/DA850_I2C1_SDA (see line 465 of baseboard-industrialio.c)? The driver may be hanging waiting on SCL being released or something.

The kernel release we are working with does not have DA850_UART2_RXD/DA850_UART2_TXD defined in the baseboard-industrialio.c file. To enable the I2C1 functions, we modified the baseboard init function to:

static int __init baseboard_init(void)
{
        pr_info("%s [%s]...\n", __func__, BASEBOARD_NAME);

        da8xx_pinmux_setup(baseboard_gpio_pins);

        da8xx_pinmux_setup(da850_i2c1_pins);

        baseboard_setup_lcd();

        baseboard_setup_mmc();

        baseboard_setup_spi();

        baseboard_setup_mcasp();

        return 0;
}

You might be right in your suspicion regarding the cpufreq change triggering the issue since I can successfully perform other operations on the I2C0 bus (e.g., i2cget or a write to an I2C DAC we have) without stalling.

Were you able to reproduce the cpufreq stalling issue with I2C1 enabled at your end?

Thanks.

I can confirm. Made the following changes to the 3.2 kernel and tried changing the frequency. It locks up if you don't access the i2c bus first.

diff --git a/arch/arm/mach-davinci/baseboard-industrialio.c b/arch/arm/mach-davinci/baseboard-industrialio.c
index 112cbf0..f897bad 100644
--- a/arch/arm/mach-davinci/baseboard-industrialio.c
+++ b/arch/arm/mach-davinci/baseboard-industrialio.c
@@ -426,11 +426,17 @@ postcore_initcall_sync(baseboard_pre_init);
  * UART2 Pins for expansion port (RS-485 port).
  */
 static short baseboard_uart2_pins[] __initdata = {
-       DA850_UART2_RXD,
-       DA850_UART2_TXD,
+       DA850_I2C1_SCL,
+       DA850_I2C1_SDA,
        -1,
 };

+static struct davinci_i2c_platform_data mityomap_i2c_1_pdata = {
+       .bus_freq       = 100,  /* kHz */
+       .bus_delay      = 0,    /* usec */
+};
+
+
 static int __init baseboard_init(void)
 {
        int ret;
@@ -439,6 +445,9 @@ static int __init baseboard_init(void)
        davinci_cfg_reg_list(baseboard_gpio_pins);

        davinci_cfg_reg_list(baseboard_uart2_pins);
+       ret = da8xx_register_i2c(1, &mityomap_i2c_1_pdata);
+       if (ret)
+               pr_warning("i2c1 registration failed: %d\n", ret);

        baseboard_setup_mmc();

The transition function looks like following. The wait_for_completion call then calls wait_for_common which can be seen in your stack trace.

static int i2c_davinci_cpufreq_transition(struct notifier_block *nb,
                                     unsigned long val, void *data)
{
        struct davinci_i2c_dev *dev;

        dev = container_of(nb, struct davinci_i2c_dev, freq_transition);
        if (val == CPUFREQ_PRECHANGE) {
                wait_for_completion(&dev->xfr_complete);
                davinci_i2c_reset_ctrl(dev, 0);
        } else if (val == CPUFREQ_POSTCHANGE) {
                i2c_davinci_calc_clk_dividers(dev);
                davinci_i2c_reset_ctrl(dev, 1);
        }

        return 0;
}

It appears that the wait_for_completion is the wrong type of synchronization as it currently will always be true as long as there has been a transfer over the i2c bus. It probably intended to make sure that an ongoing transfer completes before changing the frequency. As a work around I'd suggest to comment out the wait_for_completion(&dev->xfr_complete); line as its not accomplishing what it was intended for anyways.

diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index a76d85f..564247f 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -596,7 +596,7 @@ static int i2c_davinci_cpufreq_transition(struct notifier_block *nb,

        dev = container_of(nb, struct davinci_i2c_dev, freq_transition);
        if (val == CPUFREQ_PRECHANGE) {
-               wait_for_completion(&dev->xfr_complete);
+               //wait_for_completion(&dev->xfr_complete);
                davinci_i2c_reset_ctrl(dev, 0);
        } else if (val == CPUFREQ_POSTCHANGE) {
                i2c_davinci_calc_clk_dividers(dev);

Thanks Jonathan, I can confirm that the workaround allows the CPU frequency scaling to work with I2C1 enabled (but not yet accessed).

Okay I have submitted a bug report to the linux davinci mailing list using some of your procedures and stack trace. Waiting to see what they have to contribute.

I've created a test branch with my patches for this problem. Could you verify it works for you? Note that branch would need i2c1 enabled.

Branch: mitydsp-linux-v3.2_i2c_wip

http://support.criticallink.com/gitweb/?p=linux-davinci.git;a=shortlog;h=refs/heads/mitydsp-linux-v3.2_i2c_wip

Hi Jonathan, thanks for the testing branch. As our code is still based around the old 2.6.34-rc1 release, it will be while before we can fully port everything and test against the 3.2 kernel. However, I did try the I2C bits and your patches appear to solve the problem.

While testing, I came across another I2C issue in the 3.2 branch that causes a hang. To reproduce:

1. Change clock to 456M: "echo 456000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed"
2. Attempt to change the clock back to 300M: "echo 300000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed"
3. Process blocks with the following stack trace:

INFO: task sh:1561 blocked for more than 20 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
sh D c028788c 0 1561 1559 0x00000000
[<c028788c>] (__schedule+0x328/0x390) from [<c02891c4>] (__rt_mutex_slowlock+0xb4/0xe4)
[<c02891c4>] (__rt_mutex_slowlock+0xb4/0xe4) from [<c0289450>] (rt_mutex_slowlock+0xe8/0x168)
[<c0289450>] (rt_mutex_slowlock+0xe8/0x168) from [<c01adc14>] (i2c_transfer+0x90/0x10c)
[<c01adc14>] (i2c_transfer+0x90/0x10c) from [<c01add14>] (i2c_master_send+0x38/0x48)
[<c01add14>] (i2c_master_send+0x38/0x48) from [<c014a738>] (regmap_i2c_write+0x10/0x28)
[<c014a738>] (regmap_i2c_write+0x10/0x28) from [<c014889c>] (_regmap_raw_write+0xa8/0x140)
[<c014889c>] (_regmap_raw_write+0xa8/0x140) from [<c0148aec>] (regmap_write+0x24/0x38)
[<c0148aec>] (regmap_write+0x24/0x38) from [<c0123414>] (tps65023_dcdc_set_voltage+0xc0/0xe4)
[<c0123414>] (tps65023_dcdc_set_voltage+0xc0/0xe4) from [<c01211b0>] (_regulator_do_set_voltage+0x3c/0x1d8)
[<c01211b0>] (_regulator_do_set_voltage+0x3c/0x1d8) from [<c01214cc>] (regulator_set_voltage+0xc0/0xd4)
[<c01214cc>] (regulator_set_voltage+0xc0/0xd4) from [<c00144d8>] (davinci_target+0x130/0x158)
[<c00144d8>] (davinci_target+0x130/0x158) from [<c01b00b4>] (__cpufreq_driver_target+0x28/0x38)
[<c01b00b4>] (__cpufreq_driver_target+0x28/0x38) from [<c01b1e5c>] (cpufreq_set+0x54/0x70)
[<c01b1e5c>] (cpufreq_set+0x54/0x70) from [<c01b0644>] (store_scaling_setspeed+0x58/0x6c)
[<c01b0644>] (store_scaling_setspeed+0x58/0x6c) from [<c01b10c4>] (store+0x58/0x74)
[<c01b10c4>] (store+0x58/0x74) from [<c00c571c>] (sysfs_write_file+0x108/0x140)
[<c00c571c>] (sysfs_write_file+0x108/0x140) from [<c007a3b4>] (vfs_write+0xb0/0x128)
[<c007a3b4>] (vfs_write+0xb0/0x128) from [<c007a4dc>] (sys_write+0x3c/0x68)
[<c007a4dc>] (sys_write+0x3c/0x68) from [<c00093e0>] (ret_fast_syscall+0x0/0x2c)
Kernel panic - not syncing: hung_task: blocked tasks
[<c000d590>] (unwind_backtrace+0x0/0xe4) from [<c028726c>] (panic+0x58/0x198)
[<c028726c>] (panic+0x58/0x198) from [<c004ba20>] (watchdog+0x1dc/0x234)
[<c004ba20>] (watchdog+0x1dc/0x234) from [<c003579c>] (kthread+0x84/0x8c)
[<c003579c>] (kthread+0x84/0x8c) from [<c0009cf8>] (kernel_thread_exit+0x0/0x8)
Rebooting in 1 seconds..


I attempted the same on the old 2.6.34-rc1 kernel and the CPU freq. changed as expected (no hang).

I tried your steps on the mitydsp-linux-v3.2_i2c_wip with i2c-2 enabled but didn't encounter a hang.

That's really strange. The only modifications I made were to baseboard-industrialio.c in order to enable i2c-2:

diff --git a/arch/arm/mach-davinci/baseboard-industrialio.c b/arch/arm/mach-davinci/baseboard-industrialio.c
index 112cbf0..4958dbe 100644
--- a/arch/arm/mach-davinci/baseboard-industrialio.c
+++ b/arch/arm/mach-davinci/baseboard-industrialio.c
@@ -426,11 +426,19 @@ postcore_initcall_sync(baseboard_pre_init);
  * UART2 Pins for expansion port (RS-485 port).
  */
 static short baseboard_uart2_pins[] __initdata = {
-       DA850_UART2_RXD,
-       DA850_UART2_TXD,
+       //DA850_UART2_RXD,
+       //DA850_UART2_TXD,
+       DA850_I2C1_SCL,
+       DA850_I2C1_SDA,
        -1,
 };

+
+static struct davinci_i2c_platform_data mityomap_i2c_1_pdata = {
+       .bus_freq       = 100,  /* kHz */
+       .bus_delay      = 0,    /* usec */
+};
+
 static int __init baseboard_init(void)
 {
        int ret;
@@ -440,6 +448,10 @@ static int __init baseboard_init(void)

        davinci_cfg_reg_list(baseboard_uart2_pins);

+        ret = da8xx_register_i2c(1, &mityomap_i2c_1_pdata);
+        if (ret)
+                pr_warning("i2c1 registration failed: %d\n", ret);
+
        baseboard_setup_mmc();

        /* SYSTEM_RESET PIN connected to CAN controller and AUDIO controller */

After that, I ran


$ make -j4 ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- industrialio_defconfig


to generate the .config which I modified in order to compile the USB RNDIS gadget as a built-in. After compiling the uImage and flashing it, running the steps I mentioned earlier leads to a hang (on the IndustrialIO baseboard). I am attaching the .config for your reference.

Just to verify this was with the newer mitydsp-linux-v3.2_i2c_wip branch?