Tseng, Kuo-Lang <kuo-lang.tseng@...>
toggle quoted messageShow quoted text
-----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.
|