date:20110331

Re: [RFC] V4L2 API for flash devices

2011-03-31 Thread Sakari Ailus

Laurent Pinchart wrote:
 Hi David,

Salut,

 On Wednesday 30 March 2011 16:57:30 David Cohen wrote:
 On Wed, Mar 30, 2011 at 5:18 PM, Sakari Ailus wrote:
 On Wednesday 30 March 2011 14:44:25 Sakari Ailus wrote:
...
 But as I commented in the other e-mail, there likely isn't a need to be
 able to control this very precisely. The user just shuts down the flash
 whenever (s)he no longer needs it rather than knows beforehand how long
 it needs to stay on.

 What about hardware that needs to be pre-programmed with a duration ?

 Same control?

 I wonder if I could say we agree to have one timeout control which is
 used to control the hardware timeout directly, or to implement a timeout
 in software? :-)

 Correct if I'm wrong, but I guess we might be talking about 2 kind of
 timeouts:
 - One for the duration itself
 - Another one to act like watchdog in addition to the hw timeout
 
 Do we need a control for that, or should it just be a fixed value that comes 
 from platform data ?

I think it's good to set the hardware timeout as small as possible. This
makes the timeout behaviour more deterministic. I'm not sure if the
information _needs_ to be delivered to user space though.

On the other hand, if we now use the same control for both software and
hardware timeout we can't add a new one without changing the meaning for
the old one.

My proposal: let's postpone this and decide when we need to. Only
hardware timeouts are implemented for now. When someone wants a software
timeout then figure out what to do. We'd have exactly the same options
then: the same control or a new control.

 IMO they should be different controls. We could even specify on the
 control name when it's a watchdog case to make it more clear.

 I have to say I'm not entirely sure the duration control is required.
 The timeout could be writable for software strobe in the case drivers
 do not implement software timeout. The granularity isn't _that_ much
 anyway. Also, a timeout fault should be produced whenever the
 duration would expire.

 Perhaps it would be best to just leave that out for now.

  V4L2_CID_FLASH_LED_MODE (menu; LED)

 enum v4l2_flash_led_mode {

  V4L2_FLASH_LED_MODE_FLASH = 1,
  V4L2_FLASH_LED_MODE_TORCH,

 torch mode can also be used for video, should we rename TORCH to
 something more generic ? Maybe a manual mode ?

 The controllers recognise a torch mode and I think it describes the
 functionality quite well. Some appear to make a difference between
 torch and video light --- but I can't imagine a purpose in which this
 could be useful.

 Torch mode is indeed a common name, but it sounds a bit specific to me.

 Torch suggests it can be used over extended periods of time, unlike
 manual which doesn't really say much. I'd keep it torch since what it
 suggests is that it can stay on for long. No references outside the
 flash controller itself.

 I'd keep with torch also as it seems to be more clear.
 
 OK, I'll give up then :-)

Torch, then. :-)

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] V4L2 API for flash devices

2011-03-31 Thread Sakari Ailus

Laurent Pinchart wrote:
 On Wednesday 30 March 2011 13:05:54 Sakari Ailus wrote:
 Laurent Pinchart wrote:
 Hi Sakari,

 Hi Laurent,

 Thanks for the comments!

 On Monday 28 March 2011 14:55:40 Sakari Ailus wrote:

 [snip]

V4L2_CID_FLASH_STROBE_MODE (menu; LED)

 Use hardware or software strobe. If hardware strobe is selected, the
 flash controller is a slave in the system where the sensor produces the
 strobe signal to the flash.

 In this case the flash controller setup is limited to programming strobe
 timeout and power (LED flash) and the sensor controls the timing and
 length of the strobe.

 enum v4l2_flash_strobe_mode {

V4L2_FLASH_STROBE_MODE_SOFTWARE,
V4L2_FLASH_STROBE_MODE_EXT_STROBE,

 };

 [snip]

V4L2_CID_FLASH_LED_MODE (menu; LED)

 enum v4l2_flash_led_mode {

V4L2_FLASH_LED_MODE_FLASH = 1,
V4L2_FLASH_LED_MODE_TORCH,

 };

 Thinking about this some more, shouldn't we combine the two controls ?
 They are basically used to configure how the flash LED is controlled:
 manually (torch mode), automatically by the flash controller (software
 strobe mode) or automatically by an external component (external strobe
 mode).

 That's a good question.

 The adp1653 supports also additional control (not implemented in the
 driver, though) that affect hardware strobe length. Based on register
 setting, the led will be on after strobe either until the timeout
 expires, or until the strobe signal is high.

 Should this be also part of the same control, or a different one?
 
 That can be controlled by a duration control. If the duration is 0, the flash 
 is lit for the duration of the external strobe, otherwise it's lit for the 
 programmed duration.

Sounds good to me.

 Even without this, we'd have:

 V4L2_FLASH_MODE_OFF
 V4L2_FLASH_MODE_TORCH
 V4L2_FLASH_MODE_SOFTWARE_STROBE
 V4L2_FLASH_MODE_EXTERNAL_STROBE

 Additionally, this might be

 V4L2_FLASH_MODE_EXTERNAL_STROBE_EDGE

 It's true that these are mutually exclusive.

 I think this is about whether we want to specify the operation of the
 flash explicitly here or allow extending the interface later on when new
 hardware is available by adding new controls. There are upsides and
 downsides in each approach.

 There could be additional differentiating factors to the functionalty
 later on, like the torch/video light differentiation that some hardware
 does --- who knows based on what?

 I perhaps wouldn't combine the controls. What do you think?
 
 I'm not sure yet :-)

I have a vague feeling that as we don't know about the future hardware
I'd prefer to keep this as extensible as possible, meaning that I'd
rather add new controls than define menu controls with use case specific
items in them. This would translate to two controls: flash mode (none,
torch, flash) and strobe mode (software, external).

What do the others think on this?

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] V4L2 API for flash devices

2011-03-31 Thread Sakari Ailus

Kim HeungJun wrote:
 Hi Sakari,

Hi,

 2011. 3. 30., 오후 8:37, Sakari Ailus 작성:
 
 Kim, HeungJun wrote:
 Hi Sakari,

 Hi HeungJun,

 2011-03-29 오후 11:41, Sakari Ailus 쓴 글:
 Kim, HeungJun wrote:
 [snip]
 I think it's not different method to turn on/off, whatever the mode name 
 is.
 But, the mode name DEDICATED is look more reasonable, because the reason 
 which is devided FLASH and TORCH in the mode, is why only power up the 
 led,
 not sensor.

 Sensor? Is the flash part of the sensor module for you?
 Yes. The flash is a part of the sensor module(our case like M-5MOLS).
 Precisely, the sensor internal core's gpio pin is connected with
 external Flash LED, and the control master is the sensor internal core.
 For turnning on the Flash LED, we should use I2C register access.
 So, I think it's exactly matches with hardware strobe as you metioned.

 Ok, I think I'm lost now. :-)

 What signals are sent from sensor to flash in both torch and flash cases?
 I guess the signal probably is just continuous repetition High/Low like PWM 
 signal,
 which is generated by the core of sensor module.  Although I don't check what 
 signal
 it is, it's very possible. Because it's the only way to be able to control 
 intensity of  Flash.
 
 So, I think the torch and flash case is the same way or signal in this case.

So... to summarise, the sensor determines the flash power by providing
the flash controller a pwm signal both in flash and torch modes, if I
understand correctly?

This sounds like a quite low level control. Is the flash controller
still an I2C device?

...

 So, I suggesst that, if we can not give to users(of course, this user
 want to use only flash function, not the camera) proper method usage
 (openning the videonode for using flash), let's express that the camera
 flash is used in the DEDICATED MODE now, as the enumeration name DEDICATED.

 No. The video nodes should not be involved since they are related to the
 bridge (ISP) which is not needed to use the flash. Assuming that this is
 the situation.

 This is how the use case should go:

 1. open subdev node, e.g. /dev/v4l-subdev0, which is the flash
 (flash controller powered on)
 2. VIDIOC_S_CTRL: V4L2_CID_FLASH_LED_MODE, V4L2_FLASH_LED_MODE_TORCH
 (flash is on now)
 2. VIDIOC_S_CTRL: V4L2_CID_FLASH_LED_MODE, V4L2_FLASH_LED_MODE_NONE
 (flash is off now)
 3. close the file handle
 (flash controller powered off)
 Probably you mean media controller framework is based on. I get it. :)
 

 But, I think it might be not a big issue. So, any others don't comment at 
 this,
 it's ok for me to pass this naming issue.

 I can see this API is very cool for camera man just like me.

 Thanks!

 plus: actually I have the one of N-series, N810. So, the omap3isp is 
 available to
 activate this device, not even it's cpu is omap3? Just question.

 The N810 has OMAP 2420 which has a completely different camera bridge,
 and there's no flash. The drivers for the camera in N810 are omap24xxcam
 and tcm825x. The drivers are functional in mainline but the platform
 data is missing, as well as the CBUS driver. This work is queued but
 unknown when there's time for this.
 Thanks for plus reply. I've tested tony's patch for booting the ubuntu long 
 time ago,
 but I'm sure this gadget is good device. 

I've never tried it out with Ubuntu. Probably that 128 MiB of RAM is
slightly small for Ubuntu. ;-)

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [RFC/PATCH v7 3/5] MFC: Add MFC 5.1 V4L2 driver

2011-03-31 Thread Kamil Debski

 From: Jaeryul Oh [mailto:jaeryul...@samsung.com]
 Hi, Kamil

Hi Peter,
 
 I found some mal-functional points.

I have commented below.

 
  -Original Message-
  From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
  ow...@vger.kernel.org] On Behalf Of Kamil Debski
  Sent: Friday, March 04, 2011 8:26 PM
  To: linux-media@vger.kernel.org; linux-samsung-...@vger.kernel.org
  Cc: m.szyprow...@samsung.com; kyungmin.p...@samsung.com;
  k.deb...@samsung.com; jaeryul...@samsung.com; kgene@samsung.com
  Subject: [RFC/PATCH v7 3/5] MFC: Add MFC 5.1 V4L2 driver
 
  Multi Format Codec 5.1 is capable of handling a range of video codecs
  and this driver provides V4L2 interface for video decoding.
 
  Signed-off-by: Kamil Debski k.deb...@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
  ---
   drivers/media/video/Kconfig  |8 +
   drivers/media/video/Makefile |1 +
   drivers/media/video/s5p-mfc/Makefile |3 +
   drivers/media/video/s5p-mfc/regs-mfc5.h  |  346 
   drivers/media/video/s5p-mfc/s5p_mfc.c| 2253
  ++
   drivers/media/video/s5p-mfc/s5p_mfc_common.h |  240 +++
   drivers/media/video/s5p-mfc/s5p_mfc_ctrls.h  |  182 +++
   drivers/media/video/s5p-mfc/s5p_mfc_debug.h  |   47 +
   drivers/media/video/s5p-mfc/s5p_mfc_intr.c   |   92 ++
   drivers/media/video/s5p-mfc/s5p_mfc_intr.h   |   26 +
   drivers/media/video/s5p-mfc/s5p_mfc_memory.h |   43 +
   drivers/media/video/s5p-mfc/s5p_mfc_opr.c|  913 +++
   drivers/media/video/s5p-mfc/s5p_mfc_opr.h|  142 ++
   13 files changed, 4296 insertions(+), 0 deletions(-)
   create mode 100644 drivers/media/video/s5p-mfc/Makefile
   create mode 100644 drivers/media/video/s5p-mfc/regs-mfc5.h
   create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc.c
   create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_common.h
   create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_ctrls.h
   create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_debug.h
   create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_intr.c
   create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_intr.h
   create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_memory.h
   create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr.c
   create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr.h
 
  diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
  index 12fb325..0bdc64d 100644
  --- a/drivers/media/video/Kconfig
  +++ b/drivers/media/video/Kconfig
  @@ -1025,4 +1025,12 @@ config  VIDEO_SAMSUNG_S5P_FIMC
This is a v4l2 driver for the S5P camera interface
(video postprocessor)
 
  +config VIDEO_SAMSUNG_S5P_MFC
  +   tristate Samsung S5P MFC 5.1 Video Codec
  +   depends on VIDEO_V4L2
  +   select VIDEOBUF2_S5P_IOMMU
  +   default n
  +   help
  +   MFC 5.1 driver for V4L2.
  +
   endif # V4L_MEM2MEM_DRIVERS
  diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
  index fd9488d..4b09ddb 100644
  --- a/drivers/media/video/Makefile
  +++ b/drivers/media/video/Makefile
  @@ -164,6 +164,7 @@ obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2)  +=
  sh_mobile_csi2.o
   obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)  += sh_mobile_ceu_camera.o
   obj-$(CONFIG_VIDEO_OMAP1)  += omap1_camera.o
   obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC)   += s5p-fimc/
  +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
 
   obj-$(CONFIG_ARCH_DAVINCI) += davinci/
 
  diff --git a/drivers/media/video/s5p-mfc/Makefile
  b/drivers/media/video/s5p-mfc/Makefile
  new file mode 100644
  index 000..69b6294
  --- /dev/null
  +++ b/drivers/media/video/s5p-mfc/Makefile
  @@ -0,0 +1,3 @@
  +obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC) := s5p-mfc.o
  +s5p-mfc-y := s5p_mfc.o s5p_mfc_intr.o  s5p_mfc_opr.o
  +
  diff --git a/drivers/media/video/s5p-mfc/regs-mfc5.h
  b/drivers/media/video/s5p-mfc/regs-mfc5.h
  new file mode 100644
  index 000..eeb6e2e
  --- /dev/null
  +++ b/drivers/media/video/s5p-mfc/regs-mfc5.h
  @@ -0,0 +1,346 @@
 
 snipping
 
  +}
  +
  +static inline void s5p_mfc_run_res_change(struct s5p_mfc_ctx *ctx)
  +{
  +   struct s5p_mfc_dev *dev = ctx-dev;
  +
  +   s5p_mfc_set_dec_stream_buffer(ctx, 0, 0, 0);
  +   dev-curr_ctx = ctx-num;
  +   s5p_mfc_clean_ctx_int_flags(ctx);
  +   s5p_mfc_decode_one_frame(ctx, MFC_DEC_RES_CHANGE);
  +}
  +
  +static inline void s5p_mfc_run_dec_last_frames(struct s5p_mfc_ctx *ctx)
  +{
  +   struct s5p_mfc_dev *dev = ctx-dev;
  +
  +   s5p_mfc_set_dec_stream_buffer(ctx, 0, 0, 0);
  +   dev-curr_ctx = ctx-num;
  +   s5p_mfc_clean_ctx_int_flags(ctx);
  +   s5p_mfc_decode_one_frame(ctx, MFC_DEC_LAST_FRAME);
  +}
  +
 
 You used '0' as a second param.(= buf_addr) in
 s5p_mfc_set_dec_stream_buffer(ctx, 0, 0, 0)
 This must be a problem, 'cause OFFSETA(buf_addr) is calculated wrongly.
 And I propose that
 why don't you try to check addr condition(necessary cond. of MFC, it should
 be located at
 rear region

