* 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: [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] 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: [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: 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: 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: [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: [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
* 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: 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 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: [OOPS] hugetlbfs tests with 2.6.30-rc8-git1
From: Benjamin Herrenschmidt @ 2009-06-05 20:17 UTC (permalink / raw)
To: Sachin Sant; +Cc: Mel Gorman, linuxppc-dev
In-Reply-To: <4A290195.3080807@in.ibm.com>
On Fri, 2009-06-05 at 16:59 +0530, Sachin Sant wrote:
> While executing Hugetlbfs tests against 2.6.30-rc8-git1 on a
> Power 6 box observed the following OOPS message.
> NIP [c000000000038240] .hpte_need_flush+0x1bc/0x2d8
> LR [c0000000000380f0] .hpte_need_flush+0x6c/0x2d8
Weird. I don't really see what happened there.
> Call Trace:
> [c0000000fa8ff710] [c000000000038264] .hpte_need_flush+0x1e0/0x2d8 (unreliable)
> [c0000000fa8ff7d0] [c000000000039fa4] .huge_ptep_get_and_clear+0x40/0x5c
> [c0000000fa8ff850] [c00000000012d46c] .__unmap_hugepage_range+0x178/0x2b8
> [c0000000fa8ff940] [c00000000012d600] .unmap_hugepage_range+0x54/0x88
> [c0000000fa8ff9e0] [c0000000001173a0] .unmap_vmas+0x178/0x8f4
> [c0000000fa8ffb30] [c00000000011cab8] .unmap_region+0xfc/0x1e4
> [c0000000fa8ffc00] [c00000000011e248] .do_munmap+0x2f4/0x38c
> [c0000000fa8ffcc0] [c0000000002f6d74] .SyS_shmdt+0xc0/0x188
> [c0000000fa8ffd70] [c00000000000c430] .sys_ipc+0x274/0x2fc
> [c0000000fa8ffe30] [c000000000008534] syscall_exit+0x0/0x40
> Instruction dump:
> 78090220 2fbd0000 409e0010 7929e0e4 7be00120 4800000c 792945c6 7be00600
> 7d3f0378 7c1cb82e 3d360001 2f800000 <eb898000> 409e0028 7fe3fb78 7f24cb78
The call trace looks rather ordinary. In fact, the DAR address doesn't
even look that bad, depends how much RAM you have in this partition I
suppose.
> I first noticed this with 2.6.30-rc7-git3 on a power6 machine,
> but could not recreate again on the same machine. Now the problem
> has resurfaced again with 2.6.30-rc8 (and with git1 as well) on
> another Power6 box.
>
> I had seen similar failures(although the back trace was different,
> crash point was same) with older kernels and Mel submitted a patch
> to fix that issue. Here is the link to that patch.
>
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-May/071395.html
>
> I have attached the .config.
No, Mel's patch is for a different problem and has been fixed upstream
already. This is more concerning... I'm not sure what's up but would
you be able to send a disassembly of the hpte_need_flush() function in
your kernel binary for me to see what access precisely caused the
fault ?
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-05 18:26 UTC (permalink / raw)
To: Subrata Modak
Cc: Sachin P Sant, Stephen Rothwell, Linux-Kernel, Linuxppc-dev,
Linux-Next, Paul Mackerras, Geert Uytterhoeven,
Geert Uytterhoeven
In-Reply-To: <20090605182625.24093.7808.sendpatchset@elm3a191.beaverton.ibm.com>
On Fri, Jun 05, 2009 at 01:26:25PM -0500, Subrata Modak wrote:
> >On Thu, 2009-06-04 at 22:40 +0200, Geert Uytterhoeven wrote:
> >On Thu, Jun 4, 2009 at 20:07, Greg KH <greg@kroah.com> wrote:
> > > On Thu, Jun 04, 2009 at 07:01:32PM +0530, Subrata Modak wrote:
> > >> CC [M] drivers/staging/comedi/drivers.o
> > >> drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’:
> > >> drivers/staging/comedi/drivers.c:496: error: ‘PAGE_KERNEL_NOCACHE’ undeclared (first use in this function)
> > >> drivers/staging/comedi/drivers.c:496: error: (Each undeclared identifier is reported only once
> > >> drivers/staging/comedi/drivers.c:496: error: for each function it appears in.)
> > >> make[3]: *** [drivers/staging/comedi/drivers.o] Error 1
> > >> make[2]: *** [drivers/staging/comedi] Error 2
> > >> make[1]: *** [drivers/staging] Error 2
> > >> make: *** [drivers] Error 2
> > >>
> > >> Is it still normal to expect this failure ?
> > >
> > > No.
> > >
> > >> I reported them long back during April:
> > >> http://www.gossamer-threads.com/lists/linux/kernel/1065227,
> > >
> > > Yes, and I took some patches that were supposed to fix this. I can't
> > > duplicate this here, care to send a patch that would fix it?
>
> 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 ?
>
> The below patch fixes the build error.
Ick, that's a mess.
> +#ifdef __powerpc64__
> + vmap(pages, n_pages, VM_MAP,
> + PAGE_KERNEL_NC);
> +#else
> vmap(pages, n_pages, VM_MAP,
> PAGE_KERNEL_NOCACHE);
> +#endif
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?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] [POWERPC] 83xx: Add support for the Thecus N1200 NAS device
From: Byron Bradley @ 2009-06-05 18:44 UTC (permalink / raw)
To: Byron Bradley, linuxppc-dev, galak, tim.ellis, Peter Korsgaard
In-Reply-To: <20090605030850.GF2054@yookeroo.seuss>
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.
>
> > + 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"
> > + reg = <0xfe000000 0x0800000>;
> > + bank-width = <2>;
> > + device-width = <1>;
> > +
> > + u-boot@0 {
> > + reg = <0x0 0x040000>;
> > + read-only;
> > + };
> > +
> > + u-boot-config@40000 {
> > + reg = <0x040000 0x040000>;
> > + label = "u-boot config";
> > + };
> > +
> > + user@080000 {
> > + reg = <0x080000 0x100000>;
> > + };
> > +
> > + kernel@180000 {
> > + reg = <0x180000 0x1a0000>;
> > + };
> > +
> > + ramdisk@320000 {
> > + reg = <0x320000 0x4e0000>;
> > + };
> > + };
> > +
> > + wdt@200 {
> > + device_type = "watchdog";
>
> No device_type here.
Removed all device_type entries that you said shouldn't be there.
> > + fanctrl@32 {
>
> A less abbreviated name, like "fan-control" would be more usual here.
>
> > + compatible = "fintek,f75375";
> > + reg = <0x2e>;
> > + };
> > +
> > + rtc@32 {
> > + device_type = "rtc";
> > + compatible = "ricoh,rs5c372a";
> > + reg = <0x32>;
> > + };
> > +
> > + boardctrl@32 {
>
> Again "board-control" would be preferable.
Both changed.
> > + 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.
> > + };
> > +
> > + 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.
Cheers,
--
Byron Bradley
^ permalink raw reply
* Re: [BUILD FAILURE 02/04] Next June 04:PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
From: Subrata Modak @ 2009-06-05 18:26 UTC (permalink / raw)
To: linux-usb, David Brownell, David Brownell, Arnd Bergmann
Cc: Sachin P Sant, Randy Dunlap, Roman Weissgaerber, Stephen Rothwell,
Linux-Kernel, Linuxppc-dev, Linux-Next, Subrata Modak, kernel
>On Thu, 2009-06-04 at 10:07 -0400, Jon Smirl wrote:
>On Thu, Jun 4, 2009 at 9:31 AM, Subrata Modak
> <subrata@linux.vnet.ibm.com> wrote:
> > CC drivers/usb/host/ohci-hcd.o
> > In file included from drivers/usb/host/ohci-hcd.c:1060:
> > drivers/usb/host/ohci-ppc-of.c:242:2: error: #error "No endianess selected for ppc-of-ohci"
> > make[3]: *** [drivers/usb/host/ohci-hcd.o] Error 1
> > make[2]: *** [drivers/usb/host] Error 2
> > make[1]: *** [drivers/usb] Error 2
> > make: *** [drivers] Error 2
> >
> > I reported this earlier, and there were some discussions:
> > http://groups.google.co.kr/group/linux.kernel/browse_thread/thread/edff9d5572d3d225
>
> Proposed patch by Arnd should fix this. It has not been merged.
> http://lkml.org/lkml/2009/4/22/49
Correct, it fixes the issue. However, since few changes might have gone
to the Kconfig, the patch does not apply cleanly. Below is the patch, just
a retake of the earlier one, but on the latest code.
David,
Can you please pickup the following patch ?
Signed-off-by: Arnd Bergmann <arnd@arndb.de>,
Resent-by: Subrata Modak <subrata@linux.vnet.ibm.com>
---
--- linux-2.6.30-rc8/drivers/usb/host/Kconfig.orig 2009-06-05 10:31:30.000000000 -0500
+++ linux-2.6.30-rc8/drivers/usb/host/Kconfig 2009-06-05 10:37:53.000000000 -0500
@@ -181,26 +181,26 @@ config USB_OHCI_HCD_PPC_SOC
Enables support for the USB controller on the MPC52xx or
STB03xxx processor chip. If unsure, say Y.
-config USB_OHCI_HCD_PPC_OF
- bool "OHCI support for PPC USB controller on OF platform bus"
- depends on USB_OHCI_HCD && PPC_OF
- default y
- ---help---
- Enables support for the USB controller PowerPC present on the
- OpenFirmware platform bus.
-
config USB_OHCI_HCD_PPC_OF_BE
- bool "Support big endian HC"
- depends on USB_OHCI_HCD_PPC_OF
- default y
+ bool "OHCI support for OF platform bus (big endian)"
+ depends on USB_OHCI_HCD && PPC_OF
select USB_OHCI_BIG_ENDIAN_DESC
select USB_OHCI_BIG_ENDIAN_MMIO
+ ---help---
+ Enables support for big-endian USB controllers present on the
+ OpenFirmware platform bus.
config USB_OHCI_HCD_PPC_OF_LE
- bool "Support little endian HC"
- depends on USB_OHCI_HCD_PPC_OF
- default n
+ bool "OHCI support for OF platform bus (little endian)"
+ depends on USB_OHCI_HCD && PPC_OF
select USB_OHCI_LITTLE_ENDIAN
+ ---help---
+ Enables support for little-endian USB controllers present on the
+ OpenFirmware platform bus.
+
+ config USB_OHCI_HCD_PPC_OF
+ bool
+ default USB_OHCI_HCD_PPC_OF_BE || USB_OHCI_HCD_PPC_OF_LE
config USB_OHCI_HCD_PCI
bool "OHCI support for PCI-bus USB controllers"
---
Regards--
Subrata
>
^ permalink raw reply
* Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
From: Subrata Modak @ 2009-06-05 18:26 UTC (permalink / raw)
To: Paul Mackerras, Greg KH, Benjamin Herrenschmidt
Cc: Sachin P Sant, Stephen Rothwell, Linux-Kernel, Linuxppc-dev,
Linux-Next, Geert Uytterhoeven, Geert Uytterhoeven, Subrata Modak
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]
>On Thu, 2009-06-04 at 22:40 +0200, Geert Uytterhoeven wrote:
>On Thu, Jun 4, 2009 at 20:07, Greg KH <greg@kroah.com> wrote:
> > On Thu, Jun 04, 2009 at 07:01:32PM +0530, Subrata Modak wrote:
> >> CC [M] drivers/staging/comedi/drivers.o
> >> drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’:
> >> drivers/staging/comedi/drivers.c:496: error: ‘PAGE_KERNEL_NOCACHE’ undeclared (first use in this function)
> >> drivers/staging/comedi/drivers.c:496: error: (Each undeclared identifier is reported only once
> >> drivers/staging/comedi/drivers.c:496: error: for each function it appears in.)
> >> make[3]: *** [drivers/staging/comedi/drivers.o] Error 1
> >> make[2]: *** [drivers/staging/comedi] Error 2
> >> make[1]: *** [drivers/staging] Error 2
> >> make: *** [drivers] Error 2
> >>
> >> Is it still normal to expect this failure ?
> >
> > No.
> >
> >> I reported them long back during April:
> >> http://www.gossamer-threads.com/lists/linux/kernel/1065227,
> >
> > Yes, and I took some patches that were supposed to fix this. I can't
> > duplicate this here, care to send a patch that would fix it?
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 ?
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
* how can i send real-time signal?
From: wael showair @ 2009-06-05 17:41 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
i m using linux-kernel 2.6.27 & a board of MPC8555 processor.
i have also DSP-core on the same board.
My aim is : Each time the DSP-core interrupts the MPC8555 processor, a
process in the user space will be informed by the arrival of this each
interrupt.
So i decided to use sw signals, in the ISR of the DSP-core interrupt i send
a SW signal to the user space process? Is this the best solution? are there
any better suggestion to achieve my aim?
i used the kernel API send_sig_info because i want to send information with
the sent signal & my signal type was SIGUSR1
i could receive the SW signal successfully but i found out that the standard
SW signals are not queued if they r in the pending queue of the user space
process but the real-time signals do.
so i changed the type of the signal to SIGRTMIN but unfortunately i could
receive any SW signal from my ISR & i noticed that always the second
interrupt causes a kernel panic
so am i using the correct signal type?
am i using the correct kernel API to send a real-time SW signal?
plz help
--
View this message in context: http://www.nabble.com/how-can-i-send-real-time-signal--tp23892580p23892580.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
From: Albrecht Dreß @ 2009-06-05 16:22 UTC (permalink / raw)
To: Wolfram Sang
Cc: linuxppc-dev, devicetree-discuss, linux-mtd, David Woodhouse,
Ben Dooks
In-Reply-To: <1244203514-12516-3-git-send-email-w.sang@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 938 bytes --]
Am 05.06.09 14:05 schrieb(en) Wolfram Sang:
> 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.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Albrecht Dreß <albrecht.dress@arcor.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Ben Dooks <ben-linux@fluff.org>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: linuxppc-dev@ozlabs.org
> Cc: devicetree-discuss@ozlabs.org
> Cc: linux-mtd@lists.infradead.org
These patches work great for me on a self-designed, roughly Icecube
based, 5200B board, with a 512kB NV Ram. As I use 16-bit accesses via
the Local Plus bus to the chip, I had to add some more tweaks to other
files, which I promise to post next week...
Thanks, Albrecht.
Acked-by: Albrecht Dreß <albrecht.dress@arcor.de>
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
From: Grant Likely @ 2009-06-05 15:53 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:
> 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.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Albrecht Dre=DF <albrecht.dress@arcor.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Ben Dooks <ben-linux@fluff.org>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: linuxppc-dev@ozlabs.org
> Cc: devicetree-discuss@ozlabs.org
> Cc: linux-mtd@lists.infradead.org
On brief review, looks good to me (for both patches).
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> Changes in V2:
>
> - added binding documentation
> - added __devinit & friends
> - put struct resource on stack during probe
> - simplified getting the name of the of-device
> - made error path more readable & add check for valid bank-width-pointer
> - rename driver to "of-mtd-ram"
>
> =A0Documentation/powerpc/dts-bindings/mtd-ram.txt | =A0 18 ++++
> =A0drivers/mtd/maps/Kconfig =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |=
=A0 =A07 ++
> =A0drivers/mtd/maps/Makefile =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=
=A0 =A01 +
> =A0drivers/mtd/maps/of-ram.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|=
=A0102 ++++++++++++++++++++++++
> =A04 files changed, 128 insertions(+), 0 deletions(-)
> =A0create mode 100644 Documentation/powerpc/dts-bindings/mtd-ram.txt
> =A0create mode 100644 drivers/mtd/maps/of-ram.c
>
> 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.
> +
> +Partitions are not yet supported.
> +
> +Example:
> +
> + =A0 =A0 =A0 sram@2,0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 compatible =3D "samsung,k6f1616u6a", "mtd-r=
am";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 reg =3D <2 0 0x00200000>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 bank-width =3D <2>;
> + =A0 =A0 =A0 };
> diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
> index 82923bd..bdd9ebc 100644
> --- a/drivers/mtd/maps/Kconfig
> +++ b/drivers/mtd/maps/Kconfig
> @@ -551,6 +551,13 @@ config MTD_PLATRAM
>
> =A0 =A0 =A0 =A0 =A0This selection automatically selects the map_ram drive=
r.
>
> +config MTD_OFRAM
> + =A0 =A0 =A0 tristate "Map driver for of-device RAM (of-mtd-ram)"
> + =A0 =A0 =A0 depends on MTD_PLATRAM && OF
> + =A0 =A0 =A0 help
> + =A0 =A0 =A0 =A0 Map driver for RAM areas described via the of-device
> + =A0 =A0 =A0 =A0 system.
> +
> =A0config MTD_VMU
> =A0 =A0 =A0 =A0tristate "Map driver for Dreamcast VMU"
> =A0 =A0 =A0 =A0depends on MAPLE
> diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
> index 2dbc1be..a7a2db3 100644
> --- a/drivers/mtd/maps/Makefile
> +++ b/drivers/mtd/maps/Makefile
> @@ -57,6 +57,7 @@ obj-$(CONFIG_MTD_IXP2000) =A0 =A0 +=3D ixp2000.o
> =A0obj-$(CONFIG_MTD_WRSBC8260) =A0 =A0+=3D wr_sbc82xx_flash.o
> =A0obj-$(CONFIG_MTD_DMV182) =A0 =A0 =A0 +=3D dmv182.o
> =A0obj-$(CONFIG_MTD_PLATRAM) =A0 =A0 =A0+=3D plat-ram.o
> +obj-$(CONFIG_MTD_OFRAM) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+=3D of-ram.o
> =A0obj-$(CONFIG_MTD_OMAP_NOR) =A0 =A0 +=3D omap_nor.o
> =A0obj-$(CONFIG_MTD_INTEL_VR_NOR) +=3D intel_vr_nor.o
> =A0obj-$(CONFIG_MTD_BFIN_ASYNC) =A0 +=3D bfin-async-flash.o
> diff --git a/drivers/mtd/maps/of-ram.c b/drivers/mtd/maps/of-ram.c
> new file mode 100644
> index 0000000..e2f4476
> --- /dev/null
> +++ b/drivers/mtd/maps/of-ram.c
> @@ -0,0 +1,102 @@
> +/*
> + * Generic of device based RAM map
> + *
> + * Copyright (C) 2009 Wolfram Sang, Pengutronix
> + *
> + * Using plat-ram.c by Ben Dooks
> + *
> + * This program is free software; you can redistribute it and/or modify =
it
> + * under the terms of the GNU General Public License version 2 as publis=
hed by
> + * the Free Software Foundation.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/platform_device.h>
> +#include <linux/of_device.h>
> +#include <linux/of_platform.h>
> +#include <linux/mtd/plat-ram.h>
> +
> +static __devinit int of_ram_probe(struct of_device *op,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 const struct of_device_id *=
match)
> +{
> + =A0 =A0 =A0 struct platdata_mtd_ram *pdata;
> + =A0 =A0 =A0 struct resource res;
> + =A0 =A0 =A0 const u32 *bankwidth;
> + =A0 =A0 =A0 int ret =3D -ENOENT;
> +
> + =A0 =A0 =A0 pdata =3D kzalloc(sizeof(*pdata), GFP_KERNEL);
> + =A0 =A0 =A0 if (!pdata)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -ENOMEM;
> + =A0 =A0 =A0 op->dev.platform_data =3D pdata;
> +
> + =A0 =A0 =A0 ret =3D of_address_to_resource(op->node, 0, &res);
> + =A0 =A0 =A0 if (ret) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_dbg(&op->dev, "could not create resourc=
e (%d)\n", ret);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_free;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 bankwidth =3D of_get_property(op->node, "bank-width", NULL)=
;
> + =A0 =A0 =A0 if (!bankwidth || *bankwidth =3D=3D 0) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_dbg(&op->dev, "bank width not set\n");
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_free;
> + =A0 =A0 =A0 }
> + =A0 =A0 =A0 pdata->bankwidth =3D *bankwidth;
> +
> + =A0 =A0 =A0 ret =3D __platram_probe(&op->dev, op->node->name, &res, pda=
ta);
> + =A0 =A0 =A0 if (ret) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_dbg(&op->dev, "error probing device (%d=
)\n", ret);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out_free;
> + =A0 =A0 =A0 }
> +
> + =A0 =A0 =A0 return 0;
> +
> +out_free:
> + =A0 =A0 =A0 op->dev.platform_data =3D NULL;
> + =A0 =A0 =A0 kfree(pdata);
> + =A0 =A0 =A0 return ret;
> +}
> +
> +static __devexit int of_ram_remove(struct of_device *op)
> +{
> + =A0 =A0 =A0 int ret;
> + =A0 =A0 =A0 struct platdata_mtd_ram *pdata =3D op->dev.platform_data;
> +
> + =A0 =A0 =A0 ret =3D __platram_remove(&op->dev);
> + =A0 =A0 =A0 op->dev.platform_data =3D NULL;
> + =A0 =A0 =A0 kfree(pdata);
> + =A0 =A0 =A0 return ret;
> +}
> +
> +static const struct of_device_id __devinitconst of_ram_match[] =3D {
> + =A0 =A0 =A0 { .compatible =3D "mtd-ram", },
> + =A0 =A0 =A0 {},
> +};
> +MODULE_DEVICE_TABLE(of, of_ram_match);
> +
> +static struct of_platform_driver of_ram_driver =3D {
> + =A0 =A0 =A0 .owner =3D THIS_MODULE,
> + =A0 =A0 =A0 .name =3D "of-mtd-ram",
> + =A0 =A0 =A0 .match_table =3D of_ram_match,
> + =A0 =A0 =A0 .probe =3D of_ram_probe,
> + =A0 =A0 =A0 .remove =3D __devexit_p(of_ram_remove),
> +};
> +
> +static int __init of_ram_init(void)
> +{
> + =A0 =A0 =A0 return of_register_platform_driver(&of_ram_driver);
> +}
> +module_init(of_ram_init);
> +
> +static void __exit of_ram_exit(void)
> +{
> + =A0 =A0 =A0 of_unregister_platform_driver(&of_ram_driver);
> +}
> +module_exit(of_ram_exit);
> +
> +MODULE_AUTHOR("Wolfram Sang");
> +MODULE_DESCRIPTION("OF-MTD-RAM map driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.6.2
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [OOPS] hugetlbfs tests with 2.6.30-rc8-git1
From: Sachin Sant @ 2009-06-05 15:48 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev
In-Reply-To: <20090605150429.GA29614@csn.ul.ie>
Mel Gorman wrote:
> That patch fixes a different problem. The assertion shouldn't have been
> made for hugetlbfs regions. I can only assume we are not triggering the
> same problem. According to your .config, DEBUG_VM is not even set so
> this is some other problem.
>
> Do you know what line triggered the problem? Eric Munson is currently
> investigating this as I'm chasing down another bug but my understanding is that
> right now he can't reproduce the problem. How reproducible is this for you?
I cannot recreate this consistently. Sometimes i am able to recreate ,
but it's random. I have
seen this problem on 2 out of 4 power boxes.
Here are last few lines from the hugetlbfs test run.
get_huge_pages (32): PASS
get_huge_pages (64): PASS
quota (32): PASS
quota (64): PASS
counters (32): PASS
counters (64): PASS
mmap-gettest 10 20 (32): PASS
mmap-gettest 10 20 (64): PASS
mmap-cow 19 20 (32): PASS
mmap-cow 19 20 (64): PASS
set shmmax limit to 335544320
shm-fork 10 10 (32): PASS
shm-fork 10 10 (64): PASS
shm-fork 10 20 (32):
shm-fork was executed when the oops occurred.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* SD card over (xilinx_)SPI, timeout error while CID
From: Joachim Foerster @ 2009-06-05 15:34 UTC (permalink / raw)
To: linuxppc-dev, john.linn, dbrownell; +Cc: lorenz, joachim
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 ?
Joachim
--
for reference: relevant DTS entry:
opb_spi_0: spi@41240000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "xlnx,opb-spi-1.00.e";
reg = <0x41240000 0x10000>;
interrupt-parent = <&opb_intc_0>;
interrupts = <7 2>;
xlnx,depth = <0x10>;
xlnx,dev-blk-id = <0x4>;
xlnx,dev-mir-enable = <0x0>;
xlnx,family = "virtex4";
xlnx,fifo-exist = <0x1>;
xlnx,interrupt-present = <0x1>;
xlnx,ip-reg-bar-offset = <0x60>;
xlnx,num-bits-reg = <0x8>;
xlnx,num-bits-sr = <0x8>;
xlnx,num-offchip-ss-bits = <0x0>;
xlnx,num-ss-bits = <0x1>;
xlnx,occupancy-num-bits = <0x4>;
xlnx,spi-slave-only = <0x0>;
mmc-slot@0 {
compatible = "mmc-spi-slot";
reg = <0>;
gpios = <&opb_gpio_1 0 1>;
voltage-ranges = <3300 3300>;
spi-max-frequency = <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=18
[ 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
^ permalink raw reply
* Re: [OOPS] hugetlbfs tests with 2.6.30-rc8-git1
From: Mel Gorman @ 2009-06-05 15:04 UTC (permalink / raw)
To: Sachin Sant; +Cc: linuxppc-dev
In-Reply-To: <4A290195.3080807@in.ibm.com>
On Fri, Jun 05, 2009 at 04:59:25PM +0530, Sachin Sant wrote:
> While executing Hugetlbfs tests against 2.6.30-rc8-git1 on a
> Power 6 box observed the following OOPS message.
>
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=1024 DEBUG_PAGEALLOC NUMA pSeries
> Modules linked in: ipv6 fuse loop dm_mod sg sd_mod crc_t10dif ibmvscsic
> scsi_transport_srp scsi_tgt scsi_mod
> NIP: c000000000038240 LR: c0000000000380f0 CTR: c00000000025d050
> REGS: c0000000fa8ff490 TRAP: 0300 Not tainted (2.6.30-rc8-git1-autotest)
> MSR: 8000000000009032 <EE,ME,IR,DR> CR: 44022422 XER: 00000001
> DAR: c000000084340480, DSISR: 0000000040000000
> TASK = c0000000facf40a0[10514] 'shm-fork' THREAD: c0000000fa8fc000 CPU: 2
> GPR00: 0000000000000000 c0000000fa8ff710 c000000000a9d900
> 0000000000000004 GPR04: 000003fff0000000 c000000084338480
> 0000168008000393 0000000000000001 GPR08: 0000000000000004
> c000000084348480 000000000003fff0 0000000000000350 GPR12:
> 0000000044022422 c000000000b72800 00000000ffffffff ffffffffffffffff
> GPR16: 000000004c8d6470 0000000000000000 ffffffffffff9010
> 0000000000000000 GPR20: 0000000000000000 0000040000000000
> c000000084338480 0000000000760000 GPR24: 0000000000000000
> 0000168008000393 c000000084379700 0000000000000004 GPR28:
> c000000000890430 0000000000000001 c000000000ff0430 f9c3d6fff0000000 NIP
> [c000000000038240] .hpte_need_flush+0x1bc/0x2d8
> LR [c0000000000380f0] .hpte_need_flush+0x6c/0x2d8
> Call Trace:
> [c0000000fa8ff710] [c000000000038264] .hpte_need_flush+0x1e0/0x2d8 (unreliable)
> [c0000000fa8ff7d0] [c000000000039fa4] .huge_ptep_get_and_clear+0x40/0x5c
> [c0000000fa8ff850] [c00000000012d46c] .__unmap_hugepage_range+0x178/0x2b8
> [c0000000fa8ff940] [c00000000012d600] .unmap_hugepage_range+0x54/0x88
> [c0000000fa8ff9e0] [c0000000001173a0] .unmap_vmas+0x178/0x8f4
> [c0000000fa8ffb30] [c00000000011cab8] .unmap_region+0xfc/0x1e4
> [c0000000fa8ffc00] [c00000000011e248] .do_munmap+0x2f4/0x38c
> [c0000000fa8ffcc0] [c0000000002f6d74] .SyS_shmdt+0xc0/0x188
> [c0000000fa8ffd70] [c00000000000c430] .sys_ipc+0x274/0x2fc
> [c0000000fa8ffe30] [c000000000008534] syscall_exit+0x0/0x40
> Instruction dump:
> 78090220 2fbd0000 409e0010 7929e0e4 7be00120 4800000c 792945c6 7be00600
> 7d3f0378 7c1cb82e 3d360001 2f800000 <eb898000> 409e0028 7fe3fb78 7f24cb78
>
> I first noticed this with 2.6.30-rc7-git3 on a power6 machine,
> but could not recreate again on the same machine. Now the problem
> has resurfaced again with 2.6.30-rc8 (and with git1 as well) on
> another Power6 box.
>
> I had seen similar failures(although the back trace was different,
> crash point was same) with older kernels and Mel submitted a patch
> to fix that issue. Here is the link to that patch.
>
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-May/071395.html
>
That patch fixes a different problem. The assertion shouldn't have been
made for hugetlbfs regions. I can only assume we are not triggering the
same problem. According to your .config, DEBUG_VM is not even set so
this is some other problem.
Do you know what line triggered the problem? Eric Munson is currently
investigating this as I'm chasing down another bug but my understanding is that
right now he can't reproduce the problem. How reproducible is this for you?
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* [PATCH] Add MSI interrupts to DTS of MPC8315E-RDB
From: leon.woestenberg @ 2009-06-05 14:45 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.
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>;
+ 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 related
* (no subject)
From: Leon Woestenberg @ 2009-06-05 14:31 UTC (permalink / raw)
To: linuxppc-dev, galak
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>;
+ 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 related
* [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver
From: Wolfram Sang @ 2009-06-05 12:05 UTC (permalink / raw)
To: linuxppc-dev
Cc: devicetree-discuss, albrecht.dress, linux-mtd, Ben Dooks,
David Woodhouse
In-Reply-To: <1244203514-12516-1-git-send-email-w.sang@pengutronix.de>
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.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Albrecht Dreß <albrecht.dress@arcor.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: linuxppc-dev@ozlabs.org
Cc: devicetree-discuss@ozlabs.org
Cc: linux-mtd@lists.infradead.org
---
Changes in V2:
- added binding documentation
- added __devinit & friends
- put struct resource on stack during probe
- simplified getting the name of the of-device
- made error path more readable & add check for valid bank-width-pointer
- rename driver to "of-mtd-ram"
Documentation/powerpc/dts-bindings/mtd-ram.txt | 18 ++++
drivers/mtd/maps/Kconfig | 7 ++
drivers/mtd/maps/Makefile | 1 +
drivers/mtd/maps/of-ram.c | 102 ++++++++++++++++++++++++
4 files changed, 128 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/mtd-ram.txt
create mode 100644 drivers/mtd/maps/of-ram.c
diff --git a/Documentation/powerpc/dts-bindings/mtd-ram.txt b/Documentation/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
+ used, if known, followed by "mtd-ram".
+ - reg : Address range of the RAM chip
+ - bank-width : Width (in bytes) of the RAM bank.
+
+Partitions are not yet supported.
+
+Example:
+
+ sram@2,0 {
+ compatible = "samsung,k6f1616u6a", "mtd-ram";
+ reg = <2 0 0x00200000>;
+ bank-width = <2>;
+ };
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index 82923bd..bdd9ebc 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -551,6 +551,13 @@ config MTD_PLATRAM
This selection automatically selects the map_ram driver.
+config MTD_OFRAM
+ tristate "Map driver for of-device RAM (of-mtd-ram)"
+ depends on MTD_PLATRAM && OF
+ help
+ Map driver for RAM areas described via the of-device
+ system.
+
config MTD_VMU
tristate "Map driver for Dreamcast VMU"
depends on MAPLE
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
index 2dbc1be..a7a2db3 100644
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_MTD_IXP2000) += ixp2000.o
obj-$(CONFIG_MTD_WRSBC8260) += wr_sbc82xx_flash.o
obj-$(CONFIG_MTD_DMV182) += dmv182.o
obj-$(CONFIG_MTD_PLATRAM) += plat-ram.o
+obj-$(CONFIG_MTD_OFRAM) += of-ram.o
obj-$(CONFIG_MTD_OMAP_NOR) += omap_nor.o
obj-$(CONFIG_MTD_INTEL_VR_NOR) += intel_vr_nor.o
obj-$(CONFIG_MTD_BFIN_ASYNC) += bfin-async-flash.o
diff --git a/drivers/mtd/maps/of-ram.c b/drivers/mtd/maps/of-ram.c
new file mode 100644
index 0000000..e2f4476
--- /dev/null
+++ b/drivers/mtd/maps/of-ram.c
@@ -0,0 +1,102 @@
+/*
+ * Generic of device based RAM map
+ *
+ * Copyright (C) 2009 Wolfram Sang, Pengutronix
+ *
+ * Using plat-ram.c by Ben Dooks
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/mtd/plat-ram.h>
+
+static __devinit int of_ram_probe(struct of_device *op,
+ const struct of_device_id *match)
+{
+ struct platdata_mtd_ram *pdata;
+ struct resource res;
+ const u32 *bankwidth;
+ int ret = -ENOENT;
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+ op->dev.platform_data = pdata;
+
+ ret = of_address_to_resource(op->node, 0, &res);
+ if (ret) {
+ dev_dbg(&op->dev, "could not create resource (%d)\n", ret);
+ goto out_free;
+ }
+
+ bankwidth = of_get_property(op->node, "bank-width", NULL);
+ if (!bankwidth || *bankwidth == 0) {
+ dev_dbg(&op->dev, "bank width not set\n");
+ goto out_free;
+ }
+ pdata->bankwidth = *bankwidth;
+
+ ret = __platram_probe(&op->dev, op->node->name, &res, pdata);
+ if (ret) {
+ dev_dbg(&op->dev, "error probing device (%d)\n", ret);
+ goto out_free;
+ }
+
+ return 0;
+
+out_free:
+ op->dev.platform_data = NULL;
+ kfree(pdata);
+ return ret;
+}
+
+static __devexit int of_ram_remove(struct of_device *op)
+{
+ int ret;
+ struct platdata_mtd_ram *pdata = op->dev.platform_data;
+
+ ret = __platram_remove(&op->dev);
+ op->dev.platform_data = NULL;
+ kfree(pdata);
+ return ret;
+}
+
+static const struct of_device_id __devinitconst of_ram_match[] = {
+ { .compatible = "mtd-ram", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_ram_match);
+
+static struct of_platform_driver of_ram_driver = {
+ .owner = THIS_MODULE,
+ .name = "of-mtd-ram",
+ .match_table = of_ram_match,
+ .probe = of_ram_probe,
+ .remove = __devexit_p(of_ram_remove),
+};
+
+static int __init of_ram_init(void)
+{
+ return of_register_platform_driver(&of_ram_driver);
+}
+module_init(of_ram_init);
+
+static void __exit of_ram_exit(void)
+{
+ of_unregister_platform_driver(&of_ram_driver);
+}
+module_exit(of_ram_exit);
+
+MODULE_AUTHOR("Wolfram Sang");
+MODULE_DESCRIPTION("OF-MTD-RAM map driver");
+MODULE_LICENSE("GPL v2");
--
1.6.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox