Re: SDR FM demodulation

2012-02-10 Thread Alistair Buxton
On 9 February 2012 15:01, Antti Palosaari  wrote:

> Decode it and listen some Finnish speak ;)

Done. grc and output.wav here: http://al.robotfuzz.com/~al/rtl2832/

The trick was realising that the UChar to Float converter does not
adjust it's output to the range -1.0,1.0 that the wideband FM
demodulator block expects as input. Once I figured that out the rest
was easy. Just set the quadrature rate to the samples per second in
the source file, and the decimation to quadrature rate/output sink
rate. The source file appears to be about 2 to 2.2 million samples per
second. Any higher than that and the person speaking sounds like a
chipmunk. Maybe 22050 * 1000 or 1024? Does any Finnish station
broadcast "pips" like the BBC does? That could be used to determine
the actual rate.

-- 
Alistair Buxton
a.j.bux...@gmail.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


Problem with V4L2 IOCTLs since 2.6.39

2012-02-10 Thread Sebastian Kricner

Hello,

there must be made some changes to the V4L2 IOCTLs, also the V4L2 API
since 2.6.39.
Upon starting xawtv, i get following errors:

ioctl: VIDIOC_S_CTRL(id=9963785;value=0): Unpassender IOCTL
(I/O-Control) für das Gerät ioctl: VIDIOC_S_CTRL(id=9963785;value=1):
Unpassender IOCTL (I/O-Control) für das Gerät ioctl:
VIDIOC_S_CTRL(id=9963778;value=30801): Unpassender IOCTL (I/O-Control)
für das Gerät ioctl: VIDIOC_S_CTRL(id=9963776;value=30801): Unpassender
IOCTL (I/O-Control) für das Gerät ioctl:
VIDIOC_S_CTRL(id=9963779;value=30801): Unpassender IOCTL (I/O-Control)
für das Gerät ioctl: VIDIOC_S_CTRL(id=9963777;value=30801): Unpassender
IOCTL (I/O-Control) für das Gerät ioctl:
VIDIOC_S_CTRL(id=9963785;value=0): Unpassender IOCTL (I/O-Control) für
das Gerät

