Re: [PATCH] media: vb2: dma-sg allocator: change scatterlist allocation method

[Laurent Pinchart]

Hi,

On Wednesday 10 August 2011 10:23:37 Marek Szyprowski wrote:
> From: Andrzej Pietrasiewicz 
> 
> Scatter-gather lib provides a helper functions to allocate scatter list,
> so there is no need to use vmalloc for it. sg_alloc_table() splits
> allocation into page size chunks and links them together into a chain.

Last time I check ARM platforms didn't support SG list chaining. Has that been 
fixed ?

> Signed-off-by: Andrzej Pietrasiewicz 
> Signed-off-by: Kyungmin Park 
> Signed-off-by: Marek Szyprowski 
> CC: Pawel Osciak 
> ---
>  drivers/media/video/videobuf2-dma-sg.c |   54
> +++ 1 files changed, 33 insertions(+), 21
> deletions(-)
> 
> diff --git a/drivers/media/video/videobuf2-dma-sg.c
> b/drivers/media/video/videobuf2-dma-sg.c index 065f468..e1158f9 100644
> --- a/drivers/media/video/videobuf2-dma-sg.c
> +++ b/drivers/media/video/videobuf2-dma-sg.c
> @@ -36,6 +36,8 @@ static void vb2_dma_sg_put(void *buf_priv);
>  static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long size)
>  {
>   struct vb2_dma_sg_buf *buf;
> + struct sg_table sgt;
> + struct scatterlist *sl;
>   int i;
> 
>   buf = kzalloc(sizeof *buf, GFP_KERNEL);
> @@ -48,23 +50,21 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned
> long size) buf->sg_desc.size = size;
>   buf->sg_desc.num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
> 
> - buf->sg_desc.sglist = vzalloc(buf->sg_desc.num_pages *
> -   sizeof(*buf->sg_desc.sglist));
> - if (!buf->sg_desc.sglist)
> + if (sg_alloc_table(&sgt, buf->sg_desc.num_pages, GFP_KERNEL))
>   goto fail_sglist_alloc;
> - sg_init_table(buf->sg_desc.sglist, buf->sg_desc.num_pages);
> + buf->sg_desc.sglist = sgt.sgl;
> 
>   buf->pages = kzalloc(buf->sg_desc.num_pages * sizeof(struct page *),
>GFP_KERNEL);
>   if (!buf->pages)
>   goto fail_pages_array_alloc;
> 
> - for (i = 0; i < buf->sg_desc.num_pages; ++i) {
> - buf->pages[i] = alloc_page(GFP_KERNEL | __GFP_ZERO | 
> __GFP_NOWARN);
> + for_each_sg(buf->sg_desc.sglist, sl, buf->sg_desc.num_pages, i) {
> + buf->pages[i] = alloc_page(GFP_KERNEL | __GFP_ZERO |
> +__GFP_NOWARN);
>   if (NULL == buf->pages[i])
>   goto fail_pages_alloc;
> - sg_set_page(&buf->sg_desc.sglist[i],
> - buf->pages[i], PAGE_SIZE, 0);
> + sg_set_page(sl, buf->pages[i], PAGE_SIZE, 0);
>   }
> 
>   buf->handler.refcount = &buf->refcount;
> @@ -89,7 +89,7 @@ fail_pages_alloc:
>   kfree(buf->pages);
> 
>  fail_pages_array_alloc:
> - vfree(buf->sg_desc.sglist);
> + sg_free_table(&sgt);
> 
>  fail_sglist_alloc:
>   kfree(buf);
> @@ -99,6 +99,7 @@ fail_sglist_alloc:
>  static void vb2_dma_sg_put(void *buf_priv)
>  {
>   struct vb2_dma_sg_buf *buf = buf_priv;
> + struct sg_table sgt;
>   int i = buf->sg_desc.num_pages;
> 
>   if (atomic_dec_and_test(&buf->refcount)) {
> @@ -106,7 +107,9 @@ static void vb2_dma_sg_put(void *buf_priv)
>   buf->sg_desc.num_pages);
>   if (buf->vaddr)
>   vm_unmap_ram(buf->vaddr, buf->sg_desc.num_pages);
> - vfree(buf->sg_desc.sglist);
> + sgt.sgl = buf->sg_desc.sglist;
> + sgt.orig_nents = sgt.nents = i;
> + sg_free_table(&sgt);
>   while (--i >= 0)
>   __free_page(buf->pages[i]);
>   kfree(buf->pages);
> @@ -118,6 +121,8 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx,
> unsigned long vaddr, unsigned long size, int write)
>  {
>   struct vb2_dma_sg_buf *buf;
> + struct sg_table sgt;
> + struct scatterlist *sl;
>   unsigned long first, last;
>   int num_pages_from_user, i;
> 
> @@ -134,12 +139,9 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx,
> unsigned long vaddr, last  = ((vaddr + size - 1) & PAGE_MASK) >>
> PAGE_SHIFT;
>   buf->sg_desc.num_pages = last - first + 1;
> 
> - buf->sg_desc.sglist = vzalloc(
> - buf->sg_desc.num_pages * sizeof(*buf->sg_desc.sglist));
> - if (!buf->sg_desc.sglist)
> + if (sg_alloc_table(&sgt, buf->sg_desc.num_pages, GFP_KERNEL))
>   goto userptr_fail_sglist_alloc;
> -
> - sg_init_table(buf->sg_desc.sglist, buf->sg_desc.num_pages);
> + buf->sg_desc.sglist = sgt.sgl;
> 
>   buf->pages = kzalloc(buf->sg_desc.num_pages * sizeof(struct page *),
>GFP_KERNEL);
> @@ -158,12 +160,12 @@ static void *vb2_dma_sg_get_userptr(void *alloc_ctx,
> unsigned long vaddr, if (num_pages_from_user != buf->sg_desc.num_pages)
>   goto userptr_fail_get_user_pages;
> 
> - sg_set_page(&buf->sg_desc.sglist[0], buf->pages[0],
> - PAGE_SIZE - buf->offset, buf->offset);
> + sl = buf->sg_desc.sglist;
> + sg_

Any support for Hauppauge WinTV-Duet (USB Dual Tuner)?

[nospam312]

I have searched the archives and can find no reference to this USB
stick so I suspect it is not supported.

Does anyone know if it is supported or not?

http://www.hauppauge.co.uk/site/products/data_duet.html

Thanks
--
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 driver

[Laurent Pinchart]

Hi Sriram,

On Tuesday 09 August 2011 19:03:17 Sriram V wrote:
> Hi,
>Does the omap3isp driver implementation support rgb888 format?

No, that's not supported. The driver only support raw sensors. Support for 
YUYV sensors could be implemented, but the hardware doesn't support RGB888 
(except maybe to capture it directly to memory for CSI2 sensors).

-- 
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: PROBLEM: Unable to handle kernel paging request

[Randy Dunlap]

On Fri, 12 Aug 2011 16:05:43 -0300 Mauro Carvalho Chehab wrote:

> Hi Josef,
> 
> Em 12-08-2011 14:28, Randy Dunlap escreveu:
> > On Fri, 12 Aug 2011 14:38:40 +0200 Josef Lusticky wrote:
> > 
> >> Hi Randy,
> >> thank you for your answer!
> >>
> >> The commit seems to fix issues with ip_vs_ctl module,
> >> but I got another panic today using the script on the same machine.
> >> Here's the output:
> > 
> > Hi Josef,
> > 
> > Adding linux-media mailing list...
> 
> 
> What kernel are you using? There were some fixes applied recently
> that fixes the register/unregister logic at the rc-core stuff. It helps
> if you could test against linux-next (not sure if all such fixes were already
> added at 3.0).

Mauro,
The Oops message shows:

> >> Pid: 39, comm: kworker/1:2 Tainted: G  I 3.1.0-rc1 #1


> >> *** Loading module lirc_dev ***
> >> lirc_dev: module unloaded
> >> IR JVC protocol handler initialized
> >> IR Sony protocol handler initialized
> >> IR MCE Keyboard/mouse protocol handler initialized
> >> lirc_dev: IR Remote Control driver registered, major 250
> >> IR LIRC bridge handler initialized
> >> *** Removing modBUG: unable to handle kernel paging request at 
> >> a0852acc
> >> IP: [] 0xa0852acb
> >> PGD 1a06067 PUD 1a0a063 PMD 37e50067 PTE 0
> >> Oops: 0010 [#1] SMP
> >> CPU 1
> >> Modules linked in: ir_lirc_codec lirc_dev ir_mce_kbd_decoder 
> >> ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder 
> >> ir_nec_decoder rc_core soc_mediabus ivtv cx2341x v4l2_common videodev 
> >> v4l2_compat_ioctl32 tveeprom dvb_usb_af9005_remote des_generic dccp_ipv6 
> >> dccp_ipv4 dccp sctp libcrc32c nf_tproxy_core ts_kmp kvm mce_inject 
> >> cryptd aes_x86_64 aes_generic snd_mpu401_uart snd_rawmidi snd_seq_dummy 
> >> snd_seq snd_seq_device sunrpc cpufreq_ondemand acpi_cpufreq freq_table 
> >> mperf ipv6 dm_mirror dm_region_hash dm_log ppdev parport_pc parport 
> >> hp_wmi sparse_keymap rfkill pcspkr serio_raw sg tg3 
> >> snd_hda_codec_realtek snd_hda_codec snd_hwdep snd_pcm snd_timer snd 
> >> soundcore snd_page_alloc x38_edac edac_core ext4 mbcache jbd2 floppy 
> >> sr_mod cdrom sd_mod crc_t10dif ahci libahci nouveau ttm drm_kms_helper 
> >> drm i2c_algo_bit i2c_core mxm_wmi wmi video dm_mod [last unloaded: 
> >> lirc_dev]
> >>
> >> Pid: 39, comm: kworker/1:2 Tainted: G  I 3.1.0-rc1 #1 
> >> Hewlett-Packard HP xw4600 Workstation/0AA0h
> >> RIP: 0010:[]  [] 0xa0852acb
> >> RSP: :8800387ffdf0  EFLAGS: 00010246
> >> RAX:  RBX: 880038784740 RCX: 
> >> RDX:  RSI: 0286 RDI: 0286
> >> RBP: 8800387ffdf0 R08:  R09: 0001
> >> R10: 0001 R11:  R12: 88003fc8e140
> >> R13: 88003fc96400 R14: a0852ab0 R15: 
> >> FS:  () GS:88003fc8() 
> >> knlGS:
> >> CS:  0010 DS:  ES:  CR0: 8005003b
> >> CR2: a0852acc CR3: 3608c000 CR4: 06e0
> >> DR0:  DR1:  DR2: 
> >> DR3:  DR6: 0ff0 DR7: 0400
> >> Process kworker/1:2 (pid: 39, threadinfo 8800387fe000, task 
> >> 8800386d8b00)
> >> Stack:
> >>   8800387ffe50 81082e11 88062ac0 a08544e0
> >>   88003fc96405 3fc8e140 880038784740 880038784740
> >>   88003fc8e140 88003fc8e148 880038784760 00013c80
> >> Call Trace:
> >>   [] process_one_work+0x131/0x450
> >>   [] worker_thread+0x17b/0x3c0
> >>   [] ? manage_workers+0x120/0x120
> >>   [] kthread+0x96/0xa0
> >>   [] kernel_thread_helper+0x4/0x10
> >>   [] ? kthread_worker_fn+0x1a0/0x1a0
> >>   [] ? gs_change+0x13/0x13
> >> Code:  Bad RIP value.
> >> RIP  [] 0xa0852acb
> >>   RSP 
> >> CR2: a0852acc
> >> ---[ end trace a7919e7f17c0a727 ]---
> >> ule xpnet ***
> >> *BUG: unable to handle kernel paging request at fff8
> >> IP: [] kthread_data+0x10/0x20
> >> PGD 1a06067 PUD 1a07067 PMD 0
> >> Oops:  [#2] SMP
> >> CPU 1
> >> Modules linked in: xpnet(-) xp gru ir_lirc_codec lirc_dev 
> >> ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder 
> >> ir_rc5_decoder ir_nec_decoder rc_core soc_mediabus ivtv cx2341x 
> >> v4l2_common videodev v4l2_compat_ioctl32 tveeprom dvb_usb_af9005_remote 
> >> des_generic dccp_ipv6 dccp_ipv4 dccp sctp libcrc32c nf_tproxy_core 
> >> ts_kmp kvm mce_inject cryptd aes_x86_64 aes_generic snd_mpu401_uart 
> >> snd_rawmidi snd_seq_dummy snd_seq snd_seq_device sunrpc cpufreq_ondemand 
> >> acpi_cpufreq freq_table mperf ipv6 dm_mirror dm_region_hash dm_log ppdev 
> >> parport_pc parport hp_wmi sparse_keymap rfkill pcspkr serio_raw sg tg3 
> >> snd_hda_codec_realtek snd_hda_codec snd_hwdep snd_pcm snd_timer snd 
> >> soundcore snd_page_alloc x38_edac edac_core ext4 mbcache jbd2 floppy 
> >> sr_mod cdrom sd_mod crc_t10dif

Re: [QUERY] Inclusion of isp.h in board-omap3evm-camera.c

[Laurent Pinchart]

Hi Ravi,

On Friday 12 August 2011 09:35:16 Ravi, Deepthy wrote:
> I need to use some isp structures ( isp_v4l2_subdevs_group,
> isp_platform_data ,isp_subdev_i2c_board_info etc.) in 
> board-omap3evm-camera.c. For that header file isp.h has to be included .
> Currently I am including it in this way:
> 
> #include <../drivers/media/video/omap3isp/isp.h>

OMAP3 ISP platform data should be split from isp.h into 
include/media/omap3isp.h. I've sent a patch for that to the linux-media 
mailing list and CC'ed you.

Unfortunately that won't be enough, as board code currently requires the 
isp_device structure definition to access the platform callback functions. 
Those functions will be removed in the future when more generic alternatives 
will be available, but there's still some work required for that.

> Is there a better way to do this ? The relevant hunk of the patch is shown
> below:
> 
> diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
> b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644
> index 000..319a6a1
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +
> +#include <../drivers/media/video/omap3isp/isp.h>

#include "../drivers/media/video/omap3isp/isp.h"

but that's not really better :-)

You should include  (after applying the patch that creates 
that file). If your board code doesn't use the OMAP3 ISP platform callback 
functions, you don't need to include the isp.h header at all.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] omap3isp: Move platform data definitions from isp.h to media/omap3isp.h

[Laurent Pinchart]

drivers/media/video/omap3isp/isp.h is not a proper location for a header
that needs to be included from board code. Move the platform data
definitions to media/omap3isp.h.

Board code still needs to include isp.h to get the struct isp_device
definition and access OMAP3 ISP platform callbacks. Those callbacks will
be replaced by more generic code.

Signed-off-by: Laurent Pinchart 
---
 drivers/media/video/omap3isp/isp.h |   85 +---
 drivers/media/video/omap3isp/ispccp2.c |4 +-
 include/media/omap3isp.h   |  140 
 3 files changed, 143 insertions(+), 86 deletions(-)
 create mode 100644 include/media/omap3isp.h

diff --git a/drivers/media/video/omap3isp/isp.h 
b/drivers/media/video/omap3isp/isp.h
index 529e582..521db0c 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -27,6 +27,7 @@
 #ifndef OMAP3_ISP_CORE_H
 #define OMAP3_ISP_CORE_H
 
+#include 
 #include 
 #include 
 #include 
@@ -94,14 +95,6 @@ enum isp_subclk_resource {
OMAP3_ISP_SUBCLK_RESIZER= (1 << 4),
 };
 
-enum isp_interface_type {
-   ISP_INTERFACE_PARALLEL,
-   ISP_INTERFACE_CSI2A_PHY2,
-   ISP_INTERFACE_CCP2B_PHY1,
-   ISP_INTERFACE_CCP2B_PHY2,
-   ISP_INTERFACE_CSI2C_PHY1,
-};
-
 /* ISP: OMAP 34xx ES 1.0 */
 #define ISP_REVISION_1_0   0x10
 /* ISP2: OMAP 34xx ES 2.0, 2.1 and 3.0 */
@@ -130,82 +123,6 @@ struct isp_reg {
u32 val;
 };
 
-/**
- * struct isp_parallel_platform_data - Parallel interface platform data
- * @data_lane_shift: Data lane shifter
- * 0 - CAMEXT[13:0] -> CAM[13:0]
- * 1 - CAMEXT[13:2] -> CAM[11:0]
- * 2 - CAMEXT[13:4] -> CAM[9:0]
- * 3 - CAMEXT[13:6] -> CAM[7:0]
- * @clk_pol: Pixel clock polarity
- * 0 - Non Inverted, 1 - Inverted
- * @hs_pol: Horizontal synchronization polarity
- * 0 - Active high, 1 - Active low
- * @vs_pol: Vertical synchronization polarity
- * 0 - Active high, 1 - Active low
- * @bridge: CCDC Bridge input control
- * ISPCTRL_PAR_BRIDGE_DISABLE - Disable
- * ISPCTRL_PAR_BRIDGE_LENDIAN - Little endian
- * ISPCTRL_PAR_BRIDGE_BENDIAN - Big endian
- */
-struct isp_parallel_platform_data {
-   unsigned int data_lane_shift:2;
-   unsigned int clk_pol:1;
-   unsigned int hs_pol:1;
-   unsigned int vs_pol:1;
-   unsigned int bridge:4;
-};
-
-/**
- * struct isp_ccp2_platform_data - CCP2 interface platform data
- * @strobe_clk_pol: Strobe/clock polarity
- * 0 - Non Inverted, 1 - Inverted
- * @crc: Enable the cyclic redundancy check
- * @ccp2_mode: Enable CCP2 compatibility mode
- * 0 - MIPI-CSI1 mode, 1 - CCP2 mode
- * @phy_layer: Physical layer selection
- * ISPCCP2_CTRL_PHY_SEL_CLOCK - Data/clock physical layer
- * ISPCCP2_CTRL_PHY_SEL_STROBE - Data/strobe physical layer
- * @vpclk_div: Video port output clock control
- */
-struct isp_ccp2_platform_data {
-   unsigned int strobe_clk_pol:1;
-   unsigned int crc:1;
-   unsigned int ccp2_mode:1;
-   unsigned int phy_layer:1;
-   unsigned int vpclk_div:2;
-};
-
-/**
- * struct isp_csi2_platform_data - CSI2 interface platform data
- * @crc: Enable the cyclic redundancy check
- * @vpclk_div: Video port output clock control
- */
-struct isp_csi2_platform_data {
-   unsigned crc:1;
-   unsigned vpclk_div:2;
-};
-
-struct isp_subdev_i2c_board_info {
-   struct i2c_board_info *board_info;
-   int i2c_adapter_id;
-};
-
-struct isp_v4l2_subdevs_group {
-   struct isp_subdev_i2c_board_info *subdevs;
-   enum isp_interface_type interface;
-   union {
-   struct isp_parallel_platform_data parallel;
-   struct isp_ccp2_platform_data ccp2;
-   struct isp_csi2_platform_data csi2;
-   } bus; /* gcc < 4.6.0 chokes on anonymous union initializers */
-};
-
-struct isp_platform_data {
-   struct isp_v4l2_subdevs_group *subdevs;
-   void (*set_constraints)(struct isp_device *isp, bool enable);
-};
-
 struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
int (*csiphy_config)(struct isp_csiphy *phy,
diff --git a/drivers/media/video/omap3isp/ispccp2.c 
b/drivers/media/video/omap3isp/ispccp2.c
index ec9e395f..fa1d09b 100644
--- a/drivers/media/video/omap3isp/ispccp2.c
+++ b/drivers/media/video/omap3isp/ispccp2.c
@@ -243,9 +243,9 @@ static int ccp2_phyif_config(struct isp_ccp2_device *ccp2,
 
val = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCP2, ISPCCP2_CTRL);
if (!(val & ISPCCP2_CTRL_MODE)) {
-   if (pdata->ccp2_mode)
+   if (pdata->ccp2_mode == ISP_CCP2_MODE_CCP2)
dev_warn(isp->dev, "OMAP3 CCP2 bus not available\n");
-   if (pdata->phy_layer == ISPCCP2_CTRL_PHY_SEL_STROBE)
+   if (pdata->phy_layer == ISP_CCP2_PHY_DAT

[cron job] v4l-dvb daily build: WARNINGS

[Hans Verkuil]

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:Fri Aug 12 19:00:30 CEST 2011
git hash:9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e
gcc version:  i686-linux-gcc (GCC) 4.6.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-3.0-i686: WARNINGS
linux-3.1-rc1-i686: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-rc1-x86_64: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2

The 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: Is V4L2_PIX_FMT_RGB656 RGB or BGR ?

[Mauro Carvalho Chehab]

Em 12-08-2011 13:26, Laurent Pinchart escreveu:
> According to http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html, 
> V4L2_PIX_FMT_RGB565 is defined as
> 
>  Identifier   Byte 0 in memory Byte 1 
>   Bit  7  6  5  4  3  2  1  07  6  5  4  3  2  1  0
>  V4L2_PIX_FMT_RGB565  g2 g1 g0 r4 r3 r2 r1 r0   b4 b3 b2 b1 b0 g5 g4 g3
> 
> As this is stored in little-endian, the color word is thus
> 
> b4 b3 b2 b1 b0 g5 g4 g3 g2 g1 g0 r4 r3 r2 r1 r0
> 
> This looks awfully like BGR to me, not RGB.
> 
> I need to define a FOURCC for the corresponding RGB format
> 
>  Identifier   Byte 0 in memory Byte 1 
>   Bit  7  6  5  4  3  2  1  07  6  5  4  3  2  1  0
>  V4L2_PIX_FMT_RGB565  g2 g1 g0 b4 b3 b2 b1 b0   r4 r3 r2 r1 r0 g5 g4 g3
> 
> Should I call it V4L2_PIX_FMT_BGR565 ? :-)
> 

Had you seen both Tables 2.6 and 2.7?

http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html#rgb-formats-corrected

The format you're looking for is "table 2.7" version of V4L2_PIX_FMT_BGR565.

Yeah, this looks crazy. Basically, some drivers were using it on one way, while
other drivers were using it the other way. I suspect that this trouble were 
there
since V4L1 times.

See at the changelogs 
(http://linuxtv.org/downloads/v4l-dvb-apis/hist-v4l2.html),
in particular the one on 2003:

1998-11-14: V4L2_PIX_FMT_RGB24 changed to V4L2_PIX_FMT_BGR24, and 
V4L2_PIX_FMT_RGB32 changed to V4L2_PIX_FMT_BGR32. Audio controls are now 
accessible with the VIDIOC_G_CTRL and VIDIOC_S_CTRL ioctls under names starting 
with V4L2_CID_AUDIO. The V4L2_MAJOR define was removed from videodev.h since it 
was only used once in the videodev kernel module. The YUV422 and YUV411 planar 
image formats were added.

2001-04-13: Big endian 16-bit RGB formats were added.

V4L2 2003-11-05:

  In the section called “RGB Formats” the following pixel formats were 
incorrectly transferred from Bill Dirks' V4L2 specification. Descriptions below 
refer to bytes in memory, in ascending address order.
  In the section called “Image Properties” the mapping of the V4L 
VIDEO_PALETTE_RGB24 and VIDEO_PALETTE_RGB32 formats to V4L2 pixel formats was 
accordingly corrected.
  Unrelated to the fixes above, drivers may still interpret some V4L2 RGB pixel 
formats differently. These issues have yet to be addressed, for details see the 
section called “RGB Formats”.


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: PROBLEM: Unable to handle kernel paging request

[Mauro Carvalho Chehab]

Hi Josef,

Em 12-08-2011 14:28, Randy Dunlap escreveu:
> On Fri, 12 Aug 2011 14:38:40 +0200 Josef Lusticky wrote:
> 
>> Hi Randy,
>> thank you for your answer!
>>
>> The commit seems to fix issues with ip_vs_ctl module,
>> but I got another panic today using the script on the same machine.
>> Here's the output:
> 
> Hi Josef,
> 
> Adding linux-media mailing list...


What kernel are you using? There were some fixes applied recently
that fixes the register/unregister logic at the rc-core stuff. It helps
if you could test against linux-next (not sure if all such fixes were already
added at 3.0).

> 
> 
>> *** Loading module lirc_dev ***
>> lirc_dev: module unloaded
>> IR JVC protocol handler initialized
>> IR Sony protocol handler initialized
>> IR MCE Keyboard/mouse protocol handler initialized
>> lirc_dev: IR Remote Control driver registered, major 250
>> IR LIRC bridge handler initialized
>> *** Removing modBUG: unable to handle kernel paging request at 
>> a0852acc
>> IP: [] 0xa0852acb
>> PGD 1a06067 PUD 1a0a063 PMD 37e50067 PTE 0
>> Oops: 0010 [#1] SMP
>> CPU 1
>> Modules linked in: ir_lirc_codec lirc_dev ir_mce_kbd_decoder 
>> ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder 
>> ir_nec_decoder rc_core soc_mediabus ivtv cx2341x v4l2_common videodev 
>> v4l2_compat_ioctl32 tveeprom dvb_usb_af9005_remote des_generic dccp_ipv6 
>> dccp_ipv4 dccp sctp libcrc32c nf_tproxy_core ts_kmp kvm mce_inject 
>> cryptd aes_x86_64 aes_generic snd_mpu401_uart snd_rawmidi snd_seq_dummy 
>> snd_seq snd_seq_device sunrpc cpufreq_ondemand acpi_cpufreq freq_table 
>> mperf ipv6 dm_mirror dm_region_hash dm_log ppdev parport_pc parport 
>> hp_wmi sparse_keymap rfkill pcspkr serio_raw sg tg3 
>> snd_hda_codec_realtek snd_hda_codec snd_hwdep snd_pcm snd_timer snd 
>> soundcore snd_page_alloc x38_edac edac_core ext4 mbcache jbd2 floppy 
>> sr_mod cdrom sd_mod crc_t10dif ahci libahci nouveau ttm drm_kms_helper 
>> drm i2c_algo_bit i2c_core mxm_wmi wmi video dm_mod [last unloaded: lirc_dev]
>>
>> Pid: 39, comm: kworker/1:2 Tainted: G  I 3.1.0-rc1 #1 
>> Hewlett-Packard HP xw4600 Workstation/0AA0h
>> RIP: 0010:[]  [] 0xa0852acb
>> RSP: :8800387ffdf0  EFLAGS: 00010246
>> RAX:  RBX: 880038784740 RCX: 
>> RDX:  RSI: 0286 RDI: 0286
>> RBP: 8800387ffdf0 R08:  R09: 0001
>> R10: 0001 R11:  R12: 88003fc8e140
>> R13: 88003fc96400 R14: a0852ab0 R15: 
>> FS:  () GS:88003fc8() knlGS:
>> CS:  0010 DS:  ES:  CR0: 8005003b
>> CR2: a0852acc CR3: 3608c000 CR4: 06e0
>> DR0:  DR1:  DR2: 
>> DR3:  DR6: 0ff0 DR7: 0400
>> Process kworker/1:2 (pid: 39, threadinfo 8800387fe000, task 
>> 8800386d8b00)
>> Stack:
>>   8800387ffe50 81082e11 88062ac0 a08544e0
>>   88003fc96405 3fc8e140 880038784740 880038784740
>>   88003fc8e140 88003fc8e148 880038784760 00013c80
>> Call Trace:
>>   [] process_one_work+0x131/0x450
>>   [] worker_thread+0x17b/0x3c0
>>   [] ? manage_workers+0x120/0x120
>>   [] kthread+0x96/0xa0
>>   [] kernel_thread_helper+0x4/0x10
>>   [] ? kthread_worker_fn+0x1a0/0x1a0
>>   [] ? gs_change+0x13/0x13
>> Code:  Bad RIP value.
>> RIP  [] 0xa0852acb
>>   RSP 
>> CR2: a0852acc
>> ---[ end trace a7919e7f17c0a727 ]---
>> ule xpnet ***
>> *BUG: unable to handle kernel paging request at fff8
>> IP: [] kthread_data+0x10/0x20
>> PGD 1a06067 PUD 1a07067 PMD 0
>> Oops:  [#2] SMP
>> CPU 1
>> Modules linked in: xpnet(-) xp gru ir_lirc_codec lirc_dev 
>> ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder 
>> ir_rc5_decoder ir_nec_decoder rc_core soc_mediabus ivtv cx2341x 
>> v4l2_common videodev v4l2_compat_ioctl32 tveeprom dvb_usb_af9005_remote 
>> des_generic dccp_ipv6 dccp_ipv4 dccp sctp libcrc32c nf_tproxy_core 
>> ts_kmp kvm mce_inject cryptd aes_x86_64 aes_generic snd_mpu401_uart 
>> snd_rawmidi snd_seq_dummy snd_seq snd_seq_device sunrpc cpufreq_ondemand 
>> acpi_cpufreq freq_table mperf ipv6 dm_mirror dm_region_hash dm_log ppdev 
>> parport_pc parport hp_wmi sparse_keymap rfkill pcspkr serio_raw sg tg3 
>> snd_hda_codec_realtek snd_hda_codec snd_hwdep snd_pcm snd_timer snd 
>> soundcore snd_page_alloc x38_edac edac_core ext4 mbcache jbd2 floppy 
>> sr_mod cdrom sd_mod crc_t10dif ahci libahci nouveau ttm drm_kms_helper 
>> drm i2c_algo_bit i2c_core mxm_wmi wmi video dm_mod [last unloaded: lirc_dev]
>>
>> Pid: 39, comm: kworker/1:2 Tainted: G  D   I 3.1.0-rc1 #1 
>> Hewlett-Packard HP xw4600 Workstation/0AA0h
>> RIP: 0010:[]  [] kthread_data+0x10/0x20
>> RSP: 0018:8800387ffa38  EFLAGS: 00010096
>> RAX:  RBX: 000

Re: PROBLEM: Unable to handle kernel paging request

[Randy Dunlap]

On Fri, 12 Aug 2011 14:38:40 +0200 Josef Lusticky wrote:

> Hi Randy,
> thank you for your answer!
> 
> The commit seems to fix issues with ip_vs_ctl module,
> but I got another panic today using the script on the same machine.
> Here's the output:

Hi Josef,

Adding linux-media mailing list...


> *** Loading module lirc_dev ***
> lirc_dev: module unloaded
> IR JVC protocol handler initialized
> IR Sony protocol handler initialized
> IR MCE Keyboard/mouse protocol handler initialized
> lirc_dev: IR Remote Control driver registered, major 250
> IR LIRC bridge handler initialized
> *** Removing modBUG: unable to handle kernel paging request at 
> a0852acc
> IP: [] 0xa0852acb
> PGD 1a06067 PUD 1a0a063 PMD 37e50067 PTE 0
> Oops: 0010 [#1] SMP
> CPU 1
> Modules linked in: ir_lirc_codec lirc_dev ir_mce_kbd_decoder 
> ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder 
> ir_nec_decoder rc_core soc_mediabus ivtv cx2341x v4l2_common videodev 
> v4l2_compat_ioctl32 tveeprom dvb_usb_af9005_remote des_generic dccp_ipv6 
> dccp_ipv4 dccp sctp libcrc32c nf_tproxy_core ts_kmp kvm mce_inject 
> cryptd aes_x86_64 aes_generic snd_mpu401_uart snd_rawmidi snd_seq_dummy 
> snd_seq snd_seq_device sunrpc cpufreq_ondemand acpi_cpufreq freq_table 
> mperf ipv6 dm_mirror dm_region_hash dm_log ppdev parport_pc parport 
> hp_wmi sparse_keymap rfkill pcspkr serio_raw sg tg3 
> snd_hda_codec_realtek snd_hda_codec snd_hwdep snd_pcm snd_timer snd 
> soundcore snd_page_alloc x38_edac edac_core ext4 mbcache jbd2 floppy 
> sr_mod cdrom sd_mod crc_t10dif ahci libahci nouveau ttm drm_kms_helper 
> drm i2c_algo_bit i2c_core mxm_wmi wmi video dm_mod [last unloaded: lirc_dev]
> 
> Pid: 39, comm: kworker/1:2 Tainted: G  I 3.1.0-rc1 #1 
> Hewlett-Packard HP xw4600 Workstation/0AA0h
> RIP: 0010:[]  [] 0xa0852acb
> RSP: :8800387ffdf0  EFLAGS: 00010246
> RAX:  RBX: 880038784740 RCX: 
> RDX:  RSI: 0286 RDI: 0286
> RBP: 8800387ffdf0 R08:  R09: 0001
> R10: 0001 R11:  R12: 88003fc8e140
> R13: 88003fc96400 R14: a0852ab0 R15: 
> FS:  () GS:88003fc8() knlGS:
> CS:  0010 DS:  ES:  CR0: 8005003b
> CR2: a0852acc CR3: 3608c000 CR4: 06e0
> DR0:  DR1:  DR2: 
> DR3:  DR6: 0ff0 DR7: 0400
> Process kworker/1:2 (pid: 39, threadinfo 8800387fe000, task 
> 8800386d8b00)
> Stack:
>   8800387ffe50 81082e11 88062ac0 a08544e0
>   88003fc96405 3fc8e140 880038784740 880038784740
>   88003fc8e140 88003fc8e148 880038784760 00013c80
> Call Trace:
>   [] process_one_work+0x131/0x450
>   [] worker_thread+0x17b/0x3c0
>   [] ? manage_workers+0x120/0x120
>   [] kthread+0x96/0xa0
>   [] kernel_thread_helper+0x4/0x10
>   [] ? kthread_worker_fn+0x1a0/0x1a0
>   [] ? gs_change+0x13/0x13
> Code:  Bad RIP value.
> RIP  [] 0xa0852acb
>   RSP 
> CR2: a0852acc
> ---[ end trace a7919e7f17c0a727 ]---
> ule xpnet ***
> *BUG: unable to handle kernel paging request at fff8
> IP: [] kthread_data+0x10/0x20
> PGD 1a06067 PUD 1a07067 PMD 0
> Oops:  [#2] SMP
> CPU 1
> Modules linked in: xpnet(-) xp gru ir_lirc_codec lirc_dev 
> ir_mce_kbd_decoder ir_sony_decoder ir_jvc_decoder ir_rc6_decoder 
> ir_rc5_decoder ir_nec_decoder rc_core soc_mediabus ivtv cx2341x 
> v4l2_common videodev v4l2_compat_ioctl32 tveeprom dvb_usb_af9005_remote 
> des_generic dccp_ipv6 dccp_ipv4 dccp sctp libcrc32c nf_tproxy_core 
> ts_kmp kvm mce_inject cryptd aes_x86_64 aes_generic snd_mpu401_uart 
> snd_rawmidi snd_seq_dummy snd_seq snd_seq_device sunrpc cpufreq_ondemand 
> acpi_cpufreq freq_table mperf ipv6 dm_mirror dm_region_hash dm_log ppdev 
> parport_pc parport hp_wmi sparse_keymap rfkill pcspkr serio_raw sg tg3 
> snd_hda_codec_realtek snd_hda_codec snd_hwdep snd_pcm snd_timer snd 
> soundcore snd_page_alloc x38_edac edac_core ext4 mbcache jbd2 floppy 
> sr_mod cdrom sd_mod crc_t10dif ahci libahci nouveau ttm drm_kms_helper 
> drm i2c_algo_bit i2c_core mxm_wmi wmi video dm_mod [last unloaded: lirc_dev]
> 
> Pid: 39, comm: kworker/1:2 Tainted: G  D   I 3.1.0-rc1 #1 
> Hewlett-Packard HP xw4600 Workstation/0AA0h
> RIP: 0010:[]  [] kthread_data+0x10/0x20
> RSP: 0018:8800387ffa38  EFLAGS: 00010096
> RAX:  RBX: 0001 RCX: 0001
> RDX: 0001 RSI: 0001 RDI: 8800386d8b00
> RBP: 8800387ffa38 R08: 8800386d8b70 R09: dead00200200
> R10: 0400 R11: 0001 R12: 8800386d90a8
> R13: 0001 R14: 0001 R15: 0096
> FS:  () GS:88003fc8() knlGS:
> CS:  0010 DS

Is V4L2_PIX_FMT_RGB656 RGB or BGR ?

[Laurent Pinchart]

According to http://linuxtv.org/downloads/v4l-dvb-apis/packed-rgb.html, 
V4L2_PIX_FMT_RGB565 is defined as

 Identifier   Byte 0 in memory Byte 1 
  Bit  7  6  5  4  3  2  1  07  6  5  4  3  2  1  0
 V4L2_PIX_FMT_RGB565  g2 g1 g0 r4 r3 r2 r1 r0   b4 b3 b2 b1 b0 g5 g4 g3

As this is stored in little-endian, the color word is thus

b4 b3 b2 b1 b0 g5 g4 g3 g2 g1 g0 r4 r3 r2 r1 r0

This looks awfully like BGR to me, not RGB.

I need to define a FOURCC for the corresponding RGB format

 Identifier   Byte 0 in memory Byte 1 
  Bit  7  6  5  4  3  2  1  07  6  5  4  3  2  1  0
 V4L2_PIX_FMT_RGB565  g2 g1 g0 b4 b3 b2 b1 b0   r4 r3 r2 r1 r0 g5 g4 g3

Should I call it V4L2_PIX_FMT_BGR565 ? :-)

-- 
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: USB mini-summit at LinuxCon Vancouver

[Alan Stern]

On Fri, 12 Aug 2011, Hans de Goede wrote:

> > I'm not claiming that this is a better solution than putting everything
> > in the kernel.  Just that it is a workable alternative which would
> > involve a lot less coding.
> 
> This is definitely an interesting proposal, something to think about ...
> 
> I have 2 concerns wrt this approach:
> 
> 1) It feels less clean then just having a single driver; and

Agreed.

> 2) I agree it will be less coding, but I doubt it will really be that much
> less work. It will likely need less new code (but a lot can be more or
> less copy pasted), but it will need changes across a wider array of
> subsystems / userspace components, requiring a lot of coordinating,
> getting patches merged in different projects, etc. So in the end I
> think it too will be quite a bit of work.
> 
> I guess that what I'm trying to say here is, that if we are going to
> spend a significant amount of time on this, we might just as well
> go for the best solution we can come up with even if that is some
> more work.

Okay, go ahead.  I have no objection.

Alan Stern

--
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/9] ARM: integrate CMA with DMA-mapping subsystem

[Arnd Bergmann]

On Friday 12 August 2011, Marek Szyprowski wrote:
> @@ -82,16 +103,16 @@ static struct page *__dma_alloc_buffer(struct device 
> *dev, size_t size, gfp_t gf
>   if (mask < 0xULL)
>   gfp |= GFP_DMA;
>  
> - page = alloc_pages(gfp, order);
> - if (!page)
> - return NULL;
> -
>   /*
> -  * Now split the huge page and free the excess pages
> +  * Allocate contiguous memory
>*/
> - split_page(page, order);
> - for (p = page + (size >> PAGE_SHIFT), e = page + (1 << order); p < e; 
> p++)
> - __free_page(p);
> + if (cma_available())
> + page = dma_alloc_from_contiguous(dev, count, order);
> + else
> + page = __dma_alloc_system_pages(count, gfp, order);
> +
> + if (!page)
> + return NULL;

Why do you need the fallback here? I would assume that CMA now has to be 
available
on ARMv6 and up to work at all. When you allocate from 
__dma_alloc_system_pages(),
wouldn't that necessarily fail in the dma_remap_area() stage?

>  
> - if (arch_is_coherent() || nommu()) {
> + if (arch_is_coherent() || nommu() ||
> +(cma_available() && !(gfp & GFP_ATOMIC))) {
> + /*
> +  * Allocate from system or CMA pages
> +  */
>   struct page *page = __dma_alloc_buffer(dev, size, gfp);
>   if (!page)
>   return NULL;
> + dma_remap_area(page, size, area->prot);
>   pfn = page_to_pfn(page);
>   ret = page_address(page);

Similarly with coherent and nommu. It seems to me that lumping too
many cases together creates extra complexity here.

How about something like

if (arch_is_coherent() || nommu())
ret = alloc_simple_buffer();
else if (arch_is_v4_v5())
ret = alloc_remap();
else if (gfp & GFP_ATOMIC)
ret = alloc_from_pool();
else
ret = alloc_from_contiguous();

This also allows a natural conversion to dma_map_ops when we get there.

>   /* reserve any platform specific memblock areas */
>   if (mdesc->reserve)
>   mdesc->reserve();
>  
> + dma_coherent_reserve();
> + dma_contiguous_reserve();
> +
>   memblock_analyze();
>   memblock_dump_all();
>  }

Since we can handle most allocations using CMA on ARMv6+, I would think
that we can have a much smaller reserved area. Have you tried changing
dma_coherent_reserve() to allocate out of the contiguous area instead of
wasting a full 2MB section of memory?

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 7/9] ARM: DMA: steal memory for DMA coherent mappings

[Arnd Bergmann]

On Friday 12 August 2011, Marek Szyprowski wrote:
> 
> From: Russell King 
> 
> Steal memory from the kernel to provide coherent DMA memory to drivers.
> This avoids the problem with multiple mappings with differing attributes
> on later CPUs.
> 
> Signed-off-by: Russell King 
> [m.szyprowski: rebased onto 3.1-rc1]
> Signed-off-by: Marek Szyprowski 

Hi Marek,

Is this the same patch that Russell had to revert because it didn't
work on some of the older machines, in particular those using
dmabounce?

I thought that our discussion ended with the plan to use this only
for ARMv6+ (which has a problem with double mapping) but not on ARMv5
and below (which don't have this problem but might need dmabounce).

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drivers/media/video/zr364xx.c: add missing cleanup code

[Julia Lawall]

From: Julia Lawall 

It seems just as necessary to free cam->vdev and cam in this error case as
in the next one.

Signed-off-by: Julia Lawall 

---
There is yet another block of error handling code below the call to
zr364xx_board_init, but perhaps no cleanup code is needed in that case,
because that code is currently initializing a lock in cam?

 drivers/media/video/zr364xx.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/video/zr364xx.c b/drivers/media/video/zr364xx.c
index c492846..e78cf94 100644
--- a/drivers/media/video/zr364xx.c
+++ b/drivers/media/video/zr364xx.c
@@ -1638,6 +1638,9 @@ static int zr364xx_probe(struct usb_interface *intf,
 
if (!cam->read_endpoint) {
dev_err(&intf->dev, "Could not find bulk-in endpoint\n");
+   video_device_release(cam->vdev);
+   kfree(cam);
+   cam = NULL;
return -ENOMEM;
}
 

--
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

[PATCHv14 0/9] Contiguous Memory Allocator

[Marek Szyprowski]

Hello again,

Like I promissed on Linaro Sprint meeting, yet another round of
Contiguous Memory Allocator patches are now available. I hope that this
version finally solves all pending issues and can be widely tested in
ARM platform as well as finally be merged to -next kernel tree for even
more testing.

This version provides a solution for complete integration of CMA to DMA
mapping subsystem on ARM architecture. The issue caused by double dma
pages mapping and possible aliasing in coherent memory mapping has been
finally resolved, both for GFP_ATOMIC case (allocations comes from
reserved DMA memory pool) and non-GFP_ATOMIC case (allocations comes
from CMA managed areas).

All patches are prepared for Linux Kernel v3.1-rc1.

A few words for these who see CMA for the first time:

   The Contiguous Memory Allocator (CMA) makes it possible for device
   drivers to allocate big contiguous chunks of memory after the system
   has booted. 

   The main difference from the similar frameworks is the fact that CMA
   allows to transparently reuse memory region reserved for the big
   chunk allocation as a system memory, so no memory is wasted when no
   big chunk is allocated. Once the alloc request is issued, the
   framework will migrate system pages to create a required big chunk of
   physically contiguous memory.

   For more information you can refer to nice LWN articles: 
   http://lwn.net/Articles/447405/ and http://lwn.net/Articles/450286/
   as well as links to previous versions of the CMA framework.

   The CMA framework has been initially developed by Michal Nazarewicz
   at Samsung Poland R&D Center. Since version 9, I've taken over the
   development, because Michal has left the company.

The current version of CMA is a set of helper functions for DMA mapping
framework that handles allocation of contiguous memory blocks. The
difference between this patchset and Kamezawa's alloc_contig_pages()
are:

1. alloc_contig_pages() requires MAX_ORDER alignment of allocations
   which may be unsuitable for embeded systems where a few MiBs are
   required.

   Lack of the requirement on the alignment means that several threads
   might try to access the same pageblock/page.  To prevent this from
   happening CMA uses a mutex so that only one allocating/releasing
   function may run at one point.

2. CMA may use its own migratetype (MIGRATE_CMA) which behaves
   similarly to ZONE_MOVABLE but can be put in arbitrary places.

   This is required for us since we need to define two disjoint memory
   ranges inside system RAM.  (ie. in two memory banks (do not confuse
   with nodes)).

3. alloc_contig_pages() scans memory in search for range that could be
   migrated.  CMA on the other hand maintains its own allocator to
   decide where to allocate memory for device drivers and then tries
   to migrate pages from that part if needed.  This is not strictly
   required but I somehow feel it might be faster.

The integration with ARM DMA-mapping subsystem is done on 2 levels.
During early boot memory reserved for contiguous areas are remapped with
2-level page tables. This enables us to change cache attributes of the
individual pages from such area on request. Then, DMA mapping subsystem
is updated to use dma_alloc_from_contiguous() call instead of
alloc_pages() and perform page attributes remapping.

Current version have been tested on Samsung S5PC110 based Goni machine
and s5p-fimc V4L2 driver. The driver itself uses videobuf2 dma-contig
memory allocator, which in turn relies on dma_alloc_coherent() from
DMA-mapping subsystem. By integrating CMA with DMA-mapping we managed to
get this driver working with CMA without any single change required in
the driver or videobuf2-dma-contig allocator.

TODO (optional):
- implement support for contiguous memory areas placed in HIGHMEM zone

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center


Links to previous versions of the patchset:
v13: (internal, intentionally not released)
v12: 
v11: 
v10: 
 v9: 
 v8: 
 v7: 
 v6: 
 v5: (intentionally left out as CMA v5 was identical to CMA v4)
 v4: 
 v3: 
 v2: 
 v1: 


Changelog:

v14:
1. Merged with "ARM: DMA: steal memory for DMA coherent mappings" 
   patch, added support for GFP_ATOMIC allocations.

2. Added checks for NULL device pointer

v13: (internal, intentionally not released)

v12:
1. Fixed 2 nasty bugs in dma-contiguous al

[PATCH 4/9] mm: MIGRATE_CMA migration type added

[Marek Szyprowski]

From: Michal Nazarewicz 

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 
Signed-off-by: Kyungmin Park 
[m.szyprowski: cleaned up Kconfig, renamed some functions, removed ifdefs]
Signed-off-by: Marek Szyprowski 
CC: Michal Nazarewicz 
Acked-by: Arnd Bergmann 
---
 include/linux/mmzone.h |   41 +++---
 include/linux/page-isolation.h |1 +
 mm/Kconfig |8 +++-
 mm/compaction.c|   10 +
 mm/page_alloc.c|   88 +++-
 5 files changed, 120 insertions(+), 28 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index be1ac8d..74b7f27 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -35,13 +35,35 @@
  */
 #define PAGE_ALLOC_COSTLY_ORDER 3
 
-#define MIGRATE_UNMOVABLE 0
-#define MIGRATE_RECLAIMABLE   1
-#define MIGRATE_MOVABLE   2
-#define MIGRATE_PCPTYPES  3 /* the number of types on the pcp lists */
-#define MIGRATE_RESERVE   3
-#define MIGRATE_ISOLATE   4 /* can't allocate from here */
-#define MIGRATE_TYPES 5
+enum {
+   MIGRATE_UNMOVABLE,
+   MIGRATE_RECLAIMABLE,
+   MIGRATE_MOVABLE,
+   MIGRATE_PCPTYPES,   /* the number of types on the pcp lists */
+   MIGRATE_RESERVE = MIGRATE_PCPTYPES,
+   /*
+* MIGRATE_CMA migration type is designed to mimic the way
+* ZONE_MOVABLE works.  Only movable pages can be allocated
+* from MIGRATE_CMA pageblocks and page allocator never
+* implicitly change migration type of MIGRATE_CMA pageblock.
+*
+* The way to use it is to change migratetype of a range of
+* pageblocks to MIGRATE_CMA which can be done by
+* __free_pageblock_cma() function.  What is important though
+* is that a range of pageblocks must be aligned to
+* MAX_ORDER_NR_PAGES should biggest page be bigger then
+* a single pageblock.
+*/
+   MIGRATE_CMA,
+   MIGRATE_ISOLATE,/* can't allocate from here */
+   MIGRATE_TYPES
+};
+
+#ifdef CONFIG_CMA_MIGRATE_TYPE
+#  define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
+#else
+#  define is_migrate_cma(migratetype) false
+#endif
 
 #define for_each_migratetype_order(order, type) \
for (order = 0; order < MAX_ORDER; order++) \
@@ -54,6 +76,11 @@ static inline int get_pageblock_migratetype(struct page 
*page)
return get_pageblock_flags_group(page, PB_migrate, PB_migrate_end);
 }
 
+static inline bool is_pageblock_cma(struct page *page)
+{
+   return is_migrate_cma(get_pageblock_migratetype(page));
+}
+
 struct free_area {
struct list_headfree_list[MIGRATE_TYPES];
unsigned long   nr_free;
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index c5d1a7c..856d9cf 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -46,4 +46,5 @@ int test_pages_in_a_zone(unsigned long start_pfn, unsigned 
long end_pfn);
 unsigned long scan_lru_pages(unsigned long start, unsigned long end);
 int do_migrate_range(unsigned long start_pfn, unsigned long end_pfn);
 
+extern void init_cma_reserved_pageblock(struct page *page);
 #endif
diff --git a/mm/Kconfig b/mm/Kconfig
index f2f1ca1..dd6e1ea 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -189,7 +189,7 @@ config COMPACTION
 config MIGRATION
bool "Page migration"
def_bool y
-   depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION
+   depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || 
CMA_MIGRATE_TYPE
help
  Allows the migration of the physical location of pages of processes
  while the virtual addresses are not changed. This is useful in
@@ -198,6 +198,12 @@ config MIGRATION
  pages as migration can relocate pages to satisfy a huge page
  allocation instead of reclaiming.
 
+config CMA_MIGRATE_TYPE
+   bool
+   help
+ This enables the use the MIGRATE_CMA migrate type, which lets lets CMA
+ work on almost arbitrary memory range and not only inside 
ZONE_MOVABLE.
+
 config PHYS_ADDR_T_64BIT
def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT
 
diff --git a/mm/compaction.c b/mm/compac

[PATCH 5/9] mm: MIGRATE_CMA isolation functions added

[Marek Szyprowski]

From: Michal Nazarewicz 

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 
Signed-off-by: Kyungmin Park 
Signed-off-by: Marek Szyprowski 
CC: Michal Nazarewicz 
Acked-by: Arnd Bergmann 
---
 include/linux/page-isolation.h |   40 +++-
 mm/page_alloc.c|   19 ---
 mm/page_isolation.c|   15 ---
 3 files changed, 47 insertions(+), 27 deletions(-)

diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 856d9cf..b2a81fd 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -3,39 +3,53 @@
 
 /*
  * Changes migrate type in [start_pfn, end_pfn) to be MIGRATE_ISOLATE.
- * If specified range includes migrate types other than MOVABLE,
+ * If specified range includes migrate types other than MOVABLE or CMA,
  * this will fail with -EBUSY.
  *
  * For isolating all pages in the range finally, the caller have to
  * free all pages in the range. test_page_isolated() can be used for
  * test it.
  */
-extern int
-start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn);
+int __start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
+  unsigned migratetype);
+
+static inline int
+start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn)
+{
+   return __start_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
+}
+
+int __undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
+ unsigned migratetype);
 
 /*
  * Changes MIGRATE_ISOLATE to MIGRATE_MOVABLE.
  * target range is [start_pfn, end_pfn)
  */
-extern int
-undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn);
+static inline int
+undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn)
+{
+   return __undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
+}
 
 /*
- * test all pages in [start_pfn, end_pfn)are isolated or not.
+ * Test all pages in [start_pfn, end_pfn) are isolated or not.
  */
-extern int
-test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn);
+int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn);
 
 /*
- * Internal funcs.Changes pageblock's migrate type.
- * Please use make_pagetype_isolated()/make_pagetype_movable().
+ * Internal functions. Changes pageblock's migrate type.
  */
-extern int set_migratetype_isolate(struct page *page);
-extern void unset_migratetype_isolate(struct page *page);
+int set_migratetype_isolate(struct page *page);
+void __unset_migratetype_isolate(struct page *page, unsigned migratetype);
+static inline void unset_migratetype_isolate(struct page *page)
+{
+   __unset_migratetype_isolate(page, MIGRATE_MOVABLE);
+}
 extern unsigned long alloc_contig_freed_pages(unsigned long start,
  unsigned long end, gfp_t flag);
 extern int alloc_contig_range(unsigned long start, unsigned long end,
- gfp_t flags);
+ gfp_t flags, unsigned migratetype);
 extern void free_contig_pages(struct page *page, int nr_pages);
 
 /*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index aecf32a..e3d756a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5702,7 +5702,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;
@@ -5710,8 +5710,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);
 }
@@ -5816,6 +5816,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
@@ -5827,7 +5831,7 @@ static int __alloc_contig_migrate_range(unsigned long 
start, unsigned long end)
 

[PATCH 6/9] drivers: add Contiguous Memory Allocator

[Marek Szyprowski]

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 
Signed-off-by: Kyungmin Park 
CC: Michal Nazarewicz 
---
 arch/Kconfig   |3 +
 drivers/base/Kconfig   |   77 
 drivers/base/Makefile  |1 +
 drivers/base/dma-contiguous.c  |  396 
 include/linux/dma-contiguous.h |  106 +++
 5 files changed, 583 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 4b0669c..a3b39a2 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 21cf46f..02c0552 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -174,4 +174,81 @@ config SYS_HYPERVISOR
 
 source "drivers/base/regmap/Kconfig"
 
+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 .
+ 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 99a375a..794546f 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

[PATCH 9/9] ARM: S5PV210: example of CMA private area for FIMC device on Goni board

[Marek Szyprowski]

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 
Signed-off-by: Kyungmin Park 
---
 arch/arm/mach-s5pv210/Kconfig |1 +
 arch/arm/mach-s5pv210/mach-goni.c |4 
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s5pv210/Kconfig b/arch/arm/mach-s5pv210/Kconfig
index 69dd87c..697a5be 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 85c2d51..665c4ae 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -848,6 +849,9 @@ static void __init goni_map_io(void)
 static void __init goni_reserve(void)
 {
s5p_mfc_reserve_mem(0x4300, 8 << 20, 0x5100, 8 << 20);
+
+   /* Create private 16MiB contiguous memory area for s5p-fimc.0 device */
+   dma_declare_contiguous(&s5p_device_fimc0.dev, 16*SZ_1M, 0);
 }
 
 static void __init goni_machine_init(void)
-- 
1.7.1.569.g6f426

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/9] mm: move some functions from memory_hotplug.c to page_isolation.c

