Re: [PATCH] v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats

[Sakari Ailus]

Hi Laurent,

Thanks for the patch.

On Fri, Aug 19, 2011 at 08:14:20AM +0200, Laurent Pinchart wrote:
> NV24 and NV42 are planar YCbCr 4:4:4 and YCrCb 4:4:4 formats with a
> luma plane followed by an interleaved chroma plane.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  Documentation/DocBook/media/v4l/pixfmt-nv24.xml |  128 
> +++
>  Documentation/DocBook/media/v4l/pixfmt.xml  |1 +
>  include/linux/videodev2.h   |2 +
>  3 files changed, 131 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24.xml
> 
> This format will be used by an fbdev driver. I'm already posting the patch for
> for review and will send a pull request later.
> 
> diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv24.xml 
> b/Documentation/DocBook/media/v4l/pixfmt-nv24.xml
> new file mode 100644
> index 000..e77301d
> --- /dev/null
> +++ b/Documentation/DocBook/media/v4l/pixfmt-nv24.xml
> @@ -0,0 +1,128 @@
> +
> +  
> + V4L2_PIX_FMT_NV24 ('NV24'), V4L2_PIX_FMT_NV42 
> ('NV42')
> + &manvol;
> +  
> +  
> +  id="V4L2-PIX-FMT-NV24">V4L2_PIX_FMT_NV24
> +  id="V4L2-PIX-FMT-NV42">V4L2_PIX_FMT_NV42
> + Formats with full horizontal and vertical
> +chroma resolutions, also known as YUV 4:4:4. One luminance and one
> +chrominance plane with alternating chroma samples as opposed to
> +V4L2_PIX_FMT_YVU420
> +  
> +  
> + Description
> +
> + These are two-plane versions of the YUV 4:4:4 format.
> +The three components are separated into two sub-images or planes. The
> +Y plane is first. The Y plane has one byte per pixel. For

Are all 8 bits being used per sample, or is there padding?

> +V4L2_PIX_FMT_NV24, a combined CbCr plane
> +immediately follows the Y plane in memory.  The CbCr plane is the same
> +width and height, in pixels, as the Y plane (and of the image).
> +Each line contains one CbCr pair per pixel.

How may bits / bytes per Cb / Cr sample? Perhaps you could mention this once
somewhere if all have the same.

> +V4L2_PIX_FMT_NV42 is the same except the Cb and
> +Cr bytes are swapped, the CrCb plane starts with a Cr byte.
> + If the Y plane has pad bytes after each row, then the
> +CbCr plane has twice as many pad bytes after its rows.

[clip]

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: [PATCHv2] adp1653: make ->power() method optional

[Sylwester Nawrocki]

On 08/19/2011 06:16 PM, Sakari Ailus wrote:
> Sylwester Nawrocki wrote:
>> On 08/18/2011 09:02 PM, Sakari Ailus wrote:
>>>
>>> He-h, I guess you are not going to apply this one.
>>> The patch breaks init logic of the device. If we have no ->power(), we
>>> still need to bring the device to the known state. I have no good idea
>>> how to do this.
>>
>> I don't think it breaks anything actually. Albeit in practice one is 
>> still
>> likely to put the adp1653 reset line to the board since that lowers its 
>> power
>> consumption significantly.
> Yeah, even in practice we might see various ways of a chip connection.
>
>> Instead of being in power-up state after opening the flash subdev, it 
>> will
>> reach this state already when the system is powered up. At subdev open 
>> all
>> the relevant registers are written to anyway, so I don't see an issue 
>> here.
> You mean at first writing to the V4L2 value, do you? Because ->open()
> uses set_power() which will be skipped in case of no ->power method
> defined.
>
>> I think either this one, or one should check in probe() that the power()
>> callback is non-NULL.
>> The board code is going away in the near future so this callback will
>> disappear eventually anyway.
> So, it's up to you to include or not my last patch.
>
>> The gpio code in the board file should likely
>> be moved to the driver itself.
> The line could be different, the hw could be used in environment w/o
> gpio, but with (for example) external gate, and so on. I think current
> generic driver is pretty okay.

 Would it make sense to use the regulator API in place of the platform_data
 callback? If there is only one GPIO then it's easy to create a 'fixed 
 voltage
 regulator' for this.
>>>
>>> I don't know the regulator framework very well, but do you mean creating a 
>>> new
>>> regulator which just controls a gpio? It would be preferable that this 
>>> wouldn't
>>> create a new driver nor add any board core.
>>
>> I'm afraid your requirements are too demanding :)
>> Yes, I meant creating a new regulator. In case the ADP1635 voltage regulator
>> is inhibited through a GPIO at a host processor such regulator would in fact
>> be only flipping a GPIO (and its driver would request the GPIO and set it 
>> into
>> a default inactive state during its initialization). But the LDO for ADP1635
> 
> Thinking about this again, I think we'd need a regulator and reset gpio.
> The reset line probably can't be really modelled as a power supply, as
> the voltage provided to the chip is different from the reset line. Both
> may exist on some boards.
> 
> The regulator might be a dummy one, too, as well as the reset line. 

Yes, this would make the driver most complete I guess.
And the gpio API seems a natural choice for the reset signal. If there is
some 'non-standard' circuit to drive the ADP1635 pin possibly it can be
handled by some existing or dedicated gpio driver.


--
Regards,
Sylwester
--
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: [PATCHv2] adp1653: make ->power() method optional

[Sakari Ailus]

On Fri, Aug 19, 2011 at 07:16:59PM +0300, Sakari Ailus wrote:
[clip]
> > I'm afraid your requirements are too demanding :)
> > Yes, I meant creating a new regulator. In case the ADP1635 voltage regulator
> > is inhibited through a GPIO at a host processor such regulator would in fact
> > be only flipping a GPIO (and its driver would request the GPIO and set it 
> > into
> > a default inactive state during its initialization). But the LDO for ADP1635
> 
> Thinking about this again, I think we'd need a regulator and reset gpio.

