| Message ID | 1386825152-398-1-git-send-email-panchaxari.prasannamurthy@linaro.org |
|---|---|
| State | New |
| Headers | show |
Hi panchaxari, On Thursday 12 of December 2013 10:42:32 panchaxari wrote: > ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR have been enabled as default configs > to S5P64X0 platforms. > > Introduction of PHYS_VIRT config as default would enable phy-to-virt and > virt-to-phy translation function at boot and module loading time > and enforce dynamic reallocation of memory. AUTO_ZRELADDR config would > enable calculation of kernel load address at run time. > > PHYS_VIRT config is mutually exclusive to XIP_KERNEL, XIP_KERNEL is used in > systems with NOR flash devices, and ZRELADDR config is mutually exclusive > to ZBOOT_ROM. > > CFT::Call For Testing > > Requesting maintainers of S5P64X0 platforms to evaluate the changes on the > board and comment, as I dont have the board for testing and also requesting > an ACK Could you explain the purpose of this change on S5P64x0? This is actually quite a poor platform choice. As of today, the kernel is stuck with supporting just SMDK6440/6450 boards, which are proprietary development boards and it doesn't look like any further boards will show up in future. Kukjin has actually proposed removing support for this platform at all and I consider this reasonable. Kukjin, should we proceed with removal? Best regards, Tomasz
Hi Tomasz > Could you explain the purpose of this change on S5P64x0? > > This is actually quite a poor platform choice. As of today, the kernel > is stuck with supporting just SMDK6440/6450 boards, which are proprietary > development boards and it doesn't look like any further boards will show > up in future. Kukjin has actually proposed removing support for this > platform at all and I consider this reasonable. > > Kukjin, should we proceed with removal? The purpose of this patch is with the greater intent of consolidating ARM-32 kernel. Which means a generic kernel for ARM-32 processors. Hence these platform supported configs are introduced as default for that particular platform. I hope i answered your question. Else please mail me with further queries. thanks Panchaxari
On Thursday 12 of December 2013 16:33:46 Panchaxari Prasannamurthy Tumkur wrote: > Hi Tomasz > > > Could you explain the purpose of this change on S5P64x0? > > > > This is actually quite a poor platform choice. As of today, the kernel > > is stuck with supporting just SMDK6440/6450 boards, which are proprietary > > development boards and it doesn't look like any further boards will show > > up in future. Kukjin has actually proposed removing support for this > > platform at all and I consider this reasonable. > > > > Kukjin, should we proceed with removal? > > The purpose of this patch is with the greater intent of consolidating > ARM-32 kernel. Which means a generic kernel for ARM-32 processors. OK. So do you have plans to send similar patches for other, more active (and closer to having multiplatform support) platforms, such as s3c64xx, s5pv210 and exynos? In case of s5p64x0 probably the only person capable of testing it is Kukjin, as we don't have any other active people with boards based on these SoCs. Best regards, Tomasz
> OK. So do you have plans to send similar patches for other, more active > (and closer to having multiplatform support) platforms, such as s3c64xx, > s5pv210 and exynos? > > In case of s5p64x0 probably the only person capable of testing it is > Kukjin, as we don't have any other active people with boards based on > these SoCs. Yes I have, Exynos is already sent, s3c64xx and s5pv210 are in pipeline. I shall send them shortly. thanks for your guidance. regards pancham
On Thu, Dec 12, 2013 at 10:47 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote: > This is actually quite a poor platform choice. As of today, the kernel > is stuck with supporting just SMDK6440/6450 boards, which are proprietary > development boards and it doesn't look like any further boards will show > up in future. Kukjin has actually proposed removing support for this > platform at all and I consider this reasonable. > > Kukjin, should we proceed with removal? Isn't Mark Brown using that platform for some various stuff? Yours, Linus Walleij
2013/12/12 Linus Walleij <linus.walleij@linaro.org>: > On Thu, Dec 12, 2013 at 10:47 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote: > >> This is actually quite a poor platform choice. As of today, the kernel >> is stuck with supporting just SMDK6440/6450 boards, which are proprietary >> development boards and it doesn't look like any further boards will show >> up in future. Kukjin has actually proposed removing support for this >> platform at all and I consider this reasonable. >> >> Kukjin, should we proceed with removal? > > Isn't Mark Brown using that platform for some various stuff? Not as far as I know. He's using Cragganmore board based on s3c6410, but this is a different platform (s3c64xx). Best regards, Tomasz
On Thu, Dec 12, 2013 at 10:22 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote: > 2013/12/12 Linus Walleij <linus.walleij@linaro.org>: >> On Thu, Dec 12, 2013 at 10:47 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote: >> >>> This is actually quite a poor platform choice. As of today, the kernel >>> is stuck with supporting just SMDK6440/6450 boards, which are proprietary >>> development boards and it doesn't look like any further boards will show >>> up in future. Kukjin has actually proposed removing support for this >>> platform at all and I consider this reasonable. >>> >>> Kukjin, should we proceed with removal? >> >> Isn't Mark Brown using that platform for some various stuff? > > Not as far as I know. > > He's using Cragganmore board based on s3c6410, but this is a different > platform (s3c64xx). Ahhhh I see it now. So the S3C:s are actually in a lot of use and the S5P is one of those stepping stones to Exynos that never really was in any widespread use. Yeah I'm all for deleteing that :-) Thanks! Linus Walleij
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 934e26c..8986335 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -759,6 +759,8 @@ config ARCH_S3C64XX config ARCH_S5P64X0 bool "Samsung S5P6440 S5P6450" + select ARM_PATCH_PHYS_VIRT + select AUTO_ZRELADDR select CLKDEV_LOOKUP select CLKSRC_SAMSUNG_PWM select CPU_V6
ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR have been enabled as default configs to S5P64X0 platforms. Introduction of PHYS_VIRT config as default would enable phy-to-virt and virt-to-phy translation function at boot and module loading time and enforce dynamic reallocation of memory. AUTO_ZRELADDR config would enable calculation of kernel load address at run time. PHYS_VIRT config is mutually exclusive to XIP_KERNEL, XIP_KERNEL is used in systems with NOR flash devices, and ZRELADDR config is mutually exclusive to ZBOOT_ROM. CFT::Call For Testing Requesting maintainers of S5P64X0 platforms to evaluate the changes on the board and comment, as I dont have the board for testing and also requesting an ACK Signed-off-by: panchaxari <panchaxari.prasannamurthy@linaro.org> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: Tomasz Figa <tomasz.figa@gmail.com> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Russell King <linux@arm.linux.org.uk> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- The samsung S5P64X0 vega has an average performing CPU with max speed 667 Mhz. This SOC has two variants S5P6440 and S5P6450. It has one core based on ARM1176JZF-S instruction set, and has 16KB data and instruction cache each. SOC has a memory subsystem with support to NAND Flash interface with x8 data bus, with 1/4/8/12/16 bit hardware ECC circuit and 4KB Page mode. It has Mobile DDR interface with x16 or x32 data bus, and DDR2 interface with x16 or x32 data bus it also supports eMMC4.4. Below lkml link is a quoting by Russell which clears the concept of PHYS_VIRT and ZRELADDR ------------------------------------------------- https://lkml.org/lkml/2011/10/14/434 ------------------------------------------------- --- arch/arm/Kconfig | 2 ++ 1 file changed, 2 insertions(+)