Re: [patch 0/6] PS3 Storage Drivers for 2.6.23, take 4

2007-07-10 Thread Geert Uytterhoeven
On Wed, 4 Jul 2007, Geert Uytterhoeven wrote:
> This is the fourth submission of the new PS3 storage drivers:
>   [1] ps3: Preallocate bootmem memory for the PS3 FLASH ROM storage driver
>   [2] ps3: Storage Driver Core
>   [3] ps3: Storage device registration routines.
>   [4] ps3: Disk Storage Driver
>   [5] ps3: BD/DVD/CD-ROM Storage Driver
>   [6] ps3: FLASH ROM Storage Driver
> 
> They are based on:
>   - the current Linux kernel source tree,
>   - plus the PS3 patches already submitted by Geoff Levand on linuxppc-dev,
>   - plus the shost_priv() patch in scsi-misc (commit
> bcd92c9fbcc679ee95003083056f0441a1f474fa).
> 
> All issues raised during the previous review rounds should be fixed.
> There were no more comments after the third submission.
> 
> Paul already integrated Geoff Levand's PS3 patches and the first 3 patches
> in this series in the for-2.6.23 branch in powerpc.git.
> 
> Maintainers of block/SCSI/misc, can you please ack the last 3 patches so Paul
> can take them, too?

Ping block/SCSI/misc maintainers?

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: 2.4/2.6/ppc/powerpc/8245/8347e

2007-07-10 Thread Marc Leeman
> > I was expecting a lower DMM performance but wasn't expecting such a
> > drain on kernel/network load.
> 
> OK, to be clear: you seem to be saying that using the SLOB instead
> of the SLAB allocator results in such terrible memory fragmentation
> that network performance is degraded by large factors (2x or 5x or
> something like that, if I remember your earlier emails). Is that right?

Yep, I thought I would at least post my findings after hurracing the
list with my posts.

Well, I don't really know if it is the fragmentation that comes into
play, or if it is simply the implementation of the slob allocator that
much more inefficient in allocating free blocks of memory; but that's
about right.

> I thought I heard about some memory-defrag patches being posted.  
> What happens if these are used together with SLOB? Does one regain the
> lost performance? Perhaps maybe one gets even better performance?

In the ChangeLog of the 2.6.22, I saw something about a slub allocator
that I want to test; I'll give your suggestion a go too, though I would
not expect significant improvements: I suspect it's the slob
implementation that is slower.

But I had a small problem with my flash not being detected anymore when
quickly booting the 2.6.22, I'll look into it today, there was a note in
the ChangeLog for powerpc about this IIRC.

-- 
  greetz, marc
Better wed than dead.
Crichton - Look at the Princess - A Kiss is Just a Kiss
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [patch 0/6] PS3 Storage Drivers for 2.6.23, take 4

2007-07-10 Thread Paul Mackerras
Jens Axboe writes:

> I have no objections to the block bits, however I feel uneasy merging
> the full patchset unless patch #1 has been acked by the platform person.

I have the first 3 patches in my queue, so yes I've acked it.  It's
probably easiest if the remaining 3 go through my queue once they've
been acked - or if you prefer, you can push #4 via your tree once I've
got Linus to pull my tree.  Let me know either way.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] xilinxfb: Parameterize xilinxfb platform device registration

2007-07-10 Thread Andrei Konovalov
Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
> 
> This patch allows multiple xilinxfb devices to be registered and used
> 
> Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
> cc: Andrei Konovalov <[EMAIL PROTECTED]>
> ---

Looks OK for me.

Thanks,
Andrei

>  arch/ppc/syslib/virtex_devices.c |   38 
> +-
>  1 files changed, 25 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/ppc/syslib/virtex_devices.c 
> b/arch/ppc/syslib/virtex_devices.c
> index 83f978f..9b473cf 100644
> --- a/arch/ppc/syslib/virtex_devices.c
> +++ b/arch/ppc/syslib/virtex_devices.c
> @@ -152,6 +152,21 @@
>   }, \
>  }
>  
> +/*
> + * ML300/ML403 Video Device: shortcut macro for single instance
> + */
> +#define XPAR_TFT(num) { \
> + .name = "xilinxfb", \
> + .id = num, \
> + .num_resources = 1, \
> + .resource = (struct resource[]) { \
> + { \
> + .start = XPAR_TFT_##num##_BASEADDR, \
> + .end = XPAR_TFT_##num##_BASEADDR+7, \
> + .flags = IORESOURCE_IO, \
> + }, \
> + }, \
> +}
>  
>  /* UART 8250 driver platform data table */
>  struct plat_serial8250_port virtex_serial_platform_data[] = {
> @@ -274,20 +289,17 @@ struct platform_device virtex_platform_devices[] = {
>  #endif
>  #endif
>  
> - /* ML300/403 reference design framebuffer */
>  #if defined(XPAR_TFT_0_BASEADDR)
> - {
> - .name   = "xilinxfb",
> - .id = 0,
> - .num_resources  = 1,
> - .resource = (struct resource[]) {
> - {
> - .start  = XPAR_TFT_0_BASEADDR,
> - .end= XPAR_TFT_0_BASEADDR+7,
> - .flags  = IORESOURCE_IO,
> - },
> - },
> - },
> + XPAR_TFT(0),
> +#endif
> +#if defined(XPAR_TFT_1_BASEADDR)
> + XPAR_TFT(1),
> +#endif
> +#if defined(XPAR_TFT_2_BASEADDR)
> + XPAR_TFT(2),
> +#endif
> +#if defined(XPAR_TFT_3_BASEADDR)
> + XPAR_TFT(3),
>  #endif
>  };
>  

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 2/4] Add dma sector to mpc8641hpcn board dts

2007-07-10 Thread Zhang Wei
This patch add DMA sector to MPC8641HPCN board dts.

Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
Signed-off-by: Ebony Zhu <[EMAIL PROTECTED]>
---
 arch/powerpc/boot/dts/mpc8641_hpcn.dts |   30 ++
 1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts 
b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index 393cfdf..8a70736 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -405,5 +405,35 @@
device_type = "open-pic";
big-endian;
};
+
+   [EMAIL PROTECTED]
+   compatible = "fsl,mpc8xxx-dma";
+   reg = <21000 100>;
+   ranges = <0 21000 1000>;
+   [EMAIL PROTECTED]
+   reg = <100 80>;
+   extended;
+   interrupt-parent = <&mpic>;
+   interrupts = <14 2>;
+   };
+   [EMAIL PROTECTED]
+   reg = <180 80>;
+   extended;
+   interrupt-parent = <&mpic>;
+   interrupts = <15 2>;
+   };
+   [EMAIL PROTECTED]
+   reg = <200 80>;
+   extended;
+   interrupt-parent = <&mpic>;
+   interrupts = <16 2>;
+   };
+   [EMAIL PROTECTED]
+   reg = <280 80>;
+   extended;
+   interrupt-parent = <&mpic>;
+   interrupts = <17 2>;
+   };
+   };
};
 };
-- 
1.5.1

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 0/4] DMA engine driver for Freescale MPC8xxx processor.

2007-07-10 Thread Zhang Wei
Hi, All,

These patches are DMA engine driver for Freescale MPC8xxx processor.

They implement the DMA engine API for MEM-2-MEM data DMA transfer
and extend the DMA engine API for IO_ADDR-2-MEM and IO_ADDR-2-IO_ADDR data
transfer.

Patches:
[PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
[PATCH 2/4] Add dma sector to mpc8641hpcn board dts
[PATCH 3/4] Extend the DMA-engine API.
[PATCH 4/4] Add DMA engine driver for Freescale MPC8xxx processors.

Best Regards,
Zhang Wei


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

2007-07-10 Thread Zhang Wei
This patch adds DMA sector to Documentation/powerpc/booting-without-of.txt file.

Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
Signed-off-by: Ebony Zhu <[EMAIL PROTECTED]>
---
 Documentation/powerpc/booting-without-of.txt |   60 ++
 1 files changed, 60 insertions(+), 0 deletions(-)

diff --git a/Documentation/powerpc/booting-without-of.txt 
b/Documentation/powerpc/booting-without-of.txt
index c169299..08c619f 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1790,6 +1790,66 @@ platforms are moved over to use the 
flattened-device-tree model.
partition-names = "fs\0firmware";
};
 
+   k) DMA
+
+   This sector define DMA for dma-engine driver of Freescale
+   MPC8xxx silicon. For each DMA setor, you should define
+   channels included.
+   Please see below 'l) DMA channel' for DMA channel's definition.
+
+   Required properties:
+
+- compatible : Should be "fsl,mpc8xxx-dma"
+- reg : Offset and length of the register set for the device
+- ranges : Should be defined as specified in 1) to describe the
+   DMA controller's register.
+
+  Example:
+   [EMAIL PROTECTED]
+   compatible = "fsl,mpc8xxx-dma";
+   reg = <21000 100>;
+   ranges = <0 21000 1000>;
+   [EMAIL PROTECTED]
+   reg = <100 80>;
+   extended;
+   reserved;
+   interrupt-parent = <&mpic>;
+   interrupts = <14 2>;
+   };
+   [EMAIL PROTECTED]
+   reg = <180 80>;
+   extended;
+   reserved;
+   interrupt-parent = <&mpic>;
+   interrupts = <15 2>;
+   };
+   [EMAIL PROTECTED]
+   reg = <200 80>;
+   extended;
+   interrupt-parent = <&mpic>;
+   interrupts = <16 2>;
+   };
+   [EMAIL PROTECTED]
+   reg = <280 80>;
+   extended;
+   interrupt-parent = <&mpic>;
+   interrupts = <17 2>;
+   };
+   };
+
+   l) DMA channel
+
+   Required properties:
+
+- reg : Offset and length of the register set for the device
+
+   Recommended properties :
+
+- extended : Set the DMA channel to work at extended chain mode.
+ If not set, the DMA channel will work at basic
+ chain mode.
+- reserved : Reserve the DMA channel to device.
+
More devices will be defined as this spec matures.
 
 VII - Specifying interrupt information for devices
-- 
1.5.1

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 3/4] Extend the DMA-engine API.

2007-07-10 Thread Zhang Wei
Add channel wait queue and transfer callback dma_xfer_callback().
If the DMA controller and driver support interrupt, when the
transfer is finished, it will wakeup the wait queue
and call the callback function of the channel.

Add dma_async_raw_xfer() to API and device_raw_xfer() to struct dma_device
for RAW physical address DMA transfer, which will be used at transfer
between I/O address and memory address.

Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
---
 include/linux/dmaengine.h |   35 +++
 1 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index c94d8f1..d9dfc57 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * enum dma_event - resource PNP/power managment events
@@ -108,6 +109,8 @@ struct dma_chan {
struct list_head client_node;
struct list_head device_node;
struct dma_chan_percpu *local;
+
+   wait_queue_head_t wait_q;
 };
 
 void dma_chan_cleanup(struct kref *kref);
@@ -138,6 +141,12 @@ static inline void dma_chan_put(struct dma_chan *chan)
 typedef void (*dma_event_callback) (struct dma_client *client,
struct dma_chan *chan, enum dma_event event);
 
