* Daniel Mack | 2013-10-01 15:31:08 [+0200]:
Patch #1 restores more registers on resume time.
Patch #2 is a cosmetic cleanup that emerged while digging through the
driver and gaining a basic idea of how it's implemented. Nothing fancy.
I'm fine with those two.
Patch #3, however, gives me
On 09.10.2013 08:41, Sebastian Andrzej Siewior wrote:
* Daniel Mack | 2013-10-01 15:31:08 [+0200]:
Patch #1 restores more registers on resume time.
Patch #2 is a cosmetic cleanup that emerged while digging through the
driver and gaining a basic idea of how it's implemented. Nothing fancy.
On 10/09/2013 09:23 AM, Daniel Mack wrote:
Ok, thank you very much for the update :) I can of course test
alternative patches if you have any.
Could you actually reproduce the issue I described by sending your board
to suspend?
No, I don't have mem, just freeze. I try to test if this is a
On 09.10.2013 09:28, Sebastian Andrzej Siewior wrote:
On 10/09/2013 09:23 AM, Daniel Mack wrote:
Ok, thank you very much for the update :) I can of course test
alternative patches if you have any.
Could you actually reproduce the issue I described by sending your board
to suspend?
No, I
* Daniel Mack | 2013-10-01 15:31:08 [+0200]:
Patch #3, however, gives me headaches. I can't fully explain what's
going on, but I can tell for sure that if fixes a problem that I stared
on for many hours.
The problem is that on resume, the musb core will detect that some of
the suspended USB
On 02.10.2013 12:20, Sebastian Andrzej Siewior wrote:
* Daniel Mack | 2013-10-01 15:31:08 [+0200]:
Patch #3, however, gives me headaches. I can't fully explain what's
going on, but I can tell for sure that if fixes a problem that I stared
on for many hours.
The problem is that on resume,
On 10/02/2013 01:07 PM, Daniel Mack wrote:
No, as stated, the line numbers in the kernel message are somewhat off
due to added debugging code. What kicks in here is this one:
if (!c-td_desc_seen) {
desc_phys = cppi41_pop_desc(cdd, c-q_comp_num);
if
