* [PATCH] powerpc/mm: Fix parse_arg build error
From: Matthew McClintock @ 2012-01-13 5:05 UTC (permalink / raw)
To: linuxppc-dev, benh
This fixes this build issue:
arch/powerpc/mm/hugetlbpage.c: In function 'reserve_hugetlb_gpages':
arch/powerpc/mm/hugetlbpage.c:312:2: error: implicit declaration of function 'parse_args'
make[1]: *** [arch/powerpc/mm/hugetlbpage.o] Error 1
Signed-off-by: Matthew McClintock <msm@freescale.com>
---
This is for benh next tree
arch/powerpc/mm/hugetlbpage.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 79c575d..a8b3cc7 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -15,6 +15,7 @@
#include <linux/of_fdt.h>
#include <linux/memblock.h>
#include <linux/bootmem.h>
+#include <linux/moduleparam.h>
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
#include <asm/tlb.h>
--
1.7.6.1
^ permalink raw reply related
* Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one
From: Grant Likely @ 2012-01-13 2:20 UTC (permalink / raw)
To: Rob Herring
Cc: sfr, Russell King, linux-kernel, Thomas Gleixner, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <4F0F7B60.5040701@gmail.com>
On Thu, Jan 12, 2012 at 06:31:28PM -0600, Rob Herring wrote:
> Adding lakml...
>
> On 01/11/2012 03:27 PM, Grant Likely wrote:
> > On Wed, Jan 11, 2012 at 2:15 PM, Rob Herring <robherring2@gmail.com> wrote:
> >> Grant,
> >>
> >> On 01/11/2012 02:22 PM, Grant Likely wrote:
> >>> This patch removes the simplistic implementation of irq_domains and enables
> >>> the powerpc infrastructure for all irq_domain users. The powerpc
> >>> infrastructure includes support for complex mappings between Linux and
> >>> hardware irq numbers, and can manage allocation of irq_descs.
> >>>
> >>> This patch also converts the few users of irq_domain_add()/irq_domain_del()
> >>> to call irq_domain_add_legacy() instead.
> >>
> >> So what is the non-legacy way? Legacy implies we don't want to do it
> >> that way. I guess until we remove all non-DT platforms with GIC we are
> >> stuck with legacy. That seems like it could be a ways out until we get
> >> there.
> >
> > Non-legacy is letting the irq_domain manage the irq_desc allocations.
> > Some of the controllers will be easy to convert, some will be more
> > difficult. The primary thing that really blocks getting away from the
> > legacy method is anything that expects hardcoded #defined irq numbers.
> > The goal is to convert all users over to the linear revmap method.
> >
>
> So I gave this a spin on highbank. I ran into a couple problems.
>
> I had to revert "irqdesc: Consolidate irq reservation logic" which is in
> your branch, but not this series. irq_alloc_desc_from was returning -EEXIST.
Gah, I flubbed that patch too. Try this on top of it:
---
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 8a9e2ec..11feb2f 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -375,6 +375,9 @@ __irq_reserve_irqs(int irq, unsigned int from, unsigned int cnt)
}
bitmap_set(allocated_irqs, start, cnt);
+ mutex_unlock(&sparse_irq_lock);
+ return start;
+
err:
mutex_unlock(&sparse_irq_lock);
return ret;
@@ -408,7 +411,8 @@ EXPORT_SYMBOL_GPL(__irq_alloc_descs);
*/
int irq_reserve_irqs(unsigned int from, unsigned int cnt)
{
- return __irq_reserve_irqs(from, from, cnt);
+ int start = __irq_reserve_irqs(from, from, cnt);
+ return start < 0 ? start : 0;
}
/**
^ permalink raw reply related
* Re: [RFC 12/14] irq_domain: Add support for base irq and hwirq in legacy mappings
From: Grant Likely @ 2012-01-13 0:53 UTC (permalink / raw)
To: Rob Herring
Cc: sfr, Russell King, linux-kernel, Thomas Gleixner, linuxppc-dev
In-Reply-To: <4F0F7CC5.5080900@gmail.com>
On Thu, Jan 12, 2012 at 5:37 PM, Rob Herring <robherring2@gmail.com> wrote:
> On 01/11/2012 02:22 PM, Grant Likely wrote:
>> Add support for a legacy mapping where irq =3D (hwirq - first_hwirq + fi=
rst_irq)
>> so that a controller driver can allocate a fixed range of irq_descs and =
use
>> a simple calculation to translate back and forth between linux and hw ir=
q
>> numbers. =A0This is needed to use an irq_domain with many of the ARM int=
errupt
>> controller drivers that manage their own irq_desc allocations. =A0Ultima=
tely
>> the goal is to migrate those drivers to use the linear revmap, but doing=
it
>> this way allows each driver to be converted separately which makes the
>> migration path easier.
>>
>> This patch generalizes the IRQ_DOMAIN_MAP_LEGACY method to use
>> (first_irq-first_hwirq) as the offset between hwirq and linux irq number=
,
>> and adds checks to make sure that the hwirq number does not exceed range
>> assigned to the controller.
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> ---
>> =A0arch/powerpc/include/asm/irq.h =A0 | =A0 =A03 -
>> =A0arch/powerpc/sysdev/i8259.c =A0 =A0 =A0| =A0 =A02 +-
>> =A0arch/powerpc/sysdev/tsi108_pci.c | =A0 =A02 +-
>> =A0include/linux/irqdomain.h =A0 =A0 =A0 =A0| =A0 20 +++++++++-
>> =A0kernel/irq/irqdomain.c =A0 =A0 =A0 =A0 =A0 | =A0 78 +++++++++++++++++=
++++++++-------------
>> =A05 files changed, 73 insertions(+), 32 deletions(-)
>>
>
> snip...
>
>> @@ -454,8 +477,11 @@ unsigned int irq_find_mapping(struct irq_domain *do=
main,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0;
>>
>> =A0 =A0 =A0 /* legacy -> bail early */
>> - =A0 =A0 if (domain->revmap_type =3D=3D IRQ_DOMAIN_MAP_LEGACY)
>> - =A0 =A0 =A0 =A0 =A0 =A0 return hwirq;
>> + =A0 =A0 if (domain->revmap_type =3D=3D IRQ_DOMAIN_MAP_LEGACY) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 if (hwirq > domain->revmap_data.legacy.size)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return 0;
>> + =A0 =A0 =A0 =A0 =A0 =A0 return domain->revmap_data.legacy.first_irq + =
hwirq;
>
> This needs a "- domain->revmap_data.legacy.first_hwirq"
Good catch, thanks.
g.
^ permalink raw reply
* Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one
From: Rob Herring @ 2012-01-13 0:53 UTC (permalink / raw)
To: Grant Likely
Cc: sfr, Russell King, linux-kernel, Thomas Gleixner, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CACxGe6vER6hTr0ez9_=bTL+F1n3DZHCa9Yc9fVGQ36i=X62sVQ@mail.gmail.com>
On 01/12/2012 06:47 PM, Grant Likely wrote:
> On Thu, Jan 12, 2012 at 5:31 PM, Rob Herring <robherring2@gmail.com> wrote:
>> Adding lakml...
>>
>> On 01/11/2012 03:27 PM, Grant Likely wrote:
>>> On Wed, Jan 11, 2012 at 2:15 PM, Rob Herring <robherring2@gmail.com> wrote:
>>>> Grant,
>>>>
>>>> On 01/11/2012 02:22 PM, Grant Likely wrote:
>>>>> This patch removes the simplistic implementation of irq_domains and enables
>>>>> the powerpc infrastructure for all irq_domain users. The powerpc
>>>>> infrastructure includes support for complex mappings between Linux and
>>>>> hardware irq numbers, and can manage allocation of irq_descs.
>>>>>
>>>>> This patch also converts the few users of irq_domain_add()/irq_domain_del()
>>>>> to call irq_domain_add_legacy() instead.
>>>>
>>>> So what is the non-legacy way? Legacy implies we don't want to do it
>>>> that way. I guess until we remove all non-DT platforms with GIC we are
>>>> stuck with legacy. That seems like it could be a ways out until we get
>>>> there.
>>>
>>> Non-legacy is letting the irq_domain manage the irq_desc allocations.
>>> Some of the controllers will be easy to convert, some will be more
>>> difficult. The primary thing that really blocks getting away from the
>>> legacy method is anything that expects hardcoded #defined irq numbers.
>>> The goal is to convert all users over to the linear revmap method.
>>>
>>
>> So I gave this a spin on highbank. I ran into a couple problems.
>>
>> I had to revert "irqdesc: Consolidate irq reservation logic" which is in
>> your branch, but not this series. irq_alloc_desc_from was returning -EEXIST.
>
> Hmmm... I thought I sorted that out. Thanks for letting me know.
>
>>
>> The GIC code did not work which I think is specific to using gic_of_init
>> which makes irq_start = -1. With that it still doesn't work. It dies in
>> gic_set_type... I've found one problem which I'll reply inline to, but I
>> think this is a dead end path anyway.
>
> Haha, I'm not surprised. That last patch was only compile tested on
> platforms using the gic. I'm not surprised that I flubbed it.
>
>> You have removed the irq_alloc_descs call from the GIC which is a step
>> backwards. Several of the ARM DT enabled platforms are at the point they
>> can fully support dynamic virq base for each irqchip. I changed the
>> domain from legacy to linear and got things working.
>> The issue with
>
> I hadn't actually intended to remove the irq_alloc_descs in this
> patch. That was a leftover hunk from when I was playing with going
> straight to irq_domain_add_linear(). For this specific patch, I'll
> put the alloc back in and test it that way. A follow-on patch can do
> a proper conversion to the linear revmap.
>
>> linear is for SPARSE_IRQ. The default behavior on ARM for SPARSE_IRQ is
>> all nr_irqs are allocated at boot time before any controller is
>> initialized. The only platform with a GIC and requiring SPARSE_IRQ is
>> shmobile, but it is also the only one that calls irq_alloc_desc
>> functions for it's interrupts. So I think we are okay there. The problem
>> occurs when enabling SPARSE_IRQ for a non-DT platform with a GIC and
>> with irqchips that don't call irq_alloc_desc for their irqs. IMHO, this
>> should be an okay trade-off. There's no advantage to enabling SPARSE_IRQ
>> on ARM for platforms that don't require it. All the platforms with a GIC
>> have active work to convert to DT (except shmobile which I think is
>> okay), so it's a temporary issue.
>
> Actually, I believe Thomas' long term goal is to always enable
> SPARSE_IRQ and remove the option entirely, so it should still be
> properly resolved. I'll take a look next week if I don't get to it
> tomorrow. I need to resurrect my vexpress qemu test environment so I
> can test the permutations.
>
Agreed. I think that is the path to the removing include of mach/irqs.h
as well, and I have a patch series to do just that when SPARSE_IRQ is
enabled. It also has the problem of breaking platforms which don't NEED
to enable SPARSE_IRQ. I'll try to get it sent out soon.
Rob
^ permalink raw reply
* Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one
From: Grant Likely @ 2012-01-13 0:47 UTC (permalink / raw)
To: Rob Herring
Cc: sfr, Russell King, linux-kernel, Thomas Gleixner, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <4F0F7B60.5040701@gmail.com>
On Thu, Jan 12, 2012 at 5:31 PM, Rob Herring <robherring2@gmail.com> wrote:
> Adding lakml...
>
> On 01/11/2012 03:27 PM, Grant Likely wrote:
>> On Wed, Jan 11, 2012 at 2:15 PM, Rob Herring <robherring2@gmail.com> wro=
te:
>>> Grant,
>>>
>>> On 01/11/2012 02:22 PM, Grant Likely wrote:
>>>> This patch removes the simplistic implementation of irq_domains and en=
ables
>>>> the powerpc infrastructure for all irq_domain users. =A0The powerpc
>>>> infrastructure includes support for complex mappings between Linux and
>>>> hardware irq numbers, and can manage allocation of irq_descs.
>>>>
>>>> This patch also converts the few users of irq_domain_add()/irq_domain_=
del()
>>>> to call irq_domain_add_legacy() instead.
>>>
>>> So what is the non-legacy way? Legacy implies we don't want to do it
>>> that way. I guess until we remove all non-DT platforms with GIC we are
>>> stuck with legacy. That seems like it could be a ways out until we get
>>> there.
>>
>> Non-legacy is letting the irq_domain manage the irq_desc allocations.
>> Some of the controllers will be easy to convert, some will be more
>> difficult. =A0The primary thing that really blocks getting away from the
>> legacy method is anything that expects hardcoded #defined irq numbers.
>> =A0The goal is to convert all users over to the linear revmap method.
>>
>
> So I gave this a spin on highbank. I ran into a couple problems.
>
> I had to revert "irqdesc: Consolidate irq reservation logic" which is in
> your branch, but not this series. irq_alloc_desc_from was returning -EEXI=
ST.
Hmmm... I thought I sorted that out. Thanks for letting me know.
>
> The GIC code did not work which I think is specific to using gic_of_init
> which makes irq_start =3D -1. With that it still doesn't work. It dies in
> gic_set_type... I've found one problem which I'll reply inline to, but I
> think this is a dead end path anyway.
Haha, I'm not surprised. That last patch was only compile tested on
platforms using the gic. I'm not surprised that I flubbed it.
> You have removed the irq_alloc_descs call from the GIC which is a step
> backwards. Several of the ARM DT enabled platforms are at the point they
> can fully support dynamic virq base for each irqchip. I changed the
> domain from legacy to linear and got things working.
> The issue with
I hadn't actually intended to remove the irq_alloc_descs in this
patch. That was a leftover hunk from when I was playing with going
straight to irq_domain_add_linear(). For this specific patch, I'll
put the alloc back in and test it that way. A follow-on patch can do
a proper conversion to the linear revmap.
> linear is for SPARSE_IRQ. The default behavior on ARM for SPARSE_IRQ is
> all nr_irqs are allocated at boot time before any controller is
> initialized. The only platform with a GIC and requiring SPARSE_IRQ is
> shmobile, but it is also the only one that calls irq_alloc_desc
> functions for it's interrupts. So I think we are okay there. The problem
> occurs when enabling SPARSE_IRQ for a non-DT platform with a GIC and
> with irqchips that don't call irq_alloc_desc for their irqs. IMHO, this
> should be an okay trade-off. There's no advantage to enabling SPARSE_IRQ
> on ARM for platforms that don't require it. All the platforms with a GIC
> have active work to convert to DT (except shmobile which I think is
> okay), so it's a temporary issue.
Actually, I believe Thomas' long term goal is to always enable
SPARSE_IRQ and remove the option entirely, so it should still be
properly resolved. I'll take a look next week if I don't get to it
tomorrow. I need to resurrect my vexpress qemu test environment so I
can test the permutations.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC 12/14] irq_domain: Add support for base irq and hwirq in legacy mappings
From: Rob Herring @ 2012-01-13 0:37 UTC (permalink / raw)
To: Grant Likely
Cc: sfr, Russell King, linux-kernel, Thomas Gleixner, linuxppc-dev
In-Reply-To: <1326313337-24603-13-git-send-email-grant.likely@secretlab.ca>
On 01/11/2012 02:22 PM, Grant Likely wrote:
> Add support for a legacy mapping where irq = (hwirq - first_hwirq + first_irq)
> so that a controller driver can allocate a fixed range of irq_descs and use
> a simple calculation to translate back and forth between linux and hw irq
> numbers. This is needed to use an irq_domain with many of the ARM interrupt
> controller drivers that manage their own irq_desc allocations. Ultimately
> the goal is to migrate those drivers to use the linear revmap, but doing it
> this way allows each driver to be converted separately which makes the
> migration path easier.
>
> This patch generalizes the IRQ_DOMAIN_MAP_LEGACY method to use
> (first_irq-first_hwirq) as the offset between hwirq and linux irq number,
> and adds checks to make sure that the hwirq number does not exceed range
> assigned to the controller.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> arch/powerpc/include/asm/irq.h | 3 -
> arch/powerpc/sysdev/i8259.c | 2 +-
> arch/powerpc/sysdev/tsi108_pci.c | 2 +-
> include/linux/irqdomain.h | 20 +++++++++-
> kernel/irq/irqdomain.c | 78 +++++++++++++++++++++++++-------------
> 5 files changed, 73 insertions(+), 32 deletions(-)
>
snip...
> @@ -454,8 +477,11 @@ unsigned int irq_find_mapping(struct irq_domain *domain,
> return 0;
>
> /* legacy -> bail early */
> - if (domain->revmap_type == IRQ_DOMAIN_MAP_LEGACY)
> - return hwirq;
> + if (domain->revmap_type == IRQ_DOMAIN_MAP_LEGACY) {
> + if (hwirq > domain->revmap_data.legacy.size)
> + return 0;
> + return domain->revmap_data.legacy.first_irq + hwirq;
This needs a "- domain->revmap_data.legacy.first_hwirq"
Rob
> + }
>
> /* Slow path does a linear search of the map */
> if (hint < NUM_ISA_INTERRUPTS)
^ permalink raw reply
* Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one
From: Rob Herring @ 2012-01-13 0:31 UTC (permalink / raw)
To: Grant Likely
Cc: sfr, Russell King, linux-kernel, Thomas Gleixner, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CACxGe6vVSO0cTgPurr6jFoo9QF_W02UaABOFYadCTQGU9dcwmg@mail.gmail.com>
Adding lakml...
On 01/11/2012 03:27 PM, Grant Likely wrote:
> On Wed, Jan 11, 2012 at 2:15 PM, Rob Herring <robherring2@gmail.com> wrote:
>> Grant,
>>
>> On 01/11/2012 02:22 PM, Grant Likely wrote:
>>> This patch removes the simplistic implementation of irq_domains and enables
>>> the powerpc infrastructure for all irq_domain users. The powerpc
>>> infrastructure includes support for complex mappings between Linux and
>>> hardware irq numbers, and can manage allocation of irq_descs.
>>>
>>> This patch also converts the few users of irq_domain_add()/irq_domain_del()
>>> to call irq_domain_add_legacy() instead.
>>
>> So what is the non-legacy way? Legacy implies we don't want to do it
>> that way. I guess until we remove all non-DT platforms with GIC we are
>> stuck with legacy. That seems like it could be a ways out until we get
>> there.
>
> Non-legacy is letting the irq_domain manage the irq_desc allocations.
> Some of the controllers will be easy to convert, some will be more
> difficult. The primary thing that really blocks getting away from the
> legacy method is anything that expects hardcoded #defined irq numbers.
> The goal is to convert all users over to the linear revmap method.
>
So I gave this a spin on highbank. I ran into a couple problems.
I had to revert "irqdesc: Consolidate irq reservation logic" which is in
your branch, but not this series. irq_alloc_desc_from was returning -EEXIST.
The GIC code did not work which I think is specific to using gic_of_init
which makes irq_start = -1. With that it still doesn't work. It dies in
gic_set_type... I've found one problem which I'll reply inline to, but I
think this is a dead end path anyway.
You have removed the irq_alloc_descs call from the GIC which is a step
backwards. Several of the ARM DT enabled platforms are at the point they
can fully support dynamic virq base for each irqchip. I changed the
domain from legacy to linear and got things working. The issue with
linear is for SPARSE_IRQ. The default behavior on ARM for SPARSE_IRQ is
all nr_irqs are allocated at boot time before any controller is
initialized. The only platform with a GIC and requiring SPARSE_IRQ is
shmobile, but it is also the only one that calls irq_alloc_desc
functions for it's interrupts. So I think we are okay there. The problem
occurs when enabling SPARSE_IRQ for a non-DT platform with a GIC and
with irqchips that don't call irq_alloc_desc for their irqs. IMHO, this
should be an okay trade-off. There's no advantage to enabling SPARSE_IRQ
on ARM for platforms that don't require it. All the platforms with a GIC
have active work to convert to DT (except shmobile which I think is
okay), so it's a temporary issue.
Rob
^ permalink raw reply
* Re: [RFC PATCH 14/16] KVM: PPC: booke: category E.HV (GS-mode) support
From: Scott Wood @ 2012-01-12 16:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: kvm-ppc, linuxppc-dev, Alexander Graf, kvm
In-Reply-To: <1326350666.23910.209.camel@pasglop>
On Thu, Jan 12, 2012 at 05:44:26PM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2012-01-10 at 04:11 +0100, Alexander Graf wrote:
> > This is what book3s does:
> >
> > case EMULATE_FAIL:
> > printk(KERN_CRIT "%s: emulation at %lx failed
> > (%08x)\n",
> > __func__, kvmppc_get_pc(vcpu),
> > kvmppc_get_last_inst(vcpu));
> > kvmppc_core_queue_program(vcpu, flags);
> > r = RESUME_GUEST;
> >
> > which also doesn't throttle the printk, but I think injecting a
> > program fault into the guest is the most sensible thing to do if we
> > don't know what the instruction is supposed to do. Best case we get an
> > oops inside the guest telling us what broke :).
>
> You can also fallback to a slow path that reads the guest TLB,
> translates then reads the instruction. Of course you have to be careful
> as such a manual translate + read + execute needs to be somewhat
> synchronized with a possible TLB invalidation :-)
That's how we should deal with a failure to read the instruction due to
it being execute-only (once we add the ability to fix up a fault on a
booke KVM instruction fetch) -- but the above code is dealing with the
case where we read the instruction successfully, but don't have an
emulation handler for it.
-Scott
^ permalink raw reply
* spi device from handle
From: Michael Remski @ 2012-01-12 16:02 UTC (permalink / raw)
To: linuxppc-dev
kernel 2.6.33
relevant section of dts has:
spi@7000 {
fpga0: fpga@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl, espi-fpga";
reg = <0>;
linux,modalias = "spidev";
spi-max-frequency = <1572864>;
};
}
I have another device driver that needs to talk to this fpga device, but
for the life of me I can't figure out the appropriate hooks to get there.
The device can be talked to from userland via /dev/spixyx.k, but how do I
get to the device from another driver?
Any little hints would be appreciated. Upgrading kernel is not an option
(sorry).
thanks
mike
^ permalink raw reply
* Re: [PATCH] KVM: Move gfn_to_memslot() to kvm_host.h
From: Avi Kivity @ 2012-01-12 15:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Alexander Graf, kvm-ppc, kvm
In-Reply-To: <20120112104115.GA32021@bloggs.ozlabs.ibm.com>
On 01/12/2012 12:41 PM, Paul Mackerras wrote:
> This moves __gfn_to_memslot() and search_memslots() from kvm_main.c to
> kvm_host.h to reduce the code duplication caused by the need for
> non-modular code in arch/powerpc/kvm/book3s_hv_rm_mmu.c to call
> gfn_to_memslot() in real mode.
>
> Rather than putting gfn_to_memslot() itself in a header, which would
> lead to increased code size, this puts __gfn_to_memslot() in a header.
> Then, the non-modular uses of gfn_to_memslot() are changed to call
> __gfn_to_memslot() instead. This way there is only one place in the
> source code that needs to be changed should the gfn_to_memslot()
> implementation need to be modified.
>
> On powerpc, the Book3S HV style of KVM has code that is called from
> real mode which needs to call gfn_to_memslot() and thus needs this.
> (Module code is allocated in the vmalloc region, which can't be
> accessed in real mode.)
>
>
> +static inline struct kvm_memory_slot *
> +search_memslots(struct kvm_memslots *slots, gfn_t gfn)
> +{
> + struct kvm_memory_slot *memslot;
> +
> + kvm_for_each_memslot(memslot, slots)
> + if (gfn >= memslot->base_gfn &&
> + gfn < memslot->base_gfn + memslot->npages)
> + return memslot;
> +
> + return NULL;
> +}
> +
> +static inline struct kvm_memory_slot *
> +__gfn_to_memslot(struct kvm_memslots *slots, gfn_t gfn)
> +{
> + return search_memslots(slots, gfn);
> +}
Please add a comment here explaining why these functions are inlined.
There's also the call to kvm_gfn_to_hva_cache_init(), which should be
changed to gfn_to_memslot(), to avoid code bloat.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] KVM: Move gfn_to_memslot() to kvm_host.h
From: Alexander Graf @ 2012-01-12 14:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, kvm, kvm-ppc, Avi Kivity
In-Reply-To: <20120112104115.GA32021@bloggs.ozlabs.ibm.com>
On 01/12/2012 11:41 AM, Paul Mackerras wrote:
> This moves __gfn_to_memslot() and search_memslots() from kvm_main.c to
> kvm_host.h to reduce the code duplication caused by the need for
> non-modular code in arch/powerpc/kvm/book3s_hv_rm_mmu.c to call
> gfn_to_memslot() in real mode.
>
> Rather than putting gfn_to_memslot() itself in a header, which would
> lead to increased code size, this puts __gfn_to_memslot() in a header.
> Then, the non-modular uses of gfn_to_memslot() are changed to call
> __gfn_to_memslot() instead. This way there is only one place in the
> source code that needs to be changed should the gfn_to_memslot()
> implementation need to be modified.
>
> On powerpc, the Book3S HV style of KVM has code that is called from
> real mode which needs to call gfn_to_memslot() and thus needs this.
> (Module code is allocated in the vmalloc region, which can't be
> accessed in real mode.)
>
> With this, we can remove builtin_gfn_to_memslot() from book3s_hv_rm_mmu.c.
>
> Signed-off-by: Paul Mackerras<paulus@samba.org>
Confusing to review, but looks correct :). Avi, please ack.
Alex
^ permalink raw reply
* Re: cpuidle: Default y for pseries
From: Deepthi Dharwar @ 2012-01-12 13:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-pm, Shaohua Li, Thadeu Lima de Souza Cascardo,
Venkatesh Pallipadi
In-Reply-To: <1326323168.23910.168.camel@pasglop>
On 01/12/2012 04:36 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2012-01-11 at 20:37 -0200, Thadeu Lima de Souza Cascardo wrote:
>> On Tue, Jan 10, 2012 at 03:05:35PM -0000, Benjamin Herrenschmidt wrote:
>>> We just replaced the pseries platform idle loops with a cpuidle backend,
>>> however that means that you won't get any power saving and won't return
>>> any unused idle time to the hypervisor unless cpuidle is enabled.
>>>
>>> Thus is should default to y when pseries is enabled. I prefer that to
>>> a select so we can still make it modular if we want to.
>>>
>>> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>>
>>> ---
>>> Linus, do you want to just pick that up or should I put it into powerpc.git
>>> and ask you to pull ? I will have 2 or 3 other fixes there later today,
>>> but I wanted to make sure you were ok with the approach with this
>>> specific one.
>>
>> Hi, Ben.
>>
>> Note that building with CONFIG_PSERIES_IDLE=m fails.
>
> Ah ok. Well, making it built-in only makes sense anyway as I said
> separately, so I think I'll just select it.
>
> Cheers,
> Ben.
>
>> CC [M] arch/powerpc/platforms/pseries/processor_idle.o
>> arch/powerpc/platforms/pseries/processor_idle.c:35: error: redefinition
>> of ‘update_smt_snooze_delay’
>> /root/linux/arch/powerpc/include/asm/system.h:230: note: previous
>> definition of ‘update_smt_snooze_delay’ was here
>> arch/powerpc/platforms/pseries/processor_idle.c:175: error: redefinition
>> of ‘pseries_notify_cpuidle_add_cpu’
>> /root/linux/arch/powerpc/include/asm/system.h:231: note: previous
>> definition of ‘pseries_notify_cpuidle_add_cpu’ was here
>> make[2]: *** [arch/powerpc/platforms/pseries/processor_idle.o] Error 1
>> make[1]: *** [arch/powerpc/platforms/pseries] Error 2
>> make: *** [arch/powerpc/platforms] Error 2
>>
>> asm/system.h has empty inline implementations for
>> update_smt_snooze_delay and pseries_notify_cpuidle_add_cpu, which are
>> used when CONFIG_PSERIES_IDLE is undefined. Since those two functions
>> are used in core power architecture functions (store_smt_snooze_delay
>> at kernel/sysfs.c and smp_xics_setup_cpu at platforms/pseries/smp.c),
>> this requires some rework in these interactions or we should simply
>> disable PSERIES_IDLE to be built as a module for now.
>>
>> Regards.
>> Cascardo.
>>
>>>
>>> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
>>> index 7dbc4a8..62ca70d 100644
>>> --- a/drivers/cpuidle/Kconfig
>>> +++ b/drivers/cpuidle/Kconfig
>>> @@ -1,7 +1,8 @@
>>>
>>> config CPU_IDLE
>>> bool "CPU idle PM support"
>>> - default ACPI
>>> + default y if ACPI
>>> + default y if PPC_PSERIES
>>> help
>>> CPU idle is a generic framework for supporting software-controlled
>>> idle processor power management. It includes modular cross-platform
The following patch disables pseries cpuidle driver to be loaded as a
module as there are build problems reported when one is trying to do so.
This is a work around for now until the problem is fixed.
arch/powerpc/platforms/pseries/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/Kconfig
b/arch/powerpc/platforms/pseries/Kconfig
index ae7b6d4..31f22c1 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -122,7 +122,7 @@ config DTL
Say N if you are unsure.
config PSERIES_IDLE
- tristate "Cpuidle driver for pSeries platforms"
+ bool "Cpuidle driver for pSeries platforms"
depends on CPU_IDLE
depends on PPC_PSERIES
default y
As pointed out, asm/system.h has empty inline implementations for
update_smt_snooze_delay and pseries_notify_cpuidle_add_cpu, which are
used when CONFIG_PSERIES_IDLE is undefined. Since those two functions
are used in core power architecture functions (store_smt_snooze_delay
at kernel/sysfs.c and smp_xics_setup_cpu at platforms/pseries/smp.c),
Going forward, the aim is to remove the dependency of using these
functions from core power architecture functions. So I am proposing the
following changes:
a) Removing update_smt_snooze_delay () and allow the pseries
idle backend driver to query snooze entry on need basis
while initializing the driver fields by exporting an api to return
snooze value for a given cpu.
b) Replacing the pseries_notify_cpuidle_add_cpu() call
by registering a cpu_notifier to take actions accordingly.
Regards,
Deepthi
^ permalink raw reply related
* [PATCH] KVM: Move gfn_to_memslot() to kvm_host.h
From: Paul Mackerras @ 2012-01-12 10:41 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <20111220092102.GA5626@bloggs.ozlabs.ibm.com>
This moves __gfn_to_memslot() and search_memslots() from kvm_main.c to
kvm_host.h to reduce the code duplication caused by the need for
non-modular code in arch/powerpc/kvm/book3s_hv_rm_mmu.c to call
gfn_to_memslot() in real mode.
Rather than putting gfn_to_memslot() itself in a header, which would
lead to increased code size, this puts __gfn_to_memslot() in a header.
Then, the non-modular uses of gfn_to_memslot() are changed to call
__gfn_to_memslot() instead. This way there is only one place in the
source code that needs to be changed should the gfn_to_memslot()
implementation need to be modified.
On powerpc, the Book3S HV style of KVM has code that is called from
real mode which needs to call gfn_to_memslot() and thus needs this.
(Module code is allocated in the vmalloc region, which can't be
accessed in real mode.)
With this, we can remove builtin_gfn_to_memslot() from book3s_hv_rm_mmu.c.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 23 ++---------------------
include/linux/kvm_host.h | 19 +++++++++++++++++++
virt/kvm/kvm_main.c | 19 -------------------
3 files changed, 21 insertions(+), 40 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index d3e36fc..9055cd2 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -21,25 +21,6 @@
#include <asm/synch.h>
#include <asm/ppc-opcode.h>
-/*
- * Since this file is built in even if KVM is a module, we need
- * a local copy of this function for the case where kvm_main.c is
- * modular.
- */
-static struct kvm_memory_slot *builtin_gfn_to_memslot(struct kvm *kvm,
- gfn_t gfn)
-{
- struct kvm_memslots *slots;
- struct kvm_memory_slot *memslot;
-
- slots = kvm_memslots(kvm);
- kvm_for_each_memslot(memslot, slots)
- if (gfn >= memslot->base_gfn &&
- gfn < memslot->base_gfn + memslot->npages)
- return memslot;
- return NULL;
-}
-
/* Translate address of a vmalloc'd thing to a linear map address */
static void *real_vmalloc_addr(void *x)
{
@@ -97,7 +78,7 @@ static void remove_revmap_chain(struct kvm *kvm, long pte_index,
rev = real_vmalloc_addr(&kvm->arch.revmap[pte_index]);
ptel = rev->guest_rpte;
gfn = hpte_rpn(ptel, hpte_page_size(hpte_v, ptel));
- memslot = builtin_gfn_to_memslot(kvm, gfn);
+ memslot = __gfn_to_memslot(kvm_memslots(kvm), gfn);
if (!memslot || (memslot->flags & KVM_MEMSLOT_INVALID))
return;
@@ -171,7 +152,7 @@ long kvmppc_h_enter(struct kvm_vcpu *vcpu, unsigned long flags,
/* Find the memslot (if any) for this address */
gpa = (ptel & HPTE_R_RPN) & ~(psize - 1);
gfn = gpa >> PAGE_SHIFT;
- memslot = builtin_gfn_to_memslot(kvm, gfn);
+ memslot = __gfn_to_memslot(kvm_memslots(kvm), gfn);
pa = 0;
is_io = ~0ul;
rmap = NULL;
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index ec79a45..86d08f0 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -649,6 +649,25 @@ static inline void kvm_guest_exit(void)
current->flags &= ~PF_VCPU;
}
+static inline struct kvm_memory_slot *
+search_memslots(struct kvm_memslots *slots, gfn_t gfn)
+{
+ struct kvm_memory_slot *memslot;
+
+ kvm_for_each_memslot(memslot, slots)
+ if (gfn >= memslot->base_gfn &&
+ gfn < memslot->base_gfn + memslot->npages)
+ return memslot;
+
+ return NULL;
+}
+
+static inline struct kvm_memory_slot *
+__gfn_to_memslot(struct kvm_memslots *slots, gfn_t gfn)
+{
+ return search_memslots(slots, gfn);
+}
+
static inline int memslot_id(struct kvm *kvm, gfn_t gfn)
{
return gfn_to_memslot(kvm, gfn)->id;
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index c144132..5de8f61 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -640,19 +640,6 @@ static int kvm_create_dirty_bitmap(struct kvm_memory_slot *memslot)
}
#endif /* !CONFIG_S390 */
-static struct kvm_memory_slot *
-search_memslots(struct kvm_memslots *slots, gfn_t gfn)
-{
- struct kvm_memory_slot *memslot;
-
- kvm_for_each_memslot(memslot, slots)
- if (gfn >= memslot->base_gfn &&
- gfn < memslot->base_gfn + memslot->npages)
- return memslot;
-
- return NULL;
-}
-
static int cmp_memslot(const void *slot1, const void *slot2)
{
struct kvm_memory_slot *s1, *s2;
@@ -1031,12 +1018,6 @@ int kvm_is_error_hva(unsigned long addr)
}
EXPORT_SYMBOL_GPL(kvm_is_error_hva);
-static struct kvm_memory_slot *__gfn_to_memslot(struct kvm_memslots *slots,
- gfn_t gfn)
-{
- return search_memslots(slots, gfn);
-}
-
struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm, gfn_t gfn)
{
return __gfn_to_memslot(kvm_memslots(kvm), gfn);
--
1.7.8.3
^ permalink raw reply related
* [PATCH] powerpc/dts: update dts for p1020rdb
From: Zhicheng Fan @ 2012-01-12 10:04 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: Zhicheng Fan
nand: Sync base address with U-boot
sdhc: Add suppot auto cmd12
Signed-off-by: Zhicheng Fan <B32736@freescale.com>
---
arch/powerpc/boot/dts/fsl/p1020si-post.dtsi | 3 +++
arch/powerpc/boot/dts/p1020rdb.dts | 2 +-
arch/powerpc/boot/dts/p1020rdb_36b.dts | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
index fc924c5..8e56ad2 100644
--- a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
@@ -145,6 +145,9 @@
/include/ "pq3-usb2-dr-1.dtsi"
/include/ "pq3-esdhc-0.dtsi"
+ sdhc@2e000 {
+ sdhci,auto-cmd12;
+ };
/include/ "pq3-sec3.3-0.dtsi"
/include/ "pq3-mpic.dtsi"
diff --git a/arch/powerpc/boot/dts/p1020rdb.dts b/arch/powerpc/boot/dts/p1020rdb.dts
index 518bf99..19b8c77 100644
--- a/arch/powerpc/boot/dts/p1020rdb.dts
+++ b/arch/powerpc/boot/dts/p1020rdb.dts
@@ -23,7 +23,7 @@
/* NOR, NAND Flashes and Vitesse 5 port L2 switch */
ranges = <0x0 0x0 0x0 0xef000000 0x01000000
- 0x1 0x0 0x0 0xffa00000 0x00040000
+ 0x1 0x0 0x0 0xff800000 0x00040000
0x2 0x0 0x0 0xffb00000 0x00020000>;
};
diff --git a/arch/powerpc/boot/dts/p1020rdb_36b.dts b/arch/powerpc/boot/dts/p1020rdb_36b.dts
index bdbdb60..7c53ad7 100644
--- a/arch/powerpc/boot/dts/p1020rdb_36b.dts
+++ b/arch/powerpc/boot/dts/p1020rdb_36b.dts
@@ -23,7 +23,7 @@
/* NOR, NAND Flashes and Vitesse 5 port L2 switch */
ranges = <0x0 0x0 0xf 0xef000000 0x01000000
- 0x1 0x0 0xf 0xffa00000 0x00040000
+ 0x1 0x0 0xf 0xff800000 0x00040000
0x2 0x0 0xf 0xffb00000 0x00020000>;
};
--
1.6.4
^ permalink raw reply related
* Re: [SDK v1.2][PATCH] powerpc/dts: update dts for p1020rdb
From: fanzc @ 2012-01-12 10:02 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
In-Reply-To: <1326362459-9654-1-git-send-email-B32736@freescale.com>
hi all
please ignore this email
On Thu, 2012-01-12 at 18:00 +0800, Zhicheng Fan wrote:
> nand: Sync base address with U-boot
> sdhc: Add suppot auto cmd12
>
> Signed-off-by: Zhicheng Fan <B32736@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/p1020si-post.dtsi | 3 +++
> arch/powerpc/boot/dts/p1020rdb.dts | 2 +-
> arch/powerpc/boot/dts/p1020rdb_36b.dts | 2 +-
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
> index fc924c5..8e56ad2 100644
> --- a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
> @@ -145,6 +145,9 @@
> /include/ "pq3-usb2-dr-1.dtsi"
>
> /include/ "pq3-esdhc-0.dtsi"
> + sdhc@2e000 {
> + sdhci,auto-cmd12;
> + };
> /include/ "pq3-sec3.3-0.dtsi"
>
> /include/ "pq3-mpic.dtsi"
> diff --git a/arch/powerpc/boot/dts/p1020rdb.dts b/arch/powerpc/boot/dts/p1020rdb.dts
> index 518bf99..19b8c77 100644
> --- a/arch/powerpc/boot/dts/p1020rdb.dts
> +++ b/arch/powerpc/boot/dts/p1020rdb.dts
> @@ -23,7 +23,7 @@
>
> /* NOR, NAND Flashes and Vitesse 5 port L2 switch */
> ranges = <0x0 0x0 0x0 0xef000000 0x01000000
> - 0x1 0x0 0x0 0xffa00000 0x00040000
> + 0x1 0x0 0x0 0xff800000 0x00040000
> 0x2 0x0 0x0 0xffb00000 0x00020000>;
> };
>
> diff --git a/arch/powerpc/boot/dts/p1020rdb_36b.dts b/arch/powerpc/boot/dts/p1020rdb_36b.dts
> index bdbdb60..7c53ad7 100644
> --- a/arch/powerpc/boot/dts/p1020rdb_36b.dts
> +++ b/arch/powerpc/boot/dts/p1020rdb_36b.dts
> @@ -23,7 +23,7 @@
>
> /* NOR, NAND Flashes and Vitesse 5 port L2 switch */
> ranges = <0x0 0x0 0xf 0xef000000 0x01000000
> - 0x1 0x0 0xf 0xffa00000 0x00040000
> + 0x1 0x0 0xf 0xff800000 0x00040000
> 0x2 0x0 0xf 0xffb00000 0x00020000>;
> };
>
^ permalink raw reply
* [SDK v1.2][PATCH] powerpc/dts: update dts for p1020rdb
From: Zhicheng Fan @ 2012-01-12 10:00 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: Zhicheng Fan
nand: Sync base address with U-boot
sdhc: Add suppot auto cmd12
Signed-off-by: Zhicheng Fan <B32736@freescale.com>
---
arch/powerpc/boot/dts/fsl/p1020si-post.dtsi | 3 +++
arch/powerpc/boot/dts/p1020rdb.dts | 2 +-
arch/powerpc/boot/dts/p1020rdb_36b.dts | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
index fc924c5..8e56ad2 100644
--- a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
@@ -145,6 +145,9 @@
/include/ "pq3-usb2-dr-1.dtsi"
/include/ "pq3-esdhc-0.dtsi"
+ sdhc@2e000 {
+ sdhci,auto-cmd12;
+ };
/include/ "pq3-sec3.3-0.dtsi"
/include/ "pq3-mpic.dtsi"
diff --git a/arch/powerpc/boot/dts/p1020rdb.dts b/arch/powerpc/boot/dts/p1020rdb.dts
index 518bf99..19b8c77 100644
--- a/arch/powerpc/boot/dts/p1020rdb.dts
+++ b/arch/powerpc/boot/dts/p1020rdb.dts
@@ -23,7 +23,7 @@
/* NOR, NAND Flashes and Vitesse 5 port L2 switch */
ranges = <0x0 0x0 0x0 0xef000000 0x01000000
- 0x1 0x0 0x0 0xffa00000 0x00040000
+ 0x1 0x0 0x0 0xff800000 0x00040000
0x2 0x0 0x0 0xffb00000 0x00020000>;
};
diff --git a/arch/powerpc/boot/dts/p1020rdb_36b.dts b/arch/powerpc/boot/dts/p1020rdb_36b.dts
index bdbdb60..7c53ad7 100644
--- a/arch/powerpc/boot/dts/p1020rdb_36b.dts
+++ b/arch/powerpc/boot/dts/p1020rdb_36b.dts
@@ -23,7 +23,7 @@
/* NOR, NAND Flashes and Vitesse 5 port L2 switch */
ranges = <0x0 0x0 0xf 0xef000000 0x01000000
- 0x1 0x0 0xf 0xffa00000 0x00040000
+ 0x1 0x0 0xf 0xff800000 0x00040000
0x2 0x0 0xf 0xffb00000 0x00020000>;
};
--
1.6.4
^ permalink raw reply related
* [PATCH 12/15] arch/powerpc/sysdev/fsl_pci.c: add missing iounmap
From: Julia Lawall @ 2012-01-12 9:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: devicetree-discuss, kernel-janitors, linux-kernel, Rob Herring,
Paul Mackerras, linuxppc-dev
From: Julia Lawall <Julia.Lawall@lip6.fr>
Add missing iounmap in error handling code, in a case where the function
already preforms iounmap on some other execution path.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e;
statement S,S1;
int ret;
@@
e = \(ioremap\|ioremap_nocache\)(...)
... when != iounmap(e)
if (<+...e...+>) S
... when any
when != iounmap(e)
*if (...)
{ ... when != iounmap(e)
return ...; }
... when any
iounmap(e);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
arch/powerpc/sysdev/fsl_pci.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4ce547e..bb025da 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -179,12 +179,12 @@ static void __init setup_pci_atmu(struct pci_controller *hose,
if (paddr_hi == paddr_lo) {
pr_err("%s: No outbound window space\n", name);
- return ;
+ goto out;
}
if (paddr_lo == 0) {
pr_err("%s: No space for inbound window\n", name);
- return ;
+ goto out;
}
/* setup PCSRBAR/PEXCSRBAR */
@@ -273,6 +273,7 @@ static void __init setup_pci_atmu(struct pci_controller *hose,
(u64)hose->dma_window_size);
}
+out:
iounmap(pci);
}
^ permalink raw reply related
* Re: Problem in getting shared memory access on P1022RDK
From: tiejun.chen @ 2012-01-12 8:09 UTC (permalink / raw)
To: Arshad, Farrukh; +Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <93CD5F41FDBC6042A6B449764F3B35CC050CD375@EU-MBX-03.mgc.mentorg.com>
Arshad, Farrukh wrote:
> Adding more it,
>
> I have removed the shared memory kernel driver dependency just to narrow down the problem area and I have written a small piece of code in user space. A writer & a reader application which access the shared memory and I got the same behavior as with the shared memory kernel driver. Interestingly, my user space application work fine on P1022DS but not on P1022RDK however both using the same CPU modules.
>
> When I write a simple string on shared memory from Core 1 it is read at Core 0 properly
> When I write a simple string on shared memory from Core 0 it is not read at Core 1.
>
Did you dump TLB entry to check page memory coherence attribute for a shared
memory as I mentioned previously? This should be consistent on both sides.
> With this test now I am sure the problem lies in the kernel itself. Any pointers to look for the troubled area ?
>
> My application code is (error checking and other code is omitted)
>
> #define SHM_BASE 0x1C000000
> #define SHM_SIZE 0x400000 // 4 MB of Shared Memory
> #define PAGE_SIZE (4*1024)
>
> fd = open(device, O_RDWR);
You may need to add with 'O_SYNC'.
Tiejun
>
> shm = malloc(SHM_SIZE + (PAGE_SIZE - 1));
> if ( (unsigned long) shm % PAGE_SIZE) {
> shm += PAGE_SIZE - ((unsigned long)shm % PAGE_SIZE);
> }
>
> shm = mmap(shm, SHM_SIZE, PROT_READ|PROT_WRITE, MAP_SHARED | MAP_FIXED, fd, SHM_BASE);
> ......
> ...... write some string at shm.
>
> My memory partitioning for both systems is
>
> Core Base Address Size
> Core 0 0x0000,0000 0x1000,0000
> Core 1 0x1000,0000 0x0C00,0000
> Shared Memory 0x1C00,0000 0x0400,0000
>
> Regards,
> Farrukh Arshad.
> Mentor Graphics Pakistan
^ permalink raw reply
* Re: [RFC PATCH 14/16] KVM: PPC: booke: category E.HV (GS-mode) support
From: Alexander Graf @ 2012-01-12 7:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <1326350666.23910.209.camel@pasglop>
On 12.01.2012, at 07:44, Benjamin Herrenschmidt <benh@kernel.crashing.org> w=
rote:
> On Tue, 2012-01-10 at 04:11 +0100, Alexander Graf wrote:
>> This is what book3s does:
>>=20
>> case EMULATE_FAIL:
>> printk(KERN_CRIT "%s: emulation at %lx failed
>> (%08x)\n",
>> __func__, kvmppc_get_pc(vcpu),
>> kvmppc_get_last_inst(vcpu));
>> kvmppc_core_queue_program(vcpu, flags);
>> r =3D RESUME_GUEST;
>>=20
>> which also doesn't throttle the printk, but I think injecting a
>> program fault into the guest is the most sensible thing to do if we
>> don't know what the instruction is supposed to do. Best case we get an
>> oops inside the guest telling us what broke :).
>=20
> You can also fallback to a slow path that reads the guest TLB,
> translates then reads the instruction. Of course you have to be careful
> as such a manual translate + read + execute needs to be somewhat
> synchronized with a possible TLB invalidation :-)
Well we do want to be fast on the default path though. So yes, what you're s=
aying is what book3s does, but as a fallback in case the fast path didn't wo=
rk.
The problem here however is that we don't know if the fast path failed; we o=
ops.
>=20
> (MMIO emulation is broken in this regard too btw)
Huh?
Alex
>=20
> Cheers,
> Ben.
>=20
>=20
^ permalink raw reply
* Re: [RFC PATCH 14/16] KVM: PPC: booke: category E.HV (GS-mode) support
From: Benjamin Herrenschmidt @ 2012-01-12 6:44 UTC (permalink / raw)
To: Alexander Graf; +Cc: Scott Wood, linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <A1483A2E-FF86-4E25-93CC-9EA1BA4925D4@suse.de>
On Tue, 2012-01-10 at 04:11 +0100, Alexander Graf wrote:
> This is what book3s does:
>
> case EMULATE_FAIL:
> printk(KERN_CRIT "%s: emulation at %lx failed
> (%08x)\n",
> __func__, kvmppc_get_pc(vcpu),
> kvmppc_get_last_inst(vcpu));
> kvmppc_core_queue_program(vcpu, flags);
> r = RESUME_GUEST;
>
> which also doesn't throttle the printk, but I think injecting a
> program fault into the guest is the most sensible thing to do if we
> don't know what the instruction is supposed to do. Best case we get an
> oops inside the guest telling us what broke :).
You can also fallback to a slow path that reads the guest TLB,
translates then reads the instruction. Of course you have to be careful
as such a manual translate + read + execute needs to be somewhat
synchronized with a possible TLB invalidation :-)
(MMIO emulation is broken in this regard too btw)
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC PATCH 04/16] KVM: PPC: factor out lpid allocator from book3s_64_mmu_hv
From: Paul Mackerras @ 2012-01-12 4:16 UTC (permalink / raw)
To: Alexander Graf; +Cc: Scott Wood, linuxppc-dev, kvm-ppc, KVM mailing list
In-Reply-To: <CE2DB77D-1D57-4D7A-92E6-08368733DE6F@suse.de>
On Mon, Jan 09, 2012 at 04:35:52PM +0100, Alexander Graf wrote:
> Paul, does this work for you? IIRC you need this code to be
> available from real mode, which powerpc.c isn't in, right?
We don't need to allocated LPIDs from real mode, so it should be OK.
book3s_64_mmu_hv.c is not real mode code, and it gets compiled into
the KVM module.
Paul.
^ permalink raw reply
* Re: cpuidle: Default y for pseries
From: Benjamin Herrenschmidt @ 2012-01-11 23:06 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: Venkatesh Pallipadi, linuxppc-dev, linux-pm, Linus Torvalds,
Shaohua Li
In-Reply-To: <20120111223744.GA30947@oc1711230544.ibm.com>
On Wed, 2012-01-11 at 20:37 -0200, Thadeu Lima de Souza Cascardo wrote:
> On Tue, Jan 10, 2012 at 03:05:35PM -0000, Benjamin Herrenschmidt wrote:
> > We just replaced the pseries platform idle loops with a cpuidle backend,
> > however that means that you won't get any power saving and won't return
> > any unused idle time to the hypervisor unless cpuidle is enabled.
> >
> > Thus is should default to y when pseries is enabled. I prefer that to
> > a select so we can still make it modular if we want to.
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> >
> > ---
> > Linus, do you want to just pick that up or should I put it into powerpc.git
> > and ask you to pull ? I will have 2 or 3 other fixes there later today,
> > but I wanted to make sure you were ok with the approach with this
> > specific one.
>
> Hi, Ben.
>
> Note that building with CONFIG_PSERIES_IDLE=m fails.
Ah ok. Well, making it built-in only makes sense anyway as I said
separately, so I think I'll just select it.
Cheers,
Ben.
> CC [M] arch/powerpc/platforms/pseries/processor_idle.o
> arch/powerpc/platforms/pseries/processor_idle.c:35: error: redefinition
> of ‘update_smt_snooze_delay’
> /root/linux/arch/powerpc/include/asm/system.h:230: note: previous
> definition of ‘update_smt_snooze_delay’ was here
> arch/powerpc/platforms/pseries/processor_idle.c:175: error: redefinition
> of ‘pseries_notify_cpuidle_add_cpu’
> /root/linux/arch/powerpc/include/asm/system.h:231: note: previous
> definition of ‘pseries_notify_cpuidle_add_cpu’ was here
> make[2]: *** [arch/powerpc/platforms/pseries/processor_idle.o] Error 1
> make[1]: *** [arch/powerpc/platforms/pseries] Error 2
> make: *** [arch/powerpc/platforms] Error 2
>
> asm/system.h has empty inline implementations for
> update_smt_snooze_delay and pseries_notify_cpuidle_add_cpu, which are
> used when CONFIG_PSERIES_IDLE is undefined. Since those two functions
> are used in core power architecture functions (store_smt_snooze_delay
> at kernel/sysfs.c and smp_xics_setup_cpu at platforms/pseries/smp.c),
> this requires some rework in these interactions or we should simply
> disable PSERIES_IDLE to be built as a module for now.
>
> Regards.
> Cascardo.
>
> >
> > diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
> > index 7dbc4a8..62ca70d 100644
> > --- a/drivers/cpuidle/Kconfig
> > +++ b/drivers/cpuidle/Kconfig
> > @@ -1,7 +1,8 @@
> >
> > config CPU_IDLE
> > bool "CPU idle PM support"
> > - default ACPI
> > + default y if ACPI
> > + default y if PPC_PSERIES
> > help
> > CPU idle is a generic framework for supporting software-controlled
> > idle processor power management. It includes modular cross-platform
^ permalink raw reply
* Re: cpuidle: Default y for pseries
From: Thadeu Lima de Souza Cascardo @ 2012-01-11 22:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Venkatesh Pallipadi, linuxppc-dev, linux-pm, Linus Torvalds,
Shaohua Li
In-Reply-To: <1326243935.23910.85.camel@pasglop>
On Tue, Jan 10, 2012 at 03:05:35PM -0000, Benjamin Herrenschmidt wrote:
> We just replaced the pseries platform idle loops with a cpuidle backend,
> however that means that you won't get any power saving and won't return
> any unused idle time to the hypervisor unless cpuidle is enabled.
>
> Thus is should default to y when pseries is enabled. I prefer that to
> a select so we can still make it modular if we want to.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> ---
> Linus, do you want to just pick that up or should I put it into powerpc.git
> and ask you to pull ? I will have 2 or 3 other fixes there later today,
> but I wanted to make sure you were ok with the approach with this
> specific one.
Hi, Ben.
Note that building with CONFIG_PSERIES_IDLE=m fails.
CC [M] arch/powerpc/platforms/pseries/processor_idle.o
arch/powerpc/platforms/pseries/processor_idle.c:35: error: redefinition
of ‘update_smt_snooze_delay’
/root/linux/arch/powerpc/include/asm/system.h:230: note: previous
definition of ‘update_smt_snooze_delay’ was here
arch/powerpc/platforms/pseries/processor_idle.c:175: error: redefinition
of ‘pseries_notify_cpuidle_add_cpu’
/root/linux/arch/powerpc/include/asm/system.h:231: note: previous
definition of ‘pseries_notify_cpuidle_add_cpu’ was here
make[2]: *** [arch/powerpc/platforms/pseries/processor_idle.o] Error 1
make[1]: *** [arch/powerpc/platforms/pseries] Error 2
make: *** [arch/powerpc/platforms] Error 2
asm/system.h has empty inline implementations for
update_smt_snooze_delay and pseries_notify_cpuidle_add_cpu, which are
used when CONFIG_PSERIES_IDLE is undefined. Since those two functions
are used in core power architecture functions (store_smt_snooze_delay
at kernel/sysfs.c and smp_xics_setup_cpu at platforms/pseries/smp.c),
this requires some rework in these interactions or we should simply
disable PSERIES_IDLE to be built as a module for now.
Regards.
Cascardo.
>
> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
> index 7dbc4a8..62ca70d 100644
> --- a/drivers/cpuidle/Kconfig
> +++ b/drivers/cpuidle/Kconfig
> @@ -1,7 +1,8 @@
>
> config CPU_IDLE
> bool "CPU idle PM support"
> - default ACPI
> + default y if ACPI
> + default y if PPC_PSERIES
> help
> CPU idle is a generic framework for supporting software-controlled
> idle processor power management. It includes modular cross-platform
^ permalink raw reply
* Re: [RFC 0/14] Finish up irq_domain generalization
From: Randy Dunlap @ 2012-01-11 22:48 UTC (permalink / raw)
To: Grant Likely
Cc: sfr, Russell King, linux-kernel, Rob Herring, Thomas Gleixner,
linuxppc-dev
In-Reply-To: <CACxGe6v0YcxsmidFhe=s3EiDrYDoYBZLyk1MZjyg8uXRFGSvoQ@mail.gmail.com>
On 01/11/2012 01:23 PM, Grant Likely wrote:
> On Wed, Jan 11, 2012 at 1:50 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Wed, Jan 11, 2012 at 2:39 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>>> On 01/11/2012 12:22 PM, Grant Likely wrote:
>>>> Here are the patches that I've been working on to finish up the creation
>>>> of the generic irq_domain infrastructure.
>>>
>>> Does this fix the linux-next build problems that I have reported?
>>>
>>> https://lkml.org/lkml/2012/1/9/318
>>
>> IIRC, that was solved and a fix merged. The problem was a driver
>> selecting CONFIG_IRQ_DOMAIN when it must not do so. I'm build testing
>> with that randconfig now to make sure.
>
> Yes, doing oldconfig on that sample no longer has CONFIG_IRQ_DOMAIN
> selected, so it looks okay.
Thanks. I never saw a patch for it.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [RFC 13/14] irq_domain: Remove 'new' irq_domain in favour of the ppc one
From: Grant Likely @ 2012-01-11 21:27 UTC (permalink / raw)
To: Rob Herring
Cc: sfr, Russell King, linux-kernel, Thomas Gleixner, linuxppc-dev
In-Reply-To: <4F0DFC0F.2090005@gmail.com>
On Wed, Jan 11, 2012 at 2:15 PM, Rob Herring <robherring2@gmail.com> wrote:
> Grant,
>
> On 01/11/2012 02:22 PM, Grant Likely wrote:
>> This patch removes the simplistic implementation of irq_domains and enab=
les
>> the powerpc infrastructure for all irq_domain users. =A0The powerpc
>> infrastructure includes support for complex mappings between Linux and
>> hardware irq numbers, and can manage allocation of irq_descs.
>>
>> This patch also converts the few users of irq_domain_add()/irq_domain_de=
l()
>> to call irq_domain_add_legacy() instead.
>
> So what is the non-legacy way? Legacy implies we don't want to do it
> that way. I guess until we remove all non-DT platforms with GIC we are
> stuck with legacy. That seems like it could be a ways out until we get
> there.
Non-legacy is letting the irq_domain manage the irq_desc allocations.
Some of the controllers will be easy to convert, some will be more
difficult. The primary thing that really blocks getting away from the
legacy method is anything that expects hardcoded #defined irq numbers.
The goal is to convert all users over to the linear revmap method.
g.
^ 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