Re: [PATCH] powerpc/iseries: viodasd needs to depend on CONFIG_BLOCK
On Wed, Dec 17 2008, Stephen Rothwell wrote: > Otherwise you get lot of errors like these: > > drivers/block/viodasd.c:72: error: dereferencing pointer to incomplete type > drivers/block/viodasd.c: In function 'viodasd_open': > drivers/block/viodasd.c:135: error: dereferencing pointer to incomplete type > drivers/block/viodasd.c: In function 'viodasd_release': > drivers/block/viodasd.c:184: error: dereferencing pointer to incomplete type > drivers/block/viodasd.c: In function 'viodasd_getgeo': > drivers/block/viodasd.c:209: error: dereferencing pointer to incomplete type > drivers/block/viodasd.c:214: error: implicit declaration of function > 'get_capacity' > drivers/block/viodasd.c: At top level: > drivers/block/viodasd.c:222: error: variable 'viodasd_fops' has initializer > but incomplete type > drivers/block/viodasd.c:223: error: unknown field 'owner' specified in > initializer > > Discovered by a randconfig build. > > Signed-off-by: Stephen Rothwell > --- > arch/powerpc/platforms/iseries/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/powerpc/platforms/iseries/Kconfig > b/arch/powerpc/platforms/iseries/Kconfig > index 45ffd8e..ed3753d 100644 > --- a/arch/powerpc/platforms/iseries/Kconfig > +++ b/arch/powerpc/platforms/iseries/Kconfig > @@ -9,6 +9,7 @@ menu "iSeries device drivers" > > config VIODASD > tristate "iSeries Virtual I/O disk support" > + depends on BLOCK > help > If you are running on an iSeries system and you want to use > virtual disks created and managed by OS/400, say Y. > -- > 1.6.0.5 Indeed, looks good. I trust the ppc folks will carry this one? If so, feel free to add my acked-by to this. -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/iseries: viodasd needs to depend on CONFIG_BLOCK
Hi Jens, On Wed, 17 Dec 2008 09:02:11 +0100 Jens Axboe wrote: > > Indeed, looks good. I trust the ppc folks will carry this one? If so, > feel free to add my acked-by to this. Thanks, I would expect Paul (or Ben) to pick this up. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpAweLtIZ52R.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix corruption error in rh_alloc_fixed()
On Dec 16, 2008, at 7:13 PM, Paul Mackerras wrote: Kumar Gala writes: Paul are you planning on picking this up for .28 if not I'll pick it up for .29 I was waiting for you to say if it needed to go in .28. Sounds like you don't think it's that urgent then? Since I have another patch for .28 I'll include in my merge tree. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'merge' for 2.6.28
The following changes since commit 23e0e8afafd9ac065d81506524adf3339584044b: Arnd Bergmann (1): powerpc/cell/axon-msi: Fix MSI after kexec are available in the git repository at: master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge Dave Liu (1): powerpc/fsl-booke: Fix the miss interrupt restore Guillaume Knispel (1): powerpc: Fix corruption error in rh_alloc_fixed() arch/powerpc/kernel/misc_32.S |4 ++-- arch/powerpc/lib/rheap.c |1 + 2 files changed, 3 insertions(+), 2 deletions(-) -- Dave's patch fixes a stupid issue I introduced with my previous commit and Guillaume is a simple fix for some oops's he was seeing. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix corruption error in rh_alloc_fixed()
On Dec 9, 2008, at 8:28 AM, Guillaume Knispel wrote: There is an error in rh_alloc_fixed() of the Remote Heap code: If there is at least one free block blk won't be NULL at the end of the search loop, so -ENOMEM won't be returned and the else branch of "if (bs == s || be == e)" will be taken, corrupting the management structures. Signed-off-by: Guillaume Knispel --- Fix an error in rh_alloc_fixed() that made allocations succeed when they should fail, and corrupted management structures. diff --git a/arch/powerpc/lib/rheap.c b/arch/powerpc/lib/rheap.c index 29b2941..45907c1 100644 --- a/arch/powerpc/lib/rheap.c +++ b/arch/powerpc/lib/rheap.c @@ -556,6 +556,7 @@ unsigned long rh_alloc_fixed(rh_info_t * info, unsigned long start, int size, co be = blk->start + blk->size; if (s >= bs && e <= be) break; + blk = NULL; } if (blk == NULL) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl-booke: Fix the miss interrupt restore
On Dec 17, 2008, at 4:24 AM, Dave Liu wrote: The commit e5e774d8833de1a0037be2384efccadf16935675 powerpc/fsl-booke: Fix problem with _tlbil_va being interrupted introduce one issue. that casue the problem like this: Kernel BUG at c00b19fc [verbose debug info unavailable] Oops: Exception in kernel mode, sig: 5 [#1] MPC8572 DS Modules linked in: NIP: c00b19fc LR: c00b1c34 CTR: c0064e88 REGS: ef02b7b0 TRAP: 0700 Not tainted (2.6.28-rc8-00057-g1bda712) MSR: 00021000 CR: 44048028 XER: 2000 TASK = ef02c000[1] 'init' THREAD: ef02a000 GPR00: 0001 ef02b860 ef02c000 eec201a0 c0dec2c0 78a1 0400 GPR08: c00b4e40 78a1 c048ec00 a178 44048028 ecd26917 0001 ef02b948 GPR16: ffea 020c 0003 000a 78a1 GPR24: eec201a0 ed849000 0400 ef02b95c 0001 ef02b978 ef02b984 NIP [c00b19fc] __find_get_block+0x24/0x238 LR [c00b1c34] __getblk+0x24/0x2a0 Call Trace: [ef02b860] [c017b768] generic_make_request+0x290/0x328 (unreliable) [ef02b8b0] [c00b1c34] __getblk+0x24/0x2a0 [ef02b910] [c00b4ae4] __bread+0x14/0xf8 [ef02b920] [c00fc228] ext2_get_branch+0xf0/0x138 [ef02b940] [c00fcc88] ext2_get_block+0xb8/0x828 [ef02ba00] [c00bbdc8] do_mpage_readpage+0x188/0x808 [ef02bac0] [c00bc5b4] mpage_readpages+0xec/0x144 [ef02bb50] [c00fba38] ext2_readpages+0x24/0x34 [ef02bb60] [c006ade0] __do_page_cache_readahead+0x150/0x230 [ef02bbb0] [c0064bdc] filemap_fault+0x31c/0x3e0 [ef02bbf0] [c00728b8] __do_fault+0x60/0x5b0 [ef02bc50] [c0011e0c] do_page_fault+0x2d8/0x4c4 [ef02bd10] [c000ed90] handle_page_fault+0xc/0x80 [ef02bdd0] [c00c7adc] set_brk+0x74/0x9c [ef02bdf0] [c00c9274] load_elf_binary+0x70c/0x1180 [ef02be70] [c00945f0] search_binary_handler+0xa8/0x274 [ef02bea0] [c0095818] do_execve+0x19c/0x1d4 [ef02bed0] [c000766c] sys_execve+0x58/0x84 [ef02bef0] [c000e950] ret_from_syscall+0x0/0x3c [ef02bfb0] [c009c6fc] sys_dup+0x24/0x6c [ef02bfc0] [c0001e04] init_post+0xb0/0xf0 [ef02bfd0] [c046c1ac] kernel_init+0xcc/0xf4 [ef02bff0] [c000e6d0] kernel_thread+0x4c/0x68 Instruction dump: 4ba4 813f000c 4bac 9421ffb0 7c0802a6 7d800026 90010054 bf210034 91810030 7ca6 68008000 54008ffe <0f00> 3d20c04e 3b29ffb8 3808 Signed-off-by: Dave Liu --- arch/powerpc/kernel/misc_32.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Good catch. applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] powerpc/qe: Implement QE Pin Multiplexing API
On Dec 17, 2008, at 9:41 AM, Anton Vorontsov wrote: On Wed, Dec 03, 2008 at 10:27:38PM +0300, Anton Vorontsov wrote: With this API we're able to set a QE pin to the GPIO mode or a dedicated peripheral function. The API relies on the fact that QE gpio controllers are registered. If they aren't, the API won't work (gracefully though). There is one caveat though: if anybody occupied the node->data before us, or overwrote it, then bad things will happen. Luckily this is all in the platform code that we fully control, so this should never happen. I could implement more checks (for example we could create a list of successfully registered QE controllers, and compare the node->data in the qe_pin_request()), but this is unneeded if nobody is going to do silly things behind our back. Signed-off-by: Anton Vorontsov --- Kumar, can you please merge this patch? It is the last patch that holds the FHCI USB driver. Thanks, Will do. Can I get you to add kdoc comments for the API functions: +extern struct qe_pin *qe_pin_request(struct device_node *np, int index); +extern void qe_pin_free(struct qe_pin *qe_pin); +extern void qe_pin_set_gpio(struct qe_pin *qe_pin); +extern void qe_pin_set_dedicated(struct qe_pin *pin); - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] powerpc/qe: Implement QE Pin Multiplexing API
On Wed, Dec 17, 2008 at 10:46:17AM -0600, Kumar Gala wrote: > > On Dec 17, 2008, at 9:41 AM, Anton Vorontsov wrote: > >> On Wed, Dec 03, 2008 at 10:27:38PM +0300, Anton Vorontsov wrote: >>> With this API we're able to set a QE pin to the GPIO mode or a >>> dedicated >>> peripheral function. >>> >>> The API relies on the fact that QE gpio controllers are registered. >>> If >>> they aren't, the API won't work (gracefully though). >>> >>> There is one caveat though: if anybody occupied the node->data >>> before us, >>> or overwrote it, then bad things will happen. Luckily this is all in >>> the >>> platform code that we fully control, so this should never happen. >>> >>> I could implement more checks (for example we could create a list of >>> successfully registered QE controllers, and compare the node->data >>> in the >>> qe_pin_request()), but this is unneeded if nobody is going to do >>> silly >>> things behind our back. >>> >>> Signed-off-by: Anton Vorontsov >>> --- >> >> Kumar, can you please merge this patch? It is the last patch that >> holds the FHCI USB driver. >> >> Thanks, > > Will do. Can I get you to add kdoc comments for the API functions: The functions already have kdoc comments (see qe_lib/gpio.c changes). > +extern struct qe_pin *qe_pin_request(struct device_node *np, int > index); > +extern void qe_pin_free(struct qe_pin *qe_pin); > +extern void qe_pin_set_gpio(struct qe_pin *qe_pin); > +extern void qe_pin_set_dedicated(struct qe_pin *pin); -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc: Implement GPIO driver for simple memory-mapped banks
On Dec 3, 2008, at 1:27 PM, Anton Vorontsov wrote:
The driver supports very simple GPIO controllers, that is, when a
controller provides just a 'data' register. Such controllers may be
found in various BCSRs (Board's FPGAs used to control board's
switches, LEDs, chip-selects, Ethernet/USB PHY power, etc).
So far we support only 1-byte GPIO banks. Support for other widths may
be implemented when/if needed.
p.s.
To avoid "made up" compatible entries (like compatible = "simple-
gpio"),
boards must call the simple_gpiochip_init() to pass the compatible
string.
Signed-off-by: Anton Vorontsov
---
Documentation/powerpc/dts-bindings/fsl/board.txt | 30
can we pull this out of this patch. Since the fsl board specific
binding its 100% relevant to the generic support for simple_gpio. We
can also update the .dts for just gpio and Kconfig in that patch.
arch/powerpc/platforms/Kconfig | 10 ++
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/simple_gpio.c| 156 +
+
arch/powerpc/sysdev/simple_gpio.h| 15 ++
5 files changed, 212 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/simple_gpio.c
create mode 100644 arch/powerpc/sysdev/simple_gpio.h
diff --git a/Documentation/powerpc/dts-bindings/fsl/board.txt b/
Documentation/powerpc/dts-bindings/fsl/board.txt
index 81a917e..2bd9888 100644
--- a/Documentation/powerpc/dts-bindings/fsl/board.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/board.txt
@@ -27,3 +27,33 @@ Example (MPC8610HPCD):
compatible = "fsl,fpga-pixis";
reg = <0xe800 32>;
};
+
+* Freescale BCSR GPIO banks
+
+Some BCSR registers act as simple GPIO controllers, each such
+register can be represented by the gpio-controller node.
+
+Required properities:
+- compatible : Should be "fsl,-bcsr-gpio";
+- reg : Should contain the address and the lenght of the GPIO bank
+ register;
spelling - length
semicolon at add of register can be dropped.
+- #gpio-cells : Should be two. The first cell is the pin number and
the
+ second cell is used to specify optional paramters (currently
unused);
+- gpio-controller : Marks the port as GPIO controller.
+
+Example:
+
+ b...@1,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8360mds-bcsr";
+ reg = <1 0 0x8000>;
+ ranges = <0 1 0 0x8000>;
+
+ bcsr13: gpio-control...@d {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360mds-bcsr-gpio";
+ reg = <0xd 1>;
+ gpio-controller;
+ };
+ };
diff --git a/arch/powerpc/sysdev/simple_gpio.c b/arch/powerpc/sysdev/
simple_gpio.c
new file mode 100644
index 000..d62c85a
--- /dev/null
+++ b/arch/powerpc/sysdev/simple_gpio.c
@@ -0,0 +1,156 @@
+/*
+ * Simple Memory-Mapped GPIOs
+ *
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Anton Vorontsov
+ *
+ * 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 "simple_gpio.h"
+
+struct u8_gpio_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u8 data;
+};
+
+static struct u8_gpio_chip *to_u8_gpio_chip(struct of_mm_gpio_chip
*mm_gc)
+{
+ return container_of(mm_gc, struct u8_gpio_chip, mm_gc);
+}
+
+static u8 u8_pin2mask(unsigned int pin)
+{
+ return 1 << (8 - 1 - pin);
+}
+
+static int u8_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+
+ return in_8(mm_gc->regs) & u8_pin2mask(gpio);
+}
+
+static void u8_gpio_set(struct gpio_chip *gc, unsigned int gpio,
int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct u8_gpio_chip *u8_gc = to_u8_gpio_chip(mm_gc);
+ unsigned long flags;
+
+ spin_lock_irqsave(&u8_gc->lock, flags);
+
+ if (val)
+ u8_gc->data |= u8_pin2mask(gpio);
+ else
+ u8_gc->data &= ~u8_pin2mask(gpio);
+
+ out_8(mm_gc->regs, u8_gc->data);
+
+ spin_unlock_irqrestore(&u8_gc->lock, flags);
+}
+
+static int u8_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ return 0;
+}
+
+static int u8_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio,
int val)
+{
+ u8_gpio_set(gc, gpio, val);
+ return 0;
+}
+
+static void u8_gpio_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+ struct u8_gpio_chip *u8_gc = to_u8_gpio_ch
Re: [PATCH 3/5] powerpc/83xx: Add USB Host/Gadget support for MPC8360E-MDS boards
Kumar Gala wrote: > Of these are they all in the kernel tree already? What I mean is QE > usb bindings in linus's tree? I know GTM timers is and this patch > series had the bcsr gpio. Similar question for qe par io. I think we > are good but clearly I leave much of QE to you & timur. These QE GPIO and USB patches have been floating around so long, that I think it's important to get them in so that the functionality is available. I reviewed them a while go and gave them my thumbs up, and I trust Anton, so I'm sure these latest patches are OK. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/16] powerpc/4xx: Extended DCR support v2
On Mon, Dec 15, 2008 at 04:44:17PM +1100, Benjamin Herrenschmidt wrote: >This adds supports to the "extended" DCR addressing via >the indirect mfdcrx/mtdcrx instructions supported by some >4xx cores (440H6 and later) > >I enabled the feature for now only on AMCC 460 chips > >Signed-off-by: Benjamin Herrenschmidt Acked-by: Josh Boyer I actually ran some tests on this patch on a Bamboo board that lacks the new instructions. While tbench might not be great here, it's the thing I had handy and it does drive some DCR access given that every interrupt uses DCR instructions to handle the UIC bits (and some of the MAL stuff I'm assuming). The results with and without the patch were pretty close. Differences were in the noise range. I wanted to test on Canyonlands, which does have the new instructions, but mine appears to be DOA. So in summary, it doesn't make things worse :). josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/11][v2] async_tx: add support for asynchronous GF multiplication
Hi Yuri,
On Mon, Dec 8, 2008 at 2:55 PM, Yuri Tikhonov wrote:
> This adds support for doing asynchronous GF multiplication by adding
> four additional functions to async_tx API:
>
> async_pq() does simultaneous XOR of sources and XOR of sources
> GF-multiplied by given coefficients.
>
> async_pq_zero_sum() checks if results of calculations match given
> ones.
>
> async_gen_syndrome() does sumultaneous XOR and R/S syndrome of sources.
>
> async_syndrome_zerosum() checks if results of XOR/syndrome calculation
> matches given ones.
>
> Latter two functions just use async_pq() with the approprite coefficients
> in asynchronous case but have significant optimizations if synchronous
> case.
>
I like this separation of gen_syndrome and generic pq.
[..]
> + /* DMAs use destinations as sources, so use BIDIRECTIONAL mapping */
> + dma_dest[0] = !blocks[src_cnt] ? 0 :
> + dma_map_page(dma->dev, blocks[src_cnt],
> +offset, len, DMA_BIDIRECTIONAL);
"0" could be a valid dma address on some architectures.
DMA_ERROR_CODE looks like the closest fit for what we are trying to do
here, but that only exists on sparc and powerpc. We could add a
"dest_mask" parameter to device_prep_dma_pq where the mask is 1 =
p-only, 2 = q-only, and 3 = p and q.
> + dma_dest[1] = !blocks[src_cnt+1] ? 0 :
> + dma_map_page(dma->dev, blocks[src_cnt+1],
> +offset, len, DMA_BIDIRECTIONAL);
> +
> + for (i = 0; i < src_cnt; i++)
> + dma_src[i] = dma_map_page(dma->dev, blocks[i],
> + offset, len, DMA_TO_DEVICE);
> +
> + while (src_cnt) {
> + async_flags = flags;
> + pq_src_cnt = min(src_cnt, dma->max_pq);
> + /* if we are submitting additional pqs, leave the chain open,
> +* clear the callback parameters, and leave the destination
> +* buffers mapped
> +*/
> + if (src_cnt > pq_src_cnt) {
> + async_flags &= ~ASYNC_TX_ACK;
> + dma_flags |= DMA_COMPL_SKIP_DEST_UNMAP;
> + _cb_fn = NULL;
> + _cb_param = NULL;
> + } else {
> + _cb_fn = cb_fn;
> + _cb_param = cb_param;
> + }
> + if (_cb_fn)
> + dma_flags |= DMA_PREP_INTERRUPT;
> +
> + /* Since we have clobbered the src_list we are committed
> +* to doing this asynchronously. Drivers force forward
> +* progress in case they can not provide a descriptor
> +*/
> + tx = dma->device_prep_dma_pq(chan, dma_dest,
> +&dma_src[src_off], pq_src_cnt,
> +scf_list ? &scf_list[src_off] :
> + NULL,
> +len, dma_flags);
...one nit for readability can we replace these ternary conditionals
with proper if-else statements? i.e.
if (scf_list)
scf = &scf_list[src_off];
else
scf = NULL;
tx = dma->device_prep_dma_pq(chan, dma_dest,
&dma_src[src_off], pq_src_cnt,
scf, len, dma_flags);
> + if (unlikely(!tx))
> + async_tx_quiesce(&depend_tx);
> +
> + /* spin wait for the preceeding transactions to complete */
> + while (unlikely(!tx)) {
> + dma_async_issue_pending(chan);
> + tx = dma->device_prep_dma_pq(chan, dma_dest,
> + &dma_src[src_off], pq_src_cnt,
> + scf_list ? &scf_list[src_off] : NULL,
> + len, dma_flags);
> + }
> +
> + async_tx_submit(chan, tx, async_flags, depend_tx,
> + _cb_fn, _cb_param);
> +
> + depend_tx = tx;
> + flags |= ASYNC_TX_DEP_ACK;
> +
> + if (src_cnt > pq_src_cnt) {
> + /* drop completed sources */
> + src_cnt -= pq_src_cnt;
> + src_off += pq_src_cnt;
> +
> + /* use the intermediate result as a source; we
> +* clear DMA_PREP_ZERO, so prep_dma_pq will
> +* include destination(s) into calculations
> +*/
> + dma_flags = 0;
> + } else
> + break;
> + }
> +
> + return tx;
> +}
> +
> +/**
> + * do_
Re: MPC8572 - IPR Register
On Dec 16, 2008, at 4:08 PM, bterrell wrote: > > > Kumar Gala-3 wrote: >> >> >> <1. Which PCIe port is the device on? >> 2. is this a INT-X style or MSI interrupt? >> 3. if INT-X is INT-A, B, C, D? 1. Non-transparent bridge device is on port 1 of the PLX8616 switch, which is connected to first PCIE controller. 2. Using INTx style interrupts. 3. NT device asserts INTA, but this is swizzled by the upstream port of the switch to be INTB before sending to 8572. The problem also occurs when a hot-reset is sent inband from the PCIE controller on 8572. I see the following differences in 8572 PCIE registers in configuration space before/after the "hot reset" is sent: PEX Config Space Register 0x414: before 0x after 0x1 <== undocumented reg?? PEX Config Space Register 0x43C: before 0x00C2DC76 after 0x00013014 <== undocumented reg?? PEX Config Space Register 0x4E8: before 0x4D4D after 0x0101 <== undocumented reg?? Any idea what these registers are? thanks, Bill Terrell Empirix, Inc. -- View this message in context: http://www.nabble.com/MPC8572---IPR-Register-tp21040440p21058850.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/fsl-booke: Fix the miss interrupt restore
The commit e5e774d8833de1a0037be2384efccadf16935675 powerpc/fsl-booke: Fix problem with _tlbil_va being interrupted introduce one issue. that casue the problem like this: Kernel BUG at c00b19fc [verbose debug info unavailable] Oops: Exception in kernel mode, sig: 5 [#1] MPC8572 DS Modules linked in: NIP: c00b19fc LR: c00b1c34 CTR: c0064e88 REGS: ef02b7b0 TRAP: 0700 Not tainted (2.6.28-rc8-00057-g1bda712) MSR: 00021000 CR: 44048028 XER: 2000 TASK = ef02c000[1] 'init' THREAD: ef02a000 GPR00: 0001 ef02b860 ef02c000 eec201a0 c0dec2c0 78a1 0400 GPR08: c00b4e40 78a1 c048ec00 a178 44048028 ecd26917 0001 ef02b948 GPR16: ffea 020c 0003 000a 78a1 GPR24: eec201a0 ed849000 0400 ef02b95c 0001 ef02b978 ef02b984 NIP [c00b19fc] __find_get_block+0x24/0x238 LR [c00b1c34] __getblk+0x24/0x2a0 Call Trace: [ef02b860] [c017b768] generic_make_request+0x290/0x328 (unreliable) [ef02b8b0] [c00b1c34] __getblk+0x24/0x2a0 [ef02b910] [c00b4ae4] __bread+0x14/0xf8 [ef02b920] [c00fc228] ext2_get_branch+0xf0/0x138 [ef02b940] [c00fcc88] ext2_get_block+0xb8/0x828 [ef02ba00] [c00bbdc8] do_mpage_readpage+0x188/0x808 [ef02bac0] [c00bc5b4] mpage_readpages+0xec/0x144 [ef02bb50] [c00fba38] ext2_readpages+0x24/0x34 [ef02bb60] [c006ade0] __do_page_cache_readahead+0x150/0x230 [ef02bbb0] [c0064bdc] filemap_fault+0x31c/0x3e0 [ef02bbf0] [c00728b8] __do_fault+0x60/0x5b0 [ef02bc50] [c0011e0c] do_page_fault+0x2d8/0x4c4 [ef02bd10] [c000ed90] handle_page_fault+0xc/0x80 [ef02bdd0] [c00c7adc] set_brk+0x74/0x9c [ef02bdf0] [c00c9274] load_elf_binary+0x70c/0x1180 [ef02be70] [c00945f0] search_binary_handler+0xa8/0x274 [ef02bea0] [c0095818] do_execve+0x19c/0x1d4 [ef02bed0] [c000766c] sys_execve+0x58/0x84 [ef02bef0] [c000e950] ret_from_syscall+0x0/0x3c [ef02bfb0] [c009c6fc] sys_dup+0x24/0x6c [ef02bfc0] [c0001e04] init_post+0xb0/0xf0 [ef02bfd0] [c046c1ac] kernel_init+0xcc/0xf4 [ef02bff0] [c000e6d0] kernel_thread+0x4c/0x68 Instruction dump: 4ba4 813f000c 4bac 9421ffb0 7c0802a6 7d800026 90010054 bf210034 91810030 7ca6 68008000 54008ffe <0f00> 3d20c04e 3b29ffb8 3808 Signed-off-by: Dave Liu --- arch/powerpc/kernel/misc_32.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S index d108715..5c33bc1 100644 --- a/arch/powerpc/kernel/misc_32.S +++ b/arch/powerpc/kernel/misc_32.S @@ -486,13 +486,13 @@ _GLOBAL(_tlbil_va) tlbsx 0,r3 mfspr r4,SPRN_MAS1/* check valid */ andis. r3,r4,mas1_va...@h - beqlr + beq 1f rlwinm r4,r4,0,1,31 mtspr SPRN_MAS1,r4 tlbwe msync isync - wrtee r10 +1: wrtee r10 blr #endif /* CONFIG_FSL_BOOKE */ -- 1.5.4 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ndfc driver
On Tue, Dec 16, 2008 at 11:14:00PM -0500, Sean MacLennan wrote: >On Wed, 10 Dec 2008 18:16:34 -0500 >"Sean MacLennan" wrote: > >> Here is an updated patch. Doc has been moved to 4xx and amcc changed >> to ibm. > >Anybody? Even if it is not perfect, it would be better to have >a driver that at least compiles ;) Reviewing it today. Looked pretty good at first glance. It would be nice to get David or Thomas to Ack it. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] POWERPC/fsl-pci: Better ATMU setup
The code that sets up the outbound ATMU windows, which is used to map CPU
physical addresses into PCI bus addresses where BARs will be mapped, didn't
work so well.
For one, it leaked the ioremap() of the ATMU registers. Another small bug
was the high 20 bits of the PCI bus address were left as zero. It's legal
for prefetchable memory regions to be above 32 bits, so the high 20 bits
might not be zero.
Mainly, it couldn't handle ranges that were not a power of two in size or
were not naturally aligned. The ATMU windows have these requirements (size
& alignment), but the code didn't bother to check if the ranges it was
programming met them. If they didn't, the windows would silently be
programmed incorrectly.
This new code can handle ranges which are not power of two sized nor
naturally aligned. It simply splits the ranges into multiple valid ATMU
windows. As there are only four windows, pooly aligned or sized ranges
(which didn't even work before) may run out of windows. In this case an
error is printed and an effort is made to disable the unmapped resources.
An improvement that could be made would be to make use of the default
outbound window. Iff hose->pci_mem_offset is zero, then it's possible that
some or all of the ranges might not need an outbound window and could just
use the default window.
The default ATMU window can support a pci_mem_offset less than zero too,
but pci_mem_offset is unsigned. One could say the abilities allowed a
powerpc pci_controller is neither subset nor a superset of the abilities of
a Freescale PCIe controller. Thankfully, the most useful bits are in the
intersection of the two abilities.
Signed-off-by: Trent Piepho
---
arch/powerpc/sysdev/fsl_pci.c | 104 -
1 files changed, 71 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 5b264eb..656f914 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -28,62 +28,100 @@
#include
#if defined(CONFIG_PPC_85xx) || defined(CONFIG_PPC_86xx)
+static int __init setup_one_atmu(struct ccsr_pci __iomem *pci,
+ unsigned int index, const struct resource *res,
+ resource_size_t offset)
+{
+ resource_size_t pci_addr = res->start - offset;
+ resource_size_t phys_addr = res->start;
+ resource_size_t size = res->end - res->start + 1;
+ u32 flags = 0x80044000; /* enable & mem R/W */
+ unsigned int i;
+
+ pr_debug("PCI MEM resource start 0x%016llx, size 0x%016llx.\n",
+ (u64)res->start, (u64)size);
+
+ for (i = 0; size > 0; i++) {
+ unsigned int bits = min(__ilog2(size),
+ __ffs(pci_addr | phys_addr));
+
+ if (index + i >= 5)
+ return -1;
+
+ out_be32(&pci->pow[index + i].potar, pci_addr >> 12);
+ out_be32(&pci->pow[index + i].potear, (u64)pci_addr >> 44);
+ out_be32(&pci->pow[index + i].powbar, phys_addr >> 12);
+ out_be32(&pci->pow[index + i].powar, flags | (bits - 1));
+
+ pci_addr += (resource_size_t)1U << bits;
+ phys_addr += (resource_size_t)1U << bits;
+ size -= (resource_size_t)1U << bits;
+ }
+
+ return i;
+}
+
/* atmu setup for fsl pci/pcie controller */
void __init setup_pci_atmu(struct pci_controller *hose, struct resource *rsrc)
{
struct ccsr_pci __iomem *pci;
- int i;
+ int i, j, n;
pr_debug("PCI memory map start 0x%016llx, size 0x%016llx\n",
(u64)rsrc->start, (u64)rsrc->end - (u64)rsrc->start + 1);
pci = ioremap(rsrc->start, rsrc->end - rsrc->start + 1);
+ if (!pci) {
+ dev_err(hose->parent, "Unable to map ATMU registers\n");
+ return;
+ }
- /* Disable all windows (except powar0 since its ignored) */
+ /* Disable all windows (except powar0 since it's ignored) */
for(i = 1; i < 5; i++)
out_be32(&pci->pow[i].powar, 0);
for(i = 0; i < 3; i++)
out_be32(&pci->piw[i].piwar, 0);
/* Setup outbound MEM window */
- for(i = 0; i < 3; i++)
- if (hose->mem_resources[i].flags & IORESOURCE_MEM){
- resource_size_t pci_addr_start =
-hose->mem_resources[i].start -
-hose->pci_mem_offset;
- pr_debug("PCI MEM resource start 0x%016llx, size
0x%016llx.\n",
- (u64)hose->mem_resources[i].start,
- (u64)hose->mem_resources[i].end
- - (u64)hose->mem_resources[i].start + 1);
- out_be32(&pci->pow[i+1].potar, (pci_addr_start >> 12));
- out_be32(&pci->pow[i+1].potear, 0);
- out_be32(&pci->pow[i+1].powbar,
-
[PATCH 2/2] POWERPC/fsl-pci: Set relaxed ordering on prefetchable ranges
Provides a small speedup when accessing pefetchable ranges. To indicate
that a memory range is prefetchable, mark it in the dts file with 4200
instead of 0200.
A powepc pci_controller is allowed three memory ranges, any of which may be
prefetchable. However, the PCI-PCI bridge configuration space only has one
field for "non-prefetchable memory behind bridge", which has a 32 bit
address, and one field for "prefetchable memory behind bridge", which may
have a 64 bit address. These are PCI bus addresses, not CPU physical
addresses.
So really you're only allowed one memory range of each type. And if you
want the range at a PCI address above 32 bits you must make it
prefetchable.
Signed-off-by: Trent Piepho
---
arch/powerpc/sysdev/fsl_pci.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 656f914..af0d7e3 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -41,6 +41,9 @@ static int __init setup_one_atmu(struct ccsr_pci __iomem *pci,
pr_debug("PCI MEM resource start 0x%016llx, size 0x%016llx.\n",
(u64)res->start, (u64)size);
+ if (res->flags & IORESOURCE_PREFETCH)
+ flags |= 0x1000; /* enable relaxed ordering */
+
for (i = 0; size > 0; i++) {
unsigned int bits = min(__ilog2(size),
__ffs(pci_addr | phys_addr));
--
1.5.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
What means "technology has been retired"?
Does anyone know what the statement: "This technology has been retired." on this page: http://www.alphaworks.ibm.com/tech/powerscale4ppc means? Something about 970FX frequency scaling? kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
FHCI driver adaptation for CPM2
Hi, I have a few questions with regard to adapting the FHCI USB host controller driver (for QE) from Anton Vorontsov to CPM2, based on past discussions from linuxppc-dev & linuxppc-embedded. http://ozlabs.org/pipermail/linuxppc-dev/2008-April/054253.html >On Tuesday 08 April 2008 14:16, Anton Vorontsov wrote: >> On Mon, Apr 07, 2008 at 06:11:15PM +0200, Laurent Pinchart wrote: >> > I had a first go at hacking the FHCI driver to make it run on a CPM2 >> > platform. Results so far are quite good. After getting rid of qe-specific >> > APIs as explained above, and adding SOF token generation support, I've >> > been able to access a mass storage device. The driver hasn't been >> > stress-tested yet though. >> >> Wow, awesome! That's great news, really. Looking forward for the patch. :-) > >The current version of the code is CPM2-specific and won't work on QE-based >platforms. Should I still post it ? Has this CPM2 patch adaptation been posted somewhere ? I will have soon to evaluate an USB disk on MPC8270 and it would be great to spend time working on adapting the patch to last gpio changes and trying to merge it with the original QE patch rather than doing this work again. http://ozlabs.org/pipermail/linuxppc-embedded/2008-June/030541.html >Laurent Pinchart-4 wrote: >The bad news is that, from my experience with the CPM2, the controller is >almost unusable. It eats around 40% CPU time on my MPC8248 system, and >requires software help to generate SOF tokens, which results in bad SOF >tokens being sent on the bus. Most USB disks don't seem to care, but all the >USB Bluetooth host controllers I've tested crashed. Does this mean than SOF tokens handling can be ignored when working with USB disks, or only that they don't care of a few errors ? Also 40% seems quite a lot, even at 1000Hz interruptions, an idea how much does the CRC computation contribute in this CPU hogging ? Best regards, Rémi Lefèvre ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
Added additional information for type and compatibility strings and
interrupt information to the SDRAM0 memory-controller device tree
nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver.
Signed-off-by: Grant Erickson
---
As support in the associated EDAC adapter driver is added over time,
similar changes will/should be made to the DTS files for boards
leveraging realizations of this "ibm,sdram-4xx-ddr2" controller,
including the 440SP, 440SPe, 460EX, 460GT and 460SX.
arch/powerpc/boot/dts/haleakala.dts | 11 ++-
arch/powerpc/boot/dts/kilauea.dts | 11 ++-
arch/powerpc/boot/dts/makalu.dts| 11 ++-
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/haleakala.dts
b/arch/powerpc/boot/dts/haleakala.dts
index 513bc43..e45ce7e 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -89,8 +89,17 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405exr";
+ device_type = "memory-controller";
+ compatible = "ibm,sdram-405exr", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&SDRAM0>;
+ interrupts = <0x0 0x1>;
+ interrupt-map = ;
+ interrupt-map-mask = <0x>;
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index dececc4..d492ead 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -90,8 +90,17 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405ex";
+ device_type = "memory-controller";
+ compatible = "ibm,sdram-405ex", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&SDRAM0>;
+ interrupts = <0x0 0x1>;
+ interrupt-map = ;
+ interrupt-map-mask = <0x>;
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index 945508c..52b9f32 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -90,8 +90,17 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405ex";
+ device_type = "memory-controller";
+ compatible = "ibm,sdram-405ex", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&SDRAM0>;
+ interrupts = <0x0 0x1>;
+ interrupt-map = ;
+ interrupt-map-mask = <0x>;
};
MAL0: mcmal {
--
1.6.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.
On Thu, Dec 11, 2008 at 04:55:41AM +0300, Ilya Yanok wrote: >This patch adds support for page sizes bigger than 4K (16K/64K) on >PPC 44x. >PGDIR table is much smaller than page in case of 16K/64K pages (512 >and 32 bytes resp.) so we allocate PGDIR with kzalloc() instead of >__get_free_pages(). >PTE table covers rather big memory area in case of 16K/64K pages >(32MB and 512MB resp.) so we can easily put FIXMAP and PKMAP in >area covered by one PTE table. > >Signed-off-by: Yuri Tikhonov >Signed-off-by: Vladimir Panfilov >Signed-off-by: Ilya Yanok I tested this a bit today on a Bamboo board. Overall, it functioned well enough to not crash :). Note that I also included Hollis' memory size alignment patch which is required. The code looks pretty clean now. I think if we're going to include this patch it should go in now. Acked-by: Josh Boyer >--- > arch/powerpc/Kconfig | 58 > arch/powerpc/include/asm/highmem.h | 19 +- > arch/powerpc/include/asm/mmu-44x.h | 17 + > arch/powerpc/include/asm/page.h| 13 --- > arch/powerpc/include/asm/page_32.h |7 +++- > arch/powerpc/kernel/asm-offsets.c |4 ++ > arch/powerpc/kernel/head_44x.S | 23 - > arch/powerpc/kernel/misc_32.S | 12 +++--- > arch/powerpc/mm/pgtable_32.c | 23 - > arch/powerpc/platforms/Kconfig.cputype |2 +- > 10 files changed, 130 insertions(+), 48 deletions(-) > >diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >index 525c13a..cd8ff7c 100644 >--- a/arch/powerpc/Kconfig >+++ b/arch/powerpc/Kconfig >@@ -401,23 +401,53 @@ config PPC_HAS_HASH_64K > depends on PPC64 > default n > >-config PPC_64K_PAGES >- bool "64k page size" >- depends on PPC64 >- select PPC_HAS_HASH_64K >+choice >+ prompt "Page size" >+ default PPC_4K_PAGES > help >-This option changes the kernel logical page size to 64k. On machines >-without processor support for 64k pages, the kernel will simulate >-them by loading each individual 4k page on demand transparently, >-while on hardware with such support, it will be used to map >-normal application pages. >+Select the kernel logical page size. Increasing the page size >+will reduce software overhead at each page boundary, allow >+hardware prefetch mechanisms to be more effective, and allow >+larger dma transfers increasing IO efficiency and reducing >+overhead. However the utilization of memory will increase. >+For example, each cached file will using a multiple of the >+page size to hold its contents and the difference between the >+end of file and the end of page is wasted. >+ >+Some dedicated systems, such as software raid serving with >+accelerated calculations, have shown significant increases. >+ >+If you configure a 64 bit kernel for 64k pages but the >+processor does not support them, then the kernel will simulate >+them with 4k pages, loading them on demand, but with the >+reduced software overhead and larger internal fragmentation. >+For the 32 bit kernel, a large page option will not be offered >+unless it is supported by the configured processor. >+ >+If unsure, choose 4K_PAGES. >+ >+config PPC_4K_PAGES >+ bool "4k page size" >+ >+config PPC_16K_PAGES >+ bool "16k page size" if 44x >+ >+config PPC_64K_PAGES >+ bool "64k page size" if 44x || PPC_STD_MMU_64 >+ select PPC_HAS_HASH_64K if PPC_STD_MMU_64 >+ >+endchoice > > config FORCE_MAX_ZONEORDER > int "Maximum zone order" >- range 9 64 if PPC_64K_PAGES >- default "9" if PPC_64K_PAGES >- range 13 64 if PPC64 && !PPC_64K_PAGES >- default "13" if PPC64 && !PPC_64K_PAGES >+ range 9 64 if PPC_STD_MMU_64 && PPC_64K_PAGES >+ default "9" if PPC_STD_MMU_64 && PPC_64K_PAGES >+ range 13 64 if PPC_STD_MMU_64 && !PPC_64K_PAGES >+ default "13" if PPC_STD_MMU_64 && !PPC_64K_PAGES >+ range 9 64 if PPC_STD_MMU_32 && PPC_16K_PAGES >+ default "9" if PPC_STD_MMU_32 && PPC_16K_PAGES >+ range 7 64 if PPC_STD_MMU_32 && PPC_64K_PAGES >+ default "7" if PPC_STD_MMU_32 && PPC_64K_PAGES > range 11 64 > default "11" > help >@@ -437,7 +467,7 @@ config FORCE_MAX_ZONEORDER > > config PPC_SUBPAGE_PROT > bool "Support setting protections for 4k subpages" >- depends on PPC_64K_PAGES >+ depends on PPC_STD_MMU_64 && PPC_64K_PAGES > help > This option adds support for a system call to allow user programs > to set access permissions (read/write, readonly, or no access) >diff --git a/arch/powerpc/include/asm/highmem.h >b/arch/powerpc/include/asm/highmem.h >index 91c5895..7d6bb37 100644 >--- a/arch/powerpc/include/asm/highmem.h >+++ b/arch/powerpc/include/asm/highmem.h >@@ -38,9 +38,24
Re: [PATCH 3/5] powerpc/83xx: Add USB Host/Gadget support for MPC8360E-MDS boards
On Wed, Dec 17, 2008 at 10:59:09AM -0600, Kumar Gala wrote: > > On Dec 3, 2008, at 1:27 PM, Anton Vorontsov wrote: > >> - Update the device tree per QE USB bindings; >> - Add timer (FSL GTM) node; >> - Add gpio-controller node for BCSR13 bank (GPIOs on that bank >> are used to control the USB transceiver); >> - Set up other BCSR registers; >> - Configure the QE Par IO. > > Of these are they all in the kernel tree already? What I mean is QE usb > bindings in linus's tree? Yes, they're all in the Linus' tree already (except for simple/bcsr gpio bindings, which are in this patch series). Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc: Implement GPIO driver for simple memory-mapped banks
On Wed, Dec 17, 2008 at 10:56:08AM -0600, Kumar Gala wrote:
>
> On Dec 3, 2008, at 1:27 PM, Anton Vorontsov wrote:
>
>> The driver supports very simple GPIO controllers, that is, when a
>> controller provides just a 'data' register. Such controllers may be
>> found in various BCSRs (Board's FPGAs used to control board's
>> switches, LEDs, chip-selects, Ethernet/USB PHY power, etc).
>>
>> So far we support only 1-byte GPIO banks. Support for other widths may
>> be implemented when/if needed.
>>
>> p.s.
>> To avoid "made up" compatible entries (like compatible = "simple-
>> gpio"),
>> boards must call the simple_gpiochip_init() to pass the compatible
>> string.
>>
>> Signed-off-by: Anton Vorontsov
>> ---
>> Documentation/powerpc/dts-bindings/fsl/board.txt | 30
>
> can we pull this out of this patch.
Will do.
[...]
>> +#ifdef CONFIG_SIMPLE_GPIO
>> +extern int simple_gpiochip_init(const char *compatible);
>> +#else
>> +static inline int simple_gpiochip_init(const char *compatible)
>> +{
>> +return -ENODEV;
>> +}
>> +#endif /* CONFIG_SIMPLE_GPIO */
>> +
>> +#endif /* __SYSDEV_SIMPLE_GPIO_H */
>
> Can I call simple_gpiochip_init() multiple times w/different
> compatibles?
Yes, sure.
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/7] Kdump support for classic PPC
Hi all, This is Kdump part of the older series[1] posted few months ago. Yeah, I didn't bother with relocatable kernel support (yet), I just want to consolidate a position of the working Kdump implementation, and then we can improve it as time goes by. Other than that, all the comments that were previously made were addressed in this series. Hope this can make it into 2.6.29. Thanks, [1] http://ozlabs.org/pipermail/linuxppc-dev/2008-August/061161.html -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/7] powerpc: Prepare xmon_save_regs for use with kdump
Today the arch/powerpc/xmon/setjmp.S file contains only the
xmon_save_regs function. We want to use it for kdump purposes, so let's
move the file into arch/powerpc/kernel/ and give the function a more
generic name (ppc_save_regs).
Signed-off-by: Anton Vorontsov
---
This is "git-format-patch -M"-style patch.
arch/powerpc/include/asm/reg.h |4
arch/powerpc/kernel/Makefile |4
.../{xmon/setjmp.S => kernel/ppc_save_regs.S} |2 +-
arch/powerpc/xmon/Makefile |2 +-
arch/powerpc/xmon/xmon.c |5 ++---
5 files changed, 12 insertions(+), 5 deletions(-)
rename arch/powerpc/{xmon/setjmp.S => kernel/ppc_save_regs.S} (98%)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index c6d1ab6..f484a34 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -783,6 +783,10 @@ extern void scom970_write(unsigned int address, unsigned
long value);
#define __get_SP() ({unsigned long sp; \
asm volatile("mr %0,1": "=r" (sp)); sp;})
+struct pt_regs;
+
+extern void ppc_save_regs(struct pt_regs *regs);
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_REG_H */
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 92673b4..616c889 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -102,6 +102,10 @@ endif
obj-$(CONFIG_PPC64)+= $(obj64-y)
+ifneq ($(CONFIG_XMON),)
+obj-y += ppc_save_regs.o
+endif
+
extra-$(CONFIG_PPC_FPU)+= fpu.o
extra-$(CONFIG_PPC64) += entry_64.o
diff --git a/arch/powerpc/xmon/setjmp.S b/arch/powerpc/kernel/ppc_save_regs.S
similarity index 98%
rename from arch/powerpc/xmon/setjmp.S
rename to arch/powerpc/kernel/ppc_save_regs.S
index 04c0b30..5113bd2 100644
--- a/arch/powerpc/xmon/setjmp.S
+++ b/arch/powerpc/kernel/ppc_save_regs.S
@@ -22,7 +22,7 @@
* that will be different for 32-bit and 64-bit, because of the
* different ABIs, though).
*/
-_GLOBAL(xmon_save_regs)
+_GLOBAL(ppc_save_regs)
PPC_STL r0,0*SZL(r3)
PPC_STL r2,2*SZL(r3)
PPC_STL r3,3*SZL(r3)
diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile
index 51d9758..9cb03b7 100644
--- a/arch/powerpc/xmon/Makefile
+++ b/arch/powerpc/xmon/Makefile
@@ -4,7 +4,7 @@ ifdef CONFIG_PPC64
EXTRA_CFLAGS += -mno-minimal-toc
endif
-obj-y += xmon.o setjmp.o start.o nonstdio.o
+obj-y += xmon.o start.o nonstdio.o
ifdef CONFIG_XMON_DISASSEMBLY
obj-y += ppc-dis.o ppc-opc.o
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 076368c..8dfad7d 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_PPC64
#include
@@ -159,8 +160,6 @@ static int xmon_no_auto_backtrace;
extern void xmon_enter(void);
extern void xmon_leave(void);
-extern void xmon_save_regs(struct pt_regs *);
-
#ifdef CONFIG_PPC64
#define REG"%.16lx"
#define REGS_PER_LINE 4
@@ -532,7 +531,7 @@ int xmon(struct pt_regs *excp)
struct pt_regs regs;
if (excp == NULL) {
- xmon_save_regs(®s);
+ ppc_save_regs(®s);
excp = ®s;
}
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/7] powerpc/32/kdump: Implement crash_setup_regs() using ppc_save_regs()
This patch replaces dummy function with full-fledged crash_setup_regs()
implementation. On PPC32 we simply use ppc_save_regs function to dump
the registers.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/include/asm/kexec.h | 15 ++-
arch/powerpc/kernel/Makefile |2 +-
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index 3736d9b..6dbffc9 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -33,12 +33,12 @@
#ifndef __ASSEMBLY__
#include
+#include
typedef void (*crash_shutdown_t)(void);
#ifdef CONFIG_KEXEC
-#ifdef __powerpc64__
/*
* This function is responsible for capturing register states if coming
* via panic or invoking dump using sysrq-trigger.
@@ -48,6 +48,7 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
{
if (oldregs)
memcpy(newregs, oldregs, sizeof(*newregs));
+#ifdef __powerpc64__
else {
/* FIXME Merge this with xmon_save_regs ?? */
unsigned long tmp1, tmp2;
@@ -100,15 +101,11 @@ static inline void crash_setup_regs(struct pt_regs
*newregs,
: "b" (newregs)
: "memory");
}
-}
#else
-/*
- * Provide a dummy definition to avoid build failures. Will remain
- * empty till crash dump support is enabled.
- */
-static inline void crash_setup_regs(struct pt_regs *newregs,
- struct pt_regs *oldregs) { }
-#endif /* !__powerpc64 __ */
+ else
+ ppc_save_regs(newregs);
+#endif /* __powerpc64__ */
+}
extern void kexec_smp_wait(void); /* get and clear naca physid, wait for
master to copy new code to 0 */
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 616c889..089209a 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -102,7 +102,7 @@ endif
obj-$(CONFIG_PPC64)+= $(obj64-y)
-ifneq ($(CONFIG_XMON),)
+ifneq ($(CONFIG_XMON)$(CONFIG_KEXEC),)
obj-y += ppc_save_regs.o
endif
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/7] powerpc/32: Setup OF properties for kdump
From: Dale Farnsworth
Refactor the setting of kexec OF properties, moving the common code
from machine_kexec_64.c to machine_kexec.c where it can be used on
both ppc64 and ppc32. This will be needed for kdump to work on ppc32
platforms.
Signed-off-by: Dale Farnsworth
Signed-off-by: Anton Vorontsov
---
arch/powerpc/kernel/machine_kexec.c| 36
arch/powerpc/kernel/machine_kexec_64.c | 56 ++-
2 files changed, 40 insertions(+), 52 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index 4f797c0..b3abebb 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -120,6 +120,7 @@ int overlaps_crashkernel(unsigned long start, unsigned long
size)
/* Values we need to export to the second kernel via the device tree. */
static unsigned long kernel_end;
+static unsigned long crashk_size;
static struct property kernel_end_prop = {
.name = "linux,kernel-end",
@@ -127,6 +128,39 @@ static struct property kernel_end_prop = {
.value = &kernel_end,
};
+static struct property crashk_base_prop = {
+ .name = "linux,crashkernel-base",
+ .length = sizeof(unsigned long),
+ .value = &crashk_res.start,
+};
+
+static struct property crashk_size_prop = {
+ .name = "linux,crashkernel-size",
+ .length = sizeof(unsigned long),
+ .value = &crashk_size,
+};
+
+static void __init export_crashk_values(struct device_node *node)
+{
+ struct property *prop;
+
+ /* There might be existing crash kernel properties, but we can't
+* be sure what's in them, so remove them. */
+ prop = of_find_property(node, "linux,crashkernel-base", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ prop = of_find_property(node, "linux,crashkernel-size", NULL);
+ if (prop)
+ prom_remove_property(node, prop);
+
+ if (crashk_res.start != 0) {
+ prom_add_property(node, &crashk_base_prop);
+ crashk_size = crashk_res.end - crashk_res.start + 1;
+ prom_add_property(node, &crashk_size_prop);
+ }
+}
+
static int __init kexec_setup(void)
{
struct device_node *node;
@@ -145,6 +179,8 @@ static int __init kexec_setup(void)
kernel_end = __pa(_end);
prom_add_property(node, &kernel_end_prop);
+ export_crashk_values(node);
+
of_node_put(node);
return 0;
}
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index a89bce8..49e705f 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -303,18 +303,18 @@ static struct property htab_size_prop = {
.value = &htab_size_bytes,
};
-static void __init export_htab_values(void)
+static int __init export_htab_values(void)
{
struct device_node *node;
struct property *prop;
/* On machines with no htab htab_address is NULL */
if (!htab_address)
- return;
+ return -ENODEV;
node = of_find_node_by_path("/chosen");
if (!node)
- return;
+ return -ENODEV;
/* remove any stale propertys so ours can be found */
prop = of_find_property(node, htab_base_prop.name, NULL);
@@ -329,54 +329,6 @@ static void __init export_htab_values(void)
prom_add_property(node, &htab_size_prop);
of_node_put(node);
-}
-
-static struct property crashk_base_prop = {
- .name = "linux,crashkernel-base",
- .length = sizeof(unsigned long),
- .value = &crashk_res.start,
-};
-
-static unsigned long crashk_size;
-
-static struct property crashk_size_prop = {
- .name = "linux,crashkernel-size",
- .length = sizeof(unsigned long),
- .value = &crashk_size,
-};
-
-static void __init export_crashk_values(void)
-{
- struct device_node *node;
- struct property *prop;
-
- node = of_find_node_by_path("/chosen");
- if (!node)
- return;
-
- /* There might be existing crash kernel properties, but we can't
-* be sure what's in them, so remove them. */
- prop = of_find_property(node, "linux,crashkernel-base", NULL);
- if (prop)
- prom_remove_property(node, prop);
-
- prop = of_find_property(node, "linux,crashkernel-size", NULL);
- if (prop)
- prom_remove_property(node, prop);
-
- if (crashk_res.start != 0) {
- prom_add_property(node, &crashk_base_prop);
- crashk_size = crashk_res.end - crashk_res.start + 1;
- prom_add_property(node, &crashk_size_prop);
- }
-
- of_node_put(node);
-}
-
-static int __init kexec_setup(void)
-{
- export_htab_values();
- export_crashk_values();
return 0;
}
-__initcall(kexec_setup);
+late_initcall(export_htab_values);
--
1.5.6.5
[PATCH 4/7] powerpc/32: Allow to ioremap RAM addresses for kdump kernel
While for debugging it is good to catch bogus users of ioremap, though for kdump support it is more convenient to use ioremap for copy_oldmem_page() (exactly as we do for PPC64 currently). Note that copy_oldmem_page() calls __ioremap with flags set to '0', so it should be safe with the regard to the caches. The other option is to use kmap_atomic_pfn()[1], but it will not work for kernels compiled without HIGHMEM. That is, on a board with 256MB RAM and crashkernel=...@32m case, the !HIGHMEM capturing kernel maps 0-96M range, which does not include all the memory needed to capture the dump. And, obviously, accessing anything upper than 96M will cause faults. [1] http://ozlabs.org/pipermail/linuxppc-dev/2007-November/046747.html Signed-off-by: Anton Vorontsov --- arch/powerpc/mm/pgtable_32.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c index 3414724..cd56097 100644 --- a/arch/powerpc/mm/pgtable_32.c +++ b/arch/powerpc/mm/pgtable_32.c @@ -173,6 +173,7 @@ __ioremap(phys_addr_t addr, unsigned long size, unsigned long flags) if (p < 16*1024*1024) p += _ISA_MEM_BASE; +#ifndef CONFIG_CRASH_DUMP /* * Don't allow anybody to remap normal RAM that we're using. * mem_init() sets high_memory so only do the check after that. @@ -182,6 +183,7 @@ __ioremap(phys_addr_t addr, unsigned long size, unsigned long flags) (unsigned long long)p, __builtin_return_address(0)); return NULL; } +#endif if (size == 0) return NULL; -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/7] powerpc/32: Add the ability for a classic ppc kernel to be loaded at 32M
From: Dale Farnsworth
Add the ability for a classic ppc kernel to be loaded at an address
of 32MB. This done by fixing a few places that assume we are loaded
at address 0, and by changing several uses of KERNELBASE to use
PAGE_OFFSET, instead.
Signed-off-by: Dale Farnsworth
Signed-off-by: Anton Vorontsov
---
arch/powerpc/include/asm/ppc_asm.h |4 ++--
arch/powerpc/kernel/head_32.S | 11 ++-
arch/powerpc/mm/init_32.c |2 +-
arch/powerpc/mm/pgtable_32.c |4 ++--
arch/powerpc/mm/ppc_mmu_32.c |8
5 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc_asm.h
b/arch/powerpc/include/asm/ppc_asm.h
index c4a029c..1a0d628 100644
--- a/arch/powerpc/include/asm/ppc_asm.h
+++ b/arch/powerpc/include/asm/ppc_asm.h
@@ -425,14 +425,14 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
#define fromreal(rd) tovirt(rd,rd)
#define tophys(rd,rs) \
-0: addis rd,rs,-kernelb...@h;\
+0: addis rd,rs,-page_off...@h; \
.section ".vtop_fixup","aw";\
.align 1; \
.long 0b; \
.previous
#define tovirt(rd,rs) \
-0: addis rd,rs,kernelb...@h; \
+0: addis rd,rs,page_off...@h;\
.section ".ptov_fixup","aw";\
.align 1; \
.long 0b; \
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 0c32682..97338d9 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -182,7 +182,8 @@ __after_mmu_off:
bl reloc_offset
mr r26,r3
addis r4,r3,kernelb...@h /* current address of _start */
- cmpwi 0,r4,0 /* are we already running at 0? */
+ lis r5,physical_st...@h
+ cmplw 0,r4,r5 /* already running at PHYSICAL_START? */
bne relocate_kernel
/*
* we now have the 1st 16M of ram mapped with the bats.
@@ -810,13 +811,13 @@ giveup_altivec:
/*
* This code is jumped to from the startup code to copy
- * the kernel image to physical address 0.
+ * the kernel image to physical address PHYSICAL_START.
*/
relocate_kernel:
addis r9,r26,kli...@ha/* fetch klimit */
lwz r25,kli...@l(r9)
addis r25,r25,-kernelb...@h
- li r3,0/* Destination base address */
+ lis r3,physical_st...@h /* Destination base address */
li r6,0/* Destination offset */
li r5,0x4000 /* # bytes of memory to copy */
bl copy_and_flush /* copy the first 0x4000 bytes */
@@ -1178,11 +1179,11 @@ mmu_off:
/*
* Use the first pair of BAT registers to map the 1st 16MB
- * of RAM to KERNELBASE. From this point on we can't safely
+ * of RAM to PAGE_OFFSET. From this point on we can't safely
* call OF any more.
*/
initial_bats:
- lis r11,kernelb...@h
+ lis r11,page_off...@h
mfspr r9,SPRN_PVR
rlwinm r9,r9,16,16,31 /* r9 = 1 for 601, 4 for 604 */
cmpwi 0,r9,1
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 388ceda..4ac0e4e 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -49,7 +49,7 @@
#if defined(CONFIG_KERNEL_START_BOOL) || defined(CONFIG_LOWMEM_SIZE_BOOL)
/* The ammount of lowmem must be within 0xF000 - KERNELBASE. */
-#if (CONFIG_LOWMEM_SIZE > (0xF000 - KERNELBASE))
+#if (CONFIG_LOWMEM_SIZE > (0xF000 - PAGE_OFFSET))
#error "You must adjust CONFIG_LOWMEM_SIZE or CONFIG_START_KERNEL"
#endif
#endif
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index cd56097..8cba46f 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -269,7 +269,7 @@ int map_page(unsigned long va, phys_addr_t pa, int flags)
}
/*
- * Map in a big chunk of physical memory starting at KERNELBASE.
+ * Map in a big chunk of physical memory starting at PAGE_OFFSET.
*/
void __init mapin_ram(void)
{
@@ -278,7 +278,7 @@ void __init mapin_ram(void)
int ktext;
s = mmu_mapin_ram();
- v = KERNELBASE + s;
+ v = PAGE_OFFSET + s;
p = memstart_addr + s;
for (; s < total_lowmem; s += PAGE_SIZE) {
ktext = ((char *) v >= _stext && (char *) v < etext);
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index 6aa1208..49b195e 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -95,16 +95,16 @@ unsigned long __init mmu_mapin_ram(void)
break;
}
- setbat(2, KERNELBASE, 0, bl, _PAGE_RAM);
- done = (unsigned long)bat_addrs[2].limit - KERNELBASE + 1;
+ setbat(2, PAGE_OFFSET,
Re: [PATCH 1/5] powerpc/qe: Implement QE Pin Multiplexing API
On Wed, Dec 03, 2008 at 10:27:38PM +0300, Anton Vorontsov wrote:
> With this API we're able to set a QE pin to the GPIO mode or a dedicated
> peripheral function.
>
> The API relies on the fact that QE gpio controllers are registered. If
> they aren't, the API won't work (gracefully though).
>
> There is one caveat though: if anybody occupied the node->data before us,
> or overwrote it, then bad things will happen. Luckily this is all in the
> platform code that we fully control, so this should never happen.
>
> I could implement more checks (for example we could create a list of
> successfully registered QE controllers, and compare the node->data in the
> qe_pin_request()), but this is unneeded if nobody is going to do silly
> things behind our back.
>
> Signed-off-by: Anton Vorontsov
> ---
Kumar, can you please merge this patch? It is the last patch that
holds the FHCI USB driver.
Thanks,
> arch/powerpc/include/asm/qe.h | 21
> arch/powerpc/sysdev/qe_lib/gpio.c | 195
> +
> 2 files changed, 216 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
> index edee15d..3227440 100644
> --- a/arch/powerpc/include/asm/qe.h
> +++ b/arch/powerpc/include/asm/qe.h
> @@ -17,6 +17,8 @@
> #ifdef __KERNEL__
>
> #include
> +#include
> +#include
> #include
> #include
>
> @@ -112,6 +114,25 @@ extern int par_io_config_pin(u8 port, u8 pin, int dir,
> int open_drain,
>int assignment, int has_irq);
> extern int par_io_data_set(u8 port, u8 pin, u8 val);
>
> +/*
> + * Pin multiplexing functions.
> + */
> +struct qe_pin;
> +#ifdef CONFIG_QE_GPIO
> +extern struct qe_pin *qe_pin_request(struct device_node *np, int index);
> +extern void qe_pin_free(struct qe_pin *qe_pin);
> +extern void qe_pin_set_gpio(struct qe_pin *qe_pin);
> +extern void qe_pin_set_dedicated(struct qe_pin *pin);
> +#else
> +static inline struct qe_pin *qe_pin_request(struct device_node *np, int
> index)
> +{
> + return ERR_PTR(-ENOSYS);
> +}
> +static inline void qe_pin_free(struct qe_pin *qe_pin) {}
> +static inline void qe_pin_set_gpio(struct qe_pin *qe_pin) {}
> +static inline void qe_pin_set_dedicated(struct qe_pin *pin) {}
> +#endif /* CONFIG_QE_GPIO */
> +
> /* QE internal API */
> int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input);
> enum qe_clock qe_clock_source(const char *source);
> diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c
> b/arch/powerpc/sysdev/qe_lib/gpio.c
> index 8e5a0bc..3485288 100644
> --- a/arch/powerpc/sysdev/qe_lib/gpio.c
> +++ b/arch/powerpc/sysdev/qe_lib/gpio.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -24,8 +25,14 @@ struct qe_gpio_chip {
> struct of_mm_gpio_chip mm_gc;
> spinlock_t lock;
>
> + unsigned long pin_flags[QE_PIO_PINS];
> +#define QE_PIN_REQUESTED 0
> +
> /* shadowed data register to clear/set bits safely */
> u32 cpdata;
> +
> + /* saved_regs used to restore dedicated functions */
> + struct qe_pio_regs saved_regs;
> };
>
> static inline struct qe_gpio_chip *
> @@ -40,6 +47,12 @@ static void qe_gpio_save_regs(struct of_mm_gpio_chip
> *mm_gc)
> struct qe_pio_regs __iomem *regs = mm_gc->regs;
>
> qe_gc->cpdata = in_be32(®s->cpdata);
> + qe_gc->saved_regs.cpdata = qe_gc->cpdata;
> + qe_gc->saved_regs.cpdir1 = in_be32(®s->cpdir1);
> + qe_gc->saved_regs.cpdir2 = in_be32(®s->cpdir2);
> + qe_gc->saved_regs.cppar1 = in_be32(®s->cppar1);
> + qe_gc->saved_regs.cppar2 = in_be32(®s->cppar2);
> + qe_gc->saved_regs.cpodr = in_be32(®s->cpodr);
> }
>
> static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> @@ -103,6 +116,188 @@ static int qe_gpio_dir_out(struct gpio_chip *gc,
> unsigned int gpio, int val)
> return 0;
> }
>
> +struct qe_pin {
> + /*
> + * The qe_gpio_chip name is unfortunate, we should change that to
> + * something like qe_pio_controller. Someday.
> + */
> + struct qe_gpio_chip *controller;
> + int num;
> +};
> +
> +/**
> + * qe_pin_request - Request a QE pin
> + * @np: device node to get a pin from
> + * @index: index of a pin in the device tree
> + * Context: non-atomic
> + *
> + * This function return qe_pin so that you could use it with the rest of
> + * the QE Pin Multiplexing API.
> + */
> +struct qe_pin *qe_pin_request(struct device_node *np, int index)
> +{
> + struct qe_pin *qe_pin;
> + struct device_node *gc;
> + struct of_gpio_chip *of_gc = NULL;
> + struct of_mm_gpio_chip *mm_gc;
> + struct qe_gpio_chip *qe_gc;
> + int err;
> + int size;
> + const void *gpio_spec;
> + const u32 *gpio_cells;
> + unsigned long flags;
> +
> + qe_pin = kzalloc(sizeof(*qe_pin), GFP_KERNEL);
> + if (!qe_pin) {
> + pr_debug("%s: can't allocate memory\n", __func__);
> +
[PATCH 6/7] powerpc/32: Wire up the trampoline code for kdump
From: Dale Farnsworth Wire up the trampoline code for ppc32 to relay exceptions from the vectors at address 0 to vectors at address 32MB, and modify Kconfig to enable Kdump support for all classic powerpcs. Signed-off-by: Dale Farnsworth Signed-off-by: Anton Vorontsov --- arch/powerpc/Kconfig |2 +- arch/powerpc/include/asm/kdump.h | 13 + arch/powerpc/kernel/setup_32.c |2 ++ 3 files changed, 16 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index be4f99b..f7f5448 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -326,7 +326,7 @@ config KEXEC config CRASH_DUMP bool "Build a kdump crash kernel" - depends on PPC_MULTIPLATFORM && PPC64 && RELOCATABLE + depends on (PPC64 && RELOCATABLE) || 6xx help Build a kernel suitable for use as a kdump capture kernel. The same kernel binary can be used as production kernel and dump diff --git a/arch/powerpc/include/asm/kdump.h b/arch/powerpc/include/asm/kdump.h index b07ebb9..5ebfe5d 100644 --- a/arch/powerpc/include/asm/kdump.h +++ b/arch/powerpc/include/asm/kdump.h @@ -1,6 +1,8 @@ #ifndef _PPC64_KDUMP_H #define _PPC64_KDUMP_H +#include + /* Kdump kernel runs at 32 MB, change at your peril. */ #define KDUMP_KERNELBASE 0x200 @@ -11,8 +13,19 @@ #ifdef CONFIG_CRASH_DUMP +/* + * On PPC64 translation is disabled during trampoline setup, so we use + * physical addresses. Though on PPC32 translation is already enabled, + * so we can't do the same. Luckily create_trampoline() creates relative + * branches, so we can just add the PAGE_OFFSET and don't worry about it. + */ +#ifdef __powerpc64__ #define KDUMP_TRAMPOLINE_START 0x0100 #define KDUMP_TRAMPOLINE_END 0x3000 +#else +#define KDUMP_TRAMPOLINE_START (0x0100 + PAGE_OFFSET) +#define KDUMP_TRAMPOLINE_END (0x3000 + PAGE_OFFSET) +#endif /* __powerpc64__ */ #define KDUMP_MIN_TCE_ENTRIES 2048 diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c index 086c23c..9ca1d2b 100644 --- a/arch/powerpc/kernel/setup_32.c +++ b/arch/powerpc/kernel/setup_32.c @@ -121,6 +121,8 @@ notrace void __init machine_init(unsigned long dt_ptr) probe_machine(); + setup_kdump_trampoline(); + #ifdef CONFIG_6xx if (cpu_has_feature(CPU_FTR_CAN_DOZE) || cpu_has_feature(CPU_FTR_CAN_NAP)) -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/7] powerpc/64/kdump: Use ppc_save_regs() in crash_setup_regs()
The patch replaces internal registers dump implementation with
ppc_save_regs(). From now on PPC64 and PPC32 are using the same
code for crash_setup_regs().
NOTE: The old regs dump implementation was capturing SP (r1) directly
as is, so you could see crash_kexec() function on top of the back-trace.
But ppc_save_regs() goes up one stack frame, so you'll not see it
anymore, at the top-level you'll see who actually triggered the crash
dump instead.
Signed-off-by: Anton Vorontsov
---
p.s.
The patch is the last in the series, so you can easily drop it
until somebody actually test it (I don't have any PPC64 machine,
so I'm looking for volunteers. :-)
arch/powerpc/include/asm/kexec.h | 55 --
1 files changed, 0 insertions(+), 55 deletions(-)
diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index 6dbffc9..7e06b43 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -48,63 +48,8 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
{
if (oldregs)
memcpy(newregs, oldregs, sizeof(*newregs));
-#ifdef __powerpc64__
- else {
- /* FIXME Merge this with xmon_save_regs ?? */
- unsigned long tmp1, tmp2;
- __asm__ __volatile__ (
- "std0,0(%2)\n"
- "std1,8(%2)\n"
- "std2,16(%2)\n"
- "std3,24(%2)\n"
- "std4,32(%2)\n"
- "std5,40(%2)\n"
- "std6,48(%2)\n"
- "std7,56(%2)\n"
- "std8,64(%2)\n"
- "std9,72(%2)\n"
- "std10,80(%2)\n"
- "std11,88(%2)\n"
- "std12,96(%2)\n"
- "std13,104(%2)\n"
- "std14,112(%2)\n"
- "std15,120(%2)\n"
- "std16,128(%2)\n"
- "std17,136(%2)\n"
- "std18,144(%2)\n"
- "std19,152(%2)\n"
- "std20,160(%2)\n"
- "std21,168(%2)\n"
- "std22,176(%2)\n"
- "std23,184(%2)\n"
- "std24,192(%2)\n"
- "std25,200(%2)\n"
- "std26,208(%2)\n"
- "std27,216(%2)\n"
- "std28,224(%2)\n"
- "std29,232(%2)\n"
- "std30,240(%2)\n"
- "std31,248(%2)\n"
- "mfmsr %0\n"
- "std%0, 264(%2)\n"
- "mfctr %0\n"
- "std%0, 280(%2)\n"
- "mflr %0\n"
- "std%0, 288(%2)\n"
- "bl 1f\n"
- "1: mflr %1\n"
- "std%1, 256(%2)\n"
- "mtlr %0\n"
- "mfxer %0\n"
- "std%0, 296(%2)\n"
- : "=&r" (tmp1), "=&r" (tmp2)
- : "b" (newregs)
- : "memory");
- }
-#else
else
ppc_save_regs(newregs);
-#endif /* __powerpc64__ */
}
extern void kexec_smp_wait(void); /* get and clear naca physid, wait for
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/7] powerpc: Prepare xmon_save_regs for use with kdump
Today the arch/powerpc/xmon/setjmp.S file contains only the
xmon_save_regs function. We want to use it for kdump purposes, so let's
move the file into arch/powerpc/kernel/ and give the function a more
generic name (ppc_save_regs).
Signed-off-by: Anton Vorontsov
---
The same patch but suitable for patch(1), quilt users would
appreciate. ;-)
arch/powerpc/include/asm/reg.h |4 ++
arch/powerpc/kernel/Makefile|4 ++
arch/powerpc/kernel/ppc_save_regs.S | 74 +++
arch/powerpc/xmon/Makefile |2 +-
arch/powerpc/xmon/setjmp.S | 74 ---
arch/powerpc/xmon/xmon.c|5 +-
6 files changed, 85 insertions(+), 78 deletions(-)
create mode 100644 arch/powerpc/kernel/ppc_save_regs.S
delete mode 100644 arch/powerpc/xmon/setjmp.S
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index c6d1ab6..f484a34 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -783,6 +783,10 @@ extern void scom970_write(unsigned int address, unsigned
long value);
#define __get_SP() ({unsigned long sp; \
asm volatile("mr %0,1": "=r" (sp)); sp;})
+struct pt_regs;
+
+extern void ppc_save_regs(struct pt_regs *regs);
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_REG_H */
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 92673b4..616c889 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -102,6 +102,10 @@ endif
obj-$(CONFIG_PPC64)+= $(obj64-y)
+ifneq ($(CONFIG_XMON),)
+obj-y += ppc_save_regs.o
+endif
+
extra-$(CONFIG_PPC_FPU)+= fpu.o
extra-$(CONFIG_PPC64) += entry_64.o
diff --git a/arch/powerpc/kernel/ppc_save_regs.S
b/arch/powerpc/kernel/ppc_save_regs.S
new file mode 100644
index 000..5113bd2
--- /dev/null
+++ b/arch/powerpc/kernel/ppc_save_regs.S
@@ -0,0 +1,74 @@
+/*
+ * Copyright (C) 1996 Paul Mackerras.
+ *
+ * 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.
+ *
+ * NOTE: assert(sizeof(buf) > 23 * sizeof(long))
+ */
+#include
+#include
+#include
+
+/*
+ * Grab the register values as they are now.
+ * This won't do a particularily good job because we really
+ * want our caller's caller's registers, and our caller has
+ * already executed its prologue.
+ * ToDo: We could reach back into the caller's save area to do
+ * a better job of representing the caller's state (note that
+ * that will be different for 32-bit and 64-bit, because of the
+ * different ABIs, though).
+ */
+_GLOBAL(ppc_save_regs)
+ PPC_STL r0,0*SZL(r3)
+ PPC_STL r2,2*SZL(r3)
+ PPC_STL r3,3*SZL(r3)
+ PPC_STL r4,4*SZL(r3)
+ PPC_STL r5,5*SZL(r3)
+ PPC_STL r6,6*SZL(r3)
+ PPC_STL r7,7*SZL(r3)
+ PPC_STL r8,8*SZL(r3)
+ PPC_STL r9,9*SZL(r3)
+ PPC_STL r10,10*SZL(r3)
+ PPC_STL r11,11*SZL(r3)
+ PPC_STL r12,12*SZL(r3)
+ PPC_STL r13,13*SZL(r3)
+ PPC_STL r14,14*SZL(r3)
+ PPC_STL r15,15*SZL(r3)
+ PPC_STL r16,16*SZL(r3)
+ PPC_STL r17,17*SZL(r3)
+ PPC_STL r18,18*SZL(r3)
+ PPC_STL r19,19*SZL(r3)
+ PPC_STL r20,20*SZL(r3)
+ PPC_STL r21,21*SZL(r3)
+ PPC_STL r22,22*SZL(r3)
+ PPC_STL r23,23*SZL(r3)
+ PPC_STL r24,24*SZL(r3)
+ PPC_STL r25,25*SZL(r3)
+ PPC_STL r26,26*SZL(r3)
+ PPC_STL r27,27*SZL(r3)
+ PPC_STL r28,28*SZL(r3)
+ PPC_STL r29,29*SZL(r3)
+ PPC_STL r30,30*SZL(r3)
+ PPC_STL r31,31*SZL(r3)
+ /* go up one stack frame for SP */
+ PPC_LL r4,0(r1)
+ PPC_STL r4,1*SZL(r3)
+ /* get caller's LR */
+ PPC_LL r0,LRSAVE(r4)
+ PPC_STL r0,_NIP-STACK_FRAME_OVERHEAD(r3)
+ PPC_STL r0,_LINK-STACK_FRAME_OVERHEAD(r3)
+ mfmsr r0
+ PPC_STL r0,_MSR-STACK_FRAME_OVERHEAD(r3)
+ mfctr r0
+ PPC_STL r0,_CTR-STACK_FRAME_OVERHEAD(r3)
+ mfxer r0
+ PPC_STL r0,_XER-STACK_FRAME_OVERHEAD(r3)
+ mfcrr0
+ PPC_STL r0,_CCR-STACK_FRAME_OVERHEAD(r3)
+ li r0,0
+ PPC_STL r0,_TRAP-STACK_FRAME_OVERHEAD(r3)
+ blr
diff --git a/arch/powerpc/xmon/Makefile b/arch/powerpc/xmon/Makefile
index 51d9758..9cb03b7 100644
--- a/arch/powerpc/xmon/Makefile
+++ b/arch/powerpc/xmon/Makefile
@@ -4,7 +4,7 @@ ifdef CONFIG_PPC64
EXTRA_CFLAGS += -mno-minimal-toc
endif
-obj-y += xmon.o setjmp.o start.o nonstdio.o
+obj-y += xmon.o start.o nonstdio.o
ifdef CONFIG_XMON_DISASSEMBLY
obj-y += ppc-dis.o ppc-opc.o
diff --git a/arch/powerpc/xmon/setjmp.S b/arch/powerpc/xmon/setjmp.S
deleted file mode 100644
index 04c
Re: [PATCH 3/5] powerpc/83xx: Add USB Host/Gadget support for MPC8360E-MDS boards
On Dec 17, 2008, at 11:15 AM, Anton Vorontsov wrote: On Wed, Dec 17, 2008 at 10:59:09AM -0600, Kumar Gala wrote: On Dec 3, 2008, at 1:27 PM, Anton Vorontsov wrote: - Update the device tree per QE USB bindings; - Add timer (FSL GTM) node; - Add gpio-controller node for BCSR13 bank (GPIOs on that bank are used to control the USB transceiver); - Set up other BCSR registers; - Configure the QE Par IO. Of these are they all in the kernel tree already? What I mean is QE usb bindings in linus's tree? Yes, they're all in the Linus' tree already (except for simple/bcsr gpio bindings, which are in this patch series). Ok. If you fixup my comment about splitting up patch 2/5 & 3/5 w/ regards to BCSR GPIO and repost the patch series (excluding 1/5 since that is in my tree) I'll apply all these since they look good. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull bjdoo ks' i2c-fixes
Hi Ben, > Mike Ditto (1): > i2c-cpm: Detect and report NAK right away instead of timing out Could you also have a look at http://patchwork.ozlabs.org/patch/7452/ ? (Discussion at http://patchwork.ozlabs.org/patch// ) IIRC, Kumar prefers to push this via your tree. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FHCI driver adaptation for CPM2
> Hi Remi, Hi Laurent, > You will find my latest version of the CPM2 FHCI patch attached to this e- > mail. I've never bothered to clean it as we decided to drop the USB host > function from our device. Thank you very much. Not clean is better than lost. > This depends on the disk. Some will probably not check the SOF token, others > will do and behave strangely. > >> Also 40% seems quite a lot, even at 1000Hz interruptions, an idea how much >> does the CRC computation contribute in this CPU hogging ? > > I haven't measured that, but probably not much. The biggest CPU time eater > isn't the SOF generation interrupt but the USB packet handling code. The CPM2 > USB host controller is really too low-level to be usable (except maybe for > specific applications). Comparing the OHCI/UHCI/EHCI and FHCI controllers is > akin to bit like comparing a full 16550 UART with a software bit-bang > implementation. You can get around with it, it might work for your specific > application, but you shouldn't try a full speed 115200bds communication while > computing a CPU-hungry physical simulation. That's what I was afraid of. I now understand clearly why you didn't expect that much better performance with CPM3 in a past message (http://ozlabs.org/pipermail/linuxppc-embedded/2008-May/030508.html). Still, as you said, it can have some use for specific applications. Do you remember the throughput you were able to reach with this cpu overhead ? > Laurent Pinchart > CSE Semaphore Belgium Kind regards, Rémi Lefèvre ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: What means "technology has been retired"?
Kevin Diggs wrote: Does anyone know what the statement: "This technology has been retired." on this page: http://www.alphaworks.ibm.com/tech/powerscale4ppc means? Something about 970FX frequency scaling? I'm guessing they simply don't want to bother supporting the maple/970 anymore. Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RFC] Pass a valid token to rats_call() in phyp-dump code.
On Tue, Dec 16, 2008 at 03:34:43PM +1100, Tony Breeds wrote: >ibm_configure_kernel_dump, is passed as the token to rtas_call() but I >cannot see where it is initialised. Set it to something sane? > >Signed-off-by: Tony Breeds Seems sane as a fix, just a note that whoever needs to apply this patch should fix the Subject line to say "rtas" and not "rats". Though rats is applicable at times :) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] powerpc/qe: Implement QE Pin Multiplexing API
On Dec 3, 2008, at 1:27 PM, Anton Vorontsov wrote: With this API we're able to set a QE pin to the GPIO mode or a dedicated peripheral function. The API relies on the fact that QE gpio controllers are registered. If they aren't, the API won't work (gracefully though). There is one caveat though: if anybody occupied the node->data before us, or overwrote it, then bad things will happen. Luckily this is all in the platform code that we fully control, so this should never happen. I could implement more checks (for example we could create a list of successfully registered QE controllers, and compare the node->data in the qe_pin_request()), but this is unneeded if nobody is going to do silly things behind our back. Signed-off-by: Anton Vorontsov --- arch/powerpc/include/asm/qe.h | 21 arch/powerpc/sysdev/qe_lib/gpio.c | 195 + 2 files changed, 216 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ndfc driver
On Wed, Dec 10, 2008 at 06:16:34PM -0500, Sean MacLennan wrote:
>Here is an updated patch. Doc has been moved to 4xx and amcc changed to
>ibm.
>
>Arnd: I removed your acked-by just in case you don't approve of the new
>flash layout. Feel free to ack again.
>
>Cheers,
> Sean
>
>Port of the ndfc driver to an OF platform driver.
>
>Signed-off-by: Sean MacLennan
Acked-By: Josh Boyer
David, if you have no objections I'd like to take this patch
through my tree. I'll fixup the subject and commit log when
I do.
josh
>---
>diff --git a/Documentation/powerpc/dts-bindings/4xx/ndfc.txt
>b/Documentation/powerpc/dts-bindings/4xx/ndfc.txt
>new file mode 100644
>index 000..869f0b5
>--- /dev/null
>+++ b/Documentation/powerpc/dts-bindings/4xx/ndfc.txt
>@@ -0,0 +1,39 @@
>+AMCC NDFC (NanD Flash Controller)
>+
>+Required properties:
>+- compatible : "ibm,ndfc".
>+- reg : should specify chip select and size used for the chip (0x2000).
>+
>+Optional properties:
>+- ccr : NDFC config and control register value (default 0).
>+- bank-settings : NDFC bank configuration register value (default 0).
>+
>+Notes:
>+- partition(s) - follows the OF MTD standard for partitions
>+
>+Example:
>+
>+n...@1,0 {
>+ compatible = "ibm,ndfc";
>+ reg = <0x0001 0x 0x2000>;
>+ ccr = <0x1000>;
>+ bank-settings = <0x8000>;
>+ #address-cells = <1>;
>+ #size-cells = <1>;
>+
>+ nand {
>+ #address-cells = <1>;
>+ #size-cells = <1>;
>+
>+ partit...@0 {
>+ label = "kernel";
>+ reg = <0x 0x0020>;
>+ };
>+ partit...@20 {
>+ label = "root";
>+ reg = <0x0020 0x03E0>;
>+ };
>+ };
>+};
>+
>+
>diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
>index 1c2e945..5705f85 100644
>--- a/drivers/mtd/nand/Kconfig
>+++ b/drivers/mtd/nand/Kconfig
>@@ -163,6 +163,13 @@ config MTD_NAND_S3C2410_HWECC
> incorrect ECC generation, and if using these, the default of
> software ECC is preferable.
>
>+config MTD_NAND_NDFC
>+ tristate "NDFC NanD Flash Controller"
>+ depends on 4xx
>+ select MTD_NAND_ECC_SMC
>+ help
>+ NDFC Nand Flash Controllers are integrated in IBM/AMCC's 4xx SoCs
>+
> config MTD_NAND_S3C2410_CLKSTOP
> bool "S3C2410 NAND IDLE clock stop"
> depends on MTD_NAND_S3C2410
>diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
>index 955959e..582cf80 100644
>--- a/drivers/mtd/nand/ndfc.c
>+++ b/drivers/mtd/nand/ndfc.c
>@@ -2,12 +2,20 @@
> * drivers/mtd/ndfc.c
> *
> * Overview:
>- * Platform independend driver for NDFC (NanD Flash Controller)
>+ * Platform independent driver for NDFC (NanD Flash Controller)
> * integrated into EP440 cores
> *
>+ * Ported to an OF platform driver by Sean MacLennan
>+ *
>+ * The NDFC supports multiple chips, but this driver only supports a
>+ * single chip since I do not have access to any boards with
>+ * multiple chips.
>+ *
> * Author: Thomas Gleixner
> *
> * Copyright 2006 IBM
>+ * Copyright 2008 PIKA Technologies
>+ *Sean MacLennan
> *
> * This program is free software; you can redistributeit and/or
> modify it
> * under the terms ofthe GNU General Public License as published
> by the
>@@ -21,27 +29,20 @@
> #include
> #include
> #include
>-#include
>-
>+#include
> #include
>-#ifdef CONFIG_40x
>-#include
>-#else
>-#include
>-#endif
>-
>-struct ndfc_nand_mtd {
>- struct mtd_info mtd;
>- struct nand_chipchip;
>- struct platform_nand_chip *pl_chip;
>-};
>
>-static struct ndfc_nand_mtd ndfc_mtd[NDFC_MAX_BANKS];
>
> struct ndfc_controller {
>- void __iomem*ndfcbase;
>- struct nand_hw_control ndfc_control;
>- atomic_tchilds_active;
>+ struct of_device *ofdev;
>+ void __iomem *ndfcbase;
>+ struct mtd_info mtd;
>+ struct nand_chip chip;
>+ int chip_select;
>+ struct nand_hw_control ndfc_control;
>+#ifdef CONFIG_MTD_PARTITIONS
>+ struct mtd_partition *parts;
>+#endif
> };
>
> static struct ndfc_controller ndfc_ctrl;
>@@ -50,17 +51,14 @@ static void ndfc_select_chip(struct mtd_info *mtd, int
>chip)
> {
> uint32_t ccr;
> struct ndfc_controller *ndfc = &ndfc_ctrl;
>- struct nand_chip *nandchip = mtd->priv;
>- struct ndfc_nand_mtd *nandmtd = nandchip->priv;
>- struct platform_nand_chip *pchip = nandmtd->pl_chip;
>
>- ccr = __raw_readl(ndfc->ndfcbase + NDFC_CCR);
>+ ccr = in_be32(ndfc->ndfcbase + NDFC_CCR);
> if (chip >= 0) {
> ccr &= ~NDFC_CCR_BS_MASK;
>- ccr |= NDFC_CCR_BS(chip + pchip->chip_offset);
>+ ccr |= NDFC_CCR_BS(chip + ndfc->chip_select);
> } else
> ccr |= NDFC_CCR_RESET_CE;
>- __raw_writel(ccr, ndfc->ndfcb
Re: [PATCH 1/5] powerpc/qe: Implement QE Pin Multiplexing API
Kumar, can you please merge this patch? It is the last patch that holds the FHCI USB driver. Thanks, Will do. Can I get you to add kdoc comments for the API functions: The functions already have kdoc comments (see qe_lib/gpio.c changes). Yeah, I noticed that.. sorry about the noise. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] POWERPC/fsl-pci: Better ATMU setup
On Wed, 2008-12-17 at 11:43 -0800, Trent Piepho wrote: The default ATMU window can support a pci_mem_offset less than zero too, but pci_mem_offset is unsigned. One could say the abilities allowed a powerpc pci_controller is neither subset nor a superset of the abilities of a Freescale PCIe controller. Thankfully, the most useful bits are in the intersection of the two abilities. That sign issue shouldn't be too hard to fix if there's a real need by making sure everything is unsigned and of the same width, in which case, an addition with the unsigned pci_mem_offset will properly result in a substraction of the later is negative, even when everybody is unsigned :-) But I don't see any pressing need for that. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] POWERPC: MTD: Add cached map support to physmap_of MTD driver
On Tue, 16 Dec 2008, Benjamin Herrenschmidt wrote:
> On Mon, 2008-12-15 at 17:11 -0800, Trent Piepho wrote:
>> Shame, as it provides a huge speed up. I suppose an alternative would be
>> to map the chip twice at different physical addresses, by just configuring
>> the chip select to be twice the size it should be, and giving them
>> different cacheability.
>
> Nice trick. That would probably work.
Thinking about it more, this is probably the way to do it. Mapping the
same address twice appeared to worked for me, but it looks like it's a bad
thing to do. To bad I didn't have time to finish this.
Creating two copies of the flash chip will take twice the physical address
space, but the virtual address space used is the same as mapping the chip
twice. Since kernel virtual address space <= physical address space, there
really shouldn't be a problem with that.
Probably do something like this to the dts:
localbus {
- ranges = <0x1 0x0 0xe800 0x0800>;
+ ranges = <0x1 0x0 0xe000 0x1000>; /* CS size x2 */
- n...@1,0 {
+ n...@1,0x0800 {
compatible = "cfi-flash";
- reg = <0x1 0x0 0x0800>;
+ reg = <0x1 0x0800 0x0800>;
+ cached-alias = <&cached_nor>;
};
+ cached_nor: n...@1,0 {
+ compatible = "alias";
+ reg = <0x1 0 0x0800>;
+ };
}
Since physmap_of is an openfirmware driver, it won't be a problem to have
if look for "cached-alias" to get the range to map as cached. The MTD
layer only supports one "map->phys" address, but I don't think this address
is used for anything on powerpc.
>> Or changing the mapping for writes and then changing it back. It wouldn't
>> be necessary to change the whole thing, just the page being written to.
>
> Right though changing mappings can be expensive. It might be worth
> looking at using fixmap for that tho, which is the fastest way to setup
> and tear down mappings, especially since we can (though we don't today)
> implement a bypass on those to directly load the TLB.
The MTD layer appears to program flash one word at a time, so writing to
flash would mean changing maps on a per word basis. Of course flash is
slow too so maybe the relative cost is not that much. It takes more
modifications to MTD than the previous method.
> The problem gets worsened by the fact that cores that support
> speculative loads and prefetch will potentially bring anything mapped
> into the cache even if it's not directly accessed.
This is really the whole point of mapping it cached. Since the cpu can
prefetch data, it's able to use more efficient back-to-back reads or page
burst mode to read a whole cache line at once. The latter can more than
triple the read rate.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/5] powerpc/83xx: Add USB Host/Gadget support for MPC8360E-MDS boards
On Dec 3, 2008, at 1:27 PM, Anton Vorontsov wrote: - Update the device tree per QE USB bindings; - Add timer (FSL GTM) node; - Add gpio-controller node for BCSR13 bank (GPIOs on that bank are used to control the USB transceiver); - Set up other BCSR registers; - Configure the QE Par IO. Of these are they all in the kernel tree already? What I mean is QE usb bindings in linus's tree? I know GTM timers is and this patch series had the bcsr gpio. Similar question for qe par io. I think we are good but clearly I leave much of QE to you & timur. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 14/16] powerpc/mm: Runtime allocation of mmu context maps for nohash CPUs v2
/*
* Initialize the context management stuff.
@@ -326,13 +344,56 @@ void __init mmu_context_init(void)
init_mm.context.active = NR_CPUS;
/*
+ * The MPC8xx has only 16 contexts. We rotate through them on
each
+* task switch. A better way would be to keep track of tasks that
+* own contexts, and implement an LRU usage. That way very active
+* tasks don't always have to pay the TLB reload overhead. The
+* kernel pages are mapped shared, so the kernel can run on behalf
+* of any task that makes a kernel entry. Shared does not mean they
+ * are not protected, just that the ASID comparison is not
performed.
+* -- Dan
+*
+* The IBM4xx has 256 contexts, so we can just rotate through these
+* as a way of "switching" contexts. If the TID of the TLB is zero,
+* the PID/TID comparison is disabled, so we can use a TID of zero
+* to represent all kernel pages as shared among all contexts.
can expand the comment of change it to say all other nonhash parts
40x, 4xx, fsl-booke right now have 256 contexts.
+* -- Dan
+*/
+ if (mmu_has_feature(MMU_FTR_TYPE_8xx)) {
+ first_context = 0;
+ last_context = 15;
+ } else {
+ first_context = 1;
+ last_context = 255;
+ }
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 7/16] powerpc/mm: Rework context management for CPUs with no hash table v2
On Dec 14, 2008, at 11:44 PM, Benjamin Herrenschmidt wrote: This reworks the context management code used by 4xx,8xx and freescale BookE. It adds support for SMP by implementing a concept of stale context map to lazily flush the TLB on processors where a context may have been invalidated. This also contains the ground work for generalizing such lazy TLB flushing by just picking up a new PID and marking the old one stale. This will be implemented later. This is a first implementation that uses a global spinlock. Ideally, we should try to get at least the fast path (context ID already assigned) lockless or limited to a per context lock, but for now this will do. I tried to keep the UP case reasonably simple to avoid adding too much overhead to 8xx which does a lot of context stealing since it effectively has only 16 PIDs available. Signed-off-by: Benjamin Herrenschmidt --- v2. remove some bugs with active tracking on SMP I'd personally like a bit more commentary on how the stale map addresses the SMP issues in the commit message. Also, Paul had a comment that we've kept around related to 8xx/4xx SMP as well as LRU.. is that still relevant? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
"booke: Fix problem with _tlbil_va being interrupted" causes BUG()
I just pulled from Linus and the Kernel I booted gave me this: | Freeing unused kernel memory: 152k init | BUG: sleeping function called from invalid context at /home/bigeasy/git/linux-2.6-powerpc/fs/exec.c:417 | in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: swapper | Call Trace: | [ef831dd0] [c0007764] show_stack+0x48/0x154 (unreliable) | [ef831e00] [c002b4d0] __might_sleep+0x118/0x11c | [ef831e10] [c009bcfc] copy_strings+0x70/0x324 | [ef831e70] [c009bfd0] copy_strings_kernel+0x20/0x38 | [ef831e90] [c009d3b8] do_execve+0x15c/0x1ec | [ef831ec0] [c00084ac] sys_execve+0x58/0x84 | [ef831ee0] [c000f0e8] ret_from_syscall+0x0/0x3c | [ef831fa0] [c0001d68] init_post+0x54/0x174 | [ef831fc0] [c038a1c0] kernel_init+0xdc/0x104 | [ef831ff0] [c000ee68] kernel_thread+0x4c/0x68 | [ cut here ] It looks like userspace starts here. A bisect leads to |commit e5e774d8833de1a0037be2384efccadf16935675 |Author: Kumar Gala |Date: Sat Dec 13 17:01:37 2008 -0600 | |powerpc/fsl-booke: Fix problem with _tlbil_va being interrupted | |An example calling sequence which we did see: | |copy_user_highpage -> kmap_atomic -> flush_tlb_page -> _tlbil_va | |We got interrupted after setting up the MAS registers before the |tlbwe and the interrupt handler that caused the interrupt also did |a kmap_atomic (ide code) and thus on returning from the interrupt |the MAS registers no longer contained the proper values. | |Since we dont save/restore MAS registers for normal interrupts we |need to disable interrupts in _tlbil_va to ensure atomicity. | |Signed-off-by: Kumar Gala | |:04 04 1f298a8930bd2704f4481307f3d22589943bb5c0 7e3847dab748c332c8533111de32d23731ec778b M arch as the guilty commit. This box has highmem. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: "booke: Fix problem with _tlbil_va being interrupted" causes BUG()
On Dec 17, 2008, at 3:34 PM, Sebastian Andrzej Siewior wrote: I just pulled from Linus and the Kernel I booted gave me this: | Freeing unused kernel memory: 152k init | BUG: sleeping function called from invalid context at /home/ bigeasy/git/linux-2.6-powerpc/fs/exec.c:417 | in_atomic(): 0, irqs_disabled(): 1, pid: 1, name: swapper | Call Trace: | [ef831dd0] [c0007764] show_stack+0x48/0x154 (unreliable) | [ef831e00] [c002b4d0] __might_sleep+0x118/0x11c | [ef831e10] [c009bcfc] copy_strings+0x70/0x324 | [ef831e70] [c009bfd0] copy_strings_kernel+0x20/0x38 | [ef831e90] [c009d3b8] do_execve+0x15c/0x1ec | [ef831ec0] [c00084ac] sys_execve+0x58/0x84 | [ef831ee0] [c000f0e8] ret_from_syscall+0x0/0x3c | [ef831fa0] [c0001d68] init_post+0x54/0x174 | [ef831fc0] [c038a1c0] kernel_init+0xdc/0x104 | [ef831ff0] [c000ee68] kernel_thread+0x4c/0x68 | [ cut here ] It looks like userspace starts here. A bisect leads to |commit e5e774d8833de1a0037be2384efccadf16935675 |Author: Kumar Gala |Date: Sat Dec 13 17:01:37 2008 -0600 | |powerpc/fsl-booke: Fix problem with _tlbil_va being interrupted | |An example calling sequence which we did see: | |copy_user_highpage -> kmap_atomic -> flush_tlb_page -> _tlbil_va | |We got interrupted after setting up the MAS registers before the |tlbwe and the interrupt handler that caused the interrupt also did |a kmap_atomic (ide code) and thus on returning from the interrupt |the MAS registers no longer contained the proper values. | |Since we dont save/restore MAS registers for normal interrupts we |need to disable interrupts in _tlbil_va to ensure atomicity. | |Signed-off-by: Kumar Gala | |:04 04 1f298a8930bd2704f4481307f3d22589943bb5c0 7e3847dab748c332c8533111de32d23731ec778b M arch as the guilty commit. This box has highmem. Sebastian Dave Liu noticed something similar.. Feel free to send me a brown paper bag. Fixed in my 'merge' branch and just waiting for Paul or Linus to pick it up. http://ozlabs.org/pipermail/linuxppc-dev/2008-December/066352.html - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: "booke: Fix problem with _tlbil_va being interrupted" causes BUG()
* Kumar Gala | 2008-12-17 15:41:42 [-0600]: > Dave Liu noticed something similar.. Feel free to send me a brown paper > bag. :) > Fixed in my 'merge' branch and just waiting for Paul or Linus to pick it > up. > > http://ozlabs.org/pipermail/linuxppc-dev/2008-December/066352.html Thx. > - k Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add PPC/4xx "ibm,sdram-4xx-ddr2" EDAC MC Driver
This adds support for an EDAC memory controller adaptation driver for the "ibm,sdram-4xx-ddr2" ECC controller realized in the AMCC PowerPC 405EX[r]. Signed-off-by: Grant Erickson --- At present, this driver has been developed and tested against the controller realization in the AMCC PPC405EX[r] on the AMCC Kilauea and Haleakala boards (256 MiB w/o ECC memory soldered onto the board) and a proprietary board based on those designs (128 MiB ECC memory, also soldered onto the board). In the future, dynamic feature detection and handling needs to be added for the other realizations of this controller found in the 440SP, 440SPe, 460EX, 460GT and 460SX. Eventually, this driver will likely be evolved and adapted to the above variant realizations of this controller as well as broken apart to handle the other known ECC-capable controllers prevalent in other PPC4xx processors: - IBM SDRAM (405GP, 405CR and 405EP) "ibm,sdram-4xx" - IBM DDR1 (440GP, 440GX, 440EP and 440GR) "ibm,sdram-4xx-ddr" - Denali DDR1/DDR2 (440EPX and 440GRX) "denali,sdram-4xx-ddr2" drivers/edac/Kconfig |9 + drivers/edac/Makefile |2 +- drivers/edac/ppc4xx_edac.c | 1333 drivers/edac/ppc4xx_edac.h | 179 ++ 4 files changed, 1522 insertions(+), 1 deletions(-) diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig index e0dbd38..2690946 100644 --- a/drivers/edac/Kconfig +++ b/drivers/edac/Kconfig @@ -167,4 +167,13 @@ config EDAC_CELL Cell Broadband Engine internal memory controller on platform without a hypervisor +config EDAC_PPC4XX + tristate "PPC4xx IBM DDR2 Memory Controller" + depends on EDAC_MM_EDAC && 4xx + help + This enables support for EDAC on the ECC memory used + with the IBM DDR2 memory controller found in various + PowerPC 4xx embedded processors such as the 405EX[r], + 440SP, 440SPe, 460EX,460GT and 460SX. + endif # EDAC diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile index 62c2d9b..de8d4c1 100644 --- a/drivers/edac/Makefile +++ b/drivers/edac/Makefile @@ -33,4 +33,4 @@ obj-$(CONFIG_EDAC_PASEMI) += pasemi_edac.o obj-$(CONFIG_EDAC_MPC85XX) += mpc85xx_edac.o obj-$(CONFIG_EDAC_MV64X60) += mv64x60_edac.o obj-$(CONFIG_EDAC_CELL)+= cell_edac.o - +obj-$(CONFIG_EDAC_PPC4XX) += ppc4xx_edac.o diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c new file mode 100644 index 000..493c273 --- /dev/null +++ b/drivers/edac/ppc4xx_edac.c @@ -0,0 +1,1333 @@ +/* + * Copyright (c) 2008 Nuovation System Designs, LLC + * Grant Erickson + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; version 2 of the + * License. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "edac_core.h" +#include "ppc4xx_edac.h" + +/* + * This file implements a driver for monitoring and handling events + * associated with the IMB DDR2 ECC controller found in the AMCC/IBM + * 405EX[r], 440SP, 440SPe, 460EX, 460GT and 460SX. + * + * As realized in the 405EX[r], this controller features: + * + * - Support for registered- and non-registered DDR1 and DDR2 memory. + * - 32-bit or 16-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 4-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Two (2) memory banks/ranks. + * - Up to 1 GiB per bank/rank in 32-bit mode and up to 512 MiB per + * bank/rank in 16-bit mode. + * + * As realized in the 440SP and 440SPe, this controller changes/adds: + * + * - 64-bit or 32-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 8-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Up to 4 GiB per bank/rank in 64-bit mode and up to 2 GiB + * per bank/rank in 32-bit mode. + * + * As realized in the 460EX and 460GT, this controller changes/adds: + * + * - 64-bit or 32-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 8-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Four (4) memory banks/ranks. + * - Up to 16 GiB per bank/rank in 64-bit mode and up to 8 GiB + * per bank/rank in 32-bit mode. + * + * At present, this driver has ONLY been tested against the controller + * realization in the 405EX[r] on the AMCC Kilauea and Haleakala + * boards (256 MiB w/o ECC memory soldered onto the board) and a + * proprietary board based on those designs (128 MiB ECC memory, also + * soldered onto the board). + * + * Dynamic feature detection and handling needs to be added for the + * other realizations of this controller listed above. + * + * Ev
Re: Please pull from 'merge' for 2.6.28
Kumar Gala writes: > The following changes since commit 23e0e8afafd9ac065d81506524adf3339584044b: > Arnd Bergmann (1): > powerpc/cell/axon-msi: Fix MSI after kexec > > are available in the git repository at: > > master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge Linus, please pull Kumar's tree directly, since I have no other commits needing to go in 2.6.28 at this stage. Thanks, Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
On Wed, Dec 17, 2008 at 11:56:07AM -0800, Grant Erickson wrote:
> Added additional information for type and compatibility strings and
> interrupt information to the SDRAM0 memory-controller device tree
> nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
> with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver.
>
> Signed-off-by: Grant Erickson
> ---
> As support in the associated EDAC adapter driver is added over time,
> similar changes will/should be made to the DTS files for boards
> leveraging realizations of this "ibm,sdram-4xx-ddr2" controller,
> including the 440SP, 440SPe, 460EX, 460GT and 460SX.
>
> arch/powerpc/boot/dts/haleakala.dts | 11 ++-
> arch/powerpc/boot/dts/kilauea.dts | 11 ++-
> arch/powerpc/boot/dts/makalu.dts| 11 ++-
> 3 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/haleakala.dts
> b/arch/powerpc/boot/dts/haleakala.dts
> index 513bc43..e45ce7e 100644
> --- a/arch/powerpc/boot/dts/haleakala.dts
> +++ b/arch/powerpc/boot/dts/haleakala.dts
> @@ -89,8 +89,17 @@
> clock-frequency = <0>; /* Filled in by U-Boot */
>
> SDRAM0: memory-controller {
> - compatible = "ibm,sdram-405exr";
> + device_type = "memory-controller";
This should not have a device_type.
> + compatible = "ibm,sdram-405exr", "ibm,sdram-4xx-ddr2";
> dcr-reg = <0x010 0x002>;
> + #address-cells = <0>;
> + #size-cells = <0>;
This seems odd. These should only be present if the node does, or at
least can, have subnodes - I don't see that it would.
> + #interrupt-cells = <1>;
> + interrupt-parent = <&SDRAM0>;
> + interrupts = <0x0 0x1>;
> + interrupt-map = + /* ECCSEC Error */ 0x1 &UIC2 0x6 0x4>;
> + interrupt-map-mask = <0x>;
> };
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
On 12/17/08 3:46 PM, David Gibson wrote:
> On Wed, Dec 17, 2008 at 11:56:07AM -0800, Grant Erickson wrote:
>> Added additional information for type and compatibility strings and
>> interrupt information to the SDRAM0 memory-controller device tree
>> nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
>> with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver.
>>
>> Signed-off-by: Grant Erickson
>> ---
>> As support in the associated EDAC adapter driver is added over time,
>> similar changes will/should be made to the DTS files for boards
>> leveraging realizations of this "ibm,sdram-4xx-ddr2" controller,
>> including the 440SP, 440SPe, 460EX, 460GT and 460SX.
>>
>> arch/powerpc/boot/dts/haleakala.dts | 11 ++-
>> arch/powerpc/boot/dts/kilauea.dts | 11 ++-
>> arch/powerpc/boot/dts/makalu.dts| 11 ++-
>> 3 files changed, 30 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/boot/dts/haleakala.dts
>> b/arch/powerpc/boot/dts/haleakala.dts
>> index 513bc43..e45ce7e 100644
>> --- a/arch/powerpc/boot/dts/haleakala.dts
>> +++ b/arch/powerpc/boot/dts/haleakala.dts
>> @@ -89,8 +89,17 @@
>> clock-frequency = <0>; /* Filled in by U-Boot */
>>
>> SDRAM0: memory-controller {
>> - compatible = "ibm,sdram-405exr";
>> + device_type = "memory-controller";
>
> This should not have a device_type.
I'm still growing my device tree expertise. Can you elaborate on why SDRAM0
shouldn't be described generically as a "memory-controller" device in the
same way the EMAC0 is generically described as a "network" device? A URL to
said elaboration would be sufficient.
>> + compatible = "ibm,sdram-405exr", "ibm,sdram-4xx-ddr2";
>> dcr-reg = <0x010 0x002>;
>> + #address-cells = <0>;
>> + #size-cells = <0>;
>
> This seems odd. These should only be present if the node does, or at
> least can, have subnodes - I don't see that it would.
See above qualifier; will remove.
Thanks for the prompt review!
Regards,
Grant
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
On Wed, Dec 17, 2008 at 04:09:05PM -0800, Grant Erickson wrote:
> On 12/17/08 3:46 PM, David Gibson wrote:
> > On Wed, Dec 17, 2008 at 11:56:07AM -0800, Grant Erickson wrote:
> >> Added additional information for type and compatibility strings and
> >> interrupt information to the SDRAM0 memory-controller device tree
> >> nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
> >> with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver.
> >>
> >> Signed-off-by: Grant Erickson
> >> ---
> >> As support in the associated EDAC adapter driver is added over time,
> >> similar changes will/should be made to the DTS files for boards
> >> leveraging realizations of this "ibm,sdram-4xx-ddr2" controller,
> >> including the 440SP, 440SPe, 460EX, 460GT and 460SX.
> >>
> >> arch/powerpc/boot/dts/haleakala.dts | 11 ++-
> >> arch/powerpc/boot/dts/kilauea.dts | 11 ++-
> >> arch/powerpc/boot/dts/makalu.dts| 11 ++-
> >> 3 files changed, 30 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/powerpc/boot/dts/haleakala.dts
> >> b/arch/powerpc/boot/dts/haleakala.dts
> >> index 513bc43..e45ce7e 100644
> >> --- a/arch/powerpc/boot/dts/haleakala.dts
> >> +++ b/arch/powerpc/boot/dts/haleakala.dts
> >> @@ -89,8 +89,17 @@
> >> clock-frequency = <0>; /* Filled in by U-Boot */
> >>
> >> SDRAM0: memory-controller {
> >> - compatible = "ibm,sdram-405exr";
> >> + device_type = "memory-controller";
> >
> > This should not have a device_type.
>
> I'm still growing my device tree expertise. Can you elaborate on why SDRAM0
> shouldn't be described generically as a "memory-controller" device in the
> same way the EMAC0 is generically described as a "network" device? A URL to
> said elaboration would be sufficient.
Because "device_type" isn't just a generic description of the device.
"device_type" is used in actual OF implementations to specify what OF
method interface the device supports. Since with a flattened tree
there is no method interface, device_type is not appropriate. For
long-established device_type values, like "network" we keep it in
because there's software that expects to see it, but unless there is a
defined and supported OF method interface binding, device_type should
not be added for anything new.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
Added additional information for type and compatibility strings and
interrupt information to the SDRAM0 memory-controller device tree
nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver.
Signed-off-by: Grant Erickson
---
As support in the associated EDAC adapter driver is added over time,
similar changes will/should be made to the DTS files for boards
leveraging realizations of this "ibm,sdram-4xx-ddr2" controller,
including the 440SP, 440SPe, 460EX, 460GT and 460SX.
Patch v2, based on review from David Gibson, removes the 'device_type'
field because it is only used for legacy OpenFirmware method
interfaces and no such compatibility is warranted here. In addition,
removed address- and size-cells as this node has no children.
arch/powerpc/boot/dts/haleakala.dts |8 +-
arch/powerpc/boot/dts/kilauea.dts |8 +-
arch/powerpc/boot/dts/makalu.dts|8 +-
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/haleakala.dts
b/arch/powerpc/boot/dts/haleakala.dts
index 513bc43..64880ab 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -89,8 +89,14 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405exr";
+ compatible = "ibm,sdram-405exr", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&SDRAM0>;
+ interrupts = <0x0 0x1>;
+ interrupt-map = ;
+ interrupt-map-mask = <0x>;
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index dececc4..bc32b60 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -90,8 +90,14 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405ex";
+ compatible = "ibm,sdram-405ex", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&SDRAM0>;
+ interrupts = <0x0 0x1>;
+ interrupt-map = ;
+ interrupt-map-mask = <0x>;
};
MAL0: mcmal {
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index 945508c..472d22d 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -90,8 +90,14 @@
clock-frequency = <0>; /* Filled in by U-Boot */
SDRAM0: memory-controller {
- compatible = "ibm,sdram-405ex";
+ compatible = "ibm,sdram-405ex", "ibm,sdram-4xx-ddr2";
dcr-reg = <0x010 0x002>;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&SDRAM0>;
+ interrupts = <0x0 0x1>;
+ interrupt-map = ;
+ interrupt-map-mask = <0x>;
};
MAL0: mcmal {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] Add PPC/4xx "ibm,sdram-4xx-ddr2" EDAC MC Driver
This adds support for an EDAC memory controller adaptation driver for the "ibm,sdram-4xx-ddr2" ECC controller realized in the AMCC PowerPC 405EX[r]. Signed-off-by: Grant Erickson --- At present, this driver has been developed and tested against the controller realization in the AMCC PPC405EX[r] on the AMCC Kilauea and Haleakala boards (256 MiB w/o ECC memory soldered onto the board) and a proprietary board based on those designs (128 MiB ECC memory, also soldered onto the board). In the future, dynamic feature detection and handling needs to be added for the other realizations of this controller found in the 440SP, 440SPe, 460EX, 460GT and 460SX. Eventually, this driver will likely be evolved and adapted to the above variant realizations of this controller as well as broken apart to handle the other known ECC-capable controllers prevalent in other PPC4xx processors: - IBM SDRAM (405GP, 405CR and 405EP) "ibm,sdram-4xx" - IBM DDR1 (440GP, 440GX, 440EP and 440GR) "ibm,sdram-4xx-ddr" - Denali DDR1/DDR2 (440EPX and 440GRX) "denali,sdram-4xx-ddr2" Patch v2 removes the 'type' field from the of_device_id match structure to reflect the corresponding removal of the 'device_type' field from the device tree node. drivers/edac/Kconfig|9 + drivers/edac/Makefile |2 +- drivers/edac/ppc4xx_edac.c | 1332 +++ drivers/edac/ppc4xx_edac.h | 179 + 4 files changed, 1521 insertions(+), 1 deletions(-) diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig index e0dbd38..ae950d7 100644 --- a/drivers/edac/Kconfig +++ b/drivers/edac/Kconfig @@ -167,4 +167,13 @@ config EDAC_CELL Cell Broadband Engine internal memory controller on platform without a hypervisor +config EDAC_PPC4XX + tristate "PPC4xx IBM DDR2 Memory Controller" + depends on EDAC_MM_EDAC && 4xx + help + This enables support for EDAC on the ECC memory used + with the IBM DDR2 memory controller found in various + PowerPC 4xx embedded processors such as the 405EX[r], + 440SP, 440SPe, 460EX, 460GT and 460SX. + endif # EDAC diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile index 62c2d9b..de8d4c1 100644 --- a/drivers/edac/Makefile +++ b/drivers/edac/Makefile @@ -33,4 +33,4 @@ obj-$(CONFIG_EDAC_PASEMI) += pasemi_edac.o obj-$(CONFIG_EDAC_MPC85XX) += mpc85xx_edac.o obj-$(CONFIG_EDAC_MV64X60) += mv64x60_edac.o obj-$(CONFIG_EDAC_CELL)+= cell_edac.o - +obj-$(CONFIG_EDAC_PPC4XX) += ppc4xx_edac.o diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c new file mode 100644 index 000..5caadc6 --- /dev/null +++ b/drivers/edac/ppc4xx_edac.c @@ -0,0 +1,1332 @@ +/* + * Copyright (c) 2008 Nuovation System Designs, LLC + * Grant Erickson + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; version 2 of the + * License. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "edac_core.h" +#include "ppc4xx_edac.h" + +/* + * This file implements a driver for monitoring and handling events + * associated with the IMB DDR2 ECC controller found in the AMCC/IBM + * 405EX[r], 440SP, 440SPe, 460EX, 460GT and 460SX. + * + * As realized in the 405EX[r], this controller features: + * + * - Support for registered- and non-registered DDR1 and DDR2 memory. + * - 32-bit or 16-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 4-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Two (2) memory banks/ranks. + * - Up to 1 GiB per bank/rank in 32-bit mode and up to 512 MiB per + * bank/rank in 16-bit mode. + * + * As realized in the 440SP and 440SPe, this controller changes/adds: + * + * - 64-bit or 32-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 8-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Up to 4 GiB per bank/rank in 64-bit mode and up to 2 GiB + * per bank/rank in 32-bit mode. + * + * As realized in the 460EX and 460GT, this controller changes/adds: + * + * - 64-bit or 32-bit memory interface with optional ECC. + * + * o ECC support includes: + * + * - 8-bit SEC/DED + * - Aligned-nibble error detect + * - Bypass mode + * + * - Four (4) memory banks/ranks. + * - Up to 16 GiB per bank/rank in 64-bit mode and up to 8 GiB + * per bank/rank in 32-bit mode. + * + * At present, this driver has ONLY been tested against the controller + * realization in the 405EX[r] on the AMCC Kilauea and Haleakala + * boards (256 MiB w/o ECC memory soldered onto the board) and a + * proprietary board based on those designs (128
Re: [PATCH v2] powerpc/4xx: DTS: Add Add'l SDRAM0 Compatible and Interrupt Info
On Wed, Dec 17, 2008 at 05:31:40PM -0800, Grant Erickson wrote: > Added additional information for type and compatibility strings and > interrupt information to the SDRAM0 memory-controller device tree > nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding > with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver. > > Signed-off-by: Grant Erickson Acked-by: David Gibson -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v1] Add support for getting device platform data to I2C device
There is no standard way of getting device platform data from
dts file to the I2C device when it's probed. This patch adds
a function pointer to the of_modalias_table to get such bindings
properties into device's platform data.
Signed-off-by: Mingkai Hu
---
Thanks to Scott Wood's suggestions.
drivers/of/base.c |9 -
drivers/of/of_i2c.c |3 ++-
drivers/of/of_spi.c |2 +-
include/linux/of.h |3 ++-
4 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ad8ac1a..38ab2a2 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -408,6 +408,7 @@ EXPORT_SYMBOL(of_find_matching_node);
struct of_modalias_table {
char *of_device;
char *modalias;
+ const void *(*binder)(struct device_node *node);
};
static struct of_modalias_table of_modalias_table[] = {
/* Empty for now; add entries as needed */
@@ -418,6 +419,7 @@ static struct of_modalias_table of_modalias_table[] = {
* @node: pointer to a device tree node
* @modalias: Pointer to buffer that modalias value will be copied into
* @len: Length of modalias value
+ * @platform_data: pointer to device's platform specific data
*
* Based on the value of the compatible property, this routine will determine
* an appropriate modalias value for a particular device tree node. Three
@@ -430,7 +432,8 @@ static struct of_modalias_table of_modalias_table[] = {
*
* This routine returns 0 on success
*/
-int of_modalias_node(struct device_node *node, char *modalias, int len)
+int of_modalias_node(struct device_node *node, char *modalias, int len,
+ const void **platform_data)
{
int i, cplen;
const char *compatible;
@@ -442,6 +445,10 @@ int of_modalias_node(struct device_node *node, char
*modalias, int len)
if (!of_device_is_compatible(node, compatible))
continue;
strlcpy(modalias, of_modalias_table[i].modalias, len);
+
+ if (platform_data && of_modalias_table[i].binder)
+ *platform_data = of_modalias_table[i].binder(node);
+
return 0;
}
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index 6a98dc8..38d9faf 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -27,7 +27,8 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
const u32 *addr;
int len;
- if (of_modalias_node(node, info.type, sizeof(info.type)) < 0)
+ if (of_modalias_node(node, info.type, sizeof(info.type),
+ (const void **)&info.platform_data) < 0)
continue;
addr = of_get_property(node, "reg", &len);
diff --git a/drivers/of/of_spi.c b/drivers/of/of_spi.c
index b01eec0..0dcd52c 100644
--- a/drivers/of/of_spi.c
+++ b/drivers/of/of_spi.c
@@ -39,7 +39,7 @@ void of_register_spi_devices(struct spi_master *master,
struct device_node *np)
/* Select device driver */
if (of_modalias_node(nc, spi->modalias,
-sizeof(spi->modalias)) < 0) {
+sizeof(spi->modalias), NULL) < 0) {
dev_err(&master->dev, "cannot find modalias for %s\n",
nc->full_name);
spi_dev_put(spi);
diff --git a/include/linux/of.h b/include/linux/of.h
index 79886ad..ed4c269 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -70,6 +70,7 @@ extern int of_n_addr_cells(struct device_node *np);
extern int of_n_size_cells(struct device_node *np);
extern const struct of_device_id *of_match_node(
const struct of_device_id *matches, const struct device_node *node);
-extern int of_modalias_node(struct device_node *node, char *modalias, int len);
+extern int of_modalias_node(struct device_node *node, char *modalias, int len,
+ const void **platform_data);
#endif /* _LINUX_OF_H */
--
1.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][v2] fork_init: fix division by zero
Hello Paul,
On Friday 12 December 2008 03:48, Paul Mackerras wrote:
> Andrew Morton writes:
>
> > > +#if (8 * THREAD_SIZE) > PAGE_SIZE
> > > max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
> > > +#else
> > > + max_threads = mempages * (PAGE_SIZE / (8 * THREAD_SIZE));
> > > +#endif
> >
> > The expression you've chosen here can be quite inacccurate, because
> > ((PAGE_SIZE / (8 * THREAD_SIZE)) is a small number. The way to
> > preserve accuracy is
>
> The assumption is that THREAD_SIZE is a power of 2, as is PAGE_SIZE.
>
> I think Yuri should be increasing THREAD_SIZE for the larger page
> sizes he's implementing, because we have on-stack arrays whose size
> depends on the page size. I suspect that having THREAD_SIZE less than
> 1/8 of PAGE_SIZE risks stack overflows, and the better fix is for Yuri
> to make sure THREAD_SIZE is at least 1/8 of PAGE_SIZE. (In fact, more
> may be needed - someone should work out what fraction is actually
> needed.)
Right, thanks for pointing this. I guess, I was just lucky since didn't run
into
problems with stack overflows. So, I agree that we should increase the
THREAD_SIZE in case of 256KB pages up to 1/8 of PAGE_SIZE, that is up
to 32KB.
There is one more warning from the common code when I use 256KB pages:
CC mm/shmem.o
mm/shmem.c: In function 'shmem_truncate_range':
mm/shmem.c:613: warning: division by zero
mm/shmem.c:619: warning: division by zero
mm/shmem.c:644: warning: division by zero
mm/shmem.c: In function 'shmem_unuse_inode':
mm/shmem.c:873: warning: division by zero
The problem here is that ENTRIES_PER_PAGEPAGE becomes 0x1..
when PAGE_SIZE is 256K.
How about the following fix ?
diff --git a/mm/shmem.c b/mm/shmem.c
index 0ed0752..99d7c91 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -57,7 +57,7 @@
#include
#define ENTRIES_PER_PAGE (PAGE_CACHE_SIZE/sizeof(unsigned long))
-#define ENTRIES_PER_PAGEPAGE (ENTRIES_PER_PAGE*ENTRIES_PER_PAGE)
+#define ENTRIES_PER_PAGEPAGE ((unsigned long
long)ENTRIES_PER_PAGE*ENTRIES_PER_PAGE)
#define BLOCKS_PER_PAGE (PAGE_CACHE_SIZE/512)
#define SHMEM_MAX_INDEX (SHMEM_NR_DIRECT + (ENTRIES_PER_PAGEPAGE/2) *
(ENTRIES_PER_PAGE+1))
@@ -95,7 +95,7 @@ static unsigned long shmem_default_max_inodes(void)
}
#endif
-static int shmem_getpage(struct inode *inode, unsigned long idx,
+static int shmem_getpage(struct inode *inode, unsigned long long idx,
struct page **pagep, enum sgp_type sgp, int *type);
static inline struct page *shmem_dir_alloc(gfp_t gfp_mask)
@@ -533,7 +533,7 @@ static void shmem_truncate_range(struct inode *inode,
loff_t start, loff_t end)
int punch_hole;
spinlock_t *needs_lock;
spinlock_t *punch_lock;
- unsigned long upper_limit;
+ unsigned long long upper_limit;
inode->i_ctime = inode->i_mtime = CURRENT_TIME;
idx = (start + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
@@ -1175,7 +1175,7 @@ static inline struct mempolicy *shmem_get_sbmpol(struct
shmem_sb_info *sbinfo)
* vm. If we swap it in we mark it dirty since we also free the swap
* entry since a page cannot live in both the swap and page cache
*/
-static int shmem_getpage(struct inode *inode, unsigned long idx,
+static int shmem_getpage(struct inode *inode, unsigned long long idx,
struct page **pagep, enum sgp_type sgp, int *type)
{
struct address_space *mapping = inode->i_mapping;
Regards, Yuri
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
