Date   

FRDM-K64 GPIO driver name

Anders Dam Kofoed <adk@...>
 

Hi,

I am trying to use GPIO on my Freescale FRDM-K64 board. However, I cannot seem to find the driver name. It from this page that the driver name should be something like CONFIG_GPIO_<VENDOR_<MCU>_PORTn_DEV_NAME but nothing matches the FRDM-K64.
https://www.zephyrproject.org/doc/reference/kconfig/index.html

This is the code I'm trying to use (where GPIO_DRV_NAME should be what I need):
gpio_dev = device_get_binding(GPIO_DRV_NAME);
if (!gpio_dev) {
PRINT("Cannot find %s!\n", GPIO_DRV_NAME);
}

Got it from the GPIO example.

Any hints?

/Anders


FRDM-K64 PRINT not working

Anders Dam Kofoed <adk@...>
 

Hi,

I have a Freescale FRDM-K64 board. I cannot get the samples/hello_world/microkernel to work. Compiling with this:
# make O=out-arm BOARD=frdm_k64f

It compiles fine and the out-arm/zephyr.bin can be dropped into the MBED folder (for easy programming) just fine. However I can see actually flashes the board (because the previous program is overwritten) but it's not showing "Hello World!" as I'd expect on the /dev/ttyACM0 (Linux).

What am I doing wrong?

Kind regards
Anders


Re: 2/5 System Device Driver Modifications

Boie, Andrew P
 

Do you think we should replace SYS_INIT() with the new one? i.e. just
modify SYS_INIT(). I am ok either way.
That was my first thought but I don't think we have the liberty of changing our 1.0 APIs.

Andrew


Re: 2/5 System Device Driver Modifications

Thomas, Ramesh
 

On Fri, 2016-03-11 at 23:41 +0000, Boie, Andrew P wrote:
On Fri, 2016-03-11 at 22:30 +0000, Thomas, Ramesh wrote:

For example, the PMA may chooses to apply .resume on -> APICs, Timers,
ARC, UART in that order because of dependencies and policies. Assuming
it has a list of devices, it can identify these devices in that list by
the name.

The goal is to leave the ordering of operations on devices to the PMA as
kernel can only guarantee the initialization order.
I see. So at boot it could use device_get_binding() or DEVICE_GET() to
populate some data structure with device pointers which is then used at
suspend/resume time.

Another reason of giving the PMA direct access to the device is to
handle the case of DEV_BUSY/DEV_FAIL. It can then choose to
retry .suspend only that device that returned DEV_BUSY.
You're already calling .suspend the first time so presumably you already
have a device pointer, so I'm not sure how this imposes a requirement on
naming.

However the custom ordering for suspend/resume dependencies makes
perfect sense, thanks for the additional detail.

Looking at our headers I see some areas needing improvement. These
anonymous drivers use SYS_INIT(). This macro declares a device with ""
for its name, and the name you would use for DEVICE_GET() is very
counter-intuitive. Which means you can't really use either
device_get_binding() or DEVICE_GET() with them.

I think this API needs to be refactored for system devices like this.
Maybe have SYS_INIT() take a dev_name parameter. Here's a potential way
with a new macro SYS_INIT_NAMED(), the difference is in the first couple
args to DEVICE_INIT():

Old:
#define SYS_INIT(init_fn, level, prio) \
DEVICE_INIT(sys_init_##init_fn, "", init_fn, NULL, NULL, level, prio)

New:
#define SYS_INIT_NAMED(name, init_fn, level, prio) \
DEVICE_INIT(name, STRINGIFY(name), init_fn, NULL, NULL, level, prio)
Sounds good. We can use the SYS_INIT_NAMED() macro for devices that
need a name for PM purpose.

Do you think we should replace SYS_INIT() with the new one? i.e. just
modify SYS_INIT(). I am ok either way.


Re: RFC: Use error codes from errno.h

Andre Guedes <andre.guedes@...>
 

Hi all,

Quoting Andre Guedes (2016-03-03 16:43:24)
Quoting Jesus Sanchez-Palencia (2016-03-02 16:03:22)
The initial discussion was about using errno.h codes at the driver's layer
but I think we can expand it to the whole system. Actually, errno.h codes
are already used in net/bluetooth and net/ip.
+1 ! But I would propose that we first get this right for the device driver APIs.
Yes, this is the idea.
Do we have a consensus about this?

After the "errno-drivers" patchset, DEV_* codes will be used only at 'board'
and 'arch' layers. Actually, all occurrences of DEV_* codes in board/ are
from pinmux drivers. These drivers are going to be landed in drivers/ soon
(patches are under review on gerrit) so they will already be replaced by -E*
codes. This means that only a few files from arch/ will be using DEV_* codes.

If we have a consensus, the next steps are:
1) Replace DEV_* occurrences in arch/ (and boards/ if applicable);
2) Deprecate DEV_* (just add a comment in device.h saying: DEV_* are deprecate,
use errno.h codes instead.
3) Remove DEV_* codes.

