Re: RFC: Counter driver API

Andre Guedes <andre.guedes@...>

Hi guys,

Quoting D'alton, Alexandre (2016-02-29 12:22:31)
There are 2 aon counters:

Aon counter => monotinic counter without interrupt
Aon periodic timer => periodic timer with interrupt support
In terms of 'implementation details', should we have two drivers under
drivers/counter/ e.g. quark_aon_counter.c and quark_aon_timer.c? Both
drivers would implement the counter API being proposed here.

Or we have only one driver (e.g. quark_aon_counters.c) which defines
both devices (e.g. DEVICE_INIT(aon_counter, ...) and DEVICE_INIT(aon_
timer, ...)?



-----Original Message-----
From: Dirk Brandewie [mailto:dirk.j.brandewie(a)]
Sent: Monday, February 29, 2016 16:09
To: Tseng, Kuo-Lang <kuo-lang.tseng(a)>;
Cc: Brandewie, Dirk J <dirk.j.brandewie(a)>
Subject: [devel] Re: RFC: Counter driver API

On 02/26/2016 12:29 PM, Tseng, Kuo-Lang wrote:

As per suggestion from Gerrit comment, moving the discussion to mailing


On Quark (SE and D2000), there are Always On Counter (free running) and
Always ON Periodic Timer devices. A counter|timer driver is to be added for
supporting these devices. At same time, the goal is to create an API that is
generic enough for not just these two specific devices.


Generic counter driver API:
We will have 3 routines - start, stop, and read, which takes in the device
pointer - which identifies the timer. The driver header, counter.h, is under
/include folder:

* @brief Set up counter configuration and start it.
* @param dev Pointer to the device structure for the driver instance.
* @param config Pointer to counter configuration structure
* @retval DEV_OK If successful.
* @retval DEV_* Code otherwise.
int counter_start(struct device *dev, counter_input *config);

* @brief Stop the counter.
* @param dev Pointer to the device structure for the driver instance.
* @retval DEV_OK If successful.
* @retval DEV_* Code otherwise.
int counter_stop(struct device *dev);

* @brief Read current counter value
* @param dev Pointer to the device structure for the driver instance.
* @return 32-bit value
uint32_t counter_read(struct device *dev)

The counter_input structure can be something like below:

* @brief Counter configuration.
* Acceptable setting in the configuration structure is hardware-
* initial_value - Initial value to load to the counter or timer.
* callback - Callback function when timer expires.
struct counter_input {
uint32_t initial_value;
end_count/expiration_count something like like that so the reader knows how
the value is used.

void (*callback)(void);

Note - Using structure, tomorrow we can add more fields for a counter with
more features.
For the Free Running counter in Quark, these fields would be null as it
does not support interrupt or callback notification.
Confused by this note. The always on counter does have an interrupt it the
only way for the device to signal counter expiration.

The hardware-specific driver implementation:

This can be implemented in /drivers directory. For example, for Quark SE
and D2000, we can have below file which implements the API functionality
using the AON Counter and AON Periodic Timer:


Comment, feedback welcome.
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Join to automatically receive all group messages.