Hi Guennadi,
I was wondering what's the stand on allowing soc_camera host drivers to have
internal scalers...
It looks possible, but however I see one important blocker for being able to
change window rectangle while streaming (for example, when attempting to do
zoom in/out during streaming). See here:
in soc_camera.c::soc_camera_s_crop()
...
/* If get_crop fails, we'll let host and / or client drivers decide */
ret = ici->ops->get_crop(icd, ¤t_crop);
/* Prohibit window size change with initialised buffers */
if (ret < 0) {
dev_err(&icd->dev,
"S_CROP denied: getting current crop failed\n");
} else if (icd->vb_vidq.bufs[0] &&
(a->c.width != current_crop.c.width ||
a->c.height != current_crop.c.height)) {
dev_err(&icd->dev,
"S_CROP denied: queue initialised and sizes differ\n");
ret = -EBUSY;
} else {
ret = ici->ops->set_crop(icd, a);
}
...
Now, I don't want to move just yet to a Media Controller implementation in my
omap4 camera driver, since I don't intend yet to exploit the full HW, which
is easly 2x more complicated than omap3. But I want to start with a simplistic
driver which Pandaboard community can take (which don't need any advanced
features, just being able to receive frames.) and i just want to know how
complicated is to just offer the scaler functionality still.
Regards,
Sergio
--
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
