[PATCH] ARM: SAMSUNG: Add plat-samsung as starting point for plat-s3c* moves

Kyungmin Park kmpark at infradead.org
Wed Nov 11 03:31:24 EST 2009


On Wed, Nov 11, 2009 at 1:58 PM, Harald Welte <laforge at gnumonks.org> wrote:
> Hi Marek,
>
> On Tue, Nov 10, 2009 at 02:38:42PM +0100, Marek Szyprowski wrote:
>> >
>> > Of course.  The code for the C100, C110, V210, etc. is also subject to
>> > this.  Maybe Ben simply wanted to be polite and indicate he does not
>> > intend to interfere with your current codebase.  After all, DMC is the
>> > maintainer of the C100 support in mainline, and we hope we can have your
>> > cooperation with this new structure.  But since we did not ask you yet,
>> > we couldn't assume that you would agree.
>>
>> We are also interested in improving mainline support for C100 series as
>> well as upcoming C110.
>
> Ok.  The general goal of the work that Ben and me have been discussing
> and initiating is to remove the amount of code duplication when
> introducing support for a new SoC.  Right now, the c100 code contains a
> number of copies of the 6410 code, and the 6440 code also copies a lot
> from 6410.
>
> A lot of copying was identified in things like the platform device files
> (*-dev.c) and the *-clock.c files - which is why that was the starting
> point.
>
> There may also be other files up to something like sleep.S where again
> much duplication is visible (see my 6440 review mail recently)
>
>> > plat-samsung is intended for stuff that's shared between all the various
>> > arm9/arm11/a8 based SoCs.  This is so far in plat-s3c, even though it's
>> > not only used (and will not only be used) by s3c parts.
>>
>> So most of the current code from plat-s3c (mainly common dev-* platform
>> resources, clocks, uart and gpio core functions) would be moved to
>> plat-samsung? Right?
>
> I think this is the goal, yes.  I personally don't care too much about
> correct naming or correct directory name.  The most important goal is to
> prevent/remove copy+paste style code and really have every function only
> once, if it is the same or 99% the same on multiple SoCs.
>
>> > Also, don't you think it is somewhat weird that soon samsung would have
>> > as many plat-* directories as all other ARM SoC makers together?
>>
>> These multiple plat-* directories for all Samsung chip series are in
>> fact a big overhead for kernel tree. I assume that You want to end with
>> only one plat-samsung directory.
>
> I think currently having 3 directories: plat-samsung, plat-s3c and
> plat-s5p are in the discussion.
>
>> Am I right? What about multiple mach-* directories (mach-s3c2400, ...,
>> mach-s3c24a0, mach-s3c6400, mach-s3c6410, mach-s5pc100, ...)? Do you
>> plan to keep them? Maybe a multilevel structure would be more
>> aproperiate? (mach-samsung/s3c2400, mach-samsung/s3c6400, and so on)?
>
> I think at the moment we're focusing on the plat-* directories first and
> try not to change everything at the same time.  I would not propose
> freely renaming / moving all directories if this does not at the same
> time mean that we can remove code duplication.
>
>> How do you plan to handle different includes, register map, register
>> offset defines, etc in each chip series? Would this result in moving
>> the series specific include directories to mach-* directories?
>
> I think the details will be worked out while the task is being done.
> The actual base addresses for each integrated peripheral will be
> provided through a soc-specific table that is passed to the platform
> device handling code that ben is working on.
>
>> How can we adapt the current plat-s5pcxx code to better match the
>> migration to common plat-samsung directory?
>
> I think it is best to first wait for those changes to appear on the
> 24xx/6410 code in mainline.  We are working with System LSI to add the
> 6440.  Once that has been implemented and is known to work in next-s3c,
> I think you can adapt your code and e.g. remove some code from
> s5pc100-clock.c
>
> So for right now, I would recommend to be a bit patient until the core
> changes have emerged and stabilized, to avoid wasting your time to
> change to a moving target.

We are waiting too much time. but nothing are change. As you mentioned
you and ben try to change frameworks and directories. However we did a
lot of works already. but your changes make it works twice since to
match framework changes
The point of view are different, you and LSI focuses on 64xx series
but I don't interest these SoCs. Since we are focusing on s5pc1xx
series whatever S5PV210 is.
Also I can't find any activities at ben's git or LSI git. Where's your
works and plan?

If you want to change, please also change the s5pc1xx that merged at mainline.

Thank you,
Kyungmin Park



More information about the linux-arm-kernel mailing list