Pull media updates from Mauro Carvalho Chehab:
- a new jpeg codec driver for Samsung Exynos (jpeg-hw-exynos4)
- a new dvb frontend for ds2103 chipset (m88ds2103)
- a new sensor driver for Samsung S5K5BAF UXGA (s5k5baf)
- new drivers for R-Car VSP1
- a new radio driver: radio-raremono
- a new tuner driver for ts2022 chipset (m88ts2022)
- the analog part of em28xx is now a separate module that only
load/runs if the device is not a pure digital TV device
- added a staging driver for bcm2048 radio devices
- the omap 2 video driver (omap24xx) was moved to staging. This driver
is for an old hardware and uses a deprecated Kernel internal API. If
nobody cares enough to fix it, it would be removed on a couple Kernel
releases
- the sn9c102 driver was moved to staging. This driver was replaced by
gspca, and disabled on some distros, as almost all devices are known
to work properly with gspca. It should be removed from kernel on a
couple Kernel releases
- lots of driver fixes, improvements and cleanups
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (421 commits)
[media] media: v4l2-dev: fix video device index assignment
[media] rc-core: reuse device numbers
[media] em28xx-cards: properly initialize the device bitmap
[media] Staging: media: Fix line length exceeding 80 characters in as102_drv.c
[media] Staging: media: Fix line length exceeding 80 characters in as102_fe.c
[media] Staging: media: Fix quoted string split across line in as102_fe.c
[media] media: st-rc: Add reset support
[media] m2m-deinterlace: fix allocated struct type
[media] radio-usb-si4713: fix sparse non static symbol warnings
[media] em28xx-audio: remove needless check before usb_free_coherent()
[media] au0828: Fix sparse non static symbol warning
Revert "[media] go7007-usb: only use go->dev after allocated"
[media] em28xx-audio: provide an error code when URB submit fails
[media] em28xx: fix check for audio only usb interfaces when changing the usb alternate setting
[media] em28xx: fix usb alternate setting for analog and digital video endpoints > 0
[media] em28xx: make 'em28xx_ctrl_ops' static
em28xx-alsa: Fix error patch for init/fini
[media] em28xx-audio: flush work at .fini
[media] drxk: remove the option to load firmware asynchronously
[media] em28xx: adjust period size at runtime
...
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>
Correct spelling typo in various part of kernel
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
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>
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>
