RE: [PATCH 8/8] OMAP: DSS2: OMAPFB: Reduce stack usage

2011-05-10 Thread aaro.koskinen
Hi, Tomi Valkeinen [tomi.valkei...@ti.com]: omapfb_mode_to_timings() had struct fb_info, struct fb_var and struct fb_ops allocated from stack. This caused the stack usage grow quite high. Use kzalloc to allocate the structs instead. [...] + fbi = kzalloc(sizeof(*fbi), GFP_KERNEL);

RE: Code for v2.6.39 merge window frozen, patches archived

2011-03-15 Thread aaro.koskinen
Hi, From: Cousson, Benoit [b-cous...@ti.com]: On 3/15/2011 6:54 PM, Aaro Koskinen wrote: On Mon, 14 Mar 2011, Tony Lindgren wrote: I've applied few random fix like patches today into omap-for-linus but that's it for this merge window. So let's do some testing with with Stephen's for-next and

RE: [PATCH] arm: mach-omap2: pm: cleanup !CONFIG_SUSPEND handling

2011-01-06 Thread aaro.koskinen
Hi, Kevin Hilman [khil...@ti.com]: Aaro Koskinen aaro.koski...@nokia.com writes: Make !CONFIG_SUSPEND init declarations identical on all OMAPs and eliminate some ifdefs. Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com I like this solution, but it introduces compiler warnings:

RE: [PATCH] arm: mach-omap2: pm: cleanup !CONFIG_SUSPEND handling

2011-01-06 Thread aaro.koskinen
Hi, Russell King - ARM Linux [li...@arm.linux.org.uk]: -static struct platform_suspend_ops omap_pm_ops = { - .begin = omap2_pm_begin, - .enter = omap2_pm_enter, - .end= omap2_pm_end, - .valid = suspend_valid_only_mem, +static const

RE: [PATCH v2] Keyboard: omap-keypad: use matrix_keypad.h

2010-12-20 Thread aaro.koskinen
Hi, From: Janusz Krzysztofik [jkrzy...@tis.icnet.pl] Monday 20 December 2010 16:29:32 Aaro Koskinen wrote: You should update the ams_delta_keymap type as well, otherwise this patch will introduce the following sparse warning: CHECK arch/arm/mach-omap1/board-ams-delta.c

RE: [PATCH v2 1/2] I2C: i2c-omap: Change device name: i2c_omap - omap_i2c

2010-12-09 Thread aaro.koskinen
Hi, Kevin Hilman [khil...@deeprootsystems.com]: Ben Dooks ben-...@fluff.org writes: Renaming stuff like this is going to have an impact on the userspace as anyone looking through /sys's driver heirarchy is going to miss the old name... It all depends if you really want to go ahead with