* RE: Gianfar - MPC8541 - tx buffer overrun errors
From: Joyeau Sylvain @ 2007-09-06 8:43 UTC (permalink / raw)
To: Shriram Janardhan, linuxppc-embedded
Hi Shriram,
Try to increase the DEFAULT_TX_RING_SIZE parameter in gianfar.h.
Enabling NAPI mechanism should have no effect on transmission side.
Cheers
--
sj
________________________________
From:
linuxppc-embedded-bounces+sylvain.joyeau=3Dthomson.net@ozlabs.org
[mailto:linuxppc-embedded-bounces+sylvain.joyeau=3Dthomson.net@ozlabs.org=
]
On Behalf Of Shriram Janardhan
Sent: jeudi 6 septembre 2007 03:49
To: linuxppc-embedded@ozlabs.org
Subject: Gianfar - MPC8541 - tx buffer overrun errors
=09
=09
All,
=20
I am running 2.6.11 version of the kernel on MPC8541. Have one
of the TSECs configured at 100Mbps/Full Duplex. The TSEC MAC is
connected to a Marvell Ethernet switch MAC without any PHY in between.
MAC level flow control is enabled but no pause frames sent or received.
=20
I see a high number of transmit buffer overrun errors
(tx_fifo_empty errors in the gianfar driver). I don't have NAPI
enabled. In addition to other things, I was thinking of enabling NAPI
and see if it helps - is there any downside to it?? Are there any other
parameters that I could tweak to reduce/eliminate the overrun errors??
=20
Thanks,
Shriram.
=20
________________________________
Got a little couch potato?=20
Check out fun summer activities for kids.
<http://us.rd.yahoo.com/evt=3D48248/*http://search.yahoo.com/search?fr=3D=
oni
_on_mail&p=3Dsummer+activities+for+kids&cs=3Dbz>=20
^ permalink raw reply
* [PATCH update] Re: Sleep problems with kernels >= 2.6.21 on powerpc
From: Stefan Richter @ 2007-09-06 7:50 UTC (permalink / raw)
To: Andrew Morton
Cc: michal.k.k.piotrowski, rbrito, krh, linux-kernel, rjw,
linuxppc-dev, debian-powerpc, linux-pm, rael
In-Reply-To: <tkrat.29a16d2ec8698ff2@s5r6.in-berlin.de>
On 5 Sep, Stefan Richter wrote:
> On 5 Sep, Andrew Morton wrote:
>>> >>> Trying to free already-free IRQ 40
>>> >>> pci_set_power_state(): 0002:20:0e.0: state=3, current state=5
>>> >>> firewire_ohci: pci_set_power_state failed with -22<3>pci_device_suspend(): pci_suspend+0x0/0x9c [firewire_ohci]() returns -22
...
>> It's not clear _why_ pci_set_power_state() is failing.
>
> The only -22 error path in pci_set_power_state is this:
>
> /* Validate current state:
> * Can enter D0 from any state, but if we can only go deeper
> * to sleep if we're already in a low power state
> */
> if (state != PCI_D0 && dev->current_state > state) {
> printk(KERN_ERR "%s(): %s: state=%d, current state=%d\n",
> __FUNCTION__, pci_name(dev), state, dev->current_state);
> return -EINVAL;
> } [...else...]
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Subject: firewire: fw-ohci: ignore failure of pci_set_power_state (fix suspend regression)
Fixes (papers over) "Sleep problems with kernels >= 2.6.21 on powerpc",
http://lkml.org/lkml/2007/8/25/155. The issue is that the FireWire
controller's pci_dev.current_state of iBook G3 and presumably older
PowerBooks is still in PCI_UNKNOWN instead of PCI_D0 when the firewire
driver's .suspend method is called.
Like it was suggested earlier in http://lkml.org/lkml/2006/10/24/13, we
do not fail .suspend anymore if pci_set_power_state failed.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
Update:
- omit comment which will become outdated if the underlying problem is fixed
- log the error return value
- document the actual bug in the patch description
IMO the actual bug here (operating the controller while it is in
PCI_UNKNOWN state, which is surely a fault in the PPC platform code) is
something to be fixed post 2.6.23 release.
drivers/firewire/fw-ohci.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
Index: linux/drivers/firewire/fw-ohci.c
===================================================================
--- linux.orig/drivers/firewire/fw-ohci.c
+++ linux/drivers/firewire/fw-ohci.c
@@ -1973,10 +1973,8 @@ static int pci_suspend(struct pci_dev *p
return err;
}
err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
- if (err) {
- fw_error("pci_set_power_state failed\n");
- return err;
- }
+ if (err)
+ fw_error("pci_set_power_state failed with %d\n", err);
return 0;
}
--
Stefan Richter
-=====-=-=== =--= --==-
http://arcgraph.de/sr/
^ permalink raw reply
* Re: Problems enabling NTP on ELDK
From: Johan Borkhuis @ 2007-09-06 7:43 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20070905184827.26859247AF@gemini.denx.de>
Wolfgang Denk wrote:
> In message <46DE9322.7080901@dutchspace.nl> you wrote:
>
>> I tried enabling NTP on my embedded machine (using ELDK 4.1, ppc_85xx,
>> kernel version 2.6.14 with Xenomai 2.3.2). After I did that I noticed
>> that ksoftirqd/0 suddenly took almost all processor time (> 95%). What
>> is causing this? Is there a way around this, or is this something that
>> does not cause any problems?
>>
>
> You probably have some poroblems in your kernel port - check the RTC
> driver and related modules like I2C etc. Of course this depends on
> the NTP configuration you use, but the only kernel interaction I can
> think of that could cause this is if you interact with the RTC. [I
> guess that normal network traffic is working fine on your board.]
>
All other functions are working fine: no problem with network or other
PCI devices.
I disabled all RTC and I2C devices, and the problem disappeared. After
enabling all items one by one the cause of the problem seems to be the
DS1375 RTC: after I enable this and start NTPD ksoftirqd goes wild
again. I do not see any other special activity: no extra interrupts in
/proc/interrupts, and also no other RTC related errors or messages. Also
OpenPIC does not show any extra interrupts.
Is there a way to find out what interrupt is causing ksoftirqd to be
triggered?
> BTW: ELDK 4.1 comes with a 2.6.19.2 kernel - is there a special
> reason that you use such an obsoletel kernel tree?
>
I am using an MVME3100 board together with Xenomai. This board has
support for version 2.6.14-ppc and 2.6.20-ppc, while Xenomai/Adeos is
supported on 2.6.14 and 2.6.19. I did not yet find time to backport the
support to 2.6.19.
Kind regards,
Johan Borkhuis
^ permalink raw reply
* [PATCH] cmd_ctrl-callback is needed in plat_nand.c
From: Sergej Stepanov @ 2007-09-06 7:41 UTC (permalink / raw)
To: linuxppc-embedded, Vitaly Wool
To get our board (IDS8247) to work with the driver the cmd_ctrl-callback is needed (controlling ALE/CLE/nCE).
Sigend-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
---
diff -ruN linux-2.6.22.1-orig/drivers/mtd/nand/plat_nand.c linux-2.6.22.1_ids8247/drivers/mtd/nand/plat_nand.c
--- linux-2.6.22.1-orig/drivers/mtd/nand/plat_nand.c 2007-07-10 20:56:30.000000000 +0200
+++ linux-2.6.22.1_ids8247/drivers/mtd/nand/plat_nand.c 2007-08-02 10:54:34.000000000 +0200
@@ -66,7 +66,7 @@
data->chip.ecc.hwctl = pdata->ctrl.hwcontrol;
data->chip.ecc.layout = pdata->chip.ecclayout;
data->chip.ecc.mode = NAND_ECC_SOFT;
+ data->chip.cmd_ctrl = pdata->ctrl.cmd_ctrl;
platform_set_drvdata(pdev, data);
/* Scan to find existance of the device */
^ permalink raw reply
* Re: The question about the relocate_code on u-boot for MPC8360?
From: Paul Gortmaker @ 2007-09-06 3:12 UTC (permalink / raw)
To: 郭劲; +Cc: linuxppc-embedded
In-Reply-To: <388526407.00819@tsinghua.org.cn>
T24gOC8zMC8wNywgufm+oiA8Z3VvamluMDJAdHNpbmdodWEub3JnLmNuPiB3cm90ZToKPgo+IEhp
LCBGcmllbmRzLAo+Cj4KPiBJIGFtIGRlYnVnaW5nIHRoZSB1LWJvb3Qgb24gZnJlZXNjYWxlIE1Q
QzgzNjAsIHRoZSB2ZXJzaW9uIG9mIHUtYm9vdCBpcyAxLjIuMCwgdGhlCj4gY29kZSBvbiBmbGFz
aCBpcyBPSyxidXQgdGhlIGNvZGUgZnJvbSBGTEFTSCB0byBERFIgaXMgYnJva2VuLCB0aGF0IGlz
LCBhZnRlciB0aGUKPiByZWxvY2F0ZV9jb2RlIGZ1bmN0aW9uLCB0aGUgdS1ib290IHN0YXJ0IGFn
YWluLiBJIHRlc3RlZCB0aGUgRERSIG9uIHUtYm9vdCwgaXQncwo+IE9LLiBJIHdhcyB3b25kZXJp
bmcgdGhhdCBob3QgdG8gZGVhbCB3aXRoIHRoaXMgcHJvYmxlbT8gZm9sbG93IGlzIHRoZSBDT00g
b3V0cHV0Cj4gZnJvbSB1LWJvb3QuIFRoYW5rcy4KPgoKSSB0aGluayB5b3Ugd2lsbCBmaW5kIHRo
YXQgdGhlIGRlZmF1bHQgMS4yLjAgdHJlZSBkb2VzIG5vdCBjb250YWluIHRoZQpzdXBwb3J0IGZv
ciBuZXdlciA4MzYwTURTIGJvYXJkcyB3aXRoIHRoZSByZXYyIENQVSBhbmQgdGhlIEREUjIuClRo
ZXJlIHdlcmUgZ2l0IGNvbW1pdHMgcG9zdCAxLjIuMCB0aGF0IGFkZGVkIHN1cHBvcnQgZm9yIHRo
ZXNlIC0tIGZvcgpleGFtcGxlOgoKICAgICAgICBGaXggdHdvIGJ1Z3MgZm9yIE1QQzgzeHggRERS
MiBjb250cm9sbGVyIFNQRCBJbml0CiAgICAgICAgY29tbWl0IDZmYmYyNjFmOGRmMjk0ZTU4OWNm
YWRlYmViZTU0NjhlM2MwZjI5ZTkKCiAgICAgICAgbXBjODN4eDogQWRkIEREUjIgY29udHJvbGxl
ciBmaXhlZC9TUEQgSW5pdCBmb3IgTVBDODN4eAogICAgICAgIGNvbW1pdCBkNjE4NTNjZjI0NzJl
MGI4YmNiZDEzMTQ2MWE5M2QxYzQ5ZmYwYzFmCgpUaGVyZSB3ZXJlIGFsc28gc29tZSBERFIyIHJl
bGF0ZWQgY2hhbmdlcyB0aGF0IGNhbWUgaW4gd2l0aCB0aGUKbXBjODMyeE1EUyBwYXRjaGVzLgoK
UGF1bC4KCgoKCj4KPgo+Cj4KPgo+Cj4gVS1Cb290IDEuMi4wIChBdWcgMjkgMjAwNyAtIDIwOjUw
OjM3KSBNUEM4M1hYCj4KPiBDbG9jayBjb25maWd1cmF0aW9uOgo+ICAgQ29oZXJlbnQgU3lzdGVt
IEJ1czogIDI2NCBNSHoKPiAgIENvcmU6ICAgICAgICAgICAgICAgICA1MjggTUh6Cj4gICBRRTog
ICAgICAgICAgICAgICAgICAgMTk4IE1Iego+ICAgTG9jYWwgQnVzIENvbnRyb2xsZXI6IDI2NCBN
SHoKPiAgIExvY2FsIEJ1czogICAgICAgICAgICAgNjYgTUh6Cj4gICBERFI6ICAgICAgICAgICAg
ICAgICAgMjY0IE1Iego+ICAgRERSIFNlY29uZGFyeTogICAgICAgIDI2NCBNSHoKPiAgIFNFQzog
ICAgICAgICAgICAgICAgICAgODggTUh6Cj4gICBJMkMxOiAgICAgICAgICAgICAgICAgMjY0IE1I
ego+ICAgSTJDMjogICAgICAgICAgICAgICAgIDI2NCBNSHoKPiBDUFU6IFJldjogVW5rbm93biBn
dW9qaW5nIG1vZGlmaWVkIHNvdXJjZSBjb2RlCj4gUmV2OiAyMCBhdCA1MjggTUh6Cj4gQm9hcmQ6
IEZyZWVzY2FsZSBNUEM4MzYwRU1EUwo+IEkyQzogICByZWFkeQo+IERSQU06Cj4gICAgU0RSQU0g
b24gTG9jYWwgQnVzOiA2NCBNQgo+ICAgIEREUiBSQU06IDI1NiBNQgo+IEREUiB0ZXN0IHBoYXNl
IDE6Cj4gRERSIHRlc3QgcGhhc2UgMjoKPiBERFIgdGVzdCBwYXNzZWQuCj4gaW5pdF9zZXF1ZW5j
ZSBmaW5pc2hlZAo+IGJlZ2luIHNldCB1cCBhIG5ldyBzdGFjawo+IGJlZ2lubmluZyBtZW1jcHkK
PiBlbmRlZCBtZW1jcHksYmVnaW5uaW5nIHJlbG9jYXRlX2NvZGUKPgo+Cj4gVS1Cb290IDEuMi4w
IChBdWcgMjkgMjAwNyAtIDIwOjUwOjM3KSBNUEM4M1hYCj4KPiBDbG9jayBjb25maWd1cmF0aW9u
Ogo+ICAgQ29oZXJlbnQgU3lzdGVtIEJ1czogIDI2NCBNSHoKPiAgIENvcmU6ICAgICAgICAgICAg
ICAgICA1MjggTUh6Cj4gICBRRTogICAgICAgICAgICAgICAgICAgMTk4IE1Iego+ICAgTG9jYWwg
QnVzIENvbnRyb2xsZXI6IDI2NCBNSHoKPiAgIExvY2FsIEJ1czogICAgICAgICAgICAgNjYgTUh6
Cj4gICBERFI6ICAgICAgICAgICAgICAgICAgMjY0IE1Iego+ICAgRERSIFNlY29uZGFyeTogICAg
ICAgIDI2NCBNSHoKPiAgIFNFQzogICAgICAgICAgICAgICAgICAgODggTUh6Cj4gICBJMkMxOiAg
ICAgICAgICAgICAgICAgMjY0IE1Iego+ICAgSTJDMjogICAgICAgICAgICAgICAgIDI2NCBNSHoK
PiBDUFU6IFJldjogVW5rbm93biBndW9qaW5nIG1vZGlmaWVkIHNvdXJjZSBjb2RlCj4gUmV2OiAy
MCBhdCA1MjggTUh6Cj4gQm9hcmQ6IEZyZWVzY2FsZSBNUEM4MzYwRU1EUwo+IEkyQzogICByZWFk
eQo+IERSQU06Cj4gICAgU0RSQU0gb24gTG9jYWwgQnVzOiA2NCBNQgo+ICAgIEREUiBSQU06IDI1
NiBNQgo+IEREUiB0ZXN0IHBoYXNlIDE6Cj4gRERSIHRlc3QgcGhhc2UgMjoKPiBERFIgdGVzdCBw
YXNzZWQuCj4gaW5pdF9zZXF1ZW5jZSBmaW5pc2hlZAo+IGJlZ2luIHNldCB1cCBhIG5ldyBzdGFj
awo+IGJlZ2lubmluZyBtZW1jcHkKPiBlbmRlZCBtZW1jcHksYmVnaW5uaW5nIHJlbG9jYXRlX2Nv
ZGUKPgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K
PiBMaW51eHBwYy1lbWJlZGRlZCBtYWlsaW5nIGxpc3QKPiBMaW51eHBwYy1lbWJlZGRlZEBvemxh
YnMub3JnCj4gaHR0cHM6Ly9vemxhYnMub3JnL21haWxtYW4vbGlzdGluZm8vbGludXhwcGMtZW1i
ZWRkZWQKPgo=
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Scott Wood @ 2007-09-06 3:11 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <63F66EED-7808-40A3-B63D-AA53664CB1A0@embeddedalley.com>
On Wed, Sep 05, 2007 at 03:27:31PM -0700, Dan Malek wrote:
> On Sep 5, 2007, at 1:59 PM, Scott Wood wrote:
>
> >BTW, it seems I misremembered what the conflict was -- it's not with
> >ioremap space, but with the default location of the consistent memory
> >pool (at 0xff100000).
>
> Change the configuration option to move this somewhere
> else, outside of the wired mapping.
Sure, that'd work too -- though then I'd either have to change the
default for all platforms and hope I didn't break any of them, or have
8xx be different for what might amount to be no reason.
Would any platforms have a problem with setting the default to
0xfd000000? Anything over 0xfe000000 is particularly likely to conflict
with something.
> As I said in the last message, these lower end processors are very
> resource challenged, and we need to clever about the memory mapping and
> use of the TLBs. This isn't a place to be creating fancy memory maps
> and algorithms to manage them.
Actually, being slightly fancier by dynamically choosing where to place
the consistent memory pool would have avoided this issue.
I agree that not using a pinned TLB entry for the IMMR sucks, and maybe
I'll do something about it later -- just not right now. This patchset's
been floating for long enough without expanding its scope further.
> Use maximum mappings whenever possible, configure the memory controller
> to pack as much stuff into this single TLB mapping as possible.
> Something configurable like this memory pool should not be a reason to
> give up these performance enhancements.
Sure. I still don't think it's that big of a deal when none of the
currently supported boards have anything useful in the 8MB after the
IMMR (and pinning is only used for the debug console anyway), and custom
boards can always use custom TLB mappings, but moving the coherent region
to somewhere a little more polite is something that we should do anyway.
-Scott
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Scott Wood @ 2007-09-06 3:01 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <04819433-30F0-4789-864D-57B474485E32@embeddedalley.com>
On Wed, Sep 05, 2007 at 03:42:03PM -0700, Dan Malek wrote:
> On Sep 5, 2007, at 3:23 PM, Scott Wood wrote:
>
> >The IMMRs I've seen from the bootloader are ff000000 (Freescale
> >boards)
> >and fa200000 (Embedded Planet). AFAICT, the number of fixed TLB
> >entries
> >is fixed at 4 on these chips, so using the fourth for flash
> >wouldn't take
> >away any general-purpose TLB entries.
>
> On these same boards, the memory controllers are usually
> configured to put the flash somewhere in that space as well.
Not on any of the boards I've worked with.
> >I certainly agree that it would be nice to check -- my immediate goal
> >is to get things working, though.
>
> It's more than nice. If you want this to work correctly and also get
> the performance enhancement, it needs to be done.
And my point was that getting that performance enhancement is "nice".
It's not there now. If you want to submit a patch to add it, go right
ahead, but it's not really related to this patch.
-Scott
^ permalink raw reply
* RE: Keep On Debugging You
From: Zhang Wei-r63237 @ 2007-09-06 2:59 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <46DE1A36.3010300@tabi.org>
Oops!
Could you give us a live show version? :D =20
Cheers!
- zw
> -----Original Message-----
> From: linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.or
> g] On Behalf Of Timur Tabi
> Sent: Wednesday, September 05, 2007 10:54 AM
> To: linuxppc-dev@ozlabs.org
> Subject: Keep On Debugging You
>=20
> I wrote this last year in frustration with an out-of-order=20
> execution bug=20
> I was trying to fix.
>=20
>=20
> Keep On Debugging You
> Sung to the tune of REO Speedwagon's "Keep on Loving' You"
>=20
> You should've seen by the opcodes in the queue, baby
> There was something missin'
> You should known by the registers, too, maybe
> But you were too busy bitchin'
> You stalled ahead
> But you never fed
> Instead my instructions
> All ended up switchin'
>=20
> And though I know all flushes
> Still I don't remember
> Cause it was stwu way before lwzu
> And they're still together
> And I meant every line I wrote
> When I wrote them in order I meant
> That I wanted them in order
>=20
> And I'm gonna keep on debugging you
> Cause it's the only thing I'm paid to do
> I don't have time to sleep
> I just want to keep on debugging you
>=20
> (solo)
>=20
> And I meant every line I wrote
> When I wrote them in order I meant
> That I wanted them in order
>=20
> (chorus)
>=20
>=20
> --=20
> Timur Tabi
>=20
^ permalink raw reply
* Gianfar - MPC8541 - tx buffer overrun errors
From: Shriram Janardhan @ 2007-09-06 1:48 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
All,
I am running 2.6.11 version of the kernel on MPC8541. Have one of the TSECs configured at 100Mbps/Full Duplex. The TSEC MAC is connected to a Marvell Ethernet switch MAC without any PHY in between. MAC level flow control is enabled but no pause frames sent or received.
I see a high number of transmit buffer overrun errors (tx_fifo_empty errors in the gianfar driver). I don't have NAPI enabled. In addition to other things, I was thinking of enabling NAPI and see if it helps - is there any downside to it?? Are there any other parameters that I could tweak to reduce/eliminate the overrun errors??
Thanks,
Shriram.
---------------------------------
Got a little couch potato?
Check out fun summer activities for kids.
[-- Attachment #2: Type: text/html, Size: 1026 bytes --]
^ permalink raw reply
* Re: [PATCH] PowerPC: Add 64-bit resources support to pci_iomap
From: David Gibson @ 2007-09-06 1:27 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070905173016.GA27771@ru.mvista.com>
On Wed, Sep 05, 2007 at 09:30:16PM +0400, Valentine Barshak wrote:
> The patch adds support for the 64-bit resources to the PCI
> iomap code.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* use of asm/prom.h
From: Stephen Rothwell @ 2007-09-05 23:39 UTC (permalink / raw)
To: LKML; +Cc: sparclinux, ppc-dev, Helt, Krzysztof
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
Hi all,
I noticed in the ALSA tree:
------------------------------ sound/sparc/dbri.c ------------------------------
index 12d11fc..e96023f 100644
@@ -66,6 +66,7 @@
#include <sound/control.h>
#include <sound/initval.h>
+#include <asm/prom.h>
#include <asm/sbus.h>
#include <asm/atomic.h>
(I don't mean to pick on this particular example, it is just what was in
front of me.)
Could people please consider using linux/{of,of_device,of_platform}.h
instead of asm/prom.h now that these exist. Using asm/prom.h only works
now because it includes the above files, but that may (will?) change
eventually.
Most includes of asm/prom.h are there to get access to the routines and
data structures associated with the Open Firmware device tree, and these
are now all available from the above files instead.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Xilinx FX60
From: Grant Likely @ 2007-09-05 22:55 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY138-F27BF81B9795BD26A16564BB2CB0@phx.gbl>
On 9/5/07, Ming Liu <eemingliu@hotmail.com> wrote:
>
> > > Is it then possible to run two independent kernels, one on each PPC??
> >
> >Absolutely.
>
> Are you meaning two entirely seperate systems, or two ones which share a
> common HW such as memory space? Is that possible without any memory
> confliction?
You can share physical memory as long as each processor is dedicated
to separate regions. However, Linux on power expects memory to be
based at 0. Therefore you need to tweak the memory design so that the
second processor sees a different area of the ram based at zero.
You can even setup a shared memory region between the two processors,
but you that region should be cache-inhibited.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Dan Malek @ 2007-09-05 22:42 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905222310.GA11433@ld0162-tx32.am.freescale.net>
On Sep 5, 2007, at 3:23 PM, Scott Wood wrote:
> The IMMRs I've seen from the bootloader are ff000000 (Freescale
> boards)
> and fa200000 (Embedded Planet). AFAICT, the number of fixed TLB
> entries
> is fixed at 4 on these chips, so using the fourth for flash
> wouldn't take
> away any general-purpose TLB entries.
On these same boards, the memory controllers are usually
configured to put the flash somewhere in that space as well.
This is useful for flash file system performance. If you don't
need that, you can allocate the space differently. The point is
cover as much as you can with the IMMR entry and beyond.
Some people like to map external devices out there.
The 8xx variants have different TLB configurations.
You can't assume anything here. Some parts don't have
enough TLBs to make pinning useful, some allow hardware
wiring of only 2. When using hardware wiring, it's always
the upper entries that are wired. Since the number of
entries varies, you can't assume which TLB index
will be wired.
> I certainly agree that it would be nice to check -- my immediate
> goal is
> to get things working, though.
It's more than nice. If you want this to work correctly
and also get the performance enhancement, it needs
to be done.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Dan Malek @ 2007-09-05 22:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905205951.GA1047@ld0162-tx32.am.freescale.net>
On Sep 5, 2007, at 1:59 PM, Scott Wood wrote:
> BTW, it seems I misremembered what the conflict was -- it's not with
> ioremap space, but with the default location of the consistent memory
> pool (at 0xff100000).
Change the configuration option to move this somewhere
else, outside of the wired mapping.
As I said in the last message, these lower end processors
are very resource challenged, and we need to clever
about the memory mapping and use of the TLBs. This
isn't a place to be creating fancy memory maps and
algorithms to manage them. Use maximum mappings
whenever possible, configure the memory controller
to pack as much stuff into this single TLB mapping
as possible. Something configurable like this memory
pool should not be a reason to give up these performance
enhancements.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Scott Wood @ 2007-09-05 22:23 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <CF1B6B97-44FA-4002-9030-3C1A20F2F2F4@embeddedalley.com>
On Wed, Sep 05, 2007 at 03:08:28PM -0700, Dan Malek wrote:
> All of this worked in 2.4, many changes were part
> of the evolution in 2.6... configurable pinned entries,
> large page sizes, variations, I didn't keep track of
> all of this. I just assumed I'd have to fix it all if I
> ever needed to use it, which I haven't. The original
> version of 8xx could wire exactly three entries for
> 8M text, 8M data, and 8M IMMR plus upper device
> addresses. We would set the IMMR to ff800000,
> cover the CPM, some other devices and the flash
> at the top of memory.
The IMMRs I've seen from the bootloader are ff000000 (Freescale boards)
and fa200000 (Embedded Planet). AFAICT, the number of fixed TLB entries
is fixed at 4 on these chips, so using the fourth for flash wouldn't take
away any general-purpose TLB entries.
> >I didn't change it on a whim, I changed it because ioremap() wasn't
> >working the way it currently is.
>
> This processor is severely resource limited. It's
> far better to fix ioremap and take advantage of this
> performance enhancement than to further
> cripple it. Just like other processors test for
> mapping by BATs or CAMs, the 8xx and
> probably 4xx should test for wired mapping.
I certainly agree that it would be nice to check -- my immediate goal is
to get things working, though.
-Scott
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Dan Malek @ 2007-09-05 22:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905205301.GA807@ld0162-tx32.am.freescale.net>
On Sep 5, 2007, at 1:53 PM, Scott Wood wrote:
> Where is the code that checks for pinned TLB entries on 8xx when doing
> ioremap?
I don't know. I haven't been the maintainer for the 2.6
changes.
> Why could this not be done with a 512K mapping? How was this
> even tested, given the obvious wrong-register mistake in the other
> CONFIG_PIN_TLB section? On what do you base the assumption that
> flash is
> within 8MB of the IMMR base?
All of this worked in 2.4, many changes were part
of the evolution in 2.6... configurable pinned entries,
large page sizes, variations, I didn't keep track of
all of this. I just assumed I'd have to fix it all if I
ever needed to use it, which I haven't. The original
version of 8xx could wire exactly three entries for
8M text, 8M data, and 8M IMMR plus upper device
addresses. We would set the IMMR to ff800000,
cover the CPM, some other devices and the flash
at the top of memory. If you have too much flash, this
had to be adjusted accordingly, but for small systems
this was a nice performance enhancement.
> I didn't change it on a whim, I changed it because ioremap() wasn't
> working the way it currently is.
This processor is severely resource limited. It's
far better to fix ioremap and take advantage of this
performance enhancement than to further
cripple it. Just like other processors test for
mapping by BATs or CAMs, the 8xx and
probably 4xx should test for wired mapping.
Unfortunately, lots of things got messed up on 2.6
for the 8xx. I was not in the loop to approve changes,
and most of my advice was ignored. :-)
Thanks.
-- Dan
^ permalink raw reply
* Re: Xilinx FX60
From: Sergey Temerkhanov @ 2007-09-05 22:05 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAY138-F2634DB70ACDB83FA7430FEB2CB0@phx.gbl>
On Thursday 06 September 2007 00:40:33 Ming Liu wrote:
> >It won't. There is no hardware cache coherency on Virtex.
>
> Is that possible if we turn off the cache?
Not in current versions. Implementation of SMP will require implementing
functions from struct smp_ops_t (defined in include/asm-ppc/machdep.h) and
some additional work. Maybe PIC redesign/modification will be needed. And
after all there will be significant performance hit with caches disabled.
^ permalink raw reply
* [PATCH 4/3] Make swsusp_32.S usable for suspend-to-RAM.
From: Scott Wood @ 2007-09-05 22:08 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905220438.GA11283@ld0162-tx32.am.freescale.net>
This allows platform suspend code to re-use the generic state saving
code, passing a pointer to the low-level suspend code.
The resume path is modified so that non-hibernate callers skip
hibernate-specific bits, and so that callers can specify that the MMU is
off (and thus BATs should be restored).
The _GLOBAL around swsusp_save_area is changed to .global, as the former
puts the data in the text section, which causes an oops with page
debugging enabled.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
Sorry, this one got left out of the previous PM patchset.
arch/powerpc/Kconfig | 11 +++++++
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/swsusp_32.S | 60 ++++++++++++++++++++++----------------
3 files changed, 47 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 00099ef..b8c6fa2 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -123,6 +123,17 @@ config DEFAULT_UIMAGE
Used to allow a board to specify it wants a uImage built by default
default n
+config PPC32_SUSPEND
+ bool
+ depends on PPC32
+ default n
+
+config PPC32_SWSUSP
+ bool
+ depends on PPC32 && HIBERNATION
+ select PPC32_SUSPEND
+ default y
+
config PPC64_SWSUSP
bool
depends on PPC64 && (BROKEN || (PPC_PMAC64 && EXPERIMENTAL))
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 967afc5..d95b09f 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -38,7 +38,7 @@ obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o
obj-$(CONFIG_TAU) += tau_6xx.o
obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o
-obj32-$(CONFIG_HIBERNATION) += swsusp_32.o
+obj32-$(CONFIG_PPC32_SUSPEND) += swsusp_32.o
obj64-$(CONFIG_HIBERNATION) += swsusp_64.o swsusp_asm64.o
obj32-$(CONFIG_MODULES) += module_32.o
diff --git a/arch/powerpc/kernel/swsusp_32.S b/arch/powerpc/kernel/swsusp_32.S
index 69e8f86..ed1c95b 100644
--- a/arch/powerpc/kernel/swsusp_32.S
+++ b/arch/powerpc/kernel/swsusp_32.S
@@ -33,15 +33,21 @@
.section .data
.align 5
-_GLOBAL(swsusp_save_area)
+ .global swsusp_save_area
+swsusp_save_area:
.space SL_SIZE
.section .text
.align 5
+#ifdef CONFIG_SOFTWARE_SUSPEND
_GLOBAL(swsusp_arch_suspend)
+ lis r3, swsusp_save@h
+ ori r3, r3, swsusp_save@l
+#endif
+_GLOBAL(do_suspend)
lis r11,swsusp_save_area@h
ori r11,r11,swsusp_save_area@l
@@ -64,8 +70,8 @@ _GLOBAL(swsusp_arch_suspend)
stw r4,SL_TB(r11)
mftb r5
stw r5,SL_TB+4(r11)
- mftbu r3
- cmpw r3,r4
+ mftbu r6
+ cmpw r6,r4
bne 1b
/* Save SPRGs */
@@ -119,7 +125,8 @@ _GLOBAL(swsusp_arch_suspend)
/* Call the low level suspend stuff (we should probably have made
* a stackframe...
*/
- bl swsusp_save
+ mtctr r3
+ bctrl
/* Restore LR from the save area */
lis r11,swsusp_save_area@h
@@ -129,7 +136,7 @@ _GLOBAL(swsusp_arch_suspend)
blr
-
+#ifdef CONFIG_SOFTWARE_SUSPEND
/* Resume code */
_GLOBAL(swsusp_arch_resume)
@@ -212,6 +219,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
bdnz 1b
sync
+ li r3, 0
+#endif
+
+ /* r3 = nonzero if the MMU is completely disabled and
+ * BATs may be restored, zero otherwise.
+ */
+_GLOBAL(do_resume)
/* Ok, we are now running with the kernel data of the old
* kernel fully restored. We can get to the save area
* easily now. As for the rest of the code, it assumes the
@@ -226,10 +240,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
bl __restore_cpu_setup
#endif
/* Restore the BATs, and SDR1. Then we can turn on the MMU.
- * This is a bit hairy as we are running out of those BATs,
- * but first, our code is probably in the icache, and we are
- * writing the same value to the BAT, so that should be fine,
- * though a better solution will have to be found long-term
+ * This can only be done when r3 != 0 (and thus the MMU is
+ * off).
*/
lwz r4,SL_SDR1(r11)
mtsdr1 r4
@@ -242,7 +254,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
lwz r4,SL_SPRG0+12(r11)
mtsprg 3,r4
-#if 0
+ cmpw r3, 0
+ beq 1f
+
lwz r4,SL_DBAT0(r11)
mtdbatu 0,r4
lwz r4,SL_DBAT0+4(r11)
@@ -275,8 +289,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
mtibatu 3,r4
lwz r4,SL_IBAT3+4(r11)
mtibatl 3,r4
-#endif
+1:
BEGIN_FTR_SECTION
li r4,0
mtspr SPRN_DBAT4U,r4
@@ -306,8 +320,16 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_HIGH_BATS)
/* restore the MSR and turn on the MMU */
lwz r3,SL_MSR(r11)
- bl turn_on_mmu
- tovirt(r11,r11)
+ lis r4, 1f@h
+ ori r4, r4, 1f@l
+
+ mtsrr0 r4
+ mtsrr1 r3
+ sync
+ isync
+ rfi
+
+1: tovirt(r11, r11)
/* Restore TB */
li r3,0
@@ -334,15 +356,3 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_HIGH_BATS)
li r3,0
blr
-
-/* FIXME:This construct is actually not useful since we don't shut
- * down the instruction MMU, we could just flip back MSR-DR on.
- */
-turn_on_mmu:
- mflr r4
- mtsrr0 r4
- mtsrr1 r3
- sync
- isync
- rfi
-
--
1.5.3
^ permalink raw reply related
* [PATCH 3/3] Add 6xx-style HID0_SLEEP support.
From: Scott Wood @ 2007-09-05 22:06 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905220438.GA11283@ld0162-tx32.am.freescale.net>
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/sysdev/6xx-suspend.S | 52 +++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/Makefile | 4 +++
include/asm-powerpc/mpc6xx.h | 6 ++++
3 files changed, 62 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/6xx-suspend.S
create mode 100644 include/asm-powerpc/mpc6xx.h
diff --git a/arch/powerpc/sysdev/6xx-suspend.S b/arch/powerpc/sysdev/6xx-suspend.S
new file mode 100644
index 0000000..976ee07
--- /dev/null
+++ b/arch/powerpc/sysdev/6xx-suspend.S
@@ -0,0 +1,52 @@
+/*
+ * Enter and leave sleep state on chips with 6xx-style HID0
+ * power management bits.
+ *
+ * Author: Scott Wood <scottwood@freescale.com>
+ *
+ * Copyright (c) 2006-2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include <asm/ppc_asm.h>
+#include <asm/reg.h>
+#include <asm/thread_info.h>
+#include <asm/asm-offsets.h>
+
+_GLOBAL(mpc6xx_enter_sleep)
+ mflr r4
+
+ mfspr r5, SPRN_HID0
+ rlwinm r5, r5, 0, ~(HID0_DOZE | HID0_NAP)
+ oris r5, r5, HID0_SLEEP@h
+ mtspr SPRN_HID0, r5
+ isync
+
+ lis r5, ret_from_sleep@h
+ ori r5, r5, ret_from_sleep@l
+ mtlr r5
+
+ rlwinm r5, r1, 0, 0, 31-THREAD_SHIFT
+ lwz r6, TI_LOCAL_FLAGS(r5)
+ ori r6, r6, _TLF_NAPPING
+ stw r6, TI_LOCAL_FLAGS(r5)
+
+ mfmsr r5
+ ori r5, r5, MSR_EE
+ oris r5, r5, MSR_POW@h
+ sync
+ mtmsr r5
+ isync
+
+1: b 1b
+
+ret_from_sleep:
+ mfspr r5, SPRN_HID0
+ rlwinm r5, r5, 0, ~HID0_SLEEP
+ mtspr SPRN_HID0, r5
+
+ mtlr r4
+ blr
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 08ce31e..84a0800 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -38,3 +38,7 @@ obj-$(CONFIG_CPM2) += cpm2_common.o cpm2_pic.o
obj-$(CONFIG_8xx) += mpc8xx_pic.o commproc.o
obj-$(CONFIG_UCODE_PATCH) += micropatch.o
endif
+
+ifeq ($(CONFIG_SUSPEND),y)
+obj-$(CONFIG_6xx) += 6xx-suspend.o
+endif
diff --git a/include/asm-powerpc/mpc6xx.h b/include/asm-powerpc/mpc6xx.h
new file mode 100644
index 0000000..01a33ed
--- /dev/null
+++ b/include/asm-powerpc/mpc6xx.h
@@ -0,0 +1,6 @@
+#ifndef __ASM_POWERPC_MPC6xx_H
+#define __ASM_POWERPC_MPC6xx_H
+
+void mpc6xx_enter_sleep(void);
+
+#endif
--
1.5.3
^ permalink raw reply related
* [PATCH 2/3] pm: Handle HID0_SLEEP in the TLF_NAPPING hack.
From: Scott Wood @ 2007-09-05 22:06 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905220438.GA11283@ld0162-tx32.am.freescale.net>
The e300 core (and probably most other 6xx chips) can only come out of
sleep mode with an interrupt. However, interrupts are logically disabled
by the power management layer.
This hack extends the existing doze/nap hack to also suppress the running
of the interrupt handler when in sleep mode.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/idle_6xx.S | 40 +++++++++++++++++++++++++++++++++++++---
1 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S
index 01bcd52..d176042 100644
--- a/arch/powerpc/kernel/idle_6xx.S
+++ b/arch/powerpc/kernel/idle_6xx.S
@@ -147,6 +147,12 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
isync
b 1b
+#ifdef CONFIG_SUSPEND
+ret_from_sleep:
+ .long ret_from_except
+ .long ret_from_except
+#endif
+
/*
* Return from NAP/DOZE mode, restore some CPU specific registers,
* we are called with DR/IR still off and r2 containing physical
@@ -154,7 +160,33 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
* address). We have to preserve r10.
*/
_GLOBAL(power_save_6xx_restore)
- lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */
+#ifdef CONFIG_SUSPEND
+ mfspr r8, SPRN_HID0
+ andis. r9, r8, HID0_SLEEP@h
+ beq+ 1f
+
+ /*
+ * SLEEP mode is invoked through the PM subsystem, which means
+ * that interrupts should be disabled. However, the hardware
+ * requires them to be enabled to wake up. To prevent the
+ * interrupt from being visible to Linux, return immediately
+ * rather than run the interrupt handler.
+ */
+ lis r9, ret_from_sleep@h
+ ori r9, r9, ret_from_sleep@l
+ tophys(r9, r9)
+ mtlr r9
+
+ /*
+ * Disable interrupts, so that the interrupt doesn't happen
+ * again until the PM code sets MSR[EE].
+ */
+ lwz r9, _MSR(r11)
+ rlwinm r9, r9, 0, ~MSR_EE
+ stw r9, _MSR(r11)
+#endif
+
+1: lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */
stw r9,_NIP(r11) /* make it do a blr */
#ifdef CONFIG_SMP
@@ -168,8 +200,10 @@ _GLOBAL(power_save_6xx_restore)
* and load r11 (@ha part + CPU offset) only once
*/
BEGIN_FTR_SECTION
- mfspr r9,SPRN_HID0
- andis. r9,r9,HID0_NAP@h
+#ifndef CONFIG_SUSPEND
+ mfspr r8,SPRN_HID0
+#endif
+ andis. r9,r8,HID0_NAP@h
beq 1f
addis r9,r11,(nap_save_msscr0-KERNELBASE)@ha
lwz r9,nap_save_msscr0@l(r9)
--
1.5.3
^ permalink raw reply related
* [PATCH 1/3] Implement arch disable/enable irq hooks.
From: Scott Wood @ 2007-09-05 22:06 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
These hooks ensure that a decrementer interrupt is not pending when
suspending; otherwise, problems may occur. For example, with deep sleep
on the 831x, a pending decrementer will cause a system freeze because the
SoC thinks the decrementer interrupt would have woken the system, but the
core must have interrupts disabled due to the setup required for deep
sleep.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/time.c | 41 +++++++++++++++++++++++++++++++++++++++++
include/asm-powerpc/machdep.h | 13 +++++++++++++
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index b5944d8..bf7c4d3 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -728,6 +728,47 @@ void wakeup_decrementer(void)
set_dec(ticks);
}
+#ifdef CONFIG_SUSPEND
+void generic_suspend_disable_irqs(void)
+{
+ preempt_disable();
+
+ /* Disable the decrementer, so that it doesn't interfere
+ * with suspending.
+ */
+
+ set_dec(0x7fffffff);
+ local_irq_disable();
+ set_dec(0x7fffffff);
+}
+
+void generic_suspend_enable_irqs(void)
+{
+ wakeup_decrementer();
+
+ local_irq_enable();
+ preempt_enable();
+}
+
+/* Overrides the weak version in kernel/power/main.c */
+void arch_suspend_disable_irqs(void)
+{
+ if (ppc_md.suspend_disable_irqs)
+ ppc_md.suspend_disable_irqs();
+ else
+ generic_suspend_disable_irqs();
+}
+
+/* Overrides the weak version in kernel/power/main.c */
+void arch_suspend_enable_irqs(void)
+{
+ if (ppc_md.suspend_enable_irqs)
+ ppc_md.suspend_enable_irqs();
+ else
+ generic_suspend_enable_irqs();
+}
+#endif
+
#ifdef CONFIG_SMP
void __init smp_space_timers(unsigned int max_cpus)
{
diff --git a/include/asm-powerpc/machdep.h b/include/asm-powerpc/machdep.h
index 71c6e7e..7d6d2cb 100644
--- a/include/asm-powerpc/machdep.h
+++ b/include/asm-powerpc/machdep.h
@@ -253,6 +253,16 @@ struct machdep_calls {
*/
void (*machine_kexec)(struct kimage *image);
#endif /* CONFIG_KEXEC */
+
+#ifdef CONFIG_SUSPEND
+ /* These are called to disable and enable, respectively, IRQs when
+ * entering a suspend state. If NULL, then the generic versions
+ * will be called. The generic versions disable/enable the
+ * decrementer along with interrupts.
+ */
+ void (*suspend_disable_irqs)(void);
+ void (*suspend_enable_irqs)(void);
+#endif
};
extern void power4_idle(void);
@@ -326,5 +336,8 @@ static inline void log_error(char *buf, unsigned int err_type, int fatal)
ppc_md.log_error(buf, err_type, fatal);
}
+void generic_suspend_disable_irqs(void);
+void generic_suspend_enable_irqs(void);
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_MACHDEP_H */
--
1.5.3
^ permalink raw reply related
* [PATCH v2] Check _PAGE_RW and _PAGE_PRESENT on kernel addresses.
From: Scott Wood @ 2007-09-05 22:04 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Previously, the TLB miss handlers assumed that pages above KERNELBASE are
always present and read/write. This assumption is false in the case of
CONFIG_DEBUG_PAGEALLOC.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/head_32.S | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 7d73a13..0e3df1f 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -475,10 +475,10 @@ InstructionTLBMiss:
li r1,_PAGE_USER|_PAGE_PRESENT /* low addresses tested as user */
lwz r2,PGDIR(r2)
blt+ 112f
+ mfspr r2,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
+ rlwimi r1,r2,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
lis r2,swapper_pg_dir@ha /* if kernel address, use */
addi r2,r2,swapper_pg_dir@l /* kernel page table */
- mfspr r1,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
- rlwinm r1,r1,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
112: tophys(r2,r2)
rlwimi r2,r3,12,20,29 /* insert top 10 bits of address */
lwz r2,0(r2) /* get pmd entry */
@@ -549,10 +549,10 @@ DataLoadTLBMiss:
li r1,_PAGE_USER|_PAGE_PRESENT /* low addresses tested as user */
lwz r2,PGDIR(r2)
blt+ 112f
+ mfspr r2,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
+ rlwimi r1,r2,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
lis r2,swapper_pg_dir@ha /* if kernel address, use */
addi r2,r2,swapper_pg_dir@l /* kernel page table */
- mfspr r1,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
- rlwinm r1,r1,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
112: tophys(r2,r2)
rlwimi r2,r3,12,20,29 /* insert top 10 bits of address */
lwz r2,0(r2) /* get pmd entry */
@@ -621,10 +621,10 @@ DataStoreTLBMiss:
li r1,_PAGE_RW|_PAGE_USER|_PAGE_PRESENT /* access flags */
lwz r2,PGDIR(r2)
blt+ 112f
+ mfspr r2,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
+ rlwimi r1,r2,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
lis r2,swapper_pg_dir@ha /* if kernel address, use */
addi r2,r2,swapper_pg_dir@l /* kernel page table */
- mfspr r1,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
- rlwinm r1,r1,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
112: tophys(r2,r2)
rlwimi r2,r3,12,20,29 /* insert top 10 bits of address */
lwz r2,0(r2) /* get pmd entry */
--
1.5.3
^ permalink raw reply related
* Re: [PATCH 1/3] CPM: Change from fsl, brg-frequency to brg/clock-frequency
From: Scott Wood @ 2007-09-05 21:58 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070905215708.GA8718@lixom.net>
On Wed, Sep 05, 2007 at 04:57:08PM -0500, Olof Johansson wrote:
> On Wed, Sep 05, 2007 at 02:13:13PM -0500, Scott Wood wrote:
> > As suggested by David Gibson, now that we have a separate node
> > for the baud rate generators, it's better to use the standard
> > clock-frequency property than a cpm-node-level fsl,brg-frequency
> > property.
> >
> > This patch updates existing places where fsl,brg-frequency is
> > used.
>
> What about older platforms that were booted with the older device
> tree? Don't you have to stay compatible with them?
The older platforms use /soc/cpm/brg-frequency, not
/soc/cpm/fsl,brg-frequency -- and that is still supported. The latter
only exists as one patch in Kumar's tree.
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] CPM: Change from fsl, brg-frequency to brg/clock-frequency
From: Olof Johansson @ 2007-09-05 21:57 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905191313.GA31927@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:13:13PM -0500, Scott Wood wrote:
> As suggested by David Gibson, now that we have a separate node
> for the baud rate generators, it's better to use the standard
> clock-frequency property than a cpm-node-level fsl,brg-frequency
> property.
>
> This patch updates existing places where fsl,brg-frequency is
> used.
What about older platforms that were booted with the older device
tree? Don't you have to stay compatible with them? Think kexec of a
system running a kernel with the older device tree, for example.
-Olof
^ permalink raw reply
* Re: Xilinx FX60
From: Sergey Temerkhanov @ 2007-09-05 21:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1189023628.6185.59.camel@PisteOff>
On Thursday 06 September 2007 00:20:28 Robert Woodworth wrote:
> Is it then possible to run two independent kernels, one on each PPC??
AMP must work there.
>
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ 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