I also have made some application
(http://tuxwave.net/index.php?page=2&subpage=23) using the radio tuner
of a Hauppauge WinTV card, since 2.6.39 i can not request the tuner
range anymore.

Initializing...
Card: BT878 radio (Hauppauge (bt878))
Lowest Frequency: 0 (0 MHz)
Highest Frequency: 0 (0 MHz

The ioctls used by xawtv are related to audio settings
(mute/unmute, volume).

I tried to get more information upon this subject, but to no available.
What changes where made, so that those ioctls fail?

I also was in contact with Verkuil, he mentioned the bug on the tuner
ranges should be fixed in the kernel versions starting the 3. branch.
I am currently useing the 3.2.5 kernel, with no difference so far.

It would be very nice and helpful what changes were made to know how to
fix those issues.

Regards

Sebastian Kricner

--
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: SDR FM demodulation

2012-02-10 Thread David Hagood
On Fri, 2012-02-10 at 21:08 -0500, Andy Walls wrote:
> 
> Randomly checking some of the data with GNUplot, if 2.5 Msps is the
> sampling rate, then the fastest freq I saw was about 50 kHz.
How'd you analyze the data - assume it was baseband I/Q and do an FFT?
If so, and if this was digitized baseband, you should have seen the FM
stereo pilot tone at 19kHz.

If it's digitized IF, you should be able to run it through a rectangular
to polar conversion (compute mag = I^2+Q^2 and phase = arctan(I/Q) (use
a proper 4 quadrant arctan), then compute frequency by the delta between
the phase samples. Mag should be constant, frequency would then be your
audio.


--
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: SDR FM demodulation

2012-02-10 Thread Andy Walls
On Thu, 2012-02-09 at 17:21 +0200, Antti Palosaari wrote:
> On 09.02.2012 17:11, Patrick Boettcher wrote:
> > On Thursday 09 February 2012 16:01:12 Antti Palosaari wrote:
> >> I have taken radio sniffs from FM capable Realtek DVB-T device. Looks
> >> like demodulator ADC samples IF frequency and pass all the sampled
> >> data to the application. Application is then responsible for
> >> decoding that. Device supports DVB-T, FM and DAB. I can guess  both
> >> FM and DAB are demodulated by software.
> >>
> >> Here is 17 second, 83 MB, FM radio sniff:
> >> http://palosaari.fi/linux/v4l-dvb/rtl2832u_fm/
> >> Decode it and listen some Finnish speak ;)
> >>
> >> Could someone help to decode it? I tried GNU Radio, but I failed
> >> likely because I didn't have enough knowledge... GNU Radio and
> >> Octave or Matlab are way to go.
> >
> > For someone to decode it, you would need to give more information about
> > the format of the stream. Like the sampling frequency, the sample-format
> > and then the IF-frequency.
> 
> You can see sampling format easily looking hexdump or open file in 
> Audacity. It is 8bit unsigned samples, 2 channels (I & Q).
> 
> No knowledge about IF... For good guess is to try some general used IFs.
> 
> Sampling freq can be calculated using sample info and the fact it is 
> about 17 sec. sample size = 86919168 Bytes, time 17 sec. 2 channels, 1 
> byte sample => 2556446,11765 sample/sec (~2.5 MHz!)

Randomly checking some of the data with GNUplot, if 2.5 Msps is the
sampling rate, then the fastest freq I saw was about 50 kHz.

Maybe you have an FM compsite baseband signal:
http://en.wikipedia.org/wiki/FM_broadcast#Other_subcarrier_services

If you low pass filter with digital filter with (an equivalent to) a 17
kHz cutoff, you may just be left with the mono L+R channel.

I am assuming the I&Q channels in the data are 8 bit LPCM so

x = (c-128)/128.0 

normalizes an usigned byte sample value c in 0 to 255 to a float value x
in -1.0 to 1.0.

Regards,
Andy

> > I never did something like myself, but from what I saw in gnuradio there
> > should be everything to make a FM-demod based on the data.
> 
> Yes there was a lot of block and those were rather easy to connect using 
> graphical interface (gnuradio-companion). But I don't know exactly what 
> block are needed and what are parameters. I used file-sink => 
> fm-modulator => audio-sink. Likely not enough :i
> 
> Without any earlier experience it is rather challenging. But if there is 
> someone who have done that earlier using USRP SDR he could likely do it 
> easier :)
> 
> regards
> Antti


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


Announcing v4l-utils-0.8.6

2012-02-10 Thread Gregor Jasny
Hi,

I'm happy to announce the release of v4l-utils-0.8.6. It contains mostly
backports from the development branch. The most interesting addition is
the new upside down table matching algorithm targeted at ASUS notebooks.
It will hopefully reduce the upside down table update frequency for
those machines.

Full changelog:

v4l-utils-0.8.6
---
* libv4l changes (0.9.x backports)
  * Add support for libjpeg >= v7
  * Add new matching algorithm for upside down table (gjasny)
  * Add some more laptop models to the upside down devices table
(hdegoede, gjasny)
  * Retry with another frame on JPEG header decode errors (hdegoede)
  * Improved JL2005BCD support (Theodore Kilgore, hdegoede)
  * Set errno to EIO if getting 4 consecutive EAGAIN convert errors
(hdegoede)
  * Make software autowhitebalance converge faster (hdegoede)
  * Add quirk support for forced tinyjpeg fallback (hdegoede)

Go get it here:
http://linuxtv.org/downloads/v4l-utils/v4l-utils-0.8.6.tar.bz2

You can always find the latest developments and the stable branch here:
http://git.linuxtv.org/v4l-utils.git

Thanks,
Gregor

PS: Ubuntu users, you can this version for Oneiric and Precise via the
ppa:libv4l/stable PPA.



signature.asc
Description: OpenPGP digital signature


Re: [PATCH v2 27/31] omap3isp: Configure CSI-2 phy based on platform data

2012-02-10 Thread Sakari Ailus
Hi Sergio,

Thanks for the review!

Aguirre, Sergio wrote:
> On Thu, Feb 2, 2012 at 5:54 PM, Sakari Ailus  wrote:
>> Configure CSI-2 phy based on platform data in the ISP driver. For that, the
>> new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
>> was configured from the board code.
>>
>> Signed-off-by: Sakari Ailus 
>> ---
>>  drivers/media/video/omap3isp/ispcsi2.c   |   10 +++-
>>  drivers/media/video/omap3isp/ispcsiphy.c |   78 
>> ++
>>  drivers/media/video/omap3isp/ispcsiphy.h |2 +
>>  3 files changed, 78 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/media/video/omap3isp/ispcsi2.c 
>> b/drivers/media/video/omap3isp/ispcsi2.c
>> index 9313f7c..e2e3d63 100644
>> --- a/drivers/media/video/omap3isp/ispcsi2.c
>> +++ b/drivers/media/video/omap3isp/ispcsi2.c
>> @@ -1068,7 +1068,13 @@ static int csi2_set_stream(struct v4l2_subdev *sd, 
>> int enable)
>>struct isp_video *video_out = &csi2->video_out;
>>
>>switch (enable) {
>> -   case ISP_PIPELINE_STREAM_CONTINUOUS:
>> +   case ISP_PIPELINE_STREAM_CONTINUOUS: {
>> +   int ret;
>> +
>> +   ret = omap3isp_csiphy_config(isp, sd);
>> +   if (ret < 0)
>> +   return ret;
>> +
>>if (omap3isp_csiphy_acquire(csi2->phy) < 0)
>>return -ENODEV;
>>csi2->use_fs_irq = pipe->do_propagation;
>> @@ -1092,7 +1098,7 @@ static int csi2_set_stream(struct v4l2_subdev *sd, int 
>> enable)
>>csi2_if_enable(isp, csi2, 1);
>>isp_video_dmaqueue_flags_clr(video_out);
>>break;
>> -
>> +   }
>>case ISP_PIPELINE_STREAM_STOPPED:
>>if (csi2->state == ISP_PIPELINE_STREAM_STOPPED)
>>return 0;
>> diff --git a/drivers/media/video/omap3isp/ispcsiphy.c 
>> b/drivers/media/video/omap3isp/ispcsiphy.c
>> index 5be37ce..5d7a6ab 100644
>> --- a/drivers/media/video/omap3isp/ispcsiphy.c
>> +++ b/drivers/media/video/omap3isp/ispcsiphy.c
>> @@ -28,6 +28,8 @@
>>  #include 
>>  #include 
>>
>> +#include "../../../../arch/arm/mach-omap2/control.h"
>> +
>>  #include "isp.h"
>>  #include "ispreg.h"
>>  #include "ispcsiphy.h"
>> @@ -138,15 +140,73 @@ static void csiphy_dphy_config(struct isp_csiphy *phy)
>>isp_reg_writel(phy->isp, reg, phy->phy_regs, ISPCSIPHY_REG1);
>>  }
>>
>> -static int csiphy_config(struct isp_csiphy *phy,
>> -struct isp_csiphy_dphy_cfg *dphy,
>> -struct isp_csiphy_lanes_cfg *lanes)
>> +/*
>> + * TCLK values are OK at their reset values
>> + */
>> +#define TCLK_TERM  0
>> +#define TCLK_MISS  1
>> +#define TCLK_SETTLE14
>> +
>> +int omap3isp_csiphy_config(struct isp_device *isp,
>> +  struct v4l2_subdev *csi2_subdev)
>>  {
>> +   struct isp_csi2_device *csi2 = v4l2_get_subdevdata(csi2_subdev);
>> +   struct isp_pipeline *pipe = to_isp_pipeline(&csi2_subdev->entity);
>> +   struct isp_v4l2_subdevs_group *subdevs = pipe->external->host_priv;
>> +   struct isp_csiphy_dphy_cfg csi2phy;
>> +   int csi2_ddrclk_khz;
>> +   struct isp_csiphy_lanes_cfg *lanes;
>>unsigned int used_lanes = 0;
>>unsigned int i;
>>
>> +   if (subdevs->interface == ISP_INTERFACE_CCP2B_PHY1
>> +   || subdevs->interface == ISP_INTERFACE_CCP2B_PHY2)
>> +   lanes = &subdevs->bus.ccp2.lanecfg;
>> +   else
>> +   lanes = &subdevs->bus.csi2.lanecfg;
>> +
>> +   /* FIXME: Do 34xx / 35xx require something here? */
>> +   if (cpu_is_omap3630()) {
>> +   u32 cam_phy_ctrl = omap_readl(
>> +   OMAP343X_CTRL_BASE + 
>> OMAP3630_CONTROL_CAMERA_PHY_CTRL);
> 
> How about:
>   u32 cam_phy_ctrl = 
> omap_ctrl_readl(OMAP3630_CONTROL_CAMERA_PHY_CTRL);
> ?

Fine for me.

>> +
>> +   /*
>> +* SCM.CONTROL_CAMERA_PHY_CTRL
>> +* - bit[4]: CSIPHY1 data sent to CSIB
>> +* - bit [3:2] : CSIPHY1 config: 00 d-phy, 01/10 ccp2
>> +* - bit [1:0] : CSIPHY2 config: 00 d-phy, 01/10 ccp2
>> +*/
>> +   if (subdevs->interface == ISP_INTERFACE_CCP2B_PHY1)
>> +   cam_phy_ctrl |= 1 << 2;
>> +   else if (subdevs->interface == ISP_INTERFACE_CSI2C_PHY1)
>> +   cam_phy_ctrl &= 1 << 2;
> 
> Shouldn't this be:
>cam_phy_ctrl &= ~(1 << 2);
> ?

Probably yes. This has come directly as it was in the original board
code and might not be entirely correct. It works on the N9 at least.

>> +
>> +   if (subdevs->interface == ISP_INTERFACE_CCP2B_PHY2)
>> +   cam_phy_ctrl |= 1;
>> +   else if (subdevs->interface == ISP_INTERFACE_CSI2A_PHY2)
>> +   cam_phy_ctrl &= 1;
> 
> ... and:
>cam_phy_ctrl &= 

Problems with saa7134 card

2012-02-10 Thread Robert Goldner

Hi everyone,

a few days ago I got an PCI-DVB-T and Radio Capture card. Is a quite old 
(and cheap) Medion card with an ssa7134 chipset. Unfortunally the card 
is not supported by linux (kernel 3.2.5) out-of-the-box. After modprobe 
ssa7134 the following message comes by dmesg:


Linux video capture interface: v2.00
saa7130/34: v4l2 driver version 0 2 17 loaded
saa7134 :00:06.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
saa7134[0]: found at :00:06.0, rev: 1 irq: 17 latency: 32 mmio: 
0x4a105000

saa7134: Board is currently unknown. You might try to use the card=
saa7134: insmod option to specify which board do you have, but this is
saa7134: somewhat risky, as might damage your card. It is better to ask
saa7134: for support at linux-media@vger.kernel.org.
saa7134: The supported cards are:
saa7134: card=0 -> UNKNOWN/GENERIC
saa7134: card=1 -> Proteus Pro [philips reference design] 1131:2001
[...]
saa7134: card=12 -> Medion 7134 16be:0003 16be:5000
[...]
saa7134: card=187 -> Beholder BeholdTV 503 FM 5ace:5030
saa7134[0]: subsystem: 1131:, board: UNKNOWN/GENERIC 
[card=0,autodetected]

saa7134[0]: board init: gpio is 10020
saa7134[0]: Huh, no eeprom present (err=-5)?
saa7134[0]: registered device video0 [v4l2]
saa7134[0]: registered device vbi0


I also used google a litte bit and found some hints to use
modprobe ssa7134 card=12 tuner=63, but it does not look well:


saa7130/34: v4l2 driver version 0 2 17 loaded
saa7134[0]: found at :00:06.0, rev: 1 irq: 17 latency: 32 mmio: 
0x4a105000
saa7134[0]: subsystem: 1131:, board: Medion 7134 [card=12,insmod 
option]

saa7134[0]: board init: gpio is 10020
saa7134[0]: Huh, no eeprom present (err=-5)?
EEPROM read failure
saa7134[0] Tuner type is 63
i2c-core: driver [tuner] using legacy suspend method
i2c-core: driver [tuner] using legacy resume method
tda9887 10-0043: creating new instance
tda9887 10-0043: tda988[5/6/7] found
tuner 10-0043: Tuner 74 found with type(s) Radio TV.
All bytes are equal. It is not a TEA5767
tuner 10-0060: Tuner -1 found with type(s) Radio TV.
tuner-simple 10-0060: creating new instance
tuner-simple 10-0060: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
saa7134[0]: registered device video0 [v4l2]
saa7134[0]: registered device vbi0
saa7134[0]: registered device radio0
dvb_init() allocating 1 frontend
tda10046: chip is not answering. Giving up.
saa7134[0]/dvb: frontend initialization failed


lspci:
Multimedia controller [0480]: Philips Semiconductors SAA7134/SAA7135HL 
Video Broadcast Decoder [1131:7134] (rev 01)

 lspci -d 1131:7134 -vvv
00:06.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL 
Video Broadcast Decoder (rev 01)

Subsystem: Philips Semiconductors Behold TV 403 FM
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium 
>TAbort- SERR- 
Latency: 32 (3750ns min, 9500ns max)
Interrupt: pin A routed to IRQ 17
Region 0: Memory at 4a105000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [40] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)

Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: saa7134


Any hints?

Robert

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


cron job: media_tree daily build: WARNINGS

2012-02-10 Thread Hans Verkuil
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:Fri Feb 10 19:00:16 CET 2012
git hash:59b30294e14fa6a370fdd2bc2921cca1f977ef16
gcc version:  i686-linux-gcc (GCC) 4.6.2
host hardware:x86_64
host os:  3.1-2.slh.1-amd64

linux-git-arm-eabi-enoxys: WARNINGS
linux-git-arm-eabi-omap: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-i686: WARNINGS
linux-3.2.1-i686: WARNINGS
linux-3.3-rc1-i686: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
linux-3.2.1-x86_64: WARNINGS
linux-3.3-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

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

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


Re: General question about IR remote signals from USB DVB tuner

2012-02-10 Thread Tony Houghton
On Fri, 10 Feb 2012 08:34:49 -0800 (PST)
Jan Panteltje  wrote:

> I recently bought a Terratec cinergy S2 USB  HD receiver.
> I got everything working just fine in Linux and get excellent
> reception.
> This thing came with a small remote controller, and I notice
> that the  output of this remote appears as ASCII characters on stdin,
> on any terminal that I open...
> Wrote a small GUI application that sets the input focus to a hidden
> input field, and can process the numbers from this remote that way,
> but of course this only works if the mouse has selected that
> application.
> 
> Thinking about this I think that the driver dumps the received remote
> control characters simply to stdout.

Something fairly low level processes the input events and converts them
to keyboard events. IIRC this happens on the console as well as in X.

> If this is so, does there perhaps exists a /dev/dvb/adapterX/remoteX
> interface in the specs so I could modify that driver to send the codes
> there?

The events can be read from /dev/input/eventX. You can do something like
parse /proc/bus/input/devices to work out which device corresponds to
your remote. The structure of the events etc is defined in
/usr/include/linux/input.h. The EVIOCGRAB ioctl is useful to grab the
events exclusively for your application and stop them appearing on the
console.

I don't know exactly what the fields in input_event are supposed to
mean, and IME their significance can vary with remote and with kernel
version. If you can find more information about this, please send a copy
to me because I'm about to unsubscribe from linux-media. If you can't
find the information you'll probably find it useful to experiment with
the attached python script (treat as Public Domain).
#!/usr/bin/env python

import os
import struct
import sys

SIZEOF_INPUT_EVENT = struct.calcsize('llHHi')
# time (2 * long), type, code, value

quiet = False

def main_loop(fd):
while True:
s = os.read(fd, SIZEOF_INPUT_EVENT)
if len(s) != SIZEOF_INPUT_EVENT:
print >>sys.stderr, "Read %d bytes, expected %d" % \
(len(s), SIZEOF_INPUT_EVENT)
break
[tsec, tusec, type, code, value] = struct.unpack('llHHi', s)
if not quiet or type:
print "T:%10.2f t:%02x c:%02x v:%02x" % \
(tsec + float(tusec) / 100, type, code, value)

def main():
if sys.argv[1] == '-q':
global quiet
quiet = True
filename = sys.argv[2]
else:
filename = sys.argv[1]
fd = os.open(filename, os.O_RDONLY)
main_loop(fd)

if __name__ == '__main__':
main()


RE: [PATCHv19 00/15] Contiguous Memory Allocator

2012-02-10 Thread Marek Szyprowski
Hi Andrew,

On Saturday, January 28, 2012 1:26 AM Andrew Morton wrote:

> These patches don't seem to have as many acked-bys and reviewed-bys as
> I'd expect.  Given the scope and duration of this, it would be useful
> to gather these up.  But please ensure they are real ones - people
> sometimes like to ack things without showing much sign of having
> actually read them.
> 
> Also there is the supreme tag: "Tested-by:.".  Ohad (at least) has been
> testing the code.  Let's mention that.
> 
> 
> The patches do seem to have been going round in ever-decreasing circles
> lately and I think we have decided to merge them (yes?) so we may as well
> get on and do that and sort out remaining issues in-tree.

It looks that the CMA patch series reached the final version - I've just 
posted version 21 a few minutes ago. Most of the patches got acks from either 
Mel or Arnd and the remaining few needs only minor tweaking, but they affect
only CMA users, which we hope to fix once the series is merged. That's why I
would like to ask You to merge these patches to Your tree and finally give
them a try in linux-next kernel.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D 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


[PATCHv21 04/16] mm: compaction: introduce isolate_freepages_range()

2012-02-10 Thread Marek Szyprowski
From: Michal Nazarewicz 

This commit introduces isolate_freepages_range() function which
generalises isolate_freepages_block() so that it can be used on
arbitrary PFN ranges.

isolate_freepages_block() is left with only minor changes.

Signed-off-by: Michal Nazarewicz 
Signed-off-by: Marek Szyprowski 
Acked-by: Mel Gorman 
Tested-by: Rob Clark 
Tested-by: Ohad Ben-Cohen 
Tested-by: Benjamin Gaignard 
---
 mm/compaction.c |  111 ++-
 1 files changed, 93 insertions(+), 18 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 9bbcc53..9fef891 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -54,24 +54,20 @@ static unsigned long release_freepages(struct list_head 
*freelist)
return count;
 }
 
-/* Isolate free pages onto a private freelist. Must hold zone->lock */
-static unsigned long isolate_freepages_block(struct zone *zone,
-   unsigned long blockpfn,
-   struct list_head *freelist)
+/*
+ * Isolate free pages onto a private freelist. Caller must hold zone->lock.
+ * If @strict is true, will abort returning 0 on any invalid PFNs or non-free
+ * pages inside of the pageblock (even though it may still end up isolating
+ * some pages).
+ */
+static unsigned long isolate_freepages_block(unsigned long blockpfn,
+   unsigned long end_pfn,
+   struct list_head *freelist,
+   bool strict)
 {
-   unsigned long zone_end_pfn, end_pfn;
int nr_scanned = 0, total_isolated = 0;
struct page *cursor;
 
-   /* Get the last PFN we should scan for free pages at */
-   zone_end_pfn = zone->zone_start_pfn + zone->spanned_pages;
-   end_pfn = min(blockpfn + pageblock_nr_pages, zone_end_pfn);
-
-   /* Find the first usable PFN in the block to initialse page cursor */
-   for (; blockpfn < end_pfn; blockpfn++) {
-   if (pfn_valid_within(blockpfn))
-   break;
-   }
cursor = pfn_to_page(blockpfn);
 
/* Isolate free pages. This assumes the block is valid */
@@ -79,15 +75,23 @@ static unsigned long isolate_freepages_block(struct zone 
*zone,
int isolated, i;
struct page *page = cursor;
 
-   if (!pfn_valid_within(blockpfn))
+   if (!pfn_valid_within(blockpfn)) {
+   if (strict)
+   return 0;
continue;
+   }
nr_scanned++;
 
-   if (!PageBuddy(page))
+   if (!PageBuddy(page)) {
+   if (strict)
+   return 0;
continue;
+   }
 
/* Found a free page, break it into order-0 pages */
isolated = split_free_page(page);
+   if (!isolated && strict)
+   return 0;
total_isolated += isolated;
for (i = 0; i < isolated; i++) {
list_add(&page->lru, freelist);
@@ -105,6 +109,73 @@ static unsigned long isolate_freepages_block(struct zone 
*zone,
return total_isolated;
 }
 
+/**
+ * isolate_freepages_range() - isolate free pages.
+ * @start_pfn: The first PFN to start isolating.
+ * @end_pfn:   The one-past-last PFN.
+ *
+ * Non-free pages, invalid PFNs, or zone boundaries within the
+ * [start_pfn, end_pfn) range are considered errors, cause function to
+ * undo its actions and return zero.
+ *
+ * Otherwise, function returns one-past-the-last PFN of isolated page
+ * (which may be greater then end_pfn if end fell in a middle of
+ * a free page).
+ */
+static unsigned long
+isolate_freepages_range(unsigned long start_pfn, unsigned long end_pfn)
+{
+   unsigned long isolated, pfn, block_end_pfn, flags;
+   struct zone *zone = NULL;
+   LIST_HEAD(freelist);
+
+   if (pfn_valid(start_pfn))
+   zone = page_zone(pfn_to_page(start_pfn));
+
+   for (pfn = start_pfn; pfn < end_pfn; pfn += isolated) {
+   if (!pfn_valid(pfn) || zone != page_zone(pfn_to_page(pfn)))
+   break;
+
+   /*
+* On subsequent iterations ALIGN() is actually not needed,
+* but we keep it that we not to complicate the code.
+*/
+   block_end_pfn = ALIGN(pfn + 1, pageblock_nr_pages);
+   block_end_pfn = min(block_end_pfn, end_pfn);
+
+   spin_lock_irqsave(&zone->lock, flags);
+   isolated = isolate_freepages_block(pfn, block_end_pfn,
+  &freelist, true);
+   spin_unlock_irqrestore(&zone->lock, flags);
+
+   /*
+* In strict mode, isolate_freepages_block() returns 0 if
+* there are any holes in the block (ie. invalid PFNs or
+ 

[PATCHv21 07/16] mm: page_alloc: change fallbacks array handling

2012-02-10 Thread Marek Szyprowski
From: Michal Nazarewicz 

This commit adds a row for MIGRATE_ISOLATE type to the fallbacks array
which was missing from it.  It also, changes the array traversal logic
a little making MIGRATE_RESERVE an end marker.  The letter change,
removes the implicit MIGRATE_UNMOVABLE from the end of each row which
was read by __rmqueue_fallback() function.

Signed-off-by: Michal Nazarewicz 
Signed-off-by: Marek Szyprowski 
Acked-by: Mel Gorman 
Tested-by: Rob Clark 
Tested-by: Ohad Ben-Cohen 
Tested-by: Benjamin Gaignard 
---
 mm/page_alloc.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f820bfa..f025fba 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -875,11 +875,12 @@ struct page *__rmqueue_smallest(struct zone *zone, 
unsigned int order,
  * This array describes the order lists are fallen back to when
  * the free lists for the desirable migrate type are depleted
  */
-static int fallbacks[MIGRATE_TYPES][MIGRATE_TYPES-1] = {
+static int fallbacks[MIGRATE_TYPES][3] = {
[MIGRATE_UNMOVABLE]   = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE,   
MIGRATE_RESERVE },
[MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE,   MIGRATE_MOVABLE,   
MIGRATE_RESERVE },
[MIGRATE_MOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE, 
MIGRATE_RESERVE },
-   [MIGRATE_RESERVE] = { MIGRATE_RESERVE, MIGRATE_RESERVE,   
MIGRATE_RESERVE }, /* Never used */
+   [MIGRATE_RESERVE] = { MIGRATE_RESERVE }, /* Never used */
+   [MIGRATE_ISOLATE] = { MIGRATE_RESERVE }, /* Never used */
 };
 
 /*
@@ -974,12 +975,12 @@ __rmqueue_fallback(struct zone *zone, int order, int 
start_migratetype)
/* Find the largest possible block of pages in the other list */
for (current_order = MAX_ORDER-1; current_order >= order;
--current_order) {
-   for (i = 0; i < MIGRATE_TYPES - 1; i++) {
+   for (i = 0;; i++) {
migratetype = fallbacks[start_migratetype][i];
 
/* MIGRATE_RESERVE handled later if necessary */
if (migratetype == MIGRATE_RESERVE)
-   continue;
+   break;
 
area = &(zone->free_area[current_order]);
if (list_empty(&area->free_list[migratetype]))
-- 
1.7.1.569.g6f426

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


[PATCHv21 09/16] mm: page_isolation: MIGRATE_CMA isolation functions added

2012-02-10 Thread Marek Szyprowski
From: Michal Nazarewicz 

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

Signed-off-by: Michal Nazarewicz 
Signed-off-by: Marek Szyprowski 
Tested-by: Rob Clark 
Tested-by: Ohad Ben-Cohen 
Tested-by: Benjamin Gaignard 
---
 include/linux/gfp.h|3 ++-
 include/linux/page-isolation.h |   18 +-
 mm/memory-failure.c|2 +-
 mm/memory_hotplug.c|6 +++---
 mm/page_alloc.c|   18 --
 mm/page_isolation.c|   15 ---
 6 files changed, 35 insertions(+), 27 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 78d32a7..1e49be4 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -394,7 +394,8 @@ static inline bool pm_suspended_storage(void)
 #ifdef CONFIG_CMA
 
 /* The below functions must be run on a range from a single zone. */
-extern int alloc_contig_range(unsigned long start, unsigned long end);
+extern int alloc_contig_range(unsigned long start, unsigned long end,
+ unsigned migratetype);
 extern void free_contig_range(unsigned long pfn, unsigned nr_pages);
 
 /* CMA stuff */
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 051c1b1..3bdcab3 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -3,7 +3,7 @@
 
 /*
  * Changes migrate type in [start_pfn, end_pfn) to be MIGRATE_ISOLATE.
- * If specified range includes migrate types other than MOVABLE,
+ * If specified range includes migrate types other than MOVABLE or CMA,
  * this will fail with -EBUSY.
  *
  * For isolating all pages in the range finally, the caller have to
@@ -11,27 +11,27 @@
  * test it.
  */
 extern int
-start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn);
+start_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
+unsigned migratetype);
 
 /*
  * Changes MIGRATE_ISOLATE to MIGRATE_MOVABLE.
  * target range is [start_pfn, end_pfn)
  */
 extern int
-undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn);
+undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
+   unsigned migratetype);
 
 /*
- * test all pages in [start_pfn, end_pfn)are isolated or not.
+ * Test all pages in [start_pfn, end_pfn) are isolated or not.
  */
-extern int
-test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn);
+int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn);
 
 /*
- * Internal funcs.Changes pageblock's migrate type.
- * Please use make_pagetype_isolated()/make_pagetype_movable().
+ * Internal functions. Changes pageblock's migrate type.
  */
 extern int set_migratetype_isolate(struct page *page);
-extern void unset_migratetype_isolate(struct page *page);
+extern void unset_migratetype_isolate(struct page *page, unsigned migratetype);
 
 
 #endif
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 56080ea..76b01bf 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1400,7 +1400,7 @@ static int get_any_page(struct page *p, unsigned long 
pfn, int flags)
/* Not a free page */
ret = 1;
}
-   unset_migratetype_isolate(p);
+   unset_migratetype_isolate(p, MIGRATE_MOVABLE);
unlock_memory_hotplug();
return ret;
 }
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 6629faf..fc898cb 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -891,7 +891,7 @@ static int __ref offline_pages(unsigned long start_pfn,
nr_pages = end_pfn - start_pfn;
 
/* set above range as isolated */
-   ret = start_isolate_page_range(start_pfn, end_pfn);
+   ret = start_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
if (ret)
goto out;
 
@@ -956,7 +956,7 @@ repeat:
   We cannot do rollback at this point. */
offline_isolated_pages(start_pfn, end_pfn);
/* reset pagetype flags and makes migrate type to be MOVABLE */
-   undo_isolate_page_range(start_pfn, end_pfn);
+   undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
/* removal success */
zone->present_pages -= offlined_pages;
zone->zone_pgdat->node_present_pages -= offlined_pages;
@@ -981,7 +981,7 @@ failed_removal:
start_pfn, end_pfn);
memory_notify(MEM_CANCEL_OFFLINE, &arg);
/* pushback to free area */
-   undo_isolate_page_range(start_pfn, end_pfn);
+   undo_isolate_page_range(start_pfn, end_pfn, MIGRATE_MOVABLE);
 
 out:
unlock_memory_hotplug();
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 0d23508..7d9f36e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5537,7 +5537,7 @@ out:
return ret;
 }
 
-void unset_migratetype_isolate(struct pa

[PATCHv21 03/16] mm: compaction: introduce map_pages()

2012-02-10 Thread Marek Szyprowski
From: Michal Nazarewicz 

This commit creates a map_pages() function which map pages freed
using split_free_pages().  This merely moves some code from
isolate_freepages() so that it can be reused in other places.

Signed-off-by: Michal Nazarewicz 
Signed-off-by: Marek Szyprowski 
Acked-by: Mel Gorman 
---
 mm/compaction.c |   15 +++
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 62902b6..9bbcc53 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -127,6 +127,16 @@ static bool suitable_migration_target(struct page *page)
return false;
 }
 
