Re: Handling of modular boards
On Tue, May 08, 2012 at 02:26:54PM +0200, Linus Walleij wrote: > On Fri, May 4, 2012 at 9:34 PM, Arnd Bergmann 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
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: Handling of modular boards
On Fri, May 04, 2012 at 11:55:14PM +0100, Russell King - ARM Linux wrote: > On Fri, May 04, 2012 at 07:58:51PM +0100, Mark Brown wrote: > > I'm just starting to put some stuff together for this so I was wondering > > if anyone had been thinking about this and had any bright ideas for how > > to handle it, and also if people think that MFD is a good fit for this > > or if we should split the silicon MFDs from these PCBs. > I don't think its true to say that there's no support for this kind of > thing. > If you're thinking about a motherboard with separate add-on cards, then > you can view the cards as their own separate platform device. Your > platform device driver would be a "whole board driver" responsible > for creating and registering the specific devices found on the board > in its probe function, and unregistering them in the remove function. Oh, absolutely - there's support there at that level and several boards doing some or all of this in mainline already. It's not that you can't do it, it's that there's a bunch of generic stuff to do with how you map the resources through to the devices on the modules and describe the chips that are on the modules for which there's no infrastructure so everything needs to be hand coded on a per board basis. The board identification bits are board specific but the remapping and subdevice instantiation bits seem like they shouldn't be. > It also helps to give the right model to the power management support, > because you're automatically arranging the child devices below the > board-level device, which means all the child devices should be > suspended before the board level device, and the board level device > should be resumed before the child devices. Yes, I'd anticipate that we'd have a device for the board which should help with this sort of stuff. signature.asc Description: Digital signature
Re: Handling of modular boards
On Fri, May 04, 2012 at 10:33:57PM +0200, Wolfgang Denk wrote: > On the other hand, some of the issues we're trying to solve here > for the kernel are also present in the boot loader, so this needs to > do this anyway - whether by inserting new or modifying (enabling or > disabling) existing properties in the DT is not really relevant here. FWIW if the bootloader can usefully handle this stuff I think that's a good approach but there is substantial variation in quality of implementation between bootloaders and even when the bootloader is a good one it's not always practical to update it or the data it relies on. signature.asc Description: Digital signature
Re: Handling of modular boards
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
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
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
Handling of modular boards
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, generally this seems to be done in arch code for the machine but this doesn't scale when even the CPU might change and isn't terribly device tree compatible either. For reference the code for current Wolfson plugin modules is in arch/arm/mach-s3c64xx/mach-crag6410-module.c. The most obvious current fit here is the MFD subsystem but it feels like we need some slightly different infastructure to what MFD currently provides. MFD is really set up to handle platform devices with a core and linear ranges of resources fanning out from that core since they're really oriented around chips. In contrast these boards are more about remapping random collections of potentially unrelated resources and instantiating devices on all sorts of buses and share more with board files. I'm just starting to put some stuff together for this so I was wondering if anyone had been thinking about this and had any bright ideas for how to handle it, and also if people think that MFD is a good fit for this or if we should split the silicon MFDs from these PCBs. signature.asc Description: Digital signature
Re: A new Subsystem for Current Management
On Thu, Nov 10, 2011 at 04:58:27PM +0530, R, Durgadoss wrote: > > > 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. > These (limits) are configurable voltage limits. The HW generates an > Interrupt when any of these configured voltage limits are crossed. > Similarly, for Current also. > Now, Say there are 3 current limits that we can program. > On the first and second limit violation we take some actions, > and control the current consumption, so that it does not hit the > worst current limit. So what you mean is that these are maxima. I'm not sure that the voltage limits are terribly useful on regulated supplies; the voltages tend not to be varied autonomously by hardware and even where they are they're not directly tied to power consumption which is usually the actual problem. On unregulated supplies like the battery output it's more useful and it's something that the existing power framework already has some support for reporting current flows, my first guess would be that for the unregulated supplies you'd build on top of that (and there will be overlap with the charger management for the devices that need hand holding to do that). Current limits are more generally useful, they apply equally well to regulated and unregulated supplies. You probably want to tie this stuff in with the thermal management work that people are starting to look at - it sounds like you're basically trying to look at a different aspect of the same problem. > Do you think, we can fit this into the regulator framework ? That's not something that the hardware generally supports; for voltages you'll usually just get an out of regulation notification and current limits generally just give you a single trip point. > But I would like to see a 'consumer' driver that uses the framework > efficiently, so that I can get some more idea. Could you point to > some source files ? find linux-2.6 -type f | xargs grep -l regulator_ should show a bunch of devices, nothing actually using any form of limiting at the minute though. Any regulator driver which notifies will be able to show when it goes out of regulation. -- 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: A new Subsystem for Current Management
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: Expose regulator:set_consumer_device_supply()?
On Tue, Apr 26, 2011 at 10:33:29AM -0500, Bill Gatliff wrote: > On Tue, Apr 26, 2011 at 3:33 AM, Mark Brown > wrote: > > You can specify the device by either dev_name() or a dev pointer. You > > can use dev_name() at any time without the device having been > > instantiated, it would be unusal to use a struct device. > When a consumer e.g. i2c chip driver is trying to get a handle for its > own regulator, the only function I see is: > > struct regulator* regulator_get(struct device *dev, const char *id) There's also regulator_get_exclusive() but it's almost exactly the same thing. > In order for there to be a regulator with a matching device:id > combination, someone must have previously provided a struct > regulator_consumer_supply with the identical device pointer to > regulator_register(). That means that I have to call > regulator_register() AFTER I register the i2c chip driver, so that I > have a struct device pointer to place in the regulator_consumer_supply > list. Right? No. As I said in the text you've quoted above you can also specify the device mapping using the dev_name() of the device. As you will have seen when looking through the regulator_get() implementation the matching is actually done on the dev_name(), if the mapping is set up with a struct device we always do matches based on the dev_name() string, not by comparing pointers. > > This would facilitate abuse of the API, we already have enough problems > > with people trying to pass regulators as platform data. > But I think you'll agree that regulators are pretty important platform data, > no? No, the set of power supplies the device has is not platform data, it's a physical property of the device. > What specifically is the breakage that comes from allowing consumers > to add themselves to regulator consumer lists at a time after > regulator_register() is complete? Why is passing a regulator pointer > as platform data such a problem? It means you get reams of code in drivers conditionally using the regulator API, all of which adds needless complexity all over the tree as people invariably make everything conditional on the regulator not being there when they shouldn't. This then means you also end up with no meaningful error handling, all errors just get silently eaten. -- 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: Expose regulator:set_consumer_device_supply()?
On Mon, Apr 25, 2011 at 09:25:22PM -0500, Bill Gatliff wrote: > This would also imply the ability to register a regulator with no > consumers listed, as they would be added later when i2c, etc. devices > were registered. This is already possible, not all consumers are visible to software anyway. -- 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: Expose regulator:set_consumer_device_supply()?
On Mon, Apr 25, 2011 at 09:16:55PM -0500, Bill Gatliff wrote:
> Guys:
Please always:
- CC maintainers on mails (in this case myself and Liam).
- CC the relevant list (in this case linux-kernel).
> In a nutshell, I have a lot of i2c chips, each of which is powered by
> its own voltage regulator. Among other things, I'm trying to write
> the i2c drivers so that they are as platform-agnostic as possible,
> because I intend for these drivers to be reused on future platforms
> with different voltage regulator layouts. On future platforms
> regulators might be shared with multiple i2c chips, for example.
OK, this is absolutely normal for the regulator API.
> What I'm hoping for is i2c driver code that asks for a regulator based
> on the name of the pin to which the regulator is connected. So
> instead of doing this:
> ... I can do this:
>
> i2c_chip_probe(i2c_client *this, ...)
> {
> ...
>/* ask for the regulator connected to our VDD pin */
>reg = regulator_get(this, "VDD");
> ...
> }
This is exactly what you're supposed to do with the regulator API now.
If you're not doing that the consumer driver is buggy and should be
fixed, it should be written without reference to the board it is running
on.
> The problem with i2c devices is that if you register them with
> i2c_register_board_info(), you don't have a device pointer that you
> can associate a regulator with. So you have to register the regulator
> after the i2c chip gets registered, which means doing it in the i2c
> chip's probe method. Ugly, and it won't work when regulators are
> shared between devices.
You can specify the device by either dev_name() or a dev pointer. You
can use dev_name() at any time without the device having been
instantiated, it would be unusal to use a struct device.
> Any reason why we couldn't expose set_consumer_device_supply(), so
> that I can add a device as a regulator consumer after a regulator is
> already registered?
This would facilitate abuse of the API, we already have enough problems
with people trying to pass regulators as platform data.
--
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
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
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
On Fri, Feb 25, 2011 at 08:46:24PM -0600, Bill Gatliff wrote: > On Mon, Feb 21, 2011 at 10:33 PM, Mark Brown > 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
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] input: evdev: Add a read() callback
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] Remove CONFIG_PM altogether, enable power management all the time
On Wed, Feb 09, 2011 at 03:09:42PM -0500, Alan Stern wrote: > On Wed, 9 Feb 2011, Mark Brown wrote: > > 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. > Or to put it another way, if you enable any of CONFIG_PM_SUSPEND, > CONFIG_PM_HIBERNATION, or CONFIG_PM_RUNTIME, then CONFIG_PM will > automatically be turned on. Otherwise it will automatically be turned > off. Plus everything controlled by the old CONFIG_PM_OPS is now controlled directly by CONFIG_PM. -- 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
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] Remove CONFIG_PM altogether, enable power management all the time
On Wed, Feb 09, 2011 at 11:00:17AM -0800, Frank Rowand wrote: > and my understanding of this proposal was a goal to remove the ability > to have CONFIG_PM disabled, which results in increased memory usage > for some configurations. 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. This comes from the fact that the options exposed and the use of them doesn't really reflect the kernel power management infrastructure any more. The PM options at Kconfig level are really SUSPEND, HIBERNATION and PM_RUNTIME but for historical reasons the idoms are all based on the root PM option. This gets fiddly and confusing as you move over build coverage. -- 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
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
On Wed, Feb 09, 2011 at 11:41:37AM +, Mark Brown wrote: > 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. OK, on ARM with slightly more than an allnoconfig (allnoconfig itself wouldn't build) I see: textdata bss dec hex filename 1361476 71360 167320 1600156 186a9c vmlinux.nopm 1364228 71520 167480 1603228 18769c vmlinux 2752 160 1603072 so 3K from CONFIG_PM there, mostly from the ARM VIC management code which I suspect really wants to be under one of the more specific PM options, though obviously this comes back to the issue with bitrotted ifdefs for PM whcih pervades the 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] Remove CONFIG_PM altogether, enable power management all the time
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] PM: Hide CONFIG_PM from users
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
On Mon, Feb 07, 2011 at 10:15:59PM +0100, Rafael J. Wysocki wrote: > I really think we should do things that makes sense rather that worry about > who's going to like or dislike it (except for Linus maybe, but he tends to > like > things that make sense anyway). At this point I think the change I suggested > makes sense, because it (a) simplifies things and (b) follows the quite common > practice which is to make PM callbacks depend on CONFIG_PM. So, part of the issue here is that it's not clear if having the ifdefs in the drivers is really something that makes sense. It's not at all clear that anyone is actually making active use of them on real systems rather than just doing build coverage testing, it really feels like the ifdefs that people are currently using are just being cargo culted around. The reason it's come up for me is that dev_pm_ops changes things a bit as you've got to decide how to handle the struct itself and there's no clear decision on what the best way forward for that is (is it OK to leave the struct if it's empty?) so you end up with the approach you need to take varying between maintainers which is annoying. > I'd appreciate it if people could review/test it and drop their comments. Looks good to me: Reviewed/Tested-by: Mark Brown -- 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
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
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: [PATCH] PM: Hide CONFIG_PM from users
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
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
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
On Tue, Feb 08, 2011 at 01:44:32AM +1100, Stephen Rothwell wrote: > On Mon, 7 Feb 2011 14:18:29 +0000 Mark Brown > 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
On Tue, Feb 08, 2011 at 01:13:24AM +1100, Stephen Rothwell wrote: > On Mon, 7 Feb 2011 12:22:15 +0000 Mark Brown > wrote: > > + bool > > + default y if !IA64_HP_SIM > Several powerpc configs have CONFIG_PM (implicitly) disabled (e.g. the > server configs), so this will unexpectedly turn it on for them. 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? -- 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
On Mon, Feb 07, 2011 at 01:40:28PM +0100, Geert Uytterhoeven wrote: > Which means that (for now) I don't have to care that CONFIG_PM becomes > unclearable. Other people may care, though... The whole point of the patch is that (other than the IA64 emulator which explicitly requires that CONFIG_PM be disabled) I strongly suspect that nobody is actually using this configuration except as a result of randconfig type testing. -- 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
On Mon, Feb 07, 2011 at 01:48:46PM +0100, Ingo Molnar wrote: > * 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. > 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
[PATCH] PM: Hide CONFIG_PM from users
It is very rare to find a current system which is both sufficiently resource constrained to want to compile out power management support and sufficiently power insensitive to be able to tolerate doing so. 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. Begin doing so by hiding it from users - this should attract complaints from any active users. The option is left disabled for the IA64 Ski simulator which is a partial simulator for IA64 systems mostly 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 --- kernel/power/Kconfig | 21 ++--- 1 files changed, 2 insertions(+), 19 deletions(-) diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig index 2657299..99e3c52 100644 --- a/kernel/power/Kconfig +++ b/kernel/power/Kconfig @@ -1,23 +1,6 @@ config PM - bool "Power Management support" - depends on !IA64_HP_SIM - ---help--- - "Power Management" means that parts of your computer are shut - off or put into a power conserving "sleep" mode if they are not - being used. There are two competing standards for doing this: APM - and ACPI. If you want to use either one, say Y here and then also - to the requisite support below. - - Power Management is most important for battery powered laptop - computers; if you have a laptop, check out the Linux Laptop home - page on the WWW at <http://www.linux-on-laptops.com/> or - Tuxmobil - Linux on Mobile Computers at <http://www.tuxmobil.org/> - and the Battery Powered Linux mini-HOWTO, available from - <http://www.tldp.org/docs.html#howto>. - - Note that, even if you say N here, Linux on the x86 architecture - will issue the hlt instruction if nothing is to be done, thereby - sending the processor to sleep and saving power. + bool + default y if !IA64_HP_SIM config PM_DEBUG bool "Power Management Debug Support" -- 1.7.2.3 -- 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
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
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. > Both Opie and GPE have the problem IIRC... Yeah, if you're working on older systems like that you'll probably have to do some userspace work as well as kernel work. -- 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
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
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
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
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
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
On Sat, Dec 05, 2009 at 02:08:11PM +0100, Linus Walleij wrote: > [Mark Brown] > > [Linus Walleij] > > 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. I'd not expect them to be there at all in this case - certainly existing drivers aren't reporting all these properties, even for relatively smart batteries with embedded controllers like those in laptops. For example, the laptop I'm typing this on only reports charge, current and voltage properties and doesn't have capacity, enegy or time to information. > 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, there's an awful lot of performance information that isn't available from hardware and has to be interpolated. > 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. I was under the impression that at least GNOME was already working on doing this themselves, based on data gathered at runtime rather than pre-provided data tables, but I'm not turning anything up right now so I might be imagining things. If a userspace implementation is done right I'd expect that it'd be possible to share the heavy lifting between the various applications, and even with an in-kernel implementaiton we'll need userspace to know to save and restore any data that needs to persist over reboots. > But as you say: > > 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. > Surely, we'd be happy to do it that way if desired. > What about drivers/power/battery_lib.c? I guess. Probably if it's going to be in the kernel ought to just be part of the power core and kick in automatically if properties it can estimate aren't supplied by the driver. > (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 entirely seeing why this needs to be in the kernel. It sounds like the main push here is to fit in with existing applications but given that these properties aren't reliably available at on current systems I'd be a bit surprised if applications were relying on this interface already. Are there reasons for doing things this way other than existing applications? > As for the calibration format, after reading up on the > latest sysfs doc I saw: ... > This is close to that, an array of two types (x,y)(x,y) > voltage,capacity,voltage,capacity etc. Pushing them in > two files > /sys/.../v_vs_cap_v > /sys/.../v_vs_cap_cap > and then make sure we write as many values to each array > is uglier IMHO. TBH I don't think there's going to be a nice way of doing this via sysfs. I'm not sure if one of the other filesystems such as configfs might be a bit more suitable for this application. The difficulty in defining an ABI is another thing that makes it seem like doing this in the kernel is the wrong approach. -- 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
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: [POWER] battery calibration parameters from sysfs
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: [PATCH 0/6] Generic PWM API implementation
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: [PATCH 0/6] Generic PWM API implementation
On Fri, Nov 20, 2009 at 03:21:31PM -0700, Grant Likely wrote: > On Tue, Nov 17, 2009 at 1:27 AM, David Brownell 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: 100Mbit ethernet performance on embedded devices
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
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