Since 3) might break external applications, we should apply it during a major
release I guess.

Regards,

Andre


Re: RFC: Use error codes from errno.h

Andre Guedes <andre.guedes@...>
 

Hi all,

Quoting Andre Guedes (2016-03-04 10:55:24)
Hi,

Quoting Nashif, Anas (2016-03-04 09:34:45)

DEV_OK = 0
DEV_FAIL = -EIO
DEV_INVALID_OP = -ENOTSUP
DEV_INVALID_CONF = -EINVAL
DEV_USED = -EBUSY
DEV_NO_ACCESS = -EACCES
DEV_NO_SUPPORT = -ENODEV
DEV_NOT_CONFIG = -EPERM
DEV_NOT_IMPLEMENTED = -ENOSYS


Time to move this to gerrit for proper reviews, right?!

Yes please,
Nice, let's move on with this convention. I'll send patches to gerrit soon.
I just sent a patchset with topic "errno-drivers" implementing what we have
discussed in this RFC. The patchset basically redefines DEV_* using -E* codes
and replaces all occurrences of DEV_* by -E* at the driver layer.

Regards,

Andre


Re: [users] Re: Re: Re: Re: Re: STM32F103x port

Boie, Andrew P
 

On Fri, 2016-03-11 at 22:41 +0000, Maureen Helm wrote:

I think we will need this additional level to support more Kinetis family devices from Freescale/NXP. Many of these devices share common peripherals, differing by number of instances and base addresses for a given instance. Related to that, I also think SOC peripheral drivers should be located under arch/arm/soc. If you moved them here, I could see a structure like this:

arch/
arm/
soc/
kinetis/
drivers/ (peripheral drivers shared across multiple Kinetis SOCs)
mk64f12/ (frdm-k64f12 is the name of the board, not the SOC. This will need to be fixed at some point.)
mk22f12/
mkl27z644/
and many more...

Where each of the mk* folders represents an SOC in the Kinetis family, and instantiates a subset of peripheral drivers that apply to that SOC.
Something that also occurred to me: we have the same issue with our
boards/ directory. As Zephyr gets put on more and more boards we're
going to find ourselves with different variants of each board. I imagine
new board revs, or that week they used a different peripheral part
because of BOM cost, etc. So eventually I think we'll also have board
configurations in-tree that are *almost* the same except for a few
parameters...could share the same board.c, etc

--
Andrew Boie
Staff Engineer - EOS Zephyr
Intel Open Source Technology Center


Re: 2/5 System Device Driver Modifications

Boie, Andrew P
 

On Fri, 2016-03-11 at 22:30 +0000, Thomas, Ramesh wrote:

For example, the PMA may chooses to apply .resume on -> APICs, Timers,
ARC, UART in that order because of dependencies and policies. Assuming
it has a list of devices, it can identify these devices in that list by
the name.

The goal is to leave the ordering of operations on devices to the PMA as
kernel can only guarantee the initialization order.
I see. So at boot it could use device_get_binding() or DEVICE_GET() to
populate some data structure with device pointers which is then used at
suspend/resume time.

Another reason of giving the PMA direct access to the device is to
handle the case of DEV_BUSY/DEV_FAIL. It can then choose to
retry .suspend only that device that returned DEV_BUSY.
You're already calling .suspend the first time so presumably you already
have a device pointer, so I'm not sure how this imposes a requirement on
naming.

However the custom ordering for suspend/resume dependencies makes
perfect sense, thanks for the additional detail.

Looking at our headers I see some areas needing improvement. These
anonymous drivers use SYS_INIT(). This macro declares a device with ""
for its name, and the name you would use for DEVICE_GET() is very
counter-intuitive. Which means you can't really use either
device_get_binding() or DEVICE_GET() with them.

I think this API needs to be refactored for system devices like this.
Maybe have SYS_INIT() take a dev_name parameter. Here's a potential way
with a new macro SYS_INIT_NAMED(), the difference is in the first couple
args to DEVICE_INIT():

