Re: [RESEND RFC/PATCH 3/8] media: platform: mtk-vpu: Support Mediatek VPU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 27/11/15 12:10, andrew-ct chen wrote:
+
> >+	memcpy((void *)send_obj->share_buf, buf, len);
> >+	send_obj->len = len;
> >+	send_obj->id = id;
> >+	vpu_cfg_writel(vpu, 0x1, HOST_TO_VPU);
> >+
> >+	/* Wait until VPU receives the command */
> >+	timeout = jiffies + msecs_to_jiffies(IPI_TIMEOUT_MS);
> >+	do {
> >+		if (time_after(jiffies, timeout)) {
> >+			dev_err(vpu->dev, "vpu_ipi_send: IPI timeout!\n");
> >+			return -EIO;
> >+		}
> >+	} while (vpu_cfg_readl(vpu, HOST_TO_VPU));
>
>Do we need to busy wait every time we communicate with the co-processor?
>Couldn't we put this wait*before*  we write to HOST_TO_VPU above.
>
>That way we only spin when there is a need to.
>
Since the hardware VPU only allows that one client sends the command to
it each time.
We need the wait to make sure VPU accepted the command and cleared the
interrupt and then the next command would be served.

I understand that the VPU  can only have on message outstanding at once.

I just wonder why we busy wait *after* sending the first command rather than *before* sending the second one.

Streamed decode/encode typically ends up being rate controlled by capture or display meaning that in these cases we don't need to busy wait at all (because by the time we send the next frame the VPU has already accepted the previous message).


Daniel.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux