Hi Steve, On Mon, 2017-01-09 at 20:43 +0100, Philipp Zabel wrote: > On the other hand, there is currently no way to communicate to userspace > that the IC can't downscale bilinearly, but only to 1/2 or 1/4 of the > input resolution, and then scale up bilinearly for there. This is completely wrong. For some reason I that I can't reconstruct anymore, I didn't realize that the PRPENC/VF_RS_R_V/H coefficient fields for the resizing section are 14 bits wide, so the bilinear scaling factor can in fact be reduced down to 8192/16383 ~= 0.50003 before the /2 downsizing section needs to be engaged. > So instead of > pretending to be able to downscale to any resolution, it would be better > to split each IC task into two subdevs, one for the > 1/2-or-1/4-downscaler, and one for the bilinear upscaler. So this point is moot. I still like the unified PRP subdev because of the single input pad, but splitting the scaling over two subdevs is not useful after all. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