RE: v4l: Buffer pools

2011-03-31 Thread Marek Szyprowski

Hello,

On Tuesday, March 29, 2011 4:02 PM Willy POISSON wrote:

   Following to the Warsaw mini-summit action point, I would like to open 
 the thread to gather
 buffer pool  memory manager requirements.
 The list of requirement for buffer pool may contain:
 - Support physically contiguous and virtual memory
 - Support IPC, import/export handles (between 
 processes/drivers/userland/etc)
 - Security(access rights in order to secure no one unauthorized is 
 allowed to access buffers)
 - Cache flush management (by using setdomain and optimize when flushing 
 is needed)
 - Pin/unpin in order to get the actual address to be able to do 
 defragmentation
 - Support pinning in user land in order to allow defragmentation while 
 buffer is mmapped but not
 pined.
 - Both a user API and a Kernel API is needed for this module. (Kernel 
 drivers needs to be able to
 resolve buffer handles as well from the memory manager module, and pin/unpin)
 - be able to support any platform specific allocator (Separate memory 
 allocation from management
 as allocator is platform dependant)
 - Support multiple region domain (Allow to allocate from several memory 
 domain ex: DDR1, DDR2,
 Embedded SRAM to make for ex bandwidth load balancing ...)

The above list looks fine.

Memory/buffer pools are a large topic that covers at least 3 subsystems:
1. user space api
2. in-kernel buffer manager
3. in-kernel memory allocator 

Most of the requirements above list can be assigned to one of these subsystems.

If would like to focus first on the user space API. This API should provide a 
generic way to allocate
memory buffers. User space should not be aware of the allocator specific 
parameters of the buffer.
User space should not decide whether a physically contiguous buffer is needed 
or not. The only
information that user space should provide is a set or list of devices that the 
application want use
with the allocated buffer. User space might also provide some additional hints 
about the buffers - like
the preferred memory region.

Our chip S5PC110 and EXYNOS4 are very similar in terms of integrated multimedia 
modules, however there
is one important difference. The latter has IOMMU module, so multimedia blocks 
doesn't require physically
contiguous buffers. In userspace however we would like to support both with the 
same API.

We have also a very specific requirement for buffers for video codes (chroma 
buffers and luma buffers
must be allocated from different memory banks). The memory bank should be 
specified at allocation time.

The only problem is to define a way the user space API will be able to provide 
a list of devices that 
must be able to operate with the allocated buffer. Without some kind of 
enumeration of all entities 
that work with buffer pool it might be a bit hard. I would like to avoid the 
need of hardcoding device 
names in the user space applications.

The in-kernel memory allocator is mainly targeted to systems that require 
physically contiguous buffers.
Currently CMA framework perfectly fits here. A new version will be posted very 
soon.

 Another idea, but not so linked to memory management (more usage of buffers), 
 would be to have a
 common data container (structure to access data) shared by several media 
 (Imaging, video/still codecs,
 graphics, Display...) to ease usage of the data. This container could  embed 
 data type (video frames,
 Access Unit) , frames format, pixel format, width, height, pixel aspect 
 ratio, region of interest, CTS
 (composition time stamp),  ColorSpace, transparency (opaque, alpha, color 
 key...), pointer on buffer(s)
 handle)...

I'm not sure if such idea can be ever implemented in the mainline kernel... 
IHMO it is too complicated.

Best regards
--
Marek Szyprowski
Samsung Poland RD Center


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

Re: [w_scan PATCH] Add Brazil support on w_scan

2011-03-31 Thread Mauro Carvalho Chehab

Em 29-03-2011 20:21, Mauro Carvalho Chehab escreveu:
 Em 29-03-2011 17:11, handygewinnsp...@gmx.de escreveu:
 So I changed it now to scan any srate for 6MHz networks, but skip over those 
 which are unsupported by bandwidth limitation.
...
 Anyway, I'll test the today's version and reply if I detect any troubles on 
 it.

Test results:

$ ./w_scan -c BR -fc 
Took about 30 mins for scan. As the board I'm using doesn't support QAM_AUTO
for DVB-C, it seek only QAM_64. No channels detected.

$ ./w_scan -c BR -fc -Q1
Took about 30 mins for scan. Channels were properly detected.

$ ./w_scan -c BR -fc -Q1 -S13
Took about 10 mins for scan. Channels were properly detected.

IMHO, the default, if QAM_AUTO is not supported and -Q parameter is not used,
sould be to test for the most common QAM types, and not for just 64-QAM.
A search at dvb-apps transponders files (upstream + Net Digital Brazil DVB-C 
freq)
show:

$ grep -l QAM64 /home/v4l/dvb-apps/util/scan/dvb-c/*|wc
 31  311087
$ grep -l QAM256 /home/v4l/dvb-apps/util/scan/dvb-c/*|wc
 18  18 859
$ grep -l QAM128 /home/v4l/dvb-apps/util/scan/dvb-c/*|wc
  8   8 249
$ grep QAM /home/v4l/dvb-apps/util/scan/dvb-c/*|cut -d' ' -f 5|sort|uniq 
-c|sort -n -r
372 QAM64
179 QAM256
 72 QAM128

So, starting with QAM64 makes sense, but it makes sense also to test for
QAM256 and QAM128, if QAM_AUTO is not supported.

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

Re: Technisat Cablestar HD2 not automatically detected by kernel 2.6.33?

2011-03-31 Thread Bjørn Mork

Jos Hoekstra joshoeks...@gmx.net writes:

 I got this card and it doesn't seem to be detected by Ubuntu 10.4.2
 with kernel 2.6.35(-25-generic #44~lucid1-Ubuntu SMP Tue Jan 25
 19:17:25 UTC 2011 x86_64 GNU/Linux)

 The wiki seems to indicate that this card is supported as of kernel
 2.6.33, however it doesn't show up as a dvb-adapter.
[..]
 After rebooting it however seems I need to manually modprobe mantis
 and restart the backend to have mythtv work with this card. Is there a
 way to make these modules load automatically after a reboot?

This is fixed by the following trivial patch, which was finally included
in kernel 2.6.38:


commit 116d588ea21cf0278a4de1e3272e9c3220a647e7
Author: Manu Abraham abraham.m...@gmail.com
Date:   Thu Feb 11 04:11:05 2010 -0300

[media] Mantis, hopper: use MODULE_DEVICE_TABLE

use the macro to make modules auto-loadable

Thanks to Ozan Çağlayan o...@pardus.org.tr for pointing it out

Signed-off-by: Manu Abraham m...@linuxtv.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/dvb/mantis/hopper_cards.c 
b/drivers/media/dvb/mantis/hopper_cards.c
index 09e9fc7..70e73af 100644
--- a/drivers/media/dvb/mantis/hopper_cards.c
+++ b/drivers/media/dvb/mantis/hopper_cards.c
@@ -251,6 +251,8 @@ static struct pci_device_id hopper_pci_table[] = {
{ }
 };
 
+MODULE_DEVICE_TABLE(pci, hopper_pci_table);
+
 static struct pci_driver hopper_pci_driver = {
.name   = DRIVER_NAME,
.id_table   = hopper_pci_table,
diff --git a/drivers/media/dvb/mantis/mantis_cards.c 
b/drivers/media/dvb/mantis/mantis_cards.c
index cf4b39f..40da225 100644
--- a/drivers/media/dvb/mantis/mantis_cards.c
+++ b/drivers/media/dvb/mantis/mantis_cards.c
@@ -281,6 +281,8 @@ static struct pci_device_id mantis_pci_table[] = {
{ }
 };
 
+MODULE_DEVICE_TABLE(pci, mantis_pci_table);
+
 static struct pci_driver mantis_pci_driver = {
.name   = DRIVER_NAME,
.id_table   = mantis_pci_table,



The best way to work around the problem until you upgrade your kernel to
2.6.38 or newer, is probably just adding mantis to /etc/modules.


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

[PATCH 04/12] mm: alloc_contig_freed_pages() added

2011-03-31 Thread Marek Szyprowski

From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com

This commit introduces alloc_contig_freed_pages() function
which allocates (ie. removes from buddy system) free pages
in range.  Caller has to guarantee that all pages in range
are in buddy system.

Along with this function, a free_contig_pages() function is
provided which frees all (or a subset of) pages allocated
with alloc_contig_free_pages().

Michal Nazarewicz has modified the function to make it easier
to allocate not MAX_ORDER_NR_PAGES aligned pages by making it
return pfn of one-past-the-last allocated page.

Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
 include/linux/page-isolation.h |3 ++
 mm/page_alloc.c|   44 
 2 files changed, 47 insertions(+), 0 deletions(-)

diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 58cdbac..f1417ed 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -32,6 +32,9 @@ test_pages_isolated(unsigned long start_pfn, unsigned long 
end_pfn);
  */
 extern int set_migratetype_isolate(struct page *page);
 extern void unset_migratetype_isolate(struct page *page);
+extern unsigned long alloc_contig_freed_pages(unsigned long start,
+ unsigned long end, gfp_t flag);
+extern void free_contig_pages(struct page *page, int nr_pages);
 
 /*
  * For migration.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d6e7ba7..11f8bcb 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5545,6 +5545,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

[PATCH 06/12] mm: cma: Contiguous Memory Allocator added

2011-03-31 Thread Marek Szyprowski

From: Michal Nazarewicz m.nazarew...@samsung.com

The Contiguous Memory Allocator is a set of functions that lets
one initialise a region of memory which then can be used to perform
allocations of contiguous memory chunks from.

CMA allows for creation of private and non-private contexts.
The former is reserved for CMA and no other kernel subsystem can
use it.  The latter allows for movable pages to be allocated within
CMA's managed memory so that it can be used for page cache when
CMA devices do not use it.

Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
 include/linux/cma.h |  219 ++
 mm/Kconfig  |   28 +
 mm/Makefile |1 +
 mm/cma.c|  330 +++
 mm/page_alloc.c |2 +-
 5 files changed, 579 insertions(+), 1 deletions(-)
 create mode 100644 include/linux/cma.h
 create mode 100644 mm/cma.c

diff --git a/include/linux/cma.h b/include/linux/cma.h
new file mode 100644
index 000..e9575fd
--- /dev/null
+++ b/include/linux/cma.h
@@ -0,0 +1,219 @@
+#ifndef __LINUX_CMA_H
+#define __LINUX_CMA_H
+
+/*
+ * Contiguous Memory Allocator
+ * Copyright (c) 2010 by Samsung Electronics.
+ * Written by Michal Nazarewicz (m.nazarew...@samsung.com)
+ */
+
+/*
+ * Contiguous Memory Allocator
+ *
+ *   The Contiguous Memory Allocator (CMA) makes it possible for
+ *   device drivers to allocate big contiguous chunks of memory after
+ *   the system has booted.
+ *
+ *   It requires some machine- and/or platform-specific initialisation
+ *   code which prepares memory ranges to be used with CMA and later,
+ *   device drivers can allocate memory from those ranges.
+ *
+ * Why is it needed?
+ *
+ *   Various devices on embedded systems have no scatter-getter and/or
+ *   IO map support and require contiguous blocks of memory to
+ *   operate.  They include devices such as cameras, hardware video
+ *   coders, etc.
+ *
+ *   Such devices often require big memory buffers (a full HD frame
+ *   is, for instance, more then 2 mega pixels large, i.e. more than 6
+ *   MB of memory), which makes mechanisms such as kmalloc() or
+ *   alloc_page() ineffective.
+ *
+ *   At the same time, a solution where a big memory region is
+ *   reserved for a device is suboptimal since often more memory is
+ *   reserved then strictly required and, moreover, the memory is
+ *   inaccessible to page system even if device drivers don't use it.
+ *
+ *   CMA tries to solve this issue by operating on memory regions
+ *   where only movable pages can be allocated from.  This way, kernel
+ *   can use the memory for pagecache and when device driver requests
+ *   it, allocated pages can be migrated.
+ *
+ * Driver usage
+ *
+ *   For device driver to use CMA it needs to have a pointer to a CMA
+ *   context represented by a struct cma (which is an opaque data
+ *   type).
+ *
+ *   Once such pointer is obtained, device driver may allocate
+ *   contiguous memory chunk using the following function:
+ *
+ * cm_alloc()
+ *
+ *   This function returns a pointer to struct cm (another opaque data
+ *   type) which represent a contiguous memory chunk.  This pointer
+ *   may be used with the following functions:
+ *
+ * cm_free()-- frees allocated contiguous memory
+ * cm_pin() -- pins memory
+ * cm_unpin()   -- unpins memory
+ * cm_vmap()-- maps memory in kernel space
+ * cm_vunmap()  -- unmaps memory from kernel space
+ *
+ *   See the respective functions for more information.
+ *
+ * Platform/machine integration
+ *
+ *   For device drivers to be able to use CMA platform or machine
+ *   initialisation code must create a CMA context and pass it to
+ *   device drivers.  The latter may be done by a global variable or
+ *   a platform/machine specific function.  For the former CMA
+ *   provides the following functions:
+ *
+ * cma_reserve()
+ * cma_create()
+ *
+ *   The cma_reserve() function must be called when memblock is still
+ *   operational and reserving memory with it is still possible.  On
+ *   ARM platform the reserve machine callback is a perfect place to
+ *   call it.
+ *
+ *   The last function creates a CMA context on a range of previously
+ *   initialised memory addresses.  Because it uses kmalloc() it needs
+ *   to be called after SLAB is initialised.
+ */
+
+/* Kernel level API */
+
+#if defined __KERNEL__  defined CONFIG_CMA
+
+/* CMA context */
+struct cma;
+/* Contiguous Memory chunk */
+struct cm;
+
+/**
+ * cma_reserve() - reserves memory.
+ * @start: start address of the memory range in bytes hint; if unsure
+ * pass zero.
+ * @size:  size of the memory to reserve in bytes.
+ * @alignment: desired alignment in bytes (must be power

[PATCH 02/12] lib: genalloc: Generic allocator improvements

2011-03-31 Thread Marek Szyprowski

From: Michal Nazarewicz m.nazarew...@samsung.com

This commit adds a gen_pool_alloc_aligned() function to the
generic allocator API.  It allows specifying alignment for the
allocated block.  This feature uses
the bitmap_find_next_zero_area_off() function.

It also fixes possible issue with bitmap's last element being
not fully allocated (ie. space allocated for chunk-bits is
not a multiple of sizeof(long)).

It also makes some other smaller changes:
- moves structure definitions out of the header file,
- adds __must_check to functions returning value,
- makes gen_pool_add() return -ENOMEM rater than -1 on error,
- changes list_for_each to list_for_each_entry, and
- makes use of bitmap_clear().

Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
 include/linux/genalloc.h |   46 ++--
 lib/genalloc.c   |  182 ++---
 2 files changed, 129 insertions(+), 99 deletions(-)

diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
index 9869ef3..8ac7337 100644
--- a/include/linux/genalloc.h
+++ b/include/linux/genalloc.h
@@ -8,29 +8,31 @@
  * Version 2.  See the file COPYING for more details.
  */
 
