On Tuesday 01 June 2010 10:38:28 ext Jarkko Nikula wrote: > On Tue, 1 Jun 2010 09:47:09 +0300 > > Peter Ujfalusi <peter.ujfalusi@xxxxxxxxx> wrote: > > I like the following naming: > > omap_mcbsp_hwrule_min_buffersize() > > omap_mcbsp_hwrule_max_periodsize() > > Looks clear to me. > > > Also, I think there is no point to limit the lower period size in > > threshold mode to 32, so I will remove that as well I think. > > What was the reason why period size cannot be bigger than threshold? > This constraint was there before your patch but I don't remember reason > for it. When DMA is used to push the data to McBSP on OMAP3: The McBSP threshold means, that if threshold amount of locations (words) are free in the buffer, than the DMA request line will be asserted, and McBSP expects that DMA will transfer _exactly_ threshold number of words in response to the DMA request. So, if threshold is 1 (in register it is 0), than McBSP requests for new word, whenever a single location is free in the FIFO. The DMA should send 1 word per DMA request. If threshold is configured to 100 (99 in register), than McBSP will asserts the DMA request line, when 100 locations are free. Than DMA has to send 100 words per DMA request. So we need to limit the period size (which is used to configure the DMA's elem count - number of words per DMA request) that it shall never be bigger than the threshold. > Should it be opposite that period size cannot be smaller than threshold? No. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html