Re: [PATCH 09/28] blk_end_request: changing ps3disk (take 3)
On Fri, 30 Nov 2007, Kiyoshi Ueda wrote:
> This patch converts ps3disk to use blk_end_request().
^^^
Patch subject and description are inconsistent with actual change.
> Signed-off-by: Kiyoshi Ueda <[EMAIL PROTECTED]>
> Signed-off-by: Jun'ichi Nomura <[EMAIL PROTECTED]>
> ---
> drivers/block/ps3disk.c |6 +-
> 1 files changed, 1 insertion(+), 5 deletions(-)
>
> Index: 2.6.24-rc3-mm2/drivers/block/ps3disk.c
> ===
> --- 2.6.24-rc3-mm2.orig/drivers/block/ps3disk.c
> +++ 2.6.24-rc3-mm2/drivers/block/ps3disk.c
> @@ -280,11 +280,7 @@ static irqreturn_t ps3disk_interrupt(int
> }
>
> spin_lock(&priv->lock);
> - if (!end_that_request_first(req, uptodate, num_sectors)) {
> - add_disk_randomness(req->rq_disk);
> - blkdev_dequeue_request(req);
> - end_that_request_last(req, uptodate);
> - }
> + __blk_end_request(req, uptodate, num_sectors << 9);
^
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] OF-platform PATA driver
On Sat, Dec 01, 2007 at 09:57:55PM -0600, Olof Johansson wrote:
> On Sun, Dec 02, 2007 at 02:58:10AM +0300, Anton Vorontsov wrote:
> > On Sat, Dec 01, 2007 at 05:54:49PM -0500, Jeff Garzik wrote:
> > while (1) {
> > send_patches();
> >
> > if (ack_collected(PaulM) && ack_collected(PowerPC_people))
> > break;
> >
> > sleep(wait_for_comments_timeout); <-- currently here.
>
> I still haven't seen you address the compatible comments (that
> pata-platform is suboptimal). Or did I miss some respin of the patches?
I didn't resend these patches yet. You started the thread, but you hid
away from the discussion (you had been Cc'ed to every mail).
1. Arnd suggested {p,s}ata-pio-{1,2,3,..} or ata-{1,2,3,..} compatible
scheme;
2. Sergei verbosely explained that that there is no reason to
complicate compatible property. He suggested ata-generic, or
ata-simple;
Mainly I was awaiting for your further comments. By now I tend to
follow Sergei's comments and rename compatible stuff to ata-generic.
Are you fine with it?
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHYlayer functionality
[SNIP]
> ^^ the correct solution is to implement arch_initcall function
> which will create fixed PHYs, and then leave only
> snprintf(fpi->bus_id, 16, PHY_ID_FMT, 0, *data); part in the
> fs_enet's find_phy().
>
> Try add something like this to the fsl_soc.c (compile untested):
>
> - - - -
> static int __init of_add_fixed_phys(void)
> {
> struct device_node *np;
> const u32 *prop;
> struct fixed_phy_status status = {};
>
> while ((np = of_find_node_by_name(NULL, "ethernet"))) {
> data = of_get_property(np, "fixed-link", NULL);
> if (!data)
> continue;
>
> status.link = 1;
> status.duplex = data[1];
> status.speed = data[2];
What about Pause and Asym_Pause? Dunno why so few, if any, eth drivers
impl. it, but the PHY lib supports it.
Even if fixed PHYs doesn't support it directly I think the OF interface
should have it.
- fixed-link : where a is emulated phy id - choose any,
but unique to the all specified fixed-links, b is duplex - 0 half,
1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no pause,
1 pause, d asym_pause - 0 no asym_pause, 1 asym_pause.
Jocke
>
> ret = fixed_phy_add(PHY_POLL, data[0], &status);
> if (ret)
> return ret;
> }
>
> return 0;
> }
> arch_initcall(of_add_fixed_phys);
> - - - -
>
> And remove fixed_phy_add() from the fs_enet. This should work
> nicely and also should be ideologically correct. ;-)
>
> > How is this supposed to work for modules or for the
> > PPC_CPM_NEW_BINDING mode where the device tree is no longer scanned
> > during fs_soc initialization but during device initialization?
>
> We should mark fixed.c as bool. Fake/virtual/fixed/platform PHYs
> creation is architecture code anyway, can't be =m.
>
> --
> Anton Vorontsov
> email: [EMAIL PROTECTED]
> backup email: [EMAIL PROTECTED]
> irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] [NET] phy/fixed.c: rework to not duplicate PHYlayer functionality
On Sun, Dec 02, 2007 at 12:54:36PM +0100, Joakim Tjernlund wrote:
> [SNIP]
> > ^^ the correct solution is to implement arch_initcall function
> > which will create fixed PHYs, and then leave only
> > snprintf(fpi->bus_id, 16, PHY_ID_FMT, 0, *data); part in the
> > fs_enet's find_phy().
> >
> > Try add something like this to the fsl_soc.c (compile untested):
> >
> > - - - -
> > static int __init of_add_fixed_phys(void)
> > {
> > struct device_node *np;
> > const u32 *prop;
> > struct fixed_phy_status status = {};
> >
> > while ((np = of_find_node_by_name(NULL, "ethernet"))) {
> > data = of_get_property(np, "fixed-link", NULL);
> > if (!data)
> > continue;
> >
> > status.link = 1;
> > status.duplex = data[1];
> > status.speed = data[2];
>
> What about Pause and Asym_Pause?
Will be addressed in the next respin of these patches. Let's
hope on Monday.
> Dunno why so few, if any, eth drivers
> impl. it, but the PHY lib supports it.
> Even if fixed PHYs doesn't support it directly I think the OF interface
> should have it.
>
> - fixed-link : where a is emulated phy id - choose any,
> but unique to the all specified fixed-links, b is duplex - 0 half,
> 1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no pause,
> 1 pause, d asym_pause - 0 no asym_pause, 1 asym_pause.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 24/24] powerpc: Base support for 440SPe "Katmai" eval board
Hi Ben,
On Friday 30 November 2007, Benjamin Herrenschmidt wrote:
> This adds base support for the Katmai board, including PCI-X and
> PCI-Express (but no RTC, nvram, etc... yet).
Please see comments below.
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
>
> As for Taishan, the bootwrapper code can be simplified. In fact,
> we probably don't need to probe clocks & memsize off the chip and
> just trust what uboot tells us.
>
> arch/powerpc/boot/44x.h |1
> arch/powerpc/boot/Makefile |7
> arch/powerpc/boot/cuboot-katmai.c | 35 +++
> arch/powerpc/boot/dts/katmai.dts| 392
> arch/powerpc/boot/katmai.c |
> 64 +
> arch/powerpc/platforms/44x/Kconfig | 12 +
> arch/powerpc/platforms/44x/Makefile |3
> arch/powerpc/platforms/44x/katmai.c | 63 +
> 8 files changed, 574 insertions(+), 3 deletions(-)
>
> Index: linux-work/arch/powerpc/platforms/44x/Kconfig
> ===
> --- linux-work.orig/arch/powerpc/platforms/44x/Kconfig2007-11-30
> 13:51:48.0 +1100 +++
> linux-work/arch/powerpc/platforms/44x/Kconfig 2007-11-30 13:51:48.0
> +1100 @@ -30,6 +30,14 @@ config TAISHAN
> help
> This option enables support for the IBM PPC440GX "Taishan" evaluation
> board.
>
> +config KATMAI
> + bool "Katmai"
> + depends on 44x
> + default n
> + select 440SPe
> + help
> + This option enables support for the AMCC PPC440SPe evaluation board.
> +
> #config LUAN
> #bool "Luan"
> #depends on 44x
> @@ -74,6 +82,10 @@ config 440GX
> config 440SP
> bool
>
> +config 440SPe
> +select IBM_NEW_EMAC_EMAC4
> + bool
> +
> # 44x errata/workaround config symbols, selected by the CPU models above
> config IBM440EP_ERR42
> bool
> Index: linux-work/arch/powerpc/platforms/44x/Makefile
> ===
> --- linux-work.orig/arch/powerpc/platforms/44x/Makefile 2007-11-30
> 13:51:48.0 +1100 +++
> linux-work/arch/powerpc/platforms/44x/Makefile2007-11-30
> 13:51:48.0 +1100 @@ -1,5 +1,6 @@
> obj-$(CONFIG_44x):= misc_44x.o
> obj-$(CONFIG_EBONY) += ebony.o
> obj-$(CONFIG_TAISHAN)+= taishan.o
> -obj-$(CONFIG_BAMBOO) += bamboo.o
> +obj-$(CONFIG_BAMBOO) += bamboo.o
> obj-$(CONFIG_SEQUOIA)+= sequoia.o
> +obj-$(CONFIG_KATMAI) += katmai.o
> Index: linux-work/arch/powerpc/boot/dts/katmai.dts
> ===
> --- /dev/null 1970-01-01 00:00:00.0 +
> +++ linux-work/arch/powerpc/boot/dts/katmai.dts 2007-11-30
> 14:46:02.0 +1100 @@ -0,0 +1,392 @@
> +/*
> + * Device Tree Source for AMCC Bamboo
> + *
> + * Copyright (c) 2006, 2007 IBM Corp.
> + * Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> + *
> + * Copyright (c) 2006, 2007 IBM Corp.
> + * Josh Boyer <[EMAIL PROTECTED]>
> + *
> + * FIXME: Draft only!
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without
> + * any warranty of any kind, whether express or implied.
> + */
> +
> +/ {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + model = "amcc,katmai";
> + compatible = "amcc,katmai";
> + dcr-parent = <&/cpus/PowerPC,[EMAIL PROTECTED]>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,[EMAIL PROTECTED] {
> + device_type = "cpu";
> + reg = <0>;
> + clock-frequency = <0>; /* Filled in by zImage */
> + timebase-frequency = <0>; /* Filled in by zImage */
> + i-cache-line-size = <20>;
> + d-cache-line-size = <20>;
> + i-cache-size = <2>;
> + d-cache-size = <2>;
> + dcr-controller;
> + dcr-access-method = "native";
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0 0 0>; /* Filled in by zImage */
> + };
> +
> + UIC0: interrupt-controller0 {
> + compatible = "ibm,uic-440spe","ibm,uic";
> + interrupt-controller;
> + cell-index = <0>;
> + dcr-reg = <0c0 009>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + #interrupt-cells = <2>;
> + };
> +
> + UIC1: interrupt-controller1 {
> + compatible = "ibm,uic-440spe","ibm,uic";
> + interrupt-controller;
> + cell-index = <1>;
> + dcr-reg = <0d0 009>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + #interrupt-cells = <2>;
> + interrupts = <1e 4 1f 4>; /* cascade */
> + inter
Re: [PATCH 24/24] powerpc: Base support for 440SPe "Katmai" eval board
On Sunday 02 December 2007, Stefan Roese wrote:
> > + PCIE0: [EMAIL PROTECTED] {
> > + device_type = "pci";
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > + compatible = "ibm,plb-pciex-440speB", "ibm,plb-pciex";
> > + primary;
> > + port = <0>; /* port number */
>
> port = <1>;
Ups, sorry. <0> is correct here of course. "PCIE1" and "PCIE2" need different
numbers though.
> > + reg = > */
> > + c 1000 1000>;/* Registers */
> > + dcr-reg = <100 020>;
> > + sdr-base = <300>;
> > +
> > + /* Outbound ranges, one memory and one IO,
> > +* later cannot be changed
> > +*/
> > + ranges = <0200 0 8000 000e 0
> > 8000
> > + 0100 0 000f 8000 0
> > 0001>;
> > +
> > + /* Inbound 2GB range starting at 0 */
> > + dma-ranges = <4200 0 0 0 0 0 8000>;
> > +
> > + /* This drives busses 10 to 0x1f */
> > + bus-range = <10 1f>;
> > +
> > + /* Legacy interrupts (note the weird polarity). We are
> > +* de-swizzling here because the numbers are actually
> > for
> > +* port of the root complex virtual P2P bridge. But I
> > want
> > +* to avoid putting a node for it in the tree, so the
> > numbers
> > +* below are basically de-swizzled numbers. The real
> > slot is
> > +* on idsel 1, so the swizzling is new_pin = (pin % 4)
> > + 1
> > +*/
> > + interrupt-map-mask = < 0 0 7>;
> > + interrupt-map = <
> > + 0 0 2 &UIC3 0 4 /* swizzled int A */
> > + 0 0 3 &UIC3 1 4 /* swizzled int B */
> > + 0 0 4 &UIC3 2 4 /* swizzled int C */
> > + 0 0 1 &UIC3 3 4 /* swizzled int D */>;
> > + };
> > +
> > + PCIE1: [EMAIL PROTECTED] {
> > + device_type = "pci";
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > + compatible = "ibm,plb-pciex-440speB", "ibm,plb-pciex";
> > + primary;
> > + port = <0>; /* port number */
>
> port = <2>;
That should be <1> now. And PCIE2 has this problem too.
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 12/24] powerpc: 4xx PLB to PCI Express support
Hi Ben,
On Friday 30 November 2007, Benjamin Herrenschmidt wrote:
> This adds to the previous 2 patches the support for the 4xx PCI Express
> cells as found in the 440SPe revA, revB and 405EX.
>
> Unfortunately, due to significant differences between these, and other
> interesting "features" of those pieces of HW, the code isn't as simple
> as it is for PCI and PCI-X and some of the functions differ significantly
> between the 3 implementations. Thus, not only this code can only support
> those 3 implementations for now and will refuse to operate on any other,
> but there are added ifdef's to avoid the bloat of building a fairly large
> amount of code on platforms that don't need it.
>
> Also, this code currently only supports fully initializing root complex
> nodes, not endpoint. Some more code will have to be lifted from the
> arch/ppc implementation to add the endpoint support, though it's mostly
> differences in memory mapping, and the question on how to represent
> endpoint mode PCI in the device-tree is thus open.
>
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
>
> 440SPeA is untested, 440SPeB is slightly tested (with a sky2 network card
> on port 0 only for now) and 405EX is untested.
As already mentioned I'm experiencing some problems with this current version.
At least what's available in Josh's 2.6.25-candidates branch. The kernel
crashes in the first ppc4xx_pciex_read_config() call upon (after I fixed the
small problem mentioned further down below):
BUG_ON(hose != port->hose);
So before digging into this deeper, I wanted to check if you don't have a
slightly "better" version which passed your tests with the sky2 PCIe card.
One further comment below.
> arch/powerpc/Kconfig |1
> arch/powerpc/sysdev/Kconfig |8
> arch/powerpc/sysdev/ppc4xx_pci.c | 927
> ++- arch/powerpc/sysdev/ppc4xx_pci.h |
> 237 +
> 4 files changed, 1172 insertions(+), 1 deletion(-)
>
> Index: linux-work/arch/powerpc/sysdev/ppc4xx_pci.c
> +static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port
> *port) +{
> + struct resource dma_window;
> + struct pci_controller *hose = NULL;
> + const int *bus_range;
> + int primary, busses;
> + void __iomem *mbase = NULL, *cfg_data = NULL;
> +
> + /* XXX FIXME: Handle endpoint mode properly */
> + if (port->endpoint)
> + return;
> +
> + /* Check if primary bridge */
> + if (of_get_property(port->node, "primary", NULL))
> + primary = 1;
> +
> + /* Get bus range if any */
> + bus_range = of_get_property(port->node, "bus-range", NULL);
> +
> + /* Allocate the host controller data structure */
> + hose = pcibios_alloc_controller(port->node);
> + if (!hose)
> + goto fail;
> +
> + /* We stick the port number in "indirect_type" so the config space
> + * ops can retrieve the port data structure easily
> + */
> + hose->indirect_type = port->index;
> +
> + /* Get bus range */
> + hose->first_busno = bus_range ? bus_range[0] : 0x0;
> + hose->last_busno = bus_range ? bus_range[1] : 0xff;
> +
> + /* Because of how big mapping the config space is (1M per bus), we
> + * limit how many busses we support. In the long run, we could replace
> + * that with something akin to kmap_atomic instead. We set aside 1 bus
> + * for the host itself too.
> + */
> + busses = hose->last_busno - hose->first_busno; /* This is off by 1 */
> + if (busses > MAX_PCIE_BUS_MAPPED) {
> + busses = MAX_PCIE_BUS_MAPPED;
> + hose->last_busno = hose->first_busno + busses;
> + }
> +
> + /* We map the external config space in cfg_data and the host config
> + * space in cfg_addr. External space is 1M per bus, internal space
> + * is 4K
> + */
> + cfg_data = ioremap(port->cfg_space.start +
> + (hose->first_busno + 1) * 0x10,
> + busses * 0x10);
> + mbase = ioremap(port->cfg_space.start + 0x1000, 0x1000);
> + if (cfg_data == NULL || mbase == NULL) {
> + printk(KERN_ERR "%s: Can't map config space !",
> +port->node->full_name);
> + goto fail;
> + }
> +
> + hose->cfg_data = cfg_data;
> + hose->cfg_addr = mbase;
> +
> +#ifdef CONFIG_40x
> + /*
> + * 405EX needs this offset in the PCIe config cycles
> + * need a little more debugging to see if this can be handled
> + * differently. sr, 2007-10
> + */
> + if (of_device_is_compatible(port->node, "ibm,plb-pciex-405ex"))
> + hose->cfg_data -= 0x8000;
> +#endif /* CONFIG_40x */
> +
> + pr_debug("PCIE %s, bus %d..%d\n", port->node->full_name,
> + hose->first_busno, hose->last_busno);
> + pr_debug(" config space mapped at: root @0x%p, other @0x%p\n",
> +
Re: [PATCH 12/24] powerpc: 4xx PLB to PCI Express support
On Sun, 2 Dec 2007 13:32:28 +0100 Stefan Roese <[EMAIL PROTECTED]> wrote: > Hi Ben, > > On Friday 30 November 2007, Benjamin Herrenschmidt wrote: > > This adds to the previous 2 patches the support for the 4xx PCI Express > > cells as found in the 440SPe revA, revB and 405EX. > > > > Unfortunately, due to significant differences between these, and other > > interesting "features" of those pieces of HW, the code isn't as simple > > as it is for PCI and PCI-X and some of the functions differ significantly > > between the 3 implementations. Thus, not only this code can only support > > those 3 implementations for now and will refuse to operate on any other, > > but there are added ifdef's to avoid the bloat of building a fairly large > > amount of code on platforms that don't need it. > > > > Also, this code currently only supports fully initializing root complex > > nodes, not endpoint. Some more code will have to be lifted from the > > arch/ppc implementation to add the endpoint support, though it's mostly > > differences in memory mapping, and the question on how to represent > > endpoint mode PCI in the device-tree is thus open. > > > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > > --- > > > > 440SPeA is untested, 440SPeB is slightly tested (with a sky2 network card > > on port 0 only for now) and 405EX is untested. > > As already mentioned I'm experiencing some problems with this current > version. > At least what's available in Josh's 2.6.25-candidates branch. The kernel > crashes in the first ppc4xx_pciex_read_config() call upon (after I fixed the > small problem mentioned further down below): > > BUG_ON(hose != port->hose); > > So before digging into this deeper, I wanted to check if you don't have a > slightly "better" version which passed your tests with the sky2 PCIe card. These should be the latest versions that Ben sent out. I plan on applying newer versions to that branch as they come out, which means the git branch will probably reset often for a bit. I have some other patches I want to pull into there as well anyway. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] OF-platform PATA driver
On Sun, Dec 02, 2007 at 02:46:17PM +0300, Anton Vorontsov wrote:
> On Sat, Dec 01, 2007 at 09:57:55PM -0600, Olof Johansson wrote:
> > On Sun, Dec 02, 2007 at 02:58:10AM +0300, Anton Vorontsov wrote:
> > > On Sat, Dec 01, 2007 at 05:54:49PM -0500, Jeff Garzik wrote:
> > > while (1) {
> > > send_patches();
> > >
> > > if (ack_collected(PaulM) && ack_collected(PowerPC_people))
> > > break;
> > >
> > > sleep(wait_for_comments_timeout); <-- currently here.
> >
> > I still haven't seen you address the compatible comments (that
> > pata-platform is suboptimal). Or did I miss some respin of the patches?
>
> I didn't resend these patches yet. You started the thread, but you hid
> away from the discussion (you had been Cc'ed to every mail).
>
> 1. Arnd suggested {p,s}ata-pio-{1,2,3,..} or ata-{1,2,3,..} compatible
>scheme;
> 2. Sergei verbosely explained that that there is no reason to
>complicate compatible property. He suggested ata-generic, or
>ata-simple;
>
> Mainly I was awaiting for your further comments. By now I tend to
> follow Sergei's comments and rename compatible stuff to ata-generic.
> Are you fine with it?
Ah, sorry about that. The discussion got a bit noisy so I tuned it out.
Yes, I agree with Sergei: I don't think the pio/ata mode belongs there,
"ata-generic" (or "generic-ata") sounds good to me. If firmwares want to
specify pata/sata stuff as more specific compatible fields, then they are
free to, but the driver shouldn't depend on it as long as "ata-generic"
is in the list.
ATA/PIO modes could be communicated with separate properties as well,
but I don't see a need for it right now. Tuning PIO modes normally
involves changing bus parameters/cycle times, etc, and that' hardly
generic enough to be handled by this driver in the first place.
I will need to add a compatible field to it myself (our firmware uses
"electra-ide") + some minor changes, but I will do that on top of this
patch once it goes in since it involves removing the old code from
arch/powerpc/platforms/pasemi.
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.24-rc3-mm2 kernel bug on nfs & cifs mounted partitions
Jan Kara wrote:
> On Thu 29-11-07 17:27:08, Kamalesh Babulal wrote:
>> Andrew Morton wrote:
>>> On Thu, 29 Nov 2007 14:30:14 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
>>> wrote:
>>>
Hi Andrew,
While running file system stress on nfs and cifs mounted partitions, the
machine
drops to xmon
1:mon> e
cpu 0x1: Vector: 300 (Data Access) at [c00080a9f880]
pc: c01392c8: .inotify_inode_queue_event+0x50/0x158
lr: c01074d0: .vfs_link+0x204/0x298
sp: c00080a9fb00
msr: 80009032
dar: 280
dsisr: 4001
current = 0xc000c8e6f670
paca= 0xc0512c00
pid = 2848, comm = fsstress
1:mon> t
[c00080a9fbd0] c01074d0 .vfs_link+0x204/0x298
[c00080a9fc70] c010b6e0 .sys_linkat+0x134/0x1b4
[c00080a9fe30] c000872c syscall_exit+0x0/0x40
--- Exception: c00 (System Call) at 0ff1bdfc
SP (ffeaed10) is in userspace
1:mon> r
R00 = c01074d0 R16 =
R01 = c00080a9fb00 R17 =
R02 = c060c380 R18 =
R03 = R19 =
R04 = 0004 R20 =
R05 = R21 =
R06 = R22 =
R07 = R23 = 0004
R08 = R24 = 0280
R09 = R25 = f000
R10 = 0001 R26 = c00082827790
R11 = c03963e8 R27 = c000828275a0
R12 = d0deec78 R28 =
R13 = c0512c00 R29 = c0007b18fcf0
R14 = R30 = c05bc088
R15 = R31 =
pc = c01392c8 .inotify_inode_queue_event+0x50/0x158
lr = c01074d0 .vfs_link+0x204/0x298
msr = 80009032 cr = 24000882
ctr = c03963e8 xer = trap = 300
dar = 0280 dsisr = 4001
The gdb output shows
0xc01076d4 is in vfs_symlink (include/linux/fsnotify.h:108).
103 * fsnotify_create - 'name' was linked in
104 */
105 static inline void fsnotify_create(struct inode *inode, struct
dentry *dentry)
106 {
107 inode_dir_notify(inode, DN_CREATE);
108 inotify_inode_queue_event(inode, IN_CREATE, 0,
dentry->d_name.name,
109 dentry->d_inode);
110 audit_inode_child(dentry->d_name.name, dentry, inode);
111 }
112
>>> If it is reproducible can you please try reverting
>>> inotify-send-in_attrib-events-when-link-count-changes.patch?
>> Hi Andrew,
>>
>> reverting the patch
>> inotify-send-in_attrib-events-when-link-count-changes.patch, the
>> bug is not reproduced.
> OK, it's a problem with CIFS. Its cifs_hardlink() function doesn't call
> d_instantiate() and thus returns a dentry with d_inode set to NULL. I'm not
> sure if such behavior is really correct but anyway, attached is a new
> version of the patch which should handle it gracefully. Kamalesh, can you
> please give it a try? Thanks.
>
> Honza
Hi Jan,
Thanks, the patch fixes the bug.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] [POWERPC] Use new machine_xxx_initcall hooks in platform code
On Sat, Dec 01, 2007 at 11:10:33PM -0700, Grant Likely wrote: > From: Grant Likely <[EMAIL PROTECTED]> > > This patch makes the platform code use the new machine-specific initcall > hooks. This has the advantage of not needing to explicitly test > machine_is() at the top of every initcall function. > > Signed-off-by: Grant Likely <[EMAIL PROTECTED]> PA Semi parts: Acked-by: Olof Johansson <[EMAIL PROTECTED]> Overall I approve of the approach as well, looks like a good idea. I tried building all defconfigs, they pass. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 12/24] powerpc: 4xx PLB to PCI Express support
On Sun, 2007-12-02 at 13:32 +0100, Stefan Roese wrote: > As already mentioned I'm experiencing some problems with this current > version. > At least what's available in Josh's 2.6.25-candidates branch. The > kernel > crashes in the first ppc4xx_pciex_read_config() call upon (after I > fixed the > small problem mentioned further down below): > > BUG_ON(hose != port->hose); > > So before digging into this deeper, I wanted to check if you don't > have a > slightly "better" version which passed your tests with the sky2 PCIe > card. Yup, looks I forgot a quilt ref or something. I'll check. I'll also give port 1 and 2 a go (after fixing the DT). I also want to change the config space code to use some fixmap type direct mapping/unmapping to remove bus number limitations as soon as Kumar has implemented the fixmap stuff, since he seems to be working on it now. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 12/24] powerpc: 4xx PLB to PCI Express support
On Sunday 02 December 2007, Benjamin Herrenschmidt wrote: > > So before digging into this deeper, I wanted to check if you don't > > have a > > slightly "better" version which passed your tests with the sky2 PCIe > > card. > > Yup, looks I forgot a quilt ref or something. I'll check. I'll also give > port 1 and 2 a go (after fixing the DT). > > I also want to change the config space code to use some fixmap type > direct mapping/unmapping to remove bus number limitations as soon as > Kumar has implemented the fixmap stuff, since he seems to be working on > it now. Great, thanks. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull powerpc.git merge branch
Linus, Please do git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge There are two commits there; one reverts a patch which was causing some machines to fail to come back up when rebooting, and the other only touches a couple of defconfigs. Thanks, Paul. arch/powerpc/kernel/rtas.c | 12 ++-- arch/powerpc/platforms/pseries/setup.c |3 +-- arch/ppc/configs/ml300_defconfig |2 +- arch/ppc/configs/ml403_defconfig |2 +- include/asm-powerpc/rtas.h |3 +-- 5 files changed, 10 insertions(+), 12 deletions(-) Grant Likely (1): [POWERPC] Remove xmon from ml300 and ml403 defconfig in arch/ppc Paul Mackerras (1): Revert "[POWERPC] Fix RTAS os-term usage on kernel panic" ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] OF-platform PATA driver
On Sunday 02 December 2007, Olof Johansson wrote: > Yes, I agree with Sergei: I don't think the pio/ata mode belongs there, > "ata-generic" (or "generic-ata") sounds good to me. If firmwares want to > specify pata/sata stuff as more specific compatible fields, then they are > free to, but the driver shouldn't depend on it as long as "ata-generic" > is in the list. Yes, that makes sense. Let me just make it clear that I no longer think we should have the PIO mode or the ATA level in the compatible property. The PIO modes should really have their own property, if any, and the ATA standard would need to be a property of the attached device, not a property of the controller. I can see a point in listing the ATA devices themselves in the device tree, but it's probably not really worth it for the fdt setup, since they can easily be probed at runtime. > I will need to add a compatible field to it myself (our firmware uses > "electra-ide") + some minor changes, but I will do that on top of this > patch once it goes in since it involves removing the old code from > arch/powerpc/platforms/pasemi. I'd suggest to also have electra-ide hardcoded in the driver alongside ata-generic, as a special case for backwards compatibility. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] OF-platform PATA driver
On Mon, Dec 03, 2007 at 12:40:21AM +0100, Arnd Bergmann wrote: > On Sunday 02 December 2007, Olof Johansson wrote: > > > Yes, I agree with Sergei: I don't think the pio/ata mode belongs there, > > "ata-generic" (or "generic-ata") sounds good to me. If firmwares want to > > specify pata/sata stuff as more specific compatible fields, then they are > > free to, but the driver shouldn't depend on it as long as "ata-generic" > > is in the list. > > Yes, that makes sense. Let me just make it clear that I no longer think > we should have the PIO mode or the ATA level in the compatible property. > The PIO modes should really have their own property, if any, and the ATA > standard would need to be a property of the attached device, not a property > of the controller. Right. And configuring PIO modes is something quite hardware specific, which defeats the purpose of having a "generic" driver as a catch-all for "simple" configs in the first place. If the hardware needs (much) tuning it probably makes more sense to do it as a separate driver. > I can see a point in listing the ATA devices themselves in the device tree, > but it's probably not really worth it for the fdt setup, since they > can easily be probed at runtime. If the firmware probes them and/or knows about them. It's the kind of thing that can change quite often. We don't list USB devices under the usb controllers either, since they're quite volatile and the device tree is (fairly) static on the DTS-based platforms. > > I will need to add a compatible field to it myself (our firmware uses > > "electra-ide") + some minor changes, but I will do that on top of this > > patch once it goes in since it involves removing the old code from > > arch/powerpc/platforms/pasemi. > > I'd suggest to also have electra-ide hardcoded in the driver alongside > ata-generic, as a special case for backwards compatibility. Yep, that's my plan, I'll do that when I move it over. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull powerpc.git merge branch
On Mon, 3 Dec 2007 10:12:49 +1100 Paul Mackerras <[EMAIL PROTECTED]> wrote: > Linus, > > Please do > > git pull \ > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge > > There are two commits there; one reverts a patch which was causing > some machines to fail to come back up when rebooting, and the other > only touches a couple of defconfigs. > > Thanks, > Paul. > > arch/powerpc/kernel/rtas.c | 12 ++-- > arch/powerpc/platforms/pseries/setup.c |3 +-- > arch/ppc/configs/ml300_defconfig |2 +- > arch/ppc/configs/ml403_defconfig |2 +- > include/asm-powerpc/rtas.h |3 +-- > 5 files changed, 10 insertions(+), 12 deletions(-) > > Grant Likely (1): > [POWERPC] Remove xmon from ml300 and ml403 defconfig in arch/ppc Thanks Paul. I had this one queued for you to pull, but you beat me to it. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
On Sun, Nov 25, 2007 at 03:47:12PM -0700, Grant Likely wrote:
> On 11/24/07, Stephen Neuendorffer <[EMAIL PROTECTED]> wrote:
[snip]
> > So: the mpmc generates a 'memory' node, corresponding to it's memory
> > interface. It also gets a separate entry which contains the (optional, not
> > present in this example) slave management interface (for ECC and performance
> > information), and any sdma ports. In this case, this node is [EMAIL
> > PROTECTED],
> > because there is no management interface. If a management interface was
> > present, then it would be @ the management address.
>
> I don't think this is right; but I'm not sure. I don't know what the
> best naming convention is for the case of no management interface, but
> [EMAIL PROTECTED] doesn't feel right.
>
> Segher, David; what's your opinion?
If a node is present, but has no reg property, then it should not have
a unit address either. AFAICT what you're doing here is having one
node to represent the actual memory space (/[EMAIL PROTECTED], as it should
be) and another to represent the memory controller's control
interface. That's reasonable, but the unit address of the control
interface should be the address of the control registers, not the
address of the memory. If there is no control interface, there should
be no node for it at all.
[snip]
> > The temac works similarly, although the temac itself doesn't have a slave
> > interface, so no compatible node for it. The sub nodes get the compatible
> > string for the ll_temac driver. In this case, there is only one temac port
> > active. Some of the parameters are specific to port 0, in which case the
> > parameter names (e.g. phyaddr) are generated by stripping off the complete
> > C_TEMAC0 prefix. Other parameters (e.g. phy-type) are common to both sub
> > nodes, but are duplicated to make it easier for the driver to get the
> > information out. At runtime, the driver has to follow the llink-connected
> > path to find what it is connected to, and use the dma code, or the fifo
> > code.
> >
> > the xps-ll-fifo structure is a bit simpler, with llink-connected pointing
> > to the fifo, which looks like a 'normal' peripheral.
> >
> > Points for comment:
> > 1) I don't like the "PIM3" label, which is artificial (i.e. it doesn't
> > correspond to a name in the .mhs) and not guaranteed to be unique. However,
> > in the BSP generator it seems awkward to generate path references easily in
> > a single pass. What I'd might prefer is:
> > DDR2_SDRAM: [EMAIL PROTECTED] {
> > [EMAIL PROTECTED] {
> >
> > and refer to the sdma port using something like <&DDR2_SDRAM/[EMAIL
> > PROTECTED]>, but I
> > don't think you can do that in dtc?
>
> If not, it is possible to extend the dtc syntax. Jon, David? Thoughts?
&label/relative/path is not currently allowable in dtc. I suppose
it's possible to add it, but there are complications. I'm already
making some patches to deal with lexical ambiguities in the
&/full/path syntax, and the new syntax would make things more
complicated to deal with. I'll think about it.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
On Mon, Nov 26, 2007 at 01:44:02PM -0800, Stephen Neuendorffer wrote: [snip] > > > reg = < 81c0 40 >; > > > > If these registers are addressable, then the parent needs a > > 'ranges' property. > > I thought ranges weren't necessary in a 1:1 mapping? You were misinformed. If there is no ranges property, the child nodes are not directly addressable from the bus above. If the ranges property is present, but empty, then there is an identity mapping between parent and child bus addresses. So you probably want to add ranges; to the parent node. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
On Thu, Nov 29, 2007 at 06:28:36PM +0300, Andrei Dolnikov wrote:
> Device tree source file for the Emerson Katana Qp board
>
> Signed-off-by: Andrei Dolnikov <[EMAIL PROTECTED]>
>
> ---
> katanaqp.dts | 360
> +++
> 1 files changed, 360 insertions(+)
>
> diff --git a/arch/powerpc/boot/dts/katanaqp.dts
> b/arch/powerpc/boot/dts/katanaqp.dts
> new file mode 100644
> index 000..98257a2
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/katanaqp.dts
> @@ -0,0 +1,360 @@
> +/* Device Tree Source for Emerson Katana Qp
> + *
> + * Authors: Vladislav Buzov <[EMAIL PROTECTED]>
> + * Andrei Dolnikov <[EMAIL PROTECTED]>
> + *
> + * Based on prpmc8200.dts by Mark A. Greer <[EMAIL PROTECTED]>
> + *
> + * 2007 (c) MontaVista, Software, Inc. This file is licensed under
> + * the terms of the GNU General Public License version 2. This program
> + * is licensed "as is" without any warranty of any kind, whether express
> + * or implied.
> + *
> + */
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + model = "Katana-Qp"; /* Default */
> + compatible = "emerson,Katana-Qp";
> + coherency-off;
What is this property for?
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,[EMAIL PROTECTED] {
> + device_type = "cpu";
> + reg = <0>;
> + clock-frequency = <0>; /* From U-boot */
> + bus-frequency = <0>;/* From U-boot */
> + timebase-frequency = <0>; /* From U-boot */
> + i-cache-line-size = <20>;
> + d-cache-line-size = <20>;
> + i-cache-size = <8000>;
> + d-cache-size = <8000>;
> + };
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = < >; /* Filled in by bootwrapper */
> + };
> +
> + [EMAIL PROTECTED] { /* Marvell Discovery */
> + #address-cells = <1>;
> + #size-cells = <1>;
> + model = "mv64460"; /* Default */
> + compatible = "marvell,mv64x60";
Compatible properties should not have "x" asn in 64x60 here. If
there's a suitable name for the general register interface use that,
otherwise use the specific model number of the earliest device to
implement this register interface. Later models should have a
compatible property which lists their specific model, followed by the
earlier model number with which they're compatible.
> + clock-frequency = <7f28155>;/* 133.33 MHz */
You can use to avoid the ugly hex.
> + reg = ;
> + virtual-reg = ;
> + ranges = + 9000 9000 3000/* PCI 1 MEM Space */
> + e800 e800 0400/* User FLASH: Up to
> 64Mb */
> + f810 0001/* Bridge's regs */
> + f850 f850 0004>; /* Integrated SRAM */
These ranges look kind of weird, but I'd have to think about them
harder to say something more specific.
> + [EMAIL PROTECTED] {
> + compatible = "cfi-flash";
> + reg = ; /* Default (16MB) */
> + probe-type = "CFI";
You're using the new-style binding (compatible == "cfi-flash"), so the
obsolete probe-tyope property should not be included.
> + bank-width = <4>;
> +
> + [EMAIL PROTECTED] {
> + label = "Primary Monitor";
> + reg = <0 10>; /* 1Mb */
> + read-only;
> + };
> +
> + [EMAIL PROTECTED] {
> + label = "Primary Kernel";
> + reg = <10 20>; /* 2 Mb */
> + };
> +
> + [EMAIL PROTECTED] {
> + label = "Primary FS";
> + reg = <30 d0>; /* 13 Mb */
> + };
> +
> + };
> +
> + mdio {
There must be some way of actuall accessing the mdio bus, so this node
ought to have a 'reg' property and unit address.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "marvell,mv64x60-mdio";
> + [EMAIL PROTECTED] {
> + block-index = <0>;
> + compatible = "marvell,mv88e";
> + reg = ;
> + };
> + [EMAIL PROTECTED] {
> + compatible = "marvell,mv88e";
> + block-in
Re: [PATCH] Add IPIC MSI interrupt support
On Fri, Nov 30, 2007 at 11:48:39AM +0800, Li Li wrote:
> The IPIC MSI is introduced on MPC837x chip.
> Implements the IPIC MSI as two level interrupt controller.
>
> Signed-off-by: Tony Li <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/mpc8377_mds.dts | 14 ++
> arch/powerpc/boot/dts/mpc8378_mds.dts | 14 ++
> arch/powerpc/boot/dts/mpc8379_mds.dts | 14 ++
> arch/powerpc/platforms/83xx/Kconfig |6 +
> arch/powerpc/platforms/83xx/mpc837x_mds.c | 11 +
> arch/powerpc/sysdev/Makefile |1 +
> arch/powerpc/sysdev/ipic_msi.c| 359
> +
> include/asm-powerpc/ipic_msi.h| 54 +
> 8 files changed, 473 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/sysdev/ipic_msi.c
> create mode 100644 include/asm-powerpc/ipic_msi.h
>
> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
> b/arch/powerpc/boot/dts/mpc8377_mds.dts
> index 1f7819e..1068fe2 100644
> --- a/arch/powerpc/boot/dts/mpc8377_mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
> @@ -210,6 +210,20 @@
> #interrupt-cells = <2>;
> reg = <700 100>;
> };
> +
> + [EMAIL PROTECTED] {
> + compatible = "fsl,ipic-msi";
> + reg = <7c0 40>;
> + interrupts = < 43 8
> +4 8
> +51 8
> +52 8
> +56 8
> +57 8
> +58 8
> +59 8 >;
> + interrupt-parent = < &ipic >;
> + };
I'm not sure why the MSI needs a device node of its own. What actual
piece of hardware is this representing?
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: make 64K huge pages more reliable
On Tue, Nov 27, 2007 at 11:03:16PM -0600, Jon Tollefson wrote: > This patch adds reliability to the 64K huge page option by making use of > the PMD for 64K huge pages when base pages are 4k. So instead of a 12 > bit pte it would be 7 bit pmd and a 5 bit pte. The pgd and pud offsets > would continue as 9 bits and 7 bits respectively. This will allow the > pgtable to fit in one base page. This patch would have to be applied > after part 1. Hrm.. shouldn't we just ban 64K hugepages on a 64K base page size setup? There's not a whole lot of point to it, after all... -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx SATA device tree nodes
> -Original Message-
> From: Kumar Gala [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 21, 2007 1:13 PM
> To: linuxppc-dev@ozlabs.org
> Cc: Segher Boessenkool; Li Yang
> Subject: [PATCH 1/3] [POWERPC] Add docs for Freescale 83xx
> SATA device tree nodes
>
> ---
> Documentation/powerpc/booting-without-of.txt | 23
> +++
> 1 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt
> b/Documentation/powerpc/booting-without-of.txt
> index e9a3cb1..eb14dd5 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2514,6 +2514,29 @@ platforms are moved over to use the
> flattened-device-tree model.
>Requred properties:
> - current-speed : Baud rate of uartlite
>
> +* Freescale 8xxx/3.0 Gb/s SATA nodes
> +
> +SATA nodes are defined to describe on-chip Serial ATA
> controllers.
> +Each SATA port should have its own node.
> +
> +Required properties:
> +- compatible: compatible list, contains 2
> entries, first is
> + "fsl,sata-CHIP", where CHIP is the processor
Should be "fsl,CHIP-sata"
> + (mpc8315, mpc8379, etc.) and the second is
> + "fsl,sata-pq2pro"
Why not use "pq2pro-sata" to be consistent with the CHIP version?
> +- interrupts:
> +- interrupt-parent : optional, if needed for interrupt mapping
> +- reg :
> +
> + Example:
> +
> + [EMAIL PROTECTED] {
> + compatible = "fsl,mpc8315-sata", "fsl,sata-pq2pro;
Quotation mark missing.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Xilinx EDK BSP generation of device trees for microblaze and PowerPC
Bah; I wrote this email about a week ago, but never sent it. Sorry.
g.
On 11/26/07, Stephen Neuendorffer <[EMAIL PROTECTED]> wrote:
>
> I've pushed the current state up to
> git://git.xilinx.com/gen-mhs-devtree.git for your perusing. Comments
> below.
>
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > Behalf Of Grant Likely
> > Sent: Sunday, November 25, 2007 2:47 PM
> > To: Stephen Neuendorffer; Segher Boessenkool; David Gibson;
> > Jon Loeliger
> > Cc: [EMAIL PROTECTED];
> > linuxppc-dev@ozlabs.org; Michal Simek; git
> > Subject: Re: Xilinx EDK BSP generation of device trees for
> > microblaze and PowerPC
> >
> > On 11/24/07, Stephen Neuendorffer
> > <[EMAIL PROTECTED]> wrote:
> > >
> >
> > Thanks for all this work; comments below.
> >
> > >
> > > Here's what I've gotten so far:
> > >
> > > Hard_Ethernet_MAC: [EMAIL PROTECTED] {
> > > #address-cells = <1>;
> > > #size-cells = <1>;
> > > [EMAIL PROTECTED] {
> > > compatible =
> > "xlnx,xps-ll-temac-1.00.a",
> > > "xlnx,xps-ll-temac";
> >
> > Drop "xlnx,xps-ll-temac"; it's 100% made up. This should be simply:
> > compatible = "xlnx,xps-ll-temac-1.00.a" for version 1.00.a and
> > compatible =
> > "xlnx,xps-ll-temac-","xlnx,xps-ll-temac-1.00.a" for a future
> > version if it maintains register level compatibility.
> >
> > "xlnx,xps-ll-temac" is far to ambiguous.
>
> What if it was: compatible = "xlnx,xps-ll-temac-1.00.a",
> "xlnx,xps-ll-temac-1"?
Here's what I've learned: There is no such thing as a perfect device
tree. Either hardware bugs will be discovered at a later date which
make compatible inaccurate, or a better understanding of the device
will come along which will change the understood best practices for
describing the device.
My opinion is the best strategy against claiming something that's not
true, or won't be true in the fucture, is to strive for uniqueness and
describe only what you are certain of. Be conservative instead of
liberal in the compatible case; ie. it's easier to teach the driver
about other versions it can bind against than it is to teach it about
exceptions to certain versions of the hardware (when binding).
In this particular case the problem still stands that the VHDL
engineer may make a non backward compatible change in version
xlnx,xps-ll-temac-1.00.c or -1.03.c. You just don't know until it
happens. Stick with what is known and don't try to extrapolate to a
'generic' version when there is no guarantee that it will remain
generic.
When sticking with real version numbers, it is quite safe to claim
compatibility with an older version number because you've probably
tested it; something which isn't so safe when you attempt to make up
generic versions.
>
> Basically, I don't want to be responsible for declaring what versions of
> IP are backward compatible with ll-temac-1.00.a, and I think it's bad
> software design to put that list into the dts generator anyway. In
> theory, at least, all ip with the same major version should be
> compatible.
Yes, but at the point of releasing, you've probably tested it so the
risk is very low.
>
> > > interrupt-parent = <&xps_intc_0>;
> > > interrupts = < 3 0 >;
> > > llink-connected = <&PIM3>;
> >
> > What's this property for?
>
> So that the ll_temac knows whether to use dma or fifo code and where the
> dma or fifo control/interrupts are.
>
> >
> > > reg = < 81c0 40 >;
> >
> > If these registers are addressable, then the parent needs a
> > 'ranges' property.
>
> I thought ranges weren't necessary in a 1:1 mapping?
At the very least there needs to be an empty 'ranges' property in
order for it to work
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[EMAIL PROTECTED]
(403) 399-0195
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PPC BOOT] Create otheros.bld next to specified output file, not in $object directory.
The bootwrapper script currently generates an 'otheros.bld' file in
addition to the file specified by the -o option, when asked to build a
wrapper for PS3.
It should do that in the same directory as the output, not the directory
where the wrapper objects are kept (which might potentially not be
writable when the script runs).
Arguably, the 'otheros.bld' ought to be created with the filename
specified as the -o argument. But that's a more intrusive change.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -287,8 +289,6 @@ ps3)
overlay_dest="256"
overlay_size="256"
-rm -f "$object/otheros.bld"
-
${CROSS}objcopy -O binary "$ofile" "$ofile.bin"
dd if="$ofile.bin" of="$ofile.bin" conv=notrunc \
@@ -299,6 +299,8 @@ ps3)
skip=$system_reset_overlay seek=$overlay_dest \
count=$overlay_size bs=1
-gzip --force -9 --stdout "$ofile.bin" > "$object/otheros.bld"
+odir="$(dirname "$ofile.bin")"
+rm -f "$odir/otheros.bld"
+gzip --force -9 --stdout "$ofile.bin" > "$odir/otheros.bld"
;;
esac
--
dwmw2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PPC BOOT] Find device-tree source file in default directory.
If a .dts file is given to the bootwrapper script without a full path name, look in a sensible place for it. Signed-off-by: David Woodhouse <[EMAIL PROTECTED]> --- a/arch/powerpc/boot/wrapper +++ b/arch/powerpc/boot/wrapper @@ -116,6 +118,9 @@ while [ "$#" -gt 0 ]; do done if [ -n "$dts" ]; then +if [ ! -r "$dts" -a -r "$object/dts/$dts" ]; then + dts="$object/dts/$dts" +fi if [ -z "$dtb" ]; then dtb="$platform.dtb" fi -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PPC BOOT] Allow for bootwrapper utilities being in different directory to objects
It's possible that the executables which are built as helpers for the
bootwrapper stuff might end up in a different place to the intermediate
object files. Handle that.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 31147a0..ef86a70 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -45,6 +45,7 @@ CROSS=
# directory for object and other files used by this script
object=arch/powerpc/boot
+objbin=$object
# directory for working files
tmpdir=.
@@ -95,6 +96,7 @@ while [ "$#" -gt 0 ]; do
shift
[ "$#" -gt 0 ] || usage
object="$1"
+ objbin="$1"
;;
-W)
shift
@@ -246,11 +248,11 @@ fi
# post-processing needed for some platforms
case "$platform" in
pseries|chrp)
-$object/addnote "$ofile"
+$objbin/addnote "$ofile"
;;
coff)
${CROSS}objcopy -O aixcoff-rs6000 --set-start "$entry" "$ofile"
-$object/hack-coff "$ofile"
+$objbin/hack-coff "$ofile"
;;
cuboot*)
gzip -f -9 "$ofile"
@@ -259,7 +261,7 @@ cuboot*)
;;
treeboot*)
mv "$ofile" "$ofile.elf"
-$object/mktree "$ofile.elf" "$ofile" "$base" "$entry"
+$objbin/mktree "$ofile.elf" "$ofile" "$base" "$entry"
if [ -z "$cacheit" ]; then
rm -f "$ofile.elf"
fi
--
dwmw2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PPC BOOT] 'make bootwrapper_install'
This adds a 'bootwrapper_install' make target for the powerpc architecture, which installs the wrapper script, intermediate object files and device-tree sources for later use. This will then allow bootable zImages to be created other than in the context of a kernel build. Signed-off-by: David Woodhouse <[EMAIL PROTECTED]> diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 18e3271..acf3641 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -243,3 +243,51 @@ clean-kernel := vmlinux.strip vmlinux.bin clean-kernel += $(addsuffix .gz,$(clean-kernel)) # If not absolute clean-files are relative to $(obj). clean-files += $(addprefix $(objtree)/, $(clean-kernel)) + +WRAPPER_OBJDIR := /usr/lib/kernel-wrapper +WRAPPER_DTSDIR := /usr/lib/kernel-wrapper/dts +WRAPPER_BINDIR := /usr/sbin +INSTALL := install + +extra-installed:= $(patsubst $(obj)/%, $(DESTDIR)$(WRAPPER_OBJDIR)/%, $(extra-y)) +hostprogs-installed:= $(patsubst %, $(DESTDIR)$(WRAPPER_BINDIR)/%, $(hostprogs-y)) +wrapper-installed := $(DESTDIR)$(WRAPPER_BINDIR)/wrapper +dts-installed := $(patsubst $(obj)/dts/%, $(DESTDIR)$(WRAPPER_DTSDIR)/%, $(wildcard $(obj)/dts/*.dts)) + +all-installed := $(extra-installed) $(hostprogs-installed) $(wrapper-installed) $(dts-installed) + +quiet_cmd_mkdir = MKDIR $(patsubst $(INSTALL_HDR_PATH)/%,%,$@) + cmd_mkdir = mkdir -p $@ + +quiet_cmd_install= INSTALL $(patsubst $(DESTDIR)$(WRAPPER_OBJDIR)/%,%,$@) + cmd_install= $(INSTALL) -m0644 $(patsubst $(DESTDIR)$(WRAPPER_OBJDIR)/%,$(obj)/%,$@) $@ + +quiet_cmd_install_dts= INSTALL $(patsubst $(DESTDIR)$(WRAPPER_DTSDIR)/%,dts/%,$@) + cmd_install_dts= $(INSTALL) -m0644 $(patsubst $(DESTDIR)$(WRAPPER_DTSDIR)/%,$(srctree)/$(obj)/dts/%,$@) $@ + +quiet_cmd_install_exe= INSTALL $(patsubst $(DESTDIR)$(WRAPPER_BINDIR)/%,%,$@) + cmd_install_exe= $(INSTALL) -m0755 $(patsubst $(DESTDIR)$(WRAPPER_BINDIR)/%,$(obj)/%,$@) $@ + +quiet_cmd_install_wrapper = INSTALL $(patsubst $(DESTDIR)$(WRAPPER_BINDIR)/%,%,$@) + cmd_install_wrapper = $(INSTALL) -m0755 $(patsubst $(DESTDIR)$(WRAPPER_BINDIR)/%,$(srctree)/$(obj)/%,$@) $@ ;\ + sed -i $@ -e 's%^object=.*%object=$(WRAPPER_OBJDIR)%' \ + -e 's%^objbin=.*%objbin=$(WRAPPER_BINDIR)%' \ + + +$(DESTDIR)$(WRAPPER_OBJDIR) $(DESTDIR)$(WRAPPER_DTSDIR) $(DESTDIR)$(WRAPPER_BINDIR): + $(call cmd,mkdir) + +$(extra-installed) : $(DESTDIR)$(WRAPPER_OBJDIR)/% : $(obj)/% | $(DESTDIR)$(WRAPPER_OBJDIR) + $(call cmd,install) + +$(hostprogs-installed) : $(DESTDIR)$(WRAPPER_BINDIR)/% : $(obj)/% | $(DESTDIR)$(WRAPPER_BINDIR) + $(call cmd,install_exe) + +$(dts-installed) : $(DESTDIR)$(WRAPPER_DTSDIR)/% : $(srctree)/$(obj)/dts/% | $(DESTDIR)$(WRAPPER_DTSDIR) + $(call cmd,install_dts) + +$(wrapper-installed): $(DESTDIR)$(WRAPPER_BINDIR) $(srctree)/$(obj)/wrapper | $(DESTDIR)$(WRAPPER_BINDIR) + $(call cmd,install_wrapper) + +$(obj)/bootwrapper_install: $(all-installed) + diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index bd87626..f70df9b 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -167,6 +167,9 @@ boot := arch/$(ARCH)/boot $(BOOT_TARGETS): vmlinux $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@) +bootwrapper_install: + $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@) + define archhelp @echo '* zImage - Compressed kernel image (arch/$(ARCH)/boot/zImage.*)' @echo ' install - Install kernel using' -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/24] powerpc: 4xx PCI, PCI-X and PCI-Express support among others
On Fri, 2007-11-30 at 14:17 -0600, Josh Boyer wrote: > > Some of these patches are _NOT_ yet candidate for merging > > (mostly the board support ones), but you can review them and > > Josh can put them in an experimental tree. > > I've added these to the 2.6.25-candidates branch in my tree. Fixed up > the few conflicts manually. I'll expect refreshes before merging > anyway, but I'd like to get these out there for people to play with. BTW. You were telling me the other day about a problem with the clock code. It looks like the problem is a subtle difference between 440EP /440EPx and 440SPe / 440GX. The former has the EBC clock derived from the PLB clock while the later has it derived from OPB... yuck. I'm fixing that. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PPC BOOT] Create otheros.bld next to specified output file, not in $object directory.
David Woodhouse wrote: > The bootwrapper script currently generates an 'otheros.bld' file in > addition to the file specified by the -o option, when asked to build a > wrapper for PS3. > > It should do that in the same directory as the output, not the directory > where the wrapper objects are kept (which might potentially not be > writable when the script runs). Seems reasonable for installs from read-only media. > Arguably, the 'otheros.bld' ought to be created with the filename > specified as the -o argument. But that's a more intrusive change. Yes, I think it makes sense. ps3-flash-util can handle any file name, so there is no real reason to have it named otheros.bld. > Signed-off-by: David Woodhouse <[EMAIL PROTECTED]> Acked-by: Geoff Levand <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add MPC837xEMDS PCIE RC mode support
On Fri, 2007-11-30 at 22:57 +0800, Gala Kumar wrote:
>
> On Nov 30, 2007, at 3:37 AM, Li Li wrote:
>
> > On Fri, 2007-11-30 at 17:05 +0800, Gala Kumar wrote:
> > +
> > + [EMAIL PROTECTED] {
>
> I agree w/Olof. This should be [EMAIL PROTECTED]
> >
> > + interrupt-map-mask = ;
> > + msi-available-ranges = <43 4 51 52 56 57 58 59>;
> > + interrupt-map = <
> > + 0 0 1 &ipic 1 8
> > + 0 0 2 &ipic 1 8
> > + 0 0 3 &ipic 1 8
> > + 0 0 4 &ipic 1 8
> > + >;
> > + interrupt-parent = < &ipic >;
> > + interrupts = <1 8>;
> > + bus-range = <0 0>;
> > + ranges = <0200 0 A800 A800 0 1000
> > + 0100 0 B800 0
> 0080>;
> > + clock-frequency = <0>;
> > + #interrupt-cells = <1>;
> > + #size-cells = <2>;
> > + #address-cells = <3>;
> > + reg = > +a000 0800>;
>
> Shouldn't the reg size for the cfg space be 256M?
> >>>
> >>> 256M is a little too big for kernel.
> >>
> >> what do you mean too big? Aren't you losing access to some
> >> bus/dev/fn
> >> than?
> >
> > If do it standard, a 256M config space, at least 256M mem space
> and
> > 16M
> > io space are needed for each PCIE controller.
> > To allocate PCIE window, the window size only can be 512M or 1G.
> > If we choose 1G space, two PCIE controller needs 2G space.
> > We do not have 2G free physical space now. Usually, we use upper
> 128M
> > configure space. So, we have to cut down the config space.
>
> We'll cutting config space is problematic in that its a bug since
> you
> might not be able to talk to a given device.
>
> Is it possible to make the outbound window for cfg space 4k and
> change
> the region of config space its looking at?
>
I think that is possible but it means we have to reconfigure the PCIE
controller`s outbound window at every time we want do PCI config space
access in kernel. By now, all the PCIE controller is initialized on
u-boot which like PCI controller`s case.So it is a little not compatible
with the current kernel and u-boot assignment.
> > diff --git a/arch/powerpc/platforms/83xx/Kconfig
> b/arch/powerpc/
> > platforms/83xx/Kconfig
> > index 0c61e7a..00154c5 100644
> > --- a/arch/powerpc/platforms/83xx/Kconfig
> > +++ b/arch/powerpc/platforms/83xx/Kconfig
> > @@ -87,3 +87,10 @@ config PPC_MPC837x
> > select PPC_INDIRECT_PCI
> > select FSL_SERDES
> > default y if MPC837x_MDS
> > +
> > +config PPC_MPC83XX_PCIE
> > + bool "MPC837X PCI Express support"
> > + depends on PCIEPORTBUS && PPC_MPC837x
> > + default n
> > + help
> > + Enables MPC837x PCI express RC mode
>
> This should be a hidden config that is just selected by
> >> PPC_MPC837x
> instead of a choice. Also drop the depends on.
>
> >>>
> >>> In the dts file, the PCIE is default enabled. So, we should
> provide
> >>> another way to disable the PCIE.
> >>> Modify and recompile the dts is a little unkind to user.
> >>
> >> Why do you something beyond CONFIG_PCI. if you don't want PCIe
> but
> >> do
> >> want PCI the extra code for PCIe isn't going to kill you.
> >>
> >
> > Here is a little complex. The MPC837xE board needs a carrier board
> to
> > extend PCIE slot. If user does not populate carrier board onto
> > MPC837xE
> > board and do PCIE scan, the system will halt.
> > I just want to provide a easy way to disable the PCIe other than
> > modify
> > and recompile the dts.
>
> So I have to recompile the kernel for this case, that seems even
> more
> painful to the user. Can we not detect if this board isn't there
> and
> not hang?
>
Yes. you are right. But I think we lack of a mean to tell the user the
exact mean of each device node and how to edit it.
The linux menuconfig is more directed.
As Scott said and AMHO, the dts describes what we have not what we want.
If dts describes what we have, we must provide many dts files to provide
various cpu feature combinations.
> > diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h
> >> b/arch/powerpc/
> > platforms/83xx/mpc83xx.h
> > index b778cb4..2078da7 100644
> > --- a/arch/powerpc/platforms/83xx/mpc83xx.h
> > +++ b/arch/powerpc/platforms/83xx/mpc83xx.h
> > @@ -43,12 +43,18 @@
> > #define PORTSCX_PTS_UTMI 0x
> > #define PORTSCX_PTS_ULPI 0x8000
> >
> > +/* PCIE Registers */
> > +#define PEX_LTSSM_STAT 0x404
> > +#define PEX_LTSSM_STAT_L00x16
> > +#define PEX_GCLK_RATIO
Re: [PATCH] Add IPIC MSI interrupt support
Hi r64360,
A few comments below :)
On Fri, 2007-11-30 at 11:48 +0800, Li Li wrote:
> The IPIC MSI is introduced on MPC837x chip.
> Implements the IPIC MSI as two level interrupt controller.
>
> Signed-off-by: Tony Li <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/mpc8377_mds.dts | 14 ++
> arch/powerpc/boot/dts/mpc8378_mds.dts | 14 ++
> arch/powerpc/boot/dts/mpc8379_mds.dts | 14 ++
> arch/powerpc/platforms/83xx/Kconfig |6 +
> arch/powerpc/platforms/83xx/mpc837x_mds.c | 11 +
> arch/powerpc/sysdev/Makefile |1 +
> arch/powerpc/sysdev/ipic_msi.c| 359
> +
> include/asm-powerpc/ipic_msi.h| 54 +
> 8 files changed, 473 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/sysdev/ipic_msi.c
> create mode 100644 include/asm-powerpc/ipic_msi.h
>
> diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
> b/arch/powerpc/boot/dts/mpc8377_mds.dts
> index 1f7819e..1068fe2 100644
> --- a/arch/powerpc/boot/dts/mpc8377_mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
> @@ -210,6 +210,20 @@
> #interrupt-cells = <2>;
> reg = <700 100>;
> };
> +
> + [EMAIL PROTECTED] {
> + compatible = "fsl,ipic-msi";
> + reg = <7c0 40>;
> + interrupts = < 43 8
> +4 8
> +51 8
> +52 8
> +56 8
> +57 8
> +58 8
> +59 8 >;
> + interrupt-parent = < &ipic >;
> + };
> };
>
> [EMAIL PROTECTED] {
> diff --git a/arch/powerpc/boot/dts/mpc8378_mds.dts
> b/arch/powerpc/boot/dts/mpc8378_mds.dts
> index 1503ae3..f12658f 100644
> --- a/arch/powerpc/boot/dts/mpc8378_mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8378_mds.dts
> @@ -192,6 +192,20 @@
> #interrupt-cells = <2>;
> reg = <700 100>;
> };
> +
> + [EMAIL PROTECTED] {
> + compatible = "fsl,ipic-msi";
> + reg = <7c0 40>;
> + interrupts = < 43 8
> +4 8
> +51 8
> +52 8
> +56 8
> +57 8
> +58 8
> +59 8 >;
> + interrupt-parent = < &ipic >;
> + };
> };
>
> [EMAIL PROTECTED] {
> diff --git a/arch/powerpc/boot/dts/mpc8379_mds.dts
> b/arch/powerpc/boot/dts/mpc8379_mds.dts
> index cdb4426..9fe4bd2 100644
> --- a/arch/powerpc/boot/dts/mpc8379_mds.dts
> +++ b/arch/powerpc/boot/dts/mpc8379_mds.dts
> @@ -236,6 +236,20 @@
> #interrupt-cells = <2>;
> reg = <700 100>;
> };
> +
> + [EMAIL PROTECTED] {
> + compatible = "fsl,ipic-msi";
> + reg = <7c0 40>;
> + interrupts = < 43 8
> +4 8
> +51 8
> +52 8
> +56 8
> +57 8
> +58 8
> +59 8 >;
> + interrupt-parent = < &ipic >;
> + };
> };
>
> [EMAIL PROTECTED] {
> diff --git a/arch/powerpc/platforms/83xx/Kconfig
> b/arch/powerpc/platforms/83xx/Kconfig
> index 00154c5..4c51f78 100644
> --- a/arch/powerpc/platforms/83xx/Kconfig
> +++ b/arch/powerpc/platforms/83xx/Kconfig
> @@ -88,6 +88,12 @@ config PPC_MPC837x
> select FSL_SERDES
> default y if MPC837x_MDS
>
> +config IPIC_MSI
> + bool
> + depends on PCI_MSI
> + default y if PPC_MPC837x
> + default n
> +
> config PPC_MPC83XX_PCIE
> bool "MPC837X PCI Express support"
> depends on PCIEPORTBUS && PPC_MPC837x
> diff --git a/arch/powerpc/platforms/83xx/mpc837x_mds.c
> b/arch/powerpc/platforms/83xx/mpc837x_mds.c
> index 6048f1b..dbea34b 100644
> --- a/arch/powerpc/platforms/83xx/mpc837x_mds.c
> +++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c
> @@ -17,6 +17,9 @@
>
> #include
> #include
> +#if CONFIG_IPIC_MSI
> +#include
> +#endif
> #include
> #include
I'd rather you just include it unconditionally.
> @@ -84,6 +87,14 @@ static void __init mpc837x_mds_init_IRQ(void)
>* in case the boot rom changed something on us.
>*/
> ipic_set_default_priority();
> +
> +#if CONFIG_IPIC_MSI
> + np = of_find_compatible_node(NULL, NULL, "fsl,ipic-msi");
> + if (!np)
> + ret
Re: [PATCH 0/24] powerpc: 4xx PCI, PCI-X and PCI-Express support among others
On 11/30/07, Josh Boyer <[EMAIL PROTECTED]> wrote: > On Fri, 30 Nov 2007 10:11:05 -0600 > Jon Loeliger <[EMAIL PROTECTED]> wrote: > > > Olof Johansson wrote: > > > > > I normally do "quilt diff | checkpatch.pl -" when use quilt. You could > > > similarly do "git diff HEAD | checkpatch.pl -". You'd always get the > > > warning about missing signed-off-by though. > > > > So do a "git log -p | checkpatch.pl -" instead? :-) > > That sort of defeats the purpose of running checkpatch.pl _before_ you > commit things... stg show | checkpatch.pl - :-p g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/24] powerpc: 4xx PCI, PCI-X and PCI-Express support among others
On Mon, 03 Dec 2007 14:24:30 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-11-30 at 14:17 -0600, Josh Boyer wrote: > > > Some of these patches are _NOT_ yet candidate for merging > > > (mostly the board support ones), but you can review them and > > > Josh can put them in an experimental tree. > > > > I've added these to the 2.6.25-candidates branch in my tree. Fixed up > > the few conflicts manually. I'll expect refreshes before merging > > anyway, but I'd like to get these out there for people to play with. > > BTW. You were telling me the other day about a problem with the clock > code. > > It looks like the problem is a subtle difference between 440EP /440EPx > and 440SPe / 440GX. The former has the EBC clock derived from the PLB > clock while the later has it derived from OPB... yuck. Yes. > I'm fixing that. Ok. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] Use embedded dtc in kernel builds
This patch alters the kernel makefiles to build dtc from the sources embedded in the previous patch. It also changes the arch/powerpc/boot/wrapper script to use the embedded dtc, rather than expecting a copy of dtc already installed on the system. Signed-off-by: David Gibson <[EMAIL PROTECTED]> --- Previous version would screw up badly if building with O=... Fixed now. Index: working-2.6/arch/powerpc/boot/Makefile === --- working-2.6.orig/arch/powerpc/boot/Makefile 2007-10-22 13:55:49.0 +1000 +++ working-2.6/arch/powerpc/boot/Makefile 2007-12-03 15:23:08.0 +1100 @@ -108,17 +108,52 @@ $(patsubst %.S,%.o, $(filter %.S, $(src- $(obj)/wrapper.a: $(obj-wlib) FORCE $(call if_changed,bootar) -hostprogs-y:= addnote addRamDisk hack-coff mktree +hostprogs-y:= addnote addRamDisk hack-coff mktree dtc targets+= $(patsubst $(obj)/%,%,$(obj-boot) wrapper.a) extra-y:= $(obj)/wrapper.a $(obj-plat) $(obj)/empty.o \ $(obj)/zImage.lds $(obj)/zImage.coff.lds $(obj)/zImage.ps3.lds wrapper:=$(srctree)/$(src)/wrapper -wrapperbits:= $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree) \ +wrapperbits:= $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree dtc) \ $(wrapper) FORCE # +# Bits for building dtc +# DTC_GENPARSER := 1# Uncomment to rebuild flex/bison output + +dtc-objs := dtc.o flattree.o fstree.o data.o livetree.o treesource.o srcpos.o checks.o +dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o +dtc-objs := $(addprefix dtc-src/, $(dtc-objs)) + +# prerequisites on generated files needs to be explicit +$(obj)/dtc-src/dtc-parser.tab.o: $(obj)/dtc-src/dtc-parser.tab.c $(obj)/dtc-src/dtc-parser.tab.h +$(obj)/dtc-src/dtc-lexer.lex.o: $(obj)/dtc-src/dtc-lexer.lex.c $(obj)/dtc-src/dtc-parser.tab.h + +HOSTCFLAGS += -I$(src)/dtc-src/ -I$(src)/dtc-src/libfdt/ + +targets += dtc-src/dtc-parser.tab.c +targets += dtc-src/dtc-lexer.lex.c + +ifdef DTC_GENPARSER +BISON = bison +FLEX = flex + +quiet_cmd_bison = BISON $@ + cmd_bison = $(BISON) -o$@ -d $<; cp $@ [EMAIL PROTECTED] +quiet_cmd_flex = FLEX$@ + cmd_flex = $(FLEX) -o$@ $<; cp $@ [EMAIL PROTECTED] + +$(obj)/dtc-src/dtc-parser.tab.c: $(src)/dtc-src/dtc-parser.y FORCE + $(call if_changed,bison) + +$(obj)/dtc-src/dtc-parser.tab.h: $(obj)/dtc-src/dtc-parser.tab.c + +$(obj)/dtc-src/dtc-lexer.lex.c: $(src)/dtc-src/dtc-lexer.l FORCE + $(call if_changed,flex) +endif + +# # Bits for building various flavours of zImage ifneq ($(CROSS32_COMPILE),) Index: working-2.6/arch/powerpc/boot/wrapper === --- working-2.6.orig/arch/powerpc/boot/wrapper 2007-12-03 13:17:20.0 +1100 +++ working-2.6/arch/powerpc/boot/wrapper 2007-12-03 13:47:12.0 +1100 @@ -119,7 +119,7 @@ if [ -n "$dts" ]; then if [ -z "$dtb" ]; then dtb="$platform.dtb" fi -dtc -O dtb -o "$dtb" -b 0 -V 16 "$dts" +$object/dtc -O dtb -o "$dtb" -b 0 "$dts" fi if [ -z "$kernel" ]; then -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] Use embedded libfdt in the bootwrapper
Use embedded libfdt in the bootwrapper
This patch incorporates libfdt (from the source embedded in an earlier
patch) into the wrapper.a library used by the bootwrapper. This
includes adding a libfdt_env.h file, which the libfdt sources need in
order to integrate into the bootwrapper environment, and a
libfdt-wrapper.c which provides glue to connect the bootwrappers
abstract device tree callbacks to the libfdt functions.
In addition, this patch changes the various wrapper and platform files
to use libfdt functions instead of the older flatdevtree.c library.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
---
Fixed for O= builds.
Index: working-2.6/arch/powerpc/boot/Makefile
===
--- working-2.6.orig/arch/powerpc/boot/Makefile 2007-12-03 15:23:08.0
+1100
+++ working-2.6/arch/powerpc/boot/Makefile 2007-12-03 15:24:22.0
+1100
@@ -33,7 +33,7 @@ ifeq ($(call cc-option-yn, -fstack-prote
BOOTCFLAGS += -fno-stack-protector
endif
-BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
+BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
-I$(srctree)/$(src)/dtc-src/libfdt
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
@@ -46,7 +46,9 @@ zliblinuxheader := zlib.h zconf.h zutil.
$(addprefix $(obj)/,$(zlib) gunzip_util.o main.o): \
$(addprefix $(obj)/,$(zliblinuxheader)) $(addprefix
$(obj)/,$(zlibheader))
+src-libfdt := fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
+ $(addprefix dtc-src/libfdt/,$(src-libfdt)) libfdt-wrapper.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
@@ -101,8 +103,10 @@ quiet_cmd_bootar = BOOTAR $@
cmd_bootar = $(CROSS32AR) -cr [EMAIL PROTECTED] $(filter-out FORCE,$^);
mv [EMAIL PROTECTED] $@
$(patsubst %.c,%.o, $(filter %.c, $(src-boot))): %.o: %.c FORCE
+ $(Q)mkdir -p $(dir $@)
$(call if_changed_dep,bootcc)
$(patsubst %.S,%.o, $(filter %.S, $(src-boot))): %.o: %.S FORCE
+ $(Q)mkdir -p $(dir $@)
$(call if_changed_dep,bootas)
$(obj)/wrapper.a: $(obj-wlib) FORCE
Index: working-2.6/arch/powerpc/boot/libfdt_env.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ working-2.6/arch/powerpc/boot/libfdt_env.h 2007-12-03 15:23:28.0
+1100
@@ -0,0 +1,17 @@
+#ifndef _ARCH_POWERPC_BOOT_LIBFDT_ENV_H
+#define _ARCH_POWERPC_BOOT_LIBFDT_ENV_H
+
+#include
+#include
+
+typedef u32 uint32_t;
+typedef u64 uint64_t;
+
+#define fdt16_to_cpu(x)(x)
+#define cpu_to_fdt16(x)(x)
+#define fdt32_to_cpu(x)(x)
+#define cpu_to_fdt32(x)(x)
+#define fdt64_to_cpu(x)(x)
+#define cpu_to_fdt64(x)(x)
+
+#endif /* _ARCH_POWERPC_BOOT_LIBFDT_ENV_H */
Index: working-2.6/arch/powerpc/boot/bamboo.c
===
--- working-2.6.orig/arch/powerpc/boot/bamboo.c 2007-12-03 15:20:04.0
+1100
+++ working-2.6/arch/powerpc/boot/bamboo.c 2007-12-03 15:23:28.0
+1100
@@ -42,6 +42,6 @@ void bamboo_init(void *mac0, void *mac1)
platform_ops.exit = ibm44x_dbcr_reset;
bamboo_mac0 = mac0;
bamboo_mac1 = mac1;
- ft_init(_dtb_start, 0, 32);
+ fdt_init(_dtb_start);
serial_console_init();
}
Index: working-2.6/arch/powerpc/boot/cuboot-52xx.c
===
--- working-2.6.orig/arch/powerpc/boot/cuboot-52xx.c2007-12-03
15:20:04.0 +1100
+++ working-2.6/arch/powerpc/boot/cuboot-52xx.c 2007-12-03 15:23:28.0
+1100
@@ -53,7 +53,7 @@ void platform_init(unsigned long r3, uns
unsigned long r6, unsigned long r7)
{
CUBOOT_INIT();
- ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+ fdt_init(_dtb_start);
serial_console_init();
platform_ops.fixups = platform_fixups;
}
Index: working-2.6/arch/powerpc/boot/cuboot-83xx.c
===
--- working-2.6.orig/arch/powerpc/boot/cuboot-83xx.c2007-12-03
15:20:05.0 +1100
+++ working-2.6/arch/powerpc/boot/cuboot-83xx.c 2007-12-03 15:23:28.0
+1100
@@ -52,7 +52,7 @@ void platform_init(unsigned long r3, uns
unsigned long r6, unsigned long r7)
{
CUBOOT_INIT();
- ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
+ fdt_init(_dtb_start);
serial_console_init();
platform_ops.fixups = platform_fixups;
}
Index: working-2.6/arch/powerpc/boot/cuboot-85xx.c
===
--- working-2.
[PATCH] [POWERPC] pasemi: Fix module information for gpio-mdio
[POWERPC] pasemi: Fix module information for gpio-mdio
Fix up the module information for gpio-mdio, it wouldn't load
because of lacking license, and wouldn't auto-load because of missing
MODULE_DEVICE_TABLE.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/platforms/pasemi/gpio_mdio.c
b/arch/powerpc/platforms/pasemi/gpio_mdio.c
index b029804..04a8686 100644
--- a/arch/powerpc/platforms/pasemi/gpio_mdio.c
+++ b/arch/powerpc/platforms/pasemi/gpio_mdio.c
@@ -318,6 +318,7 @@ static struct of_device_id gpio_mdio_match[] =
},
{},
};
+MODULE_DEVICE_TABLE(of, gpio_mdio_match);
static struct of_platform_driver gpio_mdio_driver =
{
@@ -356,3 +357,7 @@ void gpio_mdio_exit(void)
iounmap(gpio_regs);
}
module_exit(gpio_mdio_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Olof Johansson <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Driver for MDIO over GPIO on PA Semi PWRficient-based
boards");
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] pasemi: Fix module information for gpio-mdio
Olof Johansson writes: > Fix up the module information for gpio-mdio, it wouldn't load > because of lacking license, and wouldn't auto-load because of missing > MODULE_DEVICE_TABLE. Needed for 2.6.24? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] pasemi: Fix module information for gpio-mdio
On Mon, Dec 03, 2007 at 03:46:34PM +1100, Paul Mackerras wrote: > Olof Johansson writes: > > > Fix up the module information for gpio-mdio, it wouldn't load > > because of lacking license, and wouldn't auto-load because of missing > > MODULE_DEVICE_TABLE. > > Needed for 2.6.24? It's annoying but not critical, and the workaround is simple (build it in). I've already queued it up in my for-2.6.25 git branch, that should be sufficient. Thanks, Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull pasemi.git for-2.6.25 branch
Paul, Please do: git pull \ git://git.kernel.org/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.25 For the following patches queued up for 2.6.25. All but one are PA Semi-specific (the i2c boardinfo consolidation that's a pre-req for the platform-specific one). arch/powerpc/platforms/pasemi/Kconfig |2 arch/powerpc/platforms/pasemi/Makefile|2 arch/powerpc/platforms/pasemi/cpufreq.c | 19 +- arch/powerpc/platforms/pasemi/gpio_mdio.c | 94 ++ arch/powerpc/platforms/pasemi/misc.c | 66 + arch/powerpc/platforms/pasemi/pasemi.h|6 + arch/powerpc/platforms/pasemi/powersave.S | 11 +++ arch/powerpc/platforms/pasemi/setup.c | 16 - arch/powerpc/sysdev/Makefile |1 arch/powerpc/sysdev/fsl_soc.c | 40 arch/powerpc/sysdev/i2c_of_mapping.c | 61 +++ drivers/char/hw_random/Kconfig|2 drivers/char/hw_random/pasemi-rng.c |7 -- drivers/edac/pasemi_edac.c|4 - include/asm-powerpc/i2c_of.h | 14 15 files changed, 256 insertions(+), 89 deletions(-) Olof Johansson (7): [POWERPC] pasemi: clean up mdio_gpio a bit [POWERPC] pasemi: Broaden specific references to 1682M [POWERPC] pasemi: Don't enter powersaving states from elevated astates [POWERPC] pasemi: Move cpus to hold loop before restart [POWERPC] Consolidate compatible-to-i2c_boardinfo mapping code [POWERPC] pasemi: Register i2c_board_info [POWERPC] pasemi: Fix module information for gpio-mdio Thanks, Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
for-2.6.25 branch created in powerpc.git
I have created a for-2.6.25 branch in my powerpc.git repository and added the patches listed below to it. The master branch points to the same place as the for-2.6.25 branch. Paul. Benjamin Herrenschmidt (2): [POWERPC] Cleanup SMT thread handling [POWERPC] Add xmon function to dump 44x TLB Johannes Berg (3): [POWERPC] powermac: Fix warning in time.c [POWERPC] PMU: Don't lock_kernel() [POWERPC] PMU: Remove dead code Linas Vepstas (3): [POWERPC] EEH: Work with device endpoint, always [POWERPC] EEH: Be careful when identifying "empty" slots. [POWERPC] EEH: Report errors as soon as possible Nathan Lynch (1): [POWERPC] Remove prod_processor() Stephen Rothwell (5): [POWERPC] Make global_phb_number static [POWERPC] iSeries: Mark two functions __init [POWERPC] iSeries: Declare iSeries_pci_final_fixup in pci.h [POWERPC] iSeries: Fix sparse warnings in setup.c [POWERPC] Remove redundant declaration of hose_list [EMAIL PROTECTED] (2): [POWERPC] Add missing spaces in printk formats [POWERPC] Add missing spaces in printk formats in arch/ppc arch/powerpc/kernel/isa-bridge.c|4 + arch/powerpc/kernel/pci-common.c|4 - arch/powerpc/kernel/setup-common.c | 78 +++ arch/powerpc/mm/fault.c |2 - arch/powerpc/platforms/8xx/m8xx_setup.c |2 - arch/powerpc/platforms/cell/smp.c |3 + arch/powerpc/platforms/celleb/io-workarounds.c |2 - arch/powerpc/platforms/celleb/scc_epci.c|2 - arch/powerpc/platforms/iseries/pci.c|4 + arch/powerpc/platforms/iseries/pci.h|5 + arch/powerpc/platforms/iseries/setup.c | 22 +++--- arch/powerpc/platforms/iseries/setup.h |1 arch/powerpc/platforms/powermac/time.c |2 + arch/powerpc/platforms/pseries/eeh.c|3 + arch/powerpc/platforms/pseries/eeh_driver.c | 15 ++-- arch/powerpc/platforms/pseries/plpar_wrappers.h |5 - arch/powerpc/platforms/pseries/smp.c|3 + arch/powerpc/sysdev/fsl_pci.c |2 - arch/powerpc/xmon/xmon.c| 38 +++ arch/ppc/platforms/ev64260.c|4 + drivers/macintosh/via-pmu.c | 45 - include/asm-powerpc/cputhreads.h| 71 + include/asm-powerpc/ppc-pci.h |1 23 files changed, 218 insertions(+), 100 deletions(-) create mode 100644 include/asm-powerpc/cputhreads.h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add IPIC MSI interrupt support
On Mon, 2007-12-03 at 09:52 +0800, David Gibson wrote:
> On Fri, Nov 30, 2007 at 11:48:39AM +0800, Li Li wrote:
> > The IPIC MSI is introduced on MPC837x chip.
> > Implements the IPIC MSI as two level interrupt controller.
> >
> > Signed-off-by: Tony Li <[EMAIL PROTECTED]>
> > ---
> > arch/powerpc/boot/dts/mpc8377_mds.dts | 14 ++
> > arch/powerpc/boot/dts/mpc8378_mds.dts | 14 ++
> > arch/powerpc/boot/dts/mpc8379_mds.dts | 14 ++
> > arch/powerpc/platforms/83xx/Kconfig |6 +
> > arch/powerpc/platforms/83xx/mpc837x_mds.c | 11 +
> > arch/powerpc/sysdev/Makefile |1 +
> > arch/powerpc/sysdev/ipic_msi.c| 359
> +
> > include/asm-powerpc/ipic_msi.h| 54 +
> > 8 files changed, 473 insertions(+), 0 deletions(-)
> > create mode 100644 arch/powerpc/sysdev/ipic_msi.c
> > create mode 100644 include/asm-powerpc/ipic_msi.h
> >
> > diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts
> b/arch/powerpc/boot/dts/mpc8377_mds.dts
> > index 1f7819e..1068fe2 100644
> > --- a/arch/powerpc/boot/dts/mpc8377_mds.dts
> > +++ b/arch/powerpc/boot/dts/mpc8377_mds.dts
> > @@ -210,6 +210,20 @@
> > #interrupt-cells = <2>;
> > reg = <700 100>;
> > };
> > +
> > + [EMAIL PROTECTED] {
> > + compatible = "fsl,ipic-msi";
> > + reg = <7c0 40>;
> > + interrupts = < 43 8
> > +4 8
> > +51 8
> > +52 8
> > +56 8
> > +57 8
> > +58 8
> > +59 8 >;
> > + interrupt-parent = < &ipic >;
> > + };
>
> I'm not sure why the MSI needs a device node of its own. What actual
> piece of hardware is this representing?
>
The IPIC MSI has its own registers which control the mask and ack of MSI
interrupt. Furthermore, IPIC MSI is the second level interrupt
coontorller which connected to IPIC, to compatible with IPIC OF routine
interface, we need a device node.
> --
> 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
>
- Tony
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: for-2.6.25 branch created in powerpc.git
On Mon, 2007-12-03 at 15:45 +1100, Paul Mackerras wrote: > [POWERPC] Add xmon function to dump 44x TLB That will go via jwb, there's already some updated versions of that in my tree. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
