Message ID | 20200910054038.324517-3-hch@lst.de (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
Series | [1/3] ARM/dma-mapping: move various helpers from dma-mapping.h to dma-direct.h | expand |
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 <robin.murphy@arm.com> > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > 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(); > } > >
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.
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.
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
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(); }
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 <hch@lst.de> --- arch/arm/mach-keystone/keystone.c | 4 ++++ 1 file changed, 4 insertions(+)