Re: [PATCH] Adjust arch/powerpc inline asms for recent gcc change
On Fri, 2010-06-25 at 11:56 +0200, Jakub Jelinek wrote:
static inline void sync(void)
diff --git a/arch/powerpc/include/asm/atomic.h
b/arch/powerpc/include/asm/atomic.h
index b8f152e..288d8b2 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -19,14 +19,14 @@ static __inline__ int atomic_read(const atomic_t *v)
{
int t;
- __asm__ __volatile__(lwz%U1%X1 %0,%1 : =r(t) : m(v-counter));
+ __asm__ __volatile__(lwz%U1%X1 %0,%1 : =r(t) : m(v-counter));
return t;
}
This gives me:
/home/benh/linux-powerpc-test/arch/powerpc/kernel/time.c: In function
‘timer_interrupt’:
/home/benh/linux-powerpc-test/arch/powerpc/include/asm/atomic.h:22: error:
‘asm’ operand has impossible constraints
make[2]: *** [arch/powerpc/kernel/time.o] Error 1
$ gcc --version
gcc (Debian 4.4.4-1) 4.4.4
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] mtd: m25p80: Fix false-positive probing
On Tue, 2010-06-22 at 20:57 +0400, Anton Vorontsov wrote: Since commit 18c6182bae0acca220ed6611f741034d563cd19f (Rework probing/JEDEC code), m25p80 driver successfully registers chips even if JEDEC probing fails. This was needed to support non-JEDEC flashes. Though, it appears that some platforms (e.g. blackfin bf533 stamp[1]) used the old behavior to detect if there's any flash connected, so the driver have to fail on JEDEC probing errors. This patch restores the old behavior for JEDEC flashes, and adds -nonjedec SPI device IDs for M25Pxx flashes, so that the kernel still supports non-JEDEC flashes. [1] http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdittracker_item_id=5975 Reported-by: Mingquan Pan Reported-by: Barry Song 21cn...@gmail.com Signed-off-by: Anton Vorontsov avoront...@mvista.com --- Pushed both patches to my l2-mtd-2.6.git / dunno, added Mike's ack. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add cmd64x IDE driver to default pmac32 config
On Thu, 2010-07-08 at 15:00 +1000, Benjamin Herrenschmidt wrote: On Sat, 2010-07-03 at 20:21 +0200, lawrence rust wrote: The Blue/White Apple PowerMac G3 and early G4's use a cmd64x compatible IDE disk controller. E.g. lspci shows... 01:01.0 IDE interface: Silicon Image, Inc. PCI0646 (rev 07) Unfortunately the default pmac32 configuration does not include this driver and so PowerMac G3's can't load a root filesystem. This is an issue on a least Ubuntu since version 9.04, which uses the default config as a starting point. Signed-off-by: Lawrence Rust lawrence at softsystem.co.uk Shouldn't we just switch the whole thing to libata now anyways ? Sure. it would be preferable but unfortunately the PowerMac on-board IDE controller (CONFIG_BLK_DEV_IDE_PMAC), used for the DVD drive on B/W G3's, doesn't have a PATA equivalent. So it's pragmatic (until the IDE code is removed) to use the IDE cmd64x driver to minimise kernel code size. A minor correction to my previous post, the first version of Ubuntu to suffer from this problem was 9.10. -- Lawrence Cheers, Ben. diff -uprN a/arch/powerpc/configs/pmac32_defconfig b/arch/powerpc/configs/pmac32_defconfig --- a/arch/powerpc/configs/pmac32_defconfig 2010-05-16 23:17:36.0 +0200 +++ b/arch/powerpc/configs/pmac32_defconfig 2010-07-03 20:11:10.0 +0200 @@ -738,7 +738,7 @@ CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set -# CONFIG_BLK_DEV_CMD64X is not set +CONFIG_BLK_DEV_CMD64X=y # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- -- Lawrence Rust ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add cmd64x IDE driver to default pmac32 config
On Thu, 2010-07-08 at 08:18 +0200, lawrence rust wrote: Sure. it would be preferable but unfortunately the PowerMac on-board IDE controller (CONFIG_BLK_DEV_IDE_PMAC), used for the DVD drive on B/W G3's, doesn't have a PATA equivalent. So it's pragmatic (until the IDE code is removed) to use the IDE cmd64x driver to minimise kernel code size. Sure it does nowadays: drivers/ata/pata_macio.c :-) I merged that upstream in december last year, so it didn't make 2.6.32 which your distro probably uses, but it is in .33 and later. A minor correction to my previous post, the first version of Ubuntu to suffer from this problem was 9.10. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/kexec: Switch to a static PACA on the way out
With dynamic PACAs, the kexecing CPU's PACA won't lie within the kernel
static data and there is a chance that something may stomp it when preparing
to kexec. This patch switches this final CPU to a static PACA just before
we pull the switch.
Signed-off-by: Matt Evans m...@ozlabs.org
---
v2: Changes from Milton's review:
- Use setup_paca() and move from setup_64.c,
- SLB cache inval. not required,
- Adjust 'paca' (oops..), and
- Poison data_offset/per_cpu_offset
arch/powerpc/include/asm/paca.h|2 +-
arch/powerpc/kernel/machine_kexec_64.c | 20
arch/powerpc/kernel/paca.c | 10 ++
arch/powerpc/kernel/setup_64.c | 10 --
4 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 8ce7963..1ff6662 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -146,7 +146,7 @@ struct paca_struct {
extern struct paca_struct *paca;
extern __initdata struct paca_struct boot_paca;
extern void initialise_paca(struct paca_struct *new_paca, int cpu);
-
+extern void setup_paca(struct paca_struct *new_paca);
extern void allocate_pacas(void);
extern void free_unused_pacas(void);
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index 26f9900..c4d0123 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -273,6 +273,12 @@ static void kexec_prepare_cpus(void)
static union thread_union kexec_stack __init_task_data =
{ };
+/*
+ * For similar reasons to the stack above, the kexecing CPU needs to be on a
+ * static PACA; we switch to kexec_paca.
+ */
+struct paca_struct kexec_paca;
+
/* Our assembly helper, in kexec_stub.S */
extern NORET_TYPE void kexec_sequence(void *newstack, unsigned long start,
void *image, void *control,
@@ -300,6 +306,20 @@ void default_machine_kexec(struct kimage *image)
kexec_stack.thread_info.task = current_thread_info()-task;
kexec_stack.thread_info.flags = 0;
+ /* We need a static PACA, too; copy this CPU's PACA over and switch to
+* it. Also poison per_cpu_offset to catch anyone using non-static
+* data.
+*/
+ memcpy(kexec_paca, get_paca(), sizeof(struct paca_struct));
+ kexec_paca.data_offset = 0xedeaddeadeeeUL;
+ paca = (struct paca_struct *)RELOC_HIDE(kexec_paca, 0) -
+ kexec_paca.paca_index;
+ setup_paca(kexec_paca);
+
+ /* XXX: If anyone does 'dynamic lppacas' this will also need to be
+* switched to a static version!
+*/
+
/* Some things are best done in assembly. Finding globals with
* a toc is easier in C, so pass in what we can.
*/
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index f88acf0..3db8d64 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -105,6 +105,16 @@ void __init initialise_paca(struct paca_struct *new_paca,
int cpu)
#endif /* CONFIG_PPC_STD_MMU_64 */
}
+/* Put the paca pointer into r13 and SPRG_PACA */
+void setup_paca(struct paca_struct *new_paca)
+{
+ local_paca = new_paca;
+ mtspr(SPRN_SPRG_PACA, local_paca);
+#ifdef CONFIG_PPC_BOOK3E
+ mtspr(SPRN_SPRG_TLB_EXFRAME, local_paca-extlb);
+#endif
+}
+
static int __initdata paca_size;
void __init allocate_pacas(void)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index f3fb5a7..6efbed4 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -142,16 +142,6 @@ early_param(smt-enabled, early_smt_enabled);
#define check_smt_enabled()
#endif /* CONFIG_SMP */
-/* Put the paca pointer into r13 and SPRG_PACA */
-static void __init setup_paca(struct paca_struct *new_paca)
-{
- local_paca = new_paca;
- mtspr(SPRN_SPRG_PACA, local_paca);
-#ifdef CONFIG_PPC_BOOK3E
- mtspr(SPRN_SPRG_TLB_EXFRAME, local_paca-extlb);
-#endif
-}
-
/*
* Early initialization entry point. This is called by head.S
* with MMU translation disabled. We rely on the feature of
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are a few powerpc nits and bits still for 2.6.35. Mostly simple/trivial stuff and some gcc-4.5 related fixes. Thanks ! Cheers, Ben. The following changes since commit 2aa72f612144a0a7d4b0b22ae7c122692ac6a013: Linus Torvalds (1): Merge git://git.kernel.org/.../davem/net-2.6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Anton Blanchard (1): powerpc: Linux cannot run with 0 cores Denis Kirjanov (1): powerpc/iseries: Fix possible null pointer dereference in iSeries_pcibios_fixup_resources Johannes Berg (1): powerpc: Fix logic error in fixup_irqs Matt Evans (1): powerpc/perf_event: Fix for power_pmu_disable() Paul E. McKenney (1): powerpc: Fix default_machine_crash_shutdown #ifdef botch Sam Ravnborg (1): powerpc: Fix userspace build of ptrace.h Stephen Rothwell (3): powerpc: Fix module building for gcc 4.5 and 64 bit powerpc: Fix compile errors in prom_init_check for gcc 4.5 powerpc: Fix feature-fixup tests for gcc 4.5 Yang Li (1): powerpc: Disable SPARSE_IRQ by default arch/powerpc/Kconfig |4 +- arch/powerpc/Makefile |4 +- arch/powerpc/include/asm/ptrace.h | 32 - arch/powerpc/kernel/crash.c|2 +- arch/powerpc/kernel/irq.c |5 +- arch/powerpc/kernel/perf_event.c |5 +- arch/powerpc/kernel/prom_init.c|2 +- arch/powerpc/kernel/prom_init_check.sh |6 ++ arch/powerpc/lib/Makefile |4 +- arch/powerpc/lib/crtsavres.S | 129 arch/powerpc/lib/feature-fixups.c | 17 ++-- arch/powerpc/platforms/iseries/pci.c |6 +- scripts/mod/modpost.c |5 + 13 files changed, 184 insertions(+), 37 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add cmd64x IDE driver to default pmac32 config
On Thu, 2010-07-08 at 16:30 +1000, Benjamin Herrenschmidt wrote: On Thu, 2010-07-08 at 08:18 +0200, lawrence rust wrote: Sure. it would be preferable but unfortunately the PowerMac on-board IDE controller (CONFIG_BLK_DEV_IDE_PMAC), used for the DVD drive on B/W G3's, doesn't have a PATA equivalent. So it's pragmatic (until the IDE code is removed) to use the IDE cmd64x driver to minimise kernel code size. Sure it does nowadays: drivers/ata/pata_macio.c :-) I merged that upstream in december last year, so it didn't make 2.6.32 which your distro probably uses, but it is in .33 and later. OK I see that - good news. However, for the moment I believe that it's safer to stay with IDE. It's the smallest of changes but the wholesale move to libata could well break numerous system install scripts - e.g. for yaboot. -- Lawrence ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
On Wed, 07 Jul 2010 around 10:51:20 - Matthew McClintock wrote:
Fix sizes of variables so correct values are exported via /proc.
Cast variable in comparison to avoid compiler error.
Signed-off-by: Matthew McClintock m...@freescale.com
- csize = min(csize, PAGE_SIZE);
+ csize = min(csize, (size_t)PAGE_SIZE);
no use min_t
- if (pfn max_pfn) {
+ if ((min_low_pfn pfn) (pfn max_pfn)) {
vaddr = __va(pfn PAGE_SHIFT);
csize = copy_oldmem_vaddr(vaddr, buf, csize, offset, userbuf);
} else {
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index bb3d893..ec7f054 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -145,6 +145,7 @@ int overlaps_crashkernel(unsigned long start, unsigned
long size)
/* Values we need to export to the second kernel via the device tree. */
static unsigned long kernel_end;
+static unsigned long crashk_start;
static unsigned long crashk_size;
static struct property kernel_end_prop = {
@@ -156,7 +157,7 @@ static struct property kernel_end_prop = {
static struct property crashk_base_prop = {
.name = linux,crashkernel-base,
.length = sizeof(unsigned long),
- .value = crashk_res.start,
+ .value = crashk_start,
};
This is wrong, its truncating the start and size.
Change the variables to be physaddr_t and the length to be sizeof(physaddr_t).
Since these properites only contain one variable, the number of cells
can be inferred from the property size like we do for reading the initrd-size.
Technically they should be an array of be32 but we can make that a comment.
By the way, why does 32 bit care about the running kernel's size? aka
linux,kernel-end? 64 bit book 3S needs it because we use mmu hooks
to copy the pages to their destination, but I thought ppc32 was using
a relocatable copy routine. Are we missing the code to create
temp ref tlbs on the fly for book 3E?
static struct property crashk_size_prop = {
@@ -180,6 +181,7 @@ static void __init export_crashk_values(struct
device_node *node)
prom_remove_property(node, prop);
if (crashk_res.start != 0) {
+ crashk_start = crashk_res.start;
prom_add_property(node, crashk_base_prop);
crashk_size = crashk_res.end - crashk_res.start + 1;
prom_add_property(node, crashk_size_prop);
I guess we use the reuse of the resources varables, but such is
common code vs userspace.
milton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add cmd64x IDE driver to default pmac32 config
On Thu, 2010-07-08 at 11:01 +0200, lawrence rust wrote: On Thu, 2010-07-08 at 16:30 +1000, Benjamin Herrenschmidt wrote: On Thu, 2010-07-08 at 08:18 +0200, lawrence rust wrote: Sure. it would be preferable but unfortunately the PowerMac on-board IDE controller (CONFIG_BLK_DEV_IDE_PMAC), used for the DVD drive on B/W G3's, doesn't have a PATA equivalent. So it's pragmatic (until the IDE code is removed) to use the IDE cmd64x driver to minimise kernel code size. Sure it does nowadays: drivers/ata/pata_macio.c :-) I merged that upstream in december last year, so it didn't make 2.6.32 which your distro probably uses, but it is in .33 and later. OK I see that - good news. However, for the moment I believe that it's safer to stay with IDE. It's the smallest of changes but the wholesale move to libata could well break numerous system install scripts - e.g. for yaboot. Well, distros have moved over mostly... I don't think keeping the defaults to the old stuff upstream is going to help getting things like yaboot fixed. I'll talk to Tony see what the situation there is tomorrow, but I'd rather fix yaboot and switch the default over. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
On Thu, 2010-07-08 at 04:07 -0500, Milton Miller wrote:
On Wed, 07 Jul 2010 around 10:51:20 - Matthew McClintock wrote:
Fix sizes of variables so correct values are exported via /proc.
Cast variable in comparison to avoid compiler error.
I'm afraid I already pulled that in. Please send a fixup patch.
Cheers,
Ben.
Signed-off-by: Matthew McClintock m...@freescale.com
- csize = min(csize, PAGE_SIZE);
+ csize = min(csize, (size_t)PAGE_SIZE);
no use min_t
- if (pfn max_pfn) {
+ if ((min_low_pfn pfn) (pfn max_pfn)) {
vaddr = __va(pfn PAGE_SHIFT);
csize = copy_oldmem_vaddr(vaddr, buf, csize, offset, userbuf);
} else {
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index bb3d893..ec7f054 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -145,6 +145,7 @@ int overlaps_crashkernel(unsigned long start, unsigned
long size)
/* Values we need to export to the second kernel via the device tree. */
static unsigned long kernel_end;
+static unsigned long crashk_start;
static unsigned long crashk_size;
static struct property kernel_end_prop = {
@@ -156,7 +157,7 @@ static struct property kernel_end_prop = {
static struct property crashk_base_prop = {
.name = linux,crashkernel-base,
.length = sizeof(unsigned long),
- .value = crashk_res.start,
+ .value = crashk_start,
};
This is wrong, its truncating the start and size.
Change the variables to be physaddr_t and the length to be sizeof(physaddr_t).
Since these properites only contain one variable, the number of cells
can be inferred from the property size like we do for reading the initrd-size.
Technically they should be an array of be32 but we can make that a comment.
By the way, why does 32 bit care about the running kernel's size? aka
linux,kernel-end? 64 bit book 3S needs it because we use mmu hooks
to copy the pages to their destination, but I thought ppc32 was using
a relocatable copy routine. Are we missing the code to create
temp ref tlbs on the fly for book 3E?
static struct property crashk_size_prop = {
@@ -180,6 +181,7 @@ static void __init export_crashk_values(struct
device_node *node)
prom_remove_property(node, prop);
if (crashk_res.start != 0) {
+ crashk_start = crashk_res.start;
prom_add_property(node, crashk_base_prop);
crashk_size = crashk_res.end - crashk_res.start + 1;
prom_add_property(node, crashk_size_prop);
I guess we use the reuse of the resources varables, but such is
common code vs userspace.
milton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
On Jul 8, 2010, at 5:49 AM, Benjamin Herrenschmidt wrote: On Thu, 2010-07-08 at 04:07 -0500, Milton Miller wrote: On Wed, 07 Jul 2010 around 10:51:20 - Matthew McClintock wrote: Fix sizes of variables so correct values are exported via /proc. Cast variable in comparison to avoid compiler error. I'm afraid I already pulled that in. Please send a fixup patch. Cheers, Ben. pulled into which tree? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 06/18] spufs: use llseek in all file operations
On Thursday 08 July 2010, Jeremy Kerr wrote:
@@ -2151,7 +2166,7 @@ static ssize_t spufs_ibox_info_read(struct file
*file, char __user *buf,
static const struct file_operations spufs_ibox_info_fops = {
.open = spufs_info_open,
.read = spufs_ibox_info_read,
- .llseek = generic_file_llseek,
+ .llseek = no_llseek,
};
static ssize_t __spufs_wbox_info_read(struct spu_context *ctx,
@@ -2194,7 +2209,7 @@ static ssize_t spufs_wbox_info_read(struct file
*file, char __user *buf,
static const struct file_operations spufs_wbox_info_fops = {
.open = spufs_info_open,
.read = spufs_wbox_info_read,
- .llseek = generic_file_llseek,
+ .llseek = no_llseek,
};
Why the change in behaviour for the mbox info files?
D'oh, that wasn't intentional. I guess what must have happened is that I first
added generic_file_llseek to all file_operations in spufs and then made up my
mind and chose what I thought was correct in each case, which broke these.
Of course, these *_info_fops should be seekable.
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] spufs: use llseek in all file operations
The default for llseek is changing, so we need
explicit operations everywhere.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Jeremy Kerr j...@ozlabs.org
Cc: linuxppc-...@ozlabs.org
---
Same as previous version, but no longer breaking the existing llseek
operation in spufs_*box_info_fops. Pushed out to my bkl/llseek branch.
diff --git a/arch/powerpc/platforms/cell/spufs/file.c
b/arch/powerpc/platforms/cell/spufs/file.c
index 1a40da9..02f7b11 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -154,6 +154,7 @@ static const struct file_operations __fops = {
\
.release = spufs_attr_release, \
.read= spufs_attr_read, \
.write = spufs_attr_write,\
+ .llseek = generic_file_llseek, \
};
@@ -521,6 +522,7 @@ static const struct file_operations spufs_cntl_fops = {
.release = spufs_cntl_release,
.read = simple_attr_read,
.write = simple_attr_write,
+ .llseek = generic_file_llseek,
.mmap = spufs_cntl_mmap,
};
@@ -714,6 +716,7 @@ static ssize_t spufs_mbox_read(struct file *file, char
__user *buf,
static const struct file_operations spufs_mbox_fops = {
.open = spufs_pipe_open,
.read = spufs_mbox_read,
+ .llseek = no_llseek,
};
static ssize_t spufs_mbox_stat_read(struct file *file, char __user *buf,
@@ -743,6 +746,7 @@ static ssize_t spufs_mbox_stat_read(struct file *file, char
__user *buf,
static const struct file_operations spufs_mbox_stat_fops = {
.open = spufs_pipe_open,
.read = spufs_mbox_stat_read,
+ .llseek = no_llseek,
};
/* low-level ibox access function */
@@ -863,6 +867,7 @@ static const struct file_operations spufs_ibox_fops = {
.read = spufs_ibox_read,
.poll = spufs_ibox_poll,
.fasync = spufs_ibox_fasync,
+ .llseek = no_llseek,
};
static ssize_t spufs_ibox_stat_read(struct file *file, char __user *buf,
@@ -890,6 +895,7 @@ static ssize_t spufs_ibox_stat_read(struct file *file, char
__user *buf,
static const struct file_operations spufs_ibox_stat_fops = {
.open = spufs_pipe_open,
.read = spufs_ibox_stat_read,
+ .llseek = no_llseek,
};
/* low-level mailbox write */
@@ -1011,6 +1017,7 @@ static const struct file_operations spufs_wbox_fops = {
.write = spufs_wbox_write,
.poll = spufs_wbox_poll,
.fasync = spufs_wbox_fasync,
+ .llseek = no_llseek,
};
static ssize_t spufs_wbox_stat_read(struct file *file, char __user *buf,
@@ -1038,6 +1045,7 @@ static ssize_t spufs_wbox_stat_read(struct file *file,
char __user *buf,
static const struct file_operations spufs_wbox_stat_fops = {
.open = spufs_pipe_open,
.read = spufs_wbox_stat_read,
+ .llseek = no_llseek,
};
static int spufs_signal1_open(struct inode *inode, struct file *file)
@@ -1166,6 +1174,7 @@ static const struct file_operations spufs_signal1_fops = {
.read = spufs_signal1_read,
.write = spufs_signal1_write,
.mmap = spufs_signal1_mmap,
+ .llseek = no_llseek,
};
static const struct file_operations spufs_signal1_nosched_fops = {
@@ -1173,6 +1182,7 @@ static const struct file_operations
spufs_signal1_nosched_fops = {
.release = spufs_signal1_release,
.write = spufs_signal1_write,
.mmap = spufs_signal1_mmap,
+ .llseek = no_llseek,
};
static int spufs_signal2_open(struct inode *inode, struct file *file)
@@ -1305,6 +1315,7 @@ static const struct file_operations spufs_signal2_fops = {
.read = spufs_signal2_read,
.write = spufs_signal2_write,
.mmap = spufs_signal2_mmap,
+ .llseek = no_llseek,
};
static const struct file_operations spufs_signal2_nosched_fops = {
@@ -1312,6 +1323,7 @@ static const struct file_operations
spufs_signal2_nosched_fops = {
.release = spufs_signal2_release,
.write = spufs_signal2_write,
.mmap = spufs_signal2_mmap,
+ .llseek = no_llseek,
};
/*
@@ -1451,6 +1463,7 @@ static const struct file_operations spufs_mss_fops = {
.open= spufs_mss_open,
.release = spufs_mss_release,
.mmap= spufs_mss_mmap,
+ .llseek = no_llseek,
};
static int
@@ -1508,6 +1521,7 @@ static const struct file_operations spufs_psmap_fops = {
.open= spufs_psmap_open,
.release = spufs_psmap_release,
.mmap= spufs_psmap_mmap,
+ .llseek = no_llseek,
};
@@ -1871,6 +1885,7 @@ static const struct file_operations spufs_mfc_fops = {
.fsync = spufs_mfc_fsync,
.fasync = spufs_mfc_fasync,
.mmap= spufs_mfc_mmap,
+ .llseek = no_llseek,
};
static int spufs_npc_set(void *data, u64 val)
@@ -2246,6 +2261,7 @@ static ssize_t
Re: [1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
On Thu, 2010-07-08 at 04:07 -0500, Milton Miller wrote:
On Wed, 07 Jul 2010 around 10:51:20 - Matthew McClintock wrote:
Fix sizes of variables so correct values are exported via /proc.
Cast variable in comparison to avoid compiler error.
Signed-off-by: Matthew McClintock m...@freescale.com
- csize = min(csize, PAGE_SIZE);
+ csize = min(csize, (size_t)PAGE_SIZE);
no use min_t
Ok
- if (pfn max_pfn) {
+ if ((min_low_pfn pfn) (pfn max_pfn)) {
vaddr = __va(pfn PAGE_SHIFT);
csize = copy_oldmem_vaddr(vaddr, buf, csize, offset, userbuf);
} else {
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index bb3d893..ec7f054 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -145,6 +145,7 @@ int overlaps_crashkernel(unsigned long start, unsigned
long size)
/* Values we need to export to the second kernel via the device tree. */
static unsigned long kernel_end;
+static unsigned long crashk_start;
static unsigned long crashk_size;
static struct property kernel_end_prop = {
@@ -156,7 +157,7 @@ static struct property kernel_end_prop = {
static struct property crashk_base_prop = {
.name = linux,crashkernel-base,
.length = sizeof(unsigned long),
- .value = crashk_res.start,
+ .value = crashk_start,
};
This is wrong, its truncating the start and size.
Change the variables to be physaddr_t and the length to be sizeof(physaddr_t).
Since these properites only contain one variable, the number of cells
can be inferred from the property size like we do for reading the initrd-size.
Technically they should be an array of be32 but we can make that a comment.
I don't disagree but this can break kexec if phys_addr_t != unsigned
long. Also, doesn't the crash kernel have to live below 2GB so unsigned
long is always fine?
Will still change unless I hear otherwise.
By the way, why does 32 bit care about the running kernel's size? aka
linux,kernel-end? 64 bit book 3S needs it because we use mmu hooks
to copy the pages to their destination, but I thought ppc32 was using
a relocatable copy routine. Are we missing the code to create
temp ref tlbs on the fly for book 3E?
This is not really in this patch or did I miss something? Kexec uses
kernel-end just to add as a invalid region. Not crucial though for 32
bit.
static struct property crashk_size_prop = {
@@ -180,6 +181,7 @@ static void __init export_crashk_values(struct
device_node *node)
prom_remove_property(node, prop);
if (crashk_res.start != 0) {
+ crashk_start = crashk_res.start;
prom_add_property(node, crashk_base_prop);
crashk_size = crashk_res.end - crashk_res.start + 1;
prom_add_property(node, crashk_size_prop);
I guess we use the reuse of the resources varables, but such is
common code vs userspace.
milton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
-Original Message- From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant Likely Sent: Thursday, July 08, 2010 12:38 AM To: Benjamin Herrenschmidt Cc: Steve Deiters; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx On Wed, Jul 7, 2010 at 11:10 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2010-06-29 at 11:04 -0500, Steve Deiters wrote: These processors will corrupt data if accessing the local bus with unaligned addresses. This version fixes the typical case of copying from Flash on the local bus by keeping the source address always aligned. Shouldn't this be solved by using memcpy_to/fromio ? Maybe. plain memcpy() access to anything localbus-attached on the mpc5xxx is the wrong thing to do. memcpy_to/fromio might do the right thing; but the caller must understand the limitations of the localplus bus. The byte-wise alignment that memcpy_to/fromio() does may not work (depending on configuration). Steve, what code is doing a memcpy from flash? g. This was done in the JFFS2 code, in fs/jffs2/scan.c. At least in one function, in jffs2_scan_dirent_node it was using memcpy on a localbus mapped structure. I was getting JFFS2 filesystem corruption because of this. In fact I first tried changing this to memcpy_fromio and it fixed that particular problem. I was concerned though that other places I was not aware of might be using memcpy from the localbus in a similar manner so I decided to just tweak the memcpy routine. Just out of curiousity, what configuration might cause a byte-wise alignment not to work? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
HDLC driver for MPC885
Hello, I'm looking for an HDLC driver for the SCCs in MPC885 CPM. Does anybody know where I could find such a driver for kernel 2.6.xx ? Best regards Christophe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
405EX Rev D mis-identification?
It looks like the Rev D version of the 405EX chip without security will be identified as a 405EXr, based on the values in the cpu_specs table. For 405EX/405EXr the pvr_mask is 0x0004 with the pvr_value's as 0x12910004 and 0x1291 respectively. I see that the Rev D PVR value for the 405EX without security is 0x12911473, which would mask out to the EXr value. Is there an algorithm update needed or am I missing something? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
On Thu, Jul 8, 2010 at 8:38 AM, Steve Deiters stevedeit...@basler.com wrote: -Original Message- From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant Likely Sent: Thursday, July 08, 2010 12:38 AM To: Benjamin Herrenschmidt Cc: Steve Deiters; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx On Wed, Jul 7, 2010 at 11:10 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2010-06-29 at 11:04 -0500, Steve Deiters wrote: These processors will corrupt data if accessing the local bus with unaligned addresses. This version fixes the typical case of copying from Flash on the local bus by keeping the source address always aligned. Shouldn't this be solved by using memcpy_to/fromio ? Maybe. plain memcpy() access to anything localbus-attached on the mpc5xxx is the wrong thing to do. memcpy_to/fromio might do the right thing; but the caller must understand the limitations of the localplus bus. The byte-wise alignment that memcpy_to/fromio() does may not work (depending on configuration). Steve, what code is doing a memcpy from flash? g. This was done in the JFFS2 code, in fs/jffs2/scan.c. At least in one function, in jffs2_scan_dirent_node it was using memcpy on a localbus mapped structure. I was getting JFFS2 filesystem corruption because of this. In fact I first tried changing this to memcpy_fromio and it fixed that particular problem. I was concerned though that other places I was not aware of might be using memcpy from the localbus in a similar manner so I decided to just tweak the memcpy routine. [cc'ing David Woodhouse] Sounds to me like the right thing to do is to fix the jffs2 code. Just out of curiousity, what configuration might cause a byte-wise alignment not to work? Can't remember the register configuration, but I worked on one project where this was the case. In hindsight, it was probably a mis-configuration of the localbus CS for the particular device. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 405EX Rev D mis-identification?
On Thu, Jul 8, 2010 at 10:06, Marc Chidester marcchides...@gmail.com wrote: It looks like the Rev D version of the 405EX chip without security will be identified as a 405EXr, based on the values in the cpu_specs table. For 405EX/405EXr the pvr_mask is 0x0004 with the pvr_value's as 0x12910004 and 0x1291 respectively. I see that the Rev D PVR value for the 405EX without security is 0x12911473, which would mask out to the EXr value. Is there an algorithm update needed or am I missing something? With 405EX Rev D, we have noticed that we must reset our board one time after the initial powerup to make the PVR read correctly. See this post: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 2.6.34: arch/powerpc/sysdev/micropatch.c not compiling
On Tue, Jul 06, 2010 at 10:03:43AM +1000, Tony Breeds wrote: On Mon, Jul 05, 2010 at 09:45:11AM +0200, LEROY Christophe wrote: When activating micropatch option, the kernel does not compile. powerpc problems should alos CC linuxppc-dev. It looks like a spi_t is not defined anywhere. CC arch/powerpc/sysdev/micropatch.o arch/powerpc/sysdev/micropatch.c: In function ‘cpm_load_patch’: arch/powerpc/sysdev/micropatch.c:629: erreur: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token [...] - spp = (spi_t *)commproc-cp_dparam[PROFF_SPI]; - spp-spi_rpbase = i; + smp = (smc_uart_t *)commproc-cp_dparam[PROFF_SPI]; + smp-smc_rpbase = i; # if defined(CONFIG_I2C_SPI_UCODE_PATCH) commproc-cp_cpmcr1 = 0x802a; Would help? While this will fix the issue, I think this is not technically correct (i.e. micropatching SPI controller via I2C pram struct, even though the structs appear to be identical). As the spi_param is needed outside of the SPI driver, we'd better re-introduce the struct, I think. I'll send some fixes for this and other issues in this file. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] powerpc/cpm: Reintroduce global spi_pram struct (fixes build issue)
spi_t was removed in commit 644b2a680ccc51a9ec4d6beb12e9d47d2dee98e2
(powerpc/cpm: Remove SPI defines and spi structs), the commit assumed
that spi_t isn't used anywhere outside of the spi_mpc8xxx driver. But
it appears that the struct is needed for micropatch code. So, let's
reintroduce the struct.
Fixes the following build issue:
CC arch/powerpc/sysdev/micropatch.o
micropatch.c: In function 'cpm_load_patch':
micropatch.c:629: error: expected '=', ',', ';', 'asm' or '__attribute__'
before '*' token
micropatch.c:629: error: 'spp' undeclared (first use in this function)
micropatch.c:629: error: (Each undeclared identifier is reported only once
micropatch.c:629: error: for each function it appears in.)
Reported-by: LEROY Christophe christophe.le...@c-s.fr
Reported-by: Tony Breeds t...@bakeyournoodle.com
Cc: sta...@kernel.org [ .33, .34 ]
Signed-off-by: Anton Vorontsov avoront...@mvista.com
---
arch/powerpc/include/asm/cpm.h | 24
arch/powerpc/sysdev/micropatch.c |7 ---
drivers/spi/spi_mpc8xxx.c| 22 --
3 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/include/asm/cpm.h b/arch/powerpc/include/asm/cpm.h
index 0835eb9..e50323f 100644
--- a/arch/powerpc/include/asm/cpm.h
+++ b/arch/powerpc/include/asm/cpm.h
@@ -7,6 +7,30 @@
#include linux/of.h
/*
+ * SPI Parameter RAM common to QE and CPM.
+ */
+struct spi_pram {
+ __be16 rbase; /* Rx Buffer descriptor base address */
+ __be16 tbase; /* Tx Buffer descriptor base address */
+ u8 rfcr; /* Rx function code */
+ u8 tfcr; /* Tx function code */
+ __be16 mrblr; /* Max receive buffer length */
+ __be32 rstate; /* Internal */
+ __be32 rdp;/* Internal */
+ __be16 rbptr; /* Internal */
+ __be16 rbc;/* Internal */
+ __be32 rxtmp; /* Internal */
+ __be32 tstate; /* Internal */
+ __be32 tdp;/* Internal */
+ __be16 tbptr; /* Internal */
+ __be16 tbc;/* Internal */
+ __be32 txtmp; /* Internal */
+ __be32 res;/* Tx temp. */
+ __be16 rpbase; /* Relocation pointer (CPM1 only) */
+ __be16 res1; /* Reserved */
+};
+
+/*
* USB Controller pram common to QE and CPM.
*/
struct usb_ctlr {
diff --git a/arch/powerpc/sysdev/micropatch.c b/arch/powerpc/sysdev/micropatch.c
index d8d6028..18080f3 100644
--- a/arch/powerpc/sysdev/micropatch.c
+++ b/arch/powerpc/sysdev/micropatch.c
@@ -16,6 +16,7 @@
#include asm/page.h
#include asm/pgtable.h
#include asm/8xx_immap.h
+#include asm/cpm.h
#include asm/cpm1.h
/*
@@ -626,7 +627,7 @@ cpm_load_patch(cpm8xx_t *cp)
volatile uint *dp;/* Dual-ported RAM. */
volatile cpm8xx_t *commproc;
volatile iic_t *iip;
- volatile spi_t *spp;
+ volatile struct spi_pram *spp;
volatile smc_uart_t *smp;
int i;
@@ -668,8 +669,8 @@ cpm_load_patch(cpm8xx_t *cp)
/* Put SPI above the IIC, also 32-byte aligned.
*/
i = (RPBASE + sizeof(iic_t) + 31) ~31;
- spp = (spi_t *)commproc-cp_dparam[PROFF_SPI];
- spp-spi_rpbase = i;
+ spp = (struct spi_pram *)commproc-cp_dparam[PROFF_SPI];
+ spp-rpbase = i;
# if defined(CONFIG_I2C_SPI_UCODE_PATCH)
commproc-cp_cpmcr1 = 0x802a;
diff --git a/drivers/spi/spi_mpc8xxx.c b/drivers/spi/spi_mpc8xxx.c
index ffa111a..97ab0a8 100644
--- a/drivers/spi/spi_mpc8xxx.c
+++ b/drivers/spi/spi_mpc8xxx.c
@@ -66,28 +66,6 @@ struct mpc8xxx_spi_reg {
__be32 receive;
};
-/* SPI Parameter RAM */
-struct spi_pram {
- __be16 rbase; /* Rx Buffer descriptor base address */
- __be16 tbase; /* Tx Buffer descriptor base address */
- u8 rfcr; /* Rx function code */
- u8 tfcr; /* Tx function code */
- __be16 mrblr; /* Max receive buffer length */
- __be32 rstate; /* Internal */
- __be32 rdp;/* Internal */
- __be16 rbptr; /* Internal */
- __be16 rbc;/* Internal */
- __be32 rxtmp; /* Internal */
- __be32 tstate; /* Internal */
- __be32 tdp;/* Internal */
- __be16 tbptr; /* Internal */
- __be16 tbc;/* Internal */
- __be32 txtmp; /* Internal */
- __be32 res;/* Tx temp. */
- __be16 rpbase; /* Relocation pointer (CPM1 only) */
- __be16 res1; /* Reserved */
-};
-
/* SPI Controller mode register definitions */
#defineSPMODE_LOOP (1 30)
#defineSPMODE_CI_INACTIVEHIGH (1 29)
--
1.7.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] powerpc/cpm1: Fix build with various CONFIG_*_UCODE_PATCH combinations
Warnings are treated as errors for arch/powerpc code, so build fails
with CONFIG_I2C_SPI_UCODE_PATCH=y:
CC arch/powerpc/sysdev/micropatch.o
cc1: warnings being treated as errors
arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch':
arch/powerpc/sysdev/micropatch.c:630: warning: unused variable 'smp'
make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1
And with CONFIG_USB_SOF_UCODE_PATCH=y:
CC arch/powerpc/sysdev/micropatch.o
cc1: warnings being treated as errors
arch/powerpc/sysdev/micropatch.c: In function 'cpm_load_patch':
arch/powerpc/sysdev/micropatch.c:629: warning: unused variable 'spp'
arch/powerpc/sysdev/micropatch.c:628: warning: unused variable 'iip'
make[1]: *** [arch/powerpc/sysdev/micropatch.o] Error 1
This patch fixes these issues by introducing proper #ifdefs.
Cc: sta...@kernel.org [ .33, .34 ]
Signed-off-by: Anton Vorontsov avoront...@mvista.com
---
arch/powerpc/sysdev/micropatch.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/micropatch.c b/arch/powerpc/sysdev/micropatch.c
index 18080f3..6c56ae9 100644
--- a/arch/powerpc/sysdev/micropatch.c
+++ b/arch/powerpc/sysdev/micropatch.c
@@ -626,9 +626,14 @@ cpm_load_patch(cpm8xx_t*cp)
{
volatile uint *dp;/* Dual-ported RAM. */
volatile cpm8xx_t *commproc;
+#if defined(CONFIG_I2C_SPI_UCODE_PATCH) || \
+defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
volatile iic_t *iip;
volatile struct spi_pram *spp;
+#ifdef CONFIG_I2C_SPI_SMC1_UCODE_PATCH
volatile smc_uart_t *smp;
+#endif
+#endif
int i;
commproc = cp;
--
1.7.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] powerpc/cpm1: Mark micropatch code/data static and __init
This saves runtime memory and fixes lots of sparse warnings like this:
CHECK arch/powerpc/sysdev/micropatch.c
arch/powerpc/sysdev/micropatch.c:27:6: warning: symbol 'patch_2000'
was not declared. Should it be static?
arch/powerpc/sysdev/micropatch.c:146:6: warning: symbol 'patch_2f00'
was not declared. Should it be static?
...
Signed-off-by: Anton Vorontsov avoront...@mvista.com
---
arch/powerpc/include/asm/cpm1.h |3 ++-
arch/powerpc/sysdev/micropatch.c | 18 +-
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/cpm1.h b/arch/powerpc/include/asm/cpm1.h
index 81b0119..bd07650 100644
--- a/arch/powerpc/include/asm/cpm1.h
+++ b/arch/powerpc/include/asm/cpm1.h
@@ -17,6 +17,7 @@
#ifndef __CPM1__
#define __CPM1__
+#include linux/init.h
#include asm/8xx_immap.h
#include asm/ptrace.h
#include asm/cpm.h
@@ -54,7 +55,7 @@ extern cpm8xx_t __iomem *cpmp; /* Pointer to comm processor */
extern void cpm_setbrg(uint brg, uint rate);
-extern void cpm_load_patch(cpm8xx_t *cp);
+extern void __init cpm_load_patch(cpm8xx_t *cp);
extern void cpm_reset(void);
diff --git a/arch/powerpc/sysdev/micropatch.c b/arch/powerpc/sysdev/micropatch.c
index 6c56ae9..c0bb76e 100644
--- a/arch/powerpc/sysdev/micropatch.c
+++ b/arch/powerpc/sysdev/micropatch.c
@@ -4,6 +4,7 @@
* also relocates SMC2, but this would require additional changes
* to uart.c, so I am holding off on that for a moment.
*/
+#include linux/init.h
#include linux/errno.h
#include linux/sched.h
#include linux/kernel.h
@@ -25,7 +26,7 @@
#ifdef CONFIG_I2C_SPI_UCODE_PATCH
-uint patch_2000[] = {
+static uint patch_2000[] __initdata = {
0x7FFFEFD9,
0x3FFD,
0x7FFB49F7,
@@ -144,7 +145,7 @@ uint patch_2000[] = {
0x5F8247F8
};
-uint patch_2f00[] = {
+static uint patch_2f00[] __initdata = {
0x3E303430,
0x34343737,
0xABF7BF9B,
@@ -183,7 +184,7 @@ uint patch_2f00[] = {
#ifdef CONFIG_I2C_SPI_SMC1_UCODE_PATCH
-uint patch_2000[] = {
+static uint patch_2000[] __initdata = {
0x3fff,
0x3ffd,
0x3ffb,
@@ -506,7 +507,7 @@ uint patch_2000[] = {
0x6079e2bb
};
-uint patch_2f00[] = {
+static uint patch_2f00[] __initdata = {
0x30303030,
0x3e3e3434,
0xabbf9b99,
@@ -573,7 +574,7 @@ uint patch_2f00[] = {
0xf22f3f23
};
-uint patch_2e00[] = {
+static uint patch_2e00[] __initdata = {
0x27ee,
0x,
0x,
@@ -599,7 +600,7 @@ uint patch_2e00[] = {
#ifdef CONFIG_USB_SOF_UCODE_PATCH
-uint patch_2000[] = {
+static uint patch_2000[] __initdata = {
0x7fff,
0x7ffd,
0x7ffb,
@@ -614,15 +615,14 @@ uint patch_2000[] = {
0x6075
};
-uint patch_2f00[] = {
+static uint patch_2f00[] __initdata = {
0x3030304c,
0xcab9e441,
0xa1aaf220
};
#endif
-void
-cpm_load_patch(cpm8xx_t*cp)
+void __init cpm_load_patch(cpm8xx_t *cp)
{
volatile uint *dp;/* Dual-ported RAM. */
volatile cpm8xx_t *commproc;
--
1.7.0.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 405EX Rev D mis-identification?
On Thu, Jul 8, 2010 at 10:06, Marc Chidester marcchides...@gmail.com wrote: It looks like the Rev D version of the 405EX chip without security will be identified as a 405EXr, based on the values in the cpu_specs table. Yes, that is the case. The 405EX Rev D without security PVR matches an old 405EXr A/B with security, and hence the cpu_spec entries' pvr_mask values are no longer correct. Is there an algorithm update needed or am I missing something? Perhaps add more cpu_spec table entries for the 405EX 405EXr with pvr_mask = 0x000f ? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 405EX Rev D mis-identification?
On Thu, Jul 08, 2010 at 12:59:29PM -0500, Lee Nipper wrote: On Thu, Jul 8, 2010 at 10:06, Marc Chidester marcchides...@gmail.com wrote: It looks like the Rev D version of the 405EX chip without security will be identified as a 405EXr, based on the values in the cpu_specs table. Yes, that is the case. The 405EX Rev D without security PVR matches an old 405EXr A/B with security, and hence the cpu_spec entries' pvr_mask values are no longer correct. Is there an algorithm update needed or am I missing something? Perhaps add more cpu_spec table entries for the 405EX 405EXr with pvr_mask = 0x000f ? Have you tried that in a locally modified kernel? If so, did it work? If so, care to submit a patch? :) josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 405EX Rev D mis-identification?
On Thu, Jul 08, 2010 at 11:01:11AM -0500, Lee Nipper wrote: On Thu, Jul 8, 2010 at 10:06, Marc Chidester marcchides...@gmail.com wrote: It looks like the Rev D version of the 405EX chip without security will be identified as a 405EXr, based on the values in the cpu_specs table. For 405EX/405EXr the pvr_mask is 0x0004 with the pvr_value's as 0x12910004 and 0x1291 respectively. I see that the Rev D PVR value for the 405EX without security is 0x12911473, which would mask out to the EXr value. Is there an algorithm update needed or am I missing something? With 405EX Rev D, we have noticed that we must reset our board one time after the initial powerup to make the PVR read correctly. See this post: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html That is very very weird. Have you seen that behavior on multiple Rev D CPUs or just one board or? The PVR value should never change, so if you have odd behavior I wonder if the are silicon bugs in that revision. Did you happen to ask AMCC about it? josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
Am 08.07.10 17:22 schrieb(en) Grant Likely: Just out of curiousity, what configuration might cause a byte-wise alignment not to work? Can't remember the register configuration, but I worked on one project where this was the case. In hindsight, it was probably a mis-configuration of the localbus CS for the particular device. Not sure if you're thinking of this configuration, but if you attach a device in 16-bit mode (i.e. 16 data lines) to the LPB, byte writes simply don't work. I ran into that problem as I have a nvram attached this way to a 5200b. Using the device as mtd-ram with a jffs2 file system on it I also sometimes saw corruption after a write. I had a patch for that last year, but it was actually badly crafted (see http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072903.html). I still use the mpc52xx_memcpy2lpb16() function somewhere in my current code which is actually an ugly hack (but it works...). Actually, this is something which might need closer attention - and maybe some support in the device tree indicating which read or write width a device can accept? Best, Albrecht. pgpQDQ2The7jf.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 405EX Rev D mis-identification?
On Thu, Jul 8, 2010 at 13:24, Josh Boyer jwbo...@linux.vnet.ibm.com wrote: On Thu, Jul 08, 2010 at 11:01:11AM -0500, Lee Nipper wrote: On Thu, Jul 8, 2010 at 10:06, Marc Chidester marcchides...@gmail.com wrote: It looks like the Rev D version of the 405EX chip without security will be identified as a 405EXr, based on the values in the cpu_specs table. For 405EX/405EXr the pvr_mask is 0x0004 with the pvr_value's as 0x12910004 and 0x1291 respectively. I see that the Rev D PVR value for the 405EX without security is 0x12911473, which would mask out to the EXr value. Is there an algorithm update needed or am I missing something? With 405EX Rev D, we have noticed that we must reset our board one time after the initial powerup to make the PVR read correctly. See this post: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html That is very very weird. Have you seen that behavior on multiple Rev D CPUs or just one board or? Multiple Rev D CPUs. In fact, ALL of the samples we obtained behave this way. The PVR value should never change, so if you have odd behavior I wonder if the are silicon bugs in that revision. Did you happen to ask AMCC about it? Yes, I did. AMCC suggested doing an early one-time s/w reset to make the PVR read correctly afterwards. Since we only support one specific 405EX variety, we could do that. However, on a generic u-boot, there is no way to know if a correct PVR is read, so that approach is not a solution. I'm wondering if our power on reset circuitry is not entirely correct, and it showed up with the Rev D part. I received no comments on my original post from other users of the 405EX, so I'm thinking it is a possible explanation. Does anyone have a board with a 405EX Rev D ? If so, does the PVR value match your processor chip after power up ? Lee ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 405EX Rev D mis-identification?
On Thu, Jul 8, 2010 at 13:22, Josh Boyer jwbo...@linux.vnet.ibm.com wrote: On Thu, Jul 08, 2010 at 12:59:29PM -0500, Lee Nipper wrote: On Thu, Jul 8, 2010 at 10:06, Marc Chidester marcchides...@gmail.com wrote: Is there an algorithm update needed or am I missing something? Perhaps add more cpu_spec table entries for the 405EX 405EXr with pvr_mask = 0x000f ? Have you tried that in a locally modified kernel? If so, did it work? If so, care to submit a patch? :) I have not yet. I will prepare a patch. Lee ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
Actually, this is something which might need closer attention - and maybe some support in the device tree indicating which read or write width a device can accept? There already is device-width; the drivers never should use any other access width unless they *know* that will work. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 405EX Rev D mis-identification?
On Thu, Jul 8, 2010 at 2:24 PM, Josh Boyer jwbo...@linux.vnet.ibm.com wrote: On Thu, Jul 08, 2010 at 11:01:11AM -0500, Lee Nipper wrote: On Thu, Jul 8, 2010 at 10:06, Marc Chidester marcchides...@gmail.com wrote: It looks like the Rev D version of the 405EX chip without security will be identified as a 405EXr, based on the values in the cpu_specs table. For 405EX/405EXr the pvr_mask is 0x0004 with the pvr_value's as 0x12910004 and 0x1291 respectively. I see that the Rev D PVR value for the 405EX without security is 0x12911473, which would mask out to the EXr value. Is there an algorithm update needed or am I missing something? With 405EX Rev D, we have noticed that we must reset our board one time after the initial powerup to make the PVR read correctly. See this post: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/079099.html That is very very weird. Have you seen that behavior on multiple Rev D CPUs or just one board or? The PVR value should never change, so if you have odd behavior I wonder if the are silicon bugs in that revision. Did you happen to ask AMCC about it? josh Check the recent Errata for the chip on this issue. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
On Thu, 8 Jul 2010 21:30:33 +0200 Segher Boessenkool seg...@kernel.crashing.org wrote: Actually, this is something which might need closer attention - and maybe some support in the device tree indicating which read or write width a device can accept? There already is device-width; the drivers never should use any other access width unless they *know* that will work. Wouldn't you want to use bank-width instead? device-width might not even work if, say, you've got two 8-bit chips interleaved, feeding into a bus controller in 16-bit mode that only accepts 16-bit accesses. It would be nice to have a device tree property that can specify that all access widths supported by the CPU will work, though. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx
Am 08.07.10 21:30 schrieb(en) Segher Boessenkool: Actually, this is something which might need closer attention - and maybe some support in the device tree indicating which read or write width a device can accept? There already is device-width; the drivers never should use any other access width unless they *know* that will work. Hmm, unfortunately, it's usage is not clearly documented in mtd-physmap.txt, so I never thought of this parameter. And IMHO the problem goes further - basically *any* chip which is attached to the LPB can be affected by this problem, so it might be better to have a more general approach like a chip select property. Cheers, Albrecht. pgpyhtduU1Hps.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] mpc8308rdb: support for MPC8308RDB board from Freescale
This patch adds support for MPC8308RDB development board from
Freescale.
Supported devices:
DUART
Dual Ethernet
NOR and NAND flashes
I2C
USB in peripheral mode
PCIE support is broken by the commit 3da34aa (powerpc/fsl: Support
unique MSI addresses per PCIe Root Complex). Works after revert.
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
arch/powerpc/boot/dts/mpc8308rdb.dts | 303 +
arch/powerpc/platforms/83xx/Kconfig |8 +
arch/powerpc/platforms/83xx/Makefile |1 +
arch/powerpc/platforms/83xx/mpc830x_rdb.c | 94 +
4 files changed, 406 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8308rdb.dts
create mode 100644 arch/powerpc/platforms/83xx/mpc830x_rdb.c
diff --git a/arch/powerpc/boot/dts/mpc8308rdb.dts
b/arch/powerpc/boot/dts/mpc8308rdb.dts
new file mode 100644
index 000..a97eb2d
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8308rdb.dts
@@ -0,0 +1,303 @@
+/*
+ * MPC8308RDB Device Tree Source
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ * Copyright 2010 Ilya Yanok, Emcraft Systems, ya...@emcraft.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ compatible = fsl,mpc8308rdb;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,8...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ d-cache-size = 16384;
+ i-cache-size = 16384;
+ timebase-frequency = 0; // from bootloader
+ bus-frequency = 0;// from bootloader
+ clock-frequency = 0; // from bootloader
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x0800; // 128MB at 0
+ };
+
+ local...@e0005000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,mpc8315-elbc, fsl,elbc, simple-bus;
+ reg = 0xe0005000 0x1000;
+ interrupts = 77 0x8;
+ interrupt-parent = ipic;
+
+ // CS0 and CS1 are swapped when
+ // booting from nand, but the
+ // addresses are the same.
+ ranges = 0x0 0x0 0xfe00 0x0080
+ 0x1 0x0 0xe060 0x2000
+ 0x2 0x0 0xf000 0x0002
+ 0x3 0x0 0xfa00 0x8000;
+
+ fl...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x80;
+ bank-width = 2;
+ device-width = 1;
+
+ u-b...@0 {
+ reg = 0x0 0x6;
+ read-only;
+ };
+ e...@6 {
+ reg = 0x6 0x1;
+ };
+ e...@7 {
+ reg = 0x7 0x1;
+ };
+ ker...@8 {
+ reg = 0x8 0x20;
+ };
+ d...@28 {
+ reg = 0x28 0x1;
+ };
+ ramd...@29 {
+ reg = 0x29 0x57;
+ };
+ };
+
+ n...@1,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc8315-fcm-nand,
+fsl,elbc-fcm-nand;
+ reg = 0x1 0x0 0x2000;
+
+ jf...@0 {
+ reg = 0x0 0x200;
+ };
+ };
+ };
+
+ i...@e000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ compatible = fsl,mpc8315-immr, simple-bus;
+ ranges = 0 0xe000 0x0010;
+ reg = 0xe000 0x0200;
+ bus-frequency = 0;
+
+ i...@3000 {
+
Commit 3da34aa brakes MSI support on MPC8308 (possibly all MPC83xx)
Hi Kumar, All, I've found that MSI work correctly with older kernels on my MPC8308RDB board and don't work with newer ones. After bisecting I've found that the source of the problem is commit 3da34aa: commit 3da34aae03d498ee62f75aa7467de93cce3030fd Author: Kumar Gala ga...@kernel.crashing.org Date: Tue May 12 15:51:56 2009 -0500 powerpc/fsl: Support unique MSI addresses per PCIe Root Complex Its feasible based on how the PCI address map is setup that the region of PCI address space used for MSIs differs for each PHB on the same SoC. Instead of assuming that the address mappes to CCSRBAR 1:1 we read PEXCSRBAR (BAR0) for the PHB that the given pci_dev is on. Signed-off-by: Kumar Gala ga...@kernel.crashing.org I can see BAR0 initialization for 85xx/86xx hardware but not for 83xx neigher in the kernel nor in U-Boot (that makes me think that all 83xx can be affected). I'm not actually an PCI expert so I've just tried to write IMMR base address to the BAR0 register from the U-Boot to get the correct address but this doesn't help. Please direct me how to init 83xx PCIE controller to make it compatible with this patch. Thanks in advance. Regards, Ilya. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
On Thu, 08 Jul 2010 around 09:27:15 -0500 Matthew McClintock wrote:
On Thu, 2010-07-08 at 04:07 -0500, Milton Miller wrote:
On Wed, 07 Jul 2010 around 10:51:20 - Matthew McClintock wrote:
...
Fix sizes of variables so correct values are exported via /proc.
Cast variable in comparison to avoid compiler error.
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index bb3d893..ec7f054 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -145,6 +145,7 @@ int overlaps_crashkernel(unsigned long start,
unsigned long size)
/* Values we need to export to the second kernel via the device tree. */
static unsigned long kernel_end;
+static unsigned long crashk_start;
static unsigned long crashk_size;
static struct property kernel_end_prop = {
@@ -156,7 +157,7 @@ static struct property kernel_end_prop = {
static struct property crashk_base_prop = {
.name = linux,crashkernel-base,
.length = sizeof(unsigned long),
- .value = crashk_res.start,
+ .value = crashk_start,
};
This is wrong, its truncating the start and size.
Change the variables to be physaddr_t and the length to be
sizeof(physaddr_t).
Since these properites only contain one variable, the number of cells
can be inferred from the property size like we do for reading the
initrd-size.
Technically they should be an array of be32 but we can make that a comment.
I don't disagree but this can break kexec if phys_addr_t != unsigned
long. Also, doesn't the crash kernel have to live below 2GB so unsigned
long is always fine?
Its could only break kexec for the case of phys_addr_t != unsigned long
which you are fixing, and its the right way to fix it. There is nothing
inherent in linux requiring the crash kernel to be below 2G, although
there may be limitations of the current kernel that require such a limit.
Will still change unless I hear otherwise.
By the way, why does 32 bit care about the running kernel's size? aka
linux,kernel-end? 64 bit book 3S needs it because we use mmu hooks
to copy the pages to their destination, but I thought ppc32 was using
a relocatable copy routine. Are we missing the code to create
temp ref tlbs on the fly for book 3E?
This is not really in this patch or did I miss something? Kexec uses
kernel-end just to add as a invalid region. Not crucial though for 32
bit.
No its not in this patch, hence By the way. I figured you might have
some knowledge as you were working in this area. If there is no reason
to have the kernel region blocked for 32 bit, then it should be removed.
Obviously from kexec-tools first, and then after some time we could move
its export to be only for 64-bit (or only 64 bit book-3S?)
It only causes additional time for traditional, and memory fragmentation
for book 3E, if you disallow memory below the current kernel end. For
that matter, on 3E, does this limit creep as you repeatedly reboot?
milton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2] Support for MPC8308RDB development board
These two patches add support for MPC8308RDB development board from Freescale. Supported hardware: DUART Dual Ethernet NOR and NAND flashes I2C USB device PCIE (MSI support is broken by commit 3da34aa) Signed-off-by: Ilya Yanok ya...@emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] fsl_pci: add quirk for mpc8308 pcie bridge
This patch adds the quirk for PCIE controller found on Freescale MPC8308. The quirk is the same as for other MPC83xx processors. Signed-off-by: Ilya Yanok ya...@emcraft.com --- arch/powerpc/sysdev/fsl_pci.c |1 + include/linux/pci_ids.h |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c index a14760f..7e900ec 100644 --- a/arch/powerpc/sysdev/fsl_pci.c +++ b/arch/powerpc/sysdev/fsl_pci.c @@ -412,6 +412,7 @@ DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_P4080, quirk_fsl_pcie_header); #endif /* CONFIG_FSL_SOC_BOOKE || CONFIG_PPC_86xx */ #if defined(CONFIG_PPC_83xx) || defined(CONFIG_PPC_MPC512x) +DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8308, quirk_fsl_pcie_header); DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8314E, quirk_fsl_pcie_header); DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8314, quirk_fsl_pcie_header); DECLARE_PCI_FIXUP_HEADER(0x1957, PCI_DEVICE_ID_MPC8315E, quirk_fsl_pcie_header); diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 3bedcc1..79bb11f 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2264,6 +2264,7 @@ #define PCI_DEVICE_ID_TDI_EHCI 0x0101 #define PCI_VENDOR_ID_FREESCALE0x1957 +#define PCI_DEVICE_ID_MPC8308 0xc006 #define PCI_DEVICE_ID_MPC8315E 0x00b4 #define PCI_DEVICE_ID_MPC8315 0x00b5 #define PCI_DEVICE_ID_MPC8314E 0x00b6 -- 1.6.2.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
On Fri, 2010-07-09 at 15:18 -0500, Milton Miller wrote: I don't disagree but this can break kexec if phys_addr_t != unsigned long. Also, doesn't the crash kernel have to live below 2GB so unsigned long is always fine? Its could only break kexec for the case of phys_addr_t != unsigned long which you are fixing, and its the right way to fix it. There is nothing inherent in linux requiring the crash kernel to be below 2G, although there may be limitations of the current kernel that require such a limit. Fair enough. This will be updated in the next patch. Will still change unless I hear otherwise. By the way, why does 32 bit care about the running kernel's size? aka linux,kernel-end? 64 bit book 3S needs it because we use mmu hooks to copy the pages to their destination, but I thought ppc32 was using a relocatable copy routine. Are we missing the code to create temp ref tlbs on the fly for book 3E? This is not really in this patch or did I miss something? Kexec uses kernel-end just to add as a invalid region. Not crucial though for 32 bit. No its not in this patch, hence By the way. I figured you might have some knowledge as you were working in this area. If there is no reason to have the kernel region blocked for 32 bit, then it should be removed. Obviously from kexec-tools first, and then after some time we could move its export to be only for 64-bit (or only 64 bit book-3S?) As far as I can tell it's just used as an exclusion range. It's only applicable for a crash kernel to make sure your crashkernel=...@xxm does not overlap with the current kernel. Seems like it might not be needed. It only causes additional time for traditional, and memory fragmentation for book 3E, if you disallow memory below the current kernel end. For that matter, on 3E, does this limit creep as you repeatedly reboot? For a crash kernel it does not matter as you stick with the reserved region. For kexec proper the current kexec HEAD disallows loading from 0x0-kernelend but I think that is wrong and needs to be modified for at least some platforms. So, basically you can't load too the currently running kernel address, and you can't even restart but I have not tried a different address. I submitted a patch a while back to change that behavior for kexec-uImage targets and have more working coming soon which will need to be reviewed as well for kexec-elf targets. -Matthew ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
On Thu, 2010-07-08 at 07:40 -0500, Kumar Gala wrote: On Jul 8, 2010, at 5:49 AM, Benjamin Herrenschmidt wrote: On Thu, 2010-07-08 at 04:07 -0500, Milton Miller wrote: On Wed, 07 Jul 2010 around 10:51:20 - Matthew McClintock wrote: Fix sizes of variables so correct values are exported via /proc. Cast variable in comparison to avoid compiler error. I'm afraid I already pulled that in. Please send a fixup patch. pulled into which tree? My confusion. It was in my to-be-posted -next but I hadn't actually uploaded it yet so I've dropped the patch for now. Matthew, don't send an incremental fixup, a whole new patch will do. I've also dropped the second patch that enables building of crash dump kernels for now. I've left the MPIC CPU reset one though. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/27] KVM PPC PV framework
On Thu, Jul 1, 2010 at 4:12 PM, Alexander Graf ag...@suse.de wrote:
On PPC we run PR=0 (kernel mode) code in PR=1 (user mode) and don't use the
hypervisor extensions.
While that is all great to show that virtualization is possible, there are
quite some cases where the emulation overhead of privileged instructions is
killing performance.
This patchset tackles exactly that issue. It introduces a paravirtual
framework
using which KVM and Linux share a page to exchange register state with. That
KVM and Linux or KVM and GuestOS ?
way we don't have to switch to the hypervisor just to change a value of a
privileged register.
To prove my point, I ran the same test I did for the MMU optimizations against
the PV framework. Here are the results:
[without]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello /dev/null;
done
real 0m14.659s
user 0m8.967s
sys 0m5.688s
[with]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello /dev/null;
done
real 0m7.557s
user 0m4.121s
sys 0m3.426s
So this is a significant performance improvement! I'm quite happy how fast
this
whole thing becomes :)
I tried to take all comments I've heard from people so far about such a PV
framework into account. In case you told me something before that is a no-go
and I still did it, please just tell me again.
Now go and have fun with fast VMs on PPC! Get yourself a G5 on ebay and start
experiencing the power yourself. - heh
v1 - v2:
- change hypervisor calls to use r0 and r3
- make crit detection only trigger in supervisor mode
- RMO - PAM
- introduce kvm_patch_ins
- only flush icache when patching
- introduce kvm_patch_ins_b
- update documentation
Alexander Graf (27):
KVM: PPC: Introduce shared page
KVM: PPC: Convert MSR to shared page
KVM: PPC: Convert DSISR to shared page
KVM: PPC: Convert DAR to shared page.
KVM: PPC: Convert SRR0 and SRR1 to shared page
KVM: PPC: Convert SPRG[0-4] to shared page
KVM: PPC: Implement hypervisor interface
KVM: PPC: Add PV guest critical sections
KVM: PPC: Add PV guest scratch registers
KVM: PPC: Tell guest about pending interrupts
KVM: PPC: Make RMO a define
KVM: PPC: First magic page steps
KVM: PPC: Magic Page Book3s support
KVM: PPC: Magic Page BookE support
KVM: PPC: Expose magic page support to guest
KVM: Move kvm_guest_init out of generic code
KVM: PPC: Generic KVM PV guest support
KVM: PPC: KVM PV guest stubs
KVM: PPC: PV instructions to loads and stores
KVM: PPC: PV tlbsync to nop
KVM: PPC: Introduce kvm_tmp framework
KVM: PPC: Introduce branch patching helper
KVM: PPC: PV assembler helpers
KVM: PPC: PV mtmsrd L=1
KVM: PPC: PV mtmsrd L=0 and mtmsr
KVM: PPC: PV wrteei
KVM: PPC: Add Documentation about PV interface
Documentation/kvm/ppc-pv.txt | 185 ++
arch/powerpc/include/asm/kvm_book3s.h | 1 -
arch/powerpc/include/asm/kvm_host.h | 15 +-
arch/powerpc/include/asm/kvm_para.h | 121 +-
arch/powerpc/include/asm/kvm_ppc.h | 1 +
arch/powerpc/kernel/Makefile | 2 +
arch/powerpc/kernel/asm-offsets.c | 18 ++-
arch/powerpc/kernel/kvm.c | 408
++
arch/powerpc/kernel/kvm_emul.S | 237 +
arch/powerpc/kvm/44x.c | 7 +
arch/powerpc/kvm/44x_tlb.c | 8 +-
arch/powerpc/kvm/book3s.c | 165 -
arch/powerpc/kvm/book3s_32_mmu.c | 28 ++-
arch/powerpc/kvm/book3s_32_mmu_host.c | 16 +-
arch/powerpc/kvm/book3s_64_mmu.c | 42 +++-
arch/powerpc/kvm/book3s_64_mmu_host.c | 16 +-
arch/powerpc/kvm/book3s_emulate.c | 25 +-
arch/powerpc/kvm/book3s_paired_singles.c | 11 +-
arch/powerpc/kvm/booke.c | 113 +++--
arch/powerpc/kvm/booke.h | 6 +-
arch/powerpc/kvm/booke_emulate.c | 14 +-
arch/powerpc/kvm/booke_interrupts.S | 3 +-
arch/powerpc/kvm/e500.c | 7 +
arch/powerpc/kvm/e500_tlb.c | 31 ++-
arch/powerpc/kvm/e500_tlb.h | 2 +-
arch/powerpc/kvm/emulate.c | 47 +++-
arch/powerpc/kvm/powerpc.c | 42 +++-
arch/powerpc/platforms/Kconfig | 10 +
arch/x86/include/asm/kvm_para.h | 6 +
include/linux/kvm_para.h | 7 +-
30 files changed, 1420 insertions(+), 174 deletions(-)
create mode 100644 Documentation/kvm/ppc-pv.txt
create mode 100644 arch/powerpc/kernel/kvm.c
create mode 100644 arch/powerpc/kernel/kvm_emul.S
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
[PATCH 1/2] powerpc/crashdump: Fix issues with kexec and 36bit physical addr
Fix sizes of variables so correct values are exported via /proc.
Cast variable in comparison to avoid compiler error.
Signed-off-by: Matthew McClintock m...@freescale.com
---
arch/powerpc/kernel/crash_dump.c|4 ++--
arch/powerpc/kernel/machine_kexec.c | 10 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/crash_dump.c b/arch/powerpc/kernel/crash_dump.c
index 5fb667a..d254132 100644
--- a/arch/powerpc/kernel/crash_dump.c
+++ b/arch/powerpc/kernel/crash_dump.c
@@ -128,9 +128,9 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
if (!csize)
return 0;
- csize = min(csize, PAGE_SIZE);
+ csize = min_t(size_t, csize, PAGE_SIZE);
- if (pfn max_pfn) {
+ if ((min_low_pfn pfn) (pfn max_pfn)) {
vaddr = __va(pfn PAGE_SHIFT);
csize = copy_oldmem_vaddr(vaddr, buf, csize, offset, userbuf);
} else {
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index bb3d893..6ff15f0 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -144,24 +144,24 @@ int overlaps_crashkernel(unsigned long start, unsigned
long size)
}
/* Values we need to export to the second kernel via the device tree. */
-static unsigned long kernel_end;
-static unsigned long crashk_size;
+static phys_addr_t kernel_end;
+static phys_addr_t crashk_size;
static struct property kernel_end_prop = {
.name = linux,kernel-end,
- .length = sizeof(unsigned long),
+ .length = sizeof(phys_addr_t),
.value = kernel_end,
};
static struct property crashk_base_prop = {
.name = linux,crashkernel-base,
- .length = sizeof(unsigned long),
+ .length = sizeof(phys_addr_t),
.value = crashk_res.start,
};
static struct property crashk_size_prop = {
.name = linux,crashkernel-size,
- .length = sizeof(unsigned long),
+ .length = sizeof(phys_addr_t),
.value = crashk_size,
};
--
1.6.6.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