Old:
#define SYS_INIT(init_fn, level, prio) \
DEVICE_INIT(sys_init_##init_fn, "", init_fn, NULL, NULL, level, prio)

New:
#define SYS_INIT_NAMED(name, init_fn, level, prio) \
DEVICE_INIT(name, STRINGIFY(name), init_fn, NULL, NULL, level, prio)


--
Andrew Boie
Staff Engineer - EOS Zephyr
Intel Open Source Technology Center


Re: [users] Re: Re: Re: Re: Re: STM32F103x port

Maureen Helm
 

-----Original Message-----
From: Nashif, Anas [mailto:anas.nashif(a)intel.com]
Sent: Friday, March 11, 2016 8:34 AM
To: Kalowsky, Daniel <daniel.kalowsky(a)intel.com>
Cc: maciek.borzecki(a)gmail.com; Boie, Andrew P <andrew.p.boie(a)intel.com>;
Walsh, Benjamin (Wind River) <benjamin.walsh(a)windriver.com>;
devel(a)lists.zephyrproject.org; users(a)lists.zephyrproject.org
Subject: [devel] Re: [users] Re: Re: Re: Re: Re: STM32F103x port

On 10 Mar 2016, at 13:28, Kalowsky, Daniel <daniel.kalowsky(a)intel.com>
wrote:

-----Original Message-----
From: Nashif, Anas
Sent: Wednesday, March 9, 2016 5:49 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>; Kalowsky, Daniel
<daniel.kalowsky(a)intel.com>
Cc: users(a)lists.zephyrproject.org; maciek.borzecki(a)gmail.com;
devel(a)lists.zephyrproject.org; Walsh, Benjamin (Wind River)
<benjamin.walsh(a)windriver.com>
Subject: Re: [devel] Re: [users] Re: Re: Re: Re: Re: STM32F103x port

On 09/03/2016, 19:51, "Boie, Andrew P" <andrew.p.boie(a)intel.com> wrote:

On Wed, 2016-03-09 at 21:35 +0000, Kalowsky, Daniel wrote:
-----Original Message-----
Summing up, what you're basically suggesting is having a
structure like this (assumig that we keep vendor prefix for the time
being):

arch/
arm/
soc/
st_stm32f1/
Kconfig.soc
Kconfig
...
soc.c
st_stm32f2/
...
st_stm32l0/

If we're on the same page then i"ll post some patches tomorrow.
Seems
like an easy fix.
Yes, the only different from what you have right now is having 1
level
less. I
think everything else should stay the same.
I not convinced that is any good. You're essentially going to
create a larger
mess of MCUs in the arch/arm/soc directory.

The goal of keeping everything in a common directory (st_stm32) is
to
enforce maximum sharing between MCUs where possible. For example,
the stm32f1_init is really the same for the STM32F{1 | 2 | 3 | 4 }x
MCUs. Moving this into an upper level "common" area, not only makes
it difficult to find, it just creates confusion as we add in future platforms.

Do we need another layer of abstraction in the build for SoC variants?
Where did you see a new layer in what I said? The current patch and
adding
st_stm32 is adding a new layer. st_stm32 is not an SoC, its an
architecture (just like there is STM8) that has different variants
(M0+, M3, M4, …) that have additional SoCs. st_stm32 is something
comparable to Quark from x86.
So with this patch and looking at the Kconfig variables we have

arch / doc family or architecture / soc variant / soc / board
You're confusing me now. Please state your objection to the proposed
method clearly here.

I am not in favour of adding the stm32 layer. I am all for adding the "SoC series"
or "family layer”.

What this means:

instead of


arch/
arm/
soc/
stm32/
st_stm32f1/
st_stm32f2/


we will just have:

arch/
arm/
soc/
st_stm32f1/ (this would include multiple SoCs from the same series
and the same architecture)
st_stm32f2/


The above model is already used for the atmel_sam3, where SAM3 is the series
or family and ATMEL_SAM3X8E is the actual SoC. Actually, looking at

http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx we should
rename sam3 to sam3x to be more consistent.

If we decide to add one more level, i.e. ATMEL SAM or ST STM32, then we
need to revisit and redesign the hierarchy and mark those being families or
series in Kconfig and stop the mis-use of CONFIG_SOC_XX for three different
levels in the hierarchy.

I think we will need this additional level to support more Kinetis family devices from Freescale/NXP. Many of these devices share common peripherals, differing by number of instances and base addresses for a given instance. Related to that, I also think SOC peripheral drivers should be located under arch/arm/soc. If you moved them here, I could see a structure like this:

arch/
arm/
soc/
kinetis/
drivers/ (peripheral drivers shared across multiple Kinetis SOCs)
mk64f12/ (frdm-k64f12 is the name of the board, not the SOC. This will need to be fixed at some point.)
mk22f12/
mkl27z644/
and many more...

Where each of the mk* folders represents an SOC in the Kinetis family, and instantiates a subset of peripheral drivers that apply to that SOC.



I
share Dan's concerns, I think it may be better to have st_stm32/ SoC
and then subdirectories with variants thereof, with common code at
the toplevel.

This would mean we have inheritance as follows: arch / soc /
soc_variant / board. This would be something fully supported by the
build system, like it knows about arches / boards / socs now.

Not keen on collapsing all this to just soc/.
This the design as we have now (and it was proposed and discussed).
Under soc/ we have frdm-k64f, atmel_sam3 which are SoCs and not sub-
architectures. If you think we need another layer, then we need to
change this across the board and not only for STM32.
Correct. That would be step #2.
No, We make first make it fit in the current structure then take our time and do
it right after some discussion and after getting to an agreement.



Re: 2/5 System Device Driver Modifications

Thomas, Ramesh
 

On Fri, 2016-03-11 at 21:03 +0000, Boie, Andrew P wrote:
On Fri, 2016-03-11 at 19:02 +0000, Kalowsky, Daniel wrote:
-----Original Message-----
From: Boie, Andrew P [mailto:andrew.p.boie(a)intel.com]
Sent: Friday, March 11, 2016 9:24 AM
To: Thomas, Ramesh <ramesh.thomas(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: [devel] Re: 2/5 System Device Driver Modifications


2) Provide a name recognized by the device_get_binding() function, this
includes what are currently thought to be drivers such as timers, IOAPIC,
and
LOAPIC.
Why do you need this for the LOAPIC/IOAPIC?
All its functions are private to the kernel and do not require a device pointer.
Please provide a specific example on where you would need to run
device_get_binding() specifically for the APIC.
device_get_binding() is *slow*. It does a linear search + strcmp(). Use it
sparingly.
We agree that the device_get_binding is slow. We'd rather not depend upon it,
which is why we had suggested the addition of a routine to get the start and
end of the device list and allow the PMA to parse this list once at
initialization to figure out what is or is not needed for power
policies.
If you just need to iterate over all devices this code does the job:

struct device *info;

for (info = __device_init_start; info != __device_init_end; info++) {
/* do stuff */
}

Could add an API to nanokernel/device.c to take a function(struct device
*d) as a parameter and apply to all of them so that the private
__device_init_* symbols don't need to be public.
The list enables the PMA to choose the order in which it
suspends/resumes the devices by creating its own ordered list based on
policies. If the iteration is done by the kernel then the order will be
fixed to the order the devices are stored in the kernel's device list.


If we go with that solution, pushing all policy decisions to the PMA,
we need to be able to properly identify the devices as that list is
parsed. Currently several devices, like IOAPIC and LOAPIC, have no
name or function to identify them and make this route difficult.
I'm still confused. Does the PMA need to only apply .suspend/.resume
operations to a subset of all devices? Some examples/usecases would
help...
For example, the PMA may chooses to apply .resume on -> APICs, Timers,
ARC, UART in that order because of dependencies and policies. Assuming
it has a list of devices, it can identify these devices in that list by
the name.

The goal is to leave the ordering of operations on devices to the PMA as
kernel can only guarantee the initialization order.

Another reason of giving the PMA direct access to the device is to
handle the case of DEV_BUSY/DEV_FAIL. It can then choose to
retry .suspend only that device that returned DEV_BUSY. Also it can
choose which devices it can ignore a failure and continue suspend.





Re: 2/5 System Device Driver Modifications

Boie, Andrew P
 

On Fri, 2016-03-11 at 19:02 +0000, Kalowsky, Daniel wrote:
-----Original Message-----
From: Boie, Andrew P [mailto:andrew.p.boie(a)intel.com]
Sent: Friday, March 11, 2016 9:24 AM
To: Thomas, Ramesh <ramesh.thomas(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: [devel] Re: 2/5 System Device Driver Modifications


2) Provide a name recognized by the device_get_binding() function, this
includes what are currently thought to be drivers such as timers, IOAPIC,
and
LOAPIC.
Why do you need this for the LOAPIC/IOAPIC?
All its functions are private to the kernel and do not require a device pointer.
Please provide a specific example on where you would need to run
device_get_binding() specifically for the APIC.
device_get_binding() is *slow*. It does a linear search + strcmp(). Use it
sparingly.
We agree that the device_get_binding is slow. We'd rather not depend upon it,
which is why we had suggested the addition of a routine to get the start and
end of the device list and allow the PMA to parse this list once at
initialization to figure out what is or is not needed for power
policies.
If you just need to iterate over all devices this code does the job:

struct device *info;

for (info = __device_init_start; info != __device_init_end; info++) {
/* do stuff */
}

Could add an API to nanokernel/device.c to take a function(struct device
*d) as a parameter and apply to all of them so that the private
__device_init_* symbols don't need to be public.

If we go with that solution, pushing all policy decisions to the PMA,
we need to be able to properly identify the devices as that list is
parsed. Currently several devices, like IOAPIC and LOAPIC, have no
name or function to identify them and make this route difficult.
I'm still confused. Does the PMA need to only apply .suspend/.resume
operations to a subset of all devices? Some examples/usecases would
help...


--
Andrew Boie
Staff Engineer - EOS Zephyr
Intel Open Source Technology Center


Re: RFC: 2/5 System Device Driver Modifications

Vinicius Costa Gomes
 

Hi,

"Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes:

On Fri, 2016-03-11 at 14:59 -0300, Vinicius Costa Gomes wrote:
Hi,

"Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes:

Problem Statement:
Not all Zephyr kernel drivers provide the same interfaces.

Why this is a problem:
-----------------------------
The Zephyr kernel currently has devices that are essential for core OS
functions (such as APICs and timers), but provide no public API means
for accessing them. Without any consistent method to access device
drivers on the platform, it becomes very difficult to achieve power
targets.

What should be done:
-----------------------------
1) Each native Zephyr kernel driver and shim driver (such as QMSI) shall
support:

a) uint32_t suspend() - routine that will move any required device state
data
to RAM* with the following valid return values:
- DEV_OK
- DEV_BUSY
- DEV_FAIL
I am thinking about the case when DEV_BUSY is returned, I am considering
this would happen, for example, in the SPI case when there's a transfer
going on, right?

I guess there are at least two alternatives:
- The power management process has some kind of heuristic for retrying;
- Having some mechanism for communicating the power management that
"now I am ready to suspend" (from what I understand, this was in the
original power management proposal);
The power manager application should be able to handle that case. It
can either retry after trying other drivers, ignore that driver or abort
suspend.

The callback is not going to help because _sys_soc_suspend is already
called in the kernel idle task and it cannot go any more idle than that
waiting for a callback to come. It is better off retrying the driver
until it gets it to suspend.
Ah, I see. Thanks.



It's not clear in the RFC how do plan to handle this.


b) uint32_t resume() - routine that will retrieve any device state data
from
RAM* with the following valid return values:

- DEV_OK
- DEV_FAIL

2) Provide a name recognized by the device_get_binding() function, this
includes what are currently thought to be drivers such as timers,
IOAPIC, and LOAPIC.

*The power management process is not expected to power down system RAM
(it will most likely stay in selective suspend).

The size of the device data is dependent upon an individual device, and
therefore the system integrator must be wary of the number of devices
being utilized.

