Re: Handling of modular boards

[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 are many more, but we should make sure that everyone
  of these can live with whatever we come up with.

 The same issue sort of comes up with any system that uses the idiom
 to have a few GPIO lines indicate in a binary code what version of the
 board we're dealing with and what devices are thus on it, right?

 We have this issue for the U9540 reference design and potentially
 on the Snowball as well.

Yes, I think that's basically the same problem.


signature.asc
Description: Digital signature

Re: Handling of modular boards

[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 means it works only for boards using DT for booting, but
 it allows us to use some infrastructure that we already have.

I think anything that relies on bootloaders (or DT for that matter) is a
bit of a non-starter for my personal use cases.  Even where we're using
DT relying on a sane bootloader seems a bit scary - my personal use
cases would rely on updating this stuff in the field for non-technical
users who would have trouble recovering from issues.

 An intermediate solution that I really like is the ability to
 stuff device tree fragments on extension board themselves, but that
 can only work for new designs and causes problems when that information
 is not actually correct.

I can see the theory, but I can also see some practical concerns.  And
with the boards I'm working with we currently have 8 bits of data so...
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Handling of modular boards

[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 the configuration at
  runtime we should ideally do that but currently there's no infrastructure 
  to help with that...

 So, I'll respond within the context of device tree, although perhaps you
 were looking for something more general?

Like I just said in reply to Arnd I think that anything that relies on
the device tree is rather optimistic.  Device tree isn't even universal
for ARM and there's a huge raft of architectures that have no current
intention to adopt DT at all.  For example I understand that a lot of
the Blackfin boards are modular, though I don't know to what extent they 
can usefully be enumerated from software.

I know DT is a shiny new toy and all that but when developing generic
infrastructure there needs to be an awareness that we can't rely on it.

 I was just asked basically the same question internally to NVIDIA. One
 option that was floated was to store the device tree in chunks and have
 the bootloader piece them together. You'd start with the DT for the
 basic CPU board, probe what HW was available, and then graft in the
 content of additional DT chunks and pass the final result to the kernel.
 The advantages here are:

 a) The DT is stored in chunks for each plugin board, so there's no bloat
 in the DT that gets passed to the kernel; it contains exactly what's on
 the board.

 a) Relies on the bootloader, so is somewhat out of our control.

Yes, this is a crippling issue for my personal usecases.

 b) Doesn't integrate well with hotplug; the DT for the board
 configuration is static at boot. What if a board can be unplugged and
 another plugged in; a reboot or similar would be needed to adjust the
 kernel to this.

This is another issue - a similar set of problems does apply to some PCI
type cards where the PCI device is essentially a bridge to a typical
embedded system - though practically speaking it's much less severe.

 Another approach would be to put everything in a single DT, with some
 representation of how to identify the child boards, and then have the
 kernel only use/parse certain chunks of the DT based on the ID results.
 I’m not sure how complex that would be. Perhaps something like:

This does also have the disadvantage of requiring the device tree for
each CPU to be updated for every single plugin module which could get a
bit tedious (this does also apply to the approach of having the
bootloader create the DT - it scales fine if the CPU is a part of the
base board but if the CPU is one of the swappable modules it's less
clear).  Plus...

 The complexity here is that all the devices on the daughter board would
 end up being on different buses (e.g. 2 different I2C busses, an SPI
 bus, even an MMIO bus) so representing this in the daughter board nodes
 would be complex. Do we insert a daughter board mux onto every single
 bus that's routed to the daughter board connectors, or add the ability
 to dynamically add nodes into pre-existing busses, e.g. add
 /daughter-board/board-a/i2c-0 into /tegra-i2c@xxx/?

...there's this, I'm not sure the daughterboard mux is going to fly.
It's requiring each and every bus to understand this concept which seems
like a bit of an imposition to me, especially given that it exists
purely to service the needs of DT.  The idea of having DT blobs injected
for the modules seems easier than this.

