Lad, Prabhakar [Fri, 22 Mar 2013 07:53:13 +0000 (04:53 -0300)]
[media] media: davinci: vpbe: venc: move the enabling of vpss clocks to driver
The vpss clocks were enabled by calling a exported function from a driver
in a machine code. calling driver code from platform code is incorrect way.
This patch fixes this issue and calls the function from driver code itself.
Lad, Prabhakar [Fri, 22 Mar 2013 07:53:12 +0000 (04:53 -0300)]
[media] media: davinci: vpss: enable vpss clocks
By default the VPSS clocks were enabled in capture driver
for davinci family which creates duplicates for dm355/dm365/dm644x.
This patch adds support to enable the VPSS clocks in VPSS driver,
which avoids duplication of code and also adding clock aliases.
This patch uses PM runtime API to enable/disable clock, instead
of DaVinci clock framework. con_ids for master and slave clocks of
vpss is added in pm_domain.
This patch cleanups the VPSS clock enabling in the capture driver,
and also removes the clock alias in machine file. Along side adds
a vpss slave clock for DM365 as mentioned by Sekhar
(https://patchwork.kernel.org/patch/1221261/).
The Suspend/Resume in dm644x_ccdc.c which enabled/disabled the VPSS clock
is now implemented as part of the VPSS driver.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
drivers/media/platform/davinci/Kconfig uses selects where
it should be using 'depends on'. This results in warnings of
the following sort when doing randconfig builds.
warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI)
The VPIF kconfigs had a strange 'select' and 'depends on' cross
linkage which have been fixed as well by removing unneeded
VIDEO_DAVINCI_VPIF config symbol.
Similarly, remove the unnecessary VIDEO_VPSS_SYSTEM and
VIDEO_VPFE_CAPTURE. They don't select any independent functionality
and were being used to manage code dependencies which can
be handled using makefile.
Selecting video modules is now dependent on all ARCH_DAVINCI
instead of specific EVMs and SoCs earlier. This should help build
coverage. Remove unnecessary 'default y' for some config symbols.
While at it, fix the Kconfig help text to make it more readable
and fix names of modules created during module build.
Rename VIDEO_ISIF to VIDEO_DM365_ISIF as per suggestion from
Prabhakar.
This patch has only been build tested; I have tried to not break
any existing assumptions. I do not have the setup to test video,
so any test reports welcome.
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
[prabhakar.csengg@gmail.com: Fixed typo] Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Frank Schaefer [Thu, 11 Apr 2013 18:56:47 +0000 (15:56 -0300)]
[media] em28xx: improve em2710/em2820 distinction
Chip id 18 is used by the em2710 and em2820.
The current code assumes that if the device is a camera, the chip is an em2710
and an em2820 otherwise.
But it turned out that the em2820 is also used in camera devices.
"Silvercrest 1.3 MPix" webcams for example are available with both chips.
Fortunately both variants are using different generic USD IDs which give us a
hint about the used chip.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Frank Schaefer [Thu, 11 Apr 2013 18:56:01 +0000 (15:56 -0300)]
[media] em28xx: fix snapshot button support
The snapshot button support is currently broken, because module em28xx-rc is
loaded only if the device has remote control support.
Fix it by also loading this module if the device has a snapshot button.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Wed, 10 Apr 2013 17:26:52 +0000 (14:26 -0300)]
[media] hdpvr: allow g/s/enum/querystd when in legacy mode
Both MythTV and gstreamer expect that they can set/get/query/enumerate the
standards, even if the input is the component input for which standards
really do not apply.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sat, 6 Apr 2013 09:00:17 +0000 (06:00 -0300)]
[media] hdpvr: remove hdpvr_fh and just use v4l2_fh
This prepares the driver for priority and control event handling.
This patch also checks for correct streaming ownership and it makes a
small improvement to the encoder_cmd ioctls: always zero 'flags' and
drop the memset of 'raw' as that is already done by the v4l2 core.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Wed, 20 Mar 2013 17:31:34 +0000 (14:31 -0300)]
[media] v4l2-dv-timings.h: add 480i59.94 and 576i50 CEA-861-E timings
These formats are supported by the HDPVR, but they were missing in the list.
Note that these formats are different from the common PAL/NTSC/SECAM formats
since all color channels are transmitted separately and so there is no PAL
or NTSC or SECAM color encoding involved.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This was set to 1 << 0 which is the same as V4L2_DV_FL_REDUCED_BLANKING.
It should be 1 << 3 instead. Luckily interlaced formats are rarely used,
which is why this bug wasn't seen until now.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Mon, 8 Apr 2013 09:31:30 +0000 (06:31 -0300)]
[media] radio-si4713: use V4L2 core lock
Simplify locking by using the V4L2 core lock mechanism. This allows us to
remove all locking from the i2c module. This will also simplify the upcoming
conversion to the control framework.
Hans Verkuil [Wed, 3 Apr 2013 07:08:19 +0000 (04:08 -0300)]
[media] v4l2: drop V4L2_CHIP_MATCH_SUBDEV_NAME
After using the new VIDIOC_DBG_G_CHIP_NAME ioctl I realized that the matching
by name possibility is useless. Just drop it and rename MATCH_SUBDEV_IDX to
just MATCH_SUBDEV.
The v4l2-dbg utility is much better placed to match by name by just enumerating
all bridge and subdev devices until chip_name.name matches.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Wed, 27 Mar 2013 11:04:23 +0000 (08:04 -0300)]
[media] v4l2: put VIDIOC_DBG_G_CHIP_NAME under ADV_DEBUG
Only enable this ioctl if the VIDEO_ADV_DEBUG config option is set. This
prevents abuse from both userspace and kernelspace (some bridge drivers
abuse DBG_G_CHIP_IDENT, lets prevent that from happening again with this
ioctl).
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sat, 6 Apr 2013 07:41:29 +0000 (04:41 -0300)]
[media] tuner-core/simple: get_rf_strength can be tuner mode specific
The get_rf_strength op in tuner-simple is valid only for the radio mode.
But due to the way get_signal in analog_demod_ops was designed it would
overwrite the signal value with a bogus value when in TV mode.
Pass a pointer to the signal value instead, and when not in radio mode
leave it alone in the tuner-simple.
This broke in commit 030755bde42bbed133182b0ece7c7a9c759478e8
(tuner-core: call has_signal for both TV and radio) in kernel 3.6. Before
that this was working correctly. That commit did the right thing, but what
wasn't realized at the time was that tuner-simple should have been updated
as well to restrict setting the signal strength to the radio mode only.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Hans Verkuil [Sat, 6 Apr 2013 07:35:27 +0000 (04:35 -0300)]
[media] tuner-core/tda9887: get_afc can be tuner mode specific
The get_afc op in tda9887 is valid only for the radio mode.
But due to the way get_afc in analog_demod_ops was designed it would
overwrite the afc value with a bogus value when in TV mode.
Pass a pointer to the afc value instead, and when not in radio mode
leave it alone in the tda9887.
This broke a long time ago in 2.6.19 when the get_afc op was introduced.
Before that the afc was only set for radio mode in the tda9887.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Ondrej Zary [Fri, 1 Feb 2013 23:01:16 +0000 (20:01 -0300)]
[media] saa7134: v4l2-compliance: use v4l2_fh to fix priority handling
Make saa7134 driver more V4L2 compliant: remove broken priority handling
and use v4l2_fh instead
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
[hans.verkuil@cisco.com: fixed a merge conflict in saa7134.h] Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Enable the regulators when powering the sensor up, and disable them when
powering it down.
The regulators are mandatory. Boards that don't allow controlling the
sensor power lines must provide fixed voltage regulators.
The MT9M032 PLL was assumed to be identical to the MT9P031 PLL but
differs significantly. Update the registers definitions and PLL limits
according to the datasheet.
[media] exynos4-is: Remove meaningless test before bit setting
There is no need to check same bit before setting it, since we
always end up with a bit set. Remove some of the tests and make
set unconditional, in every place where all that needs to be done
is just setting a bit.
[media] exynos4-is: Improve the ISP chain parameter count calculation
Instead of incrementing p_region_num field each time we set a bit
in the parameter mask calculate the number of bits set only when
this information is needed.
[media] exynos4-is: Make fimc-lite independent of struct fimc_sensor_info
Make the sensor subdevs host_data hold a pointer to struct fimc_source_info,
which is defined in the driver's public header, rather than a pointer to
struct fimc_sensor_info which is specific to exynos4-is media device driver.
The purpose of this change is to allow easier reuse of the fimc-lite module
in the exynos5-is driver, which should similarly store a pointer to struct
fimc_source_info instance in the sensor's subdev host_data.
[media] exynos4-is: Make fimc-lite independent of the pipeline->subdevs array
Get the sensor subdev by walking media graph in both cases: when the
device is used as a subdev only and through video node. This allows
to not dereference the pipeline->subdevs[] array and makes the module
more generic and easier to re-use in other media driver.
[media] exynos4-is: Move the subdev group ID definitions to public header
Move the sub-device group ID definitions to the driver's public header
so they are available to other media drivers that need to share modules
found in exynos4-is.
Make sure mem_info[] array is not used uninitialized. This prevents
following compiler warning:
drivers/media/platform/s5p-mfc/s5p_mfc.c: In function s5p_mfc_probe:
drivers/media/platform/s5p-mfc/s5p_mfc.c:1032:33: warning: mem_info[0] may be used uninitialized in this function [-Wuninitialized]
drivers/media/platform/s5p-mfc/s5p_mfc.c:1021:15: note: mem_info[0] was declared here
drivers/media/platform/s5p-mfc/s5p_mfc.c:1032:33: warning: mem_info[1] may be used uninitialized in this function [-Wuninitialized]
drivers/media/platform/s5p-mfc/s5p_mfc.c:1021:15: note: mem_info[1] was declared here
Fix for this compiler warning:
CC [M] drivers/media/i2c/s5c73m3/s5c73m3-core.o
drivers/media/i2c/s5c73m3/s5c73m3-core.c: In function ‘s5c73m3_load_fw’:
drivers/media/i2c/s5c73m3/s5c73m3-core.c:360:2: warning: format ‘%d’ expects
argument of type ‘int’, but argument 4 has type ‘size_t’ [-Wformat]
Kamil Debski [Fri, 11 Jan 2013 15:29:33 +0000 (12:29 -0300)]
[media] s5p-mfc: Add support for EOS command and EOS event in video decoder
Add support for V4L2_DEC_CMD_STOP command which will instruct MFC device
to finish decoding and release all remaining frames kept for reference to
the user. After dequeueing last decoded frame the driver will generate an
V4L2_EVENT_EOS event.
[media] cx24123: improve precision when calculating symbol rate ratio
Symbol rate ratio were using a rough calculus, as the code was
limited to 32 bits arithmetic. Change it to 64 bits, in order
to better estimate the bandwidth low-pass filter on the demod.
This should reduce the noise and improve reception.
[media] mb86a20s: better name temp vars at mb86a20s_layer_bitrate()
Using 'i' for the guard interval temporary var is a bad idea, as
'i' is generally used by "anonymous" indexes.
Let's rename modulation, fec and guard interval temp vars with
a meaningful name, as that makes easier to understand the code
and avoids cut-and-paste types of error.
As reported by Dan Carpenter <dan.carpenter@oracle.com>:
Smatch warnings:
drivers/media/dvb-frontends/mb86a20s.c:644 mb86a20s_layer_bitrate() error: buffer overflow 'state->estimated_rate' 3 <= 3
What happens there is that estimate_rate index should be the layer
number, and not the guard interval.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] mb86a20s: Use 'layer' instead of 'i' on all places
We're using the anonymous 'i' to indicate the layer number
on several places on the driver. That's not good, as some
cut-and-paste type of change might be doing the wrong thing.
So, call it as "layer" everywhere.
[media] mb86a20s: Use a macro for the number of layers
Instead of using the magic number "3", use NUM_LAYERS macro
on all places that are related to the ISDB-T layers.
This makes the source code a little more readable.
No functional changes.
Ondrej Zary [Sat, 6 Apr 2013 17:21:36 +0000 (14:21 -0300)]
[media] tuner-core: Change config from unsigned int to void *
config looks like a hack that was added to tuner-core to allow some
configuration of TDA8290 tuner (it's not used by any other driver).
But with the new configuration options of tda8290 driver (no_i2c_gate
and std_map), it's no longer sufficient.
Change config to be void * instead, which allows passing tuner-dependent
config struct to drivers.
Also update saa7134 driver to reflect this change (no other driver uses this).
Signed-off-by: Ondrej Zary <linux@rainbow-software.org> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Ondrej Zary [Mon, 4 Feb 2013 01:48:56 +0000 (22:48 -0300)]
[media] tda8290: Allow custom std_map for tda18271
Allow specifying a custom std_map for tda18271 by external configuration.
This is required by cards that require custom std_map for analog TV or radio,
like AverMedia A706.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] cx88: kernel bz#9476: Fix tone setting for Nova-S+ model 92001
Hauppauge Nova-S-Plus DVB-S model 92001 does not lock on horizontal
polarisation. According with the info provided at the BZ, model
92002 does.
The difference is that, on model 92001, the tone select is done via
isl6421, while, on other devices, this is done via cx24123 code.
This patch adds a way to override the demod's set_tone at isl6421
driver. In order to avoid regressions, the override is enabled
only for cx88 Nova S plus model 92001. For all other models and
devices, the set_tone is provided by the demod driver.
Patch originally proposed at bz@9476[1] by Michel Meyers and
John Donoghue but applying the original patch would break support
for all other devices based on isl6421.
rc_unregister_device already calls rc_free_device to free the passed
device. But in one of ttusbir's probe fail paths, we call
rc_unregister_device _and_ rc_free_device. This is wrong and results
in a double free.
Instead, set rc to NULL resulting in rc_free_device being a noop.
"enum dmx_ts_pes" and "typedef enum dmx_pes_type_t" are just the
same enum declared twice, since Kernel (2.6.12). There's no reason
to duplicate it there, and sparse complains about that:
drivers/media/dvb-core/dmxdev.c:600:55: warning: mixing different enum types
So, remove the internal define, keeping just the external one.
Internally, use only "enum dmx_ts_pes", as it is too late to drop
dmx_pes_type_t from the userspace API.
[media] exynos4-is: Ensure proper media pipeline state on device close
Make sure media_entity_pipeline_stop() is called on video device
close in cases where there was VIDIOC_STREAMON ioctl and no
VIDIOC_STREAMOFF. This patch fixes media entities stream_count
state which could prevent links from being disconnected, due to
non-zero stream_count.
[media] exynos4-is: Correct input DMA YUV order configuration
This patch fixes erroneous setup of the YUV order caused by not
clearing FIMC_REG_MSCTRL_ORDER422_MASK bit field before setting
proper FIMC_REG_MSCTRL_ORDER422 bits. This resulted in false
colors for YUYV, YVYU, UYVY, VYUY color formats, depending in
what sequence those were configured by user space.
YUV order definitions are corrected so that following convention
is used:
| byte3 | byte2 | byte1 | byte0
-------+-------+-------+-------+------
YCBYCR | CR | Y | CB | Y
YCRYCB | CB | Y | CR | Y
CBYCRY | Y | CR | Y | CB
CRYCBY | Y | CB | Y | CR
[media] exynos4-is: Allow colorspace conversion at FIMC-LITE
The FIMC-LITE output DMA allows to configure different YUV order
than the order at the camera input interface. Thus there is some
limited colorspace conversion possible. This patch makes the
color format variable be per FIMC-LITE input/output, rather than
a global per device. This also fixes incorrect behavior where
color format at the FIMC-LITE.N subdev's source pad is modified
by VIDIOC_S_FMT ioctl on the related video node.
YUV order definitions are corrected so that we use notation:
| byte3 | byte2 | byte1 | byte0
-------+-------+-------+-------+------
YCBYCR | CR | Y | CB | Y
YCRYCB | CB | Y | CR | Y
CBYCRY | Y | CR | Y | CB
CRYCBY | Y | CB | Y | CR
[media] exynos4-is: Use common driver data for all FIMC-LITE IP instances
There is no need to use separate variant data structure for each
FIMC-LITE IP instance. According to my knowledge there are no
differences across them on Exynos4 as well as Exynos5 SoCs. Drop
flite_variant data structure and use struct flite_drvdata instead.
[media] exynos4-is: Remove static driver data for Exynos4210 FIMC variants
The Exynos platform will support only device tree based booting
from v3.10. The FIMC variant data will be parsed directly from
the device tree, hence the now unused static data can be removed.
This patch adds support for registration of the FIMC-IS device
represented by the FIMC-IS-ISP subdev to the top level media device
driver. The FIMC-IS subsystem is available on Exynos4x12 SoCs which
support only device tree based booting.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
[media] exynos4-is: Add common FIMC-IS image sensor driver
This patch adds a common image sensor driver and Makefile/Kconfig
to enable compilation of the whole IS driver.
The sensor subdev driver currently only handles an image sensor's
power supplies and reset signal. There is no I2C communication as
it is handled by the ISP's firmware.
[media] exynos4-is: Add FIMC-IS ISP I2C bus driver
This patch adds the ISP I2C bus controller driver files.
Creating a standard I2C bus adapter, even if the driver doesn't
actually communicate with the hardware and it is instead
controlled by the ISP firmware running on the Cortex-A5, allows
to use standard hardware description in the device tree. As the
sensor would have actually had a standard V4L2 sub-device driver
run on the host CPU.
This approach allows to adapt the driver with a relatively small
effort should the Imaging Subsystem architecture change so that
the I2C bus is handled by the host's CPU OS, rather than the
internal FIMC-IS ARM CPU firmware. The image sensor driver could
be a standard I2C client driver, as in case of most existing
image sensors.
This patch adds a set of core files of the Exynos4x12 FIMC-IS
V4L2 driver. This includes main functionality like allocating
memory, loading the firmware, FIMC-IS register interface and
host CPU <-> IS command and error code definitions.
The driver currently exposes a single subdev named FIMC-IS-ISP,
which corresponds to the FIMC-IS ISP and DRC IP blocks.
The FIMC-IS-ISP subdev currently supports only a subset of user
controls. For other controls we need several extensions at the
V4L2 API. The supported standard controls are:
brightness, contrast, saturation, hue, sharpness, 3a_lock,
exposure_time_absolute, white_balance_auto_preset,
iso_sensitivity, iso_sensitivity_auto, exposure_metering_mode.
[media] V4L: Remove incorrect EXPORT_SYMBOL() usage at v4l2-of.c
v4l2_of_parse_parallel_bus() function is now static and
EXPORT_SYMBOL() doesn't apply to it any more. Drop this
meaningless statement, which was supposed to be done in
the original merged patch.
While at it, edit the copyright notice so it is sorted in
both the v4l2-of.c and v4l2-of.h file in newest entries
on top order, and state clearly I'm just the author of
parts of the code, not the copyright owner.
[media] exynos4-is: Correct clock properties description at the DT binding documentation
The 'camera' DT node needs to have sclk_cam0/1 and pxl_async0/1 clocks
specified, while 'fimc' nodes should have only "fimc" and "sclk_fimc".
"mux" and "parent" are leftovers from early versions of patches adding
DT support, when the IP bus clock parent clock was being set by the
driver. A better solution is needed to have e.g. clocks driver setting
all required parent clocks, before clock consumers start using the
clocks. Currently this binding doesn't describe parent clocks setup,
it needs to be specified and handled somewhere else.
[media] exynos4-is: Remove dependency on SYSCON for non-dt platforms
Currently the whole driver depends on MFD_SYSCON, which in turn
depends on OF. To allow to use the driver on non-dt platforms
(S5PV210) the SYSREG support is made conditional (it is needed
only for dt enabled platforms) and MFD_SYSCON is selected if
OF is enabled, instead of depending on OF.
In multiplatform configurations, we cannot include headers
provided by only the exynos platform. Fortunately a number
of drivers that include those headers do not actually need
them, so we can just remove the inclusions.
projects / karo-tx-linux.git / log