* Re: "leds: Add openfirmware platform device support" breaks sparc
From: Grant Likely @ 2009-04-28 3:59 UTC (permalink / raw)
To: Andrew Morton
Cc: Michal Simek, tpiepho, linuxppc-dev, rpurdie, smaclennan,
sparclinux, David Miller, John Williams
In-Reply-To: <20090427152051.5067e888.akpm@linux-foundation.org>
On Mon, Apr 27, 2009 at 4:20 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Tue, 03 Mar 2009 16:37:13 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Sean MacLennan <smaclennan@pikatech.com>
>> Date: Tue, 3 Mar 2009 19:29:32 -0500
>>
>> > It has been..... uhhhh carry the two... longer than I want to admit
>> > since I worked on a sparc. Would GPIO based LEDS make sense on a sparc
>> > platform? Is sparc used much in the embedded world?
>> >
>> > If yes, the of_register_platform_driver is just a nice wrapper. It
>> > would be trivial to either change it to work on sparc, or add the
>> > wrapper to the sparc includes.
>>
>> We generally create the platform devices by hand for LED
>> devices on sparc64.
>>
>> I'd CONFIG_POWERPC depend this thing for now.
>
> Nobody has done this, so current mainline's sparc64 allmodconfig remains
> busted.
>
>
> This?
>
> --- a/drivers/leds/Kconfig~a
> +++ a/drivers/leds/Kconfig
> @@ -139,6 +139,7 @@ config LEDS_GPIO_PLATFORM
> =A0config LEDS_GPIO_OF
> =A0 =A0 =A0 =A0bool "OpenFirmware platform device bindings for GPIO LEDs"
> =A0 =A0 =A0 =A0depends on LEDS_GPIO && OF_DEVICE
> + =A0 =A0 =A0 depends on POWERPC
> =A0 =A0 =A0 =A0default y
> =A0 =A0 =A0 =A0help
> =A0 =A0 =A0 =A0 =A0Let the leds-gpio driver drive LEDs which have been de=
fined as
PowerPC actually uses CONFIG_PPC, so this doesn't work. However, this
might be better: I've compile tested it on powerpc, but I don't have
microblaze or sparc xcompilers right now. Also, probably word-wrapped
since I'm pasting it into my mailer, but I wanted to keep this within
the thread. I'll repost "for real" first thing tomorrow morning.
g.
commit 302d02a46c67938cf4ef310fec90734cb38acabe
Author: Grant Likely <grant.likely@secretlab.ca>
Date: Mon Apr 27 21:54:35 2009 -0600
of: make of_(un)register_platform_driver common code.
Some drivers using of_register_platform_driver() wrapper break on sparc
because the wrapper isn't in the header file. This patch moves it from
Microblaze and PowerPC implementations and makes it common code.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
diff --git a/arch/microblaze/include/asm/of_platform.h
b/arch/microblaze/include/asm/of_platform.h
index 187c0ee..3749127 100644
--- a/arch/microblaze/include/asm/of_platform.h
+++ b/arch/microblaze/include/asm/of_platform.h
@@ -36,16 +36,6 @@ static const struct of_device_id of_default_bus_ids[] =
=3D {
{},
};
-/* Platform drivers register/unregister */
-static inline int of_register_platform_driver(struct of_platform_driver *d=
rv)
-{
- return of_register_driver(drv, &of_platform_bus_type);
-}
-static inline void of_unregister_platform_driver(struct
of_platform_driver *drv)
-{
- of_unregister_driver(drv);
-}
-
/* Platform devices and busses creation */
extern struct of_device *of_platform_device_create(struct device_node *np,
const char *bus_id,
diff --git a/arch/powerpc/include/asm/of_platform.h
b/arch/powerpc/include/asm/of_platform.h
index 53b4650..d4aaa34 100644
--- a/arch/powerpc/include/asm/of_platform.h
+++ b/arch/powerpc/include/asm/of_platform.h
@@ -11,16 +11,6 @@
*
*/
-/* Platform drivers register/unregister */
-static inline int of_register_platform_driver(struct of_platform_driver *d=
rv)
-{
- return of_register_driver(drv, &of_platform_bus_type);
-}
-static inline void of_unregister_platform_driver(struct
of_platform_driver *drv)
-{
- of_unregister_driver(drv);
-}
-
/* Platform devices and busses creation */
extern struct of_device *of_platform_device_create(struct device_node *np,
const char *bus_id,
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 3d327b6..9084066 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -51,6 +51,16 @@ extern int of_register_driver(struct of_platform_driver =
*drv,
struct bus_type *bus);
extern void of_unregister_driver(struct of_platform_driver *drv);
+/* Platform drivers register/unregister */
+static inline int of_register_platform_driver(struct of_platform_driver *d=
rv)
+{
+ return of_register_driver(drv, &of_platform_bus_type);
+}
+static inline void of_unregister_platform_driver(struct
of_platform_driver *drv)
+{
+ of_unregister_driver(drv);
+}
+
#include <asm/of_platform.h>
extern struct of_device *of_find_device_by_node(struct device_node *np);
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply related
* Re: drivers/video/logo/logo_linux_mono.c build error
From: Stephen Rothwell @ 2009-04-28 3:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20090427145031.99d4e0ac.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 518 bytes --]
Hi Andrew,
On Mon, 27 Apr 2009 14:50:31 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> powerpc allmodconfig, current mainline:
>
> drivers/video/logo/logo_linux_mono.c:11: error: logo_linux_mono_data causes a section type conflict
>
> switching it from __initconst to __initdata "fixes" it.
Interesting. The program that generates the .c file above produces
__initdata for me ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: minimizing the configuration of linkstation_defconfig
From: Rogério Brito @ 2009-04-28 2:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-mtd, Guennadi Liakhovetski, linux-kernel
In-Reply-To: <2CE2BC61-1C6B-4D01-870B-BC460730AD79@kernel.crashing.org>
Hi, Kumar.
On Apr 27 2009, Kumar Gala wrote:
>
> On Apr 24, 2009, at 5:33 PM, Rogério Brito wrote:
>> 04. disable CONFIG_BLK_DEV_RAM.
>
> do we not allow booting a ramdisk?
Well, do we need a block device in ram to use initramfs?
(...)
>> Dear Kumar, please, apply this one.
>>
>> I have another patch regarding one regression regarding MTD &
>> PHYSMAP_COMPAT that I plan to send on top of this one.
>
> Ok, can we look at just specifying such info in the linkstation device
> tree.
Thanks. The MTD & PHYMAP_COMPAT are the things that have been bugging me
and my main reason to keep with the bleeding edge kernels is to get things
whey they were (regarding mtd) as in kernel 2.6.28.
As I have no experience with MTD devices, I would appreciate a reference to
their workings... All that I know is that all my /dev/mtd* devices are gone
if I boot a 2.6.29* kernel.
Of course, I can do a git bisect process (since the MTD subsystem doesn't
work as it did in the past even if I enable PHYMAP_COMPAT and put the same
settings there, quite unfortunately).
> Also, can you break this defconfig update into two patches. 1. that
> just updates to 2.6.30-rc3 (or latest) and 2. that makes the various
> changes you've listed above.
No problems with that. I will do that ASAP. Thanks for your kind comments.
Regards, Rogério Brito.
P.S.: Guennadi, did you see any regressions with your linkstation/kurobox
HG or whatever device you have?
--
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: David Hawkins @ 2009-04-28 2:08 UTC (permalink / raw)
To: Liu Dave-R63238
Cc: Ira Snyder, linux-kernel, linuxppc-dev, Dan Williams,
Tabi Timur-B04825, Zhang Wei
In-Reply-To: <D7CCA83BB0796C49BC0BB53B6AB1208928CABC@zch01exm21.fsl.freescale.net>
Hi Dave,
> For the DMA PCI read/line/multi-line is outbound transaction.
> So according to your experiment, the 8349 PCI controller(as master)
> attemp to streaming/combining the outbound transaction(treated as
> prefetchable space).
Yep, with the MPC8349EA configured as a PCI Target,
and operating as a Bus Master, DMA transfers between
two MPC8349EA targets to prefetchable memory on the
slave will burst at pretty much full-speed over the
PCI bus. The same goes for DMA to the host memory.
However, reading from the host is slower, as the bursts
get chopped up more than they do between two target
boards. At some point I'll get a bunch of screen
captures and put them in a document.
> IIRC, the early 8349EUM has the bit[2]-SE in the POCMRn
> register, and is removed now. Not sure if it does function.
Hey yeah, I looked in the 8349E manual, and it is defined.
I'm not sure why it would be defined there though. I can't
think of why the master would want to disable streaming
based on a bit setting; it should burst until the IOS
says its full. Anyway, the bit is gone now, so we'll
just ignore the fact it existed :)
Cheers,
Dave
^ permalink raw reply
* RE: [PATCH] fsldma: use PCI Read Multiple command
From: Liu Dave-R63238 @ 2009-04-28 2:06 UTC (permalink / raw)
To: David Hawkins, Kumar Gala
Cc: Tabi Timur-B04825, linuxppc-dev, Dan Williams, linux-kernel,
Ira Snyder
In-Reply-To: <49F60F1C.3050300@ovro.caltech.edu>
> >> You can mark the pci inbound window on the 83xx as=20
> >> non-prefetchable(assuming 83xx is host). On a x86 host
> >> I doubt there is any easy way to get non-prefetchable memory.
> One more note; we don't have access to a host-mode MPC8349EA,
> our boards are all targets.
Actually we also can use the inbound window(w/wo prefetchable)
in the agent mode. It doesn't care if it is host or agent.
^ permalink raw reply
* RE: [PATCH] fsldma: use PCI Read Multiple command
From: Liu Dave-R63238 @ 2009-04-28 1:48 UTC (permalink / raw)
To: David Hawkins, Tabi Timur-B04825
Cc: linuxppc-dev, Dan Williams, Zhang Wei, linux-kernel, Ira Snyder
In-Reply-To: <49F608B7.9080409@ovro.caltech.edu>
> Here's a few results from DMA tests between two
> MPC8349EA boards housed in a CPCI chassis.
>=20
> 1. DMA mode register (DMAMRn)
> PCI read command (PRC, bits 11:10)
>=20
> a) DMAMRn[PRC] =3D 00 =3D PCI Read
>=20
> The PCI read command is 6h on the PCI bus.
> For DMA lengths of less than 1 cache line (32-bytes)
> the DMA controller will generate a PCI 6h command.
> However, for lengths of 32-bytes and higher, the
> DMA controller actually generates a PCI Read Line (Eh)
> command.
>=20
> Freescale indicated that this 'change of PCI command code'
> functionality is an undocumented 'feature', there to
> improve performance for longer read lengths.
>=20
> b) DMAMRn[PRC] =3D 01 =3D PCI Read Line
>=20
> Generated the PCI command code for PCI read line (Eh),
> regardless of DMA length.
>=20
> c) DMAMRn[PRC] =3D 10 =3D PCI Read Multiple
>=20
> Generated the PCI command code for PCI Read Multiple (Ch),
> regardless of DMA length.
Good summary!
For the DMA PCI read/line/multi-line is outbound transaction.
So according to your experiment, the 8349 PCI controller(as master)
attemp to streaming/combining the outbound transaction(treated as
prefetchable
space).=20
IIRC, the early 8349EUM has the bit[2]-SE in the POCMRn
register, and is removed now. Not sure if it does function.
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: David Hawkins @ 2009-04-28 1:36 UTC (permalink / raw)
To: Liu Dave-R63238
Cc: linuxppc-dev, Dan Williams, Ira Snyder, Tabi Timur-B04825,
linux-kernel
In-Reply-To: <D7CCA83BB0796C49BC0BB53B6AB1208928CAB2@zch01exm21.fsl.freescale.net>
> How about FIFO RAM case?
If the FIFO has a fixed address, then according to
the user guide, the DMA controller won't generate
a burst transaction to it.
We can try confirming this if you'd like.
Cheers,
Dave
^ permalink raw reply
* RE: [PATCH] fsldma: use PCI Read Multiple command
From: Liu Dave-R63238 @ 2009-04-28 1:31 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: linuxppc-dev, Dan Williams, linux-kernel, Ira Snyder
In-Reply-To: <ed82fe3e0904270731g2d2519a7mc12e4152c716c0a9@mail.gmail.com>
> > You are assuming the PCI memory space is prefetchable( no=20
> > side effect) for DMA.
> > Is it possible that DMA is from non-prefetchable memory space?
>=20
> This should be a safe assumption for this driver. Remember, this
> driver just does offload memcpy, from one region to another. So the
> PCI memory that you are reading from should be just a buffer of data,
> and there should be side-effect of reading it.
>=20
> However, I would like to see a comment at the top of the file warning
> people that copying from PCI memory will result in prefetched reads.
How about FIFO RAM case?
^ permalink raw reply
* Re: [PATCH 1/6] powerpc: Move #ifdef'ed body of do_IRQ() into a separate function
From: Michael Ellerman @ 2009-04-28 0:49 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20090425181823.GA10481@lst.de>
[-- Attachment #1: Type: text/plain, Size: 361 bytes --]
On Sat, 2009-04-25 at 20:18 +0200, Christoph Hellwig wrote:
> On Thu, Apr 23, 2009 at 11:31:37AM +1000, Michael Ellerman wrote:
> > +#ifdef CONFIG_IRQSTACKS
>
> Wasn't there a plan to make CONFIG_IRQSTACKS the unconditional default?
Not sure. Looks like the 64-bit configs all turn it on, and all but one
or two of the 32-bit configs don't.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: "leds: Add openfirmware platform device support" breaks sparc
From: Andrew Morton @ 2009-04-27 22:20 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, rpurdie, tpiepho, smaclennan
In-Reply-To: <20090303.163713.131742043.davem@davemloft.net>
On Tue, 03 Mar 2009 16:37:13 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Sean MacLennan <smaclennan@pikatech.com>
> Date: Tue, 3 Mar 2009 19:29:32 -0500
>
> > It has been..... uhhhh carry the two... longer than I want to admit
> > since I worked on a sparc. Would GPIO based LEDS make sense on a sparc
> > platform? Is sparc used much in the embedded world?
> >
> > If yes, the of_register_platform_driver is just a nice wrapper. It
> > would be trivial to either change it to work on sparc, or add the
> > wrapper to the sparc includes.
>
> We generally create the platform devices by hand for LED
> devices on sparc64.
>
> I'd CONFIG_POWERPC depend this thing for now.
Nobody has done this, so current mainline's sparc64 allmodconfig remains
busted.
This?
--- a/drivers/leds/Kconfig~a
+++ a/drivers/leds/Kconfig
@@ -139,6 +139,7 @@ config LEDS_GPIO_PLATFORM
config LEDS_GPIO_OF
bool "OpenFirmware platform device bindings for GPIO LEDs"
depends on LEDS_GPIO && OF_DEVICE
+ depends on POWERPC
default y
help
Let the leds-gpio driver drive LEDs which have been defined as
_
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Liu Dave-R63238 @ 2009-04-27 21:59 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: Ira Snyder, linux-kernel, linuxppc-dev, Dan Williams, Zhang Wei
In-Reply-To: <ed82fe3e0904270731g2d2519a7mc12e4152c716c0a9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 453 bytes --]
>> You are assuming the PCI memory space is prefetchable( no side effect)
>> for DMA.
>> Is it possible that DMA is from non-prefetchable memory space?
> This should be a safe assumption for this driver. Remember, this
> driver just does offload memcpy, from one region to another. So the
> PCI memory that you are reading from should be just a buffer of data,
> and there should be side-effect of reading it.
How about one FIFO buffer?
[-- Attachment #2: Type: text/html, Size: 925 bytes --]
^ permalink raw reply
* drivers/video/logo/logo_linux_mono.c build error
From: Andrew Morton @ 2009-04-27 21:50 UTC (permalink / raw)
To: linuxppc-dev
powerpc allmodconfig, current mainline:
drivers/video/logo/logo_linux_mono.c:11: error: logo_linux_mono_data causes a section type conflict
switching it from __initconst to __initdata "fixes" it.
I'm (illegally) using gcc-4.1.0.
I assume this is an FAQ but I don't know what the A is ;)
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Dan Williams @ 2009-04-27 20:49 UTC (permalink / raw)
To: Timur Tabi
Cc: David Hawkins, Ira Snyder, Liu Dave-R63238, linux-kernel,
linuxppc-dev
In-Reply-To: <49F619C4.20100@freescale.com>
On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com> wrote:
> Adding Kumar to the CC: list, since he might pick up the patch.
>
Acked-by: Dan Williams <dan.j.williams@intel.com>
I agree with taking this through Kumar's tree.
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Timur Tabi @ 2009-04-27 20:49 UTC (permalink / raw)
To: Scott Wood
Cc: David Hawkins, Ira Snyder, Liu Dave-R63238, linux-kernel,
linuxppc-dev, Dan Williams
In-Reply-To: <20090427204752.GA22406@ld0162-tx32.am.freescale.net>
Scott Wood wrote:
> I thought the driver only used the bit if the device tree indicated it
> was an 83xx-era DMA controller?
I just wanted to make sure it didn't do anything weird. It was the only
test I could think of that didn't involve PCI.
> That said, the bits are documented as specifically for PCI, so it would
> be surprising if it had any effect elsewhere.
Surely you wouldn't really be surprised by incorrect documentation of
our parts. :-)
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Scott Wood @ 2009-04-27 20:47 UTC (permalink / raw)
To: Timur Tabi
Cc: David Hawkins, Ira Snyder, Liu Dave-R63238, linux-kernel,
linuxppc-dev, Dan Williams
In-Reply-To: <49F60FE1.90707@freescale.com>
On Mon, Apr 27, 2009 at 03:04:49PM -0500, Timur Tabi wrote:
> David Hawkins wrote:
>
> > Can you give me an example of non-PCI memory that would be
> > non-prefetchable that you'd like us to try? We can see if our
> > host CPUs have an area like that ... we just need to know
> > what device to look for first :)
>
> Hmmmm.... I was going to say any SOC device in the IMMR, but I don't see
> anything there that would constitute a memory buffer.
>
> I test this change on an 8610 and DMA to a register I/O, where this bit
> isn't even defined, and it made no difference. So I guess this change
> is okay.
I thought the driver only used the bit if the device tree indicated it
was an 83xx-era DMA controller?
That said, the bits are documented as specifically for PCI, so it would
be surprising if it had any effect elsewhere.
-Scott
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Timur Tabi @ 2009-04-27 20:47 UTC (permalink / raw)
To: Ira Snyder
Cc: David Hawkins, Liu Dave-R63238, linux-kernel, linuxppc-dev,
Dan Williams
In-Reply-To: <20090427204213.GA4960@ovro.caltech.edu>
Adding Kumar to the CC: list, since he might pick up the patch.
Ira Snyder wrote:
> From 73e42fa58c93de8d4d429ba8e069b60c42037b58 Mon Sep 17 00:00:00 2001
> From: Ira W. Snyder <iws@ovro.caltech.edu>
> Date: Thu, 23 Apr 2009 16:17:54 -0700
> Subject: [PATCH] fsldma: use PCI Read Multiple command
>
> By default, the Freescale 83xx DMA controller uses the PCI Read Line
> command when reading data over the PCI bus. Setting the controller to use
> the PCI Read Multiple command instead allows the controller to read much
> larger bursts of data, which provides a drastic speed increase.
>
> The slowdown due to using PCI Read Line was only observed when a PCI-to-PCI
> bridge was between the devices trying to communicate.
>
> A simple test driver showed an increase from 4MB/sec to 116MB/sec when
> performing DMA over the PCI bus. Using DMA to transfer between blocks of
> local SDRAM showed no change in performance with this patch. The dmatest
> driver was also used to verify the correctness of the transfers, and showed
> no errors.
>
> Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Acked-by: Timur Tabi <timur@freescale.com>
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: David Hawkins @ 2009-04-27 20:44 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Liu Dave-R63238, linux-kernel, Ira Snyder
In-Reply-To: <49F618D1.2050109@freescale.com>
Timur Tabi wrote:
> David Hawkins wrote:
>
>> Ira will add your comment to the body of the code near
>> the PRC_RM command and submit a new patch.
>
> I'd rather have it near the top where people can see it.
Looks like Ira had the same thought :)
Dave
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Timur Tabi @ 2009-04-27 20:42 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-dev, Liu Dave-R63238, linux-kernel, Ira Snyder
In-Reply-To: <49F6187F.8020703@ovro.caltech.edu>
David Hawkins wrote:
> Ira will add your comment to the body of the code near
> the PRC_RM command and submit a new patch.
I'd rather have it near the top where people can see it.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Ira Snyder @ 2009-04-27 20:42 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev, Dan Williams, Liu Dave-R63238, David Hawkins,
linux-kernel
In-Reply-To: <49F614FC.70000@freescale.com>
On Mon, Apr 27, 2009 at 03:26:36PM -0500, Timur Tabi wrote:
> David Hawkins wrote:
>
> > PRC_RM - PCI read multiple
> > The default PCI read command used by the DMA controller is
> > PCI Read (PCI command 6h). When the burst length is 32-bytes
> > or longer, PCI Read Line (PCI command Eh) is used (undocumented
> > feature of the controller). Using PCI read multiple
> > (PCI command Ch) results in high-performance across PCI
> > bridges. DMA transfers to non-prefetchable PCI registers
> > should not result in prefetched reads, even when using
> > the PCI read multiple command.
>
> I was thinking more along the lines of:
>
> "This driver tells the DMA controller to use the PCI Read Multiple
> command, instead of the PCI Read Line command, for PCI read operations.
> Please be aware that this setting may result in read pre-fetching on
> some platforms."
>
How about the following revised patch? Is it ok to inline it this way,
or should I send another email to the list containing just this patch?
>From 73e42fa58c93de8d4d429ba8e069b60c42037b58 Mon Sep 17 00:00:00 2001
From: Ira W. Snyder <iws@ovro.caltech.edu>
Date: Thu, 23 Apr 2009 16:17:54 -0700
Subject: [PATCH] fsldma: use PCI Read Multiple command
By default, the Freescale 83xx DMA controller uses the PCI Read Line
command when reading data over the PCI bus. Setting the controller to use
the PCI Read Multiple command instead allows the controller to read much
larger bursts of data, which provides a drastic speed increase.
The slowdown due to using PCI Read Line was only observed when a PCI-to-PCI
bridge was between the devices trying to communicate.
A simple test driver showed an increase from 4MB/sec to 116MB/sec when
performing DMA over the PCI bus. Using DMA to transfer between blocks of
local SDRAM showed no change in performance with this patch. The dmatest
driver was also used to verify the correctness of the transfers, and showed
no errors.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
v1 -> v2:
* Added comment warning about possible prefetching
drivers/dma/fsldma.c | 10 ++++++++--
drivers/dma/fsldma.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index da8a8ed..5943ca8 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -12,6 +12,11 @@
* also fit for MPC8560, MPC8555, MPC8548, MPC8641, and etc.
* The support for MPC8349 DMA contorller is also added.
*
+ * This driver instructs the DMA controller to issue the PCI Read Multiple
+ * command for PCI read operations, instead of using the default PCI Read Line
+ * command. Please be aware that this setting may result in read pre-fetching
+ * on some platforms.
+ *
* This is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -49,9 +54,10 @@ static void dma_init(struct fsl_dma_chan *fsl_chan)
case FSL_DMA_IP_83XX:
/* Set the channel to below modes:
* EOTIE - End-of-transfer interrupt enable
+ * PRC_RM - PCI read multiple
*/
- DMA_OUT(fsl_chan, &fsl_chan->reg_base->mr, FSL_DMA_MR_EOTIE,
- 32);
+ DMA_OUT(fsl_chan, &fsl_chan->reg_base->mr, FSL_DMA_MR_EOTIE
+ | FSL_DMA_MR_PRC_RM, 32);
break;
}
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index 4f21a51..dc7f268 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -38,6 +38,7 @@
/* Special MR definition for MPC8349 */
#define FSL_DMA_MR_EOTIE 0x00000080
+#define FSL_DMA_MR_PRC_RM 0x00000800
#define FSL_DMA_SR_CH 0x00000020
#define FSL_DMA_SR_PE 0x00000010
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: David Hawkins @ 2009-04-27 20:41 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev, Dan Williams, Liu Dave-R63238, linux-kernel,
Ira Snyder
In-Reply-To: <49F614FC.70000@freescale.com>
Hi Timur,
>> PRC_RM - PCI read multiple
>> The default PCI read command used by the DMA controller is
>> PCI Read (PCI command 6h). When the burst length is 32-bytes
>> or longer, PCI Read Line (PCI command Eh) is used (undocumented
>> feature of the controller). Using PCI read multiple
>> (PCI command Ch) results in high-performance across PCI
>> bridges. DMA transfers to non-prefetchable PCI registers
>> should not result in prefetched reads, even when using
>> the PCI read multiple command.
>
> I was thinking more along the lines of:
>
> "This driver tells the DMA controller to use the PCI Read Multiple
> command, instead of the PCI Read Line command, for PCI read operations.
> Please be aware that this setting may result in read pre-fetching on
> some platforms."
Ok, thanks.
Ira will add your comment to the body of the code near
the PRC_RM command and submit a new patch.
Cheers,
Dave
^ permalink raw reply
* [PATCH 2/2] powerpc/85xx: Add new LAW & MCM device tree nodes for all 85xx systems
From: Kumar Gala @ 2009-04-27 20:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss
In-Reply-To: <1240864725-29003-1-git-send-email-galak@kernel.crashing.org>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/boot/dts/ksi8560.dts | 13 +++++++++++++
arch/powerpc/boot/dts/mpc8536ds.dts | 13 +++++++++++++
arch/powerpc/boot/dts/mpc8540ads.dts | 13 +++++++++++++
arch/powerpc/boot/dts/mpc8541cds.dts | 13 +++++++++++++
arch/powerpc/boot/dts/mpc8544ds.dts | 13 +++++++++++++
arch/powerpc/boot/dts/mpc8548cds.dts | 13 +++++++++++++
arch/powerpc/boot/dts/mpc8555cds.dts | 13 +++++++++++++
arch/powerpc/boot/dts/mpc8560ads.dts | 13 +++++++++++++
arch/powerpc/boot/dts/mpc8568mds.dts | 13 +++++++++++++
arch/powerpc/boot/dts/mpc8572ds.dts | 13 +++++++++++++
arch/powerpc/boot/dts/mpc8572ds_36b.dts | 13 +++++++++++++
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 13 +++++++++++++
arch/powerpc/boot/dts/sbc8548.dts | 13 +++++++++++++
arch/powerpc/boot/dts/sbc8560.dts | 13 +++++++++++++
arch/powerpc/boot/dts/socrates.dts | 13 +++++++++++++
arch/powerpc/boot/dts/stx_gp3_8560.dts | 13 +++++++++++++
arch/powerpc/boot/dts/tqm8540.dts | 13 +++++++++++++
arch/powerpc/boot/dts/tqm8541.dts | 13 +++++++++++++
arch/powerpc/boot/dts/tqm8548-bigflash.dts | 13 +++++++++++++
arch/powerpc/boot/dts/tqm8548.dts | 13 +++++++++++++
arch/powerpc/boot/dts/tqm8555.dts | 13 +++++++++++++
arch/powerpc/boot/dts/tqm8560.dts | 13 +++++++++++++
22 files changed, 286 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/ksi8560.dts b/arch/powerpc/boot/dts/ksi8560.dts
index c9cfd37..bdb7fc0 100644
--- a/arch/powerpc/boot/dts/ksi8560.dts
+++ b/arch/powerpc/boot/dts/ksi8560.dts
@@ -56,6 +56,19 @@
ranges = <0x00000000 0xfdf00000 0x00100000>;
bus-frequency = <0>; /* Fixed by bootwrapper */
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <8>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8560-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8540-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/mpc8536ds.dts b/arch/powerpc/boot/dts/mpc8536ds.dts
index af8c64c..b6fd856 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dts
+++ b/arch/powerpc/boot/dts/mpc8536ds.dts
@@ -54,6 +54,19 @@
reg = <0xffe00000 0x1000>;
bus-frequency = <0>; // Filled out by uboot.
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <12>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8536-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8536-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts b/arch/powerpc/boot/dts/mpc8540ads.dts
index de5535c..7c8b109 100644
--- a/arch/powerpc/boot/dts/mpc8540ads.dts
+++ b/arch/powerpc/boot/dts/mpc8540ads.dts
@@ -58,6 +58,19 @@
reg = <0xe0000000 0x100000>; // CCSRBAR 1M
bus-frequency = <0>;
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <8>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8540-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,8540-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/mpc8541cds.dts b/arch/powerpc/boot/dts/mpc8541cds.dts
index d10f5d6..de9d8b5 100644
--- a/arch/powerpc/boot/dts/mpc8541cds.dts
+++ b/arch/powerpc/boot/dts/mpc8541cds.dts
@@ -58,6 +58,19 @@
reg = <0xe0000000 0x1000>; // CCSRBAR 1M
bus-frequency = <0>;
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <8>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8541-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,8541-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts b/arch/powerpc/boot/dts/mpc8544ds.dts
index 3ae31d7..9819d6c 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -60,6 +60,19 @@
reg = <0xe0000000 0x1000>; // CCSRBAR 1M
bus-frequency = <0>; // Filled out by uboot.
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8544-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,8544-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts b/arch/powerpc/boot/dts/mpc8548cds.dts
index 732c111..6e40db7 100644
--- a/arch/powerpc/boot/dts/mpc8548cds.dts
+++ b/arch/powerpc/boot/dts/mpc8548cds.dts
@@ -63,6 +63,19 @@
reg = <0xe0000000 0x1000>; // CCSRBAR
bus-frequency = <0>;
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8548-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,8548-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/mpc8555cds.dts b/arch/powerpc/boot/dts/mpc8555cds.dts
index 7f9e535..6291497 100644
--- a/arch/powerpc/boot/dts/mpc8555cds.dts
+++ b/arch/powerpc/boot/dts/mpc8555cds.dts
@@ -58,6 +58,19 @@
reg = <0xe0000000 0x1000>; // CCSRBAR 1M
bus-frequency = <0>;
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <8>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8555-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,8555-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/mpc8560ads.dts b/arch/powerpc/boot/dts/mpc8560ads.dts
index 190d46b..a2347b5 100644
--- a/arch/powerpc/boot/dts/mpc8560ads.dts
+++ b/arch/powerpc/boot/dts/mpc8560ads.dts
@@ -58,6 +58,19 @@
reg = <0xe0000000 0x200>;
bus-frequency = <330000000>;
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <8>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8560-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,8540-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 3330356..d2fb639 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -65,6 +65,19 @@
reg = <0xe0000000 0x1000>;
bus-frequency = <0>;
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8568-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,8568-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts b/arch/powerpc/boot/dts/mpc8572ds.dts
index 75fc30b..3f9a623 100644
--- a/arch/powerpc/boot/dts/mpc8572ds.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds.dts
@@ -185,6 +185,19 @@
reg = <0 0xffe00000 0 0x1000>; // CCSRBAR & soc regs, remove once parse code for immrbase fixed
bus-frequency = <0>; // Filled out by uboot.
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <12>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8572-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8572-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/mpc8572ds_36b.dts b/arch/powerpc/boot/dts/mpc8572ds_36b.dts
index e2a1f75..fee17f3 100644
--- a/arch/powerpc/boot/dts/mpc8572ds_36b.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds_36b.dts
@@ -185,6 +185,19 @@
reg = <0xf 0xffe00000 0 0x1000>; // CCSRBAR & soc regs, remove once parse code for immrbase fixed
bus-frequency = <0>; // Filled out by uboot.
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <12>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8572-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8572-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts b/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts
index 45ca89e..abb1730 100644
--- a/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts
@@ -62,6 +62,19 @@
reg = <0xffe00000 0x1000>; // CCSRBAR & soc regs, remove once parse code for immrbase fixed
bus-frequency = <0>; // Filled out by uboot.
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <12>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8572-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8572-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/sbc8548.dts b/arch/powerpc/boot/dts/sbc8548.dts
index 196fcc1..66c9165 100644
--- a/arch/powerpc/boot/dts/sbc8548.dts
+++ b/arch/powerpc/boot/dts/sbc8548.dts
@@ -155,6 +155,19 @@
bus-frequency = <0>;
compatible = "simple-bus";
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8548-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8548-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/sbc8560.dts b/arch/powerpc/boot/dts/sbc8560.dts
index 813d731..ff6a522 100644
--- a/arch/powerpc/boot/dts/sbc8560.dts
+++ b/arch/powerpc/boot/dts/sbc8560.dts
@@ -60,6 +60,19 @@
reg = <0xff700000 0x00100000>;
clock-frequency = <0>;
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <8>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8560-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8560-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/socrates.dts b/arch/powerpc/boot/dts/socrates.dts
index e8f4e46..779876a 100644
--- a/arch/powerpc/boot/dts/socrates.dts
+++ b/arch/powerpc/boot/dts/socrates.dts
@@ -59,6 +59,19 @@
bus-frequency = <0>; // Filled in by U-Boot
compatible = "fsl,mpc8544-immr", "simple-bus";
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8544-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8544-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/stx_gp3_8560.dts b/arch/powerpc/boot/dts/stx_gp3_8560.dts
index 8691dd3..ce35e89 100644
--- a/arch/powerpc/boot/dts/stx_gp3_8560.dts
+++ b/arch/powerpc/boot/dts/stx_gp3_8560.dts
@@ -56,6 +56,19 @@
bus-frequency = <0>;
compatible = "fsl,mpc8560-immr", "simple-bus";
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <8>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8560-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8540-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/tqm8540.dts b/arch/powerpc/boot/dts/tqm8540.dts
index c8265b6..5e9eecc 100644
--- a/arch/powerpc/boot/dts/tqm8540.dts
+++ b/arch/powerpc/boot/dts/tqm8540.dts
@@ -58,6 +58,19 @@
bus-frequency = <0>;
compatible = "fsl,mpc8540-immr", "simple-bus";
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <8>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8540-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8540-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/tqm8541.dts b/arch/powerpc/boot/dts/tqm8541.dts
index 9080546..3c8d5c1 100644
--- a/arch/powerpc/boot/dts/tqm8541.dts
+++ b/arch/powerpc/boot/dts/tqm8541.dts
@@ -57,6 +57,19 @@
bus-frequency = <0>;
compatible = "fsl,mpc8541-immr", "simple-bus";
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <8>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8541-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8540-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/tqm8548-bigflash.dts b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
index 1139eb5..435d2b2 100644
--- a/arch/powerpc/boot/dts/tqm8548-bigflash.dts
+++ b/arch/powerpc/boot/dts/tqm8548-bigflash.dts
@@ -59,6 +59,19 @@
bus-frequency = <0>;
compatible = "fsl,mpc8548-immr", "simple-bus";
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8548-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8548-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/tqm8548.dts b/arch/powerpc/boot/dts/tqm8548.dts
index d337d83..3b8af5b 100644
--- a/arch/powerpc/boot/dts/tqm8548.dts
+++ b/arch/powerpc/boot/dts/tqm8548.dts
@@ -59,6 +59,19 @@
bus-frequency = <0>;
compatible = "fsl,mpc8548-immr", "simple-bus";
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8548-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8548-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/tqm8555.dts b/arch/powerpc/boot/dts/tqm8555.dts
index 021039b..a820bbe 100644
--- a/arch/powerpc/boot/dts/tqm8555.dts
+++ b/arch/powerpc/boot/dts/tqm8555.dts
@@ -57,6 +57,19 @@
bus-frequency = <0>;
compatible = "fsl,mpc8555-immr", "simple-bus";
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <8>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8555-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8540-memory-controller";
reg = <0x2000 0x1000>;
diff --git a/arch/powerpc/boot/dts/tqm8560.dts b/arch/powerpc/boot/dts/tqm8560.dts
index cec84c2..fa73550 100644
--- a/arch/powerpc/boot/dts/tqm8560.dts
+++ b/arch/powerpc/boot/dts/tqm8560.dts
@@ -59,6 +59,19 @@
bus-frequency = <0>;
compatible = "fsl,mpc8560-immr", "simple-bus";
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <8>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8560-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
memory-controller@2000 {
compatible = "fsl,mpc8540-memory-controller";
reg = <0x2000 0x1000>;
--
1.6.0.6
^ permalink raw reply related
* [PATCH 1/2] powerpc/85xx: Add binding for LAWs and MCM
From: Kumar Gala @ 2009-04-27 20:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss
The first 4k region of CCSR space is well defined for local access
windows, CCSRBAR, etc. The second 4k region is well defined as
register for configuring and getting errors for the ECM coherency
module.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Documentation/powerpc/dts-bindings/ecm.txt | 64 ++++++++++++++++++++++++++++
1 files changed, 64 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/ecm.txt
diff --git a/Documentation/powerpc/dts-bindings/ecm.txt b/Documentation/powerpc/dts-bindings/ecm.txt
new file mode 100644
index 0000000..f514f29
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/ecm.txt
@@ -0,0 +1,64 @@
+=====================================================================
+E500 LAW & Coherency Module Device Tree Binding
+Copyright (C) 2009 Freescale Semiconductor Inc.
+=====================================================================
+
+Local Access Window (LAW) Node
+
+The LAW node represents the region of CCSR space where local access
+windows are configured. For ECM based devices this is the first 4k
+of CCSR space that includes CCSRBAR, ALTCBAR, ALTCAR, BPTR, and some
+number of local access windows as specified by fsl,num-laws.
+
+PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type: <string>
+ Definition: Must include "fsl,ecm-law"
+
+ - reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property. The value specifies the
+ physical address offset and length of the CCSR space
+ registers.
+
+ - fsl,num-laws
+ Usage: required
+ Value type: <u32>
+ Definition: The value specifies the number of local access
+ windows for this device.
+
+=====================================================================
+
+E500 Coherency Module Node
+
+The E500 LAW node represents the region of CCSR space where ECM config
+and error reporting registers exist, this is the second 4k (0x1000)
+of CCSR space.
+
+PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type: <string>
+ Definition: Must include "fsl,CHIP-ecm", "fsl,ecm" where
+ CHIP is the processor (mpc8572, mpc8544, etc.)
+
+ - reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property. The value specifies the
+ physical address offset and length of the CCSR space
+ registers.
+
+ - interrupts
+ Usage: required
+ Value type: <prop-encoded-array>
+
+ - interrupt-parent
+ Usage: required
+ Value type: <phandle>
+
+=====================================================================
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Timur Tabi @ 2009-04-27 20:26 UTC (permalink / raw)
To: David Hawkins
Cc: linuxppc-dev, Dan Williams, Liu Dave-R63238, linux-kernel,
Ira Snyder
In-Reply-To: <49F61416.8040501@ovro.caltech.edu>
David Hawkins wrote:
> PRC_RM - PCI read multiple
> The default PCI read command used by the DMA controller is
> PCI Read (PCI command 6h). When the burst length is 32-bytes
> or longer, PCI Read Line (PCI command Eh) is used (undocumented
> feature of the controller). Using PCI read multiple
> (PCI command Ch) results in high-performance across PCI
> bridges. DMA transfers to non-prefetchable PCI registers
> should not result in prefetched reads, even when using
> the PCI read multiple command.
I was thinking more along the lines of:
"This driver tells the DMA controller to use the PCI Read Multiple
command, instead of the PCI Read Line command, for PCI read operations.
Please be aware that this setting may result in read pre-fetching on
some platforms."
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: David Hawkins @ 2009-04-27 20:22 UTC (permalink / raw)
To: Timur Tabi
Cc: linuxppc-dev, Dan Williams, Liu Dave-R63238, linux-kernel,
Ira Snyder
In-Reply-To: <49F60A3A.4060402@freescale.com>
Hi Timur,
>> Would you like some sort of summary of this info for a commit
>> message?
>
> That's probably overkill. I just want a sentence or two that tells
> someone looking at the code casually that the behavior of reading PCI
> memory might be different than what they expect.
Could you help us with the wording you'd like to see in the code.
Did you want to see something in the header comments, or something
near the register settings?
How about something like this in place of the existing PCI_RM
comment:
PRC_RM - PCI read multiple
The default PCI read command used by the DMA controller is
PCI Read (PCI command 6h). When the burst length is 32-bytes
or longer, PCI Read Line (PCI command Eh) is used (undocumented
feature of the controller). Using PCI read multiple
(PCI command Ch) results in high-performance across PCI
bridges. DMA transfers to non-prefetchable PCI registers
should not result in prefetched reads, even when using
the PCI read multiple command.
Cheers,
Dave
^ permalink raw reply
* Please pull from 'merge' branch for 2.6.30 (updated)
From: Kumar Gala @ 2009-04-27 20:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Paul,
Can we possibly get this and the other pull requests dealt with and sent
to Linus so we might get such fixes in before he tags a -rc4.
thanks
- k
Please pull from 'merge' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
to receive the following updates:
arch/powerpc/boot/dts/gef_ppc9a.dts | 1 +
arch/powerpc/include/asm/mmu.h | 6 ------
arch/powerpc/include/asm/ppc-opcode.h | 11 +----------
arch/powerpc/kernel/cputable.c | 2 +-
arch/powerpc/mm/tlb_nohash_low.S | 16 ++--------------
5 files changed, 5 insertions(+), 31 deletions(-)
Kumar Gala (1):
Revert "powerpc: Add support for early tlbilx opcode"
Martyn Welch (1):
powerpc/86xx: Add device_type entry to soc for ppc9a
Stephen Rothwell (1):
powerpc: fix for long standing bug noticed by gcc 4.4.0
^ 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