On Fri, 28 Mar 2014, Jacek Anaszewski wrote:
This patch adds led-flash support to Maxim max77693 chipset.
Device can be exposed to user space through LED subsystem
sysfs interface or through V4L2 subdevice when the support
for Multimedia Framework is enabled. Device supports up to
two leds
On 03/15/2014 11:26 AM, Hans Verkuil wrote:
Hi!
I'm trying to cut down the list of sparse warnings and errors I get when
compiling drivers/media. Most of them are obviously our problem, but there
is one that seems to be a sparse bug:
drivers/media/v4l2-core/v4l2-dv-timings.c:30:9: error:
On 03/31/2014 09:51 AM, Hans Verkuil wrote:
On 03/15/2014 11:26 AM, Hans Verkuil wrote:
Hi!
I'm trying to cut down the list of sparse warnings and errors I get when
compiling drivers/media. Most of them are obviously our problem, but there
is one that seems to be a sparse bug:
On 03/15/2014 12:59 PM, Hans Verkuil wrote:
Hi!
Here is another sparse error that I get when running sparse over
drivers/media/v4l2-core/v4l2-ioctl.c:
drivers/media/v4l2-core/v4l2-ioctl.c:2043:9: error: bad integer constant
expression
drivers/media/v4l2-core/v4l2-ioctl.c:2044:9: error:
VIDIOC_SUBDEV_[GS]_FRAME_INTERVAL IOCTLs argument structs contain the pad
field but the validity check was missing. There should be no implications
security-wise from this since no driver currently uses the pad field in the
struct.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
Dear Guennadi
On 3/31/2014 5:20 AM, Guennadi Liakhovetski wrote:
Hi Josh,
Please correct me if I'm wrong, but I don't see how this is going to work
without the central part - building asynchronous V4L2 data structures from
the DT, something that your earlier patch
Here you mean Bryan Wu not
On 29/03/14 16:11, David Härdeman wrote:
This reverts 18bc17448147e93f31cc9b1a83be49f1224657b2
The patch ignores the fact that NEC32 scancodes are generated not only in the
NEC raw decoder but also directly in some drivers. Whichever approach is
chosen
it should be consistent across
Hi Jacek,
On Fri, Mar 28, 2014 at 04:30:19PM +0100, Jacek Anaszewski wrote:
Hi Sakari,
Thanks for the review.
On 03/24/2014 12:18 AM, Sakari Ailus wrote:
Hi Jacek,
Thanks for the patchset. It's very nice in general. I have a few comments
below.
[...]
diff --git
On 29/03/14 16:11, David Härdeman wrote:
The generic scancode filtering has questionable value and makes it
impossible to determine from userspace if there is an actual
scancode hw filter present or not.
So revert the generic parts.
Based on a patch from James Hogan
Hi jacek,
On Fri, Mar 28, 2014 at 04:30:49PM +0100, Jacek Anaszewski wrote:
...
+static int v4l2_flash_set_intensity(struct v4l2_flash *flash,
+ unsigned int intensity)
+{
+ struct led_classdev *led_cdev = flash-led_cdev;
+ unsigned int fault;
+ int ret;
Hi, Ben
Thanks for the patch, I just test atmel-isi with the your patch,
I find the mclk registered in soc-camera driver cannot be find
by the soc-camera sensors. See comment in below:
[snip]
... ...
+#ifdef CONFIG_OF
+static int soc_of_bind(struct soc_camera_host *ici,
+
On 29/03/14 16:11, David Härdeman wrote:
Using the full 32 bits for all kinds of NEC scancodes simplifies rc-core
and the nec decoder without any loss of functionality.
In order to maintain backwards compatibility, some heuristics are added
in rc-main.c to convert scancodes to NEC32 as
On 29/03/14 16:11, David Härdeman wrote:
Right now the protocol information is not preserved, rc-core gets handed a
scancode but has no idea which protocol it corresponds to.
This patch (which required reading through the source/keymap for all drivers,
not fun) makes the protocol information
On 31/03/14 10:28, Josh Wu wrote:
Hi, Ben
Thanks for the patch, I just test atmel-isi with the your patch,
I find the mclk registered in soc-camera driver cannot be find
by the soc-camera sensors. See comment in below:
Ok, I guess that the driver I have does not need the
mclk clock.
...
On Fri, 2014-03-28 at 16:28 +0100, Jacek Anaszewski wrote:
Some LED devices support two operation modes - torch and
flash. This patch provides support for flash LED devices
in the LED subsystem by introducing new sysfs attributes
and kernel internal interface. The attributes being
introduced
On 2014-03-31 11:44, James Hogan wrote:
On 29/03/14 16:11, David Härdeman wrote:
Using the full 32 bits for all kinds of NEC scancodes simplifies
rc-core
and the nec decoder without any loss of functionality.
In order to maintain backwards compatibility, some heuristics are
added
in
On 31/03/14 11:19, David Härdeman wrote:
On 2014-03-31 11:44, James Hogan wrote:
On 29/03/14 16:11, David Härdeman wrote:
Using the full 32 bits for all kinds of NEC scancodes simplifies rc-core
and the nec decoder without any loss of functionality.
In order to maintain backwards
tree: git://linuxtv.org/media_tree.git master
head: 84bc08734bb2735aa7cac30d3250e07031dac503
commit: 84bc08734bb2735aa7cac30d3250e07031dac503 [499/499] [media] em28xx-dvb:
fix PCTV 461e tuner I2C binding
config: make ARCH=mips allmodconfig
All error/warnings:
Signed-off-by: Mikhail Domrachev mihail.domryc...@comexp.ru
---
drivers/media/pci/saa7134/saa7134-empress.c | 1 +
drivers/media/pci/saa7134/saa7134-reg.h | 6
drivers/media/pci/saa7134/saa7134-video.c | 53 ++---
drivers/media/pci/saa7134/saa7134.h |
Hello.
On 31-03-2014 1:26, Ben Dooks wrote:
Add support for devicetree probe for the rcar-vin
driver.
Signed-off-by: Ben Dooks ben.do...@codethink.co.uk
---
.../devicetree/bindings/media/rcar_vin.txt | 79 ++
drivers/media/platform/soc_camera/rcar_vin.c
Hi Mikhail,
On 03/28/2014 02:16 PM, Devin Heitmueller wrote:
Let me explain why I created a new thread.
My company is engaged in the monitoring of TV air. All TV channels are
recorded 24/7 for further analysis. But some local TV channels change
the standard over time (SECAM-PAL, PAL-SECAM).
Hi David,
Em Mon, 31 Mar 2014 12:19:10 +0200
David Härdeman da...@hardeman.nu escreveu:
On 2014-03-31 11:44, James Hogan wrote:
On 29/03/14 16:11, David Härdeman wrote:
Using the full 32 bits for all kinds of NEC scancodes simplifies
rc-core
and the nec decoder without any loss of
Hi, Hans,
I agree with Devin here. None of the existing SDTV receivers do this, and
nobody ever used interrupts to check for this. Such interrupts are rarely
available, and if they exists they are never hooked up. This is quite
different for HDTV receivers where such an event is pretty much
The v4l2 event of type V4L2_EVENT_SIGNALCHANGED is emitted
when the current TV standard changes.
Signed-off-by: Mikhail Domrachev mihail.domryc...@comexp.ru
---
drivers/media/pci/saa7134/saa7134-video.c | 125 +-
drivers/media/pci/saa7134/saa7134.h | 11 +++
2
On 2014-03-31 14:14, Mauro Carvalho Chehab wrote:
Em Mon, 31 Mar 2014 12:19:10 +0200
David Härdeman da...@hardeman.nu escreveu:
On 2014-03-31 11:44, James Hogan wrote:
On 29/03/14 16:11, David Härdeman wrote:
Using the full 32 bits for all kinds of NEC scancodes simplifies
rc-core
and the
Em Mon, 31 Mar 2014 14:58:10 +0200
David Härdeman da...@hardeman.nu escreveu:
On 2014-03-31 14:14, Mauro Carvalho Chehab wrote:
Em Mon, 31 Mar 2014 12:19:10 +0200
David Härdeman da...@hardeman.nu escreveu:
On 2014-03-31 11:44, James Hogan wrote:
On 29/03/14 16:11, David Härdeman wrote:
On 2014-03-31 12:56, James Hogan wrote:
On 31/03/14 11:19, David Härdeman wrote:
On 2014-03-31 11:44, James Hogan wrote:
On 29/03/14 16:11, David Härdeman wrote:
+/* raw encoding : ddDDaaAA - scan encoding: AAaaDDdd */
+*scancode = swab32((u32)raw);
What's the point of the byte
Applications subscribed for this event can be notified about
changes of TV standard.
Signed-off-by: Mikhail Domrachev mihail.domryc...@comexp.ru
---
Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml | 7 +++
include/uapi/linux/videodev2.h | 1 +
2 files
On 2014-03-31 15:15, Mauro Carvalho Chehab wrote:
Em Mon, 31 Mar 2014 14:58:10 +0200
David Härdeman da...@hardeman.nu escreveu:
On 2014-03-31 14:14, Mauro Carvalho Chehab wrote:
The 24 or 32 bits variation is actually a violation of the NEC
protocol.
Violation is a misnomer. NEC created the
But I guess demuxing is necessary to get the NIT(actual) table, isn't it ?
Generally speaking applications configure the demux to pass all pids,
so yes - the demux is typically mandatory. Data is received from the
dvr0 device.
Assuming the card is tuning and delivering complete unfiltered
On 31/03/14 14:22, David Härdeman wrote:
On 2014-03-31 12:56, James Hogan wrote:
This would mean that if the data is put in the right bit order (first
bit received in BIT(0), last bit received in BIT(31)), then the scancode
= raw, and if the data is received in the reverse bit order (like the
Hi Mikhail,
Some comments below:
On 03/31/2014 01:13 PM, Mikhail Domrachev wrote:
Signed-off-by: Mikhail Domrachev mihail.domryc...@comexp.ru
---
drivers/media/pci/saa7134/saa7134-empress.c | 1 +
drivers/media/pci/saa7134/saa7134-reg.h | 6
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch upgrades the vpif display driver with
v4l helpers, this patch does the following,
1: initialize the vb2 queue and context at the time of probe
and removes context at remove() callback.
2: uses vb2_ioctl_*() helpers.
3: uses vb2_fop_*()
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch upgrades the vpif display driver with
v4l helpers, this patch does the following,
1: initialize the vb2 queue and context at the time of probe
and removes context at remove() callback.
2: uses vb2_ioctl_*() helpers.
3: uses vb2_fop_*()
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Hi All,
This patch series upgrades the vpif capture display
driver with the all the helpers provided by v4l, this makes
the driver much simpler and cleaner. This also includes few
checkpatch issues.
Sending them as single patch one for capture
Hi Prabhakar,
This looks really nice!
I'll do a full review on Friday, but in the meantime can you post the output
of 'v4l2-compliance -s' using the latest v4l2-compliance version? I've made
some commits today, so you need to do a git pull of v4l-utils.git.
I also have a small comment below:
Em Mon, 31 Mar 2014 15:22:47 +0200
David Härdeman da...@hardeman.nu escreveu:
On 2014-03-31 12:56, James Hogan wrote:
On 31/03/14 11:19, David Härdeman wrote:
On 2014-03-31 11:44, James Hogan wrote:
On 29/03/14 16:11, David Härdeman wrote:
+/* raw encoding : ddDDaaAA - scan encoding:
On Mon, Mar 31, 2014 at 12:26:56PM -0300, Mauro Carvalho Chehab wrote:
Inside the RC core, for all other protocols, the order always
ADDRESS + COMMAND.
Up to NEC-24 bits, this is preserved, as the command is always 0xDD
and the address is either 0xaaAA or 0xAA.
The 32-bits NEC is a little
On Mon, Mar 31, 2014 at 12:51 AM, Hans Verkuil hverk...@xs4all.nl wrote:
Here is a simple test case for this problem:
== anon-union.c ==
struct s {
union {
int val;
};
};
static struct s foo = { .val = 5, };
Ok, this fixes the warning, but we
On Mon, Mar 31, 2014 at 1:06 AM, Hans Verkuil hverk...@xs4all.nl wrote:
Running sparse over this gives:
error: bad integer constant expression
So technically sparse is correct in this case. The kernel ends up
doing some questionable things that gcc allows. The index in an
assignment
Hi Hans,
On Mon, Mar 31, 2014 at 8:34 PM, Hans Verkuil hverk...@xs4all.nl wrote:
Hi Prabhakar,
This looks really nice!
Writing a video driver has become really easy with almost 90% of work
done by v4l core itself :)
I'll do a full review on Friday, but in the meantime can you post the
On Mon, Mar 31, 2014 at 10:29:53AM +0100, James Hogan wrote:
On 29/03/14 16:11, David Härdeman wrote:
The generic scancode filtering has questionable value and makes it
impossible to determine from userspace if there is an actual
scancode hw filter present or not.
So revert the generic
On Mon, Mar 31, 2014 at 10:54:59AM +0100, James Hogan wrote:
On 29/03/14 16:11, David Härdeman wrote:
Right now the protocol information is not preserved, rc-core gets handed a
scancode but has no idea which protocol it corresponds to.
This patch (which required reading through the
On Fri, Mar 28, 2014 at 11:17:09PM +, James Hogan wrote:
On Friday 28 March 2014 01:08:56 David Härdeman wrote:
On Thu, Mar 27, 2014 at 11:21:23PM +, James Hogan wrote:
On Thursday 27 March 2014 22:00:37 David Härdeman wrote:
This reverts 18bc17448147e93f31cc9b1a83be49f1224657b2
The
Hi,
I'm trying to write a HDMI-CEC driver for the Radxa Rock (Specification -
Radxa). I am coming from a software background and have found libcec and am
looking at other implementation.
I'm wondering how to connect the hardware and software pieces under Linux /
Android.
I'm not sure if I
On Monday 31 March 2014 21:38:13 David Härdeman wrote:
The rest looks reasonable, though it could easily have been a separate
patch (at least as long as the show/store callbacks don't assume the
presence of the callbacks they use).
Yes, I wanted to avoid there being more intermediary states
Hi,
I've been having a problem with a GPIO ir device in an i.mx6 arm
system that I have (cubox-i).
It seems to all work ok, except the output on /dev/lirc0 is not quite
what lircd seems to expect. Lircd wants a long space before the
starting pulse before processing any output. However, no long
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: Tue Apr 1 04:00:22 CEST 2014
git branch: test
git hash: a83b93a7480441a47856dc9104bea970e84cda87
gcc
48 matches
Mail list logo