+static void map_pages(struct list_head *list)
+{
+   struct page *page;
+
+   list_for_each_entry(page, list, lru) {
+   arch_alloc_page(page, 0);
+   kernel_map_pages(page, 1, 1);
+   }
+}
+
 /*
  * Based on information in the current compact_control, find blocks
  * suitable for isolating free pages from and then isolate them.
@@ -206,10 +216,7 @@ static void isolate_freepages(struct zone *zone,
}
 
/* split_free_page does not map the pages */
-   list_for_each_entry(page, freelist, lru) {
-   arch_alloc_page(page, 0);
-   kernel_map_pages(page, 1, 1);
-   }
+   map_pages(freelist);
 
cc->free_pfn = high_pfn;
cc->nr_freepages = nr_freepages;
-- 
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


[PATCHv21 00/16] Contiguous Memory Allocator

2012-02-10 Thread Marek Szyprowski
Hello,

This is yet another quick update on CMA patches (this should be the last
one, really). We fixed minor bug which might cause incorrect operation
of memory compaction code as well as merged some simple updates to
memory reclaim function called by alloc_contig_range. 

I really hope that this will be a last iteration of this series.

Best regards
Marek Szyprowski
Samsung Poland R&D Center

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


Changelog:

v21:
1. Fixed incorrect check which broke memory compaction code

2. Fixed hacky and racy min_free_kbytes handling

3. Added serialization patch to watermark calculation

4. Fixed typos here and there in the comments

v20 and earlier - see previous patchsets.


Patches in this patchset:

Marek Szyprowski (6):
  mm: extract reclaim code from __alloc_pages_direct_reclaim()
  mm: trigger page reclaim in alloc_contig_range() to stabilise
watermarks
  drivers: add Contiguous Memory Allocator
  X86: integrate CMA with DMA-mapping subsystem
  ARM: integrate CMA with DMA-mapping subsystem
  ARM: Samsung: use CMA for 2 memory banks for s5p-mfc device

Mel Gorman (1):
  mm: Serialize access to min_free_kbytes

Michal Nazarewicz (9):
  mm: page_alloc: remove trailing whitespace
  mm: compaction: introduce isolate_migratepages_range()
  mm: compaction: introduce map_pages()
  mm: compaction: introduce isolate_freepages_range()
  mm: compaction: export some of the functions
  mm: page_alloc: introduce alloc_contig_range()
  mm: page_alloc: change fallbacks array handling
  mm: mmzone: MIGRATE_CMA migration type added
  mm: page_isolation: MIGRATE_CMA isolation functions added

 Documentation/kernel-parameters.txt   |9 +
 arch/Kconfig  |3 +
 arch/arm/Kconfig  |2 +
 arch/arm/include/asm/dma-contiguous.h |   16 ++
 arch/arm/include/asm/mach/map.h   |1 +
 arch/arm/kernel/setup.c   |9 +-
 arch/arm/mm/dma-mapping.c |  368 --
 arch/arm/mm/init.c|   24 ++-
 arch/arm/mm/mm.h  |3 +
 arch/arm/mm/mmu.c |   31 ++-
 arch/arm/plat-s5p/dev-mfc.c   |   51 +
 arch/x86/Kconfig  |1 +
 arch/x86/include/asm/dma-contiguous.h |   13 +
 arch/x86/include/asm/dma-mapping.h|4 +
 arch/x86/kernel/pci-dma.c |   18 ++-
 arch/x86/kernel/pci-nommu.c   |8 +-
 arch/x86/kernel/setup.c   |2 +
 drivers/base/Kconfig  |   89 +++
 drivers/base/Makefile |1 +
 drivers/base/dma-contiguous.c |  403 +++
 include/asm-generic/dma-contiguous.h  |   27 ++
 include/linux/device.h|4 +
 include/linux/dma-contiguous.h|  110 +
 include/linux/gfp.h   |   12 +
 include/linux/mmzone.h|   47 +++-
 include/linux/page-isolation.h|   18 +-
 mm/Kconfig|2 +-
 mm/Makefile   |3 +-
 mm/compaction.c   |  418 +
 mm/internal.h |   33 +++
 mm/memory-failure.c   |2 +-
 mm/memory_hotplug.c   |6 +-
 mm/page_alloc.c   |  413 
 mm/page_isolation.c   |   15 +-
 mm/vmstat.c   |3 +
 35 files changed, 1794 insertions(+), 375 deletions(-)
 create mode 100644 arch/arm/include/asm/dma-contiguous.h
 create mode 100644 arch/x86/include/asm/dma-contiguous.h
 create mode 100644 drivers/base/dma-contiguous.c
 create mode 100644 include/asm-generic/dma-contiguous.h
 create mode 100644 include/linux

[PATCHv21 02/16] mm: compaction: introduce isolate_migratepages_range()

2012-02-10 Thread Marek Szyprowski
From: Michal Nazarewicz 

This commit introduces isolate_migratepages_range() function which
extracts functionality from isolate_migratepages() so that it can be
used on arbitrary PFN ranges.

isolate_migratepages() function is implemented as a simple wrapper
around isolate_migratepages_range().

Signed-off-by: Michal Nazarewicz 
Signed-off-by: Marek Szyprowski 
Acked-by: Mel Gorman 
Tested-by: Rob Clark 
Tested-by: Ohad Ben-Cohen 
Tested-by: Benjamin Gaignard 
---
 mm/compaction.c |   75 +++---
 1 files changed, 54 insertions(+), 21 deletions(-)

diff --git a/mm/compaction.c b/mm/compaction.c
index 71a58f6..62902b6 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -250,31 +250,34 @@ typedef enum {
ISOLATE_SUCCESS,/* Pages isolated, migrate */
 } isolate_migrate_t;
 
-/*
- * Isolate all pages that can be migrated from the block pointed to by
- * the migrate scanner within compact_control.
+/**
+ * isolate_migratepages_range() - isolate all migrate-able pages in range.
+ * @zone:  Zone pages are in.
+ * @cc:Compaction control structure.
+ * @low_pfn:   The first PFN of the range.
+ * @end_pfn:   The one-past-the-last PFN of the range.
+ *
+ * Isolate all pages that can be migrated from the range specified by
+ * [low_pfn, end_pfn).  Returns zero if there is a fatal signal
+ * pending), otherwise PFN of the first page that was not scanned
+ * (which may be both less, equal to or more then end_pfn).
+ *
+ * Assumes that cc->migratepages is empty and cc->nr_migratepages is
+ * zero.
+ *
+ * Apart from cc->migratepages and cc->nr_migratetypes this function
+ * does not modify any cc's fields, in particular it does not modify
+ * (or read for that matter) cc->migrate_pfn.
  */
-static isolate_migrate_t isolate_migratepages(struct zone *zone,
-   struct compact_control *cc)
+static unsigned long
+isolate_migratepages_range(struct zone *zone, struct compact_control *cc,
+  unsigned long low_pfn, unsigned long end_pfn)
 {
-   unsigned long low_pfn, end_pfn;
unsigned long last_pageblock_nr = 0, pageblock_nr;
unsigned long nr_scanned = 0, nr_isolated = 0;
struct list_head *migratelist = &cc->migratepages;
isolate_mode_t mode = ISOLATE_ACTIVE|ISOLATE_INACTIVE;
 
-   /* Do not scan outside zone boundaries */
-   low_pfn = max(cc->migrate_pfn, zone->zone_start_pfn);
-
-   /* Only scan within a pageblock boundary */
-   end_pfn = ALIGN(low_pfn + pageblock_nr_pages, pageblock_nr_pages);
-
-   /* Do not cross the free scanner or scan within a memory hole */
-   if (end_pfn > cc->free_pfn || !pfn_valid(low_pfn)) {
-   cc->migrate_pfn = end_pfn;
-   return ISOLATE_NONE;
-   }
-
/*
 * Ensure that there are not too many pages isolated from the LRU
 * list by either parallel reclaimers or compaction. If there are,
@@ -283,12 +286,12 @@ static isolate_migrate_t isolate_migratepages(struct zone 
*zone,
while (unlikely(too_many_isolated(zone))) {
/* async migration should just abort */
if (!cc->sync)
-   return ISOLATE_ABORT;
+   return 0;
 
congestion_wait(BLK_RW_ASYNC, HZ/10);
 
if (fatal_signal_pending(current))
-   return ISOLATE_ABORT;
+   return 0;
}
 
/* Time to isolate some pages for migration */
@@ -374,10 +377,40 @@ static isolate_migrate_t isolate_migratepages(struct zone 
*zone,
acct_isolated(zone, cc);
 
spin_unlock_irq(&zone->lru_lock);
-   cc->migrate_pfn = low_pfn;
 
trace_mm_compaction_isolate_migratepages(nr_scanned, nr_isolated);
 
+   return low_pfn;
+}
+
+/*
+ * Isolate all pages that can be migrated from the block pointed to by
+ * the migrate scanner within compact_control.
+ */
+static isolate_migrate_t isolate_migratepages(struct zone *zone,
+   struct compact_control *cc)
+{
+   unsigned long low_pfn, end_pfn;
+
+   /* Do not scan outside zone boundaries */
+   low_pfn = max(cc->migrate_pfn, zone->zone_start_pfn);
+
+   /* Only scan within a pageblock boundary */
+   end_pfn = ALIGN(low_pfn + pageblock_nr_pages, pageblock_nr_pages);
+
+   /* Do not cross the free scanner or scan within a memory hole */
+   if (end_pfn > cc->free_pfn || !pfn_valid(low_pfn)) {
+   cc->migrate_pfn = end_pfn;
+   return ISOLATE_NONE;
+   }
+
+   /* Perform the isolation */
+   low_pfn = isolate_migratepages_range(zone, cc, low_pfn, end_pfn);
+   if (!low_pfn)
+   return ISOLATE_ABORT;
+
+   cc->migrate_pfn = low_pfn;
+
return ISOLATE_SUCCESS;
 }
 
-- 
1.7.1.569.g6f426

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the 

[PATCHv21 01/16] mm: page_alloc: remove trailing whitespace

2012-02-10 Thread Marek Szyprowski
From: Michal Nazarewicz 

Signed-off-by: Michal Nazarewicz 
Signed-off-by: Marek Szyprowski 
Acked-by: Mel Gorman 
---
 mm/page_alloc.c |   18 +-
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d2186ec..7fe7697 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -513,10 +513,10 @@ static inline int page_is_buddy(struct page *page, struct 
page *buddy,
  * free pages of length of (1 << order) and marked with _mapcount -2. Page's
  * order is recorded in page_private(page) field.
  * So when we are allocating or freeing one, we can derive the state of the
- * other.  That is, if we allocate a small block, and both were   
- * free, the remainder of the region must be split into blocks.   
+ * other.  That is, if we allocate a small block, and both were
+ * free, the remainder of the region must be split into blocks.
  * If a block is freed, and its buddy is also free, then this
- * triggers coalescing into a block of larger size.
+ * triggers coalescing into a block of larger size.
  *
  * -- wli
  */
@@ -1061,17 +1061,17 @@ retry_reserve:
return page;
 }
 
-/* 
+/*
  * Obtain a specified number of elements from the buddy allocator, all under
  * a single hold of the lock, for efficiency.  Add them to the supplied list.
  * Returns the number of new pages which were placed at *list.
  */
-static int rmqueue_bulk(struct zone *zone, unsigned int order, 
+static int rmqueue_bulk(struct zone *zone, unsigned int order,
unsigned long count, struct list_head *list,
int migratetype, int cold)
 {
int i;
-   
+
spin_lock(&zone->lock);
for (i = 0; i < count; ++i) {
struct page *page = __rmqueue(zone, order, migratetype);
@@ -4258,7 +4258,7 @@ static void __paginginit free_area_init_core(struct 
pglist_data *pgdat,
init_waitqueue_head(&pgdat->kswapd_wait);
pgdat->kswapd_max_order = 0;
pgdat_page_cgroup_init(pgdat);
-   
+
for (j = 0; j < MAX_NR_ZONES; j++) {
struct zone *zone = pgdat->node_zones + j;
unsigned long size, realsize, memmap_pages;
@@ -5081,11 +5081,11 @@ int __meminit init_per_zone_wmark_min(void)
 module_init(init_per_zone_wmark_min)
 
 /*
- * min_free_kbytes_sysctl_handler - just a wrapper around proc_dointvec() so 
+ * min_free_kbytes_sysctl_handler - just a wrapper around proc_dointvec() so
  * that we can call two helper functions whenever min_free_kbytes
  * changes.
  */
-int min_free_kbytes_sysctl_handler(ctl_table *table, int write, 
+int min_free_kbytes_sysctl_handler(ctl_table *table, int write,
void __user *buffer, size_t *length, loff_t *ppos)
 {
proc_dointvec(table, write, buffer, length, ppos);
-- 
1.7.1.569.g6f426

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


[PATCHv21 14/16] X86: integrate CMA with DMA-mapping subsystem

2012-02-10 Thread Marek Szyprowski
This patch adds support for CMA to dma-mapping subsystem for x86
architecture that uses common pci-dma/pci-nommu implementation. This
allows to test CMA on KVM/QEMU and a lot of common x86 boxes.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Kyungmin Park 
CC: Michal Nazarewicz 
Acked-by: Arnd Bergmann 
---
 arch/x86/Kconfig  |1 +
 arch/x86/include/asm/dma-contiguous.h |   13 +
 arch/x86/include/asm/dma-mapping.h|4 
 arch/x86/kernel/pci-dma.c |   18 --
 arch/x86/kernel/pci-nommu.c   |8 +---
 arch/x86/kernel/setup.c   |2 ++
 6 files changed, 37 insertions(+), 9 deletions(-)
 create mode 100644 arch/x86/include/asm/dma-contiguous.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 5bed94e..de6e069 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -31,6 +31,7 @@ config X86
select ARCH_WANT_OPTIONAL_GPIOLIB
select ARCH_WANT_FRAME_POINTERS
select HAVE_DMA_ATTRS
+   select HAVE_DMA_CONTIGUOUS if !SWIOTLB
select HAVE_KRETPROBES
select HAVE_OPTPROBES
select HAVE_FTRACE_MCOUNT_RECORD
diff --git a/arch/x86/include/asm/dma-contiguous.h 
b/arch/x86/include/asm/dma-contiguous.h
new file mode 100644
index 000..8fb117d
--- /dev/null
+++ b/arch/x86/include/asm/dma-contiguous.h
@@ -0,0 +1,13 @@
+#ifndef ASMX86_DMA_CONTIGUOUS_H
+#define ASMX86_DMA_CONTIGUOUS_H
+
+#ifdef __KERNEL__
+
+#include 
+#include 
+#include 
+
+static inline void dma_contiguous_early_fixup(phys_addr_t base, unsigned long 
size) { }
+
+#endif
+#endif
diff --git a/arch/x86/include/asm/dma-mapping.h 
b/arch/x86/include/asm/dma-mapping.h
index ed3065f..90ac6f0 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_ISA
 # define ISA_DMA_BIT_MASK DMA_BIT_MASK(24)
@@ -61,6 +62,9 @@ extern int dma_set_mask(struct device *dev, u64 mask);
 extern void *dma_generic_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_addr, gfp_t flag);
 
+extern void dma_generic_free_coherent(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_addr);
+
 static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t 
size)
 {
if (!dev->dma_mask)
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 1c4d769..d3c3723 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -99,14 +99,18 @@ void *dma_generic_alloc_coherent(struct device *dev, size_t 
size,
 dma_addr_t *dma_addr, gfp_t flag)
 {
unsigned long dma_mask;
-   struct page *page;
+   struct page *page = NULL;
+   unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
dma_addr_t addr;
 
dma_mask = dma_alloc_coherent_mask(dev, flag);
 
flag |= __GFP_ZERO;
 again:
-   page = alloc_pages_node(dev_to_node(dev), flag, get_order(size));
+   if (!(flag & GFP_ATOMIC))
+   page = dma_alloc_from_contiguous(dev, count, get_order(size));
+   if (!page)
+   page = alloc_pages_node(dev_to_node(dev), flag, 
get_order(size));
if (!page)
return NULL;
 
@@ -126,6 +130,16 @@ again:
return page_address(page);
 }
 
+void dma_generic_free_coherent(struct device *dev, size_t size, void *vaddr,
+  dma_addr_t dma_addr)
+{
+   unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
+   struct page *page = virt_to_page(vaddr);
+
+   if (!dma_release_from_contiguous(dev, page, count))
+   free_pages((unsigned long)vaddr, get_order(size));
+}
+
 /*
  * See  for the iommu kernel
  * parameter documentation.
diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c
index 3af4af8..656566f 100644
--- a/arch/x86/kernel/pci-nommu.c
+++ b/arch/x86/kernel/pci-nommu.c
@@ -74,12 +74,6 @@ static int nommu_map_sg(struct device *hwdev, struct 
scatterlist *sg,
return nents;
 }
 
-static void nommu_free_coherent(struct device *dev, size_t size, void *vaddr,
-   dma_addr_t dma_addr)
-{
-   free_pages((unsigned long)vaddr, get_order(size));
-}
-
 static void nommu_sync_single_for_device(struct device *dev,
dma_addr_t addr, size_t size,
enum dma_data_direction dir)
@@ -97,7 +91,7 @@ static void nommu_sync_sg_for_device(struct device *dev,
 
 struct dma_map_ops nommu_dma_ops = {
.alloc_coherent = dma_generic_alloc_coherent,
-   .free_coherent  = nommu_free_coherent,
+   .free_coherent  = dma_generic_free_coherent,
.map_sg = nommu_map_sg,
.map_page   = nommu_map_page,
.sync_single_for_device = nommu_sync_single_for_device,
diff --git a/arch/x86/kernel/setu

[PATCHv21 06/16] mm: page_alloc: introduce alloc_contig_range()

2012-02-10 Thread Marek Szyprowski
From: Michal Nazarewicz 

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

Signed-off-by: Michal Nazarewicz 
Signed-off-by: Marek Szyprowski 
Acked-by: Mel Gorman 
Tested-by: Rob Clark 
Tested-by: Ohad Ben-Cohen 
Tested-by: Benjamin Gaignard 
---
 include/linux/gfp.h |8 ++
 mm/page_alloc.c |  185 +++
 2 files changed, 193 insertions(+), 0 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 581e74b..052a5b6 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -391,4 +391,12 @@ static inline bool pm_suspended_storage(void)
 }
 #endif /* CONFIG_PM_SLEEP */
 
+#ifdef CONFIG_CMA
+
+/* The below functions must be run on a range from a single zone. */
+extern int alloc_contig_range(unsigned long start, unsigned long end);
+extern void free_contig_range(unsigned long pfn, unsigned nr_pages);
+
+#endif
+
 #endif /* __LINUX_GFP_H */
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7fe7697..f820bfa 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -5505,6 +5506,190 @@ out:
spin_unlock_irqrestore(&zone->lock, flags);
 }
 
+#ifdef CONFIG_CMA
+
+static unsigned long pfn_align_to_maxpage_down(unsigned long pfn)
+{
+   return pfn & ~(MAX_ORDER_NR_PAGES - 1);
+}
+
+static unsigned long pfn_align_to_maxpage_up(unsigned long pfn)
+{
+   return ALIGN(pfn, MAX_ORDER_NR_PAGES);
+}
+
+static struct page *
+__alloc_contig_migrate_alloc(struct page *page, unsigned long private,
+int **resultp)
+{
+   return alloc_page(GFP_HIGHUSER_MOVABLE);
+}
+
+/* [start, end) must belong to a single zone. */
+static int __alloc_contig_migrate_range(unsigned long start, unsigned long end)
+{
+   /* This function is based on compact_zone() from compaction.c. */
+
+   unsigned long pfn = start;
+   unsigned int tries = 0;
+   int ret = 0;
+
+   struct compact_control cc = {
+   .nr_migratepages = 0,
+   .order = -1,
+   .zone = page_zone(pfn_to_page(start)),
+   .sync = true,
+   };
+   INIT_LIST_HEAD(&cc.migratepages);
+
+   migrate_prep_local();
+
+   while (pfn < end || !list_empty(&cc.migratepages)) {
+   if (fatal_signal_pending(current)) {
+   ret = -EINTR;
+   break;
+   }
+
+   if (list_empty(&cc.migratepages)) {
+   cc.nr_migratepages = 0;
+   pfn = isolate_migratepages_range(cc.zone, &cc,
+pfn, end);
+   if (!pfn) {
+   ret = -EINTR;
+   break;
+   }
+   tries = 0;
+   } else if (++tries == 5) {
+   ret = ret < 0 ? ret : -EBUSY;
+   break;
+   }
+
+   ret = migrate_pages(&cc.migratepages,
+   __alloc_contig_migrate_alloc,
+   0, false, true);
+   }
+
+   putback_lru_pages(&cc.migratepages);
+   return ret > 0 ? 0 : ret;
+}
+
+/**
+ * alloc_contig_range() -- tries to allocate given range of pages
+ * @start: start PFN to allocate
+ * @end:   one-past-the-last PFN to allocate
+ *
+ * The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
+ * aligned, however it's the caller's responsibility to guarantee that
+ * we are the only thread that changes migrate type of pageblocks the
+ * pages fall in.
+ *
+ * The PFN range must belong to a single zone.
+ *
+ * Returns zero on success or negative error code.  On success all
+ * pages which PFN is in [start, end) are allocated for the caller and
+ * need to be freed with free_contig_range().
+ */
+int alloc_contig_range(unsigned long start, unsigned long end)
+{
+   struct zone *zone = page_zone(pfn_to_page(start));
+   unsigned long outer_start, outer_end;
+   int ret = 0, order;
+
+   /*
+* What we do here is we mark all pageblocks in range as
+* MIGRATE_ISOLATE.  Because of the way page allocator work, we
+* align the range to MAX_ORDER pages so that page allocator
+* won't try to merge buddies from different pageblocks and
+* change MIGRATE_ISOLATE to some other migration type.
+*
+* Once the pageblocks are marked as MIGRATE_ISOLATE, we
+* migrate the pages from an unaligned range (ie. pages that
+* we are interested in).  This will put all the pages in
+* range back to page allocator as MI

[PATCHv21 08/16] mm: mmzone: MIGRATE_CMA migration type added

2012-02-10 Thread Marek Szyprowski
From: Michal Nazarewicz 

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

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

It is designed to be used for allocating big chunks (eg. 10MiB)
of physically contiguous memory.  Once driver requests
contiguous memory, pages from MIGRATE_CMA pageblocks may be
migrated away to create a contiguous block.

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

Signed-off-by: Michal Nazarewicz 
Signed-off-by: Marek Szyprowski 
Signed-off-by: Kyungmin Park 
Acked-by: Mel Gorman 
Tested-by: Rob Clark 
Tested-by: Ohad Ben-Cohen 
Tested-by: Benjamin Gaignard 
---
 include/linux/gfp.h|3 ++
 include/linux/mmzone.h |   38 +++
 mm/Kconfig |2 +-
 mm/compaction.c|   11 +--
 mm/page_alloc.c|   76 +--
 mm/vmstat.c|3 ++
 6 files changed, 106 insertions(+), 27 deletions(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 052a5b6..78d32a7 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -397,6 +397,9 @@ static inline bool pm_suspended_storage(void)
 extern int alloc_contig_range(unsigned long start, unsigned long end);
 extern void free_contig_range(unsigned long pfn, unsigned nr_pages);
 
+/* CMA stuff */
+extern void init_cma_reserved_pageblock(struct page *page);
+
 #endif
 
 #endif /* __LINUX_GFP_H */
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 650ba2f..82f4fa5 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -35,13 +35,37 @@
  */
 #define PAGE_ALLOC_COSTLY_ORDER 3
 
-#define MIGRATE_UNMOVABLE 0
-#define MIGRATE_RECLAIMABLE   1
-#define MIGRATE_MOVABLE   2
-#define MIGRATE_PCPTYPES  3 /* the number of types on the pcp lists */
-#define MIGRATE_RESERVE   3
-#define MIGRATE_ISOLATE   4 /* can't allocate from here */
-#define MIGRATE_TYPES 5
+enum {
+   MIGRATE_UNMOVABLE,
+   MIGRATE_RECLAIMABLE,
+   MIGRATE_MOVABLE,
+   MIGRATE_PCPTYPES,   /* the number of types on the pcp lists */
+   MIGRATE_RESERVE = MIGRATE_PCPTYPES,
+#ifdef CONFIG_CMA
+   /*
+* MIGRATE_CMA migration type is designed to mimic the way
+* ZONE_MOVABLE works.  Only movable pages can be allocated
+* from MIGRATE_CMA pageblocks and page allocator never
+* implicitly change migration type of MIGRATE_CMA pageblock.
+*
+* The way to use it is to change migratetype of a range of
+* pageblocks to MIGRATE_CMA which can be done by
+* __free_pageblock_cma() function.  What is important though
+* is that a range of pageblocks must be aligned to
+* MAX_ORDER_NR_PAGES should biggest page be bigger then
+* a single pageblock.
+*/
+   MIGRATE_CMA,
+#endif
+   MIGRATE_ISOLATE,/* can't allocate from here */
+   MIGRATE_TYPES
+};
+
+#ifdef CONFIG_CMA
+#  define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
+#else
+#  define is_migrate_cma(migratetype) false
+#endif
 
 #define for_each_migratetype_order(order, type) \
for (order = 0; order < MAX_ORDER; order++) \
diff --git a/mm/Kconfig b/mm/Kconfig
index e338407..3922002 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -198,7 +198,7 @@ config COMPACTION
 config MIGRATION
bool "Page migration"
def_bool y
-   depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION
+   depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE || COMPACTION || CMA
help
  Allows the migration of the physical location of pages of processes
  while the virtual addresses are not changed. This is useful in
diff --git a/mm/compaction.c b/mm/compaction.c
index d5174c4..f4a2306 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -45,6 +45,11 @@ static void map_pages(struct list_head *list)
}
 }
 
+static inline bool migrate_async_suitable(int migratetype)
+{
+   return is_migrate_cma(migratetype) || migratetype == MIGRATE_MOVABLE;
+}
+
 /*
  * Isolate free pages onto a private freelist. Caller must hold zone->lock.
  * If @strict is true, will abort returning 0 on any invalid PFNs or non-free
@@ -277,7 +282,7 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
 */
pageblock_nr = low_pfn >> pageblock_order;
if (!cc->sync && last_pageblock_nr != pageblock_nr &&
-   get_pageblock_migratetype(page) != 
MIGRATE_MOVABLE) {
+   !migrate_async_suitable(get_pageblock_migratetype(page))) {

[PATCHv21 15/16] ARM: integrate CMA with DMA-mapping subsystem

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

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

GFP_ATOMIC allocations are performed from special pool which is created
early during boot. This way remapping page attributes is not needed on
allocation time.

CMA has been enabled unconditionally for ARMv6+ systems.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Kyungmin Park 
CC: Michal Nazarewicz 
Acked-by: Arnd Bergmann 
Tested-by: Rob Clark 
Tested-by: Ohad Ben-Cohen 
Tested-by: Benjamin Gaignard 
---
 Documentation/kernel-parameters.txt   |4 +
 arch/arm/Kconfig  |2 +
 arch/arm/include/asm/dma-contiguous.h |   16 ++
 arch/arm/include/asm/mach/map.h   |1 +
 arch/arm/kernel/setup.c   |9 +-
 arch/arm/mm/dma-mapping.c |  368 +++--
 arch/arm/mm/init.c|   24 ++-
 arch/arm/mm/mm.h  |3 +
 arch/arm/mm/mmu.c |   31 ++-
 9 files changed, 370 insertions(+), 88 deletions(-)
 create mode 100644 arch/arm/include/asm/dma-contiguous.h

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 84982e2..ff97085 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -520,6 +520,10 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
a hypervisor.
Default: yes
 
+   coherent_pool=nn[KMG]   [ARM,KNL]
+   Sets the size of memory pool for coherent, atomic dma
+   allocations if Contiguous Memory Allocator (CMA) is 
used.
+
code_bytes  [X86] How many bytes of object code to print
in an oops report.
Range: 0 - 8192
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a48aecc..56192fe 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -4,6 +4,8 @@ config ARM
select HAVE_AOUT
select HAVE_DMA_API_DEBUG
select HAVE_IDE if PCI || ISA || PCMCIA
+   select HAVE_DMA_CONTIGUOUS if (CPU_V6 || CPU_V6K || CPU_V7)
+   select CMA if (CPU_V6 || CPU_V6K || CPU_V7)
select HAVE_MEMBLOCK
select RTC_LIB
select SYS_SUPPORTS_APM_EMULATION
diff --git a/arch/arm/include/asm/dma-contiguous.h 
b/arch/arm/include/asm/dma-contiguous.h
new file mode 100644
index 000..c7ba05e
--- /dev/null
+++ b/arch/arm/include/asm/dma-contiguous.h
@@ -0,0 +1,16 @@
+#ifndef ASMARM_DMA_CONTIGUOUS_H
+#define ASMARM_DMA_CONTIGUOUS_H
+
+#ifdef __KERNEL__
+
+#include 
+#include 
+#include 
+
+#ifdef CONFIG_CMA
+
+void dma_contiguous_early_fixup(phys_addr_t base, unsigned long size);
+
+#endif
+#endif
+#endif
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index b36f365..a6efcdd 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -30,6 +30,7 @@ struct map_desc {
 #define MT_MEMORY_DTCM 12
 #define MT_MEMORY_ITCM 13
 #define MT_MEMORY_SO   14
+#define MT_MEMORY_DMA_READY15
 
 #ifdef CONFIG_MMU
 extern void iotable_init(struct map_desc *, int);
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index a255c39..a7d5fb7 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -79,6 +79,7 @@ __setup("fpe=", fpe_setup);
 extern void paging_init(struct machine_desc *desc);
 extern void sanity_check_meminfo(void);
 extern void reboot_setup(char *str);
+extern void setup_dma_zone(struct machine_desc *desc);
 
 unsigned int processor_id;
 EXPORT_SYMBOL(processor_id);
@@ -923,12 +924,8 @@ void __init setup_arch(char **cmdline_p)
machine_desc = mdesc;
machine_name = mdesc->name;
 
-#ifdef CONFIG_ZONE_DMA
-   if (mdesc->dma_zone_size) {
-   extern unsigned long arm_dma_zone_size;
-   arm_dma_zone_size = mdesc->dma_zone_size;
-   }
-#endif
+   setup_dma_zone(mdesc);
+
if (mdesc->restart_mode)
reboot_setup(&mdesc->restart_mode);
 
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 1aa664a..e614866 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -17,7 +17,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 
 #include 
@@ -26,6 +28,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "mm.h"
 
@@ -56,6 +60,19 @@ static u64 get_coherent_dma_mask(struct device *dev)
return mask;
 }
 
+static void __dma_clear_buffer(struct page *page, size_t size)
+{
+   void

[PATCHv21 05/16] mm: compaction: export some of the functions

2012-02-10 Thread Marek Szyprowski
From: Michal Nazarewicz 

This commit exports some of the functions from compaction.c file
outside of it adding their declaration into internal.h header
file so that other mm related code can use them.

This forced compaction.c to always be compiled (as opposed to being
compiled only if CONFIG_COMPACTION is defined) but as to avoid
introducing code that user did not ask for, part of the compaction.c
is now wrapped in on #ifdef.

Signed-off-by: Michal Nazarewicz 
Signed-off-by: Marek Szyprowski 
Acked-by: Mel Gorman 
Tested-by: Rob Clark 
Tested-by: Ohad Ben-Cohen 
Tested-by: Benjamin Gaignard 
---
 mm/Makefile |3 +-
 mm/compaction.c |  328 ++-
 mm/internal.h   |   33 ++
 3 files changed, 191 insertions(+), 173 deletions(-)

diff --git a/mm/Makefile b/mm/Makefile
index 50ec00e..8aada89 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -13,7 +13,7 @@ obj-y := filemap.o mempool.o oom_kill.o 
fadvise.o \
   readahead.o swap.o truncate.o vmscan.o shmem.o \
   prio_tree.o util.o mmzone.o vmstat.o backing-dev.o \
   page_isolation.o mm_init.o mmu_context.o percpu.o \
-  $(mmu-y)
+  compaction.o $(mmu-y)
 obj-y += init-mm.o
 
 ifdef CONFIG_NO_BOOTMEM
@@ -32,7 +32,6 @@ obj-$(CONFIG_NUMA)+= mempolicy.o
 obj-$(CONFIG_SPARSEMEM)+= sparse.o
 obj-$(CONFIG_SPARSEMEM_VMEMMAP) += sparse-vmemmap.o
 obj-$(CONFIG_SLOB) += slob.o
-obj-$(CONFIG_COMPACTION) += compaction.o
 obj-$(CONFIG_MMU_NOTIFIER) += mmu_notifier.o
 obj-$(CONFIG_KSM) += ksm.o
 obj-$(CONFIG_PAGE_POISONING) += debug-pagealloc.o
diff --git a/mm/compaction.c b/mm/compaction.c
index 9fef891..d5174c4 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -16,30 +16,11 @@
 #include 
 #include "internal.h"
 
+#if defined CONFIG_COMPACTION || defined CONFIG_CMA
+
 #define CREATE_TRACE_POINTS
 #include 
 
-/*
- * compact_control is used to track pages being migrated and the free pages
- * they are being migrated to during memory compaction. The free_pfn starts
- * at the end of a zone and migrate_pfn begins at the start. Movable pages
- * are moved to the end of a zone during a compaction run and the run
- * completes when free_pfn <= migrate_pfn
- */
-struct compact_control {
-   struct list_head freepages; /* List of free pages to migrate to */
-   struct list_head migratepages;  /* List of pages being migrated */
-   unsigned long nr_freepages; /* Number of isolated free pages */
-   unsigned long nr_migratepages;  /* Number of pages to migrate */
-   unsigned long free_pfn; /* isolate_freepages search base */
-   unsigned long migrate_pfn;  /* isolate_migratepages search base */
-   bool sync;  /* Synchronous migration */
-
-   unsigned int order; /* order a direct compactor needs */
-   int migratetype;/* MOVABLE, RECLAIMABLE etc */
-   struct zone *zone;
-};
-
 static unsigned long release_freepages(struct list_head *freelist)
 {
struct page *page, *next;
@@ -54,6 +35,16 @@ static unsigned long release_freepages(struct list_head 
*freelist)
return count;
 }
 
+static void map_pages(struct list_head *list)
+{
+   struct page *page;
+
+   list_for_each_entry(page, list, lru) {
+   arch_alloc_page(page, 0);
+   kernel_map_pages(page, 1, 1);
+   }
+}
+
 /*
  * Isolate free pages onto a private freelist. Caller must hold zone->lock.
  * If @strict is true, will abort returning 0 on any invalid PFNs or non-free
@@ -122,7 +113,7 @@ static unsigned long isolate_freepages_block(unsigned long 
blockpfn,
  * (which may be greater then end_pfn if end fell in a middle of
  * a free page).
  */
-static unsigned long
+unsigned long
 isolate_freepages_range(unsigned long start_pfn, unsigned long end_pfn)
 {
unsigned long isolated, pfn, block_end_pfn, flags;
@@ -176,127 +167,6 @@ isolate_freepages_range(unsigned long start_pfn, unsigned 
long end_pfn)
return pfn;
 }
 
-/* Returns true if the page is within a block suitable for migration to */
-static bool suitable_migration_target(struct page *page)
-{
-
-   int migratetype = get_pageblock_migratetype(page);
-
-   /* Don't interfere with memory hot-remove or the min_free_kbytes blocks 
*/
-   if (migratetype == MIGRATE_ISOLATE || migratetype == MIGRATE_RESERVE)
-   return false;
-
-   /* If the page is a large free page, then allow migration */
-   if (PageBuddy(page) && page_order(page) >= pageblock_order)
-   return true;
-
-   /* If the block is MIGRATE_MOVABLE, allow migration */
-   if (migratetype == MIGRATE_MOVABLE)
-   return true;
-
-   /* Otherwise skip the block */
-   return false;
-}
-
-static void map_pages(struct list_head *list)
-{
-   struct page *page;
-
-  

[PATCHv21 16/16] ARM: Samsung: use CMA for 2 memory banks for s5p-mfc device

2012-02-10 Thread Marek Szyprowski
Replace custom memory bank initialization using memblock_reserve and
dma_declare_coherent with a single call to CMA's dma_declare_contiguous.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Kyungmin Park 
Acked-by: Arnd Bergmann 
---
 arch/arm/plat-s5p/dev-mfc.c |   51 ++-
 1 files changed, 7 insertions(+), 44 deletions(-)

diff --git a/arch/arm/plat-s5p/dev-mfc.c b/arch/arm/plat-s5p/dev-mfc.c
index a30d36b..fcb8400 100644
--- a/arch/arm/plat-s5p/dev-mfc.c
+++ b/arch/arm/plat-s5p/dev-mfc.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -22,52 +23,14 @@
 #include 
 #include 
 
-struct s5p_mfc_reserved_mem {
-   phys_addr_t base;
-   unsigned long   size;
-   struct device   *dev;
-};
-
-static struct s5p_mfc_reserved_mem s5p_mfc_mem[2] __initdata;
-
 void __init s5p_mfc_reserve_mem(phys_addr_t rbase, unsigned int rsize,
phys_addr_t lbase, unsigned int lsize)
 {
-   int i;
-
-   s5p_mfc_mem[0].dev = &s5p_device_mfc_r.dev;
-   s5p_mfc_mem[0].base = rbase;
-   s5p_mfc_mem[0].size = rsize;
-
-   s5p_mfc_mem[1].dev = &s5p_device_mfc_l.dev;
-   s5p_mfc_mem[1].base = lbase;
-   s5p_mfc_mem[1].size = lsize;
-
-   for (i = 0; i < ARRAY_SIZE(s5p_mfc_mem); i++) {
-   struct s5p_mfc_reserved_mem *area = &s5p_mfc_mem[i];
-   if (memblock_remove(area->base, area->size)) {
-   printk(KERN_ERR "Failed to reserve memory for MFC 
device (%ld bytes at 0x%08lx)\n",
-  area->size, (unsigned long) area->base);
-   area->base = 0;
-   }
-   }
-}
-
-static int __init s5p_mfc_memory_init(void)
-{
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(s5p_mfc_mem); i++) {
-   struct s5p_mfc_reserved_mem *area = &s5p_mfc_mem[i];
-   if (!area->base)
-   continue;
+   if (dma_declare_contiguous(&s5p_device_mfc_r.dev, rsize, rbase, 0))
+   printk(KERN_ERR "Failed to reserve memory for MFC device (%u 
bytes at 0x%08lx)\n",
+  rsize, (unsigned long) rbase);
 
-   if (dma_declare_coherent_memory(area->dev, area->base,
-   area->base, area->size,
-   DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE) == 0)
-   printk(KERN_ERR "Failed to declare coherent memory for 
MFC device (%ld bytes at 0x%08lx)\n",
-  area->size, (unsigned long) area->base);
-   }
-   return 0;
+   if (dma_declare_contiguous(&s5p_device_mfc_l.dev, lsize, lbase, 0))
+   printk(KERN_ERR "Failed to reserve memory for MFC device (%u 
bytes at 0x%08lx)\n",
+  rsize, (unsigned long) rbase);
 }
-device_initcall(s5p_mfc_memory_init);
-- 
1.7.1.569.g6f426

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


[PATCHv21 13/16] drivers: add Contiguous Memory Allocator

2012-02-10 Thread Marek Szyprowski
The Contiguous Memory Allocator is a set of helper functions for DMA
mapping framework that improves allocations of contiguous memory chunks.

CMA grabs memory on system boot, marks it with MIGRATE_CMA migrate type
and gives back to the system. Kernel is allowed to allocate only movable
pages within CMA's managed memory so that it can be used for example for
page cache when DMA mapping do not use it. On
dma_alloc_from_contiguous() request such pages are migrated out of CMA
area to free required contiguous block and fulfill the request. This
allows to allocate large contiguous chunks of memory at any time
assuming that there is enough free memory available in the system.

This code is heavily based on earlier works by Michal Nazarewicz.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Kyungmin Park 
Signed-off-by: Michal Nazarewicz 
Acked-by: Arnd Bergmann 
Tested-by: Rob Clark 
Tested-by: Ohad Ben-Cohen 
Tested-by: Benjamin Gaignard 
---
 Documentation/kernel-parameters.txt  |5 +
 arch/Kconfig |3 +
 drivers/base/Kconfig |   89 
 drivers/base/Makefile|1 +
 drivers/base/dma-contiguous.c|  403 ++
 include/asm-generic/dma-contiguous.h |   27 +++
 include/linux/device.h   |4 +
 include/linux/dma-contiguous.h   |  110 +
 8 files changed, 642 insertions(+), 0 deletions(-)
 create mode 100644 drivers/base/dma-contiguous.c
 create mode 100644 include/asm-generic/dma-contiguous.h
 create mode 100644 include/linux/dma-contiguous.h

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 033d4e6..84982e2 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -508,6 +508,11 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
Also note the kernel might malfunction if you disable
some critical bits.
 
+   cma=nn[MG]  [ARM,KNL]
+   Sets the size of kernel global memory area for 
contiguous
+   memory allocations. For more information, see
+   include/linux/dma-contiguous.h
+
cmo_free_hint=  [PPC] Format: { yes | no }
Specify whether pages are marked as being inactive
when they are freed.  This is used in CMO environments
diff --git a/arch/Kconfig b/arch/Kconfig
index 4f55c73..8ec200c 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -128,6 +128,9 @@ config HAVE_ARCH_TRACEHOOK
 config HAVE_DMA_ATTRS
bool
 
+config HAVE_DMA_CONTIGUOUS
+   bool
+
 config USE_GENERIC_SMP_HELPERS
bool
 
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 7be9f79..f56cb20 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -189,4 +189,93 @@ config DMA_SHARED_BUFFER
  APIs extension; the file's descriptor can then be passed on to other
  driver.
 
+config CMA
+   bool "Contiguous Memory Allocator (EXPERIMENTAL)"
+   depends on HAVE_DMA_CONTIGUOUS && HAVE_MEMBLOCK && EXPERIMENTAL
+   select MIGRATION
+   help
+ This enables the Contiguous Memory Allocator which allows drivers
+ to allocate big physically-contiguous blocks of memory for use with
+ hardware components that do not support I/O map nor scatter-gather.
+
+ For more information see .
+ If unsure, say "n".
+
+if CMA
+
+config CMA_DEBUG
+   bool "CMA debug messages (DEVELOPMENT)"
+   depends on DEBUG_KERNEL
+   help
+ Turns on debug messages in CMA.  This produces KERN_DEBUG
+ messages for every CMA call as well as various messages while
+ processing calls such as dma_alloc_from_contiguous().
+ This option does not affect warning and error messages.
+
+comment "Default contiguous memory area size:"
+
+config CMA_SIZE_MBYTES
+   int "Size in Mega Bytes"
+   depends on !CMA_SIZE_SEL_PERCENTAGE
+   default 16
+   help
+ Defines the size (in MiB) of the default memory area for Contiguous
+ Memory Allocator.
+
+config CMA_SIZE_PERCENTAGE
+   int "Percentage of total memory"
+   depends on !CMA_SIZE_SEL_MBYTES
+   default 10
+   help
+ Defines the size of the default memory area for Contiguous Memory
+ Allocator as a percentage of the total memory in the system.
+
+choice
+   prompt "Selected region size"
+   default CMA_SIZE_SEL_ABSOLUTE
+
+config CMA_SIZE_SEL_MBYTES
+   bool "Use mega bytes value only"
+
+config CMA_SIZE_SEL_PERCENTAGE
+   bool "Use percentage value only"
+
+config CMA_SIZE_SEL_MIN
+   bool "Use lower value (minimum)"
+
+config CMA_SIZE_SEL_MAX
+   bool "Use higher value (maximum)"
+
+endchoice
+
+config CMA_ALIGNMENT
+   int "Maximum PAGE_SIZE order of alignment for contiguous buffers"
+   range 4 9
+   default 8
+

[PATCHv21 12/16] mm: trigger page reclaim in alloc_contig_range() to stabilise watermarks

2012-02-10 Thread Marek Szyprowski
alloc_contig_range() performs memory allocation so it also should keep
track on keeping the correct level of memory watermarks. This commit adds
a call to *_slowpath style reclaim to grab enough pages to make sure that
the final collection of contiguous pages from freelists will not starve
the system.

Signed-off-by: Marek Szyprowski 
Signed-off-by: Kyungmin Park 
CC: Michal Nazarewicz 
Tested-by: Rob Clark 
Tested-by: Ohad Ben-Cohen 
Tested-by: Benjamin Gaignard 
---
 include/linux/mmzone.h |9 +++
 mm/page_alloc.c|   62 
 2 files changed, 71 insertions(+), 0 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 82f4fa5..6a6c2cc 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -63,8 +63,10 @@ enum {
 
 #ifdef CONFIG_CMA
 #  define is_migrate_cma(migratetype) unlikely((migratetype) == MIGRATE_CMA)
+#  define cma_wmark_pages(zone)zone->min_cma_pages
 #else
 #  define is_migrate_cma(migratetype) false
+#  define cma_wmark_pages(zone) 0
 #endif
 
 #define for_each_migratetype_order(order, type) \
@@ -371,6 +373,13 @@ struct zone {
/* see spanned/present_pages for more description */
seqlock_t   span_seqlock;
 #endif
+#ifdef CONFIG_CMA
+   /*
+* CMA needs to increase watermark levels during the allocation
+* process to make sure that the system is not starved.
+*/
+   unsigned long   min_cma_pages;
+#endif
struct free_areafree_area[MAX_ORDER];
 
 #ifndef CONFIG_SPARSEMEM
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 793c4e4..2fedd36 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5035,6 +5035,11 @@ static void __setup_per_zone_wmarks(void)
 
zone->watermark[WMARK_LOW]  = min_wmark_pages(zone) + (tmp >> 
2);
zone->watermark[WMARK_HIGH] = min_wmark_pages(zone) + (tmp >> 
1);
+
+   zone->watermark[WMARK_MIN] += cma_wmark_pages(zone);
+   zone->watermark[WMARK_LOW] += cma_wmark_pages(zone);
+   zone->watermark[WMARK_HIGH] += cma_wmark_pages(zone);
+
setup_zone_migrate_reserve(zone);
spin_unlock_irqrestore(&zone->lock, flags);
}
@@ -5637,6 +5642,56 @@ static int __alloc_contig_migrate_range(unsigned long 
start, unsigned long end)
return ret > 0 ? 0 : ret;
 }
 
+/*
+ * Update zone's cma pages counter used for watermark level calculation.
+ */
+static inline void __update_cma_wmark_pages(struct zone *zone, int count)
+{
+   unsigned long flags;
+   spin_lock_irqsave(&zone->lock, flags);
+   zone->min_cma_pages += count;
+   spin_unlock_irqrestore(&zone->lock, flags);
+   setup_per_zone_wmarks();
+}
+
+/*
+ * Trigger memory pressure bump to reclaim some pages in order to be able to
+ * allocate 'count' pages in single page units. Does similar work as
+ *__alloc_pages_slowpath() function.
+ */
+static int __reclaim_pages(struct zone *zone, gfp_t gfp_mask, int count)
+{
+   enum zone_type high_zoneidx = gfp_zone(gfp_mask);
+   struct zonelist *zonelist = node_zonelist(0, gfp_mask);
+   int did_some_progress = 0;
+   int order = 1;
+   unsigned long watermark;
+
+   /*
+* Increase level of watermarks to force kswapd do his job
+* to stabilise at new watermark level.
+*/
+   __modify_min_cma_pages(zone, count);
+
+   /* Obey watermarks as if the page was being allocated */
+   watermark = low_wmark_pages(zone) + count;
+   while (!zone_watermark_ok(zone, 0, watermark, 0, 0)) {
+   wake_all_kswapd(order, zonelist, high_zoneidx, zone_idx(zone));
+
+   did_some_progress = __perform_reclaim(gfp_mask, order, zonelist,
+ NULL);
+   if (!did_some_progress) {
+   /* Exhausted what can be done so it's blamo time */
+   out_of_memory(zonelist, gfp_mask, order, NULL);
+   }
+   }
+
+   /* Restore original watermark levels. */
+   __modify_min_cma_pages(zone, -count);
+
+   return count;
+}
+
 /**
  * alloc_contig_range() -- tries to allocate given range of pages
  * @start: start PFN to allocate
@@ -5735,6 +5790,13 @@ int alloc_contig_range(unsigned long start, unsigned 
long end,
goto done;
}
 
+   /*
+* Reclaim enough pages to make sure that contiguous allocation
+* will not starve the system.
+*/
+   __reclaim_pages(zone, GFP_HIGHUSER_MOVABLE, end-start);
+
+   /* Grab isolated pages from freelists. */
outer_end = isolate_freepages_range(outer_start, end);
if (!outer_end) {
ret = -EBUSY;
-- 
1.7.1.569.g6f426

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

[PATCHv21 10/16] mm: Serialize access to min_free_kbytes

2012-02-10 Thread Marek Szyprowski
From: Mel Gorman 

There is a race between the min_free_kbytes sysctl, memory hotplug
and transparent hugepage support enablement.  Memory hotplug uses a
zonelists_mutex to avoid a race when building zonelists. Reuse it to
serialise watermark updates.

[a.p.zijls...@chello.nl: Older patch fixed the race with spinlock]
Signed-off-by: Mel Gorman 
Signed-off-by: Marek Szyprowski 
---
 mm/page_alloc.c |   23 +++
 1 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 7d9f36e..06c66b5 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4976,14 +4976,7 @@ static void setup_per_zone_lowmem_reserve(void)
calculate_totalreserve_pages();
 }
 
-/**
- * setup_per_zone_wmarks - called when min_free_kbytes changes
- * or when memory is hot-{added|removed}
- *
- * Ensures that the watermark[min,low,high] values for each zone are set
- * correctly with respect to min_free_kbytes.
- */
-void setup_per_zone_wmarks(void)
+static void __setup_per_zone_wmarks(void)
 {
unsigned long pages_min = min_free_kbytes >> (PAGE_SHIFT - 10);
unsigned long lowmem_pages = 0;
@@ -5038,6 +5031,20 @@ void setup_per_zone_wmarks(void)
calculate_totalreserve_pages();
 }
 
+/**
+ * setup_per_zone_wmarks - called when min_free_kbytes changes
+ * or when memory is hot-{added|removed}
+ *
+ * Ensures that the watermark[min,low,high] values for each zone are set
+ * correctly with respect to min_free_kbytes.
+ */
+void setup_per_zone_wmarks(void)
+{
+   mutex_lock(&zonelists_mutex);
+   __setup_per_zone_wmarks();
+   mutex_unlock(&zonelists_mutex);
+}
+
 /*
  * The inactive anon list should be small enough that the VM never has to
  * do too much work, but large enough that each inactive page has a chance
-- 
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


[PATCHv21 11/16] mm: extract reclaim code from __alloc_pages_direct_reclaim()

2012-02-10 Thread Marek Szyprowski
This patch extracts common reclaim code from __alloc_pages_direct_reclaim()
function to separate function: __perform_reclaim() which can be later used
by alloc_contig_range().

Signed-off-by: Marek Szyprowski 
Signed-off-by: Kyungmin Park 
Cc: Michal Nazarewicz 
Acked-by: Mel Gorman 
Tested-by: Rob Clark 
Tested-by: Ohad Ben-Cohen 
Tested-by: Benjamin Gaignard 
---
 mm/page_alloc.c |   30 +-
 1 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 06c66b5..793c4e4 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2092,16 +2092,13 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned 
int order,
 }
 #endif /* CONFIG_COMPACTION */
 
-/* The really slow allocator path where we enter direct reclaim */
-static inline struct page *
-__alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order,
-   struct zonelist *zonelist, enum zone_type high_zoneidx,
-   nodemask_t *nodemask, int alloc_flags, struct zone *preferred_zone,
-   int migratetype, unsigned long *did_some_progress)
+/* Perform direct synchronous page reclaim */
+static int
+__perform_reclaim(gfp_t gfp_mask, unsigned int order, struct zonelist 
*zonelist,
+ nodemask_t *nodemask)
 {
-   struct page *page = NULL;
struct reclaim_state reclaim_state;
-   bool drained = false;
+   int progress;
 
cond_resched();
 
@@ -2112,7 +2109,7 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int 
order,
reclaim_state.reclaimed_slab = 0;
current->reclaim_state = &reclaim_state;
 
-   *did_some_progress = try_to_free_pages(zonelist, order, gfp_mask, 
nodemask);
+   progress = try_to_free_pages(zonelist, order, gfp_mask, nodemask);
 
current->reclaim_state = NULL;
lockdep_clear_current_reclaim_state();
@@ -2120,6 +2117,21 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned 
int order,
 
cond_resched();
 
+   return progress;
+}
+
+/* The really slow allocator path where we enter direct reclaim */
+static inline struct page *
+__alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order,
+   struct zonelist *zonelist, enum zone_type high_zoneidx,
+   nodemask_t *nodemask, int alloc_flags, struct zone *preferred_zone,
+   int migratetype, unsigned long *did_some_progress)
+{
+   struct page *page = NULL;
+   bool drained = false;
+
+   *did_some_progress = __perform_reclaim(gfp_mask, order, zonelist,
+  nodemask);
if (unlikely(!(*did_some_progress)))
return NULL;
 
-- 
1.7.1.569.g6f426

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


Re: omap3isp: sequence number in v4l2 buffer not incremented

2012-02-10 Thread Laurent Pinchart
Hi Kruno,

On Friday 10 February 2012 17:18:22 Kruno Mrak wrote:
> Laurent,
> 
> thank you for the patch.
> It was a bit tricky to get it work as our kernel is based
> on 2.6.38, but i succeeded.
> The frame_number is incremented now.

Thanks for the confirmation. I'll test the patch with the CCP2 and CSI2 
receivers, and I'll then push it to mainline.

> The following changes are not clear to me, are they really necessary to
> get frame_number incremented?

It isn't when using the CCDC parallel input. It removes frame number 
incrementation from the CCP2 module, as the frame number is now incremented in 
the CCDC module.

> @@ -350,7 +337,6 @@ static void ccp2_lcx_config(struct isp_ccp2_device
> *ccp2,
> ISPCCP2_LC01_IRQSTATUS_LC0_CRC_IRQ |
> ISPCCP2_LC01_IRQSTATUS_LC0_FSP_IRQ |
> ISPCCP2_LC01_IRQSTATUS_LC0_FW_IRQ |
> -   ISPCCP2_LC01_IRQSTATUS_LC0_FS_IRQ |
> ISPCCP2_LC01_IRQSTATUS_LC0_FSC_IRQ |
> ISPCCP2_LC01_IRQSTATUS_LC0_SSC_IRQ;
> 
> @@ -378,21 +378,17 @@ static void csi2_timing_config(struct isp_device *isp,
> static void csi2_irq_ctx_set(struct isp_device *isp,
>struct isp_csi2_device *csi2, int enable)
>  {
> - u32 reg = ISPCSI2_CTX_IRQSTATUS_FE_IRQ;
>   int i;
> 
> - if (csi2->use_fs_irq)
> - reg |= ISPCSI2_CTX_IRQSTATUS_FS_IRQ;
> -
>   for (i = 0; i < 8; i++) {
> - isp_reg_writel(isp, reg, csi2->regs1,
> + isp_reg_writel(isp, ISPCSI2_CTX_IRQSTATUS_FE_IRQ, csi2->regs1,
>  ISPCSI2_CTX_IRQSTATUS(i));
>   if (enable)
>   isp_reg_set(isp, csi2->regs1, ISPCSI2_CTX_IRQENABLE(i),
> - reg);
> + ISPCSI2_CTX_IRQSTATUS_FE_IRQ);
>   else
>   isp_reg_clr(isp, csi2->regs1, ISPCSI2_CTX_IRQENABLE(i),
> - reg);
> + ISPCSI2_CTX_IRQSTATUS_FE_IRQ);
>   }
>  }

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


General question about IR remote signals from USB DVB tuner

2012-02-10 Thread Jan Panteltje
I recently bought a Terratec cinergy S2 USB  HD receiver.
I got everything working just fine in Linux and get excellent
reception.
This thing came with a small remote controller, and I notice
that the  output of this remote appears as ASCII characters on stdin,
on any terminal that I open...
Wrote a small GUI application that sets the input focus to a hidden
input field, and can process the numbers from this remote that way,
but of course this only works if the mouse has selected that application.

Thinking about this I think that the driver dumps the received remote
control characters simply to stdout.
If this is so, does there perhaps exists a /dev/dvb/adapterX/remoteX
interface in the specs so I could modify that driver to send the codes
there?
If not how about adding such a thing?
The application can then in a separate thread for example open
this device and use those codes.
This little remote has it all:
 numbers 0 to 9, ENTER, channel up /down, power, mute, EPG,
volume, what not.
Sorry I a am bit rusty, been many years since I did any programming
for DVB, so may be this already exists?
So much seems to have changed.
 
Any suggestions would be appreciated

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


Re: omap3isp: sequence number in v4l2 buffer not incremented

2012-02-10 Thread Kruno Mrak
Laurent,

thank you for the patch.
It was a bit tricky to get it work as our kernel is based
on 2.6.38, but i succeeded.
The frame_number is incremented now.

The following changes are not clear to me, are they really necessary to
get frame_number incremented?

@@ -350,7 +337,6 @@ static void ccp2_lcx_config(struct isp_ccp2_device
*ccp2,
  ISPCCP2_LC01_IRQSTATUS_LC0_CRC_IRQ |
  ISPCCP2_LC01_IRQSTATUS_LC0_FSP_IRQ |
  ISPCCP2_LC01_IRQSTATUS_LC0_FW_IRQ |
- ISPCCP2_LC01_IRQSTATUS_LC0_FS_IRQ |
  ISPCCP2_LC01_IRQSTATUS_LC0_FSC_IRQ |
  ISPCCP2_LC01_IRQSTATUS_LC0_SSC_IRQ;

@@ -378,21 +378,17 @@ static void csi2_timing_config(struct isp_device *isp,
 static void csi2_irq_ctx_set(struct isp_device *isp,
 struct isp_csi2_device *csi2, int enable)
 {
-   u32 reg = ISPCSI2_CTX_IRQSTATUS_FE_IRQ;
int i;

-   if (csi2->use_fs_irq)
-   reg |= ISPCSI2_CTX_IRQSTATUS_FS_IRQ;
-
for (i = 0; i < 8; i++) {
-   isp_reg_writel(isp, reg, csi2->regs1,
+   isp_reg_writel(isp, ISPCSI2_CTX_IRQSTATUS_FE_IRQ, csi2->regs1,
   ISPCSI2_CTX_IRQSTATUS(i));
if (enable)
isp_reg_set(isp, csi2->regs1, ISPCSI2_CTX_IRQENABLE(i),
-   reg);
+   ISPCSI2_CTX_IRQSTATUS_FE_IRQ);
else
isp_reg_clr(isp, csi2->regs1, ISPCSI2_CTX_IRQENABLE(i),
-   reg);
+   ISPCSI2_CTX_IRQSTATUS_FE_IRQ);
}
 }

Am 09.02.2012 17:08, schrieb Laurent Pinchart:
> Hi Kruno,
> 
> On Wednesday 25 January 2012 16:34:26 Kruno Mrak wrote:
>> Hello,
>>
>> we have an omap based intelligent camera and image sensor is connected to
>> camera parallel interface. Image capturing via "CCDC output" works fine.
>> When streaming is on and reading "sequence" variable, it shows always -1.
>> Looking at kernel-source ispvideo.c, i found following if-else statement:
>>
>> /* Do frame number propagation only if this is the output video node.
>>   * Frame number either comes from the CSI receivers or it gets
>>   * incremented here if H3A is not active.
>>   * Note: There is no guarantee that the output buffer will finish
>>   * first, so the input number might lag behind by 1 in some cases.
>>   */
>> if (video == pipe->output && !pipe->do_propagation)
>>  buf->vbuf.sequence = atomic_inc_return(&pipe->frame_number);
>> else
>>  buf->vbuf.sequence = atomic_read(&pipe->frame_number);
>>
>> When i change to
>> if (video == pipe->output && pipe->do_propagation)
>> ...
>> the sequence variable is incremented.
>>
>> So my question:
>> Could it be that "pipe->do_propagation" should be tested on true and not on
>> false?
> 
> No, the code is correct here. When do_propagation is true, the pipeline's
> frame number is incremented in the frame start interrupt handler. This allows
> synchronization of buffer sequence numbers with the statistics engine frame
> counts.
> 
>> If this change is wrong, how can i achieve that the sequence number is
>> incremented?
> 
> The driver increments the frame number in the CCP2 and CSI2 receivers
> interrupt handlers. The frame number will thus not be incremented when using
> the CCDC parallel input, which is wrong.
> 
> Does the following patch fix your problem ? I haven't been able to test it
> yet with the CCP2 and CSI2 receivers, I might ask you to test a second
> version. Sakari, could you test the patch on the N900 with the CCP2 receiver ?
> I'm currently travelling and haven't brought mine with me.
> 
>>From c0d23bfa38fc91f33f39bab9328eda3a4481f152 Mon Sep 17 00:00:00 2001
> From: Laurent Pinchart 
> Date: Thu, 9 Feb 2012 17:00:45 +0100
> Subject: [PATCH] omap3isp: Fix frame number propagation
> 
> When propagating the frame number through the pipeline, the frame number
> must be incremented at frame start by the appropriate IRQ handler. This
> was properly handled for the CSI2 and CCP2 receivers, but not when the
> CCDC parallel interface is used.
> 
> ADD frame number incrementation to the HS/VS interrupt handler. As the
> HS/VS interrupt is also generated for frames received by the CSI2 and
> CCP2 receivers, remove explicit propagation handling from the serial
> receivers.
> 
> Reported-by: Kruno Mrak 
> Signed-off-by: Laurent Pinchart 
> ---
>  drivers/media/video/omap3isp/isp.c |8 
>  drivers/media/video/omap3isp/ispccdc.c |3 +++
>  drivers/media/video/omap3isp/ispccp2.c |   22 --
>  drivers/media/video/omap3isp/ispcsi2.c |   19 +++
>  drivers/media/video/omap3isp/ispcsi2.h |1 -
>  5 files changed, 6 insertions(+), 47 deletions(-)
> 
> diff --git a/drivers/media/video/omap3isp/isp.c 
> b/drivers/media/video/omap3isp/isp.c
> index 06afbc1..df6416c 100644
> --- a/drivers/media/video/omap3isp/isp.c
> +++ b/

Re: [PATCH 00/35] Add a driver for Terratec H7

2012-02-10 Thread Jason Krolo

Am 09.02.2012 22:12, schrieb Torfinn Ingolfsen:

Update:

On Thu, Feb 9, 2012 at 12:04 AM, Torfinn Ingolfsen  wrote:

Never mind. after adding this patch:
http://patchwork.linuxtv.org/patch/9691/

and rebuilding the media drivers, the device is now detected:
tingo@kg-f4:~$ dmesg | grep -i terratec
[   19.755806] dvb-usb: found a 'TerraTec DTV StarBox DVB-T/C USB2.0
(az6007)' in warm state.
[   20.949045] DVB: registering new adapter (TerraTec DTV StarBox
DVB-T/C USB2.0 (az6007))
[   23.732039] Registered IR keymap rc-nec-terratec-cinergy-xs
[   23.732442] dvb-usb: TerraTec DTV StarBox DVB-T/C USB2.0 (az6007)
successfully initialized and connected.


I have now tested the TerraTec H7, both with w_scan and with Kaffeine.
Neither of then is able to find any channels from the H7. (The device
is connected to an external power supply). However, if I connect
another device (a PCTV nanoStick T2 290e) to the same cable, both
w_scan and Kaffeine find all the channels for my provider, and I can
watch the clear (unencrypted) ones in Kaffeine.

How can I debug the H7 further?





Thank you for the hint to the usb-pid patch. That brought my h7 the 
first dvb pictures with linux.


We both seem to have the second revision device. My has the 0ccd:10a3 
usb-id.
w_scan and dvbscan find channels. With czap i have a signal 
(FE_HAS_LOCK) but no transport traffic. With mencoder i'm able to get an 
mpeg, which is corrupt, but there are pictures and sporadically sound, 
the device receives the dvb-c stream.

Typical mencoder statement is: skipping/duplicate frame.

I didn't test dvb-t terrestrial, but under /dev/dvb i have only one 
adapter. Is there no need for two, one for cable, another for terrestrial?



ps:
Sorry I never used a newsgroup about nttp, with this post i try to get 
access. I write from moz-thunderbird and don't know if this message will 
come through. Thanks. ;)


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


Re: OV2640 and iMX25PDK - help needed

2012-02-10 Thread Fabio Estevam
Hi Gonzalo,

On 2/10/12, Fernandez Gonzalo  wrote:

> I've been finally able to attach the ov2640 camera in the i.MX25PDK.
> I've had some problems with the clocks, but a quick dirty fix looks to
> solve this issue (I'll work on cleaner solution later).

Great to know that you are having progress.

> Now I have to send the camera stream to "somewhere". In the example
> provided by Freescale based on L2.6.31, "somewhere" is the framebuffer,
> and this is done using VIDIOC_S_FBUF and VIDIOC_OVERLAY ioctls. As these
> 2 ioctls are not currently implemented in soc_camera.c, I was wondefing
> if it exist a different preferred method to implement this
> functionality?

In order to test if you are capturing the image correctly you can
launch a Gstreamer pipeline and use filesink to save the stream to a
file.

Or you can also send it to the framebuffer, with something like:

gst-launch -v v4l2src device=/dev/video0 !\
video/x-raw-yuv,width=320,height=240 !\
ffmpegcolorspace ! fbdevsink

Regards,

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


RE: OV2640 and iMX25PDK - help needed

2012-02-10 Thread Fernandez Gonzalo
Hi again,

>Hi,
>
>On 2 February 2012 15:01, Fabio Estevam  wrote:
>> On 2/1/12, Guennadi Liakhovetski  wrote:
>>> Hello Gonzalo
>>>
>>> On Tue, 31 Jan 2012, Fernandez Gonzalo wrote:
>>>
 Hi all,

 I've been working for a while with an iMX25PDK using the BSP
provided by
 Freescale (L2.6.31). The camera driver (V4L2-int) and examples do
the
 job quite well but I need to move my design to a more recent
kernel.
 I've been extensively googling but haven't found any info/examples
about
 how to run the mx2_camera driver in the i.MX25PDK. I'm stuck at
this,
 could someone point me in the right direction? Thank you in
advance...
>>>
>>> i.MX25PDK is supported in the mainline kernel
>>> (arch/arm/mach-imx/mach-mx25_3ds.c), but it doesn't attach any
cameras.
>>> Unfortunately, I also don't currently see any i.MX2x platforms in
the
>>> mainline with cameras, so, you have to begin by looking at
>>> arch/arm/plat-mxc/include/mach/mx2_cam.h, at
>>> arch/arm/plat-mxc/devices/platform-mx2-camera.c for the
>>> imx27_add_mx2_camera() function and maybe some i.MX3x or i.MX1
examples.
>>
>> Javier has been doing a lot of work on mx2-camera lately.
>>
>> Javier,
>>
>> Is mach-imx27_visstrim_m10 board connected to a CMOS camera? Do you
>> have patches for adding camera support to mach-imx27_visstrim_m10?
>
>visstrim_m10 is connected to a tvp5150 but it uses the same interface
>as a CMOS sensor. Let me find some time to send a patch that I have
>pending in my queue. Then it can be used by Gonzalo as a reference.
>
>Regards.
>-- 
>Javier Martin
>Vista Silicon S.L.
>CDTUC - FASE C - Oficina S-345
>Avda de los Castros s/n
>39005- Santander. Cantabria. Spain
>+34 942 25 32 60
>www.vista-silicon.com

I've been finally able to attach the ov2640 camera in the i.MX25PDK.
I've had some problems with the clocks, but a quick dirty fix looks to
solve this issue (I'll work on cleaner solution later).

Now I have to send the camera stream to "somewhere". In the example
provided by Freescale based on L2.6.31, "somewhere" is the framebuffer,
and this is done using VIDIOC_S_FBUF and VIDIOC_OVERLAY ioctls. As these
2 ioctls are not currently implemented in soc_camera.c, I was wondefing
if it exist a different preferred method to implement this
functionality?

Regards,
Gonzalo. 
--
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 11/15] mm: trigger page reclaim in alloc_contig_range() to stabilize watermarks

2012-02-10 Thread Marek Szyprowski
Hello,

On Friday, February 10, 2012 12:19 PM Mel Gorman wrote:

> On Wed, Feb 08, 2012 at 04:14:46PM +0100, Marek Szyprowski wrote:
> > > > 
> > > > +static int __reclaim_pages(struct zone *zone, gfp_t gfp_mask, int 
> > > > count)
> > > > +{
> > > > +   enum zone_type high_zoneidx = gfp_zone(gfp_mask);
> > > > +   struct zonelist *zonelist = node_zonelist(0, gfp_mask);
> > > > +   int did_some_progress = 0;
> > > > +   int order = 1;
> > > > +   unsigned long watermark;
> > > > +
> > > > +   /*
> > > > +* Increase level of watermarks to force kswapd do his job
> > > > +* to stabilize at new watermark level.
> > > > +*/
> > > > +   min_free_kbytes += count * PAGE_SIZE / 1024;
> > >
> > > There is a risk of overflow here although it is incredibly
> > > small. Still, a potentially nicer way of doing this was
> > >
> > > count << (PAGE_SHIFT - 10)
> > >
> > > > +   setup_per_zone_wmarks();
> > > > +
> > >
> > > Nothing prevents two or more processes updating the wmarks at the same
> > > time which is racy and unpredictable. Today it is not much of a problem
> > > but CMA makes this path hotter than it was and you may see weirdness
> > > if two processes are updating zonelists at the same time. Swap-over-NFS
> > > actually starts with a patch that serialises setup_per_zone_wmarks()
> > >
> > > You also potentially have a BIG problem here if this happens
> > >
> > > min_free_kbytes = 32768
> > > Process a: min_free_kbytes  += 65536
> > > Process a: start direct reclaim
> > > echo 16374 > /proc/sys/vm/min_free_kbytes
> > > Process a: exit direct_reclaim
> > > Process a: min_free_kbytes -= 65536
> > >
> > > min_free_kbytes now wraps negative and the machine hangs.
> > >
> > > The damage is confined to CMA though so I am not going to lose sleep
> > > over it but you might want to consider at least preventing parallel
> > > updates to min_free_kbytes from proc.
> >
> > Right. This approach was definitely too hacky. What do you think about 
> > replacing
> > it with the following code (I assume that setup_per_zone_wmarks() 
> > serialization
> > patch will be merged anyway so I skipped it here):
> >
> 
> It's part of a larger series and the rest of that series is
> controversial. That single patch can be split out obviously so feel free
> to add it to your series and stick your Signed-off-by on the end of it.

Ok, I will grab it from that series.

> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index 82f4fa5..bb9ae41 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -371,6 +371,13 @@ struct zone {
> > /* see spanned/present_pages for more description */
> > seqlock_t   span_seqlock;
> >  #endif
> > +#ifdef CONFIG_CMA
> > +   /*
> > +* CMA needs to increase watermark levels during the allocation
> > +* process to make sure that the system is not starved.
> > +*/
> > +   unsigned long   min_cma_pages;
> > +#endif
> > struct free_areafree_area[MAX_ORDER];
> >
> >  #ifndef CONFIG_SPARSEMEM
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 824fb37..1ca52f0 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -5044,6 +5044,11 @@ void setup_per_zone_wmarks(void)
> >
> > zone->watermark[WMARK_LOW]  = min_wmark_pages(zone) + (tmp 
> > >> 2);
> > zone->watermark[WMARK_HIGH] = min_wmark_pages(zone) + (tmp 
> > >> 1);
> > +#ifdef CONFIG_CMA
> > +   zone->watermark[WMARK_MIN] += zone->min_cma_pages;
> > +   zone->watermark[WMARK_LOW] += zone->min_cma_pages;
> > +   zone->watermark[WMARK_HIGH] += zone->min_cma_pages;
> > +#endif
> > setup_zone_migrate_reserve(zone);
> > spin_unlock_irqrestore(&zone->lock, flags);
> > }
> 
> This is better in that it is not vunerable to parallel updates of
> min_free_kbytes. It would be slightly tidier to introduce something
> like cma_wmark_pages() that returns min_cma_pages if CONFIG_CMA and 0
> otherwise. Use the helper to get right of this ifdef CONFIG_CMA within
> setup_per_zone_wmarks().

Thanks for the hint. I will submit this change soon.
 
> You'll still have the problem of kswapd not taking CMA pages properly into
> account when deciding whether to reclaim or not though.

This will only affect CMA clients, I hope we can fix this later once the patches
get merged. I would really like to get it into v3.4, what means that it should 
be
tested in next asap.

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


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


[PATCH] mt2063: remove mt2063_setTune from header

2012-02-10 Thread Danny Kukawka
Commit 99ac54125490f16f7434f82fcb73bbb88290b38e removed
the function mt2063_setTune() from mt2063.c. Remove it
also from the header file.

Signed-off-by: Danny Kukawka 
---
 drivers/media/common/tuners/mt2063.h |4 
 1 files changed, 0 insertions(+), 4 deletions(-)

diff --git a/drivers/media/common/tuners/mt2063.h 
b/drivers/media/common/tuners/mt2063.h
index 62d0e8e..3f5cfd9 100644
--- a/drivers/media/common/tuners/mt2063.h
+++ b/drivers/media/common/tuners/mt2063.h
@@ -23,10 +23,6 @@ static inline struct dvb_frontend *mt2063_attach(struct 
dvb_frontend *fe,
return NULL;
 }
 
-int mt2063_setTune(struct dvb_frontend *fe, u32 f_in,
-  u32 bw_in,
-  enum MTTune_atv_standard tv_type);
-
 /* FIXME: Should use the standard DVB attachment interfaces */
 unsigned int tuner_MT2063_SoftwareShutdown(struct dvb_frontend *fe);
 unsigned int tuner_MT2063_ClearPowerMaskBits(struct dvb_frontend *fe);
-- 
1.7.7.3

--
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] s5p-mfc: Added support for clk_prepare

2012-02-10 Thread Kamil Debski
Signed-off-by: Kamil Debski 
Signed-off-by: Kyungmin Park 
Reviewed-by: Sylwester Nawrocki 
---
 drivers/media/video/s5p-mfc/s5p_mfc_pm.c |   24 ++--
 1 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_pm.c 
b/drivers/media/video/s5p-mfc/s5p_mfc_pm.c
index f6a3035..738a607 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc_pm.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_pm.c
@@ -41,15 +41,29 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
pm->clock_gate = clk_get(&dev->plat_dev->dev, MFC_GATE_CLK_NAME);
if (IS_ERR(pm->clock_gate)) {
mfc_err("Failed to get clock-gating control\n");
-   ret = -ENOENT;
+   ret = PTR_ERR(pm->clock_gate);
goto err_g_ip_clk;
}
+
+   ret = clk_prepare(pm->clock_gate);
+   if (ret) {
+   mfc_err("Failed to prepare clock-gating control\n");
+   goto err_p_ip_clk;
+   }
+
pm->clock = clk_get(&dev->plat_dev->dev, MFC_CLKNAME);
if (IS_ERR(pm->clock)) {
mfc_err("Failed to get MFC clock\n");
-   ret = -ENOENT;
+   ret = PTR_ERR(pm->clock);
goto err_g_ip_clk_2;
}
+
+   ret = clk_prepare(pm->clock);
+   if (ret) {
+   mfc_err("Failed to prepare MFC clock\n");
+   goto err_p_ip_clk_2;
+   }
+
atomic_set(&pm->power, 0);
 #ifdef CONFIG_PM_RUNTIME
pm->device = &dev->plat_dev->dev;
@@ -59,7 +73,11 @@ int s5p_mfc_init_pm(struct s5p_mfc_dev *dev)
atomic_set(&clk_ref, 0);
 #endif
return 0;
+err_p_ip_clk_2:
+   clk_put(pm->clock);
 err_g_ip_clk_2:
+   clk_unprepare(pm->clock_gate);
+err_p_ip_clk:
clk_put(pm->clock_gate);
 err_g_ip_clk:
return ret;
@@ -67,7 +85,9 @@ err_g_ip_clk:
 
 void s5p_mfc_final_pm(struct s5p_mfc_dev *dev)
 {
+   clk_unprepare(pm->clock_gate);
clk_put(pm->clock_gate);
+   clk_unprepare(pm->clock);
clk_put(pm->clock);
 #ifdef CONFIG_PM_RUNTIME
pm_runtime_disable(pm->device);
-- 
1.7.0.4

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


[PATCH] s5p-g2d: Added locking for writing control values to registers

2012-02-10 Thread Kamil Debski
While at it I have removed an unused default case (control fw takes care of 
that).

Signed-off-by: Kamil Debski 
Signed-off-by: Kyungmin Park 
Reviewed-by: Sylwester Nawrocki 
---
 drivers/media/video/s5p-g2d/g2d.c |   14 ++
 drivers/media/video/s5p-g2d/g2d.h |2 +-
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/media/video/s5p-g2d/g2d.c 
b/drivers/media/video/s5p-g2d/g2d.c
index e41357f..789de74 100644
--- a/drivers/media/video/s5p-g2d/g2d.c
+++ b/drivers/media/video/s5p-g2d/g2d.c
@@ -178,6 +178,9 @@ static int g2d_s_ctrl(struct v4l2_ctrl *ctrl)
 {
struct g2d_ctx *ctx = container_of(ctrl->handler, struct g2d_ctx,
ctrl_handler);
+   unsigned long flags;
+
+   spin_lock_irqsave(&ctx->dev->ctrl_lock, flags);
switch (ctrl->id) {
case V4L2_CID_COLORFX:
if (ctrl->val == V4L2_COLORFX_NEGATIVE)
@@ -190,10 +193,8 @@ static int g2d_s_ctrl(struct v4l2_ctrl *ctrl)
ctx->flip = ctx->ctrl_hflip->val | (ctx->ctrl_vflip->val << 1);
break;
 
-   default:
-   v4l2_err(&ctx->dev->v4l2_dev, "unknown control\n");
-   return -EINVAL;
}
+   spin_unlock_irqrestore(&ctx->dev->ctrl_lock, flags);
return 0;
 }
 
@@ -558,6 +559,7 @@ static void device_run(void *prv)
struct g2d_ctx *ctx = prv;
struct g2d_dev *dev = ctx->dev;
struct vb2_buffer *src, *dst;
+   unsigned long flags;
u32 cmd = 0;
 
dev->curr = ctx;
@@ -568,6 +570,8 @@ static void device_run(void *prv)
clk_enable(dev->gate);
g2d_reset(dev);
 
+   spin_lock_irqsave(&dev->ctrl_lock, flags);
+
g2d_set_src_size(dev, &ctx->in);
g2d_set_src_addr(dev, vb2_dma_contig_plane_dma_addr(src, 0));
 
@@ -582,6 +586,8 @@ static void device_run(void *prv)
cmd |= g2d_cmd_stretch(1);
g2d_set_cmd(dev, cmd);
g2d_start(dev);
+
+   spin_unlock_irqrestore(&dev->ctrl_lock, flags);
 }
 
 static irqreturn_t g2d_isr(int irq, void *prv)
@@ -671,7 +677,7 @@ static int g2d_probe(struct platform_device *pdev)
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (!dev)
return -ENOMEM;
-   spin_lock_init(&dev->irqlock);
+   spin_lock_init(&dev->ctrl_lock);
mutex_init(&dev->mutex);
atomic_set(&dev->num_inst, 0);
init_waitqueue_head(&dev->irq_queue);
diff --git a/drivers/media/video/s5p-g2d/g2d.h 
b/drivers/media/video/s5p-g2d/g2d.h
index 78848d2..1b82065 100644
--- a/drivers/media/video/s5p-g2d/g2d.h
+++ b/drivers/media/video/s5p-g2d/g2d.h
@@ -20,7 +20,7 @@ struct g2d_dev {
struct v4l2_m2m_dev *m2m_dev;
struct video_device *vfd;
struct mutexmutex;
-   spinlock_t  irqlock;
+   spinlock_t  ctrl_lock;
atomic_tnum_inst;
struct vb2_alloc_ctx*alloc_ctx;
struct resource *res_regs;
-- 
1.7.0.4

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


[PATCH] s5p-g2d: Added support for clk_prepare

2012-02-10 Thread Kamil Debski
Signed-off-by: Kamil Debski 
Signed-off-by: Kyungmin Park 
Reviewed-by: Sylwester Nawrocki 
---
 drivers/media/video/s5p-g2d/g2d.c |   22 --
 1 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/s5p-g2d/g2d.c 
b/drivers/media/video/s5p-g2d/g2d.c
index febaa67..351080a 100644
--- a/drivers/media/video/s5p-g2d/g2d.c
+++ b/drivers/media/video/s5p-g2d/g2d.c
@@ -693,18 +693,30 @@ static int g2d_probe(struct platform_device *pdev)
goto unmap_regs;
}
 
+   ret = clk_prepare(dev->clk);
+   if (ret) {
+   dev_err(&pdev->dev, "failed to prepare g2d clock\n");
+   goto put_clk;
+   }
+
dev->gate = clk_get(&pdev->dev, "fimg2d");
if (IS_ERR_OR_NULL(dev->gate)) {
dev_err(&pdev->dev, "failed to get g2d clock gate\n");
ret = -ENXIO;
-   goto put_clk;
+   goto unprep_clk;
+   }
+
+   ret = clk_prepare(dev->gate);
+   if (ret) {
+   dev_err(&pdev->dev, "failed to prepare g2d clock gate\n");
+   goto put_clk_gate;
}
 
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(&pdev->dev, "failed to find IRQ\n");
ret = -ENXIO;
-   goto put_clk_gate;
+   goto unprep_clk_gate;
}
 
dev->irq = res->start;
@@ -764,8 +776,12 @@ alloc_ctx_cleanup:
vb2_dma_contig_cleanup_ctx(dev->alloc_ctx);
 rel_irq:
free_irq(dev->irq, dev);
+unprep_clk_gate:
+   clk_unprepare(dev->gate);
 put_clk_gate:
clk_put(dev->gate);
+unprep_clk:
+   clk_unprepare(dev->clk);
 put_clk:
clk_put(dev->clk);
 unmap_regs:
@@ -787,7 +803,9 @@ static int g2d_remove(struct platform_device *pdev)
v4l2_device_unregister(&dev->v4l2_dev);
vb2_dma_contig_cleanup_ctx(dev->alloc_ctx);
free_irq(dev->irq, dev);
+   clk_unprepare(dev->gate);
clk_put(dev->gate);
+   clk_unprepare(dev->clk);
clk_put(dev->clk);
iounmap(dev->regs);
release_resource(dev->res_regs);
-- 
1.7.0.4

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


Re: [Q] Interleaved formats on the media bus

2012-02-10 Thread Guennadi Liakhovetski
On Fri, 10 Feb 2012, Sylwester Nawrocki wrote:

> On 02/10/2012 12:15 PM, Guennadi Liakhovetski wrote:
>  On 02/10/2012 09:42 AM, Guennadi Liakhovetski wrote:
> > ...thinking about this interleaved data, is there anything else left, 
> > that 
> > the following scheme would be failing to describe:
> >
> > * The data is sent in repeated blocks (periods)
> 
>  The data is sent in irregular chunks of varying size (few hundred of 
>  bytes
>  for example).
> >>>
> >>> Right, the data includes headers. How about sensors providing 
> >>> header-parsing callbacks?
> >>
> >> This implies processing of headers/footers in kernel space to some generic 
> >> format. It might work, but sometimes there might be an unwanted 
> >> performance 
> >> loss. However I wouldn't expect it to be that significant, depends on how 
> >> the format of an embedded data from the sensor looks like. Processing 4KiB
> >> of data could be acceptable.
> > 
> > In principle I agree - (ideally) no processing in the kernel _at all_. 
> > Just pass the complete frame data as is to the user-space. But if we need 
> > any internal knowledge at all about the data, maybe callbacks would be a 
> > better option, than trying to develop a generic descriptor. Perhaps, 
> > something like "get me the location of n'th block of data of format X."
> 
> Hmm, I thought about only processing frame embedded data to some generic
> format. I find the callbacks for extracting the data in the kernel 
> impractical, with full HD video stream you may want to use some sort of
> hardware accelerated processing, like using NEON for example. We can 
> allow this only by leaving the deinterleave process to the user space.

Sorry for confusion:-) I'm not proposing to implement this now nor do I 
have a specific use-case for this. This was just an abstract idea about 
how we could do this _if_ we ever need any internal information about the 
data anywhere outside of the sensor driver. So, so far this doesn't have 
any practical implications.

OTOH - how we parse the data in the user-space. The obvious way would be 
the one, that seems to be currently favoured here too - just use a 
vendor-specific fourcc. OTOH, maybe it would be better to do something 
like the above - define new (subdev) IOCTLs to parse headers and extract 
necessary data blocks. Yes, it adds overhead, but if the user-space anyway 
has to "manually" process the data, maybe this could be tolerated.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Q] Interleaved formats on the media bus

2012-02-10 Thread Sylwester Nawrocki
On 02/10/2012 12:15 PM, Guennadi Liakhovetski wrote:
 On 02/10/2012 09:42 AM, Guennadi Liakhovetski wrote:
> ...thinking about this interleaved data, is there anything else left, 
> that 
> the following scheme would be failing to describe:
>
> * The data is sent in repeated blocks (periods)

 The data is sent in irregular chunks of varying size (few hundred of bytes
 for example).
>>>
>>> Right, the data includes headers. How about sensors providing 
>>> header-parsing callbacks?
>>
>> This implies processing of headers/footers in kernel space to some generic 
>> format. It might work, but sometimes there might be an unwanted performance 
>> loss. However I wouldn't expect it to be that significant, depends on how 
>> the format of an embedded data from the sensor looks like. Processing 4KiB
>> of data could be acceptable.
> 
> In principle I agree - (ideally) no processing in the kernel _at all_. 
> Just pass the complete frame data as is to the user-space. But if we need 
> any internal knowledge at all about the data, maybe callbacks would be a 
> better option, than trying to develop a generic descriptor. Perhaps, 
> something like "get me the location of n'th block of data of format X."

Hmm, I thought about only processing frame embedded data to some generic
format. I find the callbacks for extracting the data in the kernel 
impractical, with full HD video stream you may want to use some sort of
hardware accelerated processing, like using NEON for example. We can 
allow this only by leaving the deinterleave process to the user space.

> Notice, this does not (necessarily) have anything to do with the previous 
> discussion, concerning the way, how the CSI receiver should be getting its 
> configuration.

--

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


Re: [PATCH 11/15] mm: trigger page reclaim in alloc_contig_range() to stabilize watermarks

2012-02-10 Thread Mel Gorman
On Wed, Feb 08, 2012 at 04:14:46PM +0100, Marek Szyprowski wrote:
> > > 
> > > +static int __reclaim_pages(struct zone *zone, gfp_t gfp_mask, int count)
> > > +{
> > > + enum zone_type high_zoneidx = gfp_zone(gfp_mask);
> > > + struct zonelist *zonelist = node_zonelist(0, gfp_mask);
> > > + int did_some_progress = 0;
> > > + int order = 1;
> > > + unsigned long watermark;
> > > +
> > > + /*
> > > +  * Increase level of watermarks to force kswapd do his job
> > > +  * to stabilize at new watermark level.
> > > +  */
> > > + min_free_kbytes += count * PAGE_SIZE / 1024;
> > 
> > There is a risk of overflow here although it is incredibly
> > small. Still, a potentially nicer way of doing this was
> > 
> > count << (PAGE_SHIFT - 10)
> > 
> > > + setup_per_zone_wmarks();
> > > +
> > 
> > Nothing prevents two or more processes updating the wmarks at the same
> > time which is racy and unpredictable. Today it is not much of a problem
> > but CMA makes this path hotter than it was and you may see weirdness
> > if two processes are updating zonelists at the same time. Swap-over-NFS
> > actually starts with a patch that serialises setup_per_zone_wmarks()
> > 
> > You also potentially have a BIG problem here if this happens
> > 
> > min_free_kbytes = 32768
> > Process a: min_free_kbytes  += 65536
> > Process a: start direct reclaim
> > echo 16374 > /proc/sys/vm/min_free_kbytes
> > Process a: exit direct_reclaim
> > Process a: min_free_kbytes -= 65536
> > 
> > min_free_kbytes now wraps negative and the machine hangs.
> > 
> > The damage is confined to CMA though so I am not going to lose sleep
> > over it but you might want to consider at least preventing parallel
> > updates to min_free_kbytes from proc.
> 
> Right. This approach was definitely too hacky. What do you think about 
> replacing 
> it with the following code (I assume that setup_per_zone_wmarks() 
> serialization 
> patch will be merged anyway so I skipped it here):
> 

It's part of a larger series and the rest of that series is
controversial. That single patch can be split out obviously so feel free
to add it to your series and stick your Signed-off-by on the end of it.

> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 82f4fa5..bb9ae41 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -371,6 +371,13 @@ struct zone {
> /* see spanned/present_pages for more description */
> seqlock_t   span_seqlock;
>  #endif
> +#ifdef CONFIG_CMA
> +   /*
> +* CMA needs to increase watermark levels during the allocation
> +* process to make sure that the system is not starved.
> +*/
> +   unsigned long   min_cma_pages;
> +#endif
> struct free_areafree_area[MAX_ORDER];
> 
>  #ifndef CONFIG_SPARSEMEM
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 824fb37..1ca52f0 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5044,6 +5044,11 @@ void setup_per_zone_wmarks(void)
> 
> zone->watermark[WMARK_LOW]  = min_wmark_pages(zone) + (tmp >> 
> 2);
> zone->watermark[WMARK_HIGH] = min_wmark_pages(zone) + (tmp >> 
> 1);
> +#ifdef CONFIG_CMA
> +   zone->watermark[WMARK_MIN] += zone->min_cma_pages;
> +   zone->watermark[WMARK_LOW] += zone->min_cma_pages;
> +   zone->watermark[WMARK_HIGH] += zone->min_cma_pages;
> +#endif
> setup_zone_migrate_reserve(zone);
> spin_unlock_irqrestore(&zone->lock, flags);
> }

This is better in that it is not vunerable to parallel updates of
min_free_kbytes. It would be slightly tidier to introduce something
like cma_wmark_pages() that returns min_cma_pages if CONFIG_CMA and 0
otherwise. Use the helper to get right of this ifdef CONFIG_CMA within
setup_per_zone_wmarks().

You'll still have the problem of kswapd not taking CMA pages properly into
account when deciding whether to reclaim or not though.

-- 
Mel Gorman
SUSE Labs
--
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: [Q] Interleaved formats on the media bus

2012-02-10 Thread Guennadi Liakhovetski
On Fri, 10 Feb 2012, Sylwester Nawrocki wrote:

> On 02/10/2012 11:33 AM, Guennadi Liakhovetski wrote:
> > On Fri, 10 Feb 2012, Sylwester Nawrocki wrote:
> > 
> >> On 02/10/2012 09:42 AM, Guennadi Liakhovetski wrote:
> >>> ...thinking about this interleaved data, is there anything else left, 
> >>> that 
> >>> the following scheme would be failing to describe:
> >>>
> >>> * The data is sent in repeated blocks (periods)
> >>
> >> The data is sent in irregular chunks of varying size (few hundred of bytes
> >> for example).
> > 
> > Right, the data includes headers. How about sensors providing 
> > header-parsing callbacks?
> 
> This implies processing of headers/footers in kernel space to some generic 
> format.
> It might work, but sometimes there might be an unwanted performance loss. 
> However
> I wouldn't expect it to be that significant, depends on how the format of an 
> embedded data from the sensor looks like. Processing 4KiB of data could be 
> acceptable.

In principle I agree - (ideally) no processing in the kernel _at all_. 
Just pass the complete frame data as is to the user-space. But if we need 
any internal knowledge at all about the data, maybe callbacks would be a 
better option, than trying to develop a generic descriptor. Perhaps, 
something like "get me the location of n'th block of data of format X."

Notice, this does not (necessarily) have anything to do with the previous 
discussion, concerning the way, how the CSI receiver should be getting its 
configuration.

Thanks
Guennadi

> I'm assuming here, we want to convert the frame embedded (meta) data for each 
> sensor to some generic description format ? It would have to be then 
> relatively 
> simple, not to increase the frame header size unnecessarily.
> 
> --
> 
> Thanks
> Sylwester

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Q] Interleaved formats on the media bus

2012-02-10 Thread Sylwester Nawrocki
On 02/10/2012 11:33 AM, Guennadi Liakhovetski wrote:
> On Fri, 10 Feb 2012, Sylwester Nawrocki wrote:
> 
>> On 02/10/2012 09:42 AM, Guennadi Liakhovetski wrote:
>>> ...thinking about this interleaved data, is there anything else left, that 
>>> the following scheme would be failing to describe:
>>>
>>> * The data is sent in repeated blocks (periods)
>>
>> The data is sent in irregular chunks of varying size (few hundred of bytes
>> for example).
> 
> Right, the data includes headers. How about sensors providing 
> header-parsing callbacks?

This implies processing of headers/footers in kernel space to some generic 
format.
It might work, but sometimes there might be an unwanted performance loss. 
However
I wouldn't expect it to be that significant, depends on how the format of an 
embedded data from the sensor looks like. Processing 4KiB of data could be 
acceptable.

I'm assuming here, we want to convert the frame embedded (meta) data for each 
sensor to some generic description format ? It would have to be then relatively 
simple, not to increase the frame header size unnecessarily.

--

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


Re: [Q] Interleaved formats on the media bus

2012-02-10 Thread Guennadi Liakhovetski
On Fri, 10 Feb 2012, Sylwester Nawrocki wrote:

> On 02/10/2012 09:42 AM, Guennadi Liakhovetski wrote:
> > ...thinking about this interleaved data, is there anything else left, that 
> > the following scheme would be failing to describe:
> > 
> > * The data is sent in repeated blocks (periods)
> 
> The data is sent in irregular chunks of varying size (few hundred of bytes
> for example).

Right, the data includes headers. How about sensors providing 
header-parsing callbacks?

Thanks
Guennadi

> 
> > * Each block can be fully described by a list of format specifiers, each 
> > containing
> > ** data format code
> > ** number of alignment bytes
> > ** number of data bytes
> 
> Each frame would have its own list of such format specifiers, as the data
> chunk sizes vary from frame to frame. Therefore the above is unfortunately
> more a frame meta data, rather than a static frame description.
> 
> > Can there actually be anything more complicated than that?
> 
> There is an embedded data at end of frame (could be also at the beginning)
> which describes layout of the interleaved data.
> 
> Some data types would have padding bytes.
> 
> Even if we somehow find a way to describe the frame on media bus, using a set
> of properties, it would be difficult to pass this information to user space.
> A similar description would have to be probably exposed to applications, now
> everything is described in user space by a single fourcc..
> 
> 
> Regards,
> -- 
> Sylwester Nawrocki
> Samsung Poland R&D Center
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Q] Interleaved formats on the media bus

2012-02-10 Thread Sylwester Nawrocki
On 02/10/2012 11:19 AM, Sylwester Nawrocki wrote:
> On 02/10/2012 09:42 AM, Guennadi Liakhovetski wrote:
> Even if we somehow find a way to describe the frame on media bus, using a set
> of properties, it would be difficult to pass this information to user space.
> A similar description would have to be probably exposed to applications, now
> everything is described in user space by a single fourcc..

OK, we could associate a fourcc with an entry of some static table entry,
thus avoiding vendor specific media bus codes and leaving only vendor/sensor
specific fourcc. But still I'm not sure we can come up with a capable enough
frame description.

Thanks,
-- 
Sylwester Nawrocki
Samsung Poland R&D 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: [Q] Interleaved formats on the media bus

2012-02-10 Thread Sylwester Nawrocki
On 02/10/2012 09:42 AM, Guennadi Liakhovetski wrote:
> ...thinking about this interleaved data, is there anything else left, that 
> the following scheme would be failing to describe:
> 
> * The data is sent in repeated blocks (periods)

The data is sent in irregular chunks of varying size (few hundred of bytes
for example).

> * Each block can be fully described by a list of format specifiers, each 
> containing
> ** data format code
> ** number of alignment bytes
> ** number of data bytes

Each frame would have its own list of such format specifiers, as the data
chunk sizes vary from frame to frame. Therefore the above is unfortunately
more a frame meta data, rather than a static frame description.

> Can there actually be anything more complicated than that?

There is an embedded data at end of frame (could be also at the beginning)
which describes layout of the interleaved data.

Some data types would have padding bytes.

Even if we somehow find a way to describe the frame on media bus, using a set
of properties, it would be difficult to pass this information to user space.
A similar description would have to be probably exposed to applications, now
everything is described in user space by a single fourcc..


Regards,
-- 
Sylwester Nawrocki
Samsung Poland R&D 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: [Q] Interleaved formats on the media bus

2012-02-10 Thread Guennadi Liakhovetski
...thinking about this interleaved data, is there anything else left, that 
the following scheme would be failing to describe:

* The data is sent in repeated blocks (periods)
* Each block can be fully described by a list of format specifiers, each 
containing
** data format code
** number of alignment bytes
** number of data bytes

Can there actually be anything more complicated than that?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 3/4] media i.MX27 camera: improve discard buffer handling.