[Marek Szyprowski]

From: KAMEZAWA Hiroyuki 

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 
[m.nazarewicz: reworded commit message]
Signed-off-by: Michal Nazarewicz 
Signed-off-by: Kyungmin Park 
[m.szyprowski: rebased and updated to Linux v3.0-rc1]
Signed-off-by: Marek Szyprowski 
CC: Michal Nazarewicz 
Acked-by: Arnd Bergmann 
---
 include/linux/page-isolation.h |7 +++
 mm/memory_hotplug.c|  111 --
 mm/page_isolation.c|  114 
 3 files changed, 121 insertions(+), 111 deletions(-)

diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 051c1b1..58cdbac 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -33,5 +33,12 @@ test_pages_isolated(unsigned long start_pfn, unsigned long 
end_pfn);
 extern int set_migratetype_isolate(struct page *page);
 extern void unset_migratetype_isolate(struct page *page);
 
+/*
+ * For migration.
+ */
+
+int test_pages_in_a_zone(unsigned long start_pfn, unsigned long end_pfn);
+unsigned long scan_lru_pages(unsigned long start, unsigned long end);
+int do_migrate_range(unsigned long start_pfn, unsigned long end_pfn);
 
 #endif
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 6e7d8b2..3419dd6 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -707,117 +707,6 @@ int is_mem_section_removable(unsigned long start_pfn, 
unsigned long nr_pages)
 }
 
 /*
- * Confirm all pages in a range [start, end) is belongs to the same zone.
- */
-static int test_pages_in_a_zone(unsigned long start_pfn, unsigned long end_pfn)
-{
-   unsigned long pfn;
-   struct zone *zone = NULL;
-   struct page *page;
-   int i;
-   for (pfn = start_pfn;
-pfn < end_pfn;
-pfn += MAX_ORDER_NR_PAGES) {
-   i = 0;
-   /* This is just a CONFIG_HOLES_IN_ZONE check.*/
-   while ((i < MAX_ORDER_NR_PAGES) && !pfn_valid_within(pfn + i))
-   i++;
-   if (i == MAX_ORDER_NR_PAGES)
-   continue;
-   page = pfn_to_page(pfn + i);
-   if (zone && page_zone(page) != zone)
-   return 0;
-   zone = page_zone(page);
-   }
-   return 1;
-}
-
-/*
- * Scanning pfn is much easier than scanning lru list.
- * Scan pfn from start to end and Find LRU page.
- */
-static unsigned long scan_lru_pages(unsigned long start, unsigned long end)
-{
-   unsigned long pfn;
-   struct page *page;
-   for (pfn = start; pfn < end; pfn++) {
-   if (pfn_valid(pfn)) {
-   page = pfn_to_page(pfn);
-   if (PageLRU(page))
-   return pfn;
-   }
-   }
-   return 0;
-}
-
-static struct page *
-hotremove_migrate_alloc(struct page *page, unsigned long private, int **x)
-{
-   /* This should be improved!! */
-   return alloc_page(GFP_HIGHUSER_MOVABLE);
-}
-
-#define NR_OFFLINE_AT_ONCE_PAGES   (256)
-static int
-do_migrate_range(unsigned long start_pfn, unsigned long end_pfn)
-{
-   unsigned long pfn;
-   struct page *page;
-   int move_pages = NR_OFFLINE_AT_ONCE_PAGES;
-   int not_managed = 0;
-   int ret = 0;
-   LIST_HEAD(source);
-
-   for (pfn = start_pfn; pfn < end_pfn && move_pages > 0; pfn++) {
-   if (!pfn_valid(pfn))
-   continue;
-   page = pfn_to_page(pfn);
-   if (!get_page_unless_zero(page))
-   continue;
-   /*
-* We can skip free pages. And we can only deal with pages on
-* LRU.
-*/
-   ret = isolate_lru_page(page);
-   if (!ret) { /* Success */
-   put_page(page);
-   list_add_tail(&page->lru, &source);
-   move_pages--;
-   inc_zone_page_state(page, NR_ISOLATED_ANON +
-   page_is_file_cache(page));
-
-   } else {
-#ifdef CONFIG_DEBUG_VM
-   printk(KERN_ALERT "removing pfn %lx from LRU failed\n",
-  pfn);
-   dump_page(page);
-#endif
-   put_page(page);
-   /* Because we don't have big zone->lock. we should
-  check this again here. */
-   if (page_count(page)) {
-   not_managed++;
-   ret = -EBUSY;
-

[PATCH 3/9] mm: alloc_contig_range() added

[Marek Szyprowski]

From: Michal Nazarewicz 

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 
Signed-off-by: Kyungmin Park 
[m.szyprowski: renamed some variables for easier code reading]
Signed-off-by: Marek Szyprowski 
CC: Michal Nazarewicz 
Acked-by: Arnd Bergmann 
---
 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 ad6ae3f..35423c2 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5706,6 +5706,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 allocator will never consider using them.
+*
+* This lets us mark the pageb

[PATCH 7/9] ARM: DMA: steal memory for DMA coherent mappings

[Marek Szyprowski]

From: Russell King 

Steal memory from the kernel to provide coherent DMA memory to drivers.
This avoids the problem with multiple mappings with differing attributes
on later CPUs.

Signed-off-by: Russell King 
[m.szyprowski: rebased onto 3.1-rc1]
Signed-off-by: Marek Szyprowski 
---
 arch/arm/include/asm/dma-mapping.h |3 +-
 arch/arm/include/asm/mach/map.h|2 +
 arch/arm/include/asm/memory.h  |7 +
 arch/arm/mm/dma-mapping.c  |  313 +++-
 arch/arm/mm/init.c |1 +
 arch/arm/mm/mm.h   |2 +
 arch/arm/mm/mmu.c  |   24 +++
 7 files changed, 202 insertions(+), 150 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index 7a21d0b..2f50659 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -199,8 +199,7 @@ int dma_mmap_coherent(struct device *, struct 
vm_area_struct *,
 extern void *dma_alloc_writecombine(struct device *, size_t, dma_addr_t *,
gfp_t);
 
-#define dma_free_writecombine(dev,size,cpu_addr,handle) \
-   dma_free_coherent(dev,size,cpu_addr,handle)
+extern void dma_free_writecombine(struct device *, size_t, void *, dma_addr_t);
 
 int dma_mmap_writecombine(struct device *, struct vm_area_struct *,
void *, dma_addr_t, size_t);
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index d2fedb5..3845215 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -29,6 +29,8 @@ struct map_desc {
 #define MT_MEMORY_NONCACHED11
 #define MT_MEMORY_DTCM 12
 #define MT_MEMORY_ITCM 13
+#define MT_DMA_COHERENT14
+#define MT_WC_COHERENT 15
 
 #ifdef CONFIG_MMU
 extern void iotable_init(struct map_desc *, int);
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index b8de516..334b288 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -88,6 +88,13 @@
 #define CONSISTENT_END (0xffe0UL)
 #define CONSISTENT_BASE(CONSISTENT_END - CONSISTENT_DMA_SIZE)
 
+#ifndef CONSISTENT_WC_SIZE
+#define CONSISTENT_WC_SIZE SZ_2M
+#endif
+
+#define CONSISTENT_WC_END  CONSISTENT_BASE
+#define CONSISTENT_WC_BASE (CONSISTENT_WC_END - CONSISTENT_WC_SIZE)
+
 #else /* CONFIG_MMU */
 
 /*
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 0a0a1e7..b643262 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -18,12 +18,14 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "mm.h"
 
@@ -117,93 +119,128 @@ static void __dma_free_buffer(struct page *page, size_t 
size)
 }
 
 #ifdef CONFIG_MMU
-/* Sanity check size */
-#if (CONSISTENT_DMA_SIZE % SZ_2M)
-#error "CONSISTENT_DMA_SIZE must be multiple of 2MiB"
+/* Sanity check sizes */
+#if CONSISTENT_DMA_SIZE % SECTION_SIZE
+#error "CONSISTENT_DMA_SIZE must be a multiple of the section size"
+#endif
+#if CONSISTENT_WC_SIZE % SECTION_SIZE
+#error "CONSISTENT_WC_SIZE must be a multiple of the section size"
+#endif
+#if ((CONSISTENT_DMA_SIZE + CONSISTENT_WC_SIZE) % SZ_2M)
+#error "Sum of CONSISTENT_DMA_SIZE and CONSISTENT_WC_SIZE must be multiple of 
2MiB"
 #endif
 
-#define CONSISTENT_OFFSET(x)   (((unsigned long)(x) - CONSISTENT_BASE) >> 
PAGE_SHIFT)
-#define CONSISTENT_PTE_INDEX(x) (((unsigned long)(x) - CONSISTENT_BASE) >> 
PGDIR_SHIFT)
-#define NUM_CONSISTENT_PTES (CONSISTENT_DMA_SIZE >> PGDIR_SHIFT)
+#include "vmregion.h"
 
-/*
- * These are the page tables (2MB each) covering uncached, DMA consistent 
allocations
- */
-static pte_t *consistent_pte[NUM_CONSISTENT_PTES];
+struct dma_coherent_area {
+   struct arm_vmregion_head vm;
+   unsigned long pfn;
+   unsigned int type;
+   const char *name;
+};
 
-#include "vmregion.h"
+static struct dma_coherent_area coherent_wc_head = {
+   .vm = {
+   .vm_start   = CONSISTENT_WC_BASE,
+   .vm_end = CONSISTENT_WC_END,
+   },
+   .type = MT_WC_COHERENT,
+   .name = "WC ",
+};
 
-static struct arm_vmregion_head consistent_head = {
-   .vm_lock= __SPIN_LOCK_UNLOCKED(&consistent_head.vm_lock),
-   .vm_list= LIST_HEAD_INIT(consistent_head.vm_list),
-   .vm_start   = CONSISTENT_BASE,
-   .vm_end = CONSISTENT_END,
+static struct dma_coherent_area coherent_dma_head = {
+   .vm = {
+   .vm_start   = CONSISTENT_BASE,
+   .vm_end = CONSISTENT_END,
+   },
+   .type = MT_DMA_COHERENT,
+   .name = "DMA coherent ",
 };
 
-#ifdef CONFIG_HUGETLB_PAGE
-#error ARM Coherent DMA allocator does not (yet) support huge TLB
-#endif
+static struct dma_coherent_area *coherent_areas[2] __initdata =
+   { &coherent_wc_head, &coherent_dma_head };
 
-/*
- * Initialise the consistent mem

[PATCH 8/9] ARM: integrate CMA with DMA-mapping subsystem

[Marek Szyprowski]

This patch adds support for CMA to dma-mapping subsystem for ARM
architecture. By default a global CMA area is used, but specific devices
are allowed to have their private memory areas if required (they can be
created with dma_declare_contiguous() function during board
initialization).

Contiguous memory areas reserved for DMA are remapped with 2-level page
tables on boot. Once a buffer is requested, a low memory kernel mapping
is updated to to match requested memory access type.

GFP_ATOMIC allocations are performed from special memory area which is
exclusive from system memory to avoid remapping page attributes what might
be not allowed in atomic context on some systems. If CMA has been disabled
then all DMA allocations are performed from this area.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Kyungmin Park 
---
 arch/arm/Kconfig  |1 +
 arch/arm/include/asm/device.h |3 +
 arch/arm/include/asm/dma-contiguous.h |   33 +++
 arch/arm/include/asm/mach/map.h   |5 +-
 arch/arm/mm/dma-mapping.c |  169 +
 arch/arm/mm/init.c|5 +-
 arch/arm/mm/mm.h  |3 +
 arch/arm/mm/mmu.c |   29 --
 8 files changed, 196 insertions(+), 52 deletions(-)
 create mode 100644 arch/arm/include/asm/dma-contiguous.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c71a8f..20fa729 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -3,6 +3,7 @@ config ARM
default y
select HAVE_AOUT
select HAVE_DMA_API_DEBUG
+   select HAVE_DMA_CONTIGUOUS
select HAVE_IDE
select HAVE_MEMBLOCK
select RTC_LIB
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index 9f390ce..942913e 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -10,6 +10,9 @@ struct dev_archdata {
 #ifdef CONFIG_DMABOUNCE
struct dmabounce_device_info *dmabounce;
 #endif
+#ifdef CONFIG_CMA
+   struct cma *cma_area;
+#endif
 };
 
 struct pdev_archdata {
diff --git a/arch/arm/include/asm/dma-contiguous.h 
b/arch/arm/include/asm/dma-contiguous.h
new file mode 100644
index 000..99bf7c8
--- /dev/null
+++ b/arch/arm/include/asm/dma-contiguous.h
@@ -0,0 +1,33 @@
+#ifndef ASMARM_DMA_CONTIGUOUS_H
+#define ASMARM_DMA_CONTIGUOUS_H
+
+#ifdef __KERNEL__
+
+#include 
+#include 
+
+#ifdef CONFIG_CMA
+
+#define MAX_CMA_AREAS  (8)
+
+void dma_contiguous_early_fixup(phys_addr_t base, unsigned long size);
+
+static inline struct cma *get_dev_cma_area(struct device *dev)
+{
+   if (dev->archdata.cma_area)
+   return dev->archdata.cma_area;
+   return dma_contiguous_default_area;
+}
+
+static inline void set_dev_cma_area(struct device *dev, struct cma *cma)
+{
+   dev->archdata.cma_area = cma;
+}
+
+#else
+
+#define MAX_CMA_AREAS  (0)
+
+#endif
+#endif
+#endif
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index 3845215..5982a83 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -29,8 +29,9 @@ struct map_desc {
 #define MT_MEMORY_NONCACHED11
 #define MT_MEMORY_DTCM 12
 #define MT_MEMORY_ITCM 13
-#define MT_DMA_COHERENT14
-#define MT_WC_COHERENT 15
+#define MT_MEMORY_DMA_READY14
+#define MT_DMA_COHERENT15
+#define MT_WC_COHERENT 16
 
 #ifdef CONFIG_MMU
 extern void iotable_init(struct map_desc *, int);
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index b643262..63175d1 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -26,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mm.h"
 
@@ -56,6 +58,24 @@ static u64 get_coherent_dma_mask(struct device *dev)
return mask;
 }
 
+static struct page *__dma_alloc_system_pages(size_t count, gfp_t gfp,
+unsigned long order)
+{
+   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.
@@ -63,7 +83,8 @@ static u64 get_coherent_dma_mask(struct device *dev)
 static struct page *__dma_alloc_buffer(struct device *dev, size_t size, gfp_t 
gfp)
 {
unsigned long order = get_order(size);
-   struct page *page, *p, *e;
+   size_t count = size >> PAGE_SHIFT;
+   struct page *page;
void *ptr;
u64 mask = get_coherent_dma_mask(dev);
 
@@ -82,16 +103,16 @@ static struct p

[PATCH 2/9] mm: alloc_contig_freed_pages() added

[Marek Szyprowski]

From: KAMEZAWA Hiroyuki 

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 
Signed-off-by: Michal Nazarewicz 
Signed-off-by: Kyungmin Park 
Signed-off-by: Marek Szyprowski 
CC: Michal Nazarewicz 
Acked-by: Arnd Bergmann 
---
 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 6e8ecb6..ad6ae3f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5668,6 +5668,50 @@ out:
spin_unlock_irqrestore(&zone->lock, flags);
 }
 
+unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long end,
+  gfp_t flag)
+{
+   unsigned long pfn = start, count;
+   struct page *page;
+   struct zone *zone;
+   int order;
+
+   VM_BUG_ON(!pfn_valid(start));
+   zone = page_zone(pfn_to_page(start));
+
+   spin_lock_irq(&zone->lock);
+
+   page = pfn_to_page(pfn);
+   for (;;) {
+   VM_BUG_ON(page_count(page) || !PageBuddy(page));
+   list_del(&page->lru);
+   order = page_order(page);
+   zone->free_area[order].nr_free--;
+   rmv_page_order(page);
+   __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << order));
+   pfn  += 1 << order;
+   if (pfn >= end)
+   break;
+   VM_BUG_ON(!pfn_valid(pfn));
+   page += 1 << order;
+   }
+
+   spin_unlock_irq(&zone->lock);
+
+   /* After this, pages in the range can be freed one be one */
+   page = pfn_to_page(start);
+   for (count = pfn - start; count; --count, ++page)
+   prep_new_page(page, 0, flag);
+
+   return pfn;
+}
+
+void free_contig_pages(struct page *page, int nr_pages)
+{
+   for (; nr_pages; --nr_pages, ++page)
+   __free_page(page);
+}
+
 #ifdef CONFIG_MEMORY_HOTREMOVE
 /*
  * All pages in the range must be isolated before calling this.
-- 
1.7.1.569.g6f426

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB mini-summit at LinuxCon Vancouver

[Alan Cox]

> instead of using the V4L2 device node to access the stored images, it 
> probably makes 
> more sense to use a separate device for that, that will handle a separate set 
> of 
> ioctl's, and just use read() to retrieve the image data, after selecting the 
> desired
> image number, via ioctl().

How will you handle the permission model, what about devices where you
need the V4L2 controls to take the picture in the first place ?

It seems it should really be the same device and just a minor tweak to
the API. V4L2 already provides frame reading and mapping functionality
and the media layer provides post processing services which I could
conceive some setups needing to use.

gphoto would just open the v4l device ask for still image stuff and
discover it wasn't available.
--
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 buffer alignment

[Laurent Pinchart]

On Thursday 11 August 2011 23:21:45 Sakari Ailus wrote:
> On Thu, Aug 11, 2011 at 11:57:04AM +0200, Michael Jones wrote:
> > Hi Laurent,
> > 
> > If I understood your discussion with Russell [1] correctly, user pointer
> > buffers are required to be page-aligned because of the IOMMU API, and
> > it's desirable to keep the IOMMU driver that way for other subsystems
> > which may use it. So we're stuck with user buffers needing to be
> > page-aligned.
> 
> My understanding is that this is actually a hardware requirement. You only
> can map pages of 4 kiB (at least).

The IOMMU works on a 4kiB page granularity, but that doesn't require buffers 
to be page-aligned. If the buffer start address isn't aligned on a page 
boundary the IOMMU can map the whole page, and the driver can then just add an 
offset to the virtual address.

> > There's a check in ispvideo.c:isp_video_buffer_prepare() that the buffer
> > address is 32-byte aligned. Isn't this superfluous considering the
> > page-aligned restriction?
> 
> I guess the ISP driver isn't assuming that ispmmu_vmap always give page
> aligned mappings --- or that the page size couls theoretically be smaller.
> The assumptions might not hold in another implementation of the IOMMU API,
> which however will be replaced (hopefully at some point) by the improved
> DMA mapping API.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PATCHES FOR 3.2] gspca for_v3.2

[Jean-Francois Moine]

The following changes since commit
9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e:

  [media] tuner_xc2028: Allow selection of the frequency adjustment code for 
XC3028 (2011-08-06 09:52:47 -0300)

are available in the git repository at:
  git://linuxtv.org/jfrancois/gspca.git for_v3.2

Jean-François Moine (15):
  gspca - ov519: Fix LED inversion of some ov519 webcams
  gspca - sonixj: Fix the darkness of sensor om6802 in 320x240
  gspca - jeilinj: Cleanup code
  gspca - sonixj: Adjust the contrast control
  gspca - sonixj: Increase the exposure for sensor soi768
  gspca - sonixj: Cleanup source and remove useless instructions
  gspca - benq: Remove the useless function sd_isoc_init
  gspca - kinect: Remove the gspca_debug definition
  gspca - ov534_9: Use the new control mechanism
  gspca - ov534_9: New sensor ov9712 and new webcam 05a9:8065
  gspca - main: Fix the isochronous transfer interval
  gspca - main: Better values for V4L2_FMT_FLAG_COMPRESSED
  gspca - main: Use a better altsetting for image transfer
  gspca - main: Handle the xHCI error on usb_set_interface()
  gspca - tp6800: New subdriver for Topro webcams

Luiz Carlos Ramos (1):
  gspca - sonixj: Fix wrong register mask for sensor om6802

 Documentation/video4linux/gspca.txt |3 +
 drivers/media/video/gspca/Kconfig   |9 +
 drivers/media/video/gspca/Makefile  |2 +
 drivers/media/video/gspca/benq.c|   15 -
 drivers/media/video/gspca/gspca.c   |  234 ++-
 drivers/media/video/gspca/jeilinj.c |   10 +-
 drivers/media/video/gspca/kinect.c  |5 -
 drivers/media/video/gspca/ov519.c   |   22 +-
 drivers/media/video/gspca/ov534_9.c |  504 ++--
 drivers/media/video/gspca/sonixj.c  |   29 +-
 drivers/media/video/gspca/tp6800.c  | 4989 +++
 11 files changed, 5430 insertions(+), 392 deletions(-)
 create mode 100644 drivers/media/video/gspca/tp6800.c

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[QUERY] Inclusion of isp.h in board-omap3evm-camera.c

[Ravi, Deepthy]

I need to use some isp structures ( isp_v4l2_subdevs_group, isp_platform_data 
,isp_subdev_i2c_board_info etc.) in  board-omap3evm-camera.c. For that header 
file isp.h has to be included .
Currently I am including it in this way:

#include <../drivers/media/video/omap3isp/isp.h>

 Is there a better way to do this ? The relevant hunk of the patch is shown 
below:

diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c 
b/arch/arm/mach-omap2/board-omap3evm-camera.c
new file mode 100644
index 000..319a6a1
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#include <../drivers/media/video/omap3isp/isp.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: USB mini-summit at LinuxCon Vancouver

[Hans de Goede]

Hi,

On 08/11/2011 04:56 PM, Alan Stern wrote:

On Thu, 11 Aug 2011, Hans de Goede wrote:


The alternative seems to be to define a device-sharing protocol for USB
drivers.  Kernel drivers would implement a new callback (asking them to
give up control of the device), and usbfs would implement new ioctls by
which a program could ask for and relinquish control of a device.  The
amount of rewriting needed would be relatively small.

A few loose ends would remain, such as how to handle suspends, resumes,
resets, and disconnects.  Assuming usbfs is the only driver that will
want to share a device in this way, we could handle them.

Hans, what do you think?



First of all thanks for the constructive input!

When you say: "device-sharing protocol", do you mean 2 drivers been
attached, but only 1 being active. Or just some additional glue to make
hand-over between them work better?


I was thinking that the webcam driver would always be attached, but
from time to time usbfs would ask to use the device.  When the webcam
driver gives away control, it remains bound to the device but does not
send any URBs.  If it needs to send an URB, first it has to ask usbfs
to give control back.



Oh, interesting...




I'm not claiming that this is a better solution than putting everything
in the kernel.  Just that it is a workable alternative which would
involve a lot less coding.


This is definitely an interesting proposal, something to think about ...

I have 2 concerns wrt this approach:

1) It feels less clean then just having a single driver; and
2) I agree it will be less coding, but I doubt it will really be that much
less work. It will likely need less new code (but a lot can be more or
less copy pasted), but it will need changes across a wider array of
subsystems / userspace components, requiring a lot of coordinating,
getting patches merged in different projects, etc. So in the end I
think it too will be quite a bit of work.

I guess that what I'm trying to say here is, that if we are going to
spend a significant amount of time on this, we might just as well
go for the best solution we can come up with even if that is some
more work.

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: USB mini-summit at LinuxCon Vancouver

[Hans de Goede]

Hi,

On 08/11/2011 10:32 PM, Mauro Carvalho Chehab wrote:




instead of using the V4L2 device node to access the stored images, it probably 
makes
more sense to use a separate device for that, that will handle a separate set of
ioctl's, and just use read() to retrieve the image data, after selecting the 
desired
image number, via ioctl().


I don't see a lot of added value in doing things this way. We can simply
have a set of new ioctls on the /dev/video# node for this and a new
V4L2_CAP_STILL_IMAGE to indicate the availability of these ioctls. This will 
keep
the driver a lot simpler then doing 2 separate device nodes for 1 device.

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