Re: Compact Flash on 8349mITX
Jeff Borlin wrote: Anton Vorontsov-2 wrote: This happens just before the PATA information is printed. I'm not libata expert; and from the brief look I don't see where libata clears any pending "unexpected" irqs. Just a guesswork, could you try this patch? This patch did not appear to change anything. Without this patch, you can't use it without irq. Anton Vorontsov-2 wrote: Can you check if the CF will work w/o IRQs? To try it: Your directions did result in progress: [...] scsi4 : pata_platform ata5: PATA max PIO6 no IRQ, using PIO polling mmio cmd 0xf000 ctl 0xf20c ata5.00: CFA: SanDisk SDCFJ-512, HDX 3.13, max MWDMA2 ata5.00: 1000944 sectors, multi 0: LBA ata5.00: configured for PIO scsi 4:0:0:0: Direct-Access ATA SanDisk SDCFJ-51 HDX PQ: 0 ANSI: 5 sd 4:0:0:0: [sda] 1000944 512-byte hardware sectors (512 MB) sd 4:0:0:0: [sda] Write Protect is off sd 4:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sd 4:0:0:0: [sda] 1000944 512-byte hardware sectors (512 MB) sd 4:0:0:0: [sda] Write Protect is off sd 4:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 4:0:0:0: [sda] Attached SCSI removable disk sd 4:0:0:0: Attached scsi generic sg0 type 0 physmap platform flash device: 0100 at fe00 [...] / # dd if=/dev/sda of=/dev/null count=2 2+0 records in 2+0 records out / # mount -t vfat /dev/sda /mnt/cf mount: Mounting /dev/sda on /mnt/cf failed: Invalid argument / # mount -t vfat /dev/sda2 /mnt/cf mount: Mounting /dev/sda2 on /mnt/cf failed: Invalid argument I still need to figure out what I may be doing wrong here, but wanted to post the results I have so far in case they are useful. The CF card seems to work fine. See if your kernel supports vfat by # cat /proc/filesystems Of course, you need to mount /proc properly first. If your kernel doesn't support vfat, make it support. Or you can insert a blank CF card and play with it (ext2, etc) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] remove bogus ppc_select syscall
Arnd Bergmann writes: > Well, the point I made earlier ist that the native ppc32 path should > behave the same way as the compat ppc32 path. If we keep ppc_select > in one way or another, we should also have a compat wrapper for that, > right? No - we have other old system calls that don't exist at all on a 64-bit kernel but do on a 32-bit kernel. We decided a long time ago that there was no point supporting really ancient 32-bit userland code on a 64-bit kernel. That doesn't mean we need to rip out the support from the 32-bit kernel. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] remove bogus ppc_select syscall
Benjamin Herrenschmidt writes: > On Wed, 2008-09-24 at 08:39 +0200, Arnd Bergmann wrote: > > The ppc_select function was introduced in linux-2.3.48 in order to support > > code confusing the legacy select() calling convention with the standard one. > > Even 11 years ago, all correctly built code should not have done this and > > could have easily been phased out. Nothing that was compiled later should > > actually try to use the old_select interface, and it would have been broken > > already on all ppc64 kernels with the syscall emulation layer. > > > > This patch brings the 32 bit compat ABI and the native 32 bit ABI for > > powerpc into a consistent state, by removing support for both the > > old_select system call number and the handler for it. > > .../... > > It's me or the patch is whitespaces damaged ? Please don't apply Arnd's patch. As I said, all we need is this one-line change in arch/powerpc/include/asm/systbl.h: -SYSX_SPU(sys_select,ppc32_select,ppc_select) +SYSX_SPU(sys_select,ppc32_select,sys_select) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] remove bogus ppc_select syscall
On Friday 10 October 2008, Paul Mackerras wrote: > Arnd Bergmann writes: > > > Well, the point I made earlier ist that the native ppc32 path should > > behave the same way as the compat ppc32 path. If we keep ppc_select > > in one way or another, we should also have a compat wrapper for that, > > right? > > No - we have other old system calls that don't exist at all on a > 64-bit kernel but do on a 32-bit kernel. We decided a long time ago > that there was no point supporting really ancient 32-bit userland code > on a 64-bit kernel. That doesn't mean we need to rip out the support > from the 32-bit kernel. Ok, that makes sense, thanks for the clarification. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 11:00:09AM +0200, Geert Uytterhoeven wrote: > On Thu, 9 Oct 2008, Bill Gatliff wrote: > > Benjamin Herrenschmidt wrote: > > > On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote: > > >> This series proposes a "generic PWM" driver API. > > >> > > >> This proposed API is motivated by the author's need to support > > >> pluggable devices; a secondary objective is to consolidate the > > >> existing PWM implementations behind an agreeable, consistent, > > >> redundancy-reducing interface. > > > > > > .../... > > > > > > You should send your patches to the main linux kernel list ! > > > > Perhaps. But it seemed more relevant to this crowd, and the linux-embedded > > crowd, and the linux-arm-kernel crowd. > > Were did you actually sent them to? Apparently you sent them to each mailing > list (at least linux-embedded and linuxppc-dev) _separately_ (or using bcc). > > Hence different people may give the same comments without knowing about each > other, and you may have to explain everything multiple times. > > I would go for lkml and linux-embedded, _together_. > This is likely because some of those lists are subscribers only, so cross posting is poor form. It makes sense to keep the discussion in one place, and to send notification messages with a pointer to the list archives to the other lists so folks can jump in if they really care. Splitting it out doesn't help matters in the least, but unfortunately this is what seems to happen the most when subscribers only lists are involved. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Compact Flash on 8349mITX
On Fri, Oct 10, 2008 at 03:26:00PM +0800, Wang Jian wrote: > Jeff Borlin wrote: >> >> Anton Vorontsov-2 wrote: >>> This happens just before the PATA information is printed. I'm not >>> libata expert; and from the brief look I don't see where libata >>> clears any pending "unexpected" irqs. Just a guesswork, >>> could you try this patch? >>> >> This patch did not appear to change anything. > > Without this patch, you can't use it without irq. I purposed two patches to Jeff: one is + ioread8(ap->ioaddr.status_addr); I.e. clear an interrupt before requesting (just to be sure, I guess libata is doing this already, just don't see where exactly). That didn't work. :-/ And another approach was to try IRQ-less pata (another patch). -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/16] xics: change arg type to remove casts
The xirr is 32 bits in hardware, but the hypervisor requries the upper
bits of the register to be clear on the hcall. By changing the type
from signed to unsigned int we can drop masking it back to 32 bits.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Index: next.git/arch/powerpc/platforms/pseries/xics.c
===
--- next.git.orig/arch/powerpc/platforms/pseries/xics.c 2008-10-04
06:07:00.0 -0500
+++ next.git/arch/powerpc/platforms/pseries/xics.c 2008-10-04
06:13:40.0 -0500
@@ -87,7 +87,7 @@ static inline unsigned int direct_xirr_i
return in_be32(&xics_per_cpu[cpu]->xirr.word);
}
-static inline void direct_xirr_info_set(int value)
+static inline void direct_xirr_info_set(unsigned int value)
{
int cpu = smp_processor_id();
@@ -120,15 +120,14 @@ static inline unsigned int lpar_xirr_inf
return (unsigned int)return_value;
}
-static inline void lpar_xirr_info_set(int value)
+static inline void lpar_xirr_info_set(unsigned int value)
{
unsigned long lpar_rc;
- unsigned long val64 = value & 0x;
- lpar_rc = plpar_eoi(val64);
+ lpar_rc = plpar_eoi(value);
if (lpar_rc != H_SUCCESS)
- panic("bad return code EOI - rc = %ld, value=%lx\n", lpar_rc,
- val64);
+ panic("bad return code EOI - rc = %ld, value=%x\n", lpar_rc,
+ value);
}
static inline void lpar_cppr_info(u8 value)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 8/16] xics: factor out giq set and unset
There is a bit of math to calculate the arguments to rtas to join
or leave the global interrupt queue, and a warning on failure
afterwards. Make a helper for the 3 callers.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Index: next.git/arch/powerpc/platforms/pseries/xics.c
===
--- next.git.orig/arch/powerpc/platforms/pseries/xics.c 2008-10-04
17:40:00.0 -0500
+++ next.git/arch/powerpc/platforms/pseries/xics.c 2008-10-04
17:42:53.0 -0500
@@ -727,20 +727,19 @@ static void xics_set_cpu_priority(unsign
iosync();
}
+/* Have the calling processor join or leave the specified global queue */
+static void xics_set_cpu_giq(unsigned int gserver, unsigned int join)
+{
+ int status = rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
+ (1UL << interrupt_server_size) - 1 - gserver, join);
+ WARN_ON(status < 0);
+}
void xics_setup_cpu(void)
{
xics_set_cpu_priority(0xff);
- /*
-* Put the calling processor into the GIQ. This is really only
-* necessary from a secondary thread as the OF start-cpu interface
-* performs this function for us on primary threads.
-*
-* XXX: undo of teardown on kexec needs this too, as may hotplug
-*/
- rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
- (1UL << interrupt_server_size) - 1 - default_distrib_server, 1);
+ xics_set_cpu_giq(default_distrib_server, 1);
}
void xics_teardown_cpu(void)
@@ -749,9 +748,7 @@ void xics_teardown_cpu(void)
xics_set_cpu_priority(0);
- /*
-* Clear IPI
-*/
+ /* Clear any pending IPI request */
if (firmware_has_feature(FW_FEATURE_LPAR))
lpar_qirr_info(cpu, 0xff);
else
@@ -785,9 +782,7 @@ void xics_kexec_teardown_cpu(int seconda
* so leave the master cpu in the group.
*/
if (secondary)
- rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
- (1UL << interrupt_server_size) - 1 -
- default_distrib_server, 0);
+ xics_set_cpu_giq(default_distrib_server, 0);
}
#ifdef CONFIG_HOTPLUG_CPU
@@ -795,7 +790,6 @@ void xics_kexec_teardown_cpu(int seconda
/* Interrupts are disabled. */
void xics_migrate_irqs_away(void)
{
- int status;
int cpu = smp_processor_id(), hw_cpu = hard_smp_processor_id();
unsigned int irq, virq;
@@ -806,10 +800,8 @@ void xics_migrate_irqs_away(void)
/* Reject any interrupt that was queued to us... */
xics_set_cpu_priority(0);
- /* remove ourselves from the global interrupt queue */
- status = rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
- (1UL << interrupt_server_size) - 1 - default_distrib_server, 0);
- WARN_ON(status < 0);
+ /* Remove ourselves from the global interrupt queue */
+ xics_set_cpu_giq(default_distrib_server, 0);
/* Allow IPIs again... */
xics_set_cpu_priority(DEFAULT_PRIORITY);
@@ -817,6 +809,7 @@ void xics_migrate_irqs_away(void)
for_each_irq(virq) {
struct irq_desc *desc;
int xics_status[2];
+ int status;
unsigned long flags;
/* We cant set affinity on ISA interrupts */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 13/16] powerpc smp: no need to set_need_resched in resched ipi
The code was asking "Do we have to do this?", and according to x86 and s390 the answer is no, the scheduler will do it before calling the arch hook. Signed-off-by: Milton Miller <[EMAIL PROTECTED]> Index: next.git/arch/powerpc/kernel/smp.c === --- next.git.orig/arch/powerpc/kernel/smp.c 2008-10-04 22:09:36.0 -0500 +++ next.git/arch/powerpc/kernel/smp.c 2008-10-04 22:12:32.0 -0500 @@ -101,8 +101,7 @@ void smp_message_recv(int msg) generic_smp_call_function_interrupt(); break; case PPC_MSG_RESCHEDULE: - /* XXX Do we have to do this? */ - set_need_resched(); + /* we notice need_resched on exit */ break; case PPC_MSG_CALL_FUNC_SINGLE: generic_smp_call_function_single_interrupt(); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 14/16] powerpc mpic: use smp_request_message_ipi
mpic has 4 ipis so use the new smp_request_message_ipi to reduce
pathlength when reciving an ipi.
This has the side effect of using the common ipi names, and also
continuing to try request the remaining messages when one fails.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Index: next.git/arch/powerpc/sysdev/mpic.c
===
--- next.git.orig/arch/powerpc/sysdev/mpic.c2008-10-05 00:20:41.0
-0500
+++ next.git/arch/powerpc/sysdev/mpic.c 2008-10-05 00:21:41.0 -0500
@@ -616,17 +616,6 @@ static inline void mpic_eoi(struct mpic
(void)mpic_cpu_read(MPIC_INFO(CPU_WHOAMI));
}
-#ifdef CONFIG_SMP
-static irqreturn_t mpic_ipi_action(int irq, void *data)
-{
- long ipi = (long)data;
-
- smp_message_recv(ipi);
-
- return IRQ_HANDLED;
-}
-#endif /* CONFIG_SMP */
-
/*
* Linux descriptor level callbacks
*/
@@ -1492,13 +1481,7 @@ unsigned int mpic_get_mcirq(void)
void mpic_request_ipis(void)
{
struct mpic *mpic = mpic_primary;
- long i, err;
- static char *ipi_names[] = {
- "IPI0 (call function)",
- "IPI1 (reschedule)",
- "IPI2 (call function single)",
- "IPI3 (debugger break)",
- };
+ int i;
BUG_ON(mpic == NULL);
printk(KERN_INFO "mpic: requesting IPIs ... \n");
@@ -1507,17 +1490,10 @@ void mpic_request_ipis(void)
unsigned int vipi = irq_create_mapping(mpic->irqhost,
mpic->ipi_vecs[0] + i);
if (vipi == NO_IRQ) {
- printk(KERN_ERR "Failed to map IPI %ld\n", i);
- break;
- }
- err = request_irq(vipi, mpic_ipi_action,
- IRQF_DISABLED|IRQF_PERCPU,
- ipi_names[i], (void *)i);
- if (err) {
- printk(KERN_ERR "Request of irq %d for IPI %ld
failed\n",
- vipi, i);
- break;
+ printk(KERN_ERR "Failed to map %s\n", smp_ipi_name[i]);
+ continue;
}
+ smp_request_message_ipi(vipi, i);
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/5] AMCC PowerPC 405EZ Acadia eval board port
This is the latest set of Acadia patches I have. If there are no major objections to these, I intend to put them in my next branch for 2.6.28 josh Josh Boyer (5): powerpc/40x: AMCC PowerPC 405EZ Acadia DTS powerpc/40x: Add support for PowerPC 405EZ Acadia board powerpc/40x: Add AMCC PowerPC 405EZ to cputable powerpc/40x: Add cuboot wrapper for Acadia board powerpc/40x: Add PowerPC 405EZ Acadia defconfig arch/powerpc/boot/Makefile|4 +- arch/powerpc/boot/cuboot-acadia.c | 174 ++ arch/powerpc/boot/dts/acadia.dts | 224 +++ arch/powerpc/configs/40x/acadia_defconfig | 917 + arch/powerpc/kernel/cputable.c| 13 + arch/powerpc/platforms/40x/Kconfig| 14 + arch/powerpc/platforms/40x/Makefile |1 + arch/powerpc/platforms/40x/acadia.c | 56 ++ 8 files changed, 1402 insertions(+), 1 deletions(-) create mode 100644 arch/powerpc/boot/cuboot-acadia.c create mode 100644 arch/powerpc/boot/dts/acadia.dts create mode 100644 arch/powerpc/configs/40x/acadia_defconfig create mode 100644 arch/powerpc/platforms/40x/acadia.c ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/5] powerpc/40x: AMCC PowerPC 405EZ Acadia DTS
Add the DTS for the AMCC PowerPC 405EZ Acadia evaluation board
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/acadia.dts | 224 ++
1 files changed, 224 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/acadia.dts
diff --git a/arch/powerpc/boot/dts/acadia.dts b/arch/powerpc/boot/dts/acadia.dts
new file mode 100644
index 000..57291f6
--- /dev/null
+++ b/arch/powerpc/boot/dts/acadia.dts
@@ -0,0 +1,224 @@
+/*
+ * Device Tree Source for AMCC Acadia (405EZ)
+ *
+ * Copyright IBM Corp. 2008
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "amcc,acadia";
+ compatible = "amcc,acadia";
+ dcr-parent = <&{/cpus/[EMAIL PROTECTED]>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ [EMAIL PROTECTED] {
+ device_type = "cpu";
+ model = "PowerPC,405EZ";
+ reg = <0x0>;
+ clock-frequency = <0>; /* Filled in by wrapper */
+ timebase-frequency = <0>; /* Filled in by wrapper */
+ i-cache-line-size = <32>;
+ d-cache-line-size = <32>;
+ i-cache-size = <16384>;
+ d-cache-size = <16384>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x0>; /* Filled in by wrapper */
+ };
+
+ UIC0: interrupt-controller {
+ compatible = "ibm,uic-405ez", "ibm,uic";
+ interrupt-controller;
+ dcr-reg = <0x0c0 0x009>;
+ cell-index = <0>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ plb {
+ compatible = "ibm,plb-405ez", "ibm,plb3";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by wrapper */
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-405ez", "ibm,mcmal";
+ dcr-reg = <0x380 0x62>;
+ num-tx-chans = <1>;
+ num-rx-chans = <1>;
+ interrupt-parent = <&UIC0>;
+ /* 405EZ has only 3 interrupts to the UIC, as
+* SERR, TXDE, and RXDE are or'd together into
+* one UIC bit
+*/
+ interrupts = <
+ 0x13 0x4 /* TXEOB */
+ 0x15 0x4 /* RXEOB */
+ 0x12 0x4 /* SERR, TXDE, RXDE */>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-405ez", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ dcr-reg = <0x0a 0x05>;
+ clock-frequency = <0>; /* Filled in by wrapper */
+
+ UART0: [EMAIL PROTECTED] {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0xef600300 0x8>;
+ virtual-reg = <0xef600300>;
+ clock-frequency = <0>; /* Filled in by wrapper
*/
+ current-speed = <115200>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x5 0x4>;
+ };
+
+ UART1: [EMAIL PROTECTED] {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0xef600400 0x8>;
+ clock-frequency = <0>; /* Filled in by wrapper
*/
+ current-speed = <115200>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0x6 0x4>;
+ };
+
+ IIC: [EMAIL PROTECTED] {
+ compatible = "ibm,iic-405ez", "ibm,iic";
+ reg = <0xef600500 0x11>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0xa 0x4>;
+ };
+
[PATCH 4/5] powerpc/40x: Add cuboot wrapper for Acadia board
This adds a cuboot wrapper for the AMCC PowerPC 405EZ Acadia board. The
clocking code is derived from U-Boot, originally written by Stefan Roese.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/Makefile|4 +-
arch/powerpc/boot/cuboot-acadia.c | 174 +
2 files changed, 177 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/cuboot-acadia.c
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 6403275..5f4a59c 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -68,7 +68,8 @@ src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c
cuboot-85xx.c holly.c
fixed-head.S ep88xc.c ep405.c cuboot-c2k.c \
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c
\
- virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c
+ virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c \
+ cuboot-acadia.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -211,6 +212,7 @@ image-$(CONFIG_DEFAULT_UIMAGE) += uImage
# Board ports in arch/powerpc/platform/40x/Kconfig
image-$(CONFIG_EP405) += dtbImage.ep405
image-$(CONFIG_WALNUT) += treeImage.walnut
+image-$(CONFIG_ACADIA) += cuImage.acadia
# Board ports in arch/powerpc/platform/44x/Kconfig
image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony
diff --git a/arch/powerpc/boot/cuboot-acadia.c
b/arch/powerpc/boot/cuboot-acadia.c
new file mode 100644
index 000..0634aba
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-acadia.c
@@ -0,0 +1,174 @@
+/*
+ * Old U-boot compatibility for Acadia
+ *
+ * Author: Josh Boyer <[EMAIL PROTECTED]>
+ *
+ * Copyright 2008 IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "io.h"
+#include "dcr.h"
+#include "stdio.h"
+#include "4xx.h"
+#include "44x.h"
+#include "cuboot.h"
+
+#define TARGET_4xx
+#include "ppcboot.h"
+
+static bd_t bd;
+
+#define CPR_PERD0_SPIDV_MASK 0x000F /* SPI Clock Divider */
+
+#define PLLC_SRC_MASK 0x2000 /* PLL feedback source */
+
+#define PLLD_FBDV_MASK0x1F00 /* PLL feedback divider value */
+#define PLLD_FWDVA_MASK0x000F /* PLL forward divider A value */
+#define PLLD_FWDVB_MASK0x0700 /* PLL forward divider B value */
+
+#define PRIMAD_CPUDV_MASK 0x0F00 /* CPU Clock Divisor Mask */
+#define PRIMAD_PLBDV_MASK 0x000F /* PLB Clock Divisor Mask */
+#define PRIMAD_OPBDV_MASK 0x0F00 /* OPB Clock Divisor Mask */
+#define PRIMAD_EBCDV_MASK 0x000F /* EBC Clock Divisor Mask */
+
+#define PERD0_PWMDV_MASK 0xFF00 /* PWM Divider Mask */
+#define PERD0_SPIDV_MASK 0x000F /* SPI Divider Mask */
+#define PERD0_U0DV_MASK0xFF00 /* UART 0 Divider Mask */
+#define PERD0_U1DV_MASK0x00FF /* UART 1 Divider Mask */
+
+static void get_clocks(void)
+{
+ unsigned long sysclk, cpr_plld, cpr_pllc, cpr_primad, plloutb, i;
+ unsigned long pllFwdDiv, pllFwdDivB, pllFbkDiv, pllPlbDiv, pllExtBusDiv;
+ unsigned long pllOpbDiv, freqEBC, freqUART, freqOPB;
+ unsigned long div; /* total divisor udiv * bdiv */
+ unsigned long umin; /* minimum udiv */
+ unsigned short diff;/* smallest diff */
+ unsigned long udiv; /* best udiv */
+ unsigned short idiff; /* current diff */
+ unsigned short ibdiv; /* current bdiv */
+ unsigned long est; /* current estimate */
+ unsigned long baud;
+ void *np;
+
+ /* read the sysclk value from the CPLD */
+ sysclk = (in_8((unsigned char *)0x8000) == 0xc) ? :
3000;
+
+ /*
+* Read PLL Mode registers
+*/
+ cpr_plld = CPR0_READ(DCRN_CPR0_PLLD);
+ cpr_pllc = CPR0_READ(DCRN_CPR0_PLLC);
+
+ /*
+* Determine forward divider A
+*/
+ pllFwdDiv = ((cpr_plld & PLLD_FWDVA_MASK) >> 16);
+
+ /*
+* Determine forward divider B
+*/
+ pllFwdDivB = ((cpr_plld & PLLD_FWDVB_MASK) >> 8);
+ if (pllFwdDivB == 0)
+ pllFwdDivB = 8;
+
+ /*
+* Determine FBK_DIV.
+*/
+ pllFbkDiv = ((cpr_plld & PLLD_FBDV_MASK) >> 24);
+ if (pllFbkDiv == 0)
+ pllFbkDiv = 256;
+
+ /*
+* Read CPR_PRIMAD register
+*/
+ cpr_primad = CPR0_READ(DCRN_CPR0_PRIMAD);
+
+ /*
+* Determine PLB_DIV.
+*/
+ pllPl
[PATCH 5/5] powerpc/40x: Add PowerPC 405EZ Acadia defconfig
Add simple defconfig for the AMCC PowerPC 405EZ Acadia evaluation board Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> --- arch/powerpc/configs/40x/acadia_defconfig | 917 + 1 files changed, 917 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/configs/40x/acadia_defconfig diff --git a/arch/powerpc/configs/40x/acadia_defconfig b/arch/powerpc/configs/40x/acadia_defconfig new file mode 100644 index 000..99a0e2a --- /dev/null +++ b/arch/powerpc/configs/40x/acadia_defconfig @@ -0,0 +1,917 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.27-rc3 +# Wed Sep 3 14:47:45 2008 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +# CONFIG_6xx is not set +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +CONFIG_40x=y +# CONFIG_44x is not set +# CONFIG_E200 is not set +CONFIG_4xx=y +# CONFIG_PPC_MM_SLICES is not set +CONFIG_NOT_COHERENT_CACHE=y +CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 +CONFIG_PPC_MERGE=y +CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set +CONFIG_IRQ_PER_CPU=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +CONFIG_PPC_UDBG_16550=y +# CONFIG_GENERIC_TBSYNC is not set +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +# CONFIG_DEFAULT_UIMAGE is not set +CONFIG_PPC_DCR_NATIVE=y +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_PPC_DCR=y +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +CONFIG_GROUP_SCHED=y +# CONFIG_FAIR_GROUP_SCHED is not set +# CONFIG_RT_GROUP_SCHED is not set +CONFIG_USER_SCHED=y +# CONFIG_CGROUP_SCHED is not set +CONFIG_SYSFS_DEPRECATED=y +CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_RELAY is not set +# CONFIG_NAMESPACES is not set +CONFIG_BLK_DEV_INITRD=y +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +CONFIG_KALLSYMS_ALL=y +CONFIG_KALLSYMS_EXTRA_PASS=y +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_COMPAT_BRK=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_TIMERFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLUB_DEBUG=y +# CONFIG_SLAB is not set +CONFIG_SLUB=y +# CONFIG_SLOB is not set +# CONFIG_PROFILING is not set +# CONFIG_MARKERS is not set +CONFIG_HAVE_OPROFILE=y +# CONFIG_KPROBES is not set +CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y +CONFIG_HAVE_IOREMAP_PROT=y +CONFIG_HAVE_KPROBES=y +CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_ARCH_TRACEHOOK=y +# CONFIG_HAVE_DMA_ATTRS is not set +# CONFIG_USE_GENERIC_SMP_HELPERS is not set +# CONFIG_HAVE_CLK is not set +CONFIG_PROC_PAGE_MONITOR=y +# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +# CONFIG_MODULE_FORCE_LOAD is not set +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y +CONFIG_BLOCK=y +CONFIG_LBD=y +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set +# CONFIG_BLK_DEV_INTEGRITY is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" +CONFIG_CLASSIC_RCU=y +# CONFIG_PPC4xx_PCI_EXPRESS is not set + +# +# Platform support +# +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_PQ2ADS is not set +CONFIG_ACADIA=y +# CONFIG_EP405 is not set +# CONFIG_KILAUEA is not set +# CONFIG_MAKALU is not set +# CONFIG_WALNUT is not set +# CONFIG_XILINX_VIRTEX_GENERIC_BOARD is not set +CONFIG_405EZ=y +# CONFIG_IPIC is not set +# CONFIG_MPIC is not set +# CONFIG_MPIC_WEIRD is not set +# CONFIG_PPC_I8259 is not set +# CONFIG_PPC_RTAS is not set +# CONFIG_MMIO_NVRAM is not set +# CONFIG_PPC_MPC106 is not s
Re: Compact Flash on 8349mITX
On Thu, Oct 09, 2008 at 08:27:05PM -0700, Jeff Borlin wrote: > > > Anton Vorontsov-2 wrote: > > > > This happens just before the PATA information is printed. I'm not > > libata expert; and from the brief look I don't see where libata > > clears any pending "unexpected" irqs. Just a guesswork, > > could you try this patch? > > > This patch did not appear to change anything. :-( > Anton Vorontsov-2 wrote: > > > > Can you check if the CF will work w/o IRQs? To try it: > > > Your directions did result in progress: > [...] > scsi4 : pata_platform > ata5: PATA max PIO6 no IRQ, using PIO polling mmio cmd 0xf000 ctl > 0xf20c > ata5.00: CFA: SanDisk SDCFJ-512, HDX 3.13, max MWDMA2 > ata5.00: 1000944 sectors, multi 0: LBA > ata5.00: configured for PIO > scsi 4:0:0:0: Direct-Access ATA SanDisk SDCFJ-51 HDX PQ: 0 ANSI: 5 > sd 4:0:0:0: [sda] 1000944 512-byte hardware sectors (512 MB) > sd 4:0:0:0: [sda] Write Protect is off > sd 4:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't > support DPO or FUA > sd 4:0:0:0: [sda] 1000944 512-byte hardware sectors (512 MB) > sd 4:0:0:0: [sda] Write Protect is off > sd 4:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't > support DPO or FUA > sda: sda1 sda2 > sd 4:0:0:0: [sda] Attached SCSI removable disk > sd 4:0:0:0: Attached scsi generic sg0 type 0 > physmap platform flash device: 0100 at fe00 > [...] > / # dd if=/dev/sda of=/dev/null count=2 > 2+0 records in > 2+0 records out Ok, it basically works w/o IRQs... I'll try to find bunch of CF flashes to test, but to my knowledge they all worked for me on the mitx (i.e. with IRQs)... :-/ If I could find the non-working CF (or non-working mITX board) I would investigate this... > / # mount -t vfat /dev/sda /mnt/cf > mount: Mounting /dev/sda on /mnt/cf failed: Invalid argument > / # mount -t vfat /dev/sda2 /mnt/cf > mount: Mounting /dev/sda2 on /mnt/cf failed: Invalid argument This seems unrelated, either there isn't vfat support enabled in the kernel, or there is another filesystem on the CF). -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/5] powerpc/40x: Add support for PowerPC 405EZ Acadia board
Add base support for the AMCC PowerPC 405EZ Acadia evalution board. In addition
to some of the normal PPC 40x peripherals, the Acadia board has:
- 64 MiB PSRAM
- NOR and NAND flash
- Two USB 1.1 host ports
- Two CAN 2.0 ports
- ADC and DAC connectors
- LCD display
This adds the basic platform support to build from.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/40x/Kconfig | 14 +
arch/powerpc/platforms/40x/Makefile |1 +
arch/powerpc/platforms/40x/acadia.c | 56 +++
3 files changed, 71 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/40x/acadia.c
diff --git a/arch/powerpc/platforms/40x/Kconfig
b/arch/powerpc/platforms/40x/Kconfig
index a9260e2..fe59060 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -14,6 +14,14 @@
# help
#This option enables support for the CPCI405 board.
+config ACADIA
+ bool "Acadia"
+ depends on 40x
+ default n
+ select 405EZ
+ help
+ This option enables support for the AMCC 405EZ Acadia evaluation
board.
+
config EP405
bool "EP405/EP405PC"
depends on 40x
@@ -118,6 +126,12 @@ config 405EX
select IBM_NEW_EMAC_EMAC4
select IBM_NEW_EMAC_RGMII
+config 405EZ
+ bool
+ select IBM_NEW_EMAC_NO_FLOW_CTRL
+ select IBM_NEW_EMAC_MAL_CLR_ICINTSTAT
+ select IBM_NEW_EMAC_MAL_COMMON_ERR
+
config 405GPR
bool
diff --git a/arch/powerpc/platforms/40x/Makefile
b/arch/powerpc/platforms/40x/Makefile
index 5533a5c..ff483c0 100644
--- a/arch/powerpc/platforms/40x/Makefile
+++ b/arch/powerpc/platforms/40x/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_MAKALU)+= makalu.o
obj-$(CONFIG_WALNUT) += walnut.o
obj-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD) += virtex.o
obj-$(CONFIG_EP405)+= ep405.o
+obj-$(CONFIG_ACADIA) += acadia.o
diff --git a/arch/powerpc/platforms/40x/acadia.c
b/arch/powerpc/platforms/40x/acadia.c
new file mode 100644
index 000..9a4419b
--- /dev/null
+++ b/arch/powerpc/platforms/40x/acadia.c
@@ -0,0 +1,56 @@
+/*
+ * Acadia board support
+ *
+ * Copyright 2008 IBM Corporation
+ * Based on the Walnut code
+ * Josh Boyer <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static __initdata struct of_device_id acadia_of_bus[] = {
+ { .compatible = "ibm,plb3", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ {},
+};
+
+static int __init acadia_device_probe(void)
+{
+ of_platform_bus_probe(NULL, acadia_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(acadia, acadia_device_probe);
+
+static int __init acadia_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, "amcc,acadia"))
+ return 0;
+
+ return 1;
+}
+
+define_machine(acadia) {
+ .name = "Acadia",
+ .probe = acadia_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq= uic_get_irq,
+ .restart= ppc4xx_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 16/16] powerpc ps3: use smp_request_message_ipi
ps3 has 4 ipis per cpu and can use the new smp_request_message_ipi to
reduce path length when receiving an ipi.
This has the side effect of setting IRQF_PERCPU.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Index: next.git/arch/powerpc/platforms/ps3/smp.c
===
--- next.git.orig/arch/powerpc/platforms/ps3/smp.c 2008-10-05
00:20:41.0 -0500
+++ next.git/arch/powerpc/platforms/ps3/smp.c 2008-10-05 00:22:50.0
-0500
@@ -32,12 +32,6 @@
#define DBG pr_debug
#endif
-static irqreturn_t ipi_function_handler(int irq, void *msg)
-{
- smp_message_recv((int)(long)msg);
- return IRQ_HANDLED;
-}
-
/**
* ps3_ipi_virqs - a per cpu array of virqs for ipi use
*/
@@ -45,13 +39,6 @@ static irqreturn_t ipi_function_handler(
#define MSG_COUNT 4
static DEFINE_PER_CPU(unsigned int, ps3_ipi_virqs[MSG_COUNT]);
-static const char *names[MSG_COUNT] = {
- "ipi call",
- "ipi reschedule",
- "ipi migrate",
- "ipi debug brk"
-};
-
static void do_message_pass(int target, int msg)
{
int result;
@@ -119,8 +106,7 @@ static void __init ps3_smp_setup_cpu(int
DBG("%s:%d: (%d, %d) => virq %u\n",
__func__, __LINE__, cpu, i, virqs[i]);
- result = request_irq(virqs[i], ipi_function_handler,
- IRQF_DISABLED, names[i], (void*)(long)i);
+ result = smp_request_message_ipi(virqs[i], i);
if (result)
virqs[i] = NO_IRQ;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove non-dependent load fsl_booke PTE_64BIT
On Oct 10, 2008, at 6:56 AM, Milton Miller wrote: b38fd42ff46a4a31dced8533e8a6e549693500b6 added false dependencys to order the load of upper and lower halfs of the pte, but only adjusted whitespace instead of deleting the old load in the iside handler, letting the hardware see the non-dependent load. This patch removes the extra load. Signed-off-by: Milton Miller <[EMAIL PROTECTED]> --- Kumar, I think this is right from my inspection, please review. good catch, thanks. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove non-dependent load fsl_booke PTE_64BIT
On Oct 10, 2008, at 6:56 AM, Milton Miller wrote: b38fd42ff46a4a31dced8533e8a6e549693500b6 added false dependencys to order the load of upper and lower halfs of the pte, but only adjusted whitespace instead of deleting the old load in the iside handler, letting the hardware see the non-dependent load. This patch removes the extra load. Signed-off-by: Milton Miller <[EMAIL PROTECTED]> --- Kumar, I think this is right from my inspection, please review. applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 10/16] xics: make printk formats fit on one line
Several printks were broken at word boundaries for line length. Some
even referred to old function names. Using __func__ and changing the
text slightly for the format allows these printk formats to fit on one
line.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Index: next.git/arch/powerpc/platforms/pseries/xics.c
===
--- next.git.orig/arch/powerpc/platforms/pseries/xics.c 2008-10-04
21:56:17.0 -0500
+++ next.git/arch/powerpc/platforms/pseries/xics.c 2008-10-04
21:56:30.0 -0500
@@ -201,17 +201,17 @@ static void xics_unmask_irq(unsigned int
call_status = rtas_call(ibm_set_xive, 3, 1, NULL, irq, server,
DEFAULT_PRIORITY);
if (call_status != 0) {
- printk(KERN_ERR "xics_enable_irq: irq=%u: ibm_set_xive "
- "returned %d\n", irq, call_status);
- printk("set_xive %x, server %x\n", ibm_set_xive, server);
+ printk(KERN_ERR
+ "%s: ibm_set_xive irq %u server %x returned %d\n",
+ __func__, irq, server, call_status);
return;
}
/* Now unmask the interrupt (often a no-op) */
call_status = rtas_call(ibm_int_on, 1, 1, NULL, irq);
if (call_status != 0) {
- printk(KERN_ERR "xics_enable_irq: irq=%u: ibm_int_on "
- "returned %d\n", irq, call_status);
+ printk(KERN_ERR "%s: ibm_int_on irq=%u returned %d\n",
+ __func__, irq, call_status);
return;
}
}
@@ -232,8 +232,8 @@ static void xics_mask_real_irq(unsigned
call_status = rtas_call(ibm_int_off, 1, 1, NULL, irq);
if (call_status != 0) {
- printk(KERN_ERR "xics_disable_real_irq: irq=%u: "
- "ibm_int_off returned %d\n", irq, call_status);
+ printk(KERN_ERR "%s: ibm_int_off irq=%u returned %d\n",
+ __func__, irq, call_status);
return;
}
@@ -241,8 +241,8 @@ static void xics_mask_real_irq(unsigned
call_status = rtas_call(ibm_set_xive, 3, 1, NULL, irq,
default_server, 0xff);
if (call_status != 0) {
- printk(KERN_ERR "xics_disable_irq: irq=%u: ibm_set_xive(0xff)"
- " returned %d\n", irq, call_status);
+ printk(KERN_ERR "%s: ibm_set_xive(0xff) irq=%u returned %d\n",
+ __func__, irq, call_status);
return;
}
}
@@ -346,8 +346,8 @@ static void xics_set_affinity(unsigned i
status = rtas_call(ibm_get_xive, 1, 3, xics_status, irq);
if (status) {
- printk(KERN_ERR "xics_set_affinity: irq=%u ibm,get-xive "
- "returns %d\n", irq, status);
+ printk(KERN_ERR "%s: ibm,get-xive irq=%u returns %d\n",
+ __func__, irq, status);
return;
}
@@ -359,8 +359,9 @@ static void xics_set_affinity(unsigned i
if (irq_server == -1) {
char cpulist[128];
cpumask_scnprintf(cpulist, sizeof(cpulist), cpumask);
- printk(KERN_WARNING "xics_set_affinity: No online cpus in "
- "the mask %s for irq %d\n", cpulist, virq);
+ printk(KERN_WARNING
+ "%s: No online cpus in the mask %s for irq %d\n",
+ __func__, cpulist, virq);
return;
}
@@ -368,8 +369,8 @@ static void xics_set_affinity(unsigned i
irq, irq_server, xics_status[1]);
if (status) {
- printk(KERN_ERR "xics_set_affinity: irq=%u ibm,set-xive "
- "returns %d\n", irq, status);
+ printk(KERN_ERR "%s: ibm,set-xive irq=%u returns %d\n",
+ __func__, irq, status);
return;
}
}
@@ -829,9 +830,8 @@ void xics_migrate_irqs_away(void)
status = rtas_call(ibm_get_xive, 1, 3, xics_status, irq);
if (status) {
- printk(KERN_ERR "migrate_irqs_away: irq=%u "
- "ibm,get-xive returns %d\n",
- virq, status);
+ printk(KERN_ERR "%s: ibm,get-xive irq=%u returns %d\n",
+ __func__, irq, status);
goto unlock;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
Matt Sealey wrote: CHRP and PMAC aren't following the rules that everyone else is following. Why? Because they are by far the historically most common configuration, and still in production as the defacto standard PowerPC system configuration. So you could make an argument for it being turned on in arch/powerpc/defconfig, if we had one. That doesn't mean it should be "default y". IBM blades etc. with SLOF will boot up as a CHRP-ish system, as well as the Efika and Pegasos and anything else Genesi produces. Since Linux distributions generally do not support tiny embedded boards, What do distributions have to do with it? It's harder for distributions to set the options they want than for embedded developers? you can imagine why it's disabled by default, but there's no reason it can't be ENABLED by default and turned off by a distribution, the same way it can't be enabled by default and turned off by YOU (compare and contrast having to manually select which board you want to build for every time). Likewise there's no reason that PMAC/CHRP can't be DISABLED by default, and turned on by YOU. But, turning them all on would not matter. You would build a kernel for every one and a device tree for every one increasing your build time a bit for a default kernel, s/a bit/a lot/ but you would be guaranteed to get a kernel binary somewhere in the tree that would work on all of them :) Really? Who do I go to for this guarantee, when there's no support for the hardware I'm trying to get to work? :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove support for bootmem-allocated memory for the DIU driver
On Sep 23, 2008, at 9:47 AM, Timur Tabi wrote: Early versions of the Freescale DIU framebuffer driver depended on a bootmem allocation of memory for the video buffer. The need for this feature was removed in commit 6b51d51a, so now we can remove the platform- specific code that allocated that memory. Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> --- This patch is for 2.6.28. arch/powerpc/platforms/86xx/mpc8610_hpcd.c |1 - arch/powerpc/sysdev/fsl_soc.c | 38 +--- arch/powerpc/sysdev/fsl_soc.h |8 -- 3 files changed, 1 insertions(+), 46 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix conflict with Elo DMA driver in MPC8610 device tree
On Sep 26, 2008, at 12:20 PM, Timur Tabi wrote: The Freescale Elo DMA driver binds to all DMA channels in the device tree that are compatible with "fsl,eloplus-dma-channel". This conflicts with the sound drivers for the MPC8610. To avoid the conflict, change the compatible property for the DMA channels needed by the sound drivers to "fsl,ssi-dma- channel". This works because the sound drivers don't actually check the compatible property when it grabs DMA channels. Also update dma.txt and ssi.txt with this information. Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> --- Documentation/powerpc/dts-bindings/fsl/dma.txt | 13 +++-- Documentation/powerpc/dts-bindings/fsl/ssi.txt | 12 ++-- arch/powerpc/boot/dts/mpc8610_hpcd.dts |4 ++-- 3 files changed, 23 insertions(+), 6 deletions(-) Break this into two patches. The second one should just be the .dts and specifically say "on the MPC8610 HPCD board we use SSI and thus the dma channel is not available for general purpose use"... - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/16] xics: initialization cleanups
We only need to check the ibm,interrupt-server#-size property once, not
once per global server and thread.
We can use !CONFIG_SMP cpu masks and hard_smp_processor_id() to avoid an ifdef.
Put the node when breaking out of the loop on lpar systems.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Index: next.git/arch/powerpc/platforms/pseries/xics.c
===
--- next.git.orig/arch/powerpc/platforms/pseries/xics.c 2008-10-04
17:39:58.0 -0500
+++ next.git/arch/powerpc/platforms/pseries/xics.c 2008-10-04
17:40:00.0 -0500
@@ -606,21 +606,20 @@ static void xics_update_irq_servers(void
if (ireg[j] == hcpuid) {
default_server = hcpuid;
default_distrib_server = ireg[j+1];
-
- isize = of_get_property(np,
- "ibm,interrupt-server#-size", NULL);
- if (isize)
- interrupt_server_size = *isize;
}
}
+ /* get the bit size of server numbers */
+ isize = of_get_property(np, "ibm,interrupt-server#-size", NULL);
+ if (isize)
+ interrupt_server_size = *isize;
+
of_node_put(np);
}
static void __init xics_map_one_cpu(int hw_id, unsigned long addr,
unsigned long size)
{
-#ifdef CONFIG_SMP
int i;
/* This may look gross but it's good enough for now, we don't quite
@@ -634,11 +633,6 @@ static void __init xics_map_one_cpu(int
return;
}
}
-#else
- if (hw_id != 0)
- return;
- xics_per_cpu[0] = ioremap(addr, size);
-#endif /* CONFIG_SMP */
}
static void __init xics_init_one_node(struct device_node *np,
@@ -700,8 +694,10 @@ void __init xics_init_IRQ(void)
for_each_node_by_type(np, "PowerPC-External-Interrupt-Presentation") {
found = 1;
- if (firmware_has_feature(FW_FEATURE_LPAR))
+ if (firmware_has_feature(FW_FEATURE_LPAR)) {
+ of_node_put(np);
break;
+ }
xics_init_one_node(np, &indx);
}
if (found == 0)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v7] PPC440EPx gpio driver
This patch adds support for the GPIO functions of PPC40x and PPC44x
SOCs.
Signed-off-by: Steve Falco
---
Changes from the previous version:
1) Removed !! from the input routine. I'll work up a separate patch for
sysfs to sanitize input.
2) Used the clr/set macros to improve readability.
3) Changed the device from amcc to ibm.
diff --git a/arch/powerpc/platforms/40x/Kconfig
b/arch/powerpc/platforms/40x/Kconfig
index a9260e2..aaada72 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -139,6 +139,14 @@ config STB03xxx
select IBM405_ERR77
select IBM405_ERR51
+config PPC4xx_GPIO
+ bool "PPC4xx GPIO support"
+ depends on 40x
+ select ARCH_REQUIRE_GPIOLIB
+ select GENERIC_GPIO
+ help
+ Enable gpiolib support for ppc40x based boards
+
# 40x errata/workaround config symbols, selected by the CPU models above
# All 405-based cores up until the 405GPR and 405EP have this errata.
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index 249ba01..eec5cb4 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -127,6 +143,14 @@ config XILINX_VIRTEX440_GENERIC_BOARD
Most Virtex 5 designs should use this unless it needs to do some
special configuration at board probe time.
+config PPC4xx_GPIO
+ bool "PPC4xx GPIO support"
+ depends on 44x
+ select ARCH_REQUIRE_GPIOLIB
+ select GENERIC_GPIO
+ help
+ Enable gpiolib support for ppc440 based boards
+
# 44x specific CPU modules, selected based on the board above.
config 440EP
bool
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index a90054b..35d5765 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_OF_RTC) += of_rtc.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
endif
+obj-$(CONFIG_PPC4xx_GPIO) += ppc4xx_gpio.o
# Temporary hack until we have migrated to asm-powerpc
ifeq ($(ARCH),powerpc)
diff --git a/arch/powerpc/sysdev/ppc4xx_gpio.c
b/arch/powerpc/sysdev/ppc4xx_gpio.c
new file mode 100644
index 000..110efe2
--- /dev/null
+++ b/arch/powerpc/sysdev/ppc4xx_gpio.c
@@ -0,0 +1,217 @@
+/*
+ * PPC4xx gpio driver
+ *
+ * Copyright (c) 2008 Harris Corporation
+ * Copyright (c) 2008 Sascha Hauer <[EMAIL PROTECTED]>, Pengutronix
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Steve Falco <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GPIO_MASK(gpio)(0x8000 >> (gpio))
+#define GPIO_MASK2(gpio) (0xc000 >> ((gpio) * 2))
+
+/* Physical GPIO register layout */
+struct ppc4xx_gpio {
+ __be32 or;
+ __be32 tcr;
+ __be32 osrl;
+ __be32 osrh;
+ __be32 tsrl;
+ __be32 tsrh;
+ __be32 odr;
+ __be32 ir;
+ __be32 rr1;
+ __be32 rr2;
+ __be32 rr3;
+ __be32 reserved1;
+ __be32 isr1l;
+ __be32 isr1h;
+ __be32 isr2l;
+ __be32 isr2h;
+ __be32 isr3l;
+ __be32 isr3h;
+};
+
+struct ppc4xx_gpio_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+};
+
+/*
+ * GPIO LIB API implementation for GPIOs
+ *
+ * There are a maximum of 32 gpios in each gpio controller.
+ */
+
+static inline struct ppc4xx_gpio_chip *
+to_ppc4xx_gpiochip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct ppc4xx_gpio_chip, mm_gc);
+}
+
+static int ppc4xx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct ppc4xx_gpio __iomem *regs = mm_gc->regs;
+
+ return in_be32(®s->ir) & GPIO_MASK(gpio);
+}
+
+static inline void
+__ppc4xx_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 ppc4xx_gpio __iomem *regs = mm_gc->regs;
+
+ if (val)
+ setbits32(®s->or, GPIO_MASK(gpio));
+ else
+ clrbits32(®s->or, GPIO_MASK(gpio));
+}
+
+static void
+ppc4xx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_g
Re: [RFC 0/6] Proposal for a Generic PWM Device API
David Woodhouse wrote: > Subscriber-only lists are broken. Just don't use them. You owe me a new keyboard! :) b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
kernel 2.6.27 MPC512x status
I gave a try to the brand new 2.6.27 kernel on my ADS5121 evaluation board: * FEC support is not in, though it was quite easy to add FSL patches from 2.6.24.6 and have the ethernet working * If I turn on any USB support, the board resets itself as soon as the USB driver is loaded. Without USB, I can get to a prompt. Funny that the software reset is not working, but this bug is actually able to sw reset the board... * PCI seems not to be working, but I need to test it more. The fact that FSL needed to patch 2.6.24.6 in order to get PCI working makes me think it's needs some work. This is bad because I wanted to incorporate some newer patches, like the PWM one, but kernel 2.6.24.6 is too backward in time, while 2.6.27 is too forward for FSL patches... M ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 15/16] powerpc cell: use smp_request_message_ipi
cell native has 4 interrupts for ipis, so use the new smp_request_message_ipi
to save pathlength and the data-dependent branch.
This has the side effects of enabling the debugger ipi for kdump and
setting IRQF_PERCPU for the ipi interrupts. It doesn't undo the virq
mapping if it turns out the ipi is not used.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Index: next.git/arch/powerpc/platforms/cell/interrupt.c
===
--- next.git.orig/arch/powerpc/platforms/cell/interrupt.c 2008-10-04
23:40:24.0 -0500
+++ next.git/arch/powerpc/platforms/cell/interrupt.c2008-10-04
23:44:49.0 -0500
@@ -190,38 +190,25 @@ struct irq_host *iic_get_irq_host(int no
}
EXPORT_SYMBOL_GPL(iic_get_irq_host);
-static irqreturn_t iic_ipi_action(int irq, void *dev_id)
-{
- int ipi = (int)(long)dev_id;
-
- smp_message_recv(ipi);
-
- return IRQ_HANDLED;
-}
-static void iic_request_ipi(int ipi, const char *name)
+static void iic_request_ipi(int ipi)
{
int virq;
virq = irq_create_mapping(iic_host, iic_ipi_to_irq(ipi));
if (virq == NO_IRQ) {
printk(KERN_ERR
- "iic: failed to map IPI %s\n", name);
+ "iic: failed to map IPI %s\n", smp_ipi_name[ipi]);
return;
}
- if (request_irq(virq, iic_ipi_action, IRQF_DISABLED, name,
- (void *)(long)ipi))
- printk(KERN_ERR
- "iic: failed to request IPI %s\n", name);
+ smp_request_message_ipi(virq, ipi);
}
void iic_request_IPIs(void)
{
- iic_request_ipi(PPC_MSG_CALL_FUNCTION, "IPI-call");
- iic_request_ipi(PPC_MSG_RESCHEDULE, "IPI-resched");
- iic_request_ipi(PPC_MSG_CALL_FUNC_SINGLE, "IPI-call-single");
-#ifdef CONFIG_DEBUGGER
- iic_request_ipi(PPC_MSG_DEBUGGER_BREAK, "IPI-debug");
-#endif /* CONFIG_DEBUGGER */
+ iic_request_ipi(PPC_MSG_CALL_FUNCTION);
+ iic_request_ipi(PPC_MSG_RESCHEDULE);
+ iic_request_ipi(PPC_MSG_CALL_FUNC_SINGLE);
+ iic_request_ipi(PPC_MSG_DEBUGGER_BREAK);
}
#endif /* CONFIG_SMP */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mtd: remove dead Kconfig associated with !CONFIG_PPC_MERGE
On Thu, Oct 09, 2008 at 10:50:06PM -0500, Kumar Gala wrote: >Removed the Kconfig associated with 'NDFC NanD Flash Controller'. >We can't enable !CONFIG_PPC_MERGE so there is no way to enable >this. Additionally the code needs to get updated for arch/powerpc. > >For the time being lets just remove the Kconfig option so we can >actually remove CONFIG_PPC_MERGE. > >Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> The driver does need fixing, and there are patches for it. We just haven't settled on an implementation yet so: Acked-by: Josh Boyer <[EMAIL PROTECTED]> >--- > drivers/mtd/nand/Kconfig |7 --- > 1 files changed, 0 insertions(+), 7 deletions(-) > >diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig >index 41f361c..1acdff7 100644 >--- a/drivers/mtd/nand/Kconfig >+++ b/drivers/mtd/nand/Kconfig >@@ -163,13 +163,6 @@ 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 && !PPC_MERGE >- 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 >-- >1.5.5.1 > >___ >Linuxppc-dev mailing list >Linuxppc-dev@ozlabs.org >https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Paul Mundt wrote: > This is likely because some of those lists are subscribers only, so cross > posting is poor form. It makes sense to keep the discussion in one place, > and to send notification messages with a pointer to the list archives to > the other lists so folks can jump in if they really care. Splitting it > out doesn't help matters in the least, but unfortunately this is what > seems to happen the most when subscribers only lists are involved. Alright, then maybe I can do this when I post the "final" changeset for review: cross-post to lkml and linux-embedded, and then post one short note on l-a-k, linuxppc-dev and elsewhere that refers those interested to the actual content. I can live with that. b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7] PPC440EPx gpio driver
On Friday 10 October 2008, Steven A. Falco wrote: > This patch adds support for the GPIO functions of PPC40x and PPC44x > SOCs. Looks good. But you should change the subject line now. Its not only a PPC440EPx gpio driver but ppc4xx. Also please add "powerpc/4xx: " to the beginning of the subject line. And you should always send 4xx related patches to the subsystem maintainer too (CC), in this case Josh Boyer. > Signed-off-by: Steve Falco You can add my: Acked-by: Stefan Roese <[EMAIL PROTECTED]> in the next patch revision. :) Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Jon Smirl wrote: > What do the device tree deities have to say about PWM support? Dunno. What lists are they on? :) b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Modify sysfs gpio export so that "value" displays as 0 or 1
gpiolib can export GPIOs to userspace via sysfs. This patch modifies the gpio_value_show() so that any non-zero value is explicitly printed as "1", rather than whatever numerical value the lower-level driver returns. Signed-off-by: Steve Falco --- diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 8d29405..36bf72b 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -237,7 +237,7 @@ static ssize_t gpio_value_show(struct device *dev, if (!test_bit(FLAG_EXPORT, &desc->flags)) status = -EIO; else - status = sprintf(buf, "%d\n", gpio_get_value_cansleep(gpio)); + status = sprintf(buf, "%d\n", !!gpio_get_value_cansleep(gpio)); mutex_unlock(&sysfs_lock); return status; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 1/6] [PWM] Generic PWM API implementation
Benjamin Herrenschmidt wrote: > On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote: >> Signed-off-by: Bill Gatliff <[EMAIL PROTECTED]> >> --- > > And you haven't provided -any- changeset comment. That isn't good :-) What's the easiest way to do that with git? I'm using git-format-patch and git-send-email to produce the changeset emails themselves, after extensive use of git-add --interactive and git-rebase --interactive to get rid of the "mundane" commit stuff that I do because of my highly interrupt-driven workflow. Should I just edit the files that come out of git-format-patch? b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 10:04 AM, Bill Gatliff <[EMAIL PROTECTED]> wrote: > Jon Smirl wrote: > >> What do the device tree deities have to say about PWM support? > > Dunno. What lists are they on? :) They are on linuxppc-dev. Device trees would be used on powerpc to control the initial setup of the PWM device. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] i2c: MPC8349E-mITX Power Management and GPIO expander driver
On Sep 23, 2008, at 9:13 AM, Anton Vorontsov wrote: On MPC8349E-mITX, MPC8315E-RDB and MPC837x-RDB boards there is a Freescale MC9S08QG8 (MCU) chip with the custom firmware pre-programmed. The chip is used to power-off the board by the software, and to control some GPIO pins. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- drivers/i2c/chips/Kconfig| 11 ++ drivers/i2c/chips/Makefile |1 + drivers/i2c/chips/mcu_mpc8349emitx.c | 209 + + 3 files changed, 221 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/chips/mcu_mpc8349emitx.c is the plan to connect ppc_md.machine_shutdown() with this? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] OF: add fsl,mcu-mpc8349emitx to the exception list
On Sep 23, 2008, at 9:12 AM, Anton Vorontsov wrote: of/base.c matches on the first (most specific) entries, which isn't quite practical but it was discussed[1] that this won't change. The bindings specifies verbose information for the devices, but it doesn't fit in the I2C ID's 20 characters limit. The limit won't change[2], and the bindings won't change either as they're correct. So we have to put an exception for the MPC8349E-mITX-compatible MCUs. [1] http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg21196.html [2] http://www.nabble.com/-PATCH-1-2--i2c:-expand-I2C's-id.name-to-23-characters-td19577063.html Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- drivers/of/base.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] remove bogus ppc_select syscall
On Friday 10 October 2008, Paul Mackerras wrote: > Please don't apply Arnd's patch. As I said, all we need is this > one-line change in arch/powerpc/include/asm/systbl.h: > > -SYSX_SPU(sys_select,ppc32_select,ppc_select) > +SYSX_SPU(sys_select,ppc32_select,sys_select) > > Paul. FWIW, Acked-by: Arnd Bergmann <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: kernel 2.6.27 MPC512x status
On Oct 10, 2008, at 8:37 AM, Matteo Fortini wrote: I gave a try to the brand new 2.6.27 kernel on my ADS5121 evaluation board: * FEC support is not in, though it was quite easy to add FSL patches from 2.6.24.6 and have the ethernet working * If I turn on any USB support, the board resets itself as soon as the USB driver is loaded. Without USB, I can get to a prompt. Funny that the software reset is not working, but this bug is actually able to sw reset the board... * PCI seems not to be working, but I need to test it more. The fact that FSL needed to patch 2.6.24.6 in order to get PCI working makes me think it's needs some work. This is bad because I wanted to incorporate some newer patches, like the PWM one, but kernel 2.6.24.6 is too backward in time, while 2.6.27 is too forward for FSL patches... I've applied some 3 patches from John Ribgy to add 5121 PCI support. These are intended for .28, but should be clean against .27. They are: powerpc/fsl: Hide MPC5121 pci bridge. powerpc: 83xx: pci: Remove need for get_immrbase from mpc83xx_add_bridge. powerpc/5121: Add PCI support. And can be found in: git.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git powerpc-next - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 00/16] xics and ipi cleanups for 2.6.28
The first two patches in this series implememnt a couple of bug fixes for the xics interrupt controller accessed as found in pseries hardware. The next several patches implement some code orginization and cleanups, followed by some changes to reduce code or flag the behavior to generic code. The last 5 patces are independent of the xics changes, although the first one affects xics. They are designed to reduce interrupt overhead for interprocessor interupts. While I would have liked to do more testing where I have access to the hardware (which is only xics), I am sending them out now for review and consdieration for the merge window. All have been compile tested, and I feel they are split into reviewable pieces. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 14/16] powerpc: expand vs demux ipi actions per message
With the new generic smp call function helpers, I noticed the code in
smp_message_recv was a single function call in many cases. While
getting the message number from the ipi data is easy, we can reduce
the path length by a function call and a mult-way data dependent
switch by registering seperate ipi actions for these simple calls.
Originally I left the ipi action array exposed, but then I realized the
registration code should be common so that decisions like needing the
driver data are common, along with flagging the interrupt per-cpu.
The three users each had their own name array and contents, so I
made a fourth style for all users.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
Perhaps we should make the common code look like an ipi action handler
and remove this last call? Currently we still have to allocate a stack
frame to load the return value.
Index: next.git/arch/powerpc/include/asm/smp.h
===
--- next.git.orig/arch/powerpc/include/asm/smp.h2008-10-05
00:08:36.0 -0500
+++ next.git/arch/powerpc/include/asm/smp.h 2008-10-05 00:16:34.0
-0500
@@ -81,6 +81,13 @@ extern int cpu_to_core_id(int cpu);
#define PPC_MSG_CALL_FUNC_SINGLE 2
#define PPC_MSG_DEBUGGER_BREAK 3
+/*
+ * irq controllers that have dedicated ipis per message and don't
+ * need additional code in the action handler may use this
+ */
+extern int smp_request_message_ipi(int irq, int message);
+extern const char *smp_ipi_name[];
+
void smp_init_iSeries(void);
void smp_init_pSeries(void);
void smp_init_cell(void);
Index: next.git/arch/powerpc/kernel/smp.c
===
--- next.git.orig/arch/powerpc/kernel/smp.c 2008-10-05 00:08:38.0
-0500
+++ next.git/arch/powerpc/kernel/smp.c 2008-10-05 00:19:12.0 -0500
@@ -123,6 +123,65 @@ void smp_message_recv(int msg)
}
}
+static irqreturn_t call_function_action(int irq, void *data)
+{
+ generic_smp_call_function_interrupt();
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t reschedule_action(int irq, void *data)
+{
+ /* we just need the return path side effect of checking need_resched */
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t call_function_single_action(int irq, void *data)
+{
+ generic_smp_call_function_single_interrupt();
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t debug_ipi_action(int irq, void *data)
+{
+ smp_message_recv(PPC_MSG_DEBUGGER_BREAK);
+ return IRQ_HANDLED;
+}
+
+static irq_handler_t smp_ipi_action[] = {
+ [PPC_MSG_CALL_FUNCTION] = call_function_action,
+ [PPC_MSG_RESCHEDULE] = reschedule_action,
+ [PPC_MSG_CALL_FUNC_SINGLE] = call_function_single_action,
+ [PPC_MSG_DEBUGGER_BREAK] = debug_ipi_action,
+};
+
+const char *smp_ipi_name[] = {
+ [PPC_MSG_CALL_FUNCTION] = "ipi call function",
+ [PPC_MSG_RESCHEDULE] = "ipi reschedule",
+ [PPC_MSG_CALL_FUNC_SINGLE] = "ipi call function single",
+ [PPC_MSG_DEBUGGER_BREAK] = "ipi debugger",
+};
+
+/* optional function to request ipi, for controllers with >= 4 ipis */
+int smp_request_message_ipi(int msg, int virq)
+{
+ int err;
+
+ if (msg < 0 || msg > PPC_MSG_DEBUGGER_BREAK) {
+ return -EINVAL;
+ }
+#if !defined(CONFIG_DEBUGGER) && !defined(CONFIG_KEXEC)
+ if (msg == PPC_MSG_DEBUGGER_BREAK) {
+ return 1;
+ }
+#endif
+ err = request_irq(virq, smp_ipi_action[msg], IRQF_DISABLED|IRQF_PERCPU,
+ smp_ipi_name[msg], 0);
+ WARN(err < 0, "unable to request_irq %d for %s (rc %d)\n",
+ virq, ipi_names[msg], err);
+
+ return err;
+}
+
void smp_send_reschedule(int cpu)
{
if (likely(smp_ops))
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2 v2] OF: new helper: of_parse_phandles_with_args()
The helper is factored out of of_get_gpio(). Will be used by the QE
pin multiplexing functions (they need to parse the gpios = <> too).
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
On Fri, Oct 10, 2008 at 02:37:29PM +1100, Benjamin Herrenschmidt wrote:
[...]
> Rather than incrementing i, I would just use a running pointer "list"
> and drop "i" totally. Not big deal tho.
Done.
> > + /* one cell hole in the list = <>; */
> > + if (!*phandle) {
> > + if (cur_index == index)
> > + return -ENOENT;
> > + i++;
> > + continue;
> > + }
>
> I don't totally understand the above. The 0 phandle terminates the list
> or is just an empty slot in it ?
An empty slot case.
> In the later case, it might be more
> readable to use goto to skip over down to the normal if (cur_index ==
> index) break; and let it return via the normal if (!node) return -ENOENT
> out of the loop.
Agree, done.
> Appart from that it's good and I'm fine with putting it in if you respin
> despite being a bit late mostly because it's me who is later reviewing
> there :-)
Much appreciated. Thanks for the comments.
drivers/of/base.c | 109
drivers/of/gpio.c | 79 +-
include/linux/of.h |3 +
3 files changed, 130 insertions(+), 61 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ad8ac1a..517da97 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -473,3 +473,112 @@ int of_modalias_node(struct device_node *node, char
*modalias, int len)
}
EXPORT_SYMBOL_GPL(of_modalias_node);
+/**
+ * of_parse_phandles_with_args - Find a node pointed by phandle in a list
+ * @np:pointer to a device tree node containing a list
+ * @list_name: property name that contains a list
+ * @cells_name:property name that specifies phandles' arguments count
+ * @index: index of a phandle to parse out
+ * @out_node: pointer to device_node struct pointer (will be filled)
+ * @out_args: pointer to arguments pointer (will be filled)
+ *
+ * This function is useful to parse lists of phandles and their arguments.
+ * Returns 0 on success and fills out_node and out_args, on error returns
+ * appropriate errno value.
+ *
+ * Example:
+ *
+ * phandle1: node1 {
+ * #list-cells = <2>;
+ * }
+ *
+ * phandle2: node2 {
+ * #list-cells = <1>;
+ * }
+ *
+ * node3 {
+ * list = <&phandle1 1 2 &phandle2 3>;
+ * }
+ *
+ * To get a device_node of the `node2' node you may call this:
+ * of_parse_phandles_with_args(node3, "list", "#list-cells", 2, &node2, &args);
+ */
+int of_parse_phandles_with_args(struct device_node *np, const char *list_name,
+ const char *cells_name, int index,
+ struct device_node **out_node,
+ const void **out_args)
+{
+ int ret = -EINVAL;
+ const u32 *list;
+ const u32 *list_end;
+ int size;
+ int cur_index = 0;
+ struct device_node *node = NULL;
+ const void *args;
+
+ list = of_get_property(np, list_name, &size);
+ if (!list) {
+ ret = -ENOENT;
+ goto err0;
+ }
+ list_end = list + size / sizeof(*list);
+
+ while (list < list_end) {
+ const u32 *cells;
+ const phandle *phandle;
+
+ phandle = list;
+ args = list + 1;
+
+ /* one cell hole in the list = <>; */
+ if (!*phandle) {
+ list++;
+ goto next;
+ }
+
+ node = of_find_node_by_phandle(*phandle);
+ if (!node) {
+ pr_debug("%s: could not find phandle\n",
+np->full_name);
+ goto err0;
+ }
+
+ cells = of_get_property(node, cells_name, &size);
+ if (!cells || size != sizeof(*cells)) {
+ pr_debug("%s: could not get %s for %s\n",
+np->full_name, cells_name, node->full_name);
+ goto err1;
+ }
+
+ /* Next phandle is at offset of one phandle cell + #cells */
+ list += 1 + *cells;
+ if (list > list_end) {
+ pr_debug("%s: insufficient arguments length\n",
+np->full_name);
+ goto err1;
+ }
+next:
+ if (cur_index == index)
+ break;
+
+ of_node_put(node);
+ node = NULL;
+ cur_index++;
+ }
+
+ if (!node) {
+ ret = -ENOENT;
+ goto err0;
+ }
+
+ *out_node = node;
+ *out_args = args;
+
+ return 0;
+err1:
+ of_node_put(n
Re: [PATCH 2/2] i2c: MPC8349E-mITX Power Management and GPIO expander driver
On Fri, Oct 10, 2008 at 09:22:02AM -0500, Kumar Gala wrote:
>
> On Sep 23, 2008, at 9:13 AM, Anton Vorontsov wrote:
>
>> On MPC8349E-mITX, MPC8315E-RDB and MPC837x-RDB boards there is a
>> Freescale MC9S08QG8 (MCU) chip with the custom firmware
>> pre-programmed. The chip is used to power-off the board by the
>> software, and to control some GPIO pins.
>>
>> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
>> ---
>> drivers/i2c/chips/Kconfig| 11 ++
>> drivers/i2c/chips/Makefile |1 +
>> drivers/i2c/chips/mcu_mpc8349emitx.c | 209 +
>> +
>> 3 files changed, 221 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/i2c/chips/mcu_mpc8349emitx.c
>
> is the plan to connect ppc_md.machine_shutdown() with this?
You mean poweroff? It's already connected.
+ /* XXX: this is potentially racy, but there is no lock for ppc_md */
+ if (!ppc_md.power_off) {
+ glob_mcu = mcu;
+ ppc_md.power_off = mcu_power_off;
+ dev_info(&client->dev, "will provide power-off service\n");
+ }
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 12/16] powerpc: reduce and comment xics ipi memory barrier
A single full sync (mb()) is requrired to order the mmio to the qirr reg
with the set or clear of the message word. However, test_and_clear_bit
has the effect of smp_mb() and we are not doing any other io from here,
so we don't need a mb per bit processed.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Index: next.git/arch/powerpc/platforms/pseries/xics.c
===
--- next.git.orig/arch/powerpc/platforms/pseries/xics.c 2008-10-04
23:56:15.0 -0500
+++ next.git/arch/powerpc/platforms/pseries/xics.c 2008-10-05
00:01:26.0 -0500
@@ -498,26 +498,23 @@ static irqreturn_t xics_ipi_dispatch(int
{
WARN_ON(cpu_is_offline(cpu));
+ mb(); /* order mmio clearing qirr */
while (xics_ipi_message[cpu].value) {
if (test_and_clear_bit(PPC_MSG_CALL_FUNCTION,
&xics_ipi_message[cpu].value)) {
- mb();
smp_message_recv(PPC_MSG_CALL_FUNCTION);
}
if (test_and_clear_bit(PPC_MSG_RESCHEDULE,
&xics_ipi_message[cpu].value)) {
- mb();
smp_message_recv(PPC_MSG_RESCHEDULE);
}
if (test_and_clear_bit(PPC_MSG_CALL_FUNC_SINGLE,
&xics_ipi_message[cpu].value)) {
- mb();
smp_message_recv(PPC_MSG_CALL_FUNC_SINGLE);
}
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
if (test_and_clear_bit(PPC_MSG_DEBUGGER_BREAK,
&xics_ipi_message[cpu].value)) {
- mb();
smp_message_recv(PPC_MSG_DEBUGGER_BREAK);
}
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 14/16] powerpc: expand vs demux ipi actions per message
On Fri, 10 Oct 2008, Milton Miller wrote: > +/* > + * irq controllers that have dedicated ipis per message and don't > + * need additional code in the action handler may use this > + */ > +extern int smp_request_message_ipi(int irq, int message); ^^^ ^^^ > +/* optional function to request ipi, for controllers with >= 4 ipis */ > +int smp_request_message_ipi(int msg, int virq) ^^^ Woops, the order (and to a lesser extend, the name) of the arguments doesn't match? Worse, all callers use the order of the prototype, not the one of the implementation. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/16] powerpc pseries: eoi unmapped xics irqs after disable
When reciving an irq vector that does not have a linux mapping, the kernel
prints a message and calls RTAS to disable the irq source. Previously
the kernel did not EOI the interrupt, causing the source to think it is
still being processed by software. While this does add an additional
layer of protection against interrupt storms had RTAS failed to disable
the source, it also prevents the interrupt from working when a driver
later enables it. (We could alternatively send an EOI on startup, but
that strategy would likely fail on an emulated xics.)
All interrupts should be disabled when the kernel starts, but this can
be observed if a driver does not shutdown an interrupt in its reboot
hook before starting a new kernel with kexec.
Michael reports this can be reproduced trivially by banging the keyboard
while kexec'ing on a P5 LPAR: even though the hvc_console driver request's
the console irq later in boot, the console is non-functional because
we're receiving no console interrupts.
Reported-By: Michael Ellerman
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
This version is for 2.6.28 based on benh's next branch. For prior
kernels, s/irq_radix_revmap_lookup/irq_radix_revmap/ before applying.
Index: next.git/arch/powerpc/platforms/pseries/xics.c
===
--- next.git.orig/arch/powerpc/platforms/pseries/xics.c 2008-10-04
16:34:45.0 -0500
+++ next.git/arch/powerpc/platforms/pseries/xics.c 2008-10-05
01:49:59.0 -0500
@@ -332,32 +332,61 @@ static void xics_eoi_lpar(unsigned int v
lpar_xirr_info_set((0xff << 24) | irq);
}
-static inline unsigned int xics_remap_irq(unsigned int vec)
+static inline unsigned int xics_xirr_vector(unsigned int xirr)
{
- unsigned int irq;
+ /*
+* The top byte is the old cppr, to be restored on EOI.
+* The remaining 24 bits are the vector.
+*/
+ return xirr & 0x00ff;
+}
- vec &= 0x00ff;
+static void xics_mask_unknown_vec(unsigned int vec)
+{
+ printk(KERN_ERR "Interrupt %u (real) is invalid, disabling it.\n", vec);
+ xics_mask_real_irq(vec);
+}
+
+static unsigned int xics_get_irq_direct(void)
+{
+ unsigned int xirr = direct_xirr_info_get();
+ unsigned int vec = xics_xirr_vector(xirr);
+ unsigned int irq;
if (vec == XICS_IRQ_SPURIOUS)
return NO_IRQ;
+
irq = irq_radix_revmap_lookup(xics_host, vec);
if (likely(irq != NO_IRQ))
return irq;
- printk(KERN_ERR "Interrupt %u (real) is invalid,"
- " disabling it.\n", vec);
- xics_mask_real_irq(vec);
- return NO_IRQ;
-}
+ /* We don't have a linux mapping, so have rtas mask it. */
+ xics_mask_unknown_vec(vec);
-static unsigned int xics_get_irq_direct(void)
-{
- return xics_remap_irq(direct_xirr_info_get());
+ /* We might learn about it later, so EOI it */
+ direct_xirr_info_set(xirr);
+ return NO_IRQ;
}
static unsigned int xics_get_irq_lpar(void)
{
- return xics_remap_irq(lpar_xirr_info_get());
+ unsigned int xirr = lpar_xirr_info_get();
+ unsigned int vec = xics_xirr_vector(xirr);
+ unsigned int irq;
+
+ if (vec == XICS_IRQ_SPURIOUS)
+ return NO_IRQ;
+
+ irq = irq_radix_revmap_lookup(xics_host, vec);
+ if (likely(irq != NO_IRQ))
+ return irq;
+
+ /* We don't have a linux mapping, so have RTAS mask it. */
+ xics_mask_unknown_vec(vec);
+
+ /* We might learn about it later, so EOI it */
+ lpar_xirr_info_set(xirr);
+ return NO_IRQ;
}
#ifdef CONFIG_SMP
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Thu, 9 Oct 2008, Bill Gatliff wrote: > Benjamin Herrenschmidt wrote: > > On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote: > >> This series proposes a "generic PWM" driver API. > >> > >> This proposed API is motivated by the author's need to support > >> pluggable devices; a secondary objective is to consolidate the > >> existing PWM implementations behind an agreeable, consistent, > >> redundancy-reducing interface. > > > > .../... > > > > You should send your patches to the main linux kernel list ! > > Perhaps. But it seemed more relevant to this crowd, and the linux-embedded > crowd, and the linux-arm-kernel crowd. Were did you actually sent them to? Apparently you sent them to each mailing list (at least linux-embedded and linuxppc-dev) _separately_ (or using bcc). Hence different people may give the same comments without knowing about each other, and you may have to explain everything multiple times. I would go for lkml and linux-embedded, _together_. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis · BIC GEBABEBB · IBAN BE41293037680010___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove default=y from PMAC and CHRP Kconfigs
Matt Sealey wrote: You do realise it's entirely possible to build a kernel which supports 50 different Freescale CPUs all in one? Enabling CHRP, PMAC support *AND* non-CHRP platforms is possible in the same binary. It's possible to build a kernel with 50 network drivers, too. That doesn't mean they should all be "default y". The kernel build takes long enough as is. If you really want to build a single-cpu single-board kernel, disable CHRP and PMAC for those board configs, If you really want to build a targets-everything kernel, then turn on everything. Go ahead and create a 6xx_defconfig that has support for everything enabled. But don't cause huge heaps of stuff to be enabled for everyone that does a "make oldconfig" with a config file that predates change d8267c1a36864fc30a2ce01f4349a8f2931ae741. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] i2c: MPC8349E-mITX Power Management and GPIO expander driver
On Oct 10, 2008, at 9:45 AM, Anton Vorontsov wrote:
On Fri, Oct 10, 2008 at 09:22:02AM -0500, Kumar Gala wrote:
On Sep 23, 2008, at 9:13 AM, Anton Vorontsov wrote:
On MPC8349E-mITX, MPC8315E-RDB and MPC837x-RDB boards there is a
Freescale MC9S08QG8 (MCU) chip with the custom firmware
pre-programmed. The chip is used to power-off the board by the
software, and to control some GPIO pins.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
drivers/i2c/chips/Kconfig| 11 ++
drivers/i2c/chips/Makefile |1 +
drivers/i2c/chips/mcu_mpc8349emitx.c | 209 +++
++
+
3 files changed, 221 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/chips/mcu_mpc8349emitx.c
is the plan to connect ppc_md.machine_shutdown() with this?
You mean poweroff? It's already connected.
+ /* XXX: this is potentially racy, but there is no lock for
ppc_md */
+ if (!ppc_md.power_off) {
+ glob_mcu = mcu;
+ ppc_md.power_off = mcu_power_off;
+ dev_info(&client->dev, "will provide power-off
service\n");
+ }
uuh, yeah.. poweroff :)
and look at that. Is this in Jean's queue?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Bill Gatliff <[EMAIL PROTECTED]> wrote: > Paul Mundt wrote: > > This is likely because some of those lists are subscribers only, so cross > > posting is poor form. It makes sense to keep the discussion in one place, > > and to send notification messages with a pointer to the list archives to > > the other lists so folks can jump in if they really care. Splitting it > > out doesn't help matters in the least, but unfortunately this is what > > seems to happen the most when subscribers only lists are involved. > > Alright, then maybe I can do this when I post the "final" changeset for > review: > cross-post to lkml and linux-embedded, and then post one short note on l-a-k, > linuxppc-dev and elsewhere that refers those interested to the actual content. > I can live with that. Feel free to cross-post to [EMAIL PROTECTED] It's open for non-subscribers, and there may be people interested in PWM there (especially since you include a driver for the PWM hardware on AVR32 devices.) Haavard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: FPGA support for GE Fanuc SBC610
On Oct 3, 2008, at 4:57 PM, Kumar Gala wrote: On Oct 1, 2008, at 7:46 AM, Martyn Welch wrote: Support for the SBC610 VPX Single Board Computer from GE Fanuc (PowerPC MPC8641D). This patch adds support for the registers held in the devices main FPGA, exposing extra information about the revision of the board through cpuinfo. Signed-off-by: Martyn Welch <[EMAIL PROTECTED]> --- this doesn't apply for me. any plans for an updated patch? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/5] powerpc/40x: Add AMCC PowerPC 405EZ to cputable
This adds the AMCC PowerPC 405EZ chip to the cputable
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/cputable.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index e70d048..b1eb834 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1277,6 +1277,19 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_4xx,
.platform = "ppc405",
},
+ {
+ /* 405EZ */
+ .pvr_mask = 0x,
+ .pvr_value = 0x4151,
+ .cpu_name = "405EZ",
+ .cpu_features = CPU_FTRS_40X,
+ .cpu_user_features = PPC_FEATURE_32 |
+ PPC_FEATURE_HAS_MMU | PPC_FEATURE_HAS_4xxMAC,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .machine_check = machine_check_4xx,
+ .platform = "ppc405",
+ },
{ /* default match */
.pvr_mask = 0x,
.pvr_value = 0x,
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] i2c: MPC8349E-mITX Power Management and GPIO expander driver
On Fri, Oct 10, 2008 at 09:58:44AM -0500, Kumar Gala wrote:
[...]
>>> is the plan to connect ppc_md.machine_shutdown() with this?
>>
>> You mean poweroff? It's already connected.
>>
>> + /* XXX: this is potentially racy, but there is no lock for
>> ppc_md */
>> + if (!ppc_md.power_off) {
>> + glob_mcu = mcu;
>> + ppc_md.power_off = mcu_power_off;
>> + dev_info(&client->dev, "will provide power-off
>> service\n");
>> + }
>
>
> uuh, yeah.. poweroff :)
>
> and look at that. Is this in Jean's queue?
Nope. Here's what Jean wrote:
On Wed, Oct 01, 2008 at 01:22:48PM +0200, Jean Delvare wrote:
> I do not have the time to review these patches (and, honestly, have no
> interest in them.) So I will not merge them but I have no objection to
> them being merged by somebody else.
So.. I think it could easily go through the powerpc tree.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/16] xics: rearrange file to group code by function
Now that xics_update_irq_servers is called only from init and hotplug
code, it becomes possible to clean up the ordering of functions in the
file, grouping them but the interfaces they implement.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
This patch is pure function reordering and comments.
This patch applies to -next. For prior kernels, there are 6 more lines
in xics_startup() that affect patch application.
Index: next.git/arch/powerpc/platforms/pseries/xics.c
===
--- next.git.orig/arch/powerpc/platforms/pseries/xics.c 2008-10-04
17:09:57.0 -0500
+++ next.git/arch/powerpc/platforms/pseries/xics.c 2008-10-04
17:39:02.0 -0500
@@ -9,7 +9,6 @@
* 2 of the License, or (at your option) any later version.
*/
-
#include
#include
#include
@@ -35,6 +34,8 @@
#include "xics.h"
#include "plpar_wrappers.h"
+static struct irq_host *xics_host;
+
#define XICS_IPI 2
#define XICS_IRQ_SPURIOUS 0
@@ -47,6 +48,20 @@
*/
#define IPI_PRIORITY 4
+static unsigned int default_server = 0xFF;
+static unsigned int default_distrib_server = 0;
+static unsigned int interrupt_server_size = 8;
+
+/* RTAS service tokens */
+static int ibm_get_xive;
+static int ibm_set_xive;
+static int ibm_int_on;
+static int ibm_int_off;
+
+
+/* Direct hardware low level accessors */
+
+/* The part of the interrupt presentation layer that we care about */
struct xics_ipl {
union {
u32 word;
@@ -65,22 +80,6 @@ struct xics_ipl {
static struct xics_ipl __iomem *xics_per_cpu[NR_CPUS];
-static unsigned int default_server = 0xFF;
-static unsigned int default_distrib_server = 0;
-static unsigned int interrupt_server_size = 8;
-
-static struct irq_host *xics_host;
-
-/* RTAS service tokens */
-static int ibm_get_xive;
-static int ibm_set_xive;
-static int ibm_int_on;
-static int ibm_int_off;
-
-
-/* Direct HW low level accessors */
-
-
static inline unsigned int direct_xirr_info_get(void)
{
int cpu = smp_processor_id();
@@ -110,7 +109,6 @@ static inline void direct_qirr_info(int
/* LPAR low level accessors */
-
static inline unsigned int lpar_xirr_info_get(void)
{
unsigned long lpar_rc;
@@ -152,59 +150,9 @@ static inline void lpar_qirr_info(int n_
}
-/* High level handlers and init code */
-
-static void xics_update_irq_servers(void)
-{
- int i, j;
- struct device_node *np;
- u32 ilen;
- const u32 *ireg, *isize;
- u32 hcpuid;
-
- /* Find the server numbers for the boot cpu. */
- np = of_get_cpu_node(boot_cpuid, NULL);
- BUG_ON(!np);
-
- ireg = of_get_property(np, "ibm,ppc-interrupt-gserver#s", &ilen);
- if (!ireg) {
- of_node_put(np);
- return;
- }
-
- i = ilen / sizeof(int);
- hcpuid = get_hard_smp_processor_id(boot_cpuid);
-
- /* Global interrupt distribution server is specified in the last
-* entry of "ibm,ppc-interrupt-gserver#s" property. Get the last
-* entry fom this property for current boot cpu id and use it as
-* default distribution server
-*/
- for (j = 0; j < i; j += 2) {
- if (ireg[j] == hcpuid) {
- default_server = hcpuid;
- default_distrib_server = ireg[j+1];
-
- isize = of_get_property(np,
- "ibm,interrupt-server#-size", NULL);
- if (isize)
- interrupt_server_size = *isize;
- }
- }
-
- of_node_put(np);
-}
+/* Interface to generic irq subsystem */
#ifdef CONFIG_SMP
-/*
- * XICS only has a single IPI, so encode the messages per CPU
- */
-struct xics_ipi_struct {
-unsigned long value;
- } cacheline_aligned;
-
-static struct xics_ipi_struct xics_ipi_message[NR_CPUS] __cacheline_aligned;
-
static int get_irq_server(unsigned int virq, unsigned int strict_check)
{
int server;
@@ -239,7 +187,6 @@ static int get_irq_server(unsigned int v
}
#endif
-
static void xics_unmask_irq(unsigned int virq)
{
unsigned int irq;
@@ -273,6 +220,13 @@ static void xics_unmask_irq(unsigned int
}
}
+static unsigned int xics_startup(unsigned int virq)
+{
+ /* unmask it */
+ xics_unmask_irq(virq);
+ return 0;
+}
+
static void xics_mask_real_irq(unsigned int irq)
{
int call_status;
@@ -309,28 +263,10 @@ static void xics_mask_irq(unsigned int v
xics_mask_real_irq(irq);
}
-static unsigned int xics_startup(unsigned int virq)
-{
- /* unmask it */
- xics_unmask_irq(virq);
- return 0;
-}
-
-static void xics_eoi_direct(unsigned int virq)
-{
- unsigned int irq = (unsigned int)irq_map[virq].hwirq;
-
- iosync();
- direct_xirr_info_set((0xff << 24) | irq);
-}
-
-
-static void xics_eoi_lpar(unsigned int virq)
+s
[PATCH 6/16] xics: trim includes
Trim unneeded includes from xics.c. We don't use signals or gfp flags, we use only OF functions and don't need prom, and the 8259 is now handled by our caller. Signed-off-by: Milton Miller <[EMAIL PROTECTED]> --- asm/smp.h gives us cpu mask accessors for !CONFIG_SMP, used in the next patch Index: work.git/arch/powerpc/platforms/pseries/xics.c === --- work.git.orig/arch/powerpc/platforms/pseries/xics.c 2008-08-07 03:41:08.0 -0500 +++ work.git/arch/powerpc/platforms/pseries/xics.c 2008-08-07 03:43:12.0 -0500 @@ -15,21 +15,18 @@ #include #include #include -#include #include -#include #include #include +#include #include -#include #include #include #include #include #include #include -#include #include "xics.h" #include "plpar_wrappers.h" ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 11/16] powerpc: mark xics ipi percpu
Its physically per-cpu, and we want the irq layer to treat it that way. Signed-off-by: Milton Miller <[EMAIL PROTECTED]> Index: next.git/arch/powerpc/platforms/pseries/xics.c === --- next.git.orig/arch/powerpc/platforms/pseries/xics.c 2008-10-04 23:54:18.0 -0500 +++ next.git/arch/powerpc/platforms/pseries/xics.c 2008-10-04 23:55:43.0 -0500 @@ -557,11 +557,11 @@ static void xics_request_ipi(void) */ set_irq_handler(ipi, handle_percpu_irq); if (firmware_has_feature(FW_FEATURE_LPAR)) - rc = request_irq(ipi, xics_ipi_action_lpar, IRQF_DISABLED, - "IPI", NULL); + rc = request_irq(ipi, xics_ipi_action_lpar, + IRQF_DISABLED|IRQF_PERCPU, "IPI", NULL); else - rc = request_irq(ipi, xics_ipi_action_direct, IRQF_DISABLED, - "IPI", NULL); + rc = request_irq(ipi, xics_ipi_action_direct, + IRQF_DISABLED|IRQF_PERCPU, "IPI", NULL); BUG_ON(rc); } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/16] xics: consolidate ipi message encode and decode
xics supports only one ipi per cpu, and expects software to use some
queue to know why the interrupt was sent. In Linux, we use a an array
of bitmaps indexed by cpu to identify the message. Currently the bits
are set in smp.c and decoded in xics.c, with the data structure in a
header file. Consolidate the code in xics.c similar to mpic and other
interrupt controllers.
Also, while making the the array static, the message word doesn't need
to be volatile as set_bit and test_clear_bit take care of it for us, and
put it under ifdef smp.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
iseries and powermac psurge have similar code due to only one ipi,
but they don't spread out the lines by cachelines for scalability
like pseries. Since that is one other platform per arch head, I
left the code replicated.
I kept smp_xics_cpu_setup in smp.c as the vpa init is unrelated.
Index: next.git/arch/powerpc/platforms/pseries/smp.c
===
--- next.git.orig/arch/powerpc/platforms/pseries/smp.c 2008-10-04
16:34:45.0 -0500
+++ next.git/arch/powerpc/platforms/pseries/smp.c 2008-10-04
16:37:39.0 -0500
@@ -37,7 +37,6 @@
#include
#include
#include
-#include "xics.h"
#include
#include
#include
@@ -49,6 +48,7 @@
#include "plpar_wrappers.h"
#include "pseries.h"
+#include "xics.h"
/*
@@ -105,36 +105,6 @@ static inline int __devinit smp_startup_
}
#ifdef CONFIG_XICS
-static inline void smp_xics_do_message(int cpu, int msg)
-{
- set_bit(msg, &xics_ipi_message[cpu].value);
- mb();
- xics_cause_IPI(cpu);
-}
-
-static void smp_xics_message_pass(int target, int msg)
-{
- unsigned int i;
-
- if (target < NR_CPUS) {
- smp_xics_do_message(target, msg);
- } else {
- for_each_online_cpu(i) {
- if (target == MSG_ALL_BUT_SELF
- && i == smp_processor_id())
- continue;
- smp_xics_do_message(i, msg);
- }
- }
-}
-
-static int __init smp_xics_probe(void)
-{
- xics_request_IPIs();
-
- return cpus_weight(cpu_possible_map);
-}
-
static void __devinit smp_xics_setup_cpu(int cpu)
{
if (cpu != boot_cpuid)
Index: next.git/arch/powerpc/platforms/pseries/xics.c
===
--- next.git.orig/arch/powerpc/platforms/pseries/xics.c 2008-10-04
16:36:09.0 -0500
+++ next.git/arch/powerpc/platforms/pseries/xics.c 2008-10-04
17:09:57.0 -0500
@@ -71,11 +71,6 @@ static unsigned int interrupt_server_siz
static struct irq_host *xics_host;
-/*
- * XICS only has a single IPI, so encode the messages per CPU
- */
-struct xics_ipi_struct xics_ipi_message[NR_CPUS] __cacheline_aligned;
-
/* RTAS service tokens */
static int ibm_get_xive;
static int ibm_set_xive;
@@ -201,6 +196,15 @@ static void xics_update_irq_servers(void
}
#ifdef CONFIG_SMP
+/*
+ * XICS only has a single IPI, so encode the messages per CPU
+ */
+struct xics_ipi_struct {
+unsigned long value;
+ } cacheline_aligned;
+
+static struct xics_ipi_struct xics_ipi_message[NR_CPUS] __cacheline_aligned;
+
static int get_irq_server(unsigned int virq, unsigned int strict_check)
{
int server;
@@ -387,7 +391,6 @@ static unsigned int xics_get_irq_lpar(vo
}
#ifdef CONFIG_SMP
-
static irqreturn_t xics_ipi_dispatch(int cpu)
{
WARN_ON(cpu_is_offline(cpu));
@@ -419,6 +422,33 @@ static irqreturn_t xics_ipi_dispatch(int
return IRQ_HANDLED;
}
+static inline void smp_xics_do_message(int cpu, int msg)
+{
+ set_bit(msg, &xics_ipi_message[cpu].value);
+ mb();
+ if (firmware_has_feature(FW_FEATURE_LPAR))
+ lpar_qirr_info(cpu, IPI_PRIORITY);
+ else
+ direct_qirr_info(cpu, IPI_PRIORITY);
+}
+
+void smp_xics_message_pass(int target, int msg)
+{
+ unsigned int i;
+
+ if (target < NR_CPUS) {
+ smp_xics_do_message(target, msg);
+ } else {
+ for_each_online_cpu(i) {
+ if (target == MSG_ALL_BUT_SELF
+ && i == smp_processor_id())
+ continue;
+ smp_xics_do_message(i, msg);
+ }
+ }
+}
+
+
static irqreturn_t xics_ipi_action_direct(int irq, void *dev_id)
{
int cpu = smp_processor_id();
@@ -436,15 +466,6 @@ static irqreturn_t xics_ipi_action_lpar(
return xics_ipi_dispatch(cpu);
}
-
-void xics_cause_IPI(int cpu)
-{
- if (firmware_has_feature(FW_FEATURE_LPAR))
- lpar_qirr_info(cpu, IPI_PRIORITY);
- else
- direct_qirr_info(cpu, IPI_PRIORITY);
-}
-
#endif /* CONFIG_SMP */
static void xics_set_cpu_priority(unsigned char cppr)
@@ -697,7 +718,7 @@ void __init xics_init_IRQ(void)
#ifdef CONFIG_SMP
-void xics_reque
[PATCH 2/16] xics: update default_server during migrate_irqs_away
Currently, every time we determine which irq server to use, we check if default_server, which is the id of the bootcpu, is still online. But default_server is a hardware cpu, not the logical cpu id needed to index cpu_online_map. Since the default server can only go offline during a cpu hotplug event, explicitly check the default server and choose the new one when we move irqs away from the cpu being offlined. This has the added benefit of only needing the boot_cpuid to be updated and not relying on the cpu being marked offline during migrate_irqs_away. Also, since xics_update_irq_servers only reads device tree information, we can call it before xics_init_host in xics_init_IRQ and then default_server will always be valid when we can reach get_irq_server via the host ops. Signed-off-by: Milton Miller <[EMAIL PROTECTED]> --- I realized the hard vs soft cpu id as I was writing the patch description. get_irq_server is called from unmask and set affinity. The effects of this bug would be the increased pathlength to walk the device tree in the unmask and set affinity methods, and possible failure to migrate irqs during cpu hotplug removal (not likely to be seen on until a sequence of remove and adds is performed). This check dates to 2.6.25 via de0723dcca6e593a12a259798a54eb0e82628fb8. Index: next.git/arch/powerpc/platforms/pseries/xics.c === --- next.git.orig/arch/powerpc/platforms/pseries/xics.c 2008-10-04 16:36:07.0 -0500 +++ next.git/arch/powerpc/platforms/pseries/xics.c 2008-10-04 16:36:09.0 -0500 @@ -208,9 +208,6 @@ static int get_irq_server(unsigned int v cpumask_t cpumask = irq_desc[virq].affinity; cpumask_t tmp = CPU_MASK_NONE; - if (! cpu_isset(default_server, cpu_online_map)) - xics_update_irq_servers(); - if (!distribute_irqs) return default_server; @@ -685,8 +682,8 @@ void __init xics_init_IRQ(void) if (found == 0) return; - xics_init_host(); xics_update_irq_servers(); + xics_init_host(); if (firmware_has_feature(FW_FEATURE_LPAR)) ppc_md.get_irq = xics_get_irq_lpar; @@ -779,6 +776,10 @@ void xics_migrate_irqs_away(void) int cpu = smp_processor_id(), hw_cpu = hard_smp_processor_id(); unsigned int irq, virq; + /* If we used to be the default server, move to the new "boot_cpuid" */ + if (hw_cpu == default_server) + xics_update_irq_servers(); + /* Reject any interrupt that was queued to us... */ xics_set_cpu_priority(0); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: remove non-dependent load fsl_booke PTE_64BIT
b38fd42ff46a4a31dced8533e8a6e549693500b6 added false dependencys to order the load of upper and lower halfs of the pte, but only adjusted whitespace instead of deleting the old load in the iside handler, letting the hardware see the non-dependent load. This patch removes the extra load. Signed-off-by: Milton Miller <[EMAIL PROTECTED]> --- Kumar, I think this is right from my inspection, please review. Index: next.git/arch/powerpc/kernel/head_fsl_booke.S === --- next.git.orig/arch/powerpc/kernel/head_fsl_booke.S 2008-10-05 02:40:38.0 -0500 +++ next.git/arch/powerpc/kernel/head_fsl_booke.S 2008-10-05 02:40:58.0 -0500 @@ -658,10 +658,6 @@ interrupt_base: bne 2f /* Bail if permission mismach */ -#ifdef CONFIG_PTE_64BIT - lwz r13,0(r12) -#endif - /* Jump to common TLB load point */ b finish_tlb_load ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 9/16] powerpc: eoi xics ipi by hand in kexec
EOI normally has the side effect of returning the cpu to the base
priority to recieve the next interrupt. This is actually controlled
by the top byte of the xirr register. When we are exiting the
kernel in kexec we must eoi the ipi for the next kernel because we
never return from the handler, but we want to leave interrupt
delivery blocked until the next kernel takes action.
Since the hardware ipi vector is fixed, its easiest to just do the
eoi explicitly.
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
Index: next.git/arch/powerpc/platforms/pseries/xics.c
===
--- next.git.orig/arch/powerpc/platforms/pseries/xics.c 2008-10-04
17:43:17.0 -0500
+++ next.git/arch/powerpc/platforms/pseries/xics.c 2008-10-04
21:56:17.0 -0500
@@ -757,25 +757,21 @@ void xics_teardown_cpu(void)
void xics_kexec_teardown_cpu(int secondary)
{
- unsigned int ipi;
- struct irq_desc *desc;
-
xics_teardown_cpu();
/*
-* we need to EOI the IPI
+* we take the ipi irq but and never return so we
+* need to EOI the IPI, but want to leave our priority 0
*
-* probably need to check all the other interrupts too
+* should we check all the other interrupts too?
* should we be flagging idle loop instead?
* or creating some task to be scheduled?
*/
- ipi = irq_find_mapping(xics_host, XICS_IPI);
- if (ipi == XICS_IRQ_SPURIOUS)
- return;
- desc = get_irq_desc(ipi);
- if (desc->chip && desc->chip->eoi)
- desc->chip->eoi(ipi);
+ if (firmware_has_feature(FW_FEATURE_LPAR))
+ lpar_xirr_info_set((0x00 << 24) | XICS_IPI);
+ else
+ direct_xirr_info_set((0x00 << 24) | XICS_IPI);
/*
* Some machines need to have at least one cpu in the GIQ,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, 2008-10-10 at 18:36 +0900, Paul Mundt wrote: > This is likely because some of those lists are subscribers only, so cross > posting is poor form. It makes sense to keep the discussion in one place, > and to send notification messages with a pointer to the list archives to > the other lists so folks can jump in if they really care. Splitting it > out doesn't help matters in the least, but unfortunately this is what > seems to happen the most when subscribers only lists are involved. Subscriber-only lists are broken. Just don't use them. -- David WoodhouseOpen Source Technology Centre [EMAIL PROTECTED] Intel Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: add DS1374 RTC support for the MPC837xE-MDS boards
On Oct 8, 2008, at 1:16 PM, Anton Vorontsov wrote: The RTC is sitting on the I2C1 bus at address 0x68. RTC interrupt signal is connected to the IPIC's EXT3 interrupt line. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- arch/powerpc/boot/dts/mpc8377_mds.dts |7 +++ arch/powerpc/boot/dts/mpc8378_mds.dts |7 +++ arch/powerpc/boot/dts/mpc8379_mds.dts |7 +++ 3 files changed, 21 insertions(+), 0 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Compact Flash on 8349mITX
On Fri, Oct 10, 2008 at 10:14:17AM +0800, Wang Jian wrote: > How 8349mITX's compact flash is wired? FYI, the schematics are openly available. http://www.freescale.com/files/32bit/hardware_tools/schematics/MPC8349EMITXESCH.pdf?WT_TYPE=Schematics&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Downloads > If it is wired using 8 bit data bus line, > without another patch, data transfer can't be done. It is wired that way: LBD[7:0]D[0:7] LBD[15:8] D[8:15] LBA[30..28] A[0..2] I.e. 16 bits for data. > Looking at logs Sam Sparks provided (without irq): > > ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) > > it seems data transfer failed. Well, w/o IRQs everything is OK. I think it's just a bogus message after the interrupt issues. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Geert Uytterhoeven wrote: > > Were did you actually sent them to? Apparently you sent them to each mailing > list (at least linux-embedded and linuxppc-dev) _separately_ (or using bcc). I sent them separately to linux-embedded, linuxppc-dev, and linux-arm-kernel. Those three groups seemed to have the developers who were most likely to provide a motivated review and constructive response; unfortunately, some are subscriber-only and so I couldn't just cross-post. I was expecting some criticism for this, but I'm not sure there's a good alternative. I don't like the idea of posting in so many places, but PWM is a pretty expansive topic: just about every SoC under the sun has some ability to do PWM, and people use the signals for all sorts of things. Both have to be taken into consideration by the API, hence I need lots of review and feedback. There isn't a lot of traffic on linux-embedded, and I'm not sure how many people who read linux-arm-kernel also read linuxppc-dev. Lkml's topic coverage is huge, so I don't know how many hardcore embedded developers I would encounter there. I was hoping for a round of feedback at a lower level before pushing anything upstream like that. > Hence different people may give the same comments without knowing about each > other, and you may have to explain everything multiple times. Hasn't been a problem so far. I posted the first version of the code on l-a-k, and got some feedback on the pwm_device API and a lot of feedback on the way users wanted to use the API to realize applications. I incorporated all of it, and in this "release" I broadened the exposure per recommendations received from l-a-k. > I would go for lkml and linux-embedded, _together_. So, you're saying the same thing as me, basically. But leaving out the lists with very high ratios of device-specific domain knowledge, which is important for the backend parts of what I'm proposing. Blackfin's PWM-capable peripherals work differently from those commonly found in ARM and PPC, for example. I haven't run anything by the MIPS or AVR guys, but I'm guessing they would have something to add, too. I'm beginning to appreciate what everyone must have had to deal with for GPIO. :) b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: disable CHRP and PMAC support in various defconfigs
Because CHRP and PMAC are by default enabled, several non-CHRP and non-PMAC PowerPC defconfigs will have these Kconfig options set erroneously. Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> --- arch/powerpc/configs/83xx/asp8347_defconfig |2 ++ arch/powerpc/configs/83xx/mpc8313_rdb_defconfig |2 ++ arch/powerpc/configs/83xx/mpc8315_rdb_defconfig |2 ++ arch/powerpc/configs/83xx/mpc832x_mds_defconfig |2 ++ arch/powerpc/configs/83xx/mpc832x_rdb_defconfig |2 ++ arch/powerpc/configs/83xx/mpc834x_itx_defconfig |2 ++ arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig |2 ++ arch/powerpc/configs/83xx/mpc834x_mds_defconfig |2 ++ arch/powerpc/configs/83xx/mpc836x_mds_defconfig |2 ++ arch/powerpc/configs/83xx/mpc836x_rdk_defconfig |2 ++ arch/powerpc/configs/83xx/mpc837x_mds_defconfig |2 ++ arch/powerpc/configs/83xx/mpc837x_rdb_defconfig |2 ++ arch/powerpc/configs/83xx/sbc834x_defconfig |2 ++ arch/powerpc/configs/86xx/gef_sbc610_defconfig|5 - arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig |2 ++ arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig |2 ++ arch/powerpc/configs/86xx/sbc8641d_defconfig |2 ++ arch/powerpc/configs/ep8248e_defconfig|2 ++ arch/powerpc/configs/mpc8272_ads_defconfig|2 ++ arch/powerpc/configs/mpc83xx_defconfig|2 ++ arch/powerpc/configs/pq2fads_defconfig|2 ++ 21 files changed, 44 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/configs/83xx/asp8347_defconfig b/arch/powerpc/configs/83xx/asp8347_defconfig index 6638f5a..0b1fa20 100644 --- a/arch/powerpc/configs/83xx/asp8347_defconfig +++ b/arch/powerpc/configs/83xx/asp8347_defconfig @@ -164,6 +164,8 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_PMAC is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set diff --git a/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig b/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig index df125f3..b7eae2b 100644 --- a/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig +++ b/arch/powerpc/configs/83xx/mpc8313_rdb_defconfig @@ -163,6 +163,8 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_PMAC is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set diff --git a/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig b/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig index 6e0e08c..b0a27a6 100644 --- a/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig +++ b/arch/powerpc/configs/83xx/mpc8315_rdb_defconfig @@ -163,6 +163,8 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_PMAC is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set diff --git a/arch/powerpc/configs/83xx/mpc832x_mds_defconfig b/arch/powerpc/configs/83xx/mpc832x_mds_defconfig index d6e204a..ad825bc 100644 --- a/arch/powerpc/configs/83xx/mpc832x_mds_defconfig +++ b/arch/powerpc/configs/83xx/mpc832x_mds_defconfig @@ -163,6 +163,8 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_PMAC is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set diff --git a/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig b/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig index 1f3d343..3826750 100644 --- a/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig +++ b/arch/powerpc/configs/83xx/mpc832x_rdb_defconfig @@ -163,6 +163,8 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_PMAC is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set diff --git a/arch/powerpc/configs/83xx/mpc834x_itx_defconfig b/arch/powerpc/configs/83xx/mpc834x_itx_defconfig index 4686c21..90aab34 100644 --- a/arch/powerpc/configs/83xx/mpc834x_itx_defconfig +++ b/arch/powerpc/configs/83xx/mpc834x_itx_defconfig @@ -163,6 +163,8 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_PMAC is not set # CONFIG_MPC5121_ADS is not set # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set diff --git a/arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig b/arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig index f11c25e..7458a24 100644 --- a/arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig +++ b/arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig @@ -163,6 +163,8 @@ CONFIG_CLASSIC_RCU=y # CONFIG_PPC_MULTIPLATFORM=y CONFIG_CLASSIC32=y +# CONFIG_PPC_CHRP is not set +# CONFIG_PPC_PMAC is not set # CONFIG_MPC5121_ADS is not set # CONFIG_
Re: [PATCH 2/5] powerpc/40x: Add support for PowerPC 405EZ Acadia board
On Thursday 04 September 2008, Josh Boyer wrote: > arch/powerpc/platforms/40x/Kconfig | 14 + > arch/powerpc/platforms/40x/Makefile |1 + > arch/powerpc/platforms/40x/acadia.c | 56 > +++ acadia.c is 99% identical malaku.c and kilauea.c, right? Wouldn't this be a good moment to start the ppc405_simple platform like you have for 440? Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add legacy PCI access via sysfs
On Thursday, October 9, 2008 7:50 pm Benjamin Herrenschmidt wrote: > This patch adds support for legacy_io and legacy_mem files in > bus class directories in sysfs for powerpc > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- > > This is version 2, slightly different approach for getting at VGA > memory which works a lot better with bridges providing a separate > ISA Memory hole (which is the case of most of them). > > Also tested on a variety of hardware with a little tool using x86emu > to run VGA BIOSes, do VBE calls and whack text mode. > > This patch relies on its generic counterpart, posted previously > being applied first. > > Jesse, due to the dependency, it's better if we have both in > the powerpc tree -or- both in the PCI tree, what do you think > is best ? Either that or I have to delay applying it to powerpc > until you get the generic part in. Ah I was worried the first one might need a respin, but it applied fine, so I'll go ahead and apply this one too. Thanks, Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc/40x: Add support for PowerPC 405EZ Acadia board
On Fri, Oct 10, 2008 at 05:58:54PM +0200, Arnd Bergmann wrote: >On Thursday 04 September 2008, Josh Boyer wrote: > >> arch/powerpc/platforms/40x/Kconfig | 14 + >> arch/powerpc/platforms/40x/Makefile |1 + >> arch/powerpc/platforms/40x/acadia.c | 56 >> +++ > >acadia.c is 99% identical malaku.c and kilauea.c, right? > >Wouldn't this be a good moment to start the ppc405_simple platform like >you have for 440? It would, except for timing. I didn't get a chance to convert 40x over before the merge window opened and I'd rather not try to cram it in during the 1 week we have. And Acadia is ported now (and has been for a few weeks), so getting that in seemed to be an easier route to take. I do have plans to convert 40x for 2.6.29, and if there are major objections I can hold off Acadia until then. I just don't like holding back board ports for the "next re-org". josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] dma: add new dma_mapping_ops API sync_page
On Fri, 2008-10-10 at 14:46 +1100, Benjamin Herrenschmidt wrote: > > > A virtual address will typically be needed to perform the flush; why > > > pass the bus address? > > > Because it is a sync API. You want to make sure that a physical memory > > area is in sync with the caches, not the virtual address. This > > distinction can become important in the event where the page is mapped > > multiple times in the memory and the architecture does not take care of > > synchronizing the multiple mapping, the dma_mapping_ops code should be > > able to synchronize the multiple mapping. In most case it would be easy > > of course to go from virtual address to the page address, but not if the > > page is in high memory ... > > Well, not really. IE, you are right that a dma_addr_t or a struct page > is the way to go but for the wrong reasons :-) > > All mappings should be coherent. The powerpc architecture is pretty > strict with that. The only known violation is the instruction cache on > 44x but that's irrelevant to your problem. > > Thus, -any- virtual address will do. Good! That certainly simplify the code. > However, you may not have a virtual address. You may get into a > situation where the page isn't in the linear mapping and needs to be > kmap'ed for the sync to happen. > > Now, using PCI_DRAM_OFFSET in bus_to_page() is incorrect here with > Becky's new set of changes. You need to get the offset properly using > the accessor she provides (I don't have the name off the top of my > head). > Totally agree with that. In the last set of patch I committed (which I need to re-commit because I need to use vmalloc in dma-noncoherent.c) I removed most of the reference to PCI_DRAM_OFFSET. The only reference to it remaining is in virt_to_bus which is called by dma_cache_sync. I did not see an accessor that can be used in dma-mapping.h (the accessor API I have seen is private to dma.c and dma-noncoherent.c), I would be happy to use it if there really is one though. I could add another 2 APIs to dma_mapping_ops which converts a page to/from its bus address, what do you think? Remi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc/40x: Add support for PowerPC 405EZ Acadia board
On Friday 10 October 2008, Josh Boyer wrote: > It would, except for timing. I didn't get a chance to convert > 40x over before the merge window opened and I'd rather not try > to cram it in during the 1 week we have. And Acadia is ported > now (and has been for a few weeks), so getting that in seemed > to be an easier route to take. > > I do have plans to convert 40x for 2.6.29, and if there are > major objections I can hold off Acadia until then. I just > don't like holding back board ports for the "next re-org". > How about just renaming 40x/acadia.c to 40x/ppc405_simple.c without the merge? Then you can merge in the other platforms as time permits and any other new ones can start using the _simple platform right away. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: reserve two DMA channels for audio in MPC8610 HPCD device tree
The Freescale Elo DMA driver binds to all DMA channels in the device tree that
are compatible with "fsl,eloplus-dma-channel". This conflicts with the sound
drivers for the MPC8610 HPCD. On this board, the SSI uses two DMA channels and
therefore those channels are not available for general purpose use. We
change the compatible properties for these channels "fsl,ssi-dma-channel".
This works because the sound drivers don't actually check the compatible
property when it grabs channels.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8610_hpcd.dts |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 0f3a36e..3f4c610 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -237,7 +237,7 @@
dma00: [EMAIL PROTECTED] {
compatible = "fsl,mpc8610-dma-channel",
- "fsl,eloplus-dma-channel";
+ "fsl,ssi-dma-channel";
cell-index = <0>;
reg = <0x0 0x80>;
interrupt-parent = <&mpic>;
@@ -245,7 +245,7 @@
};
dma01: [EMAIL PROTECTED] {
compatible = "fsl,mpc8610-dma-channel",
- "fsl,eloplus-dma-channel";
+ "fsl,ssi-dma-channel";
cell-index = <1>;
reg = <0x80 0x80>;
interrupt-parent = <&mpic>;
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: document the "fsl, ssi-dma-channel" compatible property
The "fsl,ssi-dma-channel" compatible property is used to specify a DMA channel on the Freescale Elo DMA controller that should be used exclusively by the Freescale SSI audio controller. When a property is marked as such, the Elo DMA driver will ignore it, and so it will be available for the sound drivers. Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> --- Documentation/powerpc/dts-bindings/fsl/dma.txt | 13 +++-- Documentation/powerpc/dts-bindings/fsl/ssi.txt | 20 ++-- 2 files changed, 25 insertions(+), 8 deletions(-) diff --git a/Documentation/powerpc/dts-bindings/fsl/dma.txt b/Documentation/powerpc/dts-bindings/fsl/dma.txt index 86826df..cc45311 100644 --- a/Documentation/powerpc/dts-bindings/fsl/dma.txt +++ b/Documentation/powerpc/dts-bindings/fsl/dma.txt @@ -20,7 +20,7 @@ Required properties: - compatible: compatible list, contains 2 entries, first is "fsl,CHIP-dma-channel", where CHIP is the processor (mpc8349, mpc8350, etc.) and the second is -"fsl,elo-dma-channel" +"fsl,elo-dma-channel". However, see note below. - reg : - cell-index: dma channel index starts at 0. @@ -82,7 +82,7 @@ Required properties: - compatible: compatible list, contains 2 entries, first is "fsl,CHIP-dma-channel", where CHIP is the processor (mpc8540, mpc8560, etc.) and the second is -"fsl,eloplus-dma-channel" +"fsl,eloplus-dma-channel". However, see note below. - cell-index: dma channel index starts at 0. - reg : - interrupts: @@ -125,3 +125,12 @@ Example: interrupts = <17 2>; }; }; + +Note on DMA channel compatible properties: The compatible property must say +"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA +driver (fsldma). Any DMA channel used by fsldma cannot be used by another +DMA driver, such as the SSI sound drivers for the MPC8610. Therefore, any DMA +channel that should be used for another driver should not use +"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel". For the SSI drivers, for +example, the compatible property should be "fsl,ssi-dma-channel". See ssi.txt +for more information. diff --git a/Documentation/powerpc/dts-bindings/fsl/ssi.txt b/Documentation/powerpc/dts-bindings/fsl/ssi.txt index 5d98413..a2d9639 100644 --- a/Documentation/powerpc/dts-bindings/fsl/ssi.txt +++ b/Documentation/powerpc/dts-bindings/fsl/ssi.txt @@ -24,12 +24,12 @@ Required properties: "rj-master" - r.j., SSI is clock master "ac97-slave" - AC97 mode, SSI is clock slave "ac97-master" - AC97 mode, SSI is clock master -- fsl,playback-dma: phandle to a DMA node for the DMA channel to use for - playback of audio. This is typically dictated by SOC - design. See the notes below. -- fsl,capture-dma: phandle to a DMA node for the DMA channel to use for - capture (recording) of audio. This is typically dictated - by SOC design. See the notes below. +- fsl,playback-dma: phandle to a node for the DMA channel to use for +playback of audio. This is typically dictated by SOC +design. See the notes below. +- fsl,capture-dma: phandle to a node for the DMA channel to use for +capture (recording) of audio. This is typically dictated +by SOC design. See the notes below. Optional properties: - codec-handle : phandle to a 'codec' node that defines an audio @@ -51,3 +51,11 @@ playback and DMA channel 1 for capture. SSI2 must use DMA channel 2 for playback and DMA channel 3 for capture. The developer can choose which DMA controller to use, but the channels themselves are hard-wired. The purpose of these two properties is to represent this hardware design. + +The device tree nodes for the DMA channels that are referenced by +"fsl,playback-dma" and "fsl,capture-dma" must be marked as compatible with +"fsl,ssi-dma-channel". The SOC-specific compatible string (e.g. +"fsl,mpc8610-dma-channel") can remain. If these nodes are left as +"fsl,elo-dma-channel" or "fsl,eloplus-dma-channel", then the generic Elo DMA +drivers (fsldma) will attempt to use them, and it will conflict with the +sound drivers. -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/3] USB support for MPC8360E-MDS and RDK boards
Hi all, The patches don't (build)depend on anything else, so if they're OK I think it would be great to have them in the powerpc-next. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] powerpc/83xx: add USB Host/Gadget support for the MPC8360E-MDS boards
- 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.
The work is loosely based on Li Yang's patch[1], which is used
to support peripheral mode only.
[1] http://ozlabs.org/pipermail/linuxppc-dev/2008-August/061357.html
The s-o-b line of the original patch preserved here.
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc836x_mds.dts | 43 ++-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 52 -
2 files changed, 92 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts
b/arch/powerpc/boot/dts/mpc836x_mds.dts
index ada8446..74528ce 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -69,8 +69,18 @@
};
[EMAIL PROTECTED],0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
device_type = "board-control";
reg = <1 0 0x8000>;
+ ranges = <0 1 0 0x8000>;
+
+ bcsr13: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360mds-bcsr-gpio";
+ reg = <0xd 1>;
+ gpio-controller;
+ };
};
};
@@ -191,10 +201,21 @@
};
[EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
reg = <0x1400 0x100>;
+ ranges = <0 0x1400 0x100>;
device_type = "par_io";
num-ports = <7>;
+ qe_pio_b: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360-qe-pario-bank",
+"fsl,mpc8323-qe-pario-bank";
+ reg = <0x18 0x18>;
+ gpio-controller;
+ };
+
pio1: [EMAIL PROTECTED] {
pio-map = <
/* port pin dir open_drain assignment has_irq */
@@ -278,6 +299,15 @@
};
};
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8360-qe-gtm",
+"fsl,qe-gtm", "fsl,gtm";
+ reg = <0x440 0x40>;
+ clock-frequency = <13200>;
+ interrupts = <12 13 14 15>;
+ interrupt-parent = <&qeic>;
+ };
+
[EMAIL PROTECTED] {
cell-index = <0>;
compatible = "fsl,spi";
@@ -297,11 +327,20 @@
};
[EMAIL PROTECTED] {
- compatible = "qe_udc";
+ compatible = "fsl,mpc8360-qe-usb",
+"fsl,mpc8323-qe-usb";
reg = <0x6c0 0x40 0x8b00 0x100>;
interrupts = <11>;
interrupt-parent = <&qeic>;
- mode = "slave";
+ fsl,fullspeed-clock = "clk21";
+ fsl,lowspeed-clock = "brg9";
+ gpios = <&qe_pio_b 2 0 /* USBOE */
+&qe_pio_b 3 0 /* USBTP */
+&qe_pio_b 8 0 /* USBTN */
+&qe_pio_b 9 0 /* USBRP */
+&qe_pio_b 11 0 /* USBRN */
+&bcsr135 0 /* SPEED */
+&bcsr134 1>; /* POWER */
};
enet0: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c
b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 9d46e5b..4e69f7b 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
@@ -127,9 +128,58 @@ static void __init mpc836x_mds_setup_arch(void)
iounmap(immap);
}
- iounmap(bcsr_regs);
of_node_put(np);
}
+#ifdef CONFIG_QE_USB
+ np = of_find_compatible_node(NULL, NULL, "fsl,mpc8323-qe-usb");
+ if (np) {
+ const char *mode = of_get_property(np, "mode", NULL);
+
+ par_io_config_pin(1, 2, 1, 0, 3, 0); /* USBOE */
+ par_io_config_pin(1, 3, 1, 0, 3, 0); /* USBTP */
+
[PATCH 1/3] powerpc: add driver for simple GPIO banks
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 <[EMAIL PROTECTED]>
---
Documentation/powerpc/dts-bindings/fsl/board.txt | 30
arch/powerpc/platforms/Kconfig | 11 ++
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/simple_gpio.c| 157 ++
arch/powerpc/sysdev/simple_gpio.h| 13 ++
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 74ae6f1..e97877f 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;
+- #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:
+
+ [EMAIL PROTECTED],0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "board-control";
+ reg = <1 0 0x8000>;
+ ranges = <0 1 0 0x8000>;
+
+ bcsr13: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360mds-bcsr-gpio";
+ reg = <0xd 1>;
+ gpio-controller;
+ };
+ };
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 71845d7..e4482b5 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -303,4 +303,15 @@ config OF_RTC
source "arch/powerpc/sysdev/bestcomm/Kconfig"
+config SIMPLE_GPIO
+ bool "Support for simple, memory-mapped GPIO controllers"
+ depends on PPC
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
+ help
+ Say Y here to support simple, memory-mapped GPIO controllers.
+ These are usually BCSRs used to control board's switches, LEDs,
+ chip-selects, Ethernet/USB PHY's power and various other small
+ on-board peripherals.
+
endmenu
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index a90054b..cd06d7e 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_4xx) += uic.o
obj-$(CONFIG_4xx_SOC) += ppc4xx_soc.o
obj-$(CONFIG_XILINX_VIRTEX)+= xilinx_intc.o
obj-$(CONFIG_OF_RTC) += of_rtc.o
+obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
endif
diff --git a/arch/powerpc/sysdev/simple_gpio.c
b/arch/powerpc/sysdev/simple_gpio.c
new file mode 100644
index 000..ef0a452
--- /dev/null
+++ b/arch/powerpc/sysdev/simple_gpio.c
@@ -0,0 +1,157 @@
+/*
+ * Simple Memory-Mapped GPIOs
+ *
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "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->r
[PATCH 3/3] powerpc/83xx: add USB Host support for the MPC8360E-RDK boards
Simply add the usb node to support USB host on the MPC8360E-RDK
boards.
Currently U-Boot doesn't fill the clock-frequency property for
timer nodes, so for now we have to fill it manually.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc836x_rdk.dts | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts
b/arch/powerpc/boot/dts/mpc836x_rdk.dts
index 89c9202..b4f3a17 100644
--- a/arch/powerpc/boot/dts/mpc836x_rdk.dts
+++ b/arch/powerpc/boot/dts/mpc836x_rdk.dts
@@ -214,8 +214,23 @@
reg = <0x440 0x40>;
interrupts = <12 13 14 15>;
interrupt-parent = <&qeic>;
- /* filled by u-boot */
- clock-frequency = <0>;
+ clock-frequency = <1>;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8360-qe-usb",
+"fsl,mpc8323-qe-usb";
+ reg = <0x6c0 0x40 0x8b00 0x100>;
+ interrupts = <11>;
+ interrupt-parent = <&qeic>;
+ fsl,fullspeed-clock = "clk21";
+ gpios = <&qe_pio_b 2 0 /* USBOE */
+&qe_pio_b 3 0 /* USBTP */
+&qe_pio_b 8 0 /* USBTN */
+&qe_pio_b 9 0 /* USBRP */
+&qe_pio_b 11 0 /* USBRN */
+&qe_pio_e 20 0 /* SPEED */
+&qe_pio_e 21 1 /* POWER */>;
};
[EMAIL PROTECTED] {
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc/40x: Add support for PowerPC 405EZ Acadia board
On Fri, Oct 10, 2008 at 06:16:55PM +0200, Arnd Bergmann wrote: >On Friday 10 October 2008, Josh Boyer wrote: >> It would, except for timing. I didn't get a chance to convert >> 40x over before the merge window opened and I'd rather not try >> to cram it in during the 1 week we have. And Acadia is ported >> now (and has been for a few weeks), so getting that in seemed >> to be an easier route to take. >> >> I do have plans to convert 40x for 2.6.29, and if there are >> major objections I can hold off Acadia until then. I just >> don't like holding back board ports for the "next re-org". >> > >How about just renaming 40x/acadia.c to 40x/ppc405_simple.c >without the merge? Then you can merge in the other platforms >as time permits and any other new ones can start using the >_simple platform right away. Hm. That sounds like a really good idea. I'll try go get that done over the weekend and send out a rework of just that patch. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: performance: memcpy vs. __copy_tofrom_user
Paul Mackerras wrote: > Very interesting. Can you work out where memcpy is being called on > the network data? I wouldn't have expected that. Ok. I've some results. I done two test with different MTU. In both cases, about 0.5GB in total has been transfered over network. Large blocks. The test didn't trace a "shallow copy", where occasionally memcpy() is also in use. 1) MTU=1500 (on both host and mpc8313) * achieved throughput: 22MB/s (from mpc), 16MB/s (to mpc) * total size of copied data by memcpy() was 37.6MB * 96% of that has been copied by skb_clone(): 787758 times in blocks of 48B. * about 3% of that has been copied by skb_copy_bits(): 1013 times, the block size vary but rather bigger like 1300B. * about 1% of that has been copied by eth_header(): 80248 times in blocks of 6B (). 2) MTU=9000 (on both host and mpc8313) * achieved throughput: 50MB/s (from mpc), 44MB/s (to mpc) * total size of copied data by memcpy() was 6.4MB * 97% of that has been copied by skb_clone(): 134260 times in blocks of 48B. * 3% (whole rest) has been copied by eth_header(): 32912 times in blocks of 6B. Conclusion. Need for optimized memcpy() for blocks 48B and 6B :). Joke. I said earlier, that I got about 10% boost when I replaced memcpy() by __copy_tofrom_user(). It was the case with MTU 9000 because I work with that setting in my environment. I don't know when __copy_tofrom_user get faster than memcpy on other cpus than mpc8313, but on mpc8313 48B blocks are more suitable for __copy_tofrom_user. Dominik ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 09:03:34AM -0500, Bill Gatliff wrote: > Paul Mundt wrote: > > This is likely because some of those lists are subscribers only, so cross > > posting is poor form. It makes sense to keep the discussion in one place, > > and to send notification messages with a pointer to the list archives to > > the other lists so folks can jump in if they really care. Splitting it > > out doesn't help matters in the least, but unfortunately this is what > > seems to happen the most when subscribers only lists are involved. > > Alright, then maybe I can do this when I post the "final" changeset for > review: > cross-post to lkml and linux-embedded, and then post one short note on l-a-k, > linuxppc-dev and elsewhere that refers those interested to the actual content. > I can live with that. > linux-arm-kernel is the only one that is subscribers only out of that list, according to MAINTAINERS. If rmk wants to mandate a broken policy, that's perfectly fine, just don't expect the rest of the kernel community to tolerate it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add legacy PCI access via sysfs
On Thursday, October 9, 2008 7:50 pm Benjamin Herrenschmidt wrote: > This patch adds support for legacy_io and legacy_mem files in > bus class directories in sysfs for powerpc > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > --- Applied to linux-next, thanks. Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 08:59:08AM -0500, Bill Gatliff wrote: > There isn't a lot of traffic on linux-embedded, and I'm not sure how many > people > who read linux-arm-kernel also read linuxppc-dev. Lkml's topic coverage is > huge, so I don't know how many hardcore embedded developers I would encounter > there. I was hoping for a round of feedback at a lower level before pushing > anything upstream like that. > This isn't your problem. If people are interested in general embedded topics, they should be subscribed to the list. If they aren't, it's their loss. Cross posting to every potentially relevant list is a complete waste of time, and only helps to split out the discussion so nothing actually gets accomplished in a centralized location. > Hasn't been a problem so far. I posted the first version of the code on > l-a-k, > and got some feedback on the pwm_device API and a lot of feedback on the way > users wanted to use the API to realize applications. I incorporated all of > it, > and in this "release" I broadened the exposure per recommendations received > from > l-a-k. > This is precisely the problem. Stuff that gets "reviewed" on linux-arm-kernel gets reviewed for ARM only. There has been way too much crap that has been pushed into the kernel under the guise of being generic and "reviewed" that has broken _every_ architecture _except_ ARM. If you want to refute this, go look at the recent fiasco with musb, which still hasn't been solved properly, primarily because the ARM people couldn't be bothered using grep. This crap happens all the time, because stuff is reviewed and merged in private, and the only time anyone else notices is when their platform suddenly stops building. Your first version should have been to linux-embedded and linux-kernel. If you want to alert the linux-arm-kernel people to the fact that a discussion is going on in this area, then feel free to post a notification to the list with references to the relevant lists. There is no reason why public lists should have to dig in to private archives to try and play catch up. > So, you're saying the same thing as me, basically. But leaving out the lists > with very high ratios of device-specific domain knowledge, which is important > for the backend parts of what I'm proposing. Blackfin's PWM-capable > peripherals > work differently from those commonly found in ARM and PPC, for example. I > haven't run anything by the MIPS or AVR guys, but I'm guessing they would have > something to add, too. > > I'm beginning to appreciate what everyone must have had to deal with for > GPIO. :) > The GPIO mess was broken in different ways, which we're still trying to fix today. The GPIO discussion did happen out on public lists though, so all of the discussion on that was visible, even if the end result left something to be desired. If you're trying to pitch a generic API and doing your review on a private list, you've already lost. If you're talking about things that only effect arch/arm, feel free to do whatever you want. As soon as you step outside of that structure, you have to follow common convention, or you risk breaking things all over the place. I can't remember the last time I saw a "generic" API reviewed on linux-arm-kernel that didn't end up breaking every other architecture in existence. This is true for drivers, also. Better yet, don't bother dropping the ARM depedency until you've posted to a public list. Some of us are pretty damn tired of cleaning up after the ARM people. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_of_platform: fix no irq handling
On Wed, Oct 08, 2008 at 11:59:59AM +0200, Geert Uytterhoeven wrote: > On Wed, 8 Oct 2008, Alan Cox wrote: > > On Wed, 08 Oct 2008 09:40:54 +0100 > > David Woodhouse <[EMAIL PROTECTED]> wrote: > > > > > On Tue, 2008-10-07 at 10:37 +0100, Alan Cox wrote: > > > > Zero means no IRQ. Any platform with bits of code left over exposing IRQ > > > > 0 is already not supported by lots of driver code including libata. > > > > > > ...and must implement some kind of interrupt remapping crap just to work > > > around this bogus design decision. > > > > I'll leave you to argue with Linus about that, but since that was the > > decision back in 2005 (for good C reasons) we can safely rely on it. > > `git grep NO_IRQ include arch/*/include' is still quite enlightening... > In the case of PCI where IRQ is unsigned int, that's certainly bogus. The problem originates on platforms where a 1:1 mapping between vector and IRQ exists, where 0 is a valid value. This then needs to be remapped in to an IRQ cookie that has a non-0 value in order to be assigned to dev->irq. Despite whether this is bogus or not, there's not much to be done about it. Those of us with vectored IRQ platforms generally have enough sources that the use of IRQ-0 doesn't matter, and it's not worth the headache of setting up the remapping crap. As an example, on SH, IRQ-0 is mapped to vector 0x200. It is '0' for symbolic reasons only. It's just as easy to pad out irq_desc and treat it as an off-by-1 to work around all of code that assumes NO_IRQ == 0. There is enough code in the kernel today that makes the non-zero IRQ cookie assumption that platforms that do otherwise are simply broken. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/83xx: add NAND support for the MPC8360E-RDK boards
The StMicro NAND chip (512Mbit, 64MB) is connected to the local bus,
the first local bus' user-programmable machine is configured by the
firmware to work with NAND chips.
QE GPIO pin is used to poll the NAND's Ready-Not-Busy signal.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc836x_rdk.dts | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts
b/arch/powerpc/boot/dts/mpc836x_rdk.dts
index b4f3a17..10237dc 100644
--- a/arch/powerpc/boot/dts/mpc836x_rdk.dts
+++ b/arch/powerpc/boot/dts/mpc836x_rdk.dts
@@ -398,6 +398,18 @@
device-width = <1>;
};
+ [EMAIL PROTECTED],0 {
+ compatible = "fsl,upm-nand";
+ reg = <1 0 1>;
+ fsl,upm-addr-offset = <16>;
+ fsl,upm-cmd-offset = <8>;
+ gpios = <&qe_pio_e 18 0>;
+
+ flash {
+ compatible = "stm,nand512-a";
+ };
+ };
+
[EMAIL PROTECTED],0 {
device_type = "display";
compatible = "fujitsu,MB86277", "fujitsu,mint";
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] 64 bit csum_partial_copy_generic
Thanks for doing this. A few comments below, but first, can you clarify what your and George Fulk's roles were in producing this? I had the impression George had written the code, and if that's the case, you need to put a "From: George Fulk <...>" line as the first line of your mail when you re-send the patch. I wrote the patch, George wrote some very useful testcases. So a Tested-by: George Fulk <[EMAIL PROTECTED]> line would be appropriate, not sure if that line ever really caught on. As for the technical comments, I agree with all of them and will incorporate them into the next version. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: disable CHRP and PMAC support in various defconfigs
On Oct 10, 2008, at 10:35 AM, Timur Tabi wrote: Because CHRP and PMAC are by default enabled, several non-CHRP and non-PMAC PowerPC defconfigs will have these Kconfig options set erroneously. Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> --- arch/powerpc/configs/83xx/asp8347_defconfig |2 ++ arch/powerpc/configs/83xx/mpc8313_rdb_defconfig |2 ++ arch/powerpc/configs/83xx/mpc8315_rdb_defconfig |2 ++ arch/powerpc/configs/83xx/mpc832x_mds_defconfig |2 ++ arch/powerpc/configs/83xx/mpc832x_rdb_defconfig |2 ++ arch/powerpc/configs/83xx/mpc834x_itx_defconfig |2 ++ arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig |2 ++ arch/powerpc/configs/83xx/mpc834x_mds_defconfig |2 ++ arch/powerpc/configs/83xx/mpc836x_mds_defconfig |2 ++ arch/powerpc/configs/83xx/mpc836x_rdk_defconfig |2 ++ arch/powerpc/configs/83xx/mpc837x_mds_defconfig |2 ++ arch/powerpc/configs/83xx/mpc837x_rdb_defconfig |2 ++ arch/powerpc/configs/83xx/sbc834x_defconfig |2 ++ arch/powerpc/configs/86xx/gef_sbc610_defconfig|5 - arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig |2 ++ arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig |2 ++ arch/powerpc/configs/86xx/sbc8641d_defconfig |2 ++ arch/powerpc/configs/ep8248e_defconfig|2 ++ arch/powerpc/configs/mpc8272_ads_defconfig|2 ++ arch/powerpc/configs/mpc83xx_defconfig|2 ++ arch/powerpc/configs/pq2fads_defconfig|2 ++ 21 files changed, 44 insertions(+), 1 deletions(-) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: reserve two DMA channels for audio in MPC8610 HPCD device tree
On Oct 10, 2008, at 11:52 AM, Timur Tabi wrote: The Freescale Elo DMA driver binds to all DMA channels in the device tree that are compatible with "fsl,eloplus-dma-channel". This conflicts with the sound drivers for the MPC8610 HPCD. On this board, the SSI uses two DMA channels and therefore those channels are not available for general purpose use. We change the compatible properties for these channels "fsl,ssi-dma- channel". This works because the sound drivers don't actually check the compatible property when it grabs channels. Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> --- arch/powerpc/boot/dts/mpc8610_hpcd.dts |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: document the "fsl, ssi-dma-channel" compatible property
On Oct 10, 2008, at 11:52 AM, Timur Tabi wrote: The "fsl,ssi-dma-channel" compatible property is used to specify a DMA channel on the Freescale Elo DMA controller that should be used exclusively by the Freescale SSI audio controller. When a property is marked as such, the Elo DMA driver will ignore it, and so it will be available for the sound drivers. Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> --- Documentation/powerpc/dts-bindings/fsl/dma.txt | 13 +++-- Documentation/powerpc/dts-bindings/fsl/ssi.txt | 20 + +-- 2 files changed, 25 insertions(+), 8 deletions(-) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] i2c: MPC8349E-mITX Power Management and GPIO expander driver
On Sep 23, 2008, at 9:13 AM, Anton Vorontsov wrote: On MPC8349E-mITX, MPC8315E-RDB and MPC837x-RDB boards there is a Freescale MC9S08QG8 (MCU) chip with the custom firmware pre-programmed. The chip is used to power-off the board by the software, and to control some GPIO pins. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- drivers/i2c/chips/Kconfig| 11 ++ drivers/i2c/chips/Makefile |1 + drivers/i2c/chips/mcu_mpc8349emitx.c | 209 + + 3 files changed, 221 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/chips/mcu_mpc8349emitx.c applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Remove old workaround for arch/ppc vs. arch/powerpc from Makefile
There is an old workaround in the sysdev/Makefile for dealing with arch/ppc vs. arch/powerpc compiles. This is no longer needed as arch/ppc is dead. Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> --- diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile index 55618ba..a44709a 100644 --- a/arch/powerpc/sysdev/Makefile +++ b/arch/powerpc/sysdev/Makefile @@ -38,15 +38,12 @@ ifeq ($(CONFIG_PCI),y) obj-$(CONFIG_4xx) += ppc4xx_pci.o endif -# Temporary hack until we have migrated to asm-powerpc -ifeq ($(ARCH),powerpc) obj-$(CONFIG_CPM) += cpm_common.o obj-$(CONFIG_CPM2) += cpm2.o cpm2_pic.o obj-$(CONFIG_QUICC_ENGINE) += cpm_common.o obj-$(CONFIG_PPC_DCR) += dcr.o obj-$(CONFIG_8xx) += mpc8xx_pic.o cpm1.o obj-$(CONFIG_UCODE_PATCH) += micropatch.o -endif ifeq ($(CONFIG_SUSPEND),y) obj-$(CONFIG_6xx) += 6xx-suspend.o ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Paul Mundt wrote: > On Fri, Oct 10, 2008 at 09:03:34AM -0500, Bill Gatliff wrote: >> Paul Mundt wrote: >>> This is likely because some of those lists are subscribers only, so cross >>> posting is poor form. It makes sense to keep the discussion in one place, >>> and to send notification messages with a pointer to the list archives to >>> the other lists so folks can jump in if they really care. Splitting it >>> out doesn't help matters in the least, but unfortunately this is what >>> seems to happen the most when subscribers only lists are involved. >> Alright, then maybe I can do this when I post the "final" changeset for >> review: >> cross-post to lkml and linux-embedded, and then post one short note on l-a-k, >> linuxppc-dev and elsewhere that refers those interested to the actual >> content. >> I can live with that. >> > linux-arm-kernel is the only one that is subscribers only out of that > list, according to MAINTAINERS. If rmk wants to mandate a broken policy, > that's perfectly fine, just don't expect the rest of the kernel community > to tolerate it. Problem is, the rest of the kernel community is the one who takes it in the, ahem, server when I cross-post. And since my reference platform is currently ARM, I can't leave l-a-k out. b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
Paul Mundt wrote: >> Hasn't been a problem so far. I posted the first version of the code on >> l-a-k, >> and got some feedback on the pwm_device API and a lot of feedback on the way >> users wanted to use the API to realize applications. I incorporated all of >> it, >> and in this "release" I broadened the exposure per recommendations received >> from >> l-a-k. >> > This is precisely the problem. Stuff that gets "reviewed" on > linux-arm-kernel gets reviewed for ARM only. There has been way too much > crap that has been pushed into the kernel under the guise of being > generic and "reviewed" that has broken _every_ architecture _except_ ARM. > If you want to refute this, go look at the recent fiasco with musb, which > still hasn't been solved properly, primarily because the ARM people > couldn't be bothered using grep. This crap happens all the time, because > stuff is reviewed and merged in private, and the only time anyone else > notices is when their platform suddenly stops building. I'll note for the record that I didn't post on linux-arm-kernel only. Otherwise, we wouldn't be having this discussion. :) > Your first version should have been to linux-embedded and linux-kernel. > If you want to alert the linux-arm-kernel people to the fact that a > discussion is going on in this area, then feel free to post a > notification to the list with references to the relevant lists. There is > no reason why public lists should have to dig in to private archives to > try and play catch up. I'm not asking anyone to do that. Just review the patches posted to the list of your choice. Or, don't review them. Up to you. My next update will be the one where I formally request a review with intent to merge into mainline. That one will go to linux-embedded only, with notifications sent elsewhere as indicated per community request. I don't have a problem with that. I can't change history, but I'm doing what you are asking of me otherwise. > If you're trying to pitch a generic API and doing your review on a > private list, you've already lost. If you're talking about things that > only effect arch/arm, feel free to do whatever you want. As soon as you > step outside of that structure, you have to follow common convention, or > you risk breaking things all over the place. I can't remember the last > time I saw a "generic" API reviewed on linux-arm-kernel that didn't end > up breaking every other architecture in existence. This is true for > drivers, also. Better yet, don't bother dropping the ARM depedency until > you've posted to a public list. Again, we wouldn't be having this exchange if I was pitching a generic API on a private list because I sense that you aren't an l-a-k subscriber. :) It's true that the early posts were on the ARM list, but you can see that I didn't stop there. I started there because the platform that supports the API right now is ARM, and so I wanted that part to be right before moving upstream. That process worked: I received feedback on the ARM-specific bits which improved the API as a whole. The diversity of ARM machines plus Blackfin, PPC, MIPS, X, Y, Z and PDQ machines was more than I could deal with until now. Right, enough of that. I really don't want to get distracted from the code. I'll readily admit to not handing the mailing list submissions right, and I resolve to do a better job effective immediately. But I think that's the last that I need to say on the subject. If it makes you feel any better, I'll stop responding to your replies unless they come to me via linux-embedded. :) > Some of us are pretty damn tired of cleaning up after the ARM people. Sounds like the ARM people need you to drop by and help them do a better job. Sounds like you could directly benefit from their doing a better job, too. Win-win. b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: Make ppc32 actually respect the boot cpu id for !CONFIG_SMP
Previosly the FDT header field boot_cpuid_phys wasn't actually used
on ppc32. Instead the physical boot cpuid was assumed to be 0 for
!CONFIG_SMP.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
set boot_cpuid_phys to phys, not logical
- k
arch/powerpc/include/asm/smp.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index c092f84..1866cec 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -93,7 +93,7 @@ extern void __cpu_die(unsigned int cpu);
#else
/* for UP */
-#define hard_smp_processor_id()0
+#define hard_smp_processor_id()get_hard_smp_processor_id(0)
#define smp_setup_cpu_maps()
#endif /* CONFIG_SMP */
@@ -122,6 +122,7 @@ static inline int get_hard_smp_processor_id(int cpu)
static inline void set_hard_smp_processor_id(int cpu, int phys)
{
+ boot_cpuid_phys = phys;
}
#endif /* !CONFIG_SMP */
#endif /* !CONFIG_PPC64 */
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Remove old workaround for arch/ppc vs. arch/powerpc from Makefile
On Oct 10, 2008, at 1:53 PM, Josh Boyer wrote: There is an old workaround in the sysdev/Makefile for dealing with arch/ppc vs. arch/powerpc compiles. This is no longer needed as arch/ppc is dead. Signed-off-by: Josh Boyer <[EMAIL PROTECTED]> --- Acked-by: Kumar Gala <[EMAIL PROTECTED]> - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, 2008-10-10 at 09:04 -0500, Bill Gatliff wrote: > Jon Smirl wrote: > > > What do the device tree deities have to say about PWM support? > > Dunno. What lists are they on? :) > Perhaps [EMAIL PROTECTED] too. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1] IB/ehca: Disallow creating UC QP with SRQ
thanks, applied -- it didn't apply to the latest tree, because of the
flush CQE changes, so I merged it manually as below -- let me know if
this is wrong:
commit 0540bbbe455e123a1692d26205ad1a29983883b0
Author: Hoang-Nam Nguyen <[EMAIL PROTECTED]>
Date: Fri Oct 10 14:40:39 2008 -0700
IB/ehca: Don't allow creating UC QP with SRQ
This patch prevents a UC QP to be created attached to an SRQ, since
current firmware does not support this feature.
Signed-off-by: Michael Faath <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c
b/drivers/infiniband/hw/ehca/ehca_qp.c
index 4dbe287..40b578d 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -502,6 +502,12 @@ static struct ehca_qp *internal_create_qp(
if (init_attr->srq) {
my_srq = container_of(init_attr->srq, struct ehca_qp, ib_srq);
+ if (qp_type == IB_QPT_UC) {
+ ehca_err(pd->device, "UC with SRQ not supported");
+ atomic_dec(&shca->num_qps);
+ return ERR_PTR(-EINVAL);
+ }
+
has_srq = 1;
parms.ext_type = EQPT_SRQBASE;
parms.srq_qpn = my_srq->real_qp_num;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] remove bogus ppc_select syscall
On Fri, 2008-10-10 at 18:43 +1100, Paul Mackerras wrote: > > It's me or the patch is whitespaces damaged ? > > Please don't apply Arnd's patch. As I said, all we need is this > one-line change in arch/powerpc/include/asm/systbl.h: > > -SYSX_SPU(sys_select,ppc32_select,ppc_select) > +SYSX_SPU(sys_select,ppc32_select,sys_select) Ok, so you want to keep compat with the old stuff. Note that we still have this weird thing that on 64-bit kernels, we don't provide this. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add legacy PCI access via sysfs
On Fri, 2008-10-10 at 09:02 -0700, Jesse Barnes wrote: > Ah I was worried the first one might need a respin, but it applied > fine, so > I'll go ahead and apply this one too. Let's hope it doesn't collide with the pending powerpc.git merge... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7] PPC440EPx gpio driver
On Fri, 10 Oct 2008 16:02:32 +0200 "Stefan Roese" <[EMAIL PROTECTED]> wrote: > On Friday 10 October 2008, Steven A. Falco wrote: > > This patch adds support for the GPIO functions of PPC40x and PPC44x > > SOCs. > > Looks good. But you should change the subject line now. Its not only > a PPC440EPx gpio driver but ppc4xx. Also please add "powerpc/4xx: " > to the beginning of the subject line. And you should always send 4xx > related patches to the subsystem maintainer too (CC), in this case > Josh Boyer. > > > Signed-off-by: Steve Falco > > You can add my: > > Acked-by: Stefan Roese <[EMAIL PROTECTED]> > > in the next patch revision. :) Tested on the warp (440EP). Acked-by: Sean MacLennan <[EMAIL PROTECTED]> Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_of_platform: fix no irq handling
Anton Vorontsov wrote: > On Mon, Oct 06, 2008 at 03:41:19PM -0500, Matt Sealey wrote: >> There is a simple problem with the patch which is that an "IRQ 0" can and >> does >> actually exist on a bunch of platforms, at least to the best of my knowledge. >> >> Checking for -1 (which means for definite, no irq at all, because it is >> totally unambiguous, as a -1 IRQ numbering is "impossible") is more correct. > > This was discussed years ago. > > http://lkml.org/lkml/2005/11/22/159 > http://lkml.org/lkml/2005/11/22/227 > Would this break any existing platforms? If so, can those be fixed together or does it become a much bigger problem that way? Thanks. -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16
Elbert, Just CCing in the ehea maintainers... Jan-Bernd, Thomas, Christoph: can you help with this query? Mikey System log shows a lot of "ehea: Error", see below, during system start up. Not sure what it is. I'd like to understand this, could someone points me the direction? My "Machine Type and Model ... ST9146802SS" reported from lscfg (p6 blade). OS is RHEL 5.2. Kernel level is 2.6.18-92.1.10.el5. Thanks. E. Hu ehea.modinfo filename: /lib/modules/2.6.18-92.1.10.el5/kernel/drivers/net/ehea/ehea.ko version: EHEA_0076-05 description: IBM eServer HEA Driver author: Christoph Raisch <[EMAIL PROTECTED]> license: GPL srcversion: C481DB79B4694F406CF4AA7 depends: vermagic: 2.6.18-92.1.10.el5 SMP mod_unload gcc-4.1 parm: num_tx_qps:Number of TX-QPS (int) parm: msg_level:msg_level (int) parm: prop_carrier_state:Propagate carrier state of physical port to stack. 1:yes, 0:no. Default = 0 (int) parm: rq3_entries:Number of entries for Receive Queue 3 [2^x - 1], x = [6..14]. Default = 1023) (int) parm: rq2_entries:Number of entries for Receive Queue 2 [2^x - 1], x = [6..14]. Default = 1023) (int) parm: rq1_entries:Number of entries for Receive Queue 1 [2^x - 1], x = [6..14]. Default = 4095) (int) parm: sq_entries: Number of entries for the Send Queue [2^x - 1], x = [6..14]. Default = 1023) (int) parm: use_mcs: 0:NAPI, 1:Multiple receive queues, Default = 0 (int) parm: lro_max_aggr: LRO: Max packets to be aggregated. Default = 64 (int) parm: use_lro: Large Receive Offload, 1: enable, 0: disable, Default = 0 (int) module_sig: 883f3504886ebc8736cb7d2578e3b1112b7ab09e3b2c69b141d16d1bbbd51ab063f7955335a49e80a0ba218c849673e067f7c0ccc9d7353cc1ce05997 system log Sep 29 09:35:35 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 09:35:35 newhamburg kernel: ehea CQE adr=c001ddbc1400 ofs= 2000408e Sep 29 09:35:35 newhamburg kernel: ehea CQE adr=c001ddbc1410 ofs=0010 d6ec002a 0400 Sep 29 09:35:35 newhamburg kernel: ehea CQE adr=c001ddbc1420 ofs=0020 Sep 29 09:35:35 newhamburg kernel: ehea CQE adr=c001ddbc1430 ofs=0030 Sep 29 09:40:10 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 09:40:10 newhamburg kernel: ehea CQE adr=c001dd9d2800 ofs= 2000408e Sep 29 09:40:10 newhamburg kernel: ehea CQE adr=c001dd9d2810 ofs=0010 d6ec002a 0800 Sep 29 09:40:10 newhamburg kernel: ehea CQE adr=c001dd9d2820 ofs=0020 Sep 29 09:40:10 newhamburg kernel: ehea CQE adr=c001dd9d2830 ofs=0030 Sep 29 10:08:17 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 10:08:17 newhamburg kernel: ehea CQE adr=c001dd9eb600 ofs= 2000408e Sep 29 10:08:17 newhamburg kernel: ehea CQE adr=c001dd9eb610 ofs=0010 d6ec002a 0600 Sep 29 10:08:17 newhamburg kernel: ehea CQE adr=c001dd9eb620 ofs=0020 Sep 29 10:08:17 newhamburg kernel: ehea CQE adr=c001dd9eb630 ofs=0030 Sep 29 10:21:51 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 10:21:51 newhamburg kernel: ehea CQE adr=c001dd9e2300 ofs= 2000408e Sep 29 10:21:51 newhamburg kernel: ehea CQE adr=c001dd9e2310 ofs=0010 d6ec002a 0300 Sep 29 10:21:51 newhamburg kernel: ehea CQE adr=c001dd9e2320 ofs=0020 Sep 29 10:21:51 newhamburg kernel: ehea CQE adr=c001dd9e2330 ofs=0030 Sep 29 16:16:23 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 16:16:23 newhamburg kernel: ehea CQE adr=c001ddb9a800 ofs= 03000263 408040e0 Sep 29 16:16:23 newhamburg kernel: ehea CQE adr=c001ddb9a810 ofs=0010 e10f002a 0800 Sep 29 16:16:23 newhamburg kernel: ehea CQE adr=c001ddb9a820 ofs=0020 Sep 29 16:16:23 newhamburg kernel: ehea CQE adr=c001ddb9a830 ofs=0030 Sep 29 21:50:04 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 29 21:50:04 newhamburg kernel: ehea CQE adr=c001dd9c0700 ofs= 20804076 Sep 29 21:50:04 newhamburg kernel: ehea CQE adr=c001dd9c0710 ofs=0010 fb42002a 0700 Sep 29 21:50:04 newhamburg kernel: ehea CQE adr=c001dd9c0720 ofs=0020 Sep 29 21:50:04 newhamburg kernel: ehea CQE adr=c001dd9c0730 ofs=0030 Sep 30 03:55:49 newhamburg kernel: ehea: Error in ehea_treat_poll_error: CQE Error for QP 16 Sep 30 03:55:49 ne