+/*
+ * typedef dma_xfer_callback
+ *   - function pointer to a DMA transfer callback when finished
+ */
+typedef void (*dma_xfer_callback) (struct dma_chan *chan, void *data);
+
 /**
  * struct dma_client - info on the entity making use of DMA services
  * @event_callback: func ptr to call when something happens
@@ -187,6 +196,9 @@ struct dma_device {
 
int (*device_alloc_chan_resources)(struct dma_chan *chan);
void (*device_free_chan_resources)(struct dma_chan *chan);
+   dma_cookie_t (*device_raw_xfer)(struct dma_chan *chan,
+   dma_addr_t dest, dma_addr_t src, size_t len,
+   dma_xfer_callback cb, void *data);
dma_cookie_t (*device_memcpy_buf_to_buf)(struct dma_chan *chan,
void *dest, void *src, size_t len);
dma_cookie_t (*device_memcpy_buf_to_pg)(struct dma_chan *chan,
@@ -209,6 +221,29 @@ void dma_async_client_chan_request(struct dma_client 
*client,
unsigned int number);
 
 /**
+ * dma_async_raw_xfer - transfor data between physical addresses with callback
+ * @chan: DMA channel to be used
+ * @dest: destination address (physical)
+ * @src: source address (physical)
+ * @len: length
+ */
+static inline dma_cookie_t dma_async_raw_xfer(struct dma_chan *chan,
+   dma_addr_t dest, dma_addr_t src, size_t len,
+   dma_xfer_callback cb, void *data)
+{
+   int cpu = get_cpu();
+   per_cpu_ptr(chan->local, cpu)->bytes_transferred += len;
+   per_cpu_ptr(chan->local, cpu)->memcpy_count++;
+   put_cpu();
+
+   if (chan->device->device_raw_xfer)
+   return chan->device->device_raw_xfer(chan, dest, src, len,
+   cb, data);
+   else
+   return -EPERM;
+}
+
+/**
  * dma_async_memcpy_buf_to_buf - offloaded copy between virtual addresses
  * @chan: DMA channel to offload copy to
  * @dest: destination address (virtual)
-- 
1.5.1

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 4/4] Add DMA engine driver for Freescale MPC8xxx processors.

2007-07-10 Thread Zhang Wei
This driver adopts DMA engine API, which could be used for
MEM<-->MEM, IO_ADDR<-->MEM and IO_ADDR<-->IO_ADDR data transfer.
This driver support both Basic and Extended chain mode of Freescale
MPC8xxx DMA controller.

Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
Signed-off-by: Ebony Zhu <[EMAIL PROTECTED]>
---
 drivers/dma/Kconfig  |7 +
 drivers/dma/Makefile |1 +
 drivers/dma/fsldma.c | 1074 ++
 drivers/dma/fsldma.h |  161 
 4 files changed, 1243 insertions(+), 0 deletions(-)
 create mode 100644 drivers/dma/fsldma.c
 create mode 100644 drivers/dma/fsldma.h

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 72be6c6..8102a0b 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -32,4 +32,11 @@ config INTEL_IOATDMA
---help---
  Enable support for the Intel(R) I/OAT DMA engine.
 
+config FSL_DMA
+   bool "Freescale MPC8xxx DMA support"
+   depends on DMA_ENGINE && (PPC_86xx || PPC_85xx)
+   ---help---
+ Enable support for the Freescale DMA engine. Now, it support
+ MPC8xxx processors.
+
 endmenu
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index bdcfdbd..7a28d5c 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_DMA_ENGINE) += dmaengine.o
 obj-$(CONFIG_NET_DMA) += iovlock.o
 obj-$(CONFIG_INTEL_IOATDMA) += ioatdma.o
+obj-$(CONFIG_FSL_DMA) += fsldma.o
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
new file mode 100644
index 000..f5a2a78
--- /dev/null
+++ b/drivers/dma/fsldma.c
@@ -0,0 +1,1074 @@
+/*
+ * Freescale MPC8xxx DMA Engine support
+ *
+ * Copyright (C) 2007 Freescale Semiconductor, Inc. All rights reserved.
+ *
+ * Author:
+ *   Zhang Wei <[EMAIL PROTECTED]>, Jul 2007
+ *   Ebony Zhu <[EMAIL PROTECTED]>, May 2007
+ *
+ * Description:
+ *   DMA engine driver for Freescale MPC8xxx DMA controller, such as MPC85xx,
+ *   MPC86xx.
+ *
+ * This is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "fsldma.h"
+
+#include 
+#include 
+
+static LIST_HEAD(reserved_chan_list);
+
+#define to_fsl_chan(chan) container_of(chan, struct fsl_dma_chan, common)
+#define to_fsl_desc(lh) container_of(lh, struct fsl_desc_sw, node)
+
+#define FSL_SET_EOSIE(x) (x) = cpu_to_be64(be64_to_cpu(x) | FSL_DMA_EOSIE);
+#define FSL_CLR_EOSIE(x) (x) = cpu_to_be64(be64_to_cpu(x) & ~FSL_DMA_EOSIE);
+#define FSL_SET_EOL(x)   (x) = cpu_to_be64(be64_to_cpu(x) | FSL_DMA_EOL);
+#define FSL_CLR_EOL(x)   (x) = cpu_to_be64(be64_to_cpu(x) & ~FSL_DMA_EOL);
+
+#define INSERT_LD_RING(fsl_chan, desc, ld, reg)
\
+   (desc)->hw.ld.reg = cpu_to_be64(\
+   (uint64_t)to_fsl_desc(list_ring_next(   \
+   &(desc)->node, &(fsl_chan)->ld_ring))->phys);   \
+   to_fsl_desc(list_ring_prev(&(desc)->node,   \
+   &(fsl_chan)->ld_ring))->hw.ld.reg   \
+   = cpu_to_be64((uint64_t)desc->phys);
+
+static inline int fsl_dma_idle(struct fsl_dma_chan *fsl_chan)
+{
+   return (((in_be32(&fsl_chan->reg_base->sr) & FSL_DMA_SR_CB) == 0) &&
+   ((in_be32(&fsl_chan->reg_base->mr) & FSL_DMA_MR_CC) == 0));
+}
+
+static inline void fsl_dma_start(struct fsl_dma_chan *fsl_chan)
+{
+   if (fsl_dma_idle(fsl_chan))
+   setbits32(&fsl_chan->reg_base->mr, FSL_DMA_MR_CS);
+}
+
+static inline void fsl_dma_halt(struct fsl_dma_chan *fsl_chan)
+{
+   clrbits32(&fsl_chan->reg_base->mr, FSL_DMA_MR_CS);
+}
+
+static inline struct list_head *list_ring_next(struct list_head *cur,
+   struct list_head *head)
+{
+   return (cur->next == head) ? head->next : cur->next;
+}
+
+static inline struct list_head *list_ring_prev(struct list_head *cur,
+   struct list_head *head)
+{
+   return (cur->prev == head) ? head->prev : cur->prev;
+}
+
+/* Get current list physical address from DMA register */
+static inline dma_addr_t fsl_get_cur_list_pa(struct fsl_dma_chan *fsl_chan)
+{
+   return be64_to_cpu(
+   ((uint64_t)in_be32(&fsl_chan->reg_base->eclsdar) << 32
+   | in_be32(&fsl_chan->reg_base->clsdar))
+   & FSL_DMA_NLDA_MASK);
+}
+
+/* Get current link physical address from DMA register */
+static inline dma_addr_t fsl_get_cur_link_pa(struct fsl_dma_chan *fsl_chan)
+{
+   return be64_to_cpu(
+   ((uint64_t)in_be32(&fsl_chan->reg_base->eclndar) << 32
+   | in_be32(&fsl_chan->reg_base->clndar))
+   & FSL_DMA_NLDA_MASK);
+}
+/**

Re: [PATCH] Infinite loop/always true check possible with unsigned counter.

2007-07-10 Thread Andreas Schwab
Paul Mackerras <[EMAIL PROTECTED]> writes:

> Manish Ahuja writes:
>
>> Repost to fix my email id.
>> 
>> Fix to correct a possible infinite loop or an always true check when the 
>> unsigned long counter "i" is used in
>> lmb_add_region() in the following for loop:
>> 
>> for (i = rgn->cnt-1; i >= 0; i--)
>
> Unfortunately this won't fix the bug.  Since rgn->cnt is unsigned
> long, the comparison will be done as an unsigned comparison even if i
> is signed.

??? There is no rgn->cnt involved in the comparison.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Infinite loop/always true check possible with unsigned counter.

2007-07-10 Thread Paul Mackerras
Andreas Schwab writes:
> Paul Mackerras <[EMAIL PROTECTED]> writes:
> 
> > Manish Ahuja writes:
> >
> >> Repost to fix my email id.
> >> 
> >> Fix to correct a possible infinite loop or an always true check when the 
> >> unsigned long counter "i" is used in
> >> lmb_add_region() in the following for loop:
> >> 
> >> for (i = rgn->cnt-1; i >= 0; i--)
> >
> > Unfortunately this won't fix the bug.  Since rgn->cnt is unsigned
> > long, the comparison will be done as an unsigned comparison even if i
> > is signed.
> 
> ??? There is no rgn->cnt involved in the comparison.

Look further down in lmb_add_region; there is a second for loop that
does

for (i = rgn->cnt-1; i >= 0; i--)

I agree that Manish's patch description was misleading, but there is
a real problem in there.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Infinite loop/always true check possible with unsigned counter.

2007-07-10 Thread Andreas Schwab
Paul Mackerras <[EMAIL PROTECTED]> writes:

> Andreas Schwab writes:
>> Paul Mackerras <[EMAIL PROTECTED]> writes:
>> 
>> > Manish Ahuja writes:
>> >
>> >> Repost to fix my email id.
>> >> 
>> >> Fix to correct a possible infinite loop or an always true check when the 
>> >> unsigned long counter "i" is used in
>> >> lmb_add_region() in the following for loop:
>> >> 
>> >> for (i = rgn->cnt-1; i >= 0; i--)
>> >
>> > Unfortunately this won't fix the bug.  Since rgn->cnt is unsigned
>> > long, the comparison will be done as an unsigned comparison even if i
>> > is signed.
>> 
>> ??? There is no rgn->cnt involved in the comparison.
>
> Look further down in lmb_add_region; there is a second for loop that
> does
>
>   for (i = rgn->cnt-1; i >= 0; i--)

Which is exactly the one quoted above.  I still don't see your point.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Infinite loop/always true check possible with unsigned counter.

2007-07-10 Thread Paul Mackerras
Andreas Schwab writes:

> >> ??? There is no rgn->cnt involved in the comparison.
> >
> > Look further down in lmb_add_region; there is a second for loop that
> > does
> >
> > for (i = rgn->cnt-1; i >= 0; i--)
> 
> Which is exactly the one quoted above.  I still don't see your point.

You're right - my mistake.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [patch 0/6] PS3 Storage Drivers for 2.6.23, take 4

2007-07-10 Thread Jens Axboe
On Tue, Jul 10 2007, Geert Uytterhoeven wrote:
> On Wed, 4 Jul 2007, Geert Uytterhoeven wrote:
> > This is the fourth submission of the new PS3 storage drivers:
> >   [1] ps3: Preallocate bootmem memory for the PS3 FLASH ROM storage driver
> >   [2] ps3: Storage Driver Core
> >   [3] ps3: Storage device registration routines.
> >   [4] ps3: Disk Storage Driver
> >   [5] ps3: BD/DVD/CD-ROM Storage Driver
> >   [6] ps3: FLASH ROM Storage Driver
> > 
> > They are based on:
> >   - the current Linux kernel source tree,
> >   - plus the PS3 patches already submitted by Geoff Levand on linuxppc-dev,
> >   - plus the shost_priv() patch in scsi-misc (commit
> > bcd92c9fbcc679ee95003083056f0441a1f474fa).
> > 
> > All issues raised during the previous review rounds should be fixed.
> > There were no more comments after the third submission.
> > 
> > Paul already integrated Geoff Levand's PS3 patches and the first 3 patches
> > in this series in the for-2.6.23 branch in powerpc.git.
> > 
> > Maintainers of block/SCSI/misc, can you please ack the last 3 patches so 
> > Paul
> > can take them, too?
> 
> Ping block/SCSI/misc maintainers?

I have no objections to the block bits, however I feel uneasy merging
the full patchset unless patch #1 has been acked by the platform person.

-- 
Jens Axboe

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [patch 0/6] PS3 Storage Drivers for 2.6.23, take 4

2007-07-10 Thread Jens Axboe
On Tue, Jul 10 2007, Paul Mackerras wrote:
> Jens Axboe writes:
> 
> > I have no objections to the block bits, however I feel uneasy merging
> > the full patchset unless patch #1 has been acked by the platform person.
> 
> I have the first 3 patches in my queue, so yes I've acked it.  It's
> probably easiest if the remaining 3 go through my queue once they've
> been acked - or if you prefer, you can push #4 via your tree once I've
> got Linus to pull my tree.  Let me know either way.

If you already have the 3 first patches, just slurp up the rest as well.
No point in making it more complicated than we have to.

-- 
Jens Axboe

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver

2007-07-10 Thread Gabriel Paubert
On Fri, May 18, 2007 at 05:52:45PM +0100, Matt Sealey wrote:
> Kumar Gala wrote:
> > 
> > On May 18, 2007, at 9:48 AM, Thomas Gleixner wrote:
> > 
> >> On Fri, 2007-05-18 at 15:28 +0100, Matt Sealey wrote:
> >>>
> >>> I think both the MPC52xx GPT0-7 and the SLT0-1 fulfil this fairly
> >>> easily.
> >>
> >> There is some basic work for MPC5200 available:
> >>
> >> http://www.pengutronix.de/oselas/bsp/phytec/index_en.html#phyCORE-MPC5200B-tiny
> >>
> > 
> > I asked this earlier, but figured you might have a better insight.  Is
> > their value in having 'drivers' for more than one clock source?  I'd say
> > most (of not all) the PPC SoCs have timers on the system side that we
> > could provide drivers for, I'm just not sure if that does anything for
> > anyone.
> 
> As I asked after, I'm also very intrigued as to what is going to end
> up using these timers, but likewise, not much use writing a driver if
> everyone can use the extremely high resolution decrementer all at
> once..
> 
> As I said before too, at least Intel has decided there is a great need
> for up to 256 high resolution timer sources on a system, but since this
> is a fairly new concept to Linux (and hrtimers and dynticks too) it
> only seems to be used in the case of i8254/RTC emulation, mostly on
> x86-64.
> 
> I'm looking at it now and finding "users" of hrtimers is looking very
> thin on the ground. Maybe it's justified on the basis that more is
> better, and having support is preferable to not having it (even if
> nobody really uses it) but it seems the entire gamut of timing
> possibility in Linux can be handled through a simple, and single,
> high resolution timer and a queue of events..
> 
> So do we need some more? :D
> 

I don't think so. I really wonder what other capabilities the
other clock sources bring, except more convoluted and complex
code in the end.

There may be one exception to it: scheduled wakeup with 
very deep sleep in which you can't even afford the power
dissipated by the processor in the modes in with the
timebase/decrementer keeps running (which is fairly low
to start with). But this would be a special wakeup path 
where timebase and decrementer are reinitialized and 
become again the main timer source.

Otherwise the decrementer can provide essentially arbitrary 
high resolution (i.e., comparable to the time of an external 
bus access) on a fairly large number of independent timers. 
This scales with the number of processors since there is one 
decrementer per core (is it per thread on SMT chips? 
I don't know).


A few months ago, I implemented here for out internal needs
the equivalent of HRT (I called them FGT for fine-grained timers)
for our VME machines still running a 2.2 kernel. We have boards
who should have generated regular interrupts at programmable
rate interpreting GPS timestamp signals (IRIG B). Unfortunately
the signals were sometimes corrupt and the interrupts were no
more regularly spaced. Now the IRIGB signal is only used to feed
NTP which acts as a low pass filter with an extremely small
cut-off frequency (1mHz or less) and the regular interrupts
are generated from the decrementer in parallel with the standard
ticks. The code is not really polished and would not scale to
a large number of timers but it took me about one day and a half 
to write and debug it. I can even monitor it from a /proc file:

[EMAIL PROTECTED] /root]# cat /proc/fgtimer
 Calls   Lost Name
  60865181158 System timer tick
  77889762  0 itFast (128Hz)

There are a few lost ticks for the main system timer because 
some operations mask interrupts for too long during early
boot, especially with root on NFS which is the case here,
they never happen after the root file system is mounted.

This is also a somewhat special 2.2 kernel, it essentially has
the timekeeping code I submitted for 2.4 and which is
still the core of PPC timekeeping.


Regards,
Gabriel
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 06/13] IB/ehca: Set SEND_GRH flag for all non-LL UD QPs on eHCA2

2007-07-10 Thread Joachim Fenkes
Roland Dreier <[EMAIL PROTECTED]> wrote on 09.07.2007 23:35:31:

> Out of curiousity, does this mean that a GRH will be sent on all UD
> messages (for non-LL QPs)?

No - the bit instructs the hardware to fetch the GRH parts of the QP 
context.
The GRH will only be used if the WQE says so.

Joachim
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


more patches pushed to powerpc.git for-2.6.23 branch

2007-07-10 Thread Paul Mackerras
I just pushed the following patches to the for-2.6.23 branch on
powerpc.git.  I intend to ask Linus to pull everything on the
for-2.6.23 branch shortly, unless I hear loud screams to the
contrary. :)

Paul.

 Documentation/feature-removal-schedule.txt   |   12 +
 Documentation/powerpc/booting-without-of.txt |   32 ++
 arch/powerpc/boot/Makefile   |   31 ++
 arch/powerpc/boot/dts/ebony.dts  |4 
 arch/powerpc/boot/dts/mpc8272ads.dts |   42 +--
 arch/powerpc/boot/dts/mpc832x_mds.dts|   16 +
 arch/powerpc/boot/dts/mpc832x_rdb.dts|   16 +
 arch/powerpc/boot/dts/mpc8349emitx.dts   |   10 +
 arch/powerpc/boot/dts/mpc834x_mds.dts|   10 +
 arch/powerpc/boot/dts/mpc836x_mds.dts|   16 +
 arch/powerpc/boot/dts/mpc8540ads.dts |  147 ++-
 arch/powerpc/boot/dts/mpc8541cds.dts |   90 +++
 arch/powerpc/boot/dts/mpc8544ds.dts  |   18 +
 arch/powerpc/boot/dts/mpc8548cds.dts |  108 
 arch/powerpc/boot/dts/mpc8555cds.dts |   90 +++
 arch/powerpc/boot/dts/mpc8560ads.dts |  148 ++-
 arch/powerpc/boot/dts/mpc8568mds.dts |   66 +++--
 arch/powerpc/boot/dts/mpc8641_hpcn.dts   |   50 +++-
 arch/powerpc/boot/dts/mpc866ads.dts  |   31 +-
 arch/powerpc/boot/dts/mpc885ads.dts  |   54 ++--
 arch/powerpc/boot/ps3-head.S |   80 ++
 arch/powerpc/boot/ps3-hvcall.S   |  184 ++
 arch/powerpc/boot/ps3.c  |  161 
 arch/powerpc/boot/wrapper|   55 
 arch/powerpc/boot/zImage.ps3.lds.S   |   50 
 arch/powerpc/kernel/cputable.c   |   20 +
 arch/powerpc/kernel/io.c |   12 -
 arch/powerpc/kernel/irq.c|3 
 arch/powerpc/kernel/pci_32.c |   34 ---
 arch/powerpc/kernel/pci_64.c |9 -
 arch/powerpc/kernel/ppc_ksyms.c  |1 
 arch/powerpc/kernel/prom.c   |   27 +-
 arch/powerpc/kernel/setup-common.c   |   21 ++
 arch/powerpc/kernel/sysfs.c  |5 
 arch/powerpc/kernel/time.c   |9 -
 arch/powerpc/kernel/vmlinux.lds.S|6 
 arch/powerpc/mm/hash_native_64.c |2 
 arch/powerpc/mm/mem.c|2 
 arch/powerpc/mm/stab.c   |4 
 arch/powerpc/oprofile/op_model_power4.c  |   14 +
 arch/powerpc/platforms/52xx/efika.c  |4 
 arch/powerpc/platforms/52xx/lite5200.c   |2 
 arch/powerpc/platforms/52xx/mpc52xx_pm.c |8 -
 arch/powerpc/platforms/83xx/Makefile |2 
 arch/powerpc/platforms/83xx/mpc8313_rdb.c|1 
 arch/powerpc/platforms/83xx/mpc834x_itx.c|2 
 arch/powerpc/platforms/83xx/mpc834x_mds.c|   49 
 arch/powerpc/platforms/83xx/mpc83xx.h|   28 ++
 arch/powerpc/platforms/83xx/usb.c|  181 +
 arch/powerpc/platforms/85xx/misc.c   |   32 ++
 arch/powerpc/platforms/85xx/mpc8544_ds.c |   15 -
 arch/powerpc/platforms/85xx/mpc85xx_ads.c|   22 --
 arch/powerpc/platforms/85xx/mpc85xx_cds.c|   99 +++
 arch/powerpc/platforms/85xx/mpc85xx_mds.c|   21 --
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c   |   15 -
 arch/powerpc/platforms/8xx/m8xx_setup.c  |5 
 arch/powerpc/platforms/8xx/mpc885ads_setup.c |   71 +
 arch/powerpc/platforms/pasemi/Kconfig|1 
 arch/powerpc/platforms/pasemi/setup.c|2 
 arch/powerpc/platforms/powermac/low_i2c.c|   23 +-
 arch/powerpc/platforms/ps3/mm.c  |2 
 arch/powerpc/platforms/pseries/reconfig.c|2 
 arch/powerpc/sysdev/fsl_soc.c|   13 +
 arch/powerpc/sysdev/mpc8xx_pic.h |   11 +
 arch/powerpc/sysdev/qe_lib/ucc.c |2 
 arch/powerpc/sysdev/qe_lib/ucc_fast.c|8 +
 arch/powerpc/xmon/xmon.c |2 
 arch/ppc/kernel/ppc_ksyms.c  |1 
 arch/ppc/mm/tlb.c|1 
 drivers/block/viodasd.c  |4 
 drivers/char/briq_panel.c|   10 -
 drivers/char/hvc_console.c   |2 
 drivers/char/viotape.c   |   12 -
 drivers/pcmcia/Kconfig   |   17 +
 drivers/pcmcia/m8xx_pcmcia.c |  351 --
 drivers/rtc/Kconfig  |2 
 drivers/serial/cpm_uart/cpm_uart_core.c  |2 
 drivers/serial/of_serial.c   |   33 ++
 include/asm-powerpc/cache.h  |4 
 include/asm-powerpc/cputable.h   |   26 --
 include/asm-powerpc/mmu-8xx.h|  147 +++
 include/asm-powerpc/mmu-fsl-booke.h  |   88 +++
 include/asm-powerpc/mmu.h|   10 -
 include/asm-powerpc/mmu_context.h|  202 +++
 include/asm-power

Re: [PATCH v3] Create add_rtc() function to enable the RTC CMOS driver

2007-07-10 Thread Paul Mackerras
Wade Farnsworth writes:

> In order to use the RTC CMOS driver, each architecture must register a
> platform device for the RTC.
> 
> This creates a function to register the platform device based on the RTC
> device node and verifies that the RTC port against the hard-coded value
> in asm/mc146818rtc.h.

The patch appears to be line-wrapped.  Please re-send.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH][POWERPC] document ipic level/sense info

2007-07-10 Thread Segher Boessenkool
> +Sense and level information follows the Linux convention
> +(specified in include/linux/interrupt.h) and should be encoded
> +as follows:
> +
> + 1 =  low to high edge sensitive type enabled
> + 2 =  high to low edge sensitive type enabled
> + 4 =  active high level sensitive type enabled
> + 8 =  active low level sensitive type enabled

Please note that using the same bit encoding as some Linux
version does buys you (almost) nothing; a good parser for
this OF node should do range/value checking on this property
anyway, translating the values in the process costs nothing.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] ide: Use inline function for eieio

2007-07-10 Thread Sergei Shtylyov
Hello.

Kumar Gala wrote:
> Move to using inline function variant of eieio instead of inline assmebly.

> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>

MBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Allow exec on 32-bit from readable, non-exec pages, with a warning.

2007-07-10 Thread Segher Boessenkool
>> I may be missing the obvious, but doesn't that defeat the purpose of
>> non-executable mappings?
>
> The hardware in question doesn't support non-executable mappings;

Not on a per-page basis, anyway.

> otherwise, it'd never have worked in the first place.  Note that  
> this is
> only allowed on 32-bit, non-book-E.
>
> There isn't much value in enforcing non-exec mappings only if it  
> happens
> to be the first fault on a given page.

Yeah.  Giving the warning is a good thing though.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Allow exec on 32-bit from readable, non-exec pages, with a warning.

2007-07-10 Thread Segher Boessenkool
> In older versions of glibc (through 2.3), the dynamic linker  
> executes a
> small amount of code from the data segment, which is not marked as
> executable.  A recent change (commit  
> 9ba4ace39fdfe22268daca9f28c5df384ae462cf)
> stops this from working; there should be a deprecation period before
> older glibc versions stop working.
>
> The problem has been observed on glibc 2.2.  While glibc 2.3 has  
> the same
> code, I did not see the problem; it may be that it accesses the  
> page in
> question as data before executing from it, and thus it is already  
> mapped.
>
> Signed-off-by: Scott Wood <[EMAIL PROTECTED]>

Acked-by: Segher Boessenkool <[EMAIL PROTECTED]>

> Unfortunately, this didn't make it into 2.6.22, but it should  
> probably go
> into the stable branch...

Both .21.x and .22.x I suppose; if we care about glibc 2.2.x
at all still, that is.

So to make double sure, this doesn't warn on glibc 2.3.x?


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 00/13] IB/ehca: eHCA2 enablement & some fixes

2007-07-10 Thread Joachim Fenkes
Roland Dreier <[EMAIL PROTECTED]> wrote on 10.07.2007 00:11:42:

> thanks, I applied these for 2.6.23 and fixed a bunch of minor things
> that scripts/checkpatch.pl complained about (since I was in a mood to
> do mindless things).

Thanks! Both for the quick merge and for the fixes!

> In the future please run that yourself and clean
> up the obvious things.  I generally don't worry about the 80 column
> stuff, but it will catch most whitespace problems and tell you that
> foo(x,y) should be foo(x, y) etc.  So you don't have to completely
> silence the script but at least take a look at the output.

Didn't know about that script before, so thanks for the pointer!
I'll be sure to pass the next set of patches through it.

Joachim
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v2][POWERPC] document ipic level/sense info

2007-07-10 Thread Segher Boessenkool
>> +Sense and level information follows the Linux convention
>> +(specified in include/linux/interrupt.h) and should be encoded
>> +as follows:
>> +
>> +   2 =  high to low edge sensitive type enabled
>> +   8 =  active low level sensitive type enabled

> ... but it is probably worthwhile commentting that sense types 1 & 4
> are not supported; just to fill in the obvious gaps.  :-)

Same for sense types 0, 3, 5, 6, ...

Just name the sense types 0 and 1, similar to what all other
OF interrupt controller bindings do.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 06/13] IB/ehca: Set SEND_GRH flag for all non-LL UD QPs on eHCA2

2007-07-10 Thread Christoph Raisch


> What decides if a QP is LL or not?
>
>  - R.
Currently we use a high bit in the QP type, which is not how we want to
keep it permanently.
What would you suggest, add two additional LL QP types, or change something
more fundamental
in libibverbs and kernel ib core?
We think we can get along quite well with the existing parameters in the
current create QP.
The current user-kernel interface is ok for these new QPs for post_send +
post_recv,
but unfortunately the libibverbs userspace calls don't match exactly how
the LL queues are to be used.
We would need something like the LL QP interface in libehca in libibverbs
to keep that interface generic.

We didn't see a usage yet for LL QP in kernel, so maybe we should continue
that
discussion on [EMAIL PROTECTED] only.
We could provide example code in libehca/samples if needed.


Gruss / Regards
Christoph + Nam

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2/4] Add dma sector to mpc8641hpcn board dts

2007-07-10 Thread Segher Boessenkool
> + [EMAIL PROTECTED]
> + compatible = "fsl,mpc8xxx-dma";

Please use a real name, not this "xxx" stuff.

> + reg = <21000 100>;
> + ranges = <0 21000 1000>;

These overlap, that can't be right; it is just begging for
trouble.

> + [EMAIL PROTECTED]
> + reg = <100 80>;
> + extended;

I think you want a little more detailed property name
than "extended" here?


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2/4] Add dma sector to mpc8641hpcn board dts

2007-07-10 Thread Segher Boessenkool
> + [EMAIL PROTECTED]

"dma-controller" btw.  And a space before the "{" (here and
elsewhere) :-)


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

2007-07-10 Thread Segher Boessenkool
> +   k) DMA
> +
> +   This sector define DMA for dma-engine driver of Freescale

It's called a "device node" or "node", not a "sector".

> +- compatible : Should be "fsl,mpc8xxx-dma"

Should _include_, not should _be_.  And none of this xxx
business, of course.

> +- extended : Set the DMA channel to work at extended chain mode.
> + If not set, the DMA channel will work at basic
> + chain mode.

Call it "extended-chain-mode", perhaps?

> +- reserved : Reserve the DMA channel to device.

What does this do?  Reserve it for what device, and where?
The OS driver?


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver

2007-07-10 Thread Segher Boessenkool
> This scales with the number of processors since there is one
> decrementer per core (is it per thread on SMT chips?
> I don't know).

One per core.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


RE: [PATCH v2][POWERPC] document ipic level/sense info

2007-07-10 Thread Yoder Stuart-B08248
 

> -Original Message-
> From: Segher Boessenkool [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, July 10, 2007 8:21 AM
> To: Grant Likely
> Cc: Yoder Stuart-B08248; linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]
> Subject: Re: [PATCH v2][POWERPC] document ipic level/sense info
> 
> >> +Sense and level information follows the Linux convention
> >> +(specified in include/linux/interrupt.h) and should be encoded
> >> +as follows:
> >> +
> >> +   2 =  high to low edge sensitive type enabled
> >> +   8 =  active low level sensitive type enabled
> 
> > ... but it is probably worthwhile commentting that sense types 1 & 4
> > are not supported; just to fill in the obvious gaps.  :-)
> 
> Same for sense types 0, 3, 5, 6, ...
> 
> Just name the sense types 0 and 1, similar to what all other
> OF interrupt controller bindings do.

Actually, all I am trying to do with this patch is document the
current state of things.  The 2/8 sense type usage has been that
way for a long time, and I'll defer to the 83xx maintainers
if they see any value in changing it.

Right now there are many DTS files with level/sense set to values
like 8 and no indication anywhere where those values came from.

Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v2][POWERPC] document ipic level/sense info

2007-07-10 Thread Kumar Gala

On Jul 10, 2007, at 8:21 AM, Segher Boessenkool wrote:

>>> +Sense and level information follows the Linux convention
>>> +(specified in include/linux/interrupt.h) and should be encoded
>>> +as follows:
>>> +
>>> +   2 =  high to low edge sensitive type enabled
>>> +   8 =  active low level sensitive type enabled
>
>> ... but it is probably worthwhile commentting that sense types 1 & 4
>> are not supported; just to fill in the obvious gaps.  :-)
>
> Same for sense types 0, 3, 5, 6, ...
>
> Just name the sense types 0 and 1, similar to what all other
> OF interrupt controller bindings do.

I'm not really keen on changing the values at this point.  I think we  
are stuck with them.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 1/1] powerpc: Add H_ILLAN_ATTRIBUTES

2007-07-10 Thread Brian King

Adds the H_ILLAN_ATTRIBUTES hcall

Signed-off-by: Brian King <[EMAIL PROTECTED]>
---

 linux-2.6-bjking1/include/asm-powerpc/hvcall.h |1 +
 1 file changed, 1 insertion(+)

diff -puN include/asm-powerpc/hvcall.h~powerpc_illan_attrs 
include/asm-powerpc/hvcall.h
--- linux-2.6/include/asm-powerpc/hvcall.h~powerpc_illan_attrs  2007-07-10 
09:37:57.0 -0500
+++ linux-2.6-bjking1/include/asm-powerpc/hvcall.h  2007-07-10 
09:37:57.0 -0500
@@ -206,6 +206,7 @@
 #define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
 #define H_QUERY_INT_STATE   0x1E4
 #define H_POLL_PENDING 0x1D8
+#define H_ILLAN_ATTRIBUTES 0x244
 #define H_JOIN 0x298
 #define H_VASI_STATE0x2A4
 #define H_ENABLE_CRQ   0x2B0
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Fix the PCI-Ex link training bug on MPC8641HPCN board.

2007-07-10 Thread Kumar Gala

On Jul 10, 2007, at 1:34 AM, Zhang Wei wrote:

> If the PCI-Ex hose link training is failed, the kernel will halt at  
> the
> PCI scan process on MPC8641HPCN board.
>
> This patch will remove and free the hose from PCI host list if the
> PCI hose link training is failed.
>
> Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>

Thanks.  Going to roll this into the work Roy's been doing to make  
PCI code work across 85xx/86xx.

- k

> ---
>  arch/powerpc/platforms/86xx/pci.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/ 
> platforms/86xx/pci.c
> index 73cd5b0..0b7835c 100644
> --- a/arch/powerpc/platforms/86xx/pci.c
> +++ b/arch/powerpc/platforms/86xx/pci.c
> @@ -210,8 +210,10 @@ int __init mpc86xx_add_bridge(struct  
> device_node *dev)
>
>   /* Probe the hose link training status */
>   early_read_config_word(hose, 0, 0, PCIE_LTSSM, &val);
> - if (val < PCIE_LTSSM_L0)
> + if (val < PCIE_LTSSM_L0) {
> + pcibios_free_controller(hose);
>   return -ENXIO;
> + }
>
>   /* Setup the PCIE host controller. */
>   mpc86xx_setup_pcie(hose, rsrc.start, rsrc.end - rsrc.start + 1);
> -- 
> 1.5.1

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH v3][POWERPC] document ipic level/sense info

2007-07-10 Thread Stuart Yoder
document level/sense encoding info for IPIC 
interrupt controllers

Signed-off-by: Stuart Yoder <[EMAIL PROTECTED]>
---
 Documentation/powerpc/booting-without-of.txt |   19 ++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/Documentation/powerpc/booting-without-of.txt 
b/Documentation/powerpc/booting-without-of.txt
index c169299..e7a465c 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -50,13 +50,14 @@ Table of Contents
   g) Freescale SOC SEC Security Engines
   h) Board Control and Status (BCSR)
   i) Freescale QUICC Engine module (QE)
-  g) Flash chip nodes
+  j) Flash chip nodes
 
   VII - Specifying interrupt information for devices
 1) interrupts property
 2) interrupt-parent property
 3) OpenPIC Interrupt Controllers
 4) ISA Interrupt Controllers
+5) IPIC Interrupt Controllers
 
   Appendix A - Sample SOC node for MPC8540
 
