* Re: [PATCH v6] spi: Add PPC4xx SPI driver
From: David Brownell @ 2009-04-22 20:00 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <1231411250-25380-1-git-send-email-sr@denx.de>
On Thursday 08 January 2009, Stefan Roese wrote:
> This adds a SPI driver for the SPI controller found in the IBM/AMCC
> 4xx PowerPC's.
> +/*
> + * The PPC4xx SPI controller has no FIFO so each sent/received byte will
> + * generate an interrupt to the CPU. This can cause high CPU utilization.
> + * This driver allows platforms to reduce the interrupt load on the CPU
> + * during SPI transfers by setting max_speed_hz via the device tree.
Note that an alternate strategy is to use polling instead of IRQs,
at least when the data rate is high enough that the IRQ processing
is also slowing down the data transfers.
> +/* bits in mode register - bit 0 ist MSb */
> +/* data latched on leading edge of clock, else trailing edge */
> +#define SPI_PPC4XX_MODE_SCP (0x80 >> 3)
Or in short, SCP == CPHA.
> +/* port enabled */
> +#define SPI_PPC4XX_MODE_SPE (0x80 >> 4)
> +/* MSB first, else LSB first */
> +#define SPI_PPC4XX_MODE_RD (0x80 >> 5)
> +/* clock invert - idle clock = 1, active clock = 0; else reversed */
> +#define SPI_PPC4XX_MODE_CI (0x80 >> 6)
Or in short, CI == CPOL.
> +/* loopback enable */
> +#define SPI_PPC4XX_MODE_IL (0x80 >> 7)
> +/* bits in control register */
> +/* starts a transfer when set */
> +#define SPI_PPC4XX_CR_STR (0x80 >> 7)
> +/* bits in status register */
> +/* port is busy with a transfer */
> +#define SPI_PPC4XX_SR_BSY (0x80 >> 6)
> +/* RxD ready */
> +#define SPI_PPC4XX_SR_RBR (0x80 >> 7)
> +
> +/* the spi->mode bits understood by this driver: */
> +#define MODEBITS (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST)
> +
> +/* clock settings (SCP and CI) for various SPI modes */
> +#define SPI_CLK_MODE0 SPI_PPC4XX_MODE_SCP
> +#define SPI_CLK_MODE1 0
> +#define SPI_CLK_MODE2 SPI_PPC4XX_MODE_CI
> +#define SPI_CLK_MODE3 (SPI_PPC4XX_MODE_SCP | SPI_PPC4XX_MODE_CI)
Color me puzzled then. Either the definitions of MODE0 and MODE1
are swapped here ... or the comments above are wrong, and SCP should
describe "falling" vs "rising" instead of "leading" vs "trailing".
> +static int spi_ppc4xx_setupxfer(struct spi_device *spi, struct spi_transfer *t)
> +{
> + struct ppc4xx_spi *hw = spi_master_get_devdata(spi->master);
> + struct spi_ppc4xx_cs *cs = spi->controller_state;
> + int scr;
> + u8 cdm = 0;
> + u32 speed;
> + u8 bits_per_word;
> +
> + bits_per_word = (t) ? t->bits_per_word : spi->bits_per_word;
> + speed = (t) ? t->speed_hz : spi->max_speed_hz;
> +
> + ...
> +
> + if (!speed || (speed > spi->max_speed_hz)) {
This is wrong. Typical case is that t->speed_hz is zero,
meaning "use spi->max_speed_hz" ... you treat that as an error.
> + dev_err(&spi->dev, "invalid speed_hz (%d)\n", speed);
> + return -EINVAL;
> + }
> +
> + ...
> +}
> +
> +static int spi_ppc4xx_setup(struct spi_device *spi)
> +{
> + int ret;
> + struct spi_ppc4xx_cs *cs = spi->controller_state;
> + int init = 0;
This "init" thing is still wrong.
Consider: board gets set up with one device. Later,
*WHILE BUSY TRANSFERRING DATA TO/FROM THAT DEVICE*
some other device gets instantiated. Then ...
> + if (cs == NULL) {
> + cs = kzalloc(sizeof *cs, GFP_KERNEL);
> + if (!cs)
> + return -ENOMEM;
> + spi->controller_state = cs;
> +
> + /*
> + * First time called, so let's init the SPI controller
> + * at the end of this function
> + */
> + init = 1;
"init" becomes true here, although the controller has
already been initialized. If it needs to be set up,
do it in probe() before registering the spi_master.
> + }
> +
> + ...
> +
> + /*
> + * New configuration (mode, speed etc) will be written to the
> + * controller in spi_ppc4xx_setupxfer(). Only call
> + * spi_ppc4xx_setupxfer() directly upon first initialization.
> + */
> + if (init) {
> + ret = spi_ppc4xx_setupxfer(spi, NULL);
... so blam, you clobber the settings currently being used for
the active transfer. So this would be a bug.
If not ... this driver deserves a comment on exactly how
unusual this driver is. Specifically, that all spi_device
children must be set up *in advance* so that standard calls
like spi_new_device() don't work with it; and why.
I don't think I see anything in this driver which would
prevent that from working, though. Sure you've got to
have a list of chipselect GPIOs in advance, but that's
distinct from being unable to use spi_new_device().
> + ...
> +}
> +
> +static void spi_ppc4xx_chipsel(struct spi_device *spi, int value)
> +{
> + struct ppc4xx_spi *hw = spi_master_get_devdata(spi->master);
> + unsigned int cspol = spi->mode & SPI_CS_HIGH ? 1 : 0;
> + unsigned int cs = spi->chip_select;
> +
> + if (!hw->num_gpios)
> + return;
Hmm, num_gpios ... can never be zero, right? You always
set it up so that of_gpio_count() GPIOs can all be used
as chipselects. Looks like this check is not needed.
> +
> + if (cs >= hw->num_gpios)
> + return;
I guess I don't see why you have num_gpio instead of just
using the chipselect count, either. (Assuming that the
of_gpio_count routine isn't counting *all* gpios, instead
of just ones allocated to this controller, which would be
a different issue.)
> +
> + if (value != BITBANG_CS_INACTIVE && value != BITBANG_CS_ACTIVE)
> + return;
Strange, what other values could be passed??
> +
> + if (value == BITBANG_CS_INACTIVE)
> + cspol = !cspol;
> +
> + gpio_set_value(hw->gpios[cs], cspol);
> +}
> +
> +static irqreturn_t spi_ppc4xx_int(int irq, void *dev_id)
> +{
> + struct ppc4xx_spi *hw;
> + u8 status;
> + u8 data;
> + unsigned int count;
> +
> + hw = (struct ppc4xx_spi *)dev_id;
> +
> + status = in_8(&hw->regs->sr);
> + if (!status)
> + return IRQ_NONE;
> +
> + /* should never happen but check anyway */
> + if (status & SPI_PPC4XX_SR_BSY) {
Maybe "if (unlikely(...)) {" then.
> + u8 lstatus;
> + int cnt = 0;
> +
> + dev_dbg(hw->dev, "got interrupt but spi still busy?\n");
But ... *does* this ever happen? If not, I'd strike this
code. And if it does, I'd add a comment explaining what's
known about this hardware bug. Without this, the IRQ handler
would look pretty tight.
> + do {
> + ndelay(10);
> + lstatus = in_8(&hw->regs->sr);
> + } while (++cnt < 100 && lstatus & SPI_PPC4XX_SR_BSY);
> +
> + if (cnt >= 100) {
> + dev_err(hw->dev, "busywait: too many loops!\n");
> + complete(&hw->done);
> + return IRQ_HANDLED;
> + } else {
> + /* status is always 1 (RBR) here */
> + status = in_8(&hw->regs->sr);
> + dev_dbg(hw->dev, "loops %d status %x\n", cnt, status);
> + }
> + }
> +
> + count = hw->count;
> + hw->count++;
> +
> + if (status & SPI_PPC4XX_SR_RBR) {
> + /* Data Ready */
Most SPI hardware I've seen has at most a weak distinction
between "tx done" and "rx done" IRQs ... there's little
point to separate IRQs, since shifting out the last TX bit
is what shifts in the last RX bit.
Unless this is unusual hardware you can probably just assume
that there's RX data, and only read it if hw->rx is non-null.
Or, if this is *not* set, report the odd behavior...
> + data = in_8(&hw->regs->rxd);
> + if (hw->rx)
> + hw->rx[count] = data;
> + }
> +
> + count++;
> +
> + if (count < hw->len) {
> + data = hw->tx ? hw->tx[count] : 0;
> + out_8(&hw->regs->txd, data);
> + out_8(&hw->regs->cr, SPI_PPC4XX_CR_STR);
> + } else {
> + complete(&hw->done);
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
> + ...
> +
> +static int __init spi_ppc4xx_of_probe(struct of_device *op,
> + const struct of_device_id *match)
> +{
> + struct ppc4xx_spi *hw;
> + struct spi_master *master;
> + struct spi_bitbang *bbp;
> + struct resource resource;
> + struct device_node *np = op->node;
> + struct device *dev = &op->dev;
> + struct device_node *opbnp;
> + int ret;
> + const unsigned int *clk;
> +
> + master = spi_alloc_master(dev, sizeof *hw);
> + if (master == NULL)
> + return -ENOMEM;
> + dev_set_drvdata(dev, master);
> + hw = spi_master_get_devdata(master);
> + memset(hw, 0, sizeof(struct ppc4xx_spi));
That memset is not required, it comes to you pre-zeroed.
> +
> + hw->master = spi_master_get(master);
> + hw->dev = dev;
> +
> + init_completion(&hw->done);
> +
> + hw->num_gpios = of_gpio_count(np);
Worth a comment what's going on there. I'm assuming this
of_gpio_count() thing returns a count of GPIOs somehow
associated with this specific device tree node, rather than
say all GPIOs known to the device tree...
> + if (hw->num_gpios) {
> + int i;
> +
> + hw->gpios = kzalloc(sizeof(int) * hw->num_gpios,
> + GFP_KERNEL);
> + if (!hw->gpios) {
> + ret = -ENOMEM;
> + goto free_master;
> + }
> +
> + for (i = 0; i < hw->num_gpios; i++) {
> + int gpio = of_get_gpio(np, i);
> + if (gpio < 0) {
> + dev_err(dev, "Invalid gpio spec %d\n", i);
> + ret = gpio;
> + goto free_gpios;
> + }
> +
> + ret = gpio_request(gpio, np->name);
> + if (ret < 0) {
> + dev_err(dev, "gpio %d already in use\n", i);
> + ret = gpio;
> + goto free_gpios;
> + }
> +
> + gpio_direction_output(gpio, 0);
> + hw->gpios[i] = gpio;
> + }
> + }
Else ... error, if there are no chipselects?
I've got a patch pending to add a "no chipselect" spi->mode flag.
If you expect to support that, please let me know.
> +
> + /* Setup the state for the bitbang driver */
> + bbp = &hw->bitbang;
> + bbp->master = hw->master;
> + bbp->setup_transfer = spi_ppc4xx_setupxfer;
> + bbp->chipselect = spi_ppc4xx_chipsel;
> + bbp->txrx_bufs = spi_ppc4xx_txrx;
> + bbp->use_dma = 0;
> + bbp->master->setup = spi_ppc4xx_setup;
> + bbp->master->cleanup = spi_ppc4xx_cleanup;
> + /* only one SPI controller */
> + bbp->master->bus_num = 0;
Bad assumption. There could be GPIO-based adapters,
of course. And aren't these the cores which can be
found on higher end Xilinx FPGAs? And, accordingly,
integrated with any number of additional controllers?
If so, the restriction is just that this controller
be bus #0. If not ... the Kconfig should say more
about *which* PPC4xx chips have this controller.
(I suspect it's the latter.)
> + if (bbp->master->num_chipselect == 0) {
You didn't set it, so of course it's still zeroed.
> + /* this many pins in al GPIO controllers */
> + bbp->master->num_chipselect = hw->num_gpios;
So num_chipselect is alays num_gpios, and there's no point
to having num_gpios since you could always use num_chipselect.
> + }
> +
> + ...
> +}
^ permalink raw reply
* Re: removing get_immrbase()??
From: Kumar Gala @ 2009-04-22 20:00 UTC (permalink / raw)
To: Scott Wood; +Cc: Linuxppc-dev Development
In-Reply-To: <49EF7394.30606@freescale.com>
On Apr 22, 2009, at 2:44 PM, Scott Wood wrote:
>> CPM/QE related users.
>> arch/powerpc/include/asm/cpm1.h:#define IMAP_ADDR
>> (get_immrbase())
>> only used drivers/net/fs_enet/fs_enet-main.c which seems evil.
>
> That driver *is* evil. :-)
>
> It looks like the only remaining user of fs_enet_immap (which is
> what IMAP_ADDR is used to initialize) is in mac-fec.c, under
> CONFIG_DUET -- which hasn't been touched since 2005 and appears to
> have died with arch/ppc.
>
> I'm fine with removing it -- it probably no longer compiles anyway.
I'll send DaveM a bit to kill it off.
- k
^ permalink raw reply
* Re: removing get_immrbase()??
From: Scott Wood @ 2009-04-22 19:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development
In-Reply-To: <A6732FD8-FBC6-420F-9318-CC111D266993@kernel.crashing.org>
Kumar Gala wrote:
> I'm not sure if we can actually get away with completely removing
> get_immrbase() but I figured I'd give everyone something to flame me
> about. The current users are:
I think we want to keep it for an eventual re-introduction of a large
TLB entry to cover IMMR (but no longer at a fixed virtual address, of
course).
> CPM/QE related users.
>
> arch/powerpc/include/asm/cpm1.h:#define IMAP_ADDR (get_immrbase())
>
> only used drivers/net/fs_enet/fs_enet-main.c which seems evil.
That driver *is* evil. :-)
It looks like the only remaining user of fs_enet_immap (which is what
IMAP_ADDR is used to initialize) is in mac-fec.c, under CONFIG_DUET --
which hasn't been touched since 2005 and appears to have died with arch/ppc.
I'm fine with removing it -- it probably no longer compiles anyway.
> arch/powerpc/sysdev/cpm1.c: mpc8xx_immr = ioremap(get_immrbase(),
> 0x4000);
> not sure? ideas?
This is used for accessing a variety of registers, not all of which are
currently expressed in the device tree.
> arch/powerpc/include/asm/cpm2.h:#define CPM_MAP_ADDR (get_immrbase() +
> 0x80000)
> arch/powerpc/sysdev/cpm2.c: cpm2_immr = ioremap(get_immrbase(),
> CPM_MAP_SIZE);
> these two are related and seem like we could look for "fsl,cpm2"
And do what with it that wouldn't be a reimplementation of get_immrbase()?
> arch/powerpc/platforms/83xx/suspend.c: rcw_regs =
> ioremap(get_immrbase() + IMMR_RCW_OFFSET,
> arch/powerpc/platforms/83xx/suspend.c: immrbase = get_immrbase();
The suspend code touches a variety of SOC registers in various blocks --
likely including some which are not described by any device node at present.
-Scott
^ permalink raw reply
* Re: removing get_immrbase()??
From: Timur Tabi @ 2009-04-22 19:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development
In-Reply-To: <A6732FD8-FBC6-420F-9318-CC111D266993@kernel.crashing.org>
On Wed, Apr 22, 2009 at 1:38 PM, Kumar Gala <galak@kernel.crashing.org> wro=
te:
> I'm not sure if we can actually get away with completely removing
> get_immrbase() but I figured I'd give everyone something to flame me abou=
t.
> =A0The current users are:
>
> CPM/QE related users.
I'm okay with doing this for QE, but I don't see it used in any QE code.
> arch/powerpc/include/asm/cpm2.h:#define CPM_MAP_ADDR (get_immrbase() +
> 0x80000)
> arch/powerpc/sysdev/cpm2.c: =A0 =A0 cpm2_immr =3D ioremap(get_immrbase(),
> CPM_MAP_SIZE);
> =A0 =A0 =A0 =A0these two are related and seem like we could look for "fsl=
,cpm2"
That's okay, as long as you don't break compatibility with older
device trees that don't have that property, unless you can demonstrate
that these trees would never work with the current kernel anyway.
I think this is a good idea, but it looks like we'll need to define a
whole bunch of new structures to replace all of the "+ offset" usages.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: ofpart: Partitions at same address cannot have the same name
From: Ricardo Ribalda Delgado @ 2009-04-22 18:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, David.Woodhouse
In-Reply-To: <49EF5DDF.8050208@freescale.com>
Hello Scott
It is definitively more elegant...
Let me send tomorrow a patch
On Wed, Apr 22, 2009 at 20:11, Scott Wood <scottwood@freescale.com> wrote:
> Ricardo Ribalda Delgado wrote:
>>
>> Hi Scott
>>
>>> Perhaps "compatible" should be used instead?
>>
>> What do you mean?
>>
>> if (strcmp(partname, "partition") || strcmp(partname, "compatible") )
>>
>> I can't see the advantages.
>
> No, I mean:
>
> foo {
> =A0 =A0 =A0 =A0compatible =3D "partition";
> =A0 =A0 =A0 =A0...
> };
>
> -Scott
>
--=20
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
^ permalink raw reply
* [PATCH] powerpc/cpm: Remove some cruft code and defines
From: Kumar Gala @ 2009-04-22 18:45 UTC (permalink / raw)
To: linuxppc-dev
Kill of some old defines and macros that we no longer use like
CPM_MAP_ADDR and CPM_IRQ_OFFSET.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/cpm2.h | 4 ----
arch/powerpc/platforms/82xx/pq2ads.h | 13 -------------
arch/powerpc/platforms/8xx/mpc885ads.h | 4 ----
arch/powerpc/sysdev/cpm2.c | 2 +-
4 files changed, 1 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/cpm2.h b/arch/powerpc/include/asm/cpm2.h
index 0f5e8ff..990ff19 100644
--- a/arch/powerpc/include/asm/cpm2.h
+++ b/arch/powerpc/include/asm/cpm2.h
@@ -14,10 +14,6 @@
#include <asm/cpm.h>
#include <sysdev/fsl_soc.h>
-#ifdef CONFIG_PPC_85xx
-#define CPM_MAP_ADDR (get_immrbase() + 0x80000)
-#endif
-
/* CPM Command register.
*/
#define CPM_CR_RST ((uint)0x80000000)
diff --git a/arch/powerpc/platforms/82xx/pq2ads.h b/arch/powerpc/platforms/82xx/pq2ads.h
index 984db42..6cf0f97 100644
--- a/arch/powerpc/platforms/82xx/pq2ads.h
+++ b/arch/powerpc/platforms/82xx/pq2ads.h
@@ -24,10 +24,6 @@
#include <linux/seq_file.h>
-/* Backword-compatibility stuff for the drivers */
-#define CPM_MAP_ADDR ((uint)0xf0000000)
-#define CPM_IRQ_OFFSET 0
-
/* The ADS8260 has 16, 32-bit wide control/status registers, accessed
* only on word boundaries.
* Not all are used (yet), or are interesting to us (yet).
@@ -44,14 +40,5 @@
#define BCSR3_FETHIEN2 ((uint)0x10000000) /* 0 == enable*/
#define BCSR3_FETH2_RST ((uint)0x80000000) /* 0 == reset */
-/* cpm serial driver works with constants below */
-
-#define SIU_INT_SMC1 ((uint)0x04+CPM_IRQ_OFFSET)
-#define SIU_INT_SMC2 ((uint)0x05+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC1 ((uint)0x28+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC2 ((uint)0x29+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC3 ((uint)0x2a+CPM_IRQ_OFFSET)
-#define SIU_INT_SCC4 ((uint)0x2b+CPM_IRQ_OFFSET)
-
#endif /* __MACH_ADS8260_DEFS */
#endif /* __KERNEL__ */
diff --git a/arch/powerpc/platforms/8xx/mpc885ads.h b/arch/powerpc/platforms/8xx/mpc885ads.h
index a507666..19412f7 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads.h
+++ b/arch/powerpc/platforms/8xx/mpc885ads.h
@@ -17,10 +17,6 @@
#include <sysdev/fsl_soc.h>
-#define MPC8xx_CPM_OFFSET (0x9c0)
-#define CPM_MAP_ADDR (get_immrbase() + MPC8xx_CPM_OFFSET)
-#define CPM_IRQ_OFFSET 16 // for compability with cpm_uart driver
-
/* Bits of interest in the BCSRs.
*/
#define BCSR1_ETHEN ((uint)0x20000000)
diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
index fd969f0..eb59272 100644
--- a/arch/powerpc/sysdev/cpm2.c
+++ b/arch/powerpc/sysdev/cpm2.c
@@ -61,7 +61,7 @@ EXPORT_SYMBOL(cpm2_immr);
void __init cpm2_reset(void)
{
#ifdef CONFIG_PPC_85xx
- cpm2_immr = ioremap(CPM_MAP_ADDR, CPM_MAP_SIZE);
+ cpm2_immr = ioremap(get_immrbase() + 0x80000, CPM_MAP_SIZE);
#else
cpm2_immr = ioremap(get_immrbase(), CPM_MAP_SIZE);
#endif
--
1.6.0.6
^ permalink raw reply related
* removing get_immrbase()??
From: Kumar Gala @ 2009-04-22 18:38 UTC (permalink / raw)
To: Linuxppc-dev Development
I'm not sure if we can actually get away with completely removing
get_immrbase() but I figured I'd give everyone something to flame me
about. The current users are:
CPM/QE related users.
arch/powerpc/include/asm/cpm1.h:#define IMAP_ADDR (get_immrbase())
only used drivers/net/fs_enet/fs_enet-main.c which seems evil.
arch/powerpc/platforms/8xx/mpc885ads.h:#define CPM_MAP_ADDR
(get_immrbase() + MPC8xx_CPM_OFFSET)
not used
arch/powerpc/sysdev/cpm1.c: mpc8xx_immr = ioremap(get_immrbase(),
0x4000);
not sure? ideas?
arch/powerpc/include/asm/cpm2.h:#define CPM_MAP_ADDR (get_immrbase() +
0x80000)
arch/powerpc/sysdev/cpm2.c: cpm2_immr = ioremap(get_immrbase(),
CPM_MAP_SIZE);
these two are related and seem like we could look for "fsl,cpm2"
arch/powerpc/platforms/83xx/misc.c: restart_reg_base =
ioremap(get_immrbase() + 0x900, 0xff);
arch/powerpc/platforms/83xx/misc.c: __be32 __iomem *spcr =
ioremap(get_immrbase() + SPCR_OFFSET, 4);
arch/powerpc/platforms/83xx/mpc836x_mds.c: immap =
ioremap(get_immrbase() + 0x14a8, 8);
arch/powerpc/platforms/83xx/suspend.c: rcw_regs =
ioremap(get_immrbase() + IMMR_RCW_OFFSET,
arch/powerpc/platforms/83xx/suspend.c: immrbase = get_immrbase();
arch/powerpc/platforms/83xx/usb.c: immap = ioremap(get_immrbase(),
0x1000);
arch/powerpc/platforms/83xx/usb.c: immap = ioremap(get_immrbase(),
0x1000);
arch/powerpc/platforms/83xx/usb.c: immap = ioremap(get_immrbase(),
0x1000);
83xx cruft -- needs more investigation:
arch/powerpc/platforms/86xx/mpc8610_hpcd.c: clkdvdr =
ioremap(get_immrbase() + 0xe0800, sizeof(u32));
arch/powerpc/platforms/86xx/mpc86xx_smp.c: mcm_vaddr =
ioremap(get_immrbase() + MPC86xx_MCM_OFFSET,
86xx: the first can be fixed to use guts, the second can be fixed to
use the new "fsl,mcm" that I proposed:
arch/powerpc/sysdev/fsl_pci.c: immr_base = get_immrbase();
This one is a bit more problematic but can use the new "fsl,mcm-law",
"fsl,ecm-law"
- k
^ permalink raw reply
* Re: ofpart: Partitions at same address cannot have the same name
From: Benjamin Krill @ 2009-04-22 18:33 UTC (permalink / raw)
To: Ricardo Ribalda Delgado; +Cc: David.Woodhouse, linuxppc-dev
In-Reply-To: <aa76a2be0904221059h59f3bea5w18f9a7f40c3e9551@mail.gmail.com>
* Ricardo Ribalda Delgado | 2009-04-22 19:59:08 [+0200]:
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (strcmp(partna=
me, "partition") <=3D 0) {
>
>Anything alfabetically higher than partition (like "zzzzz" will pass
>the test :S)
You are totally right!
cheers
ben
^ permalink raw reply
* Re: [PATCH v3] powerpc/85xx: Add P2020DS board support
From: Kumar Gala @ 2009-04-22 18:23 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <49EF5EFE.2040608@freescale.com>
On Apr 22, 2009, at 1:16 PM, Scott Wood wrote:
> Kumar Gala wrote:
>>> What "we care about" at this point is irrelevant, given the PITA
>>> it would be to change the device trees (or u-boot) that are
>>> already in use once we do begin to care.
>> Which is exactly why I didn't put it in the .dts right now.
>
> ???
>
>> Today we know NO code exists that cares about "fsl,elbc-1.2". Once
>> someone adds such code they can also update the .dts to match it.
>
> DTS files and firmware are *MUCH* harder to update once they're out
> there than the kernel. Why such opposition to using an appropriate
> compatible?
Because I want to avoid make the decision right now. We are on rev1.x
silicon and I want to avoid greatly having to spawn a new .dts just
for "fsl,elbc-1.2.1" that has some errata fix in it. If dtc was
smarter and I had less duplication between the 40-50 .dts we have for
our various parts I wouldn't care that match.
> Is there anything in the p2020ds u-boot patches to set the elbc
> version, or was that just a brush-off?
I was hoping that Poonam would look at doing that, but there isn't
anything right now.
I can put out some code for u-boot to address the specific elbc issue
if that will resolve this.
- k
^ permalink raw reply
* [PATCH] powerpc/fsl: use of_iomap() for rstcr mapping
From: Kumar Gala @ 2009-04-22 18:19 UTC (permalink / raw)
To: linuxppc-dev
The rstcr register mapping code was written sometime ago before
of_iomap() existed. We can use it and clean up the code a bit
and get rid of one user of get_immrbase() in the process.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/sysdev/fsl_soc.c | 14 ++++----------
1 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index afe8dbc..bd1b74d 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -425,16 +425,10 @@ static int __init setup_rstcr(void)
struct device_node *np;
np = of_find_node_by_name(NULL, "global-utilities");
if ((np && of_get_property(np, "fsl,has-rstcr", NULL))) {
- const u32 *prop = of_get_property(np, "reg", NULL);
- if (prop) {
- /* map reset control register
- * 0xE00B0 is offset of reset control register
- */
- rstcr = ioremap(get_immrbase() + *prop + 0xB0, 0xff);
- if (!rstcr)
- printk (KERN_EMERG "Error: reset control "
- "register not mapped!\n");
- }
+ rstcr = of_iomap(np, 0) + 0xb0;
+ if (!rstcr)
+ printk (KERN_EMERG "Error: reset control register "
+ "not mapped!\n");
} else
printk (KERN_INFO "rstcr compatible register does not exist!\n");
if (np)
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH v3] powerpc/85xx: Add P2020DS board support
From: Scott Wood @ 2009-04-22 18:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <FA468435-A799-4EB9-8DA1-EC8F3B58EAEB@kernel.crashing.org>
Kumar Gala wrote:
>> What "we care about" at this point is irrelevant, given the PITA it
>> would be to change the device trees (or u-boot) that are already in
>> use once we do begin to care.
>
> Which is exactly why I didn't put it in the .dts right now.
???
> Today we know NO code exists that cares about "fsl,elbc-1.2". Once someone adds
> such code they can also update the .dts to match it.
DTS files and firmware are *MUCH* harder to update once they're out
there than the kernel. Why such opposition to using an appropriate
compatible?
Is there anything in the p2020ds u-boot patches to set the elbc version,
or was that just a brush-off?
-Scott
^ permalink raw reply
* [RFC][PATCH] powerpc/86xx: Add binding for LAWs and MCM
From: Kumar Gala @ 2009-04-22 18:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss
The first 4k region of CCSR space is well defined for local access
windows, CCSRBAR, etc. The second 4k region is well defined as
register for configuring and getting errors for the MPX coherency
module.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Please review. Once we close on this I intend to mimic this for the 85xx based
chips.
- k
Documentation/powerpc/dts-bindings/fsl/mcm.txt | 64 ++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 13 +++++
2 files changed, 77 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/mcm.txt
diff --git a/Documentation/powerpc/dts-bindings/fsl/mcm.txt b/Documentation/powerpc/dts-bindings/fsl/mcm.txt
new file mode 100644
index 0000000..4ceda9b
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/mcm.txt
@@ -0,0 +1,64 @@
+=====================================================================
+MPX LAW & Coherency Module Device Tree Binding
+Copyright (C) 2009 Freescale Semiconductor Inc.
+=====================================================================
+
+Local Access Window (LAW) Node
+
+The LAW node represents the region of CCSR space where local access
+windows are configured. For MCM based devices this is the first 4k
+of CCSR space that includes CCSRBAR, ALTCBAR, ALTCAR, BPTR, and some
+number of local access windows as specified by fsl,num-laws.
+
+PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type: <string>
+ Definition: Must include "fsl,mcm-law"
+
+ - reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property. The value specifies the
+ physical address offset and length of the CCSR space
+ registers.
+
+ - fsl,num-laws
+ Usage: required
+ Value type: <u32>
+ Definition: The value specifies the number of local access
+ windows for this device.
+
+=====================================================================
+
+MPX Coherency Module Node
+
+The MPX LAW node represents the region of CCSR space where MCM config
+and error reporting registers exist, this is the second 4k (0x1000)
+of CCSR space.
+
+PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type: <string>
+ Definition: Must include "fsl,CHIP-mcm", "fsl,mcm" where
+ CHIP is the processor (mpc8641, mpc8610, etc.)
+
+ - reg
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A standard property. The value specifies the
+ physical address offset and length of the CCSR space
+ registers.
+
+ - interrupts
+ Usage: required
+ Value type: <prop-encoded-array>
+
+ - interrupt-parent
+ Usage: required
+ Value type: <phandle>
+
+=====================================================================
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index 51852e6..8bcccd7 100644
--- a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -117,6 +117,19 @@
reg = <0xffe00000 0x00001000>; // CCSRBAR
bus-frequency = <0>;
+ mcm-law@0 {
+ compatible = "fsl,mcm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ mcm@1000 {
+ compatible = "fsl,mpc8641-mcm", "fsl,mcm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <&mpic>;
+ };
+
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH v3] powerpc/85xx: Add P2020DS board support
From: Kumar Gala @ 2009-04-22 18:11 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <49EF560F.90208@freescale.com>
On Apr 22, 2009, at 12:38 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Apr 22, 2009, at 12:16 PM, Scott Wood wrote:
>>> Kumar Gala wrote:
>>>> On Apr 22, 2009, at 12:04 PM, Scott Wood wrote:
>>>>> Kumar Gala wrote:
>>>>>>> If this has an elbc more recent than 1.0 (looks like it), we
>>>>>>> should
>>>>>>> indicate that here.
>>>>>> that might be the case, but I leave it to u-boot to do that.
>>>>>
>>>>> Why? There's no p2020 with an older eLBC, and there's no block
>>>>> version register.
>>>> But there might be a p2020 w/a newer eLBC version in the future.
>>>
>>> At which point we can add something to u-boot -- but magic SVR
>>> tables seem a step backward from the dts except where needed to
>>> avoid the creation of extra dts files.
>> I don't see the value of complicating u-boot
>
> But complicating u-boot is just what you're suggesting. Put it in
> the dts, and u-boot has *zero* code to deal with this unless we find
> ourselves wanting to share the dts with another board rev with a
> newer chip with a newer elbc.
>
>> to have to parse and "fixup" the compatible instead of just having
>> to prepend to it. Especially since I don't believe there is
>> anything specific we care about in the 1.2 version of elbc at this
>> point.
>
> If the new elbc is compatible with the current one, then you will
> still just be prepending. If it is not, then it very likely isn't
> compatible with 1.0 either, so you'll have to remove fsl,elbc anyway.
>
> What "we care about" at this point is irrelevant, given the PITA it
> would be to change the device trees (or u-boot) that are already in
> use once we do begin to care.
Which is exactly why I didn't put it in the .dts right now. Today we
know NO code exists that cares about "fsl,elbc-1.2". Once someone adds
such code they can also update the .dts to match it.
- k
^ permalink raw reply
* Re: ofpart: Partitions at same address cannot have the same name
From: Scott Wood @ 2009-04-22 18:11 UTC (permalink / raw)
To: Ricardo Ribalda Delgado; +Cc: linuxppc-dev, David.Woodhouse
In-Reply-To: <aa76a2be0904221056v7c7357abk52e9b31bb3f7b143@mail.gmail.com>
Ricardo Ribalda Delgado wrote:
> Hi Scott
>
>> Perhaps "compatible" should be used instead?
>
> What do you mean?
>
> if (strcmp(partname, "partition") || strcmp(partname, "compatible") )
>
> I can't see the advantages.
No, I mean:
foo {
compatible = "partition";
...
};
-Scott
^ permalink raw reply
* Re: [OT] Lite5200B w/ nfs root hangs after some time
From: Wolfgang Denk @ 2009-04-22 18:10 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: Linux PPC Development
In-Reply-To: <1240422181.5492.0@antares>
Dear Albrecht =?iso-8859-1?b?RHJl3w==?=,
In message <1240422181.5492.0@antares> you wrote:
>
> this question is maybe off-topic on this list...
This is not off topic (actually, if you had bothered to check the
mailing ist archives before posting, you would have known - because
you would have found previous discussions of this issue, including the
necessary fix).
> I use the Lite5200B board with stock kernel 2.6.29, and boot with the
That's known to show this problem.
> [ 4912.350855] nfs: server 10.16.10.29 not responding, still trying
well known symptom.
> an the the system is *completely* dead, i.e. it doesn't respond to
No, it is NOT completely dead, just extremely slow.
> Any idea what goes wrong here, and how I could fix it?
Apply this patch:
http://patchwork.ozlabs.org/patch/24487/
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
When all is said and done, more is said than done.
^ permalink raw reply
* Re: FPGA IRQ design question
From: Wolfgang Grandegger @ 2009-04-22 18:07 UTC (permalink / raw)
To: Eddie Dawydiuk; +Cc: linuxppc-dev
In-Reply-To: <49EF5C4D.6040402@embeddedarm.com>
Eddie Dawydiuk wrote:
> Grant,
>
>> However, if you're writing one-off custom drivers and there is no
>> common coded needed for acking irqs, then I would probably just use
>> the external IRQ.
>
> Thanks for the suggestions I think going to just use the external IRQ.
> As a result I've been reading through a few different dts files to try
> to understand how/where to specify this in the dts file. I see in the
> Yosemite dts file the PCI bus device node has an interrupt-map-mask and
> an interrupt-map.
>
> e.g.
>
> PCI0: pci@ec000000 {
> device_type = "pci";
> ...
> /* Bamboo has all 4 IRQ pins tied together per slot */
> interrupt-map-mask = <0xf800 0x0 0x0 0x0>;
> interrupt-map = <
> /* IDSEL 1 */
> 0x800 0x0 0x0 0x0 &UIC0 0x1c 0x8
> ...
> };
>
> As far as I can tell this appears to be the proper location to specify
> that the PCI device(FPGA) connects an the IRQ to an external IRQ on the
> AMCC 440EP. I see where the interrupt controller(e.g. &UIC0), the
> interrupt number(0x1C), and the sense(0x8) of the external interrupt is
> specified. But I'm a bit puzzled by some of the other information.
>
> Is this the proper place in the dts file to specify that the FPGA
> connects and external interrupt to the SoC? Can you point me to a
> document explaining the interrupt-map-mask and interrupt-map arguments?
Yes, have a look to
http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf.
Wolfgang.
^ permalink raw reply
* Re: FPGA IRQ design question
From: Eddie Dawydiuk @ 2009-04-22 18:05 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40904220757u1bcf1693oc2329c67209249ac@mail.gmail.com>
Grant,
> However, if you're writing one-off custom drivers and there is no
> common coded needed for acking irqs, then I would probably just use
> the external IRQ.
Thanks for the suggestions I think going to just use the external IRQ. As a
result I've been reading through a few different dts files to try to understand
how/where to specify this in the dts file. I see in the Yosemite dts file the
PCI bus device node has an interrupt-map-mask and an interrupt-map.
e.g.
PCI0: pci@ec000000 {
device_type = "pci";
...
/* Bamboo has all 4 IRQ pins tied together per slot */
interrupt-map-mask = <0xf800 0x0 0x0 0x0>;
interrupt-map = <
/* IDSEL 1 */
0x800 0x0 0x0 0x0 &UIC0 0x1c 0x8
...
};
As far as I can tell this appears to be the proper location to specify that the
PCI device(FPGA) connects an the IRQ to an external IRQ on the AMCC 440EP. I see
where the interrupt controller(e.g. &UIC0), the interrupt number(0x1C), and the
sense(0x8) of the external interrupt is specified. But I'm a bit puzzled by some
of the other information.
Is this the proper place in the dts file to specify that the FPGA connects and
external interrupt to the SoC? Can you point me to a document explaining the
interrupt-map-mask and interrupt-map arguments?
Thanks for any pointers.
--
Best Regards,
________________________________________________________________
Eddie Dawydiuk, Technologic Systems | voice: (480) 837-5200
16525 East Laser Drive | fax: (480) 837-5300
Fountain Hills, AZ 85268 | web: www.embeddedARM.com
^ permalink raw reply
* Re: ofpart: Partitions at same address cannot have the same name
From: Ricardo Ribalda Delgado @ 2009-04-22 17:59 UTC (permalink / raw)
To: Benjamin Krill; +Cc: David.Woodhouse, linuxppc-dev
In-Reply-To: <20090422171030.GH14906@codiert.org>
Hello Benjamin
> Hi Recardo,
>
> I would suggest to do:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (strcmp(partname, "partition") <=3D 0) =
{
Anything alfabetically higher than partition (like "zzzzz" will pass
the test :S)
Regards
>
> cheers
> =A0ben
>
>
--=20
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
^ permalink raw reply
* Re: ofpart: Partitions at same address cannot have the same name
From: Ricardo Ribalda Delgado @ 2009-04-22 17:56 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, David.Woodhouse
In-Reply-To: <49EF5391.9050404@freescale.com>
Hi Scott
> Perhaps "compatible" should be used instead?
What do you mean?
if (strcmp(partname, "partition") || strcmp(partname, "compatible") )
I can't see the advantages.
>
>> Hi Recardo,
>>
>> I would suggest to do:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (strcmp(partname, "partition") <=3D 0)=
{
>
> Check whether it sorts alphabetically before "partition"? =A0Why?
>
> -Scott
>
--=20
Ricardo Ribalda
http://www.eps.uam.es/~rribalda/
^ permalink raw reply
* [OT] Lite5200B w/ nfs root hangs after some time
From: Albrecht Dreß @ 2009-04-22 17:42 UTC (permalink / raw)
To: Linux PPC Development
[-- Attachment #1: Type: text/plain, Size: 898 bytes --]
Hi,
this question is maybe off-topic on this list...
I use the Lite5200B board with stock kernel 2.6.29, and boot with the
root fs on nfs on an Ubuntu 8.10 PC. Both the Lite5200B and the Ubuntu
PC are part of a corporate network. On the root fs, I have busybox and
everything else needed. Being connected with minicom to the serial
console, after some time I always see a message like
[ 4912.350855] nfs: server 10.16.10.29 not responding, still trying
an the the system is *completely* dead, i.e. it doesn't respond to
<ctrl>-<c>, it doesn't (as a desktop pc sometimes does) print more than
one of these or any other kernel messages, and it doesn't recover from
this condition. Apparently it doesn't matter if just the busybox shell
is waiting or if an application is running.
Any idea what goes wrong here, and how I could fix it?
Thanks, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v3] powerpc/85xx: Add P2020DS board support
From: Scott Wood @ 2009-04-22 17:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <E25C4315-A3BA-42DF-B2D2-B1CD2D76A03F@kernel.crashing.org>
Kumar Gala wrote:
>
> On Apr 22, 2009, at 12:16 PM, Scott Wood wrote:
>
>> Kumar Gala wrote:
>>> On Apr 22, 2009, at 12:04 PM, Scott Wood wrote:
>>>> Kumar Gala wrote:
>>>>>> If this has an elbc more recent than 1.0 (looks like it), we should
>>>>>> indicate that here.
>>>>> that might be the case, but I leave it to u-boot to do that.
>>>>
>>>> Why? There's no p2020 with an older eLBC, and there's no block
>>>> version register.
>>> But there might be a p2020 w/a newer eLBC version in the future.
>>
>> At which point we can add something to u-boot -- but magic SVR tables
>> seem a step backward from the dts except where needed to avoid the
>> creation of extra dts files.
>
> I don't see the value of complicating u-boot
But complicating u-boot is just what you're suggesting. Put it in the
dts, and u-boot has *zero* code to deal with this unless we find
ourselves wanting to share the dts with another board rev with a newer
chip with a newer elbc.
> to have to parse and
> "fixup" the compatible instead of just having to prepend to it.
> Especially since I don't believe there is anything specific we care
> about in the 1.2 version of elbc at this point.
If the new elbc is compatible with the current one, then you will still
just be prepending. If it is not, then it very likely isn't compatible
with 1.0 either, so you'll have to remove fsl,elbc anyway.
What "we care about" at this point is irrelevant, given the PITA it
would be to change the device trees (or u-boot) that are already in use
once we do begin to care.
-Scott
^ permalink raw reply
* [PATCH] powerpc/86xx: clean up smp init code
From: Kumar Gala @ 2009-04-22 17:34 UTC (permalink / raw)
To: linuxppc-dev
Removed the need for asm/mpc86xx.h as it was only used in mpc86xx_smp.c
and just moved the defines it cared about into there. Also fixed up
the ioremap to only map the one 4k page we need access to and to iounmap
when we are done.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/include/asm/mpc86xx.h | 33 ----------------------------
arch/powerpc/platforms/86xx/gef_ppc9a.c | 1 -
arch/powerpc/platforms/86xx/gef_sbc310.c | 1 -
arch/powerpc/platforms/86xx/gef_sbc610.c | 1 -
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 1 -
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 1 -
arch/powerpc/platforms/86xx/mpc86xx_smp.c | 8 ++++++-
arch/powerpc/platforms/86xx/sbc8641d.c | 1 -
8 files changed, 7 insertions(+), 40 deletions(-)
delete mode 100644 arch/powerpc/include/asm/mpc86xx.h
diff --git a/arch/powerpc/include/asm/mpc86xx.h b/arch/powerpc/include/asm/mpc86xx.h
deleted file mode 100644
index 15f650f..0000000
--- a/arch/powerpc/include/asm/mpc86xx.h
+++ /dev/null
@@ -1,33 +0,0 @@
-/*
- * MPC86xx definitions
- *
- * Author: Jeff Brown
- *
- * Copyright 2004 Freescale Semiconductor, Inc
- *
- * 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.
- */
-
-#ifdef __KERNEL__
-#ifndef __ASM_POWERPC_MPC86xx_H__
-#define __ASM_POWERPC_MPC86xx_H__
-
-#include <asm/mmu.h>
-
-#ifdef CONFIG_PPC_86xx
-
-#define CPU0_BOOT_RELEASE 0x01000000
-#define CPU1_BOOT_RELEASE 0x02000000
-#define CPU_ALL_RELEASED (CPU0_BOOT_RELEASE | CPU1_BOOT_RELEASE)
-#define MCM_PORT_CONFIG_OFFSET 0x1010
-
-/* Offset from CCSRBAR */
-#define MPC86xx_MCM_OFFSET (0x00000)
-#define MPC86xx_MCM_SIZE (0x02000)
-
-#endif /* CONFIG_PPC_86xx */
-#endif /* __ASM_POWERPC_MPC86xx_H__ */
-#endif /* __KERNEL__ */
diff --git a/arch/powerpc/platforms/86xx/gef_ppc9a.c b/arch/powerpc/platforms/86xx/gef_ppc9a.c
index d791046..2efa052 100644
--- a/arch/powerpc/platforms/86xx/gef_ppc9a.c
+++ b/arch/powerpc/platforms/86xx/gef_ppc9a.c
@@ -28,7 +28,6 @@
#include <asm/time.h>
#include <asm/machdep.h>
#include <asm/pci-bridge.h>
-#include <asm/mpc86xx.h>
#include <asm/prom.h>
#include <mm/mmu_decl.h>
#include <asm/udbg.h>
diff --git a/arch/powerpc/platforms/86xx/gef_sbc310.c b/arch/powerpc/platforms/86xx/gef_sbc310.c
index af14f85..90754e7 100644
--- a/arch/powerpc/platforms/86xx/gef_sbc310.c
+++ b/arch/powerpc/platforms/86xx/gef_sbc310.c
@@ -28,7 +28,6 @@
#include <asm/time.h>
#include <asm/machdep.h>
#include <asm/pci-bridge.h>
-#include <asm/mpc86xx.h>
#include <asm/prom.h>
#include <mm/mmu_decl.h>
#include <asm/udbg.h>
diff --git a/arch/powerpc/platforms/86xx/gef_sbc610.c b/arch/powerpc/platforms/86xx/gef_sbc610.c
index ea23606..72b31a6 100644
--- a/arch/powerpc/platforms/86xx/gef_sbc610.c
+++ b/arch/powerpc/platforms/86xx/gef_sbc610.c
@@ -28,7 +28,6 @@
#include <asm/time.h>
#include <asm/machdep.h>
#include <asm/pci-bridge.h>
-#include <asm/mpc86xx.h>
#include <asm/prom.h>
#include <mm/mmu_decl.h>
#include <asm/udbg.h>
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 3f49a6f..51eec0c 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -28,7 +28,6 @@
#include <asm/time.h>
#include <asm/machdep.h>
#include <asm/pci-bridge.h>
-#include <asm/mpc86xx.h>
#include <asm/prom.h>
#include <mm/mmu_decl.h>
#include <asm/udbg.h>
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index c4ec49b..7e9e83c 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -24,7 +24,6 @@
#include <asm/time.h>
#include <asm/machdep.h>
#include <asm/pci-bridge.h>
-#include <asm/mpc86xx.h>
#include <asm/prom.h>
#include <mm/mmu_decl.h>
#include <asm/udbg.h>
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_smp.c b/arch/powerpc/platforms/86xx/mpc86xx_smp.c
index 014e26c..d84bbb5 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_smp.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_smp.c
@@ -20,7 +20,6 @@
#include <asm/pgtable.h>
#include <asm/pci-bridge.h>
#include <asm/mpic.h>
-#include <asm/mpc86xx.h>
#include <asm/cacheflush.h>
#include <sysdev/fsl_soc.h>
@@ -30,6 +29,11 @@
extern void __secondary_start_mpc86xx(void);
extern unsigned long __secondary_hold_acknowledge;
+#define MCM_PORT_CONFIG_OFFSET 0x10
+
+/* Offset from CCSRBAR */
+#define MPC86xx_MCM_OFFSET (0x1000)
+#define MPC86xx_MCM_SIZE (0x1000)
static void __init
smp_86xx_release_core(int nr)
@@ -48,6 +52,8 @@ smp_86xx_release_core(int nr)
pcr = in_be32(mcm_vaddr + (MCM_PORT_CONFIG_OFFSET >> 2));
pcr |= 1 << (nr + 24);
out_be32(mcm_vaddr + (MCM_PORT_CONFIG_OFFSET >> 2), pcr);
+
+ iounmap(mcm_vaddr);
}
diff --git a/arch/powerpc/platforms/86xx/sbc8641d.c b/arch/powerpc/platforms/86xx/sbc8641d.c
index 2886a36..51c8f33 100644
--- a/arch/powerpc/platforms/86xx/sbc8641d.c
+++ b/arch/powerpc/platforms/86xx/sbc8641d.c
@@ -25,7 +25,6 @@
#include <asm/time.h>
#include <asm/machdep.h>
#include <asm/pci-bridge.h>
-#include <asm/mpc86xx.h>
#include <asm/prom.h>
#include <mm/mmu_decl.h>
#include <asm/udbg.h>
--
1.6.0.6
^ permalink raw reply related
* Re: ofpart: Partitions at same address cannot have the same name
From: Scott Wood @ 2009-04-22 17:27 UTC (permalink / raw)
To: Benjamin Krill; +Cc: Ricardo Ribalda Delgado, linuxppc-dev, David.Woodhouse
In-Reply-To: <20090422171030.GH14906@codiert.org>
Benjamin Krill wrote:
>> --- a/drivers/mtd/ofpart.c
>> +++ b/drivers/mtd/ofpart.c
>> @@ -48,7 +48,7 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
>>
>> /* check if this is a partition node */
>> partname = of_get_property(pp, "name", &len);
>> - if (strcmp(partname, "partition") != 0) {
>> + if (strncmp(partname, "partition", strlen("partition") != 0) {
Perhaps "compatible" should be used instead?
> Hi Recardo,
>
> I would suggest to do:
>
> if (strcmp(partname, "partition") <= 0) {
Check whether it sorts alphabetically before "partition"? Why?
-Scott
^ permalink raw reply
* Re: [PATCH v3] powerpc/85xx: Add P2020DS board support
From: Kumar Gala @ 2009-04-22 17:25 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <49EF50EC.1040608@freescale.com>
On Apr 22, 2009, at 12:16 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Apr 22, 2009, at 12:04 PM, Scott Wood wrote:
>>> Kumar Gala wrote:
>>>>> If this has an elbc more recent than 1.0 (looks like it), we
>>>>> should
>>>>> indicate that here.
>>>> that might be the case, but I leave it to u-boot to do that.
>>>
>>> Why? There's no p2020 with an older eLBC, and there's no block
>>> version register.
>> But there might be a p2020 w/a newer eLBC version in the future.
>
> At which point we can add something to u-boot -- but magic SVR
> tables seem a step backward from the dts except where needed to
> avoid the creation of extra dts files.
I don't see the value of complicating u-boot to have to parse and
"fixup" the compatible instead of just having to prepend to it.
Especially since I don't believe there is anything specific we care
about in the 1.2 version of elbc at this point.
- k
^ permalink raw reply
* Re: [BUILD FAILURE 02/12] Next April 21 : PPC64 randconfig [drivers/net/ni65.c]
From: Andreas Mohr @ 2009-04-22 17:20 UTC (permalink / raw)
To: Subrata Modak
Cc: sachinp, Stephen Rothwell, Jan-Pascal van Best, netdev,
linux-kernel, Andreas Mohr, Linuxppc-dev, Michael Hipp,
linux-next, linux-net, Alexander Beregalov
In-Reply-To: <1240416947.26824.9.camel@subratamodak.linux.ibm.com>
Hi,
On Wed, Apr 22, 2009 at 09:45:47PM +0530, Subrata Modak wrote:
> On Wed, 2009-04-22 at 00:20 +0530, Subrata Modak wrote:
> > I am observing this for the first time:
> >
> > CC drivers/net/ni65.o
> > drivers/net/ni65.c: In function ‘ni65_init_lance’:
> > drivers/net/ni65.c:585: error: implicit declaration of function
> > ‘isa_virt_to_bus’
> > drivers/net/ni65.c: In function ‘ni65_stop_start’:
> > drivers/net/ni65.c:757: error: implicit declaration of function
> > ‘isa_bus_to_virt’
> > make[2]: *** [drivers/net/ni65.o] Error 1
> > make[1]: *** [drivers/net] Error 2
> > make: *** [drivers] Error 2
> > ---
>
> Is there any specific dependency of whether this should be built only
> with certain archs ? As the case may be, i found the functions
> prototypes defined inside the arch specific headers, which definitely
> will not compile on PPC64:
>
> # find . -type f | xargs grep -in isa_virt_to_bus
> ./arch/alpha/include/asm/io.h:119:#define isa_virt_to_bus virt_to_bus
> ./arch/arm/include/asm/io.h:33:#define isa_virt_to_bus virt_to_phys
> ./arch/mips/include/asm/io.h:142:static inline unsigned long
> isa_virt_to_bus(volatile void * address)
> ./arch/parisc/include/asm/io.h:17:static inline unsigned long
> isa_virt_to_bus(void *addr) {
> ./arch/x86/include/asm/floppy.h:182:
> isa_virt_to_bus(addr) >= 0x1000000 ||
> ./arch/x86/include/asm/floppy.h:218: set_dma_addr(FLOPPY_DMA,
> isa_virt_to_bus(addr));
> ./arch/x86/include/asm/io.h:130:static inline unsigned int
> isa_virt_to_bus(volatile void *address)
But NI65 is properly guarded against ISA bus non-support already:
config NI65
tristate "NI6510 support"
depends on NET_VENDOR_RACAL && ISA && ISA_DMA_API
help
If you have a network (Ethernet) card of this type, say Y and read
the Ethernet-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
To compile this driver as a module, choose M here. The module
will be called ni65.
And powerpc _does_ offer ISA bus support:
./arch/powerpc/Kconfig:config ISA
./arch/powerpc/Kconfig: bool "Support for ISA-bus hardware"
./arch/powerpc/Kconfig: Find out whether you have ISA slots on your motherboard. ISA is the
Of course I'm 167% sure that nobody has ever tried those cards on ppc ;-),
but still that would be a _possibility_ that shouldn't be denied straight away.
> Then there should be some solution to the problem inside
> drivers/net/Kconfig
Indeed, which (given my above comments) should probably be to provide
some isa_virt_to_bus() functionality on powerpc or conditionally disable (yuck!)
use of these mechanisms in the drivers.
Anyway, it's certainly not a mistake per se to try to build those drivers on
an ISA-support-enabled powerpc platform.
Of course I'm not certain as to current status of e.g. ni5010, but OTOH I still
have some of those cards... (after all I'm the driver co-author)
Thanks for the heads-up,
Andreas Mohr
^ 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