diff mbox

[03/15] SPEAr13xx: Add mach/io.h

Message ID cce9cba6020c30f0edb15e43fa51208524b59322.1351492562.git.pratyush.anand@st.com (mailing list archive)
State New, archived
Delegated to: Bjorn Helgaas
Headers show

Commit Message

Pratyush ANAND Oct. 29, 2012, 7:01 a.m. UTC 
In case of PCIe we need to have a different __io macro, which can write
into PCIe address space.

Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
---
 arch/arm/mach-spear13xx/include/mach/io.h |   35 +++++++++++++++++++++++++++++
 1 files changed, 35 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-spear13xx/include/mach/io.h

Comments

Viresh Kumar Oct. 29, 2012, 7:29 a.m. UTC | #1 
On Mon, Oct 29, 2012 at 12:31 PM, Pratyush Anand <pratyush.anand@st.com> wrote:
> In case of PCIe we need to have a different __io macro, which can write
> into PCIe address space.

You may find this interesting:

Do, git log --stat -p dd9bf78040fa0da4cecc228e1682b9682b8cb180

There is a series of commits like:

commit dd9bf78040fa0da4cecc228e1682b9682b8cb180
Author: Rob Herring <rob.herring@calxeda.com>
Date:   Wed Jul 4 11:18:40 2012 -0500

    ARM: iop3xx: use fixed PCI i/o mapping

    Move iop33x and iop32x PCI to fixed i/o mapping and remove io.h. This
    changes the PCI bus addresses from the cpu address to 0 based. It appears
    that there is translation h/w for this, but its untested.

    Not sure what to do with io_offset. I think it should always be 0.
    AFAICT, PCI setup is skipped if the ATU is already setup.

    Signed-off-by: Rob Herring <rob.herring@calxeda.com>
    Reviewed-by: Arnd Bergmann <arnd@arndb.de>

All mach/io.h are removed and you are adding one of those. :)

>
> Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
> ---
>  arch/arm/mach-spear13xx/include/mach/io.h |   35 +++++++++++++++++++++++++++++
>  1 files changed, 35 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/mach-spear13xx/include/mach/io.h
>
> diff --git a/arch/arm/mach-spear13xx/include/mach/io.h b/arch/arm/mach-spear13xx/include/mach/io.h
> new file mode 100644
> index 0000000..a0d93ca
> --- /dev/null
> +++ b/arch/arm/mach-spear13xx/include/mach/io.h
> @@ -0,0 +1,35 @@
> +/*
> + * arch/arm/mach-spear13xx/include/mach/io.h
> + *
> + * spear13xx machine family generic header file

SPEAr

> + *
> + * Copyright (C) 2012 ST Microelectronics
> + * Pratyush Anand <pratyush.anand@st.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#ifndef __MACH_IO_H
> +#define __MACH_IO_H
> +
> +#define IO_SPACE_LIMIT 0xFFFF
> +
> +#ifdef CONFIG_SPEAR13XX_PCI
> +extern void __iomem *spear13xx_pcie_io_base(unsigned long addr);
> +
> +static inline void __iomem *__io(unsigned long addr)
> +{
> +       return spear13xx_pcie_io_base(addr) + (addr & IO_SPACE_LIMIT);
> +}
> +#else
> +static inline void __iomem *__io(unsigned long addr)
> +{
> +       return (void __iomem *)addr;
> +}
> +#endif
> +
> +#define __io(a)                __io(a)
> +
> +#endif /* __MACH_IO_H */
> --
> 1.7.5.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pratyush ANAND Oct. 29, 2012, 8:11 a.m. UTC | #2 
On 10/29/2012 12:59 PM, viresh kumar wrote:
> On Mon, Oct 29, 2012 at 12:31 PM, Pratyush Anand <pratyush.anand@st.com> wrote:
>> In case of PCIe we need to have a different __io macro, which can write
>> into PCIe address space.
>
> You may find this interesting:
>
> Do, git log --stat -p dd9bf78040fa0da4cecc228e1682b9682b8cb180
>
> There is a series of commits like:
>
> commit dd9bf78040fa0da4cecc228e1682b9682b8cb180
> Author: Rob Herring <rob.herring@calxeda.com>
> Date:   Wed Jul 4 11:18:40 2012 -0500
>
>      ARM: iop3xx: use fixed PCI i/o mapping
>
>      Move iop33x and iop32x PCI to fixed i/o mapping and remove io.h. This
>      changes the PCI bus addresses from the cpu address to 0 based. It appears
>      that there is translation h/w for this, but its untested.

