* ML405 gigabit ethernet with kernel 2.6.23
From: kentaro @ 2007-11-08 2:16 UTC (permalink / raw)
To: linuxppc-embedded
Dear all,
I have measured ethernet performance on ML405 with linux
kernel 2.6.23-rc2 which I obtained from the secreatlab.ca
git tree. I will post this e-mail because I would like to
share the data and besides I would like to ask something
about the performance.
In the past, similar e-mails are also posted to this mailing list;
http://ozlabs.org/pipermail/linuxppc-embedded/2007-June/027328.html
They are also helpful.
My hardware configuration :
-------------------------------------------------------------
ISE, EDK : 9.1SP3(IP update-3) 9.1SP2
-------------------------------------------------------------
Board : ML405
PPC frequency : 300 MHz
TEMAC : SG-DMA, TX/RX checksum offload
TX/RX FIFO depth = 131072
MAC length and Status FIFO Depth = 64
TX/RX DRE = 2
DDR Memory : Support PLB Bursts and Cache = TRUE
-------------------------------------------------------------
Basically, this configuration is exactly same as XAPP1023
except for BRAM. (I used 64k BRAM.) And with this configuration,
Xilinx achieved 400 Mbps ~ 500Mbps throughput with MontaVista
Linux 4.0. However, my results were
~110 Mbps (TCP) and ~200 Mbps (UDP). I guess the differences
came from linux configuration. Here are my linux setup.
-------------------------------------------------------------
kernel : 2.6.23-rc2 (from linux-2.6-virtex.git)
gcc, glibc : 4.0.2, 2.3.6
TX,RX threshold = 32, 8 and waitbound = 1, 1
-------------------------------------------------------------
Before compiling the kernel, I needed to modify a checksum
code in adapter.c because the checksum insert address was wrong.
Original (line 1076):
XTemac_mSgSendBdCsumSetup(bd_ptr, skb->transport_header
- skb->data, (skb->transport_header - skb->data) + skb->csum);
Modified :
XTemac_mSgSendBdCsumSetup(bd_ptr, skb_transport_offset(skb),
skb_transport_offset(skb) + skb->csum_offset);
I used "nerperf" to measure performance on the built kernel.
The results were
-------------------------------------------------------------
"netperf -H 192.168.1.1 -t TCP_STREAM" 110 Mbps
"netperf -H 192.168.1.1 -t UDP_STREAM" 210 Mbps
-------------------------------------------------------------
I have changed some netperf parameters but the results
didn't change so much. It seemed to me that the performance
was limited by CPU because "top" command told CPU usage was
99% (71% SYSTEM, 27% IRQ). If I lower the TX threshold down
to 16, the score becomes (~50% SYSTEM, ~40% IRQ).
Then, I changed MTU to 8000 (on both PC and ML405).
This made everything upset. Network became very unstable
and I couldn't run netperf successfully.
So, my question is
(1) Do I need to apply some optimization to the kernel sources
in order to achieve ~400 Mbps ? It seems to me the difference
comes from the kernel part.
(2) Does anyone have some MTU problem ? I'm very glad if I could
have advices.
Any suggestion is welcome.
Best regards,
Kentaro.
--------------------------------------------------------------------
PS:
For your interest, here I attach my /proc/profile info
obtained while running netperf.
=============== Netperf Test (TCP STREAM) ====================
394 __copy_tofrom_user 0.6888
208 invalidate_dcache_range 4.3333
196 clean_dcache_range 4.0833
173 XDmaV3_SgBdToHw 0.5149
152 tcp_sendmsg 0.0485
105 skb_clone 0.1862
71 tcp_transmit_skb 0.0380
71 ip_queue_xmit 0.0870
67 cpu_idle 0.3102
59 kfree 0.2588
57 tcp_cwnd_validate 0.4191
49 tcp_push_one 0.1551
49 kmem_cache_alloc 0.3063
45 ip_output 0.0622
44 tcp_ack 0.0067
42 xenet_SgSend_internal 0.0587
38 __alloc_skb 0.1418
36 pfifo_fast_enqueue 0.1579
33 __kmalloc 0.1375
30 memset 0.3261
28 _xenet_SgSetupRecvBuffers 0.0493
27 XTemac_IntrSgEnable 0.0938
23 skb_release_data 0.1150
22 tcp_rcv_established 0.0097
=============== Netperf Test (UDP STREAM) ====================
1426 csum_partial_copy_generic 6.4818
961 cpu_idle 4.4491
126 ip_fragment 0.0754
63 xenet_SgSend_internal 0.0880
58 memcpy 0.3718
50 memset 0.5435
48 XDmaV3_SgBdToHw 0.1429
48 __kmalloc 0.2000
46 ip_push_pending_frames 0.0451
38 kfree 0.1667
37 clean_dcache_range 0.7708
36 dev_queue_xmit 0.0536
33 __alloc_skb 0.1231
32 udp_push_pending_frames 0.0452
29 local_bh_enable 0.2071
29 ace_fsm_tasklet 0.3295
24 ip_append_data 0.0100
23 XTemac_SgCommit 0.1027
22 XDmaV3_SgBdAlloc 0.1964
21 skb_release_data 0.1050
21 kmem_cache_alloc 0.1313
20 ip_finish_output2 0.0365
19 XTemac_SgAlloc 0.0679
19 pfifo_fast_dequeue 0.1532
^ permalink raw reply
* Re: use of fsl, in lite5200b.dts in git current
From: Grant Likely @ 2007-11-08 3:14 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-embedded
In-Reply-To: <473258B8.4060905@genesi-usa.com>
On 11/7/07, Matt Sealey <matt@genesi-usa.com> wrote:
> Jon Smirl wrote:
> > I'm not in favor of all these fsl prefixes. These chip families do get
> > sold. What would we have done with intel,pxa320 all over the place
> > when they sold it to marvell? mass changes to marvell,pxa320?
>
> That's the idea, and there'd be a compatible entry for intel,pxa320.
>
> Actually the spec says you should use the stock ticker (IBM, FSL, INTC,
> JAVA, MRVL) if they have one and if not, the company name in lower case.
>
> Freescale are a funny one because they used to have a stock ticker as
> MOT and then FSL but now they're privately owned, so it's gonna have to
> be lower case :]
And really, this doesn't even matter. So what if 'mot,' --> 'fsl,'
--> 'freescale,'? Even if an older name is used, it is still
unambiguous and therefore a useful property.
Besides, If you're designing a device tree for a board, and Linux or
some other OS already has support for a similar board, it would be
madness to use property values different from what the OS already uses
just to make the values "more correct".
ie. even if Marvell sells the pxa255 for then next 5 years, it is
still correct to call it an "intel,pxa255".
> It's just to seperate out the fact that sometimes you get chips with
> very similar or identical names, or to mark out vendor-specific
> functionality. fsl,has-wdt differs from has-wdt ideally because
> Freescale watchdog timers aren't the same as other watchdog timers -
> the term is pretty pliable, Freescale's GPT on the MPC52xx isn't
> always a watchdog (it can be a normal, non-watchdog timer too..)
>
> > The mpc/pxa parts numbers don't get changes when chip families get sold.
>
> There is a case that between selling chips, some of them get updated
> or bugfixed, and you can tell which one you have by the name.
>
> There has to be some standardisation on the first implementation of
> the device tree for the chip, otherwise the chopping and changing
> gets rather tedious.
>
> I'm sure you can see why we don't release firmware updates every time
> some Linux guy changes some lousy, hacky tree definition for yet another
> 6 times a year, until it finally stabilises and the product is usually
> discontinued anyway :D
Oh come on; I've hardly changed the mpc5200 bindings at all since we
last talked about them... :-P (Totally joking, see comment and
eating-of-crow below).
>
> However in the current situation it just means you need to flash new
> FDT blobs to your U-Boots which are more clean, and keep your kernel
> in sync, because Linux only handles what it currently thinks is the
> standard.
>
> The real loser is the real Open Firmware implementation, but nobody
> seems to think about that, the device trees on OF devices get more
> cluttered..
Not quite true; I personally am now quite loath to changing
conventions without maintaining compatibility with the old. I also
tend to make the assumption that upgrading the kernel should not
always require a device tree upgrade also.
In other words:
Changing conventions to better match the OF guidelines: possibly a
good thing, especially if it results in more clarity.
--- but ---
Breaking boards with trees that follow older conventions: Bad!
This is probably a good time for me to apologize for the pain that
I've caused in the past on this issue. My stance in the past on
designing mpc5200 device trees was wrong headed on a couple of points.
First, insisting that the Efika device tree should exactly match what
was currently in vogue was wrong. Second, assuming that it was even
possible to define a 'perfect' and 'exact' mpc5200 device tree binding
was pure hubris.
So, I'm sorry and I apologize. Experience has taught me better over
the past year.
I'm now of the opinion that device trees are *never* perfect, and
that's not even the point. The point is that a device tree should
uniquely and unambiguously describe the platform. If the device tree
isn't quite unambiguous in one aspect, other aspects of the tree will
provide enough information to work around what is lacking. Every
device driver may have a current-as-of-now idea on what those
properties should look like, but that should not cause platforms with
device trees which differ from that to be punted as unsupportable.
I do not think that means that vendors can put whatever they want into
a device tree without regard to current conventions (at the time of
designing their tree). Doing so generally causes friction with the
folks who are writing software for it (and I'm not directing this
comment at bPlan either). But I do think that changing conventions
must always be done with care and without breaking earlier users;
either by modifying the tree at platform setup time or retaining
compatibility with the old property name.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH (2.6.25) 2/2] suspend: clean up Kconfig
From: Paul Mackerras @ 2007-11-08 2:30 UTC (permalink / raw)
To: Johannes Berg
Cc: Bryan Wu, linux-mips, Ralf Baechle, Rafael J. Wysocki,
linuxppc-dev, Paul Mundt, linux-pm, Guennadi Liakhovetski,
Russell King
In-Reply-To: <20071107135849.207149000@sipsolutions.net>
Johannes Berg writes:
> This cleans up the suspend Kconfig and removes the need to
> declare centrally which architectures support suspend. All
> architectures that currently support suspend are modified
> accordingly.
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH (2.6.25) 1/2] hibernation: clean up Kconfig
From: Paul Mackerras @ 2007-11-08 2:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: Rafael J. Wysocki, linuxppc-dev, linux-pm
In-Reply-To: <20071107135848.417344000@sipsolutions.net>
Johannes Berg writes:
> This cleans up the hibernation Kconfig and removes the need to
> declare centrally which architectures support hibernation. All
> architectures that currently support hibernation are modified
> accordingly.
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: mm snapshot broken-out-2007-11-06-02-32 build failure - !CONFIG_PPC_ISERIES
From: Tony Breeds @ 2007-11-08 2:27 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, akpm, mm-commits, linux-kernel
In-Reply-To: <473226A3.7090704@linux.vnet.ibm.com>
On Thu, Nov 08, 2007 at 02:27:07AM +0530, Kamalesh Babulal wrote:
> Hi Andrew,
>
> The kernel build fails with randconfig, with following error
>
> CC arch/powerpc/platforms/celleb/setup.o
> arch/powerpc/platforms/celleb/setup.c:151: error: ‘generic_calibrate_decr’ undeclared here (not in a function)
> make[2]: *** [arch/powerpc/platforms/celleb/setup.o] Error 1
> make[1]: *** [arch/powerpc/platforms/celleb] Error 2
> make: *** [arch/powerpc/platforms] Error 2
I think you need this patch:
http://patchwork.ozlabs.org/linuxppc/patch?q=Tony%20Breeds&id=14462
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [RFC] Modifying i2c-core to support alias driver names compatible with device trees
From: Jon Smirl @ 2007-11-08 2:18 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Jean Delvare, Tjernlund, i2c, linuxppc-dev
In-Reply-To: <20071108120535.769e4d73.sfr@canb.auug.org.au>
On 11/7/07, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Tue, 6 Nov 2007 15:39:42 -0500 "Jon Smirl" <jonsmirl@gmail.com> wrote:
> >
> > It was requested to split this code out into a separate thread....
> >
> > This code modifies the i2c-core to support lists of alias names in the
> > chip drivers.
> > For example: .aliases = (char const
> > *[]){"ricoh,rs5c372a","ricoh,rs5c372b","ricoh,rv5c386","ricoh,rv5c387a",
> > 0},
>
> You should not need the (char const *[]) casts at all.
That is what I thought but the compiler complains without it. I tried
everything I could think of to get rid of it.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: use of fsl, in lite5200b.dts in git current
From: Jon Smirl @ 2007-11-08 2:15 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-embedded
In-Reply-To: <473258B8.4060905@genesi-usa.com>
On 11/7/07, Matt Sealey <matt@genesi-usa.com> wrote:
> Jon Smirl wrote:
> > I'm not in favor of all these fsl prefixes. These chip families do get
> > sold. What would we have done with intel,pxa320 all over the place
> > when they sold it to marvell? mass changes to marvell,pxa320?
>
> That's the idea, and there'd be a compatible entry for intel,pxa320.
The vendor part really isn't needed and it is going to be a source of
trouble. The vendors are smart enough not to create two chips with the
same part number. Adding a vendor qualifier complicates things
needlessly.
>
> Actually the spec says you should use the stock ticker (IBM, FSL, INTC,
> JAVA, MRVL) if they have one and if not, the company name in lower case.
>
> Freescale are a funny one because they used to have a stock ticker as
> MOT and then FSL but now they're privately owned, so it's gonna have to
> be lower case :]
Another example of how these vendor prefixes can change. The chip
numbers are never going to change. Just use them and drop these vendor
prefixes.
> It's just to separate out the fact that sometimes you get chips with
> very similar or identical names, or to mark out vendor-specific
You don't get chips with identical names. If they had identical names
you couldn't order them from a distributor. Similar yes, identical no.
> functionality. fsl,has-wdt differs from has-wdt ideally because
This one I can buy, but it should be fsl-has-wdt. Drop the vendor prefixes.
> Freescale watchdog timers aren't the same as other watchdog timers -
> the term is pretty pliable, Freescale's GPT on the MPC52xx isn't
> always a watchdog (it can be a normal, non-watchdog timer too..)
>
> > The mpc/pxa parts numbers don't get changes when chip families get sold.
>
> There is a case that between selling chips, some of them get updated
> or bug fixed, and you can tell which one you have by the name.
You can always tell which one you have. The vendors add suffixes to
the part numbers so that you can identify the steppings.
>
> There has to be some standardization on the first implementation of
> the device tree for the chip, otherwise the chopping and changing
> gets rather tedious.
>
> I'm sure you can see why we don't release firmware updates every time
> some Linux guy changes some lousy, hacky tree definition for yet another
> 6 times a year, until it finally stabilizes and the product is usually
> discontinued anyway :D
That's life in the Linux world, no backwards binary compatibility. I'm
in favor of the model since we can fix things until with get the right
instead of piling hacks upon hacks trying to keep ancient, broken
interfaces working (I used to work on the Windows kernel. it is major
ugly).
> However in the current situation it just means you need to flash new
> FDT blobs to your U-Boots which are more clean, and keep your kernel
> in sync, because Linux only handles what it currently thinks is the
> standard.
>
> The real loser is the real Open Firmware implementation, but nobody
> seems to think about that, the device trees on OF devices get more
> cluttered.
Open Firmware lost when it initially came out closed source and people
charged for it. uBoot/redboot/etc took the market because they were
open and free. If Open Firmware had been a free implementation from
day one things would have ended up differently.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH 3/3] powerpc: mv64x60 - Aesthetic fixups for bootwrapper code
From: Mark A. Greer @ 2007-11-08 1:58 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071108015415.GA14900@mag.az.mvista.com>
From: Mark A. Greer <mgreer@mvista.com>
Specify locations when initializing arrays. This has already been done
for one array so may as well do it for them all.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
I don't know if this one is worth the bother (it is a little anal)
but it keeps things consistent. I'm happy with or without it.
arch/powerpc/boot/mv64x60.c | 72 +++++++++++++++++-----------------
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/boot/mv64x60.c b/arch/powerpc/boot/mv64x60.c
index ddddc3f..d207a0b 100644
--- a/arch/powerpc/boot/mv64x60.c
+++ b/arch/powerpc/boot/mv64x60.c
@@ -174,11 +174,11 @@ struct {
u32 addr;
u32 data;
} static mv64x60_pci_cfgio[2] = {
- { /* hose 0 */
+ [0] = { /* hose 0 */
.addr = 0xcf8,
.data = 0xcfc,
},
- { /* hose 1 */
+ [1] = { /* hose 1 */
.addr = 0xc78,
.data = 0xc7c,
}
@@ -201,76 +201,76 @@ void mv64x60_cfg_write(u8 *bridge_base, u8 hose, u8 bus, u8 devfn, u8 offset,
/* I/O ctlr -> system memory setup */
static struct mv64x60_mem_win mv64x60_cpu2mem[MV64x60_CPU2MEM_WINDOWS] = {
- {
+ [0] = {
.lo = MV64x60_CPU2MEM_0_BASE,
.size = MV64x60_CPU2MEM_0_SIZE,
},
- {
+ [1] = {
.lo = MV64x60_CPU2MEM_1_BASE,
.size = MV64x60_CPU2MEM_1_SIZE,
},
- {
+ [2] = {
.lo = MV64x60_CPU2MEM_2_BASE,
.size = MV64x60_CPU2MEM_2_SIZE,
},
- {
+ [3] = {
.lo = MV64x60_CPU2MEM_3_BASE,
.size = MV64x60_CPU2MEM_3_SIZE,
},
};
static struct mv64x60_mem_win mv64x60_enet2mem[MV64x60_CPU2MEM_WINDOWS] = {
- {
+ [0] = {
.lo = MV64x60_ENET2MEM_0_BASE,
.size = MV64x60_ENET2MEM_0_SIZE,
},
- {
+ [1] = {
.lo = MV64x60_ENET2MEM_1_BASE,
.size = MV64x60_ENET2MEM_1_SIZE,
},
- {
+ [2] = {
.lo = MV64x60_ENET2MEM_2_BASE,
.size = MV64x60_ENET2MEM_2_SIZE,
},
- {
+ [3] = {
.lo = MV64x60_ENET2MEM_3_BASE,
.size = MV64x60_ENET2MEM_3_SIZE,
},
};
static struct mv64x60_mem_win mv64x60_mpsc2mem[MV64x60_CPU2MEM_WINDOWS] = {
- {
+ [0] = {
.lo = MV64x60_MPSC2MEM_0_BASE,
.size = MV64x60_MPSC2MEM_0_SIZE,
},
- {
+ [1] = {
.lo = MV64x60_MPSC2MEM_1_BASE,
.size = MV64x60_MPSC2MEM_1_SIZE,
},
- {
+ [2] = {
.lo = MV64x60_MPSC2MEM_2_BASE,
.size = MV64x60_MPSC2MEM_2_SIZE,
},
- {
+ [3] = {
.lo = MV64x60_MPSC2MEM_3_BASE,
.size = MV64x60_MPSC2MEM_3_SIZE,
},
};
static struct mv64x60_mem_win mv64x60_idma2mem[MV64x60_CPU2MEM_WINDOWS] = {
- {
+ [0] = {
.lo = MV64x60_IDMA2MEM_0_BASE,
.size = MV64x60_IDMA2MEM_0_SIZE,
},
- {
+ [1] = {
.lo = MV64x60_IDMA2MEM_1_BASE,
.size = MV64x60_IDMA2MEM_1_SIZE,
},
- {
+ [2] = {
.lo = MV64x60_IDMA2MEM_2_BASE,
.size = MV64x60_IDMA2MEM_2_SIZE,
},
- {
+ [3] = {
.lo = MV64x60_IDMA2MEM_3_BASE,
.size = MV64x60_IDMA2MEM_3_SIZE,
},
@@ -338,7 +338,7 @@ void mv64x60_config_ctlr_windows(u8 *bridge_base, u8 *bridge_pbase,
/* PCI MEM -> system memory, et. al. setup */
static struct mv64x60_pci_win mv64x60_pci2mem[2][MV64x60_CPU2MEM_WINDOWS] = {
- { /* hose 0 */
+ [0] = { /* hose 0 */
[0] = {
.fcn = 0,
.hi = 0x14,
@@ -364,7 +364,7 @@ static struct mv64x60_pci_win mv64x60_pci2mem[2][MV64x60_CPU2MEM_WINDOWS] = {
.size = MV64x60_PCI02MEM_3_SIZE,
},
},
- { /* hose 1 */
+ [1] = { /* hose 1 */
[0] = {
.fcn = 0,
.hi = 0x94,
@@ -394,45 +394,45 @@ static struct mv64x60_pci_win mv64x60_pci2mem[2][MV64x60_CPU2MEM_WINDOWS] = {
static struct
mv64x60_mem_win mv64x60_pci_acc[2][MV64x60_PCI_ACC_CNTL_WINDOWS] = {
- { /* hose 0 */
- {
+ [0] = { /* hose 0 */
+ [0] = {
.hi = MV64x60_PCI0_ACC_CNTL_0_BASE_HI,
.lo = MV64x60_PCI0_ACC_CNTL_0_BASE_LO,
.size = MV64x60_PCI0_ACC_CNTL_0_SIZE,
},
- {
+ [1] = {
.hi = MV64x60_PCI0_ACC_CNTL_1_BASE_HI,
.lo = MV64x60_PCI0_ACC_CNTL_1_BASE_LO,
.size = MV64x60_PCI0_ACC_CNTL_1_SIZE,
},
- {
+ [2] = {
.hi = MV64x60_PCI0_ACC_CNTL_2_BASE_HI,
.lo = MV64x60_PCI0_ACC_CNTL_2_BASE_LO,
.size = MV64x60_PCI0_ACC_CNTL_2_SIZE,
},
- {
+ [3] = {
.hi = MV64x60_PCI0_ACC_CNTL_3_BASE_HI,
.lo = MV64x60_PCI0_ACC_CNTL_3_BASE_LO,
.size = MV64x60_PCI0_ACC_CNTL_3_SIZE,
},
},
- { /* hose 1 */
- {
+ [1] = { /* hose 1 */
+ [0] = {
.hi = MV64x60_PCI1_ACC_CNTL_0_BASE_HI,
.lo = MV64x60_PCI1_ACC_CNTL_0_BASE_LO,
.size = MV64x60_PCI1_ACC_CNTL_0_SIZE,
},
- {
+ [1] = {
.hi = MV64x60_PCI1_ACC_CNTL_1_BASE_HI,
.lo = MV64x60_PCI1_ACC_CNTL_1_BASE_LO,
.size = MV64x60_PCI1_ACC_CNTL_1_SIZE,
},
- {
+ [2] = {
.hi = MV64x60_PCI1_ACC_CNTL_2_BASE_HI,
.lo = MV64x60_PCI1_ACC_CNTL_2_BASE_LO,
.size = MV64x60_PCI1_ACC_CNTL_2_SIZE,
},
- {
+ [3] = {
.hi = MV64x60_PCI1_ACC_CNTL_3_BASE_HI,
.lo = MV64x60_PCI1_ACC_CNTL_3_BASE_LO,
.size = MV64x60_PCI1_ACC_CNTL_3_SIZE,
@@ -441,13 +441,13 @@ mv64x60_mem_win mv64x60_pci_acc[2][MV64x60_PCI_ACC_CNTL_WINDOWS] = {
};
static struct mv64x60_pci_win mv64x60_pci2reg[2] = {
- { /* hose 0 */
+ [0] = { /* hose 0 */
.fcn = 0,
.hi = 0x24,
.lo = 0x20,
.size = 0,
},
- { /* hose 1 */
+ [1] = { /* hose 1 */
.fcn = 0,
.hi = 0xa4,
.lo = 0xa0,
@@ -519,13 +519,13 @@ void mv64x60_config_pci_windows(u8 *bridge_base, u8 *bridge_pbase, u8 hose,
/* CPU -> PCI I/O & MEM setup */
struct mv64x60_cpu2pci_win mv64x60_cpu2pci_io[2] = {
- { /* hose 0 */
+ [0] = { /* hose 0 */
.lo = MV64x60_CPU2PCI0_IO_BASE,
.size = MV64x60_CPU2PCI0_IO_SIZE,
.remap_hi = 0,
.remap_lo = MV64x60_CPU2PCI0_IO_REMAP,
},
- { /* hose 1 */
+ [1] = { /* hose 1 */
.lo = MV64x60_CPU2PCI1_IO_BASE,
.size = MV64x60_CPU2PCI1_IO_SIZE,
.remap_hi = 0,
@@ -534,13 +534,13 @@ struct mv64x60_cpu2pci_win mv64x60_cpu2pci_io[2] = {
};
struct mv64x60_cpu2pci_win mv64x60_cpu2pci_mem[2] = {
- { /* hose 0 */
+ [0] = { /* hose 0 */
.lo = MV64x60_CPU2PCI0_MEM_0_BASE,
.size = MV64x60_CPU2PCI0_MEM_0_SIZE,
.remap_hi = MV64x60_CPU2PCI0_MEM_0_REMAP_HI,
.remap_lo = MV64x60_CPU2PCI0_MEM_0_REMAP_LO,
},
- { /* hose 1 */
+ [1] = { /* hose 1 */
.lo = MV64x60_CPU2PCI1_MEM_0_BASE,
.size = MV64x60_CPU2PCI1_MEM_0_SIZE,
.remap_hi = MV64x60_CPU2PCI1_MEM_0_REMAP_HI,
^ permalink raw reply related
* [PATCH 2/3] powerpc: prpmc2800 - Use new mv64x60_config_pci_windows() interface
From: Mark A. Greer @ 2007-11-08 1:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071108015415.GA14900@mag.az.mvista.com>
From: Mark A. Greer <mgreer@mvista.com>
Make the prpmc2800 bootwrapper code use the new interface to
mv64x60_config_pci_windows(). With that change, some minor code
rearrangement is possible to make things neater.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
arch/powerpc/boot/prpmc2800.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/boot/prpmc2800.c b/arch/powerpc/boot/prpmc2800.c
index 9614e1d..d72400d 100644
--- a/arch/powerpc/boot/prpmc2800.c
+++ b/arch/powerpc/boot/prpmc2800.c
@@ -315,7 +315,7 @@ static struct prpmc2800_board_info *prpmc2800_get_bip(void)
return bip;
}
-static void prpmc2800_bridge_setup(u32 mem_size)
+static void prpmc2800_bridge_setup(void)
{
u32 i, v[12], enables, acc_bits;
u32 pci_base_hi, pci_base_lo, size, buf[2];
@@ -340,8 +340,7 @@ static void prpmc2800_bridge_setup(u32 mem_size)
| MV64x60_PCI_ACC_CNTL_RDSIZE_256_BYTES;
mv64x60_config_ctlr_windows(bridge_base, bridge_pbase, is_coherent);
- mv64x60_config_pci_windows(bridge_base, bridge_pbase, 0, 0, mem_size,
- acc_bits);
+ mv64x60_config_pci_windows(bridge_base, bridge_pbase, 0, 0, acc_bits);
/* Get the cpu -> pci i/o & mem mappings from the device tree */
devp = finddevice("/mv64x60/pci@80000000");
@@ -397,20 +396,19 @@ static void prpmc2800_bridge_setup(u32 mem_size)
static void prpmc2800_fixups(void)
{
- u32 v[2], l, mem_size;
+ u32 v[2], l;
int rc;
void *devp;
char model[BOARD_MODEL_MAX];
struct prpmc2800_board_info *bip;
- bip = prpmc2800_get_bip(); /* Get board info based on VPD */
-
- mem_size = (bip) ? bip->mem_size : mv64x60_get_mem_size(bridge_base);
- prpmc2800_bridge_setup(mem_size); /* Do necessary bridge setup */
+ prpmc2800_bridge_setup(); /* Do necessary bridge setup */
- /* If the VPD doesn't match what we know about, just use the
+ /*
+ * If the VPD doesn't match what we know about, just use the
* defaults already in the device tree.
*/
+ bip = prpmc2800_get_bip(); /* Get board info based on VPD */
if (!bip)
return;
@@ -439,8 +437,8 @@ static void prpmc2800_fixups(void)
devp = finddevice("/memory");
if (devp == NULL)
fatal("Error: Missing /memory device tree node\n\r");
- v[0] = 0;
- v[1] = bip->mem_size;
+ v[0] = 0; /* Take min of DT's mem size and what mem ctlr is setup for */
+ v[1] = min(mv64x60_get_mem_size(bridge_base), bip->mem_size);
setprop(devp, "reg", v, sizeof(v));
/* Update /mv64x60/model, if this is a mv64362 */
^ permalink raw reply related
* [PATCH 1/3] powerpc: mv64x60 - Fix PCI MEM->System Mem window setup
From: Mark A. Greer @ 2007-11-08 1:54 UTC (permalink / raw)
To: linuxppc-dev
From: Mark A. Greer <mgreer@mvista.com>
The Marvell mv64x60 line of host bridges just don't like
PCI MEM->System Memory windows setups that don't match
the CPU->System Memory window setups. For example, if there
is 1GB of System Memory and 2 CPU->System Memory windows set up
for 512MB each, then there had better be 2 PCI->System Memory
windows set up for 512MB each as well.
This restriction was documented in early versions of the bridge
but isn't supposed to apply to recent versions. It seems as though
it still applies to recent versions as well.
mv64x60_config_pci_windows() is now changed to make the windows match
as described above.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
arch/powerpc/boot/mv64x60.c | 133 ++++++++++++++++++++++++----------
arch/powerpc/boot/mv64x60.h | 2
2 files changed, 96 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/boot/mv64x60.c b/arch/powerpc/boot/mv64x60.c
index b432594..ddddc3f 100644
--- a/arch/powerpc/boot/mv64x60.c
+++ b/arch/powerpc/boot/mv64x60.c
@@ -92,6 +92,9 @@
#define MV64x60_PCI0_BAR_ENABLE 0x0c3c
#define MV64x60_PCI02MEM_0_SIZE 0x0c08
+#define MV64x60_PCI02MEM_1_SIZE 0x0d08
+#define MV64x60_PCI02MEM_2_SIZE 0x0c0c
+#define MV64x60_PCI02MEM_3_SIZE 0x0d0c
#define MV64x60_PCI0_ACC_CNTL_0_BASE_LO 0x1e00
#define MV64x60_PCI0_ACC_CNTL_0_BASE_HI 0x1e04
#define MV64x60_PCI0_ACC_CNTL_0_SIZE 0x1e08
@@ -113,6 +116,9 @@
#define MV64x60_PCI1_BAR_ENABLE 0x0cbc
#define MV64x60_PCI12MEM_0_SIZE 0x0c88
+#define MV64x60_PCI12MEM_1_SIZE 0x0d88
+#define MV64x60_PCI12MEM_2_SIZE 0x0c8c
+#define MV64x60_PCI12MEM_3_SIZE 0x0d8c
#define MV64x60_PCI1_ACC_CNTL_0_BASE_LO 0x1e80
#define MV64x60_PCI1_ACC_CNTL_0_BASE_HI 0x1e84
#define MV64x60_PCI1_ACC_CNTL_0_SIZE 0x1e88
@@ -331,18 +337,58 @@ void mv64x60_config_ctlr_windows(u8 *bridge_base, u8 *bridge_pbase,
}
/* PCI MEM -> system memory, et. al. setup */
-static struct mv64x60_pci_win mv64x60_pci2mem[2] = {
+static struct mv64x60_pci_win mv64x60_pci2mem[2][MV64x60_CPU2MEM_WINDOWS] = {
{ /* hose 0 */
- .fcn = 0,
- .hi = 0x14,
- .lo = 0x10,
- .size = MV64x60_PCI02MEM_0_SIZE,
+ [0] = {
+ .fcn = 0,
+ .hi = 0x14,
+ .lo = 0x10,
+ .size = MV64x60_PCI02MEM_0_SIZE,
+ },
+ [1] = {
+ .fcn = 0,
+ .hi = 0x1c,
+ .lo = 0x18,
+ .size = MV64x60_PCI02MEM_1_SIZE,
+ },
+ [2] = {
+ .fcn = 1,
+ .hi = 0x14,
+ .lo = 0x10,
+ .size = MV64x60_PCI02MEM_2_SIZE,
+ },
+ [3] = {
+ .fcn = 1,
+ .hi = 0x1c,
+ .lo = 0x18,
+ .size = MV64x60_PCI02MEM_3_SIZE,
+ },
},
{ /* hose 1 */
- .fcn = 0,
- .hi = 0x94,
- .lo = 0x90,
- .size = MV64x60_PCI12MEM_0_SIZE,
+ [0] = {
+ .fcn = 0,
+ .hi = 0x94,
+ .lo = 0x90,
+ .size = MV64x60_PCI12MEM_0_SIZE,
+ },
+ [1] = {
+ .fcn = 0,
+ .hi = 0x9c,
+ .lo = 0x98,
+ .size = MV64x60_PCI12MEM_1_SIZE,
+ },
+ [2] = {
+ .fcn = 1,
+ .hi = 0x94,
+ .lo = 0x90,
+ .size = MV64x60_PCI12MEM_2_SIZE,
+ },
+ [3] = {
+ .fcn = 1,
+ .hi = 0x9c,
+ .lo = 0x98,
+ .size = MV64x60_PCI12MEM_3_SIZE,
+ },
},
};
@@ -394,70 +440,81 @@ mv64x60_mem_win mv64x60_pci_acc[2][MV64x60_PCI_ACC_CNTL_WINDOWS] = {
},
};
-static struct mv64x60_mem_win mv64x60_pci2reg[2] = {
- {
+static struct mv64x60_pci_win mv64x60_pci2reg[2] = {
+ { /* hose 0 */
+ .fcn = 0,
.hi = 0x24,
.lo = 0x20,
.size = 0,
},
- {
+ { /* hose 1 */
+ .fcn = 0,
.hi = 0xa4,
.lo = 0xa0,
.size = 0,
},
};
-/* Only need to use 1 window (per hose) to get access to all of system memory */
+/* Make PCI->System memory windows match CPU->System memory windows */
void mv64x60_config_pci_windows(u8 *bridge_base, u8 *bridge_pbase, u8 hose,
- u8 bus, u32 mem_size, u32 acc_bits)
+ u8 bus, u32 acc_bits)
{
- u32 i, offset, bar_enable, enables;
+ u32 i, offset, bar_enable, menables, penables, base, size;
/* Disable all windows but PCI MEM -> Bridge's regs window */
- enables = ~(1 << 9);
+ penables = ~(1 << 9);
bar_enable = hose ? MV64x60_PCI1_BAR_ENABLE : MV64x60_PCI0_BAR_ENABLE;
- out_le32((u32 *)(bridge_base + bar_enable), enables);
+ out_le32((u32 *)(bridge_base + bar_enable), penables);
for (i=0; i<MV64x60_PCI_ACC_CNTL_WINDOWS; i++)
out_le32((u32 *)(bridge_base + mv64x60_pci_acc[hose][i].lo), 0);
- /* If mem_size is 0, leave windows disabled */
- if (mem_size == 0)
- return;
-
/* Cause automatic updates of PCI remap regs */
offset = hose ?
MV64x60_PCI1_PCI_DECODE_CNTL : MV64x60_PCI0_PCI_DECODE_CNTL;
i = in_le32((u32 *)(bridge_base + offset));
out_le32((u32 *)(bridge_base + offset), i & ~0x1);
- mem_size = (mem_size - 1) & 0xfffff000;
+ menables = in_le32((u32 *)(bridge_base + MV64x60_CPU_BAR_ENABLE)) & 0xf;
- /* Map PCI MEM addr 0 -> System Mem addr 0 */
- mv64x60_cfg_write(bridge_base, hose, bus,
- PCI_DEVFN(0, mv64x60_pci2mem[hose].fcn),
- mv64x60_pci2mem[hose].hi, 0);
- mv64x60_cfg_write(bridge_base, hose, bus,
- PCI_DEVFN(0, mv64x60_pci2mem[hose].fcn),
- mv64x60_pci2mem[hose].lo, 0);
- out_le32((u32 *)(bridge_base + mv64x60_pci2mem[hose].size),mem_size);
+ for (i=0; i<MV64x60_CPU2MEM_WINDOWS; i++) {
+ if (menables & (1 << i)) /* Set means disabled */
+ continue;
- acc_bits |= MV64x60_PCI_ACC_CNTL_ENABLE;
- out_le32((u32 *)(bridge_base + mv64x60_pci_acc[hose][0].hi), 0);
- out_le32((u32 *)(bridge_base + mv64x60_pci_acc[hose][0].lo), acc_bits);
- out_le32((u32 *)(bridge_base + mv64x60_pci_acc[hose][0].size),mem_size);
+ penables &= ~(1 << i); /* Enable this PCI BAR */
+ base = in_le32((u32 *)(bridge_base + mv64x60_cpu2mem[i].lo))
+ << 16;
+ size = (in_le32((u32 *)(bridge_base + mv64x60_cpu2mem[i].size))
+ << 16) | 0xf000;
+
+ mv64x60_cfg_write(bridge_base, hose, bus,
+ PCI_DEVFN(0, mv64x60_pci2mem[hose][i].fcn),
+ mv64x60_pci2mem[hose][i].hi, 0);
+ mv64x60_cfg_write(bridge_base, hose, bus,
+ PCI_DEVFN(0, mv64x60_pci2mem[hose][i].fcn),
+ mv64x60_pci2mem[hose][i].lo, base | 0xc);
+ out_le32((u32 *)(bridge_base + mv64x60_pci2mem[hose][i].size),
+ size);
+
+ out_le32((u32 *)(bridge_base + mv64x60_pci_acc[hose][i].hi), 0);
+ out_le32((u32 *)(bridge_base + mv64x60_pci_acc[hose][i].lo),
+ base | acc_bits | MV64x60_PCI_ACC_CNTL_ENABLE);
+ out_le32((u32 *)(bridge_base + mv64x60_pci_acc[hose][i].size),
+ size);
+ }
/* Set PCI MEM->bridge's reg window to where they are in CPU mem map */
i = (u32)bridge_base;
i &= 0xffff0000;
i |= (0x2 << 1);
- mv64x60_cfg_write(bridge_base, hose, bus, PCI_DEVFN(0,0),
+ mv64x60_cfg_write(bridge_base, hose, bus,
+ PCI_DEVFN(0, mv64x60_pci2reg[hose].fcn),
mv64x60_pci2reg[hose].hi, 0);
- mv64x60_cfg_write(bridge_base, hose, bus, PCI_DEVFN(0,0),
+ mv64x60_cfg_write(bridge_base, hose, bus,
+ PCI_DEVFN(0, mv64x60_pci2reg[hose].fcn),
mv64x60_pci2reg[hose].lo, i);
- enables &= ~0x1; /* Enable PCI MEM -> System Mem window 0 */
- out_le32((u32 *)(bridge_base + bar_enable), enables);
+ out_le32((u32 *)(bridge_base + bar_enable), penables);
}
/* CPU -> PCI I/O & MEM setup */
diff --git a/arch/powerpc/boot/mv64x60.h b/arch/powerpc/boot/mv64x60.h
index b827105..d0b29a7 100644
--- a/arch/powerpc/boot/mv64x60.h
+++ b/arch/powerpc/boot/mv64x60.h
@@ -53,7 +53,7 @@ void mv64x60_cfg_write(u8 *bridge_base, u8 hose, u8 bus, u8 devfn,
void mv64x60_config_ctlr_windows(u8 *bridge_base, u8 *bridge_pbase,
u8 is_coherent);
void mv64x60_config_pci_windows(u8 *bridge_base, u8 *bridge_pbase, u8 hose,
- u8 bus, u32 mem_size, u32 acc_bits);
+ u8 bus, u32 acc_bits);
void mv64x60_config_cpu2pci_window(u8 *bridge_base, u8 hose, u32 pci_base_hi,
u32 pci_base_lo, u32 cpu_base, u32 size,
struct mv64x60_cpu2pci_win *offset_tbl);
^ permalink raw reply related
* Re: [RFC] Modifying i2c-core to support alias driver names compatible with device trees
From: Stephen Rothwell @ 2007-11-08 1:05 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jean Delvare, Tjernlund, i2c, linuxppc-dev
In-Reply-To: <9e4733910711061239g22b06863rbec37fcef138c869@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 532 bytes --]
On Tue, 6 Nov 2007 15:39:42 -0500 "Jon Smirl" <jonsmirl@gmail.com> wrote:
>
> It was requested to split this code out into a separate thread....
>
> This code modifies the i2c-core to support lists of alias names in the
> chip drivers.
> For example: .aliases = (char const
> *[]){"ricoh,rs5c372a","ricoh,rs5c372b","ricoh,rv5c386","ricoh,rv5c387a",
> 0},
You should not need the (char const *[]) casts at all.
--
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: use of fsl, in lite5200b.dts in git current
From: Matt Sealey @ 2007-11-08 0:30 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910711071421i347a6a0bu99cbf062cc152aca@mail.gmail.com>
Jon Smirl wrote:
> I'm not in favor of all these fsl prefixes. These chip families do get
> sold. What would we have done with intel,pxa320 all over the place
> when they sold it to marvell? mass changes to marvell,pxa320?
That's the idea, and there'd be a compatible entry for intel,pxa320.
Actually the spec says you should use the stock ticker (IBM, FSL, INTC,
JAVA, MRVL) if they have one and if not, the company name in lower case.
Freescale are a funny one because they used to have a stock ticker as
MOT and then FSL but now they're privately owned, so it's gonna have to
be lower case :]
It's just to seperate out the fact that sometimes you get chips with
very similar or identical names, or to mark out vendor-specific
functionality. fsl,has-wdt differs from has-wdt ideally because
Freescale watchdog timers aren't the same as other watchdog timers -
the term is pretty pliable, Freescale's GPT on the MPC52xx isn't
always a watchdog (it can be a normal, non-watchdog timer too..)
> The mpc/pxa parts numbers don't get changes when chip families get sold.
There is a case that between selling chips, some of them get updated
or bugfixed, and you can tell which one you have by the name.
There has to be some standardisation on the first implementation of
the device tree for the chip, otherwise the chopping and changing
gets rather tedious.
I'm sure you can see why we don't release firmware updates every time
some Linux guy changes some lousy, hacky tree definition for yet another
6 times a year, until it finally stabilises and the product is usually
discontinued anyway :D
However in the current situation it just means you need to flash new
FDT blobs to your U-Boots which are more clean, and keep your kernel
in sync, because Linux only handles what it currently thinks is the
standard.
The real loser is the real Open Firmware implementation, but nobody
seems to think about that, the device trees on OF devices get more
cluttered..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: mpc5200, sysctl table check failed
From: Jon Smirl @ 2007-11-07 23:46 UTC (permalink / raw)
To: Grant Likely; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711071304l46cb948fk8a1fba27acdd6dac@mail.gmail.com>
I think whatever is broken in my FEC code is exposing a different bug
in some timeout code that is not normally run. Something to do with
the swap thread being unable to get to the swap device maybe?
Can anyone tell me where this Oops is coming from? It is the same oops
as the previous one, but the stacks are different.
I am getting it after a random number of retries of:
nfs: server 192.168.1.4 not responding, still trying
nfs: server 192.168.1.4 not responding, still trying
nfs: server 192.168.1.4 not responding, still trying
nfs: server 192.168.1.4 not responding, still trying
nfs: server 192.168.1.4 not responding, still trying
nfs: server 192.168.1.4 not responding, still trying
Using current git head.
Unable to handle kernel paging request for data at address 0x0000001b
Faulting instruction address: 0xc0027288
Oops: Kernel access of bad area, sig: 11 [#1]
pcm030
Modules linked in:
NIP: c0027288 LR: c0027284 CTR: c00274c4
REGS: c031bd80 TRAP: 0300 Not tainted (2.6.24-rc2-efika-g34082a7d-dirty)
MSR: 00001032 <ME,IR,DR> CR: 28000028 XER: 00000000
DAR: 0000001b, DSISR: 20000000
TASK = c02fa570[0] 'swapper' THREAD: c031a000
GPR00: 03ffffff c031be30 c02fa570 c032e9a8 0000001b 00000001 c0320000 c0320000
GPR08: c02febd8 c032e9a8 00004000 00000000 248e3746 ffefffff 03ffe000 ffffffff
GPR16: 00000001 00000000 007ffc00 00000000 00000000 03ff8838 00000000 00000004
GPR24: 00000000 00000000 c032341c c0320000 c031a000 00000001 c032e9a0 0000001b
NIP [c0027288] cascade+0x74/0x9c
LR [c0027284] cascade+0x70/0x9c
Call Trace:
[c031be30] [c0018c94] __update_rq_clock+0x20/0x124 (unreliable)
[c031be60] [c002753c] run_timer_softirq+0x78/0x1b4
[c031be90] [c00234cc] __do_softirq+0x64/0xd4
[c031beb0] [c0006144] do_softirq+0x40/0x58
[c031bec0] [c0023378] irq_exit+0x38/0x48
[c031bed0] [c000d178] timer_interrupt+0x164/0x180
[c031bee0] [c000fe64] ret_from_except+0x0/0x14
--- Exception: 901 at cpu_idle+0x88/0xd0
LR = cpu_idle+0x88/0xd0
[c031bfa0] [c0009038] cpu_idle+0xcc/0xd0 (unreliable)
[c031bfb0] [c024aa30] rest_init+0x50/0x60
[c031bfc0] [c02d19c4] start_kernel+0x298/0x2ac
[c031bff0] [00003438] 0x3438
Instruction dump:
80810008 83e40000 4800002c 80040014 5400003c 7c00f278 3160ffff 7d2b0110
0f090000 7fc3f378 4bfffecd 7fe4fb78 <83ff0000> 38010008 7f840000 409effd0
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 180 seconds..
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re[2]: [PATCH] [PPC 44x] L2-cache synchronization for ppc44x
From: Yuri Tikhonov @ 2007-11-07 23:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1194477573.6523.58.camel@pasglop>
Hi Ben,
On 08.11.2007, 2:19:33 you wrote:
> On Thu, 2007-11-08 at 02:12 +0300, Yuri Tikhonov wrote:
>> This is the updated patch for support synchronization of L2-Cache with
>> the external memory on the ppc44x-based platforms.
>>
>> Differencies against the previous patch-set:
>> - remove L2_CACHE config option;
>> - introduce the ppc machdep to invalidate L2 cache lines;
>> - some code clean-up.
> Can you tell me more about how this cache operates ? I don't quite
> understand why you would invalidate it on bidirectional DMAs rather than
> flush it to memory (unless you get your terminology wrong) and why you
> wouldn't flush it on transfers to the device.. Unless it is a
> write-through cache ?
Yes, the ppc44x Level2 cache has the write-through design, so no need to do any kind of l2_flush.
As far as the DMA_BIDIRECTIONAL case is concerned flush_dcache_range() flushes the data over the following path: L1->L2->RAM, but invalidates L1 only, and L2 remains invalid. Since in the BIDIRECTIONAL case DMA may update the data in RAM - we have to invalidate L2-cache manually, so that CPU may read new data transmitted by DMA right from RAM rather than old ones stuck in L2 due to flush_dcache().
Regards,
Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
^ permalink raw reply
* Re: [PATCH] [PPC 44x] L2-cache synchronization for ppc44x
From: Benjamin Herrenschmidt @ 2007-11-07 23:19 UTC (permalink / raw)
To: Yuri Tikhonov; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <608329302.20071108021252@emcraft.com>
On Thu, 2007-11-08 at 02:12 +0300, Yuri Tikhonov wrote:
> This is the updated patch for support synchronization of L2-Cache with the external memory on the ppc44x-based platforms.
>
> Differencies against the previous patch-set:
> - remove L2_CACHE config option;
> - introduce the ppc machdep to invalidate L2 cache lines;
> - some code clean-up.
Can you tell me more about how this cache operates ? I don't quite
understand why you would invalidate it on bidirectional DMAs rather than
flush it to memory (unless you get your terminology wrong) and why you
wouldn't flush it on transfers to the device.. Unless it is a
write-through cache ?
Ben.
> Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
> Signed-off-by: Pavel Kolesnikov <concord@emcraft.com>
>
> --
> diff --git a/arch/powerpc/lib/dma-noncoherent.c b/arch/powerpc/lib/dma-noncoherent.c
> index 1947380..b06f05c 100644
> --- a/arch/powerpc/lib/dma-noncoherent.c
> +++ b/arch/powerpc/lib/dma-noncoherent.c
> @@ -31,6 +31,7 @@
> #include <linux/dma-mapping.h>
>
> #include <asm/tlbflush.h>
> +#include <asm/machdep.h>
>
> /*
> * This address range defaults to a value that is safe for all
> @@ -186,6 +187,8 @@ __dma_alloc_coherent(size_t size, dma_addr_t *handle, gfp_t gfp)
> unsigned long kaddr = (unsigned long)page_address(page);
> memset(page_address(page), 0, size);
> flush_dcache_range(kaddr, kaddr + size);
> + if (ppc_md.l2cache_inv_range)
> + ppc_md.l2cache_inv_range(__pa(kaddr), __pa(kaddr + size));
> }
>
> /*
> @@ -351,12 +354,16 @@ void __dma_sync(void *vaddr, size_t size, int direction)
> BUG();
> case DMA_FROM_DEVICE: /* invalidate only */
> invalidate_dcache_range(start, end);
> + if (ppc_md.l2cache_inv_range)
> + ppc_md.l2cache_inv_range(__pa(start), __pa(end));
> break;
> case DMA_TO_DEVICE: /* writeback only */
> clean_dcache_range(start, end);
> break;
> case DMA_BIDIRECTIONAL: /* writeback and invalidate */
> flush_dcache_range(start, end);
> + if (ppc_md.l2cache_inv_range)
> + ppc_md.l2cache_inv_range(__pa(start), __pa(end));
> break;
> }
> }
> diff --git a/arch/ppc/kernel/misc.S b/arch/ppc/kernel/misc.S
> index 46cf8fa..31c9149 100644
> --- a/arch/ppc/kernel/misc.S
> +++ b/arch/ppc/kernel/misc.S
> @@ -25,6 +25,10 @@
> #include <asm/thread_info.h>
> #include <asm/asm-offsets.h>
>
> +#ifdef CONFIG_44x
> +#include <asm/ibm44x.h>
> +#endif
> +
> #ifdef CONFIG_8xx
> #define ISYNC_8xx isync
> #else
> @@ -386,6 +390,35 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
> sync /* additional sync needed on g4 */
> isync
> blr
> +
> +#if defined(CONFIG_44x)
> +/*
> + * Invalidate the Level-2 cache lines corresponded to the address
> + * range.
> + *
> + * invalidate_l2cache_range(unsigned long start, unsigned long stop)
> + */
> +_GLOBAL(invalidate_l2cache_range)
> + li r5,PPC44X_L2_CACHE_BYTES-1 /* align on L2-cache line */
> + andc r3,r3,r5
> + subf r4,r3,r4
> + add r4,r4,r5
> + srwi. r4,r4,PPC44X_L2_CACHE_SHIFT
> + mtctr r4
> +
> + lis r4, L2C_CMD_INV>>16
> +1: mtdcr DCRN_L2C0_ADDR,r3 /* write address to invalidate */
> + mtdcr DCRN_L2C0_CMD,r4 /* issue the Invalidate cmd */
> +
> +2: mfdcr r5,DCRN_L2C0_SR /* wait for complete */
> + andis. r5,r5,L2C_CMD_CLR>>16
> + beq 2b
> +
> + addi r3,r3,PPC44X_L2_CACHE_BYTES /* next address to invalidate */
> + bdnz 1b
> + blr
> +#endif
> +
> /*
> * Write any modified data cache blocks out to memory.
> * Does not invalidate the corresponding cache lines (especially for
> diff --git a/arch/ppc/syslib/ibm440gx_common.c b/arch/ppc/syslib/ibm440gx_common.c
> index 6b1a801..64c663f 100644
> --- a/arch/ppc/syslib/ibm440gx_common.c
> +++ b/arch/ppc/syslib/ibm440gx_common.c
> @@ -12,6 +12,8 @@
> */
> #include <linux/kernel.h>
> #include <linux/interrupt.h>
> +#include <asm/machdep.h>
> +#include <asm/cacheflush.h>
> #include <asm/ibm44x.h>
> #include <asm/mmu.h>
> #include <asm/processor.h>
> @@ -201,6 +203,7 @@ void __init ibm440gx_l2c_enable(void){
>
> asm volatile ("sync; isync" ::: "memory");
> local_irq_restore(flags);
> + ppc_md.l2cache_inv_range = invalidate_l2cache_range;
> }
>
> /* Disable L2 cache */
> diff --git a/include/asm-powerpc/cacheflush.h b/include/asm-powerpc/cacheflush.h
> index ba667a3..bdebfaa 100644
> --- a/include/asm-powerpc/cacheflush.h
> +++ b/include/asm-powerpc/cacheflush.h
> @@ -49,6 +49,7 @@ extern void flush_dcache_range(unsigned long start, unsigned long stop);
> #ifdef CONFIG_PPC32
> extern void clean_dcache_range(unsigned long start, unsigned long stop);
> extern void invalidate_dcache_range(unsigned long start, unsigned long stop);
> +extern void invalidate_l2cache_range(unsigned long start, unsigned long stop);
> #endif /* CONFIG_PPC32 */
> #ifdef CONFIG_PPC64
> extern void flush_inval_dcache_range(unsigned long start, unsigned long stop);
> diff --git a/include/asm-powerpc/machdep.h b/include/asm-powerpc/machdep.h
> index 71c6e7e..754f416 100644
> --- a/include/asm-powerpc/machdep.h
> +++ b/include/asm-powerpc/machdep.h
> @@ -201,6 +201,8 @@ struct machdep_calls {
> void (*early_serial_map)(void);
> void (*kgdb_map_scc)(void);
>
> + void (*l2cache_inv_range)(unsigned long s, unsigned long e);
> +
> /*
> * optional PCI "hooks"
> */
> diff --git a/include/asm-ppc/ibm44x.h b/include/asm-ppc/ibm44x.h
> index 8078a58..8ac0a13 100644
> --- a/include/asm-ppc/ibm44x.h
> +++ b/include/asm-ppc/ibm44x.h
> @@ -138,7 +138,6 @@
> * The "residual" board information structure the boot loader passes
> * into the kernel.
> */
> -#ifndef __ASSEMBLY__
>
> /*
> * DCRN definitions
> @@ -596,6 +595,9 @@
> #define SRAM_DPC_ENABLE 0x80000000
>
> /* L2 Cache Controller 440GX/440SP/440SPe */
> +#define PPC44X_L2_CACHE_SHIFT 5
> +#define PPC44X_L2_CACHE_BYTES (1 << PPC44X_L2_CACHE_SHIFT)
> +
> #define DCRN_L2C0_CFG 0x030
> #define L2C_CFG_L2M 0x80000000
> #define L2C_CFG_ICU 0x40000000
> @@ -814,6 +816,5 @@
>
> #include <asm/ibm4xx.h>
>
> -#endif /* __ASSEMBLY__ */
> #endif /* __ASM_IBM44x_H__ */
> #endif /* __KERNEL__ */
> diff --git a/include/asm-ppc/machdep.h b/include/asm-ppc/machdep.h
> index 293a444..4e7a270 100644
> --- a/include/asm-ppc/machdep.h
> +++ b/include/asm-ppc/machdep.h
> @@ -80,6 +80,8 @@ struct machdep_calls {
> void (*nvram_write_val)(int addr, unsigned char val);
> void (*nvram_sync)(void);
>
> + void (*l2cache_inv_range)(unsigned long s, unsigned long e);
> +
> /*
> * optional PCI "hooks"
> */
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] DTC: Polish up the DTS Version 1 implementation.
From: David Gibson @ 2007-11-07 23:19 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
In-Reply-To: <E1Iplfp-0003WY-MB@jdl.com>
On Wed, Nov 07, 2007 at 08:14:29AM -0600, Jon Loeliger wrote:
> So, like, the other day David Gibson mumbled:
> > On Tue, Nov 06, 2007 at 04:19:19PM -0600, Jon Loeliger wrote:
> > > From: Jon Loeliger <jdl@freescale.com>
> > >
> > > Fixes BYTESTRING lexing.
> > > Allows -O dts output to be emitted in a given (1) format version.
> >
> > Ok... I'd actually be more inclined to remove the option and just have
> > -Odts *always* use the newer version.
>
> You didn't read the code. :-) That's what it does!
> There is no option, it is just parameterized in the code.
> It _always_ forward re-writes as the latest version.
Yes, I know, but I don't think it's even worth having the unused
internal parameterization.
> > Having dtc be able to convert dts versions forward is easy and
> > useful.
>
> Oh, I see. Thank you.
>
> > > This patch is directly on top of your prior two patches.
> > > Lemme know what you think.
> >
> > On top of my two dts-v1 patches that is, I assume?
>
> Right.
>
> > Ow... that's rather embarrassing, that I didn't even notice I'd
> > totally broken bytestrings. Really must add some bytestrings to
> > test_tree1.dts so this actually gets checked by the testsuite.
>
> I ran my "old versus new DTC" comparison script and found it. :-)
Heh, we should fold that into the testsuite, too.
> > Not really related changes, but whatever..
>
> Uh, yeah. Leftoverish. Sorry.
>
>
> > > +/*
> > > + * bits is unused, but it should be 32 or 64 as needed.
> > > + *
> > > + * FIXME: However, with bits == 64, ((1ULL << bits) - 1)
> > > + * overflows before you can actually do the range test.
> > > + */
> > > unsigned long long eval_literal(const char *s, int base, int bits)
> > > {
> > > unsigned long long val;
> > > @@ -317,9 +323,10 @@ unsigned long long eval_literal(const char *s, int base, int bits)
> > > val = strtoull(s, &e, base);
> > > if (*e)
> > > yyerror("bad characters in literal");
> > > - else if ((errno == ERANGE) || (val > ((1ULL << bits)-1)))
> > > + else if (errno == ERANGE)
> > > yyerror("literal out of range");
> > > else if (errno != 0)
> > > yyerror("bad literal");
> > > +
> >
> > Ok.. I don't understand why you've pulled out the range checking
> > against bits here.
>
> Because it wasn't working, as explained in the comment I added.
> Specifically, (1<<bits), with bits==64 overflowed and yielded
> the value 0.
Ah...
Well, I assumed (1ULL << 64) would equal 0, which is why the
comparison has the (-1) - I was expecting for bits == 64 it would end
up being against -1, i.e. 0xffffffffffffffff. This appears to work on
the systems I've been using.
But I just remembered that (x << n) has undefined behaviour in C when
n >= word size. So I guess (1 << 64) is just returning garbage - I
suspect I didn't catch it because I've been building with -O0 for
gdb-ability, which might change the behaviour of corner cases like
that.
So I guess we need
else if ((errno == ERANGE)
|| ((bits < 64) && (val >= (1ULL << bits))))
[snip]
> > > -static void write_propval_bytes(FILE *f, struct data val)
> > > +static void write_propval_bytes(FILE *f, struct data val, int dts_version)
> > > {
> > > void *propend = val.val + val.len;
> > > char *bp = val.val;
> > >
> > > fprintf(f, " = [");
> > > for (;;) {
> > > - fprintf(f, "%02hhx", *bp++);
> > > + if (dts_version == 0) {
> > > + fprintf(f, "%02hhx", *bp++);
> > > + } else {
> > > + fprintf(f, "0x%02hhx", *bp++);
> > > + }
> >
> > Uh.. not quite right. My patch (intentionally) leaves bytestrings as
> > pure hex, without 0x.
>
> Ugh. That seems inconsistent and wrong to me.
Well... depends on how you think about it. If you think of [] as a
list of really small integers, then it's inconsistent. But, if you
think of [] as a way of doing really long hex literals..
> > We can argue about whether that's a good idea,
> > if you like,
>
> And in the blue corner, touting consistent hex forms, ...
And in the red, compact bytestring representations.
No, seriously, the inconsistency bothers me too. But so does the fact
that using 0x in the bytestring would double the minimum size for
representing bytestrings, somewhat changing the flavour of [] as well
(because spaces are no longer optional). I'm looking for a killer
argument one way or the other, but I haven't found it yet.
> > but in any case input and output should match.
>
> Oops. That they should.
>
> > To avoid this sort of problem, I suggest before we apply the dts-v1
> > transition, we apply the patch I'm working on (I'll try to get it out
> > today), which adds a bunch of extra testcases checking that using dtc
> > to go dtb->dts->dtb preserves everything.
>
> Yeah, I've been doing that too... Sounds good.
--
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
* [PATCH] [PPC 44x] L2-cache synchronization for ppc44x
From: Yuri Tikhonov @ 2007-11-07 23:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson
=0D=0A This is the updated patch for support synchronization of L2-Cache wi=
th the external memory on the ppc44x-based platforms.
Differencies against the previous patch-set:
- remove L2_CACHE config option;
- introduce the ppc machdep to invalidate L2 cache lines;
- some code clean-up.
Signed-off-by: Yuri Tikhonov <yur@emcraft.com>
Signed-off-by: Pavel Kolesnikov <concord@emcraft.com>
--
diff --git a/arch/powerpc/lib/dma-noncoherent.c b/arch/powerpc/lib/dma-nonc=
oherent.c
index 1947380..b06f05c 100644
--- a/arch/powerpc/lib/dma-noncoherent.c
+++ b/arch/powerpc/lib/dma-noncoherent.c
@@ -31,6 +31,7 @@
#include <linux/dma-mapping.h>
=20
#include <asm/tlbflush.h>
+#include <asm/machdep.h>
=20
/*
* This address range defaults to a value that is safe for all
@@ -186,6 +187,8 @@ __dma_alloc_coherent(size_t size, dma_addr_t *handle, g=
fp_t gfp)
=09=09unsigned long kaddr =3D (unsigned long)page_address(page);
=09=09memset(page_address(page), 0, size);
=09=09flush_dcache_range(kaddr, kaddr + size);
+=09=09if (ppc_md.l2cache_inv_range)
+=09=09=09ppc_md.l2cache_inv_range(__pa(kaddr), __pa(kaddr + size));
=09}
=20
=09/*
@@ -351,12 +354,16 @@ void __dma_sync(void *vaddr, size_t size, int directi=
on)
=09=09BUG();
=09case DMA_FROM_DEVICE:=09/* invalidate only */
=09=09invalidate_dcache_range(start, end);
+=09=09if (ppc_md.l2cache_inv_range)
+=09=09=09ppc_md.l2cache_inv_range(__pa(start), __pa(end));
=09=09break;
=09case DMA_TO_DEVICE:=09=09/* writeback only */
=09=09clean_dcache_range(start, end);
=09=09break;
=09case DMA_BIDIRECTIONAL:=09/* writeback and invalidate */
=09=09flush_dcache_range(start, end);
+=09=09if (ppc_md.l2cache_inv_range)
+=09=09=09ppc_md.l2cache_inv_range(__pa(start), __pa(end));
=09=09break;
=09}
}
diff --git a/arch/ppc/kernel/misc.S b/arch/ppc/kernel/misc.S
index 46cf8fa..31c9149 100644
--- a/arch/ppc/kernel/misc.S
+++ b/arch/ppc/kernel/misc.S
@@ -25,6 +25,10 @@
#include <asm/thread_info.h>
#include <asm/asm-offsets.h>
=20
+#ifdef CONFIG_44x
+#include <asm/ibm44x.h>
+#endif
+
#ifdef CONFIG_8xx
#define ISYNC_8xx isync
#else
@@ -386,6 +390,35 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
=09sync=09=09=09=09/* additional sync needed on g4 */
=09isync
=09blr
+
+#if defined(CONFIG_44x)
+/*
+ * Invalidate the Level-2 cache lines corresponded to the address
+ * range.
+ *
+ * invalidate_l2cache_range(unsigned long start, unsigned long stop)
+ */
+_GLOBAL(invalidate_l2cache_range)
+=09li=09r5,PPC44X_L2_CACHE_BYTES-1=09/* align on L2-cache line */
+=09andc=09r3,r3,r5
+=09subf=09r4,r3,r4
+=09add=09r4,r4,r5
+=09srwi.=09r4,r4,PPC44X_L2_CACHE_SHIFT
+=09mtctr=09r4
+
+=09lis=09r4, L2C_CMD_INV>>16
+1:=09mtdcr=09DCRN_L2C0_ADDR,r3=09/* write address to invalidate */
+=09mtdcr=09DCRN_L2C0_CMD,r4=09/* issue the Invalidate cmd */
+
+2:=09mfdcr=09r5,DCRN_L2C0_SR=09=09/* wait for complete */
+=09andis.=09r5,r5,L2C_CMD_CLR>>16
+=09beq=092b
+
+=09addi=09r3,r3,PPC44X_L2_CACHE_BYTES=09/* next address to invalidate */
+=09bdnz=091b
+=09blr
+#endif
+
/*
* Write any modified data cache blocks out to memory.
* Does not invalidate the corresponding cache lines (especially for
diff --git a/arch/ppc/syslib/ibm440gx_common.c b/arch/ppc/syslib/ibm440gx_c=
ommon.c
index 6b1a801..64c663f 100644
--- a/arch/ppc/syslib/ibm440gx_common.c
+++ b/arch/ppc/syslib/ibm440gx_common.c
@@ -12,6 +12,8 @@
*/
#include <linux/kernel.h>
#include <linux/interrupt.h>
+#include <asm/machdep.h>
+#include <asm/cacheflush.h>
#include <asm/ibm44x.h>
#include <asm/mmu.h>
#include <asm/processor.h>
@@ -201,6 +203,7 @@ void __init ibm440gx_l2c_enable(void){
=20
=09asm volatile ("sync; isync" ::: "memory");
=09local_irq_restore(flags);
+=09ppc_md.l2cache_inv_range =3D invalidate_l2cache_range;
}
=20
/* Disable L2 cache */
diff --git a/include/asm-powerpc/cacheflush.h b/include/asm-powerpc/cachefl=
ush.h
index ba667a3..bdebfaa 100644
--- a/include/asm-powerpc/cacheflush.h
+++ b/include/asm-powerpc/cacheflush.h
@@ -49,6 +49,7 @@ extern void flush_dcache_range(unsigned long start, unsig=
ned long stop);
#ifdef CONFIG_PPC32
extern void clean_dcache_range(unsigned long start, unsigned long stop);
extern void invalidate_dcache_range(unsigned long start, unsigned long sto=
p);
+extern void invalidate_l2cache_range(unsigned long start, unsigned long st=
op);
#endif /* CONFIG_PPC32 */
#ifdef CONFIG_PPC64
extern void flush_inval_dcache_range(unsigned long start, unsigned long st=
op);
diff --git a/include/asm-powerpc/machdep.h b/include/asm-powerpc/machdep.h
index 71c6e7e..754f416 100644
--- a/include/asm-powerpc/machdep.h
+++ b/include/asm-powerpc/machdep.h
@@ -201,6 +201,8 @@ struct machdep_calls {
=09void=09=09(*early_serial_map)(void);
=09void=09=09(*kgdb_map_scc)(void);
=20
+=09void=09=09(*l2cache_inv_range)(unsigned long s, unsigned long e);
+
=09/*
=09 * optional PCI "hooks"
=09 */
diff --git a/include/asm-ppc/ibm44x.h b/include/asm-ppc/ibm44x.h
index 8078a58..8ac0a13 100644
--- a/include/asm-ppc/ibm44x.h
+++ b/include/asm-ppc/ibm44x.h
@@ -138,7 +138,6 @@
* The "residual" board information structure the boot loader passes
* into the kernel.
*/
-#ifndef __ASSEMBLY__
=20
/*
* DCRN definitions
@@ -596,6 +595,9 @@
#define SRAM_DPC_ENABLE=090x80000000
=20
/* L2 Cache Controller 440GX/440SP/440SPe */
+#define PPC44X_L2_CACHE_SHIFT=095
+#define PPC44X_L2_CACHE_BYTES=09(1 << PPC44X_L2_CACHE_SHIFT)
+
#define DCRN_L2C0_CFG=09=090x030
#define L2C_CFG_L2M=09=090x80000000
#define L2C_CFG_ICU=09=090x40000000
@@ -814,6 +816,5 @@
=20
#include <asm/ibm4xx.h>
=20
-#endif /* __ASSEMBLY__ */
#endif /* __ASM_IBM44x_H__ */
#endif /* __KERNEL__ */
diff --git a/include/asm-ppc/machdep.h b/include/asm-ppc/machdep.h
index 293a444..4e7a270 100644
--- a/include/asm-ppc/machdep.h
+++ b/include/asm-ppc/machdep.h
@@ -80,6 +80,8 @@ struct machdep_calls {
=09void=09=09(*nvram_write_val)(int addr, unsigned char val);
=09void=09=09(*nvram_sync)(void);
=20
+=09void=09=09(*l2cache_inv_range)(unsigned long s, unsigned long e);
+
=09/*
=09 * optional PCI "hooks"
=09 */=20
^ permalink raw reply related
* Re[2]: [PATCH 2/2] [PPC 44x] enable L2-cache for ALPR, Katmai, Ocotea, and Taishan
From: Yuri Tikhonov @ 2007-11-07 23:10 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071107040608.GB22637@lixom.net>
Hi Olof,
On 07.11.2007, 7:06:08 you wrote:
...
>> +
>> +config L2_CACHE
>> + bool "Enable Level-2 Cache"
>> + depends on NOT_COHERENT_CACHE && (KATMAI || TAISHAN || OCOTEA || ALPR)
>> + default y
>> + help
>> + This option enables L2-cache on ppc44x controllers.
>> + If unsure, say Y.
> That's a very generic config name. Maybe something like PPC_4XX_L2_CACHE?
Having the ppc_machdep for invalidating L2-cache lines we can avoid introducing the new configuration options at all. See below.
> Is there ever a case where a user would NOT want l2 cache enabled (and
> disabled permanently enough to rebuild the kernel instead of giving a
> kernel command line option?)
Theoretically - yes. Internal SRAM of ppc44x may be used for something else than L2 cache.
Admittedly, the configuration option was necessary for me to enable or disable my L2-cache synchronization routine in the generic dma_sync() function. Per your suggestion, now, instead of introducing the new kernel option I initialize the L2-cache sync ppc_machdep right in the L2-cache enable routine: thus if the user will not enable L2-cache (will not want internal SRAM to act as L2-cache and will not call the L2-cache enabling routine) then my new ppc_machdep will remain set to zero and will not affect on SRAM used for some specific purposes.
...
>> @@ -567,7 +569,9 @@ void __init platform_init(unsigned long r3, unsigned long r4,
>> #ifdef CONFIG_KGDB
>> ppc_md.early_serial_map = alpr_early_serial_map;
>> #endif
>> +#ifdef CONFIG_L2_CACHE
>> ppc_md.init = alpr_init;
>> +#endif
> Why do you take out the above calls if the new option is selected? Seems
> odd to remove something that worked(?) before.
Umm.. Quite the contrary, the option selected made these calls avaiable. Though it doesn't matter anymore since there is no CONFIG_L2_CACHE option anymore (i.e. all the four boards dealt with in this patch-set now have L2-cache enabled regardless of configuration, as it was initially).
>> ppc_md.restart = alpr_restart;
>> }
>>
...
>> +#ifdef CONFIG_L2_CACHE
>> +static void __init katmai_init(void)
>> +{
>> + ibm440gx_l2c_setup(&clocks);
>> +}
>> +#endif
>> +
>> void __init platform_init(unsigned long r3, unsigned long r4,
>> unsigned long r5, unsigned long r6, unsigned long r7)
>> {
>> @@ -599,4 +607,7 @@ void __init platform_init(unsigned long r3, unsigned long r4,
>> ppc_md.early_serial_map = katmai_early_serial_map;
>> #endif
>> ppc_md.restart = katmai_restart;
>> +#ifdef CONFIG_L2_CACHE
>> + ppc_md.init = katmai_init;
>> +#endif
> See comment above. Should the above init be called for all configs, not just
> when L2_CACHE is enabled?
> Also, it looks like the init function is the same on every board. It would
> be better to make a common function instead of duplicating it everywhere.
Agree, but perhaps it's not the case for the ppc branch. Will do this in the powerpc branch as soon as support for these boards will be ported there.. by someone :)
Regards,
Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
^ permalink raw reply
* Re[2]: [PATCH 1/2] [PPC 4xx] invalidate_l2cache_range() implementation for ppc44x
From: Yuri Tikhonov @ 2007-11-07 23:10 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071107040428.GA22637@lixom.net>
Hi Olof,
Thanks a lot for the feedbacks. Comments below.
On 07.11.2007, 7:04:28 you wrote:
> Hi,
> Some comments below. In general this patch adds #ifdefs in common code,
> that's normally frowned upon.
> It would maybe be better to add a new call to ppc_machdeps and call it
> if set.
Agree; this looks better indeed.
> On Wed, Nov 07, 2007 at 01:40:28AM +0300, Yuri Tikhonov wrote:
...
>> +
>> /*
>> * Write any modified data cache blocks out to memory.
>> * Does not invalidate the corresponding cache lines (especially for
>> diff --git a/include/asm-powerpc/cache.h b/include/asm-powerpc/cache.h
>> index 5350704..8a2f9e6 100644
>> --- a/include/asm-powerpc/cache.h
>> +++ b/include/asm-powerpc/cache.h
>> @@ -10,12 +10,14 @@
>> #define MAX_COPY_PREFETCH 1
>> #elif defined(CONFIG_PPC32)
>> #define L1_CACHE_SHIFT 5
>> +#define L2_CACHE_SHIFT 5
>> #define MAX_COPY_PREFETCH 4
>> #else /* CONFIG_PPC64 */
>> #define L1_CACHE_SHIFT 7
>> #endif
>>
>> #define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT)
>> +#define L2_CACHE_BYTES (1 << L2_CACHE_SHIFT)
> The above looks highly system dependent to me. Should maybe be a part
> of the cache info structures instead, and filled in from the device tree?
This is the Level-2 cache line parameter. I'll see what can be made here. For now I've just renamed these definitions and moved them into the PPC44x-specific header.
Regards,
Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
^ permalink raw reply
* Re: use of fsl, in lite5200b.dts in git current
From: Matt Sealey @ 2007-11-07 22:17 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910711071355l75da5444kb7082692f1bdc0@mail.gmail.com>
Jon Smirl wrote:
> Sometimes the fsl prefix is being used and sometimes it isn't. Look at
> the two compatible strings. Which way is it going to be? Is
> fsl,has-wdt right?
fsl,has-wdt is right, at least since someone changed it.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: [PATCH (2.6.25) 2/2] suspend: clean up Kconfig
From: Russell King @ 2007-11-07 22:21 UTC (permalink / raw)
To: Johannes Berg
Cc: Bryan Wu, linux-mips, Ralf Baechle, Rafael J. Wysocki,
linuxppc-dev, Paul Mundt, linux-pm, Guennadi Liakhovetski
In-Reply-To: <20071107135849.207149000@sipsolutions.net>
On Wed, Nov 07, 2007 at 02:58:00PM +0100, Johannes Berg wrote:
> This cleans up the suspend Kconfig and removes the need to
> declare centrally which architectures support suspend. All
> architectures that currently support suspend are modified
> accordingly.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> Cc: Rafael J. Wysocki <rjw@sisk.pl>
> Cc: linuxppc-dev@ozlabs.org
> Cc: linux-pm@lists.linux-foundation.org
> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: linux-mips@linux-mips.org
> Cc: Paul Mundt <lethal@linux-sh.org>
> Cc: Bryan Wu <bryan.wu@analog.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> Architecture maintainers should evaluate whether their
> ARCH_SUSPEND_POSSIBLE symbol should be set only under
> stricter circumstances like I've done for powerpc.
>
> Always setting it is not usually a problem, however, since the
> infrastructure is only available for use after suspend_set_ops().
>
> arch/arm/Kconfig | 3 +++
> arch/blackfin/Kconfig | 4 ++++
> arch/frv/Kconfig | 5 +++++
> arch/i386/Kconfig | 4 ++++
> arch/mips/Kconfig | 4 ++++
> arch/powerpc/Kconfig | 4 ++++
> arch/sh/Kconfig | 4 ++++
> arch/x86_64/Kconfig | 3 +++
> kernel/power/Kconfig | 21 +++------------------
> 9 files changed, 34 insertions(+), 18 deletions(-)
>
> --- everything.orig/arch/i386/Kconfig 2007-11-07 14:45:28.591544215 +0100
> +++ everything/arch/i386/Kconfig 2007-11-07 14:45:28.631515461 +0100
> @@ -1323,3 +1323,7 @@ config KTIME_SCALAR
> config ARCH_HIBERNATION_POSSIBLE
> def_bool y
> depends on !SMP || !X86_VOYAGER
> +
> +config ARCH_SUSPEND_POSSIBLE
> + def_bool y
> + depends on !X86_VOYAGER
> --- everything.orig/arch/x86_64/Kconfig 2007-11-07 14:45:28.591544215 +0100
> +++ everything/arch/x86_64/Kconfig 2007-11-07 14:45:28.631515461 +0100
> @@ -716,6 +716,9 @@ menu "Power management options"
>
> source kernel/power/Kconfig
>
> +config ARCH_SUSPEND_POSSIBLE
> + def_bool y
> +
> config ARCH_HIBERNATION_POSSIBLE
> def_bool y
>
> --- everything.orig/kernel/power/Kconfig 2007-11-07 14:45:28.591544215 +0100
> +++ everything/kernel/power/Kconfig 2007-11-07 14:45:28.641531465 +0100
> @@ -64,7 +64,7 @@ config PM_TRACE
> config PM_SLEEP_SMP
> bool
> depends on SMP
> - depends on SUSPEND_SMP_POSSIBLE || ARCH_HIBERNATION_POSSIBLE
> + depends on ARCH_SUSPEND_POSSIBLE || ARCH_HIBERNATION_POSSIBLE
> depends on PM_SLEEP
> select HOTPLUG_CPU
> default y
> @@ -74,29 +74,14 @@ config PM_SLEEP
> depends on SUSPEND || HIBERNATION
> default y
>
> -config SUSPEND_UP_POSSIBLE
> - bool
> - depends on (X86 && !X86_VOYAGER) || PPC || ARM || BLACKFIN || MIPS \
> - || SUPERH || FRV
> - depends on !SMP
> - default y
> -
> -config SUSPEND_SMP_POSSIBLE
> - bool
> - depends on (X86 && !X86_VOYAGER) \
> - || (PPC && (PPC_PSERIES || PPC_PMAC)) || ARM
> - depends on SMP
> - default y
> -
> config SUSPEND
> bool "Suspend to RAM and standby"
> - depends on PM
> - depends on SUSPEND_UP_POSSIBLE || SUSPEND_SMP_POSSIBLE
> + depends on PM && ARCH_SUSPEND_POSSIBLE
> default y
> ---help---
> Allow the system to enter sleep states in which main memory is
> powered and thus its contents are preserved, such as the
> - suspend-to-RAM state (i.e. the ACPI S3 state).
> + suspend-to-RAM state (e.g. the ACPI S3 state).
>
> config HIBERNATION
> bool "Hibernation (aka 'suspend to disk')"
> --- everything.orig/arch/blackfin/Kconfig 2007-11-07 14:44:55.551521971 +0100
> +++ everything/arch/blackfin/Kconfig 2007-11-07 14:45:28.641531465 +0100
> @@ -993,6 +993,10 @@ endmenu
> menu "Power management options"
> source "kernel/power/Kconfig"
>
> +config ARCH_SUSPEND_POSSIBLE
> + def_bool y
> + depends on !SMP
> +
> choice
> prompt "Select PM Wakeup Event Source"
> default PM_WAKEUP_GPIO_BY_SIC_IWR
> --- everything.orig/arch/arm/Kconfig 2007-11-07 14:44:55.651522948 +0100
> +++ everything/arch/arm/Kconfig 2007-11-07 14:45:28.641531465 +0100
> @@ -977,6 +977,9 @@ menu "Power management options"
>
> source "kernel/power/Kconfig"
>
> +config ARCH_SUSPEND_POSSIBLE
> + def_bool y
> +
> endmenu
>
> source "net/Kconfig"
> --- everything.orig/arch/mips/Kconfig 2007-11-07 14:44:55.701522460 +0100
> +++ everything/arch/mips/Kconfig 2007-11-07 14:45:28.641531465 +0100
> @@ -1999,6 +1999,10 @@ endmenu
>
> menu "Power management options"
>
> +config ARCH_SUSPEND_POSSIBLE
> + def_bool y
> + depends on !SMP
> +
> source "kernel/power/Kconfig"
>
> endmenu
> --- everything.orig/arch/sh/Kconfig 2007-11-07 14:44:55.801520344 +0100
> +++ everything/arch/sh/Kconfig 2007-11-07 14:45:28.651528536 +0100
> @@ -748,6 +748,10 @@ endmenu
> menu "Power management options (EXPERIMENTAL)"
> depends on EXPERIMENTAL && SYS_SUPPORTS_PM
>
> +config ARCH_SUSPEND_POSSIBLE
> + def_bool y
> + depends on !SMP
> +
> source kernel/power/Kconfig
>
> endmenu
> --- everything.orig/arch/frv/Kconfig 2007-11-07 14:44:55.861520941 +0100
> +++ everything/arch/frv/Kconfig 2007-11-07 14:45:28.651528536 +0100
> @@ -357,6 +357,11 @@ source "drivers/pcmcia/Kconfig"
> # should probably wait a while.
>
> menu "Power management options"
> +
> +config ARCH_SUSPEND_POSSIBLE
> + def_bool y
> + depends on !SMP
> +
> source kernel/power/Kconfig
> endmenu
>
> --- everything.orig/arch/powerpc/Kconfig 2007-11-07 14:45:28.591544215 +0100
> +++ everything/arch/powerpc/Kconfig 2007-11-07 14:45:28.651528536 +0100
> @@ -155,6 +155,10 @@ config ARCH_HIBERNATION_POSSIBLE
> depends on (PPC64 && HIBERNATE_64) || (PPC32 && HIBERNATE_32)
> default y
>
> +config ARCH_SUSPEND_POSSIBLE
> + def_bool y
> + depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200
> +
> config PPC_DCR_NATIVE
> bool
> default n
>
> --
>
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* [PATCH] ioremap/iounmap issue in yucca_setup_pcie_fpga_rootpoint(); arch/ppc/platforms/4xx/yucca.c
From: Roel Kluin @ 2007-11-07 22:22 UTC (permalink / raw)
To: linuxppc-dev
iounmap pcie_reg_fpga_base in default case
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/ppc/platforms/4xx/yucca.c b/arch/ppc/platforms/4xx/yucca.c
index a83b0ba..66a44ff 100644
--- a/arch/ppc/platforms/4xx/yucca.c
+++ b/arch/ppc/platforms/4xx/yucca.c
@@ -211,6 +211,7 @@ static void __init yucca_setup_pcie_fpga_rootpoint(int port)
break;
default:
+ iounmap(pcie_reg_fpga_base);
return;
}
^ permalink raw reply related
* Re: use of fsl, in lite5200b.dts in git current
From: Jon Smirl @ 2007-11-07 22:21 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-embedded
In-Reply-To: <4732396D.4040904@genesi-usa.com>
I'm not in favor of all these fsl prefixes. These chip families do get
sold. What would we have done with intel,pxa320 all over the place
when they sold it to marvell? mass changes to marvell,pxa320?
The mpc/pxa parts numbers don't get changes when chip families get sold.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: use of fsl, in lite5200b.dts in git current
From: Jon Smirl @ 2007-11-07 22:18 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-embedded
In-Reply-To: <4732396D.4040904@genesi-usa.com>
On 11/7/07, Matt Sealey <matt@genesi-usa.com> wrote:
> Jon Smirl wrote:
> > Sometimes the fsl prefix is being used and sometimes it isn't. Look at
> > the two compatible strings. Which way is it going to be? Is
> > fsl,has-wdt right?
>
> fsl,has-wdt is right, at least since someone changed it.
What's the story with compatible?
I would think the gdt entries are wrong.
gpt@600 { // General Purpose Timer
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
code in drivers/watchdog/mpc5200_wdt.c would need to be changed to.
drivers/watchdog/mpc5200_wdt.c: { .compatible = "fsl,mpc5200-gpt", },
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] very similar, now in walnut_setup_arch(); arch/ppc/platforms/4xx/walnut.c
From: Roel Kluin @ 2007-11-07 22:17 UTC (permalink / raw)
To: linuxppc-dev
iounmap kb_data on error
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/arch/ppc/platforms/4xx/walnut.c b/arch/ppc/platforms/4xx/walnut.c
index 2f97723..04d3f3f 100644
--- a/arch/ppc/platforms/4xx/walnut.c
+++ b/arch/ppc/platforms/4xx/walnut.c
@@ -81,22 +81,23 @@ walnut_setup_arch(void)
kb_data = ioremap(WALNUT_PS2_BASE, 8);
if (!kb_data) {
printk(KERN_CRIT
"walnut_setup_arch() kb_data ioremap failed\n");
return;
}
kb_cs = kb_data + 1;
fpga_status = ioremap(PPC40x_FPGA_BASE, 8);
if (!fpga_status) {
+ iounmap(kb_data);
printk(KERN_CRIT
"walnut_setup_arch() fpga_status ioremap failed\n");
return;
}
fpga_enable = fpga_status + 1;
fpga_polarity = fpga_status + 2;
fpga_trigger = fpga_status + 3;
fpga_brdc = fpga_status + 4;
/* split the keyboard and mouse interrupts */
^ permalink raw reply related
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