2012-02-10 Thread Guennadi Liakhovetski
Hi Javier

On Fri, 10 Feb 2012, javier Martin wrote:

[snip]

> I'd rather you merge this as it is, because it really fixes a driver
> which is currently buggy. I'll send a clean up series adressing the
> following issues next week:
> 1. Eliminate the unwanted "goto".
> 2. Use list_first_entry() macro.
> 3. Use spin_lock() in ISR.
> 4. Return IRQ_NONE if list is empty and no status bit is set.
> 5. Integrate discard buffers in a more efficient way.

Ok, let's do that.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 3/4] media i.MX27 camera: improve discard buffer handling.

2012-02-10 Thread javier Martin
Hi Guennadi,

On 9 February 2012 23:36, Guennadi Liakhovetski  wrote:
> Hi Javier
>
> On Thu, 9 Feb 2012, javier Martin wrote:
>
>> Hi Guennadi,
>> I understand you are probably quite busy right now but it would be
>> great if you could ack this patch. The sooner you merge it the sooner
>> I will start working on the cleanup series. I've got some time on my
>> hands now.
>
> Yes, I can take this version, at the same time, I have a couple of
> comments, that you might find useful to address in a clean-up patch;-) Or
> just leave them as they are...


Of course,
I'm the most interested person on this driver being as better as possible.

> [anip]
>
>
>> > @@ -1274,6 +1298,15 @@ static irqreturn_t mx27_camera_emma_irq(int 
>> > irq_emma, void *data)
>> >struct mx2_camera_dev *pcdev = data;
>> >unsigned int status = readl(pcdev->base_emma + PRP_INTRSTATUS);
>> >struct mx2_buffer *buf;
>> > +   unsigned long flags;
>> > +
>> > +   spin_lock_irqsave(&pcdev->lock, flags);
>
> It wasn't an accident, that I wrote "spin_lock()" - without the "_irqsave"
> part. You are in an ISR here, and this is the only IRQ, that your driver
> has to protect against, so, here, I think, you don't have to block other
> IRQs.

Ok,
>> > +
>> > +   if (list_empty(&pcdev->active_bufs)) {
>> > +   dev_warn(pcdev->dev, "%s: called while active list is 
>> > empty\n",
>> > +   __func__);
>> > +   goto irq_ok;
>
> This means, you return IRQ_HANDLED here without even checking whether any
> of your status bits are actually set. So, if you get an interrupt here
> with an empty list, it might indeed be the case of a shared IRQ, in which
> case you'd have to return IRQ_NONE.

Got it.

>> > +   }
>> >
>> >if (status & (1 << 7)) { /* overflow */
>> >u32 cntl;
>
> As I said - we can keep this version, but maybe you'll like to improve at
> least the latter of the above two snippets.

I'd rather you merge this as it is, because it really fixes a driver
which is currently buggy. I'll send a clean up series adressing the
following issues next week:
1. Eliminate the unwanted "goto".
2. Use list_first_entry() macro.
3. Use spin_lock() in ISR.
4. Return IRQ_NONE if list is empty and no status bit is set.
5. Integrate discard buffers in a more efficient way.

Regards.
-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html