On Thu, 2014-03-20 at 18:52 -0500, Felipe Balbi wrote:
Hi folks,
I've been toying with the idea of removing
drivers/tty/serial/omap-serial.c since that's, to put it bluntly, an
ungly copy of 8250 driver.
The original concern was wrt suspend/resume but I think it'd be a far
better
Fair enough. But there's no such thing a 'hotplug enumeration
construct' in Linux yet, and a bus is the closest thing to it. It does
take advantage of the nice way device code matches drivers and devices
though.
A bus is the wrong construct. You need something to add devices onto the
Further, it is critical to enable hardware vendors to avoid writing
any code for which there are existing drivers.
Which is why you don't want to create a new bus type for it.
Capebus seems to me to provide this solution fairly well. I don't
believe the SFI approach covers the most critical
What they want, and what every user wants, is I plug this board in, and
the driver make sure everything is loaded and ready. No, the end users
don't want to see any of the implementation details of how the bitfile
is transported; the driver can handle it.
That doesn't necessarily make it a
On Sat, 06 Oct 2012 13:45:47 +0100
Russell King rmk+ker...@arm.linux.org.uk wrote:
This allows drivers (such as OMAP serial) to allocate and free their
transmit buffers in a sane manner, rather than working around the
buffer allocation provided by serial_core.
I think this just illustrates
for DMA support
otherwise we have no way to properly pause the transmitter.
All the generic parts
Acked-by: Alan Cox a...@linux.intel.com
--
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
) {
if (pt-port.iotype == UPIO_AU)
return 0x1000;
-#ifdef CONFIG_ARCH_OMAP
+#ifdef CONFIG_ARCH_OMAP1
if (is_omap_port(pt))
return 0x16 pt-port.regshift;
#endif
Acked-by: Alan Cox a...@linux.intel.com
Even better would be if for other cases is_omap_port
Even better would be if for other cases is_omap_port and friends
returned 0...
Yes it seems that those macros could be moved from plat-omap/serial.h
to live in drivers/tty/serial/8250/8250.h? Or do you have some better
place in mind?
I've not looked at it enough to decide if it's doable
On Tue, 21 Aug 2012 12:15:44 +0300
Felipe Balbi ba...@ti.com wrote:
Even if we enter our IRQ handler just to notice
that the our device didn't generate the IRQ,
that still means handling and IRQ, so let's
return IRQ_HANDLED.
That looks wrong - you'll defeat the stuck IRQ protection. If we
Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific
workarounds? And Panda is not the only device with this issue.
Why should we crap all over the kernel for all these board specific
problems ? Userspace code is at least pageable and generally less
security critical.
So
diff --git a/drivers/tty/serial/serial_core.c
b/drivers/tty/serial/serial_core.c
index 9c4c05b..c176ff2 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1426,6 +1426,9 @@ static void uart_port_shutdown(struct tty_port *port)
*/
On Thu, 19 Apr 2012 20:00:12 +0530
Raja, Govindraj govindraj.r...@ti.com wrote:
On Thu, Apr 19, 2012 at 12:38 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
The point is that wakeups should be enabled whenever driver is in use,
and disabled when the driver is not in use.
Which
diff --git a/drivers/tty/serial/serial_core.c
b/drivers/tty/serial/serial_core.c
index 9c4c05b..0dc246d 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1284,6 +1284,8 @@ static void uart_close(struct tty_struct *tty, struct
file *filp)
The point is that wakeups should be enabled whenever driver is in use,
and disabled when the driver is not in use.
Which is the tty_port methods for initialisation and shutdown, which are
mutex protected against each other and hang up.
Not sure how the uart layer glue exposes that.
Alan
--
On Thu, 5 Apr 2012 16:54:03 +0530
Raja, Govindraj govindraj.r...@ti.com wrote:
On Wed, Mar 21, 2012 at 3:54 PM, Govindraj.R govindraj.r...@ti.com
wrote:
From: Govindraj.R govindraj.r...@ti.com
Based on Linux-OMAP tree uart branch.
On Thu, 16 Feb 2012 15:57:57 +0530
Aneesh V ane...@ti.com wrote:
On Thursday 16 February 2012 03:37 PM, Santosh Shilimkar wrote:
On Saturday 04 February 2012 05:46 PM, Aneesh V wrote:
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2
I will do it, although I do cling to the hope that others will help.
I always work on the basis that if its had some coverage testing then the
other folks who might have been affected should have reviewed the patch.
They opted not to, within reason - their lookout.
They'll only test it later
On Wed, 14 Dec 2011 07:20:13 -0800
Kevin Hilman khil...@ti.com wrote:
Greg, Alan,
Rajendra Nayak rna...@ti.com writes:
v3 is rebased on top of the latest serial runtime
patches[1] and boot tested with/without DT on OMAP4
SDP and OMAP4 Panda boards.
With your ack on the
On Tue, 06 Dec 2011 16:21:20 -0800
Kevin Hilman khil...@ti.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
Converting uart driver to adapt to pm runtime API's.
Code re-org + cleanup.
Moving some functionality from serial.c to omap-serial.c
Alan, can you confirm your Ack's are
On Sat, 26 Nov 2011 12:31:44 +0800
tom.leim...@gmail.com wrote:
From: Ming Lei ming@canonical.com
One face detection IP[1] is integared inside OMAP4 SoC, so
introduce this driver to make face detection function work
on OMAP4 SoC.
This driver is platform independent, so in theory can
On Fri, 07 Oct 2011 10:33:09 +0500
G, Manjunath Kondaiah manj...@ti.com wrote:
The gpio library should return -EPROBE_DEFER in gpio_request
if gpio driver is not ready.
Why not use the perfectly good existing error codes we have for this ?
We have EAGAIN and EUNATCH both of which look
On Mon, 22 Aug 2011 23:10:21 -0600 (MDT)
Paul Walmsley p...@pwsan.com wrote:
Convert the omap-serial hardirq handler to a threaded IRQ handler. Without
this patch, OMAP boards which use the on-board OMAP UARTs and the
omap-serial driver will not boot to userspace after commit
On Fri, 10 Jun 2011 16:38:37 +0300
Carlos Chinea carlos.chi...@nokia.com wrote:
Hi !
Here you have the fifth round of the HSI framework patches.
Looks good to me - only other oddity I found is to build hsi_char on x86
you need slab.h before kmemleak.h or the build errors
--
To unsubscribe
no idea.
So for the tty bits with my serial maintainer hat on
Acked-by: Alan Cox a...@linux.intel.com
but its mostly up to the ARM/OMAP people
--
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
Absolutely. On Intel, it is (still) Windows the reference. If Windows
doesn't boot on your motherboard you have a problem. So motherboard
vendors won't make crazy incompatible things. They are constrained to
OLPC, Moorestown ?
fix their hardware because they just cannot alter Windows
1) make sure that we have the new watchdog core infrastructure going in for
2.6.32.
This new core integrates the common code that we use over and over again. I
once
wrote code for it and then Alan had different ideas and thoughts and wrote
his updated
code. I reviewed that and I am
+#define HSI_CHST_RD(c) ((c)-state HSI_CHST_RD_MASK)
+#define HSI_CHST_WR(c) ((c)-state HSI_CHST_WR_MASK)
+
+#define HSI_CHST_OC_SET(c, v) \
+ do { \
+ (c)-state = ~HSI_CHST_OC_MASK; \
+ (c)-state |= v; \
+ } while (0);
+
On Thu, 25 Nov 2010 12:20:31 -0500
Andy Walls awa...@md.metrocast.net wrote:
The signedness of char is ambiguous for 8 bit data, which is why an API would
normally use u8 (or s8, I guess).
Since this is known to be character data, I would think char would be fine.
I am assuming C
On Mon, 27 Sep 2010 15:05:52 -0700
Kevin Hilman khil...@deeprootsystems.com wrote:
Govindraj.R govindraj.r...@ti.com writes:
This patch adds driver support for OMAP2/3/4 high speed UART.
Cc'ing Greg KH and Alan Cox for review of the the new serial driver in
this series.
Greg/Alan
1. Input transport via evdev is very convenient
2. There is no other standard alternative
Once there is standard interface for such sensors they will happily use
it and will not look back.
I think the fact that most of the interest in IIO is how do we make an
IIO/Input bridge speaks
IIO which is currently in staging.
Except we had ALS before that as a layer and Linus vetoed it. So there is
zero faith in IIO ever going anywhere.
Instead we now have about ten different light sensor APIs to the point
developers are writing a toolkit userspace plugin for *each* sensor.
--
To
My hope is that we can make use of a well known and uniform
API for all input devices in a device, be it a keypad,
touchscreen, accelerometer, magnetometer, gyro, or whatever.
If only we could agree what input devices are...
Is that the right test for some of these devices.
Surely
If non-input uses later need non-input interfaces they can switch to that
with an input bridge when there is one and when it happens, which
probably won't.
Would there even be an argument which subsystem to use if IIO-input
bridge existed today? Because if the answer is no then push into
On Mon, 30 Aug 2010 11:04:39 -0500
Felipe Balbi m...@felipebalbi.com wrote:
Hi Dmitry,
When we tried to push N900's accelerometer driver as an
input device you commented you didn't want sensors such
as accelerometers, magnetometers, proximity, etc on the
input layer because they are not
Why video4linux can't use the DMA API? Doing DMA with vmalloc'ed
buffers is a thing that we should avoid (there are some exceptions
like xfs though).
Vmalloc is about the only API for creating virtually linear memory areas.
The video stuff really needs that to avoid lots of horrible special
On Tue, 13 Jul 2010 17:30:43 +0900
FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp wrote:
On Tue, 13 Jul 2010 09:20:12 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Why video4linux can't use the DMA API? Doing DMA with vmalloc'ed
buffers is a thing that we should avoid (there are some
On Sun, 6 Jun 2010 12:46:01 +0200
Florian Mickler flor...@mickler.org wrote:
On Sun, 6 Jun 2010 12:00:47 +0200
Vitaly Wool vitalyw...@gmail.com wrote:
Even worse, the suspend wakelock will keep the
whole kernel active, as opposed to powering off unused devices
separately as it's done in
[mtg: ] This has been a pain point for the PM_QOS implementation. They
change the constrain back and forth at the transaction level of the i2c
driver. The pm_qos code really wasn't made to deal with such hot path use,
as each such change triggers a re-computation of what the aggregate qos
On Wed, 02 Jun 2010 11:10:51 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Wed, 2010-06-02 at 10:29 +0200, Thomas Gleixner wrote:
If I understood you correctly then you can shutdown the CPU in idle
completelty already, but that's not enough due to:
1) crappy applications
Is there any standardisation of the ABIs whcih these drivers offer? If
so, does this new driver comply with that?
There was an attempt to sort this out but Linux vetoed it because he is
under the delusion that light sensors are input devices. That doesn't
work in many use cases as you have to
Android does not only run on phones. It is possible that no android
devices have ACPI, but I don't know that for a fact. What I do know is
that people want to run Android on x86 hardware and supporting suspend
could be very benficial.
Sufficently beneficial to justify putting all this stuff
Keep in mind, though, that a solution which is acceptable for Android
has to include making sure that crappy applications don't cause the
Ted if you are speaking for Android do you think you should post from a
google address or with a google .sig ?
battery to get drained. There seem to be
Ted
As a PS to the previous email the situation has I think more choices than
you portray.
Given the need for various constraints imposed by drivers for things like
RT it's entirely possible that a solution ends up being something like
Kernel proper:
Turn suspend block kernel API into an
This is a much harder question to answer that what we need to use
opportunistic suspend. The question we ask is more like this: Is all
important work complete?. In the simplest case these can be the same,
I don't believe you can answer that question without telepathy and a
crystal ball.
The
My laptop behaves in
that way if for example the battery is almost flat. Your suspend blocker
would cause me to lose all my work with a flat battery. This is another
example of why the application must not be the policy manager.
You can still force suspend when the battery gets low.
Ok lets try and produce something more concrete. The control groups may
be the wrong tool but we've got several such tools already
Kernel involved
acquire:mark myself important (into cgroup important)
acquire(timeout)ditto, plus app timer/timeout handler
On Fri, 28 May 2010 14:30:36 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Fri, 2010-05-28 at 13:21 +0100, Alan Cox wrote:
[Total kernel changes
Ability to mark/unmark a scheduler control group as outside of
some parts of idle consideration. Generically useful
The UI manager gets told the phone is 'down'
Ten seconds later it is still down
- wakeup event that should be delivered to untrusted app arrives
here
At this point you may mark the downtrodden group as ignored between the
untrusted app receiving the event and the
On Fri, 28 May 2010 12:41:23 +0100
Matthew Garrett mj...@srcf.ucam.org 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 behaved
I think you are missing the point. It works fine if the alarm caused
the wakeup, but if you had just used your system and your inactivity
timeout expired just as your alarm goes off, the alarm will not wake
the system, nor does it prevent it from suspending.
As far as I can tell (and its an
That's very good. But if it is done in a conceptually flawed way, some
better solution should be considered for upstream merge.
How is it flawed? Serious question.
- It means changing drivers and quite a few apps
- It doesn't solve the problem of rogue apps if they end up owning locks
-
I think the suggestion that has the closet fit with what we're trying
to accomplish is Ingo's (or perhaps Ingo's explanation of Alan's):
http://lkml.org/lkml/2010/5/28/106 where it's implemented as a
constraint of some sort.
I think we ended up in the same place on our own.
Arve points out
On Fri, 28 May 2010 15:02:37 +0100
Ok, I think I've misunderstood you. You're actually saying that only
applications that are trusted to behave well are allowed to receive
wakeup events? Yes, that makes implementation significantly easier. If
To receive them in a manner that they are
I think Arve's concern was the representation of the I care, but only
a little or just low enough to ensure threads must run level which
is what suspend blockers would map to (low enough to ensure we
shouldn't halt the world but not necessarily implying a hard latency
constraint beyond that).
Now, if the user is playing this game, you want it to be scheduled. If
the user has put down their phone and the screen lock has kicked in, you
don't want it to be scheduled. So we could imagine some sort of cgroup
that contains untrusted tasks - when the session is active we set a flag
I
Heck, for all I care, simply SIGKILL the thing and report it once the
user starts looking at his screen again.
Provide incentive for Joe Clicker to improve his app, instead of cope
with the shit he created.
That isn't helpful. But if you feel like that I suggest you run with your
memory
The proposal I made a couple of days ago removes this API and leaves
the other things (i.e., the in-kernel suspend blockers and
opportunistic suspend) intact. In place of the userspace
kernel-blocker API, Android would have to implement a power manager
process that would essentially juggle
On Thu, 27 May 2010 17:09:16 +0200
Peter Zijlstra pet...@infradead.org wrote:
On Thu, 2010-05-27 at 11:06 -0400, Alan Stern wrote:
Opportunistic suspends are okay.
The proposed userspace API is too Android-specific.
I would argue opportunistic suspends are not ok,
No. Suspend blockers are designed to ensure that suspend isn't racy with
respect to wakeup events. The bit that mitigates badly written
applications is the bit where the scheduler doesn't run any more.
How does having applications taking blockers fix that - it makes it
worse. They are now
On Thu, 27 May 2010 17:07:14 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 04:05:43PM +0100, Alan Cox wrote:
Now, if the user is playing this game, you want it to be scheduled. If
the user has put down their phone and the screen lock has kicked in, you
don't
Opportunistic suspend is just a deep idle state, nothing else.
No. The useful property of opportunistic suspend is that nothing gets
scheduled. That's fundamentally different to a deep idle state.
Nothing gets scheduled in a deep idle state either - its idle. We leave
the idle state to
What is a Correctly implemented driver in this case? One that receives
a wakeup event and then prevents suspend being entered until userspace
has acknowledged that event? Because that's what an in-kernel suspend
blocker is.
Kernel side maybe - but even then its a subset of expressing
network packet arrives. The difference between these scenarios is large.
Your application seems to change desired outcome every email. Sorry but
you need to explicitly explain and define a policy in full that we can
test ideas against. Otherwise this is useless.
If you have wake-on-lan then
On Thu, 27 May 2010 18:40:19 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 07:34:40PM +0200, Peter Zijlstra wrote:
we still need to be able to enter suspend while the system isn't idle.
_WHY_!?
Because if I'm running a kernel build in a tmpfs and I hit the
So PCs with current ACPI don't get opportunistic suspend capability. It
probably won't be supported on the Commodore Amiga either - your point ?
Actually, the reverse - there's no terribly good way to make PCs work
with scheduler-based suspend, but there's no reason why they wouldn't
On Thu, 27 May 2010 18:57:19 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 07:52:59PM +0200, Peter Zijlstra wrote:
Shall we henceforth stop confusing forced suspend for laptops and
powersaving a running system?
If you want to support forced suspend for laptops
No, it's not. Forced suspend may be in response to hitting a key, but it
You are the only person here talking about 'forced' suspends. The rest of
us are talking about idling down and ensuring we are always in a state we
un-idle correctly.
may also be in response to a 30 minute timeout
On Thu, 27 May 2010 19:17:58 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 08:06:38PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:59 +0100, Matthew Garrett wrote:
On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at
If one works so does the other.
Not at all. The entire point of opportunistic suspend is that I don't
care is currently in TASK_RUNNABLE or has a timer that's due to expire
in 100msec - based on policy (through not having any held suspend
blockers), I'll go to sleep. That's easily
Sigh. No. Forced suspend is a fact of life
'Fact of life' isn't a useful reasoning basis. It tells me nothing about
how you got to that pronouncement.
Drivers should enable wakeups before they disable interrupts. So either
the packet hits the IRQ handler and the driver takes a suspend block
On Thu, 27 May 2010 20:29:26 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 08:25:38PM +0100, Alan Cox wrote:
The scheduler can happily do this, the power management will also
recognize STOPPED processes as no impediment to suspend.
But wakeup events won't
On Thu, 27 May 2010 19:23:03 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 08:18:49PM +0200, Thomas Gleixner wrote:
On Thu, 27 May 2010, Matthew Garrett wrote:
Actually, the reverse - there's no terribly good way to make PCs work
with scheduler-based suspend,
We were talking about PCs. Suspend-as-c-state is already implemented for
OMAP.
You were talking about PCs. Some of us are interested in the making
Linux do the right thing not adding platform specific hacks all over the
userspace of all the apps.
So the only thing you are imposing to app
The event was not lost.
Not lost, but not delivered. So you need your policy agent to send
it will be delivered next time the process wakes. It's not lost.
SIGCONT when you receive any wakeup event, which either means proxying
all your network traffic through your policy agent or having
On Thu, 27 May 2010 18:59:20 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 07:56:21PM +0200, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 18:52 +0100, Matthew Garrett wrote:
If that's what you're aiming for then you don't need to block
applications on
That's the point -- suspend does not evaluate the system state
correctly because it doesn't have the necessary information. Suspend
The power management layer knows if the machine is idle, it has insight
into when the next wakeups will occur.
blockers are a way of providing it that
Well, what about when I want the machine to suspend _regardless_ of whether
or not it's idle at the moment? That actually happens quite often to me. :-)
I don't think it helps to combine them for this discussion ?
I don't see much difference between that and ACPI S3 other than the memory
On Thu, 27 May 2010 13:29:18 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
On Thu, 27 May 2010, Peter Zijlstra wrote:
On Thu, 2010-05-27 at 13:04 -0400, Alan Stern wrote:
Does this mean you believe echo mem /sys/power/state is bad and
should be removed? Or echo disk
On Thu, 27 May 2010 18:25:10 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 07:20:56PM +0200, Peter Zijlstra wrote:
Suppose X (or whatever windowing system) will block all clients that try
to draw when you switch off your screen.
How would we not wake them
On Thu, 27 May 2010 22:36:35 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 10:37:51PM +0100, Alan Cox wrote:
On Thu, 27 May 2010 18:25:10 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
How (and why) does the WoL (which may be *any* packet, not just a magic
On Thu, 27 May 2010 17:38:03 -0400 (EDT)
Alan Stern st...@rowland.harvard.edu wrote:
and power management does the rest. If an event wakes up the process
before we get to suspend in kernel we will wake it back up.
Okay, and the kernel never suspends. We _are_ talking about a kind of
On Thu, 27 May 2010 23:55:13 +0200
Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday 27 May 2010, Alan Cox wrote:
If one works so does the other.
Not at all. The entire point of opportunistic suspend is that I don't
care is currently in TASK_RUNNABLE or has a timer that's due
On Thu, 27 May 2010 23:09:49 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote:
This is I believe robust (and has been implemented on some non x86
boxes). It depends on not forcing running tasks into suspend. That is the
key
The kernel performs no explicit notification to userspace. With legacy
For a PC ACPI using type device /proc/acpi/events which wakes acpid which
wakes gnome-power-manager which wakes half the universe
Do we need a better more generic version of the events files - maybe but
thats a rather
On Thu, 27 May 2010 23:36:05 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 11:23:57PM +0100, Alan Cox wrote:
On Thu, 27 May 2010 23:09:49 +0100
Matthew Garrett mj...@srcf.ucam.org wrote:
On Thu, May 27, 2010 at 11:08:06PM +0100, Alan Cox wrote
The approach with user space power manager suggested by Dmitry and Alan Stern
may work, but it still assumes some kind of suspend blockers to be present in
the kernel. If we reject that too, I wonder what approach Google is supposed
to use and still get the same battery life they get with
I don't think x86 is relevant anyway, it doesn't suspend/resume anywhere
near fast enough for this to be usable.
Yet...
My laptop still takes several seconds to suspend (Lenovo T500), and
resume (aside from some userspace bustage) takes the same amount of
time. That is quick enough for
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows app)
And if you have two kernels, one with which your device is dead after 1
hour and one with which your device is dead after 10 hours. Which would
Nonetheless, I really think the kernel needs to allow for the android
way of power saving. It misses out on a big feature and a big user-base
if not.
That seems to me to be conflating models of behaviour and implementations.
This is a _big_ plus for attracting 3rd party programs. (And of
I'm not saying that your argument is not valid. But why don't you look
at suspend blockers as a contract between userspace and kernelspace? An
Opt-In to the current guarantees the kernel provides in the non-suspend
case.
It is a contract - but not the right one. You are removing autonomy from
The power efficiency of a mobile device is depending on a sane overall
software stack and not on the ability to mitigate crappy software in
some obscure way which is prone to malfunction and disappoint users.
Even if you believe the kernel should be containing junk the model that
works and is
suspend blockers are completely backwards as they basically disable
the kernels ability to do resource management.
I don't think this is a defect in the approach but the point of it.
I think it's both. It's the point of it, and that itself is a defect. Its
designed wrongly.
drivers code
On Wed, 26 May 2010 15:30:58 -0700
Arve Hjønnevåg a...@android.com wrote:
On Wed, May 26, 2010 at 6:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Really, what are you getting at? Do you deny that there are programs,
that prevent a device from sleeping? (Just think of the bouncing
cows
stable and software has to cope with fewer events. We've lived without
it for quite some time, though.
We lived without graphics for quite some time, without 64bit for quite
some time ;)
Alan
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index cd85fd1..ed1ed74 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1461,9 +1461,14 @@ int gpio_set_debounce(unsigned gpio, unsigned debounce)
spin_lock_irqsave(gpio_lock, flags);
+
One of the earlier examples of why to want debouncing (in the
original discussion, not this one) was for buttons (one signal
per button press) and the hardware designers don't necessarily
hook buttons up to only GPIOs with hardware debounce. So code
to kick in debounce there needed to be
+EXPORT_SYMBOL_GPL(gpio_set_debounce);
nitlet: I suspect this function is taking gpio_lock sooner than it
strictly needs to. Find-tuning that would decrease contention by an
insignificant amount ;)
We need this for Intel MID boxes as well Andrew - so its a generic need.
Alan
--
To
+ 213 = /dev/ttyO0 OMAP serial port 0
+ 214 = /dev/ttyO1 OMAP serial port 1
+ 215 = /dev/ttyO2 OMAP serial port 2
+ 216 = /dev/ttyO3 OMAP serial port 3
I think it might be best to
On Tue, 19 Jan 2010 22:17:59 +0100
Wim Van Sebroeck w...@iguana.be wrote:
Hi All,
please comment on following patch.
Why move them out - why not just make them const ?
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
On Tue, 17 Nov 2009 15:16:55 -0600
Vikram Pandita vikram.pand...@ti.com wrote:
OMAP3630 and OMAP4430 UART IP blocks have a restriction wrt RX FIFO.
Empty RX fifo read causes an abort. OMAP1/2/3 do not have this restriction.
Nothing wrong with the requirement but I think it would keep 8250.c a
1 - 100 of 107 matches
Mail list logo
