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.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
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. Previously, we copied the source queue colorspace to the
destination queue colorspace as we didn't support RGB formats. Now, we configure
pix->colorspace based on the color format set(and the height of the image if
it's a YUV format).
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.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
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.
YUV to RGB coefficients are provided for standard and high definition
colorspaces. The coefficients can also be limited or full range. For now, only
full range coefficients are chosen. We would need some sort of control ioctl for
the user to specify the range needed. Not sure if there is a generic control
ioctl for this already?
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
VPE and VIP IPs in DAR7x contain a color space converter(CSC) sub block. Create
a library which will perform CSC related configurations and hold CSC register
definitions. The functions provided by this library will be called by the vpe
and vip drivers using a csc_data handle.
The vpe_dev holds the csc_data handle. The handle represents an instance of the
CSC hardware, and the vpe driver uses it to access the CSC register offsets or
helper functions to configure these registers.
The CSC register offsets are now relative to the CSC block itself, so we need
to use the macro GET_OFFSET_TOP to get the CSC register offset relative to the
VPE IP in the vpe driver.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Add the required SC 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 SC features like peaking, trimming and non-linear scaling aren't
implemented for now. Only the minimal register fields required for basic scaling
operation are configured.
The function to configure SC registers takes the sc_data handle, the source and
destination widths and heights, and the scaler address data block offsets for
the current context so that they can be configured.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Make the driver allocate dma buffers to store horizontal and scaler coeffs.
Use the scaler library api to choose and copy scaler coefficients to a
the above buffers based on the scaling ratio. Since the SC block comes after
the de-interlacer, make sure that the source height is doubled if de-interlacer
was used.
These buffers now need to be used by VPDMA to load the coefficients into the
SRAM within SC.
In device_run, add configuration descriptors which have payloads pointing to
the scaler coefficients in memory. Use the members in sc_data handle to prevent
addition of these descriptors if there isn't a need to re-load coefficients into
SC. This comes helps unnecessary re-loading of the coefficients when we switch
back and forth between vpe contexts.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
The SC block in VPE/VIP contains a SRAM within it. This internal memory
requires to be loaded with appropriate scaler coefficients from a contiguous
block of memory through VPDMA.
The horizontal and vertical scaler each require 2 sets of scaler coefficients
for luma and chroma scaling. The horizontal polyphase scaler requires
coefficients for a 32 phase and 8 tap filter. Similarly, the vertical scaler
requires coefficients for a 5 tap filter.
The choice of the scaler coefficients depends on the scaling ratio. Add
coefficient tables for different scaling ratios in sc_coeffs.h. In the case of
horizontal downscaling, we need to consider the change in ratio caused by
decimation performed by the horizontal scaler.
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. Coefficients for each phase have to be placed in memory in a
particular order understood by the scaler hardware.
The choice of the scaler coefficients, and the loading of the coefficients from
our tables to a contiguous buffer is managed by the functions
sc_set_hs_coefficients and sc_set_vs_coefficients.
The sc_data handle is now added with some parameters to describe the state of
the coefficients loaded in the SC block. 'loaded_coeff_h' and 'loaded_coeff_v'
hold the address of the last dma buffer which was used by VPDMA to copy
coefficients. This information can be used by a vpe mem-to-mem context to decide
whether it should load coefficients or not. 'hs_index' and 'vs_index' provide
some optimization by preventing loading of coefficients if the scaling ratio
didn't change between 2 contexts. 'load_coeff_h' and 'load_coeff_v' tell the
vpe/vip driver whether we need to load the coefficients through VPDMA or not.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
VPE and VIP IPs in DAR7x contain a scaler(SC) sub block. Create a library which
will perform scaler block related configurations and hold SC register
definitions. The functions provided by this library will be called by the vpe
and vip drivers using a sc_data handle.
The vpe_dev holds the sc_data handle. The handle represents an instance of the
SC hardware, and the vpe driver uses it to access the scaler register offsets
or helper functions to configure these registers.
We move the SC register definitions to sc.h so that they aren't specific to
VPE anymore. The register offsets are now relative to the sub-block, and not the
VPE IP as a whole. In order for VPDMA to configure registers, it requires it's
offset from the top level VPE module. A macro called GET_OFFSET_TOP is added to
return the offset of the register relative to the VPE IP.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
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. This causes VPE to work incorrectly for source or destination
widths which don't satisfy the above alignment requirement.
In order to prevent this, we now make sure that when we set pix format for the
input and output buffers, the VPE source and destination image line strides are
16 byte aligned. Also, the motion vector buffers for the de-interlacer are
allocated in such a way that it ensures the same alignment.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
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.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
In case of error, the function devm_kzalloc() and devm_ioremap()
returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return
value check should be replaced with NULL test.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: Archit Taneja <archit@ti.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Reviewed-by: Archit Taneja <archit@ti.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Add support for the de-interlacer block in VPE. For de-interlacer to
work, we need to enable 2 more sets of VPE input ports which fetch data
from the 'last' and 'last to last' fields of the interlaced video. Apart
from that, we need to enable the Motion vector output and input ports,
and also allocate DMA buffers for them.
We need to make sure that two most recent fields in the source queue are
available and in the 'READY' state. Once a mem2mem context gets access
to the VPE HW(in device_run), it extracts the addresses of the 3
buffers, and provides it to the data descriptors for the 3 sets of input
ports((LUMA1, CHROMA1), (LUMA2, CHROMA2), and (LUMA3, CHROMA3))
respectively for the 3 consecutive fields. The motion vector and output
port descriptors are configured and the list is submitted to VPDMA.
Once the transaction is done, the v4l2 buffer corresponding to the
oldest field(the 3rd one) is changed to the state 'DONE', and the
buffers corresponding to 1st and 2nd fields become the 2nd and 3rd field
for the next de-interlace operation. This way, for each deinterlace
operation, we have the 3 most recent fields. After each transaction, we
also swap the motion vector buffers, the new input motion vector buffer
contains the resultant motion information of all the previous frames,
and the new output motion vector buffer will be used to hold the updated
motion vector to capture the motion changes in the next field. The
motion vector buffers are allocated using the DMA allocation API.
The de-interlacer is removed from bypass mode, it requires some extra
default configurations which are now added. The chrominance upsampler
coefficients are added for interlaced frames. Some VPDMA parameters like
frame start event and line mode are configured for the 2 extra sets of
input ports.
Signed-off-by: Archit Taneja <archit@ti.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
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.
When the list is parsed completely(and the DMAs on all the output ports
done), an interrupt is generated which we use to notify that the source
and destination buffers are done. The rest of the driver is quite
similar to other mem2mem drivers, we use the multiplane v4l2 ioctls as
the HW support coplanar formats.
Signed-off-by: Archit Taneja <archit@ti.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Create functions which the VPE driver can use to create a VPDMA
descriptor and add it to a VPDMA descriptor list. These functions take a
pointer to an existing list, and append the configuration/data/control
descriptor header to the list.
In the case of configuration descriptors, the creation of a payload
block may be required(the payloads can hold VPE MMR values, or scaler
coefficients). The allocation of the payload buffer and it's content is
left to the VPE driver. However, the VPDMA library provides helper
macros to create payload in the correct format.
Add debug functions to dump the descriptors in a way such that it's easy
to see the values of different fields in the descriptors.
Signed-off-by: Archit Taneja <archit@ti.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
The primary function of VPDMA is to move data between external memory
and internal processing modules(in our case, VPE) that source or sink
data. VPDMA is capable of buffering this data and then delivering the
data as demanded to the modules as programmed. The modules that source
or sink data are referred to as clients or ports. A channel is setup
inside the VPDMA to connect a specific memory buffer to a specific
client. The VPDMA centralizes the DMA control functions and buffering
required to allow all the clients to minimize the effect of long latency
times.
Add the following to the VPDMA helper:
- A data struct which describe VPDMA channels. For now, these channels
are the ones used only by VPE, the list of channels will increase when
VIP(Video Input Port) also uses the VPDMA library. This channel
information will be used to populate fields required by data
descriptors.
- Data structs which describe the different data types supported by
VPDMA. This data type information will be used to populate fields
required by data descriptors and used by the VPE driver to map a V4L2
format to the corresponding VPDMA data type.
- Provide VPDMA register offset definitions, functions to read, write
and modify VPDMA registers.
- Functions to create and submit a VPDMA list. A list is a group of
descriptors that makes up a set of DMA transfers that need to be
completed. Each descriptor will either perform a DMA transaction to
fetch input buffers and write to output buffers(data descriptors), or
configure the MMRs of sub blocks of VPE(configuration descriptors), or
provide control information to VPDMA (control descriptors).
- Functions to allocate, map and unmap buffers needed for the descriptor
list, payloads containing MMR values and scaler coefficients. These use
the DMA mapping APIs to ensure exclusive access to VPDMA.
- Functions to enable VPDMA interrupts. VPDMA can trigger an interrupt
on the VPE interrupt line when a descriptor list is parsed completely
and the DMA transactions are completed. This requires masking the events
in VPDMA registers and configuring some top level VPE interrupt
registers.
- Enable some VPDMA specific parameters: frame start event(when to start
DMA for a client) and line mode(whether each line fetched should be
mirrored or not).
- Function to load firmware required by VPDMA. VPDMA requires a firmware
for it's internal list manager. We add the required request_firmware
apis to fetch this firmware from user space.
- Function to dump VPDMA registers.
- A function to initialize and create a VPDMA instance, this will be
called by the VPE driver with it's platform device pointer, this
function will take care of loading VPDMA firmware and returning a
vpdma_data instance back to the VPE driver. The VIP driver will also
call the same init function to initialize it's own VPDMA instance.
Signed-off-by: Archit Taneja <archit@ti.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Archit Taneja