The second argument should be physical address rather than virtual address.
Signed-off-by: Ma Haijun mahaij...@gmail.com
---
drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
Hi Laurent,
On Wed, 26 Mar 2014 18:33:09 +0100
Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:
That could work in your case, but I don't really like that.
We need to describe the hardware topology, that might be the only point we
all
agree on. There are various hardware
Hi Patrick,
a quick question regarding the dib0700 driver:
in ./media/usb/dvb-usb/dib0700_core.c the RC RX packet is defined as:
struct dib0700_rc_response {
u8 report_id;
u8 data_state;
union {
u16 system16;
Hi,
I'm a linux user and I've purchased easycap. I must load the firmware, but I
don't know what is the right one. I get from lsusb: 1c88:0007 Somagic, Inc.
What is the right firmware for my device: SmiUsbGrabber3C.sys,
SmiUsbGrabber3E.sys or SmiUsbGrabber3F.sys ?
Waiting for a reply,
Best
Recent changes in the em28xx module introduced a bug which I'm
encountering with my PCTV 510e DVB-C stick. It seems that starting a
stream increases the queue in the host controller up to the point to
which it would overflow (at least for ehci).
I'v done some preliminary work to trace the
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 drivers and this patch needs more discussion.
It turns out, that 64-bit compilations sometimes align structs within
other structs on 32-bit boundaries, but in other cases alignment is done
on 64-bit boundaries, adding padding if necessary. This is done, for
example when the embedded struct contains a pointer. This is the case with
struct
On Thu, Mar 27, 2014 at 01:07:28PM +0100, David Härdeman wrote:
Hi Patrick,
a quick question regarding the dib0700 driver:
in ./media/usb/dvb-usb/dib0700_core.c the RC RX packet is defined as:
...
The NEC protocol transmits in the order:
...
Does the dib0700 fw really reorder the bytes, or could
Hi David,
On Thursday 27 March 2014 22:40:41 David Härdeman wrote:
On Thu, Mar 27, 2014 at 01:07:28PM +0100, David Härdeman wrote:
Hi Patrick,
a quick question regarding the dib0700 driver:
in ./media/usb/dvb-usb/dib0700_core.c the RC RX packet is defined as:
...
The NEC protocol
Hi David,
On Thursday 27 March 2014 22:00:37 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
On Thu, Mar 27, 2014 at 11:13:35PM +0100, Patrick Boettcher wrote:
Hi David,
On Thursday 27 March 2014 22:40:41 David Härdeman wrote:
On Thu, Mar 27, 2014 at 01:07:28PM +0100, David Härdeman wrote:
Hi Patrick,
a quick question regarding the dib0700 driver:
in
On Thu, Mar 27, 2014 at 11:21:23PM +, James Hogan wrote:
Hi David,
On Thursday 27 March 2014 22:00:37 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
Hi Malcolm,
I'm trying to make sure that the extended NEC parsing is consistent
across drivers and I have a question regarding
drivers/media/usb/dvb-usb-v2/lmedm04.c
In commit 616a4b83 you changed the scancode from something like this:
ibuf[2] 24 | ibuf[3] 16 | ibuf[4] 8 | ibuf[5]
FYI, I've gone through all the drivers in the media tree that generate
NECX codes to make sure they are consistent. There are two question
marks (that probably just need a small cleanup) and one driver that
reverses the order of the address bytes compared to the rest.
file:
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: Fri Mar 28 04:00:24 CET 2014
git branch: test
git hash: 8432164ddf7bfe40748ac49995356ab4dfda43b7
gcc
26.03.2014 21:41, Laurent Pinchart wrote:
Hi Anton,
Thank you for the patch.
On Tuesday 25 March 2014 08:40:57 Anton Leontiev wrote:
Set error bit for incomplete buffers when end of buffer is detected by
FID toggling (for example when last transaction with EOF is lost).
This prevents
timestamps in v4l2 buffers returned to userspace are updated in
uvc_video_clock_update() which uses timestamps fetched from
uvc_video_clock_decode() by calling unconditionally ktime_get_ts().
Hence setting the module clock param to realtime have no effect
before this patch.
This has been tested
17 matches
Mail list logo
