Problem: there are two similar mechanisms in nanokernel: nano_timers and nano_timeouts. In order to optimize codeand space it's better to have one mechanism for both. Proposal: Implement nano_timer

I agree, Galileo is a special case and it's initialization code may/will share enough code with development part. I think, pinmux_galileo_priv.c will implement those common functions, am I

Hi Dmitriy, Dmitriy Korovkin <dmitriy.korovkin(a)windriver.com> writes: Good idea, this is going to be useful to see if what I have in mind is aligned with what other's have. This is a rough sketch

It would be good to have design changes for pinmux outlined in one text. Are we talking about code consolidation for Quark SE/D2000 or the global change for all pinmuxes? Are we touching the part

Hi all, Quoting Vinicius Costa Gomes (2016-02-24 18:34:16) Yes, I also like this proposal and I think we should move with it instead of with the proposal I did. I have just one comment regarding the

It's the MACRO names the need fixed up IMO. Any functions that are added should be in the sys_* space sure. I didn't see any new C functions being added.

Again, do we want to take over _another_ namespace ? Maybe it should be sys_debug or sys_dbg or sys_dbg_log ? The sample implementation is adding all these in logging.h, which is a public API file:

If get binding fails the app will know the device failed or is otherwise unavailable. The return code from init() tells the kernel whether it's a fatal error and to call _NanoFatalErrorHandler()

I like this in general we need a common set of debug output macros that all drivers can use. Currently we have a *bunch* of different versions of the same thing in use throughout the driver tree. I

Dirk Brandewie <dirk.j.brandewie(a)intel.com> writes: [...] I already started this. Hoping to have something to show later today or tomorrow. Cheers, -- Vinicius

yeah better idea :-D when the quark_se gets more design wins things would get crowded. Now the question is who is signing up to do the refactoring? :-)

Hi Genaro, The idea is nice, at least it will prevent to declare debug macros everywhere. However, split the patch: - first provide a patch with the logging.h and it's related Kconfig file - and

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