Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
On Tuesday, July 05, 2011 00:47:43 Laurent Pinchart wrote: Hi Mauro, On Monday 04 July 2011 18:09:18 Mauro Carvalho Chehab wrote: [snip] 1) PRESET STANDARDS == = There are 3 specs involved with DV presets: ITU-R BT 709 and BT 1120 and CEA 861. At ITU-R BT.709, both 60Hz and 60/1.001 Hz are equally called as 60 Hz. BT.1120 follows the same logic, as it uses BT.709 as a reference for video timings. The CEA-861-E spec says at item 4, that: [snip] At the same item, the table 2 describes several video parameters for each preset, associating the Video Identification Codes (VIC) for each preset. This might be a bit out of scope, but why aren't we using the VICs as DV presets ? The VIC does more than just set the timings. It also determines the pixel aspect ratio. So exactly the same video timings may have two VICs, the only difference being the pixel aspect which is *not* part of the timings. The VIC is part of the AVI InfoFrame, however. So VIC != timings. 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
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
On Monday, July 04, 2011 18:09:18 Mauro Carvalho Chehab wrote:
Em 29-06-2011 09:51, Tomasz Stanislawski escreveu:
The 1080p59_94 is supported by latest Samsung SoC.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/v4l2-common.c |1 +
include/linux/videodev2.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 06b9f9f..003e648 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -582,6 +582,7 @@ int v4l_fill_dv_preset_info(u32 preset, struct
v4l2_dv_enum_preset *info)
{ 1920, 1080, 1080p@30 }, /* V4L2_DV_1080P30 */
{ 1920, 1080, 1080p@50 }, /* V4L2_DV_1080P50 */
{ 1920, 1080, 1080p@60 }, /* V4L2_DV_1080P60 */
+ { 1920, 1080, 1080p@59.94 }, /* V4L2_DV_1080P59_94 */
};
if (info == NULL || preset = ARRAY_SIZE(dv_presets))
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 8a4c309..7c77c4e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -872,6 +872,7 @@ struct v4l2_dv_enum_preset {
#defineV4L2_DV_1080P30 16 /* SMPTE 296M */
#defineV4L2_DV_1080P50 17 /* BT.1120 */
#defineV4L2_DV_1080P60 18 /* BT.1120 */
+#defineV4L2_DV_1080P59_94 19
/*
* D V B T T I M I N G S
This patch deserves further discussions, as the specs that define the presets
are not so clear with respect to 60Hz and 60/1.001 Hz.
Let me summarize the issue.
1) PRESET STANDARDS
== =
There are 3 specs involved with DV presets: ITU-R BT 709 and BT 1120 and CEA
861.
At ITU-R BT.709, both 60Hz and 60/1.001 Hz are equally called as 60 Hz.
BT.1120
follows the same logic, as it uses BT.709 as a reference for video timings.
The CEA-861-E spec says at item 4, that:
A video timing with a vertical frequency that is an integer multiple of
6.00 Hz (i.e. 24.00, 30.00, 60.00,
120.00 or 240.00 Hz) is considered to be the same as a video timing
with the equivalent detailed timing
information but where the vertical frequency is adjusted by a factor of
1000/1001 (i.e., 24/1.001, 30/1.001,
60/1.001, 120/1.001 or 240/1.001). That is, they are considered two
versions of the same video timing but
with slightly different pixel clock frequencies. Therefore, a DTV that
declares it is capable of displaying a
video timing with a vertical frequency that is either an integer
multiple of 6 Hz or an integer multiple of 6
Hz adjusted by a factor of 1000/1001 shall be capable of displaying
both versions of the video timing.
At the same item, the table 2 describes several video parameters for each
preset, associating the
Video Identification Codes (VIC) for each preset.
No, *multiple VICs* are associated with each preset. VIC != preset.
Also, the VICs do not differentiate between 60 and 59.94 Hz.
Table 4 associates each VIC with the supported formats. For example, VIC 16
means a resolution of
1920x1080 at 59.94Hz/60Hz. The spec does explicitly allow that all vertical
frequencies that are
multiple of 6 Hz to accept both 59.94 Hz and 60 Hz, as said at note 3 of
table 2:
3. A video timing with a vertical frequency that is an integer multiple
of 6.00 Hz (i.e. 24.00, 30.00, 60.00, 120.00 or
240.00 Hz) is considered to be the same as a video timing with the
equivalent detailed timing information but where
the vertical frequency is adjusted by a factor of 1000/1001 (i.e.,
24/1.001, 30/1.001, 60/1.001, 120/1.001 or
240/1.001). That is, they are considered two versions of the same video
timing but with slightly different pixel clock
frequencies. The vertical frequencies of the 240p, 480p, and 480i video
formats are typically adjusted by a factor of
exactly 1000/1001 for NTSC video compatibility, while the 576p, 576i,
and the HDTV video formats are not. The
VESA DMT standard [65] specifies a ± 0.5% pixel clock frequency
tolerance. Therefore, the nominally 25.175 MHz
pixel clock frequency value given for video identification code 1 may
be adjusted to 25.2 MHz to obtain an exact 60
Hz vertical frequency.
In other words, the preset for 1920x1080p@60Hz can be used for both 60Hz and
59.94 Hz,
according with the above note, being 59.94 Hz the typical value (e. g. the
value that
should be used on most places).
However, there are some 60 Hz vertical resolutions that have VIC's with
different framerates (like 59.94Hz, 60.054Hz, etc). Those seem to not be
covered by the multiple of 6.00 Hz rule.
No. A preset identifies one
[RFCv2 PATCH] poll: add poll_requested_events() function
This is the second version of this patch. The only change I've made is that
init_poll_funcptr() is now used in fs/eventpoll.c to initialize the poll_table
instead of initializing it with '= { NULL, ~0 }'.
Comments? Or even better: an Acked-by or Reviewed-by?
Regards,
Hans
In some cases the poll() implementation in a driver has to do different
things depending on the events the caller wants to poll for. An example is
when a driver needs to start a DMA engine if the caller polls for POLLIN,
but doesn't want to do that if POLLIN is not requested but instead only
POLLOUT or POLLPRI is requested. This is something that can happen in the
video4linux subsystem.
Unfortunately, the current epoll/poll/select implementation doesn't provide
that information reliably. The poll_table_struct does have it: it has a key
field with the event mask. But once a poll() call matches one or more bits
of that mask any following poll() calls are passed a NULL poll_table_struct
pointer.
The solution is to set the qproc field to NULL in poll_table_struct once
poll() matches the events, not the poll_table_struct pointer itself. That
way drivers can obtain the mask through a new poll_requested_events inline.
The poll_table_struct can still be NULL since some kernel code calls it
internally (netfs_state_poll() in ./drivers/staging/pohmelfs/netfs.h). In
that case poll_requested_events() returns ~0 (i.e. all events).
Since eventpoll always leaves the key field at ~0 instead of using the
requested events mask, that source was changed as well to properly fill in
the key field.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
fs/eventpoll.c | 19 +++
fs/select.c | 32 ++--
include/linux/poll.h |7 ++-
3 files changed, 35 insertions(+), 23 deletions(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index f9cfd16..6a54a69 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -650,9 +650,12 @@ static int ep_read_events_proc(struct eventpoll *ep,
struct list_head *head,
void *priv)
{
struct epitem *epi, *tmp;
+ poll_table pt;
+ init_poll_funcptr(pt, NULL);
list_for_each_entry_safe(epi, tmp, head, rdllink) {
- if (epi-ffd.file-f_op-poll(epi-ffd.file, NULL)
+ pt.key = epi-event.events;
+ if (epi-ffd.file-f_op-poll(epi-ffd.file, pt)
epi-event.events)
return POLLIN | POLLRDNORM;
else {
@@ -946,6 +949,7 @@ static int ep_insert(struct eventpoll *ep, struct
epoll_event *event,
/* Initialize the poll table using the queue callback */
epq.epi = epi;
init_poll_funcptr(epq.pt, ep_ptable_queue_proc);
+ epq.pt.key = event-events;
/*
* Attach the item to the poll hooks and get current event bits.
@@ -1027,20 +1031,23 @@ static int ep_modify(struct eventpoll *ep, struct
epitem *epi, struct epoll_even
{
int pwake = 0;
unsigned int revents;
+ poll_table pt;
+
+ init_poll_funcptr(pt, NULL);
/*
* Set the new event interest mask before calling f_op-poll();
* otherwise we might miss an event that happens between the
* f_op-poll() call and the new event set registering.
*/
- epi-event.events = event-events;
+ epi-event.events = pt.key = event-events;
epi-event.data = event-data; /* protected by mtx */
/*
* Get current event bits. We can safely use the file* here because
* its usage count has been increased by the caller of this function.
*/
- revents = epi-ffd.file-f_op-poll(epi-ffd.file, NULL);
+ revents = epi-ffd.file-f_op-poll(epi-ffd.file, pt);
/*
* If the item is hot and it is not registered inside the ready
@@ -1075,6 +1082,9 @@ static int ep_send_events_proc(struct eventpoll *ep,
struct list_head *head,
unsigned int revents;
struct epitem *epi;
struct epoll_event __user *uevent;
+ poll_table pt;
+
+ init_poll_funcptr(pt, NULL);
/*
* We can loop without lock because we are passed a task private list.
@@ -1087,7 +1097,8 @@ static int ep_send_events_proc(struct eventpoll *ep,
struct list_head *head,
list_del_init(epi-rdllink);
- revents = epi-ffd.file-f_op-poll(epi-ffd.file, NULL)
+ pt.key = epi-event.events;
+ revents = epi-ffd.file-f_op-poll(epi-ffd.file, pt)
epi-event.events;
/*
diff --git a/fs/select.c b/fs/select.c
index d33418f..2da21b8 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -386,13 +386,11 @@ get_max:
static inline void wait_key_set(poll_table *wait, unsigned long in,
unsigned long out, unsigned long bit)
{
- if (wait) {
- wait-key = POLLEX_SET;
- if (in
[PATCH 5/8] mm: MIGRATE_CMA isolation functions added
From: Michal Nazarewicz m.nazarew...@samsung.com
This commit changes various functions that change pages and
pageblocks migrate type between MIGRATE_ISOLATE and
MIGRATE_MOVABLE in such a way as to allow to work with
MIGRATE_CMA migrate type.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
include/linux/page-isolation.h | 40 +++-
mm/page_alloc.c| 19 ---
mm/page_isolation.c| 15 ---
3 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 014ebb5..96e287d 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -3,39 +3,53 @@
/*
* Changes migrate type in [start_pfn, end_pfn) to be MIGRATE_ISOLATE.
- * If specified range includes migrate types other than MOVABLE,
+ * If specified range includes migrate types other than MOVABLE or CMA,
* this will fail with -EBUSY.
*
* For isolating all pages in the range finally, the caller have to
* free all pages in the range. test_page_isolated() can be used for
* test it.
*/
-extern int
-start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn);
+int __start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
+ unsigned migratetype);
+
+static inline int
+start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn)
+{
+ return __start_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
+}
+
+int __undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
+ unsigned migratetype);
/*
* Changes MIGRATE_ISOLATE to MIGRATE_MOVABLE.
* target range is [start_pfn, end_pfn)
*/
-extern int
-undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn);
+static inline int
+undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn)
+{
+ return __undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
+}
/*
- * test all pages in [start_pfn, end_pfn)are isolated or not.
+ * Test all pages in [start_pfn, end_pfn) are isolated or not.
*/
-extern int
-test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn);
+int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn);
/*
- * Internal funcs.Changes pageblock's migrate type.
- * Please use make_pagetype_isolated()/make_pagetype_movable().
+ * Internal functions. Changes pageblock's migrate type.
*/
-extern int set_migratetype_isolate(struct page *page);
-extern void unset_migratetype_isolate(struct page *page);
+int set_migratetype_isolate(struct page *page);
+void __unset_migratetype_isolate(struct page *page, unsigned migratetype);
+static inline void unset_migratetype_isolate(struct page *page)
+{
+ __unset_migratetype_isolate(page, MIGRATE_MOVABLE);
+}
extern unsigned long alloc_contig_freed_pages(unsigned long start,
unsigned long end, gfp_t flag);
extern int alloc_contig_range(unsigned long start, unsigned long end,
- gfp_t flags);
+ gfp_t flags, unsigned migratetype);
extern void free_contig_pages(struct page *page, int nr_pages);
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 1353a0c..a936a75 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5642,7 +5642,7 @@ out:
return ret;
}
-void unset_migratetype_isolate(struct page *page)
+void __unset_migratetype_isolate(struct page *page, unsigned migratetype)
{
struct zone *zone;
unsigned long flags;
@@ -5650,8 +5650,8 @@ void unset_migratetype_isolate(struct page *page)
spin_lock_irqsave(zone-lock, flags);
if (get_pageblock_migratetype(page) != MIGRATE_ISOLATE)
goto out;
- set_pageblock_migratetype(page, MIGRATE_MOVABLE);
- move_freepages_block(zone, page, MIGRATE_MOVABLE);
+ set_pageblock_migratetype(page, migratetype);
+ move_freepages_block(zone, page, migratetype);
out:
spin_unlock_irqrestore(zone-lock, flags);
}
@@ -5756,6 +5756,10 @@ static int __alloc_contig_migrate_range(unsigned long
start, unsigned long end)
* @start: start PFN to allocate
* @end: one-past-the-last PFN to allocate
* @flags: flags passed to alloc_contig_freed_pages().
+ * @migratetype: migratetype of the underlaying pageblocks (either
+ * #MIGRATE_MOVABLE or #MIGRATE_CMA). All pageblocks
+ * in range must have the same migratetype and it must
+ * be either of the two.
*
* The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
* aligned, hovewer it's callers responsibility to guarantee that we
@@ -5767,7 +5771,7
[PATCH 7/8] ARM: integrate CMA with dma-mapping subsystem
This patch adds support for CMA to dma-mapping subsystem for ARM
architecture. By default a global CMA area is used, but specific devices
are allowed to have their private memory areas if required (they can be
created with dma_declare_contiguous() function during board
initialization).
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/Kconfig |1 +
arch/arm/include/asm/device.h |3 ++
arch/arm/include/asm/dma-mapping.h | 20 ++
arch/arm/mm/dma-mapping.c | 51 +++
arch/arm/mm/init.c |3 ++
5 files changed, 66 insertions(+), 12 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9adc278..3cca8cc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -3,6 +3,7 @@ config ARM
default y
select HAVE_AOUT
select HAVE_DMA_API_DEBUG
+ select HAVE_DMA_CONTIGUOUS
select HAVE_IDE
select HAVE_MEMBLOCK
select RTC_LIB
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index 9f390ce..942913e 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -10,6 +10,9 @@ struct dev_archdata {
#ifdef CONFIG_DMABOUNCE
struct dmabounce_device_info *dmabounce;
#endif
+#ifdef CONFIG_CMA
+ struct cma *cma_area;
+#endif
};
struct pdev_archdata {
diff --git a/arch/arm/include/asm/dma-mapping.h
b/arch/arm/include/asm/dma-mapping.h
index 4fff837..a3e1e48c 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -6,6 +6,7 @@
#include linux/mm_types.h
#include linux/scatterlist.h
#include linux/dma-debug.h
+#include linux/dma-contiguous.h
#include asm-generic/dma-coherent.h
#include asm/memory.h
@@ -14,6 +15,25 @@
#error Please update to __arch_pfn_to_dma
#endif
+#ifdef CONFIG_CMA
+static inline struct cma *get_dev_cma_area(struct device *dev)
+{
+ if (dev-archdata.cma_area)
+ return dev-archdata.cma_area;
+ return dma_contiguous_default_area;
+}
+
+static inline void set_dev_cma_area(struct device *dev, struct cma *cma)
+{
+ dev-archdata.cma_area = cma;
+}
+#else
+static inline struct cma *get_dev_cma_area(struct device *dev)
+{
+ return NULL;
+}
+#endif
+
/*
* dma_to_pfn/pfn_to_dma/dma_to_virt/virt_to_dma are architecture private
* functions used internally by the DMA-mapping API to provide DMA
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 82a093c..1d4e916 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -17,6 +17,7 @@
#include linux/init.h
#include linux/device.h
#include linux/dma-mapping.h
+#include linux/dma-contiguous.h
#include linux/highmem.h
#include asm/memory.h
@@ -52,16 +53,35 @@ static u64 get_coherent_dma_mask(struct device *dev)
return mask;
}
+
+static struct page *__alloc_system_pages(size_t count, unsigned int order,
gfp_t gfp)
+{
+ struct page *page, *p, *e;
+
+ page = alloc_pages(gfp, order);
+ if (!page)
+ return NULL;
+
+ /*
+* Now split the huge page and free the excess pages
+*/
+ split_page(page, order);
+ for (p = page + count, e = page + (1 order); p e; p++)
+ __free_page(p);
+ return page;
+}
+
/*
* Allocate a DMA buffer for 'dev' of size 'size' using the
* specified gfp mask. Note that 'size' must be page aligned.
*/
static struct page *__dma_alloc_buffer(struct device *dev, size_t size, gfp_t
gfp)
{
- unsigned long order = get_order(size);
- struct page *page, *p, *e;
+ struct page *page;
+ size_t count = size PAGE_SHIFT;
void *ptr;
u64 mask = get_coherent_dma_mask(dev);
+ unsigned long order = get_order(count PAGE_SHIFT);
#ifdef CONFIG_DMA_API_DEBUG
u64 limit = (mask + 1) ~mask;
@@ -78,16 +98,19 @@ static struct page *__dma_alloc_buffer(struct device *dev,
size_t size, gfp_t gf
if (mask 0xULL)
gfp |= GFP_DMA;
- page = alloc_pages(gfp, order);
- if (!page)
- return NULL;
+ /*
+* First, try to allocate memory from contiguous area
+*/
+ page = dma_alloc_from_contiguous(dev, count, order);
/*
-* Now split the huge page and free the excess pages
+* Fallback if contiguous alloc fails or is not available
*/
- split_page(page, order);
- for (p = page + (size PAGE_SHIFT), e = page + (1 order); p e;
p++)
- __free_page(p);
+ if (!page)
+ page = __alloc_system_pages(count, order, gfp);
+
+ if (!page)
+ return NULL;
/*
* Ensure that the allocated pages are zeroed, and that any data
@@ -104,9 +127,13 @@ static struct page *__dma_alloc_buffer(struct device *dev,
size_t size, gfp_t
[PATCH 3/8] mm: alloc_contig_range() added
From: Michal Nazarewicz m.nazarew...@samsung.com
This commit adds the alloc_contig_range() function which tries
to allecate given range of pages. It tries to migrate all
already allocated pages that fall in the range thus freeing them.
Once all pages in the range are freed they are removed from the
buddy system thus allocated for the caller to use.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[m.szyprowski: renamed some variables for easier code reading]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
include/linux/page-isolation.h |2 +
mm/page_alloc.c| 144
2 files changed, 146 insertions(+), 0 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index f1417ed..c5d1a7c 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -34,6 +34,8 @@ extern int set_migratetype_isolate(struct page *page);
extern void unset_migratetype_isolate(struct page *page);
extern unsigned long alloc_contig_freed_pages(unsigned long start,
unsigned long end, gfp_t flag);
+extern int alloc_contig_range(unsigned long start, unsigned long end,
+ gfp_t flags);
extern void free_contig_pages(struct page *page, int nr_pages);
/*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 00e9b24..2cea044 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5638,6 +5638,150 @@ unsigned long alloc_contig_freed_pages(unsigned long
start, unsigned long end,
return pfn;
}
+static unsigned long pfn_to_maxpage(unsigned long pfn)
+{
+ return pfn ~(MAX_ORDER_NR_PAGES - 1);
+}
+
+static unsigned long pfn_to_maxpage_up(unsigned long pfn)
+{
+ return ALIGN(pfn, MAX_ORDER_NR_PAGES);
+}
+
+#define MIGRATION_RETRY5
+static int __alloc_contig_migrate_range(unsigned long start, unsigned long end)
+{
+ int migration_failed = 0, ret;
+ unsigned long pfn = start;
+
+ /*
+* Some code borrowed from KAMEZAWA Hiroyuki's
+* __alloc_contig_pages().
+*/
+
+ for (;;) {
+ pfn = scan_lru_pages(pfn, end);
+ if (!pfn || pfn = end)
+ break;
+
+ ret = do_migrate_range(pfn, end);
+ if (!ret) {
+ migration_failed = 0;
+ } else if (ret != -EBUSY
+ || ++migration_failed = MIGRATION_RETRY) {
+ return ret;
+ } else {
+ /* There are unstable pages.on pagevec. */
+ lru_add_drain_all();
+ /*
+* there may be pages on pcplist before
+* we mark the range as ISOLATED.
+*/
+ drain_all_pages();
+ }
+ cond_resched();
+ }
+
+ if (!migration_failed) {
+ /* drop all pages in pagevec and pcp list */
+ lru_add_drain_all();
+ drain_all_pages();
+ }
+
+ /* Make sure all pages are isolated */
+ if (WARN_ON(test_pages_isolated(start, end)))
+ return -EBUSY;
+
+ return 0;
+}
+
+/**
+ * alloc_contig_range() -- tries to allocate given range of pages
+ * @start: start PFN to allocate
+ * @end: one-past-the-last PFN to allocate
+ * @flags: flags passed to alloc_contig_freed_pages().
+ *
+ * The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
+ * aligned, hovewer it's callers responsibility to guarantee that we
+ * are the only thread that changes migrate type of pageblocks the
+ * pages fall in.
+ *
+ * Returns zero on success or negative error code. On success all
+ * pages which PFN is in (start, end) are allocated for the caller and
+ * need to be freed with free_contig_pages().
+ */
+int alloc_contig_range(unsigned long start, unsigned long end,
+ gfp_t flags)
+{
+ unsigned long outer_start, outer_end;
+ int ret;
+
+ /*
+* What we do here is we mark all pageblocks in range as
+* MIGRATE_ISOLATE. Because of the way page allocator work, we
+* align the range to MAX_ORDER pages so that page allocator
+* won't try to merge buddies from different pageblocks and
+* change MIGRATE_ISOLATE to some other migration type.
+*
+* Once the pageblocks are marked as MIGRATE_ISOLATE, we
+* migrate the pages from an unaligned range (ie. pages that
+* we are interested in). This will put all the pages in
+* range back to page allocator as MIGRATE_ISOLATE.
+*
+* When this is done, we take the pages in range from page
+* allocator removing them from the buddy system. This way
+* page
[PATCH 4/8] mm: MIGRATE_CMA migration type added
From: Michal Nazarewicz m.nazarew...@samsung.com
The MIGRATE_CMA migration type has two main characteristics:
(i) only movable pages can be allocated from MIGRATE_CMA
pageblocks and (ii) page allocator will never change migration
type of MIGRATE_CMA pageblocks.
This guarantees that page in a MIGRATE_CMA page block can
always be migrated somewhere else (unless there's no memory left
in the system).
It is designed to be used with Contiguous Memory Allocator
(CMA) for allocating big chunks (eg. 10MiB) of physically
contiguous memory. Once driver requests contiguous memory,
CMA will migrate pages from MIGRATE_CMA pageblocks.
To minimise number of migrations, MIGRATE_CMA migration type
is the last type tried when page allocator falls back to other
migration types then requested.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[m.szyprowski: cleaned up Kconfig, renamed some functions]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
cma migrate fixup
---
include/linux/mmzone.h | 43 +++---
include/linux/page-isolation.h |4 ++
mm/Kconfig |8 +++-
mm/compaction.c| 10
mm/page_alloc.c| 94
5 files changed, 132 insertions(+), 27 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 9f7c3eb..126014d 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_TYPE
+ /*
+* 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_MIGRATE_TYPE
+# define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
+#else
+# define is_migrate_cma(migratetype) false
+#endif
#define for_each_migratetype_order(order, type) \
for (order = 0; order MAX_ORDER; order++) \
@@ -54,6 +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 c5d1a7c..014ebb5 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -46,4 +46,8 @@ int test_pages_in_a_zone(unsigned long start_pfn, unsigned
long end_pfn);
unsigned long scan_lru_pages(unsigned long start, unsigned long end);
int do_migrate_range(unsigned long start_pfn, unsigned long end_pfn);
+#ifdef CONFIG_CMA_MIGRATE_TYPE
+extern void init_cma_reserved_pageblock(struct page *page);
+#endif
+
#endif
diff --git a/mm/Kconfig b/mm/Kconfig
index 8ca47a5..6ffedd8 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -189,7 +189,7 @@ config COMPACTION
config MIGRATION
bool Page migration
def_bool y
- depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION
+ depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION ||
CMA_MIGRATE_TYPE
help
Allows the migration of the physical location of pages of processes
while the virtual addresses are not changed. This is useful in
@@ -198,6 +198,12 @@ config MIGRATION
pages as migration can relocate pages to satisfy a huge page
allocation instead of reclaiming.
+config CMA_MIGRATE_TYPE
+ bool
+ help
+ This enables the use the MIGRATE_CMA migrate type, which lets lets CMA
+ work on almost
[PATCH 2/8] mm: alloc_contig_freed_pages() added
From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
This commit introduces alloc_contig_freed_pages() function
which allocates (ie. removes from buddy system) free pages
in range. Caller has to guarantee that all pages in range
are in buddy system.
Along with this function, a free_contig_pages() function is
provided which frees all (or a subset of) pages allocated
with alloc_contig_free_pages().
Michal Nazarewicz has modified the function to make it easier
to allocate not MAX_ORDER_NR_PAGES aligned pages by making it
return pfn of one-past-the-last allocated page.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
include/linux/page-isolation.h |3 ++
mm/page_alloc.c| 44
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 58cdbac..f1417ed 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -32,6 +32,9 @@ test_pages_isolated(unsigned long start_pfn, unsigned long
end_pfn);
*/
extern int set_migratetype_isolate(struct page *page);
extern void unset_migratetype_isolate(struct page *page);
+extern unsigned long alloc_contig_freed_pages(unsigned long start,
+ unsigned long end, gfp_t flag);
+extern void free_contig_pages(struct page *page, int nr_pages);
/*
* For migration.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 4e8985a..00e9b24 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5600,6 +5600,50 @@ out:
spin_unlock_irqrestore(zone-lock, flags);
}
+unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long end,
+ gfp_t flag)
+{
+ unsigned long pfn = start, count;
+ struct page *page;
+ struct zone *zone;
+ int order;
+
+ VM_BUG_ON(!pfn_valid(start));
+ zone = page_zone(pfn_to_page(start));
+
+ spin_lock_irq(zone-lock);
+
+ page = pfn_to_page(pfn);
+ for (;;) {
+ VM_BUG_ON(page_count(page) || !PageBuddy(page));
+ list_del(page-lru);
+ order = page_order(page);
+ zone-free_area[order].nr_free--;
+ rmv_page_order(page);
+ __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL order));
+ pfn += 1 order;
+ if (pfn = end)
+ break;
+ VM_BUG_ON(!pfn_valid(pfn));
+ page += 1 order;
+ }
+
+ spin_unlock_irq(zone-lock);
+
+ /* After this, pages in the range can be freed one be one */
+ page = pfn_to_page(start);
+ for (count = pfn - start; count; --count, ++page)
+ prep_new_page(page, 0, flag);
+
+ return pfn;
+}
+
+void free_contig_pages(struct page *page, int nr_pages)
+{
+ for (; nr_pages; --nr_pages, ++page)
+ __free_page(page);
+}
+
#ifdef CONFIG_MEMORY_HOTREMOVE
/*
* All pages in the range must be isolated before calling this.
--
1.7.1.569.g6f426
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv11 0/8] Contiguous Memory Allocator
Hello everyone, This is yet another round of Contiguous Memory Allocator patches. I hope that I've managed to resolve all the items discussed during the Memory Management summit at Linaro Meeting in Budapest and pointed later on mailing lists. The goal is to integrate it as tight as possible with other kernel subsystems (like memory management and dma-mapping) and finally merge to mainline. Previous version introduced integration with DMA-mapping subsystem for ARM architecture. In this version I've cleaned up it even more and prepared for easier integration on other than ARM architectures. I've also rebased all the code onto latest v3.0-rc6 kernel. 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 article: http://lwn.net/Articles/447405/ and links to previous versions of CMA framework. The CMA framework has been initially developed by Michal Nazarewicz at Samsung Poland RD Center. Since version 9, I've taken over the development, because Michal has left the company. The current version of CMA is a set of helper functions for DMA mapping framework that handles allocation of contiguous memory blocks. The difference between this patchset and Kamezawa's alloc_contig_pages() are: 1. alloc_contig_pages() requires MAX_ORDER alignment of allocations which may be unsuitable for embeded systems where a few MiBs are required. Lack of the requirement on the alignment means that several threads might try to access the same pageblock/page. To prevent this from happening CMA uses a mutex so that only one allocating/releasing function may run at one point. 2. CMA may use its own migratetype (MIGRATE_CMA) which behaves similarly to ZONE_MOVABLE but can be put in arbitrary places. This is required for us since we need to define two disjoint memory ranges inside system RAM. (ie. in two memory banks (do not confuse with nodes)). 3. alloc_contig_pages() scans memory in search for range that could be migrated. CMA on the other hand maintains its own allocator to decide where to allocate memory for device drivers and then tries to migrate pages from that part if needed. This is not strictly required but I somehow feel it might be faster. The integration with ARM DMA-mapping subsystem is quite straightforward. Once cma context is available alloc_pages() can be replaced by dma_alloc_from_contiguous() call. Current version have been tested on Samsung S5PC110 based Goni machine and s5p-fimc V4L2 driver. The driver itself uses videobuf2 dma-contig memory allocator, which in turn relies on dma_alloc_coherent() from DMA-mapping subsystem. By integrating CMA with DMA-mapping we managed to get this driver working with CMA without any single change required in the driver or videobuf2-dma-contig allocator. TODO: - resolve double-mapping issues with ARMv6+ and coherent memory Best regards -- Marek Szyprowski Samsung Poland RD Center Links to previous versions of the patchset: 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: v11: 1. Removed genalloc usage and replaced it with direct calls to bitmap_* functions, dropped patches that are not needed anymore (genalloc extensions) 2. Moved all contiguous area management code from mm/cma.c to drivers/base/dma-contiguous.c 3. Renamed cm_alloc/free to dma_alloc/release_from_contiguous 4. Introduced global, system wide (default) contiguous area configured with kernel config and kernel cmdline parameters 5. Simplified initialization to just one function: dma_declare_contiguous() 6. Added example of device private memory contiguous area v10: 1. Rebased onto 3.0-rc2 and resolved all conflicts 2. Simplified CMA to be just a pure memory allocator, for use with platfrom/bus specific subsystems, like dma-mapping.
[PATCH 6/8] drivers: add Contiguous Memory Allocator
The Contiguous Memory Allocator is a set of helper functions for DMA mapping framework that improves allocations of contiguous memory chunks. CMA grabs memory on system boot, marks it with CMA_MIGRATE_TYPE and gives back to the system. Kernel is allowed to allocate movable pages within CMA's managed memory so that it can be used for example for page cache when DMA mapping do not use it. On dma_alloc_from_contiguous() request such pages are migrated out of CMA area to free required contiguous block and fulfill the request. This allows to allocate large contiguous chunks of memory at any time assuming that there is enough free memory available in the system. This code is heavily based on earlier works by Michal Nazarewicz. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com CC: Michal Nazarewicz min...@mina86.com --- drivers/base/Kconfig | 77 + drivers/base/Makefile |1 + drivers/base/dma-contiguous.c | 367 include/linux/dma-contiguous.h | 104 +++ 4 files changed, 549 insertions(+), 0 deletions(-) create mode 100644 drivers/base/dma-contiguous.c create mode 100644 include/linux/dma-contiguous.h diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index d57e8d0..95ae1a7 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -168,4 +168,81 @@ config SYS_HYPERVISOR bool default n +config CMA + bool Contiguous Memory Allocator + depends HAVE_DMA_CONTIGUOUS HAVE_MEMBLOCK + select MIGRATION + select CMA_MIGRATE_TYPE + help + This enables the Contiguous Memory Allocator which allows drivers + to allocate big physically-contiguous blocks of memory for use with + hardware components that do not support I/O map nor scatter-gather. + + For more information see include/linux/dma-contiguous.h. + If unsure, say n. + +if CMA + +config CMA_DEBUG + bool CMA debug messages (DEVELOPEMENT) + help + Turns on debug messages in CMA. This produces KERN_DEBUG + messages for every CMA call as well as various messages while + processing calls such as dma_alloc_from_contiguous(). + This option does not affect warning and error messages. + +comment Default contiguous memory area size: + +config CMA_SIZE_ABSOLUTE + int Absolute size (in MiB) + default 16 + help + Defines the size (in MiB) of the default memory area for Contiguous + Memory Allocator. + +config CMA_SIZE_PERCENTAGE + int Percentage of total memory + default 10 + help + Defines the size of the default memory area for Contiguous Memory + Allocator as a percentage of the total memory in the system. + +choice + prompt Selected region size + default CMA_SIZE_SEL_ABSOLUTE + +config CMA_SIZE_SEL_ABSOLUTE + bool Use absolute value only + +config CMA_SIZE_SEL_PERCENTAGE + bool Use percentage value only + +config CMA_SIZE_SEL_MIN + bool Use lower value (minimum) + +config CMA_SIZE_SEL_MAX + bool Use higher value (maximum) + +endchoice + +config CMA_ALIGNMENT + int Maximum PAGE_SIZE order of alignment for contiguous buffers + range 4 9 + default 8 + help + DMA mapping framework by default aligns all buffers to the smallest + PAGE_SIZE order which is greater than or equal to the requested buffer + size. This works well for buffers up to a few hundreds kilobytes, but + for larger buffers it just a memory waste. With this parameter you can + specify the maximum PAGE_SIZE order for contiguous buffers. Larger + buffers will be aligned only to this specified order. The order is + expressed as a power of two multiplied by the PAGE_SIZE. + + For example, if your system defaults to 4KiB pages, the order value + of 8 means that the buffers will be aligned up to 1MiB only. + + If unsure, leave the default value 8. + +endif + endmenu diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 4c5701c..be6aab4 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -5,6 +5,7 @@ obj-y := core.o sys.o bus.o dd.o syscore.o \ cpu.o firmware.o init.o map.o devres.o \ attribute_container.o transport_class.o obj-$(CONFIG_DEVTMPFS) += devtmpfs.o +obj-$(CONFIG_CMA) += dma-contiguous.o obj-y += power/ obj-$(CONFIG_HAS_DMA) += dma-mapping.o obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c new file mode 100644 index 000..707b901 --- /dev/null +++ b/drivers/base/dma-contiguous.c @@ -0,0 +1,367 @@ +/* + * Contiguous Memory Allocator for DMA mapping framework + * Copyright (c) 2010-2011 by Samsung Electronics. + *
[PATCH 8/8] ARM: S5PV210: example of CMA private area for FIMC device on Goni board
This patch is an example how device private CMA area can be activated.
It creates one CMA region and assigns it to the first s5p-fimc device on
Samsung Goni S5PC110 board.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
arch/arm/mach-s5pv210/Kconfig |1 +
arch/arm/mach-s5pv210/mach-goni.c |8
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 37b5a97..c09a92c 100644
--- a/arch/arm/mach-s5pv210/Kconfig
+++ b/arch/arm/mach-s5pv210/Kconfig
@@ -64,6 +64,7 @@ menu S5PC110 Machines
config MACH_AQUILA
bool Aquila
select CPU_S5PV210
+ select CMA
select S3C_DEV_FB
select S5P_DEV_FIMC0
select S5P_DEV_FIMC1
diff --git a/arch/arm/mach-s5pv210/mach-goni.c
b/arch/arm/mach-s5pv210/mach-goni.c
index 31d5aa7..d9e565d 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -26,6 +26,7 @@
#include linux/input.h
#include linux/gpio.h
#include linux/interrupt.h
+#include linux/dma-contiguous.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -886,6 +887,12 @@ static void __init goni_machine_init(void)
platform_add_devices(goni_devices, ARRAY_SIZE(goni_devices));
}
+static void __init goni_reserve(void)
+{
+ /* Create private 16MiB contiguous memory area for s5p-fimc.0 device */
+ dma_declare_contiguous(s5p_device_fimc0.dev, 16*SZ_1M, 0);
+}
+
MACHINE_START(GONI, GONI)
/* Maintainers: Kyungmin Park kyungmin.p...@samsung.com */
.boot_params= S5P_PA_SDRAM + 0x100,
@@ -893,4 +900,5 @@ MACHINE_START(GONI, GONI)
.map_io = goni_map_io,
.init_machine = goni_machine_init,
.timer = s5p_timer,
+ .reserve= goni_reserve,
MACHINE_END
--
1.7.1.569.g6f426
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.1] Various fixes: v4l2-ctrls.c, vivi and DocBook
Some small stuff: a fix for a copy-and-paste error introduced in v4l2-ctrls.c, a fix for a missing event, a DocBook typo fix and the vivi sleep-in-atomic context fix that I posted earlier as a separate patch. Regards, Hans The following changes since commit df6aabbeb2b8799d97f3886fc994c318bc6a6843: [media] v4l2-ctrls.c: add support for V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK (2011-07-01 20:54:51 -0300) are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git fixes Hans Verkuil (4): v4l2-ctrls.c: copy-and-paste error: user_to_new - new_to_user v4l2-ctrls: always send an event if a control changed implicitly DocBook: fix typo: vl42_plane_pix_format - v4l2_plane_pix_format vivi: Fix sleep-in-atomic-context Documentation/DocBook/media/v4l/pixfmt.xml |2 +- drivers/media/video/v4l2-ctrls.c |9 +++-- drivers/media/video/vivi.c |6 +++--- 3 files changed, 11 insertions(+), 6 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
RE: [PATCH 6/8] drivers: add Contiguous Memory Allocator
Hello, On Tuesday, July 05, 2011 9:42 AM Marek Szyprowski wrote: 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 --- drivers/base/Kconfig | 77 + drivers/base/Makefile |1 + drivers/base/dma-contiguous.c | 367 include/linux/dma-contiguous.h | 104 +++ 4 files changed, 549 insertions(+), 0 deletions(-) create mode 100644 drivers/base/dma-contiguous.c create mode 100644 include/linux/dma-contiguous.h diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index d57e8d0..95ae1a7 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -168,4 +168,81 @@ config SYS_HYPERVISOR bool default n +config CMA + bool Contiguous Memory Allocator + depends HAVE_DMA_CONTIGUOUS HAVE_MEMBLOCK The above line should be obviously depends on HAVE_DMA_CONTIGUOUS HAVE_MEMBLOCK. I'm sorry for posting broken version. (snipped) 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
[PATCH 6/8 RESEND] drivers: add Contiguous Memory Allocator
The Contiguous Memory Allocator is a set of helper functions for DMA mapping framework that improves allocations of contiguous memory chunks. CMA grabs memory on system boot, marks it with CMA_MIGRATE_TYPE and gives back to the system. Kernel is allowed to allocate movable pages within CMA's managed memory so that it can be used for example for page cache when DMA mapping do not use it. On dma_alloc_from_contiguous() request such pages are migrated out of CMA area to free required contiguous block and fulfill the request. This allows to allocate large contiguous chunks of memory at any time assuming that there is enough free memory available in the system. This code is heavily based on earlier works by Michal Nazarewicz. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com CC: Michal Nazarewicz min...@mina86.com --- arch/Kconfig |3 + drivers/base/Kconfig | 77 + drivers/base/Makefile |1 + drivers/base/dma-contiguous.c | 367 include/linux/dma-contiguous.h | 104 +++ 5 files changed, 552 insertions(+), 0 deletions(-) create mode 100644 drivers/base/dma-contiguous.c create mode 100644 include/linux/dma-contiguous.h diff --git a/arch/Kconfig b/arch/Kconfig index 26b0e23..228d761 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -124,6 +124,9 @@ config HAVE_ARCH_TRACEHOOK config HAVE_DMA_ATTRS bool +config HAVE_DMA_CONTIGUOUS + bool + config USE_GENERIC_SMP_HELPERS bool diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index d57e8d0..c690d05 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -168,4 +168,81 @@ config SYS_HYPERVISOR bool default n +config CMA + bool Contiguous Memory Allocator + depends on HAVE_DMA_CONTIGUOUS HAVE_MEMBLOCK + select MIGRATION + select CMA_MIGRATE_TYPE + help + This enables the Contiguous Memory Allocator which allows drivers + to allocate big physically-contiguous blocks of memory for use with + hardware components that do not support I/O map nor scatter-gather. + + For more information see include/linux/dma-contiguous.h. + If unsure, say n. + +if CMA + +config CMA_DEBUG + bool CMA debug messages (DEVELOPEMENT) + help + Turns on debug messages in CMA. This produces KERN_DEBUG + messages for every CMA call as well as various messages while + processing calls such as dma_alloc_from_contiguous(). + This option does not affect warning and error messages. + +comment Default contiguous memory area size: + +config CMA_SIZE_ABSOLUTE + int Absolute size (in MiB) + default 16 + help + Defines the size (in MiB) of the default memory area for Contiguous + Memory Allocator. + +config CMA_SIZE_PERCENTAGE + int Percentage of total memory + default 10 + help + Defines the size of the default memory area for Contiguous Memory + Allocator as a percentage of the total memory in the system. + +choice + prompt Selected region size + default CMA_SIZE_SEL_ABSOLUTE + +config CMA_SIZE_SEL_ABSOLUTE + bool Use absolute value only + +config CMA_SIZE_SEL_PERCENTAGE + bool Use percentage value only + +config CMA_SIZE_SEL_MIN + bool Use lower value (minimum) + +config CMA_SIZE_SEL_MAX + bool Use higher value (maximum) + +endchoice + +config CMA_ALIGNMENT + int Maximum PAGE_SIZE order of alignment for contiguous buffers + range 4 9 + default 8 + help + DMA mapping framework by default aligns all buffers to the smallest + PAGE_SIZE order which is greater than or equal to the requested buffer + size. This works well for buffers up to a few hundreds kilobytes, but + for larger buffers it just a memory waste. With this parameter you can + specify the maximum PAGE_SIZE order for contiguous buffers. Larger + buffers will be aligned only to this specified order. The order is + expressed as a power of two multiplied by the PAGE_SIZE. + + For example, if your system defaults to 4KiB pages, the order value + of 8 means that the buffers will be aligned up to 1MiB only. + + If unsure, leave the default value 8. + +endif + endmenu diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 4c5701c..be6aab4 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -5,6 +5,7 @@ obj-y := core.o sys.o bus.o dd.o syscore.o \ cpu.o firmware.o init.o map.o devres.o \ attribute_container.o transport_class.o obj-$(CONFIG_DEVTMPFS) += devtmpfs.o +obj-$(CONFIG_CMA) += dma-contiguous.o obj-y += power/ obj-$(CONFIG_HAS_DMA) += dma-mapping.o
[GIT PULL FOR 3.1] Bitmask controls, flash API and adp1653 driver
Hi Mauro, This pull request adds the bitmask controls, flash API and the adp1653 driver. Changes since the first pull request: - Added a patch to document the V4L2 control endianness. It's on the top. - Rebased the patches. I haven't tested vivi, though. - The adp1653 uses dev_pm_ops instead of i2c ops for suspend/resume. Changes since the last patchset since the first pull request: - Adp1653 flash faults control is volatile. Fix this. - Flash interface marked as experimental. - Moved the DocBook documentation to a new location. - The target version is 3.1, not 2.6.41. The following changes since commit df6aabbeb2b8799d97f3886fc994c318bc6a6843: [media] v4l2-ctrls.c: add support for V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK (2011-07-01 20:54:51 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.1-flash-3 Hans Verkuil (3): v4l2-ctrls: add new bitmask control type. vivi: add bitmask test control. DocBook: document V4L2_CTRL_TYPE_BITMASK. Sakari Ailus (4): v4l: Add a class and a set of controls for flash devices. v4l: Add flash control documentation adp1653: Add driver for LED flash controller v4l: Document V4L2 control endianness as machine endianness. Documentation/DocBook/media/v4l/compat.xml | 11 + Documentation/DocBook/media/v4l/controls.xml | 291 Documentation/DocBook/media/v4l/v4l2.xml |6 +- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |7 + .../DocBook/media/v4l/vidioc-queryctrl.xml | 12 +- drivers/media/video/Kconfig|9 + drivers/media/video/Makefile |1 + drivers/media/video/adp1653.c | 491 drivers/media/video/v4l2-common.c |3 + drivers/media/video/v4l2-ctrls.c | 62 +++- drivers/media/video/vivi.c | 18 +- include/linux/videodev2.h | 37 ++ include/media/adp1653.h| 126 + 13 files changed, 1067 insertions(+), 7 deletions(-) create mode 100644 drivers/media/video/adp1653.c create mode 100644 include/media/adp1653.h -- Sakari Ailus sakari.ai...@iki.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 1/8] mm: move some functions from memory_hotplug.c to page_isolation.c
On Tuesday 05 July 2011, Marek Szyprowski wrote: From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com Memory hotplug is a logic for making pages unused in the specified range of pfn. So, some of core logics can be used for other purpose as allocating a very large contigous memory block. This patch moves some functions from mm/memory_hotplug.c to mm/page_isolation.c. This helps adding a function for large-alloc in page_isolation.c with memory-unplug technique. Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com [m.nazarewicz: reworded commit message] Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com [m.szyprowski: rebased and updated to Linux v3.0-rc1] Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com CC: Michal Nazarewicz min...@mina86.com Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] mm: alloc_contig_freed_pages() added
On Tuesday 05 July 2011, Marek Szyprowski wrote: From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com This commit introduces alloc_contig_freed_pages() function which allocates (ie. removes from buddy system) free pages in range. Caller has to guarantee that all pages in range are in buddy system. Along with this function, a free_contig_pages() function is provided which frees all (or a subset of) pages allocated with alloc_contig_free_pages(). Michal Nazarewicz has modified the function to make it easier to allocate not MAX_ORDER_NR_PAGES aligned pages by making it return pfn of one-past-the-last allocated page. Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com CC: Michal Nazarewicz min...@mina86.com Acked-by: Arnd Bergmann a...@arndb.de -- 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] mm: alloc_contig_range() added
On Tuesday 05 July 2011, Marek Szyprowski wrote: From: Michal Nazarewicz m.nazarew...@samsung.com This commit adds the alloc_contig_range() function which tries to allecate given range of pages. It tries to migrate all already allocated pages that fall in the range thus freeing them. Once all pages in the range are freed they are removed from the buddy system thus allocated for the caller to use. Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com [m.szyprowski: renamed some variables for easier code reading] Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com CC: Michal Nazarewicz min...@mina86.com Acked-by: Arnd Bergmann a...@arndb.de -- 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 6/8] drivers: add Contiguous Memory Allocator
On Tue, Jul 05, 2011 at 09:41:48AM +0200, Marek Szyprowski wrote: 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. And how are you addressing the technical concerns about aliasing of cache attributes which I keep bringing up with this and you keep ignoring and telling me that I'm standing in your way. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL for v3.0] OMAP_VOUT bug fixes and code cleanup
-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@redhat.com]
Sent: Saturday, July 02, 2011 12:13 AM
To: Hiremath, Vaibhav
Cc: linux-media@vger.kernel.org; JAIN, AMBER; David Rientjes; Andrew
Morton
Subject: Re: [GIT PULL for v3.0] OMAP_VOUT bug fixes and code cleanup
Em 22-06-2011 16:32, hvaib...@ti.com escreveu:
The following changes since commit
af0d6a0a3a30946f7df69c764791f1b0643f7cd6:
Linus Torvalds (1):
Merge branch 'x86-urgent-for-linus' of
git://git.kernel.org/.../tip/linux-2.6-tip
are available in the git repository at:
git://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git for-
linux-media
Amber Jain (2):
V4L2: omap_vout: Remove GFP_DMA allocation as ZONE_DMA is not
configured on OMAP
OMAP2: V4L2: Remove GFP_DMA allocation as ZONE_DMA is not
configured on OMAP
From: Amber Jain am...@ti.com
Date: Tue May 31 11:45:36 2011 -0300
OMAP2: V4L2: Remove GFP_DMA allocation as ZONE_DMA is not configured on
OMAP
Remove GFP_DMA from the __get_free_pages() call from omap24xxcam as
ZONE_DMA
is not configured on OMAP. Earlier the page allocator used to return a
page
from ZONE_NORMAL even when GFP_DMA is passed and CONFIG_ZONE_DMA is
disabled.
As a result of commit a197b59ae6e8bee56fcef37ea2482dc08414e2ac, page
allocator
returns null in such a scenario with a warning emitted to kernel log.
Signed-off-by: Amber Jain am...@ti.com
Acked-by: Sakari Ailus sakari.ai...@iki.fi
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
diff --git a/drivers/media/video/omap24xxcam.c
b/drivers/media/video/omap24xxcam.c
index f6626e8..d92d4c6 100644
--- a/drivers/media/video/omap24xxcam.c
+++ b/drivers/media/video/omap24xxcam.c
@@ -309,11 +309,11 @@ static int
omap24xxcam_vbq_alloc_mmap_buffer(struct videobuf_buffer *vb)
order--;
/* try to allocate as many contiguous pages as possible */
- page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
+ page = alloc_pages(GFP_KERNEL, order);
/* if allocation fails, try to allocate smaller amount */
while (page == NULL) {
order--;
- page = alloc_pages(GFP_KERNEL | GFP_DMA, order);
+ page = alloc_pages(GFP_KERNEL, order);
if (page == NULL !order) {
err = -ENOMEM;
goto out;
Hmm... the proper fix wouldn't be to define ZONE_DMA at OMAP?
I don't think so, my understanding for ZOME_DMA is that it is defined for
architectures that have restrictions on memory addresses that can be used for
DMA. OMAP doesn't have any such restriction and hence we should not define
ZONE_DMA.
Please let me know if I have missed some point.
Thanks,
Amber
Thanks,
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
omap3isp: known causes of CCDC won't become idle!
Hi Laurent, I'm just trying to get an mt9v034 sensor working on a beagle xm. Everything more or less works, except that after a random number of frames of capture, I tend to get won't become idle messages and the vd0 and vd1 interrupts tend to turn up at same time. I was just wondering if there are any known issues with the ccdc driver / silicon that might explain this? I also note that it appears to be impossible to disable HS_VS_IRQ despite the datasheet claiming this can be done. Is this a known issue? Thanks, Jonathan -- 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/8] mm: MIGRATE_CMA migration type added
On Tuesday 05 July 2011, Marek Szyprowski wrote:
From: Michal Nazarewicz m.nazarew...@samsung.com
The MIGRATE_CMA migration type has two main characteristics:
(i) only movable pages can be allocated from MIGRATE_CMA
pageblocks and (ii) page allocator will never change migration
type of MIGRATE_CMA pageblocks.
This guarantees that page in a MIGRATE_CMA page block can
always be migrated somewhere else (unless there's no memory left
in the system).
It is designed to be used with Contiguous Memory Allocator
(CMA) for allocating big chunks (eg. 10MiB) of physically
contiguous memory. Once driver requests contiguous memory,
CMA will migrate pages from MIGRATE_CMA pageblocks.
To minimise number of migrations, MIGRATE_CMA migration type
is the last type tried when page allocator falls back to other
migration types then requested.
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[m.szyprowski: cleaned up Kconfig, renamed some functions]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
Acked-by: Arnd Bergmann a...@arndb.de, but I noticed a few things:
cma migrate fixup
This text doesn't belong here.
+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_TYPE
+ /*
+ * 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
+};
It's not clear to me why you need this #ifdef. Does it hurt if the
migration type is defined but not used?
@@ -198,6 +198,12 @@ config MIGRATION
pages as migration can relocate pages to satisfy a huge page
allocation instead of reclaiming.
+config CMA_MIGRATE_TYPE
+ bool
+ help
+ This enables the use the MIGRATE_CMA migrate type, which lets lets CMA
+ work on almost arbitrary memory range and not only inside
ZONE_MOVABLE.
+
config PHYS_ADDR_T_64BIT
def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
This is currently only selected on ARM with your patch set.
diff --git a/mm/compaction.c b/mm/compaction.c
index 6cc604b..9e5cc59 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -119,6 +119,16 @@ static bool suitable_migration_target(struct page *page)
if (migratetype == MIGRATE_ISOLATE || migratetype == MIGRATE_RESERVE)
return false;
+ /* Keep MIGRATE_CMA alone as well. */
+ /*
+ * XXX Revisit. We currently cannot let compaction touch CMA
+ * pages since compaction insists on changing their migration
+ * type to MIGRATE_MOVABLE (see split_free_page() called from
+ * isolate_freepages_block() above).
+ */
+ if (is_migrate_cma(migratetype))
+ return false;
+
/* If the page is a large free page, then allow migration */
if (PageBuddy(page) page_order(page) = pageblock_order)
return true;
Do you plan to fix address this before merging the patch set, or is
it harmless enough to get in this way?
/*
* The order of subdivision here is critical for the IO subsystem.
@@ -827,11 +852,15 @@ 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][4] = {
[MIGRATE_UNMOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE,
MIGRATE_RESERVE },
[MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE, MIGRATE_MOVABLE,
MIGRATE_RESERVE },
+#ifdef CONFIG_CMA_MIGRATE_TYPE
+ [MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE,
MIGRATE_CMA, MIGRATE_RESERVE },
+#else
[MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE,
MIGRATE_RESERVE },
- [MIGRATE_RESERVE] = { MIGRATE_RESERVE, MIGRATE_RESERVE,
MIGRATE_RESERVE }, /* Never used */
+#endif
+ [MIGRATE_RESERVE] = { MIGRATE_RESERVE }, /* Never used */
};
/*
@@ -1044,7 +1086,12 @@ static int rmqueue_bulk(struct zone *zone, unsigned
int order,
Re: [PATCH 5/8] mm: MIGRATE_CMA isolation functions added
On Tuesday 05 July 2011, Marek Szyprowski wrote: From: Michal Nazarewicz m.nazarew...@samsung.com This commit changes various functions that change pages and pageblocks migrate type between MIGRATE_ISOLATE and MIGRATE_MOVABLE in such a way as to allow to work with MIGRATE_CMA migrate type. Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com CC: Michal Nazarewicz min...@mina86.com Acked-by: Arnd Bergmann a...@arndb.de -- 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 6/8 RESEND] drivers: add Contiguous Memory Allocator
On Tuesday 05 July 2011, Marek Szyprowski wrote: 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 Reviewed-by: Arnd Bergmann a...@arndb.de, but I noticed two one-character mistakes: +if CMA + +config CMA_DEBUG + bool CMA debug messages (DEVELOPEMENT) s/DEVELOPEMENT/DEVELOPMENT/ diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 4c5701c..be6aab4 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -5,6 +5,7 @@ obj-y := core.o sys.o bus.o dd.o syscore.o \ cpu.o firmware.o init.o map.o devres.o \ attribute_container.o transport_class.o obj-$(CONFIG_DEVTMPFS) += devtmpfs.o +obj-$(CONFIG_CMA) += dma-contiguous.o obj-y+= power/ obj-$(CONFIG_HAS_DMA)+= dma-mapping.o Please add another tab to indent the line in the same way as the others. 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
Re: [PATCH 8/8] ARM: S5PV210: example of CMA private area for FIMC device on Goni board
On Tuesday 05 July 2011, Marek Szyprowski wrote: This patch is an example how device private CMA area can be activated. It creates one CMA region and assigns it to the first s5p-fimc device on Samsung Goni S5PC110 board. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Arnd Bergmann a...@arndb.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 7/8] ARM: integrate CMA with dma-mapping subsystem
On Tuesday 05 July 2011, Marek Szyprowski wrote: 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). Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Arnd Bergmann a...@arndb.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
[PATCH 0/4 v10] Multi Format Codec 5.1 driver for s5pv210 and exynos4 SoC
Hi, The tenth version of MFC 5.1 driver. Decoding and encoding is supported. The first version that included only decoding was done by me. The encoding part was originally done by Jeongtae Park and I did some modifications to his code. Changes since the v9 in the v4l: add fourcc definitions for compressed formats patch are minor - I have removed the DIVX format definitions as they will not be supported by MFC. In the v4l: add control definitions for codec devices. I have added the changes suggested on the list. Same goes to v4l2-ctrl: add codec controls support to the control framework. In the v4l2-ctrl patch I have also corrected names of menu control to be capitalized as in English titles. The MFC: Add MFC 5.1 V4L2 driver patch contains the driver code has also been modified accordingly to the suggestions on the linux-media list. Also I did some code cleanup. I hope that the v4l2 patches are correct, but if you have any comments then feel free to share them. I would greatly welcome comments on the MFC driver patch. The branch based on the mauro/staging/for_v3.1 with MFC patches applied can be found on the following website (it is scheduled for update later today, now contains the v9 version): http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/mfc-for-mauro Best wishes, Kamil Debski * Changelog: == Changes since v9 == 1) Remove *_VOP_TIME_RES and *_VOP_TIME_INC controls for MPEG4, the have been replaced with a call to S_PARM 2) V4L2_MPEG_MFC51_VIDEO_FRAME_SKIP_MODE_VBV_LIMIT renamed to V4L2_MPEG_MFC51_VIDEO_FRAME_SKIP_MODE_BUF_LIMIT 3) Removed a lot of debug messages that were not needed anymore 4) Code cleanup of the driver 5) Added kernel-doc comments for MFC driver structures 6) Update of handling volatile controls to conform with the latest patches by Hans Verkuil 7) Removed references to DIVX format from videodev2.h and v4l2 documentation as it is no longer supported == Changes since v8 == 1) Change code to use only dma_contig memory allocator, this removes any dependencies on other subsystems that could delay the merging of MFC to the mainline. 2) Support for per buffer controls have been removed, it will be added at later time after the initial version gets merged in mainline. This is because the support for per buffer controls was overly complicated and offered little added functionality. 3) Due to licensing issues support for DIVX has been removed from the driver. 4) Update the code to work with latest version of codec controls patch. == Changes since v7 == 1) New fourcc definitions for codecs - Fourcc definitions based on the new RFC 2) New controls defined in videodev2.h - Controls definitions based on the new RFC 3) Support for multiple memory allocators - DMA Pool, CMA and IOMMU - Now one can choose memory allocator in the kernel config. 4) Improved method of handling shared memory - by using memory barriers - Problems with using the shared memory registers have been previously addressed with cleaning and invalidating cache. Now it is handles by memory barriers and proper mapping. 5) Fixed packed PB sequence numbering - Numbering of sequence numbers was corrected for streams with packed PB. 6) Proper poll mechanism has been included - Previously poll would not distinguish between queues. == Changes since v6 == 1) Stream seeking handling - done by running stream off and then stream on from another point of the stream 2) Support for streams during which the resolution is changed - done by calling stream off, reallocating the buffers and stream on again to resume 3) Power domain handling 4) Clock gating hw related operations - This has introduced a large reduction in power use 5) Support for IOMMU allocator - Using IOMMU as the memory allocator removes the cache problem and the need for reserving continuous memory at system boot 6) Flags of v4l2_buffer are set accordingly to the returned buffer frame type V4L2_BUF_FLAG_(KEY|P|B)FRAME 7) Fixed display delay handling of H264. Now dealy of 0 frames is possible, although it may cause that the frames are returned out of order. 8) Minor changes - global s5p_mfc_dev variable has been removed - improved Packed PB handling - fixed error handling - separate for decoding and display frames - some cosmetic changes to simplify the code and make it more readable == Changes since v5 == 1) Changes suggested by Hans Verkuil: - small change in videodev2.h - corrected control offsets - made the code more readable by simplifying if statements and using temporary pointers - mfc_mutex is now included in s5p_mfc_dev structure - after discussion with Peter Oh modification of fourcc definitions (replaced DX52 and DX53 with DX50) 2) Changes suggested by JongHun Han: -
[PATCH 1/4 v10] v4l: add fourcc definitions for compressed formats.
Add fourcc definitions and documentation for the following compressed formats: H263, H264, H264 without start codes, MPEG1/2/4 ES, XVID, VC1 Annex G and Annex L compliant. Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/media/v4l/controls.xml |7 +++- Documentation/DocBook/media/v4l/pixfmt.xml | 47 +- include/linux/videodev2.h| 17 +++-- 3 files changed, 64 insertions(+), 7 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index a920ee8..6880798 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -670,7 +670,8 @@ caption of a Tab page in a GUI, for example./entry /rowrowentry spanname=descrThe MPEG-1, -2 or -4 output stream type. One cannot assume anything here. Each hardware MPEG encoder tends to support different subsets of the available MPEG -stream types. The currently defined stream types are:/entry +stream types. This control is specific to multiplexed MPEG streams. +The currently defined stream types are:/entry /row row entrytbl spanname=descr cols=2 @@ -800,6 +801,7 @@ frequency. Possible values are:/entry entry spanname=idconstantV4L2_CID_MPEG_AUDIO_ENCODING/constantnbsp;/entry entryenumnbsp;v4l2_mpeg_audio_encoding/entry /rowrowentry spanname=descrMPEG Audio encoding. +This control is specific to multiplexed MPEG streams. Possible values are:/entry /row row @@ -1250,7 +1252,8 @@ and reproducible audio bitstream. 0 = unmuted, 1 = muted./entry entry spanname=idconstantV4L2_CID_MPEG_VIDEO_ENCODING/constantnbsp;/entry entryenumnbsp;v4l2_mpeg_video_encoding/entry /rowrowentry spanname=descrMPEG Video encoding -method. Possible values are:/entry +method. This control is specific to multiplexed MPEG streams. +Possible values are:/entry /row row entrytbl spanname=descr cols=2 diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index 88e5c21..c10afa0 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -741,10 +741,55 @@ information./para row id=V4L2-PIX-FMT-MPEG entryconstantV4L2_PIX_FMT_MPEG/constant/entry entry'MPEG'/entry - entryMPEG stream. The actual format is determined by + entryMPEG multiplexed stream. The actual format is determined by extended control constantV4L2_CID_MPEG_STREAM_TYPE/constant, see xref linkend=mpeg-control-id /./entry /row + row id=V4L2-PIX-FMT-H264 + entryconstantV4L2_PIX_FMT_H264/constant/entry + entry'H264'/entry + entryH264 video elementary stream with start codes./entry + /row + row id=V4L2-PIX-FMT-H264-NO-SC + entryconstantV4L2_PIX_FMT_H264_NO_SC/constant/entry + entry'AVC1'/entry + entryH264 video elementary stream without start codes./entry + /row + row id=V4L2-PIX-FMT-H263 + entryconstantV4L2_PIX_FMT_H263/constant/entry + entry'H263'/entry + entryH263 video elementary stream./entry + /row + row id=V4L2-PIX-FMT-MPEG1 + entryconstantV4L2_PIX_FMT_MPEG1/constant/entry + entry'MPG1'/entry + entryMPEG1 video elementary stream./entry + /row + row id=V4L2-PIX-FMT-MPEG2 + entryconstantV4L2_PIX_FMT_MPEG2/constant/entry + entry'MPG2'/entry + entryMPEG2 video elementary stream./entry + /row + row id=V4L2-PIX-FMT-MPEG4 + entryconstantV4L2_PIX_FMT_MPEG4/constant/entry + entry'MPG4'/entry + entryMPEG4 video elementary stream./entry + /row + row id=V4L2-PIX-FMT-XVID + entryconstantV4L2_PIX_FMT_XVID/constant/entry + entry'XVID'/entry + entryXvid video elementary stream./entry + /row + row id=V4L2-PIX-FMT-VC1-ANNEX-G + entryconstantV4L2_PIX_FMT_VC1_ANNEX_G/constant/entry + entry'VC1G'/entry + entryVC1, SMPTE 421M Annex G compliant stream./entry + /row + row id=V4L2-PIX-FMT-VC1-ANNEX-L + entryconstantV4L2_PIX_FMT_VC1_ANNEX_L/constant/entry + entry'VC1L'/entry + entryVC1, SMPTE 421M Annex L compliant stream./entry + /row /tbody /tgroup /table diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h index 2c4e837..f47265e 100644 --- a/include/linux/videodev2.h +++
[PATCH 2/4 v10] v4l: add control definitions for codec devices.
Add control definitions and documentation for controls specific to codec devices. Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/DocBook/media/v4l/controls.xml | 969 ++ include/linux/videodev2.h| 169 +- 2 files changed, 1137 insertions(+), 1 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 6880798..0f5e97c 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -325,6 +325,22 @@ minimum value disables backlight compensation./entry constantV4L2_CID_ILLUMINATORS_2/constant + 1)./entry /row row + entryconstantV4L2_CID_MIN_BUFFERS_FOR_CAPTURE/constant/entry + entryinteger/entry + entryThis is a read-only control that can be read by the application +and used as a hint to determine the number of CAPTURE buffers to pass to REQBUFS. +The value is the minimum number of CAPTURE buffers that is necessary for hardware +to work./entry + /row + row + entryconstantV4L2_CID_MIN_BUFFERS_FOR_OUTPUT/constant/entry + entryinteger/entry + entryThis is a read-only control that can be read by the application +and used as a hint to determine the number of OUTPUT buffers to pass to REQBUFS. +The value is the minimum number of OUTPUT buffers that is necessary for hardware +to work./entry + /row + row entryconstantV4L2_CID_PRIVATE_BASE/constant/entry entry/entry entryID of the first custom (driver specific) control. @@ -1409,6 +1425,959 @@ of the video. The supplied 32-bit integer is interpreted as follows (bit /tbody /entrytbl /row + + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrIf enabled the decoder expects to receive a single slice per buffer, otherwise +the decoder expects a single frame in per buffer. Applicable to the decoder, all codecs. +/entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_VUI_SAR_ENABLE/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnable writing sample aspect ratio in the Video Usability Information. +Applicable to the H264 encoder./entry + /row + + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_MPEG_VIDEO_H264_VUI_SAR_IDC/constantnbsp;/entry + entryenumnbsp;v4l2_mpeg_video_h264_vui_sar_idc/entry + /row + rowentry spanname=descrVUI sample aspect ratio indicator for H.264 encoding. The value +is defined in the table E-1 in the standard. Applicable to the H264 encoder./entry + /row + row + entrytbl spanname=descr cols=2 + tbody valign=top + + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_UNSPECIFIED/constantnbsp;/entry + entryUnspecified/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_1x1/constantnbsp;/entry + entry1x1/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_12x11/constantnbsp;/entry + entry12x11/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_10x11/constantnbsp;/entry + entry10x11/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_16x11/constantnbsp;/entry + entry16x11/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_40x33/constantnbsp;/entry + entry40x33/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_24x11/constantnbsp;/entry + entry24x11/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_20x11/constantnbsp;/entry + entry20x11/entry + /row + row + entryconstantV4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_32x11/constantnbsp;/entry +
[PATCH 3/4 v10] v4l2-ctrl: add codec controls support to the control framework
Add support for the codec controls to the v4l2 control framework.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-ctrls.c | 197 +-
1 files changed, 192 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 37a50e5..4e629a0 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -203,7 +203,7 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
};
static const char * const mpeg_stream_vbi_fmt[] = {
No VBI,
- Private packet, IVTV format,
+ Private Packet, IVTV Format,
NULL
};
static const char * const camera_power_line_frequency[] = {
@@ -226,18 +226,118 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Negative,
Emboss,
Sketch,
- Sky blue,
- Grass green,
- Skin whiten,
+ Sky Blue,
+ Grass Green,
+ Skin Whiten,
Vivid,
NULL
};
static const char * const tune_preemphasis[] = {
- No preemphasis,
+ No Preemphasis,
50 useconds,
75 useconds,
NULL,
};
+ static const char * const header_mode[] = {
+ Separate Buffer,
+ Joined With 1st Frame,
+ NULL,
+ };
+ static const char * const multi_slice[] = {
+ Single,
+ Max Macroblocks,
+ Max Bytes,
+ NULL,
+ };
+ static const char * const entropy_mode[] = {
+ CAVLC,
+ CABAC,
+ NULL,
+ };
+ static const char * const mpeg_h264_level[] = {
+ 1,
+ 1b,
+ 1.1,
+ 1.2,
+ 1.3,
+ 2,
+ 2.1,
+ 2.2,
+ 3,
+ 3.1,
+ 3.2,
+ 4,
+ 4.1,
+ 4.2,
+ 5,
+ 5.1,
+ NULL,
+ };
+ static const char * const h264_loop_filter[] = {
+ Enabled,
+ Disabled,
+ Disabled at Slice Boundary,
+ NULL,
+ };
+ static const char * const h264_profile[] = {
+ Baseline,
+ Constrained Baseline,
+ Main,
+ Extended,
+ High,
+ High 10,
+ High 422,
+ High 444 Predictive,
+ High 10 Intra,
+ High 422 Intra,
+ High 444 Intra,
+ CAVLC 444 Intra,
+ Scalable Baseline,
+ Scalable High,
+ Scalable High Intra,
+ Multiview High,
+ NULL,
+ };
+ static const char * const vui_sar_idc[] = {
+ Unspecified,
+ 1:1,
+ 12:11,
+ 10:11,
+ 16:11,
+ 40:33,
+ 24:11,
+ 20:11,
+ 32:11,
+ 80:33,
+ 18:11,
+ 15:11,
+ 64:33,
+ 160:99,
+ 4:3,
+ 3:2,
+ 2:1,
+ Extended SAR,
+ NULL,
+ };
+ static const char * const mpeg_mpeg4_level[] = {
+ 0,
+ 0b,
+ 1,
+ 2,
+ 3,
+ 3b,
+ 4,
+ 5,
+ NULL,
+ };
+ static const char * const mpeg4_profile[] = {
+ Simple,
+ Adcanved Simple,
+ Core,
+ Simple Scalable,
+ Advanced Coding Efficency,
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -278,6 +378,24 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
return tune_preemphasis;
+ case V4L2_CID_MPEG_VIDEO_HEADER_MODE:
+ return header_mode;
+ case V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MODE:
+ return multi_slice;
+ case V4L2_CID_MPEG_VIDEO_H264_ENTROPY_MODE:
+ return entropy_mode;
+ case V4L2_CID_MPEG_VIDEO_H264_LEVEL:
+ return mpeg_h264_level;
+ case V4L2_CID_MPEG_VIDEO_H264_LOOP_FILTER_MODE:
+ return h264_loop_filter;
+ case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
+ return h264_profile;
+ case V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_IDC:
+ return vui_sar_idc;
+ case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
+ return mpeg_mpeg4_level;
Re: [PATCHv11 0/8] Contiguous Memory Allocator
On Tuesday 05 July 2011, Marek Szyprowski wrote: This is yet another round of Contiguous Memory Allocator patches. I hope that I've managed to resolve all the items discussed during the Memory Management summit at Linaro Meeting in Budapest and pointed later on mailing lists. The goal is to integrate it as tight as possible with other kernel subsystems (like memory management and dma-mapping) and finally merge to mainline. You have certainly addressed all of my concerns, this looks really good now! Andrew, can you add this to your -mm tree? What's your opinion on the current state, do you think this is ready for merging in 3.1 or would you want to have more reviews from core memory management people? My reviews were mostly on the driver and platform API side, and I think we're fine there now, but I don't really understand the impacts this has in mm. 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
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Em 05-07-2011 04:26, Hans Verkuil escreveu:
On Monday, July 04, 2011 18:09:18 Mauro Carvalho Chehab wrote:
Em 29-06-2011 09:51, Tomasz Stanislawski escreveu:
The 1080p59_94 is supported by latest Samsung SoC.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/v4l2-common.c |1 +
include/linux/videodev2.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 06b9f9f..003e648 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -582,6 +582,7 @@ int v4l_fill_dv_preset_info(u32 preset, struct
v4l2_dv_enum_preset *info)
{ 1920, 1080, 1080p@30 }, /* V4L2_DV_1080P30 */
{ 1920, 1080, 1080p@50 }, /* V4L2_DV_1080P50 */
{ 1920, 1080, 1080p@60 }, /* V4L2_DV_1080P60 */
+ { 1920, 1080, 1080p@59.94 }, /* V4L2_DV_1080P59_94 */
};
if (info == NULL || preset = ARRAY_SIZE(dv_presets))
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 8a4c309..7c77c4e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -872,6 +872,7 @@ struct v4l2_dv_enum_preset {
#defineV4L2_DV_1080P30 16 /* SMPTE 296M */
#defineV4L2_DV_1080P50 17 /* BT.1120 */
#defineV4L2_DV_1080P60 18 /* BT.1120 */
+#defineV4L2_DV_1080P59_94 19
/*
* D V B T T I M I N G S
This patch deserves further discussions, as the specs that define the presets
are not so clear with respect to 60Hz and 60/1.001 Hz.
Let me summarize the issue.
1) PRESET STANDARDS
== =
There are 3 specs involved with DV presets: ITU-R BT 709 and BT 1120 and CEA
861.
At ITU-R BT.709, both 60Hz and 60/1.001 Hz are equally called as 60 Hz.
BT.1120
follows the same logic, as it uses BT.709 as a reference for video timings.
The CEA-861-E spec says at item 4, that:
A video timing with a vertical frequency that is an integer multiple of
6.00 Hz (i.e. 24.00, 30.00, 60.00,
120.00 or 240.00 Hz) is considered to be the same as a video timing
with the equivalent detailed timing
information but where the vertical frequency is adjusted by a factor of
1000/1001 (i.e., 24/1.001, 30/1.001,
60/1.001, 120/1.001 or 240/1.001). That is, they are considered two
versions of the same video timing but
with slightly different pixel clock frequencies. Therefore, a DTV that
declares it is capable of displaying a
video timing with a vertical frequency that is either an integer
multiple of 6 Hz or an integer multiple of 6
Hz adjusted by a factor of 1000/1001 shall be capable of displaying
both versions of the video timing.
At the same item, the table 2 describes several video parameters for each
preset, associating the
Video Identification Codes (VIC) for each preset.
No, *multiple VICs* are associated with each preset. VIC != preset.
There are two VIC's for several presets, as it is also used at the spec to
determine the aspect ratio, but, basically,
for one given VIC, there's just one timings preset at the table 2.
Also, the VICs do not differentiate between 60 and 59.94 Hz.
Yes, but V4L2 DV timings also don't differentiate.
Table 4 associates each VIC with the supported formats. For example, VIC 16
means a resolution of
1920x1080 at 59.94Hz/60Hz. The spec does explicitly allow that all vertical
frequencies that are
multiple of 6 Hz to accept both 59.94 Hz and 60 Hz, as said at note 3 of
table 2:
3. A video timing with a vertical frequency that is an integer multiple
of 6.00 Hz (i.e. 24.00, 30.00, 60.00, 120.00 or
240.00 Hz) is considered to be the same as a video timing with the
equivalent detailed timing information but where
the vertical frequency is adjusted by a factor of 1000/1001 (i.e.,
24/1.001, 30/1.001, 60/1.001, 120/1.001 or
240/1.001). That is, they are considered two versions of the same video
timing but with slightly different pixel clock
frequencies. The vertical frequencies of the 240p, 480p, and 480i video
formats are typically adjusted by a factor of
exactly 1000/1001 for NTSC video compatibility, while the 576p, 576i,
and the HDTV video formats are not. The
VESA DMT standard [65] specifies a ± 0.5% pixel clock frequency
tolerance. Therefore, the nominally 25.175 MHz
pixel clock frequency value given for video identification code 1 may
be adjusted to 25.2 MHz to obtain an exact 60
Hz vertical frequency.
In other words, the preset for 1920x1080p@60Hz can be used for both 60Hz and
59.94 Hz,
according with the above note, being 59.94 Hz the typical value (e. g. the
value that
should be used on most places).
Re: omap3isp: known causes of CCDC won't become idle!
On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: Hi Laurent, I'm just trying to get an mt9v034 sensor working on a beagle xm. Everything more or less works, except that after a random number of frames of capture, I tend to get won't become idle messages and the vd0 and vd1 interrupts tend to turn up at same time. I was just wondering if there are any known issues with the ccdc driver / silicon that might explain this? I also note that it appears to be impossible to disable HS_VS_IRQ despite the datasheet claiming this can be done. Is this a known issue? The same interrupt may be used to produce an interrupt per horizontal sync but the driver doesn't use that. I remember of a case where the two sync signals had enough crosstalk to cause vertical sync interrupt per every horizontal sync. (It's been discussed on this list.) This might not be the case here, though: you should be flooded with HS_VS interrupts. The VD* counters are counting and interrupts are produced (AFAIR) even if the CCDC is disabled. Once the CCDC starts receiving a frame, it becomes busy, and becomes idle only when it has received the full frame. For this reason it's important that the full frame is actually received by the CCDC, otherwise this is due to happen when the CCDC is being stopped at the end of the stream. Regards, -- Sakari Ailus sakari.ai...@iki.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: omap3isp: known causes of CCDC won't become idle!
Hi Sakari, On Tuesday 05 July 2011 14:19:16 Sakari Ailus wrote: On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: Hi Laurent, I'm just trying to get an mt9v034 sensor working on a beagle xm. Everything more or less works, except that after a random number of frames of capture, I tend to get won't become idle messages and the vd0 and vd1 interrupts tend to turn up at same time. I was just wondering if there are any known issues with the ccdc driver / silicon that might explain this? I also note that it appears to be impossible to disable HS_VS_IRQ despite the datasheet claiming this can be done. Is this a known issue? The same interrupt may be used to produce an interrupt per horizontal sync but the driver doesn't use that. I remember of a case where the two sync signals had enough crosstalk to cause vertical sync interrupt per every horizontal sync. (It's been discussed on this list.) This might not be the case here, though: you should be flooded with HS_VS interrupts. It was worse than that, it was crosstalk between the pixel clock and the vsync signal, resulting in one vsync interrupt per pixel. The VD* counters are counting and interrupts are produced (AFAIR) even if the CCDC is disabled. If I'm not mistaken the interrupts can be produced if the CCDC is disabled, but clearing the interrupt enable bit for the HS_VS interrupt should prevent them from being generated. Once the CCDC starts receiving a frame, it becomes busy, and becomes idle only when it has received the full frame. For this reason it's important that the full frame is actually received by the CCDC, otherwise this is due to happen when the CCDC is being stopped at the end of the stream. You also need to make sure that the input stream contains enough vertical blanking, otherwise the ISP driver might not have time to restart the CCDC before the beginning of the next frame, especially under high load conditions. -- 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 6/8] drivers: add Contiguous Memory Allocator
On Tuesday 05 July 2011, Russell King - ARM Linux wrote: On Tue, Jul 05, 2011 at 09:41:48AM +0200, Marek Szyprowski wrote: 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. And how are you addressing the technical concerns about aliasing of cache attributes which I keep bringing up with this and you keep ignoring and telling me that I'm standing in your way. This is of course an important issue, and it's the one item listed as TODO in the introductory mail that sent. It's also a preexisting problem as far as I can tell, and it needs to be solved in __dma_alloc for both cases, dma_alloc_from_contiguous and __alloc_system_pages as introduced in patch 7. We've discussed this back and forth, and it always comes down to one of two ugly solutions: 1. Put all of the MIGRATE_CMA and pages into highmem and change __alloc_system_pages so it also allocates only from highmem pages. The consequences of this are that we always need to build kernels with highmem enabled and that we have less lowmem on systems that are already small, both of which can be fairly expensive unless you have lots of highmem already. 2. Add logic to unmap pages from the linear mapping, which is very expensive because it forces the use of small pages in the linear mapping (or in parts of it), and possibly means walking all page tables to remove the PTEs on alloc and put them back in on free. I believe that Chunsang Jeong from Linaro is planning to implement both variants and post them for review, so we can decide which one to merge, or even to merge both and make it a configuration option. See also https://blueprints.launchpad.net/linaro-mm-sig/+spec/engr-mm-dma-mapping-2011.07 I don't think we need to make merging the CMA patches depending on the other patches, it's clear that both need to be solved, and they are independent enough. 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
Re: [PATCH 4/8] mm: MIGRATE_CMA migration type added
On Tue, Jul 05, 2011 at 01:44:31PM +0200, Arnd Bergmann wrote: @@ -198,6 +198,12 @@ config MIGRATION pages as migration can relocate pages to satisfy a huge page allocation instead of reclaiming. +config CMA_MIGRATE_TYPE + bool + help + This enables the use the MIGRATE_CMA migrate type, which lets lets CMA + work on almost arbitrary memory range and not only inside ZONE_MOVABLE. + config PHYS_ADDR_T_64BIT def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT This is currently only selected on ARM with your patch set. That's because CMA is targeted at solving the we need massive contiguous DMA areas problem on ARM SoCs. And it does this without addressing the technical architecture problems surrounding multiple aliasing mappings with differing attributes which actually make it unsuitable for use on ARM. This is not the first time I've pointed that out, and I'm now at the point of basically ignoring this CMA work because I'm tired of constantly pointing this out. My silence on this subject must not be taken as placid acceptance of the approach, but revulsion at seemingly being constantly ignored and having these patches pushed time and time again with nothing really changing on that issue. It will be a sad day if these patches make their way into mainline without that being addressed, and will show contempt for architecture maintainers if it does. -- 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: [PATCHv11 0/8] Contiguous Memory Allocator
On Tue, Jul 05, 2011 at 02:07:17PM +0200, Arnd Bergmann wrote: On Tuesday 05 July 2011, Marek Szyprowski wrote: This is yet another round of Contiguous Memory Allocator patches. I hope that I've managed to resolve all the items discussed during the Memory Management summit at Linaro Meeting in Budapest and pointed later on mailing lists. The goal is to integrate it as tight as possible with other kernel subsystems (like memory management and dma-mapping) and finally merge to mainline. You have certainly addressed all of my concerns, this looks really good now! Andrew, can you add this to your -mm tree? What's your opinion on the current state, do you think this is ready for merging in 3.1 or would you want to have more reviews from core memory management people? See my other mails. It is not ready for mainline. -- 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 6/8] drivers: add Contiguous Memory Allocator
On Tue, Jul 05, 2011 at 02:27:44PM +0200, Arnd Bergmann wrote: It's also a preexisting problem as far as I can tell, and it needs to be solved in __dma_alloc for both cases, dma_alloc_from_contiguous and __alloc_system_pages as introduced in patch 7. Which is now resolved in linux-next, and has been through this cycle as previously discussed. It's taken some time because the guy who tested the patch for me said he'd review other platforms but never did, so I've just about given up waiting and stuffed it in ready for the 3.1 merge window irrespective of anything else. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
On Tuesday, July 05, 2011 14:08:03 Mauro Carvalho Chehab wrote:
Em 05-07-2011 04:26, Hans Verkuil escreveu:
On Monday, July 04, 2011 18:09:18 Mauro Carvalho Chehab wrote:
Em 29-06-2011 09:51, Tomasz Stanislawski escreveu:
The 1080p59_94 is supported by latest Samsung SoC.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/v4l2-common.c |1 +
include/linux/videodev2.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c
b/drivers/media/video/v4l2-common.c
index 06b9f9f..003e648 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -582,6 +582,7 @@ int v4l_fill_dv_preset_info(u32 preset, struct
v4l2_dv_enum_preset *info)
{ 1920, 1080, 1080p@30 }, /* V4L2_DV_1080P30 */
{ 1920, 1080, 1080p@50 }, /* V4L2_DV_1080P50 */
{ 1920, 1080, 1080p@60 }, /* V4L2_DV_1080P60 */
+ { 1920, 1080, 1080p@59.94 }, /* V4L2_DV_1080P59_94 */
};
if (info == NULL || preset = ARRAY_SIZE(dv_presets))
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 8a4c309..7c77c4e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -872,6 +872,7 @@ struct v4l2_dv_enum_preset {
#define V4L2_DV_1080P30 16 /* SMPTE 296M */
#define V4L2_DV_1080P50 17 /* BT.1120 */
#define V4L2_DV_1080P60 18 /* BT.1120 */
+#define V4L2_DV_1080P59_94 19
/*
* D V B T T I M I N G S
This patch deserves further discussions, as the specs that define the
presets
are not so clear with respect to 60Hz and 60/1.001 Hz.
Let me summarize the issue.
1) PRESET STANDARDS
== =
There are 3 specs involved with DV presets: ITU-R BT 709 and BT 1120 and
CEA 861.
At ITU-R BT.709, both 60Hz and 60/1.001 Hz are equally called as 60 Hz.
BT.1120
follows the same logic, as it uses BT.709 as a reference for video timings.
The CEA-861-E spec says at item 4, that:
A video timing with a vertical frequency that is an integer multiple of
6.00 Hz (i.e. 24.00, 30.00, 60.00,
120.00 or 240.00 Hz) is considered to be the same as a video timing
with the equivalent detailed timing
information but where the vertical frequency is adjusted by a factor of
1000/1001 (i.e., 24/1.001, 30/1.001,
60/1.001, 120/1.001 or 240/1.001). That is, they are considered two
versions of the same video timing but
with slightly different pixel clock frequencies. Therefore, a DTV that
declares it is capable of displaying a
video timing with a vertical frequency that is either an integer
multiple of 6 Hz or an integer multiple of 6
Hz adjusted by a factor of 1000/1001 shall be capable of displaying
both versions of the video timing.
At the same item, the table 2 describes several video parameters for each
preset, associating the
Video Identification Codes (VIC) for each preset.
No, *multiple VICs* are associated with each preset. VIC != preset.
There are two VIC's for several presets, as it is also used at the spec to
determine the aspect ratio, but, basically,
for one given VIC, there's just one timings preset at the table 2.
Sigh. VIC != video timings. It just gives some additional information regarding
aspect ration
(duplicated information actually).
The simple fact that you can't use it to determine the pixelclock and thus the
vertical
frequency means that it is *not* suitable as a way to determine the video
timings.
I've been working with HDMI receivers and transmitters for several years now,
and
it simply is not suitable.
Also, the VICs do not differentiate between 60 and 59.94 Hz.
Yes, but V4L2 DV timings also don't differentiate.
??? Yes, they do. There is a 720P60 and a 720P59_94. Also 1080I29_97 and
1080I30.
The 1080P59_94 is simply missing because nobody needed it yet.
Table 4 associates each VIC with the supported formats. For example, VIC
16 means a resolution of
1920x1080 at 59.94Hz/60Hz. The spec does explicitly allow that all
vertical frequencies that are
multiple of 6 Hz to accept both 59.94 Hz and 60 Hz, as said at note 3 of
table 2:
3. A video timing with a vertical frequency that is an integer multiple
of 6.00 Hz (i.e. 24.00, 30.00, 60.00, 120.00 or
240.00 Hz) is considered to be the same as a video timing with the
equivalent detailed timing information but where
the vertical frequency is adjusted by a factor of 1000/1001 (i.e.,
24/1.001, 30/1.001, 60/1.001, 120/1.001 or
240/1.001). That is, they are considered two versions of the same video
timing but with slightly different pixel clock
frequencies. The vertical
Re: omap3isp: known causes of CCDC won't become idle!
On 07/05/11 13:19, Sakari Ailus wrote: On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: Hi Laurent, I'm just trying to get an mt9v034 sensor working on a beagle xm. Everything more or less works, except that after a random number of frames of capture, I tend to get won't become idle messages and the vd0 and vd1 interrupts tend to turn up at same time. I was just wondering if there are any known issues with the ccdc driver / silicon that might explain this? I also note that it appears to be impossible to disable HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling support despite the datasheet claiming this can be done. Is this a known issue? The same interrupt may be used to produce an interrupt per horizontal sync but the driver doesn't use that. I remember of a case where the two sync signals had enough crosstalk to cause vertical sync interrupt per every horizontal sync. (It's been discussed on this list.) This might not be the case here, though: you should be flooded with HS_VS interrupts. As far as I can tell, the driver doesn't use either interrupt (except to pass it up as an event). Hence I was trying to mask it purely to cut down on the interrupt load. The VD* counters are counting and interrupts are produced (AFAIR) even if the CCDC is disabled. Oh goody... Once the CCDC starts receiving a frame, it becomes busy, and becomes idle only when it has received the full frame. For this reason it's important that the full frame is actually received by the CCDC, otherwise this is due to happen when the CCDC is being stopped at the end of the stream. Fair enough. Is there any software reason why it might think it hasn't received the whole frame? Obviously it could in theory be a hardware issue, but it's a bit odd that it can reliably do a certain number of frames before falling over. -- 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 6/8] drivers: add Contiguous Memory Allocator
On Tuesday 05 July 2011, Russell King - ARM Linux wrote: On Tue, Jul 05, 2011 at 02:27:44PM +0200, Arnd Bergmann wrote: It's also a preexisting problem as far as I can tell, and it needs to be solved in __dma_alloc for both cases, dma_alloc_from_contiguous and __alloc_system_pages as introduced in patch 7. Which is now resolved in linux-next, and has been through this cycle as previously discussed. It's taken some time because the guy who tested the patch for me said he'd review other platforms but never did, so I've just about given up waiting and stuffed it in ready for the 3.1 merge window irrespective of anything else. Ah, sorry I missed that patch on the mailing list, found it now in your for-next branch. If I'm reading your ARM: DMA: steal memory for DMA coherent mappings correctly, the idea is to have a per-platform compile-time amount of memory that is reserved purely for coherent allocations and taking out of the buddy allocator, right? As you say, this solves the problem for the non-CMA case, and does not apply to CMA because the entire point of CMA is not to remove the pages from the buddy allocator in order to preserve memory. So with your patch getting merged, patch 7/8 obviously has both a conflict and introduces a regression against the fix you did. Consequently that patch needs to be redone in a way that fits on top of your patch and avoids the double-mapping problem. What about the rest? As I mentioned in private, adding invasive features to core code is obviously not nice if it can be avoided, but my feeling is that we can no longer claim that there is no need for this with so much hardware relying on large contiguous memory ranges for DMA. The patches have come a long way since the first version, especially regarding the device driver interface and I think they are about as good as it gets in that regard. I do understand that without patch 7, there isn't a single architecture using the feature, which is somewhat silly, but I'm also convinced that other architectures will start using it, and that a solution for the double mapping in the ways I mentioned in my previous mail is going to happen. Probably not in 3.1 then, but we could put the patches into -mm anyway until we get there. 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
Re: [PATCH] viacam: Don't explode if pci_find_bus() returns NULL
On Sun, 3 Jul 2011 09:54:12 +0200 (CEST) Jesper Juhl j...@chaosbits.net wrote: In the unlikely case that pci_find_bus() should return NULL viacam_serial_is_enabled() is going to dereference a NULL pointer and blow up. Better safe than sorry, so be defensive and check the pointer. Extremely unlikely - that function is only called on a single architecture where the bus is known to exist. Still, no harm can come from checking. Acked-by: Jonathan Corbet cor...@lwn.net Thanks, 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: omap3isp: known causes of CCDC won't become idle!
On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: On 07/05/11 13:19, Sakari Ailus wrote: On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: Hi Laurent, I'm just trying to get an mt9v034 sensor working on a beagle xm. Everything more or less works, except that after a random number of frames of capture, I tend to get won't become idle messages and the vd0 and vd1 interrupts tend to turn up at same time. I was just wondering if there are any known issues with the ccdc driver / silicon that might explain this? I also note that it appears to be impossible to disable HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling support despite the datasheet claiming this can be done. Is this a known issue? The same interrupt may be used to produce an interrupt per horizontal sync but the driver doesn't use that. I remember of a case where the two sync signals had enough crosstalk to cause vertical sync interrupt per every horizontal sync. (It's been discussed on this list.) This might not be the case here, though: you should be flooded with HS_VS interrupts. As far as I can tell, the driver doesn't use either interrupt (except to pass it up as an event). Hence I was trying to mask it purely to cut down on the interrupt load. It does. This is the only way to detect the CCDC has finished processing a frame. The VD* counters are counting and interrupts are produced (AFAIR) even if the CCDC is disabled. Oh goody... Once the CCDC starts receiving a frame, it becomes busy, and becomes idle only when it has received the full frame. For this reason it's important that the full frame is actually received by the CCDC, otherwise this is due to happen when the CCDC is being stopped at the end of the stream. Fair enough. Is there any software reason why it might think it hasn't received the whole frame? Obviously it could in theory be a hardware issue, but it's a bit odd that it can reliably do a certain number of frames before falling over. Others than those which Laurent already pointed out, one which crosses my mind is the vsync polarity. The Documentation/video4linux/omap3isp.txt does mention it. It _may_ have the effect that one line of input is missed by the VD* counters. Thus the VD* counters might never reach the expected value --- the last line of the frame. -- Sakari Ailus sakari.ai...@iki.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: omap3isp: known causes of CCDC won't become idle!
On Tuesday 05 July 2011 16:38:07 Sakari Ailus wrote: On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: On 07/05/11 13:19, Sakari Ailus wrote: On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: Hi Laurent, I'm just trying to get an mt9v034 sensor working on a beagle xm. Everything more or less works, except that after a random number of frames of capture, I tend to get won't become idle messages and the vd0 and vd1 interrupts tend to turn up at same time. I was just wondering if there are any known issues with the ccdc driver / silicon that might explain this? I also note that it appears to be impossible to disable HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling support despite the datasheet claiming this can be done. Is this a known issue? The same interrupt may be used to produce an interrupt per horizontal sync but the driver doesn't use that. I remember of a case where the two sync signals had enough crosstalk to cause vertical sync interrupt per every horizontal sync. (It's been discussed on this list.) This might not be the case here, though: you should be flooded with HS_VS interrupts. As far as I can tell, the driver doesn't use either interrupt (except to pass it up as an event). Hence I was trying to mask it purely to cut down on the interrupt load. It does. This is the only way to detect the CCDC has finished processing a frame. We actually use the VD0 and VD1 interrupts for that, not the HS_VS interrupt. The VD* counters are counting and interrupts are produced (AFAIR) even if the CCDC is disabled. Oh goody... Once the CCDC starts receiving a frame, it becomes busy, and becomes idle only when it has received the full frame. For this reason it's important that the full frame is actually received by the CCDC, otherwise this is due to happen when the CCDC is being stopped at the end of the stream. Fair enough. Is there any software reason why it might think it hasn't received the whole frame? Obviously it could in theory be a hardware issue, but it's a bit odd that it can reliably do a certain number of frames before falling over. Others than those which Laurent already pointed out, one which crosses my mind is the vsync polarity. The Documentation/video4linux/omap3isp.txt does mention it. It _may_ have the effect that one line of input is missed by the VD* counters. Thus the VD* counters might never reach the expected value --- the last line of the frame. I would first try to increase vertical blanking to see if it helps. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap3isp: known causes of CCDC won't become idle!
On 07/05/11 16:02, Laurent Pinchart wrote: On Tuesday 05 July 2011 16:38:07 Sakari Ailus wrote: On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: On 07/05/11 13:19, Sakari Ailus wrote: On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: Hi Laurent, I'm just trying to get an mt9v034 sensor working on a beagle xm. Everything more or less works, except that after a random number of frames of capture, I tend to get won't become idle messages and the vd0 and vd1 interrupts tend to turn up at same time. I was just wondering if there are any known issues with the ccdc driver / silicon that might explain this? I also note that it appears to be impossible to disable HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling support despite the datasheet claiming this can be done. Is this a known issue? The same interrupt may be used to produce an interrupt per horizontal sync but the driver doesn't use that. I remember of a case where the two sync signals had enough crosstalk to cause vertical sync interrupt per every horizontal sync. (It's been discussed on this list.) This might not be the case here, though: you should be flooded with HS_VS interrupts. As far as I can tell, the driver doesn't use either interrupt (except to pass it up as an event). Hence I was trying to mask it purely to cut down on the interrupt load. It does. This is the only way to detect the CCDC has finished processing a frame. We actually use the VD0 and VD1 interrupts for that, not the HS_VS interrupt. The VD* counters are counting and interrupts are produced (AFAIR) even if the CCDC is disabled. Oh goody... Once the CCDC starts receiving a frame, it becomes busy, and becomes idle only when it has received the full frame. For this reason it's important that the full frame is actually received by the CCDC, otherwise this is due to happen when the CCDC is being stopped at the end of the stream. Fair enough. Is there any software reason why it might think it hasn't received the whole frame? Obviously it could in theory be a hardware issue, but it's a bit odd that it can reliably do a certain number of frames before falling over. Others than those which Laurent already pointed out, one which crosses my mind is the vsync polarity. The Documentation/video4linux/omap3isp.txt does mention it. It _may_ have the effect that one line of input is missed by the VD* counters. Thus the VD* counters might never reach the expected value --- the last line of the frame. I would first try to increase vertical blanking to see if it helps. Have done. No luck as yet. This sensor mt9v034 annoyingly starts live. Right now this means I get two frames with very short vblank (10% ratio, at 60fps, so sub 2 microseonds.) Whilst the failure seems to be at a later time, I'd obviously like to get rid of these. -- 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: omap3isp: known causes of CCDC won't become idle!
On Tue, Jul 05, 2011 at 05:02:52PM +0200, Laurent Pinchart wrote: On Tuesday 05 July 2011 16:38:07 Sakari Ailus wrote: On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: On 07/05/11 13:19, Sakari Ailus wrote: On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: Hi Laurent, I'm just trying to get an mt9v034 sensor working on a beagle xm. Everything more or less works, except that after a random number of frames of capture, I tend to get won't become idle messages and the vd0 and vd1 interrupts tend to turn up at same time. I was just wondering if there are any known issues with the ccdc driver / silicon that might explain this? I also note that it appears to be impossible to disable HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling support despite the datasheet claiming this can be done. Is this a known issue? The same interrupt may be used to produce an interrupt per horizontal sync but the driver doesn't use that. I remember of a case where the two sync signals had enough crosstalk to cause vertical sync interrupt per every horizontal sync. (It's been discussed on this list.) This might not be the case here, though: you should be flooded with HS_VS interrupts. As far as I can tell, the driver doesn't use either interrupt (except to pass it up as an event). Hence I was trying to mask it purely to cut down on the interrupt load. It does. This is the only way to detect the CCDC has finished processing a frame. We actually use the VD0 and VD1 interrupts for that, not the HS_VS interrupt. Right; I confused the two for a moment. Cheers, -- Sakari Ailus sakari.ai...@iki.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: omap3isp: known causes of CCDC won't become idle!
On 07/05/11 16:22, Jonathan Cameron wrote: On 07/05/11 16:02, Laurent Pinchart wrote: On Tuesday 05 July 2011 16:38:07 Sakari Ailus wrote: On Tue, Jul 05, 2011 at 02:48:57PM +0100, Jonathan Cameron wrote: On 07/05/11 13:19, Sakari Ailus wrote: On Tue, Jul 05, 2011 at 12:22:06PM +0100, Jonathan Cameron wrote: Hi Laurent, I'm just trying to get an mt9v034 sensor working on a beagle xm. Everything more or less works, except that after a random number of frames of capture, I tend to get won't become idle messages and the vd0 and vd1 interrupts tend to turn up at same time. I was just wondering if there are any known issues with the ccdc driver / silicon that might explain this? I also note that it appears to be impossible to disable HS_VS_IRQarch/arm/mach-s3c2410/Kconfig:# cpu frequency scaling support despite the datasheet claiming this can be done. Is this a known issue? The same interrupt may be used to produce an interrupt per horizontal sync but the driver doesn't use that. I remember of a case where the two sync signals had enough crosstalk to cause vertical sync interrupt per every horizontal sync. (It's been discussed on this list.) This might not be the case here, though: you should be flooded with HS_VS interrupts. As far as I can tell, the driver doesn't use either interrupt (except to pass it up as an event). Hence I was trying to mask it purely to cut down on the interrupt load. It does. This is the only way to detect the CCDC has finished processing a frame. We actually use the VD0 and VD1 interrupts for that, not the HS_VS interrupt. On that note, the interrupt was being disabled, just not it's value in the register. What I was actually seeing was it combined with one of the others. The VD* counters are counting and interrupts are produced (AFAIR) even if the CCDC is disabled. Oh goody... Once the CCDC starts receiving a frame, it becomes busy, and becomes idle only when it has received the full frame. For this reason it's important that the full frame is actually received by the CCDC, otherwise this is due to happen when the CCDC is being stopped at the end of the stream. Fair enough. Is there any software reason why it might think it hasn't received the whole frame? Obviously it could in theory be a hardware issue, but it's a bit odd that it can reliably do a certain number of frames before falling over. Others than those which Laurent already pointed out, one which crosses my mind is the vsync polarity. The Documentation/video4linux/omap3isp.txt does mention it. It _may_ have the effect that one line of input is missed by the VD* counters. Thus the VD* counters might never reach the expected value --- the last line of the frame. I would first try to increase vertical blanking to see if it helps. Have done. No luck as yet. This sensor mt9v034 annoyingly starts live. Right now this means I get two frames with very short vblank (10% ratio, at 60fps, so sub 2 microseonds.) Whilst the failure seems to be at a later time, I'd obviously like to get rid of these. Hmm. Via a bit of reordering of writes and a temporary disable, it now does one frame, then about a 100ms pause, then continues with 50ms blanking periods, vs, about 18ms of data transfer. Still running into what looks like the same issue with the ccdc getting wedged... Having introduced some debugging into the isr I get: 55.123840] power on called [ 55.135528] interrupt 2147483648 [ 55.139038] interrupt 2147483648 [ 55.142578] interrupt 2147483648 [ 55.145965] interrupt 2147483648 [ 55.149383] interrupt 2147483648 [ 55.152770] interrupt 2147483648 [ 55.156188] interrupt 2147483648 [ 55.159576] interrupt 2147483648 [ 55.162994] interrupt 2147483648 [ 55.181854] end of set power [ 55.241821] get format called [ 55.245025] get pad format [ 55.248138] in [ 55.249877] get format called [ 55.252990] get pad format [ 55.256195] on [ 55.257904] s_stream called [ 55.260833] set params called [ 55.267944] stream enable attempted [ 55.282257] interrupt 2147483648 [ 55.302429] interrupt 512 [ 55.312408] interrupt 256 [ 55.385864] interrupt 2147483648 [ 55.406005] interrupt 512 [ 55.415985] interrupt 256 [ 55.492401] interrupt 2147483648 [ 55.512603] interrupt 512 [ 55.522583] interrupt 256 [ 55.599029] interrupt 2147483648 [ 55.619201] interrupt 512 [ 55.629180] interrupt 256 [ 55.705627] interrupt 2147483648 [ 55.725738] interrupt 512 [ 55.735687] interrupt 256 [ 55.740417] omap3isp omap3isp: CCDC won't become idle! [ 55.811645] interrupt 2147483648 [ 55.832000] interrupt 512 [ 55.842010] interrupt 256 Repeat last 4 lines ad infinitum or if lucky till my program gives up and closes everything. Sometimes that hangs the machine as well. So nothing obviously changing. Waveform of the vsync signal looks right to me. The other fun wedge that sometimes happens is both vd0 and vd1 occur together.
Re: [PATCH] [staging] lirc_serial: allocate irq at init time
On Thu, Jun 16, 2011 at 03:31:46PM -0400, Jarod Wilson wrote: There's really no good reason not to just grab the desired IRQ at driver init time, instead of every time the lirc device node is accessed. This also improves the speed and reliability with which a serial transmitter can operate, as back-to-back transmission attempts (i.e., channel change to a multi-digit channel) don't have to spend time acquiring and then releasing the IRQ for every digit, sometimes multiple times, if lircd has been told to use the min_repeat parameter. CC: de...@driverdev.osuosl.org Signed-off-by: Jarod Wilson ja...@redhat.com --- drivers/staging/lirc/lirc_serial.c | 44 +-- 1 files changed, 21 insertions(+), 23 deletions(-) This patch doesn't apply to the staging-next branch, care to respin it and resend it so I can apply it? thanks, greg k-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/6] V4L2: OMAP: VOUT: isr handling extended for DPI and HDMI interface
-Original Message-
From: JAIN, AMBER
Sent: Tuesday, June 07, 2011 8:18 PM
To: linux-media@vger.kernel.org
Cc: Hiremath, Vaibhav; Semwal, Sumit; JAIN, AMBER
Subject: [PATCH 1/6] V4L2: OMAP: VOUT: isr handling extended for DPI and
HDMI interface
[Hiremath, Vaibhav] Few minor comments below -
Extending the omap vout isr handling for:
- secondary lcd over DPI interface,
- HDMI interface.
[Hiremath, Vaibhav] It would be useful to mention about OMAP4 DSS block (these
are new additions compared to OAMP3), that's where both the interfaces are
getting used, right?
Signed-off-by: Amber Jain am...@ti.com
---
drivers/media/video/omap/omap_vout.c | 26 +++---
1 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index a831241..6fe7efa 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -544,10 +544,20 @@ void omap_vout_isr(void *arg, unsigned int
irqstatus)
spin_lock(vout-vbq_lock);
do_gettimeofday(timevalue);
- if (cur_display-type == OMAP_DISPLAY_TYPE_DPI) {
- if (!(irqstatus DISPC_IRQ_VSYNC))
- goto vout_isr_err;
+ if (cur_display-type != OMAP_DISPLAY_TYPE_VENC) {
+ switch (cur_display-type) {
+ case OMAP_DISPLAY_TYPE_DPI:
+ if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
+ goto vout_isr_err;
+ break;
+ case OMAP_DISPLAY_TYPE_HDMI:
+ if (!(irqstatus DISPC_IRQ_EVSYNC_EVEN))
+ goto vout_isr_err;
+ break;
+ default:
+ goto vout_isr_err;
+ }
[Hiremath, Vaibhav] how about implementing this like,
if (cur_display-type != OMAP_DISPLAY_TYPE_VENC) {
unsigned int status;
switch (cur_display-type) {
case OMAP_DISPLAY_TYPE_DPI:
status = DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2;
break;
case OMAP_DISPLAY_TYPE_HDMI:
status = DISPC_IRQ_EVSYNC_EVEN;
break;
default:
goto vout_isr_err;
}
If (!(irqstatus status))
goto vout_isr_err;
Thanks,
Vaibhav
if (!vout-first_int (vout-cur_frm != vout-next_frm)) {
vout-cur_frm-ts = timevalue;
vout-cur_frm-state = VIDEOBUF_DONE;
@@ -571,7 +581,7 @@ void omap_vout_isr(void *arg, unsigned int irqstatus)
ret = omapvid_init(vout, addr);
if (ret)
printk(KERN_ERR VOUT_NAME
- failed to set overlay info\n);
+ [Hiremath, Vaibhav] failed to set overlay
info\n);
/* Enable the pipeline and set the Go bit */
ret = omapvid_apply_changes(vout);
if (ret)
@@ -925,7 +935,7 @@ static int omap_vout_release(struct file *file)
u32 mask = 0;
mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN |
- DISPC_IRQ_EVSYNC_ODD;
+ DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_VSYNC2;
omap_dispc_unregister_isr(omap_vout_isr, vout, mask);
vout-streaming = 0;
@@ -1596,7 +1606,8 @@ static int vidioc_streamon(struct file *file, void
*fh, enum v4l2_buf_type i)
addr = (unsigned long) vout-queued_buf_addr[vout-cur_frm-i]
+ vout-cropped_offset;
- mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN |
DISPC_IRQ_EVSYNC_ODD;
+ mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN |
DISPC_IRQ_EVSYNC_ODD
+ | DISPC_IRQ_VSYNC2;
omap_dispc_register_isr(omap_vout_isr, vout, mask);
@@ -1646,7 +1657,8 @@ static int vidioc_streamoff(struct file *file, void
*fh, enum v4l2_buf_type i)
return -EINVAL;
vout-streaming = 0;
- mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN |
DISPC_IRQ_EVSYNC_ODD;
+ mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN |
DISPC_IRQ_EVSYNC_ODD
+ | DISPC_IRQ_VSYNC2;
omap_dispc_unregister_isr(omap_vout_isr, vout, mask);
--
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
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Jul 5 19:00:35 CEST 2011 git hash:df6aabbeb2b8799d97f3886fc994c318bc6a6843 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: 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-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 spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Hans Verkuil hverk...@xs4all.nl wrote: I can work on the proposal this week for that. The only reason the fps hasn't been added yet is that I never had the time to do the research on how to represent the fps reliably for all CEA/VESA formats. Hmm, pixelclock / total_framesize should always work, of course. We can add a flags field as well (for interlaced vs progressive and perhaps others such as normal vs reduced blanking). That leaves the problem with GTF/CVT. I'll get back to that tomorrow. I have ideas, but I need to discuss it first. 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 For fps you could use horizontal_line_freq/lines_per_frame. However, all of the non-integer fps numbers I have seen in this email chain all seem to be multiples of 29.97002997 Hz. So maybe you could just use the closest integer rate with a flag labeled ntsc_bw_timing_hack to indicate the fractional rates. :) That 29.97 Hz number comes from the NTSC decision in 1953(!) to change the horizontal line freq to 4.5 MHz/286. Note that (4.5 MHz/286)/525 = 30 * (1000/1001) = 29.97002997 Hz It is interesting to see one of the most ingenious analog hacks in TV history (to achieve color and BW backward compatabilty while staying in the 10% tolerance of the old BW receivers) being codified in digital standards over 50 years later. It boggles the mind... Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/6] V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers in qbuf and dqbuf
-Original Message-
From: JAIN, AMBER
Sent: Tuesday, June 07, 2011 8:18 PM
To: linux-media@vger.kernel.org
Cc: Hiremath, Vaibhav; Semwal, Sumit; JAIN, AMBER
Subject: [PATCH 2/6] V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers in
qbuf and dqbuf
[Hiremath, Vaibhav] few minor comments below -
Add support to map the buffer using dma_map_single during qbuf which
inturn
calls cache flush and unmap the same during dqbuf. This is done to prevent
the artifacts seen because of cache-coherency issues on OMAP4
Signed-off-by: Amber Jain am...@ti.com
---
drivers/media/video/omap/omap_vout.c | 29 +++--
1 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 6fe7efa..435fe65 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -37,6 +37,7 @@
#include linux/platform_device.h
#include linux/irq.h
#include linux/videodev2.h
+#include linux/dma-mapping.h
#include media/videobuf-dma-contig.h
#include media/v4l2-device.h
@@ -768,6 +769,17 @@ static int omap_vout_buffer_prepare(struct
videobuf_queue *q,
vout-queued_buf_addr[vb-i] = (u8 *)
omap_vout_uservirt_to_phys(vb-baddr);
} else {
+ int addr, dma_addr;
[Hiremath, Vaibhav] Why is it int? It should be either u32 or unsigned long
or dma_addr_t. Also you don't need type casting everywhere with this.
+ unsigned long size;
+
+ addr = (unsigned long) vout-buf_virt_addr[vb-i];
+ size = (unsigned long) vb-size;
+
+ dma_addr = dma_map_single(vout-vid_dev-v4l2_dev.dev, (void
*) addr,
+ (unsigned) size, DMA_TO_DEVICE);
[Hiremath, Vaibhav] Why type casting required here?
+ if (dma_mapping_error(vout-vid_dev-v4l2_dev.dev, dma_addr))
+ printk(KERN_ERR dma_map_single failed\n);
[Hiremath, Vaibhav] Can this be changed to v4l2_err?
+
vout-queued_buf_addr[vb-i] = (u8 *)vout-buf_phy_addr[vb-
i];
}
@@ -1549,15 +1561,28 @@ static int vidioc_dqbuf(struct file *file, void
*fh, struct v4l2_buffer *b)
struct omap_vout_device *vout = fh;
struct videobuf_queue *q = vout-vbq;
+ unsigned long size;
+ u32 addr;
+ struct videobuf_buffer *vb;
+ int ret;
+
[Hiremath, Vaibhav] Just for readability can you put them in order (lengthwise)?
+ vb = q-bufs[b-index];
+
if (!vout-streaming)
return -EINVAL;
if (file-f_flags O_NONBLOCK)
/* Call videobuf_dqbuf for non blocking mode */
- return videobuf_dqbuf(q, (struct v4l2_buffer *)b, 1);
+ ret = videobuf_dqbuf(q, (struct v4l2_buffer *)b, 1);
else
/* Call videobuf_dqbuf for blocking mode */
- return videobuf_dqbuf(q, (struct v4l2_buffer *)b, 0);
+ ret = videobuf_dqbuf(q, (struct v4l2_buffer *)b, 0);
+
+ addr = (unsigned long) vout-buf_phy_addr[vb-i];
+ size = (unsigned long) vb-size;
+ dma_unmap_single(vout-vid_dev-v4l2_dev.dev, addr,
+ (unsigned) size, DMA_TO_DEVICE);
[Hiremath, Vaibhav] Type cast???
Thanks,
Vaibhav
+ return ret;
}
static int vidioc_streamon(struct file *file, void *fh, enum
v4l2_buf_type i)
--
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 6/6] V4l2: OMAP: VOUT: Minor Cleanup, removing the unnecessary code.
-Original Message-
From: JAIN, AMBER
Sent: Tuesday, June 07, 2011 8:18 PM
To: linux-media@vger.kernel.org
Cc: Hiremath, Vaibhav; Semwal, Sumit; JAIN, AMBER; Nilofer, Samreen
Subject: [PATCH 6/6] V4l2: OMAP: VOUT: Minor Cleanup, removing the
unnecessary code.
Minor changes to remove the unused code from omap_vout driver.
Signed-off-by: Amber Jain am...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
drivers/media/video/omap/omap_vout.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 25025a1..4aeea06 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1090,10 +1090,7 @@ static int vidioc_enum_fmt_vid_out_mplane(struct
file *file, void *fh,
struct v4l2_fmtdesc *fmt)
{
int index = fmt-index;
- enum v4l2_buf_type type = fmt-type;
- fmt-index = index;
- fmt-type = type;
[Hiremath, Vaibhav] These lines are not present in main-line driver? Which
baseline have you used for this patch?
Thanks,
Vaibhav
if (index = NUM_OUTPUT_FORMATS)
return -EINVAL;
@@ -1268,10 +1265,7 @@ static int vidioc_enum_fmt_vid_overlay(struct file
*file, void *fh,
struct v4l2_fmtdesc *fmt)
{
int index = fmt-index;
- enum v4l2_buf_type type = fmt-type;
- fmt-index = index;
- fmt-type = type;
if (index = NUM_OUTPUT_FORMATS)
return -EINVAL;
--
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 6/6] V4l2: OMAP: VOUT: Minor Cleanup, removing the unnecessary code.
-Original Message-
From: Hiremath, Vaibhav
Sent: Wednesday, July 06, 2011 12:38 AM
To: JAIN, AMBER; linux-media@vger.kernel.org
Cc: Semwal, Sumit; Nilofer, Samreen
Subject: RE: [PATCH 6/6] V4l2: OMAP: VOUT: Minor Cleanup, removing the
unnecessary code.
-Original Message-
From: JAIN, AMBER
Sent: Tuesday, June 07, 2011 8:18 PM
To: linux-media@vger.kernel.org
Cc: Hiremath, Vaibhav; Semwal, Sumit; JAIN, AMBER; Nilofer, Samreen
Subject: [PATCH 6/6] V4l2: OMAP: VOUT: Minor Cleanup, removing the
unnecessary code.
Minor changes to remove the unused code from omap_vout driver.
Signed-off-by: Amber Jain am...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
drivers/media/video/omap/omap_vout.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 25025a1..4aeea06 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1090,10 +1090,7 @@ static int vidioc_enum_fmt_vid_out_mplane(struct
file *file, void *fh,
struct v4l2_fmtdesc *fmt)
{
int index = fmt-index;
- enum v4l2_buf_type type = fmt-type;
- fmt-index = index;
- fmt-type = type;
[Hiremath, Vaibhav] These lines are not present in main-line driver? Which
baseline have you used for this patch?
[Hiremath, Vaibhav] My bad, I hit send button quite early. I will queue this up
for 3.1.
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Thanks,
Vaibhav
Thanks,
Vaibhav
if (index = NUM_OUTPUT_FORMATS)
return -EINVAL;
@@ -1268,10 +1265,7 @@ static int vidioc_enum_fmt_vid_overlay(struct
file
*file, void *fh,
struct v4l2_fmtdesc *fmt)
{
int index = fmt-index;
- enum v4l2_buf_type type = fmt-type;
- fmt-index = index;
- fmt-type = type;
if (index = NUM_OUTPUT_FORMATS)
return -EINVAL;
--
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/6] V4L2: OMAP: VOUT: Adapt to Multiplanar APIs
-Original Message-
From: JAIN, AMBER
Sent: Tuesday, June 07, 2011 8:18 PM
To: linux-media@vger.kernel.org
Cc: Hiremath, Vaibhav; Semwal, Sumit; JAIN, AMBER; Nilofer, Samreen
Subject: [PATCH 3/6] V4L2: OMAP: VOUT: Adapt to Multiplanar APIs
Adapting the omap_vout driver for multiplanar API support.
[Hiremath, Vaibhav] Personally I think it doesn't make sense to change function
names only without adding functionality.
So I would suggest merging this patch with the actual multi-planar format
support patch, which I believe is not part of this series.
Irrespective of this, can you create separate patch series for,
V4L2: OMAP: VOUT: isr handling extended for DPI and HDMI interface
V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers in qbuf and dqbuf
V4l2: OMAP: VOUT: Minor Cleanup, removing the unnecessary code.
Thanks,
Vaibhav
Signed-off-by: Amber Jain am...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
drivers/media/video/omap/omap_vout.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 435fe65..70fb45e 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1014,12 +1014,13 @@ static int vidioc_querycap(struct file *file, void
*fh,
strlcpy(cap-driver, VOUT_NAME, sizeof(cap-driver));
strlcpy(cap-card, vout-vfd-name, sizeof(cap-card));
cap-bus_info[0] = '\0';
- cap-capabilities = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_OUTPUT;
+ cap-capabilities = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_OUTPUT |
+ V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
return 0;
}
-static int vidioc_enum_fmt_vid_out(struct file *file, void *fh,
+static int vidioc_enum_fmt_vid_out_mplane(struct file *file, void *fh,
struct v4l2_fmtdesc *fmt)
{
int index = fmt-index;
@@ -1038,7 +1039,7 @@ static int vidioc_enum_fmt_vid_out(struct file *file,
void *fh,
return 0;
}
-static int vidioc_g_fmt_vid_out(struct file *file, void *fh,
+static int vidioc_g_fmt_vid_out_mplane(struct file *file, void *fh,
struct v4l2_format *f)
{
struct omap_vout_device *vout = fh;
@@ -1048,7 +1049,7 @@ static int vidioc_g_fmt_vid_out(struct file *file,
void *fh,
}
-static int vidioc_try_fmt_vid_out(struct file *file, void *fh,
+static int vidioc_try_fmt_vid_out_mplane(struct file *file, void *fh,
struct v4l2_format *f)
{
struct omap_overlay *ovl;
@@ -1071,7 +1072,7 @@ static int vidioc_try_fmt_vid_out(struct file *file,
void *fh,
return 0;
}
-static int vidioc_s_fmt_vid_out(struct file *file, void *fh,
+static int vidioc_s_fmt_vid_out_mplane(struct file *file, void *fh,
struct v4l2_format *f)
{
int ret, bpp;
@@ -1817,10 +1818,10 @@ static int vidioc_g_fbuf(struct file *file, void
*fh,
static const struct v4l2_ioctl_ops vout_ioctl_ops = {
.vidioc_querycap= vidioc_querycap,
- .vidioc_enum_fmt_vid_out= vidioc_enum_fmt_vid_out,
- .vidioc_g_fmt_vid_out = vidioc_g_fmt_vid_out,
- .vidioc_try_fmt_vid_out = vidioc_try_fmt_vid_out,
- .vidioc_s_fmt_vid_out = vidioc_s_fmt_vid_out,
+ .vidioc_enum_fmt_vid_out_mplane =
vidioc_enum_fmt_vid_out_mplane,
+ .vidioc_g_fmt_vid_out_mplane= vidioc_g_fmt_vid_out_mplane,
+ .vidioc_try_fmt_vid_out_mplane =
vidioc_try_fmt_vid_out_mplane,
+ .vidioc_s_fmt_vid_out_mplane= vidioc_s_fmt_vid_out_mplane,
.vidioc_queryctrl = vidioc_queryctrl,
.vidioc_g_ctrl = vidioc_g_ctrl,
.vidioc_s_fbuf = vidioc_s_fbuf,
--
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: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Em 05-07-2011 16:02, Andy Walls escreveu: Hans Verkuil hverk...@xs4all.nl wrote: I can work on the proposal this week for that. The only reason the fps hasn't been added yet is that I never had the time to do the research on how to represent the fps reliably for all CEA/VESA formats. Hmm, pixelclock / total_framesize should always work, of course. We can add a flags field as well (for interlaced vs progressive and perhaps others such as normal vs reduced blanking). That leaves the problem with GTF/CVT. I'll get back to that tomorrow. I have ideas, but I need to discuss it first. 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 For fps you could use horizontal_line_freq/lines_per_frame. However, all of the non-integer fps numbers I have seen in this email chain all seem to be multiples of 29.97002997 Hz. So maybe you could just use the closest integer rate with a flag labeled ntsc_bw_timing_hack to indicate the fractional rates. :) CEA-861 has some other timings that are not 60 Hz * 1000/1001. Yet, v4l2_fract is capable of handling any of such timings, as, whatever frequency taken, it needs to be a fractional number. Btw, even some userspace libraries prefer to represent fps using a fraction, instead of a float, to avoid rounding issues. That 29.97 Hz number comes from the NTSC decision in 1953(!) to change the horizontal line freq to 4.5 MHz/286. Note that (4.5 MHz/286)/525 = 30 * (1000/1001) = 29.97002997 Hz One of the rationale for that decision was to avoid flicking issues with cathodic ray monitors and fluorescent lamps. It is interesting to see one of the most ingenious analog hacks in TV history (to achieve color and BW backward compatabilty while staying in the 10% tolerance of the old BW receivers) being codified in digital standards over 50 years later. It boggles the mind... Yes. Bad (and good) API decisions will stay forever. Cheers, 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: [RFC] DV timings spec fixes at V4L2 API - was: [PATCH 1/8] v4l: add macro for 1080p59_54 preset
Mauro Carvalho Chehab mche...@redhat.com wrote: Em 05-07-2011 16:02, Andy Walls escreveu: Hans Verkuil hverk...@xs4all.nl wrote: I can work on the proposal this week for that. The only reason the fps hasn't been added yet is that I never had the time to do the research on how to represent the fps reliably for all CEA/VESA formats. Hmm, pixelclock / total_framesize should always work, of course. We can add a flags field as well (for interlaced vs progressive and perhaps others such as normal vs reduced blanking). That leaves the problem with GTF/CVT. I'll get back to that tomorrow. I have ideas, but I need to discuss it first. 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 For fps you could use horizontal_line_freq/lines_per_frame. However, all of the non-integer fps numbers I have seen in this email chain all seem to be multiples of 29.97002997 Hz. So maybe you could just use the closest integer rate with a flag labeled ntsc_bw_timing_hack to indicate the fractional rates. :) CEA-861 has some other timings that are not 60 Hz * 1000/1001. Yet, v4l2_fract is capable of handling any of such timings, as, whatever frequency taken, it needs to be a fractional number. Btw, even some userspace libraries prefer to represent fps using a fraction, instead of a float, to avoid rounding issues. That 29.97 Hz number comes from the NTSC decision in 1953(!) to change the horizontal line freq to 4.5 MHz/286. Note that (4.5 MHz/286)/525 = 30 * (1000/1001) = 29.97002997 Hz One of the rationale for that decision was to avoid flicking issues with cathodic ray monitors and fluorescent lamps. It is interesting to see one of the most ingenious analog hacks in TV history (to achieve color and BW backward compatabilty while staying in the 10% tolerance of the old BW receivers) being codified in digital standards over 50 years later. It boggles the mind... Yes. Bad (and good) API decisions will stay forever. Cheers, Mauro. Oops, yes I see the 60.054 Hz rate corresponds to a 262 line field (524 line frame) at the standard NTSC line rate. Weird stuff. Regards, Andy -- 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/6] V4L2: OMAP: VOUT: isr handling extended for DPI and HDMI interface
-Original Message-
From: Hiremath, Vaibhav
Sent: Wednesday, July 06, 2011 12:17 AM
To: JAIN, AMBER; linux-media@vger.kernel.org
Cc: Semwal, Sumit
Subject: RE: [PATCH 1/6] V4L2: OMAP: VOUT: isr handling extended for DPI
and HDMI interface
-Original Message-
From: JAIN, AMBER
Sent: Tuesday, June 07, 2011 8:18 PM
To: linux-media@vger.kernel.org
Cc: Hiremath, Vaibhav; Semwal, Sumit; JAIN, AMBER
Subject: [PATCH 1/6] V4L2: OMAP: VOUT: isr handling extended for DPI and
HDMI interface
[Hiremath, Vaibhav] Few minor comments below -
Extending the omap vout isr handling for:
- secondary lcd over DPI interface,
- HDMI interface.
[Hiremath, Vaibhav] It would be useful to mention about OMAP4 DSS block
(these are new additions compared to OAMP3), that's where both the
interfaces are getting used, right?
Ok, will add that.
Signed-off-by: Amber Jain am...@ti.com
---
drivers/media/video/omap/omap_vout.c | 26 +++---
1 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index a831241..6fe7efa 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -544,10 +544,20 @@ void omap_vout_isr(void *arg, unsigned int
irqstatus)
spin_lock(vout-vbq_lock);
do_gettimeofday(timevalue);
- if (cur_display-type == OMAP_DISPLAY_TYPE_DPI) {
- if (!(irqstatus DISPC_IRQ_VSYNC))
- goto vout_isr_err;
+ if (cur_display-type != OMAP_DISPLAY_TYPE_VENC) {
+ switch (cur_display-type) {
+ case OMAP_DISPLAY_TYPE_DPI:
+ if (!(irqstatus (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
+ goto vout_isr_err;
+ break;
+ case OMAP_DISPLAY_TYPE_HDMI:
+ if (!(irqstatus DISPC_IRQ_EVSYNC_EVEN))
+ goto vout_isr_err;
+ break;
+ default:
+ goto vout_isr_err;
+ }
[Hiremath, Vaibhav] how about implementing this like,
if (cur_display-type != OMAP_DISPLAY_TYPE_VENC) {
unsigned int status;
switch (cur_display-type) {
case OMAP_DISPLAY_TYPE_DPI:
status = DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2;
break;
case OMAP_DISPLAY_TYPE_HDMI:
status = DISPC_IRQ_EVSYNC_EVEN;
break;
default:
goto vout_isr_err;
}
If (!(irqstatus status))
goto vout_isr_err;
Thanks,
Vaibhav
It can be done, but I don't really see a benefit of using a new variable for it
as it is used just once for check.
if (!vout-first_int (vout-cur_frm != vout-next_frm)) {
vout-cur_frm-ts = timevalue;
vout-cur_frm-state = VIDEOBUF_DONE;
@@ -571,7 +581,7 @@ void omap_vout_isr(void *arg, unsigned int
irqstatus)
ret = omapvid_init(vout, addr);
if (ret)
printk(KERN_ERR VOUT_NAME
- failed to set overlay info\n);
+ [Hiremath, Vaibhav] failed to set overlay
info\n);
/* Enable the pipeline and set the Go bit */
ret = omapvid_apply_changes(vout);
if (ret)
@@ -925,7 +935,7 @@ static int omap_vout_release(struct file *file)
u32 mask = 0;
mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN |
- DISPC_IRQ_EVSYNC_ODD;
+ DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_VSYNC2;
omap_dispc_unregister_isr(omap_vout_isr, vout, mask);
vout-streaming = 0;
@@ -1596,7 +1606,8 @@ static int vidioc_streamon(struct file *file, void
*fh, enum v4l2_buf_type i)
addr = (unsigned long) vout-queued_buf_addr[vout-cur_frm-i]
+ vout-cropped_offset;
- mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN |
DISPC_IRQ_EVSYNC_ODD;
+ mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN |
DISPC_IRQ_EVSYNC_ODD
+ | DISPC_IRQ_VSYNC2;
omap_dispc_register_isr(omap_vout_isr, vout, mask);
@@ -1646,7 +1657,8 @@ static int vidioc_streamoff(struct file *file,
void
*fh, enum v4l2_buf_type i)
return -EINVAL;
vout-streaming = 0;
- mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN |
DISPC_IRQ_EVSYNC_ODD;
+ mask = DISPC_IRQ_VSYNC | DISPC_IRQ_EVSYNC_EVEN |
DISPC_IRQ_EVSYNC_ODD
+ | DISPC_IRQ_VSYNC2;
omap_dispc_unregister_isr(omap_vout_isr, vout, mask);
--
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 2/6] V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers in qbuf and dqbuf
-Original Message-
From: Hiremath, Vaibhav
Sent: Wednesday, July 06, 2011 12:34 AM
To: JAIN, AMBER; linux-media@vger.kernel.org
Cc: Semwal, Sumit
Subject: RE: [PATCH 2/6] V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers
in qbuf and dqbuf
-Original Message-
From: JAIN, AMBER
Sent: Tuesday, June 07, 2011 8:18 PM
To: linux-media@vger.kernel.org
Cc: Hiremath, Vaibhav; Semwal, Sumit; JAIN, AMBER
Subject: [PATCH 2/6] V4L2: OMAP: VOUT: dma map and unmap v4l2 buffers in
qbuf and dqbuf
[Hiremath, Vaibhav] few minor comments below -
Add support to map the buffer using dma_map_single during qbuf which
inturn
calls cache flush and unmap the same during dqbuf. This is done to
prevent
the artifacts seen because of cache-coherency issues on OMAP4
Signed-off-by: Amber Jain am...@ti.com
---
drivers/media/video/omap/omap_vout.c | 29
+++--
1 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 6fe7efa..435fe65 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -37,6 +37,7 @@
#include linux/platform_device.h
#include linux/irq.h
#include linux/videodev2.h
+#include linux/dma-mapping.h
#include media/videobuf-dma-contig.h
#include media/v4l2-device.h
@@ -768,6 +769,17 @@ static int omap_vout_buffer_prepare(struct
videobuf_queue *q,
vout-queued_buf_addr[vb-i] = (u8 *)
omap_vout_uservirt_to_phys(vb-baddr);
} else {
+ int addr, dma_addr;
[Hiremath, Vaibhav] Why is it int? It should be either u32 or unsigned
long or dma_addr_t. Also you don't need type casting everywhere with this.
Ok, I will change it.
+ unsigned long size;
+
+ addr = (unsigned long) vout-buf_virt_addr[vb-i];
+ size = (unsigned long) vb-size;
+
+ dma_addr = dma_map_single(vout-vid_dev-v4l2_dev.dev, (void
*) addr,
+ (unsigned) size, DMA_TO_DEVICE);
[Hiremath, Vaibhav] Why type casting required here?
+ if (dma_mapping_error(vout-vid_dev-v4l2_dev.dev, dma_addr))
+ printk(KERN_ERR dma_map_single failed\n);
[Hiremath, Vaibhav] Can this be changed to v4l2_err?
Ok, I will change it.
+
vout-queued_buf_addr[vb-i] = (u8 *)vout-buf_phy_addr[vb-
i];
}
@@ -1549,15 +1561,28 @@ static int vidioc_dqbuf(struct file *file, void
*fh, struct v4l2_buffer *b)
struct omap_vout_device *vout = fh;
struct videobuf_queue *q = vout-vbq;
+ unsigned long size;
+ u32 addr;
+ struct videobuf_buffer *vb;
+ int ret;
+
[Hiremath, Vaibhav] Just for readability can you put them in order
(lengthwise)?
+ vb = q-bufs[b-index];
+
if (!vout-streaming)
return -EINVAL;
if (file-f_flags O_NONBLOCK)
/* Call videobuf_dqbuf for non blocking mode */
- return videobuf_dqbuf(q, (struct v4l2_buffer *)b, 1);
+ ret = videobuf_dqbuf(q, (struct v4l2_buffer *)b, 1);
else
/* Call videobuf_dqbuf for blocking mode */
- return videobuf_dqbuf(q, (struct v4l2_buffer *)b, 0);
+ ret = videobuf_dqbuf(q, (struct v4l2_buffer *)b, 0);
+
+ addr = (unsigned long) vout-buf_phy_addr[vb-i];
+ size = (unsigned long) vb-size;
+ dma_unmap_single(vout-vid_dev-v4l2_dev.dev, addr,
+ (unsigned) size, DMA_TO_DEVICE);
[Hiremath, Vaibhav] Type cast???
Thanks,
Vaibhav
+ return ret;
}
static int vidioc_streamon(struct file *file, void *fh, enum
v4l2_buf_type i)
--
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 6/6] V4l2: OMAP: VOUT: Minor Cleanup, removing the unnecessary code.
-Original Message-
From: Hiremath, Vaibhav
Sent: Wednesday, July 06, 2011 12:38 AM
To: JAIN, AMBER; linux-media@vger.kernel.org
Cc: Semwal, Sumit; Nilofer, Samreen
Subject: RE: [PATCH 6/6] V4l2: OMAP: VOUT: Minor Cleanup, removing the
unnecessary code.
-Original Message-
From: JAIN, AMBER
Sent: Tuesday, June 07, 2011 8:18 PM
To: linux-media@vger.kernel.org
Cc: Hiremath, Vaibhav; Semwal, Sumit; JAIN, AMBER; Nilofer, Samreen
Subject: [PATCH 6/6] V4l2: OMAP: VOUT: Minor Cleanup, removing the
unnecessary code.
Minor changes to remove the unused code from omap_vout driver.
Signed-off-by: Amber Jain am...@ti.com
Signed-off-by: Samreen samr...@ti.com
---
drivers/media/video/omap/omap_vout.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 25025a1..4aeea06 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1090,10 +1090,7 @@ static int vidioc_enum_fmt_vid_out_mplane(struct
file *file, void *fh,
struct v4l2_fmtdesc *fmt)
{
int index = fmt-index;
- enum v4l2_buf_type type = fmt-type;
- fmt-index = index;
- fmt-type = type;
[Hiremath, Vaibhav] These lines are not present in main-line driver? Which
baseline have you used for this patch?
I checked it again, it is present in mainline. Can you please check 3.0-rc6
branch.
Thanks,
Amber
Thanks,
Vaibhav
if (index = NUM_OUTPUT_FORMATS)
return -EINVAL;
@@ -1268,10 +1265,7 @@ static int vidioc_enum_fmt_vid_overlay(struct
file
*file, void *fh,
struct v4l2_fmtdesc *fmt)
{
int index = fmt-index;
- enum v4l2_buf_type type = fmt-type;
- fmt-index = index;
- fmt-type = type;
if (index = NUM_OUTPUT_FORMATS)
return -EINVAL;
--
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] media: initial driver for ov5642 CMOS sensor
Hi, Guennadi
The solution you said is right. We could use parameters to
distinguish different power managerment, gain, etc.
So ov5642_default_regs_init and ov5642_default_regs_finalise in the
patch could be removed in the final version, right?
Since it's not common for all boards. What I think about is that
ov5642.c is a common driver, which could use on almost
all platforms. But the setting could be different from different
boards from my experience on three boards. And the setting
contains lots of registers. OV5642 document should be learnt a lot
before merging the patch.
Thank you
Angela
On Mon, Jul 4, 2011 at 3:35 AM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Hi Angela
On Sun, 3 Jul 2011, angela wan wrote:
Hi, Bastian,
Could the setting in ov5642.c like ov5642_default_regs_init and
ov5642_default_regs_finalise adapt to different board? From my experience,
ov5642 may have difference settings for differnt boards. So could we put the
setting in another file instead of in the common driver?
No, that's not the solution, that we want. What we want is find the
differences, understand them and learn to calculate them. So, for example,
if you need different power management procedures, or if you feed the
sensor with a different frequency clock, or if you use different lenses
and your WB or gain or any other parameters differ then, we might have to
use or add some platform parameters and verify them in the driver.
Thanks
Guennadi
Best Regards,
Angela Wan
Application Processor Systems Engineering,
Marvell Technology Group Ltd.
On Tue, Jun 28, 2011 at 5:48 AM, Bastian Hecht hec...@googlemail.comwrote:
2011/6/27 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Bastian,
Thanks for the patch.
On Friday 24 June 2011 12:57:36 Bastian Hecht wrote:
This is an initial driver release for the Omnivision 5642 CMOS sensor.
Signed-off-by: Bastian Hecht hec...@gmail.com
---
diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
new file mode 100644
index 000..3cdae97
--- /dev/null
+++ b/drivers/media/video/ov5642.c
@@ -0,0 +1,1011 @@
+/*
+ * Driver for OV5642 CMOS Image Sensor from Omnivision
+ *
+ * Copyright (C) 2011, Bastian Hecht hec...@gmail.com
+ *
+ * Based on Sony IMX074 Camera Driver
+ * Copyright (C) 2010, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * Based on Omnivision OV7670 Camera Driver
+ * Copyright (C) 2006-7 Jonathan Corbet cor...@lwn.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/slab.h
+#include linux/videodev2.h
+
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
+
+/* OV5642 registers */
+#define REG_CHIP_ID_HIGH 0x300a
+#define REG_CHIP_ID_LOW 0x300b
+
+#define REG_WINDOW_START_X_HIGH 0x3800
+#define REG_WINDOW_START_X_LOW 0x3801
+#define REG_WINDOW_START_Y_HIGH 0x3802
+#define REG_WINDOW_START_Y_LOW 0x3803
+#define REG_WINDOW_WIDTH_HIGH 0x3804
+#define REG_WINDOW_WIDTH_LOW 0x3805
+#define REG_WINDOW_HEIGHT_HIGH 0x3806
+#define REG_WINDOW_HEIGHT_LOW 0x3807
+#define REG_OUT_WIDTH_HIGH 0x3808
+#define REG_OUT_WIDTH_LOW 0x3809
+#define REG_OUT_HEIGHT_HIGH 0x380a
+#define REG_OUT_HEIGHT_LOW 0x380b
+#define REG_OUT_TOTAL_WIDTH_HIGH 0x380c
+#define REG_OUT_TOTAL_WIDTH_LOW 0x380d
+#define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e
+#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f
+
+/*
+ * define standard resolution.
+ * Works currently only for up to 720 lines
+ * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
+ */
+
+#define OV5642_WIDTH 1280
+#define OV5642_HEIGHT 720
+#define OV5642_TOTAL_WIDTH 3200
+#define OV5642_TOTAL_HEIGHT 2000
+#define OV5642_SENSOR_SIZE_X 2592
+#define OV5642_SENSOR_SIZE_Y 1944
+
+struct regval_list {
+ u16 reg_num;
+ u8 value;
+};
+
+static struct regval_list ov5642_default_regs_init[] = {
+ { 0x3103, 0x93 },
+ { 0x3008, 0x82 },
+ { 0x3017, 0x7f },
+ { 0x3018, 0xfc },
+ { 0x3810, 0xc2 },
+ { 0x3615, 0xf0 },
+ { 0x3000, 0x0 },
+ { 0x3001, 0x0 },
+ { 0x3002, 0x0 },
+ { 0x3003, 0x0 },
+ { 0x3004, 0xff },
+ { 0x3030, 0x2b },
+ { 0x3011, 0x8 },
+ { 0x3010, 0x10 },
+ { 0x3604, 0x60 },
+ { 0x3622, 0x60 },
+ { 0x3621, 0x9 },
+ {
RE: [ RFC PATCH 0/8] RFC for Media Controller capture driver for DM365
Hi Sakari, On Mon, Jul 04, 2011 at 21:43:09, Sakari Ailus wrote: Hadli, Manjunath wrote: Thank you Laurent. Hi Manjunath, On Mon, Jul 04, 2011 at 18:52:37, Laurent Pinchart wrote: Hi Manjunath, On Monday 04 July 2011 07:58:06 Hadli, Manjunath wrote: On Thu, Jun 30, 2011 at 19:27:36, Sakari Ailus wrote: [snip] I understand that not all the blocks are there. Are there any major functional differences between those in Davinci and those in OMAP 3? Could the OMAP 3 ISP driver made support Davinci ISP as well? Yes, there are a lot of major differences between OMAP3 and Dm365/Dm355, both in terms of features, there IP, and the software interface, including all the registers which are entirely different. The closest omap3 would come to is only to DM6446. I do not think OMAP3 driver can be made to support Dm355 and Dm365. It is good to keep the OMAP3 neat and clean to cater for OMAP4 and beyond, and keep the Davinci family separate. The names might look similar and hence confusing for you, but the names can as well be made the same as Dm365 blocks like ISIF and IPIPE and IPIPEIF which are different. The DM6446 ISP is very similar to the OMAP3 ISP, and thus quite different from the DM355/365 ISPs. Should the DM6446 be supported by the OMAP3 ISP driver, and the DM355/365 by this driver ? DM6446 capture IP is in some respects similar to OMAP3 for some features, but there are a large number of differences also (MMU, VRFB, a lot of display interfaces etc). Having a single driver catering to Since DM6446 and OMAP3 is going to be unwieldy. Also, DM6446 belongs to the Davinci family of chips, it should be clubbed with the other Davinci SoCs as it will simplify a lot of other things including directory subdirectory/file naming, organization of machine/platform code etc among other things. Other than Video a lot of other system registers and features which are common with the rest of Davinci SoCs which if treated together is a good thing, whereas OMAP3 can be modified and developed with those on the OMAP family (OMAP4 for ex). Thanks for the clarifications. What about the DM3730? As far as I understand, the ISP on that one is supported by the OMAP 3 ISP driver. But it looks like that it's more continuation for the OMAP family of the chips than the Davinci. Let me say that for all practical purposes, for developers, DM3730 is OMAP3. So a distinction between OMAP3 and DM3730 need not be made at all. As to why it is a Davinci device, has more to do with things outside the realm of development. So Dm3730 for us, including you and me, can be OMAP3, As the TRM says - It is OMAP3 compatible. I glanced at the DM6446 documentation and at the register level the interface looks somewhat different although some register names are the same. I didn't found a proper TRM which would be as detailed as the OMAP ones --- does TI have one available in public? TRMs for Davinci devices are slightly in a different format - split into multiple documents for each peripheral and system functionalities unlike a big singe doc for OMAP. But all the required documents are in public domain and can be found at : http://focus.ti.com/docs/prod/folders/print/tms320dm6446.html under the user guides category. If you are looking for some particular information, let me know and I can help you locate it. OMAP 4 has a quite different ISS --- which the ISP is a part of, and which also is very different to the OMAP 3 one --- so it's unlikely that the same driver would support OMAP 3 and OMAP 4 ISPs. Kind regards, -- Sakari Ailus sakari.ai...@iki.fi Regards, -Manjunath -- 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
