All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org,
	stefano.stabellini@citrix.com
Subject: Re: [PATCH v2 3/6] xen/arm32: Introduce lookup_processor_type
Date: Fri, 14 Mar 2014 14:31:43 +0000	[thread overview]
Message-ID: <532312CF.1020906@linaro.org> (raw)
In-Reply-To: <1394807086.6442.87.camel@kazak.uk.xensource.com>

Hi Ian,

On 03/14/2014 02:24 PM, Ian Campbell wrote:
> On Wed, 2014-03-05 at 12:46 +0800, Julien Grall wrote:@@ -545,6 +535,45
>> #endif /* !CONFIG_EARLY_PRINTK */
> 
> I got a reject here because currently this reads /* EARLY_PRINTK */. I
> presume this patch is in your queue after your other series but that
> they are actually unrelated. On that assumption I intend to resolve the
> conflict and commit... Let me know if I shouldn't do that!

There is no dependency between the both series. I should have rebase my series
before to send it, sorry.

You will find below the diff without the conflict.

Regards,

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index e889596..72cda34 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -198,26 +198,16 @@ skip_bss:
         PRINT("- Setting up control registers -\r\n")
 
         /* Get processor specific proc info into r1 */
-        mrc   CP32(r0, MIDR)                /* r0 := our cpu id */
-        ldr   r1, = __proc_info_start
-        add   r1, r1, r10                   /* r1 := paddr of table (start) */
-        ldr   r2, = __proc_info_end
-        add   r2, r2, r10                   /* r2 := paddr of table (end) */
-1:      ldr   r3, [r1, #PROCINFO_cpu_mask]
-        and   r4, r0, r3                    /* r4 := our cpu id with mask */
-        ldr   r3, [r1, #PROCINFO_cpu_val]   /* r3 := cpu val in current proc info */
-        teq   r4, r3
-        beq   2f                            /* Match => exit, or try next proc info */
-        add   r1, r1, #PROCINFO_sizeof
-        cmp   r1, r2
-        blo   1b
+        bl    __lookup_processor_type
+        teq   r1, #0
+        bne   1f
         mov   r4, r0
         PRINT("- Missing processor info: ")
         mov   r0, r4
         bl    putn
         PRINT(" -\r\n")
         b     fail
-2:
+1:
 
         /* Jump to cpu_init */
         ldr   r1, [r1, #PROCINFO_cpu_init]  /* r1 := vaddr(init func) */
@@ -545,6 +535,45 @@ putn:   mov   pc, lr
 
 #endif /* !EARLY_PRINTK */
 
+/* This provides a C-API version of __lookup_processor_type */
+GLOBAL(lookup_processor_type)
+        stmfd sp!, {r4, r10, lr}
+        mov   r10, #0                   /* r10 := offset between virt&phys */
+        bl    __lookup_processor_type
+        mov r0, r1
+        ldmfd sp!, {r4, r10, pc}
+
+/* Read processor ID register (CP#15, CR0), and Look up in the linker-built
+ * supported processor list. Note that we can't use the absolute addresses for
+ * the __proc_info lists since we aren't running with the MMU on (and therefore,
+ * we are not in correct address space). We have to calculate the offset.
+ *
+ * r10: offset between virt&phys
+ *
+ * Returns:
+ * r0: CPUID
+ * r1: proc_info pointer
+ * Clobbers r2-r4
+ */
+__lookup_processor_type:
+        mrc   CP32(r0, MIDR)                /* r0 := our cpu id */
+        ldr   r1, = __proc_info_start
+        add   r1, r1, r10                   /* r1 := paddr of table (start) */
+        ldr   r2, = __proc_info_end
+        add   r2, r2, r10                   /* r2 := paddr of table (end) */
+1:      ldr   r3, [r1, #PROCINFO_cpu_mask]
+        and   r4, r0, r3                    /* r4 := our cpu id with mask */
+        ldr   r3, [r1, #PROCINFO_cpu_val]   /* r3 := cpu val in current proc info */
+        teq   r4, r3
+        beq   2f                            /* Match => exit, or try next proc info */
+        add   r1, r1, #PROCINFO_sizeof
+        cmp   r1, r2
+        blo   1b
+        /* We failed to find the proc_info, return NULL */
+        mov   r1, #0
+2:
+        mov   pc, lr
+
 /*
  * Local variables:
  * mode: ASM

-- 
Julien Grall

  reply	other threads:[~2014-03-14 14:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-05  4:46 [PATCH v2 0/6] xen/arm: Remove processor specific bits in Xen code Julien Grall
2014-03-05  4:46 ` [PATCH v2 1/6] xen/arm32: proc-v7.S: Rename v7_init and ACTLR_V7_SMP Julien Grall
2014-03-12 14:19   ` Ian Campbell
2014-03-12 14:21     ` Julien Grall
2014-03-05  4:46 ` [PATCH v2 2/6] xen/arm32: head.S: Remove CA15 and CA7 specific includes Julien Grall
2014-03-05  4:46 ` [PATCH v2 3/6] xen/arm32: Introduce lookup_processor_type Julien Grall
2014-03-14 14:24   ` Ian Campbell
2014-03-14 14:31     ` Julien Grall [this message]
2014-03-05  4:46 ` [PATCH v2 4/6] xen/arm64: Implement lookup_processor_type as a dummy function Julien Grall
2014-03-05  4:46 ` [PATCH v2 5/6] xen/arm: Remove processor specific setup in vcpu_initialise Julien Grall
2014-03-12 14:22   ` Ian Campbell
2014-03-05  4:46 ` [PATCH v2 6/6] xen/arm: Remove asm-arm/processor-ca{15, 7}.h headers Julien Grall
2014-03-06 14:41 ` [PATCH v2 0/6] xen/arm: Remove processor specific bits in Xen code Tim Deegan
2014-03-14 15:13   ` Ian Campbell

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=532312CF.1020906@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=Ian.Campbell@citrix.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.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.