<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style> tfiga: I suppose the request should be completed, but does that mean that we need to return the buffers from the other queues too? <br> <u>pinchartl</u>: sailus: ^^ <br> to make it even more complicated, what if there are some requests without a buffer from the queue being stopped pinchartl: <u>tfiga</u>: I think streamon/streamoff makes less sense with requests. we're trying to make two very different APIs work together, and it shows its limits. regardless of what we decide to do in this particular case, we'll have hacks <br> is this for a video codec ? tfiga: <u>pinchartl</u>: indeed, that was a bit of my thought as well :( <br> for an ISP <br> think of a similar model as IPU3 IMGU, but using Request API pinchartl: one option would be to ignore streamon/off on all queues but the main one (you can pick pretty much any queue as the main one) <br> and a VIDIOC_STREAMON/OFF on the main video node would then start/stop all queues paulk-leonov: <u>bbrezillon</u>: ezequielg: is the RK3399 VDPU related to hantro in any way? <br> seems to have different codec ops in the driver bbrezillon: paulk-leonov: it is <br> the fields are just shuffled paulk-leonov: <u>bbrezillon</u>: ah I see <br> so it's also a G1 and probably a G2 for HEVC/VP9? bbrezillon: but you'll find exactly the same fields and it works the same way paulk-leonov: okay thanks bbrezillon: nope, they have their own block for HEVC/H264(4K)/VP9 paulk-leonov: ah ok bbrezillon: AFAICT it's not based on the G2 paulk-leonov: that's what they call VPU2? bbrezillon: they call it rkvdec <br> VPU2 is the G1 with reg-fields shuffled IIRC <br> well, it's actually a G1/H1 combo paulk-leonov: right <br> so rk3288 has a G2 then? <br> (I see HAVE_HEVC_DEC in mpp) bbrezillon: hm, I don't think it has a G2 paulk-leonov: <u>bbrezillon</u>: so my understanding is that rockchip came up (or sourced) an h265 IP that they used in rk3288 and later improved it to become the rk3399 h264/hevc/vp9 engine <br> apparently mpp has only a single implementation for hevc <br> so I'm assuming it must be the same on both rk3288 and rk3399 <br> clocks between rk3288 hevc and rk3399 rkvdec seem to match ***: benjiG has left