Apologies for the very late response. > My initial reaction is why can't we come up with a good > abstraction that would work for the product families? I think > its ok for a pm-qos option to exist but not be used on every > architecture. Main buses and peripheral buses are possible abstractions. However, using our shipped devices as a guide, the number of each type of buses can vary. The number of main buses can go from 1 to 2 or more. (For example, there can be different types of memory in a single device and each type of memory sits on a separate main bus.) The number of peripheral buses can go from 1 to 3 or 4 or more. There are also a great deal of variations on what hardware blocks are connected on what buses. The interconnection of CPU, memories, DSP engines, peripheral hardware through the various buses change from device to device, making practical classification/abstraction of the buses difficult. >From a system point of view on power, controlling the bus freq is also related to controlling freq of various PLLs, clocks, hw clocks. Because many of them are used by multiple hardware clients and drivers, they appear to be good candidates for pm_qos as well. Unfortunately for these hw entities, the number and the types of hardware instances vary even more across devices. One may think that the system/hardware designers have gone overboard with all the complexities. Perhaps they have. But one major advantage of the compartmentalization and multi-levels is that unused or under-used entities can be turned off or turned down, saving more power. Some of our devices on the market do not run Linux. Some others run Linux but only use pm_qos in a limited fashion, for example, CPU_DMA_LATENCY. We hope to collaborate with the community to extend pm_qos, enabling power control in a better, smarter way. Abstraction is more preferable. Good abstractions that make sense across a wide variety of architectures and platforms, i.e. x86, arm, powerpc, however require lots of knowledge and insights. With limited participation and inputs from arch/platform folks, the top-down approach seems problematic. Adding platform-specific parameters enables a bottom-up approach, where archs/platforms can first come up with parameters that are relevant to their targets. As more people uses pm_qos and various parameters gets incorporated, it can become easier to spot common ones and to make them platform independent. Given Linux's distributed development style, the bottom-up approach may work better. > > I haven't seen much discussion recently on platform specific > > pm_qos_params. Are people still open to the idea? I also > would like > > to help working on it. > > I worry that this is the road to hell. > > If the platform specific pm-qos parameter is accessed by any > platform independent driver code then its a big failure and > leads to code that will give me a rash to look at. Not sure that it is a big failure. The guarantee from pm_qos framework has always been best-effort. If a specific QoS parameter does not exist, the caller can see that from an error return code during add_request and compensate in some fashion. Or, pm_qos framework can return a "no-op" pm_qos handle. The handle can be a singleton handle that does nothing with the update requests. In other words, drivers and other code can always request a QoS value, but there is no guarantee that anything will be done to honor it unless a platform actively provide back-end support for the QoS parameter. I think the behavior would be consistent with that of the existing pm_qos framework; on arch/platforms where no code has registered with the pm_qos notifier chain or used pm_qos_requirement, the QoS values are not acted upon. > > So one requirement for platform specific pm-qos parameters I > have is that such parameters shall only be accessible from > platform specific code and not from any platform independent > stuff. (I don't think this is possible in C, so I'll need more > convincing to not block this idea.) > > I welcome help coming up with good pm-qos abstractions for the > multiple bus bandwidth problem above. Having a nice discussion > about the problem space would be good start, then we can propose > some possible abstractions and prototype some implementations. > > It also is important to provide some application specific > motivation as to why the buses you are calling out can not self > throttle without causing issues. I once had a graphics bus > example in mind but I've been told that graphics drivers have > the data needed to do effective throttling and they already do > so. Therefore I shouldn't bother with such parameters. > > I don't know if I believe that but I don't feel like arguing > with graphics experts too much on the matter without a specific > application where the need for such a parameter could be used. > i.e. I need a graphics driver author or graphics Si vendor to > step up and tell us they could do a lot better with power if a > pm-qos parameter for graphics bus bandwidth existed. > > So do you see my issue? I understand. Using our shipped devices as an example, graphics hardware shares the bus with other hardware blocks. The freq/bandwidth of the bus can be adjusted to accommodate needs from all the hardware blocks. When the bus is running out of bandwidth at its current freq to satisfy the graphics hardware, the graphics driver can throttle its need. Alternatively the driver can pre-request its QoS so that the bus freq is fast enough for the graphics hardware. Looking at it from an opposite direction, if there is no QoS request on the bus, the bus driver can lower the bus freq to save power, knowing that it is not ruining any graphics performance. I'm not suggesting we add a graphics bus QoS, just to convey that QoS parameters are useful on shared entities, like buses, clocks, etc. > > I hope I'm not scaring you off. I want to do more with pm-qos > but it takes collaboration to make it happen. Today, I feel > adding platform specific PM-QOS would put off solving the > problems by enabling device specific parameters that would be > forever out of tree and delay the collaboration needed to move > forward. > > --mgross I'm hoping platform specific pm_qos will encourage collaboration on multiple levels: core folks, arch folks, platform folks, device folks, etc. At first, various new parameters may show up in arch trees, platform trees, or device trees. But as common QoS parameters are found, they can be migrated to the main tree. The idea of QoS aggregation in pm_qos is very powerful. IMO, it would be beneficial to apply it not only to platform-independent QoS but also to platform-specific QoS. ~Ai _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