+struct gen_pool;
 
-/*
- *  General purpose special memory pool descriptor.
- */
-struct gen_pool {
-   rwlock_t lock;
-   struct list_head chunks;/* list of chunks in this pool */
-   int min_alloc_order;/* minimum allocation order */
-};
+struct gen_pool *__must_check gen_pool_create(unsigned order, int nid);
 
-/*
- *  General purpose special memory pool chunk descriptor.
+int __must_check gen_pool_add(struct gen_pool *pool, unsigned long addr,
+ size_t size, int nid);
+
+void gen_pool_destroy(struct gen_pool *pool);
+
+unsigned long __must_check
+gen_pool_alloc_aligned(struct gen_pool *pool, size_t size,
+  unsigned alignment_order);
+
+/**
+ * gen_pool_alloc() - allocate special memory from the pool
+ * @pool:  Pool to allocate from.
+ * @size:  Number of bytes to allocate from the pool.
+ *
+ * Allocate the requested number of bytes from the specified pool.
+ * Uses a first-fit algorithm.
  */
-struct gen_pool_chunk {
-   spinlock_t lock;
-   struct list_head next_chunk;/* next chunk in pool */
-   unsigned long start_addr;   /* starting address of memory chunk */
-   unsigned long end_addr; /* ending address of memory chunk */
-   unsigned long bits[0];  /* bitmap for allocating memory chunk */
-};
+static inline unsigned long __must_check
+gen_pool_alloc(struct gen_pool *pool, size_t size)
+{
+   return gen_pool_alloc_aligned(pool, size, 0);
+}
 
-extern struct gen_pool *gen_pool_create(int, int);
-extern int gen_pool_add(struct gen_pool *, unsigned long, size_t, int);
-extern void gen_pool_destroy(struct gen_pool *);
-extern unsigned long gen_pool_alloc(struct gen_pool *, size_t);
-extern void gen_pool_free(struct gen_pool *, unsigned long, size_t);
+void gen_pool_free(struct gen_pool *pool, unsigned long addr, size_t size);
diff --git a/lib/genalloc.c b/lib/genalloc.c
index 1923f14..0761079 100644
--- a/lib/genalloc.c
+++ b/lib/genalloc.c
@@ -16,53 +16,80 @@
 #include linux/genalloc.h
 
 
+/* General purpose special memory pool descriptor. */
+struct gen_pool {
+   rwlock_t lock;  /* protects chunks list */
+   struct list_head chunks;/* list of chunks in this pool */
+   unsigned order; /* minimum allocation order */
+};
+
+/* General purpose special memory pool chunk descriptor. */
+struct gen_pool_chunk {
+   spinlock_t lock;/* protects bits */
+   struct list_head next_chunk;/* next chunk in pool */
+   unsigned long start;/* start of memory chunk */
+   unsigned long size; /* number of bits */
+   unsigned long bits[0];  /* bitmap for allocating memory chunk */
+};
+
+
 /**
- * gen_pool_create - create a new special memory pool
- * @min_alloc_order: log base 2 of number of bytes each bitmap bit represents
- * @nid: node id of the node the pool structure should be allocated on, or -1
+ * gen_pool_create() - create a new special memory pool
+ * @order: Log base 2 of number of bytes each bitmap bit
+ * represents.
+ * @nid:   Node id of the node the pool structure should be allocated
+ * on, or -1.  This will be also used for other allocations.
  *
  * Create a new special memory pool that can be used to manage special purpose
  * memory not managed by the regular kmalloc/kfree interface.
  */
