All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)
@ 2014-08-19 23:19 Suriyan Ramasami
  2014-08-21 22:21 ` Ian Campbell
  2014-08-26 21:01 ` Ian Campbell
  0 siblings, 2 replies; 14+ messages in thread
From: Suriyan Ramasami @ 2014-08-19 23:19 UTC (permalink / raw)
  To: xen-devel
  Cc: keir, ian.campbell, Suriyan Ramasami, julien.grall, tim,
	jbeulich, ian.jackson

    XEN/ARM: Add support for the Odroid-XU board.

    The Odroid-XU from hardkernel is an Exynos 5410 based board.
    This patch adds support to the above said board.

Signed-off-by: Suriyan Ramasami <suriyan.r@gmail.com>
---

Changes between versions as follows:
   v4:
       a. Lots of Xen coding style changes.
       b. Directly assign cpu_up_send_sgi for 5250.
       c. S5P_PA_SYSRAM renamed to EXYNOS5250_PA_SYSRAM so it is clear
          that newer platforms should use the device tree for information.
       d. Use __raw_readl and _raw_writel instead of readl and writel
       e. Leave function names consistent with what Linux uses so that it
          avoids confusion and is easier to backport in the future.
       f. Remove "samsung,exynos5422-pmu" as no such thing exists.
       g. Use XENLOG_DEBUG instead of XENLOG_INFO for power_base_address.
       h. iounmap(power) in the failure case.
       i. As its generic, call the new platform exynos5.
   v3:
       a. Separate commit message and change log.
       b. Define odroid-xu as a separate platform API.
       c. Use mainline linux's way of retrieving sysram from DT.
       d. Use mainline linux's way of bringing up secondary CPUs.
       e. Keep the #defines in the local C file.
       f. Bringing up newer Exynos platforms should be easier.

   v2:
       a. Set startup address in exynos5_smp_init() only once.
       b. Turn on power to each core in exynos5_cpu_up().
       c. Create single PLATFORM with smp_init, and cpu_up  which dispatches
          to correct code.
       d. Check return code of io_remap for power.
       e. Use read* write* calls for MMIO mapped addresses.
       f. Xen coding style changes.

    v1: Add Odroid-XU board support

---
 xen/arch/arm/platforms/exynos5.c        | 169 +++++++++++++++++++++++++++++---
 xen/include/asm-arm/platforms/exynos5.h |   2 +-
 2 files changed, 158 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
index b65c2c2..6c28279 100644
--- a/xen/arch/arm/platforms/exynos5.c
+++ b/xen/arch/arm/platforms/exynos5.c
@@ -23,10 +23,16 @@
 #include <xen/domain_page.h>
 #include <xen/mm.h>
 #include <xen/vmap.h>
+#include <xen/delay.h>
 #include <asm/platforms/exynos5.h>
 #include <asm/platform.h>
 #include <asm/io.h>
 
+#define EXYNOS_ARM_CORE0_CONFIG     0x2000
+#define EXYNOS_ARM_CORE_CONFIG(_nr) (0x80 * (_nr))
+#define EXYNOS_ARM_CORE_STATUS(_nr) (EXYNOS_ARM_CORE_CONFIG(_nr) + 0x4)
+#define S5P_CORE_LOCAL_PWR_EN       0x3
+
 static int exynos5_init_time(void)
 {
     uint32_t reg;
@@ -51,7 +57,7 @@ static int exynos5_init_time(void)
 }
 
 /* Additional mappings for dom0 (Not in the DTS) */
