nWAITing for Glamo / DMA on timer

Andy Green andy at openmoko.com
Wed Jul 16 09:04:21 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

| 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

It says in the datasheet that the nWAIT period should "typically" be 0
and max 3 "T" where "T" is some undefined internal Glamo clock.  But
instead of nWAIT being an occasional last resort for sorting out
arbitration clashes it seems to be very common indeed.  I fiddled with
the arbitration min max chunk sizes in Glamo but it didn't help.

| (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

Yes I saw this too when poking the Glamo regs, it makes sense if nWAIT
is just asserted all the time then the CPU is in "autistic mode", it
can't get out of the chip to do anything.  It's not the CPU's fault,
it's normal if something acts like that on the other end.  It's the
Glamo for not having a big FIFO.

| 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.

It's a subtle decision about what CPU to use, we have investment in s3c
stuff in hardware and kernel, but it seems more people worked on OMAP
Linux and maybe it is an easier ride.  Grass is always greener though
and this is just a little corner of what we have to worry about if we
considered to jump ship.  Agree about the datasheet closure though, it
is pretty annoying when it is normal to have open data for these kind of
chips from other vendors.

| 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.

It's an interesting idea, you basically make a slower autonomous
"shipping lane" to push stuff into Glamo RAM in the background without
blocking external bus in lumps.  It can make sense considering there is
a lot of RAM outside the framebuffer in the Glamo, if you can bitblit
later from Glamo RAM -> Glamo RAM you get it "for free" then.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list