* Re: [patch 02/18] PS3: Rename IPI symbols
From: Will Schmidt @ 2007-06-06 14:48 UTC (permalink / raw)
To: Geoff Levand; +Cc: Stephen Rothwell, Paul Mackerras, linuxppc-dev
In-Reply-To: <20070606131157.133ce9bb.sfr@canb.auug.org.au>
On Wed, 2007-06-06 at 13:11 +1000, Stephen Rothwell wrote:
> On Tue, 05 Jun 2007 19:59:25 -0700 Geoff Levand <geoffrey.levand@am.sony.com> wrote:
> >
> > Rename the PS3 static symbol virqs to ps3_ipi_virqs to aid in
> > debugging.
> >
> > Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
> >
> > for (i = 0; i < MSG_COUNT; i++) {
> > - free_irq(virqs[i], (void*)(long)i);
> > + /* Can't call free_irq from interrupt context. */
>
> This change is probably worth a mention in the change log - it looks like
> a bug fix.
Does the free_irq call (being removed here) need to be added back in
somewhere else?
-Will
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [patch 01/18] Cell: Add spu shutdown method
From: André Detsch @ 2007-06-06 14:41 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann
In-Reply-To: <1181102914.5536.22.camel@concordia.ozlabs.ibm.com>
Michael Ellerman wrote:
> On Tue, 2007-06-05 at 19:59 -0700, Geoff Levand wrote:
>> Add a shutdown method to spu_sysdev_class to allow proper spu resource
>> cleanup on system shutdown. This is needed to support kexec on the PS3
>> platform.
>>
>> Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
>> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
>> ---
>> arch/powerpc/platforms/cell/spu_base.c | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> André, does this interact with your kexec work at all?
No. My cell kexec patch is actually crash-specific, activated under
default_machine_crash_shutdown. Geoff's ps3 kexec patches do not seem to
affect this code path.
--
Andre Detsch
^ permalink raw reply
* Re: [PATCH] [POWERPC] Some extra via-pmu exports
From: Arnd Bergmann @ 2007-06-06 14:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, paulus, Stephen Rothwell
In-Reply-To: <1181139781.3666.3.camel@johannes.berg>
On Wednesday 06 June 2007, Johannes Berg wrote:
> Actually, I think that with the latest patch I sent that disallows you
> to build APM-emulation for 64-bit (which doesn't make sense) this
> shouldn't be a problem any more. Are tehre still some that need
> exporting?
Sorry, I must have missed your patch.
I can confirm that in 2.6.22-rc4 Stephen's patch is no longer needed.
Arnd <><
^ permalink raw reply
* Re: memory issue on ppc
From: Detlev Zundel @ 2007-06-06 14:30 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200706060834.l568YTvM018140@lords.patni.com>
Hello Sekhar,
> I m working on powerpc and new to linux . wrote a small program where
> I allocate memory for 100, 1000 ,10000 bytes and memset them to zero . when I
> allocate to more than 8108 bytes and memset to zero it fails . but when I
> memset to any other ASCII value it passes . can u help me out as I m stuck with
> it for a long time . is there any problem with the library ?
My crystal ball is out of order right now so I would need some more
details to answer.
Please post the code and tell us on what platform and with which
kernel version, gcc version, etc. you are working.
Cheers
Detlev
--
"Our enemies are innovative and resourceful, and so are we. They
never stop thinking about new ways to harm our country and our people,
and neither do we."
-- George W. Bush during a defense bill ceremony on 5. Aug 2004
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: [PATCH] [POWERPC] Some extra via-pmu exports
From: Johannes Berg @ 2007-06-06 14:23 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus, Stephen Rothwell
In-Reply-To: <200706061605.48983.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]
On Wed, 2007-06-06 at 16:05 +0200, Arnd Bergmann wrote:
> On Monday 21 May 2007, Stephen Rothwell wrote:
> > pmu_battery_count, pmu_batteries, pmu_power_flags were only exported
> > for 32 bit builds but are now needed for 64 bit as well.
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> I haven't seen this one show up in 2.6.22-rc or powerpc.git yet,
> but I think we should have it in there to avoid build breakage.
>
> I stumbled over the same bug and wanted to submit a fix when
> I saw it was posted already.
Actually, I think that with the latest patch I sent that disallows you
to build APM-emulation for 64-bit (which doesn't make sense) this
shouldn't be a problem any more. Are tehre still some that need
exporting?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [patch 05/18] PS3: Fix sparse warnings
From: Arnd Bergmann @ 2007-06-06 14:21 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert Uytterhoeven, Paul Mackerras
In-Reply-To: <46662326.4030706@am.sony.com>
On Wednesday 06 June 2007, Geoff Levand wrote:
> -=A0=A0=A0=A0=A0=A0=A0spu->local_store =3D ioremap(spu->local_store_phys,=
LS_SIZE);
> +=A0=A0=A0=A0=A0=A0=A0spu->local_store =3D (__force void *)ioremap(spu->l=
ocal_store_phys,
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 L=
S_SIZE);
I haven't noticed this before, but it seems to be a preexisting bug:
You map the local_store as with the guarded page table bit set, which
causes a performance degradation when accessing the memory from kernel
space.
If you're lucky, your hypervisor knows this and will fix it up for
you, but I would replace the ioremap call with an
ioremap_flags(..., _PAGE_NO_CACHE); to be on the safe side.
If you want to measure the impact, I'd suggest timing a user space
read() on the mem file of a running SPU context.
Arnd <><
^ permalink raw reply
* Re: MPC8349ea Random Device Generator driver
From: Arnd Bergmann @ 2007-06-06 14:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sl, Philippe Lachenal
In-Reply-To: <BAY122-F18923A7AA6D3A4D96A360085200@phx.gbl>
On Tuesday 05 June 2007, Philippe Lachenal wrote:
> I've made a driver for the MPC8349ea Random Device Generator, and I=20
> therefore submit it to your impartial judgment.. ;)
Looks good from the point of integration into the driver framework.
I can't judge the hwrng specific parts, but don't see anything
fundamentally wrong there.
> +static int __init mpc834x_itx_declare_of_platform_devices(void)
> +{
> +=A0=A0=A0=A0=A0=A0=A0if (!machine_is(mpc834x_itx)){
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk("__init mpc834x_itx_=
declare_of_platform_devices error\n");
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return 0;
> +=A0=A0=A0=A0=A0=A0=A0}
I would think that it's not strictly an error to be running on some other
hardware than yours ;-)
Just remove the printk here.
> +=A0=A0=A0=A0=A0=A0=A0err =3D of_address_to_resource(rng_np, 0, &res);
> +=A0=A0=A0=A0=A0=A0=A0if (err)
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return -ENODEV;=A0
> +=A0=A0=A0=A0=A0=A0=A0rng_regs =3D ioremap(res.start, (res.end - res.star=
t));
This can be done in one step with the new 'of_iomap' function.
> +=A0=A0=A0=A0=A0=A0=A0printk(KERN_INFO "Registering Talitos RNG\n");
> +
> +=A0=A0=A0=A0=A0=A0=A0err =3D hwrng_register(&talitos_rng);
> +=A0=A0=A0=A0=A0=A0=A0if (err){
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0printk(".............. fail=
ure\n");
> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0iounmap(rng_regs);
> +=A0=A0=A0=A0=A0=A0=A0}
This printk should have a KERN_ERROR or similar level.
Ideally, replace all instances of printk in your driver with 'dev_err',
'dev_info' or similar calls from <linux/device.h>.
Arnd <><
^ permalink raw reply
* Re: [PATCH] [POWERPC] Some extra via-pmu exports
From: Arnd Bergmann @ 2007-06-06 14:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, paulus
In-Reply-To: <20070521150531.e498340a.sfr@canb.auug.org.au>
On Monday 21 May 2007, Stephen Rothwell wrote:
> pmu_battery_count, pmu_batteries, pmu_power_flags were only exported
> for 32 bit builds but are now needed for 64 bit as well.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
I haven't seen this one show up in 2.6.22-rc or powerpc.git yet,
but I think we should have it in there to avoid build breakage.
I stumbled over the same bug and wanted to submit a fix when
I saw it was posted already.
Arnd <><
^ permalink raw reply
* [PATCH] Enable SPI controller support for Xilinx ML300 board
From: Andrei Konovalov @ 2007-06-06 14:11 UTC (permalink / raw)
To: linuxppc-embedded
-------- Original Message --------
> Subject: [PATCH] Simple driver for Xilinx SPI controler.
> Date: Wed, 06 Jun 2007 18:05:59 +0400
> From: Andrei Konovalov <akonovalov@ru.mvista.com>
> To: spi-devel-general@lists.sourceforge.net
> CC: linuxppc-embedded@ozlabs.org
<snip>
> The patch to enable SPI for Xilinx ML300 board (EDK reference design)
> will be sent to linuxppc-embedded list shortly.
Here it goes.
EDK 8.2 doesn't create a "Canonical Constant Name" for the
number of slave selects, so the definition of XPAR_SPI_0_NUM_SS_BITS
has been added to xparameters_ml300.h by hand.
Thanks,
Andrei
Signed-off-by: Andrei Konovalov <akonovalov@ru.mvista.com>
---
arch/ppc/platforms/4xx/xilinx_ml300.c | 31 +++++++++++++++++++++++++
arch/ppc/syslib/virtex_devices.c | 40 +++++++++++++++++++++++++++++++++
2 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/platforms/4xx/xilinx_ml300.c b/arch/ppc/platforms/4xx/xilinx_ml300.c
index 623aa92..e065c1b 100644
--- a/arch/ppc/platforms/4xx/xilinx_ml300.c
+++ b/arch/ppc/platforms/4xx/xilinx_ml300.c
@@ -16,6 +16,8 @@
#include <linux/serial_core.h>
#include <linux/serial_8250.h>
#include <linux/serialP.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/eeprom.h>
#include <asm/io.h>
#include <asm/machdep.h>
@@ -122,6 +124,27 @@ static struct xilinxfb_platform_data xilinxfb_ml300_pdata = {
.screen_width_mm = 132,
};
+#ifdef CONFIG_SPI_XILINX
+
+static struct spi_eeprom ml300_eeprom = {
+ .byte_len = 2048,
+ .name = "25LC160",
+ .page_size = 16,
+ .flags = EE_ADDR2,
+};
+
+static struct spi_board_info ml300_spi_board_info[] = {
+ {
+ .modalias = "at25",
+ .platform_data = &ml300_eeprom,
+ .max_speed_hz = 2 * 1000 * 1000,
+ .bus_num = 0,
+ .chip_select = 0,
+ },
+};
+
+#endif /* CONFIG_SPI_XILINX */
+
int __init virtex_device_fixup(struct platform_device *dev)
{
if (strcmp(dev->name, "xilinxfb") == 0) {
@@ -130,6 +153,14 @@ int __init virtex_device_fixup(struct platform_device *dev)
dev->dev.platform_data = &xilinxfb_ml300_pdata;
return 0;
}
+#ifdef CONFIG_SPI_XILINX
+ if (strcmp(dev->name, "xspi") == 0) {
+ if (dev->id != 0) /* paranoic */
+ return 1;
+ spi_register_board_info(ml300_spi_board_info,
+ ARRAY_SIZE(ml300_spi_board_info));
+ }
return 0;
+#endif /* CONFIG_SPI_XILINX */
}
diff --git a/arch/ppc/syslib/virtex_devices.c b/arch/ppc/syslib/virtex_devices.c
index 56cbdd6..4a2d106 100644
--- a/arch/ppc/syslib/virtex_devices.c
+++ b/arch/ppc/syslib/virtex_devices.c
@@ -161,6 +161,41 @@ DEFINE_XPAR_TEMAC_PDATA(1);
}, \
}
+/*
+ * SPI platform data
+ */
+#define DEFINE_XPAR_SPI_PDATA(num) \
+static struct xspi_platform_data xspi_##num##_pdata = { \
+ .bus_num = XPAR_SPI_##num##_DEVICE_ID, \
+ .num_chipselect = XPAR_SPI_##num##_NUM_SS_BITS, \
+}
+
+#ifdef XPAR_SPI_0_BASEADDR
+DEFINE_XPAR_SPI_PDATA(0);
+#endif /* XPAR_SPI_0_BASEADDR */
+
+/*
+ * SPI: shortcut macro for single instance
+ */
+#define XPAR_SPI(num) { \
+ .name = "xspi", \
+ .id = XPAR_SPI_##num##_DEVICE_ID, \
+ .dev.platform_data = &xspi_##num##_pdata, \
+ .num_resources = 2, \
+ .resource = (struct resource[]) { \
+ { \
+ .start = XPAR_SPI_##num##_BASEADDR, \
+ .end = XPAR_SPI_##num##_HIGHADDR, \
+ .flags = IORESOURCE_MEM, \
+ }, \
+ { \
+ .start = XPAR_INTC_0_SPI_##num##_VEC_ID, \
+ .end = XPAR_INTC_0_SPI_##num##_VEC_ID, \
+ .flags = IORESOURCE_IRQ, \
+ }, \
+ }, \
+}
+
struct platform_device virtex_platform_devices[] = {
/* UARTLITE instances */
#if defined(XPAR_UARTLITE_0_BASEADDR)
@@ -220,6 +255,11 @@ struct platform_device virtex_platform_devices[] = {
#ifdef XPAR_TEMAC_1_BASEADDR
XPAR_TEMAC(1),
#endif
+
+ /* SPI instances */
+#ifdef XPAR_SPI_0_BASEADDR
+ XPAR_SPI(0),
+#endif /* XPAR_SPI_0_BASEADDR */
};
/* Early serial support functions */
--
1.5.1.1
^ permalink raw reply related
* [PATCH] Simple driver for Xilinx SPI controler.
From: Andrei Konovalov @ 2007-06-06 14:05 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-embedded
Only master mode is supported.
No support for multiple masters. Slave mode is not supported either.
Not using level 1 drivers from EDK.
The reason not to use EDK is basically this driver being a simple one:
- SPI level 1 driver from EDK supports much more then needed for this
simple version of the SPI driver (slave mode, multiple masters etc).
And leaving just single master case alone is not possible without
changing the level 1 driver.
- SPI level 1 driver from EDK manipulates chip selects on its own.
This makes it impossible to use the spi_bitbang.
The driver has been tested with Xilinx ML300 reference design.
The patch to enable SPI for Xilinx ML300 board (EDK reference design)
will be sent to linuxppc-embedded list shortly.
Would be nice to get this driver into mainline.
Reviews and comments are welcome.
Thanks,
Andrei
Signed-off-by: Yuri Frolov <yfrolov@ru.mvista.com>
Signed-off-by: Andrei Konovalov <akonovalov@ru.mvista.com>
---
arch/ppc/syslib/virtex_devices.h | 6 +
drivers/spi/Kconfig | 9 +
drivers/spi/Makefile | 1 +
drivers/spi/xilinx_spi.c | 447 ++++++++++++++++++++++++++++++++++++++
4 files changed, 463 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/xilinx_spi.c
diff --git a/arch/ppc/syslib/virtex_devices.h b/arch/ppc/syslib/virtex_devices.h
index b49dc61..9ab3152 100644
--- a/arch/ppc/syslib/virtex_devices.h
+++ b/arch/ppc/syslib/virtex_devices.h
@@ -45,4 +45,10 @@ struct xtemac_platform_data {
u8 mac_addr[6];
};
+/* SPI Controller IP */
+struct xspi_platform_data {
+ s16 bus_num;
+ u16 num_chipselect;
+};
+
#endif /* __ASM_VIRTEX_DEVICES_H__ */
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 5e3f748..851d651 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -156,6 +156,15 @@ config SPI_S3C24XX_GPIO
GPIO lines to provide the SPI bus. This can be used where
the inbuilt hardware cannot provide the transfer mode, or
where the board is using non hardware connected pins.
+
+config SPI_XILINX
+ tristate "Xilinx SPI controller"
+ depends on SPI_MASTER && XILINX_VIRTEX && EXPERIMENTAL
+ select SPI_BITBANG
+ help
+ This enables using the SPI controller IP from Xilinx EDK in master
+ mode. See the DS464, "OPB Serial Peripheral Interface (SPI) (v1.00e)"
+ Product Specification document for the hardware details.
#
# Add new SPI master controllers in alphabetical order above this line
#
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 5788d86..a2412bd 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_SPI_MPC52xx_PSC) += mpc52xx_psc_spi.o
obj-$(CONFIG_SPI_MPC83xx) += spi_mpc83xx.o
obj-$(CONFIG_SPI_S3C24XX_GPIO) += spi_s3c24xx_gpio.o
obj-$(CONFIG_SPI_S3C24XX) += spi_s3c24xx.o
+obj-$(CONFIG_SPI_XILINX) += xilinx_spi.o
# ... add above this line ...
# SPI protocol drivers (device/link on bus)
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
new file mode 100644
index 0000000..e5f149f
--- /dev/null
+++ b/drivers/spi/xilinx_spi.c
@@ -0,0 +1,447 @@
+/*
+ * xilinx_spi.c
+ *
+ * Xilinx SPI controler driver (master mode only)
+ *
+ * Author: MontaVista Software, Inc.
+ * source@mvista.com
+ *
+ * 2002-2007 (c) MontaVista Software, Inc. This file is licensed under the
+ * terms of the GNU General Public License version 2. This program is licensed
+ * "as is" without any warranty of any kind, whether express or implied.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/spi/spi.h>
+#include <linux/spi/spi_bitbang.h>
+
+#include <asm/io.h>
+#include <syslib/virtex_devices.h>
+
+#define XILINX_SPI_NAME "xspi"
+
+/* Register definitions as per "OPB Serial Peripheral Interface (SPI) (v1.00e)
+ * Product Specification", DS464
+ */
+#define XSPI_CR_OFFSET 0x62 /* 16-bit Control Register */
+
+#define XSPI_CR_ENABLE 0x02
+#define XSPI_CR_MASTER_MODE 0x04
+#define XSPI_CR_CPOL 0x08
+#define XSPI_CR_CPHA 0x10
+#define XSPI_CR_MODE_MASK (XSPI_CR_CPHA | XSPI_CR_CPOL)
+#define XSPI_CR_TXFIFO_RESET 0x20
+#define XSPI_CR_RXFIFO_RESET 0x40
+#define XSPI_CR_MANUAL_SSELECT 0x80
+#define XSPI_CR_TRANS_INHIBIT 0x100
+
+#define XSPI_SR_OFFSET 0x67 /* 8-bit Status Register */
+
+#define XSPI_SR_RX_EMPTY_MASK 0x01 /* Receive FIFO is empty */
+#define XSPI_SR_RX_FULL_MASK 0x02 /* Receive FIFO is full */
+#define XSPI_SR_TX_EMPTY_MASK 0x04 /* Transmit FIFO is empty */
+#define XSPI_SR_TX_FULL_MASK 0x08 /* Transmit FIFO is full */
+#define XSPI_SR_MODE_FAULT_MASK 0x10 /* Mode fault error */
+
+#define XSPI_TXD_OFFSET 0x6b /* 8-bit Data Transmit Register */
+#define XSPI_RXD_OFFSET 0x6f /* 8-bit Data Receive Register */
+
+#define XSPI_SSR_OFFSET 0x70 /* 32-bit Slave Select Register */
+
+/* Register definitions as per "OPB IPIF (v3.01c) Product Specification", DS414
+ * IPIF registers are 32 bit
+ */
+#define XIPIF_V123B_DGIER_OFFSET 0x1c /* IPIF global int enable reg */
+#define XIPIF_V123B_GINTR_ENABLE 0x80000000
+
+#define XIPIF_V123B_IISR_OFFSET 0x20 /* IPIF interrupt status reg */
+#define XIPIF_V123B_IIER_OFFSET 0x28 /* IPIF interrupt enable reg */
+
+#define XSPI_INTR_MODE_FAULT 0x01 /* Mode fault error */
+#define XSPI_INTR_SLAVE_MODE_FAULT 0x02 /* Selected as slave while
+ * disabled */
+#define XSPI_INTR_TX_EMPTY 0x04 /* TxFIFO is empty */
+#define XSPI_INTR_TX_UNDERRUN 0x08 /* TxFIFO was underrun */
+#define XSPI_INTR_RX_FULL 0x10 /* RxFIFO is full */
+#define XSPI_INTR_RX_OVERRUN 0x20 /* RxFIFO was overrun */
+
+#define XIPIF_V123B_RESETR_OFFSET 0x40 /* IPIF reset register */
+#define XIPIF_V123B_RESET_MASK 0x0a /* the value to write */
+
+/* Simple macros to get the code more readable */
+#define xspi_in16(addr) in_be16((u16 __iomem *)(addr))
+#define xspi_in32(addr) in_be32((u32 __iomem *)(addr))
+#define xspi_out16(addr, value) out_be16((u16 __iomem *)(addr), (value))
+#define xspi_out32(addr, value) out_be32((u32 __iomem *)(addr), (value))
+
+struct xilinx_spi {
+ /* bitbang has to be first */
+ struct spi_bitbang bitbang;
+ struct completion done;
+
+ u32 regs_phys; /* phys. address of the control registers */
+ void __iomem *regs; /* virt. address of the control registers */
+
+ u32 irq;
+
+ u8 *rx_ptr; /* pointer in the Tx buffer */
+ const u8 *tx_ptr; /* pointer in the Rx buffer */
+ int remaining_bytes; /* the number of bytes left to transfer */
+};
+
+static void xspi_abort_transfer(u8 __iomem *regs_base)
+{
+ /* Deselect the slave on the SPI bus */
+ xspi_out32(regs_base + XSPI_SSR_OFFSET, 0xffff);
+
+ /* Terminate transmit in progress (if any) and Reset the FIFOs */
+ xspi_out16(regs_base + XSPI_CR_OFFSET,
+ xspi_in16(regs_base + XSPI_CR_OFFSET)
+ | XSPI_CR_TRANS_INHIBIT | XSPI_CR_TXFIFO_RESET
+ | XSPI_CR_RXFIFO_RESET);
+}
+
+static void xspi_init_hw(u8 __iomem *regs_base)
+{
+ /* Reset the SPI device */
+ xspi_out32(regs_base + XIPIF_V123B_RESETR_OFFSET,
+ XIPIF_V123B_RESET_MASK);
+ /* Disable all the interrupts just in case */
+ xspi_out32(regs_base + XIPIF_V123B_IIER_OFFSET, 0);
+ /* Enable the global IPIF interrupt */
+ xspi_out32(regs_base + XIPIF_V123B_DGIER_OFFSET,
+ XIPIF_V123B_GINTR_ENABLE);
+ /* Deselect the slave on the SPI bus */
+ xspi_out32(regs_base + XSPI_SSR_OFFSET, 0xffff);
+ /* Disable the transmitter, enable Manual Slave Select Assertion,
+ * put SPI controller into master mode, and enable it */
+ xspi_out16(regs_base + XSPI_CR_OFFSET,
+ XSPI_CR_TRANS_INHIBIT | XSPI_CR_MANUAL_SSELECT
+ | XSPI_CR_MASTER_MODE | XSPI_CR_ENABLE);
+}
+
+static void xilinx_spi_chipselect(struct spi_device *spi, int is_on)
+{
+ struct xilinx_spi *xspi;
+ u8 __iomem *regs_base;
+
+ xspi = spi_master_get_devdata(spi->master);
+ regs_base = xspi->regs;
+
+ if (is_on == BITBANG_CS_INACTIVE) {
+ /* Deselect the slave on the SPI bus */
+ xspi_out32(regs_base + XSPI_SSR_OFFSET, 0xffff);
+ } else if (is_on == BITBANG_CS_ACTIVE) {
+ /* Set the SPI clock phase and polarity */
+ u16 cr = xspi_in16(regs_base + XSPI_CR_OFFSET)
+ & ~XSPI_CR_MODE_MASK;
+ if (spi->mode & SPI_CPHA)
+ cr |= XSPI_CR_CPHA;
+ if (spi->mode & SPI_CPOL)
+ cr |= XSPI_CR_CPOL;
+ xspi_out16(regs_base + XSPI_CR_OFFSET, cr);
+
+ /* We do not check spi->max_speed_hz here as the SPI clock
+ * frequency is not software programmable (the IP block design
+ * parameter)
+ */
+
+ /* Activate the chip select */
+ xspi_out32(regs_base + XSPI_SSR_OFFSET,
+ ~(0x0001 << spi->chip_select));
+ }
+}
+
+/* spi_bitbang requires custom setup_transfer() to be defined if there is a
+ * custom txrx_bufs(). We have nothing to setup here as the SPI IP block
+ * supports just 8 bits per word, and SPI clock can't be changed in software.
+ * Check for 8 bits per word; speed_hz checking could be added if the SPI
+ * clock information is available. Chip select delay calculations could be
+ * added here as soon as bitbang_work() can be made aware of the delay value.
+ */
+static int xilinx_spi_setup_transfer(struct spi_device *spi,
+ struct spi_transfer *t)
+{
+ u8 bits_per_word;
+
+ bits_per_word = (t) ? t->bits_per_word : spi->bits_per_word;
+ if (bits_per_word != 8)
+ return -EINVAL;
+
+ return 0;
+}
+
+
+static int xilinx_spi_setup(struct spi_device *spi)
+{
+ struct spi_bitbang *bitbang;
+ struct xilinx_spi *xspi;
+ int retval;
+
+ xspi = spi_master_get_devdata(spi->master);
+ bitbang = &xspi->bitbang;
+
+ if (!spi->bits_per_word)
+ spi->bits_per_word = 8;
+
+ retval = xilinx_spi_setup_transfer(spi, NULL);
+ if (retval < 0)
+ return retval;
+
+ dev_dbg(&spi->dev, "%s, mode %d, %u bits/w, %u nsec/bit\n",
+ __FUNCTION__, spi->mode & (SPI_CPOL | SPI_CPHA),
+ spi->bits_per_word, 0);
+
+ return 0;
+}
+
+static int xilinx_spi_txrx_bufs(struct spi_device *spi, struct spi_transfer *t)
+{
+ struct xilinx_spi *xspi;
+ u8 __iomem *regs_base;
+ u32 ipif_ier;
+ u16 cr;
+ u8 sr;
+
+ /* We get here with transmitter inhibited */
+
+ xspi = spi_master_get_devdata(spi->master);
+ regs_base = xspi->regs;
+
+ xspi->tx_ptr = t->tx_buf;
+ xspi->rx_ptr = t->rx_buf;
+ xspi->remaining_bytes = t->len;
+ INIT_COMPLETION(xspi->done);
+
+ /* Fill the Tx FIFO with as many bytes as possible */
+ sr = in_8(regs_base + XSPI_SR_OFFSET);
+ while ((sr & XSPI_SR_TX_FULL_MASK) == 0 && xspi->remaining_bytes > 0) {
+ if (xspi->tx_ptr) {
+ out_8(regs_base + XSPI_TXD_OFFSET, *xspi->tx_ptr++);
+ } else {
+ out_8(regs_base + XSPI_TXD_OFFSET, 0);
+ }
+ xspi->remaining_bytes--;
+ sr = in_8(regs_base + XSPI_SR_OFFSET);
+ }
+
+ /* Enable the transmit empty interrupt, which we use to determine
+ * progress on the transmission.
+ */
+ ipif_ier = xspi_in32(regs_base + XIPIF_V123B_IIER_OFFSET);
+ xspi_out32(regs_base + XIPIF_V123B_IIER_OFFSET,
+ ipif_ier | XSPI_INTR_TX_EMPTY);
+
+ /* Start the transfer by not inhibiting the transmitter any longer */
+ cr = xspi_in16(regs_base + XSPI_CR_OFFSET) & ~XSPI_CR_TRANS_INHIBIT;
+ xspi_out16(regs_base + XSPI_CR_OFFSET, cr);
+
+ wait_for_completion(&xspi->done);
+
+ /* Disable the transmit empty interrupt */
+ xspi_out32(regs_base + XIPIF_V123B_IIER_OFFSET, ipif_ier);
+
+ return t->len - xspi->remaining_bytes;
+}
+
+
+/* This driver supports single master mode only. Hence Tx FIFO Empty
+ * is the only interrupt we care about.
+ * Receive FIFO Overrun, Transmit FIFO Underrun, Mode Fault, and Slave Mode
+ * Fault are not to happen.
+ */
+static irqreturn_t xilinx_spi_irq(int irq, void *dev_id)
+{
+ struct xilinx_spi *xspi;
+ u8 __iomem *regs_base;
+ u32 ipif_isr;
+
+ xspi = (struct xilinx_spi *) dev_id;
+ regs_base = xspi->regs;
+
+ /* Get the IPIF inetrrupts, and clear them immediately */
+ ipif_isr = xspi_in32(regs_base + XIPIF_V123B_IISR_OFFSET);
+ xspi_out32(regs_base + XIPIF_V123B_IISR_OFFSET, ipif_isr);
+
+ if (ipif_isr & XSPI_INTR_TX_EMPTY) { /* Transmission completed */
+ u16 cr;
+ u8 sr;
+
+ /* A transmit has just completed. Process received data and
+ * check for more data to transmit. Always inhibit the
+ * transmitter while the Isr refills the transmit register/FIFO,
+ * or make sure it is stopped if we're done.
+ */
+ cr = xspi_in16(regs_base + XSPI_CR_OFFSET);
+ xspi_out16(regs_base + XSPI_CR_OFFSET,
+ cr | XSPI_CR_TRANS_INHIBIT);
+
+ /* Read out all the data from the Rx FIFO */
+ sr = in_8(regs_base + XSPI_SR_OFFSET);
+ while ((sr & XSPI_SR_RX_EMPTY_MASK) == 0) {
+ u8 data;
+
+ data = in_8(regs_base + XSPI_RXD_OFFSET);
+ if (xspi->rx_ptr) {
+ *xspi->rx_ptr++ = data;
+ }
+ sr = in_8(regs_base + XSPI_SR_OFFSET);
+ }
+
+ /* See if there is more data to send */
+ if (xspi->remaining_bytes > 0) {
+ /* sr content is valid here; no need for io_8() */
+ while ((sr & XSPI_SR_TX_FULL_MASK) == 0
+ && xspi->remaining_bytes > 0) {
+ if (xspi->tx_ptr) {
+ out_8(regs_base + XSPI_TXD_OFFSET,
+ *xspi->tx_ptr++);
+ } else {
+ out_8(regs_base + XSPI_TXD_OFFSET, 0);
+ }
+ xspi->remaining_bytes--;
+ sr = in_8(regs_base + XSPI_SR_OFFSET);
+ }
+ /* Start the transfer by not inhibiting the
+ * transmitter any longer
+ */
+ xspi_out16(regs_base + XSPI_CR_OFFSET, cr);
+ } else {
+ /* No more data to send.
+ * Indicate the transfer is completed.
+ */
+ complete(&xspi->done);
+ }
+ } else {
+ /* spurious interrupt */
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int __init xilinx_spi_probe(struct platform_device *dev)
+{
+ int ret = 0;
+ struct spi_master *master;
+ struct xilinx_spi *xspi;
+ struct xspi_platform_data *pdata;
+ struct resource *r;
+
+ /* Get resources(memory, IRQ) associated with the device */
+ master = spi_alloc_master(&dev->dev, sizeof(struct xilinx_spi));
+
+ if (master == NULL) {
+ return -ENOMEM;
+ }
+
+ platform_set_drvdata(dev, master);
+ pdata = dev->dev.platform_data;
+
+ if (pdata == NULL) {
+ ret = -ENODEV;
+ goto put_master;
+ }
+
+ r = platform_get_resource(dev, IORESOURCE_MEM, 0);
+ if (r == NULL) {
+ ret = -ENODEV;
+ goto put_master;
+ }
+
+ xspi = spi_master_get_devdata(master);
+ xspi->bitbang.master = spi_master_get(master);
+ xspi->bitbang.chipselect = xilinx_spi_chipselect;
+ xspi->bitbang.setup_transfer = xilinx_spi_setup_transfer;
+ xspi->bitbang.txrx_bufs = xilinx_spi_txrx_bufs;
+ xspi->bitbang.master->setup = xilinx_spi_setup;
+ init_completion(&xspi->done);
+
+ xspi->regs = ioremap(r->start, r->end - r->start + 1);
+ if (xspi->regs == NULL) {
+ ret = -ENOMEM;
+ goto put_master;
+ }
+
+ xspi->irq = platform_get_irq(dev, 0);
+ if (xspi->irq < 0) {
+ ret = -ENXIO;
+ goto unmap_io;
+ }
+
+ master->bus_num = pdata->bus_num;
+ master->num_chipselect = pdata->num_chipselect;
+
+ /* SPI controller initializations */
+ xspi_init_hw(xspi->regs);
+
+ /* Register for SPI Interrupt */
+ ret = request_irq(xspi->irq, xilinx_spi_irq, 0, XILINX_SPI_NAME, xspi);
+ if (ret != 0)
+ goto unmap_io;
+
+ ret = spi_bitbang_start(&xspi->bitbang);
+ if (ret != 0) {
+ printk(KERN_ALERT "spi_btbang_start FAILED\n");
+ goto free_irq;
+ }
+
+ printk(KERN_INFO "%s: at 0x%08X mapped to 0x%08X, irq=%d\n",
+ dev->dev.bus_id, r->start, (u32)xspi->regs, xspi->irq);
+
+ return ret;
+
+free_irq:
+ free_irq(xspi->irq, xspi);
+unmap_io:
+ iounmap(xspi->regs);
+put_master:
+ spi_master_put(master);
+ return ret;
+}
+
+static int __devexit xilinx_spi_remove(struct platform_device *dev)
+{
+ struct xilinx_spi *xspi;
+ struct spi_master *master;
+
+ master = platform_get_drvdata(dev);
+ xspi = spi_master_get_devdata(master);
+
+ spi_bitbang_stop(&xspi->bitbang);
+ xspi_abort_transfer(xspi->regs);
+ free_irq(xspi->irq, xspi);
+ iounmap(xspi->regs);
+ platform_set_drvdata(dev, 0);
+ spi_master_put(xspi->bitbang.master);
+
+ return 0;
+}
+
+static struct platform_driver xilinx_spi_driver = {
+ .probe = xilinx_spi_probe,
+ .remove = __devexit_p(xilinx_spi_remove),
+ .driver = {
+ .name = XILINX_SPI_NAME,
+ .owner = THIS_MODULE,
+ },
+};
+
+static int __init xilinx_spi_init(void)
+{
+ return platform_driver_register(&xilinx_spi_driver);
+}
+
+static void __exit xilinx_spi_exit(void)
+{
+ platform_driver_unregister(&xilinx_spi_driver);
+}
+
+module_init(xilinx_spi_init);
+module_exit(xilinx_spi_exit);
+
+MODULE_AUTHOR("MontaVista Software, Inc. <source@mvista.com>");
+MODULE_DESCRIPTION("Xilinx SPI driver");
+MODULE_LICENSE("GPL");
--
1.5.1.1
^ permalink raw reply related
* Re: [PATCH] of_serial: ignore unknown serial port
From: Segher Boessenkool @ 2007-06-06 13:44 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200706061501.15853.arnd@arndb.de>
>>> Is this a bugfix that needs to go in 2.6.22?
>>
>> This potentially breaks lots of other platforms, so no
>> please, put it in early in the next cycle and give those
>> others time to recover from this change.
>
> I would expect that the bugfix is relatively harmless,
Sure, but you cannot prove that without checking all possibly
affected systems' device trees, that's my whole point. If
you need a fix for .22 you can always put a conditional on
celleb around the offending code. Anyway, Paul's choice.
Segher
^ permalink raw reply
* Re: [PATCH] of_serial: ignore unknown serial port
From: Arnd Bergmann @ 2007-06-06 13:01 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <fe647387a21ec103882e7cf577d0d7d5@kernel.crashing.org>
On Wednesday 06 June 2007, Segher Boessenkool wrote:
> >
> > Is this a bugfix that needs to go in 2.6.22?
>
> This potentially breaks lots of other platforms, so no
> please, put it in early in the next cycle and give those
> others time to recover from this change.
I would expect that the bugfix is relatively harmless, as the
driver is rather new and there can only be a very small set
of users. All the OF based systems should be working fine
either way, because they already have legacy_serial, and
the dtc sources that come with the kernel all list the
serial ports as compatible to either "ns16550", "cpm_uart",
"marvell,mpsc", or "mpc5200-psc-uart". In the first case
of those four, the change is harmless, for the other three
it is a valid bug fix.
It probably only makes a difference for 52xx in the case that
you have CONFIG_SERIAL_OF_PLATFORM=y and CONFIG_SERIAL_MPC52xx=m.
In that configuration, you get the same bug that Kou Ishizaki
observed on celleb without this fix.
Arnd <><
^ permalink raw reply
* Re: [PATCH] powerpc: Create "rom" (MTD) device prpmc2800
From: Sergei Shtylyov @ 2007-06-06 12:41 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20070605211114.GA17131@mag.az.mvista.com>
Hello.
Mark A. Greer wrote:
>>Mark A. Greer wrote:
>>> flash@a0000000 {
>>> device_type = "rom";
>>> compatible = "direct-mapped";
>>> reg = <a0000000 4000000>; /* Default (64MB) */
>>> probe-type = "CFI";
>>> bank-width = <4>;
>>> partitions = <00000000 00100000 /* RO */
>>> 00100000 00040001 /* RW */
>>> 00140000 00400000 /* RO */
>>> 00540000 039c0000 /* RO */
>>> 03f00000 00100000>; /* RO */
>> Hm, this should have been the other way around -- ones with odd size are
>>RO, ones with even size are RW.
> Yeah, that's what the comment says but the code says the opposite:
> if (*part++ & 1) /* bit 0 set signifies read only partition */
> (*parts)[i].mask_flags = MTD_WRITEABLE;
> Doesn't that make it RW if bit 0 is set?
Contrarywise, though this may surprise you. ;-)
This is a question to MTD people...
WBR, Sergei
^ permalink raw reply
* cpm_setbrg problem
From: Matvejchikov Ilya @ 2007-06-06 12:30 UTC (permalink / raw)
To: linuxppc-embedded
Hi all!
There is a problem in cpm_setbrg (arch/powerpc/sysdev/cpm2_common.c
file) function. When rate 9600 all is OK, but with 115200 it doesn't
work properly. As I see it the following is incorrect:
*bp = ((BRG_UART_CLK / rate) << 1) | CPM_BRG_EN;
it must be
*bp = (((BRG_UART_CLK / rate) - 1) << 1) | CPM_BRG_EN;
Best regards,
Matvejchikov Ilya.
^ permalink raw reply
* Re: [patch 18/18] PS3: Device registration routines.
From: Geert Uytterhoeven @ 2007-06-06 12:21 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <466623A4.1080102@am.sony.com>
On Tue, 5 Jun 2007, Geoff Levand wrote:
> +static int __init ps3_register_vuart_devices(void)
> +{
> + int result;
> + unsigned int port_number;
> +
> + pr_debug(" -> %s:%d\n", __func__, __LINE__);
> +
> + result = ps3_repository_read_vuart_av_port(&port_number);
> +
> + if (result)
> + port_number = 0; /* av default */
> +
> + result = ps3_setup_vuart_device(PS3_MATCH_ID_AV_SETTINGS, port_number);
> + WARN_ON(result);
> +
> + ps3_repository_read_vuart_sysmgr_port(&port_number);
^^^^
> +
> + if (result)
> + port_number = 2; /* sysmgr default */
You forgot to assign the return value of
ps3_repository_read_vuart_sysmgr_port(). As the system manager vuart port
number is not in the repository on the firmware I'm using, port_number contains
garbage, and ps3_vuart_probe() will BUG().
As this problem is present in your current git tree, here's a patch:
Subject: [PATCH] Check return value of ps3_repository_read_vuart_sysmgr_port()
Add a missing assignment of the return value of
ps3_repository_read_vuart_sysmgr_port(). As the system manager vuart port
number is not in the repository on the firmware I'm using, port_number contains
garbage, and ps3_vuart_probe() will BUG().
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
--- a/arch/powerpc/platforms/ps3/device-init.c 2007-06-06 13:58:43.000000000 +0200
+++ b/arch/powerpc/platforms/ps3/device-init.c 2007-06-06 14:12:35.000000000 +0200
@@ -505,15 +505,13 @@ static int __init ps3_register_vuart_dev
pr_debug(" -> %s:%d\n", __func__, __LINE__);
result = ps3_repository_read_vuart_av_port(&port_number);
-
if (result)
port_number = 0; /* av default */
result = ps3_setup_vuart_device(PS3_MATCH_ID_AV_SETTINGS, port_number);
WARN_ON(result);
- ps3_repository_read_vuart_sysmgr_port(&port_number);
-
+ result = ps3_repository_read_vuart_sysmgr_port(&port_number);
if (result)
port_number = 2; /* sysmgr default */
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* Re: [PATCH] Fix interrupt distribution in ppc970
From: Mohan Kumar M @ 2007-06-06 11:31 UTC (permalink / raw)
To: Milton Miller, Paul Mackerras; +Cc: ppcdev, kexec
In-Reply-To: <c1b8d82c8241fc3750c1339c34ecc799@bga.com>
I updated the patch with correct tab spacing and removed unnecessary
"else".
In some of the PPC970 based systems, interrupt would be distributed to
offline cpus also even when booted with "maxcpus=1". So check whether
cpu online map and cpu present map are equal or not. If they are equal
default_distrib_server is used as interrupt server otherwise boot cpu
(default_server) used as interrupt server.
In addition to this, if an interrupt is assigned to a specific cpu (ie
smp affinity) and if that cpu is not online, the earlier code used to
return the default_distrib_server as interrupt server. This patch
introduces an additional paramter to the get_irq function ie
strict_check, based on this parameter, if the cpu is not online either
default_distrib_server or -1 is returned.
Cc: Milton Miller <miltonm@bga.com>,
Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
---
arch/powerpc/platforms/pseries/xics.c | 53 ++++++++++++++++++----------------
1 file changed, 29 insertions(+), 24 deletions(-)
Index: linux-2.6.21.1/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- linux-2.6.21.1.orig/arch/powerpc/platforms/pseries/xics.c
+++ linux-2.6.21.1/arch/powerpc/platforms/pseries/xics.c
@@ -156,9 +156,9 @@ static inline void lpar_qirr_info(int n_
#ifdef CONFIG_SMP
-static int get_irq_server(unsigned int virq)
+static int get_irq_server(unsigned int virq, unsigned int strict_check)
{
- unsigned int server;
+ int server;
/* For the moment only implement delivery to all cpus or one cpu */
cpumask_t cpumask = irq_desc[virq].affinity;
cpumask_t tmp = CPU_MASK_NONE;
@@ -166,22 +166,25 @@ static int get_irq_server(unsigned int v
if (!distribute_irqs)
return default_server;
- if (cpus_equal(cpumask, CPU_MASK_ALL)) {
- server = default_distrib_server;
- } else {
+ if (!cpus_equal(cpumask, CPU_MASK_ALL)) {
cpus_and(tmp, cpu_online_map, cpumask);
- if (cpus_empty(tmp))
- server = default_distrib_server;
- else
- server = get_hard_smp_processor_id(first_cpu(tmp));
+ server = first_cpu(tmp);
+
+ if (server < NR_CPUS)
+ return get_hard_smp_processor_id(server);
+
+ if (strict_check)
+ return -1;
}
- return server;
+ if (cpus_equal(cpu_online_map, cpu_present_map))
+ return default_distrib_server;
+ return default_server;
}
#else
-static int get_irq_server(unsigned int virq)
+static int get_irq_server(unsigned int virq, unsigned int strict_check)
{
return default_server;
}
@@ -192,7 +195,7 @@ static void xics_unmask_irq(unsigned int
{
unsigned int irq;
int call_status;
- unsigned int server;
+ int server;
pr_debug("xics: unmask virq %d\n", virq);
@@ -201,7 +204,7 @@ static void xics_unmask_irq(unsigned int
if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
return;
- server = get_irq_server(virq);
+ server = get_irq_server(virq, 0);
call_status = rtas_call(ibm_set_xive, 3, 1, NULL, irq, server,
DEFAULT_PRIORITY);
@@ -398,8 +401,7 @@ static void xics_set_affinity(unsigned i
unsigned int irq;
int status;
int xics_status[2];
- unsigned long newmask;
- cpumask_t tmp = CPU_MASK_NONE;
+ int irq_server;
irq = (unsigned int)irq_map[virq].hwirq;
if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
@@ -413,18 +415,21 @@ static void xics_set_affinity(unsigned i
return;
}
- /* For the moment only implement delivery to all cpus or one cpu */
- if (cpus_equal(cpumask, CPU_MASK_ALL)) {
- newmask = default_distrib_server;
- } else {
- cpus_and(tmp, cpu_online_map, cpumask);
- if (cpus_empty(tmp))
- return;
- newmask = get_hard_smp_processor_id(first_cpu(tmp));
+ /*
+ * For the moment only implement delivery to all cpus or one cpu.
+ * Get current irq_server for the given irq
+ */
+ irq_server = get_irq_server(irq, 1);
+ if (irq_server == -1) {
+ char cpulist[128];
+ cpulist_scnprintf(cpulist, sizeof(cpulist), cpumask);
+ printk(KERN_WARNING "xics_set_affinity: No online cpus in "
+ "the mask %s for irq %d\n", cpulist, virq);
+ return;
}
status = rtas_call(ibm_set_xive, 3, 1, NULL,
- irq, newmask, xics_status[1]);
+ irq, irq_server, xics_status[1]);
if (status) {
printk(KERN_ERR "xics_set_affinity: irq=%u ibm,set-xive "
^ permalink raw reply
* Re: [patch 07/18] PS3: Make ps3av.h usable from user space
From: Geert Uytterhoeven @ 2007-06-06 11:27 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, Paul Mackerras, Masashi Kimoto
In-Reply-To: <20070606074609.GA31975@lst.de>
On Wed, 6 Jun 2007, Christoph Hellwig wrote:
> On Tue, Jun 05, 2007 at 08:00:07PM -0700, Geoff Levand wrote:
> > The user applications to manage the PS3 AV modes can use values
> > defined in this header.
>
> NACK. First please don't introduce new unifdef-y headers but always
> separated them. Second I don't see any of the values actually used
> in a user<->kerne interface. If the application only happens to use
> the same values it should ship a copy of the header intead.
ps3videomode (from ps3-utils,
git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-utils.git) uses the
PS3AV_MODE_* definitions for the PS3FB_IOCTL_[SG]ETMODE ioctls on /dev/fb0.
But it indeed just uses a few values, and ps3videomode.c already handles the
case were <asm/ps3av.h> is not available, so I guess we can drop the export.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* Re: 83xx GPIO/EXT int in arch/powerpc/
From: Segher Boessenkool @ 2007-06-06 9:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1181113438.31677.234.camel@localhost.localdomain>
> In addition, linux always reserve numbers 0...15. 0 is
> always illegal and 1..15 can only be mapped to a 8259 type legacy ISA
> controller. This is to avoid problem with stupid drivers from the x86
> world.
Of course, it doesn't help if you have an i8259 but have
non-legacy-PC devices on it. Oh the horror!
> Now, there is no automagic way of setting up GPIOs. You have to
> manually
> (from your firmware that is, or maybe from your platform code),
> configure the appropriate GPIO to the appropriate HW irq source on the
> IPIC that matches what you put in your DTS.
It *really* shouldn't be Linux platform code, if you can
avoid it at all. It's just more trouble than it's worth.
> - You can create a device-node for the PCI device. PCI devices
> normally, in linux, don't need to have device-nodes in the DTS, at
> least
> it's not mandatory, but you -can- do it. If your node has the correct
> "reg" property,
What is "correct" in this case? We probably should describe
what properties are required in a (non-phb) pci node for
platforms that don't use the device tree for probing PCI.
In this specific case, do you only need the configuration
address in the "reg"?
> it should be matches by the linux parser, and thus you
> have the ability to put an interrupts property in there. It would
> normally be a PCI interrupt specification, but you can specify
> explicitely an interrupt parent that points to the IPIC and thus have
> an
> interrupt pointing directly there. That's the example that, I think,
> Andy gave you
Yeah.
> - You can do it in your interrupt-map. That's probably the cleanest
> way
> to do it.
Not really. If the device interrupt is physically connected
directly to a GPIO or a PIC or whatever, if it doesn't go
through the PCI bus; then it shouldn't be represented in
the device tree as if it did. The higher-up bridge has
nothing whatsoever to do with this device's interrupt.
It's a simple hack of course, it can be useful sometimes.
It's not "clean" at all however.
> Just make sure you have
> an entry there for your device pin A dev/fn whose specification points
> to the IPIC with the appropriate IRQ number and that should work fine.
Depending on the rest of the tree, this would often mean
you have to do a much bigger interrupt-map-mask than
without this hack, and the corresponding explosion in
interrupt-map size.
> Now, that's assuming GPIOs, when used as external interrupts, are
> directly routed to the IPIC. I don't know the 83xx so I just assumed
> it :-)
Almost always that's how it works yeah. And the "GPIO"
stage isn't normally represented in the device tree, GPIO
settings are considered a part of the PCB layout ;-) (one
more reason why Linux shouldn't have to touch it).
> If that's not the case, you may need some intermediary cascaded
> interrupt controller or something around those lines.
Yeah, but that's just the more general case of the
general case :-)
Segher
^ permalink raw reply
* MPC8272 LPT support
From: Kruit, Chris van der [FINT] @ 2007-06-06 9:35 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]
Hi,
I'm new to Linux and PowerPC.
Last days I did some research to find out if we could use a specific
board for our new project. I found a board with a MPC8272 processor; it
got all the IO we need, except for a LPT port that we use now for
driving a HD44780 based display.
Now the MPC8272 has a lot free GPIO pins which can be used for driving
the HD44780 controller.
Now my question is if there are drivers for these GPIO pins and if there
is a way too emulate a parallel port on GPIO pins.
Thanks in advanced.
Regards,
Chris
[-- Attachment #2: Type: text/html, Size: 3711 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix interrupt distribution in ppc970
From: Milton Miller @ 2007-06-06 9:43 UTC (permalink / raw)
To: mohan; +Cc: ppcdev, kexec, Paul Mackerras
In-Reply-To: <20070604105455.GA4916@in.ibm.com>
On Jun 4, 2007, at 5:54 AM, Mohan Kumar M wrote:
> Milton,
>
> How about this patch?
I'd make a few minor changes (see below), but I'll ack it.
I've checked it compiles and boots but not the server selection.
> =============================================================
> In some of the PPC970 based systems, interrupt would be distributed to
> offline cpus also even when booted with "maxcpus=1". So check whether
> cpu online map and cpu present map are equal or not. If they are equal
> default_distrib_server is used as interrupt server otherwise boot cpu
> (default_server) used as interrupt server.
>
> In addition to this, if an interrupt is assigned to a specific cpu (ie
> smp affinity) and if that cpu is not online, the earlier code used to
> return the default_distrib_server as interrupt server. This patch
> introduces an additional paramter to the get_irq function ie
> strict_check, based on this parameter, if the cpu is not online either
> default_distrib_server or -1 is returned.
>
> Cc: Milton Miller <miltonm@bga.com>,
> Michael Ellerman <michael@ellerman.id.au>
> Signed-off-by: Mohan Kumar M <mohan@in.ibm.com>
Acked-By: Milton Miller <miltonm@bga.com>
> @@ -166,22 +166,24 @@ static int get_irq_server(unsigned int v
> if (!distribute_irqs)
> return default_server;
>
> - if (cpus_equal(cpumask, CPU_MASK_ALL)) {
> - server = default_distrib_server;
> - } else {
> + if (!cpus_equal(cpumask, CPU_MASK_ALL)) {
> cpus_and(tmp, cpu_online_map, cpumask);
>
> - if (cpus_empty(tmp))
> - server = default_distrib_server;
> - else
> - server = get_hard_smp_processor_id(first_cpu(tmp));
> - }
> + server = first_cpu(tmp);
>
> - return server;
> + if (server < NR_CPUS)
> + return get_hard_smp_processor_id(server);
> + else if (strict_check)
> + return -1;
The indent on the return is 1 tab too many.
See next comment.
> + }
>
> + if (cpus_equal(cpu_online_map, cpu_present_map))
> + return default_distrib_server;
> + else
> + return default_server;
I'd actually remove both occurrences of "else" bringing this and the
previous return back a tabstop. The else is unnecessary because the if
statement is return . (Seperate the new if from the previous with a
blank line in both cases).
> }
> #else
> -static int get_irq_server(unsigned int virq)
> +static int get_irq_server(unsigned int virq, unsigned int
> strict_check)
> {
> return default_server;
> }
^ permalink raw reply
* RE: [PATCH] of_serial: ignore unknown serial port
From: kouish @ 2007-06-06 9:28 UTC (permalink / raw)
To: 'Paul Mackerras'; +Cc: linuxppc-dev, segher, arnd
In-Reply-To: <18022.19709.50452.30370@cargo.ozlabs.ibm.com>
> Ishizaki Kou writes:
>
> > Current of_serial driver assumes unknown serial port to be 8250. But
> > this behavior may cause fatal problems when the serial port is not
> > 8250. This patch corrects probe routine to ignore unknown
> serial port.
> >
> > Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
> > Cc: Arnd Bergmann <arnd@arndb.de>
>
> Is this a bugfix that needs to go in 2.6.22? Likewise, is your next
> patch (of_serial: add port type checking) needed in 2.6.22?
>
> Paul.
Paul-san,
Thank you to ask me about our patches to of_serial driver.
We need the 'ignore unknown serial port' patch in 2.6.22 because
assuming an unknown port as 8250 may cause fatal problems on Celleb
with our new device tree which has 'serial' type device nodes. These
serial ports are not 8250.
On the other hand, we have no problem even if the 'of_serial: add port
type checking' patch will be merged in 2.6.23.
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [PATCH] Create a dummy zImage if no valid platform has been selected.
From: Segher Boessenkool @ 2007-06-06 9:27 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev
In-Reply-To: <20070606070115.GW15955@bakeyournoodle.com>
> +$(obj)/zImage.strip: vmlinux
> + $(STRIP) -s -R .comment $< -o $@
Bad name, you are not creating a stripped zImage, but
a stripped vmlinux.
> +# If we don't have a platform selected then just strip the vmlinux.
Why do anything at all when no platform is selected?
> +ifeq ("$(image-y)", "")
No quotes needed, standard style is
ifeq (,$(image-y))
> +image-y := zImage.strip
> +endif
> +
> $(obj)/zImage: $(addprefix $(obj)/, $(image-y))
> @rm -f $@; ln $< $@
Perhaps the minimal change (this is a degenerated case
anyway) would be to make this command non-failing? Or
maybe that's not desired for "normal" builds? Hard to
see how it ever could go wrong then, but that's wishful
thinking. Maybe ln -sf would be best, it would just
create a dangling softlink in the allno case (and remove
the need for the rm command, too).
What do y'all think?
Segher
^ permalink raw reply
* memory issue on ppc
From: Sekhar Pedamallu @ 2007-06-06 8:41 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]
Hi Guyz!
I m working on powerpc and new to linux . wrote a small program
where I allocate memory for 100, 1000 ,10000 bytes and memset them to zero .
when I allocate to more than 8108 bytes and memset to zero it fails . but
when I memset to any other ASCII value it passes . can u help me out as I m
stuck with it for a long time . is there any problem with the library ?
Thanks & Regards ,
Sekhar Pedamallu
http://www.patni.com
World-Wide Partnerships. World-Class Solutions.
_____________________________________________________________________
This e-mail message may contain proprietary, confidential or legally
privileged information for the sole use of the person or entity to
whom this message was originally addressed. Any review, e-transmission
dissemination or other use of or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. If you have received this e-mail in error
kindly delete this e-mail from your records. If it appears that this
mail has been forwarded to you without proper authority, please notify
us immediately at netadmin@patni.com and delete this mail.
_____________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 3573 bytes --]
^ permalink raw reply
* Re: [PATCH] of_serial: ignore unknown serial port
From: Segher Boessenkool @ 2007-06-06 9:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, arnd
In-Reply-To: <18022.19709.50452.30370@cargo.ozlabs.ibm.com>
>> Current of_serial driver assumes unknown serial port to be 8250. But
>> this behavior may cause fatal problems when the serial port is not
>> 8250. This patch corrects probe routine to ignore unknown serial port.
>>
>> Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>
> Is this a bugfix that needs to go in 2.6.22?
This potentially breaks lots of other platforms, so no
please, put it in early in the next cycle and give those
others time to recover from this change.
Segher
^ permalink raw reply
* Re: [patch 07/18] PS3: Make ps3av.h usable from user space
From: Christoph Hellwig @ 2007-06-06 7:46 UTC (permalink / raw)
To: Geoff Levand
Cc: Geert Uytterhoeven, linuxppc-dev, Paul Mackerras, Masashi Kimoto
In-Reply-To: <46662337.9060908@am.sony.com>
On Tue, Jun 05, 2007 at 08:00:07PM -0700, Geoff Levand wrote:
> The user applications to manage the PS3 AV modes can use values
> defined in this header.
NACK. First please don't introduce new unifdef-y headers but always
separated them. Second I don't see any of the values actually used
in a user<->kerne interface. If the application only happens to use
the same values it should ship a copy of the header intead.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox