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 f
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 putt
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 i
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 t
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 simp
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 th
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 wi
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 de
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 configura
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 p
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 me,
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
12 matches
Mail list logo
