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

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

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

Thanks for pointing out the facts and issues :-) I agree it cannot be used as a replacement for proper handling of resume() by devices.

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

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

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

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

Hi, "Kalowsky, Daniel" <daniel.kalowsky(a)intel.com> writes: Thanks for the well thought answer.

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

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

I managed to get following backtrace when the system is hanging: _nano_fiber_ready (tcs=tcs(a)entry=0xa800f020 <tx_fiber_stack>)     at

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).

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

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.

You could find the trace log uploaded under the issue ZEP-65 in jira: https://jira.zephyrproject.org/browse/ZEP-65 Yannis

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

Yannis can you provide an trace log? $ strace -fo trace.log make ... [ETC ETC] ... Thanks,

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