Date   

Re: Suggestions for getting started

Kumar Gala
 

On Jan 18, 2017, at 12:29 PM, Abhinav Misra <abhitheextremeeng(a)gmail.com> wrote:

Hi All,

Hope everybody is doing well.

I recently joined the zephyr devel mailing list and going through the documentation and other starters stuffs as being new to open source development.

I want to contribute to the project.Please suggest me some ways how to get started and on to which things to focus on.

I have following boards - :
1. Beagle bone black
2. STM32 discovery board
3. TI's MSP432

Any type of suggestion and help would be much appreciated.

Regards,
Abhinav
Which STM32 discovery board do you have, this is possibly the best starting point to try and get zephyr up and running.

What kinda of work or code have you developed in the past? Any particular area of interest?

- k


Re: [RFC]DMA API Update

Liu, Baohong
 

From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
Sent: Monday, January 16, 2017 7:16 AM
Subject: Re: [devel] [RFC]DMA API Update

On Sat, 2017-01-14 at 00:31 +0000, Liu, Baohong wrote:
Thanks for the feedback. See my reply inline.
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
[...]

But finally, the big elephant in the room is: how are DMA APIs
actually expected to used? And how should the system be configured?
The same way as other device drivers. There will be a driver to
implement the APIs for each SoC. App does the config, and initiate the
transfer by calling the APIs.
As far as I can see there is no documentation or examples in Zephyr that give
a clue as to how DMA can be used with device drivers. So it's very difficult to
review a DMA API without some more explanation on it's expected use.
The DMA API can be used by drivers for DMA operations


Let me try some more specific questions...

Say I have a system which has:
A) a driver for a DMA Controller (it implement struct dma_driver_api)
B) a driver for some interface, e.g. SPI
C) an app which wants to talk to a device attached to that interface
e.g. and LCD controller
D) other things

Which of the above will call

- dma_channel_config
- dma_transfer_config
- dma_transfer_start
- dma_transfer_stop

?
IMO, ideally the SPI driver should call the DMA API to implement the DMA support.
However, I think this is up to the driver to decide to use the DMA API or to utilize a
HAL driver it depends on


The SPI subsystem interface doesn't have anything DMA related in it, so I can
only assume that DMA use will have to be hidden inside the SPI driver, and
for each spi_transceive request made made of it will setup and operate on
an appropriate struct dma_transfer_config? (Or use scatter-gather lists when
API's get that ;-)

If so, every device driver in zephyr that anyone wants to use with DMA will
need to add DMA support to it and make it configurable to
(optionally) use the generic DMA API. Or is it expected that all APIs like SPI
grow new functions for use with DMA specifically?
Either one is fine.


That still leaves the question as to who calls dma_channel_config and how
the parameters for that get into the system. Is each driver that implements
DMA support going to have a bunch of KConfig entries to dma_slot,
hankshake_polarity etc? Or will the SoC have a bunch of #defines (like we
currently have for IRQ numbers) for setting these DMA attributes (assuming
they are fixed in hardware).
The DMA driver should have configuration entries for setting these parameters and
the values of these configurations should be determined and set by an app level
prj.conf, not by the SPI or DMA driver


There's also the question as to how channel numbers are allocated. Is this
more per-driver KConfig options or should we have a DMA channel allocator
function so they can just be assigned at runtime?

I'm also thinking about the fact that there are likely to be more devices
capable of DMA than channels available so how about an API to free a
channel? E.g. dma_channel_config claims a channel for use and
dma_channel_free releases for someone else. That way even with static
allocation of channels we have the option of allocating the same channel to
two different devices if we know they can't be active at the same time.
The current API dma_channel_config can support this; when the channel is being used by
a driver, if another driver calls the dma_channel_config API, the API should return an
specific error code indicating the channel is not ready to be used.

--
Tixy


Re: [RFC]DMA API Update

Liu, Baohong
 

From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
Sent: Wednesday, January 18, 2017 3:31 AM
Subject: Re: [devel] [RFC]DMA API Update

On Wed, 2017-01-18 at 01:14 +0000, Liu, Baohong wrote:
-----Original Message-----
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
[...]
?

The SPI subsystem interface doesn't have anything DMA related in it,
so I can only assume that DMA use will have to be hidden inside the
SPI driver, and for each spi_transceive request made made of it will
setup and operate on an appropriate struct dma_transfer_config? (Or
use scatter-gather lists when API's get that ;-)

If so, every device driver in zephyr that anyone wants to use with
DMA will need to add DMA support to it and make it configurable to
(optionally) use the generic DMA API. Or is it expected that all
APIs like SPI grow new functions for use with DMA specifically?

That still leaves the question as to who calls dma_channel_config
and how the parameters for that get into the system. Is each driver
that implements DMA support going to have a bunch of KConfig entries
to dma_slot, hankshake_polarity etc? Or will the SoC have a bunch of
#defines (like we currently have for IRQ numbers) for setting these
DMA attributes (assuming they are fixed in hardware).

There's also the question as to how channel numbers are allocated.
Is this more per-driver KConfig options or should we have a DMA
channel allocator function so they can just be assigned at runtime?
What you said is the scenario of driver over driver. There are
existing examples In Zephyr.
Just to clarify my previous answer which is meant to say that there are existing
usage cases a driver use API from another driver. (e.g some sensor drivers uses
I2C driver API)

For the channel assignment, I think this should be decided and set by an app level
Prj.conf, not by driver Kconfig.


Where? I can only assume you have in mind the things in
ext/hal/qmsi/drivers which is only occurrence of DMA in the Zephyr tree I
can find. Those drivers look hard coded for use on a single SoC and have
driver specific APIs for DMA, and nothing in-tree uses those APIs.

Also, there is no app in-tree that actually uses DMA apart from
test_loop_transfer which just does a simple memory-to-memory DMA test.

If the idea is that people should follow the Quark example, then it looks to
me that your saying DMA support in drivers is something everyone has to
design for themselves on a per-driver basis? If so, there'll be no API
consistency between drivers and every app will be hard coded to a particular
set of drivers.

But I can't believe that is what is intended, so I must have mis- understood
something fundamental.
The DMA API is designed to solve that; ideally app or drivers should all use the DMA
API to implement DMA support

--
Tixy


Re: [RFC]DMA API Update

Tseng, Kuo-Lang <kuo-lang.tseng@...>
 

Baohong,

-----Original Message-----
From: Liu, Baohong [mailto:baohong.liu(a)intel.com]
Sent: Tuesday, January 17, 2017 4:52 PM


Hi everyone,

Based on the feedbacks, I updated the RFC.
[...]

/**
* @brief DMA channel configuration structure.
*
* config is a bit field with the following parts:
* dma_slot [ 0 : 5 ] --which peripheral and direction(HW
specific)
* hankshake_polarity [ 6 ] --high or low
* channel_direction [ 7 : 9 ] --0-memory to memory, 1-memory to
peripheral,
* 2-peripheral to memory ...
* complete_int_en [ 10 ] --completion interrupt enable
* block_int_en [ 11 ] --block completion interrupt enable
* source_int_en [ 12 ] --source completion interrupt enable
* dest_int_en [ 13 ] --destination completion interrupt
enable
* error_int_en [ 14 ] --error interrupt enable
* source_handshake [ 15 ] --HW or SW
* dest_handshake [ 16 ] --HW or SW
I thought the original idea (from ZEP-873) was to minimize the dma_channel_config
structure by removing SoC or driver specific entries like the handshake interface
above which may not be common in other DMA engines. IMO, those should be kept
inside the driver and not to be exposed in API.

Kuo


SSH on Galileo

Fábio Iaione <fabio.iaione at gmail.com...>
 

Dear Sirs,
Does Zephyr have SSH support?
Thank you.


Re: Zephyr on STM32F042/072/405 with USB?

Christer Weinigel
 

Hi Erwan,

well, it wasn't too hard. Almost everything is already implemented in
the STM Cube drivers and only a little bit of glue code was needed.

I've only implemented the functions needed by the cdc_acm driver so
other higher level drivers such as mass storage will probably not work.
It's not very heavily tested and might contain race conditions that will
show up under load. But it's a start.

https://gerrit.zephyrproject.org/r/#/c/10175/

Even if this driver doesn't break down under load, performance will suck
due to the way I've implemented the usb_dc_ep_read function. The upper
layers expect the usb_dc_read function to return data immediately while
the STM32 Cube HAL_PCD_EP_Receive function only starts a read and data
will not be available until HAL_PCD_DataOutStageCallback is called by
the HAL. The way I have worked around this for the moment is to have an
extra packet buffer in the usb_dc_stm driver that HAL_PCD_EP_Receive
reads into, and then when usb_dc_ep_read is called data from this buffer
is copied to higher level driver. In the case of cdc_acm driver, this
will be done 4 bytes at a time, and then the data in the cdc_acm buffer
is copied to yet another buffer one byte at a time and when data is read
from the serial buffer it's copied again.

To get decent performance out of the STM32 Cube drivers all higher level
drivers ought to split usb_dc_ep_read into a usb_dc_ep_start_read and a
usb_dc_ep_get_read_count function so that it matches what the HAL layer
does. It's a bit painful, but shouldn't be that hard.

If the higher level driver is also aware of USB packet boundaries and
alighment this could also allow DMA directly into the driver buffers for
hardware (such as the STM32F4xx) that supports it.

/Christer

On 2017-01-16 11:31, Erwan Gouriou wrote:
Hi Christer,

Thanks in advance for these tasks.

For USB support on STM32, it would be great that this work could benefit
to the whole STM32 family.
STM32Cube SDK could help you in implementing a single driver common to
STM32 SoCs thanks to HAL.
Should you prefer to implement a zephyr native driver, please note that
Cube SDKs
provides CMSIS defines, structures and macros that are useful for
abstracting
differences between SoC and keep genericity in your driver.

Good luck with this work
Erwan


On 15 January 2017 at 17:13, Christer Weinigel <christer(a)weinigel.se
<mailto:christer(a)weinigel.se>> wrote:

Hi all,

I have a bunch of STM32F042/072/405 based boards that I'm currently
running ChibiOS on. I'm thinking about porting Zephyr to these boards
and also try to add support for the USB device in them.
Before I spend a lot of time trying to do this, is anyone else working
on support for those MCUs or on the USB device? It would be kind of
silly of I someone else has already done that and I would duplicate
their work.

/Christer


Re: Any plan for OTA support?

David Brown
 

We are working on the Mynewt bootloader (which is going to be its own
project, called mcuboot). I have the OTA update as something that needs to
be done, but I'm not aware of currently plans to implement anything.

David

On Sat, Jan 14, 2017 at 12:10 PM Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
wrote:

Hi Linh,



I was actually asking myself the same question recently. I think Linaro
has started working on making the Mynewt bootloader usable with Zephyr, but
that is only the first step I assume.



Also, to add a bit to your question, are there plans for IP-based OTA
only, or is “regular” BLE OTA support also planned? By regular I mean
similar to the proprietary solutions that vendors offer today, where one
can update the firmware using only GATT, without requiring IPSP or LE
Connection-Oriented Channels.



Thanks,



Carles



*From:* nvl1109(a)gmail.com [mailto:nvl1109(a)gmail.com]
*Sent:* Saturday, January 14, 2017 15:43
*To:* devel(a)lists.zephyrproject.org <devel(a)lists.zephyrproject.org>
*Subject:* [devel] Any plan for OTA support?



Hi all,



Do you have any plans to support OTA framework on Zephyr?



Thank & Regards,
Linh Nguyen



Suggestions for getting started

Abhinav Misra
 

Hi All,

Hope everybody is doing well.

I recently joined the zephyr devel mailing list and going through the
documentation and other starters stuffs as being new to open source
development.

I want to contribute to the project.Please suggest me some ways how to get
started and on to which things to focus on.

I have following boards - :
1. Beagle bone black
2. STM32 discovery board
3. TI's MSP432

Any type of suggestion and help would be much appreciated.

Regards,
Abhinav


Re: RFC: ieee802154 radio api

Tomasz Bursztyka
 

Hi Johann,


int (*set_rf_test_mode)(struct device *dev, uint32_t mode),
What's the use case for it?
It would be turned off by default (return -ENOTSUPP). It is useful for
commissioning the hardware and is required for the test during the CE
or FCC certification. Of course, there are tools from the
manufacturers for it, but they are usually not so nice and they are
almost always bound to an OS, which I do not want to use. Natively
implemented, it is also useful in driver development, e.g. to check
whether PLL was set correctly after the channel was switched or to
test CCA :-). Mostly only four modes are useful: Idle, continues RX,
carrier wave, PRBS9. It must be clearly marked that it is only for
testing.
Isn't this kind of test made out of any 15.4 network? (i.e.: does it
require L2? I don't think so).
No, it just for the PHY (RF Testing, simular to BT DTM, e.g.
DTM_PKT_PRBS9 or CARRIER_TEST ...). It would also needs a shell command.
Ok sound like it could use the actual RAW use of the driver.

So you would need 2 function:

- one returning the supported modes

- one running the test with requested mode as you proposed.

this would be exposed only on Kconfig option condition.


Br

Tomasz


Re: [RFC] STM32 pinmux - simplify pinmux logic

Christer Weinigel
 

Hi Erwan,

On 2017-01-17 13:38, Erwan Gouriou wrote:
I agree with the observation that gpio/pinmux configuration is
overcomplicated.
Your proposal is interesting and look rather easy to use.
Maybe you can also have a look to Adam's porting of STM32F3x family, in
which
he's trying to by pass pin configuration this in another way:
https://gerrit.zephyrproject.org/r/#/c/9701
It looks quite similar, if I understood this correctly, he's also added
some macros to combine the pull up/pull down/function with the alternate
function in one word:

https://gerrit.zephyrproject.org/r/#/c/9325/19/drivers/pinmux/stm32/pinmux_stm32.h

Although I think it's nicer to do what I did and put the pin information
in drivers/pinmux/stm32/pinmux_stm32f4.h since it puts everything in one
file.

Other than that it looks like a nice patchset to add support for the
STM32F3xx family.

After thinking a bit more about this, I'm actually not too fond of magic
macros like my STM32F4_PINMUX_ENCODE. Sometimes abstractions can be
nice, but in this case I actually thinks that it obscures more than it
helps. I would actually prefer to change the defines to have the a
shift built in, that is change the stm32f4x_pin_config_mode enum to defines:

#define STM32F4X_PIN_CONFIG_AF_PUSH_MASK (15 << 8)
#define STM32F4X_PIN_CONFIG_AF_PUSH_PULL (0 << 8)
#define STM32F4X_PIN_CONFIG_AF_PUSH_UP (1 << 8)
#define STM32F4X_PIN_CONFIG_AF_PUSH_DOWN (2 << 8)
...
STM32F4X_PIN_CONFIG_ANALOG (15 << 8)

so that the defines in pinmux_stm32.h can be a bit more explicit not
have to use the STM32F4_PINMUX_ENCODE macro:

#define STM32F4_PINMUX_FUNC_PA9_USART1_TX
(STM32F4X_PIN_CONFIG_AF_PUSH_UP | STM32_PINMUX_FUNC_ALT_7)

this also allows more flexibility, we're no longer limited to just two
axes of parameters. For example AF_PUSH_UP actually combines three
different settings. We can split that into MODE_AF, PULL_UP and
OTYPE_PUSH_PULL:

#define STM32F4X_PIN_MODE_MASK (3 << 8)
#define STM32F4X_PIN_MODE_INPUT (0 << 8)
#define STM32F4X_PIN_MODE_OUTPUT (1 << 8)
#define STM32F4X_PIN_MODE_AF (2 << 8)
#define STM32F4X_PIN_MODE_ANALOG (3 << 8)

#define STM32F4X_PIN_PULL_MASK (3 << 10)
#define STM32F4X_PIN_PULL_NONE (0 << 10)
#define STM32F4X_PIN_PULL_UP (1 << 10)
#define STM32F4X_PIN_PULL_DOWN (2 << 10)

#define STM32F4X_PIN_OTYPE_MASK (1 << 12)
#define STM32F4X_PIN_OTYPE_PUSH_PULL (0 << 12)
#define STM32F4X_PIN_OTYPE_OPEN_DRAIN (1 << 12)

and for completeness we could also expose the speed settings:

#define STM32F4X_PIN_SPEED_MASK (3 << 13)
#define STM32F4X_PIN_SPEED_LOW (0 << 13)
#define STM32F4X_PIN_SPEED_MEDIUM (1 << 13)
#define STM32F4X_PIN_SPEED_FAST (2 << 13)
#define STM32F4X_PIN_SPEED_HIGH (3 << 13)

The above pin definition would look like this:

#define STM32F4_PINMUX_FUNC_PA9_USART1_TX (STM32F4X_PIN_FUNC_AF |
STM32F4X_PIN_PULL_UP | STM32_PINMUX_FUNC_ALT_7)

It's a bit more verbose, but it's obvious what it does, especially if
you look at the corresponding definitions in the data sheet since this
is how the hardware registers look.

If we do this we can rip out stm32_get_pin_config completely and also
simplify the __func_to_foo functions in soc_gpio.c

It might also be a good idea to unify these defines between STM32
families. If I recall correctly many STM32F1xx, STM32F2xx and STMF4xx
packages are mostly pin compatible. The same PCB could have a STM32Fxx
or STM32F4xx MCU mounted on it (with a zero ohm resistor or capacitor to
account for any differences between them) and it would be nice if they
could use the same board file.

Some functions might not be supported on all families, for example, I
don't think the STM32F1xx can have a pull-up/pull-down at the same tie
as a pin is an output or alternate function, but that shouldn't be problem.

Btw, I think that you could submit your RFC as a patch in Gerrit, so we can
better appreciate the differences and comment easily.
I'll see if I can clean up my ideas and push a few patches for review in
gerrit.

/Christer


Re: RFC: ieee802154 radio api

Johann Fischer
 

Hi Tomasz,

int (*set_rf_test_mode)(struct device *dev, uint32_t mode),
What's the use case for it?
It would be turned off by default (return -ENOTSUPP). It is useful for
commissioning the hardware and is required for the test during the CE
or FCC certification. Of course, there are tools from the
manufacturers for it, but they are usually not so nice and they are
almost always bound to an OS, which I do not want to use. Natively
implemented, it is also useful in driver development, e.g. to check
whether PLL was set correctly after the channel was switched or to
test CCA :-). Mostly only four modes are useful: Idle, continues RX,
carrier wave, PRBS9. It must be clearly marked that it is only for
testing.
Isn't this kind of test made out of any 15.4 network? (i.e.: does it
require L2? I don't think so).
No, it just for the PHY (RF Testing, simular to BT DTM, e.g.
DTM_PKT_PRBS9 or CARRIER_TEST ...). It would also needs a shell command.

--
Best Regards,
Johann Fischer


Re: RFC: ieee802154 radio api

Tomasz Bursztyka
 

Hi Oliver,

On Wed, Jan 18, 2017 at 09:57:15AM +0100, Tomasz Bursztyka wrote:
For example, if the hardware can automatically perform CCA before the TX
sequence (IEEE802154_HW_LBT is set), the linklayer does not have to call
the API function int (*cca)(struct device *dev);
No. L2 has to call that, unless hw can perform part or all of the radio
strategy (usually, CSMA).
Doing cca before tx on hw side is just to ensure that it won't generate
noise uselessly. (and fails its transmission as well as
creating jitters on the network). That has to be enabled all the time, it's
cost-less.
<snip>
- IEEE802154_HW_LBT (listen before transmit or CCA before TX)
Always enable it if the hw supports it, at built time.
Not sure, I understand you correctly here, but some transceivers (e.g. the
at86rf2xx) does not allow you to perform manual CCA if automatic CCA is
enabled.
Good to know. Does it behave like that because it can do some/all of the
CSMA job directly?
For now I'd say disable auto-CCA in driver by default, then.

Basically manual CCA is meant for the fully soft-CSMA radio strategy,
as it is right now.
If only auto-cca does not mess up with the manual one, then keep it enabled.

But soon, we'll have to figure out a way to hand-over CSMA parts to
relevant hw that can
do it.


- IEEE802154_HW_FRAME_RETRIES
Up to the driver to handle it. L2 does not have to care about it.
What if the MAC needs full control over L2 retransmissions (e.g. in a TDMA
MAC).
Hum, MAC and L2 in our case is the same. What I call L2 here is
ieee802.15.4 soft-MAC L2 stack.
See subsys/net/ip/l2/ieee802154/

Anyway, TDMA is not part of IEEE 802.15.4 <= 2011, so we can put it aside.


In addition, I would insert following flags:
- IEEE802154_HW_TX_AUTOACK (can transmit ACK frame after RX)
Always enable it if the hw supports it.
Same as above. For some MAC protocols (e.g. IEEE 802.15.4 TSCH mode) this is
not a viable solution.
TSCH is for IEEE 802.15.4 >= 2012. So at this point we can put it aside.

Or is your point only about setting these capabilities at runtime? Is it still
possible to disable these flags at compile time?
We had autoack, and crc and all being disabled at compile time for a
while. But at this stage
it was just useless, so it got removed.


Br,

Tomasz


Re: RFC: ieee802154 radio api

Oliver Hahm <oliver.hahm@...>
 

Hi Tomasz!

On Wed, Jan 18, 2017 at 09:57:15AM +0100, Tomasz Bursztyka wrote:
For example, if the hardware can automatically perform CCA before the TX
sequence (IEEE802154_HW_LBT is set), the linklayer does not have to call
the API function int (*cca)(struct device *dev);
No. L2 has to call that, unless hw can perform part or all of the radio
strategy (usually, CSMA).
Doing cca before tx on hw side is just to ensure that it won't generate
noise uselessly. (and fails its transmission as well as
creating jitters on the network). That has to be enabled all the time, it's
cost-less.
<snip>
- IEEE802154_HW_LBT (listen before transmit or CCA before TX)
Always enable it if the hw supports it, at built time.
Not sure, I understand you correctly here, but some transceivers (e.g. the
at86rf2xx) does not allow you to perform manual CCA if automatic CCA is
enabled.

- IEEE802154_HW_FRAME_RETRIES
Up to the driver to handle it. L2 does not have to care about it.
What if the MAC needs full control over L2 retransmissions (e.g. in a TDMA
MAC).

In addition, I would insert following flags:
- IEEE802154_HW_TX_AUTOACK (can transmit ACK frame after RX)
Always enable it if the hw supports it.
Same as above. For some MAC protocols (e.g. IEEE 802.15.4 TSCH mode) this is
not a viable solution.

Or is your point only about setting these capabilities at runtime? Is it still
possible to disable these flags at compile time?

Cheers,
Oleg


Re: RFC: ieee802154 radio api

Tomasz Bursztyka
 

Hi Johann,


The Flags for the Hardware Capabilities:
(The same identifiers as in Linux kernel)
- IEEE802154_HW_TX_OMIT_CKSUM
Is there any hw which is unable to do the chksum?
I made a patch on my local tree, to support software chksum on tx, and
rx. But as long as
there is no hw supporting it: I won't post it.
ok I agree. What bothers me is the IEEE802154_MTU of 127, the frame
length is 127 octets (including FCS field), should it not be 125?
It's a left-over. Just keep it that way. Drivers are setting the MTU to
125 mostly due to net buf. (it's possible to reserve header part, not
tail part, and that was generating issuse)
Up to the driver to not write the fcs into buffer's data. (L2 does not
care about it anyway).
And anyway driver don't push bigger frames than what they are supposed
to, so the check in frame is really superfluous.




int (*set_cca_mode)(struct device *dev, ...),

int (*set_cca_threshold)(struct device *dev, int32_t level),
Not convinced to expose these 2.
It makes a difference what CCA mode the HW uses. It should be
prescribed somewhere or the L2 sets it to runtime.
For the threshold, the default value of the PHY may be ok.


int (*set_promiscuous_mode)(struct device *dev, bool on),
Ok on that one. But it should be built time set feature.
You mean the timestamps should be inserted by the driver?
No I mean the promiscuous feature should be Kconfig set, and disabled by
default.


int (*set_rf_test_mode)(struct device *dev, uint32_t mode),
What's the use case for it?
It would be turned off by default (return -ENOTSUPP). It is useful for
commissioning the hardware and is required for the test during the CE
or FCC certification. Of course, there are tools from the
manufacturers for it, but they are usually not so nice and they are
almost always bound to an OS, which I do not want to use. Natively
implemented, it is also useful in driver development, e.g. to check
whether PLL was set correctly after the channel was switched or to
test CCA :-). Mostly only four modes are useful: Idle, continues RX,
carrier wave, PRBS9. It must be clearly marked that it is only for
testing.
Isn't this kind of test made out of any 15.4 network? (i.e.: does it
require L2? I don't think so).


Br,

Tomasz


Re: RFC: ieee802154 radio api

Johann Fischer
 

Hi Tomasz,

For example, if the hardware can automatically perform CCA before the
TX sequence (IEEE802154_HW_LBT is set), the linklayer does not have to
call the API function int (*cca)(struct device *dev);
No. L2 has to call that, unless hw can perform part or all of the radio
strategy (usually, CSMA).
Doing cca before tx on hw side is just to ensure that it won't generate
noise uselessly. (and fails its transmission as well as
creating jitters on the network). That has to be enabled all the time,
it's cost-less.
Ok, then I will implement the cca function, which then execute a
standalone CCA.


The Flags for the Hardware Capabilities:
(The same identifiers as in Linux kernel)
- IEEE802154_HW_TX_OMIT_CKSUM
Is there any hw which is unable to do the chksum?
I made a patch on my local tree, to support software chksum on tx, and
rx. But as long as
there is no hw supporting it: I won't post it.
ok I agree. What bothers me is the IEEE802154_MTU of 127, the frame
length is 127 octets (including FCS field), should it not be 125?


- IEEE802154_HW_LBT (listen before transmit or CCA before TX)
Always enable it if the hw supports it, at built time.
> ...

ok



int (*set_cca_mode)(struct device *dev, ...),

int (*set_cca_threshold)(struct device *dev, int32_t level),
Not convinced to expose these 2.
It makes a difference what CCA mode the HW uses. It should be prescribed
somewhere or the L2 sets it to runtime.
For the threshold, the default value of the PHY may be ok.


int (*set_promiscuous_mode)(struct device *dev, bool on),
Ok on that one. But it should be built time set feature.
You mean the timestamps should be inserted by the driver?


int (*set_hw_addr_filt)(struct device *dev, ...),
That one we are missing yes. So it could be used once neighbors are
detected etc...
But it means improving nbr management also. It's really not the biggest
feature missing
right now.
ok


int (*set_rf_test_mode)(struct device *dev, uint32_t mode),
What's the use case for it?
It would be turned off by default (return -ENOTSUPP). It is useful for
commissioning the hardware and is required for the test during the CE or
FCC certification. Of course, there are tools from the manufacturers for
it, but they are usually not so nice and they are almost always bound to
an OS, which I do not want to use. Natively implemented, it is also
useful in driver development, e.g. to check whether PLL was set
correctly after the channel was switched or to test CCA :-). Mostly only
four modes are useful: Idle, continues RX, carrier wave, PRBS9. It must
be clearly marked that it is only for testing.


For now I don't see much point for exposing capabilities, besides maybe
the autoack one but I want
a real hw example that does not support it first. (pushing awai the
newer specs for now).

Point is, all drivers are exposing the same API. For instance, if it
does not support promiscuous mode, then
it sets the relevant api function pointer to NULL. If the user asks "set
promiscuous" (let's say through the 15.4 shell),
l2 verify that and return -ENOTSUPP accordingly. No need of any flag here.
Same for hw filtering etc etc... There is no need of checking any flag
at anytime.
ok, got it :-)

Br,

Tomasz
--
Best Regards,
Johann Fischer


Daily JIRA Digest

donotreply@...
 

NEW JIRA items within last 24 hours: 2
[ZEP-1588] I2C doesn't work on Arduino 101
https://jira.zephyrproject.org/browse/ZEP-1588

[ZEP-1586] menuconfig: Backspace is broken
https://jira.zephyrproject.org/browse/ZEP-1586


UPDATED JIRA items within last 24 hours: 18
[ZEP-819] 6LowPAN-GHC: Generic Header Compression for IPv6
https://jira.zephyrproject.org/browse/ZEP-819

[ZEP-1103] Propose and implement synchronization flow for multicore power management
https://jira.zephyrproject.org/browse/ZEP-1103

[ZEP-1457] Add SPDX Tags to Zephyr licence boilerplate
https://jira.zephyrproject.org/browse/ZEP-1457

[ZEP-1321] Glossary of Terms needs updating
https://jira.zephyrproject.org/browse/ZEP-1321

[ZEP-878] 6LoWPAN - Unicast-Prefix based IPv6 Multicast (dst) address compression
https://jira.zephyrproject.org/browse/ZEP-878

[ZEP-1558] Support of user private data pointer in Timer expiry function
https://jira.zephyrproject.org/browse/ZEP-1558

[ZEP-513] extern declarations of small microkernel objects in designated sections require __attribute__((section)) in gp-enabled systems
https://jira.zephyrproject.org/browse/ZEP-513

[ZEP-1561] Implement _tsc_read for NiosII
https://jira.zephyrproject.org/browse/ZEP-1561

[ZEP-802] DNS Configuration Options for DHCPv6
https://jira.zephyrproject.org/browse/ZEP-802

[ZEP-1532] Wrong accelerometer readings
https://jira.zephyrproject.org/browse/ZEP-1532

[ZEP-1579] external links to zephyr technical docs are broken
https://jira.zephyrproject.org/browse/ZEP-1579

[ZEP-1566] WDT: Interrupt is triggered multiple times @ARC
https://jira.zephyrproject.org/browse/ZEP-1566

[ZEP-1585] "legacy.h" should be disabled in "kernel.h" with CONFIG_LEGACY_KERNEL=n
https://jira.zephyrproject.org/browse/ZEP-1585

[ZEP-1358] BMI160 accelerometer gives 0 on all axes
https://jira.zephyrproject.org/browse/ZEP-1358

[ZEP-1587] sensor.h still uses legacy APIs and structs
https://jira.zephyrproject.org/browse/ZEP-1587

[ZEP-1583] ARC: warning: unmet direct dependencies (SOC_RISCV32_PULPINO || SOC_RISCV32_QEMU)
https://jira.zephyrproject.org/browse/ZEP-1583

[ZEP-1548] Python script invocation is inconsistent
https://jira.zephyrproject.org/browse/ZEP-1548

[ZEP-1064] Fix wiki section coding standards/include paths
https://jira.zephyrproject.org/browse/ZEP-1064


CLOSED JIRA items within last 24 hours: 11
[ZEP-801] (Fixed) DNS Extensions to support IPv6
https://jira.zephyrproject.org/browse/ZEP-801

[ZEP-1208] (Fixed) Create test for Timer kernel object using native unified kernel API
https://jira.zephyrproject.org/browse/ZEP-1208

[ZEP-964] (Fixed) Add a (hidden?) Kconfig option for disabling legacy API
https://jira.zephyrproject.org/browse/ZEP-964

[ZEP-630] (Won't Do) Features support matrix for supported boards
https://jira.zephyrproject.org/browse/ZEP-630

[ZEP-1497] (Fixed) Cortex-M0 port exception and interrupt priority setting and getting is broken
https://jira.zephyrproject.org/browse/ZEP-1497

[ZEP-1512] (Fixed) doc-theme has its own conf.py
https://jira.zephyrproject.org/browse/ZEP-1512

[ZEP-872] (Fixed) Unable to flash Zephyr on Arduino 101 using Ubuntu and following wiki instructions
https://jira.zephyrproject.org/browse/ZEP-872

[ZEP-1370] (Fixed) There's a wiki page for arduino_due but no zephyr/boards support folder
https://jira.zephyrproject.org/browse/ZEP-1370

[ZEP-1363] (Done) Missing wiki board support page for arm/arduino_101_ble
https://jira.zephyrproject.org/browse/ZEP-1363

[ZEP-1443] (Fixed) Samples/net/zperf: Build fail as net_private.h can not be founld
https://jira.zephyrproject.org/browse/ZEP-1443

[ZEP-1575] (Won't Do) Getting warning messages due to Macro SYS_LOG_DOMAIN defined in bmi160.h file
https://jira.zephyrproject.org/browse/ZEP-1575


RESOLVED JIRA items within last 24 hours: 0


Daily Gerrit Digest

donotreply@...
 

NEW within last 24 hours:
- https://gerrit.zephyrproject.org/r/10168 : net: shell: Use lighter printk() instead of printf()
- https://gerrit.zephyrproject.org/r/10169 : Bluetooth: Don't select TinyCrypt RNG for combined builds
- https://gerrit.zephyrproject.org/r/10132 : samples/zoap_server: Also listen on the unicast address
- https://gerrit.zephyrproject.org/r/10122 : net: tcp: remove unused semaphore tcp_lock
- https://gerrit.zephyrproject.org/r/10150 : net: ipv6: Fix IPv6 prefix comparision
- https://gerrit.zephyrproject.org/r/10152 : net: 6lo: Handle destination address uncompression properly
- https://gerrit.zephyrproject.org/r/10154 : net: dhcpv4: Remove dead code
- https://gerrit.zephyrproject.org/r/10153 : net: 6lo: Fix dereferencing null pointer
- https://gerrit.zephyrproject.org/r/10151 : net: nbuf: Check possible null pointer access
- https://gerrit.zephyrproject.org/r/10149 : net: ipv6: Check neighbor pointer in NS reply timeout
- https://gerrit.zephyrproject.org/r/10148 : net: tcp: Allocate space for TCP header
- https://gerrit.zephyrproject.org/r/10147 : net: icmpv6: Removing dead code
- https://gerrit.zephyrproject.org/r/10146 : net: Fix possible null pointer dereference in nbuf
- https://gerrit.zephyrproject.org/r/10140 : tests/gpio: enable gpio cases to run on more platforms
- https://gerrit.zephyrproject.org/r/10139 : arm/nordic_nrf5: enable SOC_FLASH_NRF5 by default if FLASH is enabled
- https://gerrit.zephyrproject.org/r/10144 : net: tcp: add timeout wait in net_context_connect
- https://gerrit.zephyrproject.org/r/10142 : net: tcp: fix buffer leak in tcp_synack_received
- https://gerrit.zephyrproject.org/r/10143 : boards/pinmux: fix typo
- https://gerrit.zephyrproject.org/r/10141 : tests: fix invoke k_timer_stop issue inside timeout expiry_fn
- https://gerrit.zephyrproject.org/r/10138 : arm: set default vector table address in prep_c when XIP
- https://gerrit.zephyrproject.org/r/10136 : drivers: QMSI RTC: simplify driver reentrancy code using IS_ENABLED
- https://gerrit.zephyrproject.org/r/10135 : drivers: QMSI SOC flash: simplify driver reentrancy code using IS_ENABLED
- https://gerrit.zephyrproject.org/r/10134 : drivers: QMSI PWM: simplify driver reentrancy code using IS_ENABLED macro
- https://gerrit.zephyrproject.org/r/10120 : sanitycheck: improve terse output
- https://gerrit.zephyrproject.org/r/10125 : build: remove obsolete sections from linker scripts
- https://gerrit.zephyrproject.org/r/10117 : doc: move context back to doc/, fix broken links

UPDATED within last 24 hours:
- https://gerrit.zephyrproject.org/r/9874 : arm: cmsis: Convert enable_floating_point to use CMSIS
- https://gerrit.zephyrproject.org/r/9973 : Bluetooth: Controller: Use CMSIS NVIC APIs directly
- https://gerrit.zephyrproject.org/r/10093 : net/samples: HTTP server sample application
- https://gerrit.zephyrproject.org/r/10111 : Bluetooth: L2CAP: Fix always using RX_BUF_COUNT as initial credits
- https://gerrit.zephyrproject.org/r/9925 : arm: cmsis: Port nvic to CMSIS
- https://gerrit.zephyrproject.org/r/10106 : samples: net: Add DHCPv4 sample application README file
- https://gerrit.zephyrproject.org/r/9373 : Bluetooth: AVDTP: Add AVDTP Discover API Prototype
- https://gerrit.zephyrproject.org/r/9460 : Bluetooth: AVDTP: Add AVDTP Discover Function Definition
- https://gerrit.zephyrproject.org/r/9807 : drivers: ieee802154: add MCR20A driver
- https://gerrit.zephyrproject.org/r/5504 : dma: Introduce STM32F4x DMA driver
- https://gerrit.zephyrproject.org/r/10077 : net: buf: introduce NET_BUF_ALIGNMENT macro
- https://gerrit.zephyrproject.org/r/10091 : net/mqtt: Add the testcase.ini file to the MQTT Publisher sample app
- https://gerrit.zephyrproject.org/r/10075 : net/mqtt: Add the MQTT Publisher sample application
- https://gerrit.zephyrproject.org/r/10074 : net/mqtt: Add the "malformed" callback to the MQTT ctx structure
- https://gerrit.zephyrproject.org/r/10072 : net/mqtt: Move upwards buffer size validation
- https://gerrit.zephyrproject.org/r/10073 : net/mqtt: Simplify the MQTT high-level API
- https://gerrit.zephyrproject.org/r/9638 : Bluetooth: HFP HF: Handle +CIEV reponse
- https://gerrit.zephyrproject.org/r/9637 : Bluetooth: AT: HFP HF: Handle unsolicited reponse
- https://gerrit.zephyrproject.org/r/6716 : Bluetooth: SDP: Server: Refactor data element structure header
- https://gerrit.zephyrproject.org/r/9692 : doc: Include main Network APIs doxygen documentation
- https://gerrit.zephyrproject.org/r/9331 : Bluetooth: A2DP: Adds accept state callback handlers
- https://gerrit.zephyrproject.org/r/7492 : Bluetooth: A2DP: Added Preset Structure
- https://gerrit.zephyrproject.org/r/6720 : Bluetooth: A2DP: Stream End Point Registration
- https://gerrit.zephyrproject.org/r/9964 : Xtensa port: Added board config files for Xtensa simulator paltform
- https://gerrit.zephyrproject.org/r/9974 : Xtensa port: Added support for XCC, the Cadence Systems Inc compiler
- https://gerrit.zephyrproject.org/r/9982 : drivers: spi: enable gpio driver automatically when needed
- https://gerrit.zephyrproject.org/r/9827 : pinmux/nucleo_l476rg: Define pinmuxing for SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/9950 : net: tcp: handle TCP_FIN after processing any data in the buffer
- https://gerrit.zephyrproject.org/r/9896 : cc3200: Added board documentation in RST format.
- https://gerrit.zephyrproject.org/r/9516 : drivers: Add Atmel SAM family GMAC Ethernet driver
- https://gerrit.zephyrproject.org/r/9933 : tests: benchmark: sys_kernel: Porting to unified
- https://gerrit.zephyrproject.org/r/9680 : quark_se: Fix restore info address
- https://gerrit.zephyrproject.org/r/9980 : tests: include: Move timestamp.h into common location
- https://gerrit.zephyrproject.org/r/9681 : quark_se: Add shared GDT in RAM memory to linker
- https://gerrit.zephyrproject.org/r/9979 : kernel: sysclock: Add an API to get tick delta
- https://gerrit.zephyrproject.org/r/9356 : quark_se: PM: Add multicore support
- https://gerrit.zephyrproject.org/r/9682 : quark_d2000: Add shared GDT memory to linker
- https://gerrit.zephyrproject.org/r/9709 : Bluetooth: SDP: Add API to extract Attribute Value
- https://gerrit.zephyrproject.org/r/9710 : Bluetooth: shell: Add SDP client support
- https://gerrit.zephyrproject.org/r/8803 : benchmarks: boot_time: Move to unified kernel
- https://gerrit.zephyrproject.org/r/9711 : Bluetooth: SDP: Get ProtocolDescriptorList attrbute internals
- https://gerrit.zephyrproject.org/r/9714 : Bluetooth: shell: Add getting ProfileDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9715 : Bluetooth: SDP: Add API to get SupportedFeature attribute
- https://gerrit.zephyrproject.org/r/9712 : Bluetooth: shell: Add getting ProtocolDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9713 : Bluetooth: SDP: Add API to get ProfileDescriptorList attribute
- https://gerrit.zephyrproject.org/r/9717 : Bluetooth: SDP: Add getting A2SRC in BTshell
- https://gerrit.zephyrproject.org/r/9716 : Bluetooth: SDP: Use SupportedFeature attr API in BTshell
- https://gerrit.zephyrproject.org/r/9894 : net: ipv6: fix link address handling in handle_ns_neighbor
- https://gerrit.zephyrproject.org/r/9951 : net: tcp: don't assume TCP_FIN buffers are NET_DROP
- https://gerrit.zephyrproject.org/r/9948 : net: tcp: in tcp_establish save TCP flags for post-processing use
- https://gerrit.zephyrproject.org/r/9952 : net: tcp: if buffer is TCP_FIN increment send_ack by 1
- https://gerrit.zephyrproject.org/r/9363 : arch: nrf5: Add option for enabling internal DCDC
- https://gerrit.zephyrproject.org/r/9762 : RFC: CI: rearchitect with a framework that orchestrates running
- https://gerrit.zephyrproject.org/r/9110 : test message: please ignore
- https://gerrit.zephyrproject.org/r/9975 : net: tcp: Make the connect callback on success, not transmission

MERGED within last 24 hours:
- https://gerrit.zephyrproject.org/r/10124 : Makefile: Streamline building of CoAP-related projects.
- https://gerrit.zephyrproject.org/r/10131 : net: tcp: When retransmitting, hold an extra, temporary reference
- https://gerrit.zephyrproject.org/r/10119 : Bluetooth: SMP: Take advantage of IS_ENABLED whenever possible
- https://gerrit.zephyrproject.org/r/10116 : Bluetooth: L2CAP: Take advantage of IS_ENABLED whenever possible
- https://gerrit.zephyrproject.org/r/10115 : Bluetooth: conn: Take advantage of IS_ENABLED whenever possible
- https://gerrit.zephyrproject.org/r/10145 : Bluetooth: drivers/nble: Remove bogus BT_DBG manipulation
- https://gerrit.zephyrproject.org/r/10126 : echo_server: Remove unnecessary config from prf_frdm_k64f.conf
- https://gerrit.zephyrproject.org/r/10121 : Install pre-release SDK 0.9 on minions
- https://gerrit.zephyrproject.org/r/10118 : branch: add 'core' branch to verify jobs
- https://gerrit.zephyrproject.org/r/9858 : Bluetooth: samples/beacon: Print message at start of sample
- https://gerrit.zephyrproject.org/r/9859 : Bluetooth: Kconfig: Specify stack size for Bluetooth SPI
- https://gerrit.zephyrproject.org/r/9857 : Bluetooth: Add HCI SPI driver
- https://gerrit.zephyrproject.org/r/9937 : net: tcp: Get rid of `recv_mss` field from TCP struct
- https://gerrit.zephyrproject.org/r/9944 : net: tcp: Reduce size of `state` member from 32 to 4 bits
- https://gerrit.zephyrproject.org/r/9446 : Bluetooth: AVDTP: Added params to AVDTP Request structure
- https://gerrit.zephyrproject.org/r/9653 : net: slip: Do not remove fragments when sending data
- https://gerrit.zephyrproject.org/r/9929 : net: tcp: Ensure all timers are disposed of when releasing context
- https://gerrit.zephyrproject.org/r/9930 : net: tcp: Use an uint8_t for retry timeout instead of an uin32_t
- https://gerrit.zephyrproject.org/r/9936 : net: tcp: Remove unused `recv_ack` field from TCP context
- https://gerrit.zephyrproject.org/r/10110 : Bluetooth: L2CAP: Make sure state is correctly updated
- https://gerrit.zephyrproject.org/r/9905 : pinmux/nucleo_l476rg: Define pinmuxing for SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/10105 : samples: net: Fix DHCPv4 config options and run on its own thread
- https://gerrit.zephyrproject.org/r/9904 : pinmux/stm32l4: Add support for STM32L SPI1 and SPI3
- https://gerrit.zephyrproject.org/r/10104 : Bluetooth: hci_core: Take advantage of IS_ENABLED whenever possible
- https://gerrit.zephyrproject.org/r/10095 : Bluetooth: Add __printf_like annotation for bt_log
- https://gerrit.zephyrproject.org/r/10094 : Bluetooth: Take advantage of IS_ENABLED macro for BT_DBG
- https://gerrit.zephyrproject.org/r/9996 : doc: move context back to doc/, fix broken links
- https://gerrit.zephyrproject.org/r/9703 : boards: prepare for integration of board documentation
- https://gerrit.zephyrproject.org/r/9960 : Xtensa port: Started port to for Xtensa cores family.
- https://gerrit.zephyrproject.org/r/8961 : drivers: QMSI AON counter: Simplify driver reentrancy code
- https://gerrit.zephyrproject.org/r/10099 : tests: do not use RC_OK, use 0 instead
- https://gerrit.zephyrproject.org/r/10108 : kernel: use __ticks_to_ms directly
- https://gerrit.zephyrproject.org/r/10101 : kernel: make legacy calls depends on CONFIG_LEGACY_KERNEL
- https://gerrit.zephyrproject.org/r/10100 : kernel: build legacy timer only conditionally
- https://gerrit.zephyrproject.org/r/10103 : kernel: include limits.h for UINT_MAX
- https://gerrit.zephyrproject.org/r/10102 : kernel: mailbox: legacy calls depend on CONFIG_LEGACY_KERNEL
- https://gerrit.zephyrproject.org/r/10097 : legacy: Move TICKS_UNLIMITED -> K_FOREVER
- https://gerrit.zephyrproject.org/r/10112 : tests: footprint: set ARCH correctly and provide defaults
- https://gerrit.zephyrproject.org/r/10113 : samples: legacy: enable legacy kernel
- https://gerrit.zephyrproject.org/r/10096 : legacy: use k_cycle_get_32 instead of legacy sys_cycle_get_32
- https://gerrit.zephyrproject.org/r/10114 : sensor: remove unused legacy macros
- https://gerrit.zephyrproject.org/r/10098 : net: zoap_client: fix usage of legacy APIs
- https://gerrit.zephyrproject.org/r/10107 : kernel: including legacy.h depends on CONFIG_LEGACY_KERNEL
- https://gerrit.zephyrproject.org/r/10109 : Bluetooth: IPSP: Reuse buffer fragments instead of copying
- https://gerrit.zephyrproject.org/r/10088 : riscv32: fix KConfig selection of ATOMIC_OPERATIONS_C


Re: [RFC]DMA API Update

Jon Medhurst (Tixy) <tixy@...>
 

On Wed, 2017-01-18 at 01:14 +0000, Liu, Baohong wrote:
-----Original Message-----
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
[...]
?

The SPI subsystem interface doesn't have anything DMA related in it, so I can
only assume that DMA use will have to be hidden inside the SPI driver, and
for each spi_transceive request made made of it will setup and operate on
an appropriate struct dma_transfer_config? (Or use scatter-gather lists when
API's get that ;-)

If so, every device driver in zephyr that anyone wants to use with DMA will
need to add DMA support to it and make it configurable to
(optionally) use the generic DMA API. Or is it expected that all APIs like SPI
grow new functions for use with DMA specifically?

That still leaves the question as to who calls dma_channel_config and how
the parameters for that get into the system. Is each driver that implements
DMA support going to have a bunch of KConfig entries to dma_slot,
hankshake_polarity etc? Or will the SoC have a bunch of #defines (like we
currently have for IRQ numbers) for setting these DMA attributes (assuming
they are fixed in hardware).

There's also the question as to how channel numbers are allocated. Is this
more per-driver KConfig options or should we have a DMA channel allocator
function so they can just be assigned at runtime?
What you said is the scenario of driver over driver. There are existing examples
In Zephyr.
Where? I can only assume you have in mind the things in
ext/hal/qmsi/drivers which is only occurrence of DMA in the Zephyr tree
I can find. Those drivers look hard coded for use on a single SoC and
have driver specific APIs for DMA, and nothing in-tree uses those APIs.

Also, there is no app in-tree that actually uses DMA apart from
test_loop_transfer which just does a simple memory-to-memory DMA test.

If the idea is that people should follow the Quark example, then it
looks to me that your saying DMA support in drivers is something
everyone has to design for themselves on a per-driver basis? If so,
there'll be no API consistency between drivers and every app will be
hard coded to a particular set of drivers.

But I can't believe that is what is intended, so I must have mis-
understood something fundamental.

--
Tixy


Re: RFC: ieee802154 radio api

Tomasz Bursztyka
 

Hi Johann,

The transceivers can have different capabilities (csma, autoack ...).
During the initialization of the driver, the appropriate flags should
be set by the driver. During the initializing of the subsystem, the
flags must be checked and enabled according to the desired behavior.
L2 behavior can avoid using any flags, at least for now (see below).
There is no reason to copy the way it's done elsewhere.
Moreover from Linux which really does not have the same constraints as
Zephyr.
Not to say about the design obviously.

That said, current L2 does lack of some features below.


For example, if the hardware can automatically perform CCA before the
TX sequence (IEEE802154_HW_LBT is set), the linklayer does not have to
call the API function int (*cca)(struct device *dev);
No. L2 has to call that, unless hw can perform part or all of the radio
strategy (usually, CSMA).
Doing cca before tx on hw side is just to ensure that it won't generate
noise uselessly. (and fails its transmission as well as
creating jitters on the network). That has to be enabled all the time,
it's cost-less.


The Flags for the Hardware Capabilities:
(The same identifiers as in Linux kernel)
- IEEE802154_HW_TX_OMIT_CKSUM
Is there any hw which is unable to do the chksum?
I made a patch on my local tree, to support software chksum on tx, and
rx. But as long as
there is no hw supporting it: I won't post it.

- IEEE802154_HW_LBT (listen before transmit or CCA before TX)
Always enable it if the hw supports it, at built time.

- IEEE802154_HW_CSMA_PARAMS
That's when the hw support csma strategy on its own. Afaik, we don't
have any yet.

- IEEE802154_HW_FRAME_RETRIES
Up to the driver to handle it. L2 does not have to care about it.

- IEEE802154_HW_AFILT
About hw filtering I guess?

- IEEE802154_HW_PROMISCUOUS
See below, at the end of this mail.

- IEEE802154_HW_RX_OMIT_CKSUM
- IEEE802154_HW_RX_DROP_BAD_CKSUM
Same as above about chksum on tx.
Is there any hw that cannot do cksum by itself and thus drop relevant
frames?
If not, then we can forget about it.


In addition, I would insert following flags:
- IEEE802154_HW_TX_AUTOACK (can transmit ACK frame after RX)
Always enable it if the hw supports it.

That said, if the hw does not support it, one will want the L2 to handle it.
It is handled currently, enabled at built time. But it does not mix at
all if we have 2 15.4 devices:
one supporting autoack, not the other.
But then again: is there any hw around that is unable to do such thing?
(At least for 15.4 >= 2012, I guess not many can do. But we are not
there yet)

- IEEE802154_HW_RX_ACKREQ (RX ACK frame is expected after TX)
Already handled. That's part of the radio strategy.

- IEEE802154_RF_TESTMODE (disabled by default, Modes: RX, CW, PRBS9 ...)
- bit field for supported channels ?
For now the hardware are only 2.4Ghz. That will come when other band
will be supported.

Other suggestions and comments are welcome.

What would be the appropriate place for the flags variable, Network
Interface structure?

Then the ieee802154_radio_api could then be extended by the following
operations:
...
int (*set_lbt)(struct device *dev, bool on),
No. If the device can do it, just enable it all the time.
I don't see any point in being able, at runtime, to play with it.


int (*set_csma_params)(struct device *dev, ...),
As long as there is no hw supporting it, no need to add that yet.


int (*set_cca_mode)(struct device *dev, ...),

int (*set_cca_threshold)(struct device *dev, int32_t level),
Not convinced to expose these 2.


int (*set_promiscuous_mode)(struct device *dev, bool on),
Ok on that one. But it should be built time set feature.


int (*set_frame_retries)(struct device *dev, bool on),
driver/hw side, at built time. No need to play with it at runtime.


int (*set_hw_addr_filt)(struct device *dev, ...),
That one we are missing yes. So it could be used once neighbors are
detected etc...
But it means improving nbr management also. It's really not the biggest
feature missing
right now.


int (*set_auto_ack)(struct device *dev, ...),
No, that's set at built time. And imo, there is no point in playing with it.
For now it should be always enabled.
(will see when newer spec will have to be implemented)


int (*set_rf_test_mode)(struct device *dev, uint32_t mode),
What's the use case for it?

...

Is it ok to use the same identifiers as Linux kernel?
As long as it's semantically relevant, and we don't export any code from
linux. Sure.



For now I don't see much point for exposing capabilities, besides maybe
the autoack one but I want
a real hw example that does not support it first. (pushing awai the
newer specs for now).

Point is, all drivers are exposing the same API. For instance, if it
does not support promiscuous mode, then
it sets the relevant api function pointer to NULL. If the user asks "set
promiscuous" (let's say through the 15.4 shell),
l2 verify that and return -ENOTSUPP accordingly. No need of any flag here.
Same for hw filtering etc etc... There is no need of checking any flag
at anytime.

Br,

Tomasz


Re: [RFC]DMA API Update

Liu, Baohong
 

-----Original Message-----
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
Sent: Monday, January 16, 2017 7:16 AM
To: Liu, Baohong <baohong.liu(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] [RFC]DMA API Update

On Sat, 2017-01-14 at 00:31 +0000, Liu, Baohong wrote:
Thanks for the feedback. See my reply inline.
From: Jon Medhurst (Tixy) [mailto:tixy(a)linaro.org]
[...]

But finally, the big elephant in the room is: how are DMA APIs
actually expected to used? And how should the system be configured?
The same way as other device drivers. There will be a driver to
implement the APIs for each SoC. App does the config, and initiate the
transfer by calling the APIs.
As far as I can see there is no documentation or examples in Zephyr that give
a clue as to how DMA can be used with device drivers. So it's very difficult to
review a DMA API without some more explanation on it's expected use.

Let me try some more specific questions...

Say I have a system which has:
A) a driver for a DMA Controller (it implement struct dma_driver_api)
B) a driver for some interface, e.g. SPI
C) an app which wants to talk to a device attached to that interface
e.g. and LCD controller
D) other things

Which of the above will call

- dma_channel_config
- dma_transfer_config
- dma_transfer_start
- dma_transfer_stop
I updated the RFC.
The sequence is dma_channel_config, dma_transfer_start, and then callback.
So simple!

dma_transfer_stop is to abort an existing transfer.

?

The SPI subsystem interface doesn't have anything DMA related in it, so I can
only assume that DMA use will have to be hidden inside the SPI driver, and
for each spi_transceive request made made of it will setup and operate on
an appropriate struct dma_transfer_config? (Or use scatter-gather lists when
API's get that ;-)

If so, every device driver in zephyr that anyone wants to use with DMA will
need to add DMA support to it and make it configurable to
(optionally) use the generic DMA API. Or is it expected that all APIs like SPI
grow new functions for use with DMA specifically?

That still leaves the question as to who calls dma_channel_config and how
the parameters for that get into the system. Is each driver that implements
DMA support going to have a bunch of KConfig entries to dma_slot,
hankshake_polarity etc? Or will the SoC have a bunch of #defines (like we
currently have for IRQ numbers) for setting these DMA attributes (assuming
they are fixed in hardware).

There's also the question as to how channel numbers are allocated. Is this
more per-driver KConfig options or should we have a DMA channel allocator
function so they can just be assigned at runtime?
What you said is the scenario of driver over driver. There are existing examples
In Zephyr.


I'm also thinking about the fact that there are likely to be more devices
capable of DMA than channels available so how about an API to free a
channel? E.g. dma_channel_config claims a channel for use and
dma_channel_free releases for someone else. That way even with static
allocation of channels we have the option of allocating the same channel to
two different devices if we know they can't be active at the same time.
dma_slot is the one to dynamically connect a dma channel to a device. But, the
responsibility to prevent conflict is on user.


--
Tixy

5781 - 5800 of 8046