|
Re: RFC[1/2] Common logging infrastructure and API
Maybe it did not come clear in my reply, but what I proposed did not
have a global logging level, or rather, the global level is always
"OFF". Each subsystem that you want to log has to enable it,
Maybe it did not come clear in my reply, but what I proposed did not
have a global logging level, or rather, the global level is always
"OFF". Each subsystem that you want to log has to enable it,
|
By
Benjamin Walsh <benjamin.walsh@...>
·
#2440
·
|
|
Re: STM32F103x port
+1
--
Benjamin Walsh, SMTS
Wind River Rocket
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org
+1
--
Benjamin Walsh, SMTS
Wind River Rocket
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org
|
By
Benjamin Walsh <benjamin.walsh@...>
·
#2438
·
|
|
Re: STM32F103x port
<daniel.kalowsky(a)intel.com> wrote:
Single 'x' as in 'everything that comes after the i-1 character' :)
As for the models, I'm not aware of any non STF32F10x MCUs, however
all of these are
<daniel.kalowsky(a)intel.com> wrote:
Single 'x' as in 'everything that comes after the i-1 character' :)
As for the models, I'm not aware of any non STF32F10x MCUs, however
all of these are
|
By
Maciek Borzecki <maciek.borzecki@...>
·
#2437
·
|
|
Re: RFC [0/3] - SoC, CPU LPS, Tickless idle and Device power management
Sure. I will be glad to work with you on making it better. Thanks.
Sure. I will be glad to work with you on making it better. Thanks.
|
By
Thomas, Ramesh
·
#2436
·
|
|
Re: RFC [2/3] - SoC, CPU LPS, Tickless idle and Device power management
device
called
In this RFC I tried to keep the main ideas and feedbacks from the
original RFCs but made some modifications as I encountered issues during
implementation. These should not impact the
device
called
In this RFC I tried to keep the main ideas and feedbacks from the
original RFCs but made some modifications as I encountered issues during
implementation. These should not impact the
|
By
Thomas, Ramesh
·
#2435
·
|
|
Re: STM32F103x port
Hey Pawel,
By
Kalowsky, Daniel <daniel.kalowsky@...>
·
#2434
·
|
|
Re: STM32F103x port
By
Kalowsky, Daniel <daniel.kalowsky@...>
·
#2433
·
|
|
Re: RFC[2/2] Common logging infrastructure and API
By
Kalowsky, Daniel <daniel.kalowsky@...>
·
#2432
·
|
|
Re: RFC [0/3] - SoC, CPU LPS, Tickless idle and Device power management
Hi Ramesh,
By
Kalowsky, Daniel <daniel.kalowsky@...>
·
#2431
·
|
|
Re: RFC[1/2] Common logging infrastructure and API
Implementing this.
+1
I'm supporting this now and will implement this on some reference
module as example for the following patch set.
Implementing this.
+1
I'm supporting this now and will implement this on some reference
module as example for the following patch set.
|
By
Saucedo Tejada, Genaro <genaro.saucedo.tejada@...>
·
#2430
·
|
|
Re: RFC[1/2] Common logging infrastructure and API
I understand, for this first effort the goal is to unify calls under a
single API that can be later provided by different implementations. I
don't foresee conflicts between initial proposal and
I understand, for this first effort the goal is to unify calls under a
single API that can be later provided by different implementations. I
don't foresee conflicts between initial proposal and
|
By
Saucedo Tejada, Genaro <genaro.saucedo.tejada@...>
·
#2429
·
|
|
Re: RFC[2/2] Common logging infrastructure and API
Although a namespace is needed (as noted bellow) debug is not the only
goal of this infrastructure INFO and ERROR level might be used for big
production environments in the future.
I reused some
Although a namespace is needed (as noted bellow) debug is not the only
goal of this infrastructure INFO and ERROR level might be used for big
production environments in the future.
I reused some
|
By
Saucedo Tejada, Genaro <genaro.saucedo.tejada@...>
·
#2428
·
|
|
[RFC v2] uart: add ISR callback mechanism for UART drivers
The peripherals utilizing UART were required to register their own
ISR rountines. This means that all those peripherals drivers need
to know which IRQ line is attached to a UART controller, and
The peripherals utilizing UART were required to register their own
ISR rountines. This means that all those peripherals drivers need
to know which IRQ line is attached to a UART controller, and
|
By
Daniel Leung <daniel.leung@...>
·
#2427
·
|
|
Re: [RFC] Nanokernel timers rework proposal
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
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
|
By
Dmitriy Korovkin
·
#2426
·
|
|
Re: [RFC] Nanokernel timers rework proposal
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
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
|
By
Benjamin Walsh <benjamin.walsh@...>
·
#2425
·
|
|
Re: RFC [3/3] - SoC, CPU LPS, Tickless idle and Device power management
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
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
|
By
Thomas, Ramesh
·
#2424
·
|
|
Re: RFC [3/3] - SoC, CPU LPS, Tickless idle and Device power management
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
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
|
By
Boie, Andrew P
·
#2423
·
|
|
Re: RFC: Counter driver API
By
Tseng, Kuo-Lang <kuo-lang.tseng@...>
·
#2422
·
|
|
Re: RFC: Counter driver API
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?
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?
|
By
Andre Guedes <andre.guedes@...>
·
#2421
·
|
|
Re: RFC: Counter driver API
Missed addressing one comment on write function.
Missed addressing one comment on write function.
|
By
Tseng, Kuo-Lang <kuo-lang.tseng@...>
·
#2420
·
|