Samsung SoCs: preparation for single kernel

Samsung SoCs: preparation for single kernel

[Kyungmin Park]

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();
}

Samsung SoCs: preparation for single kernel

[Eric Miao]

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
>

Samsung SoCs: preparation for single kernel

[Kyungmin Park]

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
>

Samsung SoCs: preparation for single kernel

[Eric Miao]

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
>>
>

Samsung SoCs: preparation for single kernel

[Kyungmin Park]

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
>

Samsung SoCs: preparation for single kernel

[Marek Szyprowski]

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

Samsung SoCs: preparation for single kernel

[Eric Miao]

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.

Samsung SoCs: preparation for single kernel

[Marek Szyprowski]

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

Samsung SoCs: preparation for single kernel

[Eric Miao]

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
>
>
>
>

Samsung SoCs: preparation for single kernel

[Kyungmin Park]

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
>

Samsung SoCs: preparation for single kernel

[Marek Szyprowski]

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

Samsung SoCs: preparation for single kernel

[Tony Lindgren]

* 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

Samsung SoCs: preparation for single kernel

[Eric Miao]

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.