Andrew Morton wrote:
> Oh, it's just a pain in the ass. Please don't do it lightly - if there's a
> really good reason then OK.
>
The mmc code is a mess (mostly my fault for the addition of SD support)
and I'm trying to break things apart to clear the code up. That
unfortunately meant moving
On Tue, 06 Mar 2007 06:47:32 +0100 Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> >
> > (I'm also inclined to drop the darned mmc tree - am getting rather tired of
> > people moving their files all over the tree all the time).
> >
> >
>
> Fine, I can stop bothering with
Andrew Morton wrote:
>
> (I'm also inclined to drop the darned mmc tree - am getting rather tired of
> people moving their files all over the tree all the time).
>
>
Fine, I can stop bothering with putting up a test tree and just push the
stuff to Linus directly if that is what you prefer. Or
On Mon, 05 Mar 2007 10:19:55 -0500 Mark Lord <[EMAIL PROTECTED]> wrote:
> The interrupt is shared with another device, which resumes
> earlier than the sdhci controller, and generates an interrupt.
>
> The sdhci interrupt handler runs, sees 0x in its own
> device's interrupt status, and
Pierre Ossman wrote:
Mark Lord wrote:
From linux/Documentation/power/pci.txt:
That conveniently leaves out the part of how to handle when we're not
getting our stuff back. ;)
But it seems to be the easier route anyway... I'll whip up a patch.
It's probably best all-round.
But another
Mark Lord wrote:
> Pierre Ossman wrote:
>>
>> Hmm... I guess it can't be as the interrupt handler isn't associated
>> with a
>> device, just a random pointer.
>>
>> So either release the interrupt (which seems a bit unsafe as then we
>> might not
>> get it back), or handle states at the start of
Pierre Ossman wrote:
Pierre Ossman wrote:
I'd say it's the kernel calling the interrupt handler of a
currently sleeping device. Since we're seeing this problem I assume the
kernel's interrupt code isn't aware of PM states?
Hmm... I guess it can't be as the interrupt handler isn't associated
Pierre Ossman wrote:
> Mark Lord wrote:
>> But.. in the middle of all of this, we now see the SHDCI code
>> trying to talk to its as-yet-not-restored device, and being rather
>> noisy about it all:
>>
>
> Not quite. I'd say it's the kernel calling the interrupt handler of a
> currently sleeping
Mark Lord wrote:
Pierre Ossman wrote:
Mark Lord wrote:
Another regression, for Pierre Ossman this time.
My syslog gets spammed like this (below) on suspend/resume (to RAM)
cycles.
Worked fine, without all of the noise, in all previous kernels up to
2.6.20+.
This looks like a PCI
Mark Lord wrote:
>
> But.. in the middle of all of this, we now see the SHDCI code
> trying to talk to its as-yet-not-restored device, and being rather
> noisy about it all:
>
Not quite. I'd say it's the kernel calling the interrupt handler of a
currently sleeping device. Since we're seeing this
Pierre Ossman wrote:
Mark Lord wrote:
Another regression, for Pierre Ossman this time.
My syslog gets spammed like this (below) on suspend/resume (to RAM) cycles.
Worked fine, without all of the noise, in all previous kernels up to
2.6.20+.
This looks like a PCI configuration issue.
To
Pierre Ossman wrote:
Mark Lord wrote:
Another regression, for Pierre Ossman this time.
My syslog gets spammed like this (below) on suspend/resume (to RAM) cycles.
Worked fine, without all of the noise, in all previous kernels up to
2.6.20+.
This looks like a PCI configuration issue.
To
Mark Lord wrote:
But.. in the middle of all of this, we now see the SHDCI code
trying to talk to its as-yet-not-restored device, and being rather
noisy about it all:
Not quite. I'd say it's the kernel calling the interrupt handler of a
currently sleeping device. Since we're seeing this
Mark Lord wrote:
Pierre Ossman wrote:
Mark Lord wrote:
Another regression, for Pierre Ossman this time.
My syslog gets spammed like this (below) on suspend/resume (to RAM)
cycles.
Worked fine, without all of the noise, in all previous kernels up to
2.6.20+.
This looks like a PCI
Pierre Ossman wrote:
Mark Lord wrote:
But.. in the middle of all of this, we now see the SHDCI code
trying to talk to its as-yet-not-restored device, and being rather
noisy about it all:
Not quite. I'd say it's the kernel calling the interrupt handler of a
currently sleeping device. Since
Pierre Ossman wrote:
Pierre Ossman wrote:
I'd say it's the kernel calling the interrupt handler of a
currently sleeping device. Since we're seeing this problem I assume the
kernel's interrupt code isn't aware of PM states?
Hmm... I guess it can't be as the interrupt handler isn't associated
Mark Lord wrote:
Pierre Ossman wrote:
Hmm... I guess it can't be as the interrupt handler isn't associated
with a
device, just a random pointer.
So either release the interrupt (which seems a bit unsafe as then we
might not
get it back), or handle states at the start of the isr.
From
Pierre Ossman wrote:
Mark Lord wrote:
From linux/Documentation/power/pci.txt:
That conveniently leaves out the part of how to handle when we're not
getting our stuff back. ;)
But it seems to be the easier route anyway... I'll whip up a patch.
It's probably best all-round.
But another
On Mon, 05 Mar 2007 10:19:55 -0500 Mark Lord [EMAIL PROTECTED] wrote:
The interrupt is shared with another device, which resumes
earlier than the sdhci controller, and generates an interrupt.
The sdhci interrupt handler runs, sees 0x in its own
device's interrupt status, and tries
Andrew Morton wrote:
(I'm also inclined to drop the darned mmc tree - am getting rather tired of
people moving their files all over the tree all the time).
Fine, I can stop bothering with putting up a test tree and just push the
stuff to Linus directly if that is what you prefer. Or is
On Tue, 06 Mar 2007 06:47:32 +0100 Pierre Ossman [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
(I'm also inclined to drop the darned mmc tree - am getting rather tired of
people moving their files all over the tree all the time).
Fine, I can stop bothering with putting up a test
Andrew Morton wrote:
Oh, it's just a pain in the ass. Please don't do it lightly - if there's a
really good reason then OK.
The mmc code is a mess (mostly my fault for the addition of SD support)
and I'm trying to break things apart to clear the code up. That
unfortunately meant moving
Mark Lord wrote:
> Another regression, for Pierre Ossman this time.
>
> My syslog gets spammed like this (below) on suspend/resume (to RAM) cycles.
> Worked fine, without all of the noise, in all previous kernels up to
> 2.6.20+.
>
This looks like a PCI configuration issue. Can you bisect which
Another regression, for Pierre Ossman this time.
My syslog gets spammed like this (below) on suspend/resume (to RAM) cycles.
Worked fine, without all of the noise, in all previous kernels up to 2.6.20+.
Mar 4 23:28:45 silvy logger: suspending
Mar 4 23:29:09 silvy kernel: Stopping tasks ...
Another regression, for Pierre Ossman this time.
My syslog gets spammed like this (below) on suspend/resume (to RAM) cycles.
Worked fine, without all of the noise, in all previous kernels up to 2.6.20+.
Mar 4 23:28:45 silvy logger: suspending
Mar 4 23:29:09 silvy kernel: Stopping tasks ...
Mark Lord wrote:
Another regression, for Pierre Ossman this time.
My syslog gets spammed like this (below) on suspend/resume (to RAM) cycles.
Worked fine, without all of the noise, in all previous kernels up to
2.6.20+.
This looks like a PCI configuration issue. Can you bisect which
26 matches
Mail list logo
