[PATCH] [POWERPC] mpic: cope with non mpic irqs
Compiling ppc64_defconfig with gcc 4.3 gives thes warnings:
arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_get_priority':
arch/powerpc/sysdev/mpic.c:1351: warning: 'is_ipi' may be used uninitialized in
this function
arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_set_priority':
arch/powerpc/sysdev/mpic.c:1328: warning: 'is_ipi' may be used uninitialized in
this function
It turns out that in the cases where is_ipi is uninitialized, another
variable (mpic) will be NULL and it is dereferenced. Protect against
this by returning if mpic is NULL in mpic_irq_set_priority and removing
mpic_irq_get_priority completely as it has no in tree callers.
This has the nice side effect of making the warning go away.
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/sysdev/mpic.c | 20 +++-
include/asm-powerpc/mpic.h |3 +--
2 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8619f2a..7680001 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1331,6 +1331,9 @@ void mpic_irq_set_priority(unsigned int irq, unsigned int
pri)
unsigned long flags;
u32 reg;
+ if (!mpic)
+ return;
+
spin_lock_irqsave(mpic_lock, flags);
if (is_ipi) {
reg = mpic_ipi_read(src - mpic-ipi_vecs[0])
@@ -1346,23 +1349,6 @@ void mpic_irq_set_priority(unsigned int irq, unsigned
int pri)
spin_unlock_irqrestore(mpic_lock, flags);
}
-unsigned int mpic_irq_get_priority(unsigned int irq)
-{
- unsigned int is_ipi;
- struct mpic *mpic = mpic_find(irq, is_ipi);
- unsigned int src = mpic_irq_to_hw(irq);
- unsigned long flags;
- u32 reg;
-
- spin_lock_irqsave(mpic_lock, flags);
- if (is_ipi)
- reg = mpic_ipi_read(src = mpic-ipi_vecs[0]);
- else
- reg = mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI));
- spin_unlock_irqrestore(mpic_lock, flags);
- return (reg MPIC_VECPRI_PRIORITY_MASK) MPIC_VECPRI_PRIORITY_SHIFT;
-}
-
void mpic_setup_this_cpu(void)
{
#ifdef CONFIG_SMP
diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
index 943c5a3..a4d0f87 100644
--- a/include/asm-powerpc/mpic.h
+++ b/include/asm-powerpc/mpic.h
@@ -428,12 +428,11 @@ extern void mpic_init(struct mpic *mpic);
*/
-/* Change/Read the priority of an interrupt. Default is 8 for irqs and
+/* Change the priority of an interrupt. Default is 8 for irqs and
* 10 for IPIs. You can call this on both IPIs and IRQ numbers, but the
* IPI number is then the offset'ed (linux irq number mapped to the IPI)
*/
extern void mpic_irq_set_priority(unsigned int irq, unsigned int pri);
-extern unsigned int mpic_irq_get_priority(unsigned int irq);
/* Setup a non-boot CPU */
extern void mpic_setup_this_cpu(void);
--
1.5.5.1
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add kernstart_addr to list of allowed symbols in prom_init
Michael Ellerman wrote: Since commit 85xx: Add support for relocatable kernel (and booting at non-zero) (37dd2badcfcec35f5e21a0926968d77a404f03c3), PHYSICAL_START is #defined as kernstart_addr if RELOCATABLE and FLATMEM is enabled. PHYSICAL_START is used in prom_init.c and so kernstart_addr needs to be added to the list of allowed symbols that prom_init.c can access. Signed-off-by: Michael Ellerman [EMAIL PROTECTED] --- Not sure if anyone is building this config in practice, but it is broken in 26 without this patch. arch/powerpc/kernel/prom_init_check.sh |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/prom_init_check.sh b/arch/powerpc/kernel/prom_init_check.sh index 8e24fc1..31729a9 100644 --- a/arch/powerpc/kernel/prom_init_check.sh +++ b/arch/powerpc/kernel/prom_init_check.sh @@ -20,7 +20,7 @@ WHITELIST=add_reloc_offset __bss_start __bss_stop copy_and_flush _end enter_prom memcpy memset reloc_offset __secondary_hold __secondary_hold_acknowledge __secondary_hold_spinloop __start strcmp strcpy strlcpy strlen strncmp strstr logo_linux_clut224 -reloc_got2 +reloc_got2 kernstart_addr NM=$1 OBJ=$2 Hi Michael, Thanks, the patch fixes the build failure. Tested-by: Kamalesh Babulal [EMAIL PROTECTED] -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
Trent Piepho [EMAIL PROTECTED] writes: On Wed, 21 May 2008, Andreas Schwab wrote: Trent Piepho [EMAIL PROTECTED] writes: It's the _le versions that have a problem, since we can't get gcc to just use the register indexed mode. It seems like an obvious thing to have a constraint for, but I guess there weren't enough instructions that only come in 'x' versions to bother with it. There is a 'Z' constraint, Memory operand that is an indexed or indirect from a register, but I tried it and it can use both rb,ri and disp(rb) forms. Actually, I'm not sure how 'Z' is any different than m? 'Z' will never emit a non-zero constant displacement. It's too bad gas doesn't appear to be smart enough to turn: stwbrx 0, 0(3) -or- stwbr 0, 0(3) Use the %y modifier when substituting the operand. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Add i2c pins to dts and board setup
Initialize I2C pins on boards with CPM1/CPM2 controllers.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt | 39 ++
arch/powerpc/boot/dts/mpc8272ads.dts | 11 +++
arch/powerpc/boot/dts/mpc866ads.dts | 11 +++
arch/powerpc/boot/dts/mpc885ads.dts | 11 +++
arch/powerpc/platforms/82xx/mpc8272_ads.c|4 ++
arch/powerpc/platforms/8xx/mpc86xads_setup.c |4 ++
arch/powerpc/platforms/8xx/mpc885ads_setup.c |3 ++
7 files changed, 83 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 1d2a772..3fc4eb2 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2132,6 +2132,45 @@ platforms are moved over to use the
flattened-device-tree model.
};
};
+ ix) I2C
+
+ The I2C controller is expressed as a bus under the CPM node.
+
+ Properties:
+ - compatible : fsl,cpm1-i2c, fsl,cpm2-i2c
+ - reg : On CPM2 devices, the second resource doesn't specify the I2C
+ Parameter RAM itself, but the I2C_BASE field of the CPM2 Parameter RAM
+ (typically 0x8afc 0x2).
+ - #address-cells : Should be one. The cell is the i2c device address with
+ the r/w bit set to zero.
+ - #size-cells : Should be zero.
+ - linux,i2c-index : Can be used to hard code an i2c bus nummer.
+ - linux,i2c-class : Can be used to override the i2c class. The class is used
+ by old style i2c device drivers to find a bus in a specific context like
+ system management, video or sound. By default, I2C_CLASS_HWMON (1) is
+ being used. The definition of the classes can be found in
+ include/i2c/i2c.h
+ - bus-frequency : Can be used to set the i2c bus frequency. If unspecified,
+ a default frequency of 60kHz is being used.
+
+ Example, based on mpc823:
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc823-i2c,
+fsl,cpm1-i2c;
+ reg = 0x860 0x20 0x3c80 0x30;
+ interrupts = 16;
+ interrupt-parent = CPM_PIC;
+ fsl,cpm-command = 0x10;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = dallas,ds1307;
+ reg = 0x68;
+ };
+ };
+
m) Chipselect/Local Bus
Properties:
diff --git a/arch/powerpc/boot/dts/mpc8272ads.dts
b/arch/powerpc/boot/dts/mpc8272ads.dts
index 46e2da3..d27f8a7 100644
--- a/arch/powerpc/boot/dts/mpc8272ads.dts
+++ b/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -217,6 +217,17 @@
linux,network-index = 1;
fsl,cpm-command = 0x16200300;
};
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8272-i2c,
+fsl,cpm2-i2c;
+ reg = 0x11860 0x20 0x8afc 0x2;
+ interrupts = 1 8;
+ interrupt-parent = PIC;
+ fsl,cpm-command = 0x2960;
+ #address-cells = 1;
+ #size-cells = 0;
+ };
};
PIC: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc866ads.dts
b/arch/powerpc/boot/dts/mpc866ads.dts
index 765e43c..bd70065 100644
--- a/arch/powerpc/boot/dts/mpc866ads.dts
+++ b/arch/powerpc/boot/dts/mpc866ads.dts
@@ -171,6 +171,17 @@
fsl,cpm-command = ;
linux,network-index = 1;
};
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc866-i2c,
+fsl,cpm1-i2c;
+ reg = 0x860 0x20 0x3c80 0x30;
+ interrupts = 16;
+ interrupt-parent = CPM_PIC;
+ fsl,cpm-command = 0x10;
+ #address-cells = 1;
+ #size-cells = 0;
+ };
};
};
diff --git a/arch/powerpc/boot/dts/mpc885ads.dts
b/arch/powerpc/boot/dts/mpc885ads.dts
index 9895043..b123e9f 100644
--- a/arch/powerpc/boot/dts/mpc885ads.dts
+++ b/arch/powerpc/boot/dts/mpc885ads.dts
@@ -215,6 +215,17 @@
fsl,cpm-command = 0x80;
linux,network-index = 2;
};
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc885-i2c,
+fsl,cpm1-i2c;
+ reg = 0x860 0x20 0x3c80 0x30;
+
[PATCH] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
This driver uses the port of 2.4 code from Vitaly Bordug
[EMAIL PROTECTED] and the actual algorithm used by the i2c
driver of the DBox code on cvs.tuxboc.org from Felix Domke
([EMAIL PROTECTED]) and Gillem ([EMAIL PROTECTED]) converted to an
of_platform_driver. Tested on CPM1 (MPC823 on dbox2 hardware) and
CPM2 (MPC8272).
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-cpm.c | 745 ++
3 files changed, 756 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/busses/i2c-cpm.c
Changes since last version:
- fixed copy and paste bug (I2COM_MASTER - I2COM_START)
- changed dev_err() to dev_dbg() for NACK
- changed dev_dbg() to dev_err() for Timeout
- added explanation for brg formular
- added bus-frequency OF attribute to be able to override i2c clock
- support for numbered adapter (it was already documented in
my booting-without-of patch but not yet implemented)
- finally changed i2c pseudo address 0xfe to 0x7f 1
- get rid of the fsl,cpm-i2c name. This logic was screwed
- fixed the error patch for request_irq failure
- s/IIC/I2C/g
- fixed error output read timeout - transfer timeout
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 48438cc..c627b94 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -117,6 +117,16 @@ config I2C_BLACKFIN_TWI_CLK_KHZ
help
The unit of the TWI clock is kHz.
+config I2C_CPM
+ tristate Freescale CPM1 or CPM2 (MPC8xx/826x)
+ depends on (CPM1 || CPM2) OF_I2C
+ help
+ This supports the use of the I2C interface on Freescale
+ processors with CPM1 or CPM2.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-cpm.
+
config I2C_DAVINCI
tristate DaVinci I2C driver
depends on ARCH_DAVINCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index e8c882a..1ccd5ba 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
+obj-$(CONFIG_I2C_CPM) += i2c-cpm.o
obj-$(CONFIG_I2C_DAVINCI) += i2c-davinci.o
obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
new file mode 100644
index 000..305159c
--- /dev/null
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -0,0 +1,745 @@
+/*
+ * Freescale CPM1/CPM2 I2C interface.
+ * Copyright (c) 1999 Dan Malek ([EMAIL PROTECTED]).
+ *
+ * moved into proper i2c interface;
+ * Brad Parker ([EMAIL PROTECTED])
+ *
+ * Parts from dbox2_i2c.c (cvs.tuxbox.org)
+ * (C) 2000-2001 Felix Domke ([EMAIL PROTECTED]), Gillem ([EMAIL PROTECTED])
+ *
+ * (C) 2007 Montavista Software, Inc.
+ * Vitaly Bordug [EMAIL PROTECTED]
+ *
+ * Converted to of_platform_device. Renamed to i2c-cpm.c.
+ * (C) 2007,2008 Jochen Friedrich [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.
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/delay.h
+#include linux/slab.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/errno.h
+#include linux/stddef.h
+#include linux/i2c.h
+#include linux/io.h
+#include linux/dma-mapping.h
+#include linux/of_device.h
+#include linux/of_platform.h
+#include linux/of_i2c.h
+#include sysdev/fsl_soc.h
+#include asm/cpm.h
+
+/* Try to define this if you have an older CPU (earlier than rev D4) */
+/* However, better use a GPIO based bitbang driver in this case :/ */
+#undef I2C_CHIP_ERRATA
+
+#define CPM_MAX_READ513
+#define CPM_MAXBD 4
+
+#define I2C_EB (0x10) /* Big endian mode */
+#define I2C_EB_CPM2(0x30) /* Big endian mode, memory snoop */
+
+#define DPRAM_BASE ((u8 __iomem __force *)cpm_muram_addr(0))
+
+/* I2C parameter RAM. */
+struct i2c_ram {
+ ushort rbase; /* Rx Buffer descriptor base address */
+ ushort tbase; /* Tx Buffer descriptor base address */
+ u_char rfcr;
Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
Depends on what you define as necessary. It's seem clear that I/O accessors
_no not_ need to be strictly ordered with respect to normal memory accesses,
by what's defined in memory-barriers.txt. So if by necessary you mean what
the Linux standard for I/O accessors requires (and what other archs provide),
then yes, they have the necessary ordering guarantees.
But, if you want them to be strictly ordered w.r.t to normal memory, that's
not the case.
They should be.
For example, in something like:
u32 *dmabuf = kmalloc(...);
...
dmabuf[0] = 1;
out_be32(regs-dmactl, DMA_SEND_BUFFER);
dmabuf[0] = 2;
out_be32(regs-dmactl, DMA_SEND_BUFFER);
gcc might decide to optimize this code to:
out_be32(regs-dmactl, DMA_SEND_BUFFER);
out_be32(regs-dmactl, DMA_SEND_BUFFER);
dmabuf[0] = 2;
If that's the case, there is a bug. Ignoring gcc possible optimisations,
the accessors contain the necessary memory barriers for things to work
the way you describe above. If the use of volatile and clobber in our
macros isn't enough to also prevent optimisations, then we have a bug
and you are welcome to provide a patch to fix it.
gcc will often not do this optimization, because there might be aliasing
between regs-dmact and dmabuf, but it _can_ do it. gcc can't optimize
the two identical out_be32's into one, or re-order them if they were to
different registers, but it can move the normal memory accesses around them.
The linus kernel -cannot- be compiled with strict aliasing rules. This
is one of the many areas where those are violated. Frankly, this strict
aliasing stuff is just a total nightmare turning a pefectly nice and
useable language into something it's not meant to be.
Here's a quick hack I stuck in a driver to test. compile with -save-temps and
check the resulting asm. gcc will do the optimization I described above.
static void __iomem *baz = (void*)0x1234;
static struct bar {
u32 bar[256];
} bar;
void foo(void) {
bar.bar[0] = 44;
out_be32(baz+100, 200);
bar.bar[0] = 45;
out_be32(baz+101, 201);
}
Have you removed -fno-strict-aliasing ? Just don't do that.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
On Tue, 2008-05-20 at 15:55 -0700, Trent Piepho wrote: here doesn't appear to be any barriers to use for coherent dma other than mb() and wmb(). Correct me if I'm wrong, but I think the sync isn't actually _required_ (by memory-barriers.txt's definitions), and it would be enough to use eieio, except there is code that doesn't use mmiowb() between I/O access and unlocking. So, as I understand it, the minimum needed is eieio. To provide strict ordering w.r.t. spin locks without using mmiowb(), you need sync. To provide strict ordering w.r.t. normal memory, you need sync and a compiler barrier. Right now no archs provide the last option. powerpc is currently the middle option. I don't know if anything uses the first option, maybe alpha? I'm almost certain x86 is the middle option (the first isn't possible, the arch already has more ordering than that), which is probably why powerpc used that option and not the first. I don't have time for that now. Can you dig into the archives ? The whole thing has been discussed at lenght already. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/2] powerpc: rmb fix
Hi,
I'm sure I've sent these patches before, but I can't remember why they
weren't merged. They still seem obviously correct to me.
--
lwsync is explicitly defined not to have any effect on the ordering of
accesses to device memory, so it cannot be used for rmb(). sync appears
to be the only barrier which fits the bill.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/include/asm-powerpc/system.h
===
--- linux-2.6.orig/include/asm-powerpc/system.h
+++ linux-2.6/include/asm-powerpc/system.h
@@ -34,7 +34,7 @@
* SMP since it is only used to order updates to system memory.
*/
#define mb() __asm__ __volatile__ (sync : : : memory)
-#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : : memory)
+#define rmb() __asm__ __volatile__ (sync : : : memory)
#define wmb() __asm__ __volatile__ (sync : : : memory)
#define read_barrier_depends() do { } while(0)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 2/2] powerpc: optimise smp_wmb
lwsync is the recommended method of store/store ordering on caching enabled memory. For those subarchs which have lwsync, use it rather than eieio for smp_wmb. Signed-off-by: Nick Piggin [EMAIL PROTECTED] --- Index: linux-2.6/include/asm-powerpc/system.h === --- linux-2.6.orig/include/asm-powerpc/system.h +++ linux-2.6/include/asm-powerpc/system.h @@ -30,8 +30,8 @@ * * For wmb(), we use sync since wmb is used in drivers to order * stores to system memory with respect to writes to the device. - * However, smp_wmb() can be a lighter-weight eieio barrier on - * SMP since it is only used to order updates to system memory. + * However, smp_wmb() can be a lighter-weight lwsync or eieio barrier + * on SMP since it is only used to order updates to system memory. */ #define mb() __asm__ __volatile__ (sync : : : memory) #define rmb() __asm__ __volatile__ (sync : : : memory) @@ -43,9 +43,16 @@ #ifdef __KERNEL__ #define AT_VECTOR_SIZE_ARCH 6 /* entries in ARCH_DLINFO */ #ifdef CONFIG_SMP + +#ifdef __SUBARCH_HAS_LWSYNC +#define SMPWMB lwsync +#else +#define SMPWMB eieio +#endif + #define smp_mb() mb() #define smp_rmb() rmb() -#define smp_wmb() eieio() +#define smp_wmb() __asm__ __volatile__ (__stringify(SMPWMB) : : :memory) #define smp_read_barrier_depends() read_barrier_depends() #else #define smp_mb() barrier() ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
Hi Jochen, On Wed, May 21, 2008 at 12:43:22PM +0200, Jochen Friedrich wrote: This driver uses the port of 2.4 code from Vitaly Bordug [EMAIL PROTECTED] and the actual algorithm used by the i2c driver of the DBox code on cvs.tuxboc.org from Felix Domke ([EMAIL PROTECTED]) and Gillem ([EMAIL PROTECTED]) converted to an of_platform_driver. Tested on CPM1 (MPC823 on dbox2 hardware) and CPM2 (MPC8272). Signed-off-by: Jochen Friedrich [EMAIL PROTECTED] --- Works on MPC8260. Tested-by: Wolfram Sang [EMAIL PROTECTED] drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile |1 + drivers/i2c/busses/i2c-cpm.c | 745 ++ 3 files changed, 756 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/busses/i2c-cpm.c Changes since last version: - fixed copy and paste bug (I2COM_MASTER - I2COM_START) - changed dev_err() to dev_dbg() for NACK - changed dev_dbg() to dev_err() for Timeout - added explanation for brg formular Typo: formula - added bus-frequency OF attribute to be able to override i2c clock \o/ Cool feature. Worked nicely. - support for numbered adapter (it was already documented in my booting-without-of patch but not yet implemented) - finally changed i2c pseudo address 0xfe to 0x7f 1 - get rid of the fsl,cpm-i2c name. This logic was screwed - fixed the error patch for request_irq failure path instead of patch? But well, I assume typos in this section do not matter much anyhow as they are not imported into git. Am I right, Jean? - s/IIC/I2C/g - fixed error output read timeout - transfer timeout diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 48438cc..c627b94 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -117,6 +117,16 @@ config I2C_BLACKFIN_TWI_CLK_KHZ help The unit of the TWI clock is kHz. +config I2C_CPM + tristate Freescale CPM1 or CPM2 (MPC8xx/826x) + depends on (CPM1 || CPM2) OF_I2C + help + This supports the use of the I2C interface on Freescale + processors with CPM1 or CPM2. + + This driver can also be built as a module. If so, the module + will be called i2c-cpm. + config I2C_DAVINCI tristate DaVinci I2C driver depends on ARCH_DAVINCI diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile index e8c882a..1ccd5ba 100644 --- a/drivers/i2c/busses/Makefile +++ b/drivers/i2c/busses/Makefile @@ -11,6 +11,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o obj-$(CONFIG_I2C_AT91) += i2c-at91.o obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o +obj-$(CONFIG_I2C_CPM)+= i2c-cpm.o obj-$(CONFIG_I2C_DAVINCI)+= i2c-davinci.o obj-$(CONFIG_I2C_ELEKTOR)+= i2c-elektor.o obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c new file mode 100644 index 000..305159c --- /dev/null +++ b/drivers/i2c/busses/i2c-cpm.c @@ -0,0 +1,745 @@ +/* + * Freescale CPM1/CPM2 I2C interface. + * Copyright (c) 1999 Dan Malek ([EMAIL PROTECTED]). + * + * moved into proper i2c interface; + * Brad Parker ([EMAIL PROTECTED]) + * + * Parts from dbox2_i2c.c (cvs.tuxbox.org) + * (C) 2000-2001 Felix Domke ([EMAIL PROTECTED]), Gillem ([EMAIL PROTECTED]) + * + * (C) 2007 Montavista Software, Inc. + * Vitaly Bordug [EMAIL PROTECTED] + * + * Converted to of_platform_device. Renamed to i2c-cpm.c. + * (C) 2007,2008 Jochen Friedrich [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. + * + * 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., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#include linux/kernel.h +#include linux/module.h +#include linux/delay.h +#include linux/slab.h +#include linux/init.h +#include linux/interrupt.h +#include linux/errno.h +#include linux/stddef.h +#include linux/i2c.h +#include linux/io.h +#include linux/dma-mapping.h +#include linux/of_device.h +#include linux/of_platform.h +#include linux/of_i2c.h +#include sysdev/fsl_soc.h +#include asm/cpm.h + +/* Try to define this if you have an older CPU (earlier than rev D4) */ +/* However, better use a GPIO based bitbang driver in this case :/ */ +#undef I2C_CHIP_ERRATA + +#define CPM_MAX_READ
Re: [PATCH] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
On Wed, 21 May 2008 16:33:07 +0200, Wolfram Sang wrote: Hi Jochen, On Wed, May 21, 2008 at 12:43:22PM +0200, Jochen Friedrich wrote: This driver uses the port of 2.4 code from Vitaly Bordug [EMAIL PROTECTED] and the actual algorithm used by the i2c driver of the DBox code on cvs.tuxboc.org from Felix Domke ([EMAIL PROTECTED]) and Gillem ([EMAIL PROTECTED]) converted to an of_platform_driver. Tested on CPM1 (MPC823 on dbox2 hardware) and CPM2 (MPC8272). Signed-off-by: Jochen Friedrich [EMAIL PROTECTED] --- Works on MPC8260. Tested-by: Wolfram Sang [EMAIL PROTECTED] drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile |1 + drivers/i2c/busses/i2c-cpm.c | 745 ++ 3 files changed, 756 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/busses/i2c-cpm.c Changes since last version: - fixed copy and paste bug (I2COM_MASTER - I2COM_START) - changed dev_err() to dev_dbg() for NACK - changed dev_dbg() to dev_err() for Timeout - added explanation for brg formular Typo: formula - added bus-frequency OF attribute to be able to override i2c clock \o/ Cool feature. Worked nicely. - support for numbered adapter (it was already documented in my booting-without-of patch but not yet implemented) - finally changed i2c pseudo address 0xfe to 0x7f 1 - get rid of the fsl,cpm-i2c name. This logic was screwed - fixed the error patch for request_irq failure path instead of patch? But well, I assume typos in this section do not matter much anyhow as they are not imported into git. Am I right, Jean? Yes you are. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Add i2c pins to dts and board setup
On Wed, May 21, 2008 at 12:31:40PM +0200, Jochen Friedrich wrote: + - linux,i2c-index : Can be used to hard code an i2c bus nummer. s/nummer/number/ Why do we need this? + - linux,i2c-class : Can be used to override the i2c class. The class is used + by old style i2c device drivers to find a bus in a specific context like + system management, video or sound. By default, I2C_CLASS_HWMON (1) is + being used. The definition of the classes can be found in + include/i2c/i2c.h It'd be better to just convert any needed old-style drivers than add this to the device tree. + - bus-frequency : Can be used to set the i2c bus frequency. If unspecified, + a default frequency of 60kHz is being used. clock-frequency is the standard name for such things. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] spi: Add OF binding support for SPI busses
On Fri, May 16, 2008 at 01:36:13PM -0600, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
This patch adds support for populating an SPI bus based on data in the
OF device tree. This is useful for powerpc platforms which use the
device tree instead of discrete code for describing platform layout.
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
[...]
diff --git a/drivers/spi/spi_of.c b/drivers/spi/spi_of.c
new file mode 100644
index 000..b5ae434
--- /dev/null
+++ b/drivers/spi/spi_of.c
@@ -0,0 +1,86 @@
+/*
I think better placement for this is drivers/of, no?
+ * SPI OF support routines
+ * Copyright (C) 2008 Secret Lab Technologies Ltd.
+ *
+ * Support routines for deriving SPI device attachments from the device
+ * tree.
+ */
+
+#include linux/of.h
+#include linux/device.h
+#include linux/spi/spi.h
+#include linux/spi/spi_of.h
+
+/**
+ * spi_of_register_devices - Register child devices onto the SPI bus
+ * @master: Pointer to spi_master device
+ * @np: parent node of SPI device nodes
+ *
+ * Registers an spi_device for each child node of 'np' which has a 'reg'
+ * property.
+ */
+void spi_of_register_devices(struct spi_master *master, struct device_node
*np)
+{
+ struct spi_device *spi;
+ struct device_node *nc;
+ const u32 *prop;
+ const char *sprop;
+ int rc;
+ int len;
+
+ for_each_child_of_node(np, nc) {
+ /* Alloc an spi_device */
+ spi = spi_alloc_device(master);
+ if (!spi) {
+ dev_err(master-dev, spi_device alloc error for %s\n,
+ np-full_name);
+ continue;
+ }
+
+ /* Device address */
+ prop = of_get_property(nc, reg, len);
+ if (!prop || len sizeof(*prop)) {
+ dev_err(master-dev, %s has no 'reg' property\n,
+ np-full_name);
Should be nc-full_name.
+ continue;
+ }
[...]
--
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: [patch 2/2] powerpc: optimise smp_wmb
On Wed, 2008-05-21 at 16:12 +0200, Nick Piggin wrote: lwsync is the recommended method of store/store ordering on caching enabled memory. For those subarchs which have lwsync, use it rather than eieio for smp_wmb. Yuck... existence of lwsync depends on the processor at boot time... Ben. Signed-off-by: Nick Piggin [EMAIL PROTECTED] --- Index: linux-2.6/include/asm-powerpc/system.h === --- linux-2.6.orig/include/asm-powerpc/system.h +++ linux-2.6/include/asm-powerpc/system.h @@ -30,8 +30,8 @@ * * For wmb(), we use sync since wmb is used in drivers to order * stores to system memory with respect to writes to the device. - * However, smp_wmb() can be a lighter-weight eieio barrier on - * SMP since it is only used to order updates to system memory. + * However, smp_wmb() can be a lighter-weight lwsync or eieio barrier + * on SMP since it is only used to order updates to system memory. */ #define mb() __asm__ __volatile__ (sync : : : memory) #define rmb() __asm__ __volatile__ (sync : : : memory) @@ -43,9 +43,16 @@ #ifdef __KERNEL__ #define AT_VECTOR_SIZE_ARCH 6 /* entries in ARCH_DLINFO */ #ifdef CONFIG_SMP + +#ifdef __SUBARCH_HAS_LWSYNC +#define SMPWMB lwsync +#else +#define SMPWMB eieio +#endif + #define smp_mb() mb() #define smp_rmb()rmb() -#define smp_wmb()eieio() +#define smp_wmb()__asm__ __volatile__ (__stringify(SMPWMB) : : :memory) #define smp_read_barrier_depends() read_barrier_depends() #else #define smp_mb() barrier() ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/2] powerpc: rmb fix
On Wed, 2008-05-21 at 16:10 +0200, Nick Piggin wrote:
Hi,
I'm sure I've sent these patches before, but I can't remember why they
weren't merged. They still seem obviously correct to me.
We should already do all that's needed in our IO accessors no ?
--
lwsync is explicitly defined not to have any effect on the ordering of
accesses to device memory, so it cannot be used for rmb(). sync appears
to be the only barrier which fits the bill.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/include/asm-powerpc/system.h
===
--- linux-2.6.orig/include/asm-powerpc/system.h
+++ linux-2.6/include/asm-powerpc/system.h
@@ -34,7 +34,7 @@
* SMP since it is only used to order updates to system memory.
*/
#define mb() __asm__ __volatile__ (sync : : : memory)
-#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : : memory)
+#define rmb() __asm__ __volatile__ (sync : : : memory)
#define wmb() __asm__ __volatile__ (sync : : : memory)
#define read_barrier_depends() do { } while(0)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/2] powerpc: rmb fix
On Wed, May 21, 2008 at 11:27:03AM -0400, Benjamin Herrenschmidt wrote:
On Wed, 2008-05-21 at 16:10 +0200, Nick Piggin wrote:
Hi,
I'm sure I've sent these patches before, but I can't remember why they
weren't merged. They still seem obviously correct to me.
We should already do all that's needed in our IO accessors no ?
More than one device driver does raw/relaxed io accessors and expects the
*mb functions to order them.
--
lwsync is explicitly defined not to have any effect on the ordering of
accesses to device memory, so it cannot be used for rmb(). sync appears
to be the only barrier which fits the bill.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
---
Index: linux-2.6/include/asm-powerpc/system.h
===
--- linux-2.6.orig/include/asm-powerpc/system.h
+++ linux-2.6/include/asm-powerpc/system.h
@@ -34,7 +34,7 @@
* SMP since it is only used to order updates to system memory.
*/
#define mb() __asm__ __volatile__ (sync : : : memory)
-#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : : memory)
+#define rmb() __asm__ __volatile__ (sync : : : memory)
#define wmb() __asm__ __volatile__ (sync : : : memory)
#define read_barrier_depends() do { } while(0)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/2] powerpc: optimise smp_wmb
On Wed, May 21, 2008 at 11:26:32AM -0400, Benjamin Herrenschmidt wrote: On Wed, 2008-05-21 at 16:12 +0200, Nick Piggin wrote: lwsync is the recommended method of store/store ordering on caching enabled memory. For those subarchs which have lwsync, use it rather than eieio for smp_wmb. Yuck... existence of lwsync depends on the processor at boot time... Not according to the __stringify(LWSYNC) that I just removed. At least, presumably it is always present on 64 bit processors, and 32 bit ones will be no worse off as they'll continue just using eieio. Ben. Signed-off-by: Nick Piggin [EMAIL PROTECTED] --- Index: linux-2.6/include/asm-powerpc/system.h === --- linux-2.6.orig/include/asm-powerpc/system.h +++ linux-2.6/include/asm-powerpc/system.h @@ -30,8 +30,8 @@ * * For wmb(), we use sync since wmb is used in drivers to order * stores to system memory with respect to writes to the device. - * However, smp_wmb() can be a lighter-weight eieio barrier on - * SMP since it is only used to order updates to system memory. + * However, smp_wmb() can be a lighter-weight lwsync or eieio barrier + * on SMP since it is only used to order updates to system memory. */ #define mb() __asm__ __volatile__ (sync : : : memory) #define rmb() __asm__ __volatile__ (sync : : : memory) @@ -43,9 +43,16 @@ #ifdef __KERNEL__ #define AT_VECTOR_SIZE_ARCH 6 /* entries in ARCH_DLINFO */ #ifdef CONFIG_SMP + +#ifdef __SUBARCH_HAS_LWSYNC +#define SMPWMB lwsync +#else +#define SMPWMB eieio +#endif + #define smp_mb() mb() #define smp_rmb() rmb() -#define smp_wmb() eieio() +#define smp_wmb() __asm__ __volatile__ (__stringify(SMPWMB) : : :memory) #define smp_read_barrier_depends() read_barrier_depends() #else #define smp_mb() barrier() ___ 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
[RFC/DRAFT] SPI OF bindings, MMC-over-SPI, chip-selects and so on
Hi all, This is just a bait for further discussion of OF/SPI, chip-selects, e.t.c. I've converted the spi_mpc83xx to the OF driver (using Grant's SPI_MASTER_OF work + some additions), and implemented MMC-over-SPI bindings. This stuff extensively using GPIOs, and I think this will work for the bridged SPI too, since the SPI bridge could be represented as GPIO controller (inside the SPI controller node). Thoughts? -- 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/4] [OF] spi_of: add support for dedicated SPI constructors
Dedicated (usually the ones that need to fill platform data) constructors
will create board info, so SPI core will probe them as normal SPI devices.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/spi/spi_of.c | 67
include/linux/spi/spi_of.h |5 +++
2 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi_of.c b/drivers/spi/spi_of.c
index b5ae434..2e1a11f 100644
--- a/drivers/spi/spi_of.c
+++ b/drivers/spi/spi_of.c
@@ -11,6 +11,66 @@
#include linux/spi/spi.h
#include linux/spi/spi_of.h
+/*
+ * Caller have no idea who is master, i.e. this function does not
+ * accept pointer to the master, instead we use board infos.
+ */
+int of_spi_device_probe_common(struct device_node *np,
+ struct spi_board_info *spi_binfo,
+ const char *modalias)
+{
+ struct device_node *parent;
+ const u32 *bus_num;
+ const u32 *chip_select;
+ const u32 *max_speed;
+ int size;
+
+ parent = of_get_parent(np);
+ if (!parent) {
+ pr_err(%s: no parent\n, np-full_name);
+ return -EINVAL;
+ }
+
+ bus_num = of_get_property(parent, reg, size);
+ if (!bus_num || size sizeof(*bus_num)) {
+ pr_err(%s: no reg specified for parent\n, np-full_name);
+ of_node_put(parent);
+ return -EINVAL;
+ }
+ spi_binfo-bus_num = *bus_num;
+ of_node_put(parent);
+
+ chip_select = of_get_property(np, reg, size);
+ if (!chip_select || size sizeof(*chip_select)) {
+ pr_err(%s: no reg (chip-select) specified\n, np-full_name);
+ return -EINVAL;
+ }
+ spi_binfo-chip_select = *chip_select;
+
+ max_speed = of_get_property(np, max-speed, size);
+ if (!max_speed || size sizeof(*max_speed))
+ spi_binfo-max_speed_hz = 10;
+ else
+ spi_binfo-max_speed_hz = *max_speed;
+
+ strcpy(spi_binfo-modalias, modalias);
+
+ /*
+* spi_of_register_devices() should not probe this device, it will
+* be managed by the dedicated driver.
+*/
+ np-data = spi_binfo;
+
+ return 0;
+}
+EXPORT_SYMBOL(of_spi_device_probe_common);
+
+void of_spi_device_remove_common(struct device_node *np)
+{
+ /* For some reason dedicated driver changed its mind. */
+ np-data = NULL;
+}
+
/**
* spi_of_register_devices - Register child devices onto the SPI bus
* @master:Pointer to spi_master device
@@ -29,6 +89,13 @@ void spi_of_register_devices(struct spi_master *master,
struct device_node *np)
int len;
for_each_child_of_node(np, nc) {
+ if (nc-data) {
+ dev_dbg(master-dev, %s: device seem to be not
+ a simple one, somebody took care of it
+ already\n, np-full_name);
+ continue;
+ }
+
/* Alloc an spi_device */
spi = spi_alloc_device(master);
if (!spi) {
diff --git a/include/linux/spi/spi_of.h b/include/linux/spi/spi_of.h
index c943f98..1ea2d82 100644
--- a/include/linux/spi/spi_of.h
+++ b/include/linux/spi/spi_of.h
@@ -12,6 +12,11 @@
#include linux/of.h
#include linux/spi/spi.h
+extern int of_spi_device_probe_common(struct device_node *np,
+ struct spi_board_info *spi_binfo,
+ const char *modalias);
+extern void of_spi_device_remove_common(struct device_node *np);
+
extern void spi_of_register_devices(struct spi_master *master,
struct device_node *np);
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] [SPI] spi_mpc83xx: convert to the OF platform driver
This patch converts the driver to speak OF directly. FSL SPI controllers
do not use internal chip-select machines, so boards must use GPIOs for
these purposes.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt |1 +
drivers/spi/Kconfig |3 +-
drivers/spi/spi_mpc83xx.c| 279 +-
3 files changed, 184 insertions(+), 99 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 8545f82..011bf5e 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1607,6 +1607,7 @@ platforms are moved over to use the flattened-device-tree
model.
controller you have.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
+ - gpios : (optional) may specify GPIOs used for SPI chip-selects
Example:
[EMAIL PROTECTED] {
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 3f0dcae..4c9afeb 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -129,7 +129,8 @@ config SPI_MPC52xx_PSC
config SPI_MPC83xx
tristate Freescale MPC8xxx SPI controller
- depends on SPI_MASTER FSL_SOC EXPERIMENTAL
+ depends on SPI_MASTER OF_GPIO FSL_SOC EXPERIMENTAL
+ select SPI_MASTER_OF
help
This enables using the Freescale MPC8xxx SPI controllers in master
mode.
diff --git a/drivers/spi/spi_mpc83xx.c b/drivers/spi/spi_mpc83xx.c
index 6832da6..7ae4096 100644
--- a/drivers/spi/spi_mpc83xx.c
+++ b/drivers/spi/spi_mpc83xx.c
@@ -21,11 +21,14 @@
#include linux/device.h
#include linux/spi/spi.h
#include linux/spi/spi_bitbang.h
-#include linux/platform_device.h
-#include linux/fsl_devices.h
+#include linux/spi/spi_of.h
+#include linux/of_platform.h
+#include linux/gpio.h
+#include linux/of_gpio.h
#include asm/irq.h
#include asm/io.h
+#include sysdev/fsl_soc.h
/* SPI Controller registers */
struct mpc83xx_spi_reg {
@@ -66,6 +69,11 @@ struct mpc83xx_spi_reg {
#defineSPIM_NE 0x0200 /* Not empty */
#defineSPIM_NF 0x0100 /* Not full */
+enum spi83xx_mode {
+ CPU_MODE = 0,
+ CPU_QE_MODE,
+};
+
/* SPI Controller driver's private data. */
struct mpc83xx_spi {
struct mpc83xx_spi_reg __iomem *base;
@@ -80,6 +88,7 @@ struct mpc83xx_spi {
unsigned int count;
int irq;
+ unsigned int *gpios;
unsigned nsecs; /* (clock cycle time)/2 */
@@ -87,10 +96,7 @@ struct mpc83xx_spi {
u32 rx_shift; /* RX data reg shift when in qe mode */
u32 tx_shift; /* TX data reg shift when in qe mode */
- bool qe_mode;
-
- void (*activate_cs) (u8 cs, u8 polarity);
- void (*deactivate_cs) (u8 cs, u8 polarity);
+ enum spi83xx_mode mode;
u8 busy;
@@ -151,16 +157,13 @@ MPC83XX_SPI_TX_BUF(u32)
static void mpc83xx_spi_chipselect(struct spi_device *spi, int value)
{
- struct mpc83xx_spi *mpc83xx_spi;
u8 pol = spi-mode SPI_CS_HIGH ? 1 : 0;
+ struct mpc83xx_spi *mpc83xx_spi = spi_master_get_devdata(spi-master);
struct spi_mpc83xx_cs *cs = spi-controller_state;
+ unsigned int cs_gpio = mpc83xx_spi-gpios[spi-chip_select];
- mpc83xx_spi = spi_master_get_devdata(spi-master);
-
- if (value == BITBANG_CS_INACTIVE) {
- if (mpc83xx_spi-deactivate_cs)
- mpc83xx_spi-deactivate_cs(spi-chip_select, pol);
- }
+ if (value == BITBANG_CS_INACTIVE gpio_is_valid(cs_gpio))
+ gpio_set_value(cs_gpio, !pol);
if (value == BITBANG_CS_ACTIVE) {
u32 regval = mpc83xx_spi_read_reg(mpc83xx_spi-base-mode);
@@ -184,8 +187,8 @@ static void mpc83xx_spi_chipselect(struct spi_device *spi,
int value)
mpc83xx_spi_write_reg(tmp_ptr, regval);
local_irq_restore(flags);
}
- if (mpc83xx_spi-activate_cs)
- mpc83xx_spi-activate_cs(spi-chip_select, pol);
+ if (gpio_is_valid(cs_gpio))
+ gpio_set_value(cs_gpio, pol);
}
}
@@ -225,14 +228,14 @@ int mpc83xx_spi_setup_transfer(struct spi_device *spi,
struct spi_transfer *t)
if (bits_per_word = 8) {
cs-get_rx = mpc83xx_spi_rx_buf_u8;
cs-get_tx = mpc83xx_spi_tx_buf_u8;
- if (mpc83xx_spi-qe_mode) {
+ if (mpc83xx_spi-mode == CPU_QE_MODE) {
cs-rx_shift = 16;
cs-tx_shift = 24;
}
} else if (bits_per_word = 16) {
cs-get_rx = mpc83xx_spi_rx_buf_u16;
cs-get_tx = mpc83xx_spi_tx_buf_u16;
- if (mpc83xx_spi-qe_mode) {
+ if
[PATCH 3/4] [OF] MMC-over-SPI OF constructor
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt | 24 +
drivers/of/Kconfig |6 ++
drivers/of/Makefile |1 +
drivers/of/spi_mmc.c | 122 ++
4 files changed, 153 insertions(+), 0 deletions(-)
create mode 100644 drivers/of/spi_mmc.c
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 011bf5e..474f50a 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -3113,7 +3113,31 @@ platforms are moved over to use the
flattened-device-tree model.
};
};
+t) MMC-over-SPI
+ Required properties:
+ - #address-cells : should be 0;
+ - #size-cells : should be 0;
+ - compatible : linux,mmc-spi.
+ - linux,modalias - (optional) permissible value is mmc_spi, only used
+if dedicated driver failed to probe.
+ - reg : should specify SPI address (chip-select number).
+ - max-speed : (optional) maximum frequency for this device (Hz).
+ - mmc,ocr-mask : (optional) Linux-specific MMC OCR mask (slot voltage).
+ - gpios : (optional) may specify GPIOs in this order: Write-Protect GPIO,
+Card-Detect GPIO.
+
+ Example:
+
+ [EMAIL PROTECTED] {
+ compatible = linux,mmc-spi;
+ linux,modalias = mmc_spi;
+ reg = 0;
+ max-speed = 5000;
+ mmc,ocr-mask = 0x0020;
+ gpios = sdcsr_pio 6 0 /* WP */
+sdcsr_pio 7 1; /* nCD */
+ };
VII - Marvell Discovery mv64[345]6x System Controller chips
===
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 3a7a11a..80aaf8b 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -13,3 +13,9 @@ config OF_I2C
depends on PPC_OF I2C
help
OpenFirmware I2C accessors
+
+config OF_MMC_SPI
+ def_bool y if MMC_SPI
+ depends on OF_GPIO
+ help
+ OpenFirmware MMC-over-SPI constructor
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 548772e..f6ee8b3 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -2,3 +2,4 @@ obj-y = base.o
obj-$(CONFIG_OF_DEVICE) += device.o platform.o
obj-$(CONFIG_OF_GPIO) += gpio.o
obj-$(CONFIG_OF_I2C) += of_i2c.o
+obj-$(CONFIG_OF_MMC_SPI) += spi_mmc.o
diff --git a/drivers/of/spi_mmc.c b/drivers/of/spi_mmc.c
new file mode 100644
index 000..90fff50
--- /dev/null
+++ b/drivers/of/spi_mmc.c
@@ -0,0 +1,122 @@
+/*
+ * OpenFirmware MMC-over-SPI constructor
+ *
+ * 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 linux/init.h
+#include linux/kernel.h
+#include linux/of_platform.h
+#include linux/spi/spi.h
+#include linux/spi/spi_of.h
+#include linux/spi/mmc_spi.h
+#include linux/mmc/host.h
+#include linux/gpio.h
+#include linux/of_gpio.h
+
+struct of_mmc_spi {
+ int wp_gpio;
+ int cd_gpio;
+ struct spi_board_info spi_binfo;
+ struct mmc_spi_platform_data mmc_pdata;
+};
+
+static int mmc_get_ro(struct device *dev)
+{
+ /* luckily spi core copies pdata pointer, not the data */
+ struct of_mmc_spi *oms = container_of(dev-platform_data,
+ struct of_mmc_spi, mmc_pdata);
+ return gpio_get_value(oms-wp_gpio);
+}
+
+static int __devinit of_mmc_spi_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ int ret = -EINVAL;
+ struct of_mmc_spi *oms = kzalloc(sizeof(*oms), GFP_KERNEL);
+ struct device_node *np = ofdev-node;
+ struct device *dev = ofdev-dev;
+ const u32 *ocr_mask;
+ int size;
+
+ if (!oms)
+ return -ENOMEM;
+
+ ocr_mask = of_get_property(np, mmc,ocr-mask, size);
+ if (ocr_mask size = sizeof(ocr_mask))
+ oms-mmc_pdata.ocr_mask = *ocr_mask;
+
+ oms-wp_gpio = of_get_gpio(np, 0);
+ if (gpio_is_valid(oms-wp_gpio)) {
+ ret = gpio_request(oms-wp_gpio, dev-bus_id);
+ if (ret 0)
+ goto err_wp_gpio;
+ oms-mmc_pdata.get_ro = mmc_get_ro;
+ }
+
+ oms-cd_gpio = of_get_gpio(np, 1);
+ if (gpio_is_valid(oms-cd_gpio)) {
+ ret = gpio_request(oms-cd_gpio, dev-bus_id);
+ if (ret 0)
+ goto err_cd_gpio;
+ }
+
+ oms-spi_binfo.platform_data = oms-mmc_pdata;
[PATCH 4/4] [POWERPC] 86xx: mpc8610_hpcd: support for MMC-over-SPI and PIXIS' GPIOs
This patch implements support for PIXIS' GPIOs and adds appropriate
nodes to support MMC-over-SPI.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 32
arch/powerpc/platforms/86xx/Kconfig|2 +
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 119
3 files changed, 153 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 44e9287..e3bf5e6 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -100,8 +100,18 @@
};
[EMAIL PROTECTED],0 {
+ #address-cells = 1;
+ #size-cells = 1;
compatible = fsl,fpga-pixis;
+ ranges = 0 3 0 0x20;
reg = 3 0 0x20;
+
+ sdcsr_pio: [EMAIL PROTECTED] {
+ #gpio-cells = 2;
+ compatible = fsl,fpga-pixis-pio;
+ reg = 0xa 1;
+ gpio-controller;
+ };
};
};
@@ -193,6 +203,28 @@
reg = 0xe4000 0x100;
};
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,mpc8610-spi, fsl,spi, simple-bus;
+ cell-index = 0;
+ reg = 0x7000 0x40;
+ interrupts = 59 2;
+ interrupt-parent = mpic;
+ mode = cpu;
+ /* gpios = sdcsr_pio 0 1; */
+
+ [EMAIL PROTECTED] {
+ compatible = linux,mmc-spi;
+ linux,modalias = mmc_spi;
+ reg = 0;
+ max-speed = 5000;
+ mmc,ocr-mask = 0x0020;
+ gpios = sdcsr_pio 6 0 /* WP */
+sdcsr_pio 7 1; /* nCD */
+ };
+ };
+
[EMAIL PROTECTED] {
compatible = fsl,mpc8610-ssi;
cell-index = 0;
diff --git a/arch/powerpc/platforms/86xx/Kconfig
b/arch/powerpc/platforms/86xx/Kconfig
index 39c02af..a7eb89c 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -22,6 +22,8 @@ config MPC8610_HPCD
bool Freescale MPC8610 HPCD
select DEFAULT_UIMAGE
select FSL_ULI1575
+ select GENERIC_GPIO
+ select HAVE_GPIO_LIB
help
This option enables support for the MPC8610 HPCD board.
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index fe163d4..9c1a56b 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -23,6 +23,9 @@
#include linux/delay.h
#include linux/seq_file.h
#include linux/of.h
+#include linux/io.h
+#include linux/gpio.h
+#include linux/of_gpio.h
#include asm/system.h
#include asm/time.h
@@ -42,6 +45,122 @@
static unsigned char *pixis_bdcfg0, *pixis_arch;
+struct px_gpio_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* mask for active-low pins */
+ u8 active_low;
+};
+
+static inline struct px_gpio_chip *
+to_px_gpio_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct px_gpio_chip, mm_gc);
+}
+
+static int px_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct px_gpio_chip *px_gc = to_px_gpio_chip(mm_gc);
+ u8 __iomem *regs = mm_gc-regs;
+ u32 pin_mask = 1 gpio;
+
+ return (in_8(regs) ^ px_gc-active_low) pin_mask;
+}
+
+static void px_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 px_gpio_chip *px_gc = to_px_gpio_chip(mm_gc);
+ u8 __iomem *regs = mm_gc-regs;
+ unsigned long flags;
+ u32 pin_mask = 1 gpio;
+
+ spin_lock_irqsave(px_gc-lock, flags);
+
+ if (((!!val gpio) ^ px_gc-active_low) pin_mask)
+ setbits8(regs, pin_mask);
+ else
+ clrbits8(regs, pin_mask);
+
+ spin_unlock_irqrestore(px_gc-lock, flags);
+}
+
+static int px_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ return 0;
+}
+
+static int px_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ px_gpio_set(gc, gpio, val);
+ return 0;
+}
+
+#define PX_GPIO_FLAG_ACTIVE_LOW(1 0)
+
+int px_gpio_xlate(struct of_gpio_chip *of_gc, struct device_node *np,
+ const void *gpio_spec)
Re: [patch 2/2] powerpc: optimise smp_wmb
On Wed, 2008-05-21 at 17:34 +0200, Nick Piggin wrote: On Wed, May 21, 2008 at 11:26:32AM -0400, Benjamin Herrenschmidt wrote: On Wed, 2008-05-21 at 16:12 +0200, Nick Piggin wrote: lwsync is the recommended method of store/store ordering on caching enabled memory. For those subarchs which have lwsync, use it rather than eieio for smp_wmb. Yuck... existence of lwsync depends on the processor at boot time... Not according to the __stringify(LWSYNC) that I just removed. At least, presumably it is always present on 64 bit processors, and 32 bit ones will be no worse off as they'll continue just using eieio. No, it doesn't exist on power3, but it degrades into a sync Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/2] powerpc: rmb fix
On Wed, 2008-05-21 at 17:32 +0200, Nick Piggin wrote: We should already do all that's needed in our IO accessors no ? More than one device driver does raw/relaxed io accessors and expects the *mb functions to order them. That's fishy... ok. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/2] powerpc: optimise smp_wmb
On Wed, May 21, 2008 at 11:43:00AM -0400, Benjamin Herrenschmidt wrote: On Wed, 2008-05-21 at 17:34 +0200, Nick Piggin wrote: On Wed, May 21, 2008 at 11:26:32AM -0400, Benjamin Herrenschmidt wrote: On Wed, 2008-05-21 at 16:12 +0200, Nick Piggin wrote: lwsync is the recommended method of store/store ordering on caching enabled memory. For those subarchs which have lwsync, use it rather than eieio for smp_wmb. Yuck... existence of lwsync depends on the processor at boot time... Not according to the __stringify(LWSYNC) that I just removed. At least, presumably it is always present on 64 bit processors, and 32 bit ones will be no worse off as they'll continue just using eieio. No, it doesn't exist on power3, but it degrades into a sync OK, but I just don't understand what the problem is... your synch.h has #ifdef __powerpc64__ #define __SUBARCH_HAS_LWSYNC #endif #ifdef __SUBARCH_HAS_LWSYNC #define LWSYNC lwsync #else #define LWSYNC sync #endif And LWSYNC is then used for rmb()... how was that OK but this not? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/DRAFT] SPI OF bindings, MMC-over-SPI, chip-selects and so on
On Wed, 21 May 2008, Anton Vorontsov wrote: This is just a bait for further discussion of OF/SPI, chip-selects, e.t.c. I've converted the spi_mpc83xx to the OF driver (using Grant's SPI_MASTER_OF work + some additions), and implemented MMC-over-SPI bindings. This stuff extensively using GPIOs, and I think this will work for the bridged SPI too, since the SPI bridge could be represented as GPIO controller (inside the SPI controller node). Yes, but do you really _want_ to represent them as GPIOs? Firstly they are not really G P, secondly, they are not even I, rather only O. And do you really want to register your SPI CS lines to the whole system for everyone's (ab)use?... Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [OF] spi_of: add support for dedicated SPI constructors
On Wed, 21 May 2008, Anton Vorontsov wrote:
Dedicated (usually the ones that need to fill platform data) constructors
will create board info, so SPI core will probe them as normal SPI devices.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/spi/spi_of.c | 67
include/linux/spi/spi_of.h |5 +++
2 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi_of.c b/drivers/spi/spi_of.c
index b5ae434..2e1a11f 100644
--- a/drivers/spi/spi_of.c
+++ b/drivers/spi/spi_of.c
@@ -11,6 +11,66 @@
#include linux/spi/spi.h
#include linux/spi/spi_of.h
+/*
+ * Caller have no idea who is master, i.e. this function does not
+ * accept pointer to the master, instead we use board infos.
+ */
+int of_spi_device_probe_common(struct device_node *np,
+struct spi_board_info *spi_binfo,
+const char *modalias)
+{
Hm, I might well misunderstand something here, but it looks to me like you
are again trying to use both OF _and_ platform (spi_board_info) bindings
for your SPI setup? And this is exactly what we are trying to avoid in
Grant's series of patches...
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/DRAFT] SPI OF bindings, MMC-over-SPI, chip-selects and so on
On Wed, May 21, 2008 at 05:54:20PM +0200, Guennadi Liakhovetski wrote: On Wed, 21 May 2008, Anton Vorontsov wrote: This is just a bait for further discussion of OF/SPI, chip-selects, e.t.c. I've converted the spi_mpc83xx to the OF driver (using Grant's SPI_MASTER_OF work + some additions), and implemented MMC-over-SPI bindings. This stuff extensively using GPIOs, and I think this will work for the bridged SPI too, since the SPI bridge could be represented as GPIO controller (inside the SPI controller node). Yes, but do you really _want_ to represent them as GPIOs? Firstly they are not really G P, secondly, they are not even I, rather only O. General Purpose Input/Output implies that lines could be only I or only O, or both. (plus dedicated function, though, here David Brownell will probably disagree ;-) GPIOs are really general. And do you really want to register your SPI CS lines to the whole system for everyone's (ab)use?... This is represented via device tree, so the only abusers could be hardware designers. :-) -- 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: [patch 2/2] powerpc: optimise smp_wmb
On Wed, May 21, 2008 at 11:43:00AM -0400, Benjamin Herrenschmidt wrote: On Wed, 2008-05-21 at 17:34 +0200, Nick Piggin wrote: On Wed, May 21, 2008 at 11:26:32AM -0400, Benjamin Herrenschmidt wrote: On Wed, 2008-05-21 at 16:12 +0200, Nick Piggin wrote: lwsync is the recommended method of store/store ordering on caching enabled memory. For those subarchs which have lwsync, use it rather than eieio for smp_wmb. Yuck... existence of lwsync depends on the processor at boot time... Not according to the __stringify(LWSYNC) that I just removed. At least, presumably it is always present on 64 bit processors, and 32 bit ones will be no worse off as they'll continue just using eieio. No, it doesn't exist on power3, but it degrades into a sync Oh, the instruction does exist, but it degrades to a sync so actually turns out to be slower than eieio? I think it would be a good idea just to take the hit on power3. From memory, I measured lwsync is 5 times faster than eieio on a dual G5. This was on a simple microbenchmark that made use of smp_wmb for store ordering, but it did not involve any IO access (which presumably would disadvantage eieio further). Given the G5 speedup, I'd be surprised if there is not an improvment on POWER4 and 5 as well, although no idea about POWER6 or cell... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/2] powerpc: optimise smp_wmb
On Wed, 2008-05-21 at 17:47 +0200, Nick Piggin wrote: OK, but I just don't understand what the problem is... your synch.h has #ifdef __powerpc64__ #define __SUBARCH_HAS_LWSYNC #endif #ifdef __SUBARCH_HAS_LWSYNC #define LWSYNC lwsync #else #define LWSYNC sync #endif This is mostly useless then since lwsync is just a sync to a processor that doesn't know it (it's a sync with a reservd bit set) :-) Or it's just to make gas happy if you specify a processor type that doesn't have lwsync ? Paul, do we have a case of a 32 bits CPU that chokes on the added bit ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
qs21 crashes during boot. Using 2.6.26-rc3.
Is this a known problem? Thx, Luke 0:mon x Unable to handle kernel paging request for data at address 0x0170 Faulting instruction address: 0xc00d8f70 cpu 0x0: Vector: 300 (Data Access) at [c07c3500] pc: c00d8f70: .kmem_cache_alloc+0x3c/0xd0 lr: c000f2dc: .alloc_thread_info+0x24/0x3c sp: c07c3780 msr: 90009032 dar: 170 dsisr: 4000 current = 0xc06a4080 paca= 0xc0833480 pid = 0, comm = swapper enter ? for help 0:mon di c00d8f70 c00d8f70 eba90170 ld r29,368(r9) c00d8f74 7fa7eb78 mr r7,r29 c00d8f78 ebfd ld r31,0(r29) c00d8f7c 2fbf cmpdi cr7,r31,0 c00d8f80 7cc802a6 mflrr6 c00d8f84 40be0010 bne cr7,c00d8f94 # .kmem_cache_alloc+0x60/0xd0 c00d8f88 4bfff559 bl c00d84e0 # .__slab_alloc+0x0/0x514 c00d8f8c 7c7f1b78 mr r31,r3 c00d8f90 4814 b c00d8fa4 # .kmem_cache_alloc+0x70/0xd0 c00d8f94 801d0014 lwz r0,20(r29) c00d8f98 78001f24 rldicr r0,r0,3,60 c00d8f9c 7c1f002a ldx r0,r31,r0 c00d8fa0 f81d std r0,0(r29) c00d8fa4 2fbc cmpdi cr7,r28,0 c00d8fa8 3860 li r3,0 c00d8fac 419e0008 beq cr7,c00d8fb4 # .kmem_cache_alloc+0x80/0xd0 0:mon r R00 = c000f2dc R16 = 4140 R01 = c07c3780 R17 = c057ba00 R02 = c07b9068 R18 = c057a3d8 R03 = R19 = R04 = 00d0 R20 = c07c3b60 R05 = R21 = c07c3de0 R06 = c0003e02002b R22 = 0001 R07 = c0003ffeec90 R23 = R08 = 0048 R24 = 00800b00 R09 = R25 = 0001 R10 = R26 = fff4 R11 = R27 = 00d0 R12 = 90009032 R28 = 0001 R13 = c0833480 R29 = c0003e13 R14 = R30 = c0721fd0 R15 = R31 = c083cb70 pc = c00d8f70 .kmem_cache_alloc+0x3c/0xd0 lr = c000f2dc .alloc_thread_info+0x24/0x3c msr = 90009032 cr = 8448 ctr = xer = trap = 300 dar = 0170 dsisr = 4000 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [OF] spi_of: add support for dedicated SPI constructors
On Wed, May 21, 2008 at 05:56:33PM +0200, Guennadi Liakhovetski wrote:
On Wed, 21 May 2008, Anton Vorontsov wrote:
Dedicated (usually the ones that need to fill platform data) constructors
will create board info, so SPI core will probe them as normal SPI devices.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/spi/spi_of.c | 67
include/linux/spi/spi_of.h |5 +++
2 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi_of.c b/drivers/spi/spi_of.c
index b5ae434..2e1a11f 100644
--- a/drivers/spi/spi_of.c
+++ b/drivers/spi/spi_of.c
@@ -11,6 +11,66 @@
#include linux/spi/spi.h
#include linux/spi/spi_of.h
+/*
+ * Caller have no idea who is master, i.e. this function does not
+ * accept pointer to the master, instead we use board infos.
+ */
+int of_spi_device_probe_common(struct device_node *np,
+ struct spi_board_info *spi_binfo,
+ const char *modalias)
+{
Hm, I might well misunderstand something here, but it looks to me like you
are again trying to use both OF _and_ platform (spi_board_info) bindings
for your SPI setup?
Yes, you didn't misunderstand. ;-)
And this is exactly what we are trying to avoid in
Grant's series of patches...
I didn't find other way... The show stopper is master argument,
drivers don't know about masters (and should not, since if they should,
then this implies that masters should be registered prior to devices,
and that complicates everything).
What is the problem with board infos, btw? I missed that part. Board
infos are good because:
1. This is how things work in real life: SPI isn't probe-able bus, so
platform code (or board code, or OF helpers) should explicitly probe
and create devices.
2. With platform infos we're probing in a Linux usual way (e.g.
master's .bus_id + chip_select matching).
--
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: [PATCH] [POWERPC] Add i2c pins to dts and board setup
Hi Scott, + - linux,i2c-index : Can be used to hard code an i2c bus number. + - linux,i2c-class : Can be used to override the i2c class. Why do we need this? There are still a bunch of i2c drivers using the old API (mainly v4l and dvb stuff) which are slowly being converted by their subsystem maintainers, though. It'd be better to just convert any needed old-style drivers than add this to the device tree. Sure. That's why the parameters are only optional. Once all i2c drivers are converted, these parameters won't be used anymore. Maybe they should be marked as deprecated. + - bus-frequency : Can be used to set the i2c bus frequency. If unspecified, + a default frequency of 60kHz is being used. clock-frequency is the standard name for such things. I was just confused by the fact that unlike a serial port, i2c is a bus itself. Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [OF] spi_of: add support for dedicated SPI constructors
On Wed, 21 May 2008, Anton Vorontsov wrote: On Wed, May 21, 2008 at 05:56:33PM +0200, Guennadi Liakhovetski wrote: Hm, I might well misunderstand something here, but it looks to me like you are again trying to use both OF _and_ platform (spi_board_info) bindings for your SPI setup? Yes, you didn't misunderstand. ;-) And this is exactly what we are trying to avoid in Grant's series of patches... I didn't find other way... The show stopper is master argument, drivers don't know about masters (and should not, since if they should, then this implies that masters should be registered prior to devices, and that complicates everything). What is the problem with board infos, btw? I missed that part. Board In short: board infos are not bad as such. I find it bad if you have to use both OF and platform bindings to describe _one_ piece of hardware. For more details you might want to re-read the thread, so, we don't have to discuss the same issues again. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCHv2] [POWERPC] Add i2c pins to dts and board setup
Initialize I2C pins on boards with CPM1/CPM2 controllers.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt | 42 ++
arch/powerpc/boot/dts/mpc8272ads.dts | 11 +++
arch/powerpc/boot/dts/mpc866ads.dts | 11 +++
arch/powerpc/boot/dts/mpc885ads.dts | 11 +++
arch/powerpc/platforms/82xx/mpc8272_ads.c|4 ++
arch/powerpc/platforms/8xx/mpc86xads_setup.c |4 ++
arch/powerpc/platforms/8xx/mpc885ads_setup.c |3 ++
7 files changed, 86 insertions(+), 0 deletions(-)
Changes since v1:
- document the fact that linux,i2c-class and linux,i2c-index are deprecated and
for old style i2c drivers only.
- fix typo nummer - number
- fix property bus-frequency - clock-frequency.
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 1d2a772..8ab9d16 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2132,6 +2132,48 @@ platforms are moved over to use the
flattened-device-tree model.
};
};
+ ix) I2C
+
+ The I2C controller is expressed as a bus under the CPM node.
+
+ Properties:
+ - compatible : fsl,cpm1-i2c, fsl,cpm2-i2c
+ - reg : On CPM2 devices, the second resource doesn't specify the I2C
+ Parameter RAM itself, but the I2C_BASE field of the CPM2 Parameter RAM
+ (typically 0x8afc 0x2).
+ - #address-cells : Should be one. The cell is the i2c device address with
+ the r/w bit set to zero.
+ - #size-cells : Should be zero.
+ - clock-frequency : Can be used to set the i2c clock frequency. If
+ unspecified, a default frequency of 60kHz is being used.
+ The following two properties are deprecated. They are only used by old style
+ i2c drivers to find the bus to probe:
+ - linux,i2c-index : Can be used to hard code an i2c bus number. By default,
+ the bus number is dynamically assigned by the i2c core.
+ - linux,i2c-class : Can be used to override the i2c class. The class is used
+ by old style i2c device drivers to find a bus in a specific context like
+ system management, video or sound. By default, I2C_CLASS_HWMON (1) is
+ being used. The definition of the classes can be found in
+ include/i2c/i2c.h
+
+ Example, based on mpc823:
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc823-i2c,
+fsl,cpm1-i2c;
+ reg = 0x860 0x20 0x3c80 0x30;
+ interrupts = 16;
+ interrupt-parent = CPM_PIC;
+ fsl,cpm-command = 0x10;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ [EMAIL PROTECTED] {
+ compatible = dallas,ds1307;
+ reg = 0x68;
+ };
+ };
+
m) Chipselect/Local Bus
Properties:
diff --git a/arch/powerpc/boot/dts/mpc8272ads.dts
b/arch/powerpc/boot/dts/mpc8272ads.dts
index 46e2da3..d27f8a7 100644
--- a/arch/powerpc/boot/dts/mpc8272ads.dts
+++ b/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -217,6 +217,17 @@
linux,network-index = 1;
fsl,cpm-command = 0x16200300;
};
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8272-i2c,
+fsl,cpm2-i2c;
+ reg = 0x11860 0x20 0x8afc 0x2;
+ interrupts = 1 8;
+ interrupt-parent = PIC;
+ fsl,cpm-command = 0x2960;
+ #address-cells = 1;
+ #size-cells = 0;
+ };
};
PIC: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc866ads.dts
b/arch/powerpc/boot/dts/mpc866ads.dts
index 765e43c..bd70065 100644
--- a/arch/powerpc/boot/dts/mpc866ads.dts
+++ b/arch/powerpc/boot/dts/mpc866ads.dts
@@ -171,6 +171,17 @@
fsl,cpm-command = ;
linux,network-index = 1;
};
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc866-i2c,
+fsl,cpm1-i2c;
+ reg = 0x860 0x20 0x3c80 0x30;
+ interrupts = 16;
+ interrupt-parent = CPM_PIC;
+ fsl,cpm-command = 0x10;
+ #address-cells = 1;
+ #size-cells = 0;
+ };
};
};
diff --git a/arch/powerpc/boot/dts/mpc885ads.dts
b/arch/powerpc/boot/dts/mpc885ads.dts
index 9895043..b123e9f 100644
--- a/arch/powerpc/boot/dts/mpc885ads.dts
+++
[PATCHv2] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
This driver uses the port of 2.4 code from Vitaly Bordug
[EMAIL PROTECTED] and the actual algorithm used by the i2c
driver of the DBox code on cvs.tuxboc.org from Felix Domke
([EMAIL PROTECTED]) and Gillem ([EMAIL PROTECTED]) converted to an
of_platform_driver. Tested on CPM1 (MPC823 on dbox2 hardware) and
CPM2 (MPC8272).
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-cpm.c | 745 ++
3 files changed, 756 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/busses/i2c-cpm.c
Changes since last version:
- change bus-frequency - clock-frequency to comply to OF standard.
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 7112a50..4aeefa6 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -350,6 +350,16 @@ config I2C_BLACKFIN_TWI_CLK_KHZ
help
The unit of the TWI clock is kHz.
+config I2C_CPM
+ tristate Freescale CPM1 or CPM2 (MPC8xx/826x)
+ depends on (CPM1 || CPM2) OF_I2C
+ help
+ This supports the use of the I2C interface on Freescale
+ processors with CPM1 or CPM2.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-cpm.
+
config I2C_DAVINCI
tristate DaVinci I2C driver
depends on ARCH_DAVINCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 3c56bd9..bc6fc36 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_I2C_ACORN) += i2c-acorn.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
+obj-$(CONFIG_I2C_CPM) += i2c-cpm.o
obj-$(CONFIG_I2C_DAVINCI) += i2c-davinci.o
obj-$(CONFIG_I2C_ELEKTOR) += i2c-elektor.o
obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
new file mode 100644
index 000..2977dd0
--- /dev/null
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -0,0 +1,745 @@
+/*
+ * Freescale CPM1/CPM2 I2C interface.
+ * Copyright (c) 1999 Dan Malek ([EMAIL PROTECTED]).
+ *
+ * moved into proper i2c interface;
+ * Brad Parker ([EMAIL PROTECTED])
+ *
+ * Parts from dbox2_i2c.c (cvs.tuxbox.org)
+ * (C) 2000-2001 Felix Domke ([EMAIL PROTECTED]), Gillem ([EMAIL PROTECTED])
+ *
+ * (C) 2007 Montavista Software, Inc.
+ * Vitaly Bordug [EMAIL PROTECTED]
+ *
+ * Converted to of_platform_device. Renamed to i2c-cpm.c.
+ * (C) 2007,2008 Jochen Friedrich [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.
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/delay.h
+#include linux/slab.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/errno.h
+#include linux/stddef.h
+#include linux/i2c.h
+#include linux/io.h
+#include linux/dma-mapping.h
+#include linux/of_device.h
+#include linux/of_platform.h
+#include linux/of_i2c.h
+#include sysdev/fsl_soc.h
+#include asm/cpm.h
+
+/* Try to define this if you have an older CPU (earlier than rev D4) */
+/* However, better use a GPIO based bitbang driver in this case :/ */
+#undef I2C_CHIP_ERRATA
+
+#define CPM_MAX_READ513
+#define CPM_MAXBD 4
+
+#define I2C_EB (0x10) /* Big endian mode */
+#define I2C_EB_CPM2(0x30) /* Big endian mode, memory snoop */
+
+#define DPRAM_BASE ((u8 __iomem __force *)cpm_muram_addr(0))
+
+/* I2C parameter RAM. */
+struct i2c_ram {
+ ushort rbase; /* Rx Buffer descriptor base address */
+ ushort tbase; /* Tx Buffer descriptor base address */
+ u_char rfcr; /* Rx function code */
+ u_char tfcr; /* Tx function code */
+ ushort mrblr; /* Max receive buffer length */
+ uintrstate; /* Internal */
+ uintrdp;/* Internal */
+ ushort rbptr; /* Rx Buffer descriptor pointer */
+ ushort rbc;/* Internal */
+ uintrxtmp; /* Internal */
+ uinttstate; /* Internal */
+ uinttdp;/* Internal */
+ ushort
Re: [patch v2] PS3: Fix memory hotplug
Geoff Levand wrote: A change was made to walk_memory_resource() in commit 4b119e21d0c66c22e8ca03df05d9de623d0eb50f that added a check of find_lmb(). Add the coresponding lmb_add() call to ps3_mm_add_memory() so that that check will succeed. This fixes the condition where the PS3 boots up with only the 128 MiB of boot memory. Signed-off-by: Geoff Levand [EMAIL PROTECTED] --- v2: Add call to lmb_analyze(). arch/powerpc/platforms/ps3/mm.c |3 +++ 1 file changed, 3 insertions(+) --- a/arch/powerpc/platforms/ps3/mm.c +++ b/arch/powerpc/platforms/ps3/mm.c @@ -317,6 +317,9 @@ static int __init ps3_mm_add_memory(void return result; } + lmb_add(start_addr, map.r1.size); + lmb_analyze(); + result = online_pages(start_pfn, nr_pages); if (result) Hi Paul, Could you please merge this one in for 2.6.26. Without it the system boots with just 128 of the total 256 MiB of memory. There is the concurrency problem as Ben commented on, but I think not having the 128 MiB of memory is worse than having the potential race, which we can work on as a separate fix. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [OF] spi_of: add support for dedicated SPI constructors
On Wed, May 21, 2008 at 06:24:58PM +0200, Guennadi Liakhovetski wrote: On Wed, 21 May 2008, Anton Vorontsov wrote: On Wed, May 21, 2008 at 05:56:33PM +0200, Guennadi Liakhovetski wrote: Hm, I might well misunderstand something here, but it looks to me like you are again trying to use both OF _and_ platform (spi_board_info) bindings for your SPI setup? Yes, you didn't misunderstand. ;-) And this is exactly what we are trying to avoid in Grant's series of patches... I didn't find other way... The show stopper is master argument, drivers don't know about masters (and should not, since if they should, then this implies that masters should be registered prior to devices, and that complicates everything). What is the problem with board infos, btw? I missed that part. Board In short: board infos are not bad as such. I find it bad if you have to use both OF and platform bindings to describe _one_ piece of hardware. This particular discussion isn't about describing hardware (since we're describing it via device tree), but about implementation details, such as: 1. Passing platform_data to the drivers; 2. Creating SPI Linux devices from the OF description. I see there ways: 1. Grant Likely's approach (works great for simple drivers which don't need SPI platform_data). 2. Old board infos approach, there we can do whatever we want. 3. Implementing OF bindings for the every SPI driver that needs platform_data. I could do 3, let's see what it will look like... -- 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: [PATCH 1/4] [SPI] spi_mpc83xx: convert to the OF platform driver
On Wed, May 21, 2008 at 9:41 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
This patch converts the driver to speak OF directly. FSL SPI controllers
do not use internal chip-select machines, so boards must use GPIOs for
these purposes.
Mostly this looks good to me, but I didn't look
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt |1 +
drivers/spi/Kconfig |3 +-
drivers/spi/spi_mpc83xx.c| 279
+-
3 files changed, 184 insertions(+), 99 deletions(-)
@@ -536,92 +539,152 @@ static void mpc83xx_spi_cleanup(struct spi_device *spi)
kfree(spi-controller_state);
}
-static int __init mpc83xx_spi_probe(struct platform_device *dev)
+static unsigned int of_num_children(struct device_node *parent)
+{
+ unsigned int count = 0;
+ struct device_node *child = NULL;
+
+ for_each_child_of_node(parent, child)
+ count++;
+
+ return count;
+}
This smells like it should be in common of code; but I don't think
this routine is needed at all (see below)
[...]
- if (master == NULL) {
+ bus_num = of_get_property(np, reg, size);
+ if (!bus_num || size sizeof(*bus_num)) {
+ dev_err(dev, unable to get reg property from OF\n);
+ ret = -EINVAL;
+ goto err_bus_num;
+ }
+ master-bus_num = *bus_num;
Does the driver really need to define its own bus num? I know your
using it for binding with a board info structure, but I think there
are better ways to do it (I'll elaborate in my reply to your patch
that adds support for boardinfo structures). It's better to let the
SPI infrastructure assign an SPI bus number. and use other methods to
ensure that extra data is provided to the driver. Besides, there is
no guarantee that 'reg' will be unique.
+
+ master-num_chipselect = of_num_children(np);
This assumes that there are no gaps in the assigned CS numbers of
child nodes, or that the child nodes are an exhaustive list of
attached devices, neither of which may be true. num_chipselect should
be calculated from the number of GPIOs specified instead.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/DRAFT] SPI OF bindings, MMC-over-SPI, chip-selects and so on
On Wed, May 21, 2008 at 9:41 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: Hi all, This is just a bait for further discussion of OF/SPI, chip-selects, e.t.c. I've converted the spi_mpc83xx to the OF driver (using Grant's SPI_MASTER_OF work + some additions), and implemented MMC-over-SPI bindings. This stuff extensively using GPIOs, and I think this will work for the bridged SPI too, since the SPI bridge could be represented as GPIO controller (inside the SPI controller node). The GPIOs case doesn't bother me too much. If the controller supports GPIO chip selects (and pretty much all of them could I think) then the SPI master driver just needs to specify that it supports N chip selects and have a gpios property that lists all the relevant GPIOs (just like you've done). So I think this bit is looking good. More complex cases would still probably need some form of spi-bridge node (and most likely requiring changes to the SPI infrastructure to make bridging easy; but that is just driver details). The board info handling I think requires more thought... (details in another email) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] [SPI] spi_mpc83xx: convert to the OF platform driver
On Wed, May 21, 2008 at 10:50:02AM -0600, Grant Likely wrote: [..] + + master-num_chipselect = of_num_children(np); This assumes that there are no gaps in the assigned CS numbers of child nodes, or that the child nodes are an exhaustive list of attached devices, neither of which may be true. num_chipselect should be calculated from the number of GPIOs specified instead. [I'm not arguing just a thought.] - every SPI device must have its own chip-select, otherwise SPI device node should not be a part of a SPI controller node; - or there is just once device on the SPI bus with chip-select always asserted, no gpios = is specified (this case is implemented); - or the SPI is bridged, gpios = should list behind-the-bridge devices' chip-selects, and driver should understand that there is a special (bridge) device somewhere on the bus (not implemented). -- 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: [PATCH 2/4] [OF] spi_of: add support for dedicated SPI constructors
On Wed, May 21, 2008 at 10:48 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: On Wed, May 21, 2008 at 06:24:58PM +0200, Guennadi Liakhovetski wrote: On Wed, 21 May 2008, Anton Vorontsov wrote: On Wed, May 21, 2008 at 05:56:33PM +0200, Guennadi Liakhovetski wrote: Hm, I might well misunderstand something here, but it looks to me like you are again trying to use both OF _and_ platform (spi_board_info) bindings for your SPI setup? Yes, you didn't misunderstand. ;-) And this is exactly what we are trying to avoid in Grant's series of patches... I didn't find other way... The show stopper is master argument, drivers don't know about masters (and should not, since if they should, then this implies that masters should be registered prior to devices, and that complicates everything). What is the problem with board infos, btw? I missed that part. Board In short: board infos are not bad as such. I find it bad if you have to use both OF and platform bindings to describe _one_ piece of hardware. Sonething to note: 'platform bindings' is the wrong terminology. I'd like to be careful here because the term 'platform' is already overloaded and leads to confusion. Specifically, the 'platform bus' doesn't come into play at all here and 'platform code' simply refers to the board specific code in arch/powerpc/platforms. Really, the discussion is between using 'board info' to pass data vs. using the OF api. This particular discussion isn't about describing hardware (since we're describing it via device tree), but about implementation details, such as: 1. Passing platform_data to the drivers; 2. Creating SPI Linux devices from the OF description. I see there ways: 1. Grant Likely's approach (works great for simple drivers which don't need SPI platform_data). 2. Old board infos approach, there we can do whatever we want. 3. Implementing OF bindings for the every SPI driver that needs platform_data. or perhaps: 4. allow platform code to pass supplementary board info to specific spi devices when appropriate (so the '1.' path is always used, but it can also parse a board info structure if one is provided. This is different from '2.' which short circuits the spi_of path entirely). I concede that sometimes platform code just has to pass data to the driver that cannot be described in the device tree. callback pointers being the most significant example and we do need a sane way to do so. That being said; in most cases I'd much rather see code added to the driver itself to extract data from the device tree. This has the advantage that the data transformation code stays with the driver where it belongs and it keeps code common as much as possible (discourage duplication of code in the platform directories). Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] [SPI] spi_mpc83xx: convert to the OF platform driver
On Wed, May 21, 2008 at 11:05 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: On Wed, May 21, 2008 at 10:50:02AM -0600, Grant Likely wrote: [..] + + master-num_chipselect = of_num_children(np); This assumes that there are no gaps in the assigned CS numbers of child nodes, or that the child nodes are an exhaustive list of attached devices, neither of which may be true. num_chipselect should be calculated from the number of GPIOs specified instead. [I'm not arguing just a thought.] :-) Here's some quick feedback off the top of my head... - every SPI device must have its own chip-select, otherwise SPI device node should not be a part of a SPI controller node; How about this example: Board has SPI controller with 4 CS lines and 4 devices. Board vendor has 3 versions of board with different devices populated (Ver1 has all 4; Ver2 has 1 and 3; Ver3 has 1, 3 and 4). Board firmware drops nodes from tree for non-present devices before booting kernel (not arguing if this is the best way for firmware to behave; but it is valid and legal). Therefore there may be gaps in the CS assignments. Or how about this one: the SPI devices are off board and are plugged in after boot. They aren't available to be described in the device tree, but are added at a later time in response to some hot plug event. The SPI bus needs to be already set up with the correct number of CS lines. I don't think you can assume that the device tree data will be exhaustive. - or there is just once device on the SPI bus with chip-select always asserted, no gpios = is specified (this case is implemented); - or the SPI is bridged, gpios = should list behind-the-bridge devices' chip-selects, and driver should understand that there is a special (bridge) device somewhere on the bus (not implemented). In this case, I think the gpios would be a property of the spi-bridge, not the spi-master. The gpios of the spi-master would have to specify how to address the bridge; not the downstream devices. The bridge; when addressed correctly; would then proceed with addressing the downstream. In other words; the 'reg' of spi-devices attached to a bridge would be an address that the bridge understands, not an address that the master understands. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [OF] spi_of: add support for dedicated SPI constructors
On Wed, May 21, 2008 at 9:41 AM, Anton Vorontsov
[EMAIL PROTECTED] wrote:
Dedicated (usually the ones that need to fill platform data) constructors
will create board info, so SPI core will probe them as normal SPI devices.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/spi/spi_of.c | 67
include/linux/spi/spi_of.h |5 +++
2 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi_of.c b/drivers/spi/spi_of.c
index b5ae434..2e1a11f 100644
--- a/drivers/spi/spi_of.c
+++ b/drivers/spi/spi_of.c
@@ -11,6 +11,66 @@
#include linux/spi/spi.h
#include linux/spi/spi_of.h
+/*
+ * Caller have no idea who is master, i.e. this function does not
+ * accept pointer to the master, instead we use board infos.
+ */
+int of_spi_device_probe_common(struct device_node *np,
+ struct spi_board_info *spi_binfo,
+ const char *modalias)
+{
+ struct device_node *parent;
+ const u32 *bus_num;
+ const u32 *chip_select;
+ const u32 *max_speed;
+ int size;
+
+ parent = of_get_parent(np);
+ if (!parent) {
+ pr_err(%s: no parent\n, np-full_name);
+ return -EINVAL;
+ }
+
+ bus_num = of_get_property(parent, reg, size);
+ if (!bus_num || size sizeof(*bus_num)) {
+ pr_err(%s: no reg specified for parent\n, np-full_name);
+ of_node_put(parent);
+ return -EINVAL;
+ }
+ spi_binfo-bus_num = *bus_num;
+ of_node_put(parent);
+
+ chip_select = of_get_property(np, reg, size);
+ if (!chip_select || size sizeof(*chip_select)) {
+ pr_err(%s: no reg (chip-select) specified\n, np-full_name);
+ return -EINVAL;
+ }
+ spi_binfo-chip_select = *chip_select;
+
+ max_speed = of_get_property(np, max-speed, size);
+ if (!max_speed || size sizeof(*max_speed))
+ spi_binfo-max_speed_hz = 10;
+ else
+ spi_binfo-max_speed_hz = *max_speed;
+
+ strcpy(spi_binfo-modalias, modalias);
+
+ /*
+* spi_of_register_devices() should not probe this device, it will
+* be managed by the dedicated driver.
+*/
+ np-data = spi_binfo;
+
+ return 0;
+}
+EXPORT_SYMBOL(of_spi_device_probe_common);
This is mostly a duplication of stuff in spi_of_register_devices() and
it short circuits that path. While I'm not hugely fond of boardinfo
in general, I'd much rather see it passed via spi_of_register_devices
instead of using a different path. I know we've discussed this before
and I resisted settling on a solution (like adding a specific
platform_data pointer instead of using device_node-data) mostly
because I'm being cautious. I still don't know if it would be better
to use a device_node value or to have some form of callback into the
boards platform code. But, either method would be better than having
multiple paths for registering SPI devices which are described in the
device tree.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/DRAFT] SPI OF bindings, MMC-over-SPI, chip-selects and so on
On Wed, May 21, 2008 at 9:41 AM, Anton Vorontsov [EMAIL PROTECTED] wrote: Hi all, This is just a bait for further discussion of OF/SPI, chip-selects, e.t.c. BTW; [EMAIL PROTECTED] should probably be CC'd on the next posting of this series. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] 4xx hardware watchpoint support
Hi,
This is a patch that has been sitting idle for quite some time. I
decided to move it further because it is something useful. It was
originally written by Michel Darneille, based off of 2.6.16.
The original patch, though, was not compatible with the current DABR
logic. DABR's are used to implement hardware watchpoint support for
ppc64 processors (i.e. 970, Power5 etc). 4xx's have a different
debugging register layout and needs to be handled differently (they two
registers: DAC and DBCR0).
I've refreshed the patch to a recent stable release (2.6.25.1, still
apllies cleanly on 2.6.25.4), made the patch compatible with both 4xx
and ppc64 processor designs, fixed some masks that didn't seem correct
(the ones setting hw watch read/write modes) and refactored some of the
code.
Though, i'm still not happy enough with the patch as i think we could
improve it a bit further. Some points i consider worth of attention:
1) There is a do_dac(...) implementation inside
arch/powerpc/kernel/traps.c. I don't feel this is correct. I see that
the 64-bit counterpart, do_dabr(...), is implemented inside
arch/powerpc/mm/fault.c. Due to do_dac(...) being implemented inside
traps.c, we need to externalize the declaration for get_dac(...) on
include/asm-[powerpc|ppc]/system.h so it's made visible to that scope.
We could use mfspr(...) to get the register's contents directly, but
then i wouldn't make sense to have get_dac(...) in the first place.
Maybe moving the do_dac(...) code to arch/powerpc/mm/fault.c would make
more sense since we seem to have the address already, and won't need to
call get_dac(...) to get it.
2) The change to make set_debugreg(...) and get_debugreg(...)
transparent for both DAC-driven and DABR-driven processors is OK. But
that shouldn't require us to externalize the declaration of
set_debugreg(...) in order to use it in arch/powerpc/kernel/traps.c
right? Maybe this has some relationship with the above point.
3) Maybe it would be better to come up with a way to merge both DABR and
DAC/DBCR0 logic in order to get rid of dozens of processor-specific
#ifdef's? This could be a bit more complex since it would require
re-writing good portions of code.
4) Should i use CONFIG_40x ou CONFIG_4xx instead? Would CONFIG_4xx
automatically include 40x's? I'm mainly targetting 4xx's here, though
40x's should be similar except for 403.
5) This is something i'm worried about for future features. We currently
have a way to support only Hardware Watchpoints, but not Hardware
Breakpoints (on 64-bit processors that have a IABR register or 32-bit
processors carrying the IAC register). Looking at the code, we don't
differentiate a watchpoint from a breakpoint request. A ptrace call has
currently 3 arguments: REQUEST, ADDR and DATA. We use REQUEST and DATA
to set a hardware watchpoint. Maybe we could use the ADDR parameter to
set a hardware breakpoint? Or use it to tell the kernel whether we want
a hardware watchpoint or hardware breakpoint and then pass the address
of the instruction/data through the DATA parameter? What do you think?
I appreciate any comments about these items and the patch itself.
Best regards.
Luis
Index: linux-2.6.25.1/arch/powerpc/kernel/process.c
===
--- linux-2.6.25.1.orig/arch/powerpc/kernel/process.c 2008-05-21 07:25:45.0 -0700
+++ linux-2.6.25.1/arch/powerpc/kernel/process.c 2008-05-21 07:26:55.0 -0700
@@ -219,6 +219,28 @@
}
#endif /* CONFIG_SPE */
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+
+/* Add support for HW Debug breakpoint. Use DAC register. */
+int set_dac(unsigned long dac)
+{
+ mtspr(SPRN_DAC1, dac);
+
+ return 0;
+}
+unsigned int get_dac()
+{
+ return mfspr(SPRN_DAC1);
+}
+int set_dbcr0(unsigned long dbcr)
+{
+ mtspr(SPRN_DBCR0, dbcr);
+
+ return 0;
+}
+
+#endif
+
#ifndef CONFIG_SMP
/*
* If we are doing lazy switching of CPU state (FP, altivec or SPE),
@@ -330,6 +352,13 @@
if (unlikely(__get_cpu_var(current_dabr) != new-thread.dabr))
set_dabr(new-thread.dabr);
+
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ /* If new thread DAC (HW breakpoint) is the same then leave it. */
+ if (new-thread.dac)
+ set_dac(new-thread.dac);
+#endif
+
new_thread = new-thread;
old_thread = current-thread;
@@ -515,6 +544,16 @@
discard_lazy_cpu_state();
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ if (current-thread.dac) {
+ current-thread.dac = 0;
+ /* Clear debug control. */
+ current-thread.dbcr0 = ~(DBSR_DAC1R | DBSR_DAC1W);
+
+ set_dac(0);
+ }
+#endif
+
if (current-thread.dabr) {
current-thread.dabr = 0;
set_dabr(0);
Index: linux-2.6.25.1/arch/powerpc/kernel/ptrace.c
===
--- linux-2.6.25.1.orig/arch/powerpc/kernel/ptrace.c 2008-05-21 07:25:45.0 -0700
+++ linux-2.6.25.1/arch/powerpc/kernel/ptrace.c 2008-05-21 08:23:34.0 -0700
@@ -629,9 +629,15 @@
{
struct pt_regs *regs =
[2.6 patch] powerpc/boot/Makefile CONFIG_ variable fixes
This patch corrects the names of two CONFIG_ variables. Note that the CONFIG_MPC86XADS fix uncovers another bug (with mpc866_ads_defconfig) that will require fixing: -- snip -- ... arch/powerpc/boot/dtc -O dtb -o arch/powerpc/boot/mpc866ads.dtb -b 0 /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/mpc866ads.dts DTC: dts-dtb on file /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc/boot/dts/mpc866ads.dts WRAParch/powerpc/boot/cuImage.mpc866ads powerpc64-linux-ld: arch/powerpc/boot/cuboot-mpc866ads.o: No such file: No such file or directory make[2]: *** [arch/powerpc/boot/cuImage.mpc866ads] Error 1 -- snip -- Reported-by: Robert P. J. Day [EMAIL PROTECTED] Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- 9a0137fa7d60e7ee62ae4e08e3e5b7d94b66debf diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 7822d25..cfb6983 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -221,8 +221,8 @@ image-$(CONFIG_WARP)+= cuImage.warp image-$(CONFIG_YOSEMITE) += cuImage.yosemite # Board ports in arch/powerpc/platform/8xx/Kconfig -image-$(CONFIG_PPC_MPC86XADS) += cuImage.mpc866ads -image-$(CONFIG_PPC_MPC885ADS) += cuImage.mpc885ads +image-$(CONFIG_MPC86XADS) += cuImage.mpc866ads +image-$(CONFIG_MPC885ADS) += cuImage.mpc885ads image-$(CONFIG_PPC_EP88XC) += dtbImage.ep88xc image-$(CONFIG_PPC_ADDER875) += cuImage.adder875-uboot \ dtbImage.adder875-redboot ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [OF] spi_of: add support for dedicated SPI constructors
On Wed, 21 May 2008, Grant Likely wrote: I concede that sometimes platform code just has to pass data to the driver that cannot be described in the device tree. callback pointers being the most significant example and we do need a sane way to do so. Sorry, I just cannot understand. So far my understanding was, that OF bindings were there to _completely_ describe hardware, that cannot be autoconfigured or probed. So a _generic_ driver gets all information it needs from the device tree and needs no additional information to handle the hardware. Now if a driver needs additional information from platform code what's the purpose of partial data in the device tree at all? Just use board information as usual. What good is an OF-binding if it doesn't provide complete information? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
On Fri, 2008-04-18 at 16:44 +1000, Benjamin Herrenschmidt wrote: so what about the patch below ? I like it, but the compiler won't ;) If you're ok, I'll re-send with appropriate sob adapted powerpc part. Sure. +void __init __attribute__((weak) thread_info_cache_init(void) Back to this old subject... I'm having reports that this is not working... gcc is seeing the empty weak function and is optimizing it out before it gets a chance to link to the arch provided one. This would affect that and the other one next to it.. That seems pretty bad... it causes nasty crashes as we end up having no idea what the compiler decided to generate... I suppose we could keep the weak stubs out of the file where they are called but that sucks. ie. This is some form of gcc 4.1.1 Is that a known problem ? A gcc issue ? Not sure what is expected from those weak functions. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
1 GB lowmem
Hi I am trying to enable 1 GB of lowmem on a Freescale 8280. In arch/ppc this was easilly done by: CONFIG_ADVANCED_OPTIONS=y CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE_BOOL=y CONFIG_LOWMEM_SIZE=0x4000 CONFIG_KERNEL_START_BOOL=y CONFIG_KERNEL_START=0xa000 This does not work in arch/powerpc. CPU hangs as soon as init starts. Any ideas what to look at, what to change? The reason I want to do this is because I cannot get highmem support to work when using CONFIG_PREEMPT_RT. (hitting a bug_on in kmap_atomic) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PS3: Fix memory hotplug
Paul Mackerras wrote: Benjamin Herrenschmidt writes: When you do an lmb_add you should probably also do an lmb_analyze to update the total memory count etc... That leads to some interesting issues such as the LMB stuff wasn't really meant to be dynamically modified after boot, and thus the kernel has no locks in there. That can be an issue... Paul, any thoughts here ? Should we add a lock ? That would mean being careful as the LMB stuff can be called very early, and spinlock wants things like PACA and possibly lockdep to be around.. Either that, or we give in and use iomem_resource to track where system RAM is, as well as the other things in the physical address space, like other architectures do... The generic hot plug routines already use iomem_resource (mm/memory_hotplug.c). Both __add_pages() and add_memory() add the new mem to iomem_resource, and so it seems there is no need for the powerpc specific walk_memory_resource(), since the generic one does its check with iomem_resource. I need to look a little closer at how the pSeries does its memory hot plug, but I think removing the powerpc specific walk_memory_resource() won't effect pSeries since it seems to have its own hot plug routines that do their own thing entirely with lmb. It doesn't seem that it would be difficult to make the pSeries hot plug code to use iomem_resource, but some of the generic hot plug routines cannot be called until fairly late in the startup. The other thing to do then would be to change the other powerpc startup code to use iomem_resource instead of lmb. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add cuImage.mpc866ads to the bootwrapper as a cuboot-8xx target.
As pointed out by Adrian Bunk. Signed-off-by: Scott Wood [EMAIL PROTECTED] --- arch/powerpc/boot/wrapper |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper index d6c96d9..3b59e33 100755 --- a/arch/powerpc/boot/wrapper +++ b/arch/powerpc/boot/wrapper @@ -159,7 +159,7 @@ cuboot*) binary=y gzip= case $platform in -*-mpc885ads|*-adder875*|*-ep88xc) +*-mpc866ads|*-mpc885ads|*-adder875*|*-ep88xc) platformo=$object/cuboot-8xx.o ;; *5200*|*-motionpro) -- 1.5.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
On Wed, 21 May 2008 13:56:25 -0400 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
On Fri, 2008-04-18 at 16:44 +1000, Benjamin Herrenschmidt wrote:
so what
about the patch below ?
I like it, but the compiler won't ;)
If you're ok, I'll re-send with appropriate sob
adapted powerpc part.
Sure.
+void __init __attribute__((weak) thread_info_cache_init(void)
Back to this old subject...
I'm having reports that this is not working...
gcc is seeing the empty weak function and is optimizing it out
before it gets a chance to link to the arch provided one.
This would affect that and the other one next to it..
That seems pretty bad... it causes nasty crashes as we end up having no
idea what the compiler decided to generate... I suppose we could keep
the weak stubs out of the file where they are called but that sucks.
ie. This is some form of gcc 4.1.1
Is that a known problem ? A gcc issue ? Not sure what is expected from
those weak functions.
yup, gcc bug. Discussed recently on lkml, Subject: Re: huge gcc
4.1.{0,1} __weak problem. I don't think anything ended up happening
about it though.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] [MMC] mmc_spi: add polling support for the card detect line
On Sat, May 17, 2008 at 01:36:33PM +0200, Pierre Ossman wrote: On Fri, 16 May 2008 20:50:57 +0400 Anton Vorontsov [EMAIL PROTECTED] wrote: Some boards do not use interrupts on the CD line, so we want to poll the CD and see if there was a change. 1 second poll interval seems resonable. The idea isn't bad, but I'm not sure about the mechanism. To poll a MMC slot, you do not really need a card detect at all. The MMC layer can just shoot off some requests and see if anything responds. The PXA driver (if my memory serves me right) already does this. So the best idea there would be to add this feature to the MMC core and let the host indicate that it needs it via MMC_CAP_NEEDS_POLL or something like that. The card detection pin then becomes an optimisation, something that is also useful in other ways. Have the host driver check the card detection pin at the start of every request, and quickly fail it if there is no card present. Calling get_cd() for every request smells like overhead, especially given that that get_cd() could ask for GPIO status via relatively slow bus (like I2C GPIO expanders). So, polling seems most reasonable solution here, no need to call it very often. How about these patches? Tested with and without get_cd() optimization. -- 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 1/2] mmc: add support for card-detection polling
Some hosts (and boards that use mmc_spi) do not use interrupts on the CD
line, so they can't trigger mmc_detect_change. We want to poll the card
and see if there was a change. 1 second poll interval seems resonable.
This patch also implements .get_cd() host operation, that could be used
by the hosts that are able to report card-detect status without need to
talk MMC.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/mmc/core/core.c | 19 ---
include/linux/mmc/host.h |3 +++
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 01ced4c..e455ebd 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -631,6 +631,16 @@ void mmc_rescan(struct work_struct *work)
mmc_bus_get(host);
+ if (host-ops-get_cd) {
+ int old_cd_status = host-cd_status;
+
+ host-cd_status = !!host-ops-get_cd(host);
+ if (!(old_cd_status ^ host-cd_status)) {
+ mmc_bus_put(host);
+ goto out;
+ }
+ }
+
if (host-bus_ops == NULL) {
/*
* Only we can add a new handler, so it's safe to
@@ -652,7 +662,7 @@ void mmc_rescan(struct work_struct *work)
if (!err) {
if (mmc_attach_sdio(host, ocr))
mmc_power_off(host);
- return;
+ goto out;
}
/*
@@ -662,7 +672,7 @@ void mmc_rescan(struct work_struct *work)
if (!err) {
if (mmc_attach_sd(host, ocr))
mmc_power_off(host);
- return;
+ goto out;
}
/*
@@ -672,7 +682,7 @@ void mmc_rescan(struct work_struct *work)
if (!err) {
if (mmc_attach_mmc(host, ocr))
mmc_power_off(host);
- return;
+ goto out;
}
mmc_release_host(host);
@@ -683,6 +693,9 @@ void mmc_rescan(struct work_struct *work)
mmc_bus_put(host);
}
+out:
+ if (host-caps MMC_CAP_NEEDS_POLL)
+ mmc_schedule_delayed_work(host-detect, HZ);
}
void mmc_start_host(struct mmc_host *host)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 7ab962f..05d03a4 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -53,6 +53,7 @@ struct mmc_host_ops {
void(*request)(struct mmc_host *host, struct mmc_request *req);
void(*set_ios)(struct mmc_host *host, struct mmc_ios *ios);
int (*get_ro)(struct mmc_host *host);
+ int (*get_cd)(struct mmc_host *host);
void(*enable_sdio_irq)(struct mmc_host *host, int enable);
};
@@ -94,6 +95,7 @@ struct mmc_host {
#define MMC_CAP_SD_HIGHSPEED (1 3)/* Can do SD high-speed timing
*/
#define MMC_CAP_SDIO_IRQ (1 4)/* Can signal pending SDIO IRQs
*/
#define MMC_CAP_SPI(1 5)/* Talks only SPI protocols */
+#define MMC_CAP_NEEDS_POLL (1 6)/* Needs polling for
card-detection */
/* host specific block data */
unsigned intmax_seg_size; /* see
blk_queue_max_segment_size */
@@ -114,6 +116,7 @@ struct mmc_host {
unsigned intuse_spi_crc:1;
unsigned intclaimed:1; /* host exclusively claimed */
unsigned intbus_dead:1; /* bus has been released */
+ unsigned intcd_status:1;/* card-detect status */
#ifdef CONFIG_MMC_DEBUG
unsigned intremoved:1; /* host is being removed */
#endif
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] mmc_spi: add support for card-detection polling
If platform_data lacks init() callback (solely used to request
card-detect interrupt), we mark the host as MMC_CAP_NEEDS_POLL.
get_cd() host operation provided to optimize polling.
p.s. Since mmc_host_ops no longer the same for every instance of
mmc_spi, struct mmc_host_ops can't be const and should be allocated
dynamically.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/mmc/host/mmc_spi.c | 31 +--
include/linux/spi/mmc_spi.h |6 ++
2 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index 3550858..667855a 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -115,6 +115,7 @@ struct scratch {
struct mmc_spi_host {
struct mmc_host *mmc;
+ struct mmc_host_ops mmc_spi_ops;
struct spi_device *spi;
unsigned char power_mode;
@@ -1131,13 +1132,12 @@ static int mmc_spi_get_ro(struct mmc_host *mmc)
return 0;
}
+static int mmc_spi_get_cd(struct mmc_host *mmc)
+{
+ struct mmc_spi_host *host = mmc_priv(mmc);
-static const struct mmc_host_ops mmc_spi_ops = {
- .request= mmc_spi_request,
- .set_ios= mmc_spi_set_ios,
- .get_ro = mmc_spi_get_ro,
-};
-
+ return host-pdata-get_cd(mmc-parent);
+}
//
@@ -1236,8 +1236,12 @@ static int mmc_spi_probe(struct spi_device *spi)
mmc = mmc_alloc_host(sizeof(*host), spi-dev);
if (!mmc)
goto nomem;
+ host = mmc_priv(mmc);
- mmc-ops = mmc_spi_ops;
+ host-mmc_spi_ops.request = mmc_spi_request,
+ host-mmc_spi_ops.set_ios = mmc_spi_set_ios,
+ host-mmc_spi_ops.get_ro = mmc_spi_get_ro,
+ mmc-ops = host-mmc_spi_ops;
mmc-max_blk_size = MMC_SPI_BLOCKSIZE;
/* As long as we keep track of the number of successfully
@@ -1256,7 +1260,6 @@ static int mmc_spi_probe(struct spi_device *spi)
mmc-f_min = 40;
mmc-f_max = spi-max_speed_hz;
- host = mmc_priv(mmc);
host-mmc = mmc;
host-spi = spi;
@@ -1323,13 +1326,21 @@ static int mmc_spi_probe(struct spi_device *spi)
if (status != 0)
goto fail_add_host;
- dev_info(spi-dev, SD/MMC host %s%s%s%s\n,
+ if (host-pdata !host-pdata-init)
+ mmc-caps |= MMC_CAP_NEEDS_POLL;
+
+ if (host-pdata host-pdata-get_cd)
+ host-mmc_spi_ops.get_cd = mmc_spi_get_cd;
+
+ dev_info(spi-dev, SD/MMC host %s%s%s%s%s\n,
mmc-class_dev.bus_id,
host-dma_dev ? : , no DMA,
(host-pdata host-pdata-get_ro)
? : , no WP,
(host-pdata host-pdata-setpower)
- ? : , no poweroff);
+ ? : , no poweroff,
+ (mmc-caps MMC_CAP_NEEDS_POLL)
+ ? , cd polling : );
return 0;
fail_add_host:
diff --git a/include/linux/spi/mmc_spi.h b/include/linux/spi/mmc_spi.h
index d5ca78b..915faf3 100644
--- a/include/linux/spi/mmc_spi.h
+++ b/include/linux/spi/mmc_spi.h
@@ -23,6 +23,12 @@ struct mmc_spi_platform_data {
/* sense switch on sd cards */
int (*get_ro)(struct device *);
+ /*
+* if board does not use CD interrupts, driver can poll the CD
+* line using this function.
+*/
+ int (*get_cd)(struct device *);
+
/* how long to debounce card detect, in msecs */
u16 detect_delay;
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
On Wed, May 21, 2008 at 11:41:47AM -0700, Andrew Morton wrote:
On Wed, 21 May 2008 13:56:25 -0400 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
On Fri, 2008-04-18 at 16:44 +1000, Benjamin Herrenschmidt wrote:
so what
about the patch below ?
I like it, but the compiler won't ;)
If you're ok, I'll re-send with appropriate sob
adapted powerpc part.
Sure.
+void __init __attribute__((weak) thread_info_cache_init(void)
Back to this old subject...
I'm having reports that this is not working...
gcc is seeing the empty weak function and is optimizing it out
before it gets a chance to link to the arch provided one.
This would affect that and the other one next to it..
That seems pretty bad... it causes nasty crashes as we end up having no
idea what the compiler decided to generate... I suppose we could keep
the weak stubs out of the file where they are called but that sucks.
ie. This is some form of gcc 4.1.1
Is that a known problem ? A gcc issue ? Not sure what is expected from
those weak functions.
yup, gcc bug. Discussed recently on lkml, Subject: Re: huge gcc
4.1.{0,1} __weak problem. I don't think anything ended up happening
about it though.
It was discussed to add some run-time checks for this issue.
But the examples given were a bit fluffy so I never integrated anything
i kbuild to detect this.
As this is only a bug for const weak functions they could be made non-const
if they are seldomly used?
Sam
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [OF] spi_of: add support for dedicated SPI constructors
On Wed, May 21, 2008 at 11:51 AM, Guennadi Liakhovetski [EMAIL PROTECTED] wrote: On Wed, 21 May 2008, Grant Likely wrote: I concede that sometimes platform code just has to pass data to the driver that cannot be described in the device tree. callback pointers being the most significant example and we do need a sane way to do so. Sorry, I just cannot understand. So far my understanding was, that OF bindings were there to _completely_ describe hardware, that cannot be autoconfigured or probed. Correct, they describe the hardware... to a level sufficient to identify it usefully and uniquely to an operating system. So a _generic_ driver gets all information it needs from the device tree and needs no additional information to handle the hardware. Also correct. Now if a driver needs additional information from platform code what's the purpose of partial data in the device tree at all? Just use board information as usual. (Note; it must be said that I think the situation is *rare* and should be avoided) If some behaviour is entirely board specific and doesn't have any possibility of being duplicated on other boards, then it makes sense for the code implementing that behaviour to live with the platform code. For example; consider the example of the ads7846 device driver. It needs a pointer to a function that will tell it whether or not the pen is down. This is entirely a board specific kind of thing; it might happen via a GPIO or a key press or a phase of the moon. The device doesn't care; but the driver needs a way to test the state. The driver needs some method to obtain the pointer to the function. It cannot be encoded in the device tree because it is a function pointer, not raw 'data'. The device tree may have some data that tells the platform code how it is wired up; but the pointer itself cannot be encoded into the device tree. I see two obvious ways to do this. (note: platform code cannot simply export the function because it might be a multiplatform kernel with multiple platforms defining the same function). 1) Pass it in a data structure passed with the device structure 2) Make the device driver call out to a lookup function that returns the function pointer. Option 1) is basically some form of pdata scheme. Option 2 requires the driver to use some API to go looking for the relevant function. I'm not convinced yet on which method is the best; but I cannot say that platform code must never pass data to drivers that is not directly encoded into the device tree. Besides, we must always account for the situation where the provided device tree has a bug or the hardware has a quirk and platform code needs to do something to fix it up. Or if you prefer: 99% of the time everything is handled with common code reading the device tree directly; but in the 1% of the time where that does not work (due to bugs or quirks) we have options to insert workaround code. What good is an OF-binding if it doesn't provide complete information? It still increases the amount of common code even if there are rare corner cases that require board specific code. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] spi: Add OF binding support for SPI busses
Ok, elegance apart:-) You can use the SPI-bridge construct to also
describe simple SPI-chipselect configurations. But is it really a good
idea? Wouldn't it be better to handle these two cases separately?
It would be best to handle all these things that are specific to
a certain SPI controller (like how CSs work) in the binding for
that SPI controller, and not try to shoehorn all of this into some
artificial generic framework.
If you can have identical addresses on the SPI bus going to different
devices based on which CS is asserted, you'll have to make the CS part
of the reg. Example:
spi-controller {
#address-cells = 2;
#size-cells = 0;
[EMAIL PROTECTED],f000 { reg = 0 f000 ; } // CS 0, SPI address f000
[EMAIL PROTECTED],f000 { reg = 1 f000 ; } // CS 1, SPI address f000
[EMAIL PROTECTED],ff00 { reg = 1 ff00 ; } // CS 1, SPI address ff00
}
SPI-to-SPI bridges can (and should!) be handled the same way as
anything-to-anything-else bridges are handled as well: either there
is a nice simple one-to-one matching (and you can use ranges) or
you need a driver for that bridge that knows how to make it work (or
both, ranges isn't always enough, the bridge might require some
specific handling for some special situations -- error handling,
suspend, whatever).
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [OF] spi_of: add support for dedicated SPI constructors
On Wed, 21 May 2008, Grant Likely wrote: If some behaviour is entirely board specific and doesn't have any possibility of being duplicated on other boards, then it makes sense for the code implementing that behaviour to live with the platform code. Exactly - entirely board specific and doesn't have any possibility of being duplicated on other boards. What good is an OF-binding if it doesn't provide complete information? It still increases the amount of common code even if there are rare corner cases that require board specific code. Right again - _rare_ corner cases. Whereas we are talking about _all_ SPI busses, maybe apart from those, where the controller itself switches CSs in a well-defined way, and the driver doesn't need any additional information to handle this. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] spi: Add OF binding support for SPI busses
On Wed, May 21, 2008 at 1:11 PM, Segher Boessenkool
[EMAIL PROTECTED] wrote:
Ok, elegance apart:-) You can use the SPI-bridge construct to also
describe simple SPI-chipselect configurations. But is it really a good
idea? Wouldn't it be better to handle these two cases separately?
It would be best to handle all these things that are specific to
a certain SPI controller (like how CSs work) in the binding for
that SPI controller, and not try to shoehorn all of this into some
artificial generic framework.
If you can have identical addresses on the SPI bus going to different
devices based on which CS is asserted, you'll have to make the CS part
of the reg. Example:
spi-controller {
#address-cells = 2;
#size-cells = 0;
[EMAIL PROTECTED],f000 { reg = 0 f000 ; } // CS 0, SPI address f000
[EMAIL PROTECTED],f000 { reg = 1 f000 ; } // CS 1, SPI address f000
[EMAIL PROTECTED],ff00 { reg = 1 ff00 ; } // CS 1, SPI address ff00
}
For SPI the CS # *is* the address. :-)
Unlike I2C, SPI doesn't impose any protocol on the data. It is all
anonymous data out, anonymous data in, a clock and a chip select.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
On Wed, 21 May 2008, Benjamin Herrenschmidt wrote:
Depends on what you define as necessary. It's seem clear that I/O accessors
_no not_ need to be strictly ordered with respect to normal memory accesses,
by what's defined in memory-barriers.txt. So if by necessary you mean what
the Linux standard for I/O accessors requires (and what other archs provide),
then yes, they have the necessary ordering guarantees.
But, if you want them to be strictly ordered w.r.t to normal memory, that's
not the case.
They should be.
Someone should update memory-barriers.txt, because it doesn't say that, and
all I/O accessors for all the arches, because none of them are.
Here's a quick hack I stuck in a driver to test. compile with -save-temps and
check the resulting asm. gcc will do the optimization I described above.
static void __iomem *baz = (void*)0x1234;
static struct bar {
u32 bar[256];
} bar;
void foo(void) {
bar.bar[0] = 44;
out_be32(baz+100, 200);
bar.bar[0] = 45;
out_be32(baz+101, 201);
}
Have you removed -fno-strict-aliasing ? Just don't do that.
No, it's compiled with a normal kernel build, which includes
-fno-strict-aliasing.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [OF] spi_of: add support for dedicated SPI constructors
On Wed, May 21, 2008 at 1:20 PM, Guennadi Liakhovetski [EMAIL PROTECTED] wrote: On Wed, 21 May 2008, Grant Likely wrote: If some behaviour is entirely board specific and doesn't have any possibility of being duplicated on other boards, then it makes sense for the code implementing that behaviour to live with the platform code. Exactly - entirely board specific and doesn't have any possibility of being duplicated on other boards. What good is an OF-binding if it doesn't provide complete information? It still increases the amount of common code even if there are rare corner cases that require board specific code. Right again - _rare_ corner cases. Whereas we are talking about _all_ SPI busses, maybe apart from those, where the controller itself switches CSs in a well-defined way, and the driver doesn't need any additional information to handle this. Ah, I see where we are crossing our wires. I was talking about the case of registering spi devices. I agree that the spi bus should not need any additional information. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 1 GB lowmem
[EMAIL PROTECTED] wrote: Hi I am trying to enable 1 GB of lowmem on a Freescale 8280. In arch/ppc this was easilly done by: CONFIG_ADVANCED_OPTIONS=y CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE_BOOL=y CONFIG_LOWMEM_SIZE=0x4000 CONFIG_KERNEL_START_BOOL=y CONFIG_KERNEL_START=0xa000 This does not work in arch/powerpc. CPU hangs as soon as init starts. Any ideas what to look at, what to change? The reason I want to do this is because I cannot get highmem support to work when using CONFIG_PREEMPT_RT. (hitting a bug_on in kmap_atomic) Scratch that. 1 GB lowmem works with vanilla 2.6.25.4, but not at all with 2.6.25.4-rt[13] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [OF] spi_of: add support for dedicated SPI constructors
On Wed, 21 May 2008, Grant Likely wrote: On Wed, May 21, 2008 at 1:20 PM, Guennadi Liakhovetski [EMAIL PROTECTED] wrote: Right again - _rare_ corner cases. Whereas we are talking about _all_ SPI busses, maybe apart from those, where the controller itself switches CSs in a well-defined way, and the driver doesn't need any additional information to handle this. Ah, I see where we are crossing our wires. I was talking about the case of registering spi devices. I agree that the spi bus should not need any additional information. No, sorry for not making it clear. I wrote busses because on those controllers, that control CS themselves _devices_ don't need any additional info. But I meant, that describing SPI _devices_ should be done in only one way or another - either using fdt, or platform data, not both. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [OF] spi_of: add support for dedicated SPI constructors
On Wed, May 21, 2008 at 2:00 PM, Guennadi Liakhovetski [EMAIL PROTECTED] wrote: On Wed, 21 May 2008, Grant Likely wrote: On Wed, May 21, 2008 at 1:20 PM, Guennadi Liakhovetski [EMAIL PROTECTED] wrote: Right again - _rare_ corner cases. Whereas we are talking about _all_ SPI busses, maybe apart from those, where the controller itself switches CSs in a well-defined way, and the driver doesn't need any additional information to handle this. Ah, I see where we are crossing our wires. I was talking about the case of registering spi devices. I agree that the spi bus should not need any additional information. No, sorry for not making it clear. I wrote busses because on those controllers, that control CS themselves _devices_ don't need any additional info. But I meant, that describing SPI _devices_ should be done in only one way or another - either using fdt, or platform data, not both. Yes, I agree with that too... with the one caveat that platform code should have some method to supplement the data in the device tree *only when it is absolutely necessary to do so*. (note: I say 'platform code' here, not 'platform data'. They are two different things) I make no claims on what that method should be at this time. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/2] powerpc: optimise smp_wmb
From memory, I measured lwsync is 5 times faster than eieio on a dual G5. This was on a simple microbenchmark that made use of smp_wmb for store ordering, but it did not involve any IO access (which presumably would disadvantage eieio further). This is very much specific to your particular benchmark. On the 970, there are two differences between lwsync and eieio: 1) lwsync cannot issue before all previous loads are done; eieio does not have this restriction. Then, they both fly through the execution core, it doesn't wait for the barrier insn to complete in the storage system. In both cases, a barrier is inserted into both the L2 queues and the non-cacheable queues. These barriers are both removed at the same time, that is, when both are the oldest in their queue and have done their thing. 2) For eieio, the non-cacheable unit waits for all previous (non-cacheable) stores to complete, and then arbitrates for the bus and sends an EIEIO transaction. Your benchmark doesn't do non-cacheable stores, so it would seem the five-time slowdown is caused by that bus arbitration (and the bus transaction). Maybe your cacheable stores hit the bus as well, that would make this worse. Your benchmark also doesn't see the negative effects from 1). In real code, I expect 2) to be pretty much invisible (the store queues will never be completely filled up), but 1) shouldn't be very bad either. So it's a wash. But only a real benchmark will tell. Given the G5 speedup, I'd be surprised if there is not an improvment on POWER4 and 5 as well, The 970 storage subsystem and the POWER4 one are very different. Or maybe these queues are just about the last thing that _is_ identical, I dunno, there aren't public POWER4 docs for this ;-) although no idea about POWER6 or cell... No idea about POWER6; for CBE, the backend works similar to the 970 one. Given that the architecture says to use lwsync for cases like this, it would be very surprising if it performed (much) worse than eieio, eh? ;-) So I think your patch is a win; just wanted to clarify on your five-time slowdown number. HTH, Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/2] powerpc: optimise smp_wmb
+#ifdef __SUBARCH_HAS_LWSYNC +#define SMPWMB lwsync +#else +#define SMPWMB eieio +#endif + #define smp_mb() mb() #define smp_rmb() rmb() -#define smp_wmb() eieio() +#define smp_wmb() __asm__ __volatile__ (__stringify(SMPWMB) : : :memory) SMPWMB is used only here. Why not just #ifdef __SUBARCH_HAS_LWSYNC #define smp_wmb() lwsync() #else #define smp_wmb() eieio() #endif ? Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
On Wed, 21 May 2008, Andreas Schwab wrote: Trent Piepho [EMAIL PROTECTED] writes: On Wed, 21 May 2008, Andreas Schwab wrote: Trent Piepho [EMAIL PROTECTED] writes: It's the _le versions that have a problem, since we can't get gcc to just use the register indexed mode. It seems like an obvious thing to have a constraint for, but I guess there weren't enough instructions that only come in 'x' versions to bother with it. There is a 'Z' constraint, Memory operand that is an indexed or indirect from a register, but I tried it and it can use both rb,ri and disp(rb) forms. Actually, I'm not sure how 'Z' is any different than m? 'Z' will never emit a non-zero constant displacement. It's too bad gas doesn't appear to be smart enough to turn: stwbrx 0, 0(3) -or- stwbr 0, 0(3) Use the %y modifier when substituting the operand. Of course, the undocumented y modifier! Print AltiVec or SPE memory operand Why didn't I think of that? That appears to work. I can get gcc to to emit 0,reg and reg,reg but not disp(reg). It won't try to use an update address either, though it will with an m constraint. But, gcc 4.0.2 can't handle the 'Z' constraint. It looks like it's not supported. Other than this, I can build a kernel with 4.0.2 that appears to work. Is it ok to break compatibility with 4.0.2, or should I put in a gcc version check? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
On Wed, 2008-05-21 at 11:41 -0700, Andrew Morton wrote:
yup, gcc bug. Discussed recently on lkml, Subject: Re: huge gcc
4.1.{0,1} __weak problem. I don't think anything ended up happening
about it though.
Hrm... do you think we should work around ? ie. move the stubs to a
separate .c file ?
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
On Wed, 2008-05-21 at 21:06 +0200, Sam Ravnborg wrote:
It was discussed to add some run-time checks for this issue.
But the examples given were a bit fluffy so I never integrated
anything
i kbuild to detect this.
As this is only a bug for const weak functions they could be made
non-const
if they are seldomly used?
With the asm() trick ?
I suppose, but I'm also happy to just reject the bad gcc...
It shouldn't be too hard to do a test case made of 2 files.
test_foo.c
int foo(void)
{
printf(good\n);
}
test_bar.c
int foo(void) __weak
{
}
int main(void)
{
foo();
return 0;
}
And check for good in the output of said program..
Can somebody test that ? Luke, you have a broken compiler, can you make
up some test that could be integrated in the kernel build system
easily ?
(I'm travelling right now, no time to play much with it myself).
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code
On Wed, 2008-05-21 at 12:44 -0700, Trent Piepho wrote: Someone should update memory-barriers.txt, because it doesn't say that, and all I/O accessors for all the arches, because none of them are. There have been long discussions about that. The end result was that being too weakly ordered is just asking for trouble because the majority of drivers are written tested on x86 which is in order. If you look at our accessors, minus that gcc problem you found, the barriers in there should pretty much guarantee ordering in the cases that matter, which are basically MMIO read followed by memory accesses and memory writes followed by MMIO. In fact, MMIO read are fully sychronous. No, it's compiled with a normal kernel build, which includes -fno-strict-aliasing Ok, so there is a very bad bug indeed, we need to fix that. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/2] powerpc: optimise smp_wmb
On Wed, 2008-05-21 at 22:12 +0200, Segher Boessenkool wrote: No idea about POWER6; for CBE, the backend works similar to the 970 one. Given that the architecture says to use lwsync for cases like this, it would be very surprising if it performed (much) worse than eieio, eh? ;-) So I think your patch is a win; just wanted to clarify on your five-time slowdown number. It makes sense to use lwsync rather than eieio for smb_wmb() as this is not supposed to be used to order with cache inhibited storage. It's really a data barrier used by the kernel for normal cacheable storage. The main question is do we care if the downgrade to sync on power3 hurts performances (and does it ?) and what do we do for 32 bits as currently, no 32 bits implementation has lwsync afaik (though that might not be true for long). Also, we don't, I think, have verified that they all properly ignore the added bit and behave as sync rather than program checking.. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpic: cope with non mpic irqs
On Wed, 2008-05-21 at 16:24 +1000, Stephen Rothwell wrote:
Compiling ppc64_defconfig with gcc 4.3 gives thes warnings:
arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_get_priority':
arch/powerpc/sysdev/mpic.c:1351: warning: 'is_ipi' may be used uninitialized
in this function
arch/powerpc/sysdev/mpic.c: In function 'mpic_irq_set_priority':
arch/powerpc/sysdev/mpic.c:1328: warning: 'is_ipi' may be used uninitialized
in this function
It turns out that in the cases where is_ipi is uninitialized, another
variable (mpic) will be NULL and it is dereferenced. Protect against
this by returning if mpic is NULL in mpic_irq_set_priority and removing
mpic_irq_get_priority completely as it has no in tree callers.
This has the nice side effect of making the warning go away.
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/sysdev/mpic.c | 20 +++-
include/asm-powerpc/mpic.h |3 +--
2 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8619f2a..7680001 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1331,6 +1331,9 @@ void mpic_irq_set_priority(unsigned int irq, unsigned
int pri)
unsigned long flags;
u32 reg;
+ if (!mpic)
+ return;
+
spin_lock_irqsave(mpic_lock, flags);
if (is_ipi) {
reg = mpic_ipi_read(src - mpic-ipi_vecs[0])
@@ -1346,23 +1349,6 @@ void mpic_irq_set_priority(unsigned int irq, unsigned
int pri)
spin_unlock_irqrestore(mpic_lock, flags);
}
-unsigned int mpic_irq_get_priority(unsigned int irq)
-{
- unsigned int is_ipi;
- struct mpic *mpic = mpic_find(irq, is_ipi);
- unsigned int src = mpic_irq_to_hw(irq);
- unsigned long flags;
- u32 reg;
-
- spin_lock_irqsave(mpic_lock, flags);
- if (is_ipi)
- reg = mpic_ipi_read(src = mpic-ipi_vecs[0]);
- else
- reg = mpic_irq_read(src, MPIC_INFO(IRQ_VECTOR_PRI));
- spin_unlock_irqrestore(mpic_lock, flags);
- return (reg MPIC_VECPRI_PRIORITY_MASK) MPIC_VECPRI_PRIORITY_SHIFT;
-}
-
void mpic_setup_this_cpu(void)
{
#ifdef CONFIG_SMP
diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
index 943c5a3..a4d0f87 100644
--- a/include/asm-powerpc/mpic.h
+++ b/include/asm-powerpc/mpic.h
@@ -428,12 +428,11 @@ extern void mpic_init(struct mpic *mpic);
*/
-/* Change/Read the priority of an interrupt. Default is 8 for irqs and
+/* Change the priority of an interrupt. Default is 8 for irqs and
* 10 for IPIs. You can call this on both IPIs and IRQ numbers, but the
* IPI number is then the offset'ed (linux irq number mapped to the IPI)
*/
extern void mpic_irq_set_priority(unsigned int irq, unsigned int pri);
-extern unsigned int mpic_irq_get_priority(unsigned int irq);
/* Setup a non-boot CPU */
extern void mpic_setup_this_cpu(void);
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/2] powerpc: optimise smp_wmb
This is mostly useless then since lwsync is just a sync to a processor that doesn't know it (it's a sync with a reservd bit set) :-) Or it's just to make gas happy if you specify a processor type that doesn't have lwsync ? GAS doesn't care (I tried with -Wa,-m405). Support for this insn was added to binutils in august 2001; do we still support older binutils than that? If so, we should just do the .long trick in a lwsync() inline function, like we do for similar cases. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] [POWERPC] mpic: deal with bogus NIRQ in Feature Reporting Register
Some chips (like the SoCs from Freescale) report the wrong value in NIRQ
and this causes issues if its doesn't match or exceed the value of
irq_count.
Add a flag that board code can set to just use irq_count instead of
FRR[NIRQ]. Eventually we'll add a device tree property with the number
of sources.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Screw up with git on the first version.
- k
arch/powerpc/sysdev/mpic.c |9 ++---
include/asm-powerpc/mpic.h |2 ++
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8619f2a..12e285d 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1144,9 +1144,12 @@ struct mpic * __init mpic_alloc(struct device_node *node,
mpic-num_cpus = ((greg_feature MPIC_GREG_FEATURE_LAST_CPU_MASK)
MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1;
if (isu_size == 0)
- mpic-num_sources =
- ((greg_feature MPIC_GREG_FEATURE_LAST_SRC_MASK)
- MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1;
+ if (flags MPIC_BROKEN_FRR_NIRQS)
+ mpic-num_sources = mpic-irq_count;
+ else
+ mpic-num_sources =
+ ((greg_feature
MPIC_GREG_FEATURE_LAST_SRC_MASK)
+ MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1;
/* Map the per-CPU registers */
for (i = 0; i mpic-num_cpus; i++) {
diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
index 943c5a3..6802570 100644
--- a/include/asm-powerpc/mpic.h
+++ b/include/asm-powerpc/mpic.h
@@ -353,6 +353,8 @@ struct mpic
#define MPIC_ENABLE_MCK0x0200
/* Disable bias among target selection, spread interrupts evenly */
#define MPIC_NO_BIAS 0x0400
+/* Ignore NIRQS as reported by FRR */
+#define MPIC_BROKEN_FRR_NIRQS 0x0800
/* MPIC HW modification ID */
#define MPIC_REGSET_MASK 0xf000
--
1.5.4.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 1 GB lowmem
Rune Torgersen wrote: [EMAIL PROTECTED] wrote: Hi I am trying to enable 1 GB of lowmem on a Freescale 8280. In arch/ppc this was easilly done by: CONFIG_ADVANCED_OPTIONS=y CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE_BOOL=y CONFIG_LOWMEM_SIZE=0x4000 CONFIG_KERNEL_START_BOOL=y CONFIG_KERNEL_START=0xa000 This does not work in arch/powerpc. CPU hangs as soon as init starts. Any ideas what to look at, what to change? The reason I want to do this is because I cannot get highmem support to work when using CONFIG_PREEMPT_RT. (hitting a bug_on in kmap_atomic) Scratch that. 1 GB lowmem works with vanilla 2.6.25.4, but not at all with 2.6.25.4-rt[13] Argh... Found it. Had to set CONFIG_TASK_SIZE to 0x8000. Now it works in both vaniulla an d RT kernel. Highmem still doesn't work. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [POWERPC] mpic: deal with bogus NIRQ in Feature Reporting Register
On Wed, 2008-05-21 at 15:59 -0500, Kumar Gala wrote:
Some chips (like the SoCs from Freescale) report the wrong value in NIRQ
and this causes issues if its doesn't match or exceed the value of
irq_count.
Add a flag that board code can set to just use irq_count instead of
FRR[NIRQ]. Eventually we'll add a device tree property with the number
of sources.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Screw up with git on the first version.
- k
arch/powerpc/sysdev/mpic.c |9 ++---
include/asm-powerpc/mpic.h |2 ++
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8619f2a..12e285d 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1144,9 +1144,12 @@ struct mpic * __init mpic_alloc(struct device_node
*node,
mpic-num_cpus = ((greg_feature MPIC_GREG_FEATURE_LAST_CPU_MASK)
MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1;
if (isu_size == 0)
- mpic-num_sources =
- ((greg_feature MPIC_GREG_FEATURE_LAST_SRC_MASK)
- MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1;
+ if (flags MPIC_BROKEN_FRR_NIRQS)
+ mpic-num_sources = mpic-irq_count;
+ else
+ mpic-num_sources =
+ ((greg_feature
MPIC_GREG_FEATURE_LAST_SRC_MASK)
+ MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1;
/* Map the per-CPU registers */
for (i = 0; i mpic-num_cpus; i++) {
diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
index 943c5a3..6802570 100644
--- a/include/asm-powerpc/mpic.h
+++ b/include/asm-powerpc/mpic.h
@@ -353,6 +353,8 @@ struct mpic
#define MPIC_ENABLE_MCK 0x0200
/* Disable bias among target selection, spread interrupts evenly */
#define MPIC_NO_BIAS 0x0400
+/* Ignore NIRQS as reported by FRR */
+#define MPIC_BROKEN_FRR_NIRQS0x0800
/* MPIC HW modification ID */
#define MPIC_REGSET_MASK 0xf000
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
On Wed, 21 May 2008 15:44:41 -0400
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Wed, 2008-05-21 at 11:41 -0700, Andrew Morton wrote:
yup, gcc bug. Discussed recently on lkml, Subject: Re: huge gcc
4.1.{0,1} __weak problem. I don't think anything ended up happening
about it though.
Hrm... do you think we should work around ? ie. move the stubs to a
separate .c file ?
istr that sticking an asm(); in the weak function was a reliable
workaround. If we are going to to that it should be via
/* comment goes here */
#define gcc_screws_up_weak_stuff() asm()
but that approach didn't seem very popular. It's a _bit_ fragile I
guess, but it's pretty easy to grep for missed workarounds.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 1 GB lowmem
On May 21, 2008, at 3:55 PM, Rune Torgersen wrote: Rune Torgersen wrote: [EMAIL PROTECTED] wrote: Hi I am trying to enable 1 GB of lowmem on a Freescale 8280. In arch/ppc this was easilly done by: CONFIG_ADVANCED_OPTIONS=y CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE_BOOL=y CONFIG_LOWMEM_SIZE=0x4000 CONFIG_KERNEL_START_BOOL=y CONFIG_KERNEL_START=0xa000 This does not work in arch/powerpc. CPU hangs as soon as init starts. Any ideas what to look at, what to change? The reason I want to do this is because I cannot get highmem support to work when using CONFIG_PREEMPT_RT. (hitting a bug_on in kmap_atomic) Scratch that. 1 GB lowmem works with vanilla 2.6.25.4, but not at all with 2.6.25.4-rt[13] Argh... Found it. Had to set CONFIG_TASK_SIZE to 0x8000. Now it works in both vaniulla an d RT kernel. We should really add some sanity check on CONFIG_TASK_SIZE vs KERNEL_START. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 1 GB lowmem
Kumar Gala wrote: On May 21, 2008, at 3:55 PM, Rune Torgersen wrote: Argh... Found it. Had to set CONFIG_TASK_SIZE to 0x8000. Now it works in both vaniulla an d RT kernel. We should really add some sanity check on CONFIG_TASK_SIZE vs KERNEL_START. Something like this? Wording sould probablyy be a bit different/cleare. diff --git a/include/asm-powerpc/processor.h b/include/asm-powerpc/processor.h index fd98ca9..72e0e3f 100644 --- a/include/asm-powerpc/processor.h +++ b/include/asm-powerpc/processor.h @@ -81,6 +81,10 @@ extern struct task_struct *last_task_used_altivec; extern struct task_struct *last_task_used_spe; #ifdef CONFIG_PPC32 + +#if CONFIG_TASK_SIZE CONFIG_KERNEL_START +#error User TASK_SIZE overlaps with KERNEL_START address +#endif #define TASK_SIZE (CONFIG_TASK_SIZE) /* This decides where the kernel will search for a free chunk of vm ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 1 GB lowmem
On Wed, 2008-05-21 at 13:00 -0500, Rune Torgersen wrote: Hi I am trying to enable 1 GB of lowmem on a Freescale 8280. In arch/ppc this was easilly done by: CONFIG_ADVANCED_OPTIONS=y CONFIG_HIGHMEM_START=0xfe00 CONFIG_LOWMEM_SIZE_BOOL=y CONFIG_LOWMEM_SIZE=0x4000 CONFIG_KERNEL_START_BOOL=y CONFIG_KERNEL_START=0xa000 This does not work in arch/powerpc. CPU hangs as soon as init starts. Any ideas what to look at, what to change? You probably need to lower TASK_SIZE too. The reason I want to do this is because I cannot get highmem support to work when using CONFIG_PREEMPT_RT. (hitting a bug_on in kmap_atomic) We should look into fixing that :-) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] 4xx hardware watchpoint support
Two real quick notes. Take a look at: http://ozlabs.org/pipermail/linuxppc-dev/2008-May/055745.html and can you try and post the patch inline next time. Hard to provide review comments on it :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/2] USB: isp1760: Fixes and support for more hardware configs
I spent a little time getting the new isp1760 driver to work on my ppc64 board with an ISP1761. There were two main problems I encountered: - Driver wrote to the PORT 1 control register which is actually the OTG control register on the ISP1761. This needs to be skipped on ISP1761 until we have proper OTG support. - Driver assumed 32-bit data bus mode. You have to jump through a couple small hoops to get 16-bit mode to work, including some changes to the scratch register test. I also had to re-order some of the steps to occur _after_ setting HW MODE control. The first patch is a minor fix. The second patch takes care of the above issues and also adds support for the other bits in HW MODE control that might vary from board to board. Sebastian: I tried to be careful to minimize functional changes for your case (isp1760, 32-bit mode), so things should work the same for you with these patches applied. However, I only have an ISP1761 to test with so I'd appreciate it if you could test with your board. I'm CCing linuxppc-dev in case there's any feedback on the OF device tree property usage in patch 2/2. -- Nate Case [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] USB: isp1760: Assign resource fields before adding hcd
This fixes the bogus io mem 0x message printed during driver init due to hcd-rsrc_start being assigned after the call to usb_add_hcd(). Signed-off-by: Nate Case [EMAIL PROTECTED] --- drivers/usb/host/isp1760-hcd.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/usb/host/isp1760-hcd.c b/drivers/usb/host/isp1760-hcd.c index c9cec87..65aa5ec 100644 --- a/drivers/usb/host/isp1760-hcd.c +++ b/drivers/usb/host/isp1760-hcd.c @@ -2207,14 +2207,14 @@ struct usb_hcd *isp1760_register(u64 res_start, u64 res_len, int irq, goto err_put; } - ret = usb_add_hcd(hcd, irq, irqflags); - if (ret) - goto err_unmap; - hcd-irq = irq; hcd-rsrc_start = res_start; hcd-rsrc_len = res_len; + ret = usb_add_hcd(hcd, irq, irqflags); + if (ret) + goto err_unmap; + return hcd; err_unmap: -- 1.5.4.4 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] USB: isp1760: Support board-specific hardware configurations
This adds support for hardware configurations that don't match the
chip default register settings (e.g., 16-bit data bus, DACK and
DREQ pulled down instead of up, analog overcurrent mode).
These settings are passed in via the OF device tree. The PCI
interface still assumes the same default values.
Signed-off-by: Nate Case [EMAIL PROTECTED]
---
drivers/usb/host/isp1760-hcd.c | 68 +++
drivers/usb/host/isp1760-hcd.h | 19 ++-
drivers/usb/host/isp1760-if.c | 34 +++-
3 files changed, 103 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/host/isp1760-hcd.c b/drivers/usb/host/isp1760-hcd.c
index 65aa5ec..679b8df 100644
--- a/drivers/usb/host/isp1760-hcd.c
+++ b/drivers/usb/host/isp1760-hcd.c
@@ -38,6 +38,7 @@ struct isp1760_hcd {
unsignedi_thresh;
unsigned long reset_done;
unsigned long next_statechange;
+ unsigned intdevflags;
};
static inline struct isp1760_hcd *hcd_to_priv(struct usb_hcd *hcd)
@@ -378,9 +379,31 @@ static int isp1760_hc_setup(struct usb_hcd *hcd)
{
struct isp1760_hcd *priv = hcd_to_priv(hcd);
int result;
- u32 scratch;
+ u32 scratch, hwmode;
+
+ /* Setup HW Mode Control: This assumes a level active-low interrupt */
+ hwmode = HW_DATA_BUS_32BIT;
+
+ if (priv-devflags ISP1760_FLAG_BUS_WIDTH_16)
+ hwmode = ~HW_DATA_BUS_32BIT;
+ if (priv-devflags ISP1760_FLAG_ANALOG_OC)
+ hwmode |= HW_ANA_DIGI_OC;
+ if (priv-devflags ISP1760_FLAG_DACK_POL_HIGH)
+ hwmode |= HW_DACK_POL_HIGH;
+ if (priv-devflags ISP1760_FLAG_DREQ_POL_HIGH)
+ hwmode |= HW_DREQ_POL_HIGH;
+
+ /*
+* We have to set this first in case we're in 16-bit mode.
+* Write it twice to ensure correct upper bits if switching
+* to 16-bit mode.
+*/
+ isp1760_writel(hwmode, hcd-regs + HC_HW_MODE_CTRL);
+ isp1760_writel(hwmode, hcd-regs + HC_HW_MODE_CTRL);
isp1760_writel(0xdeadbabe, hcd-regs + HC_SCRATCH_REG);
+ /* Change bus pattern */
+ scratch = isp1760_readl(hcd-regs + HC_CHIP_ID_REG);
scratch = isp1760_readl(hcd-regs + HC_SCRATCH_REG);
if (scratch != 0xdeadbabe) {
printk(KERN_ERR ISP1760: Scratch test failed.\n);
@@ -403,17 +426,30 @@ static int isp1760_hc_setup(struct usb_hcd *hcd)
/* Step 11 passed */
- isp1760_writel(INTERRUPT_ENABLE_MASK, hcd-regs + HC_INTERRUPT_REG);
- isp1760_writel(INTERRUPT_ENABLE_MASK, hcd-regs + HC_INTERRUPT_ENABLE);
+ isp1760_info(priv, bus width: %d, oc: %s\n,
+ (priv-devflags ISP1760_FLAG_BUS_WIDTH_16) ?
+ 16 : 32, (priv-devflags ISP1760_FLAG_ANALOG_OC) ?
+ analog : digital);
/* ATL reset */
- scratch = isp1760_readl(hcd-regs + HC_HW_MODE_CTRL);
- isp1760_writel(scratch | ALL_ATX_RESET, hcd-regs + HC_HW_MODE_CTRL);
+ isp1760_writel(hwmode | ALL_ATX_RESET, hcd-regs + HC_HW_MODE_CTRL);
mdelay(10);
- isp1760_writel(scratch, hcd-regs + HC_HW_MODE_CTRL);
+ isp1760_writel(hwmode, hcd-regs + HC_HW_MODE_CTRL);
- isp1760_writel(PORT1_POWER | PORT1_INIT2, hcd-regs + HC_PORT1_CTRL);
- mdelay(10);
+ isp1760_writel(INTERRUPT_ENABLE_MASK, hcd-regs + HC_INTERRUPT_REG);
+ isp1760_writel(INTERRUPT_ENABLE_MASK, hcd-regs + HC_INTERRUPT_ENABLE);
+
+ /*
+* PORT 1 Control register of the ISP1760 is the OTG control
+* register on ISP1761.
+*/
+ scratch = isp1760_readl(hcd-regs + HC_CHIP_ID_REG);
+ if (((scratch 0x) == 0x1760)
+ !(priv-devflags ISP1760_FLAG_PORT1_DIS)) {
+ isp1760_writel(PORT1_POWER | PORT1_INIT2,
+ hcd-regs + HC_PORT1_CTRL);
+ mdelay(10);
+ }
priv-hcs_params = isp1760_readl(hcd-regs + HC_HCSPARAMS);
@@ -453,8 +489,7 @@ static int isp1760_run(struct usb_hcd *hcd)
hcd-state = HC_STATE_RUNNING;
isp1760_enable_interrupts(hcd);
temp = isp1760_readl(hcd-regs + HC_HW_MODE_CTRL);
- temp |= FINAL_HW_CONFIG;
- isp1760_writel(temp, hcd-regs + HC_HW_MODE_CTRL);
+ isp1760_writel(temp | HW_GLOBAL_INTR_EN, hcd-regs + HC_HW_MODE_CTRL);
command = isp1760_readl(hcd-regs + HC_USBCMD);
command = ~(CMD_LRESET|CMD_RESET);
@@ -2112,6 +2147,7 @@ static int isp1760_get_frame(struct usb_hcd *hcd)
static void isp1760_stop(struct usb_hcd *hcd)
{
struct isp1760_hcd *priv = hcd_to_priv(hcd);
+ u32 temp;
isp1760_hub_control(hcd, ClearPortFeature, USB_PORT_FEAT_POWER, 1,
NULL, 0);
@@ -2120,7 +2156,8 @@ static void isp1760_stop(struct usb_hcd *hcd)
spin_lock_irq(priv-lock);
ehci_reset(priv);
/* Disable IRQ */
-
[PATCH] [POWERPC] mpic: deal with bogus NIRQ in Feature Reporting Register
Some chips (like the SoCs from Freescale) report the wrong value in NIRQ
and this causes issues if its doesn't match or exceed the value of
irq_count.
Add a flag that board code can set to just use irq_count instead of
FRR[NIRQ]. Eventually we'll add a device tree property with the number
of sources.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
arch/powerpc/sysdev/mpic.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 8619f2a..4530b38 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1144,9 +1144,9 @@ struct mpic * __init mpic_alloc(struct device_node *node,
mpic-num_cpus = ((greg_feature MPIC_GREG_FEATURE_LAST_CPU_MASK)
MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1;
if (isu_size == 0)
- mpic-num_sources =
+ mpic-num_sources = max(mpic-irq_count,
((greg_feature MPIC_GREG_FEATURE_LAST_SRC_MASK)
- MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1;
+ MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1);
/* Map the per-CPU registers */
for (i = 0; i mpic-num_cpus; i++) {
--
1.5.4.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] 4xx hardware watchpoint support
Thanks for the inlining tip. It should be now. :-)
So, basically we are looking at a cleaner and much better interface to
set such hardware features? That's something that would greatly improve
the communication from, say, GDB to the kernel regarding these
facilities.
Regards,
Luis
On Wed, 2008-05-21 at 16:16 -0500, Kumar Gala wrote:
Two real quick notes.
Take a look at:
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/055745.html
and can you try and post the patch inline next time. Hard to provide
review comments on it :)
- kIndex: linux-2.6.25.1/arch/powerpc/kernel/process.c
===
--- linux-2.6.25.1.orig/arch/powerpc/kernel/process.c 2008-05-21
07:25:45.0 -0700
+++ linux-2.6.25.1/arch/powerpc/kernel/process.c2008-05-21
07:26:55.0 -0700
@@ -219,6 +219,28 @@
}
#endif /* CONFIG_SPE */
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+
+/* Add support for HW Debug breakpoint. Use DAC register. */
+int set_dac(unsigned long dac)
+{
+ mtspr(SPRN_DAC1, dac);
+
+ return 0;
+}
+unsigned int get_dac()
+{
+ return mfspr(SPRN_DAC1);
+}
+int set_dbcr0(unsigned long dbcr)
+{
+ mtspr(SPRN_DBCR0, dbcr);
+
+ return 0;
+}
+
+#endif
+
#ifndef CONFIG_SMP
/*
* If we are doing lazy switching of CPU state (FP, altivec or SPE),
@@ -330,6 +352,13 @@
if (unlikely(__get_cpu_var(current_dabr) != new-thread.dabr))
set_dabr(new-thread.dabr);
+
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ /* If new thread DAC (HW breakpoint) is the same then leave it. */
+ if (new-thread.dac)
+ set_dac(new-thread.dac);
+#endif
+
new_thread = new-thread;
old_thread = current-thread;
@@ -515,6 +544,16 @@
discard_lazy_cpu_state();
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ if (current-thread.dac) {
+ current-thread.dac = 0;
+ /* Clear debug control. */
+ current-thread.dbcr0 = ~(DBSR_DAC1R | DBSR_DAC1W);
+
+ set_dac(0);
+ }
+#endif
+
if (current-thread.dabr) {
current-thread.dabr = 0;
set_dabr(0);
Index: linux-2.6.25.1/arch/powerpc/kernel/ptrace.c
===
--- linux-2.6.25.1.orig/arch/powerpc/kernel/ptrace.c2008-05-21
07:25:45.0 -0700
+++ linux-2.6.25.1/arch/powerpc/kernel/ptrace.c 2008-05-21 08:23:34.0
-0700
@@ -629,9 +629,15 @@
{
struct pt_regs *regs = task-thread.regs;
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ /* If DAC then do not single step, skip. */
+ if (task-thread.dac)
+ return;
+#endif
+
if (regs != NULL) {
#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
- task-thread.dbcr0 = 0;
+ task-thread.dbcr0 = ~(DBCR0_IC | DBCR0_IDM);
regs-msr = ~MSR_DE;
#else
regs-msr = ~MSR_SE;
@@ -640,22 +646,83 @@
clear_tsk_thread_flag(task, TIF_SINGLESTEP);
}
-static int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
+static int ptrace_get_debugreg(struct task_struct *task, unsigned long data)
+{
+ int ret;
+
+ #if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+ ret = put_user(task-thread.dac,
+ (unsigned long __user *)data);
+ #else
+ ret = put_user(task-thread.dabr,
+ (unsigned long __user *)data);
+ #endif
+
+ return ret;
+}
+
+int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
unsigned long data)
{
- /* We only support one DABR and no IABRS at the moment */
+ /* For ppc64 we support one DABR and no IABR's at the moment (ppc64).
+ For embedded processors we support one DAC and no IAC's
+ at the moment. */
if (addr 0)
return -EINVAL;
- /* The bottom 3 bits are flags */
if ((data ~0x7UL) = TASK_SIZE)
return -EIO;
- /* Ensure translation is on */
+#ifdef CONFIG_PPC64
+
+ /* For processors using DABR (i.e. 970), the bottom 3 bits are flags.
+ It was assumed, on previous implementations, that 3 bits were
+ passed together with the data address, fitting the design of the
+ DABR register, as follows:
+
+ bit 0: Read flag
+ bit 1: Write flag
+ bit 2: Breakpoint translation
+
+ Thus, we use them here as so. */
+
+ /* Ensure breakpoint translation bit is set. */
if (data !(data DABR_TRANSLATION))
return -EIO;
+ /* Move contents to the DABR register. */
task-thread.dabr = data;
+
+#endif
+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+
+ /* Read or Write bits must be set. */
+ if (!(data 0x3UL))
+
Re: [patch 2/2] powerpc: optimise smp_wmb
The main question is do we care if the downgrade to sync on power3 hurts performances (and does it ?) and what do we do for 32 bits as currently, no 32 bits implementation has lwsync afaik (though that might not be true for long). Some time ago, I benchmarked (*) a loop of stw;sync vs. stw;eieio on a 750 (yeah, great micro-benchmark, heh); and the sync version was a factor ~100 slower. Also, we don't, I think, have verified that they all properly ignore the added bit and behave as sync rather than program checking.. The architecture books don't have a programming note about this (like they do in similar cases), so either a) it works fine on every implementation; or b) someone forgot to add such a note. We shouldn't use lwsync on 32-bit (it's an awful performance hit on classic cpus, and who knows what it does on embedded cpus (bookE *shudder*)). For POWER3 and *star, i.e., all 64-bit? Perhaps it'll be okay there, but if as you suggest some 32-bit CPUs will add proper lwsync support soonish, maybe a feature fixup or some such is in order. Segher (*) Not on purpose. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpic: deal with bogus NIRQ in Feature Reporting Register
On Wed, May 21, 2008 at 03:57:55PM -0500, Kumar Gala wrote: Some chips (like the SoCs from Freescale) report the wrong value in NIRQ and this causes issues if its doesn't match or exceed the value of irq_count. Is it really wrong, or just not accounting for the gap between external and internal interrupts? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: patch to install unstripped vDSO on disk breaks powerpc kernel build
Roland McGrath wrote: Ok. That looks like a bug in the older binutils (objcopy) you are using. It is confused by the empty .rela.dyn section right next to the .dynamic section. Current binutils don't seem to have a problem with this. I haven't tried to get an old binutils running to reproduce this. I suspect the following change will work around the problem. It should not cause any problem with newer or older binutils. Thanks, this seems to have fixed the problem. Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/2] powerpc: optimise smp_wmb
On Wed, May 21, 2008 at 10:12:03PM +0200, Segher Boessenkool wrote: From memory, I measured lwsync is 5 times faster than eieio on a dual G5. This was on a simple microbenchmark that made use of smp_wmb for store ordering, but it did not involve any IO access (which presumably would disadvantage eieio further). This is very much specific to your particular benchmark. On the 970, there are two differences between lwsync and eieio: 1) lwsync cannot issue before all previous loads are done; eieio does not have this restriction. Then, they both fly through the execution core, it doesn't wait for the barrier insn to complete in the storage system. In both cases, a barrier is inserted into both the L2 queues and the non-cacheable queues. These barriers are both removed at the same time, that is, when both are the oldest in their queue and have done their thing. 2) For eieio, the non-cacheable unit waits for all previous (non-cacheable) stores to complete, and then arbitrates for the bus and sends an EIEIO transaction. Your benchmark doesn't do non-cacheable stores, so it would seem the five-time slowdown is caused by that bus arbitration (and the bus transaction). Maybe your cacheable stores hit the bus as well, that would make this worse. Your benchmark also doesn't see the negative effects from 1). In real code, I expect 2) to be pretty much invisible (the store queues will never be completely filled up), but 1) shouldn't be very bad either. So it's a wash. But only a real benchmark will tell. OK, interesting thanks. Yes the benchmark is not a good one, but it verified for me that there is a difference there. Combined with IBM's documents saying lwsync is preferred for store/store ordering is my rationale for sending the patch. A real benchmark would be nice but it would probably be hard to notice any improvement. Given the G5 speedup, I'd be surprised if there is not an improvment on POWER4 and 5 as well, The 970 storage subsystem and the POWER4 one are very different. Or maybe these queues are just about the last thing that _is_ identical, I dunno, there aren't public POWER4 docs for this ;-) although no idea about POWER6 or cell... No idea about POWER6; for CBE, the backend works similar to the 970 one. Given that the architecture says to use lwsync for cases like this, it would be very surprising if it performed (much) worse than eieio, eh? ;-) So I think your patch is a win; just wanted to clarify on your five-time slowdown number. Sure, thanks! Nick ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5 v3] powerpc: DTS file for the C2K
On Tue, May 20, 2008 at 09:38:08AM -0700, Remi Machet wrote:
On Tue, 2008-05-20 at 11:13 +1000, David Gibson wrote:
On Mon, May 19, 2008 at 05:00:23PM -0700, Remi Machet wrote:
Support for the C2K cPCI Single Board Computer from GEFanuc
(PowerPC MPC7448 with a Marvell MV64460 chipset)
All features of the board are not supported yet, but the board
boots, flash works, all Ethernet ports are working and PCI
devices are all found (USB and SATA on PCI1 do not work yet).
Part 1 of 5: DTS file describing the board peripherals. As far as I know
all peripherals except the FPGA are listed in there (I did not included
the FPGA because a lot of work is needed there).
[snip]
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = marvell,mv64360-eth-group;
+ reg = 0x2000 0x2000;
+ PHY0: [EMAIL PROTECTED] {
+ device_type = ethernet-phy;
+ interrupts = 76; /* GPP 12 */
+ interrupt-parent = PIC;
+ reg = 0;
+ };
+ [EMAIL PROTECTED] {
+ device_type = network;
+ compatible = marvell,mv64360-eth;
+ reg = 0;
+ interrupts = 32;
+ interrupt-parent = PIC;
+ phy = PHY0;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ };
Not sure if this is new, or I just didn't notice it before. Also not
sure if this is your mistake, or a mistake in the binding for the
marvell device here.
The address in reg should be unique within the bus the device
appears on. So having both the PHY and the MAC devices with the same
reg and same unit address here is bad.
Having both the PHYs and the MACs as children of the ethernet-group
node is possible, but the addresses must be encoded to distinguish
them (e.g. MACs are 0x0, 0x1, 0x2, PHYS are 0x1000 0x1001 0x1002).
It was an attempt at getting rid of the mdio group since the PHY is
effectively managed by the Ethernet hardware. The problem is that the
reg field must contain those values ... if I change this, I must change
the driver and other boards DTS files that depend on it which I would
rather not do at the same time I am pushing this patch through.
Right. Getting rid of the mdio node isn't an inherently bad idea, but
it constitutes a change in the binding, so as you've noticed it would
need the drivers to change, and can't just be done for one board
unilaterally.
I will put back the mdio group and add a reg field to it as you
suggested previously.
Ok.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpic: deal with bogus NIRQ in Feature Reporting Register
On May 21, 2008, at 5:11 PM, Scott Wood wrote: On Wed, May 21, 2008 at 03:57:55PM -0500, Kumar Gala wrote: Some chips (like the SoCs from Freescale) report the wrong value in NIRQ and this causes issues if its doesn't match or exceed the value of irq_count. Is it really wrong, or just not accounting for the gap between external and internal interrupts? I consider it wrong by my interpretation of the open-pic spec. The spec says: Num IRQ Sources: The number of highest IRQ source supported. For instance, in a 32 source implementation, this value will be 31. This allows support of a maximum of 2048 interrupt sources. (Interrupt Sources are in the 0x1 to 0x1 range). So for something like 8572, the top most interrupt source is at 0x1CE0. So I'd take that to mean NIRQs should be 231. (0x1CE0 / 0x20 - 1). NIRQS reports 107. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] spi: split up spi_new_device() to allow two stage registration.
On Friday 16 May 2008, Grant Likely wrote: This patch splits the allocation and registration portions of code out of spi_new_device() and creates three new functions; spi_alloc_device(), spi_register_device(), and spi_device_release(). I have no problem with the first two, but why the last? If the devices are always allocated by spi_alloc_device() as they should be -- probably through an intermediary -- the only public function necessary for that cleanup should be the existing spi_dev_put(). - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] spi: Add OF binding support for SPI busses
On Friday 16 May 2008, Grant Likely wrote: In my mind; platform_data and the device tree are all about the same thing: representation. In other words, how to describe the configuration of the hardware independent of the driver itself. Platform_data isn't what I'd call independent of drivers. The reason the data is there in the first place is that the driver needs it ... and chose not to hard-wire it. One of the things I find rather interesting is just how frequently drivers using platform data structures have a big block of code which simply copy pdata fields into identically named fields in the device private data... ... because platform data was designed as a partial template for that driver, letting it do that. (Sometimes without even doing scale conversions.) As drivers grow functionally, they sometimes end up needing more platform data fields, to expose data that previously didn't matter. Whether that data can usefully be stored in flash (or ROM) and handed out through the bootloader is something of a manufacturing issue. - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] 4xx hardware watchpoint support
Luis Machado writes: This is a patch that has been sitting idle for quite some time. I decided to move it further because it is something useful. It was originally written by Michel Darneille, based off of 2.6.16. The original patch, though, was not compatible with the current DABR logic. DABR's are used to implement hardware watchpoint support for ppc64 processors (i.e. 970, Power5 etc). 4xx's have a different debugging register layout and needs to be handled differently (they two registers: DAC and DBCR0). Yes, they are different, but they do essentially the same thing, so I think we should try and unify the handling of the two. Maybe you could rename set_dabr() to set_hw_watchpoint() or something and make it set DABR on 64-bit and classic 32-bit processors, and DAC on 4xx/Book E processors. Likewise, I don't think we need both a dabr field and a dac field in the thread_struct - one should do. Rename dabr to something else if you feel that the dabr name is too ppc64-specific. And I don't think we need both __debugger_dabr_match and __debugger_dac_match. 5) This is something i'm worried about for future features. We currently have a way to support only Hardware Watchpoints, but not Hardware Breakpoints (on 64-bit processors that have a IABR register or 32-bit processors carrying the IAC register). Looking at the code, we don't differentiate a watchpoint from a breakpoint request. A ptrace call has currently 3 arguments: REQUEST, ADDR and DATA. We use REQUEST and DATA to set a hardware watchpoint. Maybe we could use the ADDR parameter to set a hardware breakpoint? Or use it to tell the kernel whether we want a hardware watchpoint or hardware breakpoint and then pass the address of the instruction/data through the DATA parameter? What do you think? I would think there would be a different REQUEST value to mean set a hardware breakpoint. Roland McGrath (cc'd) might be able to tell us what other architectures do. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 1 GB lowmem
On May 21, 2008, at 4:24 PM, Rune Torgersen wrote: Kumar Gala wrote: On May 21, 2008, at 3:55 PM, Rune Torgersen wrote: Argh... Found it. Had to set CONFIG_TASK_SIZE to 0x8000. Now it works in both vaniulla an d RT kernel. We should really add some sanity check on CONFIG_TASK_SIZE vs KERNEL_START. Something like this? Wording sould probablyy be a bit different/cleare. diff --git a/include/asm-powerpc/processor.h b/include/asm-powerpc/processor.h index fd98ca9..72e0e3f 100644 --- a/include/asm-powerpc/processor.h +++ b/include/asm-powerpc/processor.h @@ -81,6 +81,10 @@ extern struct task_struct *last_task_used_altivec; extern struct task_struct *last_task_used_spe; #ifdef CONFIG_PPC32 + +#if CONFIG_TASK_SIZE CONFIG_KERNEL_START +#error User TASK_SIZE overlaps with KERNEL_START address +#endif #define TASK_SIZE (CONFIG_TASK_SIZE) /* This decides where the kernel will search for a free chunk of vm something like that would be good. is there really anything PPC32 specific about it? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] edac: mpc85xx - Fix building as a module
including of asm/mpc85xx.h causes build problems since it doesn't exist. Also removed warning: drivers/edac/mpc85xx_edac.c:45: warning: 'mpc85xx_ctl_name' defined but not used Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- This is a fix for 2.6.26. - k drivers/edac/mpc85xx_edac.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c index 065732d..d49361b 100644 --- a/drivers/edac/mpc85xx_edac.c +++ b/drivers/edac/mpc85xx_edac.c @@ -20,7 +20,6 @@ #include linux/of_platform.h #include linux/of_device.h -#include asm/mpc85xx.h #include edac_module.h #include edac_core.h #include mpc85xx_edac.h @@ -43,8 +42,6 @@ static u32 orig_pci_err_en; static u32 orig_l2_err_disable; static u32 orig_hid1; -static const char *mpc85xx_ctl_name = MPC85xx; - / MC SYSFS parts ***/ static ssize_t mpc85xx_mc_inject_data_hi_show(struct mem_ctl_info *mci, -- 1.5.4.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
