All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Ungerer <gerg@snapgear.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-m68k@vger.kernel.org, uclinux-dev@uclinux.org,
	Greg Ungerer <gerg@uclinux.org>
Subject: Re: [PATCH 06/36] m68k: modify user space access functions to support ColdFire CPUs
Date: Mon, 31 Oct 2011 15:03:12 +1000	[thread overview]
Message-ID: <4EAE2C10.5050908@snapgear.com> (raw)
In-Reply-To: <CAMuHMdVRvncpVWNa+2EUybv3+v+3PzQ4R_7-sqV71pVqQ67qoQ@mail.gmail.com>

Hi Geert,

On 30/10/11 23:02, Geert Uytterhoeven wrote:
> On Tue, Oct 25, 2011 at 09:18,<gerg@snapgear.com>  wrote:
>> From: Greg Ungerer<gerg@uclinux.org>
>>
>> Modify the user space access functions to support the ColdFire V4e cores
>> running with MMU enabled.
>>
>> The ColdFire processors do not support the "moves" instruction used by
>> the traditional 680x0 processors for moving data into and out of another
>> address space. They only support the notion of a single address space,
>> and you use the usual "move" instruction to access that.
>>
>> I am interrested in what others think if this approach. It is a little
>> ugly, but it does mean that the same code is used, not a complete
>> duplicate that is almost the same except for the "moves" instructions.
>> It does also mean in this form that it is an either/or compile. It
>> can't support both ColdFire and 680x0 in the same binary as it is.
>>
>> Signed-off-by: Greg Ungerer<gerg@uclinux.org>
>
>> +#ifdef CONFIG_COLDFIRE
>> +/*
>> + * The ColdFire processors do not support the moves instruction used by
>> + * the traditional 680x0 processors for moving data into and out of
>> + * another address space. They only support the notion of a single address
>> + * space, and you use the usual move instruction to access that.
>> + *
>> + * All the user space access functions are otherwise the same on ColdFire
>> + * as the other 680x0 processors. So lets keep the code simple and just
>> + * define in what we need to use.
>> + */
>> +#define	MOVES	"move"
>> +#else
>> +#define	MOVES	"moves"
>> +#endif /* CONFIG_COLDFIRE */
>
> I did the same thing originally when trying to get uClinux running on
> MMU-less Amigas, so it's fine for me.
>
> If I'm not mistaken, this will also make it easier to merge uaccess.h again in
> the long run, as the version with "move" should work on all MMU-less
> platforms, right?

Yes, very good point. I hadn't even considered then when I was trying
to make this work. Another good reason to go with it :-)

