From: Leif Lindholm <leif.lindholm@linaro.org>
To: Mark Salter <msalter@redhat.com>
Cc: Will Deacon <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"grant.likely@secretlab.ca" <grant.likely@secretlab.ca>,
"linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"patches@linaro.org" <patches@linaro.org>,
"roy.franz@linaro.org" <roy.franz@linaro.org>,
"matt.fleming@intel.com" <matt.fleming@intel.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 2/5] arm: add new asm macro update_sctlr
Date: Thu, 30 Jan 2014 13:12:47 +0000 [thread overview]
Message-ID: <20140130131247.GG11329@bivouac.eciton.net> (raw)
In-Reply-To: <1391029124.2488.50.camel@deneb.redhat.com>
On Wed, Jan 29, 2014 at 03:58:44PM -0500, Mark Salter wrote:
> > (i.e. conditionalise on whether an optional parameter was provided),
> > so my attempt of refactoring actually ends up using an additional
> > register:
> >
>
> Register parameters are just strings, so how about this:
>
> .macro foo bar=, baz=
> .ifnc \bar,
> mov \bar,#0
> .endif
> .ifnc \baz,
> mov \baz,#1
> .endif
> .endm
>
> foo x0
> foo
> foo x1, x2
> foo ,x3
>
> Results in:
>
> 0000000000000000 <.text>:
> 0: d2800000 mov x0, #0x0 // #0
> 4: d2800001 mov x1, #0x0 // #0
> 8: d2800022 mov x2, #0x1 // #1
> c: d2800023 mov x3, #0x1 // #1
Oh, that's neat - thanks!
Well, given that, I can think of two less horrible options:
1)
.macro update_sctlr, tmp:req, set=, clear=
mrc p15, 0, \tmp, c1, c0, 0
.ifnc \set,
orr \tmp, \set
.endif
.ifnc \clear,
mvn \clear, \clear
and \tmp, \tmp, \clear
.endif
mcr p15, 0, \tmp, c1, c0, 0
.endm
With the two call sites in uefi_phys.S as:
ldr r5, =(CR_M)
update_sctlr r12, , r5
and
ldr r4, =(CR_I | CR_C | CR_M)
update_sctlr r12, r4
Which disassembles as:
2c: e3a05001 mov r5, #1
30: ee11cf10 mrc 15, 0, ip, cr1, cr0, {0}
34: e1e05005 mvn r5, r5
38: e00cc005 and ip, ip, r5
3c: ee01cf10 mcr 15, 0, ip, cr1, cr0, {0}
and
48: e59f4034 ldr r4, [pc, #52] ; 84 <tmpstack+0x4>
4c: ee11cf10 mrc 15, 0, ip, cr1, cr0, {0}
50: e18cc004 orr ip, ip, r4
54: ee01cf10 mcr 15, 0, ip, cr1, cr0, {0}
2)
.macro update_sctlr, tmp:req, tmp2:req, set=, clear=
mrc p15, 0, \tmp, c1, c0, 0
.ifnc \set,
ldr \tmp2, =\set
orr \tmp, \tmp, \tmp2
.endif
.ifnc \clear,
ldr \tmp2, =\clear
mvn \tmp2, \tmp2
and \tmp, \tmp, \tmp2
.endif
mcr p15, 0, \tmp, c1, c0, 0
.endm
With the two call sites in uefi_phys.S as:
update_sctlr r4, r5, , (CR_M)
and
update_sctlr r4, r5, (CR_I | CR_C | CR_M)
Which disassembles as:
2c: ee114f10 mrc 15, 0, r4, cr1, cr0, {0}
30: e3a05001 mov r5, #1
34: e1e05005 mvn r5, r5
38: e0044005 and r4, r4, r5
3c: ee014f10 mcr 15, 0, r4, cr1, cr0, {0}
and
48: ee114f10 mrc 15, 0, r4, cr1, cr0, {0}
4c: e59f5030 ldr r5, [pc, #48] ; 84 <tmpstack+0x4>
50: e1844005 orr r4, r4, r5
54: ee014f10 mcr 15, 0, r4, cr1, cr0, {0}
The benefit of 2) is a cleaner call site, and one fewer register
used if setting and clearing simultaneously.
The benefit of 1) is that the macro could then easily be used with
the crval mask in mm/proc*.S
So, Will, which one do you want?
/
Leif
next prev parent reply other threads:[~2014-01-30 13:11 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-11 13:05 [PATCH v4 0/5] arm: add UEFI runtime services support Leif Lindholm
2014-01-11 13:05 ` [PATCH v4 1/5] arm: break part of __soft_restart out into separate function Leif Lindholm
2014-01-22 11:09 ` Will Deacon
2014-01-11 13:05 ` [PATCH v4 2/5] arm: add new asm macro update_sctlr Leif Lindholm
2014-01-22 11:20 ` Will Deacon
2014-01-29 18:28 ` Leif Lindholm
2014-01-29 19:27 ` Will Deacon
2014-01-29 20:58 ` Mark Salter
2014-01-30 13:12 ` Leif Lindholm [this message]
2014-02-03 10:34 ` Will Deacon
2014-02-03 15:55 ` Leif Lindholm
2014-02-03 16:00 ` Will Deacon
2014-02-03 16:20 ` Rob Herring
2014-02-03 16:46 ` Leif Lindholm
2014-02-03 16:57 ` Will Deacon
2014-02-03 18:15 ` Leif Lindholm
2014-01-11 13:05 ` [PATCH v4 3/5] Documentation: arm: add UEFI support documentation Leif Lindholm
2014-01-11 13:05 ` [PATCH v4 4/5] arm: Add [U]EFI runtime services support Leif Lindholm
2014-01-13 15:40 ` Matt Fleming
2014-01-13 18:43 ` Arnd Bergmann
2014-01-13 20:01 ` Leif Lindholm
2014-01-14 6:52 ` Arnd Bergmann
2014-01-14 11:44 ` Leif Lindholm
2014-01-14 13:26 ` Arnd Bergmann
2014-01-14 15:25 ` Leif Lindholm
2014-01-11 13:05 ` [PATCH v4 5/5] init: efi: arm: enable (U)EFI runtime services on arm Leif Lindholm
2014-01-13 18:29 ` Arnd Bergmann
2014-01-13 18:57 ` Leif Lindholm
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=20140130131247.GG11329@bivouac.eciton.net \
--to=leif.lindholm@linaro.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=matt.fleming@intel.com \
--cc=msalter@redhat.com \
--cc=patches@linaro.org \
--cc=roy.franz@linaro.org \
--cc=will.deacon@arm.com \
/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
all inboxes | Powered by JetHome®