In case of SPEAr we can not translate a CPU address 0 to PCIe space. To 
explain it better, lets say we allocate 0x0000 - 0xFFFF for PCIe IO 
transaction. Now if CPU writes on these addressed, there is no way we 
can route those transactions to PCIe bus.

Any transaction between 0x80000000 to 0x8FFFFFFF can only be used for 
any type(IO/MEM/CFG0/CFG1) of PCIe transaction. Therefore , we need to 
have this mapping in io.h.

Regards
Pratyush

>
>      Not sure what to do with io_offset. I think it should always be 0.
>      AFAICT, PCI setup is skipped if the ATU is already setup.
>
>      Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>      Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>
> All mach/io.h are removed and you are adding one of those. :)
>
>>
>> Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
>> ---
>>   arch/arm/mach-spear13xx/include/mach/io.h |   35 +++++++++++++++++++++++++++++
>>   1 files changed, 35 insertions(+), 0 deletions(-)
>>   create mode 100644 arch/arm/mach-spear13xx/include/mach/io.h
>>
>> diff --git a/arch/arm/mach-spear13xx/include/mach/io.h b/arch/arm/mach-spear13xx/include/mach/io.h
>> new file mode 100644
>> index 0000000..a0d93ca
>> --- /dev/null
>> +++ b/arch/arm/mach-spear13xx/include/mach/io.h
>> @@ -0,0 +1,35 @@
>> +/*
>> + * arch/arm/mach-spear13xx/include/mach/io.h
>> + *
>> + * spear13xx machine family generic header file
>
> SPEAr
>
>> + *
>> + * Copyright (C) 2012 ST Microelectronics
>> + * Pratyush Anand <pratyush.anand@st.com>
>> + *
>> + * This file is licensed under the terms of the GNU General Public
>> + * License version 2. This program is licensed "as is" without any
>> + * warranty of any kind, whether express or implied.
>> + */
>> +
>> +#ifndef __MACH_IO_H
>> +#define __MACH_IO_H
>> +
>> +#define IO_SPACE_LIMIT 0xFFFF
>> +
>> +#ifdef CONFIG_SPEAR13XX_PCI
>> +extern void __iomem *spear13xx_pcie_io_base(unsigned long addr);
>> +
>> +static inline void __iomem *__io(unsigned long addr)
>> +{
>> +       return spear13xx_pcie_io_base(addr) + (addr & IO_SPACE_LIMIT);
>> +}
>> +#else
>> +static inline void __iomem *__io(unsigned long addr)
>> +{
>> +       return (void __iomem *)addr;
>> +}
>> +#endif
>> +
>> +#define __io(a)                __io(a)
>> +
>> +#endif /* __MACH_IO_H */
>> --
>> 1.7.5.4
>>
> .
>


--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann Oct. 30, 2012, 9:45 p.m. UTC | #3 
On Monday 29 October 2012, Pratyush Anand wrote:
> Any transaction between 0x80000000 to 0x8FFFFFFF can only be used for 
> any type(IO/MEM/CFG0/CFG1) of PCIe transaction. Therefore , we need to 
> have this mapping in io.h.

No you don't.

The I/O space window will only be in one place on a given system, so you
should register that window using pci_ioremap_io() as all the other
modern platforms. There is no excuse for having a per-platform mach/io.h
any more and that would prevent you from enabling spear in a multiplatform
configuration.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pratyush ANAND Oct. 31, 2012, 11:24 a.m. UTC | #4 
On 10/31/2012 3:15 AM, Arnd Bergmann wrote:
> On Monday 29 October 2012, Pratyush Anand wrote:
>> Any transaction between 0x80000000 to 0x8FFFFFFF can only be used for
>> any type(IO/MEM/CFG0/CFG1) of PCIe transaction. Therefore , we need to
>> have this mapping in io.h.
>
> No you don't.
>
> The I/O space window will only be in one place on a given system, so you
> should register that window using pci_ioremap_io() as all the other

