* [PATCH 02/17] Add RapidIO option to kernel configuration.
From: Zhang Wei @ 2008-03-11 9:07 UTC (permalink / raw)
To: mporter, akpm, galak; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1205226478-7641-1-git-send-email-wei.zhang@freescale.com>
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
---
arch/powerpc/Kconfig | 13 +++++++++++++
arch/powerpc/platforms/86xx/Kconfig | 1 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 1189d8d..88f8b6c 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -560,6 +560,19 @@ source "drivers/pcmcia/Kconfig"
source "drivers/pci/hotplug/Kconfig"
+config HAS_RAPIDIO
+ bool
+ default n
+
+config RAPIDIO
+ bool "RapidIO support"
+ depends on HAS_RAPIDIO
+ help
+ If you say Y here, the kernel will include drivers and
+ infrastructure code to support RapidIO interconnect devices.
+
+source "drivers/rapidio/Kconfig"
+
endmenu
menu "Advanced setup"
diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig
index 21d1135..8c7c5ff 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -8,6 +8,7 @@ config MPC8641_HPCN
select PPC_I8259
select DEFAULT_UIMAGE
select FSL_ULI1575
+ select HAS_RAPIDIO
help
This option enables support for the MPC8641 HPCN board.
--
1.5.4
^ permalink raw reply related
* [PATCH 01/17] Change RIO function mpc85xx_ to fsl_ .
From: Zhang Wei @ 2008-03-11 9:07 UTC (permalink / raw)
To: mporter, akpm, galak; +Cc: linuxppc-dev, linux-kernel
The driver is also fit for Freescale MPC8641 processor.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
---
arch/powerpc/sysdev/fsl_rio.c | 80 ++++++++++++++++++++--------------------
1 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index af2425e..659a560 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -1,5 +1,5 @@
/*
- * MPC85xx RapidIO support
+ * Freescale MPC85xx/MPC86xx RapidIO support
*
* Copyright 2005 MontaVista Software, Inc.
* Matt Porter <mporter@kernel.crashing.org>
@@ -145,7 +145,7 @@ static struct rio_msg_rx_ring {
} msg_rx_ring;
/**
- * mpc85xx_rio_doorbell_send - Send a MPC85xx doorbell message
+ * fsl_rio_doorbell_send - Send a MPC85xx doorbell message
* @index: ID of RapidIO interface
* @destid: Destination ID of target device
* @data: 16-bit info field of RapidIO doorbell message
@@ -153,9 +153,9 @@ static struct rio_msg_rx_ring {
* Sends a MPC85xx doorbell message. Returns %0 on success or
* %-EINVAL on failure.
*/
-static int mpc85xx_rio_doorbell_send(int index, u16 destid, u16 data)
+static int fsl_rio_doorbell_send(int index, u16 destid, u16 data)
{
- pr_debug("mpc85xx_doorbell_send: index %d destid %4.4x data %4.4x\n",
+ pr_debug("fsl_doorbell_send: index %d destid %4.4x data %4.4x\n",
index, destid, data);
out_be32((void *)&dbell_atmu_regs->rowtar, destid << 22);
out_be16((void *)(dbell_win), data);
@@ -164,7 +164,7 @@ static int mpc85xx_rio_doorbell_send(int index, u16 destid, u16 data)
}
/**
- * mpc85xx_local_config_read - Generate a MPC85xx local config space read
+ * fsl_local_config_read - Generate a MPC85xx local config space read
* @index: ID of RapdiIO interface
* @offset: Offset into configuration space
* @len: Length (in bytes) of the maintenance transaction
@@ -173,9 +173,9 @@ static int mpc85xx_rio_doorbell_send(int index, u16 destid, u16 data)
* Generates a MPC85xx local configuration space read. Returns %0 on
* success or %-EINVAL on failure.
*/
-static int mpc85xx_local_config_read(int index, u32 offset, int len, u32 * data)
+static int fsl_local_config_read(int index, u32 offset, int len, u32 *data)
{
- pr_debug("mpc85xx_local_config_read: index %d offset %8.8x\n", index,
+ pr_debug("fsl_local_config_read: index %d offset %8.8x\n", index,
offset);
*data = in_be32((void *)(regs_win + offset));
@@ -183,7 +183,7 @@ static int mpc85xx_local_config_read(int index, u32 offset, int len, u32 * data)
}
/**
- * mpc85xx_local_config_write - Generate a MPC85xx local config space write
+ * fsl_local_config_write - Generate a MPC85xx local config space write
* @index: ID of RapdiIO interface
* @offset: Offset into configuration space
* @len: Length (in bytes) of the maintenance transaction
@@ -192,10 +192,10 @@ static int mpc85xx_local_config_read(int index, u32 offset, int len, u32 * data)
* Generates a MPC85xx local configuration space write. Returns %0 on
* success or %-EINVAL on failure.
*/
-static int mpc85xx_local_config_write(int index, u32 offset, int len, u32 data)
+static int fsl_local_config_write(int index, u32 offset, int len, u32 data)
{
pr_debug
- ("mpc85xx_local_config_write: index %d offset %8.8x data %8.8x\n",
+ ("fsl_local_config_write: index %d offset %8.8x data %8.8x\n",
index, offset, data);
out_be32((void *)(regs_win + offset), data);
@@ -203,7 +203,7 @@ static int mpc85xx_local_config_write(int index, u32 offset, int len, u32 data)
}
/**
- * mpc85xx_rio_config_read - Generate a MPC85xx read maintenance transaction
+ * fsl_rio_config_read - Generate a MPC85xx read maintenance transaction
* @index: ID of RapdiIO interface
* @destid: Destination ID of transaction
* @hopcount: Number of hops to target device
@@ -215,13 +215,13 @@ static int mpc85xx_local_config_write(int index, u32 offset, int len, u32 data)
* success or %-EINVAL on failure.
*/
static int
-mpc85xx_rio_config_read(int index, u16 destid, u8 hopcount, u32 offset, int len,
+fsl_rio_config_read(int index, u16 destid, u8 hopcount, u32 offset, int len,
u32 * val)
{
u8 *data;
pr_debug
- ("mpc85xx_rio_config_read: index %d destid %d hopcount %d offset %8.8x len %d\n",
+ ("fsl_rio_config_read: index %d destid %d hopcount %d offset %8.8x len %d\n",
index, destid, hopcount, offset, len);
out_be32((void *)&maint_atmu_regs->rowtar,
(destid << 22) | (hopcount << 12) | ((offset & ~0x3) >> 9));
@@ -243,7 +243,7 @@ mpc85xx_rio_config_read(int index, u16 destid, u8 hopcount, u32 offset, int len,
}
/**
- * mpc85xx_rio_config_write - Generate a MPC85xx write maintenance transaction
+ * fsl_rio_config_write - Generate a MPC85xx write maintenance transaction
* @index: ID of RapdiIO interface
* @destid: Destination ID of transaction
* @hopcount: Number of hops to target device
@@ -255,12 +255,12 @@ mpc85xx_rio_config_read(int index, u16 destid, u8 hopcount, u32 offset, int len,
* success or %-EINVAL on failure.
*/
static int
-mpc85xx_rio_config_write(int index, u16 destid, u8 hopcount, u32 offset,
+fsl_rio_config_write(int index, u16 destid, u8 hopcount, u32 offset,
int len, u32 val)
{
u8 *data;
pr_debug
- ("mpc85xx_rio_config_write: index %d destid %d hopcount %d offset %8.8x len %d val %8.8x\n",
+ ("fsl_rio_config_write: index %d destid %d hopcount %d offset %8.8x len %d val %8.8x\n",
index, destid, hopcount, offset, len, val);
out_be32((void *)&maint_atmu_regs->rowtar,
(destid << 22) | (hopcount << 12) | ((offset & ~0x3) >> 9));
@@ -344,7 +344,7 @@ rio_hw_add_outb_message(struct rio_mport *mport, struct rio_dev *rdev, int mbox,
EXPORT_SYMBOL_GPL(rio_hw_add_outb_message);
/**
- * mpc85xx_rio_tx_handler - MPC85xx outbound message interrupt handler
+ * fsl_rio_tx_handler - MPC85xx outbound message interrupt handler
* @irq: Linux interrupt number
* @dev_instance: Pointer to interrupt-specific data
*
@@ -352,7 +352,7 @@ EXPORT_SYMBOL_GPL(rio_hw_add_outb_message);
* mailbox event handler and acks the interrupt occurrence.
*/
static irqreturn_t
-mpc85xx_rio_tx_handler(int irq, void *dev_instance)
+fsl_rio_tx_handler(int irq, void *dev_instance)
{
int osr;
struct rio_mport *port = (struct rio_mport *)dev_instance;
@@ -452,7 +452,7 @@ int rio_open_outb_mbox(struct rio_mport *mport, void *dev_id, int mbox, int entr
/* Hook up outbound message handler */
if ((rc =
- request_irq(MPC85xx_IRQ_RIO_TX, mpc85xx_rio_tx_handler, 0,
+ request_irq(MPC85xx_IRQ_RIO_TX, fsl_rio_tx_handler, 0,
"msg_tx", (void *)mport)) < 0)
goto out_irq;
@@ -511,7 +511,7 @@ void rio_close_outb_mbox(struct rio_mport *mport, int mbox)
}
/**
- * mpc85xx_rio_rx_handler - MPC85xx inbound message interrupt handler
+ * fsl_rio_rx_handler - MPC85xx inbound message interrupt handler
* @irq: Linux interrupt number
* @dev_instance: Pointer to interrupt-specific data
*
@@ -519,7 +519,7 @@ void rio_close_outb_mbox(struct rio_mport *mport, int mbox)
* mailbox event handler and acks the interrupt occurrence.
*/
static irqreturn_t
-mpc85xx_rio_rx_handler(int irq, void *dev_instance)
+fsl_rio_rx_handler(int irq, void *dev_instance)
{
int isr;
struct rio_mport *port = (struct rio_mport *)dev_instance;
@@ -597,7 +597,7 @@ int rio_open_inb_mbox(struct rio_mport *mport, void *dev_id, int mbox, int entri
/* Hook up inbound message handler */
if ((rc =
- request_irq(MPC85xx_IRQ_RIO_RX, mpc85xx_rio_rx_handler, 0,
+ request_irq(MPC85xx_IRQ_RIO_RX, fsl_rio_rx_handler, 0,
"msg_rx", (void *)mport)) < 0) {
dma_free_coherent(NULL, RIO_MSG_BUFFER_SIZE,
msg_tx_ring.virt_buffer[i],
@@ -729,7 +729,7 @@ void *rio_hw_get_inb_message(struct rio_mport *mport, int mbox)
EXPORT_SYMBOL_GPL(rio_hw_get_inb_message);
/**
- * mpc85xx_rio_dbell_handler - MPC85xx doorbell interrupt handler
+ * fsl_rio_dbell_handler - MPC85xx doorbell interrupt handler
* @irq: Linux interrupt number
* @dev_instance: Pointer to interrupt-specific data
*
@@ -737,7 +737,7 @@ EXPORT_SYMBOL_GPL(rio_hw_get_inb_message);
* doorbell event handlers and executes a matching event handler.
*/
static irqreturn_t
-mpc85xx_rio_dbell_handler(int irq, void *dev_instance)
+fsl_rio_dbell_handler(int irq, void *dev_instance)
{
int dsr;
struct rio_mport *port = (struct rio_mport *)dev_instance;
@@ -794,14 +794,14 @@ mpc85xx_rio_dbell_handler(int irq, void *dev_instance)
}
/**
- * mpc85xx_rio_doorbell_init - MPC85xx doorbell interface init
+ * fsl_rio_doorbell_init - MPC85xx doorbell interface init
* @mport: Master port implementing the inbound doorbell unit
*
* Initializes doorbell unit hardware and inbound DMA buffer
- * ring. Called from mpc85xx_rio_setup(). Returns %0 on success
+ * ring. Called from fsl_rio_setup(). Returns %0 on success
* or %-ENOMEM on failure.
*/
-static int mpc85xx_rio_doorbell_init(struct rio_mport *mport)
+static int fsl_rio_doorbell_init(struct rio_mport *mport)
{
int rc = 0;
@@ -835,7 +835,7 @@ static int mpc85xx_rio_doorbell_init(struct rio_mport *mport)
/* Hook up doorbell handler */
if ((rc =
- request_irq(MPC85xx_IRQ_RIO_BELL, mpc85xx_rio_dbell_handler, 0,
+ request_irq(MPC85xx_IRQ_RIO_BELL, fsl_rio_dbell_handler, 0,
"dbell_rx", (void *)mport) < 0)) {
iounmap((void *)dbell_win);
dma_free_coherent(NULL, 512 * DOORBELL_MESSAGE_SIZE,
@@ -854,7 +854,7 @@ static int mpc85xx_rio_doorbell_init(struct rio_mport *mport)
static char *cmdline = NULL;
-static int mpc85xx_rio_get_hdid(int index)
+static int fsl_rio_get_hdid(int index)
{
/* XXX Need to parse multiple entries in some format */
if (!cmdline)
@@ -863,7 +863,7 @@ static int mpc85xx_rio_get_hdid(int index)
return simple_strtol(cmdline, NULL, 0);
}
-static int mpc85xx_rio_get_cmdline(char *s)
+static int fsl_rio_get_cmdline(char *s)
{
if (!s)
return 0;
@@ -872,10 +872,10 @@ static int mpc85xx_rio_get_cmdline(char *s)
return 1;
}
-__setup("riohdid=", mpc85xx_rio_get_cmdline);
+__setup("riohdid=", fsl_rio_get_cmdline);
/**
- * mpc85xx_rio_setup - Setup MPC85xx RapidIO interface
+ * fsl_rio_setup - Setup MPC85xx RapidIO interface
* @law_start: Starting physical address of RapidIO LAW
* @law_size: Size of RapidIO LAW
*
@@ -883,17 +883,17 @@ __setup("riohdid=", mpc85xx_rio_get_cmdline);
* master port with system-specific info, and registers the
* master port with the RapidIO subsystem.
*/
-void mpc85xx_rio_setup(int law_start, int law_size)
+void fsl_rio_setup(int law_start, int law_size)
{
struct rio_ops *ops;
struct rio_mport *port;
ops = kmalloc(sizeof(struct rio_ops), GFP_KERNEL);
- ops->lcread = mpc85xx_local_config_read;
- ops->lcwrite = mpc85xx_local_config_write;
- ops->cread = mpc85xx_rio_config_read;
- ops->cwrite = mpc85xx_rio_config_write;
- ops->dsend = mpc85xx_rio_doorbell_send;
+ ops->lcread = fsl_local_config_read;
+ ops->lcwrite = fsl_local_config_write;
+ ops->cread = fsl_rio_config_read;
+ ops->cwrite = fsl_rio_config_write;
+ ops->dsend = fsl_rio_doorbell_send;
port = kmalloc(sizeof(struct rio_mport), GFP_KERNEL);
port->id = 0;
@@ -909,7 +909,7 @@ void mpc85xx_rio_setup(int law_start, int law_size)
strcpy(port->name, "RIO0 mport");
port->ops = ops;
- port->host_deviceid = mpc85xx_rio_get_hdid(port->id);
+ port->host_deviceid = fsl_rio_get_hdid(port->id);
rio_register_mport(port);
@@ -928,5 +928,5 @@ void mpc85xx_rio_setup(int law_start, int law_size)
/* Configure outbound doorbell window */
out_be32((void *)&dbell_atmu_regs->rowbar, 0x000c0400);
out_be32((void *)&dbell_atmu_regs->rowar, 0x8004200b);
- mpc85xx_rio_doorbell_init(port);
+ fsl_rio_doorbell_init(port);
}
--
1.5.4
^ permalink raw reply related
* RE: [PATCH 11/17] Add memory mapping driver to RapidIO.
From: Zhang Wei @ 2008-03-11 8:53 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080305135148.21d6c25a.sfr@canb.auug.org.au>
Hi, Stephen,
I've updated those patches with fixing up.
Thanks!=20
Wei.
> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr@canb.auug.org.au]=20
> Sent: Wednesday, March 05, 2008 10:52 AM
> To: Zhang Wei
> Cc: linuxppc-dev@ozlabs.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 11/17] Add memory mapping driver to RapidIO.
>=20
> Hi Weu,
>=20
> On Wed, 5 Mar 2008 09:59:38 +0800 "Zhang Wei"=20
> <Wei.Zhang@freescale.com> wrote:
> >
> > Thanks! I'm considering to commit a updated patch or new=20
> code cleaning
> > patch.
> > How about your idea?
>=20
> Preferably, fix up the patches. If that is a pain, then a=20
> followup patch
> that cleans up is ok as these do not affect the correctness=20
> of the code.
>=20
> --=20
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>=20
^ permalink raw reply
* I2C device node on Sequoia (440EPx)
From: Vaupotic Marko @ 2008-03-11 7:50 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 573 bytes --]
Hi
I am using an AMCC 440EPx processor on "Sequoia" board with Linux 2.6.21
rc4. I am trying to use the i2c in the user-space
In my Linux config file (Sequoia default) I have:
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
I than added the "i2c-0" device in /dev (# mknod i2c-0 c 89 0)
When I run a simple program to open the device (provided by the
"dev-interface" file of i2c kernel documentation) it returns errno message:
"No such device".
I have tried to use the device number 1, 2, 3, 4 but with no luck.
Any suggestions what I might be doing wrong?
Best Regards
Marko
[-- Attachment #2: Type: text/html, Size: 1305 bytes --]
^ permalink raw reply
* Re: [PATCH] pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
From: Andrew Morton @ 2008-03-11 7:06 UTC (permalink / raw)
To: Olof Johansson
Cc: hskinnemoen, shannon.nelson, linux-kernel, linuxppc-dev,
pasemi-linux, dan.j.williams
In-Reply-To: <20080306233900.GA3969@lixom.net>
On Thu, 6 Mar 2008 17:39:00 -0600 Olof Johansson <olof@lixom.net> wrote:
> pasemi_dma: Driver for PA Semi PWRficient on-chip DMA engine
>
> First cut at a dma copy offload driver for PA Semi PWRficient. It uses the
> platform-specific functions to allocate channels, etc.
Applied this on Paul's latest and powerpc allmodconfig goes boom.
drivers/dma/pasemi_dma.c: In function `pasemi_dma_alloc_chan_resources':
drivers/dma/pasemi_dma.c:152: error: `PAS_DMA_TXCHAN_CFG_TY_COPY' undeclared (first use in this function)
drivers/dma/pasemi_dma.c:152: error: (Each undeclared identifier is reported only once
drivers/dma/pasemi_dma.c:152: error: for each function it appears in.)
drivers/dma/pasemi_dma.c:154: error: `PAS_DMA_TXCHAN_CFG_LPDQ' undeclared (first use in this function)
drivers/dma/pasemi_dma.c:155: error: `PAS_DMA_TXCHAN_CFG_LPSQ' undeclared (first use in this function)
drivers/dma/pasemi_dma.c: In function `pasemi_dma_probe':
drivers/dma/pasemi_dma.c:394: error: structure has no member named `device_dependency_added'
Also this driver from git-md-accel is pretty sick:
drivers/dma/fsldma.c:439: warning: comparison of distinct pointer types lacks a cast
drivers/dma/fsldma.c: In function `fsl_chan_xfer_ld_queue':
drivers/dma/fsldma.c:584: warning: long long unsigned int format, dma_addr_t arg (arg 4)
drivers/dma/fsldma.c: In function `fsl_dma_chan_do_interrupt':
drivers/dma/fsldma.c:661: warning: unsigned int format, different type arg (arg 5)
drivers/dma/fsldma.c:677: warning: long long unsigned int format, dma_addr_t arg (arg 4)
drivers/dma/fsldma.c:677: warning: long long unsigned int format, dma_addr_t arg (arg 5)
drivers/dma/fsldma.c:694: warning: unsigned int format, different type arg (arg 4)
drivers/dma/fsldma.c: In function `fsl_dma_self_test':
drivers/dma/fsldma.c:833: warning: int format, different type arg (arg 5)
drivers/dma/fsldma.c: In function `of_fsl_dma_probe':
drivers/dma/fsldma.c:1003: warning: unsigned int format, different type arg (arg 5)
drivers/dma/fsldma.c: At top level:
drivers/dma/fsldma.c:723: warning: 'fsl_dma_callback_test' defined but not used
^ permalink raw reply
* Re: [PATCH 8/8] pseries: phyp dump: config file
From: Paul Mackerras @ 2008-03-11 6:21 UTC (permalink / raw)
To: Manish Ahuja; +Cc: linuxppc-dev, linasvepstas, mahuja
In-Reply-To: <47C7533D.9040002@austin.ibm.com>
Manish Ahuja writes:
> +config PHYP_DUMP
> + bool "Hypervisor-assisted dump (EXPERIMENTAL)"
> + depends on PPC_PSERIES && EXPERIMENTAL
> + default y
I think this should default to n for now (i.e. leave out the default
line entirely). We can make it default to y later.
Paul.
^ permalink raw reply
* Re: [PATCH 6/8] pseries: phyp dump: Invalidate and print dump areas.
From: Paul Mackerras @ 2008-03-11 6:19 UTC (permalink / raw)
To: Manish Ahuja; +Cc: linuxppc-dev, linasvepstas, mahuja
In-Reply-To: <47C75292.6000705@austin.ibm.com>
Manish Ahuja writes:
> -static void
> -release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
> +static
> +void release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
This change looks rather pointless. If you have to change it, I'd
prefer:
static void release_memory_range(unsigned long start_pfn,
unsigned long nr_pages)
Paul.
^ permalink raw reply
* Re: [PATCH 4/8] pseries: phyp dump: register dump area.
From: Paul Mackerras @ 2008-03-11 6:17 UTC (permalink / raw)
To: Manish Ahuja; +Cc: linuxppc-dev, linasvepstas, mahuja
In-Reply-To: <47C751F1.5040505@austin.ibm.com>
Manish Ahuja writes:
> +#define NUM_DUMP_SECTIONS 3
> +#define DUMP_HEADER_VERSION 0x1
> +#define DUMP_REQUEST_FLAG 0x1
> +#define DUMP_SOURCE_CPU 0x0001
> +#define DUMP_SOURCE_HPTE 0x0002
> +#define DUMP_SOURCE_RMO 0x0011
I think it would be clearer if you use a tab to line up the values,
like this:
#define NUM_DUMP_SECTIONS 3
#define DUMP_HEADER_VERSION 0x1
#define DUMP_REQUEST_FLAG 0x1
#define DUMP_SOURCE_CPU 0x0001
#define DUMP_SOURCE_HPTE 0x0002
#define DUMP_SOURCE_RMO 0x0011
Paul.
^ permalink raw reply
* Re: [PATCH 3/8] pseries: phyp dump: use sysfs to release reserved mem
From: Paul Mackerras @ 2008-03-11 6:16 UTC (permalink / raw)
To: Manish Ahuja; +Cc: linuxppc-dev, linasvepstas, mahuja
In-Reply-To: <47C75189.4070801@austin.ibm.com>
Manish Ahuja writes:
> Check to see if there actually is data from a previously
> crashed kernel waiting. If so, Allow user-sapce tools to
> grab the data (by reading /proc/kcore). When user-space
> finishes dumping a section, it must release that memory
> by writing to sysfs. For example,
>
> echo "0x40000000 0x10000000" > /sys/kernel/release_region
>
> will release 256MB starting at the 1GB. The released memory
> becomes free for general use.
>
> Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
> Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
>
> ------
This line needs to be exactly 3 dashes, because otherwise the tools
include the diffstat into the commit message. Putting 4 or more
dashes was an annoying habit Linas had, and it means I have to fix it
manually (usually after I have committed the patches, and then notice
that the commit message has the extra stuff in it, so I have to go
back and fix the separators, reset my tree and re-commit the patches.)
> + dump_header = of_get_property(rtas, "ibm,kernel-dump",
> + &header_len);
This is a somewhat weird-looking way of coping with too-long lines.
Please indent the second line either one more tab than the first line,
or else so that it starts just after the '(' in the first line (which
is what emacs will do by default). The same comment applies in
several other places.
Paul.
^ permalink raw reply
* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Paul Mackerras @ 2008-03-11 6:12 UTC (permalink / raw)
To: Manish Ahuja; +Cc: linuxppc-dev, linasvepstas, mahuja
In-Reply-To: <47C750CE.7050202@austin.ibm.com>
Manish Ahuja writes:
> +#else /* CONFIG_PHYP_DUMP */
> +int early_init_dt_scan_phyp_dump(unsigned long node,
> + const char *uname, int depth, void *data) { return 0; }
This shouldn't be in the header file. Either put it in prom.c (and
make it return 1 so the of_scan_flat_dt call doesn't have to go
through the entire device tree), or put #ifdef CONFIG_PHYP_DUMP around
the of_scan_flat_dt call itself.
> +/* Global, used to communicate data between early boot and late boot */
> +static struct phyp_dump phyp_dump_global;
> +struct phyp_dump *phyp_dump_info = &phyp_dump_global;
It's a little weird to have a static variable with global in its name.
> +int __init early_init_dt_scan_phyp_dump(unsigned long node,
> + const char *uname, int depth, void *data)
> +{
> +#ifdef CONFIG_PHYP_DUMP
This is in phyp_dump.c, which only gets compiled if CONFIG_PHYP_DUMP
is set, so you don't need this ifdef.
Paul.
^ permalink raw reply
* [PATCH] [POWERPC] Remove Kconfig option BOOT_LOAD
From: Kumar Gala @ 2008-03-11 5:00 UTC (permalink / raw)
To: linuxppc-dev
Nothing appears to use BOOT_LOAD so remove it as a configurable option.
---
in my powerpc-next branch.
- k
arch/powerpc/Kconfig | 16 ----------------
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e4e13e0..803415e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -663,22 +663,6 @@ config CONSISTENT_SIZE
hex "Size of consistent memory pool" if CONSISTENT_SIZE_BOOL
default "0x00200000" if NOT_COHERENT_CACHE
-config BOOT_LOAD_BOOL
- bool "Set the boot link/load address"
- depends on ADVANCED_OPTIONS && !PPC_MULTIPLATFORM
- help
- This option allows you to set the initial load address of the zImage
- or zImage.initrd file. This can be useful if you are on a board
- which has a small amount of memory.
-
- Say N here unless you know what you are doing.
-
-config BOOT_LOAD
- hex "Link/load address for booting" if BOOT_LOAD_BOOL
- default "0x00400000" if 40x || 8xx || 8260
- default "0x01000000" if 44x
- default "0x00800000"
-
config PIN_TLB
bool "Pinned Kernel TLBs (860 ONLY)"
depends on ADVANCED_OPTIONS && 8xx
--
1.5.4.1
^ permalink raw reply related
* Re: [PATCH] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Kumar Gala @ 2008-03-11 4:19 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080311003705.GH11559@localhost.localdomain>
On Mar 10, 2008, at 7:37 PM, David Gibson wrote:
> On Fri, Mar 07, 2008 at 10:55:51AM -0600, Kumar Gala wrote:
>> Normally we assume kernel images will be loaded at offset 0. However
>> there are situations, like when the kernel itself is running at a
>> non-zero
>> physical address, that we don't want to load it at 0.
>>
>> Allow the wrapper to take an offset. We use this when building u-
>> boot images.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> Hrm. It concerns me that with the patch as it stands,
> CONFIG_MEMORY_START looks like a fairly universal option, but it will
> only be respected on u-boot platforms (and only new u-boot, not cuboot
> at that).
Nothing stops anyone from submitting patches that makes it work for
other platforms. CONFIG_MEMORY_START is only of utility on book-e
class machines at this point and from a Freescale point of view that's
85xx and thus means u-boot. IBM, AMCC, or a random Joe is free to
submit patches to make it work on 44x. :)
- k
^ permalink raw reply
* The question about the QUICC ENGINE microcode for freescale PowerPC?
From: 郭劲 @ 2008-03-11 1:31 UTC (permalink / raw)
To: linuxppc-embedded
Hi,friends,
I want to realize the high speed TCP package on GETH of MPC8360E,I would like the
speed on both UCC1 and UCC2 for both send and receive TCP package(big package) up
to 1000M bits/sec, so the total internet speed is 4000M bits/sec for MPC8360E.
I tested the internet performance by IPERF test software with the condition that
the core cpu deal with the TCP package,without microcode. I config the UCC2 down,
config UCC1 to send package out to an server PC,no receive,the speed for UCC1 just
only sending package is about 300M bits/sec, and CPU is 100% used. This speed is
so slow, is too slow. If I send and recieve at the same time, the speed is much
slower, if I make the UCC2 up, the speed is much slower and slower.
I do not know how to incrase the internet speed for MPC8360E, somebody told me, we
must use the microcode for QUICC ENGINE.
My question is that where can I download the microcode for QUICC ENGINE and how to
use it? Whether or not this microcode can help me to realize the 4000M bits/sec
for TCP package?
^ permalink raw reply
* Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
From: David Gibson @ 2008-03-11 1:32 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Li Yang, paulus
In-Reply-To: <200803110143.50561.arnd@arndb.de>
On Tue, Mar 11, 2008 at 01:43:49AM +0100, Arnd Bergmann wrote:
> On Tuesday 11 March 2008, David Gibson wrote:
> > On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote:
> > > > This isn't a problem with this device tree, but it's probably time we
> > > > started establishing some conventional generic names for nand flash
> > > > and board-control devices.
> > > >
> > > > So, to start the ball rolling, I've seen several names for nand flash
> > > > nodes, I'd suggest we standardise on "nand-flash".
> > >
> > > What's wrong with the already well-established generic name "flash"?
> >
> > I was concerned that using "flash" for both NOR flash (which it
> > already is) and NAND flash might be unwise. I am quite open to being
> > convinced otherwise, though.
>
> One argument for just using "flash" is that there are much finer differences
> than just "NAND" and "NOR", with at least "dataflash", "OneNAND", "SD/MMC"
> being further types of flash that don't fit the categories exactly, though
> each one for different reasons.
>
> For SD/MMC, there are good reasons to use something completely different,
> for the others, calling them all "flash" sounds better than fitting them
> into "nand" and "nor".
Ok, I'm convinced. "flash" it is.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Michael Ellerman @ 2008-03-11 1:02 UTC (permalink / raw)
To: Manish Ahuja; +Cc: mahuja, linuxppc-dev, linasvepstas, paulus
In-Reply-To: <47C750CE.7050202@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 6762 bytes --]
On Thu, 2008-02-28 at 18:24 -0600, Manish Ahuja wrote:
> Initial patch for reserving memory in early boot, and freeing it later.
> If the previous boot had ended with a crash, the reserved memory would contain
> a copy of the crashed kernel data.
>
> Signed-off-by: Manish Ahuja <mahuja@us.ibm.com>
> Signed-off-by: Linas Vepstas <linasvepstas@gmail.com>
Hi Manish,
A few comments inline ..
> Index: 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ 2.6.25-rc1/arch/powerpc/platforms/pseries/phyp_dump.c 2008-02-28 21:57:52.000000000 -0600
> @@ -0,0 +1,105 @@
> +/*
> + * Hypervisor-assisted dump
> + *
> + * Linas Vepstas, Manish Ahuja 2008
> + * Copyright 2008 IBM Corp.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + *
> + */
> +
> +#include <linux/init.h>
> +#include <linux/mm.h>
> +#include <linux/pfn.h>
> +#include <linux/swap.h>
> +
> +#include <asm/page.h>
> +#include <asm/phyp_dump.h>
> +#include <asm/machdep.h>
> +#include <asm/prom.h>
> +
> +/* Global, used to communicate data between early boot and late boot */
> +static struct phyp_dump phyp_dump_global;
> +struct phyp_dump *phyp_dump_info = &phyp_dump_global;
I don't see the point of this. You have a static (ie. non-global) struct
called phyp_dump_global, then you create a pointer to it and pass that
around. It could just be:
phyp_dump.h:
extern struct phyp_dump phyp_dump_info;
phyp_dump.c:
struct phyp_dump phyp_dump_info;
phyp_dump_info.foo = bar;
I also think the struct should be called phyp_dump_info, not phyp_dump -
it contains info about phyp_dump, not the dump itself.
> +
> +/**
> + * release_memory_range -- release memory previously lmb_reserved
> + * @start_pfn: starting physical frame number
> + * @nr_pages: number of pages to free.
> + *
> + * This routine will release memory that had been previously
> + * lmb_reserved in early boot. The released memory becomes
> + * available for genreal use.
> + */
> +static void
> +release_memory_range(unsigned long start_pfn, unsigned long nr_pages)
> +{
> + struct page *rpage;
> + unsigned long end_pfn;
> + long i;
> +
> + end_pfn = start_pfn + nr_pages;
> +
> + for (i = start_pfn; i <= end_pfn; i++) {
> + rpage = pfn_to_page(i);
> + if (PageReserved(rpage)) {
> + ClearPageReserved(rpage);
> + init_page_count(rpage);
> + __free_page(rpage);
> + totalram_pages++;
> + }
> + }
> +}
> +
> +static int __init phyp_dump_setup(void)
> +{
> + unsigned long start_pfn, nr_pages;
> +
> + /* If no memory was reserved in early boot, there is nothing to do */
> + if (phyp_dump_info->init_reserve_size == 0)
> + return 0;
> +
> + /* Release memory that was reserved in early boot */
> + start_pfn = PFN_DOWN(phyp_dump_info->init_reserve_start);
> + nr_pages = PFN_DOWN(phyp_dump_info->init_reserve_size);
> + release_memory_range(start_pfn, nr_pages);
> +
> + return 0;
> +}
> +machine_subsys_initcall(pseries, phyp_dump_setup);
> +
> +int __init early_init_dt_scan_phyp_dump(unsigned long node,
> + const char *uname, int depth, void *data)
> +{
> +#ifdef CONFIG_PHYP_DUMP
> + const unsigned int *sizes;
> +
> + phyp_dump_info->phyp_dump_configured = 0;
> + phyp_dump_info->phyp_dump_is_active = 0;
> +
> + if (depth != 1 || strcmp(uname, "rtas") != 0)
> + return 0;
> +
> + if (of_get_flat_dt_prop(node, "ibm,configure-kernel-dump", NULL))
> + phyp_dump_info->phyp_dump_configured++;
> +
> + if (of_get_flat_dt_prop(node, "ibm,dump-kernel", NULL))
> + phyp_dump_info->phyp_dump_is_active++;
> +
> + sizes = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump-sizes",
> + NULL);
> + if (!sizes)
> + return 0;
> +
> + if (sizes[0] == 1)
> + phyp_dump_info->cpu_state_size = *((unsigned long *)&sizes[1]);
> +
> + if (sizes[3] == 2)
> + phyp_dump_info->hpte_region_size =
> + *((unsigned long *)&sizes[4]);
> +#endif
This doesn't need to be inside #ifdef, you have a dummy version already
defined in the header file.
> Index: 2.6.25-rc1/arch/powerpc/kernel/prom.c
> ===================================================================
> --- 2.6.25-rc1.orig/arch/powerpc/kernel/prom.c 2008-02-28 21:54:57.000000000 -0600
> +++ 2.6.25-rc1/arch/powerpc/kernel/prom.c 2008-02-28 21:55:27.000000000 -0600
> @@ -1039,6 +1040,51 @@ static void __init early_reserve_mem(voi
> #endif
> }
>
> +#ifdef CONFIG_PHYP_DUMP
> +/**
> + * reserve_crashed_mem() - reserve all not-yet-dumped mmemory
> + *
> + * This routine may reserve memory regions in the kernel only
> + * if the system is supported and a dump was taken in last
> + * boot instance or if the hardware is supported and the
> + * scratch area needs to be setup. In other instances it returns
> + * without reserving anything. The memory in case of dump being
> + * active is freed when the dump is collected (by userland tools).
> + */
> +static void __init reserve_crashed_mem(void)
This could do with a name change IMO, eg. phyp_dump_reserve_mem() or
something.
> +{
> + unsigned long base, size;
> + if (!phyp_dump_info->phyp_dump_configured) {
> + printk(KERN_ERR "Phyp-dump not supported on this hardware\n");
> + return;
> + }
> +
> + if (phyp_dump_info->phyp_dump_is_active) {
> + /* Reserve *everything* above RMR.Area freed by userland tools*/
> + base = PHYP_DUMP_RMR_END;
> + size = lmb_end_of_DRAM() - base;
> +
> + /* XXX crashed_ram_end is wrong, since it may be beyond
> + * the memory_limit, it will need to be adjusted. */
> + lmb_reserve(base, size);
> +
> + phyp_dump_info->init_reserve_start = base;
> + phyp_dump_info->init_reserve_size = size;
> + } else {
> + size = phyp_dump_info->cpu_state_size +
> + phyp_dump_info->hpte_region_size +
> + PHYP_DUMP_RMR_END;
> + base = lmb_end_of_DRAM() - size;
> + lmb_reserve(base, size);
> + phyp_dump_info->init_reserve_start = base;
> + phyp_dump_info->init_reserve_size = size;
> + }
> +}
> +#else
> +static inline void __init reserve_crashed_mem(void) {}
> +#endif /* CONFIG_PHYP_DUMP && CONFIG_PPC_RTAS */
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: David Gibson @ 2008-03-11 0:45 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev, linux-mtd, ben
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B0418505E@ismail.innsys.innovsys.com>
On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:
> linuxppc-dev-bounces+runet=innovsys.com@ozlabs.org wrote:
> > Hi everybody,
> >
> > as part of a ARCH=ppc to ARCH=powerpc migration process, I'm
> > looking for an
> > OpenFirmware compatible way to handle a RAM-based MTD device.
> >
> > On the platform_device based ppc architecture, the
> > drivers/mtd/maps/plat-ram.c
> > driver handled "mtd-ram" platform devices. There is no such
> > driver for the
> > OF-based powerpc architecture.
> >
> > As a temporary workaround I hacked the physmap_of driver to
> > handle "direct-mapped" OF devices oh type "ram" by adding a
> > corresponding entry in the of_flash_match[] array. This seems to work
> > fine.
> >
> > What would be the preferred way to handle OF-compatible RAM-based MTD
> > devices ? The 3 ways I can think of are
> >
> > 1. porting the plat-ram driver to OF (the driver isn't used
> > in the kernel tree
> > but I suspect it is used by out-of-tree boards)
> >
> > 2. creating a new plat-ram-of driver, much like the
> > physmap_of driver comes
> > from the physmap driver
> >
> > 3. extending the physmap_of driver to handle RAM devices (in
> > which case
> > references to "flash" in the function names should probably
> > be replaced
> > by "mtd")
> >
> > I live option 3 better so far.
> >
> > Has anyone already worked on this ? Is there any defined
> > device tree mapping
> > for MTD RAM devices ?
>
> We ran ito the same issue.
> We did option 3, as it was efinetly the easiest,
I think this is the best option in principle.
> here is the sram entry in our dts:
Except that your implementation of it is not good.
You're relying on the old obsolete flash binding with the "probe-type"
field. The solution should be adapted to the new approach which uses
values in the "compatible" field to indicate various sorts of flash
device.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
From: Arnd Bergmann @ 2008-03-11 0:43 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Li Yang, paulus, David Gibson
In-Reply-To: <20080310235429.GC11559@localhost.localdomain>
On Tuesday 11 March 2008, David Gibson wrote:
> On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote:
> > > This isn't a problem with this device tree, but it's probably time we
> > > started establishing some conventional generic names for nand flash
> > > and board-control devices.
> > >
> > > So, to start the ball rolling, I've seen several names for nand flash
> > > nodes, I'd suggest we standardise on "nand-flash".
> >=20
> > What's wrong with the already well-established generic name "flash"?
>=20
> I was concerned that using "flash" for both NOR flash (which it
> already is) and NAND flash might be unwise. =A0I am quite open to being
> convinced otherwise, though.
One argument for just using "flash" is that there are much finer differences
than just "NAND" and "NOR", with at least "dataflash", "OneNAND", "SD/MMC"
being further types of flash that don't fit the categories exactly, though
each one for different reasons.
=46or SD/MMC, there are good reasons to use something completely different,
for the others, calling them all "flash" sounds better than fitting them
into "nand" and "nor".
Arnd <><
^ permalink raw reply
* Re: [PATCH] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: David Gibson @ 2008-03-11 0:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0803071055200.8522@blarg.am.freescale.net>
On Fri, Mar 07, 2008 at 10:55:51AM -0600, Kumar Gala wrote:
> Normally we assume kernel images will be loaded at offset 0. However
> there are situations, like when the kernel itself is running at a non-zero
> physical address, that we don't want to load it at 0.
>
> Allow the wrapper to take an offset. We use this when building u-boot images.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Hrm. It concerns me that with the patch as it stands,
CONFIG_MEMORY_START looks like a fairly universal option, but it will
only be respected on u-boot platforms (and only new u-boot, not cuboot
at that).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: David Gibson @ 2008-03-11 0:32 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080309223109.GA3989@netgate.macqel>
On Sun, Mar 09, 2008 at 11:31:09PM +0100, Philippe De Muyter wrote:
> Hi Ben,
>
> I now have a working linux on my mpc8540 based board, with support for
> the compactflash disk and the i2c rtc.
>
> The network tough, does not work yet. altough the the integrated ethernet
> controller (FEC) seems to be recognized. Could it be a problem with the phy ?
> I notice that I do not have an entry for gfar_interrupt in /proc/interrupts
> on my ethernet-missing linux, while I have one ont the working arch/ppc linux ?
> Do I need to give the phy type in the dts file, and how ?
>
> I would also like to know if it is possible to still get in linux the mac
> address known by uboot when using a dts file, and how ?
This chiefly depends on whether you're using an old u-boot that
doesn't know about the device tree, or a new u-boot which itself
supplies a device tree to the kernel.
If the old u-boot, you'll need to write a bootwrapper for your
platform which reads the bd_t and pokes the right mac addresses into
the device tree.
If the new u-boot, u-boot itself should put the address into the
device tree. If it's not, why it's not is a u-boot question rather
than a device tree question.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.
From: David Gibson @ 2008-03-10 23:54 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Li Yang, paulus
In-Reply-To: <9f7d0248e911f6fa1a2d4292c96ef72e@kernel.crashing.org>
On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote:
> > This isn't a problem with this device tree, but it's probably time we
> > started establishing some conventional generic names for nand flash
> > and board-control devices.
> >
> > So, to start the ball rolling, I've seen several names for nand flash
> > nodes, I'd suggest we standardise on "nand-flash".
>
> What's wrong with the already well-established generic name "flash"?
I was concerned that using "flash" for both NOR flash (which it
already is) and NAND flash might be unwise. I am quite open to being
convinced otherwise, though.
> > I've seen several variants for board control devices (cpld, bcsr,
> > fpga, etc.) I suggest we standardise on "board-control"
>
> Fine with me, but it's very vague (hard to avoid though).
Yes.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* dtc: Add some documentation for the dts formta
From: David Gibson @ 2008-03-10 23:47 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Yoder Stuart
This patch adds a dts-format.txt in the Documentation directory, with
an introduction to the dtc source format. Note that this
documentation is also going into the upcoming ePAPR specification.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Documentation/dts-format.txt | 110 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 110 insertions(+)
I wrote this documentation based on an earlier draft from Stuart
Yoder. Stuart, can you please reply with a Signed-off-by line?
Index: dtc/Documentation/dts-format.txt
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/Documentation/dts-format.txt 2008-03-11 10:42:17.000000000 +1100
@@ -0,0 +1,110 @@
+Device Tree Source Format (version 1)
+=====================================
+
+The Device Tree Source (DTS) format is a textual representation of a
+device tree in a form that can be processed by dtc into a binary
+device tree in the form expected by the kernel. The description below
+is not a formal syntax definition of DTS, but describes the basic
+constructs used to represent device trees.
+
+Node and property definitions
+-----------------------------
+
+Device tree nodes are defined with a node name and unit address with
+braces marking the start and end of the node definition. They may be
+preceded by a label.
+
+ [label:] node-name[@unit-address] {
+ [properties definitions]
+ [child nodes]
+ }
+
+Nodes may contain property definitions and/or child node
+definitions. If both are present, properties must come before child
+nodes.
+
+Property definitions are name value pairs in the form:
+ [label:] property-name = value;
+except for properties with empty (zero length) value which have the
+form:
+ [label:] property-name;
+
+Property values may be defined as an array of 32-bit integer cells, as
+NUL-terminated strings, as bytestrings or a combination of these.
+
+* Arrays of cells are represented by angle brackets surrounding a
+ space separated list of C-style integers
+
+ e.g. interrupts = <17 0xc>;
+
+* A 64-bit value is represented with two 32-bit cells.
+
+ e.g. clock-frequency = <0x00000001 0x00000000>;
+
+* A NUL-terminated string value is represented using double quotes
+ (the property value is considered to include the terminating NUL
+ character).
+
+ e.g. compatible = "simple-bus";
+
+* A bytestring is enclosed in square brackets [] with each byte
+ represented by two hexadecimal digits. Spaces between each byte are
+ optional.
+
+ e.g. local-mac-address = [00 00 12 34 56 78]; or equivalently
+ local-mac-address = [000012345678];
+
+* Values may have several comma-separated components, which are
+ concatenated together.
+ e.g. compatible = "ns16550", "ns8250";
+ example = <0xf00f0000 19>, "a strange property format";
+
+* In a cell array a reference to another node will be expanded to that
+ node's phandle. References may by '&' followed by a node's label:
+ e.g. interrupt-parent = < &mpic >;
+ or they may be '&' followed by a node's full path in braces:
+ e.g. interrupt-parent = < &{/soc/interrupt-controller@40000} >;
+
+* Outside a cell array, a reference to another node will be expanded
+ to that node's full path.
+ e.g. ethernet0 = &EMAC0;
+
+* Labels may also appear before or after any component of a property
+ value, or between cells of a cell array, or between bytes of a
+ bytestring.
+ e.g. reg = reglabel: <0 sizelabel: 0x1000000>;
+ e.g. prop = [ab cd ef byte4: 00 ff fe];
+ e.g. str = start: "string value" end: ;
+
+
+File layout
+-----------
+
+Version 1 DTS files have the overall layout:
+ /dts-v1/;
+
+ [memory reservations]
+
+ / {
+ [property definitions]
+ [child nodes]
+ };
+
+* The "/dts-v1/;" must be present to identify the file as a version 1
+ DTS (dts files without this tag will be treated by dtc as being in
+ the obsolete "version 0", which uses a different format for integers
+ amongst other small but incompatible changes).
+
+* Memory reservations define an entry for the device tree blob's
+ memory reservation table. They have the form:
+ e.g. /memreserve/ <address> <length>;
+ Where <address> and <length> are 64-bit C-style integers.
+
+* The / { ... }; section defines the root node of the device tree.
+
+* C style (/* ... */) and C++ style (// ...) comments are supported.
+
+
+
+ -- David Gibson <david@gibson.dropbear.id.au>
+ -- Yoder Stuart <stuart.yoder@freescale.com>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: ADT746X: logical-bitwise & confusion in set_max_duty_at_crit()
From: Roel Kluin @ 2008-03-10 22:15 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: lkml, linuxppc-dev, Colin Leroy, akpm, Darrick J. Wong
In-Reply-To: <1dd996a5ad3a455c91886cacd3243128@kernel.crashing.org>
Segher Boessenkool wrote:
>> It includes suggested changes by Segher Boessenkool and I think this
>> version was tested by Darrick J. Wong
>
>> - u8 reg;
>> + u8 reg, temp;
>> struct i2c_client *client = to_i2c_client(dev);
>> struct adt7473_data *data = i2c_get_clientdata(client);
>> - int temp = simple_strtol(buf, NULL, 10);
>> - temp = temp && 0xFF;
>> +
>> + temp = simple_strtol(buf, NULL, 10) & 0xFF;
>
> It still does this superfluous "& 0xff", which hides the lack of
> range checking.
Sorry didn't quite grep that
---
logical-bitwise & confusion
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
index 9587869..98937d3 100644
--- a/drivers/hwmon/adt7473.c
+++ b/drivers/hwmon/adt7473.c
@@ -566,11 +566,11 @@ static ssize_t set_max_duty_at_crit(struct device *dev,
const char *buf,
size_t count)
{
- u8 reg;
+ u8 reg, temp;
struct i2c_client *client = to_i2c_client(dev);
struct adt7473_data *data = i2c_get_clientdata(client);
- int temp = simple_strtol(buf, NULL, 10);
- temp = temp && 0xFF;
+
+ temp = simple_strtol(buf, NULL, 10);
mutex_lock(&data->lock);
data->max_duty_at_overheat = temp;
^ permalink raw reply related
* Re: PPC upstream kernel ignored DABR bug
From: Segher Boessenkool @ 2008-03-10 22:06 UTC (permalink / raw)
To: Roland McGrath
Cc: linuxppc-dev, Jan Kratochvil, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20080310191957.0B42626F991@magilla.localdomain>
>> On the Blade DABRX had to be set additional to DABR. PS3 and Celleb
>> already did this. Uli Weigand found this back in November. I submitted
>> a patch for this which went into 2.6.25-rc4.
>> Can you please try again with rc4 ?
>
> This is not the problem. This came up before and everyone seems have
> forgotten. This bug has been reproduced on G5's, which do not have
> DABRX
> as I understand it.
970 (all versions) _does_ have a DABRX register. Dunno if it has
the same register definition (I cannot find DABRX in the Cell docs).
Segher
^ permalink raw reply
* Re: ADT746X: logical-bitwise & confusion in set_max_duty_at_crit()
From: Segher Boessenkool @ 2008-03-10 21:56 UTC (permalink / raw)
To: Roel Kluin; +Cc: lkml, linuxppc-dev, Colin Leroy, akpm, Darrick J. Wong
In-Reply-To: <47D5A585.8050107@tiscali.nl>
> It includes suggested changes by Segher Boessenkool and I think this
> version was tested by Darrick J. Wong
> - u8 reg;
> + u8 reg, temp;
> struct i2c_client *client = to_i2c_client(dev);
> struct adt7473_data *data = i2c_get_clientdata(client);
> - int temp = simple_strtol(buf, NULL, 10);
> - temp = temp && 0xFF;
> +
> + temp = simple_strtol(buf, NULL, 10) & 0xFF;
It still does this superfluous "& 0xff", which hides the lack of
range checking.
Segher
^ permalink raw reply
* Re: ADT746X: logical-bitwise & confusion in set_max_duty_at_crit()
From: Roel Kluin @ 2008-03-10 21:17 UTC (permalink / raw)
To: Segher Boessenkool, akpm; +Cc: Colin Leroy, Darrick J. Wong, lkml, linuxppc-dev
In-Reply-To: <64d5b5e6dfd0d1820d21db323ef88e25@kernel.crashing.org>
Andrew, I think you may want this patch instead of the other
adt746x-logical-bitwise-confusion-in-set_max_duty_at_crit.patch
It includes suggested changes by Segher Boessenkool and I think this
version was tested by Darrick J. Wong
---
logical-bitwise & confusion
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/drivers/hwmon/adt7473.c b/drivers/hwmon/adt7473.c
index 9587869..2a2de73 100644
--- a/drivers/hwmon/adt7473.c
+++ b/drivers/hwmon/adt7473.c
@@ -566,11 +566,11 @@ static ssize_t set_max_duty_at_crit(struct device *dev,
const char *buf,
size_t count)
{
- u8 reg;
+ u8 reg, temp;
struct i2c_client *client = to_i2c_client(dev);
struct adt7473_data *data = i2c_get_clientdata(client);
- int temp = simple_strtol(buf, NULL, 10);
- temp = temp && 0xFF;
+
+ temp = simple_strtol(buf, NULL, 10) & 0xFF;
mutex_lock(&data->lock);
data->max_duty_at_overheat = temp;
^ 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