* Re: [PATCH v4] FEC - fast ethernet controller for mpc52xx
From: Domen Puncer @ 2007-10-25 19:41 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071025185706.29496.qmail@farnsworth.org>
On 25/10/07 11:57 -0700, Dale Farnsworth wrote:
> Domen wrote:
> > > use your platform's dma mapping functions, rather than virt_to_phys()
> > >
> > > it might be the exact same implementation, inside the platform
> > > internals, but drivers should not be using this directly.
> >
> > I've replaced this with dma_map_single(), unmatched with
> > dma_unmap_single(), since bestcomm doesn't have a way to do that
> > and it's blank on ppc32 anyway.
> >
> > Is this OK? PPC guys?
>
> Even though dma_unmap_single() may be a no-op, calls to
> dma_map_single() must be matched with calls to dma_unmap_single().
>
> Perhaps with the additions below:
>
> > +static void mpc52xx_fec_free_rx_buffers(struct bcom_task *s)
> > +{
> > + struct sk_buff *skb;
> > +
> > + while (!bcom_queue_empty(s)) {
> > + skb = bcom_retrieve_buffer(s, NULL, NULL);
>
> dma_unmap_single(&skb->dev->dev, skb-data,
> FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
It looks to me like dma_unmap_single takes the mapped address
(what dma_map_single returned), and not the address we're mapping
(skb->data).
Domen
^ permalink raw reply
* Re: [PATCH v4] FEC - fast ethernet controller for mpc52xx
From: Dale Farnsworth @ 2007-10-25 20:29 UTC (permalink / raw)
To: Domen Puncer; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071025194114.GH3369@nd47.coderock.org>
On Thu, Oct 25, 2007 at 09:41:14PM +0200, Domen Puncer wrote:
> On 25/10/07 11:57 -0700, Dale Farnsworth wrote:
> > Domen wrote:
> > > > use your platform's dma mapping functions, rather than virt_to_phys()
> > > >
> > > > it might be the exact same implementation, inside the platform
> > > > internals, but drivers should not be using this directly.
> > >
> > > I've replaced this with dma_map_single(), unmatched with
> > > dma_unmap_single(), since bestcomm doesn't have a way to do that
> > > and it's blank on ppc32 anyway.
> > >
> > > Is this OK? PPC guys?
> >
> > Even though dma_unmap_single() may be a no-op, calls to
> > dma_map_single() must be matched with calls to dma_unmap_single().
> >
> > Perhaps with the additions below:
> >
> > > +static void mpc52xx_fec_free_rx_buffers(struct bcom_task *s)
> > > +{
> > > + struct sk_buff *skb;
> > > +
> > > + while (!bcom_queue_empty(s)) {
> > > + skb = bcom_retrieve_buffer(s, NULL, NULL);
> >
> > dma_unmap_single(&skb->dev->dev, skb-data,
> > FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
>
> It looks to me like dma_unmap_single takes the mapped address
> (what dma_map_single returned), and not the address we're mapping
> (skb->data).
Yeah. Sorry. That won't be so easy. We'll either need to
squirrel away the mapped address, or change the interface to
bcom_retrieve_buffers() so we can get the address.
IMO, it's still a requirement that we call dma_unmap_single() for
each call to dma_map_single().
-Dale
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: Workaround for the 440EP(x)/GR(x) processors identical PVR issue.
From: Benjamin Herrenschmidt @ 2007-10-25 20:44 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, sr
In-Reply-To: <20071025181640.GA18933@ru.mvista.com>
On Thu, 2007-10-25 at 22:16 +0400, Valentine Barshak wrote:
> PowerPC 440EP(x) 440GR(x) processors have the same PVR values, since
> they have identical cores. However, FPU is not supported on GR(x) and
> enabling APU instruction broadcast in the CCR0 register (to enable FPU)
> may cause unpredictable results. There's no safe way to detect FPU
> support at runtime. This patch provides a workarund for the issue.
> We use a POWER6 "logical PVR approach". First, we identify all EP(x)
> and GR(x) processors as GR(x) ones (which is safe). Then we check
> the device tree cpu path. If we have a EP(x) processor entry,
> we call identify_cpu again with PVR | 0x8. This bit is always 0
> in the real PVR. This way we enable FPU only for 440EP(x).
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Why not just or-in the FPU feature bit ?
Ben.
^ permalink raw reply
* RE: settimeofday not working
From: Rune Torgersen @ 2007-10-25 21:50 UTC (permalink / raw)
To: Rune Torgersen, linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B038A269F@ismail.innsys.innovsys.com>
> From: Rune Torgersen
> Sent: Thursday, October 25, 2007 2:40 PM
> On any kernel newer than 2.6.20, settimeofday does not work.
> I try to set the current date, but when I read back the time, it is
> still the old date (in our case, Jan 1 1970)
Eventually the date actually got updated. Before then it returned 00:00
Jan 1 1970 every time it was queried.
Anyways. Updated to 2.6.24-rc1, and it seems to work correctly.
^ permalink raw reply
* Re: MPC85xx and linux IDE driver
From: Michael Brian Willis @ 2007-10-25 21:49 UTC (permalink / raw)
To: Ben Warren; +Cc: linuxppc-embedded
In-Reply-To: <471657FB.3040806@qstreams.com>
On Wed, 2007-10-17 at 14:44 -0400, Ben Warren wrote:
> This device driver is a platform driver, so you need to register a
> platform device somewhere in your board-specific init code that contains
> the hardware details (memory mapping and IRQ #).
After modifying your init code and putting it in my board specific ".c"
file everything is working great.
Thanks again for all of your help!
Michael Willis
^ permalink raw reply
* Porting to /arch/powerpc
From: Rune Torgersen @ 2007-10-25 21:59 UTC (permalink / raw)
To: linuxppc-embedded
Is there a good platform/documents to look at for doing a board port
from arch/ppc to arch/powerpc?
I'm porting a 8266/8280 based board with PCI and 2 FCC ethernets
connected phy-less to a switch.
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Matt Sealey @ 2007-10-25 22:02 UTC (permalink / raw)
To: Valentine Barshak; +Cc: David Brownell, linux-usb-devel, linuxppc-dev
In-Reply-To: <4720E560.8060206@ru.mvista.com>
Valentine Barshak wrote:
> Matt Sealey wrote:
>> Compatible property on /builtin@F0000000/usb@F0001000 is
>
> We should also keep "ohci-bigendian" and "ohci-be" in the match table.
Eh.. maybe.
>> I am currently moving on the assumption that the "correct" device
>> tree for the Efika (notwithstanding the above) would be
>>
>> usb@F0001000 {
>> device-type = "usb-ohci"
>> compatible = "mpc5200-ohci,mpc5200-usb-ohci"
>
> It should also have compatible "usb-ohci" entry as a more general one.
> Others are for device-specific quirks:
> compatible = "mpc5200-usb-ohci","usb-ohci"
Why? It's in the device_type. You don't need to duplicate it as compatible
with the same value as in the device_type.
>> Using mpc5200-ohci out is by far the safest idea, although it
>> leaves in a rather platform-specific fix, I prefer singling out that
>> platform and potentially causing nasty looks towards the
>> direction of Genesi/bplan, than having ohci-bigendian continue
>> to exist for the sake of it :D
>
> So, do you suggest to use "mpc5200-ohci" instead of "ohci-be" in the
> match table?
Yes. I think ohci-be and ohci-bigendian should die. After all, it
might get mixed with Firewire if you are not being careful.
If we had to start again, device-type of "usb" (that just makes it
easier all round, it allows a system based on the MPC5200B alone to
make the assumption of OHCI), compatibles of "usb-ohci" (since this makes
it very specific that it is not just USB, but the OHCI spec) and big-endian
property would be all there would be.
Model property would give the "mpc5200-ohci" value. Since nothing checks
model (and this is not set on the firmware here), figuring on
"mpc5200-ohci" as a compatible entry is good enough. Device-specific
quirks should (Segher? Clarify please) never be futzed into compatible
properties. At least the IEEE 1275 spec makes it clear that the model
property is meant to clarify the particular device in question and is
for information, I think defining a device as "USB", then subordinately
as "OHCI flavor of USB" and particularly "the USB controller on an
MPC5200 chip" (model) is all we need here, and in fact in any device.
You could say the same about any other device - why is the current
standard to give each node a unique name based on chip docs? 5200
device tree spec says, use "gpt" as the name for the MPC5200 general
purpose timers. Why not "timer" as the name, with "fsl,gpt" in the
device_type or compatible property, and "mpc5200-gpt" in the model
property? or "fsl,slt" compatible and "mpc5200-slt" model? Or
"dma-controller" with a *model* of "bestcomm"?
Some of this makes me grind my teeth so much..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: MPC85xx and linux IDE driver
From: Ben Warren @ 2007-10-25 22:04 UTC (permalink / raw)
To: Michael Brian Willis; +Cc: linuxppc-embedded
In-Reply-To: <1193348964.29111.71.camel@louie>
Michael Brian Willis wrote:
> On Wed, 2007-10-17 at 14:44 -0400, Ben Warren wrote:
>
>
>> This device driver is a platform driver, so you need to register a
>> platform device somewhere in your board-specific init code that contains
>> the hardware details (memory mapping and IRQ #).
>>
>
> After modifying your init code and putting it in my board specific ".c"
> file everything is working great.
>
>
Fantastic!
> Thanks again for all of your help!
>
>
You're welcome.
^ permalink raw reply
* Re: Porting to /arch/powerpc
From: Scott Wood @ 2007-10-25 22:08 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-embedded
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B038A279C@ismail.innsys.innovsys.com>
Rune Torgersen wrote:
> Is there a good platform/documents to look at for doing a board port
> from arch/ppc to arch/powerpc?
> I'm porting a 8266/8280 based board with PCI and 2 FCC ethernets
> connected phy-less to a switch.
Look at head-of-tree for 82xx stuff (lots of changes since 2.6.23)...
any of the 82xx boards in arch/powerpc should be good to look at.
The fs_enet driver doesn't currently support phy-less directly, but you
may be able to do something with the fixed phy driver.
-Scott
^ permalink raw reply
* RE: Porting to /arch/powerpc
From: Joakim Tjernlund @ 2007-10-25 22:26 UTC (permalink / raw)
To: 'Scott Wood', 'Rune Torgersen'; +Cc: linuxppc-embedded
In-Reply-To: <472113CC.5020409@freescale.com>
> -----Original Message-----
> From:
> linuxppc-embedded-bounces+joakim.tjernlund=lumentis.se@ozlabs.
> org
> [mailto:linuxppc-embedded-bounces+joakim.tjernlund=lumentis.se
> @ozlabs.org] On Behalf Of Scott Wood
> Sent: den 26 oktober 2007 00:08
> To: Rune Torgersen
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Porting to /arch/powerpc
>
> Rune Torgersen wrote:
> > Is there a good platform/documents to look at for doing a board port
> > from arch/ppc to arch/powerpc?
> > I'm porting a 8266/8280 based board with PCI and 2 FCC ethernets
> > connected phy-less to a switch.
>
> Look at head-of-tree for 82xx stuff (lots of changes since 2.6.23)...
> any of the 82xx boards in arch/powerpc should be good to look at.
>
> The fs_enet driver doesn't currently support phy-less
> directly, but you
> may be able to do something with the fixed phy driver.
How is PHY less support supposed to be impl.? I would like
to do the same for ucc_geth. I once sent a patch that made
the PHY optional, but it never made into the driver.
Jocke
>
> -Scott
^ permalink raw reply
* Re: [PATCH v4] FEC - fast ethernet controller for mpc52xx
From: Jeff Garzik @ 2007-10-25 22:46 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: netdev, Domen Puncer, linuxppc-dev
In-Reply-To: <20071025202908.GA2102@xyzzy.farnsworth.org>
Dale Farnsworth wrote:
> IMO, it's still a requirement that we call dma_unmap_single() for
> each call to dma_map_single().
Yep...
^ permalink raw reply
* [PATCH 1/2] powerpc: prpmc2800 - Add MTD support
From: Mark A. Greer @ 2007-10-25 23:39 UTC (permalink / raw)
To: linuxppc-dev
From: Mark A. Greer <mgreer@mvista.com>
Create necessary device nodes so that the MTD subsystem recognizes
the MTD entries in the prpmc2800's DTS file. Also bring MTD section
of the prpmc2800's DTS file up to the current DTS specification.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
arch/powerpc/boot/dts/prpmc2800.dts | 39 +++++++++++----
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 13 +++++
2 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts b/arch/powerpc/boot/dts/prpmc2800.dts
index 297dfa5..50fc0a7 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -55,17 +55,36 @@
f2000000 f2000000 00040000>; /* Integrated SRAM */
flash@a0000000 {
- device_type = "rom";
- compatible = "direct-mapped";
- reg = <a0000000 4000000>; /* Default (64MB) */
- probe-type = "CFI";
+ compatible = "cfi-flash";
+ reg = <a0000000 04000000>;
bank-width = <4>;
- partitions = <00000000 00100000 /* RO */
- 00100000 00040001 /* RW */
- 00140000 00400000 /* RO */
- 00540000 039c0000 /* RO */
- 03f00000 00100000>; /* RO */
- partition-names = "FW Image A", "FW Config Data", "Kernel Image", "Filesystem", "FW Image B";
+ device-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ fw@0 {
+ label = "FW Image A";
+ reg = <00000000 00100000>;
+ read-only;
+ };
+ cfg@100000 {
+ label = "FW Config Data"; /* RW */
+ reg = <00100000 00040000>;
+ };
+ kernel@140000 {
+ label = "Kernel Image";
+ reg = <00140000 00400000>;
+ read-only;
+ };
+ fs@540000 {
+ label = "Filesystem";
+ reg = <00540000 039c0000>;
+ read-only;
+ };
+ fw@3f00000 {
+ label = "FW Image B";
+ reg = <03f00000 00100000>;
+ read-only;
+ };
};
mdio {
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index e484cac..a356a19 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -14,6 +14,7 @@
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/seq_file.h>
+#include <linux/of_platform.h>
#include <asm/machdep.h>
#include <asm/prom.h>
@@ -68,6 +69,18 @@ static void __init prpmc2800_setup_arch(void)
printk("Motorola %s\n", prpmc2800_platform_name);
}
+static int __init prpmc2800_register_mtd(void)
+{
+ struct device_node *np = NULL;
+
+ while ((np = of_find_compatible_node(np, NULL, "cfi-flash")) != NULL)
+ of_platform_device_create(np, NULL, NULL);
+
+ of_node_put(np);
+ return 0;
+}
+device_initcall(prpmc2800_register_mtd);
+
static void prpmc2800_reset_board(void)
{
u32 temp;
^ permalink raw reply related
* [PATCH 2/2] powerpc: prpmc2800 - Don't overwrite user FLASH size
From: Mark A. Greer @ 2007-10-25 23:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071025233948.GA22703@mag.az.mvista.com>
From: Mark A. Greer <mgreer@mvista.com>
The prpmc2800 bootwrapper code currently overwrites the DTS' user FLASH
size with a predetermined value. Intead make it use whatever is specified
in the DTS unless the prpmc2800 variant the bootwrapper is running on has
no user FLASH. In that case, set the user FLASH size to 0.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
arch/powerpc/boot/prpmc2800.c | 54 ++++++++++++++++----------------
1 file changed, 28 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/boot/prpmc2800.c b/arch/powerpc/boot/prpmc2800.c
index 9614e1d..a8b3213 100644
--- a/arch/powerpc/boot/prpmc2800.c
+++ b/arch/powerpc/boot/prpmc2800.c
@@ -58,7 +58,7 @@ struct prpmc2800_board_info {
u32 core_speed;
u32 mem_size;
u32 boot_flash;
- u32 user_flash;
+ u8 has_user_flash;
};
static struct prpmc2800_board_info prpmc2800_board_info[] = {
@@ -73,7 +73,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -86,7 +86,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 0,
- .user_flash = 0,
+ .has_user_flash = 0,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -99,7 +99,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 733*MHz,
.mem_size = 512*MB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -112,7 +112,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 1*GB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -125,7 +125,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -138,7 +138,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 733*MHz,
.mem_size = 128*MB,
.boot_flash = 1*MB,
- .user_flash = 0,
+ .has_user_flash = 0,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -151,7 +151,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 256*MB,
.boot_flash = 1*MB,
- .user_flash = 0,
+ .has_user_flash = 0,
},
{
.model = BOARD_MODEL_PRPMC280,
@@ -164,7 +164,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 1*GB,
.boot_flash = 1*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -177,7 +177,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 2*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -190,7 +190,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 0,
- .user_flash = 0,
+ .has_user_flash = 0,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -203,7 +203,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 733*MHz,
.mem_size = 512*MB,
.boot_flash = 2*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -216,7 +216,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 1*GB,
.boot_flash = 2*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -229,7 +229,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 512*MB,
.boot_flash = 2*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -242,7 +242,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 733*MHz,
.mem_size = 128*MB,
.boot_flash = 2*MB,
- .user_flash = 0,
+ .has_user_flash = 0,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -255,7 +255,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 1*GHz,
.mem_size = 2*GB,
.boot_flash = 2*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
{
.model = BOARD_MODEL_PRPMC2800,
@@ -268,7 +268,7 @@ static struct prpmc2800_board_info prpmc2800_board_info[] = {
.core_speed = 733*MHz,
.mem_size = 1*GB,
.boot_flash = 2*MB,
- .user_flash = 64*MB,
+ .has_user_flash = 1,
},
};
@@ -451,15 +451,17 @@ static void prpmc2800_fixups(void)
setprop(devp, "model", "mv64362", strlen("mv64362") + 1);
}
- /* Set User FLASH size */
- devp = finddevice("/mv64x60/flash@a0000000");
- if (devp == NULL)
- fatal("Error: Missing User FLASH device tree node\n\r");
- rc = getprop(devp, "reg", v, sizeof(v));
- if (rc != sizeof(v))
- fatal("Error: Can't find User FLASH reg property\n\r");
- v[1] = bip->user_flash;
- setprop(devp, "reg", v, sizeof(v));
+ /* Some PrPMC2800 variants have no User FLASH */
+ if (!bip->has_user_flash) {
+ devp = finddevice("/mv64x60/flash@a0000000");
+ if (devp != NULL) {
+ rc = getprop(devp, "reg", v, sizeof(v));
+ if (rc == sizeof(v)) {
+ v[1] = 0;
+ setprop(devp, "reg", v, sizeof(v));
+ }
+ }
+ }
}
#define MV64x60_MPP_CNTL_0 0xf000
^ permalink raw reply related
* Re: [PATCH v4] FEC - fast ethernet controller for mpc52xx
From: Stephen Hemminger @ 2007-10-25 23:50 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: netdev, Domen Puncer, linuxppc-dev
In-Reply-To: <20071025202908.GA2102@xyzzy.farnsworth.org>
On Thu, 25 Oct 2007 13:29:08 -0700
"Dale Farnsworth" <dale@farnsworth.org> wrote:
> On Thu, Oct 25, 2007 at 09:41:14PM +0200, Domen Puncer wrote:
> > On 25/10/07 11:57 -0700, Dale Farnsworth wrote:
> > > Domen wrote:
> > > > > use your platform's dma mapping functions, rather than virt_to_phys()
> > > > >
> > > > > it might be the exact same implementation, inside the platform
> > > > > internals, but drivers should not be using this directly.
> > > >
> > > > I've replaced this with dma_map_single(), unmatched with
> > > > dma_unmap_single(), since bestcomm doesn't have a way to do that
> > > > and it's blank on ppc32 anyway.
> > > >
> > > > Is this OK? PPC guys?
> > >
> > > Even though dma_unmap_single() may be a no-op, calls to
> > > dma_map_single() must be matched with calls to dma_unmap_single().
> > >
> > > Perhaps with the additions below:
> > >
> > > > +static void mpc52xx_fec_free_rx_buffers(struct bcom_task *s)
> > > > +{
> > > > + struct sk_buff *skb;
> > > > +
> > > > + while (!bcom_queue_empty(s)) {
> > > > + skb = bcom_retrieve_buffer(s, NULL, NULL);
> > >
> > > dma_unmap_single(&skb->dev->dev, skb-data,
> > > FEC_RX_BUFFER_SIZE, DMA_FROM_DEVICE);
> >
> > It looks to me like dma_unmap_single takes the mapped address
> > (what dma_map_single returned), and not the address we're mapping
> > (skb->data).
>
> Yeah. Sorry. That won't be so easy. We'll either need to
> squirrel away the mapped address, or change the interface to
> bcom_retrieve_buffers() so we can get the address.
>
> IMO, it's still a requirement that we call dma_unmap_single() for
> each call to dma_map_single().
>
There exist some macro's for pci stuff to handle the nop case well
see: pci_unmap_addr(), pci_unmap_len().
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: prpmc2800 - Add MTD support
From: Stephen Rothwell @ 2007-10-26 0:23 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20071025233948.GA22703@mag.az.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 650 bytes --]
Hi Mark,
On Thu, 25 Oct 2007 16:39:48 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
>
> +static int __init prpmc2800_register_mtd(void)
> +{
> + struct device_node *np = NULL;
^^^^^^^
Not needed if you use for_each_compatible_node().
> +
> + while ((np = of_find_compatible_node(np, NULL, "cfi-flash")) != NULL)
for_each_compatible_node(np, NULL, "cfi-flash")
> + of_platform_device_create(np, NULL, NULL);
> +
> + of_node_put(np);
Not needed as np must be NULL when you get here.
--
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: [PATCH 1/2] powerpc: prpmc2800 - Add MTD support
From: Mark A. Greer @ 2007-10-26 1:06 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071026102353.b837423b.sfr@canb.auug.org.au>
On Fri, Oct 26, 2007 at 10:23:53AM +1000, Stephen Rothwell wrote:
> Hi Mark,
>
> On Thu, 25 Oct 2007 16:39:48 -0700 "Mark A. Greer" <mgreer@mvista.com> wrote:
> >
> > +static int __init prpmc2800_register_mtd(void)
> > +{
> > + struct device_node *np = NULL;
> ^^^^^^^
> Not needed if you use for_each_compatible_node().
>
> > +
> > + while ((np = of_find_compatible_node(np, NULL, "cfi-flash")) != NULL)
>
> for_each_compatible_node(np, NULL, "cfi-flash")
>
> > + of_platform_device_create(np, NULL, NULL);
> > +
> > + of_node_put(np);
>
> Not needed as np must be NULL when you get here.
Ah, yes, true on all points. Thanks Stephen.
Update coming shortly...
Mark
^ permalink raw reply
* Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
From: David Gibson @ 2007-10-26 1:28 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1Il7O5-00036T-Iy@jdl.com>
On Thu, Oct 25, 2007 at 01:24:57PM -0500, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> > > Use of "d#', "o#", "h#" and "b#" are gone in version 1.
> >
> > Also good. We might want to keep b#, since there's no C way of doing
> > binary literals, but in that case I'd suggest recognizing it at the
> > lexical level, not the grammar level as we do now (which would mean a
> > space between the b# and the digits would no longer be permissible).
>
> I added 0(b|B)[01]+ literal support.
Ok.
[snip]
> > Therefore, I'd prefer that instead of having this general version
> > number, we introduce a separate token for each new version. So
> > /dts-version-1/ or whatever. Any new, incompatible, dts version is a
> > big deal in any case - not something we want to happen often - so a
> > new token for each version is not a big deal, I think. With this
> > approach, the version flag can be tripped in the lexer, and the
> > ordering of lexer rule execution is obvious.
>
> I don't see how this will work at the purely lexical level in
> a reliable way. Sure, I see the lexer matching the token and
> setting some variable (dts_version = 0 or 1) as needed.
> But there is no really good way to enforce that this happens at
> an early enough state that it covers the rest of the file short
> of having a staged lexical context state machine. And that just
> seems way hacky to me.
>
> With it in the grammar, we can enforce it being early in the file
> and can be assured of it happening in time to affect the rest of
> the parse. Personally, I think having it be a general statement
> like:
Ah... I think I see the source of our misunderstanding. Sorry if I
was unclear. I'm not saying that the version token would be
invisible to the parser, just that it would be recognized by the lexer
first.
So, the grammar would still need to specify that the magic version
token comes first, of course. A file which had it in the middle would
lex very strangely, but it wouldn't matter because it will never pass
the parser anyway.
> /<option>/ <value> ;
>
> makes a whole lot more sense than having the purely lexical
> context. Future versions of the DTS files will be syntactically
> correct even when moving to a (now) hypothetical version 2 file.
I see that as bad thing not a good thing. The only reason to bump the
version number is for *incompatible* source changes - that's why we're
doing it now, because the new representation would be ambiguous with
the current representation without something specifying which we're
using. Therefore future files *shouldn't* be syntactically correct
with a current parser.
The nice thing about having a token, is that if necessary we can
completely change the grammar for each version, without having to have
tangled rules that have to generate yyerror()s in some circumstances
depending on the version variable. The alternate grammars can be
encoded directly into the yacc rules:
startsymbol : version0_file
| V1_TOKEN version1_file
| V2_TOKEN version2_file
;
> > I'm also inclined to leave the syntax for bytestrings as it is, in
>
> Why? Why not be allowed to form up a series of expressions
> that make up a byte string? Am I missing something obvious here?
Because part of the point of bytestrings is to provide representation
for binary data. For a MAC address, say
[0x00 0x0a 0xe4 0x2c 0x23 0x1f]
is way bulkier than
[000ae42c231f]
And in bytestring context, I suspect having every expression result be
truncated to bytesize will be way more of a gotcha than in cell
context.
I suspect we can get the expression flexibility we want here by
providing the right operators to act *on* bytestrings, rather than
within bytestrings.
[snip]
> > > +u64 expr_from_string(char *s, unsigned int base)
> > > +{
> > > + u64 v;
> > > + char *e;
> > > +
> > > + v = strtoull(s, &e, base);
> > > + if (*e) {
> > > + fprintf(stderr,
> > > + "Line %d: Invalid literal value '%s' : "
> > > + "%c is not a base %d digit; %lld assumed\n",
> > > + yylloc.first_line, s, *e,
> > > + base == 0 ? expr_default_base : base,
> > > + (unsigned long long) v);
> >
> > Do we need this error checking? Won't the regexes mean that the
> > string *must* be a valid literal by this point?
>
> It's still needed for the legacy bits where you have modified
> the base for the following numbers. Specifically, you can say
> something like "d# 123abc" and it will scan lexically, but
> not be correct semantically still. Blah.
Uh, yeah, that. And as I realised afterwards also in case some one
writes 09999. The latter can be banned in the grammar, but not doing
so will give better error messages (e.g. "invalid digits in octal
literal" instead of "syntax error").
Actually, possibly we should make the literal regex allow [0-9a-zA-Z]
after the initial digit or 0x, so that 0xabcdzoom gives an error,
rather than parsing as a literal followed by a name, which could be
confusing to say the least. Of course that will make the literal/name
ambiguity worse (see below).
> > > @@ -46,25 +47,27 @@ extern struct boot_info *the_boot_info;
> > > int hexlen;
> > > u64 addr;
> > > struct reserve_info *re;
> > > + u64 ire;
> >
> > What's "ire" supposed to be short for?
>
> Oh, longer term. I have a intermediate representation for
> expressions up my sleeve. Sorry, wasn't clear there...
Hrm. I think just exprval or intval would be better. Actually
probably intval, since last we spoke I though we were planning on
having expressions of string and bytestring types as well.
> > > + | label DT_MEMRESERVE expr '-' expr ';'
> >
> > Oh.. you haven't actually abolished the '-' syntax, even in version 1
> > mode. Since we're already making an incompatible syntax change, we
> > should really make this one at the same time.
>
> I can make that fail, no problem.
Incidentally, there's another problem here: we haven't solved the
problem about having to allow property names with initial digits.
That's a particular problem here, because although we can make
literals scanned in preference to propnames of the same length, in
this case
0x1234..0xabcd
Will be scanned as one huge propname.
This might work for you at the moment, if you've still got all the
lexer states, but I was really hoping we could ditch most of them with
the new literals.
> > > +cell:
> > > + expr
> > > + {
> > > + $$ = expr_cell_value($1);
> > > + }
> > > + ;
> > > +
> > > +expr:
> > > + expr_primary
> > > + ;
> > > +
> > > +expr_primary:
> > > + opt_cell_base DT_LITERAL
> > > + {
> > > + $$ = $2;
> > > + }
> >
> > Hrm. I realise you haven't actually implemented expressions here, but
>
> Right. Initial framework....
But you haven't actually addressed my concern about this. Actually
it's worse that I said then, because
<0x10000000 -999>
is ambiguous. Is it a single subtraction expression, or one literal
cell followed by an expression cell with a unary '-'?
[snip]
> > > +unsigned int dts_version = 0;
> > > +unsigned int expr_default_base = 10;
> > > +
> > > +
> > > +void set_dts_version(u64 vers)
> > > +{
> > > + if (vers > 1) {
> > > + yywarn("Unknown version %lld; 0 assumed\n", vers);
> > > + dts_version = 0;
> > > + } else {
> > > + dts_version = vers;
> > > + }
> > > +
> > > + if (dts_version == 0) {
> > > + expr_default_base = 16;
> > > + in_lexer_use_base = 16;
> > > + } else {
> > > + expr_default_base = 10;
> > > + in_lexer_use_base = 10;
> >
> > Uh.. I don't think we should need either of expr_default_base and
> > in_lexer_use_base, let alone both..
>
> You need to temporarily know what the base of the next number
> will be for "d#"-like constructs, and then you need to know
> what to revert to again (default). Sure, we could consult the
> dts_version again directly at that time if you'd rather.
Yeah, I figured this out after. Youch, an even tighter and harder to
follow coupling between lexer and parser execution order. I can think
of at least two better ways to do this.
1) handle d# b# etc. at the lexer lexel, with a regex like
(d#{WS}*[0-9]+). Strictly speaking that changes the language, but I
don't think anyone's been insane enough to do something like "d#
/*stupid comment*/ 999". That would remove the whole ugly
opt_cell_base tangle from the grammar.
2) Have the lexer just pass up literals as strings, and let the parser
do the conversion to integer, based on the grammatical context. I
think this is preferable because it has other advantages: we can do
the distinction between 64-bit values for memreserve and 32-bit values
for cell at the grammatical level. It can also be used to handle the
propname/literal ambiguity without lexer states (I had a patch a while
back which removed the MEMRESERVE and CELLDATA lex states using this
technique).
> > > - fprintf(f, "%x", be32_to_cpu(*cp++));
> > > + if (dts_version == 0) {
> >
> > Where does dts_version get set in the -Odts case?
>
> The same call to set_dts_version() as any other case.
Erm... which same call to set_dts_version()? Surely not the one in
the parser..
--
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
* Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
From: David Gibson @ 2007-10-26 1:33 UTC (permalink / raw)
To: Marian Balakowicz; +Cc: linuxppc-dev, Martin Krause
In-Reply-To: <4720BA4B.5090707@semihalf.com>
On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote:
> Grant Likely wrote:
> > On 10/25/07, Martin Krause <Martin.Krause@tqs.de> wrote:
[snip]
> >> On a board with 16 MiB FLASH for example the "big-fs" _and_ the "misc"
> >> partition could not be used. "big-fs", because the memory is too small
> >> (which is OK) and "misc", because it overlaps 1 MiB over the physikal
> >> flash border. So only the first 9 MiB of the flash could be used in Linux.
> >> The remaining 7 MiB couldn't be accessed.
> >
> > Perhaps it would be better to drop the flash layout from the in-kernel
> > dts files entirely since flash layout can be a fluid thing.
>
> Well, but that would not be really user friendly, I'd rather stick
> with some default config.
Strictly speaking the device-tree is not the right place for flash
partitioning information. We put it there because it's preferable to
having hardcoded per-board flash layouts in the code itself.
It only really works well, though, when there are strong conventions
(shared with the firmware) about how to partition the flash.
Where it's really up to the user to determine how they want to lay out
their flash, putting things in the device tree isn't a really good
idea.
Incidentally, it's not required that *all* the flash address space be
in partitions, so it is possible only give partitions for those flash
chunks which the firmware needs to know about.
--
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
* Re: Apparent kernel bug with GDB on ppc405
From: Benjamin Herrenschmidt @ 2007-10-26 1:46 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071024194640.GB19691@waste.org>
On Wed, 2007-10-24 at 14:46 -0500, Matt Mackall wrote:
>
> My first suspicion was a dcache/icache coherency issue in
> copy_to_user_page, so I added flush_dcache_icache_page(page) here to
> no avail. On closer inspection, it looks like both icache and dcache
> are already being flushed by flush_icache_user_range().
>
> Adding printk(".") (or any printk) in this function here fixes things
> (serial console at 115k), while printk("") and udelay(100) do not.
> Which still suggests an icache bug..?
>
> Any suggestions?
I think you're hitting a known bug of 44x support. Those CPUs have a
crazy virtually tagged icache and the kernel doesn't deal with it at all
(pretty much...). We just are lucky things generally work :-)
That means among other things that flush_icache_* will not work because
they kmap pages and use that mapping. The only way to flush icache user
pages with 44x is to actually flush with the user virtual address
(meaning you have to be in the current context, and you probably need to
have a TLB entry there... yuck)... or just blow the whole icache away.
Try sticking an iccci in there and let me know if that helps.
Ben
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Benjamin Herrenschmidt @ 2007-10-26 1:50 UTC (permalink / raw)
To: Grant Likely; +Cc: gdb, linuxppc-embedded, Matt Mackall
In-Reply-To: <fa686aa40710241540y498b0c92le63920862d6b9315@mail.gmail.com>
On Wed, 2007-10-24 at 16:40 -0600, Grant Likely wrote:
> On 10/24/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > > Not completely implausible, but a) why isn't this seen on basically
> > > every machine with software TLB? b) why does -local- GDB, which is
> > > presumably doing much less work than gdbserver + network stack, not fail?
> >
> > a) I don't know.... very odd.
> >
> > b) gdb is big. It probably touches far more pages (via library calls)
> > than gdbserver. The network stack is also big, but it's probably more
> > localized too.
> >
> > Niceing down the host also makes sense because if the PC is being slow
> > then the target may go off and run other things while between setting
> > the breakpoint and getting the 'go' command.
> >
> > Can you grab a snapshot of the TLB before and after setting the breakpoint?
>
> Or; probably more relevant, before and after the page copy?
COW does ptep_clear_flush before setting the new TLB which does a
flush_tlb_page() so that should work.
Ben.
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Benjamin Herrenschmidt @ 2007-10-26 1:51 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb, linuxppc-embedded, Matt Mackall
In-Reply-To: <20071024224130.GA30819@caradoc.them.org>
On Wed, 2007-10-24 at 18:41 -0400, Daniel Jacobowitz wrote:
> On Wed, Oct 24, 2007 at 05:32:50PM -0500, Matt Mackall wrote:
> > Not completely implausible, but a) why isn't this seen on basically
> > every machine with software TLB? b) why does -local- GDB, which is
> > presumably doing much less work than gdbserver + network stack, not fail?
>
> You said it yourself. Local gdb does more work -> blows through more
> TLB entries.
>
> I can't answer you about the other half, but I'm pretty sure TLB
> invalidation is already supposed to be happening... somewhere.
Yes. do_wp_page() -> ptep_clear_flush() -> flush_tlb_page()
Ben.
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Benjamin Herrenschmidt @ 2007-10-26 1:52 UTC (permalink / raw)
To: David Daney; +Cc: gdb, linuxppc-embedded, Matt Mackall
In-Reply-To: <471FAC48.1070008@avtrex.com>
On Wed, 2007-10-24 at 13:34 -0700, David Daney wrote:
> First of all I have never used a similar configuration so this may be
> totally off base. But...
>
> If the icache is virtually indexed, then I think there are only two
> ways
> to invalidate it. The first is from the context of the debugged
> process
> where the page is mapped at the location the target program will see
> it.
> If you try to invalidate from the context of the debugger, the
> page
> will most likely not be mapped at the virtual address of the target
> program so you might have to invalidate the *entire* icache.
Yup, sounds likely. We don't handle that virtual icache well at all in
linux. Things tend to work by mere luck. I have various ideas to fix
that but haven't actually implemented them.
Ben.
^ permalink raw reply
* [PATCH v2 1/2] powerpc: prpmc2800 - Add MTD support
From: Mark A. Greer @ 2007-10-26 2:19 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071025233948.GA22703@mag.az.mvista.com>
From: Mark A. Greer <mgreer@mvista.com>
Create necessary device nodes so that the MTD subsystem recognizes
the MTD entries in the prpmc2800's DTS file. Also bring MTD section
of the prpmc2800's DTS file up to the current DTS specification.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
With Stephen's comments addressed. Much nicer. Thanks again, Stephen.
arch/powerpc/boot/dts/prpmc2800.dts | 39 +++++++++++----
arch/powerpc/platforms/embedded6xx/prpmc2800.c | 12 ++++
2 files changed, 41 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/boot/dts/prpmc2800.dts b/arch/powerpc/boot/dts/prpmc2800.dts
index 297dfa5..24944ca 100644
--- a/arch/powerpc/boot/dts/prpmc2800.dts
+++ b/arch/powerpc/boot/dts/prpmc2800.dts
@@ -55,17 +55,36 @@
f2000000 f2000000 00040000>; /* Integrated SRAM */
flash@a0000000 {
- device_type = "rom";
- compatible = "direct-mapped";
- reg = <a0000000 4000000>; /* Default (64MB) */
- probe-type = "CFI";
+ compatible = "cfi-flash";
+ reg = <a0000000 04000000>;
bank-width = <4>;
- partitions = <00000000 00100000 /* RO */
- 00100000 00040001 /* RW */
- 00140000 00400000 /* RO */
- 00540000 039c0000 /* RO */
- 03f00000 00100000>; /* RO */
- partition-names = "FW Image A", "FW Config Data", "Kernel Image", "Filesystem", "FW Image B";
+ device-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ fw@0 {
+ label = "FW Image A";
+ reg = <00000000 00100000>;
+ read-only;
+ };
+ cfg@100000 {
+ label = "FW Config Data"; /* RW */
+ reg = <00100000 00040000>;
+ };
+ kernel@140000 {
+ label = "Kernel Image";
+ reg = <00140000 00400000>;
+ read-only;
+ };
+ fs@540000 {
+ label = "Filesystem";
+ reg = <00540000 039c0000>;
+ read-only;
+ };
+ fw@3f00000 {
+ label = "FW Image B";
+ reg = <03f00000 00100000>;
+ read-only;
+ };
};
mdio {
diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
index e484cac..2506f38 100644
--- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c
+++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c
@@ -14,6 +14,7 @@
#include <linux/delay.h>
#include <linux/interrupt.h>
#include <linux/seq_file.h>
+#include <linux/of_platform.h>
#include <asm/machdep.h>
#include <asm/prom.h>
@@ -68,6 +69,17 @@ static void __init prpmc2800_setup_arch(void)
printk("Motorola %s\n", prpmc2800_platform_name);
}
+static int __init prpmc2800_register_mtd(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "cfi-flash")
+ of_platform_device_create(np, NULL, NULL);
+
+ return 0;
+}
+device_initcall(prpmc2800_register_mtd);
+
static void prpmc2800_reset_board(void)
{
u32 temp;
^ permalink raw reply related
* Re: Apparent kernel bug with GDB on ppc405
From: Grant Likely @ 2007-10-26 2:45 UTC (permalink / raw)
To: benh; +Cc: gdb, linuxppc-embedded, Matt Mackall
In-Reply-To: <1193363202.7018.36.camel@pasglop>
On 10/25/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Wed, 2007-10-24 at 14:46 -0500, Matt Mackall wrote:
> >
> > My first suspicion was a dcache/icache coherency issue in
> > copy_to_user_page, so I added flush_dcache_icache_page(page) here to
> > no avail. On closer inspection, it looks like both icache and dcache
> > are already being flushed by flush_icache_user_range().
> >
> > Adding printk(".") (or any printk) in this function here fixes things
> > (serial console at 115k), while printk("") and udelay(100) do not.
> > Which still suggests an icache bug..?
> >
> > Any suggestions?
>
> I think you're hitting a known bug of 44x support. Those CPUs have a
> crazy virtually tagged icache and the kernel doesn't deal with it at all
> (pretty much...). We just are lucky things generally work :-)
>
> That means among other things that flush_icache_* will not work because
> they kmap pages and use that mapping. The only way to flush icache user
> pages with 44x is to actually flush with the user virtual address
> (meaning you have to be in the current context, and you probably need to
> have a TLB entry there... yuck)... or just blow the whole icache away.
This is actually 405. Does that have the same issue?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Benjamin Herrenschmidt @ 2007-10-26 3:23 UTC (permalink / raw)
To: Grant Likely; +Cc: gdb, linuxppc-embedded, Matt Mackall
In-Reply-To: <fa686aa40710251945l51604c5vdf0b49b03b9a1a57@mail.gmail.com>
> This is actually 405. Does that have the same issue?
hrm... I don't remember :-) There -is- something fishy about the icache
on 405 but I don't remember for sure. Try sticking an iccci in there and
tell us if that helps.
Ben.
^ 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