@@ -1878,6 +1879,22 @@ encodings listed below:
2 =  high to low edge sensitive type enabled
3 =  low to high edge sensitive type enabled
 
+5) Freescale IPIC Interrupt Controllers
+---
+
+IPIC interrupt controllers are specific to Freescale 83xx
+SOCs.  Two cells are required to encode interrupt information.
+The first cell defines the interrupt number.  The second cell
+defines the sense and level information.
+
+Sense and level information follows the Linux convention
+(specified in include/linux/interrupt.h) and should be encoded
+as follows:
+
+   2 =  high to low edge sense type enabled
+   8 =  active low level sense type enabled
+
+Note: other level/sense types (0,1,4, etc) are not supported.
 
 Appendix A - Sample SOC node for MPC8540
 
-- 
1.5.0.3

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] xilinxfb: Parameterize xilinxfb platform device registration

2007-07-10 Thread Grant Likely
On 7/10/07, Andrei Konovalov <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
> > From: Grant Likely <[EMAIL PROTECTED]>
> >
> > This patch allows multiple xilinxfb devices to be registered and used
> >
> > Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
> > cc: Andrei Konovalov <[EMAIL PROTECTED]>
> > ---
>
> Looks OK for me.

Paulus, can you please pick this one up?
Thanks,
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 v3][POWERPC] document ipic level/sense info

2007-07-10 Thread Grant Likely
On 7/10/07, Stuart Yoder <[EMAIL PROTECTED]> wrote:
> document level/sense encoding info for IPIC
> interrupt controllers
>
> Signed-off-by: Stuart Yoder <[EMAIL PROTECTED]>
> ---
> +   2 =  high to low edge sense type enabled
> +   8 =  active low level sense type enabled
> +
> +Note: other level/sense types (0,1,4, etc) are not supported.

Perfect!  :-)

Acked-by: Grant Likely <[EMAIL PROTECTED]>


-- 
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


[PATCH] Consolidate mm_context_t definition in mmu.h

2007-07-10 Thread Josh Boyer
All of the platforms except PPC64 share a common mm_context_t definition.
Defining it in mmu.h avoids duplicating it in the platform specific mmu
header files.

Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>

---
 include/asm-powerpc/mmu-44x.h   |5 -
 include/asm-powerpc/mmu-8xx.h   |4 
 include/asm-powerpc/mmu-fsl-booke.h |4 
 include/asm-powerpc/mmu-hash32.h|5 -
 include/asm-powerpc/mmu-hash64.h|   16 
 include/asm-powerpc/mmu.h   |   28 
 6 files changed, 28 insertions(+), 34 deletions(-)

--- linux-2.6.orig/include/asm-powerpc/mmu-44x.h
+++ linux-2.6/include/asm-powerpc/mmu-44x.h
@@ -55,11 +55,6 @@
 
 typedef unsigned long long phys_addr_t;
 
-typedef struct {
-   unsigned long id;
-   unsigned long vdso_base;
-} mm_context_t;
-
 #endif /* !__ASSEMBLY__ */
 
 #ifndef CONFIG_PPC_EARLY_DEBUG_44x
--- linux-2.6.orig/include/asm-powerpc/mmu-8xx.h
+++ linux-2.6/include/asm-powerpc/mmu-8xx.h
@@ -138,10 +138,6 @@
 #ifndef __ASSEMBLY__
 typedef unsigned long phys_addr_t;
 
-typedef struct {
-   unsigned long id;
-   unsigned long vdso_base;
-} mm_context_t;
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_MMU_8XX_H_ */
--- linux-2.6.orig/include/asm-powerpc/mmu-fsl-booke.h
+++ linux-2.6/include/asm-powerpc/mmu-fsl-booke.h
@@ -79,10 +79,6 @@ typedef unsigned long phys_addr_t;
 typedef unsigned long long phys_addr_t;
 #endif
 
-typedef struct {
-   unsigned long id;
-   unsigned long vdso_base;
-} mm_context_t;
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_MMU_FSL_BOOKE_H_ */
--- linux-2.6.orig/include/asm-powerpc/mmu-hash32.h
+++ linux-2.6/include/asm-powerpc/mmu-hash32.h
@@ -79,11 +79,6 @@ struct hash_pte {
unsigned long pp:2; /* Page protection */
 };
 
-typedef struct {
-   unsigned long id;
-   unsigned long vdso_base;
-} mm_context_t;
-
 typedef unsigned long phys_addr_t;
 
 #endif /* !__ASSEMBLY__ */
--- linux-2.6.orig/include/asm-powerpc/mmu-hash64.h
+++ linux-2.6/include/asm-powerpc/mmu-hash64.h
@@ -359,22 +359,6 @@ extern void stab_initialize(unsigned lon
 
 #ifndef __ASSEMBLY__
 
-typedef unsigned long mm_context_id_t;
-
-typedef struct {
-   mm_context_id_t id;
-   u16 user_psize; /* page size index */
-
-#ifdef CONFIG_PPC_MM_SLICES
-   u64 low_slices_psize;   /* SLB page size encodings */
-   u64 high_slices_psize;  /* 4 bits per slice for now */
-#else
-   u16 sllp;   /* SLB page size encoding */
-#endif
-   unsigned long vdso_base;
-} mm_context_t;
-
-
 static inline unsigned long vsid_scramble(unsigned long protovsid)
 {
 #if 0
--- linux-2.6.orig/include/asm-powerpc/mmu.h
+++ linux-2.6/include/asm-powerpc/mmu.h
@@ -19,5 +19,33 @@
 #  include 
 #endif
 
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_PPC64
+typedef unsigned long mm_context_id_t;
+
+typedef struct {
+   mm_context_id_t id;
+   u16 user_psize; /* page size index */
+
+#ifdef CONFIG_PPC_MM_SLICES
+   u64 low_slices_psize;   /* SLB page size encodings */
+   u64 high_slices_psize;  /* 4 bits per slice for now */
+#else
+   u16 sllp;   /* SLB page size encoding */
+#endif
+   unsigned long vdso_base;
+} mm_context_t;
+
+#else /* !CONFIG_PPC64 */
+
+typedef struct {
+   unsigned long id;
+   unsigned long vdso_base;
+} mm_context_t;
+
+#endif /* CONFIG_PPC64 */
+#endif /* !__ASSEMBLY__ */
+
 #endif /* __KERNEL__ */
 #endif /* _ASM_POWERPC_MMU_H_ */

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[patch 0/6] Unify the PCI/PCI Express support for 83xx/85xx/86xx

2007-07-10 Thread Zang Roy-r61911
This series of patches do:

(1) unify the PCI/PCI express support
for 83xx/85xx/86xx.


(2) Add basic PCI Express support for mpc8548 Rev 2.0 
board.

(3) Add basic PCI support for mpc8568mds board.

The patches have been tested on 8548 rev2.0 with Arcadia 3.1 
board, mpc8568mds board and 8641HPCN board.

Some of them have been in the tree on opensource.freescale.com.
I regenerated them based on my previous patches and comments. 
The baseline is Kumar's current tree for paulus.

The VIA support on CDS board and PCI/E support for 
8544DS board will be in next series of patches :-).



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[patch 1/6] Create common fsl pci/e files based on 86xx platform

2007-07-10 Thread Zang Roy-r61911
From: Roy Zang <[EMAIL PROTECTED]>

Move
arch/powerpc/platforms/86xx/pci.c -> arch/powerpc/sysdev/fsl_pci.c
arch/powerpc/sysdev/fsl_pcie.h -> arch/powerpc/sysdev/fsl_pci.h
as the base to unify 83xx/85xx/86xx pci and pcie.

Add CONFIG_FSL_PCI to build fsl_pci.c for Freescale pci and pcie option.
The code is still work for 86xx platform.

Signed-off-by: Roy Zang <[EMAIL PROTECTED]>
---
 arch/powerpc/Kconfig |4 +
 arch/powerpc/platforms/86xx/Kconfig  |1 +
 arch/powerpc/platforms/86xx/Makefile |1 -
 arch/powerpc/platforms/86xx/pci.c|  238 --
 arch/powerpc/sysdev/Makefile |1 +
 arch/powerpc/sysdev/fsl_pci.c|  238 ++
 arch/powerpc/sysdev/fsl_pci.h|   94 +
 arch/powerpc/sysdev/fsl_pcie.h   |   94 -
 8 files changed, 338 insertions(+), 333 deletions(-)
 delete mode 100644 arch/powerpc/platforms/86xx/pci.c
 create mode 100644 arch/powerpc/sysdev/fsl_pci.c
 create mode 100644 arch/powerpc/sysdev/fsl_pci.h
 delete mode 100644 arch/powerpc/sysdev/fsl_pcie.h

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index cbfbd98..8c780bf 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -419,6 +419,10 @@ config SBUS
 config FSL_SOC
bool
 
+config FSL_PCI
+   bool
+   depends on PPC_86xx
+
 # Yes MCA RS/6000s exist but Linux-PPC does not currently support any
 config MCA
bool
diff --git a/arch/powerpc/platforms/86xx/Kconfig 
b/arch/powerpc/platforms/86xx/Kconfig
index 0faebfd..c848173 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -16,6 +16,7 @@ config MPC8641
bool
select PPC_INDIRECT_PCI
select PPC_INDIRECT_PCI_BE
+   select FSL_PCI
select PPC_UDBG_16550
select MPIC
default y if MPC8641_HPCN
diff --git a/arch/powerpc/platforms/86xx/Makefile 
b/arch/powerpc/platforms/86xx/Makefile
index 418fd8f..3376c77 100644
--- a/arch/powerpc/platforms/86xx/Makefile
+++ b/arch/powerpc/platforms/86xx/Makefile
@@ -4,4 +4,3 @@
 
 obj-$(CONFIG_SMP)  += mpc86xx_smp.o
 obj-$(CONFIG_MPC8641_HPCN) += mpc86xx_hpcn.o
-obj-$(CONFIG_PCI)  += pci.o
diff --git a/arch/powerpc/platforms/86xx/pci.c 
b/arch/powerpc/platforms/86xx/pci.c
deleted file mode 100644
index 73cd5b0..000
--- a/arch/powerpc/platforms/86xx/pci.c
+++ /dev/null
@@ -1,238 +0,0 @@
-/*
- * MPC86XX pci setup code
- *
- * Recode: ZHANG WEI <[EMAIL PROTECTED]>
- * Initial author: Xianghua Xiao <[EMAIL PROTECTED]>
- *
- * Copyright 2006 Freescale Semiconductor Inc.
- *
- * This program is free software; you can redistribute  it and/or modify it
- * under  the terms of  the GNU General  Public License as published by the
- * Free Software Foundation;  either version 2 of the  License, or (at your
- * option) any later version.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "mpc86xx.h"
-
-#undef DEBUG
-
-#ifdef DEBUG
-#define DBG(fmt, args...) printk(KERN_ERR "%s: " fmt, __FUNCTION__, ## args)
-#else
-#define DBG(fmt, args...)
-#endif
-
-struct pcie_outbound_window_regs {
-   uintpexotar;   /* 0x.0 - PCI Express outbound 
translation address register */
-   uintpexotear;  /* 0x.4 - PCI Express outbound 
translation extended address register */
-   uintpexowbar;  /* 0x.8 - PCI Express outbound window 
base address register */
-   charres1[4];
-   uintpexowar;   /* 0x.10 - PCI Express outbound window 
attributes register */
-   charres2[12];
-};
-
-struct pcie_inbound_window_regs {
-   uintpexitar;   /* 0x.0 - PCI Express inbound 
translation address register */
-   charres1[4];
-   uintpexiwbar;  /* 0x.8 - PCI Express inbound window 
base address register */
-   uintpexiwbear; /* 0x.c - PCI Express inbound window 
base extended address register */
-   uintpexiwar;   /* 0x.10 - PCI Express inbound window 
attributes register */
-   charres2[12];
-};
-
-static void __init setup_pcie_atmu(struct pci_controller *hose, struct 
resource *rsrc)
-{
-   volatile struct ccsr_pex *pcie;
-   volatile struct pcie_outbound_window_regs *pcieow;
-   volatile struct pcie_inbound_window_regs *pcieiw;
-   int i = 0;
-
-   DBG("PCIE memory map start 0x%x, size 0x%x\n", rsrc->start,
-   rsrc->end - rsrc->start + 1);
-   pcie = ioremap(rsrc->start, rsrc->end - rsrc->start + 1);
-
-   /* Disable all windows (except pexowar0 since its ignored) */
-   pcie->pexowar1 = 0;
-   pcie->pexowar2 = 0;
-   pcie->pexowar3 = 0;
-   pcie->pexowar4 = 0;
-   pcie->pexiwar1 = 0;
-   pcie->pexiwar2 = 0;
-   pcie->pexiwar3 = 0;
-
-   pcieow = (s

[patch 2/6] Rewrite Freescale pci/pcie routing for 85xx/86xx pci/pcie controller

2007-07-10 Thread Zang Roy-r61911
From: Roy Zang <[EMAIL PROTECTED]>

Rewrite Freescale pci/pcie routing for 83xx/85xx/86xx pci/pcie 
controller.

The routing are common for 83xx/85xx/86xx pci/pcie host.

Signed-off-by: Roy Zang <[EMAIL PROTECTED]>
---
 arch/powerpc/sysdev/fsl_pci.c |  244 ++---
 arch/powerpc/sysdev/fsl_pci.h |  143 +++-
 2 files changed, 172 insertions(+), 215 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 24ba1b6..5e15cfc 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -1,136 +1,98 @@
 /*
- * MPC86XX pci setup code
+ * MPC85xx/86xx PCI/PCIE support routing.
  *
- * Recode: ZHANG WEI <[EMAIL PROTECTED]>
- * Initial author: Xianghua Xiao <[EMAIL PROTECTED]>
+ * Copyright 2007 Freescale Semiconductor, Inc
  *
- * Copyright 2006 Freescale Semiconductor Inc.
+ * Initial author: Xianghua Xiao <[EMAIL PROTECTED]>
+ * Recode: ZHANG WEI <[EMAIL PROTECTED]>
+ * Rewrite the routing for Frescale PCI and PCI Express
+ * Roy Zang <[EMAIL PROTECTED]>
  *
  * This program is free software; you can redistribute  it and/or modify it
  * under  the terms of  the GNU General  Public License as published by the
  * Free Software Foundation;  either version 2 of the  License, or (at your
  * option) any later version.
  */
-
-#include 
-#include 
-#include 
+#include 
 #include 
-#include 
+#include 
+#include 
+#include 
+#include 
 
-#include 
-#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-#include "../platforms/86xx/mpc86xx.h"
-
-#undef DEBUG
-
-#ifdef DEBUG
-#define DBG(fmt, args...) printk(KERN_ERR "%s: " fmt, __FUNCTION__, ## args)
-#else
-#define DBG(fmt, args...)
-#endif
-
-struct pcie_outbound_window_regs {
-   uintpexotar;   /* 0x.0 - PCI Express outbound 
translation address register */
-   uintpexotear;  /* 0x.4 - PCI Express outbound 
translation extended address register */
-   uintpexowbar;  /* 0x.8 - PCI Express outbound window 
base address register */
-   charres1[4];
-   uintpexowar;   /* 0x.10 - PCI Express outbound window 
attributes register */
-   charres2[12];
-};
-
-struct pcie_inbound_window_regs {
-   uintpexitar;   /* 0x.0 - PCI Express inbound 
translation address register */
-   charres1[4];
-   uintpexiwbar;  /* 0x.8 - PCI Express inbound window 
base address register */
-   uintpexiwbear; /* 0x.c - PCI Express inbound window 
base extended address register */
-   uintpexiwar;   /* 0x.10 - PCI Express inbound window 
attributes register */
-   charres2[12];
-};
-
-static void __init setup_pcie_atmu(struct pci_controller *hose, struct 
resource *rsrc)
+/* atmu setup for fsl pci/pcie controller */
+void __init setup_pci_atmu(struct pci_controller *hose, struct resource *rsrc)
 {
-   volatile struct ccsr_pex *pcie;
-   volatile struct pcie_outbound_window_regs *pcieow;
-   volatile struct pcie_inbound_window_regs *pcieiw;
-   int i = 0;
+   struct ccsr_pci __iomem *pci;
+   int i;
 
-   DBG("PCIE memory map start 0x%x, size 0x%x\n", rsrc->start,
+   pr_debug("PCI memory map start 0x%x, size 0x%x\n", rsrc->start,
rsrc->end - rsrc->start + 1);
-   pcie = ioremap(rsrc->start, rsrc->end - rsrc->start + 1);
-
-   /* Disable all windows (except pexowar0 since its ignored) */
-   pcie->pexowar1 = 0;
-   pcie->pexowar2 = 0;
-   pcie->pexowar3 = 0;
-   pcie->pexowar4 = 0;
-   pcie->pexiwar1 = 0;
-   pcie->pexiwar2 = 0;
-   pcie->pexiwar3 = 0;
-
-   pcieow = (struct pcie_outbound_window_regs *)&pcie->pexotar1;
-   pcieiw = (struct pcie_inbound_window_regs *)&pcie->pexitar1;
-
-   /* Setup outbound MEM window */
-   for(i = 0; i < 3; i++)
-   if (hose->mem_resources[i].flags & IORESOURCE_MEM){
-   DBG("PCIE MEM resource start 0x%08x, size 0x%08x.\n",
-   hose->mem_resources[i].start,
-   hose->mem_resources[i].end
- - hose->mem_resources[i].start + 1);
-   pcieow->pexotar = (hose->mem_resources[i].start) >> 12
-   & 0x000f;
-   pcieow->pexotear = 0;
-   pcieow->pexowbar = (hose->mem_resources[i].start) >> 12
-   & 0x000f;
-   /* Enable, Mem R/W */
-   pcieow->pexowar = 0x80044000 |
-   (__ilog2(hose->mem_resources[i].end
-- hose->mem_resources[i].start + 1)
-- 1);
-   pcieow++;
-   }
-
-   /* Setup outbound IO window */
-   if (hose->io_resourc

[patch 3/6] Add 8548 CDS PCI express controller node and PCI-X device node

2007-07-10 Thread Zang Roy-r61911
From: Roy Zang <[EMAIL PROTECTED]>

Add 8548 CDS PCI express controller node and PCI-X device node.
The current  dts file is suitable for 8548 Rev 2.0 board with
Arcadia 3.1.
This kind of board combination is the most popular.

Indentify pci, pcie host by compatible property "fsl,mpc85xx-pci"
and "fsl, mpc85xx-pciex".

Signed-off-by: Roy Zang <[EMAIL PROTECTED]>
---
 arch/powerpc/boot/dts/mpc8548cds.dts |  156 +++---
 1 files changed, 105 insertions(+), 51 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts 
b/arch/powerpc/boot/dts/mpc8548cds.dts
index 9d0b84b..d60821b 100644
--- a/arch/powerpc/boot/dts/mpc8548cds.dts
+++ b/arch/powerpc/boot/dts/mpc8548cds.dts
@@ -1,5 +1,5 @@
 /*
- * MPC8555 CDS Device Tree Source
+ * MPC8548 CDS Device Tree Source
  *
  * Copyright 2006 Freescale Semiconductor Inc.
  *
@@ -186,67 +186,96 @@
pci1: [EMAIL PROTECTED] {
interrupt-map-mask = <1f800 0 0 7>;
interrupt-map = <
+   /* IDSEL 0x4 (PCIX Slot 2) */
+   02000 0 0 1 &mpic 0 1
+   02000 0 0 2 &mpic 1 1
+   02000 0 0 3 &mpic 2 1
+   02000 0 0 4 &mpic 3 1
+
+   /* IDSEL 0x5 (PCIX Slot 3) */
+   02800 0 0 1 &mpic 1 1
+   02800 0 0 2 &mpic 2 1
+   02800 0 0 3 &mpic 3 1
+   02800 0 0 4 &mpic 0 1
+
+   /* IDSEL 0x6 (PCIX Slot 4) */
+   03000 0 0 1 &mpic 2 1
+   03000 0 0 2 &mpic 3 1
+   03000 0 0 3 &mpic 0 1
+   03000 0 0 4 &mpic 1 1
+
+   /* IDSEL 0x8 (PCIX Slot 5) */
+   04000 0 0 1 &mpic 0 1
+   04000 0 0 2 &mpic 1 1
+   04000 0 0 3 &mpic 2 1
+   04000 0 0 4 &mpic 3 1
+
+   /* IDSEL 0xC (Tsi310 bridge) */
+   06000 0 0 1 &mpic 0 1
+   06000 0 0 2 &mpic 1 1
+   06000 0 0 3 &mpic 2 1
+   06000 0 0 4 &mpic 3 1
+
+   /* IDSEL 0x14 (Slot 2) */
+   0a000 0 0 1 &mpic 0 1
+   0a000 0 0 2 &mpic 1 1
+   0a000 0 0 3 &mpic 2 1
+   0a000 0 0 4 &mpic 3 1
+
+   /* IDSEL 0x15 (Slot 3) */
+   0a800 0 0 1 &mpic 1 1
+   0a800 0 0 2 &mpic 2 1
+   0a800 0 0 3 &mpic 3 1
+   0a800 0 0 4 &mpic 0 1
+
+   /* IDSEL 0x16 (Slot 4) */
+   0b000 0 0 1 &mpic 2 1
+   0b000 0 0 2 &mpic 3 1
+   0b000 0 0 3 &mpic 0 1
+   0b000 0 0 4 &mpic 1 1
+
+   /* IDSEL 0x18 (Slot 5) */
+   0c000 0 0 1 &mpic 0 1
+   0c000 0 0 2 &mpic 1 1
+   0c000 0 0 3 &mpic 2 1
+   0c000 0 0 4 &mpic 3 1
+
+   /* IDSEL 0x1C (Tsi310 bridge PCI primary) */
+   0E000 0 0 1 &mpic 0 1
+   0E000 0 0 2 &mpic 1 1
+   0E000 0 0 3 &mpic 2 1
+   0E000 0 0 4 &mpic 3 1
+
+   /* bus 1 , idsel 0x2 Tsi310 bridge secondary */
+   11000 0 0 1 &mpic 2 1
+   11000 0 0 2 &mpic 3 1
+   11000 0 0 3 &mpic 0 1
+   11000 0 0 4 &mpic 1 1
+
+   /* VIA chip */
+   12000 0 0 1 &mpic 0 1
+   12000 0 0 2 &mpic 1 1
+   12000 0 0 3 &mpic 2 1
+   12000 0 0 4 &mpic 3 1>;
 
-   /* IDSEL 0x10 */
-   08000 0 0 1 &mpic 0 1
-   08000 0 0 2 &mpic 1 1
-   08000 0 0 3 &mpic 2 1
-   08000 0 0 4 &mpic 3 1
-
-   /* IDSEL 0x11 */
-   08800 0 0 1 &mpic 0 1
-   08800 0 0 2 &mpic 1 1
-   08800 0 0 3 &mpic 2 1
-   08800 0 0 4 &mpic 3 1
-
-   /* IDSEL 0x12 (Slot 1) */
-   

[patch 4/6] User Freescale pci/pcie common routing for 83xx/85xx/86xx boards

2007-07-10 Thread Zang Roy-r61911
From: Roy Zang <[EMAIL PROTECTED]>

User Freescale pci/pcie common routing for 83xx/85xx/86xx
boards.

Signed-off-by: Roy Zang <[EMAIL PROTECTED]>
---
 arch/powerpc/Kconfig   |2 +-
 arch/powerpc/platforms/83xx/Kconfig|4 +
 arch/powerpc/platforms/83xx/mpc8313_rdb.c  |2 +-
 arch/powerpc/platforms/83xx/mpc832x_mds.c  |2 +-
 arch/powerpc/platforms/83xx/mpc832x_rdb.c  |2 +-
 arch/powerpc/platforms/83xx/mpc834x_itx.c  |   11 +++-
 arch/powerpc/platforms/83xx/mpc834x_mds.c  |   11 +++-
 arch/powerpc/platforms/83xx/mpc836x_mds.c  |2 +-
 arch/powerpc/platforms/83xx/mpc83xx.h  |2 +-
 arch/powerpc/platforms/83xx/pci.c  |   57 -
 arch/powerpc/platforms/85xx/Kconfig|1 +
 arch/powerpc/platforms/85xx/Makefile   |2 +-
 arch/powerpc/platforms/85xx/mpc85xx.h  |1 -
 arch/powerpc/platforms/85xx/mpc85xx_ads.c  |3 +-
 arch/powerpc/platforms/85xx/mpc85xx_cds.c  |   14 +++--
 arch/powerpc/platforms/85xx/mpc85xx_mds.c  |6 +-
 arch/powerpc/platforms/85xx/pci.c  |   91 
 arch/powerpc/platforms/86xx/mpc86xx.h  |2 -
 arch/powerpc/platforms/86xx/mpc86xx_hpcn.c |   11 +++-
 19 files changed, 51 insertions(+), 175 deletions(-)
 delete mode 100644 arch/powerpc/platforms/85xx/pci.c

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8c780bf..20f7a34 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -421,7 +421,7 @@ config FSL_SOC
 
 config FSL_PCI
bool
-   depends on PPC_86xx
+   depends on PPC_85xx || PPC_86xx || PPC_83xx
 
 # Yes MCA RS/6000s exist but Linux-PPC does not currently support any
 config MCA
diff --git a/arch/powerpc/platforms/83xx/Kconfig 
b/arch/powerpc/platforms/83xx/Kconfig
index ec305f1..d60a431 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -55,23 +55,27 @@ endchoice
 config PPC_MPC831x
bool
select PPC_UDBG_16550
+   select FSL_PCI
select PPC_INDIRECT_PCI
default y if MPC8313_RDB
 
 config PPC_MPC832x
bool
select PPC_UDBG_16550
+   select FSL_PCI
select PPC_INDIRECT_PCI
default y if MPC832x_MDS || MPC832x_RDB
 
 config MPC834x
bool
select PPC_UDBG_16550
+   select FSL_PCI
select PPC_INDIRECT_PCI
default y if MPC834x_MDS || MPC834x_ITX
 
 config PPC_MPC836x
bool
select PPC_UDBG_16550
+   select FSL_PCI
select PPC_INDIRECT_PCI
default y if MPC836x_MDS
diff --git a/arch/powerpc/platforms/83xx/mpc8313_rdb.c 
b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
index 3edfe17..41f4988 100644
--- a/arch/powerpc/platforms/83xx/mpc8313_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc8313_rdb.c
@@ -44,7 +44,7 @@ static void __init mpc8313_rdb_setup_arch(void)
 
 #ifdef CONFIG_PCI
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
-   mpc83xx_add_bridge(np);
+   fsl_add_bridge(np, 1);
 
ppc_md.pci_exclude_device = mpc83xx_exclude_device;
 #endif
diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c 
b/arch/powerpc/platforms/83xx/mpc832x_mds.c
index b39cb52..6ef2acf 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
@@ -75,7 +75,7 @@ static void __init mpc832x_sys_setup_arch(void)
 
 #ifdef CONFIG_PCI
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
-   mpc83xx_add_bridge(np);
+   fsl_add_bridge(np, 1);
ppc_md.pci_exclude_device = mpc83xx_exclude_device;
 #endif
 
diff --git a/arch/powerpc/platforms/83xx/mpc832x_rdb.c 
b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
index b2b28a4..0acc670 100644
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -48,7 +48,7 @@ static void __init mpc832x_rdb_setup_arch(void)
 
 #ifdef CONFIG_PCI
for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
-   mpc83xx_add_bridge(np);
+   fsl_add_bridge(np, 1);
 
ppc_md.pci_exclude_device = mpc83xx_exclude_device;
 #endif
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c 
b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index 47ba544..defde26 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -53,9 +53,14 @@ static void __init mpc834x_itx_setup_arch(void)
ppc_md.progress("mpc834x_itx_setup_arch()", 0);
 
 #ifdef CONFIG_PCI
-   for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
-   mpc83xx_add_bridge(np);
-
+   for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;) {
+   struct resource rsrc;
+   of_address_to_resource(np, 0, &rsrc);
+   if ((rsrc.start & 0xf) == 0x8500)
+   fsl_add_bridge(np, 1);
+   else
+   fsl_add_bridge(n

[patch 5/6] Update the 83xx/85xx/86xx boards device tree

2007-07-10 Thread Zang Roy-r61911
From: Roy Zang <[EMAIL PROTECTED]>

Update the 83xx/85xx/86xx boards device tree.

Indentify pci, pcie host by compatible property
"fsl,mpc83xx-pci","83xx"
"fsl,mpc85xx-pci","85xx"
"fsl,mpc86xx-pci","86xx"
and
"fsl, mpc85xx-pciex","85xx"
"fsl, mpc86xx-pciex","86xx"

Signed-off-by: Roy Zang <[EMAIL PROTECTED]>
---
 arch/powerpc/boot/dts/mpc8313erdb.dts|2 +-
 arch/powerpc/boot/dts/mpc832x_mds.dts|2 +-
 arch/powerpc/boot/dts/mpc832x_rdb.dts|2 +-
 arch/powerpc/boot/dts/mpc8349emitx.dts   |4 ++--
 arch/powerpc/boot/dts/mpc8349emitxgp.dts |2 +-
 arch/powerpc/boot/dts/mpc834x_mds.dts|4 ++--
 arch/powerpc/boot/dts/mpc836x_mds.dts|2 +-
 arch/powerpc/boot/dts/mpc8540ads.dts |2 +-
 arch/powerpc/boot/dts/mpc8541cds.dts |4 ++--
 arch/powerpc/boot/dts/mpc8555cds.dts |4 ++--
 arch/powerpc/boot/dts/mpc8560ads.dts |2 +-
 arch/powerpc/boot/dts/mpc8641_hpcn.dts   |4 ++--
 12 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts 
b/arch/powerpc/boot/dts/mpc8313erdb.dts
index a1533cc..5276843 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -178,7 +178,7 @@
#size-cells = <2>;
#address-cells = <3>;
reg = <8500 100>;
-   compatible = "83xx";
+   compatible = "fsl,mpc83xx-pci","83xx";
device_type = "pci";
};
 
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts 
b/arch/powerpc/boot/dts/mpc832x_mds.dts
index 4fc0c4d..ee8897b 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -154,7 +154,7 @@
#size-cells = <2>;
#address-cells = <3>;
reg = <8500 100>;
-   compatible = "83xx";
+   compatible = "fsl,mpc83xx-pci","83xx";
device_type = "pci";
};
 
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts 
b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index 447c03f..d83469b 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -123,7 +123,7 @@
#size-cells = <2>;
#address-cells = <3>;
reg = <8500 100>;
-   compatible = "83xx";
+   compatible = "fsl,mpc83xx-pci","83xx";
device_type = "pci";
};
 
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts 
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index ae9bca5..911984b 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -197,7 +197,7 @@
#size-cells = <2>;
#address-cells = <3>;
reg = <8500 100>;
-   compatible = "83xx";
+   compatible = "fsl,mpc83xx-pci","83xx";
device_type = "pci";
};
 
@@ -222,7 +222,7 @@
#size-cells = <2>;
#address-cells = <3>;
reg = <8600 100>;
-   compatible = "83xx";
+   compatible = "fsl,mpc83xx-pci","83xx";
device_type = "pci";
};
 
diff --git a/arch/powerpc/boot/dts/mpc8349emitxgp.dts 
b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
index f636528..8790349 100644
--- a/arch/powerpc/boot/dts/mpc8349emitxgp.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
@@ -154,7 +154,7 @@
#size-cells = <2>;
#address-cells = <3>;
reg = <8600 100>;
-   compatible = "83xx";
+   compatible = "fsl,mpc83xx-pci","83xx";
device_type = "pci";
};
 
