Hi Mauro,
On Mon, Oct 24, 2011 at 15:05, Mauro Carvalho Chehab mchehab@redhat.com wrote:
Em 24-10-2011 18:42, Pawel Osciak escreveu:
On Mon, Oct 24, 2011 at 08:57, Mauro Carvalho Chehab mchehab@redhat.com wrote:
I added two things that were asked for to be added to vb2 for Qualcomm hardware.
Those ones, right?
Yes.
Changes in vb2 core (requested by Qualcomm)
- Add an option to choose between allocating multi-planar buffers in one shot (i.e. all planes in one alloc call) or each plane sepearately (one alloc call per plane).
- Add an additional field to v4l2_plane - reserved_size (or something similar). The plane would look like this: |<-reserved_size->|<-data_offset->|<-image bits->|. Reserved size can only be passed by application and driver has to respect it and never overwrite that area. Data_offset can be set by application (in OUTPUT case) or by the driver (in CAPTURE) case and has to be copied on QBUF in former case and on DQBUF in latter case.
It follows my comments about them:
I don't see why not adding the first one to the driver. My understanding is that this is something that it could be added together with the rest of patches they'll be submitting for merge.
vb2 core calls memops->alloc for every plane, which is clean and simple and maps nicely to general-use allocators. The Qualcomm drivers though would like to allocate all planes for one buffer in one shot, as they need to establish a relationship between planes belonging to one buffer (e.g. to map them in one shot in IOMMU). Adding this would not be very elegant, alloc would have to take an additional argument like the buffer number, and that argument would be a dead-weight for all others. I must say I am not very happy with this additional complication, but how could this be solved just by the driver? It would have to somehow figure out which planes belong to which buffer by itself... Would anyone have a better idea?
With regards to the second one, it sounds really weird to me. Why should feature should be needed?
There apparently is a need to store application-specific data in the buffer that should not be modified by drivers, but could be read by them. I think Hans also found a use for this, I don't want to mix things up here, Mingcheng and Hans, could you answer this question?