* Re: [PATCH] powerpc: Fix IO space on PCI busses created from of_platform
From: Michael Neuling @ 2007-05-15 6:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Olof Johansson, linuxppc-dev, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20070515062007.5A4B8DDEC4@ozlabs.org>
> - /* Setup IO space.
> - * This will not work properly for ISA IOs, something needs to be done
> - * about it if we ever generalize that way of probing PCI brigdes
> + /* Setup IO space. We use the non-dynamic version of that code here,
> + * which doesn't quite support unplugging. Next kernel release will
> + * have a better fix for this.
> + * Note also that we don't do ISA, this will also be fixed with a
> + * more massive rework.
> */
Do you want to put some absolute kernel version numbers here (rather
than "next kernel release") so that someone reading this won't have to
look through the changelog to work out if this is an old bogus comment,
or something that is actively being hacked on?
Mikey
^ permalink raw reply
* Re: Small fixes for the Ebony device tree
From: David Gibson @ 2007-05-15 6:34 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Stefan Roese, Paul Mackerras
In-Reply-To: <1950a79f97480ba96f1b00352ec449a5@kernel.crashing.org>
On Tue, May 15, 2007 at 08:28:09AM +0200, Segher Boessenkool wrote:
> > Anyone have any objection to the following: each of these controllers
> > should have compatible properties listing 3 string, first, a specific
> > version for the CPU in question (e.g "ibm,sdram-440gp"), then a string
> > based on the type as listed below, finally "ibm,sdram-4xx".
>
> Is that last entry ever useful? Do all those controllers
> have something in common?
A quick glance over the descriptions in the 440GP and 405GP user
manuals suggests that they have most of the registers in common,
though I haven't checked to see if the semantics of those registers
are actually all the same.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] [POWERPC] remove build warnings in windfarm_core
From: Segher Boessenkool @ 2007-05-15 6:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev, Stephen Rothwell
In-Reply-To: <17993.20745.432703.238649@cargo.ozlabs.ibm.com>
>> - device_create_file(&wf_platform_device.dev, &new_ct->attr);
>> + ret = device_create_file(&wf_platform_device.dev, &new_ct->attr);
>> + if (ret) {
>> + list_del(&new_ct->link);
>> + printk(KERN_WARNING "windfarm: device_creat_file failed"
>> + "for %s\n", new_ct->name);
>> + goto out_unlock;
>
> This shows up why I hate the must_check stuff. The sysfs files are
> not essential for the operation of the windfarm subsystem.
They are essential for the user expectations of the
subsystem though; if registration fails, a warning
should be printed.
> If the
> sysfs registration fails for any reason, we now have a completely
> non-functional windfarm subsystem instead of a mostly-working one. :(
Yeah, but that's not must_check's fault, it doesn't
say *what* to do with the error code :-)
Segher
^ permalink raw reply
* Re: Small fixes for the Ebony device tree
From: Segher Boessenkool @ 2007-05-15 6:28 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Stefan Roese, Paul Mackerras
In-Reply-To: <20070515061855.GD6998@localhost.localdomain>
> Anyone have any objection to the following: each of these controllers
> should have compatible properties listing 3 string, first, a specific
> version for the CPU in question (e.g "ibm,sdram-440gp"), then a string
> based on the type as listed below, finally "ibm,sdram-4xx".
Is that last entry ever useful? Do all those controllers
have something in common?
>> SDRAM: all 40x (except for 405EZ)
> ibm,sdram-40x
>
>> DDR: 440GP, 440GX, 440EP, 440GR
> ibm,sdram-44x-ddr
>
>> DDR2: 440SP, 440SPe
> ibm,sdram-44x-ddr2
>
>> DDR2 (Denali): 440EPx, 440GRx
> ibm,sdram-44x-ddr2denali
Is this one a superset of the previous one? If so,
put both names in.
> Seem reasonable?
It's better to say 440 than 44x, maybe all "441" parts
will be totally different. I don't know what to do
with 40x; maybe say 405 as that seems to be the most
common chip. OTOH, you don't have to deal with that
right now :-)
Segher
^ permalink raw reply
* Re: [patch 4/4] powerpc 2.6.21-rt1: reduce scheduling latency by changing tlb flush size
From: Tsutomu OWA @ 2007-05-15 6:27 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Thomas Gleixner, mingo, linux-kernel
In-Reply-To: <200705141640.02561.arnd@arndb.de>
At Mon, 14 May 2007 16:40:02 +0200, Arnd Bergmann wrote:
> > +#if defined(CONFIG_PPC_CELLEB) && defined(CONFIG_PREEMPT_RT)
> > +/* Since tlb flush takes long time on Celleb, reduce it to 1 when Celleb && RT */
> > +#define PPC64_TLB_BATCH_NR 1
> With this code, you get silent side-effects of enabling PPC_CELLEB
> along with another platform.
> Maybe instead you should change the hpte_need_flush() to always flush
> when running on the celleb platform and PREEMPT_RT is enabled.
OK, how about this one?
thanks a lot!
Since flushing tlb needs expensive hypervisor call(s) on celleb,
always flush it on RT to reduce scheduling latency.
Signed-off-by: Tsutomu OWA <tsutomu.owa@toshiba.co.jp>
-- owa
--- linux-2.6.21-rt1/arch/powerpc/mm/tlb_64.c 2007-05-07 14:08:12.000000000 +0900
+++ rt/arch/powerpc/mm/tlb_64.c 2007-05-15 15:19:34.000000000 +0900
@@ -31,6 +31,7 @@
#include <asm/tlbflush.h>
#include <asm/tlb.h>
#include <asm/bug.h>
+#include <asm/machdep.h>
DEFINE_PER_CPU(struct ppc64_tlb_batch, ppc64_tlb_batch);
@@ -180,6 +181,18 @@ void hpte_update(struct mm_struct *mm, u
batch->vaddr[i] = (vsid << 28 ) | (addr & 0x0fffffff);
batch->pte[i] = __real_pte(__pte(pte), ptep);
batch->index = ++i;
+
+#ifdef CONFIG_PREEMPT_RT
+ /*
+ * Since flushing tlb needs expensive hypervisor call(s) on celleb,
+ * always flush it on RT to reduce scheduling latency.
+ */
+ if (machine_is(celleb)) {
+ flush_tlb_pending();
+ return;
+ }
+#endif /* CONFIG_PREEMPT_RT */
+
if (i >= PPC64_TLB_BATCH_NR)
flush_tlb_pending();
}
^ permalink raw reply
* Re: [PATCH] [POWERPC] remove build warnings in windfarm_core
From: Paul Mackerras @ 2007-05-15 6:19 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20070514163219.9d78cde0.sfr@canb.auug.org.au>
Stephen Rothwell writes:
> - device_create_file(&wf_platform_device.dev, &new_ct->attr);
> + ret = device_create_file(&wf_platform_device.dev, &new_ct->attr);
> + if (ret) {
> + list_del(&new_ct->link);
> + printk(KERN_WARNING "windfarm: device_creat_file failed"
> + "for %s\n", new_ct->name);
> + goto out_unlock;
This shows up why I hate the must_check stuff. The sysfs files are
not essential for the operation of the windfarm subsystem. If the
sysfs registration fails for any reason, we now have a completely
non-functional windfarm subsystem instead of a mostly-working one. :(
Paul.
^ permalink raw reply
* [PATCH] powerpc: Fix IO space on PCI busses created from of_platform
From: Benjamin Herrenschmidt @ 2007-05-15 6:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Olof Johansson, linuxppc-dev, Arnd Bergmann
This changes the way of_platform_pci creates PCI host bridges such
that it uses request_phb_iospace() for mapping the IO ports, instead
of using the dynamic hotplug stuff. That guarantees the IO space
stays within the 2GB limit and thus doesn't break half of the legacy
drivers around.
Fixes a couple of warnings due to missing IO space while at it.
This patch is a temporary workaround for 2.6.22 before a more complete
rewrite of IO mappings is merged in 2.6.23
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This version renames pci_initial_scan to pci_initial_scan_done as
per Olof comment.
arch/powerpc/kernel/of_platform.c | 10 ++++++----
arch/powerpc/kernel/pci_64.c | 23 ++++++++++++++++++++++-
2 files changed, 28 insertions(+), 5 deletions(-)
Index: linux-cell/arch/powerpc/kernel/of_platform.c
===================================================================
--- linux-cell.orig/arch/powerpc/kernel/of_platform.c 2007-05-15 14:13:21.000000000 +1000
+++ linux-cell/arch/powerpc/kernel/of_platform.c 2007-05-15 16:15:12.000000000 +1000
@@ -427,11 +427,13 @@ static int __devinit of_pci_phb_probe(st
/* Process "ranges" property */
pci_process_bridge_OF_ranges(phb, dev->node, 0);
- /* Setup IO space.
- * This will not work properly for ISA IOs, something needs to be done
- * about it if we ever generalize that way of probing PCI brigdes
+ /* Setup IO space. We use the non-dynamic version of that code here,
+ * which doesn't quite support unplugging. Next kernel release will
+ * have a better fix for this.
+ * Note also that we don't do ISA, this will also be fixed with a
+ * more massive rework.
*/
- pci_setup_phb_io_dynamic(phb, 0);
+ pci_setup_phb_io(phb, 0);
/* Init pci_dn data structures */
pci_devs_phb_init_dynamic(phb);
Index: linux-cell/arch/powerpc/kernel/pci_64.c
===================================================================
--- linux-cell.orig/arch/powerpc/kernel/pci_64.c 2007-05-15 14:13:21.000000000 +1000
+++ linux-cell/arch/powerpc/kernel/pci_64.c 2007-05-15 16:15:41.000000000 +1000
@@ -41,6 +41,7 @@
unsigned long pci_probe_only = 1;
int pci_assign_all_buses = 0;
+static int pci_initial_scan_done;
static void fixup_resource(struct resource *res, struct pci_dev *dev);
static void do_bus_setup(struct pci_bus *bus);
@@ -604,6 +605,8 @@ static int __init pcibios_init(void)
/* map in PCI I/O space */
phbs_remap_io();
+ pci_initial_scan_done = 1;
+
printk(KERN_DEBUG "PCI: Probing PCI hardware done\n");
return 0;
@@ -1042,13 +1045,16 @@ void __devinit pci_process_bridge_OF_ran
}
}
-void __init pci_setup_phb_io(struct pci_controller *hose, int primary)
+void __devinit pci_setup_phb_io(struct pci_controller *hose, int primary)
{
unsigned long size = hose->pci_io_size;
unsigned long io_virt_offset;
struct resource *res;
struct device_node *isa_dn;
+ if (size == 0)
+ return;
+
hose->io_base_virt = reserve_phb_iospace(size);
DBG("phb%d io_base_phys 0x%lx io_base_virt 0x%lx\n",
hose->global_number, hose->io_base_phys,
@@ -1069,6 +1075,15 @@ void __init pci_setup_phb_io(struct pci_
res = &hose->io_resource;
res->start += io_virt_offset;
res->end += io_virt_offset;
+
+ /* If this is called after the initial PCI scan, then we need to
+ * proceed to IO mappings now
+ */
+ if (pci_initial_scan_done)
+ __ioremap_explicit(hose->io_base_phys,
+ (unsigned long)hose->io_base_virt,
+ hose->pci_io_size,
+ _PAGE_NO_CACHE | _PAGE_GUARDED);
}
void __devinit pci_setup_phb_io_dynamic(struct pci_controller *hose,
@@ -1078,6 +1093,9 @@ void __devinit pci_setup_phb_io_dynamic(
unsigned long io_virt_offset;
struct resource *res;
+ if (size == 0)
+ return;
+
hose->io_base_virt = __ioremap(hose->io_base_phys, size,
_PAGE_NO_CACHE | _PAGE_GUARDED);
DBG("phb%d io_base_phys 0x%lx io_base_virt 0x%lx\n",
@@ -1106,6 +1124,9 @@ static int get_bus_io_range(struct pci_b
/* Root Bus */
res = &hose->io_resource;
+ if (res->end == 0 && res->start == 0)
+ return 1;
+
*start_virt = pci_io_base + res->start;
*start_phys = *start_virt + hose->io_base_phys
- (unsigned long) hose->io_base_virt;
^ permalink raw reply
* Re: Small fixes for the Ebony device tree
From: David Gibson @ 2007-05-15 6:18 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200705150811.09927.sr@denx.de>
On Tue, May 15, 2007 at 08:11:09AM +0200, Stefan Roese wrote:
> On Tuesday 15 May 2007, David Gibson wrote:
> > > "ibm,sdram" is way too generic to ever be usefully
> > > used for device matching.
> >
> > Yeah, I guess this should be ibm,sdram-44x or ibm,sdram-4xx. Better
> > go look up if any 40x chips use a similar sdram controller.
>
> Here a list of the current 4xx SDRAM controllers:
Ah, thanks :).
Anyone have any objection to the following: each of these controllers
should have compatible properties listing 3 string, first, a specific
version for the CPU in question (e.g "ibm,sdram-440gp"), then a string
based on the type as listed below, finally "ibm,sdram-4xx".
> SDRAM: all 40x (except for 405EZ)
ibm,sdram-40x
> DDR: 440GP, 440GX, 440EP, 440GR
ibm,sdram-44x-ddr
> DDR2: 440SP, 440SPe
ibm,sdram-44x-ddr2
> DDR2 (Denali): 440EPx, 440GRx
ibm,sdram-44x-ddr2denali
Seem reasonable?
--
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: Small fixes for the Ebony device tree
From: Stefan Roese @ 2007-05-15 6:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, David Gibson
In-Reply-To: <20070515054758.GC6998@localhost.localdomain>
On Tuesday 15 May 2007, David Gibson wrote:
> > "ibm,sdram" is way too generic to ever be usefully
> > used for device matching.
>
> Yeah, I guess this should be ibm,sdram-44x or ibm,sdram-4xx. Better
> go look up if any 40x chips use a similar sdram controller.
Here a list of the current 4xx SDRAM controllers:
SDRAM: all 40x (except for 405EZ)
DDR: 440GP, 440GX, 440EP, 440GR
DDR2: 440SP, 440SPe
DDR2 (Denali): 440EPx, 440GRx
Best regards,
Stefan
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Rewrite IO allocation & mapping on powerpc64
From: Benjamin Herrenschmidt @ 2007-05-15 6:04 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <66b16b11858147b8790b70416fd3833a@kernel.crashing.org>
On Tue, 2007-05-15 at 06:33 +0200, Segher Boessenkool wrote:
>
> Ben, can we have a config option to _not_ create a
> mapping for the legacy hardcoded stuff, even if there
> is an "isa" device node? Some platforms do not need
> it or want it, and it can help find the remaining
> drivers that do this x86 nastiness.
Maybe separately... let's not introduce too much breakage in one
patch :-)
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix warning in pci_64.c
From: Benjamin Herrenschmidt @ 2007-05-15 6:03 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070515143042.987cba34.sfr@canb.auug.org.au>
On Tue, 2007-05-15 at 14:30 +1000, Stephen Rothwell wrote:
> On Tue, 15 May 2007 14:16:35 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > void pcibios_add_platform_entries(struct pci_dev *pdev)
> > {
> > - device_create_file(&pdev->dev, &dev_attr_devspec);
> > + int rc = device_create_file(&pdev->dev, &dev_attr_devspec);
> > + WARN_ON(rc != 0);
>
> If we really don't care if the file is not created, then it is probably
> worth a comment as to why ...
Well, if it's not created, then something is badly wrong thus a
WARN_ON ... Do you think I should do more ?
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix warning in pci_64.c
From: Michael Ellerman @ 2007-05-15 6:03 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <20070515143042.987cba34.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 802 bytes --]
On Tue, 2007-05-15 at 14:30 +1000, Stephen Rothwell wrote:
> On Tue, 15 May 2007 14:16:35 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > void pcibios_add_platform_entries(struct pci_dev *pdev)
> > {
> > - device_create_file(&pdev->dev, &dev_attr_devspec);
> > + int rc = device_create_file(&pdev->dev, &dev_attr_devspec);
> > + WARN_ON(rc != 0);
>
> If we really don't care if the file is not created, then it is probably
> worth a comment as to why ...
Greg already has a patch from me to fix that.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
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: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Add spinlock to request_phb_iospace()
From: Benjamin Herrenschmidt @ 2007-05-15 6:02 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20070515142615.bf748b7a.sfr@canb.auug.org.au>
On Tue, 2007-05-15 at 14:26 +1000, Stephen Rothwell wrote:
> On Tue, 15 May 2007 14:16:26 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > request_phb_iospace() can be called from different CPUs at init
> > time (at least with my next patch) and thus needs a spinlock. As
> > for the next patch, this is a temporary workaround for 2.6.22
> > issues until my rewrite of IO mappings is ready (for 2.6.23)
>
> What problem is this solving?
See the description of the next patch.
Ben.
^ permalink raw reply
* Re: [PATCH] pcmcia: ppc64 needs 64-bit ioaddr_t
From: Christoph Hellwig @ 2007-05-15 5:52 UTC (permalink / raw)
To: Olof Johansson
Cc: linux-pcmcia, linux-kernel, linuxppc-dev, paulus,
Christoph Hellwig, Dominik Brodowski
In-Reply-To: <20070514225731.GA4191@lixom.net>
On Mon, May 14, 2007 at 05:57:31PM -0500, Olof Johansson wrote:
> On Sun, May 13, 2007 at 11:46:08PM +0200, Christoph Hellwig wrote:
> > On Sat, May 12, 2007 at 09:31:05AM -0500, Olof Johansson wrote:
> > > ppc64 really needs ioaddr_t to be 64-bit, since I/O addresses really
> > > are MMIO addresses, and remapped to a high range.
> > >
> > > While the type is exported to userspace, there hasn't been any platforms
> > > with PCMCIA on 64-bit powerpc until now, so changing it won't regress
> > > any existing users.
> >
> > In fact the only use of the type should be in the obsolete ioctl-based user
> > interface. So instead of changing the size of the type you should
> >
> > a) make sure you're not using cardmgr
> > b) fix up those places that still use ioaddr_t where they shouldn't
> > and switch the to kio_addr_t (why not just unsigned long like all
> > other busses?)
>
> I just noticed that feature-removal-schedule.txt says November 2005 for
> the removal of the pcmcia ioctl's, but they're still there. I'm missing
> the history here, any reason they weren't removed yet?
See the discussions on lkml. It seems like people haven't really
noticed the deprecation messages and are still using it. Still not
a good reason to use them on a new port (at least new in terms of
pcmcia support)
^ permalink raw reply
* Re: Small fixes for the Ebony device tree
From: David Gibson @ 2007-05-15 5:47 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <8492e53122b6e1ba269afd53b48a4968@kernel.crashing.org>
On Tue, May 15, 2007 at 07:11:07AM +0200, Segher Boessenkool wrote:
> Just a few more things...
>
> > plb {
> > - device_type = "ibm,plb";
> > compatible = "ibm,plb-440gp", "ibm,plb4";
>
> You match on "ibm,plb" though. Well you got one
> in three right ;-)
Indeed. And I'm still not sure how it's recognizing the plb devices
right now...
> > + SDRAM0: memory-controller {
> > compatible = "ibm,sdram-440gp", "ibm,sdram";
>
> "ibm,sdram" is way too generic to ever be usefully
> used for device matching.
Yeah, I guess this should be ibm,sdram-44x or ibm,sdram-4xx. Better
go look up if any 40x chips use a similar sdram controller.
> > + SRAM0: sram {
> > + compatible = "ibm,sram440gp";
>
> You spell this one without a dash, all others with one.
Ah, yes, oops...
--
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: Small fixes for the Ebony device tree
From: David Gibson @ 2007-05-15 5:46 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <b353b330365fd9ede35fb1cbbbf09aec@kernel.crashing.org>
On Tue, May 15, 2007 at 06:59:49AM +0200, Segher Boessenkool wrote:
> >>> + SRAM0: sram {
> >>> + compatible = "ibm,sram440gp";
> >>> + dcr-reg = <020 8 00a 1>;
> >>> + };
> >>
> >> Is this thing _only_ addressable over DCRs? Weird.
> >
> > Well... the control registers are certainly DCR only. I guess there's
> > the actual SRAM itself, though whether this belongs in this node, or
> > elsewhere isn't immediately clear. I haven't yet investigated how the
> > SRAM is mapped (it depends on DIP switch settings) so I'm certainly
> > not considering this node complete yet.
>
> If it is supposed to have a "reg" property, and it doesn't
> yet, it might be a good idea to comment it out in the DTS
> for now, so later kernels can work with the older device
> tree correctly.
Given that I'm not aware of any Ebony firmwares that actually supply a
device tree, so in practice the kernel's tree will always come from an
attached zImage, I don't think this is really a big consideration.
> >>> MAL0: mcmal {
> >>> - device_type = "mcmal-dma";
> >>> + device_type = "dma-controller";
> >>> compatible = "ibm,mcmal-440gp", "ibm,mcmal";
> >>
> >> Remove "device_type", change name to "dma-controller"?
> >
> > Don't really want to remove the device_type, because the MAL driver
> > looks for it at present.
>
> Fair enough. But you change the "device_type" in
> this patch, so presumably you change it in the kernel
The kernel driver recognizes both variants, but the one I had
previously is marked deprecated.
> driver as well -- can't you just *fix* the kernel driver,
> instead?
Well.. I guess, but I'd prefer to leave that to BenH, who wrote the
driver.
> > Don't really want to change the name, since
> > that might encourage confusion with the other (more conventional) DMA
> > controller.
>
> Nah, just look at the other properties in the node and
> you know what is what. It is quite common to have nodes
> with the same name representing different devices (for
> example, "ethernet" devices -- "dma-controller" would be
> a bit more unusual, sure).
>
> I have no strong feelings about the name, "mcmal" is
> generic enough a name as far as I'm concerned.
>
> >>> EBC0: ebc {
> >>> - device_type = "ibm,ebc";
> >>> compatible = "ibm,ebc-440gp";
> >>
> >> You forgot "ibm,ebc" here.
> >
> > Hmm.. yeah, I guess.
>
> Well that's what the kernel code matches on ;-)
Um.. yes. I wonder how it was working before...
--
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: Small fixes for the Ebony device tree
From: Segher Boessenkool @ 2007-05-15 5:11 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070515020026.GG565@localhost.localdomain>
Just a few more things...
> plb {
> - device_type = "ibm,plb";
> compatible = "ibm,plb-440gp", "ibm,plb4";
You match on "ibm,plb" though. Well you got one
in three right ;-)
> + SDRAM0: memory-controller {
> compatible = "ibm,sdram-440gp", "ibm,sdram";
"ibm,sdram" is way too generic to ever be usefully
used for device matching.
> + SRAM0: sram {
> + compatible = "ibm,sram440gp";
You spell this one without a dash, all others with one.
Segher
^ permalink raw reply
* [Patch] [POWERPC] allow make defconfig to work on non-power machines
From: Simon Horman @ 2007-05-15 4:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
I'm wondering if there is any interest in a patch along the lines
of this to allow make defconfig to do something sensible when
uname isn't sensible - I noticed this when doing cross-compile builds.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
arch/powerpc/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/arch/powerpc/Makefile
===================================================================
--- linux-2.6.orig/arch/powerpc/Makefile 2007-05-15 11:23:14.000000000 +0900
+++ linux-2.6/arch/powerpc/Makefile 2007-05-15 13:28:36.000000000 +0900
@@ -35,7 +35,7 @@ endif
export CROSS32CC CROSS32AS CROSS32LD CROSS32AR CROSS32OBJCOPY
-KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
+KBUILD_DEFCONFIG := $(shell c=`uname -m`_defconfig; if [ ! -f arch/powerpc/configs/$$c ]; then c=ppc64_defconfig; fi; echo -n $$c)
ifeq ($(CONFIG_PPC64),y)
OLDARCH := ppc64
^ permalink raw reply
* Re: Small fixes for the Ebony device tree
From: Segher Boessenkool @ 2007-05-15 4:59 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070515011704.GB565@localhost.localdomain>
>>> + SRAM0: sram {
>>> + compatible = "ibm,sram440gp";
>>> + dcr-reg = <020 8 00a 1>;
>>> + };
>>
>> Is this thing _only_ addressable over DCRs? Weird.
>
> Well... the control registers are certainly DCR only. I guess there's
> the actual SRAM itself, though whether this belongs in this node, or
> elsewhere isn't immediately clear. I haven't yet investigated how the
> SRAM is mapped (it depends on DIP switch settings) so I'm certainly
> not considering this node complete yet.
If it is supposed to have a "reg" property, and it doesn't
yet, it might be a good idea to comment it out in the DTS
for now, so later kernels can work with the older device
tree correctly.
>>> MAL0: mcmal {
>>> - device_type = "mcmal-dma";
>>> + device_type = "dma-controller";
>>> compatible = "ibm,mcmal-440gp", "ibm,mcmal";
>>
>> Remove "device_type", change name to "dma-controller"?
>
> Don't really want to remove the device_type, because the MAL driver
> looks for it at present.
Fair enough. But you change the "device_type" in
this patch, so presumably you change it in the kernel
driver as well -- can't you just *fix* the kernel driver,
instead?
> Don't really want to change the name, since
> that might encourage confusion with the other (more conventional) DMA
> controller.
Nah, just look at the other properties in the node and
you know what is what. It is quite common to have nodes
with the same name representing different devices (for
example, "ethernet" devices -- "dma-controller" would be
a bit more unusual, sure).
I have no strong feelings about the name, "mcmal" is
generic enough a name as far as I'm concerned.
>>> EBC0: ebc {
>>> - device_type = "ibm,ebc";
>>> compatible = "ibm,ebc-440gp";
>>
>> You forgot "ibm,ebc" here.
>
> Hmm.. yeah, I guess.
Well that's what the kernel code matches on ;-)
> Revised patch coming shortly.
Looking forward to it!
Segher
^ permalink raw reply
* [PATCH 3/3] Fixes to allow use of Ebony's flash chips through physmap_of
From: David Gibson @ 2007-05-15 4:54 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070515045247.GA6998@localhost.localdomain>
This patch contains a handful of small fixes to allow the Ebony's
flash to be exposed as MTD devices via the physmap_of driver.
Specifically it:
- Makes a small addition to the device tree and zImage wrapper
to record the correct address for the flash in the device tree based
on the board switches as reported via an FPGA register.
- Prohibits building the old hard-coded "Ebony" flash map on
arch/powerpc kernels, in favour of using physmap_of's device tree
based approach.
- Enables MTD and physmap_of in the Ebony defconfig.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/boot/dts/ebony.dts | 1
arch/powerpc/boot/ebony.c | 41 +++++++++
arch/powerpc/configs/ebony_defconfig | 148 ++++++++++++++++++++++++++---------
drivers/mtd/maps/Kconfig | 2
4 files changed, 154 insertions(+), 38 deletions(-)
Index: working-2.6/drivers/mtd/maps/Kconfig
===================================================================
--- working-2.6.orig/drivers/mtd/maps/Kconfig 2007-05-14 14:37:57.000000000 +1000
+++ working-2.6/drivers/mtd/maps/Kconfig 2007-05-14 14:45:58.000000000 +1000
@@ -368,7 +368,7 @@ config MTD_WALNUT
config MTD_EBONY
tristate "Flash devices mapped on IBM 440GP Ebony"
- depends on MTD_JEDECPROBE && EBONY
+ depends on MTD_JEDECPROBE && EBONY && !PPC_MERGE
help
This enables access routines for the flash chips on the IBM 440GP
Ebony board. If you have one of these boards and would like to
Index: working-2.6/arch/powerpc/configs/ebony_defconfig
===================================================================
--- working-2.6.orig/arch/powerpc/configs/ebony_defconfig 2007-05-14 14:37:57.000000000 +1000
+++ working-2.6/arch/powerpc/configs/ebony_defconfig 2007-05-14 14:45:58.000000000 +1000
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.21
-# Fri May 4 13:47:08 2007
+# Linux kernel version: 2.6.21-powerpc-ebony-mtd
+# Fri May 11 14:41:46 2007
#
# CONFIG_PPC64 is not set
CONFIG_PPC32=y
@@ -45,6 +45,7 @@ CONFIG_4xx=y
CONFIG_BOOKE=y
CONFIG_PTE_64BIT=y
CONFIG_PHYS_64BIT=y
+# CONFIG_PPC_MM_SLICES is not set
CONFIG_NOT_COHERENT_CACHE=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
@@ -70,6 +71,7 @@ CONFIG_POSIX_MQUEUE=y
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
+CONFIG_LOG_BUF_SHIFT=14
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
@@ -89,12 +91,13 @@ CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
-CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_SLAB=y
+# CONFIG_SLUB is not set
+# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
-# CONFIG_SLOB is not set
#
# Loadable module support
@@ -193,16 +196,14 @@ CONFIG_PPC_INDIRECT_PCI=y
CONFIG_PCI=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCIEPORTBUS is not set
+CONFIG_ARCH_SUPPORTS_MSI=y
+# CONFIG_PCI_MSI is not set
# CONFIG_PCI_DEBUG is not set
#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set
-
-#
-# PCI Hotplug Support
-#
# CONFIG_HOTPLUG_PCI is not set
#
@@ -310,7 +311,9 @@ CONFIG_DEFAULT_TCP_CONG="cubic"
#
# CONFIG_CFG80211 is not set
# CONFIG_WIRELESS_EXT is not set
+# CONFIG_MAC80211 is not set
# CONFIG_IEEE80211 is not set
+# CONFIG_RFKILL is not set
#
# Device Drivers
@@ -331,7 +334,80 @@ CONFIG_FW_LOADER=y
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+# CONFIG_MTD_CMDLINE_PARTS is not set
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+CONFIG_MTD_JEDECPROBE=y
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+# CONFIG_MTD_CFI_INTELEXT is not set
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PHYSMAP is not set
+CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+# CONFIG_MTD_NAND is not set
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
#
# Parallel port support
@@ -365,8 +441,10 @@ CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
#
# Misc devices
#
+# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
+# CONFIG_BLINK is not set
#
# ATA/ATAPI/MFM/RLL support
@@ -398,6 +476,7 @@ CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
#
# IEEE 1394 (FireWire) support
#
+# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
#
@@ -468,6 +547,8 @@ CONFIG_IBM_NEW_EMAC_ZMII=y
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
+# CONFIG_MLX4_CORE is not set
+CONFIG_MLX4_DEBUG=y
#
# Token Ring devices
@@ -550,15 +631,10 @@ CONFIG_LEGACY_PTY_COUNT=256
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
-
-#
-# Watchdog Cards
-#
# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_GEN_RTC is not set
-# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_AGP is not set
@@ -569,10 +645,7 @@ CONFIG_LEGACY_PTY_COUNT=256
# TPM devices
#
# CONFIG_TCG_TPM is not set
-
-#
-# I2C support
-#
+CONFIG_DEVPORT=y
# CONFIG_I2C is not set
#
@@ -585,12 +658,7 @@ CONFIG_LEGACY_PTY_COUNT=256
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
-
-#
-# Hardware Monitoring support
-#
# CONFIG_HWMON is not set
-# CONFIG_HWMON_VID is not set
#
# Multifunction device drivers
@@ -611,6 +679,12 @@ CONFIG_LEGACY_PTY_COUNT=256
# Graphics support
#
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+
+#
+# Display device support
+#
+# CONFIG_DISPLAY_SUPPORT is not set
+# CONFIG_VGASTATE is not set
# CONFIG_FB is not set
# CONFIG_FB_IBM_GXT4500 is not set
@@ -635,10 +709,6 @@ CONFIG_USB_ARCH_HAS_EHCI=y
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
-
-#
-# MMC/SD Card support
-#
# CONFIG_MMC is not set
#
@@ -682,14 +752,6 @@ CONFIG_USB_ARCH_HAS_EHCI=y
#
#
-# Auxiliary Display support
-#
-
-#
-# Virtualization
-#
-
-#
# File systems
#
CONFIG_EXT2_FS=y
@@ -749,6 +811,15 @@ CONFIG_RAMFS=y
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
+CONFIG_JFFS2_FS=y
+CONFIG_JFFS2_FS_DEBUG=0
+CONFIG_JFFS2_FS_WRITEBUFFER=y
+# CONFIG_JFFS2_SUMMARY is not set
+# CONFIG_JFFS2_FS_XATTR is not set
+# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
+CONFIG_JFFS2_ZLIB=y
+CONFIG_JFFS2_RTIME=y
+# CONFIG_JFFS2_RUBIN is not set
CONFIG_CRAMFS=y
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
@@ -770,6 +841,7 @@ CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
+# CONFIG_SUNRPC_BIND34 is not set
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
@@ -803,12 +875,15 @@ CONFIG_MSDOS_PARTITION=y
CONFIG_BITREVERSE=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
+# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
+CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
+CONFIG_HAS_DMA=y
#
# Instrumentation Support
@@ -826,7 +901,6 @@ CONFIG_MAGIC_SYSRQ=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
-CONFIG_LOG_BUF_SHIFT=14
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
@@ -851,7 +925,6 @@ CONFIG_FORCED_INLINING=y
# CONFIG_DEBUGGER is not set
# CONFIG_BDI_SWITCH is not set
# CONFIG_BOOTX_TEXT is not set
-# CONFIG_SERIAL_TEXT_DEBUG is not set
# CONFIG_PPC_EARLY_DEBUG is not set
#
@@ -882,6 +955,7 @@ CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_PCBC=y
# CONFIG_CRYPTO_LRW is not set
+# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_BLOWFISH is not set
Index: working-2.6/arch/powerpc/boot/ebony.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/ebony.c 2007-05-14 14:45:56.000000000 +1000
+++ working-2.6/arch/powerpc/boot/ebony.c 2007-05-14 14:45:58.000000000 +1000
@@ -24,6 +24,7 @@
#include "page.h"
#include "ops.h"
#include "reg.h"
+#include "io.h"
#include "dcr.h"
#include "44x.h"
@@ -92,6 +93,45 @@ void ibm440gp_fixup_clocks(unsigned int
dt_fixup_clock("/plb/opb/serial@40000300", uart1);
}
+#define EBONY_FPGA_PATH "/plb/opb/ebc/fpga"
+#define EBONY_FPGA_FLASH_SEL 0x01
+#define EBONY_SMALL_FLASH_PATH "/plb/opb/ebc/small-flash"
+
+static void ebony_flashsel_fixup(void)
+{
+ void *devp;
+ u32 reg[3] = {0x0, 0x0, 0x80000};
+ u8 *fpga;
+ u8 fpga_reg0 = 0x0;
+
+ devp = finddevice(EBONY_FPGA_PATH);
+ if (! devp)
+ fatal("Couldn't locate FPGA node %s\n\r", EBONY_FPGA_PATH);
+
+ if (getprop(devp, "virtual-reg", fpga, sizeof(fpga)) != sizeof(fpga))
+ fatal("%s has virtual-reg property of unexpected size\n\r",
+ EBONY_FPGA_PATH);
+
+ fpga_reg0 = in_8(fpga);
+
+ printf("Ebony: FPGA register 0 = 0x%02x\n\r", fpga_reg0);
+
+ devp = finddevice(EBONY_SMALL_FLASH_PATH);
+ if (! devp)
+ fatal("Couldn't locate small flash node %s\n\r",
+ EBONY_SMALL_FLASH_PATH);
+
+ if (getprop(devp, "reg", reg, sizeof(reg)) != sizeof(reg))
+ fatal("%s has reg property of unexpected size\n\r",
+ EBONY_SMALL_FLASH_PATH);
+
+ /* Invert address bit 14 (IBM-endian) if FLASH_SEL fpga bit is set */
+ if (fpga_reg0 & EBONY_FPGA_FLASH_SEL)
+ reg[1] ^= 0x80000;
+
+ setprop(devp, "reg", reg, sizeof(reg));
+}
+
static void ebony_fixups(void)
{
// FIXME: sysclk should be derived by reading the FPGA registers
@@ -101,6 +141,7 @@ static void ebony_fixups(void)
ibm44x_fixup_memsize();
dt_fixup_mac_addresses(ebony_mac0, ebony_mac1);
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
+ ebony_flashsel_fixup();
}
void ebony_init(void *mac0, void *mac1)
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-05-14 14:45:56.000000000 +1000
+++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-05-14 14:45:58.000000000 +1000
@@ -176,6 +176,7 @@
fpga@7,0 {
compatible = "Ebony-FPGA";
reg = <7 0 10>;
+ virtual-reg = <e8300000>;
};
};
^ permalink raw reply
* [PATCH 2/3] Derive ebc ranges property from EBC registers
From: David Gibson @ 2007-05-15 4:54 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070515045247.GA6998@localhost.localdomain>
In the device tree for Ebony, the 'ranges' property in the node for
the EBC bridge shows the mappings from the chip select / address lines
actually used for the EBC peripherals into the address space of the
OPB. At present, these mappings are hardcoded in ebony.dts for the
mappings set up by the OpenBIOS firmware when it configures the EBC
bridge.
This patch replaces the hardcoded mappings with code in the zImage to
read the EBC configuration registers and create an appropriate ranges
property based on them. This should make the zImage and kernel more
robust to changes in firmware configuration. In particular, some of
the Ebony's DIP switches can change the effective address of the Flash
and other peripherals in OPB space. With this patch, the kernel will
be able to cope with at least some of the possible variations.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/boot/44x.c | 29 +++++++++++++++++++++++++++++
arch/powerpc/boot/44x.h | 1 +
arch/powerpc/boot/dcr.h | 37 +++++++++++++++++++++++++++++++++++++
arch/powerpc/boot/dts/ebony.dts | 8 +++-----
arch/powerpc/boot/ebony.c | 1 +
5 files changed, 71 insertions(+), 5 deletions(-)
Index: working-2.6/arch/powerpc/boot/dcr.h
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dcr.h 2007-05-14 14:37:57.000000000 +1000
+++ working-2.6/arch/powerpc/boot/dcr.h 2007-05-14 14:45:56.000000000 +1000
@@ -26,6 +26,43 @@ static const unsigned long sdram_bxcr[]
#define SDRAM_CONFIG_BANK_SIZE(reg) \
(0x00400000 << ((reg & SDRAM_CONFIG_SIZE_MASK) >> 17))
+/* 440GP External Bus Controller (EBC) */
+#define DCRN_EBC0_CFGADDR 0x012
+#define DCRN_EBC0_CFGDATA 0x013
+#define EBC_NUM_BANKS 8
+#define EBC_B0CR 0x00
+#define EBC_B1CR 0x01
+#define EBC_B2CR 0x02
+#define EBC_B3CR 0x03
+#define EBC_B4CR 0x04
+#define EBC_B5CR 0x05
+#define EBC_B6CR 0x06
+#define EBC_B7CR 0x07
+#define EBC_BXCR(n) (n)
+#define EBC_BXCR_BAS 0xfff00000
+#define EBC_BXCR_BS 0x000e0000
+#define EBC_BXCR_BANK_SIZE(reg) \
+ (0x100000 << (((reg) & EBC_BXCR_BS) >> 17))
+#define EBC_BXCR_BU 0x00018000
+#define EBC_BXCR_BU_OFF 0x00000000
+#define EBC_BXCR_BU_RO 0x00008000
+#define EBC_BXCR_BU_WO 0x00010000
+#define EBC_BXCR_BU_RW 0x00018000
+#define EBC_BXCR_BW 0x00006000
+#define EBC_B0AP 0x10
+#define EBC_B1AP 0x11
+#define EBC_B2AP 0x12
+#define EBC_B3AP 0x13
+#define EBC_B4AP 0x14
+#define EBC_B5AP 0x15
+#define EBC_B6AP 0x16
+#define EBC_B7AP 0x17
+#define EBC_BXAP(n) (0x10+(n))
+#define EBC_BEAR 0x20
+#define EBC_BESR 0x21
+#define EBC_CFG 0x23
+#define EBC_CID 0x24
+
/* 440GP Clock, PM, chip control */
#define DCRN_CPC0_SR 0x0b0
#define DCRN_CPC0_ER 0x0b1
Index: working-2.6/arch/powerpc/boot/ebony.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/ebony.c 2007-05-14 14:45:55.000000000 +1000
+++ working-2.6/arch/powerpc/boot/ebony.c 2007-05-14 14:45:56.000000000 +1000
@@ -100,6 +100,7 @@ static void ebony_fixups(void)
ibm440gp_fixup_clocks(sysclk, 6 * 1843200);
ibm44x_fixup_memsize();
dt_fixup_mac_addresses(ebony_mac0, ebony_mac1);
+ ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
}
void ebony_init(void *mac0, void *mac1)
Index: working-2.6/arch/powerpc/boot/dts/ebony.dts
===================================================================
--- working-2.6.orig/arch/powerpc/boot/dts/ebony.dts 2007-05-14 14:38:39.000000000 +1000
+++ working-2.6/arch/powerpc/boot/dts/ebony.dts 2007-05-14 14:45:56.000000000 +1000
@@ -136,11 +136,9 @@
#address-cells = <2>;
#size-cells = <1>;
clock-frequency = <0>; // Filled in by zImage
- ranges = <0 00000000 fff00000 100000
- 1 00000000 48000000 100000
- 2 00000000 ff800000 400000
- 3 00000000 48200000 100000
- 7 00000000 48300000 100000>;
+ // ranges property is supplied by zImage
+ // based on firmware's configuration of the
+ // EBC bridge
interrupts = <5 4>;
interrupt-parent = <&UIC1>;
Index: working-2.6/arch/powerpc/boot/44x.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/44x.c 2007-05-14 14:45:55.000000000 +1000
+++ working-2.6/arch/powerpc/boot/44x.c 2007-05-14 14:45:56.000000000 +1000
@@ -54,3 +54,32 @@ void ibm44x_dbcr_reset(void)
);
}
+
+/* Read 4xx EBC bus bridge registers to get mappings of the peripheral
+ * banks into the OPB address space */
+void ibm4xx_fixup_ebc_ranges(const char *ebc)
+{
+ void *devp;
+ u32 bxcr;
+ u32 ranges[EBC_NUM_BANKS*4];
+ u32 *p = ranges;
+ int i;
+
+ for (i = 0; i < EBC_NUM_BANKS; i++) {
+ mtdcr(DCRN_EBC0_CFGADDR, EBC_BXCR(i));
+ bxcr = mfdcr(DCRN_EBC0_CFGDATA);
+
+ if ((bxcr & EBC_BXCR_BU) != EBC_BXCR_BU_OFF) {
+ *p++ = i;
+ *p++ = 0;
+ *p++ = bxcr & EBC_BXCR_BAS;
+ *p++ = EBC_BXCR_BANK_SIZE(bxcr);
+ }
+ }
+
+ devp = finddevice(ebc);
+ if (! devp)
+ fatal("Couldn't locate EBC node %s\n\r", ebc);
+
+ setprop(devp, "ranges", ranges, (p - ranges) * sizeof(u32));
+}
Index: working-2.6/arch/powerpc/boot/44x.h
===================================================================
--- working-2.6.orig/arch/powerpc/boot/44x.h 2007-05-14 14:45:55.000000000 +1000
+++ working-2.6/arch/powerpc/boot/44x.h 2007-05-14 14:45:56.000000000 +1000
@@ -11,6 +11,7 @@
#define _PPC_BOOT_44X_H_
void ibm44x_fixup_memsize(void);
+void ibm4xx_fixup_ebc_ranges(const char *ebc);
void ibm44x_dbcr_reset(void);
void ebony_init(void *mac0, void *mac1);
^ permalink raw reply
* [PATCH 1/3] Factor zImage's 44x reset code out of ebony.c
From: David Gibson @ 2007-05-15 4:54 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070515045247.GA6998@localhost.localdomain>
The ebony_exit() function which resets the Ebony board should in fact
be common to most if not all 44x boards. This patch moves the
function out into 44x.c, renaming it, so it can be used by other 44x
platforms.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/boot/44x.c | 16 ++++++++++++++++
arch/powerpc/boot/44x.h | 2 ++
arch/powerpc/boot/ebony.c | 18 +-----------------
3 files changed, 19 insertions(+), 17 deletions(-)
Index: working-2.6/arch/powerpc/boot/44x.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/44x.c 2007-05-08 15:07:45.000000000 +1000
+++ working-2.6/arch/powerpc/boot/44x.c 2007-05-14 13:15:22.000000000 +1000
@@ -38,3 +38,19 @@ void ibm44x_fixup_memsize(void)
dt_fixup_memory(0, memsize);
}
+
+#define SPRN_DBCR0 0x134
+#define DBCR0_RST_SYSTEM 0x30000000
+
+void ibm44x_dbcr_reset(void)
+{
+ unsigned long tmp;
+
+ asm volatile (
+ "mfspr %0,%1\n"
+ "oris %0,%0,%2@h\n"
+ "mtspr %1,%0"
+ : "=&r"(tmp) : "i"(SPRN_DBCR0), "i"(DBCR0_RST_SYSTEM)
+ );
+
+}
Index: working-2.6/arch/powerpc/boot/44x.h
===================================================================
--- working-2.6.orig/arch/powerpc/boot/44x.h 2007-05-08 15:07:45.000000000 +1000
+++ working-2.6/arch/powerpc/boot/44x.h 2007-05-14 13:15:52.000000000 +1000
@@ -11,6 +11,8 @@
#define _PPC_BOOT_44X_H_
void ibm44x_fixup_memsize(void);
+
+void ibm44x_dbcr_reset(void);
void ebony_init(void *mac0, void *mac1);
#endif /* _PPC_BOOT_44X_H_ */
Index: working-2.6/arch/powerpc/boot/ebony.c
===================================================================
--- working-2.6.orig/arch/powerpc/boot/ebony.c 2007-05-08 15:07:45.000000000 +1000
+++ working-2.6/arch/powerpc/boot/ebony.c 2007-05-14 13:15:22.000000000 +1000
@@ -102,26 +102,10 @@ static void ebony_fixups(void)
dt_fixup_mac_addresses(ebony_mac0, ebony_mac1);
}
-#define SPRN_DBCR0 0x134
-#define DBCR0_RST_SYSTEM 0x30000000
-
-static void ebony_exit(void)
-{
- unsigned long tmp;
-
- asm volatile (
- "mfspr %0,%1\n"
- "oris %0,%0,%2@h\n"
- "mtspr %1,%0"
- : "=&r"(tmp) : "i"(SPRN_DBCR0), "i"(DBCR0_RST_SYSTEM)
- );
-
-}
-
void ebony_init(void *mac0, void *mac1)
{
platform_ops.fixups = ebony_fixups;
- platform_ops.exit = ebony_exit;
+ platform_ops.exit = ibm44x_dbcr_reset;
ebony_mac0 = mac0;
ebony_mac1 = mac1;
ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
^ permalink raw reply
* [0/3] Ebony tweaks
From: David Gibson @ 2007-05-15 4:52 UTC (permalink / raw)
To: linuxppc-dev
The core Ebony support is merged now, but here are some extra cleanups
and extensions to the Ebony support. These are mostly RFC for now,
not expect to merge before 2.6.23.
--
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 -msoft-float to BOOTCFLAGS
From: Segher Boessenkool @ 2007-05-15 4:46 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, paulus
In-Reply-To: <1179190345.3420.74.camel@zod.rchland.ibm.com>
> HOSTCC := gcc
> BOOTCFLAGS := $(HOSTCFLAGS) -fno-builtin -nostdinc -isystem \
> - $(shell $(CROSS32CC) -print-file-name=include) -fPIC
> + $(shell $(CROSS32CC) -print-file-name=include) -fPIC -msoft-float
> BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
While you're at it, could you get rid of the HOSTCFLAGS
inclusion here? The host compiler has absolutely nothing
to do with the 32-bit powerpc compiler.
There are some more flags you might want to add btw
(-nostdlib, -mno-multiple, stuff like that -- just examples,
don't blindly add these).
Segher
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Rewrite IO allocation & mapping on powerpc64
From: Segher Boessenkool @ 2007-05-15 4:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <17992.64515.797925.855510@cargo.ozlabs.ibm.com>
>> This is wrong -- there are systems with ISA that
>> also have PCI devices that require 16-bit legacy
>> I/O windows (e.g., systems with the AMD8111 chip,
>> like Maple).
>
> If they are PCI devices and their drivers use a pci_dev's resources
> to get to the device's I/O resources, then they are fine.
>
> The only reason for reserving the low 64k is to cater for drivers that
> use a hard-coded port number, e.g. video drivers using the VGA port
> numbers. We have been gradually getting rid of the hard coded port
> numbers in drivers but I don't think they're all gone yet.
Yes, I misunderstood (that teaches me for reading the
patch description only, not the patch itself :-) ).
Ben, can we have a config option to _not_ create a
mapping for the legacy hardcoded stuff, even if there
is an "isa" device node? Some platforms do not need
it or want it, and it can help find the remaining
drivers that do this x86 nastiness.
Segher
^ 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