|
Re: RFC[2/2] Common logging infrastructure and API
Hi Genaro,
<genaro.saucedo.tejada(a)intel.com> wrote:
I welcome these changes but Im not so sure logging levels are actually
necessary if one can define different domains, at least in case
Hi Genaro,
<genaro.saucedo.tejada(a)intel.com> wrote:
I welcome these changes but Im not so sure logging levels are actually
necessary if one can define different domains, at least in case
|
By
Luiz Augusto von Dentz
·
#2326
·
|
|
RFC[2/2] Common logging infrastructure and API
From 9baee79d211bfb94aeed970c55f31cd3c4b2a8ad Mon Sep 17 00:00:00 2001
From: Genaro Saucedo Tejada <genaro.saucedo.tejada(a)intel.com>
Date: Fri, 19 February 2016 23:10:28 +0000
Subject: [PATCH] Log
From 9baee79d211bfb94aeed970c55f31cd3c4b2a8ad Mon Sep 17 00:00:00 2001
From: Genaro Saucedo Tejada <genaro.saucedo.tejada(a)intel.com>
Date: Fri, 19 February 2016 23:10:28 +0000
Subject: [PATCH] Log
|
By
Saucedo Tejada, Genaro <genaro.saucedo.tejada@...>
·
#2325
·
|
|
RFC[1/2] Common logging infrastructure and API
Hello, please review this proposal and provide feedback if possible.
This email should be followed by a patch containing a prototype
implementation for reference but not meant to be
Hello, please review this proposal and provide feedback if possible.
This email should be followed by a patch containing a prototype
implementation for reference but not meant to be
|
By
Saucedo Tejada, Genaro <genaro.saucedo.tejada@...>
·
#2324
·
|
|
Re: RFC: return type of functions passed to DEVICE_INIT()
Thanks for pointing out the facts and issues :-) I agree it cannot be
used as a replacement for proper handling of resume() by devices.
Thanks for pointing out the facts and issues :-) I agree it cannot be
used as a replacement for proper handling of resume() by devices.
|
By
Thomas, Ramesh
·
#2323
·
|
|
Re: Pinmux driver model: per board vs. unified
Hi Dirk,
Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes:
[...]
I like it.
The only thing I am thinking about is polluting the drivers/pinmux/
directory when there are more than a couple of
Hi Dirk,
Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes:
[...]
I like it.
The only thing I am thinking about is polluting the drivers/pinmux/
directory when there are more than a couple of
|
By
Vinicius Costa Gomes
·
#2322
·
|
|
Re: RFC: return type of functions passed to DEVICE_INIT()
I do agree with you that the app cannot do much in failures. But then
kernel need not do even what you propose with failing binding. Let the
app figure out when it tries to use the port. Also
I do agree with you that the app cannot do much in failures. But then
kernel need not do even what you propose with failing binding. Let the
app figure out when it tries to use the port. Also
|
By
Thomas, Ramesh
·
#2321
·
|
|
Re: Pinmux driver model: per board vs. unified
By
Kalowsky, Daniel <daniel.kalowsky@...>
·
#2320
·
|
|
Re: Pinmux driver model: per board vs. unified
Don't hate it :-)
Although it occurs to me that the pinmux API is not all that useful
and could be considered harmful.
Setting up the pin configuration on an SOC/platform is an init time
only
Don't hate it :-)
Although it occurs to me that the pinmux API is not all that useful
and could be considered harmful.
Setting up the pin configuration on an SOC/platform is an init time
only
|
By
Dirk Brandewie <dirk.j.brandewie@...>
·
#2319
·
|
|
Re: RFC: make _fiber_start() return a handle on the fiber
Yeah, that would do it: the task has to yield to the fiber somehow,
since it will never pend (in a nanokernel context).
Hmm, I would counter this with the argument that passing the current
fiber
Yeah, that would do it: the task has to yield to the fiber somehow,
since it will never pend (in a nanokernel context).
Hmm, I would counter this with the argument that passing the current
fiber
|
By
Benjamin Walsh <benjamin.walsh@...>
·
#2318
·
|
|
Re: Pinmux driver model: per board vs. unified
Hi,
"Kalowsky, Daniel" <daniel.kalowsky(a)intel.com> writes:
Thanks for the well thought answer.
Hi,
"Kalowsky, Daniel" <daniel.kalowsky(a)intel.com> writes:
Thanks for the well thought answer.
|
By
Vinicius Costa Gomes
·
#2317
·
|
|
Re: RFC: make _fiber_start() return a handle on the fiber
I think I figured this out:
- I was trying to wake up the same fiber I was running
- I was always calling fiber_fiber_wakeup() instead of proper context
depending version
After fixing these two
I think I figured this out:
- I was trying to wake up the same fiber I was running
- I was always calling fiber_fiber_wakeup() instead of proper context
depending version
After fixing these two
|
By
Jukka Rissanen
·
#2315
·
|
|
Re: RFC: make _fiber_start() return a handle on the fiber
Re-sending this using proper mail address.
I managed to get following backtrace when the system is hanging:
_nano_fiber_ready (tcs=tcs(a)entry=0xa800f020 <tx_fiber_stack>)
at
Re-sending this using proper mail address.
I managed to get following backtrace when the system is hanging:
_nano_fiber_ready (tcs=tcs(a)entry=0xa800f020 <tx_fiber_stack>)
at
|
By
Jukka Rissanen
·
#2314
·
|
|
Re: RFC: make _fiber_start() return a handle on the fiber
I managed to get following backtrace when the system is hanging:
_nano_fiber_ready (tcs=tcs(a)entry=0xa800f020 <tx_fiber_stack>)
at
I managed to get following backtrace when the system is hanging:
_nano_fiber_ready (tcs=tcs(a)entry=0xa800f020 <tx_fiber_stack>)
at
|
By
Rissanen, Jukka <jukka.rissanen@...>
·
#2316
·
|
|
Re: RFC: make _fiber_start() return a handle on the fiber
Hi Peter & Ben,
I am seeing couple of issues when trying to wake up a fiber.
1) if my fiber tries to to wake up itself (yes, there was a bug in my
program), there seems to be weird issues (hangs).
Hi Peter & Ben,
I am seeing couple of issues when trying to wake up a fiber.
1) if my fiber tries to to wake up itself (yes, there was a bug in my
program), there seems to be weird issues (hangs).
|
By
Jukka Rissanen
·
#2313
·
|
|
Re: RFC: make _fiber_start() return a handle on the fiber
Returning a handler maybe is good for app to invoke other fiber related APIs for operation on same fiber.
But regarding the case described below, I have question can "nano_sem_give" be used instead
Returning a handler maybe is good for app to invoke other fiber related APIs for operation on same fiber.
But regarding the case described below, I have question can "nano_sem_give" be used instead
|
By
Liu, Sharron <sharron.liu@...>
·
#2312
·
|
|
Re: Pinmux driver model: per board vs. unified
In the future, when you're making architectural changes like this, send to the mailing list first. Submitting it to gerrit only is NOT advised, and limits the audience which can view the commentary.
In the future, when you're making architectural changes like this, send to the mailing list first. Submitting it to gerrit only is NOT advised, and limits the audience which can view the commentary.
|
By
Kalowsky, Daniel <daniel.kalowsky@...>
·
#2311
·
|
|
Re: Build fails when the sdk is not installed in the default path in Archlinux.
You could find the trace log uploaded under the issue ZEP-65 in jira:
https://jira.zephyrproject.org/browse/ZEP-65
Yannis
You could find the trace log uploaded under the issue ZEP-65 in jira:
https://jira.zephyrproject.org/browse/ZEP-65
Yannis
|
By
Yannis Damigos
·
#2310
·
|
|
Re: Pinmux driver model: per board vs. unified
Hi all,
Here is one proposal on how we can deal with pinmux drivers and board-
specific pinmux configurations:
1. All pinmux drivers land in driver/pinmux/ directory and they all
implement the
Hi all,
Here is one proposal on how we can deal with pinmux drivers and board-
specific pinmux configurations:
1. All pinmux drivers land in driver/pinmux/ directory and they all
implement the
|
By
Andre Guedes <andre.guedes@...>
·
#2309
·
|
|
Re: Build fails when the sdk is not installed in the default path in Archlinux.
Yannis can you provide an trace log?
$ strace -fo trace.log make ... [ETC ETC] ...
Thanks,
Yannis can you provide an trace log?
$ strace -fo trace.log make ... [ETC ETC] ...
Thanks,
|
By
Perez-Gonzalez, Inaky <inaky.perez-gonzalez@...>
·
#2308
·
|
|
Pinmux driver model: per board vs. unified
Hi,
(Sorry for the click bait-ish subject)
As per Dirk's suggestion moving the discussion on the pinmux model[1][2] to
the mailing list.
Quoting Dirk:
Makes sense.
The only thing that may
Hi,
(Sorry for the click bait-ish subject)
As per Dirk's suggestion moving the discussion on the pinmux model[1][2] to
the mailing list.
Quoting Dirk:
Makes sense.
The only thing that may
|
By
Vinicius Costa Gomes
·
#2307
·
|