-struct gen_pool *gen_pool_create(int min_alloc_order, int nid)
+struct gen_pool *__must_check gen_pool_create(unsigned order, int nid)
 {
struct gen_pool *pool;
 
-   pool =

[PATCH 03/12] mm: move some functions from memory_hotplug.c to page_isolation.c

2011-03-31 Thread Marek Szyprowski

From: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com

Memory hotplug is a logic for making pages unused in the specified
range of pfn. So, some of core logics can be used for other purpose
as allocating a very large contigous memory block.

This patch moves some functions from mm/memory_hotplug.c to
mm/page_isolation.c. This helps adding a function for large-alloc in
page_isolation.c with memory-unplug technique.

Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
[m.nazarewicz: reworded commit message]
Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[m.szyprowski: rebase and updated to v2.6.39-rc1 changes]
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
 include/linux/page-isolation.h |7 +++
 mm/memory_hotplug.c|  109 ---
 mm/page_isolation.c|  111 
 3 files changed, 118 insertions(+), 109 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 321fc74..746f6ed 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -640,115 +640,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 (!page_count(page))
-   continue;
-   /*
-* We can skip free pages. And we can only deal with pages on
-* LRU.
-*/
-   ret = isolate_lru_page(page);
-   if (!ret) { /* Success */
-   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
-   /* Becasue we don't have big zone-lock. we should
-  check this again here. */
-   if (page_count(page)) {
-   not_managed++;
-

[PATCH 11/12] v4l: videobuf2: add CMA allocator (for testing)

2011-03-31 Thread Marek Szyprowski

Add support for the CMA contiguous memory allocator to videobuf2.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
CC: Michal Nazarewicz min...@mina86.com
---
 drivers/media/video/Kconfig |6 +
 drivers/media/video/Makefile|1 +
 drivers/media/video/videobuf2-cma.c |  227 +++
 include/media/videobuf2-cma.h   |   40 ++
 4 files changed, 274 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/videobuf2-cma.c
 create mode 100644 include/media/videobuf2-cma.h

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 4498b94..d80c9d6 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -66,6 +66,12 @@ config VIDEOBUF2_DMA_SG
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
tristate
+
+config VIDEOBUF2_CMA
+   depends on CMA
+   select VIDEOBUF2_CORE
+   select VIDEOBUF2_MEMOPS
+   tristate
 #
 # Multimedia Video device configuration
 #
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index ace5d8b..86e98df 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -118,6 +118,7 @@ obj-$(CONFIG_VIDEOBUF2_MEMOPS)  += 
videobuf2-memops.o
 obj-$(CONFIG_VIDEOBUF2_VMALLOC)+= videobuf2-vmalloc.o
 obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
 obj-$(CONFIG_VIDEOBUF2_DMA_SG) += videobuf2-dma-sg.o
+obj-$(CONFIG_VIDEOBUF2_CMA)+= videobuf2-cma.o
 
 obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
 
diff --git a/drivers/media/video/videobuf2-cma.c 
b/drivers/media/video/videobuf2-cma.c
new file mode 100644
index 000..5dc7e89
--- /dev/null
+++ b/drivers/media/video/videobuf2-cma.c
@@ -0,0 +1,227 @@
+/*
+ * videobuf2-cma.c - CMA memory allocator for videobuf2
+ *
+ * Copyright (C) 2010-2011 Samsung Electronics
+ *
+ * Author: Pawel Osciak p.osc...@samsung.com
+ *Marek Szyprowski m.szyprow...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/slab.h
+#include linux/cma.h
+#include linux/mm.h
+#include linux/sched.h
+#include linux/file.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-memops.h
+
+#include asm/io.h
+
+struct vb2_cma_conf {
+   struct device   *dev;
+   const char  *type;
+   unsigned long   alignment;
+};
+
+struct vb2_cma_buf {
+   struct vb2_cma_conf *conf;
+   struct cm   *cm;
+   dma_addr_t  paddr;
+   unsigned long   size;
+   struct vm_area_struct   *vma;
+   atomic_trefcount;
+   struct vb2_vmarea_handler   handler;
+};
+
+static void vb2_cma_put(void *buf_priv);
+
+static void *vb2_cma_alloc(void *alloc_ctx, unsigned long size)
+{
+   struct vb2_cma_conf *conf = alloc_ctx;
+   struct vb2_cma_buf *buf;
+
+   buf = kzalloc(sizeof *buf, GFP_KERNEL);
+   if (!buf)
+   return ERR_PTR(-ENOMEM);
+
+   buf-cm = cma_alloc(conf-dev, conf-type, size, conf-alignment);
+   if (IS_ERR(buf-cm)) {
+   printk(KERN_ERR cma_alloc of size %ld failed\n, size);
+   kfree(buf);
+   return ERR_PTR(-ENOMEM);
+   }
+   buf-paddr = cm_pin(buf-cm);
+   buf-conf = conf;
+   buf-size = size;
+
+   buf-handler.refcount = buf-refcount;
+   buf-handler.put = vb2_cma_put;
+   buf-handler.arg = buf;
+
+   atomic_inc(buf-refcount);
+
+   return buf;
+}
+
+static void vb2_cma_put(void *buf_priv)
+{
+   struct vb2_cma_buf *buf = buf_priv;
+
+   if (atomic_dec_and_test(buf-refcount)) {
+   cm_unpin(buf-cm);
+   cma_free(buf-cm);
+   kfree(buf);
+   }
+}
+
+static void *vb2_cma_cookie(void *buf_priv)
+{
+   struct vb2_cma_buf *buf = buf_priv;
+
+   return (void *)buf-paddr;
+}
+
+static unsigned int vb2_cma_num_users(void *buf_priv)
+{
+   struct vb2_cma_buf *buf = buf_priv;
+
+   return atomic_read(buf-refcount);
+}
+
+static int vb2_cma_mmap(void *buf_priv, struct vm_area_struct *vma)
+{
+   struct vb2_cma_buf *buf = buf_priv;
+
+   if (!buf) {
+   printk(KERN_ERR No buffer to map\n);
+   return -EINVAL;
+   }
+
+   return vb2_mmap_pfn_range(vma, buf-paddr, buf-size,
+ vb2_common_vm_ops, buf-handler);
+}
+
+static void *vb2_cma_get_userptr(void *alloc_ctx, unsigned long vaddr,
+unsigned long size, int write)
+{
+   struct vb2_cma_buf *buf;
+   struct vm_area_struct *vma;
+   dma_addr_t paddr = 0;
+   int

[PATCH 12/12] ARM: S5PC110: Added CMA regions to Aquila and Goni boards

2011-03-31 Thread Marek Szyprowski

This commit adds CMA memory regions to Aquila and Goni boards.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-s5pv210/mach-aquila.c |   31 +++
 arch/arm/mach-s5pv210/mach-goni.c   |   31 +++
 2 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s5pv210/mach-aquila.c 
b/arch/arm/mach-s5pv210/mach-aquila.c
index 4e1d8ff..de3c41f 100644
--- a/arch/arm/mach-s5pv210/mach-aquila.c
+++ b/arch/arm/mach-s5pv210/mach-aquila.c
@@ -21,6 +21,7 @@
 #include linux/gpio_keys.h
 #include linux/input.h
 #include linux/gpio.h
+#include linux/cma.h
 
 #include asm/mach/arch.h
 #include asm/mach/map.h
@@ -642,6 +643,35 @@ static void __init aquila_sound_init(void)
__raw_writel(__raw_readl(S5P_OTHERS) | (0x3  8), S5P_OTHERS);
 }
 
+static void __init aquila_reserve(void)
+{
+   static struct cma_region regions[] = {
+   {
+   .name   = fw,
+   .size   =  16  20,
+   .alignment  = 128  10,
+   .start  = 0x3200,
+   },
+   {
+   .name   = b1,
+   .size   =  32  20,
+   .start  = 0x3300,
+   },
+   {
+   .name   = b2,
+   .size   =  32  20,
+   .start  = 0x4400,
+   },
+   { }
+   };
+
+   static const char map[] __initconst =
+   s5p-mfc/f=fw;s5p-mfc/a=b1;s5p-mfc/b=b2;*=b1,b2;
+
+   cma_set_defaults(regions, map);
+   cma_early_regions_reserve(NULL);
+}
+
 static void __init aquila_map_io(void)
 {
s5p_init_io(NULL, 0, S5P_VA_CHIPID);
@@ -683,4 +713,5 @@ MACHINE_START(AQUILA, Aquila)
.map_io = aquila_map_io,
.init_machine   = aquila_machine_init,
.timer  = s5p_timer,
+   .reserve= aquila_reserve,
 MACHINE_END
diff --git a/arch/arm/mach-s5pv210/mach-goni.c 
b/arch/arm/mach-s5pv210/mach-goni.c
index 31d5aa7..24f3f5c 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -26,6 +26,7 @@
 #include linux/input.h
 #include linux/gpio.h
 #include linux/interrupt.h
+#include linux/cma.h
 
 #include asm/mach/arch.h
 #include asm/mach/map.h
@@ -833,6 +834,35 @@ static void __init goni_sound_init(void)
__raw_writel(__raw_readl(S5P_OTHERS) | (0x3  8), S5P_OTHERS);
 }
 
+static void __init goni_reserve(void)
+{
+   static struct cma_region regions[] = {
+   {
+   .name   = fw,
+   .size   =  16  20,
+   .alignment  = 128  10,
+   .start  = 0x3100,
+   },
+   {
+   .name   = b1,
+   .size   =  32  20,
+   .start  = 0x3300,
+   },
+   {
+   .name   = b2,
+   .size   =  32  20,
+   .start  = 0x4400,
+   },
+   { }
+   };
+
+   static const char map[] __initconst =
+   s5p-mfc/f=fw;s5p-mfc/a=b1;s5p-mfc/b=b2;*=b1,b2;
+
+   cma_set_defaults(regions, map);
+   cma_early_regions_reserve(NULL);
+}
+
 static void __init goni_map_io(void)
 {
s5p_init_io(NULL, 0, S5P_VA_CHIPID);
@@ -893,4 +923,5 @@ MACHINE_START(GONI, GONI)
.map_io = goni_map_io,
.init_machine   = goni_machine_init,
.timer  = s5p_timer,
+   .reserve= goni_reserve,
 MACHINE_END
-- 
1.7.1.569.g6f426
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 07/12] mm: MIGRATE_CMA migration type added

2011-03-31 Thread Marek Szyprowski

From: Michal Nazarewicz m.nazarew...@samsung.com

The MIGRATE_CMA migration type has two main characteristics:
(i) only movable pages can be allocated from MIGRATE_CMA
pageblocks and (ii) page allocator will never change migration
type of MIGRATE_CMA pageblocks.

This guarantees that page in a MIGRATE_CMA page block can
always be migrated somewhere else (unless there's no memory left
in the system).

It is designed to be used with Contiguous Memory Allocator
(CMA) for allocating big chunks (eg. 10MiB) of physically
contiguous memory.  Once driver requests contiguous memory,
CMA will migrate pages from MIGRATE_CMA pageblocks.

To minimise number of migrations, MIGRATE_CMA migration type
is the last type tried when page allocator falls back to other
migration types then requested.

Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
 include/linux/mmzone.h |   43 ++
 mm/Kconfig |   28 +--
 mm/compaction.c|   10 +
 mm/internal.h  |3 ++
 mm/page_alloc.c|   93 ++--
 5 files changed, 140 insertions(+), 37 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index e56f835..db8495e 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -35,13 +35,37 @@
  */
 #define PAGE_ALLOC_COSTLY_ORDER 3
 
-#define MIGRATE_UNMOVABLE 0
-#define MIGRATE_RECLAIMABLE   1
-#define MIGRATE_MOVABLE   2
-#define MIGRATE_PCPTYPES  3 /* the number of types on the pcp lists */
-#define MIGRATE_RESERVE   3
-#define MIGRATE_ISOLATE   4 /* can't allocate from here */
-#define MIGRATE_TYPES 5
+enum {
+   MIGRATE_UNMOVABLE,
+   MIGRATE_RECLAIMABLE,
+   MIGRATE_MOVABLE,
+   MIGRATE_PCPTYPES,   /* the number of types on the pcp lists */
+   MIGRATE_RESERVE = MIGRATE_PCPTYPES,
+#ifdef CONFIG_MIGRATE_CMA
+   /*
+* MIGRATE_CMA migration type is designed to mimic the way
+* ZONE_MOVABLE works.  Only movable pages can be allocated
+* from MIGRATE_CMA pageblocks and page allocator never
+* implicitly change migration type of MIGRATE_CMA pageblock.
+*
+* The way to use it is to change migratetype of a range of
+* pageblocks to MIGRATE_CMA which can be done by
+* __free_pageblock_cma() function.  What is important though
+* is that a range of pageblocks must be aligned to
+* MAX_ORDER_NR_PAGES should biggest page be bigger then
+* a single pageblock.
+*/
+   MIGRATE_CMA,
+#endif
+   MIGRATE_ISOLATE,/* can't allocate from here */
+   MIGRATE_TYPES
+};
+
+#ifdef CONFIG_MIGRATE_CMA
+#  define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
+#else
+#  define is_migrate_cma(migratetype) false
+#endif
 
 #define for_each_migratetype_order(order, type) \
for (order = 0; order  MAX_ORDER; order++) \
@@ -54,6 +78,11 @@ static inline int get_pageblock_migratetype(struct page 
*page)
return get_pageblock_flags_group(page, PB_migrate, PB_migrate_end);
 }
 
+static inline bool is_pageblock_cma(struct page *page)
+{
+   return is_migrate_cma(get_pageblock_migratetype(page));
+}
+
 struct free_area {
struct list_headfree_list[MIGRATE_TYPES];
unsigned long   nr_free;
diff --git a/mm/Kconfig b/mm/Kconfig
index ac40779..844455e 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -341,23 +341,29 @@ choice
 endchoice
 
 config CMA
-   bool Contiguous Memory Allocator framework
-   # Currently there is only one allocator so force it on
+   bool Contiguous Memory Allocator
select MIGRATION
select GENERIC_ALLOCATOR
help
- This enables the Contiguous Memory Allocator framework 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.
+ 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.
 
- If you select this option you will also have to select at least
- one allocator algorithm below.
+ For more information see include/linux/cma.h.  If unsure, say n.
+
+config MIGRATE_CMA
+   bool Use MIGRATE_CMA migratetype
+   depends on CMA
+   default y
+   help
+ This enables the use the MIGRATE_CMA migrate type in the CMA.
+ MIGRATE_CMA lets CMA work on almost arbitrary memory range and
+ not only inside ZONE_MOVABLE.
 
- To make use of CMA you need to specify the regions and
- driver-region mapping on command line when

[PATCH 09/12] mm: MIGRATE_CMA support added to CMA

2011-03-31 Thread Marek Szyprowski

From: Michal Nazarewicz m.nazarew...@samsung.com

This commit adds MIGRATE_CMA migratetype support to the CMA.
The advantage is that an (almost) arbitrary memory range can
be marked as MIGRATE_CMA which may not be the case with
ZONE_MOVABLE.

Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
 include/linux/cma.h |   58 +++---
 mm/cma.c|  167 --
 2 files changed, 197 insertions(+), 28 deletions(-)

diff --git a/include/linux/cma.h b/include/linux/cma.h
index e9575fd..8952531 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -71,9 +71,14 @@
  *   a platform/machine specific function.  For the former CMA
  *   provides the following functions:
  *
+ * cma_init_migratetype()
  * cma_reserve()
  * cma_create()
  *
+ *   The first one initialises a portion of reserved memory so that it
+ *   can be used with CMA.  The second first tries to reserve memory
+ *   (using memblock) and then initialise it.
+ *
  *   The cma_reserve() function must be called when memblock is still
  *   operational and reserving memory with it is still possible.  On
  *   ARM platform the reserve machine callback is a perfect place to
@@ -93,21 +98,56 @@ struct cma;
 /* Contiguous Memory chunk */
 struct cm;
 
+#ifdef CONFIG_MIGRATE_CMA
+
+/**
+ * cma_init_migratetype() - initialises range of physical memory to be used
+ * with CMA context.
+ * @start: start address of the memory range in bytes.
+ * @size:  size of the memory range in bytes.
+ *
+ * The range must be MAX_ORDER_NR_PAGES aligned and it must have been
+ * already reserved (eg. with memblock).
+ *
+ * The actual initialisation is deferred until subsys initcalls are
+ * evaluated (unless this has already happened).
+ *
+ * Returns zero on success or negative error.
+ */
+int cma_init_migratetype(unsigned long start, unsigned long end);
+
+#else
+
+static inline int cma_init_migratetype(unsigned long start, unsigned long end)
+{
+   (void)start; (void)end;
+   return -EOPNOTSUPP;
+}
+
+#endif
+
 /**
  * cma_reserve() - reserves memory.
  * @start: start address of the memory range in bytes hint; if unsure
  * pass zero.
  * @size:  size of the memory to reserve in bytes.
  * @alignment: desired alignment in bytes (must be power of two or zero).
+ * @init_migratetype:  whether to initialise pageblocks.
+ *
+ * It will use memblock to allocate memory.  If @init_migratetype is
+ * true, the function will also call cma_init_migratetype() on
+ * reserved region so that a non-private CMA context can be created on
+ * given range.
  *
- * It will use memblock to allocate memory.  @start and @size will be
- * aligned to PAGE_SIZE.
+ * @start and @size will be aligned to PAGE_SIZE if @init_migratetype
+ * is false or to (MAX_ORDER_NR_PAGES  PAGE_SHIFT) if
+ * @init_migratetype is true.
  *
  * Returns reserved's area physical address or value that yields true
  * when checked with IS_ERR_VALUE().
  */
 unsigned long cma_reserve(unsigned long start, unsigned long size,
- unsigned long alignment);
+ unsigned long alignment, _Bool init_migratetype);
 
 /**
  * cma_create() - creates a CMA context.
@@ -118,12 +158,14 @@ unsigned long cma_reserve(unsigned long start, unsigned 
long size,
  *
  * The range must be page aligned.  Different contexts cannot overlap.
  *
- * Unless @private is true the memory range must lay in ZONE_MOVABLE.
- * If @private is true no underlaying memory checking is done and
- * during allocation no pages migration will be performed - it is
- * assumed that the memory is reserved and only CMA manages it.
+ * Unless @private is true the memory range must either lay in
+ * ZONE_MOVABLE or must have been initialised with
+ * cma_init_migratetype() function.  If @private is true no
+ * underlaying memory checking is done and during allocation no pages
+ * migration will be performed - it is assumed that the memory is
+ * reserved and only CMA manages it.
  *
- * @start and @size must be page and @min_alignment alignment.
+ * @start and @size must be page and @min_alignment aligned.
  * @min_alignment specifies the minimal alignment that user will be
  * able to request through cm_alloc() function.  In most cases one
  * will probably pass zero as @min_alignment but if the CMA context
diff --git a/mm/cma.c b/mm/cma.c
index f212920..ded91cab 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -57,21 +57,132 @@ static unsigned long phys_to_pfn(phys_addr_t phys)
 
 /* Initialise CMA */
 
+#ifdef CONFIG_MIGRATE_CMA
+
+static struct cma_grabbed {
+   unsigned long start;
+   unsigned long size;
+} cma_grabbed[8] __initdata;
+static unsigned cma_grabbed_count __initdata;
+

[PATCH 05/12] mm: alloc_contig_range() added

2011-03-31 Thread Marek Szyprowski

From: Michal Nazarewicz m.nazarew...@samsung.com

This commit adds the alloc_contig_range() function which tries
to allecate given range of pages.  It tries to migrate all
already allocated pages that fall in the range thus freeing them.
Once all pages in the range are freed they are removed from the
buddy system thus allocated for the caller to use.

Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
 include/linux/page-isolation.h |2 +
 mm/page_alloc.c|  144 
 2 files changed, 146 insertions(+), 0 deletions(-)

diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index f1417ed..c5d1a7c 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -34,6 +34,8 @@ extern int set_migratetype_isolate(struct page *page);
 extern void unset_migratetype_isolate(struct page *page);
 extern unsigned long alloc_contig_freed_pages(unsigned long start,
  unsigned long end, gfp_t flag);
+extern int alloc_contig_range(unsigned long start, unsigned long end,
+ gfp_t flags);
 extern void free_contig_pages(struct page *page, int nr_pages);
 
 /*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 11f8bcb..0a270a5 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5583,6 +5583,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 _start, _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

[PATCH 08/12] mm: MIGRATE_CMA isolation functions added

2011-03-31 Thread Marek Szyprowski

From: Michal Nazarewicz m.nazarew...@samsung.com

This commit changes various functions that change pages and
pageblocks migrate type between MIGRATE_ISOLATE and
MIGRATE_MOVABLE in such a way as to allow to work with
MIGRATE_CMA migrate type.

Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
 include/linux/page-isolation.h |   40 +++-
 mm/page_alloc.c|   19 ---
 mm/page_isolation.c|   15 ---
 3 files changed, 47 insertions(+), 27 deletions(-)

diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index c5d1a7c..177b307 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 24f795e..5f4232d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5586,7 +5586,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;
@@ -5594,8 +5594,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);
 }
@@ -5700,6 +5700,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
@@ -5711,7 +5715,7

[PATCH 01/12] lib: bitmap: Added alignment offset for bitmap_find_next_zero_area()

2011-03-31 Thread Marek Szyprowski

From: Michal Nazarewicz m.nazarew...@samsung.com

This commit adds a bitmap_find_next_zero_area_off() function which
works like bitmap_find_next_zero_area() function expect it allows an
offset to be specified when alignment is checked.  This lets caller
request a bit such that its number plus the offset is aligned
according to the mask.

Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
 include/linux/bitmap.h |   24 +++-
 lib/bitmap.c   |   22 --
 2 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
index daf8c48..c0528d1 100644
--- a/include/linux/bitmap.h
+++ b/include/linux/bitmap.h
@@ -45,6 +45,7 @@
  * bitmap_set(dst, pos, nbits) Set specified bit area
  * bitmap_clear(dst, pos, nbits)   Clear specified bit area
  * bitmap_find_next_zero_area(buf, len, pos, n, mask)  Find bit free area
+ * bitmap_find_next_zero_area_off(buf, len, pos, n, mask)  as above
  * bitmap_shift_right(dst, src, n, nbits)  *dst = *src  n
  * bitmap_shift_left(dst, src, n, nbits)   *dst = *src  n
  * bitmap_remap(dst, src, old, new, nbits) *dst = map(old, new)(src)
@@ -113,11 +114,24 @@ extern int __bitmap_weight(const unsigned long *bitmap, 
int bits);
 
 extern void bitmap_set(unsigned long *map, int i, int len);
 extern void bitmap_clear(unsigned long *map, int start, int nr);
-extern unsigned long bitmap_find_next_zero_area(unsigned long *map,
-unsigned long size,
-unsigned long start,
-unsigned int nr,
-unsigned long align_mask);
+
+extern unsigned long bitmap_find_next_zero_area_off(unsigned long *map,
+   unsigned long size,
+   unsigned long start,
+   unsigned int nr,
+   unsigned long align_mask,
+   unsigned long align_offset);
+
+static inline unsigned long
+bitmap_find_next_zero_area(unsigned long *map,
+  unsigned long size,
+  unsigned long start,
+  unsigned int nr,
+  unsigned long align_mask)
+{
+   return bitmap_find_next_zero_area_off(map, size, start, nr,
+ align_mask, 0);
+}
 
 extern int bitmap_scnprintf(char *buf, unsigned int len,
const unsigned long *src, int nbits);
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 741fae9..8e75a6f 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -315,30 +315,32 @@ void bitmap_clear(unsigned long *map, int start, int nr)
 }
 EXPORT_SYMBOL(bitmap_clear);
 
-/*
+/**
  * bitmap_find_next_zero_area - find a contiguous aligned zero area
  * @map: The address to base the search on
  * @size: The bitmap size in bits
  * @start: The bitnumber to start searching at
  * @nr: The number of zeroed bits we're looking for
  * @align_mask: Alignment mask for zero area
+ * @align_offset: Alignment offset for zero area.
  *
  * The @align_mask should be one less than a power of 2; the effect is that
- * the bit offset of all zero areas this function finds is multiples of that
- * power of 2. A @align_mask of 0 means no alignment is required.
+ * the bit offset of all zero areas this function finds plus @align_offset
+ * is multiple of that power of 2.
  */
-unsigned long bitmap_find_next_zero_area(unsigned long *map,
-unsigned long size,
-unsigned long start,
-unsigned int nr,
-unsigned long align_mask)
+unsigned long bitmap_find_next_zero_area_off(unsigned long *map,
+unsigned long size,
+unsigned long start,
+unsigned int nr,
+unsigned long align_mask,
+unsigned long align_offset)
 {
unsigned long index, end, i;
 again:
index = find_next_zero_bit(map, size, start);
 
/* Align allocation */
-   index = __ALIGN_MASK(index, align_mask);
+   index = __ALIGN_MASK(index + align_offset, align_mask) - align_offset;
 
end = index + nr;
if (end  size)
@@ -350,7 +352,7 @@ again:
}
return index;
 }
-EXPORT_SYMBOL(bitmap_find_next_zero_area);
+EXPORT_SYMBOL(bitmap_find_next_zero_area_off);
 
 /*

[PATCHv9 0/12] Contiguous Memory Allocator

2011-03-31 Thread Marek Szyprowski

Hello everyone,

There have been a bit quiet about Contiguous Memory Allocator for last
months. This is mainly caused by the fact that Michal (the author of CMA
patches) has left our team and we needed some time to takeover the
development.

This version is mainly a rebase and adaptation for 2.6.39-rc1 kernel
release. I've also managed to fix a bunch of nasty bugs that caused
problems if the allocation failed.

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 see the changelog and links to previous versions
   of CMA framework.

The current version is just an allocator 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 cm_alloc()/cm_free()
   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 current version doesn't handle any DMA mapping for the allocated
chunks. This topic will be handled by a separate patch series in the
future.

Despite that, we were able to test this version with real multimedia
hardware on Samsung S5PC110 platform. We used V4L2 drivers that already
contain support for CMA-based memory allocator in videobuf2 framework.
Please refer to last 3 patches of this series to get the idea how it can
be used.


Links to previous versions of the patchset:
v8: http://article.gmane.org/gmane.linux.kernel.mm/56855
v7: http://article.gmane.org/gmane.linux.kernel.mm/55626
v6: http://article.gmane.org/gmane.linux.kernel.mm/55626
v5: (intentionally left out as CMA v5 was identical to CMA v4)
v4: http://article.gmane.org/gmane.linux.kernel.mm/52010
v3: http://article.gmane.org/gmane.linux.kernel.mm/51573
v2: http://article.gmane.org/gmane.linux.kernel.mm/50986
v1: http://article.gmane.org/gmane.linux.kernel.mm/50669


Changelog:

v9: 1. Rebased onto 2.6.39-rc1 and resolved all conflicts

2. Fixed a bunch of nasty bugs that happened when the allocation
   failed (mainly kernel oops due to NULL ptr dereference).

3. Introduced testing code: cma-regions compatibility layer and
   videobuf2-cma memory allocator module.

v8: 1. The alloc_contig_range() function has now been separated from
   CMA and put in page_allocator.c.  This function tries to
   migrate all LRU pages in specified range and then allocate the
   range using alloc_contig_freed_pages().

2. Support for MIGRATE_CMA has been separated from the CMA code.
   I have not tested if CMA works with ZONE_MOVABLE but I see no
   reasons why it shouldn't.

3. I have added a @private argument when creating CMA contexts so
   that one can reserve memory and not share it with the rest of
   the system.  This way, CMA acts only as allocation algorithm.

v7: 1. A lot of functionality that handled driver-allocator_context
   mapping has been removed from the patchset.  This is not to say
   that this code is not needed, it's just not worth posting
   everything in one patchset.

   Currently, CMA is just an allocator.  It uses it's own
   migratetype (MIGRATE_CMA) for defining ranges of pageblokcs
   which behave just like ZONE_MOVABLE but dispite the latter can
   be put in arbitrary places.

2. The migration code that was introduced in the previous version
   actually started working.


v6: 1. Most importantly, v6 introduces support for memory migration.
   The implementation is not yet complete though.

   Migration support means that when CMA is not using memory
   reserved for it, page

[PATCH 10/12] mm: cma: add CMA 'regions style' API (for testing)

2011-03-31 Thread Marek Szyprowski

This patch adds CMA 'regions style' API (almost compatible with CMA v1).
It is intended mainly for testing the real contigous memory allocator
and page migration with devices that use older CMA api.

Based on previous works by Michal Nazarewicz.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Michal Nazarewicz min...@mina86.com
---
 include/linux/cma-regions.h |  340 +++
 include/linux/cma.h |3 +
 mm/Makefile |2 +-
 mm/cma-regions.c|  759 +++
 4 files changed, 1103 insertions(+), 1 deletions(-)
 create mode 100644 include/linux/cma-regions.h
 create mode 100644 mm/cma-regions.c

diff --git a/include/linux/cma-regions.h b/include/linux/cma-regions.h
new file mode 100644
index 000..f3a2f4d
--- /dev/null
+++ b/include/linux/cma-regions.h
@@ -0,0 +1,340 @@
+#ifndef __LINUX_CMA_REGIONS_H
+#define __LINUX_CMA_REGIONS_H
+
+/*
+ * Contiguous Memory Allocator framework - memory region management
+ * Copyright (c) 2010-2011 by Samsung Electronics.
+ * Written by Michal Nazarewicz (m.nazarew...@samsung.com)
+ * Updated by Marek Szyprowski (m.szyprow...@samsung.com)
+ */
+
+/*
+ * See Documentation/contiguous-memory.txt for details.
+ */
+
+#include linux/ioctl.h
+#include linux/types.h
+#include linux/err.h
+#include linux/init.h
+
+/* Kernel level API */
+
+#include linux/rbtree.h
+#include linux/list.h
+
+
+struct device;
+struct cma_info;
+struct cm;
+
+/*
+ * Don't call it directly, use cma_alloc(), cma_alloc_from() or
+ * cma_alloc_from_region().
+ */
+struct cm * __must_check
+__cma_alloc(const struct device *dev, const char *type,
+   size_t size, dma_addr_t alignment);
+
+/* Don't call it directly, use cma_info() or cma_info_about(). */
+int
+__cma_info(struct cma_info *info, const struct device *dev, const char *type);
+
+
+/**
+ * cma_alloc - allocates contiguous chunk of memory.
+ * @dev:   The device to perform allocation for.
+ * @type:  A type of memory to allocate.  Platform may define
+ * several different types of memory and device drivers
+ * can then request chunks of different types.  Usually it's
+ * safe to pass NULL here which is the same as passing
+ * common.
+ * @size:  Size of the memory to allocate in bytes.
+ * @alignment: Desired alignment in bytes.  Must be a power of two or
+ * zero.  If alignment is less then a page size it will be
+ * set to page size. If unsure, pass zero here.
+ *
+ * On error returns a negative error cast to dma_addr_t.  Use
+ * IS_ERR_VALUE() to check if returned value is indeed an error.
+ * Otherwise bus address of the chunk is returned.
+ */
+static inline struct cm * __must_check
+cma_alloc(const struct device *dev, const char *type,
+ size_t size, dma_addr_t alignment)
+{
+   return dev ? __cma_alloc(dev, type, size, alignment) : ERR_PTR(-EINVAL);
+}
+
+
+/**
+ * struct cma_info - information about regions returned by cma_info().
+ * @lower_bound:   The smallest address that is possible to be
+ * allocated for given (dev, type) pair.
+ * @upper_bound:   The one byte after the biggest address that is
+ * possible to be allocated for given (dev, type)
+ * pair.
+ * @total_size:Total size of regions mapped to (dev, type) pair.
+ * @free_size: Total free size in all of the regions mapped to (dev, type)
+ * pair.  Because of possible race conditions, it is not
+ * guaranteed that the value will be correct -- it gives only
+ * an approximation.
+ * @count: Number of regions mapped to (dev, type) pair.
+ */
+struct cma_info {
+   dma_addr_t lower_bound, upper_bound;
+   size_t total_size, free_size;
+   unsigned count;
+};
+
+/**
+ * cma_info - queries information about regions.
+ * @info:  Pointer to a structure where to save the information.
+ * @dev:   The device to query information for.
+ * @type:  A type of memory to query information for.
+ * If unsure, pass NULL here which is equal to passing
+ * common.
+ *
+ * On error returns a negative error, zero otherwise.
+ */
+static inline int
+cma_info(struct cma_info *info, const struct device *dev, const char *type)
+{
+   return dev ? __cma_info(info, dev, type) : -EINVAL;
+}
+
+
+/**
+ * cma_free - frees a chunk of memory.
+ * @addr:  Beginning of the chunk.
+ *
+ * Returns -ENOENT if there is no chunk at given location; otherwise
+ * zero.  In the former case issues a warning.
+ */
+int cma_free(struct cm *addr);
+
+
+
+/** Lower lever API */
+
+/**
+ * cma_alloc_from - allocates contiguous chunk of memory from named regions.
+ * @regions:   Comma separated

Re: [RFC] API for controlling Scenemode Preset

2011-03-31 Thread Laurent Pinchart

Hi HeungJun,

On Thursday 31 March 2011 07:39:09 Kim, HeungJun wrote:
 Hello everyone,
 
 This is a suggestion about the preset for the scenemode of camera. It's
 just one API, and its role determines which current scenemode preset of
 camera is.
 
 The kinds of scenemode are various at each camera. But, as you look around
 camera, the each scenemode has common name and the specific scenemode just
 exist or not. So, I started to collect the scenemode common set of Fujitsu
 M-5MOLS and NEC CE147. And, I found these modes are perfetly matched,
 althogh the names are a little different.

[snip]

Are those presets really implemented in hardware ? I expect that they control 
various configuration parameters such as white balance. Can all those 
parameters also be controlled manually, or are they (or some of them) settable 
only through the scene mode presets ?

-- 
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: v4l: Buffer pools

2011-03-31 Thread Laurent Pinchart

Hi Marek,

On Thursday 31 March 2011 12:14:55 Marek Szyprowski wrote:
 On Tuesday, March 29, 2011 4:02 PM Willy POISSON wrote:
  Following to the Warsaw mini-summit action point, I would like to open
  the thread to gather
  
  buffer pool  memory manager requirements.
  The list of requirement for buffer pool may contain:
  -   Support physically contiguous and virtual memory
  -   Support IPC, import/export handles (between
  processes/drivers/userland/etc) -   Security(access rights in order to
  secure no one unauthorized is allowed to access buffers) -  Cache flush
  management (by using setdomain and optimize when flushing is needed)
  -   Pin/unpin in order to get the actual address to be able to do
  defragmentation -   Support pinning in user land in order to allow
  defragmentation while buffer is mmapped but not pined.
  -   Both a user API and a Kernel API is needed for this module. (Kernel
  drivers needs to be able to resolve buffer handles as well from the
  memory manager module, and pin/unpin) - be able to support any platform
  specific allocator (Separate memory allocation from management as
  allocator is platform dependant)
  -   Support multiple region domain (Allow to allocate from several memory
  domain ex: DDR1, DDR2, Embedded SRAM to make for ex bandwidth load
  balancing ...)
 
 The above list looks fine.
 
 Memory/buffer pools are a large topic that covers at least 3 subsystems:
 1. user space api
 2. in-kernel buffer manager
 3. in-kernel memory allocator
 
 Most of the requirements above list can be assigned to one of these
 subsystems.
 
 If would like to focus first on the user space API. This API should provide
 a generic way to allocate memory buffers. User space should not be aware
 of the allocator specific parameters of the buffer. User space should not
 decide whether a physically contiguous buffer is needed or not. The only
 information that user space should provide is a set or list of devices
 that the application want use with the allocated buffer. User space might
 also provide some additional hints about the buffers - like the preferred
 memory region.
 
 Our chip S5PC110 and EXYNOS4 are very similar in terms of integrated
 multimedia modules, however there is one important difference. The latter
 has IOMMU module, so multimedia blocks doesn't require physically
 contiguous buffers. In userspace however we would like to support both
 with the same API.
 
 We have also a very specific requirement for buffers for video codes
 (chroma buffers and luma buffers must be allocated from different memory
 banks). The memory bank should be specified at allocation time.
 
 The only problem is to define a way the user space API will be able to
 provide a list of devices that must be able to operate with the allocated
 buffer. Without some kind of enumeration of all entities that work with
 buffer pool it might be a bit hard. I would like to avoid the need of
 hardcoding device names in the user space applications.

I've been thinking about that, and I'm not sure how feasible it would be. 
Beside the difficulty of passing a list of devices from applications to the 
kernel, drivers would need to transform that list into memory requirements 
compatible with all devices in the list. That will likely become very complex.

Wouldn't it be better to let applications specify memory requirements 
explicitly, and have individual drivers check if the buffers match their 
requirements when the buffer are used ?

 The in-kernel memory allocator is mainly targeted to systems that require
 physically contiguous buffers. Currently CMA framework perfectly fits
 here. A new version will be posted very soon.
 
  Another idea, but not so linked to memory management (more usage of
  buffers), would be to have a common data container (structure to access
  data) shared by several media (Imaging, video/still codecs, graphics,
  Display...) to ease usage of the data. This container could  embed data
  type (video frames, Access Unit) , frames format, pixel format, width,
  height, pixel aspect ratio, region of interest, CTS (composition time
  stamp),  ColorSpace, transparency (opaque, alpha, color key...), pointer
  on buffer(s) handle)...
 
 I'm not sure if such idea can be ever implemented in the mainline kernel...
 IHMO it is too complicated.

-- 
Regards,

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

Re: [PATCH 04/12] mm: alloc_contig_freed_pages() added

2011-03-31 Thread Dave Hansen

On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
 
 +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));

This seems kinda mean.  Could we return an error?  I understand that
this is largely going to be an early-boot thing, but surely trying to
punt on crappy input beats a full-on BUG().

if (!pfn_valid(start))
return -1;

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

If start-end happens to span the end of a zone, I believe this will
jump out of the zone.  It will still be pfn_valid(), but potentially not
in the same zone. 

 +   VM_BUG_ON(!pfn_valid(pfn));
 +   page += 1  order;
 +   }

That will break on SPARSEMEM.  You potentially need to revalidate the
pfn-page mapping on every MAX_ORDER pfn change.  It's easiest to just
do pfn_to_page() on each loop.

 +
 +   spin_unlock_irq(zone-lock); 
 
 +void free_contig_pages(struct page *page, int nr_pages)
 +{
 +   for (; nr_pages; --nr_pages, ++page)
 +   __free_page(page);
 +}

Can't help but notice that this resembles a bit of a patch I posted last
week:

http://www.spinics.net/lists/linux-mm/msg16364.html

We'll have to make sure we only have one copy of this in the end.

-- Dave

--
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 05/12] mm: alloc_contig_range() added

2011-03-31 Thread Dave Hansen

On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
 +   ret = 0;
 +   while (!PageBuddy(pfn_to_page(start  (~0UL  ret
 +   if (WARN_ON(++ret = MAX_ORDER))
 +   return -EINVAL; 

Holy cow, that's dense.  Is there really no more straightforward way to
do that?

In any case, please pull the ++ret bit out of the WARN_ON().  Some
people like to do:

#define WARN_ON(...) do{}while(0)

to save space on some systems.  

-- Dave

--
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 05/12] mm: alloc_contig_range() added

2011-03-31 Thread Michal Nazarewicz


On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:

+   ret = 0;
+   while (!PageBuddy(pfn_to_page(start  (~0UL  ret
+   if (WARN_ON(++ret = MAX_ORDER))
+   return -EINVAL;


On Thu, 31 Mar 2011 18:02:41 +0200, Dave Hansen wrote:

Holy cow, that's dense.  Is there really no more straightforward way to
do that?


Which part exactly is dense?  What would be qualify as a more
straightforward way?


In any case, please pull the ++ret bit out of the WARN_ON().  Some
people like to do:

#define WARN_ON(...) do{}while(0)

to save space on some systems.


I don't think that's the case.  Even if WARN_ON() decides not to print
a warning, it will still return the value of the argument.  If not,
a lot of code will brake.

--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michal mina86 Nazarewicz(o o)
ooo +-email/xmpp: mnazarew...@google.com-ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/12] mm: alloc_contig_range() added

2011-03-31 Thread Dave Hansen

On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
 +   _start = start  (~0UL  ret);
 +   _end   = alloc_contig_freed_pages(_start, end, flag); 

These names are a wee bit lacking.  Care to give them proper names that
might let a reader figure out how the _ makes the variable different
from its nearly-identical twin?

-- Dave

--
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: [w_scan PATCH] Add Brazil support on w_scan

2011-03-31 Thread handygewinnspiel


 Em 29-03-2011 20:21, Mauro Carvalho Chehab escreveu:
  Em 29-03-2011 17:11, handygewinnsp...@gmx.de escreveu:
  So I changed it now to scan any srate for 6MHz networks, but skip over
 those which are unsupported by bandwidth limitation.
 ...
  Anyway, I'll test the today's version and reply if I detect any troubles
 on it.
 
 Test results:
 
   $ ./w_scan -c BR -fc 
 Took about 30 mins for scan. As the board I'm using doesn't support
 QAM_AUTO
 for DVB-C, it seek only QAM_64

This is unexpected  should be fixed to fit to w_scan's default behaviour: 
first QAM_64, then QAM_256.

Can you pls re-check with the following change in countries.c line 500ff

/*
 * start/stop values for dvbc qam loop
 * 0 == QAM_64, 1 == QAM_256, 2 == QAM_128
 */
int dvbc_qam_max(int channel, int channellist) {
switch(channellist) {
   case DVBC_FI:return 2; //QAM128
+  case DVBC_BR:
   case DVBC_FR:
   case DVBC_QAM:   return 1; //QAM256
   default: return 0; //no qam loop
   }
}


int dvbc_qam_min(int channel, int channellist) {
switch(channellist) {
   case DVBC_FI:
+  case DVBC_BR:
   case DVBC_FR:
   case DVBC_QAM:   return 0; //QAM64
   default: return 0; //no qam loop
   }
}

I don't think that adding QAM_128 makes sense. Later, if i have more reports 
from 6MHz network users, i will reduce the number of symbol rates.
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 dvb-apps] Fix scan handling for EN 300468 charsets

