* Samsung SoCs: preparation for single kernel
@ 2010-06-22 23:27 ` Kyungmin Park
0 siblings, 0 replies; 26+ messages in thread
From: Kyungmin Park @ 2010-06-22 23:27 UTC (permalink / raw)
To: Ben Dooks, arm-linux, linux-samsung-soc
Cc: Russell King - ARM Linux, Marek Szyprowski
To Ben,
I really need single kernel for s5pc110 (cortex A8) and s5pc210
(cortex A9) at least.
Fortunately arm move to these approaches recently. but current Samsung
SoCs not prepare these one.
So I wonder do you have a plan or how to address these issues?
How to assign the address at resources and use it at runtime?
Personally I want to use cpu_is_*. but you reject it to use.
Other way is that we can create the base address variables and assign
it at init time.
Please give your opinions.
Thank you,
Kyungmin Park
e.g., cpu_is_* usage at OMAP tree
static void omap_init_mcspi(void)
{
if (cpu_is_omap44xx())
omap4_mcspi_fixup();
platform_device_register(&omap2_mcspi1);
platform_device_register(&omap2_mcspi2);
if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx())
omap2_mcspi3_init();
if (cpu_is_omap343x() || cpu_is_omap44xx())
omap2_mcspi4_init();
}
^ permalink raw reply [flat|nested] 26+ messages in thread* Samsung SoCs: preparation for single kernel @ 2010-06-22 23:27 ` Kyungmin Park 0 siblings, 0 replies; 26+ messages in thread From: Kyungmin Park @ 2010-06-22 23:27 UTC (permalink / raw) To: linux-arm-kernel To Ben, I really need single kernel for s5pc110 (cortex A8) and s5pc210 (cortex A9) at least. Fortunately arm move to these approaches recently. but current Samsung SoCs not prepare these one. So I wonder do you have a plan or how to address these issues? How to assign the address at resources and use it at runtime? Personally I want to use cpu_is_*. but you reject it to use. Other way is that we can create the base address variables and assign it at init time. Please give your opinions. Thank you, Kyungmin Park e.g., cpu_is_* usage at OMAP tree static void omap_init_mcspi(void) { if (cpu_is_omap44xx()) omap4_mcspi_fixup(); platform_device_register(&omap2_mcspi1); platform_device_register(&omap2_mcspi2); if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) omap2_mcspi3_init(); if (cpu_is_omap343x() || cpu_is_omap44xx()) omap2_mcspi4_init(); } ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Samsung SoCs: preparation for single kernel 2010-06-22 23:27 ` Kyungmin Park @ 2010-06-23 0:50 ` Eric Miao -1 siblings, 0 replies; 26+ messages in thread From: Eric Miao @ 2010-06-23 0:50 UTC (permalink / raw) To: Kyungmin Park Cc: Ben Dooks, arm-linux, linux-samsung-soc, Russell King - ARM Linux, Marek Szyprowski On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park <kmpark@infradead.org> wrote: > To Ben, > > I really need single kernel for s5pc110 (cortex A8) and s5pc210 > (cortex A9) at least. > Fortunately arm move to these approaches recently. but current Samsung > SoCs not prepare these one. > > So I wonder do you have a plan or how to address these issues? > How to assign the address at resources and use it at runtime? > > Personally I want to use cpu_is_*. but you reject it to use. > Other way is that we can create the base address variables and assign > it at init time. > > Please give your opinions. > > Thank you, > Kyungmin Park > > e.g., cpu_is_* usage at OMAP tree > > static void omap_init_mcspi(void) > { > if (cpu_is_omap44xx()) > omap4_mcspi_fixup(); > > platform_device_register(&omap2_mcspi1); > platform_device_register(&omap2_mcspi2); > > if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) > omap2_mcspi3_init(); > > if (cpu_is_omap343x() || cpu_is_omap44xx()) > omap2_mcspi4_init(); > } Just my two cents: cpu_is_*() can be used, but only when absolutely necessary. The s3c does a CPU detection at startup, so I guess the usage of cpu_is_*() can be even reduced. I'm not sure if the above case is a good reference or not. The omap_init_mcspi is called from omap2_init_devices(), while the registration can actually be made into the board init code when that device is used (some of the McSPIs are not used, and it's not necessary to register them), and the differences be handled in the driver. > > _______________________________________________ > 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] 26+ messages in thread
* Samsung SoCs: preparation for single kernel @ 2010-06-23 0:50 ` Eric Miao 0 siblings, 0 replies; 26+ messages in thread From: Eric Miao @ 2010-06-23 0:50 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park <kmpark@infradead.org> wrote: > To Ben, > > I really need single kernel for s5pc110 (cortex A8) and s5pc210 > (cortex A9) at least. > Fortunately arm move to these approaches recently. but current Samsung > SoCs not prepare these one. > > So I wonder do you have a plan or how to address these issues? > How to assign the address at resources and use it at runtime? > > Personally I want to use cpu_is_*. but you reject it to use. > Other way is that we can create the base address variables and assign > it at init time. > > Please give your opinions. > > Thank you, > Kyungmin Park > > e.g., cpu_is_* usage at OMAP tree > > static void omap_init_mcspi(void) > { > ? ? ? ?if (cpu_is_omap44xx()) > ? ? ? ? ? ? ? ?omap4_mcspi_fixup(); > > ? ? ? ?platform_device_register(&omap2_mcspi1); > ? ? ? ?platform_device_register(&omap2_mcspi2); > > ? ? ? ?if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) > ? ? ? ? ? ? ? ?omap2_mcspi3_init(); > > ? ? ? ?if (cpu_is_omap343x() || cpu_is_omap44xx()) > ? ? ? ? ? ? ? ?omap2_mcspi4_init(); > } Just my two cents: cpu_is_*() can be used, but only when absolutely necessary. The s3c does a CPU detection at startup, so I guess the usage of cpu_is_*() can be even reduced. I'm not sure if the above case is a good reference or not. The omap_init_mcspi is called from omap2_init_devices(), while the registration can actually be made into the board init code when that device is used (some of the McSPIs are not used, and it's not necessary to register them), and the differences be handled in the driver. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Samsung SoCs: preparation for single kernel 2010-06-23 0:50 ` Eric Miao @ 2010-06-23 1:47 ` Kyungmin Park -1 siblings, 0 replies; 26+ messages in thread From: Kyungmin Park @ 2010-06-23 1:47 UTC (permalink / raw) To: Eric Miao Cc: Ben Dooks, arm-linux, linux-samsung-soc, Russell King - ARM Linux, Marek Szyprowski On Wed, Jun 23, 2010 at 9:50 AM, Eric Miao <eric.y.miao@gmail.com> wrote: > On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park <kmpark@infradead.org> wrote: >> To Ben, >> >> I really need single kernel for s5pc110 (cortex A8) and s5pc210 >> (cortex A9) at least. >> Fortunately arm move to these approaches recently. but current Samsung >> SoCs not prepare these one. >> >> So I wonder do you have a plan or how to address these issues? >> How to assign the address at resources and use it at runtime? >> >> Personally I want to use cpu_is_*. but you reject it to use. >> Other way is that we can create the base address variables and assign >> it at init time. >> >> Please give your opinions. >> >> Thank you, >> Kyungmin Park >> >> e.g., cpu_is_* usage at OMAP tree >> >> static void omap_init_mcspi(void) >> { >> if (cpu_is_omap44xx()) >> omap4_mcspi_fixup(); >> >> platform_device_register(&omap2_mcspi1); >> platform_device_register(&omap2_mcspi2); >> >> if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) >> omap2_mcspi3_init(); >> >> if (cpu_is_omap343x() || cpu_is_omap44xx()) >> omap2_mcspi4_init(); >> } > > Just my two cents: cpu_is_*() can be used, but only when absolutely necessary. > The s3c does a CPU detection at startup, so I guess the usage of cpu_is_*() > can be even reduced. My concern is that most device resources use the S3C_* or S5P_* prefix and defined at each arch differently. E.G., mmc resource drivers use the S3C_PA_HSMMC0. but each mach has different base address. then how to handle this or make it possible? #define S5PV210_PA_HSMMC(x) (0xEB000000 + ((x) * 0x100000)) #define S3C_PA_HSMMC0 S5PV210_PA_HSMMC(0) #define S3C_PA_HSMMC1 S5PV210_PA_HSMMC(1) #define S3C_PA_HSMMC2 S5PV210_PA_HSMMC(2) #define S5PC100_PA_HSMMC(x) (0xED800000 + ((x) * 0x100000)) #define S3C_PA_HSMMC0 S5PC100_PA_HSMMC(0) #define S3C_PA_HSMMC1 S5PC100_PA_HSMMC(1) #define S3C_PA_HSMMC2 S5PC100_PA_HSMMC(2) #define S3C64XX_PA_HSMMC(x) (0x7C200000 + ((x) * 0x100000)) #define S3C64XX_PA_HSMMC0 S3C64XX_PA_HSMMC(0) #define S3C64XX_PA_HSMMC1 S3C64XX_PA_HSMMC(1) #define S3C64XX_PA_HSMMC2 S3C64XX_PA_HSMMC(2) #define S3C_PA_HSMMC0 S3C64XX_PA_HSMMC0 #define S3C_PA_HSMMC1 S3C64XX_PA_HSMMC1 #define S3C_PA_HSMMC2 S3C64XX_PA_HSMMC2 > > I'm not sure if the above case is a good reference or not. The omap_init_mcspi > is called from omap2_init_devices(), while the registration can actually be > made into the board init code when that device is used (some of the McSPIs are > not used, and it's not necessary to register them), and the differences be > handled in the driver. that's just example how to use cpu_is_* in others. the current schme in samsung SoCs. we passed the different platform name for each arch. e.g., s3c2410_i2c or s3c2440_i2c then i2c driver detect it and handle properly. of course it assume base address is set correctly as above. Thank you, Kyungmin Park > >> >> _______________________________________________ >> 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-samsung-soc" 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] 26+ messages in thread
* Samsung SoCs: preparation for single kernel @ 2010-06-23 1:47 ` Kyungmin Park 0 siblings, 0 replies; 26+ messages in thread From: Kyungmin Park @ 2010-06-23 1:47 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jun 23, 2010 at 9:50 AM, Eric Miao <eric.y.miao@gmail.com> wrote: > On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park <kmpark@infradead.org> wrote: >> To Ben, >> >> I really need single kernel for s5pc110 (cortex A8) and s5pc210 >> (cortex A9) at least. >> Fortunately arm move to these approaches recently. but current Samsung >> SoCs not prepare these one. >> >> So I wonder do you have a plan or how to address these issues? >> How to assign the address at resources and use it at runtime? >> >> Personally I want to use cpu_is_*. but you reject it to use. >> Other way is that we can create the base address variables and assign >> it at init time. >> >> Please give your opinions. >> >> Thank you, >> Kyungmin Park >> >> e.g., cpu_is_* usage at OMAP tree >> >> static void omap_init_mcspi(void) >> { >> ? ? ? ?if (cpu_is_omap44xx()) >> ? ? ? ? ? ? ? ?omap4_mcspi_fixup(); >> >> ? ? ? ?platform_device_register(&omap2_mcspi1); >> ? ? ? ?platform_device_register(&omap2_mcspi2); >> >> ? ? ? ?if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) >> ? ? ? ? ? ? ? ?omap2_mcspi3_init(); >> >> ? ? ? ?if (cpu_is_omap343x() || cpu_is_omap44xx()) >> ? ? ? ? ? ? ? ?omap2_mcspi4_init(); >> } > > Just my two cents: cpu_is_*() can be used, but only when absolutely necessary. > The s3c does a CPU detection at startup, so I guess the usage of cpu_is_*() > can be even reduced. My concern is that most device resources use the S3C_* or S5P_* prefix and defined at each arch differently. E.G., mmc resource drivers use the S3C_PA_HSMMC0. but each mach has different base address. then how to handle this or make it possible? #define S5PV210_PA_HSMMC(x) (0xEB000000 + ((x) * 0x100000)) #define S3C_PA_HSMMC0 S5PV210_PA_HSMMC(0) #define S3C_PA_HSMMC1 S5PV210_PA_HSMMC(1) #define S3C_PA_HSMMC2 S5PV210_PA_HSMMC(2) #define S5PC100_PA_HSMMC(x) (0xED800000 + ((x) * 0x100000)) #define S3C_PA_HSMMC0 S5PC100_PA_HSMMC(0) #define S3C_PA_HSMMC1 S5PC100_PA_HSMMC(1) #define S3C_PA_HSMMC2 S5PC100_PA_HSMMC(2) #define S3C64XX_PA_HSMMC(x) (0x7C200000 + ((x) * 0x100000)) #define S3C64XX_PA_HSMMC0 S3C64XX_PA_HSMMC(0) #define S3C64XX_PA_HSMMC1 S3C64XX_PA_HSMMC(1) #define S3C64XX_PA_HSMMC2 S3C64XX_PA_HSMMC(2) #define S3C_PA_HSMMC0 S3C64XX_PA_HSMMC0 #define S3C_PA_HSMMC1 S3C64XX_PA_HSMMC1 #define S3C_PA_HSMMC2 S3C64XX_PA_HSMMC2 > > I'm not sure if the above case is a good reference or not. The omap_init_mcspi > is called from omap2_init_devices(), while the registration can actually be > made into the board init code when that device is used (some of the McSPIs are > not used, and it's not necessary to register them), and the differences be > handled in the driver. that's just example how to use cpu_is_* in others. the current schme in samsung SoCs. we passed the different platform name for each arch. e.g., s3c2410_i2c or s3c2440_i2c then i2c driver detect it and handle properly. of course it assume base address is set correctly as above. Thank you, Kyungmin Park > >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel at lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at ?http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Samsung SoCs: preparation for single kernel 2010-06-23 1:47 ` Kyungmin Park @ 2010-06-23 1:54 ` Eric Miao -1 siblings, 0 replies; 26+ messages in thread From: Eric Miao @ 2010-06-23 1:54 UTC (permalink / raw) To: Kyungmin Park Cc: Ben Dooks, arm-linux, linux-samsung-soc, Russell King - ARM Linux, Marek Szyprowski On Wed, Jun 23, 2010 at 9:47 AM, Kyungmin Park <kmpark@infradead.org> wrote: > On Wed, Jun 23, 2010 at 9:50 AM, Eric Miao <eric.y.miao@gmail.com> wrote: >> On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park <kmpark@infradead.org> wrote: >>> To Ben, >>> >>> I really need single kernel for s5pc110 (cortex A8) and s5pc210 >>> (cortex A9) at least. >>> Fortunately arm move to these approaches recently. but current Samsung >>> SoCs not prepare these one. >>> >>> So I wonder do you have a plan or how to address these issues? >>> How to assign the address at resources and use it at runtime? >>> >>> Personally I want to use cpu_is_*. but you reject it to use. >>> Other way is that we can create the base address variables and assign >>> it at init time. >>> >>> Please give your opinions. >>> >>> Thank you, >>> Kyungmin Park >>> >>> e.g., cpu_is_* usage at OMAP tree >>> >>> static void omap_init_mcspi(void) >>> { >>> if (cpu_is_omap44xx()) >>> omap4_mcspi_fixup(); >>> >>> platform_device_register(&omap2_mcspi1); >>> platform_device_register(&omap2_mcspi2); >>> >>> if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) >>> omap2_mcspi3_init(); >>> >>> if (cpu_is_omap343x() || cpu_is_omap44xx()) >>> omap2_mcspi4_init(); >>> } >> >> Just my two cents: cpu_is_*() can be used, but only when absolutely necessary. >> The s3c does a CPU detection at startup, so I guess the usage of cpu_is_*() >> can be even reduced. > > My concern is that most device resources use the S3C_* or S5P_* prefix > and defined at each arch differently. > > E.G., mmc resource drivers use the S3C_PA_HSMMC0. but each mach has > different base address. > then how to handle this or make it possible? > Now you have s5pv210_device_hsmmc0 s5pc100_device_hsmmc0 s3c64xx_device_hsmmc0 .... each with a different base. > #define S5PV210_PA_HSMMC(x) (0xEB000000 + ((x) * 0x100000)) > #define S3C_PA_HSMMC0 S5PV210_PA_HSMMC(0) > #define S3C_PA_HSMMC1 S5PV210_PA_HSMMC(1) > #define S3C_PA_HSMMC2 S5PV210_PA_HSMMC(2) > > #define S5PC100_PA_HSMMC(x) (0xED800000 + ((x) * 0x100000)) > #define S3C_PA_HSMMC0 S5PC100_PA_HSMMC(0) > #define S3C_PA_HSMMC1 S5PC100_PA_HSMMC(1) > #define S3C_PA_HSMMC2 S5PC100_PA_HSMMC(2) > > #define S3C64XX_PA_HSMMC(x) (0x7C200000 + ((x) * 0x100000)) > #define S3C64XX_PA_HSMMC0 S3C64XX_PA_HSMMC(0) > #define S3C64XX_PA_HSMMC1 S3C64XX_PA_HSMMC(1) > #define S3C64XX_PA_HSMMC2 S3C64XX_PA_HSMMC(2) > #define S3C_PA_HSMMC0 S3C64XX_PA_HSMMC0 > #define S3C_PA_HSMMC1 S3C64XX_PA_HSMMC1 > #define S3C_PA_HSMMC2 S3C64XX_PA_HSMMC2 > >> >> I'm not sure if the above case is a good reference or not. The omap_init_mcspi >> is called from omap2_init_devices(), while the registration can actually be >> made into the board init code when that device is used (some of the McSPIs are >> not used, and it's not necessary to register them), and the differences be >> handled in the driver. > > that's just example how to use cpu_is_* in others. the current schme > in samsung SoCs. we passed the different platform name for each arch. > e.g., s3c2410_i2c or s3c2440_i2c then i2c driver detect it and handle > properly. of course it assume base address is set correctly as above. For the device driver, when you register two different i2c devices: struct platform_device s3c2410_device_i2c { .name = "s3c2410-i2c", ... }; struct platform_device s3c2440_device_i2c { .name = "s3c2440-i2c", ... }; And register the corresponding one in your board code (your board code knows exactly which one to register, no? ) And then in your i2c driver, you declare: const static struct platform_device_id s3c_i2c_ids[] = { { "s3c2410-i2c", S3C2410_SPECIFIC_FLAGS }, { "s3c2440-i2c", S3C2440_SPECIFIC_FLAGS }, ..... }; Now you have S3C2410_SPECIFIC_FLAGS and S3C2440_SPECIFIC_FLAGS for your device driver to distinguish between the differences. Normally, the differences won't be much, and make sure you have good abstraction of those _SPECIFIC_FLAGS. > > Thank you, > Kyungmin Park >> >>> >>> _______________________________________________ >>> 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-samsung-soc" 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] 26+ messages in thread
* Samsung SoCs: preparation for single kernel @ 2010-06-23 1:54 ` Eric Miao 0 siblings, 0 replies; 26+ messages in thread From: Eric Miao @ 2010-06-23 1:54 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jun 23, 2010 at 9:47 AM, Kyungmin Park <kmpark@infradead.org> wrote: > On Wed, Jun 23, 2010 at 9:50 AM, Eric Miao <eric.y.miao@gmail.com> wrote: >> On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park <kmpark@infradead.org> wrote: >>> To Ben, >>> >>> I really need single kernel for s5pc110 (cortex A8) and s5pc210 >>> (cortex A9) at least. >>> Fortunately arm move to these approaches recently. but current Samsung >>> SoCs not prepare these one. >>> >>> So I wonder do you have a plan or how to address these issues? >>> How to assign the address at resources and use it at runtime? >>> >>> Personally I want to use cpu_is_*. but you reject it to use. >>> Other way is that we can create the base address variables and assign >>> it at init time. >>> >>> Please give your opinions. >>> >>> Thank you, >>> Kyungmin Park >>> >>> e.g., cpu_is_* usage at OMAP tree >>> >>> static void omap_init_mcspi(void) >>> { >>> ? ? ? ?if (cpu_is_omap44xx()) >>> ? ? ? ? ? ? ? ?omap4_mcspi_fixup(); >>> >>> ? ? ? ?platform_device_register(&omap2_mcspi1); >>> ? ? ? ?platform_device_register(&omap2_mcspi2); >>> >>> ? ? ? ?if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) >>> ? ? ? ? ? ? ? ?omap2_mcspi3_init(); >>> >>> ? ? ? ?if (cpu_is_omap343x() || cpu_is_omap44xx()) >>> ? ? ? ? ? ? ? ?omap2_mcspi4_init(); >>> } >> >> Just my two cents: cpu_is_*() can be used, but only when absolutely necessary. >> The s3c does a CPU detection at startup, so I guess the usage of cpu_is_*() >> can be even reduced. > > My concern is that most device resources use the S3C_* or S5P_* prefix > and defined at each arch differently. > > E.G., mmc resource drivers use the S3C_PA_HSMMC0. but each mach has > different base address. > then how to handle this or make it possible? > Now you have s5pv210_device_hsmmc0 s5pc100_device_hsmmc0 s3c64xx_device_hsmmc0 .... each with a different base. > #define S5PV210_PA_HSMMC(x) ? ? (0xEB000000 + ((x) * 0x100000)) > #define S3C_PA_HSMMC0 ? ? ? ? ? S5PV210_PA_HSMMC(0) > #define S3C_PA_HSMMC1 ? ? ? ? ? S5PV210_PA_HSMMC(1) > #define S3C_PA_HSMMC2 ? ? ? ? ? S5PV210_PA_HSMMC(2) > > #define S5PC100_PA_HSMMC(x) ? ? (0xED800000 + ((x) * 0x100000)) > #define S3C_PA_HSMMC0 ? ? ? ? ? S5PC100_PA_HSMMC(0) > #define S3C_PA_HSMMC1 ? ? ? ? ? S5PC100_PA_HSMMC(1) > #define S3C_PA_HSMMC2 ? ? ? ? ? S5PC100_PA_HSMMC(2) > > #define S3C64XX_PA_HSMMC(x) ? ? (0x7C200000 + ((x) * 0x100000)) > #define S3C64XX_PA_HSMMC0 ? ? ? S3C64XX_PA_HSMMC(0) > #define S3C64XX_PA_HSMMC1 ? ? ? S3C64XX_PA_HSMMC(1) > #define S3C64XX_PA_HSMMC2 ? ? ? S3C64XX_PA_HSMMC(2) > #define S3C_PA_HSMMC0 ? ? ? ? ? S3C64XX_PA_HSMMC0 > #define S3C_PA_HSMMC1 ? ? ? ? ? S3C64XX_PA_HSMMC1 > #define S3C_PA_HSMMC2 ? ? ? ? ? S3C64XX_PA_HSMMC2 > >> >> I'm not sure if the above case is a good reference or not. The omap_init_mcspi >> is called from omap2_init_devices(), while the registration can actually be >> made into the board init code when that device is used (some of the McSPIs are >> not used, and it's not necessary to register them), and the differences be >> handled in the driver. > > that's just example how to use cpu_is_* in others. the current schme > in samsung SoCs. we passed the different platform name for each arch. > e.g., s3c2410_i2c or s3c2440_i2c then i2c driver detect it and handle > properly. of course it assume base address is set correctly as above. For the device driver, when you register two different i2c devices: struct platform_device s3c2410_device_i2c { .name = "s3c2410-i2c", ... }; struct platform_device s3c2440_device_i2c { .name = "s3c2440-i2c", ... }; And register the corresponding one in your board code (your board code knows exactly which one to register, no? ) And then in your i2c driver, you declare: const static struct platform_device_id s3c_i2c_ids[] = { { "s3c2410-i2c", S3C2410_SPECIFIC_FLAGS }, { "s3c2440-i2c", S3C2440_SPECIFIC_FLAGS }, ..... }; Now you have S3C2410_SPECIFIC_FLAGS and S3C2440_SPECIFIC_FLAGS for your device driver to distinguish between the differences. Normally, the differences won't be much, and make sure you have good abstraction of those _SPECIFIC_FLAGS. > > Thank you, > Kyungmin Park >> >>> >>> _______________________________________________ >>> linux-arm-kernel mailing list >>> linux-arm-kernel at lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in >> the body of a message to majordomo at vger.kernel.org >> More majordomo info at ?http://vger.kernel.org/majordomo-info.html >> > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Samsung SoCs: preparation for single kernel 2010-06-23 1:54 ` Eric Miao @ 2010-06-23 2:01 ` Kyungmin Park -1 siblings, 0 replies; 26+ messages in thread From: Kyungmin Park @ 2010-06-23 2:01 UTC (permalink / raw) To: Eric Miao Cc: Ben Dooks, arm-linux, linux-samsung-soc, Russell King - ARM Linux, Marek Szyprowski On Wed, Jun 23, 2010 at 10:54 AM, Eric Miao <eric.y.miao@gmail.com> wrote: > On Wed, Jun 23, 2010 at 9:47 AM, Kyungmin Park <kmpark@infradead.org> wrote: >> On Wed, Jun 23, 2010 at 9:50 AM, Eric Miao <eric.y.miao@gmail.com> wrote: >>> On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park <kmpark@infradead.org> wrote: >>>> To Ben, >>>> >>>> I really need single kernel for s5pc110 (cortex A8) and s5pc210 >>>> (cortex A9) at least. >>>> Fortunately arm move to these approaches recently. but current Samsung >>>> SoCs not prepare these one. >>>> >>>> So I wonder do you have a plan or how to address these issues? >>>> How to assign the address at resources and use it at runtime? >>>> >>>> Personally I want to use cpu_is_*. but you reject it to use. >>>> Other way is that we can create the base address variables and assign >>>> it at init time. >>>> >>>> Please give your opinions. >>>> >>>> Thank you, >>>> Kyungmin Park >>>> >>>> e.g., cpu_is_* usage at OMAP tree >>>> >>>> static void omap_init_mcspi(void) >>>> { >>>> if (cpu_is_omap44xx()) >>>> omap4_mcspi_fixup(); >>>> >>>> platform_device_register(&omap2_mcspi1); >>>> platform_device_register(&omap2_mcspi2); >>>> >>>> if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) >>>> omap2_mcspi3_init(); >>>> >>>> if (cpu_is_omap343x() || cpu_is_omap44xx()) >>>> omap2_mcspi4_init(); >>>> } >>> >>> Just my two cents: cpu_is_*() can be used, but only when absolutely necessary. >>> The s3c does a CPU detection at startup, so I guess the usage of cpu_is_*() >>> can be even reduced. >> >> My concern is that most device resources use the S3C_* or S5P_* prefix >> and defined at each arch differently. >> >> E.G., mmc resource drivers use the S3C_PA_HSMMC0. but each mach has >> different base address. >> then how to handle this or make it possible? >> > > Now you have > > s5pv210_device_hsmmc0 > s5pc100_device_hsmmc0 > s3c64xx_device_hsmmc0 > .... > > each with a different base. Good, then wait Ben's opinions. > >> #define S5PV210_PA_HSMMC(x) (0xEB000000 + ((x) * 0x100000)) >> #define S3C_PA_HSMMC0 S5PV210_PA_HSMMC(0) >> #define S3C_PA_HSMMC1 S5PV210_PA_HSMMC(1) >> #define S3C_PA_HSMMC2 S5PV210_PA_HSMMC(2) >> >> #define S5PC100_PA_HSMMC(x) (0xED800000 + ((x) * 0x100000)) >> #define S3C_PA_HSMMC0 S5PC100_PA_HSMMC(0) >> #define S3C_PA_HSMMC1 S5PC100_PA_HSMMC(1) >> #define S3C_PA_HSMMC2 S5PC100_PA_HSMMC(2) >> >> #define S3C64XX_PA_HSMMC(x) (0x7C200000 + ((x) * 0x100000)) >> #define S3C64XX_PA_HSMMC0 S3C64XX_PA_HSMMC(0) >> #define S3C64XX_PA_HSMMC1 S3C64XX_PA_HSMMC(1) >> #define S3C64XX_PA_HSMMC2 S3C64XX_PA_HSMMC(2) >> #define S3C_PA_HSMMC0 S3C64XX_PA_HSMMC0 >> #define S3C_PA_HSMMC1 S3C64XX_PA_HSMMC1 >> #define S3C_PA_HSMMC2 S3C64XX_PA_HSMMC2 >> >>> >>> I'm not sure if the above case is a good reference or not. The omap_init_mcspi >>> is called from omap2_init_devices(), while the registration can actually be >>> made into the board init code when that device is used (some of the McSPIs are >>> not used, and it's not necessary to register them), and the differences be >>> handled in the driver. >> >> that's just example how to use cpu_is_* in others. the current schme >> in samsung SoCs. we passed the different platform name for each arch. >> e.g., s3c2410_i2c or s3c2440_i2c then i2c driver detect it and handle >> properly. of course it assume base address is set correctly as above. > > For the device driver, when you register two different i2c devices: > > struct platform_device s3c2410_device_i2c { > .name = "s3c2410-i2c", > ... > }; > > struct platform_device s3c2440_device_i2c { > .name = "s3c2440-i2c", > ... > }; > > And register the corresponding one in your board code (your board code > knows exactly which one to register, no? ) > > And then in your i2c driver, you declare: > > const static struct platform_device_id s3c_i2c_ids[] = { > { "s3c2410-i2c", S3C2410_SPECIFIC_FLAGS }, > { "s3c2440-i2c", S3C2440_SPECIFIC_FLAGS }, > ..... > }; > > Now you have S3C2410_SPECIFIC_FLAGS and S3C2440_SPECIFIC_FLAGS for your > device driver to distinguish between the differences. Normally, the > differences won't be much, and make sure you have good abstraction of > those _SPECIFIC_FLAGS. It's already done. >> >> Thank you, >> Kyungmin Park >>> >>>> >>>> _______________________________________________ >>>> 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-samsung-soc" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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] 26+ messages in thread
* Samsung SoCs: preparation for single kernel @ 2010-06-23 2:01 ` Kyungmin Park 0 siblings, 0 replies; 26+ messages in thread From: Kyungmin Park @ 2010-06-23 2:01 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jun 23, 2010 at 10:54 AM, Eric Miao <eric.y.miao@gmail.com> wrote: > On Wed, Jun 23, 2010 at 9:47 AM, Kyungmin Park <kmpark@infradead.org> wrote: >> On Wed, Jun 23, 2010 at 9:50 AM, Eric Miao <eric.y.miao@gmail.com> wrote: >>> On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park <kmpark@infradead.org> wrote: >>>> To Ben, >>>> >>>> I really need single kernel for s5pc110 (cortex A8) and s5pc210 >>>> (cortex A9) at least. >>>> Fortunately arm move to these approaches recently. but current Samsung >>>> SoCs not prepare these one. >>>> >>>> So I wonder do you have a plan or how to address these issues? >>>> How to assign the address at resources and use it at runtime? >>>> >>>> Personally I want to use cpu_is_*. but you reject it to use. >>>> Other way is that we can create the base address variables and assign >>>> it at init time. >>>> >>>> Please give your opinions. >>>> >>>> Thank you, >>>> Kyungmin Park >>>> >>>> e.g., cpu_is_* usage at OMAP tree >>>> >>>> static void omap_init_mcspi(void) >>>> { >>>> ? ? ? ?if (cpu_is_omap44xx()) >>>> ? ? ? ? ? ? ? ?omap4_mcspi_fixup(); >>>> >>>> ? ? ? ?platform_device_register(&omap2_mcspi1); >>>> ? ? ? ?platform_device_register(&omap2_mcspi2); >>>> >>>> ? ? ? ?if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) >>>> ? ? ? ? ? ? ? ?omap2_mcspi3_init(); >>>> >>>> ? ? ? ?if (cpu_is_omap343x() || cpu_is_omap44xx()) >>>> ? ? ? ? ? ? ? ?omap2_mcspi4_init(); >>>> } >>> >>> Just my two cents: cpu_is_*() can be used, but only when absolutely necessary. >>> The s3c does a CPU detection at startup, so I guess the usage of cpu_is_*() >>> can be even reduced. >> >> My concern is that most device resources use the S3C_* or S5P_* prefix >> and defined at each arch differently. >> >> E.G., mmc resource drivers use the S3C_PA_HSMMC0. but each mach has >> different base address. >> then how to handle this or make it possible? >> > > Now you have > > s5pv210_device_hsmmc0 > s5pc100_device_hsmmc0 > s3c64xx_device_hsmmc0 > .... > > each with a different base. Good, then wait Ben's opinions. > >> #define S5PV210_PA_HSMMC(x) ? ? (0xEB000000 + ((x) * 0x100000)) >> #define S3C_PA_HSMMC0 ? ? ? ? ? S5PV210_PA_HSMMC(0) >> #define S3C_PA_HSMMC1 ? ? ? ? ? S5PV210_PA_HSMMC(1) >> #define S3C_PA_HSMMC2 ? ? ? ? ? S5PV210_PA_HSMMC(2) >> >> #define S5PC100_PA_HSMMC(x) ? ? (0xED800000 + ((x) * 0x100000)) >> #define S3C_PA_HSMMC0 ? ? ? ? ? S5PC100_PA_HSMMC(0) >> #define S3C_PA_HSMMC1 ? ? ? ? ? S5PC100_PA_HSMMC(1) >> #define S3C_PA_HSMMC2 ? ? ? ? ? S5PC100_PA_HSMMC(2) >> >> #define S3C64XX_PA_HSMMC(x) ? ? (0x7C200000 + ((x) * 0x100000)) >> #define S3C64XX_PA_HSMMC0 ? ? ? S3C64XX_PA_HSMMC(0) >> #define S3C64XX_PA_HSMMC1 ? ? ? S3C64XX_PA_HSMMC(1) >> #define S3C64XX_PA_HSMMC2 ? ? ? S3C64XX_PA_HSMMC(2) >> #define S3C_PA_HSMMC0 ? ? ? ? ? S3C64XX_PA_HSMMC0 >> #define S3C_PA_HSMMC1 ? ? ? ? ? S3C64XX_PA_HSMMC1 >> #define S3C_PA_HSMMC2 ? ? ? ? ? S3C64XX_PA_HSMMC2 >> >>> >>> I'm not sure if the above case is a good reference or not. The omap_init_mcspi >>> is called from omap2_init_devices(), while the registration can actually be >>> made into the board init code when that device is used (some of the McSPIs are >>> not used, and it's not necessary to register them), and the differences be >>> handled in the driver. >> >> that's just example how to use cpu_is_* in others. the current schme >> in samsung SoCs. we passed the different platform name for each arch. >> e.g., s3c2410_i2c or s3c2440_i2c then i2c driver detect it and handle >> properly. of course it assume base address is set correctly as above. > > For the device driver, when you register two different i2c devices: > > struct platform_device s3c2410_device_i2c { > ? ? ? ?.name ? = "s3c2410-i2c", > ? ? ? ?... > }; > > struct platform_device s3c2440_device_i2c { > ? ? ? ?.name ? = "s3c2440-i2c", > ? ? ? ?... > }; > > And register the corresponding one in your board code (your board code > knows exactly which one to register, no? ) > > And then in your i2c driver, you declare: > > const static struct platform_device_id s3c_i2c_ids[] = { > ? ? ? ?{ "s3c2410-i2c", S3C2410_SPECIFIC_FLAGS }, > ? ? ? ?{ "s3c2440-i2c", S3C2440_SPECIFIC_FLAGS }, > ? ? ? ?..... > }; > > Now you have S3C2410_SPECIFIC_FLAGS and S3C2440_SPECIFIC_FLAGS for your > device driver to distinguish between the differences. Normally, the > differences won't be much, and make sure you have good abstraction of > those _SPECIFIC_FLAGS. It's already done. >> >> Thank you, >> Kyungmin Park >>> >>>> >>>> _______________________________________________ >>>> linux-arm-kernel mailing list >>>> linux-arm-kernel at lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in >>> the body of a message to majordomo at vger.kernel.org >>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html >>> >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at ?http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Samsung SoCs: preparation for single kernel 2010-06-23 1:54 ` Eric Miao @ 2010-06-23 6:25 ` Marek Szyprowski -1 siblings, 0 replies; 26+ messages in thread From: Marek Szyprowski @ 2010-06-23 6:25 UTC (permalink / raw) To: 'Eric Miao', 'Kyungmin Park' Cc: linux-samsung-soc, 'Russell King - ARM Linux', 'arm-linux', 'Ben Dooks' Hello, On Wednesday, June 23, 2010 3:55 AM Eric Miao wrote: > ... > >>> e.g., cpu_is_* usage at OMAP tree > >>> > >>> static void omap_init_mcspi(void) > >>> { > >>> if (cpu_is_omap44xx()) > >>> omap4_mcspi_fixup(); > >>> > >>> platform_device_register(&omap2_mcspi1); > >>> platform_device_register(&omap2_mcspi2); > >>> > >>> if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) > >>> omap2_mcspi3_init(); > >>> > >>> if (cpu_is_omap343x() || cpu_is_omap44xx()) > >>> omap2_mcspi4_init(); > >>> } > >> > >> Just my two cents: cpu_is_*() can be used, but only when absolutely > necessary. > >> The s3c does a CPU detection at startup, so I guess the usage of > cpu_is_*() > >> can be even reduced. > > > > My concern is that most device resources use the S3C_* or S5P_* prefix > > and defined at each arch differently. > > > > E.G., mmc resource drivers use the S3C_PA_HSMMC0. but each mach has > > different base address. > > then how to handle this or make it possible? > > > > Now you have > > s5pv210_device_hsmmc0 > s5pc100_device_hsmmc0 > s3c64xx_device_hsmmc0 > .... > > each with a different base. There is no need for such code duplication. Ben is working on a solution for a single kernel which supports multiple SoCs. Some of his work in progress can be found here: git://git.fluff.org/bjdooks/linux branch wip-samsung-dev and wip-samsung-dev2. > ... > >> I'm not sure if the above case is a good reference or not. The > omap_init_mcspi > >> is called from omap2_init_devices(), while the registration can actually > be > >> made into the board init code when that device is used (some of the > McSPIs are > >> not used, and it's not necessary to register them), and the differences > be > >> handled in the driver. > > > > that's just example how to use cpu_is_* in others. the current schme > > in samsung SoCs. we passed the different platform name for each arch. > > e.g., s3c2410_i2c or s3c2440_i2c then i2c driver detect it and handle > > properly. of course it assume base address is set correctly as above. > > For the device driver, when you register two different i2c devices: > > struct platform_device s3c2410_device_i2c { > .name = "s3c2410-i2c", > ... > }; > > struct platform_device s3c2440_device_i2c { > .name = "s3c2440-i2c", > ... > }; > > And register the corresponding one in your board code (your board code > knows exactly which one to register, no? ) Yes, this is a recommended way. Best regards -- Marek Szyprowski Samsung Poland R&D Center ^ permalink raw reply [flat|nested] 26+ messages in thread
* Samsung SoCs: preparation for single kernel @ 2010-06-23 6:25 ` Marek Szyprowski 0 siblings, 0 replies; 26+ messages in thread From: Marek Szyprowski @ 2010-06-23 6:25 UTC (permalink / raw) To: linux-arm-kernel Hello, On Wednesday, June 23, 2010 3:55 AM Eric Miao wrote: > ... > >>> e.g., cpu_is_* usage at OMAP tree > >>> > >>> static void omap_init_mcspi(void) > >>> { > >>> if (cpu_is_omap44xx()) > >>> omap4_mcspi_fixup(); > >>> > >>> platform_device_register(&omap2_mcspi1); > >>> platform_device_register(&omap2_mcspi2); > >>> > >>> if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) > >>> omap2_mcspi3_init(); > >>> > >>> if (cpu_is_omap343x() || cpu_is_omap44xx()) > >>> omap2_mcspi4_init(); > >>> } > >> > >> Just my two cents: cpu_is_*() can be used, but only when absolutely > necessary. > >> The s3c does a CPU detection at startup, so I guess the usage of > cpu_is_*() > >> can be even reduced. > > > > My concern is that most device resources use the S3C_* or S5P_* prefix > > and defined at each arch differently. > > > > E.G., mmc resource drivers use the S3C_PA_HSMMC0. but each mach has > > different base address. > > then how to handle this or make it possible? > > > > Now you have > > s5pv210_device_hsmmc0 > s5pc100_device_hsmmc0 > s3c64xx_device_hsmmc0 > .... > > each with a different base. There is no need for such code duplication. Ben is working on a solution for a single kernel which supports multiple SoCs. Some of his work in progress can be found here: git://git.fluff.org/bjdooks/linux branch wip-samsung-dev and wip-samsung-dev2. > ... > >> I'm not sure if the above case is a good reference or not. The > omap_init_mcspi > >> is called from omap2_init_devices(), while the registration can actually > be > >> made into the board init code when that device is used (some of the > McSPIs are > >> not used, and it's not necessary to register them), and the differences > be > >> handled in the driver. > > > > that's just example how to use cpu_is_* in others. the current schme > > in samsung SoCs. we passed the different platform name for each arch. > > e.g., s3c2410_i2c or s3c2440_i2c then i2c driver detect it and handle > > properly. of course it assume base address is set correctly as above. > > For the device driver, when you register two different i2c devices: > > struct platform_device s3c2410_device_i2c { > .name = "s3c2410-i2c", > ... > }; > > struct platform_device s3c2440_device_i2c { > .name = "s3c2440-i2c", > ... > }; > > And register the corresponding one in your board code (your board code > knows exactly which one to register, no? ) Yes, this is a recommended way. Best regards -- Marek Szyprowski Samsung Poland R&D Center ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Samsung SoCs: preparation for single kernel 2010-06-23 6:25 ` Marek Szyprowski @ 2010-06-23 8:01 ` Eric Miao -1 siblings, 0 replies; 26+ messages in thread From: Eric Miao @ 2010-06-23 8:01 UTC (permalink / raw) To: Marek Szyprowski Cc: Kyungmin Park, linux-samsung-soc, Russell King - ARM Linux, arm-linux, Ben Dooks On Wed, Jun 23, 2010 at 2:25 PM, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > Hello, > > On Wednesday, June 23, 2010 3:55 AM Eric Miao wrote: > >> ... > >> >>> e.g., cpu_is_* usage at OMAP tree >> >>> >> >>> static void omap_init_mcspi(void) >> >>> { >> >>> if (cpu_is_omap44xx()) >> >>> omap4_mcspi_fixup(); >> >>> >> >>> platform_device_register(&omap2_mcspi1); >> >>> platform_device_register(&omap2_mcspi2); >> >>> >> >>> if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) >> >>> omap2_mcspi3_init(); >> >>> >> >>> if (cpu_is_omap343x() || cpu_is_omap44xx()) >> >>> omap2_mcspi4_init(); >> >>> } >> >> >> >> Just my two cents: cpu_is_*() can be used, but only when absolutely >> necessary. >> >> The s3c does a CPU detection at startup, so I guess the usage of >> cpu_is_*() >> >> can be even reduced. >> > >> > My concern is that most device resources use the S3C_* or S5P_* prefix >> > and defined at each arch differently. >> > >> > E.G., mmc resource drivers use the S3C_PA_HSMMC0. but each mach has >> > different base address. >> > then how to handle this or make it possible? >> > >> >> Now you have >> >> s5pv210_device_hsmmc0 >> s5pc100_device_hsmmc0 >> s3c64xx_device_hsmmc0 >> .... >> >> each with a different base. > > There is no need for such code duplication. However, I believe this is the right way to go. A certain level of duplication is the price to pay for a generic and clean solution. When a peripheral controller or IP is moved from one SoC to the next generation, there are several things could have been changed: 1. new base address and IRQ number 2. fixes and enhancements to the original IP 1. will result in a different 'struct resource', and 2. will result in a different 'struct platform_device' with a different name, so the driver can match the platform_device_id table as you agreed I'm right on that recommendation. They are actually _two_ different devices. > Ben is working on a solution for > a single kernel which supports multiple SoCs. Some of his work in progress can > be found here: git://git.fluff.org/bjdooks/linux branch wip-samsung-dev and > wip-samsung-dev2. Could you describe it a bit here and bring it on table for discussion? PS: My feeling of commenting several of the samsung patches so far turns out to be quite frustrated, or I'm just too sensitive. NOTE neither am I NAKing Samsung patches, nor am I interested to be involved, I'm just givin my suggestions. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Samsung SoCs: preparation for single kernel @ 2010-06-23 8:01 ` Eric Miao 0 siblings, 0 replies; 26+ messages in thread From: Eric Miao @ 2010-06-23 8:01 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jun 23, 2010 at 2:25 PM, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > Hello, > > On Wednesday, June 23, 2010 3:55 AM Eric Miao wrote: > >> ... > >> >>> e.g., cpu_is_* usage at OMAP tree >> >>> >> >>> static void omap_init_mcspi(void) >> >>> { >> >>> ? ? ? ?if (cpu_is_omap44xx()) >> >>> ? ? ? ? ? ? ? ?omap4_mcspi_fixup(); >> >>> >> >>> ? ? ? ?platform_device_register(&omap2_mcspi1); >> >>> ? ? ? ?platform_device_register(&omap2_mcspi2); >> >>> >> >>> ? ? ? ?if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) >> >>> ? ? ? ? ? ? ? ?omap2_mcspi3_init(); >> >>> >> >>> ? ? ? ?if (cpu_is_omap343x() || cpu_is_omap44xx()) >> >>> ? ? ? ? ? ? ? ?omap2_mcspi4_init(); >> >>> } >> >> >> >> Just my two cents: cpu_is_*() can be used, but only when absolutely >> necessary. >> >> The s3c does a CPU detection at startup, so I guess the usage of >> cpu_is_*() >> >> can be even reduced. >> > >> > My concern is that most device resources use the S3C_* or S5P_* prefix >> > and defined at each arch differently. >> > >> > E.G., mmc resource drivers use the S3C_PA_HSMMC0. but each mach has >> > different base address. >> > then how to handle this or make it possible? >> > >> >> Now you have >> >> s5pv210_device_hsmmc0 >> s5pc100_device_hsmmc0 >> s3c64xx_device_hsmmc0 >> .... >> >> each with a different base. > > There is no need for such code duplication. However, I believe this is the right way to go. A certain level of duplication is the price to pay for a generic and clean solution. When a peripheral controller or IP is moved from one SoC to the next generation, there are several things could have been changed: 1. new base address and IRQ number 2. fixes and enhancements to the original IP 1. will result in a different 'struct resource', and 2. will result in a different 'struct platform_device' with a different name, so the driver can match the platform_device_id table as you agreed I'm right on that recommendation. They are actually _two_ different devices. > Ben is working on a solution for > a single kernel which supports multiple SoCs. Some of his work in progress can > be found here: git://git.fluff.org/bjdooks/linux branch wip-samsung-dev and > wip-samsung-dev2. Could you describe it a bit here and bring it on table for discussion? PS: My feeling of commenting several of the samsung patches so far turns out to be quite frustrated, or I'm just too sensitive. NOTE neither am I NAKing Samsung patches, nor am I interested to be involved, I'm just givin my suggestions. ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Samsung SoCs: preparation for single kernel 2010-06-23 8:01 ` Eric Miao @ 2010-06-23 9:20 ` Marek Szyprowski -1 siblings, 0 replies; 26+ messages in thread From: Marek Szyprowski @ 2010-06-23 9:20 UTC (permalink / raw) To: 'Eric Miao' Cc: 'Kyungmin Park', linux-samsung-soc, 'Russell King - ARM Linux', 'arm-linux', 'Ben Dooks' Hello, On Wednesday, June 23, 2010 10:02 AM Eric Miao wrote: > >> Now you have > >> > >> s5pv210_device_hsmmc0 > >> s5pc100_device_hsmmc0 > >> s3c64xx_device_hsmmc0 > >> .... > >> > >> each with a different base. > > > > There is no need for such code duplication. > > However, I believe this is the right way to go. A certain level of > duplication is the price to pay for a generic and clean solution. > > When a peripheral controller or IP is moved from one SoC to the > next generation, there are several things could have been changed: > > 1. new base address and IRQ number > 2. fixes and enhancements to the original IP > > 1. will result in a different 'struct resource', and 2. will result in a > different 'struct platform_device' with a different name, so the driver > can match the platform_device_id table as you agreed I'm right on > that recommendation. > > They are actually _two_ different devices. Right, they are separate entities, but would be really good if a similar git brcode could be merged together. > > Ben is working on a solution for > > a single kernel which supports multiple SoCs. Some of his work in > progress can > > be found here: git://git.fluff.org/bjdooks/linux branch wip-samsung-dev > and > > wip-samsung-dev2. > > Could you describe it a bit here and bring it on table for discussion? The idea behind his patches is to provide a table for each SoC with short description of all available devices and generate platform_device entries dynamically from that table. Here is a short code example: struct s3c_pdev_table s3c6xxx_dev_table[] __initdata = { { .type = SAMSUNG_DEVICE_UART, .name = "s3c6400-uart", .index = 0, .base = S3C_PA_UART0, .irq = IRQ_S3CUART_RX0, .template = &template_uart_s3c64xx, }, { .type = SAMSUNG_DEVICE_UART, .name = "s3c6400-uart", .index = 1, .base = S3C_PA_UART1, .irq = IRQ_S3CUART_RX1, .template = &template_uart_s3c64xx, }, { .type = SAMSUNG_DEVICE_UART, .name = "s3c6400-uart", .index = 2, .base = S3C_PA_UART2, .irq = IRQ_S3CUART_RX2, .template = &template_uart_s3c64xx, }, { .type = SAMSUNG_DEVICE_UART, .name = "s3c6400-uart", .index = 3, .base = S3C_PA_UART3, .irq = IRQ_S3CUART_RX3, .template = &template_uart_s3c64xx, }, { .type = SAMSUNG_DEVICE_WATCHDOG, .name = "s3c2410-wdt", .index = -1, .base = S3C64XX_PA_WATCHDOG, .irq = IRQ_WDT, }, { .type = SAMSUNG_DEVICE_SDHCI, .name = "s3c-sdhci", .index = 0, .base = S3C64XX_PA_HSMMC0 , .irq = IRQ_HSMMC0, .dma = &samsung_std_dma_mask, }, { .type = SAMSUNG_DEVICE_SDHCI, .name = "s3c-sdhci", .index = 1, .base = S3C64XX_PA_HSMMC1, .irq = IRQ_HSMMC1, .dma = &samsung_std_dma_mask, }, { .type = SAMSUNG_DEVICE_SDHCI, .name = "s3c-sdhci", .index = 2, .base = S3C64XX_PA_HSMMC2, .irq = IRQ_HSMMC1, .dma = &samsung_std_dma_mask, }, { .type = SAMSUNG_DEVICE_OHCI, .name = "s3c2410-ohci", .index = -1, .base = S3C64XX_PA_USBHOST, .irq = IRQ_USBH, .dma = &samsung_std_dma_mask, }, { .type = SAMSUNG_DEVICE_NAND, .name = "s3c6400-nand", .index = -1, .base = 0x4E000000, .irq = IRQ_NFC, }, { .type = SAMSUNG_DEVICE_I2C, .name = "s3c2440-i2c", .index = 0, .base = S3C64XX_PA_IIC0, .irq = IRQ_IIC, }, { ... This solution is imho really clean an easy to understand. It is also easy to check which SoC has which peripherals defined and how. I hope Ben will be able to finish it soon and all Samsung platforms can be converted for it. Then creating a single kernel for more than one SoC should be possible with only a few additional changes. > PS: My feeling of commenting several of the samsung patches so far turns > out to be quite frustrated, or I'm just too sensitive. NOTE neither am I > NAKing Samsung patches, nor am I interested to be involved, I'm just givin > my suggestions. I'm sorry if I offended You. I just wanted to show that the solution has been already found. Best regards -- Marek Szyprowski Samsung Poland R&D Center ^ permalink raw reply [flat|nested] 26+ messages in thread
* Samsung SoCs: preparation for single kernel @ 2010-06-23 9:20 ` Marek Szyprowski 0 siblings, 0 replies; 26+ messages in thread From: Marek Szyprowski @ 2010-06-23 9:20 UTC (permalink / raw) To: linux-arm-kernel Hello, On Wednesday, June 23, 2010 10:02 AM Eric Miao wrote: > >> Now you have > >> > >> s5pv210_device_hsmmc0 > >> s5pc100_device_hsmmc0 > >> s3c64xx_device_hsmmc0 > >> .... > >> > >> each with a different base. > > > > There is no need for such code duplication. > > However, I believe this is the right way to go. A certain level of > duplication is the price to pay for a generic and clean solution. > > When a peripheral controller or IP is moved from one SoC to the > next generation, there are several things could have been changed: > > 1. new base address and IRQ number > 2. fixes and enhancements to the original IP > > 1. will result in a different 'struct resource', and 2. will result in a > different 'struct platform_device' with a different name, so the driver > can match the platform_device_id table as you agreed I'm right on > that recommendation. > > They are actually _two_ different devices. Right, they are separate entities, but would be really good if a similar git brcode could be merged together. > > Ben is working on a solution for > > a single kernel which supports multiple SoCs. Some of his work in > progress can > > be found here: git://git.fluff.org/bjdooks/linux branch wip-samsung-dev > and > > wip-samsung-dev2. > > Could you describe it a bit here and bring it on table for discussion? The idea behind his patches is to provide a table for each SoC with short description of all available devices and generate platform_device entries dynamically from that table. Here is a short code example: struct s3c_pdev_table s3c6xxx_dev_table[] __initdata = { { .type = SAMSUNG_DEVICE_UART, .name = "s3c6400-uart", .index = 0, .base = S3C_PA_UART0, .irq = IRQ_S3CUART_RX0, .template = &template_uart_s3c64xx, }, { .type = SAMSUNG_DEVICE_UART, .name = "s3c6400-uart", .index = 1, .base = S3C_PA_UART1, .irq = IRQ_S3CUART_RX1, .template = &template_uart_s3c64xx, }, { .type = SAMSUNG_DEVICE_UART, .name = "s3c6400-uart", .index = 2, .base = S3C_PA_UART2, .irq = IRQ_S3CUART_RX2, .template = &template_uart_s3c64xx, }, { .type = SAMSUNG_DEVICE_UART, .name = "s3c6400-uart", .index = 3, .base = S3C_PA_UART3, .irq = IRQ_S3CUART_RX3, .template = &template_uart_s3c64xx, }, { .type = SAMSUNG_DEVICE_WATCHDOG, .name = "s3c2410-wdt", .index = -1, .base = S3C64XX_PA_WATCHDOG, .irq = IRQ_WDT, }, { .type = SAMSUNG_DEVICE_SDHCI, .name = "s3c-sdhci", .index = 0, .base = S3C64XX_PA_HSMMC0 , .irq = IRQ_HSMMC0, .dma = &samsung_std_dma_mask, }, { .type = SAMSUNG_DEVICE_SDHCI, .name = "s3c-sdhci", .index = 1, .base = S3C64XX_PA_HSMMC1, .irq = IRQ_HSMMC1, .dma = &samsung_std_dma_mask, }, { .type = SAMSUNG_DEVICE_SDHCI, .name = "s3c-sdhci", .index = 2, .base = S3C64XX_PA_HSMMC2, .irq = IRQ_HSMMC1, .dma = &samsung_std_dma_mask, }, { .type = SAMSUNG_DEVICE_OHCI, .name = "s3c2410-ohci", .index = -1, .base = S3C64XX_PA_USBHOST, .irq = IRQ_USBH, .dma = &samsung_std_dma_mask, }, { .type = SAMSUNG_DEVICE_NAND, .name = "s3c6400-nand", .index = -1, .base = 0x4E000000, .irq = IRQ_NFC, }, { .type = SAMSUNG_DEVICE_I2C, .name = "s3c2440-i2c", .index = 0, .base = S3C64XX_PA_IIC0, .irq = IRQ_IIC, }, { ... This solution is imho really clean an easy to understand. It is also easy to check which SoC has which peripherals defined and how. I hope Ben will be able to finish it soon and all Samsung platforms can be converted for it. Then creating a single kernel for more than one SoC should be possible with only a few additional changes. > PS: My feeling of commenting several of the samsung patches so far turns > out to be quite frustrated, or I'm just too sensitive. NOTE neither am I > NAKing Samsung patches, nor am I interested to be involved, I'm just givin > my suggestions. I'm sorry if I offended You. I just wanted to show that the solution has been already found. Best regards -- Marek Szyprowski Samsung Poland R&D Center ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Samsung SoCs: preparation for single kernel 2010-06-23 9:20 ` Marek Szyprowski @ 2010-06-23 10:24 ` Eric Miao -1 siblings, 0 replies; 26+ messages in thread From: Eric Miao @ 2010-06-23 10:24 UTC (permalink / raw) To: Marek Szyprowski Cc: Kyungmin Park, linux-samsung-soc@vger.kernel.org, Russell King - ARM Linux, arm-linux, Ben Dooks On Wednesday, June 23, 2010, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > Hello, > > On Wednesday, June 23, 2010 10:02 AM Eric Miao wrote: > >> >> Now you have >> >> >> >> s5pv210_device_hsmmc0 >> >> s5pc100_device_hsmmc0 >> >> s3c64xx_device_hsmmc0 >> >> .... >> >> >> >> each with a different base. >> > >> > There is no need for such code duplication. >> >> However, I believe this is the right way to go. A certain level of >> duplication is the price to pay for a generic and clean solution. >> >> When a peripheral controller or IP is moved from one SoC to the >> next generation, there are several things could have been changed: >> >> 1. new base address and IRQ number >> 2. fixes and enhancements to the original IP >> >> 1. will result in a different 'struct resource', and 2. will result in a >> different 'struct platform_device' with a different name, so the driver >> can match the platform_device_id table as you agreed I'm right on >> that recommendation. >> >> They are actually _two_ different devices. > > Right, they are separate entities, but would be really good if a similar > git brcode could be merged together. > >> > Ben is working on a solution for >> > a single kernel which supports multiple SoCs. Some of his work in >> progress can >> > be found here: git://git.fluff.org/bjdooks/linux branch wip-samsung-dev >> and >> > wip-samsung-dev2. >> >> Could you describe it a bit here and bring it on table for discussion? > > The idea behind his patches is to provide a table for each SoC with short > description of all available devices and generate platform_device entries > dynamically from that table. > > Here is a short code example: > > struct s3c_pdev_table s3c6xxx_dev_table[] __initdata = { > { > .type = SAMSUNG_DEVICE_UART, > .name = "s3c6400-uart", > .index = 0, > .base = S3C_PA_UART0, > .irq = IRQ_S3CUART_RX0, > .template = &template_uart_s3c64xx, > }, { > .type = SAMSUNG_DEVICE_UART, > .name = "s3c6400-uart", > .index = 1, > .base = S3C_PA_UART1, > .irq = IRQ_S3CUART_RX1, > .template = &template_uart_s3c64xx, > }, { > .type = SAMSUNG_DEVICE_UART, > .name = "s3c6400-uart", > .index = 2, > .base = S3C_PA_UART2, > .irq = IRQ_S3CUART_RX2, > .template = &template_uart_s3c64xx, > }, { > .type = SAMSUNG_DEVICE_UART, > .name = "s3c6400-uart", > .index = 3, > .base = S3C_PA_UART3, > .irq = IRQ_S3CUART_RX3, > .template = &template_uart_s3c64xx, > }, { > .type = SAMSUNG_DEVICE_WATCHDOG, > .name = "s3c2410-wdt", > .index = -1, > .base = S3C64XX_PA_WATCHDOG, > .irq = IRQ_WDT, > }, { > .type = SAMSUNG_DEVICE_SDHCI, > .name = "s3c-sdhci", > .index = 0, > .base = S3C64XX_PA_HSMMC0 , > .irq = IRQ_HSMMC0, > .dma = &samsung_std_dma_mask, > }, { > .type = SAMSUNG_DEVICE_SDHCI, > .name = "s3c-sdhci", > .index = 1, > .base = S3C64XX_PA_HSMMC1, > .irq = IRQ_HSMMC1, > .dma = &samsung_std_dma_mask, > }, { > .type = SAMSUNG_DEVICE_SDHCI, > .name = "s3c-sdhci", > .index = 2, > .base = S3C64XX_PA_HSMMC2, > .irq = IRQ_HSMMC1, > .dma = &samsung_std_dma_mask, > }, { > .type = SAMSUNG_DEVICE_OHCI, > .name = "s3c2410-ohci", > .index = -1, > .base = S3C64XX_PA_USBHOST, > .irq = IRQ_USBH, > .dma = &samsung_std_dma_mask, > }, { > .type = SAMSUNG_DEVICE_NAND, > .name = "s3c6400-nand", > .index = -1, > .base = 0x4E000000, > .irq = IRQ_NFC, > }, { > .type = SAMSUNG_DEVICE_I2C, > .name = "s3c2440-i2c", > .index = 0, > .base = S3C64XX_PA_IIC0, > .irq = IRQ_IIC, > }, { > ... > > This solution is imho really clean an easy to understand. It is also > easy to check which SoC has which peripherals defined and how. > Yep, this was already used in arch/arm/mach-mmp, and I wrote that. It's actually an improved version of multiple platform_device. > I hope Ben will be able to finish it soon and all Samsung platforms can > be converted for it. Then creating a single kernel for more than one SoC > should be possible with only a few additional changes. > >> PS: My feeling of commenting several of the samsung patches so far turns >> out to be quite frustrated, or I'm just too sensitive. NOTE neither am I >> NAKing Samsung patches, nor am I interested to be involved, I'm just givin >> my suggestions. > > I'm sorry if I offended You. I just wanted to show that the solution has > been already found. > > Best regards > -- > Marek Szyprowski > Samsung Poland R&D Center > > > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Samsung SoCs: preparation for single kernel @ 2010-06-23 10:24 ` Eric Miao 0 siblings, 0 replies; 26+ messages in thread From: Eric Miao @ 2010-06-23 10:24 UTC (permalink / raw) To: linux-arm-kernel On Wednesday, June 23, 2010, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > Hello, > > On Wednesday, June 23, 2010 10:02 AM Eric Miao wrote: > >> >> Now you have >> >> >> >> s5pv210_device_hsmmc0 >> >> s5pc100_device_hsmmc0 >> >> s3c64xx_device_hsmmc0 >> >> .... >> >> >> >> each with a different base. >> > >> > There is no need for such code duplication. >> >> However, I believe this is the right way to go. A certain level of >> duplication is the price to pay for a generic and clean solution. >> >> When a peripheral controller or IP is moved from one SoC to the >> next generation, there are several things could have been changed: >> >> 1. new base address and IRQ number >> 2. fixes and enhancements to the original IP >> >> 1. will result in a different 'struct resource', and 2. will result in a >> different 'struct platform_device' with a different name, so the driver >> can match the platform_device_id table as you agreed I'm right on >> that recommendation. >> >> They are actually _two_ different devices. > > Right, they are separate entities, but would be really good if a similar > git brcode could be merged together. > >> > Ben is working on a solution for >> > a single kernel which supports multiple SoCs. Some of his work in >> progress can >> > be found here: git://git.fluff.org/bjdooks/linux branch wip-samsung-dev >> and >> > wip-samsung-dev2. >> >> Could you describe it a bit here and bring it on table for discussion? > > The idea behind his patches is to provide a table for each SoC with short > description of all available devices and generate platform_device entries > dynamically from that table. > > Here is a short code example: > > struct s3c_pdev_table s3c6xxx_dev_table[] __initdata = { > ? ? ? ?{ > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_UART, > ? ? ? ? ? ? ? ?.name ? = "s3c6400-uart", > ? ? ? ? ? ? ? ?.index ?= 0, > ? ? ? ? ? ? ? ?.base ? = S3C_PA_UART0, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_S3CUART_RX0, > ? ? ? ? ? ? ? ?.template = &template_uart_s3c64xx, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_UART, > ? ? ? ? ? ? ? ?.name ? = "s3c6400-uart", > ? ? ? ? ? ? ? ?.index ?= 1, > ? ? ? ? ? ? ? ?.base ? = S3C_PA_UART1, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_S3CUART_RX1, > ? ? ? ? ? ? ? ?.template = &template_uart_s3c64xx, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_UART, > ? ? ? ? ? ? ? ?.name ? = "s3c6400-uart", > ? ? ? ? ? ? ? ?.index ?= 2, > ? ? ? ? ? ? ? ?.base ? = S3C_PA_UART2, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_S3CUART_RX2, > ? ? ? ? ? ? ? ?.template = &template_uart_s3c64xx, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_UART, > ? ? ? ? ? ? ? ?.name ? = "s3c6400-uart", > ? ? ? ? ? ? ? ?.index ?= 3, > ? ? ? ? ? ? ? ?.base ? = S3C_PA_UART3, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_S3CUART_RX3, > ? ? ? ? ? ? ? ?.template = &template_uart_s3c64xx, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_WATCHDOG, > ? ? ? ? ? ? ? ?.name ? = "s3c2410-wdt", > ? ? ? ? ? ? ? ?.index ?= -1, > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_WATCHDOG, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_WDT, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_SDHCI, > ? ? ? ? ? ? ? ?.name ? = "s3c-sdhci", > ? ? ? ? ? ? ? ?.index ?= 0, > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_HSMMC0 , > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_HSMMC0, > ? ? ? ? ? ? ? ?.dma ? ?= &samsung_std_dma_mask, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_SDHCI, > ? ? ? ? ? ? ? ?.name ? = "s3c-sdhci", > ? ? ? ? ? ? ? ?.index ?= 1, > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_HSMMC1, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_HSMMC1, > ? ? ? ? ? ? ? ?.dma ? ?= &samsung_std_dma_mask, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_SDHCI, > ? ? ? ? ? ? ? ?.name ? = "s3c-sdhci", > ? ? ? ? ? ? ? ?.index ?= 2, > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_HSMMC2, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_HSMMC1, > ? ? ? ? ? ? ? ?.dma ? ?= &samsung_std_dma_mask, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_OHCI, > ? ? ? ? ? ? ? ?.name ? = "s3c2410-ohci", > ? ? ? ? ? ? ? ?.index ?= -1, > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_USBHOST, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_USBH, > ? ? ? ? ? ? ? ?.dma ? ?= &samsung_std_dma_mask, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_NAND, > ? ? ? ? ? ? ? ?.name ? = "s3c6400-nand", > ? ? ? ? ? ? ? ?.index ?= -1, > ? ? ? ? ? ? ? ?.base ? = 0x4E000000, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_NFC, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_I2C, > ? ? ? ? ? ? ? ?.name ? = "s3c2440-i2c", > ? ? ? ? ? ? ? ?.index ?= 0, > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_IIC0, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_IIC, > ? ? ? ?}, { > ... > > This solution is imho really clean an easy to understand. It is also > easy to check which SoC has which peripherals defined and how. > Yep, this was already used in arch/arm/mach-mmp, and I wrote that. It's actually an improved version of multiple platform_device. > I hope Ben will be able to finish it soon and all Samsung platforms can > be converted for it. Then creating a single kernel for more than one SoC > should be possible with only a few additional changes. > >> PS: My feeling of commenting several of the samsung patches so far turns >> out to be quite frustrated, or I'm just too sensitive. NOTE neither am I >> NAKing Samsung patches, nor am I interested to be involved, I'm just givin >> my suggestions. > > I'm sorry if I offended You. I just wanted to show that the solution has > been already found. > > Best regards > -- > Marek Szyprowski > Samsung Poland R&D Center > > > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Samsung SoCs: preparation for single kernel 2010-06-23 9:20 ` Marek Szyprowski @ 2010-06-24 2:08 ` Kyungmin Park -1 siblings, 0 replies; 26+ messages in thread From: Kyungmin Park @ 2010-06-24 2:08 UTC (permalink / raw) To: Marek Szyprowski Cc: Eric Miao, linux-samsung-soc, Russell King - ARM Linux, arm-linux, Ben Dooks On Wed, Jun 23, 2010 at 6:20 PM, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > Hello, > > On Wednesday, June 23, 2010 10:02 AM Eric Miao wrote: > >> >> Now you have >> >> >> >> s5pv210_device_hsmmc0 >> >> s5pc100_device_hsmmc0 >> >> s3c64xx_device_hsmmc0 >> >> .... >> >> >> >> each with a different base. >> > >> > There is no need for such code duplication. >> >> However, I believe this is the right way to go. A certain level of >> duplication is the price to pay for a generic and clean solution. >> >> When a peripheral controller or IP is moved from one SoC to the >> next generation, there are several things could have been changed: >> >> 1. new base address and IRQ number >> 2. fixes and enhancements to the original IP >> >> 1. will result in a different 'struct resource', and 2. will result in a >> different 'struct platform_device' with a different name, so the driver >> can match the platform_device_id table as you agreed I'm right on >> that recommendation. >> >> They are actually _two_ different devices. > > Right, they are separate entities, but would be really good if a similar > git brcode could be merged together. > >> > Ben is working on a solution for >> > a single kernel which supports multiple SoCs. Some of his work in >> progress can >> > be found here: git://git.fluff.org/bjdooks/linux branch wip-samsung-dev >> and >> > wip-samsung-dev2. >> >> Could you describe it a bit here and bring it on table for discussion? > > The idea behind his patches is to provide a table for each SoC with short > description of all available devices and generate platform_device entries > dynamically from that table. > > Here is a short code example: > > struct s3c_pdev_table s3c6xxx_dev_table[] __initdata = { > { > .type = SAMSUNG_DEVICE_UART, > .name = "s3c6400-uart", > .index = 0, > .base = S3C_PA_UART0, > .irq = IRQ_S3CUART_RX0, > .template = &template_uart_s3c64xx, > }, { > .type = SAMSUNG_DEVICE_UART, > .name = "s3c6400-uart", > .index = 1, > .base = S3C_PA_UART1, > .irq = IRQ_S3CUART_RX1, > .template = &template_uart_s3c64xx, > }, { > .type = SAMSUNG_DEVICE_UART, > .name = "s3c6400-uart", > .index = 2, > .base = S3C_PA_UART2, > .irq = IRQ_S3CUART_RX2, > .template = &template_uart_s3c64xx, > }, { > .type = SAMSUNG_DEVICE_UART, > .name = "s3c6400-uart", > .index = 3, > .base = S3C_PA_UART3, > .irq = IRQ_S3CUART_RX3, > .template = &template_uart_s3c64xx, > }, { > .type = SAMSUNG_DEVICE_WATCHDOG, > .name = "s3c2410-wdt", > .index = -1, > .base = S3C64XX_PA_WATCHDOG, > .irq = IRQ_WDT, > }, { > .type = SAMSUNG_DEVICE_SDHCI, > .name = "s3c-sdhci", > .index = 0, > .base = S3C64XX_PA_HSMMC0 , > .irq = IRQ_HSMMC0, > .dma = &samsung_std_dma_mask, > }, { > .type = SAMSUNG_DEVICE_SDHCI, > .name = "s3c-sdhci", > .index = 1, > .base = S3C64XX_PA_HSMMC1, > .irq = IRQ_HSMMC1, > .dma = &samsung_std_dma_mask, > }, { > .type = SAMSUNG_DEVICE_SDHCI, > .name = "s3c-sdhci", > .index = 2, > .base = S3C64XX_PA_HSMMC2, > .irq = IRQ_HSMMC1, > .dma = &samsung_std_dma_mask, > }, { > .type = SAMSUNG_DEVICE_OHCI, > .name = "s3c2410-ohci", > .index = -1, > .base = S3C64XX_PA_USBHOST, > .irq = IRQ_USBH, > .dma = &samsung_std_dma_mask, > }, { > .type = SAMSUNG_DEVICE_NAND, > .name = "s3c6400-nand", > .index = -1, > .base = 0x4E000000, > .irq = IRQ_NFC, > }, { > .type = SAMSUNG_DEVICE_I2C, > .name = "s3c2440-i2c", > .index = 0, > .base = S3C64XX_PA_IIC0, > .irq = IRQ_IIC, > }, { > ... > > This solution is imho really clean an easy to understand. It is also > easy to check which SoC has which peripherals defined and how. Question. recently it's changed to use MMC0, MMC2, MMC3, then how to define it? More basically, where these info are defined for chip or board? If chip, the how to handle several variants? Thank you, Kyungmin Park > > I hope Ben will be able to finish it soon and all Samsung platforms can > be converted for it. Then creating a single kernel for more than one SoC > should be possible with only a few additional changes. > >> PS: My feeling of commenting several of the samsung patches so far turns >> out to be quite frustrated, or I'm just too sensitive. NOTE neither am I >> NAKing Samsung patches, nor am I interested to be involved, I'm just givin >> my suggestions. > > I'm sorry if I offended You. I just wanted to show that the solution has > been already found. > > Best regards > -- > Marek Szyprowski > Samsung Poland R&D Center > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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] 26+ messages in thread
* Samsung SoCs: preparation for single kernel @ 2010-06-24 2:08 ` Kyungmin Park 0 siblings, 0 replies; 26+ messages in thread From: Kyungmin Park @ 2010-06-24 2:08 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jun 23, 2010 at 6:20 PM, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > Hello, > > On Wednesday, June 23, 2010 10:02 AM Eric Miao wrote: > >> >> Now you have >> >> >> >> s5pv210_device_hsmmc0 >> >> s5pc100_device_hsmmc0 >> >> s3c64xx_device_hsmmc0 >> >> .... >> >> >> >> each with a different base. >> > >> > There is no need for such code duplication. >> >> However, I believe this is the right way to go. A certain level of >> duplication is the price to pay for a generic and clean solution. >> >> When a peripheral controller or IP is moved from one SoC to the >> next generation, there are several things could have been changed: >> >> 1. new base address and IRQ number >> 2. fixes and enhancements to the original IP >> >> 1. will result in a different 'struct resource', and 2. will result in a >> different 'struct platform_device' with a different name, so the driver >> can match the platform_device_id table as you agreed I'm right on >> that recommendation. >> >> They are actually _two_ different devices. > > Right, they are separate entities, but would be really good if a similar > git brcode could be merged together. > >> > Ben is working on a solution for >> > a single kernel which supports multiple SoCs. Some of his work in >> progress can >> > be found here: git://git.fluff.org/bjdooks/linux branch wip-samsung-dev >> and >> > wip-samsung-dev2. >> >> Could you describe it a bit here and bring it on table for discussion? > > The idea behind his patches is to provide a table for each SoC with short > description of all available devices and generate platform_device entries > dynamically from that table. > > Here is a short code example: > > struct s3c_pdev_table s3c6xxx_dev_table[] __initdata = { > ? ? ? ?{ > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_UART, > ? ? ? ? ? ? ? ?.name ? = "s3c6400-uart", > ? ? ? ? ? ? ? ?.index ?= 0, > ? ? ? ? ? ? ? ?.base ? = S3C_PA_UART0, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_S3CUART_RX0, > ? ? ? ? ? ? ? ?.template = &template_uart_s3c64xx, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_UART, > ? ? ? ? ? ? ? ?.name ? = "s3c6400-uart", > ? ? ? ? ? ? ? ?.index ?= 1, > ? ? ? ? ? ? ? ?.base ? = S3C_PA_UART1, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_S3CUART_RX1, > ? ? ? ? ? ? ? ?.template = &template_uart_s3c64xx, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_UART, > ? ? ? ? ? ? ? ?.name ? = "s3c6400-uart", > ? ? ? ? ? ? ? ?.index ?= 2, > ? ? ? ? ? ? ? ?.base ? = S3C_PA_UART2, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_S3CUART_RX2, > ? ? ? ? ? ? ? ?.template = &template_uart_s3c64xx, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_UART, > ? ? ? ? ? ? ? ?.name ? = "s3c6400-uart", > ? ? ? ? ? ? ? ?.index ?= 3, > ? ? ? ? ? ? ? ?.base ? = S3C_PA_UART3, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_S3CUART_RX3, > ? ? ? ? ? ? ? ?.template = &template_uart_s3c64xx, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_WATCHDOG, > ? ? ? ? ? ? ? ?.name ? = "s3c2410-wdt", > ? ? ? ? ? ? ? ?.index ?= -1, > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_WATCHDOG, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_WDT, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_SDHCI, > ? ? ? ? ? ? ? ?.name ? = "s3c-sdhci", > ? ? ? ? ? ? ? ?.index ?= 0, > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_HSMMC0 , > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_HSMMC0, > ? ? ? ? ? ? ? ?.dma ? ?= &samsung_std_dma_mask, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_SDHCI, > ? ? ? ? ? ? ? ?.name ? = "s3c-sdhci", > ? ? ? ? ? ? ? ?.index ?= 1, > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_HSMMC1, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_HSMMC1, > ? ? ? ? ? ? ? ?.dma ? ?= &samsung_std_dma_mask, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_SDHCI, > ? ? ? ? ? ? ? ?.name ? = "s3c-sdhci", > ? ? ? ? ? ? ? ?.index ?= 2, > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_HSMMC2, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_HSMMC1, > ? ? ? ? ? ? ? ?.dma ? ?= &samsung_std_dma_mask, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_OHCI, > ? ? ? ? ? ? ? ?.name ? = "s3c2410-ohci", > ? ? ? ? ? ? ? ?.index ?= -1, > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_USBHOST, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_USBH, > ? ? ? ? ? ? ? ?.dma ? ?= &samsung_std_dma_mask, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_NAND, > ? ? ? ? ? ? ? ?.name ? = "s3c6400-nand", > ? ? ? ? ? ? ? ?.index ?= -1, > ? ? ? ? ? ? ? ?.base ? = 0x4E000000, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_NFC, > ? ? ? ?}, { > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_I2C, > ? ? ? ? ? ? ? ?.name ? = "s3c2440-i2c", > ? ? ? ? ? ? ? ?.index ?= 0, > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_IIC0, > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_IIC, > ? ? ? ?}, { > ... > > This solution is imho really clean an easy to understand. It is also > easy to check which SoC has which peripherals defined and how. Question. recently it's changed to use MMC0, MMC2, MMC3, then how to define it? More basically, where these info are defined for chip or board? If chip, the how to handle several variants? Thank you, Kyungmin Park > > I hope Ben will be able to finish it soon and all Samsung platforms can > be converted for it. Then creating a single kernel for more than one SoC > should be possible with only a few additional changes. > >> PS: My feeling of commenting several of the samsung patches so far turns >> out to be quite frustrated, or I'm just too sensitive. NOTE neither am I >> NAKing Samsung patches, nor am I interested to be involved, I'm just givin >> my suggestions. > > I'm sorry if I offended You. I just wanted to show that the solution has > been already found. > > Best regards > -- > Marek Szyprowski > Samsung Poland R&D Center > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at ?http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Samsung SoCs: preparation for single kernel 2010-06-24 2:08 ` Kyungmin Park @ 2010-06-24 5:52 ` Marek Szyprowski -1 siblings, 0 replies; 26+ messages in thread From: Marek Szyprowski @ 2010-06-24 5:52 UTC (permalink / raw) To: 'Kyungmin Park' Cc: 'Russell King - ARM Linux', linux-samsung-soc, 'Eric Miao', 'Ben Dooks', 'arm-linux' Hello, On Thursday, June 24, 2010 4:08 AM Kyungmin Park wrote: > On Wed, Jun 23, 2010 at 6:20 PM, Marek Szyprowski > <m.szyprowski@samsung.com> wrote: > > Hello, > > > > On Wednesday, June 23, 2010 10:02 AM Eric Miao wrote: > > > >> >> Now you have > >> >> > >> >> s5pv210_device_hsmmc0 > >> >> s5pc100_device_hsmmc0 > >> >> s3c64xx_device_hsmmc0 > >> >> .... > >> >> > >> >> each with a different base. > >> > > >> > There is no need for such code duplication. > >> > >> However, I believe this is the right way to go. A certain level of > >> duplication is the price to pay for a generic and clean solution. > >> > >> When a peripheral controller or IP is moved from one SoC to the > >> next generation, there are several things could have been changed: > >> > >> 1. new base address and IRQ number > >> 2. fixes and enhancements to the original IP > >> > >> 1. will result in a different 'struct resource', and 2. will result in a > >> different 'struct platform_device' with a different name, so the driver > >> can match the platform_device_id table as you agreed I'm right on > >> that recommendation. > >> > >> They are actually _two_ different devices. > > > > Right, they are separate entities, but would be really good if a similar > > git brcode could be merged together. > > > >> > Ben is working on a solution for > >> > a single kernel which supports multiple SoCs. Some of his work in > >> progress can > >> > be found here: git://git.fluff.org/bjdooks/linux branch wip-samsung- > dev > >> and > >> > wip-samsung-dev2. > >> > >> Could you describe it a bit here and bring it on table for discussion? > > > > The idea behind his patches is to provide a table for each SoC with short > > description of all available devices and generate platform_device entries > > dynamically from that table. > > > > Here is a short code example: > > > > struct s3c_pdev_table s3c6xxx_dev_table[] __initdata = { > > { > > .type = SAMSUNG_DEVICE_UART, > > .name = "s3c6400-uart", > > .index = 0, > > .base = S3C_PA_UART0, > > .irq = IRQ_S3CUART_RX0, > > .template = &template_uart_s3c64xx, > > }, { > > .type = SAMSUNG_DEVICE_UART, > > .name = "s3c6400-uart", > > .index = 1, > > .base = S3C_PA_UART1, > > .irq = IRQ_S3CUART_RX1, > > .template = &template_uart_s3c64xx, > > }, { > > .type = SAMSUNG_DEVICE_UART, > > .name = "s3c6400-uart", > > .index = 2, > > .base = S3C_PA_UART2, > > .irq = IRQ_S3CUART_RX2, > > .template = &template_uart_s3c64xx, > > }, { > > .type = SAMSUNG_DEVICE_UART, > > .name = "s3c6400-uart", > > .index = 3, > > .base = S3C_PA_UART3, > > .irq = IRQ_S3CUART_RX3, > > .template = &template_uart_s3c64xx, > > }, { > > .type = SAMSUNG_DEVICE_WATCHDOG, > > .name = "s3c2410-wdt", > > .index = -1, > > .base = S3C64XX_PA_WATCHDOG, > > .irq = IRQ_WDT, > > }, { > > .type = SAMSUNG_DEVICE_SDHCI, > > .name = "s3c-sdhci", > > .index = 0, > > .base = S3C64XX_PA_HSMMC0 , > > .irq = IRQ_HSMMC0, > > .dma = &samsung_std_dma_mask, > > }, { > > .type = SAMSUNG_DEVICE_SDHCI, > > .name = "s3c-sdhci", > > .index = 1, > > .base = S3C64XX_PA_HSMMC1, > > .irq = IRQ_HSMMC1, > > .dma = &samsung_std_dma_mask, > > }, { > > .type = SAMSUNG_DEVICE_SDHCI, > > .name = "s3c-sdhci", > > .index = 2, > > .base = S3C64XX_PA_HSMMC2, > > .irq = IRQ_HSMMC1, > > .dma = &samsung_std_dma_mask, > > }, { > > .type = SAMSUNG_DEVICE_OHCI, > > .name = "s3c2410-ohci", > > .index = -1, > > .base = S3C64XX_PA_USBHOST, > > .irq = IRQ_USBH, > > .dma = &samsung_std_dma_mask, > > }, { > > .type = SAMSUNG_DEVICE_NAND, > > .name = "s3c6400-nand", > > .index = -1, > > .base = 0x4E000000, > > .irq = IRQ_NFC, > > }, { > > .type = SAMSUNG_DEVICE_I2C, > > .name = "s3c2440-i2c", > > .index = 0, > > .base = S3C64XX_PA_IIC0, > > .irq = IRQ_IIC, > > }, { > > ... > > > > This solution is imho really clean an easy to understand. It is also > > easy to check which SoC has which peripherals defined and how. > > Question. recently it's changed to use MMC0, MMC2, MMC3, then how to define > it? There is index parameter that defines the instance of the device. > More basically, where these info are defined for chip or board? The above table is defined per SoC. Each board then registers the particular devices like it is done in the current kernels. The following diff should explain it better: -static struct platform_device *smdk6400_devices[] __initdata = { - &s3c_device_hsmmc1, - &s3c_device_i2c0, +static struct s3c_devtable smdk6400_devtable[] __initdata = { + { .type = SAMSUNG_DEVICE_SDHCI, .index = 1, }, + { .type = SAMSUNG_DEVICE_I2C, .index = 0, }, static void __init smdk6400_machine_init(void) { i2c_register_board_info(0, i2c_devs, ARRAY_SIZE(i2c_devs)); - platform_add_devices(smdk6400_devices, ARRAY_SIZE(smdk6400_devices)); + samsung_add_devices(smdk6400_devtable, ARRAY_SIZE(smdk6400_devtable)); } > If chip, the how to handle several variants? The same way it is handled in the current kernels. Machine init code can even do some additional fixups if required. Best regards -- Marek Szyprowski Samsung Poland R&D Center ^ permalink raw reply [flat|nested] 26+ messages in thread
* Samsung SoCs: preparation for single kernel @ 2010-06-24 5:52 ` Marek Szyprowski 0 siblings, 0 replies; 26+ messages in thread From: Marek Szyprowski @ 2010-06-24 5:52 UTC (permalink / raw) To: linux-arm-kernel Hello, On Thursday, June 24, 2010 4:08 AM Kyungmin Park wrote: > On Wed, Jun 23, 2010 at 6:20 PM, Marek Szyprowski > <m.szyprowski@samsung.com> wrote: > > Hello, > > > > On Wednesday, June 23, 2010 10:02 AM Eric Miao wrote: > > > >> >> Now you have > >> >> > >> >> s5pv210_device_hsmmc0 > >> >> s5pc100_device_hsmmc0 > >> >> s3c64xx_device_hsmmc0 > >> >> .... > >> >> > >> >> each with a different base. > >> > > >> > There is no need for such code duplication. > >> > >> However, I believe this is the right way to go. A certain level of > >> duplication is the price to pay for a generic and clean solution. > >> > >> When a peripheral controller or IP is moved from one SoC to the > >> next generation, there are several things could have been changed: > >> > >> 1. new base address and IRQ number > >> 2. fixes and enhancements to the original IP > >> > >> 1. will result in a different 'struct resource', and 2. will result in a > >> different 'struct platform_device' with a different name, so the driver > >> can match the platform_device_id table as you agreed I'm right on > >> that recommendation. > >> > >> They are actually _two_ different devices. > > > > Right, they are separate entities, but would be really good if a similar > > git brcode could be merged together. > > > >> > Ben is working on a solution for > >> > a single kernel which supports multiple SoCs. Some of his work in > >> progress can > >> > be found here: git://git.fluff.org/bjdooks/linux branch wip-samsung- > dev > >> and > >> > wip-samsung-dev2. > >> > >> Could you describe it a bit here and bring it on table for discussion? > > > > The idea behind his patches is to provide a table for each SoC with short > > description of all available devices and generate platform_device entries > > dynamically from that table. > > > > Here is a short code example: > > > > struct s3c_pdev_table s3c6xxx_dev_table[] __initdata = { > > ? ? ? ?{ > > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_UART, > > ? ? ? ? ? ? ? ?.name ? = "s3c6400-uart", > > ? ? ? ? ? ? ? ?.index ?= 0, > > ? ? ? ? ? ? ? ?.base ? = S3C_PA_UART0, > > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_S3CUART_RX0, > > ? ? ? ? ? ? ? ?.template = &template_uart_s3c64xx, > > ? ? ? ?}, { > > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_UART, > > ? ? ? ? ? ? ? ?.name ? = "s3c6400-uart", > > ? ? ? ? ? ? ? ?.index ?= 1, > > ? ? ? ? ? ? ? ?.base ? = S3C_PA_UART1, > > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_S3CUART_RX1, > > ? ? ? ? ? ? ? ?.template = &template_uart_s3c64xx, > > ? ? ? ?}, { > > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_UART, > > ? ? ? ? ? ? ? ?.name ? = "s3c6400-uart", > > ? ? ? ? ? ? ? ?.index ?= 2, > > ? ? ? ? ? ? ? ?.base ? = S3C_PA_UART2, > > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_S3CUART_RX2, > > ? ? ? ? ? ? ? ?.template = &template_uart_s3c64xx, > > ? ? ? ?}, { > > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_UART, > > ? ? ? ? ? ? ? ?.name ? = "s3c6400-uart", > > ? ? ? ? ? ? ? ?.index ?= 3, > > ? ? ? ? ? ? ? ?.base ? = S3C_PA_UART3, > > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_S3CUART_RX3, > > ? ? ? ? ? ? ? ?.template = &template_uart_s3c64xx, > > ? ? ? ?}, { > > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_WATCHDOG, > > ? ? ? ? ? ? ? ?.name ? = "s3c2410-wdt", > > ? ? ? ? ? ? ? ?.index ?= -1, > > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_WATCHDOG, > > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_WDT, > > ? ? ? ?}, { > > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_SDHCI, > > ? ? ? ? ? ? ? ?.name ? = "s3c-sdhci", > > ? ? ? ? ? ? ? ?.index ?= 0, > > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_HSMMC0 , > > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_HSMMC0, > > ? ? ? ? ? ? ? ?.dma ? ?= &samsung_std_dma_mask, > > ? ? ? ?}, { > > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_SDHCI, > > ? ? ? ? ? ? ? ?.name ? = "s3c-sdhci", > > ? ? ? ? ? ? ? ?.index ?= 1, > > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_HSMMC1, > > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_HSMMC1, > > ? ? ? ? ? ? ? ?.dma ? ?= &samsung_std_dma_mask, > > ? ? ? ?}, { > > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_SDHCI, > > ? ? ? ? ? ? ? ?.name ? = "s3c-sdhci", > > ? ? ? ? ? ? ? ?.index ?= 2, > > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_HSMMC2, > > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_HSMMC1, > > ? ? ? ? ? ? ? ?.dma ? ?= &samsung_std_dma_mask, > > ? ? ? ?}, { > > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_OHCI, > > ? ? ? ? ? ? ? ?.name ? = "s3c2410-ohci", > > ? ? ? ? ? ? ? ?.index ?= -1, > > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_USBHOST, > > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_USBH, > > ? ? ? ? ? ? ? ?.dma ? ?= &samsung_std_dma_mask, > > ? ? ? ?}, { > > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_NAND, > > ? ? ? ? ? ? ? ?.name ? = "s3c6400-nand", > > ? ? ? ? ? ? ? ?.index ?= -1, > > ? ? ? ? ? ? ? ?.base ? = 0x4E000000, > > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_NFC, > > ? ? ? ?}, { > > ? ? ? ? ? ? ? ?.type ? = SAMSUNG_DEVICE_I2C, > > ? ? ? ? ? ? ? ?.name ? = "s3c2440-i2c", > > ? ? ? ? ? ? ? ?.index ?= 0, > > ? ? ? ? ? ? ? ?.base ? = S3C64XX_PA_IIC0, > > ? ? ? ? ? ? ? ?.irq ? ?= IRQ_IIC, > > ? ? ? ?}, { > > ... > > > > This solution is imho really clean an easy to understand. It is also > > easy to check which SoC has which peripherals defined and how. > > Question. recently it's changed to use MMC0, MMC2, MMC3, then how to define > it? There is index parameter that defines the instance of the device. > More basically, where these info are defined for chip or board? The above table is defined per SoC. Each board then registers the particular devices like it is done in the current kernels. The following diff should explain it better: -static struct platform_device *smdk6400_devices[] __initdata = { - &s3c_device_hsmmc1, - &s3c_device_i2c0, +static struct s3c_devtable smdk6400_devtable[] __initdata = { + { .type = SAMSUNG_DEVICE_SDHCI, .index = 1, }, + { .type = SAMSUNG_DEVICE_I2C, .index = 0, }, static void __init smdk6400_machine_init(void) { i2c_register_board_info(0, i2c_devs, ARRAY_SIZE(i2c_devs)); - platform_add_devices(smdk6400_devices, ARRAY_SIZE(smdk6400_devices)); + samsung_add_devices(smdk6400_devtable, ARRAY_SIZE(smdk6400_devtable)); } > If chip, the how to handle several variants? The same way it is handled in the current kernels. Machine init code can even do some additional fixups if required. Best regards -- Marek Szyprowski Samsung Poland R&D Center ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Samsung SoCs: preparation for single kernel 2010-06-23 0:50 ` Eric Miao @ 2010-06-23 7:28 ` Tony Lindgren -1 siblings, 0 replies; 26+ messages in thread From: Tony Lindgren @ 2010-06-23 7:28 UTC (permalink / raw) To: Eric Miao Cc: Kyungmin Park, linux-samsung-soc, Russell King - ARM Linux, arm-linux, Ben Dooks, Marek Szyprowski * Eric Miao <eric.y.miao@gmail.com> [100623 03:48]: > On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park <kmpark@infradead.org> wrote: > > To Ben, > > > > I really need single kernel for s5pc110 (cortex A8) and s5pc210 > > (cortex A9) at least. > > Fortunately arm move to these approaches recently. but current Samsung > > SoCs not prepare these one. > > > > So I wonder do you have a plan or how to address these issues? > > How to assign the address at resources and use it at runtime? > > > > Personally I want to use cpu_is_*. but you reject it to use. > > Other way is that we can create the base address variables and assign > > it at init time. > > > > Please give your opinions. > > > > Thank you, > > Kyungmin Park > > > > e.g., cpu_is_* usage at OMAP tree > > > > static void omap_init_mcspi(void) > > { > > if (cpu_is_omap44xx()) > > omap4_mcspi_fixup(); > > > > platform_device_register(&omap2_mcspi1); > > platform_device_register(&omap2_mcspi2); > > > > if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) > > omap2_mcspi3_init(); > > > > if (cpu_is_omap343x() || cpu_is_omap44xx()) > > omap2_mcspi4_init(); > > } > > Just my two cents: cpu_is_*() can be used, but only when absolutely necessary. > The s3c does a CPU detection at startup, so I guess the usage of cpu_is_*() > can be even reduced. > > I'm not sure if the above case is a good reference or not. The omap_init_mcspi > is called from omap2_init_devices(), while the registration can actually be > made into the board init code when that device is used (some of the McSPIs are > not used, and it's not necessary to register them), and the differences be > handled in the driver. Few comments regarding the cpu_is_omap macros: The macros should really be soc_is_omapxxxx() instead cpu_is_omapxxxx(). Also, sprinkling these too much makes the code messy and hard to patch for new processors. So you should limit the use to very selected places during init, then set some flag like OMAP_HAS_MCSPI2 | OMAP_HAS_MCSPI3 or something similar. Regards, Tony ^ permalink raw reply [flat|nested] 26+ messages in thread
* Samsung SoCs: preparation for single kernel @ 2010-06-23 7:28 ` Tony Lindgren 0 siblings, 0 replies; 26+ messages in thread From: Tony Lindgren @ 2010-06-23 7:28 UTC (permalink / raw) To: linux-arm-kernel * Eric Miao <eric.y.miao@gmail.com> [100623 03:48]: > On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park <kmpark@infradead.org> wrote: > > To Ben, > > > > I really need single kernel for s5pc110 (cortex A8) and s5pc210 > > (cortex A9) at least. > > Fortunately arm move to these approaches recently. but current Samsung > > SoCs not prepare these one. > > > > So I wonder do you have a plan or how to address these issues? > > How to assign the address at resources and use it at runtime? > > > > Personally I want to use cpu_is_*. but you reject it to use. > > Other way is that we can create the base address variables and assign > > it at init time. > > > > Please give your opinions. > > > > Thank you, > > Kyungmin Park > > > > e.g., cpu_is_* usage at OMAP tree > > > > static void omap_init_mcspi(void) > > { > > ? ? ? ?if (cpu_is_omap44xx()) > > ? ? ? ? ? ? ? ?omap4_mcspi_fixup(); > > > > ? ? ? ?platform_device_register(&omap2_mcspi1); > > ? ? ? ?platform_device_register(&omap2_mcspi2); > > > > ? ? ? ?if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) > > ? ? ? ? ? ? ? ?omap2_mcspi3_init(); > > > > ? ? ? ?if (cpu_is_omap343x() || cpu_is_omap44xx()) > > ? ? ? ? ? ? ? ?omap2_mcspi4_init(); > > } > > Just my two cents: cpu_is_*() can be used, but only when absolutely necessary. > The s3c does a CPU detection at startup, so I guess the usage of cpu_is_*() > can be even reduced. > > I'm not sure if the above case is a good reference or not. The omap_init_mcspi > is called from omap2_init_devices(), while the registration can actually be > made into the board init code when that device is used (some of the McSPIs are > not used, and it's not necessary to register them), and the differences be > handled in the driver. Few comments regarding the cpu_is_omap macros: The macros should really be soc_is_omapxxxx() instead cpu_is_omapxxxx(). Also, sprinkling these too much makes the code messy and hard to patch for new processors. So you should limit the use to very selected places during init, then set some flag like OMAP_HAS_MCSPI2 | OMAP_HAS_MCSPI3 or something similar. Regards, Tony ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Samsung SoCs: preparation for single kernel 2010-06-23 7:28 ` Tony Lindgren @ 2010-06-23 7:36 ` Eric Miao -1 siblings, 0 replies; 26+ messages in thread From: Eric Miao @ 2010-06-23 7:36 UTC (permalink / raw) To: Tony Lindgren Cc: Kyungmin Park, linux-samsung-soc, Russell King - ARM Linux, arm-linux, Ben Dooks, Marek Szyprowski On Wed, Jun 23, 2010 at 3:28 PM, Tony Lindgren <tony@atomide.com> wrote: > * Eric Miao <eric.y.miao@gmail.com> [100623 03:48]: >> On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park <kmpark@infradead.org> wrote: >> > To Ben, >> > >> > I really need single kernel for s5pc110 (cortex A8) and s5pc210 >> > (cortex A9) at least. >> > Fortunately arm move to these approaches recently. but current Samsung >> > SoCs not prepare these one. >> > >> > So I wonder do you have a plan or how to address these issues? >> > How to assign the address at resources and use it at runtime? >> > >> > Personally I want to use cpu_is_*. but you reject it to use. >> > Other way is that we can create the base address variables and assign >> > it at init time. >> > >> > Please give your opinions. >> > >> > Thank you, >> > Kyungmin Park >> > >> > e.g., cpu_is_* usage at OMAP tree >> > >> > static void omap_init_mcspi(void) >> > { >> > if (cpu_is_omap44xx()) >> > omap4_mcspi_fixup(); >> > >> > platform_device_register(&omap2_mcspi1); >> > platform_device_register(&omap2_mcspi2); >> > >> > if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) >> > omap2_mcspi3_init(); >> > >> > if (cpu_is_omap343x() || cpu_is_omap44xx()) >> > omap2_mcspi4_init(); >> > } >> >> Just my two cents: cpu_is_*() can be used, but only when absolutely necessary. >> The s3c does a CPU detection at startup, so I guess the usage of cpu_is_*() >> can be even reduced. >> >> I'm not sure if the above case is a good reference or not. The omap_init_mcspi >> is called from omap2_init_devices(), while the registration can actually be >> made into the board init code when that device is used (some of the McSPIs are >> not used, and it's not necessary to register them), and the differences be >> handled in the driver. > > Few comments regarding the cpu_is_omap macros: The macros should really be > soc_is_omapxxxx() instead cpu_is_omapxxxx(). Right, that will be more specific. cpu_is_* could be used only with the ARM core, like cpu_is_arm946ejs(), ... And apparently we all have abusively used it :-) > > Also, sprinkling these too much makes the code messy and hard to patch for > new processors. So you should limit the use to very selected places during > init, then set some flag like OMAP_HAS_MCSPI2 | OMAP_HAS_MCSPI3 or something > similar. Exactly. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Samsung SoCs: preparation for single kernel @ 2010-06-23 7:36 ` Eric Miao 0 siblings, 0 replies; 26+ messages in thread From: Eric Miao @ 2010-06-23 7:36 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jun 23, 2010 at 3:28 PM, Tony Lindgren <tony@atomide.com> wrote: > * Eric Miao <eric.y.miao@gmail.com> [100623 03:48]: >> On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park <kmpark@infradead.org> wrote: >> > To Ben, >> > >> > I really need single kernel for s5pc110 (cortex A8) and s5pc210 >> > (cortex A9) at least. >> > Fortunately arm move to these approaches recently. but current Samsung >> > SoCs not prepare these one. >> > >> > So I wonder do you have a plan or how to address these issues? >> > How to assign the address at resources and use it at runtime? >> > >> > Personally I want to use cpu_is_*. but you reject it to use. >> > Other way is that we can create the base address variables and assign >> > it at init time. >> > >> > Please give your opinions. >> > >> > Thank you, >> > Kyungmin Park >> > >> > e.g., cpu_is_* usage at OMAP tree >> > >> > static void omap_init_mcspi(void) >> > { >> > ? ? ? ?if (cpu_is_omap44xx()) >> > ? ? ? ? ? ? ? ?omap4_mcspi_fixup(); >> > >> > ? ? ? ?platform_device_register(&omap2_mcspi1); >> > ? ? ? ?platform_device_register(&omap2_mcspi2); >> > >> > ? ? ? ?if (cpu_is_omap2430() || cpu_is_omap343x() || cpu_is_omap44xx()) >> > ? ? ? ? ? ? ? ?omap2_mcspi3_init(); >> > >> > ? ? ? ?if (cpu_is_omap343x() || cpu_is_omap44xx()) >> > ? ? ? ? ? ? ? ?omap2_mcspi4_init(); >> > } >> >> Just my two cents: cpu_is_*() can be used, but only when absolutely necessary. >> The s3c does a CPU detection at startup, so I guess the usage of cpu_is_*() >> can be even reduced. >> >> I'm not sure if the above case is a good reference or not. The omap_init_mcspi >> is called from omap2_init_devices(), while the registration can actually be >> made into the board init code when that device is used (some of the McSPIs are >> not used, and it's not necessary to register them), and the differences be >> handled in the driver. > > Few comments regarding the cpu_is_omap macros: The macros should really be > soc_is_omapxxxx() instead cpu_is_omapxxxx(). Right, that will be more specific. cpu_is_* could be used only with the ARM core, like cpu_is_arm946ejs(), ... And apparently we all have abusively used it :-) > > Also, sprinkling these too much makes the code messy and hard to patch for > new processors. So you should limit the use to very selected places during > init, then set some flag like OMAP_HAS_MCSPI2 | OMAP_HAS_MCSPI3 or something > similar. Exactly. ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2010-06-24 5:53 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-06-22 23:27 Samsung SoCs: preparation for single kernel Kyungmin Park 2010-06-22 23:27 ` Kyungmin Park 2010-06-23 0:50 ` Eric Miao 2010-06-23 0:50 ` Eric Miao 2010-06-23 1:47 ` Kyungmin Park 2010-06-23 1:47 ` Kyungmin Park 2010-06-23 1:54 ` Eric Miao 2010-06-23 1:54 ` Eric Miao 2010-06-23 2:01 ` Kyungmin Park 2010-06-23 2:01 ` Kyungmin Park 2010-06-23 6:25 ` Marek Szyprowski 2010-06-23 6:25 ` Marek Szyprowski 2010-06-23 8:01 ` Eric Miao 2010-06-23 8:01 ` Eric Miao 2010-06-23 9:20 ` Marek Szyprowski 2010-06-23 9:20 ` Marek Szyprowski 2010-06-23 10:24 ` Eric Miao 2010-06-23 10:24 ` Eric Miao 2010-06-24 2:08 ` Kyungmin Park 2010-06-24 2:08 ` Kyungmin Park 2010-06-24 5:52 ` Marek Szyprowski 2010-06-24 5:52 ` Marek Szyprowski 2010-06-23 7:28 ` Tony Lindgren 2010-06-23 7:28 ` Tony Lindgren 2010-06-23 7:36 ` Eric Miao 2010-06-23 7:36 ` Eric Miao
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.