And as noted below, the regulator isn't needed at this point.

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

[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 19 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: image capturing on i.mx27 with gstreamer

[Fabio Estevam]

On Fri, Aug 19, 2011 at 4:05 AM, Jan Pohanka  wrote:
> Hi all,
>
> I'm playing with i.mx27 processor by Freescale, namely with ipcam reference
> design. There is unfortunately no support available for this hw this time so
> I have adapted a kernel from Pengutronix Oselas distribution (available here
> ftp://ftp.phytec.de/pub/Products/phyCORE-iMX27/Linux/PD11.1.0/).

Whick kernel version is this? I am also interested in getting VPU
support in the mainline kernel?

Are you working on that?

Regards,

Fabio Estevam
--
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: image capturing on i.mx27 with gstreamer

[Fabio Estevam]

Jan,

On Fri, Aug 19, 2011 at 4:05 AM, Jan Pohanka  wrote:
...
> However, there is also an issue with resolution. This works up to 640x480.
> For example for 800x600 i'm getting this error message
> WARNING: erroneous pipeline: could not link ffmpegcsp0 to mfwgstvpu_enc0

MX27 can decode/encode up to full D1 (720x576 or 720x480) resolution.

Regards,

Fabio Estevam
--
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] vp7045: fix buffer setup

[Florian Mickler]

On Wed, 10 Aug 2011 12:05:20 +0200
Florian Mickler  wrote:

> dvb_usb_device_init calls the frontend_attach method of this driver which
> uses vp7045_usb_ob. In order to have a buffer ready in vp7045_usb_op, it has 
> to
> be allocated before that happens.
> 
> Luckily we can use the whole private data as the buffer as it gets separately
> allocated on the heap via kzalloc in dvb_usb_device_init and is thus apt for
> use via usb_control_msg.
> 
> This fixes a
>   BUG: unable to handle kernel paging request at 1e78
> 
> reported by Tino Keitel and diagnosed by Dan Carpenter.
> 
> References: https://bugzilla.kernel.org/show_bug.cgi?id=40062
> Cc: v3.0.y 
> Tested-by: Tino Keitel 
> Signed-off-by: Florian Mickler 

...ping...
--
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: [PATCHv2] adp1653: make ->power() method optional

[Sakari Ailus]

Sylwester Nawrocki wrote:
> On 08/18/2011 09:02 PM, Sakari Ailus wrote:
>>
>> He-h, I guess you are not going to apply this one.
>> The patch breaks init logic of the device. If we have no ->power(), we
>> still need to bring the device to the known state. I have no good idea
>> how to do this.
>
> I don't think it breaks anything actually. Albeit in practice one is still
> likely to put the adp1653 reset line to the board since that lowers its 
> power
> consumption significantly.
 Yeah, even in practice we might see various ways of a chip connection.

> Instead of being in power-up state after opening the flash subdev, it will
> reach this state already when the system is powered up. At subdev open all
> the relevant registers are written to anyway, so I don't see an issue 
> here.
 You mean at first writing to the V4L2 value, do you? Because ->open()
 uses set_power() which will be skipped in case of no ->power method
 defined.

> I think either this one, or one should check in probe() that the power()
> callback is non-NULL.
> The board code is going away in the near future so this callback will
> disappear eventually anyway.
 So, it's up to you to include or not my last patch.

> The gpio code in the board file should likely
> be moved to the driver itself.
 The line could be different, the hw could be used in environment w/o
 gpio, but with (for example) external gate, and so on. I think current
 generic driver is pretty okay.
>>>
>>> Would it make sense to use the regulator API in place of the platform_data
>>> callback? If there is only one GPIO then it's easy to create a 'fixed 
>>> voltage
>>> regulator' for this.
>>
>> I don't know the regulator framework very well, but do you mean creating a 
>> new
>> regulator which just controls a gpio? It would be preferable that this 
>> wouldn't
>> create a new driver nor add any board core.
> 
> I'm afraid your requirements are too demanding :)
> Yes, I meant creating a new regulator. In case the ADP1635 voltage regulator
> is inhibited through a GPIO at a host processor such regulator would in fact
> be only flipping a GPIO (and its driver would request the GPIO and set it into
> a default inactive state during its initialization). But the LDO for ADP1635

Thinking about this again, I think we'd need a regulator and reset gpio.
The reset line probably can't be really modelled as a power supply, as
the voltage provided to the chip is different from the reset line. Both
may exist on some boards.

The regulator might be a dummy one, too, as well as the reset line.

> could be also a part of larger PMIC device, which are often configured through
> I2C and have their generic drivers (in drivers/regulator). So the regulator 
> API
> in some extent abstracts the power supply details. There is a common API at 
> the
> client driver side regardless of the details how the power is actually 
> enabled/
> disabled.
> 
> I've seen some patches for the device tree bindings for the regulator API
> but I guess this is not in the mainline yet.
> 
> Currently the 'fixed voltage regulator' is instantiated by creating a 
> platform 
> device, with an appropriate 'id', in the board code. And you have to 
> create... 
> a platform data for it :) The driver is common for all such devices
> (drivers/regulator/fixed.c). 

I'll take a look at that.

>>> Does the 'platform_data->power' callback control power supply on pin 14 
>>> (VDD)
>>> or does it do something else?
>>
>> No. The chip is always powered on the N900 but pulling down (or up, I don't 
>> remember)
>> its reset pin puts the chip to reset and causes the current draw to reach 
>> almost zero.
>> I think it's in the class of some or few tens of µA. Someone still might 
>> implement
> 
> According to the datasheet it's even less, below 1 uA :)

Right. That indeed was probably the reason there was no need for a
controllable regulator.

> "Shutdown Current (EN = GND, TJ = −40°C to +85°C) = 0.1μA (Typ.), 1μA (Max)"
> 
> So the reset (EN) pin is basically a GPIO, but it could be as well some signal
> provided by a glue FPGA, driven by a memory mapped register(s).
> Then the callback is most flexible, but it's a little bit ugly at the same 
> time:)
> If I were you I, would probably originally put a GPIO number in platform_data,
> instead of a function callback. But that depends on priorities.
> 
>> a board containing the adp1653 which would require enabling a regulator for 
>> it.
>  
> Indeed, I guess there is no point in adding support for the power supply 
> control
> over the regulator API now. When someone needs it on some other board, it can
> be added in the driver then.

I fully agree.

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

Re: Afatech AF9013

[Josu Lazkano]

2011/8/17 Antti Palosaari :
> On 08/17/2011 10:36 AM, Josu Lazkano wrote:
>> I don't know how wide is the stream, but it could be a USB wide
>> limitation. My board is a little ION based and I have some USB
>> devices:
>> $ lsusb
>> Bus 001 Device 002: ID 1b80:e399 Afatech
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> I don't think so. Total under 50Mbit/sec stream should not be too much
> for one USB2.0 root hub.
>
> Which is chipset used ION (it is southbridge which contains usually USB
> ports)?
>
>> The problematic twin device is the "Afatech" one, there is an DVB-S2
>> USB tuner, a bluetooth dongle, a IR receiver and a wireless
>> mouse/keybord receiver.
>>
>> Now I am at work, I will try to disconnect all devices and try with
>> just the DVB-T device.
>>
>> I use to try with MythTV if it works or not. Is there any other tool
>> to test and debug more deep about USB or DVB wide?
>
> You can look stream sizes using dvbtraffic tool. It is last line of
> output which shows total stream size.
>
> tzap can be used to tune channel. But it you can use some other app like
> MythTV and then run dvbtraffic same time.
>
>> I apreciate your help. Thanks and best regards.
>
> regards
> Antti
>
> --
> http://palosaari.fi/
>

Thanks Antti, I don't know the chipset model, my board is this one:
ZOTAC ION ITX-G Synergy Edition:
http://www.zotac.com/pdbrochures/mb/ION-ITX-G-E-Synergy-Edition_v1.3.pdf

On the BIOS there is something about southbridge, but now I am
connected remotely so I can not access to the BIOS, I must change
something on the BIOS?

I make this steps to record a TV channel:

1. Scan with w_scan with both adapters:
w_scan -a 2 -ft -c ES >> canales1_TDT.conf
w_scan -a 3 -ft -c ES >> canales2_TDT.conf

Here is the output and the channel files:
http://dl.dropbox.com/u/1541853/w_scan1
http://dl.dropbox.com/u/1541853/canales1_TDT.conf

http://dl.dropbox.com/u/1541853/w_scan2
http://dl.dropbox.com/u/1541853/canales2_TDT.conf

I think there is something wrong, because there must be more channels
as TVE 1, La 2...

How can I tune the correct channel?

I try this:

$ tzap -a 2 -c canales1_TDT.conf -r "TELECINCO"
using '/dev/dvb/adapter2/frontend0' and '/dev/dvb/adapter2/demux0'
reading channels from file 'canales1_TDT.conf'
ERROR: could not find channel 'TELECINCO' in channel list

I want to try to tune the channel and record it with gnutv and see if
there is any problem. Thanks for the dvbtraffic tool.

Thanks for all your help, best regards.

-- 
Josu Lazkano
--
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/8] 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;
-

[PATCHv15 0/8] Contiguous Memory Allocator

[Marek Szyprowski]

Hello again,

This is yet another round of Contiguous Memory Allocator patches. Now I
implemented all the ideas that has been discussed during Linaro Sprint
meeting.

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

For coherent, nommu, ARMv4 and ARMv5 systems the current DMA-mapping
implementation has been kept.

For ARMv6+ systems, CMA has been enabled and a special pool of coherent
memory for atomic allocations has been created. The size of this pool
defaults to CONSISTEN_DMA_SIZE/8, but can be changed with coherent_pool
kernel parameter (if really required).

All atomic allocations are served from this pool. I've did a little
simplification here, because there is no separate pool for writecombine
memory - such requests are also served from coherent pool. I don't think
that such simplification is a problem here - I found no driver that use
dma_alloc_writecombine with GFP_ATOMIC flags.

All non-atomic allocation are served from CMA area. Kernel mapping is
updated to reflect required memory attributes changes. This is possible
because during early boot, all CMA area are remapped with 4KiB pages in
kernel low-memory.

This version have been tested on Samsung S5PC110 based Goni machine and
Exynos4 UniversalC210 board with various V4L2 multimedia drivers.

Coherent atomic allocations has been tested by manually enabling the dma
bounce for the s3c-sdhci device.

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

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.

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

v15:
1. fixed calculation of the total memory after activating CMA area (was
   broken from v12)

2. more code cleanup in drivers/base/dma-contiguous.c

3. added address limit for default CMA area

4. rewrote ARM DMA integration:
- removed "ARM: DMA: steal memory for DMA coherent mappings" patch
- kept current DMA mapping implementation for coherent, nommu and
  ARMv4/ARMv5 systems
- enabled CMA for all ARMv6+ systems
- added separate, small pool for coherent atomic allocations, defaults
  to CONSISTENT_DMA_SIZE/8, but can be changed with kernel parameter
  coherent_pool=[size]

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 allocator:
   - alignment argument was not passed correctly
   - range for dma_release_from_contiguous was not checked correctly

2. Added support for architecture specfic dma_contiguous_early_fixup()
   function

3. CMA and DMA-mapping integration for ARM arc

[PATCH 4/8] 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 8/8] 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/mach-goni.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s5pv210/mach-goni.c 
b/arch/arm/mach-s5pv210/mach-goni.c
index 14578f5..f766c45 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 
@@ -857,6 +858,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 7/8] 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 pool which is created
early during boot. This way remapping page attributes is not needed on
allocation time.

