* 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
* 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: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 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: 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 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 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: 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 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: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: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: tlb flushing on Power
From: Benjamin Herrenschmidt @ 2012-02-16 20:31 UTC (permalink / raw)
To: Seth Jennings; +Cc: Robert Jennings, linuxppc-dev, Nitin Gupta, Dave Hansen
In-Reply-To: <4F3D38D3.4020903@linux.vnet.ibm.com>
On Thu, 2012-02-16 at 11:11 -0600, Seth Jennings wrote:
> 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.
On ppc64 with hash-table MMU, we handle the flushes very differently.
PTEs that are modified are added to a list at the time of the
modification and either flushed immediately if no lazy tlb batching is
in progress or flushed when leaving the lazy tlb op.
This is to avoid a problem where we might otherwise, under some
circumstances, create a new TLB which can be hashed in to the hash table
before the previous one has been flushed out. That would lead to a dup
in the hash table which is architecturally illegal.
This happens via the call to hpte_need_flush() in pte_update().
Unfortunately, it will always consider all kernel mappings as global,
so the per-cpu "optimization" won't be usable in this case, at least
not until we add some kind of additional argument to that function.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2 v5] powerpc/85xx: Add Quicc Engine support for p1025rdb
From: Tabi Timur-B04825 @ 2012-02-16 21:05 UTC (permalink / raw)
To: Fan Zhicheng-B32736; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329289091-26231-1-git-send-email-B32736@freescale.com>
On Wed, Feb 15, 2012 at 12:58 AM, Zhicheng Fan <B32736@freescale.com> wrote=
:
> From: Zhicheng Fan <b32736@freescale.com>
>
> Signed-off-by: Zhicheng Fan <b32736@freescale.com>
> ---
Acked-by: Timur Tabi <timur@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH 2/2 v4] powerpc/dts: Add dts for p1025rdb board
From: Tabi Timur-B04825 @ 2012-02-16 21:06 UTC (permalink / raw)
To: Fan Zhicheng-B32736; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329206783-12190-2-git-send-email-B32736@freescale.com>
On Tue, Feb 14, 2012 at 2:06 AM, Zhicheng Fan <B32736@freescale.com> wrote:
> From: Zhicheng Fan <b32736@freescale.com>
>
> P1025RDB Overview
> ------------------
> 1Gbyte DDR3 SDRAM
> 32 Mbyte NAND flash
> 16Mbyte NOR flash
> 16 Mbyte SPI flash
> SD connector to interface with the SD memory card
> Real-time clock on I2C bus
>
> PCIe:
> - x1 PCIe slot
> - x1 mini-PCIe slot
>
> 10/100/1000 BaseT Ethernet ports:
> - eTSEC1, RGMII: one 10/100/1000 port using AtherosTM AR8021
> - eTSEC2, SGMII: one 10/100/1000 port using VitesseTM VSC8221
> - eTSEC3, RGMII: one 10/100/1000 port using AtherosTM AR8021
>
> USB 2.0 port:
> - Two USB2.0 Type A receptacles
> - One USB2.0 signal to Mini PCIe slot
>
> Dual RJ45 UART ports:
> - DUART interface: supports two UARTs up to 115200 bps for console displa=
y
>
> Signed-off-by: Zhicheng Fan <b32736@freescale.com>
> ---
Acked-by: Timur Tabi <timur@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH 1/2 v4] powerpc/85xx: Add p1025rdb platform support
From: Tabi Timur-B04825 @ 2012-02-16 21:07 UTC (permalink / raw)
To: Fan Zhicheng-B32736; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1329206783-12190-1-git-send-email-B32736@freescale.com>
On Tue, Feb 14, 2012 at 2:06 AM, Zhicheng Fan <B32736@freescale.com> wrote:
> From: Zhicheng Fan <b32736@freescale.com>
>
> Signed-off-by: Zhicheng Fan <b32736@freescale.com>
> ---
Acked-by: Timur Tabi <timur@freescale.com>
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ permalink raw reply
* Re: [PATCH v5 00/27] irq_domain generalization and rework
From: Andrew Morton @ 2012-02-16 22:52 UTC (permalink / raw)
To: Grant Likely
Cc: Russell King, devicetree-discuss, linux-kernel, Milton Miller,
Rob Herring, Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1329383368-12122-1-git-send-email-grant.likely@secretlab.ca>
On Thu, 16 Feb 2012 02:09:01 -0700
Grant Likely <grant.likely@secretlab.ca> wrote:
>
> This series generalizes the "irq_host" infrastructure from powerpc
> so that it can be used by all architectures and renames it to "irq_domain".
drivers/mfd/twl-core.c is fairly horked on i386 allmodconfig:
drivers/mfd/twl-core.c: In function 'twl_probe':
drivers/mfd/twl-core.c:1218: error: implicit declaration of function 'irq_alloc_descs'
drivers/mfd/twl-core.c:1226: error: implicit declaration of function 'irq_domain_add_legacy'
drivers/mfd/twl-core.c:1227: error: 'irq_domain_simple_ops' undeclared (first use in this function)
drivers/mfd/twl-core.c:1227: error: (Each undeclared identifier is reported only once
drivers/mfd/twl-core.c:1227: error: for each function it appears in.)
This is today's linux-next so it has rmk's "ARM: omap: fix broken
twl-core dependencies and ifdefs" in there, which looks like it
attempts to repair this stuff.
It's looking for things which are in both linux/irq.h and in
linux/irqdomain.h.
btw, Russell, regarding this comment in include/linux/irq.h:
/*
* Please do not include this file in generic code. There is currently
* no requirement for any architecture to implement anything held
* within this file.
*
* Thanks. --rmk
*/
A quick grep indicates that we've lost this battle ;) Is the comments
still true? Should we stop discouraging inclusion of linux/irq.h?
Does anyone even know that it's discouraged ;)
^ permalink raw reply
* Re: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Benjamin Herrenschmidt @ 2012-02-16 22:58 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <1329386540-12341-1-git-send-email-Shengzhou.Liu@freescale.com>
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.
>
> Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> ---
> Apply for master branch of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Tested on P5020DS, the issue was reported by Benjamin Herrenschmidt.
This fixes the hang, but sadly doesn't make USB work. I now get:
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
/soc@ffe000000/usb@210000: Invalid 'dr_mode' property, fallback to host mode
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 44, io mem 0xffe210000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
fsl-ehci fsl-ehci.1: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.1: new USB bus registered, assigned bus number 2
fsl-ehci fsl-ehci.1: irq 45, io mem 0xffe211000
fsl-ehci fsl-ehci.1: USB 2.0 started, EHCI 1.00
.../...
usb 1-1: device descriptor read/64, error -110
usb 1-1: device descriptor read/64, error -110
<remove device, re-plug it>
usb 1-1: new full-speed USB device number 3 using fsl-ehci
hub 1-0:1.0: unable to enumerate USB device on port 1
<remove again, re-plug it>
usb 1-1: new full-speed USB device number 4 using fsl-ehci
usb 1-1: device descriptor read/64, error -110
The blurb about "invalid dr_mode property" makes me think there's some
kind of disagreement between the device-tree coming with the machine and
what upstream expects. Basically the DT doesn't contain a dr_mode
property at all (which should be fine, host mode is what I want, but I
suspect some stuff aren't being configured properly by u-boot either...)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v5 00/27] irq_domain generalization and rework
From: Russell King - ARM Linux @ 2012-02-16 23:26 UTC (permalink / raw)
To: Andrew Morton
Cc: devicetree-discuss, linux-kernel, Milton Miller, Rob Herring,
Thomas Gleixner, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120216145219.0f1c1b98.akpm@linux-foundation.org>
On Thu, Feb 16, 2012 at 02:52:19PM -0800, Andrew Morton wrote:
> On Thu, 16 Feb 2012 02:09:01 -0700
> Grant Likely <grant.likely@secretlab.ca> wrote:
> > This series generalizes the "irq_host" infrastructure from powerpc
> > so that it can be used by all architectures and renames it to "irq_domain".
>
> drivers/mfd/twl-core.c is fairly horked on i386 allmodconfig:
>
> drivers/mfd/twl-core.c: In function 'twl_probe':
> drivers/mfd/twl-core.c:1218: error: implicit declaration of function 'irq_alloc_descs'
> drivers/mfd/twl-core.c:1226: error: implicit declaration of function 'irq_domain_add_legacy'
> drivers/mfd/twl-core.c:1227: error: 'irq_domain_simple_ops' undeclared (first use in this function)
> drivers/mfd/twl-core.c:1227: error: (Each undeclared identifier is reported only once
> drivers/mfd/twl-core.c:1227: error: for each function it appears in.)
>
> This is today's linux-next so it has rmk's "ARM: omap: fix broken
> twl-core dependencies and ifdefs" in there, which looks like it
> attempts to repair this stuff.
Yes, you're the third to report this breakage.
Grant's response on Tuesday over this was:
| This is irq_domain related. It's related to an API change. I'm
| tracking to get it solved, either by moving the twl commit into the
| irqdomain branch or by deferring the api change to v3.5.
|
| I've also got a patch that converts x86 over to the new api, but I
| don't have sufficient review to put it into the irqdomain tree yet.
> btw, Russell, regarding this comment in include/linux/irq.h:
>
> /*
> * Please do not include this file in generic code. There is currently
> * no requirement for any architecture to implement anything held
> * within this file.
> *
> * Thanks. --rmk
> */
>
> A quick grep indicates that we've lost this battle ;) Is the comments
> still true? Should we stop discouraging inclusion of linux/irq.h?
> Does anyone even know that it's discouraged ;)
It's still true for any platform which hasn't been converted to genirq,
as such a platform would not have asm/hw_irq.h. That said, since
genirq, it's now necessary for any driver which contains interrupt
controller code like GPIO drivers. So I suspect the comment should now
be lost, even though it's not really a replacement for asm/irq.h.
^ permalink raw reply
* Re: [PATCH] powerpc/usb: fix bug of kernel hang when initializing usb
From: Benjamin Herrenschmidt @ 2012-02-17 0:02 UTC (permalink / raw)
To: Shengzhou Liu; +Cc: linux-usb, linuxppc-dev
In-Reply-To: <1329433132.2892.30.camel@pasglop>
On Fri, 2012-02-17 at 09:58 +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.
> >
> > Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
> > ---
> > Apply for master branch of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > Tested on P5020DS, the issue was reported by Benjamin Herrenschmidt.
>
> This fixes the hang, but sadly doesn't make USB work. I now get:
.../...
Ok, found the problem.
First, the SDK kernel had a delay after setting that bit, I added that
back in. This is not what fixed it but it looks like the right thing to
do, though please, use msleep rather than udelay here if possible (not
in atomic context).
Then, the real culprit is (CC'ing Kumar and Scott to figure out why)
this statement:
#if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
/*
* Turn on cache snooping hardware, since some PowerPC platforms
* wholly rely on hardware to deal with cache coherent
*/
/* Setup Snooping for all the 4GB space */
/* SNOOP1 starts from 0x0, size 2G */
out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
/* SNOOP2 starts from 0x80000000, size 2G */
out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
#endif
I'm building a 64-bit kernel so this isn't compiled and it looks like
the EHCI is thus not snooping.
By removing the defined(CONFIG_PPC32) part of the statement, my problem
goes away.
Cheers,
Ben.
^ permalink raw reply
* 5020 SATA fix
From: Benjamin Herrenschmidt @ 2012-02-17 0:29 UTC (permalink / raw)
To: Xulei; +Cc: linuxppc-dev
Hi Lei !
In your SDK kernel I see this commit:
92c0ce1e599e788ffc0908739db9bd5e0dbdad69
sata_fsl: Add the workaround for SATA-A005 erratum on P2040/P3041/P5020
Without this commit, SATA doesn't work on the p5020ds board that FSL
just sent me. I see this was committed in June last year, any reason why
this is not upstream yet ?
Any objection to me just sending it upstream ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Benjamin Herrenschmidt @ 2012-02-17 0:40 UTC (permalink / raw)
To: Qiang Liu; +Cc: linux-ide, jgarzik, linuxppc-dev, linux-kernel
In-Reply-To: <1329284944-17943-1-git-send-email-qiang.liu@freescale.com>
On Wed, 2012-02-15 at 13:49 +0800, Qiang Liu wrote:
]
> diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
> index 0120b0d..d6577b9 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
> @@ -26,6 +26,15 @@
> #include <asm/io.h>
> #include <linux/of_platform.h>
>
> +static unsigned int intr_coalescing_count;
> +module_param(intr_coalescing_count, int, S_IRUGO);
> +MODULE_PARM_DESC(intr_coalescing_count,
> + "INT coalescing count threshold (1..31)");
> +
> +static unsigned int intr_coalescing_ticks;
> +module_param(intr_coalescing_ticks, int, S_IRUGO);
> +MODULE_PARM_DESC(intr_coalescing_ticks,
> + "INT coalescing timer threshold in AHB ticks");
You don't seem to provide very useful defaults... for example,
intr_coalescing_count starts at 0 which isn't even in range
(the code fixes that up but still...).
I tried a debian install on the p5020ds here and I find SATA to be
extremely slow, generating millions of interrupts. I think the defaults
should be a lot more aggressive at coalescing.
Cheers,
Ben.
> /* Controller information */
> enum {
> SATA_FSL_QUEUE_DEPTH = 16,
> @@ -83,6 +92,16 @@ enum {
> };
>
> /*
> + * Interrupt Coalescing Control Register bitdefs */
> +enum {
> + ICC_MIN_INT_COUNT_THRESHOLD = 1,
> + ICC_MAX_INT_COUNT_THRESHOLD = ((1 << 5) - 1),
> + ICC_MIN_INT_TICKS_THRESHOLD = 0,
> + ICC_MAX_INT_TICKS_THRESHOLD = ((1 << 19) - 1),
> + ICC_SAFE_INT_TICKS = 1,
> +};
> +
> +/*
> * Host Controller command register set - per port
> */
> enum {
> @@ -263,8 +282,65 @@ struct sata_fsl_host_priv {
> void __iomem *csr_base;
> int irq;
> int data_snoop;
> + struct device_attribute intr_coalescing;
> };
>
> +static void fsl_sata_set_irq_coalescing(struct ata_host *host,
> + unsigned int count, unsigned int ticks)
> +{
> + struct sata_fsl_host_priv *host_priv = host->private_data;
> + void __iomem *hcr_base = host_priv->hcr_base;
> +
> + if (count > ICC_MAX_INT_COUNT_THRESHOLD)
> + count = ICC_MAX_INT_COUNT_THRESHOLD;
> + else if (count < ICC_MIN_INT_COUNT_THRESHOLD)
> + count = ICC_MIN_INT_COUNT_THRESHOLD;
> +
> + if (ticks > ICC_MAX_INT_TICKS_THRESHOLD)
> + ticks = ICC_MAX_INT_TICKS_THRESHOLD;
> + else if ((ICC_MIN_INT_TICKS_THRESHOLD == ticks) &&
> + (count > ICC_MIN_INT_COUNT_THRESHOLD))
> + ticks = ICC_SAFE_INT_TICKS;
> +
> + spin_lock(&host->lock);
> + iowrite32((count << 24 | ticks), hcr_base + ICC);
> +
> + intr_coalescing_count = count;
> + intr_coalescing_ticks = ticks;
> + spin_unlock(&host->lock);
> +
> + DPRINTK("intrrupt coalescing, count = 0x%x, ticks = %x\n",
> + intr_coalescing_count, intr_coalescing_ticks);
> + DPRINTK("ICC register status: (hcr base: 0x%x) = 0x%x\n",
> + hcr_base, ioread32(hcr_base + ICC));
> +}
> +
> +static ssize_t fsl_sata_intr_coalescing_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d %d\n",
> + intr_coalescing_count, intr_coalescing_ticks);
> +}
> +
> +static ssize_t fsl_sata_intr_coalescing_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + unsigned int coalescing_count, coalescing_ticks;
> +
> + if (sscanf(buf, "%d%d",
> + &coalescing_count,
> + &coalescing_ticks) != 2) {
> + printk(KERN_ERR "fsl-sata: wrong parameter format.\n");
> + return -EINVAL;
> + }
> +
> + fsl_sata_set_irq_coalescing(dev_get_drvdata(dev),
> + coalescing_count, coalescing_ticks);
> +
> + return strlen(buf);
> +}
> +
> static inline unsigned int sata_fsl_tag(unsigned int tag,
> void __iomem *hcr_base)
> {
> @@ -346,10 +422,10 @@ static unsigned int sata_fsl_fill_sg(struct ata_queued_cmd *qc, void *cmd_desc,
> (unsigned long long)sg_addr, sg_len);
>
> /* warn if each s/g element is not dword aligned */
> - if (sg_addr & 0x03)
> + if (unlikely(sg_addr & 0x03))
> ata_port_err(qc->ap, "s/g addr unaligned : 0x%llx\n",
> (unsigned long long)sg_addr);
> - if (sg_len & 0x03)
> + if (unlikely(sg_len & 0x03))
> ata_port_err(qc->ap, "s/g len unaligned : 0x%x\n",
> sg_len);
>
> @@ -1245,6 +1321,13 @@ static int sata_fsl_init_controller(struct ata_host *host)
> iowrite32(0x00000FFFF, hcr_base + CE);
> iowrite32(0x00000FFFF, hcr_base + DE);
>
> + /*
> + * reset the number of command complete bits which will cause the
> + * interrupt to be signaled
> + */
> + fsl_sata_set_irq_coalescing(host, intr_coalescing_count,
> + intr_coalescing_ticks);
> +
> /*
> * host controller will be brought on-line, during xx_port_start()
> * callback, that should also initiate the OOB, COMINIT sequence
> @@ -1309,7 +1392,7 @@ static int sata_fsl_probe(struct platform_device *ofdev)
> void __iomem *csr_base = NULL;
> struct sata_fsl_host_priv *host_priv = NULL;
> int irq;
> - struct ata_host *host;
> + struct ata_host *host = NULL;
> u32 temp;
>
> struct ata_port_info pi = sata_fsl_port_info[0];
> @@ -1356,6 +1439,10 @@ static int sata_fsl_probe(struct platform_device *ofdev)
>
> /* allocate host structure */
> host = ata_host_alloc_pinfo(&ofdev->dev, ppi, SATA_FSL_MAX_PORTS);
> + if (!host) {
> + retval = -ENOMEM;
> + goto error_exit_with_cleanup;
> + }
>
> /* host->iomap is not used currently */
> host->private_data = host_priv;
> @@ -1373,10 +1460,24 @@ static int sata_fsl_probe(struct platform_device *ofdev)
>
> dev_set_drvdata(&ofdev->dev, host);
>
> + host_priv->intr_coalescing.show = fsl_sata_intr_coalescing_show;
> + host_priv->intr_coalescing.store = fsl_sata_intr_coalescing_store;
> + sysfs_attr_init(&host_priv->intr_coalescing.attr);
> + host_priv->intr_coalescing.attr.name = "intr_coalescing";
> + host_priv->intr_coalescing.attr.mode = S_IRUGO | S_IWUSR;
> + retval = device_create_file(host->dev, &host_priv->intr_coalescing);
> + if (retval)
> + goto error_exit_with_cleanup;
> +
> return 0;
>
> error_exit_with_cleanup:
>
> + if (host) {
> + dev_set_drvdata(&ofdev->dev, NULL);
> + ata_host_detach(host);
> + }
> +
> if (hcr_base)
> iounmap(hcr_base);
> if (host_priv)
> @@ -1390,6 +1491,8 @@ static int sata_fsl_remove(struct platform_device *ofdev)
> struct ata_host *host = dev_get_drvdata(&ofdev->dev);
> struct sata_fsl_host_priv *host_priv = host->private_data;
>
> + device_remove_file(&ofdev->dev, &host_priv->intr_coalescing);
> +
> ata_host_detach(host);
>
> dev_set_drvdata(&ofdev->dev, NULL);
> --
> 1.6.4
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
From: Ira W. Snyder @ 2012-02-17 0:57 UTC (permalink / raw)
To: Timur Tabi; +Cc: Dan Williams, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4F3D5D84.2040609@freescale.com>
On Thu, Feb 16, 2012 at 01:48:20PM -0600, Timur Tabi wrote:
> 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.
>
I tried both with and without this patch on my P2020 COM Express board.
With both kernels, the board locks up after 20 minutes or so, no
messages to the serial console.
I wouldn't be surprised if there are some memory problems with this
board. In any case, I don't have any reason to believe that this patch
causes any trouble: the board dies without it.
However, the patch doesn't break DMA on 85xx. If I unload the dmatest
module after 10 minutes or so, it claims to have passed many thousands
of tests without problems.
My 8349EA test boards (15 of them) have been running their normal DMA
workload plus dmatest on the unused 4th channel, all without errors, for
several hours. ~2.5 million successful tests per board, as I write this.
Ira
^ permalink raw reply
* Re: 5020 SATA fix
From: Kumar Gala @ 2012-02-17 1:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Xulei, linuxppc-dev
In-Reply-To: <1329438578.2892.34.camel@pasglop>
On Feb 16, 2012, at 6:29 PM, Benjamin Herrenschmidt wrote:
> Hi Lei !
>=20
> In your SDK kernel I see this commit:
>=20
> 92c0ce1e599e788ffc0908739db9bd5e0dbdad69
> sata_fsl: Add the workaround for SATA-A005 erratum on =
P2040/P3041/P5020
>=20
> Without this commit, SATA doesn't work on the p5020ds board that FSL
> just sent me. I see this was committed in June last year, any reason =
why
> this is not upstream yet ?
>=20
> Any objection to me just sending it upstream ?
>=20
> Cheers,
> Ben.
>=20
In general we've avoided sending erratum fixes for non-production =
silicon upstream.
- k
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
From: Kumar Gala @ 2012-02-17 1:27 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1329394210-1014-1-git-send-email-leoli@freescale.com>
On Feb 16, 2012, at 6:10 AM, Li Yang wrote:
> Fix the problem that large physical address support cannot be
> disabled when some platforms which only provides 36-bit support
> are selected. According to the philosophy of kernel config
> enabling a platform support doesn't mean the kernel is only
> running on that platform. Remove the auto selection of PHYS_64BIT
> option for these platforms. They will need to use a 36bit default
> config that selects PHYS_64BIT explicitly.
>=20
> 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. We should
> not enable it unless really needed, e.g. use large memory of 4GB
> or bigger.
>=20
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/platforms/85xx/Kconfig | 6 ------
> 1 files changed, 0 insertions(+), 6 deletions(-)
Nak, this isn't correct.
For some of these platforms like P2041RDB, P3041DS, P3060QDS, P4080DS, & =
P5020DS only a 36-bit physical address map is supported by u-boot and =
the device tree. This was a decision that was made to NOT support =
32-bit address map for these boards and accept the performance =
implication of it to reduce the # of builds, etc.
Additionally, outside of maybe P2041RDB I believe the majority of these =
boards ship with 4G of DDR (but that off the top of my head) and thus =
require the 36-bit / PHYS_64BIT support to be enabled.
- k
^ permalink raw reply
* RE: [PATCH V2 RESEND] fsl-sata: I/O load balancing
From: Liu Qiang-B32616 @ 2012-02-17 1:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ide@vger.kernel.org, jgarzik@pobox.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1329439216.2892.36.camel@pasglop>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW5qYW1pbiBIZXJyZW5zY2ht
aWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jhc2hpbmcub3JnXQ0KPiBTZW50OiBGcmlkYXksIEZl
YnJ1YXJ5IDE3LCAyMDEyIDg6NDAgQU0NCj4gVG86IExpdSBRaWFuZy1CMzI2MTYNCj4gQ2M6IGpn
YXJ6aWtAcG9ib3guY29tOyBsaW51eC1pZGVAdmdlci5rZXJuZWwub3JnOyBsaW51eHBwYy0NCj4g
ZGV2QGxpc3RzLm96bGFicy5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcNCj4gU3Vi
amVjdDogUmU6IFtQQVRDSCBWMiBSRVNFTkRdIGZzbC1zYXRhOiBJL08gbG9hZCBiYWxhbmNpbmcN
Cj4gDQo+IE9uIFdlZCwgMjAxMi0wMi0xNSBhdCAxMzo0OSArMDgwMCwgUWlhbmcgTGl1IHdyb3Rl
Og0KPiBdDQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvYXRhL3NhdGFfZnNsLmMgYi9kcml2ZXJz
L2F0YS9zYXRhX2ZzbC5jIGluZGV4DQo+ID4gMDEyMGIwZC4uZDY1NzdiOSAxMDA2NDQNCj4gPiAt
LS0gYS9kcml2ZXJzL2F0YS9zYXRhX2ZzbC5jDQo+ID4gKysrIGIvZHJpdmVycy9hdGEvc2F0YV9m
c2wuYw0KPiA+IEBAIC02LDcgKzYsNyBAQA0KPiA+ICAgKiBBdXRob3I6IEFzaGlzaCBLYWxyYSA8
YXNoaXNoLmthbHJhQGZyZWVzY2FsZS5jb20+DQo+ID4gICAqIExpIFlhbmcgPGxlb2xpQGZyZWVz
Y2FsZS5jb20+DQo+ID4gICAqDQo+ID4gLSAqIENvcHlyaWdodCAoYykgMjAwNi0yMDA3LCAyMDEx
IEZyZWVzY2FsZSBTZW1pY29uZHVjdG9yLCBJbmMuDQo+ID4gKyAqIENvcHlyaWdodCAoYykgMjAw
Ni0yMDA3LCAyMDExLTIwMTIgRnJlZXNjYWxlIFNlbWljb25kdWN0b3IsIEluYy4NCj4gPiAgICoN
Cj4gPiAgICogVGhpcyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmli
dXRlICBpdCBhbmQvb3INCj4gbW9kaWZ5IGl0DQo+ID4gICAqIHVuZGVyICB0aGUgdGVybXMgb2Yg
IHRoZSBHTlUgR2VuZXJhbCAgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkDQo+ID4gYnkgdGhl
IEBAIC0yNiw2ICsyNiwxNSBAQCAgI2luY2x1ZGUgPGFzbS9pby5oPiAgI2luY2x1ZGUNCj4gPiA8
bGludXgvb2ZfcGxhdGZvcm0uaD4NCj4gPg0KPiA+ICtzdGF0aWMgdW5zaWduZWQgaW50IGludHJf
Y29hbGVzY2luZ19jb3VudDsNCj4gPiArbW9kdWxlX3BhcmFtKGludHJfY29hbGVzY2luZ19jb3Vu
dCwgaW50LCBTX0lSVUdPKTsNCj4gPiArTU9EVUxFX1BBUk1fREVTQyhpbnRyX2NvYWxlc2Npbmdf
Y291bnQsDQo+ID4gKwkJCQkgIklOVCBjb2FsZXNjaW5nIGNvdW50IHRocmVzaG9sZCAoMS4uMzEp
Iik7DQo+ID4gKw0KPiA+ICtzdGF0aWMgdW5zaWduZWQgaW50IGludHJfY29hbGVzY2luZ190aWNr
czsNCj4gPiArbW9kdWxlX3BhcmFtKGludHJfY29hbGVzY2luZ190aWNrcywgaW50LCBTX0lSVUdP
KTsNCj4gPiArTU9EVUxFX1BBUk1fREVTQyhpbnRyX2NvYWxlc2NpbmdfdGlja3MsDQo+ID4gKwkJ
CQkgIklOVCBjb2FsZXNjaW5nIHRpbWVyIHRocmVzaG9sZCBpbiBBSEIgdGlja3MiKTsNCj4gDQo+
IFlvdSBkb24ndCBzZWVtIHRvIHByb3ZpZGUgdmVyeSB1c2VmdWwgZGVmYXVsdHMuLi4gZm9yIGV4
YW1wbGUsDQo+IGludHJfY29hbGVzY2luZ19jb3VudCBzdGFydHMgYXQgMCB3aGljaCBpc24ndCBl
dmVuIGluIHJhbmdlICh0aGUgY29kZQ0KPiBmaXhlcyB0aGF0IHVwIGJ1dCBzdGlsbC4uLikuDQo+
IA0KPiBJIHRyaWVkIGEgZGViaWFuIGluc3RhbGwgb24gdGhlIHA1MDIwZHMgaGVyZSBhbmQgSSBm
aW5kIFNBVEEgdG8gYmUNCj4gZXh0cmVtZWx5IHNsb3csIGdlbmVyYXRpbmcgbWlsbGlvbnMgb2Yg
aW50ZXJydXB0cy4gSSB0aGluayB0aGUgZGVmYXVsdHMNCj4gc2hvdWxkIGJlIGEgbG90IG1vcmUg
YWdncmVzc2l2ZSBhdCBjb2FsZXNjaW5nLg0KDQpIZWxsbyBCZW4sDQoNClRoZSBkZWZhdWx0IHdp
bGwgYmUgc2V0IGluIGEgY29tbW9uIGludGVyZmFjZSBmc2xfc2F0YV9zZXRfaXJxX2NvYWxlc2Np
bmcgd2hlbg0KaW5pdGlhbGl6ZSB0aGUgY29udHJvbGxlci4gVGhpcyBpbnRlcmZhY2Ugd2lsbCBj
aGVjayB0aGUgcmFuZ2Ugb2YgaW50ciBjb3VudA0KYW5kIHRpY2tzIGFuZCBtYWtlIHN1cmUgdGhl
IHZhbHVlcyBhcmUgcmVhc29uYWJseS4NCg0KSXQncyBoYXJkIHRvIGZpbmQgYSBhZ2dyZXNzaXZl
IHZhbHVlIHRvIGFkYXB0IGFsbCBzY2VuYXJpb3MsIHNvIEkgdXNlIGVjaG8gdG8gYWRqdXN0DQp0
aGUgdmFsdWUuIEkgcmVtZW1iZXIgUDUwMjAgaGF2ZSBzb21lIHBlcmZvcm1hbmNlIGlzc3VlLCBJ
IHdpbGwgY2hlY2sgaXQuDQpCVFcsIHdoaWNoIGZpbGVzeXN0ZW0gZG8geW91IHVzZT8gRXh0MiBp
cyBsb3dlciB0aGFuIGV4dDQgYmVjYXVzZSBtZXRhZGF0YSBpcyANCmNvbnRpbnVvdXNseSB3cm90
ZSB0byBkaXNrLiBZb3UgY2FuIHRyeSBleHQ0IG9yIHhmcy4NCg0KVGhhbmtzLg0KDQo+IA0KPiBD
aGVlcnMsDQo+IEJlbi4NCj4gDQo+ID4gIC8qIENvbnRyb2xsZXIgaW5mb3JtYXRpb24gKi8NCj4g
PiAgZW51bSB7DQo+ID4gIAlTQVRBX0ZTTF9RVUVVRV9ERVBUSAk9IDE2LA0KPiA+IEBAIC04Myw2
ICs5MiwxNiBAQCBlbnVtIHsNCj4gPiAgfTsNCj4gPg0KPiA+ICAvKg0KPiA+ICsgKiBJbnRlcnJ1
cHQgQ29hbGVzY2luZyBDb250cm9sIFJlZ2lzdGVyIGJpdGRlZnMgICovIGVudW0gew0KPiA+ICsJ
SUNDX01JTl9JTlRfQ09VTlRfVEhSRVNIT0xECT0gMSwNCj4gPiArCUlDQ19NQVhfSU5UX0NPVU5U
X1RIUkVTSE9MRAk9ICgoMSA8PCA1KSAtIDEpLA0KPiA+ICsJSUNDX01JTl9JTlRfVElDS1NfVEhS
RVNIT0xECT0gMCwNCj4gPiArCUlDQ19NQVhfSU5UX1RJQ0tTX1RIUkVTSE9MRAk9ICgoMSA8PCAx
OSkgLSAxKSwNCj4gPiArCUlDQ19TQUZFX0lOVF9USUNLUwkJPSAxLA0KPiA+ICt9Ow0KPiA+ICsN
Cj4gPiArLyoNCj4gPiAgKiBIb3N0IENvbnRyb2xsZXIgY29tbWFuZCByZWdpc3RlciBzZXQgLSBw
ZXIgcG9ydCAgKi8gIGVudW0geyBAQA0KPiA+IC0yNjMsOCArMjgyLDY1IEBAIHN0cnVjdCBzYXRh
X2ZzbF9ob3N0X3ByaXYgew0KPiA+ICAJdm9pZCBfX2lvbWVtICpjc3JfYmFzZTsNCj4gPiAgCWlu
dCBpcnE7DQo+ID4gIAlpbnQgZGF0YV9zbm9vcDsNCj4gPiArCXN0cnVjdCBkZXZpY2VfYXR0cmli
dXRlIGludHJfY29hbGVzY2luZzsNCj4gPiAgfTsNCj4gPg0KPiA+ICtzdGF0aWMgdm9pZCBmc2xf
c2F0YV9zZXRfaXJxX2NvYWxlc2Npbmcoc3RydWN0IGF0YV9ob3N0ICpob3N0LA0KPiA+ICsJCXVu
c2lnbmVkIGludCBjb3VudCwgdW5zaWduZWQgaW50IHRpY2tzKSB7DQo+ID4gKwlzdHJ1Y3Qgc2F0
YV9mc2xfaG9zdF9wcml2ICpob3N0X3ByaXYgPSBob3N0LT5wcml2YXRlX2RhdGE7DQo+ID4gKwl2
b2lkIF9faW9tZW0gKmhjcl9iYXNlID0gaG9zdF9wcml2LT5oY3JfYmFzZTsNCj4gPiArDQo+ID4g
KwlpZiAoY291bnQgPiBJQ0NfTUFYX0lOVF9DT1VOVF9USFJFU0hPTEQpDQo+ID4gKwkJY291bnQg
PSBJQ0NfTUFYX0lOVF9DT1VOVF9USFJFU0hPTEQ7DQo+ID4gKwllbHNlIGlmIChjb3VudCA8IElD
Q19NSU5fSU5UX0NPVU5UX1RIUkVTSE9MRCkNCj4gPiArCQljb3VudCA9IElDQ19NSU5fSU5UX0NP
VU5UX1RIUkVTSE9MRDsNCj4gPiArDQo+ID4gKwlpZiAodGlja3MgPiBJQ0NfTUFYX0lOVF9USUNL
U19USFJFU0hPTEQpDQo+ID4gKwkJdGlja3MgPSBJQ0NfTUFYX0lOVF9USUNLU19USFJFU0hPTEQ7
DQo+ID4gKwllbHNlIGlmICgoSUNDX01JTl9JTlRfVElDS1NfVEhSRVNIT0xEID09IHRpY2tzKSAm
Jg0KPiA+ICsJCQkoY291bnQgPiBJQ0NfTUlOX0lOVF9DT1VOVF9USFJFU0hPTEQpKQ0KPiA+ICsJ
CXRpY2tzID0gSUNDX1NBRkVfSU5UX1RJQ0tTOw0KPiA+ICsNCj4gPiArCXNwaW5fbG9jaygmaG9z
dC0+bG9jayk7DQo+ID4gKwlpb3dyaXRlMzIoKGNvdW50IDw8IDI0IHwgdGlja3MpLCBoY3JfYmFz
ZSArIElDQyk7DQo+ID4gKw0KPiA+ICsJaW50cl9jb2FsZXNjaW5nX2NvdW50ID0gY291bnQ7DQo+
ID4gKwlpbnRyX2NvYWxlc2NpbmdfdGlja3MgPSB0aWNrczsNCj4gPiArCXNwaW5fdW5sb2NrKCZo
b3N0LT5sb2NrKTsNCj4gPiArDQo+ID4gKwlEUFJJTlRLKCJpbnRycnVwdCBjb2FsZXNjaW5nLCBj
b3VudCA9IDB4JXgsIHRpY2tzID0gJXhcbiIsDQo+ID4gKwkJCWludHJfY29hbGVzY2luZ19jb3Vu
dCwgaW50cl9jb2FsZXNjaW5nX3RpY2tzKTsNCj4gPiArCURQUklOVEsoIklDQyByZWdpc3RlciBz
dGF0dXM6IChoY3IgYmFzZTogMHgleCkgPSAweCV4XG4iLA0KPiA+ICsJCQloY3JfYmFzZSwgaW9y
ZWFkMzIoaGNyX2Jhc2UgKyBJQ0MpKTsgfQ0KPiA+ICsNCj4gPiArc3RhdGljIHNzaXplX3QgZnNs
X3NhdGFfaW50cl9jb2FsZXNjaW5nX3Nob3coc3RydWN0IGRldmljZSAqZGV2LA0KPiA+ICsJCXN0
cnVjdCBkZXZpY2VfYXR0cmlidXRlICphdHRyLCBjaGFyICpidWYpIHsNCj4gPiArCXJldHVybiBz
cHJpbnRmKGJ1ZiwgIiVkCSVkXG4iLA0KPiA+ICsJCQlpbnRyX2NvYWxlc2NpbmdfY291bnQsIGlu
dHJfY29hbGVzY2luZ190aWNrcyk7IH0NCj4gPiArDQo+ID4gK3N0YXRpYyBzc2l6ZV90IGZzbF9z
YXRhX2ludHJfY29hbGVzY2luZ19zdG9yZShzdHJ1Y3QgZGV2aWNlICpkZXYsDQo+ID4gKwkJc3Ry
dWN0IGRldmljZV9hdHRyaWJ1dGUgKmF0dHIsDQo+ID4gKwkJY29uc3QgY2hhciAqYnVmLCBzaXpl
X3QgY291bnQpDQo+ID4gK3sNCj4gPiArCXVuc2lnbmVkIGludCBjb2FsZXNjaW5nX2NvdW50LAlj
b2FsZXNjaW5nX3RpY2tzOw0KPiA+ICsNCj4gPiArCWlmIChzc2NhbmYoYnVmLCAiJWQlZCIsDQo+
ID4gKwkJCQkmY29hbGVzY2luZ19jb3VudCwNCj4gPiArCQkJCSZjb2FsZXNjaW5nX3RpY2tzKSAh
PSAyKSB7DQo+ID4gKwkJcHJpbnRrKEtFUk5fRVJSICJmc2wtc2F0YTogd3JvbmcgcGFyYW1ldGVy
IGZvcm1hdC5cbiIpOw0KPiA+ICsJCXJldHVybiAtRUlOVkFMOw0KPiA+ICsJfQ0KPiA+ICsNCj4g
PiArCWZzbF9zYXRhX3NldF9pcnFfY29hbGVzY2luZyhkZXZfZ2V0X2RydmRhdGEoZGV2KSwNCj4g
PiArCQkJY29hbGVzY2luZ19jb3VudCwgY29hbGVzY2luZ190aWNrcyk7DQo+ID4gKw0KPiA+ICsJ
cmV0dXJuIHN0cmxlbihidWYpOw0KPiA+ICt9DQo+ID4gKw0KPiA+ICBzdGF0aWMgaW5saW5lIHVu
c2lnbmVkIGludCBzYXRhX2ZzbF90YWcodW5zaWduZWQgaW50IHRhZywNCj4gPiAgCQkJCQl2b2lk
IF9faW9tZW0gKmhjcl9iYXNlKQ0KPiA+ICB7DQo+ID4gQEAgLTM0NiwxMCArNDIyLDEwIEBAIHN0
YXRpYyB1bnNpZ25lZCBpbnQgc2F0YV9mc2xfZmlsbF9zZyhzdHJ1Y3QNCj4gYXRhX3F1ZXVlZF9j
bWQgKnFjLCB2b2lkICpjbWRfZGVzYywNCj4gPiAgCQkJKHVuc2lnbmVkIGxvbmcgbG9uZylzZ19h
ZGRyLCBzZ19sZW4pOw0KPiA+DQo+ID4gIAkJLyogd2FybiBpZiBlYWNoIHMvZyBlbGVtZW50IGlz
IG5vdCBkd29yZCBhbGlnbmVkICovDQo+ID4gLQkJaWYgKHNnX2FkZHIgJiAweDAzKQ0KPiA+ICsJ
CWlmICh1bmxpa2VseShzZ19hZGRyICYgMHgwMykpDQo+ID4gIAkJCWF0YV9wb3J0X2VycihxYy0+
YXAsICJzL2cgYWRkciB1bmFsaWduZWQgOiAweCVsbHhcbiIsDQo+ID4gIAkJCQkgICAgICh1bnNp
Z25lZCBsb25nIGxvbmcpc2dfYWRkcik7DQo+ID4gLQkJaWYgKHNnX2xlbiAmIDB4MDMpDQo+ID4g
KwkJaWYgKHVubGlrZWx5KHNnX2xlbiAmIDB4MDMpKQ0KPiA+ICAJCQlhdGFfcG9ydF9lcnIocWMt
PmFwLCAicy9nIGxlbiB1bmFsaWduZWQgOiAweCV4XG4iLA0KPiA+ICAJCQkJICAgICBzZ19sZW4p
Ow0KPiA+DQo+ID4gQEAgLTEyNDUsNiArMTMyMSwxMyBAQCBzdGF0aWMgaW50IHNhdGFfZnNsX2lu
aXRfY29udHJvbGxlcihzdHJ1Y3QNCj4gYXRhX2hvc3QgKmhvc3QpDQo+ID4gIAlpb3dyaXRlMzIo
MHgwMDAwMEZGRkYsIGhjcl9iYXNlICsgQ0UpOw0KPiA+ICAJaW93cml0ZTMyKDB4MDAwMDBGRkZG
LCBoY3JfYmFzZSArIERFKTsNCj4gPg0KPiA+ICsgCS8qDQo+ID4gKwkgKiByZXNldCB0aGUgbnVt
YmVyIG9mIGNvbW1hbmQgY29tcGxldGUgYml0cyB3aGljaCB3aWxsIGNhdXNlIHRoZQ0KPiA+ICsJ
ICogaW50ZXJydXB0IHRvIGJlIHNpZ25hbGVkDQo+ID4gKwkgKi8NCj4gPiArCWZzbF9zYXRhX3Nl
dF9pcnFfY29hbGVzY2luZyhob3N0LCBpbnRyX2NvYWxlc2NpbmdfY291bnQsDQo+ID4gKwkJCWlu
dHJfY29hbGVzY2luZ190aWNrcyk7DQo+ID4gKw0KPiA+ICAJLyoNCj4gPiAgCSAqIGhvc3QgY29u
dHJvbGxlciB3aWxsIGJlIGJyb3VnaHQgb24tbGluZSwgZHVyaW5nIHh4X3BvcnRfc3RhcnQoKQ0K
PiA+ICAJICogY2FsbGJhY2ssIHRoYXQgc2hvdWxkIGFsc28gaW5pdGlhdGUgdGhlIE9PQiwgQ09N
SU5JVCBzZXF1ZW5jZSBAQA0KPiA+IC0xMzA5LDcgKzEzOTIsNyBAQCBzdGF0aWMgaW50IHNhdGFf
ZnNsX3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UNCj4gKm9mZGV2KQ0KPiA+ICAJdm9pZCBf
X2lvbWVtICpjc3JfYmFzZSA9IE5VTEw7DQo+ID4gIAlzdHJ1Y3Qgc2F0YV9mc2xfaG9zdF9wcml2
ICpob3N0X3ByaXYgPSBOVUxMOw0KPiA+ICAJaW50IGlycTsNCj4gPiAtCXN0cnVjdCBhdGFfaG9z
dCAqaG9zdDsNCj4gPiArCXN0cnVjdCBhdGFfaG9zdCAqaG9zdCA9IE5VTEw7DQo+ID4gIAl1MzIg
dGVtcDsNCj4gPg0KPiA+ICAJc3RydWN0IGF0YV9wb3J0X2luZm8gcGkgPSBzYXRhX2ZzbF9wb3J0
X2luZm9bMF07IEBAIC0xMzU2LDYNCj4gKzE0MzksMTANCj4gPiBAQCBzdGF0aWMgaW50IHNhdGFf
ZnNsX3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKm9mZGV2KQ0KPiA+DQo+ID4gIAkvKiBh
bGxvY2F0ZSBob3N0IHN0cnVjdHVyZSAqLw0KPiA+ICAJaG9zdCA9IGF0YV9ob3N0X2FsbG9jX3Bp
bmZvKCZvZmRldi0+ZGV2LCBwcGksIFNBVEFfRlNMX01BWF9QT1JUUyk7DQo+ID4gKwlpZiAoIWhv
c3QpIHsNCj4gPiArCQlyZXR2YWwgPSAtRU5PTUVNOw0KPiA+ICsJCWdvdG8gZXJyb3JfZXhpdF93
aXRoX2NsZWFudXA7DQo+ID4gKwl9DQo+ID4NCj4gPiAgCS8qIGhvc3QtPmlvbWFwIGlzIG5vdCB1
c2VkIGN1cnJlbnRseSAqLw0KPiA+ICAJaG9zdC0+cHJpdmF0ZV9kYXRhID0gaG9zdF9wcml2Ow0K
PiA+IEBAIC0xMzczLDEwICsxNDYwLDI0IEBAIHN0YXRpYyBpbnQgc2F0YV9mc2xfcHJvYmUoc3Ry
dWN0DQo+ID4gcGxhdGZvcm1fZGV2aWNlICpvZmRldikNCj4gPg0KPiA+ICAJZGV2X3NldF9kcnZk
YXRhKCZvZmRldi0+ZGV2LCBob3N0KTsNCj4gPg0KPiA+ICsJaG9zdF9wcml2LT5pbnRyX2NvYWxl
c2Npbmcuc2hvdyA9IGZzbF9zYXRhX2ludHJfY29hbGVzY2luZ19zaG93Ow0KPiA+ICsJaG9zdF9w
cml2LT5pbnRyX2NvYWxlc2Npbmcuc3RvcmUgPSBmc2xfc2F0YV9pbnRyX2NvYWxlc2Npbmdfc3Rv
cmU7DQo+ID4gKwlzeXNmc19hdHRyX2luaXQoJmhvc3RfcHJpdi0+aW50cl9jb2FsZXNjaW5nLmF0
dHIpOw0KPiA+ICsJaG9zdF9wcml2LT5pbnRyX2NvYWxlc2NpbmcuYXR0ci5uYW1lID0gImludHJf
Y29hbGVzY2luZyI7DQo+ID4gKwlob3N0X3ByaXYtPmludHJfY29hbGVzY2luZy5hdHRyLm1vZGUg
PSBTX0lSVUdPIHwgU19JV1VTUjsNCj4gPiArCXJldHZhbCA9IGRldmljZV9jcmVhdGVfZmlsZSho
b3N0LT5kZXYsICZob3N0X3ByaXYtPmludHJfY29hbGVzY2luZyk7DQo+ID4gKwlpZiAocmV0dmFs
KQ0KPiA+ICsJCWdvdG8gZXJyb3JfZXhpdF93aXRoX2NsZWFudXA7DQo+ID4gKw0KPiA+ICAJcmV0
dXJuIDA7DQo+ID4NCj4gPiAgZXJyb3JfZXhpdF93aXRoX2NsZWFudXA6DQo+ID4NCj4gPiArCWlm
IChob3N0KSB7DQo+ID4gKwkJZGV2X3NldF9kcnZkYXRhKCZvZmRldi0+ZGV2LCBOVUxMKTsNCj4g
PiArCQlhdGFfaG9zdF9kZXRhY2goaG9zdCk7DQo+ID4gKwl9DQo+ID4gKw0KPiA+ICAJaWYgKGhj
cl9iYXNlKQ0KPiA+ICAJCWlvdW5tYXAoaGNyX2Jhc2UpOw0KPiA+ICAJaWYgKGhvc3RfcHJpdikN
Cj4gPiBAQCAtMTM5MCw2ICsxNDkxLDggQEAgc3RhdGljIGludCBzYXRhX2ZzbF9yZW1vdmUoc3Ry
dWN0IHBsYXRmb3JtX2RldmljZQ0KPiAqb2ZkZXYpDQo+ID4gIAlzdHJ1Y3QgYXRhX2hvc3QgKmhv
c3QgPSBkZXZfZ2V0X2RydmRhdGEoJm9mZGV2LT5kZXYpOw0KPiA+ICAJc3RydWN0IHNhdGFfZnNs
X2hvc3RfcHJpdiAqaG9zdF9wcml2ID0gaG9zdC0+cHJpdmF0ZV9kYXRhOw0KPiA+DQo+ID4gKwlk
ZXZpY2VfcmVtb3ZlX2ZpbGUoJm9mZGV2LT5kZXYsICZob3N0X3ByaXYtPmludHJfY29hbGVzY2lu
Zyk7DQo+ID4gKw0KPiA+ICAJYXRhX2hvc3RfZGV0YWNoKGhvc3QpOw0KPiA+DQo+ID4gIAlkZXZf
c2V0X2RydmRhdGEoJm9mZGV2LT5kZXYsIE5VTEwpOw0KPiA+IC0tDQo+ID4gMS42LjQNCj4gPg0K
PiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4gPiBMaW51eHBwYy1kZXYgbWFpbGluZyBsaXN0DQo+ID4gTGludXhwcGMtZGV2QGxpc3RzLm96
bGFicy5vcmcNCj4gPiBodHRwczovL2xpc3RzLm96bGFicy5vcmcvbGlzdGluZm8vbGludXhwcGMt
ZGV2DQo+IA0KPiANCg0K
^ 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