Device suspend flow:
Device Drivers at suspend shall:
- Device state shall be saved to memory and maintained across a PM event
- Turning off the device clock
- Return appropriate error code

Device resume flow:
Device Drivers at resume shall:
- Restore to state saved in memory
- Turn on the device clock
- Return appropriate error code

Device domain experts will be needed to implement the proper methods for
suspending and resuming each device.

Cheers,
--
Vinicius
Cheers,
--
Vinicius


Re: RFC: 2/5 System Device Driver Modifications

Thomas, Ramesh
 

On Fri, 2016-03-11 at 14:59 -0300, Vinicius Costa Gomes wrote:
Hi,

"Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes:

Problem Statement:
Not all Zephyr kernel drivers provide the same interfaces.

Why this is a problem:
-----------------------------
The Zephyr kernel currently has devices that are essential for core OS
functions (such as APICs and timers), but provide no public API means
for accessing them. Without any consistent method to access device
drivers on the platform, it becomes very difficult to achieve power
targets.

What should be done:
-----------------------------
1) Each native Zephyr kernel driver and shim driver (such as QMSI) shall
support:

a) uint32_t suspend() - routine that will move any required device state
data
to RAM* with the following valid return values:
- DEV_OK
- DEV_BUSY
- DEV_FAIL
I am thinking about the case when DEV_BUSY is returned, I am considering
this would happen, for example, in the SPI case when there's a transfer
going on, right?

