Re: [RFC] Media devices, V4L2 subdevs and Linux device model
On Fri, Jul 15, 2011 at 01:34:55PM +0200, Laurent Pinchart wrote:
Hi Sakari,
Hi Laurent,
Many thanks for the comments!
On Monday 11 July 2011 18:17:10 Sakari Ailus wrote:
The way devices, V4L2 subdevs and media devices are currently being handled
does not make efficient use of the Linux device model. We have dependencies
which we are handling in a way or another, usually not in a very generic
way.
I came to think of sub-subdevs recently, and implementing them, but
before that Laurent suggested that V4L2 should be better aligned with
the Linux device model, which I can't deny.
I don't know the Linux device model very well, so what I did was that I
collected a summary of the current situation. That may be found below.
Comments are very, very welcome.
struct video_device
===
struct video_device represents the character device, either a V4L2
device node or a V4L2 subdev device node. entity is the entity in the
subdev graph, and for V4L2 this is the device node.
I assume you're talking about video_device::entity. To be exact, that field
represents the entity in the media device graph associated with the V4L2
device node, and isn't used for subdevice devnodes.
The usage of video_device to create subdevice devnodes leads to confusion in
my opinion. I've initially proposed to split video_device into a v4l2_devnode
and a video_device structure, but that was rejected.
I agree this is confusing. It's not self-evident which of the fields in
video_device are being used and which are not.
A new struct device, dev, is created and it is given a name which
corresponds to the type of the device, e.g. video0 or v4l-subdev0, and
it's registered using device_register().
OMAP3ISP driver uses the same v4l2_dev for every struct video_device it
has to represent video nodes, so parent is NULL. It assigns
video_device_release_empty() as the release function pointer.
struct video_device {
#ifdef CONFIG_MEDIA_CONTROLLER
struct media_entity entity;
#endif
struct device dev;
/* Either one of these two may be set. */
struct device *parent;
struct v4l2_device *v4l2_dev;
int (*release)(struct video_device *);
};
struct v4l2_device
==
struct v4l2_device is a V4L2 equivalent to more generic media_device.
There's one per each driver that implements a media device (or in case
of absence of one, a device which implements V4L2 video devices).
struct v4l2_device {
struct device *dev;
#ifdef CONFIG_MEDIA_CONTROLLER
struct media_device *mdev;
#endif
struct list_head subdevs;
};
struct v4l2_subdev
==
struct v4l2_subdev {
#ifdef CONFIG_MEDIA_CONTROLLER
struct media_entity entity;
#endif
struct video_device devnode;
struct module *owner;
};
struct media_device
===
struct media_device {
struct media_devnode devnode;
struct list_head entities;
};
struct media_entity
===
struct media_entity {
struct media_device *parent;
};
struct media_devnode
struct media_devnode {
struct device dev; /* media device */
struct cdev cdev; /* character device */
struct device *parent; /* device parent */
};
Lifecycle of a media device
===
The media device contains entities, which further, in V4L2, depend on V4L2
subdev or V4L2 video nodes. The media device, subdevs and video nodes have
a corresponding interface to user space. There is a v4l2_device which
corresponds to media device but is V4L2 specific.
media device
/\
media_entity... media_entity...
v4l2_subdev video_device
v4l2_device
/ \
v4l2_subdev...video_device...
Dots in the diagram means zero or more instead of one.
The subdevs are initialised by their proper drivers using
v4l2_i2c_subdev_init() (for I2C subdevs) or v4l2_spi_subdev_init() (for
SPI subdevs). These functions will call v4l2_subdev_init(), set the
owner of the subdev to the owner of the I2C client (or SPI device)
driver's owner and make both subdev reachable from I2C client and the
other way around by setting private pointers point to the other one.
If the subdevs are part of the driver which implements the
media_device, the initialisation is slightly different. Instead of being
able to rely on either of the current bus specific subdev_init() functions,
the driver directly calls v4l2_subdev_init() and does the rest of the
required setup. The owner field will be left to NULL.
The media entity for the subdev
[PATCH v3] V4L: add two new ioctl()s for multi-size videobuffer management
A possibility to preallocate and initialise buffers of different sizes in V4L2 is required for an efficient implementation of asnapshot mode. This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF and defines respective data structures. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- It's been almost a month since v2, the only comments were a request to increase the reserved space in the new ioctl() and to improve documentation. The reserved field is increased in this version, documentation also has been improved in multiple locations. I think, documentation can be further improved at any time, but if there are no objections against the actual contents of this patch, maybe we can commit this version. I still don't see v3.0;-), so, maybe we even can push it for 3.1. A trivial comparison with v2 shows the size of the reserved field as the only change in the API, and the compatibility fix as the only two functional changes. v3: addressed multiple comments by Sakari Ailus 1. increased reserved field in struct v4l2_create_buffers to 8 32-bit ints 2. multiple documentation fixes and improvements 3. fixed misplaced case VIDIOC_PREPARE_BUF in ioctl 32-bit compatibility processing v2: 1. add preliminary Documentation 2. add flag V4L2_BUFFER_FLAG_NO_CACHE_CLEAN 3. remove VIDIOC_DESTROY_BUFS 4. rename SUBMIT to VIDIOC_PREPARE_BUF 5. add reserved field to struct v4l2_create_buffers 6. cache handling flags moved to struct v4l2_buffer for processing during VIDIOC_PREPARE_BUF 7. VIDIOC_PREPARE_BUF now uses struct v4l2_buffer as its argument Documentation/DocBook/media/v4l/io.xml | 17 +++ Documentation/DocBook/media/v4l/v4l2.xml |2 + .../DocBook/media/v4l/vidioc-create-bufs.xml | 152 .../DocBook/media/v4l/vidioc-prepare-buf.xml | 96 drivers/media/video/v4l2-compat-ioctl32.c | 68 - drivers/media/video/v4l2-ioctl.c | 32 include/linux/videodev2.h | 16 ++ include/media/v4l2-ioctl.h |2 + 8 files changed, 377 insertions(+), 8 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-create-bufs.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 227e7ac..6249d0e 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -927,6 +927,23 @@ ioctl is called./entry Applications set or clear this flag before calling the constantVIDIOC_QBUF/constant ioctl./entry /row + row + entryconstantV4L2_BUF_FLAG_NO_CACHE_INVALIDATE/constant/entry + entry0x0400/entry + entryCaches do not have to be invalidated for this buffer. +Typically applications shall use this flag, if the data, captured in the buffer +is not going to br touched by the CPU, instead the buffer will, probably, be +passed on to a DMA-capable hardware unit for further processing or output. +/entry + /row + row + entryconstantV4L2_BUF_FLAG_NO_CACHE_CLEAN/constant/entry + entry0x0800/entry + entryCaches do not have to be cleaned for this buffer. +Typically applications shall use this flag for output buffers, if the data +in this buffer has not been created by the CPU, but by some DMA-capable unit, +in which case caches have not been used./entry + /row /tbody /tgroup /table diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 0d05e87..06bb179 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -462,6 +462,7 @@ and discussions on the V4L mailing list./revremark sub-close; sub-ioctl; !-- All ioctls go here. -- +sub-create-bufs; sub-cropcap; sub-dbg-g-chip-ident; sub-dbg-g-register; @@ -504,6 +505,7 @@ and discussions on the V4L mailing list./revremark sub-queryctrl; sub-query-dv-preset; sub-querystd; +sub-prepare-buf; sub-reqbufs; sub-s-hw-freq-seek; sub-streamon; diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml new file mode 100644 index 000..5f0158c --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml @@ -0,0 +1,152 @@ +refentry id=vidioc-create-bufs + refmeta +refentrytitleioctl VIDIOC_CREATE_BUFS/refentrytitle +manvol; + /refmeta + + refnamediv +refnameVIDIOC_CREATE_BUFS/refname +refpurposeCreate buffers for Memory Mapped or User Pointer I/O/refpurpose + /refnamediv + + refsynopsisdiv +funcsynopsis + funcprototype + funcdefint functionioctl/function/funcdef + paramdefint parameterfd/parameter/paramdef + paramdefint
Re: ISP CCDC freeze-up on STREAMON
Hi Michael, Sorry for the late reply. On Thursday 30 June 2011 10:31:52 Michael Jones wrote: Hi Laurent, I'm observing a system freeze-up with the ISP when writing data to memory directly from the ccdc. Here's the sequence I'm using: 0. apply the patch I'm sending separate in this thread. 1. configure the ISP pipeline for the CCDC to deliver V4L2_PIX_FMT_GREY directly from the sensor to memory. 2. yavta -c10 /dev/video2 The patch is pretty self-explanatory. It introduces a loop (with ugly indenting to keep the patch simple) with 100 iterations leaving the device open between them. My system usually hangs up within the first 30 iterations. I've never made it to 100 successfully. I see the same behavior with user pointers and with mmap, but I don't see it when using data from the previewer. Can you please try this out with your setup? Even if you can't get 8-bit gray data from your sensor, hopefully you could observe it with any other format directly from the CCDC. I'll postpone further discussion until you confirm that you can reproduce the behavior. As the patch illustrates, it looks like it is hanging up in STREAMON. I've tested this with a serial CSI-2 sensor and a parallel sensor (MT9V032, in both 8-bit and 10-bit modes, albeit with SGRBG8 instead of GREY for the 8-bit mode), and I can't reproduce the issue. I thought I've asked you already but can't find this in my mailbox, so I apologize if I have, but could you try increasing vertical blanking and see if it helps ? -- 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
[PATCH 8/8] ARM: S5PV210: example of CMA private area for FIMC device on Goni board
This patch is an example how device private CMA area can be activated.
It creates one CMA region and assigns it to the first s5p-fimc device on
Samsung Goni S5PC110 board.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-s5pv210/Kconfig |1 +
arch/arm/mach-s5pv210/mach-goni.c |8
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 37b5a97..c09a92c 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -64,6 +64,7 @@ menu S5PC110 Machines
config MACH_AQUILA
bool Aquila
select CPU_S5PV210
+ select CMA
select S3C_DEV_FB
select S5P_DEV_FIMC0
select S5P_DEV_FIMC1
diff --git a/arch/arm/mach-s5pv210/mach-goni.c
b/arch/arm/mach-s5pv210/mach-goni.c
index 31d5aa7..d9e565d 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -26,6 +26,7 @@
#include linux/input.h
#include linux/gpio.h
#include linux/interrupt.h
+#include linux/dma-contiguous.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -886,6 +887,12 @@ static void __init goni_machine_init(void)
platform_add_devices(goni_devices, ARRAY_SIZE(goni_devices));
}
+static void __init goni_reserve(void)
+{
+ /* Create private 16MiB contiguous memory area for s5p-fimc.0 device */
+ dma_declare_contiguous(s5p_device_fimc0.dev, 16*SZ_1M, 0);
+}
+
MACHINE_START(GONI, GONI)
/* Maintainers: Kyungmin Park kyungmin.p...@samsung.com */
.boot_params= S5P_PA_SDRAM + 0x100,
@@ -893,4 +900,5 @@ MACHINE_START(GONI, GONI)
.map_io = goni_map_io,
.init_machine = goni_machine_init,
.timer = s5p_timer,
+ .reserve= goni_reserve,
MACHINE_END
--
1.7.1.569.g6f426
--
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 7/8] ARM: integrate CMA with dma-mapping subsystem
This patch adds support for CMA to dma-mapping subsystem for ARM
architecture. By default a global CMA area is used, but specific devices
are allowed to have their private memory areas if required (they can be
created with dma_declare_contiguous() function during board
initialization).
This patch is mainly a proof-of-concept.
Contiguous memory areas reserved for DMA are remapped with 2-level page
tables on boot. Once a buffer is requested, a low memory kernel mapping
is updated to to match requested memory access type.
TODO 1: Add support for GFP_ATOMIC allocations. They will be performed
from special memory area which is exclusive from system memory. Such
solution has been presented in ARM: DMA: steal memory for DMA coherent
mappings patch prepared by Russell King.
TODO 2: Implement support for contiguous memory areas that are placed
in HIGHMEM zone
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/Kconfig |1 +
arch/arm/include/asm/device.h |3 +
arch/arm/include/asm/dma-contiguous.h | 33 +
arch/arm/include/asm/mach/map.h |1 +
arch/arm/mm/dma-mapping.c | 244 +
arch/arm/mm/init.c|3 +
arch/arm/mm/mmu.c | 56 -
7 files changed, 133 insertions(+), 208 deletions(-)
create mode 100644 arch/arm/include/asm/dma-contiguous.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9adc278..3cca8cc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -3,6 +3,7 @@ config ARM
default y
select HAVE_AOUT
select HAVE_DMA_API_DEBUG
+ select HAVE_DMA_CONTIGUOUS
select HAVE_IDE
select HAVE_MEMBLOCK
select RTC_LIB
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index 9f390ce..942913e 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -10,6 +10,9 @@ struct dev_archdata {
#ifdef CONFIG_DMABOUNCE
struct dmabounce_device_info *dmabounce;
#endif
+#ifdef CONFIG_CMA
+ struct cma *cma_area;
+#endif
};
struct pdev_archdata {
diff --git a/arch/arm/include/asm/dma-contiguous.h
b/arch/arm/include/asm/dma-contiguous.h
new file mode 100644
index 000..99bf7c8
--- /dev/null
+++ b/arch/arm/include/asm/dma-contiguous.h
@@ -0,0 +1,33 @@
+#ifndef ASMARM_DMA_CONTIGUOUS_H
+#define ASMARM_DMA_CONTIGUOUS_H
+
+#ifdef __KERNEL__
+
+#include linux/device.h
+#include linux/dma-contiguous.h
+
+#ifdef CONFIG_CMA
+
+#define MAX_CMA_AREAS (8)
+
+void dma_contiguous_early_fixup(phys_addr_t base, unsigned long size);
+
+static inline struct cma *get_dev_cma_area(struct device *dev)
+{
+ if (dev-archdata.cma_area)
+ return dev-archdata.cma_area;
+ return dma_contiguous_default_area;
+}
+
+static inline void set_dev_cma_area(struct device *dev, struct cma *cma)
+{
+ dev-archdata.cma_area = cma;
+}
+
+#else
+
+#define MAX_CMA_AREAS (0)
+
+#endif
+#endif
+#endif
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index d2fedb5..6ae266a 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -29,6 +29,7 @@ struct map_desc {
#define MT_MEMORY_NONCACHED11
#define MT_MEMORY_DTCM 12
#define MT_MEMORY_ITCM 13
+#define MT_MEMORY_DMA 14
#ifdef CONFIG_MMU
extern void iotable_init(struct map_desc *, int);
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 82a093c..ce0a981 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -17,6 +17,7 @@
#include linux/init.h
#include linux/device.h
#include linux/dma-mapping.h
+#include linux/dma-contiguous.h
#include linux/highmem.h
#include asm/memory.h
@@ -58,10 +59,11 @@ static u64 get_coherent_dma_mask(struct device *dev)
*/
static struct page *__dma_alloc_buffer(struct device *dev, size_t size, gfp_t
gfp)
{
- unsigned long order = get_order(size);
- struct page *page, *p, *e;
+ struct page *page;
+ size_t count = size PAGE_SHIFT;
void *ptr;
u64 mask = get_coherent_dma_mask(dev);
+ unsigned long order = get_order(count PAGE_SHIFT);
#ifdef CONFIG_DMA_API_DEBUG
u64 limit = (mask + 1) ~mask;
@@ -78,16 +80,12 @@ static struct page *__dma_alloc_buffer(struct device *dev,
size_t size, gfp_t gf
if (mask 0xULL)
gfp |= GFP_DMA;
- page = alloc_pages(gfp, order);
- if (!page)
- return NULL;
-
/*
-* Now split the huge page and free the excess pages
+* Allocate memory from contiguous area
*/
- split_page(page, order);
- for (p = page + (size PAGE_SHIFT), e = page + (1 order); p e;
p++)
- __free_page(p);
+ page = dma_alloc_from_contiguous(dev, count, order);
+ if (!page)
+ return NULL;
[PATCH 6/8] drivers: add Contiguous Memory Allocator
The Contiguous Memory Allocator is a set of helper functions for DMA mapping framework that improves allocations of contiguous memory chunks. CMA grabs memory on system boot, marks it with CMA_MIGRATE_TYPE and gives back to the system. Kernel is allowed to allocate movable pages within CMA's managed memory so that it can be used for example for page cache when DMA mapping do not use it. On dma_alloc_from_contiguous() request such pages are migrated out of CMA area to free required contiguous block and fulfill the request. This allows to allocate large contiguous chunks of memory at any time assuming that there is enough free memory available in the system. This code is heavily based on earlier works by Michal Nazarewicz. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com CC: Michal Nazarewicz min...@mina86.com --- arch/Kconfig |3 + drivers/base/Kconfig | 77 drivers/base/Makefile |1 + drivers/base/dma-contiguous.c | 396 include/linux/dma-contiguous.h | 102 ++ 5 files changed, 579 insertions(+), 0 deletions(-) create mode 100644 drivers/base/dma-contiguous.c create mode 100644 include/linux/dma-contiguous.h diff --git a/arch/Kconfig b/arch/Kconfig index 26b0e23..228d761 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -124,6 +124,9 @@ config HAVE_ARCH_TRACEHOOK config HAVE_DMA_ATTRS bool +config HAVE_DMA_CONTIGUOUS + bool + config USE_GENERIC_SMP_HELPERS bool diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index d57e8d0..c690d05 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -168,4 +168,81 @@ config SYS_HYPERVISOR bool default n +config CMA + bool Contiguous Memory Allocator + depends on HAVE_DMA_CONTIGUOUS HAVE_MEMBLOCK + select MIGRATION + select CMA_MIGRATE_TYPE + help + This enables the Contiguous Memory Allocator which allows drivers + to allocate big physically-contiguous blocks of memory for use with + hardware components that do not support I/O map nor scatter-gather. + + For more information see include/linux/dma-contiguous.h. + If unsure, say n. + +if CMA + +config CMA_DEBUG + bool CMA debug messages (DEVELOPEMENT) + help + Turns on debug messages in CMA. This produces KERN_DEBUG + messages for every CMA call as well as various messages while + processing calls such as dma_alloc_from_contiguous(). + This option does not affect warning and error messages. + +comment Default contiguous memory area size: + +config CMA_SIZE_ABSOLUTE + int Absolute size (in MiB) + default 16 + help + Defines the size (in MiB) of the default memory area for Contiguous + Memory Allocator. + +config CMA_SIZE_PERCENTAGE + int Percentage of total memory + default 10 + help + Defines the size of the default memory area for Contiguous Memory + Allocator as a percentage of the total memory in the system. + +choice + prompt Selected region size + default CMA_SIZE_SEL_ABSOLUTE + +config CMA_SIZE_SEL_ABSOLUTE + bool Use absolute value only + +config CMA_SIZE_SEL_PERCENTAGE + bool Use percentage value only + +config CMA_SIZE_SEL_MIN + bool Use lower value (minimum) + +config CMA_SIZE_SEL_MAX + bool Use higher value (maximum) + +endchoice + +config CMA_ALIGNMENT + int Maximum PAGE_SIZE order of alignment for contiguous buffers + range 4 9 + default 8 + help + DMA mapping framework by default aligns all buffers to the smallest + PAGE_SIZE order which is greater than or equal to the requested buffer + size. This works well for buffers up to a few hundreds kilobytes, but + for larger buffers it just a memory waste. With this parameter you can + specify the maximum PAGE_SIZE order for contiguous buffers. Larger + buffers will be aligned only to this specified order. The order is + expressed as a power of two multiplied by the PAGE_SIZE. + + For example, if your system defaults to 4KiB pages, the order value + of 8 means that the buffers will be aligned up to 1MiB only. + + If unsure, leave the default value 8. + +endif + endmenu diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 4c5701c..be6aab4 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -5,6 +5,7 @@ obj-y := core.o sys.o bus.o dd.o syscore.o \ cpu.o firmware.o init.o map.o devres.o \ attribute_container.o transport_class.o obj-$(CONFIG_DEVTMPFS) += devtmpfs.o +obj-$(CONFIG_CMA) += dma-contiguous.o obj-y += power/ obj-$(CONFIG_HAS_DMA) += dma-mapping.o obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT)
[PATCH 5/8] mm: MIGRATE_CMA isolation functions added
From: Michal Nazarewicz m.nazarew...@samsung.com
This commit changes various functions that change pages and
pageblocks migrate type between MIGRATE_ISOLATE and
MIGRATE_MOVABLE in such a way as to allow to work with
MIGRATE_CMA migrate type.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
Acked-by: Arnd Bergmann a...@arndb.de
---
include/linux/page-isolation.h | 40 +++-
mm/page_alloc.c| 19 ---
mm/page_isolation.c| 15 ---
3 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 856d9cf..b2a81fd 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -3,39 +3,53 @@
/*
* Changes migrate type in [start_pfn, end_pfn) to be MIGRATE_ISOLATE.
- * If specified range includes migrate types other than MOVABLE,
+ * If specified range includes migrate types other than MOVABLE or CMA,
* this will fail with -EBUSY.
*
* For isolating all pages in the range finally, the caller have to
* free all pages in the range. test_page_isolated() can be used for
* test it.
*/
-extern int
-start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn);
+int __start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
+ unsigned migratetype);
+
+static inline int
+start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn)
+{
+ return __start_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
+}
+
+int __undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
+ unsigned migratetype);
/*
* Changes MIGRATE_ISOLATE to MIGRATE_MOVABLE.
* target range is [start_pfn, end_pfn)
*/
-extern int
-undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn);
+static inline int
+undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn)
+{
+ return __undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
+}
/*
- * test all pages in [start_pfn, end_pfn)are isolated or not.
+ * Test all pages in [start_pfn, end_pfn) are isolated or not.
*/
-extern int
-test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn);
+int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn);
/*
- * Internal funcs.Changes pageblock's migrate type.
- * Please use make_pagetype_isolated()/make_pagetype_movable().
+ * Internal functions. Changes pageblock's migrate type.
*/
-extern int set_migratetype_isolate(struct page *page);
-extern void unset_migratetype_isolate(struct page *page);
+int set_migratetype_isolate(struct page *page);
+void __unset_migratetype_isolate(struct page *page, unsigned migratetype);
+static inline void unset_migratetype_isolate(struct page *page)
+{
+ __unset_migratetype_isolate(page, MIGRATE_MOVABLE);
+}
extern unsigned long alloc_contig_freed_pages(unsigned long start,
unsigned long end, gfp_t flag);
extern int alloc_contig_range(unsigned long start, unsigned long end,
- gfp_t flags);
+ gfp_t flags, unsigned migratetype);
extern void free_contig_pages(struct page *page, int nr_pages);
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e6c403c..2d2cf29 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5634,7 +5634,7 @@ out:
return ret;
}
-void unset_migratetype_isolate(struct page *page)
+void __unset_migratetype_isolate(struct page *page, unsigned migratetype)
{
struct zone *zone;
unsigned long flags;
@@ -5642,8 +5642,8 @@ void unset_migratetype_isolate(struct page *page)
spin_lock_irqsave(zone-lock, flags);
if (get_pageblock_migratetype(page) != MIGRATE_ISOLATE)
goto out;
- set_pageblock_migratetype(page, MIGRATE_MOVABLE);
- move_freepages_block(zone, page, MIGRATE_MOVABLE);
+ set_pageblock_migratetype(page, migratetype);
+ move_freepages_block(zone, page, migratetype);
out:
spin_unlock_irqrestore(zone-lock, flags);
}
@@ -5748,6 +5748,10 @@ static int __alloc_contig_migrate_range(unsigned long
start, unsigned long end)
* @start: start PFN to allocate
* @end: one-past-the-last PFN to allocate
* @flags: flags passed to alloc_contig_freed_pages().
+ * @migratetype: migratetype of the underlaying pageblocks (either
+ * #MIGRATE_MOVABLE or #MIGRATE_CMA). All pageblocks
+ * in range must have the same migratetype and it must
+ * be either of the two.
*
* The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
* aligned, hovewer it's callers responsibility
[PATCHv12 0/8] Contiguous Memory Allocator
Hello everyone, This is yet another round of Contiguous Memory Allocator patches. Now I focused mainly on the integration of CMA to DMA mapping subsystem on ARM architecture. In this version I've tried to solve the issue of the aliasing in coherent memory mapping that was present in earlier versions of DMA mapping framework. The proposed solution should be considered as a proof-of-concept. Right now it doesn't support GFP_ATOMIC allocations. Support for them is on my TODO list and will be implemented on top of the ARM: DMA: steal memory for DMA coherent mappings patch by Russell King. A few words for these who see CMA for the first time: The Contiguous Memory Allocator (CMA) makes it possible for device drivers to allocate big contiguous chunks of memory after the system has booted. The main difference from the similar frameworks is the fact that CMA allows to transparently reuse memory region reserved for the big chunk allocation as a system memory, so no memory is wasted when no big chunk is allocated. Once the alloc request is issued, the framework will migrate system pages to create a required big chunk of physically contiguous memory. For more information you can refer to nice LWN articles: http://lwn.net/Articles/447405/ and http://lwn.net/Articles/450286/ as well as links to previous versions of the CMA framework. The CMA framework has been initially developed by Michal Nazarewicz at Samsung Poland RD Center. Since version 9, I've taken over the development, because Michal has left the company. The current version of CMA is a set of helper functions for DMA mapping framework that handles allocation of contiguous memory blocks. The difference between this patchset and Kamezawa's alloc_contig_pages() are: 1. alloc_contig_pages() requires MAX_ORDER alignment of allocations which may be unsuitable for embeded systems where a few MiBs are required. Lack of the requirement on the alignment means that several threads might try to access the same pageblock/page. To prevent this from happening CMA uses a mutex so that only one allocating/releasing function may run at one point. 2. CMA may use its own migratetype (MIGRATE_CMA) which behaves similarly to ZONE_MOVABLE but can be put in arbitrary places. This is required for us since we need to define two disjoint memory ranges inside system RAM. (ie. in two memory banks (do not confuse with nodes)). 3. alloc_contig_pages() scans memory in search for range that could be migrated. CMA on the other hand maintains its own allocator to decide where to allocate memory for device drivers and then tries to migrate pages from that part if needed. This is not strictly required but I somehow feel it might be faster. The integration with ARM DMA-mapping subsystem is done on 2 levels. During early boot memory reserved for contiguous areas are remapped with 2-level page tables. This enables us to change cache attributes of the individual pages from such area on request. Then, DMA mapping subsystem is updated to use dma_alloc_from_contiguous() call instead of alloc_pages() and perform page attributes remapping. Current version have been tested on Samsung S5PC110 based Goni machine and s5p-fimc V4L2 driver. The driver itself uses videobuf2 dma-contig memory allocator, which in turn relies on dma_alloc_coherent() from DMA-mapping subsystem. By integrating CMA with DMA-mapping we managed to get this driver working with CMA without any single change required in the driver or videobuf2-dma-contig allocator. TODO: - implement GPF_ATOMIC allocations - implement support for contiguous memory areas placed in HIGHMEM zone Best regards -- Marek Szyprowski Samsung Poland RD Center Links to previous versions of the patchset: v11: http://www.spinics.net/lists/linux-mm/msg21868.html v10: http://www.spinics.net/lists/linux-mm/msg20761.html v9: http://article.gmane.org/gmane.linux.kernel.mm/60787 v8: http://article.gmane.org/gmane.linux.kernel.mm/56855 v7: http://article.gmane.org/gmane.linux.kernel.mm/55626 v6: http://article.gmane.org/gmane.linux.kernel.mm/55626 v5: (intentionally left out as CMA v5 was identical to CMA v4) v4: http://article.gmane.org/gmane.linux.kernel.mm/52010 v3: http://article.gmane.org/gmane.linux.kernel.mm/51573 v2: http://article.gmane.org/gmane.linux.kernel.mm/50986 v1: http://article.gmane.org/gmane.linux.kernel.mm/50669 Changelog: v12: 1. Fixed 2 nasty bugs in dma-contiguous allocator: - alignment argument was not passed correctly - range for dma_release_from_contiguous was not checked correctly 2. Added support for architecture specfic dma_contiguous_early_fixup() function 3. CMA and DMA-mapping integration for ARM architechture has been rewritten to take care of the memory aliasing issue that might happen for newer ARM CPUs (mapping of the same pages with different cache attributes
[PATCH 1/8] mm: move some functions from memory_hotplug.c to page_isolation.c
From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Memory hotplug is a logic for making pages unused in the specified
range of pfn. So, some of core logics can be used for other purpose
as allocating a very large contigous memory block.
This patch moves some functions from mm/memory_hotplug.c to
mm/page_isolation.c. This helps adding a function for large-alloc in
page_isolation.c with memory-unplug technique.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
[m.nazarewicz: reworded commit message]
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[m.szyprowski: rebased and updated to Linux v3.0-rc1]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
Acked-by: Arnd Bergmann a...@arndb.de
---
include/linux/page-isolation.h |7 +++
mm/memory_hotplug.c| 111 --
mm/page_isolation.c| 114
3 files changed, 121 insertions(+), 111 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 051c1b1..58cdbac 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -33,5 +33,12 @@ test_pages_isolated(unsigned long start_pfn, unsigned long
end_pfn);
extern int set_migratetype_isolate(struct page *page);
extern void unset_migratetype_isolate(struct page *page);
+/*
+ * For migration.
+ */
+
+int test_pages_in_a_zone(unsigned long start_pfn, unsigned long end_pfn);
+unsigned long scan_lru_pages(unsigned long start, unsigned long end);
+int do_migrate_range(unsigned long start_pfn, unsigned long end_pfn);
#endif
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index c46887b..c32ca23 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -645,117 +645,6 @@ int is_mem_section_removable(unsigned long start_pfn,
unsigned long nr_pages)
}
/*
- * Confirm all pages in a range [start, end) is belongs to the same zone.
- */
-static int test_pages_in_a_zone(unsigned long start_pfn, unsigned long end_pfn)
-{
- unsigned long pfn;
- struct zone *zone = NULL;
- struct page *page;
- int i;
- for (pfn = start_pfn;
-pfn end_pfn;
-pfn += MAX_ORDER_NR_PAGES) {
- i = 0;
- /* This is just a CONFIG_HOLES_IN_ZONE check.*/
- while ((i MAX_ORDER_NR_PAGES) !pfn_valid_within(pfn + i))
- i++;
- if (i == MAX_ORDER_NR_PAGES)
- continue;
- page = pfn_to_page(pfn + i);
- if (zone page_zone(page) != zone)
- return 0;
- zone = page_zone(page);
- }
- return 1;
-}
-
-/*
- * Scanning pfn is much easier than scanning lru list.
- * Scan pfn from start to end and Find LRU page.
- */
-static unsigned long scan_lru_pages(unsigned long start, unsigned long end)
-{
- unsigned long pfn;
- struct page *page;
- for (pfn = start; pfn end; pfn++) {
- if (pfn_valid(pfn)) {
- page = pfn_to_page(pfn);
- if (PageLRU(page))
- return pfn;
- }
- }
- return 0;
-}
-
-static struct page *
-hotremove_migrate_alloc(struct page *page, unsigned long private, int **x)
-{
- /* This should be improved!! */
- return alloc_page(GFP_HIGHUSER_MOVABLE);
-}
-
-#define NR_OFFLINE_AT_ONCE_PAGES (256)
-static int
-do_migrate_range(unsigned long start_pfn, unsigned long end_pfn)
-{
- unsigned long pfn;
- struct page *page;
- int move_pages = NR_OFFLINE_AT_ONCE_PAGES;
- int not_managed = 0;
- int ret = 0;
- LIST_HEAD(source);
-
- for (pfn = start_pfn; pfn end_pfn move_pages 0; pfn++) {
- if (!pfn_valid(pfn))
- continue;
- page = pfn_to_page(pfn);
- if (!get_page_unless_zero(page))
- continue;
- /*
-* We can skip free pages. And we can only deal with pages on
-* LRU.
-*/
- ret = isolate_lru_page(page);
- if (!ret) { /* Success */
- put_page(page);
- list_add_tail(page-lru, source);
- move_pages--;
- inc_zone_page_state(page, NR_ISOLATED_ANON +
- page_is_file_cache(page));
-
- } else {
-#ifdef CONFIG_DEBUG_VM
- printk(KERN_ALERT removing pfn %lx from LRU failed\n,
- pfn);
- dump_page(page);
-#endif
- put_page(page);
- /* Because we don't have big zone-lock. we should
- check this again here. */
-
[PATCH 4/8] mm: MIGRATE_CMA migration type added
From: Michal Nazarewicz m.nazarew...@samsung.com
The MIGRATE_CMA migration type has two main characteristics:
(i) only movable pages can be allocated from MIGRATE_CMA
pageblocks and (ii) page allocator will never change migration
type of MIGRATE_CMA pageblocks.
This guarantees that page in a MIGRATE_CMA page block can
always be migrated somewhere else (unless there's no memory left
in the system).
It is designed to be used with Contiguous Memory Allocator
(CMA) for allocating big chunks (eg. 10MiB) of physically
contiguous memory. Once driver requests contiguous memory,
CMA will migrate pages from MIGRATE_CMA pageblocks.
To minimise number of migrations, MIGRATE_CMA migration type
is the last type tried when page allocator falls back to other
migration types then requested.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[m.szyprowski: cleaned up Kconfig, renamed some functions, removed ifdefs]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
include/linux/mmzone.h | 41 +++---
include/linux/page-isolation.h |1 +
mm/Kconfig |8 +++-
mm/compaction.c| 10 +
mm/page_alloc.c| 88 +++-
5 files changed, 120 insertions(+), 28 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 9f7c3eb..5152597 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -35,13 +35,35 @@
*/
#define PAGE_ALLOC_COSTLY_ORDER 3
-#define MIGRATE_UNMOVABLE 0
-#define MIGRATE_RECLAIMABLE 1
-#define MIGRATE_MOVABLE 2
-#define MIGRATE_PCPTYPES 3 /* the number of types on the pcp lists */
-#define MIGRATE_RESERVE 3
-#define MIGRATE_ISOLATE 4 /* can't allocate from here */
-#define MIGRATE_TYPES 5
+enum {
+ MIGRATE_UNMOVABLE,
+ MIGRATE_RECLAIMABLE,
+ MIGRATE_MOVABLE,
+ MIGRATE_PCPTYPES, /* the number of types on the pcp lists */
+ MIGRATE_RESERVE = MIGRATE_PCPTYPES,
+ /*
+* MIGRATE_CMA migration type is designed to mimic the way
+* ZONE_MOVABLE works. Only movable pages can be allocated
+* from MIGRATE_CMA pageblocks and page allocator never
+* implicitly change migration type of MIGRATE_CMA pageblock.
+*
+* The way to use it is to change migratetype of a range of
+* pageblocks to MIGRATE_CMA which can be done by
+* __free_pageblock_cma() function. What is important though
+* is that a range of pageblocks must be aligned to
+* MAX_ORDER_NR_PAGES should biggest page be bigger then
+* a single pageblock.
+*/
+ MIGRATE_CMA,
+ MIGRATE_ISOLATE,/* can't allocate from here */
+ MIGRATE_TYPES
+};
+
+#ifdef CONFIG_CMA_MIGRATE_TYPE
+# define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
+#else
+# define is_migrate_cma(migratetype) false
+#endif
#define for_each_migratetype_order(order, type) \
for (order = 0; order MAX_ORDER; order++) \
@@ -54,6 +76,11 @@ static inline int get_pageblock_migratetype(struct page
*page)
return get_pageblock_flags_group(page, PB_migrate, PB_migrate_end);
}
+static inline bool is_pageblock_cma(struct page *page)
+{
+ return is_migrate_cma(get_pageblock_migratetype(page));
+}
+
struct free_area {
struct list_headfree_list[MIGRATE_TYPES];
unsigned long nr_free;
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index c5d1a7c..856d9cf 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -46,4 +46,5 @@ int test_pages_in_a_zone(unsigned long start_pfn, unsigned
long end_pfn);
unsigned long scan_lru_pages(unsigned long start, unsigned long end);
int do_migrate_range(unsigned long start_pfn, unsigned long end_pfn);
+extern void init_cma_reserved_pageblock(struct page *page);
#endif
diff --git a/mm/Kconfig b/mm/Kconfig
index 8ca47a5..6ffedd8 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -189,7 +189,7 @@ config COMPACTION
config MIGRATION
bool Page migration
def_bool y
- depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION
+ depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION ||
CMA_MIGRATE_TYPE
help
Allows the migration of the physical location of pages of processes
while the virtual addresses are not changed. This is useful in
@@ -198,6 +198,12 @@ config MIGRATION
pages as migration can relocate pages to satisfy a huge page
allocation instead of reclaiming.
+config CMA_MIGRATE_TYPE
+ bool
+ help
+ This enables the use the MIGRATE_CMA migrate type, which lets lets CMA
+ work on almost arbitrary memory range and not only inside
ZONE_MOVABLE.
+
config PHYS_ADDR_T_64BIT
[PATCH 3/8] mm: alloc_contig_range() added
From: Michal Nazarewicz m.nazarew...@samsung.com
This commit adds the alloc_contig_range() function which tries
to allecate given range of pages. It tries to migrate all
already allocated pages that fall in the range thus freeing them.
Once all pages in the range are freed they are removed from the
buddy system thus allocated for the caller to use.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[m.szyprowski: renamed some variables for easier code reading]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
Acked-by: Arnd Bergmann a...@arndb.de
---
include/linux/page-isolation.h |2 +
mm/page_alloc.c| 144
2 files changed, 146 insertions(+), 0 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index f1417ed..c5d1a7c 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -34,6 +34,8 @@ extern int set_migratetype_isolate(struct page *page);
extern void unset_migratetype_isolate(struct page *page);
extern unsigned long alloc_contig_freed_pages(unsigned long start,
unsigned long end, gfp_t flag);
+extern int alloc_contig_range(unsigned long start, unsigned long end,
+ gfp_t flags);
extern void free_contig_pages(struct page *page, int nr_pages);
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 00e9b24..2cea044 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5638,6 +5638,150 @@ unsigned long alloc_contig_freed_pages(unsigned long
start, unsigned long end,
return pfn;
}
+static unsigned long pfn_to_maxpage(unsigned long pfn)
+{
+ return pfn ~(MAX_ORDER_NR_PAGES - 1);
+}
+
+static unsigned long pfn_to_maxpage_up(unsigned long pfn)
+{
+ return ALIGN(pfn, MAX_ORDER_NR_PAGES);
+}
+
+#define MIGRATION_RETRY5
+static int __alloc_contig_migrate_range(unsigned long start, unsigned long end)
+{
+ int migration_failed = 0, ret;
+ unsigned long pfn = start;
+
+ /*
+* Some code borrowed from KAMEZAWA Hiroyuki's
+* __alloc_contig_pages().
+*/
+
+ for (;;) {
+ pfn = scan_lru_pages(pfn, end);
+ if (!pfn || pfn = end)
+ break;
+
+ ret = do_migrate_range(pfn, end);
+ if (!ret) {
+ migration_failed = 0;
+ } else if (ret != -EBUSY
+ || ++migration_failed = MIGRATION_RETRY) {
+ return ret;
+ } else {
+ /* There are unstable pages.on pagevec. */
+ lru_add_drain_all();
+ /*
+* there may be pages on pcplist before
+* we mark the range as ISOLATED.
+*/
+ drain_all_pages();
+ }
+ cond_resched();
+ }
+
+ if (!migration_failed) {
+ /* drop all pages in pagevec and pcp list */
+ lru_add_drain_all();
+ drain_all_pages();
+ }
+
+ /* Make sure all pages are isolated */
+ if (WARN_ON(test_pages_isolated(start, end)))
+ return -EBUSY;
+
+ return 0;
+}
+
+/**
+ * alloc_contig_range() -- tries to allocate given range of pages
+ * @start: start PFN to allocate
+ * @end: one-past-the-last PFN to allocate
+ * @flags: flags passed to alloc_contig_freed_pages().
+ *
+ * The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
+ * aligned, hovewer it's callers responsibility to guarantee that we
+ * are the only thread that changes migrate type of pageblocks the
+ * pages fall in.
+ *
+ * Returns zero on success or negative error code. On success all
+ * pages which PFN is in (start, end) are allocated for the caller and
+ * need to be freed with free_contig_pages().
+ */
+int alloc_contig_range(unsigned long start, unsigned long end,
+ gfp_t flags)
+{
+ unsigned long outer_start, outer_end;
+ int ret;
+
+ /*
+* What we do here is we mark all pageblocks in range as
+* MIGRATE_ISOLATE. Because of the way page allocator work, we
+* align the range to MAX_ORDER pages so that page allocator
+* won't try to merge buddies from different pageblocks and
+* change MIGRATE_ISOLATE to some other migration type.
+*
+* Once the pageblocks are marked as MIGRATE_ISOLATE, we
+* migrate the pages from an unaligned range (ie. pages that
+* we are interested in). This will put all the pages in
+* range back to page allocator as MIGRATE_ISOLATE.
+*
+* When this is done, we take the pages in range from page
+* allocator removing them from the buddy
[PATCH 2/8] mm: alloc_contig_freed_pages() added
From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
This commit introduces alloc_contig_freed_pages() function
which allocates (ie. removes from buddy system) free pages
in range. Caller has to guarantee that all pages in range
are in buddy system.
Along with this function, a free_contig_pages() function is
provided which frees all (or a subset of) pages allocated
with alloc_contig_free_pages().
Michal Nazarewicz has modified the function to make it easier
to allocate not MAX_ORDER_NR_PAGES aligned pages by making it
return pfn of one-past-the-last allocated page.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
Acked-by: Arnd Bergmann a...@arndb.de
---
include/linux/page-isolation.h |3 ++
mm/page_alloc.c| 44
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 58cdbac..f1417ed 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -32,6 +32,9 @@ test_pages_isolated(unsigned long start_pfn, unsigned long
end_pfn);
*/
extern int set_migratetype_isolate(struct page *page);
extern void unset_migratetype_isolate(struct page *page);
+extern unsigned long alloc_contig_freed_pages(unsigned long start,
+ unsigned long end, gfp_t flag);
+extern void free_contig_pages(struct page *page, int nr_pages);
/*
* For migration.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 4e8985a..00e9b24 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5600,6 +5600,50 @@ out:
spin_unlock_irqrestore(zone-lock, flags);
}
+unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long end,
+ gfp_t flag)
+{
+ unsigned long pfn = start, count;
+ struct page *page;
+ struct zone *zone;
+ int order;
+
+ VM_BUG_ON(!pfn_valid(start));
+ zone = page_zone(pfn_to_page(start));
+
+ spin_lock_irq(zone-lock);
+
+ page = pfn_to_page(pfn);
+ for (;;) {
+ VM_BUG_ON(page_count(page) || !PageBuddy(page));
+ list_del(page-lru);
+ order = page_order(page);
+ zone-free_area[order].nr_free--;
+ rmv_page_order(page);
+ __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL order));
+ pfn += 1 order;
+ if (pfn = end)
+ break;
+ VM_BUG_ON(!pfn_valid(pfn));
+ page += 1 order;
+ }
+
+ spin_unlock_irq(zone-lock);
+
+ /* After this, pages in the range can be freed one be one */
+ page = pfn_to_page(start);
+ for (count = pfn - start; count; --count, ++page)
+ prep_new_page(page, 0, flag);
+
+ return pfn;
+}
+
+void free_contig_pages(struct page *page, int nr_pages)
+{
+ for (; nr_pages; --nr_pages, ++page)
+ __free_page(page);
+}
+
#ifdef CONFIG_MEMORY_HOTREMOVE
/*
* All pages in the range must be isolated before calling this.
--
1.7.1.569.g6f426
--
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][saa7134] do not change mute state for capturing audio
Em 20-07-2011 02:28, Stas Sergeev escreveu:
20.07.2011 04:55, Mauro Carvalho Chehab wrote:
The proposed solution is to have the mute
control, that can be valid for all the cards/drivers.
Presumably, it should have the similar name
for all of them, even though for some it will be
a virtual control that will control several items,
and for others - it should map directly to their
single mute control.
If we have such a mute control, any app can use
it,
Any app can do it right now via the V4L2 api.
I am just following your logic, you said that
---
Moving such logic to happen at userspace would be very complex, and will
break existing applications.
---
To solve that, I proposed adding such mixer control
to where it is missing right now.
But if this is no longer a problem and the app
can just use v4l2 for that instead, then what still
keeps us from removing the auto-unmute things?
I won't keep discussing something that won't be merged, as it will
cause regressions.
and the auto-unmute logic can be removed
from the alsa driver. v4l2 is left as it is now.
What is the sense of capturing data for a device that is not ready
for stream?
This may be a PA's hack, or a user's mistake, or
whatever, but whatever it is, it shouldn't lead to
any sounds from speakers. Just starting the capture,
willingly or by mistake, should never lead to any
sound from speakers, IMO. So that's the bug too.
And the simpler one to fix.
If the application is starting streaming, audio should be expected on devices
where the audio output is internally wired with the capture input.
This seems to be the case of your device. There's nothing that can be
done to fix a bad hardware design or the lack of enough information
from the device manufacturer.
The enclosed patch probably does the trick (completely untested).
I'll be able to test it on avertv 307 the next week-end.
The patch is not that simple. The driver needs to set the device inputs
accordingly, otherwise it will break support for digital audio.
In the specific case of avertv 307, this patch alone may not work. I suspect
that there is a problem at the GPIO settings for mute on its board entry:
[SAA7134_BOARD_AVERMEDIA_STUDIO_307] = {
...
.inputs = {{
.name = name_tv,
.vmux = 1,
.amux = TV,
.tv = 1,
.gpio = 0x00,
},{
...
.mute = {
.name = name_mute,
.amux = LINE1,
.gpio = 0x00,
},
See: mute GPIO's are equal for TV GPIO. That means that it will select the
TV gpio for mute.
-
[PATCHv2 - BROKEN] saa7134: Don't touch at the analog mute at the alsa driver
Via the alsa driver, it is possible to start capturing from an audio input.
When capture is started, the driver will unmute the audio input associated
with the selected video input, if it were muted.
However, if the device is using a wire for the audio output, it may produce
audio at the speakers. This patch changes the mute logic to:
1) on saa7134, don't touch at the ANALOG_MUTE at alsa unmute call;
2) don't change the GPIO's.
I suspect, however, that not changing the GPIO's is a very bad idea, and
it will actually break audio for devices with external GPIO-based input
switches, but, as this version was already done, it might be useful for some
tests. A version 3 will follow shortly.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c
b/drivers/media/video/saa7134/saa7134-alsa.c
index 10460fd..cbc665a 100644
--- a/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/drivers/media/video/saa7134/saa7134-alsa.c
@@ -77,7 +77,6 @@ typedef struct snd_card_saa7134 {
unsigned long iobase;
s16 irq;
- u16 mute_was_on;
spinlock_t lock;
} snd_card_saa7134_t;
@@ -718,9 +717,10 @@ static int snd_card_saa7134_capture_close(struct
snd_pcm_substream * substream)
snd_card_saa7134_t *saa7134 = snd_pcm_substream_chip(substream);
struct saa7134_dev *dev = saa7134-dev;
- if (saa7134-mute_was_on) {
+ if (dev-mute_was_on) {
dev-ctl_mute = 1;
saa7134_tvaudio_setmute(dev);
+ dev-mute_was_on = false;
}
return 0;
}
@@ -775,7 +775,7 @@ static int snd_card_saa7134_capture_open(struct
snd_pcm_substream * substream)
runtime-hw = snd_card_saa7134_capture;
if (dev-ctl_mute != 0) {
- saa7134-mute_was_on = 1;
+ dev-mute_was_on = true;
dev-ctl_mute = 0;
saa7134_tvaudio_setmute(dev);
}
diff --git a/drivers/media/video/saa7134/saa7134-tvaudio.c
b/drivers/media/video/saa7134/saa7134-tvaudio.c
index 57e646b..535aa75 100644
--- a/drivers/media/video/saa7134/saa7134-tvaudio.c
+++
Re: [patch][saa7134] do not change mute state for capturing audio
Em 20-07-2011 07:32, Mauro Carvalho Chehab escreveu:
Em 20-07-2011 02:28, Stas Sergeev escreveu:
20.07.2011 04:55, Mauro Carvalho Chehab wrote:
[PATCHv2 - BROKEN] saa7134: Don't touch at the analog mute at the alsa driver
Via the alsa driver, it is possible to start capturing from an audio input.
When capture is started, the driver will unmute the audio input associated
with the selected video input, if it were muted.
However, if the device is using a wire for the audio output, it may produce
audio at the speakers. This patch changes the mute logic to:
1) on saa7134, don't touch at the ANALOG_MUTE at alsa unmute call;
2) don't change the GPIO's.
I suspect, however, that not changing the GPIO's is a very bad idea, and
it will actually break audio for devices with external GPIO-based input
switches, but, as this version was already done, it might be useful for some
tests. A version 3 will follow shortly.
[PATCHv3] saa7134: Don't touch at the analog mute at the alsa driver
Via the alsa driver, it is possible to start capturing from an audio input.
When capture is started, the driver will unmute the audio input associated
with the selected video input, if it were muted.
However, if the device is using a wire for the audio output, it may produce
audio at the speakers. This patch changes the mute logic to don't touch
at the ANALOG_MUTE at alsa unmute call, for saa7134. Not sure if this will
produce any effect, as it will depend on how the board is wired, but it is
a worth trial.
Patch is untested.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c
b/drivers/media/video/saa7134/saa7134-alsa.c
index 10460fd..cbc665a 100644
--- a/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/drivers/media/video/saa7134/saa7134-alsa.c
@@ -77,7 +77,6 @@ typedef struct snd_card_saa7134 {
unsigned long iobase;
s16 irq;
- u16 mute_was_on;
spinlock_t lock;
} snd_card_saa7134_t;
@@ -718,9 +717,10 @@ static int snd_card_saa7134_capture_close(struct
snd_pcm_substream * substream)
snd_card_saa7134_t *saa7134 = snd_pcm_substream_chip(substream);
struct saa7134_dev *dev = saa7134-dev;
- if (saa7134-mute_was_on) {
+ if (dev-mute_was_on) {
dev-ctl_mute = 1;
saa7134_tvaudio_setmute(dev);
+ dev-mute_was_on = false;
}
return 0;
}
@@ -775,7 +775,7 @@ static int snd_card_saa7134_capture_open(struct
snd_pcm_substream * substream)
runtime-hw = snd_card_saa7134_capture;
if (dev-ctl_mute != 0) {
- saa7134-mute_was_on = 1;
+ dev-mute_was_on = true;
dev-ctl_mute = 0;
saa7134_tvaudio_setmute(dev);
}
diff --git a/drivers/media/video/saa7134/saa7134-tvaudio.c
b/drivers/media/video/saa7134/saa7134-tvaudio.c
index 57e646b..11631f4 100644
--- a/drivers/media/video/saa7134/saa7134-tvaudio.c
+++ b/drivers/media/video/saa7134/saa7134-tvaudio.c
@@ -190,6 +190,9 @@ static void mute_input_7134(struct saa7134_dev *dev)
struct saa7134_input *in;
int ausel=0, ics=0, ocs=0;
int mask;
+ bool change_analog_mute;
+
+ change_analog_mute = dev-mute_was_on ? false : true;
/* look what is to do ... */
in = dev-input;
@@ -204,7 +207,8 @@ static void mute_input_7134(struct saa7134_dev *dev)
in = card(dev).mute;
}
- if (dev-hw_mute == mute
+
+ if (dev-hw_mute == mute !dev-mute_was_on
dev-hw_input == in !dev-insuspend) {
dprintk(mute/input: nothing to do [mute=%d,input=%s]\n,
mute,in-name);
@@ -216,13 +220,18 @@ static void mute_input_7134(struct saa7134_dev *dev)
dev-hw_mute = mute;
dev-hw_input = in;
- if (PCI_DEVICE_ID_PHILIPS_SAA7134 == dev-pci-device)
+ if (PCI_DEVICE_ID_PHILIPS_SAA7134 == dev-pci-device) {
+ u32 mask = ~0;
+ u32 mute_val = SAA7134_MUTE_MASK;
+
+ if (!change_analog_mute)
+ mask ^= SAA7134_MUTE_ANALOG;
+ if (mute)
+ mute_val |= SAA7134_MUTE_I2S | SAA7134_MUTE_ANALOG;
+
/* 7134 mute */
- saa_writeb(SAA7134_AUDIO_MUTE_CTRL, mute ?
- SAA7134_MUTE_MASK |
- SAA7134_MUTE_ANALOG |
- SAA7134_MUTE_I2S :
- SAA7134_MUTE_MASK);
+ saa_andorb(SAA7134_AUDIO_MUTE_CTRL, mask, mute_val);
+ }
/* switch internal audio mux */
switch (in-amux) {
diff --git a/drivers/media/video/saa7134/saa7134.h
b/drivers/media/video/saa7134/saa7134.h
index bc8d6bb..ae34f68 100644
--- a/drivers/media/video/saa7134/saa7134.h
Re: [patch][saa7134] do not change mute state for capturing audio
20.07.2011 14:32, Mauro Carvalho Chehab wrote: I won't keep discussing something that won't be merged, as it will cause regressions. Please explain what regressions it will make! I am asking that question over and over again, and every time you either ignore it, or refer to an apps that use v4l2 ioctls, which are unaffected. I wonder why you don't want to explain what regressions do you have in mind... If the application is starting streaming, audio should be expected on devices where the audio output is internally wired with the capture input. This seems to be the case of your device. There's nothing that can be done to fix a bad hardware design or the lack of enough information from the device manufacturer. Well, until you explain the exact breakage of my proposal, I won't trust this. :) I suspect, however, that not changing the GPIO's is a very bad idea, and it will actually break audio for devices with external GPIO-based input switches, but, as this version was already done, it might be useful for some tests. A version 3 will follow shortly. I'll test at a week-end whatever we'll have to that date. -- 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][saa7134] do not change mute state for capturing audio
Em 20-07-2011 07:45, Stas Sergeev escreveu: 20.07.2011 14:32, Mauro Carvalho Chehab wrote: I won't keep discussing something that won't be merged, as it will cause regressions. Please explain what regressions it will make! I am asking that question over and over again, and every time you either ignore it, or refer to an apps that use v4l2 ioctls, which are unaffected. I wonder why you don't want to explain what regressions do you have in mind... If the application is starting streaming, audio should be expected on devices where the audio output is internally wired with the capture input. This seems to be the case of your device. There's nothing that can be done to fix a bad hardware design or the lack of enough information from the device manufacturer. Well, until you explain the exact breakage of my proposal, I won't trust this. :) I've said already: mplayer for example relies on such behavior to work. Reverting it breaks mplayer. This is enough for me to NACK your patch. I suspect, however, that not changing the GPIO's is a very bad idea, and it will actually break audio for devices with external GPIO-based input switches, but, as this version was already done, it might be useful for some tests. A version 3 will follow shortly. I'll test at a week-end whatever we'll have to that date. -- 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][saa7134] do not change mute state for capturing audio
20.07.2011 14:48, Mauro Carvalho Chehab wrote: Well, until you explain the exact breakage of my proposal, I won't trust this. :) I've said already: mplayer for example relies on such behavior to work. Reverting it breaks mplayer. This is enough for me to NACK your patch. What you said, was: --- Some applications like mplayer don't use V4L2_CID_AUDIO_MUTE to unmute a video device. They assume the current behavior that starting video also unmutes audio. --- starting video also unmutes audio is what my patch _does not touch_! And that certainly happens not even in the alsa driver, but somewhere in the v4l2 code. So, please please please, could you actually precisely explain how exactly mplayer breaks with my patch? That's the only thing I need! :)) -- 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] Fix wrong register mask in gspca/sonixj.c
On Mon, 18 Jul 2011 18:39:14 -0700 (PDT) Luiz Ramos lramos.p...@yahoo.com.br wrote: [snip] I noticed that in 640x480 the device worked fine, but in 320x240 and 160x120 it didn't (I mean: the image is dark). Or'ing reg17 with 0x04 in line 2535 (as it's currently done for VGA) is sufficient to make the webcam work again. The change could be like that: [snip] However, the frame rates get limited to 10 fps. Without that change, and in 320x240 and 160x120, they reach 20 fps (of darkness). I can't see what or'ing that register means, and what's the relationship between this and the webcam darkness. It seems that these bits control some kind of clock; this can be read in the program comments. One other argument in favour of this assumption is the fact that the frame rate changes accordingly to the value of these bits. But I can't see how this relates to exposure. For my purposes, I'll stay with that change; it's sufficient for my purposes. If you know what I did, please advise me. :-) Hi Luiz, You changed the sensor clock from 24MHz to 12MHz. The clocks of the sensor and the bridge may have different values. In 640x480, the bridge clock is 48MHz (reg01) and the sensor clock is 12MHz (reg17: clock / 4). Previously, in 320x240, the bridge clock was 48MHz and the sensor clock 24 MHz (reg17: clock / 2). I think that the sensor clock must stay the same for a same frame rate. So, what about changing the bridge clock only, i.e. bridge clock 24MHZ (reg01) and sensor clock 24MHz (reg17: clock / 1)? That's what I coded in the last gspca test version (2.13.3) which is available in my web site (see below). May you try it? Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] siano: apply debug flag to module level.
Hi,
Siano modules already had sms_dbg flag which is a module parameter which
sets the debug mode so module prints messages to dmesg for debugging.
The variable was static therefore apply only to the file which defines
the module. In modules as smsmdtv.ko that contain a few files, the debug
flag applied only for functions in that main file.
flag was changed to be non-static and therefore can be accessed by all
module files (although it is still not exported out of the module).
Thanks,
Doron
Signed-off-by: Doron Cohen dor...@siano-ms.com
---
drivers/media/dvb/siano/sms-cards.c |4
drivers/media/dvb/siano/smscoreapi.c |2 +-
drivers/media/dvb/siano/smscoreapi.h |1 +
drivers/media/dvb/siano/smsdvb.c |2 +-
drivers/media/dvb/siano/smsusb.c |2 +-
5 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb/siano/sms-cards.c
b/drivers/media/dvb/siano/sms-cards.c
index af121db..cf442dc 100644
--- a/drivers/media/dvb/siano/sms-cards.c
+++ b/drivers/media/dvb/siano/sms-cards.c
@@ -20,10 +20,6 @@
#include sms-cards.h
#include smsir.h
-static int sms_dbg;
-module_param_named(cards_dbg, sms_dbg, int, 0644);
-MODULE_PARM_DESC(cards_dbg, set debug level (info=1, adv=2
(or-able)));
-
static struct sms_board sms_boards[] = {
[SMS_BOARD_UNKNOWN] = {
.name = Unknown board,
diff --git a/drivers/media/dvb/siano/smscoreapi.c
b/drivers/media/dvb/siano/smscoreapi.c
index 78765ed..239f453 100644
--- a/drivers/media/dvb/siano/smscoreapi.c
+++ b/drivers/media/dvb/siano/smscoreapi.c
@@ -39,7 +39,7 @@
#include smsir.h
#include smsendian.h
-static int sms_dbg;
+int sms_dbg;
module_param_named(debug, sms_dbg, int, 0644);
MODULE_PARM_DESC(debug, set debug level (info=1, adv=2 (or-able)));
diff --git a/drivers/media/dvb/siano/smscoreapi.h
b/drivers/media/dvb/siano/smscoreapi.h
index 8ecadec..05dd9f6 100644
--- a/drivers/media/dvb/siano/smscoreapi.h
+++ b/drivers/media/dvb/siano/smscoreapi.h
@@ -752,6 +752,7 @@ int smscore_led_state(struct smscore_device_t *core,
int led);
/*
*/
+extern int sms_dbg;
#define DBG_INFO 1
#define DBG_ADV 2
diff --git a/drivers/media/dvb/siano/smsdvb.c
b/drivers/media/dvb/siano/smsdvb.c
index 37c594f..9fbf022 100644
--- a/drivers/media/dvb/siano/smsdvb.c
+++ b/drivers/media/dvb/siano/smsdvb.c
@@ -60,7 +60,7 @@ struct smsdvb_client_t {
static struct list_head g_smsdvb_clients;
static struct mutex g_smsdvb_clientslock;
-static int sms_dbg;
+int sms_dbg;
module_param_named(debug, sms_dbg, int, 0644);
MODULE_PARM_DESC(debug, set debug level (info=1, adv=2 (or-able)));
diff --git a/drivers/media/dvb/siano/smsusb.c
b/drivers/media/dvb/siano/smsusb.c
index 0b8da57..da4628d 100644
--- a/drivers/media/dvb/siano/smsusb.c
+++ b/drivers/media/dvb/siano/smsusb.c
@@ -29,7 +29,7 @@ along with this program. If not, see
http://www.gnu.org/licenses/.
#include sms-cards.h
#include smsendian.h
-static int sms_dbg;
+int sms_dbg;
module_param_named(debug, sms_dbg, int, 0644);
MODULE_PARM_DESC(debug, set debug level (info=1, adv=2 (or-able)));
--
--
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/3] OMAP3 ISP patches for v3.1
Laurent Pinchart wrote: Hi everybody, Here are the OMAP3 ISP patches in my queue for v3.1. I'll send a pull request in a couple of days if there's no objection. Kalle Jokiniemi (2): OMAP3: ISP: Add regulator control for omap34xx OMAP3: RX-51: define vdds_csib regulator supply Laurent Pinchart (1): omap3isp: Support configurable HS/VS polarities arch/arm/mach-omap2/board-rx51-peripherals.c |5 drivers/media/video/omap3isp/isp.h |6 + drivers/media/video/omap3isp/ispccdc.c |4 +- drivers/media/video/omap3isp/ispccp2.c | 27 - drivers/media/video/omap3isp/ispccp2.h |1 + 5 files changed, 39 insertions(+), 4 deletions(-) Hi Laurent, Thanks for the patchset! Acked-by: Sakari Ailus sakari.ai...@iki.fi -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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] imon: don't parse scancodes until intf configured
On Wed, Jul 20, 2011 at 08:05:43AM +1000, Chris W wrote: On 20/07/11 02:12, Jarod Wilson wrote: The imon devices have either 1 or 2 usb interfaces on them, each wired up to its own urb callback. The interface 0 urb callback is wired up before the imon context's rc_dev pointer is filled in, which is necessary for imon 0xffdc device auto-detection to work properly, but we need to make sure we don't actually run the callback routines until we've entirely filled in the necessary bits for each given interface, lest we wind up oopsing. Technically, any imon device could have hit this, but the issue is exacerbated on the 0xffdc devices, which send a constant stream of interrupts, even when they have no valid key data. OK. The patch applies and everything continues to work. There is no obvious difference in the dmesg output on module load, with my device remaining unidentified. I don't know if that is indicative of anything. Did you apply this patch on top of the earlier patch, or instead of it? input: iMON Panel, Knob and Mouse(15c2:ffdc) as /devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/input/input9 imon 4-2:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id 0x00) The 'id 0x00' part should read 'id 0x24', as the ongoing spew below has in index 6, which makes me think you still have the earlier patch applied. You actually want only the newer patch applied. If you only have the newer one applied, then I'll have to take another look to see what's up. intf0 decoded packet: 00 00 00 00 00 00 24 01 intf0 decoded packet: 00 00 00 00 00 00 24 01 intf0 decoded packet: 00 00 00 00 00 00 24 01 One other amusing tidbit: you get continuous spew like the above, because to date, I thought all the ffdc devices had nothing to report spew that started with 0xff, which we filter out. Sigh. I hate imon hardware... -- Jarod Wilson ja...@redhat.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
[GIT PULL FOR v3.1] OMAP3 ISP fixes
Hi Mauro, The following changes since commit 9bc5f6fa12c9e3e1e73e66bfabe9d463ea779b08: [media] drxk: Remove goto/break after return (2011-07-15 09:35:58 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git omap3isp-next-omap3isp Kalle Jokiniemi (2): OMAP3: ISP: Add regulator control for omap34xx OMAP3: RX-51: define vdds_csib regulator supply Laurent Pinchart (1): omap3isp: Support configurable HS/VS polarities arch/arm/mach-omap2/board-rx51-peripherals.c |5 drivers/media/video/omap3isp/isp.h |6 + drivers/media/video/omap3isp/ispccdc.c |4 +- drivers/media/video/omap3isp/ispccp2.c | 27 - drivers/media/video/omap3isp/ispccp2.h |1 + 5 files changed, 39 insertions(+), 4 deletions(-) -- 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 v3] V4L: add two new ioctl()s for multi-size videobuffer management
Hi, Guennadi! Thanks for the patch! On Wed, Jul 20, 2011 at 10:43:08AM +0200, Guennadi Liakhovetski wrote: A possibility to preallocate and initialise buffers of different sizes in V4L2 is required for an efficient implementation of asnapshot mode. This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF and defines respective data structures. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- It's been almost a month since v2, the only comments were a request to increase the reserved space in the new ioctl() and to improve documentation. The reserved field is increased in this version, documentation also has been improved in multiple locations. I think, documentation can be further improved at any time, but if there are no objections against the actual contents of this patch, maybe we can commit this version. I still don't see v3.0;-), so, maybe we even can push it for 3.1. A trivial comparison with v2 shows the size of the reserved field as the only change in the API, and the compatibility fix as the only two functional changes. v3: addressed multiple comments by Sakari Ailus 1. increased reserved field in struct v4l2_create_buffers to 8 32-bit ints 2. multiple documentation fixes and improvements 3. fixed misplaced case VIDIOC_PREPARE_BUF in ioctl 32-bit compatibility processing v2: 1. add preliminary Documentation 2. add flag V4L2_BUFFER_FLAG_NO_CACHE_CLEAN 3. remove VIDIOC_DESTROY_BUFS 4. rename SUBMIT to VIDIOC_PREPARE_BUF 5. add reserved field to struct v4l2_create_buffers 6. cache handling flags moved to struct v4l2_buffer for processing during VIDIOC_PREPARE_BUF 7. VIDIOC_PREPARE_BUF now uses struct v4l2_buffer as its argument Documentation/DocBook/media/v4l/io.xml | 17 +++ Documentation/DocBook/media/v4l/v4l2.xml |2 + .../DocBook/media/v4l/vidioc-create-bufs.xml | 152 .../DocBook/media/v4l/vidioc-prepare-buf.xml | 96 drivers/media/video/v4l2-compat-ioctl32.c | 68 - drivers/media/video/v4l2-ioctl.c | 32 include/linux/videodev2.h | 16 ++ include/media/v4l2-ioctl.h |2 + 8 files changed, 377 insertions(+), 8 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-create-bufs.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 227e7ac..6249d0e 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -927,6 +927,23 @@ ioctl is called./entry Applications set or clear this flag before calling the constantVIDIOC_QBUF/constant ioctl./entry /row + row + entryconstantV4L2_BUF_FLAG_NO_CACHE_INVALIDATE/constant/entry + entry0x0400/entry + entryCaches do not have to be invalidated for this buffer. +Typically applications shall use this flag, if the data, captured in the buffer +is not going to br touched by the CPU, instead the buffer will, probably, be +passed on to a DMA-capable hardware unit for further processing or output. +/entry + /row + row + entryconstantV4L2_BUF_FLAG_NO_CACHE_CLEAN/constant/entry + entry0x0800/entry + entryCaches do not have to be cleaned for this buffer. +Typically applications shall use this flag for output buffers, if the data +in this buffer has not been created by the CPU, but by some DMA-capable unit, +in which case caches have not been used./entry + /row /tbody /tgroup /table diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 0d05e87..06bb179 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -462,6 +462,7 @@ and discussions on the V4L mailing list./revremark sub-close; sub-ioctl; !-- All ioctls go here. -- +sub-create-bufs; sub-cropcap; sub-dbg-g-chip-ident; sub-dbg-g-register; @@ -504,6 +505,7 @@ and discussions on the V4L mailing list./revremark sub-queryctrl; sub-query-dv-preset; sub-querystd; +sub-prepare-buf; sub-reqbufs; sub-s-hw-freq-seek; sub-streamon; diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml new file mode 100644 index 000..5f0158c --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml @@ -0,0 +1,152 @@ +refentry id=vidioc-create-bufs + refmeta +refentrytitleioctl VIDIOC_CREATE_BUFS/refentrytitle +manvol; + /refmeta + + refnamediv +refnameVIDIOC_CREATE_BUFS/refname +refpurposeCreate buffers for Memory Mapped or User Pointer
Re: [PATCH v3] V4L: add two new ioctl()s for multi-size videobuffer management
On Wed, Jul 20, 2011 at 04:47:46PM +0200, Guennadi Liakhovetski wrote: On Wed, 20 Jul 2011, Sakari Ailus wrote: Hi, Guennadi! Thanks for the patch! On Wed, Jul 20, 2011 at 10:43:08AM +0200, Guennadi Liakhovetski wrote: A possibility to preallocate and initialise buffers of different sizes in V4L2 is required for an efficient implementation of asnapshot mode. This patch adds two new ioctl()s: VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF and defines respective data structures. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- It's been almost a month since v2, the only comments were a request to increase the reserved space in the new ioctl() and to improve documentation. The reserved field is increased in this version, documentation also has been improved in multiple locations. I think, documentation can be further improved at any time, but if there are no objections against the actual contents of this patch, maybe we can commit this version. I still don't see v3.0;-), so, maybe we even can push it for 3.1. A trivial comparison with v2 shows the size of the reserved field as the only change in the API, and the compatibility fix as the only two functional changes. v3: addressed multiple comments by Sakari Ailus 1. increased reserved field in struct v4l2_create_buffers to 8 32-bit ints 2. multiple documentation fixes and improvements 3. fixed misplaced case VIDIOC_PREPARE_BUF in ioctl 32-bit compatibility processing v2: 1. add preliminary Documentation 2. add flag V4L2_BUFFER_FLAG_NO_CACHE_CLEAN 3. remove VIDIOC_DESTROY_BUFS 4. rename SUBMIT to VIDIOC_PREPARE_BUF 5. add reserved field to struct v4l2_create_buffers 6. cache handling flags moved to struct v4l2_buffer for processing during VIDIOC_PREPARE_BUF 7. VIDIOC_PREPARE_BUF now uses struct v4l2_buffer as its argument Documentation/DocBook/media/v4l/io.xml | 17 +++ Documentation/DocBook/media/v4l/v4l2.xml |2 + .../DocBook/media/v4l/vidioc-create-bufs.xml | 152 .../DocBook/media/v4l/vidioc-prepare-buf.xml | 96 drivers/media/video/v4l2-compat-ioctl32.c | 68 - drivers/media/video/v4l2-ioctl.c | 32 include/linux/videodev2.h | 16 ++ include/media/v4l2-ioctl.h |2 + 8 files changed, 377 insertions(+), 8 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-create-bufs.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 227e7ac..6249d0e 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -927,6 +927,23 @@ ioctl is called./entry Applications set or clear this flag before calling the constantVIDIOC_QBUF/constant ioctl./entry /row + row + entryconstantV4L2_BUF_FLAG_NO_CACHE_INVALIDATE/constant/entry + entry0x0400/entry + entryCaches do not have to be invalidated for this buffer. +Typically applications shall use this flag, if the data, captured in the buffer +is not going to br touched by the CPU, instead the buffer will, probably, be +passed on to a DMA-capable hardware unit for further processing or output. +/entry + /row + row + entryconstantV4L2_BUF_FLAG_NO_CACHE_CLEAN/constant/entry + entry0x0800/entry + entryCaches do not have to be cleaned for this buffer. +Typically applications shall use this flag for output buffers, if the data +in this buffer has not been created by the CPU, but by some DMA-capable unit, +in which case caches have not been used./entry + /row /tbody /tgroup /table diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 0d05e87..06bb179 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -462,6 +462,7 @@ and discussions on the V4L mailing list./revremark sub-close; sub-ioctl; !-- All ioctls go here. -- +sub-create-bufs; sub-cropcap; sub-dbg-g-chip-ident; sub-dbg-g-register; @@ -504,6 +505,7 @@ and discussions on the V4L mailing list./revremark sub-queryctrl; sub-query-dv-preset; sub-querystd; +sub-prepare-buf; sub-reqbufs; sub-s-hw-freq-seek; sub-streamon; diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml new file mode 100644 index 000..5f0158c --- /dev/null +++
Re: [GIT PULL] NetUP Dual DVB-T/C CI RF card
Hi Mauro, Here is more correct pull request. URL now is git://git.netup.tv/git/linux-3.0-netup.git. The following changes since commit f560f6697f17e2465c8845c09f3a483faef38275: Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6 (2011-07-17 12:49:55 -0700) are available in the git repository at: git://git.netup.tv/git/linux-3.0-netup.git netup-fw Abylay Ospan (3): NetUP Dual DVB-T/C CI RF: load firmware according card revision Don't fail if videobuf_dvb_get_frontend return NULL NetUP Dual DVB-T/C CI RF: force card hardware revision by module param drivers/media/video/cx23885/cx23885-cards.c | 21 + drivers/media/video/cx23885/cx23885-dvb.c |2 +- 2 files changed, 22 insertions(+), 1 deletions(-) On 18.07.2011 12:21, Abylay Ospan wrote: Hi Mauro, Please pull 3 changes from http://stand.netup.tv/gitweb/?p=linux-3.0-netup;a=summary Thanks! The following changes since commit f560f6697f17e2465c8845c09f3a483faef38275: Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6 (2011-07-17 12:49:55 -0700) are available in the git repository at: http://stand.netup.tv/gitweb/?p=linux-3.0-netup netup_fw Abylay Ospan (3): NetUP Dual DVB-T/C CI RF: load firmware according card revision Don't fail if videobuf_dvb_get_frontend return NULL NetUP Dual DVB-T/C CI RF: force card hardware revision by module param drivers/media/video/cx23885/cx23885-cards.c | 21 + drivers/media/video/cx23885/cx23885-dvb.c |2 +- 2 files changed, 22 insertions(+), 1 deletions(-) -- Abylai Ospanaos...@netup.ru NetUP Inc. -- 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] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Jul 20 19:00:31 CEST 2011 git hash:9bc5f6fa12c9e3e1e73e66bfabe9d463ea779b08 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification 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: [GIT PULL] NetUP Dual DVB-T/C CI RF card
Hi Abylay, Em 20-07-2011 13:56, Abylay Ospan escreveu: Hi Mauro, Here is more correct pull request. URL now is git://git.netup.tv/git/linux-3.0-netup.git. The following changes since commit f560f6697f17e2465c8845c09f3a483faef38275: Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6 (2011-07-17 12:49:55 -0700) are available in the git repository at: git://git.netup.tv/git/linux-3.0-netup.git netup-fw Could you please also prepare a patch moving altera-stapl to drivers/misc? Thanks! Mauro Abylay Ospan (3): NetUP Dual DVB-T/C CI RF: load firmware according card revision Don't fail if videobuf_dvb_get_frontend return NULL NetUP Dual DVB-T/C CI RF: force card hardware revision by module param drivers/media/video/cx23885/cx23885-cards.c | 21 + drivers/media/video/cx23885/cx23885-dvb.c |2 +- 2 files changed, 22 insertions(+), 1 deletions(-) On 18.07.2011 12:21, Abylay Ospan wrote: Hi Mauro, Please pull 3 changes from http://stand.netup.tv/gitweb/?p=linux-3.0-netup;a=summary Thanks! The following changes since commit f560f6697f17e2465c8845c09f3a483faef38275: Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6 (2011-07-17 12:49:55 -0700) are available in the git repository at: http://stand.netup.tv/gitweb/?p=linux-3.0-netup netup_fw Abylay Ospan (3): NetUP Dual DVB-T/C CI RF: load firmware according card revision Don't fail if videobuf_dvb_get_frontend return NULL NetUP Dual DVB-T/C CI RF: force card hardware revision by module param drivers/media/video/cx23885/cx23885-cards.c | 21 + drivers/media/video/cx23885/cx23885-dvb.c |2 +- 2 files changed, 22 insertions(+), 1 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] dvb/as102 nBox DVB-T dongle
I just bought DVB-T USB dongle for one of polish digital platform. It
works fine with as102 driver.
Here is patch adding vendor and product ID to as102 driver taken from
http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102.
I tested it with kernel-3.0-rc7-git7 (had to change usb_buffer_alloc()
to usb_alloc_coherent and usb_buffer_free to usb_free_coherent() ).
patch:
diff -Nur linux/drivers/media/dvb/as102/as102_usb_drv.c
linux-mine/drivers/media/dvb/as102/as102_usb_drv.c
--- as102/as102_usb_drv.c2011-07-20 21:37:33.924143297 +0200
+++ /usr/src/linux/drivers/media/dvb/as102/as102_usb_drv.c2011-07-20
20:40:21.0 +0200
@@ -39,6 +39,7 @@
static struct usb_device_id as102_usb_id_table[] = {
{ USB_DEVICE(AS102_USB_DEVICE_VENDOR_ID, AS102_USB_DEVICE_PID_0001) },
{ USB_DEVICE(PCTV_74E_USB_VID, PCTV_74E_USB_PID) },
+{ USB_DEVICE(NBOX_USB_VID, NBOX_USB_PID) },
{ USB_DEVICE(ELGATO_EYETV_DTT_USB_VID, ELGATO_EYETV_DTT_USB_PID) },
{ } /* Terminating entry */
};
@@ -48,6 +49,7 @@
static const char *as102_device_names[] = {
AS102_REFERENCE_DESIGN,
AS102_PCTV_74E,
+AS102_NBOX,
AS102_ELGATO_EYETV_DTT_NAME,
NULL /* Terminating entry */
};
diff -Nur linux/drivers/media/dvb/as102/as102_usb_drv.h
linux-mine/drivers/media/dvb/as102/as102_usb_drv.h
--- as102/as102_usb_drv.h2011-07-20 21:37:33.925143297 +0200
+++ /usr/src/linux/drivers/media/dvb/as102/as102_usb_drv.h2011-07-20
20:39:46.0 +0200
@@ -36,6 +36,11 @@
#define PCTV_74E_USB_VID0x2013
#define PCTV_74E_USB_PID0x0246
+/* nBox DVB-T Stick */
+#define AS102_NBOXnBox DVB-T Stick
+#define NBOX_USB_VID0x0b89
+#define NBOX_USB_PID0x0007
+
/* Elgato: EyeTV DTT Deluxe */
#define AS102_ELGATO_EYETV_DTT_NAMEElgato EyeTV DTT Deluxe
#define ELGATO_EYETV_DTT_USB_VID0x0fd9
--
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] imon: don't parse scancodes until intf configured
On 20/07/11 23:18, Jarod Wilson wrote: On Wed, Jul 20, 2011 at 08:05:43AM +1000, Chris W wrote: On 20/07/11 02:12, Jarod Wilson wrote: The imon devices have either 1 or 2 usb interfaces on them, each wired up to its own urb callback. The interface 0 urb callback is wired up before the imon context's rc_dev pointer is filled in, which is necessary for imon 0xffdc device auto-detection to work properly, but we need to make sure we don't actually run the callback routines until we've entirely filled in the necessary bits for each given interface, lest we wind up oopsing. Technically, any imon device could have hit this, but the issue is exacerbated on the 0xffdc devices, which send a constant stream of interrupts, even when they have no valid key data. OK. The patch applies and everything continues to work. There is no obvious difference in the dmesg output on module load, with my device remaining unidentified. I don't know if that is indicative of anything. Did you apply this patch on top of the earlier patch, or instead of it? On top of it. I've reversed the patches and installed just the last one with this result on loading the module: input: iMON Panel, Knob and Mouse(15c2:ffdc) as /devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/input/input8 imon 4-2:1.0: 0xffdc iMON VFD, iMON IR (id 0x24) Registered IR keymap rc-imon-pad input: iMON Remote (15c2:ffdc) as /devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/rc/rc3/input9 rc3: iMON Remote (15c2:ffdc) as /devices/pci:00/:00:10.2/usb4/4-2/4-2:1.0/rc/rc3 imon 4-2:1.0: iMON device (15c2:ffdc, intf0) on usb4:3 initialized usbcore: registered new interface driver imon Much better. intf0 decoded packet: 00 00 00 00 00 00 24 01 intf0 decoded packet: 00 00 00 00 00 00 24 01 intf0 decoded packet: 00 00 00 00 00 00 24 01 One other amusing tidbit: you get continuous spew like the above, because to date, I thought all the ffdc devices had nothing to report spew that started with 0xff, which we filter out. Sigh. I hate imon hardware... I am beginning to understand why. That output was only printed with the debug=1 option and is not printed with the patched module. Regards, Chris -- Chris Williams Brisbane, Australia -- 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
