From: Hans Verkuil hans.verk...@cisco.com
radio-bcm2048.c: In function 'bcm2048_i2c_driver_probe':
radio-bcm2048.c:2597:11: warning: variable 'skip_release' set but not used
[-Wunused-but-set-variable]
int err, skip_release = 0;
^
Signed-off-by: Hans Verkuil
From: Hans Verkuil hans.verk...@cisco.com
In file included from drivers/media/common/b2c2/flexcop-fe-tuner.c:13:0:
drivers/media/dvb-frontends/cx24123.h:54:2: warning:
'cx24123_get_tuner_i2c_adapter' defined but not used [-Wunused-function]
cx24123_get_tuner_i2c_adapter(struct dvb_frontend
From: Hans Verkuil hans.verk...@cisco.com
In file included from include/uapi/linux/posix_types.h:4:0,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/sysinfo.h:4,
from
From: Hans Verkuil hans.verk...@cisco.com
Fix these compiler warnings that appeared after switching to gcc-5.1.0:
drivers/media/i2c/s5k5baf.c: In function 's5k5baf_set_power':
drivers/media/i2c/s5k5baf.c:1057:10: warning: logical not is only applied to
the left hand side of comparison
From: Hans Verkuil hans.verk...@cisco.com
Various patches to fix compiler warnings. Some of these appeared after
I switched to gcc-5.1.0 for the daily build.
There is one more warning in a davinci driver remaining, I've asked
Prabhakar to look at that one.
Regards,
Hans
Hans Verkuil
From: Hans Verkuil hans.verk...@cisco.com
Fix these compiler warnings that appeared after switching to gcc-5.1.0:
drivers/media/platform/s3c-camif/camif-capture.c: In function
'sensor_set_power':
drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not
is only applied to
Hi Lars,
Thank you for your comments.
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Lars Op den Kamp
Sent: Friday, April 24, 2015 12:04 PM
Hi Kamil, Hans,
I'm the main developer of libCEC
(https://github.com/Pulse-Eight/libcec). Sorry
On 04/27/2015 11:22 AM, Hans Verkuil wrote:
Hi Kamil,
Sorry for all the replies, but I'm writing the DocBook documentation, so
whenever I find something missing I'll just reply to this patch.
+/* The CEC version */
Add support for version 1.3a here:
#define CEC_VERSION_1_3A
Hi Kamil,
I've added some missing HDMI 2.0 commands:
On 04/23/2015 03:03 PM, Kamil Debski wrote:
From: Hans Verkuil hansv...@cisco.com
The added HDMI CEC framework provides a generic kernel interface for
HDMI CEC devices.
Signed-off-by: Hans Verkuil hansv...@cisco.com
On 04/23/2015 03:03 PM, Kamil Debski wrote:
From: Hans Verkuil hansv...@cisco.com
The added HDMI CEC framework provides a generic kernel interface for
HDMI CEC devices.
Signed-off-by: Hans Verkuil hansv...@cisco.com
[k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil]
Hi Kamil,
Sorry for all the replies, but I'm writing the DocBook documentation, so
whenever I find something missing I'll just reply to this patch.
+/* The CEC version */
Add support for version 1.3a here:
#define CEC_VERSION_1_3A4
+#define CEC_VERSION_1_4B 5
On 04/23/2015 03:03 PM, Kamil Debski wrote:
From: Hans Verkuil hansv...@cisco.com
The added HDMI CEC framework provides a generic kernel interface for
HDMI CEC devices.
Signed-off-by: Hans Verkuil hansv...@cisco.com
[k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil]
Thank you for your review Mauro.
In total there are about 3-4 (it's a guess) users of this driver and
this, written-once read-never, code is for a hardware which is very
unlikely to be ever reused again ever. Sometimes I regret that there is
no carpet in OpenSource where you could hide the dirt
(Resending to fix reply-all)
Hi Mauro,
Thanks for taking the time to look into this. I'll let Patrick respond
to the first part regards the pull request - I'll just respond to the
points you've made about the driver itself.
On 27/04/15 21:16, Mauro Carvalho Chehab wrote:
+
+
+/* Write
Em Mon, 20 Apr 2015 09:27:20 +0200
Patrick Boettcher patrick.boettc...@posteo.de escreveu:
Hi Mauro,
Would you please pull the following two patches for finally
mainlining the Technisat SkyStar S2 (and its frontend cx24120).
Ideally for 4.1, but I assume it is too late. So for 4.2.
Hi
Hi Lars,
My thanks as well for your comments.
I'd like to add some background information as well as to why we move
the core CEC support into the kernel: the main reason for doing this
is to support the HEAC part of the CEC protocol. Specifically the ARC
support and handling the hotplug detect
Added the y2038 mailinglist since I would like to get their input for
this API.
Y2038 experts, can you take a look at my comments in the code below?
Thanks!
On 04/23/2015 03:03 PM, Kamil Debski wrote:
From: Hans Verkuil hansv...@cisco.com
The added HDMI CEC framework provides a generic
On 04/27/2015 11:22 AM, Hans Verkuil wrote:
Hi Kamil,
Sorry for all the replies, but I'm writing the DocBook documentation, so
whenever I find something missing I'll just reply to this patch.
+/* The CEC version */
Add support for version 1.3a here:
#define CEC_VERSION_1_3A
Hi Hans,
Thank you so much for all today's comments. I will consider them when
preparing the next version.
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Monday, April 27, 2015 1:27 PM
On 04/27/2015 12:25 PM, Hans Verkuil
(Kamil, here is the DocBook documentation for the CEC API. Please add this to
your
patch series when you post the next version of that.)
---
Add the documentation for the public CEC API.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
Documentation/DocBook/media/Makefile |
Thank you Steven,
That's helpful to know. I've been bumping into some issues with
another Si2168-based device and certain DVB-C streams. Will try to see
if this could help in that case...
Cheers,
-olli
On 24 April 2015 at 15:16, Steven Toth st...@kernellabs.com wrote:
I've also seen that the
Hi Philipp,
I finally got around to reviewing this patch series. Sorry for the delay, but
here are my comments:
On 04/20/2015 10:28 AM, Philipp Zabel wrote:
Document the interaction between VIDIOC_DECODER_CMD V4L2_DEC_CMD_STOP and
VIDIOC_ENCODER_CMD V4L2_ENC_CMD_STOP to start the draining, the
On 04/27/2015 12:25 PM, Hans Verkuil wrote:
On 04/23/2015 03:03 PM, Kamil Debski wrote:
From: Hans Verkuil hansv...@cisco.com
The added HDMI CEC framework provides a generic kernel interface for
HDMI CEC devices.
Signed-off-by: Hans Verkuil hansv...@cisco.com
[k.deb...@samsung.com: Merged
On 04/20/2015 10:28 AM, Philipp Zabel wrote:
From: Peter Seiderer ps.rep...@gmx.net
This v4l2_buffer flag can be used by drivers to mark a capture buffer
as the last generated buffer, for example after a V4L2_DEC_CMD_STOP
command was issued.
Signed-off-by: Peter Seiderer ps.rep...@gmx.net
On 04/20/2015 10:28 AM, Philipp Zabel wrote:
Document the interaction between VIDIOC_DECODER_CMD V4L2_DEC_CMD_STOP and
VIDIOC_ENCODER_CMD V4L2_ENC_CMD_STOP to start the draining, the V4L2_EVENT_EOS
event signalling all capture buffers are finished and ready to be dequeud,
the new
The following changes since commit b3e5ced63e051e8f911b795ac5b06229a5328f7b:
Merge tag 'v4.1-rc1' into patchwork (2015-04-27 10:32:45 -0300)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git for-v4.2f
for you to fetch changes up to
On 04/20/2015 10:28 AM, Philipp Zabel wrote:
If the last buffer was dequeued from a capture queue, let poll return
immediately and let DQBUF return -EPIPE to signal there will no more
buffers to dequeue until STREAMOFF.
The driver signals the last buffer by setting the V4L2_BUF_FLAG_LAST.
To
tree: git://linuxtv.org/media_tree.git master
head: cb0c9e1f6777287e81d9b48c264d980bf5014b48
commit: 698da18e082c8fdfa675bee6338e3f9864d5d7ee [731/732] [media] v4l: of:
Parse variable length properties --- link-frequencies
config: x86_64-randconfig-ib0-04280406 (attached as .config)
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 28 04:00:17 CEST 2015
git branch: test
git hash: cb0c9e1f6777287e81d9b48c264d980bf5014b48
gcc
This adds DT binding documentation for STMicroelectronics bdisp driver.
Signed-off-by: Fabien Dessenne fabien.desse...@st.com
---
.../devicetree/bindings/media/st,stih4xx.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644
gute Neuigkeiten
Handy, Laptop, TV-Raum, Goultard .
Versand ist kostenlos
Alle unsere Produkte können Preferred Rabatt von 50% angeboten werden
si te: weacaoo . com
Creates 5 debugfs entries to dump the last HW request, the last HW node
(=command), the HW registers and the recent HW performance (time fps)
Signed-off-by: Fabien Dessenne fabien.desse...@st.com
---
drivers/media/platform/bdisp/Makefile | 2 +-
drivers/media/platform/bdisp/bdisp-debug.c
This v4l2 mem2mem driver is a 2D blitter for STMicroelectronics SoC.
It uses the v4l2 mem2mem framework.
The following features are supported and tested:
- Color format conversion (RGB32, RGB24, RGB16, NV12, YUV420P)
- Copy
- Scale
- Flip
- Deinterlace
- Wide (4K) picture support
- Crop
This series of patches adds the support of v4l2 2D blitter driver for
STMicroelectronics SOC.
The following features are supported and tested:
- Color format conversion (RGB32, RGB24, RGB16, NV12, YUV420P)
- Copy
- Scale
- Flip
- Deinterlace
- Wide (4K) picture support
- Crop
This driver uses
From: Luis R. Rodriguez mcg...@suse.com
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
Hi Fabien,
Thank you for this driver! Good to see V4L2 support for this SoC.
I did a quick initial scan over the driver and there are a few things that
need to be addressed:
- I think bdisp as the driver name is a bit generic, perhaps something like
stih4xx-bdisp might be more appropriate.
On Sat, Apr 25, 2015 at 07:12:05AM -0400, Andy Walls wrote:
Hi Luis,
Sorry for the late reply.
Thank you for the patch! See my comments below:
On Wed, 2015-04-22 at 12:33 -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
We are burrying direct access to MTRR
Em Mon, 27 Apr 2015 23:25:23 +0200
Patrick Boettcher patrick.boettc...@posteo.de escreveu:
Thank you for your review Mauro.
In total there are about 3-4 (it's a guess) users of this driver and
this, written-once read-never, code is for a hardware which is very
unlikely to be ever reused
On Mon, 2015-04-27 at 09:43 -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC,
39 matches
Mail list logo
