* Re: snd-aoa status update / automatic driver loading
From: Eddy Petrişor @ 2006-05-25 7:21 UTC (permalink / raw)
To: Johannes Berg, linuxppc-dev list, debian-powerpc
In-Reply-To: <20060523154137.GA3205@spring.luon.net>
T24gNS8yMy8wNiwgU2pvZXJkIFNpbW9ucyA8c2pvZXJkQHNwcmluZy5sdW9uLm5ldD4gd3JvdGU6
Cj4gT24gRnJpLCBNYXkgMTksIDIwMDYgYXQgMTE6MjA6MjlQTSArMTAwMCwgUGF1bCBDb2xsaW5z
IHdyb3RlOgo+ID4gSm9oYW5uZXMgQmVyZyA8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4gd3Jp
dGVzOgo+ID4KPiA+ID4gT24gVGh1LCAyMDA2LTA1LTE4IGF0IDEwOjI1ICswMzAwLCBFZGR5IFBl
dHJpPz9vciB3cm90ZToKPiA+ID4KPiA+ID4+IEFueSBjaGFuY2UgZm9yIDUsMiA/IFdoYXQgaXMg
bmVlZGVkIGZvciBpdD8gQ29kZWMgb25seT8KPiA+ID4KPiA+ID4gSSBkb24ndCBrbm93LiBJZiB5
b3UgdHJ5IGxvYWRpbmcgdGhlIG1vZHVsZXMsIHRoZSBrZXJuZWwgd2lsbCB0ZWxsIHlvdQo+ID4g
PiBzb21ldGhpbmcgYWJvdXQgYW4gdW5oYW5kbGVkIGxheW91dCBpZC4gQWx0ZXJuYXRpdmVseSwg
eW91IGNhbiBmaW5kIHRoZQo+ID4gPiBsYXlvdXQtaWQgZmlsZSBpbiB5b3VyIC9wcm9jL2Rldmlj
ZS10cmVlLyBhbmQgdGVsbCBtZSB0aGUgbnVtYmVyIGluIGl0Lgo+ID4gPiBUaGUgcmVzdCBJIGNh
biBmaWd1cmUgb3V0Lgo+Cj4gSSB3YW50ZWQgdG8gdGVzdCBvbiBteSBQb3dlckJvb2s1LDIuIFVo
Zm9ydHVuYXRlbHkgaSBjYW4ndCBmaW5kIG5vIGxheW91dC1pZAo+IGZpbGUgZm9yIHRoZSBzb3Vu
ZCBkZXZpY2Ugb3IgYW55IG90aGVyIGxheW91dC1pZCBmaWxlIGZvciB0aGF0IG1hdHRlcjoKClNh
bWUgbWFjaGluZSBoZXJlOyBJIGhhdmUgY2xvbmVkIHRoZSBhb2EgcmVwbyBhbmQgIm1hZGUiIGl0
LgpJbnNtb2QgZGlkbid0IHdvcmsgb24gYW55IG90aGVyIG1vZHVsZSBidXQgdGhlIHRoZSBzb3Vu
ZGJ1cywgYW5kCnJlc3VsdGVkIGluIGEgbWlzc2luZyBzeW1ib2wuCgpUaGlzIGlzIG9uIGEgMi4x
Ni4xNyBrZXJuZWwKCgotLSAKUmVnYXJkcywKRWRkeVAKPT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09CiJJbWFnaW5hdGlvbiBpcyBtb3JlIGltcG9ydGFudCB0aGFu
IGtub3dsZWRnZSIgQS5FaW5zdGVpbgo=
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Eddy Petrişor @ 2006-05-25 7:21 UTC (permalink / raw)
To: linuxppc-dev list, debian-powerpc
In-Reply-To: <60381eeb0605250021t17ff3299l74fc59993c683306@mail.gmail.com>
T24gNS8yNS8wNiwgRWRkeSBQZXRyacWfb3IgPGVkZHkucGV0cmlzb3JAZ21haWwuY29tPiB3cm90
ZToKPiBUaGlzIGlzIG9uIGEgMi4xNi4xNyBrZXJuZWwKCmVyciwgMi42LjE2LjE3CgotLSAKUmVn
YXJkcywKRWRkeVAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
CiJJbWFnaW5hdGlvbiBpcyBtb3JlIGltcG9ydGFudCB0aGFuIGtub3dsZWRnZSIgQS5FaW5zdGVp
bgo=
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Benjamin Herrenschmidt @ 2006-05-25 8:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, Benjamin Berg, debian-powerpc
In-Reply-To: <1148463777.11734.19.camel@johannes>
On Wed, 2006-05-24 at 11:42 +0200, Johannes Berg wrote:
> On Wed, 2006-05-24 at 08:15 +1000, Benjamin Herrenschmidt wrote:
> > > Right, that's how snd-powermac does it. It has the nasty side-effect of
> > > polluting the cache a lot though, since dbdma commands are 16 bytes
> > > long. Am I wrong?
> >
> > You don't have that much DBDMA commands that it would pollute the cache
> > _a lot_ :)
>
> Ah, yeah, I guess so. Well I do have 32 dbdma commands, them being
> spaced up in 16-bytes means 16 cachelines, no? I'm not sure how the
> cache is wired up ...
On a 32 bits CPU yes.
> > > Alsa calls this thing the 'pointer' :) The frame counter we currently
> > > use is the frame counter register of the i2s bus controller, and I don't
> > > see why we shouldn't do that instead of reading back all the dbdma
> > > command status fields.
> >
> > If you manage to have it properly in sync, that may work too.
>
> Seems to work fine so far, even if bcm43xx kills a few interrupts ;)
So it's bcm's fault ? Did you do a bit of analysis ? that would be
useful...
Ben.
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-25 9:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Benjamin Berg, debian-powerpc
In-Reply-To: <1148544004.13249.270.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 471 bytes --]
On Thu, 2006-05-25 at 18:00 +1000, Benjamin Herrenschmidt wrote:
> So it's bcm's fault ? Did you do a bit of analysis ? that would be
> useful...
I kinda assumed the list was lagging again and my brother had already
posted the solution. Yes, bcm does some measuring stuff that keeps
interrupts disabled for lots of milliseconds (25 or something). It's
being fixed.
I still think, however, that we ought to be able to deal with lost
interrupts.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Johannes Berg @ 2006-05-25 9:43 UTC (permalink / raw)
To: Eddy Petrişor; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <60381eeb0605250021t17ff3299l74fc59993c683306@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 277 bytes --]
On Thu, 2006-05-25 at 10:21 +0300, Eddy Petrişor wrote:
> Same machine here; I have cloned the aoa repo and "made" it.
> Insmod didn't work on any other module but the the soundbus, and
> resulted in a missing symbol.
You probably forgot to load snd-pcm.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: PowerMac: force only suspend-to-disk to be valid
From: Johannes Berg @ 2006-05-25 10:05 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Andrew Morton
In-Reply-To: <1146562296.3858.9.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]
On Tue, 2006-05-02 at 11:31 +0200, Johannes Berg wrote:
> This patch adds the .valid callback to pm_ops on PowerMac so that only the
> suspend to disk state can be entered. Note that just returning 0 would
> suffice since the upper layers don't pass PM_SUSPEND_DISK down, but I think
> they ought to be passing it down since they do really need support (or
> am I mistaken again?) so we handle it there regardless.
No one ever seemed to care about this patch, can we queue it up for
2.6.18? I suppose it's too late now for 2.6.17 even if it fixes the
long-standing but that on ppc, /sys/power/state kills the machine.
[quoted patch for reference]
> --- wireless-dev.orig/arch/powerpc/platforms/powermac/setup.c 2006-05-02 10:57:32.101509438 +0200
> +++ wireless-dev/arch/powerpc/platforms/powermac/setup.c 2006-05-02 10:58:44.491509438 +0200
> @@ -463,11 +463,23 @@ static int pmac_pm_finish(suspend_state_
> return 0;
> }
>
> +static int pmac_pm_valid(suspend_state_t state)
> +{
> + switch (state) {
> + case PM_SUSPEND_DISK:
> + return 1;
> + /* can't do any other states via generic mechanism yet */
> + default:
> + return 0;
> + }
> +}
> +
> static struct pm_ops pmac_pm_ops = {
> .pm_disk_mode = PM_DISK_SHUTDOWN,
> .prepare = pmac_pm_prepare,
> .enter = pmac_pm_enter,
> .finish = pmac_pm_finish,
> + .valid = pmac_pm_valid,
> };
>
> #endif /* CONFIG_SOFTWARE_SUSPEND */
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* [snd] looking for layout-ids
From: Johannes Berg @ 2006-05-25 10:43 UTC (permalink / raw)
To: debian-powerpc; +Cc: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
Hey,
In order to replace snd-powermac for the newer machines where the
'sound' node has the 'layout-id' property, I'm looking for testers on
machines that have a layout-id [1] property with one of the following
values: 0x24, 0x29, 0x33, 0x50 and 0x3a.
Once I have all these, I will, along with submitting snd-aoa [2], submit
a patch to snd-powermac that makes it refuse loading in presence of a
layout-id property as a first step to migrate to snd-aoa.
At the same time, I'll probably make i2sbus refuse attaching to a device
unless there's a layout-id property so that it doesn't claim devices aoa
doesn't handle yet.
johannes
[1] to find your layout-id, execute the following:
find /proc/device-tree/ -name layout-id | xargs hexdump -e '1/4 "0x%x\n"'
If you get no output, you have no layout-id property. If you do get
output, it will look like this:
0x46
This is the layout-id of your sound node.
[2] Before you ask: I will not do this before snd-aoa supports headphone
detection :)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Andreas Schwab @ 2006-05-25 12:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148553785.11759.12.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> writes:
> In order to replace snd-powermac for the newer machines where the
> 'sound' node has the 'layout-id' property, I'm looking for testers on
> machines that have a layout-id [1] property with one of the following
> values: 0x24
That would be mine, but it has the problem of the broken device tree, so
i2sbus doesn't work yet.
> [2] Before you ask: I will not do this before snd-aoa supports headphone
> detection :)
Another important feature would be DRC, IMHO.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Johannes Berg @ 2006-05-25 12:37 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <jefyiy9tds.fsf@sykes.suse.de>
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]
> > In order to replace snd-powermac for the newer machines where the
> > 'sound' node has the 'layout-id' property, I'm looking for testers on
> > machines that have a layout-id [1] property with one of the following
> > values: 0x24
>
> That would be mine, but it has the problem of the broken device tree, so
> i2sbus doesn't work yet.
Ah, right. I'll have to check with Ben a bit more when he comes back. He
seemed to have half of a plan ;)
> > [2] Before you ask: I will not do this before snd-aoa supports headphone
> > detection :)
>
> Another important feature would be DRC, IMHO.
Yeah, I guess, but that's only doable with the tas codec. I don't think
it's hard, if anyone wnats to try: the tas datasheet is in my
repository, and all you need to do is modify the tas codec to show the
controls for that. Could also use some bass/treble controls.
If we want DRC even for the other machines, that's an alsa userspace
thing since it needs a soft-DSP then.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Johannes Berg @ 2006-05-25 12:41 UTC (permalink / raw)
To: Ken Moffat; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <20060525123247.GA19308@deepthought.linux.bogus>
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
Hey,
> How about 0x3c and 0x3d (PowerMac9,1) ? I can't see anything in
> snd-aoa-fabric-layout that matches 60 or 61. I last tried to play
> with this a few weeks ago, but gave up with what I assumed were
> config problems (undefined symbols) and had too many other things to
> get on with.
undefined symbols are usually because alsa isn't configured, or snd-pcm
isn't loaded.
> Certainly, this is one of the machines where loading snd-powermac
> is catastrophic.
Catastrophic? How so? Anyway, I don't care much :)
Anyway, if you want to give it a spin, try the latest snd-aoa (see
http://johannes.sipsolutions.net/Projects/snd-aoa/ for a description).
It should report an unknown layout, which are those two ones you
described above. I think you probably have a tas and topaz combination,
so if you get i2sbus to load, I might be able to give you a patch to
test.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: CPU 1 refused to die!
From: Giuliano Pochini @ 2006-05-25 12:46 UTC (permalink / raw)
To: Nathan Lynch; +Cc: LinuxPPC-dev
In-Reply-To: <20060523225113.GD11414@localdomain>
On 23-May-2006 Nathan Lynch wrote:
> Giuliano Pochini wrote:
>>
>> I booted with maxcpus=1, then I enabled the 2nd cpu
>> with echo 1 > /sys/devices/system/cpu/cpu1/online
>
> So onlining at runtime seems to work. Did you verify that tasks get
> run on the 2nd cpu after you online it?
Yes, I did, and the difference in speed is pretty obvious.
> Any other strange messages in dmesg?
Nothing unusual.
> Can you online and offline cpus if you boot without maxcpus=1?
It behaves exactly the same. I can't say exactly when it stopped
working. 2.6.14 worked fine.
--
Giuliano.
^ permalink raw reply
* Re: [snd] looking for layout-ids
From: Paul Collins @ 2006-05-25 13:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1148553785.11759.12.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> writes:
> Hey,
>
> In order to replace snd-powermac for the newer machines where the
> 'sound' node has the 'layout-id' property, I'm looking for testers on
> machines that have a layout-id [1] property with one of the following
> values: 0x24, 0x29, 0x33, 0x50 and 0x3a.
0x33 here.
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: PowerMac: force only suspend-to-disk to be valid
From: Andrew Morton @ 2006-05-25 14:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1148551527.11759.10.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Tue, 2006-05-02 at 11:31 +0200, Johannes Berg wrote:
> > This patch adds the .valid callback to pm_ops on PowerMac so that only the
> > suspend to disk state can be entered. Note that just returning 0 would
> > suffice since the upper layers don't pass PM_SUSPEND_DISK down, but I think
> > they ought to be passing it down since they do really need support (or
> > am I mistaken again?) so we handle it there regardless.
>
> No one ever seemed to care about this patch,
I don't recall having seen it before.
> can we queue it up for
> 2.6.18? I suppose it's too late now for 2.6.17 even if it fixes the
> long-standing but that on ppc, /sys/power/state kills the machine.
>
> [quoted patch for reference]
>
> > --- wireless-dev.orig/arch/powerpc/platforms/powermac/setup.c 2006-05-02 10:57:32.101509438 +0200
> > +++ wireless-dev/arch/powerpc/platforms/powermac/setup.c 2006-05-02 10:58:44.491509438 +0200
> > @@ -463,11 +463,23 @@ static int pmac_pm_finish(suspend_state_
> > return 0;
> > }
> >
> > +static int pmac_pm_valid(suspend_state_t state)
> > +{
> > + switch (state) {
> > + case PM_SUSPEND_DISK:
> > + return 1;
> > + /* can't do any other states via generic mechanism yet */
> > + default:
> > + return 0;
> > + }
> > +}
> > +
> > static struct pm_ops pmac_pm_ops = {
> > .pm_disk_mode = PM_DISK_SHUTDOWN,
> > .prepare = pmac_pm_prepare,
> > .enter = pmac_pm_enter,
> > .finish = pmac_pm_finish,
> > + .valid = pmac_pm_valid,
> > };
> >
> > #endif /* CONFIG_SOFTWARE_SUSPEND */
>
It looks like a 2.6.17 patch to me. If someone wants to send it over with
changelog, signed-off-by, etc I can take care of it.
^ permalink raw reply
* Re: PowerMac: force only suspend-to-disk to be valid
From: Andrew Morton @ 2006-05-25 14:10 UTC (permalink / raw)
To: johannes, linuxppc-dev, benh
In-Reply-To: <20060525070558.2b7e24cd.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
>
> > > +static int pmac_pm_valid(suspend_state_t state)
> > > +{
> > > + switch (state) {
> > > + case PM_SUSPEND_DISK:
> > > + return 1;
> > > + /* can't do any other states via generic mechanism yet */
> > > + default:
> > > + return 0;
> > > + }
> > > +}
> > > +
> > > static struct pm_ops pmac_pm_ops = {
> > > .pm_disk_mode = PM_DISK_SHUTDOWN,
> > > .prepare = pmac_pm_prepare,
> > > .enter = pmac_pm_enter,
> > > .finish = pmac_pm_finish,
> > > + .valid = pmac_pm_valid,
> > > };
> > >
> > > #endif /* CONFIG_SOFTWARE_SUSPEND */
> >
>
> It looks like a 2.6.17 patch to me. If someone wants to send it over with
> changelog, signed-off-by, etc I can take care of it.
>
Please also explain whether this fix is needed in 2.6.16.x.
^ permalink raw reply
* [PATCH] PowerMac: force only suspend-to-disk to be valid
From: Johannes Berg @ 2006-05-25 14:11 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list
This patch adds the .valid callback to pm_ops on PowerMac so that only the
suspend to disk state can be entered. Note that just returning 0 would
suffice since the upper layers don't pass PM_SUSPEND_DISK down, but we
handle it there regardless just in case that changes.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
--- wireless-dev.orig/arch/powerpc/platforms/powermac/setup.c 2006-05-02 10:57:32.101509438 +0200
+++ wireless-dev/arch/powerpc/platforms/powermac/setup.c 2006-05-02 10:58:44.491509438 +0200
@@ -463,11 +463,23 @@ static int pmac_pm_finish(suspend_state_
return 0;
}
+static int pmac_pm_valid(suspend_state_t state)
+{
+ switch (state) {
+ case PM_SUSPEND_DISK:
+ return 1;
+ /* can't do any other states via generic mechanism yet */
+ default:
+ return 0;
+ }
+}
+
static struct pm_ops pmac_pm_ops = {
.pm_disk_mode = PM_DISK_SHUTDOWN,
.prepare = pmac_pm_prepare,
.enter = pmac_pm_enter,
.finish = pmac_pm_finish,
+ .valid = pmac_pm_valid,
};
#endif /* CONFIG_SOFTWARE_SUSPEND */
^ permalink raw reply
* Re: PowerMac: force only suspend-to-disk to be valid
From: Johannes Berg @ 2006-05-25 14:13 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20060525071013.21379ba8.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 319 bytes --]
On Thu, 2006-05-25 at 07:10 -0700, Andrew Morton wrote:
> Please also explain whether this fix is needed in 2.6.16.x.
Well, for a very long time, echoing 'standby' or 'mem'
into /sys/power/state has killed the machine on powerpc. This patch
fixes that. So I guess yes, it is applicable to 2.6.16.x
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [Fwd: Re: via-pmu runs device_power_down in atomic context]
From: Alan Stern @ 2006-05-25 14:12 UTC (permalink / raw)
To: Andrew Morton; +Cc: cpufreq, Johannes Berg, linuxppc-dev
In-Reply-To: <20060524215917.230af218.akpm@osdl.org>
On Wed, 24 May 2006, Andrew Morton wrote:
> > device_power_down should be called with interrupts off, thus the PMU
> > driver is fine. It's a misnamed function, it calls the sysdev's suspend
> > and those should be called with irq off. I think the problem is more due
> > to some cpufreq or notifier change that somebody done to recent kernels
> > and that added some might_sleep.... I wonder why.
> >
> > Andrew, what's up there ? What is this new
> > "blocking_notifier_call_chain" thing ? notifiers use to not use
> > semaphores and not be blocking... at least powermac implementation of
> > cpufreq relies on that.
>
> notifiers used to be racy too - we just waddled across them without any
> locking.
>
> Alan made a best-effort conversion of callers, and there have been a few
> problems.
>
> Here, pmac has gone and unilaterally decided that device_power_down() is
> atomic, even though device_power_down() _already_ calls suspend_device(),
> which does down(). So I'd say you've gone and found a via-pmu bug here.
>
> A way of shutting up the warning would be to use an atomic notifier, but
> it'll still be buggy. Better would be to teach pmac_suspend_devices() not
> to assume things which aren't true ;)
Someone else had a problem with the cpufreq conversion earlier. I posted
a message on the cpufreq mailing list but nobody ever responded to it.
This may or may not be related to that earlier problem.
In essence, the problem seemed to be that the cpufreq notifier chain is
sometimes expected to be blocking and sometimes expected to be atomic,
based on the "val" code passed to notifier_call_chain. The cleanest
solution would be to split the single notifier chain into two chains,
one always blocking and the other always atomic.
Somebody who knows more about cpufreq than I do will have to make that
change.
Alan Stern
^ permalink raw reply
* Re: [PATCH] PowerMac: force only suspend-to-disk to be valid
From: Andrew Morton @ 2006-05-25 14:41 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1148566305.11759.35.camel@johannes.berg>
Johannes Berg <johannes@sipsolutions.net> wrote:
>
> This patch adds the .valid callback to pm_ops on PowerMac so that only the
> suspend to disk state can be entered. Note that just returning 0 would
> suffice since the upper layers don't pass PM_SUSPEND_DISK down, but we
> handle it there regardless just in case that changes.
That's the "what" - please provide the "why": what bug does this fix, and
what are the consequences of not having this patch?
^ permalink raw reply
* Re: [Fwd: Re: via-pmu runs device_power_down in atomic context]
From: Andrew Morton @ 2006-05-25 14:44 UTC (permalink / raw)
To: Alan Stern; +Cc: cpufreq, johannes, linuxppc-dev
In-Reply-To: <Pine.LNX.4.44L0.0605251005450.6990-100000@iolanthe.rowland.org>
Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Wed, 24 May 2006, Andrew Morton wrote:
>
> > > device_power_down should be called with interrupts off, thus the PMU
> > > driver is fine. It's a misnamed function, it calls the sysdev's suspend
> > > and those should be called with irq off. I think the problem is more due
> > > to some cpufreq or notifier change that somebody done to recent kernels
> > > and that added some might_sleep.... I wonder why.
> > >
> > > Andrew, what's up there ? What is this new
> > > "blocking_notifier_call_chain" thing ? notifiers use to not use
> > > semaphores and not be blocking... at least powermac implementation of
> > > cpufreq relies on that.
> >
> > notifiers used to be racy too - we just waddled across them without any
> > locking.
> >
> > Alan made a best-effort conversion of callers, and there have been a few
> > problems.
> >
> > Here, pmac has gone and unilaterally decided that device_power_down() is
> > atomic, even though device_power_down() _already_ calls suspend_device(),
> > which does down(). So I'd say you've gone and found a via-pmu bug here.
> >
> > A way of shutting up the warning would be to use an atomic notifier, but
> > it'll still be buggy. Better would be to teach pmac_suspend_devices() not
> > to assume things which aren't true ;)
>
> Someone else had a problem with the cpufreq conversion earlier. I posted
> a message on the cpufreq mailing list but nobody ever responded to it.
> This may or may not be related to that earlier problem.
>
> In essence, the problem seemed to be that the cpufreq notifier chain is
> sometimes expected to be blocking and sometimes expected to be atomic,
> based on the "val" code passed to notifier_call_chain. The cleanest
> solution would be to split the single notifier chain into two chains,
> one always blocking and the other always atomic.
>
> Somebody who knows more about cpufreq than I do will have to make that
> change.
>
I wouldn't describe the cpufreq project as a teeming hive of frenetic
activity, and we need something pronto.
We could go back to a raw_notifier and be as buggy as we used to be.
^ permalink raw reply
* Re: [Fwd: Re: via-pmu runs device_power_down in atomic context]
From: Jon Loeliger @ 2006-05-25 16:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: cpufreq, johannes, Alan Stern, linuxppc-dev@ozlabs.org
In-Reply-To: <20060525074412.19a03c22.akpm@osdl.org>
On Thu, 2006-05-25 at 09:44, Andrew Morton wrote:
> > In essence, the problem seemed to be that the cpufreq notifier chain is
> > sometimes expected to be blocking and sometimes expected to be atomic,
> > based on the "val" code passed to notifier_call_chain. The cleanest
> > solution would be to split the single notifier chain into two chains,
> > one always blocking and the other always atomic.
> >
> > Somebody who knows more about cpufreq than I do will have to make that
> > change.
> >
>
> I wouldn't describe the cpufreq project as a teeming hive of frenetic
> activity, and we need something pronto.
>
> We could go back to a raw_notifier and be as buggy as we used to be.
It _is_ actively being pursued today for a cleaned up
implementation. If there are issues or requirements
here, we should really pass them on to the linux-pm list.
Thanks,
jdl
^ permalink raw reply
* Re: snd-aoa status update / automatic driver loading
From: Eddy Petrişor @ 2006-05-25 17:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <1147947784.15507.46.camel@johannes>
T24gNS8xOC8wNiwgSm9oYW5uZXMgQmVyZyA8am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldD4gd3Jv
dGU6Cj4gT24gVGh1LCAyMDA2LTA1LTE4IGF0IDEwOjI1ICswMzAwLCBFZGR5IFBldHJpxZ9vciB3
cm90ZToKPgo+ID4gQW55IGNoYW5jZSBmb3IgNSwyID8gV2hhdCBpcyBuZWVkZWQgZm9yIGl0PyBD
b2RlYyBvbmx5Pwo+Cj4gSSBkb24ndCBrbm93LiBJZiB5b3UgdHJ5IGxvYWRpbmcgdGhlIG1vZHVs
ZXMsIHRoZSBrZXJuZWwgd2lsbCB0ZWxsIHlvdQo+IHNvbWV0aGluZyBhYm91dCBhbiB1bmhhbmRs
ZWQgbGF5b3V0IGlkLiBBbHRlcm5hdGl2ZWx5LCB5b3UgY2FuIGZpbmQgdGhlCj4gbGF5b3V0LWlk
IGZpbGUgaW4geW91ciAvcHJvYy9kZXZpY2UtdHJlZS8gYW5kIHRlbGwgbWUgdGhlIG51bWJlciBp
biBpdC4KPiBUaGUgcmVzdCBJIGNhbiBmaWd1cmUgb3V0LgoKSSBhbSBub3Qgc3VyZSBpZiB5b3Ug
Y2FuIG1ha2UgX25vd18gc29tZXRoaWduIG91dCBvZiB0aGlzIGluZm8sIGJ1dCBJCmd1ZXNzIHRo
aXMgaXMgd2lsbCBub3QgaHVydDoKCmh0dHA6Ly9saXN0cy5kZWJpYW4ub3JnL2RlYmlhbi1wb3dl
cnBjLzIwMDYvMDQvbXNnMDAwNTkuaHRtbApodHRwOi8vbGlzdHMuZGViaWFuLm9yZy9kZWJpYW4t
cG93ZXJwYy8yMDA2LzA0L21zZzAwMDYzLmh0bWwKCi0tIApSZWdhcmRzLApFZGR5UAo9PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KIkltYWdpbmF0aW9uIGlzIG1v
cmUgaW1wb3J0YW50IHRoYW4ga25vd2xlZGdlIiBBLkVpbnN0ZWluCg==
^ permalink raw reply
* [PATCH] Make cpufreq_transition_notifier a raw notifier
From: Alan Stern @ 2006-05-25 17:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev@ozlabs.org, johannes, cpufreq
In-Reply-To: <1148575497.24946.40.camel@cashmere.sps.mot.com>
The cpufreq code has problems with atomic vs. blocking notifier calls and
enabling vs. disabling interrupts (show up on pmac). As a temporary
band-aid, this patch (as697) makes the cpufreq_transition_notifier_list
into a raw notifier.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
---
On Thu, 25 May 2006, Jon Loeliger wrote:
> On Thu, 2006-05-25 at 09:44, Andrew Morton wrote:
>
> > > In essence, the problem seemed to be that the cpufreq notifier chain is
> > > sometimes expected to be blocking and sometimes expected to be atomic,
> > > based on the "val" code passed to notifier_call_chain. The cleanest
> > > solution would be to split the single notifier chain into two chains,
> > > one always blocking and the other always atomic.
> > >
> > > Somebody who knows more about cpufreq than I do will have to make that
> > > change.
> > >
> >
> > I wouldn't describe the cpufreq project as a teeming hive of frenetic
> > activity, and we need something pronto.
> >
> > We could go back to a raw_notifier and be as buggy as we used to be.
>
> It _is_ actively being pursued today for a cleaned up
> implementation. If there are issues or requirements
> here, we should really pass them on to the linux-pm list.
>
> Thanks,
> jdl
Here's the patch Andrew asked for. I have no idea whether it will solve
any of these problems, and I'm certain that in the long run we shouldn't
keep it. Perhaps it will at least help stabilize 2.6.17.
It's up to you guys to see if the patch helps at all and to decide whether
or not it should be applied.
Alan Stern
Index: usb-2.6/drivers/cpufreq/cpufreq.c
===================================================================
--- usb-2.6.orig/drivers/cpufreq/cpufreq.c
+++ usb-2.6/drivers/cpufreq/cpufreq.c
@@ -50,10 +50,9 @@ static void handle_update(void *data);
* validation process for a new CPU frequency policy; the
* "transition" list for kernel code that needs to handle
* changes to devices when the CPU clock speed changes.
- * The mutex locks both lists.
*/
static BLOCKING_NOTIFIER_HEAD(cpufreq_policy_notifier_list);
-static BLOCKING_NOTIFIER_HEAD(cpufreq_transition_notifier_list);
+static RAW_NOTIFIER_HEAD(cpufreq_transition_notifier_list);
static LIST_HEAD(cpufreq_governor_list);
@@ -263,14 +262,14 @@ void cpufreq_notify_transition(struct cp
freqs->old = policy->cur;
}
}
- blocking_notifier_call_chain(&cpufreq_transition_notifier_list,
+ raw_notifier_call_chain(&cpufreq_transition_notifier_list,
CPUFREQ_PRECHANGE, freqs);
adjust_jiffies(CPUFREQ_PRECHANGE, freqs);
break;
case CPUFREQ_POSTCHANGE:
adjust_jiffies(CPUFREQ_POSTCHANGE, freqs);
- blocking_notifier_call_chain(&cpufreq_transition_notifier_list,
+ raw_notifier_call_chain(&cpufreq_transition_notifier_list,
CPUFREQ_POSTCHANGE, freqs);
if (likely(policy) && likely(policy->cpu == freqs->cpu))
policy->cur = freqs->new;
@@ -1014,7 +1013,7 @@ static int cpufreq_suspend(struct sys_de
freqs.old = cpu_policy->cur;
freqs.new = cur_freq;
- blocking_notifier_call_chain(&cpufreq_transition_notifier_list,
+ raw_notifier_call_chain(&cpufreq_transition_notifier_list,
CPUFREQ_SUSPENDCHANGE, &freqs);
adjust_jiffies(CPUFREQ_SUSPENDCHANGE, &freqs);
@@ -1095,7 +1094,7 @@ static int cpufreq_resume(struct sys_dev
freqs.old = cpu_policy->cur;
freqs.new = cur_freq;
- blocking_notifier_call_chain(
+ raw_notifier_call_chain(
&cpufreq_transition_notifier_list,
CPUFREQ_RESUMECHANGE, &freqs);
adjust_jiffies(CPUFREQ_RESUMECHANGE, &freqs);
@@ -1141,7 +1140,7 @@ int cpufreq_register_notifier(struct not
switch (list) {
case CPUFREQ_TRANSITION_NOTIFIER:
- ret = blocking_notifier_chain_register(
+ ret = raw_notifier_chain_register(
&cpufreq_transition_notifier_list, nb);
break;
case CPUFREQ_POLICY_NOTIFIER:
@@ -1173,7 +1172,7 @@ int cpufreq_unregister_notifier(struct n
switch (list) {
case CPUFREQ_TRANSITION_NOTIFIER:
- ret = blocking_notifier_chain_unregister(
+ ret = raw_notifier_chain_unregister(
&cpufreq_transition_notifier_list, nb);
break;
case CPUFREQ_POLICY_NOTIFIER:
^ permalink raw reply
* [PATCH 1/5] Updates for WRS SBC82xx boards
From: Paul Gortmaker @ 2006-05-25 18:22 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: p_gortmaker
patch1: sbc82xx-diff0
- replace NR_SIU_INTS with NR_CPM_INTS
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff -ur orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c
--- orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c 2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c 2006-02-07 16:22:28.000000000 -0500
@@ -74,7 +74,7 @@
{
unsigned long flags;
- irq_nr -= NR_SIU_INTS;
+ irq_nr -= NR_CPM_INTS;
spin_lock_irqsave(&sbc82xx_i8259_lock, flags);
sbc82xx_i8259_mask |= 1 << irq_nr;
@@ -88,7 +88,7 @@
{
unsigned long flags;
- irq_nr -= NR_SIU_INTS;
+ irq_nr -= NR_CPM_INTS;
spin_lock_irqsave(&sbc82xx_i8259_lock, flags);
sbc82xx_i8259_mask |= 1 << irq_nr;
@@ -100,7 +100,7 @@
{
unsigned long flags;
- irq_nr -= NR_SIU_INTS;
+ irq_nr -= NR_CPM_INTS;
spin_lock_irqsave(&sbc82xx_i8259_lock, flags);
sbc82xx_i8259_mask &= ~(1 << irq_nr);
@@ -142,7 +142,7 @@
return IRQ_HANDLED;
}
}
- __do_IRQ(NR_SIU_INTS + irq, regs);
+ __do_IRQ(NR_CPM_INTS + irq, regs);
return IRQ_HANDLED;
}
@@ -173,7 +173,7 @@
}
/* Set up the interrupt handlers for the i8259 IRQs */
- for (i = NR_SIU_INTS; i < NR_SIU_INTS + 8; i++) {
+ for (i = NR_CPM_INTS; i < NR_CPM_INTS + 8; i++) {
irq_desc[i].handler = &sbc82xx_i8259_ic;
irq_desc[i].status |= IRQ_LEVEL;
}
diff -ur orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h
--- orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h 2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h 2006-02-07 14:48:03.000000000 -0500
@@ -24,13 +24,14 @@
#define BOOTROM_RESTART_ADDR ((uint)0x40000104)
-#define SBC82xx_PC_IRQA (NR_SIU_INTS+0)
-#define SBC82xx_PC_IRQB (NR_SIU_INTS+1)
-#define SBC82xx_MPC185_IRQ (NR_SIU_INTS+2)
-#define SBC82xx_ATM_IRQ (NR_SIU_INTS+3)
-#define SBC82xx_PIRQA (NR_SIU_INTS+4)
-#define SBC82xx_PIRQB (NR_SIU_INTS+5)
-#define SBC82xx_PIRQC (NR_SIU_INTS+6)
-#define SBC82xx_PIRQD (NR_SIU_INTS+7)
+#define SBC82xx_PC_IRQA (NR_CPM_INTS+0)
+#define SBC82xx_PC_IRQB (NR_CPM_INTS+1)
+#define SBC82xx_MPC185_IRQ (NR_CPM_INTS+2)
+#define SBC82xx_ATM_IRQ (NR_CPM_INTS+3)
+
+#define SBC82xx_PIRQA (NR_CPM_INTS+4)
+#define SBC82xx_PIRQB (NR_CPM_INTS+5)
+#define SBC82xx_PIRQC (NR_CPM_INTS+6)
+#define SBC82xx_PIRQD (NR_CPM_INTS+7)
#endif /* __PPC_SBC82xx_H__ */
^ permalink raw reply
* [PATCH 2/5] Updates for WRS SBC82xx boards
From: Paul Gortmaker @ 2006-05-25 18:25 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: p_gortmaker
patch2: sbc82xx-PCI-diff1
- allow m82xx_pci.c to be used by other platforms that have
their own map_irq
I'm open to doing this another way if desired -- I just went for the
minimal impact on the existing code with this.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff -ur orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c
--- orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c 2006-02-09 16:20:35.000000000 -0500
+++ linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.c 2006-02-09 16:01:40.000000000 -0500
@@ -198,7 +198,7 @@
}
}
-static int sbc82xx_pci_map_irq(struct pci_dev *dev, unsigned char idsel,
+int pq2pci_map_irq(struct pci_dev *dev, unsigned char idsel,
unsigned char pin)
{
static char pci_irq_table[][4] = {
@@ -247,7 +247,7 @@
callback_init_IRQ = ppc_md.init_IRQ;
ppc_md.init_IRQ = sbc82xx_init_IRQ;
- ppc_md.pci_map_irq = sbc82xx_pci_map_irq;
+ ppc_md.pci_map_irq = pq2pci_map_irq;
#ifdef CONFIG_GEN_RTC
ppc_md.time_init = NULL;
ppc_md.get_rtc_time = NULL;
diff -ur orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h
--- orig/linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h 2006-02-09 16:20:35.000000000 -0500
+++ linux-2.6.16rc2/arch/ppc/platforms/sbc82xx.h 2006-02-09 16:35:05.000000000 -0500
@@ -24,6 +24,7 @@
#define BOOTROM_RESTART_ADDR ((uint)0x40000104)
+#define HAVE_OWN_PQ2PCI_IRQ
#define SBC82xx_PC_IRQA (NR_CPM_INTS+0)
#define SBC82xx_PC_IRQB (NR_CPM_INTS+1)
#define SBC82xx_MPC185_IRQ (NR_CPM_INTS+2)
diff -ur orig/linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c
--- orig/linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c 2006-01-02 22:21:10.000000000 -0500
+++ linux-2.6.16rc2/arch/ppc/syslib/m82xx_pci.c 2006-02-09 14:35:10.000000000 -0500
@@ -51,6 +51,10 @@
* Interrupt routing
*/
+#ifdef HAVE_OWN_PQ2PCI_IRQ
+extern int
+pq2pci_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin);
+#else
static inline int
pq2pci_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin)
{
@@ -172,6 +176,7 @@
setup_irq(PCI_INT_TO_SIU, &pq2pci_irqaction);
return;
}
+#endif /* HAVE_OWN_PQ2PCI_IRQ */
static int
pq2pci_exclude_device(u_char bus, u_char devfn)
^ permalink raw reply
* [PATCH 3/5] Updates for WRS SBC82xx boards
From: Paul Gortmaker @ 2006-05-25 18:26 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: p_gortmaker
patch3: sbc82xx-CONFIG.diff1
- add CONFIG_SBC82xx alongside CONFIG_PQ2FADS where required.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
--- linux-2.6.16_rc5/arch/ppc/syslib/m82xx_pci.c.orig 2006-02-27 14:55:41.000000000 -0500
+++ linux-2.6.16_rc5/arch/ppc/syslib/m82xx_pci.c 2006-02-27 15:02:01.000000000 -0500
@@ -238,7 +238,7 @@
SIUMCR_APPC10 | SIUMCR_CS10PC00 |
SIUMCR_BCTLC00 | SIUMCR_MMR11 ;
-#elif defined CONFIG_PQ2FADS
+#elif defined(CONFIG_PQ2FADS) || defined(CONFIG_SBC82xx)
/*
* Setting required to enable IRQ1-IRQ7 (SIUMCR [DPPC]),
* and local bus for PCI (SIUMCR [LBPC]).
@@ -292,7 +292,7 @@
#if defined CONFIG_ADS8272
/* PCI int highest prio */
immap->im_siu_conf.siu_82xx.sc_ppc_alrh = 0x01236745;
-#elif defined CONFIG_PQ2FADS
+#elif defined(CONFIG_PQ2FADS) || defined(CONFIG_SBC82xx)
immap->im_siu_conf.siu_82xx.sc_ppc_alrh = 0x03124567;
#endif
/* park bus on PCI */
@@ -380,7 +380,10 @@
IORESOURCE_IO | 1, "PCI I/O");
ppc_md.pci_exclude_device = pq2pci_exclude_device;
+
+#ifndef CONFIG_SBC82xx
hose->last_busno = pciauto_bus_scan(hose, hose->first_busno);
+#endif
ppc_md.pci_map_irq = pq2pci_map_irq;
ppc_md.pcibios_fixup = NULL;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox