* [PATCH v2] powerpc/kexec: Fix orphaned offline CPUs across kexec
From: Matt Evans @ 2010-07-29 5:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Milton Miller
When CPU hotplug is used, some CPUs may be offline at the time a kexec is
performed. The subsequent kernel may expect these CPUs to be already running,
and will declare them stuck. On pseries, there's also a soft-offline (cede)
state that CPUs may be in; this can also cause problems as the kexeced kernel
may ask RTAS if they're online -- and RTAS would say they are. Again, stuck.
This patch kicks each present offline CPU awake before the kexec, so that
none are lost to these assumptions in the subsequent kernel.
Signed-off-by: Matt Evans <matt@ozlabs.org>
---
v2: Added FIXME comment noting a possible problem with incorrectly
started secondary CPUs, following feedback from Milton.
arch/powerpc/kernel/machine_kexec_64.c | 55 ++++++++++++++++++++++++++++---
1 files changed, 49 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index 4fbb3be..37f805e 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -15,6 +15,8 @@
#include <linux/thread_info.h>
#include <linux/init_task.h>
#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/cpu.h>
#include <asm/page.h>
#include <asm/current.h>
@@ -181,7 +183,20 @@ static void kexec_prepare_cpus_wait(int wait_state)
int my_cpu, i, notified=-1;
my_cpu = get_cpu();
- /* Make sure each CPU has atleast made it to the state we need */
+ /* Make sure each CPU has at least made it to the state we need.
+ *
+ * FIXME: There is a (slim) chance of a problem if not all of the CPUs
+ * are correctly onlined. If somehow we start a CPU on boot with RTAS
+ * start-cpu, but somehow that CPU doesn't write callin_cpu_map[] in
+ * time, the boot CPU will timeout. If it does eventually execute
+ * stuff, the secondary will start up (paca[].cpu_start was written) and
+ * get into a peculiar state. If the platform supports
+ * smp_ops->take_timebase(), the secondary CPU will probably be spinning
+ * in there. If not (i.e. pseries), the secondary will continue on and
+ * try to online itself/idle/etc. If it survives that, we need to find
+ * these possible-but-not-online-but-should-be CPUs and chaperone them
+ * into kexec_smp_wait().
+ */
for_each_online_cpu(i) {
if (i == my_cpu)
continue;
@@ -189,9 +204,9 @@ static void kexec_prepare_cpus_wait(int wait_state)
while (paca[i].kexec_state < wait_state) {
barrier();
if (i != notified) {
- printk( "kexec: waiting for cpu %d (physical"
- " %d) to enter %i state\n",
- i, paca[i].hw_cpu_id, wait_state);
+ printk(KERN_INFO "kexec: waiting for cpu %d "
+ "(physical %d) to enter %i state\n",
+ i, paca[i].hw_cpu_id, wait_state);
notified = i;
}
}
@@ -199,9 +214,32 @@ static void kexec_prepare_cpus_wait(int wait_state)
mb();
}
-static void kexec_prepare_cpus(void)
+/*
+ * We need to make sure each present CPU is online. The next kernel will scan
+ * the device tree and assume primary threads are online and query secondary
+ * threads via RTAS to online them if required. If we don't online primary
+ * threads, they will be stuck. However, we also online secondary threads as we
+ * may be using 'cede offline'. In this case RTAS doesn't see the secondary
+ * threads as offline -- and again, these CPUs will be stuck.
+ *
+ * So, we online all CPUs that should be running, including secondary threads.
+ */
+static void wake_offline_cpus(void)
{
+ int cpu = 0;
+ for_each_present_cpu(cpu) {
+ if (!cpu_online(cpu)) {
+ printk(KERN_INFO "kexec: Waking offline cpu %d.\n",
+ cpu);
+ cpu_up(cpu);
+ }
+ }
+}
+
+static void kexec_prepare_cpus(void)
+{
+ wake_offline_cpus();
smp_call_function(kexec_smp_down, NULL, /* wait */0);
local_irq_disable();
mb(); /* make sure IRQs are disabled before we say they are */
@@ -215,7 +253,10 @@ static void kexec_prepare_cpus(void)
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(0, 0);
- /* Before removing MMU mapings make sure all CPUs have entered real mode */
+ /*
+ * Before removing MMU mappings make sure all CPUs have entered real
+ * mode:
+ */
kexec_prepare_cpus_wait(KEXEC_STATE_REAL_MODE);
put_cpu();
@@ -284,6 +325,8 @@ void default_machine_kexec(struct kimage *image)
if (crashing_cpu == -1)
kexec_prepare_cpus();
+ pr_debug("kexec: Starting switchover sequence.\n");
+
/* switch to a staticly allocated stack. Based on irq stack code.
* XXX: the task struct will likely be invalid once we do the copy!
*/
--
1.6.3.3
^ permalink raw reply related
* [PATCH 0/6] Remove owner field from sysfs attribute structure
From: Guenter Roeck @ 2010-07-29 5:09 UTC (permalink / raw)
To: James E.J. Bottomley, Richard Purdie, Greg Kroah-Hartman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: Guenter Roeck, Nick Cheng, Linus Walleij, James Smart,
linuxppc-dev, Eric W. Biederman, Dmitry Torokhov, Mark Brown,
linux-kernel, Chris Wright, Tejun Heo, Alex Iannicelli,
Jani Nikula, Jean Delvare, Benjamin Thery, linux-scsi,
Liam Girdwood
The following comment is found in include/linux/sysfs.h:
/* FIXME
* The *owner field is no longer used.
* x86 tree has been cleaned up. The owner
* attribute is still left for other arches.
*/
As it turns out, the *owner field is (again?) initialized in several modules,
suggesting that such initialization may be creeping back into the code.
This patch set removes the above comment, the *owner field, and each instance
in the code where it was found to be initialized.
Compiled with x86 allmodconfig as well as with all alpha, arm, mips, powerpc,
and sparc defconfig builds.
^ permalink raw reply
* [PATCH 1/6] scsi: Remove owner field from attribute initialization in LPFC driver
From: Guenter Roeck @ 2010-07-29 5:09 UTC (permalink / raw)
To: James E.J. Bottomley, Richard Purdie, Greg Kroah-Hartman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: Guenter Roeck, Nick Cheng, Linus Walleij, James Smart,
linuxppc-dev, Eric W. Biederman, Dmitry Torokhov, Mark Brown,
linux-kernel, Chris Wright, Tejun Heo, Alex Iannicelli,
Jani Nikula, Jean Delvare, Benjamin Thery, linux-scsi,
Liam Girdwood
In-Reply-To: <1280380166-29196-1-git-send-email-guenter.roeck@ericsson.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
---
drivers/scsi/lpfc/lpfc_attr.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index bf33b31..8f89edf 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -2720,7 +2720,6 @@ static struct bin_attribute sysfs_drvr_stat_data_attr = {
.attr = {
.name = "lpfc_drvr_stat_data",
.mode = S_IRUSR,
- .owner = THIS_MODULE,
},
.size = LPFC_MAX_TARGET * MAX_STAT_DATA_SIZE_PER_TARGET,
.read = sysfs_drvr_stat_data_read,
--
1.7.0.87.g0901d
^ permalink raw reply related
* [PATCH 5/6] powerpc/pci: Remove owner field from attribute initialization in PCI bridge init
From: Guenter Roeck @ 2010-07-29 5:09 UTC (permalink / raw)
To: James E.J. Bottomley, Richard Purdie, Greg Kroah-Hartman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: Guenter Roeck, Nick Cheng, Linus Walleij, James Smart,
linuxppc-dev, Eric W. Biederman, Dmitry Torokhov, Mark Brown,
linux-kernel, Chris Wright, Tejun Heo, Alex Iannicelli,
Jani Nikula, Jean Delvare, Benjamin Thery, linux-scsi,
Liam Girdwood
In-Reply-To: <1280380166-29196-1-git-send-email-guenter.roeck@ericsson.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
---
arch/powerpc/sysdev/mv64x60_pci.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/mv64x60_pci.c b/arch/powerpc/sysdev/mv64x60_pci.c
index 198f288..77bb3f4 100644
--- a/arch/powerpc/sysdev/mv64x60_pci.c
+++ b/arch/powerpc/sysdev/mv64x60_pci.c
@@ -73,7 +73,6 @@ static struct bin_attribute mv64x60_hs_reg_attr = { /* Hotswap register */
.attr = {
.name = "hs_reg",
.mode = S_IRUGO | S_IWUSR,
- .owner = THIS_MODULE,
},
.size = MV64X60_VAL_LEN_MAX,
.read = mv64x60_hs_reg_read,
--
1.7.0.87.g0901d
^ permalink raw reply related
* [PATCH 6/6] Remove owner field from sysfs struct attribute
From: Guenter Roeck @ 2010-07-29 5:09 UTC (permalink / raw)
To: James E.J. Bottomley, Richard Purdie, Greg Kroah-Hartman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: Guenter Roeck, Nick Cheng, Linus Walleij, James Smart,
linuxppc-dev, Eric W. Biederman, Dmitry Torokhov, Mark Brown,
linux-kernel, Chris Wright, Tejun Heo, Alex Iannicelli,
Jani Nikula, Jean Delvare, Benjamin Thery, linux-scsi,
Liam Girdwood
In-Reply-To: <1280380166-29196-1-git-send-email-guenter.roeck@ericsson.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
---
include/linux/sysfs.h | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index f2694eb..880fa1a 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -22,14 +22,8 @@ struct kobject;
struct module;
enum kobj_ns_type;
-/* FIXME
- * The *owner field is no longer used.
- * x86 tree has been cleaned up. The owner
- * attribute is still left for other arches.
- */
struct attribute {
const char *name;
- struct module *owner;
mode_t mode;
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lock_class_key *key;
--
1.7.0.87.g0901d
^ permalink raw reply related
* [PATCH 2/6] scsi: Remove owner field from attribute initialization in ARCMSR driver
From: Guenter Roeck @ 2010-07-29 5:09 UTC (permalink / raw)
To: James E.J. Bottomley, Richard Purdie, Greg Kroah-Hartman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: Guenter Roeck, Nick Cheng, Linus Walleij, James Smart,
linuxppc-dev, Eric W. Biederman, Dmitry Torokhov, Mark Brown,
linux-kernel, Chris Wright, Tejun Heo, Alex Iannicelli,
Jani Nikula, Jean Delvare, Benjamin Thery, linux-scsi,
Liam Girdwood
In-Reply-To: <1280380166-29196-1-git-send-email-guenter.roeck@ericsson.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
---
drivers/scsi/arcmsr/arcmsr_attr.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/arcmsr/arcmsr_attr.c b/drivers/scsi/arcmsr/arcmsr_attr.c
index 07fdfe5..a4e04c5 100644
--- a/drivers/scsi/arcmsr/arcmsr_attr.c
+++ b/drivers/scsi/arcmsr/arcmsr_attr.c
@@ -192,7 +192,6 @@ static struct bin_attribute arcmsr_sysfs_message_read_attr = {
.attr = {
.name = "mu_read",
.mode = S_IRUSR ,
- .owner = THIS_MODULE,
},
.size = 1032,
.read = arcmsr_sysfs_iop_message_read,
@@ -202,7 +201,6 @@ static struct bin_attribute arcmsr_sysfs_message_write_attr = {
.attr = {
.name = "mu_write",
.mode = S_IWUSR,
- .owner = THIS_MODULE,
},
.size = 1032,
.write = arcmsr_sysfs_iop_message_write,
@@ -212,7 +210,6 @@ static struct bin_attribute arcmsr_sysfs_message_clear_attr = {
.attr = {
.name = "mu_clear",
.mode = S_IWUSR,
- .owner = THIS_MODULE,
},
.size = 1,
.write = arcmsr_sysfs_iop_message_clear,
--
1.7.0.87.g0901d
^ permalink raw reply related
* [PATCH 3/6] leds: Remove owner field from attribute initialization in bd2802 driver
From: Guenter Roeck @ 2010-07-29 5:09 UTC (permalink / raw)
To: James E.J. Bottomley, Richard Purdie, Greg Kroah-Hartman,
Benjamin Herrenschmidt, Paul Mackerras
Cc: Guenter Roeck, Nick Cheng, Linus Walleij, James Smart,
linuxppc-dev, Eric W. Biederman, Dmitry Torokhov, Mark Brown,
linux-kernel, Chris Wright, Tejun Heo, Alex Iannicelli,
Jani Nikula, Jean Delvare, Benjamin Thery, linux-scsi,
Liam Girdwood
In-Reply-To: <1280380166-29196-1-git-send-email-guenter.roeck@ericsson.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
---
drivers/leds/leds-bd2802.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/leds/leds-bd2802.c b/drivers/leds/leds-bd2802.c
index 5dcdf9d..19dc4b6 100644
--- a/drivers/leds/leds-bd2802.c
+++ b/drivers/leds/leds-bd2802.c
@@ -351,7 +351,7 @@ static ssize_t bd2802_store_reg##reg_addr(struct device *dev, \
return count; \
} \
static struct device_attribute bd2802_reg##reg_addr##_attr = { \
- .attr = {.name = reg_name, .mode = 0644, .owner = THIS_MODULE}, \
+ .attr = {.name = reg_name, .mode = 0644}, \
.store = bd2802_store_reg##reg_addr, \
};
@@ -482,7 +482,6 @@ static struct device_attribute bd2802_adv_conf_attr = {
.attr = {
.name = "advanced_configuration",
.mode = 0644,
- .owner = THIS_MODULE
},
.show = bd2802_show_adv_conf,
.store = bd2802_store_adv_conf,
@@ -519,7 +518,6 @@ static struct device_attribute bd2802_##attr_name##_attr = { \
.attr = { \
.name = name_str, \
.mode = 0644, \
- .owner = THIS_MODULE \
}, \
.show = bd2802_show_##attr_name, \
.store = bd2802_store_##attr_name, \
--
1.7.0.87.g0901d
^ permalink raw reply related
* i meet some surprising things,when i modify the dts file
From: hacklu @ 2010-07-29 6:08 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]
localbus@f0010100 {
....
ranges = <
0 0 FC000000 1000000
2 0 FA000000 1000000
1 0 70000000 1000000
>;
flash@0,0{
.....
}
flash@2,0{
....
}
board-control@1,0{
.....
}
}
this is part of my dts files. I don't kown what each field means in the config rangs.
for instance, 2 0 FA000000 1000000 .
I only konw this:
"2" is means chip selects.
"0" is what?
"Fa00000" means the start address.
"1000000" means the range of the device
but ,I got some puzzled.
when I set the two flash in the 0,1 chips select or 0,2 chips select my linux works well.
and, the board-control only can be set at 1 chis select,otherwise the pci doesn't be detected.
so , what is the chips select? is it based on hardware? but my flash can use 0,1,2 chips select.
or it is just set by software? but my pci devece can only work in 1 chips select.
BTW:
I also want to know how to write the dts file. I want to understand each node in the dts files.
but I can't get enough documents. I have readed the linux/document/...
could you privode me some useful information?
thank you ver much~
2010-07-29
hacklu
[-- Attachment #2: Type: text/html, Size: 4617 bytes --]
^ permalink raw reply
* Re: Memory Mapping Buffers smaller than page size?
From: Ravi Gupta @ 2010-07-29 6:15 UTC (permalink / raw)
To: Simon Richter; +Cc: linuxppc-dev
In-Reply-To: <20100728142140.GA9494@richter>
[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]
Hi Simon,
Thanks for the quick reply. One more thing I want to ask is what if I create
a dma pool (using pci_pool_create()), allocate dma buffers from that pool
and then try to memory map them? will the buffers in that case will be
continuous and is it possible to memory map them in a single user space
page?
Thanks in advance
Ravi Gupta
On Wed, Jul 28, 2010 at 7:51 PM, Simon Richter <Simon.Richter@hogyros.de>wrote:
> Hi,
>
> On Wed, Jul 28, 2010 at 06:44:10PM +0530, Ravi Gupta wrote:
>
> > I am new to linux device drivers development. I have created 16 buffers
> of
> > size 256 bytes each(using kmalloc()) in my device driver code. I want to
> > memory map these buffers to user space. Now is it possible to memory map
> > these buffer(16*256 = 4096 = 1 page on 32 bit linux) into a single page
> in
> > user space OR i have to map them in individual pages in user space? Note,
> > all the buffers may not be stored in continuous memory location.
>
> Pages are the smallest unit for mappings, so each buffer would end up in
> its own mapping. If you want the buffers to be accessible without an
> offset, then you cannot have them in continuous locations, as you cannot
> map memory from the middle of a page to the beginning either.
>
> So your options are: one page per buffer (wasteful, but gives you
> granular access control), or allocating all the buffers as a single
> block.
>
> Simon
>
[-- Attachment #2: Type: text/html, Size: 1848 bytes --]
^ permalink raw reply
* Re: [PATCH 0/6] Remove owner field from sysfs attribute structure
From: Eric Biederman @ 2010-07-29 6:16 UTC (permalink / raw)
To: Guenter Roeck
Cc: Mark Brown, Jani Nikula, Linus Walleij, James Smart, linuxppc-dev,
Greg Kroah-Hartman, linux-kernel, Chris Wright, Tejun Heo,
James E.J. Bottomley, Richard Purdie, Nick Cheng, Dmitry Torokhov,
Jean Delvare, Paul Mackerras, Benjamin Thery, linux-scsi,
Alex Iannicelli, Liam Girdwood
In-Reply-To: <1280380166-29196-1-git-send-email-guenter.roeck@ericsson.com>
On Wed, Jul 28, 2010 at 10:09 PM, Guenter Roeck
<guenter.roeck@ericsson.com> wrote:
> The following comment is found in include/linux/sysfs.h:
>
> =A0 /* FIXME
> =A0 =A0* The *owner field is no longer used.
> =A0 =A0* x86 tree has been cleaned up. The owner
> =A0 =A0* attribute is still left for other arches.
> =A0 =A0*/
>
> As it turns out, the *owner field is (again?) initialized in several modu=
les,
> suggesting that such initialization may be creeping back into the code.
>
> This patch set removes the above comment, the *owner field, and each inst=
ance
> in the code where it was found to be initialized.
>
> Compiled with x86 allmodconfig as well as with all alpha, arm, mips, powe=
rpc,
> and sparc defconfig builds.
This seems reasonable to me. Can we get this in linux-next?
Eric
^ permalink raw reply
* Re: [Patch v2] kexec: increase max of kexec segments and use dynamic allocation
From: Cong Wang @ 2010-07-29 6:42 UTC (permalink / raw)
To: Milton Miller
Cc: Neil Horman, Neil Horman, huang ying, linux-kernel, kexec,
Eric W. Biederman, linuxppc-dev
In-Reply-To: <kexec-nrseg-reply1@mdm.bga.com>
On 07/27/10 18:00, Milton Miller wrote:
> [ Added kexec at lists.infradead.org and linuxppc-dev@lists.ozlabs.org ]
>
>>
>> Currently KEXEC_SEGMENT_MAX is only 16 which is too small for machine with
>> many memory ranges. When hibernate on a machine with disjoint memory we do
>> need one segment for each memory region. Increase this hard limit to 16K
>> which is reasonably large.
>>
>> And change ->segment from a static array to a dynamically allocated memory.
>>
>> Cc: Neil Horman<nhorman@redhat.com>
>> Cc: huang ying<huang.ying.caritas@gmail.com>
>> Cc: Eric W. Biederman<ebiederm@xmission.com>
>> Signed-off-by: WANG Cong<amwang@redhat.com>
>>
>> ---
>> diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
>> index ed31a29..f115585 100644
>> --- a/arch/powerpc/kernel/machine_kexec_64.c
>> +++ b/arch/powerpc/kernel/machine_kexec_64.c
>> @@ -131,10 +131,7 @@ static void copy_segments(unsigned long ind)
>> void kexec_copy_flush(struct kimage *image)
>> {
>> long i, nr_segments = image->nr_segments;
>> - struct kexec_segment ranges[KEXEC_SEGMENT_MAX];
>> -
>> - /* save the ranges on the stack to efficiently flush the icache */
>> - memcpy(ranges, image->segment, sizeof(ranges));
>> + struct kexec_segment range;
>
> I'm glad you found our copy on the stack and removed the stack overflow
> that comes with this bump, but ...
>
>>
>> /*
>> * After this call we may not use anything allocated in dynamic
>> @@ -148,9 +145,11 @@ void kexec_copy_flush(struct kimage *image)
>> * we need to clear the icache for all dest pages sometime,
>> * including ones that were in place on the original copy
>> */
>> - for (i = 0; i< nr_segments; i++)
>> - flush_icache_range((unsigned long)__va(ranges[i].mem),
>> - (unsigned long)__va(ranges[i].mem + ranges[i].memsz));
>> + for (i = 0; i< nr_segments; i++) {
>> + memcpy(&range,&image->segment[i], sizeof(range));
>> + flush_icache_range((unsigned long)__va(range.mem),
>> + (unsigned long)__va(range.mem + range.memsz));
>> + }
>> }
>
> This is executed after the copy, so as it says,
> "we may not use anything allocated in dynamic memory".
>
> We could allocate control pages to copy the segment list into.
> Actually ppc64 doesn't use the existing control page, but that
> is only 4kB today.
>
> We need the list to icache flush all the pages in all the segments.
> The as the indirect list doesn't have pages that were allocated at
> their destination.
>
> Or maybe the icache flush should be done in the generic code
> like it does for crash load segments?
>
I don't get the point here, according to the comments,
it is copied into stack because of efficiency.
--
The opposite of love is not hate, it's indifference.
- Elie Wiesel
^ permalink raw reply
* Re: [PATCH V5] powerpc/mpc512x: Add gpio driver
From: Grant Likely @ 2010-07-29 7:19 UTC (permalink / raw)
To: Peter Korsgaard
Cc: linuxppc-dev, Anatolij Gustschin, Wolfgang Denk, Detlev Zundel,
Matthias Fuchs
In-Reply-To: <87iq4r5y4q.fsf@macbook.be.48ers.dk>
On Wed, Jul 7, 2010 at 5:28 AM, Peter Korsgaard <jacmet@sunsite.dk> wrote:
>>>>>> "Anatolij" =3D=3D Anatolij Gustschin <agust@denx.de> writes:
>
> Hi,
>
> Old mail, I know ..
>
> =A0Anatolij> From: Matthias Fuchs <matthias.fuchs@esd.eu>
> =A0Anatolij> This patch adds a gpio driver for MPC512X PowerPCs.
>
> =A0Anatolij> It has been tested on our CAN-CBX-CPU5201 module that
> =A0Anatolij> uses a MPC5121 CPU. This platform comes with a couple of
> =A0Anatolij> LEDs and configuration switches that have been used for test=
ing.
>
> =A0Anatolij> After change to the of-gpio api the reworked driver has been
> =A0Anatolij> tested on pdm360ng board with some configuration switches.
>
> This looks very similar to the existing
> arch/powerpc/sysdev/mpc8xxx_gpio.c - Couldn't we just add 5121 support
> there instead?
>
> =A0Anatolij> +struct mpc512x_gpio_regs {
> =A0Anatolij> + =A0 =A0u32 gpdir;
> =A0Anatolij> + =A0 =A0u32 gpodr;
> =A0Anatolij> + =A0 =A0u32 gpdat;
> =A0Anatolij> + =A0 =A0u32 gpier;
> =A0Anatolij> + =A0 =A0u32 gpimr;
> =A0Anatolij> + =A0 =A0u32 gpicr1;
> =A0Anatolij> + =A0 =A0u32 gpicr2;
> =A0Anatolij> +};
Hi Anatolij,
Peter's right, the register map looks the same, except for the
additional gpicr1 & 2 registers in the 512x version. Can the 512x
gpios be supported by the 8xxx gpio driver?
g.
^ permalink raw reply
* Re: i meet some surprising things,when i modify the dts file
From: Grant Likely @ 2010-07-29 7:28 UTC (permalink / raw)
To: hacklu; +Cc: linuxppc-dev
In-Reply-To: <201007291408499573189@gmail.com>
On Thu, Jul 29, 2010 at 12:08 AM, hacklu <embedway.test@gmail.com> wrote:
> =A0localbus@f0010100=A0{
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0....
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0ranges=A0=3D=A0<
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A00=A00=A0FC000000=A01000000
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A02=A00=A0FA000000=A01000000
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A01=A00=A070000000=A01000000
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0>;
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0flash@0,0{
>
> .....
> }
>
> flash@2,0{
>
> ....
> }
>
> =A0=A0=A0=A0=A0=A0=A0=A0=A0board-control@1,0{
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 .....
> }
>
> }
>
> this is part of my dts files. I don't kown what each field means in the
> config rangs.
> for instance, 2=A00=A0FA000000=A01000000=A0.
> I only konw this:
> "2" is means chip selects.
> "0" is what?
> "Fa00000" means the start address.
> "1000000" means the range of the device
Ranges translates from the child address domain to the parent address
domain. It consists of 3 fields; The child base address, the parent
base address, and the size. In this case:
child base address :=3D 2 0 (#address-cells =3D <2> in this node)
parent base address :=3D 0xfa000000 (#address-cells =3D <1> in parent node)
and length =3D 0x1000000 (16MB)
For the child address, #address-cells is set to 2, meaning 1 cell for
the chip select #, and 1 cell for an offset into the chip select
range. In most cases the offset will be zero in a ranges property.
So in this case, the ranges property states that chip select 2 is a
16MB region mapped to base address 0xfa000000.
>
> but ,I got some puzzled.
> when I set the two flash in the 0,1 chips select or 0,2 chips select my
> linux works well.
> and, the board-control only can be set at 1 chis select,otherwise the pci
> doesn't be detected.
Unless the bus controller hardware needs to know the chip select
number for another purpose (ie. setting up a local bus DMA transfer),
you could really use any number for the chip select as long as it is
consistent between the child node and the ranges property.
>
> so , what is the chips select? is it based on hardware?
Yes, it is based on hardware. The .dts file is describing which CS
line each external device is attached to.
but my flash can use
> 0,1,2 chips select.
> or it is just set by software? but my pci devece can only work in 1 chips
> select.
>
>
> BTW:
> I also want to know how to write the dts file. I want to understand each
> node in the dts files.
> but I can't get enough documents. I have readed the linux/document/...
> could you privode me some useful information?
See here:
http://www.devicetree.org/Device_Tree_Usage
g.
^ permalink raw reply
* Re: [PATCH V5] powerpc/mpc512x: Add gpio driver
From: Anatolij Gustschin @ 2010-07-29 7:39 UTC (permalink / raw)
To: Grant Likely; +Cc: Matthias Fuchs, Wolfgang Denk, Detlev Zundel, linuxppc-dev
In-Reply-To: <AANLkTi=drdEQG7n8c2-UniYtY0g64kzkY-Oy_uD7iCBG@mail.gmail.com>
On Thu, 29 Jul 2010 01:19:23 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:
> On Wed, Jul 7, 2010 at 5:28 AM, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> >>>>>> "Anatolij" =3D=3D Anatolij Gustschin <agust@denx.de> writes:
> >
> > Hi,
> >
> > Old mail, I know ..
> >
> > =A0Anatolij> From: Matthias Fuchs <matthias.fuchs@esd.eu>
> > =A0Anatolij> This patch adds a gpio driver for MPC512X PowerPCs.
> >
> > =A0Anatolij> It has been tested on our CAN-CBX-CPU5201 module that
> > =A0Anatolij> uses a MPC5121 CPU. This platform comes with a couple of
> > =A0Anatolij> LEDs and configuration switches that have been used for te=
sting.
> >
> > =A0Anatolij> After change to the of-gpio api the reworked driver has be=
en
> > =A0Anatolij> tested on pdm360ng board with some configuration switches.
> >
> > This looks very similar to the existing
> > arch/powerpc/sysdev/mpc8xxx_gpio.c - Couldn't we just add 5121 support
> > there instead?
> >
> > =A0Anatolij> +struct mpc512x_gpio_regs {
> > =A0Anatolij> + =A0 =A0u32 gpdir;
> > =A0Anatolij> + =A0 =A0u32 gpodr;
> > =A0Anatolij> + =A0 =A0u32 gpdat;
> > =A0Anatolij> + =A0 =A0u32 gpier;
> > =A0Anatolij> + =A0 =A0u32 gpimr;
> > =A0Anatolij> + =A0 =A0u32 gpicr1;
> > =A0Anatolij> + =A0 =A0u32 gpicr2;
> > =A0Anatolij> +};
>=20
> Hi Anatolij,
>=20
> Peter's right, the register map looks the same, except for the
> additional gpicr1 & 2 registers in the 512x version. Can the 512x
> gpios be supported by the 8xxx gpio driver?
Hi Grant,
I wanted to extend/test this driver but didn't have time so far. I'll
look at 8xxx gpio driver this weekend to see if it can be used for
512x gpios.
Anatolij
^ permalink raw reply
* Re: [PATCH v2 5/7] Add support for ramdisk on ppc32 for uImage-ppc and Elf-ppc
From: Simon Horman @ 2010-07-29 8:33 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev, kexec
In-Reply-To: <1279656900-27458-5-git-send-email-msm@freescale.com>
On Tue, Jul 20, 2010 at 03:14:58PM -0500, Matthew McClintock wrote:
> This fixes --reuseinitrd and --ramdisk option for ppc32 on
> uImage-ppc and Elf. It works for normal kexec as well as for
> kdump.
>
> When using --reuseinitrd you need to specifify retain_initrd
> on the command line. Also, if you are doing kdump you need to make
> sure your initrd lives in the crashdump region otherwise the
> kdump kernel will not be able to access it. The --ramdisk option
> should always work.
Thanks, I have applied this change.
I had to do a minor merge on the Makefile,
could you verify that the result is correct?
^ permalink raw reply
* Re: [PATCH 1/4] irq: rename IRQF_TIMER to IRQF_NO_SUSPEND
From: Thomas Gleixner @ 2010-07-29 8:49 UTC (permalink / raw)
To: Ian Campbell
Cc: Jeremy Fitzhardinge, xen-devel, devicetree-discuss,
Dmitry Torokhov, linux-kernel, linuxppc-dev, Paul Mackerras,
linux-input
In-Reply-To: <1280314467-5637-1-git-send-email-ian.campbell@citrix.com>
On Wed, 28 Jul 2010, Ian Campbell wrote:
> Continue to provide IRQF_TIMER as an alias to IRQF_NO_SUSPEND since I
> think it is worth preserving the nice self-documenting name (where it
> is used appropriately). It also avoid needing to patch all the many
> users who are using the flag for an actual timer interrupt.
I'm not happy about the alias. What about:
#define __IRQF_TIMER 0x00000200
#define IRQF_NO_SUSPEND 0x00000400
#define IRQF_TIMER (__IRQF_TIMER | IRQF_NO_SUSPEND)
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 1/4] irq: rename IRQF_TIMER to IRQF_NO_SUSPEND
From: Ian Campbell @ 2010-07-29 9:03 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Jeremy Fitzhardinge, xen-devel@lists.xensource.com,
devicetree-discuss@lists.ozlabs.org, Dmitry Torokhov,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Paul Mackerras, linux-input@vger.kernel.org
In-Reply-To: <alpine.LFD.2.00.1007291045060.2471@localhost.localdomain>
On Thu, 2010-07-29 at 09:49 +0100, Thomas Gleixner wrote:
> On Wed, 28 Jul 2010, Ian Campbell wrote:
>
> > Continue to provide IRQF_TIMER as an alias to IRQF_NO_SUSPEND since I
> > think it is worth preserving the nice self-documenting name (where it
> > is used appropriately). It also avoid needing to patch all the many
> > users who are using the flag for an actual timer interrupt.
>
> I'm not happy about the alias. What about:
>
> #define __IRQF_TIMER 0x00000200
> #define IRQF_NO_SUSPEND 0x00000400
>
> #define IRQF_TIMER (__IRQF_TIMER | IRQF_NO_SUSPEND)
Sure, I'll rework along those lines.
Ian.
^ permalink raw reply
* Re: [PATCH v3 0/7] Fixup booting with device trees and uImage/elf on ppc32
From: Simon Horman @ 2010-07-29 9:18 UTC (permalink / raw)
To: Matthew McClintock; +Cc: muvarov, linuxppc-dev, sebastian, kexec
In-Reply-To: <14FA0578-0D5B-48D1-BF5D-EB39DF1432D1@freescale.com>
On Mon, Jul 26, 2010 at 11:22:58PM -0500, Matthew McClintock wrote:
>
> On Jul 26, 2010, at 9:55 PM, Simon Horman wrote:
>
> > [Cced linuxppc-dev]
> >
> > On Tue, Jul 20, 2010 at 11:42:57PM -0500, Matthew McClintock wrote:
> >> This patch series adds full support for booting with a flat device tree
> >> with either uImage or elf file formats. Kexec and Kdump should work, and
> >> you should also be able to use ramdisks or reuse your current ramdisk as well
> >>
> >> This patch series was tested on an mpc85xx system with a kernel version
> >> 2.6.35-rc3
> >>
> >> v1: Initial version
> >>
> >> v2: Added support for fs2dt (file system to device tree)
> >>
> >> v3: Fix some misc. git problems I had and other code cleanups
> >
> > Hi Matthew,
> >
> > I'm a little concerned that these changes are non trivial and haven't had
> > much review. But I am prepared to put them into my tree once 2.0.2 is
> > released - perhaps that way they will get some test coverage. Does
> > that work for you?
>
> Either way works for me. I know they could use more review, however as Maxim said the current tree does not work AFAIK. Either way, I'm willing to keeping addressing everyones concerns and wait or move forward and make some quick fixes as well.
All applied.
I made some minor changes to three of the patches.
I have noted each change in separate emails.
^ permalink raw reply
* [GIT/PATCH 0/4] Do not use IRQF_TIMER for non timer interrupts
From: Ian Campbell @ 2010-07-29 10:16 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Jeremy Fitzhardinge, xen-devel@lists.xensource.com,
devicetree-discuss@lists.ozlabs.org, Dmitry Torokhov,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Paul Mackerras, linux-input@vger.kernel.org
In-Reply-To: <alpine.LFD.2.00.1007291045060.2471@localhost.localdomain>
On Thu, 2010-07-29 at 09:49 +0100, Thomas Gleixner wrote:
> On Wed, 28 Jul 2010, Ian Campbell wrote:
>
> > Continue to provide IRQF_TIMER as an alias to IRQF_NO_SUSPEND since I
> > think it is worth preserving the nice self-documenting name (where it
> > is used appropriately). It also avoid needing to patch all the many
> > users who are using the flag for an actual timer interrupt.
>
> I'm not happy about the alias. What about:
>
> #define __IRQF_TIMER 0x00000200
> #define IRQF_NO_SUSPEND 0x00000400
>
> #define IRQF_TIMER (__IRQF_TIMER | IRQF_NO_SUSPEND)
Resending with this change. Plus I ran checkpatch on the whole lot (I
previously managed to run it only on the first patch) and fixed the
complaints.
Ian.
The following changes since commit fc0f5ac8fe693d1b05f5a928cc48135d1c8b7f2e:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../ericvh/v9fs
are available in the git repository at:
git://xenbits.xensource.com/people/ianc/linux-2.6.git for-irq/irqf-no-suspend
Ian Campbell (4):
irq: Add new IRQ flag IRQF_NO_SUSPEND
ixp4xx-beeper: Use IRQF_NO_SUSPEND not IRQF_TIMER for non-timer interrupt
powerpc: Use IRQF_NO_SUSPEND not IRQF_TIMER for non-timer interrupts
xen: do not suspend IPI IRQs.
arch/powerpc/platforms/powermac/low_i2c.c | 5 +++--
drivers/input/misc/ixp4xx-beeper.c | 3 ++-
drivers/macintosh/via-pmu.c | 9 +++++----
drivers/xen/events.c | 1 +
include/linux/interrupt.h | 7 ++++++-
kernel/irq/manage.c | 2 +-
6 files changed, 18 insertions(+), 9 deletions(-)
^ permalink raw reply
* [PATCH 1/4] irq: Add new IRQ flag IRQF_NO_SUSPEND
From: Ian Campbell @ 2010-07-29 10:16 UTC (permalink / raw)
To: linux-kernel
Cc: Jeremy Fitzhardinge, xen-devel, Ian Campbell, devicetree-discuss,
Dmitry Torokhov, linuxppc-dev, Paul Mackerras, linux-input,
Thomas Gleixner
In-Reply-To: <1280398573.24292.1684.camel@zakaz.uk.xensource.com>
A small number of users of IRQF_TIMER are using it for the implied no
suspend behaviour on interrupts which are not timer interrupts.
Therefore add a new IRQF_NO_SUSPEND flag, rename IRQF_TIMER to
__IRQF_TIMER and redefine IRQF_TIMER in terms of these new flags.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: xen-devel@lists.xensource.com
Cc: linux-input@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org
Cc: devicetree-discuss@lists.ozlabs.org
---
include/linux/interrupt.h | 7 ++++++-
kernel/irq/manage.c | 2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index c233113..a0384a4 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -53,16 +53,21 @@
* IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler finished.
* Used by threaded interrupts which need to keep the
* irq line disabled until the threaded handler has been run.
+ * IRQF_NO_SUSPEND - Do not disable this IRQ during suspend
+ *
*/
#define IRQF_DISABLED 0x00000020
#define IRQF_SAMPLE_RANDOM 0x00000040
#define IRQF_SHARED 0x00000080
#define IRQF_PROBE_SHARED 0x00000100
-#define IRQF_TIMER 0x00000200
+#define __IRQF_TIMER 0x00000200
#define IRQF_PERCPU 0x00000400
#define IRQF_NOBALANCING 0x00000800
#define IRQF_IRQPOLL 0x00001000
#define IRQF_ONESHOT 0x00002000
+#define IRQF_NO_SUSPEND 0x00004000
+
+#define IRQF_TIMER (__IRQF_TIMER | IRQF_NO_SUSPEND)
/*
* Bits used by threaded handlers:
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index e149748..c3003e9 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -216,7 +216,7 @@ static inline int setup_affinity(unsigned int irq, struct irq_desc *desc)
void __disable_irq(struct irq_desc *desc, unsigned int irq, bool suspend)
{
if (suspend) {
- if (!desc->action || (desc->action->flags & IRQF_TIMER))
+ if (!desc->action || (desc->action->flags & IRQF_NO_SUSPEND))
return;
desc->status |= IRQ_SUSPENDED;
}
--
1.5.6.5
^ permalink raw reply related
* [PATCH 3/4] powerpc: Use IRQF_NO_SUSPEND not IRQF_TIMER for non-timer interrupts
From: Ian Campbell @ 2010-07-29 10:16 UTC (permalink / raw)
To: linux-kernel
Cc: Ian Campbell, devicetree-discuss, linuxppc-dev, Paul Mackerras,
Thomas Gleixner
In-Reply-To: <1280398573.24292.1684.camel@zakaz.uk.xensource.com>
kw_i2c_irq and via_pmu_interrupt are not timer interrupts and
therefore should not use IRQF_TIMER. Use the recently introduced
IRQF_NO_SUSPEND instead since that is the actual desired behaviour.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org
Cc: devicetree-discuss@lists.ozlabs.org
---
arch/powerpc/platforms/powermac/low_i2c.c | 5 +++--
drivers/macintosh/via-pmu.c | 9 +++++----
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/low_i2c.c b/arch/powerpc/platforms/powermac/low_i2c.c
index 06a137c..480567e 100644
--- a/arch/powerpc/platforms/powermac/low_i2c.c
+++ b/arch/powerpc/platforms/powermac/low_i2c.c
@@ -542,11 +542,12 @@ static struct pmac_i2c_host_kw *__init kw_i2c_host_init(struct device_node *np)
/* Make sure IRQ is disabled */
kw_write_reg(reg_ier, 0);
- /* Request chip interrupt. We set IRQF_TIMER because we don't
+ /* Request chip interrupt. We set IRQF_NO_SUSPEND because we don't
* want that interrupt disabled between the 2 passes of driver
* suspend or we'll have issues running the pfuncs
*/
- if (request_irq(host->irq, kw_i2c_irq, IRQF_TIMER, "keywest i2c", host))
+ if (request_irq(host->irq, kw_i2c_irq, IRQF_NO_SUSPEND,
+ "keywest i2c", host))
host->irq = NO_IRQ;
printk(KERN_INFO "KeyWest i2c @0x%08x irq %d %s\n",
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 3d4fc0f..35bc273 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -400,11 +400,12 @@ static int __init via_pmu_start(void)
printk(KERN_ERR "via-pmu: can't map interrupt\n");
return -ENODEV;
}
- /* We set IRQF_TIMER because we don't want the interrupt to be disabled
- * between the 2 passes of driver suspend, we control our own disabling
- * for that one
+ /* We set IRQF_NO_SUSPEND because we don't want the interrupt
+ * to be disabled between the 2 passes of driver suspend, we
+ * control our own disabling for that one
*/
- if (request_irq(irq, via_pmu_interrupt, IRQF_TIMER, "VIA-PMU", (void *)0)) {
+ if (request_irq(irq, via_pmu_interrupt, IRQF_NO_SUSPEND,
+ "VIA-PMU", (void *)0)) {
printk(KERN_ERR "via-pmu: can't request irq %d\n", irq);
return -ENODEV;
}
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH v4 1/5] fsl-diu-fb: fix issue with re-enabling DIU area descriptor
From: Detlev Zundel @ 2010-07-29 11:48 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <AANLkTikkLVCxU4ZC_nmUhKTQogUNeQzxOX6KqgZcxiYr__2540.83384429595$1280300644$gmane$org@mail.gmail.com>
Hi Grant,
> On Fri, Jul 23, 2010 at 8:00 AM, Anatolij Gustschin <agust@denx.de> wrote:
>> On MPC5121e Rev 2.0 re-configuring the DIU area descriptor
>> by writing new descriptor address doesn't always work.
>> As a result, DIU continues to display using old area descriptor
>> even if the new one has been written to the descriptor register of
>> the plane.
>>
>> Add the code from Freescale MPC5121EADS BSP for writing descriptor
>> addresses properly. This fixes the problem for Rev 2.0 silicon.
>>
>> Signed-off-by: Anatolij Gustschin <agust@denx.de>
>> ---
>> v4:
>> - use workaround code as suggested by FSL technical support.
>>
>> v3:
>> - no changes since v1
>>
>> drivers/video/fsl-diu-fb.c | 38 +++++++++++++++++++++++---------------
>> 1 files changed, 23 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
>> index 27455ce..9b8c991 100644
>> --- a/drivers/video/fsl-diu-fb.c
>> +++ b/drivers/video/fsl-diu-fb.c
>> @@ -317,6 +317,17 @@ static void fsl_diu_free(void *virt, size_t size)
>> free_pages_exact(virt, size);
>> }
>>
>> +/*
>> + * Workaround for failed writing desc register of planes.
>> + * Needed with MPC5121 DIU rev 2.0 silicon.
>> + */
>> +void wr_reg_wa(u32 *reg, u32 val)
>> +{
>> + do {
>> + out_be32(reg, val);
>> + } while (in_be32(reg) != val);
>> +}
>
> I'll apply this one, but it looks like a potential problem. What
> happens if the write never succeeds? The kernel then gets stuck in a
> forever busy loop. You should look at reworking it.
We would surely like to do this "the correct way(tm)". Unfortunately
this commit reflects what we have been told by Freescale support and it
fixes a real observed problem. We fail to find a better solution
without any insight into the internal workings of the functional block.
Cheers
Detlev
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* Re: Problems using UART on MPC5200
From: Detlev Zundel @ 2010-07-29 11:55 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <59976.84.175.96.30.1280309170.squirrel__2764.8760042668$1280309549$gmane$org@batzer-biz.prossl.de>
Hi Sven,
> I am using a PowerPC MPC5200 from Freescale (with STK5200-Board), ELDK 4.2
> from DENX and the Kernel 2.6.34-rc5.
>
> My Kernel is running fine. The console output is coming over the device
> ttyPSC0.
>
> In future I want to login over telnet. So I deactivated the Kerneloption
> to output the console over the UART device.
It would help if you were more precise in describing what you did and
what you try to achieve. What exact option did you change?
> Now I want to read and write to the RS232 interface from a program.
> But when I try to open the device ttyPSC* I get the following error:
> "unable to read portsettings : Inappropriate ioctl for device"
The message means what it says - whatever device driver is connected to
the device file you open does not support the ioctl you call on it.
Now to better understand this, it would help if you tell us what device
file you open, what major and minor number this has, what /proc/devices
shows this hooks to and what ioctl you do in your application.
> What does this mean ? How can I send and receive Data from/to the UART ?
This should all work with standard procedures.
Cheers
Detlev
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de
^ permalink raw reply
* [PATCH 00/27] KVM PPC PV framework v3
From: Alexander Graf @ 2010-07-29 12:47 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, KVM list
On PPC we run PR=0 (kernel mode) code in PR=1 (user mode) and don't use the
hypervisor extensions.
While that is all great to show that virtualization is possible, there are
quite some cases where the emulation overhead of privileged instructions is
killing performance.
This patchset tackles exactly that issue. It introduces a paravirtual framework
using which KVM and Linux share a page to exchange register state with. That
way we don't have to switch to the hypervisor just to change a value of a
privileged register.
To prove my point, I ran the same test I did for the MMU optimizations against
the PV framework. Here are the results:
[without]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello > /dev/null; done
real 0m14.659s
user 0m8.967s
sys 0m5.688s
[with]
debian-powerpc:~# time for i in {1..1000}; do /bin/echo hello > /dev/null; done
real 0m7.557s
user 0m4.121s
sys 0m3.426s
So this is a significant performance improvement! I'm quite happy how fast this
whole thing becomes :)
I tried to take all comments I've heard from people so far about such a PV
framework into account. In case you told me something before that is a no-go
and I still did it, please just tell me again.
To make use of this whole thing you also need patches to qemu and openbios. I
have them in my queue, but want to see this set upstream first before I start
sending patches to the other projects.
Now go and have fun with fast VMs on PPC! Get yourself a G5 on ebay and start
experiencing the power yourself. - heh
v1 -> v2:
- change hypervisor calls to use r0 and r3
- make crit detection only trigger in supervisor mode
- RMO -> PAM
- introduce kvm_patch_ins
- only flush icache when patching
- introduce kvm_patch_ins_b
- update documentation
v2 -> v3:
- use pPAPR conventions for hypercall interface
- only use r0 as magic sc number
- remove PVR detection
- remove BookE shared page mapping support
- combine book3s-64 and -32 magic page ra override
- add self-test check if the mapping works to guest code
- add safety check for relocatable kernels
Alexander Graf (27):
KVM: PPC: Introduce shared page
KVM: PPC: Convert MSR to shared page
KVM: PPC: Convert DSISR to shared page
KVM: PPC: Convert DAR to shared page.
KVM: PPC: Convert SRR0 and SRR1 to shared page
KVM: PPC: Convert SPRG[0-4] to shared page
KVM: PPC: Implement hypervisor interface
KVM: PPC: Add PV guest critical sections
KVM: PPC: Add PV guest scratch registers
KVM: PPC: Tell guest about pending interrupts
KVM: PPC: Make PAM a define
KVM: PPC: First magic page steps
KVM: PPC: Magic Page Book3s support
KVM: PPC: Expose magic page support to guest
KVM: Move kvm_guest_init out of generic code
KVM: PPC: Generic KVM PV guest support
KVM: PPC: KVM PV guest stubs
KVM: PPC: PV instructions to loads and stores
KVM: PPC: PV tlbsync to nop
KVM: PPC: Introduce kvm_tmp framework
KVM: PPC: Introduce branch patching helper
KVM: PPC: PV assembler helpers
KVM: PPC: PV mtmsrd L=1
KVM: PPC: PV mtmsrd L=0 and mtmsr
KVM: PPC: PV wrteei
KVM: PPC: Add Documentation about PV interface
KVM: PPC: Add get_pvinfo interface to query hypercall instructions
Documentation/kvm/api.txt | 23 ++
Documentation/kvm/ppc-pv.txt | 180 +++++++++++
arch/powerpc/include/asm/kvm_book3s.h | 2 +-
arch/powerpc/include/asm/kvm_host.h | 15 +-
arch/powerpc/include/asm/kvm_para.h | 135 ++++++++-
arch/powerpc/include/asm/kvm_ppc.h | 1 +
arch/powerpc/kernel/Makefile | 2 +
arch/powerpc/kernel/asm-offsets.c | 18 +-
arch/powerpc/kernel/kvm.c | 485 ++++++++++++++++++++++++++++++
arch/powerpc/kernel/kvm_emul.S | 247 +++++++++++++++
arch/powerpc/kvm/44x.c | 7 +
arch/powerpc/kvm/44x_tlb.c | 8 +-
arch/powerpc/kvm/book3s.c | 188 ++++++++----
arch/powerpc/kvm/book3s_32_mmu.c | 28 ++-
arch/powerpc/kvm/book3s_32_mmu_host.c | 6 +-
arch/powerpc/kvm/book3s_64_mmu.c | 42 +++-
arch/powerpc/kvm/book3s_64_mmu_host.c | 13 +-
arch/powerpc/kvm/book3s_emulate.c | 25 +-
arch/powerpc/kvm/book3s_paired_singles.c | 11 +-
arch/powerpc/kvm/booke.c | 83 ++++--
arch/powerpc/kvm/booke.h | 6 +-
arch/powerpc/kvm/booke_emulate.c | 14 +-
arch/powerpc/kvm/booke_interrupts.S | 3 +-
arch/powerpc/kvm/e500.c | 7 +
arch/powerpc/kvm/e500_tlb.c | 12 +-
arch/powerpc/kvm/e500_tlb.h | 2 +-
arch/powerpc/kvm/emulate.c | 36 ++-
arch/powerpc/kvm/powerpc.c | 84 +++++-
arch/powerpc/platforms/Kconfig | 10 +
arch/x86/include/asm/kvm_para.h | 6 +
include/linux/kvm.h | 11 +
include/linux/kvm_para.h | 7 +-
32 files changed, 1538 insertions(+), 179 deletions(-)
create mode 100644 Documentation/kvm/ppc-pv.txt
create mode 100644 arch/powerpc/kernel/kvm.c
create mode 100644 arch/powerpc/kernel/kvm_emul.S
^ permalink raw reply
* [PATCH 08/27] KVM: PPC: Add PV guest critical sections
From: Alexander Graf @ 2010-07-29 12:47 UTC (permalink / raw)
To: kvm-ppc; +Cc: linuxppc-dev, KVM list
In-Reply-To: <1280407688-9815-1-git-send-email-agraf@suse.de>
When running in hooked code we need a way to disable interrupts without
clobbering any interrupts or exiting out to the hypervisor.
To achieve this, we have an additional critical field in the shared page. If
that field is equal to the r1 register of the guest, it tells the hypervisor
that we're in such a critical section and thus may not receive any interrupts.
Signed-off-by: Alexander Graf <agraf@suse.de>
---
v1 -> v2:
- make crit detection only trigger in supervisor mode
---
arch/powerpc/include/asm/kvm_para.h | 1 +
arch/powerpc/kvm/book3s.c | 18 ++++++++++++++++--
arch/powerpc/kvm/booke.c | 15 +++++++++++++++
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_para.h b/arch/powerpc/include/asm/kvm_para.h
index 556fd59..4577e7b 100644
--- a/arch/powerpc/include/asm/kvm_para.h
+++ b/arch/powerpc/include/asm/kvm_para.h
@@ -24,6 +24,7 @@
#include <linux/of.h>
struct kvm_vcpu_arch_shared {
+ __u64 critical; /* Guest may not get interrupts if == r1 */
__u64 sprg0;
__u64 sprg1;
__u64 sprg2;
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 5cb5f0d..d6227ff 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -251,14 +251,28 @@ int kvmppc_book3s_irqprio_deliver(struct kvm_vcpu *vcpu, unsigned int priority)
int deliver = 1;
int vec = 0;
ulong flags = 0ULL;
+ ulong crit_raw = vcpu->arch.shared->critical;
+ ulong crit_r1 = kvmppc_get_gpr(vcpu, 1);
+ bool crit;
+
+ /* Truncate crit indicators in 32 bit mode */
+ if (!(vcpu->arch.shared->msr & MSR_SF)) {
+ crit_raw &= 0xffffffff;
+ crit_r1 &= 0xffffffff;
+ }
+
+ /* Critical section when crit == r1 */
+ crit = (crit_raw == crit_r1);
+ /* ... and we're in supervisor mode */
+ crit = crit && !(vcpu->arch.shared->msr & MSR_PR);
switch (priority) {
case BOOK3S_IRQPRIO_DECREMENTER:
- deliver = vcpu->arch.shared->msr & MSR_EE;
+ deliver = (vcpu->arch.shared->msr & MSR_EE) && !crit;
vec = BOOK3S_INTERRUPT_DECREMENTER;
break;
case BOOK3S_IRQPRIO_EXTERNAL:
- deliver = vcpu->arch.shared->msr & MSR_EE;
+ deliver = (vcpu->arch.shared->msr & MSR_EE) && !crit;
vec = BOOK3S_INTERRUPT_EXTERNAL;
break;
case BOOK3S_IRQPRIO_SYSTEM_RESET:
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 13e0747..104d0ee 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -147,6 +147,20 @@ static int kvmppc_booke_irqprio_deliver(struct kvm_vcpu *vcpu,
int allowed = 0;
ulong uninitialized_var(msr_mask);
bool update_esr = false, update_dear = false;
+ ulong crit_raw = vcpu->arch.shared->critical;
+ ulong crit_r1 = kvmppc_get_gpr(vcpu, 1);
+ bool crit;
+
+ /* Truncate crit indicators in 32 bit mode */
+ if (!(vcpu->arch.shared->msr & MSR_SF)) {
+ crit_raw &= 0xffffffff;
+ crit_r1 &= 0xffffffff;
+ }
+
+ /* Critical section when crit == r1 */
+ crit = (crit_raw == crit_r1);
+ /* ... and we're in supervisor mode */
+ crit = crit && !(vcpu->arch.shared->msr & MSR_PR);
switch (priority) {
case BOOKE_IRQPRIO_DTLB_MISS:
@@ -181,6 +195,7 @@ static int kvmppc_booke_irqprio_deliver(struct kvm_vcpu *vcpu,
case BOOKE_IRQPRIO_DECREMENTER:
case BOOKE_IRQPRIO_FIT:
allowed = vcpu->arch.shared->msr & MSR_EE;
+ allowed = allowed && !crit;
msr_mask = MSR_CE|MSR_ME|MSR_DE;
break;
case BOOKE_IRQPRIO_DEBUG:
--
1.6.0.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox