-----Original Message-----
From: D'alton, Alexandre
Sent: Monday, February 29, 2016 7:23 AM
To: Brandewie, Dirk J <dirk.j.brandewie(a)intel.com>; Tseng, Kuo-Lang <kuo-
lang.tseng(a)intel.com>; devel(a)lists.zephyrproject.org
Cc: Brandewie, Dirk J <dirk.j.brandewie(a)intel.com>
Subject: RE: [devel] Re: RFC: Counter driver API

There are 2 aon counters:

Aon counter => monotinic counter without interrupt
Aon periodic timer => periodic timer with interrupt support

Thanks for the clarification.

Just to add on top. The Aon counter (AONC), once started, it starts from zero and continuously increments. S/w can read the current value any time but there is no interrupt, like Alexandre pointed out.
The Aon periodic timer (AONPT) allows initial timer value to be loaded and interrupt to be enabled. Once started, it decrements and an interrupt fires when the timer reaches to zero. S/W can also choose to read current value any time, if it needs.

The proposed API interface is generic one; the setting in the counter_input data structure is hardware-specific, i.e. for AONC case, it is not applicable and for AONPT, it is used.

Regards,
Alex.

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



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

Hi,

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

list.

Background
--------------

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.

Proposal:
-----------

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-

specific.

*
* 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:

drivers/quark_aon_counter.c

Comment, feedback welcome.