* Re: [PATCH] Freescale QUICC Engine USB Host Controller
From: Laurent Pinchart @ 2008-04-03 13:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-usb
In-Reply-To: <20080311191744.GA10518@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]
Hi Anton,
On Tuesday 11 March 2008 20:17, Anton Vorontsov wrote:
> This is patch adds support for the FHCI USB controller, as found
> in the Freescale MPC836x and MPC832x processors. It can support
> Full or Low speed modes.
>
> Quite a lot hardware is doing by itself (SOF generation, CRC generation
> and checking), though scheduling and retransmission is on the software
> shoulders.
>
> This controller does not integrate the root hub, so this driver also
> fakes an one-port hub. External hub is required to support more than
> one device.
Would it be possible to use the driver for CPM2-based devices ? The only
difference I found between the CPM2 and QE USB controllers is the SOF
handling. The QE USB controller increments the frame number itself, while the
CPM USB controller requires the host to increment the frame number.
At first sight the driver depends on qe_lib for:
- muram allocation (qe_muram_alloc/free, qe_muram_offset/addr)
- GPIO access (qe_gpio_set_dedicated)
- clock routing (qe_clock_source, qe_usb_clock_set)
- QE commands execution (qe_issue_cmd)
It shouldn't be too difficult to abstract those operation in a fashion similar
to the cpm_uart driver.
Have you already worked on CPM2 support, or thought about any particular issue
I should pay attention to ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* interrupt latency spi
From: mejjad lahcen @ 2008-04-03 14:04 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
hi all of you , I am wndering if someone has already done test for interrupt
latency on linx 2.6.23 mpc5200b.
I am working on writing a driver which is get SPi involved on design, and I
know that the spi interrupt will occurs at every 2 us ( speed 4 MHz
interupt occurs when It recieves on bytes) so I am worring about interrupt
latency.
I dont know if someone has any suggestions or a litle advice.
cheers
[-- Attachment #2: Type: text/html, Size: 482 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
From: Grant Likely @ 2008-04-03 14:05 UTC (permalink / raw)
To: John Linn; +Cc: Johann Baudy, linuxppc-dev
In-Reply-To: <20080403132901.B50D1194805D@mail96-sin.bigfish.com>
On Thu, Apr 3, 2008 at 7:28 AM, John Linn <John.Linn@xilinx.com> wrote:
> Hi Johann,
>
> You're right about it being missing. I have another patch for virtex
> specific initialization that handles that. I have not submitted it yet as I
> was trying to get these patches thru the system.
>
> I have been told in this forum that the bootstrap loader should not be
> setting up the baud rate and that normally the boot loader does it.
>
> In the case of FPGAs, we don't always use a boot loader so we need this to
> happen in the bootstrap loader. I can forward that patch to you if you're
> interested before it goes to this group.
>
Yes, the reason for not fiddling with the clock rate divisor at this
point is that it increases the chance of getting at least *something*
out the serial port if the boot goes bad. For example, if the device
tree has the clock rate listed incorrectly and the wrapper sets the
serial port baud rate then the serial port will become unusable for
bootwrapper debug.
So, in the FPGA case or other no-firmware situations there needs to be
a place to do this. Thinking on it further, I suppose it really does
belong in the serial driver, but it needs to be protected so that only
board ports that explicitly request it will do baud rate setup.
Perhaps ns16550_console_init() should call a __weak function that can
be overridden by a board port with a version that returns 1 instead of
0. (off the top of my head; there may be better approaches).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] ibm_newemac: Fix problem with jumbo frame support and EMAC V4
From: Stefan Roese @ 2008-04-03 14:16 UTC (permalink / raw)
To: netdev, linuxppc-dev
This fixes the jumbo frame support on EMAC V4 systems. Now the correct
bit is set depending on the EMAC version configured.
Tested on Kilauea (405EX) and Canyonlands (460EX).
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/core.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 0789802..486901f 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -524,7 +524,10 @@ static int emac_configure(struct emac_instance *dev)
rx_size = dev->rx_fifo_size_gige;
if (dev->ndev->mtu > ETH_DATA_LEN) {
- mr1 |= EMAC_MR1_JPSM;
+ if (emac_has_feature(dev, EMAC_FTR_EMAC4))
+ mr1 |= EMAC4_MR1_JPSM;
+ else
+ mr1 |= EMAC_MR1_JPSM;
dev->stop_timeout = STOP_TIMEOUT_1000_JUMBO;
} else
dev->stop_timeout = STOP_TIMEOUT_1000;
--
1.5.4.5
^ permalink raw reply related
* Re: [PATCH] Freescale QUICC Engine USB Host Controller
From: Anton Vorontsov @ 2008-04-03 14:30 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Scott Wood, linuxppc-dev, linux-usb, David Brownell, Timur Tabi
In-Reply-To: <200804031545.51834.laurentp@cse-semaphore.com>
On Thu, Apr 03, 2008 at 03:45:47PM +0200, Laurent Pinchart wrote:
> Hi Anton,
>
> On Tuesday 11 March 2008 20:17, Anton Vorontsov wrote:
> > This is patch adds support for the FHCI USB controller, as found
> > in the Freescale MPC836x and MPC832x processors. It can support
> > Full or Low speed modes.
> >
> > Quite a lot hardware is doing by itself (SOF generation, CRC generation
> > and checking), though scheduling and retransmission is on the software
> > shoulders.
> >
> > This controller does not integrate the root hub, so this driver also
> > fakes an one-port hub. External hub is required to support more than
> > one device.
>
> Would it be possible to use the driver for CPM2-based devices ?
Probably. But no one had tried this yet.
> The only
> difference I found between the CPM2 and QE USB controllers is the SOF
> handling. The QE USB controller increments the frame number itself, while the
> CPM USB controller requires the host to increment the frame number.
>
> At first sight the driver depends on qe_lib for:
>
> - muram allocation (qe_muram_alloc/free, qe_muram_offset/addr)
Yeah, I already posted a patch to deal with it, see
http://ozlabs.org/pipermail/linuxppc-dev/2008-March/053249.html
(btw... Scott, Timur did you have a chance to look into this?)
> - GPIO access (qe_gpio_set_dedicated)
This is because of David Brownell. ;-) Specifically, unwillingness to
accept that set_dedicated is portable for some scope of GPIO controllers,
as well as GPIO users.
> - clock routing (qe_clock_source, qe_usb_clock_set)
Well, there is Linux CLK API (somewhat similar to GPIO API), but PowerPC
doesn't use it yet. Neither I can tell if CLK API is suitable for our
needs, or if it needs to be extended. Quick&dirty workarounds are
still possible though, but clk api is the right way to go.
> - QE commands execution (qe_issue_cmd)
No proper solution yet.
> It shouldn't be too difficult to abstract those operation in a fashion similar
> to the cpm_uart driver.
Yup, but we still have ucc_serial (QE) and cpm_uart (CPM1/2) drivers as
separate matters though. ;-) I didn't look for the reasons of this split
but I assume there are and they're strong enough.
> Have you already worked on CPM2 support,
Nope, I don't have CPM2 board to work on.
> or thought about any particular issue
> I should pay attention to ?
Nope, sorry.
--
Anton Vorontsov
email: cboumailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] [POWERPC] 4xx: Change dts files to support jumbo frames
From: Stefan Roese @ 2008-04-03 14:38 UTC (permalink / raw)
To: linuxppc-dev
This patch changes the "max-frame-size" property to 9000 for all gbit
enabled 4xx boards. All those ports generally support jumbo frames, so
let's give the user a chance to enable it.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/boot/dts/haleakala.dts | 2 +-
arch/powerpc/boot/dts/katmai.dts | 2 +-
arch/powerpc/boot/dts/kilauea.dts | 4 ++--
arch/powerpc/boot/dts/makalu.dts | 4 ++--
arch/powerpc/boot/dts/rainier.dts | 4 ++--
arch/powerpc/boot/dts/sequoia.dts | 4 ++--
arch/powerpc/boot/dts/taishan.dts | 4 ++--
7 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/boot/dts/haleakala.dts b/arch/powerpc/boot/dts/haleakala.dts
index 02e4ba3..b5d95ac 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -218,7 +218,7 @@
mal-tx-channel = <0>;
mal-rx-channel = <0>;
cell-index = <0>;
- max-frame-size = <5dc>;
+ max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
index fc86e5a..cc2873a 100644
--- a/arch/powerpc/boot/dts/katmai.dts
+++ b/arch/powerpc/boot/dts/katmai.dts
@@ -212,7 +212,7 @@
mal-tx-channel = <0>;
mal-rx-channel = <0>;
cell-index = <0>;
- max-frame-size = <5dc>;
+ max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "gmii";
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
index 8baef61..48c9a6e 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -219,7 +219,7 @@
mal-tx-channel = <0>;
mal-rx-channel = <0>;
cell-index = <0>;
- max-frame-size = <5dc>;
+ max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
@@ -247,7 +247,7 @@
mal-tx-channel = <1>;
mal-rx-channel = <1>;
cell-index = <1>;
- max-frame-size = <5dc>;
+ max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index 710c011..84cc5e7 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -219,7 +219,7 @@
mal-tx-channel = <0>;
mal-rx-channel = <0>;
cell-index = <0>;
- max-frame-size = <5dc>;
+ max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
@@ -247,7 +247,7 @@
mal-tx-channel = <1>;
mal-rx-channel = <1>;
cell-index = <1>;
- max-frame-size = <5dc>;
+ max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
diff --git a/arch/powerpc/boot/dts/rainier.dts b/arch/powerpc/boot/dts/rainier.dts
index 9f6f58b..6a8fa70 100644
--- a/arch/powerpc/boot/dts/rainier.dts
+++ b/arch/powerpc/boot/dts/rainier.dts
@@ -269,7 +269,7 @@
mal-tx-channel = <0>;
mal-rx-channel = <0>;
cell-index = <0>;
- max-frame-size = <5dc>;
+ max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
@@ -298,7 +298,7 @@
mal-tx-channel = <1>;
mal-rx-channel = <1>;
cell-index = <1>;
- max-frame-size = <5dc>;
+ max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
index 675026b..a1ae4d6 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -284,7 +284,7 @@
mal-tx-channel = <0>;
mal-rx-channel = <0>;
cell-index = <0>;
- max-frame-size = <5dc>;
+ max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
@@ -313,7 +313,7 @@
mal-tx-channel = <1>;
mal-rx-channel = <1>;
cell-index = <1>;
- max-frame-size = <5dc>;
+ max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
index 96d033d..e808e1c 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -304,7 +304,7 @@
mal-tx-channel = <2>;
mal-rx-channel = <2>;
cell-index = <2>;
- max-frame-size = <5dc>;
+ max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
@@ -328,7 +328,7 @@
mal-tx-channel = <3>;
mal-rx-channel = <3>;
cell-index = <3>;
- max-frame-size = <5dc>;
+ max-frame-size = <2328>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
phy-mode = "rgmii";
--
1.5.4.5
^ permalink raw reply related
* Re: [PATCH] Freescale QUICC Engine USB Host Controller
From: Scott Wood @ 2008-04-03 15:27 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, linux-usb, David Brownell, Timur Tabi
In-Reply-To: <20080403143052.GA5955@polina.dev.rtsoft.ru>
On Thu, Apr 03, 2008 at 06:30:52PM +0400, Anton Vorontsov wrote:
> On Thu, Apr 03, 2008 at 03:45:47PM +0200, Laurent Pinchart wrote:
> > At first sight the driver depends on qe_lib for:
> >
> > - muram allocation (qe_muram_alloc/free, qe_muram_offset/addr)
>
> Yeah, I already posted a patch to deal with it, see
> http://ozlabs.org/pipermail/linuxppc-dev/2008-March/053249.html
> (btw... Scott, Timur did you have a chance to look into this?)
It looks fine to me.
> > It shouldn't be too difficult to abstract those operation in a fashion similar
> > to the cpm_uart driver.
>
> Yup, but we still have ucc_serial (QE) and cpm_uart (CPM1/2) drivers as
> separate matters though. ;-) I didn't look for the reasons of this split
> but I assume there are and they're strong enough.
Not really. :-)
The reason was because the work hasn't been done yet to merge the
infrastructure for CPM and QE.
-Scott
^ permalink raw reply
* Re: [PATCH] Freescale QUICC Engine USB Host Controller
From: Timur Tabi @ 2008-04-03 15:33 UTC (permalink / raw)
To: avorontsov; +Cc: Scott Wood, linux-usb, David Brownell, linuxppc-dev
In-Reply-To: <20080403143052.GA5955@polina.dev.rtsoft.ru>
Anton Vorontsov wrote:
> Yeah, I already posted a patch to deal with it, see
> http://ozlabs.org/pipermail/linuxppc-dev/2008-March/053249.html
> (btw... Scott, Timur did you have a chance to look into this?)
Seems to be okay. I presume the code actually works with these changes. :-)
My only concern is that the functions are still called cpm_xxxx even though they
apply to the CPM and the QE. Sure, the QE is really just CPM3, but I'd like to
see a nomenclature that's more inclusive.
We should also be able to get rid of cpm_alloc/free functions anyway, since
they're just front-ends to the rheap code. But that's a problem for another time.
> Well, there is Linux CLK API (somewhat similar to GPIO API), but PowerPC
> doesn't use it yet.
Yeah, I noticed that too. I'll add it to my to-do list, but I suspect that
someone else will get around to it before I do.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] Freescale QUICC Engine USB Host Controller
From: Scott Wood @ 2008-04-03 15:36 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, David Brownell, linux-usb
In-Reply-To: <47F4F8B0.4090708@freescale.com>
On Thu, Apr 03, 2008 at 10:33:04AM -0500, Timur Tabi wrote:
> My only concern is that the functions are still called cpm_xxxx even though they
> apply to the CPM and the QE. Sure, the QE is really just CPM3, but I'd like to
> see a nomenclature that's more inclusive.
Yeah, but cpmqe would be too clunky. I went with cpm since it has
seniority.
-Scott
^ permalink raw reply
* RE: Xilinx LLTEMAC driver issues
From: Xiaochang Duan @ 2008-04-03 15:42 UTC (permalink / raw)
To: MingLiu, John Bonesio, Johann Baudy; +Cc: John Linn, git, linuxppc-embedded
In-Reply-To: <BAY138-W45D7625ED50533D8D2680BB2F70@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]
According to C operator precedence ((http://www.difranco.net/cop2220/op-prec.htm), the following patch should not be needed as operator “<<” has higher precedence than operator “|”.
- XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, (Start) << 16 | (Insert))
+ XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, ((Start) << 16) |
+ (Insert))
Also FYI, the XLlDma_mBdWrite currently is defined in xlldma driver as:
#define XLlDma_mBdWrite(BaseAddress, Offset, Data) \
(*(u32*)((u32)(BaseAddress) + (u32)(Offset)) = (Data))
So I don’t understand why the patch could help.
Thanks,
-Xiaochang
________________________________
From: MingLiu [mailto:eemingliu@hotmail.com]
Sent: Thursday, April 03, 2008 2:29 AM
To: John Bonesio; Johann Baudy
Cc: linuxppc-embedded@ozlabs.org; John Linn; git
Subject: RE: Xilinx LLTEMAC driver issues
Dear all,
> The change with the extra parenthesis (in the patch starting with line 133) seems unecessary. I looked at the XLlDma_mBdWrite macro and it appeared to have the correct use of parethesis in the implementation.
> So, assuming there's nothing subtle that I missed, it's not needed. However, it does no harm either.
However it really helps after I tried this patch. So there should be some difference after it is used.
One more question, does this mean that the problem is not on the hardware timing, but the device driver?
BR
Ming
________________________________
Windows Live Writer，支持离线撰写博客内容，随时随地想写就写。 立即使用！ <http://get.live.cn/product/writer.html>
[-- Attachment #2: Type: text/html, Size: 7774 bytes --]
^ permalink raw reply
* RE: linux 2.6 and xps_ethernetlite
From: Stephen Neuendorffer @ 2008-04-03 16:01 UTC (permalink / raw)
To: Matteo Vit, linuxppc-embedded
In-Reply-To: <47F49EF7.6010709@dave.eu>
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Matteo =
Vit
> Sent: Thursday, April 03, 2008 2:10 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: linux 2.6 and xps_ethernetlite
>=20
> Hi,
> I'm planning to use the xps_ethernetlite with linux 2.6 kernel (xilinx
> git for example). Is there support for it ? Can I use the
> opb_ethernetlite driver ?
Yes, it works fine.
Steve
^ permalink raw reply
* cpu_clock confusion (was: printk time confusion?)
From: Johannes Berg @ 2008-04-03 16:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Ingo Molnar, Arnd Bergmann, Linux Kernel list
In-Reply-To: <1207219724.10388.319.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]
Hi,
> > Not sure whether the lockdep patches or something else is causing this
> > as I haven't checked w/o the patches yet, but I seem to be having some
> > confusion of printk timestamps:
>
> Tried reverting the patches ?
That didn't help, so it's not the lockdep patches causing it. I'm still
seeing printk timestamps like this:
[ 2.764009 (3/3)]
[ 4.272241 (2/2)]
[ 4.272322 (2/2)]
[ 4.272375 (2/2)]
[ 2.948002 (3/3)]
As you can see, I added printk_cpu and smp_processor_id() to the printk
timestamp output and thus it is obvious that the different times come
from different CPUs.
I have to admit that I do not understand the cpu_clock() implementation,
but I can only point out that the bug seems to be there since our
sched_clock() uses the timebase which is certainly synchronized. For the
fun of it, here's another output, with get_tb() thrown in:
[ 15.285317 (0/0,1734086151)]
[ 13.563845 (3/3,1757040324)]
[ 13.700157 (3/3,1773150788)]
[ 15.181275 (1/1,1829646200)]
[ 15.181343 (1/1,1829648488)]
[ 16.987944 (0/0,1829664311)]
[ 16.988485 (0/0,1829682407)]
[ 12.047482 (2/2,1829690681)]
As expected, the timebase is perfectly fine, it's monotonously
increasing over all the processors, but cpu_clock() doesn't seem to
notice. Not sure what to make of it. It seems just using the timebase
(in form of sched_clock()) ought to be perfectly fine and even have less
overhead than all this cpu_clock() business.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: Xilinx LLTEMAC driver issues
From: Johann Baudy @ 2008-04-03 16:39 UTC (permalink / raw)
To: Xiaochang Duan; +Cc: John Linn, git, linuxppc-embedded
In-Reply-To: <20080403154253.286DE5A004D@mail128-sin.bigfish.com>
VGhlIG9ubHkgcGFydCBvZiB0aGUgcGF0Y2ggdGhhdCByZWFsbHkgc29sdmVzIHRoZSBjaGVja3N1
bSBvZmZsb2FkCmNhbGN1bGF0aW9uIGlzIGludG8geGVuZXRfRG1hU2VuZF9pbnRlcm5hbCgpLgpU
aGUgcmVzdCBpcyB3YXJuaW5nIHJlbW92YWwsIGNvbW1lbnQgdXBkYXRlIGFuZCBkZXZlbG9wZXIg
ZnJpZW5kbHkgZGVmaW5lIDopCgpCZXN0IHJlZ2FyZHMsCkpvaGFubgoKCjIwMDgvNC8zIFhpYW9j
aGFuZyBEdWFuIDx4aWFvY2hhbmcuZHVhbkB4aWxpbnguY29tPjoKPgo+Cj4KPgo+IEFjY29yZGlu
ZyB0byBDIG9wZXJhdG9yIHByZWNlZGVuY2UgKChodHRwOi8vd3d3LmRpZnJhbmNvLm5ldC9jb3Ay
MjIwL29wLXByZWMuaHRtKSwgdGhlIGZvbGxvd2luZyBwYXRjaCBzaG91bGQgbm90IGJlIG5lZWRl
ZCBhcyBvcGVyYXRvciAiPDwiIGhhcyBoaWdoZXIgcHJlY2VkZW5jZSB0aGFuIG9wZXJhdG9yICJ8
Ii4KPgo+Cj4KPiAtICAgIFhMbERtYV9tQmRXcml0ZSgoQmRQdHIpLCBYTExETUFfQkRfVVNSMV9P
RkZTRVQsIChTdGFydCkgPDwgMTYgfCAoSW5zZXJ0KSkKPgo+Cj4gKyAgICBYTGxEbWFfbUJkV3Jp
dGUoKEJkUHRyKSwgWExMRE1BX0JEX1VTUjFfT0ZGU0VULCAoKFN0YXJ0KSA8PCAxNikgfAo+Cj4g
KyAoSW5zZXJ0KSkKPgo+Cj4KPiBBbHNvIEZZSSwgdGhlIFhMbERtYV9tQmRXcml0ZSBjdXJyZW50
bHkgaXMgZGVmaW5lZCBpbiB4bGxkbWEgZHJpdmVyIGFzOgo+Cj4KPgo+ICNkZWZpbmUgWExsRG1h
X21CZFdyaXRlKEJhc2VBZGRyZXNzLCBPZmZzZXQsIERhdGEpICAgICAgICAgICAgICAgIFwKPgo+
ICAgICAgICAgICAgICgqKHUzMiopKCh1MzIpKEJhc2VBZGRyZXNzKSArICh1MzIpKE9mZnNldCkp
ID0gKERhdGEpKQo+Cj4KPgo+IFNvIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdGhlIHBhdGNoIGNv
dWxkIGhlbHAuCj4KPgo+Cj4gVGhhbmtzLAo+Cj4gLVhpYW9jaGFuZwo+Cj4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KCj4KPiBGcm9tOiBNaW5nTGl1IFttYWlsdG86ZWVtaW5nbGl1
QGhvdG1haWwuY29tXQo+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwMywgMjAwOCAyOjI5IEFNCj4g
VG86IEpvaG4gQm9uZXNpbzsgSm9oYW5uIEJhdWR5Cj4gQ2M6IGxpbnV4cHBjLWVtYmVkZGVkQG96
bGFicy5vcmc7IEpvaG4gTGlubjsgZ2l0Cj4KPiBTdWJqZWN0OiBSRTogWGlsaW54IExMVEVNQUMg
ZHJpdmVyIGlzc3Vlcwo+Cj4KPgo+Cj4KPgo+IERlYXIgYWxsLAo+Cj4gPiBUaGUgY2hhbmdlIHdp
dGggdGhlIGV4dHJhIHBhcmVudGhlc2lzIChpbiB0aGUgcGF0Y2ggc3RhcnRpbmcgd2l0aCBsaW5l
IDEzMykgc2VlbXMgdW5lY2Vzc2FyeS4gSSBsb29rZWQgYXQgdGhlIFhMbERtYV9tQmRXcml0ZSBt
YWNybyBhbmQgaXQgYXBwZWFyZWQgdG8gaGF2ZSB0aGUgY29ycmVjdCB1c2Ugb2YgcGFyZXRoZXNp
cyBpbiB0aGUgaW1wbGVtZW50YXRpb24uCj4gPiBTbywgYXNzdW1pbmcgdGhlcmUncyBub3RoaW5n
IHN1YnRsZSB0aGF0IEkgbWlzc2VkLCBpdCdzIG5vdCBuZWVkZWQuIEhvd2V2ZXIsIGl0IGRvZXMg
bm8gaGFybSBlaXRoZXIuCj4KPiBIb3dldmVyIGl0IHJlYWxseSBoZWxwcyBhZnRlciBJIHRyaWVk
IHRoaXMgcGF0Y2guIFNvIHRoZXJlIHNob3VsZCBiZSBzb21lIGRpZmZlcmVuY2UgYWZ0ZXIgaXQg
aXMgdXNlZC4KPgo+IE9uZSBtb3JlIHF1ZXN0aW9uLCBkb2VzIHRoaXMgbWVhbiB0aGF0IHRoZSBw
cm9ibGVtIGlzIG5vdCBvbiB0aGUgaGFyZHdhcmUgdGltaW5nLCBidXQgdGhlIGRldmljZSBkcml2
ZXI/Cj4KPiBCUgo+IE1pbmcKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKPgo+
IFdpbmRvd3MgTGl2ZSBXcml0ZXKjrNans9bA68/f16vQtLKpv83E2sjdo6zL5sqxy+a12M/r0LS+
zdC0oaMgwaK8tMq508OjoQoKCgotLSAKSm9oYW5uIEJhdWR5CmpvaGFhaG5AZ21haWwuY29tCg==
^ permalink raw reply
* [PATCH v2] E500 Make steal_context SMP-safe.
From: Randy Vinson @ 2008-04-03 16:46 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
When steal_context is used on SMP systems, it can steal a context in
use by one of the other processors. This patch adds context tracking to
prevent this as suggested by BenH.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
---
The previous version of this patch had some unnecessary code which has been
removed in this version.
Note: This is a proof-of-concept patch. This isn't my area of expertise,
so I'd greatly appreciate any guidance I can get. I'm considering the
use of for_each_online_cpu() instead of for_each_possible_cpu() and
possibly putting the changes under a CONFIG_SMP switch to prevent unnecessary
overhead in the non-SMP case.
arch/powerpc/mm/mmu_context_32.c | 29 ++++++++++++++++++++++++-----
include/asm-powerpc/mmu_context.h | 5 +++++
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/mm/mmu_context_32.c b/arch/powerpc/mm/mmu_context_32.c
index cc32ba4..0dc7b83 100644
--- a/arch/powerpc/mm/mmu_context_32.c
+++ b/arch/powerpc/mm/mmu_context_32.c
@@ -34,6 +34,8 @@ unsigned long context_map[LAST_CONTEXT / BITS_PER_LONG + 1];
atomic_t nr_free_contexts;
struct mm_struct *context_mm[LAST_CONTEXT+1];
void steal_context(void);
+DEFINE_SPINLOCK(mm_lock);
+DEFINE_PER_CPU(struct mm_struct *, curr_mm);
#endif /* FEW_CONTEXTS */
/*
@@ -42,6 +44,9 @@ void steal_context(void);
void __init
mmu_context_init(void)
{
+#ifdef FEW_CONTEXTS
+ int cpu;
+#endif
/*
* Some processors have too few contexts to reserve one for
* init_mm, and require using context 0 for a normal task.
@@ -52,6 +57,8 @@ mmu_context_init(void)
next_mmu_context = FIRST_CONTEXT;
#ifdef FEW_CONTEXTS
atomic_set(&nr_free_contexts, LAST_CONTEXT - FIRST_CONTEXT + 1);
+ for_each_possible_cpu(cpu)
+ per_cpu(curr_mm, cpu) = NULL;
#endif /* FEW_CONTEXTS */
}
@@ -72,12 +79,24 @@ void
steal_context(void)
{
struct mm_struct *mm;
+ int cpu;
+
+ do {
+ /* free up context `next_mmu_context' */
+ /* if we shouldn't free context 0, don't... */
+ if (next_mmu_context < FIRST_CONTEXT)
+ next_mmu_context = FIRST_CONTEXT;
+ mm = context_mm[next_mmu_context];
+ for_each_possible_cpu(cpu) {
+ if ((cpu != smp_processor_id()) &&
+ per_cpu(curr_mm, cpu) == mm) {
+ mm = NULL;
+ next_mmu_context = (next_mmu_context + 1) &
+ LAST_CONTEXT;
+ }
+ }
+ } while(!mm);
- /* free up context `next_mmu_context' */
- /* if we shouldn't free context 0, don't... */
- if (next_mmu_context < FIRST_CONTEXT)
- next_mmu_context = FIRST_CONTEXT;
- mm = context_mm[next_mmu_context];
flush_tlb_mm(mm);
destroy_context(mm);
}
diff --git a/include/asm-powerpc/mmu_context.h b/include/asm-powerpc/mmu_context.h
index 9102b8b..e083b25 100644
--- a/include/asm-powerpc/mmu_context.h
+++ b/include/asm-powerpc/mmu_context.h
@@ -113,6 +113,8 @@ extern unsigned long next_mmu_context;
extern atomic_t nr_free_contexts;
extern struct mm_struct *context_mm[LAST_CONTEXT+1];
extern void steal_context(void);
+extern spinlock_t mm_lock;
+DECLARE_PER_CPU(struct mm_struct *, curr_mm);
#endif
/*
@@ -125,6 +127,7 @@ static inline void get_mmu_context(struct mm_struct *mm)
if (mm->context.id != NO_CONTEXT)
return;
#ifdef FEW_CONTEXTS
+ spin_lock(&mm_lock);
while (atomic_dec_if_positive(&nr_free_contexts) < 0)
steal_context();
#endif
@@ -138,6 +141,8 @@ static inline void get_mmu_context(struct mm_struct *mm)
mm->context.id = ctx;
#ifdef FEW_CONTEXTS
context_mm[ctx] = mm;
+ per_cpu(curr_mm, smp_processor_id()) = mm;
+ spin_unlock(&mm_lock);
#endif
}
--
1.5.4.4.551.g1658c
^ permalink raw reply related
* Re: interrupt latency spi
From: Gabriel Paubert @ 2008-04-03 17:41 UTC (permalink / raw)
To: mejjad lahcen; +Cc: linuxppc-dev
In-Reply-To: <9b4863980804030609s3ff05c33g462ffc1769546010@mail.gmail.com>
On Thu, Apr 03, 2008 at 09:09:04AM -0400, mejjad lahcen wrote:
> hi all of you ,
> I am wndering if someone has already done test for interrupt latency on
> linx 2.6.23 mpc5200b.
> I am working on writing a driver which is get SPi involved on design, and I
> know that the spi interrupt will occurs at every 2 us ( speed 4 MHz
> interupt occurs when It recieves on bytes) so I am worring about interrupt
> latency.
Expecting to be able to handle an interrupt every 2 microseconds is
simply crazy. Your hardware should at least have some FIFO to buffer
the data, hey, that's what UART started doing even at much lower bit
rates...
Gabriel
^ permalink raw reply
* RE: Xilinx LLTEMAC driver issues
From: Xiaochang Duan @ 2008-04-03 17:41 UTC (permalink / raw)
To: Johann Baudy; +Cc: John Linn, git, linuxppc-embedded
In-Reply-To: <7e0dd21a0804030939p30699ae3s4c485eb35a53b7ee@mail.gmail.com>
Thanks for the clarification. :)
-Xiaochang
-----Original Message-----
From: Johann Baudy [mailto:johaahn@gmail.com]=20
Sent: Thursday, April 03, 2008 10:39 AM
To: Xiaochang Duan
Cc: MingLiu; John Bonesio; linuxppc-embedded@ozlabs.org; John Linn; git
Subject: Re: Xilinx LLTEMAC driver issues
The only part of the patch that really solves the checksum offload
calculation is into xenet_DmaSend_internal().
The rest is warning removal, comment update and developer friendly =
define :)
Best regards,
Johann
2008/4/3 Xiaochang Duan <xiaochang.duan@xilinx.com>:
>
>
>
>
> According to C operator precedence =
((http://www.difranco.net/cop2220/op-prec.htm), the following patch =
should not be needed as operator "<<" has higher precedence than =
operator "|".
>
>
>
> - XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, (Start) << 16 | =
(Insert))
>
>
> + XLlDma_mBdWrite((BdPtr), XLLDMA_BD_USR1_OFFSET, ((Start) << 16) |
>
> + (Insert))
>
>
>
> Also FYI, the XLlDma_mBdWrite currently is defined in xlldma driver =
as:
>
>
>
> #define XLlDma_mBdWrite(BaseAddress, Offset, Data) \
>
> (*(u32*)((u32)(BaseAddress) + (u32)(Offset)) =3D (Data))
>
>
>
> So I don't understand why the patch could help.
>
>
>
> Thanks,
>
> -Xiaochang
>
> ________________________________
>
> From: MingLiu [mailto:eemingliu@hotmail.com]
> Sent: Thursday, April 03, 2008 2:29 AM
> To: John Bonesio; Johann Baudy
> Cc: linuxppc-embedded@ozlabs.org; John Linn; git
>
> Subject: RE: Xilinx LLTEMAC driver issues
>
>
>
>
>
>
> Dear all,
>
> > The change with the extra parenthesis (in the patch starting with =
line 133) seems unecessary. I looked at the XLlDma_mBdWrite macro and it =
appeared to have the correct use of parethesis in the implementation.
> > So, assuming there's nothing subtle that I missed, it's not needed. =
However, it does no harm either.
>
> However it really helps after I tried this patch. So there should be =
some difference after it is used.
>
> One more question, does this mean that the problem is not on the =
hardware timing, but the device driver?
>
> BR
> Ming
> ________________________________
>
> Windows Live =
Writer=A3=AC=D6=A7=B3=D6=C0=EB=CF=DF=D7=AB=D0=B4=B2=A9=BF=CD=C4=DA=C8=DD=A3=
=AC=CB=E6=CA=B1=CB=E6=B5=D8=CF=EB=D0=B4=BE=CD=D0=B4=A1=A3 =
=C1=A2=BC=B4=CA=B9=D3=C3=A3=A1
--=20
Johann Baudy
johaahn@gmail.com
^ permalink raw reply
* Re: [PATCH] Freescale QUICC Engine USB Host Controller
From: David Brownell @ 2008-04-03 18:22 UTC (permalink / raw)
To: Timur Tabi; +Cc: Scott Wood, linux-usb, linuxppc-dev
In-Reply-To: <47F4F8B0.4090708@freescale.com>
On Thursday 03 April 2008, Timur Tabi wrote:
> > Well, there is Linux CLK API (somewhat similar to GPIO API), but PowerPC
> > doesn't use it yet.
>
> Yeah, I noticed that too. I'll add it to my to-do list, but I suspect that
> someone else will get around to it before I do.
Note that there's some work afoot to provide a generic
implementation framework for the clk_*() calls. It was
last posted on the ARM list ... I'd hope it would make
it easier for at least some PowerPC platforms to support
that interface.
- Dave
^ permalink raw reply
* Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
From: Hollis Blanchard @ 2008-04-03 18:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804030144460.15974@blarg.am.freescale.net>
On Thursday 03 April 2008 01:52:36 Kumar Gala wrote:
> Wanted to get any feedback on this initial port of the fixmap support over
> from x86. There are a few TODOs:
>
> * change HIGHMEM support to use fixmap
> * fixup up VMALLOC config to respect fixmap
>
> (after initial powerpc patch is in tree/accepted):
> * rework a few bits of fixmap.h into an asm-generic/fixmap.h
>
> The reason for introducing fixmap into ppc32 is it provides us with a
> clean way of getting fixed compile time virtual addresses for things.
>
> Beyond the HIGHMEM usage. Ben and I have discussed cleaning up the PCIe
> 44x config code (and 83xx PCIe cfg) to use it. Also, Dale's kexec/kdump
> support on ppc32 can take advantage of it. I'm also told this is useful
> for hypervisor interactions.
>
> One question for the guys looking at hypervisor. The x86 code also has a
> function called reserve_top_address (see arch/x86/mm/pgtable_32.c). Is
> this functionality something useful on ppc? If so for what?
x86 virtualization implementations often needs a trampoline that's mapped into
both host and guest virtual address space, so that's part of what you're
seeing.
In general though, it can be very useful for the host to own a piece of the
guest's virtual address space. For example, the host could rewrite
problematic guest instructions to branch to host-optimized code which avoids
hypercalls. However, this is impossible unless the host knows it can
overwrite some portion of the guest's effective address space.
reserve_top_address() doesn't look complicated, so we might as well keep it?
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: ppc405ep and Ready enable in EBC0_BnAP register
From: ravi.rao @ 2008-04-03 18:48 UTC (permalink / raw)
To: ravi.rao; +Cc: linuxppc-embedded-bounces+ravi.rao=rflelect.com,
linuxppc-embedded
In-Reply-To: <OF39A36E1A.054DB15D-ON8525741F.00650F27-8525741F.00663A93@slpower.com>
[-- Attachment #1: Type: text/plain, Size: 2022 bytes --]
Hi All,
Some more updates..
I tried to single step using BDI2000 to narrow down what may be happening.
This is what I observed..
When I tried to access a TDMoIP reg which is memory mapped I did not see
any chipselect but got the bus error with the following Info..
********************* Screen dump
****************************************************
# echo f9200000 1 > /proc/rfl_tdmoip/prep_2dump_tdmoip_cfg
Ready to dump 0x1 TDMOIP regs starting from 0xf9200000(Phy)
0xc5380000(Virt)
# cat /proc/rfl_tdmoip/dump_tdmoip_cfg
Data machine check in kernel mode.
PLB0: BEAR= 0xc0123644 ACR= 0x00000000 BESR= 0x00800000
PLB0 to OPB: BEAR= 0xef60071c BESR0= 0x00000000 BESR1= 0x00000000
Oops: machine check, sig: 7 [#1]
NIP: 00001100 LR: C0123764 CTR: 00000001
REGS: c0240f50 TRAP: 0202 Not tainted (2.6.21)
MSR: 00001000 <ME> CR: 84044404 XER: 00000007
TASK = c3f674b0[652] 'cat' THREAD: c3a86000
GPR00: 00000001 C3A87650 C3F674B0 C3AAE000 C3A87EAC 00000000 00000C00
C3A87EA8
GPR08: 00000000 00000000 FFFFFFFF C5380000 44044408 100A54C0 03FF9C00
00000001
GPR16: 0000005E C01DB87C C02E7F78 C01E1CA8 C3A87EA8 C01E1C78 C3A87EAC
C3FD4320
GPR24: C3AAE000 00000000 C3A87F20 C0216C90 C3A87658 C3A87EA8 00000C00
C3AAE000
Call Trace:
[C3A87E80] [C0123764]
[C3A87EA0] [C009BA60]
[C3A87EF0] [C0063E6C]
[C3A87F10] [C00642C8]
[C3A87F40] [C0002CB4]
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Bus error
Upon futher digging up in the PPC405EP user manual Found the Error BESR
referring to is
Figure 26-190. PLB Error Status Register (PLB0_BESR)
Bit 8 indicates PTE2 Master 2(processor core DCU) PLB Timeout Error
Status
0 means No master 2 timeout error
1 means Master 2 timeout error
Any thoughts why we would get Timeouts from DCU ??
Thanks,
Ravishankar Govindarao
RFL Electronics Inc.
E-mail : Ravi.Rao@rflelect.com
Voice: 973.334.3100 Ext. 233
Fax: 973.334.3863
[-- Attachment #2: Type: text/html, Size: 4022 bytes --]
^ permalink raw reply
* Re: Question on mpc52xx_common.c
From: Grant Likely @ 2008-04-03 19:00 UTC (permalink / raw)
To: Detlev Zundel, linuxppc-dev
In-Reply-To: <m2wsne9a4c.fsf@ohwell.denx.de>
(cc'ing the mailing list in my reply)
On Thu, Apr 3, 2008 at 10:27 AM, Detlev Zundel <dzu@denx.de> wrote:
> I wrote,
>
> > debugging a lite5200b kernel (linux-2.6-denx equivalent of 2.6.25-rc8) I
> > noticed that in mpc52xx_map_common_devices (mpc52xx_common.c:161) the
> > cdm module is tentatively mapped. It seems strange to me that there is no
> > error checking here. Is a FDT without an cdm entry usable at all?
Sure, why not? If the firmware has already set it up correctly and no
devices using it are in use, then the kernel should be okay. :-)
That said, I can't imagine choosing to not put the cdm node into the
device tree.
> > Checking for the usage of mpc52xx_cdm I found mpc52xx_set_psc_clkdiv
> > (mpc52xx_common.c:186) only returning ENODEV when no CDM module is
> > mapped - but still not even a warning. Now the only user of
> > set_psc_clkdiv seems to be drivers/spi/mpc52xx_psc_spi.c:342 where the
> > return value is not even checked....
> >
> > Wouldn't at least a warning on a failed mapping be in order here?
By rights, the psc_spi driver should be fixed to report an error.
Other than that, there are no users of the CDM in-tree right now.
>
> And yes, I've seen that the lite5200 specific code warns on a missing
> cdm node but thats no help for other platforms....
And that's because older lite5200 firmware doesn't setup the CDM correctly.
Now, all of the mpc5200 common code needs some work I think. There
are too many places where bestcomm or other code redundantly goes
looking for common device nodes. I'd like to amalgamate a bunch of
that stuff to map them all at platform initialization time and provide
an api for retrieving the mapped region or for controlling the shared
device.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
From: Valentine Barshak @ 2008-04-03 19:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: olof
We really need to ack interrupts at mpic_teardown, since
not all platforms reset mpic at kernel start-up. For example,
kexec'ed kernel hangs on P.A. Semi if mpic_eoi() isn't called.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/sysdev/mpic.c | 6 +-----
1 files changed, 1 insertion(+), 5 deletions(-)
--- powerpc/arch/powerpc/sysdev/mpic.c 2008-02-26 15:56:57.000000000 +0300
+++ linux-2.6.new/arch/powerpc/sysdev/mpic.c 2008-04-03 23:00:45.000000000 +0400
@@ -1410,11 +1410,6 @@ void mpic_cpu_set_priority(int prio)
mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), prio);
}
-/*
- * XXX: someone who knows mpic should check this.
- * do we need to eoi the ipi including for kexec cpu here (see xics comments)?
- * or can we reset the mpic in the new kernel?
- */
void mpic_teardown_this_cpu(int secondary)
{
struct mpic *mpic = mpic_primary;
@@ -1434,6 +1429,7 @@ void mpic_teardown_this_cpu(int secondar
/* Set current processor priority to max */
mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0xf);
+ mpic_eoi(mpic);
spin_unlock_irqrestore(&mpic_lock, flags);
}
^ permalink raw reply
* [PATCH] powerpc TLF_RESTORE_SIGMASK
From: Roland McGrath @ 2008-04-03 21:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
This requires the earlier HAVE_SET_RESTORE_SIGMASK patch series.
This does the same for powerpc that I posted the x86 change for.
---
Replace TIF_RESTORE_SIGMASK with TLF_RESTORE_SIGMASK and define
our own set_restore_sigmask() function. This saves the costly
SMP-safe set_bit operation, which we do not need for the sigmask
flag since TIF_SIGPENDING always has to be set too.
Signed-off-by: Roland McGrath <roland@redhat.com>
---
arch/powerpc/kernel/entry_32.S | 4 ++--
arch/powerpc/kernel/signal.c | 12 ++++++------
arch/powerpc/kernel/signal_32.c | 2 +-
include/asm-powerpc/thread_info.h | 17 +++++++++++++----
4 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 69a91bd..646daf4 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -661,7 +661,7 @@ user_exc_return: /* r10 contains MSR_KERNEL here */
/* Check current_thread_info()->flags */
rlwinm r9,r1,0,0,(31-THREAD_SHIFT)
lwz r9,TI_FLAGS(r9)
- andi. r0,r9,(_TIF_SIGPENDING|_TIF_RESTORE_SIGMASK|_TIF_NEED_RESCHED)
+ andi. r0,r9,(_TIF_SIGPENDING|_TIF_NEED_RESCHED)
bne do_work
restore_user:
@@ -912,7 +912,7 @@ recheck:
lwz r9,TI_FLAGS(r9)
andi. r0,r9,_TIF_NEED_RESCHED
bne- do_resched
- andi. r0,r9,_TIF_SIGPENDING|_TIF_RESTORE_SIGMASK
+ andi. r0,r9,_TIF_SIGPENDING
beq restore_user
do_user_signal: /* r10 contains MSR_KERNEL here */
ori r10,r10,MSR_EE
diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
index a65a44f..ad55488 100644
--- a/arch/powerpc/kernel/signal.c
+++ b/arch/powerpc/kernel/signal.c
@@ -120,7 +120,7 @@ int do_signal(sigset_t *oldset, struct pt_regs *regs)
int ret;
int is32 = is_32bit_task();
- if (test_thread_flag(TIF_RESTORE_SIGMASK))
+ if (current_thread_info()->local_flags & _TLF_RESTORE_SIGMASK)
oldset = ¤t->saved_sigmask;
else if (!oldset)
oldset = ¤t->blocked;
@@ -131,9 +131,10 @@ int do_signal(sigset_t *oldset, struct pt_regs *regs)
check_syscall_restart(regs, &ka, signr > 0);
if (signr <= 0) {
+ struct thread_info *ti = current_thread_info();
/* No signal to deliver -- put the saved sigmask back */
- if (test_thread_flag(TIF_RESTORE_SIGMASK)) {
- clear_thread_flag(TIF_RESTORE_SIGMASK);
+ if (ti->local_flags & _TLF_RESTORE_SIGMASK) {
+ ti->local_flags &= ~_TLF_RESTORE_SIGMASK;
sigprocmask(SIG_SETMASK, ¤t->saved_sigmask, NULL);
}
return 0; /* no signals delivered */
@@ -169,10 +170,9 @@ int do_signal(sigset_t *oldset, struct pt_regs *regs)
/*
* A signal was successfully delivered; the saved sigmask is in
- * its frame, and we can clear the TIF_RESTORE_SIGMASK flag.
+ * its frame, and we can clear the TLF_RESTORE_SIGMASK flag.
*/
- if (test_thread_flag(TIF_RESTORE_SIGMASK))
- clear_thread_flag(TIF_RESTORE_SIGMASK);
+ current_thread_info()->local_flags &= ~_TLF_RESTORE_SIGMASK;
}
return ret;
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index ad69434..4ae16d1 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -243,7 +243,7 @@ long sys_sigsuspend(old_sigset_t mask)
current->state = TASK_INTERRUPTIBLE;
schedule();
- set_thread_flag(TIF_RESTORE_SIGMASK);
+ set_restore_sigmask();
return -ERESTARTNOHAND;
}
diff --git a/include/asm-powerpc/thread_info.h b/include/asm-powerpc/thread_info.h
index 40d5f98..3b9271b 100644
--- a/include/asm-powerpc/thread_info.h
+++ b/include/asm-powerpc/thread_info.h
@@ -120,7 +120,6 @@ static inline struct thread_info *current_thread_info(void)
#define TIF_SECCOMP 10 /* secure computing */
#define TIF_RESTOREALL 11 /* Restore all regs (implies NOERROR) */
#define TIF_NOERROR 12 /* Force successful syscall return */
-#define TIF_RESTORE_SIGMASK 13 /* Restore signal mask in do_signal */
#define TIF_FREEZE 14 /* Freezing for suspend */
#define TIF_RUNLATCH 15 /* Is the runlatch enabled? */
#define TIF_ABI_PENDING 16 /* 32/64 bit switch needed */
@@ -138,21 +137,31 @@ static inline struct thread_info *current_thread_info(void)
#define _TIF_SECCOMP (1<<TIF_SECCOMP)
#define _TIF_RESTOREALL (1<<TIF_RESTOREALL)
#define _TIF_NOERROR (1<<TIF_NOERROR)
-#define _TIF_RESTORE_SIGMASK (1<<TIF_RESTORE_SIGMASK)
#define _TIF_FREEZE (1<<TIF_FREEZE)
#define _TIF_RUNLATCH (1<<TIF_RUNLATCH)
#define _TIF_ABI_PENDING (1<<TIF_ABI_PENDING)
#define _TIF_SYSCALL_T_OR_A (_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP)
-#define _TIF_USER_WORK_MASK ( _TIF_SIGPENDING | \
- _TIF_NEED_RESCHED | _TIF_RESTORE_SIGMASK)
+#define _TIF_USER_WORK_MASK (_TIF_SIGPENDING | _TIF_NEED_RESCHED)
#define _TIF_PERSYSCALL_MASK (_TIF_RESTOREALL|_TIF_NOERROR)
/* Bits in local_flags */
/* Don't move TLF_NAPPING without adjusting the code in entry_32.S */
#define TLF_NAPPING 0 /* idle thread enabled NAP mode */
+#define TLF_RESTORE_SIGMASK 1 /* Restore signal mask in do_signal */
#define _TLF_NAPPING (1 << TLF_NAPPING)
+#define _TLF_RESTORE_SIGMASK (1 << TLF_RESTORE_SIGMASK)
+
+#ifndef __ASSEMBLY__
+#define HAVE_SET_RESTORE_SIGMASK 1
+static inline void set_restore_sigmask(void)
+{
+ struct thread_info *ti = current_thread_info();
+ ti->local_flags |= TLF_RESTORE_SIGMASK;
+ set_bit(TIF_SIGPENDING, &ti->flags);
+}
+#endif /* !__ASSEMBLY__ */
#endif /* __KERNEL__ */
^ permalink raw reply related
* Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
From: Benjamin Herrenschmidt @ 2008-04-03 21:45 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <200804031347.54517.hollisb@us.ibm.com>
On Thu, 2008-04-03 at 13:47 -0500, Hollis Blanchard wrote:
>
> x86 virtualization implementations often needs a trampoline that's
> mapped into
> both host and guest virtual address space, so that's part of what
> you're
> seeing.
>
> In general though, it can be very useful for the host to own a piece
> of the
> guest's virtual address space. For example, the host could rewrite
> problematic guest instructions to branch to host-optimized code which
> avoids
> hypercalls. However, this is impossible unless the host knows it can
> overwrite some portion of the guest's effective address space.
>
> reserve_top_address() doesn't look complicated, so we might as well
> keep it ?
Agreed. In fact, using the top of the address space for that is a good
idea as you can do the branching there using absolute branch
instructions which is simpler.
Ben.
^ permalink raw reply
* Re: [PATCH] PowerPC: MPIC ack interrupts at mpic_teardown_this_cpu()
From: Benjamin Herrenschmidt @ 2008-04-03 21:50 UTC (permalink / raw)
To: Valentine Barshak; +Cc: olof, linuxppc-dev
In-Reply-To: <20080403190943.GA16446@ru.mvista.com>
On Thu, 2008-04-03 at 23:09 +0400, Valentine Barshak wrote:
> We really need to ack interrupts at mpic_teardown, since
> not all platforms reset mpic at kernel start-up. For example,
> kexec'ed kernel hangs on P.A. Semi if mpic_eoi() isn't called.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
Would be interesting to find out why it hangs tho... it shouldn't .
Ben.
> arch/powerpc/sysdev/mpic.c | 6 +-----
> 1 files changed, 1 insertion(+), 5 deletions(-)
>
> --- powerpc/arch/powerpc/sysdev/mpic.c 2008-02-26 15:56:57.000000000 +0300
> +++ linux-2.6.new/arch/powerpc/sysdev/mpic.c 2008-04-03 23:00:45.000000000 +0400
> @@ -1410,11 +1410,6 @@ void mpic_cpu_set_priority(int prio)
> mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), prio);
> }
>
> -/*
> - * XXX: someone who knows mpic should check this.
> - * do we need to eoi the ipi including for kexec cpu here (see xics comments)?
> - * or can we reset the mpic in the new kernel?
> - */
> void mpic_teardown_this_cpu(int secondary)
> {
> struct mpic *mpic = mpic_primary;
> @@ -1434,6 +1429,7 @@ void mpic_teardown_this_cpu(int secondar
>
> /* Set current processor priority to max */
> mpic_cpu_write(MPIC_INFO(CPU_CURRENT_TASK_PRI), 0xf);
> + mpic_eoi(mpic);
>
> spin_unlock_irqrestore(&mpic_lock, flags);
> }
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinxuart 16550.
From: Stephen Neuendorffer @ 2008-04-03 22:36 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev; +Cc: John Linn
In-Reply-To: <200804030616.09825.arnd@arndb.de>
The device tree generator now reflects this.
Steve
> -----Original Message-----
> From: =
linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org =
[mailto:linuxppc-dev-
> bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org] On Behalf Of =
Arnd Bergmann
> Sent: Wednesday, April 02, 2008 9:16 PM
> To: linuxppc-dev@ozlabs.org
> Cc: John Linn
> Subject: Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for =
Xilinxuart 16550.
>=20
> On Thursday 03 April 2008, Grant Likely wrote:
> > >
> > > =A0Since it is not really compatible with ns16550, shouldn't you =
at least specify
> > > =A0a different "compatible" property? That way, the driver won't =
do incorrect
> > > =A0accesses when you try to use an old driver with a device tree =
that specifies
> > > =A0one of these.
> >
> > Heh; we've gone back and forth on this issue. =A0The problem is that =
we
> > have a common case of ns16550 like devices that require a little bit
> > of register address tweaking that spans a whole range of vendors (so
> > adding a compatible match with each of those vendor's prefixes is
> > probably non-scalable). =A0So, if "ns16550" is not a good idea, then
> > what should be used? =A0"sparse16550" has been suggested more than =
once.
>=20
> After another IRC discussion between Grant, Segher and myself, we =
concluded
> that we don't need to invent a new "compatible" value, as only new =
device
> trees with old kernels will have a problem with this, and they don't =
work
> in the first place.
>=20
> The devices will still have their specific "compatible" value, e.g.
> "xlnx,plb-uart16550-1.00.c", followed by "ns16550", and possibly
> "ns16450" and "i8250", although the last two do not have an effect
> on Linux.
>=20
> Josh, can you please forward all three patches in their latest =
version?
>=20
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ 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