Re: Handling of modular boards

2012-05-09 Thread Mark Brown
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

Re: Handling of modular boards

2012-05-04 Thread Mark Brown
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

Re: Handling of modular boards

2012-05-04 Thread Mark Brown
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

Re: Handling of modular boards

2012-05-04 Thread Mark Brown
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

Re: Handling of modular boards

2012-05-04 Thread Mark Brown
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

Re: A new Subsystem for Current Management

2011-11-08 Thread Mark Brown
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

Re: [PATCH] extra/1 Allow setting the maximum KBUS message size

2011-04-18 Thread Mark Brown
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

Re: Question on regulator platform device

2011-03-04 Thread Mark Brown
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

Re: [PATCH] input: evdev: Add a read() callback

2011-02-26 Thread Mark Brown
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

Re: [PATCH] input: evdev: Add a read() callback

2011-02-21 Thread Mark Brown
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

Re: [PATCH] input: evdev: Add a read() callback

2011-02-21 Thread Mark Brown
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

Re: [PATCH] Remove CONFIG_PM altogether, enable power management all the time

2011-02-09 Thread Mark Brown
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

Re: [PATCH] Remove CONFIG_PM altogether, enable power management all the time

2011-02-09 Thread Mark Brown
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

Re: [PATCH] Remove CONFIG_PM altogether, enable power management all the time

2011-02-09 Thread Mark Brown
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

Re: [PATCH] PM: Hide CONFIG_PM from users

2011-02-08 Thread Mark Brown
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

Re: [PATCH] PM: Hide CONFIG_PM from users

2011-02-08 Thread Mark Brown
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

[PATCH] PM: Hide CONFIG_PM from users

2011-02-07 Thread Mark Brown
missing device support. This is a very limited use case which is unlikely to ever want to enable most drivers. Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com --- kernel/power/Kconfig | 21 ++--- 1 files changed, 2 insertions(+), 19 deletions(-) diff --git a/kernel

Re: [PATCH] PM: Hide CONFIG_PM from users

2011-02-07 Thread Mark Brown
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

Re: [PATCH] PM: Hide CONFIG_PM from users

2011-02-07 Thread Mark Brown
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

Re: [PATCH] PM: Hide CONFIG_PM from users

2011-02-07 Thread Mark Brown
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

Re: [PATCH] PM: Hide CONFIG_PM from users

2011-02-07 Thread Mark Brown
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

Re: [PATCH] PM: Hide CONFIG_PM from users

2011-02-07 Thread Mark Brown
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

Re: [PATCH] PM: Hide CONFIG_PM from users

2011-02-07 Thread Mark Brown
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

Re: Linux Plumbers Embedded microconference

2010-09-18 Thread Mark Brown
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

Re: [POWER] battery calibration parameters from sysfs

2009-12-14 Thread Mark Brown
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

Re: [POWER] battery calibration parameters from sysfs

2009-12-14 Thread Mark Brown
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

Re: [POWER] battery calibration parameters from sysfs

2009-12-14 Thread Mark Brown
On Mon, Dec 14, 2009 at 12:58:26PM +0100, Pavel Machek wrote: On Mon 2009-12-14 11:50:24, Mark Brown wrote: OpenEmbedded is a meta-distribution so doesn't use any particular software here - I suspect you're referring to things like the GPE stack which isn't so actively developed these days

Re: [POWER] battery calibration parameters from sysfs

2009-12-08 Thread Mark Brown
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

Re: [POWER] battery calibration parameters from sysfs

2009-12-07 Thread Mark Brown
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

Re: [POWER] battery calibration parameters from sysfs

2009-12-07 Thread Mark Brown
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,

Re: [POWER] battery calibration parameters from sysfs

2009-12-04 Thread Mark Brown
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

Re: [POWER] battery calibration parameters from sysfs

2009-12-04 Thread Mark Brown
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

Re: [PATCH 0/6] Generic PWM API implementation

2009-11-23 Thread Mark Brown
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

Re: [PATCH 0/6] Generic PWM API implementation

2009-11-23 Thread Mark Brown
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.

Re: 100Mbit ethernet performance on embedded devices

2009-08-28 Thread Mark Brown
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

Re: Representing Embedded Architectures at the Kernel Summit

2009-06-03 Thread Mark Brown
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