Issue using SGDMA to frame buffer

Yes, full word access only seems appropriate since you are moving pixels or multiple pixels around per clock cycle. If the master is 32-bit then yes the data needs 4-byte alignment but if you use a different width then the alignment changes (data width / 8 is the alignment constraint)

You can probably leave the response port disabled, it's really meant for ST-->MM transfers where the transfer is terminated by EOP entering the sink of the write master. Since you are working with video frames I don't see the need to use SOP&EOP packet support since you already know the frame size ahead of time.

If you place 4 descriptors into the DMA it will issue the writes when the data arrives at the ST sink port. When the first descriptor completes (first frame) the write master should be ready to start accepting the next frame of data since you already told it what to do with it in the 2nd descriptor. So if it hasn't buffered the streaming data then it won't write to memory and will sit idle waiting for it. If for some reason the memory backpressures due to traffic congestion then the write master will continue accepting data from the ST sink port since there is a FIFO inside it. If the memory backpressures to the point where the write master FIFO fills then it will backpressure the ST sink port which is typically bad in video applications because you will loose pixels typically unless you have another buffer between the DMA and the video IP. So make sure to size the data FIFO accordingly and setup the memory arbitration share high for the DMA so that it gets more shares of the bandwidth than other masters trying to access the same memory.

When a descriptor has the parked read or write bits enabled what the master will do is keep re-using the same descriptor if there are no other descriptors left to operate on. Write parking doesn't really any practical use that I can think of but read parking is useful when you use the mSGDMA for sending frame buffers out to the display. For example if you have only drawn one frame and are drawing the next one, you can send the first frame to the DMA with the parked reads bit enable which will cause it to keep redisplaying the same frame. Then when you are done drawing the next frame you send that descriptor and the DMA will then transition to the next descriptor. This prevents screen tearing because you don't want to be drawing to the same frame as the one that's being displayed but at the same time whatever is drawing the frame might not be able to keep up with the display rate so this parked read feature lets you implement double buffering and not have to worry about constantly re-sending the same descriptor multiple times to redisplay the same frame over again.