Hi Philipp,
On 25/06/15 17:12, Philipp Zabel wrote:
Am Donnerstag, den 25.06.2015, 15:11 +0200 schrieb Sylwester Nawrocki:
On 25/06/15 12:01, Philipp Zabel wrote:
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 9 -
1 file changed, 8
* Luis R. Rodriguez mcg...@suse.com wrote:
On Thu, Jun 25, 2015 at 08:49:22AM +0200, Ingo Molnar wrote:
* Luis R. Rodriguez mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
WARN() may confuse users, fix that. ipath_init_one() is part the
device's probe
* Luis R. Rodriguez mcg...@suse.com wrote:
On Thu, Jun 25, 2015 at 08:51:47AM +0200, Ingo Molnar wrote:
* Luis R. Rodriguez mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
On built-in kernels this warning will always splat as this is part
of the
Hi Prashant,
On 06/24/2015 03:59 PM, Prashant Laddha wrote:
Added reduced fps option in cvt timings calculation. In this case,
pixel clock is slowed down by a factor of 1000 / 1001 and all other
timing parameters are unchanged. With reduced fps option one could
generate timings for refresh
Hi,
Thanks everybody for comments.
2015-06-22 17:54 GMT+03:00 Kamil Debski ka...@wypas.org:
Hi,
I am adding Jacek Anaszewski to CC loop. He was working with the
s5p-jpeg driver some time ago.
I've spoken with him about questions in this email recently. Jacek,
thank you for your comments :)
Hi Mikhail,
On 26 June 2015 at 12:34, Mikhail Ulyanov
mikhail.ulya...@cogentembedded.com wrote:
Hi,
Thanks everybody for comments.
2015-06-22 17:54 GMT+03:00 Kamil Debski ka...@wypas.org:
Hi,
I am adding Jacek Anaszewski to CC loop. He was working with the
s5p-jpeg driver some time ago.
Hi Linus,
Very small pull request on dma-buf for 4.2 merge window. May I request
you to please pull?
The following changes since commit 5ebe6afaf0057ac3eaeb98defd5456894b446d22:
Linux 4.1-rc2 (2015-05-03 19:22:23 -0700)
are available in the git repository at:
An image of the top of the tuner clearly showing any manufacturing
markings would be welcome - assuming its accessible.
It's a best picture I could find:
http://www.reviews.ru/clause/over/T7_2/image41.jpg
Thanks.
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe
Here is a link on a chinese site with datasheet for xc5100.
http://wenku.baidu.com/view/7f92f3fe700abb68a982fb96.html
If you look at it, after reading Product ID we also should receive
0x14b4 (5300 decimal)
I'll try extract a FW from a Windows driver and will share results,
in case of success.
Hi Hans,
Em Fri, 26 Jun 2015 13:23:01 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
Introduction
This RFC is a proposal that will hopefully fix the impasse w.r.t. DVB and MC.
This proposal was the result of a private irc discussion between Laurent and
myself. We were both
hello all,
I am new to dvb kernel driver development and have some questions.
the hardware is explained here,
http://www.linuxtv.org/wiki/index.php/TBS_Qbox_DVB-S2_CI_USB2.0
Whats the difference between dvb-usb and dvb-usb-v2, what is added or
why are there 2 versions?
I am trying to implement
!
Signed-off-by: Randy Dunlap rdun...@infradead.org
Cc: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/pci/cobalt/Kconfig |1 +
1 file changed, 1 insertion(+)
--- linux-next-20150626.orig/drivers/media/pci/cobalt/Kconfig
+++ linux-next-20150626/drivers/media/pci/cobalt/Kconfig
@@ -2,6
(-)
--- linux-next-20150626.orig/drivers/media/dvb-frontends/Kconfig
+++ linux-next-20150626/drivers/media/dvb-frontends/Kconfig
@@ -240,7 +240,7 @@ config DVB_SI21XX
config DVB_TS2020
tristate Montage Tehnology TS2020 based tuners
- depends on DVB_CORE
+ depends on DVB_CORE
The queue owner will be used by videobuf2 trace events to determine and
record the device minor number. It is set in v4l2_m2m_reqbufs instead of
v4l2_m2m_ioctl_reqbufs because several drivers implement their own
vidioc_reqbufs handlers that still call v4l2_m2m_reqbufs directly.
Signed-off-by:
Add videobuf2 specific vb2_qbuf and vb2_dqbuf trace events that mirror the
v4l2_qbuf and v4l2_dqbuf trace events, only they include additional
information about queue fill state and are emitted right before the buffer
is enqueued in the driver or userspace is woken up. This allows to make
sense of
Trace events with exactly the same parameters and trace output, such as
v4l2_qbuf and v4l2_dqbuf, are supposed to use the DECLARE_EVENT_CLASS and
DEFINE_EVENT macros instead of duplicated TRACE_EVENT macro calls.
Suggested-by: Steven Rostedt rost...@goodmis.org
Signed-off-by: Philipp Zabel
On 26/06/15 11:02, Philipp Zabel wrote:
Am Freitag, den 26.06.2015, 10:28 +0200 schrieb Sylwester Nawrocki:
[...]
How about modifying v4l2_m2m_ioctl_reqbufs() instead ?
The coda, gsc-m2m, m2m-deinterlace, mx2_emmaprp, and sh_veu drivers all
have their own implementation of
Am Freitag, den 26.06.2015, 10:28 +0200 schrieb Sylwester Nawrocki:
[...]
How about modifying v4l2_m2m_ioctl_reqbufs() instead ?
The coda, gsc-m2m, m2m-deinterlace, mx2_emmaprp, and sh_veu drivers all
have their own implementation of vidioc_reqbufs that call
v4l2_m2m_reqbufs directly.
Em Fri, 26 Jun 2015 03:58:48 +0700
Unembossed Name severe.siberian@mail.ru escreveu:
Hi,
I was working on a Linux driver for a hybrid TV-tuner with SAA7134 PCI
bridge, XC5000C RF tuner and Si2168 DVB demodulator by a
combining all existent at that time drivers together.
During that
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: Sat Jun 27 04:00:29 CEST 2015
git branch: test
git hash: faebbd8f134f0c054f372982c8ddd1bbcc41b440
gcc
Correct. These are not parts that have any form of default firmware
in their ROM mask (i.e. not like the silabs or micronas parts which
have a default firmware and the ability to patch the ROM via a
software loaded code update). The firmware must be loaded every time
the chip is brought out
It's not new IC. It's XC5000C. Maybe i was interpreted wrong.
As I have understood, such behaviour can depends from FW version.
HW vendor says, that with his latest FW he always gets response 0x14b4.
Ah, so you're running a completely different firmware image? Well in
that case that would
Correct. These are not parts that have any form of default firmware
in their ROM mask (i.e. not like the silabs or micronas parts which
have a default firmware and the ability to patch the ROM via a
software loaded code update). The firmware must be loaded every time
the chip is brought out of
Introduction
This RFC is a proposal that will hopefully fix the impasse w.r.t. DVB and MC.
This proposal was the result of a private irc discussion between Laurent and
myself. We were both on opposite sides of the earlier discussions and we decided
to try to come to a solution
2015-06-26 15:14 GMT+03:00 Kamil Debski ka...@wypas.org:
Hi Mikhail,
On 26 June 2015 at 12:34, Mikhail Ulyanov
mikhail.ulya...@cogentembedded.com wrote:
Hi,
Thanks everybody for comments.
2015-06-22 17:54 GMT+03:00 Kamil Debski ka...@wypas.org:
Hi,
I am adding Jacek Anaszewski to CC
IMHO, the best is to get the latest firmware licensed is the best
thing to do.
Does that new xc5000c come with a firmware pre-loaded already?
I've got firmware here that is indicated as being for the xc5300 (i.e.
0x14b4). That said, I am not sure if it's the same as the original
5000c
From: Mauro Carvalho Chehab
To: Unembossed Name
Cc: linux-media@vger.kernel.org; Devin Heitmueller
Sent: Friday, June 26, 2015 4:22 PM
Subject: Re: XC5000C 0x14b4 status
After that RF tuner identification became always successful.
I had a conversation with a hardware vendor.
Now I can say,
It's not new IC. It's XC5000C. Maybe i was interpreted wrong.
As I have understood, such behaviour can depends from FW version.
HW vendor says, that with his latest FW he always gets response 0x14b4.
Ah, so you're running a completely different firmware image? Well in
that case that would
Here's the driver for the Renesas R-Car JPEG processing unit.
The driver is implemented within the V4L2 framework as a memory-to-memory
device. It presents two video nodes to userspace, one for the encoding part,
and one for the decoding part.
It was found that the only working mode for
IMHO, the best is to get the latest firmware licensed is the best
thing to do.
Does that new xc5000c come with a firmware pre-loaded already?
I've got firmware here that is indicated as being for the xc5300 (i.e.
0x14b4). That said, I am not sure if it's the same as the original
5000c
On Fri, 2015-06-26 at 10:45 +0200, Ingo Molnar wrote:
* Luis R. Rodriguez mcg...@suse.com wrote:
On Thu, Jun 25, 2015 at 08:51:47AM +0200, Ingo Molnar wrote:
* Luis R. Rodriguez mcg...@do-not-panic.com wrote:
From: Luis R. Rodriguez mcg...@suse.com
On built-in kernels
31 matches
Mail list logo
