* Re: [PATCH v2 3/3] powerpc/mpc85xx_ds: convert to unified PCI init
From: Kumar Gala @ 2012-07-11 12:57 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Alexander Graf
In-Reply-To: <1341966409-22660-4-git-send-email-scottwood@freescale.com>
On Jul 10, 2012, at 7:26 PM, Scott Wood wrote:
> Similar to how the primary PCI bridge is identified by looking
> for an isa subnode, we determine whether to apply uli exclusions
> by looking for a uli subnode.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> v2: Rebased on Kumar's next
>=20
> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 97 =
+++++++++---------------------
> 1 files changed, 29 insertions(+), 68 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH v2 2/3] powerpc/e500: add paravirt QEMU platform
From: Kumar Gala @ 2012-07-11 12:57 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Alexander Graf
In-Reply-To: <1341966409-22660-3-git-send-email-scottwood@freescale.com>
On Jul 10, 2012, at 7:26 PM, Scott Wood wrote:
> This gives the kernel a paravirtualized machine to target, without
> requiring both sides to pretend to be targeting a specific board
> that likely has little to do with the host in KVM scenarios. This
> avoids the need to add new boards to QEMU just to be able to
> run KVM on new CPUs.
>=20
> As this is the first platform that can run with either e500v2 or
> e500mc, CONFIG_PPC_E500MC is now a legitimately user configurable
> option, so add a help text.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> v2: Added a comment about the flexible nature of this platform, and
> rebased on Kumar's next
>=20
> arch/powerpc/platforms/85xx/Kconfig | 16 +++++++
> arch/powerpc/platforms/85xx/Makefile | 1 +
> arch/powerpc/platforms/85xx/qemu_e500.c | 72 =
+++++++++++++++++++++++++++++++
> arch/powerpc/platforms/Kconfig.cputype | 4 ++
> 4 files changed, 93 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/85xx/qemu_e500.c
applied to next
- k=
^ permalink raw reply
* Re: [PATCH v2 1/3] powerpc/fsl-pci: get PCI init out of board files
From: Kumar Gala @ 2012-07-11 12:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Alexander Graf
In-Reply-To: <1341966409-22660-2-git-send-email-scottwood@freescale.com>
On Jul 10, 2012, at 7:26 PM, Scott Wood wrote:
> As an alternative incremental starting point to Jia Hongtao's =
patchset,
> get the FSL PCI init out of the board files, but do not yet convert to =
a
> platform driver.
>=20
> Rather than having each board supply a magic register offset for
> determining the "primary" bus, we look for which PCI host bridge
> contains an ISA node within its subtree. If there is no ISA node,
> normally that would mean there is no primary bus, but until certain
> bugs are fixed we arbitrarily designate a primary in this case.
>=20
> Conversion to a platform driver and related improvements can happen
> after this, as the ordering issues are sorted out.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> v2: rebased on Kumar's next
>=20
> arch/powerpc/sysdev/fsl_pci.c | 71 =
++++++++++++++++++++++++++++++++++++++++-
> arch/powerpc/sysdev/fsl_pci.h | 8 +++++
> 2 files changed, 78 insertions(+), 1 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [RFC PATCH v3 0/13] memory-hotplug : hot-remove physical memory
From: Jiang Liu @ 2012-07-11 14:24 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: len.brown, wency, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, rientjes, Christoph Lameter,
linuxppc-dev, akpm
In-Reply-To: <4FFCCEC3.4050800@jp.fujitsu.com>
On 07/11/2012 08:54 AM, Yasuaki Ishimatsu wrote:
> Hi Jiang,
>
> 2012/07/11 9:21, Jiang Liu wrote:
>> On 07/11/2012 08:09 AM, Yasuaki Ishimatsu wrote:
>>> Hi Jiang,
>>>
>>> 2012/07/11 1:50, Jiang Liu wrote:
>>>> On 07/10/2012 05:58 PM, Yasuaki Ishimatsu wrote:
>>>>> Hi Christoph,
>>>>>
>>>>> 2012/07/10 0:18, Christoph Lameter wrote:
>>>>>>
>>>>>> On Mon, 9 Jul 2012, Yasuaki Ishimatsu wrote:
>>>>>>
>>>>>>> Even if you apply these patches, you cannot remove the physical memory
>>>>>>> completely since these patches are still under development. I want you to
>>>>>>> cooperate to improve the physical memory hot-remove. So please review these
>>>>>>> patches and give your comment/idea.
>>>>>>
>>>>>> Could you at least give a method on how you want to do physical memory
>>>>>> removal?
>>>>>
>>>>> We plan to release a dynamic hardware partitionable system. It will be
>>>>> able to hot remove/add a system board which included memory and cpu.
>>>>> But as you know, Linux does not support memory hot-remove on x86 box.
>>>>> So I try to develop it.
>>>>>
>>>>> Current plan to hot remove system board is to use container driver.
>>>>> Thus I define the system board in ACPI DSDT table as a container device.
>>>>> It have supported hot-add a container device. And if container device
>>>>> has _EJ0 ACPI method, "eject" file to remove the container device is
>>>>> prepared as follow:
>>>>>
>>>>> # ls -l /sys/bus/acpi/devices/ACPI0004\:01/eject
>>>>> --w-------. 1 root root 4096 Jul 10 18:19 /sys/bus/acpi/devices/ACPI0004:01/eject
>>>>>
>>>>> When I hot-remove the container device, I echo 1 to the file as follow:
>>>>>
>>>>> #echo 1 > /sys/bus/acpi/devices/ACPI0004\:02/eject
>>>>>
>>>>> Then acpi_bus_trim() is called. And it calls acpi_memory_device_remove()
>>>>> for removing memory device. But the code does not do nothing.
>>>>> So I developed the continuation of the function.
>>>>>
>>>>>> You would have to remove all objects from the range you want to
>>>>>> physically remove. That is only possible under special circumstances and
>>>>>> with a limited set of objects. Even if you exclusively use ZONE_MOVEABLE
>>>>>> you still may get cases where pages are pinned for a long time.
>>>>>
>>>>> I know it. So my memory hot-remove plan is as follows:
>>>>>
>>>>> 1. hot-added a system board
>>>>> All memory which included the system board is offline.
>>>>>
>>>>> 2. online the memory as removable page
>>>>> The function has not supported yet. It is being developed by Lai as follow:
>>>>> http://lkml.indiana.edu/hypermail/linux/kernel/1207.0/01478.html
>>>>> If it is supported, I will be able to create movable memory.
>>>>>
>>>>> 3. hot-remove the memory by container device's eject file
>>>> We have implemented a prototype to do physical node (mem + CPU + IOH) hotplug
>>>> for Itanium and is now porting it to x86. But with currently solution, memory
>>>> hotplug functionality may cause 10-20% performance decrease because we concentrate
>>>> all DMA/Normal memory to the first NUMA node, and all other NUMA nodes only
>>>> hosts ZONE_MOVABLE. We are working on solution to minimize the performance
>>>> drop now.
>>>
>>> Thank you for your interesting response.
>>>
>>> I have a question. How do you move all other NUMA nodes to ZONE_MOVABLE?
>>> To use ZONE_MOVABLE, we need to use boot options like kernelcore or movablecore.
>>> But it is not enough, since the requested amount is spread evenly throughout
>>> all nodes in the system. So I think we do not have way to move all other NUMA
>>> node to ZONE_MOVABLE.
>> We have modified the ZONE_MOVABLE spreading and bootmem allocation. If the kernelcore
>> or movablecore kernel parameters are present, we follow current behavior. If those
>> parameter are absent and the platform supports physical hotplug, we will concentrate
>> DMA/NORMAL memory to specific nodes.
>
> That's interesting. I want to know more details, if you do not mind.
> Current kernel doesn't do the behavior, does it? So I think you have some
> patches for changing the behavior. Will you merge these patches into
> community kernel?
Yeah, we do have patches for that. But it's still prototype, still much work
needed before sending them to the community.
Currently I'm trying to send out patches for an ACPI based system device
hotplug framework, which will support processor, memory, IOH and node hotplug
in a unified way. After that, I will prepare the memory hotplug code.
Thanks!
Gerry
^ permalink raw reply
* Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Joakim Tjernlund @ 2012-07-11 14:24 UTC (permalink / raw)
Cc: Scott Wood, support, Bob Cochran, linuxppc-dev
In-Reply-To: <OF7810EBD9.B191A242-ONC1257A13.0031E9E3-C1257A13.00320D10@LocalDomain>
Joakim Tjernlund/Transmode wrote on 2012/06/04 11:06:41:
>
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 2012/06/02 23:21:16:
> >
> > On Sat, 2012-06-02 at 20:29 +0200, Joakim Tjernlund wrote:
> > >
> > > hmm, where does this go w.r.t the patch? Got the feeling that the
> > > best thing is to just turn MSR:DE on and be done with it?
> >
> > Not unconditionally, we need to have a close look, that might be ok
> > specifically for BookE 32-bit, it's certainly not ok for BookE 64-bit at
> > this point.
> >
> > For now, I'm ok with a debug CONFIG_* option.
> >
> > Also do we know if MSR:DE has any performance impact on any CPU ? I know
> > having DACs enabled has a major impact on some for example.
>
> I just sent a new patch, named
> [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
> which will only add MSR_DE for booke under CONFIG_BDI_SWITCH
Now I tried running gdb in user space and then I get this(with the MSR_DE patch):
root@P2020RDB ~ # ./gdb busybox
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "powerpc-softfloat-linux-gnu"...
(no debugging symbols found)
(gdb) run
Starting program: /root/busybox
(no debugging syOops: Exception in kernel mode, sig: 5 [#1]
PREEMPT P1010 RDB
Modules linked in:
NIP: c00067dc LR: c02d1994 CTR: c004a97c
REGS: dfef9f10 TRAP: 2002 Not tainted (3.4.0+)
MSR: 00021000 <CE,ME> CR: 42002424 XER: 00000000
TASK = df9a0b10[429] 'gdb' THREAD: dfb9a000
GPR00: cc00cc00 dfb9bd70 df9a0b10 df9a0b10 df949ad0 c0396000 00000000 df949b0c
GPR08: 00000000 40000000 00002786 c03b0000 2b833af6 10493068 10490000 105a62a0
GPR16: 00000000 10490000 10490000 10490000 10490000 10490000 10490000 dfb2ce40
GPR24: df949ad0 c02e0000 c02e0000 c03b20a4 00000004 dfb9a000 c0399ce0 df9a0b10
NIP [c00067dc] __switch_to+0x74/0xc4
LR [c02d1994] __schedule+0x1a0/0x3c0
Call Trace:
[dfb9bd70] [dfb9a000] 0xdfb9a000 (unreliable)
[dfb9bd80] [c02d1994] __schedule+0x1a0/0x3c0
[dfb9bdc0] [c02d1cb8] preempt_schedule+0x54/0x74
[dfb9bdd0] [c0047fe0] try_to_wake_up+0x140/0x144
[dfb9bdf0] [c002b0bc] ptrace_resume+0x70/0xbc
[dfb9be00] [c002c044] ptrace_request+0x1e8/0x5f0
[dfb9bec0] [c00032c4] arch_ptrace+0x30/0x8f8
[dfb9bf10] [c002ba90] sys_ptrace+0xb4/0x3cc
[dfb9bf40] [c000cf4c] ret_from_syscall+0x0/0x3c
--- Exception: c01 at 0xfd607a4
LR = 0x101a4900
Instruction dump:
41820040 80040234 7c184ba6 80040238 7c194ba6 8004023c 7c1c4ba6 80040240
7c1d4ba6 80040224 7c144ba6 80040228 <7c154ba6> 8004022c 7c164ba6 7c431378
---[ end trace 584ab4ed4087571b ]---
note: gdb[429] exited with preempt_count 268435458
mbols found)
(nBUG: scheduling while atomic: busybox/430/0x10000004
o debugging symbModules linked in:ols found)
When I remove the patch it works. I got no idea were it goes wrong,
any ideas?
Jocke
^ permalink raw reply
* Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Kumar Gala @ 2012-07-11 14:45 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev, Bob Cochran, support
In-Reply-To: <OF96FD460E.639EB713-ONC1257A38.004ECE07-C1257A38.004F2536@transmode.se>
On Jul 11, 2012, at 9:24 AM, Joakim Tjernlund wrote:
> Joakim Tjernlund/Transmode wrote on 2012/06/04 11:06:41:
>>=20
>> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 2012/06/02 =
23:21:16:
>>>=20
>>> On Sat, 2012-06-02 at 20:29 +0200, Joakim Tjernlund wrote:
>>>>=20
>>>> hmm, where does this go w.r.t the patch? Got the feeling that the
>>>> best thing is to just turn MSR:DE on and be done with it?
>>>=20
>>> Not unconditionally, we need to have a close look, that might be ok
>>> specifically for BookE 32-bit, it's certainly not ok for BookE =
64-bit at
>>> this point.
>>>=20
>>> For now, I'm ok with a debug CONFIG_* option.
>>>=20
>>> Also do we know if MSR:DE has any performance impact on any CPU ? I =
know
>>> having DACs enabled has a major impact on some for example.
>>=20
>> I just sent a new patch, named
>> [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
>> which will only add MSR_DE for booke under CONFIG_BDI_SWITCH
>=20
> Now I tried running gdb in user space and then I get this(with the =
MSR_DE patch):
> root@P2020RDB ~ # ./gdb busybox
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later =
<http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show =
copying"
> and "show warranty" for details.
> This GDB was configured as "powerpc-softfloat-linux-gnu"...
> (no debugging symbols found)
> (gdb) run
> Starting program: /root/busybox
> (no debugging syOops: Exception in kernel mode, sig: 5 [#1]
> PREEMPT P1010 RDB
> Modules linked in:
> NIP: c00067dc LR: c02d1994 CTR: c004a97c
> REGS: dfef9f10 TRAP: 2002 Not tainted (3.4.0+)
> MSR: 00021000 <CE,ME> CR: 42002424 XER: 00000000
> TASK =3D df9a0b10[429] 'gdb' THREAD: dfb9a000
> GPR00: cc00cc00 dfb9bd70 df9a0b10 df9a0b10 df949ad0 c0396000 00000000 =
df949b0c
> GPR08: 00000000 40000000 00002786 c03b0000 2b833af6 10493068 10490000 =
105a62a0
> GPR16: 00000000 10490000 10490000 10490000 10490000 10490000 10490000 =
dfb2ce40
> GPR24: df949ad0 c02e0000 c02e0000 c03b20a4 00000004 dfb9a000 c0399ce0 =
df9a0b10
> NIP [c00067dc] __switch_to+0x74/0xc4
> LR [c02d1994] __schedule+0x1a0/0x3c0
> Call Trace:
> [dfb9bd70] [dfb9a000] 0xdfb9a000 (unreliable)
> [dfb9bd80] [c02d1994] __schedule+0x1a0/0x3c0
> [dfb9bdc0] [c02d1cb8] preempt_schedule+0x54/0x74
> [dfb9bdd0] [c0047fe0] try_to_wake_up+0x140/0x144
> [dfb9bdf0] [c002b0bc] ptrace_resume+0x70/0xbc
> [dfb9be00] [c002c044] ptrace_request+0x1e8/0x5f0
> [dfb9bec0] [c00032c4] arch_ptrace+0x30/0x8f8
> [dfb9bf10] [c002ba90] sys_ptrace+0xb4/0x3cc
> [dfb9bf40] [c000cf4c] ret_from_syscall+0x0/0x3c
> --- Exception: c01 at 0xfd607a4
> LR =3D 0x101a4900
> Instruction dump:
> 41820040 80040234 7c184ba6 80040238 7c194ba6 8004023c 7c1c4ba6 =
80040240
> 7c1d4ba6 80040224 7c144ba6 80040228 <7c154ba6> 8004022c 7c164ba6 =
7c431378
> ---[ end trace 584ab4ed4087571b ]---
>=20
> note: gdb[429] exited with preempt_count 268435458
> mbols found)
> (nBUG: scheduling while atomic: busybox/430/0x10000004
> o debugging symbModules linked in:ols found)
>=20
> When I remove the patch it works. I got no idea were it goes wrong,
> any ideas?
>=20
> Jocke
I was wondering if this was going to break user space debugging. What's =
probably happening by having MSR_DE always set, you are getting debug =
exceptions while in the kernel because DBCR[ICMP] (instruction complete) =
is set and the HW is taking an exception. Previously MSR_DE would ONLY =
be set while in user mode and thus prevent "spurious" debug exceptions =
like this.
- k=
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: Create dts of each core in CAMP mode for P1021RDB-PC
From: Kumar Gala @ 2012-07-11 14:47 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: McClintock Matthew-B29882, Xu Jiucheng-B37781,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXX1+=p3GMccLvCwFpei2igidXuo_U1gSVy56cBAkKxoHg@mail.gmail.com>
On Jul 10, 2012, at 7:25 AM, Tabi Timur-B04825 wrote:
> On Tue, Jul 10, 2012 at 3:39 AM, Xu Jiucheng =
<Jiucheng.Xu@freescale.com> wrote:
>> Create the dts files for each core and splits the devices between
>> the two cores for P1021RDB-PC.
>>=20
>> Core0 has l2, serial0, i2c, spi, gpio, tdm,dma, usb, eth0, eth1,
>> sdhc, crypto, global-util, message, pci0, pci1, msi, crypto.
>> Core1 has l2, serial1, eth2.
>>=20
>> Signed-off-by: Xu Jiucheng <Jiucheng.Xu@freescale.com>
>> Signed-off-by: Matthew McClintock <msm@freescale.com>
>> ---
>=20
> Do we really want AMP device trees upstream? They're very
> application-specific, and AMP support has always been a hack. If
> anything, I think we should be deleting AMP device trees from
> upstream, not adding more.
Since we already have P1021RDB-PC w/AMP support in upstream I agree we =
don't need another example on P1021RDB-PC.
- k=
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: Create dts of each core in CAMP mode for P1021RDB-PC
From: Timur Tabi @ 2012-07-11 14:49 UTC (permalink / raw)
To: Kumar Gala
Cc: McClintock Matthew-B29882, Xu Jiucheng-B37781,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4D91E39B-2773-429D-B956-38C04521C8B2@kernel.crashing.org>
Kumar Gala wrote:
> Since we already have P1021RDB-PC w/AMP support in upstream I agree we don't need another example on P1021RDB-PC.
Would you accept a patch that removes all AMP device trees from upstream?
I just don't think that these very customer-specific dts files belong
upstream.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* AW: [PATCH 2/2] powerpc/85xx: Create dts of each core in CAMP mode for P1021RDB-PC
From: Schneider, Kolja @ 2012-07-11 14:52 UTC (permalink / raw)
To: Timur Tabi, Kumar Gala
Cc: McClintock Matthew-B29882, Xu Jiucheng-B37781,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FFD9281.1070202@freescale.com>
> Kumar Gala wrote:
> > Since we already have P1021RDB-PC w/AMP support in upstream I agree
> we don't need another example on P1021RDB-PC.
>=20
> Would you accept a patch that removes all AMP device trees from upstream?
> I just don't think that these very customer-specific dts files belong
> upstream
[>]=20
Is there any alternate source for AMP device trees? Just in case someone
needs some sort of documentation?
:-) Kolja
.
>=20
> --
> Timur Tabi
> Linux kernel developer at Freescale
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: Create dts of each core in CAMP mode for P1021RDB-PC
From: Kumar Gala @ 2012-07-11 14:53 UTC (permalink / raw)
To: Timur Tabi
Cc: McClintock Matthew-B29882, Xu Jiucheng-B37781,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FFD9281.1070202@freescale.com>
On Jul 11, 2012, at 9:49 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>> Since we already have P1021RDB-PC w/AMP support in upstream I agree =
we don't need another example on P1021RDB-PC.
>=20
> Would you accept a patch that removes all AMP device trees from =
upstream?
> I just don't think that these very customer-specific dts files belong
> upstream.
No, I think we should have at least one or two examples of AMP dts in =
upstream.
- k=
^ permalink raw reply
* Re: AW: [PATCH 2/2] powerpc/85xx: Create dts of each core in CAMP mode for P1021RDB-PC
From: Timur Tabi @ 2012-07-11 14:56 UTC (permalink / raw)
To: Schneider, Kolja
Cc: McClintock Matthew-B29882, Xu Jiucheng-B37781,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <D42F060B3778074EA85B5FC2CC9E015C449536C4@MEN-EX2.intra.men.de>
Schneider, Kolja wrote:
>
> Is there any alternate source for AMP device trees? Just in case someone
> needs some sort of documentation?
The SDK. We can put a hundred AMP device trees on there if we want, and
no one will complain.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/85xx: Create dts of each core in CAMP mode for P1021RDB-PC
From: Timur Tabi @ 2012-07-11 14:56 UTC (permalink / raw)
To: Kumar Gala
Cc: McClintock Matthew-B29882, Xu Jiucheng-B37781,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <21405BDD-2124-4CB6-A947-0B8124D51063@kernel.crashing.org>
Kumar Gala wrote:
> No, I think we should have at least one or two examples of AMP dts in upstream.
We have more than that:
./p2020rdb_camp_core1.dts
./p1020rdb-pc_camp_core1.dts
./mpc8572ds_camp_core1.dts
./p2020rdb_camp_core0.dts
./p1020rdb-pc_camp_core0.dts
./mpc8572ds_camp_core0.dts
./p1020rdb_camp_core1.dts
./p1020rdb_camp_core0.dts
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [linuxppc-release] [PATCH v2 4/4] fsl-dma: use spin_lock_bh to instead of spin_lock_irqsave
From: Timur Tabi @ 2012-07-11 15:01 UTC (permalink / raw)
To: Qiang Liu
Cc: Vinod Koul, herbert, linux-crypto, Dan Williams, linuxppc-dev,
davem
In-Reply-To: <1341997326-18495-1-git-send-email-qiang.liu@freescale.com>
Qiang Liu wrote:
> Use spin_lock_bh to instead of spin_lock_irqsave for improving performance.
Please provide some evidence that performance has improved, as well as an
explanation why it's okay to use spin_lock_bh, and why it's faster.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [RFC PATCH v3 3/13] memory-hotplug : unify argument of firmware_map_add_early/hotplug
From: Dave Hansen @ 2012-07-11 15:30 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: len.brown, wency, linux-acpi, linux-kernel, linux-mm, paulus,
minchan.kim, kosaki.motohiro, rientjes, cl, linuxppc-dev, akpm,
liuj97
In-Reply-To: <4FFAB17F.2090209@jp.fujitsu.com>
On 07/09/2012 03:25 AM, Yasuaki Ishimatsu wrote:
> @@ -642,7 +642,7 @@ int __ref add_memory(int nid, u64 start,
> }
>
> /* create new memmap entry */
> - firmware_map_add_hotplug(start, start + size, "System RAM");
> + firmware_map_add_hotplug(start, start + size - 1, "System RAM");
I know the firmware_map_*() calls use inclusive end addresses
internally, but do we really need to expose them? Both of the callers
you mentioned do:
firmware_map_add_hotplug(start, start + size - 1, "System RAM");
or
firmware_map_add_early(entry->addr,
entry->addr + entry->size - 1,
e820_type_to_string(entry->type));
So it seems a _bit_ silly to keep all of the callers doing this size-1
thing. I also noted that the new caller that you added does the same
thing. Could we just change the external calling convention to be
exclusive?
BTW, this patch should probably be first in your series. It's a real
bugfix.
^ permalink raw reply
* Re: [PATCH v2 2/4] fsl-dma: remove attribute DMA_INTERRUPT of dmaengine
From: Ira W. Snyder @ 2012-07-11 16:17 UTC (permalink / raw)
To: Qiang Liu
Cc: Vinod Koul, herbert, linux-crypto, Dan Williams, linuxppc-dev,
davem
In-Reply-To: <1341997253-18424-1-git-send-email-qiang.liu@freescale.com>
On Wed, Jul 11, 2012 at 05:00:53PM +0800, Qiang Liu wrote:
> Delete attribute DMA_INTERRUPT because fsl-dma doesn't support this function,
> exception will be thrown if talitos is used to offload xor at the same time.
>
Both drivers/misc/carma/carma-fpga.c and
drivers/misc/carma/carma-fpga-program.c expect the DMA_INTERRUPT
property, though they do not use it. The mask is set for historical
reasons. It is safe to delete the line "dma_cap_set(DMA_INTERRUPT, mask);"
from both drivers.
I don't know which other drivers may expect this feature to be present.
These are only the ones which I maintain.
Other than that, you can add my:
Acked-by: Ira W. Snyder <iws@ovro.caltech.edu>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Li Yang <leoli@freescale.com>
> Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
> ---
> drivers/dma/fsldma.c | 31 -------------------------------
> 1 files changed, 0 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index 8f84761..4f2f212 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -543,35 +543,6 @@ static void fsl_dma_free_chan_resources(struct dma_chan *dchan)
> }
>
> static struct dma_async_tx_descriptor *
> -fsl_dma_prep_interrupt(struct dma_chan *dchan, unsigned long flags)
> -{
> - struct fsldma_chan *chan;
> - struct fsl_desc_sw *new;
> -
> - if (!dchan)
> - return NULL;
> -
> - chan = to_fsl_chan(dchan);
> -
> - new = fsl_dma_alloc_descriptor(chan);
> - if (!new) {
> - chan_err(chan, "%s\n", msg_ld_oom);
> - return NULL;
> - }
> -
> - new->async_tx.cookie = -EBUSY;
> - new->async_tx.flags = flags;
> -
> - /* Insert the link descriptor to the LD ring */
> - list_add_tail(&new->node, &new->tx_list);
> -
> - /* Set End-of-link to the last link descriptor of new list */
> - set_ld_eol(chan, new);
> -
> - return &new->async_tx;
> -}
> -
> -static struct dma_async_tx_descriptor *
> fsl_dma_prep_memcpy(struct dma_chan *dchan,
> dma_addr_t dma_dst, dma_addr_t dma_src,
> size_t len, unsigned long flags)
> @@ -1352,12 +1323,10 @@ static int __devinit fsldma_of_probe(struct platform_device *op)
> fdev->irq = irq_of_parse_and_map(op->dev.of_node, 0);
>
> dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
> - dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
> dma_cap_set(DMA_SG, fdev->common.cap_mask);
> dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
> fdev->common.device_alloc_chan_resources = fsl_dma_alloc_chan_resources;
> fdev->common.device_free_chan_resources = fsl_dma_free_chan_resources;
> - fdev->common.device_prep_dma_interrupt = fsl_dma_prep_interrupt;
> fdev->common.device_prep_dma_memcpy = fsl_dma_prep_memcpy;
> fdev->common.device_prep_dma_sg = fsl_dma_prep_sg;
> fdev->common.device_tx_status = fsl_tx_status;
> --
> 1.7.5.1
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH v2 3/4] fsl-dma: change the release process of dma descriptor
From: Ira W. Snyder @ 2012-07-11 16:30 UTC (permalink / raw)
To: Qiang Liu
Cc: Vinod Koul, herbert, linux-crypto, Dan Williams, linuxppc-dev,
davem
In-Reply-To: <1341997285-18459-1-git-send-email-qiang.liu@freescale.com>
On Wed, Jul 11, 2012 at 05:01:25PM +0800, Qiang Liu wrote:
> Modify the release process of dma descriptor for avoiding exception when
> enable config NET_DMA, release dma descriptor from 1st to last second, the
> last descriptor which is reserved in current descriptor register may not be
> completed, race condition will be raised if free current descriptor.
>
> A race condition which is raised when use both of talitos and dmaengine to
> offload xor is because napi scheduler (NET_DMA is enabled) will sync all
> pending requests in dma channels, it affects the process of raid operations.
> The descriptor is freed which is submitted just now, but async_tx must check
> whether this depend tx descriptor is acked, there are poison contents in the
> invalid address, then BUG_ON() is thrown, so this descriptor will be freed
> in the next time.
>
This patch seems to be covering up a bug in the driver, rather than
actually fixing it.
When it was written, it was expected that dma_do_tasklet() would run
only when the controller was idle.
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Vinod Koul <vinod.koul@intel.com>
> Cc: Li Yang <leoli@freescale.com>
> Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
> ---
> drivers/dma/fsldma.c | 15 ++++++++++++---
> 1 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index 4f2f212..0ba3e40 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -1035,14 +1035,22 @@ static irqreturn_t fsldma_chan_irq(int irq, void *data)
> static void dma_do_tasklet(unsigned long data)
> {
> struct fsldma_chan *chan = (struct fsldma_chan *)data;
> - struct fsl_desc_sw *desc, *_desc;
> + struct fsl_desc_sw *desc, *_desc, *prev = NULL;
> LIST_HEAD(ld_cleanup);
> unsigned long flags;
> + dma_addr_t curr_phys = get_cdar(chan);
>
> chan_dbg(chan, "tasklet entry\n");
>
> spin_lock_irqsave(&chan->desc_lock, flags);
>
> + /* find the descriptor which is already completed */
> + list_for_each_entry_safe(desc, _desc, &chan->ld_running, node) {
> + if (prev && desc->async_tx.phys == curr_phys)
> + break;
> + prev = desc;
> + }
> +
If the DMA controller was still busy processing transactions, you should
have gotten the printout "irq: controller not idle!" from
fsldma_chan_irq() just before it scheduled the dma_do_tasklet() to run.
If you did not get this printout, how was dma_do_tasklet() entered with
the controller still busy? I don't understand how it can happen.
If you test without your spin_lock_bh() and spin_unlock_bh() conversion
patch, do you still hit the error?
What happens if a user submits exactly one DMA transaction, and then
leaves the system idle? The callback for the last descriptor in the
chain will never get run, right? That's a bug.
> /* update the cookie if we have some descriptors to cleanup */
> if (!list_empty(&chan->ld_running)) {
> dma_cookie_t cookie;
> @@ -1058,13 +1066,14 @@ static void dma_do_tasklet(unsigned long data)
> * move the descriptors to a temporary list so we can drop the lock
> * during the entire cleanup operation
> */
> - list_splice_tail_init(&chan->ld_running, &ld_cleanup);
> + list_cut_position(&ld_cleanup, &chan->ld_running, &prev->node);
>
> /* the hardware is now idle and ready for more */
> chan->idle = true;
>
> /*
> - * Start any pending transactions automatically
> + * Start any pending transactions automatically if current descriptor
> + * list is completed
> *
> * In the ideal case, we keep the DMA controller busy while we go
> * ahead and free the descriptors below.
> --
> 1.7.5.1
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/mpc8572ds: Fix eTSEC is not available on core1 of AMP boot issue
From: Scott Wood @ 2012-07-11 17:35 UTC (permalink / raw)
To: Jia Hongtao-B38951; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <412C8208B4A0464FA894C5F0C278CD5D01A218AA@039-SN1MPN1-002.039d.mgd.msft.net>
On 07/10/2012 09:07 PM, Jia Hongtao-B38951 wrote:
>
>
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Wednesday, July 11, 2012 2:15 AM
>> To: Jia Hongtao-B38951
>> Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org
>> Subject: Re: [PATCH 1/2] powerpc/mpc8572ds: Fix eTSEC is not available on
>> core1 of AMP boot issue
>>
>> On 07/10/2012 01:08 AM, Jia Hongtao wrote:
>>> The issue log on core1 is:
>>> root@mpc8572ds:~# ifconfig eth0 10.192.208.244
>>> net eth0: could not attach to PHY
>>> SIOCSIFFLAGS: No such device
>>>
>>> To attach PHY node mdio@24520 should not be disabled in dts of core1.
>>> Because all PHYs are controlled through this node as follows:
>>
>> So you grant it to both partitions? How do you deal with synchronization?
>>
>> -Scott
>
> PHY nodes are only used by ethernet. Each ethernet is used by only one partition
> (disabled in the other partition). So I think there is no synchronization issue.
I mean for accessing the MDIO bus.
-Scott
^ permalink raw reply
* Re: [RFC PATCH 06/17] KVM: PPC: e500: Add emulation helper for getting instruction ea
From: Alexander Graf @ 2012-07-11 17:53 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: qemu-ppc@nongnu.org, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF15B1B3@039-SN2MPN1-013.039d.mgd.msft.net>
On 05.07.2012, at 13:39, Caraman Mihai Claudiu-B02008 wrote:
>> -----Original Message-----
>> From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-
>> owner@vger.kernel.org] On Behalf Of Alexander Graf
>> Sent: Wednesday, July 04, 2012 4:56 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
>> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
>> Subject: Re: [RFC PATCH 06/17] KVM: PPC: e500: Add emulation helper =
for
>> getting instruction ea
>>=20
>>=20
>> On 25.06.2012, at 14:26, Mihai Caraman wrote:
>>=20
>>> Add emulation helper for getting instruction ea and refactor tlb
>> instruction
>>> emulation to use it.
>>>=20
>>> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
>>> ---
>>> arch/powerpc/kvm/e500.h | 6 +++---
>>> arch/powerpc/kvm/e500_emulate.c | 21 ++++++++++++++++++---
>>> arch/powerpc/kvm/e500_tlb.c | 23 ++++++-----------------
>>> 3 files changed, 27 insertions(+), 23 deletions(-)
>>>=20
>>> diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
>>> index 3e31098..70bfed4 100644
>>> --- a/arch/powerpc/kvm/e500.h
>>> +++ b/arch/powerpc/kvm/e500.h
>>> @@ -130,9 +130,9 @@ int kvmppc_e500_emul_mt_mmucsr0(struct
>> kvmppc_vcpu_e500 *vcpu_e500,
>>> ulong value);
>>> int kvmppc_e500_emul_tlbwe(struct kvm_vcpu *vcpu);
>>> int kvmppc_e500_emul_tlbre(struct kvm_vcpu *vcpu);
>>> -int kvmppc_e500_emul_tlbivax(struct kvm_vcpu *vcpu, int ra, int =
rb);
>>> -int kvmppc_e500_emul_tlbilx(struct kvm_vcpu *vcpu, int rt, int ra, =
int
>> rb);
>>> -int kvmppc_e500_emul_tlbsx(struct kvm_vcpu *vcpu, int rb);
>>> +int kvmppc_e500_emul_tlbivax(struct kvm_vcpu *vcpu, gva_t ea);
>>> +int kvmppc_e500_emul_tlbilx(struct kvm_vcpu *vcpu, int rt, gva_t =
ea);
>>> +int kvmppc_e500_emul_tlbsx(struct kvm_vcpu *vcpu, gva_t ea);
>>> int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 *vcpu_e500);
>>> void kvmppc_e500_tlb_uninit(struct kvmppc_vcpu_e500 *vcpu_e500);
>>>=20
>>> diff --git a/arch/powerpc/kvm/e500_emulate.c
>> b/arch/powerpc/kvm/e500_emulate.c
>>> index 8b99e07..81288f7 100644
>>> --- a/arch/powerpc/kvm/e500_emulate.c
>>> +++ b/arch/powerpc/kvm/e500_emulate.c
>>> @@ -82,6 +82,17 @@ static int kvmppc_e500_emul_msgsnd(struct =
kvm_vcpu
>> *vcpu, int rb)
>>> }
>>> #endif
>>>=20
>>> +static inline ulong kvmppc_get_ea_indexed(struct kvm_vcpu *vcpu, =
int
>> ra, int rb)
>>> +{
>>> + ulong ea;
>>> +
>>> + ea =3D kvmppc_get_gpr(vcpu, rb);
>>> + if (ra)
>>> + ea +=3D kvmppc_get_gpr(vcpu, ra);
>>> +
>>> + return ea;
>>> +}
>>> +
>>=20
>> Please move this one to arch/powerpc/include/asm/kvm_ppc.h.
>=20
> Yep. This is similar with what I had in my internal version before =
emulation
> refactoring took place upstream. The only difference is that I split =
the embedded
> and server implementation touching this files:
> arch/powerpc/include/asm/kvm_booke.h
> arch/powerpc/include/asm/kvm_book3s.h
>=20
> Which approach do you prefer?
This is generic code to me, so it shouldn't go into booke/book3s =
specific files.
>=20
>>=20
>>> int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu =
*vcpu,
>>> unsigned int inst, int *advance)
>>> {
>>> @@ -89,6 +100,7 @@ int kvmppc_core_emulate_op(struct kvm_run *run,
>> struct kvm_vcpu *vcpu,
>>> int ra =3D get_ra(inst);
>>> int rb =3D get_rb(inst);
>>> int rt =3D get_rt(inst);
>>> + gva_t ea;
>>>=20
>>> switch (get_op(inst)) {
>>> case 31:
>>> @@ -113,15 +125,18 @@ int kvmppc_core_emulate_op(struct kvm_run =
*run,
>> struct kvm_vcpu *vcpu,
>>> break;
>>>=20
>>> case XOP_TLBSX:
>>> - emulated =3D kvmppc_e500_emul_tlbsx(vcpu,rb);
>>> + ea =3D kvmppc_get_ea_indexed(vcpu, ra, rb);
>>> + emulated =3D kvmppc_e500_emul_tlbsx(vcpu, ea);
>>> break;
>>>=20
>>> case XOP_TLBILX:
>>> - emulated =3D kvmppc_e500_emul_tlbilx(vcpu, rt, =
ra, rb);
>>> + ea =3D kvmppc_get_ea_indexed(vcpu, ra, rb);
>>> + emulated =3D kvmppc_e500_emul_tlbilx(vcpu, rt, =
ea);
>>=20
>> What's the point in hiding ra+rb, but not rt? I like the idea of =
hiding
>> the register semantics, but please move rt into a local variable that
>> gets passed as pointer to kvmppc_e500_emul_tlbilx.
>=20
> Why to send it as a pointer? rt which should be rather named t in this =
case
> is an [in] value for tlbilx, according to section 6.11.4.9 in the =
PowerISA 2.06b.
Because usually rt in the PPC ISA denotes a _t_arget _r_egister. The =
field here really is called "T" to denote the _t_ype of the operation =
which you correctly pointed out. Could you please change this misnaming =
along the way and mask it accordingly?
Alex
^ permalink raw reply
* Re: [Qemu-ppc] [RFC PATCH 03/17] KVM: PPC64: booke: Add EPCR support in sregs
From: Alexander Graf @ 2012-07-11 18:07 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: qemu-ppc@nongnu.org, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF15B38A@039-SN2MPN1-013.039d.mgd.msft.net>
On 05.07.2012, at 14:54, Caraman Mihai Claudiu-B02008 wrote:
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Thursday, July 05, 2012 3:13 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
>> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
>> Subject: Re: [Qemu-ppc] [RFC PATCH 03/17] KVM: PPC64: booke: Add EPCR
>> support in sregs
>>=20
>> On 07/05/2012 01:49 PM, Caraman Mihai Claudiu-B02008 wrote:
>>>> -----Original Message-----
>>>> From: Alexander Graf [mailto:agraf@suse.de]
>>>> Sent: Wednesday, July 04, 2012 4:34 PM
>>>> To: Caraman Mihai Claudiu-B02008
>>>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
>>>> dev@lists.ozlabs.org; qemu-ppc@nongnu.org
>>>> Subject: Re: [Qemu-ppc] [RFC PATCH 03/17] KVM: PPC64: booke: Add =
EPCR
>>>> support in sregs
>>>>=20
>>>>=20
>>>> On 25.06.2012, at 14:26, Mihai Caraman wrote:
>>>>=20
>>>>> Add KVM_SREGS_E_64 feature and EPCR spr support in get/set sregs
>>>>> for 64-bit hosts.
>>>> Please also implement a ONE_REG interface while at it. Over time, =
I'd
>>>> like to move towards ONE_REG instead of the messy regs/sregs API.
>>> ONE_REG doesn't seem to be implemented at all for book3e, I looked =
at
>>> kvm_vcpu_ioctl_set_one_reg/kvm_vcpu_ioctl_get_one_reg in booke.c =
file.
>>>=20
>>> I can take care of it soon but in a different patch set. It's ok =
like
>> this?
>>=20
>> Do it in a different patch, but as part of this patch set.
>=20
> Hmm ... then if you don't disagree I will do it as a prerequisite =
patch since I want
> to keep this patchset strictly for 64-bit support.
I don't understand? You just make the same functionality available =
through 2 interfaces to user space.
> I am not familiar with ONE_REG, is qemu tailored to use it? I need a =
way to test it.
ONE_REG is just a more extensible ioctl. Just read up on it in the =
documentation and you'll see what I mean :)
Alex
^ permalink raw reply
* Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add DO_KVM kernel hooks
From: Alexander Graf @ 2012-07-11 22:25 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: qemu-ppc@nongnu.org List, linuxppc-dev, KVM list,
<kvm-ppc@vger.kernel.org>
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF15CF83@039-SN2MPN1-013.039d.mgd.msft.net>
On 07.07.2012, at 10:39, Caraman Mihai Claudiu-B02008 wrote:
>> ________________________________________
>> From: Alexander Graf [agraf@suse.de]
>> Sent: Saturday, July 07, 2012 2:11 AM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: Benjamin Herrenschmidt; <kvm-ppc@vger.kernel.org>; KVM list; =
linuxppc-dev; qemu-ppc@nongnu.org List
>> Subject: Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add =
DO_KVM kernel hooks
>>=20
>> On 07.07.2012, at 00:33, Caraman Mihai Claudiu-B02008 wrote:
>>=20
>>>> -----Original Message-----
>>>> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
>>>> Sent: Thursday, July 05, 2012 1:26 AM
>>>> To: Alexander Graf
>>>> Cc: Caraman Mihai Claudiu-B02008; <kvm-ppc@vger.kernel.org>; KVM =
list;
>>>> linuxppc-dev; qemu-ppc@nongnu.org List
>>>> Subject: Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add =
DO_KVM
>>>> kernel hooks
>>>>=20
>>>> You can't but in any case I don't see the point of the conditional =
here,
>>>> we'll eventually have to load srr1 no ? We can move the load up to =
here
>>>> in all cases or can't we ?
>>>=20
>>> I like the idea, but there is a problem with addition macros which =
may clobber
>>> r11 and PROLOG_ADDITION_MASKABLE_GEN is such a case.
>>=20
>> Mike -v please :)
>=20
> Ben suggested something like this:
> =09
> #define EXCEPTION_PROLOG(n, type, addition) \
> mtspr SPRN_SPRG_##type##_SCRATCH,r13; /* get spare registers */ =
\
> mfspr r13,SPRN_SPRG_PACA; /* get PACA */ \
> std r10,PACA_EX##type+EX_R10(r13); \
> std r11,PACA_EX##type+EX_R11(r13); \
> mfcr r10; /* save CR */ \=09
> + mfspr r11,SPRN_##type##_SRR1;/* what are we coming from */ \
> DO_KVM intnum,srr1; \
> addition; /* additional code for that exc. */ \
> std r1,PACA_EX##type+EX_R1(r13); /* save old r1 in the PACA */ \
> stw r10,PACA_EX##type+EX_CR(r13); /* save old CR in the PACA */ =
\
> - mfspr r11,SPRN_##type##_SRR1;/* what are we coming from */ \
> type##_SET_KSTACK; /* get special stack if necessary */\
> andi. r10,r11,MSR_PR; /* save stack pointer */ \
>=20
> But one of the addition looks like this:
> =09
> #define PROLOG_ADDITION_MASKABLE_GEN(n) \
> lbz r11,PACASOFTIRQEN(r13); /* are irqs soft-disabled ? */ \
> cmpwi cr0,r11,0; /* yes -> go out of line */ \
> beq masked_interrupt_book3e_##n=09
>=20
> So for maskable gen we end up with:
>=20
> #define EXCEPTION_PROLOG(n, type, addition) \
> mtspr SPRN_SPRG_##type##_SCRATCH,r13; /* get spare registers */ =
\
> mfspr r13,SPRN_SPRG_PACA; /* get PACA */ \
> std r10,PACA_EX##type+EX_R10(r13); \
> std r11,PACA_EX##type+EX_R11(r13); \
> mfcr r10; /* save CR */ \
> mfspr r11,SPRN_##type##_SRR1;/* what are we coming from */ \
> DO_KVM intnum,srr1; \
> lbz r11,PACASOFTIRQEN(r13); /* are irqs soft-disabled ? */ \
> cmpwi cr0,r11,0; /* yes -> go out of line */ \
> beq masked_interrupt_book3e_##n \
> std r1,PACA_EX##type+EX_R1(r13); /* save old r1 in the PACA */ \
> stw r10,PACA_EX##type+EX_CR(r13); /* save old CR in the PACA */ =
\
> type##_SET_KSTACK; /* get special stack if necessary */\
> andi. r10,r11,MSR_PR; /* save stack pointer */ \
> =09
> This affects the last asm line, we load srr1 into r11 but clobber it =
in-between.
> We need a spare register for maskable gen addition. I think we can =
free r10 sooner
> and used it in addition like this:
Ah, makes sense, yes.
>=20
> #define EXCEPTION_PROLOG(n, type, addition) \
> mtspr SPRN_SPRG_##type##_SCRATCH,r13; /* get spare registers */ =
\
> mfspr r13,SPRN_SPRG_PACA; /* get PACA */ \ =09
> std r10,PACA_EX##type+EX_R10(r13); \
> std r11,PACA_EX##type+EX_R11(r13); \
Or just free up another register early on, like here.
Alex
> + mfspr r11,SPRN_##type##_SRR1;/* what are we coming from */ \
> mfcr r10; /* save CR */ \
> + stw r10,PACA_EX##type+EX_CR(r13); /* save old CR in the PACA */ =
\
> DO_KVM intnum,srr1; \
> - lbz r11,PACASOFTIRQEN(r13); /* are irqs soft-disabled ? */ \
> - cmpwi cr0,r11,0; /* yes -> go out of line */ \
> + lbz r10,PACASOFTIRQEN(r13); /* are irqs soft-disabled ? */ \
> + cmpwi cr0,r10,0; /* yes -> go out of line */ \
> beq masked_interrupt_book3e_##n \
> std r1,PACA_EX##type+EX_R1(r13); /* save old r1 in the PACA */ \
> - stw r10,PACA_EX##type+EX_CR(r13); /* save old CR in the PACA */ =
\
> - mfspr r11,SPRN_##type##_SRR1;/* what are we coming from */ \
> type##_SET_KSTACK; /* get special stack if necessary */\
> andi. r10,r11,MSR_PR; /* save stack pointer */ \
> =09
> -Mike
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add DO_KVM kernel hooks
From: Benjamin Herrenschmidt @ 2012-07-11 22:28 UTC (permalink / raw)
To: Alexander Graf
Cc: qemu-ppc@nongnu.org List, Caraman Mihai Claudiu-B02008,
linuxppc-dev, KVM list, <kvm-ppc@vger.kernel.org>
In-Reply-To: <EED22D54-8B0F-4EAE-BA70-C5C086DBB7C1@suse.de>
On Thu, 2012-07-12 at 00:25 +0200, Alexander Graf wrote:
> Or just free up another register early on, like here.
If you're going to do that, you want to measure the impact on null
syscall performance though.
Cheers,
Ben.
^ permalink raw reply
* Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add DO_KVM kernel hooks
From: Alexander Graf @ 2012-07-11 22:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: qemu-ppc@nongnu.org List, Caraman Mihai Claudiu-B02008,
linuxppc-dev, KVM list, <kvm-ppc@vger.kernel.org>
In-Reply-To: <1342045680.18850.39.camel@pasglop>
On 12.07.2012, at 00:28, Benjamin Herrenschmidt wrote:
> On Thu, 2012-07-12 at 00:25 +0200, Alexander Graf wrote:
>> Or just free up another register early on, like here.
>
> If you're going to do that, you want to measure the impact on null
> syscall performance though.
That should hold true for any change in that code, no?
Alex
^ permalink raw reply
* Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add DO_KVM kernel hooks
From: Benjamin Herrenschmidt @ 2012-07-11 22:43 UTC (permalink / raw)
To: Alexander Graf
Cc: qemu-ppc@nongnu.org List, Caraman Mihai Claudiu-B02008,
linuxppc-dev, KVM list, <kvm-ppc@vger.kernel.org>
In-Reply-To: <FE8CCAFA-454E-461A-96E8-64E8E3D186EE@suse.de>
On Thu, 2012-07-12 at 00:35 +0200, Alexander Graf wrote:
> > On Thu, 2012-07-12 at 00:25 +0200, Alexander Graf wrote:
> >> Or just free up another register early on, like here.
> >
> > If you're going to do that, you want to measure the impact on null
> > syscall performance though.
>
> That should hold true for any change in that code, no?
Yes, but adding a gpr save is more invasive (you have to also load it
back later on & put it on the stack).
Cheers,
Ben.
^ permalink raw reply
* Re: [Qemu-ppc] [RFC PATCH 12/17] PowerPC: booke64: Add DO_KVM kernel hooks
From: Alexander Graf @ 2012-07-11 22:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: qemu-ppc@nongnu.org List, Caraman Mihai Claudiu-B02008,
linuxppc-dev, KVM list, <kvm-ppc@vger.kernel.org>
In-Reply-To: <1342046584.18850.40.camel@pasglop>
On 12.07.2012, at 00:43, Benjamin Herrenschmidt wrote:
> On Thu, 2012-07-12 at 00:35 +0200, Alexander Graf wrote:
>>> On Thu, 2012-07-12 at 00:25 +0200, Alexander Graf wrote:
>>>> Or just free up another register early on, like here.
>>>=20
>>> If you're going to do that, you want to measure the impact on null
>>> syscall performance though.
>>=20
>> That should hold true for any change in that code, no?
>=20
> Yes, but adding a gpr save is more invasive (you have to also load it
> back later on & put it on the stack).
What's the usual cache line size like on these boxes? If you align it =
properly with r10 and r11 on the paca so that all 3 registers are in the =
same cache line, the load should be almost for free, no?
Alex
^ permalink raw reply
* RE: [PATCH v2 2/4] fsl-dma: remove attribute DMA_INTERRUPT of dmaengine
From: Liu Qiang-B32616 @ 2012-07-12 2:33 UTC (permalink / raw)
To: Ira W. Snyder
Cc: Vinod Koul, davem@davemloft.net, linux-crypto@vger.kernel.org,
Dan Williams, linuxppc-dev@lists.ozlabs.org,
herbert@gondor.hengli.org.au
In-Reply-To: <20120711161713.GC17539@ovro.caltech.edu>
> -----Original Message-----
> From: Ira W. Snyder [mailto:iws@ovro.caltech.edu]
> Sent: Thursday, July 12, 2012 12:17 AM
> To: Liu Qiang-B32616
> Cc: linux-crypto@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Vinod
> Koul; herbert@gondor.hengli.com.au; Dan Williams; davem@davemloft.net
> Subject: Re: [PATCH v2 2/4] fsl-dma: remove attribute DMA_INTERRUPT of
> dmaengine
>=20
> On Wed, Jul 11, 2012 at 05:00:53PM +0800, Qiang Liu wrote:
> > Delete attribute DMA_INTERRUPT because fsl-dma doesn't support this
> function,
> > exception will be thrown if talitos is used to offload xor at the same
> time.
> >
>=20
> Both drivers/misc/carma/carma-fpga.c and
> drivers/misc/carma/carma-fpga-program.c expect the DMA_INTERRUPT
> property, though they do not use it. The mask is set for historical
> reasons. It is safe to delete the line "dma_cap_set(DMA_INTERRUPT,
> mask);"
> from both drivers.
>=20
> I don't know which other drivers may expect this feature to be present.
> These are only the ones which I maintain.
The only place is in async_tx api which the feature is used. But it does no=
t
work fine as expected of DMA_INTERRUPT. In fsl-dma, it will raise a program
error if source or destination address is zero.
>=20
> Other than that, you can add my:
> Acked-by: Ira W. Snyder <iws@ovro.caltech.edu>
Thanks.
>=20
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Cc: Vinod Koul <vinod.koul@intel.com>
> > Cc: Li Yang <leoli@freescale.com>
> > Signed-off-by: Qiang Liu <qiang.liu@freescale.com>
> > ---
> > drivers/dma/fsldma.c | 31 -------------------------------
> > 1 files changed, 0 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> > index 8f84761..4f2f212 100644
> > --- a/drivers/dma/fsldma.c
> > +++ b/drivers/dma/fsldma.c
> > @@ -543,35 +543,6 @@ static void fsl_dma_free_chan_resources(struct
> dma_chan *dchan)
> > }
> >
> > static struct dma_async_tx_descriptor *
> > -fsl_dma_prep_interrupt(struct dma_chan *dchan, unsigned long flags)
> > -{
> > - struct fsldma_chan *chan;
> > - struct fsl_desc_sw *new;
> > -
> > - if (!dchan)
> > - return NULL;
> > -
> > - chan =3D to_fsl_chan(dchan);
> > -
> > - new =3D fsl_dma_alloc_descriptor(chan);
> > - if (!new) {
> > - chan_err(chan, "%s\n", msg_ld_oom);
> > - return NULL;
> > - }
> > -
> > - new->async_tx.cookie =3D -EBUSY;
> > - new->async_tx.flags =3D flags;
> > -
> > - /* Insert the link descriptor to the LD ring */
> > - list_add_tail(&new->node, &new->tx_list);
> > -
> > - /* Set End-of-link to the last link descriptor of new list */
> > - set_ld_eol(chan, new);
> > -
> > - return &new->async_tx;
> > -}
> > -
> > -static struct dma_async_tx_descriptor *
> > fsl_dma_prep_memcpy(struct dma_chan *dchan,
> > dma_addr_t dma_dst, dma_addr_t dma_src,
> > size_t len, unsigned long flags)
> > @@ -1352,12 +1323,10 @@ static int __devinit fsldma_of_probe(struct
> platform_device *op)
> > fdev->irq =3D irq_of_parse_and_map(op->dev.of_node, 0);
> >
> > dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
> > - dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
> > dma_cap_set(DMA_SG, fdev->common.cap_mask);
> > dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
> > fdev->common.device_alloc_chan_resources =3D
> fsl_dma_alloc_chan_resources;
> > fdev->common.device_free_chan_resources =3D
> fsl_dma_free_chan_resources;
> > - fdev->common.device_prep_dma_interrupt =3D fsl_dma_prep_interrupt;
> > fdev->common.device_prep_dma_memcpy =3D fsl_dma_prep_memcpy;
> > fdev->common.device_prep_dma_sg =3D fsl_dma_prep_sg;
> > fdev->common.device_tx_status =3D fsl_tx_status;
> > --
> > 1.7.5.1
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
^ 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