* Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Timur Tabi @ 2012-02-16 19:48 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: Dan Williams, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20120216194655.GD9262@ovro.caltech.edu>
Ira W. Snyder wrote:
> No. I don't have the ability to connect my P2020 up to an FPGA to
> recreate the DMA workload that causes this on my 8349EA. I can run the
> dmatest module, if you'd like.
I just want to make sure your patch doesn't break 85xx.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Ira W. Snyder @ 2012-02-16 19:46 UTC (permalink / raw)
To: Timur Tabi; +Cc: Dan Williams, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F3D5A28.4010905@freescale.com>
On Thu, Feb 16, 2012 at 01:34:00PM -0600, Timur Tabi wrote:
> Ira W. Snyder wrote:
> > This leads me to believe that this occurs mostly (but not always)
> > concurrent with the end-of-chain interrupt.
>
> Have you tested this on an 85xx platform?
>
No. I don't have the ability to connect my P2020 up to an FPGA to
recreate the DMA workload that causes this on my 8349EA. I can run the
dmatest module, if you'd like.
> I noticed something odd. You're modifying fsldma_chan_irq(), which is for
> DMA controllers that have per-channel IRQs. 83xx devices don't have
> per-channel IRQs -- all channels on one controller have the same IRQ.
> Looking at the device tree, I see that the IRQs are listed in the channel
> nodes *and* in the controller node. I don't see how we ever use the
> per-controller ISR.
>
fsldma_ctrl_irq() (the per-controller irq handler) just calls through to
fsldma_chan_irq() (the per-channel irq handler).
> I wonder if the shared IRQ is the part of the cause of the interrupts
> you're seeing.
>
My device tree is slightly modified to remove the per-controller
interrupts and interrupt-parent properties. Each individual channel has
identical interrupts and interrupt-parent properties specified.
Someone here suggested that I do that, several years ago. It has been
too long, and I do not remember who. I can reverse it, and use the
per-controller IRQ instead.
> >
> > In the last month, the "unhandled sr" error has occurred on 92 out of
> > 120 boards in production use. The statistics are included below. On some
> > boards, it is much more frequent than on others. All boards have roughly
> > the same workload.
> >
> > Another interesting tidbit from my logs: this only occurs on DMA channel
> > 2 (the are numbered starting at 0, it is the 3rd channel). Here is an
> > example log message:
>
> What happens if you never register that channel? That is, remove this
> node from the device tree:
>
> dma-channel@100 {
> compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
> reg = <0x100 0x80>;
> cell-index = <2>;
> interrupt-parent = <&ipic>;
> interrupts = <71 8>;
> };
>
I can try that. I hunch the problem will move, as the carma-fpga driver
(see drivers/misc/carma/carma-fpga.c) will claim the 4th channel
instead.
Ira
^ permalink raw reply
* Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Timur Tabi @ 2012-02-16 19:34 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: Dan Williams, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20120216190040.GA9262@ovro.caltech.edu>
Ira W. Snyder wrote:
> This leads me to believe that this occurs mostly (but not always)
> concurrent with the end-of-chain interrupt.
Have you tested this on an 85xx platform?
I noticed something odd. You're modifying fsldma_chan_irq(), which is for
DMA controllers that have per-channel IRQs. 83xx devices don't have
per-channel IRQs -- all channels on one controller have the same IRQ.
Looking at the device tree, I see that the IRQs are listed in the channel
nodes *and* in the controller node. I don't see how we ever use the
per-controller ISR.
I wonder if the shared IRQ is the part of the cause of the interrupts
you're seeing.
>
> In the last month, the "unhandled sr" error has occurred on 92 out of
> 120 boards in production use. The statistics are included below. On some
> boards, it is much more frequent than on others. All boards have roughly
> the same workload.
>
> Another interesting tidbit from my logs: this only occurs on DMA channel
> 2 (the are numbered starting at 0, it is the 3rd channel). Here is an
> example log message:
What happens if you never register that channel? That is, remove this
node from the device tree:
dma-channel@100 {
compatible = "fsl,mpc8349-dma-channel", "fsl,elo-dma-channel";
reg = <0x100 0x80>;
cell-index = <2>;
interrupt-parent = <&ipic>;
interrupts = <71 8>;
};
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Ira W. Snyder @ 2012-02-16 19:00 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: Dan Williams, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXVccE0GqZU2PvAz3RTh+X9ZYZr-9YufxS+mYWJkhSOGEQ@mail.gmail.com>
On Thu, Feb 16, 2012 at 05:50:47PM +0000, Tabi Timur-B04825 wrote:
> On Thu, Jan 26, 2012 at 2:58 PM, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
> > The mpc8349ea has been observed to generate spurious end of segments
> > interrupts despite the fact that they are not enabled by this driver.
> > Check for them and ignore them to avoid a kernel error message.
>
> When this happens, are there any other status bits set? It seems
> weird that there are spurious interrupts from an internal block,
> especially since it's the same block on all 83xx parts.
>
> I wonder if the EOSI bit just happens to be set when the interrupt
> occurs for some other reason.
>
I'm not sure. The fsldma irq handler only prints bits it did not handle.
There are several other bits in the driver which should never be seen,
but they are handled by the irq handler anyway. This is just a remnant
from the original Freescale code.
I have a set of 15 test boards that I can use to figure out which other
bits are set when this happens, if it is important.
I put a variation of this patch (missing the "skip tasklet if not idle"
logic) into my production boards roughly a month ago. I've gotten the
"controller not idle" error message 748 times, as compared to the
"unhandled sr 0x00000002" message 3449 times.
This leads me to believe that this occurs mostly (but not always)
concurrent with the end-of-chain interrupt.
In the last month, the "unhandled sr" error has occurred on 92 out of
120 boards in production use. The statistics are included below. On some
boards, it is much more frequent than on others. All boards have roughly
the same workload.
Another interesting tidbit from my logs: this only occurs on DMA channel
2 (the are numbered starting at 0, it is the 3rd channel). Here is an
example log message:
[3484053.821689] of:fsl-elo-dma e00082a8.dma: chan2: irq: unhandled sr 0x00000002
Thanks,
Ira
15 serial-number-5
1 serial-number-16
8 serial-number-18
16 serial-number-19
3 serial-number-20
21 serial-number-21
1 serial-number-24
1 serial-number-26
3 serial-number-27
2 serial-number-28
16 serial-number-29
4 serial-number-30
1 serial-number-31
4 serial-number-32
5 serial-number-33
1 serial-number-34
6 serial-number-35
18 serial-number-36
1 serial-number-39
1 serial-number-40
2 serial-number-41
10 serial-number-42
11 serial-number-43
32 serial-number-45
6 serial-number-46
4 serial-number-47
1 serial-number-49
6 serial-number-50
2 serial-number-51
4 serial-number-53
1 serial-number-55
1 serial-number-57
15 serial-number-58
1 serial-number-60
1 serial-number-62
1 serial-number-66
8 serial-number-67
2 serial-number-75
1 serial-number-76
11 serial-number-79
4 serial-number-80
8 serial-number-81
1 serial-number-82
11 serial-number-84
2 serial-number-92
20 serial-number-93
30 serial-number-94
19 serial-number-95
32 serial-number-96
73 serial-number-97
18 serial-number-99
57 serial-number-100
41 serial-number-101
28 serial-number-102
8 serial-number-103
132 serial-number-107
60 serial-number-108
55 serial-number-109
97 serial-number-110
18 serial-number-111
45 serial-number-113
6 serial-number-114
123 serial-number-115
27 serial-number-117
29 serial-number-118
12 serial-number-119
47 serial-number-120
74 serial-number-121
8 serial-number-124
128 serial-number-125
326 serial-number-128
84 serial-number-129
36 serial-number-130
2 serial-number-131
75 serial-number-133
64 serial-number-135
686 serial-number-137
97 serial-number-139
28 serial-number-140
82 serial-number-141
36 serial-number-144
31 serial-number-145
47 serial-number-147
60 serial-number-150
22 serial-number-152
36 serial-number-154
57 serial-number-156
68 serial-number-158
54 serial-number-159
37 serial-number-160
46 serial-number-161
14 serial-number-162
^ permalink raw reply
* Re: [PATCH v5 08/27] irq_domain: Move irq_domain code from powerpc to kernel/irq
From: Cousson, Benoit @ 2012-02-16 17:52 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <4F3D3F21.3060905@ti.com>
OK, forget about it, I've just seen your email on that and pulled your
latest update.
Regards,
Benoit
On 2/16/2012 6:38 PM, Cousson, Benoit wrote:
> Hi Grant,
>
> It looks like there is a small regression in that update, it cannot
> build due to a missing semi-colon.
>
> On 2/16/2012 10:09 AM, Grant Likely wrote:
>> +/**
>> + * irq_find_mapping() - Find a linux irq from an hw irq number.
>> + * @host: domain owning this hardware interrupt
>> + * @hwirq: hardware irq number in that host space
>> + *
>> + * This is a slow path, for use by generic code. It's expected that an
>> + * irq controller implementation directly calls the appropriate low
>> level
>> + * mapping function.
>> + */
>> +unsigned int irq_find_mapping(struct irq_domain *host,
>> + irq_hw_number_t hwirq)
>> +{
>> + unsigned int i;
>> + unsigned int hint = hwirq % irq_virq_count;
>> +
>> + /* Look for default host if nececssary */
>> + if (host == NULL)
>> + host = irq_default_host;
>> + if (host == NULL)
>> + return NO_IRQ;
>> +
>> + /* legacy -> bail early */
>> + if (host->revmap_type == IRQ_DOMAIN_MAP_LEGACY)
>> + return hwirq;
>> +
>> + /* Slow path does a linear search of the map */
>> + if (hint == 0)
>> + hint = 1;
>> + i = hint;
>> + do {
>> + struct irq_data *data = irq_get_irq_data(i);
>> + if (data&& (data->domain == host)&& (data->hwirq == hwirq))
>> + return i;
>> + i++;
>> + if (i>= irq_virq_count)
>> + i = 1
>
> The ";" is missing.
>
> Regards,
> Benoit
^ permalink raw reply
* Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Tabi Timur-B04825 @ 2012-02-16 17:50 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: Dan Williams, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1327611520-18256-1-git-send-email-iws@ovro.caltech.edu>
On Thu, Jan 26, 2012 at 2:58 PM, Ira W. Snyder <iws@ovro.caltech.edu> wrote=
:
> The mpc8349ea has been observed to generate spurious end of segments
> interrupts despite the fact that they are not enabled by this driver.
> Check for them and ignore them to avoid a kernel error message.
When this happens, are there any other status bits set? It seems
weird that there are spurious interrupts from an internal block,
especially since it's the same block on all 83xx parts.
I wonder if the EOSI bit just happens to be set when the interrupt
occurs for some other reason.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH v4 3/3] KVM: PPC: epapr: install ev_idle hcall for e500 guest
From: Alexander Graf @ 2012-02-16 17:39 UTC (permalink / raw)
To: Scott Wood
Cc: <linuxppc-dev@ozlabs.org>, Liu Yu,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>,
<B07421@freescale.com>
In-Reply-To: <4F3D3E89.3050301@freescale.com>
On 16.02.2012, at 18:36, Scott Wood wrote:
> On 02/16/2012 11:30 AM, Alexander Graf wrote:
>>=20
>> On 16.02.2012, at 18:28, Scott Wood wrote:
>>=20
>>> On 02/16/2012 11:18 AM, Alexander Graf wrote:
>>>> Hrm. But we can clobber ctr, right? So how about we make the =
generic version do a bctr and then just do a small C wrapper that takes =
lr, moves it to ctr and branches to the generic one?
>>>=20
>>> If it's just for this, I would say don't mess with the normal hcall =
path
>>> for the sake of idle. If using CTR would let us get away without
>>> creating a stack frame in call sites, maybe that would be =
worthwhile,
>>> depending on what sort of hcalls we end up having.
>>>=20
>>>> Then we don't have to replicate the hypercall code all over again =
for every invocation.
>>>=20
>>> We shouldn't need to do it for every invocation. Idle is special =
due to
>>> the TLF_NAPPING hack.
>>=20
>> Famous last words. If it's the only case, duplication should be ok. =
Let's hope there are no others.
>=20
> Actually, we can't use CTR -- it's volatile in the ePAPR hypercall =
ABI.
Ugh. Alrighty, let's duplicate the hc code then.
Alex
^ permalink raw reply
* Re: [PATCH v5 08/27] irq_domain: Move irq_domain code from powerpc to kernel/irq
From: Cousson, Benoit @ 2012-02-16 17:38 UTC (permalink / raw)
To: Grant Likely
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1329383368-12122-9-git-send-email-grant.likely@secretlab.ca>
Hi Grant,
It looks like there is a small regression in that update, it cannot
build due to a missing semi-colon.
On 2/16/2012 10:09 AM, Grant Likely wrote:
> +/**
> + * irq_find_mapping() - Find a linux irq from an hw irq number.
> + * @host: domain owning this hardware interrupt
> + * @hwirq: hardware irq number in that host space
> + *
> + * This is a slow path, for use by generic code. It's expected that an
> + * irq controller implementation directly calls the appropriate low level
> + * mapping function.
> + */
> +unsigned int irq_find_mapping(struct irq_domain *host,
> + irq_hw_number_t hwirq)
> +{
> + unsigned int i;
> + unsigned int hint = hwirq % irq_virq_count;
> +
> + /* Look for default host if nececssary */
> + if (host == NULL)
> + host = irq_default_host;
> + if (host == NULL)
> + return NO_IRQ;
> +
> + /* legacy -> bail early */
> + if (host->revmap_type == IRQ_DOMAIN_MAP_LEGACY)
> + return hwirq;
> +
> + /* Slow path does a linear search of the map */
> + if (hint == 0)
> + hint = 1;
> + i = hint;
> + do {
> + struct irq_data *data = irq_get_irq_data(i);
> + if (data&& (data->domain == host)&& (data->hwirq == hwirq))
> + return i;
> + i++;
> + if (i>= irq_virq_count)
> + i = 1
The ";" is missing.
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH v4 3/3] KVM: PPC: epapr: install ev_idle hcall for e500 guest
From: Scott Wood @ 2012-02-16 17:36 UTC (permalink / raw)
To: Alexander Graf
Cc: <linuxppc-dev@ozlabs.org>, Liu Yu,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>,
<B07421@freescale.com>
In-Reply-To: <144AF998-6DEE-453A-872A-B148ACA2B7B8@suse.de>
On 02/16/2012 11:30 AM, Alexander Graf wrote:
>
> On 16.02.2012, at 18:28, Scott Wood wrote:
>
>> On 02/16/2012 11:18 AM, Alexander Graf wrote:
>>> Hrm. But we can clobber ctr, right? So how about we make the generic version do a bctr and then just do a small C wrapper that takes lr, moves it to ctr and branches to the generic one?
>>
>> If it's just for this, I would say don't mess with the normal hcall path
>> for the sake of idle. If using CTR would let us get away without
>> creating a stack frame in call sites, maybe that would be worthwhile,
>> depending on what sort of hcalls we end up having.
>>
>>> Then we don't have to replicate the hypercall code all over again for every invocation.
>>
>> We shouldn't need to do it for every invocation. Idle is special due to
>> the TLF_NAPPING hack.
>
> Famous last words. If it's the only case, duplication should be ok. Let's hope there are no others.
Actually, we can't use CTR -- it's volatile in the ePAPR hypercall ABI.
-Scott
^ permalink raw reply
* Re: [PATCH v4 3/3] KVM: PPC: epapr: install ev_idle hcall for e500 guest
From: Alexander Graf @ 2012-02-16 17:30 UTC (permalink / raw)
To: Scott Wood
Cc: <linuxppc-dev@ozlabs.org>, Liu Yu,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>,
<B07421@freescale.com>
In-Reply-To: <4F3D3CBA.2060201@freescale.com>
On 16.02.2012, at 18:28, Scott Wood wrote:
> On 02/16/2012 11:18 AM, Alexander Graf wrote:
>>=20
>> On 16.02.2012, at 17:58, Scott Wood wrote:
>>=20
>>> On 02/16/2012 04:24 AM, Alexander Graf wrote:
>>>> On 16.02.2012, at 10:26, Liu Yu <yu.liu@freescale.com> wrote:
>>>>> +_GLOBAL(epapr_ev_idle)
>>>>> +epapr_ev_idle:
>>>>> + rlwinm r3,r1,0,0,31-THREAD_SHIFT /* current thread_info =
*/
>>>>> + lwz r4,TI_LOCAL_FLAGS(r3) /* set napping bit */
>>>>> + ori r4,r4,_TLF_NAPPING /* so when we take an exception =
*/
>>>>> + stw r4,TI_LOCAL_FLAGS(r3) /* it will return to our =
caller */
>>>>> +
>>>>> + wrteei 1
>>>>> +
>>>>> +idle_loop:
>>>>> + LOAD_REG_IMMEDIATE(r11, HC_VENDOR_EPAPR | HC_EV_IDLE)
>>>>> +
>>>>> +.global epapr_ev_idle_start
>>>>> +epapr_ev_idle_start:
>>>>> + li r3, -1
>>>>> + nop
>>>>> + nop
>>>>> + nop
>>>>=20
>>>> Can't you just bl into epapr_hypercall_start? You don't even have =
to save the old lr. because we never return anyways :)
>>>=20
>>> The interrupt will branch to LR, so no, we can't trash it or put it
>>> anywhere else.
>>=20
>> Hrm. But we can clobber ctr, right? So how about we make the generic =
version do a bctr and then just do a small C wrapper that takes lr, =
moves it to ctr and branches to the generic one?
>=20
> If it's just for this, I would say don't mess with the normal hcall =
path
> for the sake of idle. If using CTR would let us get away without
> creating a stack frame in call sites, maybe that would be worthwhile,
> depending on what sort of hcalls we end up having.
>=20
>> Then we don't have to replicate the hypercall code all over again for =
every invocation.
>=20
> We shouldn't need to do it for every invocation. Idle is special due =
to
> the TLF_NAPPING hack.
Famous last words. If it's the only case, duplication should be ok. =
Let's hope there are no others.
Alex
^ permalink raw reply
* Re: [PATCH v4 3/3] KVM: PPC: epapr: install ev_idle hcall for e500 guest
From: Scott Wood @ 2012-02-16 17:28 UTC (permalink / raw)
To: Alexander Graf
Cc: <linuxppc-dev@ozlabs.org>, Liu Yu,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>,
<B07421@freescale.com>
In-Reply-To: <9A00D501-8965-478F-8356-6199F5572600@suse.de>
On 02/16/2012 11:18 AM, Alexander Graf wrote:
>
> On 16.02.2012, at 17:58, Scott Wood wrote:
>
>> On 02/16/2012 04:24 AM, Alexander Graf wrote:
>>> On 16.02.2012, at 10:26, Liu Yu <yu.liu@freescale.com> wrote:
>>>> +_GLOBAL(epapr_ev_idle)
>>>> +epapr_ev_idle:
>>>> + rlwinm r3,r1,0,0,31-THREAD_SHIFT /* current thread_info */
>>>> + lwz r4,TI_LOCAL_FLAGS(r3) /* set napping bit */
>>>> + ori r4,r4,_TLF_NAPPING /* so when we take an exception */
>>>> + stw r4,TI_LOCAL_FLAGS(r3) /* it will return to our caller */
>>>> +
>>>> + wrteei 1
>>>> +
>>>> +idle_loop:
>>>> + LOAD_REG_IMMEDIATE(r11, HC_VENDOR_EPAPR | HC_EV_IDLE)
>>>> +
>>>> +.global epapr_ev_idle_start
>>>> +epapr_ev_idle_start:
>>>> + li r3, -1
>>>> + nop
>>>> + nop
>>>> + nop
>>>
>>> Can't you just bl into epapr_hypercall_start? You don't even have to save the old lr. because we never return anyways :)
>>
>> The interrupt will branch to LR, so no, we can't trash it or put it
>> anywhere else.
>
> Hrm. But we can clobber ctr, right? So how about we make the generic version do a bctr and then just do a small C wrapper that takes lr, moves it to ctr and branches to the generic one?
If it's just for this, I would say don't mess with the normal hcall path
for the sake of idle. If using CTR would let us get away without
creating a stack frame in call sites, maybe that would be worthwhile,
depending on what sort of hcalls we end up having.
> Then we don't have to replicate the hypercall code all over again for every invocation.
We shouldn't need to do it for every invocation. Idle is special due to
the TLF_NAPPING hack.
-Scott
^ permalink raw reply
* [PATCH 2/2] [v2] powerpc/fsl: add PAMUBYPENR register definition to fsl_guts.h
From: Timur Tabi @ 2012-02-16 17:21 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <1329412870-16716-1-git-send-email-timur@freescale.com>
Add a defintion of register PAMUBYPENR (offset 0x604) to the global
utilities structure.
PAMUBYPENR is the PAMU bypass enable register. It contains control
bits for enabling bypass mode on each PAMU.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/include/asm/fsl_guts.h | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_guts.h b/arch/powerpc/include/asm/fsl_guts.h
index a880377..23e483d 100644
--- a/arch/powerpc/include/asm/fsl_guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -69,7 +69,9 @@ struct ccsr_guts {
u8 res0c4[0x224 - 0xc4];
__be32 iodelay1; /* 0x.0224 - IO delay control register 1 */
__be32 iodelay2; /* 0x.0228 - IO delay control register 2 */
- u8 res22c[0x800 - 0x22c];
+ u8 res22c[0x604 - 0x22c];
+ __be32 pamubypenr; /* 0x.0604 - PAMU bypass enable register */
+ u8 res608[0x800 - 0x608];
__be32 clkdvdr; /* 0x.0800 - Clock Divide Register */
u8 res804[0x900 - 0x804];
__be32 ircr; /* 0x.0900 - Infrared Control Register */
--
1.7.3.4
^ permalink raw reply related
* [PATCH 1/2] powerpc/8xxx: remove 85xx/86xx restrictions from fsl_guts.h
From: Timur Tabi @ 2012-02-16 17:21 UTC (permalink / raw)
To: galak, linuxppc-dev
Remove the check for CONFIG_PPC_85xx and CONFIG_PPC_86xx from fsl_guts.h.
The check was originally intended to allow the same header file to
be used on 85xx and 86xx systems, even though the Global Utilities
register could be different. It turns out that they're not actually
different, and so the check is not necessary. In addition, neither
macro is defined for 64-bit e5500 kernels, so that causes a build
break.
To maintain backwards compatibility, we also define macros for
ccsr_guts_85xx and ccsr_guts_86xx. This eliminates the need to
change all the files that #include fsl_guts.h. Those files will
be updated at a later time, and then the macros can be deleted.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/include/asm/fsl_guts.h | 26 +++++++-------------------
1 files changed, 7 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/include/asm/fsl_guts.h b/arch/powerpc/include/asm/fsl_guts.h
index bebd124..a880377 100644
--- a/arch/powerpc/include/asm/fsl_guts.h
+++ b/arch/powerpc/include/asm/fsl_guts.h
@@ -16,15 +16,6 @@
#define __ASM_POWERPC_FSL_GUTS_H__
#ifdef __KERNEL__
-/*
- * These #ifdefs are safe because it's not possible to build a kernel that
- * runs on e500 and e600 cores.
- */
-
-#if !defined(CONFIG_PPC_85xx) && !defined(CONFIG_PPC_86xx)
-#error Only 85xx and 86xx SOCs are supported
-#endif
-
/**
* Global Utility Registers.
*
@@ -36,11 +27,7 @@
* different names. In these cases, one name is chosen to avoid extraneous
* #ifdefs.
*/
-#ifdef CONFIG_PPC_85xx
-struct ccsr_guts_85xx {
-#else
-struct ccsr_guts_86xx {
-#endif
+struct ccsr_guts {
__be32 porpllsr; /* 0x.0000 - POR PLL Ratio Status Register */
__be32 porbmsr; /* 0x.0004 - POR Boot Mode Status Register */
__be32 porimpscr; /* 0x.0008 - POR I/O Impedance Status and Control Register */
@@ -77,11 +64,8 @@ struct ccsr_guts_86xx {
u8 res0a8[0xb0 - 0xa8];
__be32 rstcr; /* 0x.00b0 - Reset Control Register */
u8 res0b4[0xc0 - 0xb4];
-#ifdef CONFIG_PPC_85xx
- __be32 iovselsr; /* 0x.00c0 - I/O voltage select status register */
-#else
- __be32 elbcvselcr; /* 0x.00c0 - eLBC Voltage Select Ctrl Reg */
-#endif
+ __be32 iovselsr; /* 0x.00c0 - I/O voltage select status register
+ Called 'elbcvselcr' on 86xx SOCs */
u8 res0c4[0x224 - 0xc4];
__be32 iodelay1; /* 0x.0224 - IO delay control register 1 */
__be32 iodelay2; /* 0x.0228 - IO delay control register 2 */
@@ -114,6 +98,10 @@ struct ccsr_guts_86xx {
__be32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
} __attribute__ ((packed));
+/* For backwards-compatibility */
+#define ccsr_guts_85xx ccsr_guts
+#define ccsr_guts_86xx ccsr_guts
+
#ifdef CONFIG_PPC_86xx
#define CCSR_GUTS_DMACR_DEV_SSI 0 /* DMA controller/channel set to SSI */
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH v4 3/3] KVM: PPC: epapr: install ev_idle hcall for e500 guest
From: Alexander Graf @ 2012-02-16 17:18 UTC (permalink / raw)
To: Scott Wood
Cc: <linuxppc-dev@ozlabs.org>, Liu Yu,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>,
<B07421@freescale.com>
In-Reply-To: <4F3D359E.6030209@freescale.com>
On 16.02.2012, at 17:58, Scott Wood wrote:
> On 02/16/2012 04:24 AM, Alexander Graf wrote:
>> On 16.02.2012, at 10:26, Liu Yu <yu.liu@freescale.com> wrote:
>>> +_GLOBAL(epapr_ev_idle)
>>> +epapr_ev_idle:
>>> + rlwinm r3,r1,0,0,31-THREAD_SHIFT /* current thread_info =
*/
>>> + lwz r4,TI_LOCAL_FLAGS(r3) /* set napping bit */
>>> + ori r4,r4,_TLF_NAPPING /* so when we take an exception */
>>> + stw r4,TI_LOCAL_FLAGS(r3) /* it will return to our caller =
*/
>>> +
>>> + wrteei 1
>>> +
>>> +idle_loop:
>>> + LOAD_REG_IMMEDIATE(r11, HC_VENDOR_EPAPR | HC_EV_IDLE)
>>> +
>>> +.global epapr_ev_idle_start
>>> +epapr_ev_idle_start:
>>> + li r3, -1
>>> + nop
>>> + nop
>>> + nop
>>=20
>> Can't you just bl into epapr_hypercall_start? You don't even have to =
save the old lr. because we never return anyways :)
>=20
> The interrupt will branch to LR, so no, we can't trash it or put it
> anywhere else.
Hrm. But we can clobber ctr, right? So how about we make the generic =
version do a bctr and then just do a small C wrapper that takes lr, =
moves it to ctr and branches to the generic one?
Then we don't have to replicate the hypercall code all over again for =
every invocation.
Alex
^ permalink raw reply
* Re: tlb flushing on Power
From: Seth Jennings @ 2012-02-16 17:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Robert Jennings, linuxppc-dev, Nitin Gupta, Dave Hansen
In-Reply-To: <4F356C7E.3070608@linux.vnet.ibm.com>
On 02/10/2012 01:14 PM, Seth Jennings wrote:
> On 02/08/2012 03:04 PM, Benjamin Herrenschmidt wrote:
>>
>>> You can look at https://lkml.org/lkml/2012/1/9/389 in zsmalloc-main.c,
>>> zs_[un]map_object() functions for the currently uses of set_pte() and
>>> __flush_tlb_one().
>>>
>>>> set_pte() is long gone on all archs really (or if it's still there it's
>>>> not meant to be used as is), use set_pte_at().
>>>
>>> Problem with set_pte_at() for us is that we don't have an mm_struct to pass
>>> because the mapping is not for a userspace process but for the kernel itself.
>>
>> Then use init_mm
>
> Thanks, that's what I was looking for.
>
>>> However, I do think this is the portable function we need to be using. Just
>>> need to figure out what to pass in for the mm_struct param.
>>>
>>>> __flush_tlb_one() doesn't mean anything as an arch independent
>>>> functionality. We have a local_flush_tlb_page() that -might- do what you
>>>> want but why in hell is that patch not using proper existing
>>>> interfaces ?
>>>
>>> flush_tlb_page() is the portable function we should be using. However,
>>> again, it requires a vma_area_struct. I'm not sure what we should be
>>> passing there.
>>
>> Do you need this to be CPU local flush or global ? In the later,
>> flush_tlb_kernel_range() is the right API.
>>
>> If you want per-cpu, we'll have to add a new arch hook.
>
> We have interrupts disabled, due to the get_cpu_var() on the percpu variable
> zs_map_area in zs_map_object(), while the allocation is mapped. So a CPU local
> would be what we need.
Hey Ben,
Just wanted to bump you again about this. You mentioned that if I wanted to
do a cpu-local flush of a single tlb entry, that there would have to be a new
hook. Is that right?
I've been looking through the powerpc arch and I thought that I might have
found the power analog to __flush_tlb_one() for x86 in local_flush_tlb_page()
with a NULL vma argument. This doesn't seem to work though, as indicated
by a crash when I tried it. After looking in tlbflush.h again, it seems
that local_flush_tlb_page() is a no-op when CONFIG_PPC_STD_MMU_64 is set,
as are almost ALL of the tlb flushing functions... which makes no sense to
me.
Any help you (or anyone) can give me would be greatly appreciated.
--
Seth
^ permalink raw reply
* Re: [PATCH v4 3/3] KVM: PPC: epapr: install ev_idle hcall for e500 guest
From: Scott Wood @ 2012-02-16 17:14 UTC (permalink / raw)
To: Liu Yu; +Cc: linuxppc-dev, B07421, agraf, kvm-ppc, kvm
In-Reply-To: <1329384365-4028-3-git-send-email-yu.liu@freescale.com>
On 02/16/2012 03:26 AM, Liu Yu wrote:
> If the guest hypervisor node contains "has-idle" property.
>
> Signed-off-by: Liu Yu <yu.liu@freescale.com>
> ---
> v4:
> 1. discard the CONFIG_E500 to make code for all powerpc platform
> 2. code cleanup
Is the TLF_NAPPING stuff supported on all powerpc platforms?
-Scott
^ permalink raw reply
* Re: [PATCH v4 1/3] KVM: PPC: epapr: Factor out the epapr init
From: Scott Wood @ 2012-02-16 17:13 UTC (permalink / raw)
To: Liu Yu; +Cc: linuxppc-dev, B07421, agraf, kvm-ppc, kvm
In-Reply-To: <1329384365-4028-1-git-send-email-yu.liu@freescale.com>
On 02/16/2012 03:26 AM, Liu Yu wrote:
> from the kvm guest paravirt init code.
>
> Signed-off-by: Liu Yu <yu.liu@freescale.com>
> ---
> v4:
> 1. code cleanup
> 2. move kvm_hypercall_start() to epapr_hypercall_start()
>
> arch/powerpc/Kconfig | 4 ++
> arch/powerpc/include/asm/epapr_hcalls.h | 2 +
> arch/powerpc/kernel/Makefile | 1 +
> arch/powerpc/kernel/epapr.S | 25 ++++++++++++++++
> arch/powerpc/kernel/epapr_para.c | 49 +++++++++++++++++++++++++++++++
> arch/powerpc/kernel/kvm.c | 28 ++----------------
> arch/powerpc/kernel/kvm_emul.S | 10 ------
> arch/powerpc/kvm/Kconfig | 1 +
> 8 files changed, 85 insertions(+), 35 deletions(-)
> create mode 100644 arch/powerpc/kernel/epapr.S
> create mode 100644 arch/powerpc/kernel/epapr_para.c
The comment about spelling out "paravirt" wasnn't meant to be restricted
to the kconfig symbol. There are lots of words that begin with "para",
and ePAPR isn't just about virtualization.
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 1919634..1262b43 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -202,6 +202,10 @@ config EPAPR_BOOT
> Used to allow a board to specify it wants an ePAPR compliant wrapper.
> default n
>
> +config EPAPR_PARAVIRT
> + bool
> + default n
Why isn't this user-selectable? It's useful on its own.
> diff --git a/arch/powerpc/kernel/epapr.S b/arch/powerpc/kernel/epapr.S
> new file mode 100644
> index 0000000..697b390
> --- /dev/null
> +++ b/arch/powerpc/kernel/epapr.S
epapr-hcall.S
> +bool epapr_para_enabled = false;
> +
> +static int __init epapr_para_init(void)
> +{
> + struct device_node *hyper_node;
> + const u32 *insts;
> + int len, i;
> +
> + hyper_node = of_find_node_by_path("/hypervisor");
> + if (!hyper_node)
> + return -ENODEV;
> +
> + insts = of_get_property(hyper_node, "hcall-instructions", &len);
> + if (!(len % 4) && (len >= (4 * 4))) {
> + for (i = 0; i < (len / 4); i++)
> + epapr_hypercall_start[i] = insts[i];
> + flush_icache_range((ulong)epapr_hypercall_start,
> + (ulong)epapr_hypercall_start + len);
> +
> + epapr_para_enabled = true;
> + }
Use patch_instruction(), fix the if test, and remove unnecessary
parentheses. Print an error if the if test fails, but return silently
if the property is absent.
Please make asm/epapr_hcalls.h and asm/fsl_hcalls.h work with this as well.
-Scott
^ permalink raw reply
* Re: [PATCH v4 3/3] KVM: PPC: epapr: install ev_idle hcall for e500 guest
From: Scott Wood @ 2012-02-16 16:58 UTC (permalink / raw)
To: Alexander Graf
Cc: <linuxppc-dev@ozlabs.org>, Liu Yu,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>,
<B07421@freescale.com>
In-Reply-To: <EAC043A1-A04F-4A27-8488-3C42D99D175E@suse.de>
On 02/16/2012 04:24 AM, Alexander Graf wrote:
> On 16.02.2012, at 10:26, Liu Yu <yu.liu@freescale.com> wrote:
>> +_GLOBAL(epapr_ev_idle)
>> +epapr_ev_idle:
>> + rlwinm r3,r1,0,0,31-THREAD_SHIFT /* current thread_info */
>> + lwz r4,TI_LOCAL_FLAGS(r3) /* set napping bit */
>> + ori r4,r4,_TLF_NAPPING /* so when we take an exception */
>> + stw r4,TI_LOCAL_FLAGS(r3) /* it will return to our caller */
>> +
>> + wrteei 1
>> +
>> +idle_loop:
>> + LOAD_REG_IMMEDIATE(r11, HC_VENDOR_EPAPR | HC_EV_IDLE)
>> +
>> +.global epapr_ev_idle_start
>> +epapr_ev_idle_start:
>> + li r3, -1
>> + nop
>> + nop
>> + nop
>
> Can't you just bl into epapr_hypercall_start? You don't even have to save the old lr. because we never return anyways :)
The interrupt will branch to LR, so no, we can't trash it or put it
anywhere else.
-scott
^ permalink raw reply
* Re: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Greg KH @ 2012-02-16 16:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linux-usb, linuxppc-dev, Shengzhou Liu
In-Reply-To: <1329388755.2892.15.camel@pasglop>
On Thu, Feb 16, 2012 at 09:39:15PM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2012-02-16 at 18:02 +0800, Shengzhou Liu wrote:
> > If USB UTMI PHY is not enable, writing to portsc register will lead to
> > kernel hang during boot up.
>
> Thanks, I'll try that tomorrow.
>
> Greg, you're picking that up or should I ?
I can, if you let me know that this fixes your problem :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] arch/powerpc/kvm/book3s_hv.c: included linux/sched.h twice
From: Avi Kivity @ 2012-02-16 16:09 UTC (permalink / raw)
To: Danny Kukawka
Cc: kvm, Marcelo Tosatti, Danny Kukawka, Alexander Graf, kvm-ppc,
linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <1329400554-31904-1-git-send-email-danny.kukawka@bisect.de>
On 02/16/2012 03:55 PM, Danny Kukawka wrote:
> arch/powerpc/kvm/book3s_hv.c: included 'linux/sched.h' twice,
> remove the duplicate.
>
Thanks, applied.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Tabi Timur-B04825 @ 2012-02-16 15:56 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1329394210-1014-1-git-send-email-leoli@freescale.com>
On Thu, Feb 16, 2012 at 6:10 AM, Li Yang <leoli@freescale.com> wrote:
>
> The reason why we need to keep PHYS_64BIT option configurable is
> that enabling it cause negative performance impact on various
> aspects like TLB miss and physical address manipulating. =A0We should
> not enable it unless really needed, e.g. use large memory of 4GB
> or bigger.
I think we should make 36-bit the only option for the upstream
defconfigs, and if we want a 32-bit "optimized" kernel for the SDK,
then we provide that on the SDK only.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Tabi Timur-B04825 @ 2012-02-16 15:57 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <CAOZdJXX6sY4MxsqhjJZf26vrDxu6pxh2DtCqEERJ5JxbBFjEKA@mail.gmail.com>
On Thu, Feb 16, 2012 at 9:56 AM, Tabi Timur-B04825 <b04825@freescale.com> w=
rote:
> I think we should make 36-bit the only option for the upstream
> defconfigs, and if we want a 32-bit "optimized" kernel for the SDK,
> then we provide that on the SDK only.
Oops, I meant to post this as a reply to "powerpc/85xx: add a 36-bit
corenet default config".
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* [PATCH] arch/powerpc/platforms/powernv/setup.c: included asm/xics.h twice
From: Danny Kukawka @ 2012-02-16 13:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Mackerras, Danny Kukawka, linuxppc-dev, linux-kernel
arch/powerpc/platforms/powernv/setup.c: included 'asm/xics.h' twice,
remove the duplicate.
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
---
arch/powerpc/platforms/powernv/setup.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
index 467bd4a..db1ad1c 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -31,7 +31,6 @@
#include <asm/xics.h>
#include <asm/rtas.h>
#include <asm/opal.h>
-#include <asm/xics.h>
#include "powernv.h"
--
1.7.8.3
^ permalink raw reply related
* [PATCH] arch/powerpc/kvm/book3s_hv.c: included linux/sched.h twice
From: Danny Kukawka @ 2012-02-16 13:55 UTC (permalink / raw)
To: Avi Kivity
Cc: kvm, Marcelo Tosatti, Danny Kukawka, Alexander Graf, kvm-ppc,
linux-kernel, Paul Mackerras, linuxppc-dev
arch/powerpc/kvm/book3s_hv.c: included 'linux/sched.h' twice,
remove the duplicate.
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
---
arch/powerpc/kvm/book3s_hv.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 336983d..a726716 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -46,7 +46,6 @@
#include <asm/page.h>
#include <asm/hvcall.h>
#include <linux/gfp.h>
-#include <linux/sched.h>
#include <linux/vmalloc.h>
#include <linux/highmem.h>
--
1.7.8.3
^ permalink raw reply related
* Re: [PATCH v5 08/27] irq_domain: Move irq_domain code from powerpc to kernel/irq
From: Grant Likely @ 2012-02-16 13:23 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, devicetree-discuss, linux-arm-kernel,
Benjamin Herrenschmidt, Thomas Gleixner, Milton Miller,
Rob Herring
In-Reply-To: <1329383368-12122-9-git-send-email-grant.likely@secretlab.ca>
On Thu, Feb 16, 2012 at 2:09 AM, Grant Likely <grant.likely@secretlab.ca> w=
rote:
> This patch only moves the code. =A0It doesn't make any changes, and the
> code is still only compiled for powerpc. =A0Follow-on patches will genera=
lize
> the code for other architectures.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Milton Miller <miltonm@bga.com>
> Tested-by: Olof Johansson <olof@lixom.net>
> ---
> +unsigned int irq_find_mapping(struct irq_domain *host,
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 irq_hw_number_t=
hwirq)
> +{
> + =A0 =A0 =A0 unsigned int i;
> + =A0 =A0 =A0 unsigned int hint =3D hwirq % irq_virq_count;
> +
> + =A0 =A0 =A0 /* Look for default host if nececssary */
> + =A0 =A0 =A0 if (host =3D=3D NULL)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 host =3D irq_default_host;
> + =A0 =A0 =A0 if (host =3D=3D NULL)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return NO_IRQ;
> +
> + =A0 =A0 =A0 /* legacy -> bail early */
> + =A0 =A0 =A0 if (host->revmap_type =3D=3D IRQ_DOMAIN_MAP_LEGACY)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return hwirq;
> +
> + =A0 =A0 =A0 /* Slow path does a linear search of the map */
> + =A0 =A0 =A0 if (hint =3D=3D 0)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 hint =3D 1;
> + =A0 =A0 =A0 i =3D hint;
> + =A0 =A0 =A0 do {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct irq_data *data =3D irq_get_irq_data(=
i);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (data && (data->domain =3D=3D host) && (=
data->hwirq =3D=3D hwirq))
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return i;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 i++;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (i >=3D irq_virq_count)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i =3D 1
Typo on this line; missing semicolon. Fixed in my tree now.
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