On 03/31/2014 07:24 PM, Prabhakar Lad wrote:
> Hi Hans,
>
> On Mon, Mar 31, 2014 at 8:34 PM, Hans Verkuil 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 :)
That was the idea!
>> I'll do a
Hi, Ben
On 3/31/2014 6:10 PM, Ben Dooks wrote:
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 dri
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 versi
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 s
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
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 nee
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
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 so
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 gen
Hi Hans,
On Mon, Mar 31, 2014 at 8:34 PM, Hans Verkuil 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 output
OK.
> of 'v
On Mon, Mar 31, 2014 at 1:06 AM, Hans Verkuil 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 initializer is supposed
On Mon, Mar 31, 2014 at 12:51 AM, Hans Verkuil 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 seem to sti
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
Em Mon, 31 Mar 2014 15:22:47 +0200
David Härdeman 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: A
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:
On
From: "Lad, Prabhakar"
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 and another for
display, s
From: "Lad, Prabhakar"
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_*() helpers.
4: uses SIMPLE_DE
From: "Lad, Prabhakar"
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_*() helpers.
4: uses SIMPLE_DE
Hi Mikhail,
Some comments below:
On 03/31/2014 01:13 PM, Mikhail Domrachev wrote:
> Signed-off-by: Mikhail Domrachev
> ---
> drivers/media/pci/saa7134/saa7134-empress.c | 1 +
> drivers/media/pci/saa7134/saa7134-reg.h | 6
> drivers/media/pci/saa7134/saa7134-video.c | 53
> +++
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 (lik
> 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
tra
On 2014-03-31 15:15, Mauro Carvalho Chehab wrote:
Em Mon, 31 Mar 2014 14:58:10 +0200
David Härdeman 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 24 bit version, it
Applications subscribed for this event can be notified about
changes of TV standard.
Signed-off-by: Mikhail Domrachev
---
Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml | 7 +++
include/uapi/linux/videodev2.h | 1 +
2 files changed, 8 insertions(+)
di
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 swap
Em Mon, 31 Mar 2014 14:58:10 +0200
David Härdeman escreveu:
> On 2014-03-31 14:14, Mauro Carvalho Chehab wrote:
> > Em Mon, 31 Mar 2014 12:19:10 +0200
> > David Härdeman escreveu:
> >> On 2014-03-31 11:44, James Hogan wrote:
> >> > On 29/03/14 16:11, David Härdeman wrote:
> >> >> Using the full
On 2014-03-31 14:14, Mauro Carvalho Chehab wrote:
Em Mon, 31 Mar 2014 12:19:10 +0200
David Härdeman 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
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 muc
The v4l2 event of type V4L2_EVENT_SIGNALCHANGED is emitted
when the current TV standard changes.
Signed-off-by: Mikhail Domrachev
---
drivers/media/pci/saa7134/saa7134-video.c | 125 +-
drivers/media/pci/saa7134/saa7134.h | 11 +++
2 files changed, 135 insertio
Hi David,
Em Mon, 31 Mar 2014 12:19:10 +0200
David Härdeman 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 functional
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, P
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
---
.../devicetree/bindings/media/rcar_vin.txt | 79 ++
drivers/media/platform/soc_camera/rcar_vin.c | 67 --
Signed-off-by: Mikhail Domrachev
---
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 | 1 +
4 files changed, 57 i
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:
drivers/media/usb/em28xx/em28
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 backwar
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 rc-main.
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
> introdu
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 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 informa
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 n
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,
> +
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;
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 , but this
> ver
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:
> 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 d
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 m
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
---
drivers/media/v4l2-core/v4l2-sub
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:
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 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: e
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 le
50 matches
Mail list logo
