Hi,
On Friday 30 August 2013 12:37 PM, Hans Verkuil wrote:
On 08/30/2013 08:47 AM, Archit Taneja wrote:
On Thursday 29 August 2013 06:58 PM, Hans Verkuil wrote:
On Thu 29 August 2013 14:32:49 Archit Taneja wrote:
VPE is a block which consists of a single memory to memory path which can
perform chrominance up/down sampling, de-interlacing, scaling, and color space
conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422
interleaved video formats.
We create a mem2mem driver based primarily on the mem2mem-testdev example.
The de-interlacer, scaler and color space converter are all bypassed for now
to keep the driver simple. Chroma up/down sampler blocks are implemented, so
conversion beteen different YUV formats is possible.
Each mem2mem context allocates a buffer for VPE MMR values which it will use
when it gets access to the VPE HW via the mem2mem queue, it also allocates
a VPDMA descriptor list to which configuration and data descriptors are added.
Based on the information received via v4l2 ioctls for the source and
destination queues, the driver configures the values for the MMRs, and stores
them in the buffer. There are also some VPDMA parameters like frame start and
line mode which needs to be configured, these are configured by direct register
writes via the VPDMA helper functions.
The driver's device_run() mem2mem op will add each descriptor based on how the
source and destination queues are set up for the given ctx, once the list is
prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will
upload MMR registers, start DMA of video buffers on the various input and output
clients/ports.
<snip>
+}
+
+#define V4L2_CID_TRANS_NUM_BUFS (V4L2_CID_USER_BASE + 0x1000)
Reserve a control range for this driver in include/uapi/linux/v4l2-controls.h.
Similar to the ones already defined there.
That will ensure that controls for this driver have unique IDs.
Thanks, I took this from the mem2mem-testdev driver, a test driver
doesn't need to worry about this I suppose.
I had a query regarding this. I am planning to add a capture driver in
the future for a similar IP which can share some of the control IDs with
VPE. Is it possible for 2 different drivers to share the IDs?
Certainly. There are three levels of controls:
1) Standard controls: can be used by any driver and are documented in the spec.
2) IP-specific controls: controls specific for a commonly used IP.
These can be used by any driver containing that IP and are documented as well
in the spec. Good examples are the MFC and CX2341x MPEG controls.
3) Driver-specific controls: these are specific to a driver and do not have to be
documented in the spec, only in the header/source specifying them. A range
of controls needs to be assigned to such a driver in v4l2-dv-controls.h.
In your case it looks like the controls would fall into category 2.
For 2), by commonly used IP, do you mean a commonly used class of IPs
like MPEG decoder, FM and camera? Or do you mean a specific vendor IP
like say a camera subsystem found on different SoCs.
I think the controls in my case are very specific to the VPE and VIP
IPs. These 2 IPs have some components like scaler, color space
converter, chrominance up/downsampler in common. The controls will be
specific to how these components behave. For example, a control can tell
what value of frequency of Luminance peaking the scaler needs to
perform. I don't think all scalers would provide Luma peaking. This
holds for other controls too.
So if I understood your explanation correctly, I think 3) might make
more sense.
Also, I noticed in the header that most drivers reserve space for 16
IDs. The current driver just has one, but there will be more custom ones
in the future. Is it fine if I reserve 16 for this driver too?
Sure, that's no problem. Make sure you reserve enough space for future
expansion, i.e. IDs are cheap, so no need to be conservative when defining
the range.
Thanks for the clarification.
Archit
--
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
