On Wed, Mar 06, 2013 at 20:14:59, Michal Bachraty wrote: [...]
Yes, threre is misleading with tx_num_evt in DT. This misleading is discussed in [alsa-devel] davici-mcasp: "tx-num-evt" confusion with number of serializers. thread.
I responded to that thread yesterday. Can you please check that.
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
src = dma_pos; dst = prtd->params->dma_addr; src_bidx = data_type;
dst_bidx = 0;src_cidx = data_type * fifo_level;
dst_bidx = 4;Err.. this will most likely break other audio configurations. You should look at how to avoid this change by making use of the mask and rotation operations in the McASP code.>
McAsp FIFO and McASP data port reg. is 32 bit wide, each new sample is copied to McASP after McAsp send DMA event. McASP also do data rotations and masking. When more serializers are enabled, each new sample for new serializer should be placed to new data room at +4 address. After that new DMA event is generated. I tested it with TDM slots = 2 and also 6 with one serializer and also two serializer enabled. Why do you think that brokes other audio configurations?
Refer to section 22.3.10.1.2 of the AM335x TRM.
"To access through the data port, simply have the CPU or DMA access the XRBUF through its data port location. Through the data port, the DMA/CPU can service all the serializers through a single address. The McASP automatically cycles through the appropriate serializers.
For transmit operations through the data port, the DMA/CPU should write to the same XBUF data port address to service all of the active transmit serializers. In addition, the DMA/CPU should write to the XBUF for all active transmit serializers"
The DMA controller is expected to write to the same address. I am a bit surprised the +4 thing works without issue. Still, you should not rely on that since that's not supported as per the specs.
Regards, Vaibhav