Linux patches for XIP on MPC8xx?
Hi Wolfgang, I found your homepage at http://www.denx.de/wiki/bin/view/DULG/ConfigureLinuxForXIP back from 2003. Was there any follow up of your patch for kernel 2.4.4? Regards, Márton Németh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V2 PATCH 00/10] of: Consolidate scattered device node pointers in struct device
On Thu, 2010-03-18 at 09:22 -0600, Grant Likely wrote: Currently, each of_device has a copy of the device tree node pointer in both .node, and in .dev.archdata.of_node (microblaze and powerpc) or .dev.archdata.prom_node (sparc). Also, other architectures will be adding CONFIG_OF support, and they will also need a reference to the device tree node pointer from struct device. Assuming this is similar to your experimental-devicetree branch, as of 96b4b9d7 it causes a few build errors for me: http://kisskb.ellerman.id.au/kisskb/head/2688/ Broken are 86xx/sbc8641d_defconfig, mpc83xx_defconfig, mpc885_ads_defconfig, mpc85xx_defconfig, and pmac32_defconfig. I haven't dug any further. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V2 PATCH 00/10] of: Consolidate scattered device node pointers in struct device
On Tue, Mar 23, 2010 at 12:57 AM, Michael Ellerman mich...@ellerman.id.au wrote: On Thu, 2010-03-18 at 09:22 -0600, Grant Likely wrote: Currently, each of_device has a copy of the device tree node pointer in both .node, and in .dev.archdata.of_node (microblaze and powerpc) or .dev.archdata.prom_node (sparc). Also, other architectures will be adding CONFIG_OF support, and they will also need a reference to the device tree node pointer from struct device. Assuming this is similar to your experimental-devicetree branch, as of 96b4b9d7 it causes a few build errors for me: http://kisskb.ellerman.id.au/kisskb/head/2688/ Broken are 86xx/sbc8641d_defconfig, mpc83xx_defconfig, mpc885_ads_defconfig, mpc85xx_defconfig, and pmac32_defconfig. Hey Michael, Thanks for the testing. I haven't built through all the defconfigs yet so this doesn't surprise me too much that I've missed some drivers. The failure is caused in the last three commits which remove the old variables. I'll pick through the failing defconfigs, fix and test them, and refresh my branch. I'll let you know when the branch is updated. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
The GPIO problem on MPC8323?
hi,all: i saw peter's mpc8xxx_gpio.c in kernel 2.6.31. it seems that file can only be used on 831x and others, but not mpc8323. my platform is mpc8323, how can i use the GPIO? i also found QE GPIO Support and Support for simple, memory-mapped GPIO controllers selection, how can i use it and test in user space? thanks, best regards. evan. ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
On Tue, Mar 23, 2010 at 04:33:01PM +1100, Paul Mackerras wrote: On Mon, Mar 08, 2010 at 11:44:48PM +0530, K.Prasad wrote: @@ -479,6 +483,7 @@ struct task_struct *__switch_to(struct t old_thread-accum_tb += (current_tb - start_tb); new_thread-start_tb = current_tb; } + flush_ptrace_hw_breakpoint(current); #endif local_irq_save(flags); This line should be in flush_thread(), not __switch_to(). In fact it may not be necessary at all given that flush_ptrace_hw_breakpoint() gets called in do_exit(). Paul. Yes, I did realise it. The unintended movement of flush_ptrace_hw_breakpoint() from flush_thread() is a result of a patching error (while forward porting). A fix for this issue along with those pointed out by BenH will be a part of the next version of the patch, that I intend to send very soon. Thanks for reviewing them. -- K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Virtio_console usage of early printk
On 22.03.2010, at 18:45, François Diakhate wrote: Hi all, As far as I can see, early_put_chars is not used by virtio_console because it checks whether there is a port available before using it. If I understand correctly, this makes it useless because once we have a port, we can use the regular virtio transport to output things to the console. Does the attached patch seem valid ? Feedback from s390 and powerpc users who use this functionality would be appreciated. On S390 we use the hypercall interface with characters instead of memory addresses as parameters. The hypervisor then decides if the character is an early printk or a real hypercall. I'm not sure how PPC handles that - I never used virtio console there. Either way, early printk does work for S390. So what exactly is this patch supposed to fix? Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/10] irq: move some interrupt arch_* functions into struct irq_chip.
On Sun, Mar 21, 2010 at 08:32:33PM -0700, Yinghai Lu wrote:
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 64f6f20..cafd378 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -1088,7 +1088,7 @@ int arch_early_irq_init(void)
return 0;
}
-int arch_init_chip_data(struct irq_desc *desc, int node)
+int arch_init_irq_desc(struct irq_desc *desc, int node, init_chip_data_fn fn)
{
desc-status |= IRQ_NOREQUEST;
return 0;
so this patch only change one line with powerpc code.
This API seems to be going from bad to worse. Initially we had
arch_init_chip_data(), which had precisely nothing to do with chip_data
and only concerned itself with irq_desc, and now you're renaming it to
something sensible but also trying to bolt on some ad-hoc chip_data
relation at the same time thereby nullifying any benefit obtained from
renaming the function in the first place.
Renaming to xxx_irq_desc() while preserving the existing prototypes would
make sense, even if it's ultimately just unecessary churn.
It looks to me like this should just be done via a current machine
vector or platform routine, in the same way as powerpc and (I think)
ia64, ie:
+int arch_init_irq_desc(struct irq_desc *desc, int node)
+{
+ return current_machine-init_chip_data(desc, node);
+}
looks like xen in same run time, some irqs need x86_init_chip_data,
and some may need xen_init_chip_data later.
I'm afraid I am unable to grasp the meaning of this sentence, or what
precisely this has to do with not being able to utilize platform ops to
get this sorted out on x86.
You're effectively trying to have the hardirq code pass around a function
pointer for you that ultimately only serves to bail out on certain code
paths if you're running under xen, which is a concern for how the
platform chooses to initialize the irq desc, none of this has any value
or relevance to the hardirq code outside of that. The fact that the
hardirq code doesn't do anything with this information other than pass it
around for your platform should already be a clear indicator that this is
the wrong way to go.
From a cursory look at the x86 code, this looks like precisely the sort
of thing that arch/x86/include/asm/x86_init.h is well suited for, and
indeed you already have a x86_init_irqs to expand on as needed.
The function pointer thing itself is also a bit unorthodox to say the
least. You're introducing and passing around an opaque type just so you
can get to a 'return 0' in the xen case as far as I can tell, so you
could also just make arch_init_chip_data() a weak symbol and clobber it
in the xen case, no?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] panic: Allow taint flag for warnings to be changed from TAINT_WARN
On Sat, Mar 20, 2010 at 11:05:40PM +, Ben Hutchings wrote: WARN() is used in some places to report firmware or hardware bugs that are then worked-around. These bugs do not affect the stability of the kernel and should not set the usual TAINT_WARN flag. To allow for this, add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint flag as argument. Architectures that implement warnings using trap instructions instead of calls to warn_slowpath_*() must now implement __WARN_TAINT(taint) instead of __WARN(). Signed-off-by: Ben Hutchings b...@decadent.org.uk --- The architecture-specific changes here are untested and need to be reviewed by architecture maintainers. I'm a bit confused about how this is supposed to work, the TAINT_xxx values are bit positions presently from 0 to 10, while BUGFLAG_xxx are ranged from 0 up. You've set up BUGFLAG_TAINT() to that the TAINT_xxx value is shifted up 8 bits but neglected the fact that the trap type is 16-bits on most (all?) of the platforms using trap-based BUG handling. If the 'taint' in question is just the TAINT_xxx value by itself and will never be a bitmap then that's fine, but there's certainly not enough room to pass the bitmap in on top of the bugflag otherwise (I don't know if this is your intention or not though). Also note that some platforms (like SH) implement additional bugflags, so we at least want to keep the lower byte available for architecture private use. Having said that, the current patch does work for me, although I'm a bit nervous about someone thinking it's ok to pass in a taint bitmap here. Tested-by: Paul Mundt let...@linux-sh.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
powerpc, 8xx: Add support for the MPC8xx based boards from TQC
Supported SMC1 (serial console), SCC1 Ethernet (10Mbps HD).
FEC Ethernet, 8MB NOR CFI Flash.
Tested on STK8xx with TQM860L (with FEC)
and with TQM855M (without FEC).
Signed-off-by: Heiko Schocher h...@denx.de
---
- based against git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
commit bca14dd14f3b0c5e3e2d1d314679f85b67871365
- checked with checkpatch
$ scripts/checkpatch.pl
0001-powerpc-8xx-Add-support-for-the-MPC8xx-based-board.patch
total: 0 errors, 0 warnings, 1278 lines checked
0001-powerpc-8xx-Add-support-for-the-MPC8xx-based-board.patch has no obvious
style problems and is ready for submission.
$
arch/powerpc/boot/dts/tqm8xx.dts | 172 ++
arch/powerpc/configs/tqm8xx_defconfig | 934 +
arch/powerpc/platforms/8xx/Kconfig|6 +
arch/powerpc/platforms/8xx/Makefile |1 +
arch/powerpc/platforms/8xx/tqm8xx_setup.c | 156 +
5 files changed, 1269 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/tqm8xx.dts
create mode 100644 arch/powerpc/configs/tqm8xx_defconfig
create mode 100644 arch/powerpc/platforms/8xx/tqm8xx_setup.c
diff --git a/arch/powerpc/boot/dts/tqm8xx.dts b/arch/powerpc/boot/dts/tqm8xx.dts
new file mode 100644
index 000..f6da7ec
--- /dev/null
+++ b/arch/powerpc/boot/dts/tqm8xx.dts
@@ -0,0 +1,172 @@
+/*
+ * TQM8XX Device Tree Source
+ *
+ * Heiko Schocher h...@denx.de
+ * 2010 DENX Software Engineering GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+
+/ {
+ model = TQM8xx;
+ compatible = tqc,tqm8xx;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = eth0;
+ ethernet1 = eth1;
+ mdio1 = phy1;
+ serial0 = smc1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,8...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ d-cache-line-size = 16; // 16 bytes
+ i-cache-line-size = 16; // 16 bytes
+ d-cache-size = 0x1000;// L1, 4K
+ i-cache-size = 0x1000;// L1, 4K
+ timebase-frequency = 0;
+ bus-frequency = 0;
+ clock-frequency = 0;
+ interrupts = 15 2;// decrementer interrupt
+ interrupt-parent = PIC;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x0 0x200;
+ };
+
+ local...@fff00100 {
+ compatible = fsl,mpc860-localbus, fsl,pq1-localbus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0xfff00100 0x40;
+
+ ranges =
+ 0x0 0x0 0x4000 0x80
+ ;
+
+ fl...@0,0 {
+ compatible = cfi-flash;
+ reg = 0 0 0x80;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 4;
+ device-width = 2;
+ };
+ };
+
+ s...@fff0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0x0 0xfff0 0x4000;
+
+ phy1: m...@e00 {
+ compatible = fsl,mpc866-fec-mdio, fsl,pq1-fec-mdio;
+ reg = 0xe00 0x188;
+ #address-cells = 1;
+ #size-cells = 0;
+ PHY: ethernet-...@f {
+ reg = 0xf;
+ device_type = ethernet-phy;
+ };
+ };
+
+ eth1: ether...@e00 {
+ device_type = network;
+ compatible = fsl,mpc866-fec-enet,
+fsl,pq1-fec-enet;
+ reg = 0xe00 0x188;
+ interrupts = 3 1;
+ interrupt-parent = PIC;
+ phy-handle = PHY;
+ linux,network-index = 1;
+ };
+
+ PIC: p...@0 {
+ interrupt-controller;
+ #interrupt-cells = 2;
+ reg = 0x0 0x24;
+ compatible = fsl,mpc860-pic, fsl,pq1-pic;
+ };
+
+ c...@9c0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc860-cpm,
Re: Virtio_console usage of early printk
Am Dienstag 23 März 2010 03:16:20 schrieb Amit Shah:
On (Mon) Mar 22 2010 [18:45:47], François Diakhate wrote:
the console. Does the attached patch seem valid ? Feedback from s390
and powerpc users who use this functionality would be appreciated.
Looks OK to me, Christian, others, could you comment on this please?
Looks good and boot tested with kuli on s390.
Acked-by: Christian Borntraeger borntrae...@de.ibm.com
From 3961f380bbe84a1036ddfc823039cbee31b44dcb Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Fran=C3=A7ois=20Diakhat=C3=A9?= fdi...@gmail.com
Date: Thu, 18 Mar 2010 14:48:20 +0100
Subject: virtio: console: Fix early_put_chars usage
Currently early_put_chars is not used by virtio_console because it can only
be used once a port has been found, at which point it's too late because it
is no longer needed. This patch should fix it.
---
drivers/char/virtio_console.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index f404ccf..691ba21 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -645,13 +645,13 @@ static int put_chars(u32 vtermno, const char *buf,
int count)
{
struct port *port;
+ if (unlikely(early_put_chars))
+ return early_put_chars(vtermno, buf, count);
+
port = find_port_by_vtermno(vtermno);
if (!port)
return 0;
- if (unlikely(early_put_chars))
- return early_put_chars(vtermno, buf, count);
-
return send_buf(port, (void *)buf, count);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Virtio_console usage of early printk
On (Mon) Mar 22 2010 [18:45:47], François Diakhate wrote: Hi all, As far as I can see, early_put_chars is not used by virtio_console because it checks whether there is a port available before using it. If I understand correctly, this makes it useless because once we have a port, we can use the regular virtio transport to output things to the console. Does the attached patch seem valid ? Feedback from s390 and powerpc users who use this functionality would be appreciated. Thanks, François From 3961f380bbe84a1036ddfc823039cbee31b44dcb Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Fran=C3=A7ois=20Diakhat=C3=A9?= fdi...@gmail.com Date: Thu, 18 Mar 2010 14:48:20 +0100 Subject: virtio: console: Fix early_put_chars usage Currently early_put_chars is not used by virtio_console because it can only be used once a port has been found, at which point it's too late because it is no longer needed. This patch should fix it. You'll have to give a signed-off-by for the patch. Amit ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux patches for XIP on MPC8xx?
Németh Márton wrote: Hi Wolfgang, I found your homepage at http://www.denx.de/wiki/bin/view/DULG/ConfigureLinuxForXIP back from 2003. Was there any follow up of your patch for kernel 2.4.4? Not that I remember. Wolfgang. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] panic: Allow taint flag for warnings to be changed from TAINT_WARN
On Mon, 2010-03-22 at 22:47 -0400, Andrew Morton wrote: On Sat, 20 Mar 2010 23:05:40 + Ben Hutchings b...@decadent.org.uk wrote: WARN() is used in some places to report firmware or hardware bugs that are then worked-around. These bugs do not affect the stability of the kernel and should not set the usual TAINT_WARN flag. To allow for this, add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint flag as argument. Architectures that implement warnings using trap instructions instead of calls to warn_slowpath_*() must now implement __WARN_TAINT(taint) instead of __WARN(). When you say they must now implement, I assume that you mean that they _do_ now implement, and that no additional architecture work is needed. Right, I believe I fixed-up all the current architectures. There might be more architectures out there, unmerged as yet. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] panic: Allow taint flag for warnings to be changed from TAINT_WARN
On Tue, 2010-03-23 at 16:45 +0900, Paul Mundt wrote: On Sat, Mar 20, 2010 at 11:05:40PM +, Ben Hutchings wrote: WARN() is used in some places to report firmware or hardware bugs that are then worked-around. These bugs do not affect the stability of the kernel and should not set the usual TAINT_WARN flag. To allow for this, add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint flag as argument. Architectures that implement warnings using trap instructions instead of calls to warn_slowpath_*() must now implement __WARN_TAINT(taint) instead of __WARN(). Signed-off-by: Ben Hutchings b...@decadent.org.uk --- The architecture-specific changes here are untested and need to be reviewed by architecture maintainers. I'm a bit confused about how this is supposed to work, the TAINT_xxx values are bit positions presently from 0 to 10, while BUGFLAG_xxx are ranged from 0 up. You've set up BUGFLAG_TAINT() to that the TAINT_xxx value is shifted up 8 bits but neglected the fact that the trap type is 16-bits on most (all?) of the platforms using trap-based BUG handling. If the 'taint' in question is just the TAINT_xxx value by itself and will never be a bitmap then that's fine, but there's certainly not enough room to pass the bitmap in on top of the bugflag otherwise (I don't know if this is your intention or not though). Yes, the taint value must be a bit number not a flag. Sloppy wording on my part. Also note that some platforms (like SH) implement additional bugflags, so we at least want to keep the lower byte available for architecture private use. I noticed, that's why I started at 8 not 1. Having said that, the current patch does work for me, although I'm a bit nervous about someone thinking it's ok to pass in a taint bitmap here. We can maybe use BUILD_BUG_ON() here as the taint bit is already required to be a compile-time constant. Ben. Tested-by: Paul Mundt let...@linux-sh.org -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC Patch 0/2] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XV
Hi Ben, Please find the version XV of the patch that ports the hw-breakpoint interfaces (in kernel/hw_breakpoint.c) to PPC64. The new patch includes the changes as listed below. In particular, comments are sought about the changes in Kconfig, Makefile and cputable.h and whether they clearly delimit the changes to the target architecture (ppc64 server processors with one DABR). Changelog - ver XV (Version XIV: linuxppc-dev ref: 20100308181232.ga3...@in.ibm.com) - Additional patch to disable interrupts during data breakpoint exception handling. - Moved HBP_NUM definition to cputable.h under a new CPU_FTR definition (CPU_FTR_HAS_DABR). - Filtering of extraneous exceptions (due to accesses outside symbol length) is by-passed for ptrace requests. - Removed flush_ptrace_hw_breakpoint() from __switch_to() due to incorrect coding placement. - Changes to code comments as per community reviews for previous version. - Minor coding-style changes in hw_breakpoint.c as per review comments. - Re-based to commit ae6be51ed01d6c4aaf249a207b4434bc7785853b of linux-2.6 Thanks, K.Prasad Changelog - ver XIV (Version XIII: linuxppc-dev ref: 20100215055605.gb3...@in.ibm.com) - Removed the 'name' field from 'struct arch_hw_breakpoint'. - All callback invocations through bp-overflow_handler() are replaced with perf_bp_event(). - Removed the check for pre-existing single-stepping mode in hw_breakpoint_handler() as this check is unreliable while in kernel-space. Side effect of this change is the non-triggering of hw-breakpoints while single-stepping kernel through KGDB or Xmon. - Minor code-cleanups and addition of comments in hw_breakpoint_handler() and single_step_dabr_instruction(). - Re-based to commit 25cf84cf377c0aae5dbcf937ea89bc7893db5176 of linux-2.6 Changelog - ver XIII (Version XII: linuxppc-dev ref: 20100121084640.ga3...@in.ibm.com) - Fixed a bug for user-space breakpoints (triggered following the failure of a breakpoint request). - Re-based on commit 724e6d3fe8003c3f60bf404bf22e4e331327c596 of linux-2.6 Changelog - ver XII (Version XI: linuxppc-dev ref: 20100119091234.ga9...@in.ibm.com) - Unset MSR_SE only if kernel was not previously in single-step mode. - Pre-emption is now enabled before returning from the hw-breakpoint exception handler. - Variables to track the source of single-step exception (breakpoint from kernel, user-space vs single-stepping due to other requests) are added. - Extraneous hw-breakpoint exceptions (due to memory accesses lying outside monitored symbol length) is now done for both kernel and user-space (previously only user-space). - single_step_dabr_instruction() now returns NOTIFY_DONE if kernel was in single-step mode even before the hw-breakpoint. This enables other users of single-step mode to be notified of the exception. - User-space instructions are not emulated from kernel-space, they are instead single-stepped. Changelog - ver XI -- (Version X: linuxppc-dev ref: 20091211160144.ga23...@in.ibm.com) - Conditionally unset MSR_SE in the single-step handler - Added comments to explain the duration and need for pre-emption disable following hw-breakpoint exception. Changelog - ver X -- - Re-write the PPC64 patches for the new implementation of hw-breakpoints that uses the perf-layer. - Rebased to commit 7622fc234190a37d4e9fe3ed944a2b61a63fca03 of -tip. Changelog - ver IX --- - Invocation of user-defined callback will be 'trigger-after-execute' (except for ptrace). - Creation of a new global per-CPU breakpoint structure to help invocation of user-defined callback from single-step handler. (Changes made now) - Validation before registration will fail only if the address does not match the kernel symbol's (if specified) resolved address (through kallsyms_lookup_name()). - 'symbolsize' value is expected to within the range contained by the symbol's starting address and the end of a double-word boundary (8 Bytes). - PPC64's arch-dependant code is now aware of 'cpumask' in 'struct hw_breakpoint' and can accomodate requests for a subset of CPUs in the system. - Introduced arch_disable_hw_breakpoint() required for enabledisable_hw_breakpoint() APIs. Changelog - ver VIII --- - Reverting changes to allow one-shot breakpoints only for ptrace requests. - Minor changes in sanity checking in arch_validate_hwbkpt_settings(). - put_cpu_no_resched() is no longer available. Converted to put_cpu(). Changelog - ver VII --- - Allow the one-shot behaviour for exception handlers to be defined by the user. A new 'is_one_shot' flag is added to 'struct arch_hw_breakpoint'. Changelog - ver VI -- The task of identifying 'genuine' breakpoint exceptions from those caused by 'out-of-range' accesses turned out to be more tricky than originally thought. Some changes to
[RFC Patch 1/2] PPC64-HWBKPT: Disable interrupts for data breakpoint exceptions
Data address breakpoint exceptions are currently handled along with page-faults
which require interrupts to remain in enabled state. Since exception handling
for data breakpoints aren't pre-empt safe, we handle them separately.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/kernel/exceptions-64s.S | 12
arch/powerpc/mm/fault.c |2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/exceptions-64s.S
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/exceptions-64s.S
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/exceptions-64s.S
@@ -735,6 +735,9 @@ _STATIC(do_hash_page)
std r3,_DAR(r1)
std r4,_DSISR(r1)
+ andis. r0,r4,0x0040/* Data Address Breakpoint match? */
+ bne-handle_dabr_fault
+
andis. r0,r4,0xa450/* weird error? */
bne-handle_page_fault /* if not, try to insert a HPTE */
BEGIN_FTR_SECTION
@@ -823,6 +826,15 @@ END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISER
bl .raw_local_irq_restore
b 11f
+/* We have a data breakpoint exception - handle it */
+handle_dabr_fault:
+ /* Populate the pt_regs structure */
+ ld r4,_DAR(r1)
+ ld r5,_DSISR(r1)
+ addir3,r1,STACK_FRAME_OVERHEAD
+ bl .do_dabr
+ b .ret_from_except_lite
+
/* Here we have a page fault that hash_page can't handle. */
handle_page_fault:
ENABLE_INTS
Index: linux-2.6.ppc64_test/arch/powerpc/mm/fault.c
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/mm/fault.c
+++ linux-2.6.ppc64_test/arch/powerpc/mm/fault.c
@@ -151,7 +151,7 @@ int __kprobes do_page_fault(struct pt_re
if (!user_mode(regs) (address = TASK_SIZE))
return SIGSEGV;
-#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
+#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE) || defined(CONFIG_PPC64))
if (error_code DSISR_DABRMATCH) {
/* DABR match */
do_dabr(regs, address, error_code);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC Patch 2/2] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
Implement perf-events based hw-breakpoint interfaces for PPC64 processors.
These interfaces help arbitrate requests from various users and schedules
them as appropriate.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/Kconfig |1
arch/powerpc/include/asm/cputable.h |7
arch/powerpc/include/asm/hw_breakpoint.h | 50
arch/powerpc/include/asm/processor.h |6
arch/powerpc/kernel/Makefile |3
arch/powerpc/kernel/hw_breakpoint.c | 324 +++
arch/powerpc/kernel/process.c|3
arch/powerpc/kernel/ptrace.c | 79 +++
8 files changed, 473 insertions(+)
Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
===
--- /dev/null
+++ linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
@@ -0,0 +1,50 @@
+#ifndef_PPC64_HW_BREAKPOINT_H
+#define_PPC64_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#define__ARCH_HW_BREAKPOINT_H
+#ifdef CPU_FTR_HAS_DABR
+
+struct arch_hw_breakpoint {
+ u8 len; /* length of the target data symbol */
+ int type;
+ unsigned long address;
+};
+
+#include linux/kdebug.h
+#include asm/reg.h
+#include asm/system.h
+
+struct perf_event;
+struct pmu;
+struct perf_sample_data;
+
+#define HW_BREAKPOINT_ALIGN 0x7
+/* Maximum permissible length of any HW Breakpoint */
+#define HW_BREAKPOINT_LEN 0x8
+
+extern int arch_validate_hwbkpt_settings(struct perf_event *bp,
+ struct task_struct *tsk);
+extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
+ unsigned long val, void *data);
+int arch_install_hw_breakpoint(struct perf_event *bp);
+void arch_uninstall_hw_breakpoint(struct perf_event *bp);
+void hw_breakpoint_pmu_read(struct perf_event *bp);
+extern void flush_ptrace_hw_breakpoint(struct task_struct *tsk);
+
+extern struct pmu perf_ops_bp;
+extern void ptrace_triggered(struct perf_event *bp, int nmi,
+ struct perf_sample_data *data, struct pt_regs *regs);
+static inline void hw_breakpoint_disable(void)
+{
+ set_dabr(0);
+}
+
+#else
+static inline void hw_breakpoint_disable(void)
+{
+ /* Function is defined only on PPC64 for now */
+}
+#endif /* CPU_FTR_HAS_DABR */
+#endif /* __KERNEL__ */
+#endif /* _PPC64_HW_BREAKPOINT_H */
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
===
--- /dev/null
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
@@ -0,0 +1,324 @@
+/*
+ * HW_breakpoint: a unified kernel/user-space hardware breakpoint facility,
+ * using the CPU's debug registers. Derived from
+ * arch/x86/kernel/hw_breakpoint.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2009 IBM Corporation
+ * Author: K.Prasad pra...@linux.vnet.ibm.com
+ *
+ */
+
+#include linux/hw_breakpoint.h
+#include linux/notifier.h
+#include linux/kprobes.h
+#include linux/percpu.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/sched.h
+#include linux/init.h
+#include linux/smp.h
+
+#include asm/hw_breakpoint.h
+#include asm/processor.h
+#include asm/sstep.h
+
+/*
+ * Store the 'bp' that caused the hw-breakpoint exception just before we
+ * single-step. Use it to distinguish a single-step exception (due to a
+ * previous hw-breakpoint exception) from a normal one
+ */
+static DEFINE_PER_CPU(struct perf_event *, last_hit_bp);
+
+/*
+ * Stores the breakpoints currently in use on each breakpoint address
+ * register for every cpu
+ */
+static DEFINE_PER_CPU(struct perf_event *, bp_per_reg);
+
+/*
+ * Install a perf counter breakpoint.
+ *
+ * We seek a free debug address register and use it for this
+ * breakpoint.
+ *
+ * Atomic: we hold the counter-ctx-lock and we only handle variables
+ * and registers local to this cpu.
+ */
+int arch_install_hw_breakpoint(struct perf_event *bp)
+{
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+ struct perf_event **slot = __get_cpu_var(bp_per_reg);
+
+ *slot = bp;
+ set_dabr(info-address | info-type | DABR_TRANSLATION);
+
Re: Virtio_console usage of early printk
On Tue, Mar 23, 2010 at 9:55 AM, Amit Shah amit.s...@redhat.com wrote:
On (Mon) Mar 22 2010 [18:45:47], François Diakhate wrote:
Hi all,
As far as I can see, early_put_chars is not used by virtio_console
because it checks whether there is a port available before using it.
If I understand correctly, this makes it useless because once we have
a port, we can use the regular virtio transport to output things to
the console. Does the attached patch seem valid ? Feedback from s390
and powerpc users who use this functionality would be appreciated.
Thanks,
François
From 3961f380bbe84a1036ddfc823039cbee31b44dcb Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Fran=C3=A7ois=20Diakhat=C3=A9?= fdi...@gmail.com
Date: Thu, 18 Mar 2010 14:48:20 +0100
Subject: virtio: console: Fix early_put_chars usage
Currently early_put_chars is not used by virtio_console because it can only
be used once a port has been found, at which point it's too late because it
is no longer needed. This patch should fix it.
You'll have to give a signed-off-by for the patch.
Amit
Sorry, I didn't have access to my computer this morning. Here is the
patch with a sign-off, if you still need it.
François
From 209c553355a3ac04e68a9e9560cea90897588304 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Fran=C3=A7ois=20Diakhat=C3=A9?= fdi...@gmail.com
Date: Thu, 18 Mar 2010 14:48:20 +0100
Subject: [PATCH] virtio: console: Fix early_put_chars usage
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Currently early_put_chars is not used by virtio_console because it can only be used once a port has been found, at which point it's too late because it is no longer needed. This patch should fix it.
Signed-off-by: François Diakhaté fdi...@gmail.com
---
drivers/char/virtio_console.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index f404ccf..691ba21 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -645,13 +645,13 @@ static int put_chars(u32 vtermno, const char *buf, int count)
{
struct port *port;
+ if (unlikely(early_put_chars))
+ return early_put_chars(vtermno, buf, count);
+
port = find_port_by_vtermno(vtermno);
if (!port)
return 0;
- if (unlikely(early_put_chars))
- return early_put_chars(vtermno, buf, count);
-
return send_buf(port, (void *)buf, count);
}
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: The GPIO problem on MPC8323?
On Tue, Mar 23, 2010 at 03:07:49PM +0800, liu.yao...@zte.com.cn wrote: hi,all: i saw peter's mpc8xxx_gpio.c in kernel 2.6.31. it seems that file can only be used on 831x and others, but not mpc8323. my platform is mpc8323, how can i use the GPIO? i also found QE GPIO Support and Support for simple, memory-mapped GPIO controllers selection, how can i use it and test in user space? thanks, best regards. This is the same e-mail that you sent yesterday... Yes, you want the QE GPIO driver for QE chips. It should work the same as other GPIO drivers. Check the documentation or the code for how to use the interface. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux patches for XIP on MPC8xx?
Dear Márton Németh, in message 4ba865d4.1090...@freemail.hu you wrote: I found your homepage at http://www.denx.de/wiki/bin/view/DULG/ConfigureLinuxForXIP back from 2003. Was there any follow up of your patch for kernel 2.4.4? There were very few tests done with later kernel versions, and in all practical system configurations we tested we found that XIP did not give real benefits. Usually execution from flash was slower than when running from RAM, and even booting a (inevitably uncompressed) kernel from flash is typically slower than loading a compressed image to RUM and booting from there. So except for some highly specialized applications (you may also call these exotic configurations) XIP for the Linux kernel does not make much sense to me. I am aware that there are reports which come to completely different conclusions - see for example http://www.elinux.org/Kernel_XIP ; but then look carefully - the examples come from hardware with really slow processors, which are probably not typical any more. Actually this is the first thing you should check: the ratio of processor speed versus flash memory bandwidth versus RAM bandwidth. Today you can usually expect CPU clocks way over 400 MHz, and many systems use DDR, while NOR flash speed has noch changed much. Also check if it is possible to map the flash memory cached for your system (which you definitly want when using XIP from flash); this may prevent some flash access methods from working. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Doubt isn't the opposite of faith; it is an element of faith. - Paul Tillich, German theologian and historian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/fsl: add device tree binding for QE firmware
Define a binding for embedding a QE firmware blob into the device tree. Also
define a new property for the QE node that links to a firmware node.
Signed-off-by: Timur Tabi ti...@freescale.com
---
.../powerpc/dts-bindings/fsl/cpm_qe/qe.txt | 50
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
index 6e37be1..d9d6431 100644
--- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt
@@ -20,6 +20,14 @@ Required properties:
- fsl,qe-num-riscs: define how many RISC engines the QE has.
- fsl,qe-num-snums: define how many serial number(SNUM) the QE can use for the
threads.
+- fsl,firmware-phandle:
+Usage: required
+Value type: phandle
+Definition: Points to a firmware node (see QE Firmware Node below)
+that contains the firmware that should be uploaded for this QE.
+The compatible property for the firmware node should say,
+fsl,qe-firmware.
+
Recommended properties
- brg-frequency : the internal clock source frequency for baud-rate
@@ -59,3 +67,45 @@ Example:
reg = 0 c000;
};
};
+
+* QE Firmware Node
+
+This node defines a firmware binary that is embedded in the device tree, for
+the purpose of passing the firmware from bootloader to the kernel, or from
+the hypervisor to the guest.
+
+The firmware node itself contains the firmware binary contents, a compatible
+property, and any firmware-specific properties. The node itself can be located
+anywhere, but should probably be placed at the top level. The QE node
+that needs the firmware should define a property that links to the firmware
+node's phandle.
+
+This node is typically not defined in the DTS. Instead, the boot loader
+normally creates the node from scratch, using a firmware binary that is already
+located in non-volatile storage or transferred from a tftp server.
+
+Required properties:
+ - compatible
+ Usage: required
+ Value type: string
+ Definition: A standard property. Specify a string that indicates what
+ kind of firmware it is. For QE, this should be fsl,qe-firmware.
+
+ - fsl,firmware
+ Usage: required
+ Value type: prop-encoded-array, encoded as an array of bytes
+ Definition: A standard property. This property contains the firmware
+ binary blob.
+
+Example:
+ q...@e008 {
+ compatible = fsl,qe;
+ fsl,firmware-phandle = qe_firmware;
+ ...
+ }
+
+ qe_firmware:qe-firmware {
+ compatible = fsl,qe-firmware;
+ fsl,firmware = 0x70 0xcd 0x00 0x00 0x01 0x46 0x45 0x63 ...
+ }
+
--
1.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
re: Re: The GPIO problem on MPC8323?
thanks for replying. it's my first time to use POWERPC,and i found it very different from ARM. after i select QE GPIO Suppor in KConfig, i don't know how to use in next step. Because no device node was found in /dev, and the format of dts is strange for me. could you show me a little example? On Tue, Mar 23, 2010 at 03:07:49PM +0800, liu.yao...@zte.com.cn wrote: hi,all: i saw peter's mpc8xxx_gpio.c in kernel 2.6.31. it seems that file can only be used on 831x and others, but not mpc8323. my platform is mpc8323, how can i use the GPIO? i also found QE GPIO Support and Support for simple, memory-mapped GPIO controllers selection, how can i use it and test in user space? thanks, best regards. This is the same e-mail that you sent yesterday... Yes, you want the QE GPIO driver for QE chips. It should work the same as other GPIO drivers. Check the documentation or the code for how to use the interface. -Scott ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
SPI Driver for CPM2 8260 (8272 family)
Hi, Is there an SPI Driver in Linux for CPM2 8260-based processors? I'm quite surprised that there doesn't seem to be one. Can someone please explain why this is? Cheers, Daniel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