Sorry, I could not find pci_ioremap_io function. May be you wanted to 
refer something else.

In case of SPEAr too , we can reserve first 32Kb per controller as PCIe 
IO space. So, lets say I fixed address 0x80000000--0x80007FFF for IO 
transaction. I need to register address range of this window somehow.

But, issue which faced was that I was not able to successfully 
request_resource(&ioport_resource, &res]) with res.start = 0x80000000 
and res.end = 0x80007fff.

So, I though first to change IO_SPACE_LIMIT. But I found it not a 
correct way.

May be I am missing something and not able to get how can I use 
pci_ioremap_io or something else to register 0x80000000--0x80007FFF 
window. A reference will help.


Regards
Pratyush
> modern platforms. There is no excuse for having a per-platform mach/io.h
> any more and that would prevent you from enabling spear in a multiplatform
> configuration.
>
> 	Arnd
> .
>


--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Arnd Bergmann Oct. 31, 2012, 10:05 p.m. UTC | #5 
On Wednesday 31 October 2012, Pratyush Anand wrote:
> Sorry, I could not find pci_ioremap_io function. May be you wanted to 
> refer something else.

$ git grep pci_ioremap_io
arch/arm/include/asm/io.h:extern int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr);
arch/arm/mach-dove/pcie.c:              pci_ioremap_io(sys->busnr * SZ_64K, DOVE_PCIE0_IO_PHYS_BASE);
...
arch/arm/mach-versatile/pci.c:  ret = pci_ioremap_io(0, VERSATILE_PCI_MEM_BASE0);
arch/arm/mm/ioremap.c:int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr)
arch/arm/mm/ioremap.c:EXPORT_SYMBOL_GPL(pci_ioremap_io);


> In case of SPEAr too , we can reserve first 32Kb per controller as PCIe 
> IO space. So, lets say I fixed address 0x80000000--0x80007FFF for IO 
> transaction. I need to register address range of this window somehow.
> 
> But, issue which faced was that I was not able to successfully 
> request_resource(&ioport_resource, &res]) with res.start = 0x80000000 
> and res.end = 0x80007fff.

That cannot work properly, because the ioport_resource lists ports between
0 and 0x10000 normally, or possibly a little bit higher. You certainly
don't want to waste 2 GB of virtual address space for having a PCI I/O window
that you don't use.

> So, I though first to change IO_SPACE_LIMIT. But I found it not a 
> correct way.
> 
> May be I am missing something and not able to get how can I use 
> pci_ioremap_io or something else to register 0x80000000--0x80007FFF 
> window. A reference will help.

Calling pci_ioremap_io will do the right thing, you just have to decide
how you partition the I/O space between the root complexes you have.

	Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/arch/arm/mach-spear13xx/include/mach/io.h b/arch/arm/mach-spear13xx/include/mach/io.h
new file mode 100644
index 0000000..a0d93ca
--- /dev/null
+++ b/arch/arm/mach-spear13xx/include/mach/io.h
@@ -0,0 +1,35 @@ 
+/*
+ * arch/arm/mach-spear13xx/include/mach/io.h
+ *
+ * spear13xx machine family generic header file
+ *
+ * Copyright (C) 2012 ST Microelectronics
+ * Pratyush Anand <pratyush.anand@st.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __MACH_IO_H
+#define __MACH_IO_H
+
+#define IO_SPACE_LIMIT	0xFFFF
+
+#ifdef CONFIG_SPEAR13XX_PCI
+extern void __iomem *spear13xx_pcie_io_base(unsigned long addr);
+
+static inline void __iomem *__io(unsigned long addr)
+{
+	return spear13xx_pcie_io_base(addr) + (addr & IO_SPACE_LIMIT);
+}
+#else
+static inline void __iomem *__io(unsigned long addr)
+{
+	return (void __iomem *)addr;
+}
+#endif
+
+#define __io(a)		__io(a)
+
+#endif /* __MACH_IO_H */