[PATCH] IB/ehca: Change misleading error message
The error message printed when the eHCA driver prevents memory hotplug is misleading -- the user might think that hot-removing the lhca, hotplugging memory, then hot-adding the lhca again will work, but it doesn't. Signed-off-by: Joachim Fenkes [EMAIL PROTECTED] --- drivers/infiniband/hw/ehca/ehca_main.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c index bb02a86..bec7e02 100644 --- a/drivers/infiniband/hw/ehca/ehca_main.c +++ b/drivers/infiniband/hw/ehca/ehca_main.c @@ -994,8 +994,7 @@ static int ehca_mem_notifier(struct notifier_block *nb, if (printk_timed_ratelimit(ehca_dmem_warn_time, 30 * 1000)) ehca_gen_err(DMEM operations are not allowed -as long as an ehca adapter is -attached to the LPAR); +in conjunction with eHCA); return NOTIFY_BAD; } } -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: 8572E - machine check pin (MCP0)
I wrote: snip some things I have an external watchdog timer that is going off - and pulsing into the MCP0 of the 8572E. I get the printk indicating that the MCP0 went off - the problem is - how do I clear the condition that caused this because my hardware engineer swears that the pulse is ONLY 250ms - and after resetting several status registers (mcpsumr rst (because my hardware engineer swears that the pulse is ONLY 250ms long (and I have a delay after my printk of 250ms)) - so I am pretty sure I am resetting the conditions mcpsumr (also, extra: the rstsr), but after writing mcpsumr - and reading back - it still has the mcp0 bit set? snip more Trent wrote: SRESET# also sets MCP0 and MCP1, maybe that is on? I'd also check the EMCP bit in SPRN_HID0 (on core 0 for MCP0). I think SRESET is a separate signal - and even if it was ON (which it shouldn't be) - it should show up in the MCPSUMR Register (and I am clearing that condition)... I am getting the first machine check (with an indication that the MCP0 is pulled) - I don't think you can get a Machine check without SPRN_HID0's EMCP being set? The only thing that I am thinking is that I have two edges, and after returning from the machine check (first time) the ME bit is NOT enabled, so when the falling edge of that pulse occurs, it causes another machine check - which because ME bit is NOT set it causes a checkstop - and it goes away... That explains why it hangs for the second machine check - although it still 'starts' into the machine check handler before dying very early in its execution (before it does a full dump of registers)... very strange stuff here... Tom ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
AW: [PATCH]: [MPC5200] Add ATA DMA support
Tim, Grant, just an info. Very often the Bestcomm-FEC crashed without any error logs if I initiate a transaction over FEC and save the file to disk (I rememeber I have read something like that). A restart of FEC don't work. But no I figured out, if I connect to the other ethernet port of our board (natsemi) the FEC will awake to life again, if I initiate a new transaction over natsemi. This seems a little oddly to me. Cheers Mit freundlichen Grüßen Hans Lehmann Softwareentwicklung Telefon +49 (0)2191-67-2520 Fax +49 (0)2191-67-703408 e-mail [EMAIL PROTECTED] Ritter Elektronik GmbH Leverkuser Straße 65 D-42897 Remscheid www.ritter-elektronik.de http://www.ritter-elektronik.de/start.html Geschäftsführer: Manfred A. Wagner, Dr. Uwe Baader Sitz der Gesellschaft: Oberhausen HRB 17168 Duisburg / USt-ID DE 814009849 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH]: [MPC5200] Add ATA DMA support
On Tue, Nov 25, 2008 at 8:45 AM, Lehmann, Hans (Ritter Elektronik) [EMAIL PROTECTED] wrote: Tim, Grant, just an info. Very often the Bestcomm-FEC crashed without any error logs if I initiate a transaction over FEC and save the file to disk (I rememeber I have read something like that). A restart of FEC don't work. But no I figured out, if I connect to the other ethernet port of our board (natsemi) the FEC will awake to life again, if I initiate a new transaction over natsemi. This seems a little oddly to me. Hi guys, We tried to get the SUSE guys to push the patch into openSUSE 11.1 release and the tests came back negative here too with regards to FEC support; for some odd reason, it does this; https://bugzilla.novell.com/show_bug.cgi?id=445856#c10 There is some weird interaction here, but I can't imagine what it might be. Tim, did you ever see any ethernet problems like this? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
AW: [PATCH]: [MPC5200] Add ATA DMA support
Tim, Grant here are some more information. I think there is a also a problem with memory after FEC crasched. [EMAIL PROTECTED]:~ free total used free shared buffers Mem: 12710026424 1006760 432 Swap:000 Total: 12710026424 100676 [EMAIL PROTECTED]:~ [EMAIL PROTECTED]:~ [EMAIL PROTECTED]:~ ifdown eth0 net eth0: queues didn't drain net eth0: tx: index: 10, outdex: 6 net eth0: rx: index: 117, outdex: 118 [EMAIL PROTECTED]:~ ifup eth0 net eth0: attached phy 0 to driver Generic PHY [EMAIL PROTECTED]:~ freePHY: f0003000:00 - Link is Up - 100/Full [EMAIL PROTECTED]:~ free total used free shared buffers Mem: 12710035028920720 760 Swap:000 Total: 1271003502892072 Cheers Mit freundlichen Grüßen Hans Lehmann Softwareentwicklung Telefon +49 (0)2191-67-2520 Fax +49 (0)2191-67-703408 e-mail [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Ritter Elektronik GmbH Leverkuser Straße 65 D-42897 Remscheid www.ritter-elektronik.de http://www.ritter-elektronik.de/start.html Geschäftsführer: Manfred A. Wagner, Dr. Uwe Baader Sitz der Gesellschaft: Oberhausen HRB 17168 Duisburg / USt-ID DE 814009849 Von: Matt Sealey [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 25. November 2008 16:19 An: Lehmann, Hans (Ritter Elektronik) Cc: Tim Yamin; Grant Likely; linuxppc-dev@ozlabs.org Betreff: Re: [PATCH]: [MPC5200] Add ATA DMA support On Tue, Nov 25, 2008 at 8:45 AM, Lehmann, Hans (Ritter Elektronik) [EMAIL PROTECTED] wrote: Tim, Grant, just an info. Very often the Bestcomm-FEC crashed without any error logs if I initiate a transaction over FEC and save the file to disk (I rememeber I have read something like that). A restart of FEC don't work. But no I figured out, if I connect to the other ethernet port of our board (natsemi) the FEC will awake to life again, if I initiate a new transaction over natsemi. This seems a little oddly to me. Hi guys, We tried to get the SUSE guys to push the patch into openSUSE 11.1 release and the tests came back negative here too with regards to FEC support; for some odd reason, it does this; https://bugzilla.novell.com/show_bug.cgi?id=445856#c10 There is some weird interaction here, but I can't imagine what it might be. Tim, did you ever see any ethernet problems like this? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v5] spi: Add PPC4xx SPI driver
This adds a SPI driver for the SPI controller found in the IBM/AMCC
4xx PowerPC's.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
Signed-off-by: Wolfgang Ocker [EMAIL PROTECTED]
Acked-by: Josh Boyer [EMAIL PROTECTED]
---
Changes in v5:
- Don't call setupxfer() from setup() so that the baudrate etc
won't get changed while another transfer is active, as suggested
by David Brownell.
- module_{init,exit} moved directly to the functions to which they
apply.
- Use __func__ instead of __FUNCTION__.
Changes in v4:
- Added fixes suggested by Josh Boyer
- Changed compatible property from ibm,spi to ibm,ppc4xx-spi
Changes in v3:
- When the device is removed the GPIOs are released. The memory
for the GPIO array is freed.
Changes in v2:
- Now the gpios property is correctly decoded and the
resulting gpio numbers are used as the devices chip
selects.
drivers/spi/Kconfig |7 +
drivers/spi/Makefile |1 +
drivers/spi/spi_ppc4xx.c | 597 ++
3 files changed, 605 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/spi_ppc4xx.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index b9d0efb..69d5fee 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -155,6 +155,13 @@ config SPI_ORION
help
This enables using the SPI master controller on the Orion chips.
+config SPI_PPC4xx
+ tristate PPC4xx SPI Controller
+ depends on 4xx SPI_MASTER
+ select SPI_BITBANG
+ help
+ This selects a driver for the PPC4xx SPI Controller.
+
config SPI_PXA2XX
tristate PXA2xx SSP SPI master
depends on ARCH_PXA EXPERIMENTAL
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index ccf18de..a2e5816 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_SPI_OMAP24XX)+= omap2_mcspi.o
obj-$(CONFIG_SPI_ORION)+= orion_spi.o
obj-$(CONFIG_SPI_MPC52xx_PSC) += mpc52xx_psc_spi.o
obj-$(CONFIG_SPI_MPC83xx) += spi_mpc83xx.o
+obj-$(CONFIG_SPI_PPC4xx) += spi_ppc4xx.o
obj-$(CONFIG_SPI_S3C24XX_GPIO) += spi_s3c24xx_gpio.o
obj-$(CONFIG_SPI_S3C24XX) += spi_s3c24xx.o
obj-$(CONFIG_SPI_TXX9) += spi_txx9.o
diff --git a/drivers/spi/spi_ppc4xx.c b/drivers/spi/spi_ppc4xx.c
new file mode 100644
index 000..e46292b
--- /dev/null
+++ b/drivers/spi/spi_ppc4xx.c
@@ -0,0 +1,597 @@
+/*
+ * SPI_PPC4XX SPI controller driver.
+ *
+ * Copyright (C) 2007 Gary Jennejohn [EMAIL PROTECTED]
+ * Copyright 2008 Stefan Roese [EMAIL PROTECTED], DENX Software Engineering
+ *
+ * Based in part on drivers/spi/spi_s3c24xx.c
+ *
+ * Copyright (c) 2006 Ben Dooks
+ * Copyright (c) 2006 Simtec Electronics
+ * Ben Dooks [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/sched.h
+#include linux/errno.h
+#include linux/wait.h
+#include linux/of_platform.h
+#include linux/of_spi.h
+#include linux/of_gpio.h
+#include linux/interrupt.h
+#include linux/delay.h
+
+#include linux/gpio.h
+#include linux/spi/spi.h
+#include linux/spi/spi_bitbang.h
+
+#include asm/io.h
+#include asm/dcr.h
+#include asm/dcr-regs.h
+
+/* bits in mode register - bit 0 ist MSb */
+/* data latched on leading edge of clock, else trailing edge */
+#define SPI_PPC4XX_MODE_SCP(0x80 3)
+/* port enabled */
+#define SPI_PPC4XX_MODE_SPE(0x80 4)
+/* MSB first, else LSB first */
+#define SPI_PPC4XX_MODE_RD (0x80 5)
+/* clock invert - idle clock = 1, active clock = 0; else reversed */
+#define SPI_PPC4XX_MODE_CI (0x80 6)
+/* loopback enable */
+#define SPI_PPC4XX_MODE_IL (0x80 7)
+/* bits in control register */
+/* starts a transfer when set */
+#define SPI_PPC4XX_CR_STR (0x80 7)
+/* bits in status register */
+/* port is busy with a transfer */
+#define SPI_PPC4XX_SR_BSY (0x80 6)
+/* RxD ready */
+#define SPI_PPC4XX_SR_RBR (0x80 7)
+
+/* the spi-mode bits understood by this driver: */
+#define MODEBITS (SPI_CPHA | SPI_CPOL | SPI_CS_HIGH | SPI_LSB_FIRST)
+
+/* clock settings (SCP and CI) for various SPI modes */
+#define SPI_CLK_MODE0 SPI_PPC4XX_MODE_SCP
+#define SPI_CLK_MODE1 0
+#define SPI_CLK_MODE2 SPI_PPC4XX_MODE_CI
+#define SPI_CLK_MODE3 (SPI_PPC4XX_MODE_SCP | SPI_PPC4XX_MODE_CI)
+
+#define DRIVER_NAMEspi_ppc4xx_of
+
+struct spi_ppc4xx_regs {
+ u8 mode;
+ u8 rxd;
+ u8 txd;
+ u8 cr;
+ u8 sr;
+ u8 dummy;
+ /*
+* Clock divisor modulus register
+* This uses the follwing formula:
+*SCPClkOut = OPBCLK/(4(CDM + 1))
+* or
+*CDM = (OPBCLK/4*SCPClkOut) - 1
+* bit 0 is the MSb!
+*/
+ u8 cdm;
+};
+
+/* SPI Controller driver's
Re: [Patch 2/3] OProfile SPU event profiling support for IBM Cell processor
On Tuesday 25 November 2008, Carl Love wrote: This patch basically rearranges the code a bit to make it easier to just add the needed SPU event based profiling routines. The second kernel patch contains the new spu event based profiling code. The cleanup looks fine, but should get a unique patch name, e.g. '[PATCH 2/3] powerpc/cell/oprofile: clean up event handling' to make the shortlog more meaningful. No need to mention in the changelog what the other patch does. Please mention that this patch is not supposed to change any behaviour. Signed-off-by: Carl Love [EMAIL PROTECTED] Acked-by: Arnd Bergmann [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch 3/3] OProfile SPU event profiling support for IBM Cell processor
On Tuesday 25 November 2008, Carl Love wrote:
This is the second of the two kernel patches for adding SPU profiling
for the IBM Cell processor. This patch contains the spu event profiling
setup, start and stop routines.
Signed-off-by: Carl Love [EMAIL PROTECTED]
Maybe a little more detailed description would be good. Explain
what this patch adds that isn't already there and why people would
want to have that in the kernel.
static void cell_global_stop_spu_cycles(void);
+static void cell_global_stop_spu_events(void);
Can you reorder the functions so that you don't need any forward
declarations? In general, it gets easier to understand if the
definition order matches the call graph.
static unsigned int spu_cycle_reset;
static unsigned int profiling_mode;
-
+static int spu_evnt_phys_spu_indx;
struct pmc_cntrl_data {
unsigned long vcntr;
@@ -111,6 +126,8 @@ struct pm_cntrl {
u16 trace_mode;
u16 freeze;
u16 count_mode;
+ u16 spu_addr_trace;
+ u8 trace_buf_ovflw;
};
static struct {
@@ -128,7 +145,7 @@ static struct {
#define GET_INPUT_CONTROL(x) ((x 0x0004) 2)
static DEFINE_PER_CPU(unsigned long[NR_PHYS_CTRS], pmc_values);
-
+static unsigned long spu_pm_cnt[MAX_NUMNODES * NUM_SPUS_PER_NODE];
static struct pmc_cntrl_data pmc_cntrl[NUM_THREADS][NR_PHYS_CTRS];
Can't you add this data to an existing data structure, e.g. struct spu,
rather than adding a new global?
static u32 reset_value[NR_PHYS_CTRS];
static int num_counters;
static int oprofile_running;
-static DEFINE_SPINLOCK(virt_cntr_lock);
+static DEFINE_SPINLOCK(cntr_lock);
static u32 ctr_enabled;
@@ -242,7 +260,6 @@ static int pm_rtas_activate_signals(u32
i = 0;
for (j = 0; j count; j++) {
if (pm_signal[j].signal_group != PPU_CYCLES_GRP_NUM) {
-
/* fw expects physical cpu # */
pm_signal_local[i].cpu = node;
pm_signal_local[i].signal_group
@@ -265,7 +282,6 @@ static int pm_rtas_activate_signals(u32
return -EIO;
}
}
-
return 0;
}
These look like a cleanups that should go into the first patch, right?
+static void spu_evnt_swap(unsigned long data)
This function could use a comment about why we need to swap and what
the overall effect of swapping is.
int spu_prof_running;
static unsigned int profiling_interval;
+DEFINE_SPINLOCK(oprof_spu_smpl_arry_lck);
+unsigned long oprof_spu_smpl_arry_lck_flags;
#define NUM_SPU_BITS_TRBUF 16
#define SPUS_PER_TB_ENTRY 4
+#define SPUS_PER_NODE 8
#define SPU_PC_MASK 0x
-static DEFINE_SPINLOCK(sample_array_lock);
-unsigned long sample_array_lock_flags;
-
This also looks like a rename that should go into the first patch.
+/*
+ * Entry point for SPU event profiling.
+ * NOTE: SPU profiling is done system-wide, not per-CPU.
+ *
+ * cycles_reset is the count value specified by the user when
+ * setting up OProfile to count SPU_CYCLES.
+ */
+void start_spu_profiling_events(void)
+{
+ spu_prof_running = 1;
+ schedule_delayed_work(spu_work, DEFAULT_TIMER_EXPIRE);
+
+ return;
+}
+
+void stop_spu_profiling_cycles(void)
{
spu_prof_running = 0;
hrtimer_cancel(timer);
kfree(samples);
- pr_debug(SPU_PROF: stop_spu_profiling issued\n);
+ pr_debug(SPU_PROF: stop_spu_profiling_cycles issued\n);
+}
+
+void stop_spu_profiling_events(void)
+{
+ spu_prof_running = 0;
}
Is this atomic? What if two CPUs access the spu_prof_running variable at
the same time?
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch 0/3] OProfile SPU event profiling support for IBM Cell processor
On Tuesday 25 November 2008, Carl Love wrote: This patch set consists of two kernel patches and one user level patch to add SPU event based profiling support to OProfile for the IBM Cell processor. The first patch in the series is the user level patch that adds the needed events and event checking to the user tool. The second patch is the first of two kernel patches. It makes some structural changes to the kernel code to make it easier to add the specific functions for doing SPU event profiling. The first kernel patch does not make any functional changes. The third patch in the series is the second kernel patch where the actual SPU event profiling code support is added to the kernel. Thanks for your submission! I can't comment on the oprofile user code, but I have some comments on the implementation in the third patch. Are the patches interdependent, or will old versions of the oprofile tool work with new kernels and vice versa? Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: badness in xics_set_cpu_giq on JS20 blade
On Nov 22, 2008, at 6:26 PM, Nathan Lynch wrote:
Milton Miller wrote:
On Sat Nov 22 at 14:06:53 EST in 2008, Nathan Lynch wrote:
With 2.6.28-rc5 the WARN_ON in xics_set_cpu_giq is triggering on a
JS20. I changed it to a WARN to get the actual status returned:
b4963255ad5a426f04a0bb15c4315fa4bb40cde9 Factor out cpu
joining/unjoining the GIQ consolidated the join and remove call
sites.
Looking closer it also added warn if rtas-indicator returned an error
on
join in addition to leave.
Thanks, that makes it clear why we didn't see the warning before.
When we get control of a cpu from OF it is already in the joined
state.
We join on all threads because we need to do so on secondary threads
and
because we did a remove on (previously all, but now secondary) threads
during kexec.
If memory serves, there is a property in the rtas node to indicate
each
sensor that is present. If so, we should search for that property
before calling set-indicator.
I checked PAPR; it looks like we should be looking for an
rtas-indicators property, which doesn't exist on this system. It does
exist on Power5 and Power6 systems I've checked, and it has the
expected entry for GIQ (9005).
Something like this? I've booted it on the problem JS20 as well as
Power5 and 6.
Pretty close. We need to turn the above text into a changelog and a
few comments below.
We should also check JS21 and cell blade.
arch/powerpc/include/asm/rtas.h |1 +
arch/powerpc/kernel/rtas.c| 22 ++
arch/powerpc/platforms/pseries/xics.c | 11 ---
3 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/rtas.h
b/arch/powerpc/include/asm/rtas.h
index 8eaa7b2..4846f1f 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -168,6 +168,7 @@ extern void rtas_os_term(char *str);
extern int rtas_get_sensor(int sensor, int index, int *state);
extern int rtas_get_power_level(int powerdomain, int *level);
extern int rtas_set_power_level(int powerdomain, int level, int
*setlevel);
+extern bool rtas_indicator_present(int indicator);
extern int rtas_set_indicator(int indicator, int index, int
new_value);
extern int rtas_set_indicator_fast(int indicator, int index, int
new_value);
extern void rtas_progress(char *s, unsigned short hex);
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 1f8505c..6cd2434 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -566,6 +566,28 @@ int rtas_get_sensor(int sensor, int index, int
*state)
}
EXPORT_SYMBOL(rtas_get_sensor);
+bool rtas_indicator_present(int indicator)
+{
+ int proplen, count, i;
+ const struct indicator_elem {
+ u32 token;
+ u32 maxindex;
+ } *indicators;
+
+ indicators = of_get_property(rtas.dev, rtas-indicators, proplen);
+ if (!indicators)
+ return false;
+
+ count = proplen / sizeof(struct indicator_elem);
+
+ for (i = 0; i count; i++)
+ if (indicators[i].token == indicator)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(rtas_indicator_present);
I didn't look at the stuff we do to create the indicator directory in
/proc/rtas. Should this take an optional pointer arg to return the max
count? Just noticing that we are ignoring the count parameter.
+
int rtas_set_indicator(int indicator, int index, int new_value)
{
int token = rtas_token(set-indicator);
diff --git a/arch/powerpc/platforms/pseries/xics.c
b/arch/powerpc/platforms/pseries/xics.c
index e190477..7f8fa33 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -728,9 +728,14 @@ static void xics_set_cpu_priority(unsigned char
cppr)
/* Have the calling processor join or leave the specified global
queue */
static void xics_set_cpu_giq(unsigned int gserver, unsigned int join)
{
- int status = rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
- (1UL interrupt_server_size) - 1 - gserver, join);
- WARN_ON(status 0);
+ int status;
+
+ if (!rtas_indicator_present(GLOBAL_INTERRUPT_QUEUE))
+ return;
I was thinking we would cache this result, but we don't save the token
for rtas_set_indicator_fast and we only call this twice per cpu on each
kernel (startup and kexec) so I'm ok with it. (Athought it points out
we are parsing the device tree in the kdump path).
+
+ status = rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
+ (1UL interrupt_server_size) - 1 - gserver, join);
+ WARN(status 0, set-indicator returned %d\n, status);
This WARN should at least indicate which indicator we are trying to set
(GLOBAL_INTERRUPT_QUEUE), if not the number (which is likely to always
be 0 and not checked by current firmware). That way we won't have to
remember that the set-indicator in xics.c
[PATCH] powerpc/40x: Add proper BOOTCFLAGS for cuboot-acadia
The cuboot-acadia.c wrapper can cause assembler errors on some toolchains due to the lack of the proper BOOTCFLAGS. This adds the proper flags for the file. Signed-off-by: Josh Boyer [EMAIL PROTECTED] --- diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 8fc6d72..3d3daa6 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -41,6 +41,7 @@ $(obj)/4xx.o: BOOTCFLAGS += -mcpu=405 $(obj)/ebony.o: BOOTCFLAGS += -mcpu=405 $(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=405 $(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=405 +$(obj)/cuboot-acadia.o: BOOTCFLAGS += -mcpu=405 $(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405 $(obj)/virtex405-head.o: BOOTAFLAGS += -mcpu=405 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Better setup of boot page TLB entry
On Nov 23, 2008, at 11:01 PM, Kumar Gala wrote: On Nov 22, 2008, at 10:01 PM, Trent Piepho wrote: On Sat, 22 Nov 2008, Milton Miller wrote: On Thu Nov 20 at 06:14:30 EST in 2008, Trent Piepho wrote: - li r7,0 - lis r6,PAGE_OFFSET at h - ori r6,r6,PAGE_OFFSET at l - rlwimi r6,r7,0,20,31 + lis r6,MAS2_VAL(PAGE_OFFSET, BOOKE_PAGESZ_64M, M_IF_SMP)@h + ori r6,r6,MAS2_VAL(PAGE_OFFSET, BOOKE_PAGESZ_64M, M_IF_SMP)@l I'm fine with this part, even if the expression is a bit long. You might consider using LOAD_REG_IMMEDIATE from asm/ppc_asm.h to avoid duplicating the expression. LOAD_REG_IMMEDIATE isn't used at all in that file, while lis/ori is used many times. In fact, there only one call of LOAD_REG_IMMEDIATE in all of arch/powerpc/kernel/*.S. So I think lis/ori is more easily recognized. And to be honest, I find switching syntax from assembly language instructions to C style macros that generate instructions to be aesthetically ugly. The macro is more useful for the 64 bit case where it uses its arguemnt 4 times. The usage was severely reduced with the 64 bit relocatable patch, where *IMMEDIATE was not relocated but LOAD_ADDR was. It would be nice if the assembler provided a liw macro instruction that would load an immediate. When the assembler knows the immediate value, it could even generate shorter sequences in some cases, like when the upper 16 bits are all zero. One thing that is nice about powerpc assembly is that all instructions and macros are fixed length. That means we don't need to do multiple passes to figure out how many bytes we need for that source line. In fact, I think all the standard macros are just alias formatting of one instruction. At a minimum, you would only want the zero detection when it was a constant. I agree lis/ori is what should be used in this file and am not interested in changing it at this point. It was only a light consider comment and would not have prompted the email. /* 7. Jump to KERNELBASE mapping */ - lis r6,KERNELBASE at h - ori r6,r6,KERNELBASE at l - rlwimi r6,r7,0,20,31 + lis r6,(KERNELBASE ~0xfff)@h + ori r6,r6,(KERNELBASE ~0xfff)@l Why do you need to mask off the bottom bits of KERNEL_BASE? Just trying to keep the instruction effect identical? Yes, so it was clear I wasn't changing what the code did here. And to make it clear we only wanted the page number from KERNEL_BASE. It's an obvious expression and a compile time constant, merely saving a few characters in the source doesn't seem worth much. I realize it's unnecessary since those bits get masked off in the wlwimi a few instructions later. You realize it after studying the code, but the next person reading may not. My take is putting this longer expression makes the code harder to read and a changelog comment pointing out that the lower bits are overwritten would have eliminated the need for this ugly expression. Really all I wanted to fix the was memory coherency on SMP bug. But the code for MAS2 was stupid, so I had to change that to fix the bug in a non-ugly way. But then r7 didn't need to be zeroed and the (unnecessary) rlwimi r6,r7,0,20,31 would no longer be doing what's it's supposed to, so I fixed that too. First of all, if its not aligned, then its likely other parts of the kernel will break. We could put a BUILD_BUG_ON somewhere (in c) if that check is required. I seems like Require KERNEL_BASE to be page aligned and modify code to depend on said requirement belongs in another patch. Well, I could write one, but I don't have any hardware to test. And the above code depends on the alignement, by the fact that it inserts the 4k offset into kernel base. - addir6,r6,24 + addir6,r6,(2f - 1b) and while doing assembler math is better than the hand computed 24, how about doing li r9,[EMAIL PROTECTED] and just inserting that into r6? Unless you expect step 8 to cross a page from the 1b label above. But if you are that close to a page boundary than assuming 1b is in the page at KERNEL_BASE would seem to be suspect. For that matter, just do LOAD_ADDR(2f) or LOAD_REG_IMMEDIATE(2f), which would give the same result, as KERNEL_BASE should be reflected the linked address of the kernel (I assume that you are not doing dynamic runtime relocation like ppc64 on the code up to here, otherwise the previous suggestion still works). I'm not sure if this code can be relocated or not. If it isn't now, using non-position independent code won't make it any easier to make it relocatable. It looks like the bl 1f ; 1: mflr sequence is used 13 times in arch/powerpc/kernel/*.S, I wonder if all of them are unnecessary? We support relocation of this kernel so any changes need to be tried out w/CONFIG_RELOCATABLE enabled. The question was not does the kernel support
Re: [PATCH] [v3] powerpc/4xx: work around CHIP11 errata in a more PAGE_SIZE-friendly way
On Nov 24, 2008, at 6:10 PM, Michael Ellerman wrote: On Mon, 2008-11-24 at 14:07 -0600, Hollis Blanchard wrote: On Fri, 2008-11-14 at 16:09 -0600, Hollis Blanchard wrote: If this is all too much, then I'm close to giving up and burning a 64KB page, which requires only ALIGN_DOWN() in the kernel. ppc: force memory size to be a multiple of PAGE_SIZE Ensure that total memory size is page-aligned, because otherwise bootmem.c gets upset. This error case was triggered by using 64 KiB pages in the kernel while arch/powerpc/boot/4xx.c arbitrarily reduced the amount of memory by 4096 (to work around the CHIP11 errata which affects the last 256 bytes of physical memory). Signed-off-by: Hollis Blanchard [EMAIL PROTECTED] --- This is on a common code path, and lmb_enforce_memory_limit() will now always take action, so wider testing would be good. This patch supercedes http://patchwork.ozlabs.org/patch/8211/ . diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c --- a/arch/powerpc/kernel/prom.c +++ b/arch/powerpc/kernel/prom.c @@ -1200,6 +1200,11 @@ void __init early_init_devtree(void *par early_reserve_mem(); phyp_dump_reserve_mem(); + /* Ensure that total memory size is page-aligned, because otherwise +* bootmem.c gets upset. */ + lmb_analyze(); + memory_limit = lmb_phys_mem_size() PAGE_MASK; All of the current code using memory_limit looks like it'll be safe with this change, although there are several cases of this we could remove: if (memory_limit some other condition) Because memory_limit will now always be true. memory_limit was the result of parsing mem= from the command line. Does this break that? Still, I think it would be better to only set memory_limit when the mem size is not a multiple of the PAGE_SIZE - so that memory_limit retains it's function as both the value of the limit and a boolean. I would have expected this trimming to occur where we actually transfer the memory from lmb to bootmem, since it is bootmem that has the aligned size requirement. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
This merges support for the previously DENX-only kernel feature of
specifying an alternative, external buffer for kernel printk
messages and their associated metadata. In addition, this ports
architecture support for this feature from arch/ppc to arch/powerpc.
Signed-off-by: Grant Erickson [EMAIL PROTECTED]
---
When this option is enabled, an architecture- or machine-specific log
buffer is used for all printk messages. This allows entities such as
boot loaders (e.g. U-Boot) to place printk-compatible messages into
this buffer and for the kernel to coalesce them with its normal
messages.
The code has historically been used and proven to work on the LWMON5
platform under arch/ppc and is now used (by me) successfully on the
AMCC Haleakala and Kilauea platforms.
As implemented for arch/powerpc, two suboptions for the alternative
log buffer are supported. The buffer may be contiguous with the
metadata and message data colocated or the metadata and message
storage may be in discontiguous regions of memory (e.g. a set of
scratch registers and an SRAM buffer). On Kilauea and Haleakala, I
have used the former; whereas LWMON5 has traditionally used the latter.
The code here is, more or less, as-is from the DENX GIT tree. Comments
welcome.
arch/powerpc/kernel/prom.c | 93 +++
include/linux/logbuff.h| 56
init/Kconfig | 25 +++
init/main.c|4 +
kernel/printk.c| 149 +++-
5 files changed, 324 insertions(+), 3 deletions(-)
create mode 100644 include/linux/logbuff.h
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 3a2dc7e..60282f1 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -32,6 +32,7 @@
#include linux/debugfs.h
#include linux/irq.h
#include linux/lmb.h
+#include linux/logbuff.h
#include asm/prom.h
#include asm/rtas.h
@@ -61,6 +62,15 @@
#define DBG(fmt...)
#endif
+#ifdef CONFIG_LOGBUFFER
+#ifdef CONFIG_ALT_LB_LOCATION
+# if !defined(BOARD_ALT_LH_ADDR) || !defined(BOARD_ALT_LB_ADDR)
+# error Please specify BOARD_ALT_LH_ADDR BOARD_ALT_LB_ADDR.
+# endif
+#else /* !CONFIG_ALT_LB_LOCATION */
+static phys_addr_t ext_logbuff;
+#endif /* CONFIG_ALT_LB_LOCATION */
+#endif /* CONFIG_LOGBUFFER */
static int __initdata dt_root_addr_cells;
static int __initdata dt_root_size_cells;
@@ -1018,6 +1028,85 @@ static int __init early_init_dt_scan_memory(unsigned
long node,
return 0;
}
+#ifdef CONFIG_LOGBUFFER
+#ifdef CONFIG_ALT_LB_LOCATION
+/* Alternative external log buffer mapping: log metadata header the
+ * character buffer are separated and allocated not in RAM but in some
+ * other memory-mapped I/O region (e.g. log head in unused registers,
+ * and log buffer in OCM memory)
+ */
+int __init setup_ext_logbuff_mem(volatile logbuff_t **lhead, char **lbuf)
+{
+ void *h, *b;
+
+ if (unlikely(!lhead) || unlikely(!lbuf))
+ return -EINVAL;
+
+ /* map log head */
+ h = ioremap(BOARD_ALT_LH_ADDR, sizeof(logbuff_t));
+ if (unlikely(!h))
+ return -EFAULT;
+
+ /* map log buffer */
+ b = ioremap(BOARD_ALT_LB_ADDR, LOGBUFF_LEN);
+ if (unlikely(!b)) {
+ iounmap(h);
+ return -EFAULT;
+ }
+
+ *lhead = h;
+ *lbuf = b;
+
+ return 0;
+}
+#else /* !CONFIG_ALT_LB_LOCATION */
+/* Usual external log-buffer mapping: log metadata header the character
+ * buffer are both contiguous in system RAM.
+ */
+int __init setup_ext_logbuff_mem(logbuff_t **lhead, char **lbuf)
+{
+ void *p;
+
+ if (unlikely(!lhead) || unlikely(!lbuf))
+ return -EINVAL;
+
+ if (unlikely(!ext_logbuff) || !lmb_is_reserved(ext_logbuff))
+ return -EFAULT;
+
+ p = ioremap(ext_logbuff, LOGBUFF_RESERVE);
+
+ if (unlikely(!p))
+ return -EFAULT;
+
+ *lhead = (logbuff_t *)(p + LOGBUFF_OVERHEAD -
+ sizeof(logbuff_t) +
+ sizeof(((logbuff_t *)0)-buf));
+ *lbuf = (*lhead)-buf;
+
+ return 0;
+}
+
+/* When the external log buffer configuration is used with the
+ * non-alternate location, the log head metadata and character buffer
+ * lie in the LOGBUFF_RESERVE bytes at the end of system RAM. Add this
+ * block of memory to the reserved memory pool so that it is not
+ * allocated for other purposes.
+ */
+static void __init reserve_ext_logbuff_mem(void)
+{
+ phys_addr_t top = lmb_end_of_DRAM();
+ phys_addr_t size = LOGBUFF_RESERVE;
+ phys_addr_t base = top - size;
+
+ if (top base) {
+ ext_logbuff = base;
+ DBG(reserving: %x - %x\n, base, size);
+ lmb_reserve(base, size);
+ }
+}
+#endif /* CONFIG_ALT_LB_LOCATION */
+#endif /* CONFIG_LOGBUFFER */
+
static void __init early_reserve_mem(void)
{
u64 base, size;
@@
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
Nitpick, really.. shouldn't the logbuffer location(s) be some device tree
property(ies), perhaps something in the
/chosen node that U-Boot etc. can then fill out?
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
On Tue, Nov 25, 2008 at 12:34 PM, Grant Erickson
[EMAIL PROTECTED]wrote:
This merges support for the previously DENX-only kernel feature of
specifying an alternative, external buffer for kernel printk
messages and their associated metadata. In addition, this ports
architecture support for this feature from arch/ppc to arch/powerpc.
Signed-off-by: Grant Erickson [EMAIL PROTECTED]
---
When this option is enabled, an architecture- or machine-specific log
buffer is used for all printk messages. This allows entities such as
boot loaders (e.g. U-Boot) to place printk-compatible messages into
this buffer and for the kernel to coalesce them with its normal
messages.
The code has historically been used and proven to work on the LWMON5
platform under arch/ppc and is now used (by me) successfully on the
AMCC Haleakala and Kilauea platforms.
As implemented for arch/powerpc, two suboptions for the alternative
log buffer are supported. The buffer may be contiguous with the
metadata and message data colocated or the metadata and message
storage may be in discontiguous regions of memory (e.g. a set of
scratch registers and an SRAM buffer). On Kilauea and Haleakala, I
have used the former; whereas LWMON5 has traditionally used the latter.
The code here is, more or less, as-is from the DENX GIT tree. Comments
welcome.
arch/powerpc/kernel/prom.c | 93 +++
include/linux/logbuff.h| 56
init/Kconfig | 25 +++
init/main.c|4 +
kernel/printk.c| 149
+++-
5 files changed, 324 insertions(+), 3 deletions(-)
create mode 100644 include/linux/logbuff.h
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 3a2dc7e..60282f1 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -32,6 +32,7 @@
#include linux/debugfs.h
#include linux/irq.h
#include linux/lmb.h
+#include linux/logbuff.h
#include asm/prom.h
#include asm/rtas.h
@@ -61,6 +62,15 @@
#define DBG(fmt...)
#endif
+#ifdef CONFIG_LOGBUFFER
+#ifdef CONFIG_ALT_LB_LOCATION
+# if !defined(BOARD_ALT_LH_ADDR) || !defined(BOARD_ALT_LB_ADDR)
+# error Please specify BOARD_ALT_LH_ADDR BOARD_ALT_LB_ADDR.
+# endif
+#else /* !CONFIG_ALT_LB_LOCATION */
+static phys_addr_t ext_logbuff;
+#endif /* CONFIG_ALT_LB_LOCATION */
+#endif /* CONFIG_LOGBUFFER */
static int __initdata dt_root_addr_cells;
static int __initdata dt_root_size_cells;
@@ -1018,6 +1028,85 @@ static int __init early_init_dt_scan_memory(unsigned
long node,
return 0;
}
+#ifdef CONFIG_LOGBUFFER
+#ifdef CONFIG_ALT_LB_LOCATION
+/* Alternative external log buffer mapping: log metadata header the
+ * character buffer are separated and allocated not in RAM but in some
+ * other memory-mapped I/O region (e.g. log head in unused registers,
+ * and log buffer in OCM memory)
+ */
+int __init setup_ext_logbuff_mem(volatile logbuff_t **lhead, char **lbuf)
+{
+ void *h, *b;
+
+ if (unlikely(!lhead) || unlikely(!lbuf))
+ return -EINVAL;
+
+ /* map log head */
+ h = ioremap(BOARD_ALT_LH_ADDR, sizeof(logbuff_t));
+ if (unlikely(!h))
+ return -EFAULT;
+
+ /* map log buffer */
+ b = ioremap(BOARD_ALT_LB_ADDR, LOGBUFF_LEN);
+ if (unlikely(!b)) {
+ iounmap(h);
+ return -EFAULT;
+ }
+
+ *lhead = h;
+ *lbuf = b;
+
+ return 0;
+}
+#else /* !CONFIG_ALT_LB_LOCATION */
+/* Usual external log-buffer mapping: log metadata header the character
+ * buffer are both contiguous in system RAM.
+ */
+int __init setup_ext_logbuff_mem(logbuff_t **lhead, char **lbuf)
+{
+ void *p;
+
+ if (unlikely(!lhead) || unlikely(!lbuf))
+ return -EINVAL;
+
+ if (unlikely(!ext_logbuff) || !lmb_is_reserved(ext_logbuff))
+ return -EFAULT;
+
+ p = ioremap(ext_logbuff, LOGBUFF_RESERVE);
+
+ if (unlikely(!p))
+ return -EFAULT;
+
+ *lhead = (logbuff_t *)(p + LOGBUFF_OVERHEAD -
+ sizeof(logbuff_t) +
+ sizeof(((logbuff_t *)0)-buf));
+ *lbuf = (*lhead)-buf;
+
+ return 0;
+}
+
+/* When the external log buffer configuration is used with the
+ * non-alternate location, the log head metadata and character buffer
+ * lie in the LOGBUFF_RESERVE bytes at the end of system RAM. Add this
+ * block of memory to the reserved memory pool so that it is not
+ * allocated for other purposes.
+ */
+static void __init reserve_ext_logbuff_mem(void)
+{
+ phys_addr_t
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On Tue, 25 Nov 2008 12:53:12 -0600 Matt Sealey [EMAIL PROTECTED] wrote: Nitpick, really.. shouldn't the logbuffer location(s) be some device tree property(ies), perhaps something in the /chosen node that U-Boot etc. can then fill out? I don't think that's a nitpick. It's a fundamental change in how this would all work. However, I do think you're generally right. Perhaps not /chosen, but maybe something like /rtas or /firmware, etc. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On Tue, Nov 25, 2008 at 12:55 PM, Josh Boyer [EMAIL PROTECTED]wrote: On Tue, 25 Nov 2008 12:53:12 -0600 Matt Sealey [EMAIL PROTECTED] wrote: Nitpick, really.. shouldn't the logbuffer location(s) be some device tree property(ies), perhaps something in the /chosen node that U-Boot etc. can then fill out? I don't think that's a nitpick. It's a fundamental change in how this would all work. However, I do think you're generally right. Perhaps not /chosen, but maybe something like /rtas or /firmware, etc. josh I think the best place is chosen, with things like stdin, stdout etc. - this is where you generally go and dump weird little variables which need to be passed in for early boot. You could consider the log buffer a kind of stdin/out variation. I don't think it needs a whole new device tree node just for two memory locations.. is the support really worth a compatible property, etc. to differentiate between different operating modes? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On 11/25/08 10:55 AM, Josh Boyer wrote: On Tue, 25 Nov 2008 12:53:12 -0600 Matt Sealey [EMAIL PROTECTED] wrote: Nitpick, really.. shouldn't the logbuffer location(s) be some device tree property(ies), perhaps something in the /chosen node that U-Boot etc. can then fill out? I don't think that's a nitpick. It's a fundamental change in how this would all work. However, I do think you're generally right. Perhaps not /chosen, but maybe something like /rtas or /firmware, etc. I'm inclined to agree with you both; however, the submitted implementation was a choice of expediency given the existing DENX implementation and a customer that needed the feature yesterday. ARM, MIPS, et al have not yet adopted device trees, correct? If so, is there value in providing the submitted implementation and adding support for getting said information from the device tree as another option if such information exists? Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch 0/3] OProfile SPU event profiling support for IBM Cell processor
On Tue, 2008-11-25 at 17:00 +0100, Arnd Bergmann wrote: On Tuesday 25 November 2008, Carl Love wrote: This patch set consists of two kernel patches and one user level patch to add SPU event based profiling support to OProfile for the IBM Cell processor. The first patch in the series is the user level patch that adds the needed events and event checking to the user tool. The second patch is the first of two kernel patches. It makes some structural changes to the kernel code to make it easier to add the specific functions for doing SPU event profiling. The first kernel patch does not make any functional changes. The third patch in the series is the second kernel patch where the actual SPU event profiling code support is added to the kernel. Thanks for your submission! I can't comment on the oprofile user code, but I have some comments on the implementation in the third patch. Are the patches interdependent, or will old versions of the oprofile tool work with new kernels and vice versa? Arnd There are two cases:1) new kernel code and old user tool. This works fine, user is not able to do SPU events as the user code doesn't support them. Case 2) old kernel code and new user tool. I realized that I hadn't tested this case. So, I just did. What happens is the event counters get setup for the SPU event but the kernel code treats it as if it is a PPU event. OProfile runs, you get a report for the PPU processors listing the SPU event as the PPU event used. Unfortunately, the report is all garbage and not obvious to the naive user that it is garbage. Looks like we will need to put a check into the user code to make sure it does not try to do SPU event profiling if the kernel doesn't support it. Argh! Carl Love ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
Actually there is an ARM board out there with an Open Firmware (Toshiba TOPAS910 - http://www.toshiba-components.com/microcontroller/BMSKTOPAS910.html) so, yes, device trees do appear on those platforms. QEMU is looking to go that way too, seems for every architecture it would be a pretty awesome idea (especially on ARM). In any case, for platforms that don't, you can then make sure the depends on line in Kconfig is for boards with no device trees - right now that particular thing escapes me but I bet !PPC_OF or similar couldn't be too far from the truth - so the ability to set the values is taken away if you have device tree support built-in. On MIPS or ARM with no DT support, if they don't have device tree support compiled in, the options magically appear. You get the best of both worlds. There is also no reason you can't hard-code the locations into the device tree, to support older U-Boots that don't know about /chosen/linux,log-metadata and /chosen/linux,log-buffer*. I can think of a bunch of reasons why it's a good idea.. what if your board supports a DIMM and you want to keep the buffer up near the top of memory, or the MBAR/CCSRBAR/IMMRBAR or whatever can move location so your SRAM moves around depending on your firmware version or feature support, or, similarly, if your L2 and SRAM are the same thing and can be configured to use different sizes on each boot - pick a different size for the L2/SRAM and the location may have to be moved, which means compiling a new firmware AND a new kernel and matching up the values.. in the end it makes everyone's life easier. * naive implementation - if you only specify log-buffer then that means metadata and buffer are colocated as your docs said, that'd be the least complicated way to implement it without involving a hell of a lot of new stuff, plus it means you can check the existance/value of two properties in a node you can guarantee exists. Also since the log buffer format is Linux-specific and Linux-compatible, and entirely a Linux feature, just like the linux,initrd-start and -end, making a whole new node seems wasteful. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations On Tue, Nov 25, 2008 at 1:04 PM, Grant Erickson [EMAIL PROTECTED]wrote: On 11/25/08 10:55 AM, Josh Boyer wrote: On Tue, 25 Nov 2008 12:53:12 -0600 Matt Sealey [EMAIL PROTECTED] wrote: Nitpick, really.. shouldn't the logbuffer location(s) be some device tree property(ies), perhaps something in the /chosen node that U-Boot etc. can then fill out? I don't think that's a nitpick. It's a fundamental change in how this would all work. However, I do think you're generally right. Perhaps not /chosen, but maybe something like /rtas or /firmware, etc. I'm inclined to agree with you both; however, the submitted implementation was a choice of expediency given the existing DENX implementation and a customer that needed the feature yesterday. ARM, MIPS, et al have not yet adopted device trees, correct? If so, is there value in providing the submitted implementation and adding support for getting said information from the device tree as another option if such information exists? Regards, Grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On Tue, Nov 25, 2008 at 1:51 PM, Bill Gatliff [EMAIL PROTECTED] wrote: Matt Sealey wrote: I can think of a bunch of reasons why it's a good idea.. Can you point to a GPL/LGPL/BSD/etc. source code for an OpenFirmware implementation? Yes, there's FirmWorks, CodeGen SmartFirmware, IBM SLOF and OpenBIOS.. they're all linked from the OpenBIOS website (along with a bunch of the documentation from http://www.openfirmware.org in more-readable formats like PDF) http://www.openbios.org/ But here's the real question; why do you need an opensource implementation? Curiosity? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
Matt Sealey wrote: I can think of a bunch of reasons why it's a good idea.. Can you point to a GPL/LGPL/BSD/etc. source code for an OpenFirmware implementation? b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
. F On Tue, Nov 25, 2008 at 12:51 PM, Bill Gatliff [EMAIL PROTECTED] wrote: Matt Sealey wrote: I can think of a bunch of reasons why it's a good idea.. Can you point to a GPL/LGPL/BSD/etc. source code for an OpenFirmware implementation? In powerpc land using the Open Firmware device tree does not depend on also using Open Firmware. From that perspective the availability of an open sourced Open Firmware is irrelevant. But, both OpenFirmware and SmartFirmware have been open sourced: http://www.openfirmware.info/Open_Firmware http://www.openfirmware.info/SmartFirmware Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On Tue, Nov 25, 2008 at 1:07 PM, Matt Sealey [EMAIL PROTECTED] wrote: On Tue, Nov 25, 2008 at 1:51 PM, Bill Gatliff [EMAIL PROTECTED] wrote: Matt Sealey wrote: I can think of a bunch of reasons why it's a good idea.. Can you point to a GPL/LGPL/BSD/etc. source code for an OpenFirmware implementation? Yes, there's FirmWorks, CodeGen SmartFirmware, IBM SLOF and OpenBIOS.. they're all linked from the OpenBIOS website (along with a bunch of the documentation from http://www.openfirmware.org in more-readable formats like PDF) http://www.openbios.org/ But here's the real question; why do you need an opensource implementation? Curiosity? Umm, so that it can be ported to new boards perhaps? So that developers can work with it? g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On Tue, Nov 25, 2008 at 2:17 PM, Grant Likely [EMAIL PROTECTED]wrote: On Tue, Nov 25, 2008 at 1:07 PM, Matt Sealey [EMAIL PROTECTED] wrote: But here's the real question; why do you need an opensource implementation? Curiosity? Umm, so that it can be ported to new boards perhaps? So that developers can work with it? You can port closed-source firmwares to new boards just as easily as with open source ones. For companies who have larger production requirements than Bill Gatliff, porting an open source firmware may not be a task they want to get into. Linux support is a big enough moving target without adding firmware development to it and tying up programmers implementing the same drivers twice (even if it is practically copypaste in U-Boot). In this case they may just buy one in. If everything had to be open source and freely downloadable there would be no industry at all. And if paying for someone else to write code for you is the issue, then we wouldn't have asked you for a quote last week, and you certainly wouldn't have given us a price :D Bill, as for ARM etc. support, you can imagine that most of the guts of the firmware are fairly well abstracted. Vast portions of the same code work on most platforms with the same peripherals - USB, Ethernet controllers PHYs, PCI, SDIO, etc. The device tree is how hardware designers (note; not OS designers) are meant to abstract the differences in hardware and programming model so that an OS can load the right drivers and Do The Right Thing. It doesn't matter if the device tree was generated as a flattened representation, or by an open-source firmware or closed-source firmware. However the IEEE 1275 standard is not as big a moving target as U-Boot. It has an ABI and a client interface which hasn't been moved around or modified since 1994. And when your board doesn't provide a device tree entry for something, well, you just write some Forth and can edit entries in the device tree in-place (no recompiles required). If you're so inclined you can even write things like scsi host controller drivers in Forth and present them such that they are then working - no reboots or recompiles required, just load the script - and ready to use to boot the system. You can poke around in the FirmWorks code for how powerful this can be, or poke around http://www.powerdeveloper.org/platforms/efika/devicetree for how mundane and simple it can be just fixing up some entries and making sure the chip is configured right.. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
Dear Matt, In message [EMAIL PROTECTED] you wrote: There is also no reason you can't hard-code the locations into the device tree, to support older U-Boots that don't know about /chosen/linux,log-metadata and /chosen/linux,log-buffer*. Actually there is such reason - U-Boot traditionally allocates the log buffer close to the upper end of system memory, so the start address depends on the memory size on the board, which may vary. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] The human mind ordinarily operates at only ten percent of its capacity. The rest is overhead for the operating system. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
No comment from me on $SUBJECT beyond it seems plausible, but ... On Tuesday 25 November 2008, David VomLehn wrote: The important point, though, is that device tree is the only thing approaching a standard on any non-x86-based platform for passing structured information from the bootloader to the kernel. The command line is just not sufficient for this. Me, I'll be happier if I don't have to try using that device tree. Having board-specific code in the kernel is a more complete solution, and makes it a lot easier to cope with all the hardware goofage. Recall that the *original* notion behind OpenBoot (now OpenFirmware) was to have tables for the stuff that was table-friendly, and call out to FORTH code (possibly not just at boot time) for the rest. (Given the choice of FORTH vs ACPI bytecodes, I'd go for FORTH; but the better option is neither.) Right now I see an awful lot of work going into trying to force lots of stuff into table format. Even when it's the sort of one-off or board-specific quirkery that was an original motivation for having FORTH escapes (tasks that were not table-friendly). - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [v3] powerpc/4xx: work around CHIP11 errata in a more PAGE_SIZE-friendly way
On Tue, 2008-11-25 at 11:10 +1100, Michael Ellerman wrote:
Still, I think it would be better to only set memory_limit when the mem
size is not a multiple of the PAGE_SIZE - so that memory_limit retains
it's function as both the value of the limit and a boolean.
OK, how's this?
ppc: force memory size to be a multiple of PAGE_SIZE
Ensure that total memory size is page-aligned, because otherwise
mark_bootmem() gets upset.
This error case was triggered by using 64 KiB pages in the kernel while
arch/powerpc/boot/4xx.c arbitrarily reduced the amount of memory by 4096 (to
work around a chip bug that affects the last 256 bytes of physical memory).
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -1160,6 +1160,8 @@ static inline void __init phyp_dump_rese
void __init early_init_devtree(void *params)
{
+ unsigned long limit;
+
DBG( - early_init_devtree(%p)\n, params);
/* Setup flat device-tree pointer */
@@ -1200,7 +1202,15 @@ void __init early_init_devtree(void *par
early_reserve_mem();
phyp_dump_reserve_mem();
- lmb_enforce_memory_limit(memory_limit);
+ limit = memory_limit;
+ if (! limit) {
+ /* Ensure that total memory size is page-aligned, because
+* otherwise mark_bootmem() gets upset. */
+ lmb_analyze();
+ limit = lmb_phys_mem_size() PAGE_MASK;
+ }
+ lmb_enforce_memory_limit(limit);
+
lmb_analyze();
DBG(Phys. mem: %lx\n, lmb_phys_mem_size());
--
Hollis Blanchard
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Patch 3/3] OProfile SPU event profiling support for IBM Cell processor
On Tue, 2008-11-25 at 16:58 +0100, Arnd Bergmann wrote:
snip
struct pmc_cntrl_data {
unsigned long vcntr;
@@ -111,6 +126,8 @@ struct pm_cntrl {
u16 trace_mode;
u16 freeze;
u16 count_mode;
+ u16 spu_addr_trace;
+ u8 trace_buf_ovflw;
};
static struct {
@@ -128,7 +145,7 @@ static struct {
#define GET_INPUT_CONTROL(x) ((x 0x0004) 2)
static DEFINE_PER_CPU(unsigned long[NR_PHYS_CTRS], pmc_values);
-
+static unsigned long spu_pm_cnt[MAX_NUMNODES * NUM_SPUS_PER_NODE];
static struct pmc_cntrl_data pmc_cntrl[NUM_THREADS][NR_PHYS_CTRS];
Can't you add this data to an existing data structure, e.g. struct spu,
rather than adding a new global?
The data structure above holds flags for how the performance counters
are to be setup on each node. This is not per SPU data. It is per
system data. The flags are setup once and then used when configuring
the various performance counter control registers on each node via one
of the PPU threads on each node.
snip
+
+void stop_spu_profiling_events(void)
+{
+ spu_prof_running = 0;
}
Is this atomic? What if two CPUs access the spu_prof_running variable at
the same time?
Arnd
When the user issues the command opcontrol --start then a series of
functions gets called by one CPU in the system that eventually gets down
to making the assignment spu_prof_running = 1. Similarly, the variable
is set to 0 when the user executes the command opcontrol --stop. In
each case, only one CPU in the system is executing the code to change
the value of the flag. Once OProfile is started, you can't change the
event being profiled until after oprofile is stopped. Hence, you can't
get the situation where spu_prof_running is set by the start and not
reset by the next stop command. Now, as for multiple users issuing
opcontrol --start and/or opcontrol --stop at the same time, there is no
protection at the user level to prevent this. If this occurs, then what
happens will depend on the order the OProfile file system serializes the
writes file for start/stop. It is up to the users to not step on each
other. If they do, the chances are they both will get bad data.
The other things you noted for this patch were easily fixed up.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [v3] powerpc/4xx: work around CHIP11 errata in a more PAGE_SIZE-friendly way
On Tue, 2008-11-25 at 15:53 -0600, Hollis Blanchard wrote:
On Tue, 2008-11-25 at 11:10 +1100, Michael Ellerman wrote:
Still, I think it would be better to only set memory_limit when the mem
size is not a multiple of the PAGE_SIZE - so that memory_limit retains
it's function as both the value of the limit and a boolean.
OK, how's this?
ppc: force memory size to be a multiple of PAGE_SIZE
Ensure that total memory size is page-aligned, because otherwise
mark_bootmem() gets upset.
This error case was triggered by using 64 KiB pages in the kernel while
arch/powerpc/boot/4xx.c arbitrarily reduced the amount of memory by 4096 (to
work around a chip bug that affects the last 256 bytes of physical memory).
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -1160,6 +1160,8 @@ static inline void __init phyp_dump_rese
void __init early_init_devtree(void *params)
{
+ unsigned long limit, memsize;
+
DBG( - early_init_devtree(%p)\n, params);
/* Setup flat device-tree pointer */
@@ -1200,7 +1202,15 @@ void __init early_init_devtree(void *par
early_reserve_mem();
phyp_dump_reserve_mem();
I was thinking more like the following:
- lmb_enforce_memory_limit(memory_limit);
+ limit = memory_limit;
+ if (! limit) {
+ /* Ensure that total memory size is page-aligned, because
+ * otherwise mark_bootmem() gets upset. */
+ lmb_analyze();
memsize = lmb_phys_mem_size();
if(memsize PAGE_MASK != memsize)
limit = memsize PAGE_MASK;
+ }
+ lmb_enforce_memory_limit(limit);
+
So that we never needlessly run through the enforce code with limit =
memsize. But maybe it's a bit pedantic.
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
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix system calls on Cell entered with XER.SO=1
It turns out that on Cell, on a kernel with CONFIG_VIRT_CPU_ACCOUNTING = y, if a program sets the SO (summary overflow) bit in the XER and then does a system call, the SO bit in CR0 will be set on return regardless of whether the system call detected an error. Since CR0.SO is used as the error indication from the system call, this means that all system calls appear to fail. The reason is that the workaround for the timebase bug on Cell uses a compare instruction. With CONFIG_VIRT_CPU_ACCOUNTING = y, the ACCOUNT_CPU_USER_ENTRY macro reads the timebase, so we end up doing a compare instruction, which copies XER.SO to CR0.SO. Since we were doing this in the system call entry patch after clearing CR0.SO but before saving the CR, this meant that the saved CR image had CR0.SO set if XER.SO was set on entry. This fixes it by moving the clearing of CR0.SO to after the ACCOUNT_CPU_USER_ENTRY call in the system call entry path. Signed-off-by: Paul Mackerras [EMAIL PROTECTED] --- diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S index e6d5284..9d80f55 100644 --- a/arch/powerpc/kernel/entry_64.S +++ b/arch/powerpc/kernel/entry_64.S @@ -57,12 +57,12 @@ system_call_common: beq-1f ld r1,PACAKSAVE(r13) 1: std r10,0(r1) - crclr so std r11,_NIP(r1) std r12,_MSR(r1) std r0,GPR0(r1) std r10,GPR1(r1) ACCOUNT_CPU_USER_ENTRY(r10, r11) + crclr so std r2,GPR2(r1) std r3,GPR3(r1) std r4,GPR4(r1) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] Add Alternative Log Buffer Support for printk Messages
On Tue, Nov 25, 2008 at 13:34, Grant Erickson wrote: This merges support for the previously DENX-only kernel feature of specifying an alternative, external buffer for kernel printk messages and their associated metadata. In addition, this ports architecture support for this feature from arch/ppc to arch/powerpc. Signed-off-by: Grant Erickson [EMAIL PROTECTED] --- When this option is enabled, an architecture- or machine-specific log buffer is used for all printk messages. This allows entities such as boot loaders (e.g. U-Boot) to place printk-compatible messages into this buffer and for the kernel to coalesce them with its normal messages. snip this extended info should be part of the changelog and thus above the --- marker ... -mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Re :Re: [Ltib] ltib error -linux2.6.20.6 with MPC8360E MDS
Jon Loeliger wrote: nanda wrote: Hi Stuart, Thanks for the information. gpp access was resolved. I was successful in building the linux 2.6.11 using the ltib and able to bring up the MPC8360 EMDS. But, I still face the problem for linux kernel 2.6.19 and 2.6.20. When I tried using ltib in the bringing up the board. The MPC 8360 board keeps rebooting after downloading the image Power PC Kernel Image(uImage) and Power PC RAMDisk Image(rootfs.ext2.gz.uboot) build by the ltib Please clarrify on the same. I'm not a kernel expert and don't know what failure you are seeing here, but I might observe that 2.6.19 and .20 are two years old, and 2.6.11 is more than 3 years old. If you think we, collectively, haven't improved things in that time period, please, complain about 2.6.11, .19, and .20. If on the off chance you think things *might* have gotten better due to a *bit* of development effort over the past three years, you might try installing a modern U-Boot and a modern Kernel. Thanks, jdl I would strongly recommend switching to ELDK from denx.de and the latest released (or tip-o-the-tree) u-boot. This will allow you to build and boot the latest kernel with a flattened device tree (FDT). ELDK: http://www.denx.de/wiki/DULG/ELDK http://ftp.denx.de/pub/eldk/ Specifically: http://ftp.denx.de/pub/eldk/4.2/ppc-linux-x86/iso/ u-boot: make MPC8360EMDS_HOST_66_config make linux: Start with: arch/powerpc/configs/83xx/mpc836x_mds_defconfig Trying to use an old u-boot and old toolset with a recent kernel isn't worth the headaches. The ToT supports the MPC8360EMDS directly. Best regards, gvb ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
