On Wed, Jun 23, 2010 at 9:47 AM, Kyungmin Park <kmpark@xxxxxxxxxxxxx> wrote:
> On Wed, Jun 23, 2010 at 9:50 AM, Eric Miao <eric.y.miao@xxxxxxxxx> wrote:
>> On Wed, Jun 23, 2010 at 7:27 AM, Kyungmin Park <kmpark@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
