On Sun, Jun 6, 2010 at 12:18 AM, Luke-Jr l...@dashjr.org wrote:
How do I actually get this to work? Built a kernel with it for my N810, but
there's no ttyO* (I'm using devtmpfs)...
Hope your are trying to use Kevins Wip-UART branch.
Since platform data support is currently available in that
On Sun, 2010-06-06 at 23:52 +0200, ext Luke-Jr wrote:
This doesn't even build, so I don't know how it was tested... Reverting the
offending commit (simple, but does require conflict resolution) at least lets
it compile, but I haven't tested whether it alone is enough to work in
practise
On Sun, 2010-06-06 at 23:52 +0200, ext Luke-Jr wrote:
This doesn't even build, so I don't know how it was tested... Reverting the
offending commit (simple, but does require conflict resolution) at least lets
it compile, but I haven't tested whether it alone is enough to work in
practise
On Mon, Jun 07, 2010 at 12:26:55AM +0200, Thomas Gleixner wrote:
That takes a lot of the bullshit arguments about downstream users
being hurt out of the discussion. The above problems are way more
complex to resolve than the suspend blocker details.
That's another prove why we can let the
On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote:
Somebody will have to broker a deal with the frameworks/apps folks to
get rid of the binder. They like it a lot. Of course if somebody
built a drop-in replacement for the userspace side that didn't require
a kernel driver, had
On Mon, Jun 7, 2010 at 1:03 AM, Christoph Hellwig h...@infradead.org wrote:
On Sun, Jun 06, 2010 at 12:58:10PM -0700, Brian Swetland wrote:
The group ID stuff works incredibly well for gating device access --
we ensure that devices that need access from various processes end up
with perms like
On Fri, Jun 4, 2010 at 9:05 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
This patch makes the following:
- Adds missing wakeup padding register handling.
- Fixes a hardcode to use PER module ONLY on UART3.
- Muxmode usage needed for uart4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
* Kevin Hilman khil...@deeprootsystems.com [100604 18:30]:
+ w = ~0x7;
+ w |= OMAP_MUX_MODE2;
+ omap_ctrl_writew(w, uart-padconf);
Generic NAK for tinkering with the mux registers directly.
Instead, Govindraj, please add omap_mux_request_signal() into mux.c:
void __iomem * __init
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
On Sun, Jun 06, 2010 at 07:21:49PM +0200, Vitaly Wool wrote:
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
Suspend blocks prevent system suspend, not any per-device suspend.
Can you suspend a device which is holding a wake lock?
Yes. Suspend
Hello Paul,
Can you please push these patches if you don't you are OK with them?
-
Thanks and Best Regards
Pramod Gurav
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Gurav , Pramod
Sent: Friday, April 23, 2010 7:53
Hi,
Since Linus only wants regression fixes nowadays during the -rc
cycle, few more questions below.
* Hiroshi DOYU hiroshi.d...@nokia.com [100602 10:45]:
Hi Tony,
Patches only for fixes for omap iommu module during -rc cycle.
The following changes since commit
On Mon, Jun 7, 2010 at 3:36 PM, Tony Lindgren t...@atomide.com wrote:
* Kevin Hilman khil...@deeprootsystems.com [100604 18:30]:
+ w = ~0x7;
+ w |= OMAP_MUX_MODE2;
+ omap_ctrl_writew(w, uart-padconf);
Generic NAK for tinkering with the mux registers directly.
Instead, Govindraj,
From: ext Tony Lindgren t...@atomide.com
Subject: Re: [GIT PULL] omap iommu: fixes for 2.6.35-rc1
Date: Mon, 7 Jun 2010 13:17:48 +0200
Since Linus only wants regression fixes nowadays during the -rc
cycle, few more questions below.
* Hiroshi DOYU hiroshi.d...@nokia.com [100602 10:45]:
Hi
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-fixes
Initial commit ID (Likely to change): 0b703473c328c991acf2366f4ebefc8d38884799
PatchWorks
http://patchwork.kernel.org/patch/103831/
Git (Likely to change, and takes a while to get
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Branch in linux-omap: omap-fixes
Initial commit ID (Likely to change): 4f4348dafd232a570641266e326c044abe5709fe
PatchWorks
http://patchwork.kernel.org/patch/104143/
Git (Likely to change, and takes a while to get
On Wed, Jun 02, 2010 at 05:22:29PM +0200, ext Kevin Hilman wrote:
The addition of the new debounce code (commit
168ef3d9a56bd8bffe0ef4189c450888b4aefefe) broke the auto-disable of
debounce clocks on idle by forgetting to update the debounce clock
enable mask.
Add back the updating of
On Sun, 6 Jun 2010 04:14:09 -0700 (PDT)
da...@lang.hm wrote:
On Sun, 6 Jun 2010, Florian Mickler wrote:
On Sun, 6 Jun 2010 12:19:08 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
2010/6/6 da...@lang.hm:
as an example (taken from this thread).
system A needs to wake up to get a
On Sun, 6 Jun 2010 19:21:49 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
2010/6/6 Matthew Garrett mj...@srcf.ucam.org:
Suspend blocks prevent system suspend, not any per-device suspend.
Can you suspend a device which is holding a wake lock?
~Vitaly
If you look at the suspend blocker
On Monday 07 June 2010 01:49:05 am Govindraj wrote:
Hope your are trying to use Kevins Wip-UART branch.
Since platform data support is currently available in that branch.
Nope... Google doesn't seem to know where this branch is, either. :/
ensure you have selected omap-serial driver
I'm not
On Sun, 2010-06-06 at 12:58 -0700, Brian Swetland wrote:
Somebody will have to broker a deal with the frameworks/apps folks to
get rid of the binder. They like it a lot. Of course if somebody
built a drop-in replacement for the userspace side that didn't require
a kernel driver, had the same
On Mon, Jun 7, 2010 at 6:39 PM, Luke-Jr l...@dashjr.org wrote:
On Monday 07 June 2010 01:49:05 am Govindraj wrote:
Hope your are trying to use Kevins Wip-UART branch.
Since platform data support is currently available in that branch.
Nope... Google doesn't seem to know where this branch is,
On Mon, 7 Jun 2010, Thomas Gleixner wrote:
Alan,
Thomas:
On Sun, 6 Jun 2010, Alan Stern wrote:
Remember that suspend takes place in several phases, the first of which
is to freeze tasks. The phases can be controlled individually by the
process carrying out a suspend, and there's
On Mon, Jun 7, 2010 at 5:02 PM, Govindraj govindraj...@gmail.com wrote:
On Mon, Jun 7, 2010 at 3:36 PM, Tony Lindgren t...@atomide.com wrote:
* Kevin Hilman khil...@deeprootsystems.com [100604 18:30]:
+ w = ~0x7;
+ w |= OMAP_MUX_MODE2;
+ omap_ctrl_writew(w, uart-padconf);
Generic
Alan,
On Mon, 7 Jun 2010, Alan Stern wrote:
On Mon, 7 Jun 2010, Thomas Gleixner wrote:
#2 is a tad harder, as it requires to fix the trusted apps not to fire
timers when there is nothing to do.
No; all you have to do is handle the trusted apps as though they were
untrusted -- just as
On Sun, 6 Jun 2010 20:01:56 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
And since Android can reach essentially the same low-power
state from idle as from suspend, it appears that they really don't need
any kernel changes at all.
Well, perhaps a hint to the scheduler to fall
On Monday 07 June 2010 08:28:51 am Govindraj wrote:
Link:
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=summa
ry
Branch:
pm-wip/uart
This branch doesn't appear to have omap-serial.c at all...
If you are trying to use with any client device connected to uart
then
On Monday 07 June 2010 02:47:34 am Tomi Valkeinen wrote:
I don't have any device that uses RFBI so I can't test it, but how about
this patch:
Unfortunately, I can't test it either since N8x0 has no mainline support for
video output, nor can until CBus is merged. :(
--
To unsubscribe from this
Signed-off-by: Jonathan Cameron ji...@cam.ac.uk
---
I'm not a user of this code but was browsing the kautobuild logs
and saw the igep0020 build error that has been there since
24th of May using the defconfig. Looks like a trivial
missing header to me. I can not verify the resulting
build
--- On Mon, 6/7/10, Peter Zijlstra pet...@infradead.org wrote:
So what's up with this Binder stuff, from what I can see
its just
yet-another-CORBA. Why does it need a kernel part at all,
can't you
simply run with a user-space ORB instead?
I really don't get why people keep re-inventing
Ohad Ben-Cohen wrote:
The underlying buffering implementation of mailbox
is converted from block API to kfifo due to the simplicity
and speed of kfifo.
The default size of the kfifo buffer is set to 256 bytes.
This value is configurable at compile time (via
CONFIG_OMAP_MBOX_KFIFO_SIZE), and can
On Thu, Jun 3, 2010 at 8:01 PM, Gadiyar, Anand gadi...@ti.com wrote:
Kevin Hilman wrote:
Mike Chan m...@android.com writes:
On Fri, May 21, 2010 at 9:47 AM, Kevin Hilman
khil...@deeprootsystems.com wrote:
Mike Chan m...@android.com writes:
I'm not sure if this has been discussed, yet
On Fri, Jun 04, 2010 at 05:01:49AM +0200, ext Gadiyar, Anand wrote:
What if a driver knows that it cannot afford to let the PM layer
turn off the power domain at certain points of time (maybe as long
as a USB cable is connected). How can this be specified in terms
of a latency or throughput
Hi Deepak,
On Mon, Jun 7, 2010 at 1:52 PM, Deepak Chitriki deepak.chitr...@ti.com wrote:
With this patch I observed inconsistent lock state warning.
Thanks for the report!
Kfifo is acccessed in omap_mbox_msg_send() and mbox_tx_tasklet()
functions.In order to protect this critical section we
Hi,
-Original Message-
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Monday, June 07, 2010 4:41 PM
To: Chitriki Rudramuni, Deepak; Guzman Lugo, Fernando; Ramirez Luna, Omar;
Kanigeri, Hari
Cc: linux-omap@vger.kernel.org; Hiroshi Doyu
Subject: Re: [PATCH v3 4/4] omap:
2010/6/5 Alan Stern st...@rowland.harvard.edu:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
Yes, we can keep all our user space suspend blockers and thaw the
frozen cgroup when any suspend blocker is held, but this would
eliminate any power advantage that freezing a cgroup has over using
2010/6/7 Peter Zijlstra pet...@infradead.org:
On Sun, 2010-06-06 at 12:58 -0700, Brian Swetland wrote:
Somebody will have to broker a deal with the frameworks/apps folks to
get rid of the binder. They like it a lot. Of course if somebody
built a drop-in replacement for the userspace side
Ohad Ben-Cohen wrote:
Hi Deepak,
On Mon, Jun 7, 2010 at 1:52 PM, Deepak Chitriki deepak.chitr...@ti.com wrote:
With this patch I observed inconsistent lock state warning.
Thanks for the report!
Kfifo is acccessed in omap_mbox_msg_send() and mbox_tx_tasklet()
functions.In order
2010/6/6 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
That download might
On Mon, Jun 7, 2010 at 4:17 PM, Linus Walleij
linus.ml.wall...@gmail.com wrote:
So I would really like to know from the Android people why the
binder is in the kernel, after all. Could it *theoretically* be in
userspace, on top of some unix domain sockets, running as a
real-time scheduled
2010/6/6 Thomas Gleixner t...@linutronix.de:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
Can you please explain in a consistent way how the application stack
and the underlying framework (which exists according to android docs)
is handling
2010/6/6 Alan Stern st...@rowland.harvard.edu:
On Sat, 5 Jun 2010, Alan Stern wrote:
If you are referring to the approach that we don't use suspend but
freeze a cgroup instead, this only solves the problem of bad apps. It
does not help pause timers in trusted user space code and in the
2010/6/6 Rafael J. Wysocki r...@sisk.pl:
On Sunday 06 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Rafael J. Wysocki r...@sisk.pl:
On Saturday 05 June 2010, Arve Hjønnevåg wrote:
2010/6/5 Thomas Gleixner t...@linutronix.de:
B1;2005;0cOn Fri, 4 Jun 2010, Arve Hjønnevåg wrote:
...
Arve,
On Sun, Jun 6, 2010 at 7:43 AM, Matt Helsley matth...@us.ibm.com wrote:
On Sun, Jun 06, 2010 at 12:36:21PM +0200, Thomas Gleixner wrote:
On Sat, 5 Jun 2010, Arve Hjønnevåg wrote:
snip
events like input event go though a single thread in our system
process, while other events like network
On Sun, Jun 6, 2010 at 5:01 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Sun, 6 Jun 2010, Matthew Garrett wrote:
The difference between idle-based suspend and opportunistic suspend is
that the former will continue to wake up for timers and will never be
entered if something is using
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
In fact it's possible to do this with only minimal changes to the
userspace, providing you can specify all your possible hardware wakeup
sources. (On the Android this list probably isn't very large -- I
imagine it includes the keypad, the radio
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
Remember that suspend takes place in several phases, the first of which
is to freeze tasks. The phases can be controlled individually by the
process carrying out a suspend, and there's nothing to prevent you from
stopping after the freezer phase.
2010/6/7 Alan Stern st...@rowland.harvard.edu:
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
In fact it's possible to do this with only minimal changes to the
userspace, providing you can specify all your possible hardware wakeup
sources. (On the Android this list probably isn't very large --
On Tue, 08 Jun 2010 01:17:13 +0200, Linus Walleij said:
So I would really like to know from the Android people why the
binder is in the kernel, after all. Could it *theoretically* be in
userspace, on top of some unix domain sockets, running as a
real-time scheduled daemon or whatever, still
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
It's true that under some exceptional circumstances the system would
never remove a wakeup source from the active list and then would
never go idle. But exactly the same problem exists with wakelocks, if
the kernel activates a wakelock and
2010/6/7 Alan Stern st...@rowland.harvard.edu:
On Mon, 7 Jun 2010, Arve Hjønnevåg wrote:
It's true that under some exceptional circumstances the system would
never remove a wakeup source from the active list and then would
never go idle. But exactly the same problem exists with wakelocks,
Hi Deepak,
On Mon, Jun 7, 2010 at 6:27 PM, Deepak Chitriki deepak.chitr...@ti.com wrote:
Ohad Ben-Cohen wrote:
Somewhat relevant note about mailbox performance: omap_mbox_msg_send
often (i.e. when the kfifo is empty) can just send the message
directly, without triggering the tasklet to do
From: ext Guzman Lugo, Fernando fernando.l...@ti.com
Subject: RE: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
Date: Tue, 8 Jun 2010 01:14:41 +0200
Hi,
-Original Message-
From: Ohad Ben-Cohen [mailto:o...@wizery.com]
Sent: Monday, June 07, 2010 4:41 PM
To: Chitriki
From: ext Ohad Ben-Cohen o...@wizery.com
Subject: Re: [PATCH v3 4/4] omap: mailbox: convert block api to kfifo
Date: Tue, 8 Jun 2010 05:11:50 +0200
Hi Deepak,
On Mon, Jun 7, 2010 at 6:27 PM, Deepak Chitriki deepak.chitr...@ti.com
wrote:
Ohad Ben-Cohen wrote:
Somewhat relevant note about
-Original Message-
From: Gopinath, Thara
Sent: Friday, June 04, 2010 3:35 PM
To: Kevin Hilman; Nishanth Menon
Cc: Premi, Sanjeev; Menon, Nishanth; Koen Kooi; linux-
Slightly off the topic but considering we are discussing opp layer here, I
do not find API's
that take the OPP type
-Original Message-
From: Menon, Nishanth
Sent: Tuesday, June 08, 2010 9:45 AM
To: Gopinath, Thara; Kevin Hilman; Nishanth Menon
Cc: Premi, Sanjeev; Koen Kooi; linux-omap@vger.kernel.org;
eduardo.valen...@nokia.com
Subject: opp layer query apis (was RE: omap3 pm: dependency between opp
-Original Message-
From: Gopinath, Thara
Sent: Tuesday, June 08, 2010 7:29 AM
-Original Message-
From: Menon, Nishanth
Sent: Tuesday, June 08, 2010 9:45 AM
-Original Message-
From: Gopinath, Thara
Sent: Friday, June 04, 2010 3:35 PM
Slightly off the topic
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Mike
Chan
Sent: Tuesday, June 08, 2010 1:00 AM
To: Gadiyar, Anand
Cc: Kevin Hilman; linux-omap@vger.kernel.org; Paul Walmsley
Subject: Re: Future of resource framework?
On
58 matches
Mail list logo
