David Brownell wrote: > On Tuesday 25 July 2006 3:09 am, Amit Kucheria wrote: > >> On Mon, 2006-07-24 at 17:32 -0700, ext David Brownell wrote: >> >>> On Monday 24 July 2006 2:58 pm, Preece Scott-PREECE wrote: >>> >>>> If they're defined dynamically, you can change them without recompiling >>>> the system, building a new rootfs image, etc. This is especially useful >>>> during development and tuning of systems built on new hardware, since >>>> the set of Ops available (that is, that are documented by the chip >>>> vendor to work) can vary over time and even board-to-board. >>>> >>> I could easily buy such a mechanism being dependent on EXPERIMENTAL, >>> for use with developer/prototype boards ... thanks for that scenario. >>> >>> But I have a harder time seeing it used in production systems, burnt >>> into flash on a manufacturing line that already had to qualify that >>> new hardware before the next production run (of say 10,000 units) was >>> approved by the powers-that-be. >>> >>> - Dave >>> >> Sometimes a certain operating point is not desired for regular operation >> of the device. So it would not be in the board-xx.c file. >> >> But connect a peripheral and suddenly this is the most attractive OP for >> the system. >> > > And you'd know that in advance, and thus could predefine that OP. :) > > Even in the worst case, where you somehow add a driver without > upgrading the rest of the kernel in flash, that driver should be > able to define an OP without userspace. (I suppose there are some > product vendors willing to do that type of field upgrade.) > > I'm still not persuaded that a UI for OP creation is needed except > for development. Feel free to keep trying to persuade me though; > I'm just pushing back on what I see as weak points, since that's > the best way I know to come up with good solutions. > I'd like to highlight the only thing that PowerOP sysfs layer provides two interfaces for operating points creation - one is UI and another is powerop_register_point/select_point() and the latter is intended to be utilized by a kernel entity. (Btw, please note that select routine receives 'name' argument) This may be up to a system designer to define which interface to use therefore I see it as an advantage of PowerOP rather than as a weak point. Since UI part seems most painful one I can think of additional splitting of PowerOP sysfs layer into two parts. First would be powerop_register/unregister_point(), powerop_select_point() and another one would be UI sysfs part. And the latter would be optional. Thanks, Eugeny > - Dave > > > >> So the ability to add operating points from userspace might >> be helpful there. >> >> Regards, >> Amit >> >> >>>>> I meant "they could suggest how to do the sysfs thing, in reasonable >>>>> way". Like echo new_config > file is extermely ugly, but perhaps >>>>> configfs is suitable? >>>>> >>>> Makes some sense. But I'm still puzzled why _creating_ an operating >>>> point would be done outside of the arch/.../board-xx.c file. >>>> >>> _______________________________________________ >>> linux-pm mailing list >>> linux-pm at lists.osdl.org >>> https://lists.osdl.org/mailman/listinfo/linux-pm >>> >> -- >> Amit Kucheria <amit.kucheria at nokia.com> >> Nokia >> _______________________________________________ >> linux-pm mailing list >> linux-pm at lists.osdl.org >> https://lists.osdl.org/mailman/listinfo/linux-pm >> >> > _______________________________________________ > linux-pm mailing list > linux-pm at lists.osdl.org > https://lists.osdl.org/mailman/listinfo/linux-pm > >
