On Tue, Jun 28, 2011 at 4:26 AM, Ohad Ben-Cohen o...@wizery.com wrote:
On Tue, Jun 28, 2011 at 12:22 AM, Grosen, Mark mgro...@ti.com wrote:
2. We added a special section (resource table) that is interpreted as part
of the loading process. The tool that generates our simple format just
, and then the driver core will in turn start
-remove()ing the rpmsg drivers) and power management (via runtime
PM).
About SMD: I'm not familiar with it too much, but Brian naturally is
(just for the sake of everyone who are not reading headers - Brian
Swetland wrote the Linux SMD driver
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 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
On Sun, Jun 6, 2010 at 12:52 AM, Vitaly Wool vitalyw...@gmail.com wrote:
2010/6/5 Arve Hjønnevåg a...@android.com:
We clearly have different standards for what we consider good. We
measure time suspended in minutes or hours, not seconds, and waking up
every second or two causes a noticeable
On Sun, Jun 6, 2010 at 1:32 AM, Vitaly Wool vitalyw...@gmail.com wrote:
It varies depending on device and usage. The battery monitoring on
NexusOne happens every ten minutes, so that's the longest you'll see a
N1 suspended for. On a G1 or Dream/myTouch you can see 20-30 minutes
between
On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner t...@linutronix.de wrote:
Right, so the sooner we make it easier for the drivers to use the kernel
as their main repository, the better.
Yep, the fastest way is to provide two stub inlines in pm.h and let
the driver flood come in.
As
On Sun, Jun 6, 2010 at 12:05 PM, Christoph Hellwig h...@infradead.org wrote:
On Sun, Jun 06, 2010 at 12:08:34PM -0500, James Bottomley wrote:
Well, we sort of tried this when Greg pulled some of them into the
staging tree. The problem is that without the annotations, the drivers
are still
On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig h...@infradead.org wrote:
Yes. That's what makes me wonder about some parts of the discussion
here. Getting the drivers for one or more of the android plattforms
in is not a problem. I'd say it could have easily been done with the
manweeks
On Sat, Jun 5, 2010 at 3:23 PM, Arjan van de Ven ar...@infradead.org wrote:
We clearly have different standards for what we consider good. We
measure time suspended in minutes or hours, not seconds, and waking up
every second or two causes a noticeable decrease in battery life on
the hardware
On Fri, Jun 4, 2010 at 12:57 AM, Ingo Molnar mi...@elte.hu wrote:
* Brian Swetland swetl...@google.com wrote:
We started here because it's possibly the only api level change we have --
almost everything else is driver or subarch type work or controversial but
entirely self-contained (like
On Fri, Jun 4, 2010 at 1:55 AM, Ingo Molnar mi...@elte.hu wrote:
* Brian Swetland swetl...@google.com wrote:
After basically two years of growing your fork (and some attempts to get
your drivers into drivers/staging/ - from where they have meanwhile
dropped out again) you re-started
On Fri, Jun 4, 2010 at 2:59 AM, Ingo Molnar mi...@elte.hu wrote:
You can certainly put in a suspend_blockers.h thing into some Android
directory, and populate it with empty wrappers - as long as you only use it
within Android drivers and not core kernel code or other subsystems you dont
On Fri, Jun 4, 2010 at 3:08 AM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2010-06-04 at 12:03 +0200, Ingo Molnar wrote:
The only 'interesting' issue I can see here is that if you create 1000
CLOCK_MONOTONIC namepaces, we'd need to have a tree of trees in order to
efficiently find
On Wed, Jun 2, 2010 at 11:04 PM, mark gross 640e9...@gmail.com wrote:
There are many wakeup events possible in a typical system --
keypresses or other input events, network traffic, telephony events,
media events (fill audio buffer, fill video decoder buffer, etc), and
I think requiring that
On Wed, Jun 2, 2010 at 11:33 PM, Neil Brown ne...@suse.de wrote:
The current suspend-blocker proposal already involves userspace
changes (it's different than our existing wakelock interface), and
we're certainly not opposed to any/all userspace changes on principle,
but on the other hand
On Wed, Jun 2, 2010 at 9:24 PM, Paul Mundt let...@linux-sh.org wrote:
On the other hand, while this isn't that difficult for the UP case it
does pose more problems for the SMP case. Presently the suspend paths
(suspend-to-RAM/hibernate/kexec jump) all deal with disabling and
enabling of
On Thu, Jun 3, 2010 at 6:36 AM, mark gross 640e9...@gmail.com wrote:
On Wed, Jun 02, 2010 at 11:12:39PM -0700, Brian Swetland wrote:
On Wed, Jun 2, 2010 at 11:04 PM, mark gross 640e9...@gmail.com wrote:
There are many wakeup events possible in a typical system --
keypresses or other input
On Thu, Jun 3, 2010 at 12:30 PM, Ingo Molnar mi...@elte.hu wrote:
Sadly the response from the Android team has been 100% uncompromising: either
suspend blockers or nothing.
Well, we're willing to accept something that gives us the same
functionality (thus rewriting the api several times to
On Wed, Jun 2, 2010 at 1:06 AM, Neil Brown ne...@suse.de wrote:
On Wed, 2 Jun 2010 00:05:14 -0700
Arve Hjønnevåg a...@android.com wrote:
The user-space suspend daemon avoids losing wake-events by using
fcntl(F_OWNER) to ensure it gets a signal whenever any important wake-event
is ready to
On Fri, May 28, 2010 at 5:26 AM, Igor Stoppa igor.sto...@nokia.com wrote:
ext Matthew Garrett wrote:
On Fri, May 28, 2010 at 10:37:13AM +0100, Alan Cox wrote:
The other vendors appear to be managing nicely without magic blockers. I
conjecture therefore there are other solutions.
Actually,
On Fri, May 28, 2010 at 6:32 AM, Igor Stoppa igor.sto...@nokia.com wrote:
What I consider plain wrong i to claim that since there are this many units
out, some code should be merged.
I've never suggested that we should get a get-out-of-code-review-free
card or be automatically merged based on
On Fri, May 28, 2010 at 7:21 AM, Matthew Garrett mj...@srcf.ucam.org wrote:
On Fri, May 28, 2010 at 05:14:31PM +0300, Igor Stoppa wrote:
I have seen very good proposals for saner solutions.
Is that progress?
The proposals so far involve either redefining the problem space or
being
On Fri, May 28, 2010 at 8:06 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Arve points out that qos constraint objects could work (but not if
specifically tied to apps): http://lkml.org/lkml/2010/5/28/120 though
he suggests that latency constraints don't represent this as well as
state
On Thu, May 27, 2010 at 3:55 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
This started because the Android people came to a meeting that was put
together of various folks to try and sort of the big blockage in getting
Android and Linux kernels back towards merging.
I am interested right now
On Wed, May 26, 2010 at 2:45 AM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 02:41 -0700, Arve Hjønnevåg wrote:
On Wed, May 26, 2010 at 1:47 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
This of course will
On Wed, May 26, 2010 at 3:32 AM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-05-26 at 03:25 -0700, Arve Hjønnevåg wrote:
and on systems where the
same power state can be used from idle and suspend, we use suspend so
we can stay in the low power state for minutes to hours instead
On Mon, May 17, 2010 at 11:12 AM, Felipe Balbi m...@felipebalbi.com wrote:
The technical reason for wanting suspend blockers (as has been stated
more times than I can be bothered to go back and count) is that no-one
can currently produce a working model for race free kernel to user work
On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi m...@felipebalbi.com wrote:
Hi,
On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
We (Google) would like to allow completely open app distribution with
minimal hurdles, and avoid the walled garden approach. Toward this
goal we're
On Mon, May 17, 2010 at 3:55 PM, Kevin Hilman
khil...@deeprootsystems.com wrote:
The fundamental problem is one of idleness. What we want is the
system to be idle in order to hit the lowest power states. We can't
get there because the system is not truly idle.
So, there are basically two
On Fri, May 14, 2010 at 7:58 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Fri, 14 May 2010, Brian Swetland wrote:
It provides useful functionality -- you apparently disagree, but the
wakelock/suspendblock model is in use, shipping, and solving problems
for quite a lot of android devices
On Thu, May 13, 2010 at 10:33 AM, Daniel Walker dwal...@fifo99.com wrote:
On Thu, 2010-05-13 at 13:17 +0100, Matthew Garrett wrote:
On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote:
Figuring out a different way to do this should not limit Android at all,
since Google can do
On Thu, May 13, 2010 at 3:46 PM, Greg KH gre...@suse.de wrote:
On Thu, May 13, 2010 at 05:33:58PM -0500, Woodruff, Richard wrote:
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Greg KH
Sent: Thursday, May 13, 2010 4:47 PM
Also note that
On Thu, May 13, 2010 at 4:36 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
I'm not a big fan of suspend blockers myself, but let's face it, _currently_
there's no alternative and we need to stop the trend, the sooner the better.
I don't think this is a major part of the trend -
On Mon, Nov 30, 2009 at 12:23 PM, Ladislav Michl
ladislav.mi...@seznam.cz wrote:
On Mon, Nov 23, 2009 at 09:24:16AM -0800, Tony Lindgren wrote:
* Ladislav Michl ladislav.mi...@seznam.cz [091123 03:45]:
Since omapnand driver never find its way into mainline, switch to gen_nand
instead.
[Greg KH g...@kroah.com]
but I don't think driver/staging is good place for non driver code.
The problem is, any patch must be reviewed by stakeholder, not maintenar
only.
then, the patch should post lkml and subsystem mailing list at first.
I like reviewed code than unreviewed code.
Definitely worth discussing -- I'm going to be out of the office for two
weeks over the holidays, and most of the rest of our team is on vacation
as well. I'll pass this on, but I'm not sure if people will have much
time to take a look before January.
[Trilok Soni soni.tri...@gmail.com]
Hi
[Tony Lindgren [EMAIL PROTECTED]]
I've merged Jarkko's asoc patch to linux-omap for testing. Have not
gotten any sound out of it on my n810 though.. Maybe some alsamixer
settings issue?
Kalle, do you have any tips on getting WLAN to work on n8x0?
This was the show-stopper for me. When I
[Jonathan Herriott [EMAIL PROTECTED]]
I had it confirmed in another thread that the issue is that the local
filesystem for the N810 is jffs, which is unsupported and I need to
install it on an mini SD card with ext2/ext3 on it.
I think what you're seeing here is the property service in init
[Anil S [EMAIL PROTECTED]]
Hello Brian,
It would be really great if you could share thoughts on the
questions given here on Android:
I was able to add support for the keypad, touch and network in Android,
however the interfaces like GPS, Accelerometer, vibrator, hardware 3D
[Jarkko Nikula [EMAIL PROTECTED]]
On Sun, 6 Apr 2008 06:23:23 -0700
ext Brian Swetland [EMAIL PROTECTED] wrote:
Has anyone had any luck getting a 2.6.23 or 2.6.24 kernel working
with the 800 or 810? When I was poking around with it a while back,
I had to backport our stuff to .21 due
Congrats.
Has anyone had any luck getting a 2.6.23 or 2.6.24 kernel working
with the 800 or 810? When I was poking around with it a while back,
I had to backport our stuff to .21 due to binary-only wifi drivers
being incompatible with newer kernels.
Also, if anyone knows of work done to figure
[Georges Toth [EMAIL PROTECTED]]
The touchscreen doesn't work yet, but I hope we can figure that out too.
- The driver works, there is output when one does a cat on
/dev/input/event3, but android doesn't recognize it.
Some buttons don't work ... wrong mapping.
If anybody has an idea how to
[andrzej zaborowski [EMAIL PROTECTED]]
Poky (pokylinux.org) and mamona both work pretty well for everyday use
on the nseries. Fortunately the userspace can partially ignore the
charging issue because the RETU (now Betty) chip takes care of that in
the hardware. Charging / charger-cable /
[Brian Swetland [EMAIL PROTECTED]]
I'm hoping to get a public git repository put together with the
various android-specific kernel patches (binder, logger, alarm drivers,
goldflish platform support, etc) soon. This should at least make
it easier for folks to merge various drivers 'n things
45 matches
Mail list logo
