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
prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox