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

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

[Ben Dooks]

We inted to re-organise the plat-s3c/plat-s3c24xx/plat-s3c64xx into a
more generic plat-samsung with less code in the other plat- directories
to make it easier to port new devices and try and clear up some of the
naming issues with newer devices.

Start by creating a small arch/arm/plat-samsung with no actuall code in
so we can move items in as we process them.

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
---
 arch/arm/Kconfig               |    1 +
 arch/arm/plat-samsung/Kconfig  |   17 +++++++++++++++++
 arch/arm/plat-samsung/Makefile |   11 +++++++++++
 3 files changed, 29 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/plat-samsung/Kconfig
 create mode 100644 arch/arm/plat-samsung/Makefile

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1c4119c..51a454b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -747,6 +747,7 @@ source "arch/arm/mach-orion5x/Kconfig"
 
 source "arch/arm/mach-kirkwood/Kconfig"
 
+source "arch/arm/plat-samsung/Kconfig"
 source "arch/arm/plat-s3c24xx/Kconfig"
 source "arch/arm/plat-s3c64xx/Kconfig"
 source "arch/arm/plat-s3c/Kconfig"
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
new file mode 100644
index 0000000..d5ac9be
--- /dev/null
+++ b/arch/arm/plat-samsung/Kconfig
@@ -0,0 +1,17 @@
+# arch/arm/plat-samsung/Kconfig
+#
+# Copyright 2009 Simtec Electronics
+#
+# Licensed under GPLv2
+
+config PLAT_SAMSUNG
+	bool
+	depends on ARCH_S3C2410 || ARCH_S3C24A0 || ARCH_S3C64XX
+	default y
+	help
+	  Base platform code for all Samsung SoC based systems
+
+if PLAT_SAMSUNG
+
+
+endif
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
new file mode 100644
index 0000000..4478b9f
--- /dev/null
+++ b/arch/arm/plat-samsung/Makefile
@@ -0,0 +1,11 @@
+# arch/arm/plat-s3c64xx/Makefile
+#
+# Copyright 2009 Simtec Electronics
+#
+# Licensed under GPLv2
+
+obj-y				:=
+obj-m				:=
+obj-n				:= dummy.o
+obj-				:=
+
-- 
1.6.5

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

[Kukjin Kim]

Hi, everyone

On Tue, Nov 10, 2009 at 9:20PM +0900, Ben Dooks wrote:

> We inted to re-organise the plat-s3c/plat-s3c24xx/plat-s3c64xx into a
> more generic plat-samsung with less code in the other plat- directories
> to make it easier to port new devices and try and clear up some of the
> naming issues with newer devices.
> 
> Start by creating a small arch/arm/plat-samsung with no actuall code in
> so we can move items in as we process them.
(snip)

Ok, good.

We will be creating plat-s5p following to plat-samsung and will be submitted
soon.

Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
System LSI Division, SAMSUNG ELECTRONICS CO., LTD.

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

[Kyungmin Park]

Hi,

On Tue, Nov 10, 2009 at 10:33 AM, Kukjin Kim <kgene.kim@samsung.com> wrote:
>
> Hi, everyone
>
> On Tue, Nov 10, 2009 at 9:20PM +0900, Ben Dooks wrote:
>
>> We inted to re-organise the plat-s3c/plat-s3c24xx/plat-s3c64xx into a
>> more generic plat-samsung with less code in the other plat- directories
>> to make it easier to port new devices and try and clear up some of the
>> naming issues with newer devices.

Why do you miss the plat-s5pc1xx? Also add the plat-s5pc1xx series.

>>
>> Start by creating a small arch/arm/plat-samsung with no actuall code in
>> so we can move items in as we process them.
> (snip)
>
> Ok, good.
>
> We will be creating plat-s5p following to plat-samsung and will be submitted
> soon.

Why new plat-s5p is required? The main goal of plat-* directory is
support the SoC common codes.
Of course s5pc100 and s5pc110 is different features and different IPs
but no need to create each plat directory.

Thank you,
Kyungmin Park

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

[Harald Welte]

Dear Kyungmin,

On Tue, Nov 10, 2009 at 12:27:15PM +0900, Kyungmin Park wrote:
> >
> >> We inted to re-organise the plat-s3c/plat-s3c24xx/plat-s3c64xx into a
> >> more generic plat-samsung with less code in the other plat- directories
> >> to make it easier to port new devices and try and clear up some of the
> >> naming issues with newer devices.
> 
> Why do you miss the plat-s5pc1xx? Also add the plat-s5pc1xx series.

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.

> Why new plat-s5p is required? The main goal of plat-* directory is
> support the SoC common codes.

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.

> Of course s5pc100 and s5pc110 is different features and different IPs
> but no need to create each plat directory.

The 6440 shares some things with the c100, and the 6442 shares again
some things with the c110.  So putting all those files into one
directory seems to make it much easier to share code between the
different parts as needed.  Also, it means that we have to do less
moving around.

