Re: [PATCHv2] i2c: omap: Use noirq system sleep pm ops to idle device for suspend

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

 



Hi,

* Andreas Kemnade <andreas@xxxxxxxxxxxx> [190222 12:08]:
> Hmm, so what do we know:
> - git bisect at least led to something interesting, not some unrelated thing.
>     which might just cause timing differences.

Yes seems it's some twl related driver that gets only enabled for gta04
with your .config.

> - rtcwake + actual wakeup via rtc on my config = problem
> - rtcwake + actual wakeup via some other pin in the wkup domain = no problem
> - rtcwake + actual wakeup via powerbutton (twl4030-pwrbutton) = problem
> - omap2plus_defconfig seems to work here
> - no problems at other systems with dm3730 + twl4030 with my config
>   and with omap2plus defconfig
> 
> I deduce that there happens something strange at resume independant
> from what happend at suspend. Probably some timing issue.

It's probaby some twl related code is (wrongly) trying to read/write
registers at noirq suspend level. Sounds like some driver tagged with
noirq suspend ops while it should not.

> Hmm, does "bisecting" omap2_defconfig and my config give some helpful
> information? Besides of some key points like CONFIG_PREEMPT, I will probably
> just find things which somehow influence timing a little, so I will probably
> end up without anything interesting. Hopefully it will not just fix something.

I doubt it's a register access delay needed somewhere type issue though.
It seems to be related to what happens at suspend/resume noirq level.

> I will try to add printks to find out in which order things happen.

Yes good idea, maybe try with some printks added to twl reads
and writes? If it's too noisy, you could only enable the debugging for
suspend/resume cycle.

> We have
> enable_irq_wake(irq_num);
> in twl4030-irq.c: Does that has any interersting consequences? sys_nirq seems
> to be equal on non-affected and affected systems (pinmux + twl irq config)

The sys_nirq pin needs no remuxing and it's interrupt is always wake-up
capable since it's wired to the wake-up domain.

Regards,

Tony



[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