* Re: [PATCH] PowerPC 44x: add missing define TARGET_4xx to cuboot-taishan.c
From: Josh Boyer @ 2008-02-24 15:32 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20080221144317.GA19395@ru.mvista.com>
On Thu, 21 Feb 2008 17:43:17 +0300
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> In order to get the proper bd_info structure for PowerPC 440,
> both TARGET_4xx and TARGET_44x should be defined.
Could you explain what this adds or why it's needed in the changelog?
Also, is this needed for other 440 boards?
josh
^ permalink raw reply
* Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Jochen Friedrich @ 2008-02-24 15:16 UTC (permalink / raw)
To: Olof Johansson
Cc: Jean Delvare, linuxppc-dev list, linux-kernel, Scott Wood, i2c
In-Reply-To: <20080223212823.GA22131@lixom.net>
Hi Olof,
>> 2. record the I2c name in the dts tree, either as seperate tag (like linux,i2c-name="<i2c-name>")
>> or as additional compatible entry (like compatible="...", "linux,<i2c-name>").
>
> I have to say no on this one. The device tree is not supposed to know
> about how linux uses devices, there are firmwares out there that don't
> use DTS for thier device trees, etc.
I still believe this this could be done for embedded devices which are usually booted
via wrapper or U-Boot as those devices will most probably use the most exotic I2c devices
out there (e.g. home-grown devices used by stbs). However, I'm not an device tree expert.
>> 3. use a glue layer with a translation map.
>
> In my opinion this is an OK solution since the same information has to
> be added somewhere already anyway -- eiither to the drivers or to this
> translation table. It should of course be an abstacted shared table,
> preferrably contained under the i2c source directories since several
> platforms and architectures might share them.
I could think of a mixture between 2. and 3.:
Using the compatible attribute with the manufacturer stripped off as I2c name by default
and using an exception table. For now, the struct i2c_driver_device would currently only
need one entry ("dallas,ds1374", "rtc-ds1374").
Thanks,
Jochen
^ permalink raw reply
* Re: How to dynamically disable/enable CPU features?
From: Gerhard Pircher @ 2008-02-24 14:47 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, miltonm
In-Reply-To: <1203719521.6976.30.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Sat, 23 Feb 2008 09:32:01 +1100
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: Milton Miller <miltonm@bga.com>, linuxppc-dev@ozlabs.org
> Betreff: Re: How to dynamically disable/enable CPU features?
> > The flag is in POSSIBLE. I now use this code in the platform probe
> > function to nop out the code affected by the flag:
> >
> > cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
> > /* Patch out unwanted feature. */
> > do_feature_fixups(cur_cpu_spec->cpu_features,
> > PTRRELOC(&__start___ftr_fixup),
> > PTRRELOC(&__stop___ftr_fixup));
> >
> > It seems to work so far, but I would like to know if this is the right
> > way to do it, or if calling do_feature_fixups() more than once can have
> > any side effects.
>
> It's a bit hairy... Things -could- have been nop'ed out by the first
> call as a result of CPU_FTR_NEED_COHERENT being set and the second
> call will not be able to put them back in... now that may not be the
> case (depends what kind of patching is done with that flag) and so
> 'happen' to work for this specific bit but it isn't a nice solution...
I checked this now. Looks like it only needs to nop out some code (mainly
in the hash table code).
> A better long term approach is to look at moving the fixup to after
> the machine probe() after carefully checking whether that can cause
> any problem...
Well, that's a job for an more experienced kernel developer. :)
Thanks!
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* Re: Status of 5200B and 440 Kernel Support
From: Josh Boyer @ 2008-02-24 13:38 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: LinuxPPC Embedded
In-Reply-To: <1203848259l.2313l.1l@antares.localdomain>
On Sun, 24 Feb 2008 11:17:39 +0100
Albrecht Dre=C3=9F <albrecht.dress@arcor.de> wrote:
> For a decision, I need some further information about the Kernel =20
> support (source code available, if possible in stock kernels, *not* =20
> only vendor binary modules!) of the included devices, in particular
For 440EP in arch/powerpc:
> - MTD/NAND controller
NOR flash works. NAND needs some additional code.
> - Ethernet
Works.
> - UART, IIC and SPI
UART works. IIC has recent patches. No idea about SPI.
> - USB host
Works.
> - local external bus (not PCI) DMA
DMA to the EBC for what?
josh
^ permalink raw reply
* Status of 5200B and 440 Kernel Support
From: Albrecht Dreß @ 2008-02-24 10:17 UTC (permalink / raw)
To: LinuxPPC Embedded
[-- Attachment #1: Type: text/plain, Size: 640 bytes --]
Hi all,
sorry if this is a dumb question, I'm new in the list...
For a new project, I am looking through the available PPC based SoC's.
Good candidates are probably the Freescale 5200B or the AMCC 440EP (I
need a FPU).
For a decision, I need some further information about the Kernel
support (source code available, if possible in stock kernels, *not*
only vendor binary modules!) of the included devices, in particular
- MTD/NAND controller
- Ethernet
- UART, IIC and SPI
- USB host
- local external bus (not PCI) DMA
Any information or pointers would be really appreciated!
Thanks in advance,
Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] ps3: Fix "unlikely" incorrect usage
From: Samuel Tardieu @ 2008-02-24 8:06 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, cbe-oss-dev
Fix unlikely(plug) == NO_IRQ into unlikely(plug == NO_IRQ).
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
---
arch/powerpc/platforms/ps3/interrupt.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/interrupt.c b/arch/powerpc/platforms/ps3/interrupt.c
index 3a6db04..a14e5cd 100644
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -709,7 +709,7 @@ static unsigned int ps3_get_irq(void)
asm volatile("cntlzd %0,%1" : "=r" (plug) : "r" (x));
plug &= 0x3f;
- if (unlikely(plug) == NO_IRQ) {
+ if (unlikely(plug == NO_IRQ)) {
pr_debug("%s:%d: no plug found: thread_id %lu\n", __func__,
__LINE__, pd->thread_id);
dump_bmp(&per_cpu(ps3_private, 0));
--
1.5.4.2.197.g22c43
^ permalink raw reply related
* Re: [PATCH] Add support for binary includes.
From: Jon Loeliger @ 2008-02-22 18:12 UTC (permalink / raw)
To: Scott Wood, jdl, linuxppc-dev
In-Reply-To: <20080222053450.GH3064@localhost.localdomain>
David Gibson wrote:
>> node {
>> prop = /incbin/("path/to/data");
>> };
>>
>> node {
>> prop = /incbin/("path/to/data", 8, 16);
>> };
>
> I still dislike the syntax, but haven't thought of a better one yet.
> There are some issues with the implementation too, but I've been a bit
> too busy with ePAPR stuff to review properly.
I'm OK with the syntax, but whatever-ish.
Would these be better?:
prop = /call/(incbin, "path/to/data", 17, 23);
prop = /call[incbin]/("path/to/data");
prop = /call incbin/("path/to/data", 12, 12+10);
What is the aspect of the syntax that you don't like?
I think we essentially need to stick in the /.../ realm
to be consistent with the other non-standard names being
used, like /include/.
I can see a generalized form that allows other pre-defined
or user-defined "functions" to be introduced and called
or used in a similar way:
prop = <(22 + /fibonacci/(7)) 1000>;
prop = /directoryof/("/path/to/some/file.doc");
interrupt-map = /pci_int_map/(8000, 2, 14);
or whatever. We can paint this bikeshed for a long time
if we need to. Or, we can get down to some serious issue
if there are any. Are there?
jdl
^ permalink raw reply
* Please pull linux-2.6-mpc52xx.git
From: Grant Likely @ 2008-02-24 7:35 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev, EricDuj
Paul, here is a bug fix that needs to go in for 2.6.25.
Thanks,
g.
The following changes since commit 42e6de0e6079f4a7ce6bd62340b1b14a1af314dc:
Oliver Pinter (1):
fix vmsas.c file permissions
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-mpc52xx.git for-2.6.25
Eric Dujardin (1):
[POWERPC] Add export for mpc52xx_set_psc_clkdiv
arch/powerpc/platforms/52xx/mpc52xx_common.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] Xilinx: hwicap: cleanup
From: Grant Likely @ 2008-02-24 6:20 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, git-dev, jirislaby, linux-kernel
In-Reply-To: <fa686aa40802232216s47b7751bi384352697dbf4ce2@mail.gmail.com>
Stephen, when you address these comments, please double check the lkml
address. It was misspelled when you sent this patch.
Cheers,
g.
On Sat, Feb 23, 2008 at 11:16 PM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Mon, Feb 11, 2008 at 11:24 AM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> > Fix some missing __user tags and incorrect section tags.
> > Convert semaphores to mutexes.
> > Make probed_devices re-entrancy and error condition safe.
> > Fix some backwards memcpys.
> > Some other minor cleanups.
> > Use kerneldoc format.
> >
> > Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
>
> Thanks Steven, some more comments below.
^^^^^^
Oops, sorry about the spelling.
g.
>
>
> >
> > ---
> >
> > Grant, Since it appears that the driver will stay in as-is, here are
> > the updates against mainline, based on Jiri's comments.
> > ---
> > drivers/char/xilinx_hwicap/buffer_icap.c | 80 ++++++++++----------
> > drivers/char/xilinx_hwicap/fifo_icap.c | 60 +++++++-------
> > drivers/char/xilinx_hwicap/xilinx_hwicap.c | 113 ++++++++++++++++------------
> > drivers/char/xilinx_hwicap/xilinx_hwicap.h | 24 +++---
> > 4 files changed, 148 insertions(+), 129 deletions(-)
> >
> > diff --git a/drivers/char/xilinx_hwicap/buffer_icap.c b/drivers/char/xilinx_hwicap/buffer_icap.c
> > index dfea2bd..2c5d17d 100644
> > --- a/drivers/char/xilinx_hwicap/buffer_icap.c
> > +++ b/drivers/char/xilinx_hwicap/buffer_icap.c
>
> > @@ -148,9 +148,9 @@ static inline void buffer_icap_set_size(void __iomem *base_address,
> > }
> >
> > /**
> > - * buffer_icap_mSetoffsetReg: Set the bram offset register.
> > - * @parameter base_address: contains the base address of the device.
> > - * @parameter data: is the value to be written to the data register.
> > + * buffer_icap_mSetoffsetReg - Set the bram offset register.
>
> This is the only function that is still in camel case; it should
> probably be changed also... In fact, this functions doesn't seem to be
> used at all. Can it just be removed? Are there any other unused
> functions in this driver?
>
>
> > diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> > index 24f6aef..eddaa26 100644
> > --- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> > +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
>
> > @@ -344,7 +345,7 @@ int hwicap_initialize_hwicap(struct hwicap_drvdata *drvdata)
> > }
> >
> > static ssize_t
> > -hwicap_read(struct file *file, char *buf, size_t count, loff_t *ppos)
> > +hwicap_read(struct file *file, __user char *buf, size_t count, loff_t *ppos)
>
> This looks like it should be 'char __user *buf' instead of '__user char *buf'.
>
>
> > {
> > struct hwicap_drvdata *drvdata = file->private_data;
> > ssize_t bytes_to_read = 0;
>
> > static ssize_t
> > -hwicap_write(struct file *file, const char *buf,
> > +hwicap_write(struct file *file, const __user char *buf,
> > size_t count, loff_t *ppos)
>
> Ditto on placement of __user
>
>
> > @@ -549,8 +556,7 @@ static int hwicap_release(struct inode *inode, struct file *file)
> > int i;
> > int status = 0;
> >
> > - if (down_interruptible(&drvdata->sem))
> > - return -ERESTARTSYS;
> > + mutex_lock(&drvdata->sem);
>
> Why not mutex_lock_interruptible()? (goes for all cases of mutex_lock())
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] Xilinx: hwicap: cleanup
From: Grant Likely @ 2008-02-24 6:16 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, git-dev, jirislaby, linux.kernel
In-Reply-To: <20080211182429.76E204D8018@mail62-sin.bigfish.com>
On Mon, Feb 11, 2008 at 11:24 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
> Fix some missing __user tags and incorrect section tags.
> Convert semaphores to mutexes.
> Make probed_devices re-entrancy and error condition safe.
> Fix some backwards memcpys.
> Some other minor cleanups.
> Use kerneldoc format.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Thanks Steven, some more comments below.
>
> ---
>
> Grant, Since it appears that the driver will stay in as-is, here are
> the updates against mainline, based on Jiri's comments.
> ---
> drivers/char/xilinx_hwicap/buffer_icap.c | 80 ++++++++++----------
> drivers/char/xilinx_hwicap/fifo_icap.c | 60 +++++++-------
> drivers/char/xilinx_hwicap/xilinx_hwicap.c | 113 ++++++++++++++++------------
> drivers/char/xilinx_hwicap/xilinx_hwicap.h | 24 +++---
> 4 files changed, 148 insertions(+), 129 deletions(-)
>
> diff --git a/drivers/char/xilinx_hwicap/buffer_icap.c b/drivers/char/xilinx_hwicap/buffer_icap.c
> index dfea2bd..2c5d17d 100644
> --- a/drivers/char/xilinx_hwicap/buffer_icap.c
> +++ b/drivers/char/xilinx_hwicap/buffer_icap.c
> @@ -148,9 +148,9 @@ static inline void buffer_icap_set_size(void __iomem *base_address,
> }
>
> /**
> - * buffer_icap_mSetoffsetReg: Set the bram offset register.
> - * @parameter base_address: contains the base address of the device.
> - * @parameter data: is the value to be written to the data register.
> + * buffer_icap_mSetoffsetReg - Set the bram offset register.
This is the only function that is still in camel case; it should
probably be changed also... In fact, this functions doesn't seem to be
used at all. Can it just be removed? Are there any other unused
functions in this driver?
> diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.c b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> index 24f6aef..eddaa26 100644
> --- a/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.c
> @@ -344,7 +345,7 @@ int hwicap_initialize_hwicap(struct hwicap_drvdata *drvdata)
> }
>
> static ssize_t
> -hwicap_read(struct file *file, char *buf, size_t count, loff_t *ppos)
> +hwicap_read(struct file *file, __user char *buf, size_t count, loff_t *ppos)
This looks like it should be 'char __user *buf' instead of '__user char *buf'.
> {
> struct hwicap_drvdata *drvdata = file->private_data;
> ssize_t bytes_to_read = 0;
> static ssize_t
> -hwicap_write(struct file *file, const char *buf,
> +hwicap_write(struct file *file, const __user char *buf,
> size_t count, loff_t *ppos)
Ditto on placement of __user
> @@ -549,8 +556,7 @@ static int hwicap_release(struct inode *inode, struct file *file)
> int i;
> int status = 0;
>
> - if (down_interruptible(&drvdata->sem))
> - return -ERESTARTSYS;
> + mutex_lock(&drvdata->sem);
Why not mutex_lock_interruptible()? (goes for all cases of mutex_lock())
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] [POWERPC] mpc5200: fix build error on mpc52xx_psc_spi device driver
From: Grant Likely @ 2008-02-24 5:49 UTC (permalink / raw)
To: dbrownell, dragos.carp, linux-kernel, linuxppc-dev,
spi-devel-general
From: Grant Likely <grant.likely@secretlab.ca>
Commit id 94f389485e27641348c1951ab8d65157122a8939 (Separate MPC52xx PSC
FIOF regsiters from the rest of PSC) split the PSC fifo registers away
from the core PSC regs. Doing so broke the mpc52xx_psc_spi driver.
This patch teaches the mpc52xx_psc_spi driver about the new PSC fifo
register definitions.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
This is a build error bug fix which needs to go into .25
---
drivers/spi/mpc52xx_psc_spi.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index 253ed56..a86315a 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -42,6 +42,7 @@ struct mpc52xx_psc_spi {
/* driver internal data */
struct mpc52xx_psc __iomem *psc;
+ struct mpc52xx_psc_fifo __iomem *fifo;
unsigned int irq;
u8 bits_per_word;
u8 busy;
@@ -139,6 +140,7 @@ static int mpc52xx_psc_spi_transfer_rxtx(struct spi_device *spi,
{
struct mpc52xx_psc_spi *mps = spi_master_get_devdata(spi->master);
struct mpc52xx_psc __iomem *psc = mps->psc;
+ struct mpc52xx_psc_fifo __iomem *fifo = mps->fifo;
unsigned rb = 0; /* number of bytes receieved */
unsigned sb = 0; /* number of bytes sent */
unsigned char *rx_buf = (unsigned char *)t->rx_buf;
@@ -190,11 +192,11 @@ static int mpc52xx_psc_spi_transfer_rxtx(struct spi_device *spi,
out_8(&psc->mode, 0);
} else {
out_8(&psc->mode, MPC52xx_PSC_MODE_FFULL);
- out_be16(&psc->rfalarm, rfalarm);
+ out_be16(&fifo->rfalarm, rfalarm);
}
out_be16(&psc->mpc52xx_psc_imr, MPC52xx_PSC_IMR_RXRDY);
wait_for_completion(&mps->done);
- recv_at_once = in_be16(&psc->rfnum);
+ recv_at_once = in_be16(&fifo->rfnum);
dev_dbg(&spi->dev, "%d bytes received\n", recv_at_once);
send_at_once = recv_at_once;
@@ -331,6 +333,7 @@ static void mpc52xx_psc_spi_cleanup(struct spi_device *spi)
static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi *mps)
{
struct mpc52xx_psc __iomem *psc = mps->psc;
+ struct mpc52xx_psc_fifo __iomem *fifo = mps->fifo;
u32 mclken_div;
int ret = 0;
@@ -346,7 +349,7 @@ static int mpc52xx_psc_spi_port_config(int psc_id, struct mpc52xx_psc_spi *mps)
/* Disable interrupts, interrupts are based on alarm level */
out_be16(&psc->mpc52xx_psc_imr, 0);
out_8(&psc->command, MPC52xx_PSC_SEL_MODE_REG_1);
- out_8(&psc->rfcntl, 0);
+ out_8(&fifo->rfcntl, 0);
out_8(&psc->mode, MPC52xx_PSC_MODE_FFULL);
/* Configure 8bit codec mode as a SPI master and use EOF flags */
@@ -419,6 +422,8 @@ static int __init mpc52xx_psc_spi_do_probe(struct device *dev, u32 regaddr,
ret = -EFAULT;
goto free_master;
}
+ /* On the 5200, fifo regs are immediately ajacent to the psc regs */
+ mps->fifo = ((void __iomem *)mps->psc) + sizeof(struct mpc52xx_psc);
ret = request_irq(mps->irq, mpc52xx_psc_spi_isr, 0, "mpc52xx-psc-spi",
mps);
^ permalink raw reply related
* Re: [PATCH] sata_fsl: fix build with ATA_VERBOSE_DEBUG
From: Jeff Garzik @ 2008-02-24 5:30 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <20080222165425.GA27460@localhost.localdomain>
Anton Vorontsov wrote:
> This patch fixes build and few warnings when ATA_VERBOSE_DEBUG
> is defined:
>
> CC drivers/ata/sata_fsl.o
> drivers/ata/sata_fsl.c: In function ‘sata_fsl_fill_sg’:
> drivers/ata/sata_fsl.c:338: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘void *’
> drivers/ata/sata_fsl.c:338: warning: format ‘%x’ expects type ‘unsigned int’, but argument 4 has type ‘struct prde *’
> drivers/ata/sata_fsl.c: In function ‘sata_fsl_qc_issue’:
> drivers/ata/sata_fsl.c:459: error: ‘csr_base’ undeclared (first use in this function)
> drivers/ata/sata_fsl.c:459: error: (Each undeclared identifier is reported only once
> drivers/ata/sata_fsl.c:459: error: for each function it appears in.)
> drivers/ata/sata_fsl.c: In function ‘sata_fsl_freeze’:
> drivers/ata/sata_fsl.c:525: error: ‘csr_base’ undeclared (first use in this function)
> make[2]: *** [drivers/ata/sata_fsl.o] Error 1
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/ata/sata_fsl.c | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
applied
^ permalink raw reply
* Re: [PATCH 1/2][OF] Add of_device_is_disabled function
From: David Miller @ 2008-02-24 2:45 UTC (permalink / raw)
To: jwboyer; +Cc: linuxppc-dev, sfr
In-Reply-To: <20080223185904.757c2884@zod.rchland.ibm.com>
From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Date: Sat, 23 Feb 2008 18:59:04 -0600
> Dave, I'm not sure how applicable this all is to sparc. But for some
> of the "newer" embedded ports that are coming into powerpc I can see it
> being very useful.
I think I've seen this property on sparc boxes too, I'm fine
with whatever you guys come up with.
^ permalink raw reply
* [PATCH][OF] Add of_device_is_available function
From: Josh Boyer @ 2008-02-24 2:23 UTC (permalink / raw)
To: sfr, davem, benh; +Cc: linuxppc-dev
In-Reply-To: <20080223185904.757c2884@zod.rchland.ibm.com>
On Sat, 23 Feb 2008 18:59:04 -0600
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Sat, 23 Feb 2008 15:58:23 -0600
> Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
>
> > IEEE 1275 defined a standard "status" property to indicate the operational
> > status of a device. The property has four possible values: okay, disabled,
> > fail, fail-xxx. The absence of this property means the operational status
> > of the device is unknown or okay.
> >
> > This adds a function called of_device_is_disabled that checks to see if a
> > node has the status property set to "disabled". This can be quite useful
> > for devices that may be present but disabled due to pin sharing, etc.
> >
> > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> Talking with Ben H a bit, he suggested to reverse this API. Basically,
> create an of_device_is_available that returns 1 if the status property
> is completely missing, or if it's set to "okay" or "ok". The latter is
> to cope with some broken firmwares.
And since I seem to be talking to myself and have nothing better to do
on a Saturday evening, here's the code.
josh
IEEE 1275 defined a standard "status" property to indicate the operational
status of a device. The property has four possible values: okay, disabled,
fail, fail-xxx. The absence of this property means the operational status
of the device is unknown or okay.
This adds a function called of_device_is_available that checks the state
of the status property of a device. If the property is absent or set to
either "okay" or "ok", it returns 1. Otherwise it returns 0.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
drivers/of/base.c | 23 +++++++++++++++++++++++
include/linux/of.h | 1 +
2 files changed, 24 insertions(+)
--- linux-2.6.orig/drivers/of/base.c
+++ linux-2.6/drivers/of/base.c
@@ -117,6 +117,29 @@ int of_device_is_compatible(const struct
EXPORT_SYMBOL(of_device_is_compatible);
/**
+ * of_device_is_available - check if a device is available for use
+ *
+ * @device: Node to check for availability
+ *
+ * Returns 1 if the status property is absent or set to "okay" or "ok",
+ * 0 otherwise
+ */
+int of_device_is_available(const struct device_node *device)
+{
+ const char *status;
+
+ status = of_get_property(device, "status", NULL);
+ if (status == NULL)
+ return 1;
+
+ if (!strcmp(status, "okay") || !strcmp(status, "ok"))
+ return 1;
+
+ return 0;
+}
+EXPORT_SYMBOL(of_device_is_available);
+
+/**
* of_get_parent - Get a node's parent if any
* @node: Node to get parent
*
--- linux-2.6.orig/include/linux/of.h
+++ linux-2.6/include/linux/of.h
@@ -62,6 +62,7 @@ extern struct property *of_find_property
int *lenp);
extern int of_device_is_compatible(const struct device_node *device,
const char *);
+extern int of_device_is_available(const struct device_node *device);
extern const void *of_get_property(const struct device_node *node,
const char *name,
int *lenp);
^ permalink raw reply
* Re: [PATCH 1/2][OF] Add of_device_is_disabled function
From: Josh Boyer @ 2008-02-24 0:59 UTC (permalink / raw)
To: sfr, davem, benh; +Cc: linuxppc-dev
In-Reply-To: <20080223155823.2c85d829@zod.rchland.ibm.com>
On Sat, 23 Feb 2008 15:58:23 -0600
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> IEEE 1275 defined a standard "status" property to indicate the operational
> status of a device. The property has four possible values: okay, disabled,
> fail, fail-xxx. The absence of this property means the operational status
> of the device is unknown or okay.
>
> This adds a function called of_device_is_disabled that checks to see if a
> node has the status property set to "disabled". This can be quite useful
> for devices that may be present but disabled due to pin sharing, etc.
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Talking with Ben H a bit, he suggested to reverse this API. Basically,
create an of_device_is_available that returns 1 if the status property
is completely missing, or if it's set to "okay" or "ok". The latter is
to cope with some broken firmwares.
I can do either really. Eventually you could embed the is_available
check in the of_platform code so that devices don't even get presented
to drivers if they aren't available.
Dave, I'm not sure how applicable this all is to sparc. But for some
of the "newer" embedded ports that are coming into powerpc I can see it
being very useful.
Thoughts?
josh
^ permalink raw reply
* Re: [PATCH 5/5] [POWERPC] Add 460EX PCIe support to 4xx pci driver
From: Paul Mackerras @ 2008-02-23 22:39 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <1203799608.6976.44.camel@pasglop>
Benjamin Herrenschmidt writes:
> Actually, the patch just adds a backend to my little framework for
> dealing with 4xx PCIe, which basically is a boring piece of code
> filling registers with values mostly from the spec... nothing really
> fancy there.
OK, then that's what the patch description should tell us...
Paul.
^ permalink raw reply
* Re: [PATCH 0/3] [POWERPC] 4xx: Add support for AMCC 440EP Yosemite board
From: Josh Boyer @ 2008-02-23 22:19 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080223160813.2f8d282b@zod.rchland.ibm.com>
On Sat, 23 Feb 2008 16:08:13 -0600
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> This small series of patches adds support for the AMCC 440EP Yosemite
> evaluation board. This is the newer evaluation board for PowerPC 440EP
> chips, replacing the older Bamboo board.
>
> This is just the initial round of patches, but they are functional.
> Also of note is that while all for on-board UARTs are enumerated in the
> DTS file, only two of them are usable on the board. The other two have
> their "status" property set to disabled. If used in conjunction with
> the of_device_is_disabled patches I just sent out, then devices for
> those won't be created. This is not required.
Olof asked on IRC why even bother enumerating the extra UARTs. I have
two reasons for this.
1) I want a user of the of_device_is_disabled patches, if only to show
it works and provide an example (it does work btw).
2) When I get to doing the EBC stuff for bamboo and yosemite, there are
devices that can come and go depending on dip switch settings (due to
pin sharing). My nefarious plan is to enumerate all of the devices in
the device tree, and poke a status = "disabled" property into the ones
that are no longer usable because of the dip switch settings. E.g.
EMAC1 becomes disabled if the NAND flash is enabled on Bamboo, etc.
josh
^ permalink raw reply
* [PATCH 3/3][POWERPC] 4xx: Add bootwrapper for AMCC Yosemite board
From: Josh Boyer @ 2008-02-23 22:10 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080223160813.2f8d282b@zod.rchland.ibm.com>
Add the cuboot wrapper for the AMCC 440EP Yosemite board
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/Makefile | 3 +-
arch/powerpc/boot/cuboot-yosemite.c | 42 ++++++++++++++++++++++++++++++++++++
2 files changed, 44 insertions(+), 1 deletion(-)
--- linux-2.6.orig/arch/powerpc/boot/Makefile
+++ linux-2.6/arch/powerpc/boot/Makefile
@@ -64,7 +64,7 @@ src-plat := of.c cuboot-52xx.c cuboot-82
cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
fixed-head.S ep88xc.c ep405.c \
cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \
- cuboot-warp.c cuboot-85xx-cpm2.c
+ cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -216,6 +216,7 @@ image-$(CONFIG_RAINIER) += cuImage.rai
image-$(CONFIG_TAISHAN) += cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
image-$(CONFIG_WARP) += cuImage.warp
+image-$(CONFIG_YOSEMITE) += cuImage.yosemite
# Board ports in arch/powerpc/platform/8xx/Kconfig
image-$(CONFIG_PPC_MPC86XADS) += cuImage.mpc866ads
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/cuboot-yosemite.c
@@ -0,0 +1,42 @@
+/*
+ * Old U-boot compatibility for Yosemite
+ *
+ * Author: Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * Copyright 2008 IBM Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "4xx.h"
+#include "44x.h"
+#include "cuboot.h"
+
+#define TARGET_44x
+#include "ppcboot.h"
+
+static bd_t bd;
+
+static void yosemite_fixups(void)
+{
+ unsigned long sysclk = 66666666;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
+ ibm4xx_sdram_fixup_memsize();
+ ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
+ dt_fixup_mac_addresses(&bd.bi_enetaddr, &bd.bi_enet1addr);
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+ platform_ops.fixups = yosemite_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+ fdt_init(_dtb_start);
+ serial_console_init();
+}
^ permalink raw reply
* [PATCH 2/3][POWERPC] 4xx: Add platform support for the AMCC Yosemite board
From: Josh Boyer @ 2008-02-23 22:09 UTC (permalink / raw)
Cc: linuxppc-dev
In-Reply-To: <20080223160813.2f8d282b@zod.rchland.ibm.com>
The AMCC 440EP Yosemite board is very similar to the original AMCC Bamboo
board. This adds a YOSEMITE option to Kconfig, and reuses the existing
bamboo board support in the kernel.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/platforms/44x/Kconfig | 9 +++++++++
arch/powerpc/platforms/44x/Makefile | 1 +
2 files changed, 10 insertions(+)
--- linux-2.6.orig/arch/powerpc/platforms/44x/Kconfig
+++ linux-2.6/arch/powerpc/platforms/44x/Kconfig
@@ -67,6 +67,15 @@ config WARP
See http://www.pikatechnologies.com/ and follow the "PIKA for Computer
Telephony Developers" link for more information.
+config YOSEMITE
+ bool "Yosemite"
+ depends on 44x
+ default n
+ select 440EP
+ select PCI
+ help
+ This option enables support for the AMCC PPC440EP evaluation board.
+
#config LUAN
# bool "Luan"
# depends on 44x
--- linux-2.6.orig/arch/powerpc/platforms/44x/Makefile
+++ linux-2.6/arch/powerpc/platforms/44x/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_44x) := misc_44x.o
obj-$(CONFIG_EBONY) += ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
+obj-$(CONFIG_YOSEMITE) += bamboo.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
^ permalink raw reply
* [PATCH 1/3][POWERPC] 4xx: Add AMCC 440EP Yosemite DTS
From: Josh Boyer @ 2008-02-23 22:09 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080223160813.2f8d282b@zod.rchland.ibm.com>
This adds a DTS file for the AMCC 440EP Yosemite board.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/boot/dts/yosemite.dts | 306 +++++++++++++++++++++++++++++++++++++
1 file changed, 306 insertions(+)
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/dts/yosemite.dts
@@ -0,0 +1,306 @@
+/*
+ * Device Tree Source for AMCC Yosemite
+ *
+ * Copyright 2008 IBM Corp.
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ *
+ * 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.
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,yosemite";
+ compatible = "amcc,yosemite","amcc,bamboo";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ ethernet1 = &EMAC1;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ serial2 = &UART2;
+ serial3 = &UART3;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,440EP";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ timebase-frequency = <0>; /* Filled in by zImage */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <8000>;
+ d-cache-size = <8000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0>; /* Filled in by zImage */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-440ep","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-440ep","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-440ep";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-440ep";
+ dcr-reg = <00c 002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-440ep", "ibm,plb-440gp", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-440ep", "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+ DMA0: dma {
+ compatible = "ibm,dma-440ep", "ibm,dma-440gp";
+ dcr-reg = <100 027>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-440ep", "ibm,mcmal-440gp", "ibm,mcmal";
+ dcr-reg = <180 62>;
+ num-tx-chans = <4>;
+ num-rx-chans = <2>;
+ interrupt-parent = <&MAL0>;
+ interrupts = <0 1 2 3 4>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*TXEOB*/ 0 &UIC0 a 4
+ /*RXEOB*/ 1 &UIC0 b 4
+ /*SERR*/ 2 &UIC1 0 4
+ /*TXDE*/ 3 &UIC1 1 4
+ /*RXDE*/ 4 &UIC1 2 4>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-440ep", "ibm,opb-440gp", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* Bamboo is oddball in the 44x world and doesn't use the ERPN
+ * bits.
+ */
+ ranges = <00000000 0 00000000 80000000
+ 80000000 0 80000000 80000000>;
+ interrupt-parent = <&UIC1>;
+ interrupts = <7 4>;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-440ep", "ibm,ebc-440gp", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ interrupts = <5 1>;
+ interrupt-parent = <&UIC1>;
+ };
+
+ UART0: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ current-speed = <1c200>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <0 4>;
+ };
+
+ UART1: serial@ef600400 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600400 8>;
+ virtual-reg = <ef600400>;
+ clock-frequency = <0>;
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ UART2: serial@ef600500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600500 8>;
+ virtual-reg = <ef600500>;
+ clock-frequency = <0>;
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <3 4>;
+ status = "disabled";
+ };
+
+ UART3: serial@ef600600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600600 8>;
+ virtual-reg = <ef600600>;
+ clock-frequency = <0>;
+ current-speed = <0>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <4 4>;
+ status = "disabled";
+ };
+
+ IIC0: i2c@ef600700 {
+ compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
+ reg = <ef600700 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600800 {
+ compatible = "ibm,iic-440ep", "ibm,iic-440gp", "ibm,iic";
+ reg = <ef600800 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <7 4>;
+ };
+
+ spi@ef600900 {
+ compatible = "amcc,spi-440ep";
+ reg = <ef600900 6>;
+ interrupts = <8 4>;
+ interrupt-parent = <&UIC0>;
+ };
+
+ ZMII0: emac-zmii@ef600d00 {
+ compatible = "ibm,zmii-440ep", "ibm,zmii-440gp", "ibm,zmii";
+ reg = <ef600d00 c>;
+ };
+
+ EMAC0: ethernet@ef600e00 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-440ep", "ibm,emac-440gp", "ibm,emac";
+ interrupt-parent = <&UIC1>;
+ interrupts = <1c 4 1d 4>;
+ reg = <ef600e00 70>;
+ local-mac-address = [000000000000];
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0 1>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rmii";
+ phy-map = <00000000>;
+ zmii-device = <&ZMII0>;
+ zmii-channel = <0>;
+ };
+
+ EMAC1: ethernet@ef600f00 {
+ linux,network-index = <1>;
+ device_type = "network";
+ compatible = "ibm,emac-440ep", "ibm,emac-440gp", "ibm,emac";
+ interrupt-parent = <&UIC1>;
+ interrupts = <1e 4 1f 4>;
+ reg = <ef600f00 70>;
+ local-mac-address = [000000000000];
+ mal-device = <&MAL0>;
+ mal-tx-channel = <2 3>;
+ mal-rx-channel = <1>;
+ cell-index = <1>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rmii";
+ phy-map = <00000000>;
+ zmii-device = <&ZMII0>;
+ zmii-channel = <1>;
+ };
+
+ usb@ef601000 {
+ compatible = "ohci-be";
+ reg = <ef601000 80>;
+ interrupts = <8 4 9 4>;
+ interrupt-parent = < &UIC1 >;
+ };
+ };
+
+ PCI0: pci@ec000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb440ep-pci", "ibm,plb-pci";
+ primary;
+ reg = <0 eec00000 8 /* Config space access */
+ 0 eed00000 4 /* IACK */
+ 0 eed00000 4 /* Special cycle */
+ 0 ef400000 40>; /* Internal registers */
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed. Chip supports a second
+ * IO range but we don't use it for now
+ */
+ ranges = <02000000 0 a0000000 0 a0000000 0 20000000
+ 01000000 0 00000000 0 e8000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* Bamboo has all 4 IRQ pins tied together per slot */
+ interrupt-map-mask = <f800 0 0 0>;
+ interrupt-map = <
+ /* IDSEL 1 */
+ 0800 0 0 0 &UIC0 1c 8
+
+ /* IDSEL 2 */
+ 1000 0 0 0 &UIC0 1b 8
+
+ /* IDSEL 3 */
+ 1800 0 0 0 &UIC0 1a 8
+
+ /* IDSEL 4 */
+ 2000 0 0 0 &UIC0 19 8
+ >;
+ };
+ };
+
+ chosen {
+ linux,stdout-path = "/plb/opb/serial@ef600300";
+ };
+};
^ permalink raw reply
* [PATCH 0/3] [POWERPC] 4xx: Add support for AMCC 440EP Yosemite board
From: Josh Boyer @ 2008-02-23 22:08 UTC (permalink / raw)
To: linuxppc-dev
This small series of patches adds support for the AMCC 440EP Yosemite
evaluation board. This is the newer evaluation board for PowerPC 440EP
chips, replacing the older Bamboo board.
This is just the initial round of patches, but they are functional.
Also of note is that while all for on-board UARTs are enumerated in the
DTS file, only two of them are usable on the board. The other two have
their "status" property set to disabled. If used in conjunction with
the of_device_is_disabled patches I just sent out, then devices for
those won't be created. This is not required.
josh
^ permalink raw reply
* [PATCH 2/2][POWERPC] Ignore disabled serial ports
From: Josh Boyer @ 2008-02-23 22:00 UTC (permalink / raw)
To: arnd; +Cc: sfr, davem, linuxppc-dev
In-Reply-To: <20080223155823.2c85d829@zod.rchland.ibm.com>
Some SoC chips have multiple serial ports on board. The usability of these
ports can rely on various factors, ranging from pin sharing to unpopulated
connectors. This uses the new of_device_is_disabled function to check for
and ignore disabled UARTs.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
arch/powerpc/kernel/legacy_serial.c | 4 ++++
drivers/serial/of_serial.c | 5 +++++
2 files changed, 9 insertions(+)
--- linux-2.6.orig/drivers/serial/of_serial.c
+++ linux-2.6/drivers/serial/of_serial.c
@@ -72,6 +72,11 @@ static int __devinit of_platform_serial_
int port_type;
int ret;
+ if (of_device_is_disabled(ofdev->node)) {
+ dev_info(&ofdev->dev, "Disabled serial port. Ignored\n");
+ return -ENODEV;
+ }
+
if (of_find_property(ofdev->node, "used-by-rtas", NULL))
return -EBUSY;
--- linux-2.6.orig/arch/powerpc/kernel/legacy_serial.c
+++ linux-2.6/arch/powerpc/kernel/legacy_serial.c
@@ -54,6 +54,10 @@ static int __init add_legacy_port(struct
u32 clock = BASE_BAUD * 16;
int index;
+ /* Check the status property if present. Ignore disabled devices */
+ if (of_device_is_disabled(np))
+ return -1;
+
/* get clock freq. if present */
clk = of_get_property(np, "clock-frequency", NULL);
if (clk && *clk)
^ permalink raw reply
* [PATCH 1/2][OF] Add of_device_is_disabled function
From: Josh Boyer @ 2008-02-23 21:58 UTC (permalink / raw)
To: sfr, davem; +Cc: linuxppc-dev
IEEE 1275 defined a standard "status" property to indicate the operational
status of a device. The property has four possible values: okay, disabled,
fail, fail-xxx. The absence of this property means the operational status
of the device is unknown or okay.
This adds a function called of_device_is_disabled that checks to see if a
node has the status property set to "disabled". This can be quite useful
for devices that may be present but disabled due to pin sharing, etc.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
drivers/of/base.c | 18 ++++++++++++++++++
include/linux/of.h | 1 +
2 files changed, 19 insertions(+)
--- linux-2.6.orig/drivers/of/base.c
+++ linux-2.6/drivers/of/base.c
@@ -117,6 +117,24 @@ int of_device_is_compatible(const struct
EXPORT_SYMBOL(of_device_is_compatible);
/**
+ * of_device_is_disabled - Check if a device's status is disabled
+ * @device: device node to check
+ *
+ * Returns true or false depending on the value of the staus property
+ */
+int of_device_is_disabled(const struct device_node *device)
+{
+ const char *status;
+
+ status = of_get_property(device, "status", NULL);
+ if (status == NULL)
+ return 0;
+
+ return !(strcmp(status, "disabled"));
+}
+EXPORT_SYMBOL(of_device_is_disabled);
+
+/**
* of_get_parent - Get a node's parent if any
* @node: Node to get parent
*
--- linux-2.6.orig/include/linux/of.h
+++ linux-2.6/include/linux/of.h
@@ -62,6 +62,7 @@ extern struct property *of_find_property
int *lenp);
extern int of_device_is_compatible(const struct device_node *device,
const char *);
+extern int of_device_is_disabled(const struct device_node *device);
extern const void *of_get_property(const struct device_node *node,
const char *name,
int *lenp);
^ permalink raw reply
* Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Olof Johansson @ 2008-02-23 21:28 UTC (permalink / raw)
To: Jochen Friedrich
Cc: Jean Delvare, linuxppc-dev list, linux-kernel, Scott Wood, i2c
In-Reply-To: <47BEAF00.50106@scram.de>
On Fri, Feb 22, 2008 at 12:16:16PM +0100, Jochen Friedrich wrote:
> Fortunately, I2c no longer uses numeric device IDs but names. So what are the alternatives?
>
> 1. modify the I2c subsystem to accept OF names additionally to I2c names (proposed by Jon smirl).
Sounds like Jean isn't very excited about this idea..
> 2. record the I2c name in the dts tree, either as seperate tag (like linux,i2c-name="<i2c-name>")
> or as additional compatible entry (like compatible="...", "linux,<i2c-name>").
I have to say no on this one. The device tree is not supposed to know
about how linux uses devices, there are firmwares out there that don't
use DTS for thier device trees, etc.
> 3. use a glue layer with a translation map.
In my opinion this is an OK solution since the same information has to
be added somewhere already anyway -- eiither to the drivers or to this
translation table. It should of course be an abstacted shared table,
preferrably contained under the i2c source directories since several
platforms and architectures might share them.
-Olof
^ permalink raw reply
* [PATCH v2 5/5] [POWERPC] Add 460EX PCIe support to 4xx pci driver
From: Stefan Roese @ 2008-02-23 21:08 UTC (permalink / raw)
To: linuxppc-dev
All this code is needed to properly initialize the 460EX PCIe host
bridge(s). We re-initialize all ports again, even though this has been done
in the bootloader (U-Boot) before. This way we make sure, that we always
run the latest init code in Linux and don't depend on code versions from
U-Boot.
Unfortunately all IBM/AMCC chips currently supported in this PCIe driver need
a different reset-/init-sequence.
Tested on AMCC Canyonlands eval board.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 114 ++++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/ppc4xx_pci.h | 59 +++++++++++++++++++
2 files changed, 173 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 5abfcd1..d183b83 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -527,6 +527,7 @@ static void __init ppc4xx_probe_pcix_bridge(struct device_node *np)
*
* ibm,plb-pciex-440spe
* ibm,plb-pciex-405ex
+ * ibm,plb-pciex-460ex
*
* Anything else will be rejected for now as they are all subtly
* different unfortunately.
@@ -775,6 +776,117 @@ static struct ppc4xx_pciex_hwops ppc440speB_pcie_hwops __initdata =
.setup_utl = ppc440speB_pciex_init_utl,
};
+static int __init ppc460ex_pciex_core_init(struct device_node *np)
+{
+ /* Nothing to do, return 2 ports */
+ return 2;
+}
+
+static int ppc460ex_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
+{
+ u32 val;
+ u32 utlset1;
+
+ if (port->endpoint) {
+ val = PTYPE_LEGACY_ENDPOINT << 20;
+ utlset1 = 0x20222222;
+ } else {
+ val = PTYPE_ROOT_PORT << 20;
+ utlset1 = 0x21222222;
+ }
+
+ if (port->index == 0) {
+ val |= LNKW_X1 << 12;
+ } else {
+ val |= LNKW_X4 << 12;
+ utlset1 |= 0x00101101;
+ }
+
+ mtdcri(SDR0, port->sdr_base + PESDRn_DLPSET, val);
+ mtdcri(SDR0, port->sdr_base + PESDRn_UTLSET1, utlset1);
+ mtdcri(SDR0, port->sdr_base + PESDRn_UTLSET2, 0x01210000);
+
+ switch (port->index) {
+ case 0:
+ mtdcri(SDR0, PESDR0_460EX_L0CDRCTL, 0x00003230);
+ mtdcri(SDR0, PESDR0_460EX_L0DRV, 0x00000136);
+ mtdcri(SDR0, PESDR0_460EX_L0CLK, 0x00000006);
+
+ mtdcri(SDR0, PESDR0_460EX_PHY_CTL_RST,0x10000000);
+ break;
+
+ case 1:
+ mtdcri(SDR0, PESDR1_460EX_L0CDRCTL, 0x00003230);
+ mtdcri(SDR0, PESDR1_460EX_L1CDRCTL, 0x00003230);
+ mtdcri(SDR0, PESDR1_460EX_L2CDRCTL, 0x00003230);
+ mtdcri(SDR0, PESDR1_460EX_L3CDRCTL, 0x00003230);
+ mtdcri(SDR0, PESDR1_460EX_L0DRV, 0x00000136);
+ mtdcri(SDR0, PESDR1_460EX_L1DRV, 0x00000136);
+ mtdcri(SDR0, PESDR1_460EX_L2DRV, 0x00000136);
+ mtdcri(SDR0, PESDR1_460EX_L3DRV, 0x00000136);
+ mtdcri(SDR0, PESDR1_460EX_L0CLK, 0x00000006);
+ mtdcri(SDR0, PESDR1_460EX_L1CLK, 0x00000006);
+ mtdcri(SDR0, PESDR1_460EX_L2CLK, 0x00000006);
+ mtdcri(SDR0, PESDR1_460EX_L3CLK, 0x00000006);
+
+ mtdcri(SDR0, PESDR1_460EX_PHY_CTL_RST,0x10000000);
+ break;
+ }
+
+ mtdcri(SDR0, port->sdr_base + PESDRn_RCSSET,
+ mfdcri(SDR0, port->sdr_base + PESDRn_RCSSET) |
+ (PESDRx_RCSSET_RSTGU | PESDRx_RCSSET_RSTPYN));
+
+ /* Poll for PHY reset */
+ /* XXX FIXME add timeout */
+ switch (port->index) {
+ case 0:
+ while (!(mfdcri(SDR0, PESDR0_460EX_RSTSTA) & 0x1))
+ udelay(10);
+ break;
+ case 1:
+ while (!(mfdcri(SDR0, PESDR1_460EX_RSTSTA) & 0x1))
+ udelay(10);
+ break;
+ }
+
+ mtdcri(SDR0, port->sdr_base + PESDRn_RCSSET,
+ (mfdcri(SDR0, port->sdr_base + PESDRn_RCSSET) &
+ ~(PESDRx_RCSSET_RSTGU | PESDRx_RCSSET_RSTDL)) |
+ PESDRx_RCSSET_RSTPYN);
+
+ port->has_ibpre = 1;
+
+ return 0;
+}
+
+static int ppc460ex_pciex_init_utl(struct ppc4xx_pciex_port *port)
+{
+ dcr_write(port->dcrs, DCRO_PEGPL_SPECIAL, 0x0);
+
+ /*
+ * Set buffer allocations and then assert VRB and TXE.
+ */
+ out_be32(port->utl_base + PEUTL_PBCTL, 0x0800000c);
+ out_be32(port->utl_base + PEUTL_OUTTR, 0x08000000);
+ out_be32(port->utl_base + PEUTL_INTR, 0x02000000);
+ out_be32(port->utl_base + PEUTL_OPDBSZ, 0x04000000);
+ out_be32(port->utl_base + PEUTL_PBBSZ, 0x00000000);
+ out_be32(port->utl_base + PEUTL_IPHBSZ, 0x02000000);
+ out_be32(port->utl_base + PEUTL_IPDBSZ, 0x04000000);
+ out_be32(port->utl_base + PEUTL_RCIRQEN,0x00f00000);
+ out_be32(port->utl_base + PEUTL_PCTL, 0x80800066);
+
+ return 0;
+}
+
+static struct ppc4xx_pciex_hwops ppc460ex_pcie_hwops __initdata =
+{
+ .core_init = ppc460ex_pciex_core_init,
+ .port_init_hw = ppc460ex_pciex_init_port_hw,
+ .setup_utl = ppc460ex_pciex_init_utl,
+};
+
#endif /* CONFIG_44x */
#ifdef CONFIG_40x
@@ -896,6 +1008,8 @@ static int __init ppc4xx_pciex_check_core_init(struct device_node *np)
else
ppc4xx_pciex_hwops = &ppc440speB_pcie_hwops;
}
+ if (of_device_is_compatible(np, "ibm,plb-pciex-460ex"))
+ ppc4xx_pciex_hwops = &ppc460ex_pcie_hwops;
#endif /* CONFIG_44x */
#ifdef CONFIG_40x
if (of_device_is_compatible(np, "ibm,plb-pciex-405ex"))
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.h b/arch/powerpc/sysdev/ppc4xx_pci.h
index 1c07908..d04e40b 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.h
+++ b/arch/powerpc/sysdev/ppc4xx_pci.h
@@ -271,6 +271,59 @@
#define PESDR1_405EX_PHYSTA 0x044C
/*
+ * 460EX additional DCRs
+ */
+#define PESDR0_460EX_L0BIST 0x0308
+#define PESDR0_460EX_L0BISTSTS 0x0309
+#define PESDR0_460EX_L0CDRCTL 0x030A
+#define PESDR0_460EX_L0DRV 0x030B
+#define PESDR0_460EX_L0REC 0x030C
+#define PESDR0_460EX_L0LPB 0x030D
+#define PESDR0_460EX_L0CLK 0x030E
+#define PESDR0_460EX_PHY_CTL_RST 0x030F
+#define PESDR0_460EX_RSTSTA 0x0310
+#define PESDR0_460EX_OBS 0x0311
+#define PESDR0_460EX_L0ERRC 0x0320
+
+#define PESDR1_460EX_L0BIST 0x0348
+#define PESDR1_460EX_L1BIST 0x0349
+#define PESDR1_460EX_L2BIST 0x034A
+#define PESDR1_460EX_L3BIST 0x034B
+#define PESDR1_460EX_L0BISTSTS 0x034C
+#define PESDR1_460EX_L1BISTSTS 0x034D
+#define PESDR1_460EX_L2BISTSTS 0x034E
+#define PESDR1_460EX_L3BISTSTS 0x034F
+#define PESDR1_460EX_L0CDRCTL 0x0350
+#define PESDR1_460EX_L1CDRCTL 0x0351
+#define PESDR1_460EX_L2CDRCTL 0x0352
+#define PESDR1_460EX_L3CDRCTL 0x0353
+#define PESDR1_460EX_L0DRV 0x0354
+#define PESDR1_460EX_L1DRV 0x0355
+#define PESDR1_460EX_L2DRV 0x0356
+#define PESDR1_460EX_L3DRV 0x0357
+#define PESDR1_460EX_L0REC 0x0358
+#define PESDR1_460EX_L1REC 0x0359
+#define PESDR1_460EX_L2REC 0x035A
+#define PESDR1_460EX_L3REC 0x035B
+#define PESDR1_460EX_L0LPB 0x035C
+#define PESDR1_460EX_L1LPB 0x035D
+#define PESDR1_460EX_L2LPB 0x035E
+#define PESDR1_460EX_L3LPB 0x035F
+#define PESDR1_460EX_L0CLK 0x0360
+#define PESDR1_460EX_L1CLK 0x0361
+#define PESDR1_460EX_L2CLK 0x0362
+#define PESDR1_460EX_L3CLK 0x0363
+#define PESDR1_460EX_PHY_CTL_RST 0x0364
+#define PESDR1_460EX_RSTSTA 0x0365
+#define PESDR1_460EX_OBS 0x0366
+#define PESDR1_460EX_L0ERRC 0x0368
+#define PESDR1_460EX_L1ERRC 0x0369
+#define PESDR1_460EX_L2ERRC 0x036A
+#define PESDR1_460EX_L3ERRC 0x036B
+#define PESDR0_460EX_IHS1 0x036C
+#define PESDR0_460EX_IHS2 0x036D
+
+/*
* Of the above, some are common offsets from the base
*/
#define PESDRn_UTLSET1 0x00
@@ -353,6 +406,12 @@
#define PECFG_POM2LAL 0x390
#define PECFG_POM2LAH 0x394
+/* SDR Bit Mappings */
+#define PESDRx_RCSSET_HLDPLB 0x10000000
+#define PESDRx_RCSSET_RSTGU 0x01000000
+#define PESDRx_RCSSET_RDY 0x00100000
+#define PESDRx_RCSSET_RSTDL 0x00010000
+#define PESDRx_RCSSET_RSTPYN 0x00001000
enum
{
--
1.5.4.2
^ permalink raw reply related
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