2008/7/14 The Rasterman Carsten Haitzler <[EMAIL PROTECTED]>: > On Mon, 14 Jul 2008 14:26:59 +0100 Andy Green <[EMAIL PROTECTED]> babbled: > > aye. this gives the nitties of what the glamo is causing in performance > issues. > basically this is the crux of the "bus bandwidth to the glamo" issue. while > reading or writing to the glamo the cpu gets stalled waiting for the glamo - > limiting throughput to about 7m/sec. unfortunately for us the cpu is hung > waiting on the slow glamo when it could be off doing something more useful > with > its time (even if we accepted limited write/read rates, if they could be async > we'd be much better off). this was the crux behind the DMA experiment dodji > did. the problem was that the DMA was on-soc and memory to memory and would > hold > up the cpu in wait states anyway - so you don't win over using the cpu.
<rant> Ouch. If the DMA has to block the whole SoC when waiting for the nWAIT then it's really bad, and it seems to be confirmed by what I saw (i.e. if I disabled the clock and tried to write to glamo, the whole SoC would hang, even the JTAG wouldn't respond). I'm pretty sure the S3C series must special in this regard, and someone should really consider a completely different SoC for the next models. There's so many things wrong with them (the timers (16-bit!), the DMA (see below), the power management, the documentation silently taken away - this should be alerting). Their only advantage I see is the hw team is already familiar with them. I don't believe the cost is a blocker for switching to, say, OMAP. </rant> But here's an idea: we aleady know that we will have to "nWAIT" for a moment before every write to Glamo - we can spend that time just nWAITing or perhaps we can do something else on the CPU, and then start our transfer just in the right moment for the write to be instant or almost instant. The lengths of periods we spend nWAITing may have some non-trivial pattern but it's easy to research. How to do that: the OMAP dma can be told to wait a couple of clocks before every atomic transfer (element, in omap speak), the s3c can't do that, I just checked - but it can be synchronised with a timer. In Dodjis test the transfers were not synchronised - they were like memcpy/memset, i.e. a new transfer starts a soon as the previous one finishes. Instead the DMA can stop after every 8, 16 or 32 bits or N times that, and wait for the PWM timer. I'll try that some weekend. Cheers
