Re: [PATCH 01/18] powerpc: Make decrementer interrupt robust against offlined CPUs
On Tue, 2011-03-08 at 17:37 +1100, Benjamin Herrenschmidt wrote: > With some implementations, it is possible that a timer interrupt > occurs every few seconds on an offline CPU. In this case, just > re-arm the decrementer and return immediately > > Signed-off-by: Benjamin Herrenschmidt > --- > arch/powerpc/kernel/time.c | 15 +++ > 1 files changed, 11 insertions(+), 4 deletions(-) > > diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c > index 09d31db..ecebc7c 100644 > --- a/arch/powerpc/kernel/time.c > +++ b/arch/powerpc/kernel/time.c > @@ -577,14 +577,21 @@ void timer_interrupt(struct pt_regs * regs) > struct clock_event_device *evt = &decrementer->event; > u64 now; > > + /* Ensure a positive value is written to the decrementer, or else > + * some CPUs will continuue to take decrementer exceptions ^ Seeing as you're moving it anyway, and maybe a full-stop. 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: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip.
Hi Priyanka, > Though register-set looks identical but features were different. Can you tell what exactly is different? > And also manufacturer is different. That does not matter. If you look at ds_type, there are already different manufacturers. They will be correctly distinguished by i2c_device_id. The name of the driver itself is, well, just a name. > But still it might be possible that we can reuse ds1307.c with some > modification. I agree. The driver already supports some variants. Adding one more should not hurt. See 97f902b7be4dd6ba03c6aa8d3400783ed687ebd1 for an example which added ds3231 support. > But if I look at the drivers present in drivers/rtc folder. Most of > them looks similar but still there are different drivers for different > chips. Yes, it probably could be cleaned up if somebody had the time/hardware. > Please suggest which way is more preferred: modifying existing > drivers(of different manufacturer) or writing new driver. Ususally avoiding code duplication is good, it reduces maintenance burden. However, if adding the support turns out to make the original code unreadable or hard to follow, a new driver might be justified. This is why it is important to understand the differences of the chip as a first step. (I have the feeling, that modifying is the way to go here, though). 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: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip.
Hi Wolfram, > -Original Message- > From: Wolfram Sang [mailto:w.s...@pengutronix.de] > Sent: Thursday, March 10, 2011 2:24 PM > To: Jain Priyanka-B32167 > Cc: rtc-li...@googlegroups.com; linuxppc-dev@lists.ozlabs.org; > a.zu...@towertech.it; p_gortma...@yahoo.com; a...@linux-foundation.org > Subject: Re: [rtc-linux] [PATCH] RTC driver(Linux) for PT7C4338 chip. > > Hi Priyanka, > > > Though register-set looks identical but features were different. > > Can you tell what exactly is different? I will check both the devices data sheets again in detail and will get back on this. > > > And also manufacturer is different. > > That does not matter. If you look at ds_type, there are already different > manufacturers. They will be correctly distinguished by i2c_device_id. The > name of the driver itself is, well, just a name. > > > But still it might be possible that we can reuse ds1307.c with some > > modification. > > I agree. The driver already supports some variants. Adding one more > should not hurt. See 97f902b7be4dd6ba03c6aa8d3400783ed687ebd1 for an > example which added ds3231 support. > > > But if I look at the drivers present in drivers/rtc folder. Most of > > them looks similar but still there are different drivers for different > > chips. > > Yes, it probably could be cleaned up if somebody had the time/hardware. > > > Please suggest which way is more preferred: modifying existing > > drivers(of different manufacturer) or writing new driver. > > Ususally avoiding code duplication is good, it reduces maintenance > burden. However, if adding the support turns out to make the original > code unreadable or hard to follow, a new driver might be justified. This > is why it is important to understand the differences of the chip as a > first step. (I have the feeling, that modifying is the way to go here, > though). > I will explore possibility of using ds1307 driver for this. Thanks Priyanka ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ppc, 82xx: rename and update mgcoge board support
The mgcoge board from keymile is now base for some other
similar boards. Therefore the board specific name mgcoge
was renamed to a generic name km82xx. Additionally some
enhancements were made:
- rework partition table in dts file
- add cpm2_pio_c gpio controller in dts file
- update defconfig
- add pin description for SCC1
- add pin description and configuration for USB
Signed-off-by: Holger Brunck
Acked-by: Heiko Schocher
CC: Benjamin Herrenschmidt
CC: Kumar Gala
CC: Heiko Schocher
---
arch/powerpc/boot/dts/mgcoge.dts | 47 ---
arch/powerpc/configs/mgcoge_defconfig |9 +---
arch/powerpc/platforms/82xx/Makefile |2 +-
arch/powerpc/platforms/82xx/{mgcoge.c => km82xx.c} | 62 ++--
4 files changed, 72 insertions(+), 48 deletions(-)
rename arch/powerpc/platforms/82xx/{mgcoge.c => km82xx.c} (69%)
diff --git a/arch/powerpc/boot/dts/mgcoge.dts b/arch/powerpc/boot/dts/mgcoge.dts
index 0ce9664..1360d2f 100644
--- a/arch/powerpc/boot/dts/mgcoge.dts
+++ b/arch/powerpc/boot/dts/mgcoge.dts
@@ -13,7 +13,7 @@
/dts-v1/;
/ {
model = "MGCOGE";
- compatible = "keymile,mgcoge";
+ compatible = "keymile,km82xx";
#address-cells = <1>;
#size-cells = <1>;
@@ -48,8 +48,10 @@
reg = <0xf0010100 0x40>;
ranges = <0 0 0xfe00 0x0040
- 5 0 0x5000 0x2000
- >; /* Filled in by U-Boot */
+ 1 0 0x3000 0x0001
+ 2 0 0x4000 0x0001
+ 5 0 0x5000 0x0400
+ >;
flash@0,0 {
compatible = "cfi-flash";
@@ -60,36 +62,32 @@
device-width = <1>;
partition@0 {
label = "u-boot";
- reg = <0 0x4>;
+ reg = <0x0 0xC>;
};
- partition@4 {
+ partition@1 {
label = "env";
- reg = <0x4 0x2>;
+ reg = <0xC 0x2>;
};
- partition@6 {
- label = "kernel";
- reg = <0x6 0x22>;
+ partition@2 {
+ label = "envred";
+ reg = <0xE 0x2>;
};
- partition@28 {
- label = "dtb";
- reg = <0x28 0x2>;
+ partition@3 {
+ label = "free";
+ reg = <0x10 0x30>;
};
};
flash@5,0 {
compatible = "cfi-flash";
- reg = <5 0x0 0x200>;
+ reg = <5 0x 0x0200
+ 5 0x0200 0x0200>;
#address-cells = <1>;
#size-cells = <1>;
bank-width = <2>;
- device-width = <2>;
- partition@0 {
- label = "ramdisk";
- reg = <0 0x7a>;
- };
- partition@7a {
- label = "user";
- reg = <0x7a 0x186>;
+ partition@app { /* 64 MBytes */
+ label = "ubi0";
+ reg = <0x 0x0400>;
};
};
};
@@ -217,6 +215,13 @@
};
};
+ cpm2_pio_c: gpio-controller@10d40 {
+ #gpio-cells = <2>;
+ compatible = "fsl,cpm2-pario-bank";
+ reg = <0x10d40 0x14>;
+ gpio-controller;
+ };
+
PIC: interrupt-controller@10c00 {
#interrupt-cells = <2>;
interrupt-controller;
diff --git a/arch/powerpc/configs/mgcoge_defconfig
b/arch/powerpc/configs/mgcoge_defconfig
index 39518e9..6cb588a 100644
--- a/arch/powerpc/configs/mgcoge_defconfig
+++ b/arch/powerpc/configs/mgcoge_defconfig
@@ -1,4 +1,5 @@
CONFIG_SYSVIPC=y
+CONFIG_SPARSE_IRQ=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
@@ -10,7 +11,6 @@ CONFIG_SLAB=y
CONFIG_PPC_82xx=y
CONFIG_MGCOGE=y
CONFIG_BINFMT_MISC=y
-CONFIG_SPARSE_IRQ=y
# CONFIG_SECCOMP is not set
CONFIG_NET=y
CONFIG_PACKET=y
@@ -30,7 +30,6 @@ CONFIG_MTD=y
CONFI
Re: [BUG] rebuild_sched_domains considered dangerous
On Wed, 2011-03-09 at 14:01 +0100, Peter Zijlstra wrote: > On Wed, 2011-03-09 at 11:19 +0100, Peter Zijlstra wrote: > > No, the domain stuff is good, we allocate new domains and have a > > synchronize_sched() between us installing the new ones and freeing the > > old ones. > > Gah, if only.. OK, so for hotplug and cpusets it works because they change the doms_cur set, when the old and the new set don't match it destroys the current sched_domain/sched_group sets for the relevant cpus and then calls synchronize_sched() to wait for any current activity to go away. Only then does it rebuild stuff for the new set, reusing the static allocated sched_domain and sched_group data. Now, supposedly when your new and old domain set is the same it should be a nop, unless arch_update_cpu_topology() returns true in which case it will do a full destroy and rebuild. So I'm not quite sure what power does to make it go bang.. Anyway, I'm now rewriting the sched_domain creation stuff because I've utterly had it with that code.. Also, still waiting to hear from the Power7 folks on how often they think to rebuild the topology and how they think that makes sense, afaict Power7 does have actual NUMA nodes unlike s390, so I'm still not seeing how that's going to work properly at all. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct
On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote: > > Morally, the question of whether an address lies in a gate vma should be asked > with respect to an mm, not a particular task. > > Practically, dropping the dependency on task_struct will help make current and > future operations on mm's more flexible and convenient. In particular, it > allows some code paths to avoid the need to hold task_lock. > > The only architecture this change impacts in any significant way is x86_64. > The principle change on that architecture is to mirror TIF_IA32 via > a new flag in mm_context_t. The problem is -- you're adding a likely cache miss on mm_struct for every 32bit compat syscall now, even if they don't need mm_struct currently (and a lot of them do not) Unless there's a very good justification to make up for this performance issue elsewhere (including numbers) this seems like a bad idea. > This is the first of a two part series that implements safe writes to > /proc/pid/mem. I will be posting the second series to lkml shortly. These Making every syscall slower for /proc/pid/mem doesn't seem like a good tradeoff to me. Please solve this in some other way. -Andi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct II
On Thu, Mar 10, 2011 at 08:00:32AM -0800, Andi Kleen wrote: > On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote: > > > > Morally, the question of whether an address lies in a gate vma should be > > asked > > with respect to an mm, not a particular task. > > > > Practically, dropping the dependency on task_struct will help make current > > and > > future operations on mm's more flexible and convenient. In particular, it > > allows some code paths to avoid the need to hold task_lock. > > > > The only architecture this change impacts in any significant way is x86_64. > > The principle change on that architecture is to mirror TIF_IA32 via > > a new flag in mm_context_t. > > The problem is -- you're adding a likely cache miss on mm_struct for > every 32bit compat syscall now, even if they don't need mm_struct > currently (and a lot of them do not) Unless there's a very good > justification to make up for this performance issue elsewhere > (including numbers) this seems like a bad idea. Hmm I see you're only setting it on exec time actually on rereading the patches. I thought you were changing TS_COMPAT which is in the syscall path. Never mind. I have no problems with doing such a change on exec time. -Andi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct
On Thu, Mar 10, 2011 at 08:00:32AM -0800, Andi Kleen wrote: > On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote: > > > > Morally, the question of whether an address lies in a gate vma should be > > asked > > with respect to an mm, not a particular task. > > > > Practically, dropping the dependency on task_struct will help make current > > and > > future operations on mm's more flexible and convenient. In particular, it > > allows some code paths to avoid the need to hold task_lock. > > > > The only architecture this change impacts in any significant way is x86_64. > > The principle change on that architecture is to mirror TIF_IA32 via > > a new flag in mm_context_t. > > The problem is -- you're adding a likely cache miss on mm_struct for > every 32bit compat syscall now, even if they don't need mm_struct > currently (and a lot of them do not) Unless there's a very good > justification to make up for this performance issue elsewhere > (including numbers) this seems like a bad idea. I do not think this will result in cache misses on the scale you suggest. I am simply mirroring the *state* of the TIF_IA32 flag in mm_struct, not testing/accessing it in the same way. The only place where this flag is accessed (outside the exec() syscall path) is in x86/mm/init_64.c, get_gate_vma(), which in turn is needed by a few, relatively heavy weight, page locking/pinning routines on the mm side (get_user_pages, for example). Patches 3 and 4 in the series show the extent of the change. Or am I missing something? > > /proc/pid/mem. I will be posting the second series to lkml shortly. These > > Making every syscall slower for /proc/pid/mem doesn't seem like a good > tradeoff to me. Please solve this in some other way. > > -Andi -- steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct II
On Thu, Mar 10, 2011 at 08:38:09AM -0800, Andi Kleen wrote: > On Thu, Mar 10, 2011 at 08:00:32AM -0800, Andi Kleen wrote: > > On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote: > > > The only architecture this change impacts in any significant way is > > > x86_64. > > > The principle change on that architecture is to mirror TIF_IA32 via > > > a new flag in mm_context_t. > > > > The problem is -- you're adding a likely cache miss on mm_struct for > > every 32bit compat syscall now, even if they don't need mm_struct > > currently (and a lot of them do not) Unless there's a very good > > justification to make up for this performance issue elsewhere > > (including numbers) this seems like a bad idea. > > Hmm I see you're only setting it on exec time actually on rereading > the patches. I thought you were changing TS_COMPAT which is in > the syscall path. > > Never mind. I have no problems with doing such a change on exec > time. OK. Great! Does this mean I have your ACK'ed by or reviewed by? Thanks for taking a look! -- steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct II
On Thu, Mar 10, 2011 at 11:54:14AM -0500, Stephen Wilson wrote: > > On Thu, Mar 10, 2011 at 08:38:09AM -0800, Andi Kleen wrote: > > On Thu, Mar 10, 2011 at 08:00:32AM -0800, Andi Kleen wrote: > > > On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote: > > > > The only architecture this change impacts in any significant way is > > > > x86_64. > > > > The principle change on that architecture is to mirror TIF_IA32 via > > > > a new flag in mm_context_t. > > > > > > The problem is -- you're adding a likely cache miss on mm_struct for > > > every 32bit compat syscall now, even if they don't need mm_struct > > > currently (and a lot of them do not) Unless there's a very good > > > justification to make up for this performance issue elsewhere > > > (including numbers) this seems like a bad idea. > > > > Hmm I see you're only setting it on exec time actually on rereading > > the patches. I thought you were changing TS_COMPAT which is in > > the syscall path. > > > > Never mind. I have no problems with doing such a change on exec > > time. > > OK. Great! Does this mean I have your ACK'ed by or reviewed by? I didn't read it all, but the first two patches looked ok. -Andi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 2/2] powerpc: make MPIC honor the "pic-no-reset" device tree property
On 03/01/2011 09:22 PM, Benjamin Herrenschmidt wrote:
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index e000cce..7e1be12 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -325,6 +325,8 @@ struct mpic
#ifdef CONFIG_PM
struct mpic_irq_save*save_data;
#endif
+
+ int cpu;
};
Why ? The MPIC isn't specifically associated with a CPU and whatever we
pick as default during boot isn't relevant later on, so I don't see why
we should have global permanent state here.
I agree. I shouldn't have cached that. We should probably introduce a
helper function to get the cpuid, though. The:
unsigned int cpu = 0;
if (mpic->flags & MPIC_PRIMARY)
cpu = hard_smp_processor_id();
code is scattered in three places: '_mpic_cpu_write', '_mpic_cpu_read',
and 'mpic_init'.
/* Check if we have one of those nice broken MPICs with a flipped endian on
@@ -622,6 +631,14 @@ static unsigned int mpic_is_ipi(struct mpic *mpic,
unsigned int irq)
return (src>= mpic->ipi_vecs[0]&& src<= mpic->ipi_vecs[3]);
}
+/* Determine if the linux irq is a timer interrupt */
+static unsigned int mpic_is_timer_interrupt(struct mpic *mpic, unsigned int
irq)
+{
+ unsigned int src = mpic_irq_to_hw(irq);
+
+ return (src>= mpic->timer_vecs[0]&& src<= mpic->timer_vecs[3]);
+}
+
/* Convert a cpu mask from logical to physical cpu numbers. */
static inline u32 mpic_physmask(u32 cpumask)
@@ -967,6 +984,15 @@ static int mpic_host_map(struct irq_host *h, unsigned int
virq,
if (hw>= mpic->irq_count)
return -EINVAL;
+ /* If the MPIC was reset, then all vectors have already been
+* initialized. Otherwise, the appropriate vector needs to be
+* initialized here to ensure that only used sources are setup with
+* a vector.
+*/
+ if (mpic->flags& MPIC_NO_RESET)
+ if (!(mpic_is_ipi(mpic, hw) || mpic_is_timer_interrupt(mpic,
hw)))
+ mpic_init_vector(mpic, hw);
+
The above isn't useful. Of those two registers you want to initialize,
afaik, one (the destination) will be initialized by the core calling
into set_affinity when the interrupt is requested, and the other one is
AFAIK, we can't rely on 'set_affinity' always being called. I don't
think it is called at all when !defined(CONFIG_SMP) and if it was, then
that would be an error:
/* include/linux/irq.h */
#else /* CONFIG_SMP */
static inline int irq_set_affinity(unsigned int irq,
const struct cpumask *m)
{
return -EINVAL;
}
partially initialized in set_type, I'd say just modify set_type to
initialize the source as well, and problem solved, no ?
The priority has to be initialized as well. They could both be done in
'mpic_set_irq_type', but that seems like a weird place since it has
nothing to do with actually setting the type.
Since we already have 'mpic_irq_set_priority' and 'mpic_set_vector',
perhaps a better option is to add 'mpic_set_destination' and put the
following in 'mpic_host_map' (using the cpuid helper function suggested
above):
/* Lazy source init when MPIC_NO_RESET */
if (!mpic_is_ipi(mpic, hw) && (mpic->flags & MPIC_NO_RESET)) {
mpic_set_vector(virq, hw);
mpic_set_destination(virq, mpic_cpuid(mpic));
mpic_irq_set_priority(virq, 8);
}
It is more overhead, but it reads well. Thoughts?
Or is there a chance that the interrupt was left unmasked ?
There shouldn't be. The original idea was that either the boot program
would leave it masked or one of the AMP OSes would boot without
'pic-no-reset', which would mask everything. Most likely the boot program.
I think it would be kosher to mask it in set_type unconditionally, I don't
think it's ever supposed
to be called for an enabled interrupt.
I will look into that.
Thanks,
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct II
Sorry... I confused them too. It's TS_COMPAT which is problematic. -- Sent from my mobile phone. Please pardon any lack of formatting. Stephen Wilson wrote: On Thu, Mar 10, 2011 at 08:38:09AM -0800, Andi Kleen wrote: > On Thu, Mar 10, 2011 at 08:00:32AM -0800, Andi Kleen wrote: > > On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote: > > > The only architecture this change impacts in any significant way is x86_64. > > > The principle change on that architecture is to mirror TIF_IA32 via > > > a new flag in mm_context_t. > > > > The problem is -- you're adding a likely cache miss on mm_struct for > > every 32bit compat syscall now, even if they don't need mm_struct > > currently (and a lot of them do not) Unless there's a very good > > justification to make up for this performance issue elsewhere > > (including numbers) this seems like a bad idea. > > Hmm I see you're only setting it on exec time actually on rereading > the patches. I thought you were changing TS_COMPAT which is in > the syscall path. > > Never mind. I have no problems with doing such a change on exec > time. OK. Great! Does this mean I have your ACK'e! d by or reviewed by? Thanks for taking a look! -- steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/5] make *_gate_vma accept mm_struct instead of task_struct
TIF_IA32 is set during the execution of a 32-bit system call - so touched on each compat system call. Is this the actual flag you want? A 32-bit address space flag is different from TIF_IA32. -- Sent from my mobile phone. Please pardon any lack of formatting. Stephen Wilson wrote: On Thu, Mar 10, 2011 at 08:00:32AM -0800, Andi Kleen wrote: > On Tue, Mar 08, 2011 at 07:31:56PM -0500, Stephen Wilson wrote: > > > > Morally, the question of whether an address lies in a gate vma should be asked > > with respect to an mm, not a particular task. > > > > Practically, dropping the dependency on task_struct will help make current and > > future operations on mm's more flexible and convenient. In particular, it > > allows some code paths to avoid the need to hold task_lock. > > > > The only architecture this change impacts in any significant way is x86_64. > > The principle change on that architecture is to mirror TIF_IA32 via > > a new flag in mm_context_t. > > The problem is -- you're adding a likely cache miss on mm_struct for > every 32bit compat syscall now, even if they don't need mm_struct > currently (and a lot of them do not) Unless there's a very good > justification to make up for this performance issue elsewhere > (including numbers) this seems like ! a bad idea. I do not think this will result in cache misses on the scale you suggest. I am simply mirroring the *state* of the TIF_IA32 flag in mm_struct, not testing/accessing it in the same way. The only place where this flag is accessed (outside the exec() syscall path) is in x86/mm/init_64.c, get_gate_vma(), which in turn is needed by a few, relatively heavy weight, page locking/pinning routines on the mm side (get_user_pages, for example). Patches 3 and 4 in the series show the extent of the change. Or am I missing something? > > /proc/pid/mem. I will be posting the second series to lkml shortly. These > > Making every syscall slower for /proc/pid/mem doesn't seem like a good > tradeoff to me. Please solve this in some other way. > > -Andi -- steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: fsl_udc_core not initializing properly?
On Sat, Feb 19, 2011 at 1:01 PM, Matthew L. Creech wrote:
>
> Yes, it's there. Here's the DTS entry in case anything else sticks out:
>
> usb@23000 {
> compatible = "fsl-usb2-dr";
> reg = <0x23000 0x1000>;
> #address-cells = <1>;
> #size-cells = <0>;
> interrupt-parent = <&ipic>;
> interrupts = <38 0x8>;
> phy_type = "utmi_wide";
> dr_mode = "peripheral";
> sleep = <&pmc 0x0030>;
> };
>
Hi Anatolij,
I tracked the problem down to a change made in September, which
happens to be yours:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=126512e3f274802ca65ebeca8660237f0361ad48
When I roll this back, everything works fine again.
First of all, I noticed that fsl-mph-dr-of.c isn't even compiling for
me (even though I have the option enabled in my .config), because it's
been placed in "usb/host/", and I'm only using device/gadget-mode USB.
I edited the top-level Makefile to just force it into "usb/host/", and
that makes sure that your driver gets built (and it's probed just fine
at runtime). But that still didn't solve the problem - as before,
fsl_udc_probe() is never being called.
Did you test this change in device mode? I'm wondering if there's
something different about my configuration that prevents it from
working. My config is uploaded here if it helps:
http://mcreech.com/work/linux.config
Thanks!
--
Matthew L. Creech
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 2/2] powerpc: make MPIC honor the "pic-no-reset" device tree property
On Thu, 2011-03-10 at 11:23 -0600, Meador Inge wrote: > I agree. I shouldn't have cached that. We should probably introduce a > helper function to get the cpuid, though. The: > > unsigned int cpu = 0; > > if (mpic->flags & MPIC_PRIMARY) > cpu = hard_smp_processor_id(); > > code is scattered in three places: '_mpic_cpu_write', '_mpic_cpu_read', > and 'mpic_init'. Right, but that code must act on the current CPU, not a cached per-MPIC variant. Doing a helper to factor the above 2 lines is fine if you wish to do so but then make it a separate patch. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 2/2] powerpc: make MPIC honor the "pic-no-reset" device tree property
On Thu, 2011-03-10 at 11:23 -0600, Meador Inge wrote:
> AFAIK, we can't rely on 'set_affinity' always being called. I don't
> think it is called at all when !defined(CONFIG_SMP) and if it was,
> then that would be an error:
>
> /* include/linux/irq.h */
>
> #else /* CONFIG_SMP */
>
> static inline int irq_set_affinity(unsigned int irq,
> const struct cpumask *m)
> {
> return -EINVAL;
> }
You are right. We do need to set a sane default then.
> > partially initialized in set_type, I'd say just modify set_type to
> > initialize the source as well, and problem solved, no ?
>
> The priority has to be initialized as well. They could both be done
> in
> 'mpic_set_irq_type', but that seems like a weird place since it has
> nothing to do with actually setting the type.
>
> Since we already have 'mpic_irq_set_priority' and 'mpic_set_vector',
> perhaps a better option is to add 'mpic_set_destination' and put the
> following in 'mpic_host_map' (using the cpuid helper function
> suggested
> above):
>
> /* Lazy source init when MPIC_NO_RESET */
> if (!mpic_is_ipi(mpic, hw) && (mpic->flags & MPIC_NO_RESET)) {
> mpic_set_vector(virq, hw);
> mpic_set_destination(virq, mpic_cpuid(mpic));
> mpic_irq_set_priority(virq, 8);
> }
>
> It is more overhead, but it reads well. Thoughts?
No objection.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] driver/FSL SATA: Update RX_WATER_MARK for TRANSCFG
Hi Jeff,
I am not finding any comments on this.
Could you please ACK this patch so that it can be applied in external list.
--Prabhakar
> -Original Message-
> From: Kushwaha Prabhakar-B32579
> Sent: Monday, March 07, 2011 10:00 AM
> To: linux-...@vger.kernel.org
> Cc: jgar...@pobox.com; meet2pra...@gmail.com; linuxppc-
> d...@lists.ozlabs.org; Kushwaha Prabhakar-B32579
> Subject: [PATCH] driver/FSL SATA: Update RX_WATER_MARK for TRANSCFG
>
> RX_WATER_MARK sets the number of locations in Rx FIFO that can be used
> before the transport layer instructs the link layer to transmit HOLDS.
> Note that it can take some time for the HOLDs to get to the other end,
> and that in the interim there must be enough room in the FIFO to absorb
> all data that could arrive.
>
> Update the new recommended value to 16.
>
> Signed-off-by: Prabhakar Kushwaha
> ---
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> (branch master)
>
> This patch is already gone through review of linuxppc-dev mail list.
> Making CC linuxppc-dev@lists.ozlabs.org
>
> drivers/ata/sata_fsl.c | 12
> 1 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index
> 895771c..29d2f29 100644
> --- a/drivers/ata/sata_fsl.c
> +++ b/drivers/ata/sata_fsl.c
> @@ -186,6 +186,11 @@ enum {
> COMMANDSTAT = 0x20,
> };
>
> +/* TRANSCFG (transport-layer) configuration control */ enum {
> + TRANSCFG_RX_WATER_MARK = (1 << 4),
> +};
> +
> /* PHY (link-layer) configuration control */ enum {
> PHY_BIST_ENABLE = 0x01,
> @@ -1305,6 +1310,7 @@ static int sata_fsl_probe(struct platform_device
> *ofdev,
> struct sata_fsl_host_priv *host_priv = NULL;
> int irq;
> struct ata_host *host;
> + u32 temp;
>
> struct ata_port_info pi = sata_fsl_port_info[0];
> const struct ata_port_info *ppi[] = { &pi, NULL }; @@ -1319,6
> +1325,12 @@ static int sata_fsl_probe(struct platform_device *ofdev,
> ssr_base = hcr_base + 0x100;
> csr_base = hcr_base + 0x140;
>
> + if (!of_device_is_compatible(ofdev->dev.of_node, "fsl,mpc8315-
> sata")) {
> + temp = ioread32(csr_base + TRANSCFG);
> + temp = temp & 0xffe0;
> + iowrite32(temp | TRANSCFG_RX_WATER_MARK, csr_base +
> TRANSCFG);
> + }
> +
> DPRINTK("@reset i/o = 0x%x\n", ioread32(csr_base + TRANSCFG));
> DPRINTK("sizeof(cmd_desc) = %d\n", sizeof(struct command_desc));
> DPRINTK("sizeof(#define cmd_desc) = %d\n", SATA_FSL_CMD_DESC_SIZE);
> --
> 1.7.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] ppc, 83xx: rename and update kmeter1
Beside the MPC 8360 based board kmeter1 other km83xx boards
from keymile will follow. Therefore the board specific naming
kmeter1 for functions and files were replaced with km83xx.
Additionally some updates were made:
- update defconfig for 2.6.38
- rework flash partitioning in dts file
- add gpio controller for qe_pio_c in dts
Signed-off-by: Holger Brunck
Acked-by: Heiko Schocher
CC: Benjamin Herrenschmidt
CC: Kumar Gala
CC: Heiko Schocher
---
arch/powerpc/boot/dts/kmeter1.dts | 69 +++-
arch/powerpc/configs/83xx/kmeter1_defconfig|7 +--
arch/powerpc/platforms/83xx/Makefile |2 +-
.../powerpc/platforms/83xx/{kmeter1.c => km83xx.c} | 46 +
4 files changed, 71 insertions(+), 53 deletions(-)
rename arch/powerpc/platforms/83xx/{kmeter1.c => km83xx.c} (80%)
diff --git a/arch/powerpc/boot/dts/kmeter1.dts
b/arch/powerpc/boot/dts/kmeter1.dts
index d8b5d12..d16bae1 100644
--- a/arch/powerpc/boot/dts/kmeter1.dts
+++ b/arch/powerpc/boot/dts/kmeter1.dts
@@ -1,7 +1,7 @@
/*
* Keymile KMETER1 Device Tree Source
*
- * 2008 DENX Software Engineering GmbH
+ * 2008-2011 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
@@ -70,11 +70,11 @@
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
- compatible = "fsl-i2c";
+ compatible = "fsl,mpc8313-i2c","fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <14 0x8>;
interrupt-parent = <&ipic>;
- dfsrr;
+ clock-frequency = <40>;
};
serial0: serial@4500 {
@@ -137,6 +137,13 @@
compatible = "fsl,mpc8360-par_io";
num-ports = <7>;
+ qe_pio_c: gpio-controller@30 {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360-qe-pario-bank",
+"fsl,mpc8323-qe-pario-bank";
+ reg = <0x1430 0x18>;
+ gpio-controller;
+ };
pio_ucc1: ucc_pin@0 {
reg = <0>;
@@ -472,7 +479,17 @@
#address-cells = <0>;
#interrupt-cells = <1>;
reg = <0x80 0x80>;
- interrupts = <32 8 33 8>;
+ big-endian;
+ interrupts = <
+ 32 0x8
+ 33 0x8
+ 34 0x8
+ 35 0x8
+ 40 0x8
+ 41 0x8
+ 42 0x8
+ 43 0x8
+ >;
interrupt-parent = <&ipic>;
};
};
@@ -484,43 +501,31 @@
compatible = "fsl,mpc8360-localbus", "fsl,pq2pro-localbus",
"simple-bus";
reg = <0xe0005000 0xd8>;
- ranges = <0 0 0xf000 0x0400>; /* Filled in by U-Boot
*/
+ ranges = <0 0 0xf000 0x0400 /* LB 0 */
+ 1 0 0xe800 0x0100 /* LB 1 */
+ 3 0 0xa000 0x1000>; /* LB 3 */
- flash@f000,0 {
+ flash@0,0 {
compatible = "cfi-flash";
- /*
-* The Intel P30 chip has 2 non-identical chips on
-* one die, so we need to define 2 separate regions
-* that are scanned by physmap_of independantly.
-*/
- reg = <0 0x 0x0200
- 0 0x0200 0x0200>;/* Filled in by
U-Boot */
- bank-width = <2>;
+ reg = <0 0 0x0400>;
#address-cells = <1>;
#size-cells = <1>;
- partition@0 {
+ bank-width = <2>;
+ partition@0 { /* 768KB */
label = "u-boot";
- reg = <0 0x4>;
+ reg = <0 0xC>;
};
- partition@4 {
+ partition@c { /* 128KB */
label = "env";
