* Re: [PATCH 00/10 v6] Fix 8xx MMU/TLB
From: Joakim Tjernlund @ 2009-11-27 10:57 UTC (permalink / raw)
Cc: Scott Wood, linuxppc-dev@ozlabs.org, Rex Feany
In-Reply-To: <1258712471-3104-1-git-send-email-Joakim.Tjernlund@transmode.se>
Scott and Rex, I think we need you s-o-b to make it into the kernel proper.
Marcelo and Vitaly, I noticed you guys are listed as 8xx maintainers.
Have you seen this? What do you think?
Jocke
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> wrote on 20/11/2009 11:21:01:
>
> Yet again an iteration of the series.
> Rex & Scott, please test and signoff.
> Changes since last version:
> - Fix rlwimi insn(from Scott)
>
> Joakim Tjernlund (10):
> 8xx: invalidate non present TLBs
> 8xx: Update TLB asm so it behaves as linux mm expects.
> 8xx: Tag DAR with 0x00f0 to catch buggy instructions.
> 8xx: Always pin kernel instruction TLB
> 8xx: Fixup DAR from buggy dcbX instructions.
> 8xx: Add missing Guarded setting in DTLB Error.
> 8xx: Restore _PAGE_WRITETHRU
> 8xx: start using dcbX instructions in various copy routines
> 8xx: Remove DIRTY pte handling in DTLB Error.
> 8xx: DTLB Miss cleanup
>
> arch/powerpc/include/asm/pte-8xx.h | 14 +-
> arch/powerpc/kernel/head_8xx.S | 315 ++++++++++++++++++++++--------------
> arch/powerpc/kernel/misc_32.S | 18 --
> arch/powerpc/lib/copy_32.S | 24 ---
> arch/powerpc/mm/fault.c | 8 +-
> 5 files changed, 211 insertions(+), 168 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v2] ppc440spe-adma: adds updated ppc440spe adma driver
From: Anatolij Gustschin @ 2009-11-27 10:26 UTC (permalink / raw)
To: Tirumala Reddy Marri
Cc: wd, dzu, Yuri Tikhonov, linux-raid, linuxppc-dev, dan.j.williams
In-Reply-To: <AC5E1C3367E37D44970B81A6ADD1DA2C08642A43@SDCEXCHANGE01.ad.amcc.com>
"Tirumala Reddy Marri" <tmarri@amcc.com> wrote:
> Why are we having separate directory for 440spe. Can this be generalized
> arch/dma/ppc4xx/ppc4xx_dma.c ?
currently there is only tested support for 440spe. If the driver
will be extended to support other CPUs, then the renaming can be
done while adding support for other CPUs. 'arch/' is not correct,
it should be 'driver/'.
Best regards,
Anatolij
--
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
^ permalink raw reply
* [PATCH] powerpc/ipic: support external edge triggered IRQ0
From: Norbert van Bolhuis @ 2009-11-27 10:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: nvbolhuis
Currently an external edge triggered IRQ0 gives 2 problems.
It gives a sense error ("edge sense not supported on internal interrupts")
and it isn't acked.
This patch takes into account IRQ0 can be internal or external and fixes
both issues.
Signed-off-by: Norbert van Bolhuis <nvbolhuis@aimvalley.nl>
---
arch/powerpc/sysdev/ipic.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index cb7689c..3201db1 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -316,6 +316,7 @@ static struct ipic_info ipic_info[] = {
.prio_mask = 7,
},
[48] = {
+ .ack = IPIC_SEPNR,
.mask = IPIC_SEMSR,
.prio = IPIC_SMPRR_A,
.force = IPIC_SEFCR,
@@ -619,7 +620,9 @@ static int ipic_set_irq_type(unsigned int virq, unsigned int flow_type)
return -EINVAL;
}
/* ipic supports only edge mode on external interrupts */
- if ((flow_type & IRQ_TYPE_EDGE_FALLING) && !ipic_info[src].ack) {
+ if ((flow_type & IRQ_TYPE_EDGE_FALLING) &&
+ ((src != IPIC_IRQ_EXT0 && !ipic_info[src].ack) ||
+ (src == IPIC_IRQ_EXT0 && (ipic_read(ipic->regs, IPIC_SEMSR) & SEMSR_SIRQ0)))) {
printk(KERN_ERR "ipic: edge sense not supported on internal "
"interrupts\n");
return -EINVAL;
--
1.5.2.2
^ permalink raw reply related
* [PATCH] fix PPC floating point debug
From: Stefani Seibold @ 2009-11-27 8:59 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
The PPC architecture is unable to debug applications using hardware
floating point, because it would not save the floating point registers.
After returning from the debugger, the contents of register was
modified. This patch fix this bug.
Signed-off-by: Stefani Seibold <stefani@seibold.net>
---
traps.c | 6 ++++++
1 file changed, 6 insertions(+)
--- linux-2.6.32-rc5/arch/powerpc/kernel/traps.c.orig 2009-11-27 09:47:37.989943124 +0100
+++ linux-2.6.32-rc5/arch/powerpc/kernel/traps.c 2009-11-27 09:47:41.088330825 +0100
@@ -559,6 +559,8 @@ void instruction_breakpoint_exception(st
return;
if (debugger_iabr_match(regs))
return;
+ if (regs->msr & MSR_FP)
+ giveup_fpu(current);
_exception(SIGTRAP, regs, TRAP_BRKPT, regs->nip);
}
@@ -577,6 +579,8 @@ void __kprobes single_step_exception(str
if (debugger_sstep(regs))
return;
+ if (regs->msr & MSR_FP)
+ giveup_fpu(current);
_exception(SIGTRAP, regs, TRAP_TRACE, regs->nip);
}
@@ -834,6 +838,8 @@ void __kprobes program_check_exception(s
regs->nip += 4;
return;
}
+ if (regs->msr & MSR_FP)
+ giveup_fpu(current);
_exception(SIGTRAP, regs, TRAP_BRKPT, regs->nip);
return;
}
^ permalink raw reply
* Re: [PATCH] Reserve memory for kdump kernel within RMO region
From: M. Mohan Kumar @ 2009-11-27 8:35 UTC (permalink / raw)
To: Bernhard Walle; +Cc: kexec, ppcdev
In-Reply-To: <4B0ED674.6050501@bwalle.de>
On 11/27/2009 12:56 AM, Bernhard Walle wrote:
> M. Mohan Kumar schrieb:
>> On 11/26/2009 12:22 AM, Bernhard Walle wrote:
>>> M. Mohan Kumar schrieb:
>>>> Reserve memory for kdump kernel within RMO region
>>>>
>>>> When the kernel size exceeds 32MB(observed with some distros), memory
>>>> for kdump kernel can not be reserved as kdump kernel base is assumed to
>>>> be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled,
>>>> provide the feature to reserve the memory for kdump kernel anywhere in
>>>> the RMO region.
>>
>> Hi Bernhard,
>>
>>> Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that
>>> gets loaded as crashkernel, not for the kernel that loads the
>>> crashkernel. So it would be perfectly fine that a kernel that has not
>>> CONFIG_RELOCATABLE set would load another kernel that has
>>> CONFIG_RELOCATABLE set on an address != 32 M.
>>
>> No, with relocatable option, the same kernel is used as both production
>> and kdump kernel.
>
> Can be, but it's not strictly necessary. It depends what userland does.
> Especially it's possible that a non-relocatable, self-compiled kernel
> loads a relocatable distribution kernel as capture kernel.
>
I don't understand why a non-relocatable kernel will use relocatable
kernel for capturing kdump kernel. The idea for relocatable kernel is to
avoid using two different kernels to capture kernel dump.
> Also, it would make sense to make the behaviour symmetric across
> platforms. Currently we have:
>
> - x86 and ia64: Without offset on command line, use any offset
> With offset on command line, use that offset and fail
> if no memory is available at that offset.
> - ppc64: Always use 32M and ignore the offset.
>
> If your patch gets applied, we have:
>
> - ppc64: With CONFIG_RELOCATABLE, use any offset
> With offset on command
>
> I don't see why the behaviour on ppc64 should be completely different.
>
> Having maintained kdump for SUSE for x86, ia64 and partly ppc64 in the
> past, I always felt that ppc64 is more different from x86 than ia64 is
> from x86. That's one more step into that direction without a technical
> reason.
Also with the crashkernel=auto parameter (patches are not yet merged),
the crashkernel base (offset) by default would be 32MB. In this case if
a kernel passed with crashkernel=auto and if the first kernel size
exceeds 32MB, memory for kdump kernel will always fail.
>
> Having that all said: If your patch gets in mainline kernel, than we
> should change the behaviour also for x86 and ia64.
>
>
>
> Regards,
> Bernhard
^ permalink raw reply
* ucc_geth: Fix the wrong the Rx/Tx FIFO size
From: Dave Liu @ 2009-11-27 8:16 UTC (permalink / raw)
To: davem; +Cc: netdev, @vger.kernel.org, linuxppc-dev
current the Rx/Tx FIFO size settings cause problem
when four UEC ethernets work simultaneously.
eg: GETH1, UEM-J15, GETH2, UEC-J5 on 8569MDS board
$ ifconfig eth0 10.193.20.166
$ ifconfig eth1 10.193.20.167
$ ifconfig eth2 10.193.20.168
then
$ ifconfig eth3 10.193.20.169
The fourth ethernet will cause all of interface broken,
you cann't ping successfully any more.
The patch fix this issue for MPC8569 Rev1.0 and Rev2.0
Signed-off-by: Dave Liu <daveliu@freescale.com>
---
drivers/net/ucc_geth.h | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ucc_geth.h b/drivers/net/ucc_geth.h
index 03a6ca0..26a43ed 100644
--- a/drivers/net/ucc_geth.h
+++ b/drivers/net/ucc_geth.h
@@ -838,13 +838,13 @@ struct ucc_geth_hardware_statistics {
using the maximum is
easier */
#define UCC_GETH_SEND_QUEUE_QUEUE_DESCRIPTOR_ALIGNMENT 32
-#define UCC_GETH_SCHEDULER_ALIGNMENT 4 /* This is a guess */
+#define UCC_GETH_SCHEDULER_ALIGNMENT 8 /* This is a guess */
#define UCC_GETH_TX_STATISTICS_ALIGNMENT 4 /* This is a guess */
#define UCC_GETH_RX_STATISTICS_ALIGNMENT 4 /* This is a guess */
#define UCC_GETH_RX_INTERRUPT_COALESCING_ALIGNMENT 64
#define UCC_GETH_RX_BD_QUEUES_ALIGNMENT 8 /* This is a guess */
#define UCC_GETH_RX_PREFETCHED_BDS_ALIGNMENT 128 /* This is a guess */
-#define UCC_GETH_RX_EXTENDED_FILTERING_GLOBAL_PARAMETERS_ALIGNMENT 4 /* This
+#define UCC_GETH_RX_EXTENDED_FILTERING_GLOBAL_PARAMETERS_ALIGNMENT 8 /* This
is a
guess
*/
@@ -899,16 +899,17 @@ struct ucc_geth_hardware_statistics {
#define UCC_GETH_UTFS_INIT 512 /* Tx virtual FIFO size
*/
#define UCC_GETH_UTFET_INIT 256 /* 1/2 utfs */
-#define UCC_GETH_UTFTT_INIT 128
+#define UCC_GETH_UTFTT_INIT 512
/* Gigabit Ethernet (1000 Mbps) */
#define UCC_GETH_URFS_GIGA_INIT 4096/*2048*/ /* Rx virtual
FIFO size */
#define UCC_GETH_URFET_GIGA_INIT 2048/*1024*/ /* 1/2 urfs */
#define UCC_GETH_URFSET_GIGA_INIT 3072/*1536*/ /* 3/4 urfs */
-#define UCC_GETH_UTFS_GIGA_INIT 8192/*2048*/ /* Tx virtual
+#define UCC_GETH_UTFS_GIGA_INIT 4096/*2048*/ /* Tx virtual
+ FIFO size */
+#define UCC_GETH_UTFET_GIGA_INIT 2048/*1024*/ /* 1/2 utfs */
+#define UCC_GETH_UTFTT_GIGA_INIT 4096/*0x40*/ /* Tx virtual
FIFO size */
-#define UCC_GETH_UTFET_GIGA_INIT 4096/*1024*/ /* 1/2 utfs */
-#define UCC_GETH_UTFTT_GIGA_INIT 0x400/*0x40*/ /* */
#define UCC_GETH_REMODER_INIT 0 /* bits that must be
set */
--
1.6.4
^ permalink raw reply related
* [PATCH] via-pmu: convert to proc_fops/seq_file
From: Alexey Dobriyan @ 2009-11-27 6:53 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, akpm, paulus
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/macintosh/via-pmu.c | 160 +++++++++++++++++++++++++-------------------
1 file changed, 91 insertions(+), 69 deletions(-)
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -36,6 +36,7 @@
#include <linux/spinlock.h>
#include <linux/pm.h>
#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/device.h>
@@ -186,17 +187,11 @@ static int init_pmu(void);
static void pmu_start(void);
static irqreturn_t via_pmu_interrupt(int irq, void *arg);
static irqreturn_t gpio1_interrupt(int irq, void *arg);
-static int proc_get_info(char *page, char **start, off_t off,
- int count, int *eof, void *data);
-static int proc_get_irqstats(char *page, char **start, off_t off,
- int count, int *eof, void *data);
+static const struct file_operations pmu_info_proc_fops;
+static const struct file_operations pmu_irqstats_proc_fops;
static void pmu_pass_intr(unsigned char *data, int len);
-static int proc_get_batt(char *page, char **start, off_t off,
- int count, int *eof, void *data);
-static int proc_read_options(char *page, char **start, off_t off,
- int count, int *eof, void *data);
-static int proc_write_options(struct file *file, const char __user *buffer,
- unsigned long count, void *data);
+static const struct file_operations pmu_battery_proc_fops;
+static const struct file_operations pmu_options_proc_fops;
#ifdef CONFIG_ADB
struct adb_driver via_pmu_driver = {
@@ -507,19 +502,15 @@ static int __init via_pmu_dev_init(void)
for (i=0; i<pmu_battery_count; i++) {
char title[16];
sprintf(title, "battery_%ld", i);
- proc_pmu_batt[i] = create_proc_read_entry(title, 0, proc_pmu_root,
- proc_get_batt, (void *)i);
+ proc_pmu_batt[i] = proc_create_data(title, 0, proc_pmu_root,
+ &pmu_battery_proc_fops, (void *)i);
}
- proc_pmu_info = create_proc_read_entry("info", 0, proc_pmu_root,
- proc_get_info, NULL);
- proc_pmu_irqstats = create_proc_read_entry("interrupts", 0, proc_pmu_root,
- proc_get_irqstats, NULL);
- proc_pmu_options = create_proc_entry("options", 0600, proc_pmu_root);
- if (proc_pmu_options) {
- proc_pmu_options->read_proc = proc_read_options;
- proc_pmu_options->write_proc = proc_write_options;
- }
+ proc_pmu_info = proc_create("info", 0, proc_pmu_root, &pmu_info_proc_fops);
+ proc_pmu_irqstats = proc_create("interrupts", 0, proc_pmu_root,
+ &pmu_irqstats_proc_fops);
+ proc_pmu_options = proc_create("options", 0600, proc_pmu_root,
+ &pmu_options_proc_fops);
}
return 0;
}
@@ -799,27 +790,33 @@ query_battery_state(void)
2, PMU_SMART_BATTERY_STATE, pmu_cur_battery+1);
}
-static int
-proc_get_info(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int pmu_info_proc_show(struct seq_file *m, void *v)
{
- char* p = page;
-
- p += sprintf(p, "PMU driver version : %d\n", PMU_DRIVER_VERSION);
- p += sprintf(p, "PMU firmware version : %02x\n", pmu_version);
- p += sprintf(p, "AC Power : %d\n",
+ seq_printf(m, "PMU driver version : %d\n", PMU_DRIVER_VERSION);
+ seq_printf(m, "PMU firmware version : %02x\n", pmu_version);
+ seq_printf(m, "AC Power : %d\n",
((pmu_power_flags & PMU_PWR_AC_PRESENT) != 0) || pmu_battery_count == 0);
- p += sprintf(p, "Battery count : %d\n", pmu_battery_count);
+ seq_printf(m, "Battery count : %d\n", pmu_battery_count);
+
+ return 0;
+}
- return p - page;
+static int pmu_info_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, pmu_info_proc_show, NULL);
}
-static int
-proc_get_irqstats(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static const struct file_operations pmu_info_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = pmu_info_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static int pmu_irqstats_proc_show(struct seq_file *m, void *v)
{
int i;
- char* p = page;
static const char *irq_names[] = {
"Total CB1 triggered events",
"Total GPIO1 triggered events",
@@ -835,60 +832,76 @@ proc_get_irqstats(char *page, char **start, off_t off,
};
for (i=0; i<11; i++) {
- p += sprintf(p, " %2u: %10u (%s)\n",
+ seq_printf(m, " %2u: %10u (%s)\n",
i, pmu_irq_stats[i], irq_names[i]);
}
- return p - page;
+ return 0;
}
-static int
-proc_get_batt(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int pmu_irqstats_proc_open(struct inode *inode, struct file *file)
{
- long batnum = (long)data;
- char *p = page;
+ return single_open(file, pmu_irqstats_proc_show, NULL);
+}
+
+static const struct file_operations pmu_irqstats_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = pmu_irqstats_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static int pmu_battery_proc_show(struct seq_file *m, void *v)
+{
+ long batnum = (long)m->private;
- p += sprintf(p, "\n");
- p += sprintf(p, "flags : %08x\n",
- pmu_batteries[batnum].flags);
- p += sprintf(p, "charge : %d\n",
- pmu_batteries[batnum].charge);
- p += sprintf(p, "max_charge : %d\n",
- pmu_batteries[batnum].max_charge);
- p += sprintf(p, "current : %d\n",
- pmu_batteries[batnum].amperage);
- p += sprintf(p, "voltage : %d\n",
- pmu_batteries[batnum].voltage);
- p += sprintf(p, "time rem. : %d\n",
- pmu_batteries[batnum].time_remaining);
-
- return p - page;
+ seq_putc(m, '\n');
+ seq_printf(m, "flags : %08x\n", pmu_batteries[batnum].flags);
+ seq_printf(m, "charge : %d\n", pmu_batteries[batnum].charge);
+ seq_printf(m, "max_charge : %d\n", pmu_batteries[batnum].max_charge);
+ seq_printf(m, "current : %d\n", pmu_batteries[batnum].amperage);
+ seq_printf(m, "voltage : %d\n", pmu_batteries[batnum].voltage);
+ seq_printf(m, "time rem. : %d\n", pmu_batteries[batnum].time_remaining);
+ return 0;
}
-static int
-proc_read_options(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int pmu_battery_proc_open(struct inode *inode, struct file *file)
{
- char *p = page;
+ return single_open(file, pmu_battery_proc_show, PDE(inode)->data);
+}
+static const struct file_operations pmu_battery_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = pmu_battery_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static int pmu_options_proc_show(struct seq_file *m, void *v)
+{
#if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC32)
if (pmu_kind == PMU_KEYLARGO_BASED &&
pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,-1) >= 0)
- p += sprintf(p, "lid_wakeup=%d\n", option_lid_wakeup);
+ seq_printf(m, "lid_wakeup=%d\n", option_lid_wakeup);
#endif
if (pmu_kind == PMU_KEYLARGO_BASED)
- p += sprintf(p, "server_mode=%d\n", option_server_mode);
+ seq_printf(m, "server_mode=%d\n", option_server_mode);
- return p - page;
+ return 0;
}
-
-static int
-proc_write_options(struct file *file, const char __user *buffer,
- unsigned long count, void *data)
+
+static int pmu_options_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, pmu_options_proc_show, NULL);
+}
+
+static ssize_t pmu_options_proc_write(struct file *file,
+ const char __user *buffer, size_t count, loff_t *pos)
{
char tmp[33];
char *label, *val;
- unsigned long fcount = count;
+ size_t fcount = count;
if (!count)
return -EINVAL;
@@ -927,6 +940,15 @@ proc_write_options(struct file *file, const char __user *buffer,
return fcount;
}
+static const struct file_operations pmu_options_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = pmu_options_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = pmu_options_proc_write,
+};
+
#ifdef CONFIG_ADB
/* Send an ADB command */
static int pmu_send_request(struct adb_request *req, int sync)
^ permalink raw reply
* [PATCH] iseries: convert to proc_fops
From: Alexey Dobriyan @ 2009-11-27 6:47 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, akpm, paulus
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
arch/powerpc/platforms/iseries/mf.c | 147 ++++++++++++++++++++----------------
1 file changed, 83 insertions(+), 64 deletions(-)
--- a/arch/powerpc/platforms/iseries/mf.c
+++ b/arch/powerpc/platforms/iseries/mf.c
@@ -855,59 +855,58 @@ static int mf_get_boot_rtc(struct rtc_time *tm)
}
#ifdef CONFIG_PROC_FS
-
-static int proc_mf_dump_cmdline(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int mf_cmdline_proc_show(struct seq_file *m, void *v)
{
- int len;
- char *p;
+ char *page, *p;
struct vsp_cmd_data vsp_cmd;
int rc;
dma_addr_t dma_addr;
/* The HV appears to return no more than 256 bytes of command line */
- if (off >= 256)
- return 0;
- if ((off + count) > 256)
- count = 256 - off;
+ page = kmalloc(256, GFP_KERNEL);
+ if (!page)
+ return -ENOMEM;
- dma_addr = iseries_hv_map(page, off + count, DMA_FROM_DEVICE);
- if (dma_addr == DMA_ERROR_CODE)
+ dma_addr = iseries_hv_map(page, 256, DMA_FROM_DEVICE);
+ if (dma_addr == DMA_ERROR_CODE) {
+ kfree(page);
return -ENOMEM;
- memset(page, 0, off + count);
+ }
+ memset(page, 0, 256);
memset(&vsp_cmd, 0, sizeof(vsp_cmd));
vsp_cmd.cmd = 33;
vsp_cmd.sub_data.kern.token = dma_addr;
vsp_cmd.sub_data.kern.address_type = HvLpDma_AddressType_TceIndex;
- vsp_cmd.sub_data.kern.side = (u64)data;
- vsp_cmd.sub_data.kern.length = off + count;
+ vsp_cmd.sub_data.kern.side = (u64)m->private;
+ vsp_cmd.sub_data.kern.length = 256;
mb();
rc = signal_vsp_instruction(&vsp_cmd);
- iseries_hv_unmap(dma_addr, off + count, DMA_FROM_DEVICE);
- if (rc)
+ iseries_hv_unmap(dma_addr, 256, DMA_FROM_DEVICE);
+ if (rc) {
+ kfree(page);
return rc;
- if (vsp_cmd.result_code != 0)
+ }
+ if (vsp_cmd.result_code != 0) {
+ kfree(page);
return -ENOMEM;
+ }
p = page;
- len = 0;
- while (len < (off + count)) {
- if ((*p == '\0') || (*p == '\n')) {
- if (*p == '\0')
- *p = '\n';
- p++;
- len++;
- *eof = 1;
+ while (p - page < 256) {
+ if (*p == '\0' || *p == '\n') {
+ *p = '\n';
break;
}
p++;
- len++;
- }
- if (len < off) {
- *eof = 1;
- len = 0;
}
- return len;
+ seq_write(m, page, p - page);
+ kfree(page);
+ return 0;
+}
+
+static int mf_cmdline_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, mf_cmdline_proc_show, PDE(inode)->data);
}
#if 0
@@ -962,10 +961,8 @@ static int proc_mf_dump_vmlinux(char *page, char **start, off_t off,
}
#endif
-static int proc_mf_dump_side(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int mf_side_proc_show(struct seq_file *m, void *v)
{
- int len;
char mf_current_side = ' ';
struct vsp_cmd_data vsp_cmd;
@@ -989,21 +986,17 @@ static int proc_mf_dump_side(char *page, char **start, off_t off,
}
}
- len = sprintf(page, "%c\n", mf_current_side);
+ seq_printf(m, "%c\n", mf_current_side);
+ return 0;
+}
- if (len <= (off + count))
- *eof = 1;
- *start = page + off;
- len -= off;
- if (len > count)
- len = count;
- if (len < 0)
- len = 0;
- return len;
+static int mf_side_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, mf_side_proc_show, NULL);
}
-static int proc_mf_change_side(struct file *file, const char __user *buffer,
- unsigned long count, void *data)
+static ssize_t mf_side_proc_write(struct file *file, const char __user *buffer,
+ size_t count, loff_t *pos)
{
char side;
u64 newSide;
@@ -1041,6 +1034,15 @@ static int proc_mf_change_side(struct file *file, const char __user *buffer,
return count;
}
+static const struct file_operations mf_side_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = mf_side_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = mf_side_proc_write,
+};
+
#if 0
static void mf_getSrcHistory(char *buffer, int size)
{
@@ -1087,8 +1089,7 @@ static void mf_getSrcHistory(char *buffer, int size)
}
#endif
-static int proc_mf_dump_src(char *page, char **start, off_t off,
- int count, int *eof, void *data)
+static int mf_src_proc_show(struct seq_file *m, void *v)
{
#if 0
int len;
@@ -1109,8 +1110,13 @@ static int proc_mf_dump_src(char *page, char **start, off_t off,
#endif
}
-static int proc_mf_change_src(struct file *file, const char __user *buffer,
- unsigned long count, void *data)
+static int mf_src_proc_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, mf_src_proc_show, NULL);
+}
+
+static ssize_t mf_src_proc_write(struct file *file, const char __user *buffer,
+ size_t count, loff_t *pos)
{
char stkbuf[10];
@@ -1135,9 +1141,19 @@ static int proc_mf_change_src(struct file *file, const char __user *buffer,
return count;
}
-static int proc_mf_change_cmdline(struct file *file, const char __user *buffer,
- unsigned long count, void *data)
+static const struct file_operations mf_src_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = mf_src_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = mf_src_proc_write,
+};
+
+static ssize_t mf_cmdline_proc_write(struct file *file, const char __user *buffer,
+ size_t count, loff_t *pos)
{
+ void *data = PDE(file->f_path.dentry->d_inode)->data;
struct vsp_cmd_data vsp_cmd;
dma_addr_t dma_addr;
char *page;
@@ -1172,6 +1188,15 @@ out:
return ret;
}
+static const struct file_operations mf_cmdline_proc_fops = {
+ .owner = THIS_MODULE,
+ .open = mf_cmdline_proc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = mf_cmdline_proc_write,
+};
+
static ssize_t proc_mf_change_vmlinux(struct file *file,
const char __user *buf,
size_t count, loff_t *ppos)
@@ -1246,12 +1271,10 @@ static int __init mf_proc_init(void)
if (!mf)
return 1;
- ent = create_proc_entry("cmdline", S_IFREG|S_IRUSR|S_IWUSR, mf);
+ ent = proc_create_data("cmdline", S_IRUSR|S_IWUSR, mf,
+ &mf_cmdline_proc_fops, (void *)(long)i);
if (!ent)
return 1;
- ent->data = (void *)(long)i;
- ent->read_proc = proc_mf_dump_cmdline;
- ent->write_proc = proc_mf_change_cmdline;
if (i == 3) /* no vmlinux entry for 'D' */
continue;
@@ -1263,19 +1286,15 @@ static int __init mf_proc_init(void)
return 1;
}
- ent = create_proc_entry("side", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root);
+ ent = proc_create("side", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root,
+ &mf_side_proc_fops);
if (!ent)
return 1;
- ent->data = (void *)0;
- ent->read_proc = proc_mf_dump_side;
- ent->write_proc = proc_mf_change_side;
- ent = create_proc_entry("src", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root);
+ ent = proc_create("src", S_IFREG|S_IRUSR|S_IWUSR, mf_proc_root,
+ &mf_src_proc_fops);
if (!ent)
return 1;
- ent->data = (void *)0;
- ent->read_proc = proc_mf_dump_src;
- ent->write_proc = proc_mf_change_src;
return 0;
}
^ permalink raw reply
* Re: Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT (v2)
From: David Gibson @ 2009-11-27 4:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev, Sachin Sant
In-Reply-To: <20091124053114.GD2737@yookeroo>
Oops, stupid compile bug in the !CONFIG_PPC_SUBPAGE_PROT case with the
last version. Fixed below.
Fix bug in pagetable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
Commit a0668cdc154e54bf0c85182e0535eea237d53146 cleans up the handling
of kmem_caches for allocating various levels of pagetables.
Unfortunately, it conflicts badly with CONFIG_PPC_SUBPAGE_PROT, due to
the latter's cleverly hidden technique of adding some extra allocation
space to the top level page directory to store the extra information
it needs.
Since that extra allocation really doesn't fit into the cleaned up
page directory allocating scheme, this patch alters
CONFIG_PPC_SUBPAGE_PROT to instead allocate its struct
subpage_prot_table as part of the mm_context_t.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/arch/powerpc/include/asm/mmu-hash64.h
===================================================================
--- working-2.6.orig/arch/powerpc/include/asm/mmu-hash64.h 2009-11-27 10:40:40.000000000 +1100
+++ working-2.6/arch/powerpc/include/asm/mmu-hash64.h 2009-11-27 15:54:27.423721648 +1100
@@ -373,6 +373,38 @@ extern void slb_set_size(u16 size);
#ifndef __ASSEMBLY__
+#ifdef CONFIG_PPC_SUBPAGE_PROT
+/*
+ * For the sub-page protection option, we extend the PGD with one of
+ * these. Basically we have a 3-level tree, with the top level being
+ * the protptrs array. To optimize speed and memory consumption when
+ * only addresses < 4GB are being protected, pointers to the first
+ * four pages of sub-page protection words are stored in the low_prot
+ * array.
+ * Each page of sub-page protection words protects 1GB (4 bytes
+ * protects 64k). For the 3-level tree, each page of pointers then
+ * protects 8TB.
+ */
+struct subpage_prot_table {
+ unsigned long maxaddr; /* only addresses < this are protected */
+ unsigned int **protptrs[2];
+ unsigned int *low_prot[4];
+};
+
+#define SBP_L1_BITS (PAGE_SHIFT - 2)
+#define SBP_L2_BITS (PAGE_SHIFT - 3)
+#define SBP_L1_COUNT (1 << SBP_L1_BITS)
+#define SBP_L2_COUNT (1 << SBP_L2_BITS)
+#define SBP_L2_SHIFT (PAGE_SHIFT + SBP_L1_BITS)
+#define SBP_L3_SHIFT (SBP_L2_SHIFT + SBP_L2_BITS)
+
+extern void subpage_prot_free(struct mm_struct *mm);
+extern void subpage_prot_init_new_context(struct mm_struct *mm);
+#else
+static inline void subpage_prot_free(struct mm_struct *mm) {}
+static inline void subpage_prot_init_new_context(struct mm_struct *mm) { }
+#endif /* CONFIG_PPC_SUBPAGE_PROT */
+
typedef unsigned long mm_context_id_t;
typedef struct {
@@ -386,6 +418,9 @@ typedef struct {
u16 sllp; /* SLB page size encoding */
#endif
unsigned long vdso_base;
+#ifdef CONFIG_PPC_SUBPAGE_PROT
+ struct subpage_prot_table spt;
+#endif /* CONFIG_PPC_SUBPAGE_PROT */
} mm_context_t;
Index: working-2.6/arch/powerpc/include/asm/pgalloc-64.h
===================================================================
--- working-2.6.orig/arch/powerpc/include/asm/pgalloc-64.h 2009-11-27 10:40:40.000000000 +1100
+++ working-2.6/arch/powerpc/include/asm/pgalloc-64.h 2009-11-27 10:55:00.654766147 +1100
@@ -28,10 +28,6 @@
*/
#define MAX_PGTABLE_INDEX_SIZE 0xf
-#ifndef CONFIG_PPC_SUBPAGE_PROT
-static inline void subpage_prot_free(pgd_t *pgd) {}
-#endif
-
extern struct kmem_cache *pgtable_cache[];
#define PGT_CACHE(shift) (pgtable_cache[(shift)-1])
@@ -42,7 +38,6 @@ static inline pgd_t *pgd_alloc(struct mm
static inline void pgd_free(struct mm_struct *mm, pgd_t *pgd)
{
- subpage_prot_free(pgd);
kmem_cache_free(PGT_CACHE(PGD_INDEX_SIZE), pgd);
}
Index: working-2.6/arch/powerpc/include/asm/pte-hash64-64k.h
===================================================================
--- working-2.6.orig/arch/powerpc/include/asm/pte-hash64-64k.h 2009-11-17 11:55:00.000000000 +1100
+++ working-2.6/arch/powerpc/include/asm/pte-hash64-64k.h 2009-11-27 10:55:00.654766147 +1100
@@ -76,41 +76,4 @@
remap_pfn_range((vma), (addr), (pfn), PAGE_SIZE, \
__pgprot(pgprot_val((prot)) | _PAGE_4K_PFN))
-
-#ifdef CONFIG_PPC_SUBPAGE_PROT
-/*
- * For the sub-page protection option, we extend the PGD with one of
- * these. Basically we have a 3-level tree, with the top level being
- * the protptrs array. To optimize speed and memory consumption when
- * only addresses < 4GB are being protected, pointers to the first
- * four pages of sub-page protection words are stored in the low_prot
- * array.
- * Each page of sub-page protection words protects 1GB (4 bytes
- * protects 64k). For the 3-level tree, each page of pointers then
- * protects 8TB.
- */
-struct subpage_prot_table {
- unsigned long maxaddr; /* only addresses < this are protected */
- unsigned int **protptrs[2];
- unsigned int *low_prot[4];
-};
-
-#undef PGD_TABLE_SIZE
-#define PGD_TABLE_SIZE ((sizeof(pgd_t) << PGD_INDEX_SIZE) + \
- sizeof(struct subpage_prot_table))
-
-#define SBP_L1_BITS (PAGE_SHIFT - 2)
-#define SBP_L2_BITS (PAGE_SHIFT - 3)
-#define SBP_L1_COUNT (1 << SBP_L1_BITS)
-#define SBP_L2_COUNT (1 << SBP_L2_BITS)
-#define SBP_L2_SHIFT (PAGE_SHIFT + SBP_L1_BITS)
-#define SBP_L3_SHIFT (SBP_L2_SHIFT + SBP_L2_BITS)
-
-extern void subpage_prot_free(pgd_t *pgd);
-
-static inline struct subpage_prot_table *pgd_subpage_prot(pgd_t *pgd)
-{
- return (struct subpage_prot_table *)(pgd + PTRS_PER_PGD);
-}
-#endif /* CONFIG_PPC_SUBPAGE_PROT */
#endif /* __ASSEMBLY__ */
Index: working-2.6/arch/powerpc/mm/subpage-prot.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/subpage-prot.c 2009-11-17 11:55:00.000000000 +1100
+++ working-2.6/arch/powerpc/mm/subpage-prot.c 2009-11-27 10:55:00.658768751 +1100
@@ -24,9 +24,9 @@
* Also makes sure that the subpage_prot_table structure is
* reinitialized for the next user.
*/
-void subpage_prot_free(pgd_t *pgd)
+void subpage_prot_free(struct mm_struct *mm)
{
- struct subpage_prot_table *spt = pgd_subpage_prot(pgd);
+ struct subpage_prot_table *spt = &mm->context.spt;
unsigned long i, j, addr;
u32 **p;
@@ -51,6 +51,13 @@ void subpage_prot_free(pgd_t *pgd)
spt->maxaddr = 0;
}
+void subpage_prot_init_new_context(struct mm_struct *mm)
+{
+ struct subpage_prot_table *spt = &mm->context.spt;
+
+ memset(spt, 0, sizeof(*spt));
+}
+
static void hpte_flush_range(struct mm_struct *mm, unsigned long addr,
int npages)
{
@@ -87,7 +94,7 @@ static void hpte_flush_range(struct mm_s
static void subpage_prot_clear(unsigned long addr, unsigned long len)
{
struct mm_struct *mm = current->mm;
- struct subpage_prot_table *spt = pgd_subpage_prot(mm->pgd);
+ struct subpage_prot_table *spt = &mm->context.spt;
u32 **spm, *spp;
int i, nw;
unsigned long next, limit;
@@ -136,7 +143,7 @@ static void subpage_prot_clear(unsigned
long sys_subpage_prot(unsigned long addr, unsigned long len, u32 __user *map)
{
struct mm_struct *mm = current->mm;
- struct subpage_prot_table *spt = pgd_subpage_prot(mm->pgd);
+ struct subpage_prot_table *spt = &mm->context.spt;
u32 **spm, *spp;
int i, nw;
unsigned long next, limit;
Index: working-2.6/arch/powerpc/mm/hash_utils_64.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/hash_utils_64.c 2009-11-27 10:40:40.000000000 +1100
+++ working-2.6/arch/powerpc/mm/hash_utils_64.c 2009-11-27 15:53:15.231721501 +1100
@@ -835,9 +835,9 @@ void demote_segment_4k(struct mm_struct
* Result is 0: full permissions, _PAGE_RW: read-only,
* _PAGE_USER or _PAGE_USER|_PAGE_RW: no access.
*/
-static int subpage_protection(pgd_t *pgdir, unsigned long ea)
+static int subpage_protection(struct mm_struct *mm, unsigned long ea)
{
- struct subpage_prot_table *spt = pgd_subpage_prot(pgdir);
+ struct subpage_prot_table *spt = &mm->context.spt;
u32 spp = 0;
u32 **sbpm, *sbpp;
@@ -865,7 +865,7 @@ static int subpage_protection(pgd_t *pgd
}
#else /* CONFIG_PPC_SUBPAGE_PROT */
-static inline int subpage_protection(pgd_t *pgdir, unsigned long ea)
+static inline int subpage_protection(struct mm_struct *mm, unsigned long ea)
{
return 0;
}
Index: working-2.6/arch/powerpc/mm/mmu_context_hash64.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/mmu_context_hash64.c 2009-11-27 10:40:40.000000000 +1100
+++ working-2.6/arch/powerpc/mm/mmu_context_hash64.c 2009-11-27 10:55:00.658768751 +1100
@@ -76,6 +76,7 @@ int init_new_context(struct task_struct
*/
if (slice_mm_new_context(mm))
slice_set_user_psize(mm, mmu_virtual_psize);
+ subpage_prot_init_new_context(mm);
mm->context.id = index;
return 0;
@@ -92,5 +93,6 @@ EXPORT_SYMBOL_GPL(__destroy_context);
void destroy_context(struct mm_struct *mm)
{
__destroy_context(mm->context.id);
+ subpage_prot_free(mm);
mm->context.id = NO_CONTEXT;
}
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 0/4] powerpc: Fix minor build issues on 2.6.32-rc7 without CONFIG_XICS set
From: Benjamin Herrenschmidt @ 2009-11-27 2:40 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20091118170510.GA1119@csn.ul.ie>
On Wed, 2009-11-18 at 17:05 +0000, Mel Gorman wrote:
>
> diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
> index 04a8061..a82c470 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -52,9 +52,9 @@ config PPC_UDBG_BEAT
> default n
>
> config XICS
> - depends on PPC_PSERIES
> + depends on PCI_MSI
> bool
> - default y
> + default n
Why the above ? XICS only exist on PSERIES and select bypass depends in
nasty ways anyways.
> config IPIC
> bool
> diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
> index f0e6f28..81c2289 100644
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -5,6 +5,8 @@ config PPC_PSERIES
> select PPC_I8259
> select PPC_RTAS
> select RTAS_ERROR_LOGGING
> + select PCI_MSI
> + select XICS
> select PPC_UDBG_16550
> select PPC_NATIVE
> select PPC_PCI_CHOICE if EMBEDDED
The above bits look plenty enough. Can you also stick it next to the
MPIC one ?
Cheers,
Ben.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] powerpc/mm: honor O_SYNC flag for memory mapping
From: Paul Mackerras @ 2009-11-27 2:40 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1259222529-27645-1-git-send-email-leoli@freescale.com>
Li Yang writes:
> There was no way to set mapped memory as cacheable if the memory
> is not managed by Linux kernel. It's not rare in real system to
> allocate some dedicated memory to a certain application which is not
> managed by kernel and then mmap'ed the memory to the application.
> The memory should be cacheable but we can't map it to be cacheable
> due to the intelligent setting of cacheability.
>
> The patch makes the cacheability depend on O_SYNC flag of the file
> mapped for non-kernel managed memory. Also prints a deprecation
> warning for mmap users without using O_SYNC.
NAK, since it is an incompatible change to the kernel ABI.
What sort of memory is this that you want to map as cacheable? Is it
normal system RAM that your platform code reserves, or is it some
other kind of memory?
If it's the normal system RAM, you could make phys_mem_access_prot()
smart enough to recognize that (by looking in the lmb array or the
device tree).
If it's another kind of memory, it should be described in the device
tree, and you could have a platform-specific phys_mem_access_prot
function for your platform that looks in the device tree to see if the
memory being mapped is this special sort of memory.
Paul.
^ permalink raw reply
* Re: [RFC] powerpc/mm: honor O_SYNC flag for memory map
From: Paul Mackerras @ 2009-11-27 2:30 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, Li Yang-R58472
In-Reply-To: <2a27d3730911252343j6a938d99n7152b7cc8d01c0bf@mail.gmail.com>
Li Yang writes:
> That's my concern too. But after all mmap without O_SYNC on I/O
> devices should be deprecated.
It should? Why?
Shouldn't the onus rather be on those proposing an incompatible change
to the kernel ABI, such as this is, to show why the change is
absolutely essential?
> A warning message in deprecation period
> could reduce potential problem caused by this change.
Not making the change at all would reduce the potential problems even
further. :)
Paul.
^ permalink raw reply
* Re: [RFC PATCH 04/19] powerpc: wii: device tree
From: Benjamin Herrenschmidt @ 2009-11-27 0:15 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <4AE0F44D-CAD9-457C-9E5D-0279F28D70AF@kernel.crashing.org>
On Fri, 2009-11-27 at 01:16 +0100, Segher Boessenkool wrote:
>
> In all code I have done for the XFB, I map it like any other RAM and
> dcbst it after writing to it. Maybe that is slower though, WIMG=0100
> might be better. Dunno.
Well, it depends also what you want to do with it. If you want to expose
it as a standard linux fbdev, it might break apps to expect them to use
dcbst... but it will make rmw cycles a lot faster and avoid wasting
memory with shadowfb.
It's going to mostly depend on what kind of HW accel we can get out of
it, if we get good enough accel we can probably got for I=1 like a
standard fb
Ben.
^ permalink raw reply
* Re: [RFC PATCH 02/19] powerpc: gamecube: device tree
From: Segher Boessenkool @ 2009-11-27 0:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <1259275130.2659.4.camel@pasglop>
>>>> If you have only one interrupt controller, like here, you don't
>>>> need to refer to it _at all_ :-)
>>>
>>> I think Linux requires that you do though. It might be a mistake on
>>> our
>>> part but heh ...
>>
>> Linux doesn't require it; (old) Macs are like this, for example,
>> and that works fine. Oh and all Maple firmwares are like that as
>> well I think. Etc.
>
> It works fine on old macs thanks to a quirk we enable in the mac code
> iirc and old maple works thanks to mere luck with the fallback code we
> have which reads things of PCI config space :-)
>
> Don't rely on that.
It is standard OF. Let's fix the Linux code if that is needed (and I
don't
think it is, anyway).
OTOH, it's nice to use the interrupt mapping stuff in all new device
trees.
Segher
^ permalink raw reply
* Re: [RFC PATCH 04/19] powerpc: wii: device tree
From: Segher Boessenkool @ 2009-11-27 0:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <1259275057.2659.3.camel@pasglop>
>> Yup. The idea is to map the first 16MB of MEM1 with a BAT.
>> Mapping the whole 24MB with BATs may not be possible because we
>> want the framebuffer
>> in MEM1 for performance reasons.
>
> How big is the fb ?
A bit more than a megabyte, something like that.
> We have plenty of BATs on these things... so one 16M
> for the low mem and one 64M for the "high" mem, that leaves something
> like 6 to manage as much as possible up to the fb :-)
The CXe in the gamecube has only four BATs though.
In all code I have done for the XFB, I map it like any other RAM and
dcbst it after writing to it. Maybe that is slower though, WIMG=0100
might be better. Dunno.
Segher
^ permalink raw reply
* Re: [RFC PATCH 12/19] powerpc: gamecube: platform support
From: Segher Boessenkool @ 2009-11-27 0:09 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4B0EFC1D.5030806@yahoo.es>
>>> We need it as it currently doesn't match with the default bus ids.
>>
>>> Should I introduce a .type property matching any of those above
>>> in the
>>> soc node, and get rid of the explicit bus probe?
>>
>> You don't need any fake bus as far as I can see, just probe the
>> devices
>> you want.
>
> But it's way easier to let the bus probe do it for us. I don't see
> the win here.
As long as this doesn't leak into the device tree in any way, I don't
care. How's that? :-)
Segher
^ permalink raw reply
* Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
From: Segher Boessenkool @ 2009-11-27 0:06 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4B0EFBB2.9090206@yahoo.es>
>>>> Maybe using FLIPPER (or GAMECUBE_FLIPPER) instead of
>>>> GAMECUBE_COMMON
>>>> is a good name?
>>>
>>> I'd prefer to not use a name that implies a specific hardware to
>>> describe two (mostly) similar but different hardwares.
>>
>> Hollywood is 100% compatible to Flipper though.
>
> No. There's no ARAM for example :)
ARAM is an external device.
>>>>> +/*
>>>>> + * Each interrupt has a corresponding bit in both
>>>>> + * the Interrupt Cause (ICR) and Interrupt Mask (IMR) registers.
>>>>> + *
>>>>> + * Enabling/disabling an interrupt line involves asserting/
>>>>> clearing
>>>>> + * the corresponding bit in IMR. ACK'ing a request simply
>>>>> involves
>>>>> + * asserting the corresponding bit in ICR.
>>>>> + */
>>
>> I looked it up in YAGCD; it says that _reading_ the ICR reg already
>> acks all interrupts (and clears the bits), you never write this reg!
>
> YAGCD is not always right. You should not take it as _the truth_.
Oh I know. But I have no better source of information. Well I could
actually test it, that's very easy using OF :-) Let's do that.
>>> No, it acks just a single IRQ.
>>
>> No it doesn't. Say IRQs 1 and 3 are asserted, so the reg contains
>> 0x0a.
>> Now you want to ack IRQ1; set_bit() will write 0x0a | 0x02, not
>> just 0x02.
>
> Let me rephrase it. No it should just ack a single IRQ :)
>
> So then this is working by accident.
> If that's the case, I guess it works because the interrupt is not
> cleared at the source and the ICR is set again immediately for any
> pending interrupt?
Probably, yes. Also, you will not often have more than one interrupt
pending anyway (on the legacy PIC).
Segher
^ permalink raw reply
* Re: [RFC PATCH 11/19] powerpc: gamecube/wii: flipper interrupt controller support
From: Benjamin Herrenschmidt @ 2009-11-26 23:38 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <8DD300BC-A3F3-4569-9BFC-62366F59BDA0@kernel.crashing.org>
On Fri, 2009-11-27 at 00:00 +0100, Segher Boessenkool wrote:
> >>> +unsigned int flipper_pic_get_irq(void)
> >>> +{
> >>> + void __iomem *io_base = flipper_irq_host->host_data;
> >>> + int irq;
> >>> + u32 irq_status;
> >>> +
> >>> + irq_status = in_be32(io_base + FLIPPER_ICR) &
> >>> + in_be32(io_base + FLIPPER_IMR);
> >>> + if (irq_status == 0)
> >>> + return -1; /* no more IRQs pending */
> >>
> >> NO_IRQ_IGNORE
> >
> > Why no just 0 ? (aka NO_IRQ)
> >
> > Or do you know you are getting lots of spurrious that you don't
> > want to
> > account ?
>
> IRQ #0 is a valid IRQ here (graphics error IIRC), it should be
> remapped I suppose?
All interrupts are remapped. _get_irq() should call the appropriate
revmap function to remap the HW number into a linux number. 0 is never a
valid linux number and means "no interrupt".
In the above case, it would seem to me that what he gets is a bitfield
so 0 means no interrupt. Hence the code should be:
if (irq_status == 0)
return 0;
Then, find first bit and return the linear revmap... Just look at what
the old pmac_pic does, same stuff basically.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 04/11] of/flattree: eliminate cell_t typedef
From: David Miller @ 2009-11-26 23:32 UTC (permalink / raw)
To: segher
Cc: sfr, devicetree-discuss, microblaze-uclinux, sparclinux,
linuxppc-dev
In-Reply-To: <F307E7FB-0819-47E8-9CF4-CA1433C18DA6@kernel.crashing.org>
From: Segher Boessenkool <segher@kernel.crashing.org>
Date: Thu, 26 Nov 2009 22:36:41 +0100
>>> You're right, it's not, but makes merging less complex, and then I can
>>> refactor properly.
>>
>> Still, make them __be32 at least
>
> There is no alignment guarantee at all either, better make it all u8
> and use accessor functions everywhere.
I think that might be overkill.
^ permalink raw reply
* Re: [RFC PATCH 10/19] powerpc: gamecube/wii: early debugging using usbgecko
From: Benjamin Herrenschmidt @ 2009-11-26 23:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Albert Herranz, linuxppc-dev, Arnd Bergmann
In-Reply-To: <0E5CD213-9ADE-4C49-9BD1-1DE96830F65E@kernel.crashing.org>
On Thu, 2009-11-26 at 23:54 +0100, Segher Boessenkool wrote:
> No Ben. The whole point of EARLY_DEBUG is that it _always works_,
> because
> it is such trivial code. Don't break that please, or we'll be forced to
> add a "REALLY_EARLY_DEBUG" instead :-)
I do tend to agree but heh... temptation to do more cute hacks ... :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 04/19] powerpc: wii: device tree
From: Segher Boessenkool @ 2009-11-26 23:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <1259269265.18084.14.camel@pasglop>
>> There you can find the hardware interface that supports the IPC
>> mechanism.
>> It is made up of a pair of registers to pass data between the
>> processors and a
>> pair of control/flags registers.
>> The hardware can interrupt the PowerPC side when there is data
>> available for it.
>
> Ok. So the right way to do that would be to have a node purely
> representing the HW IPC, unrelated to whatever is running on the
> secondary processor.
Or you can keep it implicit in the Hollywood control registers.
It is one 512-byte block with lots of things thrown together (and
then mixed up real good).
> However, it's ok to have -below- that node, a set of device nodes or a
> node with properties or whatever representing the FW in there and the
> function it exposes.
That's not really useful though, it's easy to probe for.
> What might do however is to have a way for that FW itself to
> provide you
> with the nodes and properties for the functions it provides :-)
You get a pointer at the very last word of memory. It point to an
info header that has everything you need to know (most importantly,
a version identifier).
> Of course that wouldn't work with FW we don't have control on. Can
> Linux
> run on the wii with the original N. FW on the aux. processor ?
It _can_, but there are no advantages to doing that, and lots and
lots of
disadvantages, so the plan is to not add support for that in mainline.
> Can we
> detect what is running there ? Do we care ?
You can detect this for anything that uses a mini-compatible interface.
You shouldn't care for anything else ;-)
Segher
^ permalink raw reply
* Re: [RFC PATCH 04/19] powerpc: wii: device tree
From: Segher Boessenkool @ 2009-11-26 23:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <1259268528.18084.2.camel@pasglop>
>> They are a bit special because registers are in reverse little
>> endian format,
>> must be written in 32-bit chunks, and (all things point to) they
>> have hardware bugs.
>
> Well.. first what is "reverse little endian" ? :-) Big endian ?
Nah. Little-endian, with a 32-bit bus swizzle. This is not the
same thing as big-endian when not all your registers are 32 bits.
Also, you can only write 32 bits, they don't use byte enables.
> As for HW bugs, well, as long as we know them we can define a quirk
> bit
> and add the necessary workarounds to the driver :-)
The question is if the device is close enough to OHCI to declare it
as that in the device tree. I would say "yes".
Segher
^ permalink raw reply
* Re: [RFC PATCH 09/19] powerpc: gamecube/wii: udbg support for usbgecko
From: Segher Boessenkool @ 2009-11-26 23:12 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <4B0E9E84.4060400@yahoo.es>
> The usbgecko is hotplugable and hotswappable.
> But as this is mostly a developer feature, not normaly used by end
> users, I think that we can just let it be as it is: autodetect it
> on boot (now probing for it instead of using information from the
> device tree).
> If you unplug it later it causes no errors, you just miss whatever
> data is sent to it.
You can get interrupts when an EXI device is plugged or unplugged; the
"normal" driver should use that. But you haven't posted that yet.
The "early debug" driver can just assume the user doesn't like to hurt
himself, and provide pain when the user does, there's no problem with
that :-)
Segher
^ permalink raw reply
* Re: [RFC PATCH 04/19] powerpc: wii: device tree
From: Albert Herranz @ 2009-11-26 23:02 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <927C3343-380D-40F7-A52E-8F842A5F4C3E@kernel.crashing.org>
Segher Boessenkool wrote:
>> So what is at d0000000 ?
>
> 0c000000 is the flipper-compatible stuff
> 0d000000 is the hollywood new devices
> 0d800000 is the same as part of 0d000000, but with some extra bits
> sometimes.
>
Also, when in Wii native mode, stuff like EXI, SI and AI (which is flipper-compatible stuff too) is available at 0d000000 only.
>>>> + serial@0d006400 {
>>>> + compatible = "nintendo,hollywood-serial";
>>>
>>> You might want to pick a more descriptive name for this,
>>> "serial" is usually understaood to mean "RS232". Which
>>> this isn't.
>>
>> What is it then ? You definitely want some other name if it's not
>> classic rs232 style serial.
>
> It's SPI I think, with some extra signals. It's the gamepads mostly.
>
EXI is SPI.
But SI is a different thingy.
See http://www.int03.co.uk/crema/hardware/gamecube/gc-control.htm .
>
> Segher
>
>
Cheers,
Albert
^ permalink raw reply
* Re: [RFC PATCH 03/19] powerpc: gamecube: bootwrapper bits
From: Segher Boessenkool @ 2009-11-26 23:06 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: Albert Herranz, linuxppc-dev
In-Reply-To: <20091126081724.GA6538@iram.es>
>>> Sure, the memory controllers don't do coherency. I'm slightly
>>> worried
>>> about two things:
>>> 1) Will the generic code use M=0 as well? Is it a problem if it
>>> doesn't?
>>
>> We can make it not do it.
>>
>>> 2) Do lwarx. etc. work in M=0?
>>
>> They should hopefully... as long as you don't rely on the reservation
>> blowing as a result of a DMA write.
>
> Hmm, this really depends on whether the DMA transfers generate bus
> cycles
> that require coherency or not.
They do not; device DMA never goes to the 6xx bus with this bridge.
> Not the other way around. M=1 only forces
> bus cycles to be snooped by other processors (asserting the GBL signal
> on 603/604/750 busses).
Right, it enables sending probes, not receiving them. On this CPU
anyway.
The architecture specification is quite silent on this all.
Segher
^ 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