|
Building project
Corey Williamson <corey.bailey.williamson@...>
Hi,
I'm currently trying to build the hello world example in a directory outside the zephyr SDK and I keep getting this make error: corey(a)corey-H97M-D3H:~/ZephyrWorkspace/eclipse_workspace/hello_world$ make Using /home/corey/ZephyrWorkspace/zephyr-project/boards/frdm_k64f/frdm_k64f_defconfig as base Merging /home/corey/ZephyrWorkspace/zephyr-project/kernel/configs/mico.config The merge file '/home/corey/ZephyrWorkspace/zephyr-project/kernel/configs/mico.config' does not exist. Exit. make: *** [/home/corey/ZephyrWorkspace/eclipse_workspace/hello_world/outdir/.config] Error 1 I thought I might be environment variables but I echoed ZEPHYR_BASE and it was correct. Any help is much appreciated, Thanks! Corey
|
|
|
|
Re: Counter driver API
Tseng, Kuo-Lang
Just to add missing sub-folder name in the hardware specific driver path:
toggle quoted messageShow quoted text
-----Original Message-----I missed sub-folder name here. It should be drivers/counter/quark_aon_counter.c
|
|
|
|
[RFC] Docker-based development environment for Windows
LeMay, Michael <michael.lemay@...>
Problem: Setting up a Zephyr development environment on Microsoft Windows involves many steps.
Proposal: Use Docker to automate the setup procedure. Docker Toolbox (https://www.docker.com/products/docker-toolbox) can be installed on Windows. It automates the installation of a VMM and a Linux VM suitable for running Docker containers. It also installs associated tools. A Dockerfile is a sort of script for creating a Linux container (https://docs.docker.com/engine/reference/builder/). I wrote one that automates the creation of a Zephyr development environment based on Ubuntu 15.10. It's fairly short, so I pasted it at the end of this message in its entirety. It would be placed in a new, empty directory, e.g. $ZEPHYR_BASE/scripts/docker. To build the container, the developer would execute "docker build -t zephyr-build ." in that directory from the "Docker Quickstart Terminal". To run the container, the developer would execute "docker run -t -i -v /c/Users/<username>/<zephyr_src_dir>:/zephyr zephyr-build", where <zephyr_src_dir> is a Zephyr source tree. This would present the developer with a command prompt in the Zephyr development environment with the root of the Zephyr source tree as the initial working directory. To build an app, the developer would navigate to the desired app source directory and execute the same commands that would be used in any other Ubuntu Linux environment. The output binary can be accessed from Windows after being built. This environment is also suitable for building GRUB for the Intel Galileo using the scripts/build_grub.sh script. However, the script must first be copied to /tmp within the Linux container and executed from there, since the GRUB build process is incompatible with the virtual filesystem for the Zephyr source tree. I think that this environment would only be suitable for building Zephyr binaries. Installing the binaries to the target is an orthogonal procedure. The files simply need to be copied to a USB-connected flash device for a board like the Intel Galileo, but the installation procedure is more complicated for some other boards. I can submit this Dockerfile as a patch with associated documentation if it seems potentially useful. This could potentially be useful on other platforms besides Windows, but I have only tested it on Windows 10 so far. -- Dockerfile: FROM ubuntu:15.10 RUN apt-get update \ && apt-get install -y \ autoconf automake bison bzip2 file flex gcc-multilib git make python \ && rm -rf /var/lib/apt/lists/* WORKDIR /tmp ENV SDK_VER 0.7.2 ENV SDK_ARCHIVE zephyr-sdk-$SDK_VER-i686-setup.run ADD https://nexus.zephyrproject.org/content/repositories/releases/org/zephyrproject/zephyr-sdk/$SDK_VER-i686/$SDK_ARCHIVE ./ RUN chmod u+x $SDK_ARCHIVE ENV ZEPHYR_SDK_INSTALL_DIR /opt/zephyr-sdk RUN ./$SDK_ARCHIVE --nox11 -- -d $ZEPHYR_SDK_INSTALL_DIR RUN rm $SDK_ARCHIVE RUN echo export ZEPHYR_GCC_VARIANT=zephyr >> ~/.bashrc RUN echo export ZEPHYR_SDK_INSTALL_DIR=$ZEPHYR_SDK_INSTALL_DIR >> ~/.bashrc RUN echo source /zephyr/zephyr-env.sh >> ~/.bashrc WORKDIR /zephyr CMD ["/bin/bash", "-l"]
|
|
|
|
Re: STM32F103x port
Maciek Borzecki <maciek.borzecki@...>
Hi list,
It has been a slow weekend, as part of my self-doubt recovery after a bad Codility experience I've started writing drivers for RCC, UART and pinmux for STM32F10x chips. The changes are pushed to bboozzoo/stm32f103-next branch here: https://github.com/bboozzoo/zephyr/tree/bboozzoo/stm32f103-next/ Beware, I'm treating this branch as a backup of my local work, so there might be force pushes from time to time. The demo code has been archived in bboozzoo/stm32f103-demo branch. Once I deem the work somewhat feature complete, I'll clean that up and push for review. I'd be glad if someone took a look at the code and shared their opinion on whether the path I took seems reasonable. I think there might be some room for extending clock control driver API. The problem comes form the fact that some chips may a more elaborate clock distribution within the SoC itself. For instance, inside the STM32F103x chip, there are at least 2 clock domains driving the peripherals (low speed clock PCLK1 and high speed PCLK2). When setting up UARTx baud rate one needs to know the clock rate in order to calculate the timings for the peripheral. Also, on this particular chip USART1 is driven by PCLK2, while the remaining for UARTx are driven by PLCK1. Finding out the rate of the clock driving particular peripheral is useful if we want to keep things generic to some extent. I've added the following call to driver specific part of the API: void stm32f10x_clock_control_get_subsys_rate(struct device *clock, clock_control_subsys_t subsys, uint32_t *rate); where `subsys` is the regular clock subsystem and the clock rate is returned in `*rate` field. Since this might be a more general problem, I think the functionality can be added to the clock_control API: typedef void (*clock_control_get_clock)(struct device *dev, clock_control_subsys_t sys, uint32_t *rate); struct clock_control_driver_api { ... clock_control_get_clock get_clock; } As for the drivers. The RCC (Reset & Clock Control) driver mostly delivers the CC part of the name. I have intentionally specified a low priority (1) in DEVICE_INIT() call. The RCC has to be initialized early in the startup process, otherwise no peripherals will work. RCC subsytem mapping enums have been put in driver specific header. I did not feel like these belonged to the SoC specific part as the mappings are shared by the whole family of SoCs. The pinmux driver contains only the parts essential for getting the UART to work. Again, this is not part of the board specific code, neither the SoC specific one, as the driver is shared by a family of MCUs. I have looked at the pinmux driver for Galileo and I understand the the API has been shaped having this board in mind. While the API methods are sufficient, I have only implemented the *_get() and *_set() calls. The pin config on STM32F10x is a bit elaborate so I reused the `func` parameter in *_get()/*_set() calls to pass driver specific function mappings. The function mapping names are currently shaped after pinconf-generic Linux driver. Perhaps I'm being too pragmatic here, but I'd like to avoid replication of STM32Cube's functionality and typing in all possible pin mappings. The UART driver is still using polling, however drive init has been reworked to use the pinmux and clock_control APIs. The baud rate is not hardcoded anymore and is calculated based on configuration. The fixed point arithmetic should be correct for low speeds and close enough for higher speeds. Depending the amount of Yocto/OE work things might be a bit slower next week, but I'll do some testing and push updates when possible. Eventually I'd like to hook up a BMP180 pressure sensor over I2C and get that working. Cheers, -- Maciek Borzecki
|
|
|
|
Re: RFC[1/2] Common logging infrastructure and API
Nashif, Anas
Hi,
On 24/02/2016, 17:13, "Saucedo Tejada, Genaro" <genaro.saucedo.tejada(a)intel.com> wrote: Hello, please review this proposal and provide feedback if possible.This is a much needed enhancement, thanks for making this proposal. We need to make sure we support logging for more than debugging and during development. In most cases logging will be used during development to assist with debugging and printing information on the console, however, we need to make sure this design also addresses cases where logging is part of the application, for example you might want to write to a file-system, send messages to a remote endpoint or write messages to a connected display. This basically means we also need to support different backends, the most immediate and straightforward backend would be printing to the console using printk and printf. An application should be able to configure the domains and levels it wants to log, for example, if I am debugging an issue with I2C and I am only interested in I2C, I want to be able to select this domain and the logging level, so for example: the defaults: CONFIG_LOG=y CONFIG_LOG_BACKEND=“printk” CONFIG_LOG_DOMAINS=“*” CONFIG_LOG_LEVEL=“INFO” would enable logging (INFO) for everything using printk For the case above I would change the following in my application .config: CONFIG_LOG_DOMAINS=“I2C” CONFIG_LOG_LEVEL=“DEBUG” Just use LOG_DOMAIN, no need to abbreviate this Keep it simple, CONFIG_LOG, the COMPILE wording can be misleading, In Kconfig we compile almost everything that is enabled, i.e. y means USE_COMPILE... LOG_THIS_MODULE: This is an additional switch intended to bridge theI think this is were things will get confusing, we do need to change all of those existing DEBUG variables and make them work with the new model instead of keeping them in the code. See my example above, using the right domains and level, the same will be achieved.
We should implement backends and clean up all the custom DEBUG usage in Kconfig and move everything to the new model reducing complexity and making things more consistent. Please make sure we have a JIRA story to track this and add the final proposal to that JIRA once we have reached consensus. Anas
|
|
|
|
Re: RFC[2/2] Common logging infrastructure and API
Nashif, Anas
Hi
toggle quoted messageShow quoted text
On 24/02/2016, 17:13, "Saucedo Tejada, Genaro" <genaro.saucedo.tejada(a)intel.com> wrote:
From 9baee79d211bfb94aeed970c55f31cd3c4b2a8ad Mon Sep 17 00:00:00 2001 From: Genaro Saucedo Tejada <genaro.saucedo.tejada(a)intel.com> See my comments on the first email.. - we need to make all existing code use this feature and how it was defined and avoid designing it to match EVERY existing custom logging and debugging implementation we currently have. - support multiple logging backends - split this patch, add the feature and testcases then add a sample that can be used for as a reference by developers - need to work on better variable names, avoid extreme abbreviations (LV -> LEVEL, DMN -> DOMAIN,...) few comments below.. The above should be defined using backend support. +/* Should use color? */ Use LEVEL instead of LV + DOMAIN +
|
|
|
|
Re: STM32F103x port
Liu, Sharron <sharron.liu@...>
Really glad to see Zephyr upon chips of STM, my former employer :)
toggle quoted messageShow quoted text
-----Original Message-----
From: Nashif, Anas [mailto:anas.nashif(a)intel.com] Sent: Saturday, February 27, 2016 4:52 AM To: Maciek Borzecki <maciek.borzecki(a)gmail.com> Cc: devel(a)lists.zephyrproject.org; users(a)lists.zephyrproject.org Subject: [devel] Re: STM32F103x port On Feb 26, 2016, at 11:08, Maciek Borzecki <maciek.borzecki(a)gmail.com> wrote: There is an effort going on right now, details will be provided soon. Anas
|
|
|
|
Re: STM32F103x port
Piyush Pangtey <ppang.cse13@...>
Hi Maciek,
i'm inspired by your work and i would like to make port for other boards too , can you guide me from where can I start ? Regards, Piyush Pangtey
|
|
|
|
RFC [0/3] - SoC, CPU LPS, Tickless idle and Device power management
Thomas, Ramesh
Migrating this RFC from the old server for reference. This is updated
with the feedbacks that were incorporated. This consists of the following parts: [0/3] - This overview [1/3] - SoC, CPU and Tickless Idle power management (merged) [2/3] - Device power management (under review) [3/3] - Areas to be implemented next including open feedbacks Following are the main areas to address for power management support in Zephyr: 1. Kernel SoC power management hook infrastructure in Zephyr 2. Kernel CPU low power state and Tickless idle power management hook infrastructure. 3. Device driver power management hook infrastructure Goal: This support in Zephyr kernel is added to assist system integrator's implementation of Power Management policy and service. Non-goal - Zephyr kernel will not: a) Implement any Power Management policy - The integrator's power management service app would implement power policy b) Implement any code to save/restore registers or SoC or device states. - The integrator's power management service app and device drivers should take care of that.
|
|
|
|
RFC [1/3] - SoC, CPU LPS, Tickless idle and Device power management
Thomas, Ramesh
***This part is merged***
https://gerrit.zephyrproject.org/r/#/c/148/ https://gerrit.zephyrproject.org/r/#/c/149/ https://gerrit.zephyrproject.org/r/#/c/150/ https://gerrit.zephyrproject.org/r/#/c/151/ Kernel SOC power management hook infrastructure in Zephyr ----------------------------------------------------------------------- This infrastructure provides hooks at locations where the kernel goes to idle to enable the PM service application to do suspend operations around them. This infrastructure can be used by power manager app to implement PM policy and to put system to various power states. A sample PM application is provided as an example to demonstrate how to use these hooks and the states it uses (listed below) are for demonstration purpose. It is up to the implementer of the PM service app to design their own. 1. LPS: CPU is put in low power states like C2. The CPU states are not lost. Woken up by any interrupt. 2. Deep Sleep: The SoC is put in deep sleep state saving most power. In this state, CPU power is off while SRAM contents are retained. Woken up by deep sleep wake up events of SoC. On wake up, execution will resume from reset vector. 3. Tickless Idle power saving: Zephyr kernel has its own idling called Tickless idle. PM service can take advantage of this by turning off peripherals to save more power when the hook infrastructure notifies it before going to idle. It will be notified again when kernel exits the tickless idle state when it can restore states it altered. The hook functions: These functions must be implemented by the power management service app. a) int _sys_soc_suspend(int32_t ticks) param ticks: - the upcoming kernel idle time return: - non-zero value if it uses its own idle or deep sleep. If a zero value is returned, then kernel will enter its own idle. Details: This is called immediately before the kernel prepares to go into its idle state. The PM service, based on the amount of idle time available, chooses an appropriate power policy comparing the wake latencies involved. For CPU low power states it would put the CPU in states like C2. For SoC deep sleep states, it would do the required SoC specific operation. In these, it would return a non-zero value indicating it has fully handled the idle and the kernel will not enter its own idle. For tickless idle power saving, the PM service app can turn off as many peripherals it requires and then returns a zero value. The zero return value would indicate to the kernel that it should do its own idle. This function is entered with interrupts disabled. It should re-enable interrupts if it does its own idle or deep sleep. If it returns zero then it should not enable interrupts so the kernel can go to idle state without interruption. b) void _sys_soc_resume(void) Details: The main purpose of this hook is to notify PM service of exit from SoC deep sleep state, CPU low power and tickless idle exit. Any states altered at _sys_soc_suspend() should be restored in this function. This hook function is called from 2 different locations in the kernel. PM service will check its internal states to determine which state the system recovering from. Following are the 2 different locations where it called from: 1. At kernel start recovering from deep sleep or entering cold boot. Deep sleep causes all CPU states to be lost so the system resumes at the reset vector taking the same path as cold boot. Since kernel does not save any state to identify whether it is recovering from cold boot or deep sleep, it would call this function in both cases. PM service can use SoC specific sticky registers that can retain values across deep sleep to identify whether it is resuming from deep sleep. In the case of cold boot, these registers would get reset. If it is cold boot then this function should return immediately doing nothing. If it is recovering from deep sleep then it should restore states including CPU registers and stack stored in _sys_soc_suspend(). Execution context should then switch to execution inside _sys_soc_suspend() at the location where it put the system to deep sleep. In this location, this function is called using a temporary stack that is also used by interrupts. It is important that this function switches to the stack that was saved during _sys_soc_suspend before interrupts are enabled when returning from _sys_soc_suspend() to avoid interfering with interrupt handlers use of this stack. 2. After the exit of tickless idle or a low power CPU state from the context of the ISR that caused the exit. In this case, PM service will restore altered states and return.
|
|
|
|
RFC [2/3] - SoC, CPU LPS, Tickless idle and Device power management
Thomas, Ramesh
***These are implemented and under review***
https://gerrit.zephyrproject.org/r/#/c/532/ https://gerrit.zephyrproject.org/r/#/c/528/ https://gerrit.zephyrproject.org/r/#/c/525/ Device driver power management hook infrastructure ------------------------------------------------------ When the _sys_soc_suspend() and _sys_soc_resume() hook functions are called, the PM service app may want to do some device specific operations. Zephyr kernel provides this infrastructure to enable device drivers to define suspend and resume hook functions that can be called by the PM service app. Following are the goals for providing this infrastructure: 1. A framework for drivers to implement generic suspend/resume hook functions. 2. Provide means for PM app service to call the suspend and resume functions of all devices in the system. This is necessary especially to do suspend and resume operations on system devices like the APIC device which do not export device binding interface. 3. Since not all devices need to implement suspend and resume hook functions, provide a no-op function by default for such devices. By default all devices would be setup with the no-op function for their hooks. The device drivers who need specific handling would assign the addresses of the functions they implement to these hooks during initialization. Non-goals: The implementation of the hook functions by the device drivers is up to each driver, the integrator and the system power management policies. All device power management infrastructure implementations is enclosed inside CONFIG_DEVICE_POWER flag. The hook functions for the PM service app: a) int device_suspend(struct device *port) param port: Device structure of the driver instance return: DEV_OK for success, error code otherwise Details - calls the suspend hook of the device associated with the device structure parameter. b) int device_resume(struct device *port) param port: Device structure of the driver instance return: DEV_OK for success, error code otherwise Details - calls the resume hook of the device associated with the device structure parameter. c) void device_suspend_all(bool system_devices) param system_devices Boolean true for only the system devices; else all devices Details: Kernel holds a list of all devices in the system. This function will iterate through that list and call the suspend hook function of each device in the list. It will do this in the reverse order in which the devices were initialized. If the <system_devices> parameter is false then it would call all devices. If it is true then it would call the suspend/resume of only system devices. This parameter is provided because it is mandatory for the PM service app to call this function for system devices. This is because it cannot bind to them and call their suspend/resume functions directly. For non-system devices, the PM service app can bind to thm and has the flexibility to call whichever device it requires to call and in the order it chooses to. If it chooses to call the suspend/resume functions of non-system devices individually, then it would call this function passing true for the <system_devices> parameter. d) void device_resume_all(bool system_devices) param system_devices Boolean true for only the system devices; else all devices Details: The description is same as for device_suspend_all() except, this would call the resume hook functions of devices and they would be called in the same order as the devices were initialized. API for device drivers: Structure storing the hook functions. This structure is stored in the device's "device" structure. struct device_power_ops { device_op_t suspend; device_op_t resume; } The NO-OP function: int device_pm_noop(struct device *unused) return - always returns DEV_OK. Details: No-op function that does nothing and returns DEV_OK immediately. This can be used to initialize hooks for which the device has no operation to do. The hooks inside device_power_ops structure are by default initialized with this function by the kernel. Device drivers which have specific operations for the hooks would overwrite with a suspend and resume functions during driver initialization. a) void device_power_ops_configure(struct device *port, device_op_t suspend_fn, device_op_t resume_fn) param port - device structure of driver instance param suspend_fn - Address of suspend function param resume_fn - Address of resume function Details: Initializes the hook functions in device_power_ops with the functions passed as parameters. This function should be called by devices during the time of initialization if they have a specific suspend or resume function implementation. Drivers can also pass the no-op function as parameter for any of the hooks it does not have an operation. If it does not have any operation for both suspend and resume then it need not call this function at all. This is because the hooks for the devices are by default initialized with the no-op function by the kernel.
|
|
|
|
RFC [3/3] - SoC, CPU LPS, Tickless idle and Device power management
Thomas, Ramesh
Areas to be implemented next:
1. ARC deep sleep support: - Currently ARC in quark_se would be reset upon deep sleep initiated from x86 core. It needs something like _sys_soc_resume() called at boot time so it can restore states and resume at the point it suspended. Suspend would be invoked from the x86 side so there is no need for a suspend function. 2. Nanokernel tickless idle PM support: - Currently tickless idle PM hooks are called only in microkernel idle task. The same hook functions should also be called from nanokernel tickless idle. Microkernel and Nanokernel implementations would be consolidated. This consolidation would also make names of functions uniform. 3. The naming of CONFIG flags and functions: - The CONFIG flag names would be made consistent with the new power management implementation. Also the dependencies between the flags would be improved and unnecessary fags removed. Feedbacks/Suggestions: 1. Provide arch specific helper functions used in the PM service app to do state transitions and save/restore CPU thread contexts. - Zephyr has arch specific code in arch folders. The suggestion is to add functions in these locations and abstract them to the PM service app.
|
|
|
|
Re: Building project
Nashif, Anas
You have a typo in your makefile? mico instead of micro?
Anas From: Corey Williamson <corey.bailey.williamson(a)gmail.com<mailto:corey.bailey.williamson(a)gmail.com>> Date: To: "devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>" <devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>> Subject: [devel] Building project Hi, I'm currently trying to build the hello world example in a directory outside the zephyr SDK and I keep getting this make error: corey(a)corey-H97M-D3H:~/ZephyrWorkspace/eclipse_workspace/hello_world$ make Using /home/corey/ZephyrWorkspace/zephyr-project/boards/frdm_k64f/frdm_k64f_defconfig as base Merging /home/corey/ZephyrWorkspace/zephyr-project/kernel/configs/mico.config The merge file '/home/corey/ZephyrWorkspace/zephyr-project/kernel/configs/mico.config' does not exist. Exit. make: *** [/home/corey/ZephyrWorkspace/eclipse_workspace/hello_world/outdir/.config] Error 1 I thought I might be environment variables but I echoed ZEPHYR_BASE and it was correct. Any help is much appreciated, Thanks! Corey
|
|
|
|
RFC - arm-gcc-embedded Toolchain Support
Hugo Vincent
Hi,
One of the complications of setting up a Zephyr development environment, especially on OS X, is having to get and build CrossTool-NG. ARM maintains an official distro and build of gcc and family for Cortex-M and Cortex-R at https://launchpad.net/gcc-arm-embedded, which provides pre-built binaries for Windows, Linux and Mac OS X. I created a simple, minimal Makefile.toolchain.gcc-arm-embedded that adds support for this toolchain to Zephyr, see attached patch. If there is interest in accepting this, I can add qemu and OpenOCD to this, as well as update the documentation, as well as generalising/parameterising the paths etc. Please advise how to proceed. I tested on the frdm_k64f board, with versions 4.9-2015-q2-update and 5.0-2015-q4-major of the toolchain, and with several of the example applications, and they all functioned correctly. (There is also another hunk in the patch that adds .DS_Store to gitignore -- it's a metadata file generated by the OS X Finder, and can be safely ignored). Regards, Hugo (Disclaimer: I work at ARM, but this is a personal contribution).
|
|
|
|
Re: RFC - arm-gcc-embedded Toolchain Support
Nashif, Anas
Hugo,
Looks good to me. You can also do that by specifying CROSS_COMPILE at the command line, for example: CROSS_COMPILE=arm-none-eabi- make BOARD=qemu_cortex_m3 will build using the installed ARM toolchain on my host. You do not need to specify the VARIANT. Thanks, Anas From: Hugo Vincent <hugo.vincent(a)gmail.com<mailto:hugo.vincent(a)gmail.com>> Date: To: "devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>" <devel(a)lists.zephyrproject.org<mailto:devel(a)lists.zephyrproject.org>> Subject: [devel] RFC - arm-gcc-embedded Toolchain Support Hi, One of the complications of setting up a Zephyr development environment, especially on OS X, is having to get and build CrossTool-NG. ARM maintains an official distro and build of gcc and family for Cortex-M and Cortex-R at https://launchpad.net/gcc-arm-embedded, which provides pre-built binaries for Windows, Linux and Mac OS X. I created a simple, minimal Makefile.toolchain.gcc-arm-embedded that adds support for this toolchain to Zephyr, see attached patch. If there is interest in accepting this, I can add qemu and OpenOCD to this, as well as update the documentation, as well as generalising/parameterising the paths etc. Please advise how to proceed. I tested on the frdm_k64f board, with versions 4.9-2015-q2-update and 5.0-2015-q4-major of the toolchain, and with several of the example applications, and they all functioned correctly. (There is also another hunk in the patch that adds .DS_Store to gitignore -- it's a metadata file generated by the OS X Finder, and can be safely ignored). Regards, Hugo (Disclaimer: I work at ARM, but this is a personal contribution).
|
|
|
|
Re: RFC: Counter driver API
Dirk Brandewie <dirk.j.brandewie@...>
On 02/26/2016 12:29 PM, Tseng, Kuo-Lang wrote:
Hi,end_count/expiration_count something like like that so the reader knows how the value is used. void (*callback)(void);Confused by this note. The always on counter does have an interrupt it the only way for the device to signal counter expiration. The hardware-specific driver implementation:
|
|
|
|
Re: RFC: Counter driver API
D'alton, Alexandre <alexandre.dalton@...>
There are 2 aon counters:
toggle quoted messageShow quoted text
Aon counter => monotinic counter without interrupt Aon periodic timer => periodic timer with interrupt support Regards, Alex.
-----Original Message-------------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
|
|
|
|
[PATCH 0/8] Adding generic suspend/resume infrasturcture.
dirk.brandewie@...
From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
Since this change set was loosely based on my RFC on the subject prior to release it is worth bringing the orginal design into this thread. Given that most/all platforms we are targeting will care deeply about power consumption this patch set changes the device model to *require* that every driver do something about suspend/resume even it is just providing a null implementation if there is nothing the device needs to do during a suspend/resume cycle. This patch does the following things: Adds suspend/resume to *all* devices. Provides a null suspend/resume implementation that can be used by *all* drivers. Provides an interface for the power management infrastrcuture (PMI) to call suspend/resume on the device without needing to know the type of the device. Provides an interface where the PMI can register callbacks with the driver to be called when suspend has completed and resume has started. These call backs allow the PMI to do any processing required to complete the suspend/resume of the device. e.g. clock control, power to IP block. This is needed since there may be multiple devices attached to a single clock or power island which can only be disabled once all attached devices are suspended and must be turned on prior to the first device resuming. This keeps *all* the information about a device in one place. Forces all drivers to support the suspend/resume interface. This will require that all the current drivers be updated to support the new interface. Now is the right time to do this before we get a *bunch* more drivers added to the tree. Patch 1 adds a PM enabled version of DEVICE_INIT() which is only there to keep things building while the drivers are being updated. Once all the drivers have been updated we can remove the extra macro with a single tree wide change. The API to suspend/resume all devices in the system was meant to show how the PMI might want to suspend all devices and is not complete since there is no error handling. After thinking about it more it is not clear to me that we should provide this convienence API. The changes to the GPIO interface and driver are meant to illustrate the changes that will need to be applied to all the drivers in the system. Dirk Brandewie (8): device: Add suspend/resume api functions to device structure device: Add _null_suspend_resume() function device: Add generic device_{suspend, resume}() API device: Add API to suspend/resume all devices in the system. device: pm: Add API for power management entity to register pm callbacks gpio: Remove suspend/resume from GPIO API gpio: gpio_dw: Use generic suspend suspend/resume API gpio: gpio_dw: Add suport for device_register_pm_ops() drivers/gpio/gpio_dw.c | 48 ++++++++++++++++---- drivers/gpio/gpio_dw.h | 2 + include/device.h | 109 +++++++++++++++++++++++++++++++++++++++++++++ include/gpio.h | 27 ----------- include/pm.h | 25 +++++++++++ kernel/nanokernel/device.c | 40 +++++++++++++++++ 6 files changed, 216 insertions(+), 35 deletions(-) create mode 100644 include/pm.h -- 2.4.3
|
|
|
|
[PATCH 1/7] device: Add _null_suspend_resume() function
dirk.brandewie@...
From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
Some devices may have no work to do in suspend/resume, but every device is required to provided a suspend/resume function to the power management subsystem. Provide generic noop suspend/resume functions to be reused by devices saving the code space for every device defining their own noop functions. Change-Id: Ia1c2edd97fc9cdaff36967f2e4901fadbaca65bf Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com> --- include/device.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/include/device.h b/include/device.h index 64b1e6f..5dbb52f 100644 --- a/include/device.h +++ b/include/device.h @@ -261,6 +261,11 @@ struct device { void _sys_device_do_config_level(int level); struct device* device_get_binding(char *name); +static inline int _null_suspend_resume(struct device *device) +{ + return 0; +}; + /** * Synchronous calls API */ -- 2.4.3
|
|
|
|
[PATCH 1/8] device: Add suspend/resume api functions to device structure
dirk.brandewie@...
From: Dirk Brandewie <dirk.j.brandewie(a)intel.com>
Suspend and resume are generic functions that each device should support. Move the suspend/resume API functions to the top level device structure. This change allows for the application to call suspend/resume without needing to know device type. Change-Id: I2fa7b13f75faeb83106ced83cd07ddbae4c915d6 Signed-off-by: Dirk Brandewie <dirk.j.brandewie(a)intel.com> --- include/device.h | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) diff --git a/include/device.h b/include/device.h index e2e657d..64b1e6f 100644 --- a/include/device.h +++ b/include/device.h @@ -147,6 +147,70 @@ extern "C" { */ #define DEVICE_DECLARE(name) extern struct device DEVICE_NAME_GET(name) +/** + * @def DEVICE_INIT_PM + * + * @brief create device object and set it up for boot time initialization + * + * @details This macro defines a device object that is automatically + * configured by the kernel during system initialization. + * + * @param dev_name Device name. + * + * @param drv_name The name this instance of the driver exposes to + * the system. + * + * @param init_fn Address to the init function of the driver. + * + * @param device_fn Address of device_ops structure for device. + * + * @param data Pointer to the device's configuration data. + * + * @param cfg_info The address to the structure containing the + * configuration information for this instance of the driver. + * + * @param level The initialization level at which configuration occurs. + * Must be one of the following symbols, which are listed in the order + * they are performed by the kernel: + * + * PRIMARY: Used for devices that have no dependencies, such as those + * that rely solely on hardware present in the processor/SOC. These devices + * cannot use any kernel services during configuration, since they are not + * yet available. + * + * SECONDARY: Used for devices that rely on the initialization of devices + * initialized as part of the PRIMARY level. These devices cannot use any + * kernel services during configuration, since they are not yet available. + * + * NANOKERNEL: Used for devices that require nanokernel services during + * configuration. + * + * MICROKERNEL: Used for devices that require microkernel services during + * configuration. + * + * APPLICATION: Used for application components (i.e. non-kernel components) + * that need automatic configuration. These devices can use all services + * provided by the kernel during configuration. + * + * @param prio The initialization priority of the device, relative to + * other devices of the same initialization level. Specified as an integer + * value in the range 0 to 99; lower values indicate earlier initialization. + * Must be a decimal integer literal without leading zeroes or sign (e.g. 32), + * or an equivalent symbolic name (e.g. #define MY_INIT_PRIO 32); symbolic + * expressions are *not* permitted + * (e.g. CONFIG_KERNEL_INIT_PRIORITY_DEFAULT + 5). + */ + +#define DECLARE_INIT_PM(cfg_name, drv_name, init_fn, \ + device_fn, config)\ + static struct device_config config_##cfg_name __used \ + __attribute__((__section__(".devconfig.init"))) = { \ + .name = drv_name, .init = (init_fn), \ + .dev_ops = device_fn, \ + .config_info = (config) \ + } + + /* Common Error Codes devices can provide */ #define DEV_OK 0 /* No error */ #define DEV_FAIL 1 /* General operation failure */ @@ -160,6 +224,15 @@ extern "C" { struct device; /** + * @brief Specify the operations common across all devices + * @param init init function for the driver + */ +struct device_ops { + int (*suspend)(struct device *device); + int (*resume)(struct device *device); +}; + +/** * @brief Static device information (In ROM) Per driver instance * @param name name of the device * @param init init function for the driver @@ -168,6 +241,7 @@ struct device; struct device_config { char *name; int (*init)(struct device *device); + struct device_ops *dev_ops; void *config_info; }; -- 2.4.3
|
|
|