Regards
Greg


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

  reply	other threads:[~2011-10-31  5:02 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-25  7:18 [PATCH 00/36] m68k: ColdFire MMU support gerg
2011-10-25  7:18 ` [PATCH 01/36] m68k: add machine and CPU definitions for ColdFire cores gerg
2011-10-25  7:18 ` [PATCH 02/36] m68k: show ColdFire CPU/FPU/MMU type gerg
2011-10-25  7:18 ` [PATCH 03/36] m68k: definitions for the ColdFire V4e MMU hardware gerg
2011-10-25  7:18 ` [PATCH 04/36] m68k: make old interrupt code conditional on correct CPU types gerg
2011-10-25  7:18 ` [PATCH 05/36] m68k: add TASK definitions for ColdFires running with MMU gerg
2011-10-25  7:18 ` [PATCH 06/36] m68k: modify user space access functions to support ColdFire CPUs gerg
2011-10-30 13:02   ` Geert Uytterhoeven
2011-10-31  5:03     ` Greg Ungerer [this message]
2011-10-25  7:18 ` [PATCH 07/36] m68k: add ColdFire 54xx CPU MMU memory init code gerg
2011-10-25  7:19 ` [PATCH 08/36] m68k: init the MMU hardware for the 54xx ColdFire gerg
2011-10-25  7:19 ` [PATCH 09/36] m68k: set register a2 to current if MMU enabled on ColdFire gerg
2011-10-30 13:06   ` Geert Uytterhoeven
2011-10-31  4:19     ` Greg Ungerer
2011-10-25  7:19 ` [PATCH 10/36] m68k: page table support definitions and code for ColdFire MMU gerg
2011-10-30 13:07   ` Geert Uytterhoeven
2011-10-25  7:19 ` [PATCH 11/36] m68k: add page table size definitions for ColdFire V4e MMU gerg
2011-10-25  7:19 ` [PATCH 12/36] m68k: add ColdFire paging exception handling code gerg
2011-10-25  7:19 ` [PATCH 13/36] m68k: add cache support for V4e ColdFire cores running with MMU enabled gerg
2011-10-25  7:19 ` [PATCH 14/36] m68k: modify ColdFire 54xx cache support for " gerg
2011-10-25  7:19 ` [PATCH 15/36] m68k: add TLB flush support for the ColdFire V4e MMU hardware gerg
2011-10-30 13:26   ` Geert Uytterhoeven
2011-10-25  7:19 ` [PATCH 16/36] m68k: set ColdFire MMU page size gerg
2011-10-30 13:29   ` Geert Uytterhoeven
2011-10-31  4:41     ` Greg Ungerer
2011-10-25  7:19 ` [PATCH 17/36] m68k: ColdFire with MMU does not support separate address spaces gerg
2011-10-25  7:19 ` [PATCH 18/36] m68k: ColdFire V4e MMU context support code gerg
2011-10-25  7:19 ` [PATCH 19/36] m68k: use tracehook_report_syscall_entry/exit for ColdFire MMU ptrace path gerg
2011-10-25  7:19 ` [PATCH 20/36] m68k: ColdFire with MMU needs simpler lib checksum code gerg
2011-10-25  7:19 ` [PATCH 21/36] m68k: modify cache push and clear code for ColdFire with MMU enable gerg
2011-10-25  7:19 ` [PATCH 22/36] m68k: use ColdFire V4e MMU flags when ioremapping() gerg
2011-10-25  7:19 ` [PATCH 23/36] m68k: ColdFire V4e MMU paginit init code and miss handler gerg
2011-10-30 15:56   ` Finn Thain
2011-10-31  4:46     ` Greg Ungerer
2011-10-25  7:19 ` [PATCH 24/36] m68k: compile appropriate mm arch files for ColdFire V4e MMU support gerg
2011-10-30 13:46   ` Geert Uytterhoeven
2011-10-31  5:39     ` Greg Ungerer
2011-10-25  7:19 ` [PATCH 25/36] m68k: create ColdFire MMU pgalloc code gerg
2011-10-25  7:19 ` [PATCH 26/36] m68k: use non-MMU entry.S code when compiling for ColdFire CPU gerg
2011-10-25  7:19 ` [PATCH 27/36] m68k: add code to setup a ColdFire 54xx platform when MMU enabled gerg
2011-10-30 13:39   ` Geert Uytterhoeven
2011-10-31  4:59     ` Greg Ungerer
2011-10-25  7:19 ` [PATCH 28/36] m68k: ColdFire with MMU enabled uses same clocking code as non-MMU gerg
2011-10-25  7:19 ` [PATCH 29/36] m68k: use non-MMU linker script for ColdFire MMU builds gerg
2011-10-25  7:19 ` [PATCH 30/36] m68k: adjustments to stack frame for ColdFire with MMU enabled gerg
2011-10-25  7:19 ` [PATCH 31/36] m68k: completely disable FPU support for ColdFire gerg
2011-10-30 15:56   ` Finn Thain
2011-10-25  7:19 ` [PATCH 32/36] m68k: use new style interrupt handling for ColdFire with MMU enabled gerg
2011-10-25  7:19 ` [PATCH 33/36] m68k: define a ack_bad_irq() function for ColdFire with MMU gerg
2011-10-25  7:19 ` [PATCH 34/36] m68k: add ColdFire with MMU enabled support to the m68k mem init code gerg
2011-10-25  7:19 ` [PATCH 35/36] m68k: config option adjustments for configuring ColdFire with MMU gerg
2011-10-30 13:42   ` Geert Uytterhoeven
2011-10-25  7:19 ` [PATCH 36/36] m68k: allow ColdFire 547x and 548x CPUs to be built with MMU enabled gerg
2011-10-30 13:47 ` [PATCH 00/36] m68k: ColdFire MMU support Geert Uytterhoeven
2011-10-31  5:46   ` Greg Ungerer

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=4EAE2C10.5050908@snapgear.com \
    --to=gerg@snapgear.com \
    --cc=geert@linux-m68k.org \
    --cc=gerg@uclinux.org \
    --cc=linux-m68k@vger.kernel.org \
    --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.