On Fri, 10 Feb 2017 09:06:14 +0100, Ughreja, Rakesh A wrote:
By using a generic dmix code with semaphore, this performance problem is resolved. So, S16/S32 supports are OK in the end.
But this leads to another question wrt the kernel driver code: why the driver allocates / maps with uncached page, not with write- combined? Pierre, Jerome, any clue?
In CHT and BYT the organization of the hardware fabric is such that the HDMI DMA transactions are not snooped and so it will fetch data only from DDR. In most non-atom platforms it is snooped, and so fabric will return data from cache if it is updated.
In the past we faced problem where the DMA was fetching some old data because cache was not flushed into DDR. That's where we marked the pages as uncached.
Thanks, that's my expectation. The similar hacks are applied to some audio platforms like AMD HDMI HD-audio. But my question is about the write-combined (WC) pages. There are four modes about page caching: write-back (WB), writhe-through (WT), write-combined (WC) and uncached (UC).
Usually WC is enough to work as uncached like the use case above, not necessary to disable the whole cache via UC. WC worked fine for HD-audio, at least. For LPE audio, is UC really stated as mandatory requirement?
No, as such there is no guidelines from HW guys. Technically WC would work as well.
Question I have is, when we use the smaller period size with say 2 periods with WC, how do we ensure that the last write has been propagated to the main memory. Last write size may be smaller than the WC cache size.
A good question. I vaguely remembered that it's rather cache align size, but I might be wrong here. It needs more check.
In anyway, WC cache can't help for dmix problem, as the dmix x86 implementation requires the read from the buffer, where the read on WC page ends up with the total flushing. So this can be postponed.
thanks,
Takashi