Hi, On Fri, Oct 19, 2012 at 04:55:38PM +0000, Paul Walmsley wrote: > On Thu, 18 Oct 2012, Paul Walmsley wrote: > > > Here are some basic OMAP test results for Linux v3.7-rc1. > > Logs and other details at http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/ > > And here's two more. > > > Failing tests: needing investigation > > ------------------------------------ > > > > > > Boot tests: > > > > * 2420n800: boot hangs during UART initialization > > - http://lkml.org/lkml/2012/9/11/454 > > - Various attempts at fixes posted; etiology known; issue still unresolved > > > > * CM-T3517: L3 in-band error with IPSS during boot > > - Cause unknown but see > > http://marc.info/?l=linux-omap&m=134833869730129&w=2 > > - Longstanding issue; does not occur on the 3517EVM > > > > * 3517EVM & CM-T3517: boot hangs with NFS root > > - Likely some Kconfig, board file, and PM issues with EMAC > > > > * CM-T3517: boot hangs with MMC boot > > - Due to missing MMC setup in board file > > * 3530ES3 Beagle: I2C timeouts during userspace init > - May be related to the threaded IRQ conversion of the I2C driver > - Unknown cause
Doesn't seem like it's related to threaded IRQ. It says:
[ 23.673858] omap_i2c omap_i2c.1: timeout waiting for bus ready
at that time we didn't even program the transfer yet, meaning we're not
even on wait_for_completion_timeout() inside omap_i2c_xfer_msg(). This
happens before:
> static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
> {
> unsigned long timeout;
>
> timeout = jiffies + OMAP_I2C_TIMEOUT;
> while (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG) & OMAP_I2C_STAT_BB) {
> if (time_after(jiffies, timeout)) {
> dev_warn(dev->dev, "timeout waiting for bus ready\n");
it' stopping here. And that's called...
> return -ETIMEDOUT;
> }
> msleep(1);
> }
>
> return 0;
> }
[...]
> static int
> omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
> {
> struct omap_i2c_dev *dev = i2c_get_adapdata(adap);
> int i;
> int r;
>
> r = pm_runtime_get_sync(dev->dev);
> if (IS_ERR_VALUE(r))
> goto out;
>
> r = omap_i2c_wait_for_bb(dev);
right here. For whatever reason, the bus is kept busy (or at least the
driver thinks so).
Looking closely at the logs I see that definitely I2C was working during
early boot (we managed to mount file system on SD card and twl got
initialized properly). But then we have a long time where I2C isn't
used, so it probably suspended in between.
Then RTC wanted to read a register, I2C woke up, restored context, but
bus was kept busy, for whatever reason.
Does it happen all the time on multiple boots or is it ramdom ?
> if (r < 0)
> goto out;
>
> /*
> * When waiting for completion of a i2c transfer, we need to
> * set a wake up latency constraint for the MPU. This is to
> * ensure quick enough wakeup from idle, when transfer
> * completes.
> */
> if (dev->latency)
> pm_qos_add_request(&dev->pm_qos_request,
> PM_QOS_CPU_DMA_LATENCY,
> dev->latency);
>
> for (i = 0; i < num; i++) {
> r = omap_i2c_xfer_msg(adap, &msgs[i], (i == (num - 1)));
> if (r != 0)
> break;
> }
>
> if (dev->latency)
> pm_qos_remove_request(&dev->pm_qos_request);
>
> if (r == 0)
> r = num;
>
> omap_i2c_wait_for_bb(dev);
> out:
> pm_runtime_mark_last_busy(dev->dev);
> pm_runtime_put_autosuspend(dev->dev);
> return r;
> }
--
balbi
signature.asc
Description: Digital signature