diff --git a/arch/powerpc/boot/dts/mpc834x_mds.dts 
b/arch/powerpc/boot/dts/mpc834x_mds.dts
index 310e877..dc4d97d 100644
--- a/arch/powerpc/boot/dts/mpc834x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc834x_mds.dts
@@ -241,7 +241,7 @@
#size-cells = <2>;
#address-cells = <3>;
reg = <8500 100>;
-   compatible = "83xx";
+   compatible = "fsl,mpc83xx-pci","83xx";
device_type = "pci";
};
 
@@ -301,7 +301,7 @@
#size-cells = <2>;
#address-cells = <3>;
reg = <8600 100>;
-   compatible = "83xx";
+   compatible = "fsl,mpc83xx-pci","83xx";
device_type = "pci";
};
 
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts 
b/arch/powerpc/boot/dts/mpc836x_mds.dts
index 1e914f3..2750eb1 10064

[patch 6/6] Add basic PCI node for mpc8568mds board

2007-07-10 Thread Zang Roy-r61911
From: Roy Zang <[EMAIL PROTECTED]>

Add basic PCI node for mpc8568mds board.

Signed-off-by: Haiying Wang <[EMAIL PROTECTED]>
Signed-off-by: Ebony Zhu <[EMAIL PROTECTED]>
Signed-off-by: Roy Zang <[EMAIL PROTECTED]>
---
 arch/powerpc/boot/dts/mpc8568mds.dts |   29 +
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts 
b/arch/powerpc/boot/dts/mpc8568mds.dts
index 6bb18f2..c6cd1d6 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -170,6 +170,35 @@
interrupt-parent = <&mpic>;
};
 
+   [EMAIL PROTECTED] {
+   interrupt-map-mask = ;
+   interrupt-map = <
+   /* IDSEL 0x12 AD18 */
+   9000 0 0 1 &mpic 5 1
+   9000 0 0 2 &mpic 6 1
+   9000 0 0 3 &mpic 7 1
+   9000 0 0 4 &mpic 4 1
+
+   /* IDSEL 0x13 AD19 */
+   9800 0 0 1 &mpic 6 1
+   9800 0 0 2 &mpic 7 1
+   9800 0 0 3 &mpic 4 1
+   9800 0 0 4 &mpic 5 1>;
+
+   interrupt-parent = <&mpic>;
+   interrupts = <18 2>;
+   bus-range = <0 ff>;
+   ranges = <0200 0 8000 8000 0 2000
+ 0100 0  e200 0 0080>;
+   clock-frequency = <3f940aa>;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   reg = <8000 1000>;
+   compatible = "fsl,mpc85xx-pci","85xx";
+   device_type = "pci";
+   };
+
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "ns16550";
-- 
1.5.1




___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.

2007-07-10 Thread Scott Wood
On Tue, Jul 10, 2007 at 04:01:19PM +0200, Segher Boessenkool wrote:
> > +- compatible : Should be "fsl,mpc8xxx-dma"
> 
> Should _include_, not should _be_.  And none of this xxx
> business, of course.

Especially since the 85xx/86xx version is not 100% compatible with the
83xx version.  How about fsl,mpc8349-dma and fsl,mpc8548-dma for the two
variants?

> > +- extended : Set the DMA channel to work at extended chain mode.
> > + If not set, the DMA channel will work at basic
> > + chain mode.
> 
> Call it "extended-chain-mode", perhaps?

Or don't call it anything.  The ability to do extended chain mode is
implicit in being compatible with fsl,mpc8548-dma.

> > +- reserved : Reserve the DMA channel to device.
> 
> What does this do?  Reserve it for what device, and where?
> The OS driver?

Some hardware has DMA channels hardwired to certain peripherals, such as
an audio codec.  This keeps them from being used as general purpose DMA
channels.

I'd rather just treat the different DMA channels as independent devices,
rather than children of a dma "bus", and change the compatible name if
they're not general purpose.  There's only one register that's shared
among the channels, and it's a superfluous status summary register.

-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Consolidate mm_context_t definition in mmu.h

2007-07-10 Thread Arnd Bergmann
On Tuesday 10 July 2007, Josh Boyer wrote:
> +#ifdef CONFIG_PPC64
> +typedef unsigned long mm_context_id_t;
> +
> +typedef struct {
> +   mm_context_id_t id;
> +   u16 user_psize; /* page size index */
> +
> +#ifdef CONFIG_PPC_MM_SLICES
> +   u64 low_slices_psize;   /* SLB page size encodings */
> +   u64 high_slices_psize;  /* 4 bits per slice for now */
> +#else
> +   u16 sllp;   /* SLB page size encoding */
> +#endif
> +   unsigned long vdso_base;
> +} mm_context_t;
> +
> +#else /* !CONFIG_PPC64 */
> +
> +typedef struct {
> +   unsigned long id;
> +   unsigned long vdso_base;
> +} mm_context_t;
> +
> +#endif /* CONFIG_PPC64 */


It seems to me that you can easily consolidate this further, if you
allow the mm_context_id_t on 32 bit, or remove it on 64 bit:

+typedef unsigned long mm_context_id_t;
+
+typedef struct {
+   mm_context_id_t id;
+   u16 user_psize; /* page size index */
+
+#ifdef CONFIG_PPC64
+#ifdef CONFIG_PPC_MM_SLICES
+   u64 low_slices_psize;   /* SLB page size encodings */
+   u64 high_slices_psize;  /* 4 bits per slice for now */
+#else
+   u16 sllp;   /* SLB page size encoding */
+#endif
+#endif
+   unsigned long vdso_base;
+} mm_context_t;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 3/4] Extend the DMA-engine API.

2007-07-10 Thread Randy Dunlap
On Tue, 10 Jul 2007 17:45:11 +0800 Zhang Wei wrote:

> Add channel wait queue and transfer callback dma_xfer_callback().
> If the DMA controller and driver support interrupt, when the
> transfer is finished, it will wakeup the wait queue
> and call the callback function of the channel.
> 
> Add dma_async_raw_xfer() to API and device_raw_xfer() to struct dma_device
> for RAW physical address DMA transfer, which will be used at transfer
> between I/O address and memory address.
> 
> Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
> ---
>  include/linux/dmaengine.h |   35 +++
>  1 files changed, 35 insertions(+), 0 deletions(-)

>  /**
> + * dma_async_raw_xfer - transfor data between physical addresses with 
> callback

   transfer

> + * @chan: DMA channel to be used
> + * @dest: destination address (physical)
> + * @src: source address (physical)
> + * @len: length
> + */
> +static inline dma_cookie_t dma_async_raw_xfer(struct dma_chan *chan,
> + dma_addr_t dest, dma_addr_t src, size_t len,
> + dma_xfer_callback cb, void *data)
> +{


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Consolidate mm_context_t definition in mmu.h

2007-07-10 Thread Josh Boyer
On Tue, 2007-07-10 at 18:36 +0200, Arnd Bergmann wrote:
> On Tuesday 10 July 2007, Josh Boyer wrote:
> > +#ifdef CONFIG_PPC64
> > +typedef unsigned long mm_context_id_t;
> > +
> > +typedef struct {
> > +   mm_context_id_t id;
> > +   u16 user_psize; /* page size index */
> > +
> > +#ifdef CONFIG_PPC_MM_SLICES
> > +   u64 low_slices_psize;   /* SLB page size encodings */
> > +   u64 high_slices_psize;  /* 4 bits per slice for now */
> > +#else
> > +   u16 sllp;   /* SLB page size encoding */
> > +#endif
> > +   unsigned long vdso_base;
> > +} mm_context_t;
> > +
> > +#else /* !CONFIG_PPC64 */
> > +
> > +typedef struct {
> > +   unsigned long id;
> > +   unsigned long vdso_base;
> > +} mm_context_t;
> > +
> > +#endif /* CONFIG_PPC64 */
> 
> 
> It seems to me that you can easily consolidate this further, if you
> allow the mm_context_id_t on 32 bit, or remove it on 64 bit:

Hm... good point.  Though...

> 
> +typedef unsigned long mm_context_id_t;
> +
> +typedef struct {
> +   mm_context_id_t id;
> +   u16 user_psize; /* page size index */
> +
> +#ifdef CONFIG_PPC64

This needs to be moved up to encompass the u16 user_psize member as
well, yes?

> +#ifdef CONFIG_PPC_MM_SLICES
> +   u64 low_slices_psize;   /* SLB page size encodings */
> +   u64 high_slices_psize;  /* 4 bits per slice for now */
> +#else
> +   u16 sllp;   /* SLB page size encoding */
> +#endif
> +#endif
> +   unsigned long vdso_base;
> +} mm_context_t;

josh

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH v4] Create add_rtc() function to enable the RTC CMOS driver

2007-07-10 Thread Wade Farnsworth
In order to use the RTC CMOS driver, each architecture must register a
platform device for the RTC.

This creates a function to register the platform device based on the RTC
device node and verifies that the RTC port against the hard-coded value
in asm/mc146818rtc.h.

Signed-off-by: Wade Farnsworth <[EMAIL PROTECTED]>

---

Fixed line wrapping.

 arch/powerpc/sysdev/Makefile |1 
 arch/powerpc/sysdev/rtc_cmos_setup.c |   49 +
 2 files changed, 50 insertions(+)

diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 7d8ac1b..f65078c 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_TSI108_BRIDGE)   += tsi108_pci.o tsi108_dev.o
 obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
 mv64x60-$(CONFIG_PCI)  += mv64x60_pci.o
 obj-$(CONFIG_MV64X60)  += $(mv64x60-y) mv64x60_pic.o mv64x60_dev.o
+obj-$(CONFIG_RTC_DRV_CMOS) += rtc_cmos_setup.o
 
 # contains only the suspend handler for time
 ifeq ($(CONFIG_RTC_CLASS),)
diff --git a/arch/powerpc/sysdev/rtc_cmos_setup.c 
b/arch/powerpc/sysdev/rtc_cmos_setup.c
new file mode 100644
index 000..e276048
--- /dev/null
+++ b/arch/powerpc/sysdev/rtc_cmos_setup.c
@@ -0,0 +1,49 @@
+/*
+ * Setup code for PC-style Real-Time Clock.
+ *
+ * Author: Wade Farnsworth <[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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static int  __init add_rtc(void)
+{
+   struct device_node *np;
+   struct platform_device *pd;
+   struct resource res;
+   int ret;
+
+   np = of_find_compatible_node(NULL, NULL, "pnpPNP,b00");
+   if (!np)
+   return -ENODEV;
+
+   ret = of_address_to_resource(np, 0, &res);
+   of_node_put(np);
+   if (ret)
+   return ret;
+
+   /*
+* RTC_PORT(x) is hardcoded in asm/mc146818rtc.h.  Verify that the
+* address provided by the device node matches.
+*/
+   if (res.start != RTC_PORT(0))
+   return -EINVAL;
+
+   pd = platform_device_register_simple("rtc_cmos", -1,
+&res, 1);
+   if (IS_ERR(pd))
+   return PTR_ERR(pd);
+
+   return 0;
+}
+fs_initcall(add_rtc);


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Consolidate mm_context_t definition in mmu.h

2007-07-10 Thread Arnd Bergmann
On Tuesday 10 July 2007, Josh Boyer wrote:
> > +       u16 user_psize;         /* page size index */
> > +
> > +#ifdef CONFIG_PPC64
> 
> This needs to be moved up to encompass the u16 user_psize member as
> well, yes?
> 

Yes, of course. my bad.

Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 1/2] eHEA: Capability flag for DLPAR support

2007-07-10 Thread Jeff Garzik
Jan-Bernd Themann wrote:
> This patch introduces a capability flag that is used by the DLPAR userspace
> tool to check which DLPAR features are supported by the eHEA driver.
> 
> Missing goto has been included.
> 
> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>

applied


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2/2] eHEA: Receive SKB Aggregation

2007-07-10 Thread Jeff Garzik
Jan-Bernd Themann wrote:
> This patch enables the receive side processing to aggregate TCP packets within
> the HEA device driver. It analyses the packets already received after an
> interrupt arrived and forwards these as chains of SKBs for the same TCP
> connection with modified header field. We have seen a lower CPU load and
> improved throughput for small numbers of parallel TCP connections.
> As this feature is considered as experimental it is switched off by default
> and can be activated via a module parameter.
> 
> Some additional security checks have been added since the last posting.
> 
> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>

as noted in comments, we don't need to recreate this in every driver. 
do something more generic.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] PHY fixed driver: rework release path and update phy_id notation

