All of lore.kernel.org
 help / color / mirror / Atom feed
From: Magnus Damm <magnus.damm@gmail.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
Date: Mon, 25 Feb 2013 14:30:58 +0000	[thread overview]
Message-ID: <CANqRtoSU9xqhTCv31CskYN8bu4H7gwz93fQcvuyLQx=hdRk2MA@mail.gmail.com> (raw)
In-Reply-To: <201302181444.21717.arnd@arndb.de>

On Mon, Feb 18, 2013 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 18 February 2013, Arnd Bergmann wrote:
>> Ok, this gets rid of the warning, but I'm a bit worried about
>> how it is hardwiring the fact that the SCU physical address has
>> the same bit pattern as the __iomem token.
>>
>> While I realize that you already rely on this in a lot of places
>> in the shmobile code, I see a red light going off every time I read
>> code like this, and it is not any more logical than the previous
>> version.
>>
>> It would be nice to keep these address spaces separate at least
>> in new code, mostly in order to not confuse reviewers with code
>> that is based on assumptions which are not generally true, but also
>> to be more flexible with the virtual memory layout. On a related
>> topic, you are using an entire 256 MB section of your virtual
>> address space for sh73a0 and sh7372 and 160 MB for r8a7740. Putting
>> less of that into the identity mapped area would free up space for
>> vmalloc, but it's hard to prove that doing this is correct when
>> you have all sorts of code using a hardcoded virtual MMIO address
>> token.
>
> To clarify my rant: I'm absolutely fine with this code going in
> for now, but I'd like to see a long-term plan about what to do
> with the hardcoded virtual address hacks.

Thanks for the clarification.

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?

Thanks,

/ magnus

WARNING: multiple messages have this Message-ID (diff)
From: magnus.damm@gmail.com (Magnus Damm)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/08] ARM: shmobile: Rework SH73A0_SCU_BASE IOMEM() usage
Date: Mon, 25 Feb 2013 23:30:58 +0900	[thread overview]
Message-ID: <CANqRtoSU9xqhTCv31CskYN8bu4H7gwz93fQcvuyLQx=hdRk2MA@mail.gmail.com> (raw)
In-Reply-To: <201302181444.21717.arnd@arndb.de>

On Mon, Feb 18, 2013 at 11:44 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 18 February 2013, Arnd Bergmann wrote:
>> Ok, this gets rid of the warning, but I'm a bit worried about
>> how it is hardwiring the fact that the SCU physical address has
>> the same bit pattern as the __iomem token.
>>
>> While I realize that you already rely on this in a lot of places
>> in the shmobile code, I see a red light going off every time I read
>> code like this, and it is not any more logical than the previous
>> version.
>>
>> It would be nice to keep these address spaces separate at least
>> in new code, mostly in order to not confuse reviewers with code
>> that is based on assumptions which are not generally true, but also
>> to be more flexible with the virtual memory layout. On a related
>> topic, you are using an entire 256 MB section of your virtual
>> address space for sh73a0 and sh7372 and 160 MB for r8a7740. Putting
>> less of that into the identity mapped area would free up space for
>> vmalloc, but it's hard to prove that doing this is correct when
>> you have all sorts of code using a hardcoded virtual MMIO address
>> token.
>
> To clarify my rant: I'm absolutely fine with this code going in
> for now, but I'd like to see a long-term plan about what to do
> with the hardcoded virtual address hacks.

Thanks for the clarification.

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?

Thanks,

/ magnus

  reply	other threads:[~2013-02-25 14:30 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 [this message]
2013-02-25 14:30         ` Magnus Damm
2013-02-26 10:18         ` Arnd Bergmann
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='CANqRtoSU9xqhTCv31CskYN8bu4H7gwz93fQcvuyLQx=hdRk2MA@mail.gmail.com' \
    --to=magnus.damm@gmail.com \
    --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.