I guess there are at least two alternatives:
- The power management process has some kind of heuristic for retrying;
- Having some mechanism for communicating the power management that
"now I am ready to suspend" (from what I understand, this was in the
original power management proposal);
The power manager application should be able to handle that case. It
can either retry after trying other drivers, ignore that driver or abort
suspend.

The callback is not going to help because _sys_soc_suspend is already
called in the kernel idle task and it cannot go any more idle than that
waiting for a callback to come. It is better off retrying the driver
until it gets it to suspend.


It's not clear in the RFC how do plan to handle this.


b) uint32_t resume() - routine that will retrieve any device state data
from
RAM* with the following valid return values:

- DEV_OK
- DEV_FAIL

2) Provide a name recognized by the device_get_binding() function, this
includes what are currently thought to be drivers such as timers,
IOAPIC, and LOAPIC.

*The power management process is not expected to power down system RAM
(it will most likely stay in selective suspend).

The size of the device data is dependent upon an individual device, and
therefore the system integrator must be wary of the number of devices
being utilized.

Device suspend flow:
Device Drivers at suspend shall:
- Device state shall be saved to memory and maintained across a PM event
- Turning off the device clock
- Return appropriate error code

Device resume flow:
Device Drivers at resume shall:
- Restore to state saved in memory
- Turn on the device clock
- Return appropriate error code

Device domain experts will be needed to implement the proper methods for
suspending and resuming each device.

Cheers,
--
Vinicius


Re: RFC: 2/5 System Device Driver Modifications

Kalowsky, Daniel <daniel.kalowsky@...>
 

Hey Vinicius,

-----Original Message-----
From: Vinicius Costa Gomes [mailto:vinicius.gomes(a)intel.com]
Sent: Friday, March 11, 2016 9:59 AM
To: Thomas, Ramesh <ramesh.thomas(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: [devel] Re: RFC: 2/5 System Device Driver Modifications

Hi,

"Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes:

Problem Statement:
Not all Zephyr kernel drivers provide the same interfaces.

Why this is a problem:
-----------------------------
The Zephyr kernel currently has devices that are essential for core OS
functions (such as APICs and timers), but provide no public API means
for accessing them. Without any consistent method to access device
drivers on the platform, it becomes very difficult to achieve power
targets.

What should be done:
-----------------------------
1) Each native Zephyr kernel driver and shim driver (such as QMSI) shall
support:

a) uint32_t suspend() - routine that will move any required device state
data
to RAM* with the following valid return values:
- DEV_OK
- DEV_BUSY
- DEV_FAIL
I am thinking about the case when DEV_BUSY is returned, I am considering
this would happen, for example, in the SPI case when there's a transfer
going on, right?
That was the general idea. Or say a comms module has been idle and is now seeing some activity or connectivity suddenly arriving.

I guess there are at least two alternatives:
- The power management process has some kind of heuristic for retrying;
- Having some mechanism for communicating the power management that
"now I am ready to suspend" (from what I understand, this was in the
original power management proposal);

It's not clear in the RFC how do plan to handle this.
When I requested Ramesh add this, it was really an idea of pushing any policy decisions out from the kernel and into the PMA. In this case, if a device reports back that it is busy, the PMA can choose to:

1) Treat this as a failure, bail out, and report back that suspend has failed.
2) Spin until the device reports back success or failure and make the decision from there.
3) Put device into a list to recheck after shutting down other devices (if possible)
4) Ignore and move along.

But again, these are all PM policy decisions that a Power Management Application should be making, not the kernel.


Re: 2/5 System Device Driver Modifications

Kalowsky, Daniel <daniel.kalowsky@...>
 

-----Original Message-----
From: Boie, Andrew P [mailto:andrew.p.boie(a)intel.com]
Sent: Friday, March 11, 2016 9:24 AM
To: Thomas, Ramesh <ramesh.thomas(a)intel.com>;
devel(a)lists.zephyrproject.org
Subject: [devel] Re: 2/5 System Device Driver Modifications


