v4l: ti-vpe: Add crop support in VPE driver Add crop ioctl ops. For VPE, cropping only makes sense with the input to VPE, or the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type. For the CAPTURE type, a S_CROP ioctl results in setting the crop region as the whole image itself, hence making crop dimensions same as the pix dimensions. Setting the crop successfully should result in re-configuration of those registers which are affected when either source or destination dimensions change, set_srcdst_params() is called for thist purpose. Some standard crop parameter checks are done in __vpe_try_crop(). Change-Id: I7b9e31d34ca8b48be0f34ba72fa7cf602458d5ab Signed-off-by: alaganraj <alaganraj.s@ti.com>
v4l: ti-vps: Fix some params in VPE data descriptors Some parameters of the VPE descriptors were understood incorrectly. They are now fixed. The fixes are explained as follows: - When adding an inbound data descriptor to the VPDMA descriptor list, we intend to use c_rect as the cropped region fetched by VPDMA. Therefore, c_rect->width shouldn't be used to calculate the line stride, the original image width should be used for that. We add a 'width' argument which gives the buffer width in memory. - frame_width and frame_height describe the complete width and height of the client to which the channel is connected. If there are multiple channels fetching data and providing to the same client, the above 2 arguments should be the width and height of the region covered by all the channels. In the case where there is only one channel providing pixel data to the client (like in VPE), frame_width and frame_height should be the cropped width and cropped height respectively. The calculation of these params is done in the vpe driver now. - start_h and start_v is also used in the case of multiple channels to decribe where each channel should start filling pixel data. We don't use this in VPE, and pass 0s to the vpdma_add_in_dtd() helper. - Some minor changes are made to the vpdma_add_out_dtd() helper. The c_rect param is removed since cropping isn't possible for outbound data, and 'width' is added to calculate the line stride. Change-Id: I4a5bc52d1a5a078663b2b03f63213eba8855e5a3 Signed-off-by: alaganraj <alaganraj.s@ti.com> Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
v4l: ti-vpe: Remove unnescessary wmb() call when submitting descs A wmb() memory barrier call was placed between the register writes to VPDMA_LIST_ADDR and VPDMA_LIST_ATTR to ensure the correct write order is ensured. iowrite32() already performs the following task, and hence it's redundant to call it again. Remove the wmb() call from vpdma_submit_descs. Change-Id: Id5c18ffce7a2c1862fed2d5d455c80c81e7883a6 Signed-off-by: alaganraj <alaganraj.s@ti.com>
v4l: ti-vpe: Remove extra vpdma_buf_unmap call The VPDMA buffer for the descriptor list is currently unmapped twice in the driver. It's first unmapped in the vpe_irq interrupt handler, and then in vpe_release() when the vpe video device is closed. Remove the extra call from vpe_release(). Change-Id: I30935e124aa440d5754e13173d37d19ad396c937 Signed-off-by: alaganraj <alaganraj.s@ti.com>
v4l: ti-vpe: Use dma API to allocate motion vector buffers Motion vector buffers are currently allocated through kernel's kzalloc function. These buffers can be large if the input buffer resolution is high. We should use dma API when allocating large buffers. Change the allocation from kzalloc to DMA API. Change-Id: I9732f7fa80ab69d7fa5bca0acfaa59f473f19539 Signed-off-by: alaganraj <alaganraj.s@ti.com>
v4l: ti-vpe: Increase VPDMA desriptor list size With the addition of config descriptors for loading scaler coefficients, and the addition of control descriptors for input channels. The current list size might not accomodate all the descriptors. Increase this value to the maximum possible descriptor size. Change-Id: Idc42fd9c065096098c1515b4b07f7c3d1786be2f Signed-off-by: alaganraj <alaganraj.s@ti.com>
v4l: ti-vpe: Add sync on channel descriptors for input VPE ports We currently stall the VPDMA descriptor list till the time the output channels complete their DMA. In certain cases, this may not be the correct completion event. It's possible that there is some pending DMA operation still occuring on one of the input channels. Add sync on channel control descriptors for the input channels to make sure a list complete interrupt occurs when all the channels are done with DMA. Change-Id: I24d3127bf854fe8ac145e33803665a7a58a1d042 Signed-off-by: alaganraj <alaganraj.s@ti.com>
v4l: ti-vpe: Add 'const' to intialized struct variables Add 'const' to intialized structure variables, to prevent members are modified at run time. Change-Id: I582b9371bee741a79f8acf699c52236d99a526e4 Signed-off-by: alaganraj <alaganraj.s@ti.com>
v4l: ti-vpe: vpdma: Add a type specifier to describe vpdma data format type The struct vpdma_data_format holds the color format depth and the data_type value needed to be programmed in the data descriptors. However, it doesn't tell what type of color format is it, i.e, whether it is RGB, YUV or Misc. This information is needed when by vpdma library when forming descriptors. We modify the depth parameter for the chroma portion of the NV12 format. For this, we check if the data_type value is C420. This isn't sufficient as there are many YUV and RGB vpdma formats which have the same data_type value. Hence, we need to hold the type of the color format for the above case, and possibly more cases in the future. Change-Id: Ia18ab994093cedc9eee23df897b250378a729b93 Signed-off-by: alaganraj <alaganraj.s@ti.com>
v4l: ti-vpe: enable CSC support for VPE Use the csc library functions to configure the CSC block in VPE. Some changes are required in try_fmt to handle the pix->colorspace parameter more correctly. Add basic RGB color formats to the list of supported vpe formats. If the destination format is RGB colorspace, we also need to use the RGB output port instead of the Luma and Chroma output ports. This requires configuring the output data descriptors differently. Also, make the default colorspace V4L2_COLORSPACE_SMPTE170M as that resembles the Standard Definition colorspace more closely. Change-Id: I9d762d8a0f6d0531dfc227e3c6853048b23fecbf Signed-off-by: alaganraj <alaganraj.s@ti.com>
v4l: ti-vpe: enable YUV to RGB color conversion support The CSC block can be used for color space conversion between YUV and RGB formats. It is configurable via a programmable set of coefficients. Add functionality to choose the appropriate CSC coefficients and program them in the CSC registers. We take the source and destination colorspace formats as the arguments, and choose the coefficient table accordingly. Only YUV to RGB coefficients are provided for standard and high definition colorspaces. The coefficients can also be limited or full range, only full range coefficients are chosen by default. We would need some sort of control ioctl for the user to specify the range needed. Change-Id: I1aa76dfcc0702ef022e8516f59a64f953f7331c5 Signed-off-by: alaganraj <alaganraj.s@ti.com>
v4l: ti-vpe: create a color space converter library Create the csc block related configurations and register definitions as a library. This is done as the same csc block is used in both VIP and VPE. The vpe_dev device holds a csc_data handle, which it can reference to access the registers, or call csc related helper functions. Change-Id: I50aaac7401c9e1848818bbb1b396f3e1e6829082 Signed-off-by: alaganraj <alaganraj.s@ti.com>
v4l: ti-vpe: enable basic scaler support Add the required scaler register configurations which lets us perform linear scaling for the supported range of horizontal and vertical scaling ratios. The horizontal scaler performs polyphase scaling using it's 8 tap 32 phase filter, decimation is performed when downscaling passes beyond 2x or 4x. The vertical scaler performs polyphase scaling using it's 5 tap 32 phase filter, it switches to a simpler form of scaling using the running average filter when the downscale ratio is more than 4x. Many of the scaler features like peaking, trimming and non-linear scaling aren't implemented for now. Only those register fields are configured which are required for basic scaling operation. The function to configure scaler registers takes the sc_data handle, the source and destination directions, and the scaler address data block offsets for the current context so that they can be configured. Change-Id: Iaaf08f5f3d5c2c9d95d97543ef333c7b7fa7178a Signed-off-by: alaganraj <alaganraj.s@ti.com>
v4l: ti-vpe: load scaler coefficients The scaler IP requires to be loaded with coefficients from memory through VPDMA. The horizontal and vertical scaler each require a set of scaler coefficients. The horizontal polyphase scaler requires luma and chroma coefficients for a 32 phase and 8 tap filter. Similarly, the vertical scaler requires coefficients for a 5 tap filter. In order to load the scaler coefficients via VPDMA, a configuration descriptor is used in block mode. The payload for the descriptor is the scaler coefficients copied to memory. The coefficients need to be placed in memory in a particular order, this is taken care by the functions sc_set_hs and sc_set_vs_coefficients. The choice of the scaler coefficients depends on the downscale ratio. In the case of horizontal downscaling, we need to consider the change in ratio cause by decimation. In the case of vertical scaling, the VPE driver should provide the source height based on whether the de-interlacer is used or not. Change-Id: I6e8b5a9e2d3a9ac1f7fbe93333be54d7edb960bc Signed-off-by: alaganraj <alaganraj.s@ti.com>
v4l: ti-vpe: Create a scaler library Create the scaler block related configurations and register definitions as a library. This is done as the same scaler block is used in both VIP and VPE. The vpe_dev device holds a sc_data handle, which it can reference to access the registers, or call scaler related helper functions. Change-Id: Ia785ba243938759555dd7bca9e6f547be00c07db Signed-off-by: alaganraj <alaganraj.s@ti.com> Conflicts: drivers/media/platform/Makefile Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
v4l: ti-vpe: make sure VPDMA line stride constraints are met When VPDMA fetches or writes to an image buffer, the line stride must be a multiple of 16 bytes. If it isn't, VPDMA HW will write/fetch until the next 16 byte boundry. In order to prevent this, we now make sure that the VPE source and destination image line strides are 16 byte aligned. Also, the motion vector buffer must be allocated in such a way that it ensures the same alignment. Change-Id: Iff0c3a433ecfeb73a4cdda9a50229d5d3c6c4f4b Signed-off-by: alaganraj <alaganraj.s@ti.com>
v4l: ti-vps: Fix the data_type value for UYVY VPDMA format The data_type value to be programmed in the data descriptors to fetch/write a UYVY buffer was not mentioned correctly in the older DRA7x documentation. This caused VPE to fail with UYVY color formats. Update the data_type value to fix functionality when UYVY format is used. Change-Id: I2ef7b07da9a1a955cf56f637f318f1f822b969f6 Signed-off-by: alaganraj <alaganraj.s@ti.com>