[PATCH] powerpc/kernel: Don't add disabled serial device
serial port nodes with the property status=disabled are not usable and so
avoid adding disabled port with the system.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
---
Based upon
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git(branch
master)
This patch is made to support Re-organizing P1020RDB P2020RDB dts. Creation
of Serial port node doesn't follow of_platform_device_create() way which takes
care case status = disabled.
arch/powerpc/kernel/legacy_serial.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/legacy_serial.c
b/arch/powerpc/kernel/legacy_serial.c
index c834757..26566ca 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -330,9 +330,11 @@ void __init find_legacy_serial_ports(void)
if (!parent)
continue;
if (of_match_node(legacy_serial_parents, parent) != NULL) {
- index = add_legacy_soc_port(np, np);
- if (index = 0 np == stdout)
- legacy_serial_console = index;
+ if (of_device_is_available(np)) {
+ index = add_legacy_soc_port(np, np);
+ if (index = 0 np == stdout)
+ legacy_serial_console = index;
+ }
}
of_node_put(parent);
}
--
1.7.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
Hi Gabriel, On Tue, Apr 05, 2011 at 01:52:59AM +0200, Gabriel Paubert wrote: I've had the following funny crashes on PPC machines, with cataleptic X server as a consequence: kernel: [drm] Setting GART location based on new memory map kernel: Oops: Exception in kernel mode, sig: 4 [#1] kernel: CHRP kernel: last sysfs file: /sys/devices/pci0001:01/0001:01:08.0/resource kernel: NIP: c05648fc LR: c0226f58 CTR: 0008 kernel: REGS: ddb53d20 TRAP: 0700 Not tainted (2.6.38) kernel: MSR: 00089032 EE,ME,IR,DR CR: 48044482 XER: kernel: TASK = ddab12b0[3040] 'Xorg' THREAD: ddb52000 kernel: GPR00: c0226f34 ddb53dd0 ddab12b0 c0509e6c kernel: GPR08: 28044488 101f3d8c bf8166b4 2c00 kernel: GPR16: 101b9458 1006f1a0 101ebe0c 0001 101ebe08 df9efc20 df9efc00 kernel: GPR24: c0591e54 80546440 ddacf660 df9efc00 c0506048 c0480210 00a0 df9ef800 kernel: NIP [c05648fc] platform_device_register_resndata+0x4/0xa4 kernel: LR [c0226f58] radeon_cp_init+0xd08/0x10c4 kernel: Call Trace: kernel: [ddb53dd0] [c0226f34] radeon_cp_init+0xce4/0x10c4 (unreliable) kernel: [ddb53df0] [c020801c] drm_ioctl+0x2c0/0x3e4 kernel: [ddb53eb0] [c0091264] do_vfs_ioctl+0x674/0x710 kernel: [ddb53f10] [c0091340] sys_ioctl+0x40/0x70 kernel: [ddb53f40] [c00111a8] ret_from_syscall+0x0/0x38 kernel: --- Exception: c01 at 0xfc54a78 kernel: LR = 0xfc549dc kernel: Instruction dump: kernel: 736f2e31 32002f75 73722f6c 69622f6c 6962786b 6c617669 65722e73 6f2e3132 kernel: 006c6962 786b6266 696c652e 736f2e31 002f7573 722f6c69 622f6c69 62786b62 kernel: ---[ end trace ed79daba161e31d9 ]--- As you can see, the processor is trying to execute ASCII strings like /usr/lib/libxkb and has trouble digesting them :-) The backtrace is actually missing radeon_cp_init_microcode and radeon_do_init_cp which are inlined inside radeon_cp_init. The trouble is that radeon_cp_init_microcode calls platform_device_register_simple which is a simple inline wrapper around platform_device_register_resndata, which happens to be already freed and overwritten with something looking like a list of filenames, since I have a non modular kernel. For now I have locally reverted 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 which simply added an _init_or_module section attribute to platform_device_register_resndata, and X is up again... Now it may be that it is the ioctl that does not have the right to do this. Actually I thought that the name radeon_cp that is registered there would appear somwhere under /sys (or /proc) but failed to find it... I don't know for sure, but it looks strange to me that an ioctl can register a device. But the fear for such code in the kernel made me choose not to squash 737a3bb941 into 44f28bdea094. So my POV is that if the maintainer of the radeon driver thinks registering the device is OK, reverting 737a3bb9416 is fine for me. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
2011/4/6 Uwe Kleine-König u.kleine-koe...@pengutronix.de: Hi Gabriel, On Tue, Apr 05, 2011 at 01:52:59AM +0200, Gabriel Paubert wrote: I've had the following funny crashes on PPC machines, with cataleptic X server as a consequence: kernel: [drm] Setting GART location based on new memory map kernel: Oops: Exception in kernel mode, sig: 4 [#1] kernel: CHRP kernel: last sysfs file: /sys/devices/pci0001:01/0001:01:08.0/resource kernel: NIP: c05648fc LR: c0226f58 CTR: 0008 kernel: REGS: ddb53d20 TRAP: 0700 Not tainted (2.6.38) kernel: MSR: 00089032 EE,ME,IR,DR CR: 48044482 XER: kernel: TASK = ddab12b0[3040] 'Xorg' THREAD: ddb52000 kernel: GPR00: c0226f34 ddb53dd0 ddab12b0 c0509e6c kernel: GPR08: 28044488 101f3d8c bf8166b4 2c00 kernel: GPR16: 101b9458 1006f1a0 101ebe0c 0001 101ebe08 df9efc20 df9efc00 kernel: GPR24: c0591e54 80546440 ddacf660 df9efc00 c0506048 c0480210 00a0 df9ef800 kernel: NIP [c05648fc] platform_device_register_resndata+0x4/0xa4 kernel: LR [c0226f58] radeon_cp_init+0xd08/0x10c4 kernel: Call Trace: kernel: [ddb53dd0] [c0226f34] radeon_cp_init+0xce4/0x10c4 (unreliable) kernel: [ddb53df0] [c020801c] drm_ioctl+0x2c0/0x3e4 kernel: [ddb53eb0] [c0091264] do_vfs_ioctl+0x674/0x710 kernel: [ddb53f10] [c0091340] sys_ioctl+0x40/0x70 kernel: [ddb53f40] [c00111a8] ret_from_syscall+0x0/0x38 kernel: --- Exception: c01 at 0xfc54a78 kernel: LR = 0xfc549dc kernel: Instruction dump: kernel: 736f2e31 32002f75 73722f6c 69622f6c 6962786b 6c617669 65722e73 6f2e3132 kernel: 006c6962 786b6266 696c652e 736f2e31 002f7573 722f6c69 622f6c69 62786b62 kernel: ---[ end trace ed79daba161e31d9 ]--- As you can see, the processor is trying to execute ASCII strings like /usr/lib/libxkb and has trouble digesting them :-) The backtrace is actually missing radeon_cp_init_microcode and radeon_do_init_cp which are inlined inside radeon_cp_init. The trouble is that radeon_cp_init_microcode calls platform_device_register_simple which is a simple inline wrapper around platform_device_register_resndata, which happens to be already freed and overwritten with something looking like a list of filenames, since I have a non modular kernel. For now I have locally reverted 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 which simply added an _init_or_module section attribute to platform_device_register_resndata, and X is up again... Now it may be that it is the ioctl that does not have the right to do this. Actually I thought that the name radeon_cp that is registered there would appear somwhere under /sys (or /proc) but failed to find it... I don't know for sure, but it looks strange to me that an ioctl can register a device. But the fear for such code in the kernel made me choose not to squash 737a3bb941 into 44f28bdea094. So my POV is that if the maintainer of the radeon driver thinks registering the device is OK, reverting 737a3bb9416 is fine for me. This is the old DRM driver for radeon, which relies on userspace to start X then calls the kernel to initialise the hardware. Due to this model, there is no device we can hang off (the PCI device might already be bound to fbdev), so we are forced to create a platform device to load the firmware. So its ugly, unless someone can suggest a better device to hang things off I don't know of another way. Dave. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/34] Make kernel build deterministic
* Artem Bityutskiy dedeki...@gmail.com wrote: On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote: On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote: Hi, this series makes it possible to build bit-identical kernel image and modules from identical sources. Of course the build is already deterministic in terms of behavior of the code, but the various timestamps embedded in the object files make it hard to compare two builds, for instance to verify that a makefile cleanup didn't accidentally change something. A prime example is /proc/config.gz, which has both a timestamp in the gzip header and a timestamp in the payload data. With this series applied, a script like this will produce identical kernels each time: Very nice stuff. Do you want to take the individual patches through one of your trees, or do you mind if the subsystem maintainers take them through theirs? But unfortunately, it is very easy to break this and for sure it'll be broken very soon. So additionally, I'd suggest: 1. Instrument checkpatch.pl and make it err or warn on timestamps. See the grandparent mail: checkpatch: Warn about usage of __DATE__, __TIME__ and __TIMESTAMP__ Thanks, Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/34] Make kernel build deterministic
* Michal Marek mma...@suse.cz wrote:
Hi,
this series makes it possible to build bit-identical kernel image and
modules from identical sources. Of course the build is already
deterministic in terms of behavior of the code, but the various
timestamps embedded in the object files make it hard to compare two
builds, for instance to verify that a makefile cleanup didn't
accidentally change something. A prime example is /proc/config.gz, which
has both a timestamp in the gzip header and a timestamp in the payload
data. With this series applied, a script like this will produce
identical kernels each time:
#!/bin/bash
rm -rf /dev/shm/{source,build}{,1,2}
export KCONFIG_NOTIMESTAMP=1
export KBUILD_BUILD_TIMESTAMP='Sun May 1 12:00:00 CEST 2011'
export KBUILD_BUILD_USER=user
export KBUILD_BUILD_HOST=host
export ROOT_DEV=FLOPPY
for i in 1 2; do
mkdir /dev/shm/source
# randomize the inode order just for fun
git ls-tree -r -z --name-only HEAD | sort -R -z | xargs -0 \
cp --parents --target=/dev/shm/source
pushd /dev/shm/source
mkdir /dev/shm/build
/dev/shm/build/all.config
for opt in GCOV_KERNEL UBIFS_FS_DEBUG; do
echo # CONFIG_$opt is not set /dev/shm/build/all.config
done
make O=/dev/shm/build KCONFIG_ALLCONFIG=1 allmodconfig
make O=/dev/shm/build -j64
popd
mv /dev/shm/source /dev/shm/source$i
mv /dev/shm/build /dev/shm/build$i
done
diff -rq /dev/shm/build{1,2}
Nice!
Acked-by: Ingo Molnar mi...@elte.hu
Unfortunatelly, this cannot be used to validate indentation-only
patches, even if CONFIG_DEBUG_INFO is turned off. This is because of the
__FILE__ and __LINE__ macros used in many places. For the same reason,
the source and build directory needs to be the same, otherwise the
results will differ.
Nor can it be used to validate untrusted patches in general: a subtle change
might be introduced in a piece of code that is dependent on a .config detail
that is off for that particular build.
But in the common case it's nice to be able to have deterministic/reproducable
builds.
Thanks,
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/34] Make kernel build deterministic
On 5.4.2011 21:24, Artem Bityutskiy wrote: On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote: On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote: Hi, this series makes it possible to build bit-identical kernel image and modules from identical sources. Of course the build is already deterministic in terms of behavior of the code, but the various timestamps embedded in the object files make it hard to compare two builds, for instance to verify that a makefile cleanup didn't accidentally change something. A prime example is /proc/config.gz, which has both a timestamp in the gzip header and a timestamp in the payload data. With this series applied, a script like this will produce identical kernels each time: Very nice stuff. Do you want to take the individual patches through one of your trees, or do you mind if the subsystem maintainers take them through theirs? But unfortunately, it is very easy to break this and for sure it'll be broken very soon. I'm not so pessimistic. 34 patches and 57 files might sound like a lot, but given that this has been accumulating since day one, the cleanup should last for some time. So additionally, I'd suggest: 1. Instrument checkpatch.pl and make it err or warn on timestamps. This is patch 34/34 in this series: https://lkml.org/lkml/2011/4/5/198 2. Probably instrument linux-next to rise a warning when people break this. I'm not sure if Stephen has that much spare time, and I don't think it is necessary. I think the checkpatch check is sufficient and I'll check myself occasionally. Michal ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/34] Make kernel build deterministic
On 5.4.2011 17:49, Greg KH wrote: Very nice stuff. Do you want to take the individual patches through one of your trees, or do you mind if the subsystem maintainers take them through theirs? I'd leave it up to the subsystem maintainers. I'll check once the merge window opens and send the remaining patches to Linus directly. Michal ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/34] Make kernel build deterministic
On Wed, 2011-04-06 at 11:07 +0200, Michal Marek wrote: So additionally, I'd suggest: 1. Instrument checkpatch.pl and make it err or warn on timestamps. This is patch 34/34 in this series: https://lkml.org/lkml/2011/4/5/198 Yeah, great, did not notice, thanks! 2. Probably instrument linux-next to rise a warning when people break this. I'm not sure if Stephen has that much spare time, and I don't think it is necessary. I think the checkpatch check is sufficient and I'll check myself occasionally. Yes, that's fine, I just wanted to speak this out - there is a probability that someone gets excited and creates some instrumentation to kbuild to automatically detect bad things and then Stephen could easily use that. WRT not necessary - well, I think it is always better to cut bad things before they are merged, rather than afterwards. But anyway, let's forget about this. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH] powerpc/book3e: Fix CPU feature handling on e5500
On Apr 6, 2011, at 12:41 AM, Stephen Rothwell wrote: Hi Kumar, On Wed, 6 Apr 2011 00:29:32 -0500 Kumar Gala ga...@kernel.crashing.org wrote: * I'm concerned if its ok to assume 'enum' can handle a 64-bit mask or not. I'm assuming this is the reason that we use a #define on __powerpc64__ enums are *ints* and therefore 32 bit. gcc can cope, but warns about it (I think). So we must use the #define if any of the included bits are above 2^32. Thanks, I'll rework the patch to use #define. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/book3e: Fix CPU feature handling on 64-bit e5500
The CPU_FTRS_POSSIBLE and CPU_FTRS_ALWAYS defines did not encompass
e5500 CPU features when built for 64-bit. This causes issues with
cpu_has_feature() as it utilizes the POSSIBLE ALWAYS defines as part
of its check.
Create a unique CPU_FTRS_E5500 (as its different from CPU_FTRS_E500MC),
created a new group for 64-bit Book3e based CPUs and add CPU_FTRS_E5500
to that group.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* This patch is intened to fix some issues and I'd like to see it in v2.6.39
- k
arch/powerpc/include/asm/cputable.h | 14 ++
arch/powerpc/kernel/cputable.c |2 +-
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index be3cdf9..9028a9e 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -386,6 +386,10 @@ extern const char *powerpc_base_platform;
CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
CPU_FTR_DBELL)
+#define CPU_FTRS_E5500 (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
+ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
+ CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
+ CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD)
#define CPU_FTRS_GENERIC_32(CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN)
/* 64-bit CPUs */
@@ -435,11 +439,15 @@ extern const char *powerpc_base_platform;
#define CPU_FTRS_COMPATIBLE(CPU_FTR_USE_TB | CPU_FTR_PPCAS_ARCH_V2)
#ifdef __powerpc64__
+#ifdef CONFIG_PPC_BOOK3E
+#define CPU_FTRS_POSSIBLE (CPU_FTRS_E5500)
+#else
#define CPU_FTRS_POSSIBLE \
(CPU_FTRS_POWER3 | CPU_FTRS_RS64 | CPU_FTRS_POWER4 |\
CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | CPU_FTRS_POWER6 | \
CPU_FTRS_POWER7 | CPU_FTRS_CELL | CPU_FTRS_PA6T | \
CPU_FTR_1T_SEGMENT | CPU_FTR_VSX)
+#endif
#else
enum {
CPU_FTRS_POSSIBLE =
@@ -473,16 +481,21 @@ enum {
#endif
#ifdef CONFIG_E500
CPU_FTRS_E500 | CPU_FTRS_E500_2 | CPU_FTRS_E500MC |
+ CPU_FTRS_E5500 |
#endif
0,
};
#endif /* __powerpc64__ */
#ifdef __powerpc64__
+#ifdef CONFIG_PPC_BOOK3E
+#define CPU_FTRS_ALWAYS(CPU_FTRS_E5500)
+#else
#define CPU_FTRS_ALWAYS\
(CPU_FTRS_POWER3 CPU_FTRS_RS64 CPU_FTRS_POWER4 \
CPU_FTRS_PPC970 CPU_FTRS_POWER5 CPU_FTRS_POWER6\
CPU_FTRS_POWER7 CPU_FTRS_CELL CPU_FTRS_PA6T CPU_FTRS_POSSIBLE)
+#endif
#else
enum {
CPU_FTRS_ALWAYS =
@@ -513,6 +526,7 @@ enum {
#endif
#ifdef CONFIG_E500
CPU_FTRS_E500 CPU_FTRS_E500_2 CPU_FTRS_E500MC
+ CPU_FTRS_E5500
#endif
CPU_FTRS_POSSIBLE,
};
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index c9b68d0..b9602ee 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1973,7 +1973,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pvr_mask = 0x,
.pvr_value = 0x8024,
.cpu_name = e5500,
- .cpu_features = CPU_FTRS_E500MC,
+ .cpu_features = CPU_FTRS_E5500,
.cpu_user_features = COMMON_USER_BOOKE,
.mmu_features = MMU_FTR_TYPE_FSL_E | MMU_FTR_BIG_PHYS
|
MMU_FTR_USE_TLBILX,
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: halt/reset on assert?
Hi Andreas - that's great; thanks. I'm on 2.4.4, which doesn't have BUG_ON. The right way for 2.4.4 turns out to be #define MY_ASSERT(expr) if(!(expr)) BUG() -Evan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/1] RapidIO: Add IDT CPS-1432 switch definitions
Signed-off-by: Alexandre Bounine alexandre.boun...@idt.com Cc: Matt Porter mpor...@kernel.crashing.org Cc: Kumar Gala ga...@kernel.crashing.org --- drivers/rapidio/switches/idt_gen2.c |1 + include/linux/rio_ids.h |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/rapidio/switches/idt_gen2.c b/drivers/rapidio/switches/idt_gen2.c index 095016a..ac2701b 100644 --- a/drivers/rapidio/switches/idt_gen2.c +++ b/drivers/rapidio/switches/idt_gen2.c @@ -418,3 +418,4 @@ DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTCPS1848, idtg2_switch_init); DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTCPS1616, idtg2_switch_init); DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTVPS1616, idtg2_switch_init); DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTSPS1616, idtg2_switch_init); +DECLARE_RIO_SWITCH_INIT(RIO_VID_IDT, RIO_DID_IDTCPS1432, idtg2_switch_init); diff --git a/include/linux/rio_ids.h b/include/linux/rio_ids.h index 7410d33..0cee015 100644 --- a/include/linux/rio_ids.h +++ b/include/linux/rio_ids.h @@ -35,6 +35,7 @@ #define RIO_DID_IDTCPS6Q 0x035f #define RIO_DID_IDTCPS10Q 0x035e #define RIO_DID_IDTCPS1848 0x0374 +#define RIO_DID_IDTCPS1432 0x0375 #define RIO_DID_IDTCPS1616 0x0379 #define RIO_DID_IDTVPS1616 0x0377 #define RIO_DID_IDTSPS1616 0x0378 -- 1.7.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 2/5]arch:powerpc:sysdev:Makefile Remove unused config in the Makefile.
On Tue, Apr 5, 2011 at 11:15 AM, Scott Wood scottw...@freescale.com wrote: On Tue, 5 Apr 2011 09:58:19 -0700 Justin P. Mattock justinmatt...@gmail.com wrote: The patch below removes an unused config variable found by using a kernel cleanup script. Note: I did try to cross compile these but hit erros while doing so.. (gcc is not setup to cross compile) and am unsure if anymore needs to be done. Please have a look if/when anybody has free time. Signed-off-by: Justin P. Mattock justinmatt...@gmail.com CC: Benjamin Herrenschmidt b...@kernel.crashing.org CC: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/sysdev/Makefile | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile index 1e0c933..243b6ad 100644 --- a/arch/powerpc/sysdev/Makefile +++ b/arch/powerpc/sysdev/Makefile @@ -18,7 +18,6 @@ obj-$(CONFIG_FSL_PMC) += fsl_pmc.o obj-$(CONFIG_FSL_LBC) += fsl_lbc.o obj-$(CONFIG_FSL_GTM) += fsl_gtm.o obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o -obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o obj-$(CONFIG_FSL_RIO) += fsl_rio.o obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o Those files do exist, and aren't pulled in by any other means I can see. It was introduced by commit 6db92cc9d07db9f713da8554b4bcdfc8e54ad386, whose changelog says: Drivers can do the following in Kconfig to use these APIs select FSL_85XX_CACHE_SRAM if MPC85xx Now, the absence of such a kconfig option[1] is a problem, but I don't think outright removal (labelled trivial cleanup) is appropriate, unless nobody fixes it after the problem is pointed out. And if it is removed, the files should go with it. -Scott [1] and of any drivers that select it, though this was added fairly recently -- perhaps such a driver change is on its way? ahh.. so the: fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o is still in use even though FSL_85XX_CACHE_SRAM is not really used, but really is used!! but might be wrong with this. -- Justin P. Mattock ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 2/5]arch:powerpc:sysdev:Makefile Remove unused config in the Makefile.
On Wed, 6 Apr 2011 08:07:58 -0700 Justin Mattock justinmatt...@gmail.com wrote: ahh.. so the: fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o is still in use even though FSL_85XX_CACHE_SRAM is not really used, but really is used!! but might be wrong with this. More like there are plans to use it, or possibly out-of-tree users. We should prod people a bit to submit the driver patches that use this before we just yank it out. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 2/5]arch:powerpc:sysdev:Makefile Remove unused config in the Makefile.
On Wed, Apr 6, 2011 at 9:03 AM, Scott Wood scottw...@freescale.com wrote: On Wed, 6 Apr 2011 08:07:58 -0700 Justin Mattock justinmatt...@gmail.com wrote: ahh.. so the: fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o is still in use even though FSL_85XX_CACHE_SRAM is not really used, but really is used!! but might be wrong with this. More like there are plans to use it, or possibly out-of-tree users. We should prod people a bit to submit the driver patches that use this before we just yank it out. -Scott well if this is going to be used for something down the line, then best leave it in.. -- Justin P. Mattock ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
known working sata_sil24.c setup on powerpc platforms?
Hello, after investigating problems with sata_sil24.c on a freescale p2020 soc, I wonder if this driver works on powerpc at all? Does anyone know of a working setup of sata_sil24 on a big endian powerpc system? Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] RapidIO/mpc85xx: Fix possible mport registration problems.
Fix possible problem with mport registration left non cleared after
fsl_rio_setup() exits on link error. Abort mport initialization
if registration failed.
This patch is applicable to 2.6.39-rc1 only. The problem does not exists
for earlier versions.
Signed-off-by: Alexandre Bounine alexandre.boun...@idt.com
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: Matt Porter mpor...@kernel.crashing.org
Cc: Li Yang le...@freescale.com
Cc: Thomas Moll thomas.m...@sysgo.com
---
arch/powerpc/sysdev/fsl_rio.c |4 +++-
drivers/rapidio/rio.c |5 +++--
include/linux/rio.h |2 +-
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index 14232d5..4979853 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -1457,7 +1457,6 @@ int fsl_rio_setup(struct platform_device *dev)
port-ops = ops;
port-priv = priv;
port-phys_efptr = 0x100;
- rio_register_mport(port);
priv-regs_win = ioremap(regs.start, regs.end - regs.start + 1);
rio_regs_win = priv-regs_win;
@@ -1504,6 +1503,9 @@ int fsl_rio_setup(struct platform_device *dev)
dev_info(dev-dev, RapidIO Common Transport System size: %d\n,
port-sys_size ? 65536 : 256);
+ if (rio_register_mport(port))
+ goto err;
+
if (port-host_deviceid = 0)
out_be32(priv-regs_win + RIO_GCCSR, RIO_PORT_GEN_HOST |
RIO_PORT_GEN_MASTER | RIO_PORT_GEN_DISCOVERED);
diff --git a/drivers/rapidio/rio.c b/drivers/rapidio/rio.c
index c29719c..86c9a09 100644
--- a/drivers/rapidio/rio.c
+++ b/drivers/rapidio/rio.c
@@ -1171,16 +1171,17 @@ static int rio_hdid_setup(char *str)
__setup(riohdid=, rio_hdid_setup);
-void rio_register_mport(struct rio_mport *port)
+int rio_register_mport(struct rio_mport *port)
{
if (next_portid = RIO_MAX_MPORTS) {
pr_err(RIO: reached specified max number of mports\n);
- return;
+ return 1;
}
port-id = next_portid++;
port-host_deviceid = rio_get_hdid(port-id);
list_add_tail(port-node, rio_mports);
+ return 0;
}
EXPORT_SYMBOL_GPL(rio_local_get_device_id);
diff --git a/include/linux/rio.h b/include/linux/rio.h
index 4e37a7c..4d50611 100644
--- a/include/linux/rio.h
+++ b/include/linux/rio.h
@@ -396,7 +396,7 @@ union rio_pw_msg {
};
/* Architecture and hardware-specific functions */
-extern void rio_register_mport(struct rio_mport *);
+extern int rio_register_mport(struct rio_mport *);
extern int rio_open_inb_mbox(struct rio_mport *, void *, int, int);
extern void rio_close_inb_mbox(struct rio_mport *, int);
extern int rio_open_outb_mbox(struct rio_mport *, void *, int, int);
--
1.7.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sdhc/mpc8536 - SDCard always detected like read-only
I will try address the issue in details.
When I insert the SDCard, the same is detect like read-only:
mmcblk0: mmc0:b368 NCard 966 MiB (ro)
mmcblk0:
mmc0: starting CMD18 arg flags 00b5
mmc0: blksz 512 blocks 8 flags 0200 tsac 100 ms nsac 0
mmc0: CMD12 arg flags 049d
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0001
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x000a
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0001
mmc0: req done (CMD18): 0: 0900
mmc0: 4096 bytes transferred: 0
mmc0: (CMD12): 0: 0b00
p1
So, I just can mount the filesystem read-only. I can read the fat32
without problems.
I tested your sugestion. I used sdhci,wp-inverted in my dtb. This
changed the behavior. Now the SDCard is detected without the read-only
flag:
mmcblk0: mmc0:b368 NCard 966 MiB
mmcblk0:
mmc0: starting CMD18 arg flags 00b5
mmc0: blksz 512 blocks 8 flags 0200 tsac 100 ms nsac 0
mmc0: CMD12 arg flags 049d
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0001
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x000a
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0001
mmc0: req done (CMD18): 0: 0900
mmc0: 4096 bytes transferred: 0
mmc0: (CMD12): 0: 0b00
p1
And, I can mount a rw filesystem:
#mount /dev/mmcblock1 /mnt
#cat /proc/mounts
...
/dev/mmcblock1 /mnt vfat
rw,relatime,fmask=,dmask=,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro
0 0
...
So, I can copy files to the mounted SDCard. But, When I try to umount I
see the following error mensagens:
#cp /etc/shadow /mnt
#ls /mnt
shadow
#umount /mnt
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 5944, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 5944
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 5936, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 5936
Buffer I/O error on device mmcblk0p1, logical block 3888
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 2049, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 2049
Buffer I/O error on device mmcblk0p1, logical block 1
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 2080, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 2080
...
I think I need the sdhci,wp-inverted in my dtb. But, it appears that
more something is necessary.
Has someone faced this situation?
Thanks by the help until here.
Regards,
Moratelli
Em Qua, 2011-04-06 às 01:48 +0200, Wolfram Sang escreveu:
sdhci@2e000 {
compatible = fsl,mpc8536-esdhc, fsl,esdhc;
reg = 0x2e000 0x1000;
interrupts = 72 0x2;
interrupt-parent = mpic;
/* Filled in by U-Boot */
clock-frequency = 0;
};
Hmm, I am not too familiar with those SoCs, yet some 83xx needed
sdhci,wp-inverted;
here. Maybe yours, too? Would fit the symptoms.
Regards,
Wolfram
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: known working sata_sil24.c setup on powerpc platforms?
On 04/06/2011 01:48 PM, Moffett, Kyle D wrote: On Apr 06, 2011, at 13:00, Leon Woestenberg wrote: after investigating problems with sata_sil24.c on a freescale p2020 soc, I wonder if this driver works on powerpc at all? Does anyone know of a working setup of sata_sil24 on a big endian powerpc system? Our P2020 boards work fine with legacy PCI interrupts (I think it's a sil3124 over PCI-E); the only deficiency is that MSI does not seem to work. I know our MSI *does* work in general because we have an Intel 82571EB chipset also attached via PCI-E with working MSI. We've definitely had issues with sata_sil24 + MSI, also... sata_sil24 does work on big endian in general. Jeff ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/book3e: Fix CPU feature handling on 64-bit e5500
On Wed, 6 Apr 2011 07:29:03 -0500 Kumar Gala ga...@kernel.crashing.org wrote: diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h index be3cdf9..9028a9e 100644 --- a/arch/powerpc/include/asm/cputable.h +++ b/arch/powerpc/include/asm/cputable.h @@ -386,6 +386,10 @@ extern const char *powerpc_base_platform; CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \ CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \ CPU_FTR_DBELL) +#define CPU_FTRS_E5500 (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \ + CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \ E5500 cannot doze or nap in the way meant by existing code (MSR[WE]). -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: known working sata_sil24.c setup on powerpc platforms?
On Apr 06, 2011, at 13:00, Leon Woestenberg wrote: after investigating problems with sata_sil24.c on a freescale p2020 soc, I wonder if this driver works on powerpc at all? Does anyone know of a working setup of sata_sil24 on a big endian powerpc system? Our P2020 boards work fine with legacy PCI interrupts (I think it's a sil3124 over PCI-E); the only deficiency is that MSI does not seem to work. I know our MSI *does* work in general because we have an Intel 82571EB chipset also attached via PCI-E with working MSI. Cheers, Kyle Moffett ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Combining multiple NAND MTDs
On Tue, 5 Apr 2011 16:35:10 -0700 Barry G mr.sc...@gmail.com wrote: I want to run UBIFS on the combined 2 gigs of flash. Whats the best way to do this? I tried using the mtdconcat stuff and wrote a small driver but I am not sure how to populate the mtd_info structure since do_probe_map doesn't work with NAND AFAIK. I see that fsl_elbc_select_chip says hardware does not seem to support this. Not sure if this is related. It's not related -- it's talking about a single physical chip with multiple chip selects, not a logical concatenation of multiple separate devices. I see some comments in mtd-physmap.txt about using multiple reg ranges? Does this work with NAND? No. I don't know of an out-of-the-box configuration step you can take to do mtdconcat of eLBC NAND, but you could try creating a custom map driver that glues things together as you wish. Or if you want to be more ambitious, perhaps a kernel command line (or other dynamic config) option that lets you glue arbitrary MTD devices together. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: known working sata_sil24.c setup on powerpc platforms?
Hello Jeff, all, On Wed, Apr 6, 2011 at 8:12 PM, Jeff Garzik j...@garzik.org wrote: On 04/06/2011 01:48 PM, Moffett, Kyle D wrote: On Apr 06, 2011, at 13:00, Leon Woestenberg wrote: after investigating problems with sata_sil24.c on a freescale p2020 soc, I wonder if this driver works on powerpc at all? Does anyone know of a working setup of sata_sil24 on a big endian powerpc system? Our P2020 boards work fine with legacy PCI interrupts (I think it's a sil3124 over PCI-E); the only deficiency is that MSI does not seem to work. We've definitely had issues with sata_sil24 + MSI, also... sata_sil24 does work on big endian in general. On my system, I have the contrary to Kyle's experience (thanks for sharing). PowerPC P2020RDB vanilla 2.6.38 Sil3132 on mini-PCI Express card Enabling msi gets me further than disabling it (default). modprobe sata_sil [8.834613] sata_sil24 0001:03:00.0: version 1.1 [8.885581] scsi0 : sata_sil24 [8.901420] scsi1 : sata_sil24 [8.904642] ata1: SATA max UDMA/100 host m128@0xc000 port 0xc0004000 irq 16 [8.911961] ata2: SATA max UDMA/100 host m128@0xc000 port 0xc0006000 irq 16 [ 11.095127] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 14.906986] eth0: no IPv6 routers present [ 16.099016] ata1.00: qc timeout (cmd 0xec) [ 16.103128] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 18.299050] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 28.303026] ata1.00: qc timeout (cmd 0xec) [ 28.307139] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 28.313233] ata1: limiting SATA link speed to 1.5 Gbps [ 30.523059] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 10) modprobe sata_sil msi=1 [ 92.984120] sata_sil24 0001:03:00.0: version 1.1 [ 92.988897] irq: irq 0 on host /soc@ffe0/msi@41600 mapped to virtual irq 41 [ 92.996229] sata_sil24 0001:03:00.0: Using MSI [ 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering [ 93.011628] scsi2 : sata_sil24 [ 93.022463] scsi3 : sata_sil24 [ 93.025695] ata3: SATA max UDMA/100 host m128@0xc000 port 0xc0004000 irq 41 [ 93.033023] ata4: SATA max UDMA/100 host m128@0xc000 port 0xc0006000 irq 41 [ 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag -84148995 sactive 0x0) [ 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max UDMA/133 [ 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth 31/32) [ 95.230905] ata3.00: configured for UDMA/100 [ 95.235399] scsi 2:0:0:0: Direct-Access ATA INTEL SSDSA2M080 2CV1 PQ: 0 ANSI: 5 [ 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0 [ 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB) [ 95.260219] sd 2:0:0:0: [sda] Write Protect is off [ 95.265063] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 95.270500] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 95.283779] sda: sda1 sda2 sda3 sda4 [ 95.289482] sd 2:0:0:0: [sda] Attached SCSI disk [ 95.965897] EXT3-fs: barriers not enabled [ 95.977279] kjournald starting. Commit interval 5 seconds [ 95.983296] EXT3-fs (sda2): using internal journal [ 95.988143] EXT3-fs (sda2): recovery complete [ 95.992504] EXT3-fs (sda2): mounted filesystem with writeback data mode [ 96.111587] NTFS volume version 3.1. [ 97.331005] ata4: SATA link down (SStatus 0 SControl 0) root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=1000 1000+0 records in 1000+0 records out 4096000 bytes (4.1 MB) copied, 0.0315629 s, 130 MB/s root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=1 1+0 records in 1+0 records out 4096 bytes (41 MB) copied, 0.471802 s, 86.8 MB/s root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=10 That stalls, I see the controller fail. See dmesg below: ^C^Cdd: reading `/dev/sda': Input/output error 51804+0 records in 51804+0 records out 212189184 bytes (212 MB) copied, 85.6537 s, 2.5 MB/s dd: closing input file `/dev/sda': Bad file descriptor [ 92.984120] sata_sil24 0001:03:00.0: version 1.1 [ 92.988897] irq: irq 0 on host /soc@ffe0/msi@41600 mapped to virtual irq 41 [ 92.996229] sata_sil24 0001:03:00.0: Using MSI [ 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering [ 93.011628] scsi2 : sata_sil24 [ 93.022463] scsi3 : sata_sil24 [ 93.025695] ata3: SATA max UDMA/100 host m128@0xc000 port 0xc0004000 irq 41 [ 93.033023] ata4: SATA max UDMA/100 host m128@0xc000 port 0xc0006000 irq 41 [ 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag -84148995 sactive 0x0) [ 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max UDMA/133 [ 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth 31/32) [ 95.230905] ata3.00: configured for UDMA/100 [ 95.235399] scsi 2:0:0:0:
Using dmaengine on Freescale P2020 RDB
All, I have a Freescale P2020 Reference Design Board. I am investigating the possibility of using the dmaengine capability in the 2.6.32.13 kernel to transfer data from memory out onto the PCIe bus. As a first step, I thought I would try the DMA test client (dmatest.ko) to make sure the dmaengine was functioning. I know this doesn't transfer anything over PCIe but only transfers from one memory buffer to another, but I figured I need to get this working first. Anyway I built dmatest.ko and ran it (with insmod), and discovered it didn't do anything. I added some printk's to the kernel to investigate what was going on and I found that all attempts to find a channel within dma_request_channel were unsuccessful. Three of the channels were not used because they were already publicly allocated. One channel was not used because it didn't have DMA_MEMCPY capability. Here are my questions then: 1. Is the dmaengine the appropriate method to use for transferring data from memory out onto the PCIe bus? 2. If dmaengine is correct, what can I do to free up a channel for my own use? Thank you. Chuck ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Using dmaengine on Freescale P2020 RDB
On Wed, Apr 06, 2011 at 12:40:58PM -0700, Chuck Ketcham wrote: All, I have a Freescale P2020 Reference Design Board. I am investigating the possibility of using the dmaengine capability in the 2.6.32.13 kernel to transfer data from memory out onto the PCIe bus. As a first step, I thought I would try the DMA test client (dmatest.ko) to make sure the dmaengine was functioning. I know this doesn't transfer anything over PCIe but only transfers from one memory buffer to another, but I figured I need to get this working first. Anyway I built dmatest.ko and ran it (with insmod), and discovered it didn't do anything. I added some printk's to the kernel to investigate what was going on and I found that all attempts to find a channel within dma_request_channel were unsuccessful. Three of the channels were not used because they were already publicly allocated. One channel was not used because it didn't have DMA_MEMCPY capability. Here are my questions then: 1. Is the dmaengine the appropriate method to use for transferring data from memory out onto the PCIe bus? 2. If dmaengine is correct, what can I do to free up a channel for my own use? I use the Freescale DMA engine to transfer lots of data out to PCI, on an 8349EA chip. The P2020 DMA engine uses the same driver. I hunch you have enabled CONFIG_NET_DMA, which will claim the channels. You should disable it to use the devices for other uses. If you want an example of using the DMA engine to transfer from DDR memory to the PowerPC local bus, search the mailing list archives for CARMA Board Drivers (RFCv7 was the latest posting). Transferring from DDR to PCI works exactly the same way. Hope it helps, Ira ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Using dmaengine on Freescale P2020 RDB
Ira,
Thanks for the reference to the CARMA drivers. I will have to take a look at
that.
In my case, CONFIG_NET_DMA is not enabled. However, I did notice the following
entry in my p2020rdb.dts file that may have something to do with dma channels
being allocated -- can anyone interpret this?:
dma@21300 {
#address-cells = 1;
#size-cells = 1;
compatible = fsl,eloplus-dma;
reg = 0x21300 0x4;
ranges = 0x0 0x21100 0x200;
cell-index = 0;
dma-channel@0 {
compatible = fsl,eloplus-dma-channel;
reg = 0x0 0x80;
cell-index = 0;
interrupt-parent = mpic;
interrupts = 20 2;
};
dma-channel@80 {
compatible = fsl,eloplus-dma-channel;
reg = 0x80 0x80;
cell-index = 1;
interrupt-parent = mpic;
interrupts = 21 2;
};
dma-channel@100 {
compatible = fsl,eloplus-dma-channel;
reg = 0x100 0x80;
cell-index = 2;
interrupt-parent = mpic;
interrupts = 22 2;
};
dma-channel@180 {
compatible = fsl,eloplus-dma-channel;
reg = 0x180 0x80;
cell-index = 3;
interrupt-parent = mpic;
interrupts = 23 2;
};
};
--- On Wed, 4/6/11, Ira W. Snyder i...@ovro.caltech.edu wrote:
From: Ira W. Snyder i...@ovro.caltech.edu
Subject: Re: Using dmaengine on Freescale P2020 RDB
To: Chuck Ketcham chuckk2...@yahoo.com
Cc: linuxppc-dev@lists.ozlabs.org
Date: Wednesday, April 6, 2011, 1:10 PM
On Wed, Apr 06, 2011 at 12:40:58PM
-0700, Chuck Ketcham wrote:
All,
I have a Freescale P2020 Reference Design Board.
I am investigating the possibility of using the dmaengine
capability in the 2.6.32.13 kernel to transfer data from
memory out onto the PCIe bus. As a first step, I
thought I would try the DMA test client (dmatest.ko) to make
sure the dmaengine was functioning. I know this
doesn't transfer anything over PCIe but only transfers from
one memory buffer to another, but I figured I need to get
this working first. Anyway I built dmatest.ko and ran
it (with insmod), and discovered it didn't do
anything. I added some printk's to the kernel to
investigate what was going on and I found that all attempts
to find a channel within dma_request_channel were
unsuccessful. Three of the channels were not used
because they were already publicly allocated. One
channel was not used because it didn't have DMA_MEMCPY
capability.
Here are my questions then:
1. Is the dmaengine the appropriate method to use for
transferring data from memory out onto the PCIe bus?
2. If dmaengine is correct, what can I do to free up a
channel for my own use?
I use the Freescale DMA engine to transfer lots of data out
to PCI, on
an 8349EA chip. The P2020 DMA engine uses the same driver.
I hunch you have enabled CONFIG_NET_DMA, which will claim
the channels.
You should disable it to use the devices for other uses.
If you want an example of using the DMA engine to transfer
from DDR
memory to the PowerPC local bus, search the mailing list
archives for
CARMA Board Drivers (RFCv7 was the latest posting).
Transferring from
DDR to PCI works exactly the same way.
Hope it helps,
Ira
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
On Wed, Apr 06, 2011 at 06:46:55PM +1000, Dave Airlie wrote: 2011/4/6 Uwe Kleine-König u.kleine-koe...@pengutronix.de: Hi Gabriel, On Tue, Apr 05, 2011 at 01:52:59AM +0200, Gabriel Paubert wrote: I've had the following funny crashes on PPC machines, with cataleptic X server as a consequence: kernel: [drm] Setting GART location based on new memory map kernel: Oops: Exception in kernel mode, sig: 4 [#1] kernel: CHRP kernel: last sysfs file: /sys/devices/pci0001:01/0001:01:08.0/resource kernel: NIP: c05648fc LR: c0226f58 CTR: 0008 kernel: REGS: ddb53d20 TRAP: 0700 Not tainted (2.6.38) kernel: MSR: 00089032 EE,ME,IR,DR CR: 48044482 XER: kernel: TASK = ddab12b0[3040] 'Xorg' THREAD: ddb52000 kernel: GPR00: c0226f34 ddb53dd0 ddab12b0 c0509e6c kernel: GPR08: 28044488 101f3d8c bf8166b4 2c00 kernel: GPR16: 101b9458 1006f1a0 101ebe0c 0001 101ebe08 df9efc20 df9efc00 kernel: GPR24: c0591e54 80546440 ddacf660 df9efc00 c0506048 c0480210 00a0 df9ef800 kernel: NIP [c05648fc] platform_device_register_resndata+0x4/0xa4 kernel: LR [c0226f58] radeon_cp_init+0xd08/0x10c4 kernel: Call Trace: kernel: [ddb53dd0] [c0226f34] radeon_cp_init+0xce4/0x10c4 (unreliable) kernel: [ddb53df0] [c020801c] drm_ioctl+0x2c0/0x3e4 kernel: [ddb53eb0] [c0091264] do_vfs_ioctl+0x674/0x710 kernel: [ddb53f10] [c0091340] sys_ioctl+0x40/0x70 kernel: [ddb53f40] [c00111a8] ret_from_syscall+0x0/0x38 kernel: --- Exception: c01 at 0xfc54a78 kernel: LR = 0xfc549dc kernel: Instruction dump: kernel: 736f2e31 32002f75 73722f6c 69622f6c 6962786b 6c617669 65722e73 6f2e3132 kernel: 006c6962 786b6266 696c652e 736f2e31 002f7573 722f6c69 622f6c69 62786b62 kernel: ---[ end trace ed79daba161e31d9 ]--- As you can see, the processor is trying to execute ASCII strings like /usr/lib/libxkb and has trouble digesting them :-) The backtrace is actually missing radeon_cp_init_microcode and radeon_do_init_cp which are inlined inside radeon_cp_init. The trouble is that radeon_cp_init_microcode calls platform_device_register_simple which is a simple inline wrapper around platform_device_register_resndata, which happens to be already freed and overwritten with something looking like a list of filenames, since I have a non modular kernel. For now I have locally reverted 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 which simply added an _init_or_module section attribute to platform_device_register_resndata, and X is up again... Now it may be that it is the ioctl that does not have the right to do this. Actually I thought that the name radeon_cp that is registered there would appear somwhere under /sys (or /proc) but failed to find it... I don't know for sure, but it looks strange to me that an ioctl can register a device. But the fear for such code in the kernel made me choose not to squash 737a3bb941 into 44f28bdea094. So my POV is that if the maintainer of the radeon driver thinks registering the device is OK, reverting 737a3bb9416 is fine for me. This is the old DRM driver for radeon, which relies on userspace to start X then calls the kernel to initialise the hardware. Due to this model, there is no device we can hang off (the PCI device might already be bound to fbdev), so we are forced to create a platform device to load the firmware. So its ugly, unless someone can suggest a better device to hang things off I don't know of another way. The probem is that, at least on one of my machines, the new driver does not work: the system hangs (apparently solid, but it's before networking starts up and I've not yet hooked up a serial console), after the radeon: ib pool ready message. With the old driver, I've found some combinations of configuration options that works. They all fail when DRM_RADEON_KMS is enabled. Gabriel Dave. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: known working sata_sil24.c setup on powerpc platforms?
Hi Leon, I think there's a hardware problem with mini PCI-E slot on P2020RDB related to legacy IRQ routing. See this thread for details http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg40037.html You may have better luck with PCI-E slot and mini PCI-E to PCI-E adapter. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: known working sata_sil24.c setup on powerpc platforms?
Hello Felix, On Wed, Apr 6, 2011 at 10:49 PM, Felix Radensky fe...@embedded-sol.com wrote: I think there's a hardware problem with mini PCI-E slot on P2020RDB related to legacy IRQ routing. See this thread for details http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg40037.html Thanks for the heads-up. You may have better luck with PCI-E slot and mini PCI-E to PCI-E adapter. Unfortunately the PCIe is slot already occupied, so that's why I searched for and found the Mini PCIe Sil3132 card. Legacy IRQ routing on PCIe is broken in what sense? Software (device tree, kernel) or silicon (p2020) ? On the MSI side, I'm getting quite far on transfers, but at one point the device stalls. Maybe a race condition in interrupt handling in sata_sil24.c? Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: known working sata_sil24.c setup on powerpc platforms?
Hi Leon, On 04/06/2011 11:58 PM, Leon Woestenberg wrote: Hello Felix, On Wed, Apr 6, 2011 at 10:49 PM, Felix Radenskyfe...@embedded-sol.com wrote: I think there's a hardware problem with mini PCI-E slot on P2020RDB related to legacy IRQ routing. See this thread for details http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg40037.html Unfortunately the PCIe is slot already occupied, so that's why I searched for and found the Mini PCIe Sil3132 card. Legacy IRQ routing on PCIe is broken in what sense? Software (device tree, kernel) or silicon (p2020) ? It's a board design problem specific to P2020RDB. Maybe it's fixed in latest board revisions. I have P2020RDB rev C and the problem is still there. Freescale people on the list should know better. On the MSI side, I'm getting quite far on transfers, but at one point the device stalls. Maybe a race condition in interrupt handling in sata_sil24.c? Sorry, cannot help you with that. I have no experience with sata_sil24. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] POWER: perf_event: Skip updating kernel counters if register value shrinks
On Thu, 31 Mar 2011, Benjamin Herrenschmidt wrote:
On Wed, 2011-03-30 at 14:36 -0400, Eric B Munson wrote:
On Wed, 30 Mar 2011, Benjamin Herrenschmidt wrote:
On Tue, 2011-03-29 at 10:25 -0400, Eric B Munson wrote:
Here I made the assumption that the hardware would never remove more
events in
a speculative roll back than it had added. This is not a situation I
encoutered in my limited testing, so I didn't think underflow was
possible. I
will send out a V2 using the signed 32 bit delta and remeber to CC
stable
this time.
I'm not thinking about underflow but rollover... or that isn't possible
with those counters ? IE. They don't wrap back to 0 after hitting
?
They do roll over to 0 after , but I thought that case was already
covered by the perf_event_interrupt. Are you concerned that we will reset a
counter and speculative roll back will underflow that counter?
No, but take this part of the patch:
--- a/arch/powerpc/kernel/perf_event.c
+++ b/arch/powerpc/kernel/perf_event.c
@@ -416,6 +416,15 @@ static void power_pmu_read(struct perf_event *event)
prev = local64_read(event-hw.prev_count);
barrier();
val = read_pmc(event-hw.idx);
+ /*
+* POWER7 can roll back counter values, if the new value is
+* smaller than the previous value it will cause the delta
+* and the counter to have bogus values. If this is the
+* case skip updating anything until the counter grows again.
+* This can lead to a small lack of precision in the counters.
+*/
+ if (val prev)
+ return;
} while (local64_cmpxchg(event-hw.prev_count, prev, val) != prev);
Doesn't that mean that power_pmu_read() can only ever increase the value of
the perf_event and so will essentially -stop- once the counter rolls over ?
Similar comments every where you do this type of comparison.
Cheers,
Ben.
Sorry for the nag, but am I missing something about the way the register and
the previous values are reset in the overflow interrupt handler?
Thanks,
Eric
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Using dmaengine on Freescale P2020 RDB
On Wed, Apr 06, 2011 at 01:29:05PM -0700, Chuck Ketcham wrote:
Ira,
Thanks for the reference to the CARMA drivers. I will have to take a look at
that.
In my case, CONFIG_NET_DMA is not enabled. However, I did notice the
following entry in my p2020rdb.dts file that may have something to do with
dma channels being allocated -- can anyone interpret this?:
dma@21300 {
#address-cells = 1;
#size-cells = 1;
compatible = fsl,eloplus-dma;
reg = 0x21300 0x4;
ranges = 0x0 0x21100 0x200;
cell-index = 0;
dma-channel@0 {
compatible = fsl,eloplus-dma-channel;
reg = 0x0 0x80;
cell-index = 0;
interrupt-parent = mpic;
interrupts = 20 2;
};
dma-channel@80 {
compatible = fsl,eloplus-dma-channel;
reg = 0x80 0x80;
cell-index = 1;
interrupt-parent = mpic;
interrupts = 21 2;
};
dma-channel@100 {
compatible = fsl,eloplus-dma-channel;
reg = 0x100 0x80;
cell-index = 2;
interrupt-parent = mpic;
interrupts = 22 2;
};
dma-channel@180 {
compatible = fsl,eloplus-dma-channel;
reg = 0x180 0x80;
cell-index = 3;
interrupt-parent = mpic;
interrupts = 23 2;
};
};
Your DTS file looks fine. It is what I would expect to see. The channels
are not allocated by anything here.
Turning on CONFIG_DMADEVICES_DEBUG may give you some insight into how
the dmaengine core is allocating the channels. I don't have any better
advice. I'm afraid you'll have to figure out who is requesting all of
the channels on your own.
Ira
--- On Wed, 4/6/11, Ira W. Snyder i...@ovro.caltech.edu wrote:
From: Ira W. Snyder i...@ovro.caltech.edu
Subject: Re: Using dmaengine on Freescale P2020 RDB
To: Chuck Ketcham chuckk2...@yahoo.com
Cc: linuxppc-dev@lists.ozlabs.org
Date: Wednesday, April 6, 2011, 1:10 PM
On Wed, Apr 06, 2011 at 12:40:58PM
-0700, Chuck Ketcham wrote:
All,
I have a Freescale P2020 Reference Design Board.
I am investigating the possibility of using the dmaengine
capability in the 2.6.32.13 kernel to transfer data from
memory out onto the PCIe bus. As a first step, I
thought I would try the DMA test client (dmatest.ko) to make
sure the dmaengine was functioning. I know this
doesn't transfer anything over PCIe but only transfers from
one memory buffer to another, but I figured I need to get
this working first. Anyway I built dmatest.ko and ran
it (with insmod), and discovered it didn't do
anything. I added some printk's to the kernel to
investigate what was going on and I found that all attempts
to find a channel within dma_request_channel were
unsuccessful. Three of the channels were not used
because they were already publicly allocated. One
channel was not used because it didn't have DMA_MEMCPY
capability.
Here are my questions then:
1. Is the dmaengine the appropriate method to use for
transferring data from memory out onto the PCIe bus?
2. If dmaengine is correct, what can I do to free up a
channel for my own use?
I use the Freescale DMA engine to transfer lots of data out
to PCI, on
an 8349EA chip. The P2020 DMA engine uses the same driver.
I hunch you have enabled CONFIG_NET_DMA, which will claim
the channels.
You should disable it to use the devices for other uses.
If you want an example of using the DMA engine to transfer
from DDR
memory to the PowerPC local bus, search the mailing list
archives for
CARMA Board Drivers (RFCv7 was the latest posting).
Transferring from
DDR to PCI works exactly the same way.
Hope it helps,
Ira
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sdhc/mpc8536 - SDCard always detected like read-only - SOLVED.
Wolfram,
Reading the MPC8536E Chip Errata I saw the SDHC_WP signal polarity is
reversed to the silicon revision 1.0.
Unfortunately my prototype board is using revision 1.0. So, I asked to
my hardware team workaround putting an extra inverter for the SDHC_WP
signal.
Now its working fine!
Thanks,
Moratelli
Em Qua, 2011-04-06 às 14:18 -0300, Carlos Roberto Moratelli escreveu:
I will try address the issue in details.
When I insert the SDCard, the same is detect like read-only:
mmcblk0: mmc0:b368 NCard 966 MiB (ro)
mmcblk0:
mmc0: starting CMD18 arg flags 00b5
mmc0: blksz 512 blocks 8 flags 0200 tsac 100 ms nsac 0
mmc0: CMD12 arg flags 049d
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0001
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x000a
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0001
mmc0: req done (CMD18): 0: 0900
mmc0: 4096 bytes transferred: 0
mmc0: (CMD12): 0: 0b00
p1
So, I just can mount the filesystem read-only. I can read the fat32
without problems.
I tested your sugestion. I used sdhci,wp-inverted in my dtb. This
changed the behavior. Now the SDCard is detected without the read-only
flag:
mmcblk0: mmc0:b368 NCard 966 MiB
mmcblk0:
mmc0: starting CMD18 arg flags 00b5
mmc0: blksz 512 blocks 8 flags 0200 tsac 100 ms nsac 0
mmc0: CMD12 arg flags 049d
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0001
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x000a
sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0001
mmc0: req done (CMD18): 0: 0900
mmc0: 4096 bytes transferred: 0
mmc0: (CMD12): 0: 0b00
p1
And, I can mount a rw filesystem:
#mount /dev/mmcblock1 /mnt
#cat /proc/mounts
...
/dev/mmcblock1 /mnt vfat
rw,relatime,fmask=,dmask=,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro
0 0
...
So, I can copy files to the mounted SDCard. But, When I try to umount I
see the following error mensagens:
#cp /etc/shadow /mnt
#ls /mnt
shadow
#umount /mnt
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 5944, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 5944
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 5936, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 5936
Buffer I/O error on device mmcblk0p1, logical block 3888
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 2049, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 2049
Buffer I/O error on device mmcblk0p1, logical block 1
mmc0: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 2080, nr 1, card status
0x900
end_request: I/O error, dev mmcblk0, sector 2080
...
I think I need the sdhci,wp-inverted in my dtb. But, it appears that
more something is necessary.
Has someone faced this situation?
Thanks by the help until here.
Regards,
Moratelli
Em Qua, 2011-04-06 às 01:48 +0200, Wolfram Sang escreveu:
sdhci@2e000 {
compatible = fsl,mpc8536-esdhc, fsl,esdhc;
reg = 0x2e000 0x1000;
interrupts = 72 0x2;
interrupt-parent = mpic;
/* Filled in by U-Boot */
clock-frequency = 0;
};
Hmm, I am not too familiar with those SoCs, yet some 83xx needed
sdhci,wp-inverted;
here. Maybe yours, too? Would fit the symptoms.
Regards,
Wolfram
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/1] powerpc/eeh: Add support for ibm,configure-pe RTAS call
From: Richard A. Lary rl...@linux.vnet.ibm.com
Added support for ibm,configure-pe RTAS call introduced with
PAPR 2.2.
Signed-off-by: Richard A. Lary rl...@linux.vnet.ibm.com
---
arch/powerpc/platforms/pseries/eeh.c | 1312 +1 - 0 !
1 file changed, 12 insertions(+), 1 deletion(-)
Index: b/arch/powerpc/platforms/pseries/eeh.c
===
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -95,6 +95,7 @@ static int ibm_slot_error_detail;
static int ibm_get_config_addr_info;
static int ibm_get_config_addr_info2;
static int ibm_configure_bridge;
+static int ibm_configure_pe;
int eeh_subsystem_enabled;
EXPORT_SYMBOL(eeh_subsystem_enabled);
@@ -263,6 +264,8 @@ void eeh_slot_error_detail(struct pci_dn
pci_regs_buf[0] = 0;
rtas_pci_enable(pdn, EEH_THAW_MMIO);
+ rtas_configure_bridge(pdn);
+ eeh_restore_bars(pdn);
loglen = gather_pci_data(pdn, pci_regs_buf, EEH_PCI_REGS_LOG_LEN);
rtas_slot_error_detail(pdn, severity, pci_regs_buf, loglen);
@@ -896,6 +899,7 @@ void
rtas_configure_bridge(struct pci_dn *pdn)
{
int config_addr;
+ int token;
int rc;
/* Use PE configuration address, if present */
@@ -903,7 +907,13 @@ rtas_configure_bridge(struct pci_dn *pdn
if (pdn-eeh_pe_config_addr)
config_addr = pdn-eeh_pe_config_addr;
- rc = rtas_call(ibm_configure_bridge,3,1, NULL,
+ /* Use new configure-pe function, if supported */
+ if (ibm_configure_pe != RTAS_UNKNOWN_SERVICE)
+ token = ibm_configure_pe;
+ else
+ token = ibm_configure_bridge;
+
+ rc = rtas_call(token, 3, 1, NULL,
config_addr,
BUID_HI(pdn-phb-buid),
BUID_LO(pdn-phb-buid));
@@ -1079,6 +1089,7 @@ void __init eeh_init(void)
ibm_get_config_addr_info = rtas_token(ibm,get-config-addr-info);
ibm_get_config_addr_info2 = rtas_token(ibm,get-config-addr-info2);
ibm_configure_bridge = rtas_token (ibm,configure-bridge);
+ ibm_configure_pe = rtas_token(ibm,configure-pe);
if (ibm_set_eeh_option == RTAS_UNKNOWN_SERVICE)
return;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] powerpc/eeh: Add support for ibm,configure-pe RTAS call
On Wed, 2011-04-06 at 15:50 -0700, Richard A Lary wrote:
From: Richard A. Lary rl...@linux.vnet.ibm.com
Added support for ibm,configure-pe RTAS call introduced with
PAPR 2.2.
Care to tell us a bit about the difference ? :-) There's nothing obvious
in the code Also you added calls to rtas_configure_bridge() and
eeh_restore_bars() to eeh_slot_error_Detail(), that might want some
explanation as well.
Cheers,
Ben.
Signed-off-by: Richard A. Lary rl...@linux.vnet.ibm.com
---
arch/powerpc/platforms/pseries/eeh.c | 13 12 +1 - 0 !
1 file changed, 12 insertions(+), 1 deletion(-)
Index: b/arch/powerpc/platforms/pseries/eeh.c
===
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -95,6 +95,7 @@ static int ibm_slot_error_detail;
static int ibm_get_config_addr_info;
static int ibm_get_config_addr_info2;
static int ibm_configure_bridge;
+static int ibm_configure_pe;
int eeh_subsystem_enabled;
EXPORT_SYMBOL(eeh_subsystem_enabled);
@@ -263,6 +264,8 @@ void eeh_slot_error_detail(struct pci_dn
pci_regs_buf[0] = 0;
rtas_pci_enable(pdn, EEH_THAW_MMIO);
+ rtas_configure_bridge(pdn);
+ eeh_restore_bars(pdn);
loglen = gather_pci_data(pdn, pci_regs_buf, EEH_PCI_REGS_LOG_LEN);
rtas_slot_error_detail(pdn, severity, pci_regs_buf, loglen);
@@ -896,6 +899,7 @@ void
rtas_configure_bridge(struct pci_dn *pdn)
{
int config_addr;
+ int token;
int rc;
/* Use PE configuration address, if present */
@@ -903,7 +907,13 @@ rtas_configure_bridge(struct pci_dn *pdn
if (pdn-eeh_pe_config_addr)
config_addr = pdn-eeh_pe_config_addr;
- rc = rtas_call(ibm_configure_bridge,3,1, NULL,
+ /* Use new configure-pe function, if supported */
+ if (ibm_configure_pe != RTAS_UNKNOWN_SERVICE)
+ token = ibm_configure_pe;
+ else
+ token = ibm_configure_bridge;
+
+ rc = rtas_call(token, 3, 1, NULL,
config_addr,
BUID_HI(pdn-phb-buid),
BUID_LO(pdn-phb-buid));
@@ -1079,6 +1089,7 @@ void __init eeh_init(void)
ibm_get_config_addr_info = rtas_token(ibm,get-config-addr-info);
ibm_get_config_addr_info2 = rtas_token(ibm,get-config-addr-info2);
ibm_configure_bridge = rtas_token (ibm,configure-bridge);
+ ibm_configure_pe = rtas_token(ibm,configure-pe);
if (ibm_set_eeh_option == RTAS_UNKNOWN_SERVICE)
return;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Use new CPU feature bit to select 2.06 tlbie
This removes MMU_FTR_TLBIE_206 as we can now use CPU_FTR_HVMODE_206. It also changes the logic to select which tlbie to use to be based on this new CPU feature bit. This also duplicates the ASM_FTR_IF/SET/CLR defines for CPU features (copied from MMU features). Signed-off-by: Michael Neuling mi...@neuling.org --- Subject: Re: [PATCH 04/15] powerpc: Define CPU feature for Architected 2.06 HV mode +#define CPU_FTR_HVMODE_206 LONG_ASM_CONST(0x000800 00) FYI With this patch we could remove MMU_FTR_TLBIE_206. We could... care to send a patch ? :-) Sure... How about this? Mikey arch/powerpc/include/asm/feature-fixups.h | 13 + arch/powerpc/include/asm/mmu.h|5 - arch/powerpc/kernel/cputable.c|9 +++-- arch/powerpc/mm/hash_native_64.c |8 4 files changed, 20 insertions(+), 15 deletions(-) Index: clone1/arch/powerpc/include/asm/feature-fixups.h === --- clone1.orig/arch/powerpc/include/asm/feature-fixups.h +++ clone1/arch/powerpc/include/asm/feature-fixups.h @@ -146,6 +146,19 @@ #ifndef __ASSEMBLY__ +#define ASM_FTR_IF(section_if, section_else, msk, val) \ + stringify_in_c(BEGIN_FTR_SECTION) \ + section_if ; \ + stringify_in_c(FTR_SECTION_ELSE)\ + section_else ;\ + stringify_in_c(ALT_FTR_SECTION_END((msk), (val))) + +#define ASM_FTR_IFSET(section_if, section_else, msk) \ + ASM_FTR_IF(section_if, section_else, (msk), (msk)) + +#define ASM_FTR_IFCLR(section_if, section_else, msk) \ + ASM_FTR_IF(section_if, section_else, (msk), 0) + #define ASM_MMU_FTR_IF(section_if, section_else, msk, val) \ stringify_in_c(BEGIN_MMU_FTR_SECTION) \ section_if ; \ Index: clone1/arch/powerpc/include/asm/mmu.h === --- clone1.orig/arch/powerpc/include/asm/mmu.h +++ clone1/arch/powerpc/include/asm/mmu.h @@ -56,11 +56,6 @@ */ #define MMU_FTR_NEED_DTLB_SW_LRU ASM_CONST(0x0020) -/* This indicates that the processor uses the ISA 2.06 server tlbie - * mnemonics - */ -#define MMU_FTR_TLBIE_206 ASM_CONST(0x0040) - /* Enable use of TLB reservation. Processor should support tlbsrx. * instruction and MAS0[WQ]. */ Index: clone1/arch/powerpc/kernel/cputable.c === --- clone1.orig/arch/powerpc/kernel/cputable.c +++ clone1/arch/powerpc/kernel/cputable.c @@ -417,8 +417,7 @@ .cpu_name = POWER7 (architected), .cpu_features = CPU_FTRS_POWER7, .cpu_user_features = COMMON_USER_POWER7, - .mmu_features = MMU_FTR_HPTE_TABLE | - MMU_FTR_TLBIE_206, + .mmu_features = MMU_FTR_HPTE_TABLE, .icache_bsize = 128, .dcache_bsize = 128, .oprofile_type = PPC_OPROFILE_POWER4, @@ -433,8 +432,7 @@ .cpu_name = POWER7 (raw), .cpu_features = CPU_FTRS_POWER7, .cpu_user_features = COMMON_USER_POWER7, - .mmu_features = MMU_FTR_HPTE_TABLE | - MMU_FTR_TLBIE_206, + .mmu_features = MMU_FTR_HPTE_TABLE, .icache_bsize = 128, .dcache_bsize = 128, .num_pmcs = 6, @@ -451,8 +449,7 @@ .cpu_name = POWER7+ (raw), .cpu_features = CPU_FTRS_POWER7, .cpu_user_features = COMMON_USER_POWER7, - .mmu_features = MMU_FTR_HPTE_TABLE | - MMU_FTR_TLBIE_206, + .mmu_features = MMU_FTR_HPTE_TABLE, .icache_bsize = 128, .dcache_bsize = 128, .num_pmcs = 6, Index: clone1/arch/powerpc/mm/hash_native_64.c === --- clone1.orig/arch/powerpc/mm/hash_native_64.c +++ clone1/arch/powerpc/mm/hash_native_64.c @@ -50,9 +50,9 @@ case MMU_PAGE_4K: va = ~0xffful; va |= ssize 8; - asm volatile(ASM_MMU_FTR_IFCLR(tlbie %0,0, PPC_TLBIE(%1,%0), + asm volatile(ASM_FTR_IFCLR(tlbie %0,0, PPC_TLBIE(%1,%0), %2) -: : r (va), r(0), i (MMU_FTR_TLBIE_206) +: : r (va), r(0), i (CPU_FTR_HVMODE_206) : memory);
Re: [PATCH] POWER: perf_event: Skip updating kernel counters if register value shrinks
Doesn't that mean that power_pmu_read() can only ever increase the value of the perf_event and so will essentially -stop- once the counter rolls over ? Similar comments every where you do this type of comparison. Cheers, Ben. Sorry for the nag, but am I missing something about the way the register and the previous values are reset in the overflow interrupt handler? Well, not all counters get interrupts right ? Some counters are just free running... I'm not sure when that power_pmu_read() function is actually used by the core, I'm not that familiar with perf, but I'd say better safe than sorry. When comparing counter values, doing in a way that is generally safe vs. wraparounds. Eventually do a helper for that. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sdhc/mpc8536 - SDCard always detected like read-only - SOLVED.
Reading the MPC8536E Chip Errata I saw the SDHC_WP signal polarity is reversed to the silicon revision 1.0. Unfortunately my prototype board is using revision 1.0. So, I asked to my hardware team workaround putting an extra inverter for the SDHC_WP signal. Now its working fine! OK, nice. I fail to see from a glimpse how all this is related to the timeout-errors you were seeing (-110), but if it works now, all is fine, I guess. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: known working sata_sil24.c setup on powerpc platforms?
Hi Leon, Can you please check p2020rdb.dts for IDSEL entries for pci0/1 node? In order to work in legacy mode, IDSEL entries are required. --Prabhakar -Original Message- From: linux-ide-ow...@vger.kernel.org [mailto:linux-ide- ow...@vger.kernel.org] On Behalf Of Leon Woestenberg Sent: Thursday, April 07, 2011 12:20 AM To: Jeff Garzik Cc: Moffett, Kyle D; Linux PPC; linux-...@vger.kernel.org; Tejun Heo Subject: Re: known working sata_sil24.c setup on powerpc platforms? Hello Jeff, all, On Wed, Apr 6, 2011 at 8:12 PM, Jeff Garzik j...@garzik.org wrote: On 04/06/2011 01:48 PM, Moffett, Kyle D wrote: On Apr 06, 2011, at 13:00, Leon Woestenberg wrote: after investigating problems with sata_sil24.c on a freescale p2020 soc, I wonder if this driver works on powerpc at all? Does anyone know of a working setup of sata_sil24 on a big endian powerpc system? Our P2020 boards work fine with legacy PCI interrupts (I think it's a sil3124 over PCI-E); the only deficiency is that MSI does not seem to work. We've definitely had issues with sata_sil24 + MSI, also... sata_sil24 does work on big endian in general. On my system, I have the contrary to Kyle's experience (thanks for sharing). PowerPC P2020RDB vanilla 2.6.38 Sil3132 on mini-PCI Express card Enabling msi gets me further than disabling it (default). modprobe sata_sil [8.834613] sata_sil24 0001:03:00.0: version 1.1 [8.885581] scsi0 : sata_sil24 [8.901420] scsi1 : sata_sil24 [8.904642] ata1: SATA max UDMA/100 host m128@0xc000 port 0xc0004000 irq 16 [8.911961] ata2: SATA max UDMA/100 host m128@0xc000 port 0xc0006000 irq 16 [ 11.095127] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 14.906986] eth0: no IPv6 routers present [ 16.099016] ata1.00: qc timeout (cmd 0xec) [ 16.103128] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 18.299050] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 28.303026] ata1.00: qc timeout (cmd 0xec) [ 28.307139] ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) [ 28.313233] ata1: limiting SATA link speed to 1.5 Gbps [ 30.523059] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 10) modprobe sata_sil msi=1 [ 92.984120] sata_sil24 0001:03:00.0: version 1.1 [ 92.988897] irq: irq 0 on host /soc@ffe0/msi@41600 mapped to virtual irq 41 [ 92.996229] sata_sil24 0001:03:00.0: Using MSI [ 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering [ 93.011628] scsi2 : sata_sil24 [ 93.022463] scsi3 : sata_sil24 [ 93.025695] ata3: SATA max UDMA/100 host m128@0xc000 port 0xc0004000 irq 41 [ 93.033023] ata4: SATA max UDMA/100 host m128@0xc000 port 0xc0006000 irq 41 [ 95.203029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 95.209045] ata3: spurious interrupt (slot_stat 0x0 active_tag -84148995 sactive 0x0) [ 95.217171] ata3.00: ATA-7: INTEL SSDSA2M080G2GN, 2CV102HD, max UDMA/133 [ 95.223882] ata3.00: 156301488 sectors, multi 1: LBA48 NCQ (depth 31/32) [ 95.230905] ata3.00: configured for UDMA/100 [ 95.235399] scsi 2:0:0:0: Direct-Access ATA INTEL SSDSA2M080 2CV1 PQ: 0 ANSI: 5 [ 95.244002] sd 2:0:0:0: Attached scsi generic sg0 type 0 [ 95.252041] sd 2:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB) [ 95.260219] sd 2:0:0:0: [sda] Write Protect is off [ 95.265063] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 95.270500] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 95.283779] sda: sda1 sda2 sda3 sda4 [ 95.289482] sd 2:0:0:0: [sda] Attached SCSI disk [ 95.965897] EXT3-fs: barriers not enabled [ 95.977279] kjournald starting. Commit interval 5 seconds [ 95.983296] EXT3-fs (sda2): using internal journal [ 95.988143] EXT3-fs (sda2): recovery complete [ 95.992504] EXT3-fs (sda2): mounted filesystem with writeback data mode [ 96.111587] NTFS volume version 3.1. [ 97.331005] ata4: SATA link down (SStatus 0 SControl 0) root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=1000 1000+0 records in 1000+0 records out 4096000 bytes (4.1 MB) copied, 0.0315629 s, 130 MB/s root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=1 1+0 records in 1+0 records out 4096 bytes (41 MB) copied, 0.471802 s, 86.8 MB/s root@p1020rdb:~# dd if=/dev/sda of=/dev/null bs=4k count=10 That stalls, I see the controller fail. See dmesg below: ^C^Cdd: reading `/dev/sda': Input/output error 51804+0 records in 51804+0 records out 212189184 bytes (212 MB) copied, 85.6537 s, 2.5 MB/s dd: closing input file `/dev/sda': Bad file descriptor [ 92.984120] sata_sil24 0001:03:00.0: version 1.1 [ 92.988897] irq: irq 0 on host /soc@ffe0/msi@41600 mapped to virtual irq 41 [ 92.996229] sata_sil24 0001:03:00.0: Using MSI [ 93.000675] sata_sil24 0001:03:00.0: enabling bus mastering [
[PATCH] powerpc: Free up some CPU feature bits by moving out MMU-related features
Some of the 64bit PPC CPU features are MMU-related, so this patch moves them to MMU_FTR_ bits. All cpu_has_feature()-style tests are moved to mmu_has_feature(), and seven feature bits are freed as a result. Signed-off-by: Matt Evans m...@ozlabs.org --- Boot-tested on pseries and G5. arch/powerpc/include/asm/cputable.h| 52 ++- arch/powerpc/include/asm/mmu.h | 28 +++ arch/powerpc/include/asm/mmu_context.h |2 +- arch/powerpc/kernel/cputable.c | 39 ++--- arch/powerpc/kernel/entry_64.S |8 ++-- arch/powerpc/kernel/exceptions-64s.S |4 +- arch/powerpc/kernel/process.c |4 +- arch/powerpc/kernel/prom.c | 17 + arch/powerpc/kernel/setup_64.c |2 +- arch/powerpc/mm/hash_low_64.S |8 ++-- arch/powerpc/mm/hash_native_64.c |8 ++-- arch/powerpc/mm/hash_utils_64.c| 18 +- arch/powerpc/mm/hugetlbpage.c |2 +- arch/powerpc/mm/slb.c |4 +- arch/powerpc/mm/slb_low.S |8 ++-- arch/powerpc/mm/stab.c |2 +- arch/powerpc/platforms/iseries/exception.S |2 +- arch/powerpc/platforms/iseries/setup.c |4 +- arch/powerpc/platforms/pseries/lpar.c |2 +- arch/powerpc/xmon/xmon.c |2 +- 20 files changed, 123 insertions(+), 93 deletions(-) diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h index be3cdf9..7b0fe7c 100644 --- a/arch/powerpc/include/asm/cputable.h +++ b/arch/powerpc/include/asm/cputable.h @@ -178,22 +178,15 @@ extern const char *powerpc_base_platform; #define LONG_ASM_CONST(x) 0 #endif -#define CPU_FTR_SLBLONG_ASM_CONST(0x0001) -#define CPU_FTR_16M_PAGE LONG_ASM_CONST(0x0002) -#define CPU_FTR_TLBIEL LONG_ASM_CONST(0x0004) #define CPU_FTR_IABR LONG_ASM_CONST(0x0020) #define CPU_FTR_MMCRA LONG_ASM_CONST(0x0040) #define CPU_FTR_CTRL LONG_ASM_CONST(0x0080) #define CPU_FTR_SMTLONG_ASM_CONST(0x0100) -#define CPU_FTR_LOCKLESS_TLBIE LONG_ASM_CONST(0x0400) -#define CPU_FTR_CI_LARGE_PAGE LONG_ASM_CONST(0x1000) #define CPU_FTR_PAUSE_ZERO LONG_ASM_CONST(0x2000) #define CPU_FTR_PURR LONG_ASM_CONST(0x4000) #define CPU_FTR_CELL_TB_BUGLONG_ASM_CONST(0x8000) #define CPU_FTR_SPURR LONG_ASM_CONST(0x0001) #define CPU_FTR_DSCR LONG_ASM_CONST(0x0002) -#define CPU_FTR_1T_SEGMENT LONG_ASM_CONST(0x0004) -#define CPU_FTR_NO_SLBIE_B LONG_ASM_CONST(0x0008) #define CPU_FTR_VSXLONG_ASM_CONST(0x0010) #define CPU_FTR_SAOLONG_ASM_CONST(0x0020) #define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040) @@ -205,9 +198,10 @@ extern const char *powerpc_base_platform; #ifndef __ASSEMBLY__ -#define CPU_FTR_PPCAS_ARCH_V2 (CPU_FTR_SLB | \ -CPU_FTR_TLBIEL | CPU_FTR_NOEXECUTE | \ -CPU_FTR_NODSISRALIGN | CPU_FTR_16M_PAGE) +#define CPU_FTR_PPCAS_ARCH_V2 (CPU_FTR_NOEXECUTE | CPU_FTR_NODSISRALIGN) + +#define MMU_FTR_PPCAS_ARCH_V2 (MMU_FTR_SLB | MMU_FTR_TLBIEL | \ +MMU_FTR_16M_PAGE) /* We only set the altivec features if the kernel was compiled with altivec * support @@ -405,41 +399,49 @@ extern const char *powerpc_base_platform; #define CPU_FTRS_POWER5(CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \ CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \ CPU_FTR_MMCRA | CPU_FTR_SMT | \ - CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \ - CPU_FTR_PURR | CPU_FTR_STCX_CHECKS_ADDRESS | \ - CPU_FTR_POPCNTB) + CPU_FTR_COHERENT_ICACHE | CPU_FTR_PURR | \ + CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB) #define CPU_FTRS_POWER6 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \ CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \ CPU_FTR_MMCRA | CPU_FTR_SMT | \ - CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \ - CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \ - CPU_FTR_DSCR | CPU_FTR_UNALIGNED_LD_STD | \ + CPU_FTR_COHERENT_ICACHE | CPU_FTR_PURR | CPU_FTR_SPURR | \ + CPU_FTR_REAL_LE | CPU_FTR_DSCR | CPU_FTR_UNALIGNED_LD_STD | \ CPU_FTR_STCX_CHECKS_ADDRESS | CPU_FTR_POPCNTB) #define CPU_FTRS_POWER7 (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \ CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \ CPU_FTR_MMCRA