2) Provide a name recognized by the device_get_binding() function, this
includes what are currently thought to be drivers such as timers, IOAPIC,
and
LOAPIC.
Why do you need this for the LOAPIC/IOAPIC?
All its functions are private to the kernel and do not require a device pointer.
Please provide a specific example on where you would need to run
device_get_binding() specifically for the APIC.
device_get_binding() is *slow*. It does a linear search + strcmp(). Use it
sparingly.
We agree that the device_get_binding is slow. We'd rather not depend upon it, which is why we had suggested the addition of a routine to get the start and end of the device list and allow the PMA to parse this list once at initialization to figure out what is or is not needed for power policies.

If we go with that solution, pushing all policy decisions to the PMA, we need to be able to properly identify the devices as that list is parsed. Currently several devices, like IOAPIC and LOAPIC, have no name or function to identify them and make this route difficult.


Re: RFC: 2/5 System Device Driver Modifications

Vinicius Costa Gomes
 

Hi,

"Thomas, Ramesh" <ramesh.thomas(a)intel.com> writes:

Problem Statement:
Not all Zephyr kernel drivers provide the same interfaces.

Why this is a problem:
-----------------------------
The Zephyr kernel currently has devices that are essential for core OS
functions (such as APICs and timers), but provide no public API means
for accessing them. Without any consistent method to access device
drivers on the platform, it becomes very difficult to achieve power
targets.

What should be done:
-----------------------------
1) Each native Zephyr kernel driver and shim driver (such as QMSI) shall
support:

a) uint32_t suspend() - routine that will move any required device state
data
to RAM* with the following valid return values:
- DEV_OK
- DEV_BUSY
- DEV_FAIL
I am thinking about the case when DEV_BUSY is returned, I am considering
this would happen, for example, in the SPI case when there's a transfer
going on, right?

I guess there are at least two alternatives:
- The power management process has some kind of heuristic for retrying;
- Having some mechanism for communicating the power management that
"now I am ready to suspend" (from what I understand, this was in the
original power management proposal);

It's not clear in the RFC how do plan to handle this.


b) uint32_t resume() - routine that will retrieve any device state data
from
RAM* with the following valid return values:

- DEV_OK
- DEV_FAIL

2) Provide a name recognized by the device_get_binding() function, this
includes what are currently thought to be drivers such as timers,
IOAPIC, and LOAPIC.

*The power management process is not expected to power down system RAM
(it will most likely stay in selective suspend).

The size of the device data is dependent upon an individual device, and
therefore the system integrator must be wary of the number of devices
being utilized.

Device suspend flow:
Device Drivers at suspend shall:
- Device state shall be saved to memory and maintained across a PM event
- Turning off the device clock
- Return appropriate error code

Device resume flow:
Device Drivers at resume shall:
- Restore to state saved in memory
- Turn on the device clock
- Return appropriate error code

Device domain experts will be needed to implement the proper methods for
suspending and resuming each device.

Cheers,
--
Vinicius


Re: RFC Common System logging API Rev. 2

Boie, Andrew P
 

CONFIG_SYS_LOG_ENABLE_PRINTF: specifies printf as backend.
CONFIG_SYS_LOG_ENABLE_PRINTK: specifies printk as backend.
I really think that officially supporting both printk() and printf() in the kernel is a bad idea. Having Zephyr depend on libc APIs really isn't the way to go. Zephyr should not care whether printf() exists or not.

The real "backend" should simply be the character output routine, an interface for emitting one character to an output device, whether a RAM buffer, IPM channel, UART, etc. Currently this is managed by ad hoc private APIs, but this would be a good thing to make official.

Andrew


Re: 2/5 System Device Driver Modifications

Boie, Andrew P
 


2) Provide a name recognized by the device_get_binding() function, this
includes what are currently thought to be drivers such as timers, IOAPIC, and
LOAPIC.
Why do you need this for the LOAPIC/IOAPIC?
All its functions are private to the kernel and do not require a device pointer.
Please provide a specific example on where you would need to run device_get_binding() specifically for the APIC.
device_get_binding() is *slow*. It does a linear search + strcmp(). Use it sparingly.

Andrew


Re: RFC Common System logging API Rev. 2

Saucedo Tejada, Genaro <genaro.saucedo.tejada@...>
 

On Fri, 2016-03-11 at 11:49 +0100, Tomasz Bursztyka wrote:
Hi Genaro,

Could you give the gerrit links?

The following switches control some optional formatting:

CONFIG_SYS_LOG_ENABLE_PRINTF: specifies printf as backend.
CONFIG_SYS_LOG_ENABLE_PRINTK: specifies printk as backend.
Aren't these 2 being mitigated by CONFIG_STDOUT_CONSOLE ?
If this option is set: printf will be used, printk otherwise.