2011-03-31 Thread Mauro Carvalho Chehab

It always bothered me that scan tables produced in Brazil
were full of reverse interrogation pseudo-chars, displayed
when some code violates UTF-8 charset.

This is due to the lack of properly interpreting the service provider
and service name charsets. There's a FIXME suggesting to use glibc
standard iconv functions in order to handle them.

According with EN 300 468, the first char (or the first 3 chars) may
specify the code to be used if they are different than code table 00
(Latin, ISO-6937 variant), and if the first character is  0x20.

Unfortunately, not all DVB operators hounor it, so an extra parameter
were added to allow overriding.

However, at least here, the DVB-C operator doesn't honour the
charset table selection.

Due to that, a new option were added to scan, allowing to override
the charset default. So, in the case of Brazil, using a:
-C ISO-8859-1
parameter, will properly produce the right channel description.

The specs allow the usage of certain control character sequences.
This is honoured by the descriptorcpy() function, for 1-byte char
tables (iso-8859 and iso-6937 tables).

Since I don't have access to dual-byte charset signals, I wouldn't
be able to test the conversions for iso-10646 table. So, I opted to
not handle 2-byte control chars (just like the previous code), but
it should be easy to do it, if someone is interested on doing it.

The code will output data by default in UTF-8 format, as this is
the charset used by modern distros, but user can use the -D option
to change the output to any other charset supported by iconv.
The supported charsets are given by:
$ iconv -l

