* Re: [patch 2/4] powerpc: add i2c pins to dts and board setup
From: Scott Wood @ 2008-05-14 23:25 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-dev, paulus
In-Reply-To: <200805142312.m4ENCrIb026259@imap1.linux-foundation.org>
akpm@linux-foundation.org wrote:
> From: Jochen Friedrich <jochen@scram.de>
>
> Initialize I2C pins on boards with CPM1/CPM2 controllers.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> arch/powerpc/boot/dts/mpc8272ads.dts | 10 ++++++++++
> arch/powerpc/boot/dts/mpc866ads.dts | 10 ++++++++++
> arch/powerpc/boot/dts/mpc885ads.dts | 10 ++++++++++
> arch/powerpc/platforms/82xx/mpc8272_ads.c | 4 ++++
> arch/powerpc/platforms/8xx/mpc86xads_setup.c | 4 ++++
> arch/powerpc/platforms/8xx/mpc885ads_setup.c | 3 +++
> 6 files changed, 41 insertions(+)
>
> diff -puN arch/powerpc/boot/dts/mpc8272ads.dts~powerpc-add-i2c-pins-to-dts-and-board-setup arch/powerpc/boot/dts/mpc8272ads.dts
> --- a/arch/powerpc/boot/dts/mpc8272ads.dts~powerpc-add-i2c-pins-to-dts-and-board-setup
> +++ a/arch/powerpc/boot/dts/mpc8272ads.dts
> @@ -217,6 +217,16 @@
> linux,network-index = <1>;
> fsl,cpm-command = <0x16200300>;
> };
> +
> + i2c@11860 {
> + compatible = "fsl,mpc8272-i2c",
> + "fsl,cpm2-i2c",
> + "fsl,cpm-i2c";
> + reg = <11860 20 8afc 2>;
> + interrupts = <1 8>;
> + interrupt-parent = <&PIC>;
> + fsl,cpm-command = <29600000>;
> + };
As I pointed out earlier, this patch is sticking dts-v0 style constants
into a dts-v1 file. It will not work.
We also need to document CPM2 i2c as an exception to the normal
interpretation of the second resource for a CPM device in
booting-without-of.txt.
-Scott
^ permalink raw reply
* [patch 1/1] fsldma: the MPC8377MDS board device tree node for fsldma driver
From: akpm @ 2008-05-14 23:17 UTC (permalink / raw)
To: paulus; +Cc: shannon.nelson, linuxppc-dev, galak, akpm, dan.j.williams,
wei.zhang
From: Zhang Wei <wei.zhang@freescale.com>
The fsldma driver is tested on MPC8377MDS board. The patch adds fsldma driver
support into MPC8377MDS device tree.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
Cc: "Nelson, Shannon" <shannon.nelson@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Kumar Gala <galak@gate.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/powerpc/boot/dts/mpc8377_mds.dts | 27 ++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff -puN arch/powerpc/boot/dts/mpc8377_mds.dts~fsldma-the-mpc8377mds-board-device-tree-node-for-fsldma-driver arch/powerpc/boot/dts/mpc8377_mds.dts
--- a/arch/powerpc/boot/dts/mpc8377_mds.dts~fsldma-the-mpc8377mds-board-device-tree-node-for-fsldma-driver
+++ a/arch/powerpc/boot/dts/mpc8377_mds.dts
@@ -295,6 +295,33 @@
};
};
+ dma@82a8 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8349-dma";
+ reg = <0x82a8 4>;
+ ranges = <0 0x8100 0x1a8>;
+ interrupt-parent = <&ipic>;
+ interrupts = <0x47 8>;
+ cell-index = <0>;
+ dma-channel@0 {
+ compatible = "fsl,mpc8349-dma-channel";
+ reg = <0 0x80>;
+ };
+ dma-channel@80 {
+ compatible = "fsl,mpc8349-dma-channel";
+ reg = <0x80 0x80>;
+ };
+ dma-channel@100 {
+ compatible = "fsl,mpc8349-dma-channel";
+ reg = <0x100 0x80>;
+ };
+ dma-channel@180 {
+ compatible = "fsl,mpc8349-dma-channel";
+ reg = <0x180 0x28>;
+ };
+ };
+
/* IPIC
* interrupts cell = <intr #, sense>
* sense values match linux IORESOURCE_IRQ_* defines:
_
^ permalink raw reply
* [patch 3/4] macintosh: replace deprecated __initcall with device_initcall
From: akpm @ 2008-05-14 23:12 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, akpm, rpjday
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/macintosh/adb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/macintosh/adb.c~macintosh-replace-deprecated-__initcall-with-device_initcall drivers/macintosh/adb.c
--- a/drivers/macintosh/adb.c~macintosh-replace-deprecated-__initcall-with-device_initcall
+++ a/drivers/macintosh/adb.c
@@ -334,7 +334,7 @@ int __init adb_init(void)
return 0;
}
-__initcall(adb_init);
+device_initcall(adb_init);
static int
do_adb_reset_bus(void)
_
^ permalink raw reply
* [patch 1/4] powerpc: fix for OProfile callgraph for Power 64 bit user apps
From: akpm @ 2008-05-14 23:12 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, akpm, carll, cel
From: Carl Love <cel@us.ibm.com>
Fix the 64 bit user code backtrace which currently may hang the system.
Signed-off-by: Carl Love <carll@us.ibm.com>
Cc: Maynard Johnson <maynardj@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/powerpc/oprofile/backtrace.c | 33 ++++++++++++++++++++++------
1 file changed, 27 insertions(+), 6 deletions(-)
diff -puN arch/powerpc/oprofile/backtrace.c~powerpc-fix-for-oprofile-callgraph-for-power-64-bit-user-apps arch/powerpc/oprofile/backtrace.c
--- a/arch/powerpc/oprofile/backtrace.c~powerpc-fix-for-oprofile-callgraph-for-power-64-bit-user-apps
+++ a/arch/powerpc/oprofile/backtrace.c
@@ -53,19 +53,40 @@ static unsigned int user_getsp32(unsigne
#ifdef CONFIG_PPC64
static unsigned long user_getsp64(unsigned long sp, int is_first)
{
- unsigned long stack_frame[3];
+ unsigned long stk_frm_lr;
+ unsigned long stk_frm_sp;
+ unsigned long size;
+
+ /* Issue the __copy_from_user_inatomic() third argument currently
+ * only takes sizes 1, 2, 4 or 8 bytes. Don't read more then the
+ * first 48 bytes of the stack frame. That is all that is
+ * guaranteed to exist. Reading more may cause the system to hang.
+ *
+ * 64 bit stack frame layout:
+ * 0-7 bytes is the pointer to previous stack
+ * 8-15 bytes condition register save area
+ * 16-23 bytes link register save area
+ */
+ size = sizeof(unsigned long);
+ if (!access_ok(VERIFY_READ, (void __user *)sp, size))
+ return 0;
- if (!access_ok(VERIFY_READ, (void __user *)sp, sizeof(stack_frame)))
+ if (__copy_from_user_inatomic(&stk_frm_sp, (void __user *)sp,
+ size))
return 0;
- if (__copy_from_user_inatomic(stack_frame, (void __user *)sp,
- sizeof(stack_frame)))
+ /* get the LR from the user stack */
+ if (!access_ok(VERIFY_READ, (void __user *)(sp+16), size))
+ return 0;
+
+ if (__copy_from_user_inatomic(&stk_frm_lr, (void __user *)(sp+16),
+ size))
return 0;
if (!is_first)
- oprofile_add_trace(STACK_LR64(stack_frame));
+ oprofile_add_trace(stk_frm_lr);
- return STACK_SP(stack_frame);
+ return stk_frm_sp;
}
#endif
_
^ permalink raw reply
* [patch 2/4] powerpc: add i2c pins to dts and board setup
From: akpm @ 2008-05-14 23:12 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, akpm
From: Jochen Friedrich <jochen@scram.de>
Initialize I2C pins on boards with CPM1/CPM2 controllers.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/powerpc/boot/dts/mpc8272ads.dts | 10 ++++++++++
arch/powerpc/boot/dts/mpc866ads.dts | 10 ++++++++++
arch/powerpc/boot/dts/mpc885ads.dts | 10 ++++++++++
arch/powerpc/platforms/82xx/mpc8272_ads.c | 4 ++++
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 4 ++++
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 3 +++
6 files changed, 41 insertions(+)
diff -puN arch/powerpc/boot/dts/mpc8272ads.dts~powerpc-add-i2c-pins-to-dts-and-board-setup arch/powerpc/boot/dts/mpc8272ads.dts
--- a/arch/powerpc/boot/dts/mpc8272ads.dts~powerpc-add-i2c-pins-to-dts-and-board-setup
+++ a/arch/powerpc/boot/dts/mpc8272ads.dts
@@ -217,6 +217,16 @@
linux,network-index = <1>;
fsl,cpm-command = <0x16200300>;
};
+
+ i2c@11860 {
+ compatible = "fsl,mpc8272-i2c",
+ "fsl,cpm2-i2c",
+ "fsl,cpm-i2c";
+ reg = <11860 20 8afc 2>;
+ interrupts = <1 8>;
+ interrupt-parent = <&PIC>;
+ fsl,cpm-command = <29600000>;
+ };
};
PIC: interrupt-controller@10c00 {
diff -puN arch/powerpc/boot/dts/mpc866ads.dts~powerpc-add-i2c-pins-to-dts-and-board-setup arch/powerpc/boot/dts/mpc866ads.dts
--- a/arch/powerpc/boot/dts/mpc866ads.dts~powerpc-add-i2c-pins-to-dts-and-board-setup
+++ a/arch/powerpc/boot/dts/mpc866ads.dts
@@ -171,6 +171,16 @@
fsl,cpm-command = <0000>;
linux,network-index = <1>;
};
+
+ i2c@860 {
+ compatible = "fsl,mpc866-i2c",
+ "fsl,cpm1-i2c",
+ "fsl,cpm-i2c";
+ reg = <860 20 3c80 30>;
+ interrupts = <10>;
+ interrupt-parent = <&CPM_PIC>;
+ fsl,cpm-command = <0010>;
+ };
};
};
diff -puN arch/powerpc/boot/dts/mpc885ads.dts~powerpc-add-i2c-pins-to-dts-and-board-setup arch/powerpc/boot/dts/mpc885ads.dts
--- a/arch/powerpc/boot/dts/mpc885ads.dts~powerpc-add-i2c-pins-to-dts-and-board-setup
+++ a/arch/powerpc/boot/dts/mpc885ads.dts
@@ -215,6 +215,16 @@
fsl,cpm-command = <0x80>;
linux,network-index = <2>;
};
+
+ i2c@860 {
+ compatible = "fsl,mpc885-i2c",
+ "fsl,cpm1-i2c",
+ "fsl,cpm-i2c";
+ reg = <860 20 3c80 30>;
+ interrupts = <10>;
+ interrupt-parent = <&CPM_PIC>;
+ fsl,cpm-command = <0010>;
+ };
};
};
diff -puN arch/powerpc/platforms/82xx/mpc8272_ads.c~powerpc-add-i2c-pins-to-dts-and-board-setup arch/powerpc/platforms/82xx/mpc8272_ads.c
--- a/arch/powerpc/platforms/82xx/mpc8272_ads.c~powerpc-add-i2c-pins-to-dts-and-board-setup
+++ a/arch/powerpc/platforms/82xx/mpc8272_ads.c
@@ -96,6 +96,10 @@ static struct cpm_pin mpc8272_ads_pins[]
{1, 31, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{2, 16, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{2, 17, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+
+ /* I2C */
+ {3, 14, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
+ {3, 15, CPM_PIN_INPUT | CPM_PIN_SECONDARY | CPM_PIN_OPENDRAIN},
};
static void __init init_ioports(void)
diff -puN arch/powerpc/platforms/8xx/mpc86xads_setup.c~powerpc-add-i2c-pins-to-dts-and-board-setup arch/powerpc/platforms/8xx/mpc86xads_setup.c
--- a/arch/powerpc/platforms/8xx/mpc86xads_setup.c~powerpc-add-i2c-pins-to-dts-and-board-setup
+++ a/arch/powerpc/platforms/8xx/mpc86xads_setup.c
@@ -65,6 +65,10 @@ static struct cpm_pin mpc866ads_pins[] =
{CPM_PORTD, 13, CPM_PIN_OUTPUT},
{CPM_PORTD, 14, CPM_PIN_OUTPUT},
{CPM_PORTD, 15, CPM_PIN_OUTPUT},
+
+ /* I2C */
+ {CPM_PORTB, 26, CPM_PIN_INPUT | CPM_PIN_OPENDRAIN},
+ {CPM_PORTB, 27, CPM_PIN_INPUT | CPM_PIN_OPENDRAIN},
};
static void __init init_ioports(void)
diff -puN arch/powerpc/platforms/8xx/mpc885ads_setup.c~powerpc-add-i2c-pins-to-dts-and-board-setup arch/powerpc/platforms/8xx/mpc885ads_setup.c
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c~powerpc-add-i2c-pins-to-dts-and-board-setup
+++ a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -158,6 +158,9 @@ static struct cpm_pin mpc885ads_pins[] =
{CPM_PORTE, 28, CPM_PIN_OUTPUT},
{CPM_PORTE, 29, CPM_PIN_OUTPUT},
#endif
+ /* I2C */
+ {CPM_PORTB, 26, CPM_PIN_INPUT | CPM_PIN_OPENDRAIN},
+ {CPM_PORTB, 27, CPM_PIN_INPUT | CPM_PIN_OPENDRAIN},
};
static void __init init_ioports(void)
_
^ permalink raw reply
* [patch 4/4] spufs: convert nopfn to fault
From: akpm @ 2008-05-14 23:12 UTC (permalink / raw)
To: paulus; +Cc: npiggin, linuxppc-dev, akpm, jk
From: Nick Piggin <npiggin@suse.de>
spufs: convert nopfn to fault
Signed-off-by: Nick Piggin <npiggin@suse.de>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/powerpc/platforms/cell/spufs/file.c | 98 ++++++++---------
arch/powerpc/platforms/cell/spufs/sputrace.c | 8 -
2 files changed, 54 insertions(+), 52 deletions(-)
diff -puN arch/powerpc/platforms/cell/spufs/file.c~spufs-convert-nopfn-to-fault arch/powerpc/platforms/cell/spufs/file.c
--- a/arch/powerpc/platforms/cell/spufs/file.c~spufs-convert-nopfn-to-fault
+++ a/arch/powerpc/platforms/cell/spufs/file.c
@@ -237,11 +237,13 @@ spufs_mem_write(struct file *file, const
return size;
}
-static unsigned long spufs_mem_mmap_nopfn(struct vm_area_struct *vma,
- unsigned long address)
+static int
+spufs_mem_mmap_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
struct spu_context *ctx = vma->vm_file->private_data;
- unsigned long pfn, offset, addr0 = address;
+ unsigned long address = (unsigned long)vmf->virtual_address;
+ unsigned long pfn, offset;
+
#ifdef CONFIG_SPU_FS_64K_LS
struct spu_state *csa = &ctx->csa;
int psize;
@@ -259,15 +261,15 @@ static unsigned long spufs_mem_mmap_nopf
}
#endif /* CONFIG_SPU_FS_64K_LS */
- offset = (address - vma->vm_start) + (vma->vm_pgoff << PAGE_SHIFT);
+ offset = vmf->pgoff << PAGE_SHIFT;
if (offset >= LS_SIZE)
- return NOPFN_SIGBUS;
+ return VM_FAULT_SIGBUS;
- pr_debug("spufs_mem_mmap_nopfn address=0x%lx -> 0x%lx, offset=0x%lx\n",
- addr0, address, offset);
+ pr_debug("spufs_mem_mmap_fault address=0x%lx, offset=0x%lx\n",
+ address, offset);
if (spu_acquire(ctx))
- return NOPFN_REFAULT;
+ return VM_FAULT_NOPAGE;
if (ctx->state == SPU_STATE_SAVED) {
vma->vm_page_prot = __pgprot(pgprot_val(vma->vm_page_prot)
@@ -282,12 +284,12 @@ static unsigned long spufs_mem_mmap_nopf
spu_release(ctx);
- return NOPFN_REFAULT;
+ return VM_FAULT_NOPAGE;
}
static struct vm_operations_struct spufs_mem_mmap_vmops = {
- .nopfn = spufs_mem_mmap_nopfn,
+ .fault = spufs_mem_mmap_fault,
};
static int spufs_mem_mmap(struct file *file, struct vm_area_struct *vma)
@@ -350,20 +352,19 @@ static const struct file_operations spuf
#endif
};
-static unsigned long spufs_ps_nopfn(struct vm_area_struct *vma,
- unsigned long address,
+static int spufs_ps_fault(struct vm_area_struct *vma,
+ struct vm_fault *vmf,
unsigned long ps_offs,
unsigned long ps_size)
{
struct spu_context *ctx = vma->vm_file->private_data;
- unsigned long area, offset = address - vma->vm_start;
+ unsigned long area, offset = vmf->pgoff << PAGE_SHIFT;
int ret = 0;
- spu_context_nospu_trace(spufs_ps_nopfn__enter, ctx);
+ spu_context_nospu_trace(spufs_ps_fault__enter, ctx);
- offset += vma->vm_pgoff << PAGE_SHIFT;
if (offset >= ps_size)
- return NOPFN_SIGBUS;
+ return VM_FAULT_SIGBUS;
/*
* Because we release the mmap_sem, the context may be destroyed while
@@ -377,7 +378,7 @@ static unsigned long spufs_ps_nopfn(stru
* pages to hand out to the user, but we don't want to wait
* with the mmap_sem held.
* It is possible to drop the mmap_sem here, but then we need
- * to return NOPFN_REFAULT because the mappings may have
+ * to return VM_FAULT_NOPAGE because the mappings may have
* hanged.
*/
if (spu_acquire(ctx))
@@ -385,14 +386,15 @@ static unsigned long spufs_ps_nopfn(stru
if (ctx->state == SPU_STATE_SAVED) {
up_read(¤t->mm->mmap_sem);
- spu_context_nospu_trace(spufs_ps_nopfn__sleep, ctx);
+ spu_context_nospu_trace(spufs_ps_fault__sleep, ctx);
ret = spufs_wait(ctx->run_wq, ctx->state == SPU_STATE_RUNNABLE);
- spu_context_trace(spufs_ps_nopfn__wake, ctx, ctx->spu);
+ spu_context_trace(spufs_ps_fault__wake, ctx, ctx->spu);
down_read(¤t->mm->mmap_sem);
} else {
area = ctx->spu->problem_phys + ps_offs;
- vm_insert_pfn(vma, address, (area + offset) >> PAGE_SHIFT);
- spu_context_trace(spufs_ps_nopfn__insert, ctx, ctx->spu);
+ vm_insert_pfn(vma, (unsigned long)vmf->virtual_address,
+ (area + offset) >> PAGE_SHIFT);
+ spu_context_trace(spufs_ps_fault__insert, ctx, ctx->spu);
}
if (!ret)
@@ -400,18 +402,18 @@ static unsigned long spufs_ps_nopfn(stru
refault:
put_spu_context(ctx);
- return NOPFN_REFAULT;
+ return VM_FAULT_NOPAGE;
}
#if SPUFS_MMAP_4K
-static unsigned long spufs_cntl_mmap_nopfn(struct vm_area_struct *vma,
- unsigned long address)
+static int spufs_cntl_mmap_fault(struct vm_area_struct *vma,
+ struct vm_fault *vmf)
{
- return spufs_ps_nopfn(vma, address, 0x4000, 0x1000);
+ return spufs_ps_fault(vma, vmf, 0x4000, 0x1000);
}
static struct vm_operations_struct spufs_cntl_mmap_vmops = {
- .nopfn = spufs_cntl_mmap_nopfn,
+ .fault = spufs_cntl_mmap_fault,
};
/*
@@ -1096,23 +1098,23 @@ static ssize_t spufs_signal1_write(struc
return 4;
}
-static unsigned long spufs_signal1_mmap_nopfn(struct vm_area_struct *vma,
- unsigned long address)
+static int
+spufs_signal1_mmap_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
#if PAGE_SIZE == 0x1000
- return spufs_ps_nopfn(vma, address, 0x14000, 0x1000);
+ return spufs_ps_fault(vma, vmf, 0x14000, 0x1000);
#elif PAGE_SIZE == 0x10000
/* For 64k pages, both signal1 and signal2 can be used to mmap the whole
* signal 1 and 2 area
*/
- return spufs_ps_nopfn(vma, address, 0x10000, 0x10000);
+ return spufs_ps_fault(vma, vmf, 0x10000, 0x10000);
#else
#error unsupported page size
#endif
}
static struct vm_operations_struct spufs_signal1_mmap_vmops = {
- .nopfn = spufs_signal1_mmap_nopfn,
+ .fault = spufs_signal1_mmap_fault,
};
static int spufs_signal1_mmap(struct file *file, struct vm_area_struct *vma)
@@ -1233,23 +1235,23 @@ static ssize_t spufs_signal2_write(struc
}
#if SPUFS_MMAP_4K
-static unsigned long spufs_signal2_mmap_nopfn(struct vm_area_struct *vma,
- unsigned long address)
+static int
+spufs_signal2_mmap_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
#if PAGE_SIZE == 0x1000
- return spufs_ps_nopfn(vma, address, 0x1c000, 0x1000);
+ return spufs_ps_fault(vma, vmf, 0x1c000, 0x1000);
#elif PAGE_SIZE == 0x10000
/* For 64k pages, both signal1 and signal2 can be used to mmap the whole
* signal 1 and 2 area
*/
- return spufs_ps_nopfn(vma, address, 0x10000, 0x10000);
+ return spufs_ps_fault(vma, vmf, 0x10000, 0x10000);
#else
#error unsupported page size
#endif
}
static struct vm_operations_struct spufs_signal2_mmap_vmops = {
- .nopfn = spufs_signal2_mmap_nopfn,
+ .fault = spufs_signal2_mmap_fault,
};
static int spufs_signal2_mmap(struct file *file, struct vm_area_struct *vma)
@@ -1361,14 +1363,14 @@ DEFINE_SPUFS_ATTRIBUTE(spufs_signal2_typ
spufs_signal2_type_set, "%llu\n", SPU_ATTR_ACQUIRE);
#if SPUFS_MMAP_4K
-static unsigned long spufs_mss_mmap_nopfn(struct vm_area_struct *vma,
- unsigned long address)
+static int
+spufs_mss_mmap_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
- return spufs_ps_nopfn(vma, address, 0x0000, 0x1000);
+ return spufs_ps_fault(vma, vmf, 0x0000, 0x1000);
}
static struct vm_operations_struct spufs_mss_mmap_vmops = {
- .nopfn = spufs_mss_mmap_nopfn,
+ .fault = spufs_mss_mmap_fault,
};
/*
@@ -1423,14 +1425,14 @@ static const struct file_operations spuf
.mmap = spufs_mss_mmap,
};
-static unsigned long spufs_psmap_mmap_nopfn(struct vm_area_struct *vma,
- unsigned long address)
+static int
+spufs_psmap_mmap_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
- return spufs_ps_nopfn(vma, address, 0x0000, 0x20000);
+ return spufs_ps_fault(vma, vmf, 0x0000, 0x20000);
}
static struct vm_operations_struct spufs_psmap_mmap_vmops = {
- .nopfn = spufs_psmap_mmap_nopfn,
+ .fault = spufs_psmap_mmap_fault,
};
/*
@@ -1483,14 +1485,14 @@ static const struct file_operations spuf
#if SPUFS_MMAP_4K
-static unsigned long spufs_mfc_mmap_nopfn(struct vm_area_struct *vma,
- unsigned long address)
+static int
+spufs_mfc_mmap_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
- return spufs_ps_nopfn(vma, address, 0x3000, 0x1000);
+ return spufs_ps_fault(vma, vmf, 0x3000, 0x1000);
}
static struct vm_operations_struct spufs_mfc_mmap_vmops = {
- .nopfn = spufs_mfc_mmap_nopfn,
+ .fault = spufs_mfc_mmap_fault,
};
/*
diff -puN arch/powerpc/platforms/cell/spufs/sputrace.c~spufs-convert-nopfn-to-fault arch/powerpc/platforms/cell/spufs/sputrace.c
--- a/arch/powerpc/platforms/cell/spufs/sputrace.c~spufs-convert-nopfn-to-fault
+++ a/arch/powerpc/platforms/cell/spufs/sputrace.c
@@ -182,10 +182,10 @@ struct spu_probe spu_probes[] = {
{ "spu_yield__enter", "ctx %p", spu_context_nospu_event },
{ "spu_deactivate__enter", "ctx %p", spu_context_nospu_event },
{ "__spu_deactivate__unload", "ctx %p spu %p", spu_context_event },
- { "spufs_ps_nopfn__enter", "ctx %p", spu_context_nospu_event },
- { "spufs_ps_nopfn__sleep", "ctx %p", spu_context_nospu_event },
- { "spufs_ps_nopfn__wake", "ctx %p spu %p", spu_context_event },
- { "spufs_ps_nopfn__insert", "ctx %p spu %p", spu_context_event },
+ { "spufs_ps_fault__enter", "ctx %p", spu_context_nospu_event },
+ { "spufs_ps_fault__sleep", "ctx %p", spu_context_nospu_event },
+ { "spufs_ps_fault__wake", "ctx %p spu %p", spu_context_event },
+ { "spufs_ps_fault__insert", "ctx %p spu %p", spu_context_event },
{ "spu_acquire_saved__enter", "ctx %p", spu_context_nospu_event },
{ "destroy_spu_context__enter", "ctx %p", spu_context_nospu_event },
{ "spufs_stop_callback__enter", "ctx %p spu %p", spu_context_event },
_
^ permalink raw reply
* [PATCH] CS4270 node is misplaced in the MPC8610 device tree
From: Timur Tabi @ 2008-05-14 22:29 UTC (permalink / raw)
To: galak, linuxppc-dev
The CS4270 is using the second I2C bus, not the first, on the Freescale
MPC8610 HPCD, so its node in the device tree belongs under 'i2c@3100'
and not 'i2c@3000'.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
Kumar, this is a must-fix for 2.6.26.
The reason this didn't show up before is because the CS4270 driver
is an old-style driver, and so it doesn't actually use the device tree
to determine the I2C bus/address.
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 08a780d..771f169 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -124,13 +124,6 @@
interrupts = <43 2>;
interrupt-parent = <&mpic>;
dfsrr;
-
- cs4270:codec@4f {
- compatible = "cirrus,cs4270";
- reg = <0x4f>;
- /* MCLK source is a stand-alone oscillator */
- clock-frequency = <12288000>;
- };
};
i2c@3100 {
@@ -142,6 +135,13 @@
interrupts = <43 2>;
interrupt-parent = <&mpic>;
dfsrr;
+
+ cs4270:codec@4f {
+ compatible = "cirrus,cs4270";
+ reg = <0x4f>;
+ /* MCLK source is a stand-alone oscillator */
+ clock-frequency = <12288000>;
+ };
};
serial0: serial@4500 {
--
1.5.5
^ permalink raw reply related
* Re: ALSA fixes for non-coherent archs (Re: [PATCH] Sam440ep support)
From: Gerhard Pircher @ 2008-05-14 21:01 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel, cjg
In-Reply-To: <s5hr6c5ax6a.wl%tiwai@suse.de>
-------- Original-Nachricht --------
> Datum: Wed, 14 May 2008 14:26:53 +0200
> Von: Takashi Iwai <tiwai@suse.de>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> CC: benh@kernel.crashing.org, galak@kernel.crashing.org, cjg@cruxppc.org, linuxppc-dev@ozlabs.org, alsa-devel@alsa-project.org
> Betreff: ALSA fixes for non-coherent archs (Re: [PATCH] Sam440ep support)
> At Tue, 06 May 2008 11:16:22 +0200,
> Gerhard Pircher wrote:
> >
> > Naturally I can do some tests, if you or Takashi come up with a new
> > patch.
>
> OK, here is another patch for testing. Since I lost my old patch
> somewhere (and it's not worth to dig the archive), I wrote it up
> quickly from scratch. This version should cover both SG and non-SG
> buffers. It's against the latest git tree.
>
> The patch adds a hackish verison of dma_mmap_coherent() for some
> architectures in sound/core/pcm_native.c. I'm not sure whether this
> works. I just tested it on X86. It'd be appreciated if someone can
> test this.
>
> Also, this disables HDSPM driver for non-X86/IA64 since the driver has
> own copy and silence methods that are incompatible with the new
> SG-buffer data.
>
>
> And, yes, I know we need to clean up huge messes in ALSA memory
> handling routines. But, let's fix obvious bugs before starting a big
> rewrite...
Okay, it seems to work fine so far. No lock-ups or kernel oopses. Tested
with kernel v2.6.26-rc2 and a Soundblaster 5.1/EMU10k1 device (which was
not working with the old patch) on my non cache coherent G4 system.
Thanks again!
Gerhard
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* New-style I2C driver not getting probed because of_register_i2c_devices() is not setting info.driver_name
From: Timur Tabi @ 2008-05-14 20:48 UTC (permalink / raw)
To: linuxppc-dev list
I'm converting sound/soc/codecs/cs4270.c into a new-style I2C driver, and this
driver is not getting probed. I believe the problem is that i2c_device_match()
is returning failure, because of this line:
return strcmp(client->driver_name, drv->name) == 0;
when this line is executed, client->drivername is blank. Therefore, the strcmp
never matches.
I think this string is blank because when of_register_i2c_devices() in fsl_soc.c
calls i2c_register_board_info(), the info.driver_name field is also blank.
i2c_new_device() copies info->driver_name to client->driver_name.
I don't understand why this code doesn't work for me. Most of the core I2C code
has been in place for a year, and I can't see how my driver is different from
any other new-style I2C driver that works on OF platforms.
Can anyone help me?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] POWERPC: Remove ioctl.h content picked up from <asm-generic/ioctl.h>.
From: Robert P. J. Day @ 2008-05-14 19:16 UTC (permalink / raw)
To: Linux PPC Mailing List
Now that <asm-generic/ioctl.h> allows overriding of the most commonly
changed macros, take advantage of that.
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
---
i *think* this results in an equivalent ioctl.h file, but feel free
to check it carefully, and tweak if necessary.
diff --git a/include/asm-powerpc/ioctl.h b/include/asm-powerpc/ioctl.h
index 8eb9984..57d6830 100644
--- a/include/asm-powerpc/ioctl.h
+++ b/include/asm-powerpc/ioctl.h
@@ -1,69 +1,13 @@
#ifndef _ASM_POWERPC_IOCTL_H
#define _ASM_POWERPC_IOCTL_H
-
-/*
- * this was copied from the alpha as it's a bit cleaner there.
- * -- Cort
- */
-
-#define _IOC_NRBITS 8
-#define _IOC_TYPEBITS 8
#define _IOC_SIZEBITS 13
#define _IOC_DIRBITS 3
-#define _IOC_NRMASK ((1 << _IOC_NRBITS)-1)
-#define _IOC_TYPEMASK ((1 << _IOC_TYPEBITS)-1)
-#define _IOC_SIZEMASK ((1 << _IOC_SIZEBITS)-1)
-#define _IOC_DIRMASK ((1 << _IOC_DIRBITS)-1)
-
-#define _IOC_NRSHIFT 0
-#define _IOC_TYPESHIFT (_IOC_NRSHIFT+_IOC_NRBITS)
-#define _IOC_SIZESHIFT (_IOC_TYPESHIFT+_IOC_TYPEBITS)
-#define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS)
-
-/*
- * Direction bits _IOC_NONE could be 0, but OSF/1 gives it a bit.
- * And this turns out useful to catch old ioctl numbers in header
- * files for us.
- */
#define _IOC_NONE 1U
#define _IOC_READ 2U
#define _IOC_WRITE 4U
-#define _IOC(dir,type,nr,size) \
- (((dir) << _IOC_DIRSHIFT) | \
- ((type) << _IOC_TYPESHIFT) | \
- ((nr) << _IOC_NRSHIFT) | \
- ((size) << _IOC_SIZESHIFT))
-
-/* provoke compile error for invalid uses of size argument */
-extern unsigned int __invalid_size_argument_for_IOC;
-#define _IOC_TYPECHECK(t) \
- ((sizeof(t) == sizeof(t[1]) && \
- sizeof(t) < (1 << _IOC_SIZEBITS)) ? \
- sizeof(t) : __invalid_size_argument_for_IOC)
-
-/* used to create numbers */
-#define _IO(type,nr) _IOC(_IOC_NONE,(type),(nr),0)
-#define _IOR(type,nr,size) _IOC(_IOC_READ,(type),(nr),(_IOC_TYPECHECK(size)))
-#define _IOW(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))
-#define _IOWR(type,nr,size) _IOC(_IOC_READ|_IOC_WRITE,(type),(nr),(_IOC_TYPECHECK(size)))
-#define _IOR_BAD(type,nr,size) _IOC(_IOC_READ,(type),(nr),sizeof(size))
-#define _IOW_BAD(type,nr,size) _IOC(_IOC_WRITE,(type),(nr),sizeof(size))
-#define _IOWR_BAD(type,nr,size) _IOC(_IOC_READ|_IOC_WRITE,(type),(nr),sizeof(size))
-
-/* used to decode them.. */
-#define _IOC_DIR(nr) (((nr) >> _IOC_DIRSHIFT) & _IOC_DIRMASK)
-#define _IOC_TYPE(nr) (((nr) >> _IOC_TYPESHIFT) & _IOC_TYPEMASK)
-#define _IOC_NR(nr) (((nr) >> _IOC_NRSHIFT) & _IOC_NRMASK)
-#define _IOC_SIZE(nr) (((nr) >> _IOC_SIZESHIFT) & _IOC_SIZEMASK)
-
-/* various drivers, such as the pcmcia stuff, need these... */
-#define IOC_IN (_IOC_WRITE << _IOC_DIRSHIFT)
-#define IOC_OUT (_IOC_READ << _IOC_DIRSHIFT)
-#define IOC_INOUT ((_IOC_WRITE|_IOC_READ) << _IOC_DIRSHIFT)
-#define IOCSIZE_MASK (_IOC_SIZEMASK << _IOC_SIZESHIFT)
-#define IOCSIZE_SHIFT (_IOC_SIZESHIFT)
+#include <asm-generic/ioctl.h>
#endif /* _ASM_POWERPC_IOCTL_H */
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
========================================================================
^ permalink raw reply related
* Re: [BUG] 2.6.26-rc2-mm1 - kernel panic at inet_create() on powerpc
From: Paul E. McKenney @ 2008-05-14 20:32 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: linux-kernel, Kamalesh Babulal, linuxppc-dev, Andrew Morton,
davem, Balbir Singh
In-Reply-To: <20080514200546.GA4802@martell.zuzino.mipt.ru>
On Thu, May 15, 2008 at 12:05:46AM +0400, Alexey Dobriyan wrote:
> On Wed, May 14, 2008 at 09:07:05AM -0700, Paul E. McKenney wrote:
> > On Wed, May 14, 2008 at 09:04:07PM +0530, Kamalesh Babulal wrote:
> > > Hi Andrew,
> > >
> > > 2.6.26-rc2-mm1 kernel panics on powerpc, while running ltp test over it.
> > > I have attached the gdb output of the pc and lr registers. The patch
> > > list_for_each_rcu-must-die-networking.patch points to changes made
> > > to the same lines listed by the gdb output.
> >
> > Hmmm.... Does the panic go away when this patch is reverted?
>
> Yes.
OK, am awake now, apologies for my confusion. Not sure -what- state
I was in when generating and validating the original...
Thanx, Paul
^ permalink raw reply
* Re: 8xx: Work around CPU15 erratum.
From: Ben Gardiner @ 2008-05-14 20:17 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <07769C41-66EB-48C5-9494-3BBE34447BBD@embeddedalley.com>
Dan Malek wrote:
>
> On May 14, 2008, at 10:52 AM, Ben Gardiner wrote:
>
>> So there likely are reasons why the following is not possible:
>
> That's way too much code for a tlb exception handler.
> From a system resource perspective, you are much better
> off with a small and efficient piece of tlb loading code,
> always invalidating pages on both ends and taking the
> tlb exception fault. Unfortunately, this could cause some
> thrashing edge cases, so a little intelligence would be
> needed. Exception processing isn't free, and it quickly
> destroys the cache footprint of your application, further
> slowing down the entire system. The tlb reload handler
> goal should be maximum of 8 instructions and 4 memory
> accesses, not 4K of elaborate conditional testing. :-)
>
> Thanks.
>
> -- Dan
>
Hi Dan,
Thanks for the rapid reply :) I really appreciate you giving me an
answer "from the horse's mouth." I would still like to experiment a
little and I'm not really sure it is safe to use any bits in a PTE.
Assuming I was crazy enough to ruin my cache footprint; are there any
three bits in the PTE that are safe to use for some page status
information?
Best Regards,
Ben
^ permalink raw reply
* RE: xilinx_hwicap driver problems
From: Stephen Neuendorffer @ 2008-05-14 20:09 UTC (permalink / raw)
To: Will Kritikos; +Cc: linuxppc-embedded
In-Reply-To: <3ee6f9e50805141220g2440bd4am6846b416ce20f721@mail.gmail.com>
OK, that's progress. The next thing I'd check is that you are *not*
using the JTAG configuration mode, as this disables the ICAP. You can
also try turning on the DEBUG flags in the driver itself. During open()
the driver attempts to read the IDCODE from the hwicap to get it back to
an initial state.
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Will
Kritikos
> Sent: Wednesday, May 14, 2008 12:20 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: xilinx_hwicap driver problems
>=20
> Steve,
> Yes, this fixed that problem. the following is now printed when
> booting the kernel.
>=20
> [ 5.866230] icap icap.0: Xilinx icap port driver
> [ 5.866401] icap icap.0: ioremap 40200000 to c5000000 with size
10000
>=20
> The icap is at address 0x40200000 on my system, so that seems correct.
>=20
> However, when I copy partial bitstreams to the device, I get strange
> results. Here is what I am seeing.
>=20
> # mknod /dev/icap c 259 0
> # cp opb_prr_0_lin_partial.bit /dev/icap
> cp: write error: Bad address
> # cp opb_prr_0_lin_partial.bit /dev/icap
> [ 66.566107] icap icap.0: Failed to open file#
> # cp opb_prr_0_lin_partial.bit /dev/icap
> #
>=20
> I know that this file exists in the current directory, and is a
> working partial bitstream.
>=20
> Thanks for the help.
> Will
>=20
>=20
> On Wed, May 14, 2008 at 2:37 PM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> > I bet you're using ARCH ppc...
> >
> > It looks like in arch/ppc/syslib/virtex_devices.c:
> >
> > #define XPAR_HWICAP(num) { \
> > .name =3D "xilinx_icap", \
> >
> > Should probably be:
> >
> > #define XPAR_HWICAP(num) { \
> > .name =3D "icap", \
> >
> > now.
> >
> > Can you make this change locally and verify that it solves the
problem?
> >
> > Steve
> >
> >> -----Original Message-----
> >> From:
linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> > [mailto:linuxppc-embedded-
> >> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Will
> > Kritikos
> >> Sent: Wednesday, May 14, 2008 9:03 AM
> >> To: linuxppc-embedded@ozlabs.org
> >> Subject: xilinx_hwicap driver problems
> >>
> >> I am having some trouble using the xilinx_hwicap driver in Linux.
> >> I am using version 2.6.24-rc8-xlnx of the Linux kernel from the
Xilinx
> >> GIT repository.
> >> The xilinx_hwicap driver is statically compiled in - not a loadable
> > module.
> >> I am using the opb_hwicap device on a V4FX60 FPGA, Linux running on
> > the PPC405.
> >>
> >> The driver successfully is initialized on boot - I added a printk
to
> >> the init function to verify this. However, as far as I can tell,
the
> >> probe function is never called. There is nothing in dmesg from the
> >> icap driver.
> >>
> >> After boot, the following files exist in /sys
> >>
> >> /sys/bus/platform/xilinx_icap.0
> >> /sys/bus/platform/drivers/icap/bind
> >> /sys/bus/platform/drivers/icap/uevent
> >> /sys/bus/platform/drivers/icap/unbind
> >> /sys/devices/platform/xilinx_icap.0
> >>
> >> I can make a device node /dev/icap, major number 259 minor number
0,
> >> and copy partial bitstreams to it, but again nothing happens, and
no
> >> output in dmesg.
> >>
> >> Any help is appreciated. I am probably overlooking something
simple.
> >>
> >> Thanks,
> >> Will Kritikos
> >> _______________________________________________
> >> Linuxppc-embedded mailing list
> >> Linuxppc-embedded@ozlabs.org
> >> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> > This email and any attachments are intended for the sole use of the
named recipient(s) and
> contain(s) confidential information that may be proprietary,
privileged or copyrighted under
> applicable law. If you are not the intended recipient, do not read,
copy, or forward this email
> message or any attachments. Delete this email message and any
attachments immediately.
> >
> >
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
This email and any attachments are intended for the sole use of the named=
recipient(s) and contain(s) confidential information that may be=
proprietary, privileged or copyrighted under applicable law. If you are=
not the intended recipient, do not read, copy, or forward this email=
message or any attachments. Delete this email message and any attachments=
immediately.
^ permalink raw reply
* Re: xilinx_hwicap driver problems
From: Will Kritikos @ 2008-05-14 19:20 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-embedded
In-Reply-To: <20080514183731.04FE920053@mail163-sin.bigfish.com>
Steve,
Yes, this fixed that problem. the following is now printed when
booting the kernel.
[ 5.866230] icap icap.0: Xilinx icap port driver
[ 5.866401] icap icap.0: ioremap 40200000 to c5000000 with size 10000
The icap is at address 0x40200000 on my system, so that seems correct.
However, when I copy partial bitstreams to the device, I get strange
results. Here is what I am seeing.
# mknod /dev/icap c 259 0
# cp opb_prr_0_lin_partial.bit /dev/icap
cp: write error: Bad address
# cp opb_prr_0_lin_partial.bit /dev/icap
[ 66.566107] icap icap.0: Failed to open file#
# cp opb_prr_0_lin_partial.bit /dev/icap
#
I know that this file exists in the current directory, and is a
working partial bitstream.
Thanks for the help.
Will
On Wed, May 14, 2008 at 2:37 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
> I bet you're using ARCH ppc...
>
> It looks like in arch/ppc/syslib/virtex_devices.c:
>
> #define XPAR_HWICAP(num) { \
> .name = "xilinx_icap", \
>
> Should probably be:
>
> #define XPAR_HWICAP(num) { \
> .name = "icap", \
>
> now.
>
> Can you make this change locally and verify that it solves the problem?
>
> Steve
>
>> -----Original Message-----
>> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> [mailto:linuxppc-embedded-
>> bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Will
> Kritikos
>> Sent: Wednesday, May 14, 2008 9:03 AM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: xilinx_hwicap driver problems
>>
>> I am having some trouble using the xilinx_hwicap driver in Linux.
>> I am using version 2.6.24-rc8-xlnx of the Linux kernel from the Xilinx
>> GIT repository.
>> The xilinx_hwicap driver is statically compiled in - not a loadable
> module.
>> I am using the opb_hwicap device on a V4FX60 FPGA, Linux running on
> the PPC405.
>>
>> The driver successfully is initialized on boot - I added a printk to
>> the init function to verify this. However, as far as I can tell, the
>> probe function is never called. There is nothing in dmesg from the
>> icap driver.
>>
>> After boot, the following files exist in /sys
>>
>> /sys/bus/platform/xilinx_icap.0
>> /sys/bus/platform/drivers/icap/bind
>> /sys/bus/platform/drivers/icap/uevent
>> /sys/bus/platform/drivers/icap/unbind
>> /sys/devices/platform/xilinx_icap.0
>>
>> I can make a device node /dev/icap, major number 259 minor number 0,
>> and copy partial bitstreams to it, but again nothing happens, and no
>> output in dmesg.
>>
>> Any help is appreciated. I am probably overlooking something simple.
>>
>> Thanks,
>> Will Kritikos
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
^ permalink raw reply
* Re: [BUG] 2.6.26-rc2-mm1 - kernel panic at inet_create() on powerpc
From: Alexey Dobriyan @ 2008-05-14 20:05 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, Kamalesh Babulal, linuxppc-dev, Andrew Morton,
davem, Balbir Singh
In-Reply-To: <20080514160705.GB8812@linux.vnet.ibm.com>
On Wed, May 14, 2008 at 09:07:05AM -0700, Paul E. McKenney wrote:
> On Wed, May 14, 2008 at 09:04:07PM +0530, Kamalesh Babulal wrote:
> > Hi Andrew,
> >
> > 2.6.26-rc2-mm1 kernel panics on powerpc, while running ltp test over it.
> > I have attached the gdb output of the pc and lr registers. The patch
> > list_for_each_rcu-must-die-networking.patch points to changes made
> > to the same lines listed by the gdb output.
>
> Hmmm.... Does the panic go away when this patch is reverted?
Yes.
^ permalink raw reply
* RE: xilinx_hwicap driver problems
From: Stephen Neuendorffer @ 2008-05-14 18:37 UTC (permalink / raw)
To: Will Kritikos, linuxppc-embedded
In-Reply-To: <3ee6f9e50805140903o381346f5kddbce29a3d06ba1f@mail.gmail.com>
I bet you're using ARCH ppc...
It looks like in arch/ppc/syslib/virtex_devices.c:
#define XPAR_HWICAP(num) { \
.name =3D "xilinx_icap", \
Should probably be:
#define XPAR_HWICAP(num) { \
.name =3D "icap", \
now.
Can you make this change locally and verify that it solves the problem?
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Will
Kritikos
> Sent: Wednesday, May 14, 2008 9:03 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: xilinx_hwicap driver problems
>=20
> I am having some trouble using the xilinx_hwicap driver in Linux.
> I am using version 2.6.24-rc8-xlnx of the Linux kernel from the Xilinx
> GIT repository.
> The xilinx_hwicap driver is statically compiled in - not a loadable
module.
> I am using the opb_hwicap device on a V4FX60 FPGA, Linux running on
the PPC405.
>=20
> The driver successfully is initialized on boot - I added a printk to
> the init function to verify this. However, as far as I can tell, the
> probe function is never called. There is nothing in dmesg from the
> icap driver.
>=20
> After boot, the following files exist in /sys
>=20
> /sys/bus/platform/xilinx_icap.0
> /sys/bus/platform/drivers/icap/bind
> /sys/bus/platform/drivers/icap/uevent
> /sys/bus/platform/drivers/icap/unbind
> /sys/devices/platform/xilinx_icap.0
>=20
> I can make a device node /dev/icap, major number 259 minor number 0,
> and copy partial bitstreams to it, but again nothing happens, and no
> output in dmesg.
>=20
> Any help is appreciated. I am probably overlooking something simple.
>=20
> Thanks,
> Will Kritikos
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
This email and any attachments are intended for the sole use of the named=
recipient(s) and contain(s) confidential information that may be=
proprietary, privileged or copyrighted under applicable law. If you are=
not the intended recipient, do not read, copy, or forward this email=
message or any attachments. Delete this email message and any attachments=
immediately.
^ permalink raw reply
* RE: [PATCH] Xilinx: framebuffer: add compatibility for ml507 dvi core.
From: Stephen Neuendorffer @ 2008-05-14 18:03 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, git-dev
In-Reply-To: <fa686aa40805140835v14b9ff85od01e74985e8e3586@mail.gmail.com>
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
Grant Likely
> Sent: Wednesday, May 14, 2008 8:35 AM
> To: Stephen Neuendorffer
> Cc: linuxppc-dev@ozlabs.org; git-dev
> Subject: Re: [PATCH] Xilinx: framebuffer: add compatibility for ml507
dvi core.
>=20
> On Mon, May 12, 2008 at 1:59 PM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf
Of
> > Grant Likely
> >> Sent: Monday, May 12, 2008 12:46 PM
> >> To: Stephen Neuendorffer
> >> Cc: linuxppc-dev@ozlabs.org; git-dev
> >> Subject: Re: [PATCH] Xilinx: framebuffer: add compatibility for
ml507
> > dvi core.
> >>
> >> On Mon, May 12, 2008 at 1:10 PM, Stephen Neuendorffer
> >> <stephen.neuendorffer@xilinx.com> wrote:
> >> >
> >> > The best possibility that I see is glopping the compatibility
> >> > information about what cores are compatible with which drivers
and
> >> > generating something. This is moderately better than blindly
> > treating
> >> > all cores with the same major version as interface compatible,
but
> > still
> >> > has the potential to blindly declare that core versions are
> > compatible
> >> > when they are not really compatible.
> >>
> >> That's okay, the device tree conventions provide for that
uncertainty.
> >> If compatible includes both the *exact* version and the oldest
known
> >> *compatible* version (the one the drivers know about) then we're in
> >> the situation where 99% of the time it just works. For the 1% of
the
> >> time when mistakes are made we still have the necessary information
to
> >> write exceptions in the code to work around bad data. This means
code
> >> only needs to changes when mistakes are discovered, not for every
IP
> >> core uprev.
> >
> > My argument was that we should do this by truncating the major
version,
> > which is also an established standard that cores *should* follow,
but
> > you didn't like that. :) It makes at least as much sense as
expressing
> > the compatibility of the driver in the tree in terms of
compatibility
> > with some other random driver. In the case of the tft core in
> > particular, there *is* no other driver AFAIK.
>=20
> The whole point of compatible is to describe software interfaces...
> *if* a device is register level backwards compatible with an older
> already supported device, *then* it is appropriate to claim
> compatibility with it. True, the TFT core is not the same as the VGA
> core. But (as your patch suggests) the register interface is
> backwards compatible.
Certainly... I don't think the question is how to do it, I think the
question is how to systematically get this information from the people
who build the cores, rather than having it put in on a case-by-case
basis somewhere down the line. This is as much a Xilinx organizational
issue as anything. If we *can't* get it in a systematic way, then I see
nothing better than putting it explicitly in the compatible list. The
current answer that I've gotten from the IP group is that the systematic
way to represent this information is through the major/minor version.
Specifically:
"The brief summary is that in a <major>.<minor>.<letter> version string:
- a change of the <letter> guarantees complete backward compatibility
- a change of the <minor> is new or modified behavior. The register
interface should remain compatible, although new features may be added.
I wouldn't say this guarantees backward compatibility, though, because
default values can change or behavior in general can change.
- a change of the <major> is quite likely to lose backward
compatibility."
> As for truncating the major version; you're right, I don't like it,
> but that doesn't mean I cannot be swayed. Best argument is to
> analogize it with a similar SoC situation. A particular SoC (let's
> say the MPC8349) will have several revisions to it, but none of that
> is reflected in the device tree. It's just referred to as
> "fsl,mpc8349". Actual silicon revision is obtainable by software from
> the PVR/SVR if it *really* needs it. The counter example is the
> MPC5200/MPC5200b where the 'b' version is explicitly specified in the
> compatible list (see arch/powerpc/boot/dts/lite5200b.dts). The 5200b
> is 99% compatible with the original 5200, with only a couple of on
> chip peripherals not being register level compatible. I'm still not
> completely certain that "fsl,mpc5200b-<blah>" was the right decision,
> but by being conservative early on means that I can still drop most of
> the 'b' specifiers at some point in the future without breaking board
> support.
>=20
> What makes me nervous about FPGA IP cores is that the potential for
> change is much higher than for an SoC. SoC vendors get very angry
> customers if a silicon uprev breaks their drivers; especially
> considering that they could very easily have boards with both the old
> and new silicon. It does not seem to me like there is quite the same
> level of pressure too keep the register level interface 100%
> compatible. So this is the pressure point to apply if you want to
> change my mind. How confident are you that the major (or minor)
> revision will remain register level compatible?
I'd actually turn it around: In most cases users of an FPGA device have
*much* more control over these versions than in a microprocessor
situation. Generally speaking, if there is a letter-version increment,
EDK generally forces you to accept the version increment when moving
from one version of EDK (with one set of IP versions) to another. If
there is a minor-version increment, then EDK asks you if you want to
change. If there is a major-version increment, then EDK notifies you of
the change, but doesn't do anything automatically. You certainly can't
do that in an SoC.
> n>> > I *really* don't want to put this into the device tree
generator on
> > a
> >> > case-by-case basis, so unless there is something that can be
> > generated
> >> > from whatever meta-information EDK has, I think we're going to
have
> > to
> >> > just have the explicit versions in the drivers for the time
being.
> >>
> >> Can we post process the generated device tree with a table of known
> >> compatibility strings (or regexps) for adding the older compatible
> >> values? I don't expect the list will be particularly long or hard
to
> >> maintain and the code to do so should be trivial.
> >
> > Ug, that's just pushing the problem around.
> > This seems as much like an argument for putting wildcards in the
> > compatible bindings in the kernel as anything...
>=20
> Not quite. There is a difference between method used to generate the
> data, and how the data is interpreted by the kernel (the boundary
> being what data is actually passed to the kernel). If the tool
> generates bad/inaccurate data, then it is a bug and it should be
> fixed. Even better, it is a bug that will be found quickly because
> the device simply won't work if it binds to the wrong driver. I do
> not want to load knowledge of all those permutation into the kernel
> image.
>
> (But I do agree that my suggestion was rather smelly)
HA! Well, I guess I was trying to be polite.. :) The much bigger
problem than binding to the wrong driver is not binding to the right
driver, particularly for anything having to do with the console.
So, what I hear is that you might be accepting of using compatible
strings of the form:
xlnx,opb-hwicap-1 (saving ~5 compatible entries in the current xilinx
git tree)
or=20
xlnx,opb-hwicap-1.00 (saving ~4 more)
Steve
arch/powerpc/boot/serial.c: else if (dt_is_compatible(devp,
"xlnx,opb-uartlite-1.00.b") ||
arch/powerpc/boot/serial.c: dt_is_compatible(devp,
"xlnx,xps-uartlite-1.00.a"))
arch/powerpc/boot/serial.c: else if (dt_is_compatible(devp,
"xlnx,opb-uart16550-1.00.c") ||
arch/powerpc/boot/serial.c: dt_is_compatible(devp,
"xlnx,opb-uart16550-1.00.d") ||
arch/powerpc/boot/serial.c: dt_is_compatible(devp,
"xlnx,opb-uart16550-1.00.e") ||
arch/powerpc/boot/serial.c: dt_is_compatible(devp,
"xlnx,plb-uart16550-1.00.c") ||
arch/powerpc/boot/serial.c: dt_is_compatible(devp,
"xlnx,xps-uart16550-1.00.a") ||
arch/powerpc/boot/serial.c: dt_is_compatible(devp,
"xlnx,xps-uart16550-2.00.a") ||
arch/powerpc/boot/serial.c: dt_is_compatible(devp,
"xlnx,xps-uart16550-2.00.b"))
arch/powerpc/platforms/44x/virtex.c: { .compatible =3D
"xlnx,plb-v46-1.00.a", },
arch/powerpc/platforms/44x/virtex.c: { .compatible =3D
"xlnx,plb-v46-1.02.a", },
arch/powerpc/platforms/44x/virtex.c: { .compatible =3D
"xlnx,plb-v34-1.01.a", },
arch/powerpc/platforms/44x/virtex.c: { .compatible =3D
"xlnx,plb-v34-1.02.a", },
arch/powerpc/platforms/44x/virtex.c: { .compatible =3D
"xlnx,opb-v20-1.10.c", },
arch/powerpc/platforms/44x/virtex.c: { .compatible =3D
"xlnx,dcr-v29-1.00.a", },
arch/powerpc/platforms/44x/virtex.c: { .compatible =3D "xlnx,compound",
},
arch/powerpc/platforms/44x/virtex.c: if
(!of_flat_dt_is_compatible(root, "xlnx,virtex"))
arch/powerpc/sysdev/xilinx_intc.c: for_each_compatible_node(np,
NULL, "xlnx,opb-intc-1.00.c") {
arch/powerpc/sysdev/xilinx_intc.c:
for_each_compatible_node(np, NULL, "xlnx,xps-intc-1.00.a") {
arch/microblaze/kernel/platform.c: { .compatible =3D
"xlnx,plb-v46-1.00.a", },
arch/microblaze/kernel/platform.c: { .compatible =3D
"xlnx,plb-v34-1.01.a", },
arch/microblaze/kernel/platform.c: { .compatible =3D
"xlnx,plb-v34-1.02.a", },
arch/microblaze/kernel/platform.c: { .compatible =3D
"xlnx,opb-v20-1.10.c", },
arch/microblaze/kernel/platform.c: { .compatible =3D
"xlnx,dcr-v29-1.00.a", },
arch/microblaze/kernel/platform.c: { .compatible =3D "xlnx,compound",
},
drivers/block/xsysace.c: { .compatible =3D
"xlnx,opb-sysace-1.00.b", },
drivers/block/xsysace.c: { .compatible =3D
"xlnx,opb-sysace-1.00.c", },
drivers/block/xsysace.c: { .compatible =3D
"xlnx,xps-sysace-1.00.a", },
drivers/char/xilinx_hwicap/xilinx_hwicap.c: { .compatible =3D
"xlnx,opb-hwicap-1.00.b", .data =3D &buffer_icap_config},
drivers/char/xilinx_hwicap/xilinx_hwicap.c: { .compatible =3D
"xlnx,xps-hwicap-1.00.a", .data =3D
&fifo_icap_config},drivers/i2c/algos/xilinx_iic/i2c-algo-xilinx.c: {
.compatible =3D "xlnx,xps-iic-2.00.a", },
drivers/input/serio/xilinx_ps2/xps2_linux.c: { .compatible =3D
"xlnx,opb-ps2-dual-ref-1.00.a", },
drivers/input/serio/xilinx_ps2/xps2_linux.c: { .compatible =3D
"xlnx,xps-ps2-1.00.a", },
drivers/net/xilinx_emac/xemac_linux.c: { .compatible =3D
"xlnx,opb-ethernet-1.01.a", },
drivers/net/xilinx_emac/xemac_linux.c: { .compatible =3D
"xlnx,opb-ethernet-1.02.a", },
drivers/net/xilinx_emac/xemac_linux.c: { .compatible =3D
"xlnx,opb-ethernet-1.04.a", },
drivers/net/xilinx_emac/xemac_linux.c: { .compatible =3D
"xlnx,plb-ethernet-1.00.a", },
drivers/net/xilinx_emac/xemac_linux.c: { .compatible =3D
"xlnx,plb-ethernet-1.01.a", },
drivers/net/xilinx_emaclite/adapter.c: { .compatible =3D
"xlnx,opb-ethernetlite-1.01.a", },
drivers/net/xilinx_emaclite/adapter.c: { .compatible =3D
"xlnx,opb-ethernetlite-1.01.b", },
drivers/net/xilinx_emaclite/adapter.c: { .compatible =3D
"xlnx,xps-ethernetlite-1.00.a", },
drivers/net/xilinx_emaclite/adapter.c: { .compatible =3D
"xlnx,xps-ethernetlite-2.00.a", },
drivers/net/xilinx_lltemac/xlltemac_main.c: { .compatible =3D
"xlnx,xps-ll-fifo-1.00.a", },
drivers/net/xilinx_lltemac/xlltemac_main.c: { .compatible =3D
"xlnx,xps-ll-fifo-1.00.b", },
drivers/net/xilinx_lltemac/xlltemac_main.c: { .compatible =3D
"xlnx,ll-dma-1.00.a", },
drivers/net/xilinx_lltemac/xlltemac_main.c: { .compatible =3D
"xlnx,xps-ll-temac-1.00.a", },
drivers/net/xilinx_lltemac/xlltemac_main.c: { .compatible =3D
"xlnx,xps-ll-temac-1.00.b", },
drivers/net/xilinx_lltemac/xlltemac_main.c: { .compatible =3D
"xlnx,xps-ll-temac-1.01.a", },
drivers/net/xilinx_lltemac/xlltemac_main.c: { .compatible =3D
"xlnx,xps-ll-temac-1.01.b", },
drivers/serial/uartlite.c: { .compatible =3D
"xlnx,opb-uartlite-1.00.b", },
drivers/serial/uartlite.c: { .compatible =3D
"xlnx,xps-uartlite-1.00.a", },
drivers/video/xilinxfb.c: { .compatible =3D
"xlnx,plb-tft-cntlr-ref-1.00.a", },
drivers/video/xilinxfb.c: { .compatible =3D
"xlnx,plbv46-tft-cntlr-1.00.a", },
drivers/video/xilinxfb.c: { .compatible =3D
"xlnx,plb-dvi-cntlr-ref-1.00.c", },
This email and any attachments are intended for the sole use of the named=
recipient(s) and contain(s) confidential information that may be=
proprietary, privileged or copyrighted under applicable law. If you are=
not the intended recipient, do not read, copy, or forward this email=
message or any attachments. Delete this email message and any attachments=
immediately.
^ permalink raw reply
* Re: 8xx: Work around CPU15 erratum.
From: Dan Malek @ 2008-05-14 16:23 UTC (permalink / raw)
To: Ben Gardiner; +Cc: linuxppc-embedded
In-Reply-To: <482AFCC5.2070907@nanometrics.ca>
On May 14, 2008, at 10:52 AM, Ben Gardiner wrote:
> So there likely are reasons why the following is not possible:
That's way too much code for a tlb exception handler.
From a system resource perspective, you are much better
off with a small and efficient piece of tlb loading code,
always invalidating pages on both ends and taking the
tlb exception fault. Unfortunately, this could cause some
thrashing edge cases, so a little intelligence would be
needed. Exception processing isn't free, and it quickly
destroys the cache footprint of your application, further
slowing down the entire system. The tlb reload handler
goal should be maximum of 8 instructions and 4 memory
accesses, not 4K of elaborate conditional testing. :-)
Thanks.
-- Dan
^ permalink raw reply
* Re: How to test the DDR memory with burst visit mode?
From: David Hawkins @ 2008-05-14 16:12 UTC (permalink / raw)
To: ??; +Cc: linuxppc-embedded
In-Reply-To: <410764342.21662@tsinghua.org.cn>
> I designed my MPC8360E board with 1GBytes DDR-1 memory, I built two demo
> boards, one is 533/266/400, the other is 660/330/400. The lower frequancy board is
> no problem for our program, but the higher frequency board is always problem about
> the data transmit on ethernet.
> I want to test 1GBytes DDR-1 memory, I want to know whether or not the DDR is
> stable and accuracy. Could you tell me a simple way that test my DDR memory?
I use MPC8349E, so the following should be similar.
1) If your board is a PCI agent.
You can run code on a host CPU that can view the MPC8360 board
over the PCI bus.
Setup the MPC8360 to come out of reset with the core held
in reset.
Program the DDR controller from the host CPU.
Program the DMA controller to move data to/from the board DDR
from/to the host memory (PCI transactions).
Sweep the DDR MCK and DQS clock skew registers across their
ranges and check for memory errors.
You should get two or three settings that work ok.
2) If your board is a PCI host, then its a bit trickier, as you
ideally want to generate burst traffic to test the DDR controller,
and since you need to reprogram the DDR controller, you can not
be running code there, eg. U-Boot.
If the MPC8360 has an I/O Sequencer (IOS) as on the MPC8349E, then
I think you should be able to write some code that DMAs from
Flash to DDR. The IOS should copy the data first to its FIFO,
and then to the DDR, so it should generate a burst.
If you have a BDI2000, you should be able to manually program
the DDR controller and the DMA controller. If you don't, just
write some simple code that runs from the startup vector,
eg. copy the contents of start.S up until the stack-in-dcache
trick, and then you can write some C-code.
Hope that helps.
Cheers,
Dave
^ permalink raw reply
* Re: [BUG] 2.6.26-rc2-mm1 - kernel panic at inet_create() on powerpc
From: Paul E. McKenney @ 2008-05-14 16:07 UTC (permalink / raw)
To: Kamalesh Babulal
Cc: linux-kernel, linuxppc-dev, Andrew Morton, davem, Balbir Singh
In-Reply-To: <482B066F.4010605@linux.vnet.ibm.com>
On Wed, May 14, 2008 at 09:04:07PM +0530, Kamalesh Babulal wrote:
> Hi Andrew,
>
> 2.6.26-rc2-mm1 kernel panics on powerpc, while running ltp test over it.
> I have attached the gdb output of the pc and lr registers. The patch
> list_for_each_rcu-must-die-networking.patch points to changes made
> to the same lines listed by the gdb output.
Hmmm.... Does the panic go away when this patch is reverted?
Thanx, Paul
> Unable to handle kernel paging request for data at address 0x00000000
> Faulting instruction address: 0xc000000000481fa0
> cpu 0x0: Vector: 300 (Data Access) at [c0000000eae37900]
> pc: c000000000481fa0: .inet_create+0xb4/0x330
> lr: c000000000413340: .__sock_create+0x190/0x280
> sp: c0000000eae37b80
> msr: 8000000000009032
> dar: 0
> dsisr: 40010000
> current = 0xc0000000cd201500
> paca = 0xc0000000007c3480
> pid = 6462, comm = socket01
> enter ? for help
> [c0000000eae37c30] c000000000413340 .__sock_create+0x190/0x280
> [c0000000eae37cf0] c0000000004137e0 .sys_socket+0x40/0x98
> [c0000000eae37d90] c000000000438e18 .compat_sys_socketcall+0xc0/0x234
> [c0000000eae37e30] c0000000000086b4 syscall_exit+0x0/0x40
> --- Exception: c01 (System Call) at 000000000ff20484
> SP (ffc8f770) is in userspace
>
>
> 0xc000000000481fa0 is in inet_create (net/ipv4/af_inet.c:290).
> 285 /* Look for the requested type/protocol pair. */
> 286 answer = NULL;
> 287 lookup_protocol:
> 288 err = -ESOCKTNOSUPPORT;
> 289 rcu_read_lock();
> 290 list_for_each_entry_rcu(answer, &inetsw[sock->type], list) {
> 291
> 292 /* Check the non-wild match. */
> 293 if (protocol == answer->protocol) {
> 294 if (protocol != IPPROTO_IP)
>
>
> 0xc000000000413340 is in __sock_create (net/socket.c:1171).
> 1166 goto out_release;
> 1167
> 1168 /* Now protected by module ref count */
> 1169 rcu_read_unlock();
> 1170
> 1171 err = pf->create(net, sock, protocol);
> 1172 if (err < 0)
> 1173 goto out_module_put;
> 1174
> 1175 /*
>
> --
> Thanks & Regards,
> Kamalesh Babulal,
> Linux Technology Center,
> IBM, ISTL.
^ permalink raw reply
* xilinx_hwicap driver problems
From: Will Kritikos @ 2008-05-14 16:03 UTC (permalink / raw)
To: linuxppc-embedded
I am having some trouble using the xilinx_hwicap driver in Linux.
I am using version 2.6.24-rc8-xlnx of the Linux kernel from the Xilinx
GIT repository.
The xilinx_hwicap driver is statically compiled in - not a loadable module.
I am using the opb_hwicap device on a V4FX60 FPGA, Linux running on the PPC405.
The driver successfully is initialized on boot - I added a printk to
the init function to verify this. However, as far as I can tell, the
probe function is never called. There is nothing in dmesg from the
icap driver.
After boot, the following files exist in /sys
/sys/bus/platform/xilinx_icap.0
/sys/bus/platform/drivers/icap/bind
/sys/bus/platform/drivers/icap/uevent
/sys/bus/platform/drivers/icap/unbind
/sys/devices/platform/xilinx_icap.0
I can make a device node /dev/icap, major number 259 minor number 0,
and copy partial bitstreams to it, but again nothing happens, and no
output in dmesg.
Any help is appreciated. I am probably overlooking something simple.
Thanks,
Will Kritikos
^ permalink raw reply
* Re: [PATCH] Xilinx: framebuffer: add compatibility for ml507 dvi core.
From: Grant Likely @ 2008-05-14 15:35 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, git-dev
In-Reply-To: <20080512195905.8DD2717B805C@mail2-dub.bigfish.com>
On Mon, May 12, 2008 at 1:59 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
>
>> -----Original Message-----
>> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
> Grant Likely
>> Sent: Monday, May 12, 2008 12:46 PM
>> To: Stephen Neuendorffer
>> Cc: linuxppc-dev@ozlabs.org; git-dev
>> Subject: Re: [PATCH] Xilinx: framebuffer: add compatibility for ml507
> dvi core.
>>
>> On Mon, May 12, 2008 at 1:10 PM, Stephen Neuendorffer
>> <stephen.neuendorffer@xilinx.com> wrote:
>> >
>> > The best possibility that I see is glopping the compatibility
>> > information about what cores are compatible with which drivers and
>> > generating something. This is moderately better than blindly
> treating
>> > all cores with the same major version as interface compatible, but
> still
>> > has the potential to blindly declare that core versions are
> compatible
>> > when they are not really compatible.
>>
>> That's okay, the device tree conventions provide for that uncertainty.
>> If compatible includes both the *exact* version and the oldest known
>> *compatible* version (the one the drivers know about) then we're in
>> the situation where 99% of the time it just works. For the 1% of the
>> time when mistakes are made we still have the necessary information to
>> write exceptions in the code to work around bad data. This means code
>> only needs to changes when mistakes are discovered, not for every IP
>> core uprev.
>
> My argument was that we should do this by truncating the major version,
> which is also an established standard that cores *should* follow, but
> you didn't like that. :) It makes at least as much sense as expressing
> the compatibility of the driver in the tree in terms of compatibility
> with some other random driver. In the case of the tft core in
> particular, there *is* no other driver AFAIK.
The whole point of compatible is to describe software interfaces...
*if* a device is register level backwards compatible with an older
already supported device, *then* it is appropriate to claim
compatibility with it. True, the TFT core is not the same as the VGA
core. But (as your patch suggests) the register interface is
backwards compatible.
As for truncating the major version; you're right, I don't like it,
but that doesn't mean I cannot be swayed. Best argument is to
analogize it with a similar SoC situation. A particular SoC (let's
say the MPC8349) will have several revisions to it, but none of that
is reflected in the device tree. It's just referred to as
"fsl,mpc8349". Actual silicon revision is obtainable by software from
the PVR/SVR if it *really* needs it. The counter example is the
MPC5200/MPC5200b where the 'b' version is explicitly specified in the
compatible list (see arch/powerpc/boot/dts/lite5200b.dts). The 5200b
is 99% compatible with the original 5200, with only a couple of on
chip peripherals not being register level compatible. I'm still not
completely certain that "fsl,mpc5200b-<blah>" was the right decision,
but by being conservative early on means that I can still drop most of
the 'b' specifiers at some point in the future without breaking board
support.
What makes me nervous about FPGA IP cores is that the potential for
change is much higher than for an SoC. SoC vendors get very angry
customers if a silicon uprev breaks their drivers; especially
considering that they could very easily have boards with both the old
and new silicon. It does not seem to me like there is quite the same
level of pressure too keep the register level interface 100%
compatible. So this is the pressure point to apply if you want to
change my mind. How confident are you that the major (or minor)
revision will remain register level compatible?
n>> > I *really* don't want to put this into the device tree generator on
> a
>> > case-by-case basis, so unless there is something that can be
> generated
>> > from whatever meta-information EDK has, I think we're going to have
> to
>> > just have the explicit versions in the drivers for the time being.
>>
>> Can we post process the generated device tree with a table of known
>> compatibility strings (or regexps) for adding the older compatible
>> values? I don't expect the list will be particularly long or hard to
>> maintain and the code to do so should be trivial.
>
> Ug, that's just pushing the problem around.
> This seems as much like an argument for putting wildcards in the
> compatible bindings in the kernel as anything...
Not quite. There is a difference between method used to generate the
data, and how the data is interpreted by the kernel (the boundary
being what data is actually passed to the kernel). If the tool
generates bad/inaccurate data, then it is a bug and it should be
fixed. Even better, it is a bug that will be found quickly because
the device simply won't work if it binds to the wrong driver. I do
not want to load knowledge of all those permutation into the kernel
image.
(But I do agree that my suggestion was rather smelly)
As for wildcards, the big problem is that the definition of a wildcard
changes over time as new devices are released. Consider this;
aesthetics aside, what is the difference between using
"xlnx,plb-tft-cntlr-ref-1.xx" and "xlnx,plb-tft-cntlr-ref-1.00.a" as a
'generic' compatible value? The value still needs to be coded into
the tool somewhere; but the second one is anchored to a single real
implementation which means that it's definition is fixed.
I know I'm being very conservative here; but it is safer to be
conservative now and relax stuff later than the other way around.
Being liberal is what got arch/ppc into the whole bdinfo_t mess in the
first place.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [BUG] 2.6.26-rc2-mm1 - kernel panic at inet_create() on powerpc
From: Kamalesh Babulal @ 2008-05-14 15:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-dev, paulmck, davem, Balbir Singh
In-Reply-To: <20080514010129.4f672378.akpm@linux-foundation.org>
Hi Andrew,
2.6.26-rc2-mm1 kernel panics on powerpc, while running ltp test over it.
I have attached the gdb output of the pc and lr registers. The patch
list_for_each_rcu-must-die-networking.patch points to changes made
to the same lines listed by the gdb output.
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc000000000481fa0
cpu 0x0: Vector: 300 (Data Access) at [c0000000eae37900]
pc: c000000000481fa0: .inet_create+0xb4/0x330
lr: c000000000413340: .__sock_create+0x190/0x280
sp: c0000000eae37b80
msr: 8000000000009032
dar: 0
dsisr: 40010000
current = 0xc0000000cd201500
paca = 0xc0000000007c3480
pid = 6462, comm = socket01
enter ? for help
[c0000000eae37c30] c000000000413340 .__sock_create+0x190/0x280
[c0000000eae37cf0] c0000000004137e0 .sys_socket+0x40/0x98
[c0000000eae37d90] c000000000438e18 .compat_sys_socketcall+0xc0/0x234
[c0000000eae37e30] c0000000000086b4 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000000000ff20484
SP (ffc8f770) is in userspace
0xc000000000481fa0 is in inet_create (net/ipv4/af_inet.c:290).
285 /* Look for the requested type/protocol pair. */
286 answer = NULL;
287 lookup_protocol:
288 err = -ESOCKTNOSUPPORT;
289 rcu_read_lock();
290 list_for_each_entry_rcu(answer, &inetsw[sock->type], list) {
291
292 /* Check the non-wild match. */
293 if (protocol == answer->protocol) {
294 if (protocol != IPPROTO_IP)
0xc000000000413340 is in __sock_create (net/socket.c:1171).
1166 goto out_release;
1167
1168 /* Now protected by module ref count */
1169 rcu_read_unlock();
1170
1171 err = pf->create(net, sock, protocol);
1172 if (err < 0)
1173 goto out_module_put;
1174
1175 /*
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* RE: linux 2.6 hangs at __delay function on Viretx 4 board
From: John Linn @ 2008-05-14 15:01 UTC (permalink / raw)
To: swamydp, linuxppc-embedded
In-Reply-To: <17222725.post@talk.nabble.com>
Hi Swamy,
I have seen this sometime before I think, but don't remember why.
I see that udelay depends on loops_per_jiffy, have you looked to see
what value it is? Maybe it's garbage and some large value?
Have you tried dumping the __log_buf to understand how far it got thru
booting the kernel before it got hung?
I assume you must be using xmd to load the image, you can also use it to
dump the buffer.
On another processor I have seen it get hung in the calibrate_delay call
from the kernel if the interrupts or timer aren't working, but haven't
ever seen that on the Powerpc.
Thanks,
John
-----Original Message-----
From: linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org] On
Behalf Of swamydp
Sent: Tuesday, May 13, 2008 9:29 PM
To: linuxppc-embedded@ozlabs.org
Subject: linux 2.6 hangs at __delay function on Viretx 4 board
I am trying to boot linux 2.6 on HITECH virtex 4(fx60) board. Linux
hangs at
address 0xc00045ec which is in the __udelay function. I am using EDK
9.2i
and gcc version 4.0.2 for compiling the kernel. The following is the
boot
message from the bootloader.=20
loaded at: 00400000 0054E19C
board data at: 0054C120 0054C19C
relocated to: 00404064 004040E0
zimage at: 00404E55 0054B5B4
avail ram: 0054F000 02000000
Linux/PPC load: console=3DttyS0,9600 console=3Dtty0 root=3D/dev/sda2
Uncompressing Linux...done.
Now booting the kernel
Any help is greatly appreciated. I have run out of ideas to fix this.
Thanks
swamy
--=20
View this message in context:
http://www.nabble.com/linux-2.6-hangs-at-__delay-function-on-Viretx-4-bo
ard-tp17222725p17222725.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 3/6] [WATCHDOG] mpc83xx_wdt: rename to mpc8xxx_wdt
From: Kumar Gala @ 2008-05-14 15:03 UTC (permalink / raw)
To: Chen Gong
Cc: Stephen Rothwell, linuxppc-dev, Wim Van Sebroeck, Wood Scott,
Tabi Timur
In-Reply-To: <58A20A281BAF1047B4EAE68DE5C0BDC2F16798@zch01exm21.fsl.freescale.net>
On May 13, 2008, at 10:53 PM, Chen Gong wrote:
>
>
>> -----Original Message-----
>> From: linuxppc-dev-bounces+b11801=freescale.com@ozlabs.org
>> [mailto:linuxppc-dev-bounces+b11801=freescale.com@ozlabs.org]
>> On Behalf Of Stephen Rothwell
>> Sent: 2008?5?14? 9:45
>> To: Anton Vorontsov
>> Cc: Wood Scott; linuxppc-dev@ozlabs.org; Wim Van Sebroeck; Tabi Timur
>> Subject: Re: [PATCH 3/6] [WATCHDOG] mpc83xx_wdt: rename to
>> mpc8xxx_wdt
>>
>> On Tue, 13 May 2008 18:14:59 +0400 Anton Vorontsov
>> <avorontsov@ru.mvista.com> wrote:
>>>
>>> Rename the driver because now we support some MPC86xx processors.
> What I want to know is that what about watchdog for booke(85xx) ?
what about it, its still there in the tree (booke_wdt.c). This driver
is for a SoC level watchdog that exists on 8xx, 83xx and 8610.
- k
^ 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