On Tue, Jun 01, 2010 at 07:43:19AM +0300, Felipe Balbi wrote:
On Mon, May 31, 2010 at 11:44:02PM +0200, ext Arce, Abraham wrote:
diff --git a/arch/arm/plat-omap/include/plat/omap4-keypad.h
b/arch/arm/plat-omap/include/plat/omap4-keypad.h
new file mode 100644
index 000..7a6ce70
---
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Friday, May 28, 2010 2:43 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH 3/4] OMAP: PM: use omap_device API for suspend/resume
Hook into the
On Tue, Jun 01, 2010 at 08:09:54AM +0200, ext Dmitry Torokhov wrote:
There isn't such member in matrix_keymap_data, it only contains length
of the keymap.
sorry, I had the idea in mind that KEY(row, col, val) would do something
different.
--
balbi
DefectiveByDesign.org
--
To unsubscribe
On 06/01/2010 08:34 AM, Venkatraman S wrote:
If you can post them formally as part of the series, I can test and
ack them (with OMAP3, OMAP4)
My original comment was even if these were not implemented due to some
constraints, they should be
mentioned in the code (as TODO / FIXME etc). The caveat
Hi,
ext Arve Hjønnevåg wrote:
It sounded like you were suggesting that initiating suspend from idle
would somehow avoid the race condition with wakeup events. All I'm
saying is that you would need to block suspend in all the same places.
If you don't care about ignoring wakeup events, then
On Mon, 31 May 2010 14:57:22 +0300
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
On Monday 31 May 2010 13:00:21 ext Liam Girdwood wrote:
...
+static int hw_rule_bsize_by_channels(struct snd_pcm_hw_params *params,
+ struct snd_pcm_hw_rule *rule)
+{
+
On Monday 31 May 2010 20:41:12 ext Nishanth Menon wrote:
On 05/31/2010 11:16 AM, Peter Ujfalusi wrote:
Use the actual FIFO size in words as buffer_size on OMAP2.
Change the threshold configuration to use 1 based numbering, when
specifying the allowed threshold maximum or the McBSP threshold
On Tue, 1 Jun 2010 09:47:09 +0300
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
I like the following naming:
omap_mcbsp_hwrule_min_buffersize()
omap_mcbsp_hwrule_max_periodsize()
Looks clear to me.
Also, I think there is no point to limit the lower period size in threshold
mode
to 32,
* Kevin Hilman khil...@deeprootsystems.com [100525 19:07]:
Tero Kristo tero.kri...@nokia.com writes:
From: Tero Kristo tero.kri...@nokia.com
The kernel timer queue is being run currently from a GP timer running in a
one
shot mode, which works in a way that when it expires, it will
On Tuesday 01 June 2010 10:38:28 ext Jarkko Nikula wrote:
On Tue, 1 Jun 2010 09:47:09 +0300
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
I like the following naming:
omap_mcbsp_hwrule_min_buffersize()
omap_mcbsp_hwrule_max_periodsize()
Looks clear to me.
Also, I think there is
Hi
Resending...
On Tuesday 01 June 2010 10:38:28 ext Jarkko Nikula wrote:
On Tue, 1 Jun 2010 09:47:09 +0300
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
I like the following naming:
omap_mcbsp_hwrule_min_buffersize()
omap_mcbsp_hwrule_max_periodsize()
Looks clear to me.
Also,
* Thomas Weber we...@corscience.de [100601 08:31]:
Hello Tony,
can you please add these patches? Or is something to change?
Well this looks OK, but for the next merge window. If you have
some fixes that are real regressions or major bugs as requested
by Linus:
http://lwn.net/Articles/389982/
On Fri, May 28, 2010 at 10:28:04PM -0700, Cory Maccarrone wrote:
This change adds the htc-mmc.c and htc-mmc.h files that
contain common setup code for many OMAP850-based HTC
smartphones. This code is a port of the code used by
the linwizard project to support devices such as the
HTC Wizard,
* Hemanth V heman...@ti.com [100521 09:49]:
From: Hemanth V heman...@ti.com
Date: Thu, 20 May 2010 20:33:03 +0530
Subject: [PATCH] Platform changes for CMA3000 Accelerometer driver
Patch description?
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of
* Grazvydas Ignotas nota...@gmail.com [100527 12:37]:
Define platform data and setup GPIOs so that TI wl1251 wifi chip
and it's driver can function.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
I could have sent this earlier but it depended on the wifi tree,
hope this can still
* Benoit Cousson b-cous...@ti.com [100531 01:57]:
+
+#define NO_EARLY_TIMERS2
The NO_ is a little bit confusing, you should maybe use _COUNT.
Also NR_ is commonly used.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
On Tue, 1 Jun 2010 11:19:30 +0300
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
If threshold is configured to 100 (99 in register), than McBSP will asserts
the
DMA request line, when 100 locations are free. Than DMA has to send 100 words
per DMA request.
So we need to limit the period
* Thara Gopinath th...@ti.com [100529 17:31]:
This patch series converts the OMAP Dual Mode Timer into a
platform driver. This involves using of hwmod structures and
omap_device layer for OMAP2/3/4 dmtimers and generic
linux platform device layer for OMAP1.
As a result of this patch series
- Original Message -
From: Tony Lindgren t...@atomide.com
To: Hemanth V heman...@ti.com
Cc: linux-in...@vger.kernel.org; linux-ker...@vger.kernel.org;
linux-omap@vger.kernel.org
Sent: Tuesday, June 01, 2010 2:05 PM
Subject: Re: [RFC ] [PATCH V2 2/2] Platform changes for CMA3000
*
* Arce, Abraham x0066...@ti.com [100601 00:39]:
Register keyboard device with hwmod framework
Please test this with omap3_defconfig too, and make sure it does not break
things for omap2 and omap3.
+int omap4_init_kp(struct omap4_keypad_platform_data *kp)
+{
+ struct omap_hwmod *oh;
+
Hi,
There is a false positive case that a pointer is calculated by other
methods than the usual container_of macro. kmemleak_ignore can cover
such a false positive, but it would loose the advantage of memory leak
detection. This patch allows kmemleak to work with such false
positives by
From: Hiroshi DOYU hiroshi.d...@nokia.com
For this test case, a pointer is converted to a physical address with
attribution bits. This test can be executed either with special scan
or without special scan. For special scan case, specifying the testing
period second with the kernel module
From: Hiroshi DOYU hiroshi.d...@nokia.com
The fist level iommu page table address is registered with the address
conversion function for kmemleak special scan.
Signed-off-by: Hiroshi DOYU hiroshi.d...@nokia.com
---
arch/arm/plat-omap/iommu.c | 19 +++
1 files changed, 19
From: Hiroshi DOYU hiroshi.d...@nokia.com
There is a false positive case that a pointer is calculated by other
methods than the usual container_of macro. kmemleak_ignore can cover
such a false positive, but it would loose the advantage of memory leak
detection. This patch allows kmemleak to work
On Tuesday 01 June 2010 12:29:21 ext Jarkko Nikula wrote:
On Tue, 1 Jun 2010 11:19:30 +0300
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
If threshold is configured to 100 (99 in register), than McBSP will
asserts the DMA request line, when 100 locations are free. Than DMA has
to send
On Tue, 1 Jun 2010, Neil Brown wrote:
I think you have acknowledged that there is a race with suspend - thanks.
Next step was can it be closed.
You seem to suggest that it can, but you describe it as a work around
rather than a bug fix...
Do you agree that the race is a bug, and therefore
Hi,
[..]
+* We have to override VBUS/ID signals when MUSB is configured into
the
+* host-only mode -- ID pin will float if no cable is connected, so
the
+* controller won't be able to drive VBUS thinking that it's a B-
device.
+* Otherwise, we want to use the OTG mode
On Mon, 31 May 2010, Arve Hjønnevåg wrote:
On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner t...@linutronix.de wrote:
On Mon, 31 May 2010, James Bottomley wrote:
For MSM hardware, it looks possible to unify the S and C states by doing
suspend to ram from idle but I'm not sure how much
On Tue, 1 Jun 2010 13:30:10 +0300
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
Because, if you want to transfer in one SDMA burst more than the space free
in
the McBSP FIFO, than where would the rest go?
I would have expected peripheral to deassert the DMA request but I
haven't read the
Hello,
Changes since RFC v2:
- Comments added explaining the changes, and documenting the API in patch2
- In patch5:
- Variable names changed in the hw_rule function
- hw_rule function got renamed
- The snd_pcm_hw_rule_add calls moved so it anly got set on OMAP3
Intro mail from the previous
Users of McBSP can use the omap_mcbsp_get_fifo_size function to query
the size of the McBSP FIFO.
The function will return the FIFO size in words (the HW maximum).
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
arch/arm/plat-omap/include/plat/mcbsp.h |2 ++
Use the actual FIFO size in words as buffer_size on OMAP2.
Change the threshold configuration to use 1 based numbering, when
specifying the allowed threshold maximum or the McBSP threshold value.
Set the default maximum threshold to (buffer_size - 0x10) intialy.
From users of McBSP, now it is
Sicne the platform data's buffer_size now holds the full size
of the FIFO, there is no longer need to handle the ports
differently.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
arch/arm/plat-omap/mcbsp.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git
Save the word length configuration of McBSP, and use that information
to calculate, and configure the threshold in McBSP.
Previously the calculation was only correct when the stream had 16bit
audio.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
sound/soc/omap/omap-mcbsp.c | 14
OMAP McBSP FIFO is word structured:
McBSP2 has 1024 + 256 = 1280 word long buffer,
McBSP1,3,4,5 has 128 word long buffer
This means, that the size of the FIFO
depends on the McBSP word size configuration.
For example on McBSP3:
16bit samples: size is 128 * 2 = 256 bytes
32bit samples: size is 128
On Tuesday 01 June 2010 14:20:47 ext Jarkko Nikula wrote:
On Tue, 1 Jun 2010 13:30:10 +0300
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
Because, if you want to transfer in one SDMA burst more than the space
free in the McBSP FIFO, than where would the rest go?
I would have expected
On Tue, 1 Jun 2010 14:18:19 +0300
Peter Ujfalusi peter.ujfal...@nokia.com wrote:
Hello,
Changes since RFC v2:
- Comments added explaining the changes, and documenting the API in patch2
- In patch5:
- Variable names changed in the hw_rule function
- hw_rule function got renamed
- The
-Original Message-
From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
Sent: Monday, May 31, 2010 10:59 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv1 1/1] omap3: pm: Delink opp layer and cpufreq
On 05/31/2010 03:39 PM, Sanjeev Premi wrote:
The
On Mon, 31 May 2010, Arve Hjønnevåg wrote:
2010/5/31 Rafael J. Wysocki r...@sisk.pl:
On Monday 31 May 2010, Arve Hjønnevåg wrote:
2010/5/30 Rafael J. Wysocki r...@sisk.pl:
...
I think it makes more sense to block suspend while wakeup events are
pending than blocking it everywhere
Hi,
On Tuesday 01 June 2010 14:18:24 Ujfalusi Peter (Nokia-D/Tampere) wrote:
...
+static int omap_mcbsp_hwrule_min_buffersize(struct snd_pcm_hw_params
*params, +struct snd_pcm_hw_rule *rule)
+{
+ struct snd_interval *buffer_size =
On Tue, Jun 01, 2010 at 02:18:19PM +0300, Peter Ujfalusi wrote:
Changes since RFC v2:
- Comments added explaining the changes, and documenting the API in patch2
- In patch5:
- Variable names changed in the hw_rule function
- hw_rule function got renamed
- The snd_pcm_hw_rule_add calls
OMAP McBSP FIFO is word structured:
McBSP2 has 1024 + 256 = 1280 word long buffer,
McBSP1,3,4,5 has 128 word long buffer
This means, that the size of the FIFO
depends on the McBSP word size configuration.
For example on McBSP3:
16bit samples: size is 128 * 2 = 256 bytes
32bit samples: size is 128
On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
You're the one mentioning x86, not me. I already explained that some
MSM hardware (the G1 for example) has lower power consumption in S3
(which I'm using as an ACPI shorthand for suspend to ram) than any
suspend from idle C
On Tue, 1 Jun 2010, Neil Brown wrote:
With wakeup events the problem isn't so bad. Wakeup events are always
noticed, and if the system is designed properly they will either abort
a suspend-in-progress or else cause the system to resume as soon as the
suspend is complete. (Linux is not
Hi Tony,
Please test this with omap3_defconfig too, and make sure it does not break
things for omap2 and omap3.
Tested, no problems...
+int omap4_init_kp(struct omap4_keypad_platform_data *kp)
+{
+ struct omap_hwmod *oh;
+ struct omap_device *od;
+ struct
On Fri, May 28, 2010 at 10:28 PM, Cory Maccarrone
darkstar6...@gmail.com wrote:
This adds MMC support to the HTC Herald, including importing
the htc-mmc.c and htc-mmc.h code for building.
This change also adds I2C support to the HTC Herald board, as well as
adding the HTCPLD driver for the
On Tue, Jun 1, 2010 at 3:19 AM, Ladislav Michl ladislav.mi...@seznam.cz wrote:
On Fri, May 28, 2010 at 10:28:04PM -0700, Cory Maccarrone wrote:
This change adds the htc-mmc.c and htc-mmc.h files that
contain common setup code for many OMAP850-based HTC
smartphones. This code is a port of the
This change adds in MMC and I2C support to the HTC Herald board, as well
as adding the HTCPLD driver for the PLD used on this phone. It also
adds in the gpio-keys entries for the front directional keys and
selector and the cursor keys on the slide-out keyboard, and gpio-leds
support for the LEDs
On Tue, Jun 1, 2010 at 8:41 AM, Cory Maccarrone darkstar6...@gmail.com wrote:
This change adds in MMC and I2C support to the HTC Herald board, as well
as adding the HTCPLD driver for the PLD used on this phone. It also
adds in the gpio-keys entries for the front directional keys and
selector
This change adds in MMC and I2C support to the HTC Herald board, as well
as adding the HTCPLD driver for the PLD used on this phone. It also
adds in the gpio-keys entries for the front directional keys and
selector and the cursor keys on the slide-out keyboard, and gpio-leds
support for the LEDs
Nayak, Rajendra rna...@ti.com writes:
[...]
diff --git a/arch/arm/mach-omap2/pm_bus.c
b/arch/arm/mach-omap2/pm_bus.c
index 69acaa5..3787da8 100644
--- a/arch/arm/mach-omap2/pm_bus.c
+++ b/arch/arm/mach-omap2/pm_bus.c
@@ -70,3 +70,64 @@ int platform_pm_runtime_idle(struct device *dev)
};
Arce, Abraham x0066...@ti.com writes:
OMAP4 keyboard controller includes:
- built-in scanning algorithm
- debouncing feature
Driver implementation is based on matrix_keypac.c
Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com
Signed-off-by: Abraham Arce x0066...@ti.com
Felipe Balbi felipe.ba...@nokia.com writes:
On Tue, Jun 01, 2010 at 06:47:34AM +0200, Balbi Felipe (Nokia-D/Helsinki)
wrote:
+pdata-device_enable = omap_device_enable;
this is undefined at least here or previous patch.
or does it come from omap_device layers ??
It's part of the
On Tue, Jun 01, 2010 at 05:14:09PM +0200, ext Arce, Abraham wrote:
I am using #ifdef CONFIG_ARCH_OMAP4 for this portion of code, what you
are suggesting is to check at runtime?
you need to add both checks. If you build omap3-only or omap2-only you
don't want that code to be compiled, but if
I re-added your reviewers to the cc...
On Mon, 24 May 2010 16:34:25 +0530 (IST)
Hemanth V heman...@ti.com wrote:
This patch adds support for ROHM BH1780GLI Ambient light sensor.
BH1780 supports I2C interface. Driver supports read/update of power state and
read of lux value (through SYSFS).
On Tue, Jun 01, 2010 at 09:53:58PM +0300, Felipe Balbi wrote:
On Tue, Jun 01, 2010 at 05:14:09PM +0200, ext Arce, Abraham wrote:
I am using #ifdef CONFIG_ARCH_OMAP4 for this portion of code, what
you are suggesting is to check at runtime?
you need to add both checks. If you build omap3-only
On Tue, Jun 01, 2010 at 01:12:44PM -0700, Andrew Morton wrote:
On Mon, 24 May 2010 16:34:25 +0530 (IST)
Hemanth V heman...@ti.com wrote:
This patch adds support for ROHM BH1780GLI Ambient light sensor.
BH1780 supports I2C interface. Driver supports read/update of power state
and
On 06/01/10 21:12, Andrew Morton wrote:
I re-added your reviewers to the cc...
On Mon, 24 May 2010 16:34:25 +0530 (IST)
Hemanth V heman...@ti.com wrote:
This patch adds support for ROHM BH1780GLI Ambient light sensor.
BH1780 supports I2C interface. Driver supports read/update of power
On Tue, 1 Jun 2010 22:27:15 +0200
Daniel Mack dan...@caiaq.de wrote:
On Tue, Jun 01, 2010 at 01:12:44PM -0700, Andrew Morton wrote:
On Mon, 24 May 2010 16:34:25 +0530 (IST)
Hemanth V heman...@ti.com wrote:
This patch adds support for ROHM BH1780GLI Ambient light sensor.
BH1780
On 06/01/10 21:27, Daniel Mack wrote:
On Tue, Jun 01, 2010 at 01:12:44PM -0700, Andrew Morton wrote:
On Mon, 24 May 2010 16:34:25 +0530 (IST)
Hemanth V heman...@ti.com wrote:
This patch adds support for ROHM BH1780GLI Ambient light sensor.
BH1780 supports I2C interface. Driver supports
On Tue, 01 Jun 2010 21:39:10 +0100
Jonathan Cameron ker...@jic23.retrosnub.co.uk wrote:
It would be most useful if the changelog were to fully describe the
proposed kernel-userspace interface. That's the most important part
of the driver, because it's the only part we can never change.
On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
You're the one mentioning x86, not me. I already explained that some
MSM hardware (the G1 for example) has lower power consumption in S3
(which I'm using as an ACPI
On Fri, May 21, 2010 at 10:05 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Mike Chan m...@android.com writes:
On Thu, May 20, 2010 at 2:01 PM, Thomas Renninger tr...@suse.de wrote:
Hi Mike,
On Thursday 20 May 2010 08:42:21 pm Mike Chan wrote:
v2:
Rebased off of Thomas Renninger's
On 06/01/10 21:54, Andrew Morton wrote:
On Tue, 01 Jun 2010 21:39:10 +0100
Jonathan Cameron ker...@jic23.retrosnub.co.uk wrote:
It would be most useful if the changelog were to fully describe the
proposed kernel-userspace interface. That's the most important part
of the driver, because
--- On Tue, 6/1/10, James Bottomley james.bottom...@suse.de wrote:
As long as you can set a wakeup timer, an S state is just a C state with
side effects.
I've seen similar statements on this endless
thread before; they're not quite true...
The significant one is that entering an
S
On Tuesday 01 June 2010, Arve Hjønnevåg wrote:
On Mon, May 31, 2010 at 3:05 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Monday 31 May 2010, Neil Brown wrote:
On Thu, 27 May 2010 23:40:29 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
On Thu, 27 May 2010, Rafael J. Wysocki
On Tuesday 01 June 2010, Alan Stern wrote:
On Tue, 1 Jun 2010, Neil Brown wrote:
As I said before, we generally can't prevent such things from happening,
because even if we handle the particular race described above, it still is
possible that the event will be lost if it arrives just a
On Tuesday 01 June 2010, Alan Stern wrote:
On Tue, 1 Jun 2010, Neil Brown wrote:
With wakeup events the problem isn't so bad. Wakeup events are always
noticed, and if the system is designed properly they will either abort
a suspend-in-progress or else cause the system to resume as
On Tuesday 01 June 2010, James Bottomley wrote:
On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
You're the one mentioning x86, not me. I already explained that some
MSM hardware (the G1 for example) has lower
This change adds in the necessary clocks and mux pins for UART
control on omap7xx devices. I also made a change in the serial
code to only try and initialize two UARTs in omap_serial_init, as
these devices don't have three.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
This change adds in a bluetooth controld driver/rfkill
interface to the serial bluetooth controller found on many
HTC smartphones such as the HTC Herald and HTC Wizard.
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
---
arch/arm/mach-omap1/htc-bt.c | 183
This change adds bluetooth and UART initialization support to the
HTC Herald board driver. This allows use of the serial bluetooth
adapter attached to UART1 using hciattach.
The defconfig was updated to add in bluetooth core support, as well
as to clean up some unneeded cruft.
Signed-off-by:
On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote:
On Tuesday 01 June 2010, James Bottomley wrote:
On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
You're the one mentioning x86, not me. I already
On Tue, 1 Jun 2010 10:47:49 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Tue, 1 Jun 2010, Neil Brown wrote:
With wakeup events the problem isn't so bad. Wakeup events are always
noticed, and if the system is designed properly they will either abort
a suspend-in-progress
On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley james.bottom...@suse.de wrote:
On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote:
On Tuesday 01 June 2010, James Bottomley wrote:
On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
On Mon, May 31, 2010 at 04:21:09PM -0500,
-Original Message-
From: Arve Hjønnevåg [mailto:a...@android.com]
Sent: Tuesday, June 01, 2010 6:11 PM
To: James Bottomley
Cc: Rafael J. Wysocki; Matthew Garrett; Thomas Gleixner; Peter Zijlstra;
ty...@mit.edu; LKML; Florian Mickler; Linux PM; Linux OMAP Mailing List;
On Tue, Jun 01, 2010 at 04:01:25PM -0500, James Bottomley wrote:
On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:
On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:
You're the one mentioning x86, not me. I already explained that some
MSM hardware (the G1 for
2010/6/1 Gross, Mark mark.gr...@intel.com:
...
4. It would be useful to change pm_qos_add_request to not allocate
anything so can add constraints from init functions that currently
cannot fail.
[mtg: ] I'm not sure how to do this but I agree it would be good. I guess we
could have a block of
2010/6/1 Thomas Gleixner t...@linutronix.de:
On Mon, 31 May 2010, Arve Hjønnevåg wrote:
2010/5/31 Rafael J. Wysocki r...@sisk.pl:
On Monday 31 May 2010, Arve Hjønnevåg wrote:
2010/5/30 Rafael J. Wysocki r...@sisk.pl:
...
I think it makes more sense to block suspend while wakeup events
2010/6/1 Thomas Gleixner t...@linutronix.de:
On Mon, 31 May 2010, Arve Hjønnevåg wrote:
On Mon, May 31, 2010 at 2:46 PM, Thomas Gleixner t...@linutronix.de wrote:
On Mon, 31 May 2010, James Bottomley wrote:
For MSM hardware, it looks possible to unify the S and C states by doing
On 06/01/2010 09:59 AM, Peter Ujfalusi wrote:
On Monday 31 May 2010 20:41:12 ext Nishanth Menon wrote:
On 05/31/2010 11:16 AM, Peter Ujfalusi wrote:
Use the actual FIFO size in words as buffer_size on OMAP2.
Change the threshold configuration to use 1 based numbering, when
specifying the
On 06/01/2010 03:01 PM, Premi, Sanjeev wrote:
-Original Message-
From: Nishanth Menon [mailto:menon.nisha...@gmail.com]
Sent: Monday, May 31, 2010 10:59 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCHv1 1/1] omap3: pm: Delink opp layer and cpufreq
On
2010/6/1 James Bottomley james.bottom...@suse.de:
On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote:
On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley james.bottom...@suse.de
wrote:
On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote:
On Tuesday 01 June 2010, James Bottomley
On Tue, 1 Jun 2010 12:50:01 +0200 (CEST)
Thomas Gleixner t...@linutronix.de wrote:
On Tue, 1 Jun 2010, Neil Brown wrote:
I think you have acknowledged that there is a race with suspend - thanks.
Next step was can it be closed.
You seem to suggest that it can, but you describe it as a
84 matches
Mail list logo