Tomasz
Yes, I got a similar comment on gerrit, this has been done in such way
because in the future more "back ends" are expected, i.e., other
functions could be called hence a "back end" menu choice. But for
following patch I'm likely removing that.

Somehow outdated patches are available at gerrit:
https://gerrit.zephyrproject.org/r/691
https://gerrit.zephyrproject.org/r/722


Re: [users] Re: Re: Re: Re: Re: STM32F103x port

Nashif, Anas
 

On 10 Mar 2016, at 13:28, Kalowsky, Daniel <daniel.kalowsky(a)intel.com> wrote:

-----Original Message-----
From: Nashif, Anas
Sent: Wednesday, March 9, 2016 5:49 PM
To: Boie, Andrew P <andrew.p.boie(a)intel.com>; Kalowsky, Daniel
<daniel.kalowsky(a)intel.com>
Cc: users(a)lists.zephyrproject.org; maciek.borzecki(a)gmail.com;
devel(a)lists.zephyrproject.org; Walsh, Benjamin (Wind River)
<benjamin.walsh(a)windriver.com>
Subject: Re: [devel] Re: [users] Re: Re: Re: Re: Re: STM32F103x port

On 09/03/2016, 19:51, "Boie, Andrew P" <andrew.p.boie(a)intel.com> wrote:

On Wed, 2016-03-09 at 21:35 +0000, Kalowsky, Daniel wrote:
-----Original Message-----
Summing up, what you're basically suggesting is having a structure
like this (assumig that we keep vendor prefix for the time being):

arch/
arm/
soc/
st_stm32f1/
Kconfig.soc
Kconfig
...
soc.c
st_stm32f2/
...
st_stm32l0/

If we're on the same page then i"ll post some patches tomorrow.
Seems
like an easy fix.
Yes, the only different from what you have right now is having 1 level
less. I
think everything else should stay the same.
I not convinced that is any good. You're essentially going to create a larger
mess of MCUs in the arch/arm/soc directory.

The goal of keeping everything in a common directory (st_stm32) is to
enforce maximum sharing between MCUs where possible. For example, the
stm32f1_init is really the same for the STM32F{1 | 2 | 3 | 4 }x MCUs. Moving
this into an upper level "common" area, not only makes it difficult to find, it
just creates confusion as we add in future platforms.

Do we need another layer of abstraction in the build for SoC variants?
Where did you see a new layer in what I said? The current patch and adding
st_stm32 is adding a new layer. st_stm32 is not an SoC, its an architecture
(just like there is STM8) that has different variants (M0+, M3, M4, …) that
have additional SoCs. st_stm32 is something comparable to Quark from x86.
So with this patch and looking at the Kconfig variables we have

arch / doc family or architecture / soc variant / soc / board
You're confusing me now. Please state your objection to the proposed method clearly here.
I am not in favour of adding the stm32 layer. I am all for adding the "SoC series" or "family layer”.

What this means:

instead of


arch/
arm/
soc/
stm32/
st_stm32f1/
st_stm32f2/


we will just have:

arch/
arm/
soc/
st_stm32f1/ (this would include multiple SoCs from the same series and the same architecture)
st_stm32f2/


The above model is already used for the atmel_sam3, where SAM3 is the series or family and ATMEL_SAM3X8E is the actual SoC. Actually, looking at

http://www.atmel.com/products/microcontrollers/arm/sam3x.aspx we should rename sam3 to sam3x to be more consistent.

If we decide to add one more level, i.e. ATMEL SAM or ST STM32, then we need to revisit and redesign the hierarchy and mark those being families or series in Kconfig and stop the mis-use of CONFIG_SOC_XX for three different levels in the hierarchy.




I
share Dan's concerns, I think it may be better to have st_stm32/ SoC and
then subdirectories with variants thereof, with common code at the
toplevel.

This would mean we have inheritance as follows: arch / soc /
soc_variant / board. This would be something fully supported by the
build system, like it knows about arches / boards / socs now.

Not keen on collapsing all this to just soc/.
This the design as we have now (and it was proposed and discussed). Under
soc/ we have frdm-k64f, atmel_sam3 which are SoCs and not sub-
architectures. If you think we need another layer, then we need to change
this across the board and not only for STM32.
Correct. That would be step #2.
No, We make first make it fit in the current structure then take our time and do it right after some discussion and after getting to an agreement.

7781 - 7800 of 8112