CMA has been enabled unconditionally for ARMv6+ systems.

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

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ebc5d9..2327fdd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -3,6 +3,8 @@ config ARM
default y
select HAVE_AOUT
select HAVE_DMA_API_DEBUG
+   select HAVE_DMA_CONTIGUOUS if (CPU_V6 || CPU_V6K || CPU_V7)
+   select CMA if (CPU_V6 || CPU_V6K || CPU_V7)
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..6be12ba
--- /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 && dev->archdata.cma_area)
+   return dev->archdata.cma_area;
+   return dma_contiguous_default_area;
+}
+
+static inline void set_dev_cma_area(struct device *dev, struct cma *cma)
+{
+   dev->archdata.cma_area = cma;
+}
+
+#else
+
+#define MAX_CMA_AREAS  (0)
+
+#endif
+#endif
+#endif
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index d2fedb5..05343de 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -29,6 +29,7 @@ struct map_desc {
 #define MT_MEMORY_NONCACHED11
 #define MT_MEMORY_DTCM 12
 #define MT_MEMORY_ITCM 13
+#define MT_MEMORY_DMA_READY14
 
 #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 0a0a1e7..a0006c9 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -17,13 +17,17 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "mm.h"
 
@@ -54,6 +58,19 @@ static u64 get_coherent_dma_mask(struct device *dev)
return mask;
 }
 