One interesting usage would be to force the output to ASCII, like:
-D ASCII

As iconv is part of glibc, it should be available on any glibc-based
distribution. The iconv library is also present on other xNIX flavors.

As a future suggestion, someone could use LANG and LC_MESSAGES environment
vars to set the default for the output format.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

---

v2: Properly handle 1-char control codes and EN 300 468 iso-6937 variant,
and allow controlling the output charset.

 scan.c |  487 +++--
 1 file changed, 444 insertions(+), 43 deletions(-)

diff --git a/util/scan/scan.c b/util/scan/scan.c
--- a/util/scan/scan.c
+++ b/util/scan/scan.c
@@ -33,6 +33,7 @@
 #include assert.h
 #include glob.h
 #include ctype.h
+#include iconv.h
 
 #include linux/dvb/frontend.h
 #include linux/dvb/dmx.h
@@ -67,6 +68,10 @@ static int vdr_version = 3;
 static struct lnb_types_st lnb_type;
 static int unique_anon_services;
 
+char *default_charset = ISO-6937;
+char *output_charset = UTF-8;
+#define CS_OPTIONS //TRANSLIT
+
 static enum fe_spectral_inversion spectral_inversion = INVERSION_AUTO;
 
 enum table_type {
@@ -543,60 +548,447 @@ static void parse_frequency_list_descrip
}
 }
 
+/*
+ * handle character set correctly (e.g. via iconv)
+ *   c.f. EN 300 468 annex A
+ */
+
+struct charset_conv {
+   unsigned len;
+   unsigned char  data[3];
+};
+
+/* This table is the Latin 00 table. Basically ISO-6937 + Euro sign */
+struct charset_conv en300468_latin_00_to_utf8[256] = {
+   [0x00] = { 1, {0x00, } },
+   [0x01] = { 1, {0x01, } },
+   [0x02] = { 1, {0x02, } },
+   [0x03] = { 1, {0x03, } },
+   [0x04] = { 1, {0x04, } },
+   [0x05] = { 1, {0x05, } },
+   [0x06] = { 1, {0x06, } },
+   [0x07] = { 1, {0x07, } },
+   [0x08] = { 1, {0x08, } },
+   [0x09] = { 1, {0x09, } },
+   [0x0a] = { 1, {0x0a, } },
+   [0x0b] = { 1, {0x0b, } },
+   [0x0c] = { 1, {0x0c, } },
+   [0x0d] = { 1, {0x0d, } },
+   [0x0e] = { 1, {0x0e, } },
+   [0x0f] = { 1, {0x0f, } },
+   [0x10] = { 1, {0x10, } },
+   [0x11] = { 1, {0x11, } },
+   [0x12] = { 1, {0x12, } },
+   [0x13] = { 1, {0x13, } },
+   [0x14] = { 1, {0x14, } },
+   [0x15] = { 1, {0x15, } },
+   [0x16] = { 1, {0x16, } },
+   [0x17] = { 1, {0x17, } },
+   [0x18] = { 1, {0x18, } },
+   [0x19] = { 1, {0x19, } },
+   [0x1a] = { 1, {0x1a, } },
+   [0x1b] = { 1, {0x1b, } },
+   [0x1c] = { 1, {0x1c, } },
+   [0x1d] = { 1, {0x1d, } },
+   [0x1e] = { 1, {0x1e, } },
+   [0x1f] = { 1, {0x1f, } },
+   [0x20] = { 1, {0x20, } },
+   [0x21] = { 1, {0x21, } },
+   [0x22] = { 1, {0x22, } },
+   [0x23] = { 1, {0x23, } },
+   [0x24] = { 1, {0x24, } },
+   [0x25] = { 1, {0x25, } },
+   [0x26] = { 1, {0x26, } },
+   [0x27] = { 1, {0x27, } },
+   [0x28] = { 1, {0x28, } },
+   [0x29] = { 1, {0x29, } },
+   [0x2a] = { 1, {0x2a, } },
+   [0x2b] = { 1, {0x2b, } },
+   [0x2c] = { 1, {0x2c, } },
+   [0x2d] = { 1, {0x2d, } },
+   [0x2e] = { 1, {0x2e, } },
+   [0x2f] = { 1, {0x2f, } },
+   [0x30] = { 1, {0x30, } },
+   [0x31] = { 1, {0x31, } },
+   [0x32] = { 1, {0x32, } },
+   [0x33] = {

[cron job] v4l-dvb daily build: ERRORS

2011-03-31 Thread 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:Thu Mar 31 19:00:30 CEST 2011
git hash:b328817a2a391d1e879c4252cd3f11a352d3f3bc
gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: OK
linux-git-armv5-davinci: OK
linux-git-armv5-ixp: OK
linux-git-armv5-omap2: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-x86_64: OK
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: ERRORS
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.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: ERRORS
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
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification from this daily build is here:

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

Re: [PATCH 04/12] mm: alloc_contig_freed_pages() added

2011-03-31 Thread Steven Rostedt

On Thu, Mar 31, 2011 at 08:58:03AM -0700, Dave Hansen wrote:
 On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
  
  +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));
 
 This seems kinda mean.  Could we return an error?  I understand that
 this is largely going to be an early-boot thing, but surely trying to
 punt on crappy input beats a full-on BUG().
 
   if (!pfn_valid(start))
   return -1;