I do think we want to be able to write drivers for modules; if we can go
with injecting DT blobs then from a kernel point of view everything is
already sorted so there's nothing to do but this doesn't feel like it
actually resolves the issue, at least for me.  For example, with my
current systems it'd require a DT port for s3c6410 plus the addition of
both DT support and hardware module identification to our current
bootloader and then the ongoing maintainance of the device trees for all
the CPU and board combinations that might exist.  This seems like a lot
of work.


signature.asc
Description: Digital signature

Re: Handling of modular boards

[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 was thinking of.

 A board I have sitting on my desk right now has separate boards for (and
 multiple options for each of):

 * Motherboard
 * CPU+DRAM
 * PMU/PMIC
 * Display (LCD)
 ... and many more.

 Interaction with the PMU/PMIC is required for at least some of the boot
 media options.

Yeah, similar setup for our boards except the PMICs are soldered down
onto other boards.  We've got a mainboard, three audio boards of various
kinds, a random non-audio components board and a CPU/DRAM board.

There's good solid engineering reasons for doing this.  CPUs and RAMs
tend to be very high density devices with lots of pins and be difficult
enough to route to require large numbers of layers (and ideally you want
the PMIC to be physically close to them since long traces tend to become
electrically interesting for CPU style loads, especially when routed
through connectors) all of which leads to an expensive board which you
pay for by area.  With reference boards with large form factors it's
worth the effort to have a separate, smaller, board manufactured to meet
these requirements - even in very low volumes the cost wins are
noticable.


signature.asc
Description: Digital signature

Re: Handling of modular boards

[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
 should be etc.

We (well, I at least) need to handle devices on other buses like I2C and
SPI too but yes, that's the sort of thing I was looking for.

 However, there's a problem with this - what if you need to do some board
 level init before hand?  That needs to be handled somehow before these
 devices are instantiated.  That could be done via a callback through
 platform data.

 But... this all seems wrong, because rather than having a driver which
 knows about the details of the board, we now have all the details of the
 board in question back in platform code which originally declared the
 board device.  That's wrong, because a daughter board may be shared
 between different platforms, and we don't want multiple copies of that
 data all around the place.

 I don't think there's an easy or generic solution to this.

I think that's OK - if there's any init stuff that needs to be done on a
prior to identification of the board then presumably it's a generic
thing for the motherboard which will apply to any plugin module on that
board and can be done as part of the normal board init.  If the init
needs to be done after identification of the board then probably it
applies to any motherboard the board might be plugged in to so we can
just define callbacks for the plugin module that can be part of the
plugin module description.

Cases that depend on a specific combination will doubtless exist and do
have the problems you describe but are probably less frequent but I
think we can go a long way on the first two.


signature.asc
Description: Digital signature

Re: A new Subsystem for Current Management

[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 people are much more likely to review
concrete code.

 In simple terms, this framework will offer something like this:
   Current[1-N]_limit - set of current limits
   Voltage[1-X]_limit - set of voltage limits

What would the voltage limits be?  Whatever is going on here there
should be some integration with the regulator framework, modern
regulators are often able to report when they go out of regulator and
able to impose current limits.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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 step might be to CC Andrew Morton on your next posting.

One other thing that it'd be good to see is a contrast and compare with
other similar things like the Android binder that are floating around.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Question on regulator platform device

[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 Documentation/power/regulator/machine.txt describes how to
 place regulator_init_data and regulator_consumer_supply structures
 into the .dev.platform_data field of a platform_device structure.  The
 platform_device.name field equals regulator.

 Trouble is, I can't find anywhere in the drivers/regulator code that
 registers a platform_driver named regulator.  Am I just going blind?

This is just an example of how to supply platform data to a device.
You need to pass things into the driver for whatever regulator you are
using.  There are quite a few systems in the tree using regulators
which you can use for reference...
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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 would deal with
 the rate control problem, but leave the synchronization problem
 unsolved.

The main source of the problem with delayed readings was that
applications weren't blocking waiting for events.  If applications block
waiting for events then the data will be delivered to them promptly.
For cases where multiple readings need to be synced IIO looks like the
way forward.

  The problem you're trying to solve is also an issue for really common
  and standard things like touchscreens and polled switches/keys (the
  latter of which you mentioned in your mail) which are used by standard
  applications.

 The existing polled switch implementation sets up a throttled
 polling loop in kernel code.  The polled switch that I was thinking
 of when I wrote the essay for the commit was a switch that is polled
 each time read() gets called.  I should have been clearer--- and
 probably picked a different name.  :)

It's the same thing, though - I'd really expect it to be handled by the
same code in kernel.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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 there is always the possibility that an
 input event will sit in the queue for 99ms waiting for an application
 to retrieve it.  For devices and applications where this potential
 delay causes problems, drivers must implement an external means for
 applications to trigger the timely production of an input event.

I don't see how any of the above shows an issue with rate limiting in
the application image.  As was discussed in some detail the last time
you posted this the issue that's causing the applications to experience
delayed notifications of events is that rather than blocking waiting for
an event to be delivered to them they're sleeping unconditionally.  If
the application were to use a rate control in conjunction with blocking
(which is the expected programming model) then a rate control will do
exactly what's expected.

 The enclosed patch address all of the above problems by implementing
 an advisory callback from the evdev read() and poll() methods to the
 associated input device driver.  The driver may then choose to
 populate the input event buffer at that time, rather than on a
 schedule implemented by a polling loop, sysfs trigger, or other means.

 Use of this callback by a driver naturally synchronizes the generation
 of input events to requests from userspace, because the driver now
 knows when userspace is attempting to retrieve an input event and
 can therefore produce one just-in-time.  It also allows the driver to
 easily match the rate of input event generation, by simply sampling the
 hardware only during this callback.

This doesn't address the issue raised in the previous discussion with
the poor interaction with applications that do behave sensibly and block
for events from the device - either we can't use the ability to trigger
readings from the hardware or we end up doing extra readings because
every read triggers an additional sample.

 If an input device driver chooses to use only the read() callback as
 its signal to produce an input event, then the driver need not
 implement a polling kernel thread or other means of pacing its event
 generation rate.  The driver also has no need to provide a sysfs
 attribute to allow userspace to request a polling rate or to trigger a
 measurement: userspace must only read() or poll() the interface at the
 desired rate.  This can greatly simplify input device driver
 implementation, while conveniently leaving the incoming event rate and

This is all stuff that can be put into a library (parts of it are
already) so there's no real cost to drivers from implementing anything.

 Finally, input device drivers might choose to implement a holdoff
 timer that gets reset in the read() callback; expiration of this timer
 would mean that userspace is no longer actively reading from the
 device, even though the interface itself might still be open.  In such
 cases the driver might wish to invoke a power-management method to
 idle the hardware until the next  callback occurs.

This will again interact poorly with event driven applications - if
notifications to userspace don't happen (eg, because there has been no
change) then there will be no cause for the application to read.

I can see a use for a read on demand callback in the implementation of
polling (eg, if rate is set to zero or for the core polling library to
use) but the userspace API thats being proposed here seems like it's
going to cause problems for applications that try to do the right thing.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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 increased.  And the work is divided
 between both kernel and userspace: the former in its mandate to
 provide a rate-request interface, and the latter to utilize that
 interface.  I really don't see the point in this.

But surely the most obvious solution here is to standardise a rate
control interface?  Anything else means we need a completely different
implementation for hardware which does have the ability to schedule its
own conversions.

 As I mention in my commit log/essay, devices like USB keyboards and
 other event-driven hardware have no use for my read callback idea, and
 can safely ignore it.  And I don't see a day on the horizon where
 anyone will plug an accelerometer into X and expect X to deal with it
 as properly as it does today for keyboards and mice.  I don't think
 the do the right thing applications you are referring to will be
 affected by the read callback at all, since the callback doesn't apply
 to ordinary, do the right thing-type situations.

The problem you're trying to solve is also an issue for really common
and standard things like touchscreens and polled switches/keys (the
latter of which you mentioned in your mail) which are used by standard
applications.

 But if the accelerometer measurement has to be synchronized with some
 other event, things get a little trickier.  At the moment my concerns
 for this are theoretical, but I can see some situations coming soon
 where the theory could be usefully put to practice.

Have you looked at the IIO subsystem for things like this?  There has
been talk of putting accelerometers in there and it certainly fits in
with the sync requirements you're mentioning.

  If the application were to use a rate control in conjunction with blocking
  (which is the expected programming model) then a rate control will do
  exactly what's expected.

 No argument with that.  My main complaint is that everyone is doing
 rate control APIs differently.  I'm proposing a way to standardize
 them by eliminating them altogether.  A side-effect of my idea is that
 applications get complete control over event generation.  Many of them
 won't care about that, but some will.

The problem with your proposal as it stands is that if they do use the
new interface they interact badly with existing applications.  This
isn't really a decision the driver should be taking, it needs to be
userspace policy if it's going to be a decision at all.

 I recognize your concern.  But I don't think that the applications
 which could be confused by the behavior I'm proposing would be the
 same applications that would take advantage of it.  Or, perhaps, such
 applications might welcome eliminating the code needed to support the
 different rate-limiting interfaces of a half-dozen or more devices
 that they claim compatibility with.

Again, you appear to be assuming that there are many rate limiting
interfaces.  Surely the solution to an excess of rate limit interfaces
is to standardise the rate limiting interfaces rather than invent a new
interface, especially one that interoperates poorly with blocking apps?

  This is all stuff that can be put into a library (parts of it are
  already) so there's no real cost to drivers from implementing anything.

 ... except the redundancy of everyone doing it slightly differently.
 Why not settle on a common approach, so the library you mention isn't
 necessary at all?

Note that I'm talking about in-kernel code here, not a linked library in
userspace.  One way or another *something* is going to have to provide
the scheduling support.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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  1321768  vmlinuxwithout CONFIG_PM
 
   41258 1904 0 43162  delta

 That is big enough for me to care.

Hrm, that's pretty surprising.  It'd be interesting to know how much of
that is due to the PM core itself and how much of that is from drivers.
For the drivers CONFIG_PM isn't really the option they should be using
in the first place - they mostly want some combination of PM_SLEEP and
PM_RUNTIME for the specific functionality.  I'm running some checks now.

   CONFIG_PM_SLEEP=y

Raphael's patch will make this a user visible option in place of raw
CONFIG_PM by default so you'd be able to turn that off.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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 when not needed.

That's not the issue you seemed to be raising, though.  While PM is now
turned on by PM_SLEEP that'll end up getting turned on by default due to
the dependency on SUSPEND - you appeared to be raising the concern that
this could happen and surprise users.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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 is there mostly for historical
  reasons, it doesn't really mean much by itself except as a gate to other
  options.

 I'm confused.  Do you plan to retain the option to
 turn off PM features completely, or not?  I thought that's
 what CONFIG_PM did today.

Raphael's patches do that in a much better way than my original patch,
my original patch would have force CONFIG_PM on but still allowed all
the PM features that it controls to be turned on and off individually.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM: Hide CONFIG_PM from users

[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 that comes
 through lkml and its various sister lists?

Actually I do at least scan most of the lists.

 Do a git blame and add them to the CC:. It's the polite thing to do.

It's also going to result in the mail not going to the mailing lists as
there's a limit on the number of people you can CC enforced by vger
which probably isn't constructive.  It's moot now but as I said in the
text you've helpfully cut I'd have suggested contacting them after the
thread had come to a conclusion.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM: Hide CONFIG_PM from users

[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.

 Proof by assertion that it is used with vanishing rarity.

Sure, hopefully if it's incorrect people will come out of the woodwork
to correct me :)

 That is not a good method of getting feedback from users.

  1) It immediately removes the ability to have CONFIG_PM undefined,
 without first giving active users a chance to provide feedback.

Note that it's not a terribly difficult change to reverse; if someone
urgently does need to do so then I'd be surprised if they were able to
build a kernel but not cope with that change.

  2) The removal of that ability is not obvious (make oldconfig does
 not say anything about CONFIG_PM).  It is easy to overlook a
 config change that happens silently.

It will expose the sub-options which actually do stuff, though - it's
only the top level option for PM.

 Would it be appropriate to use Documentation/feature-removal-schedule.txt
 if this truly will be removed?

I guess, though I'm a bit pessimistic about anyone actually noticing.
With Raphael's version it's not such a big deal as CONFIG_PM is selected
by other options that previously depended on it instead of being enabled
all the time.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM: Hide CONFIG_PM from users

[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 the option.

 Well, either make it dependent on CONFIG_EXPERT or remove the option 
 altogether.

The goal is the latter but when I saw the IA64 emulator there I didn't
want to make it instabuggy.  The current patch means we get the UI
effect of the change (especially in terms of avoiding it turning up in
randconfigs or whatever).
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM: Hide CONFIG_PM from users

[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 expect any
  ill effects from doing so?

 I don't know the answer to either question without testing.  All I am
 saying is that currently the default for CONFIG_PM is off and you are
 changing it to be on and there may not have been any testing done of
 that in some situations.   We don't know where it was explicitly
 turned off any more since we shrank our defconfig files (which was done
 automatically) ... since it is off by default, it doesn't need to be
 mentioned in a defconfig unless it needs to be turned on.

My suspicion would be that it'll have been turned off by someone hitting
return through a config upgrade rather than through deliberate effort.
On the other hand if it is essential for some machines to have it
disabled they probably want to have somethnig in Kconfig.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM: Hide CONFIG_PM from users

[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 to disabling it and if anything enabling it is the
option that requires special effort.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM: Hide CONFIG_PM from users

[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 be a naive suggestion, but have you considered simply _asking_
 the people who added those defconfigs?

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 - as Geert pointed
out there's a considerable number of defconfigs that have this turned
off.  It seems more sensible to get some idea if this seems sane to
people in the general case before going trying to identify and contact
so many individuals.

If there are systems that really require disabling CONFIG_PM we probably
need to add stuff to Kconfig to make sure it can't be enabled anyway;
this shouldn't enable any new configurations.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM: Hide CONFIG_PM from users

[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 to worry about but I'm not
fundamentally opposed to that, it achieves a similar effect.  The main
thing I'm looking for here is to cut down on the configuration options
we have to maintain.

 However, there's a number of things that I'm afraid wouldn't build correctly
 if none of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME were set in that case.

Actually CONFIG_PM_OPS probably also wants to be on independantly of
those two sometimes for .poweroff() which I'd expect to run even if we
can't suspend.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM: Hide CONFIG_PM from users

[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 emulator to worry about

 Why exactly?

Actually not so much the IA64 emulator (which does have the !PM
dependency declared already - I expect that'd just be moved) as any
other platforms with an undeclared dependency on !PM.

  but I'm not fundamentally opposed to that, it achieves a similar effect.  
  The
  main thing I'm looking for here is to cut down on the configuration options
  we have to maintain.

 But I must say you chose a particularly bad time for that from my point of 
 view.

This doesn't seem like it's a worse time than any other?

   However, there's a number of things that I'm afraid wouldn't build 
   correctly
   if none of CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME were set in that case.

  Actually CONFIG_PM_OPS probably also wants to be on independantly of
  those two sometimes for .poweroff() which I'd expect to run even if we
  can't suspend.

 If you worry about that, then add CONFIG_PM_POWEROFF and make CONFIG_PM(_OPS)
 depend on it, but I don't think it really is worth it, because people
 generally don't make the poweroff code depend on CONFIG_PM.

Yeah, but some people seem very keen on removing the pointers to the PM
ops entirely when CONFIG_PM is disabled which means that you end up with
varying idioms for what you do with the PM ops as stuff gets ifdefed
out.  Then again I'm not sure anything would make those people any
happier.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux Plumbers Embedded microconference

[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 it would be valuable.

I'd certainly be happy to do this, and I imagine Liam would too (he's on
vacation at the minute so it might take him a while to respond).
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [POWER] battery calibration parameters from sysfs

[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 things like the GPE stack
which isn't so actively developed these days.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [POWER] battery calibration parameters from sysfs

[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 userspace, which is especially serious given how
  involved this needs to be in order to be accurate.  

 Well, kernel provides /proc/apm emulation and many systems still rely
 on it. So it would be nice to provide something halfway-decent there.

Unfortunately that's really painful in kernel since you really need to
do state tracking over reboots, and even if you do that it's really
not trivial.

 Plus you need to shutdown/suspend machine on battery critical. That
 has to be in kernel and already needs those tricky parts.

Power failure detection based on voltage drop is much more reasonable
but it's a very different thing to general battery capacity estimation.

Normally you'd want to do the power failure detection separately anyway,
monitoring the system supply voltage rather than the battery voltage.
Supply failure is not only an issue in battery operation, it's also an
issue for example in systems systems powered over USB which may be
drawing more than the 500mA that USB delivers and need to supplement the
USB supply with the battery.

  I'm not sure how familiar you are with the issues surrounding trying to
  do a voltage to charge mapping for a battery but it's much more complex
  than a simple table if you want to get it accurate.  There's a lot
  of

 Well... current zaurus kernels use _huge_ table that maps voltage to
 battery %... and that table is linear function :-(.

 Do you have some papers on that?

Something like Measure Battery Capacity Precisely in Medical Design
by Bernd Krafthoefer in Power Electronics Technology Jan 2005 might be
useful here.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [POWER] battery calibration parameters from sysfs

[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 devices).  This is an issue
  for people producing new devices who are already going to be doing some
  development to get the kernel up and running on their hardware.

 My preference, from an Android point of view, would be to make sure we
 have some reasonable userspace abstraction and provide a default
 implementation that will do the right thing with an intelligent
 battery driver (our usual design for inhouse work).  Then alternative
 implementations can be plugged in, should that not be sufficient.

It proably makes sense to have some of the performance tracking in there
by default - while there are some systems out there which are able to do
high quality battery tracking there's several previous generations of
monitoring technology out there which have substantial accuracy issues
(especially in the face of removable battery packs) but which will
report information to userspace.  This makes it unwise to rely to
totally on the information you're getting from the kernel - the
smartness of a smart battery driver can vary greatly.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [POWER] battery calibration parameters from sysfs

[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 by the power subsystem, i.e. all charge_*,
 energy_*, capacity and time_to_* loose their meaning
 and must be ignored by userspace.

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, energy_ or
capacity attributes.

 Also this was just an example, we have similar calibration
 for the temperature sensor, and thus the temp sysfs file
 also loose its meaning.

Sure, and with temperature sensors tables of design based information
might be more appropriate since it's not possible to gain experimenal
data from the running system in the way we can for batteries.

 Since there is a plethora of userspace apps that just
 interface these files directly (gnome-power-manager and
 the Android stack come to mind) all these will have to
 be patches to accept a calibrated value from somewhere
 else if we shall use them with our hardware.

At least GNOME seems to already be collecting historical statistics on
the battery performance.  I believe it's factoring the results into the
values reported through the UI but I'd need to check.

  Actually, one further thing here - if this functionality
  is implemented in kernel then shouldn't it be a generic
  feature rather than part of the driver?  The idea of

 Surely, we'd be happy to do it that way if desired.
 What about drivers/power/battery_lib.c?

If we're going to do it at all.  Ideally it'd just kick in automatically
when data isn't available so possibly it ought to be core code rather
than a library used by drivers.

 (And getting algorithms in place for gradually
 adjusting the capacity levels as compared to factory
 settings for PC batteries would perhaps end up in the
 same place then.)

I'm still not convinced that it's a good idea to put this into the
kernel.

So far as I can see the main case for doing it in kernel is existing
userspace - is there any other motivation I've overlooked?  Like I say
I'd be somewhat surprised if userspace were relying on this data given
that we're not currently generating it and it's going to need at least
some userspace work to save and restore the data.  There's also policy
issues about how often you do the monitoring and so on.

 We have other odd code. Actually we have full software-
 controlled CC/CV charging in our driver, and that
 would *definately* go in such a library if it was
 to end up in kernelspace. We have actually
 pushed that to userspace, while I still tend to think
 that the kernel (with right parameters) should be able
 to charge a battery. But, well.

As was previously discussed (in another thread) I do think there needs
to be at least some in kernel part to charger code like this in order to
ensure that we're robust against userspace failure and cope well with
suspend and resume.  There's the potential for serious hardware damage
if the battery is mistreated.

 As for the calibration format, after reading up on the
 latest sysfs doc I saw:

There's other kernel filesystems that might be more approprite for this
sort of stuff, trying to fit this into sysfs really does feel like far
too much pain to be right.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [POWER] battery calibration parameters from sysfs

[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, energy_ or capacity attributes.

 Well, yeah, we're not exactly in the laptop business.
 (But my HP laptop nc2400 has the charge_* attributes,
 499 uAh in charge_now and this corresponds to
 what is shown in g-p-m converted over to Wh, but I don't
 know exactly where it's getting it from...)

Looking at what PCs are doing is often a useful guide as to what the
desktop userspace stacks will be trying to use - if you can't get the
information from a Dell or whatever then the chances are they'll cope
fine without it.  Of course, laptop batteries tend to be rather more
fancy in terms of their embedded controllers if nothing else.

 One of the things we're facing is Android, which has
 its userspace in plain Java JNI at the end of this link:
 http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=s
 ervices/jni/com_android_server_BatteryService.cpp;h=8e7cadc6b680fc420d34
 1faa094c71922946fdab;hb=HEAD

Something word wrapped that link but I think I found the same code.

 If you browse down to line 275 you can see it parse the sysfs
 attribute capacity, then this propagates up to the battery
 status indicator on *all* Android phones out there. So if
 you want to run Android unmodified, this is what you need to
 provide. They are effectively using the power sysfs as
 their hardware abstraction layer in this case.

Oh dear.  Using the power sysfs as the hardware abstraction seems
perfectly reasonable but assuming that a given battery driver is going
to have this level of information doesn't match up with an awful lot of
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 userspace, which is especially serious given how
involved this needs to be in order to be accurate.  

I'm not sure how familiar you are with the issues surrounding trying to
do a voltage to charge mapping for a battery but it's much more complex
than a simple table if you want to get it accurate.  There's a lot of
dependence on particular operating conditions and things do change as
the batteries age.  There are systems out there that do the work
required to gather the information in hardware and it's definitely good
to report the information from them but that doesn't mean it's a good
idea to try to synthesise the information for other systems.

We should at least explore the possibility of getting Android to improve
their userspace code rather than put this sort of code into the kernel.
I've CCed Brian in in case he can comment on the possibility of doing
that.

 Note: I'm not claiming that Android is doing it right or that
 we can't modify this code or so, it's just that this is the way
 a few million Android devices out there are actually doing it.

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 devices).  This is an issue
for people producing new devices who are already going to be doing some
development to get the kernel up and running on their hardware.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [POWER] battery calibration parameters from sysfs

[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 number of (x,y) pair tables like this:

 /* Vbat mV to Battery capacity % */
 struct voltage_vs_capacity {
   int voltage;
   int capacity;
 };

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 the performance of the battery will change over time.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [POWER] battery calibration parameters from sysfs

[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 the performance of the battery will change over time.

Actually, one further thing here - if this functionality is implemented
in kernel then shouldn't it be a generic feature rather than part of the
driver?  The idea of mapping battery voltages to capacity percentages
isn't specific to a given charger and will apply to all batteries using
the same technology.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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 ... practical. ;)

 I think you've missed my point and taken it to an illogical extreme to
 counter it.  I agree that PWMs are not GPIOs and visa versa.  However,
 *some* devices are both GPIOs and PWMs.  Also what is needed to manage
 GPIO and PWM pins is pretty much identical.

On most of the ARM SoCs PWM and GPIO aren't particularly special here -
most of the on-SoC functionality is multiplexed onto pins through the
same hardware interface.  A very large proportion of the pins of the SoC
will have muxes to bring out the signals from the internal IP blocks,
and pretty much all of those will have GPIO as one of those functions.

For many SoCs there will be multiple pin options for bringing out each
of the internal signals which complicates matters further.

 But that *isn't* the primary purpose of the GPIO subsystem.  All that
 stuff is layered on top of the GPIO pin management code and doesn't
 really play into this debate.

The GPIO subsystem isn't doing pin management in that way for most
systems, it's just controlling the GPIO functionality and relies on
separate configuration to ensure that the relevant pins are in GPIO
mode.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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.  In the general case PWM and GPIO have nothing
to do with each other.  

 I think pin muxing, and pin controller drivers are different problem
 domains and should be handled separately.

...

 Sorry. when I said pin management I meant how Linux keeps track of pin
 controllers.  Not pin mux.  I should use different terminology perhaps
 to reduce confusion.

I have to confess I'm a bit lost as to what you mean by a pin
controller as opposed to pin mux interface.  For a substantial
proportion of ARMs they're going to be one and the same.

Judging from some of the other messages in the thread I suspect you're
thinking of a much closer mapping between PWM and GPIO pins - many SoCs
do have distinct PWM controllers that aren't terribly tied to a GPIO
pin.  For them the whole concept of requesting a pin or having the PWM
controller be tied to a particular pin is going to be at best confusing,
you really do want to request the PWM controller itself and let the pin
mux setup figure out where that emerges from the SoC.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 100Mbit ethernet performance on embedded devices

[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 course my understanding of NAPI is
  very limited, probably I missed something...

 It would've been nice to get a comment on this.  Yeah I know,
 old kernel, non-mainline driver...

 On this platform NAPI seems to be a win when receiving small packets,
 but not for a single max-bandwidth TCP stream.  The folks at
 stlinux.com seem to be using a dedicated hw timer to delay
 the NAPI poll() calls:
 http://www.stlinux.com/drupal/kernel/network/stmmac-optimizations

 This of course adds some latency to the packet processing,
 however in the single TCP stream case this wouldn't matter.

Does your actual system have any appreciable CPU loading?  If so that
will normally have the same effect as inserting a delay in the RX path.
Some of the numbers will often look worse with NAPI when the system is
lightly loaded (though not normally throughput).
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Representing Embedded Architectures at the Kernel Summit

[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 language for describing the machine.

 OK, so my minimal understanding in this area lead me to believe this was
 because most embedded systems didn't have properly discoverable busses
 and therefore you had to tailor the kernel configuration exactly to the
 devices the system had.

Ish; essentially it's pushing the description of the non-enumerable bits
of the hardware out of kernel code and into a separate bit of data that
can be passed in to the kernel.

 It sounds interesting ... however, it also sounds like an area which
 might not impact the core kernel much ... or am I wrong about that?  The
 topics we're really looking for the Kernel Summit are ones that require
 cross system input and which can't simply be sorted out by organising an
 Embedded mini-summit.

One issue that does have wider impact is that the OpenFirmware bindings
can affect any driver level code - it means that drivers may need to
parse configuration out of the device tree as well as the mechanisms
they normally use.  This is already happening due to the current use but
will become more visible if more platforms adopt the device tree.  As
someone primarily working on driver/subsystem side stuff this is my
primary concern with expanded use of device tree - it's another set of
platform data code that needs writing in addition to the other schemes
currently in use.

On the other hand, if all the embedded architectures got together and
agreeded to move in this direction it'd be pretty much equivalent to
some new BIOS standard being introduced for PCs so perhaps not worth
worrying about at a general kernel level.

 Now if flattened device tree could help us out with BIOS, ACPI, EFI and
 the other myriad boot and identification standards that seem designed to
 hide system information rather than reveal it, then we might be all
 ears ...

Well, you could potentially try to render other BIOS data tables into
device tree format.  I'm not sure that the translation would be less
effort than parsing the existing data, though.
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html