On Tue, Jun 28, 2011 at 4:26 AM, Ohad Ben-Cohen wrote:
> On Tue, Jun 28, 2011 at 12:22 AM, Grosen, Mark 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
>> recognizes a named section (".r
te error recovery (on remote crash, we just
> remove the virtio device, 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
On Mon, Jun 7, 2010 at 4:17 PM, Linus Walleij
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 daemon or whatever, still
On Mon, Jun 7, 2010 at 1:03 AM, Christoph Hellwig 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
On Sun, Jun 6, 2010 at 12:24 PM, Christoph Hellwig 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 spent arguing
On Sun, Jun 6, 2010 at 12:05 PM, Christoph Hellwig 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 different, and
On Sun, Jun 6, 2010 at 11:04 AM, Thomas Gleixner 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 mentioned previous
On Sun, Jun 6, 2010 at 1:32 AM, Vitaly Wool 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 wakeups (depend
On Sun, Jun 6, 2010 at 12:52 AM, Vitaly Wool wrote:
> 2010/6/5 Arve Hjønnevåg :
>>
>> 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
>
On Sat, Jun 5, 2010 at 3:23 PM, Arjan van de Ven 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 we have t
On Fri, Jun 4, 2010 at 3:08 AM, Peter Zijlstra 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 the leftmo
On Fri, Jun 4, 2010 at 2:59 AM, Ingo Molnar 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
> maintain.
>
>
On Fri, Jun 4, 2010 at 1:55 AM, Ingo Molnar wrote:
> * Brian Swetland 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 12:57 AM, Ingo Molnar wrote:
> * Brian Swetland 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
On Thu, Jun 3, 2010 at 12:30 PM, Ingo Molnar 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 meet various
o
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 ma
On Wed, Jun 2, 2010 at 9:24 PM, Paul Mundt 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 non-boot CPUs via CP
On Wed, Jun 2, 2010 at 11:33 PM, Neil Brown 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 we're no
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 requ
On Wed, Jun 2, 2010 at 1:06 AM, Neil Brown wrote:
> On Wed, 2 Jun 2010 00:05:14 -0700
> Arve Hjønnevåg 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 be read by user-spa
On Fri, May 28, 2010 at 8:06 AM, Alan Cox 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" constraints.
>
> With
On Fri, May 28, 2010 at 7:21 AM, Matthew Garrett 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 inherently racey.
On Fri, May 28, 2010 at 6:32 AM, Igor Stoppa 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 shipping volume.
H
On Fri, May 28, 2010 at 5:26 AM, Igor Stoppa 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, no. A badly
On Thu, May 27, 2010 at 3:55 PM, Alan Cox 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 in finding a genera
On Wed, May 26, 2010 at 3:32 AM, Peter Zijlstra 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 of
>> millisec
On Wed, May 26, 2010 at 2:45 AM, Peter Zijlstra 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 wrote:
>> > On Tue, 2010-05-25 at 01:38 +0200, Rafael J. Wysocki wrote:
>> >> > This of course will lead to a scattering of suspend
On Mon, May 17, 2010 at 3:55 PM, Kevin Hilman
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 solutions:
>
> 1) find
On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi 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
&
On Mon, May 17, 2010 at 11:12 AM, Felipe Balbi 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
>> handoff and, in t
On Fri, May 14, 2010 at 7:58 PM, Alan Stern 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 androi
On Fri, May 14, 2010 at 3:45 PM, Kevin Hilman
wrote:
>>> Personally, I suspect that lack of this feature is not the real
>>> obstacle to getting these out-of-tree drivers upstream. Having this
>>> API upstream will not change the product schedules and corporate
>>> cultures that have prevented co
On Thu, May 13, 2010 at 4:36 PM, Mark Brown
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 - like I say, the fact
> that peo
On Thu, May 13, 2010 at 3:46 PM, Greg KH 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 10:33 AM, Daniel Walker 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 what othe
On Mon, Nov 30, 2009 at 12:23 PM, Ladislav Michl
wrote:
> On Mon, Nov 23, 2009 at 09:24:16AM -0800, Tony Lindgren wrote:
>> * Ladislav Michl [091123 03:45]:
>> > Since omapnand driver never find its way into mainline, switch to gen_nand
>> > instead.
>> > Following patch is compile tested only,
[Greg KH ]
> > 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 ]
> Hi Jani,
>
> On Thu, Dec 1
[Kalle Valo <[EMAIL PROTECTED]>]
> Brian Swetland <[EMAIL PROTECTED]> writes:
> >
> > This was the show-stopper for me. When I last got things hobbling
> > along on n8x0, the binary-only wlan module was incompatible with
> > newer kernels than 2.6.21 (
[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
[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 ini
[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.
[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
[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-cab
[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 id
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
[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 t
47 matches
Mail list logo
