dm: timer: x86: 64-bit counter support and tsc timer dm conversion

We should use device tree to pass the clock frequency of the timer instead of hardcoded in the driver codes.

Signed-off-by Bin Meng <[email protected]>

---

Changes in v3: None
Changes in v2:
- New patch to use device tree to pass the clock frequency

 arch/sandbox/dts/sandbox.dts  | 1 +
 drivers/timer/sandbox_timer.c | 4 ----
 2 files changed, 1 insertion(+), 4 deletions(-)

There are timers with a 64-bit counter value but current timer uclass driver assumes a 32-bit one. Modify timer_get_count() to ask timer driver to always return a 64-bit counter value, and provide an inline helper function timer_conv_64() to handle the 32-bit/64-bit conversion automatically.

Signed-off-by Bin Meng <[email protected]>

---

Changes in v3:
- Update commit message to reflect the v2 changes (ie: there is no "counter-64bit" property)

Changes in v2:
- Do not use "counter-64bit" property, instead create an inline function for 32-bit timer driver to construct a 64-bit timer value.

 drivers/timer/altera_timer.c  |  4 ++--
 drivers/timer/sandbox_timer.c |  2 +-
 drivers/timer/timer-uclass.c  |  8 +++-----
 include/timer.h               | 23 ++++++++++++++++++++---
 lib/time.c                    |  9 ++++++---
 5 files changed, 32 insertions(+), 14 deletions(-)

drivers/timer/altera_timer.c +2 -2

index 6fe24f2..a7ed3cc 100644
@@ -34,7 +34,7 @@ struct altera_timer_platdata {
        struct altera_timer_regs *regs;
 };
 
-static int altera_timer_get_count(struct udevice *dev, unsigned long *count)
+static int altera_timer_get_count(struct udevice *dev, u64 *count)
 {
        struct altera_timer_platdata *plat = dev->platdata;
        struct altera_timer_regs *const regs = plat->regs;

@@ -46,7 +46,7 @@ static int altera_timer_get_count(struct udevice *dev, unsigned long *count)
        /* Read timer value */
        val = readl(&regs->snapl) & 0xffff;
        val |= (readl(&regs->snaph) & 0xffff) << 16;
-       *count = ~val;
+       *count = timer_conv_64(~val);
 
        return 0;
 }

drivers/timer/sandbox_timer.c +1 -1

index 4b20af2..00a9944 100644
@@ -18,7 +18,7 @@ void sandbox_timer_add_offset(unsigned long offset)
        sandbox_timer_offset += offset;
 }
 
-static int sandbox_timer_get_count(struct udevice *dev, unsigned long *count)
+static int sandbox_timer_get_count(struct udevice *dev, u64 *count)
 {
        *count = os_get_nsec() / 1000 + sandbox_timer_offset * 1000;
 

drivers/timer/timer-uclass.c +3 -5

index 0218591..1ef0012 100644
@@ -9,18 +9,16 @@
 #include <errno.h>
 #include <timer.h>
 
-DECLARE_GLOBAL_DATA_PTR;
-
 /*
  * Implement a timer uclass to work with lib/time.c. The timer is usually
- * a 32 bits free-running up counter. The get_rate() method is used to get
+ * a 32/64 bits free-running up counter. The get_rate() method is used to get
  * the input clock frequency of the timer. The get_count() method is used
- * to get the current 32 bits count value. If the hardware is counting down,
+ * to get the current 64 bits count value. If the hardware is counting down,
  * the value should be inversed inside the method. There may be no real
  * tick, and no timer interrupt.
  */
 
-int timer_get_count(struct udevice *dev, unsigned long *count)
+int timer_get_count(struct udevice *dev, u64 *count)
 {
        const struct timer_ops *ops = device_get_ops(dev);
 

include/timer.h +18 -1

index ed5c685..4eed504 100644
@@ -7,6 +7,23 @@
 #ifndef _TIMER_H_
 #define _TIMER_H_
 
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * timer_conv_64 - convert 32-bit counter value to 64-bit
+ *
+ * @count: 32-bit counter value
+ * @return: 64-bit counter value
+ */
+static inline u64 timer_conv_64(u32 count)
+{
+       /* increment tbh if tbl has rolled over */
+       if (count < gd->timebase_l)
+               gd->timebase_h++;
+       gd->timebase_l = count;
+       return ((u64)gd->timebase_h << 32) | gd->timebase_l;
+}
+
 /*
  * Get the current timer count
  *

@@ -14,7 +31,7 @@
  * @count: pointer that returns the current timer count
  * @return: 0 if OK, -ve on error
  */
-int timer_get_count(struct udevice *dev, unsigned long *count);
+int timer_get_count(struct udevice *dev, u64 *count);
 
 /*
  * Get the timer input clock frequency

include/timer.h +0 -0

 };
 
 /*

lib/time.c +6 -4

index b001745..f37a662 100644
@@ -69,9 +69,9 @@ ulong notrace get_tbclk(void)
        return timer_get_rate(gd->timer);
 }
 
-unsigned long notrace timer_read_counter(void)
+uint64_t notrace get_ticks(void)
 {
-       unsigned long count;
+       u64 count;
        int ret;
 
        ret = dm_timer_init();

@@ -84,7 +84,8 @@ unsigned long notrace timer_read_counter(void)
 
        return count;
 }
-#endif /* CONFIG_TIMER */
+
+#else /* !CONFIG_TIMER */
 
 uint64_t __weak notrace get_ticks(void)
 {

@@ -97,6 +98,8 @@ uint64_t __weak notrace get_ticks(void)
        return ((uint64_t)gd->timebase_h << 32) | gd->timebase_l;
 }
 
+#endif /* CONFIG_TIMER */
+
 /* Returns time in milliseconds */
 static uint64_t notrace tick_to_time(uint64_t tick)
 {
--

1.8.2.1

Hi Bin,

Quoted 18 lines · Bin Meng

There are timers with a 64-bit counter value but current timer uclass driver assumes a 32-bit one. Modify timer_get_count() to ask timer driver to always return a 64-bit counter value, and provide an inline helper function timer_conv_64() to handle the 32-bit/64-bit conversion automatically.

Signed-off-by Bin Meng <[email protected]>

---

Changes in v3:
- Update commit message to reflect the v2 changes (ie: there is no "counter-64bit" property)

Changes in v2:
- Do not use "counter-64bit" property, instead create an inline function for 32-bit timer driver to construct a 64-bit timer value.

Quoted 6 lines

 drivers/timer/altera_timer.c  |  4 ++--
 drivers/timer/sandbox_timer.c |  2 +-
 drivers/timer/timer-uclass.c  |  8 +++-----
 include/timer.h               | 23 ++++++++++++++++++++---
 lib/time.c                    |  9 ++++++---
 5 files changed, 32 insertions(+), 14 deletions(-)

Is there a binding file for this timer somewhere? If both altera and sandbox share this property, should we add a generic binding? It doesn't look like Linux has one though.

Quoted 97 lines

drivers/timer/altera_timer.c +2 -2

index 6fe24f2..a7ed3cc 100644
@@ -34,7 +34,7 @@ struct altera_timer_platdata {
        struct altera_timer_regs *regs;
 };
 
-static int altera_timer_get_count(struct udevice *dev, unsigned long *count)
+static int altera_timer_get_count(struct udevice *dev, u64 *count)
 {
        struct altera_timer_platdata *plat = dev->platdata;
        struct altera_timer_regs *const regs = plat->regs;

@@ -46,7 +46,7 @@ static int altera_timer_get_count(struct udevice *dev, unsigned long *count)
        /* Read timer value */
        val = readl(&regs->snapl) & 0xffff;
        val |= (readl(&regs->snaph) & 0xffff) << 16;
-       *count = ~val;
+       *count = timer_conv_64(~val);
 
        return 0;
 }

drivers/timer/sandbox_timer.c +1 -1

index 4b20af2..00a9944 100644
@@ -18,7 +18,7 @@ void sandbox_timer_add_offset(unsigned long offset)
        sandbox_timer_offset += offset;
 }
 
-static int sandbox_timer_get_count(struct udevice *dev, unsigned long *count)
+static int sandbox_timer_get_count(struct udevice *dev, u64 *count)
 {
        *count = os_get_nsec() / 1000 + sandbox_timer_offset * 1000;
 

drivers/timer/timer-uclass.c +3 -5

index 0218591..1ef0012 100644
@@ -9,18 +9,16 @@
 #include <errno.h>
 #include <timer.h>
 
-DECLARE_GLOBAL_DATA_PTR;
-
 /*
  * Implement a timer uclass to work with lib/time.c. The timer is usually
- * a 32 bits free-running up counter. The get_rate() method is used to get
+ * a 32/64 bits free-running up counter. The get_rate() method is used to get
  * the input clock frequency of the timer. The get_count() method is used
- * to get the current 32 bits count value. If the hardware is counting down,
+ * to get the current 64 bits count value. If the hardware is counting down,
  * the value should be inversed inside the method. There may be no real
  * tick, and no timer interrupt.
  */
 
-int timer_get_count(struct udevice *dev, unsigned long *count)
+int timer_get_count(struct udevice *dev, u64 *count)
 {
        const struct timer_ops *ops = device_get_ops(dev);
 

include/timer.h +18 -1

index ed5c685..4eed504 100644
@@ -7,6 +7,23 @@
 #ifndef _TIMER_H_
 #define _TIMER_H_
 
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * timer_conv_64 - convert 32-bit counter value to 64-bit
+ *
+ * @count: 32-bit counter value
+ * @return: 64-bit counter value
+ */
+static inline u64 timer_conv_64(u32 count)
+{
+       /* increment tbh if tbl has rolled over */
+       if (count < gd->timebase_l)
+               gd->timebase_h++;
+       gd->timebase_l = count;
+       return ((u64)gd->timebase_h << 32) | gd->timebase_l;
+}
+
 /*
  * Get the current timer count
  *

@@ -14,7 +31,7 @@
  * @count: pointer that returns the current timer count
  * @return: 0 if OK, -ve on error
  */
-int timer_get_count(struct udevice *dev, unsigned long *count);
+int timer_get_count(struct udevice *dev, u64 *count);
 

include/timer.h struct timer_ops { · line 58

Quoted 12 lines

include/timer.h +2 -2

 /*
  * Get the timer input clock frequency

@@ -35,10 +52,10 @@ struct timer_ops {
         * Get the current timer count
         *
         * @dev: The timer device
-        * @count: pointer that returns the current timer count
+        * @count: pointer that returns the current 64-bit timer count
         * @return: 0 if OK, -ve on error
         */
-       int (*get_count)(struct udevice *dev, unsigned long *count);
+       int (*get_count)(struct udevice *dev, u64 *count);

Why do we need to change the API to 64-bit?

My only concern is that we are pretty happy with the 32-bit timer and I'm not sure it should change. At present unsigned long can be 32-bit on 32-bit machines.

Quoted 34 lines

include/timer.h +0 -0

 };
 
 /*

lib/time.c +4 -3

index b001745..f37a662 100644
@@ -69,9 +69,9 @@ ulong notrace get_tbclk(void)
        return timer_get_rate(gd->timer);
 }
 
-unsigned long notrace timer_read_counter(void)
+uint64_t notrace get_ticks(void)
 {
-       unsigned long count;
+       u64 count;
        int ret;
 
        ret = dm_timer_init();

@@ -84,7 +84,8 @@ unsigned long notrace timer_read_counter(void)
 
        return count;
 }
-#endif /* CONFIG_TIMER */
+
+#else /* !CONFIG_TIMER */
 
 uint64_t __weak notrace get_ticks(void)
 {

@@ -97,6 +98,8 @@ uint64_t __weak notrace get_ticks(void)
        return ((uint64_t)gd->timebase_h << 32) | gd->timebase_l;
 }
 

lib/time.c uint64_t __weak notrace get_ticks(void)

Quoted 6 lines

lib/time.c +2 -1

+#endif /* CONFIG_TIMER */
+
 /* Returns time in milliseconds */
 static uint64_t notrace tick_to_time(uint64_t tick)
 {
--

Hi Simon,

Quoted 129 lines · Simon Glass

Hi Bin,

Quoted 18 lines · Bin Meng

There are timers with a 64-bit counter value but current timer uclass driver assumes a 32-bit one. Modify timer_get_count() to ask timer driver to always return a 64-bit counter value, and provide an inline helper function timer_conv_64() to handle the 32-bit/64-bit conversion automatically.

Signed-off-by Bin Meng <[email protected]>

---

Changes in v3:
- Update commit message to reflect the v2 changes (ie: there is no "counter-64bit" property)

Changes in v2:
- Do not use "counter-64bit" property, instead create an inline function for 32-bit timer driver to construct a 64-bit timer value.

Quoted 6 lines

 drivers/timer/altera_timer.c  |  4 ++--
 drivers/timer/sandbox_timer.c |  2 +-
 drivers/timer/timer-uclass.c  |  8 +++-----
 include/timer.h               | 23 ++++++++++++++++++++---
 lib/time.c                    |  9 ++++++---
 5 files changed, 32 insertions(+), 14 deletions(-)

Is there a binding file for this timer somewhere? If both altera and sandbox share this property, should we add a generic binding? It doesn't look like Linux has one though.

Quoted 97 lines

drivers/timer/altera_timer.c +2 -2

index 6fe24f2..a7ed3cc 100644
@@ -34,7 +34,7 @@ struct altera_timer_platdata {
        struct altera_timer_regs *regs;
 };
 
-static int altera_timer_get_count(struct udevice *dev, unsigned long *count)
+static int altera_timer_get_count(struct udevice *dev, u64 *count)
 {
        struct altera_timer_platdata *plat = dev->platdata;
        struct altera_timer_regs *const regs = plat->regs;

@@ -46,7 +46,7 @@ static int altera_timer_get_count(struct udevice *dev, unsigned long *count)
        /* Read timer value */
        val = readl(&regs->snapl) & 0xffff;
        val |= (readl(&regs->snaph) & 0xffff) << 16;
-       *count = ~val;
+       *count = timer_conv_64(~val);
 
        return 0;
 }

drivers/timer/sandbox_timer.c +1 -1

index 4b20af2..00a9944 100644
@@ -18,7 +18,7 @@ void sandbox_timer_add_offset(unsigned long offset)
        sandbox_timer_offset += offset;
 }
 
-static int sandbox_timer_get_count(struct udevice *dev, unsigned long *count)
+static int sandbox_timer_get_count(struct udevice *dev, u64 *count)
 {
        *count = os_get_nsec() / 1000 + sandbox_timer_offset * 1000;
 

drivers/timer/timer-uclass.c +3 -5

index 0218591..1ef0012 100644
@@ -9,18 +9,16 @@
 #include <errno.h>
 #include <timer.h>
 
-DECLARE_GLOBAL_DATA_PTR;
-
 /*
  * Implement a timer uclass to work with lib/time.c. The timer is usually
- * a 32 bits free-running up counter. The get_rate() method is used to get
+ * a 32/64 bits free-running up counter. The get_rate() method is used to get
  * the input clock frequency of the timer. The get_count() method is used
- * to get the current 32 bits count value. If the hardware is counting down,
+ * to get the current 64 bits count value. If the hardware is counting down,
  * the value should be inversed inside the method. There may be no real
  * tick, and no timer interrupt.
  */
 
-int timer_get_count(struct udevice *dev, unsigned long *count)
+int timer_get_count(struct udevice *dev, u64 *count)
 {
        const struct timer_ops *ops = device_get_ops(dev);
 

include/timer.h +18 -1

index ed5c685..4eed504 100644
@@ -7,6 +7,23 @@
 #ifndef _TIMER_H_
 #define _TIMER_H_
 
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * timer_conv_64 - convert 32-bit counter value to 64-bit
+ *
+ * @count: 32-bit counter value
+ * @return: 64-bit counter value
+ */
+static inline u64 timer_conv_64(u32 count)
+{
+       /* increment tbh if tbl has rolled over */
+       if (count < gd->timebase_l)
+               gd->timebase_h++;
+       gd->timebase_l = count;
+       return ((u64)gd->timebase_h << 32) | gd->timebase_l;
+}
+
 /*
  * Get the current timer count
  *

@@ -14,7 +31,7 @@
  * @count: pointer that returns the current timer count
  * @return: 0 if OK, -ve on error
  */
-int timer_get_count(struct udevice *dev, unsigned long *count);
+int timer_get_count(struct udevice *dev, u64 *count);
 

Quoted 14 lines

include/timer.h struct timer_ops { · line 58

Quoted 12 lines

include/timer.h +2 -2

 /*
  * Get the timer input clock frequency

@@ -35,10 +52,10 @@ struct timer_ops {
         * Get the current timer count
         *
         * @dev: The timer device
-        * @count: pointer that returns the current timer count
+        * @count: pointer that returns the current 64-bit timer count
         * @return: 0 if OK, -ve on error
         */
-       int (*get_count)(struct udevice *dev, unsigned long *count);
+       int (*get_count)(struct udevice *dev, u64 *count);

Why do we need to change the API to 64-bit?

IMHO, this API should be created to be accept a 64-bit value in the first place. As you see the U-Boot time APIs in lib/time.c like get_ticks() has been using 64-bit value.

Quoted 5 lines

My only concern is that we are pretty happy with the 32-bit timer and I'm not sure it should change. At present unsigned long can be 32-bit on 32-bit machines.

32-bit timer has to be converted to 64-bit value as get_ticks() requires 64-bit. As for 'unsigned long can be 32-bit on 32-bit machines', I think we should explicitly declare its width as this is hardware limitation (32-bit timer can only produce 32-bit value, even if it is on a 64-bit machine, where long on 64-bit means 64-bit, which is wrong for this 32-bit timer hardware).

Quoted 35 lines

Quoted 35 lines

include/timer.h +0 -0

 };
 
 /*

lib/time.c +4 -3

index b001745..f37a662 100644
@@ -69,9 +69,9 @@ ulong notrace get_tbclk(void)
        return timer_get_rate(gd->timer);
 }
 
-unsigned long notrace timer_read_counter(void)
+uint64_t notrace get_ticks(void)
 {
-       unsigned long count;
+       u64 count;
        int ret;
 
        ret = dm_timer_init();

@@ -84,7 +84,8 @@ unsigned long notrace timer_read_counter(void)
 
        return count;
 }
-#endif /* CONFIG_TIMER */
+
+#else /* !CONFIG_TIMER */
 
 uint64_t __weak notrace get_ticks(void)
 {

@@ -97,6 +98,8 @@ uint64_t __weak notrace get_ticks(void)
        return ((uint64_t)gd->timebase_h << 32) | gd->timebase_l;
 }
 

Quoted 6 lines

lib/time.c uint64_t __weak notrace get_ticks(void)

Quoted 6 lines

lib/time.c +2 -1

+#endif /* CONFIG_TIMER */
+
 /* Returns time in milliseconds */
 static uint64_t notrace tick_to_time(uint64_t tick)
 {
--

Regards,
Bin

Quoted 13 lines

Quoted 4 lines

Quoted 4 lines

include/timer.h +0 -0

@@ -35,10 +52,10 @@ struct timer_ops {
          * Get the current timer count
          *
          * @dev: The timer device

Quoted 8 lines

include/timer.h struct timer_ops { · line 58

Quoted 6 lines

include/timer.h +2 -2

-        * @count: pointer that returns the current timer count
+        * @count: pointer that returns the current 64-bit timer count
          * @return: 0 if OK, -ve on error
          */
-       int (*get_count)(struct udevice *dev, unsigned long *count);
+       int (*get_count)(struct udevice *dev, u64 *count);

Why do we need to change the API to 64-bit?

Quoted 3 lines

IMHO, this API should be created to be accept a 64-bit value in the first place. As you see the U-Boot time APIs in lib/time.c like get_ticks() has been using 64-bit value.

Right, but the point of this timer is for time delays. Making everyone one of those 64-bit on a 32-bit machine does not seem like a win to me.

Quoted 6 lines

Quoted 5 lines

My only concern is that we are pretty happy with the 32-bit timer and I'm not sure it should change. At present unsigned long can be 32-bit on 32-bit machines.

Quoted 6 lines

32-bit timer has to be converted to 64-bit value as get_ticks() requires 64-bit. As for 'unsigned long can be 32-bit on 32-bit machines', I think we should explicitly declare its width as this is hardware limitation (32-bit timer can only produce 32-bit value, even if it is on a 64-bit machine, where long on 64-bit means 64-bit, which is wrong for this 32-bit timer hardware).

This is a bit messy, but for now I think we should follow what get_timer() does. It would be worth getting more input on the list I think.

Hi Simon,

Quoted 40 lines · Simon Glass

Quoted 16 lines

Quoted 14 lines

include/timer.h struct timer_ops { · line 58

Quoted 11 lines

include/timer.h +2 -2

@@ -35,10 +52,10 @@ struct timer_ops {
          * Get the current timer count
          *
          * @dev: The timer device
-        * @count: pointer that returns the current timer count
+        * @count: pointer that returns the current 64-bit timer count
          * @return: 0 if OK, -ve on error
          */
-       int (*get_count)(struct udevice *dev, unsigned long *count);
+       int (*get_count)(struct udevice *dev, u64 *count);

Why do we need to change the API to 64-bit?

Quoted 3 lines

IMHO, this API should be created to be accept a 64-bit value in the first place. As you see the U-Boot time APIs in lib/time.c like get_ticks() has been using 64-bit value.

Right, but the point of this timer is for time delays. Making everyone one of those 64-bit on a 32-bit machine does not seem like a win to me.

Quoted 7 lines

Quoted 5 lines

My only concern is that we are pretty happy with the 32-bit timer and I'm not sure it should change. At present unsigned long can be 32-bit on 32-bit machines.

Quoted 6 lines

32-bit timer has to be converted to 64-bit value as get_ticks() requires 64-bit. As for 'unsigned long can be 32-bit on 32-bit machines', I think we should explicitly declare its width as this is hardware limitation (32-bit timer can only produce 32-bit value, even if it is on a 64-bit machine, where long on 64-bit means 64-bit, which is wrong for this 32-bit timer hardware).

Quoted 4 lines

This is a bit messy, but for now I think we should follow what get_timer() does. It would be worth getting more input on the list I think.

I would agree with Bin that the API should have been created as 64 bits. I considered this option before, because most part of lib/time.c uses 64 bits. It was only that I didn't have much confidence to change so many global code (without buildman). I realized this mistake when I wrote the sandbox timer. It is wasteful to truncate the 64 bits count to 32 bits, and then reconstruct 32 bits to 64 bits. This is what Bin wanted to resolve. There is no overhead for 32 bits timer, as the patch only shift the 64 bits conversion from lib/time.c to driver. Yet for 64 bits timer, this is a good saving.

Hi,

Quoted 49 lines · Thomas Chou

Hi Simon,

Quoted 40 lines · Simon Glass

Quoted 16 lines

Quoted 14 lines

include/timer.h struct timer_ops { · line 58

Quoted 11 lines

include/timer.h +2 -2

@@ -35,10 +52,10 @@ struct timer_ops {
          * Get the current timer count
          *
          * @dev: The timer device
-        * @count: pointer that returns the current timer count
+        * @count: pointer that returns the current 64-bit timer count
          * @return: 0 if OK, -ve on error
          */
-       int (*get_count)(struct udevice *dev, unsigned long *count);
+       int (*get_count)(struct udevice *dev, u64 *count);

Why do we need to change the API to 64-bit?

Quoted 3 lines

IMHO, this API should be created to be accept a 64-bit value in the first place. As you see the U-Boot time APIs in lib/time.c like get_ticks() has been using 64-bit value.

Right, but the point of this timer is for time delays. Making everyone one of those 64-bit on a 32-bit machine does not seem like a win to me.

Quoted 7 lines

Quoted 5 lines

My only concern is that we are pretty happy with the 32-bit timer and I'm not sure it should change. At present unsigned long can be 32-bit on 32-bit machines.

Quoted 6 lines

32-bit timer has to be converted to 64-bit value as get_ticks() requires 64-bit. As for 'unsigned long can be 32-bit on 32-bit machines', I think we should explicitly declare its width as this is hardware limitation (32-bit timer can only produce 32-bit value, even if it is on a 64-bit machine, where long on 64-bit means 64-bit, which is wrong for this 32-bit timer hardware).

Quoted 4 lines

This is a bit messy, but for now I think we should follow what get_timer() does. It would be worth getting more input on the list I think.

Quoted 9 lines

I would agree with Bin that the API should have been created as 64 bits. I considered this option before, because most part of lib/time.c uses 64 bits. It was only that I didn't have much confidence to change so many global code (without buildman). I realized this mistake when I wrote the sandbox timer. It is wasteful to truncate the 64 bits count to 32 bits, and then reconstruct 32 bits to 64 bits. This is what Bin wanted to resolve. There is no overhead for 32 bits timer, as the patch only shift the 64 bits conversion from lib/time.c to driver. Yet for 64 bits timer, this is a good saving.

OK thank you both for your explanation. This makes sense to me now.

Acked-by Simon Glass <[email protected]>

Unfortunately this causes build errors for a few avr32 boards - e.g. grasshopper.

I think the problem is the gd declaration in the timer.h header file. I don't think that is a good idea. Can we move it to the C file?

Hi Simon,

Quoted 5 lines · Simon Glass

Unfortunately this causes build errors for a few avr32 boards - e.g. grasshopper.

Quoted 2 lines

I think the problem is the gd declaration in the timer.h header file. I don't think that is a good idea. Can we move it to the C file?

If you meant, "warning: input is not relaxable", it is fixed after commit f300dccde433 ("i2c, avr32: fix compiler warning "input is not relaxable""). The u-boot-dm/testing branch does not have such warning.

Hi Thomas,

Quoted 8 lines · Thomas Chou

Hi Simon,

Quoted 5 lines · Simon Glass

Unfortunately this causes build errors for a few avr32 boards - e.g. grasshopper.

Quoted 7 lines

Quoted 2 lines

I think the problem is the gd declaration in the timer.h header file. I don't think that is a good idea. Can we move it to the C file?

If you meant, "warning: input is not relaxable", it is fixed after commit f300dccde433 ("i2c, avr32: fix compiler warning "input is not relaxable""). The u-boot-dm/testing branch does not have such warning.

Please try u-boot-dm/testing. This seems to be a different problem:

avr32: + grasshopper
+lib/time.c:20: warning: register used for two global register variables

We should not declare the global_data pointer in a header file.

Bin, are you able to take a look? Perhaps the function that needs it should move to the C file?

Please try u-boot-dm/testing. This seems to be a different problem:

avr32: + grasshopper
+lib/time.c:20: warning: register used for two global register variables

Hi Simon,

Quoted 4 lines · Simon Glass

Please try u-boot-dm/testing. This seems to be a different problem:

Quoted 3 lines

avr32: + grasshopper
+lib/time.c:20: warning: register used for two global register variables

I am using the avr32 toolchain from kernel.org, and couldn't see the problem.
gcc version 4.2.4-atmel.1.1.3.avr32linux.1

Would you please offer the link to download the avr32 toolchain you used?

Quoted 11 lines · Thomas Chou

Hi Simon,

Quoted 7 lines · Simon Glass

Please try u-boot-dm/testing. This seems to be a different problem:

avr32: + grasshopper
+lib/time.c:20: warning: register used for two global register variables

Quoted 3 lines

I am using the avr32 toolchain from kernel.org, and couldn't see the problem.
gcc version 4.2.4-atmel.1.1.3.avr32linux.1

For me, I cannot reproduce the build error too with buildman. I am using the same toolchain as Thomas.

Quoted 2 lines

Would you please offer the link to download the avr32 toolchain you used?

Hi,

Quoted 12 lines · Bin Meng

Quoted 11 lines · Thomas Chou

Hi Simon,

Quoted 7 lines · Simon Glass

Please try u-boot-dm/testing. This seems to be a different problem:

avr32: + grasshopper
+lib/time.c:20: warning: register used for two global register variables

Quoted 8 lines

Quoted 3 lines

I am using the avr32 toolchain from kernel.org, and couldn't see the problem.
gcc version 4.2.4-atmel.1.1.3.avr32linux.1

For me, I cannot reproduce the build error too with buildman. I am using the same toolchain as Thomas.

Quoted 2 lines

Would you please offer the link to download the avr32 toolchain you used?

It is avr32-buildroot-linux-uclibc-gcc

Target: avr32-buildroot-linux-uclibc
Configured with:
/home/sjg/c/buildroot/buildroot-2013.02/output/toolchain/gcc-4.2.2-avr32-2.1.5/configure --prefix=/home/sjg/c/buildroot/buildroot-2013.02/output/host/usr --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=avr32-buildroot-linux-uclibc --enable-languages=c --with-sysroot=/home/sjg/c/buildroot/buildroot-2013.02/output/host/usr/avr32-buildroot-linux-uclibc/sysroot --with-build-time-tools=/home/sjg/c/buildroot/buildroot-2013.02/output/host/usr/avr32-buildroot-linux-uclibc/bin --disable-__cxa_atexit --enable-target-optspace --disable-libquadmath
--disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib
--disable-tls --enable-shared --with-gmp=/home/sjg/c/buildroot/buildroot-2013.02/output/host/usr --with-mpfr=/home/sjg/c/buildroot/buildroot-2013.02/output/host/usr
--disable-nls --enable-threads --disable-largefile
--disable-libmudflap
Thread model: posix
gcc version 4.2.2-atmel.1.0.8

So fairly old.

I'm not sure if I built it or downloaded it - it was a while ago.

So perhaps this is a toolchain problem. But still I don't think we want to declare the global_data pointer in a header file.

Hi Bin,

Quoted 18 lines · Bin Meng

There are timers with a 64-bit counter value but current timer uclass driver assumes a 32-bit one. Modify timer_get_count() to ask timer driver to always return a 64-bit counter value, and provide an inline helper function timer_conv_64() to handle the 32-bit/64-bit conversion automatically.

Signed-off-by Bin Meng <[email protected]>

---

Changes in v3:
- Update commit message to reflect the v2 changes (ie: there is no "counter-64bit" property)

Changes in v2:
- Do not use "counter-64bit" property, instead create an inline function for 32-bit timer driver to construct a 64-bit timer value.

Quoted 6 lines

 drivers/timer/altera_timer.c  |  4 ++--
 drivers/timer/sandbox_timer.c |  2 +-
 drivers/timer/timer-uclass.c  |  8 +++-----
 include/timer.h               | 23 ++++++++++++++++++++---
 lib/time.c                    |  9 ++++++---
 5 files changed, 32 insertions(+), 14 deletions(-)

Is there a binding file for this timer somewhere? If both altera and sandbox share this property, should we add a generic binding? It doesn't look like Linux has one though.

This series enhances timer uclass driver to support 64-bit counter value, and convert tsc timer to driver model to be used by all x86 boards.

As a result of dm conversion, the TSC_CALIBRATION_BYPASS Kconfig option is no longer needed, and the TSC frequency can be specified in the board device tree.

This v2 is rebased on top of u-boot-dm/master, to resolve conflicts with Altera timer updates and the new Sandbox timer driver.

Changes in v3:
- Update commit message to reflect the v2 changes (ie: there is no "counter-64bit" property)
- Really remove "counter-64bit" property from tsc_timer.dtsi

Changes in v2:
- Rebase on u-boot-dm/master
- Change 'Timer' to 'timer' in the sandbox timer Kconfig
- New patch to use device tree to pass the clock frequency
- Do not use "counter-64bit" property, instead create an inline function for 32-bit timer driver to construct a 64-bit timer value.
- Remove "counter-64bit" property

Bin Meng (11):
dm: timer: Fix several nits
dm: timer: Implement pre_probe()
timer: altera: Remove the codes to get clock frequency
timer: sandbox: Use device tree to pass the clock frequency
dm: timer: Support 64-bit counter
x86: Reomve MIN_PORT80_KCLOCKS_DELAY
x86: tsc: Use notrace from <linux/compiler.h>
x86: tsc: Add driver model timer support
x86: Convert to use driver model timer
x86: tsc: Remove legacy timer codes
x86: tsc: Move tsc_timer.c to drivers/timer

  arch/sandbox/dts/sandbox.dts                |   1 +
  arch/x86/Kconfig                            |  20 ------
  arch/x86/cpu/baytrail/valleyview.c          |   3 -
  arch/x86/cpu/coreboot/timestamp.c           |  22 ------
  arch/x86/cpu/cpu.c                          |  18 -----
  arch/x86/cpu/efi/efi.c                      |   4 --
  arch/x86/cpu/ivybridge/cpu.c                |   1 -
  arch/x86/cpu/qemu/Kconfig                   |   1 -
  arch/x86/cpu/qemu/qemu.c                    |   3 -
  arch/x86/cpu/quark/Kconfig                  |   5 --
  arch/x86/cpu/quark/quark.c                  |   3 -
  arch/x86/cpu/queensbay/tnc.c                |   3 -
  arch/x86/dts/bayleybay.dts                  |   1 +
  arch/x86/dts/broadwell_som-6896.dts         |   1 +
  arch/x86/dts/chromebook_link.dts            |   1 +
  arch/x86/dts/chromebox_panther.dts          |   1 +
  arch/x86/dts/crownbay.dts                   |   1 +
  arch/x86/dts/efi.dts                        |   5 ++
  arch/x86/dts/galileo.dts                    |   5 ++
  arch/x86/dts/minnowmax.dts                  |   1 +
  arch/x86/dts/qemu-x86_i440fx.dts            |   5 ++
  arch/x86/dts/qemu-x86_q35.dts               |   5 ++
  arch/x86/dts/tsc_timer.dtsi                 |   6 ++
  arch/x86/include/asm/global_data.h          |   3 -
  arch/x86/lib/Makefile                       |   1 -
  configs/bayleybay_defconfig                 |   1 +
  configs/chromebook_link_defconfig           |   2 +-
  configs/chromebox_panther_defconfig         |   2 +-
  configs/coreboot-x86_defconfig              |   3 +-
  configs/crownbay_defconfig                  |   1 +
  configs/efi-x86_defconfig                   |   2 +-
  configs/galileo_defconfig                   |   1 +
  configs/minnowmax_defconfig                 |   1 +
  configs/qemu-x86_defconfig                  |   1 +
  drivers/timer/Kconfig                       |  19 +++--
  drivers/timer/Makefile                      |   1 +
  drivers/timer/altera_timer.c                |  10 +--
  drivers/timer/sandbox_timer.c               |   6 +-
  drivers/timer/timer-uclass.c                |  19 +++--
  {arch/x86/lib => drivers/timer}/tsc_timer.c | 104 ++++++++++++++++------------
  include/configs/x86-common.h                |   2 -
  include/timer.h                             |  34 ++++++---
  lib/time.c                                  |   9 ++-
  43 files changed, 164 insertions(+), 174 deletions(-)

create mode 100644 arch/x86/dts/tsc_timer.dtsi rename {arch/x86/lib => drivers/timer}/tsc_timer.c (87%)