Imagine we continue with one plat-s5p64xx and plat-s5pc1xx, etc. for
each new SoC.  Later we detect there is some sharing with an earlier
product, then we need to move the file to plat-s5p.  This moving around
of files causes breakage in patches that people are having in their
private trees before they can move it mainline. 

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?

So the strategy for now is:

* introduce plat-samsung and plat-s5p
* implement some core changes regarding clock and platform_device to
  share more code between 6410, 6440, c100 (and sometimes also 24xx)
* introduce the s3c6440 core architecture code in plat-s5p
* introduce the smdk6440 support

After that is done and has stabilized, the idea is to
* complete the 6440 arch code with features like voltage scaling, dma,
  etc., submit more device drivers or update the mainline drivers to
  work on the 6440
* in parallel also think about converting the c100 code to use more of
  the new common code (clock, platform device and possibly more)

The System LSI focus at the moment is the 6440.  After that, V210 and
C100 are next on the priority scale (in that order).  So I think any
help that DMC can offer on completing the C100 codebase is appreciated
very much.  I don't expect any conflicts, as System LSI is working
on other parts meanwhile.

Regards,
	Harald
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

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

[Marek Szyprowski]

Hello,

On Tuesday, November 10, 2009 10:48 AM, Harald Welte wrote:

> Dear Kyungmin,
> 
> On Tue, Nov 10, 2009 at 12:27:15PM +0900, Kyungmin Park wrote:
> > >
> > >> We inted to re-organise the plat-s3c/plat-s3c24xx/plat-s3c64xx into a
> > >> more generic plat-samsung with less code in the other plat- directories
> > >> to make it easier to port new devices and try and clear up some of the
> > >> naming issues with newer devices.
> >
> > Why do you miss the plat-s5pc1xx? Also add the plat-s5pc1xx series.
> 
> 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.

> > Why new plat-s5p is required? The main goal of plat-* directory is
> > support the SoC common codes.
> 
> 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?

> > Of course s5pc100 and s5pc110 is different features and different IPs
> > but no need to create each plat directory.
> 
> The 6440 shares some things with the c100, and the 6442 shares again
> some things with the c110.  So putting all those files into one
> directory seems to make it much easier to share code between the
> different parts as needed.  Also, it means that we have to do less
> moving around.
> 
> Imagine we continue with one plat-s5p64xx and plat-s5pc1xx, etc. for
> each new SoC.  Later we detect there is some sharing with an earlier
> product, then we need to move the file to plat-s5p.  This moving around
> of files causes breakage in patches that people are having in their
> private trees before they can move it mainline.
> 
> 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. 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)?

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?

How can we adapt the current plat-s5pcxx code to better match the
migration to common plat-samsung directory?

Best regards
--
Marek Szyprowski
Samsung Poland R&D Center

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

[Harald Welte]

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.  

Regards,
-- 
- Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

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

[Kyungmin Park]

On Wed, Nov 11, 2009 at 1:58 PM, Harald Welte <laforge@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

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

[Ben Dooks]

On Wed, Nov 11, 2009 at 05:31:24PM +0900, Kyungmin Park wrote:
> On Wed, Nov 11, 2009 at 1:58 PM, Harald Welte <laforge@gnumonks.org> wrote:
> > Hi Marek,
> 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

Hey, if this stuff had been done earlier by any of the Samsung groups
then we'd be at a state where the changes would have been done to inline
code.

I hope that a lot of these changes will not only improve the code but
will be in such a way that simply editing the unsubbmitted/inprogress
architectures will not be difficult. I hope that some of these changes
will have quite a bit of the work scripted and thus fixups will be far
less painful. I also to intend not only to document the patches properly
but write some in-kernel documentation for the new systems so that it
can be referenced by developers looking at what changed.

There will be effort to ensure that these changes are not mandatory to
proper kernel operation.

You need to remember that I am doing this _in my spare time_ and thus
cannot devote the sort of time to this code that other people would
like. Hopefully the device changes (progressing) and clock changes
will be published during this weekend for people to review.

The actual change in directory structure may take more than this round
of kernel submissions. Our first aim is to factor out as much common
code as possible into plat-samung and deal with any fall out from these
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?

Currently in progress, 
 
> If you want to change, please also change the s5pc1xx that merged at mainline.

I will ensure all current defconfigs at-least build. I will throw the
autobuilder at it to see what is going on.

If someone can ensure that my last set of comments is replied to for the
S5PC merges sent by Marek, then I may consider merging as many of those
as possible (and at minimum the ones that will be affected by the changes).
 
> 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

-- 
-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

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

[Ben Dooks]

On Tue, Nov 10, 2009 at 02:38:42PM +0100, Marek Szyprowski wrote:
> Hello,
> 
> On Tuesday, November 10, 2009 10:48 AM, Harald Welte wrote:
> 
> > Dear Kyungmin,
> > 
> > On Tue, Nov 10, 2009 at 12:27:15PM +0900, Kyungmin Park wrote:
> > > >
> > > >> We inted to re-organise the plat-s3c/plat-s3c24xx/plat-s3c64xx into a
> > > >> more generic plat-samsung with less code in the other plat- directories
> > > >> to make it easier to port new devices and try and clear up some of the
> > > >> naming issues with newer devices.
> > >
> > > Why do you miss the plat-s5pc1xx? Also add the plat-s5pc1xx series.
> > 
> > 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.

Did you see my comments on the last series you submitted?
 
> > > Why new plat-s5p is required? The main goal of plat-* directory is
> > > support the SoC common codes.
> > 
> > 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?

As much as possible.
 
> > > Of course s5pc100 and s5pc110 is different features and different IPs
> > > but no need to create each plat directory.
> > 
> > The 6440 shares some things with the c100, and the 6442 shares again
> > some things with the c110.  So putting all those files into one
> > directory seems to make it much easier to share code between the
> > different parts as needed.  Also, it means that we have to do less
> > moving around.
> > 
> > Imagine we continue with one plat-s5p64xx and plat-s5pc1xx, etc. for
> > each new SoC.  Later we detect there is some sharing with an earlier
> > product, then we need to move the file to plat-s5p.  This moving around
> > of files causes breakage in patches that people are having in their
> > private trees before they can move it mainline.
> > 
> > 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. 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'm not sure what you mean by 'big overhead', could you elaborate on
that statement.

I personally do not think multiple plat- directories are much of a problem
and much prefer them to some form of heirarchy as you are discussing here
although there are probably merits either way.

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

No, each driver header carries all the necessary defines for the
version, since if the driver needs updating it is likely the header
file for that driver will need updating too.

For the maps, these are much more chip specific and will probably
be changed to a more specific name to make them easier to find if
they need to be common.

Part of the device change will be to move to a table based system
where there will be less need to have things defined in header
files.

We also want to try and ensure that <plat/xxx.h> xxx.h items are
unique as possible to avoid finding a large number of matches
for xxx.h in the header files and having to work out which one is
being included.
 
> How can we adapt the current plat-s5pcxx code to better match the
> migration to common plat-samsung directory?

Have a look at the documentation in the pre-release and then make
some comments then (if you need to).

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

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

[Marek Szyprowski]

Hello,

On Thursday, November 12, 2009 12:08 AM Ben Dooks wrote:

> On Tue, Nov 10, 2009 at 02:38:42PM +0100, Marek Szyprowski wrote:
> > Hello,
> >
> > On Tuesday, November 10, 2009 10:48 AM, Harald Welte wrote:
> >
> > > Dear Kyungmin,
> > >
> > > On Tue, Nov 10, 2009 at 12:27:15PM +0900, Kyungmin Park wrote:
> > > > >
> > > > >> We inted to re-organise the plat-s3c/plat-s3c24xx/plat-s3c64xx into a
> > > > >> more generic plat-samsung with less code in the other plat- directories
> > > > >> to make it easier to port new devices and try and clear up some of the
> > > > >> naming issues with newer devices.
> > > >
> > > > Why do you miss the plat-s5pc1xx? Also add the plat-s5pc1xx series.
> > >
> > > 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.
> 
> Did you see my comments on the last series you submitted?

Yes, I prepared new patch set that addresses these issues.

> > > > Of course s5pc100 and s5pc110 is different features and different IPs
> > > > but no need to create each plat directory.
> > >
> > > The 6440 shares some things with the c100, and the 6442 shares again
> > > some things with the c110.  So putting all those files into one
> > > directory seems to make it much easier to share code between the
> > > different parts as needed.  Also, it means that we have to do less
> > > moving around.
> > >
> > > Imagine we continue with one plat-s5p64xx and plat-s5pc1xx, etc. for
> > > each new SoC.  Later we detect there is some sharing with an earlier
> > > product, then we need to move the file to plat-s5p.  This moving around
> > > of files causes breakage in patches that people are having in their
> > > private trees before they can move it mainline.
> > >
> > > 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. 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'm not sure what you mean by 'big overhead', could you elaborate on
> that statement.

I mean that a lot plat- directories might pollute kernel tree and complicate
live other, non-samsung arm developers.

> I personally do not think multiple plat- directories are much of a problem
> and much prefer them to some form of heirarchy as you are discussing here
> although there are probably merits either way.
> 
> > 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?
> 
> No, each driver header carries all the necessary defines for the
> version, since if the driver needs updating it is likely the header
> file for that driver will need updating too.
> 
> For the maps, these are much more chip specific and will probably
> be changed to a more specific name to make them easier to find if
> they need to be common.
> 
> Part of the device change will be to move to a table based system
> where there will be less need to have things defined in header
> files.
> 
> We also want to try and ensure that <plat/xxx.h> xxx.h items are
> unique as possible to avoid finding a large number of matches
> for xxx.h in the header files and having to work out which one is
> being included.

Thanks for clarification. I'm looking forward to seeing the patches
for this new framework for Samsung chips.

Best regards
--
Marek Szyprowski
Samsung Poland R&D Center