Re: [PATCH 2/2] [media] bdisp-debug: don't try to divide by s64
Hi Fabien,
Em Thu, 11 Jun 2015 11:26:22 +0200
Fabien DESSENNE fabien.desse...@st.com escreveu:
Hi Mauro,
Please check my comments below.
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab
Sent: mercredi 10 juin 2015 22:59
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab; Mauro Carvalho Chehab; Fabien DESSENNE
Subject: [PATCH 2/2] [media] bdisp-debug: don't try to divide by s64
There are several warnings there, on some architectures, related to dividing
a s32 by a s64 value:
drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: comparison
of distinct pointer types lacks a cast
drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: right shift
count = width of type
drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: passing
argument 1 of '__div64_32' from incompatible pointer type
drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning: comparison
of distinct pointer types lacks a cast
drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning: right shift
count = width of type
drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning: passing
argument 1 of '__div64_32' from incompatible pointer type CC [M]
drivers/media/tuners/mt2060.o
drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning: comparison
of distinct pointer types lacks a cast
drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning: right shift
count = width of type
drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning: passing
argument 1 of '__div64_32' from incompatible pointer type
drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning: comparison
of distinct pointer types lacks a cast
drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning: right shift
count = width of type
drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning: passing
argument 1 of '__div64_32' from incompatible pointer type
That doesn't make much sense. What the driver is actually trying to do is to
divide one second by a value. So, check the range before dividing. That
warrants the right result and will remove the warnings on non-64 bits archs.
Also fixes this warning:
drivers/media/platform/sti/bdisp/bdisp-debug.c:588: warning: comparison
of distinct pointer types lacks a cast
by using div64_s64() instead of calling do_div() directly.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/platform/sti/bdisp/bdisp-debug.c
b/drivers/media/platform/sti/bdisp/bdisp-debug.c
index 7c3a632746ba..3f6f411aafdd 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-debug.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-debug.c
@@ -572,6 +572,8 @@ static int bdisp_dbg_regs(struct seq_file *s, void
*data)
return 0;
}
+#define SECOND 100
+
static int bdisp_dbg_perf(struct seq_file *s, void *data) {
struct bdisp_dev *bdisp = s-private;
@@ -585,16 +587,27 @@ static int bdisp_dbg_perf(struct seq_file *s, void
*data)
}
avg_time_us = bdisp-dbg.tot_duration;
When using div64_s64 the above line can be deleted, see my next comment.
- do_div(avg_time_us, request-nb_req);
-
- avg_fps = 100;
- min_fps = 100;
- max_fps = 100;
- last_fps = 100;
- do_div(avg_fps, avg_time_us);
- do_div(min_fps, bdisp-dbg.min_duration);
- do_div(max_fps, bdisp-dbg.max_duration);
- do_div(last_fps, bdisp-dbg.last_duration);
+ div64_s64(avg_time_us, request-nb_req);
The operation result is returned by div64_s64(different from do_div that
updates the 1st parameter).
The expected syntax is:
avg_time_us = div64_s64(bdisp-dbg.tot_duration, request-nb_req);
+
+ if (avg_time_us SECOND)
+ avg_fps = 0;
+ else
+ avg_fps = SECOND / (s32)avg_time_us;
+
+ if (bdisp-dbg.min_duration SECOND)
+ min_fps = 0;
+ else
+ min_fps = SECOND / (s32)bdisp-dbg.min_duration);
It probably builds better without the last unexpected parenthesis ;)
Gah, a left-over... I did a first version using a different syntax.
See version 2 below.
+
+ if (bdisp-dbg.max_duration SECOND)
+ max_fps = 0;
+ else
+ max_fps = SECOND / (s32)bdisp-dbg.max_duration;
+
+ if (bdisp-dbg.last_duration SECOND)
+ last_fps = 0;
+ else
+ last_fps = SECOND / (s32)bdisp-dbg.last_duration;
seq_printf(s, HW processing (%d requests):\n, request-nb_req);
seq_printf(s, Average: %5lld us (%3d fps)\n,
--
2.4.2
[PATCHv2] [media] bdisp-debug: don't try to divide by s64
There are several warnings there, on some architectures, related
to dividing a s32 by a s64 value:
drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: comparison of
distinct pointer types lacks a cast
Re: [git:media_tree/master] [media] vb2: Push mmap_sem down to memops
Jan,
This patch causes a regressing in videobuf2-dma-sg with a potential deadlock:
[ 82.290231] ==
[ 82.290232] [ INFO: possible circular locking dependency detected ]
[ 82.290235] 4.1.0-rc3-tb1 #12 Not tainted
[ 82.290236] ---
[ 82.290238] qv4l2/1262 is trying to acquire lock:
[ 82.290240] (mm-mmap_sem){++}, at: [a007a870]
vb2_dma_sg_put_userptr+0xf0/0x170 [videobuf2_dma_sg]
[ 82.290247]
but task is already holding lock:
[ 82.290249] (q-mmap_lock){+.+.+.}, at: [a006a9ec]
__reqbufs.isra.13+0x7c/0x410 [videobuf2_core]
[ 82.290255]
which lock already depends on the new lock.
[ 82.290257]
the existing dependency chain (in reverse order) is:
[ 82.290259]
- #1 (q-mmap_lock){+.+.+.}:
[ 82.290262][8110bab9] lock_acquire+0xc9/0x290
[ 82.290267][81a9fc1e] mutex_lock_nested+0x4e/0x3f0
[ 82.290270][a00654a2] vb2_mmap+0x232/0x350 [videobuf2_core]
[ 82.290273][a0067ab5] vb2_fop_mmap+0x25/0x30
[videobuf2_core]
[ 82.290276][a002d11a] v4l2_mmap+0x5a/0x90 [videodev]
[ 82.290281][811f4bcb] mmap_region+0x3bb/0x5f0
[ 82.290285][811f511f] do_mmap_pgoff+0x31f/0x400
[ 82.290288][811dfbe0] vm_mmap_pgoff+0x90/0xc0
[ 82.290291][811f35af] SyS_mmap_pgoff+0x1df/0x290
[ 82.290294][8105ef42] SyS_mmap+0x22/0x30
[ 82.290297][81aa4517] system_call_fastpath+0x12/0x6f
[ 82.290300]
- #0 (mm-mmap_sem){++}:
[ 82.290303][8110adb3] __lock_acquire+0x1d53/0x1fe0
[ 82.290306][8110bab9] lock_acquire+0xc9/0x290
[ 82.290308][81aa1924] down_read+0x34/0x50
[ 82.290311][a007a870] vb2_dma_sg_put_userptr+0xf0/0x170
[videobuf2_dma_sg]
[ 82.290314][a0066656] __vb2_queue_free+0x156/0x5f0
[videobuf2_core]
[ 82.290317][a006aa0f] __reqbufs.isra.13+0x9f/0x410
[videobuf2_core]
[ 82.290320][a006b084] vb2_ioctl_reqbufs+0x74/0xb0
[videobuf2_core]
[ 82.290323][a0033d83] v4l_reqbufs+0x43/0x50 [videodev]
[ 82.290327][a00329f4] __video_do_ioctl+0x274/0x310
[videodev]
[ 82.290331][a00349a8] video_usercopy+0x378/0x8f0 [videodev]
[ 82.290336][a0034f35] video_ioctl2+0x15/0x20 [videodev]
[ 82.290340][a002d6d0] v4l2_ioctl+0xd0/0xf0 [videodev]
[ 82.290343][81238258] do_vfs_ioctl+0x308/0x540
[ 82.290347][81238511] SyS_ioctl+0x81/0xa0
[ 82.290349][81aa4517] system_call_fastpath+0x12/0x6f
[ 82.290352]
other info that might help us debug this:
[ 82.290354] Possible unsafe locking scenario:
[ 82.290356]CPU0CPU1
[ 82.290357]
[ 82.290358] lock(q-mmap_lock);
[ 82.290360]lock(mm-mmap_sem);
[ 82.290362]lock(q-mmap_lock);
[ 82.290365] lock(mm-mmap_sem);
[ 82.290367]
*** DEADLOCK ***
[ 82.290369] 2 locks held by qv4l2/1262:
[ 82.290370] #0: (s-lock){+.+.+.}, at: [a002d65f]
v4l2_ioctl+0x5f/0xf0 [videodev]
[ 82.290376] #1: (q-mmap_lock){+.+.+.}, at: [a006a9ec]
__reqbufs.isra.13+0x7c/0x410 [videobuf2_core]
[ 82.290382]
stack backtrace:
[ 82.290385] CPU: 1 PID: 1262 Comm: qv4l2 Not tainted 4.1.0-rc3-tb1 #12
[ 82.290387] Hardware name: /DH67CF, BIOS
BLH6710H.86A.0105.2011.0301.1654 03/01/2011
[ 82.290388] 82c46890 8800b4bfb968 81a98687
0007
[ 82.290392] 82c46890 8800b4bfb9b8 8110785d
[ 82.290395] 8800b4bfba28 0001 8800d51ce718
0001
[ 82.290399] Call Trace:
[ 82.290402] [81a98687] dump_stack+0x4f/0x7b
[ 82.290405] [8110785d] print_circular_bug+0x1cd/0x230
[ 82.290407] [8110adb3] __lock_acquire+0x1d53/0x1fe0
[ 82.290411] [812142b9] ? kfree+0x169/0x570
[ 82.290414] [8110bab9] lock_acquire+0xc9/0x290
[ 82.290416] [a007a870] ? vb2_dma_sg_put_userptr+0xf0/0x170
[videobuf2_dma_sg]
[ 82.290419] [81aa1924] down_read+0x34/0x50
[ 82.290421] [a007a870] ? vb2_dma_sg_put_userptr+0xf0/0x170
[videobuf2_dma_sg]
[ 82.290424] [a007a870] vb2_dma_sg_put_userptr+0xf0/0x170
[videobuf2_dma_sg]
[ 82.290427] [a0066656] __vb2_queue_free+0x156/0x5f0
[videobuf2_core]
[ 82.290430] [a006aa0f] __reqbufs.isra.13+0x9f/0x410
[videobuf2_core]
[ 82.290434] [811c8a59] ? free_hot_cold_page+0x159/0x200
[ 82.290437] [a006b084]
Re: [PATCH 0/9] Helper to abstract vma handling in media layer
Hi Andrew, I discovered a regression on a prerequisite patch merged in the media tree that until solved prevents parts of this patch series from going in. See: http://www.mail-archive.com/linux-media@vger.kernel.org/msg89538.html Jan is on vacation, and I don't know if I have time this weekend to dig into this, so the patch that caused the regression may have to be reverted for 4.2 and the vb2 patches in this series postponed until the regression problem is fixed. Note that this is all v4l/vb2 related, the get_vaddr_frames helper is actually fine and could be merged, it's just the vb2 patches in this patch series that cannot be merged for now due to deadlocks. Regards, Hans On 06/10/15 11:20, Mauro Carvalho Chehab wrote: Hi Andrew, I received this patch series with a new set of helper functions for mm, together with changes for media and DRM drivers. As this stuff is actually mm code, I prefer if this got merged via your tree. Could you please handle it? Please notice that patch 8 actually changes the exynos DRM driver, but it misses ack from DRM people. Regards, Mauro Jan Kara (9): mm: Provide new get_vaddr_frames() helper [media] media: omap_vout: Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns() [media] vb2: Provide helpers for mapping virtual addresses [media] media: vb2: Convert vb2_dma_sg_get_userptr() to use frame vector [media] media: vb2: Convert vb2_vmalloc_get_userptr() to use frame vector [media] media: vb2: Convert vb2_dc_get_userptr() to use frame vector [media] media: vb2: Remove unused functions [media] drm/exynos: Convert g2d_userptr_get_dma_addr() to use get_vaddr_frames() [media] mm: Move get_vaddr_frames() behind a config option drivers/gpu/drm/exynos/Kconfig | 1 + drivers/gpu/drm/exynos/exynos_drm_g2d.c| 95 -- drivers/gpu/drm/exynos/exynos_drm_gem.c| 97 --- drivers/media/platform/omap/Kconfig| 1 + drivers/media/platform/omap/omap_vout.c| 69 drivers/media/v4l2-core/Kconfig| 1 + drivers/media/v4l2-core/videobuf2-dma-contig.c | 214 --- drivers/media/v4l2-core/videobuf2-dma-sg.c | 99 ++- drivers/media/v4l2-core/videobuf2-memops.c | 156 ++--- drivers/media/v4l2-core/videobuf2-vmalloc.c| 92 -- include/linux/mm.h | 44 + include/media/videobuf2-memops.h | 11 +- mm/Kconfig | 3 + mm/Makefile| 1 + mm/frame_vector.c | 232 + mm/gup.c | 1 + 16 files changed, 486 insertions(+), 631 deletions(-) create mode 100644 mm/frame_vector.c -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] [media] bdisp-debug: don't try to divide by s64
Hi Mauro,
Please check my comments below.
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab
Sent: mercredi 10 juin 2015 22:59
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab; Mauro Carvalho Chehab; Fabien DESSENNE
Subject: [PATCH 2/2] [media] bdisp-debug: don't try to divide by s64
There are several warnings there, on some architectures, related to dividing
a s32 by a s64 value:
drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: comparison
of distinct pointer types lacks a cast
drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: right shift
count = width of type
drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: passing
argument 1 of '__div64_32' from incompatible pointer type
drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning: comparison
of distinct pointer types lacks a cast
drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning: right shift
count = width of type
drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning: passing
argument 1 of '__div64_32' from incompatible pointer type CC [M]
drivers/media/tuners/mt2060.o
drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning: comparison
of distinct pointer types lacks a cast
drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning: right shift
count = width of type
drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning: passing
argument 1 of '__div64_32' from incompatible pointer type
drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning: comparison
of distinct pointer types lacks a cast
drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning: right shift
count = width of type
drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning: passing
argument 1 of '__div64_32' from incompatible pointer type
That doesn't make much sense. What the driver is actually trying to do is to
divide one second by a value. So, check the range before dividing. That
warrants the right result and will remove the warnings on non-64 bits archs.
Also fixes this warning:
drivers/media/platform/sti/bdisp/bdisp-debug.c:588: warning: comparison
of distinct pointer types lacks a cast
by using div64_s64() instead of calling do_div() directly.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/platform/sti/bdisp/bdisp-debug.c
b/drivers/media/platform/sti/bdisp/bdisp-debug.c
index 7c3a632746ba..3f6f411aafdd 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-debug.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-debug.c
@@ -572,6 +572,8 @@ static int bdisp_dbg_regs(struct seq_file *s, void
*data)
return 0;
}
+#define SECOND 100
+
static int bdisp_dbg_perf(struct seq_file *s, void *data) {
struct bdisp_dev *bdisp = s-private;
@@ -585,16 +587,27 @@ static int bdisp_dbg_perf(struct seq_file *s, void
*data)
}
avg_time_us = bdisp-dbg.tot_duration;
When using div64_s64 the above line can be deleted, see my next comment.
- do_div(avg_time_us, request-nb_req);
-
- avg_fps = 100;
- min_fps = 100;
- max_fps = 100;
- last_fps = 100;
- do_div(avg_fps, avg_time_us);
- do_div(min_fps, bdisp-dbg.min_duration);
- do_div(max_fps, bdisp-dbg.max_duration);
- do_div(last_fps, bdisp-dbg.last_duration);
+ div64_s64(avg_time_us, request-nb_req);
The operation result is returned by div64_s64(different from do_div that
updates the 1st parameter).
The expected syntax is:
avg_time_us = div64_s64(bdisp-dbg.tot_duration, request-nb_req);
+
+ if (avg_time_us SECOND)
+ avg_fps = 0;
+ else
+ avg_fps = SECOND / (s32)avg_time_us;
+
+ if (bdisp-dbg.min_duration SECOND)
+ min_fps = 0;
+ else
+ min_fps = SECOND / (s32)bdisp-dbg.min_duration);
It probably builds better without the last unexpected parenthesis ;)
+
+ if (bdisp-dbg.max_duration SECOND)
+ max_fps = 0;
+ else
+ max_fps = SECOND / (s32)bdisp-dbg.max_duration;
+
+ if (bdisp-dbg.last_duration SECOND)
+ last_fps = 0;
+ else
+ last_fps = SECOND / (s32)bdisp-dbg.last_duration;
seq_printf(s, HW processing (%d requests):\n, request-nb_req);
seq_printf(s, Average: %5lld us (%3d fps)\n,
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in the
body of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] v4l: omap4iss: DT bindings development
Hi Michael, On Sunday 07 June 2015 17:35:48 Michael Allwright wrote: Thanks for the patch Laurent! I have found out now what I have missed, I did not declare the DMA channels in my DT. I'm now able to capture frames at 720p. VGA and QVGA frames are coming out grainy and discoloured for the moment so this will require some further investigation. See: QVGA - https://db.tt/Asyq0xj8 VGA - https://db.tt/BIy8oVDv 720P - https://db.tt/32c9aEOF I will slowly move forwards now and develop a set of patches that allow for the ISS to work on a mainline DT enabled kernel. Please feel free to post patches incrementally, you don't have to fix all problems in one go. It will actually be easier for me to review the patches if they're sent incrementally than in one large series. I think it is also necessary to extend the V4L2 API slightly to create a function called v4l2_of_parse_sensor_bus which takes a remote endpoint and returns the underlying control bus (generally i2c) following what is outlined in Documentation/devicetree/bindings/media/video-interfaces.txt - This is required for setting up V4L2 asynchronous match between the sensor and the ISS. I'm not convinced about that. Can't you just use V4L2_ASYNC_MATCH_OF instead of V4L2_ASYNC_MATCH_I2C ? Thanks again for the support everyone! You're welcome. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] [media] media: omap_vout: Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns()
Hello,
(CC'ing Tomi Valkeinen)
On Wednesday 10 June 2015 06:20:45 Mauro Carvalho Chehab wrote:
From: Jan Kara j...@suse.cz
Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns() instead of
hand made mapping of virtual address to physical address. Also the
function leaked page reference from get_user_pages() so fix that by
properly release the reference when omap_vout_buffer_release() is
called.
Signed-off-by: Jan Kara j...@suse.cz
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
[hans.verk...@cisco.com: remove unused struct omap_vout_device *vout
variable]
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/platform/omap/omap_vout.c
b/drivers/media/platform/omap/omap_vout.c index f09c5f17a42f..7feb6394f111
100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -195,46 +195,34 @@ static int omap_vout_try_format(struct v4l2_pix_format
*pix) }
/*
- * omap_vout_uservirt_to_phys: This inline function is used to convert user
- * space virtual address to physical address.
+ * omap_vout_get_userptr: Convert user space virtual address to physical
+ * address.
*/
-static unsigned long omap_vout_uservirt_to_phys(unsigned long virtp)
+static int omap_vout_get_userptr(struct videobuf_buffer *vb, u32 virtp,
+ u32 *physp)
{
- unsigned long physp = 0;
- struct vm_area_struct *vma;
- struct mm_struct *mm = current-mm;
+ struct frame_vector *vec;
+ int ret;
/* For kernel direct-mapped memory, take the easy way */
- if (virtp = PAGE_OFFSET)
- return virt_to_phys((void *) virtp);
-
- down_read(current-mm-mmap_sem);
- vma = find_vma(mm, virtp);
- if (vma (vma-vm_flags VM_IO) vma-vm_pgoff) {
- /* this will catch, kernel-allocated, mmaped-to-usermode
-addresses */
- physp = (vma-vm_pgoff PAGE_SHIFT) + (virtp - vma-vm_start);
- up_read(current-mm-mmap_sem);
- } else {
- /* otherwise, use get_user_pages() for general userland pages */
- int res, nr_pages = 1;
- struct page *pages;
+ if (virtp = PAGE_OFFSET) {
+ *physp = virt_to_phys((void *)virtp);
Lovely. virtp comes from userspace and as far as I know it arrives here
completely unchecked. The problem isn't introduced by this patch, but
omap_vout buffer management seems completely broken to me, and nobody seems to
care about the driver. Given that omapdrm should now provide the video output
capabilities that are missing from omapfb and resulted in the development of
omap_vout, shouldn't we drop the omap_vout driver ?
Tomi, any opinion on this ? Do you see any omap_vout capability missing from
omapdrm ?
+ return 0;
+ }
- res = get_user_pages(current, current-mm, virtp, nr_pages, 1,
- 0, pages, NULL);
- up_read(current-mm-mmap_sem);
+ vec = frame_vector_create(1);
+ if (!vec)
+ return -ENOMEM;
- if (res == nr_pages) {
- physp = __pa(page_address(pages[0]) +
- (virtp ~PAGE_MASK));
- } else {
- printk(KERN_WARNING VOUT_NAME
- get_user_pages failed\n);
- return 0;
- }
+ ret = get_vaddr_frames(virtp, 1, true, false, vec);
+ if (ret != 1) {
+ frame_vector_destroy(vec);
+ return -EINVAL;
}
+ *physp = __pfn_to_phys(frame_vector_pfns(vec)[0]);
+ vb-priv = vec;
- return physp;
+ return 0;
}
/*
@@ -784,11 +772,15 @@ static int omap_vout_buffer_prepare(struct
videobuf_queue *q, * address of the buffer
*/
if (V4L2_MEMORY_USERPTR == vb-memory) {
+ int ret;
+
if (0 == vb-baddr)
return -EINVAL;
/* Physical address */
- vout-queued_buf_addr[vb-i] = (u8 *)
- omap_vout_uservirt_to_phys(vb-baddr);
+ ret = omap_vout_get_userptr(vb, vb-baddr,
+ (u32 *)vout-queued_buf_addr[vb-i]);
+ if (ret 0)
+ return ret;
} else {
unsigned long addr, dma_addr;
unsigned long size;
@@ -834,12 +826,13 @@ static void omap_vout_buffer_queue(struct
videobuf_queue *q, static void omap_vout_buffer_release(struct
videobuf_queue *q,
struct videobuf_buffer *vb)
{
- struct omap_vout_device *vout = q-priv_data;
-
vb-state = VIDEOBUF_NEEDS_INIT;
+ if (vb-memory == V4L2_MEMORY_USERPTR vb-priv) {
+ struct frame_vector *vec = vb-priv;
- if (V4L2_MEMORY_MMAP != vout-memory)
- return;
+ put_vaddr_frames(vec);
+
Re: [PATCH] treewide: Fix typo compatability - compatibility
Hello, On Wednesday 10 June 2015 13:00:20 Masanari Iida wrote: On Wed, Jun 10, 2015 at 7:27 AM, Mauro Carvalho Chehab wrote: Em Wed, 27 May 2015 15:05:42 +0300 Laurent Pinchart laurent.pinch...@ideasonboard.com escreveu: Even though 'compatability' has a dedicated entry in the Wiktionary, it's listed as 'Mispelling of compatibility'. Fix it. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com --- arch/metag/include/asm/elf.h | 2 +- arch/powerpc/kvm/book3s.c| 2 +- arch/sparc/include/uapi/asm/pstate.h | 2 +- drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- drivers/media/dvb-frontends/au8522_dig.c | 2 +- drivers/net/wireless/ipw2x00/ipw2100.h | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) I can split this into one patch per subsystem, but that seems a bit overkill. Can someone take it ? Who? That's the problem with treewide patches ;) Perhaps you should re-submit it with the acks you got to akpm. Laurent, Please re-submit your patch to triv...@kernel.org with [trivial] in the title. Ex. [PATCH] [trivial] treewide: Fix typo compatability - compatibility Done, thank you. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: uvc: add support for the Microsoft Surface Pro 3 Cameras
Hi Dennis, On Tuesday 09 June 2015 18:40:41 Dennis Chen wrote: Is this needed ? Looking at the patch your cameras are UVC-compliant and should thus be picked by the uvcvideo driver without any change to the code. The cameras are UVC-compliant but are not recognized by the uvc driver. The patch forces the uvc driver to pick up the camera if present. Could you please send me the output of 'lsusb -v -d 045e:07be' and 'lsusb -v - d 045e:07bf' (running as root if possible) ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Obtain Si2157 and LGDT3306A signal stats from HVR955Q?
Thanks for confirming the HVR-955Q SNR and other data is available via the DVBv5 API. Before switching my signal/antenna test programs to DVBv5, 'll see if I can figure out why the dvb-fe-tool is not returning the SNR data and error rate statistics from the HVR-955Q even though it does return this info from other Hauppauge USB tuners like the Aero-M. Perhaps I missed an update. I may be back with more questions! ...Doug On Mon, Jun 8, 2015 at 1:59 AM, Antti Palosaari cr...@iki.fi wrote: Moikka! On 06/08/2015 01:21 AM, Doug Lung wrote: Hello! this is my first post here, although I've benefited from all the work of the contributors over the year. Thanks! I'm looking for help getting similar signal statistics from the new Hauppauge HVR955Q (Si2157, LGDT3306A, CX23102) USB ATSC tuner that I'm now getting from the Hauppauge Aero-M (MxL111SF, LGDT3305). I'm currently using DVBv3 API in my programs but am open to switching to the DVBv5 API if necessary. I applied Antti Palosaari's si2157: implement signal strength stats patch to the media_build and dvb-fe-tool with dvbv5-zap now returns relatively accurate RSSI data in dBm from the HVR955Q but no SNR or packet error data. dvb-fe-tool provides a full set of data (unformatted) from the Aero-M but only Lock and RSSI (formatted in dBm) from the HVR955Q. The SNR and packet error data is available from the HVR955Q in raw form in DVBv3 applications like femon. The Si2157 RSSI in dBm is not. The DVBv3 apps show the signal quality based on SNR margin above threshold from the LGDT3306A. Any suggestions on modifying the HVR955Q driver to provide RSSI (unformatted is okay) from the Si2157 with the DVBv3 API? That's preferred since it will work with my existing Aero-M signal testing programs. Alternatively, is there a way to obtain full DVBv5 API compliant signal quality data (RSSI, SNR, uncorrected packets) from the HVR955Q's LGDT3306A so I can modify my programs to use the linuxdvb.py API v5.1 bindings? Looking the LGDT3306A code reveals it already calculates SNR as dB, so returning it via DVBv5 is easy. BER and UCB are returned as a raw error values from registers. You could return those also as a error values by counter type easily (numerator of fraction). But getting some useful values you will need also total number of packets too (denominator) (error fraction = error count / total count). Total count is not mandatory, but very recommend, you have to find it some how, calculate from stream parameters for example. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/3] linux: address broken PAT drivers
On Mon, Jun 08, 2015 at 09:57:12PM -0300, Mauro Carvalho Chehab wrote: Em Mon, 08 Jun 2015 17:20:19 -0700 Luis R. Rodriguez mcg...@do-not-panic.com escreveu: From: Luis R. Rodriguez mcg...@suse.com Mauro, since the ivtv patch is already acked by the driver maintainer and depends on an x86 symbol that went through Boris' tree are you OK in it going through Boris' tree? Sure. I just find a minor issues there. After they got solved, feel free to submit to Boris with my ack. OK thanks, I just fixed that, will send now to Boris. Luis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] [media] media: omap_vout: Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns()
On 06/11/15 06:21, Laurent Pinchart wrote:
Hello,
(CC'ing Tomi Valkeinen)
On Wednesday 10 June 2015 06:20:45 Mauro Carvalho Chehab wrote:
From: Jan Kara j...@suse.cz
Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns() instead of
hand made mapping of virtual address to physical address. Also the
function leaked page reference from get_user_pages() so fix that by
properly release the reference when omap_vout_buffer_release() is
called.
Signed-off-by: Jan Kara j...@suse.cz
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
[hans.verk...@cisco.com: remove unused struct omap_vout_device *vout
variable]
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/platform/omap/omap_vout.c
b/drivers/media/platform/omap/omap_vout.c index f09c5f17a42f..7feb6394f111
100644
--- a/drivers/media/platform/omap/omap_vout.c
+++ b/drivers/media/platform/omap/omap_vout.c
@@ -195,46 +195,34 @@ static int omap_vout_try_format(struct v4l2_pix_format
*pix) }
/*
- * omap_vout_uservirt_to_phys: This inline function is used to convert user
- * space virtual address to physical address.
+ * omap_vout_get_userptr: Convert user space virtual address to physical
+ * address.
*/
-static unsigned long omap_vout_uservirt_to_phys(unsigned long virtp)
+static int omap_vout_get_userptr(struct videobuf_buffer *vb, u32 virtp,
+ u32 *physp)
{
-unsigned long physp = 0;
-struct vm_area_struct *vma;
-struct mm_struct *mm = current-mm;
+struct frame_vector *vec;
+int ret;
/* For kernel direct-mapped memory, take the easy way */
-if (virtp = PAGE_OFFSET)
-return virt_to_phys((void *) virtp);
-
-down_read(current-mm-mmap_sem);
-vma = find_vma(mm, virtp);
-if (vma (vma-vm_flags VM_IO) vma-vm_pgoff) {
-/* this will catch, kernel-allocated, mmaped-to-usermode
- addresses */
-physp = (vma-vm_pgoff PAGE_SHIFT) + (virtp - vma-vm_start);
-up_read(current-mm-mmap_sem);
-} else {
-/* otherwise, use get_user_pages() for general userland pages */
-int res, nr_pages = 1;
-struct page *pages;
+if (virtp = PAGE_OFFSET) {
+*physp = virt_to_phys((void *)virtp);
Lovely. virtp comes from userspace and as far as I know it arrives here
completely unchecked. The problem isn't introduced by this patch, but
omap_vout buffer management seems completely broken to me, and nobody seems
to
care about the driver. Given that omapdrm should now provide the video output
capabilities that are missing from omapfb and resulted in the development of
omap_vout, shouldn't we drop the omap_vout driver ?
In addition it uses the old videobuf framework which at some point will be
reason
for removal if nobody cares enough to convert to videobuf2.
So I would also be in favor of removal if there are no objections (well,
probably
first to staging for one or two kernel cycles followed by removal).
Hans
Tomi, any opinion on this ? Do you see any omap_vout capability missing from
omapdrm ?
+return 0;
+}
-res = get_user_pages(current, current-mm, virtp, nr_pages, 1,
-0, pages, NULL);
-up_read(current-mm-mmap_sem);
+vec = frame_vector_create(1);
+if (!vec)
+return -ENOMEM;
-if (res == nr_pages) {
-physp = __pa(page_address(pages[0]) +
-(virtp ~PAGE_MASK));
-} else {
-printk(KERN_WARNING VOUT_NAME
-get_user_pages failed\n);
-return 0;
-}
+ret = get_vaddr_frames(virtp, 1, true, false, vec);
+if (ret != 1) {
+frame_vector_destroy(vec);
+return -EINVAL;
}
+*physp = __pfn_to_phys(frame_vector_pfns(vec)[0]);
+vb-priv = vec;
-return physp;
+return 0;
}
/*
@@ -784,11 +772,15 @@ static int omap_vout_buffer_prepare(struct
videobuf_queue *q, * address of the buffer
*/
if (V4L2_MEMORY_USERPTR == vb-memory) {
+int ret;
+
if (0 == vb-baddr)
return -EINVAL;
/* Physical address */
-vout-queued_buf_addr[vb-i] = (u8 *)
-omap_vout_uservirt_to_phys(vb-baddr);
+ret = omap_vout_get_userptr(vb, vb-baddr,
+(u32 *)vout-queued_buf_addr[vb-i]);
+if (ret 0)
+return ret;
} else {
unsigned long addr, dma_addr;
unsigned long size;
@@ -834,12 +826,13 @@ static void omap_vout_buffer_queue(struct
videobuf_queue *q, static void omap_vout_buffer_release(struct
videobuf_queue *q,
struct videobuf_buffer *vb)
{
-struct
[PATCH v6 1/3] ivtv: use arch_phys_wc_add() and require PAT disabled
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.
In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.
This is a worthy comprmise given that the hardware is
really rare these days, and perhaps only some lost souls
in some third world country are expected to be using this
feature of the device driver.
Acked-by: Andy Walls awa...@md.metrocast.net
Cc: Andy Walls awa...@md.metrocast.net
Cc: Doug Ledford dledf...@redhat.com
Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Mel Gorman mgor...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Borislav Petkov b...@suse.de
Cc: Davidlohr Bueso dbu...@suse.de
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/media/pci/ivtv/Kconfig | 3 +++
drivers/media/pci/ivtv/ivtvfb.c | 58 -
2 files changed, 26 insertions(+), 35 deletions(-)
diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index dd6ee57e..b2a7f88 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -57,5 +57,8 @@ config VIDEO_FB_IVTV
This is used in the Hauppauge PVR-350 card. There is a driver
homepage at http://www.ivtvdriver.org.
+ If you have this hardware you will need to boot with PAT disabled
+ on your x86 systems, use the nopat kernel parameter.
+
To compile this driver as a module, choose M here: the
module will be called ivtvfb.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..7685ae3 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,8 +44,8 @@
#include linux/ivtvfb.h
#include linux/slab.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
#endif
#include ivtv-driver.h
@@ -155,12 +155,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+ int wc_cookie;
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1098,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
static int ivtvfb_init_io(struct ivtv *itv)
{
struct osd_info *oi = itv-osd_info;
+ /* Find the largest power of two that maps the whole buffer */
+ int size_shift = 31;
mutex_lock(itv-serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1132,29 +1133,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_pbase, oi-video_vbase,
oi-video_buffer_size / 1024);
-#ifdef CONFIG_MTRR
- {
- /* Find the largest power of two that maps the whole buffer */
- int size_shift = 31;
-
- while (!(oi-video_buffer_size (1 size_shift))) {
- size_shift--;
- }
- size_shift++;
- oi-fb_start_aligned_physaddr = oi-video_pbase ~((1
size_shift) - 1);
- oi-fb_end_aligned_physaddr = oi-video_pbase +
oi-video_buffer_size;
- oi-fb_end_aligned_physaddr += (1 size_shift) - 1;
- oi-fb_end_aligned_physaddr = ~((1 size_shift) - 1);
- if (mtrr_add(oi-fb_start_aligned_physaddr,
- oi-fb_end_aligned_physaddr -
oi-fb_start_aligned_physaddr,
-
[PATCH v6 0/3] linux: address broken PAT drivers
From: Luis R. Rodriguez mcg...@suse.com Mauro, since the ivtv patch is already acked by the driver maintainer and depends on an x86 symbol that went through Boris' tree are you OK in it going through Boris' tree? Boris, provided the outcome of the above maintainer's preference for you to merge these please consider these patches for your tree. The maintainer path is the only thing pending for the 1 ivtv patch. The Infiniband subsystem maintainer, Doug, already provided his ACK for the ipath driver and for this to go through you. Luis R. Rodriguez (3): ivtv: use arch_phys_wc_add() and require PAT disabled IB/ipath: add counting for MTRR IB/ipath: use arch_phys_wc_add() and require PAT disabled drivers/infiniband/hw/ipath/Kconfig | 3 ++ drivers/infiniband/hw/ipath/ipath_driver.c| 18 ++--- drivers/infiniband/hw/ipath/ipath_kernel.h| 4 +- drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 43 +--- drivers/media/pci/ivtv/Kconfig| 3 ++ drivers/media/pci/ivtv/ivtvfb.c | 58 +++ 6 files changed, 52 insertions(+), 77 deletions(-) -- 2.3.2.209.gd67f9d5.dirty -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/3] IB/ipath: use arch_phys_wc_add() and require PAT disabled
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.
In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.
This is a worthy compromise given that the ipath device
driver powers the old HTX bus cards that only work in
AMD systems, while the newer IB/qib device driver
powers all PCI-e cards. The ipath device driver is
obsolete, hardware hard to find and because of this
this its a reasonable compromise to make to require
users of ipath to boot with nopat.
Acked-by: Doug Ledford dledf...@redhat.com
Cc: Doug Ledford dledf...@redhat.com
Cc: Andy Walls awa...@md.metrocast.net
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Sean Hefty sean.he...@intel.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
Cc: Mike Marciniszyn mike.marcinis...@intel.com
Cc: Roland Dreier rol...@purestorage.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Mel Gorman mgor...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Borislav Petkov b...@suse.de
Cc: Davidlohr Bueso dbu...@suse.de
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: infinip...@intel.com
Cc: linux-r...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/ipath/Kconfig | 3 ++
drivers/infiniband/hw/ipath/ipath_driver.c| 18 +++
drivers/infiniband/hw/ipath/ipath_kernel.h| 4 +--
drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 43 ++-
4 files changed, 26 insertions(+), 42 deletions(-)
diff --git a/drivers/infiniband/hw/ipath/Kconfig
b/drivers/infiniband/hw/ipath/Kconfig
index 1d9bb11..8fe54ff 100644
--- a/drivers/infiniband/hw/ipath/Kconfig
+++ b/drivers/infiniband/hw/ipath/Kconfig
@@ -9,3 +9,6 @@ config INFINIBAND_IPATH
as IP-over-InfiniBand as well as with userspace applications
(in conjunction with InfiniBand userspace access).
For QLogic PCIe QLE based cards, use the QIB driver instead.
+
+ If you have this hardware you will need to boot with PAT disabled
+ on your x86-64 systems, use the nopat kernel parameter.
diff --git a/drivers/infiniband/hw/ipath/ipath_driver.c
b/drivers/infiniband/hw/ipath/ipath_driver.c
index bd0caed..441cfe5 100644
--- a/drivers/infiniband/hw/ipath/ipath_driver.c
+++ b/drivers/infiniband/hw/ipath/ipath_driver.c
@@ -42,6 +42,9 @@
#include linux/bitmap.h
#include linux/slab.h
#include linux/module.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
+#endif
#include ipath_kernel.h
#include ipath_verbs.h
@@ -395,6 +398,14 @@ static int ipath_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
unsigned long long addr;
u32 bar0 = 0, bar1 = 0;
+#ifdef CONFIG_X86_64
+ if (WARN(pat_enabled(),
+ipath needs PAT disabled, boot with nopat kernel
parameter\n)) {
+ ret = EINVAL;
+ goto bail;
+ }
+#endif
+
dd = ipath_alloc_devdata(pdev);
if (IS_ERR(dd)) {
ret = PTR_ERR(dd);
@@ -542,6 +553,7 @@ static int ipath_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
dd-ipath_kregbase = __ioremap(addr, len,
(_PAGE_NO_CACHE|_PAGE_WRITETHRU));
#else
+ /* XXX: split this properly to enable on PAT */
dd-ipath_kregbase = ioremap_nocache(addr, len);
#endif
@@ -587,12 +599,8 @@ static int ipath_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
ret = ipath_enable_wc(dd);
- if (ret) {
- ipath_dev_err(dd, Write combining not enabled
- (err %d): performance may be poor\n,
- -ret);
+ if (ret)
ret = 0;
- }
[PATCH v6 2/3] IB/ipath: add counting for MTRR
From: Luis R. Rodriguez mcg...@suse.com
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani toshi.k...@hp.com
Cc: Roland Dreier rol...@kernel.org
Cc: Sean Hefty sean.he...@intel.com
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: infinip...@intel.com
Cc: linux-r...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
index 4ad0b93..70c1f3a 100644
--- a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
+++ b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
@@ -127,7 +127,7 @@ int ipath_enable_wc(struct ipath_devdata *dd)
(addr %llx, len=0x%llx)\n,
(unsigned long long) pioaddr,
(unsigned long long) piolen);
- cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 0);
+ cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
if (cookie 0) {
{
dev_info(dd-pcidev-dev,
--
2.3.2.209.gd67f9d5.dirty
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge 2250 on Ubuntu 15.04
On Wed, Jun 10, 2015 at 1:23 PM, Jeff Allen worthspend...@gmail.com wrote: I am trying to get the firmware to load on a fresh install of Ubuntu 15.04 desktop 64-bit on a new system. uname -a Linux 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux That's not going to work. You need to pull tip, compile and install it for HVR2255 support. No amount of specifying card=X on the module load fixes these kinds of issues. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][media] SI2168: Resolve unknown chip version errors with different HVR22x5 models
On Fri, Jun 5, 2015 at 9:40 AM, Olli Salonen olli.salo...@iki.fi wrote: Hi Steven, It seems to me that that part of the code is identical to your driver, no? Sorry for the noise. I'm been swamped with a couple of things and just getting back to the ML now. You are correct. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] Helper to abstract vma handling in media layer
On Thu, 11 Jun 2015 11:08:47 +0200 Hans Verkuil hverk...@xs4all.nl wrote: I discovered a regression on a prerequisite patch merged in the media tree that until solved prevents parts of this patch series from going in. See: http://www.mail-archive.com/linux-media@vger.kernel.org/msg89538.html Jan is on vacation, and I don't know if I have time this weekend to dig into this, so the patch that caused the regression may have to be reverted for 4.2 and the vb2 patches in this series postponed until the regression problem is fixed. Note that this is all v4l/vb2 related, the get_vaddr_frames helper is actually fine and could be merged, it's just the vb2 patches in this patch series that cannot be merged for now due to deadlocks. OK, thanks. I'll just keep these patches on hold (in -next) until advised otherwise? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/3] media: atmel-isi: rework on the clock part and add runtime pm support
Hi Josh, On Thu, 11 Jun 2015, Josh Wu wrote: Hi, Guennadi Any feedback for this patch series? Sorry, I haven't found the time to look at patches from you and William Towle, they are at the top of my todo list now - after all the compulsory things, of course. I'll handle them as soon as I find time. Sorry for the delay. Thanks Guennadi Best Regards, Josh Wu On 5/26/2015 5:54 PM, Josh Wu wrote: This patch series fix the peripheral clock code and enable runtime support. Also it clean up the code which is for the compatiblity of mck. Changes in v5: - add new patch to fix the condition that codec request still in work. - fix the error path in start_streaming() thanks to Laurent. Changes in v4: - need to call pm_runtime_disable() in atmel_isi_remove(). - merged the patch which remove isi disable code in atmel_isi_probe() as isi peripherial clock is not enabled in this moment. - refine the commit log Changes in v3: - remove useless definition: ISI_DEFAULT_MCLK_FREQ Changes in v2: - merged v1 two patch into one. - use runtime_pm_put() instead of runtime_pm_put_sync() - enable peripheral clock before access ISI registers. - totally remove clock_start()/clock_stop() as they are optional. Josh Wu (3): media: atmel-isi: disable ISI even it has codec request in stop_streaming() media: atmel-isi: add runtime pm support media: atmel-isi: remove mck back compatiable code as it's not need drivers/media/platform/soc_camera/atmel-isi.c | 105 -- 1 file changed, 48 insertions(+), 57 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1.3 1/5] v4l: async: Add a pointer to of_node to struct v4l2_subdev, match it
V4L2 async sub-devices are currently matched (OF case) based on the struct
device_node pointer in struct device. LED devices may have more than one
LED, and in that case the OF node to match is not directly the device's
node, but a LED's node.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
since v1.2:
- A - The in the of_node field comment in struct v4l2_subdev.
- A better reason for not taking a reference to the of_node is that a
reference is already there for struct device, pointed to by the dev field
of struct v4l2_subdev. The async sub-device never exists without a device.
drivers/media/v4l2-core/v4l2-async.c | 39 +---
include/media/v4l2-subdev.h | 2 ++
2 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
index 85a6a34..5bada20 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -22,10 +22,10 @@
#include media/v4l2-device.h
#include media/v4l2-subdev.h
-static bool match_i2c(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_i2c(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
#if IS_ENABLED(CONFIG_I2C)
- struct i2c_client *client = i2c_verify_client(dev);
+ struct i2c_client *client = i2c_verify_client(sd-dev);
return client
asd-match.i2c.adapter_id == client-adapter-nr
asd-match.i2c.address == client-addr;
@@ -34,14 +34,24 @@ static bool match_i2c(struct device *dev, struct
v4l2_async_subdev *asd)
#endif
}
-static bool match_devname(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_devname(struct v4l2_subdev *sd,
+ struct v4l2_async_subdev *asd)
{
- return !strcmp(asd-match.device_name.name, dev_name(dev));
+ return !strcmp(asd-match.device_name.name, dev_name(sd-dev));
}
-static bool match_of(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
- return dev-of_node == asd-match.of.node;
+ return sd-of_node == asd-match.of.node;
+}
+
+static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
+{
+ if (!asd-match.custom.match)
+ /* Match always */
+ return true;
+
+ return asd-match.custom.match(sd-dev, asd);
}
static LIST_HEAD(subdev_list);
@@ -51,17 +61,14 @@ static DEFINE_MUTEX(list_lock);
static struct v4l2_async_subdev *v4l2_async_belongs(struct v4l2_async_notifier
*notifier,
struct v4l2_subdev *sd)
{
+ bool (*match)(struct v4l2_subdev *, struct v4l2_async_subdev *);
struct v4l2_async_subdev *asd;
- bool (*match)(struct device *, struct v4l2_async_subdev *);
list_for_each_entry(asd, notifier-waiting, list) {
/* bus_type has been verified valid before */
switch (asd-match_type) {
case V4L2_ASYNC_MATCH_CUSTOM:
- match = asd-match.custom.match;
- if (!match)
- /* Match always */
- return asd;
+ match = match_custom;
break;
case V4L2_ASYNC_MATCH_DEVNAME:
match = match_devname;
@@ -79,7 +86,7 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct
v4l2_async_notifier *
}
/* match cannot be NULL here */
- if (match(sd-dev, asd))
+ if (match(sd, asd))
return asd;
}
@@ -266,6 +273,14 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
{
struct v4l2_async_notifier *notifier;
+ /*
+* No reference taken. The reference is held by the device
+* (struct v4l2_subdev.dev), and async sub-device does not
+* exist independently of the device at any point of time.
+*/
+ if (!sd-of_node sd-dev)
+ sd-of_node = sd-dev-of_node;
+
mutex_lock(list_lock);
INIT_LIST_HEAD(sd-async_list);
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 8f5da73..cdd534b 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -603,6 +603,8 @@ struct v4l2_subdev {
struct video_device *devnode;
/* pointer to the physical device, if any */
struct device *dev;
+ /* The device_node of the subdev, usually the same as dev-of_node. */
+ struct device_node *of_node;
/* Links this subdev to a global subdev_list or @notifier-done list. */
struct list_head async_list;
/* Pointer to respective struct v4l2_async_subdev. */
--
2.1.4
--
To unsubscribe from this list: send the line
Re: Hauppauge 2250 on Ubuntu 15.04
On Thu, Jun 11, 2015 at 2:58 PM, Jeff Allen worthspend...@gmail.com wrote: Thanks, I did that and it is working now. However, I ran into another problem. The card will not scan any channels. I live in the Chicago area and my cable provider is Wowway. Wowway requires a main set top box and digital adapters for every other TV in the home. Cable ready TV's after 2010 are suppose to work without the need for a digital adapter. I have a feeling that the 2255 card I have will not work with my cable provider. Any thoughts? Cc'ing linux-media back in. I'm not aware of any US cable provider that the HVR2255 cannot tune/demodulate. I'd be highly surprised if your HVR2255 isn't delivering packets, unless its faulty. However, depending on your provider, those multiplexes may only contain encrypted tv channels - not watchable by you. I have a handful of channels from my provider that are watchable. 300+ are fully encrypted the data delivered by the card isn't that useful, for encrypted channels. I suggest you share the output from your scan tests with the mailing list and see if anyone can help. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1.3 1/5] v4l: async: Add a pointer to of_node to struct v4l2_subdev, match it
Hi Sakari,
Thank you for the patch.
On Thursday 11 June 2015 22:18:01 Sakari Ailus wrote:
V4L2 async sub-devices are currently matched (OF case) based on the struct
device_node pointer in struct device. LED devices may have more than one
LED, and in that case the OF node to match is not directly the device's
node, but a LED's node.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
since v1.2:
- A - The in the of_node field comment in struct v4l2_subdev.
- A better reason for not taking a reference to the of_node is that a
reference is already there for struct device, pointed to by the dev field
of struct v4l2_subdev. The async sub-device never exists without a device.
drivers/media/v4l2-core/v4l2-async.c | 39 ++---
include/media/v4l2-subdev.h | 2 ++
2 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c index 85a6a34..5bada20 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -22,10 +22,10 @@
#include media/v4l2-device.h
#include media/v4l2-subdev.h
-static bool match_i2c(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_i2c(struct v4l2_subdev *sd, struct v4l2_async_subdev
*asd) {
#if IS_ENABLED(CONFIG_I2C)
- struct i2c_client *client = i2c_verify_client(dev);
+ struct i2c_client *client = i2c_verify_client(sd-dev);
return client
asd-match.i2c.adapter_id == client-adapter-nr
asd-match.i2c.address == client-addr;
@@ -34,14 +34,24 @@ static bool match_i2c(struct device *dev, struct
v4l2_async_subdev *asd) #endif
}
-static bool match_devname(struct device *dev, struct v4l2_async_subdev
*asd) +static bool match_devname(struct v4l2_subdev *sd,
+ struct v4l2_async_subdev *asd)
{
- return !strcmp(asd-match.device_name.name, dev_name(dev));
+ return !strcmp(asd-match.device_name.name, dev_name(sd-dev));
}
-static bool match_of(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
- return dev-of_node == asd-match.of.node;
+ return sd-of_node == asd-match.of.node;
+}
+
+static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev
*asd) +{
+ if (!asd-match.custom.match)
+ /* Match always */
+ return true;
+
+ return asd-match.custom.match(sd-dev, asd);
}
static LIST_HEAD(subdev_list);
@@ -51,17 +61,14 @@ static DEFINE_MUTEX(list_lock);
static struct v4l2_async_subdev *v4l2_async_belongs(struct
v4l2_async_notifier *notifier, struct v4l2_subdev *sd)
{
+ bool (*match)(struct v4l2_subdev *, struct v4l2_async_subdev *);
struct v4l2_async_subdev *asd;
- bool (*match)(struct device *, struct v4l2_async_subdev *);
list_for_each_entry(asd, notifier-waiting, list) {
/* bus_type has been verified valid before */
switch (asd-match_type) {
case V4L2_ASYNC_MATCH_CUSTOM:
- match = asd-match.custom.match;
- if (!match)
- /* Match always */
- return asd;
+ match = match_custom;
break;
case V4L2_ASYNC_MATCH_DEVNAME:
match = match_devname;
@@ -79,7 +86,7 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct
v4l2_async_notifier * }
/* match cannot be NULL here */
- if (match(sd-dev, asd))
+ if (match(sd, asd))
return asd;
}
@@ -266,6 +273,14 @@ int v4l2_async_register_subdev(struct v4l2_subdev *sd)
{
struct v4l2_async_notifier *notifier;
+ /*
+ * No reference taken. The reference is held by the device
+ * (struct v4l2_subdev.dev), and async sub-device does not
+ * exist independently of the device at any point of time.
+ */
+ if (!sd-of_node sd-dev)
+ sd-of_node = sd-dev-of_node;
+
mutex_lock(list_lock);
INIT_LIST_HEAD(sd-async_list);
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 8f5da73..cdd534b 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -603,6 +603,8 @@ struct v4l2_subdev {
struct video_device *devnode;
/* pointer to the physical device, if any */
struct device *dev;
+ /* The device_node of the subdev, usually the same as dev-of_node. */
+ struct device_node *of_node;
/* Links this subdev to a global subdev_list or @notifier-done list. */
struct list_head async_list;
/* Pointer to respective
Re: [PATCH 1/2] saa7164: change Si2168 reglen to 0 bit
On Sat, Jun 6, 2015 at 3:44 AM, Olli Salonen olli.salo...@iki.fi wrote: The i2c_reg_len for Si2168 should be 0 for correct I2C communication. Signed-off-by: Olli Salonen olli.salo...@iki.fi Tested-By: Steven Toth st...@kernellabs.com Checked with a HVR-2205 and a HVR-2215, firmware loads as expected. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Revert [media] saa7164: Improvements for I2C handling
On Sat, Jun 6, 2015 at 3:44 AM, Olli Salonen olli.salo...@iki.fi wrote: This reverts commit ad90b6b0f10566d4a5546e27fe455ce3b5e6b6c7. This patch breaks I2C communication towards Si2168. After reverting and applying the other patch in this series the I2C communication is correct. Tested-By: Steven Toth st...@kernellabs.com Checked with a HVR-2205 and a HVR-2215, firmware loads as expected. Thanks for chasing this down Olli. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] genalloc: rename dev_get_gen_pool() to gen_pool_get()
Le 11/06/2015 15:28, Vladimir Zapolskiy a écrit :
To be consistent with other genalloc interface namings, rename
dev_get_gen_pool() to gen_pool_get(). The original omitted dev_
prefix is removed, since it points to argument type of the function,
and so it does not bring any useful information.
Signed-off-by: Vladimir Zapolskiy vladimir_zapols...@mentor.com
---
arch/arm/mach-at91/pm.c | 2 +-
arch/arm/mach-imx/pm-imx5.c | 2 +-
arch/arm/mach-imx/pm-imx6.c | 2 +-
drivers/media/platform/coda/coda-common.c | 2 +-
include/linux/genalloc.h | 2 +-
lib/genalloc.c| 8
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 1e18476..e24df77 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -369,7 +369,7 @@ static void __init at91_pm_sram_init(void)
return;
}
- sram_pool = dev_get_gen_pool(pdev-dev);
+ sram_pool = gen_pool_get(pdev-dev);
if (!sram_pool) {
pr_warn(%s: sram pool unavailable!\n, __func__);
return;
No blocked on my side. For AT91:
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index 0309ccd..1885676 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -297,7 +297,7 @@ static int __init imx_suspend_alloc_ocram(
goto put_node;
}
- ocram_pool = dev_get_gen_pool(pdev-dev);
+ ocram_pool = gen_pool_get(pdev-dev);
if (!ocram_pool) {
pr_warn(%s: ocram pool unavailable!\n, __func__);
ret = -ENODEV;
diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
index b01650d..93ecf55 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -451,7 +451,7 @@ static int __init imx6q_suspend_init(const struct
imx6_pm_socdata *socdata)
goto put_node;
}
- ocram_pool = dev_get_gen_pool(pdev-dev);
+ ocram_pool = gen_pool_get(pdev-dev);
if (!ocram_pool) {
pr_warn(%s: ocram pool unavailable!\n, __func__);
ret = -ENODEV;
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 6d6e0ca..6e640c0 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -2157,7 +2157,7 @@ static int coda_probe(struct platform_device *pdev)
/* Get IRAM pool from device tree or platform data */
pool = of_get_named_gen_pool(np, iram, 0);
if (!pool pdata)
- pool = dev_get_gen_pool(pdata-iram_dev);
+ pool = gen_pool_get(pdata-iram_dev);
if (!pool) {
dev_err(pdev-dev, iram pool not available\n);
return -ENOMEM;
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 1ccaab4..015d170 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -119,7 +119,7 @@ extern unsigned long gen_pool_best_fit(unsigned long
*map, unsigned long size,
extern struct gen_pool *devm_gen_pool_create(struct device *dev,
int min_alloc_order, int nid);
-extern struct gen_pool *dev_get_gen_pool(struct device *dev);
+extern struct gen_pool *gen_pool_get(struct device *dev);
bool addr_in_gen_pool(struct gen_pool *pool, unsigned long start,
size_t size);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index d214866..948e92c 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -602,12 +602,12 @@ struct gen_pool *devm_gen_pool_create(struct device
*dev, int min_alloc_order,
EXPORT_SYMBOL(devm_gen_pool_create);
/**
- * dev_get_gen_pool - Obtain the gen_pool (if any) for a device
+ * gen_pool_get - Obtain the gen_pool (if any) for a device
* @dev: device to retrieve the gen_pool from
*
* Returns the gen_pool for the device if one is present, or NULL.
*/
-struct gen_pool *dev_get_gen_pool(struct device *dev)
+struct gen_pool *gen_pool_get(struct device *dev)
{
struct gen_pool **p = devres_find(dev, devm_gen_pool_release, NULL,
NULL);
@@ -616,7 +616,7 @@ struct gen_pool *dev_get_gen_pool(struct device *dev)
return NULL;
return *p;
}
-EXPORT_SYMBOL_GPL(dev_get_gen_pool);
+EXPORT_SYMBOL_GPL(gen_pool_get);
#ifdef CONFIG_OF
/**
@@ -642,7 +642,7 @@ struct gen_pool *of_get_named_gen_pool(struct device_node
*np,
of_node_put(np_pool);
if (!pdev)
return NULL;
- return dev_get_gen_pool(pdev-dev);
+ return gen_pool_get(pdev-dev);
}
EXPORT_SYMBOL_GPL(of_get_named_gen_pool);
#endif /* CONFIG_OF */
--
Nicolas Ferre
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
Re: [PATCH 0/9] Helper to abstract vma handling in media layer
On 06/11/2015 08:54 PM, Andrew Morton wrote: On Thu, 11 Jun 2015 11:08:47 +0200 Hans Verkuil hverk...@xs4all.nl wrote: I discovered a regression on a prerequisite patch merged in the media tree that until solved prevents parts of this patch series from going in. See: http://www.mail-archive.com/linux-media@vger.kernel.org/msg89538.html Jan is on vacation, and I don't know if I have time this weekend to dig into this, so the patch that caused the regression may have to be reverted for 4.2 and the vb2 patches in this series postponed until the regression problem is fixed. Note that this is all v4l/vb2 related, the get_vaddr_frames helper is actually fine and could be merged, it's just the vb2 patches in this patch series that cannot be merged for now due to deadlocks. OK, thanks. I'll just keep these patches on hold (in -next) until advised otherwise? Yes, that would be great. Thanks, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/3] IB/ipath: add counting for MTRR
On Thu, Jun 11, 2015 at 10:50:01AM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani toshi.k...@hp.com
Cc: Roland Dreier rol...@kernel.org
Cc: Sean Hefty sean.he...@intel.com
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: infinip...@intel.com
Cc: linux-r...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
index 4ad0b93..70c1f3a 100644
--- a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
+++ b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
@@ -127,7 +127,7 @@ int ipath_enable_wc(struct ipath_devdata *dd)
(addr %llx, len=0x%llx)\n,
(unsigned long long) pioaddr,
(unsigned long long) piolen);
- cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 0);
+ cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
if (cookie 0) {
{
dev_info(dd-pcidev-dev,
--
Doug, ack?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/3] linux: address broken PAT drivers
On Thu, Jun 11, 2015 at 10:49:59AM -0700, Luis R. Rodriguez wrote: From: Luis R. Rodriguez mcg...@suse.com Mauro, since the ivtv patch is already acked by the driver maintainer and depends on an x86 symbol that went through Boris' tree are you OK in it going through Boris' tree? Sorry I resent v6 by mistake, will send the v7 with the fix you requested. Luis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: uvc: add support for the Microsoft Surface Pro 3 Cameras
Could you please send me the output of 'lsusb -v -d 045e:07be' and
'lsusb -v -
d 045e:07bf' (running as root if possible) ?
Bus 001 Device 004: ID 045e:07bf Microsoft Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2 ?
bDeviceProtocol 1 Interface Association
bMaxPacketSize064
idVendor 0x045e Microsoft Corp.
idProduct 0x07bf
bcdDevice 21.52
iManufacturer 1 QCM
iProduct2 Microsoft LifeCam Rear
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 1982
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 2 Microsoft LifeCam Rear
bmAttributes 0x80
(Bus Powered)
MaxPower 250mA
Interface Association:
bLength 8
bDescriptorType11
bFirstInterface 0
bInterfaceCount 3
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 2 Microsoft LifeCam Rear
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 1
iInterface 2 Microsoft LifeCam Rear
VideoControl Interface Descriptor:
bLength14
bDescriptorType36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.50
wTotalLength 105
dwClockFrequency 150.00MHz
bInCollection 2
baInterfaceNr( 0) 1
baInterfaceNr( 1) 2
VideoControl Interface Descriptor:
bLength18
bDescriptorType36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength0
bControlSize 3
bmControls 0x0a0e
Auto-Exposure Mode
Auto-Exposure Priority
Exposure Time (Absolute)
Zoom (Absolute)
PanTilt (Absolute)
VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype 5 (PROCESSING_UNIT)
bUnitID 2
bSourceID 1
wMaxMultiplier 0
bControlSize3
bmControls 0x155b
Brightness
Contrast
Saturation
Sharpness
White Balance Temperature
Backlight Compensation
Power Line Frequency
White Balance Temperature, Auto
iProcessing 0
bmVideoStandards 0x 0
VideoControl Interface Descriptor:
bLength29
bDescriptorType36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {29a787c9-d359-6945-8467-ff0849fc19e8}
bNumControl22
bNrPins 1
baSourceID( 0) 2
bControlSize4
bmControls( 0) 0xbf
bmControls( 1) 0xfb
bmControls( 2) 0xff
bmControls( 3) 0x00
iExtension 0
VideoControl Interface Descriptor:
bLength13
bDescriptorType36
bDescriptorSubtype 7 (unknown)
Invalid desc subtype: 0b 04 00 03 cd 3e 00 cd 3e 00
VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 8
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 4
iTerminal 0
VideoControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 9
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 11
iTerminal 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes3
RE: [PATCH 2/2] [media] bdisp-debug: don't try to divide by s64
Acked-by: Fabien Dessenne fabien.desse...@st.com
-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com]
Sent: jeudi 11 juin 2015 12:37
To: Fabien DESSENNE
Cc: Linux Media Mailing List; Mauro Carvalho Chehab
Subject: Re: [PATCH 2/2] [media] bdisp-debug: don't try to divide by s64
Hi Fabien,
Em Thu, 11 Jun 2015 11:26:22 +0200
Fabien DESSENNE fabien.desse...@st.com escreveu:
Hi Mauro,
Please check my comments below.
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab
Sent: mercredi 10 juin 2015 22:59
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab; Mauro Carvalho Chehab; Fabien DESSENNE
Subject: [PATCH 2/2] [media] bdisp-debug: don't try to divide by s64
There are several warnings there, on some architectures, related to
dividing a s32 by a s64 value:
drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning:
comparison of distinct pointer types lacks a cast
drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: right
shift count = width of type
drivers/media/platform/sti/bdisp/bdisp-debug.c:594: warning: passing
argument 1 of '__div64_32' from incompatible pointer type
drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning:
comparison of distinct pointer types lacks a cast
drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning: right
shift count = width of type
drivers/media/platform/sti/bdisp/bdisp-debug.c:595: warning: passing
argument 1 of '__div64_32' from incompatible pointer type CC [M]
drivers/media/tuners/mt2060.o
drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning:
comparison of distinct pointer types lacks a cast
drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning: right
shift count = width of type
drivers/media/platform/sti/bdisp/bdisp-debug.c:596: warning: passing
argument 1 of '__div64_32' from incompatible pointer type
drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning:
comparison of distinct pointer types lacks a cast
drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning: right
shift count = width of type
drivers/media/platform/sti/bdisp/bdisp-debug.c:597: warning: passing
argument 1 of '__div64_32' from incompatible pointer type
That doesn't make much sense. What the driver is actually trying to
do is to divide one second by a value. So, check the range before
dividing. That warrants the right result and will remove the warnings on
non-64 bits archs.
Also fixes this warning:
drivers/media/platform/sti/bdisp/bdisp-debug.c:588: warning:
comparison of distinct pointer types lacks a cast
by using div64_s64() instead of calling do_div() directly.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/platform/sti/bdisp/bdisp-debug.c
b/drivers/media/platform/sti/bdisp/bdisp-debug.c
index 7c3a632746ba..3f6f411aafdd 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-debug.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-debug.c
@@ -572,6 +572,8 @@ static int bdisp_dbg_regs(struct seq_file *s,
void
*data)
return 0;
}
+#define SECOND 100
+
static int bdisp_dbg_perf(struct seq_file *s, void *data) {
struct bdisp_dev *bdisp = s-private; @@ -585,16 +587,27 @@ static
int bdisp_dbg_perf(struct seq_file *s, void
*data)
}
avg_time_us = bdisp-dbg.tot_duration;
When using div64_s64 the above line can be deleted, see my next
comment.
- do_div(avg_time_us, request-nb_req);
-
- avg_fps = 100;
- min_fps = 100;
- max_fps = 100;
- last_fps = 100;
- do_div(avg_fps, avg_time_us);
- do_div(min_fps, bdisp-dbg.min_duration);
- do_div(max_fps, bdisp-dbg.max_duration);
- do_div(last_fps, bdisp-dbg.last_duration);
+ div64_s64(avg_time_us, request-nb_req);
The operation result is returned by div64_s64(different from do_div that
updates the 1st parameter).
The expected syntax is:
avg_time_us = div64_s64(bdisp-dbg.tot_duration, request-nb_req);
+
+ if (avg_time_us SECOND)
+ avg_fps = 0;
+ else
+ avg_fps = SECOND / (s32)avg_time_us;
+
+ if (bdisp-dbg.min_duration SECOND)
+ min_fps = 0;
+ else
+ min_fps = SECOND / (s32)bdisp-dbg.min_duration);
It probably builds better without the last unexpected parenthesis ;)
Gah, a left-over... I did a first version using a different syntax.
See version 2 below.
+
+ if (bdisp-dbg.max_duration SECOND)
+ max_fps = 0;
+ else
+ max_fps = SECOND / (s32)bdisp-dbg.max_duration;
+
+ if (bdisp-dbg.last_duration SECOND)
+ last_fps = 0;
+ else
+ last_fps = SECOND / (s32)bdisp-dbg.last_duration;
seq_printf(s, HW processing (%d
Klientskie bazi tel +79133913837 Email: nonen2...@gmail.com ICQ:6288862 Yznaite podrobnee!!!
Klientskie bazi tel +79133913837 Email: nonen2...@gmail.com ICQ:6288862 Yznaite podrobnee!!! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] genalloc: rename of_get_named_gen_pool() to of_gen_pool_get()
To be consistent with other kernel interface namings, rename
of_get_named_gen_pool() to of_gen_pool_get(). In the original
function name _named suffix references to a device tree property,
which contains a phandle to a device and the corresponding
device driver is assumed to register a gen_pool object.
Due to a weak relation and to avoid any confusion (e.g. in future
possible scenario if gen_pool objects are named) the suffix is
removed.
Signed-off-by: Vladimir Zapolskiy vladimir_zapols...@mentor.com
---
drivers/dma/mmp_tdma.c| 2 +-
drivers/media/platform/coda/coda-common.c | 2 +-
include/linux/genalloc.h | 4 ++--
lib/genalloc.c| 6 +++---
sound/core/memalloc.c | 2 +-
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/mmp_tdma.c b/drivers/dma/mmp_tdma.c
index 449e785..e683761 100644
--- a/drivers/dma/mmp_tdma.c
+++ b/drivers/dma/mmp_tdma.c
@@ -657,7 +657,7 @@ static int mmp_tdma_probe(struct platform_device *pdev)
INIT_LIST_HEAD(tdev-device.channels);
if (pdev-dev.of_node)
- pool = of_get_named_gen_pool(pdev-dev.of_node, asram, 0);
+ pool = of_gen_pool_get(pdev-dev.of_node, asram, 0);
else
pool = sram_get_gpool(asram);
if (!pool) {
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 6e640c0..58f6548 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -2155,7 +2155,7 @@ static int coda_probe(struct platform_device *pdev)
}
/* Get IRAM pool from device tree or platform data */
- pool = of_get_named_gen_pool(np, iram, 0);
+ pool = of_gen_pool_get(np, iram, 0);
if (!pool pdata)
pool = gen_pool_get(pdata-iram_dev);
if (!pool) {
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 015d170..5383bb1 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -125,10 +125,10 @@ bool addr_in_gen_pool(struct gen_pool *pool, unsigned
long start,
size_t size);
#ifdef CONFIG_OF
-extern struct gen_pool *of_get_named_gen_pool(struct device_node *np,
+extern struct gen_pool *of_gen_pool_get(struct device_node *np,
const char *propname, int index);
#else
-static inline struct gen_pool *of_get_named_gen_pool(struct device_node *np,
+static inline struct gen_pool *of_gen_pool_get(struct device_node *np,
const char *propname, int index)
{
return NULL;
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 948e92c..daf0afb 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -620,7 +620,7 @@ EXPORT_SYMBOL_GPL(gen_pool_get);
#ifdef CONFIG_OF
/**
- * of_get_named_gen_pool - find a pool by phandle property
+ * of_gen_pool_get - find a pool by phandle property
* @np: device node
* @propname: property name containing phandle(s)
* @index: index into the phandle array
@@ -629,7 +629,7 @@ EXPORT_SYMBOL_GPL(gen_pool_get);
* address of the device tree node pointed at by the phandle property,
* or NULL if not found.
*/
-struct gen_pool *of_get_named_gen_pool(struct device_node *np,
+struct gen_pool *of_gen_pool_get(struct device_node *np,
const char *propname, int index)
{
struct platform_device *pdev;
@@ -644,5 +644,5 @@ struct gen_pool *of_get_named_gen_pool(struct device_node
*np,
return NULL;
return gen_pool_get(pdev-dev);
}
-EXPORT_SYMBOL_GPL(of_get_named_gen_pool);
+EXPORT_SYMBOL_GPL(of_gen_pool_get);
#endif /* CONFIG_OF */
diff --git a/sound/core/memalloc.c b/sound/core/memalloc.c
index 082509e..f05cb6a 100644
--- a/sound/core/memalloc.c
+++ b/sound/core/memalloc.c
@@ -124,7 +124,7 @@ static void snd_malloc_dev_iram(struct snd_dma_buffer
*dmab, size_t size)
dmab-addr = 0;
if (dev-of_node)
- pool = of_get_named_gen_pool(dev-of_node, iram, 0);
+ pool = of_gen_pool_get(dev-of_node, iram, 0);
if (!pool)
return;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] genalloc: rename dev_get_gen_pool() to gen_pool_get()
To be consistent with other genalloc interface namings, rename
dev_get_gen_pool() to gen_pool_get(). The original omitted dev_
prefix is removed, since it points to argument type of the function,
and so it does not bring any useful information.
Signed-off-by: Vladimir Zapolskiy vladimir_zapols...@mentor.com
---
arch/arm/mach-at91/pm.c | 2 +-
arch/arm/mach-imx/pm-imx5.c | 2 +-
arch/arm/mach-imx/pm-imx6.c | 2 +-
drivers/media/platform/coda/coda-common.c | 2 +-
include/linux/genalloc.h | 2 +-
lib/genalloc.c| 8
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 1e18476..e24df77 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -369,7 +369,7 @@ static void __init at91_pm_sram_init(void)
return;
}
- sram_pool = dev_get_gen_pool(pdev-dev);
+ sram_pool = gen_pool_get(pdev-dev);
if (!sram_pool) {
pr_warn(%s: sram pool unavailable!\n, __func__);
return;
diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c
index 0309ccd..1885676 100644
--- a/arch/arm/mach-imx/pm-imx5.c
+++ b/arch/arm/mach-imx/pm-imx5.c
@@ -297,7 +297,7 @@ static int __init imx_suspend_alloc_ocram(
goto put_node;
}
- ocram_pool = dev_get_gen_pool(pdev-dev);
+ ocram_pool = gen_pool_get(pdev-dev);
if (!ocram_pool) {
pr_warn(%s: ocram pool unavailable!\n, __func__);
ret = -ENODEV;
diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
index b01650d..93ecf55 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -451,7 +451,7 @@ static int __init imx6q_suspend_init(const struct
imx6_pm_socdata *socdata)
goto put_node;
}
- ocram_pool = dev_get_gen_pool(pdev-dev);
+ ocram_pool = gen_pool_get(pdev-dev);
if (!ocram_pool) {
pr_warn(%s: ocram pool unavailable!\n, __func__);
ret = -ENODEV;
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 6d6e0ca..6e640c0 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -2157,7 +2157,7 @@ static int coda_probe(struct platform_device *pdev)
/* Get IRAM pool from device tree or platform data */
pool = of_get_named_gen_pool(np, iram, 0);
if (!pool pdata)
- pool = dev_get_gen_pool(pdata-iram_dev);
+ pool = gen_pool_get(pdata-iram_dev);
if (!pool) {
dev_err(pdev-dev, iram pool not available\n);
return -ENOMEM;
diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 1ccaab4..015d170 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -119,7 +119,7 @@ extern unsigned long gen_pool_best_fit(unsigned long *map,
unsigned long size,
extern struct gen_pool *devm_gen_pool_create(struct device *dev,
int min_alloc_order, int nid);
-extern struct gen_pool *dev_get_gen_pool(struct device *dev);
+extern struct gen_pool *gen_pool_get(struct device *dev);
bool addr_in_gen_pool(struct gen_pool *pool, unsigned long start,
size_t size);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index d214866..948e92c 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -602,12 +602,12 @@ struct gen_pool *devm_gen_pool_create(struct device *dev,
int min_alloc_order,
EXPORT_SYMBOL(devm_gen_pool_create);
/**
- * dev_get_gen_pool - Obtain the gen_pool (if any) for a device
+ * gen_pool_get - Obtain the gen_pool (if any) for a device
* @dev: device to retrieve the gen_pool from
*
* Returns the gen_pool for the device if one is present, or NULL.
*/
-struct gen_pool *dev_get_gen_pool(struct device *dev)
+struct gen_pool *gen_pool_get(struct device *dev)
{
struct gen_pool **p = devres_find(dev, devm_gen_pool_release, NULL,
NULL);
@@ -616,7 +616,7 @@ struct gen_pool *dev_get_gen_pool(struct device *dev)
return NULL;
return *p;
}
-EXPORT_SYMBOL_GPL(dev_get_gen_pool);
+EXPORT_SYMBOL_GPL(gen_pool_get);
#ifdef CONFIG_OF
/**
@@ -642,7 +642,7 @@ struct gen_pool *of_get_named_gen_pool(struct device_node
*np,
of_node_put(np_pool);
if (!pdev)
return NULL;
- return dev_get_gen_pool(pdev-dev);
+ return gen_pool_get(pdev-dev);
}
EXPORT_SYMBOL_GPL(of_get_named_gen_pool);
#endif /* CONFIG_OF */
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] genalloc: rename dev_get_gen_pool() and of_get_named_gen_pool()
Trivial nonfunctional change initially based on discussion https://lkml.org/lkml/2015/6/8/588 Worth to mention that instead of the assumed new name dev_gen_pool_get(), this change attempts to be more close to other in-kernel interfaces and new function name is just gen_pool_get(). The change is based and tested on linux-next. Vladimir Zapolskiy (2): genalloc: rename dev_get_gen_pool() to gen_pool_get() genalloc: rename of_get_named_gen_pool() to of_gen_pool_get() arch/arm/mach-at91/pm.c | 2 +- arch/arm/mach-imx/pm-imx5.c | 2 +- arch/arm/mach-imx/pm-imx6.c | 2 +- drivers/dma/mmp_tdma.c| 2 +- drivers/media/platform/coda/coda-common.c | 4 ++-- include/linux/genalloc.h | 6 +++--- lib/genalloc.c| 14 +++--- sound/core/memalloc.c | 2 +- 8 files changed, 17 insertions(+), 17 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Support for UVC 1.5 / H.264 SVC (to be used with Logitech C930e)
Hello, I've recently got hold of a Logitech C930e webcam. AFAIK that's the only consumer webcam that support UVC 1.5 and H.264/SVC. Unfortunately, compared to its predecessor the C920, it is not very well supported on Linux. For example, the H.264 capability doesn't appear in the list of formats: v4l2-ctl -D --list-formats Driver Info (not using libv4l2): Driver name : uvcvideo Card type : Logitech Webcam C930e Bus info : usb-:00:1a.7-1.4 Driver version: 3.13.11 Capabilities : 0x8401 Video Capture Streaming Device Capabilities Device Caps : 0x0401 Video Capture Streaming ioctl: VIDIOC_ENUM_FMT Index : 0 Type: Video Capture Pixel Format: 'YUYV' Name: YUV 4:2:2 (YUYV) Index : 1 Type: Video Capture Pixel Format: 'MJPG' (compressed) Name: MJPEG Back in August 2013, there was a discussion on adding support for UVC 1.5, among other things: https://www.mail-archive.com/linux-media@vger.kernel.org/msg66203.html If I'm not mistaken, this set of patches provided above haven't been integrated into the kernel. Is there a lot of work to do to backport the code into the current kernel? 2 years after the original was written, has there been changes in the API that requires to revisit the patches? Cheers, -- Damiano Albani -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 3/3] IB/ipath: use arch_phys_wc_add() and require PAT disabled
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.
In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.
This is a worthy compromise given that the ipath device
driver powers the old HTX bus cards that only work in
AMD systems, while the newer IB/qib device driver
powers all PCI-e cards. The ipath device driver is
obsolete, hardware hard to find and because of this
this its a reasonable compromise to make to require
users of ipath to boot with nopat.
Acked-by: Doug Ledford dledf...@redhat.com
Cc: Doug Ledford dledf...@redhat.com
Cc: Andy Walls awa...@md.metrocast.net
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Sean Hefty sean.he...@intel.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
Cc: Mike Marciniszyn mike.marcinis...@intel.com
Cc: Roland Dreier rol...@purestorage.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Ingo Molnar mi...@elte.hu
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: infinip...@intel.com
Cc: linux-r...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/ipath/Kconfig | 3 ++
drivers/infiniband/hw/ipath/ipath_driver.c| 18 +++
drivers/infiniband/hw/ipath/ipath_kernel.h| 4 +--
drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 43 ++-
4 files changed, 26 insertions(+), 42 deletions(-)
diff --git a/drivers/infiniband/hw/ipath/Kconfig
b/drivers/infiniband/hw/ipath/Kconfig
index 1d9bb11..8fe54ff 100644
--- a/drivers/infiniband/hw/ipath/Kconfig
+++ b/drivers/infiniband/hw/ipath/Kconfig
@@ -9,3 +9,6 @@ config INFINIBAND_IPATH
as IP-over-InfiniBand as well as with userspace applications
(in conjunction with InfiniBand userspace access).
For QLogic PCIe QLE based cards, use the QIB driver instead.
+
+ If you have this hardware you will need to boot with PAT disabled
+ on your x86-64 systems, use the nopat kernel parameter.
diff --git a/drivers/infiniband/hw/ipath/ipath_driver.c
b/drivers/infiniband/hw/ipath/ipath_driver.c
index bd0caed..2d7e503 100644
--- a/drivers/infiniband/hw/ipath/ipath_driver.c
+++ b/drivers/infiniband/hw/ipath/ipath_driver.c
@@ -42,6 +42,9 @@
#include linux/bitmap.h
#include linux/slab.h
#include linux/module.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
+#endif
#include ipath_kernel.h
#include ipath_verbs.h
@@ -395,6 +398,14 @@ static int ipath_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
unsigned long long addr;
u32 bar0 = 0, bar1 = 0;
+#ifdef CONFIG_X86_64
+ if (WARN(pat_enabled(),
+ipath needs PAT disabled, boot with nopat kernel
parameter\n)) {
+ ret = -ENODEV;
+ goto bail;
+ }
+#endif
+
dd = ipath_alloc_devdata(pdev);
if (IS_ERR(dd)) {
ret = PTR_ERR(dd);
@@ -542,6 +553,7 @@ static int ipath_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
dd-ipath_kregbase = __ioremap(addr, len,
(_PAGE_NO_CACHE|_PAGE_WRITETHRU));
#else
+ /* XXX: split this properly to enable on PAT */
dd-ipath_kregbase = ioremap_nocache(addr, len);
#endif
@@ -587,12 +599,8 @@ static int ipath_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
ret = ipath_enable_wc(dd);
- if (ret) {
- ipath_dev_err(dd, Write combining not enabled
- (err %d): performance may be poor\n,
- -ret);
+ if (ret)
ret = 0;
- }
ipath_verify_pioperf(dd);
diff --git a/drivers/infiniband/hw/ipath/ipath_kernel.h
b/drivers/infiniband/hw/ipath/ipath_kernel.h
index e08db70..f0f9471 100644
---
[PATCH v7 0/3] linux: address broken PAT drivers
From: Luis R. Rodriguez mcg...@suse.com Boris, the following patches make use of the newly exported pat_enabled() which went in through your tree. All driver and respective subsystem maintainers have Acked these patches and are OK for them to go in through your tree. Please let me know if there any issues or questions. This v7 series goes with the return value fixed to be negative, this was spotted by Mauro on the ivtv driver, I also spotted this then on the ipath driver so fixed that there too in this series. The v7 also goes with a small change on language on the Kconfig for the ivtv as requested by Mauro. The v7 also goes with a small change on language on the Kconfig for the ivtv as requested by Mauro. Luis R. Rodriguez (3): ivtv: use arch_phys_wc_add() and require PAT disabled IB/ipath: add counting for MTRR IB/ipath: use arch_phys_wc_add() and require PAT disabled drivers/infiniband/hw/ipath/Kconfig | 3 ++ drivers/infiniband/hw/ipath/ipath_driver.c| 18 ++--- drivers/infiniband/hw/ipath/ipath_kernel.h| 4 +- drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 43 +--- drivers/media/pci/ivtv/Kconfig| 3 ++ drivers/media/pci/ivtv/ivtvfb.c | 58 +++ 6 files changed, 52 insertions(+), 77 deletions(-) -- 2.3.2.209.gd67f9d5.dirty -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 1/3] ivtv: use arch_phys_wc_add() and require PAT disabled
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.
In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.
This is a worthy compromise given that the hardware is
really rare these days, and perhaps only some lost souls
in some third world country are expected to be using this
feature of the device driver.
Acked-by: Andy Walls awa...@md.metrocast.net
Acked-by: Mauro Carvalho Chehab mche...@osg.samsung.com
Cc: Andy Walls awa...@md.metrocast.net
Cc: Doug Ledford dledf...@redhat.com
Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Borislav Petkov b...@suse.de
Cc: konrad.w...@oracle.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-media@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/media/pci/ivtv/Kconfig | 3 +++
drivers/media/pci/ivtv/ivtvfb.c | 58 -
2 files changed, 26 insertions(+), 35 deletions(-)
diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index dd6ee57e..6e5867c 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -57,5 +57,8 @@ config VIDEO_FB_IVTV
This is used in the Hauppauge PVR-350 card. There is a driver
homepage at http://www.ivtvdriver.org.
+ In order to use this module, you will need to boot with PAT disabled
+ on x86 systems, using the nopat kernel parameter.
+
To compile this driver as a module, choose M here: the
module will be called ivtvfb.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..4cb365d 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,8 +44,8 @@
#include linux/ivtvfb.h
#include linux/slab.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
#endif
#include ivtv-driver.h
@@ -155,12 +155,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+ int wc_cookie;
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1098,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
static int ivtvfb_init_io(struct ivtv *itv)
{
struct osd_info *oi = itv-osd_info;
+ /* Find the largest power of two that maps the whole buffer */
+ int size_shift = 31;
mutex_lock(itv-serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1132,29 +1133,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_pbase, oi-video_vbase,
oi-video_buffer_size / 1024);
-#ifdef CONFIG_MTRR
- {
- /* Find the largest power of two that maps the whole buffer */
- int size_shift = 31;
-
- while (!(oi-video_buffer_size (1 size_shift))) {
- size_shift--;
- }
- size_shift++;
- oi-fb_start_aligned_physaddr = oi-video_pbase ~((1
size_shift) - 1);
- oi-fb_end_aligned_physaddr = oi-video_pbase +
oi-video_buffer_size;
- oi-fb_end_aligned_physaddr += (1 size_shift) - 1;
- oi-fb_end_aligned_physaddr = ~((1 size_shift) - 1);
- if (mtrr_add(oi-fb_start_aligned_physaddr,
- oi-fb_end_aligned_physaddr -
oi-fb_start_aligned_physaddr,
-MTRR_TYPE_WRCOMB, 1) 0) {
- IVTVFB_INFO(disabled mttr\n);
- oi-fb_start_aligned_physaddr = 0;
- oi-fb_end_aligned_physaddr = 0;
-
[PATCH v7 2/3] IB/ipath: add counting for MTRR
From: Luis R. Rodriguez mcg...@suse.com
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani toshi.k...@hp.com
Cc: Roland Dreier rol...@kernel.org
Cc: Sean Hefty sean.he...@intel.com
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: infinip...@intel.com
Cc: linux-r...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
index 4ad0b93..70c1f3a 100644
--- a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
+++ b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
@@ -127,7 +127,7 @@ int ipath_enable_wc(struct ipath_devdata *dd)
(addr %llx, len=0x%llx)\n,
(unsigned long long) pioaddr,
(unsigned long long) piolen);
- cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 0);
+ cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
if (cookie 0) {
{
dev_info(dd-pcidev-dev,
--
2.3.2.209.gd67f9d5.dirty
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RIP MTRR - status update for upcoming v4.2
The series to bury direct MTRR use is almost all in and on its way to v4.2. As the pending series continue slowly to be merged I wanted to take the time to reiterate the justification for these changes in hopes it may help those still reviewing some of these patches which are pending and to help document all these changes. There are also some series which depend on symbols now exported through some other subsystem trees so coordination is needed there. In those cases we have the option there to sit and wait for the exported symbols to trickle in through v4.2 and later on v4.3 finalize the changes, or to let some of the depending changes to in through other subsystem trees. I don't consider the coordination required difficult to handle so would prefer to see the changes in for v4.2 to be able to put a nail on the MTRR coffin sooner rather than later and to also help get more testing out of this sooner rather than later. PAT is known to have errata for some CPUs so hearing reports of issues with PAT would be very valuable. I'll let maintainers decide on how that trickles through. To help with all this towards the end I provide a status of all the pending patches to get this work completed. Justification = We want to bury direct use of MTRR code because: a) MTRR is x86 specific, this means all existing MTRR code is #idef'd out. PAT support for x86 was implemented using architecture agnostic APIs, this enables other architectures to provide support for a similar write-combining feature, and removes the nasty #idef eyesores. MTRR should be seen as a first step temporary architectural evolution to what PAT eventually became on x86. b) We have a long term goal to change the default behavior of ioremap_nocache() and pci_mmap_page_range() to use PAT strong UC, right now we cannot do this, but after all drivers are converted (all these series I've been posting) we expect to be able to make the change. Making a change to strong UC on these two calls can only happen after a period of time of having Linux bake with all these changes merged and in place. How many kernels we will want Linux baked with all these transformations to arch_phys before making a change to ioremap_nocache() and pci_mmap_page_range() is up to x86 folks. There are other gains possible with this but I welcome others to chime in here with what gains we can expect from this. c) MTRR acts on physical addresses and requires power-of-two alignment, on both the base used and size, this limits the flexibility for MTRR use. For a good example of its limitations refer to the patches which change the atyfb driver from using MTRR to PAT. d) MTRR is known to be unreliable, it can at times not work even on modern systems. e) There is a limit to how many MTRRs you can use on a system. If using a large number of devices with MTRR support you will quickly run out of MTRRs. This is why originally Andy Lutomirski ended up adding the arch_phys_wc_add() API, in order to take advantage of PAT which is *not* bound to the same limitations as MTRRs are. f) PAT has been available for quite a long time, since Pentium III (circa 1999) and newer, but having PAT enabled does not restrict use of MTRR and because of this some systems may end up then combining MTRR and PAT. I do not believe this wasn't an original highly expected wide use situation, it technically should work to combine both but there might be issues with interactions between both, exactly what issues can exist or have existed remains quite unclear as MTRR in and of itself has been known to be unreliable anyway. If possible its best to just be binary about this and only use MTRR if and only if necessary because of the other issues known with MTRR. g) Linux has support for Xen PV domains using PAT, this was introduced by Juergen via v3.19 via commit 47591df50512 (xen: Support Xen pv-domains using PAT). Since MTRR is old we don't want to add MTRR support into Xen on Linux, instead since Linux now supports PV domains with PAT we can take full advantage of write combining for PV domains on Xen provided all Linux drivers are converted to use PAT properly.a framebuffer folks's ACK Review of the changes Most of the series has consisted of driver transformations using Coccinelle SmPL patches to transform existing code which access MTRR APIs directly to the architecture agnostic write-combining calls. Other patches extend bus subsystems to make available new write-combining architecture agnostic APIs. Other patches have consisted of extending architecture agnostic APIs to help work around old MTRR hacks -- this was perhaps the hardest task and took quite a bit of time and review as it required review of implications of all combinatorial possibilities with MTRR and PAT, which also got documented as part of the series. In the end it was also determined some drivers required substantial work to be able to work properly with PAT, the atyfb driver is an example driver which had the homework
Re: RIP MTRR - status update for upcoming v4.2
On Thu, 2015-06-11 at 13:36 -0700, Luis R. Rodriguez wrote: : Pending RIP MTRR patches There are a few pending series so I wanted to provide a status update on those series. mtrr: bury MTRR - unexport mtrr_add() and mtrr_del() This is the nail on the MTRR coffin, it will prevent future direct access to MTRR code. This will not be posted until all of the below patches are in and merged. A possible next step here might be to consider separating PAT code from MTRR code and making PAT a first class citizen, enabling distributions to disable MTRR code in the future. I thought this was possible but for some reason I recently thought that there was one possible issue to make this happen. I suppose we won't know unless we try, unless of course someone already knows, Toshi? There are two usages on MTRRs: 1) MTRR entries set by firmware 2) MTRR entries set by OS drivers We can obsolete 2), but we have no control over 1). As UEFI firmwares also set this up, this usage will continue to stay. So, we should not get rid of the MTRR code that looks up the MTRR entries, while we have no need to modify them. Such MTRR entries provide safe guard to /dev/mem, which allows privileged user to access a range that may require UC mapping while the /dev/mem driver blindly maps it with WB. MTRRs converts WB to UC in such a case. UEFI memory table has memory attribute, which describes cache types supported in physical memory ranges. However, this information gets lost when it it is converted to e820 table. Thanks, -Toshi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mantis: fix unused variable compiler warning
mantis_i2c.c:222:15: warning: variable 'intmask' set but not used
[-Wunused-but-set-variable]
u32 intstat, intmask;
^
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/pci/mantis/mantis_i2c.c
b/drivers/media/pci/mantis/mantis_i2c.c
index a938234..9abe1c7 100644
--- a/drivers/media/pci/mantis/mantis_i2c.c
+++ b/drivers/media/pci/mantis/mantis_i2c.c
@@ -219,7 +219,7 @@ static struct i2c_algorithm mantis_algo = {
int mantis_i2c_init(struct mantis_pci *mantis)
{
- u32 intstat, intmask;
+ u32 intstat;
struct i2c_adapter *i2c_adapter = mantis-adapter;
struct pci_dev *pdev= mantis-pdev;
@@ -242,7 +242,6 @@ int mantis_i2c_init(struct mantis_pci *mantis)
dprintk(MANTIS_DEBUG, 1, Initializing I2C ..);
intstat = mmread(MANTIS_INT_STAT);
- intmask = mmread(MANTIS_INT_MASK);
mmwrite(intstat, MANTIS_INT_STAT);
dprintk(MANTIS_DEBUG, 1, Disabling I2C interrupt);
mantis_mask_ints(mantis, MANTIS_INT_I2CDONE);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
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 Jun 12 04:00:19 CEST 2015 git branch: test git hash: e42c8c6eb456f8978de417ea349eef676ef4385c gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1-rc1-i686: OK linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/3] IB/ipath: add counting for MTRR
On 06/11/2015 03:54 PM, Borislav Petkov wrote:
On Thu, Jun 11, 2015 at 10:50:01AM -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani toshi.k...@hp.com
Cc: Roland Dreier rol...@kernel.org
Cc: Sean Hefty sean.he...@intel.com
Cc: Hal Rosenstock hal.rosenst...@gmail.com
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Andy Lutomirski l...@amacapital.net
Cc: Dave Airlie airl...@redhat.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: infinip...@intel.com
Cc: linux-r...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
drivers/infiniband/hw/ipath/ipath_wc_x86_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
index 4ad0b93..70c1f3a 100644
--- a/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
+++ b/drivers/infiniband/hw/ipath/ipath_wc_x86_64.c
@@ -127,7 +127,7 @@ int ipath_enable_wc(struct ipath_devdata *dd)
(addr %llx, len=0x%llx)\n,
(unsigned long long) pioaddr,
(unsigned long long) piolen);
-cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 0);
+cookie = mtrr_add(pioaddr, piolen, MTRR_TYPE_WRCOMB, 1);
if (cookie 0) {
{
dev_info(dd-pcidev-dev,
--
Doug, ack?
Ack.
signature.asc
Description: OpenPGP digital signature
Re: RIP MTRR - status update for upcoming v4.2
On Thu, Jun 11, 2015 at 05:23:16PM -0600, Toshi Kani wrote: On Thu, 2015-06-11 at 13:36 -0700, Luis R. Rodriguez wrote: : Pending RIP MTRR patches There are a few pending series so I wanted to provide a status update on those series. mtrr: bury MTRR - unexport mtrr_add() and mtrr_del() This is the nail on the MTRR coffin, it will prevent future direct access to MTRR code. This will not be posted until all of the below patches are in and merged. A possible next step here might be to consider separating PAT code from MTRR code and making PAT a first class citizen, enabling distributions to disable MTRR code in the future. I thought this was possible but for some reason I recently thought that there was one possible issue to make this happen. I suppose we won't know unless we try, unless of course someone already knows, Toshi? There are two usages on MTRRs: 1) MTRR entries set by firmware 2) MTRR entries set by OS drivers We can obsolete 2), but we have no control over 1). As UEFI firmwares also set this up, this usage will continue to stay. So, we should not get rid of the MTRR code that looks up the MTRR entries, while we have no need to modify them. Such MTRR entries provide safe guard to /dev/mem, which allows privileged user to access a range that may require UC mapping while the /dev/mem driver blindly maps it with WB. MTRRs converts WB to UC in such a case. UEFI memory table has memory attribute, which describes cache types supported in physical memory ranges. However, this information gets lost when it it is converted to e820 table. Is there no way to modify CPU capability bits upon boot and kick UEFI to re-evaluate ? In such UEFI cases what happens for instance when Xen is used which does not support MTRR? Luis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] mm: Provide new get_vaddr_frames() helper
On (06/10/15 06:20), Mauro Carvalho Chehab wrote:
[..]
+
+/**
+ * frame_vector_destroy() - free memory allocated to carry frame vector
+ * @vec: Frame vector to free
+ *
+ * Free structure allocated by frame_vector_create() to carry frames.
+ */
+void frame_vector_destroy(struct frame_vector *vec)
+{
+ /* Make sure put_vaddr_frames() got called properly... */
+ VM_BUG_ON(vec-nr_frames 0);
+ if (!is_vmalloc_addr(vec))
+ kfree(vec);
+ else
+ vfree(vec);
minor: kvfree(vec);
-ss
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
em28xx problem with 3.10-4.0
lo lo, I would like to use my Pinnacle Dazzle DVC usb encoder with kernels 3.10-4.0, but I'm getting the same error all the time. Latest working kernel is the 3.4 line. What happend with the driver? dmesg Description: Binary data
RE: [PATCH] [media] bdisp: remove unused var
Acked-by: Fabien Dessenne fabien.desse...@st.com
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab
Sent: mercredi 10 juin 2015 17:35
To: Linux Media Mailing List
Cc: Mauro Carvalho Chehab; Mauro Carvalho Chehab
Subject: [PATCH] [media] bdisp: remove unused var
Fix the following warning:
drivers/media/platform/sti/bdisp/bdisp-v4l2.c: In function
'bdisp_register_device':
drivers/media/platform/sti/bdisp/bdisp-v4l2.c:1024:26: warning: variable
'pdev' set but not used [-Wunused-but-set-variable]
struct platform_device *pdev;
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
---
drivers/media/platform/sti/bdisp/bdisp-v4l2.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
index 9a8405cd5216..9e782ebe18da 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
@@ -1021,14 +1021,11 @@ static const struct v4l2_ioctl_ops bdisp_ioctl_ops
= {
static int bdisp_register_device(struct bdisp_dev *bdisp) {
- struct platform_device *pdev;
int ret;
if (!bdisp)
return -ENODEV;
- pdev = bdisp-pdev;
-
bdisp-vdev.fops= bdisp_fops;
bdisp-vdev.ioctl_ops = bdisp_ioctl_ops;
bdisp-vdev.release = video_device_release_empty;
--
2.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in the
body of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
