lkml.org 
[lkml]   [2015]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RESEND RFC/PATCH 3/8] media: platform: mtk-vpu: Support Mediatek VPU
From
Date
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.



\
 
 \ /
  Last update: 2015-11-27 13:41    [W:0.118 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site