* 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: 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
* [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
* [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
* 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
* 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: [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
* 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: 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
* 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: [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: 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: 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: [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: [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: 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: 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: [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
* [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: 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
* Re: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
From: Joakim Tjernlund @ 2008-03-25 9:17 UTC (permalink / raw)
To: Li Yang; +Cc: Netdev, Linuxppc-Embedded@Ozlabs.Org
In-Reply-To: <46CAC1281D7CB94A9AEFFB131F9569CA227627@tmnt04.transmode.se>
On Sat, 2008-03-22 at 12:51 +0100, Joakim Tjernlund wrote:
> >> -----Original Message-----
> >> From: netdev-owner@vger.kernel.org
> >> [mailto:netdev-owner@vger.kernel.org] On Behalf Of Joakim Tjernlund
> > Sent: Tuesday, March 18, 2008 11:11 PM
> >> To: Netdev; Li Yang
> >> Cc: Joakim Tjernlund
> >>Subject: [PATCH] ucc_geth: Add 8 bytes to max TX frame for VLANs
> >>
> >> Creating a VLAN interface on top of ucc_geth adds 4 bytes to
> >> the frame and the HW controller is not prepared to TX a frame
> >> bigger than 1518 bytes which is 4 bytes too small for a full
> >> VLAN frame. Also add 4 extra bytes for future expansion.
> >
> > IMO, VLAN and Jumbo packet support is not general case of Ethernet.
> > Could you make this change optional? Thanks.
> >
> > - Leo
>
> hmm, I do not agree. VLAN is common today.
>
> If you were to enable HW support for VLAN then the ethernet controller
> would inject an extra 4 bytes into the frame.
> This change does not change the visible MTU for the user. As is now,
> soft VLAN is silently broken. Do you
> really want the user to find and turn on a controller specific feature
> to use VLAN?
>
> What does netdev people think?
>
> Jocke
hmm, I misread the HW specs. The change has nothing to do with TX, it is
the MAX RX frame size that was too small for VLAN and that is what the
patch addresses. I see that tg3.c adds 4 bytes to MAX RX pkgs:
/* MTU + ethernet header + FCS + optional VLAN tag */
tw32(MAC_RX_MTU_SIZE, tp->dev->mtu + ETH_HLEN + 8);
So I don't think this change should be hidden behind a new CONFIG
option. Updated patch below with changed description.
Jocke
>From ec8ca3c9666bdc72652e403ea5f252b38e5a076b Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Date: Tue, 18 Mar 2008 15:40:59 +0100
Subject: [PATCH] ucc_geth: Add 8 bytes to max RX frame for VLANs
Creating a VLAN interface on top of ucc_geth adds 4 bytes
to the frame and the HW controller is not prepared to
receive a frame bigger than 1518 bytes which is 4 bytes too
small for a full VLAN frame. Also add 4 extra bytes for future
expansion.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
drivers/net/ucc_geth.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 348892b..038ec75 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -114,10 +114,10 @@ static struct ucc_geth_info ugeth_primary_info = {
.maxGroupAddrInHash = 4,
.maxIndAddrInHash = 4,
.prel = 7,
- .maxFrameLength = 1518,
+ .maxFrameLength = 1518+8, /* Add 4 bytes for VLAN tags and 4 extra bytes */
.minFrameLength = 64,
- .maxD1Length = 1520,
- .maxD2Length = 1520,
+ .maxD1Length = 1520+8,
+ .maxD2Length = 1520+8,
.vlantype = 0x8100,
.ecamptr = ((uint32_t) NULL),
.eventRegMask = UCCE_OTHER,
--
1.5.4.3
^ permalink raw reply related
* MPC8641D PCI-Express problem
From: Marco Stornelli @ 2008-03-25 8:02 UTC (permalink / raw)
To: LinuxPPC-Embedded
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.
Marco
^ permalink raw reply
* Re: linux-next: Tree for March 20
From: Greg KH @ 2008-03-25 7:31 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Theodore Tso, LKML, linuxppc-dev, linux-next, Paul Mackerras,
Dan Williams
In-Reply-To: <20080325174817.6018edd8.sfr@canb.auug.org.au>
On Tue, Mar 25, 2008 at 05:48:17PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Wed, 19 Mar 2008 21:57:19 -0700 Greg KH <greg@kroah.com> wrote:
> >
> > On Thu, Mar 20, 2008 at 02:39:53PM +1100, Stephen Rothwell wrote:
> > >
> > > driver-core/driver-core-remove-no-longer-used-struct-class_device.patch
> > > should be merged late
>
> I still need to revert this so that the scsi tree can build (st.c).
I'll be sending this to Linus after -rc1 comes out, so it's fine that it
needs to be reverted for now.
> > > driver-core/ib-convert-struct-class_device-to-struct-device.patch
> > > conflicts with the infiniband tree
>
> This still has the same conflicts, but they are papered over by my use of
> git-rerere (which remembers my previous merge fixup and applies it for
> me).
Yeah, __FUNCTION__ fun :(
> > > driver-core/pm-make-wakeup-flags-available-whenever-config_pm-is-set.patch
> > > breaks non CONFIG_PM builds of drivers/serial/serial_core.c
>
> This one seems to be fixed.
Glad to hear it.
greg k-h
^ permalink raw reply
* Re: linux-next: Tree for March 20
From: Stephen Rothwell @ 2008-03-25 6:48 UTC (permalink / raw)
To: Greg KH
Cc: Theodore Tso, Dan, LKML, linuxppc-dev, linux-next, Paul Mackerras,
Williams
In-Reply-To: <20080320045719.GA26938@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 891 bytes --]
Hi Greg,
On Wed, 19 Mar 2008 21:57:19 -0700 Greg KH <greg@kroah.com> wrote:
>
> On Thu, Mar 20, 2008 at 02:39:53PM +1100, Stephen Rothwell wrote:
> >
> > driver-core/driver-core-remove-no-longer-used-struct-class_device.patch
> > should be merged late
I still need to revert this so that the scsi tree can build (st.c).
> > driver-core/ib-convert-struct-class_device-to-struct-device.patch
> > conflicts with the infiniband tree
This still has the same conflicts, but they are papered over by my use of
git-rerere (which remembers my previous merge fixup and applies it for
me).
> > driver-core/pm-make-wakeup-flags-available-whenever-config_pm-is-set.patch
> > breaks non CONFIG_PM builds of drivers/serial/serial_core.c
This one seems to be fixed.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2 v2] [POWERPC] Add PPC4xx L2-cache support (440GX)
From: Stefan Roese @ 2008-03-25 6:21 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080324083957.2945077c@zod.rchland.ibm.com>
On Monday 24 March 2008, Josh Boyer wrote:
> > diff --git a/arch/powerpc/sysdev/ppc4xx_soc.c
> > b/arch/powerpc/sysdev/ppc4xx_soc.c new file mode 100644
> > index 0000000..4847555
> > --- /dev/null
> > +++ b/arch/powerpc/sysdev/ppc4xx_soc.c
> > @@ -0,0 +1,178 @@
> > +/*
> > + * IBM/AMCC PPC4xx SoC setup code
> > + *
> > + * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
> > + *
> > + * L2 cache routines cloned from arch/ppc/syslib/ibm440gx_common.c whi=
ch
> > is: + * Eugene Surovegin <eugene.surovegin@zultys.com> or
> > <ebs@ebshome.net> + * Copyright (c) 2003 - 2006 Zultys Technologies
> > + *
> > + * This program is free software; you can redistribute it and/or modi=
fy
> > it + * under the terms of the GNU General Public License as published
> > by the + * Free Software Foundation; either version 2 of the License,
> > or (at your + * option) any later version.
> > + */
> > +
> > +#include <linux/stddef.h>
> > +#include <linux/kernel.h>
> > +#include <linux/init.h>
> > +#include <linux/errno.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/irq.h>
> > +#include <linux/of_platform.h>
> > +
> > +#include <asm/dcr.h>
> > +#include <asm/dcr-regs.h>
> > +
> > +static u32 dcrbase;
>
> If this file is really intended to have other miscellaneous stuff added
> to it, perhaps this variable should be renamed l2_dcrbase. I know it's
> minor, so perhaps we can wait until something else gets added.
Right. I'll change this with the next version.
> > +
> > +/*
> > + * L2-cache
> > + */
> > +
> > +/* Issue L2C diagnostic command */
> > +static inline u32 l2c_diag(u32 addr)
> > +{
> > + mtdcr(dcrbase + DCRN_L2C0_ADDR, addr);
> > + mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_DIAG);
> > + while (!(mfdcr(dcrbase + DCRN_L2C0_SR) & L2C_SR_CC))
> > + ;
> > +
> > + return mfdcr(dcrbase + DCRN_L2C0_DATA);
> > +}
> > +
> > +static irqreturn_t l2c_error_handler(int irq, void *dev)
> > +{
> > + u32 sr =3D mfdcr(dcrbase + DCRN_L2C0_SR);
> > +
> > + if (sr & L2C_SR_CPE) {
> > + /* Read cache trapped address */
> > + u32 addr =3D l2c_diag(0x42000000);
>
> What is this magical hex number?
I have to admit that I didn't check. As mentioned in the commit log, most o=
f=20
this L2 cache code is copied directly from arch/ppc done by Eugene Surovegi=
n.=20
=46rom my point of view, the comment right above the line should be enough.=
=20
Especially since this "magical hex number" isn't used anywhere else in the=
=20
code. But I could introduce a define for this. Please give me a short note =
if=20
you think it is necessary.
> > + printk(KERN_EMERG "L2C: Cache Parity Error, addr[16:26] =3D 0x%08x\n=
",
> > + addr);
> > + }
> > + if (sr & L2C_SR_TPE) {
> > + /* Read tag trapped address */
> > + u32 addr =3D l2c_diag(0x82000000) >> 16;
>
> And here?
Same comment as above.
> > + printk(KERN_EMERG "L2C: Tag Parity Error, addr[16:26] =3D 0x%08x\n",
> > + addr);
> > + }
> > +
> > + /* Clear parity errors */
> > + if (sr & (L2C_SR_CPE | L2C_SR_TPE)){
> > + mtdcr(dcrbase + DCRN_L2C0_ADDR, 0);
> > + mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_CCP | L2C_CMD_CTE);
> > + } else {
> > + printk(KERN_EMERG "L2C: LRU error\n");
> > + }
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static int __init ppc4xx_l2c_probe(void)
> > +{
> > + struct device_node *np;
> > + u32 r;
> > + unsigned long flags;
> > + int irq;
> > + const u32 *dcrreg;
> > + u32 dcrbase_isram;
> > + int len;
> > +
> > + np =3D of_find_compatible_node(np, NULL, "ibm,l2-cache");
> > + if (!np)
> > + return 0;
> > +
> > + /* Map DCRs */
> > + dcrreg =3D of_get_property(np, "dcr-reg", &len);
> > + if (!dcrreg || (len !=3D 4 * sizeof(u32))) {
> > + printk(KERN_ERR "%s: Can't get DCR register base !",
> > + np->full_name);
> > + of_node_put(np);
> > + return -ENODEV;
> > + }
> > + dcrbase_isram =3D dcrreg[0];
> > + dcrbase =3D dcrreg[2];
> > +
> > + /* Get and map irq number from device tree */
> > + irq =3D irq_of_parse_and_map(np, 0);
> > + if (irq =3D=3D NO_IRQ) {
> > + printk(KERN_ERR "irq_of_parse_and_map failed\n");
> > + of_node_put(np);
> > + return -ENODEV;
> > + }
> > +
> > + /* Install error handler */
> > + if (request_irq(irq, l2c_error_handler, IRQF_DISABLED, "L2C", 0) < 0)=
{
> > + printk(KERN_ERR "Cannot install L2C error handler"
> > + ", cache is not enabled\n");
> > + of_node_put(np);
> > + return -ENODEV;
> > + }
> > +
> > + local_irq_save(flags);
> > + asm volatile ("sync" ::: "memory");
>
> Perhaps just call iosync() for these instead of the open coded asm
> volatile stuff?
With Ben's comments, I'll leave it unchanged.
> > +
> > + /* Disable SRAM */
> > + mtdcr(dcrbase_isram + DCRN_SRAM0_DPC,
> > + mfdcr(dcrbase_isram + DCRN_SRAM0_DPC) & ~SRAM_DPC_ENABLE);
> > + mtdcr(dcrbase_isram + DCRN_SRAM0_SB0CR,
> > + mfdcr(dcrbase_isram + DCRN_SRAM0_SB0CR) & ~SRAM_SBCR_BU_MASK);
> > + mtdcr(dcrbase_isram + DCRN_SRAM0_SB1CR,
> > + mfdcr(dcrbase_isram + DCRN_SRAM0_SB1CR) & ~SRAM_SBCR_BU_MASK);
> > + mtdcr(dcrbase_isram + DCRN_SRAM0_SB2CR,
> > + mfdcr(dcrbase_isram + DCRN_SRAM0_SB2CR) & ~SRAM_SBCR_BU_MASK);
> > + mtdcr(dcrbase_isram + DCRN_SRAM0_SB3CR,
> > + mfdcr(dcrbase_isram + DCRN_SRAM0_SB3CR) & ~SRAM_SBCR_BU_MASK);
> > +
> > + /* Enable L2_MODE without ICU/DCU */
> > + r =3D mfdcr(dcrbase + DCRN_L2C0_CFG) &
> > + ~(L2C_CFG_ICU | L2C_CFG_DCU | L2C_CFG_SS_MASK);
> > + r |=3D L2C_CFG_L2M | L2C_CFG_SS_256;
> > + mtdcr(dcrbase + DCRN_L2C0_CFG, r);
> > +
> > + mtdcr(dcrbase + DCRN_L2C0_ADDR, 0);
> > +
> > + /* Hardware Clear Command */
> > + mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_HCC);
> > + while (!(mfdcr(dcrbase + DCRN_L2C0_SR) & L2C_SR_CC))
> > + ;
> > +
> > + /* Clear Cache Parity and Tag Errors */
> > + mtdcr(dcrbase + DCRN_L2C0_CMD, L2C_CMD_CCP | L2C_CMD_CTE);
> > +
> > + /* Enable 64G snoop region starting at 0 */
> > + r =3D mfdcr(dcrbase + DCRN_L2C0_SNP0) &
> > + ~(L2C_SNP_BA_MASK | L2C_SNP_SSR_MASK);
> > + r |=3D L2C_SNP_SSR_32G | L2C_SNP_ESR;
> > + mtdcr(dcrbase + DCRN_L2C0_SNP0, r);
> > +
> > + r =3D mfdcr(dcrbase + DCRN_L2C0_SNP1) &
> > + ~(L2C_SNP_BA_MASK | L2C_SNP_SSR_MASK);
> > + r |=3D 0x80000000 | L2C_SNP_SSR_32G | L2C_SNP_ESR;
> > + mtdcr(dcrbase + DCRN_L2C0_SNP1, r);
> > +
> > + asm volatile ("sync" ::: "memory");
> > +
> > + /* Enable ICU/DCU ports */
> > + r =3D mfdcr(dcrbase + DCRN_L2C0_CFG);
> > + r &=3D ~(L2C_CFG_DCW_MASK | L2C_CFG_PMUX_MASK | L2C_CFG_PMIM
> > + | L2C_CFG_TPEI | L2C_CFG_CPEI | L2C_CFG_NAM | L2C_CFG_NBRM);
> > + r |=3D L2C_CFG_ICU | L2C_CFG_DCU | L2C_CFG_TPC | L2C_CFG_CPC |
> > L2C_CFG_FRAN + | L2C_CFG_CPIM | L2C_CFG_TPIM | L2C_CFG_LIM |
> > L2C_CFG_SMCM;
> > +
> > + /* Check for 460EX/GT special handling */
> > + if (of_device_is_compatible(np, "ibm,l2-cache-460ex"))
> > + r |=3D L2C_CFG_RDBW;
> > +
> > + mtdcr(dcrbase + DCRN_L2C0_CFG, r);
> > +
> > + asm volatile ("sync; isync" ::: "memory");
> > + local_irq_restore(flags);
> > +
> > + printk(KERN_INFO "256k L2-cache enabled\n");
>
> Should the cache size be derived from the device tree?
Right, we should probably do this. Even though currently there doesn't seem=
to=20
be a 4xx with a different L2 cache size than 256k.
Best regards,
Stefan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
^ 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