+static void __dma_clear_buffer(struct page *page, size_t size)
+{
+   void *ptr;
+   /*
+* Ensure that the allocated pages are zeroed, and that any data
+* lurking in the kernel direct-mapped region is invalidated.
+*/
+   ptr = page_address(page);
+   memset(ptr, 0, size);
+   dmac_flush_range(ptr, ptr + size);
+   outer_flush_range(__pa(ptr), __pa(ptr) + size);
+}
+
 /*
  * Allocate a DMA buffer for 'dev' of size 'size' using the
  * specified gfp mask.  Note that 'size' must be page aligned.
@@ -62,23 +79,6 @@ static struct page *__dma_alloc_buffer(struct device *dev, 
size_t size, gfp_t gf
 {
unsigned long order = get_order(size);
struct page *page, *p, *e;
-   void *ptr;
-   u64 mask = get_coherent_dma_mask(dev);
-
-#ifdef CONFIG_DMA_API_DEBUG
-   u64 limit = (mask + 1) & ~mask;
-   if (limit && size >= limit) {
-   dev_warn(dev, "coherent allocation too big (requested %#x mask 
%#llx)\n",
-   size, mask);
-   return NULL;
-   }
-#endif
-
-   if (!mask)
-   return NULL;
-
-   if (mask < 0xUL

[PATCH 6/8] 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   |   79 
 drivers/base/Makefile  |1 +
 drivers/base/dma-contiguous.c  |  386 
 include/linux/dma-contiguous.h |  102 +++
 5 files changed, 571 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..bffe7fb 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -174,4 +174,83 @@ 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)"
+   depends on !CMA_SIZE_SEL_PERCENTAGE
+   default 16
+   help
+ Defines the size (in MiB) of the default memory area for Contiguous
+ Memory Allocator.
+
+config CMA_SIZE_PERCENTAGE
+   int "Percentage of total memory"
+   depends on !CMA_SIZE_SEL_ABSOLUTE
+   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

[PATCH 3/8] 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 5/8] 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 c9dfed0..46e78d4 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 2/8] 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

[PATCHv2] ISP:BUILD:FIX: Move media_entity_init() and

[Deepthy Ravi]

From: Vaibhav Hiremath 

Fix the build break caused when CONFIG_MEDIA_CONTROLLER
option is disabled and if any sensor driver has to be used
between MC and non MC framework compatible devices.

For example,if tvp514x video decoder driver migrated to
MC framework is being built without CONFIG_MEDIA_CONTROLLER
option enabled, the following error messages will result.
drivers/built-in.o: In function `tvp514x_remove':
drivers/media/video/tvp514x.c:1285: undefined reference to
`media_entity_cleanup'
drivers/built-in.o: In function `tvp514x_probe':
drivers/media/video/tvp514x.c:1237: undefined reference to
`media_entity_init'

The file containing definitions of media_entity_init and
media_entity_cleanup functions will not be built if that
config option is disabled. And this is corrected by
defining two dummy functions.

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Deepthy Ravi 
---
 include/media/media-entity.h |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index cd8bca6..c90916e 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -121,9 +121,18 @@ struct media_entity_graph {
int top;
 };
 
+#ifdef CONFIG_MEDIA_CONTROLLER
 int media_entity_init(struct media_entity *entity, u16 num_pads,
struct media_pad *pads, u16 extra_links);
 void media_entity_cleanup(struct media_entity *entity);
+#else
+static inline int media_entity_init(struct media_entity *entity, u16 num_pads,
+   struct media_pad *pads, u16 extra_links)
+{
+   return 0;
+}
+static inline void media_entity_cleanup(struct media_entity *entity) {}
+#endif
 
 int media_entity_create_link(struct media_entity *source, u16 source_pad,
struct media_entity *sink, u16 sink_pad, u32 flags);
-- 
1.7.0.4

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

RE: RFC: Negotiating frame buffer size between sensor subdevs and bridge devices

[Sylwester Nawrocki]

Hi Sakari,

On 08/18/2011 10:32 PM, Sakari Ailus wrote:
 In order to let the host drivers query or configure subdevs with 
 required frame buffer size one of the following changes could be done
at V4L2 API:

 1. Add a 'sizeimage' field in struct v4l2_mbus_framefmt and make subdev
drivers optionally set/adjust it when setting or getting the format
with
set_fmt/get_fmt pad level ops (and s/g_mbus_fmt ?)
There could be two situations:
- effective required frame buffer size is specified by the sensor
and the
  host driver relies on that value when allocating a buffer;
- the host driver forces some arbitrary buffer size and the sensor
performs
  any required action to limit transmitted amount of data to that
amount
  of data;
 Both cases could be covered similarly as it's done with VIDIOC_S_FMT.

 Introducing 'sizeimage' field is making the media bus format struct 
 looking more similar to struct v4l2_pix_format and not quite in 
 line with media bus format meaning, i.e. describing data on a physical
bus,
 not in the memory.
 The other option I can think of is to create separate subdev video ops.
 2. Add new s/g_sizeimage subdev video operations

 The best would be to make this an optional callback, not sure if it 
 makes sense though. It has an advantage of not polluting the user 
 space API. Although 'sizeimage' in user space might be useful for 
 some purposes I rather tried to focus on "in-kernel" calls.
>>>
>>> I prefer this second approach over the first once since the maxiumu 
>>> size of the image in bytes really isn't a property of the bus.
>>
>> After thinking some more about it I came to similar conclusion. I 
>> intended to find some better name for s/g_sizeimage callbacks and 
>> post relevant patch for consideration.
>> Although I haven't yet found some time to carry on with this.
> 
> That sounds a possible solution to me as well. The upside would be 
> that v4l2_mbus_framefmt would be left to describe relatively low level 
> bus and format properties.
> 
> That said, I'm not anymore quite certain it should not be part of that 
> structure. Is the size always the same, or is this maximum?

The output size is not known in advance, due to the nature of compressed
formats, as you may know. So it's actually the maximum data size that
we need to fix up along the pipeline.

> 
>>> How about a regular V4L2 control? You would also have minimum and 
>>> maximum values, I'm not quite sure whather this is a plus, though. 
>>> :)
>>
>> My intention was to have these calls used only internally in the 
>> kernel and do not allow the userspace to mess with it. All in all, if 
>> anything had interfered and the host driver would have allocated too 
>> small buffer the system would crash miserably due to buffer overrun.
> 
> The user space wouldn't be allowed to do anything like that. E.g. the 
> control would become read-only during streaming and the bridge driver 
> would need to check its value against the sizes of the video buffers. 
> Although this might not be relevant at all if there are no direct ways 
> to affect the maximum size of the resulting image.

Ok, makes sense. AFAIK in most cases you will not be able to force an
exact size of the resulting image. The application may apply some high
threshold on the sensor (firmware), which it could then have considered
when applying other controls.
Nevertheless we need to have a consistent 'sizeimage' along the pipeline.

That said, if we used a control for that, it would be mostly GET on the
transmitter (sensor) and SET on the receiver AFAIU.

But I would like more to see it as a part of struct v4l2_mbus_framefmt.

> 
>> The final buffer size for a JFIF/EXIF file will depend on other 
>> factors, like main image resolution, JPEG compression ratio, the 
>> thumbnail inclusion and its format/resolution, etc. I imagine we 
>> should be rather creating controls for those parameters.
>>
>> Also the driver would most likely have to validate the buffer size 
>> during STREAMON call.
>>
>>>
>>> Btw. how does v4l2_mbus_framefmt suit for compressed formats in general?
>>>
>>
>> Well, there is really nothing particularly addressing the compressed 
>> formats in that struct. But we need to use it as the compressed data 
>> flows through the media bus in same way as the raw data.
>> It's rather hard to define the pixel codes using existing convention 
>> as there is no simple relationship between the pixel data and what is 
>> transferred on the bus.
>> Yet I haven't run into issues other than no means to specify the 
>> whole image size.
> 
> I've never dealt with compressed image formats in drivers in general 
> but I'd suppose it might require taking this into account in the CSI-2 
> or the parallel bus receivers.

I guess it matters when the MIPI-CSI receiver driver independently allocates
the buffers to store the received data there.
And

Re: [beagleboard] Re: [PATCH v7 1/2] Add driver for Aptina (Micron) mt9p031 sensor.

[Laurent Pinchart]

Hi,

On Friday 19 August 2011 04:13:23 CJ wrote:
> Hi,
> 
> I am trying to get the mt9p031 working from nand with a ubifs file
> system and I am having a few problems.
> 
> /dev/media0 is not present unless I run:
> #mknod /dev/media0 c 251 0
> #chown root:video /dev/media0
> 
> #media-ctl -p
> Enumerating entities
> media_open: Unable to enumerate entities for device /dev/media0
> (Inappropriate ioctl for device)
> 
> With the same rig/files it works fine running from EXT4 on an SD card.
> Any idea why this does not work on nand with ubifs?

Is the OMAP3 ISP driver loaded ? Has it probed the device successfully ? Check 
the kernel log for OMAP3 ISP-related messages.

-- 
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/RFC v2 3/3] fbdev: sh_mobile_lcdc: Support FOURCC-based format API

[Laurent Pinchart]

Signed-off-by: Laurent Pinchart 
---
 arch/arm/mach-shmobile/board-ag5evm.c   |2 +-
 arch/arm/mach-shmobile/board-ap4evb.c   |4 +-
 arch/arm/mach-shmobile/board-mackerel.c |4 +-
 drivers/video/sh_mobile_lcdcfb.c|  342 ---
 include/video/sh_mobile_lcdc.h  |4 +-
 5 files changed, 230 insertions(+), 126 deletions(-)

diff --git a/arch/arm/mach-shmobile/board-ag5evm.c 
b/arch/arm/mach-shmobile/board-ag5evm.c
index ce5c251..e6dabaa 100644
--- a/arch/arm/mach-shmobile/board-ag5evm.c
+++ b/arch/arm/mach-shmobile/board-ag5evm.c
@@ -270,7 +270,7 @@ static struct sh_mobile_lcdc_info lcdc0_info = {
.flags = LCDC_FLAGS_DWPOL,
.lcd_size_cfg.width = 44,
.lcd_size_cfg.height = 79,
-   .bpp = 16,
+   .fourcc = V4L2_PIX_FMT_RGB565,
.lcd_cfg = lcdc0_modes,
.num_cfg = ARRAY_SIZE(lcdc0_modes),
.board_cfg = {
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c 
b/arch/arm/mach-shmobile/board-ap4evb.c
index 9e0856b..6f5db07 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -489,7 +489,7 @@ static struct sh_mobile_lcdc_info lcdc_info = {
.meram_dev = &meram_info,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
-   .bpp = 16,
+   .fourcc = V4L2_PIX_FMT_RGB565,
.lcd_cfg = ap4evb_lcdc_modes,
.num_cfg = ARRAY_SIZE(ap4evb_lcdc_modes),
.meram_cfg = &lcd_meram_cfg,
@@ -783,7 +783,7 @@ static struct sh_mobile_lcdc_info sh_mobile_lcdc1_info = {
.meram_dev = &meram_info,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
-   .bpp = 16,
+   .fourcc = V4L2_PIX_FMT_RGB565,
.interface_type = RGB24,
.clock_divider = 1,
.flags = LCDC_FLAGS_DWPOL,
diff --git a/arch/arm/mach-shmobile/board-mackerel.c 
b/arch/arm/mach-shmobile/board-mackerel.c
index 6e3c2df..6e36349 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -387,7 +387,7 @@ static struct sh_mobile_lcdc_info lcdc_info = {
.clock_source = LCDC_CLK_BUS,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
-   .bpp = 16,
+   .fourcc = V4L2_PIX_FMT_RGB565,
.lcd_cfg = mackerel_lcdc_modes,
.num_cfg = ARRAY_SIZE(mackerel_lcdc_modes),
.interface_type = RGB24,
@@ -450,7 +450,7 @@ static struct sh_mobile_lcdc_info hdmi_lcdc_info = {
.clock_source = LCDC_CLK_EXTERNAL,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
-   .bpp = 16,
+   .fourcc = V4L2_PIX_FMT_RGB565,
.interface_type = RGB24,
.clock_divider = 1,
.flags = LCDC_FLAGS_DWPOL,
diff --git a/drivers/video/sh_mobile_lcdcfb.c b/drivers/video/sh_mobile_lcdcfb.c
index 97ab8ba..ea3f619 100644
--- a/drivers/video/sh_mobile_lcdcfb.c
+++ b/drivers/video/sh_mobile_lcdcfb.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -101,7 +102,7 @@ struct sh_mobile_lcdc_priv {
struct sh_mobile_lcdc_chan ch[2];
struct notifier_block notifier;
int started;
-   int forced_bpp; /* 2 channel LCDC must share bpp setting */
+   int forced_fourcc; /* 2 channel LCDC must share fourcc setting */
struct sh_mobile_meram_info *meram_dev;
 };
 
