linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] [ARM] Translate delay.S into (mostly) C
Date: Wed, 06 Oct 2010 13:24:37 -0700	[thread overview]
Message-ID: <4CACDB05.5060308@codeaurora.org> (raw)
In-Reply-To: <1286393743.22265.129.camel@m0nster>

 On 10/06/2010 12:35 PM, Daniel Walker wrote:
> Is it possible to do all this in assembly ? Can't you have the default
> implementation using this assembly with different function names, then
> just set the assembly function names in C code someplace?

Sure we could do that. I went this route because adding the timer based
delay code was a copy paste instead of a copy translate. Actually, after
adding the set_delay_fn code __const_udelay and __delay aren't inlined
into __udelay anymore so we're back to the noinline behavior except
we're missing interleaving.

Finally, I thought it would be clearer what was going on if it was in C
as opposed to assembly. How bad is a branch as opposed to fall through.
And more importantly, how bad is a push/pop?

00000000 <delay_loop>:
   0:   e2500001        subs    r0, r0, #1      ; 0x1
   4:   8afffffd        bhi     0 <delay_loop>
   8:   e12fff1e        bx      lr

0000000c <set_delay_fn>:
   c:   e59f3004        ldr     r3, [pc, #4]    ; 18 <set_delay_fn+0xc>
  10:   e5830000        str     r0, [r3]
  14:   e12fff1e        bx      lr
  18:   00000000        .word   0x00000000

0000001c <__delay>:
  1c:   e92d4010        push    {r4, lr}
  20:   e59f3008        ldr     r3, [pc, #8]    ; 30 <__delay+0x14>
  24:   e1a0e00f        mov     lr, pc
  28:   e593f000        ldr     pc, [r3]
  2c:   e8bd8010        pop     {r4, pc}
  30:   00000000        .word   0x00000000

00000034 <__const_udelay>:
  34:   e59f3018        ldr     r3, [pc, #24]   ; 54 <__const_udelay+0x20>
  38:   e1a00720        lsr     r0, r0, #14
  3c:   e5933000        ldr     r3, [r3]
  40:   e1a03523        lsr     r3, r3, #10
  44:   e0000093        mul     r0, r3, r0
  48:   e1b00320        lsrs    r0, r0, #6
  4c:   012fff1e        bxeq    lr
  50:   eafffffe        b       1c <__delay>
  54:   00000000        .word   0x00000000

00000058 <__udelay>:
  58:   e59f3004        ldr     r3, [pc, #4]    ; 64 <__udelay+0xc>
  5c:   e0000093        mul     r0, r3, r0
  60:   eafffffe        b       34 <__const_udelay>
  64:   0001a36e        .word   0x0001a36e


-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

  parent reply	other threads:[~2010-10-06 20:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-28  3:33 [PATCH 0/3] Fixing udelay() on SMP (and non-SMP too) Stephen Boyd
2010-09-28  3:33 ` [PATCH 1/3] [ARM] Translate delay.S into (mostly) C Stephen Boyd
2010-10-05 17:22   ` Daniel Walker
2010-10-06  3:36     ` Stephen Boyd
2010-10-06 13:38       ` Daniel Walker
2010-10-06 14:26       ` Nicolas Pitre
2010-10-06 18:30         ` Stephen Boyd
2010-10-06 19:35           ` Daniel Walker
2010-10-06 20:05             ` Nicolas Pitre
2010-10-08  0:11               ` Stephen Boyd
2010-10-08  1:12                 ` Nicolas Pitre
2010-10-06 20:24             ` Stephen Boyd [this message]
2010-09-28  3:33 ` [PATCH 2/3] [ARM] Allow machines to override __delay() Stephen Boyd
2010-10-05 17:29   ` Daniel Walker
2010-10-06  3:36     ` Stephen Boyd
2010-09-28  3:33 ` [PATCH 3/3] [ARM] Implement a timer based __delay() loop Stephen Boyd
2010-10-05 17:38   ` Daniel Walker
2010-10-06  3:36     ` Stephen Boyd
2010-10-06 13:44       ` Daniel Walker
  -- strict thread matches above, loose matches on Subject: below --
2010-09-07 18:23 [PATCH 0/3] Fixing udelay() on SMP (and non-SMP too) Stephen Boyd
2010-09-07 18:23 ` [PATCH 1/3] [ARM] Translate delay.S into (mostly) C Stephen Boyd
2010-08-19  2:24 [PATCH 0/3] Fixing udelay() on SMP (and non-SMP too) Stephen Boyd
2010-08-19  2:24 ` [PATCH 1/3] [ARM] Translate delay.S into (mostly) C Stephen Boyd

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=4CACDB05.5060308@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).