-static int exynos5_specific_mapping(struct domain *d)
+static int exynos5250_specific_mapping(struct domain *d)
 {
     /* Map the chip ID */
     map_mmio_regions(d, paddr_to_pfn(EXYNOS5_PA_CHIPID), 1,
@@ -64,11 +70,11 @@ static int exynos5_specific_mapping(struct domain *d)
     return 0;
 }
 
-static int __init exynos5_smp_init(void)
+static int __init exynos_smp_init(paddr_t pa_sysram)
 {
     void __iomem *sysram;
 
-    sysram = ioremap_nocache(S5P_PA_SYSRAM, PAGE_SIZE);
+    sysram = ioremap_nocache(pa_sysram, PAGE_SIZE);
     if ( !sysram )
     {
         dprintk(XENLOG_ERR, "Unable to map exynos5 MMIO\n");
@@ -84,6 +90,129 @@ static int __init exynos5_smp_init(void)
     return 0;
 }
 
+static int __init exynos5250_smp_init(void)
+{
+    return exynos_smp_init(EXYNOS5250_PA_SYSRAM);
+}
+
+static int __init exynos5_smp_init(void)
+{
+    struct dt_device_node *node;
+    u64 sysram_ns_base_addr;
+    u64 size;
+    int rc;
+
+    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-sysram-ns");
+    if ( !node )
+    {
+        dprintk(XENLOG_ERR, "samsung,exynos4210-sysram-ns missing in DT\n");
+        return -ENXIO;
+    }
+
+    rc = dt_device_get_address(node, 0, &sysram_ns_base_addr, &size);
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "Error in \"samsung,exynos4210-sysram-ns\"\n");
+        return -ENXIO;
+    }
+
+    dprintk(XENLOG_INFO, "sysram_ns_base_addr: %016llx size: %016llx\n",
+            sysram_ns_base_addr, size);
+
+    return exynos_smp_init(sysram_ns_base_addr + 0x1c);
+}
+
+static int exynos_cpu_power_state(void __iomem *power, int cpu)
+{
+    return __raw_readl(power + EXYNOS_ARM_CORE_STATUS(cpu)) &
+                       S5P_CORE_LOCAL_PWR_EN;
+}
+
+static void exynos_cpu_power_up(void __iomem *power, int cpu)
+{
+    __raw_writel(S5P_CORE_LOCAL_PWR_EN,
+                 power + EXYNOS_ARM_CORE_CONFIG(cpu));
+}
+
+static int exynos5_cpu_power_up(void __iomem *power, int cpu)
+{
+    unsigned int timeout;
+
+    if ( !exynos_cpu_power_state(power, cpu) )
+    {
+        exynos_cpu_power_up(power, cpu);
+        timeout = 10;
+
+        /* wait max 10 ms until cpu is on */
+        while ( exynos_cpu_power_state(power, cpu) != S5P_CORE_LOCAL_PWR_EN )
+        {
+            if ( timeout-- == 0 )
+                break;
+
+            mdelay(1);
+        }
+
+        if ( timeout == 0 )
+        {
+            dprintk(XENLOG_ERR, "CPU%d power enable failed", cpu);
+            return -ETIMEDOUT;
+        }
+    }
+    return 0;
+}
+
+static int exynos5_cpu_up(int cpu)
+{
+    static const struct dt_device_match exynos_dt_pmu_matches[] __initconst =
+    {
+        DT_MATCH_COMPATIBLE("samsung,exynos5250-pmu"),
+        DT_MATCH_COMPATIBLE("samsung,exynos5410-pmu"),
+        DT_MATCH_COMPATIBLE("samsung,exynos5420-pmu"),
+        { /*sentinel*/ },
+    };
+    void __iomem *power;
+    u64 power_base_addr;
+    u64 size;
+    struct dt_device_node *node;
+    int rc;
+    
+    node = dt_find_matching_node(NULL, exynos_dt_pmu_matches);
+    if ( !node )
+    {
+        dprintk(XENLOG_ERR, "samsung,exynos5XXX-pmu missing in DT\n");
+        return -ENXIO;
+    }
+
+    rc = dt_device_get_address(node, 0, &power_base_addr, &size);
+    if ( rc )
+    {
+        dprintk(XENLOG_ERR, "Error in \"samsung,exynos5XXXX-pmu\"\n");
+        return -ENXIO;
+    }
+
+    dprintk(XENLOG_DEBUG, "power_base_addr: %016llx size: %016llx\n",
+            power_base_addr, size);
+
+    power = ioremap_nocache(power_base_addr +
+                            EXYNOS_ARM_CORE0_CONFIG, PAGE_SIZE);
+    if ( !power )
+    {
+        dprintk(XENLOG_ERR, "Unable to map power MMIO\n");
+        return -EFAULT;
+    }
+
+    rc = exynos5_cpu_power_up(power, cpu);
+    if ( rc )
+    {
+        iounmap(power);
+        return -ETIMEDOUT;
+    }
+
+    iounmap(power);
+
+    return cpu_up_send_sgi(cpu);
+}
+
 static void exynos5_reset(void)
 {
     void __iomem *pmu;
@@ -98,15 +227,10 @@ static void exynos5_reset(void)
     }
 
     writel(1, pmu + EXYNOS5_SWRESET);
+
     iounmap(pmu);
 }
 
-static const char * const exynos5_dt_compat[] __initconst =
-{
-    "samsung,exynos5250",
-    NULL
-};
-
 static const struct dt_device_match exynos5_blacklist_dev[] __initconst =
 {
     /* Multi core Timer
@@ -117,12 +241,33 @@ static const struct dt_device_match exynos5_blacklist_dev[] __initconst =
     { /* sentinel */ },
 };
 
+static const char * const exynos5250_dt_compat[] __initconst =
+{
+    "samsung,exynos5250",
+    NULL
+};
+
+static const char * const exynos5410_dt_compat[] __initconst =
+{
+    "samsung,exynos5410",
+    NULL
+};
+
+PLATFORM_START(exynos5250, "SAMSUNG EXYNOS5250")
+    .compatible = exynos5250_dt_compat,
+    .init_time = exynos5_init_time,
+    .specific_mapping = exynos5250_specific_mapping,
+    .smp_init = exynos5250_smp_init,
+    .cpu_up = cpu_up_send_sgi,
+    .reset = exynos5_reset,
+    .blacklist_dev = exynos5_blacklist_dev,
+PLATFORM_END
+
 PLATFORM_START(exynos5, "SAMSUNG EXYNOS5")
-    .compatible = exynos5_dt_compat,
+    .compatible = exynos5410_dt_compat,
     .init_time = exynos5_init_time,
-    .specific_mapping = exynos5_specific_mapping,
     .smp_init = exynos5_smp_init,
-    .cpu_up = cpu_up_send_sgi,
+    .cpu_up = exynos5_cpu_up,
     .reset = exynos5_reset,
     .blacklist_dev = exynos5_blacklist_dev,
 PLATFORM_END
diff --git a/xen/include/asm-arm/platforms/exynos5.h b/xen/include/asm-arm/platforms/exynos5.h
index ea941e7..7676313 100644
--- a/xen/include/asm-arm/platforms/exynos5.h
+++ b/xen/include/asm-arm/platforms/exynos5.h
@@ -12,7 +12,7 @@
 
 #define EXYNOS5_SWRESET             0x0400      /* Relative to PA_PMU */
 