But still keep the warning?

if (WARN_ON(!pfn_valid(start))
return -1;

-- Steve

--
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 05/12] mm: alloc_contig_range() added

2011-03-31 Thread Steven Rostedt

On Thu, Mar 31, 2011 at 09:02:41AM -0700, Dave Hansen wrote:
 On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
  +   ret = 0;
  +   while (!PageBuddy(pfn_to_page(start  (~0UL  ret
  +   if (WARN_ON(++ret = MAX_ORDER))
  +   return -EINVAL; 
 
 Holy cow, that's dense.  Is there really no more straightforward way to
 do that?
 
 In any case, please pull the ++ret bit out of the WARN_ON().  Some
 people like to do:
 
 #define WARN_ON(...) do{}while(0)
 
 to save space on some systems.  

That should be fixed, as the if (WARN_ON()) has become a standard in
most of the kernel. Removing WARN_ON() should be:

#define WARN_ON(x) ({0;})

But I agree, that there should be no side effects inside a WARN_ON(),
which that ++ret is definitely one.

-- Steve

--
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 05/12] mm: alloc_contig_range() added

2011-03-31 Thread Steven Rostedt

On Thu, Mar 31, 2011 at 06:26:45PM +0200, Michal Nazarewicz wrote:
 In any case, please pull the ++ret bit out of the WARN_ON().  Some
 people like to do:
 
 #define WARN_ON(...) do{}while(0)
 
 to save space on some systems.
 
 I don't think that's the case.  Even if WARN_ON() decides not to print
 a warning, it will still return the value of the argument.  If not,
 a lot of code will brake.


WARN_ON() should never do anything but test. That ret++ does not belong
inside the WARN_ON() condition. If there are other locations in the
kernel that do that, then those locations need to be fixed.

-- Steve

--
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: [w_scan PATCH] Add Brazil support on w_scan

2011-03-31 Thread Mauro Carvalho Chehab

Em 31-03-2011 14:15, handygewinnsp...@gmx.de escreveu:
 
 Em 29-03-2011 20:21, Mauro Carvalho Chehab escreveu:
 Em 29-03-2011 17:11, handygewinnsp...@gmx.de escreveu:
 So I changed it now to scan any srate for 6MHz networks, but skip over
 those which are unsupported by bandwidth limitation.
 ...
 Anyway, I'll test the today's version and reply if I detect any troubles
 on it.

 Test results:

  $ ./w_scan -c BR -fc 
 Took about 30 mins for scan. As the board I'm using doesn't support
 QAM_AUTO
 for DVB-C, it seek only QAM_64
 
 This is unexpected  should be fixed to fit to w_scan's default behaviour: 
 first QAM_64, then QAM_256.
 
 Can you pls re-check with the following change in countries.c line 500ff
 
 /*
  * start/stop values for dvbc qam loop
  * 0 == QAM_64, 1 == QAM_256, 2 == QAM_128
  */
 int dvbc_qam_max(int channel, int channellist) {
 switch(channellist) {
case DVBC_FI:return 2; //QAM128
 +  case DVBC_BR:
case DVBC_FR:
case DVBC_QAM:   return 1; //QAM256
default: return 0; //no qam loop
}
 }
 
 
 int dvbc_qam_min(int channel, int channellist) {
 switch(channellist) {
case DVBC_FI:
 +  case DVBC_BR:
case DVBC_FR:
case DVBC_QAM:   return 0; //QAM64
default: return 0; //no qam loop
}
 }
 
 I don't think that adding QAM_128 makes sense.

Agreed
 Later, if i have more reports from 6MHz network users, i will reduce the 
 number of symbol rates.

Ok.

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

Re: [w_scan PATCH] Add Brazil support on w_scan

2011-03-31 Thread Mauro Carvalho Chehab

Em 31-03-2011 16:50, Mauro Carvalho Chehab escreveu:
 Em 31-03-2011 14:15, handygewinnsp...@gmx.de escreveu:

 Em 29-03-2011 20:21, Mauro Carvalho Chehab escreveu:
 Em 29-03-2011 17:11, handygewinnsp...@gmx.de escreveu:
 So I changed it now to scan any srate for 6MHz networks, but skip over
 those which are unsupported by bandwidth limitation.
 ...
 Anyway, I'll test the today's version and reply if I detect any troubles
 on it.

 Test results:

 $ ./w_scan -c BR -fc 
 Took about 30 mins for scan. As the board I'm using doesn't support
 QAM_AUTO
 for DVB-C, it seek only QAM_64

 This is unexpected  should be fixed to fit to w_scan's default behaviour: 
 first QAM_64, then QAM_256.

 Can you pls re-check with the following change in countries.c line 500ff

 /*
  * start/stop values for dvbc qam loop
  * 0 == QAM_64, 1 == QAM_256, 2 == QAM_128
  */
 int dvbc_qam_max(int channel, int channellist) {
 switch(channellist) {
case DVBC_FI:return 2; //QAM128
 +  case DVBC_BR:
case DVBC_FR:
case DVBC_QAM:   return 1; //QAM256
default: return 0; //no qam loop
}
 }

 
 int dvbc_qam_min(int channel, int channellist) {
 switch(channellist) {
case DVBC_FI:
 +  case DVBC_BR:
case DVBC_FR:
case DVBC_QAM:   return 0; //QAM64
default: return 0; //no qam loop
}
 }

Forgot to comment: the above fixed w_scan probe with default parameters.

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

Re: [PATCH 05/12] mm: alloc_contig_range() added

2011-03-31 Thread Michal Nazarewicz


On Thu, 31 Mar 2011 21:28:21 +0200, Steven Rostedt wrote:

WARN_ON() should never do anything but test. That ret++ does not belong
inside the WARN_ON() condition. If there are other locations in the
kernel that do that, then those locations need to be fixed.


Testing implies evaluating, so if we allow:

if (++i == end) { /* ... */ }

I see no reason why not to allow:

if (WARN_ON(++i == end)) { /* ... */ }

In both cases the condition is tested.


On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:

+   ret = 0;
+   while (!PageBuddy(pfn_to_page(start  (~0UL  ret
+   if (WARN_ON(++ret = MAX_ORDER))
+   return -EINVAL;



On Thu, Mar 31, 2011 at 09:02:41AM -0700, Dave Hansen wrote:

In any case, please pull the ++ret bit out of the WARN_ON().  Some
people like to do:

#define WARN_ON(...) do{}while(0)

to save space on some systems.


On Thu, 31 Mar 2011 21:26:50 +0200, Steven Rostedt wrote:

That should be fixed, as the if (WARN_ON()) has become a standard in
most of the kernel. Removing WARN_ON() should be:

#define WARN_ON(x) ({0;})


This would break a lot of code which expect that testing to take place.
Also see http://lxr.linux.no/linux+*/include/asm-generic/bug.h#L108.


But I agree, that there should be no side effects inside a WARN_ON(),
which that ++ret is definitely one.


Thus I don't really agree with this point.

At any rate, I don't really care.

--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michal mina86 Nazarewicz(o o)
ooo +-email/xmpp: mnazarew...@google.com-ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 05/12] mm: alloc_contig_range() added

2011-03-31 Thread Dave Hansen

On Thu, 2011-03-31 at 18:26 +0200, Michal Nazarewicz wrote:
  On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
  +   ret = 0;
  +   while (!PageBuddy(pfn_to_page(start  (~0UL  ret
  +   if (WARN_ON(++ret = MAX_ORDER))
  +   return -EINVAL;
 
 On Thu, 31 Mar 2011 18:02:41 +0200, Dave Hansen wrote:
  Holy cow, that's dense.  Is there really no more straightforward way to
  do that?
 
 Which part exactly is dense?  What would be qualify as a more
 straightforward way?

I'm still not 100% sure what it's trying to do.  It looks like it
attempts to check all of start's buddy pages.

unsigned long find_buddy(unsigned long pfn, int buddy)
{
unsigned long page_idx = pfn  ((1  MAX_ORDER) - 1); // You had a 
macro for this I think
unsigned long buddy_idx = __find_buddy_index(page_idx, order);
return page_idx + buddy_idx;
}

Is something like this equivalent?

int order;
for (order = 0; order = MAX_ORDER; order++) {
unsigned long buddy_pfn = find_buddy(start, order);
struct page *buddy = pfn_to_page(buddy_pfn);
if (PageBuddy(buddy)
break;
WARN();
return -EINVAL;
}

I'm wondering also if you can share some code with __rmqueue().

  In any case, please pull the ++ret bit out of the WARN_ON().  Some
  people like to do:
 
  #define WARN_ON(...) do{}while(0)
 
  to save space on some systems.
 
 I don't think that's the case.  Even if WARN_ON() decides not to print
 a warning, it will still return the value of the argument.  If not,
 a lot of code will brake.

Bah, sorry.  I'm confusing WARN_ON() and WARN().

-- Dave

--
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 04/12] mm: alloc_contig_freed_pages() added

2011-03-31 Thread Dave Hansen

On Thu, 2011-03-31 at 15:24 -0400, Steven Rostedt wrote:
 On Thu, Mar 31, 2011 at 08:58:03AM -0700, Dave Hansen wrote:
  On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
   
   +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));
  
  This seems kinda mean.  Could we return an error?  I understand that
  this is largely going to be an early-boot thing, but surely trying to
  punt on crappy input beats a full-on BUG().
  
  if (!pfn_valid(start))
  return -1;
 
 But still keep the warning?
 
   if (WARN_ON(!pfn_valid(start))
   return -1;

Sure.  You might also want to make sure you're respecting __GFP_NOWARN
if you're going to do that, or maybe just warn once per boot.


-- Dave

--
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 04/12] mm: alloc_contig_freed_pages() added

2011-03-31 Thread Michal Nazarewicz

On Thu, 31 Mar 2011 17:58:03 +0200, Dave Hansen d...@linux.vnet.ibm.com  
wrote:



On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:


+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));


This seems kinda mean.  Could we return an error?  I understand that
this is largely going to be an early-boot thing, but surely trying to
punt on crappy input beats a full-on BUG().


Actually, I would have to check but I think that the usage of this function
(in this patchset) is that the caller expects the function to succeed.  It  
is
quite a low-level function so before running it a lot of preparation is  
needed
and the caller must make sure that several conditions are met.  I don't  
really

see advantage of returning a value rather then BUG()ing.

Also, CMA does not call this function at boot time.

--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michal mina86 Nazarewicz(o o)
ooo +-email/xmpp: mnazarew...@google.com-ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/12] mm: alloc_contig_freed_pages() added

2011-03-31 Thread Dave Hansen

On Thu, 2011-03-31 at 23:09 +0200, Michal Nazarewicz wrote:
 On Thu, 31 Mar 2011 17:58:03 +0200, Dave Hansen d...@linux.vnet.ibm.com  
 wrote:
  On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
  +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));
 
  This seems kinda mean.  Could we return an error?  I understand that
  this is largely going to be an early-boot thing, but surely trying to
  punt on crappy input beats a full-on BUG().
 
 Actually, I would have to check but I think that the usage of this function
 (in this patchset) is that the caller expects the function to succeed.  It  
 is quite a low-level function so before running it a lot of preparation is  
 needed and the caller must make sure that several conditions are met.  I 
 don't  
 really see advantage of returning a value rather then BUG()ing.
 
 Also, CMA does not call this function at boot time.

We BUG_ON() in bootmem.  Basically if we try to allocate an early-boot
structure and fail, we're screwed.  We can't keep running without an
inode hash, or a mem_map[].

This looks like it's going to at least get partially used in drivers, at
least from the examples.  Are these kinds of things that, if the driver
fails to load, that the system is useless and hosed?  Or, is it
something where we might limp along to figure out what went wrong before
we reboot?

-- Dave

--
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 05/12] mm: alloc_contig_range() added

2011-03-31 Thread Michal Nazarewicz

On Thu, 31 Mar 2011 22:28:42 +0200, Dave Hansen d...@linux.vnet.ibm.com  
wrote:



On Thu, 2011-03-31 at 18:26 +0200, Michal Nazarewicz wrote:

 On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:
 +   ret = 0;
 +   while (!PageBuddy(pfn_to_page(start  (~0UL  ret
 +   if (WARN_ON(++ret = MAX_ORDER))
 +   return -EINVAL;

On Thu, 31 Mar 2011 18:02:41 +0200, Dave Hansen wrote:
 Holy cow, that's dense.  Is there really no more straightforward way  
to

 do that?

Which part exactly is dense?  What would be qualify as a more
straightforward way?


I'm still not 100% sure what it's trying to do.  It looks like it
attempts to check all of start's buddy pages.


No.  I'm going up through parents.  This is because even though start
falls in a free block (ie. one that page allocator tracks), the actual
page that is in buddy system is larger then start and this loop looks
for beginning of that page.


int order;
for (order = 0; order = MAX_ORDER; order++) {
unsigned long buddy_pfn = find_buddy(start, order);
struct page *buddy = pfn_to_page(buddy_pfn);
if (PageBuddy(buddy)
break;
WARN();
return -EINVAL;
}


The WARN() and return would have to be outside of the loop and, as I
described, instead of find_buddy() something like find_parent() would
have to be used.


I'm wondering also if you can share some code with __rmqueue().


Doubtful since start does not (have to) point to a page that is tracked
by page allocator but a page inside such a page.

--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michal mina86 Nazarewicz(o o)
ooo +-email/xmpp: mnazarew...@google.com-ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] Pinnacle PCTV Dual DVB-T Pro PCI 2000i

2011-03-31 Thread Marc Coevoet


Op 31-03-11 23:45, pigeonskil...@libero.it schreef:

Sorry for the outburst.
A user wishing to migrate to Linux.


Migrate?  kill Pigeons?


You can take a look at logs from your device on linuxtv.org.


Marc

--
What's on Shortwave guide: choose an hour, go!
http://shortwave.tk
700+ Radio Stations on SW http://swstations.tk
300+ languages on SW http://radiolanguages.tk

--
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 04/12] mm: alloc_contig_freed_pages() added

2011-03-31 Thread Michal Nazarewicz


On Thu, 2011-03-31 at 15:16 +0200, Marek Szyprowski wrote:

+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));


On Thu, 31 Mar 2011 23:14:38 +0200, Dave Hansen wrote:

We BUG_ON() in bootmem.  Basically if we try to allocate an early-boot
structure and fail, we're screwed.  We can't keep running without an
inode hash, or a mem_map[].

This looks like it's going to at least get partially used in drivers, at
least from the examples.  Are these kinds of things that, if the driver
fails to load, that the system is useless and hosed?  Or, is it
something where we might limp along to figure out what went wrong before
we reboot?


Bug in the above place does not mean that we could not allocate memory.  It
means caller is broken.

--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michal mina86 Nazarewicz(o o)
ooo +-email/xmpp: mnazarew...@google.com-ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/12] mm: alloc_contig_freed_pages() added

2011-03-31 Thread Dave Hansen

On Fri, 2011-04-01 at 00:18 +0200, Michal Nazarewicz wrote:
 On Thu, 31 Mar 2011 23:14:38 +0200, Dave Hansen wrote:
  We BUG_ON() in bootmem.  Basically if we try to allocate an early-boot
  structure and fail, we're screwed.  We can't keep running without an
  inode hash, or a mem_map[].
 
  This looks like it's going to at least get partially used in drivers, at
  least from the examples.  Are these kinds of things that, if the driver
  fails to load, that the system is useless and hosed?  Or, is it
  something where we might limp along to figure out what went wrong before
  we reboot?
 
 Bug in the above place does not mean that we could not allocate memory.  It
 means caller is broken.

Could you explain that a bit?

Is this a case where a device is mapped to a very *specific* range of
physical memory and no where else?  What are the reasons for not marking
it off limits at boot?  I also saw some bits of isolation and migration
in those patches.  Can't the migration fail?  

-- Dave

--
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 04/12] mm: alloc_contig_freed_pages() added

2011-03-31 Thread Michal Nazarewicz

On Fri, 01 Apr 2011 00:26:51 +0200, Dave Hansen d...@linux.vnet.ibm.com  
wrote:



On Fri, 2011-04-01 at 00:18 +0200, Michal Nazarewicz wrote:

On Thu, 31 Mar 2011 23:14:38 +0200, Dave Hansen wrote:
 We BUG_ON() in bootmem.  Basically if we try to allocate an early-boot
 structure and fail, we're screwed.  We can't keep running without an
 inode hash, or a mem_map[].

 This looks like it's going to at least get partially used in drivers,  
at
 least from the examples.  Are these kinds of things that, if the  
driver

 fails to load, that the system is useless and hosed?  Or, is it
 something where we might limp along to figure out what went wrong  
before

 we reboot?

Bug in the above place does not mean that we could not allocate  
memory.  It means caller is broken.


Could you explain that a bit?

Is this a case where a device is mapped to a very *specific* range of
physical memory and no where else?  What are the reasons for not marking
it off limits at boot?  I also saw some bits of isolation and migration
in those patches.  Can't the migration fail?


The function is called from alloc_contig_range() (see patch 05/12) which
makes sure that the PFN is valid.  Situation where there is not enough
space is caught earlier in alloc_contig_range().

alloc_contig_freed_pages() must be given a valid PFN range such that all
the pages in that range are free (as in are within the region tracked by
page allocator) and of MIGRATETYPE_ISOLATE so that page allocator won't
touch them.

That's why invalid PFN is a bug in the caller and not an exception that
has to be handled.

Also, the function is not called during boot time.  It is called while
system is already running.

--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michal mina86 Nazarewicz(o o)
ooo +-email/xmpp: mnazarew...@google.com-ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/19] timberdale: mfd_cell is now implicitly available to drivers

