On Tue, Jun 02, 2009 at 05:48:37PM +, James Bottomley wrote:
On Tue, 2009-06-02 at 11:29 -0600, Grant Likely wrote:
firmware issue, where existing firmware passes very little in the way
of hardware description to the kernel, but part is also not making
available any form of common
On Fri, Aug 28, 2009 at 04:41:38PM +0200, Johannes Stezenbach wrote:
On Thu, Aug 20, 2009 at 02:56:49PM +0200, Johannes Stezenbach wrote:
which came with the 2.6.20 kernel. The delay between irq -
netif_rx_schedule() - NET_RX_SOFTIRQ - -poll() doesn't seem
to be long enough. But of
On Fri, Nov 20, 2009 at 03:21:31PM -0700, Grant Likely wrote:
On Tue, Nov 17, 2009 at 1:27 AM, David Brownell davi...@pacbell.net wrote:
Since *everything* boils down to one or more signal lines,
your argument leads directly to Linux having no native
hardware interface except GPIOs. ?Not
On Mon, Nov 23, 2009 at 10:44:25AM -0700, Grant Likely wrote:
Right, pin-mux is a different problem. But there are also devices
that implement both PWM and GPIO functionality in the same IP block.
That's not the general case, though - most of the SoCs seem to have PWM
as a separate IP block.
On Fri, Dec 04, 2009 at 11:42:22AM +0100, Linus Walleij wrote:
Most devices of this kind does not need the stuff we're doing so we're
the odd bird here. Other batteries are smart (contain factory
calibration inside of them) or get calibration from some BIOS or such.
In our code we have a
On Fri, Dec 04, 2009 at 10:49:31AM +, Mark Brown wrote:
Isn't the standard thing here to handle this voltage to capacity mapping
in userspace if we're just extrapolating from experimental results?
Even with the smart batteries in PCs there are some accuracy concerns
and obviously
On Sat, Dec 05, 2009 at 02:08:11PM +0100, Linus Walleij wrote:
[Mark Brown]
Isn't the standard thing here to handle this voltage to
capacity mapping in userspace if we're just extrapolating
from experimental results?
That's an easy solution of course, but then the sysfs files
specified
On Mon, Dec 07, 2009 at 03:07:15PM +0100, Linus Walleij wrote:
[Mark wrote]
These files should only be present if we have data for them.
Userspace can't be reliant on them at present since relatively few
systems seem to implement them, for example none of my laptops
have time_to,
On Mon, Dec 07, 2009 at 09:27:20PM -0800, Brian Swetland wrote:
On Mon, Dec 7, 2009 at 8:56 AM, Mark Brown
I don't think the existing Android devices are much of an issue here,
it's not as though end users have the ability modify the firmware on
them (modulo the fairly small number of ADP
On Sun, Dec 13, 2009 at 02:19:22PM +0100, Pavel Machek wrote:
...but then there are all the systems that rely on /proc/apm
emulation, like openembedded popular on sharp zaurus...
OpenEmbedded is a meta-distribution so doesn't use any particular
software here - I suspect you're referring to
On Sun, Dec 13, 2009 at 02:24:14PM +0100, Pavel Machek wrote:
actual charger hardware. My main concern here is that battery
performance monitoring has no pressing need to be in kernel and that
pushing it into the kernel creates a barrier to implementing more
advanced schemes in
On Fri, Sep 17, 2010 at 05:32:42PM -0600, Grant Likely wrote:
Mark or Liam: ASoC - How what needs to be done to collect disparate
devices (codecs, audio controllers, etc) into a single SoC device.
Mark and Liam, I know you haven't made a proposal to do this, but if
you'd be willing I think
On Mon, Feb 07, 2011 at 01:48:46PM +0100, Ingo Molnar wrote:
* Mark Brown broo...@opensource.wolfsonmicro.com wrote:
Since having the configuration option requires non-zero effort to
maintain, with ifdefery in most drivers, but it is used with vanishing
rarity it is simpler to just remove
On Tue, Feb 08, 2011 at 01:44:32AM +1100, Stephen Rothwell wrote:
On Mon, 7 Feb 2011 14:18:29 + Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
Do you mean that these systems require CONFIG_PM be turned off, or just
that people tend not to turn it on? If the latter would you
On Tue, Feb 08, 2011 at 02:19:16AM +1100, Stephen Rothwell wrote:
At least some of the powerpc defconfigs were added with CONFIG_PM
disabled. I assume that was on purpose (though it may not have been).
I'd not be so sure - since it's a bool without an explicit default set
Kconfig will default
On Mon, Feb 07, 2011 at 10:36:31AM -0500, Alan Stern wrote:
On Mon, 7 Feb 2011, Mark Brown wrote:
I'd not be so sure - since it's a bool without an explicit default set
Kconfig will default to disabling it and if anything enabling it is the
option that requires special effort.
This may
On Mon, Feb 07, 2011 at 08:14:03PM +0100, Rafael J. Wysocki wrote:
On Monday, February 07, 2011, Mark Brown wrote:
config PM_DEBUG
bool Power Management Debug Support
I think it would be better to simply rename CONFIG_PM_OPS into CONFIG_PM.
That still leaves the IA64 emulator
On Mon, Feb 07, 2011 at 08:46:48PM +0100, Rafael J. Wysocki wrote:
On Monday, February 07, 2011, Mark Brown wrote:
On Mon, Feb 07, 2011 at 08:14:03PM +0100, Rafael J. Wysocki wrote:
I think it would be better to simply rename CONFIG_PM_OPS into CONFIG_PM.
That still leaves the IA64
On Mon, Feb 07, 2011 at 05:17:59PM -0800, Ray Lee wrote:
On Mon, Feb 7, 2011 at 7:49 AM, Mark Brown
I'm rather hoping that they'll notice the mailing list thread or that
someone else who knows what's going on with them does
Surely you're joking. I mean, do _you_ scan every message
On Mon, Feb 07, 2011 at 06:52:00PM -0800, Frank Rowand wrote:
On 02/07/11 04:22, Mark Brown wrote:
Since having the configuration option requires non-zero effort to
maintain, with ifdefery in most drivers, but it is used with vanishing
rarity it is simpler to just remove the option
On Tue, Feb 08, 2011 at 03:35:29PM -0800, Frank Rowand wrote:
For 2.6.38-rc4, x86_64, CONFIG_NR_CPUS=4:
size vmlinux
text data bss dec hex filename
6553910 3555020 9994240 20103170 132c002 vmlinuxwithCONFIG_PM
6512652 3553116 9994240 20060008
On Wed, Feb 09, 2011 at 10:31:29AM -0800, Frank Rowand wrote:
Raphael's patch will turn on CONFIG_PM in the correct circumstances, and
leave it off when not needed by other config options. That means that
the size overhead will _not_ be an issue for me because CONFIG_PM
will not be enabled
On Wed, Feb 09, 2011 at 11:53:52AM -0800, Tim Bird wrote:
On 02/09/2011 11:25 AM, Mark Brown wrote:
Not really, the goal was to simplify the PM config options to ones that
are actually useful and cut down on the number of silly combinations
that the randconfigs turn up. CONFIG_PM
On Mon, Feb 21, 2011 at 08:18:50AM -0600, Bill Gatliff wrote:
But implementing a rate-specifying sysfs attribute isn't enough,
however. Under the Linux kernel's current input device buffering
scheme, drivers and applications can create and consume input events
every 100ms, for example, but
On Mon, Feb 21, 2011 at 10:07:12PM -0600, Bill Gatliff wrote:
A good case in point comes up when someone moves an Android
implementation from one platform to another. No two accelerometer
drivers seem to agree on how to specify the desired event generation
rate, so the migration effort is
On Fri, Feb 25, 2011 at 08:46:24PM -0600, Bill Gatliff wrote:
On Mon, Feb 21, 2011 at 10:33 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
But surely the most obvious solution here is to standardise a rate
control interface?
Yes, and no. A standardized rate control interface
On Fri, Mar 04, 2011 at 08:41:00AM -0800, Bill Gatliff wrote:
Guys:
As ever please remember to CC maintainers so they see your mails,
especially if you're going to mail a different list to the one usually
used for development of the subsystem you're working on.
The text in
On Fri, Apr 15, 2011 at 04:46:08PM -0600, Jonathan Corbet wrote:
That means getting more people to look at the patch, which could be hard.
The problem is that, if you wait, they'll only squeal when the code is
close to going in, and you could find yourself set back a long way. A
good first
On Tue, Nov 08, 2011 at 04:39:17PM +0530, R, Durgadoss wrote:
[I have posted this on lm-sensors and platform-drivers-x86
lists earlier. As per some recommendations there, posting it
here]
lkml would probably be useful. It'd also help if you could publish code
along with your mail, in general
On Fri, May 04, 2012 at 07:34:08PM +, Arnd Bergmann wrote:
One idea that I've heard before is to put device tree fragments into the
kernel and dynamically add them to the device tree that was passed by the
boot loader whenever we detect the presence of a specific device.
This obviously
On Fri, May 04, 2012 at 01:50:01PM -0600, Stephen Warren wrote:
On 05/04/2012 12:58 PM, Mark Brown wrote:
Quite a few reference platforms (including Wolfson ones, which is why
I'm particularly interested) use replaceable modules to allow
configuration changes. Since we can often identify
On Fri, May 04, 2012 at 03:09:19PM -0600, Stephen Warren wrote:
On 05/04/2012 03:03 PM, Arnd Bergmann wrote:
Sure, there are a lot of things that the boot loader can use from the
device tree, but I'm not sure if the LCD panel connection fits into
the same category as the devices that Mark
On Sat, May 05, 2012 at 12:52:25AM +0100, Russell King - ARM Linux wrote:
How about this - we have struct platform_device_info, which is used to
create platform devices. We can use this as an array to describe what
platform devices to create in the sub-driver, including what the resources
On Tue, May 08, 2012 at 02:26:54PM +0200, Linus Walleij wrote:
On Fri, May 4, 2012 at 9:34 PM, Arnd Bergmann a...@arndb.de wrote:
Thanks for getting the discussion started. I've seen the same issue come
up for arch/arm/mach-ux500/board-mop500*uib.c and for the beaglebone.
I'm sure there
34 matches
Mail list logo