2007-07-10 Thread Jeff Garzik
Vitaly Bordug wrote:
> device_bind_driver() error code returning has been fixed. 
> release() function has been written, so that to free resources
> in correct way; the release path is now clean.
> 
> Before the rework, it used to cause
>  Device '[EMAIL PROTECTED]:1' does not have a release() function, it is broken
>  and must be fixed.
>  BUG: at drivers/base/core.c:104 device_release()
>  
>  Call Trace:  
>   [] kobject_cleanup+0x53/0x7e
>   [] kobject_release+0x0/0x9
>   [] kref_put+0x74/0x81
>   [] fixed_mdio_register_device+0x230/0x265
>   [] fixed_init+0x1f/0x35
>   [] init+0x147/0x2fb
>   [] schedule_tail+0x36/0x92
>   [] child_rip+0xa/0x12
>   [] acpi_ds_init_one_object+0x0/0x83
>   [] init+0x0/0x2fb
>   [] child_rip+0x0/0x12  
> 
> 
> Also changed the notation of the fixed phy definition on
> mdio bus to the form of + to make it able to be used by
> gianfar and ucc_geth that define phy_id strictly as "%d:%d"
> 
> Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
> 
> ---
> 
>  drivers/net/phy/Kconfig |4 ++
>  drivers/net/phy/fixed.c |   93 
> +++
>  2 files changed, 57 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 09b6f25..a938c48 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -71,4 +71,8 @@ config FIXED_MII_100_FDX
>   bool "Emulation for 100M Fdx fixed PHY behavior"
>   depends on FIXED_PHY
>  
> +config FIXED_MII_1000_FDX
> + bool "Emulation for 1000M Fdx fixed PHY behavior"
> + depends on FIXED_PHY
> +
>  endif # PHYLIB
> diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
> index 68c99b4..34b9111 100644
> --- a/drivers/net/phy/fixed.c
> +++ b/drivers/net/phy/fixed.c
> @@ -187,12 +187,29 @@ static struct phy_driver fixed_mdio_driver = {
>   .driver = { .owner = THIS_MODULE,},
>  };
>  
> +static void fixed_mdio_release (struct device * dev)
> +{
> + struct phy_device *phydev = container_of(dev, struct phy_device, dev);
> + struct mii_bus *bus = phydev->bus;
> + struct fixed_info *fixed = bus->priv;
> +
> + kfree(phydev);
> + kfree(bus->dev);
> + kfree(bus);
> + kfree(fixed->regs);
> + kfree(fixed);
> +}
> +
>  
> /*-
>   *  This func is used to create all the necessary stuff, bind
>   * the fixed phy driver and register all it on the mdio_bus_type.
> - * speed is either 10 or 100, duplex is boolean.
> + * speed is either 10 or 100 or 1000, duplex is boolean.
>   * number is used to create multiple fixed PHYs, so that several devices can
>   * utilize them simultaneously.
> + *
> + * The device on mdio bus will look like :,
> + * bus_id = number 
> + * phy_id = speed+duplex.
>   
> *-*/
>  static int fixed_mdio_register_device(int number, int speed, int duplex)
>  {
> @@ -221,6 +238,12 @@ static int fixed_mdio_register_device(int number, int 
> speed, int duplex)
>   }
>  
>   fixed->regs = kzalloc(MII_REGS_NUM*sizeof(int), GFP_KERNEL);
> + if (NULL == fixed->regs) {
> + kfree(dev);
> + kfree(new_bus);
> + kfree(fixed);
> + return -ENOMEM;
> + }
>   fixed->regs_num = MII_REGS_NUM;
>   fixed->phy_status.speed = speed;
>   fixed->phy_status.duplex = duplex;
> @@ -249,57 +272,43 @@ static int fixed_mdio_register_device(int number, int 
> speed, int duplex)
>   fixed->phydev = phydev;
>  
>   if(NULL == phydev) {
> - err = -ENOMEM;
> - goto device_create_fail;
> + kfree(dev);
> + kfree(new_bus);
> + kfree(fixed->regs);
> + kfree(fixed);
> + return -ENOMEM;
>   }
>  
>   phydev->irq = PHY_IGNORE_INTERRUPT;
>   phydev->dev.bus = &mdio_bus_type;
>  
> - if(number)
> - snprintf(phydev->dev.bus_id, BUS_ID_SIZE,
> - "[EMAIL PROTECTED]:%d", number, speed, duplex);
> - else
> - snprintf(phydev->dev.bus_id, BUS_ID_SIZE,
> - "[EMAIL PROTECTED]:%d", speed, duplex);
> + snprintf(phydev->dev.bus_id, BUS_ID_SIZE,
> + "%d:%d", number, speed + duplex);
> +
>   phydev->bus = new_bus;
>  
> + phydev->dev.driver = &fixed_mdio_driver.driver;
> + phydev->dev.release = fixed_mdio_release;
> + 
> + err = phydev->dev.driver->probe(&phydev->dev);
> + if(err < 0) {
> + printk(KERN_ERR "Phy %s: problems with fixed driver\n",
> + phydev->dev.bus_id);
> + kfree(phydev);
> + kfree(dev);
> + kfree(new_bus);
> + kfree(fixed->regs);
> + kfree(fixed);
> + return err;
> + }
> + 
>   err = device_register(&phydev->dev);
>   if(err) {
>

[PATCH v2] Consolidate mm_context_t definition in mmu.h

2007-07-10 Thread Josh Boyer
All of the platforms except PPC64 share a common mm_context_t definition.
Defining it in mmu.h avoids duplicating it in the platform specific mmu
header files.  We further consolidate it by having the PPC32 definition
share the mm_context_id_t type for the id member.

Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>

---
 include/asm-powerpc/mmu-44x.h   |5 -
 include/asm-powerpc/mmu-8xx.h   |4 
 include/asm-powerpc/mmu-fsl-booke.h |4 
 include/asm-powerpc/mmu-hash32.h|5 -
 include/asm-powerpc/mmu-hash64.h|   16 
 include/asm-powerpc/mmu.h   |   21 +
 6 files changed, 21 insertions(+), 34 deletions(-)

--- linux-2.6.orig/include/asm-powerpc/mmu-44x.h
+++ linux-2.6/include/asm-powerpc/mmu-44x.h
@@ -55,11 +55,6 @@
 
 typedef unsigned long long phys_addr_t;
 
-typedef struct {
-   unsigned long id;
-   unsigned long vdso_base;
-} mm_context_t;
-
 #endif /* !__ASSEMBLY__ */
 
 #ifndef CONFIG_PPC_EARLY_DEBUG_44x
--- linux-2.6.orig/include/asm-powerpc/mmu-8xx.h
+++ linux-2.6/include/asm-powerpc/mmu-8xx.h
@@ -138,10 +138,6 @@
 #ifndef __ASSEMBLY__
 typedef unsigned long phys_addr_t;
 
-typedef struct {
-   unsigned long id;
-   unsigned long vdso_base;
-} mm_context_t;
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_MMU_8XX_H_ */
--- linux-2.6.orig/include/asm-powerpc/mmu-fsl-booke.h
+++ linux-2.6/include/asm-powerpc/mmu-fsl-booke.h
@@ -79,10 +79,6 @@ typedef unsigned long phys_addr_t;
 typedef unsigned long long phys_addr_t;
 #endif
 
-typedef struct {
-   unsigned long id;
-   unsigned long vdso_base;
-} mm_context_t;
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_POWERPC_MMU_FSL_BOOKE_H_ */
--- linux-2.6.orig/include/asm-powerpc/mmu-hash32.h
+++ linux-2.6/include/asm-powerpc/mmu-hash32.h
@@ -79,11 +79,6 @@ struct hash_pte {
unsigned long pp:2; /* Page protection */
 };
 
-typedef struct {
-   unsigned long id;
-   unsigned long vdso_base;
-} mm_context_t;
-
 typedef unsigned long phys_addr_t;
 
 #endif /* !__ASSEMBLY__ */
--- linux-2.6.orig/include/asm-powerpc/mmu-hash64.h
+++ linux-2.6/include/asm-powerpc/mmu-hash64.h
@@ -359,22 +359,6 @@ extern void stab_initialize(unsigned lon
 
 #ifndef __ASSEMBLY__
 
-typedef unsigned long mm_context_id_t;
-
-typedef struct {
-   mm_context_id_t id;
-   u16 user_psize; /* page size index */
-
-#ifdef CONFIG_PPC_MM_SLICES
-   u64 low_slices_psize;   /* SLB page size encodings */
-   u64 high_slices_psize;  /* 4 bits per slice for now */
-#else
-   u16 sllp;   /* SLB page size encoding */
-#endif
-   unsigned long vdso_base;
-} mm_context_t;
-
-
 static inline unsigned long vsid_scramble(unsigned long protovsid)
 {
 #if 0
--- linux-2.6.orig/include/asm-powerpc/mmu.h
+++ linux-2.6/include/asm-powerpc/mmu.h
@@ -19,5 +19,26 @@
 #  include 
 #endif
 
+#ifndef __ASSEMBLY__
+
+typedef unsigned long mm_context_id_t;
+
+typedef struct {
+   mm_context_id_t id;
+#ifdef CONFIG_PPC64
+   u16 user_psize; /* page size index */
+
+#ifdef CONFIG_PPC_MM_SLICES
+   u64 low_slices_psize;   /* SLB page size encodings */
+   u64 high_slices_psize;  /* 4 bits per slice for now */
+#else
+   u16 sllp;   /* SLB page size encoding */
+#endif
+#endif /* CONFIG_PPC64 */
+   unsigned long vdso_base;
+} mm_context_t;
+
+#endif /* !__ASSEMBLY__ */
+
 #endif /* __KERNEL__ */
 #endif /* _ASM_POWERPC_MMU_H_ */

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: more patches pushed to powerpc.git for-2.6.23 branch

2007-07-10 Thread Josh Boyer
On Tue, 2007-07-10 at 22:38 +1000, Paul Mackerras wrote:
> I just pushed the following patches to the for-2.6.23 branch on
> powerpc.git.  I intend to ask Linus to pull everything on the
> for-2.6.23 branch shortly, unless I hear loud screams to the
> contrary. :)

Can we get Ben's new emac driver added?  It's fairly important for 4xx
work to continue.

Ben?

josh

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


hugetlbfs for ppc440 - kernel BUG

2007-07-10 Thread Satya
hello,
I am trying to implement hugetlbfs on the IBM Bluegene/L IO node
(ppc440) and I have a big problem as well as a few questions to ask
the group. I patched a 2.6.21.6 linux kernel (manually) with Edi
Shmueli's hugetlbfs implementation (found here:
http://patchwork.ozlabs.org/linuxppc/patch?id=8427) for this. I did
have to make slight changes (described at the end) to make it work.
My test program is a shortened version of a sys v shared memory
example described in Documentation/vm/hugetlbpage.txt

I get the following kernel BUG when a page fault occurs on a huge page address:
BUG: scheduling while atomic: shmtest2/0x1001/1291
Call Trace:
[CFF0BCE0] [C00084F4] show_stack+0x4c/0x194 (unreliable)
 [CFF0BD20] [C01A53C4] schedule+0x664/0x668
[CFF0BD60] [C00175F8] __cond_resched+0x24/0x50
[CFF0BD80] [C01A5A6C] cond_resched+0x50/0x58
[CFF0BD90] [C005A31C] clear_huge_page+0x28/0x174
[CFF0BDC0] [C005B360] hugetlb_no_page+0xb4/0x220
[CFF0BE00] [C005B5BC] hugetlb_fault+0xf0/0xf4
[CFF0BE30] [C0052AC0] __handle_mm_fault+0x3a8/0x3ac
[CFF0BE70] [C00094A0] do_page_fault+0x118/0x428
[CFF0BF40] [C0002360] handle_page_fault+0xc/0x80
BUG: scheduling while atomic: shmtest2/0x1001/1291

Now for my questions:

1. Can the kernel really reschedule in a page fault handler context ?

2. Just to test where this "scheduling while atomic" bug is arising, i
put schedule() calls at various places in the path of the stack trace
shown above.
I found that a call to pte_alloc_map() puts the kernel in a context
where it cannot reschedule without throwing up. Here is a trace of
what's going on:

__handle_mm_fault -> hugetlb_fault -> huge_pte_alloc() -> pte_alloc_map()

Any call to schedule() before pte_alloc_map() does not throw this
error. Well, this might be a flawed experiment, I am no expert kernel
hacker. Does this throw any light on the problem?

Here are the modifications I made to Edi's patch:

arch/ppc/mm/hugetlbpage.c
struct page *
follow_huge_addr(struct mm_struct *mm, unsigned long address, int write)
{
  pte_t *pte;
  struct page *page;
+  struct vm_area_struct *vma;
+
+  vma = find_vma(mm, address);
+ if (!vma || !is_vm_hugetlb_page(vma))
+return ERR_PTR(-EINVAL);

  pte = huge_pte_offset(mm, address);
  page = pte_page(*pte);
  return page;
}

+int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr, pte_t *ptep)
+{
+return 0;
+}

Here is my test program:

#include 
#include 
#include 
#include 
#include 
#include 

#ifndef SHM_HUGETLB
#define SHM_HUGETLB 04000
#endif

#define LENGTH (16UL*1024*1024)

#define dprintf(x)  printf(x)

#define ADDR (void *)(0x0UL)
#define SHMAT_FLAGS (0)


int main(void)
{
int shmid;
unsigned long i;
char *shmaddr;

if ((shmid = shmget(2, LENGTH,
SHM_HUGETLB | IPC_CREAT | SHM_R | SHM_W)) < 0) {
perror("shmget");
exit(1);
}
printf("shmid: 0x%x\n", shmid);

shmaddr = shmat(shmid, ADDR, SHMAT_FLAGS);
if (shmaddr == (char *)-1) {
perror("Shared memory attach failure");
shmctl(shmid, IPC_RMID, NULL);
exit(2);
}
printf("shmaddr: %p\n", shmaddr);
printf("touching a huge page..\n");

shmaddr[0]='a';
shmaddr[1]='b';

if (shmdt((const void *)shmaddr) != 0) {
perror("Detach failure");
shmctl(shmid, IPC_RMID, NULL);
exit(3);
}

shmctl(shmid, IPC_RMID, NULL);

return 0;
}

thanks!
Satya.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Infinite loop/always true check possible with unsigned counter.

2007-07-10 Thread Manish Ahuja
Paul Mackerras wrote:
> Andreas Schwab writes:
>
>   
 ??? There is no rgn->cnt involved in the comparison.
 
>>> Look further down in lmb_add_region; there is a second for loop that
>>> does
>>>
>>> for (i = rgn->cnt-1; i >= 0; i--)
>>>   
>> Which is exactly the one quoted above.  I still don't see your point.
>> 
>
> You're right - my mistake.
>
> Paul.
>   
I presume the patch is good then. Do I need to change anything ?

Thanks,
Manish
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 3/4] Extend the DMA-engine API.

2007-07-10 Thread Dan Williams
On 7/10/07, Zhang Wei <[EMAIL PROTECTED]> wrote:
> Add channel wait queue and transfer callback dma_xfer_callback().
> If the DMA controller and driver support interrupt, when the
> transfer is finished, it will wakeup the wait queue
> and call the callback function of the channel.
>
> Add dma_async_raw_xfer() to API and device_raw_xfer() to struct dma_device
> for RAW physical address DMA transfer, which will be used at transfer
> between I/O address and memory address.
>

Please review the async_tx API patch series[1], it should meet your
needs.  What you call "raw" mode support is now default for the
dmaengine driver interface.  I plan to request that this series be
merged for 2.6.23.

Regards,
Dan

[1]http://marc.info/?l=linux-raid&w=2&r=1&s=md-accel&q=b
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 1/2] [ide] mmio ide support

2007-07-10 Thread Linas Vepstas
On Sun, Jul 08, 2007 at 03:15:41PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 
> > on the argument that drivers/ide/ is going away soon. Most
> > current distros have already moved over to using libata
> > exclusively.
> 
> The in-kernel default for PATA systems is still IDE subsystem.

In part because libata still does not yet work correctly 
for at least some (older) ide chipsets (like mine).

--linas
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Resend: [PATCH] oprofile support for Power 5++

2007-07-10 Thread Mike Wolf
The patch has not been included and there have been no comments so
I'm resending.

This patch adds a new oprofile cpu type for Power 5 revision 3 chips.
The new name is ppc64/power5++ and is used so that the performance
counters can be set up correctly.

Signed-off-by: Mike Wolf <[EMAIL PROTECTED]>

 
linux-2.6.18.ppc64.orig/arch/powerpc/kernel/cputable.c  2006-09-19 
22:42:06.0 -0500
+++ linux-2.6.18.ppc64/arch/powerpc/kernel/cputable.c   2007-06-11 
12:29:47.0 -0500
@@ -236,6 +236,21 @@
.oprofile_mmcra_sipr= MMCRA_SIPR,
.platform   = "power5",
},
+   {   /* Power5++ */
+   .pvr_mask   = 0xff00,
+   .pvr_value  = 0x003b0300,
+   .cpu_name   = "POWER5+ (gs)",
+   .cpu_features   = CPU_FTRS_POWER5,
+   .cpu_user_features  = COMMON_USER_POWER5_PLUS,
+   .icache_bsize   = 128,
+   .dcache_bsize   = 128,
+   .num_pmcs   = 6,
+   .oprofile_cpu_type  = "ppc64/power5++",
+   .oprofile_type  = PPC_OPROFILE_POWER4,
+   .oprofile_mmcra_sihv= MMCRA_SIHV,
+   .oprofile_mmcra_sipr= MMCRA_SIPR,
+   .platform   = "power5+",
+   },
{   /* Power5 GS */
.pvr_mask   = 0x,
.pvr_value  = 0x003b,

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v2][POWERPC] document ipic level/sense info

2007-07-10 Thread Segher Boessenkool
 +Sense and level information follows the Linux convention
 +(specified in include/linux/interrupt.h) and should be encoded
 +as follows:
 +
 +   2 =  high to low edge sensitive type enabled
 +   8 =  active low level sensitive type enabled
>>
>>> ... but it is probably worthwhile commentting that sense types 1 & 4
>>> are not supported; just to fill in the obvious gaps.  :-)
>>
>> Same for sense types 0, 3, 5, 6, ...
>>
>> Just name the sense types 0 and 1, similar to what all other
>> OF interrupt controller bindings do.
>
> Actually, all I am trying to do with this patch is document the
> current state of things.  The 2/8 sense type usage has been that
> way for a long time, and I'll defer to the 83xx maintainers
> if they see any value in changing it.
>
> Right now there are many DTS files with level/sense set to values
> like 8 and no indication anywhere where those values came from.

Ah right, too bad then.  Just document that only 2 and 8 make
sense on current hardware, in that case.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v2][POWERPC] document ipic level/sense info

2007-07-10 Thread Segher Boessenkool
>>> ... but it is probably worthwhile commentting that sense types 1 & 4
>>> are not supported; just to fill in the obvious gaps.  :-)
>>
>> Same for sense types 0, 3, 5, 6, ...
>>
>> Just name the sense types 0 and 1, similar to what all other
>> OF interrupt controller bindings do.
>
> I'm not really keen on changing the values at this point.  I think  
> we are stuck with them.

Yeah, unless you create a new binding for the same hardware.
Not that I recommend that of course.  I suppose the lesson
is to document a device binding as soon as possible, not
months after the corresponding code and trees are out (or to
mark all such code/trees clearly as "preliminary").


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: Resend: [PATCH] oprofile support for Power 5++

2007-07-10 Thread Michael Neuling

> The patch has not been included and there have been no comments so
> I'm resending.
> 
> This patch adds a new oprofile cpu type for Power 5 revision 3 chips.
> The new name is ppc64/power5++ and is used so that the performance
> counters can be set up correctly.

Does it make more sense to call this "ppc64/power5+rev3"?  

Mikey

> 
> Signed-off-by: Mike Wolf <[EMAIL PROTECTED]>
> 
>  
> linux-2.6.18.ppc64.orig/arch/powerpc/kernel/cputable.c2006-09-19 22:4
2:06.0 -0500
> +++ linux-2.6.18.ppc64/arch/powerpc/kernel/cputable.c 2007-06-11 12:29:47.000
00 -0500
> @@ -236,6 +236,21 @@
>   .oprofile_mmcra_sipr= MMCRA_SIPR,
>   .platform   = "power5",
>   },
> + {   /* Power5++ */
> + .pvr_mask   = 0xff00,
> + .pvr_value  = 0x003b0300,
> + .cpu_name   = "POWER5+ (gs)",
> + .cpu_features   = CPU_FTRS_POWER5,
> + .cpu_user_features  = COMMON_USER_POWER5_PLUS,
> + .icache_bsize   = 128,
> + .dcache_bsize   = 128,
> + .num_pmcs   = 6,
> + .oprofile_cpu_type  = "ppc64/power5++",
> + .oprofile_type  = PPC_OPROFILE_POWER4,
> + .oprofile_mmcra_sihv= MMCRA_SIHV,
> + .oprofile_mmcra_sipr= MMCRA_SIPR,
> + .platform   = "power5+",
> + },
>   {   /* Power5 GS */
>   .pvr_mask   = 0x,
>   .pvr_value  = 0x003b,
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH] fix idr_get_new_above id alias bugs

2007-07-10 Thread Jim Houston

Hi Everyone,

Hoang-Nam Nguyen reported a bug in idr_get_new_above() 
which occurred with a starting id value like 0x3ffc.
His test module easily reproduced the problem.  Thanks.

The test revealed the following bugs:

1. Relying on shift operations which have undefined results
   e.g.: 1 << n where n > word size.  On i386 an integer shift
   only uses the low 5 bits of the shift count.

2. An off by one error which prevented the top most layer
   of the radix tree from being allocated.  This meant that
   sub_alloc() would allocate an entry in the existing portion
   of the radix tree which aliased the requested address.  When
   it tried to allocate id 0x4000, it might use the slot 
   belonging to id 0.

3. There was also a failure in the code which walked back up
   the tree if an allocation failed.  The normal case is to
   descend the tree checking the starting id value against the
   bitmap at each level.  If the bit is set, we know that the
   entire sub-tree is full and we can short cut the search.
   We may still descend to the lowest level and find that the
   portion of the id space we want is full.  In this case we
   need to walk back up the tree and continue the search.
   The existing code just returned to the previous level and
   continued.  This resulted in an attempt to allocate an id
   above 0x3ffc using the slot for id 0x3c00 instead of
   0x4000 which it then claimed to have allocated.  The same
   problem occurs with 0x3ff as the requested id value if it
   is already in use.

With this patch, idr.c should work as advertised allocating id
values in the range 0...0x7fff.  Andrew had speculated that
it should allow the full range 0...0x to be used.  I was
tempted to make changes to allow this, but it would require changes
to API, e.g. making the starting id value and the return value
unsigned.

Signed-off-by: Jim Houston <[EMAIL PROTECTED]>

--

Index: linux-2.6.22-rc7/include/linux/idr.h
===
--- linux-2.6.22-rc7.orig/include/linux/idr.h   2007-04-25 23:08:32.0 
-0400
+++ linux-2.6.22-rc7/include/linux/idr.h2007-07-06 16:46:31.0 
-0400
@@ -18,17 +18,9 @@
 #if BITS_PER_LONG == 32
 # define IDR_BITS 5
 # define IDR_FULL 0xul
-/* We can only use two of the bits in the top level because there is
-   only one possible bit in the top level (5 bits * 7 levels = 35
-   bits, but you only use 31 bits in the id). */
-# define TOP_LEVEL_FULL (IDR_FULL >> 30)
 #elif BITS_PER_LONG == 64
 # define IDR_BITS 6
 # define IDR_FULL 0xul
-/* We can only use two of the bits in the top level because there is
-   only one possible bit in the top level (6 bits * 6 levels = 36
-   bits, but you only use 31 bits in the id). */
-# define TOP_LEVEL_FULL (IDR_FULL >> 62)
 #else
 # error "BITS_PER_LONG is not 32 or 64"
 #endif
Index: linux-2.6.22-rc7/lib/idr.c
===
--- linux-2.6.22-rc7.orig/lib/idr.c 2007-04-25 23:08:32.0 -0400
+++ linux-2.6.22-rc7/lib/idr.c  2007-07-10 11:05:19.0 -0400
@@ -105,8 +105,8 @@
 
id = *starting_id;
p = idp->top;
-   l = idp->layers;
-   pa[l--] = NULL;
+   l = idp->layers - 1;
+   pa[l] = NULL;
while (1) {
/*
 * We run around this while until we reach the leaf node...
@@ -117,8 +117,14 @@
if (m == IDR_SIZE) {
/* no space available go back to previous layer. */
l++;
-   id = (id | ((1 << (IDR_BITS * l)) - 1)) + 1;
-   if (!(p = pa[l])) {
+   id = (id | ((1 << (IDR_BITS * l)) - 1));
+   while (((id >> (IDR_BITS * l)) & IDR_MASK) == IDR_MASK)
+   l++;
+   id++;
+   p = pa[l-1];
+   if ((id >= MAX_ID_BIT) || (id < 0))
+   return -3;
+   if (!p) {
*starting_id = id;
return -2;
}
@@ -141,7 +147,7 @@
p->ary[m] = new;
p->count++;
}
-   pa[l--] = p;
+   pa[--l] = p;
p = p->ary[m];
}
/*
@@ -159,7 +165,7 @@
 */
