asterisk users - Nov 2015 - DAHDI driver question for custom card

Hi All,

Not sure if this is the right mailing list since the dahdi-dev seems not really
active, so I'll try here.

I'm developing a new DAHDI driver for a custom board. In this card I've
implemented the reading of
the TDM slots by 2 DMA channels, TX and RX. Each DMA channel has its own
callback that
decompose the each slot into a per-channel linear buffer useful for calling the
related dahdi_transmit()
and dahdi_receive() functions.

The question is, can I call the dahdi_transmit() from the TX DMA callback and
the dahdi_receive() from
the RX DMA callback or should use a particular order for them?

Looking at the DAHDI drivers it seems that the sequence is always:
dahdi_ec_chunk() -> dahdi_receive()
and then dahdi_transmit().

Thanks in advance,
Roberto Fichera.

On Thu, Nov 5, 2015 at 11:36 AM, Roberto Fichera <kernel at tekno-soft.it>
wrote:
> The question is, can I call the dahdi_transmit() from the TX DMA callback
and the dahdi_receive() from
> the RX DMA callback or should use a particular order for them?
I don't think it will be a problem to call them asynchronously.
Depending on your signal, _dahdi_transmit() and _dahdi_recieve() can
potentially do a lot of processing. They're better suited in a bottom
half than in interrupt context.


-- 
Russ Meyerriecks
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
direct: +1 256-428-6025
Check us out at: www.digium.com & www.asterisk.org

On 11/05/2015 08:56 PM, Russ Meyerriecks wrote:
> On Thu, Nov 5, 2015 at 11:36 AM, Roberto Fichera <kernel at
tekno-soft.it> wrote:
>> The question is, can I call the dahdi_transmit() from the TX DMA
callback and the dahdi_receive() from
>> the RX DMA callback or should use a particular order for them?
> I don't think it will be a problem to call them asynchronously.
> Depending on your signal, _dahdi_transmit() and _dahdi_recieve() can
> potentially do a lot of processing. They're better suited in a bottom
> half than in interrupt context.
Ok! Then I'll just copy the data and schedule the related TX or RX work.