2011-03-31 Thread Grant Likely

On Wed, Feb 02, 2011 at 08:08:12PM -0800, Andres Salomon wrote:
 
 No need to explicitly set the cell's platform_data/data_size.
 
 In this case, move the various platform_data pointers
 to driver_data.  All of the clients which make use of it
 are also changed.
 
 Signed-off-by: Andres Salomon dilin...@queued.net
 ---
  drivers/dma/timb_dma.c   |2 +-
  drivers/gpio/timbgpio.c  |5 +-
  drivers/i2c/busses/i2c-ocores.c  |2 +-
  drivers/i2c/busses/i2c-xiic.c|2 +-
  drivers/media/radio/radio-timb.c |2 +-
  drivers/media/video/timblogiw.c  |2 +-
  drivers/mfd/timberdale.c |   81 
 +-
  drivers/net/ks8842.c |2 +-
  drivers/spi/xilinx_spi.c |2 +-
  9 files changed, 36 insertions(+), 64 deletions(-)
 
 diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
 index 3b88a4e..aa06ca4 100644
 --- a/drivers/dma/timb_dma.c
 +++ b/drivers/dma/timb_dma.c
 @@ -684,7 +684,7 @@ static irqreturn_t td_irq(int irq, void *devid)
  
  static int __devinit td_probe(struct platform_device *pdev)
  {
 - struct timb_dma_platform_data *pdata = pdev-dev.platform_data;
 + struct timb_dma_platform_data *pdata = platform_get_drvdata(pdev);

Hold the phone.  I know this has already been merged, but this isn't correct.

drvdata is under the ownership of the driver, which means it should
*not* be set when .probe() gets called.  It is for driver private data
to do with as it needs, usually for internal state.

Gah.  Not all devices instantiated via mfd will be an mfd device,
which means that the driver may very well expect an *entirely
different* platform_device pointer; which further means a very high
potential of incorrectly dereferenced structures (as evidenced by a
patch series that is not bisectable).  For instance, the xilinx ip
cores are used by more than just mfd.

This is really bad.  Since this is new in .39-rc1, I really think this
series needs to be reverted.  Samuel, can you look at this please?

g.


   struct timb_dma *td;
   struct resource *iomem;
   int irq;
 diff --git a/drivers/gpio/timbgpio.c b/drivers/gpio/timbgpio.c
 index 58c8f30..e404487 100644
 --- a/drivers/gpio/timbgpio.c
 +++ b/drivers/gpio/timbgpio.c
 @@ -228,7 +228,7 @@ static int __devinit timbgpio_probe(struct 
 platform_device *pdev)
   struct gpio_chip *gc;
   struct timbgpio *tgpio;
   struct resource *iomem;
 - struct timbgpio_platform_data *pdata = pdev-dev.platform_data;
 + struct timbgpio_platform_data *pdata = platform_get_drvdata(pdev);
   int irq = platform_get_irq(pdev, 0);
  
   if (!pdata || pdata-nr_pins  32) {
 @@ -319,14 +319,13 @@ err_mem:
  static int __devexit timbgpio_remove(struct platform_device *pdev)
  {
   int err;
 - struct timbgpio_platform_data *pdata = pdev-dev.platform_data;
   struct timbgpio *tgpio = platform_get_drvdata(pdev);
   struct resource *iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
   int irq = platform_get_irq(pdev, 0);
  
   if (irq = 0  tgpio-irq_base  0) {
   int i;
 - for (i = 0; i  pdata-nr_pins; i++) {
 + for (i = 0; i  tgpio-gpio.ngpio; i++) {
   set_irq_chip(tgpio-irq_base + i, NULL);
   set_irq_chip_data(tgpio-irq_base + i, NULL);
   }
 diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
 index ef3bcb1..dc203ec 100644
 --- a/drivers/i2c/busses/i2c-ocores.c
 +++ b/drivers/i2c/busses/i2c-ocores.c
 @@ -305,7 +305,7 @@ static int __devinit ocores_i2c_probe(struct 
 platform_device *pdev)
   return -EIO;
   }
  
 - pdata = pdev-dev.platform_data;
 + pdata = platform_get_drvdata(pdev);
   if (pdata) {
   i2c-regstep = pdata-regstep;
   i2c-clock_khz = pdata-clock_khz;
 diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
 index a9c419e..830b8c1 100644
 --- a/drivers/i2c/busses/i2c-xiic.c
 +++ b/drivers/i2c/busses/i2c-xiic.c
 @@ -704,7 +704,7 @@ static int __devinit xiic_i2c_probe(struct 
 platform_device *pdev)
   if (irq  0)
   goto resource_missing;
  
 - pdata = (struct xiic_i2c_platform_data *) pdev-dev.platform_data;
 + pdata = platform_get_drvdata(pdev);
   if (!pdata)
   return -EINVAL;
  
 diff --git a/drivers/media/radio/radio-timb.c 
 b/drivers/media/radio/radio-timb.c
 index a185610..e7baf26 100644
 --- a/drivers/media/radio/radio-timb.c
 +++ b/drivers/media/radio/radio-timb.c
 @@ -148,7 +148,7 @@ static const struct v4l2_file_operations timbradio_fops = 
 {
  
  static int __devinit timbradio_probe(struct platform_device *pdev)
  {
 - struct timb_radio_platform_data *pdata = pdev-dev.platform_data;
 + struct timb_radio_platform_data *pdata = platform_get_drvdata(pdev);
   struct timbradio *tr;
   int err;
  
 diff --git a/drivers/media/video/timblogiw.c

Re: v4l: Buffer pools

2011-03-31 Thread Laurent Pinchart

Hi everybody,

Here are the requirements of the OMAP3 ISP (Image Signal Processor) regarding 
a global buffers pool. I've tried to expand the list of requirements to take 
the OMAP3 DSP and DSS (Display SubSystem) into account, but I have less 
experience with those subsystems. The list might thus not be exhaustive.

Sakari, could you please check if you see something missing from the list ?

- Memory allocation (ISP and DSP)

The ISP and DSP both use an IOMMU to access system memory. The MMUs can access 
the whole 32-bit physical address space without any restriction through 4kB or 
64kB pages, 1MB sections and 16MB supersections.

No hardware requirement needs to be enforced by the allocator, but better 
performances can be achieved if the memory is not fragmented down to page 
level.

Memory is allocated and freed at runtime. Allocation is an expensive operation 
and needs to be performed in advanced, before the memory gets used by the ISP 
and DSP drivers or devices.

- Memory allocation (DSS)

The DSS needs physically contiguous memory. The memory base address needs to 
be aligned to a pixel boundary.

Memory for framebuffer devices is allocated when the device is probed and kept 
until the device is removed or the driver unloaded. Memory for V4L2 video 
output devices is allocated and freed at runtime.

- Alignment and padding (ISP)

ISP buffers must be aligned on a 32 or 64 bytes boundary, depending on the ISP 
module that reads from or writes to memory. A 256 bytes alignment is 
preferable to achieve better performances.

Line stride (the number of bytes between the first pixel of two consecutive 
lines) must be a multiple of 32 or 64 bytes and can be larger than the line 
length. This results in padding at the end of each line (optional if the line 
length is already a multiple of 32 or 64 bytes). Padding bytes are not written 
to by the ISP, and their values are ignored when the ISP reads from memory.

To achieve interoperability with the ISP, other hardware modules need to take 
the ISP line stride requirements into account. This is likely out of scope of 
the buffer pool though.

- Cache management (ISP and DSS)

Cache needs to be synchronized between userspace applications, kernel space 
and hardware. Synchronizing the cache is an expensive operation and should be 
avoided when possible. Userspace applications don't need to select memory 
mapping cache attributes, but should be able to either handle cache 
synchronization explicitly, or override the drivers' default behaviour.

To avoid cache coherency issues caused by speculative prefetching as much as 
possible, no unneeded memory mappings should be present, both for kernelspace 
and userspace.

Cache management operations can be handled either by the buffer pool or by the 
ISP and DSP drivers. In the later case, the drivers need a way to query buffer 
properties to avoid cache synchronization if no cacheable mapping exist for a 
buffer.

- IOMMU mappings (ISP and DSP)

Mapping buffers to the ISP and DSP address spaces through the corresponding 
IOMMUs is a time consuming operation. Drivers need to map the buffers in 
advance before using the memory.

- Multiple use of the same buffer

If images need to be captured directly to the frame buffer, applications might 
need to queue a single buffer multiple times to the ISP capture device to 
avoid buffer queue underruns.

Whether this use case is needed is not known yet (the OMAP Xv implementation 
currently copies images to the frame buffer using a CPU memcpy).

-- 
Regards,

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

Re: [PATCH] media/radio/wl1273: fix build errors

2011-03-31 Thread Mike Frysinger

On Sun, Feb 27, 2011 at 12:51, Randy Dunlap wrote:
 From: Randy Dunlap randy.dun...@oracle.com

 RADIO_WL1273 needs to make sure that the mfd core is built to avoid
 build errors:

 ERROR: mfd_add_devices [drivers/mfd/wl1273-core.ko] undefined!
 ERROR: mfd_remove_devices [drivers/mfd/wl1273-core.ko] undefined!

2.6.38 stable worthy ?

now in mainline as 1b149bbe9156d2eb2afd5a072bd61ad0d4bfaca7 ...
-mike
--
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

47 matches

Mail list logo