* Re: ramdisk size is larger than 4MB
From: Scott Wood @ 2010-07-30 17:04 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcdev
In-Reply-To: <AANLkTinKb8E_McVAv5epg+4acb8H1+8HNsKHJYDr9B10@mail.gmail.com>
On Fri, 30 Jul 2010 00:00:52 -0700
Shawn Jin <shawnxjin@gmail.com> wrote:
> Hi,
>
> I have a ramdisk as RFS much larger than 4MB in a 2.4 kernel. In
> recent 2.6 kernels ramdisk is no longer supported so I decided to go
> with initramfs. However I found the initial RFS for initramfs is
> limited to 4MB since the bootwrapper locates at 0x400000.
The uncompressed image, including both ramfs and kernel must fit below
4MB.
> One way to lift this limitation is to relocate the bootwrapper to
> somewhere else, say for example, 0x1000000 so that a 16MB initramfs
> can be loaded. If the bootwrapper is relocated, what else would be
> affected by this relocation?
It should be fine to just change it locally. It would be a problem to
change it upstream for all boards, since some supported boards have
only 16MB (or even 8MB) of RAM.
Another option is to provide a vmlinux_alloc callback to stick the
kernel somewhere other than zero, at the cost of an extra image copy
once the kernel runs to get itself back down to zero. This wasn't done
in cuboot because it was considered better to adjust the bootwrapper
link address at build time based on the kernel+ramfs image size, but
that never got implemented.
Perhaps a reasonable compromise is a vmlinux_alloc that returns zero if
the image fits there, and calls malloc otherwise?
-Scott
^ permalink raw reply
* [050/165] genirq: Deal with desc->set_type() changing desc->chip
From: Greg KH @ 2010-07-30 17:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, linuxppc-dev, Thomas Gleixner, torvalds, akpm,
alan
2.6.32-stable review patch. If anyone has any objections, please let us know.
------------------
From: Thomas Gleixner <tglx@linutronix.de>
commit 4673247562e39a17e09440fa1400819522ccd446 upstream.
The set_type() function can change the chip implementation when the
trigger mode changes. That might result in using an non-initialized
irq chip when called from __setup_irq() or when called via
set_irq_type() on an already enabled irq.
The set_irq_type() function should not be called on an enabled irq,
but because we forgot to put a check into it, we have a bunch of users
which grew the habit of doing that and it never blew up as the
function is serialized via desc->lock against all users of desc->chip
and they never hit the non-initialized irq chip issue.
The easy fix for the __setup_irq() issue would be to move the
irq_chip_set_defaults(desc->chip) call after the trigger setting to
make sure that a chip change is covered.
But as we have already users, which do the type setting after
request_irq(), the safe fix for now is to call irq_chip_set_defaults()
from __irq_set_trigger() when desc->set_type() changed the irq chip.
It needs a deeper analysis whether we should refuse to change the chip
on an already enabled irq, but that'd be a large scale change to fix
all the existing users. So that's neither stable nor 2.6.35 material.
Reported-by: Esben Haabendal <eha@doredevelopment.dk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
kernel/irq/manage.c | 3 +++
1 file changed, 3 insertions(+)
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -436,6 +436,9 @@ int __irq_set_trigger(struct irq_desc *d
/* note that IRQF_TRIGGER_MASK == IRQ_TYPE_SENSE_MASK */
desc->status &= ~(IRQ_LEVEL | IRQ_TYPE_SENSE_MASK);
desc->status |= flags;
+
+ if (chip != desc->chip)
+ irq_chip_set_defaults(desc->chip);
}
return ret;
^ permalink raw reply
* [076/140] genirq: Deal with desc->set_type() changing desc->chip
From: Greg KH @ 2010-07-30 17:30 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, linuxppc-dev, Thomas Gleixner, torvalds, akpm,
alan
In-Reply-To: <20100730173205.GA22581@kroah.com>
2.6.33-stable review patch. If anyone has any objections, please let us know.
------------------
From: Thomas Gleixner <tglx@linutronix.de>
commit 4673247562e39a17e09440fa1400819522ccd446 upstream.
The set_type() function can change the chip implementation when the
trigger mode changes. That might result in using an non-initialized
irq chip when called from __setup_irq() or when called via
set_irq_type() on an already enabled irq.
The set_irq_type() function should not be called on an enabled irq,
but because we forgot to put a check into it, we have a bunch of users
which grew the habit of doing that and it never blew up as the
function is serialized via desc->lock against all users of desc->chip
and they never hit the non-initialized irq chip issue.
The easy fix for the __setup_irq() issue would be to move the
irq_chip_set_defaults(desc->chip) call after the trigger setting to
make sure that a chip change is covered.
But as we have already users, which do the type setting after
request_irq(), the safe fix for now is to call irq_chip_set_defaults()
from __irq_set_trigger() when desc->set_type() changed the irq chip.
It needs a deeper analysis whether we should refuse to change the chip
on an already enabled irq, but that'd be a large scale change to fix
all the existing users. So that's neither stable nor 2.6.35 material.
Reported-by: Esben Haabendal <eha@doredevelopment.dk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
kernel/irq/manage.c | 3 +++
1 file changed, 3 insertions(+)
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -436,6 +436,9 @@ int __irq_set_trigger(struct irq_desc *d
/* note that IRQF_TRIGGER_MASK == IRQ_TYPE_SENSE_MASK */
desc->status &= ~(IRQ_LEVEL | IRQ_TYPE_SENSE_MASK);
desc->status |= flags;
+
+ if (chip != desc->chip)
+ irq_chip_set_defaults(desc->chip);
}
return ret;
^ permalink raw reply
* [090/205] genirq: Deal with desc->set_type() changing desc->chip
From: Greg KH @ 2010-07-30 17:51 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, linuxppc-dev, Thomas Gleixner, torvalds, akpm,
alan
In-Reply-To: <20100730175238.GA3924@kroah.com>
2.6.34-stable review patch. If anyone has any objections, please let us know.
------------------
From: Thomas Gleixner <tglx@linutronix.de>
commit 4673247562e39a17e09440fa1400819522ccd446 upstream.
The set_type() function can change the chip implementation when the
trigger mode changes. That might result in using an non-initialized
irq chip when called from __setup_irq() or when called via
set_irq_type() on an already enabled irq.
The set_irq_type() function should not be called on an enabled irq,
but because we forgot to put a check into it, we have a bunch of users
which grew the habit of doing that and it never blew up as the
function is serialized via desc->lock against all users of desc->chip
and they never hit the non-initialized irq chip issue.
The easy fix for the __setup_irq() issue would be to move the
irq_chip_set_defaults(desc->chip) call after the trigger setting to
make sure that a chip change is covered.
But as we have already users, which do the type setting after
request_irq(), the safe fix for now is to call irq_chip_set_defaults()
from __irq_set_trigger() when desc->set_type() changed the irq chip.
It needs a deeper analysis whether we should refuse to change the chip
on an already enabled irq, but that'd be a large scale change to fix
all the existing users. So that's neither stable nor 2.6.35 material.
Reported-by: Esben Haabendal <eha@doredevelopment.dk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
kernel/irq/manage.c | 3 +++
1 file changed, 3 insertions(+)
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -440,6 +440,9 @@ int __irq_set_trigger(struct irq_desc *d
/* note that IRQF_TRIGGER_MASK == IRQ_TYPE_SENSE_MASK */
desc->status &= ~(IRQ_LEVEL | IRQ_TYPE_SENSE_MASK);
desc->status |= flags;
+
+ if (chip != desc->chip)
+ irq_chip_set_defaults(desc->chip);
}
return ret;
^ permalink raw reply
* Re: [PATCH RFC] usb gadget: introduce usb_gadget_probe_driver
From: David Brownell @ 2010-07-30 18:46 UTC (permalink / raw)
To: Michał Nazarewicz, Uwe Kleine-König
Cc: Cliff Cai, Greg Kroah-Hartman, Dinh Nguyen, Tony Lindgren,
Nicolas Ferre, linux-kernel, linuxppc-dev, Julia Lawall,
Philipp Zabel, Mark Brown, Felipe Balbi, Andrea Gelmini,
Robert Jarzmik, Fabien Chouteau, Dan Carpenter, David Brownell,
Vladimir Zapolskiy, Sergei Shtylyov, Vincent Sanders, Marc Singer,
André Goddard Rosa, Alan Stern, Sean MacLennan, Russell King,
Tobias Klauser, Marc Kleine-Budde, Eirik Aanonsen, Mike Frysinger,
Thomas Dahlmann, linux-geode, Ben Dooks, Magnus Damm,
Anton Vorontsov, Andrew Victor, linux-arm-kernel,
Anatolij Gustschin, Eric Miao, Németh Márton,
Jiri Kosina, Yoshihiro Shimoda, linux-usb, Harro Haan,
FUJITA Tomonori, H Hartley Sweeten, Paul Mundt, Tejun Heo,
Andrew Morton, Cory Maccarrone
In-Reply-To: <20100730152602.GA28042@pengutronix.de>
=0A> - The bind functions are only called at init time, so there=0A> is no =
need=0A> =C2=A0 to save a pointer to it.=0A=0ARight. Let's retain the spac=
e-saving behaviors=0Aby keeping init-only code in init sections.=0A=0A- Dav=
e=0A
^ permalink raw reply
* Re: [PATCH RFC] usb gadget: introduce usb_gadget_probe_driver
From: Uwe Kleine-König @ 2010-07-30 18:57 UTC (permalink / raw)
To: Michał Nazarewicz
Cc: Cliff Cai, Greg Kroah-Hartman, Dinh Nguyen, Tony Lindgren,
Nicolas Ferre, linux-kernel, linuxppc-dev, Julia Lawall,
Philipp Zabel, Mark Brown, Felipe Balbi, Andrea Gelmini,
Robert Jarzmik, Fabien Chouteau, Dan Carpenter, David Brownell,
Vladimir Zapolskiy, Sergei Shtylyov, Vincent Sanders, Marc Singer,
André Goddard Rosa, Alan Stern, Sean MacLennan, Russell King,
Tobias Klauser, Marc Kleine-Budde, Eirik Aanonsen, Mike Frysinger,
Thomas Dahlmann, linux-geode, Ben Dooks, Magnus Damm,
Anton Vorontsov, Andrew Victor, linux-arm-kernel,
Anatolij Gustschin, Eric Miao, Németh Márton,
Jiri Kosina, Yoshihiro Shimoda, linux-usb, Harro Haan,
FUJITA Tomonori, H Hartley Sweeten, Paul Mundt, Tejun Heo,
Andrew Morton, Cory Maccarrone
In-Reply-To: <op.vgny39097p4s8u@pikus>
On Fri, Jul 30, 2010 at 06:08:23PM +0200, Michał Nazarewicz wrote:
> On Fri, 30 Jul 2010 17:26:02 +0200, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
>> On Fri, Jul 30, 2010 at 05:16:46PM +0200, Michał Nazarewicz wrote:
>>> On Fri, 30 Jul 2010 16:49:14 +0200, Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
>>>
>>>> This is like usb_gadget_register_driver with the only difference that it
>>>> gets the bind function as parameter instead of using driver->bind. This
>>>> allows fixing section mismatches like
>>>>
>>>> WARNING: drivers/usb/gadget/g_printer.o(.data+0xc): Section mismatch in
>>>> reference from the variable printer_driver to the function
>>>> .init.text:printer_bind()
>>>> The variable printer_driver references
>>>> the function __init printer_bind()
>>>>
>>>> by using usb_gadget_probe_driver with driver->bind = NULL. When all
>>>> drivers are fixed to use the new function the bind member of struct
>>>> usb_gadget_driver can go away.
>>>>
>>>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>>>> Cc: Michal Nazarewicz <m.nazarewicz@samsung.com>
>>>> Cc: Greg Kroah-Hartman <gregkh@suse.de>
>
> BTW. Dunno if there is a reason to put me on Cc and Greg will be in
> Signed-off-by anyway.
>
>>>> ---
>>>> Hello,
>>>>
>>>> there is an alternative patch in Greg's tree [1], but IMHO mine is
>>>> better as it doesn't need __ref.
>>>>
>>>> Thoughts?
>>>
>>> Personally I don't see advantage of this over changing the __init to __ref.
>>> Or am I missing something? I see your patch as an unnecessary API change.
>>> The way I understand it, __ref was introduced exactly for cases like this
>>> one where function is referenced from "normal" data but used only during
>>> init. Could you try to clarify for me why you think your solution is
>>> better then mine?
>
>> - Using __ref instead of __init moves all bind functions from .init.text
>> to .text and so the code isn't freed after booting or module loading.
>> (OK, you could fix this by marking the driver structs as __ref and
>> keep __init for the bind functions.)
>
> I believe this to be untrue. __ref puts code in .ref.text which AFAIK is
> freed.
I'm pretty sure it's not freed. .ref.text is of course correct.
>> - Using __ref might hide section mismatches. (Your patch hasn't this
>> problem as the bind functions used to live in .init.text, so any
>> reference to .init should be OK assuming that it was OK to live in
>> .init.text in the first place. But when marking the driver structs
>> this is an issue.) That's why I don't like __ref and said my patch
>> were better as it doesn't make use of it.
>>
>> - The bind functions are only called at init time, so there is no need
>> to save a pointer to it.
>
> OK, I see some merit in this approach. However, the same issue is with
> usb_configuration and ?usb_composite_driver -- those should be changed
> in the same way or it would defeat the purpose of the patch.
I didn't skip these on purpose. I just stumbled over the gadget drivers
first.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 10/15] powerpc: Replace hardcoded offset by BREAK_INSTR_SIZE
From: Jason Wessel @ 2010-07-30 19:17 UTC (permalink / raw)
To: linux-kernel
Cc: Michal Simek, kgdb-bugreport, Jason Wessel, linuxppc-dev, mingo
In-Reply-To: <1280517456-1167-1-git-send-email-jason.wessel@windriver.com>
From: Michal Simek <monstr@monstr.eu>
kgdb_handle_breakpoint checks the first arch_kgdb_breakpoint
which is not known by gdb that's why is necessary jump over
it. The jump lenght is equal to BREAK_INSTR_SIZE that's
why is cleaner to use defined macro instead of hardcoded
non-described offset.
Signed-off-by: Michal Simek <monstr@monstr.eu>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: linuxppc-dev@ozlabs.org
---
arch/powerpc/kernel/kgdb.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
index 82a7b22..7f61a3a 100644
--- a/arch/powerpc/kernel/kgdb.c
+++ b/arch/powerpc/kernel/kgdb.c
@@ -129,7 +129,7 @@ static int kgdb_handle_breakpoint(struct pt_regs *regs)
return 0;
if (*(u32 *) (regs->nip) == *(u32 *) (&arch_kgdb_ops.gdb_bpt_instr))
- regs->nip += 4;
+ regs->nip += BREAK_INSTR_SIZE;
return 1;
}
--
1.6.4.rc1
^ permalink raw reply related
* Re: [PATCH 10/15] powerpc: Replace hardcoded offset by BREAK_INSTR_SIZE
From: Benjamin Herrenschmidt @ 2010-07-30 23:44 UTC (permalink / raw)
To: Jason Wessel
Cc: linuxppc-dev, kgdb-bugreport, mingo, linux-kernel, Michal Simek
In-Reply-To: <1280517456-1167-11-git-send-email-jason.wessel@windriver.com>
On Fri, 2010-07-30 at 14:17 -0500, Jason Wessel wrote:
> From: Michal Simek <monstr@monstr.eu>
>
> kgdb_handle_breakpoint checks the first arch_kgdb_breakpoint
> which is not known by gdb that's why is necessary jump over
> it. The jump lenght is equal to BREAK_INSTR_SIZE that's
> why is cleaner to use defined macro instead of hardcoded
> non-described offset.
Yeah well, all powerpc instructions are 4 bytes :-) But the
patch is fine.
> Signed-off-by: Michal Simek <monstr@monstr.eu>
> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: linuxppc-dev@ozlabs.org
> ---
> arch/powerpc/kernel/kgdb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index 82a7b22..7f61a3a 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -129,7 +129,7 @@ static int kgdb_handle_breakpoint(struct pt_regs *regs)
> return 0;
>
> if (*(u32 *) (regs->nip) == *(u32 *) (&arch_kgdb_ops.gdb_bpt_instr))
> - regs->nip += 4;
> + regs->nip += BREAK_INSTR_SIZE;
>
> return 1;
> }
^ permalink raw reply
* Re: [PATCH 0/8] v3 De-couple sysfs memory directories from memory sections
From: Benjamin Herrenschmidt @ 2010-07-31 5:36 UTC (permalink / raw)
To: Nathan Fontenot
Cc: linux-mm, greg, linux-kernel, KAMEZAWA Hiroyuki, linuxppc-dev
In-Reply-To: <4C451BF5.50304@austin.ibm.com>
On Mon, 2010-07-19 at 22:45 -0500, Nathan Fontenot wrote:
> This set of patches de-couples the idea that there is a single
> directory in sysfs for each memory section. The intent of the
> patches is to reduce the number of sysfs directories created to
> resolve a boot-time performance issue. On very large systems
> boot time are getting very long (as seen on powerpc hardware)
> due to the enormous number of sysfs directories being created.
> On a system with 1 TB of memory we create ~63,000 directories.
> For even larger systems boot times are being measured in hours.
Greg, Kame, how do we proceed with these ? I'm happy to put them in
powerpc.git with appropriate acks or will you take them ?
Cheers,
Ben.
^ permalink raw reply
* Re: Which microcode patch for MPC870?
From: Shawn Jin @ 2010-07-31 6:30 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: ppcdev
In-Reply-To: <20100730064521.GA20351@oksana.dev.rtsoft.ru>
>> Which microcode patch should be selected for MPC870? In the old 2.4
>> kernel, the CONFIG_UCODE_PATCH was selected. What's the corresponding
>> config: CONFIG_USB_SOF_UCODE_PATCH or CONFIG_I2C_SPI_UCODE_PATCH or
>> CONFIG_I2C_SPI_SMC1_UCODE_PATCH? Since my board doesn't have USB, I
>> believe USB microcode is irrelevant here. So it comes down the other
>> two choices. Of course do I really need the patch? My board has I2C
>> and SMC1, but no SPI.
>>
>> I chose CONFIG_I2C_SPI_UCODE_PATCH as an experiment but got the
>> following compilation error:
>
> These errors were fixed by
>
> http://patchwork.ozlabs.org/patch/58262/
> and
> http://patchwork.ozlabs.org/patch/58263/
Thanks a lot for the info, Anton.
Then the question is which patch should be selected. I don't enable
any patch and the SMC UART works properly. Next I'm going to enable
I2C but I don't know whether a microcode patch is required or not.
Thanks,
-Shawn.
^ permalink raw reply
* Re: ramdisk size is larger than 4MB
From: Shawn Jin @ 2010-07-31 6:32 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev
In-Reply-To: <20100730120424.6db4139f@schlenkerla.am.freescale.net>
>> One way to lift this limitation is to relocate the bootwrapper to
>> somewhere else, say for example, 0x1000000 so that a 16MB initramfs
>> can be loaded. If the bootwrapper is relocated, what else would be
>> affected by this relocation?
>
> It should be fine to just change it locally. =A0It would be a problem to
> change it upstream for all boards, since some supported boards have
> only 16MB (or even 8MB) of RAM.
I'll definitely try to change it locally first. Would a configurable
base address for the bootwrapper an acceptable solution?
> Another option is to provide a vmlinux_alloc callback to stick the
> kernel somewhere other than zero, at the cost of an extra image copy
> once the kernel runs to get itself back down to zero. =A0This wasn't done
> in cuboot because it was considered better to adjust the bootwrapper
> link address at build time based on the kernel+ramfs image size, but
> that never got implemented.
>
> Perhaps a reasonable compromise is a vmlinux_alloc that returns zero if
> the image fits there, and calls malloc otherwise?
I'll look into this too.
Thanks,
-Shawn.
^ permalink raw reply
* [PATCH 2/7] usb: fsl_udc_core: check return value of create_proc_read_entry()
From: Kulikov Vasiliy @ 2010-07-31 17:38 UTC (permalink / raw)
To: kernel-janitors
Cc: David Brownell, Greg Kroah-Hartman, linux-kernel, linuxppc-dev,
linux-usb, Anton Vorontsov, Dinh Nguyen
create_proc_read_entry() may fail, if so return -ENOMEM.
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/usb/gadget/fsl_udc_core.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/fsl_udc_core.c b/drivers/usb/gadget/fsl_udc_core.c
index 08a9a62..c3d1545 100644
--- a/drivers/usb/gadget/fsl_udc_core.c
+++ b/drivers/usb/gadget/fsl_udc_core.c
@@ -2128,7 +2128,7 @@ static int fsl_proc_read(char *page, char **start, off_t off, int count,
#else /* !CONFIG_USB_GADGET_DEBUG_FILES */
-#define create_proc_file() do {} while (0)
+#define create_proc_file() ({ (void *)1; })
#define remove_proc_file() do {} while (0)
#endif /* CONFIG_USB_GADGET_DEBUG_FILES */
@@ -2373,9 +2373,14 @@ static int __init fsl_udc_probe(struct platform_device *pdev)
ret = -ENOMEM;
goto err_unregister;
}
- create_proc_file();
+ if (create_proc_file() == 0) {
+ ret = -ENOMEM;
+ goto err_pool;
+ }
return 0;
+err_pool:
+ dma_pool_destroy(udc_controller->td_pool);
err_unregister:
device_unregister(&udc_controller->gadget.dev);
err_free_irq:
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/7] usb: fsl_udc_core: check return value of create_proc_read_entry()
From: Dan Carpenter @ 2010-07-31 19:17 UTC (permalink / raw)
To: Kulikov Vasiliy
Cc: David Brownell, Greg Kroah-Hartman, kernel-janitors, linux-kernel,
linuxppc-dev, linux-usb, Anton Vorontsov, Dinh Nguyen
In-Reply-To: <1280597900-8405-1-git-send-email-segooon@gmail.com>
On Sat, Jul 31, 2010 at 09:38:20PM +0400, Kulikov Vasiliy wrote:
> create_proc_read_entry() may fail, if so return -ENOMEM.
>
It can fail, but also we return NULL if procfs is disabled. I haven't
looked at it very carefully, would this patch break the module if procfs
was disabled?
The same applies to the similar patches in this set.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 0/8] v3 De-couple sysfs memory directories from memory sections
From: Greg KH @ 2010-07-31 19:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-mm, linux-kernel, KAMEZAWA Hiroyuki, linuxppc-dev
In-Reply-To: <1280554584.1902.31.camel@pasglop>
On Sat, Jul 31, 2010 at 03:36:24PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2010-07-19 at 22:45 -0500, Nathan Fontenot wrote:
> > This set of patches de-couples the idea that there is a single
> > directory in sysfs for each memory section. The intent of the
> > patches is to reduce the number of sysfs directories created to
> > resolve a boot-time performance issue. On very large systems
> > boot time are getting very long (as seen on powerpc hardware)
> > due to the enormous number of sysfs directories being created.
> > On a system with 1 TB of memory we create ~63,000 directories.
> > For even larger systems boot times are being measured in hours.
>
> Greg, Kame, how do we proceed with these ? I'm happy to put them in
> powerpc.git with appropriate acks or will you take them ?
I thought there would be at least one more round of these patches based
on the review comments, right?
I'll be glad to take them when everyone agrees with them.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 0/8] v3 De-couple sysfs memory directories from memory sections
From: Benjamin Herrenschmidt @ 2010-08-01 0:27 UTC (permalink / raw)
To: Greg KH; +Cc: linux-mm, linux-kernel, KAMEZAWA Hiroyuki, linuxppc-dev
In-Reply-To: <20100731195506.GC4644@kroah.com>
On Sat, 2010-07-31 at 12:55 -0700, Greg KH wrote:
> On Sat, Jul 31, 2010 at 03:36:24PM +1000, Benjamin Herrenschmidt wrote:
> > On Mon, 2010-07-19 at 22:45 -0500, Nathan Fontenot wrote:
> > > This set of patches de-couples the idea that there is a single
> > > directory in sysfs for each memory section. The intent of the
> > > patches is to reduce the number of sysfs directories created to
> > > resolve a boot-time performance issue. On very large systems
> > > boot time are getting very long (as seen on powerpc hardware)
> > > due to the enormous number of sysfs directories being created.
> > > On a system with 1 TB of memory we create ~63,000 directories.
> > > For even larger systems boot times are being measured in hours.
> >
> > Greg, Kame, how do we proceed with these ? I'm happy to put them in
> > powerpc.git with appropriate acks or will you take them ?
>
> I thought there would be at least one more round of these patches based
> on the review comments, right?
Yes, but I was nontheless inquiring whether I should pick them up after
said repost :-)
> I'll be glad to take them when everyone agrees with them.
Ok, good, one less thing to worry about in powerpc patchwork :-)
Cheers,
Ben.
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH 0/2 v3] mpc5200 ac97 gpio reset
From: Grant Likely @ 2010-08-01 4:42 UTC (permalink / raw)
To: Mark Brown; +Cc: linuxppc-dev@lists.ozlabs.org, Eric Millbrandt
In-Reply-To: <D37786F8-EBA7-4E55-AE83-5D0ABF1E17BF@opensource.wolfsonmicro.com>
On Sun, Jun 27, 2010 at 4:01 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
> On 26 Jun 2010, at 00:04, Grant Likely <grant.likely@secretlab.ca> wrote:
>
>> On Tue, Jun 22, 2010 at 5:00 PM, Mark Brown
>>> On Tue, Jun 15, 2010 at 12:05:05PM -0400, Eric Millbrandt wrote:
>>>> These patches reimplement the reset fuction in the ac97 to use gpio pi=
ns
>>>> instead of using the mpc5200 ac97 reset functionality in the psc. =A0T=
his
>>>> avoids a problem in which attached ac97 devices go into "test" mode ap=
pear
>>>> unresponsive.
>>>>
>>>> These patches were tested on a pcm030 baseboard and on custom hardware=
with
>>>> a wm9715 audio codec/touchscreen controller.
>>>
>>> Grant, are you OK with this series?
>>
>> Yes, I'm going to pick it up.
>
> I'm a little concerned with a collision with multi codec here. It'd
> be handy if you could keep it separate in case it needs merging
> into both trees (or we could merge via ASoC only).
Hmmm. Yeah, probably better to take it via your tree then. I've
currently got patch 1 in linux-next, but I'll drop it before asking
benh to pull. Go ahead and add my acked-by.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/7] usb: fsl_udc_core: check return value of create_proc_read_entry()
From: Vasiliy Kulikov @ 2010-08-01 6:19 UTC (permalink / raw)
To: Dan Carpenter, kernel-janitors, Li Yang, David Brownell,
Greg Kroah-Hartman, Dinh Nguyen, Anton Vorontsov, linux-usb,
linuxppc-dev, linux-kernel
In-Reply-To: <20100731191743.GF26313@bicker>
On Sat, Jul 31, 2010 at 21:17 +0200, Dan Carpenter wrote:
> On Sat, Jul 31, 2010 at 09:38:20PM +0400, Kulikov Vasiliy wrote:
> > create_proc_read_entry() may fail, if so return -ENOMEM.
> >
>
> It can fail, but also we return NULL if procfs is disabled. I haven't
> looked at it very carefully, would this patch break the module if procfs
> was disabled?
Probably you are right, but many drivers in tree compare return value
with NULL. Some of them interpret this as error, some of them simply
call pr_warn("Hmm, I cannot create file in proc, strange..."). Maybe
there is more simplier way to check it without #ifdefs?
>
> The same applies to the similar patches in this set.
>
> regards,
> dan carpenter
>
>
^ permalink raw reply
* Re: [PATCH] PCI: MSI: Restore read_msi_msg_desc(); add get_cached_msi_msg_desc()
From: Michael Ellerman @ 2010-08-01 6:23 UTC (permalink / raw)
To: Jesse Barnes; +Cc: Ben Hutchings, Stephen Rothwell, ppc-dev, LKML, linux-pci
In-Reply-To: <20100730094247.05cb070e@virtuousgeek.org>
[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]
On Fri, 2010-07-30 at 09:42 -0700, Jesse Barnes wrote:
> On Fri, 23 Jul 2010 14:56:28 +0100
> Ben Hutchings <bhutchings@solarflare.com> wrote:
>
> > commit 2ca1af9aa3285c6a5f103ed31ad09f7399fc65d7 "PCI: MSI: Remove
> > unsafe and unnecessary hardware access" changed read_msi_msg_desc() to
> > return the last MSI message written instead of reading it from the
> > device, since it may be called while the device is in a reduced
> > power state.
> >
> > However, the pSeries platform code really does need to read messages
> > from the device, since they are initially written by firmware.
> > Therefore:
> > - Restore the previous behaviour of read_msi_msg_desc()
> > - Add new functions get_cached_msi_msg{,_desc}() which return the
> > last MSI message written
> > - Use the new functions where appropriate
> >
> > Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> > ---
> > Compile-tested only.
> >
>
> Applied to linux-next with Michael's ack, thanks. I hope it actually
> works, I didn't see a tested-by!
I assume Stephen has been using it, otherwise his linux-next boot tests
will all have been failing. Either way he'll test it when it gets into
linux-next proper.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] of/device: Replace struct of_device with struct of_platform
From: Grant Likely @ 2010-08-01 7:57 UTC (permalink / raw)
To: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, benh, sparclinux, davem
of_device is just an alias for platform_device, so remove it entirely. Also
replace to_of_device() with to_platform_device().
This patch was initially generated from the following semantic patch, and then
edited by hand to pick up the bits that coccinelle didn't catch.
@@
@@
-struct of_device
+struct platform_device
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
This patch is *huge*, so rather than posting it and having lists barf at me, I've pushed it out to my git tree. You can view the branch[1] and the diff[2].
[1] http://git.secretlab.ca/?p=linux-2.6.git;a=shortlog;h=refs/heads/devicetree/of-device-rename
[2] http://git.secretlab.ca/?p=linux-2.6.git;a=commitdiff;h=48465300aab074396bdbad54b4fa01c793e5c987;hp=7fb8f881c54beb05dd4d2c947dada1c636581d87
It is a very mechanical change, only replaces of_device references with platform_device. I won't push it into linux-next right away because it's sure to cause a truckload of conflicts. Instead, I'll wait until the merge window settles down, spin it again with all the new driver changes, repost and ask Linus to pull.
If anyone has any problems with this plan, then please let me know.
Cheers,
g.
drivers/ata/pata_mpc52xx.c | 8 ++---
drivers/ata/pata_of_platform.c | 4 +-
drivers/ata/sata_fsl.c | 8 ++---
drivers/atm/fore200e.c | 26 +++++++--------
drivers/block/xsysace.c | 4 +-
drivers/char/hw_random/n2-drv.c | 4 +-
drivers/char/hw_random/n2rng.h | 2 +
drivers/char/hw_random/pasemi-rng.c | 4 +-
drivers/char/ipmi/ipmi_si_intf.c | 4 +-
drivers/char/rtc.c | 2 +
drivers/char/xilinx_hwicap/xilinx_hwicap.c | 4 +-
drivers/crypto/amcc/crypto4xx_core.c | 4 +-
drivers/crypto/amcc/crypto4xx_core.h | 2 +
drivers/crypto/n2_core.c | 20 ++++++-----
drivers/crypto/talitos.c | 6 ++-
drivers/dma/fsldma.c | 4 +-
drivers/dma/mpc512x_dma.c | 4 +-
drivers/dma/ppc4xx/adma.c | 8 ++---
drivers/edac/mpc85xx_edac.c | 12 +++----
drivers/edac/ppc4xx_edac.c | 12 +++----
drivers/hwmon/ams/ams.h | 2 +
drivers/hwmon/ultra45_env.c | 4 +-
drivers/i2c/busses/i2c-cpm.c | 8 ++---
drivers/i2c/busses/i2c-ibm_iic.c | 6 ++-
drivers/i2c/busses/i2c-mpc.c | 4 +-
drivers/infiniband/hw/ehca/ehca_classes.h | 2 +
drivers/infiniband/hw/ehca/ehca_main.c | 4 +-
drivers/input/misc/sparcspkr.c | 10 +++---
drivers/input/serio/i8042-sparcio.h | 8 ++---
drivers/input/serio/xilinx_ps2.c | 4 +-
drivers/leds/leds-gpio.c | 4 +-
drivers/macintosh/macio_sysfs.c | 6 ++-
drivers/macintosh/smu.c | 6 ++-
drivers/macintosh/therm_adt746x.c | 2 +
drivers/macintosh/therm_pm72.c | 6 ++-
drivers/macintosh/therm_windtunnel.c | 6 ++-
drivers/mmc/host/sdhci-of-core.c | 8 ++---
drivers/mtd/maps/physmap_of.c | 8 ++---
drivers/mtd/maps/sun_uflash.c | 6 ++-
drivers/mtd/nand/fsl_elbc_nand.c | 4 +-
drivers/mtd/nand/fsl_upm.c | 4 +-
drivers/mtd/nand/mpc5121_nfc.c | 4 +-
drivers/mtd/nand/ndfc.c | 6 ++-
drivers/mtd/nand/pasemi_nand.c | 4 +-
drivers/mtd/nand/socrates_nand.c | 4 +-
drivers/net/can/mscan/mpc5xxx_can.c | 18 +++++-----
drivers/net/can/sja1000/sja1000_of_platform.c | 4 +-
drivers/net/ehea/ehea.h | 4 +-
drivers/net/ehea/ehea_main.c | 12 +++----
drivers/net/fec_mpc52xx.c | 8 ++---
drivers/net/fec_mpc52xx_phy.c | 4 +-
drivers/net/fs_enet/fs_enet-main.c | 4 +-
drivers/net/fs_enet/mac-fcc.c | 2 +
drivers/net/fs_enet/mac-fec.c | 2 +
drivers/net/fs_enet/mac-scc.c | 2 +
drivers/net/fs_enet/mii-bitbang.c | 4 +-
drivers/net/fs_enet/mii-fec.c | 4 +-
drivers/net/fsl_pq_mdio.c | 4 +-
drivers/net/gianfar.c | 10 +++---
drivers/net/gianfar.h | 2 +
drivers/net/greth.c | 4 +-
drivers/net/ibm_newemac/core.c | 6 ++-
drivers/net/ibm_newemac/core.h | 12 +++----
drivers/net/ibm_newemac/mal.c | 4 +-
drivers/net/ibm_newemac/mal.h | 2 +
drivers/net/ibm_newemac/rgmii.c | 18 +++++-----
drivers/net/ibm_newemac/rgmii.h | 16 +++++----
drivers/net/ibm_newemac/tah.c | 14 ++++----
drivers/net/ibm_newemac/tah.h | 12 +++----
drivers/net/ibm_newemac/zmii.c | 18 +++++-----
drivers/net/ibm_newemac/zmii.h | 16 +++++----
drivers/net/ll_temac_main.c | 8 ++---
drivers/net/myri_sbus.c | 4 +-
drivers/net/myri_sbus.h | 2 +
drivers/net/niu.c | 8 ++---
drivers/net/phy/mdio-gpio.c | 4 +-
drivers/net/sunbmac.c | 18 +++++-----
drivers/net/sunbmac.h | 4 +-
drivers/net/sunhme.c | 22 ++++++-------
drivers/net/sunlance.c | 20 ++++++-----
drivers/net/sunqe.c | 16 +++++----
drivers/net/sunqe.h | 4 +-
drivers/net/ucc_geth.c | 8 ++---
drivers/net/xilinx_emaclite.c | 6 ++-
drivers/parport/parport_sunbpp.c | 4 +-
drivers/pcmcia/electra_cf.c | 6 ++-
drivers/pcmcia/m8xx_pcmcia.c | 4 +-
drivers/rtc/rtc-mpc5121.c | 4 +-
drivers/sbus/char/bbc_envctrl.c | 6 ++-
drivers/sbus/char/bbc_i2c.c | 18 +++++-----
drivers/sbus/char/bbc_i2c.h | 10 +++---
drivers/sbus/char/display7seg.c | 4 +-
drivers/sbus/char/envctrl.c | 4 +-
drivers/sbus/char/flash.c | 4 +-
drivers/sbus/char/uctrl.c | 4 +-
drivers/scsi/qlogicpti.c | 14 ++++----
drivers/scsi/qlogicpti.h | 2 +
drivers/scsi/sun_esp.c | 44 +++++++++++++------------
drivers/serial/apbuart.c | 2 +
drivers/serial/cpm_uart/cpm_uart_core.c | 4 +-
drivers/serial/mpc52xx_uart.c | 8 ++---
drivers/serial/nwpserial.c | 2 +
drivers/serial/of_serial.c | 6 ++-
drivers/serial/sunhv.c | 4 +-
drivers/serial/sunsab.c | 8 ++---
drivers/serial/sunsu.c | 8 ++---
drivers/serial/sunzilog.c | 6 ++-
drivers/serial/uartlite.c | 4 +-
drivers/serial/ucc_uart.c | 4 +-
drivers/spi/mpc512x_psc_spi.c | 4 +-
drivers/spi/mpc52xx_psc_spi.c | 4 +-
drivers/spi/mpc52xx_spi.c | 4 +-
drivers/spi/spi_mpc8xxx.c | 4 +-
drivers/spi/spi_ppc4xx.c | 4 +-
drivers/spi/xilinx_spi_of.c | 6 ++-
drivers/usb/gadget/fsl_qe_udc.c | 10 +++---
drivers/usb/host/ehci-ppc-of.c | 6 ++-
drivers/usb/host/ehci-xilinx-of.c | 6 ++-
drivers/usb/host/fhci-hcd.c | 4 +-
drivers/usb/host/isp1760-if.c | 4 +-
drivers/usb/host/ohci-ppc-of.c | 6 ++-
drivers/video/bw2.c | 4 +-
drivers/video/cg14.c | 6 ++-
drivers/video/cg3.c | 4 +-
drivers/video/cg6.c | 6 ++-
drivers/video/ffb.c | 4 +-
drivers/video/fsl-diu-fb.c | 8 ++---
drivers/video/leo.c | 6 ++-
drivers/video/mb862xx/mb862xxfb.c | 4 +-
drivers/video/p9100.c | 4 +-
drivers/video/platinumfb.c | 4 +-
drivers/video/sunxvr1000.c | 4 +-
drivers/video/tcx.c | 6 ++-
drivers/video/xilinxfb.c | 4 +-
drivers/watchdog/cpwd.c | 4 +-
drivers/watchdog/gef_wdt.c | 2 +
drivers/watchdog/mpc8xxx_wdt.c | 4 +-
drivers/watchdog/riowd.c | 4 +-
include/linux/of_device.h | 3 --
sound/aoa/soundbus/core.c | 2 +
sound/aoa/soundbus/soundbus.h | 2 +
sound/aoa/soundbus/sysfs.c | 2 +
sound/soc/fsl/mpc5200_dma.c | 4 +-
sound/soc/fsl/mpc5200_dma.h | 4 +-
sound/soc/fsl/mpc5200_psc_ac97.c | 4 +-
sound/soc/fsl/mpc5200_psc_i2s.c | 4 +-
sound/soc/fsl/mpc8610_hpcd.c | 4 +-
sound/sparc/amd7930.c | 8 ++---
sound/sparc/cs4231.c | 18 +++++-----
sound/sparc/dbri.c | 8 ++---
150 files changed, 493 insertions(+), 496 deletions(-)
^ permalink raw reply
* Re: [PATCH] of/device: Replace struct of_device with struct of_platform
From: David Miller @ 2010-08-01 8:05 UTC (permalink / raw)
To: grant.likely
Cc: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, sparclinux
In-Reply-To: <20100801074831.1099.3318.stgit@angua>
Subject should say "struct platform_device" not "struct of_platform",
I think :-)
^ permalink raw reply
* Re: [PATCH] of/device: Replace struct of_device with struct of_platform
From: Grant Likely @ 2010-08-01 8:08 UTC (permalink / raw)
To: David Miller
Cc: sfr, monstr, microblaze-uclinux, devicetree-discuss, linux-kernel,
linuxppc-dev, sparclinux
In-Reply-To: <20100801.010501.27813939.davem@davemloft.net>
On Sun, Aug 1, 2010 at 2:05 AM, David Miller <davem@davemloft.net> wrote:
>
> Subject should say "struct platform_device" not "struct of_platform",
> I think :-)
Gah! yup, will fix. Thanks.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/7] usb: fsl_udc_core: check return value of create_proc_read_entry()
From: Dan Carpenter @ 2010-08-01 10:49 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: David Brownell, Greg Kroah-Hartman, kernel-janitors, linux-kernel,
linuxppc-dev, linux-usb, Anton Vorontsov, Dinh Nguyen
In-Reply-To: <20100801061934.GB2650@albatros>
On Sun, Aug 01, 2010 at 10:19:34AM +0400, Vasiliy Kulikov wrote:
> On Sat, Jul 31, 2010 at 21:17 +0200, Dan Carpenter wrote:
> > On Sat, Jul 31, 2010 at 09:38:20PM +0400, Kulikov Vasiliy wrote:
> > > create_proc_read_entry() may fail, if so return -ENOMEM.
> > >
> >
> > It can fail, but also we return NULL if procfs is disabled. I haven't
> > looked at it very carefully, would this patch break the module if procfs
> > was disabled?
> Probably you are right, but many drivers in tree compare return value
> with NULL. Some of them interpret this as error, some of them simply
> call pr_warn("Hmm, I cannot create file in proc, strange..."). Maybe
> there is more simplier way to check it without #ifdefs?
>
If the allocation fails, there is already a warning so no need to add
another.
These things are one time allocation, normally near boot up when memory
is plentifull. The places that do check should be audited to make sure
there isn't an unneeded dependency on PROC_FS. I would just leave the
rest.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers (fix)
From: Anton Vorontsov @ 2010-08-01 10:54 UTC (permalink / raw)
To: Andrew Morton, Scott Wood
Cc: linuxppc-dev, Peter Tyser, Doug Thompson, linux-kernel,
Dave Jiang
In-Reply-To: <20100721182108.5a22c822@schlenkerla.am.freescale.net>
On Wed, Jul 21, 2010 at 06:21:08PM -0500, Scott Wood wrote:
[...]
> > > > + { .compatible = "fsl,p4080-l2-cache-controller", },
> > >
> > > L2 on the p4080 is quite different from those other chips. It's part
> > > of the core, controlled by SPRs.
> >
> > erm, was that an ack or a nack?
>
> NACK, p4080 doesn't belong in this table, at least not its L2.
>
> L3 on p4080 is similar to L2 on these other chips, though, and it
> wouldn't take much to get this driver working on it -- but the match
> table entry should wait until the differences are accommodated.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
Scott, thanks for catching this!
Andrew, please merge this patch into
edac-mpc85xx-add-support-for-new-mpcxxx-pxxxx-edac-controllers.patch
Thanks!
drivers/edac/mpc85xx_edac.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index cfa86f7..b178cfa 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -652,7 +652,6 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
{ .compatible = "fsl,p1020-l2-cache-controller", },
{ .compatible = "fsl,p1021-l2-cache-controller", },
{ .compatible = "fsl,p2020-l2-cache-controller", },
- { .compatible = "fsl,p4080-l2-cache-controller", },
{},
};
MODULE_DEVICE_TABLE(of, mpc85xx_l2_err_of_match);
--
1.7.0.5
^ permalink raw reply related
* Re: [PATCH 00/27] KVM PPC PV framework v3
From: Avi Kivity @ 2010-08-01 14:02 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <1280407688-9815-1-git-send-email-agraf@suse.de>
On 07/29/2010 03:47 PM, Alexander Graf wrote:
> 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
>
Looks reasonable. Since it's fair to say I understand nothing about
powerpc, I'd like someone who does to review it and ack, please, with an
emphasis on the interfaces.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 4/7] KVM: PPC: Add book3s_32 tlbie flush acceleration
From: Avi Kivity @ 2010-08-01 14:08 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc
In-Reply-To: <1280408662-10328-5-git-send-email-agraf@suse.de>
On 07/29/2010 04:04 PM, Alexander Graf wrote:
> On Book3s_32 the tlbie instruction flushed effective addresses by the mask
> 0x0ffff000. This is pretty hard to reflect with a hash that hashes ~0xfff, so
> to speed up that target we should also keep a special hash around for it.
>
>
> static inline u64 kvmppc_mmu_hash_vpte(u64 vpage)
> {
> return hash_64(vpage& 0xfffffffffULL, HPTEG_HASH_BITS_VPTE);
> @@ -66,6 +72,11 @@ void kvmppc_mmu_hpte_cache_map(struct kvm_vcpu *vcpu, struct hpte_cache *pte)
> index = kvmppc_mmu_hash_pte(pte->pte.eaddr);
> hlist_add_head_rcu(&pte->list_pte,&vcpu->arch.hpte_hash_pte[index]);
>
> + /* Add to ePTE_long list */
> + index = kvmppc_mmu_hash_pte_long(pte->pte.eaddr);
> + hlist_add_head_rcu(&pte->list_pte_long,
> + &vcpu->arch.hpte_hash_pte_long[index]);
> +
Isn't it better to make operations on this list conditional on
Book3s_32? Hashes are expensive since they usually cost cache misses.
Can of course be done later as an optimization.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox