[v3,4/7] of: configure the platform device dma parameters

Message ID CACRpkdZjEVYgq7tKEfmZC0Fu4n=JuUues=pAAtquLahkex=pkA@mail.gmail.com
State New
Headers show

Commit Message

Linus Walleij May 28, 2014, 8:23 a.m.
On Tue, May 27, 2014 at 3:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 27 May 2014 13:56:55 Grant Likely wrote:

>> Come to think of it, doesn't PCI DMA have to deal with that situation if
>> the PCI window is not 1:1 mapped into the CPU address space?
>
> I think all PCI buses we support so far only need a single entry in the
> dma-ranges property.

Here is the patch I've cooked for the Integrator (PCIv3), identical
to the keystone:

commit b326b94a58ff476fca2b57cf7912b00bec1363c0
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Fri Feb 14 10:26:15 2014 +0100

    ARM: integrator: get rid of <mach/memory.h>

    The Integrator has a custom <mach/memory.h> header defining the
    BUS_OFFSET for *_to_bus and bus_to_* operations as offset from
    0x80000000.

    This switches the Integrator over to using the mechanism
    introduced for the Keystone to provide the same offset using
    the device tree, deletes <mach/memory.h> and augments the
    Integrator device tree to provide the bus offset.

    Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
    Cc: Grygorii Strashko <grygorii.strashko@ti.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Jonathan Austin <jonathan.austin@arm.com>
    Cc: Russell King <linux@arm.linux.org.uk>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

diff --git a/arch/arm/mach-integrator/include/mach/memory.h
b/arch/arm/mach-integrator/include/mach/memory.h
deleted file mode 100644
index 334d5e271889..000000000000
--- a/arch/arm/mach-integrator/include/mach/memory.h
+++ /dev/null
(...)

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Comments

Arnd Bergmann May 28, 2014, 1:29 p.m. | #1
On Wednesday 28 May 2014 10:23:09 Linus Walleij wrote:
> diff --git a/arch/arm/boot/dts/integratorap.dts
> b/arch/arm/boot/dts/integratorap.dts
> index b10e6351da53..f0c397fd45c5 100644
> --- a/arch/arm/boot/dts/integratorap.dts
> +++ b/arch/arm/boot/dts/integratorap.dts
> @@ -8,6 +8,7 @@
>  / {
>         model = "ARM Integrator/AP";
>         compatible = "arm,integrator-ap";
> +       dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>;
> 
>         aliases {
>                 arm,timer-primary = &timer2;
> 

It looks like you accidentally copied the ranges from keystone, even
though that has a 64-bit root bus and you only have 32-bit.

I suspect what you want is

	dma-ranges = <0x80000000 0 0x80000000>;

to translate dma_addr_t 0x80000000-0xffffffff to phys_addr_t 0x0-0x7fffffff
rather than phys_addr_t 0x800000000-0x87fffffff.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij May 28, 2014, 1:32 p.m. | #2
On Wed, May 28, 2014 at 3:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 28 May 2014 10:23:09 Linus Walleij wrote:

>>         model = "ARM Integrator/AP";
>>         compatible = "arm,integrator-ap";
>> +       dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>;
>>
>>         aliases {
>>                 arm,timer-primary = &timer2;
>>
>
> It looks like you accidentally copied the ranges from keystone, even
> though that has a 64-bit root bus and you only have 32-bit.

Nah it was no accident, just good old incompetence ;-)

> I suspect what you want is
>
>         dma-ranges = <0x80000000 0 0x80000000>;
>
> to translate dma_addr_t 0x80000000-0xffffffff to phys_addr_t 0x0-0x7fffffff
> rather than phys_addr_t 0x800000000-0x87fffffff.

Thanks, I'll fix up my patch.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Santosh Shilimkar May 28, 2014, 2:04 p.m. | #3
On Wednesday 28 May 2014 09:32 AM, Linus Walleij wrote:
> On Wed, May 28, 2014 at 3:29 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wednesday 28 May 2014 10:23:09 Linus Walleij wrote:
> 
>>>         model = "ARM Integrator/AP";
>>>         compatible = "arm,integrator-ap";
>>> +       dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>;
>>>
>>>         aliases {
>>>                 arm,timer-primary = &timer2;
>>>
>>
>> It looks like you accidentally copied the ranges from keystone, even
>> though that has a 64-bit root bus and you only have 32-bit.
> 
> Nah it was no accident, just good old incompetence ;-)
> 
>> I suspect what you want is
>>
>>         dma-ranges = <0x80000000 0 0x80000000>;
>>
>> to translate dma_addr_t 0x80000000-0xffffffff to phys_addr_t 0x0-0x7fffffff
>> rather than phys_addr_t 0x800000000-0x87fffffff.
>
Interesting. Where does the ROM address space resides on integrator then considering
address 0 is used for DMA.
 
> Thanks, I'll fix up my patch.
> 
Feel free to add my ack after the fixup if you need one.

regards,
Santosh

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij May 29, 2014, 2:01 p.m. | #4
On Wed, May 28, 2014 at 4:04 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> On Wednesday 28 May 2014 09:32 AM, Linus Walleij wrote:

>>> I suspect what you want is
>>>
>>>         dma-ranges = <0x80000000 0 0x80000000>;
>>>
>>> to translate dma_addr_t 0x80000000-0xffffffff to phys_addr_t 0x0-0x7fffffff
>>> rather than phys_addr_t 0x800000000-0x87fffffff.
>>
> Interesting. Where does the ROM address space resides on integrator then considering
> address 0 is used for DMA.

The ROM is at physical address 0x20000000, don't ask me
why :-)

The RAM is typically at 0x00000000-0x0fffffff, on up to four parallell
tiles, i.e. up to four completely independent CPUs are booted off the
same ROM and using a set of shared peripherals.

>> Thanks, I'll fix up my patch.
>>
> Feel free to add my ack after the fixup if you need one.

Thanks!

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Santosh Shilimkar May 29, 2014, 2:08 p.m. | #5
On Thursday 29 May 2014 10:01 AM, Linus Walleij wrote:
> On Wed, May 28, 2014 at 4:04 PM, Santosh Shilimkar
> <santosh.shilimkar@ti.com> wrote:
>> On Wednesday 28 May 2014 09:32 AM, Linus Walleij wrote:
> 
>>>> I suspect what you want is
>>>>
>>>>         dma-ranges = <0x80000000 0 0x80000000>;
>>>>
>>>> to translate dma_addr_t 0x80000000-0xffffffff to phys_addr_t 0x0-0x7fffffff
>>>> rather than phys_addr_t 0x800000000-0x87fffffff.
>>>
>> Interesting. Where does the ROM address space resides on integrator then considering
>> address 0 is used for DMA.
> 
> The ROM is at physical address 0x20000000, don't ask me
> why :-)
> 
> The RAM is typically at 0x00000000-0x0fffffff, on up to four parallell
> tiles, i.e. up to four completely independent CPUs are booted off the
> same ROM and using a set of shared peripherals.
> 
The reason I asked the question because most of the ARM SOC I came across
aren't using the RAM phys address 0 and thought was because of boot architecture
with ROM occupying that address with reset vector starting at address 0.

That was one of the main reason we had description on max_*pfn on ARM w.r.t
to other acrhes.

Will corner ARM guys to understand bit more about it in some conference ;-)

Thanks for clarification.

Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Arnd Bergmann May 29, 2014, 7:24 p.m. | #6
On Thursday 29 May 2014 10:08:10 Santosh Shilimkar wrote:
> On Thursday 29 May 2014 10:01 AM, Linus Walleij wrote:
> > On Wed, May 28, 2014 at 4:04 PM, Santosh Shilimkar
> > <santosh.shilimkar@ti.com> wrote:
> >> On Wednesday 28 May 2014 09:32 AM, Linus Walleij wrote:
> > 
> >>>> I suspect what you want is
> >>>>
> >>>>         dma-ranges = <0x80000000 0 0x80000000>;
> >>>>
> >>>> to translate dma_addr_t 0x80000000-0xffffffff to phys_addr_t 0x0-0x7fffffff
> >>>> rather than phys_addr_t 0x800000000-0x87fffffff.
> >>>
> >> Interesting. Where does the ROM address space resides on integrator then considering
> >> address 0 is used for DMA.
> > 
> > The ROM is at physical address 0x20000000, don't ask me
> > why 
> > 
> > The RAM is typically at 0x00000000-0x0fffffff, on up to four parallell
> > tiles, i.e. up to four completely independent CPUs are booted off the
> > same ROM and using a set of shared peripherals.
> > 
> The reason I asked the question because most of the ARM SOC I came across
> aren't using the RAM phys address 0 and thought was because of boot architecture
> with ROM occupying that address with reset vector starting at address 0.
> 
> That was one of the main reason we had description on max_*pfn on ARM w.r.t
> to other acrhes.
> 
> Will corner ARM guys to understand bit more about it in some conference 

If this is anything like the versatile express, the reason it works is probably
because there is another microcontroller in the system that does the bootstrap
and is able to load code into RAM before turning on the main CPU.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Santosh Shilimkar May 29, 2014, 8:04 p.m. | #7
On Thursday 29 May 2014 03:24 PM, Arnd Bergmann wrote:
> On Thursday 29 May 2014 10:08:10 Santosh Shilimkar wrote:
>> On Thursday 29 May 2014 10:01 AM, Linus Walleij wrote:
>>> On Wed, May 28, 2014 at 4:04 PM, Santosh Shilimkar
>>> <santosh.shilimkar@ti.com> wrote:
>>>> On Wednesday 28 May 2014 09:32 AM, Linus Walleij wrote:
>>>
>>>>>> I suspect what you want is
>>>>>>
>>>>>>         dma-ranges = <0x80000000 0 0x80000000>;
>>>>>>
>>>>>> to translate dma_addr_t 0x80000000-0xffffffff to phys_addr_t 0x0-0x7fffffff
>>>>>> rather than phys_addr_t 0x800000000-0x87fffffff.
>>>>>
>>>> Interesting. Where does the ROM address space resides on integrator then considering
>>>> address 0 is used for DMA.
>>>
>>> The ROM is at physical address 0x20000000, don't ask me
>>> why 
>>>
>>> The RAM is typically at 0x00000000-0x0fffffff, on up to four parallell
>>> tiles, i.e. up to four completely independent CPUs are booted off the
>>> same ROM and using a set of shared peripherals.
>>>
>> The reason I asked the question because most of the ARM SOC I came across
>> aren't using the RAM phys address 0 and thought was because of boot architecture
>> with ROM occupying that address with reset vector starting at address 0.
>>
>> That was one of the main reason we had description on max_*pfn on ARM w.r.t
>> to other acrhes.
>>
>> Will corner ARM guys to understand bit more about it in some conference 
> 
> If this is anything like the versatile express, the reason it works is probably
> because there is another microcontroller in the system that does the bootstrap
> and is able to load code into RAM before turning on the main CPU.
> 
That make sense now. Thanks for those extra bits.

Regards,
Santosh

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

Patch

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ab438cb5af55..2b29a1a7f26f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -329,7 +329,6 @@  config ARCH_INTEGRATOR
        select HAVE_TCM
        select ICST
        select MULTI_IRQ_HANDLER
-       select NEED_MACH_MEMORY_H
        select PLAT_VERSATILE
        select SPARSE_IRQ
        select USE_OF
diff --git a/arch/arm/boot/dts/integratorap.dts
b/arch/arm/boot/dts/integratorap.dts
index b10e6351da53..f0c397fd45c5 100644
--- a/arch/arm/boot/dts/integratorap.dts
+++ b/arch/arm/boot/dts/integratorap.dts
@@ -8,6 +8,7 @@ 
 / {
        model = "ARM Integrator/AP";
        compatible = "arm,integrator-ap";
+       dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>;

        aliases {
                arm,timer-primary = &timer2;