* [PATCH 5/5] ibmebus: More speaking error return code in ibmebus_store_probe()
From: Joachim Fenkes @ 2007-09-25 12:13 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-Dev, LKML
Cc: Thomas Klein, Arnd Bergmann, Jan-Bernd Themann, Paul Mackerras,
Christoph Raisch, Stefan Roscher
In-Reply-To: <200709251410.29780.fenkes@de.ibm.com>
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
arch/powerpc/kernel/ibmebus.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 379472f..8c08a98 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -270,10 +270,10 @@ static ssize_t ibmebus_store_probe(struct bus_type *bus,
return -ENOMEM;
if (bus_find_device(&ibmebus_bus_type, NULL, path,
- ibmebus_match_path)) {
+ ibmebus_match_path)) {
printk(KERN_WARNING "%s: %s has already been probed\n",
__FUNCTION__, path);
- rc = -EINVAL;
+ rc = -EEXIST;
goto out;
}
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] add Altivec/VMX state to coredumps
From: Kumar Gala @ 2007-09-25 12:39 UTC (permalink / raw)
To: Mark Nelson; +Cc: linuxppc-dev
In-Reply-To: <46F88896.50706@au1.ibm.com>
On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote:
> Update dump_task_altivec() (that has so far never been put to use)
> so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
> and VRSAVE) in the same format as the ptrace get_vrregs() and add
> the appropriate glue typedefs and #defines to
> include/asm-powerpc/elf.h for it to work.
Is there some way to tell if the core dump has altivec registers
state in it?
I'm wondering how we distinguish a core dump w/altivec state vs one
with SPE state.
- k
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Kumar Gala @ 2007-09-25 12:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: PowerPC dev list, Greg KH, Linus Torvalds, Roland McGrath
In-Reply-To: <18168.62378.472571.655865@cargo.ozlabs.ibm.com>
On Sep 25, 2007, at 6:40 AM, Paul Mackerras wrote:
> Linus,
>
> Please do
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
>
> to get a patch from Roland McGrath that fixes a user-triggerable oops
> on 64-bit powerpc.
>
> Thanks,
> Paul.
Should this also go to -stable?
- k
>
> arch/powerpc/kernel/process.c | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> commit 474f81967217f3bec2389ae913da72641f2c40e3
> Author: Roland McGrath <roland@redhat.com>
> Date: Mon Sep 24 16:52:44 2007 -0700
>
> [POWERPC] Ensure FULL_REGS on exec
>
> When PTRACE_O_TRACEEXEC is used, a ptrace call to fetch the
> registers at
> the PTRACE_EVENT_EXEC stop (PTRACE_PEEKUSR) will oops in
> CHECK_FULL_REGS.
> With recent versions, "gdb --args /bin/sh -c 'exec /bin/true'"
> and "run" at
> the (gdb) prompt is sufficient to produce this. I also have
> written an
> isolated test case, see https://bugzilla.redhat.com/
> show_bug.cgi?id=301791#c15.
>
> This change fixes the problem by clearing the low bit of
> pt_regs.trap in
> start_thread so that FULL_REGS is true again. This is correct
> since all of
> the GPRs that "full" refers to are cleared in start_thread.
>
> Signed-off-by: Roland McGrath <roland@redhat.com>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-09-25 12:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Greg KH, Linus Torvalds, Roland McGrath
In-Reply-To: <24149ACB-D786-4415-99A8-117FAC9936E6@kernel.crashing.org>
Kumar Gala writes:
> Should this also go to -stable?
It turns out that it's not triggerable (as an oops) from userspace in
2.6.22 and earlier. Commit 1b6610d6 of Ben H's took out #ifdef
CONFIG_PPC32 around a couple of CHECK_FULL_REGS calls, which is what
made it triggerable on ppc64. We have an interesting difference
between ppc32 and ppc64 in our CHECK_FULL_REGS implementation - it's a
BUG_ON on 64-bit but just a printk on 32-bit. So on 32-bit someone
could use it to spam the logs but not to actually crash the system.
So yes, I guess it should go to -stable once Linus takes it, but it's
a much less serious vulnerability in 2.6.22 and earlier than I first
thought (since it's only 32-bit, and just a user-triggerable printk).
And yes we should consolidate the CHECK_FULL_REGS implementations as a
WARN_ON with a counter to limit how many we do.
Paul.
^ permalink raw reply
* Re: AMCC yosemite 440ep PCI slot doesn't work.
From: Stefan Roese @ 2007-09-25 13:21 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200709250718.51824.sr@denx.de>
On Tuesday 25 September 2007, Stefan Roese wrote:
> On Tuesday 25 September 2007, Andrew Liu wrote:
> > I have tested it on linux-2.6.19 which is from AMCC website , linux
> > 2.6.21.7 which is from linux mainline and linux-2.6.23.rc7 which is
> > from git://www.denx.de/git/linux-2.6-denx.git
> > Have the same problem.
> > I don't understand, why after enabling this PCI interrupts. in so
> > short time, produce 100,000 interrupt request (25: 100000 UIC0
> > Level eth2).
>
> Because the interrupt is somehow not acknowledged in the PCI device.
>
> I will test this on my Yosemite and let you know.
I just tested on my Yellowstone, which is nearly identical to the Yosemite.
And it works just fine with an Intel EEPRO/100.
Could you test another PCI board (ethernet, IDE, USB...)? Or do you have
access to another Yosemite or Yellowstone board?
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* PaSemi DMA API for Linux
From: Samuel Zahnd @ 2007-09-25 12:30 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
Hi embedded people,
we have a PaSemi (PA6T-1682) CPU is use with Linux and CFE. I wonder if
anybody has experience with the DMA engine of the device. Some examples or
an API would be particularly usefull.
Thanks,
Samuel Zahnd
---
Supercomputing Systems AG Direct +41 43 456 1622
Technoparkstrasse 1 Phone +41 43 456 1600
CH-8005 Zürich Fax +41 43 456 1610
www.scs.ch samuel.zahnd(at)scs.ch
[-- Attachment #2: Type: text/html, Size: 2057 bytes --]
^ permalink raw reply
* Re: 2.6.23-rc6-mm1 -- powerpc link failure
From: Andy Whitcroft @ 2007-09-25 13:40 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20070919174403.GC3115@uranus.ravnborg.org>
On Wed, Sep 19, 2007 at 07:44:03PM +0200, Sam Ravnborg wrote:
> On Wed, Sep 19, 2007 at 10:28:48AM +0100, Andy Whitcroft wrote:
> > I am seeing this strange link error from a PowerMac G5 (powerpc):
> >
> > [...]
> > KSYM .tmp_kallsyms2.S
> > AS .tmp_kallsyms2.o
> > LD vmlinux.o
> > ld: dynreloc miscount for fs/built-in.o, section .opd
> > ld: can not edit opd Bad value
> > make: *** [vmlinux.o] Error 1
>
> We have had this issue before.
> Try to see:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=045e72acf16054c4ed2760e9a8edb19a08053af1
>
> Here it was caused by a weak declaration that was superflous.
>
> I expect the workaround to be equally simple this time - or I hope so.
Yep, will investigate this as suggested. As this problem seems to
persist thru 2.6.23-rc8-mm1 I will report it again there and my
findings.
-apw
^ permalink raw reply
* MPC85xx_MDS: Patches to support QE, UCCs and SPI
From: Anton Vorontsov @ 2007-09-25 14:31 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
These patches needed to make QE, UCCs and SPI work on MPC8568E-MDS.
Patchset is against galak/powerpc.git master branch.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH 1/7] [POWERPC] mpc85xx_mds: select QUICC_ENGINE
From: Anton Vorontsov @ 2007-09-25 14:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/85xx/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index b8476b2..cf815b2 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -25,7 +25,7 @@ config MPC85xx_CDS
config MPC85xx_MDS
bool "Freescale MPC85xx MDS"
select DEFAULT_UIMAGE
-# select QUICC_ENGINE
+ select QUICC_ENGINE
help
This option enables support for the MPC85xx MDS board
--
1.5.0.6
^ permalink raw reply related
* [PATCH 2/7] [POWERPC] Fix QEIC->MPIC cascading
From: Anton Vorontsov @ 2007-09-25 14:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
set_irq_chained_handler overwrites MPIC's handle_irq function
(handle_fasteoi_irq) thus MPIC never gets eoi event from the
cascaded IRQ. This situation hangs MPIC on MPC8568E.
Patch adds flow level "end" handler to the MPIC, and QEIC calls
it when QEIC's interrupt processing finished.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/mpic.c | 3 +++
arch/powerpc/sysdev/qe_lib/qe_ic.c | 6 ++++++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8de29f2..bee2d5b 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -846,6 +846,7 @@ static struct irq_chip mpic_irq_chip = {
.mask = mpic_mask_irq,
.unmask = mpic_unmask_irq,
.eoi = mpic_end_irq,
+ .end = mpic_end_irq,
.set_type = mpic_set_irq_type,
};
@@ -854,6 +855,7 @@ static struct irq_chip mpic_ipi_chip = {
.mask = mpic_mask_ipi,
.unmask = mpic_unmask_ipi,
.eoi = mpic_end_ipi,
+ .end = mpic_end_ipi,
};
#endif /* CONFIG_SMP */
@@ -864,6 +866,7 @@ static struct irq_chip mpic_irq_ht_chip = {
.mask = mpic_mask_irq,
.unmask = mpic_unmask_ht_irq,
.eoi = mpic_end_ht_irq,
+ .end = mpic_end_ht_irq,
.set_type = mpic_set_irq_type,
};
#endif /* CONFIG_MPIC_U3_HT_IRQS */
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index 55e6f39..8e743e0 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -328,6 +328,9 @@ void qe_ic_cascade_low(unsigned int irq, struct irq_desc *desc)
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
+
+ if (desc->chip->end)
+ desc->chip->end(irq);
}
void qe_ic_cascade_high(unsigned int irq, struct irq_desc *desc)
@@ -337,6 +340,9 @@ void qe_ic_cascade_high(unsigned int irq, struct irq_desc *desc)
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
+
+ if (desc->chip->end)
+ desc->chip->end(irq);
}
void __init qe_ic_init(struct device_node *node, unsigned int flags)
--
1.5.0.6
^ permalink raw reply related
* [PATCH 3/7] [POWERPC] QEIC: implement low+high multiplexed IRQ chained handler
From: Anton Vorontsov @ 2007-09-25 14:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
For MPC8568E low and high QEIC lines routed to the single MPIC
input, thus low and high sources should be demultiplexed.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/qe_lib/qe_ic.c | 34 ++++++++++++++++++++++++++++------
1 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index 8e743e0..0ecb614 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -345,6 +345,22 @@ void qe_ic_cascade_high(unsigned int irq, struct irq_desc *desc)
desc->chip->end(irq);
}
+static void qe_ic_cascade_muxed(unsigned int irq, struct irq_desc *desc)
+{
+ struct qe_ic *qe_ic = desc->handler_data;
+ unsigned int cascade_irq;
+
+ cascade_irq = qe_ic_get_high_irq(qe_ic);
+ if (cascade_irq == NO_IRQ)
+ cascade_irq = qe_ic_get_low_irq(qe_ic);
+
+ if (cascade_irq != NO_IRQ)
+ generic_handle_irq(cascade_irq);
+
+ if (desc->chip->end)
+ desc->chip->end(irq);
+}
+
void __init qe_ic_init(struct device_node *node, unsigned int flags)
{
struct qe_ic *qe_ic;
@@ -404,12 +420,18 @@ void __init qe_ic_init(struct device_node *node, unsigned int flags)
qe_ic_write(qe_ic->regs, QEIC_CICR, temp);
- set_irq_data(qe_ic->virq_low, qe_ic);
- set_irq_chained_handler(qe_ic->virq_low, qe_ic_cascade_low);
-
- if (qe_ic->virq_high != NO_IRQ) {
- set_irq_data(qe_ic->virq_high, qe_ic);
- set_irq_chained_handler(qe_ic->virq_high, qe_ic_cascade_high);
+ if (qe_ic->virq_high == qe_ic->virq_low) {
+ set_irq_data(qe_ic->virq_low, qe_ic);
+ set_irq_chained_handler(qe_ic->virq_low, qe_ic_cascade_muxed);
+ } else {
+ set_irq_data(qe_ic->virq_low, qe_ic);
+ set_irq_chained_handler(qe_ic->virq_low, qe_ic_cascade_low);
+
+ if (qe_ic->virq_high != NO_IRQ) {
+ set_irq_data(qe_ic->virq_high, qe_ic);
+ set_irq_chained_handler(qe_ic->virq_high,
+ qe_ic_cascade_high);
+ }
}
printk("QEIC (%d IRQ sources) at %p\n", NR_QE_IC_INTS, qe_ic->regs);
--
1.5.0.6
^ permalink raw reply related
* [PATCH 4/7] [POWERPC] QE pario: support for MPC85xx layout
From: Anton Vorontsov @ 2007-09-25 14:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
8 bytes padding required to match MPC85xx registers layout.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/qe_lib/qe_io.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe_io.c b/arch/powerpc/sysdev/qe_lib/qe_io.c
index e32b45b..d566e89 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_io.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_io.c
@@ -36,6 +36,9 @@ struct port_regs {
__be32 cpdir2; /* Direction register */
__be32 cppar1; /* Pin assignment register */
__be32 cppar2; /* Pin assignment register */
+#ifdef CONFIG_MPC85xx
+ u8 pad[8];
+#endif
};
static struct port_regs *par_io = NULL;
--
1.5.0.6
^ permalink raw reply related
* [PATCH 5/7] [POWERPC] mpc8568mds: update dts to be able to use UCCs
From: Anton Vorontsov @ 2007-09-25 14:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
1. UCC1's RX_DV pin is 16, not 15;
2. UCC1's phy is at 0x7, not 0x1. Schematics says 0x7, and recent
u-boot also using 0x7.
3. Use gianfar's (eTSEC) mdio bus. This is hardware default setup.
4. tx-clock should be CLK16 (GE125, PB31);
5. phy-connection-type is RGMII-ID;
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8568mds.dts | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index c472a4b..1d082fb 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -95,10 +95,10 @@
device_type = "mdio";
compatible = "gianfar";
reg = <24520 20>;
- phy0: ethernet-phy@0 {
+ phy0: ethernet-phy@7 {
interrupt-parent = <&mpic>;
interrupts = <1 1>;
- reg = <0>;
+ reg = <7>;
device_type = "ethernet-phy";
};
phy1: ethernet-phy@1 {
@@ -286,7 +286,7 @@
4 1a 2 0 2 0 /* RxD7 */
4 0b 1 0 2 0 /* TX_EN */
4 18 1 0 2 0 /* TX_ER */
- 4 0f 2 0 2 0 /* RX_DV */
+ 4 10 2 0 2 0 /* RX_DV */
4 1e 2 0 2 0 /* RX_ER */
4 11 2 0 2 0 /* RX_CLK */
4 13 1 0 2 0 /* GTX_CLK */
@@ -377,10 +377,10 @@
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = <0>;
- tx-clock = <19>;
- phy-handle = <&qe_phy0>;
- phy-connection-type = "gmii";
+ tx-clock = <20>;
pio-handle = <&pio1>;
+ phy-handle = <&phy0>;
+ phy-connection-type = "rgmii-id";
};
ucc@3000 {
@@ -399,10 +399,10 @@
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = <0>;
- tx-clock = <14>;
- phy-handle = <&qe_phy1>;
- phy-connection-type = "gmii";
+ tx-clock = <20>;
pio-handle = <&pio2>;
+ phy-handle = <&phy1>;
+ phy-connection-type = "rgmii-id";
};
mdio@2120 {
@@ -414,10 +414,10 @@
/* These are the same PHYs as on
* gianfar's MDIO bus */
- qe_phy0: ethernet-phy@00 {
+ qe_phy0: ethernet-phy@07 {
interrupt-parent = <&mpic>;
interrupts = <1 1>;
- reg = <0>;
+ reg = <7>;
device_type = "ethernet-phy";
};
qe_phy1: ethernet-phy@01 {
--
1.5.0.6
^ permalink raw reply related
* [PATCH 6/7] [POWERPC] mpc85xx_mds: reset UCC ethernet properly
From: Anton Vorontsov @ 2007-09-25 14:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
Apart from that the current code doesn't compile it's also
meaningless with regard to the MPC8568E-MDS' BCSR.
This patch used to reset UCCs properly.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 28 ++++++++++++++++------------
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index c379286..5de409b 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -107,18 +107,22 @@ static void __init mpc85xx_mds_setup_arch(void)
}
if (bcsr_regs) {
- u8 bcsr_phy;
-
- /* Reset the Ethernet PHY */
- bcsr_phy = in_be8(&bcsr_regs[9]);
- bcsr_phy &= ~0x20;
- out_be8(&bcsr_regs[9], bcsr_phy);
-
- udelay(1000);
-
- bcsr_phy = in_be8(&bcsr_regs[9]);
- bcsr_phy |= 0x20;
- out_be8(&bcsr_regs[9], bcsr_phy);
+#define BCSR_UCC1_GETH_EN (0x1 << 7)
+#define BCSR_UCC2_GETH_EN (0x1 << 7)
+#define BCSR_UCC1_MODE_MSK (0x3 << 4)
+#define BCSR_UCC2_MODE_MSK (0x3 << 0)
+
+ /* Turn off UCC1 & UCC2 */
+ clrbits8(&bcsr_regs[8], BCSR_UCC1_GETH_EN);
+ clrbits8(&bcsr_regs[9], BCSR_UCC2_GETH_EN);
+
+ /* Mode is RGMII, all bits clear */
+ clrbits8(&bcsr_regs[11], BCSR_UCC1_MODE_MSK |
+ BCSR_UCC2_MODE_MSK);
+
+ /* Turn UCC1 & UCC2 on */
+ setbits8(&bcsr_regs[8], BCSR_UCC1_GETH_EN);
+ setbits8(&bcsr_regs[9], BCSR_UCC2_GETH_EN);
iounmap(bcsr_regs);
}
--
1.5.0.6
^ permalink raw reply related
* [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Anton Vorontsov @ 2007-09-25 14:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: spi-devel-general
In-Reply-To: <20070925143126.GA30013@localhost.localdomain>
MPC85xx's QE SPI controller is almost the same comparing to MPC83xx.
Thus lets use that driver. Tested to work in loopback mode.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b915711..14f0d0d 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -125,7 +125,7 @@ config SPI_MPC52xx_PSC
config SPI_MPC83xx
tristate "Freescale MPC83xx SPI controller"
- depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
+ depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
select SPI_BITBANG
help
This enables using the Freescale MPC83xx SPI controller in master
--
1.5.0.6
^ permalink raw reply related
* Re: [PATCH 1/5] PowerPC: Move of_device allocation into of_device.[ch]
From: Arnd Bergmann @ 2007-09-25 14:27 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Paul Mackerras, Joachim Fenkes,
LKML, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709251411.27755.fenkes@de.ibm.com>
On Tuesday 25 September 2007, Joachim Fenkes wrote:
> Extract generic of_device allocation code from of_platform_device_create()
> and move it into of_device.[ch], called of_device_alloc(). Also, there's =
now
> of_device_free() which puts the device node.
>=20
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> ---
> =A0include/asm-powerpc/of_device.h =A0 | =A0 =A04 ++
> =A0include/linux/of_device.h =A0 =A0 =A0 =A0 | =A0 =A05 ++
> =A0arch/powerpc/kernel/of_device.c =A0 | =A0 80 +++++++++++++++++++++++++=
++++++++++++
> =A0arch/powerpc/kernel/of_platform.c | =A0 70 +--------------------------=
=2D----
> =A04 files changed, 91 insertions(+), 68 deletions(-)
>=20
Sorry I didn't review the patches earlier when you sent them in private.
The patch looks good to me, especially since you did exactly what I
suggested ;-)
Maybe the description should have another sentence in it about what
the change is good for. You have that in the 0/5 mail, but that does
not go into the changelog, so the information gets lost in the process.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/5] ibmebus: Remove bus match/probe/remove functions
From: Arnd Bergmann @ 2007-09-25 14:29 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Paul Mackerras, Joachim Fenkes,
LKML, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709251411.54465.fenkes@de.ibm.com>
On Tuesday 25 September 2007, Joachim Fenkes wrote:
> ibmebus_{,un}register_driver() are replaced by dummy functions because
> ibmebus is temporarily unusable in this transitional state.
>=20
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> ---
> =A0arch/powerpc/kernel/ibmebus.c | =A0199 ++-----------------------------=
=2D---------
> =A01 files changed, 6 insertions(+), 193 deletions(-)
>=20
Great diffstat!
The description makes it sound like a git-bisect would get broken
by this patch, which should never happen. If the patch indeed
ends up with a broken kernel, it would be better to merge it with
the later patch that fixes the code again.
Arnd <><
^ permalink raw reply
* Re: [PATCH 3/5] ibmebus: Add device creation and bus probing based on of_device
From: Arnd Bergmann @ 2007-09-25 14:39 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Paul Mackerras, Joachim Fenkes,
LKML, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709251412.27896.fenkes@de.ibm.com>
On Tuesday 25 September 2007, Joachim Fenkes wrote:
> The devtree root is now searched for devices matching a built-in whitelist
> during boot, so these devices appear on the bus from the beginning. It is
> still possible to manually add/remove devices to/from the bus by using the
> probe/remove sysfs interface. Also, when a device driver registers itself,
> the devtree is matched against its matchlist.
>
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> ---
> arch/powerpc/kernel/ibmebus.c | 97 ++++++++++++++++++++++++++++++++++-------
> 1 files changed, 81 insertions(+), 16 deletions(-)
>
> diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
> index cc80f84..c506e0d 100644
> --- a/arch/powerpc/kernel/ibmebus.c
> +++ b/arch/powerpc/kernel/ibmebus.c
> @@ -51,6 +51,15 @@ static struct device ibmebus_bus_device = { /* fake "parent" device */
>
> struct bus_type ibmebus_bus_type;
>
> +/* These devices will automatically be added to the bus during init */
> +static struct of_device_id builtin_matches[] = {
> + { .name = "lhca" },
> + { .compatible = "IBM,lhca" },
> + { .name = "lhea" },
> + { .compatible = "IBM,lhea" },
> + {},
> +};
> +
Hmm, do you have devices that only have the matching name property
but not the compatible property? If not, I'd suggest only looking
for compatible, so you have less chance of false positives.
> +static int ibmebus_create_device(struct device_node *dn)
> +{
> + struct of_device *dev;
> + int ret;
> +
> + dev = of_device_alloc(dn, NULL, &ibmebus_bus_device);
> + if (!dev)
> + return -ENOMEM;
> +
> + dev->dev.bus = &ibmebus_bus_type;
> + dev->dev.archdata.dma_ops = &ibmebus_dma_ops;
> +
> + ret = of_device_register(dev);
> + if (ret) {
> + of_device_free(dev);
> + return ret;
> + }
> +
> + return 0;
> +}
nice!
> @@ -219,9 +276,9 @@ static ssize_t ibmebus_store_probe(struct bus_type *bus,
> }
>
> if ((dn = of_find_node_by_path(path))) {
> -/* dev = ibmebus_register_device_node(dn); */
> + rc = ibmebus_create_device(dn);
> of_node_put(dn);
> - rc = IS_ERR(dev) ? PTR_ERR(dev) : count;
> + rc = rc ? rc : count;
the last line looks a bit silly. Maybe instead do
rc = ibmebus_create_device(dn);
of_node_put(dn);
}
kfree(path);
if (rc)
return rc;
return count;
}
^ permalink raw reply
* Re: [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Peter Korsgaard @ 2007-09-25 14:48 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <20070925143531.GG5323@localhost.localdomain>
>>>>> "Anton" == Anton Vorontsov <avorontsov@ru.mvista.com> writes:
Hi,
Anton> config SPI_MPC83xx
Anton> tristate "Freescale MPC83xx SPI controller"
Anton> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
Anton> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
Anton> select SPI_BITBANG
Anton> help
Anton> This enables using the Freescale MPC83xx SPI controller in master
Please also update the help text.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 4/5] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
From: Arnd Bergmann @ 2007-09-25 14:42 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Jan-Bernd Themann, Paul Mackerras, Joachim Fenkes,
LKML, Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200709251412.59904.fenkes@de.ibm.com>
On Tuesday 25 September 2007, Joachim Fenkes wrote:
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
This is missing a description, but the patch looks good.
Arnd <><
^ permalink raw reply
* [PATCH v2 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Anton Vorontsov @ 2007-09-25 15:02 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <874phiol7j.fsf@macbook.be.48ers.dk>
On Tue, Sep 25, 2007 at 04:48:00PM +0200, Peter Korsgaard wrote:
> >>>>> "Anton" == Anton Vorontsov <avorontsov@ru.mvista.com> writes:
>
> Hi,
>
> Anton> config SPI_MPC83xx
> Anton> tristate "Freescale MPC83xx SPI controller"
> Anton> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
> Anton> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
> Anton> select SPI_BITBANG
> Anton> help
> Anton> This enables using the Freescale MPC83xx SPI controller in master
>
> Please also update the help text.
Oops. Thanks, fixed.
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [PATCH v2] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
MPC85xx's QE SPI controller is almost the same comparing to MPC83xx.
Thus lets use that driver. Tested to work in loopback mode.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/spi/Kconfig | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b915711..7a7a42c 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -124,16 +124,17 @@ config SPI_MPC52xx_PSC
Controller in master SPI mode.
config SPI_MPC83xx
- tristate "Freescale MPC83xx SPI controller"
- depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
+ tristate "Freescale MPC83xx/MPC85xx SPI controller"
+ depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
select SPI_BITBANG
help
- This enables using the Freescale MPC83xx SPI controller in master
- mode.
+ This enables using the Freescale MPC83xx/MPC85xx SPI controller in
+ master mode.
Note, this driver uniquely supports the SPI controller on the MPC83xx
- family of PowerPC processors. The MPC83xx uses a simple set of shift
- registers for data (opposed to the CPM based descriptor model).
+ and MPC85xx family of PowerPC processors. The MPC83xx/MPC85xx uses a
+ simple set of shift registers for data (opposed to the CPM based
+ descriptor model).
config SPI_OMAP_UWIRE
tristate "OMAP1 MicroWire"
--
1.5.0.6
^ permalink raw reply related
* Re: [spi-devel-general] [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Kumar Gala @ 2007-09-25 15:04 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <20070925143531.GG5323@localhost.localdomain>
On Sep 25, 2007, at 9:35 AM, Anton Vorontsov wrote:
> MPC85xx's QE SPI controller is almost the same comparing to MPC83xx.
> Thus lets use that driver. Tested to work in loopback mode.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/spi/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index b915711..14f0d0d 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -125,7 +125,7 @@ config SPI_MPC52xx_PSC
>
> config SPI_MPC83xx
> tristate "Freescale MPC83xx SPI controller"
> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
> select SPI_BITBANG
> help
> This enables using the Freescale MPC83xx SPI controller in master
Should that really be just PPC_83xx || QUICC_ENGINE?
- k
^ permalink raw reply
* Re: [PATCH4/4] [POWERPC] Fix cpm_uart driver
From: Scott Wood @ 2007-09-25 15:11 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <46F8FA5F.3050907@scram.de>
On Tue, Sep 25, 2007 at 02:09:03PM +0200, Jochen Friedrich wrote:
> In cpm_uart_core.c, the operation "pinfo->rx_bd_base - DPRAM_BASE" is
> used to calculate the DPRAM offset. So DPRAM_BASE must be relative to
> dpram_vbase in commproc.c as well. However, cpm_uart_cpm1.h uses cpmp in
> commproc.c to initialize DPRAM_BASE.
>
> On ARCH=ppc, cpmp is a physical address with 1:1 virtual mapping ("well
> known address"). On ARC=powerpc, this is an address obtained by
> ioremap(), however it's a different ioremap() call than dpram_vbase is
> obtained from, so noone can guarantee
> cpmp is always the same as dpram_vbase even on ARCH=powerpc.
I have patches submitted in which they're from the same ioremap, but
I agree that using cpm_dpram_addr(0) is a more robust way.
-Scott
^ permalink raw reply
* Re: [spi-devel-general] [PATCH 7/7] [POWERPC][SPI] spi_mpc83xx: allow use on MPC85xx
From: Anton Vorontsov @ 2007-09-25 15:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <16E78F0E-B57B-4084-887E-5D2F9C1D0331@kernel.crashing.org>
On Tue, Sep 25, 2007 at 10:04:41AM -0500, Kumar Gala wrote:
>
> On Sep 25, 2007, at 9:35 AM, Anton Vorontsov wrote:
>
>> MPC85xx's QE SPI controller is almost the same comparing to MPC83xx.
>> Thus lets use that driver. Tested to work in loopback mode.
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>> drivers/spi/Kconfig | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> index b915711..14f0d0d 100644
>> --- a/drivers/spi/Kconfig
>> +++ b/drivers/spi/Kconfig
>> @@ -125,7 +125,7 @@ config SPI_MPC52xx_PSC
>>
>> config SPI_MPC83xx
>> tristate "Freescale MPC83xx SPI controller"
>> - depends on SPI_MASTER && PPC_83xx && EXPERIMENTAL
>> + depends on SPI_MASTER && (PPC_83xx || PPC_85xx) && EXPERIMENTAL
>> select SPI_BITBANG
>> help
>> This enables using the Freescale MPC83xx SPI controller in master
>
> Should that really be just PPC_83xx || QUICC_ENGINE?
Well, I thought about that. By now I'm unsure if every QE
implementation will be compatible with further ones. So far
I've tested this driver on MPC8323 and MPC8568. If we'll see
more and more compatible QE SPI controllers, of course we
may just do || QUICC_ENGINE.
PPC_83xx || PPC_85xx
PPC_83xx || QUICC_ENGINE
Today first option saves us four bytes. ;-)
^ permalink raw reply
* Re: PaSemi DMA API for Linux
From: Olof Johansson @ 2007-09-25 15:22 UTC (permalink / raw)
To: Samuel Zahnd; +Cc: linuxppc-embedded
In-Reply-To: <005401c7ff6f$d24ea290$4c0112ac@scsad.scs.ch>
On Tue, Sep 25, 2007 at 02:30:13PM +0200, Samuel Zahnd wrote:
> Hi embedded people,
>
> we have a PaSemi (PA6T-1682) CPU is use with Linux and CFE. I wonder if
> anybody has experience with the DMA engine of the device. Some examples or
> an API would be particularly usefull.
The network driver uses the DMA engine, besides that there's not much
example code out there.
The DMA has alot of features, just what are you looking to do? Just DMA
copy offload, or other functions?
-Olof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox