* 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
* 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 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: 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 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 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: 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
* [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
* [PATCH v3] KVM: Move gfn_to_memslot() to kvm_host.h
From: Paul Mackerras @ 2012-01-13 6:09 UTC (permalink / raw)
To: Alexander Graf, Avi Kivity; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <20120112104115.GA32021@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>
---
v3: Add comment, change kvm_gfn_to_hva_cache_init as requested.
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 23 ++---------------------
include/linux/kvm_host.h | 25 +++++++++++++++++++++++++
virt/kvm/kvm_main.c | 21 +--------------------
3 files changed, 28 insertions(+), 41 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..688f37b 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -649,6 +649,31 @@ static inline void kvm_guest_exit(void)
current->flags &= ~PF_VCPU;
}
+/*
+ * search_memslots() and __gfn_to_memslot() are here because they are
+ * used in non-modular code in arch/powerpc/kvm/book3s_hv_rm_mmu.c.
+ * gfn_to_memslot() itself isn't here as an inline because that would
+ * bloat other code too much.
+ */
+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..8ae6b76 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);
@@ -1459,7 +1440,7 @@ int kvm_gfn_to_hva_cache_init(struct kvm *kvm, struct gfn_to_hva_cache *ghc,
ghc->gpa = gpa;
ghc->generation = slots->generation;
- ghc->memslot = __gfn_to_memslot(slots, gfn);
+ ghc->memslot = gfn_to_memslot(kvm, gfn);
ghc->hva = gfn_to_hva_many(ghc->memslot, gfn, NULL);
if (!kvm_is_error_hva(ghc->hva))
ghc->hva += offset;
--
1.7.5.4
^ permalink raw reply related
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2012-01-13 6:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Please pull this couple of important bug fixes (a commit
that went in breaks booting on some machines, this fixes
it properly).
Thanks !
Cheers,
Ben.
The following changes since commit 7b3480f8b701170c046e1ed362946f5f0d005e13:
Merge tag 'for-linus-3.3' of git://git.infradead.org/mtd-2.6 (2012-01-10 13:45:22 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Anton Blanchard (1):
powerpc: Fix RCU idle and hcall tracing
Li Zhong (1):
powerpc: Fix unpaired __trace_hcall_entry and __trace_hcall_exit
arch/powerpc/kernel/idle.c | 12 ++----------
arch/powerpc/platforms/pseries/hvCall.S | 3 ++-
arch/powerpc/platforms/pseries/lpar.c | 14 ++++++++++----
3 files changed, 14 insertions(+), 15 deletions(-)
^ permalink raw reply
* [PATCH][SDK v1.2] sata: I/O load balancing
From: Qiang Liu @ 2012-01-13 8:21 UTC (permalink / raw)
To: jgarzik, linux-ide, linux-kernel, linuxppc-dev; +Cc: Qiang Liu, Qiang Liu
From: Qiang Liu <b32616@freescale.com>
Reduce interrupt singnals through reset Interrupt Coalescing Control Reg.
Increase the threshold value of interrupt and timer will reduce the number
of complete interrupt sharply. Improve the system performance effectively.
Signed-off-by: Qiang Liu <qiang.liu@freescale.net>
---
Description:
1. sata-fsl interrupt will be raised 130 thousand times when write 8G file
(dd if=/dev/zero of=/dev/sda2 bs=128K count=65536);
2. most of interrupts raised because of only 1-4 commands completed;
3. only 30 thousand times will be raised after set max interrupt threshold,
more interrupts are coalesced as the description of ICC;
Performance Improvement:
use top command,
[root@p2020ds root]# dd if=/dev/zero of=/dev/sda2 bs=128K count=65536 &
[root@p2020ds root]# top
CPU % | dd | flush-8:0 | softirq
---------------------------------------
before | 20-22 | 17-19 | 7
---------------------------------------
after | 18-21 | 15-16 | 5
---------------------------------------
drivers/ata/sata_fsl.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 3547000..93f8b00 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -6,7 +6,7 @@
* Author: Ashish Kalra <ashish.kalra@freescale.com>
* Li Yang <leoli@freescale.com>
*
- * Copyright (c) 2006-2007, 2011 Freescale Semiconductor, Inc.
+ * Copyright (c) 2006-2007, 2011-2012 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -162,6 +162,16 @@ enum {
};
/*
+ * Interrupt Coalescing Control Register bitdefs
+ */
+enum {
+ ICC_MIN_INT_THRESHOLD_COUNT = (1 << 24),
+ ICC_MAX_INT_THRESHOLD_COUNT = (((1 << 4) - 1) << 24),
+ ICC_MIN_INT_THRESHOLD_TIMER = 1,
+ ICC_MAX_INT_THRESHOLD_TIMER = ((1 << 18) - 1),
+};
+
+/*
* SATA Superset Registers
*/
enum {
@@ -460,6 +470,13 @@ static unsigned int sata_fsl_qc_issue(struct ata_queued_cmd *qc)
/* Simply queue command to the controller/device */
iowrite32(1 << tag, CQ + hcr_base);
+ /*
+ * reset the number of command complete bits which will cause the
+ * interrupt to be signaled
+ */
+ iowrite32(ICC_MAX_INT_THRESHOLD_COUNT | ICC_MAX_INT_THRESHOLD_TIMER,
+ ICC + hcr_base);
+
VPRINTK("xx_qc_issue called, tag=%d, CQ=0x%x, CA=0x%x\n",
tag, ioread32(CQ + hcr_base), ioread32(CA + hcr_base));
--
1.6.4
^ permalink raw reply related
* [PATCH][SDK v1.2] sata: I/O load balancing
From: Qiang Liu @ 2012-01-13 8:25 UTC (permalink / raw)
To: jgarzik, linux-ide, linux-kernel, linuxppc-dev; +Cc: Qiang Liu, Qiang Liu
From: Qiang Liu <b32616@freescale.com>
Reduce interrupt singnals through reset Interrupt Coalescing Control Reg.
Increase the threshold value of interrupt and timer will reduce the number
of complete interrupt sharply. Improve the system performance effectively.
Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
---
Description:
1. sata-fsl interrupt will be raised 130 thousand times when write 8G file
(dd if=/dev/zero of=/dev/sda2 bs=128K count=65536);
2. most of interrupts raised because of only 1-4 commands completed;
3. only 30 thousand times will be raised after set max interrupt threshold,
more interrupts are coalesced as the description of ICC;
Performance Improvement:
use top command,
[root@p2020ds root]# dd if=/dev/zero of=/dev/sda2 bs=128K count=65536 &
[root@p2020ds root]# top
CPU % | dd | flush-8:0 | softirq
---------------------------------------
before | 20-22 | 17-19 | 7
---------------------------------------
after | 18-21 | 15-16 | 5
---------------------------------------
drivers/ata/sata_fsl.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 3547000..93f8b00 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -6,7 +6,7 @@
* Author: Ashish Kalra <ashish.kalra@freescale.com>
* Li Yang <leoli@freescale.com>
*
- * Copyright (c) 2006-2007, 2011 Freescale Semiconductor, Inc.
+ * Copyright (c) 2006-2007, 2011-2012 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -162,6 +162,16 @@ enum {
};
/*
+ * Interrupt Coalescing Control Register bitdefs
+ */
+enum {
+ ICC_MIN_INT_THRESHOLD_COUNT = (1 << 24),
+ ICC_MAX_INT_THRESHOLD_COUNT = (((1 << 4) - 1) << 24),
+ ICC_MIN_INT_THRESHOLD_TIMER = 1,
+ ICC_MAX_INT_THRESHOLD_TIMER = ((1 << 18) - 1),
+};
+
+/*
* SATA Superset Registers
*/
enum {
@@ -460,6 +470,13 @@ static unsigned int sata_fsl_qc_issue(struct ata_queued_cmd *qc)
/* Simply queue command to the controller/device */
iowrite32(1 << tag, CQ + hcr_base);
+ /*
+ * reset the number of command complete bits which will cause the
+ * interrupt to be signaled
+ */
+ iowrite32(ICC_MAX_INT_THRESHOLD_COUNT | ICC_MAX_INT_THRESHOLD_TIMER,
+ ICC + hcr_base);
+
VPRINTK("xx_qc_issue called, tag=%d, CQ=0x%x, CA=0x%x\n",
tag, ioread32(CQ + hcr_base), ioread32(CA + hcr_base));
--
1.6.4
^ permalink raw reply related
* Re: [PATCH][SDK v1.2] sata: I/O load balancing
From: Li Yang @ 2012-01-13 9:36 UTC (permalink / raw)
To: Qiang Liu; +Cc: linux-ide, linuxppc-dev, jgarzik, linux-kernel, Qiang Liu
In-Reply-To: <1326443147-26645-1-git-send-email-qiang.liu@freescale.com>
On Fri, Jan 13, 2012 at 4:25 PM, Qiang Liu <qiang.liu@freescale.com> wrote:
> From: Qiang Liu <b32616@freescale.com>
>
> Reduce interrupt singnals through reset Interrupt Coalescing Control Reg.
> Increase the threshold value of interrupt and timer will reduce the number
> of complete interrupt sharply. Improve the system performance effectively.
There is always a trade off of throughput and latency by using
interrupt coalescing. It's not reasonable to assume that the
throughput is the only factor to be considered and set the coalescing
threshold and timeout to the max value by default. Have you carried
out other benchmark like copying many small files?
It will be safer to make the coalescing runtime configurable like the
sata_mv driver, IMO.
- Leo
^ permalink raw reply
* Re: spi device from handle
From: Martyn Welch @ 2012-01-13 9:32 UTC (permalink / raw)
To: Michael Remski; +Cc: linuxppc-dev
In-Reply-To: <alpine.BSF.2.00.1201121056330.21456@payne.remski.net>
On 12/01/12 16:02, Michael Remski wrote:
> 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).
>
We have a FPGA that provides a number of different functions. Each function is
provided in a distinct register set. We have multiple entries in the DTS, one
for each piece of functionality. The drivers are then able to bind separately
against the required registers. So in the case of
"arch/powerpc/boot/dts/gef_ppc9a.dts", "fpga@4,0", "wdt@4,2000", "wdt@4,2010",
"pic@4,4000" and "gpio@7,14000" are all provided by the same FPGA and each has
it's own driver. However, I've just realised our FPGA is memory mapped and
looking at your DTS snippet yours isn't.
The only clean way I can think about doing it via spi would be to have a
driver that provides an in-kernel interface to access the functionality in the
FPGA (which binds to this entry in the DTS), then modify the driver providing
the user space access to use that and also use that interface for other
drivers needing access to the FPGA. Depending on the level of extrapolation
provided by the existing user space driver, this may be possible without
breaking anything in user space.
Martyn
--
Martyn Welch (Lead Software Engineer) | Registered in England and Wales
GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
T +44(0)1327322748 | Manchester, M2 3AB
E martyn.welch@ge.com | VAT:GB 927559189
^ permalink raw reply
* Re: spi device from handle
From: Michael Remski @ 2012-01-13 9:53 UTC (permalink / raw)
To: Martyn Welch; +Cc: linuxppc-dev
In-Reply-To: <4F0FFA19.7070606@ge.com>
Thanks Martyn. I'll look at that. The userspace interface is covered by
the existing "spidev" driver. The fpga child gets enumerated and added to
the spi bus as it should, it's just trying to get the "struct spi_device"
is confounding me.
On Fri, 13 Jan 2012, Martyn Welch wrote:
> On 12/01/12 16:02, Michael Remski wrote:
>> 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).
>>
>
> We have a FPGA that provides a number of different functions. Each function is
> provided in a distinct register set. We have multiple entries in the DTS, one
> for each piece of functionality. The drivers are then able to bind separately
> against the required registers. So in the case of
> "arch/powerpc/boot/dts/gef_ppc9a.dts", "fpga@4,0", "wdt@4,2000", "wdt@4,2010",
> "pic@4,4000" and "gpio@7,14000" are all provided by the same FPGA and each has
> it's own driver. However, I've just realised our FPGA is memory mapped and
> looking at your DTS snippet yours isn't.
>
> The only clean way I can think about doing it via spi would be to have a
> driver that provides an in-kernel interface to access the functionality in the
> FPGA (which binds to this entry in the DTS), then modify the driver providing
> the user space access to use that and also use that interface for other
> drivers needing access to the FPGA. Depending on the level of extrapolation
> provided by the existing user space driver, this may be possible without
> breaking anything in user space.
>
> Martyn
>
> --
> Martyn Welch (Lead Software Engineer) | Registered in England and Wales
> GE Intelligent Platforms | (3828642) at 100 Barbirolli Square
> T +44(0)1327322748 | Manchester, M2 3AB
> E martyn.welch@ge.com | VAT:GB 927559189
>
^ permalink raw reply
* RE: [PATCH][SDK v1.2] sata: I/O load balancing
From: Liu Qiang-B32616 @ 2012-01-13 9:57 UTC (permalink / raw)
To: Li Yang-R58472
Cc: linux-ide@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
jgarzik@pobox.com, linux-kernel@vger.kernel.org
In-Reply-To: <CADRPPNQsVB-2jR0UaX6RB_4PCf9kt4UXvAXnxaVk=LsBcwGowg@mail.gmail.com>
=0A=
________________________________________=0A=
> From: linux-ide-owner@vger.kernel.org [linux-ide-owner@vger.kernel.org] o=
n behalf of Li Yang [leoli@freescale.com]=0A=
> Sent: Friday, January 13, 2012 3:36 AM=0A=
> To: Liu Qiang-B32616=0A=
> Cc: jgarzik@pobox.com; linux-ide@vger.kernel.org; linux-kernel@vger.kerne=
l.org; linuxppc-dev@lists.ozlabs.org; Liu Qiang-B32616=0A=
> Subject: Re: [PATCH][SDK v1.2] sata: I/O load balancing=0A=
=0A=
> On Fri, Jan 13, 2012 at 4:25 PM, Qiang Liu <qiang.liu@freescale.com> wrot=
e:=0A=
> > From: Qiang Liu <b32616@freescale.com>=0A=
> >=0A=
> > Reduce interrupt singnals through reset Interrupt Coalescing Control Re=
g.=0A=
> > Increase the threshold value of interrupt and timer will reduce the num=
ber=0A=
> > of complete interrupt sharply. Improve the system performance effective=
ly.=0A=
=0A=
> There is always a trade off of throughput and latency by using=0A=
> interrupt coalescing. It's not reasonable to assume that the=0A=
> throughput is the only factor to be considered and set the coalescing=0A=
> threshold and timeout to the max value by default. Have you carried=0A=
> out other benchmark like copying many small files?=0A=
No, I didn't test small file. I think this won't affect system load. I can =
have a test=0A=
and describe the result in next patch.=0A=
=0A=
> It will be safer to make the coalescing runtime configurable like the=0A=
> sata_mv driver, IMO.=0A=
Ok, I will do it like this in next patch.=0A=
=0A=
=0A=
- Leo=0A=
--=0A=
To unsubscribe from this list: send the line "unsubscribe linux-ide" in=0A=
the body of a message to majordomo@vger.kernel.org=0A=
More majordomo info at http://vger.kernel.org/majordomo-info.html=0A=
=0A=
^ permalink raw reply
* Re: Cannot wake-up from standby with MPC8313
From: Norbert van Bolhuis @ 2012-01-13 14:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <4F076187.2080308@freescale.com>
On 01/06/12 22:03, Scott Wood wrote:
> On 01/06/2012 07:53 AM, Norbert van Bolhuis wrote:
>> On 01/05/12 19:22, Scott Wood wrote:
>>> On 01/05/2012 09:58 AM, Norbert van Bolhuis wrote:
>>>> thanks for your response.
>>>>
>>>> not setting MSR_POW gives same result.
>>>
>>> OK, so you're not getting an interrupt regardless of low-power state.
>>>
>>> Check whether the interrupt is getting masked during standby preparation.
>>>
>>> Does the interrupt handler run when you're not trying to enter standby?
>>>
>>
>>
>> The GPIO/UART interrupt nor the PMC interrupt are being masked during
>> standby
>> preperation.
>> The GPIO/UART interrupt works fine in "operational" mode.
>> The PMC interrupt I do not know, is it possible to to get PMC interrupt
>> without going to standby or deep-sleep ?
>
> The PMC interrupt is mainly of interest when running as a PCI agent, to
> be notified when the host changed the desired suspend state in config space.
>
> What changes from operational mode to the test where you omit setting
> MSR_POW?
>
> Try dumping SIPNR/SIMSR and GPIER/GPIMR/GPDAT at various points.
>
I dumped SIPNR/SIMSR and uart IIR/EIR (since console triggers wake-up)
but they do not change just before entering standby (via mpc6xx_enter_standby
which omits setting MSR_POW). uart IRQ is always enabled, unmasked and
not pending.
I tried to log to physical memory to see what's going on whenever the
board fails to wake-up.
(I can examine physical memory after CPU is stuck in sleep, by connecting
a JTAG debugger, start u-boot and stop after DDR2 SDRAM ctrl is
re-configured)
It looks like an interupt does occur, but do_IRQ seems to be stuck
in ppc_md.get_irq=ipic_get_irq where it reads SIVCR.
I have no idea why, any more suggestions ?
---
NvBolhuis
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Fix parse_arg build error
From: Kumar Gala @ 2012-01-13 20:45 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev
In-Reply-To: <1326431115-425-1-git-send-email-msm@freescale.com>
On Jan 12, 2012, at 11:05 PM, Matthew McClintock wrote:
> This fixes this build issue:
>=20
> 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
>=20
> Signed-off-by: Matthew McClintock <msm@freescale.com>
> ---
> This is for benh next tree
>=20
> arch/powerpc/mm/hugetlbpage.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
This is fixed upstream, benh's tree is based on a older snapshot of =
linus's tree that doesn't have this fix.
commit 13020be8be2d5843c3810169cdbcc51f07ff020f
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Thu Nov 24 09:40:07 2011 +0000
powerpc: Fix compiliation with hugetlbfs enabled
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Fix parse_arg build error
From: McClintock Matthew-B29882 @ 2012-01-13 20:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <AD686389-E2D8-49C6-9443-FF3B33775469@kernel.crashing.org>
On Fri, Jan 13, 2012 at 2:45 PM, Kumar Gala <galak@kernel.crashing.org> wro=
te:
> On Jan 12, 2012, at 11:05 PM, Matthew McClintock wrote:
>
>> 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 func=
tion '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 | =A0 =A01 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> This is fixed upstream, benh's tree is based on a older snapshot of linus=
's tree that doesn't have this fix.
>
> commit 13020be8be2d5843c3810169cdbcc51f07ff020f
> Author: Kumar Gala <galak@kernel.crashing.org>
> Date: =A0 Thu Nov 24 09:40:07 2011 +0000
>
> =A0 =A0powerpc: Fix compiliation with hugetlbfs enabled
I was starting to realize this today after I saw Ben's pull request...
-M=
^ permalink raw reply
* Re: next BUG: using smp_processor_id() in preemptible
From: Hugh Dickins @ 2012-01-14 22:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1324588672.6632.8.camel@pasglop>
On Fri, 23 Dec 2011, Benjamin Herrenschmidt wrote:
> On Thu, 2011-12-22 at 04:07 -0800, Hugh Dickins wrote:
> > On Mon, 5 Dec 2011, Hugh Dickins wrote:
> >
> > > 3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of
> > >
> > > Dec 4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
> > > Dec 4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
> > > Dec 4 20:03:19 thorn kernel: Call Trace:
> > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
> > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
> > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
> > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
> > > Dec 4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed
> > >
> > > from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
> > > in decrementer_check_overflow(): I've no idea whether it's safe
> > > just to use get_cpu_var then put_cpu_var there instead,
> > > but no hurry, I can survive with DEBUG_PREEMPT off.
> >
> > Still a problem in 3.2.0-rc6-next-20111222
>
> Ah forgot about that, I'll have a look. Thanks for the reminder.
I'm afraid it's now blighting Linus's tree for 3.3.
Hugh
^ permalink raw reply
* Re: [PATCH 2/2] Kbuild: Use dtc's -d (dependency) option
From: Michal Marek @ 2012-01-14 22:51 UTC (permalink / raw)
To: Mark Salter, Stephen Warren
Cc: Jonas Bonn, Jon Loeliger, Russell King, linux-c6x-dev,
Arnd Bergmann, Aurelien Jacquiot, linux, linux-kbuild,
Michal Simek, Rob Herring, linux-kernel, Paul Mackerras,
microblaze-uclinux, linuxppc-dev, Devicetree Discuss,
linux-arm-kernel, David Gibson
In-Reply-To: <1326310587.2535.291.camel@deneb.redhat.com>
On 11.1.2012 20:36, Mark Salter wrote:
> On Mon, 2012-01-09 at 11:38 -0700, Stephen Warren wrote:
>> This hooks dtc into Kbuild's dependency system.
>>
>> Thus, for example, "make dtbs" will rebuild tegra-harmony.dtb if only
>> tegra20.dtsi has changed yet tegra-harmony.dts has not. The previous
>> lack of this feature recently caused me to have very confusing "git
>> bisect" results.
>>
>> For ARM, it's obvious what to add to $(targets). I'm not familiar enough
>> with other architectures to know what to add there. Powerpc appears to
>> already add various .dtb files into $(targets), but the other archs may
>> need something added to $(targets) to work.
>>
>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>>
>
> Acked-by: Mark Salter <msalter@redhat.com>
>
> For the arch/c6x bit.
As the C6X port has been merged in this merge window, I can't easily
apply this patch to my kbuild branch and at the same time please Linus
by basing the pull request on a tagged release. So I'm going to drop the
arch/c6x part to keep the kbuild branch "pretty" and let either Mark or
Stephen send the patch to Linus directly, once he has merged the kbuild
branch. Would that work?
Thanks,
Michal
^ permalink raw reply
* Re: next BUG: using smp_processor_id() in preemptible
From: Benjamin Herrenschmidt @ 2012-01-15 5:05 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linuxppc-dev
In-Reply-To: <alpine.LSU.2.00.1201141419530.1266@eggly.anvils>
On Sat, 2012-01-14 at 14:21 -0800, Hugh Dickins wrote:
> On Fri, 23 Dec 2011, Benjamin Herrenschmidt wrote:
> > On Thu, 2011-12-22 at 04:07 -0800, Hugh Dickins wrote:
> > > On Mon, 5 Dec 2011, Hugh Dickins wrote:
> > >
> > > > 3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of
> > > >
> > > > Dec 4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
> > > > Dec 4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
> > > > Dec 4 20:03:19 thorn kernel: Call Trace:
> > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
> > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
> > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
> > > > Dec 4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
> > > > Dec 4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed
> > > >
> > > > from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
> > > > in decrementer_check_overflow(): I've no idea whether it's safe
> > > > just to use get_cpu_var then put_cpu_var there instead,
> > > > but no hurry, I can survive with DEBUG_PREEMPT off.
> > >
> > > Still a problem in 3.2.0-rc6-next-20111222
> >
> > Ah forgot about that, I'll have a look. Thanks for the reminder.
>
> I'm afraid it's now blighting Linus's tree for 3.3.
Grrr, my memory is a colander... And now am in Ballarat for the week
with a semi working 3g connection. I'll see what I can do.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
From: Michael Neuling @ 2012-01-16 0:29 UTC (permalink / raw)
To: Florian Tobias Schandinat, Timur Tabi; +Cc: linuxppc-dev, linux-fbdev
Fix a bunch of compiler errors and warnings introduced in:
commit ddd3d905436b572ebadc09dcf2d12ca5b37020a0
Author: Timur Tabi <timur@freescale.com>
drivers/video: fsl-diu-fb: merge all allocated data into one block
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Timur: you do compile test your patches, right? :-P
This is effecting mpc85xx_defconfig on mainline (and has been in
linux-next for while already).
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index acf292b..78cac52 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -366,7 +366,7 @@ struct mfb_info {
*/
struct fsl_diu_data {
dma_addr_t dma_addr;
- struct fb_info fsl_diu_info[NUM_AOIS];
+ struct fb_info *fsl_diu_info[NUM_AOIS];
struct mfb_info mfb[NUM_AOIS];
struct device_attribute dev_attr;
unsigned int irq;
@@ -608,8 +608,8 @@ static void adjust_aoi_size_position(struct fb_var_screeninfo *var,
int lower_aoi_is_open, upper_aoi_is_open;
__u32 base_plane_width, base_plane_height, upper_aoi_height;
- base_plane_width = data->fsl_diu_info[0].var.xres;
- base_plane_height = data->fsl_diu_info[0].var.yres;
+ base_plane_width = data->fsl_diu_info[0]->var.xres;
+ base_plane_height = data->fsl_diu_info[0]->var.yres;
if (mfbi->x_aoi_d < 0)
mfbi->x_aoi_d = 0;
@@ -624,7 +624,7 @@ static void adjust_aoi_size_position(struct fb_var_screeninfo *var,
break;
case PLANE1_AOI0:
case PLANE2_AOI0:
- lower_aoi_mfbi = data->fsl_diu_info[index+1].par;
+ lower_aoi_mfbi = data->fsl_diu_info[index+1]->par;
lower_aoi_is_open = lower_aoi_mfbi->count > 0 ? 1 : 0;
if (var->xres > base_plane_width)
var->xres = base_plane_width;
@@ -642,8 +642,8 @@ static void adjust_aoi_size_position(struct fb_var_screeninfo *var,
break;
case PLANE1_AOI1:
case PLANE2_AOI1:
- upper_aoi_mfbi = data->fsl_diu_info[index-1].par;
- upper_aoi_height = data->fsl_diu_info[index-1].var.yres;
+ upper_aoi_mfbi = data->fsl_diu_info[index-1]->par;
+ upper_aoi_height = data->fsl_diu_info[index-1]->var.yres;
upper_aoi_bottom = upper_aoi_mfbi->y_aoi_d + upper_aoi_height;
upper_aoi_is_open = upper_aoi_mfbi->count > 0 ? 1 : 0;
if (var->xres > base_plane_width)
@@ -1469,7 +1469,7 @@ static ssize_t store_monitor(struct device *device,
unsigned int i;
for (i=0; i < NUM_AOIS; i++)
- fsl_diu_set_par(&data->fsl_diu_info[i]);
+ fsl_diu_set_par(data->fsl_diu_info[i]);
}
return count;
}
@@ -1524,7 +1524,7 @@ static int __devinit fsl_diu_probe(struct platform_device *pdev)
spin_lock_init(&data->reg_lock);
for (i = 0; i < NUM_AOIS; i++) {
- struct fb_info *info = &data->fsl_diu_info[i];
+ struct fb_info *info = data->fsl_diu_info[i];
info->device = &pdev->dev;
info->par = &data->mfb[i];
@@ -1597,7 +1597,7 @@ static int __devinit fsl_diu_probe(struct platform_device *pdev)
out_be32(&data->diu_reg->desc[2], data->dummy_ad.paddr);
for (i = 0; i < NUM_AOIS; i++) {
- ret = install_fb(&data->fsl_diu_info[i]);
+ ret = install_fb(data->fsl_diu_info[i]);
if (ret) {
dev_err(&pdev->dev, "could not register fb %d\n", i);
goto error;
@@ -1625,7 +1625,7 @@ static int __devinit fsl_diu_probe(struct platform_device *pdev)
error:
for (i = 0; i < NUM_AOIS; i++)
- uninstall_fb(&data->fsl_diu_info[i]);
+ uninstall_fb(data->fsl_diu_info[i]);
iounmap(data->diu_reg);
@@ -1641,11 +1641,11 @@ static int fsl_diu_remove(struct platform_device *pdev)
int i;
data = dev_get_drvdata(&pdev->dev);
- disable_lcdc(&data->fsl_diu_info[0]);
+ disable_lcdc(data->fsl_diu_info[0]);
free_irq_local(data);
for (i = 0; i < NUM_AOIS; i++)
- uninstall_fb(&data->fsl_diu_info[i]);
+ uninstall_fb(data->fsl_diu_info[i]);
iounmap(data->diu_reg);
^ permalink raw reply related
* Re: [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
From: Tabi Timur-B04825 @ 2012-01-16 0:35 UTC (permalink / raw)
To: Michael Neuling
Cc: linuxppc-dev@ozlabs.org, linux-fbdev@vger.kernel.org,
Florian Tobias Schandinat
In-Reply-To: <19504.1326673788@neuling.org>
Michael Neuling wrote:
> Fix a bunch of compiler errors and warnings introduced in:
> commit ddd3d905436b572ebadc09dcf2d12ca5b37020a0
> Author: Timur Tabi<timur@freescale.com>
> drivers/video: fsl-diu-fb: merge all allocated data into one block
>
> Signed-off-by: Michael Neuling<mikey@neuling.org>
> ---
> Timur: you do compile test your patches, right? :-P
I have a script that tests each commit in a set to make sure it compiles,=20
so that git-bisect isn't broken.
> This is effecting mpc85xx_defconfig on mainline (and has been in
> linux-next for while already).
>
> diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
> index acf292b..78cac52 100644
> --- a/drivers/video/fsl-diu-fb.c
> +++ b/drivers/video/fsl-diu-fb.c
> @@ -366,7 +366,7 @@ struct mfb_info {
> */
> struct fsl_diu_data {
> dma_addr_t dma_addr;
> - struct fb_info fsl_diu_info[NUM_AOIS];
> + struct fb_info *fsl_diu_info[NUM_AOIS];
This doesn't make any sense. If you change fsl_diu_info into a pointer,=20
then where is the object being allocated?
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
From: Michael Neuling @ 2012-01-16 0:52 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: linuxppc-dev@ozlabs.org, linux-fbdev@vger.kernel.org,
Florian Tobias Schandinat
In-Reply-To: <4F1370C9.9010400@freescale.com>
In message <4F1370C9.9010400@freescale.com> you wrote:
> Michael Neuling wrote:
> > Fix a bunch of compiler errors and warnings introduced in:
> > commit ddd3d905436b572ebadc09dcf2d12ca5b37020a0
> > Author: Timur Tabi<timur@freescale.com>
> > drivers/video: fsl-diu-fb: merge all allocated data into one block
> >
> > Signed-off-by: Michael Neuling<mikey@neuling.org>
> > ---
> > Timur: you do compile test your patches, right? :-P
>
> I have a script that tests each commit in a set to make sure it compiles,
> so that git-bisect isn't broken.
May I suggest you actually run the script next time :-P
> > This is effecting mpc85xx_defconfig on mainline (and has been in
> > linux-next for while already).
> >
> > diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
> > index acf292b..78cac52 100644
> > --- a/drivers/video/fsl-diu-fb.c
> > +++ b/drivers/video/fsl-diu-fb.c
> > @@ -366,7 +366,7 @@ struct mfb_info {
> > */
> > struct fsl_diu_data {
> > dma_addr_t dma_addr;
> > - struct fb_info fsl_diu_info[NUM_AOIS];
> > + struct fb_info *fsl_diu_info[NUM_AOIS];
>
> This doesn't make any sense. If you change fsl_diu_info into a pointer,=20
> then where is the object being allocated?
OK, how about this?
From: Michael Neuling <mikey@neuling.org>
[PATCH] drivers/video: compile fixes for fsl-diu-fb.c
Fix a compiler errors introduced in:
commit ddd3d905436b572ebadc09dcf2d12ca5b37020a0
Author: Timur Tabi <timur@freescale.com>
drivers/video: fsl-diu-fb: merge all allocated data into one block
Signed-off-by: Michael Neuling <mikey@neuling.org>
diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
index acf292b..3006b2b 100644
--- a/drivers/video/fsl-diu-fb.c
+++ b/drivers/video/fsl-diu-fb.c
@@ -1432,7 +1432,7 @@ static int fsl_diu_suspend(struct platform_device *ofdev, pm_message_t state)
struct fsl_diu_data *data;
data = dev_get_drvdata(&ofdev->dev);
- disable_lcdc(data->fsl_diu_info[0]);
+ disable_lcdc(&(data->fsl_diu_info[0]));
return 0;
}
@@ -1442,7 +1442,7 @@ static int fsl_diu_resume(struct platform_device *ofdev)
struct fsl_diu_data *data;
data = dev_get_drvdata(&ofdev->dev);
- enable_lcdc(data->fsl_diu_info[0]);
+ enable_lcdc(&(data->fsl_diu_info[0]));
return 0;
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox