* Re: [PATCH] Fix loop logic in irq_alloc_virt()
From: Michael Ellerman @ 2006-08-02 4:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060802004852.C66FB67B7F@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]
On Wed, 2006-08-02 at 10:48 +1000, Michael Ellerman wrote:
> There's a bug in irq_alloc_virt() if it's asked for more than 1 interrupt,
> if it can't find a slot it might look past the end of the irq_map.
>
> I think this is a fix. No one in the kernel actually calls this with
> count > 1, so it's not critical.
> Index: to-merge/arch/powerpc/kernel/irq.c
> ===================================================================
> --- to-merge.orig/arch/powerpc/kernel/irq.c
> +++ to-merge/arch/powerpc/kernel/irq.c
> @@ -745,14 +744,16 @@ unsigned int irq_alloc_virt(struct irq_h
> /* Look for count consecutive numbers in the allocatable
> * (non-legacy) space
> */
> - for (i = NUM_ISA_INTERRUPTS; i <= limit; ) {
> - for (j = i; j < (i + count); j++)
> - if (irq_map[j].host != NULL) {
> - i = j + 1;
> - continue;
> - }
> - found = i;
> - break;
To be clear: the bug is that the continue affects the inner for loop,
not the outer one, so i becomes j + 1 and then we continue the inner
loop without checking if i is still <= limit.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] fix PMU initialization on pseries lpar
From: Michael Ellerman @ 2006-08-02 4:29 UTC (permalink / raw)
To: Sonny Rao; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060802042009.GA15567@kevlar.burdell.org>
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
On Wed, 2006-08-02 at 00:20 -0400, Sonny Rao wrote:
> We should not be calling power4_enable_pmcs() in
> pseries_lpar_enable_pmcs(); just doing the hypercall is sufficient.
> Prior to 2.6.15 we did not call power4_enable_pmcs() for an lpar.
>
> power4_enable_pmcs() tries to read the hid0 register which is no
> longer legal for an lpar in newer Power processors.
Argh, how did I miss that. Mea culpa.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Paul Mackerras @ 2006-08-02 4:53 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060719230014.GB3887@mag.az.mvista.com>
Mark A. Greer writes:
> Abstract the operations used in the bootwrapper. The operations
> have been divided up into platform ops (platform_ops), firware ops
> (fw_ops), device tree ops (dt_ops), and console ops (console_ops).
Overall the approach looks good.
The ops structure seems like a reasonable concept, but I question
whether we need to have platform_ops separate from fw_ops, since the
firmware is essentially part of the implementation of the platform.
Also I don't see why we need to do a double indirection to get to each
ops function.
Also, we will probably want to create some directory structure under
arch/powerpc/boot in the longer term.
> +#ifdef __powerpc64__
> +typedef unsigned long u64;
> +#else
> +typedef unsigned long long u64;
> +#endif
This is potentially confusing, because the __powerpc64__ relates to
the boot wrapper not the kernel, and we don't build a 64-bit boot
wrapper on any platform (not yet anyway). Maybe this needs a comment.
Paul.
^ permalink raw reply
* linux USB host problem
From: robinpv @ 2006-08-02 5:29 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am using linux 2.6.16.1 for MPC5200 based platorm. It has PCI based USB Host (SM501 chip)
I am facing problem in the USB host interrupts. When i plug in the USB i get the
below message.
new full speed USB device using vgxfb and address 2.
vgxfb 0000:00:10.0: Unlink after no-IRQ? Controller is probably using the
wrong IRQ.
the capture of /pci/interrupts is
CPU0
1: 0 MPC52xx Level ohci_hcd:usb1
7: 751 MPC52xx Level eth0
40: 7899 MPC52xx Level mpc52xx_psc_uart
BAD: 0
The device address is assigned but after that interrupt is not coming.
After that if i unplug and plugin there is no notification.
the sm501 chip in which USB host is there, is connected on PCI bus.
The PCI mapping is as follows
static char pci_irq_table[][4] =
/*
* PCI IDSEL/INTPIN->INTLINE
* A B C D
*/
{
{PIRQA, PIRQA, PIRQA, PIRQA}, /* SM501 */
{PIRQD, PIRQD, PIRQD, PIRQD}, /* IDE */
{PIRQC, PIRQC, PIRQC, PIRQC}, /* Ethernet */
{PIRQB, PIRQB, PIRQB, PIRQB}, /* Bridge */
};
const long min_idsel = 16, max_idsel = 18, irqs_per_slot = 4;
return PCI_IRQ_TABLE_LOOKUP;
I tried with acpi=off, but in vain.
Can some give inputs on this how to proceed.
Thanks & Regards,
Robin
^ permalink raw reply
* Re: [PATCH] turn on tigon3 support in maple_defconfig
From: Segher Boessenkool @ 2006-08-02 5:30 UTC (permalink / raw)
To: Amos Waterland; +Cc: linuxppc-dev
In-Reply-To: <20060801194411.GA22933@kvasir.watson.ibm.com>
> I think that most people who use maple_defconfig are doing so for a
> JS21,
> so it might make sense to turn Tigon3 support on by default.
Also needed on JS20.
> Built and booted on a JS21.
>
> Signed-off-by: Amos Waterland <apw@us.ibm.com>
ACK.
Segher
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Segher Boessenkool @ 2006-08-02 5:35 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, PaulMackerras
In-Reply-To: <1154474791.3987.7.camel@localhost.localdomain>
> I'm not sure what disable really needs to do, but I think drivers
> might
> expect it to set dev->irq back to the LSI value, even if we don't free
> anything internally. Not sure.
Yes, that's required by the MSI API.
Segher
^ permalink raw reply
* lockup during powersave on G3
From: marvin @ 2006-08-02 5:47 UTC (permalink / raw)
To: linuxppc-dev
hi,
since kernel 2.6.18-rc1 my b/w G3 mac locks up every time it goes into
powersave mode. Before trying to bisect, is there a candidate I can try to
revert?
marc
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Paul Mackerras @ 2006-08-02 6:15 UTC (permalink / raw)
To: Mark A. Greer, linuxppc-dev
In-Reply-To: <17616.12251.339657.215571@cargo.ozlabs.ibm.com>
I wrote:
> The ops structure seems like a reasonable concept, but I question
> whether we need to have platform_ops separate from fw_ops, since the
> firmware is essentially part of the implementation of the platform.
> Also I don't see why we need to do a double indirection to get to each
> ops function.
Thinking about this a bit more, why do we need the indirect function
calls at all? Do we ever want to be able to choose (e.g.) one of
several possible console implementations at runtime? Don't we know at
compile time which one we will be using, and thus can't we use the
linker to make the necessary linkages?
Regards,
Paul.
^ permalink raw reply
* 82xx PCI setup ioremapping twice
From: Kalle Pokki @ 2006-08-02 7:10 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
In pq2_find_bridges(), there is a call to setup_m8260_indirect_pci(),
which ioremaps the configuration address and data registers. The call
uses the cpm2_immr pointer, which however is already ioremapped by
cpm2_reset(). ioremapping these addresses twice seems to always crash
my board, and I need to e.g.
Index: linux-2.6.15.4/arch/ppc/syslib/m82xx_pci.c
===================================================================
--- linux-2.6.15.4.orig/arch/ppc/syslib/m82xx_pci.c 2006-08-02
09:45:54.000000000 +0300
+++ linux-2.6.15.4/arch/ppc/syslib/m82xx_pci.c 2006-08-02
09:46:32.000000000 +0300
@@ -324,7 +324,7 @@
hose->set_cfg_type = 1;
#endif
- setup_m8260_indirect_pci(hose,
+ setup_indirect_pci_nomap(hose,
(unsigned long)&cpm2_immr->im_pci.pci_cfg_addr,
(unsigned
long)&cpm2_immr->im_pci.pci_cfg_data);
or use the physical addresses in the original function call.
Should ioremap() code check for these double mappings? There seems to
be some attempts to do that. I remember the PCI initialisation wasn't
a problem some time before with an earlier kernel version, a different
8248 board, and internal memory at 0xf0000000.
My internal memory is at physical address 0xff000000.
Linux kernel version is 2.6.15.4.
The board is a custom 8247.
^ permalink raw reply
* SMP in 32-bit arch/powerpc
From: Adrian Cox @ 2006-08-02 8:25 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Is anybody else having problems with 32-bit SMP support in arch/powerpc?
I'm using 2.6.17 as my current base, because I've not yet merged the
latest mpic changes.
I'm currently bringing up a dual-7448 board, and when I build the kernel
with CONFIG_SMP, the bootmem allocator corrupts the device tree. The
strange thing is, this still happens when I don't start the second CPU.
Kernels built without CONFIG_SMP run flawlessly on the same hardware.
--
Adrian Cox <adrian@humboldt.co.uk>
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Michael Ellerman @ 2006-08-02 9:04 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, PaulMackerras
In-Reply-To: <1154379714.29826.396.camel@goblue>
[-- Attachment #1: Type: text/plain, Size: 3216 bytes --]
On Mon, 2006-07-31 at 16:01 -0500, Jake Moilanen wrote:
> Here's version 3 which addresses all of Michael's comments.
Sorry, more questions :)
> Index: 2.6-msi/drivers/pci/msi-rtas.c
> ===================================================================
> --- /dev/null
> +++ 2.6-msi/drivers/pci/msi-rtas.c
> @@ -0,0 +1,99 @@
> +/*
> + * Jake Moilanen <moilanen@austin.ibm.com>
> + * Copyright (C) 2006 IBM
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; version 2 of the
> + * License.
> + *
> + */
> +
> +#include <linux/pci.h>
> +#include <linux/irq.h>
> +#include <asm/rtas.h>
> +#include <asm/hw_irq.h>
> +#include <asm/ppc-pci.h>
> +
> +int rtas_enable_msi(struct pci_dev* pdev)
> +{
> + int seq_num = 1;
> + int i;
> + int rc;
> + int query_token = rtas_token("ibm,query-interrupt-source-number");
> + int ret[2];
> + int n_intr;
> + int last_virq = NO_IRQ;
> + int virq;
> + unsigned int addr;
> + unsigned long buid;
> + struct device_node * dn;
> +
> + dn = pci_device_to_OF_node(pdev);
> +
> + if (!of_find_property(dn, "ibm,req#msi", NULL))
> + return -ENOENT;
> +
> + buid = get_phb_buid(dn->parent);
> + addr = (pdev->bus->number << 16) | (pdev->devfn << 8);
> +
> + do {
> + rc = rtas_call(rtas_token("ibm,change-msi"), 6, 3, ret, addr,
> + buid >> 32, buid & 0xffffffff,
> + 0, 0, seq_num);
> +
> + seq_num = ret[1];
> + } while (rtas_busy_delay(rc));
> +
> + if (rc) {
> + printk(KERN_WARNING "error[%d]: getting the number of "
> + "MSI interrupts for %s\n", rc, dn->name);
> + return -EIO;
> + }
> +
> + /* Return if there's no MSI interrupts */
> + if (!ret[0])
> + return -ENOENT;
> +
> + n_intr = ret[0];
> +
> + for (i = 0; i < n_intr; i++) {
> + do {
> + rc = rtas_call(query_token, 4, 3, ret, addr,
> + buid >> 32, buid & 0xffffffff, i);
> + } while (rtas_busy_delay(rc));
> +
> + if (!rc) {
> + virq = irq_create_mapping(irq_find_host(dn), ret[0],
> + ret[1] ? IRQ_TYPE_EDGE_RISING :
> + IRQ_TYPE_LEVEL_LOW);
I'm only just starting to get benh's new irq code, but I think
irq_find_host(dn) isn't doing what we want here. It's probably harmless,
but AFAICT irq_find_host() is only meant to be called when you have the
node of the irq controller, not for an arbitrary dn. The doco's a bit
ambiguous:
* irq_find_host - Locates a host for a given device node
* @node: device-tree node of the interrupt controller
But looking at the implementation, it doesn't do a search up the tree or
anything, it just checks node against each host.
Also, since's benh's latest patch went in we'll have to split this into
two calls, I think we want:
virq = irq_create_mapping(NULL ???, ret[0]);
set_irq_type(virq, ret[1] ? IRQ_TYPE_EDGE_RISING : IRQ_TYPE_LEVEL_LOW);
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: SMP in 32-bit arch/powerpc
From: Michael Ellerman @ 2006-08-02 9:08 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154507145.24203.0.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]
On Wed, 2006-08-02 at 09:25 +0100, Adrian Cox wrote:
> Is anybody else having problems with 32-bit SMP support in arch/powerpc?
> I'm using 2.6.17 as my current base, because I've not yet merged the
> latest mpic changes.
>
> I'm currently bringing up a dual-7448 board, and when I build the kernel
> with CONFIG_SMP, the bootmem allocator corrupts the device tree. The
> strange thing is, this still happens when I don't start the second CPU.
> Kernels built without CONFIG_SMP run flawlessly on the same hardware.
Seems to be working OK here:
fuego:~# uname -a
Linux fuego 2.6.17 #1 SMP Mon Jul 3 12:10:43 EST 2006 ppc GNU/Linux
fuego:~# cat /proc/cpuinfo
processor : 0
cpu : 604r
clock : 332.000000MHz
revision : 49.2 (pvr 0009 3102)
bogomips : 82.68
processor : 1
cpu : 604r
clock : 332.000000MHz
revision : 49.2 (pvr 0009 3102)
bogomips : 82.68
processor : 2
cpu : 604r
clock : 332.000000MHz
revision : 49.2 (pvr 0009 3102)
bogomips : 82.68
processor : 3
cpu : 604r
clock : 332.000000MHz
revision : 49.2 (pvr 0009 3102)
bogomips : 82.68
total bogomips : 330.75
timebase : 41500582
platform : CHRP
machine : CHRP IBM,7025-F50
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: lockup during powersave on G3
From: Michael Ellerman @ 2006-08-02 9:21 UTC (permalink / raw)
To: marvin; +Cc: linuxppc-dev
In-Reply-To: <200608020747.50765.marvin24@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]
On Wed, 2006-08-02 at 07:47 +0200, marvin wrote:
> hi,
>
> since kernel 2.6.18-rc1 my b/w G3 mac locks up every time it goes into
> powersave mode. Before trying to bisect, is there a candidate I can try to
> revert?
By "since" do you mean 2.6.18-rc1 worked and it's broken since then, or
that something earlier worked and it's broken starting from 2.6.18-rc1?
Ben's new irq stuff might be a candidate, that was a pretty big change.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* RE: SMP in 32-bit arch/powerpc
From: Zhang Wei-r63237 @ 2006-08-02 9:27 UTC (permalink / raw)
To: Adrian Cox, linuxppc-dev
In-Reply-To: <1154507145.24203.0.camel@localhost.localdomain>
Do you have more detailed descriptions? Our MPC8641D(dual-7448 core CPU)
board works well.
Best Regards,
Zhang Wei=20
> -----Original Message-----
> From: linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.or
> g] On Behalf Of Adrian Cox
> Sent: Wednesday, August 02, 2006 4:26 PM
> To: linuxppc-dev@ozlabs.org
> Subject: SMP in 32-bit arch/powerpc
>=20
> Is anybody else having problems with 32-bit SMP support in=20
> arch/powerpc?
> I'm using 2.6.17 as my current base, because I've not yet merged the
> latest mpic changes.
>=20
> I'm currently bringing up a dual-7448 board, and when I build=20
> the kernel
> with CONFIG_SMP, the bootmem allocator corrupts the device tree. The
> strange thing is, this still happens when I don't start the=20
> second CPU.
> Kernels built without CONFIG_SMP run flawlessly on the same hardware.
>=20
> --=20
> Adrian Cox <adrian@humboldt.co.uk>
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: cool article
From: Ameet Patil @ 2006-08-02 10:15 UTC (permalink / raw)
To: edb; +Cc: linuxppc-embedded
In-Reply-To: <44CF89B5.7080906@datadesigncorp.net>
> Did you happen to get an Ethernet mac going on the virtex2 or
> virtex4 with the 2.6 kernel?
Nope! :-(
Rumour has it that Montavista is soon going to release the source for
2.6 kernel to run on Xilinx platforms.
-Ameet
Edward Bockhoefer wrote:
> Hello Ameet,
> I too am working on this type of project. I am trying to get the xilinx
> obp 10/100 mac driver into the 2.6.17.6 kernel. Unfortantly, I think I
> need some of the montavista sources not generated by the xilinx
> software, which only generates driver code for the 2.4 montavista
> kernel. Did you happen to get an Ethernet mac going on the virtex2 or
> virtex4 with the 2.6 kernel?
>
> Ed
>
> Ameet Patil wrote:
>
>> Thanks Ed! I did get a root fs up and running NOT using JFFS2 though.
>> I used ext2.
>>
>> cheers,
>> -Ameet
>>
>> Edward Bockhoefer wrote:
>>
>>> I found your post about the Virtex II part one at
>>> http://www.linux.get2knowmore.com. Thanks for the info. Did you
>>> happen to get a root fs up and running using jffs2?
>>>
>>> Best Regards,
>>> Ed
>>>
>>>
>>
>
>
>
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Arnd Bergmann @ 2006-08-02 12:41 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <17616.12251.339657.215571@cargo.ozlabs.ibm.com>
On Wednesday 02 August 2006 06:53, Paul Mackerras wrote:
> > +#ifdef __powerpc64__
> > +typedef unsigned long=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0u=
64;
> > +#else
> > +typedef unsigned long long=A0=A0=A0u64;
> > +#endif
>=20
> This is potentially confusing, because the __powerpc64__ relates to
> the boot wrapper not the kernel, and we don't build a 64-bit boot
> wrapper on any platform (not yet anyway). =A0Maybe this needs a comment.
>=20
Moreover, even if we ever build this on __powerpc64__, the=20
typedef unsigned long long u64 would still do the right thing.
It only ever becomes a problem when mixing with u64 the c99 uint64_t,
which is defined the other way.
Arnd <><
^ permalink raw reply
* Re: SMP in 32-bit arch/powerpc
From: Kumar Gala @ 2006-08-02 13:32 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154507145.24203.0.camel@localhost.localdomain>
On Aug 2, 2006, at 3:25 AM, Adrian Cox wrote:
> Is anybody else having problems with 32-bit SMP support in arch/
> powerpc?
> I'm using 2.6.17 as my current base, because I've not yet merged the
> latest mpic changes.
>
> I'm currently bringing up a dual-7448 board, and when I build the
> kernel
> with CONFIG_SMP, the bootmem allocator corrupts the device tree. The
> strange thing is, this still happens when I don't start the second
> CPU.
> Kernels built without CONFIG_SMP run flawlessly on the same hardware.
There are a few patches to prom.c that may help. I know I've run
into this on other 32-bit systems booting from u-boot. These patches
resolved my issue.
* [PATCH] powerpc: Auto reserve of device tree blob
* [POWERPC] Prevent duplicate lmb reservations for Device...
- kumar
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Kumar Gala @ 2006-08-02 13:35 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev@ozlabs.org, Guennadi Liakhovetski
In-Reply-To: <528646bc0608012020l11690cf7wbb7d93e6ba6eae90@mail.gmail.com>
On Aug 1, 2006, at 10:20 PM, Grant Likely wrote:
> On 8/1/06, Josh Boyer <jwboyer@jdub.homelinux.org> wrote:
>> On Tue, 2006-08-01 at 17:35 -0700, Mark A. Greer wrote:
>>> On Tue, Aug 01, 2006 at 04:01:33PM -0500, Matthew McClintock wrote:
>>>> On Tue, 2006-08-01 at 23:00 +0200, Guennadi Liakhovetski wrote:
>>>>>
>>>>> Mark A. Greer in his patch to port sandpoint to arch/powerpc put
>>>>> sandpoint.dts under arch/powerpc/boot/dts/sandpoint.dts
>>>>
>>>> I believe in his latest patches he removed this part. The device
>>>> trees
>>>> were not included at all and he left this point open for
>>>> discussion.
>>>
>>> That's correct.
>>>
>>> TBH, I think its wrong to keep them in the kernel source at all--
>>> yes,
>>> the same argument could be made for arch/powerpc/boot but that's
>>> been
>>> settled.
>>
>> Sorry, I have to disagree. We're talking about device tree _source_
>> files here. I believe they should be included in the kernel source.
>> Where that is, I don't have a particularly strong argument but they
>> should be included.
>
> I have to second that opinion. The device tree is absolutely integral
> with the rest of the code/drivers needed to support a board. I say
> there are stronger arguments for keeping the dts files in the kernel
> source than there are for the boot wrapper.
>
> powerpc/boot/dts makes a lot of sense to me.
I like this location and agree that having them in tree makes sense.
And putting them under boot isolates them from the kernel proper.
The reason I see to having them in tree is to ensure proper version
compatibility. This way there is no concern about which .dts version
will work with which kernel. In the future we can always pull them
out when things are more stable.
- kumar
^ permalink raw reply
* Help for USB host driver for MPC8xx
From: wei.li4 @ 2006-08-02 14:23 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
Dose anyone use USB host drivers for MPC875 with Linux 2.4.25? I just
found these notes from http://www.heeltoe.com/software/usb/usb.html,
but I have no idea about how to use it, any advice? Thanks.
Wei
^ permalink raw reply
* Re: SMP in 32-bit arch/powerpc
From: Jon Loeliger @ 2006-08-02 14:42 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154507145.24203.0.camel@localhost.localdomain>
So, like, the other day Adrian Cox mumbled:
> Is anybody else having problems with 32-bit SMP support in arch/powerpc?
> I'm using 2.6.17 as my current base, because I've not yet merged the
> latest mpic changes.
>
> I'm currently bringing up a dual-7448 board, and when I build the kernel
> with CONFIG_SMP, the bootmem allocator corrupts the device tree. The
> strange thing is, this still happens when I don't start the second CPU.
> Kernels built without CONFIG_SMP run flawlessly on the same hardware.
As a point of reference, the 32-bit 8641 HPCN seems to be working fine
with both CONFIG_SMP and the device tree mechanism in place. It was working
both before and after the IRQ changes.
Can you nail down any more specifics on how it is failing or where
the corruption happens?
jdl
^ permalink raw reply
* SPI spi_spcom[STR] freeze
From: GSM909 @ 2006-08-02 15:30 UTC (permalink / raw)
To: linuxppc-embedded
Hello
I have problem with SPI
When I want to start my SPI transfer by setting 0x80 to my spi_spcom register. 0x80 keeping in this register till I "READ" the SPMODE register. There is also no transfer or any clock on the pins.
Did anyone had an Idea what this can be ???
my system:
mpc8270
pm827 from mircosys
linux 2.6.14 with Xenomai 2.1.2
The kernel module with the spi run under the rtdm.
Thx for helping me.
Regards
Fred
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Sloooooowwww CFI Flash programming
From: Franca, Jose Filipe (ext) @ 2006-08-02 15:33 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
Hello all!
I'm using a linux-2.4.31 based kernel in our board and we are using a AM29LV040B flash device. Our problem is that flash programming is a rather slow process. The responsible is the file cfi_cmdset_0002.c. Is there any patch that fixes this problem and enables fast programming mode?
Thanks for reading (and many more if you reply),
Filipe França.
[-- Attachment #2: Type: text/html, Size: 1046 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Tom Rini @ 2006-08-02 16:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17616.17129.964122.125259@cargo.ozlabs.ibm.com>
On Wed, Aug 02, 2006 at 04:15:05PM +1000, Paul Mackerras wrote:
> I wrote:
>
> > The ops structure seems like a reasonable concept, but I question
> > whether we need to have platform_ops separate from fw_ops, since the
> > firmware is essentially part of the implementation of the platform.
> > Also I don't see why we need to do a double indirection to get to each
> > ops function.
>
> Thinking about this a bit more, why do we need the indirect function
> calls at all? Do we ever want to be able to choose (e.g.) one of
> several possible console implementations at runtime? Don't we know at
> compile time which one we will be using, and thus can't we use the
> linker to make the necessary linkages?
Right. I was thinking perhaps Mark did it this way so certain things
could be omitted (if ops->foo then ops->foo(bar, baz)) but that'd
better taken care of with weak functions and getting the right one at
compile time.
The only potential case, but I'm not even sure then that it is an issue,
is on platforms where it's either U-Boot or PIBS/DINK/whatever. But
even then, the only thing that should matter is 'Do we have a tree
passed in?'.
--
Tom Rini
^ permalink raw reply
* Re: [PATCH 3/6] bootwrapper: Add device tree ops for flattened device tree
From: Tom Rini @ 2006-08-02 16:10 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060719230544.GD3887@mag.az.mvista.com>
On Wed, Jul 19, 2006 at 04:05:44PM -0700, Mark A. Greer wrote:
> This patch adds the device tree operations (dt_ops) for a flattened
> device tree (fdt).
[snip]
> +/* Definitions used by the flattened device tree */
[snip]
...
> +struct fdt_bus {
> + u64 (*map)(u32 *addr, u32 *range, int na, int ns, int pna);
> + int (*translate)(u32 *addr, u64 offset, int na);
> +};
All of that should live in an fdt.h.
> +
> +static inline struct boot_param_header *
> +fdt_get_bph(void *dt_blob)
> +{
> + return (struct boot_param_header *)dt_blob;
> +}
Er, can't we just do this in the few places directly?
> + if (!(new_dtb_start = malloc(new_total_size))) {
> + printf("Can't alloc space for new fdt\n\r");
> + exit();
> + }
Wasn't there a panic("Message") or so, for bootwrapper stuff? If not,
maybe there should be..
--
Tom Rini
^ permalink raw reply
* Re: [PATCH 4/6] bootwrapper: Add non-OF serial console support
From: Tom Rini @ 2006-08-02 16:17 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060719231244.GE3887@mag.az.mvista.com>
On Wed, Jul 19, 2006 at 04:12:44PM -0700, Mark A. Greer wrote:
> This patch adds support for serial I/O to the bootwrapper.
>
> It is broken into 2 layers. The first layer is generic serial
> operations that calls uart-specific routines to do the actual I/O.
> The second layer contains support for a 16550 compatible uart.
>
> The division allows support for other serial devices to be easily
> added in the future (e.g., the Marvell MPSC and the Freescale CPM).
Why do we do this with indirection rather than weak defaults and then
real implementations? The only places I see that are data are:
> + ns16550_scd.base = NULL;
> + ns16550_scd.reg_shift = 0;
And I imagine that on platforms where these are real, we dig them out of
the tree and set them, in your scheme, so it'd just be an empty (return
0/NULL) weak function, or the dig in the tree function. Heck, it could
just always be a 'dig in the tree' function.
--
Tom Rini
^ 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