Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
On Fri, Sep 06, 2013 at 09:38:21AM +1000, Alexey Kardashevskiy wrote:
On 09/06/2013 04:10 AM, Gleb Natapov wrote:
On Wed, Sep 04, 2013 at 02:01:28AM +1000, Alexey Kardashevskiy wrote:
On 09/03/2013 08:53 PM, Gleb Natapov wrote:
On Mon, Sep 02, 2013 at 01:14:29PM +1000, Alexey Kardashevskiy wrote:
On 09/01/2013 10:06 PM, Gleb Natapov wrote:
On Wed, Aug 28, 2013 at 06:50:41PM +1000, Alexey Kardashevskiy wrote:
This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
them to user space which saves time on switching to user space and
back.
Both real and virtual modes are supported. The kernel tries to
handle a TCE request in the real mode, if fails it passes the request
to the virtual mode to complete the operation. If it a virtual mode
handler fails, the request is passed to user space.
The first user of this is VFIO on POWER. Trampolines to the VFIO
external
user API functions are required for this patch.
This adds a SPAPR TCE IOMMU KVM device to associate a logical bus
number (LIOBN) with an VFIO IOMMU group fd and enable in-kernel
handling
of map/unmap requests. The device supports a single attribute which is
a struct with LIOBN and IOMMU fd. When the attribute is set, the device
establishes the connection between KVM and VFIO.
Tests show that this patch increases transmission speed from 220MB/s
to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
Signed-off-by: Paul Mackerras pau...@samba.org
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v9:
* KVM_CAP_SPAPR_TCE_IOMMU ioctl to KVM replaced with SPAPR TCE IOMMU
KVM device
* release_spapr_tce_table() is not shared between different TCE types
* reduced the patch size by moving VFIO external API
trampolines to separate patche
* moved documentation from Documentation/virtual/kvm/api.txt to
Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
v8:
* fixed warnings from check_patch.pl
2013/07/11:
* removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
for KVM_BOOK3S_64
* kvmppc_gpa_to_hva_and_get also returns host phys address. Not much
sense
for this here but the next patch for hugepages support will use it
more.
2013/07/06:
* added realmode arch_spin_lock to protect TCE table from races
in real and virtual modes
* POWERPC IOMMU API is changed to support real mode
* iommu_take_ownership and iommu_release_ownership are protected by
iommu_table's locks
* VFIO external user API use rewritten
* multiple small fixes
2013/06/27:
* tce_list page is referenced now in order to protect it from accident
invalidation during H_PUT_TCE_INDIRECT execution
* added use of the external user VFIO API
2013/06/05:
* changed capability number
* changed ioctl number
* update the doc article number
2013/05/20:
* removed get_user() from real mode handlers
* kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts
there
translated TCEs, tries realmode_get_page() on those and if it fails, it
passes control over the virtual mode handler which tries to finish
the request handling
* kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY
bit
on a page
* The only reason to pass the request to user mode now is when the
user mode
did not register TCE table in the kernel, in all other cases the
virtual mode
handler is expected to do the job
---
.../virtual/kvm/devices/spapr_tce_iommu.txt| 37 +++
arch/powerpc/include/asm/kvm_host.h| 4 +
arch/powerpc/kvm/book3s_64_vio.c | 310
-
arch/powerpc/kvm/book3s_64_vio_hv.c| 122
arch/powerpc/kvm/powerpc.c | 1 +
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c| 5 +
7 files changed, 477 insertions(+), 3 deletions(-)
create mode 100644
Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
diff --git a/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
new file mode 100644
index 000..4bc8fc3
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
@@ -0,0 +1,37 @@
+SPAPR TCE IOMMU device
+
+Capability: KVM_CAP_SPAPR_TCE_IOMMU
+Architectures: powerpc
+
+Device type supported: KVM_DEV_TYPE_SPAPR_TCE_IOMMU
+
+Groups:
+ KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE
+ Attributes: single attribute with pair { LIOBN, IOMMU fd}
+
+This is completely made up device which provides API to link
+logical bus number (LIOBN) and IOMMU group. The user space has
+to create a new SPAPR TCE IOMMU device per a logical bus.
+
Why not have one device that can handle multimple links?
I can do that. If I make it so, it
Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
On 09/06/2013 04:01 PM, Gleb Natapov wrote:
On Fri, Sep 06, 2013 at 09:38:21AM +1000, Alexey Kardashevskiy wrote:
On 09/06/2013 04:10 AM, Gleb Natapov wrote:
On Wed, Sep 04, 2013 at 02:01:28AM +1000, Alexey Kardashevskiy wrote:
On 09/03/2013 08:53 PM, Gleb Natapov wrote:
On Mon, Sep 02, 2013 at 01:14:29PM +1000, Alexey Kardashevskiy wrote:
On 09/01/2013 10:06 PM, Gleb Natapov wrote:
On Wed, Aug 28, 2013 at 06:50:41PM +1000, Alexey Kardashevskiy wrote:
This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
them to user space which saves time on switching to user space and
back.
Both real and virtual modes are supported. The kernel tries to
handle a TCE request in the real mode, if fails it passes the request
to the virtual mode to complete the operation. If it a virtual mode
handler fails, the request is passed to user space.
The first user of this is VFIO on POWER. Trampolines to the VFIO
external
user API functions are required for this patch.
This adds a SPAPR TCE IOMMU KVM device to associate a logical bus
number (LIOBN) with an VFIO IOMMU group fd and enable in-kernel
handling
of map/unmap requests. The device supports a single attribute which is
a struct with LIOBN and IOMMU fd. When the attribute is set, the device
establishes the connection between KVM and VFIO.
Tests show that this patch increases transmission speed from 220MB/s
to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
Signed-off-by: Paul Mackerras pau...@samba.org
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v9:
* KVM_CAP_SPAPR_TCE_IOMMU ioctl to KVM replaced with SPAPR TCE IOMMU
KVM device
* release_spapr_tce_table() is not shared between different TCE types
* reduced the patch size by moving VFIO external API
trampolines to separate patche
* moved documentation from Documentation/virtual/kvm/api.txt to
Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
v8:
* fixed warnings from check_patch.pl
2013/07/11:
* removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
for KVM_BOOK3S_64
* kvmppc_gpa_to_hva_and_get also returns host phys address. Not much
sense
for this here but the next patch for hugepages support will use it
more.
2013/07/06:
* added realmode arch_spin_lock to protect TCE table from races
in real and virtual modes
* POWERPC IOMMU API is changed to support real mode
* iommu_take_ownership and iommu_release_ownership are protected by
iommu_table's locks
* VFIO external user API use rewritten
* multiple small fixes
2013/06/27:
* tce_list page is referenced now in order to protect it from accident
invalidation during H_PUT_TCE_INDIRECT execution
* added use of the external user VFIO API
2013/06/05:
* changed capability number
* changed ioctl number
* update the doc article number
2013/05/20:
* removed get_user() from real mode handlers
* kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts
there
translated TCEs, tries realmode_get_page() on those and if it fails, it
passes control over the virtual mode handler which tries to finish
the request handling
* kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY
bit
on a page
* The only reason to pass the request to user mode now is when the
user mode
did not register TCE table in the kernel, in all other cases the
virtual mode
handler is expected to do the job
---
.../virtual/kvm/devices/spapr_tce_iommu.txt| 37 +++
arch/powerpc/include/asm/kvm_host.h| 4 +
arch/powerpc/kvm/book3s_64_vio.c | 310
-
arch/powerpc/kvm/book3s_64_vio_hv.c| 122
arch/powerpc/kvm/powerpc.c | 1 +
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c| 5 +
7 files changed, 477 insertions(+), 3 deletions(-)
create mode 100644
Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
diff --git a/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
new file mode 100644
index 000..4bc8fc3
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
@@ -0,0 +1,37 @@
+SPAPR TCE IOMMU device
+
+Capability: KVM_CAP_SPAPR_TCE_IOMMU
+Architectures: powerpc
+
+Device type supported: KVM_DEV_TYPE_SPAPR_TCE_IOMMU
+
+Groups:
+ KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE
+ Attributes: single attribute with pair { LIOBN, IOMMU fd}
+
+This is completely made up device which provides API to link
+logical bus number (LIOBN) and IOMMU group. The user space has
+to create a new SPAPR TCE IOMMU device per a logical bus.
+
Why not have one device that can handle multimple links?
I can do that. If I make it so, it won't even look as a device at all,
just
some weird interface to KVM but ok. What
Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
On Thu, Sep 05, 2013 at 02:05:09PM +1000, Benjamin Herrenschmidt wrote: On Tue, 2013-09-03 at 13:53 +0300, Gleb Natapov wrote: Or supporting all IOMMU links (and leaving emulated stuff as is) in on device is the last thing I have to do and then you'll ack the patch? I am concerned more about API here. Internal implementation details I leave to powerpc experts :) So Gleb, I want to step in for a bit here. While I understand that the new KVM device API is all nice and shiny and that this whole thing should probably have been KVM devices in the first place (had they existed or had we been told back then), the point is, the API for handling HW IOMMUs that Alexey is trying to add is an extension of an existing mechanism used for emulated IOMMUs. The internal data structure is shared, and fundamentally, by forcing him to use that new KVM device for the new stuff, we create a oddball API with an ioctl for one type of iommu and a KVM device for the other, which makes the implementation a complete mess in the kernel (and you should care :-) Is it unfixable mess? Even if Alexey will do what you suggested earlier? - Convert *both* existing TCE objects to the new KVM_CREATE_DEVICE, and have some backward compat code for the old one. The point is implementation usually can be changed, but for API it is much harder to do so. So for something completely new, I would tend to agree with you. However, I still think that for this specific case, we should just plonk-in the original ioctl proposed by Alexey and be done with it. Do you think this is the last extension to IOMMU code, or we will see more and will use same justification to continue adding ioctls? -- Gleb. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
On 09/06/2013 04:57 PM, Gleb Natapov wrote: On Thu, Sep 05, 2013 at 02:05:09PM +1000, Benjamin Herrenschmidt wrote: On Tue, 2013-09-03 at 13:53 +0300, Gleb Natapov wrote: Or supporting all IOMMU links (and leaving emulated stuff as is) in on device is the last thing I have to do and then you'll ack the patch? I am concerned more about API here. Internal implementation details I leave to powerpc experts :) So Gleb, I want to step in for a bit here. While I understand that the new KVM device API is all nice and shiny and that this whole thing should probably have been KVM devices in the first place (had they existed or had we been told back then), the point is, the API for handling HW IOMMUs that Alexey is trying to add is an extension of an existing mechanism used for emulated IOMMUs. The internal data structure is shared, and fundamentally, by forcing him to use that new KVM device for the new stuff, we create a oddball API with an ioctl for one type of iommu and a KVM device for the other, which makes the implementation a complete mess in the kernel (and you should care :-) Is it unfixable mess? Even if Alexey will do what you suggested earlier? - Convert *both* existing TCE objects to the new KVM_CREATE_DEVICE, and have some backward compat code for the old one. If we convert *old*, then for compatibility we will need one KVM device (more precisely, one fd) per an TCE object (not one for all TCE objects) as the guest (upstream QEMU) will mmap the table via mmap() and it won't use any offset when mapping this fd. The current KVM device implementation does not even support mmap(). So I would go with the KVM device patch I posted and really want to avoid putting all TCEs into one device. The point is implementation usually can be changed, but for API it is much harder to do so. So for something completely new, I would tend to agree with you. However, I still think that for this specific case, we should just plonk-in the original ioctl proposed by Alexey and be done with it. Do you think this is the last extension to IOMMU code, or we will see more and will use same justification to continue adding ioctls? -- Alexey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: DTS - re-organize the SPI partitions property
Re-organize the SPI partitions and use the same SPI flash memory
map for most of the platforms which have 16MB SPI flash mounted.
1. Extend the U-Boot partition to 1MB
The image for booting from SPI is larger than 512KB, while
the size of U-Boot partition is 512KB on some boards, so
enlarge it to 1MB in order to contain the whole U-Boot image.
2. Reserve space for U-Boot environment variables
The environment variables are stored at offset 0x10, so
if other image was put at this address, it'll be overlapped
when saving the environment variables.
3. Reserve space for FMAN ucode
The FMAN ucode is required on DPAA platform and is stored at
offset 0x11, this address should not be used to store any
other images.
4. Extend the kernel partition to 5MB
Here is diagram for the SPI flash memory map:
0x00 |-|
| U-Boot |
| (1MB) |
0x10 |-|
| Env(64KB) |
0x11 |-|
| ucode |
0x18 |-|
| DTB |
| (512KB) |
0x20 |-|
| kernel |
| (5MB) |
0x70 |-|
| file system |
| (9MB) |
0x100 |-|
Signed-off-by: Mingkai Hu mingkai...@freescale.com
---
Based on 'next' branch on git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
arch/powerpc/boot/dts/bsc9131rdb.dtsi | 35 -
arch/powerpc/boot/dts/c293pcie.dts | 35 -
arch/powerpc/boot/dts/mpc8536ds.dtsi | 12 +-
arch/powerpc/boot/dts/p1010rdb.dtsi| 40 --
arch/powerpc/boot/dts/p1020rdb-pc.dtsi | 24 +---
arch/powerpc/boot/dts/p1020rdb-pd.dts | 34 -
arch/powerpc/boot/dts/p1020rdb.dtsi| 23 ---
arch/powerpc/boot/dts/p1021mds.dts | 17 +++
arch/powerpc/boot/dts/p1021rdb-pc.dtsi | 32 +--
arch/powerpc/boot/dts/p1022ds.dtsi | 21 +-
arch/powerpc/boot/dts/p1023rds.dts | 10 ++---
arch/powerpc/boot/dts/p1024rdb.dtsi| 40 --
arch/powerpc/boot/dts/p1025rdb.dtsi| 23 +--
arch/powerpc/boot/dts/p2020rdb-pc.dtsi | 40 --
arch/powerpc/boot/dts/p2020rdb.dts | 38 ++--
arch/powerpc/boot/dts/p2041rdb.dts | 12 +-
arch/powerpc/boot/dts/p3041ds.dts | 12 +-
arch/powerpc/boot/dts/p4080ds.dts | 12 +-
arch/powerpc/boot/dts/p5020ds.dts | 12 +-
arch/powerpc/boot/dts/p5040ds.dts | 13 ++-
20 files changed, 180 insertions(+), 305 deletions(-)
diff --git a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
index 9e6c013..8250593 100644
--- a/arch/powerpc/boot/dts/bsc9131rdb.dtsi
+++ b/arch/powerpc/boot/dts/bsc9131rdb.dtsi
@@ -81,32 +81,25 @@
compatible = spansion,s25sl12801;
reg = 0;
spi-max-frequency = 5000;
-
- /* 512KB for u-boot Bootloader Image */
- partition@0 {
- reg = 0x0 0x0008;
- label = SPI Flash U-Boot Image;
+ partition@u-boot {
+ label = u-boot;
+ reg = 0x 0x0010;
read-only;
};
-
- /* 512KB for DTB Image */
- partition@8 {
- reg = 0x0008 0x0008;
- label = SPI Flash DTB Image;
+ partition@dtb {
+ label = dtb;
+ reg = 0x0018 0x0008;
+ read-only;
};
-
- /* 4MB for Linux Kernel Image */
- partition@10 {
- reg = 0x0010 0x0040;
- label = SPI Flash Kernel Image;
+ partition@kernel {
+ label = kernel;
+ reg = 0x0020 0x0050;
+ read-only;
};
-
- /*11MB for RFS Image */
- partition@50 {
- reg = 0x0050 0x00B0;
- label = SPI Flash RFS Image;
+ partition@fs {
+ label = file system;
+ reg =
RE: [PATCH V3 1/2] powerpc/85xx: Add QE common init functions
Hi Scott, I already remove these code from the P1025TWR platform file(see the 2/2 patch). Do you means I also need to remove these codes from the others platforms and use the common call instead? Thank you. Best Regards Xie Xiaobo -Original Message- From: Wood Scott-B07421 Sent: Thursday, September 05, 2013 12:27 AM To: Xie Xiaobo-R63061 Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org Subject: Re: [PATCH V3 1/2] powerpc/85xx: Add QE common init functions On Mon, 2013-09-02 at 18:11 +0800, Xie Xiaobo wrote: Define two QE init functions in common file, and avoid the same codes being duplicated in board files. Signed-off-by: Xie Xiaobo x@freescale.com --- V3 - V2: Nochange arch/powerpc/platforms/85xx/common.c | 47 +++ arch/powerpc/platforms/85xx/mpc85xx.h | 8 ++ 2 files changed, 55 insertions(+) Don't just copy it; remove it from the place you copied from and have that code call the common version. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH V3 2/2] powerpc/85xx: Add TWR-P1025 board support
Hi Scott,
Thanks for your reminding and advice.
I discuss this with Liu Shengzhou(the first person that remind me
#interrupt-cells is 4), he advised removing the interrupts property from the
phy node, because the mdio used the poll way preferentially.
Best Regards
Xie Xiaobo
-Original Message-
From: Wood Scott-B07421
Sent: Thursday, September 05, 2013 12:26 AM
To: Xie Xiaobo-R63061
Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org; Johnston
Michael-R49610
Subject: Re: [PATCH V3 2/2] powerpc/85xx: Add TWR-P1025 board support
On Mon, 2013-09-02 at 18:11 +0800, Xie Xiaobo wrote:
+soc {
+ usb@22000 {
+ phy_type = ulpi;
+ };
+
+ mdio@24000 {
+ phy0: ethernet-phy@2 {
+ interrupt-parent = mpic;
+ interrupts = 1 1;
+ reg = 0x2;
+ };
+
+ phy1: ethernet-phy@1 {
+ interrupt-parent = mpic;
+ interrupts = 2 1;
+ reg = 0x1;
+ };
Again, #interrupt-cells is 4.
Please respond to feedback rather than ignoring it and reposting the same thing
without comment.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v10 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
This allows the host kernel to handle H_PUT_TCE, H_PUT_TCE_INDIRECT
and H_STUFF_TCE requests targeted an IOMMU TCE table without passing
them to user space which saves time on switching to user space and back.
Both real and virtual modes are supported. The kernel tries to
handle a TCE request in the real mode, if fails it passes the request
to the virtual mode to complete the operation. If it a virtual mode
handler fails, the request is passed to user space.
The first user of this is VFIO on POWER. Trampolines to the VFIO external
user API functions are required for this patch.
This adds a SPAPR TCE IOMMU KVM device to associate a logical bus
number (LIOBN) with an VFIO IOMMU group fd and enable in-kernel handling
of map/unmap requests. The device supports a single attribute which is
a struct with LIOBN and IOMMU fd. When the attribute is set, the device
establishes the connection between KVM and VFIO.
Tests show that this patch increases transmission speed from 220MB/s
to 750..1020MB/s on 10Gb network (Chelsea CXGB3 10Gb ethernet card).
Signed-off-by: Paul Mackerras pau...@samba.org
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v10:
* all IOMMU TCE links are handled by one KVM device now
* KVM device has its own list of TCE descriptors
* the search-by-liobn function was extended to search through
emulated and IOMMU lists
v9:
* KVM_CAP_SPAPR_TCE_IOMMU ioctl to KVM replaced with SPAPR TCE IOMMU
KVM device
* release_spapr_tce_table() is not shared between different TCE types
* reduced the patch size by moving KVM device bits and VFIO external API
trampolines to separate patches
* moved documentation from Documentation/virtual/kvm/api.txt to
Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
v8:
* fixed warnings from check_patch.pl
2013/07/11:
* removed multiple #ifdef IOMMU_API as IOMMU_API is always enabled
for KVM_BOOK3S_64
* kvmppc_gpa_to_hva_and_get also returns host phys address. Not much sense
for this here but the next patch for hugepages support will use it more.
2013/07/06:
* added realmode arch_spin_lock to protect TCE table from races
in real and virtual modes
* POWERPC IOMMU API is changed to support real mode
* iommu_take_ownership and iommu_release_ownership are protected by
iommu_table's locks
* VFIO external user API use rewritten
* multiple small fixes
2013/06/27:
* tce_list page is referenced now in order to protect it from accident
invalidation during H_PUT_TCE_INDIRECT execution
* added use of the external user VFIO API
2013/06/05:
* changed capability number
* changed ioctl number
* update the doc article number
2013/05/20:
* removed get_user() from real mode handlers
* kvm_vcpu_arch::tce_tmp usage extended. Now real mode handler puts there
translated TCEs, tries realmode_get_page() on those and if it fails, it
passes control over the virtual mode handler which tries to finish
the request handling
* kvmppc_lookup_pte() now does realmode_get_page() protected by BUSY bit
on a page
* The only reason to pass the request to user mode now is when the user mode
did not register TCE table in the kernel, in all other cases the virtual mode
handler is expected to do the job
---
.../virtual/kvm/devices/spapr_tce_iommu.txt| 40 +++
arch/powerpc/include/asm/kvm_host.h| 8 +
arch/powerpc/include/uapi/asm/kvm.h| 5 -
arch/powerpc/kvm/book3s_64_vio.c | 327 -
arch/powerpc/kvm/book3s_64_vio_hv.c| 142 +
arch/powerpc/kvm/powerpc.c | 1 +
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c| 5 +
8 files changed, 517 insertions(+), 12 deletions(-)
create mode 100644 Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
diff --git a/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
new file mode 100644
index 000..b911945
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/spapr_tce_iommu.txt
@@ -0,0 +1,40 @@
+SPAPR TCE IOMMU device
+
+Capability: KVM_CAP_SPAPR_TCE_IOMMU
+Architectures: powerpc
+
+Device type supported: KVM_DEV_TYPE_SPAPR_TCE_IOMMU
+
+Groups:
+ KVM_DEV_SPAPR_TCE_IOMMU_ATTR_LINKAGE
+ Attributes: one VFIO IOMMU fd per LIOBN, indexed by LIOBN
+
+This is completely made up device which provides API to link
+logical bus number (LIOBN) and IOMMU group. The user space has
+to create a new SPAPR TCE IOMMU device once per KVM session
+and use set_attr to add or remove a logical bus.
+
+LIOBN is a PCI bus identifier from PPC64-server (sPAPR) DMA hypercalls
+(H_PUT_TCE, H_PUT_TCE_INDIRECT, H_STUFF_TCE).
+IOMMU group is a minimal isolated device set which can be passed to
+the user space via VFIO.
+
+The userspace adds the new LIOBN-IOMMU link by calling KVM_SET_DEVICE_ATTR
+with the attribute initialized as shown below:
+struct kvm_device_attr attr = {
+ .flags = 0,
+ .group =
[PATCH v3 0/8] Getting rid of get_unused_fd() / use O_CLOEXEC
Hi, With help from subsystem maintainers, I've managed to get some of get_unused_fd() calls converted to use get_unused_fd_flags(O_CLOEXEC) instead. [ANDROID][IB][VFIO] KVM subsystem maintainers helped me to change calls to anon_inode_getfd() to use O_CLOEXEC by default. [KVM] Some maintainers applied my patches to convert get_unused_fd() to get_unused_fd_flags(0) were using O_CLOEXEC wasn't possible without breaking ABI. [SCTP][XFS] So, still in the hope to get rid of get_unused_fd(), please find a another attempt to remove get_unused_fd() macro and encourage subsystems to use get_unused_fd_flags(O_CLOEXEC) or anon_inode_getfd(O_CLOEXEC) by default were appropriate. The patchset convert all calls to get_unused_fd() to get_unused_fd_flags(0) before removing get_unused_fd() macro. Without get_unused_fd() macro, more subsystems are likely to use anon_inode_getfd() and be teached to provide an API that let userspace choose the opening flags of the file descriptor. Additionally I'm suggesting Industrial IO (IIO) subsystem to use anon_inode_getfd(O_CLOEXEC): it's the only subsystem using anon_inode_getfd() with a fixed set of flags not including O_CLOEXEC. Not using O_CLOEXEC by default or not letting userspace provide the open flags should be considered bad practice from security point of view: in most case O_CLOEXEC must be used to not leak file descriptor across exec(). Using O_CLOEXEC by default when flags are not provided by userspace allows it to choose, without race, if the file descriptor is going to be inherited across exec(). Status: In linux-next tag 20130906, they're currently: - 22 calls to get_unused_fd_flags() (+3) not counting get_unused_fd() and anon_inode_getfd() - 7 calls to get_unused_fd() (-3) - 11 calls to anon_inode_getfd()(0) Changes from patchset v2 [PATCHSETv2]: - android/sw_sync: use get_unused_fd_flags(O_CLOEXEC) instead of get_unused_fd() DROPPED: applied upstream - android/sync: use get_unused_fd_flags(O_CLOEXEC) instead of get_unused_fd() DROPPED: applied upstream - vfio: use get_unused_fd_flags(0) instead of get_unused_fd() DROPPED: applied upstream. Additionally subsystem maintainer applied another patch on top to set the flags to O_CLOEXEC. - industrialio: use anon_inode_getfd() with O_CLOEXEC flag NEW: propose to use O_CLOEXEC as default flag. Links: [ANDROID] http://lkml.kernel.org/r/cacsp8sjxgmk2_kx_+rgzqqqwqkernvf1wt3k5tw991w5dfa...@mail.gmail.com http://lkml.kernel.org/r/CACSP8SjZcpcpEtQHzcGYhf-MP7QGo0XpN7-uN7rmD=vNtopG=w...@mail.gmail.com [IB] http://lkml.kernel.org/r/CAL1RGDXV1_BjSLrQDFdVQ1_D75+bMtOtikHOUp8VBiy_OJUf=w...@mail.gmail.com [VFIO] http://lkml.kernel.org/r/20130822171744.1297.13711.st...@bling.home [KVM] http://lkml.kernel.org/r/5219a8fc.8090...@redhat.com http://lkml.kernel.org/r/3557ef65-4327-4dae-999a-b0ee13c43...@suse.de http://lkml.kernel.org/r/20130826102023.ga8...@redhat.com [SCTP] http://lkml.kernel.org/r/51d312e8.6090...@gmail.com http://lkml.kernel.org/r/20130702.161428.1703028286206350504.da...@davemloft.net [XFS] http://lkml.kernel.org/r/20130709205321.gv20...@sgi.com [PATCHSETv2] http://lkml.kernel.org/r/cover.1376327678.git.ydrone...@opteya.com Yann Droneaud (8): ia64: use get_unused_fd_flags(0) instead of get_unused_fd() ppc/cell: use get_unused_fd_flags(0) instead of get_unused_fd() binfmt_misc: use get_unused_fd_flags(0) instead of get_unused_fd() file: use get_unused_fd_flags(0) instead of get_unused_fd() fanotify: use get_unused_fd_flags(0) instead of get_unused_fd() events: use get_unused_fd_flags(0) instead of get_unused_fd() file: remove get_unused_fd() industrialio: use anon_inode_getfd() with O_CLOEXEC flag arch/ia64/kernel/perfmon.c| 2 +- arch/powerpc/platforms/cell/spufs/inode.c | 4 ++-- drivers/iio/industrialio-event.c | 2 +- fs/binfmt_misc.c | 2 +- fs/file.c | 2 +- fs/notify/fanotify/fanotify_user.c| 2 +- include/linux/file.h | 1 - kernel/events/core.c | 2 +- 8 files changed, 8 insertions(+), 9 deletions(-) -- 1.8.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 2/8] ppc/cell: use get_unused_fd_flags(0) instead of get_unused_fd()
Macro get_unused_fd() is used to allocate a file descriptor with default flags. Those default flags (0) can be unsafe: O_CLOEXEC must be used by default to not leak file descriptor across exec(). Instead of macro get_unused_fd(), functions anon_inode_getfd() or get_unused_fd_flags() should be used with flags given by userspace. If not possible, flags should be set to O_CLOEXEC to provide userspace with a default safe behavor. In a further patch, get_unused_fd() will be removed so that new code start using anon_inode_getfd() or get_unused_fd_flags() with correct flags. This patch replaces calls to get_unused_fd() with equivalent call to get_unused_fd_flags(0) to preserve current behavor for existing code. The hard coded flag value (0) should be reviewed on a per-subsystem basis, and, if possible, set to O_CLOEXEC. Signed-off-by: Yann Droneaud ydrone...@opteya.com Link: http://lkml.kernel.org/r/cover.1378460926.git.ydrone...@opteya.com --- arch/powerpc/platforms/cell/spufs/inode.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c index 87ba7cf..51effce 100644 --- a/arch/powerpc/platforms/cell/spufs/inode.c +++ b/arch/powerpc/platforms/cell/spufs/inode.c @@ -301,7 +301,7 @@ static int spufs_context_open(struct path *path) int ret; struct file *filp; - ret = get_unused_fd(); + ret = get_unused_fd_flags(0); if (ret 0) return ret; @@ -518,7 +518,7 @@ static int spufs_gang_open(struct path *path) int ret; struct file *filp; - ret = get_unused_fd(); + ret = get_unused_fd_flags(0); if (ret 0) return ret; -- 1.8.3.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v9 12/13] KVM: PPC: Add support for IOMMU in-kernel handling
On 09/06/2013 04:57 PM, Gleb Natapov wrote: On Thu, Sep 05, 2013 at 02:05:09PM +1000, Benjamin Herrenschmidt wrote: On Tue, 2013-09-03 at 13:53 +0300, Gleb Natapov wrote: Or supporting all IOMMU links (and leaving emulated stuff as is) in on device is the last thing I have to do and then you'll ack the patch? I am concerned more about API here. Internal implementation details I leave to powerpc experts :) So Gleb, I want to step in for a bit here. While I understand that the new KVM device API is all nice and shiny and that this whole thing should probably have been KVM devices in the first place (had they existed or had we been told back then), the point is, the API for handling HW IOMMUs that Alexey is trying to add is an extension of an existing mechanism used for emulated IOMMUs. The internal data structure is shared, and fundamentally, by forcing him to use that new KVM device for the new stuff, we create a oddball API with an ioctl for one type of iommu and a KVM device for the other, which makes the implementation a complete mess in the kernel (and you should care :-) Is it unfixable mess? Even if Alexey will do what you suggested earlier? - Convert *both* existing TCE objects to the new KVM_CREATE_DEVICE, and have some backward compat code for the old one. The point is implementation usually can be changed, but for API it is much harder to do so. So for something completely new, I would tend to agree with you. However, I still think that for this specific case, we should just plonk-in the original ioctl proposed by Alexey and be done with it. Do you think this is the last extension to IOMMU code, or we will see more and will use same justification to continue adding ioctls? Ok. I give up :) I implemented KVM device the way you suggested. Could you please have a look? It is [PATCH v10 12/13] KVM: PPC: Add support for IOMMU in-kernel handling, attached to this thread. Thanks! -- Alexey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
On Thu, 2013-09-05 at 21:30 -0500, Tang Yuantian-B29983 wrote: -Original Message- From: Wood Scott-B07421 Sent: 2013年9月6日 星期五 2:41 To: Tang Yuantian-B29983 Cc: Yang,Wei; Jia Hongtao-B38951; Wood Scott-B07421; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS On Tue, 2013-09-03 at 22:30 -0500, Tang Yuantian-B29983 wrote: Hi, These eeproms are never used by kernel. So no need to add them. The device tree describes the hardware, not what Linux does with it. Missing some nodes doesn't mean it is not describing the hardware. There are almost fifty I2C devices on T4 connected to PCA9547. Do you think we need to list them all? Ideally, yes. I realize it's not uncommon for some things to be missing, but that's not a reason to tell people to leave things out just because Linux doesn't use them. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 1/2] powerpc/85xx: Add QE common init functions
On Fri, 2013-09-06 at 04:52 -0500, Xie Xiaobo-R63061 wrote: Hi Scott, I already remove these code from the P1025TWR platform file(see the 2/2 patch). Do you means I also need to remove these codes from the others platforms and use the common call instead? Thank you. Yes. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
On Sep 5, 2013, at 1:37 PM, Scott Wood wrote: On Thu, 2013-09-05 at 13:34 -0500, Kumar Gala wrote: On Apr 2, 2013, at 9:03 PM, Jia Hongtao wrote: + msi-feature |= MSI_HW_ERRATA_ENDIAN; + } + /* * Remember the phandle, so that we can match with any PCI nodes * that have an fsl,msi property. diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h index 8225f86..7389e8e 100644 --- a/arch/powerpc/sysdev/fsl_msi.h +++ b/arch/powerpc/sysdev/fsl_msi.h @@ -25,6 +25,8 @@ #define FSL_PIC_IP_IPIC 0x0002 #define FSL_PIC_IP_VMPIC 0x0003 +#define MSI_HW_ERRATA_ENDIAN 0x0010 + Why does this need to be in the header, why not just have it in the .c only Didn't you ask this last time around? :-) This flag is part of the same numberspace as FSL_PIC_IP_xxx and thus should be defined in the same place. I probably did, if its part of the FSL_PIC_IP_xxx namespace, than lets remove blank line between things to make that a bit more clear - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/7] powerpc/mpc8xxx: Change EDAC for FSL SoC
Remove mpc83xx and mpc85xx as dependency. Signed-off-by: York Sun york...@freescale.com Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com --- drivers/edac/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig index 878f090..53bf163 100644 --- a/drivers/edac/Kconfig +++ b/drivers/edac/Kconfig @@ -254,10 +254,10 @@ config EDAC_SBRIDGE config EDAC_MPC85XX tristate Freescale MPC83xx / MPC85xx - depends on EDAC_MM_EDAC FSL_SOC (PPC_83xx || PPC_85xx) + depends on EDAC_MM_EDAC FSL_SOC help Support for error detection and correction on the Freescale - MPC8349, MPC8560, MPC8540, MPC8548 + MPC8349, MPC8560, MPC8540, MPC8548, T4240 config EDAC_MV64X60 tristate Marvell MV64x60 -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/7] i2c/rtc-ds3232: Fix irq for probing
Driver shouldn't request irq when irq = 0. It is returned from parsing
device tree. 0 means no interrupt.
Signed-off-by: York Sun york...@freescale.com
Reviewed-by: Zang Tiefei-R61911 tie-fei.z...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
---
drivers/rtc/rtc-ds3232.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-ds3232.c b/drivers/rtc/rtc-ds3232.c
index b83bb5a5..ae8a28e 100644
--- a/drivers/rtc/rtc-ds3232.c
+++ b/drivers/rtc/rtc-ds3232.c
@@ -418,7 +418,7 @@ static int ds3232_probe(struct i2c_client *client,
return PTR_ERR(ds3232-rtc);
}
- if (client-irq = 0) {
+ if (client-irq 0) {
ret = devm_request_irq(client-dev, client-irq, ds3232_irq, 0,
ds3232, client);
if (ret) {
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
On Fri, 2013-09-06 at 10:01 -0500, Kumar Gala wrote: On Sep 5, 2013, at 1:37 PM, Scott Wood wrote: On Thu, 2013-09-05 at 13:34 -0500, Kumar Gala wrote: On Apr 2, 2013, at 9:03 PM, Jia Hongtao wrote: + msi-feature |= MSI_HW_ERRATA_ENDIAN; + } + /* * Remember the phandle, so that we can match with any PCI nodes * that have an fsl,msi property. diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h index 8225f86..7389e8e 100644 --- a/arch/powerpc/sysdev/fsl_msi.h +++ b/arch/powerpc/sysdev/fsl_msi.h @@ -25,6 +25,8 @@ #define FSL_PIC_IP_IPIC 0x0002 #define FSL_PIC_IP_VMPIC 0x0003 +#define MSI_HW_ERRATA_ENDIAN 0x0010 + Why does this need to be in the header, why not just have it in the .c only Didn't you ask this last time around? :-) This flag is part of the same numberspace as FSL_PIC_IP_xxx and thus should be defined in the same place. I probably did, if its part of the FSL_PIC_IP_xxx namespace, than lets remove blank line between things to make that a bit more clear It's not part of the FSL_PIC_IP_MASK subnumberspace though, just the overall msi-features numberspace. It would be nice if these symbols could have some sort of prefix in common, though. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 6/7] powerpc/t4240emu: Add device tree file for t4240emu
T4240EMU is an emulator target with minimum peripherals. It is based on
T4240QDS and trimmed down most peripherals due to either not modeled or
lack of board level connections. The main purpose of this minimum dts is
to speed up booting on emulator.
Signed-off-by: York Sun york...@freescale.com
Reviewed-by: Wood Scott-B07421 scottw...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
---
arch/powerpc/boot/dts/t4240emu.dts | 278
1 file changed, 278 insertions(+)
create mode 100644 arch/powerpc/boot/dts/t4240emu.dts
diff --git a/arch/powerpc/boot/dts/t4240emu.dts
b/arch/powerpc/boot/dts/t4240emu.dts
new file mode 100644
index 000..35a9c91
--- /dev/null
+++ b/arch/powerpc/boot/dts/t4240emu.dts
@@ -0,0 +1,278 @@
+/*
+ * T4240 emulator Device Tree Source
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor AS IS AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+/include/ fsl/e6500_power_isa.dtsi
+/ {
+ #address-cells = 2;
+ #size-cells = 2;
+ interrupt-parent = mpic;
+
+ aliases {
+ ccsr = soc;
+
+ serial0 = serial0;
+ serial1 = serial1;
+ serial2 = serial2;
+ serial3 = serial3;
+ dma0 = dma0;
+ dma1 = dma1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ /*
+* Temporarily add next-level-cache info in each cpu node so
+* that uboot can do L2 cache fixup. This can be removed once
+* u-boot can create cpu node with cache info.
+*/
+ cpu0: PowerPC,e6500@0 {
+ device_type = cpu;
+ reg = 0 1;
+ next-level-cache = L2_1;
+ };
+ cpu1: PowerPC,e6500@2 {
+ device_type = cpu;
+ reg = 2 3;
+ next-level-cache = L2_1;
+ };
+ cpu2: PowerPC,e6500@4 {
+ device_type = cpu;
+ reg = 4 5;
+ next-level-cache = L2_1;
+ };
+ cpu3: PowerPC,e6500@6 {
+ device_type = cpu;
+ reg = 6 7;
+ next-level-cache = L2_1;
+ };
+
+ cpu4: PowerPC,e6500@8 {
+ device_type = cpu;
+ reg = 8 9;
+ next-level-cache = L2_2;
+ };
+ cpu5: PowerPC,e6500@10 {
+ device_type = cpu;
+ reg = 10 11;
+ next-level-cache = L2_2;
+ };
+ cpu6: PowerPC,e6500@12 {
+ device_type = cpu;
+ reg = 12 13;
+ next-level-cache = L2_2;
+ };
+ cpu7: PowerPC,e6500@14 {
+ device_type = cpu;
+ reg = 14 15;
+ next-level-cache = L2_2;
+ };
+
+ cpu8:
[PATCH 5/7] powerpc/corenet64_smp_defconfig: Enable most SPI splash
Enable CONFIG_MTD_M25P80 for corenet64_smp_defconfig. Verified on P5040DS. Signed-off-by: York Sun york...@freescale.com Reviewed-by: Wood Scott-B07421 scottw...@freescale.com Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com --- arch/powerpc/configs/corenet64_smp_defconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig index 6c8b020..1ec6f0c 100644 --- a/arch/powerpc/configs/corenet64_smp_defconfig +++ b/arch/powerpc/configs/corenet64_smp_defconfig @@ -66,6 +66,7 @@ CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_CHAR=y CONFIG_MTD_BLKDEVS=y CONFIG_MTD_BLOCK=y +CONFIG_MTD_M25P80=y CONFIG_FTL=y CONFIG_MTD_CFI=y CONFIG_MTD_GEN_PROBE=y -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/7] powerpc/b4860emu: Add device tree file for b4860emu
B4860EMU is a emualtor target with minimum peripherals. It is based on
B4860QDS and trimmed down most peripherals due to either not modeled or
lack of board level connections. The main purpose of this minimum dts is
to speed up booting on emulator.
Signed-off-by: York Sun york...@freescale.com
Reviewed-by: Wood Scott-B07421 scottw...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
---
arch/powerpc/boot/dts/b4860emu.dts | 201
1 file changed, 201 insertions(+)
create mode 100644 arch/powerpc/boot/dts/b4860emu.dts
diff --git a/arch/powerpc/boot/dts/b4860emu.dts
b/arch/powerpc/boot/dts/b4860emu.dts
new file mode 100644
index 000..cb927ba
--- /dev/null
+++ b/arch/powerpc/boot/dts/b4860emu.dts
@@ -0,0 +1,201 @@
+/*
+ * B4860 emulator Device Tree Source
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+/include/ fsl/e6500_power_isa.dtsi
+
+/ {
+ #address-cells = 2;
+ #size-cells = 2;
+ interrupt-parent = mpic;
+
+ aliases {
+ ccsr = soc;
+
+ serial0 = serial0;
+ serial1 = serial1;
+ serial2 = serial2;
+ serial3 = serial3;
+ dma0 = dma0;
+ dma1 = dma1;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu0: PowerPC,e6500@0 {
+ device_type = cpu;
+ reg = 0 1;
+ next-level-cache = L2;
+ };
+ cpu1: PowerPC,e6500@2 {
+ device_type = cpu;
+ reg = 2 3;
+ next-level-cache = L2;
+ };
+ cpu2: PowerPC,e6500@4 {
+ device_type = cpu;
+ reg = 4 5;
+ next-level-cache = L2;
+ };
+ cpu3: PowerPC,e6500@6 {
+ device_type = cpu;
+ reg = 6 7;
+ next-level-cache = L2;
+ };
+ };
+};
+
+/ {
+ model = fsl,B4860QDS;
+ compatible = fsl,b4860emu, fsl,B4860QDS;
+ #address-cells = 2;
+ #size-cells = 2;
+ interrupt-parent = mpic;
+
+ ifc: localbus@ffe124000 {
+ reg = 0xf 0xfe124000 0 0x2000;
+ ranges = 0 0 0xf 0xe800 0x0800
+ 2 0 0xf 0xff80 0x0001
+ 3 0 0xf 0xffdf 0x8000;
+
+ nor@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x800;
+ bank-width = 2;
+ device-width = 1;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ soc: soc@ffe00 {
+ ranges = 0x 0xf 0xfe00 0x100;
+ reg = 0xf 0xfe00 0 0x1000;
+
+ };
+};
+
+ifc {
+ #address-cells = 2;
+ #size-cells = 1;
[PATCH 4/7] power/mpc85xx: Add delay after enabling I2C master
Erratum A-006037 indicates I2C controller executes the write to I2CCR only
after it sees SCL idle for 64K cycle of internal I2C controller clocks. If
during this waiting period, I2C controller is disabled (I2CCR[MEN] set to
0), then the controller could end in bad state, and hang the future access
to I2C register.
The mpc_i2c_fixup() function tries to recover the bus from a stalled state
where the 9th clock pulse wasn't generated. However, this workaround
disables and enables I2C controller without meeting waiting requirement of
this erratum.
This erratum applies to some 85xx SoCs. It is safe to apply to all of them
for mpc_i2c_fixup().
Signed-off-by: York Sun york...@freescale.com
Reviewed-by: Wood Scott-B07421 scottw...@freescale.com
Reviewed-by: Fleming Andrew-AFLEMING aflem...@freescale.com
Tested-by: Fleming Andrew-AFLEMING aflem...@freescale.com
CC: linux-...@vger.kernel.org
---
drivers/i2c/busses/i2c-mpc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index b80c768..55dce43 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -106,7 +106,12 @@ static irqreturn_t mpc_i2c_isr(int irq, void *dev_id)
static void mpc_i2c_fixup(struct mpc_i2c *i2c)
{
int k;
- u32 delay_val = 100 / i2c-real_clk + 1;
+ u32 delay_val;
+#ifdef CONFIG_PPC_85xx
+ delay_val = 65536 / (fsl_get_sys_freq() / 200); /* 64K cycle */
+#else
+ delay_val = 100 / i2c-real_clk + 1;
+#endif
if (delay_val 2)
delay_val = 2;
@@ -116,7 +121,11 @@ static void mpc_i2c_fixup(struct mpc_i2c *i2c)
writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
udelay(delay_val);
writeccr(i2c, CCR_MEN);
+#ifdef CONFIG_PPC_85xx
+ udelay(delay_val);
+#else
udelay(delay_val 1);
+#endif
}
}
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] powerpc: Add I2C bus multiplexer node for B4 and T4240QDS
On Sep 5, 2013, at 10:33 PM, Jia Hongtao-B38951 wrote:
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Friday, September 06, 2013 2:41 AM
To: Jia Hongtao-B38951
Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
wei.y...@windriver.com
Subject: Re: [PATCH V2] powerpc: Add I2C bus multiplexer node for B4 and
T4240QDS
On Sep 4, 2013, at 9:41 PM, Jia Hongtao wrote:
In both B4 and T4240QDS platform PCA9547 I2C bus multiplexer is used.
The sub-nodes are also reorganized according to right I2C topology.
Signed-off-by: Jia Hongtao hongtao@freescale.com
---
V2 change log:
Reorganized the sub-nodes under I2C multiplexer to represent right
topology.
arch/powerpc/boot/dts/b4qds.dtsi | 49 +---
arch/powerpc/boot/dts/t4240qds.dts | 67 ++-
---
2 files changed, 69 insertions(+), 47 deletions(-)
diff --git a/arch/powerpc/boot/dts/b4qds.dtsi
b/arch/powerpc/boot/dts/b4qds.dtsi
index e6d2f8f..de8cb38 100644
--- a/arch/powerpc/boot/dts/b4qds.dtsi
+++ b/arch/powerpc/boot/dts/b4qds.dtsi
@@ -120,25 +120,36 @@
};
i2c@118000 {
- eeprom@50 {
- compatible = at24,24c64;
- reg = 0x50;
- };
- eeprom@51 {
- compatible = at24,24c256;
- reg = 0x51;
- };
- eeprom@53 {
- compatible = at24,24c256;
- reg = 0x53;
- };
- eeprom@57 {
- compatible = at24,24c256;
- reg = 0x57;
- };
- rtc@68 {
- compatible = dallas,ds3232;
- reg = 0x68;
+ pca9547@77 {
+ compatible = philips,pca9547;
We seem to be using nxp instead of philips now.
This is based on Documentation/devicetree/bindings/vendor-prefixes.txt
+ reg = 0x77;
+ #address-cells = 1;
+ #size-cells = 0;
+ channel@0 {
channel should probably be i2c
Is there any standard for the name?
i2c is ok but I think channel is more intuitional.
Hi Scott,
What do you think of it.
Basing my comments on Documentation/devicetree/bindings/i2c/i2c-mux.txt
Thanks.
-Hongtao
[same comments below]
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0;
+ eeprom@50 {
+ compatible = at24,24c64;
+ reg = 0x50;
+ };
+ eeprom@51 {
+ compatible = at24,24c256;
+ reg = 0x51;
+ };
+ eeprom@53 {
+ compatible = at24,24c256;
+ reg = 0x53;
+ };
+ eeprom@57 {
+ compatible = at24,24c256;
+ reg = 0x57;
+ };
+ rtc@68 {
+ compatible = dallas,ds3232;
+ reg = 0x68;
+ };
+ };
};
};
diff --git a/arch/powerpc/boot/dts/t4240qds.dts
b/arch/powerpc/boot/dts/t4240qds.dts
index 0555976..ae68595 100644
--- a/arch/powerpc/boot/dts/t4240qds.dts
+++ b/arch/powerpc/boot/dts/t4240qds.dts
@@ -118,34 +118,45 @@
};
i2c@118000 {
- eeprom@51 {
- compatible = at24,24c256;
- reg = 0x51;
- };
- eeprom@52 {
- compatible = at24,24c256;
- reg = 0x52;
- };
- eeprom@53 {
- compatible = at24,24c256;
- reg = 0x53;
- };
- eeprom@54 {
- compatible = at24,24c256;
- reg = 0x54;
- };
- eeprom@55 {
- compatible = at24,24c256;
- reg = 0x55;
- };
- eeprom@56 {
-
Re: [PATCH V2 2/2] powerpc/85xx: workaround for chips with MSI hardware errata
On Sep 6, 2013, at 10:36 AM, Scott Wood wrote: On Fri, 2013-09-06 at 10:01 -0500, Kumar Gala wrote: On Sep 5, 2013, at 1:37 PM, Scott Wood wrote: On Thu, 2013-09-05 at 13:34 -0500, Kumar Gala wrote: On Apr 2, 2013, at 9:03 PM, Jia Hongtao wrote: + msi-feature |= MSI_HW_ERRATA_ENDIAN; + } + /* * Remember the phandle, so that we can match with any PCI nodes * that have an fsl,msi property. diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h index 8225f86..7389e8e 100644 --- a/arch/powerpc/sysdev/fsl_msi.h +++ b/arch/powerpc/sysdev/fsl_msi.h @@ -25,6 +25,8 @@ #define FSL_PIC_IP_IPIC 0x0002 #define FSL_PIC_IP_VMPIC 0x0003 +#define MSI_HW_ERRATA_ENDIAN 0x0010 + Why does this need to be in the header, why not just have it in the .c only Didn't you ask this last time around? :-) This flag is part of the same numberspace as FSL_PIC_IP_xxx and thus should be defined in the same place. I probably did, if its part of the FSL_PIC_IP_xxx namespace, than lets remove blank line between things to make that a bit more clear It's not part of the FSL_PIC_IP_MASK subnumberspace though, just the overall msi-features numberspace. It would be nice if these symbols could have some sort of prefix in common, though. -Scott Maybe we should do something like MSI_FTR_ as a prefix - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git next branch
On Thu, Sep 5, 2013 at 7:24 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: * A bunch of endian fixes ! We don't have full LE support yet in that release but this contains a lot of fixes all over arch/powerpc to use the proper accessors, call the firmware with the right endian mode, etc... Ok, this caused a conflict in arch/powerpc/kernel/prom.c, where some of the OF CPU number accessors had been moved to generic OF code instead. It *looks* to me like those accessors had already been made endian-clean as part of the move to generic code, and so my conflict resolution was to just ignore the parts of the changes the code that no longer exists in prom.c, but you really should double-check my resolution. Maybe I screwed it up. But apparent'y the LE mode isn't finished, so hopefully even if I read those changes wrong it won't affect you guys too badly. I didn't test-compile any of it, yadda yadda.. Linus ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/6] powerpc/pci: use pci_is_pcie() to simplify code
On Thu, Sep 05, 2013 at 03:55:27PM +0800, Yijing Wang wrote:
Use pci_is_pcie() to simplify code.
Acked-by: Kumar Gala ga...@kernel.crashing.org
Reviewed-by: Gavin Shan sha...@linux.vnet.ibm.com
Signed-off-by: Yijing Wang wangyij...@huawei.com
Cc: Gavin Shan sha...@linux.vnet.ibm.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/powerpc/kernel/eeh.c |3 +--
arch/powerpc/sysdev/fsl_pci.c |2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
Ben, Paul, this has no dependencies on anything new to PCI or any
other patches in this series, so you can take it through the POWERPC
tree. If you don't want to do that, let me know and I can take it.
If you want it:
Acked-by: Bjorn Helgaas bhelg...@google.com
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 55593ee..6ebbe54 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -189,8 +189,7 @@ static size_t eeh_gather_pci_data(struct eeh_dev *edev,
char * buf, size_t len)
}
/* If PCI-E capable, dump PCI-E cap 10, and the AER */
- cap = pci_find_capability(dev, PCI_CAP_ID_EXP);
- if (cap) {
+ if (pci_is_pcie(dev)) {
n += scnprintf(buf+n, len-n, pci-e cap10:\n);
printk(KERN_WARNING
EEH: PCI-E capabilities and status follow:\n);
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 46ac1dd..5402a1d 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -41,7 +41,7 @@ static void quirk_fsl_pcie_header(struct pci_dev *dev)
u8 hdr_type;
/* if we aren't a PCIe don't bother */
- if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
+ if (!pci_is_pcie(dev))
return;
/* if we aren't in host mode don't bother */
--
1.7.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
