All of lore.kernel.org
 help / color / mirror / Atom feed
* Discussion request for new Samsung SoCs maintaining
@ 2009-08-27 11:06 Jinsung Yang
  2009-08-27 12:44 ` Bill Gatliff
                   ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Jinsung Yang @ 2009-08-27 11:06 UTC (permalink / raw)
  To: linux-arm-kernel


Hello,
My name is Jinsung, Yang, I'm happy to suggest my ideas to you. Let me introduce myself first.
I am working for Samsung Electronics (System LSI/Semiconductor Business), and working on device drivers on Samsung SoCs such as s3c6410 and so on.
Recently, my team has decided to contribute our source codes to the mainline.
Following are some troubles our team is facing and solutions to them.

The latest (arm) linux mainline has some Samsung SoCs supports like s3c24xx and s3c6410, and we need to add our new SoCs which are based on arm11 and cortex-a8 architectures.
I'll give some short explanations about the line-up of Samsung SoCs:
* ARM11 family: s3c6410, s3c6430, s3c6431, s5p6440, s5p6442, ..
* Cortex-A8 family: s5pc100, s5pc110, ..

As some people know, even if some SoCs are in the same family, the prefix of SoCs are different, this is the first thing of problems.
We call that 'the naming issues', we will have discuss in detail later.. (after fixing architecture issues)

The second problem is that even though same family, the features like the memory map and internal devices (IPs) are very different.
For example, s5p6442 and s5pc110 have different arm core, but internal devices are very similar.

Otherwise, although s5p6440 and s5p6442 are in the same family, architecture and similar names, internal devices are very different.
It makes to be hard to integrate codes in a same platform directory.

Similarity of our SoCs are depends on when the chip was born rather than which arm core is included because same h/w features are used for SoC design if some projects (= different core) are going on the same period.

So that, we are considering the following platform structure to manage our new SoCs.
(All names are tentative)

linux
  |
  +-- arch
        |
        +-- arm
              |
              +-- plat-samsung2
              |
              +-- mach-samsung2
              |         |
              |         +-- mach-smdk6440.c
              |         +-- mach-smdkc100.c
              |         +-- ...
              |
              +-- plat-samsung3
              |
              +-- mach-samsung3
              |         |
              |         +-- mach-smdk6442.c
              |         +-- mach-smdkc110.c
              |         +-- ...

This layout is based on the time of products, not what the core is in.
(The names like plat-samsung2 are not decided, just be used to explain our layout)

The plat-samsung2 and plat-samsung3 directories include common implementations for those groups, as you guess, mach-samsung2 and mach-samsung3 directories support board specific files.

Anyone has better idea?

We hope and need to discuss our ideas more and more, continuously, so tell us your opinions and something like this freely about this and, because s3c6410 supports is already in the mainline, we should handle this SoC specially.

Also we are considering the single binary compilation/operation for the same arm architecture.
Finally, we should talk with Ben Dooks who is a maintainer of s3c24xx series, so hope Ben's reply especially :)

Thank you,
--
Jinsung, Yang <jsgood@samsung.com>
Samsung Electronics, Co., Ltd.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Discussion request for new Samsung SoCs maintaining
  2009-08-27 11:06 Discussion request for new Samsung SoCs maintaining Jinsung Yang
@ 2009-08-27 12:44 ` Bill Gatliff
  2009-08-28  3:19   ` Harald Welte
                     ` (2 more replies)
  2009-08-27 13:14 ` Mark Brown
  2009-08-27 13:57 ` David F. Carlson
  2 siblings, 3 replies; 12+ messages in thread
From: Bill Gatliff @ 2009-08-27 12:44 UTC (permalink / raw)
  To: linux-arm-kernel

Jinsung Yang wrote:
> The second problem is that even though same family, the features like the memory map and internal devices (IPs) are very different.
> For example, s5p6442 and s5pc110 have different arm core, but internal devices are very similar. 
>
> Otherwise, although s5p6440 and s5p6442 are in the same family, architecture and similar names, internal devices are very different.
> It makes to be hard to integrate codes in a same platform directory.
>   

The AT91 and AVR32 SoCs have the same problem: very different cores 
(different instruction set architectures, actually), but compatible 
peripherals.  Their solution has been to embrace the platform and other 
device models heavily, which I think is the appropriate one.  I think 
this approach will work for you as well.

> So that, we are considering the following platform structure to manage our new SoCs.
>   

Wow, your naming situation is... messed up.  :)

I'm not sure I have any useful suggestion for this part.  It would have 
been nice to have a "mach-a8" and "mach-arm11" for these situations, but 
we don't and I'm not sure it wouldn't cause even more problems to create 
them.

Your suggestion is consistent with what OMAP is doing, and that approach 
seems to be working for them.  If you embrace the pluggable APIs as much 
as possible, and keep is much as you can over in drivers/, then 
hopefully the problem is more manageable.


b.g.

-- 
Bill Gatliff
bgat at billgatliff.com

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Discussion request for new Samsung SoCs maintaining
  2009-08-27 11:06 Discussion request for new Samsung SoCs maintaining Jinsung Yang
  2009-08-27 12:44 ` Bill Gatliff
@ 2009-08-27 13:14 ` Mark Brown
  2009-08-28  3:27   ` Harald Welte
  2009-08-27 13:57 ` David F. Carlson
  2 siblings, 1 reply; 12+ messages in thread
From: Mark Brown @ 2009-08-27 13:14 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Aug 27, 2009 at 11:06:56AM +0000, Jinsung Yang wrote:

[Reflowed into 80 columns - you might want to fix your MUA to do this,
it makes things much more legible.]

> So that, we are considering the following platform structure to manage
> our new SoCs.  (All names are tentative)

It might be easier to think about this in terms of how it integrates
with the existing Samsung CPU support - what are the changes to the
current structure and how will the new CPUs slot into that structure?
Although...

> We hope and need to discuss our ideas more and more, continuously, so
> tell us your opinions and something like this freely about this and,
> because s3c6410 supports is already in the mainline, we should handle
> this SoC specially.

It would seem to be much better to integrate your work with the existing
support for your CPUs rather than starting from scratch - there's an
awful lot of continuity in the IPs and it'd seem strange to ignore that.
What are the factors that are pushing you towards starting from scratch?

> Finally, we should talk with Ben Dooks who is a maintainer of s3c24xx
> series, so hope Ben's reply especially :)

You probably want to CC him on messages like this - I've added him here.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Discussion request for new Samsung SoCs maintaining
  2009-08-27 11:06 Discussion request for new Samsung SoCs maintaining Jinsung Yang
  2009-08-27 12:44 ` Bill Gatliff
  2009-08-27 13:14 ` Mark Brown
@ 2009-08-27 13:57 ` David F. Carlson
  2009-08-28  3:34   ` Harald Welte
  2 siblings, 1 reply; 12+ messages in thread
From: David F. Carlson @ 2009-08-27 13:57 UTC (permalink / raw)
  To: linux-arm-kernel


My 2c...

I have been working with the 6410 tree in several places.  A merge of samsung tree would be greatly appreciated.

Please remember that since I am working SmartQ and there are 3 other 6410 based MACHs in Ben's next-s3c tree.  

So, please, MACH_SMDK6410 != CPU_6410 and
            MACH_SMDK6410 != PLAT_64XX.

The common peripheral support needs to be factored out so that "thin" MACH configs can set some per-MACH GPIOs/chipsets (LCD, power,etc.)

Thanks

David F. Carlson    Chronolytics, Inc.  Rochester, NY
mailto:dave at chronolytics.com            http://www.chronolytics.com

"The faster I go, the behinder I get." --Lewis Carroll
> So that, we are considering the following platform structure to manage our new SoCs.
> (All names are tentative)
> 
> linux
>   |
>   +-- arch
>         |
>         +-- arm
>               |
>               +-- plat-samsung2
>               |
>               +-- mach-samsung2
>               |         |
>               |         +-- mach-smdk6440.c
>               |         +-- mach-smdkc100.c
>               |         +-- ...
>               |
>               +-- plat-samsung3
>               |
>               +-- mach-samsung3
>               |         |
>               |         +-- mach-smdk6442.c
>               |         +-- mach-smdkc110.c
>               |         +-- ...
> 
> This layout is based on the time of products, not what the core is in.
> (The names like plat-samsung2 are not decided, just be used to explain our layout)
> 
> The plat-samsung2 and plat-samsung3 directories include common implementations for those groups, as you guess, mach-samsung2 and mach-samsung3 directories support board specific files.
> 
> Anyone has better idea?
> 
> We hope and need to discuss our ideas more and more, continuously, so tell us your opinions and something like this freely about this and, because s3c6410 supports is already in the mainline, we should handle this SoC specially.
> 
> Also we are considering the single binary compilation/operation for the same arm architecture.
> Finally, we should talk with Ben Dooks who is a maintainer of s3c24xx series, so hope Ben's reply especially :)
> 
> Thank you,
> --
> Jinsung, Yang <jsgood@samsung.com>
> Samsung Electronics, Co., Ltd.
> 
> _______________________________________________
> 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] 12+ messages in thread

* Discussion request for new Samsung SoCs maintaining
  2009-08-27 12:44 ` Bill Gatliff
@ 2009-08-28  3:19   ` Harald Welte
  2009-09-01 13:38   ` Russell King - ARM Linux
  2009-09-29  9:32   ` Ben Dooks
  2 siblings, 0 replies; 12+ messages in thread
From: Harald Welte @ 2009-08-28  3:19 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Bill,

On Thu, Aug 27, 2009 at 07:44:32AM -0500, Bill Gatliff wrote:
> Jinsung Yang wrote:
>> The second problem is that even though same family, the features like the
>> memory map and internal devices (IPs) are very different.  For example,
>> s5p6442 and s5pc110 have different arm core, but internal devices are very
>> similar. 
>>
>> Otherwise, although s5p6440 and s5p6442 are in the same family, architecture
>> and similar names, internal devices are very different.  It makes to be hard
>> to integrate codes in a same platform directory.
>
> The AT91 and AVR32 SoCs have the same problem: very different cores  
> (different instruction set architectures, actually), but compatible  
> peripherals.  Their solution has been to embrace the platform and other  
> device models heavily, which I think is the appropriate one.  I think  
> this approach will work for you as well.

I think the existing s3c (mainline and samsung tree) and s5p (samsung tree)
is already using the device model and platform devices quite extensively - much
due to Ben Dooks great work in that area.

All that is in the plat-X and are
* the actual platform devices for the various integrated peripherals (IPs)
* the clock structure
* dma support
* gpio support
* irq support
* core power management support

There are no real 'drivers' in those directories, at least unless you call the
DMA and VIC support a driver.

The actual drivers for the IPs are all in the driver/ directory, and they are
using different platform device names (in case of completely different hardware)
or platform_data to define which variant of an otherwise similar IP is used.

However, even in this core platform/arch code, there is a lot of copy+paste
going on if we extend the current model.  Samsung has a 2.6.29 derived kernel
branch that does this, and you will see many files that are copied from
plat-s5p64xx into plat-s5pc1xx, and later into plat-s5pc110.

I hope later today we can push that tree to git.kernel.org.  Anyone who's
interested can then look at it and see that it is far from being optimal.

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)

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Discussion request for new Samsung SoCs maintaining
  2009-08-27 13:14 ` Mark Brown
@ 2009-08-28  3:27   ` Harald Welte
  2009-08-28 12:45     ` Mark Brown
  0 siblings, 1 reply; 12+ messages in thread
From: Harald Welte @ 2009-08-28  3:27 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Mark, Jin-Sung and others,

On Thu, Aug 27, 2009 at 02:14:05PM +0100, Mark Brown wrote:

> > We hope and need to discuss our ideas more and more, continuously, so
> > tell us your opinions and something like this freely about this and,
> > because s3c6410 supports is already in the mainline, we should handle
> > this SoC specially.
> 
> It would seem to be much better to integrate your work with the existing
> support for your CPUs rather than starting from scratch - there's an
> awful lot of continuity in the IPs and it'd seem strange to ignore that.
> What are the factors that are pushing you towards starting from scratch?

Nobody is proposing to start from scratch, don't worry.  Right now the plan
is as follows:

1) compare samsungs latest (2.6.28 based) 6410 support and the mainline 6410
   support and determine missing bits (if any).  Submit those missing bits

2) compare driver support for 6410 in samsungs 2.6.28 based tree and current
   mainline.  Go over each driver, determine if
   a) mainline has no driver and samsungs driver will get polished+submitted
   b) mainline has a different version of the same driver. if there are missing
      features, submit them on top of what mainline has
   c) mainline ha a completely different driver.  Decide what to do on case-by-
      case basis.

In parallel to 1+2, we want to discuss and refine an actual structure for
future SoC's.  Once that is done,

3) work on migrating samsungs existing s5p6440, s5pc100, s5pc110 code to
   conform to the new naming/structure, regularly post this for review

4) eventually submit that code mainline, keeping <= 6410 as-is or only
   with minimal modifications.

5) work on the various existing and new device drivers, gradually submit
   them to the respective subsystem maintainers.

> 
> > Finally, we should talk with Ben Dooks who is a maintainer of s3c24xx
> > series, so hope Ben's reply especially :)
> 
> You probably want to CC him on messages like this - I've added him here.

I've already sent him a mail about a week ago about what's happening at Samsung
at the moment, so he should be generally aware.  But yes, explicit Cc is
still not a bad idea.

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Discussion request for new Samsung SoCs maintaining
  2009-08-27 13:57 ` David F. Carlson
@ 2009-08-28  3:34   ` Harald Welte
  0 siblings, 0 replies; 12+ messages in thread
From: Harald Welte @ 2009-08-28  3:34 UTC (permalink / raw)
  To: linux-arm-kernel

Hi David,

On Thu, Aug 27, 2009 at 09:57:04AM -0400, David F. Carlson wrote:
 
> I have been working with the 6410 tree in several places.  A merge of samsung
> tree would be greatly appreciated.

Thanks.  Please note that this work is just starting, and it is a learning
curve for most people inside the samsung soc linux team as they have not
participated in the mainline development process so far.  So it will probably
a slow but steady start.

Though the decision has been made, and they will work on this from now on
throughout the coming months.

> Please remember that since I am working SmartQ and there are 3 other 6410
> based MACHs in Ben's next-s3c tree.  
> 
> So, please, MACH_SMDK6410 != CPU_6410 and
>             MACH_SMDK6410 != PLAT_64XX.

Yes, this is a common accident/mistake in the current code.  We'll try to sort
them out before submitting patches for review.  But even if they persist, I'm
sure you or others will be happy to point those out at that time.

> The common peripheral support needs to be factored out so that "thin" MACH
> configs can set some per-MACH GPIOs/chipsets (LCD, power,etc.)

That sounds definitely useful, but it's probably another topic on its own.
Right now the aim is to get the code cleaned up and submitted.  Samsung is
only working/testing with the SMDK's.  Once more and more machines will get
mainline, there can probably be more code sharing among them.

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

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Discussion request for new Samsung SoCs maintaining
  2009-08-28  3:27   ` Harald Welte
@ 2009-08-28 12:45     ` Mark Brown
  0 siblings, 0 replies; 12+ messages in thread
From: Mark Brown @ 2009-08-28 12:45 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Aug 28, 2009 at 12:27:14PM +0900, Harald Welte wrote:
> Hi Mark, Jin-Sung and others,

> > It would seem to be much better to integrate your work with the existing
> > support for your CPUs rather than starting from scratch - there's an
> > awful lot of continuity in the IPs and it'd seem strange to ignore that.
> > What are the factors that are pushing you towards starting from scratch?

> Nobody is proposing to start from scratch, don't worry.  Right now the plan
> is as follows:

This all sounds a lot better than the original mail - like I said in my
reply it'd be good to describe anything in terms of how it relates to
the existing support rather than in greenfield terms.  It'd probably
make things a lot clearer, or more concrete at least.

> > > Finally, we should talk with Ben Dooks who is a maintainer of s3c24xx
> > > series, so hope Ben's reply especially :)

> > You probably want to CC him on messages like this - I've added him here.

> I've already sent him a mail about a week ago about what's happening at Samsung
> at the moment, so he should be generally aware.  But yes, explicit Cc is
> still not a bad idea.

I'd say it's very important to keep folks in the loop.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Discussion request for new Samsung SoCs maintaining
  2009-08-27 12:44 ` Bill Gatliff
  2009-08-28  3:19   ` Harald Welte
@ 2009-09-01 13:38   ` Russell King - ARM Linux
  2009-09-07 13:24     ` Kyungmin Park
  2009-09-29  9:32   ` Ben Dooks
  2 siblings, 1 reply; 12+ messages in thread
From: Russell King - ARM Linux @ 2009-09-01 13:38 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Aug 27, 2009 at 07:44:32AM -0500, Bill Gatliff wrote:
> I'm not sure I have any useful suggestion for this part.  It would have  
> been nice to have a "mach-a8" and "mach-arm11" for these situations,

A8 and ARM11 are CPU types and we already have a perfectly good
abstraction for these.  Should the Realview ARM11 end up in mach-arm11
and the Realview Cortex A8 end up in mach-a8?  Clearly, it's just
wrong.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Discussion request for new Samsung SoCs maintaining
  2009-09-01 13:38   ` Russell King - ARM Linux
@ 2009-09-07 13:24     ` Kyungmin Park
  2009-09-07 17:53       ` Peter Korsgaard
  0 siblings, 1 reply; 12+ messages in thread
From: Kyungmin Park @ 2009-09-07 13:24 UTC (permalink / raw)
  To: linux-arm-kernel

hi,

On Tue, Sep 1, 2009 at 10:38 PM, Russell King - ARM
Linux<linux@arm.linux.org.uk> wrote:
> On Thu, Aug 27, 2009 at 07:44:32AM -0500, Bill Gatliff wrote:
>> I'm not sure I have any useful suggestion for this part. ?It would have
>> been nice to have a "mach-a8" and "mach-arm11" for these situations,
>
> A8 and ARM11 are CPU types and we already have a perfectly good
> abstraction for these. ?Should the Realview ARM11 end up in mach-arm11
> and the Realview Cortex A8 end up in mach-a8? ?Clearly, it's just
> wrong.

How about to finish the this issues.
Even though Ben don't give any opinion, we have to decide how to add
next new SoCs and drivers.

First, decide the proper platform directory.
1. use the plat-s3c,
2. rename plat-samsung or
3. create new plat-samsung.

Second, who maintains the new SoCs?
1. maintain the all samsung SoCs as before by Ben
2. maintain s3c24xx and s3c64xx by Ben. others (s5pc1xx series) by Samsung.

Please give your opinions.

Thank you,
Kyungmin Park

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Discussion request for new Samsung SoCs maintaining
  2009-09-07 13:24     ` Kyungmin Park
@ 2009-09-07 17:53       ` Peter Korsgaard
  0 siblings, 0 replies; 12+ messages in thread
From: Peter Korsgaard @ 2009-09-07 17:53 UTC (permalink / raw)
  To: linux-arm-kernel

>>>>> "Kyungmin" == Kyungmin Park <kmpark@infradead.org> writes:

Hi,

 Kyungmin> How about to finish the this issues.
 Kyungmin> Even though Ben don't give any opinion, we have to decide how
 Kyungmin> to add next new SoCs and drivers.

 Kyungmin> First, decide the proper platform directory.
 Kyungmin> 1. use the plat-s3c,
 Kyungmin> 2. rename plat-samsung or
 Kyungmin> 3. create new plat-samsung.

Any real reason to not go with 1?

 Kyungmin> Second, who maintains the new SoCs?
 Kyungmin> 1. maintain the all samsung SoCs as before by Ben
 Kyungmin> 2. maintain s3c24xx and s3c64xx by Ben. others (s5pc1xx
 Kyungmin> series) by Samsung.

Unless Ben disagrees, I don't see why we shouldn't go for 1 here as
well?

-- 
Bye, Peter Korsgaard

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Discussion request for new Samsung SoCs maintaining
  2009-08-27 12:44 ` Bill Gatliff
  2009-08-28  3:19   ` Harald Welte
  2009-09-01 13:38   ` Russell King - ARM Linux
@ 2009-09-29  9:32   ` Ben Dooks
  2 siblings, 0 replies; 12+ messages in thread
From: Ben Dooks @ 2009-09-29  9:32 UTC (permalink / raw)
  To: linux-arm-kernel

Bill Gatliff wrote:
> Jinsung Yang wrote:
>> The second problem is that even though same family, the features like 
>> the memory map and internal devices (IPs) are very different.
>> For example, s5p6442 and s5pc110 have different arm core, but internal 
>> devices are very similar.
>> Otherwise, although s5p6440 and s5p6442 are in the same family, 
>> architecture and similar names, internal devices are very different.
>> It makes to be hard to integrate codes in a same platform directory.
[snip]
> 
> The AT91 and AVR32 SoCs have the same problem: very different cores 
> (different instruction set architectures, actually), but compatible 
> peripherals.  Their solution has been to embrace the platform and other 
> device models heavily, which I think is the appropriate one.  I think 
> this approach will work for you as well.
> 
>> So that, we are considering the following platform structure to manage 
>> our new SoCs.
>>   
> 
> Wow, your naming situation is... messed up.  :)
> 
> I'm not sure I have any useful suggestion for this part.  It would have 
> been nice to have a "mach-a8" and "mach-arm11" for these situations, but 
> we don't and I'm not sure it wouldn't cause even more problems to create 
> them.

This won't work, the processor core is pretty much independent of what goes
around it. There are parts which are very similar apart from the choice of
the ARM core in use. We try and group together the similar IP blocks that
go together to make up the chip.


-- 
Ben Dooks, Software Engineer, Simtec Electronics

http://www.simtec.co.uk/

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2009-09-29  9:32 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-27 11:06 Discussion request for new Samsung SoCs maintaining Jinsung Yang
2009-08-27 12:44 ` Bill Gatliff
2009-08-28  3:19   ` Harald Welte
2009-09-01 13:38   ` Russell King - ARM Linux
2009-09-07 13:24     ` Kyungmin Park
2009-09-07 17:53       ` Peter Korsgaard
2009-09-29  9:32   ` Ben Dooks
2009-08-27 13:14 ` Mark Brown
2009-08-28  3:27   ` Harald Welte
2009-08-28 12:45     ` Mark Brown
2009-08-27 13:57 ` David F. Carlson
2009-08-28  3:34   ` Harald Welte

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.