Re: RFC: Counter driver API
Tseng, Kuo-Lang <kuo-lang.tseng@...>
Since this RFC has been quietly for a while and it seems we have reached
toggle quoted messageShow quoted text
a good amount of feedback so we will implement it and update the current patch.
-----Original Message-----
|
|
Re: [RFC] GPIO API changes
Hi Tomasz,
On Mon, Mar 07, 2016, Tomasz Bursztyka wrote: -typedef void (*gpio_callback_t)(struct device *port, uint32_t pin);I realize this typedef is inherited from the original code, but do we really need/want to enforce an opaque type here? The general preference with the coding style (inherited from Linux and checkpatch even complains about it) is to avoid typedefs whenever possible. I could e.g. imagine a handler function wanting set/unset some pins in the pin_mask when it gets called, in which case the struct couldn't be considered completely opaque. Johan
|
|
Re: [RFC] GPIO API changes
Vinicius Costa Gomes
Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> writes:
Hi Vinicius,I am just wondering that in the "old" API '_port_enable_callback()' wasAnother issue of the current API is the confusion caused bygpio_port_callback() make the callback called, whatever pins is a way to have the callback called with the pins expressed in a bitmask, now the same behaviour can be achieved by running '_pin_enable_callback(port, 0xffffffff)'. Just saying that, with the new API, '_port_enable_callback()' adds little value.
Cheers, -- Vinicius
|
|
Re: [RFC] GPIO API changes
Tomasz Bursztyka
Hi IvĂ¡n,
It's 2 different features:Consider there's a set/unset function in those changes, do we need to - one (un)install a callback function (and the pins it's interested in) - one enable or disable the interrupt trigger (and keeps track of it) of one pin. You might want to inhibate a pin to raise a cb, without removing the callback that would be used for other pins. For instance gpio_set_callback(my_cb) /* interested by pin x and y*/ gpio_enable_callback(pin_y) and: my_cb(pins) { if (pins & pin_y) { gpio_disable_callback(pin_y) gpio_enable_callback(pin_x) } else { gpio_disable_callback(pin_x) gpio_enable_callback(pin_y) } } Something like that could be needed. Tomasz
|
|
Re: [RFC] GPIO API changes
Tomasz Bursztyka
Hi Vinicius,
Another issue of the current API is the confusion caused bygpio_port_callback() make the callback called, whatever pins is triggering the interrupt and enabled or not (callback wise). So they are different (documentation could be better though) gpio_dw.c implementation is awkward however: I don't think it should by default enable the int on pin 0. Tomasz
|
|
Re: [RFC] GPIO API changes
IvĂ¡n Briano <ivan.briano at intel.com...>
On Mon, 07 Mar 2016 11:13:55 -0300, Vinicius Costa Gomes wrote:
Hi,Consider there's a set/unset function in those changes, do we need to enable? Can't we infer from the callbacks the user sets?
|
|
Re: [RFC] GPIO API changes
Vinicius Costa Gomes
Hi,
Sorry if I am a little too late. Tomasz Bursztyka <tomasz.bursztyka(a)linux.intel.com> writes: Hi,Another issue of the current API is the confusion caused by 'gpio_port_enable_callback()' and 'gpio_pin_enable_callback()'. With the changes proposed later in this thread, you could have a unified call: 'gpio_enable_callback(struct device *port, uint32_t pinmask)' (or something like it) [...] Cheers, -- Vinicius
|
|
Re: [RFC] GPIO API changes
Tomasz Bursztyka
static inline int gpio_dw_set_callback(struct device *port,When I say it's untested, it's for real ... should be *callback here. /**With new api, this would call all callback handles, whatever is their pin_mask. (see _gpio_fire_callbacks())
|
|
Re: [RFC] GPIO API changes
Tomasz Bursztyka
Hi,
I quickly went through prototyping something, only to detail the RFC (so it's not really tested etc...) Also, it's not something that I am planning to send right away as it breaks the former API. See attached. For the user data pointer, it's only a matter to use CONTAINER_OF() with given cb pointer as Johan noticed. I put the generic callback list functions into a header in drivers/gpio/, not sure it's would be the final place. Tomasz
|
|
Zephyr v1.1.0 tagged
Nashif, Anas
Hi,
Zephyr v1.1.0 was tagged 2 days ago and merge window for the next release is no open. Release notes and other details will be posted on the website. Here is the log of changes since the rc1. Merge window for v1.2.0 will close March 18th, so please submit any major changes by this date. Anas Nashif (3): Revert "samples: A test app for WinBond spi flash" sanitycheck: updated footprint numbers Zephyr 1.1.0 Andre Guedes (1): samples: Add UART application Andrei Emeltchenko (1): Bluetooth: Fix typo subscribtions to subscriptions Andrew Boie (7): sanitycheck: fail on footprint analysis of stripped ELFs gen_idt: correctly warn on duplicate IRQ connections REVERTME: bluetooth: tests: disable some tests sys_io: introduce bitfield ops test_bitfield: exercise sys_*_bit and sys_bitfield_*_bit sys_io: don't allow negative bit offsets system_apic: rename irq_enable/disable Dan Kalowsky (1): arch: arm: set the architecture via Kconfig Johan Hedberg (5): include: Add UNALIGNED_PUT helper include: Remove UNALIGNED_READ & UNALIGNED_WRITE drivers/spi: dw: Fix unaligned access drivers/spi: intel: Fix typo in DBG log SPI: Change read/write buffer pointers to void * Leona Cook (4): doc: Edit microkernel_semaphores.rst for consist structure and APIs. doc: Add clarification to common execution contexts docs doc: Edit microkernel_events for clarity, ReST syntax, and parallelism. doc: Edit microkernel_timers.rst with better ReST syntax to enhance readability. Maciek Borzecki (1): gitignore: make sure that SOC specific linker scripts stay visible Mariusz Skamra (1): Bluetooth: tester: Fix missing le to host order conversion Ramesh Thomas (1): power_mgmt:sample:Power Manager application Ravi kumar Veeramally (4): net: Fix NETWORKING_WITH_15_4_TI_CC2520 config option net: apps: Fix echo apps Makefile net: apps: Add separate prj_qemu.conf for board type qemu net: 802.15.4: Fix the dummy driver Vlad Lungu (2): spi: intel: fix typo in port 1 configuration spi: intel: fix write failures at low speeds Yannis Damigos (2): zephyr-env.sh: Set correctly $ZEPHYR_BASE in zsh arch: & kernel: Updated Kconfigs to remove errors in html generation .gitignore | 2 +- Makefile | 2 +- arch/arc/Kconfig | 5 +- arch/arm/Makefile | 6 + arch/arm/core/cortex_m/Kconfig | 3 +- arch/arm/soc/atmel_sam3/Makefile | 3 +- arch/arm/soc/fsl_frdm_k64f/Makefile | 4 +- arch/arm/soc/ti_lm3s6965/Makefile | 3 +- doc/kernel/common/common_contexts.rst | 49 +- doc/kernel/microkernel/microkernel_events.rst | 94 +- doc/kernel/microkernel/microkernel_semaphores.rst | 60 +- doc/kernel/microkernel/microkernel_timers.rst | 102 +- drivers/adc/adc_ti_adc108s102.c | 9 +- drivers/interrupt_controller/system_apic.c | 5 +- drivers/spi/spi_dw.c | 16 +- drivers/spi/spi_dw.h | 2 +- drivers/spi/spi_intel.c | 54 +- drivers/spi/spi_intel.h | 9 +- drivers/spi/spi_qmsi.c | 4 +- include/arch/arc/v2/asm_inline_gcc.h | 64 +- include/arch/x86/asm_inline_gcc.h | 30 +- include/spi.h | 12 +- include/sys_io.h | 90 +- include/toolchain/gcc.h | 17 +- kernel/Kconfig | 1 + kernel/microkernel/Kconfig | 1 + net/bluetooth/gatt.c | 4 +- net/ip/Kconfig | 1 - net/ip/dummy_15_4_radio.c | 20 +- samples/drivers/spi_flash/Makefile | 6 - samples/drivers/spi_flash/README.txt | 35 - samples/drivers/spi_flash/prj.conf | 7 - samples/drivers/spi_flash/prj.mdef | 5 - samples/drivers/spi_flash/src/Makefile | 1 - samples/drivers/spi_flash/src/main.c | 75 -- samples/drivers/uart/Makefile | 5 + samples/drivers/uart/prj.config | 1 + samples/drivers/uart/src/Makefile | 1 + samples/drivers/uart/src/main.c | 55 + samples/net/echo_client/Makefile | 6 +- samples/net/echo_client/prj_qemu.conf | 11 + samples/net/echo_server/Makefile | 6 +- samples/net/echo_server/Makefile.ipstack | 19 +- samples/net/echo_server/prj_qemu.conf | 10 + samples/power/power_mgr/Makefile | 6 + samples/power/power_mgr/README.txt | 56 + samples/power/power_mgr/prj.conf | 5 + samples/power/power_mgr/prj.mdef | 5 + samples/power/power_mgr/src/Makefile | 1 + samples/power/power_mgr/src/main.c | 165 +++ samples/power/power_mgr/testcase.ini | 5 + scripts/gen_idt/gen_idt.c | 5 +- scripts/sanity_chk/sanity_last_release.csv | 1144 ++++++++++----------- scripts/sanitycheck | 5 +- tests/bluetooth/shell/testcase.ini | 5 +- tests/bluetooth/tester/src/gatt.c | 6 +- tests/bluetooth/tester/testcase.ini | 3 +- tests/kernel/test_bitfield/Makefile | 4 + tests/kernel/test_bitfield/src/Makefile | 3 + tests/kernel/test_bitfield/src/bitfield.c | 208 ++++ tests/kernel/test_bitfield/testcase.ini | 4 + zephyr-env.sh | 4 +- 62 files changed, 1528 insertions(+), 1021 deletions(-)
|
|
Re: RFC[2/2] Common logging infrastructure and API
Tomasz Bursztyka
Hi,
How is this logging infra RFC going? :) Just noticed one thing to change as well: include/misc/__assert.h Would be nice if those __ASSERT macros would use this logging facilities as well. Tomasz
|
|
Re: STM32F103x port
Maciek Borzecki <maciek.borzecki@...>
Hi,
I've uploaded another patchset. Some of the patches have only gone through updates. Specifically clock_control and the base st_stm32 tree patch. I've decided to keep the RCC driver MCU specific. I'm not sure there's a nice and clean way of organizing this so. I think that the device name is unfortunately the only common part we can have for STM32 families, and so the device is initialized using STM32_CLOCK_CONTROL_NAME. GPIO and pinmux drivers have gone through a major change. I've tried to have a common base for GPIO and pinmux drivers, while proving the SoC specific functionality within arch/arm/soc/st_stm32/stm32f1 tree. The way it's implemented, the driver headers (gpio_stm32.h and pinmux_stm32.h) declare a couple of functions that need to be implemented by the soc integration. The divergence in register contents between, STM32F1 and STM32F4 as well as the approach for alternate function setup is too large to my liking. I think that callig SoC specific integration is a good compromise and would allow to keep the code maintainable. There is a chicken and egg problem with the GPIO and pimux, namely the common GPIO diver without the pinmux patch. I did not want to squash the code into one large patch to keep the things civil. Just a thing to remember, that these would have to be merged at the same time. Since I got my Nucleo-64 F103RB, I've added the config for this bard as well. The 'disco' sample has also been updated to be directly usable on the Nucleo board rather than the obscure STM32 MINI A15. I've also added 2 changes (709, 710) that will be unnecessary. A similar fix from Daniel K has been posted. Once that is merged 2 master I'll just rebase skipping my 2 patches. New Changes: https://gerrit.zephyrproject.org/r/709 arch/arm/cortex_m: move fallback NMI handler to common Cortex-M https://gerrit.zephyrproject.org/r/710 arch/arm: move NMI_INIT() helper macro to cortex_m common header https://gerrit.zephyrproject.org/r/711 clock_control/Kconfig: move quark_se entries to separate file https://gerrit.zephyrproject.org/r/712 clock_control: extend API with clock rate query operation https://gerrit.zephyrproject.org/r/713 soc/stm32f1/gpio: implement GPIO support https://gerrit.zephyrproject.org/r/714 soc/stm32f1/pinmux: implement STM32 pinmux integration https://gerrit.zephyrproject.org/r/715 boards/nucleo_f103rb: add new board Updated Changes: https://gerrit.zephyrproject.org/r/645 st_stm32/stm32f1: introduce STM32F1x SoC family https://gerrit.zephyrproject.org/r/646 clock_control/Kconfig: fix quark_se dependencies https://gerrit.zephyrproject.org/r/647 clock_control/stm32f10x: introduce new driver for STM32F10x RCC https://gerrit.zephyrproject.org/r/648 soc/stm32f1: add GPIO registers mapping https://gerrit.zephyrproject.org/r/649 pinmux/stm32: add common driver for STM32 pinmux https://gerrit.zephyrproject.org/r/650 serial/stm32: add new driver for STM32 UART https://gerrit.zephyrproject.org/r/651 gpio/stm32: add common driver for STM32 GPIO https://gerrit.zephyrproject.org/r/652 boards/stm32_mini_a15: add new board https://gerrit.zephyrproject.org/r/653 samples/disco: add 'disco' sample program -- Maciek Borzecki
|
|
Re: [RFC] Sensor API
Dmitriy Korovkin
On Thu, 3 Mar 2016, Vlad Dogaru wrote:
Hi everyone,As for me, it's a very good aproach for drivers in general. At the very least, it reduces interrupt latency. Keeping in mind the fact that some drivers support callback functions, it may be reasonable to off-load callback functionality to triggered fibers. Regards, Dmitriy In this new iteration, the user is given a choice via Kconfig of the
|
|
Re: [RFC v2] uart: add ISR callback mechanism for UART drivers
Daniel Leung <daniel.leung@...>
On Thu, Mar 03, 2016 at 12:30:09PM -0300, Andre Guedes wrote:
Hi Daniel,I have created a JIRA to address this @ https://jira.zephyrproject.org/browse/ZEP-89 ----- Daniel Leung
|
|
Re: STM32F103x port
Tomasz Bursztyka
Hi Maciek,
Can you check if drivers in the patchset that I posted are useful forWould be great to generalize as much as possible now. At least for what's concerning stm32. For instance, maybe gpio/pinmuxer could be generalized as well that way. Tomasz
|
|
Re: RFC: Use error codes from errno.h
Andre Guedes <andre.guedes@...>
Hi,
Quoting Nashif, Anas (2016-03-04 09:34:45) Nice, let's move on with this convention. I'll send patches to gerrit soon.Yes please, Thanks all, Andre
|
|
Re: RFC: Use error codes from errno.h
Nashif, Anas
On 4 Mar 2016, at 07:28, Jesus Sanchez-Palencia <jesus.sanchez-palencia(a)intel.com> wrote:Yes please, Thanks. Anas thanks,
|
|
Re: STM32F103x port
Maciek Borzecki <maciek.borzecki@...>
On Fri, Mar 4, 2016 at 7:44 AM, Pawel Wodnicki <root(a)32bitmicro.com> wrote:
Hej Maciek,That's great. I'll definitely take a look at it. Can you check if drivers in the patchset that I posted are useful for you? Specifically, the UART driver might be reusable across a larger number of MCUs. Browsing the Reference Manuals I noticed some bit differences in UART registers, but nothing that cannot be handled by per MCU-family ifdefs. Cheers, -- Maciek Borzecki
|
|
Re: STM32F103x port
Pawel Wodnicki <root@...>
Hej Maciek,
I added stm32f4 support to your stm32 patch: https://gerrit.zephyrproject.org/r/#/c/671/ Code is tested to run on Nucleo board included it the patch. Cheers, Pawel
|
|
Re: RFC: Counter driver API
Tseng, Kuo-Lang <kuo-lang.tseng@...>
Hi Andre, Tomasz, Jesus,
toggle quoted messageShow quoted text
Thanks for your feedbacks. I updated the API with these feedbacks. Please correct or if I missed any part that needed to be reflected. The updated API looks like below: /** * Start the counter device. If the device is a 'count up' counter the * counter initial value is set to zero. If it is a 'countdown' counter * the initial value is set to the maximum value supported by the device. * * @brief Start counter device in free running mode. * @param dev Pointer to the device structure for the driver instance. * @retval DEV_OK If successful. * @retval DEV_* Code otherwise. */ int counter_start(struct device *dev); /** * @brief Stop counter device. If alarm was set, this function also clears * the alarm setting. * @param dev Pointer to the device structure for the driver instance. * * @retval DEV_OK If successful. * @retval DEV_NO_SUPPORT if the device doesn't support stopping the * counter (e.g. free running counters). */ int counter_stop(struct device *dev); /** * @brief Read current counter value * @param dev Pointer to the device structure for the driver instance. * * @return 32-bit value */ uint32_t counter_read(struct device *dev); /** * Set an alarm. * * @brief Set an alarm. * @param dev Pointer to the device structure for the driver instance. * @param callback Pointer to the callback function. If this is NULL, this function * unsets the alarm. * @param count Number of counter ticks. * @param user_data pointer to user data * * @retval DEV_OK If successful. * @retval DEV_INVALID_OP If the counter was not started yet. * @retval DEV_NO_SUPPORT if the device doesn't support interrupt (e.g. * free running counters). */ int counter_set_alarm(struct device *dev, counter_callback_t callback, uint32_t count, void *user_data); typedef void (*counter_callback_t)(struct device *dev, void *user_data)
-----Original Message-----
|
|