* Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
From: Gerhard Pircher @ 2008-03-03 19:51 UTC (permalink / raw)
To: benh; +Cc: airlied, linuxppc-dev, dri-devel, linux-kernel
In-Reply-To: <1204498569.15052.488.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Mon, 03 Mar 2008 09:56:09 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org, dri-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, airlied@linux.ie
> Betreff: Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
> Bah, I think I found the problem:
>
> +static inline void *drm_vmalloc_dma(unsigned long size)
> +{
> +#if defined(__powerpc__) && defined(CONFIG_NOT_COHERENT_CACHE)
> + return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM,
> + PAGE_KERNEL | _PAGE_NO_CACHE);
> +#else
> + return vmalloc_32(size);
> +#endif
> +}
> +
>
> Remove the GFP_HIGHMEM from the above. It looks like our cache
> flushing isn't going to work for highmem, it would need some
> kmap's for that.
Yes, it looks like this was the problem. No kernel oops anymore.
The machine locks up anyway (which is a well known hardware problem).
It doesn't lock up with CPPIOMode=true, but probably only because the
initialization of DRI fails with "BAD cp_mode (f0000000)!".
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* Re: [patch 6/6] PCI: consolidate several pcibios_enable_resources() implementations
From: Bjorn Helgaas @ 2008-03-03 19:10 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel, Russell King
In-Reply-To: <200803031045.07054.jbarnes@virtuousgeek.org>
On Monday 03 March 2008 11:45:06 am Jesse Barnes wrote:
> On Wednesday, February 27, 2008 4:04 pm Bjorn Helgaas wrote:
> >
> > Not-Yet-Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
>
> So you'd like to see the MIPS stuff cleaned up a bit more first before actual
> sign-off? Or just more testing?
I think it'd be *nice* if that MIPS stuff got cleaned up, but that's
way beyond my scope. I just want to address Kyle's comments and make
sure I don't screw up ARM and PARISC.
Bjorn
^ permalink raw reply
* Re: [PATCH 2/2 v2] [POWERPC] Ignore disabled serial ports
From: Josh Boyer @ 2008-03-03 19:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <20080303190925.GA6735@loki.buserror.net>
On Mon, 3 Mar 2008 13:09:25 -0600
Scott Wood <scottwood@freescale.com> wrote:
> On Sun, Mar 02, 2008 at 10:43:17PM -0600, Josh Boyer wrote:
> > On Mon, 3 Mar 2008 04:43:42 +0100
> > Arnd Bergmann <arnd@arndb.de> wrote:
> > > I wonder whether we should move the check for "used-by-rtas" into the
> > > of_device_is_available function. I understand that used-by-rtas is
> > > another way of expressing the idea that the kernel is not supposed to
> > > access the specific device. In this case, the device is physically
> > > present, but is not available to the OS.
> >
> > I'd rather not at the moment. My intention was to only look at the
> > status property for now. I'd like to avoid this function growing into
> > a huge switch statement for $random_firmware's way of flagging
> > something as "don't touch".
>
> Better that than having the "huge" list of tests in every driver...
Perhaps.
This isn't set in stone. I'd rather get what's in the patch in-tree
now and massage it as we go. Otherwise this bike shed will wind up
being rainbow colored yet totally useless because it's a never-ending
patch rework.
josh
^ permalink raw reply
* Re: [PATCH 2/2 v2] [POWERPC] Ignore disabled serial ports
From: Scott Wood @ 2008-03-03 19:09 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <20080302224317.15f259ca@zod.rchland.ibm.com>
On Sun, Mar 02, 2008 at 10:43:17PM -0600, Josh Boyer wrote:
> On Mon, 3 Mar 2008 04:43:42 +0100
> Arnd Bergmann <arnd@arndb.de> wrote:
> > I wonder whether we should move the check for "used-by-rtas" into the
> > of_device_is_available function. I understand that used-by-rtas is
> > another way of expressing the idea that the kernel is not supposed to
> > access the specific device. In this case, the device is physically
> > present, but is not available to the OS.
>
> I'd rather not at the moment. My intention was to only look at the
> status property for now. I'd like to avoid this function growing into
> a huge switch statement for $random_firmware's way of flagging
> something as "don't touch".
Better that than having the "huge" list of tests in every driver...
-Scott
^ permalink raw reply
* Re: [PATCH] add strncmp to PowerPC
From: Segher Boessenkool @ 2008-03-03 19:08 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, paulus, LKML, Steven Rostedt
In-Reply-To: <20080303095443.GB27105@iram.es>
>> Even if it was logically faster (which I still doubt) it's a hell of
>> a lot
>> of cache lines to waste.
Yeah, 1 on 64-bit and 3 on 32-bit, that's a terrible lot.</sarcasm>
> Indeed, but there are some corner cases that the C code handles. Like
> a length of 0 which may lead to infinite loop in the asm code.
>
> OTOH, I'm a bit surprised by the extsb instructions in the compiler
> generated
> code. We don't compile with -fsigned-char, do we? The clrldi
> instructions are also extremely stupid.
Those are both necessary to be equivalent to the C code, which uses
signed char explicitly. It is generally considered a Good Thing(tm)
for the compiler to generate assembler code equivalent to the C code,
even if the C code is wrong.
> Now that I think a bit more about it, I believe that the C version is
> incorrect
It is. It's a great entry for the IOCCC as well.
I just tested the following (can't guarantee it's correct, just a PoC):
int strncmp(const char *s1, const char *s2, unsigned long /*size_t*/
len)
{
while (len--) {
unsigned char c1, c2;
c1 = *s1++;
c2 = *s2++;
int cmp = c1 - c2;
if (cmp)
return cmp;
if (c1 == 0 || c2 == 0)
break;
}
return 0;
}
which generates (with GCC-4.2.3)
strncmp:
addi 5,5,1
mtctr 5
.L2:
bdz .L11
lbz 0,0(3)
addi 3,3,1
lbz 9,0(4)
addi 4,4,1
cmpwi 7,0,0
subf. 0,9,0
cmpwi 6,9,0
bne- 0,.L4
beq- 7,.L4
bne+ 6,.L2
.L4:
mr 3,0
blr
.L11:
li 0,0
mr 3,0
blr
which isn't horrid, although it does some weirdish things obviously.
Current GCC-4.4.0 generates
strncmp:
addi 5,5,1
mr 10,3
mtctr 5
li 11,0
bdz .L7
.p2align 4,,15
.L4:
lbzx 0,10,11
lbzx 9,4,11
addi 11,11,1
subf. 3,9,0
cmpwi 6,9,0
cmpwi 7,0,0
bnelr 0
beqlr 7
beqlr 6
bdnz .L4
.L7:
li 3,0
blr
which is about as good as it can get (well, it didn't realise you
only need to test one of c1, c2 for zero. Did I say this was just
proof-of-concept code?)
Segher
^ permalink raw reply
* Re: [patch 6/6] PCI: consolidate several pcibios_enable_resources() implementations
From: Jesse Barnes @ 2008-03-03 18:45 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-arm-kernel, Russell King, Bjorn Helgaas
In-Reply-To: <20080228001053.404893334@ldl.fc.hp.com>
On Wednesday, February 27, 2008 4:04 pm Bjorn Helgaas wrote:
> There are many implementations of pcibios_enable_resources() that differ
> in minor ways that look more like bugs than architectural differences.
>
> This patch consolidates most of them to use the version annotated below.
> This is the original x86 version, except that it uses the resource
> collision check from powerpc at (5):
Looks really good to me, definitely a step in the right direction.
> The mips/pmc-sierra implementation of pcibios_enable_resources() is
> cluttered with a bunch of titan stuff, so I can't immediately consolidate
> it with the others. So I made the generic version "weak" so pmc-sierra
> can override it.
>
> Not-Yet-Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
So you'd like to see the MIPS stuff cleaned up a bit more first before actual
sign-off? Or just more testing?
> 18 files changed, 43 insertions(+), 507 deletions(-)
Nice diffstat. :)
Jesse
^ permalink raw reply
* [PATCH][MTD][NOR]Add support for the SST 36VF3203 flash chip
From: Andrei Dolnikov @ 2008-03-03 18:01 UTC (permalink / raw)
To: linux-mtd; +Cc: linuxppc-dev
Add support for the SST 36VF3203 flash chip. It is used on Emerson KSI8560 board.
Signed-off-by: Andrei Dolnikov <adolnikov@ru.mvista.com>
---
jedec_probe.c | 13 +++++++++++++
1 files changed, 13 insertions(+)
diff --git a/drivers/mtd/chips/jedec_probe.c b/drivers/mtd/chips/jedec_probe.c
index 6405938..15e061b 100644
--- a/drivers/mtd/chips/jedec_probe.c
+++ b/drivers/mtd/chips/jedec_probe.c
@@ -160,6 +160,7 @@
#define SST49LF030A 0x001C
#define SST49LF040A 0x0051
#define SST49LF080A 0x005B
+#define SST36VF3203 0x7354
/* Toshiba */
#define TC58FVT160 0x00C2
@@ -1412,6 +1413,18 @@ static const struct amd_flash_info jedec_table[] = {
ERASEINFO(0x1000,256)
}
}, {
+ .mfr_id = MANUFACTURER_SST,
+ .dev_id = SST36VF3203,
+ .name = "SST 36VF3203",
+ .devtypes = CFI_DEVICETYPE_X16|CFI_DEVICETYPE_X8,
+ .uaddr = MTD_UADDR_0x0AAA_0x0555,
+ .dev_size = SIZE_4MiB,
+ .cmd_set = P_ID_AMD_STD,
+ .nr_regions = 1,
+ .regions = {
+ ERASEINFO(0x10000,64),
+ }
+ }, {
.mfr_id = MANUFACTURER_ST,
.dev_id = M29F800AB,
.name = "ST M29F800AB",
^ permalink raw reply related
* Re: [patch 5/6] PARISC: move PERR & SERR enables out of pcibios_enable_resources()
From: Jesse Barnes @ 2008-03-03 18:30 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-arm-kernel, Russell King, Bjorn Helgaas
In-Reply-To: <20080228173125.GA16270@colo.lackof.org>
On Thursday, February 28, 2008 9:31 am Grant Grundler wrote:
> In general, I'm wondering if the check for device class would be
> sufficient here to NOT enable PERR/SERR for graphics automatically.
> While disabling PERR was "the right thing" for older "mostly write"
> devices of the 1990's and early 2000, it might not be correct for
> current 3-D graphics devices which use host mem to buffer processed
> results. I'm thinking of Intel graphics controllers in particular
> but I don't know any details of how they actually work.
Well, in general chipset devices aren't required to support parity checking,
AIUI; Intel gfx devices don't bother (PERR enable is hardwired to 0).
> I'm also a bit concerned about this now becuase (IIRC) AGP didn't
> implement parity though it looked like PCI protocol. PCI-e certainly
> does but it's possible BIOS/Firmware disable parity generation
> on the host bridge when connected to a gfx device.
> We wouldn't want to enable parity checking on a PCI-e gfx device in this
> case and I hope someone (perhaps at Intel) could double check this.
I'd have to ping our BIOS folks to see if that's the case, but I doubt it. It
would be a bad idea to disable any PCIe error reporting (including legacy
error mapping) just because a gfx device was attached. Apparently the AMD
PCIe parts include PERR generation, so disabling upstream reporting at boot
time seems like it would be an outright bug; it should be left up to driver &
OS software.
Jesse
^ permalink raw reply
* Re: [patch 4/6] ARM: move bridge enable out of pcibios_enable_resources()
From: Jesse Barnes @ 2008-03-03 17:59 UTC (permalink / raw)
To: linux-pci
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-arm-kernel, Russell King, Bjorn Helgaas
In-Reply-To: <20080228001053.013269726@ldl.fc.hp.com>
On Wednesday, February 27, 2008 4:04 pm Bjorn Helgaas wrote:
> Move bridge enable from pcibios_enable_resources() to
> platform_pci_enable_device() so the former matches other
> architectures and can be shared.
I really like the direction of these patches. Getting PCI resources assigned
& devices setup correctly for new arches has always been a bit more trouble
than it should be...
>
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
>
> Index: work6/arch/arm/kernel/bios32.c
> ===================================================================
> --- work6.orig/arch/arm/kernel/bios32.c 2008-02-27 11:25:29.000000000 -0700
> +++ work6/arch/arm/kernel/bios32.c 2008-02-27 11:55:59.000000000 -0700
> @@ -683,15 +683,32 @@
> cmd |= PCI_COMMAND_MEMORY;
> }
>
> + if (cmd != old_cmd) {
> + printk("PCI: enabling device %s (%04x -> %04x)\n",
> + pci_name(dev), old_cmd, cmd);
Probably worth giving this printk a prefix at some point (doesn't matter for
this patchset though since you're just moving it around).
Rest of it looks good.
Jesse
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Scott Wood @ 2008-03-03 17:07 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080303144727.GA27949@ingate.macqel>
On Mon, Mar 03, 2008 at 03:47:27PM +0100, Philippe De Muyter wrote:
> My root device is on a compact-flash connected to a PCI yenta chip from TI,
> and this one is not working, altough it seems to be discovered :
>
> Yenta: CardBus bridge found at 0000:00:12.0 [0000:0000]
> Yenta: Using CSCINT to route CSC interrupts to PCI
> Yenta: Routing CardBus interrupts to PCI
> Yenta TI: socket 0000:00:12.0, mfunc 0x00001b22, devctl 0x64
> irq 18: nobody cared (try booting with the "irqpoll" option)
> Call Trace:
> [cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable)
> [cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc
> [cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc
> [cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8
Maybe your PCI interrupt-map is wrong...
-Scott
^ permalink raw reply
* [PATCH] fix QE firmware uploading limit
From: Timur Tabi @ 2008-03-03 17:11 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: Timur Tabi
Fix a typo in qe_upload_firmware() that prevented uploading firmware on
systems with more than one RISC core.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch is for 2.6.25.
arch/powerpc/sysdev/qe_lib/qe.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 6efbd5e..f963fbf 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -509,7 +509,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
}
/* Validate some of the fields */
- if ((firmware->count < 1) || (firmware->count >= MAX_QE_RISC)) {
+ if ((firmware->count < 1) || (firmware->count > MAX_QE_RISC)) {
printk(KERN_ERR "qe-firmware: invalid data\n");
return -EINVAL;
}
--
1.5.4
^ permalink raw reply related
* Re: compile quirk linux-2.6.24 (with workaround)
From: Bernhard Reiter @ 2008-03-03 17:26 UTC (permalink / raw)
To: debian-powerpc; +Cc: linuxppc-dev, paulus
In-Reply-To: <200802251256.41037.bernhard@intevation.de>
[-- Attachment #1.1: Type: text/plain, Size: 1338 bytes --]
On Monday 25 February 2008 12:56, Bernhard Reiter wrote:
> On Friday 22 February 2008 15:50, Bernhard Reiter wrote:
> > > Ok, so it seems -mcpu=440 was added in gcc 3.4. The -mcpu=405 option
> > > has been around since 2001. Seeing as how there really isn't anything
> > > 440 specific in the files effected, we should be able to pass -mcpu=405
> > > for everything and have it still work.
> > >
> > > Bernhard, can you try the patch below?
> >
> > I will test it in the next days.
>
> Done. Looks good.
> (I did _not_ do a full rebuild and installation, only a build test.
> I will do a full blown test with 2.6.24.3.)
Worked fine for me with the attached patch.
Thanks again.
> Note: Your original did not fully apply, I think it had lines like
> -$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=440
> -$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=440
> which I did not have in my 2.6.24.
> Probably because you've used a git version of linux.
> What I did was to change the similiar occurances from 440 to 405.
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
[-- Attachment #1.2: linux-2.4.24-fix-ppcbuild-josh-boyer2.diff --]
[-- Type: text/x-diff, Size: 506 bytes --]
--- linux-2.6.24.3/arch/powerpc/boot/Makefile.org 2008-02-26 22:48:00.709872603 +0100
+++ linux-2.6.24.3/arch/powerpc/boot/Makefile 2008-02-26 22:48:17.509876780 +0100
@@ -35,8 +35,8 @@
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
-$(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
-$(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
+$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
+$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
$(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405
zlib := inffast.c inflate.c inftrees.c
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: I2S driver
From: Phillip Lougher @ 2008-03-03 17:14 UTC (permalink / raw)
To: Angelo; +Cc: Linuxppc-embedded
In-Reply-To: <157246.48338.qm@web23111.mail.ird.yahoo.com>
On Mon, Mar 3, 2008 at 5:05 PM, Angelo <s104259@yahoo.it> wrote:
> in my kernel version (2.6.22) there isn't any folder named
> fsl in sound/soc/
>
> So where i can found it?
>
Get the development git tree, available at:
git://opensource.wolfsonmicro.com/linux-2.6-asoc
http://opensource.wolfsonmicro.com/node/6 gives more info on the
development trees.
Phillip
> thanks for help.
>
>
>
>
>
> ________________________________
> ________________________________
>
> L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* I2S driver
From: Angelo @ 2008-03-03 17:05 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 400 bytes --]
Timur wrote:
>I wrote an ASoC driver for the MPC8610, which also has
>an I2S interface. You can find it in sound/soc/fsl.
in my kernel version (2.6.22) there isn't any folder named
fsl in sound/soc/
So where i can found it?
thanks for help.
---------------------------------
---------------------------------
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail
[-- Attachment #2: Type: text/html, Size: 597 bytes --]
^ permalink raw reply
* Re: I2S driver
From: Timur Tabi @ 2008-03-03 16:42 UTC (permalink / raw)
To: Angelo; +Cc: linuxppc-embedded
In-Reply-To: <529490.33431.qm@web23110.mail.ird.yahoo.com>
Angelo wrote:
> Hi my name is Angelo.
>
> I'm working on I2S driver, on MPC5200b board.
> Does anyone tell me where i can found some information on HOW to write it?
I wrote an ASoC driver for the MPC8610, which also has an I2S interface. You
can find it in sound/soc/fsl.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Grant Likely @ 2008-03-03 15:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel
In-Reply-To: <18379.58317.223229.950553@cargo.ozlabs.ibm.com>
Paul, can you please pick up this one too?
http://patchwork.ozlabs.org/linuxppc/patch?id=16965
Thanks,
g.
On Mon, Mar 3, 2008 at 4:41 AM, Paul Mackerras <paulus@samba.org> wrote:
> Linus,
>
> Please do:
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
>
> to get a collection of bug-fixes for powerpc, for the Cell, 4xx and
> 52xx platforms.
>
> Thanks,
> Paul.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/2] firewire: endianess fix
From: Stefan Richter @ 2008-03-03 14:35 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Kristian Hoegsberg, linux-kernel, linuxppc-dev, sparclinux,
Jarod Wilson, linux1394-devel, Sam Ravnborg, Harvey Harrison
In-Reply-To: <20080303091927.GA27105@iram.es>
Gabriel Paubert wrote:
> I have a Pismo which I use on a virtually
> daily basis (and about to remove the last remnants of MacOS on it).
> However I have disabled Firewire because it would not sleep and wake
> up properly.
>
> I can test it on Wednesday with a 5GB fireflly disk from 2001.
>
> Please tell me which configuration options I need to set for
> Firewire (which stack, etc...).
Config options of the new stack:
FIREWIRE=m
FIREWIRE_OHCI=m
FIREWIRE_SBP2=m
Config options of the old stack:
IEEE1394=m
IEEE1394_OHCI1394=m
IEEE1394_SBP2=m
and if desired also the other drivers for raw userspace access,
isochronous I/O (alias video1394 even though it can also be used for
other purposes), DV I/O, and IPv4 over 1394.
The two SBP2 drivers also need SCSI and BLK_DEV_SD a.k.a. SCSI disk
support or/and BLK_DEV_SR a.k.a. SCSI CDROM support.
You can also set the options to Y but I find loadable and hence
unloadable modules more practical... 'cause I unload and reload them all
the time. :-)
Regarding which of the two stacks to build: If you are going to test
FireWire with a storage device only, then you can choose either stack.
Caveats:
- You could build and install both stacks but should then blacklist
at least one of ohci1394 or firewire-ohci. Better keep it simple
and install only one of the stacks at a time.
- We still have a serious use-after-free bug in the new stack. This
may lead to kernel panic if the kernel was build with (slab? or
page allocation?) debugging enabled.
Users of IP over 1394 and pro/semipro audio still need the old stack.
Users of video should stick with the stack which their distribution has
enabled because our support in the lowlevel libraries libraw1394 and
libdc1394 to switch between the stacks is not quite comfortable yet.
Suspend (to RAM) and resume worked for me [TM] when I last tested them
with each stack. I tested i586/APM, x86-64/ACPI, and last weekend ppc32
on 1st generation PowerBook G4. I haven't tested hibernate (to disk)
and restore yet.
For successful resume on the Pismo with the new stack, you will most
certainly need the brand new patches which add PPC_PMAC platform support
to firewire-ohci. From what I saw with the PowerBook, you will also
need the UniNorth rev1 related patch. I wasn't able to fully test that
patch though because the electrical interface of my PowerBook's onboard
FireWire is dead. You can get the patches from kernel.org's
linux1394-2.6.git (master branch, close to Linus's latest linux-2.6.git)
or http://me.in-berlin.de/~s5r6/linux1394/updates/ (for a few kernel.org
kernels).
The old stack as found in any remotely recent 2.6 kernel should be OK
out of the box without patches... in theory. I wouldn't be surprised of
until now unreported bugs or old reported but forgotten bugs though.
--
Stefan Richter
-=====-==--- --== ---==
http://arcgraph.de/sr/
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Grant Likely @ 2008-03-03 14:54 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080303144727.GA27949@ingate.macqel>
On Mon, Mar 3, 2008 at 7:47 AM, Philippe De Muyter <phdm@macqel.be> wrote:
> My root device is on a compact-flash connected to a PCI yenta chip from TI,
> and this one is not working, altough it seems to be discovered :
>
> Yenta: CardBus bridge found at 0000:00:12.0 [0000:0000]
> Yenta: Using CSCINT to route CSC interrupts to PCI
> Yenta: Routing CardBus interrupts to PCI
> Yenta TI: socket 0000:00:12.0, mfunc 0x00001b22, devctl 0x64
> irq 18: nobody cared (try booting with the "irqpoll" option)
> Call Trace:
> [cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable)
> [cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc
> [cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc
> [cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8
>
> but my boot finally fails with :
>
> VFS: Cannot open root device "hda1" or unknown-block(0,0)
> Please append a correct "root=" boot option; here are the
> available partitions:
> 1f00 8192 mtdblock0 (driver?)
> Kernel panic - not syncing: VFS: Unable to mount root fs
> on unknown-block(0,0)
>
> Is there an easy way to use values found in /proc or even in the sources
> in my working ppc setup to put them in the dts file to make my new powerpc
> configuration work ?
It does not look like you are having dts problems. Once your in the
PCI domain, Linux will probe the devices (as your boot log shows).
Rather, your boot failure is due to the yenta device failure.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: Philippe De Muyter @ 2008-03-03 14:47 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I have a currently almost working ARCH=ppc linux-2.6.24 configuration for a
new mpc8540 board (except for a RTC chip connected to an i2c bus).
Knowing that ARCH=ppc will be removed, I try to make the ARCH=powerpc version
work, but that's not easy.
I have copied the mpc8540ads.dts file to a new dts file, and added the
following :
i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
device_type = "i2c";
compatible = "fsl-i2c";
reg = <3000 100>;
interrupts = <2b 2>;
interrupt-parent = <&mpic>;
dfsrr;
+
+ rtc@68 {
+ compatible = "stm,m41t81";
+ reg = <68>;
+ };
};
and I see in the boot log that my RTC chip is now working.
My root device is on a compact-flash connected to a PCI yenta chip from TI,
and this one is not working, altough it seems to be discovered :
Yenta: CardBus bridge found at 0000:00:12.0 [0000:0000]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:00:12.0, mfunc 0x00001b22, devctl 0x64
irq 18: nobody cared (try booting with the "irqpoll" option)
Call Trace:
[cf813af0] [c00066c8] show_stack+0x3c/0x1bc (unreliable)
[cf813b30] [c003c1ac] __report_bad_irq+0x38/0xcc
[cf813b50] [c003c4c8] note_interrupt+0x288/0x2cc
[cf813b80] [c003cc34] handle_fasteoi_irq+0x94/0xf8
but my boot finally fails with :
VFS: Cannot open root device "hda1" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the
available partitions:
1f00 8192 mtdblock0 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs
on unknown-block(0,0)
Is there an easy way to use values found in /proc or even in the sources
in my working ppc setup to put them in the dts file to make my new powerpc
configuration work ?
Thanks for listening
Philippe
^ permalink raw reply
* Re: I2S driver
From: Mark Brown @ 2008-03-03 13:47 UTC (permalink / raw)
To: Roman Fietze; +Cc: linuxppc-embedded
In-Reply-To: <200803031340.36665.roman.fietze@telemotive.de>
On Mon, Mar 03, 2008 at 01:40:36PM +0100, Roman Fietze wrote:
> On Monday 03 March 2008 13:08:43 Angelo wrote:
> > I'm working on I2S driver, on MPC5200b board.
> An ALSA sound driver?
> If yes, there are many places where you can find documentation. If
> not, there are still many places where you can find documentation.
> Could you please specify more precisely what you want to do or where
> you are having problems.
If you are working on an audio device in an embedded system you probably
want to use the ALSA SoC subsystem - have a look at
Documentation/sound/alsa/soc and sound/soc for information. There is a
development git tree for this availiable at:
git://opensource.wolfsonmicro.com/linux-2.6-asoc
^ permalink raw reply
* The problem about the GETH speed on MPC8360?
From: 郭劲 @ 2008-03-03 13:21 UTC (permalink / raw)
To: support.asia, b09033, linuxppc-embedded
Hi,freescale,
I used the linux-2.6.11 version. I designed the MPC8360 system with 1GB DDR-1
memory and the GMII 1 to interface the 88E1111(RJ45) and GMII 2 to interface the
BCM5387 switch chip(SFP). Now we do the internet test for those GETH. We connect
those RJ45 or SFP to server PC.We used "iperf" test software to test them.
Follow is the test result:
UDP protocol:
Server PC send 1GB data to MPC8360, the speed is about 300Mbps, MPC8360 CPU
used 100%;
MPC8360 send 1GB data to Server PC, the speed is about 600Mbps,MPC8360 CPU
used 100%;
Server PC send 100MB data to MPC8360, and MPC8360 send 100MB to server PC at
the same time, both send and receiver of MPC8360 is 100Mbps. MPC8360 CPU used
100%;
TCP protocol:
Server PC send 1GB data to MPC8360, the speed is about 250Mbps, MPC8360 CPU
used 100%;
MPC8360 send 1GB data to Server PC, the speed is about 6Mbps,MPC8360 CPU
used 20%;
The problem is why the speed is so slow and the cpu used so little during the
last TCP test? The Gigebyte internet is only 6M bit per sencond, it's too slow.
Could you help me to test the MPC8360EMDS board and send me the test report?
Could you tell me why the GETH on MPC8360 is so poor? Even the UDP protocol
just only realize the 100Mbps with the send and receive at the same time on
MPC8360. It just like the 100M internet, not 1000M internet.
Could you tell me why the TCP protocol is much slower then UTP procotol?
We need up to about 900Mbps TCP protocol both on send and receive at the same
time.
^ permalink raw reply
* i2s driver
From: Angelo @ 2008-03-03 13:18 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]
Thanks for answer.
>I can also send you some GPL'd code that works.
>It is extremely bad commented (:-p) and probably not useful
> (it's not an ALSA driver itself, but it uses the DMA to
> copy data to the PSC - I2S mode) but it works.
It is a great idea; i can use it to start.
You can send it via mail..
> But this code is based on 2.6.16 kernel.
I'm using 2.6.22 kernel version.
I just enabled in lite5200b.dts:
//PSC3 in CODEC mode example //asimmini
i2s@2400 { // PSC3
device_type = "sound";
compatible = "mpc5200b-psc-i2s";//not 5200 compatible
cell-index = <2>;
reg = <2400 100>;
interrupts = <2 3 0>;
interrupt-parent = <&mpc5200_pic>;
};
..and added in lite5200.c, in function mpc52xx_psc_functions
...
struct mpc52xx_psc_func mpc52xx_psc_functions[]= {
{ .id = 2,
.func = "i2s",
},
...
thanks for help.
---------------------------------
---------------------------------
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail
[-- Attachment #2: Type: text/html, Size: 1567 bytes --]
^ permalink raw reply
* RE: I2S driver
From: Pedro Luis D. L. @ 2008-03-03 13:05 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <529490.33431.qm@web23110.mail.ird.yahoo.com>
Angelo wrote:
=20
> Hi my name is Angelo.
>=20
> I'm working on I2S driver, on MPC5200b board.
> Does anyone tell me where i can found some information on HOW to write it=
?
>=20
> Thanks for help.
>=20
Hello Angelo,
depends on which kernel version are you using. You can find some working co=
de in DENX repository:
http://source.denx.net/cgi-bin/gitweb.cgi
=20
I can also send you some GPL'd code that works. It is extremely bad comment=
ed (:-p) and probably not useful (it's not an ALSA driver itself, but it us=
es the DMA to copy data to the PSC - I2S mode) but it works. But this code =
is based on 2.6.16 kernel.
Tell me the version and I would guide you a little bit.
=20
Regards,
Pedro.
_________________________________________________________________
MSN Video.=20
http://video.msn.com/?mkt=3Des-es=
^ permalink raw reply
* [PATCH] ehea: Fix missing Kconfig dependency
From: Thomas Klein @ 2008-03-03 12:52 UTC (permalink / raw)
To: Jeff Garzik
Cc: Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Stefan Roscher
Fixed Kconfig: ehea driver requires sparse mem
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
diff -Nurp linux-2.6.25-rc3.org/drivers/net/Kconfig linux-2.6.25-rc3/drivers/net/Kconfig
--- linux-2.6.25-rc3.org/drivers/net/Kconfig 2008-02-24 22:25:54.000000000 +0100
+++ linux-2.6.25-rc3/drivers/net/Kconfig 2008-03-03 13:36:48.000000000 +0100
@@ -2513,7 +2513,7 @@ config CHELSIO_T3
config EHEA
tristate "eHEA Ethernet support"
- depends on IBMEBUS && INET
+ depends on IBMEBUS && INET && SPARSEMEM
select INET_LRO
---help---
This driver supports the IBM pSeries eHEA ethernet adapter.
^ permalink raw reply
* Re: I2S driver
From: Roman Fietze @ 2008-03-03 12:40 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <529490.33431.qm@web23110.mail.ird.yahoo.com>
Hello Ngelo,
On Monday 03 March 2008 13:08:43 Angelo wrote:
> I'm working on I2S driver, on MPC5200b board.
An ALSA sound driver?
If yes, there are many places where you can find documentation. If
not, there are still many places where you can find documentation.
Could you please specify more precisely what you want to do or where
you are having problems.
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
^ 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