[PATCH 14/15] 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).
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.
GFP_ATOMIC allocations are performed from special pool which is created
early during boot. This way remapping page attributes is not needed on
allocation time.
CMA has been enabled unconditionally for ARMv6+ systems.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
Documentation/kernel-parameters.txt |4 +
arch/arm/Kconfig |2 +
arch/arm/include/asm/dma-contiguous.h | 16 ++
arch/arm/include/asm/mach/map.h |1 +
arch/arm/kernel/setup.c |9 +-
arch/arm/mm/dma-mapping.c | 368 +++--
arch/arm/mm/init.c| 22 ++-
arch/arm/mm/mm.h |3 +
arch/arm/mm/mmu.c | 31 ++-
9 files changed, 368 insertions(+), 88 deletions(-)
create mode 100644 arch/arm/include/asm/dma-contiguous.h
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 84982e2..ff97085 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -520,6 +520,10 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
a hypervisor.
Default: yes
+ coherent_pool=nn[KMG] [ARM,KNL]
+ Sets the size of memory pool for coherent, atomic dma
+ allocations if Contiguous Memory Allocator (CMA) is
used.
+
code_bytes [X86] How many bytes of object code to print
in an oops report.
Range: 0 - 8192
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 24626b0..8179981 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -4,6 +4,8 @@ config ARM
select HAVE_AOUT
select HAVE_DMA_API_DEBUG
select HAVE_IDE if PCI || ISA || PCMCIA
+ select HAVE_DMA_CONTIGUOUS if (CPU_V6 || CPU_V6K || CPU_V7)
+ select CMA if (CPU_V6 || CPU_V6K || CPU_V7)
select HAVE_MEMBLOCK
select RTC_LIB
select SYS_SUPPORTS_APM_EMULATION
diff --git a/arch/arm/include/asm/dma-contiguous.h
b/arch/arm/include/asm/dma-contiguous.h
new file mode 100644
index 000..c7ba05e
--- /dev/null
+++ b/arch/arm/include/asm/dma-contiguous.h
@@ -0,0 +1,16 @@
+#ifndef ASMARM_DMA_CONTIGUOUS_H
+#define ASMARM_DMA_CONTIGUOUS_H
+
+#ifdef __KERNEL__
+
+#include linux/device.h
+#include linux/dma-contiguous.h
+#include asm-generic/dma-contiguous.h
+
+#ifdef CONFIG_CMA
+
+void dma_contiguous_early_fixup(phys_addr_t base, unsigned long size);
+
+#endif
+#endif
+#endif
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index b36f365..a6efcdd 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -30,6 +30,7 @@ struct map_desc {
#define MT_MEMORY_DTCM 12
#define MT_MEMORY_ITCM 13
#define MT_MEMORY_SO 14
+#define MT_MEMORY_DMA_READY15
#ifdef CONFIG_MMU
extern void iotable_init(struct map_desc *, int);
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 129fbd5..ae9e86d 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -80,6 +80,7 @@ __setup(fpe=, fpe_setup);
extern void paging_init(struct machine_desc *desc);
extern void sanity_check_meminfo(void);
extern void reboot_setup(char *str);
+extern void setup_dma_zone(struct machine_desc *desc);
unsigned int processor_id;
EXPORT_SYMBOL(processor_id);
@@ -910,12 +911,8 @@ void __init setup_arch(char **cmdline_p)
machine_desc = mdesc;
machine_name = mdesc-name;
-#ifdef CONFIG_ZONE_DMA
- if (mdesc-dma_zone_size) {
- extern unsigned long arm_dma_zone_size;
- arm_dma_zone_size = mdesc-dma_zone_size;
- }
-#endif
+ setup_dma_zone(mdesc);
+
if (mdesc-restart_mode)
reboot_setup(mdesc-restart_mode);
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 1aa664a..77e7755 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -17,7 +17,9 @@
#include linux/init.h
#include linux/device.h
#include linux/dma-mapping.h
+#include linux/dma-contiguous.h
#include linux/highmem.h
+#include linux/memblock.h
#include linux/slab.h
#include asm/memory.h
@@ -26,6 +28,8 @@
#include asm/tlbflush.h
#include asm/sizes.h
#include asm/mach/arch.h
+#include asm/mach/map.h
+#include
[PATCH 13/15] X86: integrate CMA with DMA-mapping subsystem
This patch adds support for CMA to dma-mapping subsystem for x86
architecture that uses common pci-dma/pci-nommu implementation. This
allows to test CMA on KVM/QEMU and a lot of common x86 boxes.
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/x86/Kconfig |1 +
arch/x86/include/asm/dma-contiguous.h | 13 +
arch/x86/include/asm/dma-mapping.h|4
arch/x86/kernel/pci-dma.c | 18 --
arch/x86/kernel/pci-nommu.c |8 +---
arch/x86/kernel/setup.c |2 ++
6 files changed, 37 insertions(+), 9 deletions(-)
create mode 100644 arch/x86/include/asm/dma-contiguous.h
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 864cc6e..1e00736 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -31,6 +31,7 @@ config X86
select ARCH_WANT_OPTIONAL_GPIOLIB
select ARCH_WANT_FRAME_POINTERS
select HAVE_DMA_ATTRS
+ select HAVE_DMA_CONTIGUOUS if !SWIOTLB
select HAVE_KRETPROBES
select HAVE_OPTPROBES
select HAVE_FTRACE_MCOUNT_RECORD
diff --git a/arch/x86/include/asm/dma-contiguous.h
b/arch/x86/include/asm/dma-contiguous.h
new file mode 100644
index 000..8fb117d
--- /dev/null
+++ b/arch/x86/include/asm/dma-contiguous.h
@@ -0,0 +1,13 @@
+#ifndef ASMX86_DMA_CONTIGUOUS_H
+#define ASMX86_DMA_CONTIGUOUS_H
+
+#ifdef __KERNEL__
+
+#include linux/device.h
+#include linux/dma-contiguous.h
+#include asm-generic/dma-contiguous.h
+
+static inline void dma_contiguous_early_fixup(phys_addr_t base, unsigned long
size) { }
+
+#endif
+#endif
diff --git a/arch/x86/include/asm/dma-mapping.h
b/arch/x86/include/asm/dma-mapping.h
index ed3065f..90ac6f0 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -13,6 +13,7 @@
#include asm/io.h
#include asm/swiotlb.h
#include asm-generic/dma-coherent.h
+#include linux/dma-contiguous.h
#ifdef CONFIG_ISA
# define ISA_DMA_BIT_MASK DMA_BIT_MASK(24)
@@ -61,6 +62,9 @@ extern int dma_set_mask(struct device *dev, u64 mask);
extern void *dma_generic_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_addr, gfp_t flag);
+extern void dma_generic_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_addr);
+
static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t
size)
{
if (!dev-dma_mask)
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 1c4d769..d3c3723 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -99,14 +99,18 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t
size,
dma_addr_t *dma_addr, gfp_t flag)
{
unsigned long dma_mask;
- struct page *page;
+ struct page *page = NULL;
+ unsigned int count = PAGE_ALIGN(size) PAGE_SHIFT;
dma_addr_t addr;
dma_mask = dma_alloc_coherent_mask(dev, flag);
flag |= __GFP_ZERO;
again:
- page = alloc_pages_node(dev_to_node(dev), flag, get_order(size));
+ if (!(flag GFP_ATOMIC))
+ page = dma_alloc_from_contiguous(dev, count, get_order(size));
+ if (!page)
+ page = alloc_pages_node(dev_to_node(dev), flag,
get_order(size));
if (!page)
return NULL;
@@ -126,6 +130,16 @@ again:
return page_address(page);
}
+void dma_generic_free_coherent(struct device *dev, size_t size, void *vaddr,
+ dma_addr_t dma_addr)
+{
+ unsigned int count = PAGE_ALIGN(size) PAGE_SHIFT;
+ struct page *page = virt_to_page(vaddr);
+
+ if (!dma_release_from_contiguous(dev, page, count))
+ free_pages((unsigned long)vaddr, get_order(size));
+}
+
/*
* See Documentation/x86/x86_64/boot-options.txt for the iommu kernel
* parameter documentation.
diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c
index 3af4af8..656566f 100644
--- a/arch/x86/kernel/pci-nommu.c
+++ b/arch/x86/kernel/pci-nommu.c
@@ -74,12 +74,6 @@ static int nommu_map_sg(struct device *hwdev, struct
scatterlist *sg,
return nents;
}
-static void nommu_free_coherent(struct device *dev, size_t size, void *vaddr,
- dma_addr_t dma_addr)
-{
- free_pages((unsigned long)vaddr, get_order(size));
-}
-
static void nommu_sync_single_for_device(struct device *dev,
dma_addr_t addr, size_t size,
enum dma_data_direction dir)
@@ -97,7 +91,7 @@ static void nommu_sync_sg_for_device(struct device *dev,
struct dma_map_ops nommu_dma_ops = {
.alloc_coherent = dma_generic_alloc_coherent,
- .free_coherent = nommu_free_coherent,
+ .free_coherent =
[PATCH 08/15] mm: mmzone: MIGRATE_CMA migration type added
From: Michal Nazarewicz min...@mina86.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 (to some degree) 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 for allocating big chunks (eg. 10MiB)
of physically contiguous memory. Once driver requests
contiguous memory, pages from MIGRATE_CMA pageblocks may be
migrated away to create a contiguous block.
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 min...@mina86.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/mmzone.h | 43 +
include/linux/page-isolation.h |3 ++
mm/Kconfig |2 +-
mm/compaction.c| 11 +--
mm/page_alloc.c| 68 +---
mm/vmstat.c|3 ++
6 files changed, 107 insertions(+), 23 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 650ba2f..fcd4a14 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -35,13 +35,37 @@
*/
#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,
+#ifdef CONFIG_CMA
+ /*
+* 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,
+#endif
+ MIGRATE_ISOLATE,/* can't allocate from here */
+ MIGRATE_TYPES
+};
+
+#ifdef CONFIG_CMA
+# 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 +78,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 430cf61..454dd29 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -45,6 +45,9 @@ extern void unset_migratetype_isolate(struct page *page);
extern int alloc_contig_range(unsigned long start, unsigned long end);
extern void free_contig_range(unsigned long pfn, unsigned nr_pages);
+/* CMA stuff */
+extern void init_cma_reserved_pageblock(struct page *page);
+
#endif
#endif
diff --git a/mm/Kconfig b/mm/Kconfig
index e338407..3922002 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -198,7 +198,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
help
Allows the migration of the physical location of pages of processes
while the virtual addresses are not changed. This is useful in
diff --git a/mm/compaction.c b/mm/compaction.c
index 3e21d28..a075b43 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -35,6 +35,11 @@ static unsigned long release_freepages(struct list_head
*freelist)
return count;
}
+static inline bool migrate_async_suitable(int migratetype)
+{
+ return is_migrate_cma(migratetype) || migratetype == MIGRATE_MOVABLE;
+}
+
/*
* Isolate free pages onto a private freelist. Caller must hold
[PATCH 15/15] ARM: Samsung: use CMA for 2 memory banks for s5p-mfc device
Replace custom memory bank initialization using memblock_reserve and
dma_declare_coherent with a single call to CMA's dma_declare_contiguous.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/plat-s5p/dev-mfc.c | 51 ++-
1 files changed, 7 insertions(+), 44 deletions(-)
diff --git a/arch/arm/plat-s5p/dev-mfc.c b/arch/arm/plat-s5p/dev-mfc.c
index a30d36b..fcb8400 100644
--- a/arch/arm/plat-s5p/dev-mfc.c
+++ b/arch/arm/plat-s5p/dev-mfc.c
@@ -14,6 +14,7 @@
#include linux/interrupt.h
#include linux/platform_device.h
#include linux/dma-mapping.h
+#include linux/dma-contiguous.h
#include linux/memblock.h
#include linux/ioport.h
@@ -22,52 +23,14 @@
#include plat/irqs.h
#include plat/mfc.h
-struct s5p_mfc_reserved_mem {
- phys_addr_t base;
- unsigned long size;
- struct device *dev;
-};
-
-static struct s5p_mfc_reserved_mem s5p_mfc_mem[2] __initdata;
-
void __init s5p_mfc_reserve_mem(phys_addr_t rbase, unsigned int rsize,
phys_addr_t lbase, unsigned int lsize)
{
- int i;
-
- s5p_mfc_mem[0].dev = s5p_device_mfc_r.dev;
- s5p_mfc_mem[0].base = rbase;
- s5p_mfc_mem[0].size = rsize;
-
- s5p_mfc_mem[1].dev = s5p_device_mfc_l.dev;
- s5p_mfc_mem[1].base = lbase;
- s5p_mfc_mem[1].size = lsize;
-
- for (i = 0; i ARRAY_SIZE(s5p_mfc_mem); i++) {
- struct s5p_mfc_reserved_mem *area = s5p_mfc_mem[i];
- if (memblock_remove(area-base, area-size)) {
- printk(KERN_ERR Failed to reserve memory for MFC
device (%ld bytes at 0x%08lx)\n,
- area-size, (unsigned long) area-base);
- area-base = 0;
- }
- }
-}
-
-static int __init s5p_mfc_memory_init(void)
-{
- int i;
-
- for (i = 0; i ARRAY_SIZE(s5p_mfc_mem); i++) {
- struct s5p_mfc_reserved_mem *area = s5p_mfc_mem[i];
- if (!area-base)
- continue;
+ if (dma_declare_contiguous(s5p_device_mfc_r.dev, rsize, rbase, 0))
+ printk(KERN_ERR Failed to reserve memory for MFC device (%u
bytes at 0x%08lx)\n,
+ rsize, (unsigned long) rbase);
- if (dma_declare_coherent_memory(area-dev, area-base,
- area-base, area-size,
- DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE) == 0)
- printk(KERN_ERR Failed to declare coherent memory for
MFC device (%ld bytes at 0x%08lx)\n,
- area-size, (unsigned long) area-base);
- }
- return 0;
+ if (dma_declare_contiguous(s5p_device_mfc_l.dev, lsize, lbase, 0))
+ printk(KERN_ERR Failed to reserve memory for MFC device (%u
bytes at 0x%08lx)\n,
+ rsize, (unsigned long) rbase);
}
-device_initcall(s5p_mfc_memory_init);
--
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 12/15] 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
---
Documentation/kernel-parameters.txt |5 +
arch/Kconfig |3 +
drivers/base/Kconfig | 89
drivers/base/Makefile|1 +
drivers/base/dma-contiguous.c| 404 ++
include/asm-generic/dma-contiguous.h | 27 +++
include/linux/device.h |4 +
include/linux/dma-contiguous.h | 110 +
8 files changed, 643 insertions(+), 0 deletions(-)
create mode 100644 drivers/base/dma-contiguous.c
create mode 100644 include/asm-generic/dma-contiguous.h
create mode 100644 include/linux/dma-contiguous.h
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 033d4e6..84982e2 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -508,6 +508,11 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
Also note the kernel might malfunction if you disable
some critical bits.
+ cma=nn[MG] [ARM,KNL]
+ Sets the size of kernel global memory area for
contiguous
+ memory allocations. For more information, see
+ include/linux/dma-contiguous.h
+
cmo_free_hint= [PPC] Format: { yes | no }
Specify whether pages are marked as being inactive
when they are freed. This is used in CMO environments
diff --git a/arch/Kconfig b/arch/Kconfig
index 4f55c73..8ec200c 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -128,6 +128,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 7be9f79..f56cb20 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -189,4 +189,93 @@ config DMA_SHARED_BUFFER
APIs extension; the file's descriptor can then be passed on to other
driver.
+config CMA
+ bool Contiguous Memory Allocator (EXPERIMENTAL)
+ depends on HAVE_DMA_CONTIGUOUS HAVE_MEMBLOCK EXPERIMENTAL
+ select MIGRATION
+ 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 (DEVELOPMENT)
+ depends on DEBUG_KERNEL
+ 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_MBYTES
+ int Size in Mega Bytes
+ depends on !CMA_SIZE_SEL_PERCENTAGE
+ 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
+ depends on !CMA_SIZE_SEL_MBYTES
+ 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_MBYTES
+ bool Use mega bytes 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
[PATCH 10/15] mm: extract reclaim code from __alloc_pages_direct_reclaim()
This patch extracts common reclaim code from __alloc_pages_direct_reclaim()
function to separate function: __perform_reclaim() which can be later used
by alloc_contig_range().
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
mm/page_alloc.c | 30 +-
1 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 4e60c0b..e35d06b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2094,16 +2094,13 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned
int order,
}
#endif /* CONFIG_COMPACTION */
-/* The really slow allocator path where we enter direct reclaim */
-static inline struct page *
-__alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order,
- struct zonelist *zonelist, enum zone_type high_zoneidx,
- nodemask_t *nodemask, int alloc_flags, struct zone *preferred_zone,
- int migratetype, unsigned long *did_some_progress)
+/* Perform direct synchronous page reclaim */
+static inline int
+__perform_reclaim(gfp_t gfp_mask, unsigned int order, struct zonelist
*zonelist,
+ nodemask_t *nodemask)
{
- struct page *page = NULL;
struct reclaim_state reclaim_state;
- bool drained = false;
+ int progress;
cond_resched();
@@ -2114,7 +2111,7 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int
order,
reclaim_state.reclaimed_slab = 0;
current-reclaim_state = reclaim_state;
- *did_some_progress = try_to_free_pages(zonelist, order, gfp_mask,
nodemask);
+ progress = try_to_free_pages(zonelist, order, gfp_mask, nodemask);
current-reclaim_state = NULL;
lockdep_clear_current_reclaim_state();
@@ -2122,6 +2119,21 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned
int order,
cond_resched();
+ return progress;
+}
+
+/* The really slow allocator path where we enter direct reclaim */
+static inline struct page *
+__alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order,
+ struct zonelist *zonelist, enum zone_type high_zoneidx,
+ nodemask_t *nodemask, int alloc_flags, struct zone *preferred_zone,
+ int migratetype, unsigned long *did_some_progress)
+{
+ struct page *page = NULL;
+ bool drained = false;
+
+ *did_some_progress = __perform_reclaim(gfp_mask, order, zonelist,
+ nodemask);
if (unlikely(!(*did_some_progress)))
return NULL;
--
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 07/15] mm: page_alloc: change fallbacks array handling
From: Michal Nazarewicz min...@mina86.com
This commit adds a row for MIGRATE_ISOLATE type to the fallbacks array
which was missing from it. It also, changes the array traversal logic
a little making MIGRATE_RESERVE an end marker. The letter change,
removes the implicit MIGRATE_UNMOVABLE from the end of each row which
was read by __rmqueue_fallback() function.
Signed-off-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
mm/page_alloc.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index b4f50532..0a9cc8e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -875,11 +875,12 @@ struct page *__rmqueue_smallest(struct zone *zone,
unsigned int order,
* This array describes the order lists are fallen back to when
* the free lists for the desirable migrate type are depleted
*/
-static int fallbacks[MIGRATE_TYPES][MIGRATE_TYPES-1] = {
+static int fallbacks[MIGRATE_TYPES][3] = {
[MIGRATE_UNMOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE,
MIGRATE_RESERVE },
[MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE, MIGRATE_MOVABLE,
MIGRATE_RESERVE },
[MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE,
MIGRATE_RESERVE },
- [MIGRATE_RESERVE] = { MIGRATE_RESERVE, MIGRATE_RESERVE,
MIGRATE_RESERVE }, /* Never used */
+ [MIGRATE_RESERVE] = { MIGRATE_RESERVE }, /* Never used */
+ [MIGRATE_ISOLATE] = { MIGRATE_RESERVE }, /* Never used */
};
/*
@@ -974,12 +975,12 @@ __rmqueue_fallback(struct zone *zone, int order, int
start_migratetype)
/* Find the largest possible block of pages in the other list */
for (current_order = MAX_ORDER-1; current_order = order;
--current_order) {
- for (i = 0; i MIGRATE_TYPES - 1; i++) {
+ for (i = 0;; i++) {
migratetype = fallbacks[start_migratetype][i];
/* MIGRATE_RESERVE handled later if necessary */
if (migratetype == MIGRATE_RESERVE)
- continue;
+ break;
area = (zone-free_area[current_order]);
if (list_empty(area-free_list[migratetype]))
--
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 04/15] mm: compaction: introduce isolate_freepages_range()
From: Michal Nazarewicz min...@mina86.com
This commit introduces isolate_freepages_range() function which
generalises isolate_freepages_block() so that it can be used on
arbitrary PFN ranges.
isolate_freepages_block() is left with only minor changes.
Signed-off-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
mm/compaction.c | 118 ++
1 files changed, 100 insertions(+), 18 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index a42bbdd..63f82be 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -54,24 +54,20 @@ static unsigned long release_freepages(struct list_head
*freelist)
return count;
}
-/* Isolate free pages onto a private freelist. Must hold zone-lock */
-static unsigned long isolate_freepages_block(struct zone *zone,
- unsigned long blockpfn,
- struct list_head *freelist)
+/*
+ * Isolate free pages onto a private freelist. Caller must hold zone-lock.
+ * If @strict is true, will abort returning 0 on any invalid PFNs or non-free
+ * pages inside of the pageblock (even though it may still end up isolating
+ * some pages).
+ */
+static unsigned long isolate_freepages_block(unsigned long blockpfn,
+ unsigned long end_pfn,
+ struct list_head *freelist,
+ bool strict)
{
- unsigned long zone_end_pfn, end_pfn;
int nr_scanned = 0, total_isolated = 0;
struct page *cursor;
- /* Get the last PFN we should scan for free pages at */
- zone_end_pfn = zone-zone_start_pfn + zone-spanned_pages;
- end_pfn = min(blockpfn + pageblock_nr_pages, zone_end_pfn);
-
- /* Find the first usable PFN in the block to initialse page cursor */
- for (; blockpfn end_pfn; blockpfn++) {
- if (pfn_valid_within(blockpfn))
- break;
- }
cursor = pfn_to_page(blockpfn);
/* Isolate free pages. This assumes the block is valid */
@@ -79,15 +75,23 @@ static unsigned long isolate_freepages_block(struct zone
*zone,
int isolated, i;
struct page *page = cursor;
- if (!pfn_valid_within(blockpfn))
+ if (!pfn_valid_within(blockpfn)) {
+ if (strict)
+ return 0;
continue;
+ }
nr_scanned++;
- if (!PageBuddy(page))
+ if (!PageBuddy(page)) {
+ if (strict)
+ return 0;
continue;
+ }
/* Found a free page, break it into order-0 pages */
isolated = split_free_page(page);
+ if (!isolated strict)
+ return 0;
total_isolated += isolated;
for (i = 0; i isolated; i++) {
list_add(page-lru, freelist);
@@ -105,6 +109,80 @@ static unsigned long isolate_freepages_block(struct zone
*zone,
return total_isolated;
}
+/**
+ * isolate_freepages_range() - isolate free pages.
+ * @start_pfn: The first PFN to start isolating.
+ * @end_pfn: The one-past-last PFN.
+ *
+ * Non-free pages, invalid PFNs, or zone boundaries within the
+ * [start_pfn, end_pfn) range are considered errors, cause function to
+ * undo its actions and return zero.
+ *
+ * Otherwise, function returns one-past-the-last PFN of isolated page
+ * (which may be greater then end_pfn if end fell in a middle of
+ * a free page).
+ */
+static unsigned long
+isolate_freepages_range(unsigned long start_pfn, unsigned long end_pfn)
+{
+ unsigned long isolated, pfn, block_end_pfn, flags;
+ struct zone *zone = NULL;
+ LIST_HEAD(freelist);
+ struct page *page;
+
+ for (pfn = start_pfn; pfn end_pfn; pfn += isolated) {
+ if (!pfn_valid(pfn))
+ break;
+
+ if (!zone)
+ zone = page_zone(pfn_to_page(pfn));
+ else if (zone != page_zone(pfn_to_page(pfn)))
+ break;
+
+ /*
+* On subsequent iterations round_down() is actually not
+* needed, but we keep it that we not to complicate the code.
+*/
+ block_end_pfn = round_down(pfn, pageblock_nr_pages)
+ + pageblock_nr_pages;
+ block_end_pfn = min(block_end_pfn, end_pfn);
+
+ spin_lock_irqsave(zone-lock, flags);
+ isolated = isolate_freepages_block(pfn, block_end_pfn,
+ freelist, true);
+ spin_unlock_irqrestore(zone-lock, flags);
+
+ /*
+* In strict mode, isolate_freepages_block() returns 0 if
+
[PATCH 11/15] mm: trigger page reclaim in alloc_contig_range() to stabilize watermarks
alloc_contig_range() performs memory allocation so it also should keep
track on keeping the correct level of memory watermarks. This commit adds
a call to *_slowpath style reclaim to grab enough pages to make sure that
the final collection of contiguous pages from freelists will not starve
the system.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
mm/page_alloc.c | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e35d06b..05eaa82 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5613,6 +5613,34 @@ static int __alloc_contig_migrate_range(unsigned long
start, unsigned long end)
return ret;
}
+/*
+ * Trigger memory pressure bump to reclaim some pages in order to be able to
+ * allocate 'count' pages in single page units. Does similar work as
+ *__alloc_pages_slowpath() function.
+ */
+static int __reclaim_pages(struct zone *zone, gfp_t gfp_mask, int count)
+{
+ enum zone_type high_zoneidx = gfp_zone(gfp_mask);
+ struct zonelist *zonelist = node_zonelist(0, gfp_mask);
+ int did_some_progress = 0;
+ int order = 1;
+ unsigned long watermark;
+
+ /* Obey watermarks as if the page was being allocated */
+ watermark = low_wmark_pages(zone) + count;
+ while (!zone_watermark_ok(zone, 0, watermark, 0, 0)) {
+ wake_all_kswapd(order, zonelist, high_zoneidx, zone_idx(zone));
+
+ did_some_progress = __perform_reclaim(gfp_mask, order, zonelist,
+ NULL);
+ if (!did_some_progress) {
+ /* Exhausted what can be done so it's blamo time */
+ out_of_memory(zonelist, gfp_mask, order, NULL);
+ }
+ }
+ return count;
+}
+
/**
* alloc_contig_range() -- tries to allocate given range of pages
* @start: start PFN to allocate
@@ -5707,6 +5735,14 @@ int alloc_contig_range(unsigned long start, unsigned
long end,
goto done;
}
+ /*
+* Reclaim enough pages to make sure that contiguous allocation
+* will not starve the system.
+*/
+ __reclaim_pages(page_zone(pfn_to_page(outer_start)),
+ GFP_HIGHUSER_MOVABLE, end-start);
+
+ /* Grab isolated pages from freelists. */
outer_end = isolate_freepages_range(outer_start, end);
if (!outer_end) {
ret = -EBUSY;
--
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 05/15] mm: compaction: export some of the functions
From: Michal Nazarewicz min...@mina86.com
This commit exports some of the functions from compaction.c file
outside of it adding their declaration into internal.h header
file so that other mm related code can use them.
This forced compaction.c to always be compiled (as opposed to being
compiled only if CONFIG_COMPACTION is defined) but as to avoid
introducing code that user did not ask for, part of the compaction.c
is now wrapped in on #ifdef.
Signed-off-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
mm/Makefile |3 +-
mm/compaction.c | 314 ++-
mm/internal.h | 33 ++
3 files changed, 184 insertions(+), 166 deletions(-)
diff --git a/mm/Makefile b/mm/Makefile
index 50ec00e..8aada89 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -13,7 +13,7 @@ obj-y := filemap.o mempool.o oom_kill.o
fadvise.o \
readahead.o swap.o truncate.o vmscan.o shmem.o \
prio_tree.o util.o mmzone.o vmstat.o backing-dev.o \
page_isolation.o mm_init.o mmu_context.o percpu.o \
- $(mmu-y)
+ compaction.o $(mmu-y)
obj-y += init-mm.o
ifdef CONFIG_NO_BOOTMEM
@@ -32,7 +32,6 @@ obj-$(CONFIG_NUMA)+= mempolicy.o
obj-$(CONFIG_SPARSEMEM)+= sparse.o
obj-$(CONFIG_SPARSEMEM_VMEMMAP) += sparse-vmemmap.o
obj-$(CONFIG_SLOB) += slob.o
-obj-$(CONFIG_COMPACTION) += compaction.o
obj-$(CONFIG_MMU_NOTIFIER) += mmu_notifier.o
obj-$(CONFIG_KSM) += ksm.o
obj-$(CONFIG_PAGE_POISONING) += debug-pagealloc.o
diff --git a/mm/compaction.c b/mm/compaction.c
index 63f82be..3e21d28 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -16,30 +16,11 @@
#include linux/sysfs.h
#include internal.h
+#if defined CONFIG_COMPACTION || defined CONFIG_CMA
+
#define CREATE_TRACE_POINTS
#include trace/events/compaction.h
-/*
- * compact_control is used to track pages being migrated and the free pages
- * they are being migrated to during memory compaction. The free_pfn starts
- * at the end of a zone and migrate_pfn begins at the start. Movable pages
- * are moved to the end of a zone during a compaction run and the run
- * completes when free_pfn = migrate_pfn
- */
-struct compact_control {
- struct list_head freepages; /* List of free pages to migrate to */
- struct list_head migratepages; /* List of pages being migrated */
- unsigned long nr_freepages; /* Number of isolated free pages */
- unsigned long nr_migratepages; /* Number of pages to migrate */
- unsigned long free_pfn; /* isolate_freepages search base */
- unsigned long migrate_pfn; /* isolate_migratepages search base */
- bool sync; /* Synchronous migration */
-
- unsigned int order; /* order a direct compactor needs */
- int migratetype;/* MOVABLE, RECLAIMABLE etc */
- struct zone *zone;
-};
-
static unsigned long release_freepages(struct list_head *freelist)
{
struct page *page, *next;
@@ -122,7 +103,7 @@ static unsigned long isolate_freepages_block(unsigned long
blockpfn,
* (which may be greater then end_pfn if end fell in a middle of
* a free page).
*/
-static unsigned long
+unsigned long
isolate_freepages_range(unsigned long start_pfn, unsigned long end_pfn)
{
unsigned long isolated, pfn, block_end_pfn, flags;
@@ -183,120 +164,6 @@ isolate_freepages_range(unsigned long start_pfn, unsigned
long end_pfn)
return pfn;
}
-/* Returns true if the page is within a block suitable for migration to */
-static bool suitable_migration_target(struct page *page)
-{
-
- int migratetype = get_pageblock_migratetype(page);
-
- /* Don't interfere with memory hot-remove or the min_free_kbytes blocks
*/
- if (migratetype == MIGRATE_ISOLATE || migratetype == MIGRATE_RESERVE)
- return false;
-
- /* If the page is a large free page, then allow migration */
- if (PageBuddy(page) page_order(page) = pageblock_order)
- return true;
-
- /* If the block is MIGRATE_MOVABLE, allow migration */
- if (migratetype == MIGRATE_MOVABLE)
- return true;
-
- /* Otherwise skip the block */
- return false;
-}
-
-/*
- * Based on information in the current compact_control, find blocks
- * suitable for isolating free pages from and then isolate them.
- */
-static void isolate_freepages(struct zone *zone,
- struct compact_control *cc)
-{
- struct page *page;
- unsigned long high_pfn, low_pfn, pfn, zone_end_pfn, end_pfn;
- unsigned long flags;
- int nr_freepages = cc-nr_freepages;
- struct list_head *freelist = cc-freepages;
-
- /*
-* Initialise the free scanner. The starting point is where we last
-* scanned from (or the
[PATCH 01/15] mm: page_alloc: remove trailing whitespace
From: Michal Nazarewicz min...@mina86.com
Signed-off-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
mm/page_alloc.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 0027d8f..e1c5656 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -513,10 +513,10 @@ static inline int page_is_buddy(struct page *page, struct
page *buddy,
* free pages of length of (1 order) and marked with _mapcount -2. Page's
* order is recorded in page_private(page) field.
* So when we are allocating or freeing one, we can derive the state of the
- * other. That is, if we allocate a small block, and both were
- * free, the remainder of the region must be split into blocks.
+ * other. That is, if we allocate a small block, and both were
+ * free, the remainder of the region must be split into blocks.
* If a block is freed, and its buddy is also free, then this
- * triggers coalescing into a block of larger size.
+ * triggers coalescing into a block of larger size.
*
* -- wli
*/
@@ -1061,17 +1061,17 @@ retry_reserve:
return page;
}
-/*
+/*
* Obtain a specified number of elements from the buddy allocator, all under
* a single hold of the lock, for efficiency. Add them to the supplied list.
* Returns the number of new pages which were placed at *list.
*/
-static int rmqueue_bulk(struct zone *zone, unsigned int order,
+static int rmqueue_bulk(struct zone *zone, unsigned int order,
unsigned long count, struct list_head *list,
int migratetype, int cold)
{
int i;
-
+
spin_lock(zone-lock);
for (i = 0; i count; ++i) {
struct page *page = __rmqueue(zone, order, migratetype);
@@ -4258,7 +4258,7 @@ static void __paginginit free_area_init_core(struct
pglist_data *pgdat,
init_waitqueue_head(pgdat-kswapd_wait);
pgdat-kswapd_max_order = 0;
pgdat_page_cgroup_init(pgdat);
-
+
for (j = 0; j MAX_NR_ZONES; j++) {
struct zone *zone = pgdat-node_zones + j;
unsigned long size, realsize, memmap_pages;
@@ -5081,11 +5081,11 @@ int __meminit init_per_zone_wmark_min(void)
module_init(init_per_zone_wmark_min)
/*
- * min_free_kbytes_sysctl_handler - just a wrapper around proc_dointvec() so
+ * min_free_kbytes_sysctl_handler - just a wrapper around proc_dointvec() so
* that we can call two helper functions whenever min_free_kbytes
* changes.
*/
-int min_free_kbytes_sysctl_handler(ctl_table *table, int write,
+int min_free_kbytes_sysctl_handler(ctl_table *table, int write,
void __user *buffer, size_t *length, loff_t *ppos)
{
proc_dointvec(table, write, buffer, length, ppos);
--
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 09/15] mm: page_isolation: MIGRATE_CMA isolation functions added
From: Michal Nazarewicz min...@mina86.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 min...@mina86.com Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- include/linux/page-isolation.h | 21 +++-- mm/memory-failure.c|2 +- mm/memory_hotplug.c|6 +++--- mm/page_alloc.c| 18 -- mm/page_isolation.c| 15 --- 5 files changed, 35 insertions(+), 27 deletions(-) diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h index 454dd29..0659713 100644 --- a/include/linux/page-isolation.h +++ b/include/linux/page-isolation.h @@ -3,7 +3,7 @@ /* * 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 @@ -11,20 +11,21 @@ * test it. */ extern int -start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn); +start_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); +undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn, + unsigned migratetype); /* - * 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); /* * Check all pages in pageblock, find the ones on pcp list, and set @@ -33,16 +34,16 @@ test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn); extern void update_pcp_isolate_block(unsigned long 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); +extern void unset_migratetype_isolate(struct page *page, unsigned migratetype); #ifdef CONFIG_CMA /* The below functions must be run on a range from a single zone. */ -extern int alloc_contig_range(unsigned long start, unsigned long end); +extern int alloc_contig_range(unsigned long start, unsigned long end, + unsigned migratetype); extern void free_contig_range(unsigned long pfn, unsigned nr_pages); /* CMA stuff */ diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 56080ea..76b01bf 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -1400,7 +1400,7 @@ static int get_any_page(struct page *p, unsigned long pfn, int flags) /* Not a free page */ ret = 1; } - unset_migratetype_isolate(p); + unset_migratetype_isolate(p, MIGRATE_MOVABLE); unlock_memory_hotplug(); return ret; } diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 6629faf..fc898cb 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -891,7 +891,7 @@ static int __ref offline_pages(unsigned long start_pfn, nr_pages = end_pfn - start_pfn; /* set above range as isolated */ - ret = start_isolate_page_range(start_pfn, end_pfn); + ret = start_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE); if (ret) goto out; @@ -956,7 +956,7 @@ repeat: We cannot do rollback at this point. */ offline_isolated_pages(start_pfn, end_pfn); /* reset pagetype flags and makes migrate type to be MOVABLE */ - undo_isolate_page_range(start_pfn, end_pfn); + undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE); /* removal success */ zone-present_pages -= offlined_pages; zone-zone_pgdat-node_present_pages -= offlined_pages; @@ -981,7 +981,7 @@ failed_removal: start_pfn, end_pfn); memory_notify(MEM_CANCEL_OFFLINE, arg); /* pushback to free area */ - undo_isolate_page_range(start_pfn, end_pfn); + undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE); out: unlock_memory_hotplug(); diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 0fcde78..4e60c0b 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5520,7 +5520,7 @@ out: return ret; } -void unset_migratetype_isolate(struct page *page) +void unset_migratetype_isolate(struct page
Re: 290e locking issue
On 01/26/2012 12:16 AM, Claus Olesen wrote: just got 3.2.1-3.fc16.i686.PAE the issue that the driver had to be removed for the 290e to work after a replug is gone. the issue that a usb mem stick cannot be mounted while the 290e is plugged in still lingers. one workaround is to unplug the 290e and wait a little (no need to also remove the driver). What it prints to the system log? Use tail -f /var/log/messages or dmesg. 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
[PATCH 03/15] mm: compaction: introduce isolate_migratepages_range().
From: Michal Nazarewicz min...@mina86.com
This commit introduces isolate_migratepages_range() function which
extracts functionality from isolate_migratepages() so that it can be
used on arbitrary PFN ranges.
isolate_migratepages() function is implemented as a simple wrapper
around isolate_migratepages_range().
Signed-off-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
mm/compaction.c | 77 +++---
1 files changed, 55 insertions(+), 22 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 71a58f6..a42bbdd 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -250,31 +250,34 @@ typedef enum {
ISOLATE_SUCCESS,/* Pages isolated, migrate */
} isolate_migrate_t;
-/*
- * Isolate all pages that can be migrated from the block pointed to by
- * the migrate scanner within compact_control.
+/**
+ * isolate_migratepages_range() - isolate all migrate-able pages in range.
+ * @zone: Zone pages are in.
+ * @cc:Compaction control structure.
+ * @low_pfn: The first PFN of the range.
+ * @end_pfn: The one-past-the-last PFN of the range.
+ *
+ * Isolate all pages that can be migrated from the range specified by
+ * [low_pfn, end_pfn). Returns zero if there is a fatal signal
+ * pending), otherwise PFN of the first page that was not scanned
+ * (which may be both less, equal to or more then end_pfn).
+ *
+ * Assumes that cc-migratepages is empty and cc-nr_migratepages is
+ * zero.
+ *
+ * Apart from cc-migratepages and cc-nr_migratetypes this function
+ * does not modify any cc's fields, in particular it does not modify
+ * (or read for that matter) cc-migrate_pfn.
*/
-static isolate_migrate_t isolate_migratepages(struct zone *zone,
- struct compact_control *cc)
+static unsigned long
+isolate_migratepages_range(struct zone *zone, struct compact_control *cc,
+ unsigned long low_pfn, unsigned long end_pfn)
{
- unsigned long low_pfn, end_pfn;
unsigned long last_pageblock_nr = 0, pageblock_nr;
unsigned long nr_scanned = 0, nr_isolated = 0;
struct list_head *migratelist = cc-migratepages;
isolate_mode_t mode = ISOLATE_ACTIVE|ISOLATE_INACTIVE;
- /* Do not scan outside zone boundaries */
- low_pfn = max(cc-migrate_pfn, zone-zone_start_pfn);
-
- /* Only scan within a pageblock boundary */
- end_pfn = ALIGN(low_pfn + pageblock_nr_pages, pageblock_nr_pages);
-
- /* Do not cross the free scanner or scan within a memory hole */
- if (end_pfn cc-free_pfn || !pfn_valid(low_pfn)) {
- cc-migrate_pfn = end_pfn;
- return ISOLATE_NONE;
- }
-
/*
* Ensure that there are not too many pages isolated from the LRU
* list by either parallel reclaimers or compaction. If there are,
@@ -283,12 +286,12 @@ static isolate_migrate_t isolate_migratepages(struct zone
*zone,
while (unlikely(too_many_isolated(zone))) {
/* async migration should just abort */
if (!cc-sync)
- return ISOLATE_ABORT;
+ return 0;
congestion_wait(BLK_RW_ASYNC, HZ/10);
if (fatal_signal_pending(current))
- return ISOLATE_ABORT;
+ return 0;
}
/* Time to isolate some pages for migration */
@@ -313,7 +316,7 @@ static isolate_migrate_t isolate_migratepages(struct zone
*zone,
} else if (!locked)
spin_lock_irq(zone-lru_lock);
- if (!pfn_valid_within(low_pfn))
+ if (!pfn_valid(low_pfn))
continue;
nr_scanned++;
@@ -374,10 +377,40 @@ static isolate_migrate_t isolate_migratepages(struct zone
*zone,
acct_isolated(zone, cc);
spin_unlock_irq(zone-lru_lock);
- cc-migrate_pfn = low_pfn;
trace_mm_compaction_isolate_migratepages(nr_scanned, nr_isolated);
+ return low_pfn;
+}
+
+/*
+ * Isolate all pages that can be migrated from the block pointed to by
+ * the migrate scanner within compact_control.
+ */
+static isolate_migrate_t isolate_migratepages(struct zone *zone,
+ struct compact_control *cc)
+{
+ unsigned long low_pfn, end_pfn;
+
+ /* Do not scan outside zone boundaries */
+ low_pfn = max(cc-migrate_pfn, zone-zone_start_pfn);
+
+ /* Only scan within a pageblock boundary */
+ end_pfn = ALIGN(low_pfn + pageblock_nr_pages, pageblock_nr_pages);
+
+ /* Do not cross the free scanner or scan within a memory hole */
+ if (end_pfn cc-free_pfn || !pfn_valid(low_pfn)) {
+ cc-migrate_pfn = end_pfn;
+ return ISOLATE_NONE;
+ }
+
+ /* Perform the isolation */
+ low_pfn =
[PATCH 02/15] mm: page_alloc: update migrate type of pages on pcp when isolating
From: Michal Nazarewicz min...@mina86.com
This commit changes set_migratetype_isolate() so that it updates
migrate type of pages on pcp list which is saved in their
page_private.
Signed-off-by: Michal Nazarewicz min...@mina86.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
include/linux/page-isolation.h |6 ++
mm/page_alloc.c|1 +
mm/page_isolation.c| 24
3 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 051c1b1..8c02c2b 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -27,6 +27,12 @@ extern int
test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn);
/*
+ * Check all pages in pageblock, find the ones on pcp list, and set
+ * their page_private to MIGRATE_ISOLATE.
+ */
+extern void update_pcp_isolate_block(unsigned long pfn);
+
+/*
* Internal funcs.Changes pageblock's migrate type.
* Please use make_pagetype_isolated()/make_pagetype_movable().
*/
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index e1c5656..70709e7 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5465,6 +5465,7 @@ out:
if (!ret) {
set_pageblock_migratetype(page, MIGRATE_ISOLATE);
move_freepages_block(zone, page, MIGRATE_ISOLATE);
+ update_pcp_isolate_block(pfn);
}
spin_unlock_irqrestore(zone-lock, flags);
diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index 4ae42bb..9ea2f6e 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -139,3 +139,27 @@ int test_pages_isolated(unsigned long start_pfn, unsigned
long end_pfn)
spin_unlock_irqrestore(zone-lock, flags);
return ret ? 0 : -EBUSY;
}
+
+/* must hold zone-lock */
+void update_pcp_isolate_block(unsigned long pfn)
+{
+ unsigned long end_pfn = pfn + pageblock_nr_pages;
+ struct page *page;
+
+ while (pfn end_pfn) {
+ if (!pfn_valid_within(pfn)) {
+ ++pfn;
+ continue;
+ }
+
+ page = pfn_to_page(pfn);
+ if (PageBuddy(page)) {
+ pfn += 1 page_order(page);
+ } else if (page_count(page) == 0) {
+ set_page_private(page, MIGRATE_ISOLATE);
+ ++pfn;
+ } else {
+ ++pfn;
+ }
+ }
+}
--
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
[PATCHv19 00/15] Contiguous Memory Allocator
Welcome everyone! Yes, that's true. This is yet another release of the Contiguous Memory Allocator patches. This version mainly includes code cleanups requested by Mel Gorman and a few minor bug fixes. ARM integration code has not been changed since v16. It provides implementation of the ideas that has been discussed during Linaro Sprint meeting in Cambourne, August 2011. Here are the details: This version provides a solution for complete integration of CMA to DMA mapping subsystem on ARM architecture. The issue caused by double dma pages mapping and possible aliasing in coherent memory mapping has been finally resolved, both for GFP_ATOMIC case (allocations comes from coherent memory pool) and non-GFP_ATOMIC case (allocations comes from CMA managed areas). For coherent, nommu, ARMv4 and ARMv5 systems the current DMA-mapping implementation has been kept. For ARMv6+ systems, CMA has been enabled and a special pool of coherent memory for atomic allocations has been created. The size of this pool defaults to DEFAULT_CONSISTEN_DMA_SIZE/8, but can be changed with coherent_pool kernel parameter (if really required). All atomic allocations are served from this pool. I've did a little simplification here, because there is no separate pool for writecombine memory - such requests are also served from coherent pool. I don't think that such simplification is a problem here - I found no driver that use dma_alloc_writecombine with GFP_ATOMIC flags. All non-atomic allocation are served from CMA area. Kernel mappings are updated to reflect required memory attributes changes. This is possible because during early boot, all CMA area are remapped with 4KiB pages in kernel low-memory. This version have been tested on Samsung S5PC110 based Goni machine and Exynos4 UniversalC210 board with various V4L2 multimedia drivers. Coherent atomic allocations has been tested by manually enabling the dma bounce for the s3c-sdhci device. All patches are prepared for Linux Kernel v3.3-rc1. 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. Since version v17 Michal is working again on CMA patches and the current version is the result of our joint open-source effort. TODO (optional): - implement support for contiguous memory areas placed in HIGHMEM zone - resolve issue with movable pages with pending io operations Best regards Marek Szyprowski Samsung Poland RD Center Links to previous versions of the patchset: v18: http://www.spinics.net/lists/linux-mm/msg28125.html v17: http://www.spinics.net/lists/arm-kernel/msg148499.html v16: http://www.spinics.net/lists/linux-mm/msg25066.html v15: http://www.spinics.net/lists/linux-mm/msg23365.html v14: http://www.spinics.net/lists/linux-media/msg36536.html v13: (internal, intentionally not released) v12: http://www.spinics.net/lists/linux-media/msg35674.html 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: v19: 1. Addressed another set of comments and suggestions from Mel Gorman, mainly related to breaking patches into smaller, single-feature related chunks and rewriting already existing functions in memory compaction code. 2. Reworked completely page reclaim code, removed it from split_free_page() and introduce direct call from alloc_contig_range(). 3. Merged a fix from Mans Rullgard for correct cma area limit alignment. 4. Replaced broken mm: page_alloc: set_migratetype_isolate:
[PATCH 06/15] mm: page_alloc: introduce alloc_contig_range()
From: Michal Nazarewicz min...@mina86.com
This commit adds the alloc_contig_range() function which tries
to allocate 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 min...@mina86.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
include/linux/page-isolation.h |7 ++
mm/page_alloc.c| 183
2 files changed, 190 insertions(+), 0 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 8c02c2b..430cf61 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -39,5 +39,12 @@ extern void update_pcp_isolate_block(unsigned long pfn);
extern int set_migratetype_isolate(struct page *page);
extern void unset_migratetype_isolate(struct page *page);
+#ifdef CONFIG_CMA
+
+/* The below functions must be run on a range from a single zone. */
+extern int alloc_contig_range(unsigned long start, unsigned long end);
+extern void free_contig_range(unsigned long pfn, unsigned nr_pages);
+
+#endif
#endif
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 70709e7..b4f50532 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -57,6 +57,7 @@
#include linux/ftrace_event.h
#include linux/memcontrol.h
#include linux/prefetch.h
+#include linux/migrate.h
#include linux/page-debug-flags.h
#include asm/tlbflush.h
@@ -5488,6 +5489,188 @@ out:
spin_unlock_irqrestore(zone-lock, flags);
}
+#ifdef CONFIG_CMA
+
+static unsigned long pfn_align_to_maxpage_down(unsigned long pfn)
+{
+ return pfn ~(MAX_ORDER_NR_PAGES - 1);
+}
+
+static unsigned long pfn_align_to_maxpage_up(unsigned long pfn)
+{
+ return ALIGN(pfn, MAX_ORDER_NR_PAGES);
+}
+
+static struct page *
+__alloc_contig_migrate_alloc(struct page *page, unsigned long private,
+int **resultp)
+{
+ return alloc_page(GFP_HIGHUSER_MOVABLE);
+}
+
+/* [start, end) must belong to a single zone. */
+static int __alloc_contig_migrate_range(unsigned long start, unsigned long end)
+{
+ /* This function is based on compact_zone() from compaction.c. */
+
+ unsigned long pfn = start;
+ unsigned int tries = 0;
+ int ret = 0;
+
+ struct compact_control cc = {
+ .nr_migratepages = 0,
+ .order = -1,
+ .zone = page_zone(pfn_to_page(start)),
+ .sync = true,
+ };
+ INIT_LIST_HEAD(cc.migratepages);
+
+ migrate_prep_local();
+
+ while (pfn end || !list_empty(cc.migratepages)) {
+ if (fatal_signal_pending(current)) {
+ ret = -EINTR;
+ break;
+ }
+
+ if (list_empty(cc.migratepages)) {
+ cc.nr_migratepages = 0;
+ pfn = isolate_migratepages_range(cc.zone, cc,
+pfn, end);
+ if (!pfn) {
+ ret = -EINTR;
+ break;
+ }
+ tries = 0;
+ } else if (++tries == 5) {
+ ret = ret 0 ? ret : -EBUSY;
+ break;
+ }
+
+ ret = migrate_pages(cc.migratepages,
+ __alloc_contig_migrate_alloc,
+ 0, false, true);
+ }
+
+ putback_lru_pages(cc.migratepages);
+ return ret;
+}
+
+/**
+ * alloc_contig_range() -- tries to allocate given range of pages
+ * @start: start PFN to allocate
+ * @end: one-past-the-last PFN to allocate
+ *
+ * The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
+ * aligned, however it's the caller's responsibility to guarantee that
+ * we are the only thread that changes migrate type of pageblocks the
+ * pages fall in.
+ *
+ * The PFN range must belong to a single zone.
+ *
+ * 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_range().
+ */
+int alloc_contig_range(unsigned long start, unsigned long end)
+{
+ unsigned long outer_start, outer_end;
+ int ret = 0, order;
+
+ /*
+* 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
+
Re: [PATCH 05/10] v4l: add buffer exporting via dmabuf
Hi Everyone,
I would like to present a simple test application used for testing
DMABUF support in V4L2. It is used to show how support for DMABUF may
look like in V4L2.
The test application creates a simple pipeline between two V4L2 devices.
One of them is a capture device. The second one is an output device.
The buffers are exchanged using DMABUF mechanism. The application takes
additional argument to setup capture's size and rotation and compose
window on output device (controlled using VIDIOC_S_CROP).
The application was tested on s5p-tv as output and s5p-fimc as capture.
It is written in GNU99 standard
Regards,
Tomasz Stanislawski
#include errno.h
#include fcntl.h
#include linux/videodev2.h
#include math.h
#include poll.h
#include stdio.h
#include stdint.h
#include stdlib.h
#include string.h
#include sys/ioctl.h
#include sys/mman.h
#include sys/stat.h
#include sys/types.h
#define ERRSTR strerror(errno)
#define BYE_ON(cond, ...) \
do { \
if (cond) { \
int errsv = errno; \
fprintf(stderr, ERROR(%s:%d) : , \
__FILE__, __LINE__); \
errno = errsv; \
fprintf(stderr, __VA_ARGS__); \
abort(); \
} \
} while(0)
#define BUFFER_CNT 5
int main(int argc, char *argv[])
{
int ret;
BYE_ON(argc 3, bad args:\n\t%s input-node output-node
[w,h,rot] [left,top,w,h]\n, argv[0]);
int f_in, f_out;
f_in = open(argv[1], O_RDWR);
BYE_ON(f_in 0, open failed: %s\n, ERRSTR);
f_out = open(argv[2], O_RDWR);
BYE_ON(f_out 0, open failed: %s\n, ERRSTR);
/* configure desired image size */
struct v4l2_format fmt;
memset(fmt, 0, sizeof fmt);
fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
fmt.fmt.pix_mp.pixelformat = V4L2_PIX_FMT_RGB565;
int rotation = 0;
if (argc = 4) {
ret = sscanf(argv[3], %u,%u,%d,
fmt.fmt.pix_mp.width,
fmt.fmt.pix_mp.height,
rotation);
BYE_ON(ret 2, incorrect sensor size and rotation\n);
}
if (rotation) {
struct v4l2_control ctrl = {
.id = V4L2_CID_ROTATE,
.value = rotation,
};
ret = ioctl(f_in, VIDIOC_S_CTRL, ctrl);
BYE_ON(ret 0, VIDIOC_S_CTRL failed: %s\n, ERRSTR);
}
/* set format struct */
ret = ioctl(f_in, VIDIOC_S_FMT, fmt);
BYE_ON(ret 0, VIDIOC_S_FMT failed: %s\n, ERRSTR);
/* get format struct */
ret = ioctl(f_in, VIDIOC_G_FMT, fmt);
BYE_ON(ret 0, VIDIOC_G_FMT failed: %s\n, ERRSTR);
printf(G_FMT(f_in): width = %u, height = %u, 4cc = %.4s\n,
fmt.fmt.pix.width, fmt.fmt.pix.height,
(char*)fmt.fmt.pix.pixelformat);
if (argc = 5) {
struct v4l2_crop crop;
crop.type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
ret = sscanf(argv[4], %d,%d,%d,%d,
crop.c.left, crop.c.top,
crop.c.width, crop.c.height);
BYE_ON(ret != 4, incorrect cropping format\n);
ret = ioctl(f_out, VIDIOC_S_CROP, crop);
BYE_ON(ret 0, VIDIOC_S_CROP failed: %s\n, ERRSTR);
}
/* pass input format to output */
fmt.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
ret = ioctl(f_out, VIDIOC_S_FMT, fmt);
BYE_ON(ret 0, VIDIOC_S_FMT failed: %s\n, ERRSTR);
/* get format struct */
ret = ioctl(f_out, VIDIOC_G_FMT, fmt);
BYE_ON(ret 0, VIDIOC_G_FMT failed: %s\n, ERRSTR);
printf(G_FMT(f_out): width = %u, height = %u, 4cc = %.4s\n,
fmt.fmt.pix.width, fmt.fmt.pix.height,
(char*)fmt.fmt.pix.pixelformat);
/* allocate buffers */
struct v4l2_requestbuffers rqbufs;
rqbufs.count = BUFFER_CNT;
rqbufs.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
rqbufs.memory = V4L2_MEMORY_MMAP;
ret = ioctl(f_in, VIDIOC_REQBUFS, rqbufs);
BYE_ON(ret 0, VIDIOC_REQBUFS failed: %s\n, ERRSTR);
BYE_ON(rqbufs.count BUFFER_CNT, failed to get %d buffers\n,
BUFFER_CNT);
rqbufs.count = BUFFER_CNT;
rqbufs.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
rqbufs.memory = V4L2_MEMORY_DMABUF;
ret = ioctl(f_out, VIDIOC_REQBUFS, rqbufs);
BYE_ON(ret 0, VIDIOC_REQBUFS failed: %s\n, ERRSTR);
BYE_ON(rqbufs.count BUFFER_CNT, failed to get %d buffers\n,
BUFFER_CNT);
int fd[BUFFER_CNT];
/* buffers initalization */
for (int i = 0; i BUFFER_CNT; ++i) {
struct v4l2_plane plane;
struct v4l2_buffer buf;
memset(buf, 0, sizeof buf);
memset(plane, 0, sizeof plane);
buf.index = i;
Re: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
On Thu, Jan 26, 2012 at 01:28:16AM +0200, Sakari Ailus wrote: Why you should not hang onto mappings forever? This is currently done by virtually all V4L2 drivers where such mappings are relevant. Not doing so would really kill the performance i.e. it's infeasible. Same goes to (m)any other multimedia devices dealing with buffers containing streaming video data. Because I want dynamic memory managemt simple because everything else does not make sense. I know that in v4l things don't work that way, but in drm they _do_. And if you share tons of buffers with drm drivers and don't follow the rules, the OOM killer will come around and shot at your apps. Because at least in i915 we do slurp in as much memory as we can until the oom killer starts growling, at which point we kick out stuff. I know that current dma_buf isn't there and for many use-cases discussed here we can get away without that complexity. So you actually can just map your dma_buf and never ever let go of that mapping again in many cases. The only reason I'm such a stuborn bastard about all this is that drm/* will do dynamic bo management even with dma_buf sooner or later and you should better know that and why and the implications if you choose to ignore it. And obviously, the generic dma_buf interface needs to be able to support it. Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- 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 4/4] media i.MX27 camera: handle overflows properly.
Hi Guennadi,
On 25 January 2012 13:17, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Fri, 20 Jan 2012, Javier Martin wrote:
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index e0c5dd4..cdc614f 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -1274,7 +1274,10 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
buf-state = state;
do_gettimeofday(vb-v4l2_buf.timestamp);
vb-v4l2_buf.sequence = pcdev-frame_count;
- vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
+ if (state == MX2_STATE_ERROR)
+ vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
+ else
+ vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
}
pcdev-frame_count++;
@@ -1309,19 +1312,11 @@ static irqreturn_t mx27_camera_emma_irq(int
irq_emma, void *data)
struct mx2_buffer *buf;
if (status (1 7)) { /* overflow */
- u32 cntl;
- /*
- * We only disable channel 1 here since this is the only
- * enabled channel
- *
- * FIXME: the correct DMA overflow handling should be resetting
- * the buffer, returning an error frame, and continuing with
- * the next one.
- */
- cntl = readl(pcdev-base_emma + PRP_CNTL);
- writel(cntl ~(PRP_CNTL_CH1EN | PRP_CNTL_CH2EN),
- pcdev-base_emma + PRP_CNTL);
- writel(cntl, pcdev-base_emma + PRP_CNTL);
+ buf = list_entry(pcdev-active_bufs.next,
+ struct mx2_buffer, queue);
+ mx27_camera_frame_done_emma(pcdev,
+ buf-bufnum, MX2_STATE_ERROR);
+ status = ~(1 7);
}
if status (3 5)) == (3 5)) ||
Does it make sense continuing processing here, if an error occurred? To me
all the four if statements in this function seem mutually-exclusive and
should be handled by a
if () {
} else if () {
...
chain.
((status (3 3)) == (3 3)))
Yes, as you point out, everything is mutually exclusive.
Regards.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.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: 290e locking issue
the dmesg output from inplug of 290e until usb mem stick mount timeout with a cut marked --- cut similar --- between mount and timeout for less output is inplug 290e [ 112.367345] usb 2-3: new high-speed USB device number 2 using ehci_hcd [ 112.482773] usb 2-3: New USB device found, idVendor=2013, idProduct=024f [ 112.482783] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 112.482790] usb 2-3: Product: PCTV 290e [ 112.482796] usb 2-3: Manufacturer: PCTV Systems [ 112.482801] usb 2-3: SerialNumber: 0006VEJQ [ 112.988850] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) [ 112.988929] em28xx #0: chip ID is em28174 [ 113.284694] em28xx #0: Identified as PCTV nanoStick T2 290e (card=78) [ 113.340323] Registered IR keymap rc-pinnacle-pctv-hd [ 113.340594] input: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb2/2-3/rc/rc1/input19 [ 113.341677] rc1: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb2/2-3/rc/rc1 [ 113.342411] em28xx #0: v4l2 driver version 0.1.3 [ 113.348855] em28xx #0: V4L2 video device registered as video1 [ 113.350562] usbcore: registered new interface driver em28xx [ 113.350568] em28xx driver loaded [ 113.480057] tda18271 17-0060: creating new instance [ 113.485221] TDA18271HD/C2 detected @ 17-0060 [ 113.724218] tda18271 17-0060: attaching existing instance [ 113.724227] DVB: registering new adapter (em28xx #0) [ 113.724235] DVB: registering adapter 0 frontend 0 (Sony CXD2820R (DVB-T/T2))... [ 113.724763] DVB: registering adapter 0 frontend 1 (Sony CXD2820R (DVB-C))... [ 113.728614] em28xx #0: Successfully loaded em28xx-dvb [ 113.728617] Em28xx: Initialized (Em28xx dvb Extension) extension inplug usb mem stick [ 136.177341] usb 2-1: new high-speed USB device number 3 using ehci_hcd [ 136.308531] usb 2-1: New USB device found, idVendor=0bda, idProduct=0120 [ 136.308541] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 136.308548] usb 2-1: Product: USB2.0-CRW [ 136.308554] usb 2-1: Manufacturer: Generic [ 136.308559] usb 2-1: SerialNumber: 2006041309210 [ 136.630379] Initializing USB Mass Storage driver... [ 136.630764] scsi6 : usb-storage 2-1:1.0 [ 136.631270] usbcore: registered new interface driver usb-storage [ 136.631275] USB Mass Storage support registered. [ 137.636863] scsi 6:0:0:0: Direct-Access Generic- Card Reader 1.00 PQ: 0 ANSI: 0 CCS [ 137.639519] sd 6:0:0:0: Attached scsi generic sg3 type 0 [ 138.446467] sd 6:0:0:0: [sdc] 15661056 512-byte logical blocks: (8.01 GB/7.46 GiB) [ 138.447282] sd 6:0:0:0: [sdc] Write Protect is off [ 138.447291] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00 [ 138.448138] sd 6:0:0:0: [sdc] No Caching mode page present [ 138.448147] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 138.451639] sd 6:0:0:0: [sdc] No Caching mode page present [ 138.451647] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 138.452729] sdc: sdc1 mount usb mem stick sdc1 [ 168.838133] usb 2-1: reset high-speed USB device number 3 using ehci_hcd [ 168.959139] sd 6:0:0:0: [sdc] No Caching mode page present [ 168.959150] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 168.959159] sd 6:0:0:0: [sdc] Attached SCSI removable disk [ 199.878136] usb 2-1: reset high-speed USB device number 3 using ehci_hcd [ 199.998075] sd 6:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 199.998082] sd 6:0:0:0: [sdc] Sense Key : Illegal Request [current] [ 199.998087] sd 6:0:0:0: [sdc] Add. Sense: Logical block address out of range [ 199.998094] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 ee f7 80 00 00 08 00 [ 199.998106] end_request: I/O error, dev sdc, sector 15660928 [ 199.998110] Buffer I/O error on device sdc, logical block 1957616 [ 199.999455] sd 6:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 199.999460] sd 6:0:0:0: [sdc] Sense Key : Illegal Request [current] [ 199.999465] sd 6:0:0:0: [sdc] Add. Sense: Logical block address out of range [ 199.999471] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 ee f7 80 00 00 08 00 [ 199.999480] end_request: I/O error, dev sdc, sector 15660928 [ 199.999484] Buffer I/O error on device sdc, logical block 1957616 [ 200.000570] sd 6:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 200.000573] sd 6:0:0:0: [sdc] Sense Key : Illegal Request [current] [ 200.000576] sd 6:0:0:0: [sdc] Add. Sense: Logical block address out of range [ 200.000580] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 ee f7 80 00 00 08 00 [ 200.000586] end_request: I/O error, dev sdc, sector 15660928 [ 200.000589] Buffer I/O error on device sdc1, logical block 1956592 [ 200.001696] sd 6:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 200.001701] sd 6:0:0:0: [sdc] Sense Key : Illegal Request [current] [ 200.001705] sd 6:0:0:0: [sdc] Add. Sense: Logical block address out of range [ 200.001711] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 ee
Re: 290e locking issue
On 01/26/2012 01:46 PM, Claus Olesen wrote: the dmesg output from inplug of 290e until usb mem stick mount timeout with a cut marked --- cut similar --- between mount and timeout for less output is I think it is maybe some incapability of em28xx driver. Maybe it could be something to do with USB HCI too... Could you test latest drivers using media_build.git ? inplug 290e [ 112.367345] usb 2-3: new high-speed USB device number 2 using ehci_hcd [ 112.482773] usb 2-3: New USB device found, idVendor=2013, idProduct=024f [ 112.482783] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 112.482790] usb 2-3: Product: PCTV 290e [ 112.482796] usb 2-3: Manufacturer: PCTV Systems [ 112.482801] usb 2-3: SerialNumber: 0006VEJQ [ 112.988850] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) [ 112.988929] em28xx #0: chip ID is em28174 [ 113.284694] em28xx #0: Identified as PCTV nanoStick T2 290e (card=78) [ 113.340323] Registered IR keymap rc-pinnacle-pctv-hd [ 113.340594] input: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb2/2-3/rc/rc1/input19 [ 113.341677] rc1: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb2/2-3/rc/rc1 [ 113.342411] em28xx #0: v4l2 driver version 0.1.3 [ 113.348855] em28xx #0: V4L2 video device registered as video1 [ 113.350562] usbcore: registered new interface driver em28xx [ 113.350568] em28xx driver loaded [ 113.480057] tda18271 17-0060: creating new instance [ 113.485221] TDA18271HD/C2 detected @ 17-0060 [ 113.724218] tda18271 17-0060: attaching existing instance [ 113.724227] DVB: registering new adapter (em28xx #0) [ 113.724235] DVB: registering adapter 0 frontend 0 (Sony CXD2820R (DVB-T/T2))... [ 113.724763] DVB: registering adapter 0 frontend 1 (Sony CXD2820R (DVB-C))... [ 113.728614] em28xx #0: Successfully loaded em28xx-dvb [ 113.728617] Em28xx: Initialized (Em28xx dvb Extension) extension inplug usb mem stick [ 136.177341] usb 2-1: new high-speed USB device number 3 using ehci_hcd [ 136.308531] usb 2-1: New USB device found, idVendor=0bda, idProduct=0120 [ 136.308541] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 136.308548] usb 2-1: Product: USB2.0-CRW [ 136.308554] usb 2-1: Manufacturer: Generic [ 136.308559] usb 2-1: SerialNumber: 2006041309210 [ 136.630379] Initializing USB Mass Storage driver... [ 136.630764] scsi6 : usb-storage 2-1:1.0 [ 136.631270] usbcore: registered new interface driver usb-storage [ 136.631275] USB Mass Storage support registered. [ 137.636863] scsi 6:0:0:0: Direct-Access Generic- Card Reader 1.00 PQ: 0 ANSI: 0 CCS [ 137.639519] sd 6:0:0:0: Attached scsi generic sg3 type 0 [ 138.446467] sd 6:0:0:0: [sdc] 15661056 512-byte logical blocks: (8.01 GB/7.46 GiB) [ 138.447282] sd 6:0:0:0: [sdc] Write Protect is off [ 138.447291] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00 [ 138.448138] sd 6:0:0:0: [sdc] No Caching mode page present [ 138.448147] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 138.451639] sd 6:0:0:0: [sdc] No Caching mode page present [ 138.451647] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 138.452729] sdc: sdc1 mount usb mem stick sdc1 [ 168.838133] usb 2-1: reset high-speed USB device number 3 using ehci_hcd [... removed lot of similar USB errors ...] driverbyte=DRIVER_SENSE [ 478.342504] sd 6:0:0:0: [sdc] Sense Key : Illegal Request [current] [ 478.342510] sd 6:0:0:0: [sdc] Add. Sense: Logical block address out of range [ 478.342517] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 00 20 00 00 00 01 00 [ 478.342528] end_request: I/O error, dev sdc, sector 8192 [ 478.342545] FAT-fs (sdc1): unable to read boot sector On Thu, Jan 26, 2012 at 10:07 AM, Antti Palosaaricr...@iki.fi wrote: On 01/26/2012 12:16 AM, Claus Olesen wrote: just got 3.2.1-3.fc16.i686.PAE the issue that the driver had to be removed for the 290e to work after a replug is gone. the issue that a usb mem stick cannot be mounted while the 290e is plugged in still lingers. one workaround is to unplug the 290e and wait a little (no need to also remove the driver). What it prints to the system log? Use tail -f /var/log/messages or dmesg. Antti -- http://palosaari.fi/ -- 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
[PATCH v2 1/4] media i.MX27 camera: migrate driver to videobuf2
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- mx27 code doesn't use states.
- number of states reduced to the ones used by mx25.
- Fix incorrect if which broke mx25 support.
- Minor fixes.
---
drivers/media/video/mx2_camera.c | 298 --
1 files changed, 127 insertions(+), 171 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index ca76dd2..898f98f 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -3,6 +3,7 @@
*
* Copyright (C) 2008, Sascha Hauer, Pengutronix
* Copyright (C) 2010, Baruch Siach, Orex Computed Radiography
+ * Copyright (C) 2012, Javier Martin, Vista Silicon S.L.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -30,8 +31,8 @@
#include media/v4l2-common.h
#include media/v4l2-dev.h
-#include media/videobuf-core.h
-#include media/videobuf-dma-contig.h
+#include media/videobuf2-core.h
+#include media/videobuf2-dma-contig.h
#include media/soc_camera.h
#include media/soc_mediabus.h
@@ -223,6 +224,22 @@ struct mx2_fmt_cfg {
struct mx2_prp_cfg cfg;
};
+enum mx2_buffer_state {
+ MX2_STATE_QUEUED,
+ MX2_STATE_ACTIVE,
+ MX2_STATE_DONE,
+};
+
+/* buffer for one video frame */
+struct mx2_buffer {
+ /* common v4l buffer stuff -- must be first */
+ struct vb2_buffer vb;
+ struct list_headqueue;
+ enum mx2_buffer_state state;
+
+ int bufnum;
+};
+
struct mx2_camera_dev {
struct device *dev;
struct soc_camera_host soc_host;
@@ -256,16 +273,7 @@ struct mx2_camera_dev {
size_t discard_size;
struct mx2_fmt_cfg *emma_prp;
u32 frame_count;
-};
-
-/* buffer for one video frame */
-struct mx2_buffer {
- /* common v4l buffer stuff -- must be first */
- struct videobuf_buffer vb;
-
- enum v4l2_mbus_pixelcodecode;
-
- int bufnum;
+ struct vb2_alloc_ctx*alloc_ctx;
};
static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
@@ -407,7 +415,7 @@ static irqreturn_t mx27_camera_irq(int irq_csi, void *data)
static void mx25_camera_frame_done(struct mx2_camera_dev *pcdev, int fb,
int state)
{
- struct videobuf_buffer *vb;
+ struct vb2_buffer *vb;
struct mx2_buffer *buf;
struct mx2_buffer **fb_active = fb == 1 ? pcdev-fb1_active :
pcdev-fb2_active;
@@ -420,25 +428,24 @@ static void mx25_camera_frame_done(struct mx2_camera_dev
*pcdev, int fb,
goto out;
vb = (*fb_active)-vb;
- dev_dbg(pcdev-dev, %s (vb=0x%p) 0x%08lx %d\n, __func__,
- vb, vb-baddr, vb-bsize);
+ dev_dbg(pcdev-dev, %s (vb=0x%p) 0x%p %lu\n, __func__,
+ vb, vb2_plane_vaddr(vb, 0), vb2_get_plane_payload(vb, 0));
- vb-state = state;
- do_gettimeofday(vb-ts);
- vb-field_count++;
-
- wake_up(vb-done);
+ do_gettimeofday(vb-v4l2_buf.timestamp);
+ vb-v4l2_buf.sequence++;
+ vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
if (list_empty(pcdev-capture)) {
buf = NULL;
writel(0, pcdev-base_csi + fb_reg);
} else {
buf = list_entry(pcdev-capture.next, struct mx2_buffer,
- vb.queue);
+ queue);
vb = buf-vb;
- list_del(vb-queue);
- vb-state = VIDEOBUF_ACTIVE;
- writel(videobuf_to_dma_contig(vb), pcdev-base_csi + fb_reg);
+ list_del(buf-queue);
+ buf-state = MX2_STATE_ACTIVE;
+ writel(vb2_dma_contig_plane_dma_addr(vb, 0),
+ pcdev-base_csi + fb_reg);
}
*fb_active = buf;
@@ -453,9 +460,9 @@ static irqreturn_t mx25_camera_irq(int irq_csi, void *data)
u32 status = readl(pcdev-base_csi + CSISR);
if (status CSISR_DMA_TSF_FB1_INT)
- mx25_camera_frame_done(pcdev, 1, VIDEOBUF_DONE);
+ mx25_camera_frame_done(pcdev, 1, MX2_STATE_DONE);
else if (status CSISR_DMA_TSF_FB2_INT)
- mx25_camera_frame_done(pcdev, 2, VIDEOBUF_DONE);
+ mx25_camera_frame_done(pcdev, 2, MX2_STATE_DONE);
/* FIXME: handle CSISR_RFF_OR_INT */
@@ -467,59 +474,50 @@ static irqreturn_t mx25_camera_irq(int irq_csi, void
*data)
/*
* Videobuf operations
*/
-static int mx2_videobuf_setup(struct videobuf_queue *vq, unsigned int *count,
- unsigned int *size)
+static int mx2_videobuf_setup(struct vb2_queue *vq,
+ const struct v4l2_format *fmt,
+ unsigned int *count, unsigned int *num_planes,
+
[PATCH v2 2/4] media i.MX27 camera: add start_stream and stop_stream callbacks.
Add start_stream and stop_stream callback in order to enable
and disable the eMMa-PrP properly and save CPU usage avoiding
IRQs when the device is not streaming. This also makes the driver
return 0 as the sequence number of the first frame.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Merge media i.MX27 camera: properly detect frame loss
---
drivers/media/video/mx2_camera.c | 104 +-
1 files changed, 79 insertions(+), 25 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 898f98f..045c018 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -377,7 +377,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
pcdev-icd = icd;
- pcdev-frame_count = 0;
+ pcdev-frame_count = -1;
dev_info(icd-parent, Camera driver attached to camera %d\n,
icd-devnum);
@@ -647,11 +647,83 @@ static void mx2_videobuf_release(struct vb2_buffer *vb)
spin_unlock_irqrestore(pcdev-lock, flags);
}
+static int mx2_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct soc_camera_device *icd = soc_camera_from_vb2q(q);
+ struct soc_camera_host *ici =
+ to_soc_camera_host(icd-parent);
+ struct mx2_camera_dev *pcdev = ici-priv;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(pcdev-lock, flags);
+ if (mx27_camera_emma(pcdev)) {
+ if (count 2) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ if (prp-cfg.channel == 1) {
+ writel(PRP_CNTL_CH1EN |
+ PRP_CNTL_CSIEN |
+ prp-cfg.in_fmt |
+ prp-cfg.out_fmt |
+ PRP_CNTL_CH1_LEN |
+ PRP_CNTL_CH1BYP |
+ PRP_CNTL_CH1_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev-base_emma + PRP_CNTL);
+ } else {
+ writel(PRP_CNTL_CH2EN |
+ PRP_CNTL_CSIEN |
+ prp-cfg.in_fmt |
+ prp-cfg.out_fmt |
+ PRP_CNTL_CH2_LEN |
+ PRP_CNTL_CH2_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev-base_emma + PRP_CNTL);
+ }
+ }
+err:
+ spin_unlock_irqrestore(pcdev-lock, flags);
+
+ return ret;
+}
+
+static int mx2_stop_streaming(struct vb2_queue *q)
+{
+ struct soc_camera_device *icd = soc_camera_from_vb2q(q);
+ struct soc_camera_host *ici =
+ to_soc_camera_host(icd-parent);
+ struct mx2_camera_dev *pcdev = ici-priv;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+ unsigned long flags;
+ u32 cntl;
+
+ spin_lock_irqsave(pcdev-lock, flags);
+ if (mx27_camera_emma(pcdev)) {
+ cntl = readl(pcdev-base_emma + PRP_CNTL);
+ if (prp-cfg.channel == 1) {
+ writel(cntl ~PRP_CNTL_CH1EN,
+ pcdev-base_emma + PRP_CNTL);
+ } else {
+ writel(cntl ~PRP_CNTL_CH2EN,
+ pcdev-base_emma + PRP_CNTL);
+ }
+ }
+ spin_unlock_irqrestore(pcdev-lock, flags);
+
+ return 0;
+}
+
static struct vb2_ops mx2_videobuf_ops = {
- .queue_setup= mx2_videobuf_setup,
- .buf_prepare= mx2_videobuf_prepare,
- .buf_queue = mx2_videobuf_queue,
- .buf_cleanup= mx2_videobuf_release,
+ .queue_setup = mx2_videobuf_setup,
+ .buf_prepare = mx2_videobuf_prepare,
+ .buf_queue = mx2_videobuf_queue,
+ .buf_cleanup = mx2_videobuf_release,
+ .start_streaming = mx2_start_streaming,
+ .stop_streaming = mx2_stop_streaming,
};
static int mx2_camera_init_videobuf(struct vb2_queue *q,
@@ -709,16 +781,6 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
writel(pcdev-discard_buffer_dma,
pcdev-base_emma + PRP_DEST_RGB2_PTR);
- writel(PRP_CNTL_CH1EN |
- PRP_CNTL_CSIEN |
- prp-cfg.in_fmt |
- prp-cfg.out_fmt |
- PRP_CNTL_CH1_LEN |
- PRP_CNTL_CH1BYP |
- PRP_CNTL_CH1_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev-base_emma + PRP_CNTL);
-
[PATCH v2 3/4] media i.MX27 camera: improve discard buffer handling.
The way discard buffer was previously handled lead
to possible races that made a buffer that was not
yet ready to be overwritten by new video data. This
is easily detected at 25fps just adding #define DEBUG
to enable the memset check and seeing how the image
is corrupted.
A new discard queue and two discard buffers have
been added to make them flow trough the pipeline
of queues and thus provide suitable event ordering.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Don't allocate discard buffer on every set_fmt.
---
drivers/media/video/mx2_camera.c | 261 +-
1 files changed, 144 insertions(+), 117 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 045c018..71054ab 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -237,7 +237,8 @@ struct mx2_buffer {
struct list_headqueue;
enum mx2_buffer_state state;
- int bufnum;
+ int bufnum;
+ booldiscard;
};
struct mx2_camera_dev {
@@ -256,6 +257,7 @@ struct mx2_camera_dev {
struct list_headcapture;
struct list_headactive_bufs;
+ struct list_headdiscard;
spinlock_t lock;
@@ -268,6 +270,7 @@ struct mx2_camera_dev {
u32 csicr1;
+ struct mx2_buffer buf_discard[2];
void*discard_buffer;
dma_addr_t discard_buffer_dma;
size_t discard_size;
@@ -329,6 +332,30 @@ static struct mx2_fmt_cfg *mx27_emma_prp_get_format(
return mx27_emma_prp_table[0];
};
+static void mx27_update_emma_buf(struct mx2_camera_dev *pcdev,
+unsigned long phys, int bufnum)
+{
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+
+ if (prp-cfg.channel == 1) {
+ writel(phys, pcdev-base_emma +
+ PRP_DEST_RGB1_PTR + 4 * bufnum);
+ } else {
+ writel(phys, pcdev-base_emma +
+ PRP_DEST_Y_PTR - 0x14 * bufnum);
+ if (prp-out_fmt == V4L2_PIX_FMT_YUV420) {
+ u32 imgsize = pcdev-icd-user_height *
+ pcdev-icd-user_width;
+
+ writel(phys + imgsize,
+ pcdev-base_emma + PRP_DEST_CB_PTR -
+ 0x14 * bufnum);
+ writel(phys + ((5 * imgsize) / 4), pcdev-base_emma +
+ PRP_DEST_CR_PTR - 0x14 * bufnum);
+ }
+ }
+}
+
static void mx2_camera_deactivate(struct mx2_camera_dev *pcdev)
{
unsigned long flags;
@@ -377,7 +404,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
pcdev-icd = icd;
- pcdev-frame_count = -1;
+ pcdev-frame_count = 0;
dev_info(icd-parent, Camera driver attached to camera %d\n,
icd-devnum);
@@ -631,7 +658,7 @@ static void mx2_videobuf_release(struct vb2_buffer *vb)
spin_lock_irqsave(pcdev-lock, flags);
if (mx27_camera_emma(pcdev)) {
- list_del_init(buf-queue);
+ INIT_LIST_HEAD(buf-queue);
} else if (cpu_is_mx25() buf-state == MX2_STATE_ACTIVE) {
if (pcdev-fb1_active == buf) {
pcdev-csicr1 = ~CSICR1_FB1_DMA_INTEN;
@@ -647,6 +674,34 @@ static void mx2_videobuf_release(struct vb2_buffer *vb)
spin_unlock_irqrestore(pcdev-lock, flags);
}
+static void mx27_camera_emma_buf_init(struct soc_camera_device *icd,
+ int bytesperline)
+{
+ struct soc_camera_host *ici =
+ to_soc_camera_host(icd-parent);
+ struct mx2_camera_dev *pcdev = ici-priv;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+
+ writel((icd-user_width 16) | icd-user_height,
+ pcdev-base_emma + PRP_SRC_FRAME_SIZE);
+ writel(prp-cfg.src_pixel,
+ pcdev-base_emma + PRP_SRC_PIXEL_FORMAT_CNTL);
+ if (prp-cfg.channel == 1) {
+ writel((icd-user_width 16) | icd-user_height,
+ pcdev-base_emma + PRP_CH1_OUT_IMAGE_SIZE);
+ writel(bytesperline,
+ pcdev-base_emma + PRP_DEST_CH1_LINE_STRIDE);
+ writel(prp-cfg.ch1_pixel,
+ pcdev-base_emma + PRP_CH1_PIXEL_FORMAT_CNTL);
+ } else { /* channel 2 */
+ writel((icd-user_width 16) | icd-user_height,
+ pcdev-base_emma + PRP_CH2_OUT_IMAGE_SIZE);
+ }
+
+ /* Enable interrupts */
+ writel(prp-cfg.irq_flags, pcdev-base_emma + PRP_INTR_CNTL);
+}
+
static int mx2_start_streaming(struct vb2_queue *q, unsigned int count)
{
struct soc_camera_device
[PATCH v2 4/4] media i.MX27 camera: handle overflows properly.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Make ifs in irq callback mutually exclusive.
- Add new argument to mx27_camera_frame_done_emma() to handle errors.
---
drivers/media/video/mx2_camera.c | 38 --
1 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 71054ab..1759673 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -1213,7 +1213,7 @@ static struct soc_camera_host_ops mx2_soc_camera_host_ops
= {
};
static void mx27_camera_frame_done_emma(struct mx2_camera_dev *pcdev,
- int bufnum)
+ int bufnum, bool err)
{
struct mx2_buffer *buf;
struct vb2_buffer *vb;
@@ -1262,7 +1262,10 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
list_del_init(buf-queue);
do_gettimeofday(vb-v4l2_buf.timestamp);
vb-v4l2_buf.sequence = pcdev-frame_count;
- vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
+ if (err)
+ vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
+ else
+ vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
}
pcdev-frame_count++;
@@ -1297,21 +1300,12 @@ static irqreturn_t mx27_camera_emma_irq(int irq_emma,
void *data)
struct mx2_buffer *buf;
if (status (1 7)) { /* overflow */
- u32 cntl;
- /*
-* We only disable channel 1 here since this is the only
-* enabled channel
-*
-* FIXME: the correct DMA overflow handling should be resetting
-* the buffer, returning an error frame, and continuing with
-* the next one.
-*/
- cntl = readl(pcdev-base_emma + PRP_CNTL);
- writel(cntl ~(PRP_CNTL_CH1EN | PRP_CNTL_CH2EN),
- pcdev-base_emma + PRP_CNTL);
- writel(cntl, pcdev-base_emma + PRP_CNTL);
- }
- if status (3 5)) == (3 5)) ||
+ buf = list_entry(pcdev-active_bufs.next,
+ struct mx2_buffer, queue);
+ mx27_camera_frame_done_emma(pcdev,
+ buf-bufnum, 1);
+ status = ~(1 7);
+ } else if status (3 5)) == (3 5)) ||
((status (3 3)) == (3 3)))
!list_empty(pcdev-active_bufs)) {
/*
@@ -1320,13 +1314,13 @@ static irqreturn_t mx27_camera_emma_irq(int irq_emma,
void *data)
*/
buf = list_entry(pcdev-active_bufs.next,
struct mx2_buffer, queue);
- mx27_camera_frame_done_emma(pcdev, buf-bufnum);
+ mx27_camera_frame_done_emma(pcdev, buf-bufnum, 0);
status = ~(1 (6 - buf-bufnum)); /* mark processed */
+ } else if ((status (1 6)) || (status (1 4))) {
+ mx27_camera_frame_done_emma(pcdev, 0, 0);
+ } else if ((status (1 5)) || (status (1 3))) {
+ mx27_camera_frame_done_emma(pcdev, 1, 0);
}
- if ((status (1 6)) || (status (1 4)))
- mx27_camera_frame_done_emma(pcdev, 0);
- if ((status (1 5)) || (status (1 3)))
- mx27_camera_frame_done_emma(pcdev, 1);
writel(status, pcdev-base_emma + PRP_INTRSTATUS);
--
1.7.0.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
Re: CI/CAM support for offline (from file) decoding
Kovacs Balazs writes: Yes, i thought about that, but i need the Hardware CAM + CI, because it's chip paired encryption. It means in my situation that the EMM and ECM is also encrypted so it's hard to use in a SoftCam configuration. I hope there's a solution in the DVB driver space. I receive the signal via RF or IP. If via RF i think it can be decoded via the HW, and the record it to disk, but i need the full TS decrypted, and i think it's not possible (to decrypt all the encrypted ES which can be 20-30-40 in real time when i receive the signal). In IP configuration it's also not possible. So i have the recorded full TS pieces and somehow i have to decrypt with a CAM+Card paired to each other. Of course i know that the decryption is only possible if the Smartcard has the authorization in those date ranges when the files was recorded. I have seen this kind of solution in Windows, but i need it on Linux now. Yes, you can do that, but only if the hardware supports it. Most cards with CAM/CI are hardwired in such a way that the transport stream comes from the demodulator, goes through the CAM/CI and then into the PCIe/PCI bridge. There are only a few cards where you can send a TS from memory to the CAM/CI and back. -Ralph -- 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: CI/CAM support for offline (from file) decoding
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Ralph Metzler Sent: jeudi 26 janvier 2012 13:21 To: linux-media@vger.kernel.org Subject: Re: CI/CAM support for offline (from file) decoding Kovacs Balazs writes: Yes, i thought about that, but i need the Hardware CAM + CI, because it's chip paired encryption. It means in my situation that the EMM and ECM is also encrypted so it's hard to use in a SoftCam configuration. I hope there's a solution in the DVB driver space. I receive the signal via RF or IP. If via RF i think it can be decoded via the HW, and the record it to disk, but i need the full TS decrypted, and i think it's not possible (to decrypt all the encrypted ES which can be 20-30-40 in real time when i receive the signal). In IP configuration it's also not possible. So i have the recorded full TS pieces and somehow i have to decrypt with a CAM+Card paired to each other. Of course i know that the decryption is only possible if the Smartcard has the authorization in those date ranges when the files was recorded. I have seen this kind of solution in Windows, but i need it on Linux now. Yes, you can do that, but only if the hardware supports it. Most cards with CAM/CI are hardwired in such a way that the transport stream comes from the demodulator, goes through the CAM/CI and then into the PCIe/PCI bridge. There are only a few cards where you can send a TS from memory to the CAM/CI and back. -Ralph The Octopus CI from Digital Devices is the only one I know where you can input the TS stream directly to the CAM: http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ViewObjectID=370117 11 -- 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: recurring Problem with CAM on Technotrend TT-connect CT-3650
no one ? Zitat von Thor myt...@x-defense.de: hi all, checked out git on january 8th. have the cam working,but it stops working every two or 3 days (system is running 24 hours) sometimes it recovers on its own: Jan 21 20:59:45 zotac kernel: [81316.229519] dvb_ca adapter 0: CAM tried to send a buffer larger than the ecount size! Jan 21 20:59:45 zotac kernel: [81316.229752] dvb_ca adapter 0: DVB CAM link initialisation failed :( Jan 21 20:59:52 zotac kernel: [81323.339595] dvb_ca adapter 0: DVB CAM detected and initialised successfully sometimes it doesn't : Jan 24 04:35:54 zotac kernel: [281485.531723] dvb_ca adapter 0: CAM tried to send a buffer larger than the link buffer size (32896 255)! Jan 24 04:35:55 zotac kernel: [281485.629455] dvb_ca adapter 0: CAM tried to send a buffer larger than the ecount size! Jan 24 04:35:55 zotac kernel: [281485.629702] dvb_ca adapter 0: DVB CAM link initialisation failed :( rmmod -f dvb_usb_ttusb2 modprobe dvb_usb_ttusb2 does bring it back to live. I am running on 3.0.0-14-generic-pae #23-Ubuntu SMP Mon Nov 21 22:07:10 UTC 2011 i686 i686 i386 GNU/Linux from mythbuntu. is there any more info you would need ? any advise available ? tia thorsten -- 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: CI/CAM support for offline (from file) decoding
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Ralph Metzler Sent: jeudi 26 janvier 2012 13:21 To: linux-media@vger.kernel.org Subject: Re: CI/CAM support for offline (from file) decoding Kovacs Balazs writes: Yes, i thought about that, but i need the Hardware CAM + CI, because it's chip paired encryption. It means in my situation that the EMM and ECM is also encrypted so it's hard to use in a SoftCam configuration. I hope there's a solution in the DVB driver space. I receive the signal via RF or IP. If via RF i think it can be decoded via the HW, and the record it to disk, but i need the full TS decrypted, and i think it's not possible (to decrypt all the encrypted ES which can be 20-30-40 in real time when i receive the signal). In IP configuration it's also not possible. So i have the recorded full TS pieces and somehow i have to decrypt with a CAM+Card paired to each other. Of course i know that the decryption is only possible if the Smartcard has the authorization in those date ranges when the files was recorded. I have seen this kind of solution in Windows, but i need it on Linux now. Yes, you can do that, but only if the hardware supports it. Most cards with CAM/CI are hardwired in such a way that the transport stream comes from the demodulator, goes through the CAM/CI and then into the PCIe/PCI bridge. There are only a few cards where you can send a TS from memory to the CAM/CI and back. -Ralph The Octopus CI from Digital Devices is the only one I know where you can input the TS stream directly to the CAM: http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ViewObjectID=370117 11 Is this the only solution? I need s2 tuner and IP input (from the motherboard's Ethernet) and record them to file splices. Then (for request) i have to decrypt one or more ES from the recorded file and push them back. It's a DVB monitoring solution. thanks Balazs -- 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: CI/CAM support for offline (from file) decoding
Kovacs Balazs writes: Yes, i thought about that, but i need the Hardware CAM + CI, because it's chip paired encryption. It means in my situation that the EMM and ECM is also encrypted so it's hard to use in a SoftCam configuration. I hope there's a solution in the DVB driver space. I receive the signal via RF or IP. If via RF i think it can be decoded via the HW, and the record it to disk, but i need the full TS decrypted, and i think it's not possible (to decrypt all the encrypted ES which can be 20-30-40 in real time when i receive the signal). In IP configuration it's also not possible. So i have the recorded full TS pieces and somehow i have to decrypt with a CAM+Card paired to each other. Of course i know that the decryption is only possible if the Smartcard has the authorization in those date ranges when the files was recorded. I have seen this kind of solution in Windows, but i need it on Linux now. Yes, you can do that, but only if the hardware supports it. Most cards with CAM/CI are hardwired in such a way that the transport stream comes from the demodulator, goes through the CAM/CI and then into the PCIe/PCI bridge. There are only a few cards where you can send a TS from memory to the CAM/CI and back. Can you suggest some kind of hardware? -Ralph -- 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: CI/CAM support for offline (from file) decoding
-Original Message- From: Kovacs Balazs [mailto:b...@bitklub.hu] Sent: jeudi 26 janvier 2012 14:45 To: Sébastien RAILLARD (COEXSI) Cc: 'Ralph Metzler'; linux-media@vger.kernel.org Subject: Re: CI/CAM support for offline (from file) decoding -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Ralph Metzler Sent: jeudi 26 janvier 2012 13:21 To: linux-media@vger.kernel.org Subject: Re: CI/CAM support for offline (from file) decoding Kovacs Balazs writes: Yes, i thought about that, but i need the Hardware CAM + CI, because it's chip paired encryption. It means in my situation that the EMM and ECM is also encrypted so it's hard to use in a SoftCam configuration. I hope there's a solution in the DVB driver space. I receive the signal via RF or IP. If via RF i think it can be decoded via the HW, and the record it to disk, but i need the full TS decrypted, and i think it's not possible (to decrypt all the encrypted ES which can be 20-30-40 in real time when i receive the signal). In IP configuration it's also not possible. So i have the recorded full TS pieces and somehow i have to decrypt with a CAM+Card paired to each other. Of course i know that the decryption is only possible if the Smartcard has the authorization in those date ranges when the files was recorded. I have seen this kind of solution in Windows, but i need it on Linux now. Yes, you can do that, but only if the hardware supports it. Most cards with CAM/CI are hardwired in such a way that the transport stream comes from the demodulator, goes through the CAM/CI and then into the PCIe/PCI bridge. There are only a few cards where you can send a TS from memory to the CAM/CI and back. -Ralph The Octopus CI from Digital Devices is the only one I know where you can input the TS stream directly to the CAM: http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ViewObjectID= 370117 11 Is this the only solution? I need s2 tuner and IP input (from the motherboard's Ethernet) and record them to file splices. Then (for request) i have to decrypt one or more ES from the recorded file and push them back. It's a DVB monitoring solution. If you need to decrypt stream using an official CAM, I don't think you'll have too much choice. By the way, this Octopus CI card has 2 connectors where you can connect two double DVB-S2 tuners. Tuners and CAM work independently. If you don't need an official CAM, maybe you can look to the OSCAM project... thanks Balazs -- 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: 290e locking issue
On Thu, Jan 26, 2012 at 6:58 AM, Antti Palosaari cr...@iki.fi wrote: I think it is maybe some incapability of em28xx driver. Maybe it could be something to do with USB HCI too... From a USB standpoint there isn't a whole lot the em28xx driver could do wrong. It's an isoc device, and perhaps it's not clearing it's bandwidth reservation after streaming is done, but even in that case it shouldn't prevent a disk from working since those are typically bulk devices. Devin -- Devin J. Heitmueller - 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/8] soc_camera: Use soc_camera_device::sizeimage to compute buffer sizes
Hi Laurent
Thanks for the patches. This one looks good mostly, a couple of questions
though:
On Wed, 25 Jan 2012, Laurent Pinchart wrote:
Instead of computing the buffer size manually in the videobuf queue
setup and buffer prepare callbacks, use the previously negotiated
soc_camera_device::sizeimage value.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/atmel-isi.c| 17 +++--
drivers/media/video/mx1_camera.c | 14 ++
drivers/media/video/mx2_camera.c | 14 ++
drivers/media/video/mx3_camera.c | 20 +---
drivers/media/video/omap1_camera.c | 14 ++
drivers/media/video/pxa_camera.c | 14 ++
drivers/media/video/sh_mobile_ceu_camera.c | 25 +
7 files changed, 29 insertions(+), 89 deletions(-)
[snip]
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index a803d9e..e9b228d 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -433,15 +433,10 @@ static int mx2_videobuf_setup(struct videobuf_queue
*vq, unsigned int *count,
unsigned int *size)
{
struct soc_camera_device *icd = vq-priv_data;
- int bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
- icd-current_fmt-host_fmt);
dev_dbg(icd-parent, count=%d, size=%d\n, *count, *size);
- if (bytes_per_line 0)
- return bytes_per_line;
-
- *size = bytes_per_line * icd-user_height;
+ *size = icd-sizeimage;
if (0 == *count)
*count = 32;
I think, there is a bug in mx2_camera_try_fmt(), which also would affect
these your calculations. On i.MX25 they restrict the image size based on
maximum supported number of bytes. In such a case they recalculate
.bytesperline, but they fail to update .sizeimage. The fix seems to be
trivial, please add it, then your calculations should be fine.
@@ -476,16 +471,11 @@ static int mx2_videobuf_prepare(struct videobuf_queue
*vq,
{
struct soc_camera_device *icd = vq-priv_data;
struct mx2_buffer *buf = container_of(vb, struct mx2_buffer, vb);
- int bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
- icd-current_fmt-host_fmt);
int ret = 0;
dev_dbg(icd-parent, %s (vb=0x%p) 0x%08lx %d\n, __func__,
vb, vb-baddr, vb-bsize);
- if (bytes_per_line 0)
- return bytes_per_line;
-
#ifdef DEBUG
/*
* This can be useful if you want to see if we actually fill
@@ -505,7 +495,7 @@ static int mx2_videobuf_prepare(struct videobuf_queue *vq,
vb-state = VIDEOBUF_NEEDS_INIT;
}
- vb-size = bytes_per_line * vb-height;
+ vb-size = icd-sizeimage;
if (vb-baddr vb-bsize vb-size) {
ret = -EINVAL;
goto out;
diff --git a/drivers/media/video/mx3_camera.c
b/drivers/media/video/mx3_camera.c
index f96f92f..da45a89 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -199,8 +199,6 @@ static int mx3_videobuf_setup(struct vb2_queue *vq,
struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct mx3_camera_dev *mx3_cam = ici-priv;
- int bytes_per_line;
- unsigned int height;
if (!mx3_cam-idmac_channel[0])
return -EINVAL;
@@ -208,21 +206,21 @@ static int mx3_videobuf_setup(struct vb2_queue *vq,
if (fmt) {
const struct soc_camera_format_xlate *xlate =
soc_camera_xlate_by_fourcc(icd,
fmt-fmt.pix.pixelformat);
+ int bytes_per_line;
+
if (!xlate)
return -EINVAL;
+
bytes_per_line = soc_mbus_bytes_per_line(fmt-fmt.pix.width,
xlate-host_fmt);
- height = fmt-fmt.pix.height;
+ if (bytes_per_line 0)
+ return bytes_per_line;
+
+ sizes[0] = bytes_per_line * fmt-fmt.pix.height;
} else {
/* Called from VIDIOC_REQBUFS or in compatibility mode */
- bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
- icd-current_fmt-host_fmt);
- height = icd-user_height;
+ sizes[0] = icd-sizeimage;
}
- if (bytes_per_line 0)
- return bytes_per_line;
-
- sizes[0] = bytes_per_line * height;
alloc_ctxs[0] = mx3_cam-alloc_ctx;
@@ -274,7 +272,7 @@ static void mx3_videobuf_queue(struct vb2_buffer *vb)
BUG_ON(bytes_per_line = 0);
- new_size = bytes_per_line * icd-user_height;
Re: [PATCH 2/8] soc_camera: Use soc_camera_device::bytesperline to compute line sizes
On Wed, 25 Jan 2012, Laurent Pinchart wrote: Instead of computing the line sizes, use the previously negotiated soc_camera_device::bytesperline value. Ok, some of my comments to the previous patch should actually be applied to this one instead, but you'll figure it out ;-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [PATCHv19 00/15] Contiguous Memory Allocator
On Thursday 26 January 2012, Marek Szyprowski wrote: Welcome everyone! Yes, that's true. This is yet another release of the Contiguous Memory Allocator patches. This version mainly includes code cleanups requested by Mel Gorman and a few minor bug fixes. Hi Marek, Thanks for keeping up this work! I really hope it works out for the next merge window. TODO (optional): - implement support for contiguous memory areas placed in HIGHMEM zone - resolve issue with movable pages with pending io operations Can you clarify these? I believe the contiguous memory areas in highmem is something that should really be after the existing code is merged into the upstream kernel and should better not be listed as TODO here. I haven't followed the last two releases so closely. It seems that in v17 the movable pages with pending i/o was still a major problem but in v18 you added a solution. Is that right? What is still left to be done here then? Arnd -- 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 v2] imon: don't wedge hardware after early callbacks
This patch is just a minor update to one titled imon: Input from ffdc
device type ignored from Corinna Vinschen. An earlier patch to prevent
an oops when we got early callbacks also has the nasty side-effect of
wedging imon hardware, as we don't acknowledge the urb. Rework the check
slightly here to bypass processing the packet, as the driver isn't yet
fully initialized, but still acknowlege the urb and submit a new rx_urb.
Do this for both interfaces -- irrelevant for ffdc hardware, but
relevant for newer hardware, though newer hardware doesn't spew the
constant stream of data as soon as the hardware is initialized like the
older ffdc devices, so they'd be less likely to trigger this anyway...
Tested with both an ffdc device and an 0042 device.
v2: Per Corinna's suggestion and prior precedent, increment driver
version number so we can more easily tell if a user has this fix.
CC: Corinna Vinschen vinsc...@redhat.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/rc/imon.c | 26 ++
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 6ed9646..046f529 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -47,7 +47,7 @@
#define MOD_AUTHOR Jarod Wilson ja...@wilsonet.com
#define MOD_DESC Driver for SoundGraph iMON MultiMedia IR/Display
#define MOD_NAME imon
-#define MOD_VERSION0.9.3
+#define MOD_VERSION0.9.4
#define DISPLAY_MINOR_BASE 144
#define DEVICE_NAMElcd%d
@@ -1658,9 +1658,17 @@ static void usb_rx_callback_intf0(struct urb *urb)
return;
ictx = (struct imon_context *)urb-context;
- if (!ictx || !ictx-dev_present_intf0)
+ if (!ictx)
return;
+ /*
+* if we get a callback before we're done configuring the hardware, we
+* can't yet process the data, as there's nowhere to send it, but we
+* still need to acknowledge the URB to avoid wedging the hardware
+*/
+ if (!ictx-dev_present_intf0)
+ goto out;
+
switch (urb-status) {
case -ENOENT: /* usbcore unlink successful! */
return;
@@ -1678,6 +1686,7 @@ static void usb_rx_callback_intf0(struct urb *urb)
break;
}
+out:
usb_submit_urb(ictx-rx_urb_intf0, GFP_ATOMIC);
}
@@ -1690,9 +1699,17 @@ static void usb_rx_callback_intf1(struct urb *urb)
return;
ictx = (struct imon_context *)urb-context;
- if (!ictx || !ictx-dev_present_intf1)
+ if (!ictx)
return;
+ /*
+* if we get a callback before we're done configuring the hardware, we
+* can't yet process the data, as there's nowhere to send it, but we
+* still need to acknowledge the URB to avoid wedging the hardware
+*/
+ if (!ictx-dev_present_intf1)
+ goto out;
+
switch (urb-status) {
case -ENOENT: /* usbcore unlink successful! */
return;
@@ -1710,6 +1727,7 @@ static void usb_rx_callback_intf1(struct urb *urb)
break;
}
+out:
usb_submit_urb(ictx-rx_urb_intf1, GFP_ATOMIC);
}
@@ -2242,7 +2260,7 @@ find_endpoint_failed:
mutex_unlock(ictx-lock);
usb_free_urb(rx_urb);
rx_urb_alloc_failed:
- dev_err(ictx-dev, unable to initialize intf0, err %d\n, ret);
+ dev_err(ictx-dev, unable to initialize intf1, err %d\n, ret);
return NULL;
}
--
1.7.1
--
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 3/8] soc-camera: Add plane layout information to struct soc_mbus_pixelfmt
On Wed, 25 Jan 2012, Laurent Pinchart wrote: To compute the number of bytes per line according to the V4L2 specification, we need information about planes layout for planar formats. The new enum soc_mbus_layout convey that information. Maybe it is better to call that value not the number of bytes per line according to the V4L2 specification, but rather the value of the .bytesperline field? Also, conveys seems a better fit to me:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [PATCHv19 00/15] Contiguous Memory Allocator
On Thu, 26 Jan 2012 16:31:40 +0100, Arnd Bergmann a...@arndb.de wrote: I haven't followed the last two releases so closely. It seems that in v17 the movable pages with pending i/o was still a major problem but in v18 you added a solution. Is that right? What is still left to be done here then? In the current version, when allocation fails because of a page with pending I/O, CMA automatically tries allocation in another region. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo-- -- 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: [PATCHv19 00/15] Contiguous Memory Allocator
Hello, On Thursday, January 26, 2012 4:32 PM Arnd Bergmann wrote: On Thursday 26 January 2012, Marek Szyprowski wrote: Welcome everyone! Yes, that's true. This is yet another release of the Contiguous Memory Allocator patches. This version mainly includes code cleanups requested by Mel Gorman and a few minor bug fixes. Hi Marek, Thanks for keeping up this work! I really hope it works out for the next merge window. TODO (optional): - implement support for contiguous memory areas placed in HIGHMEM zone - resolve issue with movable pages with pending io operations Can you clarify these? I believe the contiguous memory areas in highmem is something that should really be after the existing code is merged into the upstream kernel and should better not be listed as TODO here. Ok, I will remove it from the TODO list. Core memory management is very little dependence on HIGHMEM, it is more about DMA-mapping framework to be aware that there might be no lowmem mappings for the allocated pages. This can be easily added once the initial version got merged. I haven't followed the last two releases so closely. It seems that in v17 the movable pages with pending i/o was still a major problem but in v18 you added a solution. Is that right? What is still left to be done here then? Since v18 the failed allocation is retried in a bit different place in the contiguous memory area what heavily increased overall reliability. This can be improved by making cma a bit more aware about pending io operations, but I want to leave this after the initial merge. I think that there are no major issues left to be resolved now. Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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 5/8] soc-camera: Add soc_mbus_image_size
On Wed, 25 Jan 2012, Laurent Pinchart wrote:
The function returns the minimum size of an image for a given number of
bytes per line (as per the V4L2 specification), width and format.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/soc_mediabus.c | 18 ++
include/media/soc_mediabus.h |2 ++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/soc_mediabus.c
b/drivers/media/video/soc_mediabus.c
index a707314..3f47774 100644
--- a/drivers/media/video/soc_mediabus.c
+++ b/drivers/media/video/soc_mediabus.c
@@ -397,6 +397,24 @@ s32 soc_mbus_bytes_per_line(u32 width, const struct
soc_mbus_pixelfmt *mf)
}
EXPORT_SYMBOL(soc_mbus_bytes_per_line);
+s32 soc_mbus_image_size(u32 bytes_per_line, u32 height,
+ const struct soc_mbus_pixelfmt *mf)
What do you think about making mf the first parameter? :-)
+{
+ if (mf-layout == SOC_MBUS_LAYOUT_PACKED)
+ return bytes_per_line * height;
+
+ switch (mf-packing) {
+ case SOC_MBUS_PACKING_2X8_PADHI:
+ case SOC_MBUS_PACKING_2X8_PADLO:
+ return bytes_per_line * height * 2;
+ case SOC_MBUS_PACKING_1_5X8:
+ return bytes_per_line * height * 3 / 2;
Hm, confused. Why have you decided to calculate the size based on packing
and not on layout?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 3/8] soc-camera: Add plane layout information to struct soc_mbus_pixelfmt
One more question:
On Wed, 25 Jan 2012, Laurent Pinchart wrote:
To compute the number of bytes per line according to the V4L2
specification, we need information about planes layout for planar
formats. The new enum soc_mbus_layout convey that information.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/atmel-isi.c|1 +
drivers/media/video/mx3_camera.c |2 +
drivers/media/video/omap1_camera.c |8 ++
drivers/media/video/pxa_camera.c |1 +
drivers/media/video/sh_mobile_ceu_camera.c |4 +++
drivers/media/video/soc_mediabus.c | 33
include/media/soc_mediabus.h | 19
7 files changed, 68 insertions(+), 0 deletions(-)
[snip]
diff --git a/include/media/soc_mediabus.h b/include/media/soc_mediabus.h
index 73f1e7e..18b0864 100644
--- a/include/media/soc_mediabus.h
+++ b/include/media/soc_mediabus.h
@@ -47,6 +47,24 @@ enum soc_mbus_order {
};
/**
+ * enum soc_mbus_layout - planes layout in memory
+ * @SOC_MBUS_LAYOUT_PACKED: color components packed
+ * @SOC_MBUS_LAYOUT_PLANAR_Y_U_V:YUV components stored in 3 planes
+ * @SOC_MBUS_LAYOUT_PLANAR_2Y_C: YUV components stored in a luma and a
+ * chroma plane (C plane is half the size
+ * of Y plane)
+ * @SOC_MBUS_LAYOUT_PLANAR_Y_C: YUV components stored in a luma
and a
+ * chroma plane (C plane is the same size
+ * as Y plane)
+ */
+enum soc_mbus_layout {
+ SOC_MBUS_LAYOUT_PACKED = 0,
+ SOC_MBUS_LAYOUT_PLANAR_Y_U_V,
Shouldn't we call this SOC_MBUS_LAYOUT_PLANAR_2Y_U_V?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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
DVB TS/PES filters
I could do with a little more information about DMX_SET_PES_FILTER. Specifically I want to use an output type of DMX_OUT_TS_TAP. I believe there's a limit on how many filters can be set, but I don't know whether the kernel imposes such a limit or whether it depends on the hardware, If the latter, how can I read the limit? I looked at the code for GStreamer's dvbsrc and that defines a limit of 32 filters. It also implies that using the magic number 8192 as the pid requests the entire stream. I can't find information about these things in the API docs. Is there somewhere I can get more details. If I ended up wanting enough pids to exceed the limit would it work to allow LIMIT - 1 individual pid filters to be set, then after that set one for 8192 instead and clear all the others? -- 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] imon: don't wedge hardware after early callbacks
This patch is just a minor update to one titled imon: Input from ffdc
device type ignored from Corinna Vinschen. An earlier patch to prevent
an oops when we got early callbacks also has the nasty side-effect of
wedging imon hardware, as we don't acknowledge the urb. Rework the check
slightly here to bypass processing the packet, as the driver isn't yet
fully initialized, but still acknowlege the urb and submit a new rx_urb.
Do this for both interfaces -- irrelevant for ffdc hardware, but
relevant for newer hardware, though newer hardware doesn't spew the
constant stream of data as soon as the hardware is initialized like the
older ffdc devices, so they'd be less likely to trigger this anyway...
Tested with both an ffdc device and an 0042 device.
v2: Per Corinna's suggestion and prior precedent, increment driver
version number so we can more easily tell if a user has this fix.
v3: cc stable, as this fixes a functional regression in 3.2
CC: sta...@vger.kernel.org
CC: Corinna Vinschen vinsc...@redhat.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/rc/imon.c | 26 ++
1 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 6ed9646..3f175eb 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -47,7 +47,7 @@
#define MOD_AUTHOR Jarod Wilson ja...@wilsonet.com
#define MOD_DESC Driver for SoundGraph iMON MultiMedia IR/Display
#define MOD_NAME imon
-#define MOD_VERSION0.9.3
+#define MOD_VERSION0.9.4
#define DISPLAY_MINOR_BASE 144
#define DEVICE_NAMElcd%d
@@ -1658,9 +1658,17 @@ static void usb_rx_callback_intf0(struct urb *urb)
return;
ictx = (struct imon_context *)urb-context;
- if (!ictx || !ictx-dev_present_intf0)
+ if (!ictx)
return;
+ /*
+* if we get a callback before we're done configuring the hardware, we
+* can't yet process the data, as there's nowhere to send it, but we
+* still need to submit a new rx URB to avoid wedging the hardware
+*/
+ if (!ictx-dev_present_intf0)
+ goto out;
+
switch (urb-status) {
case -ENOENT: /* usbcore unlink successful! */
return;
@@ -1678,6 +1686,7 @@ static void usb_rx_callback_intf0(struct urb *urb)
break;
}
+out:
usb_submit_urb(ictx-rx_urb_intf0, GFP_ATOMIC);
}
@@ -1690,9 +1699,17 @@ static void usb_rx_callback_intf1(struct urb *urb)
return;
ictx = (struct imon_context *)urb-context;
- if (!ictx || !ictx-dev_present_intf1)
+ if (!ictx)
return;
+ /*
+* if we get a callback before we're done configuring the hardware, we
+* can't yet process the data, as there's nowhere to send it, but we
+* still need to submit a new rx URB to avoid wedging the hardware
+*/
+ if (!ictx-dev_present_intf1)
+ goto out;
+
switch (urb-status) {
case -ENOENT: /* usbcore unlink successful! */
return;
@@ -1710,6 +1727,7 @@ static void usb_rx_callback_intf1(struct urb *urb)
break;
}
+out:
usb_submit_urb(ictx-rx_urb_intf1, GFP_ATOMIC);
}
@@ -2242,7 +2260,7 @@ find_endpoint_failed:
mutex_unlock(ictx-lock);
usb_free_urb(rx_urb);
rx_urb_alloc_failed:
- dev_err(ictx-dev, unable to initialize intf0, err %d\n, ret);
+ dev_err(ictx-dev, unable to initialize intf1, err %d\n, ret);
return NULL;
}
--
1.7.1
--
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/2] Import PCTV-80e Drivers from Devin Heitmueller's Repository
Em 21-01-2012 05:34, pdickeyb...@gmail.com escreveu: From: Patrick Dickey pdickeyb...@gmail.com This series of patches will import the drx39xxj(drx39xyj) drivers from Devin Heitmueller's HG Repository for the Pinnacle PCTV-80e USB Tuner. Patrick Dickey (2): import-pctv-80e-from-devin-heitmueller-hg-repository Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com Signed-off-by: Patrick Dickey pdickeyb...@gmail.com import-pctv-80e-from-devin-heitmueller-hg-repository Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com Signed-off-by: Patrick Dickey pdickeyb...@gmail.com Patch 0 never arrived. Is there a place where I could get it? If the patch is from some Devin's tree, maybe I can just get it there. Documentation/video4linux/CARDLIST.em28xx |1 + .../staging/media/dvb/frontends/drx39xyj/Kconfig |7 + .../staging/media/dvb/frontends/drx39xyj/Makefile |3 + .../media/dvb/frontends/drx39xyj/bsp_host.h| 80 + .../staging/media/dvb/frontends/drx39xyj/bsp_i2c.h | 217 + .../media/dvb/frontends/drx39xyj/bsp_tuner.h | 215 + .../media/dvb/frontends/drx39xyj/bsp_types.h | 229 + .../media/dvb/frontends/drx39xyj/drx39xxj.c| 457 + .../media/dvb/frontends/drx39xyj/drx39xxj.h| 40 + .../media/dvb/frontends/drx39xyj/drx39xxj_dummy.c | 134 + .../media/dvb/frontends/drx39xyj/drx_dap_fasi.c| 675 + .../media/dvb/frontends/drx39xyj/drx_dap_fasi.h| 268 + .../media/dvb/frontends/drx39xyj/drx_driver.c | 1600 ++ .../media/dvb/frontends/drx39xyj/drx_driver.h | 2588 +++ .../dvb/frontends/drx39xyj/drx_driver_version.h| 82 + .../staging/media/dvb/frontends/drx39xyj/drxj.c|16758 .../staging/media/dvb/frontends/drx39xyj/drxj.h| 730 + .../media/dvb/frontends/drx39xyj/drxj_map.h|15359 ++ .../staging/media/dvb/frontends/drx39xyj/drxj_mc.h | 3939 + .../media/dvb/frontends/drx39xyj/drxj_mc_vsb.h | 744 + .../media/dvb/frontends/drx39xyj/drxj_mc_vsbqam.h | 1437 ++ .../media/dvb/frontends/drx39xyj/drxj_options.h| 65 + 22 files changed, 45628 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/Kconfig create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/Makefile create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_host.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_i2c.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_tuner.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_types.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx39xxj.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx39xxj.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx39xxj_dummy.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_dap_fasi.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_dap_fasi.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_driver.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_driver.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_driver_version.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_map.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_mc.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_mc_vsb.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_mc_vsbqam.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_options.h -- 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/3] m88brs2000 DVB-S frontend and tuner module.
Em 22-01-2012 08:38, Malcolm Priestley escreveu:
Support for m88brs2000 chip used in lmedm04 driver.
Note there are still lock problems.
Slow channel change due to the large block of registers sent in set_frontend.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
...
+static int m88rs2000_set_property(struct dvb_frontend *fe,
+ struct dtv_property *p)
+{
+ dprintk(%s(..)\n, __func__);
+ return 0;
+}
+
+static int m88rs2000_get_property(struct dvb_frontend *fe,
+ struct dtv_property *p)
+{
+ dprintk(%s(..)\n, __func__);
+ return 0;
+}
...
Just don't implement set_property/get_property if you're not using them.
Except for that, the code looks ok on my eyes.
Regards,
Mauro
--
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: 290e locking issue
the behavior with the latest media_build.git is the same as that which was with fedora stock. the dmesg is inplug 290e [ 112.284350] usb 2-3: new high-speed USB device number 2 using ehci_hcd [ 112.399774] usb 2-3: New USB device found, idVendor=2013, idProduct=024f [ 112.399783] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 112.399790] usb 2-3: Product: PCTV 290e [ 112.399796] usb 2-3: Manufacturer: PCTV Systems [ 112.399802] usb 2-3: SerialNumber: 0006VEJQ [ 112.920507] em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0) [ 112.920515] em28xx: DVB interface 0 found [ 112.920647] em28xx #0: chip ID is em28174 [ 113.216668] em28xx #0: Identified as PCTV nanoStick T2 290e (card=78) [ 113.258309] Registered IR keymap rc-pinnacle-pctv-hd [ 113.258579] input: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb2/2-3/rc/rc1/input19 [ 113.259685] rc1: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb2/2-3/rc/rc1 [ 113.260303] em28xx #0: v4l2 driver version 0.1.3 [ 113.265485] em28xx #0: V4L2 video device registered as video1 [ 113.266619] usbcore: registered new interface driver em28xx [ 113.301706] WARNING: You are using an experimental version of the media stack. [ 113.301709] As the driver is backported to an older kernel, it doesn't offer [ 113.301710] enough quality for its usage in production. [ 113.301711] Use it with care. [ 113.301712] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 113.301713] 59b30294e14fa6a370fdd2bc2921cca1f977ef16 Merge branch 'v4l_for_linus' into staging/for_v3.4 [ 113.301714] 72565224609a23a60d10fcdf42f87a2fa8f7b16d [media] cxd2820r: sleep on DVB-T/T2 delivery system switch [ 113.301715] 46de20a78ae4b122b79fc02633e9a6c3d539ecad [media] anysee: fix CI init [ 113.382193] tda18271 17-0060: creating new instance [ 113.386895] TDA18271HD/C2 detected @ 17-0060 [ 113.629529] DVB: registering new adapter (em28xx #0) [ 113.629541] DVB: registering adapter 0 frontend 0 (Sony CXD2820R)... [ 113.632902] em28xx #0: Successfully loaded em28xx-dvb [ 113.632910] Em28xx: Initialized (Em28xx dvb Extension) extension inplug usb mem stick [ 152.204343] usb 2-1: new high-speed USB device number 3 using ehci_hcd [ 152.336629] usb 2-1: New USB device found, idVendor=0bda, idProduct=0120 [ 152.336639] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 152.336646] usb 2-1: Product: USB2.0-CRW [ 152.336652] usb 2-1: Manufacturer: Generic [ 152.336657] usb 2-1: SerialNumber: 2006041309210 [ 152.655077] Initializing USB Mass Storage driver... [ 152.655230] scsi6 : usb-storage 2-1:1.0 [ 152.655334] usbcore: registered new interface driver usb-storage [ 152.655336] USB Mass Storage support registered. [ 153.659503] scsi 6:0:0:0: Direct-Access Generic- Card Reader 1.00 PQ: 0 ANSI: 0 CCS [ 153.661960] sd 6:0:0:0: Attached scsi generic sg3 type 0 [ 154.551529] sd 6:0:0:0: [sdc] 15661056 512-byte logical blocks: (8.01 GB/7.46 GiB) [ 154.552415] sd 6:0:0:0: [sdc] Write Protect is off [ 154.552424] sd 6:0:0:0: [sdc] Mode Sense: 03 00 00 00 [ 154.553309] sd 6:0:0:0: [sdc] No Caching mode page present [ 154.553318] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 154.556786] sd 6:0:0:0: [sdc] No Caching mode page present [ 154.556793] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 154.557864] sdc: sdc1 mount usb mem stick sdc1 [ 184.838198] usb 2-1: reset high-speed USB device number 3 using ehci_hcd [ 184.959925] sd 6:0:0:0: [sdc] No Caching mode page present [ 184.959936] sd 6:0:0:0: [sdc] Assuming drive cache: write through [ 184.959944] sd 6:0:0:0: [sdc] Attached SCSI removable disk [ 215.878053] usb 2-1: reset high-speed USB device number 3 using ehci_hcd [ 215.998116] sd 6:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 215.998123] sd 6:0:0:0: [sdc] Sense Key : Illegal Request [current] [ 215.998128] sd 6:0:0:0: [sdc] Add. Sense: Logical block address out of range [ 215.998135] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 ee f7 80 00 00 08 00 [ 215.998147] end_request: I/O error, dev sdc, sector 15660928 [ 215.998152] Buffer I/O error on device sdc, logical block 1957616 [ 215.999614] sd 6:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 215.999619] sd 6:0:0:0: [sdc] Sense Key : Illegal Request [current] [ 215.999623] sd 6:0:0:0: [sdc] Add. Sense: Logical block address out of range [ 215.999629] sd 6:0:0:0: [sdc] CDB: Read(10): 28 00 00 ee f7 80 00 00 08 00 [ 215.999639] end_request: I/O error, dev sdc, sector 15660928 [ 215.999642] Buffer I/O error on device sdc, logical block 1957616 [ 216.000987] sd 6:0:0:0: [sdc] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 216.000992] sd 6:0:0:0: [sdc] Sense Key : Illegal Request [current] [ 216.000996] sd 6:0:0:0: [sdc] Add. Sense: Logical block address out of range [ 216.001045] sd 6:0:0:0: [sdc]
[PATCH 0/3] Updates to S5P-TV drivers
Hello Everyone, This patchset introduces SII9234 driver for MHL interface for latest Samsung boards from Exynos family. It also adds support for platform data in S5P-HDMI driver. Finally S5P-HDMI is integrated with SII9234. Regards, Tomasz Stanislawski Tomasz Stanislawski (3): v4l: s5p-tv: add sii9234 driver v4l: s5p-tv: hdmi: add support for platform data v4l: s5p-tv: hdmi: integrate with MHL drivers/media/video/s5p-tv/Kconfig | 10 + drivers/media/video/s5p-tv/Makefile |2 + drivers/media/video/s5p-tv/hdmi_drv.c| 86 -- drivers/media/video/s5p-tv/sii9234_drv.c | 432 ++ include/media/s5p_hdmi.h | 35 +++ include/media/sii9234.h | 24 ++ 6 files changed, 563 insertions(+), 26 deletions(-) create mode 100644 drivers/media/video/s5p-tv/sii9234_drv.c create mode 100644 include/media/s5p_hdmi.h create mode 100644 include/media/sii9234.h -- 1.7.5.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 2/3] v4l: s5p-tv: hdmi: add support for platform data
Moving configuration of s5p-hdmi peripherals from driver data to
platfrom data.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-tv/hdmi_drv.c | 38 ++--
include/media/s5p_hdmi.h | 35 ++
2 files changed, 52 insertions(+), 21 deletions(-)
create mode 100644 include/media/s5p_hdmi.h
diff --git a/drivers/media/video/s5p-tv/hdmi_drv.c
b/drivers/media/video/s5p-tv/hdmi_drv.c
index 8b41a04..ab3a2d3 100644
--- a/drivers/media/video/s5p-tv/hdmi_drv.c
+++ b/drivers/media/video/s5p-tv/hdmi_drv.c
@@ -30,6 +30,7 @@
#include linux/clk.h
#include linux/regulator/consumer.h
+#include media/s5p_hdmi.h
#include media/v4l2-common.h
#include media/v4l2-dev.h
#include media/v4l2-device.h
@@ -74,10 +75,6 @@ struct hdmi_device {
struct hdmi_resources res;
};
-struct hdmi_driver_data {
- int hdmiphy_bus;
-};
-
struct hdmi_tg_regs {
u8 cmd;
u8 h_fsz_l;
@@ -129,23 +126,11 @@ struct hdmi_preset_conf {
struct v4l2_mbus_framefmt mbus_fmt;
};
-/* I2C module and id for HDMIPHY */
-static struct i2c_board_info hdmiphy_info = {
- I2C_BOARD_INFO(hdmiphy, 0x38),
-};
-
-static struct hdmi_driver_data hdmi_driver_data[] = {
- { .hdmiphy_bus = 3 },
- { .hdmiphy_bus = 8 },
-};
-
static struct platform_device_id hdmi_driver_types[] = {
{
.name = s5pv210-hdmi,
- .driver_data= (unsigned long)hdmi_driver_data[0],
}, {
.name = exynos4-hdmi,
- .driver_data= (unsigned long)hdmi_driver_data[1],
}, {
/* end node */
}
@@ -870,11 +855,17 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
struct i2c_adapter *phy_adapter;
struct v4l2_subdev *sd;
struct hdmi_device *hdmi_dev = NULL;
- struct hdmi_driver_data *drv_data;
+ struct s5p_hdmi_platform_data *pdata = dev-platform_data;
int ret;
dev_dbg(dev, probe start\n);
+ if (!pdata) {
+ dev_err(dev, platform data is missing\n);
+ ret = -ENODEV;
+ goto fail;
+ }
+
hdmi_dev = kzalloc(sizeof(*hdmi_dev), GFP_KERNEL);
if (!hdmi_dev) {
dev_err(dev, out of memory\n);
@@ -927,9 +918,14 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
goto fail_irq;
}
- drv_data = (struct hdmi_driver_data *)
- platform_get_device_id(pdev)-driver_data;
- phy_adapter = i2c_get_adapter(drv_data-hdmiphy_bus);
+ /* testing if hdmiphy info is present */
+ if (!pdata-hdmiphy_info) {
+ dev_err(dev, hdmiphy info is missing in platform data\n);
+ ret = -ENXIO;
+ goto fail_vdev;
+ }
+
+ phy_adapter = i2c_get_adapter(pdata-hdmiphy_bus);
if (phy_adapter == NULL) {
dev_err(dev, adapter request failed\n);
ret = -ENXIO;
@@ -937,7 +933,7 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
}
hdmi_dev-phy_sd = v4l2_i2c_new_subdev_board(hdmi_dev-v4l2_dev,
- phy_adapter, hdmiphy_info, NULL);
+ phy_adapter, pdata-hdmiphy_info, NULL);
/* on failure or not adapter is no longer useful */
i2c_put_adapter(phy_adapter);
if (hdmi_dev-phy_sd == NULL) {
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
new file mode 100644
index 000..361a751
--- /dev/null
+++ b/include/media/s5p_hdmi.h
@@ -0,0 +1,35 @@
+/*
+ * Driver header for S5P HDMI chip.
+ *
+ * Copyright (c) 2011 Samsung Electronics, Co. Ltd
+ * Contact: Tomasz Stanislawski t.stanisl...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef S5P_HDMI_H
+#define S5P_HDMI_H
+
+struct i2c_board_info;
+
+/**
+ * @hdmiphy_bus: controller id for HDMIPHY bus
+ * @hdmiphy_info: template for HDMIPHY I2C device
+ * @mhl_bus: controller id for MHL control bus
+ * @mhl_info: template for MHL I2C device
+ *
+ * NULL pointer for *_info fields indicates that
+ * the corresponding chip is not present
+ */
+struct s5p_hdmi_platform_data {
+ int hdmiphy_bus;
+ struct i2c_board_info *hdmiphy_info;
+ int mhl_bus;
+ struct i2c_board_info *mhl_info;
+};
+
+#endif /* S5P_HDMI_H */
+
--
1.7.5.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 3/3] v4l: s5p-tv: hdmi: integrate with MHL
Adding support for using MHL (SiI9234 or other) chip if its configuration was
passed to HDMI by platfrom data.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-tv/hdmi_drv.c | 52
1 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/s5p-tv/hdmi_drv.c
b/drivers/media/video/s5p-tv/hdmi_drv.c
index ab3a2d3..ddb9fb6 100644
--- a/drivers/media/video/s5p-tv/hdmi_drv.c
+++ b/drivers/media/video/s5p-tv/hdmi_drv.c
@@ -67,6 +67,8 @@ struct hdmi_device {
struct v4l2_device v4l2_dev;
/** subdev of HDMIPHY interface */
struct v4l2_subdev *phy_sd;
+ /** subdev of MHL interface */
+ struct v4l2_subdev *mhl_sd;
/** configuration of current graphic mode */
const struct hdmi_preset_conf *cur_conf;
/** current preset */
@@ -572,7 +574,15 @@ static int hdmi_streamon(struct hdmi_device *hdev)
if (tries == 0) {
dev_err(dev, hdmiphy's pll could not reach steady state.\n);
v4l2_subdev_call(hdev-phy_sd, video, s_stream, 0);
- hdmi_dumpregs(hdev, s_stream);
+ hdmi_dumpregs(hdev, hdmiphy - s_stream);
+ return -EIO;
+ }
+
+ /* starting MHL */
+ ret = v4l2_subdev_call(hdev-mhl_sd, video, s_stream, 1);
+ if (hdev-mhl_sd ret) {
+ v4l2_subdev_call(hdev-phy_sd, video, s_stream, 0);
+ hdmi_dumpregs(hdev, mhl - s_stream);
return -EIO;
}
@@ -603,6 +613,7 @@ static int hdmi_streamoff(struct hdmi_device *hdev)
clk_set_parent(res-sclk_hdmi, res-sclk_pixel);
clk_enable(res-sclk_hdmi);
+ v4l2_subdev_call(hdev-mhl_sd, video, s_stream, 0);
v4l2_subdev_call(hdev-phy_sd, video, s_stream, 0);
hdmi_dumpregs(hdev, streamoff);
@@ -724,6 +735,7 @@ static int hdmi_runtime_suspend(struct device *dev)
struct hdmi_device *hdev = sd_to_hdmi_dev(sd);
dev_dbg(dev, %s\n, __func__);
+ v4l2_subdev_call(hdev-mhl_sd, core, s_power, 0);
hdmi_resource_poweroff(hdev-res);
return 0;
}
@@ -742,6 +754,11 @@ static int hdmi_runtime_resume(struct device *dev)
if (ret)
goto fail;
+ /* starting MHL */
+ ret = v4l2_subdev_call(hdev-mhl_sd, core, s_power, 1);
+ if (hdev-mhl_sd ret)
+ goto fail;
+
dev_dbg(dev, poweron succeed\n);
return 0;
@@ -852,7 +869,7 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
{
struct device *dev = pdev-dev;
struct resource *res;
- struct i2c_adapter *phy_adapter;
+ struct i2c_adapter *adapter;
struct v4l2_subdev *sd;
struct hdmi_device *hdmi_dev = NULL;
struct s5p_hdmi_platform_data *pdata = dev-platform_data;
@@ -925,23 +942,44 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
goto fail_vdev;
}
- phy_adapter = i2c_get_adapter(pdata-hdmiphy_bus);
- if (phy_adapter == NULL) {
- dev_err(dev, adapter request failed\n);
+ adapter = i2c_get_adapter(pdata-hdmiphy_bus);
+ if (adapter == NULL) {
+ dev_err(dev, hdmiphy adapter request failed\n);
ret = -ENXIO;
goto fail_vdev;
}
hdmi_dev-phy_sd = v4l2_i2c_new_subdev_board(hdmi_dev-v4l2_dev,
- phy_adapter, pdata-hdmiphy_info, NULL);
+ adapter, pdata-hdmiphy_info, NULL);
/* on failure or not adapter is no longer useful */
- i2c_put_adapter(phy_adapter);
+ i2c_put_adapter(adapter);
if (hdmi_dev-phy_sd == NULL) {
dev_err(dev, missing subdev for hdmiphy\n);
ret = -ENODEV;
goto fail_vdev;
}
+ /* initialization of MHL interface if present */
+ if (pdata-mhl_info) {
+ adapter = i2c_get_adapter(pdata-mhl_bus);
+ if (adapter == NULL) {
+ dev_err(dev, MHL adapter request failed\n);
+ ret = -ENXIO;
+ goto fail_vdev;
+ }
+
+ hdmi_dev-mhl_sd = v4l2_i2c_new_subdev_board(
+ hdmi_dev-v4l2_dev, adapter,
+ pdata-mhl_info, NULL);
+ /* on failure or not adapter is no longer useful */
+ i2c_put_adapter(adapter);
+ if (hdmi_dev-mhl_sd == NULL) {
+ dev_err(dev, missing subdev for MHL\n);
+ ret = -ENODEV;
+ goto fail_vdev;
+ }
+ }
+
clk_enable(hdmi_dev-res.hdmi);
pm_runtime_enable(dev);
--
1.7.5.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
[PATCH 1/3] v4l: s5p-tv: add sii9234 driver
SiI9234 is a converter of HDMI signal into MHL. The chip is present on some
boards from Samsung S5P family. The chip's configuration procedure is based on
MHD_SiI9234 driver created by doonsoo45.kim.
The driver is using:
- i2c framework
- v4l2 framework
- runtime PM
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-tv/Kconfig | 10 +
drivers/media/video/s5p-tv/Makefile |2 +
drivers/media/video/s5p-tv/sii9234_drv.c | 432 ++
include/media/sii9234.h | 24 ++
4 files changed, 468 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/s5p-tv/sii9234_drv.c
create mode 100644 include/media/sii9234.h
diff --git a/drivers/media/video/s5p-tv/Kconfig
b/drivers/media/video/s5p-tv/Kconfig
index f2a0977..f248b28 100644
--- a/drivers/media/video/s5p-tv/Kconfig
+++ b/drivers/media/video/s5p-tv/Kconfig
@@ -46,6 +46,16 @@ config VIDEO_SAMSUNG_S5P_HDMIPHY
as module. It is an I2C driver, that exposes a V4L2
subdev for use by other drivers.
+config VIDEO_SAMSUNG_S5P_SII9234
+ tristate Samsung SII9234 Driver
+ depends on VIDEO_DEV VIDEO_V4L2 I2C
+ depends on VIDEO_SAMSUNG_S5P_TV
+ help
+ Say Y here if you want support for the MHL interface
+ in S5P Samsung SoC. The driver can be compiled
+ as module. It is an I2C driver, that exposes a V4L2
+ subdev for use by other drivers.
+
config VIDEO_SAMSUNG_S5P_SDO
tristate Samsung Analog TV Driver
depends on VIDEO_DEV VIDEO_V4L2
diff --git a/drivers/media/video/s5p-tv/Makefile
b/drivers/media/video/s5p-tv/Makefile
index 37e4c17..f49e756 100644
--- a/drivers/media/video/s5p-tv/Makefile
+++ b/drivers/media/video/s5p-tv/Makefile
@@ -8,6 +8,8 @@
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_HDMIPHY) += s5p-hdmiphy.o
s5p-hdmiphy-y += hdmiphy_drv.o
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_SII9234) += s5p-sii9234.o
+s5p-sii9234-y += sii9234_drv.o
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_HDMI) += s5p-hdmi.o
s5p-hdmi-y += hdmi_drv.o
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_SDO) += s5p-sdo.o
diff --git a/drivers/media/video/s5p-tv/sii9234_drv.c
b/drivers/media/video/s5p-tv/sii9234_drv.c
new file mode 100644
index 000..0f31ecc
--- /dev/null
+++ b/drivers/media/video/s5p-tv/sii9234_drv.c
@@ -0,0 +1,432 @@
+/*
+ * Samsung MHL interface driver
+ *
+ * Copyright (C) 2011 Samsung Electronics Co.Ltd
+ * Author: Tomasz Stanislawski t.stanisl...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/delay.h
+#include linux/err.h
+#include linux/freezer.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/kthread.h
+#include linux/module.h
+#include linux/pm_runtime.h
+#include linux/regulator/machine.h
+#include linux/slab.h
+
+#include mach/gpio.h
+#include plat/gpio-cfg.h
+
+#include media/sii9234.h
+#include media/v4l2-subdev.h
+
+MODULE_AUTHOR(Tomasz Stanislawski t.stanisl...@samsung.com);
+MODULE_DESCRIPTION(Samsung MHL interface driver);
+MODULE_LICENSE(GPL);
+
+struct sii9234_context {
+ struct i2c_client *client;
+ struct regulator *power;
+ int gpio_n_reset;
+ struct v4l2_subdev sd;
+};
+
+static inline struct sii9234_context *sd_to_context(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct sii9234_context, sd);
+}
+
+static inline int sii9234_readb(struct i2c_client *client, int addr)
+{
+ return i2c_smbus_read_byte_data(client, addr);
+}
+
+static inline int sii9234_writeb(struct i2c_client *client, int addr, int
value)
+{
+ return i2c_smbus_write_byte_data(client, addr, value);
+}
+
+static inline int sii9234_writeb_mask(struct i2c_client *client, int addr,
+ int value, int mask)
+{
+ int ret;
+
+ ret = i2c_smbus_read_byte_data(client, addr);
+ if (ret 0)
+ return ret;
+ ret = (ret ~mask) | (value mask);
+ return i2c_smbus_write_byte_data(client, addr, ret);
+}
+
+static inline int sii9234_readb_idx(struct i2c_client *client, int addr)
+{
+ int ret;
+ ret = i2c_smbus_write_byte_data(client, 0xbc, addr 8);
+ if (ret 0)
+ return ret;
+ ret = i2c_smbus_write_byte_data(client, 0xbd, addr 0xff);
+ if (ret 0)
+ return ret;
+ return i2c_smbus_read_byte_data(client, 0xbe);
+}
+
+static inline int sii9234_writeb_idx(struct i2c_client *client, int addr,
+ int value)
+{
+ int ret;
+ ret = i2c_smbus_write_byte_data(client, 0xbc, addr 8);
+ if (ret 0)
+ return ret;
+ ret = i2c_smbus_write_byte_data(client, 0xbd, addr 0xff);
+ if (ret 0)
+
Re: 290e locking issue
On 01/26/2012 07:09 PM, Claus Olesen wrote: the behavior with the latest media_build.git is the same as that which was with fedora stock. After all I am almost 100% sure it is em28xx (USB-interface driver used) or/and USB-bus related issue. Likely it will happen for other em28xx devices too. But as I do not have enough knowledge about that area I cannot do much for fixing it. Maybe it is better try to avoid using those devices same time and try use USB-hub, other USB-port, add new USB-controller, etc... 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 5/8] soc-camera: Add soc_mbus_image_size
Hi Guennadi,
On Thursday 26 January 2012 16:59:23 Guennadi Liakhovetski wrote:
On Wed, 25 Jan 2012, Laurent Pinchart wrote:
The function returns the minimum size of an image for a given number of
bytes per line (as per the V4L2 specification), width and format.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/soc_mediabus.c | 18 ++
include/media/soc_mediabus.h |2 ++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/soc_mediabus.c
b/drivers/media/video/soc_mediabus.c index a707314..3f47774 100644
--- a/drivers/media/video/soc_mediabus.c
+++ b/drivers/media/video/soc_mediabus.c
@@ -397,6 +397,24 @@ s32 soc_mbus_bytes_per_line(u32 width, const struct
soc_mbus_pixelfmt *mf)
}
EXPORT_SYMBOL(soc_mbus_bytes_per_line);
+s32 soc_mbus_image_size(u32 bytes_per_line, u32 height,
+ const struct soc_mbus_pixelfmt *mf)
What do you think about making mf the first parameter? :-)
I copied the parameters order from soc_mbus_bytes_per_line(). I like having
the format first, so I'll change that for soc_mbus_image_size().
+{
+ if (mf-layout == SOC_MBUS_LAYOUT_PACKED)
+ return bytes_per_line * height;
+
+ switch (mf-packing) {
+ case SOC_MBUS_PACKING_2X8_PADHI:
+ case SOC_MBUS_PACKING_2X8_PADLO:
+ return bytes_per_line * height * 2;
+ case SOC_MBUS_PACKING_1_5X8:
+ return bytes_per_line * height * 3 / 2;
Hm, confused. Why have you decided to calculate the size based on packing
and not on layout?
Because planar YUV 4:2:0, 4:2:2 and 4:4:4 formats would all use
SOC_MBUS_LAYOUT_Y_U_V. I could create SOC_MBUS_LAYOUT_2Y_U_V and
SOC_MBUS_LAYOUT_4Y_U_V instead. As existing planar formats all have a
bits_per_sample value of 8, mf-packing was already used by
soc_mbus_bytes_per_line() (before my patches) to compute the total line size
in bytes, so I thought it made sense to reuse it in soc_mbus_image_size().
--
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
[GIT PULL for v3.3-rc2] media fixes
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus From a couple DVB driver fixes at anysee driver and cynergyT2, and a V4L driver fix at atmel-isi. Thanks! Mauro - Latest commit at the branch: c79eba92406acc4898adcd1689fc21a6aa91ed0b [media] cinergyT2-fe: Fix bandwdith settings The following changes since commit 36be126cb0ebe3000a65c1049f339a3e882a9a47: [media] as3645a: Fix compilation by including slab.h (2012-01-17 23:07:13 -0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus Antti Palosaari (4): [media] cxd2820r: fix dvb_frontend_ops [media] cxd2820r: remove unused parameter from cxd2820r_attach [media] anysee: fix CI init [media] cxd2820r: sleep on DVB-T/T2 delivery system switch Josh Wu (1): [media] V4L: atmel-isi: add clk_prepare()/clk_unprepare() functions Mauro Carvalho Chehab (1): [media] cinergyT2-fe: Fix bandwdith settings drivers/media/dvb/dvb-usb/anysee.c | 11 +-- drivers/media/dvb/dvb-usb/cinergyT2-fe.c|7 --- drivers/media/dvb/frontends/cxd2820r.h |6 ++ drivers/media/dvb/frontends/cxd2820r_core.c | 20 +++- drivers/media/video/atmel-isi.c | 14 ++ drivers/media/video/em28xx/em28xx-dvb.c |3 +-- 6 files changed, 45 insertions(+), 16 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
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:Thu Jan 26 19:00:16 CET 2012 git hash:59b30294e14fa6a370fdd2bc2921cca1f977ef16 gcc version: i686-linux-gcc (GCC) 4.6.2 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS 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-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS 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 linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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: [PATCH 3/8] soc-camera: Add plane layout information to struct soc_mbus_pixelfmt
Hi Guennadi, On Thursday 26 January 2012 16:38:31 Guennadi Liakhovetski wrote: On Wed, 25 Jan 2012, Laurent Pinchart wrote: To compute the number of bytes per line according to the V4L2 specification, we need information about planes layout for planar formats. The new enum soc_mbus_layout convey that information. Maybe it is better to call that value not the number of bytes per line according to the V4L2 specification, but rather the value of the .bytesperline field? Also, conveys seems a better fit to me:-) OK. I'll change that. -- 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 3/8] soc-camera: Add plane layout information to struct soc_mbus_pixelfmt
Hi Guennadi,
On Thursday 26 January 2012 17:01:15 Guennadi Liakhovetski wrote:
One more question:
On Wed, 25 Jan 2012, Laurent Pinchart wrote:
To compute the number of bytes per line according to the V4L2
specification, we need information about planes layout for planar
formats. The new enum soc_mbus_layout convey that information.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/atmel-isi.c|1 +
drivers/media/video/mx3_camera.c |2 +
drivers/media/video/omap1_camera.c |8 ++
drivers/media/video/pxa_camera.c |1 +
drivers/media/video/sh_mobile_ceu_camera.c |4 +++
drivers/media/video/soc_mediabus.c | 33
include/media/soc_mediabus.h
| 19 7 files changed, 68 insertions(+), 0
deletions(-)
[snip]
diff --git a/include/media/soc_mediabus.h b/include/media/soc_mediabus.h
index 73f1e7e..18b0864 100644
--- a/include/media/soc_mediabus.h
+++ b/include/media/soc_mediabus.h
@@ -47,6 +47,24 @@ enum soc_mbus_order {
};
/**
+ * enum soc_mbus_layout - planes layout in memory
+ * @SOC_MBUS_LAYOUT_PACKED:color components packed
+ * @SOC_MBUS_LAYOUT_PLANAR_Y_U_V: YUV components stored in 3 planes
+ * @SOC_MBUS_LAYOUT_PLANAR_2Y_C: YUV components stored in a luma and a
+ * chroma plane (C plane is half the size
+ * of Y plane)
+ * @SOC_MBUS_LAYOUT_PLANAR_Y_C:YUV components stored in a luma
and a
+ * chroma plane (C plane is the same size
+ * as Y plane)
+ */
+enum soc_mbus_layout {
+ SOC_MBUS_LAYOUT_PACKED = 0,
+ SOC_MBUS_LAYOUT_PLANAR_Y_U_V,
Shouldn't we call this SOC_MBUS_LAYOUT_PLANAR_2Y_U_V?
I'll change that.
--
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: 290e locking issue
I just came to think of my old 800e because also it is a em28xx device and for what it is worth I just tried it and it does not exhibit the issue. it's dmesg is inplug 800e [ 179.499370] usb 2-4: new high-speed USB device number 2 using ehci_hcd [ 179.622477] usb 2-4: New USB device found, idVendor=2304, idProduct=0227 [ 179.622486] usb 2-4: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [ 179.622494] usb 2-4: Product: PCTV 800e [ 179.622500] usb 2-4: Manufacturer: Pinnacle Systems [ 179.622505] usb 2-4: SerialNumber: 061101051592 [ 179.915633] em28xx: New device Pinnacle Systems PCTV 800e @ 480 Mbps (2304:0227, interface 0, class 0) [ 179.915636] em28xx: Audio Vendor Class interface 0 found [ 179.915638] em28xx: Video interface 0 found [ 179.915639] em28xx: DVB interface 0 found [ 179.915749] em28xx #0: chip ID is em2882/em2883 [ 180.058726] em28xx #0: i2c eeprom 00: 1a eb 67 95 04 23 27 02 d0 12 5c 03 8e 16 a4 1c [ 180.058753] em28xx #0: i2c eeprom 10: 6a 24 27 57 46 07 01 00 00 00 00 00 00 00 00 00 [ 180.058775] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00 00 00 5b 1c 00 00 [ 180.058798] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [ 180.058820] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 180.058841] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 180.058862] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 24 03 50 00 69 00 [ 180.058884] em28xx #0: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 00 53 00 [ 180.058906] em28xx #0: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00 73 00 00 00 16 03 [ 180.058928] em28xx #0: i2c eeprom 90: 50 00 43 00 54 00 56 00 20 00 38 00 30 00 30 00 [ 180.058950] em28xx #0: i2c eeprom a0: 65 00 00 00 1c 03 30 00 36 00 31 00 31 00 30 00 [ 180.058972] em28xx #0: i2c eeprom b0: 31 00 30 00 35 00 31 00 35 00 39 00 32 00 00 00 [ 180.058994] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 180.059079] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 180.059125] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 180.059170] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 180.059219] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xd2e5aebf [ 180.059226] em28xx #0: EEPROM info: [ 180.059232] em28xx #0: AC97 audio (5 sample rates) [ 180.059239] em28xx #0: 500mA max power [ 180.059247] em28xx #0: Table at 0x27, strings=0x168e, 0x1ca4, 0x246a [ 180.060458] em28xx #0: Identified as Pinnacle PCTV HD Pro Stick (card=17) [ 180.091733] tvp5150 17-005c: chip found @ 0xb8 (em28xx #0) [ 180.140502] tvp5150 17-005c: tvp5150am1 detected. [ 180.147912] i2c-core: driver [tuner] using legacy suspend method [ 180.147919] i2c-core: driver [tuner] using legacy resume method [ 180.151227] tuner 17-0061: Tuner -1 found with type(s) Radio TV. [ 180.169032] xc2028 17-0061: creating new instance [ 180.169041] xc2028 17-0061: type set to XCeive xc2028/xc3028 tuner [ 180.174254] xc2028 17-0061: Error: firmware xc3028-v27.fw not found. [ 180.199094] Registered IR keymap rc-pinnacle-pctv-hd [ 180.199334] input: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb2/2-4/rc/rc1/input19 [ 180.200463] rc1: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb2/2-4/rc/rc1 [ 180.200895] em28xx #0: Config register raw data: 0xd0 [ 180.202271] em28xx #0: AC97 vendor ID = 0x [ 180.202640] em28xx #0: AC97 features = 0x6a90 [ 180.202644] em28xx #0: Empia 202 AC97 audio processor detected [ 180.366381] em28xx #0: v4l2 driver version 0.1.3 [ 180.371937] xc2028 17-0061: Error: firmware xc3028-v27.fw not found. [ 180.441716] em28xx #0: V4L2 video device registered as video1 [ 180.441723] em28xx #0: V4L2 VBI device registered as vbi0 [ 180.444325] usbcore: registered new interface driver em28xx [ 180.469757] em28xx-audio.c: probing for em28xx Audio Vendor Class [ 180.469760] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 180.469761] em28xx-audio.c: Copyright (C) 2007-2011 Mauro Carvalho Chehab [ 180.470139] Em28xx: Initialized (Em28xx Audio Extension) extension [ 180.473969] WARNING: You are using an experimental version of the media stack. [ 180.473971] As the driver is backported to an older kernel, it doesn't offer [ 180.473972] enough quality for its usage in production. [ 180.473973] Use it with care. [ 180.473973] Latest git patches (needed if you report a bug to linux-media@vger.kernel.org): [ 180.473975] 59b30294e14fa6a370fdd2bc2921cca1f977ef16 Merge branch 'v4l_for_linus' into staging/for_v3.4 [ 180.473976] 72565224609a23a60d10fcdf42f87a2fa8f7b16d [media] cxd2820r: sleep on DVB-T/T2 delivery system switch [ 180.473977] 46de20a78ae4b122b79fc02633e9a6c3d539ecad [media] anysee: fix CI init [ 180.669893] xc2028 17-0061: attaching existing instance [ 180.669901] xc2028
Re: [PATCH 1/8] soc_camera: Use soc_camera_device::sizeimage to compute buffer sizes
Hi Guennadi,
On Thursday 26 January 2012 16:21:00 Guennadi Liakhovetski wrote:
Hi Laurent
Thanks for the patches. This one looks good mostly, a couple of questions
though:
On Wed, 25 Jan 2012, Laurent Pinchart wrote:
Instead of computing the buffer size manually in the videobuf queue
setup and buffer prepare callbacks, use the previously negotiated
soc_camera_device::sizeimage value.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/atmel-isi.c| 17 +++--
drivers/media/video/mx1_camera.c | 14 ++
drivers/media/video/mx2_camera.c | 14 ++
drivers/media/video/mx3_camera.c | 20 +---
drivers/media/video/omap1_camera.c | 14 ++
drivers/media/video/pxa_camera.c | 14 ++
drivers/media/video/sh_mobile_ceu_camera.c | 25
+ 7 files changed, 29 insertions(+), 89
deletions(-)
[snip]
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c index a803d9e..e9b228d 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -433,15 +433,10 @@ static int mx2_videobuf_setup(struct videobuf_queue
*vq, unsigned int *count,
unsigned int *size)
{
struct soc_camera_device *icd = vq-priv_data;
- int bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
- icd-current_fmt-host_fmt);
dev_dbg(icd-parent, count=%d, size=%d\n, *count, *size);
- if (bytes_per_line 0)
- return bytes_per_line;
-
- *size = bytes_per_line * icd-user_height;
+ *size = icd-sizeimage;
if (0 == *count)
*count = 32;
I think, there is a bug in mx2_camera_try_fmt(), which also would affect
these your calculations. On i.MX25 they restrict the image size based on
maximum supported number of bytes. In such a case they recalculate
.bytesperline, but they fail to update .sizeimage. The fix seems to be
trivial, please add it, then your calculations should be fine.
Indeed. I'll add a patch for that, and I'll also modify mx2_camera_try_fmt()
to use the new soc_mbus_image_size() function.
@@ -476,16 +471,11 @@ static int mx2_videobuf_prepare(struct
videobuf_queue *vq,
{
struct soc_camera_device *icd = vq-priv_data;
struct mx2_buffer *buf = container_of(vb, struct mx2_buffer, vb);
- int bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
- icd-current_fmt-host_fmt);
int ret = 0;
dev_dbg(icd-parent, %s (vb=0x%p) 0x%08lx %d\n, __func__,
vb, vb-baddr, vb-bsize);
- if (bytes_per_line 0)
- return bytes_per_line;
-
#ifdef DEBUG
/*
* This can be useful if you want to see if we actually fill
@@ -505,7 +495,7 @@ static int mx2_videobuf_prepare(struct videobuf_queue
*vq,
vb-state = VIDEOBUF_NEEDS_INIT;
}
- vb-size = bytes_per_line * vb-height;
+ vb-size = icd-sizeimage;
if (vb-baddr vb-bsize vb-size) {
ret = -EINVAL;
goto out;
diff --git a/drivers/media/video/mx3_camera.c
b/drivers/media/video/mx3_camera.c index f96f92f..da45a89 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -199,8 +199,6 @@ static int mx3_videobuf_setup(struct vb2_queue *vq,
struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
struct mx3_camera_dev *mx3_cam = ici-priv;
- int bytes_per_line;
- unsigned int height;
if (!mx3_cam-idmac_channel[0])
return -EINVAL;
@@ -208,21 +206,21 @@ static int mx3_videobuf_setup(struct vb2_queue *vq,
if (fmt) {
const struct soc_camera_format_xlate *xlate =
soc_camera_xlate_by_fourcc(icd,
fmt-fmt.pix.pixelformat);
+ int bytes_per_line;
+
if (!xlate)
return -EINVAL;
+
bytes_per_line = soc_mbus_bytes_per_line(fmt-fmt.pix.width,
xlate-host_fmt);
- height = fmt-fmt.pix.height;
+ if (bytes_per_line 0)
+ return bytes_per_line;
+
+ sizes[0] = bytes_per_line * fmt-fmt.pix.height;
} else {
/* Called from VIDIOC_REQBUFS or in compatibility mode */
- bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
- icd-current_fmt-host_fmt);
- height =
Re: [PATCH v2 06/11] v4l: Add support for omap4iss driver
Hi Sergio,
Aguirre, Sergio wrote:
On Wed, Nov 30, 2011 at 06:14:55PM -0600, Sergio Aguirre wrote:
...
+/*
+ * iss_save_ctx - Saves ISS context.
+ * @iss: OMAP4 ISS device
+ *
+ * Routine for saving the context of each module in the ISS.
+ */
+static void iss_save_ctx(struct iss_device *iss)
+{
+ iss_save_context(iss, iss_reg_list);
+}
Do you really, really need to save context related data? Couldn't you
initialise the device the usual way when e.g. returning from suspended
state?
I'll actually have to revisit this more carefuly. I haven't really
tested Runtime PM on this.
I think I'll remove this for now, until i come up with something better.
Usually it's best to recreate the configuration the same way the driver did
it in the first place. Some registers have side effects so that restoring
them requires extra care.
+/*
+ * iss_restore_ctx - Restores ISS context.
+ * @iss: OMAP4 ISS device
+ *
+ * Routine for restoring the context of each module in the ISS.
+ */
+static void iss_restore_ctx(struct iss_device *iss)
+{
+ iss_restore_context(iss, iss_reg_list);
+}
+
...
+/*
+ * csi2_irq_ctx_set - Enables CSI2 Context IRQs.
+ * @enable: Enable/disable CSI2 Context interrupts
+ */
+static void csi2_irq_ctx_set(struct iss_csi2_device *csi2, int enable)
+{
+ u32 reg = CSI2_CTX_IRQ_FE;
+ int i;
+
+ if (csi2-use_fs_irq)
+ reg |= CSI2_CTX_IRQ_FS;
+
+ for (i = 0; i 8; i++) {
8 == number of contexts?
Yes. This loops from 0 to 7.
Are you implying that I need to add a define to this?
I think something that tells it is the number of contexts would be nicer.
...
+ writel(readl(csi2-regs1 + CSI2_SYSCONFIG) |
+ CSI2_SYSCONFIG_SOFT_RESET,
+ csi2-regs1 + CSI2_SYSCONFIG);
+
+ do {
+ reg = readl(csi2-regs1 + CSI2_SYSSTATUS)
+ CSI2_SYSSTATUS_RESET_DONE;
+ if (reg == CSI2_SYSSTATUS_RESET_DONE)
+ break;
+ soft_reset_retries++;
+ if (soft_reset_retries 5)
+ udelay(100);
How about usleep_range() here? Or omit such a long busyloop. Hardware
typically resets quite fast.
I guess i'll try to fine-tune this then.
I think it's fine to replace it with usleep_range() for now. Fine
optimisations can be left for later if really needed.
...
+static void csi2_print_status(struct iss_csi2_device *csi2)
+{
+ struct iss_device *iss = csi2-iss;
+
+ if (!csi2-available)
+ return;
+
+ dev_dbg(iss-dev, -CSI2 Register dump-\n);
+
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, SYSCONFIG);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, SYSSTATUS);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, IRQENABLE);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, IRQSTATUS);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTRL);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, DBG_H);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, COMPLEXIO_CFG);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, COMPLEXIO_IRQSTATUS);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, SHORT_PACKET);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, COMPLEXIO_IRQENABLE);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, DBG_P);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, TIMING);
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_CTRL1(0));
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_CTRL2(0));
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_DAT_OFST(0));
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_PING_ADDR(0));
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_PONG_ADDR(0));
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_IRQENABLE(0));
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_IRQSTATUS(0));
+ CSI2_PRINT_REGISTER(iss, csi2-regs1, CTX_CTRL3(0));
+
+ dev_dbg(iss-dev, \n);
_If_ this is user-triggered, you might want to consider using debugfs for
the same. Just FYI.
Ok. I'll see what can I do.
Just FYI. :-) Thinking about this agian, debugfs might not go well with this
since the prints may be triggered by the driver.
...
+ /* Skip interrupts until we reach the frame skip count. The CSI2 will be
+ * automatically disabled, as the frame skip count has been programmed
+ * in the CSI2_CTx_CTRL1::COUNT field, so reenable it.
+ *
+ * It would have been nice to rely on the FRAME_NUMBER interrupt instead
+ * but it turned out that the interrupt is only generated when the CSI2
+ * writes to memory (the CSI2_CTx_CTRL1::COUNT field is decreased
+ * correctly and reaches 0 when data is forwarded to the video port only
+ * but no interrupt arrives). Maybe a CSI2 hardware bug.
+ */
+ if (csi2-frame_skip) {
+ csi2-frame_skip--;
+ if (csi2-frame_skip == 0) {
+ ctx-format_id = csi2_ctx_map_format(csi2);
+ csi2_ctx_config(csi2, ctx);
Is configuration of the context needed elsewhere than in streamon? What
changes
Re: [PATCH] [media] convert drivers/media/* to use module_i2c_driver()
On Sat, 21 Jan 2012 18:10:45 +0800 Axel Lin axel@gmail.com wrote: This patch converts the drivers in drivers/media/* to use the module_i2_driver() macro which makes the code smaller and a bit simpler. For ov7670.c (belatedly): Acked-by: Jonathan Corbet cor...@lwn.net jon -- 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: Anysee E30 S2 plus
On 12/20/2011 05:15 PM, Antti Palosaari wrote: On 12/20/2011 02:10 PM, Jesper Krogh wrote: Ok. I had my doubts on whether to include that or not - But here it is /Jesper [ 1056.137882] DVB: registering new adapter (Anysee DVB USB2.0) [ 1056.141938] anysee: firmware version:1.3 hardware id:11 [ 1056.145212] Invalid probe, probably not a CX24116 device [ 1056.145231] anysee: Unsupported Anysee version. Please report the linux-media@vger.kernel.org. Check your power supply is connected. It do same here without power supply since demod is powered using external power supply. If not then it is most likely firmware issue. I have very old firmware, maybe one of the first devel versions. I got today similar bug report and after debugging we found there is different hardware. Whole NIM, that is box containing demodulator and tuner, is different. Instead of old CX24116 there is same NIM than can be found from the E7 serie DVB-S2 receiver. So I have to get this new revision of that device in order to add support for it... Sorry :/ 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
Terratex dvb size wrong
Hi, I own a tv usb key (dvb-t), Slackware 13.37, kernel 3.0.18: dvb-usb: found a 'Terratec Cinergy T USB XXS (HD) / T3' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-dib0700 1.20.fw' dvb-usb: found a 'Terratec Cinergy T USB XXS (HD) / T3' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. dvb-usb: Terratec Cinergy T USB XXS (HD) / T3 successfully initialized and connected. usbcore: registered new interface driver dvb_usb_dib0700 I have created the configuration file of the channels. When I use: mplayer dvb://channel -demuxer mpegts -vf pp=lp I get a video with size wrong. The X window is 16:9 but the image is 4:3 in the center of the window with black bars on the sides. With Fedora 16 or Ubuntu, the video is correct 16:9. Where is the problem? Thank you. -- 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] add another Terratec H7 usb id to az6007
This patch add another Terratec H7 usb id to az6007 driver.
Jose Alberto
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
diff -ur linux/drivers/media/dvb/dvb-usb/az6007.c linux.new/drivers/media/dvb/dvb-usb/az6007.c
--- linux/drivers/media/dvb/dvb-usb/az6007.c 2012-01-22 02:53:17.0 +0100
+++ linux.new/drivers/media/dvb/dvb-usb/az6007.c 2012-01-23 00:17:57.859087470 +0100
@@ -481,6 +481,7 @@
static struct usb_device_id az6007_usb_table[] = {
{USB_DEVICE(USB_VID_AZUREWAVE, USB_PID_AZUREWAVE_6007)},
{USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_H7)},
+ {USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_H7_2)},
{0},
};
@@ -534,7 +535,7 @@
.warm_ids = { NULL },
},
{ .name = TerraTec DTV StarBox DVB-T/C USB2.0 (az6007),
- .cold_ids = { az6007_usb_table[1], NULL },
+ .cold_ids = { az6007_usb_table[1], az6007_usb_table[2], NULL },
.warm_ids = { NULL },
},
{ NULL },
diff -ur linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h linux.new/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2012-01-22 02:53:17.0 +0100
+++ linux.new/drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2012-01-23 00:16:49.993324303 +0100
@@ -228,6 +228,7 @@
#define USB_PID_TERRATEC_CINERGY_T_XXS 0x0078
#define USB_PID_TERRATEC_CINERGY_T_XXS_2 0x00ab
#define USB_PID_TERRATEC_H70x10b4
+#define USB_PID_TERRATEC_H7_20x10a3
#define USB_PID_TERRATEC_T30x10a0
#define USB_PID_TERRATEC_T50x10a1
#define USB_PID_PINNACLE_EXPRESSCARD_320CX 0x022e
Re: [PATCH 0/2] Import PCTV-80e Drivers from Devin Heitmueller's Repository
On 01/26/2012 10:36 AM, Mauro Carvalho Chehab wrote: Em 21-01-2012 05:34, pdickeyb...@gmail.com escreveu: From: Patrick Dickey pdickeyb...@gmail.com This series of patches will import the drx39xxj(drx39xyj) drivers from Devin Heitmueller's HG Repository for the Pinnacle PCTV-80e USB Tuner. Patrick Dickey (2): import-pctv-80e-from-devin-heitmueller-hg-repository Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com Signed-off-by: Patrick Dickey pdickeyb...@gmail.com import-pctv-80e-from-devin-heitmueller-hg-repository Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com Signed-off-by: Patrick Dickey pdickeyb...@gmail.com Patch 0 never arrived. Is there a place where I could get it? If the patch is from some Devin's tree, maybe I can just get it there. I may have to resend them. Somehow the subject heading of the patches became mangled. Patch 0, is just the cover letter, patch 1/2 and 2/2 (which both have mangled subject headings) are the actual patches. The other two have the subject heading of [PATCH x/2] Import PCTV-80e Drivers from Devin Heitmueller's Repository#... It combined the comments from the patch with the subject. Sorry for any inconvenience and confusion that this created. Have a great day:) Patrick. Documentation/video4linux/CARDLIST.em28xx |1 + .../staging/media/dvb/frontends/drx39xyj/Kconfig |7 + .../staging/media/dvb/frontends/drx39xyj/Makefile |3 + .../media/dvb/frontends/drx39xyj/bsp_host.h| 80 + .../staging/media/dvb/frontends/drx39xyj/bsp_i2c.h | 217 + .../media/dvb/frontends/drx39xyj/bsp_tuner.h | 215 + .../media/dvb/frontends/drx39xyj/bsp_types.h | 229 + .../media/dvb/frontends/drx39xyj/drx39xxj.c| 457 + .../media/dvb/frontends/drx39xyj/drx39xxj.h| 40 + .../media/dvb/frontends/drx39xyj/drx39xxj_dummy.c | 134 + .../media/dvb/frontends/drx39xyj/drx_dap_fasi.c| 675 + .../media/dvb/frontends/drx39xyj/drx_dap_fasi.h| 268 + .../media/dvb/frontends/drx39xyj/drx_driver.c | 1600 ++ .../media/dvb/frontends/drx39xyj/drx_driver.h | 2588 +++ .../dvb/frontends/drx39xyj/drx_driver_version.h| 82 + .../staging/media/dvb/frontends/drx39xyj/drxj.c|16758 .../staging/media/dvb/frontends/drx39xyj/drxj.h| 730 + .../media/dvb/frontends/drx39xyj/drxj_map.h|15359 ++ .../staging/media/dvb/frontends/drx39xyj/drxj_mc.h | 3939 + .../media/dvb/frontends/drx39xyj/drxj_mc_vsb.h | 744 + .../media/dvb/frontends/drx39xyj/drxj_mc_vsbqam.h | 1437 ++ .../media/dvb/frontends/drx39xyj/drxj_options.h| 65 + 22 files changed, 45628 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/Kconfig create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/Makefile create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_host.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_i2c.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_tuner.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_types.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx39xxj.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx39xxj.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx39xxj_dummy.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_dap_fasi.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_dap_fasi.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_driver.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_driver.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_driver_version.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_map.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_mc.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_mc_vsb.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_mc_vsbqam.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_options.h -- 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
RFC: removal of video/radio/vbi_nr module options?
Hi all, I'm working on cleaning up some old radio drivers and while doing that I started wondering about the usefulness of the radio_nr module option (and the corresponding video_nr/vbi_nr module options for video devices). Is that really still needed? It originates from pre-udev times, but it seems fairly useless to me these days. It is also hit-and-miss whether a driver supports it (e.g. uvc doesn't and nobody seems to miss it) and if it does, whether it is an array (and how long that array is) or a single integer. So my question is: when I'm cleaning up drivers like the old radio drivers, should I keep support for those module options or should I just drop it? I'm curious what people think. Regards, 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