n = id;
while (p->bitmap == IDR_FULL) {
-   if (!(p = pa[++l]))
+   if (!(p = pa[l++]))
break;
n = n >> IDR_BITS;
__set_bit((n & IDR_MASK), &p->bitmap);
@@ -186,7 +192,7 @@
 * Add a new layer to the top of the tree if the requested
 * id is larger than the currently allocated space.
 */
-   while ((layers < (MAX_LEVEL - 1)) && (id >= (1 << (layers*IDR_BITS {
+   while ((layers <

Re: Resend: [PATCH] oprofile support for Power 5++

2007-07-10 Thread Mike Wolf
Michael Neuling wrote:
>> The patch has not been included and there have been no comments so
>> I'm resending.
>>
>> This patch adds a new oprofile cpu type for Power 5 revision 3 chips.
>> The new name is ppc64/power5++ and is used so that the performance
>> counters can be set up correctly.
>> 
>
> Does it make more sense to call this "ppc64/power5+rev3"?  
>   
This is a change to support new counter setup for oprofile.  It may be the
same if there is a revision 4 or 5 etc.  So since the internal name was ++
I followed that convention. 
> Mikey
>
>   
>> Signed-off-by: Mike Wolf <[EMAIL PROTECTED]>
>>
>>  
>> linux-2.6.18.ppc64.orig/arch/powerpc/kernel/cputable.c   2006-09-19 22:4
>> 
> 2:06.0 -0500
>   
>> +++ linux-2.6.18.ppc64/arch/powerpc/kernel/cputable.c2007-06-11 
>> 12:29:47.000
>> 
> 00 -0500
>   
>> @@ -236,6 +236,21 @@
>>  .oprofile_mmcra_sipr= MMCRA_SIPR,
>>  .platform   = "power5",
>>  },
>> +{   /* Power5++ */
>> +.pvr_mask   = 0xff00,
>> +.pvr_value  = 0x003b0300,
>> +.cpu_name   = "POWER5+ (gs)",
>> +.cpu_features   = CPU_FTRS_POWER5,
>> +.cpu_user_features  = COMMON_USER_POWER5_PLUS,
>> +.icache_bsize   = 128,
>> +.dcache_bsize   = 128,
>> +.num_pmcs   = 6,
>> +.oprofile_cpu_type  = "ppc64/power5++",
>> +.oprofile_type  = PPC_OPROFILE_POWER4,
>> +.oprofile_mmcra_sihv= MMCRA_SIHV,
>> +.oprofile_mmcra_sipr= MMCRA_SIPR,
>> +.platform   = "power5+",
>> +},
>>  {   /* Power5 GS */
>>  .pvr_mask   = 0x,
>>  .pvr_value  = 0x003b,
>>
>> ___
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>> 

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [patch 3/6] Add 8548 CDS PCI express controller node and PCI-X device node

2007-07-10 Thread Segher Boessenkool
>   pci1: [EMAIL PROTECTED] {
>   interrupt-map-mask = <1f800 0 0 7>;

Set the mask to <1800 0 0 7>, and you need only 16
entries to encode the swizzle.  Except...

> + /* bus 1 , idsel 0x2 Tsi310 bridge secondary */

...interrupts on bus 1 should be swizzled on bus 1, not
at the PHB.  Really.  It is a horrible workaround for a
non-existing problem to do it here, and I promise you
it _will_ come back to hurt you later.  Not a threat,
just a promise :-)

> - compatible = "85xx";
> + compatible = "fsl,mpc85xx-pci","85xx";

No more "xx" please...

> + [EMAIL PROTECTED] {
> + interrupt-map-mask = ;
> + interrupt-map = <
> +
> + /* IDSEL 0x0 (PEX) */
> + 0 0 0 1 &mpic 0 1
> + 0 0 0 2 &mpic 1 0
> + 0 0 0 3 &mpic 2 0
> + 0 0 0 4 &mpic 3 0>;

Why sense 0 for all but the first entry in this map?

> + compatible = "fsl,mpc86xx-pciex","86xx";

And "xx" again.  Aren't the 85- and 86- PCIe controllers
compatible, btw?


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [patch 5/6] Update the 83xx/85xx/86xx boards device tree

2007-07-10 Thread Segher Boessenkool
> Indentify pci, pcie host by compatible property
> "fsl,mpc83xx-pci","83xx"
> "fsl,mpc85xx-pci","85xx"
> "fsl,mpc86xx-pci","86xx"
> and
> "fsl, mpc85xx-pciex","85xx"
> "fsl, mpc86xx-pciex","86xx"

This can't ever work -- if you see "compatible" = "85xx",
what is it?  PCI or PCIe?  Or something else perhaps, maybe
a CPU or an I2C controller or who-knows-what?


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: Resend: [PATCH] oprofile support for Power 5++

2007-07-10 Thread Michael Neuling
> >
> > Does it make more sense to call this "ppc64/power5+rev3"?  
> >   
> This is a change to support new counter setup for oprofile.  It may be the
> same if there is a revision 4 or 5 etc.  So since the internal name was ++
> I followed that convention. 

I'm not too fussed, but if rev 4 comes out, the counters change and we
need power5+++, it's gonna look pretty silly :-)

Mikey
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: Resend: [PATCH] oprofile support for Power 5++

2007-07-10 Thread Will Schmidt
On Tue, 2007-07-10 at 15:31 -0500, Michael Neuling wrote:
> > >
> > > Does it make more sense to call this "ppc64/power5+rev3"?  
> > >   
> > This is a change to support new counter setup for oprofile.  It may be the
> > same if there is a revision 4 or 5 etc.  So since the internal name was ++
> > I followed that convention. 

There is an oprofile change already made, or in-flight, or at least
submitted, that will be looking for the "power5++" string, so if the
string changes here, it'll need to be changed there too. 

( http://article.gmane.org/gmane.linux.oprofile/4670 )

> 
> I'm not too fussed, but if rev 4 comes out, the counters change and we
> need power5+++, it's gonna look pretty silly :-)

silly, but would be funny to see.  :-) 

> 
> Mikey
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: Resend: [PATCH] oprofile support for Power 5++

2007-07-10 Thread Maynard Johnson
Will Schmidt wrote:

> On Tue, 2007-07-10 at 15:31 -0500, Michael Neuling wrote:
> 
Does it make more sense to call this "ppc64/power5+rev3"?  
  
>>>
>>>This is a change to support new counter setup for oprofile.  It may be the
>>>same if there is a revision 4 or 5 etc.  So since the internal name was ++
I have no idea if there will be a revision 4, etc, but I'm assuming the 
behavior would be the same as rev 3.  So I'm not in favor of changing 
this string to include "rev3" in it.  But whatever decision is made, I 
hope it can be made soon.  The OProfile community is testing a release 
candidate right now that includes the userspace portion of this issue 
which checks for the string "ppc64/power5++".  We hope to GA this next 
oprofile release very soon.

Thanks.
-Maynard
>>>I followed that convention. 
> 
> 
> There is an oprofile change already made, or in-flight, or at least
> submitted, that will be looking for the "power5++" string, so if the
> string changes here, it'll need to be changed there too. 
> 
> ( http://article.gmane.org/gmane.linux.oprofile/4670 )
> 
> 
>>I'm not too fussed, but if rev 4 comes out, the counters change and we
>>need power5+++, it's gonna look pretty silly :-)
> 
> 
> silly, but would be funny to see.  :-) 
> 
> 
>>Mikey
>>___
>>Linuxppc-dev mailing list
>>Linuxppc-dev@ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-dev
> 
> 


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] ide: Use inline function for eieio

2007-07-10 Thread Bartlomiej Zolnierkiewicz

[ added Kou back to cc: ]

On Tuesday 10 July 2007, Sergei Shtylyov wrote:
> Hello.
> 
> Kumar Gala wrote:
> > Move to using inline function variant of eieio instead of inline assmebly.
> 
> > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>

applied

Please use host driver name ("scc_pata" in this case) instead of "ide" in
the patch summary if your changes are limited to a single host driver.

This helps later when going through git logs.

> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>

added

Thanks,
Bart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 0/15] bootwrapper: support for kexec to zImage

2007-07-10 Thread Milton Miller
This series creates a 32 bit zImage wrapper for a 32 or 64 bit PowerPC
Linux kernel.   This allows you to kexec a zImage with its compressed
vmlinux instead of the uncompressed vmlinux elf.  The elf is also
packaged as a 64 bit elf for use by kexec-tools for 64 bit kernels.

This series also adds code to extract the vmlinux elf file from an
initramfs (or other platform supplied location).  This allows one
to load the elf once (compressed) and use it both for userspace and
for the actual boot.

milton
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 1/15] boot: find initrd location from device-tree

2007-07-10 Thread Milton Miller
Some platforms have a boot agent that can create or modify properties in
the device-tree and load images into memory.  Provide a helper to set
loader_info used by prep_initrd().

Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
--- 
Moved to devtree.c as suggested.

define UNIT_MAX hardcoded as requested.

Print exactly why we are not propagting loader supplied initrd knowledge to
wrapper code.

Having start_prop and end_prop as variables allows several source lines
to fit in 80 columns.

Index: work.git/arch/powerpc/boot/ops.h
===
--- work.git.orig/arch/powerpc/boot/ops.h   2007-07-10 03:44:41.0 
-0500
+++ work.git/arch/powerpc/boot/ops.h2007-07-10 03:45:51.0 -0500
@@ -159,6 +159,7 @@ void dt_fixup_clock(const char *path, u3
 void __dt_fixup_mac_addresses(u32 startindex, ...);
 #define dt_fixup_mac_addresses(...) \
__dt_fixup_mac_addresses(0, __VA_ARGS__, NULL)
+void dt_find_initrd(void);
 
 
 static inline void *find_node_by_linuxphandle(const u32 linuxphandle)
Index: work.git/arch/powerpc/boot/types.h
===
--- work.git.orig/arch/powerpc/boot/types.h 2007-07-10 03:44:41.0 
-0500
+++ work.git/arch/powerpc/boot/types.h  2007-07-10 03:45:51.0 -0500
@@ -12,6 +12,8 @@ typedef short s16;
 typedef ints32;
 typedef long long  s64;
 
+#define UINT_MAX   0x
+
 #define min(x,y) ({ \
typeof(x) _x = (x); \
typeof(y) _y = (y); \
Index: work.git/arch/powerpc/boot/devtree.c
===
--- work.git.orig/arch/powerpc/boot/devtree.c   2007-07-10 03:44:41.0 
-0500
+++ work.git/arch/powerpc/boot/devtree.c2007-07-10 03:45:51.0 
-0500
@@ -1,6 +1,7 @@
 /*
  * devtree.c - convenience functions for device tree manipulation
  * Copyright 2007 David Gibson, IBM Corporation.
+ * Copyright 2007 Milton Miller, IBM Corporation.
  * Copyright (c) 2007 Freescale Semiconductor, Inc.
  *
  * Authors: David Gibson <[EMAIL PROTECTED]>
@@ -305,3 +306,68 @@ int dt_xlate_addr(void *node, u32 *buf, 
memcpy(dt_xlate_buf, buf, buflen);
return dt_xlate(node, 0, buflen / 4, xlated_addr, NULL);
 }
+
+/**
+ * dt_find_initrd - set loader initrd location based on existing properties
+ *
+ * finds the linux,initrd-start and linux,initrd-end properties in
+ * the /chosen node and sets the loader initrd fields accordingly.
+ *
+ * Use this if your loader sets the properties to allow other code to
+ * relocate the tree and/or cause r3 and r4 to be set on true OF
+ * platforms.
+ */
+void dt_find_initrd(void)
+{
+   int rc;
+   unsigned long long initrd_start, initrd_end;
+   void *devp;
+   static const char start_prop[] = "linux,initrd-start";
+   static const char end_prop[] = "linux,initrd-end";
+
+   devp = finddevice("/chosen");
+   if (! devp) {
+   return;
+   }
+
+   rc = getprop(devp, start_prop, &initrd_start, sizeof(initrd_start));
+   if (rc < 0)
+   return; /* not found */
+   /* The properties had to be 8 bytes until 2.6.22 */
+   if (rc == sizeof(unsigned long)) {
+   unsigned long tmp;
+   memcpy(&tmp, &initrd_start, rc);
+   initrd_start = tmp;
+   } else if (rc != sizeof(initrd_start)) {/* now they can be 4 */
+   printf("unexpected length of %s in /chosen!\n\r", start_prop);
+   return;
+   }
+
+   rc = getprop(devp, end_prop, &initrd_end, sizeof(initrd_end));
+   if (rc < 0) {
+   printf("chosen has %s but no %s!\n\r", start_prop, end_prop);
+   return;
+   }
+   if (rc == sizeof(unsigned long)) {
+   unsigned long tmp;
+   memcpy(&tmp, &initrd_end, rc);
+   initrd_end = tmp;
+   } else if (rc != sizeof(initrd_end)) {
+   printf("unexpected length of %s in /chosen!\n\r", end_prop);
+   return;
+   }
+
+   /* Check for presence, ignore if (partially) loaded above 32 bits */
+   if (initrd_start == initrd_end) {
+   printf("ignoring empty device-tree supplied initrd\n");
+   } else if (initrd_start > initrd_end) {
+   printf("ignoring device-tree supplied initrd: start 0x%llx"
+   " > end 0x%llx \n", initrd_start, initrd_end);
+   } else if (initrd_end > UINT_MAX) {
+   printf("ignoring device-tree supplied initrd:"
+   " end 0x%llx > 32 bits\n", initrd_end);
+   } else {
+   loader_info.initrd_addr = initrd_start;
+   loader_info.initrd_size  = initrd_end - initrd_start;
+   }
+}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.o

[PATCH 2/15] boot: record header bytes in gunzip_start

2007-07-10 Thread Milton Miller

Record the number of header bytes skipped in the total bytes read field.

This is needed for the initramfs parsing code to find the end of the zip file.

Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
--- 

Index: work.git/arch/powerpc/boot/gunzip_util.c
===
--- work.git.orig/arch/powerpc/boot/gunzip_util.c   2007-07-10 
03:44:41.0 -0500
+++ work.git/arch/powerpc/boot/gunzip_util.c2007-07-10 03:47:35.0 
-0500
@@ -78,6 +78,7 @@ void gunzip_start(struct gunzip_state *s
fatal("inflateInit2 returned %d\n\r", r);
}
 
+   state->s.total_in = hdrlen;
state->s.next_in = src + hdrlen;
state->s.avail_in = srclen - hdrlen;
 }
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 3/15] boot: simplfy gunzip_finish

2007-07-10 Thread Milton Miller

Call gunzip_partial to calculate the remaining length and copy the
data to the user buffer.   This makes it shorter and reduces
duplication.

Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
--- 

Index: work.git/arch/powerpc/boot/gunzip_util.c
===
--- work.git.orig/arch/powerpc/boot/gunzip_util.c   2007-07-10 
03:47:35.0 -0500
+++ work.git/arch/powerpc/boot/gunzip_util.c2007-07-10 03:47:39.0 
-0500
@@ -194,13 +194,10 @@ int gunzip_finish(struct gunzip_state *s
 {
int len;
 
+   len = gunzip_partial(state, dst, dstlen);
+
if (state->s.workspace) {
-   len = gunzip_partial(state, dst, dstlen);
zlib_inflateEnd(&state->s);
-   } else {
-   /* uncompressed image */
-   len = min(state->s.avail_in, (unsigned)dstlen);
-   memcpy(dst, state->s.next_in, len);
}
 
return len;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 4/15] bootwrapper: smp support code

2007-07-10 Thread Milton Miller

Support code to move cpus around, both a spin loop and c code to
move the cpus before uncompressing and copying the kernel to 0.

The low level code is designed to be included in a crt0 or other
assembly file because it may need to be at a fixed location or there
may be other entry point requirements.

Note: this code works with kernel head_64.S.   head_6xx.S needs the
0x60 entry point (it currently uses something closer to 0xC0; but
the similar code is at 0xC4); the other heads don't appear to support
SMP.

Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
--- 
Cleaned up documentation.   Hopefully the format is correct.

Removed the #if 1 #else #endif

Move hidden asm code outside function instead of branching over it.

This code has previously survied days of kexec stress and also works
when the next stage is itself (ie zBoot to zImage).

Index: work.git/arch/powerpc/boot/marshal_low.S
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ work.git/arch/powerpc/boot/marshal_low.S2007-07-10 03:48:20.0 
-0500
@@ -0,0 +1,103 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ * Copyright 2007 IBM Corporation.
+ *
+ * Authors: Milton Miller <[EMAIL PROTECTED]>
+ *
+ */
+
+#include "ppc_asm.h"
+
+   .text
+   /*
+* This code is designed to be a kexec entry point block.
+* That is, it has both code for the master cpu that begins
+* at offset 0 as linked into the image, and a sequence of
+* 0x100 bytes that, when copied to address 0, forms the
+* wait loop for slave cpus.  Each slave should have its
+* unique hardware cpu identifier in r3 before entering
+* this code.
+*/
+   .globl  master
+master: b  _zimage_start_plat
+
+   .global slave_wait
+slave_wait:
+   /* r3 cpu id, r4 slaves_wait, r5 cpu bit, r6 cpu mask word offset */
+
+   /* set our bit in the slaves mask  */
+98:lwarx   r7,r4,r6
+   or  r8,r7,r5
+   stwcx.  r8,r4,r6
+   bne 98b
+
+   and.r8,r7,r5
+   bnel-   err_slave
+
+99:lwz r7,gohere-slave_wait(r4)
+   cmpwi   0,r7,0
+   beq 99b
+   mtctr   r7
+   mr  r4,r7
+   bctr
+
+
+   .global gohere
+gohere:.long   0   /* when set the slave moves */
+
+
+err_slave:
+   stw r5,slave_error-slave_wait(4)/* no locking */
+   blr
+
+   .globl  slave_error /* set when slave detects error */
+slave_error:
+   .long   0
+
+   /*
+* The slaves may be in 32 or 64 bit mode, we don't care
+* r3 is the slave cpu number, matching the device tree.
+*/
+   .orgmaster+0x60
+   .globl  slave
+slave: bl  1f
+1: mflrr4
+   addir4,r4,slave_wait-1b /* code assumes r4=slave_wait */
+   li  r5,1
+   rlwnm   r5,r5,r3,0,31   /* bit within word */
+   rlwinm  r6,r3,32-5+2,4,29   /* word in array */
+   addir6,r6,slaves-slave_wait /* relative to r4, slave_wait */
+   b   slave_wait
+
+   .orgmaster+0x80 /* put locked bitmask data in another line */
+   .global slaves
+slaves:
+
+   .globl slaves_end;
+slaves_end = 0f
+
+#if 0
+   /* today, the 32 bit kernel starts slaves at 0xc0
+* but this limits us to cpu to 512 vs 1024
+*/
+   .orgmaster+0xc0
+0: b   slave
+#endif
+
+
+   .orgmaster+0x100/* we must fit in 0x100 bytes */
+0:
+
Index: work.git/arch/powerpc/boot/marshal.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ work.git/arch/powerpc/boot/marshal.c2007-07-10 03:48:20.0 
-0500
@@ -0,0 +1,275 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public

[PATCH 5/15] bootwrapper: occupied memory ranges

2007-07-10 Thread Milton Miller
Add a set of library routines to manage gross memory allocations.

This code uses an array in bss to store upto 32 entrys with merging
representing a range of memory below rmo_end (aka end of real mode
memory at 0).

To use this code, a platform would set rmo_end, call occupy_memory,
then then call init_malloc for fine grain allocation.

Also, an optional vmlinux_alloc.   

Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
--- 
Fixed a bug when extending across multiple ranges.

Cleaned up documentation

Index: work.git/arch/powerpc/boot/memranges.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ work.git/arch/powerpc/boot/memranges.c  2007-07-10 03:48:29.0 
-0500
@@ -0,0 +1,242 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ * Copyright IBM Corporation 2007
+ *
+ * Authors: Milton Miller <[EMAIL PROTECTED]>
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "flatdevtree.h"
+#include "page.h"
+#include "types.h"
+
+extern char _start[], _end[];
+
+void *rmo_end;
+
+static struct {
+   void *start, *end;
+} ranges[32];
+static int num_ranges;
+
+/**
+ * add_occupied_range - mark a range as occupied
+ * @start: start of range pointer
+ * @end: end of range pointer
+ *
+ * Mark the range from @start to @end as occupied.
+ * Ignore anything above rmo_end.
+ */
+void add_occupied_range(void *start, void *end)
+{
+   int i, j;
+
+   if (start == end)
+   return;
+   if (start > rmo_end)
+   return;
+   if (end > rmo_end)
+   end = rmo_end;
+   if (start > end)
+   fatal("%s: BUG: start %p > end %p\n\r", __FUNCTION__,
+   start, end);
+
+   printf("add %p %p: ", start, end);
+
+   for (i=0; i < num_ranges; i++)
+   if (start <= ranges[i].end)
+   break;
+
+   /* extend and merge any overlapping ranges */
+   if (i < num_ranges && end >= ranges[i].start) {
+   ranges[i].start = min(start, ranges[i].start);
+   for (j=i; j < num_ranges; j++)
+   if (end >= ranges[j].start)
+   end = max(end, ranges[j].end);
+   else
+   break;
+   ranges[i].end = end;
+
+   if (j == i + 1) {
+   printf("extending range %d to %p %p\n\r", i,
+   ranges[i].start, ranges[i].end);
+   } else {
+   printf("merged ranges %d to %d now %p %p\n\r", i, j,
+   ranges[i].start, ranges[i].end);
+
+   ++i;
+   memmove(&ranges[i], &ranges[j],
+   (num_ranges - j) * sizeof(ranges[0]));
+   num_ranges -= j-i;
+   }
+   } else {
+   /* insert a new range */
+   if (num_ranges >= ARRAY_SIZE(ranges) - 1)
+   fatal("Too many memory ranges to track\n");
+
+   printf("inserting range %d between %p and %p\n\r",
+   i, i ? ranges[i-1].end : 0,
+   i == num_ranges ? rmo_end : ranges[i].start);
+
+   memmove(&ranges[i+1], &ranges[i],
+   (num_ranges - i) * sizeof(ranges[0]));
+   num_ranges++;
+
+   ranges[i].start = start;
+   ranges[i].end = end;
+   }
+}
+
+/**
+ * add_occupied_range_ulong - mark a range as occupied
+ * @start: start of block to occupy
+ * @end: start of block to occupy
+ *
+ * Call add_occupied_range() after casting to ulong @start and @end to
+ * void * pointers.
+ */
+void add_occupied_range_ulong(unsigned long start, unsigned long end)
+{
+   add_occupied_range((void *)start, (void *)end);
+}
+
+/**
+ * add_known_ranges - occupy some known regions
+ * @dt_blob: a flattend device tree to occupy, or NULL to skip
+ *
+ * call add_occupied_range() for the wrapper, loader supplied initrd,
+ * and, if not %NULL, the device tree blob @dt_blob and any reserved
+ * memory ranges therein.
+ */
+void add_known_ranges(struct boot_param_header *dt_blob)
+{
+   unsigned long long rstart, rlen

[PATCH 6/15] bootwrapper: switch 64 bit cpus to 32 bit mode

2007-07-10 Thread Milton Miller
Add code to check if the processor is in 64 or 32 bit mode using
only instructions from the 32 bit subset.  If the processor is in
64 bit mode, switch to 32 bit mode by clearing MSR[SF].

Also add a 64 bit procedure descriptor to use as a elf64 entry
point.

Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
--- 
Merged into crt0.S instead of a separate file with a separate entry
point.

Index: kernel/arch/powerpc/boot/crt0.S
===
--- kernel.orig/arch/powerpc/boot/crt0.S2007-07-10 03:33:36.0 
-0500
+++ kernel/arch/powerpc/boot/crt0.S 2007-07-10 03:39:08.0 -0500
@@ -17,11 +17,47 @@
 _zimage_start_opd:
.long   _zimage_start, 0, 0, 0
 
+   /* a procedure descriptor used when pretending to be elf64_powerpc */
+   .balign 8
+   .globl  _zimage_start_64
+_zimage_start_64:
+   .long   0, _zimage_start/* big endian, supported reloc ppc32 */
+   .long   0, 0, 0, 0, 0, 0
+
+
.weak   _zimage_start
.globl  _zimage_start
 _zimage_start:
.globl  _zimage_start_lib
 _zimage_start_lib:
+   /* Check if the processor is running in 32 bit mode, using
+* only 32 bit instructions which should be safe on 32 and
+* 64 bit processors.
+*
+* Subtract the bottom 32 bits of MSR from the full value
+* recording the result.  Since MSR[SF] is in the high word,
+* the result will be not-equal iff in 32 bit mode (either
+* the processor is a 32 bit processor or MSR[SF] = 0).
+*/
+   mfmsr   r0  /* grab whole msr   */
+   rlwinm  r8,r0,0,0,31/* extract bottom word  */
+   subf.   r8,r8,r0/* subtract, same?  */
+   beq 0f  /* yes: we are 32 bit mode  */
+
+   /* We are in 64-bit mode.  This program must run in 32 bit
+* mode.  Assume we are actually running somewhere in the
+* low 32 bits of the address space, so we can just turn
+* off MSR[SF] which is bit 0.
+*/
+   .machine push
+   .machine "ppc64"
+   rldicl  r0,r0,0,1
+   sync
+   mtmsrd  r0
+   isync
+   .machine pop
+0: /* We are now in 32-bit mode */
+
/* Work out the offset between the address we were linked at
   and the address where we're running. */
bl  1f
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 7/15] bootwrapper: Add kexec callable zImage wrapper

2007-07-10 Thread Milton Miller

This code creates a 32 bit zImage wrapper for a 32 or 64 bit PowerPC
Linux kernel.   This allows you to kexec a zImage with its compressed
vmlinux instead of the uncompressed vmlinux elf.  The elf is also
packaged as a 64 bit elf for use by kexec-tools for 64 bit kernels.

Limitations:

The memory node off the root with a name starting with "memory" must
contain enough free memory (not in the reserved ranges) in the first
reg range to uncompress the the kernel with padding.

Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
I split a few more routines out from this file.

I removed the call serial_console_init because some of the serial
console require a loader supplied virtural address mapping which
will not exist when called from kexec.

Successfully boots from and to a 64 bit kernel when loaded at 0 and
when loaded after the kernel _end on machines with with initrds,
rtas, and various other data reserved.

The next patch needed to load using kexec-tools without an externally
generated flat device tree.

Index: work.git/arch/powerpc/boot/kexec.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ work.git/arch/powerpc/boot/kexec.c  2007-07-10 16:37:30.0 -0500
@@ -0,0 +1,181 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ * Copyright IBM Corporation 2007
+ *
+ * Authors: Milton Miller <[EMAIL PROTECTED]>
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "flatdevtree.h"
+#include "page.h"
+#include "types.h"
+
+extern char _start[];
+extern char _end[];
+
+BSS_STACK(16*1024);
+
+static void find_console_from_tree(void)
+{
+   int rc = -1;
+
+   if (rc) {
+   /* no console, oh well */
+   }
+}
+
+/* fixme: use find_device_by_type "memory" and xlate_reg */
+static void find_rmo_end(void)
+{
+   unsigned int na, ns, reg[4], *rp;
+   void *devp;
+   int rc;
+
+   devp = finddevice("/");
+   if (!devp)
+   fatal("Ack, device-tree root");
+   rc = getprop(devp, "#address-cells", &na, sizeof(na));
+   if (rc != sizeof(na))
+   fatal("Ack, no #address-cells in root");
+   rc = getprop(devp, "#size-cells", &ns, sizeof(ns));
+   if (rc != sizeof(ns))
+   fatal("Ack, no #size-cells in root");
+   if (!na || !ns || na + ns > ARRAY_SIZE(reg))
+   fatal("#addr-cells or #size-cells unusable");
+   do {
+   devp = finddevice("/[EMAIL PROTECTED]");
+   if (!devp)
+   devp = finddevice("/memory");
+   if (!devp)
+   devp = finddevice("/[EMAIL PROTECTED]");
+   if (!devp)
+   devp = finddevice("/[EMAIL PROTECTED]");
+   if (!devp)
+   fatal("Ack, can't find  memory");
+   rc = getprop(devp, "reg", reg, sizeof(reg));
+   if (rc < (na + ns) * sizeof(int))
+   fatal("Ack, no valid reg property in memory");
+
+   rp = ®[0];
+   while (na--) {
+   if (*rp)
+   fatal("didn't find memory at 0");
+   rp++;
+   }
+   while (--ns) {
+   if (*rp) {
+   /* first range >= 4G , use 2G */
+   rmo_end = (void *)0x8000;
+   return;
+   }
+   rp++;
+   }
+   } while (0);
+
+   rmo_end = (void *)*rp;
+}
+
+/**
+ * setup_initial_heap - setup a small heap in the bss
+ * Using a preallocated heap, setup for scanning the device tree.
+ * Intended for the initial read while the tree will remain read-only so
+ * a minimal malloc and search limit can be used.  This way we don't have
+ * lots of data or bss to clear.
+ */
+static void setup_initial_heap(void)
+{
+   static char initial_heap[8*1024];
+   void *heap_end;
+
+   heap_end = simple_alloc_init(initial_heap,
+   sizeof(initial_heap) * 7 / 8,
+   sizeof(long), 64);
+
+   if (heap_end - sizeof(initial_heap) > (void *)&initial_heap[0])
+   fatal("Initial heap too big\n\r");
+}
+
+static void

[PATCH 8/15] bootwrapper: convert flatdevtree to version 16

2007-07-10 Thread Milton Miller
kexec-tools still produces a version 2 device tree, while the
libraries in the wrapper only support version 16 and later.

Add a routine to convert a v2 flat device tree to a v16 one inplace
by inserting OF_DT_NOP and chomping full path.  Make space for new
headers by moving and then chomping the OF_DT_NOPs.

Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
Rediffed Makefile

Index: work.git/arch/powerpc/boot/flatdevtree_conv.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ work.git/arch/powerpc/boot/flatdevtree_conv.c   2007-07-10 
16:08:20.0 -0500
@@ -0,0 +1,280 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ * Copyright IBM Corporation 2007
+ *
+ * Authors: Milton Miller <[EMAIL PROTECTED]>
+ */
+#include "flatdevtree.h"
+#include "stdio.h"
+#include "ops.h"
+
+#define MIN_VERSION 2
+#define OUT_VERSION 16
+#define OUT_COMPAT 16
+
+#ifdef NO_CHECK
+static int check_v123_tree(u32 *start, u32 *limit)
+{
+   return 0;
+}
+#else
+/**
+ * check_v123_tree - check integrety of a version 1, 2, or 3 tree
+ * @start: the start of the device tree struct
+ * @limit: the end of the region for the struct
+ * structural checks on device_tree
+ */
+static int check_v123_tree(u32 *start, u32 *limit)
+{
+   u32 len;
+   int depth = 0;
+   u32 *dtp = start;
+
+   while (dtp < limit)
+   switch (*dtp) {
+   case OF_DT_END:
+   if (depth)
+   return -1;
+   return ++dtp - start;
+   case OF_DT_NOP:
+   dtp++;
+   break;
+   case OF_DT_END_NODE:
+   dtp++;
+   depth--;
+   break;
+   case OF_DT_BEGIN_NODE:
+   len = strlen((char *)(++dtp));
+   /* check path is suffix to previous? */
+   dtp += 1 + (len / 4);
+   depth++;
+   break;
+   case OF_DT_PROP:
+   len = dtp[1];
+   dtp += 3;
+   if ((len >= 8) && ((long)dtp & 4))
+   dtp++;
+   dtp += (len + 3) / 4;
+   break;
+   default:
+   return -1;
+   }
+   return -1;  /* no OF_DT_END */
+}
+#endif
+
+/**
+ * nop_to_v16 - add %OF_DT_NOP to hide alignment differences
+ * @dtp: pointer to the beginning of the struct area to modify
+ * insert %OF_DT_NOP into the dt_struct @dtp to make it v16 from v1, 2, or 3.
+ */
+static int nop_to_v16(u32 *dtp)
+{
+   int nops = 0;
+   char *p, *s;
+   int len;
+   u32 *next;
+
+   while (*dtp != OF_DT_END)
+   switch (*dtp) {
+   case OF_DT_BEGIN_NODE:
+   /* v2 & v3 names are full path, v16+ is relative */
+   p = (char *)(++dtp);
+   len = strlen(p);
+   next = dtp + 1 + len / 4;
+
+   for (s = p + len; *s != '/'; s--)
+   if (s == p)
+   fatal("name %s has no '/'", p);
+
+   len -= s++ - p; /* not the slash but the nul */
+   memmove(p, s, len);
+   while (len % 4)
+   p[len++] = '\0';
+   dtp += len / 4;
+   while (dtp != next) {
+   *dtp++ = OF_DT_NOP;
+   nops++;
+   }
+   break;
+   case OF_DT_PROP:
+   /* convert from align_8 to align_4 via prefixing nop */
+   len = dtp[1];
+   if ((len >= 8) && !((long)dtp & 4)) {
+   memmove(dtp+1, dtp, 12);
+   *dtp++ = OF_DT_NOP;
+   nops++;
+   }
+   dtp += 3 + (len + 3)/4;
+   break;
+   default:
+   fatal("%s: unrecogni

[PATCH 9/15] bootwrapper: rtas support

2007-07-10 Thread Milton Miller
This code provides a console write that calls put-term-char.

To avoid PIC relocation of the absolute rtas addresses, hide the
actual call to rtas in assembly and declare all variables as int.

An instantiated rtas will be protected by a reserved range in the
device tree, so no explicit call to add_occupied_range is needed
here.

Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
--- 
Removed use_call_rtas(); instead put asm() at the file level.

Index: work.git/arch/powerpc/boot/rtas.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ work.git/arch/powerpc/boot/rtas.c   2007-07-10 04:39:43.0 -0500
@@ -0,0 +1,146 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ * Copyright 2007 IBM Corporation.
+ *
+ * Authors: Milton Miller <[EMAIL PROTECTED]>
+ *
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "flatdevtree.h"
+
+static int rtas_entry;
+static int rtas_base;
+static int rtas_size;
+
+static void find_rtas(void)
+{
+   int rc;
+   void *devp;
+   char *str;
+
+   devp = finddevice("/rtas");
+   if (! devp)
+   return;
+
+   str = "linux,rtas-entry";
+   rc = getprop(devp, str, &rtas_entry, sizeof(rtas_entry));
+   if (rc < 0)
+   return;
+   if (rc != sizeof(rtas_entry))
+   goto fail;
+
+   str = "rtas-size";
+   rc = getprop(devp, str, &rtas_size, sizeof(rtas_size));
+   if (rc < 0)
+   return;
+   if (rc != sizeof(rtas_size))
+   goto fail;
+
+   str = "linux,rtas-base";
+   rc = getprop(devp, str, &rtas_base, sizeof(rtas_base));
+   if (rc < 0) {
+   printf("rtas-size but no linux,rtas-base in /rtas.  "
+   "disabling wrapper rtas interface\n\r");
+   rtas_entry = 0;
+   return;
+   }
+
+   if (rc != sizeof(rtas_base))
+   goto fail;
+
+   return;
+
+
+fail:
+   printf("Unexpected length %d of %s property in /rtas.\n\r"
+   "disabling wrapper rtas interface\n\r", rc, str);
+   rtas_entry = 0;
+   return;
+}
+
+/*
+ * PIC relocation of function pointers happens at call time.
+ * We have an absolute out-of-image address.   So tell C they
+ * are just integers, and hide the call as an out-of-file
+ * function.
+ */
+__asm__ (
+   "   .globl call_rtas\n"
+   "   call_rtas: mtctr 5\n"
+   "   bctr\n"
+   );
+
+void call_rtas(int args[], int base, int entry);
+
+
+static int put_term_char;
+
+static void rtas_put_term_write(const char *buf, int len)
+{
+   int i, args[5];
+
+   args[0] = put_term_char;
+   args[1] = 1;/* num inputs */
+   args[2] = 1;/* num outputs */
+
+   for (i=0; i < len; ) {
+   args[3] = buf[i];
+   args[4] = 0;
+
+   call_rtas(args, rtas_base, rtas_entry);
+   if (args[4] == 0)   /* SUCCESS */
+   i++;
+   else if (args[4] == -1) /* HARDWARE_ERROR */
+   break;
+   /* else retry */
+   }
+}
+
+int rtas_console_init(void)
+{
+   void *devp;
+   int rc;
+
+
+   devp = finddevice("/rtas");
+   if (!devp)
+   return -1;
+
+   if (!rtas_entry)
+   find_rtas();
+   if (!rtas_entry)
+   return -1;
+
+   rc = getprop(devp, "put-term-char", &put_term_char,
+   sizeof(put_term_char));
+   if (rc == sizeof(put_term_char))
+   console_ops.write = rtas_put_term_write;
+   else
+   put_term_char = -1;
+
+   return put_term_char == -1 ? -1 : 0;
+}
+
+/* for debug, hard code */
+void use_rtas_console(int entry, int base, int tc)
+{
+   rtas_entry = entry;
+   rtas_base = base;
+   put_term_char = tc;
+   console_ops.write = rtas_put_term_write;
+}
Index: work.git/arch/powerpc/boot/ops.h
===
--- work.git.orig/arch/powerpc/boot/ops.h   2007-07-10 04:39:43.0 
-0500
+++ work.git/arch/powerpc/boot/ops.h2007-07-10 04:40:11.0 -0500
@@ -94,6 +94,8 @@ void flush_cache(void *, 

[PATCH 10/15] bootwrapper: add cpio file extraction library.

2007-07-10 Thread Milton Miller
Add a library to search through a cpio or initramfs to a specified
path contained in a cpio.

Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
--- 
Status: tested and working.  

This file is designed to also be usable in a stand alone user space
application.

Index: work.git/arch/powerpc/boot/cpio.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ work.git/arch/powerpc/boot/cpio.c   2007-07-10 04:03:40.0 -0500
@@ -0,0 +1,306 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ * Copyright 2007 IBM Corporation.
+ *
+ * Authors: Milton Miller <[EMAIL PROTECTED]>
+ *
+ */
+
+#include "cpio.h"
+#include "string.h"
+
+struct cpio_header {
+   char ino[8];
+   char mode[8];
+   char uid[8];
+   char gid[8];
+   char nlink[8];
+   char mtime[8];
+   char filesize[8];
+   char maj[8];
+   char min[8];
+   char rmaj[8];
+   char rmin[8];
+   char namesize[8];
+   char chksum[8];
+} cpio_header_buf;
+
+static int check_magic(char magic[6])
+{
+   return !memcmp(magic,"070701",6) || !memcmp(magic,"070702",6);
+}
+
+static int read_magic(struct gunzip_state *stream)
+{
+   int len;
+   char magic[6];
+
+   len = gunzip_partial(stream, magic, sizeof(magic));
+   if (len == 0)
+   return 0;
+
+   if (len == sizeof(magic) && check_magic(magic))
+   return len;
+
+
+   /* Not the right magic or short read.  We might have stumbled
+* onto a compressed archive immediately following an
+* uncompressed one, or just some NUL bytes at the end of the
+* archive.  Inform the higher layers by the negative length.
+*/
+   return -len;
+}
+
+static int get_cpio_header(struct gunzip_state *stream)
+{
+   int len;
+
+   len = read_magic(stream);
+   if (len <= 0)
+   return len;
+
+   gunzip_exactly(stream, &cpio_header_buf, sizeof(cpio_header_buf));
+   len += sizeof(cpio_header_buf);
+
+   return len;
+}
+
+static unsigned int cpio_str_to_num(char hexascii[8])
+{
+   unsigned int num = 0;
+   char c;
+   int d;
+
+   for (d=0; d < 8; d++) {
+   c = hexascii[d];
+   num <<= 4;
+   if (c >= '0' && c <= '9') {
+   num += c - '0';
+   } else if (c >= 'A' && c <= 'F') {
+   num += c - 'A' + 10;
+   } else if (c >= 'a' && c <= 'f') {
+   num += c - 'a' + 10;
+   } else {
+   cpio_error("bad cpio archive header: "
+   "invalid a hex digit");
+   }
+   }
+
+   return num;
+}
+
+static char name_buf[MAX_PATH+1];
+static const char cpio_end[] = "TRAILER!!!";
+#define CPIO_END_LEN sizeof(cpio_end)
+
+/* check_next_file
+ * Look for @path in @stream.  Set @consumed to the number of bytes
+ * succesfully read and processed.  return 1 on match, 0 for discarding
+ * an unmatched file, -1 on end of archive (either detected trailer or
+ * EOF on stream), or -(1 + bytes read) for a short read or bad magic
+ * number.  (For the short or bad read, the consumed is not changed).
+ */
+static int check_next_file(char *path, int pathlen,
+   struct gunzip_state *stream, int *consumed)
+{
+   int len, total, match;
+
+   if (pathlen > MAX_PATH) {
+   cpio_error("path too long to search\n");
+   }
+   total = get_cpio_header(stream);
+   if (total <= 0)
+   return total - 1;
+
+   len = cpio_str_to_num(cpio_header_buf.namesize);
+
+   if (len == pathlen || len == CPIO_END_LEN) {
+   gunzip_exactly(stream, name_buf, len);
+   total += len;
+   match = !strcmp(name_buf, path);
+   if (!match && !cpio_str_to_num(cpio_header_buf.filesize))
+   match = -!strcmp(name_buf, cpio_end);
+   } else {
+   gunzip_discard(stream, len);
+   total += len;
+   name_buf[0] = '\0';
+   match = 0;
+   }
+
+   len = total % 4;
+   if (len) {
+   gunzip_discard(stream, 4 - len);
+   total += 4 - len;
+   }
+
+   

[PATCH 11/15] bootwrapper: allow vmlinuz to be an external payload

2007-07-10 Thread Milton Miller
Allow the boot wrapper to obtain the vmlinux elf from an external
platform supplied location instead of embedding it at link time.

When used with the cpio library, the kernel can be stored as a file
an file in the initramfs, allowing the same (compressed) copy of
the vmlinux elf to be used for both the kernel to execute and any
user space tools such as kexec (for reboot), crash dump, or oprofile.

Another use would be to uncompress directly from a memory mapped
region such as a flash partition.

Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
--- 
Check for no find_vmlinuz method before calling it.

The source and source len varables are passed to the routine only
to allow them to be printed later.

This patch follows the current policy of using linker attached data
in preference to platform supplied data (matching the initrd and
command line).

While the platform could supply archive-start, length, and offset,
in loader data, it would require decompressing the skiped portion
twice when the offset is not known in advance.

The prpmc2800 code shows that this hook to find the kernel and the
the code to uncompress the header may want to be separated from the
vmlinux alloc, decompress, and flush code.  I haven't explored an
actual split.

Index: work.git/arch/powerpc/boot/main.c
===
--- work.git.orig/arch/powerpc/boot/main.c  2007-07-10 03:44:40.0 
-0500
+++ work.git/arch/powerpc/boot/main.c   2007-07-10 04:04:02.0 -0500
@@ -47,10 +47,19 @@ static struct addr_range prep_kernel(voi
struct elf_info ei;
int len;
 
-   /* gunzip the ELF header of the kernel */
-   gunzip_start(&gzstate, vmlinuz_addr, vmlinuz_size);
-   gunzip_exactly(&gzstate, elfheader, sizeof(elfheader));
+   /* Initialze zlib.  Any attached kernel overrides find_vmlinuz */
+   if (vmlinuz_size)
+   gunzip_start(&gzstate, vmlinuz_addr, vmlinuz_size);
+   else
+   if (platform_ops.find_vmlinuz)
+   platform_ops.find_vmlinuz(&gzstate, &vmlinuz_addr,
+   &vmlinuz_size);
+   else
+   fatal("Can't find a kernel to boot: no attached "
+   "vmlinuz and no find_vmlinuz method\n\r");
 
+   /* gunzip and parse the ELF header of the kernel */
+   gunzip_exactly(&gzstate, elfheader, sizeof(elfheader));
if (!parse_elf64(elfheader, &ei) && !parse_elf32(elfheader, &ei))
fatal("Error: not a valid PPC32 or PPC64 ELF file!\n\r");
 
Index: work.git/arch/powerpc/boot/ops.h
===
--- work.git.orig/arch/powerpc/boot/ops.h   2007-07-10 04:01:57.0 
-0500
+++ work.git/arch/powerpc/boot/ops.h2007-07-10 04:04:02.0 -0500
@@ -24,6 +24,8 @@ typedef void (*kernel_entry_t)(unsigned 
 
 struct boot_param_header;
 
+struct gunzip_state;
+
 /* Platform specific operations */
 struct platform_ops {
void(*fixups)(void);
@@ -33,6 +35,8 @@ struct platform_ops {
void *  (*realloc)(void *ptr, unsigned long size);
void(*exit)(void);
void *  (*vmlinux_alloc)(unsigned long size);
+   void(*find_vmlinuz)(struct gunzip_state *, void **srcp,
+   unsigned long *lenp);
 };
 extern struct platform_ops platform_ops;
 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 12/15] bootwrapper: extract the vmlinux from initramfs

2007-07-10 Thread Milton Miller
Teach the kexec platform to find the vmlinux from the initramfs.

The implementation searches the initramfs for a file specified
by the boot-file property in chosen.


Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
--- 
Status: working.

Index: work.git/arch/powerpc/boot/kexec.c
===
--- work.git.orig/arch/powerpc/boot/kexec.c 2007-07-10 04:01:57.0 
-0500
+++ work.git/arch/powerpc/boot/kexec.c  2007-07-10 04:04:09.0 -0500
@@ -23,6 +23,8 @@
 #include "flatdevtree.h"
 #include "page.h"
 #include "types.h"
+#include "cpio.h"
+#include "stat.h"
 
 extern char _start[];
 extern char _end[];
@@ -92,6 +94,51 @@ static void find_rmo_end(void)
rmo_end = (void *)*rp;
 }
 
+void find_vmlinux_in_initramfs(struct gunzip_state *state,
+   void **srcp, unsigned long *lenp)
+{
+   void *devp;
+   int rc;
+   char path[MAX_PATH];
+
+   if (!loader_info.initrd_size)
+   dt_find_initrd();
+   if (!loader_info.initrd_size)
+   fatal("find_vmlinux: no initramfs");
+   devp = finddevice("/chosen");
+   if (!devp)
+   fatal("find_vmlinux: no /chosen to find vmlinux");
+   rc = getprop(devp, "boot-file", path, sizeof(path));
+   if (rc < 0)
+   fatal("find_vmlinux: no boot-file property in /chosen")
+   else if (rc == 0 || rc > MAX_PATH)
+   fatal("boot-file too long in /chosen")
+
+   rc = find_in_initramfs(path, (void *)loader_info.initrd_addr,
+   loader_info.initrd_size, state);
+   if (!rc)
+   fatal("find_vmlinux: couldn't find boot-file %s in initramfs",
+   path);
+
+   rc = get_cpio_file_mode();
+   if (!S_ISREG(rc))
+   fatal("find_vmlinux: boot-file %s is not a regular file",
+   path)
+
+   get_cpio_info(srcp, &rc);
+   *lenp = get_cpio_file_size();
+}
+
+void cpio_error(char *msg)
+{
+   void *srcp;
+   int read;
+
+   get_cpio_info(&srcp, &read);
+
+   fatal("cpio_error at %p + 0x%x(%d): %s", srcp, read, read, msg);
+}
+
 /**
  * setup_initial_heap - setup a small heap in the bss
  * Using a preallocated heap, setup for scanning the device tree.
@@ -178,6 +225,7 @@ void kexec_platform_init(struct boot_par
ranges_init_malloc();
init_flat_tree(dt_blob);
 
+   platform_ops.find_vmlinuz = find_vmlinux_in_initramfs;
platform_ops.vmlinux_alloc = kexec_vmlinux_alloc;
platform_ops.fixups = kexec_fixups;
finalize_chain = dt_ops.finalize;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 13/15] bootwrapper: attach an empty vmlinux

2007-07-10 Thread Milton Miller
Allow the boot wrapper code to be linked without an attached vmlinux.

Rather than invent a new syntax to invoke the wrapper, attach the
stripped version of empty.o, which produces the same result.

This new intermediary is called zBoot.

Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
--- 
Initial attempts to remove the dependency on vmlinux in the arch Makefile
have lead to multiple make commands competing in the boot directory and
destroying each other.

Index: work.git/arch/powerpc/boot/Makefile
===
--- work.git.orig/arch/powerpc/boot/Makefile2007-07-10 16:38:01.0 
-0500
+++ work.git/arch/powerpc/boot/Makefile 2007-07-10 16:41:01.0 -0500
@@ -124,7 +124,8 @@ endif
 # args (to if_changed): 1 = (this rule), 2 = platform, 3 = dts 4=dtb 5=initrd
 quiet_cmd_wrap = WRAP$@
   cmd_wrap =$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
-   $(if $3, -s $3)$(if $4, -d $4)$(if $5, -i $5) vmlinux
+   $(if $3, -s $3)$(if $4, -d $4)$(if $5, -i $5) \
+   $(if $6,$6,vmlinux)
 
 kexec-$(CONFIG_PPC32)  += zImage.kexec
 kexec-$(CONFIG_PPC64)  += zImage.kexec64
@@ -142,6 +143,7 @@ image-$(CONFIG_PPC_PRPMC2800)   += zImage
 image-$(CONFIG_PPC_ISERIES)+= zImage.iseries
 image-$(CONFIG_DEFAULT_UIMAGE) += uImage
 image-$(CONFIG_KEXEC)  += $(kexec-y)
+image-$(CONFIG_KEXEC)  += $(patsubst zImage%,zBoot%,$(kexec-y))
 
 ifneq ($(CONFIG_DEVICE_TREE),"")
 image-$(CONFIG_PPC_83xx)   += cuImage.83xx
@@ -190,6 +192,9 @@ $(obj)/vmlinux.strip: vmlinux
 $(obj)/zImage.iseries: vmlinux
$(STRIP) -s -R .comment $< -o $@
 
+$(obj)/zBoot.%: $(wrapperbits)
+   $(call if_changed,wrap,$*$(obj)/empty.o)
+
 $(obj)/zImage.ps3: vmlinux  $(wrapper) $(wrapperbits) 
$(srctree)/$(src)/dts/ps3.dts
$(STRIP) -s -R .comment $< -o vmlinux.strip
$(call cmd,wrap,ps3,$(srctree)/$(src)/dts/ps3.dts,,)
@@ -227,7 +232,7 @@ clean-files += $(image-) $(initrd-) zIma
treeImage.* $(kexec-)
 
 # clean up files cached by wrapper
-clean-kernel := vmlinux.strip vmlinux.bin
+clean-kernel := vmlinux.strip vmlinux.bin empty.o.bin
 clean-kernel += $(addsuffix .gz,$(clean-kernel))
 # If not absolute clean-files are relative to $(obj).
 clean-files += $(addprefix $(objtree)/, $(clean-kernel))
Index: work.git/arch/powerpc/boot/wrapper
===
--- work.git.orig/arch/powerpc/boot/wrapper 2007-07-10 16:37:30.0 
-0500
+++ work.git/arch/powerpc/boot/wrapper  2007-07-10 16:41:01.0 -0500
@@ -161,6 +161,13 @@ ps3)
 ;;
 esac
 
+if [ "$kernel" = $object/empty.o ] ; then
+ext=bin
+objflags="-O binary"
+gzip=
+fi
+
+
 vmz="$tmpdir/`basename \"$kernel\"`.$ext"
 if [ -z "$cacheit" -o ! -f "$vmz$gzip" -o "$vmz$gzip" -ot "$kernel" ]; then
 ${CROSS}objcopy $objflags "$kernel" "$vmz.$$"
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH 14/15] boot: add a hook to start cpus

2007-07-10 Thread Milton Miller
The kexec code is doing strange contortions with dtops.finalize and
platform_ops.vmlinux_alloc to manage the slave cpus.   Add a hook
with the needed information.

Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
Index: work.git/arch/powerpc/boot/kexec.c
===
--- work.git.orig/arch/powerpc/boot/kexec.c 2007-07-10 04:39:43.0 
-0500
+++ work.git/arch/powerpc/boot/kexec.c  2007-07-10 04:40:01.0 -0500
@@ -180,32 +180,11 @@ static void init_flat_tree(struct boot_p
fatal("Unable to initialize device_tree library!\n\r");
 }
 
-static void *saved_vmlinux_addr;
-
-static void *kexec_vmlinux_alloc(unsigned long size)
-{
-   void *addr;
-
-   addr = ranges_vmlinux_alloc(size);
-
-   saved_vmlinux_addr = addr;
-   return addr;
-}
-
 static void kexec_fixups(void)
 {
wait_slaves_moved();
 }
 
-static unsigned long (*finalize_chain)(void);
-
-static unsigned long kexec_finalize(void)
-{
-   send_slaves_to_kernel(saved_vmlinux_addr);
-
-   return finalize_chain();
-}
-
 void kexec_platform_init(struct boot_param_header *dt_blob)
 {
slaves_are_low();
@@ -226,8 +205,7 @@ void kexec_platform_init(struct boot_par
init_flat_tree(dt_blob);
 
platform_ops.find_vmlinuz = find_vmlinux_in_initramfs;
-   platform_ops.vmlinux_alloc = kexec_vmlinux_alloc;
+   platform_ops.vmlinux_alloc = ranges_vmlinux_alloc;
platform_ops.fixups = kexec_fixups;
-   finalize_chain = dt_ops.finalize;
-   dt_ops.finalize = kexec_finalize;
+   platform_ops.start_smp = send_slaves_to_kernel;
 }
Index: work.git/arch/powerpc/boot/main.c
===
--- work.git.orig/arch/powerpc/boot/main.c  2007-07-10 04:39:43.0 
-0500
+++ work.git/arch/powerpc/boot/main.c   2007-07-10 04:39:43.0 -0500
@@ -212,6 +212,9 @@ void start(void)
else
printf(" using OF tree (promptr=%p)\n\r", loader_info.promptr);
 
+   if (platform_ops.start_smp)
+   platform_ops.start_smp(vmlinux.addr);
+
if (console_ops.close)
console_ops.close();
 
Index: work.git/arch/powerpc/boot/ops.h
===
--- work.git.orig/arch/powerpc/boot/ops.h   2007-07-10 04:39:43.0 
-0500
+++ work.git/arch/powerpc/boot/ops.h2007-07-10 04:39:43.0 -0500
@@ -35,6 +35,7 @@ struct platform_ops {
void *  (*realloc)(void *ptr, unsigned long size);
void(*exit)(void);
void *  (*vmlinux_alloc)(unsigned long size);
+   void(*start_smp)(void *vmlinux);
void(*find_vmlinuz)(struct gunzip_state *, void **srcp,
unsigned long *lenp);
 };
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH/EXAMPLE 15/15] bootwrapper: example sreset marshalling

2007-07-10 Thread Milton Miller

An example using the marshalling code that can be entered by sreset.
By linking the marshalling code is at 0 and differentiating a cpu
id from a device tree, it also works for kexec.

Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
--- 
For reference only, not intended to be merged.

Index: work.git/arch/powerpc/boot/crt0_sample.S
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ work.git/arch/powerpc/boot/crt0_sample.S2007-07-10 16:47:25.0 
-0500
@@ -0,0 +1,73 @@
+/*
+ * Copyright 2006-2007 Milton Miller, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+   /*
+* This can be either a kexec started image or a sreset initiated
+* one.  kexec-tools purgatory is suppposed to copy from entry
+* point, but instead copies from image start, so put marshal_low
+* at address 0.
+*/
+
+   .globl _zimage_start
+_zimage_start:
+#include "marshal_low.S"
+
+   .org 0x100
+   bl  get_cpu_id
+1: mflr0
+   lis r4,[EMAIL PROTECTED]
+   addir4,r4,[EMAIL PROTECTED]
+   subfr0,r4,r0
+
+   lis r4,[EMAIL PROTECTED]
+   addir4,r4,[EMAIL PROTECTED]
+   add r4,r4,r0
+2: lwarx   r6,r0,r4
+   cmpwi   r6,0
+   bge 3f
+   stwcx.  r3,r0,r4
+   bne-2b
+   lwz r6,0(r4)
+
+3: lis r4,[EMAIL PROTECTED]
+   addir4,r4,[EMAIL PROTECTED]
+   add r4,r4,r0
+4: lwarx   r12,r0,r4
+   addir12,r12,1
+   stwcx.  r12,r0,r4
+   bne-4b
+
+   cmpwr6,r3
+   bne slave
+
+   mr  r4,r0
+   li  r5,0
+   b   master
+
+
+   .globl  _zimage_start_plat
+_zimage_start_plat:
+   b   _zimage_start_lib
+
+   .weak   get_cpu_id
+get_cpu_id:
+
+get_pir:
+   mfspr   r3,1023 /* SPRN_PIR */
+   blr
+
+   .balign 8
+   .globl elected_master
+elected_master:
+   .long -1
+   .globl cpus_expected
+cpus_expected:
+   .long 8
+   .globl cpus_found
+cpus_found:
+   .long 0
Index: work.git/arch/powerpc/boot/sample.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ work.git/arch/powerpc/boot/sample.c 2007-07-10 16:48:45.0 -0500
@@ -0,0 +1,62 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+ *
+ * Copyright IBM Corporation 2007
+ *
+ * Authors: Milton Miller <[EMAIL PROTECTED]>
+ */
+
+#include "ops.h"
+#include "reg.h"
+#include "flatdevtree.h"
+
+extern struct boot_param_header _dtb_start[], _dtb_end[];
+struct boot_param_header *sample_dt_blob;
+
+extern unsigned int get_cpu_id(void);
+extern unsigned int cpus_found, cpus_expected;
+
+void platform_init(unsigned long boot_cpu_id)
+{
+   if (boot_cpu_id > 1024) {
+   sample_dt_blob = (void *)boot_cpu_id;
+   boot_cpu_id = get_cpu_id();
+   }
+
+   if (!sample_dt_blob)
+   if (_dtb_start != _dtb_end)
+   sample_dt_blob = _dtb_start;
+
+   if (!sample_dt_blob)
+   sample_dt_blob = 31 * 1024 * 1024 + (void *)0;
+
+   if (sample_dt_blob->magic != OF_DT_HEADER)
+   fatal("No device tree at %p\n", sample_dt_blob);
+
+   if (sample_dt_blob->version < 2)
+   conv_flattree_inplace(sample_dt_blob);
+
+   sample_dt_blob->boot_cpuid_phys = boot_cpu_id;
+
+   if (cpus_found && cpus_found < cpus_expected) {
+   HMT_LOW;
+   while (cpus_found < cpus_expected) {
+   barrier();
+   }
+   HMT_MEDIUM;
+   }
+
+   kexec_platform_init(sample_dt_blob);
+}
Index: work.git/arch/powerpc/boot/Makefile
===
--- work.git.orig/arch/powerpc/boot/Makefile2007-07-10 16:41:01.0 
-0500
+++ work.git/arch/powerpc/boot/Makefile 2007-07-10 16:47:45.0 -0500
@@ -48,7 +48,7 @@ src-wlib := string.S crt0.S stdio.c main
44x.c 

Re: [PATCH 6/15] bootwrapper: switch 64 bit cpus to 32 bit mode

2007-07-10 Thread Segher Boessenkool
> + /* Check if the processor is running in 32 bit mode, using
> +  * only 32 bit instructions which should be safe on 32 and
> +  * 64 bit processors.
> +  *
> +  * Subtract the bottom 32 bits of MSR from the full value
> +  * recording the result.  Since MSR[SF] is in the high word,
> +  * the result will be not-equal iff in 32 bit mode (either
> +  * the processor is a 32 bit processor or MSR[SF] = 0).
> +  */

The other way around -- the processor is 64-bit and MSR[SF]=1.

Great trick btw! :-)

> + mfmsr   r0  /* grab whole msr   */
> + rlwinm  r8,r0,0,0,31/* extract bottom word  */
> + subf.   r8,r8,r0/* subtract, same?  */
> + beq 0f  /* yes: we are 32 bit mode  */

The code is fine though.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 11/15] bootwrapper: allow vmlinuz to be an external payload

2007-07-10 Thread Segher Boessenkool
> Allow the boot wrapper to obtain the vmlinux elf from an external
> platform supplied location instead of embedding it at link time.
>
> When used with the cpio library, the kernel can be stored as a file
> an file in the initramfs, allowing the same (compressed) copy of
> the vmlinux elf to be used for both the kernel to execute and any
> user space tools such as kexec (for reboot), crash dump, or oprofile.

Awesome!


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix

2007-07-10 Thread Mikael Pettersson
On Tue, 10 Jul 2007 11:52:59 +0800, Albert Lee wrote:
> >>Recently the PLL input clock of pata_pdc2027x is sometimes detected
> >>higer than expected (e.g. 20.027 MHz compared to 16.714 MHz).
> >>It seems sometimes the mdelay() function is not as precise as it
> >>used to be. Per Alan's advice, HT or power management might affect
> >>the precision of mdelay().
> >>
> >>This patch calls gettimeofday() to mesure the time elapsed and
> >>calculate the PLL input clock accordingly.
> > 
> > 
> > Unfortunately this breaks pata_pdc2027x on my PowerMac G3:
> > 
> 
> > 
> > In fairness, this is a slightly non-standard PowerMac G3, in that it
> > has a G4 upgrade processor. The firmware doesn't recognise the CPU
> > and gives some CPU core frequency-related properties too low values.
> > However, the bus frequency property _is_ correct, which is what
> > most or all timing stuff should be based on.
> > 
> > Looks like a platform bug.
> > 
> 
> According to the document, do_gettimeofday() has microsecond
> resolution. Since the driver calls mdelay(100) (10 microseconds), 
> it won't affect the PLL input clock calculation much if somehow
> do_gettimeofday() drifts several (say 100) microseconds.
> 
> Could you please apply the attached debug patch and collect more info
> on the PowerMac G3. Hopefully we can have more clue. Thanks.
> --
> albert
> 
> (BTW, maybe opening a bug in bugzilla.kernel.org would help the
> debugging.)
> 
> --- 00_libata-dev/drivers/ata/pata_pdc2027x.c 2007-07-07 09:58:55.0 
> +0800
> +++ 01_debug/drivers/ata/pata_pdc2027x.c  2007-07-10 11:18:38.0 
> +0800
> @@ -722,6 +722,15 @@ static long pdc_detect_pll_input_clock(s
>   pll_clock = (start_count - end_count) / 100 *
>   (1 / usec_elapsed);
>  
> + do_gettimeofday(&start_time);
> + mdelay(37);
> + do_gettimeofday(&end_time);
> + usec_elapsed = (end_time.tv_sec - start_time.tv_sec) * 100 +
> + (end_time.tv_usec - start_time.tv_usec);
> + printk(KERN_ERR "usec_elapsed for mdelay(37) [%ld]\n", usec_elapsed);
> + printk(KERN_ERR "start time: [%ld]s [%ld]us \n", start_time.tv_sec, 
> start_time.tv_usec);
> + printk(KERN_ERR "end   time: [%ld]s [%ld]us \n", end_time.tv_sec, 
> end_time.tv_usec);
> +
>   PDPRINTK("start[%ld] end[%ld] \n", start_count, end_count);
>   PDPRINTK("PLL input clock[%ld]Hz\n", pll_clock);

2.6.22 + this prints the following on my G3:

pata_pdc2027x :00:0e.0: version 0.9
usec_elapsed for mdelay(37) [35431]
start time: [1184112028]s [775333]us 
end   time: [1184112028]s [810764]us 
pata_pdc2027x :00:0e.0: PLL input clock 1691741 kHz
pata_pdc2027x: Invalid PLL input clock 1691741kHz, give up!

/Mikael
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 7/15] bootwrapper: Add kexec callable zImage wrapper

2007-07-10 Thread Segher Boessenkool
> The memory node off the root with a name starting with "memory" must
> contain enough free memory (not in the reserved ranges) in the first
> reg range to uncompress the the kernel with padding.

There can be many nodes called "/memory".  You probably
want to use the node pointed to by /chosen/memory instead?


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Infinite loop/always true check possible with unsigned counter.

2007-07-10 Thread Paul Mackerras
Manish Ahuja writes:

> I presume the patch is good then. Do I need to change anything ?

I guess not.  It will cause a warning on the first for loop if anyone
tries to compile with -Wextra or -Wsign-compare, but it would be only
one of lots of warnings in that case (and in fact comparing signed
with unsigned is a perfectly legitimate, well-defined thing to do; you
just have to be aware that the comparison is done as unsigned).

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v2] Consolidate mm_context_t definition in mmu.h

2007-07-10 Thread Paul Mackerras
Josh Boyer writes:

> All of the platforms except PPC64 share a common mm_context_t definition.
> Defining it in mmu.h avoids duplicating it in the platform specific mmu
> header files.  We further consolidate it by having the PPC32 definition
> share the mm_context_id_t type for the id member.

Unfortunately the string of ifdefs in your consolidated version makes
my eyes water.  I'm not sure it isn't better the way it is.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver

2007-07-10 Thread Paul Mackerras
Segher Boessenkool writes:

> > This scales with the number of processors since there is one
> > decrementer per core (is it per thread on SMT chips?
> > I don't know).
> 
> One per core.

No, each thread has its own decrementer, but the timebase is shared.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Allow exec on 32-bit from readable, non-exec pages, with a warning.

2007-07-10 Thread Paul Mackerras
Segher Boessenkool writes:

> Yeah.  Giving the warning is a good thing though.

No, it isn't; it's just noise, if we're not ever going to do anything
to prevent the behaviour - and we can't.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Allow exec on 32-bit from readable, non-exec pages, with a warning.

2007-07-10 Thread Segher Boessenkool
>> Yeah.  Giving the warning is a good thing though.
>
> No, it isn't; it's just noise, if we're not ever going to do anything
> to prevent the behaviour - and we can't.

The same userland code will not run correctly on PPC64 or BookE
systems.  Is that not a reason to warn?


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver

2007-07-10 Thread Segher Boessenkool
>>> This scales with the number of processors since there is one
>>> decrementer per core (is it per thread on SMT chips?
>>> I don't know).
>>
>> One per core.
>
> No, each thread has its own decrementer, but the timebase is shared.

Argh, of course you're right, I'm reading the wrong ISA
version again.  Sorry.


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.

2007-07-10 Thread Segher Boessenkool
>> In older versions of glibc (through 2.3), the dynamic linker  
>> executes a
>> small amount of code from the data segment, which is not marked as
>> executable.  A recent change (commit  
>> 9ba4ace39fdfe22268daca9f28c5df384ae462cf)
>> stops this from working; there should be a deprecation period before
>> older glibc versions stop working.
>
> Actually I see no good reason to enforce no-exec at all if we can't do
> it consistently.  And if we're not going to enforce it then there is
> no point whinging about it.

I have a new patch with just this behaviour, Scott is
testing it on old glibc (I think it succeeded, need
confirmation though), I'll have it tested on new glibc
tomorrow.  So patch tomorrow, and let's try to forget
about all this after that, eh?  :-)

> When I applied Segher's original patch I thought that we had the
> read-implies-exec stuff enabled for the affected CPUs, but it turns
> out we don't.  (We only have that stuff turned on for 32-bit processes
> on 64-bit cpus - see elf_read_implies_exec in include/asm-powerpc/ 
> elf.h.)

I never thought "real code" would rely on executing stuff
it didn't map as executable before.  Silly me.  In my
defense, no one else noticed in time either ;-)


Segher

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Allow exec on 32-bit from readable, non-exec pages, with a warning.

2007-07-10 Thread Paul Mackerras
Segher Boessenkool writes:

> >> Yeah.  Giving the warning is a good thing though.
> >
> > No, it isn't; it's just noise, if we're not ever going to do anything
> > to prevent the behaviour - and we can't.
> 
> The same userland code will not run correctly on PPC64 or BookE
> systems.  Is that not a reason to warn?

It *will* run on ppc64 systems, because there we get the
READ_IMPLIES_EXEC personality flag set via the elf_read_implies_exec
thing in include/asm-powerpc/elf.h.  The READ_IMPLIES_EXEC flag is
only set if we don't have the non-executable stack note in the ELF
header, i.e. only for old binaries or libraries.

As for Book E, that could be fixed using elf_read_implies_exec too, if
anyone cared.  In fact maybe the correct solution is to have

#define elf_read_implies_exec(ex, exec_stk) \
(exec_stk != EXSTACK_DISABLE_X) : 0)

for all 32-bit powerpc.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


  1   2   >