Re: [PATCH] OMAP/I2C - Fix timeout problem during suspend.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 04 Jan 2012 14:19:48 -0800 Kevin Hilman <khilman@xxxxxx> wrote:

> +Felipe
> 
> NeilBrown <neilb@xxxxxxx> writes:
> 
> > On a board with OMAP3 processor and TWL4030 Power management,
> > we need to talk to the TWL4030 during late suspend but cannot
> > because the I2C interrupt is disabled (as late suspend disables
> > interrupt).
> 
> I'm not convinced this is the right solution to this problem.
> 
> IMO, this problem is caused by the MUSB driver being broken for
> suspend/resume.  I've reported this problem (and an RFC/PATCH)
> already[1], but I don't think the driver has been fixed.
> 
> Can you try my patch[1] to see if it fixes your problem as well?
> 
> Kevin
> 
> [1] http://marc.info/?l=linux-omap&m=132252827112721&w=2
> 

Yes... and no.

I reverted my patch to confirm that the timeout messages come back which
they did.
I then applied your patch and the suspend was nice and smooth again with no
timeouts.  So that is good.

However immediately after I wake it up I get:

[  109.193054] Powerdomain (core_pwrdm) didn't enter target state 1
[  109.199310] Could not enter target state in pm_suspend

whereas with my patch in place I get:

[  123.666046] Successfully put all powerdomains to target state

Following this hint I looked into current draw.  With my patch I get a
suspend-time current draw of 60-80mA (which is still too high..).
With your patch in place I get 120mA or more (about 4 tests, definitely at
least 30mA difference).  I measure this by checking the 'charge_now' reported
by the bq27000 in the battery.

This is without the usb cable plugged in.  With usb plugged in your version
has the positive effect that charging continues while in suspend while with
mine it doesn't.  But I don't think that justifies the extra current drain :-)

So I'll be sticking with my patch for now.

My next problem I need to resolve relates to i2c and the charger as well.
When entering suspend the various twl4030 interrupts are disabled by not
masked.  This means they can still fire but are not handled until after
suspend.  This effectively blocks other interrupts from the twl4030 that I
actually want (like the RTC alarm).
I think there are at least 3 or 4 bugs in here making it rather hard to sort
out.  However I think I will want to mask interrupt sources when they are
disabled.  To mask the interrupts I need to talk to the twl4030 over i2c.
And this means that I need the i2c interrupt to still be working.

So I feel that my patch might be more generally useful.  However I confess
that there is a lot here that I don't completely understand, and I might have
a different opinion tomorrow.

Thanks,
NeilBrown

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux