@@ -247,8 +247,6 @@ static int host1x_cdma_wait_pushbuffer_space(struct host1x *host1x,
trace_host1x_wait_cdma(dev_name(cdma_to_channel(cdma)->dev),
CDMA_EVENT_PUSH_BUFFER_SPACE);
- host1x_hw_cdma_flush(host1x, cdma);
-
/* If somebody has managed to already start waiting, yield */
if (cdma->event != CDMA_EVENT_NONE) {
mutex_unlock(&cdma->lock);
@@ -591,7 +589,6 @@ int host1x_cdma_begin(struct host1x_cdma *cdma, struct host1x_job *job)
*/
void host1x_cdma_push(struct host1x_cdma *cdma, u32 op1, u32 op2)
{
- struct host1x *host1x = cdma_to_host1x(cdma);
struct push_buffer *pb = &cdma->push_buffer;
u32 slots_free = cdma->slots_free;
@@ -599,11 +596,9 @@ void host1x_cdma_push(struct host1x_cdma *cdma, u32 op1, u32 op2)
trace_host1x_cdma_push(dev_name(cdma_to_channel(cdma)->dev),
op1, op2);
- if (slots_free == 0) {
- host1x_hw_cdma_flush(host1x, cdma);
+ if (slots_free == 0)
slots_free = host1x_cdma_wait_locked(cdma,
CDMA_EVENT_PUSH_BUFFER_SPACE);
- }
cdma->slots_free = slots_free - 1;
cdma->slots_used++;
The current code can issue CDMA flushes (DMAPUT bumps) in the middle of a job, before all opcodes have been written into the pushbuffer. This can happen when pushbuffer fills up. Presumably this made sense at some point in the past, but it doesn't anymore, as it cannot lead to more space appearing in the pushbuffer as it is only cleaned full jobs at a time. Mid-job flushes can also cause problems, as in an extreme situation (seen in practice), the hardware can run through the entire pushbuffer including the prefix of a partially written job without the driver being able to process any CDMA updates. This can cause the engine MLOCK to be taken and held for extended periods as the tail of the job is not yet available to hardware. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> --- drivers/gpu/host1x/cdma.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)