All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
Date: Tue, 26 Feb 2013 10:18:28 +0000	[thread overview]
Message-ID: <201302261018.28463.arnd@arndb.de> (raw)
In-Reply-To: <CANqRtoSU9xqhTCv31CskYN8bu4H7gwz93fQcvuyLQx=hdRk2MA@mail.gmail.com>

On Monday 25 February 2013, Magnus Damm wrote:
> For mach-shmobile the three major components that rely on entity
> mapped memory maps are SMP, clocks and power domains. The clocks
> should really be moved in the common direction and I intend to get
> people to focus on that in the not too distant future (next 6 months).
> Power domains should be rather easy to convert. SMP tends to be a bit
> of a headache because last time I checked I couldn't use ioremap() at
> ->smp_init_cpus() time. What I recall is that ioremap() hanged instead
> of returning something.
> 
> Anyway, if I track down the ioremap() issue, would it be possible for
> you to check if it can be reproduced on some other sub-architecture?

You are right that ioremap cannot be used from ->smp_init_cpus() and any
code called from there needs to use a static mapping for accessing
MMIO registers. There is nothing wrong with that. There are in fact
three distinct reasons why people use static MMIO mappings with
iotable_init():

1. For MMIO registers that need to be accessed before ioremap works.
   This usually means the SMP startup and the early printk (which I
   believe shmobile is not using).

2. For getting hugetlb mappings of MMIO registers into the kernel
   address space. If you have a lot of registers in the same area,
   using a single TLB to map them is more efficient, even when 
   accessing the registers through ioremap from a device driver.

3. For hardcoding the virtual address to a location that is passed
   to device drivers as compile-time constants.

The first two are absolutely fine, there are no objections to those.
The third one is tradtitionally used on a lot of the older platforms,
but with the multiplatform work, we are moving away from it, towards
passing resources in the platform device (ideally from DT, but that
is an orthogonal question here). AFAICT, shmobile is the only "modern"
platform that still relies on fixed virtual addresses, and it is the
only one I know that uses a mapping where the virtual address equals
the physical address.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
Date: Tue, 26 Feb 2013 10:18:28 +0000	[thread overview]
Message-ID: <201302261018.28463.arnd@arndb.de> (raw)
In-Reply-To: <CANqRtoSU9xqhTCv31CskYN8bu4H7gwz93fQcvuyLQx=hdRk2MA@mail.gmail.com>

On Monday 25 February 2013, Magnus Damm wrote:
> For mach-shmobile the three major components that rely on entity
> mapped memory maps are SMP, clocks and power domains. The clocks
> should really be moved in the common direction and I intend to get
> people to focus on that in the not too distant future (next 6 months).
> Power domains should be rather easy to convert. SMP tends to be a bit
> of a headache because last time I checked I couldn't use ioremap() at
> ->smp_init_cpus() time. What I recall is that ioremap() hanged instead
> of returning something.
> 
> Anyway, if I track down the ioremap() issue, would it be possible for
> you to check if it can be reproduced on some other sub-architecture?

You are right that ioremap cannot be used from ->smp_init_cpus() and any
code called from there needs to use a static mapping for accessing
MMIO registers. There is nothing wrong with that. There are in fact
three distinct reasons why people use static MMIO mappings with
iotable_init():

1. For MMIO registers that need to be accessed before ioremap works.
   This usually means the SMP startup and the early printk (which I
   believe shmobile is not using).

2. For getting hugetlb mappings of MMIO registers into the kernel
   address space. If you have a lot of registers in the same area,
   using a single TLB to map them is more efficient, even when 
   accessing the registers through ioremap from a device driver.

3. For hardcoding the virtual address to a location that is passed
   to device drivers as compile-time constants.

The first two are absolutely fine, there are no objections to those.
The third one is tradtitionally used on a lot of the older platforms,
but with the multiplatform work, we are moving away from it, towards
passing resources in the platform device (ideally from DT, but that
is an orthogonal question here). AFAICT, shmobile is the only "modern"
platform that still relies on fixed virtual addresses, and it is the
only one I know that uses a mapping where the virtual address equals
the physical address.

	Arnd

  reply	other threads:[~2013-02-26 10:18 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-18 13:46 [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2 Magnus Damm
2013-02-18 13:46 ` Magnus Damm
2013-02-18 13:46 ` [PATCH 01/08] ARM: shmobile: Fix base address readout in headsmp-scu.S Magnus Damm
2013-02-18 13:46   ` Magnus Damm
2013-02-18 14:57   ` Bastian Hecht
2013-02-18 14:57     ` Bastian Hecht
2013-02-18 13:47 ` [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage Magnus Damm
2013-02-18 13:47   ` Magnus Damm
2013-02-18 14:39   ` Arnd Bergmann
2013-02-18 14:39     ` Arnd Bergmann
2013-02-18 14:44     ` Arnd Bergmann
2013-02-18 14:44       ` Arnd Bergmann
2013-02-25 14:30       ` Magnus Damm
2013-02-25 14:30         ` Magnus Damm
2013-02-26 10:18         ` Arnd Bergmann [this message]
2013-02-26 10:18           ` Arnd Bergmann
2013-02-26 15:20           ` Magnus Damm
2013-02-26 15:20             ` Magnus Damm
2013-02-26 16:12             ` Arnd Bergmann
2013-02-26 16:12               ` Arnd Bergmann
2013-03-06  7:15               ` Magnus Damm
2013-03-06  7:15                 ` Magnus Damm
2013-02-18 13:47 ` [PATCH 03/08] ARM: shmobile: Use R8A7779_SCU_BASE with TWD Magnus Damm
2013-02-18 13:47   ` Magnus Damm
2013-02-18 13:47 ` [PATCH 04/08] ARM: shmobile: Update r8a7779 to check SCU for hotplug Magnus Damm
2013-02-18 13:47   ` Magnus Damm
2013-02-18 13:47 ` [PATCH 05/08] ARM: shmobile: Update r8a7779 to use scu_power_mode() Magnus Damm
2013-02-18 13:47   ` Magnus Damm
2013-02-18 13:47 ` [PATCH 06/08] ARM: shmobile: Use sh73a0-specific cpu disable code Magnus Damm
2013-02-18 13:47   ` Magnus Damm
2013-02-18 13:47 ` [PATCH 07/08] ARM: shmobile: Rearrange r8a7779 cpu hotplug code Magnus Damm
2013-02-18 13:47   ` Magnus Damm
2013-02-18 13:48 ` [PATCH 08/08] ARM: shmobile: Remove unused hotplug.c Magnus Damm
2013-02-18 13:48   ` Magnus Damm
2013-02-19  0:49 ` [PATCH 00/08] ARM: shmobile: CPU Hotplug and SMP CA9 SCU rework part 2 Simon Horman
2013-02-19  0:49   ` Simon Horman
2013-02-19 10:09   ` Magnus Damm
2013-02-19 10:09     ` Magnus Damm
2013-02-26  8:53     ` Simon Horman
2013-02-26  8:53       ` Simon Horman
2013-03-27  6:42 ` Magnus Damm
2013-03-27  8:45 ` Simon Horman
2013-03-27  8:53 ` Magnus Damm
2013-03-27 10:57 ` Simon Horman
2013-03-27 14:58 ` Magnus Damm
2013-03-28  0:17 ` Simon Horman

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=201302261018.28463.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.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.