On 6 July 2012 08:43, Sascha Hauer wrote:
> Hi Javier,
>
> On Fri, Jul 06, 2012 at 08:31:49AM +0200, Javier Martin wrote:
>> This driver wasn't converted to the new clock changes
>> (clk_prepare_enable/clk_disable_unprepare). Also naming
>> of emma-prp related clocks for the i.MX27 was not correct
Hi Javier,
On Fri, Jul 06, 2012 at 08:31:49AM +0200, Javier Martin wrote:
> This driver wasn't converted to the new clock changes
> (clk_prepare_enable/clk_disable_unprepare). Also naming
> of emma-prp related clocks for the i.MX27 was not correct.
Thanks for fixing this. Sorry for breaking this
This driver wasn't converted to the new clock changes
(clk_prepare_enable/clk_disable_unprepare). Also naming
of emma-prp related clocks for the i.MX27 was not correct.
Signed-of-by: Javier Martin
---
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index 295cbd7..e8a601
Hi Kamil,
The patch for videodev2.h is already posted by Jeongtae Park and is under
review. [1]
Now as suggested by you, I will send that patch again and also by incorporating
the review comments given there.
[1]
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/45190
R
Em 24-06-2012 22:44, Douglas Bagnall escreveu:
> hi,
>
> I probably should have sent that in reply to
> http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/49740
> which is the problem it fixes.
>
> Some things which might be of interest:
>
> 1. I innocently followed the inst
Em 24-06-2012 21:00, Douglas Bagnall escreveu:
> For some reason, when the lirc daemon learns that a usb remote control
> has been unplugged, it wants to read the sysfs attributes of the
> disappearing device. This is useful for uncovering transient
> inconsistencies, but less so for keeping the sy
The logic that checks if a device has remote control is wrong.
Due to that, the em28xx RC module is not loaded by default.
Fix the logic, in order to make it work properly.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/video/em28xx/em28xx-cards.c |2 +-
1 file changed, 1 insertion(
The firmwares are there at the same place for a long time. However,
each time I need to remember where it is, I need to seek at the net.
The better is to just add a logic at the get_dvb_firmare script,
in order to obtain it from a reliable source.
Cc: Steven Toth
Signed-off-by: Mauro Carvalho Ch
Em 05-07-2012 19:36, Sylwester Nawrocki escreveu:
> On 07/06/2012 12:11 AM, Mauro Carvalho Chehab wrote:
>>> +static int vidioc_dqbuf(struct file *file, void *priv, struct v4l2_buffer
>>> *p)
>>> +{
>>> + struct stk1160 *dev = video_drvdata(file);
>>> +
>>> + if (!stk1160_is_owner(dev, file))
On 07/06/2012 12:11 AM, Mauro Carvalho Chehab wrote:
>> +static int vidioc_dqbuf(struct file *file, void *priv, struct v4l2_buffer
>> *p)
>> +{
>> +struct stk1160 *dev = video_drvdata(file);
>> +
>> +if (!stk1160_is_owner(dev, file))
>> +return -EBUSY;
>> +
>> +return vb2_d
Em 05-07-2012 18:31, Ezequiel Garcia escreveu:
> On Thu, Jul 5, 2012 at 6:21 PM, Sakari Ailus wrote:
>>
>> There was a discussion between Ezequiel and Hans that in my understanding
>> led to a conclusion there's no such use case, at least one which would be
>> properly supported by the hardware. (
Hi Guennadi,
Thanks for the patch.
On Friday 22 June 2012 18:40:08 Guennadi Liakhovetski wrote:
> Add .get_selection() and .set_selection() soc-camera host driver
> operations. Additionally check, that the user is not trying to change the
> output sizes during a running capture.
How will that in
Em 05-07-2012 18:21, Sakari Ailus escreveu:
> Hi Mauro,
>
> Mauro Carvalho Chehab wrote:
>> Em 10-06-2012 17:22, Sakari Ailus escreveu:
>>> Hi Mauro,
>>>
>>> Here are two V4L2 API cleanup patches; the first removes __user from
>>> videodev2.h from a few places, making it possible to use the header
On Thu, Jul 5, 2012 at 6:21 PM, Sakari Ailus wrote:
>
> There was a discussion between Ezequiel and Hans that in my understanding
> led to a conclusion there's no such use case, at least one which would be
> properly supported by the hardware. (Please correct me if I'm mistaken.)
>
Concerning stk
Hi Mauro,
Mauro Carvalho Chehab wrote:
Em 10-06-2012 17:22, Sakari Ailus escreveu:
Hi Mauro,
Here are two V4L2 API cleanup patches; the first removes __user from
videodev2.h from a few places, making it possible to use the header file
as such in user space, while the second one changes the
v4l
Hi Michael,
Thanks for the patch.
On Wednesday 27 June 2012 17:06:57 Michael Jones wrote:
> Signed-off-by: Michael Jones
> ---
> drivers/media/video/omap3isp/ispqueue.c |9 ++---
> 1 files changed, 2 insertions(+), 7 deletions(-)
>
> This comment looks like it was a copy-paste from the
Em 10-06-2012 17:22, Sakari Ailus escreveu:
> Hi Mauro,
>
> Here are two V4L2 API cleanup patches; the first removes __user from
> videodev2.h from a few places, making it possible to use the header file
> as such in user space, while the second one changes the
> v4l2_buffer.input field back to re
Em 11-06-2012 06:39, Sakari Ailus escreveu:
> On Mon, Jun 11, 2012 at 09:50:54AM +0200, Laurent Pinchart wrote:
>> Hi Sakari,
>>
>> On Sunday 10 June 2012 23:22:59 Sakari Ailus wrote:
>>> Hi Mauro,
>>>
>>> Here are two V4L2 API cleanup patches; the first removes __user from
>>> videodev2.h from a f
There will be no soc_camera_device instance with a soc-camera device is
used with a non soc-camera host, so we won't be able to pass the
soc_camera_device fake platform device to board code. Pass the physical
device instead.
The argument is currently not used by any board file so this is safe.
Si
The .s_power() call only covers the .g_mbus_fmt() operation call.
Several clients required to be powered on to retrieve the current mbus
format but have now been fixed. The .s_power() call is thus not needed
anymore and can be removed.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/soc_
Powering off a device is a "best effort" task: failure to execute one of
the steps should not prevent the next steps to be executed. For
instance, an I2C communication error when putting the chip in stand-by
mode should not prevent the more agressive next step of turning the
chip's power supply off
Several client drivers access the hardware at probe time, for instance
to read the probe chip ID. Such chips need to be powered up when being
probed.
soc-camera handles this by powering chips up in the soc-camera probe
implementation. However, this will break with non soc-camera hosts that
don't p
Instead of forcing all soc-camera drivers to go through the mid-layer to
handle power management, create soc_camera_power_[on|off]() functions
that can be called from the subdev .s_power() operation to manage
regulators and platform-specific power handling. This allows non
soc-camera hosts to use s
The g_mbus_fmt operation only needs to return the current mbus frame
format and doesn't need to configure the hardware to do so. Fix it to
avoid requiring the chip to be powered on when calling the operation.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/tw9910.c |8 +++-
1 fil
The g_mbus_fmt operation only needs to return the current mbus frame
format and doesn't need to configure the hardware to do so. Fix it to
avoid requiring the chip to be powered on when calling the operation.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/ov2640.c |6 ++
1 files
The g_mbus_fmt operation only needs to return the current mbus frame
format and doesn't need to configure the hardware to do so. Fix it to
avoid requiring the chip to be powered on when calling the operation.
Signed-off-by: Laurent Pinchart
---
drivers/media/video/ov772x.c |8 ++--
1 fil
Here's the second version of the miscellaneous soc-camera patches that try to
improve the interoperability between soc-camera clients and non soc-camera
hosts.
As with the previous version, all patches have been compile-tested but not
runtime-tested as I lack the necessary hardware.
Changes compa
The soc-camera module exports functions that are needed by soc-camera
client drivers even when not running in soc-camera mode. Replace the
platform_driver_probe() with a platform_driver_register() call to avoid
module load failures if no soc-camera device is present.
Signed-off-by: Laurent Pinchar
Em 05-07-2012 14:37, Bert Massop escreveu:
> On Thu, Jul 5, 2012 at 5:05 PM, Antti Palosaari wrote:
>>
>> On 07/05/2012 05:16 PM, Mauro Carvalho Chehab wrote:
>>>
>>> Implement API support to return AFC frequency shift, as this device
>>> supports it. The only other driver that implements it is td
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date:Thu Jul 5 19:00:23 CEST 2012
git hash:e9da6b3ca5a6a0df8c8b790d8f1f4b232bed2a6b
gcc version: i686-linux-gcc (GC
The preview engine crops 4 columns and 4 lines when CFA is enabled.
Commit b2da46e52fe7871cba36e1a435844502c0eccf39 ("omap3isp: preview: Add
support for greyscale input") inverted the condition by mistake, fix
this.
Reported-by: Florian Neuhaus
Signed-off-by: Laurent Pinchart
---
drivers/media/
On Thu, Jul 5, 2012 at 5:05 PM, Antti Palosaari wrote:
>
> On 07/05/2012 05:16 PM, Mauro Carvalho Chehab wrote:
>>
>> Implement API support to return AFC frequency shift, as this device
>> supports it. The only other driver that implements it is tda9887,
>> and the frequency there is reported in H
Hi Hans-Petter,
On Monday 02 July 2012 21:07:56 Hans Petter Selasky wrote:
> Hi Laurent and Sakari,
>
> For the sake of the matter, here is the driver in question:
> http://www.freshports.org/multimedia/webcamd/
>
> Under native-Linux (kernel mode):
>
> I've looked at the linux-media code a bit
Hi Mauro,
On Thu, Jul 5, 2012 at 1:57 PM, Mauro Carvalho Chehab
wrote:
>>
>> snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
>> dev->adev.capture_pcm_substream = substream;
>> - runtime->private_data = dev;
>
>
> Are you sure that this can be removed? I think
xc5000 is just a tuner, not a decoder, so both DMB-TH and ISDB-T should
work properly there: it is just a matter of teaching the driver what
saw filter should be used and how to calculate the center frequency.
Requested-by: Choi Wing Chan
Cc: Steven Toth
Cc: Devin Heitmueller
Signed-off-by: Mau
Em 12-06-2012 10:53, Ezequiel Garcia escreveu:
> Signed-off-by: Ezequiel Garcia
> ---
> drivers/media/video/em28xx/em28xx-audio.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/video/em28xx/em28xx-audio.c
> b/drivers/media/video/em28xx/em28xx-audio
Em 04-07-2012 02:01, Hadli, Manjunath escreveu:
> Mauro,
> Can you please pull the patches? Let me know if anything needs to be done
> from my side.
>
> -Manju
>
>
> On Thu, May 31, 2012 at 17:42:24, Hadli, Manjunath wrote:
>> Mauro,
>> The following patch set adds the media controller based d
Hi Michael,
On Tuesday 03 July 2012 11:46:33 Michael Jones wrote:
> Hi Laurent & co.,
>
> I'm looking at the memory limitations in the omap3isp driver. 'struct
> isp_video' contains member 'capture_mem', which is set separately for each
> of our v4l2 video device nodes. The CCDC, for example, has
Hi Florian,
On Thursday 05 July 2012 16:06:03 Florian Neuhaus wrote:
> Laurent Pinchart wrote on 2012-07-05:
> >> When I now capture a frame with yavta (see [3] for details), I must use
> >> 846x639 as frame size (as this size is reported by the driver). But it
> >> seems that the outputted image
Hi Michael,
Please fix the DocBooc Index entries for ATSC/MH:
Error: no ID for constraint linkend: atscmh-sccc-block-mode.
Error: no ID for constraint linkend: atscmh-sccc-code-mode.
Error: no ID for constraint linkend: atscmh-rs-frame-ensemble.
Error: no ID for constraint linkend: atscmh-rs-fram
Em 05-07-2012 11:35, Antti Palosaari escreveu:
> On 07/05/2012 05:32 PM, Mauro Carvalho Chehab wrote:
>> Em 18-05-2012 15:47, Thomas Mair escreveu:
>>> +static const int reg_mask[32] = {
>>> +0x0001,
>>> +0x0003,
>>> +0x0007,
>>> +0x000f,
>>> +0x001f,
>>> +
Em 05-07-2012 11:41, Antti Palosaari escreveu:
> On 07/05/2012 05:32 PM, Mauro Carvalho Chehab wrote:
>> Em 18-05-2012 15:47, Thomas Mair escreveu:
>
>>> +static int rtl2832_read_signal_strength(struct dvb_frontend *fe, u16
>>> *strength)
>>> +{
>>> +*strength = 0;
>>> +return 0;
>>> +}
>
Em 05-07-2012 11:31, Devin Heitmueller escreveu:
> On Thu, Jul 5, 2012 at 10:25 AM, Devin Heitmueller
> wrote:
>> On Thu, Jul 5, 2012 at 10:16 AM, Mauro Carvalho Chehab
>>> - /* Use both frq_lock and signal to generate the result */
>>> - signal = signal || ((signal & 0x07) << 12);
>>>
In kernel 2.6.33 request_firmware_nowait() gained a new parameter to set
the memory allocation flags.
We have to remove this parameter to make the drxk driver (the only user of
request_firmware_nowait() so far) compilable again with kernels older
than 2.6.33.
Signed-off-by: Gianluca Gennari
---
Hi Arun,
First of all - your patch is incomplete. I cannot find a
modified videodev2.h file. Compilation fails with a lot of
undefined symbols - attached below.
Please supply this file, then I will be able to provide you with
more comments and a proper review.
Best wishes,
--
Kamil Debski
Linux
On 07/05/2012 06:08 PM, Hans de Goede wrote:
Hi,
On 07/05/2012 04:13 PM, Antti Palosaari wrote:
On 07/05/2012 04:41 PM, Hans de Goede wrote:
Hi,
On 07/05/2012 03:35 PM, Antti Palosaari wrote:
I believe you're doing something wrong ...
I compiled radio from http://git.linuxtv.org/xawtv3.
Hi,
On 07/05/2012 04:13 PM, Antti Palosaari wrote:
On 07/05/2012 04:41 PM, Hans de Goede wrote:
Hi,
On 07/05/2012 03:35 PM, Antti Palosaari wrote:
I believe you're doing something wrong ...
I compiled radio from http://git.linuxtv.org/xawtv3.git to tune and
> "arecord -r96000 -c2 -f S
On 07/05/2012 05:16 PM, Mauro Carvalho Chehab wrote:
Implement API support to return AFC frequency shift, as this device
supports it. The only other driver that implements it is tda9887,
and the frequency there is reported in Hz. So, use Hz also for this
tuner.
What is AFC and why it is needed?
David, i see your point - as i mentioned i have no any knowledge of IR
receiver part you're discussing and/or its Linux drivers and don't
want just to spam, but my simple thinking is that if the Logitech
Harmony universal remote control is with wrongly configured firmware
it can emit something that
On Thu, 5 Jul 2012 17:39:18 +0300, Konstantin Dimitrov
wrote:
> excuse me for my ignorance, but don't you think adjusting the IR
> receiver to universal remote control is fundamentally wrong, while the
> whole point of universal remote control like Logitech Harmony is to be
> adjusted to the IR re
On 07/05/2012 05:32 PM, Mauro Carvalho Chehab wrote:
Em 18-05-2012 15:47, Thomas Mair escreveu:
+static int rtl2832_read_signal_strength(struct dvb_frontend *fe, u16 *strength)
+{
+ *strength = 0;
+ return 0;
+}
Why to implement the above, if they're doing nothing?
Other your f
hi David,
excuse me for my ignorance, but don't you think adjusting the IR
receiver to universal remote control is fundamentally wrong, while the
whole point of universal remote control like Logitech Harmony is to be
adjusted to the IR receiver and be able to be adjusted to any IR
receiver and not
These new controls and two new ioctls make it possible to properly support
VGA, DVI-A/D/I, HDMI and DisplayPort connectors. All these controls and the
ioctls are all at the sub-device level. They are meant for V4L2 bridge/platform
drivers or to be accessed on embedded systems through /dev/v4l-subde
Signed-off-by: Hans Verkuil
---
drivers/media/video/v4l2-ctrls.c | 39 ++
1 file changed, 39 insertions(+)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 9abd9ab..a664795 100644
--- a/drivers/media/video/v4l2-ctrls.c
+
Hi all,
This RFC patch series builds on an earlier RFC patch series (posted only to
linux-media) that adds support for DVI/HDMI/DP connectors to the V4L2 API.
This earlier patch series is here:
http://www.spinics.net/lists/linux-media/msg48529.html
The first 3 patches are effectively un
Signed-off-by: Hans Verkuil
---
Documentation/DocBook/media/v4l/controls.xml | 149 +++
Documentation/DocBook/media/v4l/v4l2.xml |1 +
.../DocBook/media/v4l/vidioc-subdev-g-edid.xml | 152
3 files changed, 302 insertions(+)
create mo
These two helper functions detect whether the analog video timings detected
by the video receiver match the VESA CVT or GTF standards.
They basically do the inverse of the CVT and GTF modeline calculations.
This patch also adds a helper function that will determine the aspect ratio
based on the p
Initial version of this driver.
The full datasheets are available from the Analog Devices website:
http://ez.analog.com/docs/DOC-1741
Not all features of the receiver are supported by this driver for various
reasons. Most notably:
- No CEC support (the CEC API needs a lot more discussio
Signed-off-by: Hans Verkuil
---
drivers/media/video/v4l2-ioctl.c | 13 +
drivers/media/video/v4l2-subdev.c |6 ++
include/media/v4l2-subdev.h |2 ++
3 files changed, 21 insertions(+)
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
On 07/05/2012 05:32 PM, Mauro Carvalho Chehab wrote:
Em 18-05-2012 15:47, Thomas Mair escreveu:
Changelog for ver. 0.5:
- fixed code style and naming errors
Changelog for ver. 0.4:
- removed statistics as their calculation was wrong
- fixed bug in Makefile
- indentation and code style improveme
Em 18-05-2012 15:47, Thomas Mair escreveu:
> Changelog for ver. 0.5:
> - fixed code style and naming errors
>
> Changelog for ver. 0.4:
> - removed statistics as their calculation was wrong
> - fixed bug in Makefile
> - indentation and code style improvements
>
> Signed-off-by: Thomas Mair
> ---
On Thu, Jul 5, 2012 at 10:25 AM, Devin Heitmueller
wrote:
> On Thu, Jul 5, 2012 at 10:16 AM, Mauro Carvalho Chehab
>> - /* Use both frq_lock and signal to generate the result */
>> - signal = signal || ((signal & 0x07) << 12);
>> + /* Signal level is 3 bits only */
>> +
>> +
On Thu, Jul 5, 2012 at 10:16 AM, Mauro Carvalho Chehab
> - /* Use both frq_lock and signal to generate the result */
> - signal = signal || ((signal & 0x07) << 12);
> + /* Signal level is 3 bits only */
> +
> + signal = ((1 << 12) - 1) | ((signal & 0x07) << 12);
Are you sur
On 07/05/2012 04:14 PM, Marx wrote:
Maybe i did something wrong because I'm new to git, so below are steps i
followed to compile new driver set:
1) git clone git://linuxtv.org/anttip/media_tree.git
2) git checkout -b pctv452e origin/pctv452e
3) copy config file from 3.4 kernel
4) make menuconfig,
Implement API support to return AFC frequency shift, as this device
supports it. The only other driver that implements it is tda9887,
and the frequency there is reported in Hz. So, use Hz also for this
tuner.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/common/tuners/tuner-xc2028.c |
There are several bugs at the signal strength algorithm:
- It is using logical OR, instead of bit OR;
- It doesn't wait up to 18 ms as it should;
- the strength range is not ok.
Rework on it, in order to make it work.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/med
If g_tuner is called and the tuner is able to return the signal strength
via has_signal(), call the tunner callback to retrieve such data for all
tuner types, not only for radio ones.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/video/tuner-core.c |4 ++--
1 file changed, 2 inserti
On 07/05/2012 04:41 PM, Hans de Goede wrote:
Hi,
On 07/05/2012 03:35 PM, Antti Palosaari wrote:
I believe you're doing something wrong ...
I compiled radio from http://git.linuxtv.org/xawtv3.git to tune and
> "arecord -r96000 -c2 -f S16_LE | aplay - " to play sound. Just
silent white no
On Thu, 5 Jul 2012 20:30:35 +1000, Anton Blanchard
wrote:
> I had a closer look. I dumped the RC6 debug, but I also printed the raw
> data in the interrupt handler:
>
> printk("%x %d %d\n", irdata, rawir.pulse, rawir.duration);
>
...
> That should have been a pulse but it came out as a space
Hi Laurent,
Laurent Pinchart wrote on 2012-07-05:
>> When I now capture a frame with yavta (see [3] for details), I must use
>> 846x639 as frame size (as this size is reported by the driver). But it
>> seems that the outputted image is 2px wider (that means 848x639). This
>> results in a "scramble
Hi,
On 07/05/2012 03:35 PM, Antti Palosaari wrote:
I believe you're doing something wrong ...
I compiled radio from http://git.linuxtv.org/xawtv3.git to tune and
> "arecord -r96000 -c2 -f S16_LE | aplay - " to play sound. Just
silent white noise is heard.
You're not specifying which dev
On 07/05/2012 11:33 AM, Hans de Goede wrote:
Hi,
On 07/04/2012 05:23 PM, Antti Palosaari wrote:
On 06/14/2012 04:43 PM, Hans de Goede wrote:
With the changes from the previous patches device firmware version 14 +
usb microcontroller software version 1 works fine too.
Signed-off-by: Hans de Go
Series looks good to me, ack series:
Acked-by: Hans de Goede
On 07/05/2012 12:25 PM, Hans Verkuil wrote:
Hi Mauro,
This should be the final patch series for adding multiband support to the
kernel.
This patch series assumes that this pull request was merged first:
http://patchwork.linuxtv.or
hi Anton,
it's very debatable that is fault of the Linux driver(s) and let me
elaborate why i think so: i have Logitech Harmony 890 remote and MCE
USB IR receiver that is supported by 'mceusb.c' in Linux, i.e. it's
different than your IR receiver, but yet the work is very unstable
together with my
Hi Florian,
On Thursday 05 July 2012 12:28:04 Florian Neuhaus wrote:
> Dear all,
> I am trying to get a mt9p031 sensor running on a beagleboard-xm with the
> following configuration:
>
> Hardware:
> - beagleboard-xm, rev c1
> - Leopard Imaging cam module LI-5M03 with a mt9p031 5MP sensor
>
> Sof
Dear all,
I am trying to get a mt9p031 sensor running on a beagleboard-xm with the
following configuration:
Hardware:
- beagleboard-xm, rev c1
- Leopard Imaging cam module LI-5M03 with a mt9p031 5MP sensor
Software:
- Angstrom-distro built with bitbake using the setup-scripts from [4] (commit
d
Hi David,
> The in-kernel RC6 decoder already has margins of around 50% for most
> pulse/spaces (i.e. 444us +/- 222us). Changing the sample resolution
> from 10 to 6 us should have little to no effect on the RC6 decoding
> (also, the Windows driver uses a 50us resolution IIRC).
>
> Do you have a
From: Hans Verkuil
- add control framework
- use core locking
- use V4L2_TUNER_CAP_LOW
- remove volume support: there is no hardware volume control
Signed-off-by: Hans Verkuil
---
drivers/media/radio/radio-cadet.c | 243 +
1 file changed, 83 insertions(+),
From: Hans Verkuil
Signed-off-by: Hans Verkuil
---
drivers/media/radio/radio-cadet.c | 129 +
1 file changed, 72 insertions(+), 57 deletions(-)
diff --git a/drivers/media/radio/radio-cadet.c
b/drivers/media/radio/radio-cadet.c
index d1fb427..18b8c71 100644
From: Hans Verkuil
This adds the usual core support code for this new ioctl.
Signed-off-by: Hans Verkuil
---
drivers/media/video/v4l2-compat-ioctl32.c |1 +
drivers/media/video/v4l2-dev.c|2 +
drivers/media/video/v4l2-ioctl.c | 88 -
i
From: Hans Verkuil
The current RDS code suffered from bit rot. Clean it up and make it work again.
Signed-off-by: Hans Verkuil
---
drivers/media/radio/radio-cadet.c | 56 ++---
1 file changed, 39 insertions(+), 17 deletions(-)
diff --git a/drivers/media/radio
From: Hans Verkuil
Signed-off-by: Hans Verkuil
---
Documentation/DocBook/media/v4l/compat.xml | 12 ++
Documentation/DocBook/media/v4l/v4l2.xml |6 +
.../DocBook/media/v4l/vidioc-enum-freq-bands.xml | 179
.../DocBook/media/v4l/vidioc-g-frequency.
From: Hans Verkuil
Add a new ioctl to enumerate the supported frequency bands of a tuner.
Signed-off-by: Hans Verkuil
---
include/linux/videodev2.h | 40 ++--
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/include/linux/videodev2.h b/inclu
Hi Mauro,
This should be the final patch series for adding multiband support to the
kernel.
This patch series assumes that this pull request was merged first:
http://patchwork.linuxtv.org/patch/13180/
Changes since the previous RFC patch series:
(See http://www.mail-archive.com/linux-media@vger
This patch add support gscaler device which is a new device
for scaling and color space conversion on EXYNOS5 SoCs.
This device supports the followings as key feature.
1) Input image format
- RGB888/565, YUV422 1P/2P, YUV420 2P/3P, TILE
2) Output image format
- RGB888/565, YUV422 1P/2P, YU
Hi Sachin,
Thank you for the patch.
On 07/04/2012 08:33 AM, Sachin Kamat wrote:
> module_i2c_driver makes the code simpler by eliminating module_init
> and module_exit calls.
>
> Signed-off-by: Sachin Kamat
Acked-by: Tomasz Stanislawski
> ---
> drivers/media/video/s5p-tv/sii9234_drv.c |
On Thu 5 July 2012 10:28:50 Sylwester Nawrocki wrote:
> Hi Hans,
>
> On 07/05/2012 08:54 AM, Hans Verkuil wrote:
> > Hi Sylwester,
> >
> > It still doesn't apply. This patch starts with:
> >
> > diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
> > b/drivers/media/video/s5p-fimc/fimc-cap
Hi,
On 07/04/2012 05:23 PM, Antti Palosaari wrote:
On 06/14/2012 04:43 PM, Hans de Goede wrote:
With the changes from the previous patches device firmware version 14 +
usb microcontroller software version 1 works fine too.
Signed-off-by: Hans de Goede
---
drivers/media/radio/si470x/radio-si
Hi Hans,
On 07/05/2012 08:54 AM, Hans Verkuil wrote:
> Hi Sylwester,
>
> It still doesn't apply. This patch starts with:
>
> diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
> b/drivers/media/video/s5p-fimc/fimc-capture.c
> index da2c40e..cb04a870 100644
> --- a/drivers/media/video/s5p-
89 matches
Mail list logo
