public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Jonas Bonn <jonas@southpole.se>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 03/19] OpenRISC: Memory management
Date: Sun, 19 Jun 2011 20:35:05 +0200	[thread overview]
Message-ID: <201106192035.06133.arnd@arndb.de> (raw)
In-Reply-To: <1308483825-6023-4-git-send-email-jonas@southpole.se>

On Sunday 19 June 2011 13:43:29 Jonas Bonn wrote:

> +#define FIXADDR_TOP	((unsigned long) (-2*PAGE_SIZE))
> +
> +#include <linux/kernel.h>
> +#include <linux/threads.h>
> +#include <asm/page.h>
> +
> +/*
> + * Here we define all the compile-time 'special' virtual
> + * addresses. The point is to have a constant address at
> + * compile time, but to set the physical address only
> + * in the boot process. We allocate these special addresses
> + * from the end of virtual memory (0xffffb000) backwards.
> + *
> + * Also this would let us do fail-safe vmalloc(), we
> + * can guarantee that these special addresses and
> + * vmalloc()-ed addresses never overlap.  We don't actually
> + * do this on OpenRISC though (nor do most other arch's).
> + *
> + * these 'compile-time allocated' memory buffers are
> + * fixed-size (PAGE_SIZE) pages. (or larger if used with an increment
> + * highger than 1) use fixmap_set(idx,phys) to associate
> + * physical memory with fixmap indices.
> + *
> + * TLB entries of such buffers will not be flushed across
> + * task switches.
> + */
> +enum fixed_addresses {
> +	/*
> +	 * FIX_IOREMAP entries are useful for mapping physical address
> +	 * space before ioremap() is useable, e.g. really early in boot
> +	 * before kmalloc() is working.
> +	 */
> +#define FIX_N_IOREMAPS  32
> +	FIX_IOREMAP_BEGIN,
> +	FIX_IOREMAP_END = FIX_IOREMAP_BEGIN + FIX_N_IOREMAPS - 1,
> +	__end_of_fixed_addresses
> +};


What is this actually needed for? I know that there are a few architectures
that have this, but I couldn't find any users of fixmap_set in your code.

If you don't use it, it's probably better to remove the code. Otherwise,
would it be possible to generalize it enough to merge the code with the
x86 and tile implementations and move it into mm/fixmap.c and/or
include/asm-generix/fixmap.h?

> +
> +extern int mem_init_done;

Move this to a header file, too.

> +/*
> + * OR1K has no port-mapped IO, only MMIO
> + */
> +void __iomem *ioport_map(unsigned long port, unsigned int len)
> +{
> +	BUG();
> +}
> +
> +void ioport_unmap(void __iomem *addr)
> +{
> +	BUG();
> +}

If you don't have port-mapped I/O, you cannot have PCI, so you should
remove the option to enable PCI from Kconfig.

If you actually support PCI, you should implement ioport_map to point
to the memory-mapped location of PCI I/O space window.

	Arnd

  reply	other threads:[~2011-06-19 18:35 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-19 11:43 OpenRISC Architecture: Request for review Jonas Bonn
2011-06-19 11:43 ` [PATCH 01/19] OpenRISC: Boot code Jonas Bonn
2011-06-19 17:14   ` Arnd Bergmann
2011-06-19 11:43 ` [PATCH 02/19] OpenRISC: Device tree Jonas Bonn
2011-06-19 17:19   ` Arnd Bergmann
2011-06-19 11:43 ` [PATCH 03/19] OpenRISC: Memory management Jonas Bonn
2011-06-19 18:35   ` Arnd Bergmann [this message]
2011-06-19 11:43 ` [PATCH 04/19] OpenRISC: Signal handling Jonas Bonn
2011-06-19 11:43 ` [PATCH 05/19] OpenRISC: Build infrastructure Jonas Bonn
2011-06-19 18:57   ` Arnd Bergmann
2011-06-19 11:43 ` [PATCH 06/19] OpenRISC: PTrace Jonas Bonn
2011-06-19 11:43 ` [PATCH 07/19] OpenRISC: DMA Jonas Bonn
2011-06-19 19:02   ` Arnd Bergmann
2011-06-19 11:43 ` [PATCH 08/19] OpenRISC: Timekeeping Jonas Bonn
2011-06-19 19:06   ` Arnd Bergmann
2011-06-19 11:43 ` [PATCH 09/19] OpenRISC: IRQ Jonas Bonn
2011-06-19 19:09   ` Arnd Bergmann
2011-06-19 11:43 ` [PATCH 10/19] OpenRISC: System calls Jonas Bonn
2011-06-19 15:09   ` richard -rw- weinberger
2011-06-19 15:51     ` Jonas Bonn
2011-06-19 21:11       ` Andi Kleen
2011-06-19 11:43 ` [PATCH 11/19] OpenRISC: Idle/Power management Jonas Bonn
2011-06-20  8:20   ` Arnd Bergmann
2011-06-19 11:43 ` [PATCH 12/19] OpenRISC: Scheduling/Process management Jonas Bonn
2011-06-19 19:12   ` Arnd Bergmann
2011-06-19 21:17   ` Andi Kleen
2011-06-19 11:43 ` [PATCH 13/19] OpenRISC: GPIO Jonas Bonn
2011-06-19 11:43 ` [PATCH 14/19] OpenRISC: Module support Jonas Bonn
2011-06-21 20:03   ` Valdis.Kletnieks
2011-06-22 14:26     ` Arnd Bergmann
2011-06-22 19:08       ` [PATCH 1/1] Add default implementations for moduleloader hooks Jonas Bonn
2011-06-22 19:14       ` [PATCH 14/19] OpenRISC: Module support Jonas Bonn
2011-06-22 19:58         ` Arnd Bergmann
2011-06-22 20:05           ` Jonas Bonn
2011-06-22 20:46             ` Arnd Bergmann
2011-06-24  8:52       ` Jonas Bonn
2011-06-24 10:05         ` Arnd Bergmann
2011-06-24 11:06           ` Rusty Russell
2011-06-19 11:43 ` [PATCH 15/19] OpenRISC: Traps Jonas Bonn
2011-06-19 11:43 ` [PATCH 16/19] OpenRISC: Headers Jonas Bonn
2011-06-19 19:39   ` Arnd Bergmann
2011-06-19 19:43     ` Arnd Bergmann
2011-06-19 20:19   ` Geert Uytterhoeven
2011-06-19 11:43 ` [PATCH 17/19] OpenRISC: Library routines Jonas Bonn
2011-06-19 11:43 ` [PATCH 18/19] OpenRISC: Miscellaneous Jonas Bonn
2011-06-19 11:43 ` [PATCH 19/19] OpenRISC: Add MAINTAINERS entry Jonas Bonn
2011-06-19 17:06 ` OpenRISC Architecture: Request for review Arnd Bergmann
2011-06-22 21:23 ` H. Peter Anvin
2011-06-23  9:10   ` Jonas Bonn
2011-06-23  9:54     ` Julius Baxter

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=201106192035.06133.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=jonas@southpole.se \
    --cc=linux-kernel@vger.kernel.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