2020-09-10 05:42:20

by Christoph Hellwig

[permalink] [raw]
Subject: [PATCH 2/3] ARM/keystone: move the DMA offset handling under ifdef CONFIG_ARM_LPAE

The DMA offset notifier can only be used if PHYS_OFFSET is at least
KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit
phys_addr_t. Currently the code compiles fine despite that, a pending
change to the DMA offset handling would create a compiler warning for
this case. Add an ifdef to not compile the code except for LPAE
configs.

Signed-off-by: Christoph Hellwig <[email protected]>
---
arch/arm/mach-keystone/keystone.c | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
index 638808c4e12247..dcd031ba84c2e0 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -24,6 +24,7 @@

#include "keystone.h"

+#ifdef CONFIG_ARM_LPAE
static unsigned long keystone_dma_pfn_offset __read_mostly;

static int keystone_platform_notifier(struct notifier_block *nb,
@@ -48,14 +49,17 @@ static int keystone_platform_notifier(struct notifier_block *nb,
static struct notifier_block platform_nb = {
.notifier_call = keystone_platform_notifier,
};
+#endif /* CONFIG_ARM_LPAE */

static void __init keystone_init(void)
{
+#ifdef CONFIG_ARM_LPAE
if (PHYS_OFFSET >= KEYSTONE_HIGH_PHYS_START) {
keystone_dma_pfn_offset = PFN_DOWN(KEYSTONE_HIGH_PHYS_START -
KEYSTONE_LOW_PHYS_START);
bus_register_notifier(&platform_bus_type, &platform_nb);
}
+#endif
keystone_pm_runtime_init();
}

--
2.28.0


2020-09-11 11:14:34

by Robin Murphy

[permalink] [raw]
Subject: Re: [PATCH 2/3] ARM/keystone: move the DMA offset handling under ifdef CONFIG_ARM_LPAE

On 2020-09-10 06:40, Christoph Hellwig wrote:
> The DMA offset notifier can only be used if PHYS_OFFSET is at least
> KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit
> phys_addr_t. Currently the code compiles fine despite that, a pending
> change to the DMA offset handling would create a compiler warning for
> this case. Add an ifdef to not compile the code except for LPAE
> configs.

Seems reasonable - once again I wonder whether this notifier is really
needed any more since "dma-ranges" should now be handled properly for
PCI devices as well, but that's not something to worry about in this series.

Reviewed-by: Robin Murphy <[email protected]>

> Signed-off-by: Christoph Hellwig <[email protected]>
> ---
> arch/arm/mach-keystone/keystone.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/mach-keystone/keystone.c b/arch/arm/mach-keystone/keystone.c
> index 638808c4e12247..dcd031ba84c2e0 100644
> --- a/arch/arm/mach-keystone/keystone.c
> +++ b/arch/arm/mach-keystone/keystone.c
> @@ -24,6 +24,7 @@
>
> #include "keystone.h"
>
> +#ifdef CONFIG_ARM_LPAE
> static unsigned long keystone_dma_pfn_offset __read_mostly;
>
> static int keystone_platform_notifier(struct notifier_block *nb,
> @@ -48,14 +49,17 @@ static int keystone_platform_notifier(struct notifier_block *nb,
> static struct notifier_block platform_nb = {
> .notifier_call = keystone_platform_notifier,
> };
> +#endif /* CONFIG_ARM_LPAE */
>
> static void __init keystone_init(void)
> {
> +#ifdef CONFIG_ARM_LPAE
> if (PHYS_OFFSET >= KEYSTONE_HIGH_PHYS_START) {
> keystone_dma_pfn_offset = PFN_DOWN(KEYSTONE_HIGH_PHYS_START -
> KEYSTONE_LOW_PHYS_START);
> bus_register_notifier(&platform_bus_type, &platform_nb);
> }
> +#endif
> keystone_pm_runtime_init();
> }
>
>

2020-09-11 11:17:18

by Russell King (Oracle)

[permalink] [raw]
Subject: Re: [PATCH 2/3] ARM/keystone: move the DMA offset handling under ifdef CONFIG_ARM_LPAE

On Thu, Sep 10, 2020 at 07:40:37AM +0200, Christoph Hellwig wrote:
> The DMA offset notifier can only be used if PHYS_OFFSET is at least
> KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit
> phys_addr_t. Currently the code compiles fine despite that, a pending
> change to the DMA offset handling would create a compiler warning for
> this case. Add an ifdef to not compile the code except for LPAE
> configs.

However, to have use of the high physical offset, LPAE needs to be
enabled, which ensures that phys_addr_t is 64-bit.

I believe that DMA is non-coherent on this platform unless the high
physical address is used. Or something like that.

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

2020-09-11 11:34:02

by Robin Murphy

[permalink] [raw]
Subject: Re: [PATCH 2/3] ARM/keystone: move the DMA offset handling under ifdef CONFIG_ARM_LPAE

On 2020-09-11 12:15, Russell King - ARM Linux admin wrote:
> On Thu, Sep 10, 2020 at 07:40:37AM +0200, Christoph Hellwig wrote:
>> The DMA offset notifier can only be used if PHYS_OFFSET is at least
>> KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit
>> phys_addr_t. Currently the code compiles fine despite that, a pending
>> change to the DMA offset handling would create a compiler warning for
>> this case. Add an ifdef to not compile the code except for LPAE
>> configs.
>
> However, to have use of the high physical offset, LPAE needs to be
> enabled, which ensures that phys_addr_t is 64-bit.
>
> I believe that DMA is non-coherent on this platform unless the high
> physical address is used. Or something like that.

Yeah, it's probably not a configuration that anyone would actually want
to use in anger on Keystone itself, but as long as folks might have
ARCH_KEYSTONE selected in their non-LPAE multiplatform config we should
avoid build regressions. I did wonder if Keystone should simply have a
hard dependency on LPAE, but there does appear to be some explicit
support for running directly from the non-coherent low 2G alias :/

Robin.

2020-09-11 18:03:05

by Santosh Shilimkar

[permalink] [raw]
Subject: Re: [PATCH 2/3] ARM/keystone: move the DMA offset handling under ifdef CONFIG_ARM_LPAE

On 9/11/20 4:15 AM, Russell King - ARM Linux admin wrote:
> On Thu, Sep 10, 2020 at 07:40:37AM +0200, Christoph Hellwig wrote:
>> The DMA offset notifier can only be used if PHYS_OFFSET is at least
>> KEYSTONE_HIGH_PHYS_START, which can't be represented by a 32-bit
>> phys_addr_t. Currently the code compiles fine despite that, a pending
>> change to the DMA offset handling would create a compiler warning for
>> this case. Add an ifdef to not compile the code except for LPAE
>> configs.
>
> However, to have use of the high physical offset, LPAE needs to be
> enabled, which ensures that phys_addr_t is 64-bit.
>
> I believe that DMA is non-coherent on this platform unless the high
> physical address is used. Or something like that.
>
Exactly. Higher address ranges needs to be used for DMA coherency.

Regards,
Santosh