Skip to contentSkip to conversation

clocksource/drivers/atcpit100: Add andestech atcpit100 timer

PATCH Superseded Greentime Hu 3 participants 8 messages Jan 15, 2018 – Jan 20, 2018

Subsystems (6)

v6 of 7 Superseded Latest is v7 →

lore
Share & tools
lore
#0 lore raw

v6 cover clocksource/drivers/atcpit100: Add andestech atcpit100 timer

ATCPIT100 is often used on the Andes architecture, This timer provide 4 PIT channels. Each PIT channel is a multi-function timer, can be configured as 32,16,8 bit timers or PWM as well.

For system timer it will set channel 1 32-bit timer0 as clock source and count downwards until underflow and restart again.

It also set channel 0 32-bit timer0 as clock event and count downwards until condition match. It will generate an interrupt for handling periodically.

Changes in v6:
- To select TIMER_OF in drivers/clocksource/Kconfig instead of arch/nds32/Kconfig
- Refine Kconfig
- Update license format to SPDX-License-Identifier

Rick Chen (3):
clocksource/drivers/atcpit100: Add andestech atcpit100 timer clocksource/drivers/atcpit100: VDSO support
dt-bindings: timer: Add andestech atcpit100 timer binding doc

 .../bindings/timer/andestech,atcpit100-timer.txt   |   33 +++
 drivers/clocksource/Kconfig                        |    9 +
 drivers/clocksource/Makefile                       |    1 +
 drivers/clocksource/timer-atcpit100.c              |  262 ++++++++++++++++++++
 4 files changed, 305 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
 create mode 100644 drivers/clocksource/timer-atcpit100.c
Signature · 1 line
1.7.9.5
#1 lore raw

PATCH v6 1/3 clocksource/drivers/atcpit100: Add andestech atcpit100 timer

From: Rick Chen <[email protected]>

ATCPIT100 is often used on the Andes architecture, This timer provide 4 PIT channels. Each PIT channel is a multi-function timer, can be configured as 32,16,8 bit timers or PWM as well.

For system timer it will set channel 1 32-bit timer0 as clock source and count downwards until underflow and restart again.

It also set channel 0 32-bit timer0 as clock event and count downwards until condition match. It will generate an interrupt for handling periodically.

---
 drivers/clocksource/Kconfig           |    9 ++
 drivers/clocksource/Makefile          |    1 +
 drivers/clocksource/timer-atcpit100.c |  244 +++++++++++++++++++++++++++++++++
 3 files changed, 254 insertions(+)
 create mode 100644 drivers/clocksource/timer-atcpit100.c
drivers/clocksource/Kconfig +9 -0
index cc60620..5014949 100644
@@ -615,4 +615,13 @@ config CLKSRC_ST_LPC
 	  Enable this option to use the Low Power controller timer
 	  as clocksource.
 
+config ATCPIT100_TIMER
+	bool "ATCPIT100 timer driver"
+	depends on NDS32 || COMPILE_TEST
+	depends on HAS_IOMEM
+	select TIMER_OF
+	default NDS32
+	help
+	  This option enables support for the Andestech ATCPIT100 timers.
+
 endmenu
drivers/clocksource/Makefile +1 -0
index 72711f1..7403a19 100644
@@ -75,3 +75,4 @@ obj-$(CONFIG_H8300_TMR16)		+= h8300_timer16.o
 obj-$(CONFIG_H8300_TPU)			+= h8300_tpu.o
 obj-$(CONFIG_CLKSRC_ST_LPC)		+= clksrc_st_lpc.o
 obj-$(CONFIG_X86_NUMACHIP)		+= numachip.o
+obj-$(CONFIG_ATCPIT100_TIMER)		+= timer-atcpit100.o
drivers/clocksource/timer-atcpit100.c new file +244 -0

244 lines not on this page · raw message

Signature · 1 line
1.7.9.5
#2 lore raw

PATCH v6 2/3 clocksource/drivers/atcpit100: VDSO support

In reply to Greentime Hu

From: Rick Chen <[email protected]>

VDSO needs real-time cycle count to ensure the time accuracy. Unlike others, nds32 architecture does not define clock source, hence VDSO needs atcpit100 offering real-time cycle count to derive the correct time.

---
 drivers/clocksource/timer-atcpit100.c |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
drivers/clocksource/timer-atcpit100.c +18 -0
index e34b2fe..4cf69e2 100644
@@ -18,6 +18,9 @@
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include "timer-of.h"
+#ifdef CONFIG_NDS32
+#include <asm/vdso_timer_info.h>
+#endif
 
 /*
  * Definition of register offsets
@@ -200,6 +203,17 @@ static u64 notrace atcpit100_timer_sched_read(void)
 	return ~readl(timer_of_base(&to) + CH1_CNT);
 }
 
+#ifdef CONFIG_NDS32
+static void fill_vdso_need_info(struct device_node *node)
+{
+	struct resource timer_res;
+	of_address_to_resource(node, 0, &timer_res);
+	timer_info.mapping_base = (unsigned long)timer_res.start;
+	timer_info.cycle_count_down = true;
+	timer_info.cycle_count_reg_offset = CH1_CNT;
+}
+#endif
+
 static int __init atcpit100_timer_init(struct device_node *node)
 {
 	int ret;
@@ -238,6 +252,10 @@ static int __init atcpit100_timer_init(struct device_node *node)
 	val = readl(base + INT_EN);
 	writel(val | CH0INT0EN, base + INT_EN);
 
+#ifdef CONFIG_NDS32
+	fill_vdso_need_info(node);
+#endif
+
 	return ret;
 }
 
Signature · 1 line
1.7.9.5
maintainer
#3 lore raw

Re: [PATCH v6 2/3] clocksource/drivers/atcpit100: VDSO support

Quoted 10 lines · Greentime Hu

From: Rick Chen <[email protected]>

VDSO needs real-time cycle count to ensure the time accuracy. Unlike others, nds32 architecture does not define clock source, hence VDSO needs atcpit100 offering real-time cycle count to derive the correct time.

I'm a bit puzzled by this patch, can you explain how the vdso actually manages to access the clock hardware? It looks like you make the physical address and the register offset available to user space, but how does it end up accessing it?

Arnd

#4 lore raw

Re: [PATCH v6 2/3] clocksource/drivers/atcpit100: VDSO support

2018-01-18 19:08 GMT+08:00 Arnd Bergmann <[email protected]>:

Quoted 12 lines · Greentime Hu
Quoted 10 lines

From: Rick Chen <[email protected]>

VDSO needs real-time cycle count to ensure the time accuracy. Unlike others, nds32 architecture does not define clock source, hence VDSO needs atcpit100 offering real-time cycle count to derive the correct time.

Quoted 6 lines

I'm a bit puzzled by this patch, can you explain how the vdso actually manages to access the clock hardware? It looks like you make the physical address and the register offset available to user space, but how does it end up accessing it?

Arnd

Dear Arnd:

Accessing clock hardware in vdso can be divided to 2 step.

1. Setup an additional memory mapping for clock hardware in user space when establishing
vdso-needed memory mapping

In arch_setup_additional_pages(), kernel establishes memory
mapping for vdso's text and vdata page
in user space. In order to make clock hardware be accessible in
user space, we try to establish an
additional memory mapping for clock hardware here based on clock
information from driver. This page is
located between vdata page and vdso text page. For safety, this
region for clock accessing is read-only.

2. Accessing clock hardware in vdso

After step 1, clock hardware is accessible in user space
through memory-mapped IO. However, it is not
enough to access a specific register. Therefore, we store register
offset information in vdata page to make it
visible in user space. Now, vdso can derive the address of counter
register by summation of __get_timerpage()
and counter register offset where __get_timerpage() is used to
derive the virtual address of memory-mapped
clock.

Vincent

#5 lore raw

Re: [PATCH v6 2/3] clocksource/drivers/atcpit100: VDSO support

Correct the composition

Dear Arnd:

1. Setup an additional memory mapping for clock hardware in user space when establishing vdso-needed memory mapping
In arch_setup_additional_pages(), kernel establishes memory
mapping for vdso's text and vdata page in user space. In order to make clock hardware be accessible in user space, we try to establish an additional memory mapping for clock hardware here based on clock information from driver. This page is located between vdata page and vdso text page. For safety, this region for clock accessing is read-only.

2. Accessing clock hardware in vdso
After step 1, clock hardware is accessible in user space through
memory-mapped IO. However, it is not enough to access a specific register. Therefore, we store register offset information in vdata page to make it visible in user space. Now, vdso can derive the address of counter register by summation of __get_timerpage() and counter register offset where __get_timerpage() is used to derive the virtual address of memory-mapped clock.

2018-01-20 19:11 GMT+08:00 Vincent Chen <[email protected]>:

Quoted 51 lines

2018-01-18 19:08 GMT+08:00 Arnd Bergmann <[email protected]>:

Quoted 12 lines · Greentime Hu
Quoted 10 lines

From: Rick Chen <[email protected]>

VDSO needs real-time cycle count to ensure the time accuracy. Unlike others, nds32 architecture does not define clock source, hence VDSO needs atcpit100 offering real-time cycle count to derive the correct time.

Quoted 6 lines

I'm a bit puzzled by this patch, can you explain how the vdso actually manages to access the clock hardware? It looks like you make the physical address and the register offset available to user space, but how does it end up accessing it?

Arnd

Dear Arnd:

Accessing clock hardware in vdso can be divided to 2 step.

1. Setup an additional memory mapping for clock hardware in user space when establishing
vdso-needed memory mapping

In arch_setup_additional_pages(), kernel establishes memory
mapping for vdso's text and vdata page
in user space. In order to make clock hardware be accessible in
user space, we try to establish an
additional memory mapping for clock hardware here based on clock
information from driver. This page is
located between vdata page and vdso text page. For safety, this
region for clock accessing is read-only.

2. Accessing clock hardware in vdso

After step 1, clock hardware is accessible in user space
through memory-mapped IO. However, it is not
enough to access a specific register. Therefore, we store register
offset information in vdata page to make it
visible in user space. Now, vdso can derive the address of counter
register by summation of __get_timerpage()
and counter register offset where __get_timerpage() is used to
derive the virtual address of memory-mapped
clock.

Vincent

#6 lore raw

PATCH v6 3/3 dt-bindings: timer: Add andestech atcpit100 timer binding doc

In reply to Greentime Hu

From: Rick Chen <[email protected]>

Add a document to describe Andestech atcpit100 timer and binding information.

---
 .../bindings/timer/andestech,atcpit100-timer.txt   |   33 ++++++++++++++++++++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt new file +33 -0
new file mode 100644
index 0000000..4c9ea59
@@ -0,0 +1,33 @@
+Andestech ATCPIT100 timer
+------------------------------------------------------------------
+ATCPIT100 is a generic IP block from Andes Technology, embedded in
+Andestech AE3XX platforms and other designs.
+
+This timer is a set of compact multi-function timers, which can be
+used as pulse width modulators (PWM) as well as simple timers.
+
+It supports up to 4 PIT channels. Each PIT channel is a
+multi-function timer and provide the following usage scenarios:
+One 32-bit timer
+Two 16-bit timers
+Four 8-bit timers
+One 16-bit PWM
+One 16-bit timer and one 8-bit PWM
+Two 8-bit timer and one 8-bit PWM
+
+Required properties:
+- compatible	: Should be "andestech,atcpit100"
+- reg		: Address and length of the register set
+- interrupts	: Reference to the timer interrupt
+- clocks 	: a clock to provide the tick rate for "andestech,atcpit100"
+- clock-names 	: should be "PCLK" for the peripheral clock source.
+
+Examples:
+
+timer0: timer@f0400000 {
+	compatible = "andestech,atcpit100";
+	reg = <0xf0400000 0x1000>;
+	interrupts = <2>;
+	clocks = <&apb>;
+	clock-names = "PCLK";
+};
Signature · 1 line
1.7.9.5
maintainer Acked-by on v6 3/3
#7 lore raw

Re: [PATCH v6 3/3] dt-bindings: timer: Add andestech atcpit100 timer binding doc

Quoted 8 lines · Greentime Hu

From: Rick Chen <[email protected]>

Add a document to describe Andestech atcpit100 timer and binding information.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html