Hello, This is a hardware-agnostic issue, see: https://jira.zephyrproject.org/browse/ZEP-428. The issue description is not really useful, although comments will help. BTW, we apply the same

Hi everyone, I would like to propose the re-design of PWM API interfaces. (https://jira.zephyrproject.org/browse/ZEP-745). PWM APIs had been through a few times of updates from different

Hello Rohit, et al, Thanks for the information below. I didn't yet have chance to test multiple TCP/IPv4 connections in row, because I have issue with reliably handling one. Just as before, my setup

NEW JIRA items within last 24 hours: 3 [ZEP-865] convert filesystem sample to a runnable test https://jira.zephyrproject.org/browse/ZEP-865 [ZEP-869] TCP connection fails if communication slows

What about your lock that you'll use in the RFC's proposed of spi_tranceive? I think I've must have misunderstood something fundamental, because I see so difference between A(); B();

NEW within last 24 hours: - https://gerrit.zephyrproject.org/r/4773 : Bluetooth: Controller: Make HCI endianness-independent - https://gerrit.zephyrproject.org/r/4774 : intel_quark: move X86_IAMCU

Hi Jon, As I said your example does not work unless you keep track of who owns the lock. And anyway, it looks ugly to handle low level SPI concept (CS) in user API. You _cannot_ know in your code,

I was assuming 'lock' == mutex/semaphore and would be the same method you would use in a single function. E.g. Single function... lock do some work unlock Separate function1 lock do some

Hi Jon, I guess we would have to think about something driver generic, configured through board.h also. There isn't much other way. Or it can be done through Kconfig as well, though that could end

Except as I want zero copy now, with current APIs, I have to handle CS manually, outside the SPI driver; that's what I meant. I didn't want to write code to handle GPIO chip select in the driver which

Hi Jon, For this to work, you would need to relate the lock to the caller, to block any other caller to mess up. It's possible (fiber/task id), but a bit more bloated than doing all at once in one

I'm was just wondering how to tell a generic SPI driver, which DMA to use. Or how it requests one itself. Or if these things we're going to have to be hard coded at build time in a device specific

[...] I don't see that concurrent access is any more of a problem with this than without it. What if a task calls the single transceive() function you propose, then that task gets preempted and

Hi Jon, I call it a hack in DW driver, because this controller has a CS... which is broken. Legacy or new API: your driver will have to deal with CS internally, either controlling the controller's

Eitan,, In principle I agree we need to support additional backends, but I do not think this fits in how it is being done in sys_log.h. I propose to extend syslog to support custom backends without

Not sure why you call this a 'hack'. Anyway, the serial device IP I'm writing an SPI driver for (ARM's PL022) doesn't have a concept of a chip select, so I'm going to have to implement this same

Hi Jon, DMA is not meant to support such scatter-gather buffer, but it would be easy to wrap dma primitives to do so. (However, I don't know why it separates transfer cb and error cb, these could

From memory/complexity point of view, is it better to provide a spi_config for each slave device (thus the slave id into it), or is it better to have one possibility to share the same spi_config?

Take a look at https://jira.zephyrproject.org/browse/ZEP-783. My idea is to start sending those patches over the next few days, once I'm done with some other unrelated critical work. Also check