@@ -214,6 +215,42 @@ struct sh_mobile_lcdc_sys_bus_ops 
sh_mobile_lcdc_sys_bus_ops = {
lcdc_sys_read_data,
 };
 
+static int sh_mobile_format_fourcc(const struct fb_var_screeninfo *var)
+{
+   if (var->format.fourcc > 1)
+   return var->format.fourcc;
+
+   switch (var->bits_per_pixel) {
+   case 16:
+   return V4L2_PIX_FMT_RGB565;
+   case 24:
+   return V4L2_PIX_FMT_BGR24;
+   case 32:
+   return V4L2_PIX_FMT_BGR32;
+   default:
+   return 0;
+   }
+}
+
+static bool sh_mobile_format_yuv(const struct fb_var_screeninfo *var)
+{
+   if (var->format.fourcc <= 1)
+   return false;
+
+   switch (var->format.fourcc) {
+   case V4L2_PIX_FMT_NV12:
+   case V4L2_PIX_FMT_NV21:
+   case V4L2_PIX_FMT_NV16:
+   case V4L2_PIX_FMT_NV61:
+   case V4L2_PIX_FMT_NV24:
+   case V4L2_PIX_FMT_NV42:
+   return true;
+
+   default:
+   return false;
+   }
+}
+
 static void sh_mobile_lcdc_clk_on(struct sh_mobile_lcdc_priv *priv)
 {
if (atomic_inc_and_test(&priv->hw_usecnt)) {
@@ -434,7 +471,6 @@ static void __sh_mobile_lcdc_start(struct 
sh_mobile_lcdc_priv *priv)
 {
struct sh_mobile_lcdc_chan *ch;
unsigned long tmp;
-   int bpp = 0;
int k, m;
 
/* Enable LCDC channels. Read data from external memory, avoid using the
@@ 

[PATCH/RFC v2 2/3] v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats

[Laurent Pinchart]

NV24 and NV42 are planar YCbCr 4:4:4 and YCrCb 4:4:4 formats with a
luma plane followed by an interleaved chroma plane.

Signed-off-by: Laurent Pinchart 
---
 Documentation/DocBook/media/v4l/pixfmt-nv24.xml |  128 +++
 Documentation/DocBook/media/v4l/pixfmt.xml  |1 +
 include/linux/videodev2.h   |2 +
 3 files changed, 131 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24.xml

diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv24.xml 
b/Documentation/DocBook/media/v4l/pixfmt-nv24.xml
new file mode 100644
index 000..e77301d
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv24.xml
@@ -0,0 +1,128 @@
+
+  
+   V4L2_PIX_FMT_NV24 ('NV24'), V4L2_PIX_FMT_NV42 
('NV42')
+   &manvol;
+  
+  
+   V4L2_PIX_FMT_NV24
+   V4L2_PIX_FMT_NV42
+   Formats with full horizontal and vertical
+chroma resolutions, also known as YUV 4:4:4. One luminance and one
+chrominance plane with alternating chroma samples as opposed to
+V4L2_PIX_FMT_YVU420
+  
+  
+   Description
+
+   These are two-plane versions of the YUV 4:4:4 format.
+The three components are separated into two sub-images or planes. The
+Y plane is first. The Y plane has one byte per pixel. For
+V4L2_PIX_FMT_NV24, a combined CbCr plane
+immediately follows the Y plane in memory.  The CbCr plane is the same
+width and height, in pixels, as the Y plane (and of the image).
+Each line contains one CbCr pair per pixel.
+V4L2_PIX_FMT_NV42 is the same except the Cb and
+Cr bytes are swapped, the CrCb plane starts with a Cr byte.
+
+   If the Y plane has pad bytes after each row, then the
+CbCr plane has twice as many pad bytes after its rows.
+
+   
+ V4L2_PIX_FMT_NV24 4 × 4
+pixel image
+
+ 
+   Byte Order.
+   Each cell is one byte.
+   
+   
+ 
+ 
+   
+ start + 0:
+ Y'00
+ Y'01
+ Y'02
+ Y'03
+   
+   
+ start + 4:
+ Y'10
+ Y'11
+ Y'12
+ Y'13
+   
+   
+ start + 8:
+ Y'20
+ Y'21
+ Y'22
+ Y'23
+   
+   
+ start + 12:
+ Y'30
+ Y'31
+ Y'32
+ Y'33
+   
+   
+ start + 16:
+ Cb00
+ Cr00
+ Cb01
+ Cr01
+ Cb02
+ Cr02
+ Cb03
+ Cr03
+   
+   
+ start + 24:
+ Cb10
+ Cr10
+ Cb11
+ Cr11
+ Cb12
+ Cr12
+ Cb13
+ Cr13
+   
+   
+ start + 32:
+ Cb20
+ Cr20
+ Cb21
+ Cr21
+ Cb22
+ Cr22
+ Cb23
+ Cr23
+   
+   
+ start + 40:
+ Cb30
+ Cr30
+ Cb31
+ Cr31
+ Cb32
+ Cr32
+ Cb33
+ Cr33
+   
+ 
+   
+   
+ 
+ 
+   
+  
+
+
+  
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
b/Documentation/DocBook/media/v4l/pixfmt.xml
index 2ff6b77..aef4615 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -714,6 +714,7 @@ information.
 &sub-nv12m;
 &sub-nv12mt;
 &sub-nv16;
+&sub-nv24;
 &sub-m420;
   
 
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index fca24cc..8225163 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -343,6 +343,8 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V', '2', '1') /* 12  Y/CrCb 
4:2:0  */
 #define V4L2_PIX_FMT_NV16v4l2_fourcc('N', 'V', '1', '6') /* 16  Y/CbCr 
4:2:2  */
 #define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 
4:2:2  */
+#define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 
4:4:4  */
+#define V4L2_PIX_FMT_NV42v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 
4:4:4  */
 
 /* two non contiguous pl

[PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API

[Laurent Pinchart]

This API will be used to support YUV frame buffer formats in a standard
way.

Last but not least, create a much needed fbdev API documentation and
document the format setting APIs.

Signed-off-by: Laurent Pinchart 
---
 Documentation/fb/api.txt |  299 ++
 include/linux/fb.h   |   27 -
 2 files changed, 320 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/fb/api.txt

diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt
new file mode 100644
index 000..6808492
--- /dev/null
+++ b/Documentation/fb/api.txt
@@ -0,0 +1,299 @@
+   The Frame Buffer Device API
+   ---
+
+Last revised: June 21, 2011
+
+
+0. Introduction
+---
+
+This document describes the frame buffer API used by applications to interact
+with frame buffer devices. In-kernel APIs between device drivers and the frame
+buffer core are not described.
+
+Due to a lack of documentation in the original frame buffer API, drivers
+behaviours differ in subtle (and not so subtle) ways. This document describes
+the recommended API implementation, but applications should be prepared to
+deal with different behaviours.
+
+
+1. Capabilities
+---
+
+Device and driver capabilities are reported in the fixed screen information
+capabilities field.
+
+struct fb_fix_screeninfo {
+   ...
+   __u16 capabilities; /* see FB_CAP_* */
+   ...
+};
+
+Application should use those capabilities to find out what features they can
+expect from the device and driver.
+
+- FB_CAP_FOURCC
+
+The driver supports the four character code (FOURCC) based format setting API.
+When supported, formats are configured using a FOURCC instead of manually
+specifying color components layout.
+
+
+2. Types and visuals
+
+
+Pixels are stored in memory in hardware-dependent formats. Applications need
+to be aware of the pixel storage format in order to write image data to the
+frame buffer memory in the format expected by the hardware.
+
+Formats are described by frame buffer types and visuals. Some visuals require
+additional information, which are stored in the variable screen information
+bits_per_pixel, grayscale, fourcc, red, green, blue and transp fields.
+
+The following types and visuals are supported.
+
+- FB_TYPE_PACKED_PIXELS
+
+Color components (usually RGB or YUV) are packed together into macropixels
+that are stored in a single plane. The exact color components layout is
+described in a visual-dependent way.
+
+Frame buffer visuals that don't use multiple color components per pixel
+(such as monochrome and pseudo-color visuals) are reported as packed frame
+buffer types, even though they don't stricly speaking pack color components
+into macropixels.
+
+- FB_TYPE_PLANES
+
+Color components are stored in separate planes. Planes are located
+contiguously in memory.
+
+- FB_VISUAL_MONO01
+
+Pixels are black or white and stored on one bit. A bit set to 1 represents a
+black pixel and a bit set to 0 a white pixel. Pixels are packed together in
+bytes with 8 pixels per byte.
+
+FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_MONO10
+
+Pixels are black or white and stored on one bit. A bit set to 1 represents a
+white pixel and a bit set to 0 a black pixel. Pixels are packed together in
+bytes with 8 pixels per byte.
+
+FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_TRUECOLOR
+
+Pixels are broken into red, green and blue components, and each component
+indexes a read-only lookup table for the corresponding value. Lookup tables
+are device-dependent, and provide linear or non-linear ramps.
+
+Each component is stored in memory according to the variable screen
+information red, green, blue and transp fields.
+
+- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR
+
+Pixel values are encoded as indices into a colormap that stores red, green and
+blue components. The colormap is read-only for FB_VISUAL_STATIC_PSEUDOCOLOR
+and read-write for FB_VISUAL_PSEUDOCOLOR.
+
+Each pixel value is stored in the number of bits reported by the variable
+screen information bits_per_pixel field. Pixels are contiguous in memory.
+
+FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR are used with
+FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_DIRECTCOLOR
+
+Pixels are broken into red, green and blue components, and each component
+indexes a programmable lookup table for the corresponding value.
+
+Each component is stored in memory according to the variable screen
+information red, green, blue and transp fields.
+
+- FB_VISUAL_FOURCC
+
+Pixels are stored in memory as described by the format FOURCC identifier
+stored in the variable screen information fourcc field.
+
+
+3. Screen information
+-
+
+Screen information are queried by applications using the FBIOGET_FSCREENINFO
+and FBIOGET_VSCREENINFO ioctls. Those ioct

[PATCH/RFC v2 0/3] fbdev: Add FOURCC-based format configuration API

[Laurent Pinchart]

Hi everybody,

Here's the second version of the fbdev FOURCC-based format configuration API.

Compared to the previous version, I've removed the FB_VMODE_FOURCC bit (FOURCC
mode is now selected by a grayscale value > 1), reorganized the union in the
fb_var_screeninfo structure, and added a colorspace field used for YUV modes.

This patch set also contains an implementation of the FOURCC-based format API
for the sh_mobile_lcdc driver, based on top of the latest patches I've sent to
the list. You can find a consolidated version that includes this patch set at
http://git.linuxtv.org/pinchartl/fbdev.git/shortlog/refs/heads/fbdev-yuv.
YUV support when MERAM is enabled is currently broken, I'm working on fixing
that.

I've updated the fbdev-test tool to add FOURCC support. The code is available
in the fbdev-test yuv branch at
http://git.ideasonboard.org/?p=fbdev-test.git;a=shortlog;h=refs/heads/yuv.

Laurent Pinchart (3):
  fbdev: Add FOURCC-based format configuration API
  v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats
  fbdev: sh_mobile_lcdc: Support FOURCC-based format API

 Documentation/DocBook/media/v4l/pixfmt-nv24.xml |  128 +
 Documentation/DocBook/media/v4l/pixfmt.xml  |1 +
 Documentation/fb/api.txt|  299 
 arch/arm/mach-shmobile/board-ag5evm.c   |2 +-
 arch/arm/mach-shmobile/board-ap4evb.c   |4 +-
 arch/arm/mach-shmobile/board-mackerel.c |4 +-
 drivers/video/sh_mobile_lcdcfb.c|  342 +++
 include/linux/fb.h  |   27 ++-
 include/linux/videodev2.h   |2 +
 include/video/sh_mobile_lcdc.h  |4 +-
 10 files changed, 681 insertions(+), 132 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24.xml
 create mode 100644 Documentation/fb/api.txt

-- 
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: Image and webcam freeze on Ubuntu with Logitech QuickCam Communicate STX

[Jean-Francois Moine]

On Thu, 18 Aug 2011 12:31:51 +0200
Damien Cassou  wrote:

> my Logitech QuickCam Communicate STX works perfectly well for a few
> minutes when I use it. However, after that the image is frozen and I
> can't make it work again until I reboot the system (before rebooting,
> the webcam has a blue color indicating it is "working" even though I
> can't get anything displayed). What can I do? A way to avoid rebooting
> would be a very welcomed workaround.
> 
> Details below:
> 
> - because of this bug I compiled the driver manually to see if the bug
> was fixed. I compiled it from gspca-2.13.6.tar.gz
> 
> - ubuntu 11.04, all updates installed
> 
> - dmesg displays a lot of the following line:
> gspca: ISOC data error: [0] len=0, status=-18
> 
> - lsusb returns:
> Bus 003 Device 002: ID 046d:08ad Logitech, Inc. QuickCam Communicate STX

Hi Damien,

I need more information.

May you send me the kernel messages starting from the webcam connection
up to the first ISOC data errors? Please, use the gspca 2.13.6 and set
the debug level to 0x0f:

echo 0x0f > /sys/module/gspca_main/parameters/debug

(then, unplug / replug the webcam)

Thanks.

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

image capturing on i.mx27 with gstreamer

[Jan Pohanka]

Hi all,

I'm playing with i.mx27 processor by Freescale, namely with ipcam  
reference design. There is unfortunately no support available for this hw  
this time so I have adapted a kernel from Pengutronix Oselas distribution  
(available here  
ftp://ftp.phytec.de/pub/Products/phyCORE-iMX27/Linux/PD11.1.0/).


There is mt9d131 CMOS imager from Aptina on the board with 1600x1200  
resolution. As there was none driver, I adapted the one for mt9m111 one  
for my chip. Unfortunately I'm able to get image with any resolution only  
up to 800x600, with higher resolution resulting image is fragmented - it  
looks like the both synchronization (vertical, horizontal) fails. I was  
not able to solve it yet, I'm only sure that I wrote correct values to  
WINDOW_WIDHT and WINDOW_HEIGHT registers, also no skipping is set up.

I use following command to capture single image:
gst-launch \
  v4l2src num-buffers=1 device=/dev/video1 ! \
  video/x-raw-yuv,format=\(fourcc\)UYVY,width=$WIDTH,height=$HEIGHT ! \
  ffmpegcolorspace ! \
  video/x-raw-yuv,width=$WIDTH,height=$HEIGHT ! \
  jpegenc ! \
  filesink location=col_image.jpg

My second problem concerns streaming via udp. I'm able to stream mpeg4  
using hardware VPU on the chip using following gstreamer command

gst-launch -v \
  v4l2src device=/dev/video1 ! \
  video/x-raw-yuv,format=\(fourcc\)UYVY,width=$WIDTH,height=$HEIGHT,  
framerate='(fraction)'10/1 ! \

  ffmpegcolorspace ! \
  mfw_vpuencoder codec-type=std_mpeg4 bitrate=16383 gopsize=20  
profile=true ! \

  rtpmp4vpay send-config=TRUE  ! \
  udpsink host=192.168.10.1 port=5434

However, there is also an issue with resolution. This works up to 640x480.  
For example for 800x600 i'm getting this error message

WARNING: erroneous pipeline: could not link ffmpegcsp0 to mfwgstvpu_enc0

Could please anyone give me an advice how to solve described problems?

with best regards
Jan


--
Tato zpráva byla vytvořena převratným poštovním klientem Opery:  
http://www.opera.com/mail/

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