| Message ID | 1410253952-15631-6-git-send-email-jingchang.lu@freescale.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tuesday 09 September 2014 17:12:31 Jingchang Lu wrote: > +#include "common.h" > + > +static void __init ls1021a_init_machine(void) > +{ > + mxc_arch_reset_init_dt(); > + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); > +} > + > +static const char *ls1021a_dt_compat[] __initdata = { > + "fsl,ls1021a", > + NULL, > +}; Please don't add any new users of mxc_arch_reset_init_dt(). We now have infrastructure to register a system-reset handler from the watchdog driver, so please do that instead, and clean up the existing users as well. > +DT_MACHINE_START(LS1021A, "Freescale LS1021A") > +#ifdef CONFIG_ZONE_DMA > + .dma_zone_size = SZ_128M, > +#endif > + .init_machine = ls1021a_init_machine, > + .dt_compat = ls1021a_dt_compat, > + .restart = mxc_restart, > +MACHINE_END I believe someone recently posted a patch to derive the dma_zone_size from device tree. Can yo try to find that and see if that will work for you? Can you explain what the reason is for needing a DMA zone? Arnd
>-----Original Message----- >From: Arnd Bergmann [mailto:arnd@arndb.de] >Sent: Tuesday, September 09, 2014 7:41 PM >To: linux-arm-kernel@lists.infradead.org >Cc: Lu Jingchang-B35083; Guo Shawn-R65073; Lu Jingchang-B35083; >devicetree@vger.kernel.org >Subject: Re: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale >LS1021A > >On Tuesday 09 September 2014 17:12:31 Jingchang Lu wrote: >> +#include "common.h" >> + >> +static void __init ls1021a_init_machine(void) { >> + mxc_arch_reset_init_dt(); >> + of_platform_populate(NULL, of_default_bus_match_table, NULL, >> +NULL); } >> + >> +static const char *ls1021a_dt_compat[] __initdata = { >> + "fsl,ls1021a", >> + NULL, >> +}; > >Please don't add any new users of mxc_arch_reset_init_dt(). We now have >infrastructure to register a system-reset handler from the watchdog driver, >so please do that instead, and clean up the existing users as well. I just notice the restart_handler support, I will use that instead, thanks. > >> +DT_MACHINE_START(LS1021A, "Freescale LS1021A") #ifdef CONFIG_ZONE_DMA >> + .dma_zone_size = SZ_128M, >> +#endif >> + .init_machine = ls1021a_init_machine, >> + .dt_compat = ls1021a_dt_compat, >> + .restart = mxc_restart, >> +MACHINE_END > >I believe someone recently posted a patch to derive the dma_zone_size from >device tree. Can yo try to find that and see if that will work for you? > >Can you explain what the reason is for needing a DMA zone? > > Arnd With LPAE enabled on our SoC, we meet the system complaint of "coherent DMA mask 0xffffffff is smaller than system GFP_DMA mask 0xffffffffffffffff", and I notice that CONFIG_ZONE_DMA and dma_zone_size is a common resolve for this. Thanks. Best Regards, Jingchang
On Wednesday 10 September 2014 03:31:19 Jingchang Lu wrote: > >> +DT_MACHINE_START(LS1021A, "Freescale LS1021A") > >> + #ifdef CONFIG_ZONE_DMA > >> + .dma_zone_size = SZ_128M, > >> +#endif > >> + .init_machine = ls1021a_init_machine, > >> + .dt_compat = ls1021a_dt_compat, > >> + .restart = mxc_restart, > >> +MACHINE_END > > > >I believe someone recently posted a patch to derive the dma_zone_size from > >device tree. Can yo try to find that and see if that will work for you? > > > >Can you explain what the reason is for needing a DMA zone? > > With LPAE enabled on our SoC, we meet the system complaint of > "coherent DMA mask 0xffffffff is smaller than system GFP_DMA mask 0xffffffffffffffff", > and I notice that CONFIG_ZONE_DMA and dma_zone_size is a common resolve for this. Ok, I see. The actual point of dma_zone_size however is slightly different, and I think you should not use it like this. We normally only use ZONE_DMA if there are devices that have a limitation smaller than 4GB, and that appear to be the case for your system. The message you quote is only present in arch/powerpc, so I'm not sure what symptoms you are actually seeing. Please try removing the dma_zone_size setting for your platform and report if it works or what the symptom is if it does not work with the latest kernel. We definitely need to get this to work out of the box without a dma_zone_size hack. Can you describe what the memory layout is of your platform? Can you have RAM installed above the 4GB physical address boundary? If you can, are there any devices that are unable to perform DMA into that memory without the use of an IOMMU? Arnd
>-----Original Message----- >From: Arnd Bergmann [mailto:arnd@arndb.de] >Sent: Wednesday, September 10, 2014 3:42 PM >To: Lu Jingchang-B35083 >Cc: linux-arm-kernel@lists.infradead.org; Guo Shawn-R65073; >devicetree@vger.kernel.org >Subject: Re: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale >LS1021A > >On Wednesday 10 September 2014 03:31:19 Jingchang Lu wrote: > >> >> +DT_MACHINE_START(LS1021A, "Freescale LS1021A") #ifdef >> >> +CONFIG_ZONE_DMA >> >> + .dma_zone_size = SZ_128M, >> >> +#endif >> >> + .init_machine = ls1021a_init_machine, >> >> + .dt_compat = ls1021a_dt_compat, >> >> + .restart = mxc_restart, >> >> +MACHINE_END >> > >> >I believe someone recently posted a patch to derive the dma_zone_size >> >from device tree. Can yo try to find that and see if that will work for >you? >> > >> >Can you explain what the reason is for needing a DMA zone? >> >> With LPAE enabled on our SoC, we meet the system complaint of >> "coherent DMA mask 0xffffffff is smaller than system GFP_DMA mask >> 0xffffffffffffffff", and I notice that CONFIG_ZONE_DMA and dma_zone_size >is a common resolve for this. > >Ok, I see. The actual point of dma_zone_size however is slightly different, >and I think you should not use it like this. We normally only use ZONE_DMA >if there are devices that have a limitation smaller than 4GB, and that >appear to be the case for your system. > >The message you quote is only present in arch/powerpc, so I'm not sure >what symptoms you are actually seeing. Please try removing the >dma_zone_size setting for your platform and report if it works or what the >symptom is if it does not work with the latest kernel. > >We definitely need to get this to work out of the box without a >dma_zone_size hack. > >Can you describe what the memory layout is of your platform? Can you have >RAM installed above the 4GB physical address boundary? If you can, are >there any devices that are unable to perform DMA into that memory without >the use of an IOMMU? > > Arnd Our first LS1021A support is based on kernel-3.12, where when LPAE enabled it will compare the device's coherent_dma_mask with arm_dma_limit, which is 64-bit 0xffffffffffffffff without CONFIG_ZONE_DMA, with CONFIG_ZONE_DMA can limit the comparison and avoid the warning. All device can address 32-bit address space on LS1021A, With you comment above, I remove the dma_zone_size and only reserve the CONFIG_ZONE_DMA On kernel-3.12, finding all works well, so I will remove the dma_zone_size setting on 3.12. Thanks. I have a look on latest kernel, finding get_coherent_dma_mask() has limited the mask to (u64)DMA_BIT_MASK(32), does this mean the CONFIG_ZONE_DMA is not needed for me here? Thanks. Best Regards, Jingchang
>-----Original Message----- >From: Arnd Bergmann [mailto:arnd@arndb.de] >Sent: Wednesday, September 10, 2014 3:42 PM >To: Lu Jingchang-B35083 >Cc: linux-arm-kernel@lists.infradead.org; Guo Shawn-R65073; >devicetree@vger.kernel.org >Subject: Re: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale >LS1021A > >On Wednesday 10 September 2014 03:31:19 Jingchang Lu wrote: > >> >> +DT_MACHINE_START(LS1021A, "Freescale LS1021A") #ifdef >> >> +CONFIG_ZONE_DMA >> >> + .dma_zone_size = SZ_128M, >> >> +#endif >> >> + .init_machine = ls1021a_init_machine, >> >> + .dt_compat = ls1021a_dt_compat, >> >> + .restart = mxc_restart, >> >> +MACHINE_END >> > >> >I believe someone recently posted a patch to derive the dma_zone_size >> >from device tree. Can yo try to find that and see if that will work for >you? >> > >> >Can you explain what the reason is for needing a DMA zone? >> >> With LPAE enabled on our SoC, we meet the system complaint of >> "coherent DMA mask 0xffffffff is smaller than system GFP_DMA mask >> 0xffffffffffffffff", and I notice that CONFIG_ZONE_DMA and dma_zone_size >is a common resolve for this. > >Ok, I see. The actual point of dma_zone_size however is slightly different, >and I think you should not use it like this. We normally only use ZONE_DMA >if there are devices that have a limitation smaller than 4GB, and that >appear to be the case for your system. > >The message you quote is only present in arch/powerpc, so I'm not sure >what symptoms you are actually seeing. Please try removing the >dma_zone_size setting for your platform and report if it works or what the >symptom is if it does not work with the latest kernel. > >We definitely need to get this to work out of the box without a >dma_zone_size hack. > >Can you describe what the memory layout is of your platform? Can you have >RAM installed above the 4GB physical address boundary? If you can, are >there any devices that are unable to perform DMA into that memory without >the use of an IOMMU? > > Arnd Our platform has implemented the Large physical Address Extension, with 40-bit address space, SDRAM can be above 4GB address, but currently we only use the DDR controller1 at 0x80000000 below 4GB on our QDS and TWR board. Others is above 4GB address. PCIE address is also above 4GB address and we are adding support to it. Thanks. Best Regards, Jingchang
On Thursday 11 September 2014 09:53:56 Jingchang Lu wrote: > >From: Arnd Bergmann [mailto:arnd@arndb.de] > > > >Ok, I see. The actual point of dma_zone_size however is slightly different, > >and I think you should not use it like this. We normally only use ZONE_DMA > >if there are devices that have a limitation smaller than 4GB, and that > >appear to be the case for your system. > > > >The message you quote is only present in arch/powerpc, so I'm not sure > >what symptoms you are actually seeing. Please try removing the > >dma_zone_size setting for your platform and report if it works or what the > >symptom is if it does not work with the latest kernel. > > > >We definitely need to get this to work out of the box without a > >dma_zone_size hack. > > > >Can you describe what the memory layout is of your platform? Can you have > >RAM installed above the 4GB physical address boundary? If you can, are > >there any devices that are unable to perform DMA into that memory without > >the use of an IOMMU? > > > Our first LS1021A support is based on kernel-3.12, where when LPAE enabled > it will compare the device's coherent_dma_mask with arm_dma_limit, which is > 64-bit 0xffffffffffffffff without CONFIG_ZONE_DMA, with CONFIG_ZONE_DMA can > limit the comparison and avoid the warning. > All device can address 32-bit address space on LS1021A, With you comment above, > I remove the dma_zone_size and only reserve the CONFIG_ZONE_DMA On kernel-3.12, > finding all works well, so I will remove the dma_zone_size setting on 3.12. Thanks. Ok, good. > I have a look on latest kernel, finding get_coherent_dma_mask() has limited the mask > to (u64)DMA_BIT_MASK(32), does this mean the CONFIG_ZONE_DMA is not needed for me > here? Thanks. You only need to enable CONFIG_ZONE_DMA in the case of RAM above the 4GB boundary. I would suggest you do the same as some of the other platforms by adding select ZONE_DMA if ARM_LPAE into your Kconfig file. If LPAE is disabled, you know that you won't need ZONE_DMA. Arnd
>-----Original Message----- >From: Arnd Bergmann [mailto:arnd@arndb.de] >Sent: Thursday, September 11, 2014 6:45 PM >To: Lu Jingchang-B35083 >Cc: linux-arm-kernel@lists.infradead.org; Guo Shawn-R65073; >devicetree@vger.kernel.org >Subject: Re: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale >LS1021A > >On Thursday 11 September 2014 09:53:56 Jingchang Lu wrote: >> >From: Arnd Bergmann [mailto:arnd@arndb.de] >> > >> >Ok, I see. The actual point of dma_zone_size however is slightly >> >different, and I think you should not use it like this. We normally >> >only use ZONE_DMA if there are devices that have a limitation smaller >> >than 4GB, and that appear to be the case for your system. >> > >> >The message you quote is only present in arch/powerpc, so I'm not >> >sure what symptoms you are actually seeing. Please try removing the >> >dma_zone_size setting for your platform and report if it works or >> >what the symptom is if it does not work with the latest kernel. >> > >> >We definitely need to get this to work out of the box without a >> >dma_zone_size hack. >> > >> >Can you describe what the memory layout is of your platform? Can you >> >have RAM installed above the 4GB physical address boundary? If you >> >can, are there any devices that are unable to perform DMA into that >> >memory without the use of an IOMMU? >> > >> Our first LS1021A support is based on kernel-3.12, where when LPAE >> enabled it will compare the device's coherent_dma_mask with >> arm_dma_limit, which is 64-bit 0xffffffffffffffff without >> CONFIG_ZONE_DMA, with CONFIG_ZONE_DMA can limit the comparison and avoid >the warning. >> All device can address 32-bit address space on LS1021A, With you >> comment above, I remove the dma_zone_size and only reserve the >> CONFIG_ZONE_DMA On kernel-3.12, finding all works well, so I will remove >the dma_zone_size setting on 3.12. Thanks. > >Ok, good. > >> I have a look on latest kernel, finding get_coherent_dma_mask() has >> limited the mask to (u64)DMA_BIT_MASK(32), does this mean the >> CONFIG_ZONE_DMA is not needed for me here? Thanks. > >You only need to enable CONFIG_ZONE_DMA in the case of RAM above the 4GB >boundary. I would suggest you do the same as some of the other platforms >by adding > > select ZONE_DMA if ARM_LPAE > >into your Kconfig file. If LPAE is disabled, you know that you won't need >ZONE_DMA. > > Arnd I will do that. Thanks. Best Regards, Jingchang
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 3da9f71..ba7a089 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -651,6 +651,20 @@ config SOC_VF610 help This enable support for Freescale Vybrid VF610 processor. +config SOC_LS1021A + bool "Freescale LS1021A support" + select CPU_V7 + select ARM_GIC + select CLKSRC_OF + select HAVE_ARM_ARCH_TIMER + select HAVE_SMP + select MIGHT_HAVE_PCI + select PCI_DOMAINS if PCI + select ZONE_DMA if ARM_LPAE + + help + This enable support for Freescale LS1021A processor. + endif source "arch/arm/mach-imx/devices/Kconfig" diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile index dd674c7..3e12532 100644 --- a/arch/arm/mach-imx/Makefile +++ b/arch/arm/mach-imx/Makefile @@ -111,4 +111,6 @@ obj-$(CONFIG_SOC_IMX53) += mach-imx53.o obj-$(CONFIG_SOC_VF610) += clk-vf610.o mach-vf610.o +obj-$(CONFIG_SOC_LS1021A) += mach-ls1021a.o + obj-y += devices/ diff --git a/arch/arm/mach-imx/mach-ls1021a.c b/arch/arm/mach-imx/mach-ls1021a.c new file mode 100644 index 0000000..2ffc20f --- /dev/null +++ b/arch/arm/mach-imx/mach-ls1021a.c @@ -0,0 +1,33 @@ +/* + * Copyright 2013-2014 Freescale Semiconductor, Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include <linux/of_platform.h> +#include <asm/mach/arch.h> + +#include "common.h" + +static void __init ls1021a_init_machine(void) +{ + mxc_arch_reset_init_dt(); + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); +} + +static const char *ls1021a_dt_compat[] __initdata = { + "fsl,ls1021a", + NULL, +}; + +DT_MACHINE_START(LS1021A, "Freescale LS1021A") +#ifdef CONFIG_ZONE_DMA + .dma_zone_size = SZ_128M, +#endif + .init_machine = ls1021a_init_machine, + .dt_compat = ls1021a_dt_compat, + .restart = mxc_restart, +MACHINE_END