* [PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD @ 2010-12-22 7:09 Philip Rakity 2010-12-22 14:10 ` Arnd Bergmann 0 siblings, 1 reply; 11+ messages in thread From: Philip Rakity @ 2010-12-22 7:09 UTC (permalink / raw) To: linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Mark Brown [-- Attachment #1: Type: text/plain, Size: 2392 bytes --] >From 09a87e2cbf0e58e3c864406fe09cee8ec1024f91 Mon Sep 17 00:00:00 2001 From: Philip Rakity <prakity@marvell.com> Date: Mon, 20 Dec 2010 11:41:07 -0800 Subject: [PATCH] arch-arm: allow PXA168/PXA910/MMP2 SoC to be selected - not same The PXA168, PXA910, and MMP2 are not the same SOC. The family of embedded processors have slightly different internal blocks for SD, I2C, etc. Sometimes it is important to know which SOC is being used due to differences in the silicon. Sometimes it is important to know evaluation boards should be selected based on the SOC on the board. Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Mark. F. Brown <markb@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> --- arch/arm/Kconfig | 40 ++++++++++++++++++++++++++++++---------- 1 files changed, 30 insertions(+), 10 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index efe07d4..b6edd4f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -516,18 +516,28 @@ config ARCH_ORION5X Orion-1 (5181), Orion-VoIP (5181L), Orion-NAS (5182), Orion-2 (5281), Orion-1-90 (6183). -config ARCH_MMP - bool "Marvell PXA168/910/MMP2" +config ARCH_PXA168 + bool "Marvell PXA168" + select ARCH_MMP + select CPU_PXA168 + help + Support for Marvell PXA168 processor line. + +config ARCH_PXA910 + bool "Marvell PXA910" depends on MMU - select ARCH_REQUIRE_GPIOLIB - select CLKDEV_LOOKUP - select GENERIC_CLOCKEVENTS - select HAVE_SCHED_CLOCK - select TICK_ONESHOT - select PLAT_PXA - select SPARSE_IRQ + select ARCH_MMP + select CPU_PXA910 help - Support for Marvell's PXA168/PXA910(MMP) and MMP2 processor line. + Support for Marvell PXA910 processor line. + +config ARCH_MMP2 + bool "Marvell MMP2" + depends on MMU + select ARCH_MMP + select CPU_MMP2 + help + Support for Marvell MMP2 processor line. config ARCH_KS8695 bool "Micrel/Kendin KS8695" @@ -948,6 +958,16 @@ source "arch/arm/mach-orion5x/Kconfig" source "arch/arm/mach-pxa/Kconfig" source "arch/arm/plat-pxa/Kconfig" +config ARCH_MMP + bool + select ARCH_REQUIRE_GPIOLIB + select CLKDEV_LOOKUP + select GENERIC_CLOCKEVENTS + select HAVE_SCHED_CLOCK + select TICK_ONESHOT + select PLAT_PXA + select SPARSE_IRQ + source "arch/arm/mach-mmp/Kconfig" source "arch/arm/mach-realview/Kconfig" -- 1.6.0.4 [-- Attachment #2: 0015-arch-arm-allow-PXA168-PXA910-MMP2-SoC-to-be-selecte.patch --] [-- Type: application/octet-stream, Size: 2311 bytes --] From 09a87e2cbf0e58e3c864406fe09cee8ec1024f91 Mon Sep 17 00:00:00 2001 From: Philip Rakity <prakity@marvell.com> Date: Mon, 20 Dec 2010 11:41:07 -0800 Subject: [PATCH] arch-arm: allow PXA168/PXA910/MMP2 SoC to be selected - not same The PXA168, PXA910, and MMP2 are not the same SOC. The family of embedded processors have slightly different internal blocks for SD, I2C, etc. Sometimes it is important to know which SOC is being used due to differences in the silicon. Sometimes it is important to know evaluation boards should be selected based on the SOC on the board. Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Mark. F. Brown <markb@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> --- arch/arm/Kconfig | 40 ++++++++++++++++++++++++++++++---------- 1 files changed, 30 insertions(+), 10 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index efe07d4..b6edd4f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -516,18 +516,28 @@ config ARCH_ORION5X Orion-1 (5181), Orion-VoIP (5181L), Orion-NAS (5182), Orion-2 (5281), Orion-1-90 (6183). -config ARCH_MMP - bool "Marvell PXA168/910/MMP2" +config ARCH_PXA168 + bool "Marvell PXA168" + select ARCH_MMP + select CPU_PXA168 + help + Support for Marvell PXA168 processor line. + +config ARCH_PXA910 + bool "Marvell PXA910" depends on MMU - select ARCH_REQUIRE_GPIOLIB - select CLKDEV_LOOKUP - select GENERIC_CLOCKEVENTS - select HAVE_SCHED_CLOCK - select TICK_ONESHOT - select PLAT_PXA - select SPARSE_IRQ + select ARCH_MMP + select CPU_PXA910 help - Support for Marvell's PXA168/PXA910(MMP) and MMP2 processor line. + Support for Marvell PXA910 processor line. + +config ARCH_MMP2 + bool "Marvell MMP2" + depends on MMU + select ARCH_MMP + select CPU_MMP2 + help + Support for Marvell MMP2 processor line. config ARCH_KS8695 bool "Micrel/Kendin KS8695" @@ -948,6 +958,16 @@ source "arch/arm/mach-orion5x/Kconfig" source "arch/arm/mach-pxa/Kconfig" source "arch/arm/plat-pxa/Kconfig" +config ARCH_MMP + bool + select ARCH_REQUIRE_GPIOLIB + select CLKDEV_LOOKUP + select GENERIC_CLOCKEVENTS + select HAVE_SCHED_CLOCK + select TICK_ONESHOT + select PLAT_PXA + select SPARSE_IRQ + source "arch/arm/mach-mmp/Kconfig" source "arch/arm/mach-realview/Kconfig" -- 1.6.0.4 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD 2010-12-22 7:09 [PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD Philip Rakity @ 2010-12-22 14:10 ` Arnd Bergmann 2010-12-22 22:58 ` Philip Rakity 0 siblings, 1 reply; 11+ messages in thread From: Arnd Bergmann @ 2010-12-22 14:10 UTC (permalink / raw) To: linux-arm-kernel; +Cc: Philip Rakity, linux-mmc@vger.kernel.org, Mark Brown On Wednesday 22 December 2010 08:09:58 Philip Rakity wrote: > The PXA168, PXA910, and MMP2 are not the same SOC. The family > of embedded processors have slightly different internal blocks > for SD, I2C, etc. Sometimes it is important to know which SOC > is being used due to differences in the silicon. Sometimes it > is important to know evaluation boards should be selected based > on the SOC on the board. This looks like you're moving in the wrong direction. If the chips are just slightly different, you'd certainly want to make sure that you can detect the difference at runtime, and be able to use the same kernel on all of the variants. Instead, you promote each of the SOCs to a top-level family in this patch, which makes it impossible to build a kernel for more than one of them at a time. Arnd ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD 2010-12-22 14:10 ` Arnd Bergmann @ 2010-12-22 22:58 ` Philip Rakity 2010-12-31 5:46 ` Haojian Zhuang 0 siblings, 1 reply; 11+ messages in thread From: Philip Rakity @ 2010-12-22 22:58 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel@lists.infradead.org, linux-mmc@vger.kernel.org, Mark Brown On Dec 22, 2010, at 6:10 AM, Arnd Bergmann wrote: > On Wednesday 22 December 2010 08:09:58 Philip Rakity wrote: >> The PXA168, PXA910, and MMP2 are not the same SOC. The family >> of embedded processors have slightly different internal blocks >> for SD, I2C, etc. Sometimes it is important to know which SOC >> is being used due to differences in the silicon. Sometimes it >> is important to know evaluation boards should be selected based >> on the SOC on the board. > > This looks like you're moving in the wrong direction. > > If the chips are just slightly different, you'd certainly > want to make sure that you can detect the difference at runtime, > and be able to use the same kernel on all of the variants. MMP2 used PJ4 core --- PXA168/PXA910 use PJ1 so rather different architecture. PXA168/PXA910 have slightly different internal peripherals with different quirks. Certainly possible to tell this apart at runtime but not all peripherals are the same and startup files ARE different. > > Instead, you promote each of the SOCs to a top-level family > in this patch, which makes it impossible to build a kernel > for more than one of them at a time. That was the intent to handle the case of development board selection. it is meaningless to select MMP2 development board with say PXA168 SoC. Open to other way to handle this problem. Suggestions welcome. > > Arnd ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD 2010-12-22 22:58 ` Philip Rakity @ 2010-12-31 5:46 ` Haojian Zhuang 2010-12-31 6:03 ` Philip Rakity 0 siblings, 1 reply; 11+ messages in thread From: Haojian Zhuang @ 2010-12-31 5:46 UTC (permalink / raw) To: Philip Rakity Cc: Arnd Bergmann, Mark Brown, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org On Thu, Dec 23, 2010 at 6:58 AM, Philip Rakity <prakity@marvell.com> wrote: > > On Dec 22, 2010, at 6:10 AM, Arnd Bergmann wrote: > >> On Wednesday 22 December 2010 08:09:58 Philip Rakity wrote: >>> The PXA168, PXA910, and MMP2 are not the same SOC. The family >>> of embedded processors have slightly different internal blocks >>> for SD, I2C, etc. Sometimes it is important to know which SOC >>> is being used due to differences in the silicon. Sometimes it >>> is important to know evaluation boards should be selected based >>> on the SOC on the board. >> >> This looks like you're moving in the wrong direction. >> >> If the chips are just slightly different, you'd certainly >> want to make sure that you can detect the difference at runtime, >> and be able to use the same kernel on all of the variants. > > MMP2 used PJ4 core --- PXA168/PXA910 use PJ1 so rather different architecture. > > PXA168/PXA910 have slightly different internal peripherals with different quirks. > Certainly possible to tell this apart at runtime but not all peripherals are the same > and startup files ARE different. > > MMP2 and PJ4 are different SoC silicons. But they're using similar SD IP, so we can share same driver to them. Different quirks can be handled by different flags in run time. There's no reason to copy driver for each silicon. >> >> Instead, you promote each of the SOCs to a top-level family >> in this patch, which makes it impossible to build a kernel >> for more than one of them at a time. > > That was the intent to handle the case of development board selection. > it is meaningless to select MMP2 development board with say PXA168 SoC. > > Open to other way to handle this problem. Suggestions welcome. > Again, you did wrong. You couldn't make patch for top-level family. It will introduce a lot of error to maintainers. Your patches will make them mess. Thanks Haojian >> >> Arnd > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD 2010-12-31 5:46 ` Haojian Zhuang @ 2010-12-31 6:03 ` Philip Rakity 2010-12-31 6:46 ` Haojian Zhuang 2011-01-06 19:29 ` Arnd Bergmann 0 siblings, 2 replies; 11+ messages in thread From: Philip Rakity @ 2010-12-31 6:03 UTC (permalink / raw) To: Haojian Zhuang Cc: Arnd Bergmann, Mark Brown, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org On Dec 30, 2010, at 9:46 PM, Haojian Zhuang wrote: > On Thu, Dec 23, 2010 at 6:58 AM, Philip Rakity <prakity@marvell.com> wrote: >> >> On Dec 22, 2010, at 6:10 AM, Arnd Bergmann wrote: >> >>> On Wednesday 22 December 2010 08:09:58 Philip Rakity wrote: >>>> The PXA168, PXA910, and MMP2 are not the same SOC. The family >>>> of embedded processors have slightly different internal blocks >>>> for SD, I2C, etc. Sometimes it is important to know which SOC >>>> is being used due to differences in the silicon. Sometimes it >>>> is important to know evaluation boards should be selected based >>>> on the SOC on the board. >>> >>> This looks like you're moving in the wrong direction. >>> >>> If the chips are just slightly different, you'd certainly >>> want to make sure that you can detect the difference at runtime, >>> and be able to use the same kernel on all of the variants. >> >> MMP2 used PJ4 core --- PXA168/PXA910 use PJ1 so rather different architecture. >> >> PXA168/PXA910 have slightly different internal peripherals with different quirks. >> Certainly possible to tell this apart at runtime but not all peripherals are the same >> and startup files ARE different. >> >> > MMP2 and PJ4 are different SoC silicons. But they're using similar SD > IP, so we can share same driver to them. Different quirks can be > handled by different flags in run time. > The SD IP is not the same. One uses SD controller 3.0 and the other is 2.0. They are the same in the sense that they public registers adhere to the appropriate SD spec 2.0/3.0 but these accesses are handled by sdhci.c. (SD 3.0 extends the SD 2.0 spec by adding new registers and adding some bit definitions in a compatible manner inside the public space). The private registers that need to be programmed are not extensions but are at different locations and bit fields do not have exactly the same meaning. The code to handle the differences is rather small and is not NOT placed in arch/arm/ directory but rather in the drivers/mmc/host directory and follows the conventions to handle this. > There's no reason to copy driver for each silicon > >>> >>> Instead, you promote each of the SOCs to a top-level family >>> in this patch, which makes it impossible to build a kernel >>> for more than one of them at a time. >> >> That was the intent to handle the case of development board selection. >> it is meaningless to select MMP2 development board with say PXA168 SoC. >> >> Open to other way to handle this problem. Suggestions welcome. >> > Again, you did wrong. You couldn't make patch for top-level family. It > will introduce a lot of error to maintainers. The patch selects ARCH-MMP (as now) but adds the ability to also know which specific SoC was chosen. (This is sort of done by choosing the development board today). > > Your patches will make them mess. suggest a solution. The current mechanism of having the development board select the CPU does not seem right. One can select a development board for MMP2 and PXA168 and yet the arch files to support each CPU are different and not compatible. (for example cache handling). > > Thanks > Haojian > >>> >>> Arnd >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD 2010-12-31 6:03 ` Philip Rakity @ 2010-12-31 6:46 ` Haojian Zhuang 2010-12-31 22:08 ` Mark Brown 2011-01-06 19:29 ` Arnd Bergmann 1 sibling, 1 reply; 11+ messages in thread From: Haojian Zhuang @ 2010-12-31 6:46 UTC (permalink / raw) To: Philip Rakity Cc: Arnd Bergmann, Mark Brown, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org On Fri, Dec 31, 2010 at 2:03 PM, Philip Rakity <prakity@marvell.com> wrote: > > On Dec 30, 2010, at 9:46 PM, Haojian Zhuang wrote: > >> On Thu, Dec 23, 2010 at 6:58 AM, Philip Rakity <prakity@marvell.com> wrote: >>> >>> On Dec 22, 2010, at 6:10 AM, Arnd Bergmann wrote: >>> >>>> On Wednesday 22 December 2010 08:09:58 Philip Rakity wrote: >>>>> The PXA168, PXA910, and MMP2 are not the same SOC. The family >>>>> of embedded processors have slightly different internal blocks >>>>> for SD, I2C, etc. Sometimes it is important to know which SOC >>>>> is being used due to differences in the silicon. Sometimes it >>>>> is important to know evaluation boards should be selected based >>>>> on the SOC on the board. >>>> >>>> This looks like you're moving in the wrong direction. >>>> >>>> If the chips are just slightly different, you'd certainly >>>> want to make sure that you can detect the difference at runtime, >>>> and be able to use the same kernel on all of the variants. >>> >>> MMP2 used PJ4 core --- PXA168/PXA910 use PJ1 so rather different architecture. >>> >>> PXA168/PXA910 have slightly different internal peripherals with different quirks. >>> Certainly possible to tell this apart at runtime but not all peripherals are the same >>> and startup files ARE different. >>> >>> >> MMP2 and PJ4 are different SoC silicons. But they're using similar SD >> IP, so we can share same driver to them. Different quirks can be >> handled by different flags in run time. >> > > The SD IP is not the same. One uses SD controller 3.0 and the other is 2.0. > > They are the same in the sense that they public registers adhere to the appropriate SD spec 2.0/3.0 but > these accesses are handled by sdhci.c. (SD 3.0 extends the SD 2.0 spec by adding new registers and adding some bit definitions > in a compatible manner inside the public space). > Yes, you confirmed that they're same in the sense. It's enough. User needn't care whether it's SD2.0 or SD3.0. It's the business of silicon engineer. > The private registers that need to be programmed are not extensions but are at different locations and bit fields do not have exactly the same meaning. > > The code to handle the differences is rather small and is not NOT placed in arch/arm/ directory but rather in the > drivers/mmc/host directory and follows the conventions to handle this. > In your patch, you divide them into silicon depedant files. I think that putting them into arch/arm is better. > >> There's no reason to copy driver for each silicon > >> >>>> >>>> Instead, you promote each of the SOCs to a top-level family >>>> in this patch, which makes it impossible to build a kernel >>>> for more than one of them at a time. >>> >>> That was the intent to handle the case of development board selection. >>> it is meaningless to select MMP2 development board with say PXA168 SoC. >>> >>> Open to other way to handle this problem. Suggestions welcome. >>> >> Again, you did wrong. You couldn't make patch for top-level family. It >> will introduce a lot of error to maintainers. > > The patch selects ARCH-MMP (as now) but adds the ability > to also know which specific SoC was chosen. (This is sort of done by choosing the development board today). > If you want to change mmc code, push it into mmc tree. If you want to change pxa code, push it into pxa tree. If they're dependant, please make sure the sequence is right. > >> >> Your patches will make them mess. > > suggest a solution. > > The current mechanism of having the development board select the CPU does not seem right. > One can select a development board for MMP2 and PXA168 and yet the arch files to support each CPU > are different and not compatible. (for example cache handling). > Only one SoC can be installed on one board. If silicons are pin-compatible to one board, we can register different boards. For example, we can divide saarb as saarb_pv and saarb_mg. If MMP2 and PXA168 are both installed on one board, it means that you must run two kernel images on two APs. Actually, I don't think anyone will design system like this way. If so, why not adopt the above policy? You can divide the board into two sub-board on naming policy. >> >> Thanks >> Haojian >> >>>> >>>> Arnd >>> >>> >>> _______________________________________________ >>> linux-arm-kernel mailing list >>> linux-arm-kernel@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>> > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD 2010-12-31 6:46 ` Haojian Zhuang @ 2010-12-31 22:08 ` Mark Brown 2011-01-04 6:10 ` zhangfei gao 0 siblings, 1 reply; 11+ messages in thread From: Mark Brown @ 2010-12-31 22:08 UTC (permalink / raw) To: Haojian Zhuang Cc: Philip Rakity, Arnd Bergmann, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org On Dec 31, 2010, at 1:46 AM, Haojian Zhuang wrote: > On Fri, Dec 31, 2010 at 2:03 PM, Philip Rakity <prakity@marvell.com> wrote: >> >> On Dec 30, 2010, at 9:46 PM, Haojian Zhuang wrote: >> >>> On Thu, Dec 23, 2010 at 6:58 AM, Philip Rakity <prakity@marvell.com> wrote: >>>> >>>> On Dec 22, 2010, at 6:10 AM, Arnd Bergmann wrote: >>>> >>>>> On Wednesday 22 December 2010 08:09:58 Philip Rakity wrote: >>>>>> The PXA168, PXA910, and MMP2 are not the same SOC. The family >>>>>> of embedded processors have slightly different internal blocks >>>>>> for SD, I2C, etc. Sometimes it is important to know which SOC >>>>>> is being used due to differences in the silicon. Sometimes it >>>>>> is important to know evaluation boards should be selected based >>>>>> on the SOC on the board. >>>>> >>>>> This looks like you're moving in the wrong direction. >>>>> >>>>> If the chips are just slightly different, you'd certainly >>>>> want to make sure that you can detect the difference at runtime, >>>>> and be able to use the same kernel on all of the variants. >>>> >>>> MMP2 used PJ4 core --- PXA168/PXA910 use PJ1 so rather different architecture. >>>> >>>> PXA168/PXA910 have slightly different internal peripherals with different quirks. >>>> Certainly possible to tell this apart at runtime but not all peripherals are the same >>>> and startup files ARE different. >>>> >>>> >>> MMP2 and PJ4 are different SoC silicons. But they're using similar SD I think you meant MMP2 and PJ1 there. MMP2 is a PJ4 core. >>> IP, so we can share same driver to them. Different quirks can be >>> handled by different flags in run time. Technically all of these SDHCI controllers are extremely similar. The point of the SDHCI-* family of drivers are there to specify the implementation differences. sdhci-pxa codebase is currently minimal it performs two operations: 1. Register sdhci instance using platform data. 2. Define common quirks. 3. Provides clock control callback The PXA168/PXA910 (PJ1) versions would have specific needs: 1. There is a difference in clock control and power up sequencing 2. There is a specific I/O accessor needed to access registers 3. There are workarounds for SDIO that are needed. 4. There specific quirks needed for the PXA168/PXA910. Even if we were to write a separate driver for PXA168/910 and MMP2 there would be no code duplication except for the code to interpret the platform data. In Philip's code he took the duplication into account and further abstracted it so that the platform data interpretation is done in sdhci-pxa.c and the differences are exposed in the sdhci-pxa168 and sdhci-mmp2 modules. There is already precedence for this already in sdhci-of-* implementation. I am not sure why people think combining all of these differences into one massive sdhci-pxa driver would make maintenance simpler when the relevant commonality is already abstracted away in sdhci.c. >>> >> >> The SD IP is not the same. One uses SD controller 3.0 and the other is 2.0. >> >> They are the same in the sense that they public registers adhere to the appropriate SD spec 2.0/3.0 but >> these accesses are handled by sdhci.c. (SD 3.0 extends the SD 2.0 spec by adding new registers and adding some bit definitions >> in a compatible manner inside the public space). >> > Yes, you confirmed that they're same in the sense. It's enough. User > needn't care whether it's SD2.0 or SD3.0. It's the business of silicon > engineer. > >> The private registers that need to be programmed are not extensions but are at different locations and bit fields do not have exactly the same meaning. >> >> The code to handle the differences is rather small and is not NOT placed in arch/arm/ directory but rather in the >> drivers/mmc/host directory and follows the conventions to handle this. >> > In your patch, you divide them into silicon depedant files. I think > that putting them into arch/arm is better. > >> >>> There's no reason to copy driver for each silicon >> >>> >>>>> >>>>> Instead, you promote each of the SOCs to a top-level family >>>>> in this patch, which makes it impossible to build a kernel >>>>> for more than one of them at a time. >>>> >>>> That was the intent to handle the case of development board selection. >>>> it is meaningless to select MMP2 development board with say PXA168 SoC. >>>> >>>> Open to other way to handle this problem. Suggestions welcome. >>>> >>> Again, you did wrong. You couldn't make patch for top-level family. It >>> will introduce a lot of error to maintainers. >> >> The patch selects ARCH-MMP (as now) but adds the ability >> to also know which specific SoC was chosen. (This is sort of done by choosing the development board today). >> > If you want to change mmc code, push it into mmc tree. If you want to > change pxa code, push it into pxa tree. If they're dependant, please > make sure the sequence is right. >> >>> >>> Your patches will make them mess. >> >> suggest a solution. >> >> The current mechanism of having the development board select the CPU does not seem right. >> One can select a development board for MMP2 and PXA168 and yet the arch files to support each CPU >> are different and not compatible. (for example cache handling). >> > Only one SoC can be installed on one board. If silicons are > pin-compatible to one board, we can register different boards. For > example, we can divide saarb as saarb_pv and saarb_mg. > > If MMP2 and PXA168 are both installed on one board, it means that you > must run two kernel images on two APs. Actually, I don't think anyone > will design system like this way. If so, why not adopt the above > policy? You can divide the board into two sub-board on naming policy. >>> >>> Thanks >>> Haojian >>> >>>>> >>>>> Arnd >>>> >>>> >>>> _______________________________________________ >>>> linux-arm-kernel mailing list >>>> linux-arm-kernel@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>>> >> >> ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD 2010-12-31 22:08 ` Mark Brown @ 2011-01-04 6:10 ` zhangfei gao 0 siblings, 0 replies; 11+ messages in thread From: zhangfei gao @ 2011-01-04 6:10 UTC (permalink / raw) To: Mark Brown Cc: Haojian Zhuang, Philip Rakity, Arnd Bergmann, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org On Fri, Dec 31, 2010 at 5:08 PM, Mark Brown <markb@marvell.com> wrote: > On Dec 31, 2010, at 1:46 AM, Haojian Zhuang wrote: > >> On Fri, Dec 31, 2010 at 2:03 PM, Philip Rakity <prakity@marvell.com> wrote: >>> >>> On Dec 30, 2010, at 9:46 PM, Haojian Zhuang wrote: >>> >>>> On Thu, Dec 23, 2010 at 6:58 AM, Philip Rakity <prakity@marvell.com> wrote: >>>>> >>>>> On Dec 22, 2010, at 6:10 AM, Arnd Bergmann wrote: >>>>> >>>>>> On Wednesday 22 December 2010 08:09:58 Philip Rakity wrote: >>>>>>> The PXA168, PXA910, and MMP2 are not the same SOC. The family >>>>>>> of embedded processors have slightly different internal blocks >>>>>>> for SD, I2C, etc. Sometimes it is important to know which SOC >>>>>>> is being used due to differences in the silicon. Sometimes it >>>>>>> is important to know evaluation boards should be selected based >>>>>>> on the SOC on the board. >>>>>> >>>>>> This looks like you're moving in the wrong direction. >>>>>> >>>>>> If the chips are just slightly different, you'd certainly >>>>>> want to make sure that you can detect the difference at runtime, >>>>>> and be able to use the same kernel on all of the variants. >>>>> >>>>> MMP2 used PJ4 core --- PXA168/PXA910 use PJ1 so rather different architecture. >>>>> >>>>> PXA168/PXA910 have slightly different internal peripherals with different quirks. >>>>> Certainly possible to tell this apart at runtime but not all peripherals are the same >>>>> and startup files ARE different. >>>>> >>>>> >>>> MMP2 and PJ4 are different SoC silicons. But they're using similar SD > > I think you meant MMP2 and PJ1 there. MMP2 is a PJ4 core. > >>>> IP, so we can share same driver to them. Different quirks can be >>>> handled by different flags in run time. > > Technically all of these SDHCI controllers are extremely similar. The point of the SDHCI-* family of drivers > are there to specify the implementation differences. > > sdhci-pxa codebase is currently minimal it performs two operations: > 1. Register sdhci instance using platform data. > 2. Define common quirks. > 3. Provides clock control callback > > The PXA168/PXA910 (PJ1) versions would have specific needs: > 1. There is a difference in clock control and power up sequencing > 2. There is a specific I/O accessor needed to access registers > 3. There are workarounds for SDIO that are needed. > 4. There specific quirks needed for the PXA168/PXA910. For mmp2 and pxa910, they are same ip in fact, same silicon bug, and same workaround, and fixed together in updated version. That's the reason they worked well in currently code base with same quirk, same driver. pxa168 may be different since no future stepping. It is true, one is v2, the other is v3, but this is handled in sdhci.c and transparent for specific driver. The only difference is different private register, that may because when define v2 and can not foresee v3 definition. Still not find strong reason to add more specific driver only handle different private register, if so more driver will be added for mmp2x, for example, though same ip are used. BTW, brownstone with mmc support is already added if work based on pxa-linux-2.6.git, devel branch. > > Even if we were to write a separate driver for PXA168/910 and MMP2 there would be no code duplication except for > the code to interpret the platform data. > > In Philip's code he took the duplication into account and further abstracted it so that the platform data interpretation is done in > sdhci-pxa.c and the differences are exposed in the sdhci-pxa168 and sdhci-mmp2 modules. > > There is already precedence for this already in sdhci-of-* implementation. > > I am not sure why people think combining all of these differences into one massive sdhci-pxa driver would make maintenance simpler when the > relevant commonality is already abstracted away in sdhci.c. > >>>> >>> >>> The SD IP is not the same. One uses SD controller 3.0 and the other is 2.0. >>> >>> They are the same in the sense that they public registers adhere to the appropriate SD spec 2.0/3.0 but >>> these accesses are handled by sdhci.c. (SD 3.0 extends the SD 2.0 spec by adding new registers and adding some bit definitions >>> in a compatible manner inside the public space). >>> >> Yes, you confirmed that they're same in the sense. It's enough. User >> needn't care whether it's SD2.0 or SD3.0. It's the business of silicon >> engineer. >> >>> The private registers that need to be programmed are not extensions but are at different locations and bit fields do not have exactly the same meaning. >>> >>> The code to handle the differences is rather small and is not NOT placed in arch/arm/ directory but rather in the >>> drivers/mmc/host directory and follows the conventions to handle this. >>> >> In your patch, you divide them into silicon depedant files. I think >> that putting them into arch/arm is better. >> >>> >>>> There's no reason to copy driver for each silicon >>> >>>> >>>>>> >>>>>> Instead, you promote each of the SOCs to a top-level family >>>>>> in this patch, which makes it impossible to build a kernel >>>>>> for more than one of them at a time. >>>>> >>>>> That was the intent to handle the case of development board selection. >>>>> it is meaningless to select MMP2 development board with say PXA168 SoC. >>>>> >>>>> Open to other way to handle this problem. Suggestions welcome. >>>>> >>>> Again, you did wrong. You couldn't make patch for top-level family. It >>>> will introduce a lot of error to maintainers. >>> >>> The patch selects ARCH-MMP (as now) but adds the ability >>> to also know which specific SoC was chosen. (This is sort of done by choosing the development board today). >>> >> If you want to change mmc code, push it into mmc tree. If you want to >> change pxa code, push it into pxa tree. If they're dependant, please >> make sure the sequence is right. >>> >>>> >>>> Your patches will make them mess. >>> >>> suggest a solution. >>> >>> The current mechanism of having the development board select the CPU does not seem right. >>> One can select a development board for MMP2 and PXA168 and yet the arch files to support each CPU >>> are different and not compatible. (for example cache handling). >>> >> Only one SoC can be installed on one board. If silicons are >> pin-compatible to one board, we can register different boards. For >> example, we can divide saarb as saarb_pv and saarb_mg. >> >> If MMP2 and PXA168 are both installed on one board, it means that you >> must run two kernel images on two APs. Actually, I don't think anyone >> will design system like this way. If so, why not adopt the above >> policy? You can divide the board into two sub-board on naming policy. >>>> >>>> Thanks >>>> Haojian >>>> >>>>>> >>>>>> Arnd >>>>> >>>>> >>>>> _______________________________________________ >>>>> linux-arm-kernel mailing list >>>>> linux-arm-kernel@lists.infradead.org >>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>>>> >>> >>> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD 2010-12-31 6:03 ` Philip Rakity 2010-12-31 6:46 ` Haojian Zhuang @ 2011-01-06 19:29 ` Arnd Bergmann 2011-01-07 16:48 ` Philip Rakity 1 sibling, 1 reply; 11+ messages in thread From: Arnd Bergmann @ 2011-01-06 19:29 UTC (permalink / raw) To: Philip Rakity Cc: Haojian Zhuang, Mark Brown, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org On Friday 31 December 2010, Philip Rakity wrote: > The patch selects ARCH-MMP (as now) but adds the ability > to also know which specific SoC was chosen. (This is sort of done by choosing the development board today). On a larger scale, we try to go in the opposite direction: make it possible to have kernels run on as many boards as possible by decreasing the code differences between SoCs and even SoC families. > > Your patches will make them mess. > > suggest a solution. > > The current mechanism of having the development board select the CPU does not seem right. > One can select a development board for MMP2 and PXA168 and yet the arch files to support each CPU > are different and not compatible. (for example cache handling). The optimal solution would be to make sure that working support for both CPUs can be built into a single kernel. There is a lot of infrastructure in arch/arm/mm/* that tries to do this, but I don't know of that actually works for the combination of CPU_MOHAWK and CPU_V6. It does work for some other combinations of CPU cores though, so it's certainly possible. For instance, arch/arm/include/asm/cacheflush.h has abstractions to select the cache handling at boot time. To go even further, it might make sense to combine the PXA and MMP platforms, since they already share some code through the plat-pxa directory. Getting it running for MMP with mohawk and v6 cores could be a significant amount of work if nobody has tries this in that platform, so for now, I would recommend you just keep ARCH_MMP as a global option in arch/arm/Kconfig for now and add another 'choice' statement in arch/arm/mach-mmp/Kconfig to select the CPU core, with the board selection depending on that. Arnd ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD 2011-01-06 19:29 ` Arnd Bergmann @ 2011-01-07 16:48 ` Philip Rakity 2011-01-07 17:51 ` Arnd Bergmann 0 siblings, 1 reply; 11+ messages in thread From: Philip Rakity @ 2011-01-07 16:48 UTC (permalink / raw) To: Arnd Bergmann Cc: Haojian Zhuang, Mark Brown, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org On Jan 6, 2011, at 11:29 AM, Arnd Bergmann wrote: > On Friday 31 December 2010, Philip Rakity wrote: >> The patch selects ARCH-MMP (as now) but adds the ability >> to also know which specific SoC was chosen. (This is sort of done by choosing the development board today). > > On a larger scale, we try to go in the opposite direction: make it possible to > have kernels run on as many boards as possible by decreasing the code differences > between SoCs and even SoC families. > >>> Your patches will make them mess. >> >> suggest a solution. >> >> The current mechanism of having the development board select the CPU does not seem right. >> One can select a development board for MMP2 and PXA168 and yet the arch files to support each CPU >> are different and not compatible. (for example cache handling). > > The optimal solution would be to make sure that working support for both CPUs can be built into > a single kernel. There is a lot of infrastructure in arch/arm/mm/* that tries to do this, but > I don't know of that actually works for the combination of CPU_MOHAWK and CPU_V6. It does > work for some other combinations of CPU cores though, so it's certainly possible. > For instance, arch/arm/include/asm/cacheflush.h has abstractions to select the cache handling > at boot time. > > To go even further, it might make sense to combine the PXA and MMP platforms, since they already > share some code through the plat-pxa directory. > > Getting it running for MMP with mohawk and v6 cores could be a significant amount of work if > nobody has tries this in that platform, so for now, I would recommend you just keep ARCH_MMP as > a global option in arch/arm/Kconfig for now and add another 'choice' statement in > arch/arm/mach-mmp/Kconfig to select the CPU core, with the board selection depending on that. > Thanks for the suggestion. Let me see if I can implement this. A couple of points first a) current implementation once PXA168/910 is selected will no longer show MMP2 boards so it is also broken. Play around and you will see the issues My proposed patch did the following a) ARCH_MMP is set when PXA168, PXA910 or MMP2 are selected (from arch/arm) b) Board selection uses the PXA168/PXA910/MMP2 to show correct board. If I understand what you are suggesting is the following a) leave ARCH_MMP is system selection alone -- b) move speciific CPU selection to where board selection is now (cpu/arch/mach-mmp) c) what do with development boards ? select all of them for the CPU Type ? Point me to a Kconfig that does what you are suggesting as an example and I can try out the suggestion. > Arnd > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD 2011-01-07 16:48 ` Philip Rakity @ 2011-01-07 17:51 ` Arnd Bergmann 0 siblings, 0 replies; 11+ messages in thread From: Arnd Bergmann @ 2011-01-07 17:51 UTC (permalink / raw) To: Philip Rakity Cc: Haojian Zhuang, Mark Brown, linux-mmc@vger.kernel.org, linux-arm-kernel@lists.infradead.org On Friday 07 January 2011, Philip Rakity wrote: > Thanks for the suggestion. Let me see if I can implement this. > > A couple of points first > > a) current implementation once PXA168/910 is selected will no longer show MMP2 boards so it is also broken. Play around and you will see the issues I didn't see it on the version I'm looking at now, but if it's inconsistent or allows you to select combinationst that cannot be built, then it should be fixed. > My proposed patch did the following > a) ARCH_MMP is set when PXA168, PXA910 or MMP2 are selected (from arch/arm) > b) Board selection uses the PXA168/PXA910/MMP2 to show correct board. Yes, that is what I thought, but it is inconsistent with how other platforms do this. Usually, the top-level selection chooses one source directory, and anything specific to that platform is handled by that Kconfig. > If I understand what you are suggesting is the following > a) leave ARCH_MMP is system selection alone -- > b) move speciific CPU selection to where board selection is now (cpu/arch/mach-mmp) Right. > c) what do with development boards ? select all of them for the CPU Type ? > > Point me to a Kconfig that does what you are suggesting as an example and I can try out the suggestion. Just put it below the CPU selection. OMAP does something like this -- you first select either OMAP1 or OMAP2/3/4, then the families in the latter case, and finally the boards. You can do the same by first giving the choice between ARMv6 and PXA168/910, and then showing the boards below the CPU. There are multiple ways of doing this that lead to the same result. Arnd ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-01-07 17:51 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-12-22 7:09 [PATCH 15/23] Alternative mmc structure to support pxa168, pxa910, mmp2 family SD Philip Rakity 2010-12-22 14:10 ` Arnd Bergmann 2010-12-22 22:58 ` Philip Rakity 2010-12-31 5:46 ` Haojian Zhuang 2010-12-31 6:03 ` Philip Rakity 2010-12-31 6:46 ` Haojian Zhuang 2010-12-31 22:08 ` Mark Brown 2011-01-04 6:10 ` zhangfei gao 2011-01-06 19:29 ` Arnd Bergmann 2011-01-07 16:48 ` Philip Rakity 2011-01-07 17:51 ` Arnd Bergmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox