Messages in this thread | ![/](/images/icornerl.gif) | | Date | Sat, 29 May 2004 12:10:59 +0400 | From | Andrew Zabolotny <> | Subject | Re: two patches - request for comments |
| |
On Fri, 28 May 2004 14:59:53 -0700 Todd Poynor <tpoynor@mvista.com> wrote:
> Hi, you're adding new interfaces for power management of LCD and > backlight devices. Since there's already LDM/sysfs interfaces for > reading and writing power state of generic devices, is it necessary to > add ones particular to these devices or device classes? In other words, > is /sys/devices/<bus>/<device>/power/state not suitable for these purposes? Well, first liquid crystal displays and backlight are not connected to any specific bus. They could, on some platforms, and could not on other. For example, on some PDAs backlight is controlled via the programmed I/O CPU pins (GPIO), on other they are connected to some weird companion chips, on third they could be controlled via the PCI bus (on large PCs, I mean) and so on. So there will be no easy way for an application to find the backlight devices and control them. In our case that's easy: opendir ("/sys/class/backlight") and you found all of them.
On the other hand, the lcd and backlight modules will be used by the framebuffer device, which in most cases will be itself on a certain bus. And when the framebuffer device will be powered off, it contacts the corresponding lcd and backlight devices to power them off as well.
On the third hand (:-) the lcd device class, for example, actually has *two* power switches: the 'power' and the 'enable' attribute. The first powers off the liquid crystal display, and seconds powers off the lcd controller. These are different things and it would be wise to leave them apart, as having finer grained control is always better. Also they have attributes that are in no way part of power management: contrast, brightness etc. So these attributes would have to be spreaded out across the entire sysfs.
On the fourth hand (oh no), what would be the code sequence for a framebuffer device to find the corresponding lcd and backlight devices? For now that's done by searching the 'backlight' and 'lcd' device classes for a device with the same name as the framebuffer device; if we place every device on its own bus, the framebuffer device will have to search all the buses in the system. Not speaking that the code will be substantially larger (current code is already 2-3k for each class, which is alot if we're speaking of embedded systems).
> And if a PM interface for device classes is needed that ties into the > device driver suspend/resume callbacks, perhaps it can be modeled more > closely on the existing interfaces? These new interfaces seem to be > intended to define: 0 == power off, 1 == power on. The existing > ACPI-inspired interfaces use: 0 == power on/full-power, 1/2/3/4 == > low-power/off state. Um, well, this could be implemented. Although I don't see much reason for a backlight to be in a "semi-enabled state"; besides if it will remain a separate class device, it doesn't matter much. But if someone cares, it could be changed now since there is not much code which depends on that.
> New files don't have GPL license comments. Indeed, I forgot to add them. Initially they weren't designed to be compiled as modules.
-- Greetings, Andrew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |