Hi, The last month has been very busy. Zephyr was launched, we had 2 releases and a lot of changes to address the launch of the project. Sorry about the late notice. Up to the release of the project

Acked-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com>

Hi Daniel, It seems you've missed at least drivers/nble/uart.c that uses both IRQ_CONNECT and irq_enable. Otherwise the change looks fine to me. Johan

Hi Fabian, <fabien.chereau(a)intel.com> wrote: Which is why I commented that having log level is not really necessary, perhaps this is even misleading since it should always be selected at build-time

Hi Luiz, I don't see anything we could do about that in this logging API. If there is something to be done, let's see it in another patch. Nanokernel could get it, it would run in low prio fiber and

Hi,

Hi, I have been working with Dan's stm32 patch to add support for stm32f4xx and just wanted to share couple of thoughts. https://gerrit.zephyrproject.org/r/#/c/209/ I would second the idea of

Thanks for letting me know about this. I will modify and re-submit. If anyone notices anything missing, please let me know. ----- Daniel Leung

Having thought about it for 10 seconds it seems reasonable :-) To the greatest extent reasonable please avoid link time binding of SOC specifc code into the generic stm32 code. We don't want to the

I think it might be useful to add a function to retrieve the timebase of the counter. ATM the developer just needs to *know* what is being counted. A function to set the timebase may be needed in

There is a basic disconnects between my original RFC and this one. In mine all drivers are required to provide an implementation of suspend/resume even if it is null. All the information for the

Do you mind taking a look here https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103-next-soc-layout-change and sending some feedback? The branch implements this layout: arch/ arm/ soc/

Missed addressing one comment on write function.

Hi guys, Quoting D'alton, Alexandre (2016-02-29 12:22:31) In terms of 'implementation details', should we have two drivers under drivers/counter/ e.g. quark_aon_counter.c and quark_aon_timer.c?

With all due respect what are you talking about? Tickless idle and PM are orthogonal! Tickless idle means we don't come out of idle to just serve periodic timer interrupts, we come out of idle for the

This is to give an opportunity for the PM service app to do additional operations saving power around the tickless idle i.e. do more than just rely on the power savings achieved by HLT that is done by

I don't think you need this expired flag: delta_ticks_from_prev is either 0 or -1 when the timeout expires (-1 I think). I would prefer if we had a nano_timer object that is a wrapper around

Yes, after the timeout expires, delta_ticks_from_prev is -1. I agree, we can check it and not use any flag. This can be implemented. In this case nano_timer_test() places the nano_timeout part of