-#define S5P_PA_SYSRAM   0x02020000
+#define EXYNOS5250_PA_SYSRAM        0x02020000
 
 #endif /* __ASM_ARM_PLATFORMS_EXYNOS5_H */
 /*
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)
  2014-08-19 23:19 [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410) Suriyan Ramasami
@ 2014-08-21 22:21 ` Ian Campbell
  2014-08-25 21:45   ` Suriyan Ramasami
  2014-08-26 21:01 ` Ian Campbell
  1 sibling, 1 reply; 14+ messages in thread
From: Ian Campbell @ 2014-08-21 22:21 UTC (permalink / raw)
  To: Suriyan Ramasami
  Cc: keir, julien.grall, tim, xen-devel, jbeulich, ian.jackson

On Tue, 2014-08-19 at 16:19 -0700, Suriyan Ramasami wrote:
> @@ -64,11 +70,11 @@ static int exynos5_specific_mapping(struct domain *d)
>      return 0;
>  }
>  
> -static int __init exynos5_smp_init(void)
> +static int __init exynos_smp_init(paddr_t pa_sysram)
> [...]

> +static int __init exynos5250_smp_init(void)
> [...]
> +static int __init exynos5_smp_init(void)

I'm not sure I grok the intending meaning/distinction of exynos5_* vs
exynos5250_*. It *looks* like you are using exynos5_* for the 5410
specific stuff, but I'm not sure (and I'm half suspecting that you are
using it for both 5410 specific and more general things...).

If that is the case then you really ought to be using exynos5410_* for
stuff which is specific to that chip.

Perhaps exynos5xxx_* would be less confusing for the generic stuff, but
just avoiding using exynos5_* for 5410 specific stuff would be
sufficient.

Ian.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)
  2014-08-21 22:21 ` Ian Campbell
@ 2014-08-25 21:45   ` Suriyan Ramasami
  2014-08-25 22:06     ` Suriyan Ramasami
  0 siblings, 1 reply; 14+ messages in thread
From: Suriyan Ramasami @ 2014-08-25 21:45 UTC (permalink / raw)
  To: Ian Campbell
  Cc: keir, Julien Grall, Tim Deegan, xen-devel, Jan Beulich, ian.jackson

On Thu, Aug 21, 2014 at 3:21 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Tue, 2014-08-19 at 16:19 -0700, Suriyan Ramasami wrote:
>> @@ -64,11 +70,11 @@ static int exynos5_specific_mapping(struct domain *d)
>>      return 0;
>>  }
>>
>> -static int __init exynos5_smp_init(void)
>> +static int __init exynos_smp_init(paddr_t pa_sysram)
>> [...]
>
>> +static int __init exynos5250_smp_init(void)
>> [...]
>> +static int __init exynos5_smp_init(void)
>
> I'm not sure I grok the intending meaning/distinction of exynos5_* vs
> exynos5250_*. It *looks* like you are using exynos5_* for the 5410
> specific stuff, but I'm not sure (and I'm half suspecting that you are
> using it for both 5410 specific and more general things...).
>
> If that is the case then you really ought to be using exynos5410_* for
> stuff which is specific to that chip.
>
> Perhaps exynos5xxx_* would be less confusing for the generic stuff, but
> just avoiding using exynos5_* for 5410 specific stuff would be
> sufficient.
>
Thank you Ian for the review and suggestion. I shall use exynos5xxx_*
for generic and exynos5410_* and exynos5250_* names in my next
iteration.

> Ian.
>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)
  2014-08-25 21:45   ` Suriyan Ramasami
@ 2014-08-25 22:06     ` Suriyan Ramasami
  2014-08-26 17:34       ` Ian Campbell
  0 siblings, 1 reply; 14+ messages in thread
From: Suriyan Ramasami @ 2014-08-25 22:06 UTC (permalink / raw)
  To: Ian Campbell
  Cc: keir, Julien Grall, Tim Deegan, xen-devel, Jan Beulich, ian.jackson

On Mon, Aug 25, 2014 at 2:45 PM, Suriyan Ramasami <suriyan.r@gmail.com> wrote:
> On Thu, Aug 21, 2014 at 3:21 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
>> On Tue, 2014-08-19 at 16:19 -0700, Suriyan Ramasami wrote:
>>> @@ -64,11 +70,11 @@ static int exynos5_specific_mapping(struct domain *d)
>>>      return 0;
>>>  }
>>>
>>> -static int __init exynos5_smp_init(void)
>>> +static int __init exynos_smp_init(paddr_t pa_sysram)
>>> [...]
>>
>>> +static int __init exynos5250_smp_init(void)
>>> [...]
>>> +static int __init exynos5_smp_init(void)
>>
>> I'm not sure I grok the intending meaning/distinction of exynos5_* vs
>> exynos5250_*. It *looks* like you are using exynos5_* for the 5410
>> specific stuff, but I'm not sure (and I'm half suspecting that you are
>> using it for both 5410 specific and more general things...).
>>
>> If that is the case then you really ought to be using exynos5410_* for
>> stuff which is specific to that chip.
>>
>> Perhaps exynos5xxx_* would be less confusing for the generic stuff, but
>> just avoiding using exynos5_* for 5410 specific stuff would be
>> sufficient.
>>
> Thank you Ian for the review and suggestion. I shall use exynos5xxx_*
> for generic and exynos5410_* and exynos5250_* names in my next
> iteration.
>
I just looked at the code again. I do find that it I have consistently
used exynos5_* for generic functions and exynos5410_* for 5410 specifc
and exynos5250_* for 5250 specific functions. The function
exynos5_smp_init(void) was moved down the file, and that is possibly
causing some of this confusion (from a diff perspective).

The exynos_* functions are helpers that have the same name as used in
the linux tree to help in future backports as suggested by Julien.

Please let me know if this is OK.
- Suriyan

>> Ian
>>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)
  2014-08-25 22:06     ` Suriyan Ramasami
@ 2014-08-26 17:34       ` Ian Campbell
  0 siblings, 0 replies; 14+ messages in thread
From: Ian Campbell @ 2014-08-26 17:34 UTC (permalink / raw)
  To: Suriyan Ramasami
  Cc: keir, Julien Grall, Tim Deegan, xen-devel, Jan Beulich, ian.jackson

On Mon, 2014-08-25 at 15:06 -0700, Suriyan Ramasami wrote:
> On Mon, Aug 25, 2014 at 2:45 PM, Suriyan Ramasami <suriyan.r@gmail.com> wrote:
> > On Thu, Aug 21, 2014 at 3:21 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
> >> On Tue, 2014-08-19 at 16:19 -0700, Suriyan Ramasami wrote:
> >>> @@ -64,11 +70,11 @@ static int exynos5_specific_mapping(struct domain *d)
> >>>      return 0;
> >>>  }
> >>>
> >>> -static int __init exynos5_smp_init(void)
> >>> +static int __init exynos_smp_init(paddr_t pa_sysram)
> >>> [...]
> >>
> >>> +static int __init exynos5250_smp_init(void)
> >>> [...]
> >>> +static int __init exynos5_smp_init(void)
> >>
> >> I'm not sure I grok the intending meaning/distinction of exynos5_* vs
> >> exynos5250_*. It *looks* like you are using exynos5_* for the 5410
> >> specific stuff, but I'm not sure (and I'm half suspecting that you are
> >> using it for both 5410 specific and more general things...).
> >>
> >> If that is the case then you really ought to be using exynos5410_* for
> >> stuff which is specific to that chip.
> >>
> >> Perhaps exynos5xxx_* would be less confusing for the generic stuff, but
> >> just avoiding using exynos5_* for 5410 specific stuff would be
> >> sufficient.
> >>
> > Thank you Ian for the review and suggestion. I shall use exynos5xxx_*
> > for generic and exynos5410_* and exynos5250_* names in my next
> > iteration.
> >
> I just looked at the code again. I do find that it I have consistently
> used exynos5_* for generic functions and exynos5410_* for 5410 specifc
> and exynos5250_* for 5250 specific functions. The function
> exynos5_smp_init(void) was moved down the file, and that is possibly
> causing some of this confusion (from a diff perspective).

Yes, that could well be what confused me, sorry about that.

If you can avoid moving the function, then great, otherwise then don't
worry.

> The exynos_* functions are helpers that have the same name as used in
> the linux tree to help in future backports as suggested by Julien.
> 
> Please let me know if this is OK.

>From what you've said here it sounds like it, I'll take another look at
the patch, I'm terribly backlogged at the moment (vacation followed by
conference travel...)

Ian.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)
  2014-08-19 23:19 [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410) Suriyan Ramasami
  2014-08-21 22:21 ` Ian Campbell
@ 2014-08-26 21:01 ` Ian Campbell
  2014-08-27 19:27   ` Suriyan Ramasami
  1 sibling, 1 reply; 14+ messages in thread
From: Ian Campbell @ 2014-08-26 21:01 UTC (permalink / raw)
  To: Suriyan Ramasami
  Cc: keir, julien.grall, tim, xen-devel, jbeulich, ian.jackson

On Tue, 2014-08-19 at 16:19 -0700, Suriyan Ramasami wrote:
> +static int __init exynos5250_smp_init(void)
> +{
> +    return exynos_smp_init(EXYNOS5250_PA_SYSRAM);
> +}
> +
> +static int __init exynos5_smp_init(void)
> +{
> +    struct dt_device_node *node;
> +    u64 sysram_ns_base_addr;
> +    u64 size;
> +    int rc;
> +
> +    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-sysram-ns");


Looking at Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
in the Linx tree it seems that this node is supposed to be present on
all systems, including 5250 and it seems to be present in all the DTBs I
can see.

IOW I think exynos5_smp_init and exynos5250_smp_init can just be
exynos5_smp_init (perhaps even folding in exynos_smp_init too).

I'm unsure whether we should fallback to the existing PA_SYSRAM value,
but my initial feeling is that we can get away without.

My only concern is that right now EXYNOS5250_PA_SYSRAM == 0x02020000 but
the DTB contains:

        sysram@02020000 {
[...]
                smp-sysram@0 {
[...]
                smp-sysram@2f000 {
                        compatible = "samsung,exynos4210-sysram-ns";
                        reg = <0x2f000 0x1000>;
                };
        };

IOW I think the final address for the NS sysram will be 0x204f000 and
not 0x2020000. I'm confused how this work{s,ed}. since the DT seem to
suggest that the sysram at 0x2020000 is secure mode, so we can't be
using it.

Ian.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)
  2014-08-26 21:01 ` Ian Campbell
@ 2014-08-27 19:27   ` Suriyan Ramasami
  2014-09-03 10:03     ` Ian Campbell
  0 siblings, 1 reply; 14+ messages in thread
From: Suriyan Ramasami @ 2014-08-27 19:27 UTC (permalink / raw)
  To: Ian Campbell
  Cc: keir, Julien Grall, Tim Deegan, xen-devel, Jan Beulich, ian.jackson

On Tue, Aug 26, 2014 at 2:01 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Tue, 2014-08-19 at 16:19 -0700, Suriyan Ramasami wrote:
>> +static int __init exynos5250_smp_init(void)
>> +{
>> +    return exynos_smp_init(EXYNOS5250_PA_SYSRAM);
>> +}
>> +
>> +static int __init exynos5_smp_init(void)
>> +{
>> +    struct dt_device_node *node;
>> +    u64 sysram_ns_base_addr;
>> +    u64 size;
>> +    int rc;
>> +
>> +    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-sysram-ns");
>
>
> Looking at Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
> in the Linx tree it seems that this node is supposed to be present on
> all systems, including 5250 and it seems to be present in all the DTBs I
> can see.
>
> IOW I think exynos5_smp_init and exynos5250_smp_init can just be
> exynos5_smp_init (perhaps even folding in exynos_smp_init too).
>
It definitely can be folded in, but as you have mentioned later on in
this email that Exynos5250 will stop booting cause of the erroneous
value of 0x204f000 instead of 0x2020000. If this is folded in, then
the arndale DT should be possibly corrected for it to play well with
XEN.

> I'm unsure whether we should fallback to the existing PA_SYSRAM value,
> but my initial feeling is that we can get away without.
>
> My only concern is that right now EXYNOS5250_PA_SYSRAM == 0x02020000 but
> the DTB contains:
>
>         sysram@02020000 {
> [...]
>                 smp-sysram@0 {
> [...]
>                 smp-sysram@2f000 {
>                         compatible = "samsung,exynos4210-sysram-ns";
>                         reg = <0x2f000 0x1000>;
>                 };
>         };
>
> IOW I think the final address for the NS sysram will be 0x204f000 and
> not 0x2020000. I'm confused how this work{s,ed}. since the DT seem to
> suggest that the sysram at 0x2020000 is secure mode, so we can't be
> using it.
>
I was going over linux kernels (not mainline but vendor modified)
3.10/3.13/3.14 and I find that though they have a DT, they do not seem
to use it entirely. Especially the Exynos modified ones. They have
many hardcoded values which they pull out of thin air and not use the
DT ones. I am guessing that is the reason they are working. I wonder
if the linux mainline 3.16 or 3.17 which I believe has support for the
arndale exynos5250 boots up because of the erroneous (or so I think)
sysram-ns value?

> Ian.
>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)
  2014-08-27 19:27   ` Suriyan Ramasami
@ 2014-09-03 10:03     ` Ian Campbell
  2014-09-03 17:55       ` Suriyan Ramasami
  0 siblings, 1 reply; 14+ messages in thread
From: Ian Campbell @ 2014-09-03 10:03 UTC (permalink / raw)
  To: Suriyan Ramasami
  Cc: keir, Julien Grall, Tim Deegan, xen-devel, Jan Beulich, ian.jackson

On Wed, 2014-08-27 at 12:27 -0700, Suriyan Ramasami wrote:
> On Tue, Aug 26, 2014 at 2:01 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
> > On Tue, 2014-08-19 at 16:19 -0700, Suriyan Ramasami wrote:
> >> +static int __init exynos5250_smp_init(void)
> >> +{
> >> +    return exynos_smp_init(EXYNOS5250_PA_SYSRAM);
> >> +}
> >> +
> >> +static int __init exynos5_smp_init(void)
> >> +{
> >> +    struct dt_device_node *node;
> >> +    u64 sysram_ns_base_addr;
> >> +    u64 size;
> >> +    int rc;
> >> +
> >> +    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-sysram-ns");
> >
> >
> > Looking at Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
> > in the Linx tree it seems that this node is supposed to be present on
> > all systems, including 5250 and it seems to be present in all the DTBs I
> > can see.
> >
> > IOW I think exynos5_smp_init and exynos5250_smp_init can just be
> > exynos5_smp_init (perhaps even folding in exynos_smp_init too).
> >
> It definitely can be folded in, but as you have mentioned later on in
> this email that Exynos5250 will stop booting cause of the erroneous
> value of 0x204f000 instead of 0x2020000. If this is folded in, then
> the arndale DT should be possibly corrected for it to play well with
> XEN.

I think this is already done, looking at v3.16-rc6 (just because I had
it checked out) arch/arm/boot/dts/exynos5250.dtsi has:
        sysram@02020000 {
                compatible = "mmio-sram";
                reg = <0x02020000 0x30000>;
                #address-cells = <1>;
                #size-cells = <1>;
                ranges = <0 0x02020000 0x30000>;

                smp-sysram@0 {
                        compatible = "samsung,exynos4210-sysram";
                        reg = <0x0 0x1000>;
                };

                smp-sysram@2f000 {
                        compatible = "samsung,exynos4210-sysram-ns";
                        reg = <0x2f000 0x1000>;
                };
        };

> > I'm unsure whether we should fallback to the existing PA_SYSRAM value,
> > but my initial feeling is that we can get away without.
> >
> > My only concern is that right now EXYNOS5250_PA_SYSRAM == 0x02020000 but
> > the DTB contains:
> >
> >         sysram@02020000 {
> > [...]
> >                 smp-sysram@0 {
> > [...]
> >                 smp-sysram@2f000 {
> >                         compatible = "samsung,exynos4210-sysram-ns";
> >                         reg = <0x2f000 0x1000>;
> >                 };
> >         };
> >
> > IOW I think the final address for the NS sysram will be 0x204f000 and
> > not 0x2020000. I'm confused how this work{s,ed}. since the DT seem to
> > suggest that the sysram at 0x2020000 is secure mode, so we can't be
> > using it.
> >
> I was going over linux kernels (not mainline but vendor modified)
> 3.10/3.13/3.14 and I find that though they have a DT, they do not seem
> to use it entirely. Especially the Exynos modified ones. They have
> many hardcoded values which they pull out of thin air and not use the
> DT ones. I am guessing that is the reason they are working. I wonder
> if the linux mainline 3.16 or 3.17 which I believe has support for the
> arndale exynos5250 boots up because of the erroneous (or so I think)
> sysram-ns value?

I've not tried something more modern on an arndale but I'm told they are
now multiplatform capable, which implies most stuff is correctly driven
by DT, proof will be in the pudding though!

Ian.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)
  2014-09-03 10:03     ` Ian Campbell
@ 2014-09-03 17:55       ` Suriyan Ramasami
  2014-09-03 18:25         ` Julien Grall
       [not found]         ` <1409821081.15505.44.camel@kazak.uk.xensource.com>
  0 siblings, 2 replies; 14+ messages in thread
From: Suriyan Ramasami @ 2014-09-03 17:55 UTC (permalink / raw)
  To: Ian Campbell
  Cc: keir, Julien Grall, Tim Deegan, xen-devel, Jan Beulich, ian.jackson

On Wed, Sep 3, 2014 at 3:03 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2014-08-27 at 12:27 -0700, Suriyan Ramasami wrote:
>> On Tue, Aug 26, 2014 at 2:01 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > On Tue, 2014-08-19 at 16:19 -0700, Suriyan Ramasami wrote:
>> >> +static int __init exynos5250_smp_init(void)
>> >> +{
>> >> +    return exynos_smp_init(EXYNOS5250_PA_SYSRAM);
>> >> +}
>> >> +
>> >> +static int __init exynos5_smp_init(void)
>> >> +{
>> >> +    struct dt_device_node *node;
>> >> +    u64 sysram_ns_base_addr;
>> >> +    u64 size;
>> >> +    int rc;
>> >> +
>> >> +    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-sysram-ns");
>> >
>> >
>> > Looking at Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
>> > in the Linx tree it seems that this node is supposed to be present on
>> > all systems, including 5250 and it seems to be present in all the DTBs I
>> > can see.
>> >
>> > IOW I think exynos5_smp_init and exynos5250_smp_init can just be
>> > exynos5_smp_init (perhaps even folding in exynos_smp_init too).
>> >
>> It definitely can be folded in, but as you have mentioned later on in
>> this email that Exynos5250 will stop booting cause of the erroneous
>> value of 0x204f000 instead of 0x2020000. If this is folded in, then
>> the arndale DT should be possibly corrected for it to play well with
>> XEN.
>
> I think this is already done, looking at v3.16-rc6 (just because I had
> it checked out) arch/arm/boot/dts/exynos5250.dtsi has:
>         sysram@02020000 {
>                 compatible = "mmio-sram";
>                 reg = <0x02020000 0x30000>;
>                 #address-cells = <1>;
>                 #size-cells = <1>;
>                 ranges = <0 0x02020000 0x30000>;
>
>                 smp-sysram@0 {
>                         compatible = "samsung,exynos4210-sysram";
>                         reg = <0x0 0x1000>;
>                 };
>
>                 smp-sysram@2f000 {
>                         compatible = "samsung,exynos4210-sysram-ns";
>                         reg = <0x2f000 0x1000>;
>                 };
>         };
>

I am a little confused here. We are using - compatible =
"samsung,exynos4210-sysram-ns" to pull the value for
sysram_ns_base_addr in function exynos5_smp_init(). I believe with the
exynos5250 DT you have quoted above, wouldn't that add up to 2020000 +
2f000? (which is not what we want for the arndale?) I shall wait on
your thoughts on this.

On the same train of thought, it would seem that EXYNOS5_MCT_BASE
should also be extracted from the DT (in function exynos5_init_time).

Also, I realized that the PLATFORM_START for the exynos5410 is thus:
PLATFORM_START(exynos5, "SAMSUNG EXYNOS5")
I believe it should instead be:
PLATFORM_START(exynos5410, "SAMSUNG EXYNOS5410")

I shall send out a patch version 5 with these changes.

>> > I'm unsure whether we should fallback to the existing PA_SYSRAM value,
>> > but my initial feeling is that we can get away without.
>> >
>> > My only concern is that right now EXYNOS5250_PA_SYSRAM == 0x02020000 but
>> > the DTB contains:
>> >
>> >         sysram@02020000 {
>> > [...]
>> >                 smp-sysram@0 {
>> > [...]
>> >                 smp-sysram@2f000 {
>> >                         compatible = "samsung,exynos4210-sysram-ns";
>> >                         reg = <0x2f000 0x1000>;
>> >                 };
>> >         };
>> >
>> > IOW I think the final address for the NS sysram will be 0x204f000 and
>> > not 0x2020000. I'm confused how this work{s,ed}. since the DT seem to
>> > suggest that the sysram at 0x2020000 is secure mode, so we can't be
>> > using it.
>> >
>> I was going over linux kernels (not mainline but vendor modified)
>> 3.10/3.13/3.14 and I find that though they have a DT, they do not seem
>> to use it entirely. Especially the Exynos modified ones. They have
>> many hardcoded values which they pull out of thin air and not use the
>> DT ones. I am guessing that is the reason they are working. I wonder
>> if the linux mainline 3.16 or 3.17 which I believe has support for the
>> arndale exynos5250 boots up because of the erroneous (or so I think)
>> sysram-ns value?
>
> I've not tried something more modern on an arndale but I'm told they are
> now multiplatform capable, which implies most stuff is correctly driven
> by DT, proof will be in the pudding though!
>
> Ian.
>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)
  2014-09-03 17:55       ` Suriyan Ramasami
@ 2014-09-03 18:25         ` Julien Grall
  2014-09-03 19:07           ` Suriyan Ramasami
       [not found]         ` <1409821081.15505.44.camel@kazak.uk.xensource.com>
  1 sibling, 1 reply; 14+ messages in thread
From: Julien Grall @ 2014-09-03 18:25 UTC (permalink / raw)
  To: Suriyan Ramasami, Ian Campbell
  Cc: ian.jackson, Tim Deegan, keir, Jan Beulich, xen-devel

Hello Suriyan,

On 03/09/14 13:55, Suriyan Ramasami wrote:
> On the same train of thought, it would seem that EXYNOS5_MCT_BASE
> should also be extracted from the DT (in function exynos5_init_time).

Sounds a good things to modify.

> Also, I realized that the PLATFORM_START for the exynos5410 is thus:
> PLATFORM_START(exynos5, "SAMSUNG EXYNOS5")
> I believe it should instead be:
> PLATFORM_START(exynos5410, "SAMSUNG EXYNOS5410")

It looks like the platform you've introduced doesn't contain exyno5410 
specific code. Why would you rename to exynos5410?

Regards,

-- 
Julien Grall

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)
  2014-09-03 18:25         ` Julien Grall
@ 2014-09-03 19:07           ` Suriyan Ramasami
  2014-09-03 19:15             ` Julien Grall
  0 siblings, 1 reply; 14+ messages in thread
From: Suriyan Ramasami @ 2014-09-03 19:07 UTC (permalink / raw)
  To: Julien Grall
  Cc: keir, Ian Campbell, Tim Deegan, xen-devel, Jan Beulich, ian.jackson

On Wed, Sep 3, 2014 at 11:25 AM, Julien Grall <julien.grall@linaro.org> wrote:
> Hello Suriyan,
>
>
> On 03/09/14 13:55, Suriyan Ramasami wrote:
>>
>> On the same train of thought, it would seem that EXYNOS5_MCT_BASE
>> should also be extracted from the DT (in function exynos5_init_time).
>
>
> Sounds a good things to modify.
>
Hello Julien,
  Thanks for the feedback. I shall modify it accordingly.

>
>> Also, I realized that the PLATFORM_START for the exynos5410 is thus:
>> PLATFORM_START(exynos5, "SAMSUNG EXYNOS5")
>> I believe it should instead be:
>> PLATFORM_START(exynos5410, "SAMSUNG EXYNOS5410")
>
>
> It looks like the platform you've introduced doesn't contain exyno5410
> specific code. Why would you rename to exynos5410?
>
The .compatible is exynos5410_dt_compat which lists
"samsung,exynos5410". Hence, I wanted to make the whole PLATFORM
platform specific to the exynos5410.
Now, rethinking what you have said, I believe as all of this is
generic code, the  .compatible should then be exynos5_dt_compat, thus:
PLATFORM_START(exynos5, "SAMSUNG EXYNOS5")
    .compatible = exynos5_dt_compat,
and not, .compatible = exynos5410_dt_compat as it is now.

I believe this is what you were suggesting? In which case when more
SoCs are added, we just add the corresponding string in
exynos5_dt_compat. Would that be the correct interpretation?

Hence, if a SoC needs something platform specific, we then add a new
PLATFORM_START for that particular SoC.

I hope I am following you guys correctly here!
Thanks as always
- Suriyan



> Regards,
>
> --
> Julien Grall

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)
  2014-09-03 19:07           ` Suriyan Ramasami
@ 2014-09-03 19:15             ` Julien Grall
  0 siblings, 0 replies; 14+ messages in thread
From: Julien Grall @ 2014-09-03 19:15 UTC (permalink / raw)
  To: Suriyan Ramasami
  Cc: keir, Ian Campbell, Tim Deegan, xen-devel, Jan Beulich, ian.jackson



On 03/09/14 15:07, Suriyan Ramasami wrote:
> The .compatible is exynos5410_dt_compat which lists
> "samsung,exynos5410". Hence, I wanted to make the whole PLATFORM
> platform specific to the exynos5410.
> Now, rethinking what you have said, I believe as all of this is
> generic code, the  .compatible should then be exynos5_dt_compat, thus:
> PLATFORM_START(exynos5, "SAMSUNG EXYNOS5")
>      .compatible = exynos5_dt_compat,
> and not, .compatible = exynos5410_dt_compat as it is now.
>
> I believe this is what you were suggesting? In which case when more
> SoCs are added, we just add the corresponding string in
> exynos5_dt_compat. Would that be the correct interpretation?

Yes.

Regards,

-- 
Julien Grall

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)
       [not found]         ` <1409821081.15505.44.camel@kazak.uk.xensource.com>
@ 2014-09-04 15:44           ` Suriyan Ramasami
  2014-09-04 15:51             ` Ian Campbell
  0 siblings, 1 reply; 14+ messages in thread
From: Suriyan Ramasami @ 2014-09-04 15:44 UTC (permalink / raw)
  To: Ian Campbell
  Cc: keir, Julien Grall, Tim Deegan, xen-devel, Jan Beulich, ian.jackson

On Thu, Sep 4, 2014 at 1:58 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2014-09-03 at 10:55 -0700, Suriyan Ramasami wrote:
>> On Wed, Sep 3, 2014 at 3:03 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>> > On Wed, 2014-08-27 at 12:27 -0700, Suriyan Ramasami wrote:
>> >> On Tue, Aug 26, 2014 at 2:01 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
>> >> > On Tue, 2014-08-19 at 16:19 -0700, Suriyan Ramasami wrote:
>> >> >> +static int __init exynos5250_smp_init(void)
>> >> >> +{
>> >> >> +    return exynos_smp_init(EXYNOS5250_PA_SYSRAM);
>> >> >> +}
>> >> >> +
>> >> >> +static int __init exynos5_smp_init(void)
>> >> >> +{
>> >> >> +    struct dt_device_node *node;
>> >> >> +    u64 sysram_ns_base_addr;
>> >> >> +    u64 size;
>> >> >> +    int rc;
>> >> >> +
>> >> >> +    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-sysram-ns");
>> >> >
>> >> >
>> >> > Looking at Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
>> >> > in the Linx tree it seems that this node is supposed to be present on
>> >> > all systems, including 5250 and it seems to be present in all the DTBs I
>> >> > can see.
>> >> >
>> >> > IOW I think exynos5_smp_init and exynos5250_smp_init can just be
>> >> > exynos5_smp_init (perhaps even folding in exynos_smp_init too).
>> >> >
>> >> It definitely can be folded in, but as you have mentioned later on in
>> >> this email that Exynos5250 will stop booting cause of the erroneous
>> >> value of 0x204f000 instead of 0x2020000. If this is folded in, then
>> >> the arndale DT should be possibly corrected for it to play well with
>> >> XEN.
>> >
>> > I think this is already done, looking at v3.16-rc6 (just because I had
>> > it checked out) arch/arm/boot/dts/exynos5250.dtsi has:
>> >         sysram@02020000 {
>> >                 compatible = "mmio-sram";
>> >                 reg = <0x02020000 0x30000>;
>> >                 #address-cells = <1>;
>> >                 #size-cells = <1>;
>> >                 ranges = <0 0x02020000 0x30000>;
>> >
>> >                 smp-sysram@0 {
>> >                         compatible = "samsung,exynos4210-sysram";
>> >                         reg = <0x0 0x1000>;
>> >                 };
>> >
>> >                 smp-sysram@2f000 {
>> >                         compatible = "samsung,exynos4210-sysram-ns";
>> >                         reg = <0x2f000 0x1000>;
>> >                 };
>> >         };
>> >
>>
>> I am a little confused here. We are using - compatible =
>> "samsung,exynos4210-sysram-ns" to pull the value for
>> sysram_ns_base_addr in function exynos5_smp_init(). I believe with the
>> exynos5250 DT you have quoted above, wouldn't that add up to 2020000 +
>> 2f000? (which is not what we want for the arndale?) I shall wait on
>> your thoughts on this.
>
> I think I mentioned this upthread. At the time I had no idea why but
> looking again:
>
> DT has 0x0204f000 whereas we are hardcoding 0x02020000. The DT lists
> 0x2020000 as the secure sysram. Aha! Looks like this was wrongly
> converted by:
>
>         4557c2292854d047ba8e44a69e2d60d99533d155
>         Author: Ian Campbell <ian.campbell@citrix.com>
>         Date:   Thu Aug 29 16:25:00 2013 +0100
>
>             xen: arm: rewrite start of day page table and cpu bring up
>
> which moved the CPU kick from secure mode to NS mode. Has SMP on arndale
> been broken since then? Probably.
>

So, it does make sense to fold it in and get rid of the 0x02020000
hardcoded value for Arndale. Right? I shall push a version 6 with this
change.

>> On the same train of thought, it would seem that EXYNOS5_MCT_BASE
>> should also be extracted from the DT (in function exynos5_init_time).
>
> Ideally, yes.
>
This has been incorporated in version 5 of the patch.
Thanks!

> Ian.
>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410)
  2014-09-04 15:44           ` Suriyan Ramasami
@ 2014-09-04 15:51             ` Ian Campbell
  0 siblings, 0 replies; 14+ messages in thread
From: Ian Campbell @ 2014-09-04 15:51 UTC (permalink / raw)
  To: Suriyan Ramasami
  Cc: keir, Julien Grall, Tim Deegan, xen-devel, Jan Beulich, ian.jackson

On Thu, 2014-09-04 at 08:44 -0700, Suriyan Ramasami wrote:
> On Thu, Sep 4, 2014 at 1:58 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2014-09-03 at 10:55 -0700, Suriyan Ramasami wrote:
> >> On Wed, Sep 3, 2014 at 3:03 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> >> > On Wed, 2014-08-27 at 12:27 -0700, Suriyan Ramasami wrote:
> >> >> On Tue, Aug 26, 2014 at 2:01 PM, Ian Campbell <ian.campbell@citrix.com> wrote:
> >> >> > On Tue, 2014-08-19 at 16:19 -0700, Suriyan Ramasami wrote:
> >> >> >> +static int __init exynos5250_smp_init(void)
> >> >> >> +{
> >> >> >> +    return exynos_smp_init(EXYNOS5250_PA_SYSRAM);
> >> >> >> +}
> >> >> >> +
> >> >> >> +static int __init exynos5_smp_init(void)
> >> >> >> +{
> >> >> >> +    struct dt_device_node *node;
> >> >> >> +    u64 sysram_ns_base_addr;
> >> >> >> +    u64 size;
> >> >> >> +    int rc;
> >> >> >> +
> >> >> >> +    node = dt_find_compatible_node(NULL, NULL, "samsung,exynos4210-sysram-ns");
> >> >> >
> >> >> >
> >> >> > Looking at Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
> >> >> > in the Linx tree it seems that this node is supposed to be present on
> >> >> > all systems, including 5250 and it seems to be present in all the DTBs I
> >> >> > can see.
> >> >> >
> >> >> > IOW I think exynos5_smp_init and exynos5250_smp_init can just be
> >> >> > exynos5_smp_init (perhaps even folding in exynos_smp_init too).
> >> >> >
> >> >> It definitely can be folded in, but as you have mentioned later on in
> >> >> this email that Exynos5250 will stop booting cause of the erroneous
> >> >> value of 0x204f000 instead of 0x2020000. If this is folded in, then
> >> >> the arndale DT should be possibly corrected for it to play well with
> >> >> XEN.
> >> >
> >> > I think this is already done, looking at v3.16-rc6 (just because I had
> >> > it checked out) arch/arm/boot/dts/exynos5250.dtsi has:
> >> >         sysram@02020000 {
> >> >                 compatible = "mmio-sram";
> >> >                 reg = <0x02020000 0x30000>;
> >> >                 #address-cells = <1>;
> >> >                 #size-cells = <1>;
> >> >                 ranges = <0 0x02020000 0x30000>;
> >> >
> >> >                 smp-sysram@0 {
> >> >                         compatible = "samsung,exynos4210-sysram";
> >> >                         reg = <0x0 0x1000>;
> >> >                 };
> >> >
> >> >                 smp-sysram@2f000 {
> >> >                         compatible = "samsung,exynos4210-sysram-ns";
> >> >                         reg = <0x2f000 0x1000>;
> >> >                 };
> >> >         };
> >> >
> >>
> >> I am a little confused here. We are using - compatible =
> >> "samsung,exynos4210-sysram-ns" to pull the value for
> >> sysram_ns_base_addr in function exynos5_smp_init(). I believe with the
> >> exynos5250 DT you have quoted above, wouldn't that add up to 2020000 +
> >> 2f000? (which is not what we want for the arndale?) I shall wait on
> >> your thoughts on this.
> >
> > I think I mentioned this upthread. At the time I had no idea why but
> > looking again:
> >
> > DT has 0x0204f000 whereas we are hardcoding 0x02020000. The DT lists
> > 0x2020000 as the secure sysram. Aha! Looks like this was wrongly
> > converted by:
> >
> >         4557c2292854d047ba8e44a69e2d60d99533d155
> >         Author: Ian Campbell <ian.campbell@citrix.com>
> >         Date:   Thu Aug 29 16:25:00 2013 +0100
> >
> >             xen: arm: rewrite start of day page table and cpu bring up
> >
> > which moved the CPU kick from secure mode to NS mode. Has SMP on arndale
> > been broken since then? Probably.
> >
> 
> So, it does make sense to fold it in and get rid of the 0x02020000
> hardcoded value for Arndale. Right?

Correct.

> I shall push a version 6 with this change.

Thanks.

> 
> >> On the same train of thought, it would seem that EXYNOS5_MCT_BASE
> >> should also be extracted from the DT (in function exynos5_init_time).
> >
> > Ideally, yes.
> >
> This has been incorporated in version 5 of the patch.
> Thanks!
> 
> > Ian.
> >

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2014-09-04 15:51 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-19 23:19 [PATCH v4 1/1] Support Odroid-XU board (Exynos 5410) Suriyan Ramasami
2014-08-21 22:21 ` Ian Campbell
2014-08-25 21:45   ` Suriyan Ramasami
2014-08-25 22:06     ` Suriyan Ramasami
2014-08-26 17:34       ` Ian Campbell
2014-08-26 21:01 ` Ian Campbell
2014-08-27 19:27   ` Suriyan Ramasami
2014-09-03 10:03     ` Ian Campbell
2014-09-03 17:55       ` Suriyan Ramasami
2014-09-03 18:25         ` Julien Grall
2014-09-03 19:07           ` Suriyan Ramasami
2014-09-03 19:15             ` Julien Grall
     [not found]         ` <1409821081.15505.44.camel@kazak.uk.xensource.com>
2014-09-04 15:44           ` Suriyan Ramasami
2014-09-04 15:51             ` Ian Campbell

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.