* Re: [PATCH] powerpc/mpc52xx/mtd: fix mtd-ram access for 16-bit Local Plus Bus
From: Grant Likely @ 2009-06-11 17:28 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Albrecht Dreß, dwmw2, Linux PPC Development
In-Reply-To: <20090611165527.GB28028@pengutronix.de>
On Thu, Jun 11, 2009 at 10:55 AM, Wolfram Sang<w.sang@pengutronix.de> wrote=
:
>> Blech. =A0ugly #ifdef and not really multiplatform safe (yeah, I know it
>> shouldn't break non-5200 platforms, but it does have an undesirable
>> impact). =A0There's got to be a better way.
>
> What about putting the special memcpy in asm/io.h (like it is done for ee=
h)?
It is a beefy enough function that it is probably a net loss to make
it an inline static in the header file. It should be an exported
function.
> Will this cause too much overhead for a memcpy which does not go to the L=
PB?
It doesn't solve my concerns. bankwidth=3D=3D2 is the wrong test; plenty
of non-mpc5200 platforms could have the same property set without
needing the workaround.
inline_map_copy_to is used in exactly 2 places in drivers/mtd/* and
include/linux/mtd/*:
1) the definition of map_copy_to() in include/linux/mtd/map.h
- map_copy_to() is only used by maprap_write() which is a mtd_info hook.
2) the definition of simple_map_copy_to() in drivers/mtd/maps/map_funcs.c
- a map_info hook.
So; the solution to me seems to be on an MPC5200 platform replace the
offending hooks with MPC5200 specific variants at runtime.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation
From: Grant Likely @ 2009-06-11 17:30 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: Linux PPC Development
In-Reply-To: <1243454441.3489.1@antares>
On Wed, May 27, 2009 at 2:00 PM, Albrecht Dre=DF<albrecht.dress@arcor.de> w=
rote:
> This trivial patch changes memcpy_(to|from)io as to transfer as many 32-b=
it
> words as possible in 32-bit accesses (in the current solution, the last
> 32-bit word was transferred as 4 byte accesses).
>
> Signed-off-by: Albrecht Dre=DF <albrecht.dress@arcor.de>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> diff -urpN -X linux-2.6.29.1.orig/Documentation/dontdiff
> linux-2.6.29.1.orig/arch/powerpc/kernel/io.c
> linux-2.6.29.1/arch/powerpc/kernel/io.c
> --- linux-2.6.29.1.orig/arch/powerpc/kernel/io.c =A0 =A0 =A0 =A02009-04-0=
2
> 22:55:27.000000000 +0200
> +++ linux-2.6.29.1/arch/powerpc/kernel/io.c =A0 =A0 2009-05-27
> 11:36:09.000000000 +0200
> @@ -161,7 +161,7 @@ void _memcpy_fromio(void *dest, const vo
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dest++;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0n--;
> =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 while(n > 4) {
> + =A0 =A0 =A0 while(n >=3D 4) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*((u32 *)dest) =3D *((volatile u32 *)vsrc)=
;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0eieio();
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vsrc +=3D 4;
> @@ -190,7 +190,7 @@ void _memcpy_toio(volatile void __iomem
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vdest++;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0n--;
> =A0 =A0 =A0 =A0}
> - =A0 =A0 =A0 while(n > 4) {
> + =A0 =A0 =A0 while(n >=3D 4) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0*((volatile u32 *)vdest) =3D *((volatile u=
32 *)src);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0src +=3D 4;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0vdest +=3D 4;
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation
From: Wolfram Sang @ 2009-06-11 17:07 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: Linux PPC Development
In-Reply-To: <1243454441.3489.1@antares>
[-- Attachment #1: Type: text/plain, Size: 602 bytes --]
On Wed, May 27, 2009 at 10:00:41PM +0200, Albrecht Dreß wrote:
> This trivial patch changes memcpy_(to|from)io as to transfer as many
> 32-bit words as possible in 32-bit accesses (in the current solution,
> the last 32-bit word was transferred as 4 byte accesses).
>
> Signed-off-by: Albrecht Dreß <albrecht.dress@arcor.de>
Besides the discussion about optimizing the loop, what about the patch itself?
Looks plausible to me...
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: "next" branch update
From: Josh Boyer @ 2009-06-11 17:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1244603678.2431.18.camel@pasglop>
Quoting Benjamin Herrenschmidt <benh@kernel.crashing.org>:
> Hi !
>
> I've updated my "next" branch with the following patches. We're getting
> real close to the merge window now, so if something is missing, please
> holler ASAP.
Could you please pull the 'next' branch of the 4xx tree? I haven't
had a chance to generate a formal pull request due to travel and now
an unexpected family issue.
josh
^ permalink raw reply
* Re: [PATCH] powerpc/mpc52xx/mtd: fix mtd-ram access for 16-bit Local Plus Bus
From: Wolfram Sang @ 2009-06-11 16:55 UTC (permalink / raw)
To: Grant Likely; +Cc: Albrecht Dreß, dwmw2, Linux PPC Development
In-Reply-To: <fa686aa40906110927w60a5a74alaa3420b9bf3f3e44@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
> Blech. ugly #ifdef and not really multiplatform safe (yeah, I know it
> shouldn't break non-5200 platforms, but it does have an undesirable
> impact). There's got to be a better way.
What about putting the special memcpy in asm/io.h (like it is done for eeh)?
Will this cause too much overhead for a memcpy which does not go to the LPB?
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/mpc52xx/mtd: fix mtd-ram access for 16-bit Local Plus Bus
From: Grant Likely @ 2009-06-11 16:27 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: Linux PPC Development, dwmw2
In-Reply-To: <1244576781.3455.0@antares>
On Tue, Jun 9, 2009 at 1:46 PM, Albrecht Dre=DF<albrecht.dress@arcor.de> wr=
ote:
> Hi all,
>
> this patch adds support for RAM chips connected to the Local Plus Bus of =
a
> MPC5200B in 16-bit mode. =A0As no single byte write accesses are allowed =
by
> the bus in this mode, a byte write has to be split into a word read - mod=
ify
> - write sequence (mpc52xx_memcpy2lpb16, as fix/extension for memcpy_toio;
> note that memcpy_fromio *does* work just fine). =A0It has been tested in
> conjunction with Wolfram Sang's mtd-ram [1] and Sascha Hauer's jffs
> unaligned access [2] patches on 2.6.29.1, with a Renesas static RAM
> connected in 16-bit "Large Flash" mode.
>
> [1] <http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072794.html=
>
> [2] <http://article.gmane.org/gmane.linux.drivers.mtd/21521>
>
> Signed-off-by: Albrecht Dre=DF <albrecht.dress@arcor.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: linuxppc-dev@ozlabs.org
>
> ---
>
> diff -u linux-2.6.29.1.orig/arch/powerpc/platforms/52xx/mpc52xx_common.c
> linux-2.6.29.1/arch/powerpc/platforms/52xx/mpc52xx_common.c
> --- linux-2.6.29.1.orig/arch/powerpc/platforms/52xx/mpc52xx_common.c
> =A02009-04-02 22:55:27.000000000 +0200
> +++ linux-2.6.29.1/arch/powerpc/platforms/52xx/mpc52xx_common.c 2009-06-0=
9
> 21:16:22.000000000 +0200
> @@ -225,3 +225,59 @@
>
> =A0 =A0 =A0 =A0while (1);
> =A0}
> +
> +/**
> + * mpc52xx_memcpy2lpb16: copy data to the Local Plus Bus in 16-bit mode
> which
> + * doesn't allow byte accesses
> + */
> +void
> +mpc52xx_memcpy2lpb16(volatile void __iomem *dest, const void *src,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned long n)
> +{
> + =A0 =A0 =A0 void *vdest =3D (void __force *) dest;
> +
> + =A0 =A0 =A0 __asm__ __volatile__ ("sync" : : : "memory");
> +
> + =A0 =A0 =A0 if (((unsigned long) vdest & 1) !=3D 0) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 u8 buf[2];
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 *(u16 *)buf =3D *((volatile u16 *)(vdest - =
1));
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 buf[1] =3D *((u8 *)src);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 *((volatile u16 *)(vdest - 1)) =3D *(u16 *)=
buf;
what is the purpose of volatile here? If you need io barriers, then
use the in_/out_be16 macros.
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 src++;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 vdest++;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 n--;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 /* looks weird, but helps the optimiser... */
> + =A0 =A0 =A0 if (n >=3D 4) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 unsigned long chunks =3D n >> 2;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 volatile u32 * _dst =3D (volatile u32 *)(vd=
est - 4);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 volatile u32 * _src =3D (volatile u32 *)(sr=
c - 4);
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 vdest +=3D chunks << 2;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 src +=3D chunks << 2;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 do {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *++_dst =3D *++_src;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 } while (--chunks);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 n &=3D 3;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 if (n >=3D 2) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 *((volatile u16 *)vdest) =3D *((volatile u1=
6 *)src);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 src +=3D 2;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 vdest +=3D 2;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 n -=3D 2;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 if (n > 0) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 u8 buf[2];
> +
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 *(u16 *)buf =3D *((volatile u16 *)vdest);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 buf[0] =3D *((u8 *)src);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 *((volatile u16 *)vdest) =3D *(u16 *)buf;
ditto.
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 __asm__ __volatile__ ("sync" : : : "memory");
> +}
> +EXPORT_SYMBOL(mpc52xx_memcpy2lpb16);
> diff -u linux-2.6.29.1.orig/arch/powerpc/include/asm/mpc52xx.h
> linux-2.6.29.1/arch/powerpc/include/asm/mpc52xx.h
> --- linux-2.6.29.1.orig/arch/powerpc/include/asm/mpc52xx.h =A0 =A0 =A0200=
9-04-02
> 22:55:27.000000000 +0200
> +++ linux-2.6.29.1/arch/powerpc/include/asm/mpc52xx.h =A0 2009-06-09
> 21:14:31.000000000 +0200
> @@ -274,6 +274,8 @@
> =A0extern void mpc52xx_map_common_devices(void);
> =A0extern int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv);
> =A0extern void mpc52xx_restart(char *cmd);
> +extern void mpc52xx_memcpy2lpb16(volatile void __iomem *dest, const void
> *src,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unsigned=
long n);
>
> =A0/* mpc52xx_pic.c */
> =A0extern void mpc52xx_init_irq(void);
> diff -u linux-2.6.29.1.orig/include/linux/mtd/map.h
> linux-2.6.29.1/include/linux/mtd/map.h
> --- linux-2.6.29.1.orig/include/linux/mtd/map.h 2009-04-02
> 22:55:27.000000000 +0200
> +++ linux-2.6.29.1/include/linux/mtd/map.h =A0 =A0 =A02009-06-08
> 14:28:05.000000000 +0200
> @@ -13,6 +13,9 @@
> =A0#include <asm/unaligned.h>
> =A0#include <asm/system.h>
> =A0#include <asm/io.h>
> +#ifdef CONFIG_PPC_MPC52xx
> +#include <asm/mpc52xx.h>
> +#endif
>
> =A0#ifdef CONFIG_MTD_MAP_BANK_WIDTH_1
> =A0#define map_bankwidth(map) 1
> @@ -417,6 +420,11 @@
>
> =A0static inline void inline_map_copy_to(struct map_info *map, unsigned l=
ong
> to, const void *from, ssize_t len)
> =A0{
> +#ifdef CONFIG_PPC_MPC52xx
> + =A0 =A0 =A0 if (map->bankwidth =3D=3D 2)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 mpc52xx_memcpy2lpb16(map->virt + to, from, =
len);
> + =A0 =A0 =A0 else
> +#endif
> =A0 =A0 =A0 =A0memcpy_toio(map->virt + to, from, len);
> =A0}
Blech. ugly #ifdef and not really multiplatform safe (yeah, I know it
shouldn't break non-5200 platforms, but it does have an undesirable
impact). There's got to be a better way.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: MPC5200B: Can't receive/handle external Interrupts
From: Grant Likely @ 2009-06-11 16:18 UTC (permalink / raw)
To: Schaller Stephan; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <C10D11C8340AFC47891731EA67CD31C20162F071EFC7@stwex.stww2k.local>
On Wed, Jun 10, 2009 at 12:03 PM, Schaller
Stephan<Stephan.Schaller@sensor-technik.de> wrote:
> So, basically two Problems:
> - ISR seems only to get called by a "Main Interrupt", not by a "IRQ Interrupt". How do I make the connection between these?
This is probably due to the way the IRQ driver reads the irq registers
to decide what interrupts are pending. I wouldn't worry about it.
> - The IRQ3 input Pin level is not shown in the status register and is not regognized by the CPU.
Odd. This shouldn't happen. Is your hardware okay?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: System clock systems to be twice as fast as RTC
From: Nate Case @ 2009-06-11 16:07 UTC (permalink / raw)
To: Subodh Nijsure; +Cc: linuxppc-dev
In-Reply-To: <008701c9eaa7$3c8336c0$8dde520a@cisco.com>
On Thu, 2009-06-11 at 08:13 -0700, Subodh Nijsure wrote:
> The system clock seems to be running twice as as fast as RTC,
>
> sh-2.05b# date ; sleep 60 ; date
> Fri Sep 11 01:37:11 UTC 1970
> Fri Sep 11 01:37:41 UTC 1970
That's strange, but note that "date" reads the system clock and not the
RTC. Use "hwclock" for the RTC.
--
Nate Case <ncase@xes-inc.com>
^ permalink raw reply
* Re: [PATCH v2 -next] powerpc/85xx: Add support for X-ES MPC85xx boards
From: Nate Case @ 2009-06-11 16:04 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20090611013201.GA31850@yookeroo.seuss>
Hi David,
Thanks for the comments.
On Thu, 2009-06-11 at 11:32 +1000, David Gibson wrote:
> These last two aren't standard properties, so should probably be
> "xes,form-factor" and "xes,boot-bank".
I'll just delete them for now since they're not critical.
> > + pmcslots {
>
> What does this structure model? Without any reg properties it's kind
> of hard to see what you could do with it.
This would be a bit more obvious to those familiar with CompactPCI and
PMC modules. It aims to describe how many PMC slots are in the system,
and gives information on whether or not a module is installed and if
it's monarch of the bus or not. So it's really just a description of
the hardware. The properties themselves are useful because you may have
to read from GPIO lines to get this information (which may be accessible
only via I2C, which can't be done too early in the kernel). A reg
property could be used just for indexing the slots, but there are no
real memory-mapped resources involved for the slot itself (that
information would go in the PCI nodes).
It'd be nice if we could get a device tree standard for this type of
information in the future, but for now I can just delete it since we
don't yet rely on it in the kernel.
> > +
> > + tbi2: tbi-phy@11 {
> > + reg = <0x11>;
> > + device_type = "tbi-phy";
>
> And this one, too. Although this node should probably have a
> compatible property instead.
I don't think I can drop that device_type yet. All the other device
trees for Freescale boards use it, and the Freescale MDIO driver appears
to rely on it. A future patch I suppose?
> Analagous comments for the other device trees.
Thanks again. I'll fix up the other things you and Kumar mentioned and
re-submit today.
--
Nate Case <ncase@xes-inc.com>
^ permalink raw reply
* System clock systems to be twice as fast as RTC
From: Subodh Nijsure @ 2009-06-11 15:13 UTC (permalink / raw)
To: linuxppc-dev
I am running system with kernel 2.6.10 with following cpuinfo
sh-2.05b# cat /proc/cpuinfo
processor : 0
cpu : 440 in Virtex-5 FXT
clock : 200MHz
revision : 25.18 (pvr 7ff2 1912)
bogomips : 296.96
machine : Xilinx ML507 PPC440 evaluation board
plb bus clock : 100MHz
The system clock seems to be running twice as as fast as RTC,
sh-2.05b# date ; sleep 60 ; date
Fri Sep 11 01:37:11 UTC 1970
Fri Sep 11 01:37:41 UTC 1970
sh-2.05b# date ; sleep 60 ; date
Fri Sep 11 01:38:21 UTC 1970
Fri Sep 11 01:38:51 UTC 1970
sh-2.05b# date ; sleep 60 ; date
Fri Sep 11 01:38:59 UTC 1970
Fri Sep 11 01:39:29 UTC 1970
I have tried various values of CONFIG_HZ and that didn't help. Google
searches has shown up this issue on X86 system but not on PPC. Any hints as
to what I should be looking for? I have included relevant portion of config
file..
/Subodh
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ASM_SEMAPHORES=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_GENERIC_NVRAM=y
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SEMMNI=128
CONFIG_SYSVIPC_SEMMSL=250
CONFIG_POSIX_MQUEUE=y
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_LTT_MAX_HANDLES=128
CONFIG_LOCKLESS=y
CONFIG_BOOT_FLIGHT_BUFFERS=4
CONFIG_BOOT_FLIGHT_SIZE=524288
CONFIG_FLIGHT_PROC_BUFFERS=8
CONFIG_FLIGHT_PROC_SIZE=8192
CONFIG_NEWEV=y
CONFIG_CSTM=y
CONFIG_CREATE_DEV_CONSOLE=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_KMOD=y
CONFIG_44x=y
CONFIG_BOOKE=y
CONFIG_PTE_64BIT=y
CONFIG_PHYS_64BIT=y
CONFIG_MATH_EMULATION=y
CONFIG_4xx=y
CONFIG_XILINX_ML507=y
CONFIG_XILINX_OCP=y
CONFIG_XILINX_VIRTEX_5_FX=y
CONFIG_XILINX_VIRTEX=y
CONFIG_EMBEDDEDBOOT=y
CONFIG_PPC_GEN550=y
CONFIG_UART0_TTYS0=y
CONFIG_NOT_COHERENT_CACHE=y
CONFIG_PREEMPT_DESKTOP=y
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BINFMT_ELF=y
CONFIG_CMDLINE_BOOL=y
CONFIG_CMDLINE="console=ttyS0,9600n8 initrd=0x1800000,32M rw root=/dev/ram
ip=$(ipaddr)::(gatewayip):$(subnetmask)::eth0:none eth=$(ethaddr)"
<snip>
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Ira Snyder @ 2009-06-11 15:17 UTC (permalink / raw)
To: Kumar Gala
Cc: David Hawkins, Liu Dave-R63238, linux-kernel, linuxppc-dev,
Dan Williams, Li Yang, Timur Tabi
In-Reply-To: <09185A86-F744-4302-A78A-04E1FFFA32BD@kernel.crashing.org>
On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote:
>
> On Apr 27, 2009, at 3:49 PM, Dan Williams wrote:
>
>> 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.
>
> I'm going through patches for .31.. Should I still pick this up? Going
> forward should I pick up fsldma patches?
>
I'm fine with that, but you should probably talk to Li Yang (added to
CC). He's gotten in contact with me a few times recently.
In addition to the PCI Read Multiple patch, I've posted a few more
fsldma patches to ppcdev recently:
fsldma: enable external start for the 83xx controller
fsldma: do not clear bandwidth control bits on the 83xx controller
fsldma: Add DMA_SLAVE support
The first two are very straightforward. The third probably needs some
review before it can be picked up, though. It is well tested, I've been
using it for a few weeks without issues.
Thanks,
Ira
^ permalink raw reply
* Re: [PATCH][POWERPC] mpc83xx : allow SPI without cs.
From: Rini van Zetten @ 2009-06-11 15:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: spi-devel-general, Andrew Morton, linuxppc-dev list
In-Reply-To: <7071E2AF-65ED-41C2-AFE7-06E9336619CB@kernel.crashing.org>
excuse me for my ignorance, but which -mm tree do you mean and where can I find it.
Regards,
Rini
Kumar Gala schreef:
>
> On Jun 11, 2009, at 4:10 AM, Rini van Zetten wrote:
>
>> This patch adds the possibility to have a spi device without a cs.
>>
>> For example, the dts file should look something like this:
>>
>> spi-controller {
>> gpios = <&pio1 1 0 /* cs0 */
>> 0 /* cs1, no GPIO */
>> &pio2 2 0>; /* cs2 */
>>
>>
>>
>> Signed-off-by: Rini van Zetten <rini@arvoo.nl>
>> ---
>> drivers/spi/spi_mpc83xx.c | 44
>> +++++++++++++++++++++++---------------------
>> 1 files changed, 23 insertions(+), 21 deletions(-)
>
> This patch needs to be respun against the -mm tree as a lot of other spi
> patches are queued up there that will cause this patch to not merge
> correctly.
>
> - k
--
Rini van Zetten
Senior Software Engineer
-------------------------
ARVOO Engineering B.V.
Tasveld 13
3417 XS Montfoort
The Netherlands
E-mail : <mailto:rini@arvoo.com> Rini van Zetten
Web : www.arvoo.com
^ permalink raw reply
* Re: [RFC v2] virtio: add virtio-over-PCI driver
From: Ira Snyder @ 2009-06-11 15:10 UTC (permalink / raw)
To: Grant Likely
Cc: Arnd Bergmann, Jan-Bernd Themann, netdev, Rusty Russell,
linux-kernel, linuxppc-dev
In-Reply-To: <fa686aa40906110722y1b4b8c22l7ccdd32d6684324d@mail.gmail.com>
On Thu, Jun 11, 2009 at 08:22:54AM -0600, Grant Likely wrote:
> On Tue, Apr 14, 2009 at 3:53 PM, Ira Snyder<iws@ovro.caltech.edu> wrote:
> > On Tue, Apr 14, 2009 at 02:28:26PM -0600, Grant Likely wrote:
> >> On Mon, Feb 23, 2009 at 6:00 PM, Ira Snyder <iws@ovro.caltech.edu> wrote:
> >> > This adds support to Linux for using virtio between two computers linked by
> >> > a PCI interface. This allows the use of virtio_net to create a familiar,
> >> > fast interface for communication. It should be possible to use other virtio
> >> > devices in the future, but this has not been tested.
> >>
> >> Hey Ira,
> >>
> >> I like this a lot. I need to do much the same thing on one of my
> >> platforms, so I'm going to use your patch as my starting point. Have
> >> you made many changes since you posted this version of your patch?
> >> I'd like to collaborate on the development and help to get it
> >> mainlined.
> >>
> >
> > This would be great. I'd really appreciate the help. I haven't had time
> > to make any changes since I last posted the patch. I started work on
> > converting all of the usage of struct vop_loc_* to just use the on-wire
> > structures, but I didn't get very far before other work got in the way.
> >
> >> In my case I've got an MPC5200 as the 'host' and a Xilinx Virtex
> >> (ppc440) as the 'client'. I intend set aside a region of the Xilinx
> >> Virtex's memory space for the shared queues. I'm starting work on it
> >> now, and I'll provide you with feedback and/or patches as I make
> >> progress.
> >>
> >
> > I'm looking forward to seeing your implementation. If you have any
> > questions, I'd be happy to attempt to answer them :)
>
> Hey Ira,
>
> I've been slowly hacking on your virtio-over-pci stuff. I've got an
> initial series of cleanup patches which address some of the comments
> from this thread. Before I send them to you, have you made any
> changes on your end? They likely won't apply without changes to the
> core code, so I'd like to sync up with you first.
>
I haven't made any changes to the code since you've last seen it. I've
been busy with other stuff for quite a while now. I can't wait to see
what you've done :)
At least for the use of the 83xx DMA controller, the DMA_SLAVE mode
patch I posted up about a week ago (to the ppcdev list) could make the
DMA setup much simpler. It hasn't been accepted to mainline yet.
Ira
^ permalink raw reply
* Re: "test" branch updates
From: Kumar Gala @ 2009-06-11 14:49 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev list
In-Reply-To: <1244730787.4599.94.camel@concordia>
On Jun 11, 2009, at 9:33 AM, Michael Ellerman wrote:
> On Mon, 2009-05-18 at 17:19 +1000, Benjamin Herrenschmidt wrote:
>> Just a quick note before I leave the office...
>>
>> I've just pushed out a bunch of stuff to my "test" branch. There's a
>> couple of known breakage (iseries and 8xx) which will have to be =20
>> sorted
>> out before that stuff goes into "next". hopefully in a couple of =20
>> days.
>>
>> Still... feel free to take a peek, test, etc...
>
> The swiotlb stuff doesn't build:
>
> arch/powerpc/kernel/dma-swiotlb.c
> In function =91swiotlb_bus_to_virt=92:
> 29: warning: passing argument 1 of =91swiotlb_bus_to_phys=92 makes =20=
> integer from pointer without a cast
> 29: error: too many arguments to function =91swiotlb_bus_to_phys=92
> At top level:
> 42: error: conflicting types for =91swiotlb_bus_to_phys=92
>
>
> There's changes in linux-next that make it work, which look like =20
> they're
> going via Ingo?
I think those changes are now in Linus's tree.
- k=
^ permalink raw reply
* Re: "test" branch updates
From: Michael Ellerman @ 2009-06-11 14:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1242631175.18075.54.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
On Mon, 2009-05-18 at 17:19 +1000, Benjamin Herrenschmidt wrote:
> Just a quick note before I leave the office...
>
> I've just pushed out a bunch of stuff to my "test" branch. There's a
> couple of known breakage (iseries and 8xx) which will have to be sorted
> out before that stuff goes into "next". hopefully in a couple of days.
>
> Still... feel free to take a peek, test, etc...
The swiotlb stuff doesn't build:
arch/powerpc/kernel/dma-swiotlb.c
In function ‘swiotlb_bus_to_virt’:
29: warning: passing argument 1 of ‘swiotlb_bus_to_phys’ makes integer from pointer without a cast
29: error: too many arguments to function ‘swiotlb_bus_to_phys’
At top level:
42: error: conflicting types for ‘swiotlb_bus_to_phys’
There's changes in linux-next that make it work, which look like they're
going via Ingo?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC v2] virtio: add virtio-over-PCI driver
From: Grant Likely @ 2009-06-11 14:22 UTC (permalink / raw)
To: Ira Snyder
Cc: Arnd Bergmann, Jan-Bernd Themann, netdev, Rusty Russell,
linux-kernel, linuxppc-dev
In-Reply-To: <20090414215342.GB9877@ovro.caltech.edu>
On Tue, Apr 14, 2009 at 3:53 PM, Ira Snyder<iws@ovro.caltech.edu> wrote:
> On Tue, Apr 14, 2009 at 02:28:26PM -0600, Grant Likely wrote:
>> On Mon, Feb 23, 2009 at 6:00 PM, Ira Snyder <iws@ovro.caltech.edu> wrote=
:
>> > This adds support to Linux for using virtio between two computers link=
ed by
>> > a PCI interface. This allows the use of virtio_net to create a familia=
r,
>> > fast interface for communication. It should be possible to use other v=
irtio
>> > devices in the future, but this has not been tested.
>>
>> Hey Ira,
>>
>> I like this a lot. =A0I need to do much the same thing on one of my
>> platforms, so I'm going to use your patch as my starting point. =A0Have
>> you made many changes since you posted this version of your patch?
>> I'd like to collaborate on the development and help to get it
>> mainlined.
>>
>
> This would be great. I'd really appreciate the help. I haven't had time
> to make any changes since I last posted the patch. I started work on
> converting all of the usage of struct vop_loc_* to just use the on-wire
> structures, but I didn't get very far before other work got in the way.
>
>> In my case I've got an MPC5200 as the 'host' and a Xilinx Virtex
>> (ppc440) as the 'client'. =A0I intend set aside a region of the Xilinx
>> Virtex's memory space for the shared queues. =A0I'm starting work on it
>> now, and I'll provide you with feedback and/or patches as I make
>> progress.
>>
>
> I'm looking forward to seeing your implementation. If you have any
> questions, I'd be happy to attempt to answer them :)
Hey Ira,
I've been slowly hacking on your virtio-over-pci stuff. I've got an
initial series of cleanup patches which address some of the comments
from this thread. Before I send them to you, have you made any
changes on your end? They likely won't apply without changes to the
core code, so I'd like to sync up with you first.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v3] 83xx: add support for the kmeter1 board.
From: Kumar Gala @ 2009-06-11 14:10 UTC (permalink / raw)
To: hs; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <4A30A14D.50907@denx.de>
On Jun 11, 2009, at 1:16 AM, Heiko Schocher wrote:
> The following series implements basic board support for
> the kmeter1 board from keymile, based on a MPC8360.
>
> This series provides the following functionality:
>
> - The board can boot with a serial console on UART1
> - Ethernet:
> UCC1 in RGMII mode
> UCC2 in RGMII mode
> UCC4 in RMII mode
> UCC5 in RMII mode
> UCC6 in RMII mode
> UCC7 in RMII mode
> UCC8 in RMII mode
>
> following patch is necessary for working UCC in RMII mode:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070909.html
>
> - Flash accessed via MTD layer
>
> On this hardware there is an Intel P30 flash, following patch
> series is necessary for working with this hardware:
>
> http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070716.html
the links are stale since the ozlabs.org rebuilt and moved the
maillist.. mind updating.
>
>
> - I2C using I2C Bus 1 from the MPC8360 cpu
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> ---
> changes since v1:
> - added comments from Kumar Gala and Scott Wood
> - get rid of using get_immrbase() in board specific code
>
> changes since v2:
> - added comments from Kumar Gala
> - rebased against 1406de8e11eb043681297adf86d6892ff8efc27a
> from git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
>
> $ ./scripts/checkpatch.pl 0001--83xx-add-support-for-the-kmeter1-
> board.patch
> total: 0 errors, 0 warnings, 1618 lines checked
>
> 0001--83xx-add-support-for-the-kmeter1-board.patch has no obvious
> style problems and is ready for submission.
> $
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: add nor flash partitions for mpc8569mds
From: Kumar Gala @ 2009-06-11 14:06 UTC (permalink / raw)
To: Kevin Hao; +Cc: linuxppc-dev, Haiying Wang
In-Reply-To: <1243389905.13410.6.camel@kevin>
On May 26, 2009, at 9:05 PM, Kevin Hao wrote:
> Add 4 partitions in nor flash. Also fix nor flash
> bank width bug.
>
> Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
> ---
> arch/powerpc/boot/dts/mpc8569mds.dts | 24 +++++++++++++++++++++++-
> 1 files changed, 23 insertions(+), 1 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
From: Kumar Gala @ 2009-06-11 13:32 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: Zhang Wei, netdev, linux-kernel, davem, linuxppc-dev, akpm
In-Reply-To: <3A45394FD742FA419B760BB8D398F9ED483CCD@zch01exm26.fsl.freescale.net>
On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote:
>> On May 12, 2009, at 3:35 AM, Li Yang wrote:
>>
>>> Add the mapping functions used to support direct IO memory access of
>>> rapidIO.
>>>
>>> Signed-off-by: Zhang Wei <zw@zh-kernel.org>
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>
>> Use inbnd/outbnd instead of inb/outb which make one think of
>> byte level io accessors.
>>
>> As I look at this I don't think this is the correct API. I
>> think we should be using the DMA mapping API to hide these
>> details. The concept of mapping like this seems to be more a
>> function of FSL's Address translation/mapping unit (ATMU) than
>> anything specific to the RIO bus standard.
>
> This is a separate RIO block level ATMU. Although it looks like the
> system level ATMU, system ATMU doesn't have the knowledge of rapidIO
> target device ID. The mapping need to be dynamic, as it's easy to
> have
> more RIO devices than the outbound windows.
I understand that. What I'm saying is the RIO block level ATMU is a
Freescale specific detail and not part of any standard RIO bus
programming model. We have mapping APIs that we can connect to for
this via the DMA API layer.
- k
^ permalink raw reply
* Re: [PATCH][POWERPC] mpc83xx : allow SPI without cs.
From: Kumar Gala @ 2009-06-11 13:29 UTC (permalink / raw)
To: Rini van Zetten; +Cc: spi-devel-general, Andrew Morton, linuxppc-dev list
In-Reply-To: <4A30CA1F.4000702@arvoo.nl>
On Jun 11, 2009, at 4:10 AM, Rini van Zetten wrote:
> This patch adds the possibility to have a spi device without a cs.
>
> For example, the dts file should look something like this:
>
> spi-controller {
> gpios = <&pio1 1 0 /* cs0 */
> 0 /* cs1, no GPIO */
> &pio2 2 0>; /* cs2 */
>
>
>
> Signed-off-by: Rini van Zetten <rini@arvoo.nl>
> ---
> drivers/spi/spi_mpc83xx.c | 44 ++++++++++++++++++++++
> +---------------------
> 1 files changed, 23 insertions(+), 21 deletions(-)
This patch needs to be respun against the -mm tree as a lot of other
spi patches are queued up there that will cause this patch to not
merge correctly.
- k
^ permalink raw reply
* [PATCH] powerpc/iseries: Mark signal_vsp_instruction() as maybe unused
From: Michael Ellerman @ 2009-06-11 12:18 UTC (permalink / raw)
To: linuxppc-dev
signal_vsp_instruction() is currently only used if CONFIG_PROC_FS
is enabled. However logically it has nothing to do with PROC_FS,
so rather than making it depend on that mark it as maybe unused.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/iseries/mf.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/mf.c b/arch/powerpc/platforms/iseries/mf.c
index 3689c24..fef4d51 100644
--- a/arch/powerpc/platforms/iseries/mf.c
+++ b/arch/powerpc/platforms/iseries/mf.c
@@ -267,7 +267,8 @@ static struct pending_event *new_pending_event(void)
return ev;
}
-static int signal_vsp_instruction(struct vsp_cmd_data *vsp_cmd)
+static int __maybe_unused
+signal_vsp_instruction(struct vsp_cmd_data *vsp_cmd)
{
struct pending_event *ev = new_pending_event();
int rc;
--
1.6.2.1
^ permalink raw reply related
* [PATCH] powerpc/iseries: Fix unused function warning in iSeries DT code
From: Michael Ellerman @ 2009-06-11 12:18 UTC (permalink / raw)
To: linuxppc-dev
If CONFIG_BLK_DEV_INITRD is unset dt_prop_u64() is unused, which
causes a warning. We don't really want to tie the definition to
BLK_DEV_INITRD, so mark it as maybe unused.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/iseries/dt.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/dt.c b/arch/powerpc/platforms/iseries/dt.c
index 4543c4b..c5a87a7 100644
--- a/arch/powerpc/platforms/iseries/dt.c
+++ b/arch/powerpc/platforms/iseries/dt.c
@@ -204,7 +204,8 @@ static void __init dt_prop_u32(struct iseries_flat_dt *dt, const char *name,
dt_prop(dt, name, &data, sizeof(u32));
}
-static void __init dt_prop_u64(struct iseries_flat_dt *dt, const char *name,
+static void __init __maybe_unused dt_prop_u64(struct iseries_flat_dt *dt,
+ const char *name,
u64 data)
{
dt_prop(dt, name, &data, sizeof(u64));
--
1.6.2.1
^ permalink raw reply related
* [PATCH] powerpc: Only build prom_init.o when CONFIG_PPC_OF_BOOT_TRAMPOLINE=y
From: Michael Ellerman @ 2009-06-11 12:12 UTC (permalink / raw)
To: linuxppc-dev
Commit 28794d34 ("powerpc/kconfig: Kill PPC_MULTIPLATFORM"), added
CONFIG_PPC_OF_BOOT_TRAMPOLINE to control the buliding of prom_init.o
However the Makefile still unconditionally builds prom_init_check,
the script that checks prom_init.o for symbol usage, and so in turn
prom_init.o is still always being built. (it's not linked though)
So surround all the prom_init_check logic with an ifeq block testing
if CONFIG_PPC_OF_BOOT_TRAMPOLINE is set.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 110ec6d..655b724 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -124,6 +124,7 @@ PHONY += systbl_chk
systbl_chk: $(src)/systbl_chk.sh $(obj)/systbl_chk.i
$(call cmd,systbl_chk)
+ifeq ($(CONFIG_PPC_OF_BOOT_TRAMPOLINE),y)
$(obj)/built-in.o: prom_init_check
quiet_cmd_prom_init_check = CALL $<
@@ -132,5 +133,6 @@ quiet_cmd_prom_init_check = CALL $<
PHONY += prom_init_check
prom_init_check: $(src)/prom_init_check.sh $(obj)/prom_init.o
$(call cmd,prom_init_check)
+endif
clean-files := vmlinux.lds
--
1.6.2.1
^ permalink raw reply related
* Re: [PATCH v2] Fix RTAS watchdog driver temperature read functionality
From: Adrian Reber @ 2009-06-11 10:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Utz Bacher
In-Reply-To: <20090326120542.GD24889@lisas.de>
I forgot about this patch. Can this still be merged?
On Thu, Mar 26, 2009 at 01:05:42PM +0100, Adrian Reber wrote:
> Using the RTAS watchdog driver to read out the temperature crashes
> on a PXCAB:
>
> Unable to handle kernel paging request for data at address 0xfe347b50
> Faulting instruction address: 0xc00000000001af64
> Oops: Kernel access of bad area, sig: 11 [#1]
>
> The wrong usage of "(void *)__pa(&temperature)" in rtas_call() is
> removed by using the function rtas_get_sensor() which does the
> right thing.
>
> Signed-off-by: Adrian Reber <adrian@lisas.de>
> ---
> v2: use rtas_get_sensor(); typo fixed
> ---
> drivers/watchdog/wdrtas.c | 8 +++-----
> 1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/watchdog/wdrtas.c b/drivers/watchdog/wdrtas.c
> index 5d3b1a8..a9f00dc 100644
> --- a/drivers/watchdog/wdrtas.c
> +++ b/drivers/watchdog/wdrtas.c
> @@ -214,16 +214,14 @@ static void wdrtas_timer_keepalive(void)
> */
> static int wdrtas_get_temperature(void)
> {
> - long result;
> + int result;
> int temperature = 0;
>
> - result = rtas_call(wdrtas_token_get_sensor_state, 2, 2,
> - (void *)__pa(&temperature),
> - WDRTAS_THERMAL_SENSOR, 0);
> + result = rtas_get_sensor(WDRTAS_THERMAL_SENSOR, 0, &temperature);
>
> if (result < 0)
> printk(KERN_WARNING "wdrtas: reading the thermal sensor "
> - "faild: %li\n", result);
> + "failed: %i\n", result);
> else
> temperature = ((temperature * 9) / 5) + 32; /* fahrenheit */
>
> --
> 1.5.6.6
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: add nor flash partitions for mpc8569mds
From: Kevin Hao @ 2009-06-11 10:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Haiying Wang
In-Reply-To: <76C9B3EA-967A-4B4F-BC3A-A24942F31294@kernel.crashing.org>
On Wed, 2009-06-10 at 21:20 -0500, Kumar Gala wrote:
> On May 26, 2009, at 9:05 PM, Kevin Hao wrote:
>
> > Add 4 partitions in nor flash. Also fix nor flash
> > bank width bug.
>
> Can you explain this.. I'm trying to understand why you set the bank-
> width to 1
The NOR flash (S29GL256N) works in 8-bit mode. And it's also not
interleaved. So the bank-width should be equal to device-width. If we
set bank-width to 2 the flash can not work correctly.
Thanks,
Kevin
>
> - k
>
> >
> >
> > Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
> > ---
> > arch/powerpc/boot/dts/mpc8569mds.dts | 24 +++++++++++++++++++++++-
> > 1 files changed, 23 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts b/arch/powerpc/
> > boot/dts/mpc8569mds.dts
> > index 39c2927..1f98990 100644
> > --- a/arch/powerpc/boot/dts/mpc8569mds.dts
> > +++ b/arch/powerpc/boot/dts/mpc8569mds.dts
> > @@ -70,8 +70,30 @@
> > #size-cells = <1>;
> > compatible = "cfi-flash";
> > reg = <0x0 0x0 0x02000000>;
> > - bank-width = <2>;
> > + bank-width = <1>;
> > device-width = <1>;
> > + partition@0 {
> > + label = "ramdisk";
> > + reg = <0x00000000 0x01c00000>;
> > + };
> > + partition@1c00000 {
> > + label = "kernel";
> > + reg = <0x01c00000 0x002e0000>;
> > + };
> > + partiton@1ee0000 {
> > + label = "dtb";
> > + reg = <0x01ee0000 0x00020000>;
> > + };
> > + partition@1f00000 {
> > + label = "firmware";
> > + reg = <0x01f00000 0x00080000>;
> > + read-only;
> > + };
> > + partition@1f80000 {
> > + label = "u-boot";
> > + reg = <0x01f80000 0x00080000>;
> > + read-only;
> > + };
> > };
> >
> > bcsr@1,0 {
> > --
> > 1.6.0.4.771.gef3b3
>
^ 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