* Re: Oops with TQM5200 on TQM5200
From: Wolfgang Grandegger @ 2008-03-25 9:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Anatolij Gustschin
In-Reply-To: <18407.20074.364347.911781@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Wolfgang Grandegger writes:
>> Bartlomiej Sieka wrote:
>>> Grant Likely wrote:
>>>> Paul, my git server is down at the moment. Can you please pick this
>>>> one up for .25? It is needed to boot the tqm5200 board.
>>> Could we also have similar fixes for cm5200.dts and motionpro.dts picked
>>> up? I could provide the patches within a day -- will this be OK?
>> At that occasion, could you please also add two CAN nodes to tqm5200.dts
>> as shown:
>
> Does this really need to go in for 2.6.25 -- i.e., does it fix a
> regression or a serious bug (not just a missing feature)? If so,
> please send it with a proper subject and patch description, with your
> Signed-off-by.
It's not a serious bug fix, of course, but the mentioned DTS file needs
fixing anyhow and I asked Bartlomiej to add the two CAN nodes at that
occasion to avoid another round of updates.
Thanks,
Wolfgang.
^ permalink raw reply
* [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based platforms.
From: Laurent Pinchart @ 2008-03-25 11:24 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 5734 bytes --]
Hi everybody,
the following patch fixes SMC DPRAM handling on CPM2-based platforms. It makes
the cpm_uart driver independent of any SMC initialisation made by the boot
loader. This is required to be able to reset the CPM in cpm2_reset() which
should be the next step in making CPM2 initialisation independent of the
boot loader.
I was concerned this would break udbg, but udbg doesn't seem to be supported
on PQ2-based platforms.
---
This patch allocates parameter RAM for SMC serial ports without relying on
previous initialisation by a boot loader or a wrapper layer.
SMC parameter RAM on CPM2-based platforms can be allocated anywhere in the
general-purpose areas of the dual-port RAM. The current code relies on the
boot loader to allocate a section of general-purpose CPM RAM and gets the
section address from the device tree.
This patch modifies the device tree address usage to reference the SMC
parameter RAM base pointer instead of a pre-allocated RAM section and
allocates memory from the CPM dual-port RAM when initialising the SMC port.
CPM1-based platforms are not affected.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
---
drivers/serial/cpm_uart/cpm_uart.h | 3 ++
drivers/serial/cpm_uart/cpm_uart_core.c | 19 +++++++--------
drivers/serial/cpm_uart/cpm_uart_cpm1.c | 12 ++++++++++
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 37 +++++++++++++++++++++++++++++++
4 files changed, 61 insertions(+), 10 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart.h b/drivers/serial/cpm_uart/cpm_uart.h
index 80a7d60..5334653 100644
--- a/drivers/serial/cpm_uart/cpm_uart.h
+++ b/drivers/serial/cpm_uart/cpm_uart.h
@@ -93,6 +93,9 @@ extern struct uart_cpm_port cpm_uart_ports[UART_NR];
/* these are located in their respective files */
void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd);
+void __iomem *cpm_uart_map_pram(struct uart_cpm_port *port,
+ struct device_node *np);
+void cpm_uart_unmap_pram(struct uart_cpm_port *port, void __iomem *pram);
int cpm_uart_init_portdesc(void);
int cpm_uart_allocbuf(struct uart_cpm_port *pinfo, unsigned int is_con);
void cpm_uart_freebuf(struct uart_cpm_port *pinfo);
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index af875ad..56f39ca 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -997,24 +997,23 @@ static int cpm_uart_init_port(struct device_node *np,
if (!mem)
return -ENOMEM;
- pram = of_iomap(np, 1);
- if (!pram) {
- ret = -ENOMEM;
- goto out_mem;
- }
-
if (of_device_is_compatible(np, "fsl,cpm1-scc-uart") ||
of_device_is_compatible(np, "fsl,cpm2-scc-uart")) {
pinfo->sccp = mem;
- pinfo->sccup = pram;
+ pinfo->sccup = pram = cpm_uart_map_pram(pinfo, np);
} else if (of_device_is_compatible(np, "fsl,cpm1-smc-uart") ||
of_device_is_compatible(np, "fsl,cpm2-smc-uart")) {
pinfo->flags |= FLAG_SMC;
pinfo->smcp = mem;
- pinfo->smcup = pram;
+ pinfo->smcup = pram = cpm_uart_map_pram(pinfo, np);
} else {
ret = -ENODEV;
- goto out_pram;
+ goto out_mem;
+ }
+
+ if (!pram) {
+ ret = -ENOMEM;
+ goto out_mem;
}
pinfo->tx_nrfifos = TX_NUM_FIFO;
@@ -1038,7 +1037,7 @@ static int cpm_uart_init_port(struct device_node *np,
return cpm_uart_request_port(&pinfo->port);
out_pram:
- iounmap(pram);
+ cpm_uart_unmap_pram(pinfo, pram);
out_mem:
iounmap(mem);
return ret;
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.c b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
index 52fb044..060f566 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
@@ -58,6 +58,18 @@ void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
while (in_be16(cpcr) & CPM_CR_FLG)
;
}
+
+void __iomem *cpm_uart_map_pram(struct uart_cpm_port *port,
+ struct device_node *np)
+{
+ return of_iomap(np, 1);
+}
+
+void cpm_uart_unmap_pram(struct uart_cpm_port *port, void __iomem *pram)
+{
+ iounmap(pram);
+}
+
#else
void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
{
diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
index 88daad1..9391dc6 100644
--- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
+++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
@@ -41,6 +41,9 @@
#include <asm/io.h>
#include <asm/irq.h>
#include <asm/fs_pd.h>
+#ifdef CONFIG_PPC_CPM_NEW_BINDING
+#include <asm/prom.h>
+#endif
#include <linux/serial_core.h>
#include <linux/kernel.h>
@@ -60,6 +63,40 @@ void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
cpm2_unmap(cp);
}
+
+void __iomem *cpm_uart_map_pram(struct uart_cpm_port *port,
+ struct device_node *np)
+{
+ void __iomem *pram;
+ unsigned long offset;
+
+ /* Don't remap parameter RAM if it has already been initialized
+ * during console setup.
+ */
+ if (IS_SMC(port) && port->smcup)
+ return port->smcup;
+ else if (!IS_SMC(port) && port->sccup)
+ return port->sccup;
+
+ pram = of_iomap(np, 1);
+ if (!pram)
+ return NULL;
+
+ if (!IS_SMC(port))
+ return pram;
+
+ offset = cpm_dpalloc(PROFF_SMC_SIZE, 64);
+ out_be16(pram, offset);
+ iounmap(pram);
+ return cpm_muram_addr(offset);
+}
+
+void cpm_uart_unmap_pram(struct uart_cpm_port *port, void __iomem *pram)
+{
+ if (!(port->flags & FLAG_SMC))
+ iounmap(pram);
+}
+
#else
void cpm_line_cr_cmd(struct uart_cpm_port *port, int cmd)
{
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [RESEND] [PATCH 1/2 v2] [OF] Add of_device_is_available function
From: Josh Boyer @ 2008-03-25 11:51 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080325004753.5885ede9@lappy.seanm.ca>
On Tue, 25 Mar 2008 00:47:53 -0400
Sean MacLennan <smaclennan@pikatech.com> wrote:
> On Mon, 24 Mar 2008 22:39:18 +1100
> "Paul Mackerras" <paulus@samba.org> wrote:
>
> > The second test will succeed for anything that starts with "ok", so
> > the first test is redundant. I suspect you want strcmp instead of
> > strncmp in both tests.
>
> I like the strncmp(status, "ok", 2). Then you can have a status of
> okey-dokey ;)
You can also have "oklahoma", "okaly-dokaly-do" (I hate Ned Flanders),
and "ok-this-device-is-fubar-don't-ever-touch-it!"
We really want just "okay" and "ok". Look for a version 3 of the patch
that fixes it later today.
josh
^ permalink raw reply
* Re: MPC8641D PCI-Express problem
From: Kumar Gala @ 2008-03-25 12:55 UTC (permalink / raw)
To: Marco Stornelli; +Cc: LinuxPPC-Embedded
In-Reply-To: <47E8B19B.10705@coritel.it>
On Mar 25, 2008, at 3:02 AM, Marco Stornelli wrote:
> Hi,
>
> do you remember my problem with the pci-express? I have an
> mpc8641d_hpcn (rev. 2.0) board connected via pci-express with the
> Xilinx ML555 evaluation board. I'm using the 2.6.24 kernel. I'm
> observing this strange behavior:
>
> 1) I turn on the board and I stop the U-boot
> 2) I load the FPGA microcode
> 3) I start the system
> 4) I load the driver module and I read a version register in the FPGA
> 5) The system crashes with a "machine check exception: transfer
> error ack signal"
> 6) reboot
> 7) same procedure (without load the FPGA again)
> 8) now I can read the registers!
>
> If I repeat the procedure again it doesn't work anymore. I think
> it's a problem with pci-express controller. Have you got any
> suggestions?
>
> Thanks.
Where are you loading the FPGA microcode (linux, u-boot)? Also, is
the FPGA the only device connected over PCIe?
- k
^ permalink raw reply
* Re: MPC8641D PCI-Express problem
From: Marco Stornelli @ 2008-03-25 13:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: LinuxPPC-Embedded
In-Reply-To: <7F2C28B9-9B87-4F46-9C57-3666BB8F7EFD@kernel.crashing.org>
Kumar Gala ha scritto:
>
> On Mar 25, 2008, at 3:02 AM, Marco Stornelli wrote:
>> Hi,
>>
>> do you remember my problem with the pci-express? I have an
>> mpc8641d_hpcn (rev. 2.0) board connected via pci-express with the
>> Xilinx ML555 evaluation board. I'm using the 2.6.24 kernel. I'm
>> observing this strange behavior:
>>
>> 1) I turn on the board and I stop the U-boot
>> 2) I load the FPGA microcode
>> 3) I start the system
>> 4) I load the driver module and I read a version register in the FPGA
>> 5) The system crashes with a "machine check exception: transfer error
>> ack signal"
>> 6) reboot
>> 7) same procedure (without load the FPGA again)
>> 8) now I can read the registers!
>>
>> If I repeat the procedure again it doesn't work anymore. I think it's
>> a problem with pci-express controller. Have you got any suggestions?
>>
>> Thanks.
>
> Where are you loading the FPGA microcode (linux, u-boot)? Also, is the
> FPGA the only device connected over PCIe?
>
> - k
>
I load the FPGA with JTAG and with a Xilinx program without a specific
linux driver or u-boot. Yes, it is the only device connected over PCIe.
\Marco
^ permalink raw reply
* Re: [PATCH 2/2 v2] Add DIU platform code for MPC8610HPCD
From: Andy Whitcroft @ 2008-03-25 12:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-fbdev-devel, York Sun, linux-kernel
In-Reply-To: <20080320153304.cdc1817d.akpm@linux-foundation.org>
On Thu, Mar 20, 2008 at 03:33:04PM -0700, Andrew Morton wrote:
> On Wed, 19 Mar 2008 13:50:27 -0500
> York Sun <yorksun@freescale.com> wrote:
>
> > Add platform code to support Freescale DIU. The platform code includes
> > framebuffer memory allocation, pixel format, monitor port, etc.
> >
> > ...
> >
> > +unsigned int mpc8610hpcd_get_pixel_format
> > + (unsigned int bits_per_pixel, int monitor_port)
This seems like it might be detectable, does this seem like something we
should try an report?
WARNING: arguments for function declarations should follow identifier
#7: FILE: Z110.c:7:
+int __init preallocate_diu_videomemory
> Again, please do
>
> unsigned int mpc8610hpcd_get_pixel_format(unsigned int bits_per_pixel,
> int monitor_port)
>
> (and anywhere else where this was done)
>
> > +int __init preallocate_diu_videomemory(void);
>
> Nope, please don't put extern declarations in .c files. Find a suitable
> header for it - one which is included by the defining file and by all users
> of the symbol.
>
> Andy, checkpatch missed this.
Yeah, we did only look for explicitly extern'd declarations. But this
form seems detectable, will be in v0.17.
WARNING: externs should be avoided in .c files
#2: FILE: Z110.c:2:
+int __init preallocate_diu_videomemory(void);
-apw
^ permalink raw reply
* Re: [PATCH] ppc: Export empty_zero_page
From: Theodore Tso @ 2008-03-25 13:54 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev
In-Reply-To: <20080312202431.GG15804@mit.edu>
So I screwed this one up. Mea culpa, mea culpa, mea maxima culpa....
I assume Stephen's already sent this to patch to you guys (I picked it
up from the linux-next git tree), but just in case he didn't....
- Ted
>From 7919d4874fe991abd0b686ac1f68131c818cdb36 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 13 Mar 2008 16:16:10 +1100
Subject: [PATCH] really export empty_zero_page
It was being protected by CONFIG_PPC32.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/ppc_ksyms.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index 65d14e6..1e89eb5 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -57,7 +57,6 @@ extern void program_check_exception(struct pt_regs *regs);
extern void single_step_exception(struct pt_regs *regs);
extern int sys_sigreturn(struct pt_regs *regs);
-EXPORT_SYMBOL(empty_zero_page);
EXPORT_SYMBOL(clear_pages);
EXPORT_SYMBOL(copy_page);
EXPORT_SYMBOL(ISA_DMA_THRESHOLD);
@@ -191,3 +190,4 @@ EXPORT_SYMBOL(intercept_table);
EXPORT_SYMBOL(__mtdcr);
EXPORT_SYMBOL(__mfdcr);
#endif
+EXPORT_SYMBOL(empty_zero_page);
--
1.5.4.1.144.gdfee-dirty
^ permalink raw reply related
* Re: OF compatible MTD platform RAM driver ?
From: Laurent Pinchart @ 2008-03-25 14:36 UTC (permalink / raw)
To: David Gibson; +Cc: ben, linuxppc-dev, linux-mtd
In-Reply-To: <20080311224048.GA7642@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2189 bytes --]
On Tuesday 11 March 2008 23:40, David Gibson wrote:
> On Tue, Mar 11, 2008 at 11:39:08AM +0100, Laurent Pinchart wrote:
> > On Tuesday 11 March 2008 01:45, David Gibson wrote:
> > > On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:
> > > > linuxppc-dev-bounces+runet=innovsys.com@ozlabs.org wrote:
> [snip]
> > > > 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.
> >
> > I'll implement that and post a patch after completing the ppc-to-powerpc
> > migration.
> >
> > > > 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.
> >
> > What "compatible" values should I use for ROM and RAM mappings ?
>
> That I'm not so sure of. We'll need to find some consensus.
>
> There may be existing IEEE1275 bindings for roms, which we should
> investigate.
Do you (or someone else here) have access to the IEEE1275 specification ? Is
there any ROM binding in there ?
> Arguably RAM should be represented by a memory node, but
> that's going to get messy for this sort of application.
We're talking about a very specific type of RAM, used for permanent storage
with a battery backup. The RAM is really meant to be used as an MTD device
and as such I think it makes sense to describe it as an mtd-compatible device
on the local bus.
What about the following definition for the RAM node ?
nvram@2,0000 {
compatible = "mtd,ram";
reg = <2 0x0000 0x00100000>;
bank-width = <2>;
};
Or should the node have a device-type property of either 'ram' or 'rom' with
the compatible property just referencing MTD ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: dtc: Simplify error handling for unparseable input
From: Scott Wood @ 2008-03-25 14:36 UTC (permalink / raw)
To: Jon Loeliger, linuxppc-dev
In-Reply-To: <20080325012805.GA1227@localhost.localdomain>
On Tue, Mar 25, 2008 at 12:28:05PM +1100, David Gibson wrote:
> On Mon, Mar 24, 2008 at 12:36:41PM -0500, Scott Wood wrote:
> > If you remove this, there'll be no way to indicate semantic errors other
> > than die() (the NULL approaches are no good, since they inhibit recovery),
> > which is suboptimal if the error is not immediately fatal.
>
> But everything is immediately fatal. When we have a *real* example of
> something that's not, we can restore an error code.
Failed binary includes are not immediately fatal.
-Scott
^ permalink raw reply
* Re: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based platforms.
From: Scott Wood @ 2008-03-25 14:58 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803251224.45408.laurentp@cse-semaphore.com>
On Tue, Mar 25, 2008 at 12:24:40PM +0100, Laurent Pinchart wrote:
> I was concerned this would break udbg, but udbg doesn't seem to be supported
> on PQ2-based platforms.
Yes, it is (see arch/powerpc/sysdev/cpm_common.c).
> This patch modifies the device tree address usage to reference the SMC
> parameter RAM base pointer instead of a pre-allocated RAM section and
> allocates memory from the CPM dual-port RAM when initialising the SMC port.
> CPM1-based platforms are not affected.
Please maintain backward compatibility with older device trees (by
checking the length of the second reg resource). At the very least,
update the device trees that are affected.
> + offset = cpm_dpalloc(PROFF_SMC_SIZE, 64);
> + out_be16(pram, offset);
Up to this point, if we don't reset the CPM prior to any dpalloc calls
(and if we do, udbg printk breaks), the SMC could be running and
clobbering some other bit of dpram, which could have been allocated to
something else.
After this point, even if you don't reset the CPM, udbg printk is broken
because you moved pram. The udbg disabling will have to be moved before
this.
-Scott
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Sergei Shtylyov @ 2008-03-25 15:29 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <200803251536.17795.laurentp@cse-semaphore.com>
Hello.
Laurent Pinchart wrote:
>>>>>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.
>>>What "compatible" values should I use for ROM and RAM mappings ?
>>That I'm not so sure of. We'll need to find some consensus.
>>There may be existing IEEE1275 bindings for roms, which we should
>>investigate.
> Do you (or someone else here) have access to the IEEE1275 specification ? Is
Yeah, and I can point you to it -- see the documantation section on
http://www.openbios.org/...
> there any ROM binding in there ?
No. We initially called the flash devices that physmap_of driver
controlled "rom" (I mean the "device_type" property) -- now this is obsoleted.
>>Arguably RAM should be represented by a memory node, but
>>that's going to get messy for this sort of application.
Note that the OF "memory" type nodes do *not* represent RAM devices.
> We're talking about a very specific type of RAM, used for permanent storage
> with a battery backup. The RAM is really meant to be used as an MTD device
> and as such I think it makes sense to describe it as an mtd-compatible device
> on the local bus.
> What about the following definition for the RAM node ?
> nvram@2,0000 {
Note that there's a OF "device_type" of "nvram", so your (generic) device
name seems to add some mess. (IIRC, that OF device type didn't actually
represent a "real" device, and only served to provide access to NVRAM for OF).
> compatible = "mtd,ram";
The part before comma should be a company name or a stock ticker. What did
you mean here?
> reg = <2 0x0000 0x00100000>;
> bank-width = <2>;
> };
> Or should the node have a device-type property of either 'ram' or 'rom' with
> the compatible property just referencing MTD ?
The "device_type" properties are not required and their further creation
has been discouraged on liunxppc-dev.
> Best regards,
WBR, Sergei
^ permalink raw reply
* Re: Please pull linux-2.6-mpc52xx.git
From: Bartlomiej Sieka @ 2008-03-25 15:29 UTC (permalink / raw)
To: Richard Purdie; +Cc: linuxppc-dev
In-Reply-To: <1205834666.7500.27.camel@dax.rpnet.com>
Richard Purdie wrote:
> On Tue, 2008-03-18 at 09:29 +0100, Bartlomiej Sieka wrote:
>> Grant Likely wrote:
>>> The LED code just hasn't been picked up. IIRC, it was reworked to
>>> make it a proper driver in drivers/leds.
>> Yes, the Motion-PRO LED driver has been reworked and posted:
>> http://patchwork.ozlabs.org/linuxppc/patch?q=Motion-pro&id=16617
>>
>> > I need to look at it again,
>>> but it is a lot of code for a very simple thing and I wasn't sure if I
>>> should be the one to pick it up because it is in drivers/leds which
>>> has a different maintainer.
>> I'm copying Richard Purdie who's listed as LED SUBSYSTEM maintainer.
>>
>> Richard -- could pick up the above mentioned Motion-PRO LED driver for
>> upstream inclusion? It started as a MPC5200-specific thing posted to
>> linuxppc-dev and got reviewed there, with the intent to go upstream via
>> Grant (MPC52XX maintainer). However, it seems that it should be merged
>> through your subsystem.
>
> There are some tweaks this driver needs before it can be merged.
>
> Firstly, it seems to re implement a timer to make the LED blink and I'm
> not keen on doing that. I notice that you have default_trigger = "timer"
> but that won't make it activate at boot which is probably why the other
> code exists?
That's right. The requirement is to have the LED blink while the system
is booting up, until a custom application takes control over.
> I will accept a patch which allows the default timer state
> to be configurable (either from the defconfig or from the commandline)
> which should solve your problem?
Yes, this should work. Will you accept a patch that allows default timer
configuration based on the information from the device tree blob (the
board in question is under arch/powerpc)?
>
> Secondly, can you confirm what of_get_property(op->node, "label", NULL);
> returns and whether this conforms to the LED naming guidelines?
No it does not -- thanks for bringing this point up. Will post code that
fixes this.
Thanks for your comments.
Regards,
Bartlomiej
^ permalink raw reply
* Please pull pasemi.git for-2.6.25 branch
From: Olof Johansson @ 2008-03-25 15:41 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Sorry for the late request, had I seen the request for last round of
patches I would have sent this out sooner. I've been offline most of
the last week. Looks like Linus already pulled last request.
Below updates pasemi_defconfig for 2.6.25:
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.25
to receive the following updates:
arch/powerpc/configs/pasemi_defconfig | 142 +++++++++++++++++++++-------------
1 file changed, 88 insertions(+), 54 deletions(-)
Olof Johansson (1):
[POWERPC] update pasemi_defconfig
-Olof
^ permalink raw reply
* Re: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based platforms.
From: Laurent Pinchart @ 2008-03-25 15:34 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080325145841.GG13187@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]
On Tuesday 25 March 2008 15:58, Scott Wood wrote:
> On Tue, Mar 25, 2008 at 12:24:40PM +0100, Laurent Pinchart wrote:
> > I was concerned this would break udbg, but udbg doesn't seem to be
supported
> > on PQ2-based platforms.
>
> Yes, it is (see arch/powerpc/sysdev/cpm_common.c).
I thought that was for CPM1 only. My bad.
> > This patch modifies the device tree address usage to reference the SMC
> > parameter RAM base pointer instead of a pre-allocated RAM section and
> > allocates memory from the CPM dual-port RAM when initialising the SMC
port.
> > CPM1-based platforms are not affected.
>
> Please maintain backward compatibility with older device trees (by
> checking the length of the second reg resource). At the very least,
> update the device trees that are affected.
I haven't seen any CPM2-based board using SMC ports in the device trees
available in arch/powerpc/boot/dts.
Should I still maintain compatibility with older device trees ? Is there any
out-of-tree PQ2 boards using udbg and SMC ? What about printing a warning if
the second reg resource has the wrong size ?
> > + offset = cpm_dpalloc(PROFF_SMC_SIZE, 64);
> > + out_be16(pram, offset);
>
> Up to this point, if we don't reset the CPM prior to any dpalloc calls
> (and if we do, udbg printk breaks), the SMC could be running and
> clobbering some other bit of dpram, which could have been allocated to
> something else.
If udbg uses the parameter RAM allocated by the boot loader, that section of
DPRAM should be removed from the muram node in the device tree. Otherwise the
SMC DPRAM will eventually be allocated to something else and the system will
break.
It should thus be safe to reset the CPM if udbg isn't used, and the device
tree should explicitely exclude the pre-allocated parameter RAM from the
muram node when udbg is used.
> After this point, even if you don't reset the CPM, udbg printk is broken
> because you moved pram. The udbg disabling will have to be moved before
> this.
Moving the SMC pram doesn't break udbg printk in itself. What will break it is
moving the TX BDs, but the end result is the same, moving pram will result in
udbg being broken.
The cpm_uart driver disable udbg before allocating the new BDs. What about
moving that right before moving the parameter RAM ? cpm_uart_request_port(),
which is called in between, already disables RX and TX on the port, so we
won't loose any debug message.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] ehea: Fix IPv6 support
From: Thomas Klein @ 2008-03-25 15:41 UTC (permalink / raw)
To: Andrew Morton
Cc: jeff, themann, netdev, hering2, linux-kernel, linuxppc-dev,
raisch, stefan.roscher, stable
In-Reply-To: <20080320145456.f0b6d101.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Wed, 19 Mar 2008 13:55:43 +0100
> Thomas Klein <osstklei@de.ibm.com> wrote:
>
>> Indicate that HEA calculates IPv4 checksums only
>>
>> Signed-off-by: Thomas Klein <tklein@de.ibm.com>
>>
>> ---
>> diff -Nurp -X dontdiff linux-2.6.25-rc6/drivers/net/ehea/ehea.h patched_kernel/drivers/net/ehea/ehea.h
>> --- linux-2.6.25-rc6/drivers/net/ehea/ehea.h 2008-03-17 00:32:14.000000000 +0100
>> +++ patched_kernel/drivers/net/ehea/ehea.h 2008-03-19 08:58:07.000000000 +0100
>> @@ -40,7 +40,7 @@
>> #include <asm/io.h>
>>
>> #define DRV_NAME "ehea"
>> -#define DRV_VERSION "EHEA_0087"
>> +#define DRV_VERSION "EHEA_0089"
>>
>> /* eHEA capability flags */
>> #define DLPAR_PORT_ADD_REM 1
>> diff -Nurp -X dontdiff linux-2.6.25-rc6/drivers/net/ehea/ehea_main.c patched_kernel/drivers/net/ehea/ehea_main.c
>> --- linux-2.6.25-rc6/drivers/net/ehea/ehea_main.c 2008-03-17 00:32:14.000000000 +0100
>> +++ patched_kernel/drivers/net/ehea/ehea_main.c 2008-03-19 08:58:07.000000000 +0100
>> @@ -3108,7 +3108,7 @@ struct ehea_port *ehea_setup_single_port
>> dev->vlan_rx_add_vid = ehea_vlan_rx_add_vid;
>> dev->vlan_rx_kill_vid = ehea_vlan_rx_kill_vid;
>> dev->features = NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_TSO
>> - | NETIF_F_HIGHDMA | NETIF_F_HW_CSUM | NETIF_F_HW_VLAN_TX
>> + | NETIF_F_HIGHDMA | NETIF_F_IP_CSUM | NETIF_F_HW_VLAN_TX
>> | NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_FILTER
>> | NETIF_F_LLTX;
>> dev->tx_timeout = &ehea_tx_watchdog;
>
> That looks like a pretty significant fix to me? Should it be backported to
> 2.6.24.x?
Agreed. I'll send a patch.
Thomas
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Laurent Pinchart @ 2008-03-25 15:51 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <47E91A5B.1060406@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 2889 bytes --]
Hi Sergei,
On Tuesday 25 March 2008 16:29, Sergei Shtylyov wrote:
> Hello.
>
> Laurent Pinchart wrote:
>
> >>>>>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.
>
> >>>What "compatible" values should I use for ROM and RAM mappings ?
>
> >>That I'm not so sure of. We'll need to find some consensus.
>
> >>There may be existing IEEE1275 bindings for roms, which we should
> >>investigate.
>
> > Do you (or someone else here) have access to the IEEE1275 specification ? Is
>
> Yeah, and I can point you to it -- see the documantation section on
> http://www.openbios.org/...
Thanks a lot for the pointer.
> > there any ROM binding in there ?
>
> No. We initially called the flash devices that physmap_of driver
> controlled "rom" (I mean the "device_type" property) -- now this is obsoleted.
>
> >>Arguably RAM should be represented by a memory node, but
> >>that's going to get messy for this sort of application.
>
> Note that the OF "memory" type nodes do *not* represent RAM devices.
>
> > We're talking about a very specific type of RAM, used for permanent storage
> > with a battery backup. The RAM is really meant to be used as an MTD device
> > and as such I think it makes sense to describe it as an mtd-compatible device
> > on the local bus.
>
> > What about the following definition for the RAM node ?
>
> > nvram@2,0000 {
>
> Note that there's a OF "device_type" of "nvram", so your (generic) device
> name seems to add some mess. (IIRC, that OF device type didn't actually
> represent a "real" device, and only served to provide access to NVRAM for OF).
Ok.
> > compatible = "mtd,ram";
>
> The part before comma should be a company name or a stock ticker. What did
> you mean here?
I didn't know that. Let's say I meant "mtd-ram" :-)
> > reg = <2 0x0000 0x00100000>;
> > bank-width = <2>;
> > };
>
> > Or should the node have a device-type property of either 'ram' or 'rom' with
> > the compatible property just referencing MTD ?
>
> The "device_type" properties are not required and their further creation
> has been discouraged on liunxppc-dev.
What about
mtdram@2,0000 {
compatible = "mtd-ram";
reg = <2 0x0000 0x00100000>;
bank-width = <2>;
};
ROMs could use "mtd-rom" for their compatible property.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 2.6.24-stable] ehea: Fix IPv6 support
From: Thomas Klein @ 2008-03-25 15:56 UTC (permalink / raw)
To: stable
Cc: Jan-Bernd Themann, netdev, Hannes Hering, linux-kernel, linux-ppc,
Christoph Raisch, Andrew Morton, Stefan Roscher
Indicate that HEA calculates IPv4 checksums only
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
diff -Nurp linux-2.6.24.4.org/drivers/net/ehea/ehea.h linux-2.6.24.4/drivers/net/ehea/ehea.h
--- linux-2.6.24.4.org/drivers/net/ehea/ehea.h 2008-03-25 12:42:18.000000000 +0100
+++ linux-2.6.24.4/drivers/net/ehea/ehea.h 2008-03-25 13:13:29.000000000 +0100
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0083"
+#define DRV_VERSION "EHEA_0083a"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff -Nurp linux-2.6.24.4.org/drivers/net/ehea/ehea_main.c linux-2.6.24.4/drivers/net/ehea/ehea_main.c
--- linux-2.6.24.4.org/drivers/net/ehea/ehea_main.c 2008-03-25 12:42:18.000000000 +0100
+++ linux-2.6.24.4/drivers/net/ehea/ehea_main.c 2008-03-25 13:13:12.000000000 +0100
@@ -2945,7 +2945,7 @@ struct ehea_port *ehea_setup_single_port
dev->vlan_rx_add_vid = ehea_vlan_rx_add_vid;
dev->vlan_rx_kill_vid = ehea_vlan_rx_kill_vid;
dev->features = NETIF_F_SG | NETIF_F_FRAGLIST | NETIF_F_TSO
- | NETIF_F_HIGHDMA | NETIF_F_HW_CSUM | NETIF_F_HW_VLAN_TX
+ | NETIF_F_HIGHDMA | NETIF_F_IP_CSUM | NETIF_F_HW_VLAN_TX
| NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_FILTER
| NETIF_F_LLTX;
dev->tx_timeout = &ehea_tx_watchdog;
^ permalink raw reply
* [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
From: Carl Love @ 2008-03-25 15:58 UTC (permalink / raw)
To: cbe-oss-dev, linuxppc-dev, linux-kernel, cel
This patch fixes a bug in the code that records the SPU data and
context switches. The buffer_mutex lock must be held when the
kernel is adding data to the buffer between the kernel and the
OProfile daemon. The lock is not being held in the current code
base. This patch fixes the bug using work queues. The data to
be passed to the daemon is caputured by the interrupt handler.
The workqueue function is invoked to grab the buffer_mutex lock
and add the data to the buffer.
Signed-off-by: Carl Love <cel@us.ibm.com>
Index: linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
===================================================================
--- linux-2.6.25-rc4.orig/arch/powerpc/oprofile/cell/spu_profiler.c
+++ linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
@@ -16,6 +16,7 @@
#include <linux/smp.h>
#include <linux/slab.h>
#include <asm/cell-pmu.h>
+#include <linux/workqueue.h>
#include "pr_util.h"
#define TRACE_ARRAY_SIZE 1024
@@ -32,9 +33,19 @@ static unsigned int profiling_interval;
#define SPU_PC_MASK 0xFFFF
+/* The generic OProfile code uses the buffer_mutex to protect the buffer
+ * between the kernel and the daemon. The SPU code needs to use the buffer
+ * to ensure that the kernel SPU writes complete as a single block before
+ * being consumed by the daemon.
+ */
+extern struct mutex buffer_mutex;
+
static DEFINE_SPINLOCK(sample_array_lock);
unsigned long sample_array_lock_flags;
+struct work_struct spu_record_wq;
+extern struct workqueue_struct *oprofile_spu_wq;
+
void set_spu_profiling_frequency(unsigned int freq_khz, unsigned int cycles_reset)
{
unsigned long ns_per_cyc;
@@ -123,14 +134,14 @@ static int cell_spu_pc_collection(int cp
return entry;
}
-
-static enum hrtimer_restart profile_spus(struct hrtimer *timer)
-{
- ktime_t kt;
+static void profile_spus_record_samples (struct work_struct *ws) {
+ /* This routine is called via schedule_work() to record the
+ * spu data. It must be run in a normal kernel mode to
+ * grab the OProfile mutex lock.
+ */
int cpu, node, k, num_samples, spu_num;
- if (!spu_prof_running)
- goto stop;
+ mutex_lock(&buffer_mutex);
for_each_online_cpu(cpu) {
if (cbe_get_hw_thread_id(cpu))
@@ -170,6 +181,20 @@ static enum hrtimer_restart profile_spus
smp_wmb(); /* insure spu event buffer updates are written */
/* don't want events intermingled... */
+ mutex_unlock(&buffer_mutex);
+}
+
+static enum hrtimer_restart profile_spus(struct hrtimer *timer)
+{
+ ktime_t kt;
+
+
+ if (!spu_prof_running)
+ goto stop;
+
+ /* schedule the funtion to record the data */
+ schedule_work(&spu_record_wq);
+
kt = ktime_set(0, profiling_interval);
if (!spu_prof_running)
goto stop;
@@ -209,6 +234,10 @@ int start_spu_profiling(unsigned int cyc
spu_prof_running = 1;
hrtimer_start(&timer, kt, HRTIMER_MODE_REL);
+ /* setup the workqueue for recording the SPU data */
+ INIT_WORK(&spu_record_wq,
+ profile_spus_record_samples);
+
return 0;
}
Index: linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_task_sync.c
===================================================================
--- linux-2.6.25-rc4.orig/arch/powerpc/oprofile/cell/spu_task_sync.c
+++ linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_task_sync.c
@@ -27,15 +27,44 @@
#include <linux/numa.h>
#include <linux/oprofile.h>
#include <linux/spinlock.h>
+#include <linux/workqueue.h>
#include "pr_util.h"
#define RELEASE_ALL 9999
-static DEFINE_SPINLOCK(buffer_lock);
+extern struct mutex buffer_mutex;
+extern struct workqueue_struct *oprofile_spu_wq;
+extern int calls_to_record_switch;
+
static DEFINE_SPINLOCK(cache_lock);
static int num_spu_nodes;
+
int spu_prof_num_nodes;
int last_guard_val[MAX_NUMNODES * 8];
+int cnt_swtch_processed_flag[MAX_NUMNODES * 8];
+
+struct spus_profiling_code_data_s {
+ int num_spu_nodes;
+ struct work_struct spu_prof_code_wq;
+} spus_profiling_code_data;
+
+struct spu_context_switch_data_s {
+ struct spu *spu;
+ unsigned long spu_cookie;
+ unsigned long app_dcookie;
+ unsigned int offset;
+ unsigned long objectId;
+ int valid_entry;
+} spu_context_switch_data;
+
+int calls_to_record_switch = 0;
+int record_spu_start_flag = 0;
+
+struct spus_cntxt_sw_data_s {
+ int num_spu_nodes;
+ struct spu_context_switch_data_s spu_data[MAX_NUMNODES * 8];
+ struct work_struct spu_cntxt_work;
+} spus_cntxt_sw_data;
/* Container for caching information about an active SPU task. */
struct cached_info {
@@ -44,6 +73,8 @@ struct cached_info {
struct kref cache_ref;
};
+struct workqueue_struct *oprofile_spu_wq;
+
static struct cached_info *spu_info[MAX_NUMNODES * 8];
static void destroy_cached_info(struct kref *kref)
@@ -283,39 +314,90 @@ fail_no_image_cookie:
* passed SPU and records SPU context information into the OProfile
* event buffer.
*/
+static void record_spu_process_switch(struct work_struct *ws) {
+ int spu;
+ int req_processed=0;
+ struct spus_cntxt_sw_data_s *data
+ = container_of(ws, struct spus_cntxt_sw_data_s,
+ spu_cntxt_work);
+
+ mutex_lock(&buffer_mutex);
+
+ if (record_spu_start_flag) {
+ add_event_entry(ESCAPE_CODE);
+ add_event_entry(SPU_PROFILING_CODE);
+ add_event_entry(data->num_spu_nodes);
+ record_spu_start_flag = 0;
+ }
+
+ for (spu = 0; spu < data->num_spu_nodes; spu ++) {
+ /* If the cached info can be created, put the info
+ * into the oprofile buffer for the daemon. Otherwise
+ * toss the entry.
+ */
+ if (data->spu_data[spu].valid_entry == 1) {
+ /* Record context info in event buffer */
+ req_processed++;
+ add_event_entry(ESCAPE_CODE);
+ add_event_entry(SPU_CTX_SWITCH_CODE);
+ add_event_entry(spu);
+ add_event_entry(data->spu_data[spu].spu->pid);
+ add_event_entry(data->spu_data[spu].spu->tgid);
+ add_event_entry(data->spu_data[spu].app_dcookie);
+ add_event_entry(data->spu_data[spu].spu_cookie);
+ add_event_entry(data->spu_data[spu].offset);
+
+ /* Context switch has been processed, can now
+ * begin recording samples.
+ */
+ cnt_swtch_processed_flag[spu] = 1;
+
+ /* insure spu event buffer updates are written
+ * don't want entries intermingled...
+ */
+ smp_wmb();
+ }
+ data->spu_data[spu].valid_entry = 0;
+ }
+
+ mutex_unlock(&buffer_mutex);
+}
+
static int process_context_switch(struct spu *spu, unsigned long objectId)
{
- unsigned long flags;
- int retval;
+ int retval = 0;
unsigned int offset = 0;
unsigned long spu_cookie = 0, app_dcookie;
retval = prepare_cached_spu_info(spu, objectId);
- if (retval)
+ if (retval) {
+ printk(KERN_ERR "SPU_PROF: "
+ "%s, line %d: prepare_cached_spu_info call "
+ "failed, returned %d\n",
+ __FUNCTION__, __LINE__, retval);
goto out;
+ }
+
- /* Get dcookie first because a mutex_lock is taken in that
- * code path, so interrupts must not be disabled.
- */
app_dcookie = get_exec_dcookie_and_offset(spu, &offset, &spu_cookie, objectId);
if (!app_dcookie || !spu_cookie) {
+ printk(KERN_ERR "SPU_PROF: "
+ "%s, line %d: get_exec_dcookie_and_offset call "
+ "failed, returned %lu\n",
+ __FUNCTION__, __LINE__, app_dcookie);
retval = -ENOENT;
goto out;
}
- /* Record context info in event buffer */
- spin_lock_irqsave(&buffer_lock, flags);
- add_event_entry(ESCAPE_CODE);
- add_event_entry(SPU_CTX_SWITCH_CODE);
- add_event_entry(spu->number);
- add_event_entry(spu->pid);
- add_event_entry(spu->tgid);
- add_event_entry(app_dcookie);
- add_event_entry(spu_cookie);
- add_event_entry(offset);
- spin_unlock_irqrestore(&buffer_lock, flags);
- smp_wmb(); /* insure spu event buffer updates are written */
- /* don't want entries intermingled... */
+ /* save the spu contect info */
+ spus_cntxt_sw_data.spu_data[spu->number].spu = spu;
+ spus_cntxt_sw_data.spu_data[spu->number].app_dcookie = app_dcookie;
+ spus_cntxt_sw_data.spu_data[spu->number].spu_cookie = spu_cookie;
+ spus_cntxt_sw_data.spu_data[spu->number].offset = offset;
+ spus_cntxt_sw_data.spu_data[spu->number].objectId = objectId;
+ spus_cntxt_sw_data.spu_data[spu->number].valid_entry = 1;
+
+ queue_work(oprofile_spu_wq, &spus_cntxt_sw_data.spu_cntxt_work);
out:
return retval;
}
@@ -375,16 +457,30 @@ int spu_sync_start(void)
int k;
int ret = SKIP_GENERIC_SYNC;
int register_ret;
- unsigned long flags = 0;
spu_prof_num_nodes = number_of_online_nodes();
num_spu_nodes = spu_prof_num_nodes * 8;
- spin_lock_irqsave(&buffer_lock, flags);
- add_event_entry(ESCAPE_CODE);
- add_event_entry(SPU_PROFILING_CODE);
- add_event_entry(num_spu_nodes);
- spin_unlock_irqrestore(&buffer_lock, flags);
+ /* create private work queue, execution of work is time critical */
+ oprofile_spu_wq = create_workqueue("spu_oprofile");
+
+ /* due to a race when the spu is already running stuff, need to
+ * set a flag to tell the spu context switch to record the start
+ * before recording the context switches.
+ */
+ record_spu_start_flag = 1;
+
+ spus_profiling_code_data.num_spu_nodes = num_spu_nodes;
+
+ /* setup work queue functiion for recording context switch info */
+ spus_cntxt_sw_data.num_spu_nodes = num_spu_nodes;
+ for (k = 0; k<(MAX_NUMNODES * 8); k++) {
+ spus_cntxt_sw_data.spu_data[k].valid_entry = 0;
+ cnt_swtch_processed_flag[k] = 0;
+ }
+
+ INIT_WORK(&spus_cntxt_sw_data.spu_cntxt_work,
+ record_spu_process_switch);
/* Register for SPU events */
register_ret = spu_switch_event_register(&spu_active);
@@ -413,6 +509,17 @@ void spu_sync_buffer(int spu_num, unsign
unsigned long long spu_num_shifted = spu_num_ll << 32;
struct cached_info *c_info;
+ /* Do not record any samples until after the context switch
+ * for this SPU has been recorded. The daemon gets really
+ * confused.
+ */
+ if (!(cnt_swtch_processed_flag[spu_num]))
+ return;
+
+ /* note, the mutex lock on buffer_mutex has already been
+ * grabbed by the caller to this function.
+ */
+
/* We need to obtain the cache_lock here because it's
* possible that after getting the cached_info, the SPU job
* corresponding to this cached_info may end, thus resulting
@@ -432,7 +539,7 @@ void spu_sync_buffer(int spu_num, unsign
map = c_info->map;
the_spu = c_info->the_spu;
- spin_lock(&buffer_lock);
+
for (i = 0; i < num_samples; i++) {
unsigned int sample = *(samples+i);
int grd_val = 0;
@@ -452,9 +559,11 @@ void spu_sync_buffer(int spu_num, unsign
break;
}
+ /* add_event() protected by the mutex_lock(buffer_mutex) taken
+ * in routine profile_spus_record_samples()
+ */
add_event_entry(file_offset | spu_num_shifted);
}
- spin_unlock(&buffer_lock);
out:
spin_unlock_irqrestore(&cache_lock, flags);
}
@@ -463,7 +572,9 @@ out:
int spu_sync_stop(void)
{
unsigned long flags = 0;
+ int k;
int ret = spu_switch_event_unregister(&spu_active);
+
if (ret) {
printk(KERN_ERR "SPU_PROF: "
"%s, line %d: spu_switch_event_unregister returned %d\n",
@@ -475,6 +586,15 @@ int spu_sync_stop(void)
ret = release_cached_info(RELEASE_ALL);
spin_unlock_irqrestore(&cache_lock, flags);
out:
+ /* clear any pending spu cntx switch request */
+
+ for (k = 0; k<(MAX_NUMNODES * 8); k++)
+ if (spus_cntxt_sw_data.spu_data[k].valid_entry == 1)
+ pr_debug ("spu_sync_stop -- removed "\
+ "pending SPU sw req\n");
+
+ spus_cntxt_sw_data.spu_data[k].valid_entry = 0;
+
pr_debug("spu_sync_stop -- done.\n");
return ret;
}
^ permalink raw reply
* Re: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based platforms.
From: Scott Wood @ 2008-03-25 16:03 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803251634.50253.laurentp@cse-semaphore.com>
On Tue, Mar 25, 2008 at 04:34:46PM +0100, Laurent Pinchart wrote:
> On Tuesday 25 March 2008 15:58, Scott Wood wrote:
> > Please maintain backward compatibility with older device trees (by
> > checking the length of the second reg resource). At the very least,
> > update the device trees that are affected.
>
> I haven't seen any CPM2-based board using SMC ports in the device trees
> available in arch/powerpc/boot/dts.
ep8248e
> Should I still maintain compatibility with older device trees ? Is there any
> out-of-tree PQ2 boards using udbg and SMC ?
Yes, I've answered questions on the lists from at least one person using
a custom board with cpm2 smc.
> What about printing a warning if the second reg resource has the wrong
> size ?
The only way you'll see the warning is if udbg is enabled. :-P
Will a CPM reset blow away the portion of muram that holds the SMC pram
pointer? If not (and I don't think it will), just return the device tree
reg resource as is currently done if the resource is the wrong size.
> > After this point, even if you don't reset the CPM, udbg printk is broken
> > because you moved pram. The udbg disabling will have to be moved before
> > this.
>
> Moving the SMC pram doesn't break udbg printk in itself. What will break it is
> moving the TX BDs, but the end result is the same, moving pram will result in
> udbg being broken.
>
> The cpm_uart driver disable udbg before allocating the new BDs. What about
> moving that right before moving the parameter RAM ? cpm_uart_request_port(),
> which is called in between, already disables RX and TX on the port, so we
> won't loose any debug message.
cpm_uart_request_port() returns without doing that if it's a console
port. I think the current placement of the udbg disable will be fine.
-Scott
^ permalink raw reply
* how to use head_fsl_booke.S:abort to restart
From: Philippe De Muyter @ 2008-03-25 16:15 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I have a mpc8540 board that could reboot when driven by a ARCH=ppc linux,
but that hangs now in arch/powerpc/sysdev/fsl_soc.c:fsl_rstcr_restart when
asked to reboot with a ARCH=powerpc linux.
I have found that if I call arch/powerpc/kernel/head_fsl_booke.S:abort from
there, my board reboots correctly, but I feel that's not the right place
to put that call. Where/how should I do that ?
Philippe
PS : Does arch/powerpc/sysdev/fsl_soc.c:fsl_rstcr_restart actually work
for mpc8540_ads boards ?
^ permalink raw reply
* Re: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based platforms.
From: Laurent Pinchart @ 2008-03-25 16:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080325160331.GB15093@ld0162-tx32.am.freescale.net>
[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]
On Tuesday 25 March 2008 17:03, Scott Wood wrote:
> On Tue, Mar 25, 2008 at 04:34:46PM +0100, Laurent Pinchart wrote:
> > On Tuesday 25 March 2008 15:58, Scott Wood wrote:
> > > Please maintain backward compatibility with older device trees (by
> > > checking the length of the second reg resource). At the very least,
> > > update the device trees that are affected.
> >
> > I haven't seen any CPM2-based board using SMC ports in the device trees
> > available in arch/powerpc/boot/dts.
>
> ep8248e
I should have checked git head. My bad. I'll include the ep8248e device tree
in the next patch.
> > Should I still maintain compatibility with older device trees ? Is there
any
> > out-of-tree PQ2 boards using udbg and SMC ?
>
> Yes, I've answered questions on the lists from at least one person using
> a custom board with cpm2 smc.
Are you sure it wasn't me ? ;-)
> > What about printing a warning if the second reg resource has the wrong
> > size ?
>
> The only way you'll see the warning is if udbg is enabled. :-P
>
> Will a CPM reset blow away the portion of muram that holds the SMC pram
> pointer? If not (and I don't think it will), just return the device tree
> reg resource as is currently done if the resource is the wrong size.
Ok I'll do that. Should I add a warning message to tell people to update the
device tree ?
> > > After this point, even if you don't reset the CPM, udbg printk is broken
> > > because you moved pram. The udbg disabling will have to be moved before
> > > this.
> >
> > Moving the SMC pram doesn't break udbg printk in itself. What will break
it is
> > moving the TX BDs, but the end result is the same, moving pram will result
in
> > udbg being broken.
> >
> > The cpm_uart driver disable udbg before allocating the new BDs. What about
> > moving that right before moving the parameter RAM ?
cpm_uart_request_port(),
> > which is called in between, already disables RX and TX on the port, so we
> > won't loose any debug message.
>
> cpm_uart_request_port() returns without doing that if it's a console
> port. I think the current placement of the udbg disable will be fine.
Ok. I'll prepare a new patch that maintains compatibility with old device
trees.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: Sergei Shtylyov @ 2008-03-25 16:23 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, linuxppc-dev, linux-mtd, David Gibson
In-Reply-To: <200803251651.42608.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
>>>We're talking about a very specific type of RAM, used for permanent storage
>>>with a battery backup. The RAM is really meant to be used as an MTD device
>>>and as such I think it makes sense to describe it as an mtd-compatible device
>>>on the local bus.
>>>What about the following definition for the RAM node ?
>>> nvram@2,0000 {
>> Note that there's a OF "device_type" of "nvram", so your (generic) device
>>name seems to add some mess. (IIRC, that OF device type didn't actually
>>represent a "real" device, and only served to provide access to NVRAM for OF).
> Ok.
Well, I might have gone too far here -- it should be a real device
(spec'ed in Device Support Extensions recommended practice). It's just that
the spec didn't mention "reg" property, only "#bytes" (the device capacity).
So, it may be worth considering...
>>> compatible = "mtd,ram";
>> The part before comma should be a company name or a stock ticker. What did
>>you mean here?
> I didn't know that. Let's say I meant "mtd-ram" :-)
>>> reg = <2 0x0000 0x00100000>;
>>> bank-width = <2>;
>>> };
>>>Or should the node have a device-type property of either 'ram' or 'rom' with
>>>the compatible property just referencing MTD ?
>> The "device_type" properties are not required and their further creation
>>has been discouraged on liunxppc-dev.
> What about
> mtdram@2,0000 {
> compatible = "mtd-ram";
> reg = <2 0x0000 0x00100000>;
> bank-width = <2>;
> };
> ROMs could use "mtd-rom" for their compatible property.
Heh, there was a whole company against mentioning "mtd" when we started
working on this (of course, the first idea was to call the flash device type
"mtd"). I don't think "mtd" looks good here -- I'd suggest "flash-ram" (if
this is just a linearly mapped NVRAM).
> Best regards,
WBR, Sergei
^ permalink raw reply
* RE: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports onCPM2-based platforms.
From: Rune Torgersen @ 2008-03-25 16:27 UTC (permalink / raw)
To: Laurent Pinchart, Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <200803251720.24667.laurentp@cse-semaphore.com>
>Laurent Pinchart wrote:
> On Tuesday 25 March 2008 17:03, Scott Wood wrote:
>> Yes, I've answered questions on the lists from at least one person
>> using a custom board with cpm2 smc.
>=20
> Are you sure it wasn't me ? ;-)
>=20
Probably me, actually. We have a 8280 with SMC's in use (SMC1 and 2)
^ permalink raw reply
* Re: [PATCH] cpm_uart: Allocate DPRAM memory for SMC ports onCPM2-based platforms.
From: Laurent Pinchart @ 2008-03-25 16:32 UTC (permalink / raw)
To: Rune Torgersen; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B04276FB4@ismail.innsys.innovsys.com>
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
On Tuesday 25 March 2008 17:27, Rune Torgersen wrote:
> >Laurent Pinchart wrote:
> > On Tuesday 25 March 2008 17:03, Scott Wood wrote:
> >> Yes, I've answered questions on the lists from at least one person
> >> using a custom board with cpm2 smc.
> >
> > Are you sure it wasn't me ? ;-)
> >
>
> Probably me, actually. We have a 8280 with SMC's in use (SMC1 and 2)
Ok.
Do you have any opinion about the proposed patch ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: how to use head_fsl_booke.S:abort to restart
From: Haiying Wang @ 2008-03-25 16:34 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: linuxppc-dev
In-Reply-To: <20080325161513.GB15991@frolo.macqel>
8540 doesn't have RSTCR register. You should not use fsl_rstcr_restart
for reboot your 8540 board.
Haiying
On Tue, 2008-03-25 at 17:15 +0100, Philippe De Muyter wrote:
> Hi all,
>
> I have a mpc8540 board that could reboot when driven by a ARCH=ppc linux,
> but that hangs now in arch/powerpc/sysdev/fsl_soc.c:fsl_rstcr_restart when
> asked to reboot with a ARCH=powerpc linux.
>
> I have found that if I call arch/powerpc/kernel/head_fsl_booke.S:abort from
> there, my board reboots correctly, but I feel that's not the right place
> to put that call. Where/how should I do that ?
>
> Philippe
>
> PS : Does arch/powerpc/sysdev/fsl_soc.c:fsl_rstcr_restart actually work
> for mpc8540_ads boards ?
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox