All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Ungerer <gerg@snapgear.com>
To: Luis Alves <ljalvs@gmail.com>
Cc: linux-m68k@vger.kernel.org, uclinux-dev@uclinux.org, gerg@uclinux.org
Subject: Re: [PATCH 1/1] Changes for 68000 code integration.
Date: Sat, 28 Apr 2012 23:02:02 +1000	[thread overview]
Message-ID: <4F9BEA4A.8090802@snapgear.com> (raw)
In-Reply-To: <CAGj5WxBNxkXdS8atb-WVwWR5QLWPS6wreDnmpwaZLa=PzE6cNw@mail.gmail.com>

Hi Luis,

On 04/28/2012 12:30 AM, Luis Alves wrote:
> On Fri, Apr 27, 2012 at 3:06 PM, Greg Ungerer<gerg@snapgear.com>  wrote:
>> On 04/27/2012 09:08 AM, Luis Alves wrote:
>>> This is the first of a pack of patches to support the original 68000 cpu.
>>> This adds:
>>> á-MC68000 cpu as a choice in the config menu.
>>> á-Alcetronics M68K board (uses this cpu).
>>>
>>> What I have changed:
>>> á-CONFIG_M68000 was being used by 68328 CPUs.
>>> á Renamed to CONFIG_M68XXX. Now the 68000 and all CPU32 CPUs use this flag
>>> for common configurations.
>>> á-Modified all 68[VZ|EZ]328 to select CONFIG_MCPU32
>>> á-Modified CONFIG_MCPU32 to select CONFIG_M68XXX.
>>> á-Modified CONFIG_M68360 to select CONFIG_M68XXX (I think it was missing
>>> some settings).
>>> á-Modified some files to use CONFIG_M68XXX instead of
>>> CONFIG_M68000/CONFIG_MCPU32
>>
>>
>> Thinking on this a little more, you probably don't want most of
>> these changes. Certainly as Brad points out CPU32 and 68000 are
>> quite different, and they need to remain as separate config options.
>>
>> I can see you will end up with a arch/m68k/platform/68000 with
>> some new code. Is any of that common with what is currently in
>> arch/m68k/platform/68328? áI would expect we want to move the
>> common 68000 code into that platform/68000 directory. Longer
>> term we may want to do away with 68328/68EZ328/68VZ328 directories
>> all together. All the code may go in a platform/68000. (Still
>> thinking this one over though, but I am planning on doing away
>> with the separate 5xxx ColdFire directories real soon now).
>>
>
> I think this is a good idea. Do you suggest putting all together in the
> same file and use #ifdef's for cpu specific options? I could do that.

That may or may not make sense, we need to think about each case.
Hopefully we can keep common code together with minimal additional
#ifdefs. And put board (or on/off chip peripherals) in there own
files.


> Also, how to deal with board specific configuration files?
> As I referred in the previous mail, the 68000 has zero on-chip peripherals
> so the initial setup and configuration is a lot 'board-dependent'.

Yep. The best case is if you have specific configuration files
separate, and built based on their appropriate defines in the Makefile.
(See examples in arch/m68k/platform/coldfire/Makefile).

To start I would just put them all in the common 68000 sub-directory.
If the need arises we can start putting machine specific sub-directories
later (which is what we have at the top arch level, arch/m68k/). For
quite a few years we had machine specific directories under
platform/coldfire. But I gave up on it eventually - there was just so
much duplicated code it didn't seem to make any sense.

Regards
Greg



------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
8 Gardner Close,                            FAX:         +61 7 3891 3630
Milton, QLD, 4064, Australia                WEB: http://www.SnapGear.com

      reply	other threads:[~2012-04-28 13:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <MC68000 integration>
2012-04-26 23:08 ` [PATCH 1/1] Changes for 68000 code integration Luis Alves
2012-04-27  6:43   ` Greg Ungerer
2012-04-27  6:55     ` Geert Uytterhoeven
2012-04-27  7:33   ` Brad Boyer
     [not found]     ` <CAGj5WxDCYXOX9Jw2zRxxb0NBJnnKkQTWj03FeY+u35EsfuiHjQ@mail.gmail.com>
2012-04-27 14:16       ` Luis Alves
2012-04-27 14:06   ` Greg Ungerer
2012-04-27 14:30     ` Luis Alves
2012-04-28 13:02       ` Greg Ungerer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F9BEA4A.8090802@snapgear.com \
    --to=gerg@snapgear.com \
    --cc=gerg@uclinux.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=ljalvs@gmail.com \
    --cc=uclinux-dev@uclinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.