Hi, this is David Wu from Shanghai, China.
We are a printing company, we can print color box, corrugated box,
label, hang tag etc.
Please let me know if you need these.
I will send you the website then.
Best regards,
David Wu
--
To unsubscribe from this list: send the line unsubscribe
get_user_pages(write=1, force=1) has always had odd behaviour on write-
protected shared mappings: although it demands FMODE_WRITE-access to the
underlying object (do_mmap_pgoff sets neither VM_SHARED nor VM_MAYWRITE
without that), it ends up with do_wp_page substituting private anonymous
Hi Prabhakar,
Some review comments below. I'm going through the code quite carefully since
this very nice cleanup is a good opportunity to check for correct behavior in
this driver.
On 04/04/2014 07:17 AM, Lad, Prabhakar wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch
Hi!
We have an Osprey 210 video capture card, which we want to use with Matterhorn
platform for lecture recording purposes. The problem is in the following,
osprey card records audio in the “fast” mode. So, when you play the recorded
track, speech sounds unnatural and accelerated. The card is
Hi Mauro,
A bunch of fixes for the davinci driver (found with the new vb2 instrumentation
and kmemleak) and a vb2 fix: the finish memop wasn't called for prepared or
queued buffers. Found with v4l2-compliance and the vb2 instrumentation.
This happens in the corner case where you call QBUF and/or
Can someone review this? That would be much appreciated!
Regards,
Hans
On 03/10/2014 10:20 PM, Hans Verkuil wrote:
This patch series contains a list of various vb2 fixes and improvements.
These patches were originally part of this RFC patch series:
Whatever happened with this btw? Also are you sure we don't need a
second check after line 457?
regards,
dan carpenter
On Tue, Aug 27, 2013 at 04:26:07PM +0200, Sylwester Nawrocki wrote:
On 08/27/2013 04:19 PM, Dan Carpenter wrote:
On Sun, Aug 25, 2013 at 02:23:18PM +0200, Sylwester Nawrocki
On Fri, Apr 04, 2014 at 01:28:22AM -0700, Hugh Dickins wrote:
get_user_pages(write=1, force=1) has always had odd behaviour on write-
protected shared mappings: although it demands FMODE_WRITE-access to the
underlying object (do_mmap_pgoff sets neither VM_SHARED nor VM_MAYWRITE
without that),
Hi David,
On 4 April 2014 00:31, David Härdeman da...@hardeman.nu wrote:
Overloading dev-s_filter to do two different functions (set wakeup filters
and generic hardware filters) makes it impossible to tell what the
hardware actually supports, so create a separate dev-s_wakeup_filter and
make
Hi David,
On 4 April 2014 00:31, David Härdeman da...@hardeman.nu wrote:
diff --git a/drivers/media/rc/img-ir/img-ir-nec.c
b/drivers/media/rc/img-ir/img-ir-nec.c
index c0111d6..ee45795 100644
--- a/drivers/media/rc/img-ir/img-ir-nec.c
+++ b/drivers/media/rc/img-ir/img-ir-nec.c
/* Convert
The input field in struct v4l2_buffer no longer exists but has been replaced
by a reserved field. Remove the field documentation.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
include/uapi/linux/videodev2.h | 1 -
1 file changed, 1 deletion(-)
diff --git
V4L2_MBUS_FRAME_DESC_FL_BLOB intends to say the receiver must use 1D DMA to
receive the image, as the format does not have line offsets. This typically
includes all compressed formats.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
---
Hi,
Two trivial fixes. The first one perhaps is worth a thought. This was anyway
my original intention. I'm not sure we'll ever want to have user defined
(i.e. undocumented) media bus formats anyway. Hopefully not at least. :-)
--
Kind regards,
Sakari
--
To unsubscribe from this list: send the
Hi David,
On 4 April 2014 00:31, David Härdeman da...@hardeman.nu 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.
I've already mentioned in
On Fri, 4 Apr 2014, Kirill A. Shutemov wrote:
There's comment in do_wp_page() which is not true anymore with patch
applied. It should be fixed.
The * Only catch write-faults on shared writable pages,
* read-only shared pages can get COWed by
* get_user_pages(.write=1, .force=1).
Yes,
On Thu, Apr 3, 2014 at 9:11 AM, Mauro Carvalho Chehab
m.che...@samsung.com wrote:
PS.: You'll find some minor conflicts between this changeset and upstream,
mainly due to some code that moved from V4L2 to OF subsystem.
That conflict was not at all minor, unless I were willing to do the
merge
Hi Linus,
On Friday 04 April 2014 10:26:42 Linus Torvalds wrote:
On Thu, Apr 3, 2014 at 9:11 AM, Mauro Carvalho Chehab wrote:
PS.: You'll find some minor conflicts between this changeset and upstream,
mainly due to some code that moved from V4L2 to OF subsystem.
That conflict was not at
Hi Linus,
That's the remaining patches I have for the merge windows. It basically
adds a new sensor and adds the needed DT bits for it to work.
-
PS.: This patch also have some conflicts with the code that got moved
to drivers/of, but this conflict is just function rename:
- node =
Hi Laurent,
I've done the following:
echo 3 /sys/module/videobuf2_core/parameters/debug
and found in /var/log/kern.log after starting my program:
Apr 4 21:53:48 x240 kernel: [239432.535077] vb2: Buffer 0, plane 0 offset
0x
Apr 4 21:53:48 x240 kernel: [239432.535080] vb2: Buffer 1,
On Thu, Apr 3, 2014 at 9:11 AM, Mauro Carvalho Chehab
m.che...@samsung.com wrote:
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
v4l_for_linus
Oh, just noticed that this seems to be the cause of a new annoying warning:
The following three patches are the quickfixes that we (Mauro, James, me)
seemed to agree to. I've updated the patches to apply cleanly without
the preceeding patches from my previous patchbomb and I've hopefully fixed
the comments that James provided (I'll let him reply with separate Acked-by
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.
Overloading dev-s_filter to do two different functions (set wakeup filters
and generic hardware filters) makes it impossible to tell what the
hardware actually supports, so create a separate dev-s_wakeup_filter and
make the distinction explicit.
v2: hopefully address James' comments on what
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 james.ho...@imgtec.com, but this
version also makes sure that only the
On Saturday 05 April 2014 00:05:56 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
On Saturday 05 April 2014 00:06:01 David Härdeman wrote:
Overloading dev-s_filter to do two different functions (set wakeup filters
and generic hardware filters) makes it impossible to tell what the
hardware actually supports, so create a separate dev-s_wakeup_filter and
make the distinction
On Saturday 05 April 2014 00:06:06 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
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 Apr 5 04:00:42 CEST 2014
git branch: test
git hash: a83b93a7480441a47856dc9104bea970e84cda87
gcc
Hi Bud,
It seems that the tuner modules use fe-ops.write()
for i2c communications, which is set by parent module.
but I'm afraid fe-ops.write() is not for the purpose.
Shouldn't they use i2c_adapters passed from _attach() etc. instead?
regards,
akihiro
--
To unsubscribe from this list: send the
29 matches
Mail list logo
