* Add "mpc5200-simple-platform" to the list of supported boards
From: Marcelo Dalmas @ 2009-06-05 21:01 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 344 bytes --]
Hello,
Adding "mpc5200-simple-platform" to the list of supported boards allow to use the option "Generic support for simple MPC5200 based boards" without patching the kernel. Just set model to "mpc5200-simple-plataform" on your dts file.
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: add_mpc5200_simple_platform_to_supported_boards.patch --]
[-- Type: text/x-diff; name="add_mpc5200_simple_platform_to_supported_boards.patch", Size: 476 bytes --]
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c
index c31e5b5..a2df795 100644
--- a/arch/powerpc/platforms/52xx/mpc5200_simple.c
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
@@ -50,6 +50,7 @@ static void __init mpc5200_simple_setup_arch(void)
/* list of the supported boards */
static char *board[] __initdata = {
+ "mpc5200-simple-platform",
"intercontrol,digsy-mtc",
"phytec,pcm030",
"phytec,pcm032",
^ permalink raw reply related
* RE: SD card over (xilinx_)SPI, timeout error while CID
From: John Linn @ 2009-06-05 21:15 UTC (permalink / raw)
To: Joachim Foerster, linuxppc-dev, dbrownell; +Cc: lorenz, joachim
In-Reply-To: <1244216069.21470.12.camel@localhost>
> -----Original Message-----
> From: Joachim Foerster [mailto:JOFT@gmx.de]
> Sent: Friday, June 05, 2009 9:34 AM
> To: linuxppc-dev@ozlabs.org; John Linn;
dbrownell@users.sourceforge.net
> Cc: lorenz@missinglinkelectronics.com;
joachim@missinglinkelectronics.com
> Subject: SD card over (xilinx_)SPI, timeout error while CID
> =
> Hi,
> =
> we have a very strange problem with SD-card-over-SPI support using
> 2.6.29.4 on our custom PowerPC 405 (Virtex-4 FX FPGA) based board. To
> summarize the problem in one sentence: mmc_spi gets a timeout (error
> -110) after sending MMC command "CMD10" (CID, card identification?).
> =
> The attached log file shows device registration messages during bootup
> and debug/error messages after inserting a SD card.
> =
> ATM we are migrating from 2.6.26 (old arch/ppc-based, non-device-tree)
> to the already mentioned version 2.6.29.4 (arch/powerpc, device tree).
> We use Xilinx' opb_spi core (v1.00.e, EDK 9.1.02i) inside the FPGA,
> which is connected to a SD card slot. With our old 2.6.26 kernel, SD
> cards _are working fine_!.
> =
> To solve the problem, among other things, we tried 2.6.26+arch/powerpc
> (applying only necessary patches to support/include SPI, MMC OF
> bindings) - but the result is the same (error -110). The same is also
> true for
> 2.6.28+arch/powerpc and Linus-HEAD+arch/powerpc . Then we checked
these
> patches, which add OF bindings for
> SPI/MMC/..., line by line and did not find any hint.
> For debugging we added a lot of printks ;-) and noticed that then
there
> are less timeouts (error -110), but CRC check errors (-EILSEQ,
> mmc_spi.c, mmc_spi_readblock) happen - maybe even signal
shifts/sampling
> errors?
> =
> To complete confusion :-( the same setup (xilinx_spi+opb_spi) using an
> ADS7846 touchscreen controller as SPI slave _does work_ correctly
> =
> Our current guess is, that it could be a more "basic" (?) error in
> arch/powerpc . But we have no lead ATM.
> =
> Any hints? Does anybody use SD card support with mmc_spi+xilinx_spi ?
> =
There were definitely some changes to the spi driver as I had to make it
use the device tree.
I have not tested with SD as I don't have a board with SD memory. I have
only tested
with a serial eeprom.
Sorry not much help. If I had to guess I would also think it might be
device tree related.
-- John
> Joachim
> =
> --
> for reference: relevant DTS entry:
> =
> opb_spi_0: spi@41240000 {
> #address-cells =3D <1>;
> #size-cells =3D <0>;
> =
> compatible =3D "xlnx,opb-spi-1.00.e";
> reg =3D <0x41240000 0x10000>;
> interrupt-parent =3D <&opb_intc_0>;
> interrupts =3D <7 2>;
> =
> xlnx,depth =3D <0x10>;
> xlnx,dev-blk-id =3D <0x4>;
> xlnx,dev-mir-enable =3D <0x0>;
> xlnx,family =3D "virtex4";
> xlnx,fifo-exist =3D <0x1>;
> xlnx,interrupt-present =3D <0x1>;
> xlnx,ip-reg-bar-offset =3D <0x60>;
> xlnx,num-bits-reg =3D <0x8>;
> xlnx,num-bits-sr =3D <0x8>;
> xlnx,num-offchip-ss-bits =3D <0x0>;
> xlnx,num-ss-bits =3D <0x1>;
> xlnx,occupancy-num-bits =3D <0x4>;
> xlnx,spi-slave-only =3D <0x0>;
> =
> mmc-slot@0 {
> compatible =3D "mmc-spi-slot";
> reg =3D <0>;
> gpios =3D <&opb_gpio_1 0 1>;
> voltage-ranges =3D <3300 3300>;
> spi-max-frequency =3D <6250000>;
> };
> };
> =
> dmesg during boot sequence, messages concerning SPI and MMC/SD only:
> =
> [ 30.677087] xilinx-xps-spi 41240000.spi: at 0x41240000 mapped to
> 0xC9040000, irq=3D18
> [ 30.875967] mmc_spi spi32766.0: SD/MMC host mmc0, no WP, no
poweroff,
> cd polling
> =
> dmesg after inserting a SD card:
> =
> [ 105.375146] mmc0: clock 0Hz busmode 2 powermode 1 cs 1 Vdd 21 width
0
> timing 0
> [ 105.381246] mmc_spi spi32766.0: mmc_spi: power up (21)
> [ 105.388286] mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21
> width 0 timing 0
> [ 105.394839] mmc_spi spi32766.0: mmc_spi: power on (21)
> [ 105.400197] mmc_spi spi32766.0: xilinx_spi_setup, unsupported mode
> bits 4
> [ 105.406601] mmc_spi spi32766.0: can't change chip-select polarity
> [ 105.414666] mmc0: starting CMD0 arg 00000000 flags 000000c0
> [ 105.419176] mmc_spi spi32766.0: mmc_spi: CMD0, resp R1
> [ 105.424511] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
> nsec/bit
> [ 105.431557] mmc0: req done (CMD0): 0: 00000001 00000000 00000000
> 00000000
> [ 105.439251] mmc0: starting CMD8 arg 000001aa flags 000002f5
> [ 105.443770] mmc_spi spi32766.0: mmc_spi: CMD8, resp R3/R4/R7
> [ 105.449740] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
> nsec/bit
> [ 105.456789] mmc0: req done (CMD8): 0: 00000001 000001aa 00000000
> 00000000
> [ 105.463502] mmc0: starting CMD5 arg 00000000 flags 000002e1
> [ 105.468999] mmc_spi spi32766.0: mmc_spi: CMD5, resp R3/R4/R7
> [ 105.474968] mmc_spi spi32766.0: ... CMD5 response SPI_R3/R4/R:
resp
> 0005 ffffffff
> [ 105.482448] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
> nsec/bit
> [ 105.489606] mmc0: req done (CMD5): -22: 00000005 ffffffff 00000000
> 00000000
> [ 105.496511] mmc0: starting CMD55 arg 00000000 flags 000000f5
> [ 105.502092] mmc_spi spi32766.0: mmc_spi: CMD55, resp R1
> [ 105.507645] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
> nsec/bit
> [ 105.514650] mmc0: req done (CMD55): 0: 00000001 00000000 00000000
> 00000000
> [ 105.521476] mmc0: starting CMD41 arg 00000000 flags 000000e1
> [ 105.527055] mmc_spi spi32766.0: mmc_spi: CMD41, resp R1
> [ 105.532615] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
> nsec/bit
> [ 105.539646] mmc0: req done (CMD41): 0: 00000001 00000000 00000000
> 00000000
> [ 105.546424] mmc0: starting CMD0 arg 00000000 flags 000000c0
> [ 105.551986] mmc_spi spi32766.0: mmc_spi: CMD0, resp R1
> [ 105.557387] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
> nsec/bit
> [ 105.564440] mmc0: req done (CMD0): 0: 00000001 00000000 00000000
> 00000000
> [ 105.572158] mmc0: starting CMD58 arg 00000000 flags 00000280
> [ 105.576741] mmc_spi spi32766.0: mmc_spi: CMD58, resp R3/R4/R7
> [ 105.582795] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
> nsec/bit
> [ 105.589846] mmc0: req done (CMD58): 0: 00000001 00ff8000 00000000
> 00000000
> [ 105.596650] mmc0: clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 20
> width 0 timing 0
> [ 105.604258] mmc0: starting CMD0 arg 00000000 flags 000000c0
> [ 105.609744] mmc_spi spi32766.0: mmc_spi: CMD0, resp R1
> [ 105.615214] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
> nsec/bit
> [ 105.622217] mmc0: req done (CMD0): 0: 00000001 00000000 00000000
> 00000000
> [ 105.629975] mmc0: starting CMD8 arg 000001aa flags 000002f5
> [ 105.634459] mmc_spi spi32766.0: mmc_spi: CMD8, resp R3/R4/R7
> [ 105.640457] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
> nsec/bit
> [ 105.647472] mmc0: req done (CMD8): 0: 00000001 000001aa 00000000
> 00000000
> [ 105.654162] mmc0: starting CMD55 arg 00000000 flags 000000f5
> [ 105.659796] mmc_spi spi32766.0: mmc_spi: CMD55, resp R1
> [ 105.665301] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
> nsec/bit
> [ 105.672372] mmc0: req done (CMD55): 0: 00000001 00000000 00000000
> 00000000
> [ 105.679157] mmc0: starting CMD41 arg 40000000 flags 000000e1
> [ 105.684737] mmc_spi spi32766.0: mmc_spi: CMD41, resp R1
> [ 105.690267] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
> nsec/bit
> [ 105.697327] mmc0: req done (CMD41): 0: 00000001 00000000 00000000
> 00000000
> ...
> CMD55 + CMD41 repeated 3 times, same messages as above.
> ...
> [ 105.895962] mmc0: starting CMD59 arg 00000001 flags 00000080
> [ 105.901545] mmc_spi spi32766.0: mmc_spi: CMD59, resp R1
> [ 105.907129] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
> nsec/bit
> [ 105.914091] mmc0: req done (CMD59): 0: 00000000 00000000 00000000
> 00000000
> [ 105.920964] mmc0: starting CMD10 arg 00000000 flags 000000b5
> [ 105.926517] mmc0: blksz 16 blocks 1 flags 00000200 tsac 0 ms
nsac
> 64
> [ 105.933195] mmc_spi spi32766.0: mmc_spi: CMD10, resp R1
> [ 105.938693] mmc_spi spi32766.0: mmc_spi: read block, 16 bytes
> [ 105.944823] mmc_spi spi32766.0: read error ffffff92 (-110)
> [ 105.950015] mmc_spi spi32766.0: read status -110
> [ 105.954579] mmc_spi spi32766.0: xilinx_spi_setup, mode 0, 8 bits/w,
0
> nsec/bit
> [ 105.961806] mmc0: req done (CMD10): 0: 00000000 00000000 00000000
> 00000000
> [ 105.968609] mmc0: 0 bytes transferred: -110
> [ 105.973082] mmc0: clock 0Hz busmode 2 powermode 0 cs 1 Vdd 0 width
0
> timing 0
> [ 105.980189] mmc_spi spi32766.0: mmc_spi: power off (0)
> [ 105.985254] mmc0: error -110 whilst initialising SD card
> =
> =
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Add "mpc5200-simple-platform" to the list of supported boards
From: Marcelo Dalmas @ 2009-06-05 23:20 UTC (permalink / raw)
To: linuxppc-dev
Hello,=0A=0AAdding "mpc5200-simple-platform" to the list of supported boar=
ds allow to use the option "Generic support for simple MPC5200 based boards=
" without patching the kernel. Just set model to "mpc5200-simple-plataform"=
on your dts file.=0A=0A=0Adiff --git a/arch/powerpc/platforms/52xx/mpc5200=
_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c=0Aindex c31e5b5..a=
2df795 100644=0A--- a/arch/powerpc/platforms/52xx/mpc5200_simple.c=0A+++ b/=
arch/powerpc/platforms/52xx/mpc5200_simple.c=0A@@ -50,6 +50,7 @@ static voi=
d __init mpc5200_simple_setup_arch(void)=0A =0A /* list of the supported bo=
ards */=0A static char *board[] __initdata =3D {=0A+=09"mpc5200-simple-plat=
form",=0A =09"intercontrol,digsy-mtc",=0A =09"phytec,pcm030",=0A =09"phytec=
,pcm032",=0A=0A=0A=0A=0A Veja quais s=E3o os assuntos do momento no Ya=
hoo! +Buscados=0Ahttp://br.maisbuscados.yahoo.com
^ permalink raw reply
* Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
From: Benjamin Herrenschmidt @ 2009-06-05 23:31 UTC (permalink / raw)
To: Greg KH
Cc: Sachin P Sant, Stephen Rothwell, Linux-Kernel, Linuxppc-dev,
Linux-Next, Paul Mackerras, Geert Uytterhoeven,
Geert Uytterhoeven, Subrata Modak
In-Reply-To: <20090605182618.GA11853@kroah.com>
On Fri, 2009-06-05 at 11:26 -0700, Greg KH wrote:
> Should the comedi layer just not be using PAGE_KERNEL_NOCACHE here? I
> can't believe that we need to do something like this in a driver. What
> should the proper fix for this be?
Actualy, I think powerpc -had- PAGE_KERNEL_NOCACHE and I removed it ...
Oh well... My understanding was that the exposed interface isn't that
but instead pgprot_noncached().
Nowadays we provide these on ppc:
#define pgprot_noncached(prot) (__pgprot((pgprot_val(prot) & ~_PAGE_CACHE_CTL) | \
_PAGE_NO_CACHE | _PAGE_GUARDED))
#define pgprot_noncached_wc(prot) (__pgprot((pgprot_val(prot) & ~_PAGE_CACHE_CTL) | \
_PAGE_NO_CACHE))
#define pgprot_cached(prot) (__pgprot((pgprot_val(prot) & ~_PAGE_CACHE_CTL) | \
_PAGE_COHERENT))
#define pgprot_cached_wthru(prot) (__pgprot((pgprot_val(prot) & ~_PAGE_CACHE_CTL) | \
_PAGE_COHERENT | _PAGE_WRITETHRU))
Now, of course, expect interesting problems if you use it in vmap, since
you are mapping struct pages, you are effectively mapping memory.
On some platforms, it's absolutely illegal to map memory non-cacheable while
this memory is mapped cacheable elsewhere and can be fatal. But the pages you
are mapping here, I suppose, are also part of the linear mapping which is ...
cacheable.
Why would you need that non-cacheable mapping in the first place ? If it's
for DMA, it's the wrong interface I believe....
Cheers,
Ben.
^ permalink raw reply
* Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
From: Benjamin Herrenschmidt @ 2009-06-05 23:32 UTC (permalink / raw)
To: Subrata Modak
Cc: Sachin P Sant, Stephen Rothwell, Greg KH, Linux-Kernel,
Linuxppc-dev, Linux-Next, Paul Mackerras, Geert Uytterhoeven,
Geert Uytterhoeven
In-Reply-To: <20090605182625.24093.7808.sendpatchset@elm3a191.beaverton.ibm.com>
> I tried this. But, with some catch. ‘PAGE_KERNEL_NOCACHE’ seems to be the
> choice for majority of architectures like frv, m32r, sh, x86, etc, as Geert
> mentions below. However, i believe POWERPC defines it as ‘PAGE_KERNEL_NC‘
> found at arch/powerpc/include/asm/pte-common.h.
>
> Paul/Banjamin,
> Can you please confirm this ?
Read my reply to Greg. Why the heck are you trying to map memory
non-cacheable in the first place ?
Cheers
Ben.
> The below patch fixes the build error.
>
> Signed-off-by: Subrata Modak <subrata@linux.vnet.ibm.com>
> ---
>
> --- linux-2.6.30-rc8/drivers/staging/comedi/drivers.c.orig 2009-06-05 12:46:35.000000000 -0500
> +++ linux-2.6.30-rc8/drivers/staging/comedi/drivers.c 2009-06-05 13:03:31.000000000 -0500
> @@ -43,9 +43,13 @@
> #include <linux/vmalloc.h>
> #include <linux/cdev.h>
> #include <linux/dma-mapping.h>
> -
> #include <asm/io.h>
> #include <asm/system.h>
> +#ifdef __powerpc64__
> +#include <asm/pte-common.h>
> +#else
> +#include <asm/pgtable.h>
> +#endif
>
> static int postconfig(struct comedi_device *dev);
> static int insn_rw_emulate_bits(struct comedi_device *dev, struct comedi_subdevice *s,
> @@ -492,8 +496,13 @@ int comedi_buf_alloc(struct comedi_devic
> }
> if (i == n_pages) {
> async->prealloc_buf =
> +#ifdef __powerpc64__
> + vmap(pages, n_pages, VM_MAP,
> + PAGE_KERNEL_NC);
> +#else
> vmap(pages, n_pages, VM_MAP,
> PAGE_KERNEL_NOCACHE);
> +#endif
> }
> if (pages) {
> vfree(pages);
>
> ---
> Regards--
> Subrata
>
> > PAGE_KERNEL_NOCACHE is defined on a few architectures only, namely
> > frv, m32r, mn10300, sh, and x86[*]. On all others, it will fail.
> >
> > [*] Interestingly, sparc refers to it in one of its include files,
> > without providing a
> > definition, Probably that code is unused.
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> >
^ permalink raw reply
* Re: Add "mpc5200-simple-platform" to the list of supported boards
From: Grant Likely @ 2009-06-05 23:52 UTC (permalink / raw)
To: Marcelo Dalmas; +Cc: linuxppc-dev
In-Reply-To: <461095.11075.qm@web111310.mail.gq1.yahoo.com>
On Fri, Jun 5, 2009 at 5:20 PM, Marcelo Dalmas<m_dalmas@yahoo.com.br> wrote=
:
>
> Hello,
>
> Adding =A0"mpc5200-simple-platform" to the list of supported boards allow=
to use the option "Generic support for simple MPC5200 based boards" withou=
t patching the kernel. Just set model to "mpc5200-simple-plataform" on your=
dts file.
>
>
> diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/=
platforms/52xx/mpc5200_simple.c
> index c31e5b5..a2df795 100644
> --- a/arch/powerpc/platforms/52xx/mpc5200_simple.c
> +++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
> @@ -50,6 +50,7 @@ static void __init mpc5200_simple_setup_arch(void)
>
> =A0/* list of the supported boards */
> =A0static char *board[] __initdata =3D {
> + =A0 =A0 =A0 "mpc5200-simple-platform",
> =A0 =A0 =A0 =A0"intercontrol,digsy-mtc",
> =A0 =A0 =A0 =A0"phytec,pcm030",
> =A0 =A0 =A0 =A0"phytec,pcm032",
Sorry, nack. For the time being, board support is listed explicitly
in mpc5200_simple.c and 'generic' compatible values are strongly
discouraged. This is on purpose.
I have been thinking about coming up with a method for generic mpc5200
platform support code to bind against an otherwise unknown mpc5200
board, but there are subtleties here and considerable pain if it is
done wrong.
In the mean time, just patch your kernel with your board name(s) and
don't try to use a generic value like mpc5200-simple-platform.
BTW, please cc: the appropriate maintainers and developers when
posting patches to the Linux kernel. The MAINTAINERS file and
'scripts/get_maintainer.pl -f <filename>' are useful tools here.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Add "mpc5200-simple-platform" to the list of supported boards
From: Benjamin Herrenschmidt @ 2009-06-06 0:28 UTC (permalink / raw)
To: Marcelo Dalmas; +Cc: linuxppc-dev
In-Reply-To: <461095.11075.qm@web111310.mail.gq1.yahoo.com>
On Fri, 2009-06-05 at 16:20 -0700, Marcelo Dalmas wrote:
> Hello,
>
> Adding "mpc5200-simple-platform" to the list of supported boards allow to use the option "Generic support for simple MPC5200 based boards" without patching the kernel. Just set model to "mpc5200-simple-plataform" on your dts file.
I'm generally against that. Some time you'll need to diverge and poof !
you lost the ability to identify your board... it's also a very linux
centric thing to put in the device-tree.
Cheers,
Ben.
> diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c b/arch/powerpc/platforms/52xx/mpc5200_simple.c
> index c31e5b5..a2df795 100644
> --- a/arch/powerpc/platforms/52xx/mpc5200_simple.c
> +++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
> @@ -50,6 +50,7 @@ static void __init mpc5200_simple_setup_arch(void)
>
> /* list of the supported boards */
> static char *board[] __initdata = {
> + "mpc5200-simple-platform",
> "intercontrol,digsy-mtc",
> "phytec,pcm030",
> "phytec,pcm032",
>
>
>
>
> Veja quais são os assuntos do momento no Yahoo! +Buscados
> http://br.maisbuscados.yahoo.com
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
From: David Miller @ 2009-06-06 0:56 UTC (permalink / raw)
To: benh
Cc: sachinp, sfr, greg, linux-kernel, Linuxppc-dev, linux-next,
paulus, Geert.Uytterhoeven, geert, subrata
In-Reply-To: <1244244749.31984.16.camel@pasglop>
RnJvbTogQmVuamFtaW4gSGVycmVuc2NobWlkdCA8YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnPg0K
RGF0ZTogU2F0LCAwNiBKdW4gMjAwOSAwOTozMjoyOSArMTAwMA0KDQo+IA0KPj4gSSB0cmllZCB0
aGlzLiBCdXQsIHdpdGggc29tZSBjYXRjaC4g4oCYUEFHRV9LRVJORUxfTk9DQUNIReKAmSBzZWVt
cyB0byBiZSB0aGUNCj4+IGNob2ljZSBmb3IgbWFqb3JpdHkgb2YgYXJjaGl0ZWN0dXJlcyBsaWtl
IGZydiwgbTMyciwgc2gsIHg4NiwgZXRjLCBhcyBHZWVydA0KPj4gbWVudGlvbnMgYmVsb3cuIEhv
d2V2ZXIsIGkgYmVsaWV2ZSBQT1dFUlBDIGRlZmluZXMgaXQgYXMg4oCYUEFHRV9LRVJORUxfTkPi
gJgNCj4+IGZvdW5kIGF0IGFyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9wdGUtY29tbW9uLmguDQo+
PiANCj4+IFBhdWwvQmFuamFtaW4sDQo+PiBDYW4geW91IHBsZWFzZSBjb25maXJtIHRoaXMgPw0K
PiANCj4gUmVhZCBteSByZXBseSB0byBHcmVnLiBXaHkgdGhlIGhlY2sgYXJlIHlvdSB0cnlpbmcg
dG8gbWFwIG1lbW9yeQ0KPiBub24tY2FjaGVhYmxlIGluIHRoZSBmaXJzdCBwbGFjZSA/DQoNCkkg
YWdyZWUsIHRoaXMgaXMgZXh0cmVtZWx5IGZpc2h5Lg0KDQpJIGd1ZXNzIHRoZSBpc3N1ZSBpcyB0
aGF0IHRoZSBkcml2ZXIgd2FudHMgY29uc2lzdGVudCBETUEgbWVtb3J5DQpidXQgd2FudHMgdG8g
YWxsb2NhdGUgYSBodWdlIGFyZWEgdm1hcCgpIHN0eWxlLg0K
^ permalink raw reply
* Re: [PATCH] Add MSI interrupts to DTS of MPC8315E-RDB
From: David Gibson @ 2009-06-06 0:44 UTC (permalink / raw)
To: leon.woestenberg; +Cc: linuxppc-dev, Leon Woestenberg, linux-kernel
In-Reply-To: <4a292f95.05a4100a.1a14.0a04@mx.google.com>
On Fri, Jun 05, 2009 at 07:45:41AM -0700, leon.woestenberg@gmail.com wrote:
> The PCIe MSI interrupts are missing from the device tree source, and
> thus were not enabled. This patch adds them.
>
> Tested to work on MPC8315E-RDB with custom FPGA PCIe device.
>
> Signed-off-by: Leon Woestenberg <leon@sidebranch.com>
> Tested-by: Leon Woestenberg <leon@sidebranch.com>
>
> diff --git a/arch/powerpc/boot/dts/mpc8315erdb.dts b/arch/powerpc/boot/dts/mpc8315erdb.dts
> index 3f4c5fb..4f04667 100644
> --- a/arch/powerpc/boot/dts/mpc8315erdb.dts
> +++ b/arch/powerpc/boot/dts/mpc8315erdb.dts
> @@ -322,6 +322,21 @@
> reg = <0x700 0x100>;
> device_type = "ipic";
> };
> +
> + ipic-msi@7c0 {
> + compatible = "fsl,ipic-msi";
> + reg = <0x7c0 0x40>;
> + msi-available-ranges = <0 0x100>;
This patch appears not to use consistent whitespace formatting.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx: Add support for the Thecus N1200 NAS device
From: David Gibson @ 2009-06-06 3:11 UTC (permalink / raw)
To: Byron Bradley; +Cc: linuxppc-dev, tim.ellis
In-Reply-To: <alpine.DEB.2.00.0906051851120.22609@gamma>
On Fri, Jun 05, 2009 at 07:44:31PM +0100, Byron Bradley wrote:
> On Fri, 5 Jun 2009, David Gibson wrote:
>
> > On Thu, Jun 04, 2009 at 09:59:04PM +0100, Byron Bradley wrote:
> > > The Thecus N1200 is a NAS device with a single internal SATA disk and
> > > an eSATA port based on an MPC8347 SoC.
> >
> > Comments on a number of fairly minor device tree nits below:
>
> Hi David, Peter. Thanks for the comments, replies inline below.
>
> >
> > [snip]
> > > + soc8349@e0000000 {
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + device_type = "soc";
> > > + compatible = "simple-bus";
> >
> > The compatible value should have something more specific
> > (e.g. "fsl,mpc8340-soc") before listing "simple-bus".
>
> Added "fsl,mpc8347-soc" and changed soc8349 to soc8347.
Ok. Strictly speaking, I think new conventions say it should be just
"soc@" but I think that might confuse u-boot.
> > > + ranges = <0x0 0xe0000000 0x00100000
> > > + 0xfe000000 0xfe000000 0x0800000>;
> > > + reg = <0xe0000000 0x00000200>;
> > > + bus-frequency = <0>; // from bootloader
> > > +
> > > + physmap-flash@fe000000 {
> >
> > Calling this just "flash" would be more normal.
>
> Done.
>
> > > + #address-cells = <1>;
> > > + #size-cells = <1>;
> > > + compatible = "cfi-flash";
> >
> > Ideally this should list the actual model of flash chip, before the
> > generic "cfi-flash".
>
> Added "numonyx,28f640j3d"
Ok.
[snip]
> > > + wdt@200 {
> > > + device_type = "watchdog";
> >
> > No device_type here.
>
> Removed all device_type entries that you said shouldn't be there.
Excellent.
[snip]
> > > + ipic: pic@700 {
> > > + interrupt-controller;
> > > + #address-cells = <0>;
> > > + #interrupt-cells = <2>;
> > > + reg = <0x700 0x100>;
> > > + device_type = "ipic";
> >
> > This should have a compatible property. It shouldn't really have
> > device_type, but I suspect that's a bug in the ipic binding, rather
> > than your tree per-se.
>
> The binding for this seems to be done in the setup file,
> arch/powerpc/platforms/83xx/thecus_n1200.c in my case. At the moment it
> does:
> np = of_find_node_by_type(NULL, "ipic");
> ...
> ipic_init(np, 0);
> so making it look for something like "fsl,mpc8347-ipic" should be no
> problem if that's how it should be done.
Ok, sounds good. device_type is a hangover from real OF - where it
advertises what method interface the node supports. As such it has
little place in flattened trees and should not be used for driver
binding.
> > > + };
> > > +
> > > + gpio1: gpio-controller@c00 {
> > > + #gpio-cells = <2>;
> > > + compatible = "fsl,mpc8347-gpio", "fsl,mpc8349-gpio";
> >
> > This actually is an 8349 board, yes? Generally compatible should be
> > listed from most specific to least specific, so the 8349 entry should
> > go first.
>
> No, as Peter pointed out this is an 8347. The soc8349 at the top was
> probably a combination of basing this dts on an 8349 one and the fact that
> most of the freescale docs for 8347 just point to 8349 ones. I've made
> sure the only place 8349 is referenced is in compatible fields and it's
> always after the 8347 version.
Ok, 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
* Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Stefan Roese @ 2009-06-06 3:59 UTC (permalink / raw)
To: linux-mtd; +Cc: linuxppc-dev, devicetree-discuss, David Woodhouse
In-Reply-To: <200904161549.44841.sr@denx.de>
On Thursday 16 April 2009 15:49:44 Stefan Roese wrote:
> > Okay. It will be good to get this one into -next for some testing
> > exposure. Unless he asks me to do otherwise, I'll leave this one to
> > David to pick up.
>
> Understood. Thanks Grant.
David, just checking on the status of this patch. Is it in your queue for the
next merge window?
Thanks,
Stefan
^ permalink raw reply
* Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
From: Benjamin Herrenschmidt @ 2009-06-06 4:16 UTC (permalink / raw)
To: David Miller
Cc: sachinp, sfr, greg, linux-kernel, Linuxppc-dev, linux-next,
paulus, Geert.Uytterhoeven, geert, subrata
In-Reply-To: <20090605.175656.95336229.davem@davemloft.net>
On Fri, 2009-06-05 at 17:56 -0700, David Miller wrote:
> >
> > Read my reply to Greg. Why the heck are you trying to map memory
> > non-cacheable in the first place ?
>
> I agree, this is extremely fishy.
>
> I guess the issue is that the driver wants consistent DMA memory
> but wants to allocate a huge area vmap() style.
That's my guess too, and I suppose we should be able to provide an
appropriate interface for that... There are two aspects that
are completely separate here:
- One is the allocation of the pages themselves which much match
the various criteria for DMA'bility to the target device (fit the
DMA mask, etc...)
- One is the creation of the virtual mapping in kernel space for which
appropriate pgprot for DMA must be provided.
For the first one, I don't know how legit it would be to allocate the
pages using dma_alloc_coherent one page at a time and try to figure out
the struct page * out of it. Sounds fishy and possibly non-portable. So
appart from using normal GFP and crossing fingers I'm not sure what
would be the right way to obtain the pages in the first place. Maybe we
should provide something.
The second could be as simple as having a pgprot_dma_coherent() like we
have a pgprot_uncached() for example, which would be either uncached or
cached depending on the consistency of DMA on the platform. But we need
to run that through things like MIPS which may have additional virtual
address space requirements.
Cheers,
Ben.
^ permalink raw reply
* Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
From: Greg KH @ 2009-06-06 5:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Ian Abbott, Frank Mori Hess
Cc: sachinp, sfr, linux-kernel, Linuxppc-dev, linux-next, paulus,
Geert.Uytterhoeven, geert, subrata, David Miller
In-Reply-To: <1244261806.31984.36.camel@pasglop>
On Sat, Jun 06, 2009 at 02:16:46PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-05 at 17:56 -0700, David Miller wrote:
> > >
> > > Read my reply to Greg. Why the heck are you trying to map memory
> > > non-cacheable in the first place ?
> >
> > I agree, this is extremely fishy.
> >
> > I guess the issue is that the driver wants consistent DMA memory
> > but wants to allocate a huge area vmap() style.
>
> That's my guess too, and I suppose we should be able to provide an
> appropriate interface for that... There are two aspects that
> are completely separate here:
>
> - One is the allocation of the pages themselves which much match
> the various criteria for DMA'bility to the target device (fit the
> DMA mask, etc...)
>
> - One is the creation of the virtual mapping in kernel space for which
> appropriate pgprot for DMA must be provided.
>
> For the first one, I don't know how legit it would be to allocate the
> pages using dma_alloc_coherent one page at a time and try to figure out
> the struct page * out of it. Sounds fishy and possibly non-portable. So
> appart from using normal GFP and crossing fingers I'm not sure what
> would be the right way to obtain the pages in the first place. Maybe we
> should provide something.
>
> The second could be as simple as having a pgprot_dma_coherent() like we
> have a pgprot_uncached() for example, which would be either uncached or
> cached depending on the consistency of DMA on the platform. But we need
> to run that through things like MIPS which may have additional virtual
> address space requirements.
All good questions. So, let's ask the original authors :)
Frank and Ian, any thoughts about the vmap call in the
comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what
is the prealloc_buf buffer used for?
The problem is that PAGE_KERNEL_NOCACHE isn't a "standard" interface,
and not all architectures support it.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: David Woodhouse @ 2009-06-06 7:25 UTC (permalink / raw)
To: dedekind; +Cc: linuxppc-dev, Stefan Roese, linux-mtd, devicetree-discuss
In-Reply-To: <1239956778.3390.262.camel@localhost.localdomain>
On Fri, 2009-04-17 at 11:26 +0300, Artem Bityutskiy wrote:
>
> I'm going to try to help you. I've just created a git tree where
> I'll push patches I consider OK and I approve. Here it is:
> git://git.infradead.org/users/dedekind/l2-mtd-2.6.git
>
> My hope is that you would look at that tree from time to time
> and pull it. At least you may be sure I looked at the patches and
> did some validation. This should save your time and help MTD
> users.
This was _really_ useful. Thank you very much.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
From: David Woodhouse @ 2009-06-06 8:14 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree-discuss, albrecht.dress, linuxppc-dev, linux-mtd,
Ben Dooks
In-Reply-To: <1244203514-12516-3-git-send-email-w.sang@pengutronix.de>
On Fri, 2009-06-05 at 14:05 +0200, Wolfram Sang wrote:
> Create an of-aware driver using the now exported generic functions from
> plat-ram.c. Also add the documentation for the binding. Partitions are
> not yet supported. Tested on a phyCORE-MPC5200B-IO.
Do we have an ack for the device-tree bindings?
It _would_ be possible to hook up RAM through the existing of_physmap
driver, I think -- although it would be slightly less efficient that
way.
Maybe cleaner from the device-tree POV though. And if we want to put a
special case in the _code_ to make it more efficient, we can do that.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply
* Re: mailing list moving
From: Michael Ellerman @ 2009-06-06 8:37 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, linuxppc-dev-owner
In-Reply-To: <20090605190831.c5d59095.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
On Fri, 2009-06-05 at 19:08 +1000, Stephen Rothwell wrote:
> Hi Michael,
>
> On Fri, 05 Jun 2009 17:38:40 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
> >
> > On Fri, 2009-06-05 at 17:26 +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > On Sun, 31 May 2009 15:09:50 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > The archives on lists.ozlabs.org (and ozlabs.org) have unfortunately not
> > > retained their URLs (the basename of the article URLs changed).
> >
> > Would a rewrite rule fix it? It'd be nice for them to keep working.
>
> No, because the actual article numbers changed when I rebuilt the archive
> on the new server.
>
> Sorry.
>
> I do, however, have the old archives, so maybe we can do something ...
We could use the old archive to work out the mapping between old and new
and write a billion rewrite rules, but it'd probably crash the rewrite
code - and if not slow the server to a crawl.
So into the too hard basket I think :)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
From: Wolfram Sang @ 2009-06-06 11:19 UTC (permalink / raw)
To: David Woodhouse
Cc: devicetree-discuss, albrecht.dress, linuxppc-dev, linux-mtd,
Ben Dooks
In-Reply-To: <1244276049.3751.1176.camel@macbook.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]
On Sat, Jun 06, 2009 at 09:14:08AM +0100, David Woodhouse wrote:
> On Fri, 2009-06-05 at 14:05 +0200, Wolfram Sang wrote:
> > Create an of-aware driver using the now exported generic functions from
> > plat-ram.c. Also add the documentation for the binding. Partitions are
> > not yet supported. Tested on a phyCORE-MPC5200B-IO.
>
> Do we have an ack for the device-tree bindings?
>
> It _would_ be possible to hook up RAM through the existing of_physmap
> driver, I think -- although it would be slightly less efficient that
> way.
>
> Maybe cleaner from the device-tree POV though. And if we want to put a
> special case in the _code_ to make it more efficient, we can do that.
During development, I also checked physmap_of.c and found this binding:
{
.type = "rom",
.compatible = "direct-mapped"
},
which made some sense to me and I thought about .type = "ram". However, I then
found this in the code:
/* Helper function to handle probing of the obsolete "direct-mapped"
* compatible binding, which has an extra "probe-type" property
* describing the type of flash probe necessary. */
static struct mtd_info * __devinit obsolete_probe(struct of_device *dev,
struct map_info *map)
{
[...]
dev_warn(&dev->dev, "Device tree uses obsolete \"direct-mapped\" "
"flash binding\n");
My conclusion was then that a mtd-ram binding wouldn't belong here, but I have
maybe misinterpreted things...
Regards,
Wolfram
--
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
* Missing some interrupts
From: wael showair @ 2009-06-06 13:17 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
i have a freescale board, that contains MPC8555 processor & DSP-core
there is a GPIO connecting the DSP-core into an input pin of the OpenPIC of
the MPC8555 processor.
i test one interrupt from the DSP-core to the MPC8555 processor where i
configure this interrupt line to be edge-triggered (falling edge) & i
receive it successfully
but
when i generate this interrupt 10 successive times using for loop
i just receive 2 interrupts?
why can't i receive the 8 other interrupts?
i print the value of every irq number inside do_IRQ & i found that i receive
the DSP-interrupt just only twice.
do u have any suggestions to solve this problem?
i want to make sure that i can receive 10 interrupts
--
View this message in context: http://www.nabble.com/Missing-some-interrupts-tp23901807p23901807.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Missing some interrupts
From: Jon Smirl @ 2009-06-06 13:34 UTC (permalink / raw)
To: wael showair; +Cc: linuxppc-dev
In-Reply-To: <23901807.post@talk.nabble.com>
On Sat, Jun 6, 2009 at 9:17 AM, wael showair<showair2003@yahoo.com> wrote:
>
> Hi All,
> i have a freescale board, that contains MPC8555 processor & DSP-core
> there is a GPIO connecting the DSP-core into an input pin of the OpenPIC of
> the MPC8555 processor.
>
> i test one interrupt from the DSP-core to the MPC8555 processor where i
> configure this interrupt line to be edge-triggered (falling edge) & i
> receive it successfully
> but
> when i generate this interrupt 10 successive times using for loop
> i just receive 2 interrupts?
>
> why can't i receive the 8 other interrupts?
> i print the value of every irq number inside do_IRQ & i found that i receive
> the DSP-interrupt just only twice.
>
> do u have any suggestions to solve this problem?
> i want to make sure that i can receive 10 interrupts
Don't do a printk() with interrupts disabled. A printk() takes 1.5ms
on a mpc5200.
> --
> View this message in context: http://www.nabble.com/Missing-some-interrupts-tp23901807p23901807.html
> Sent from the linuxppc-dev mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
From: Frank Mori Hess @ 2009-06-06 13:36 UTC (permalink / raw)
To: Greg KH
Cc: sachinp, Frank Mori Hess, sfr, linux-kernel, Linuxppc-dev,
Ian Abbott, linux-next, paulus, Geert.Uytterhoeven, geert,
subrata, David Miller
In-Reply-To: <20090606055103.GA9446@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
On Saturday 06 June 2009, Greg KH wrote:
> Frank and Ian, any thoughts about the vmap call in the
> comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what
> is the prealloc_buf buffer used for?
It is a circular buffer used to hold data streaming either to or from a
board (for example when producing an analog output waveform). Reads and
writes to the device files read/write to the circular buffer, plus a few
drivers do dma directly to/from it. I personally don't have a problem
with requiring drivers to have their own dma buffers and making them copy
data between their private dma buffers and the main circular buffer. I
guess the original design wanted to support zero-copy dma.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: SD card over (xilinx_)SPI, timeout error while CID
From: Peter Korsgaard @ 2009-06-06 15:14 UTC (permalink / raw)
To: Joachim Foerster; +Cc: joachim, linuxppc-dev, dbrownell, john.linn, lorenz
In-Reply-To: <1244216069.21470.12.camel@localhost>
>>>>> "Joachim" == Joachim Foerster <JOFT@gmx.de> writes:
Hi,
Joachim> Any hints? Does anybody use SD card support with
Joachim> mmc_spi+xilinx_spi ?
I don't, but have you compared the spi signals on a scope in the 2
setups? Is timing significantly different?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
From: Grant Likely @ 2009-06-06 16:05 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree-discuss, albrecht.dress, linuxppc-dev, linux-mtd,
Ben Dooks, David Woodhouse
In-Reply-To: <1244203514-12516-3-git-send-email-w.sang@pengutronix.de>
On Fri, Jun 5, 2009 at 6:05 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
> diff --git a/Documentation/powerpc/dts-bindings/mtd-ram.txt b/Documentati=
on/powerpc/dts-bindings/mtd-ram.txt
> new file mode 100644
> index 0000000..a2e9932
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/mtd-ram.txt
> @@ -0,0 +1,18 @@
> +RAM emulating an MTD
> +
> +An external RAM like SRAM or FRAM can also be treated as an MTD.
> +
> + - compatible : should contain the specific model of the RAM chip
> + =A0 used, if known, followed by "mtd-ram".
> + - reg : Address range of the RAM chip
> + - bank-width : Width (in bytes) of the RAM bank.
Question: why is bank-width even relevant for a RAM device?
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
From: Albrecht Dreß @ 2009-06-06 16:16 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linuxppc-dev, linux-mtd, Ben Dooks,
David Woodhouse
In-Reply-To: <fa686aa40906060905y1d39dce1j87d993ceb94273be@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 584 bytes --]
Am 06.06.09 18:05 schrieb(en) Grant Likely:
> > + - bank-width : Width (in bytes) of the RAM bank.
>
> Question: why is bank-width even relevant for a RAM device?
At least if the RAM is attached to the 5200's Local Plus Bus in 16-bit
mode, no byte write accesses are allowed (byte /reads/ work, though).
I have a tweak (which I will post next week) to address this case,
which depends upon this setting. No idea if the same happens on other
chips and/or on 5200 in 32-bit (muxed) mode, but I guess similar
effects will pop up there, too.
Cheers, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH v2] Add MSI interrupts to DTS of MPC8315E-RDB
From: leon.woestenberg @ 2009-06-06 16:15 UTC (permalink / raw)
To: linuxppc-dev, galak, linux-kernel, Leon Woestenberg
The PCIe MSI interrupts are missing from the device tree source, and
thus were not enabled. This patch adds them.
v2 of the patch fixes inconsistent white space, reported by David Gibson.
Tested to work on MPC8315E-RDB with custom FPGA PCIe device.
Signed-off-by: Leon Woestenberg <leon@sidebranch.com>
Tested-by: Leon Woestenberg <leon@sidebranch.com>
Index: git/arch/powerpc/boot/dts/mpc8315erdb.dts
===================================================================
--- git.orig/arch/powerpc/boot/dts/mpc8315erdb.dts 2009-05-23 20:49:40.000000000 +0200
+++ git/arch/powerpc/boot/dts/mpc8315erdb.dts 2009-06-06 10:35:14.000000000 +0200
@@ -322,6 +322,21 @@
reg = <0x700 0x100>;
device_type = "ipic";
};
+
+ ipic-msi@7c0 {
+ compatible = "fsl,ipic-msi";
+ reg = <0x7c0 0x40>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <0x43 0x8
+ 0x4 0x8
+ 0x51 0x8
+ 0x52 0x8
+ 0x56 0x8
+ 0x57 0x8
+ 0x58 0x8
+ 0x59 0x8>;
+ interrupt-parent = < &ipic >;
+ };
};
pci0: pci@e0008500 {
^ permalink raw reply
* Please pull -next branch from git.secretlab.ca
From: Grant Likely @ 2009-06-06 16:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Roderick Colenbrander, linuxppc-dev
Hi Ben,
Here are some new commits to support the Xilinx ML507 board for 2.6.31
The following changes since commit baf75b0a42a1b3f6fca80f8949b6141eaff61b0d:
Stephen Rothwell (1):
powerpc/pci: Fix annotation of pcibios_claim_one_bus
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 next
Grant Likely (1):
powerpc/virtex: refactor intc driver and add support for i8259 cascading
Roderick Colenbrander (3):
powerpc/virtex: Add support for Xilinx PCI host bridge
powerpc/virtex: Add Xilinx ML510 reference design support
powerpc/virtex: Add ml510 reference design device tree
arch/powerpc/boot/dts/virtex440-ml510.dts | 465 +++++++++++++++++++++++++++++
arch/powerpc/include/asm/xilinx_pci.h | 21 ++
arch/powerpc/platforms/40x/virtex.c | 2 +
arch/powerpc/platforms/44x/Kconfig | 13 +-
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/virtex.c | 2 +
arch/powerpc/platforms/44x/virtex_ml510.c | 29 ++
arch/powerpc/platforms/Kconfig | 4 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/xilinx_intc.c | 81 ++++--
arch/powerpc/sysdev/xilinx_pci.c | 132 ++++++++
11 files changed, 732 insertions(+), 19 deletions(-)
create mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
create mode 100644 arch/powerpc/include/asm/xilinx_pci.h
create mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
create mode 100644 arch/powerpc/sysdev/xilinx_pci.c
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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