On Mon, Jun 4, 2012 at 8:40 AM, Martin Peres <martin.peres@xxxxxxx> wrote: > Le 04/06/2012 13:30, Christian König a écrit : >> >> On 04.06.2012 10:44, Lauri Kasanen wrote: >>> >>> So the issue is the location of the info, not the format. I'd be more >>> than happy to split it into six files (default_core_clock, >>> current_core_clock...) that each offer just a kHz number, just like the >>> cpufreq scaling_cur_freq do. Would that be preferable? >> >> Yeah, that sounds like a start, and also only register those files if the >> clock in question is really available, e. g. integrated chipsets doesn't >> have a memory clock for example. >> >> But I have my doubts that it would be accepted easily, cause for debugfs >> we can pretty much pump every information in there we want, while sysfs >> files must maintain a more or less stable API for setting system parameters, >> see Documentation/sysfs-rules.txt. >> >> Christian. > > Hey everyone, > > Now that we talk about this, I think we need a common way to expose clocks > and performance levels across drm drivers. At the moment, Nouveau's sysfs > interface for PM is all but great. I'm sure we can all agree on a common > interface. > > NVIDIA PM is performance-level based (up to 4 + possible overclocking). > IIRC, AMD uses perflvls too (3, low, middle and high). No idea about Intel > but I'm curious about their boost feature. > I also don't know how many reclockable domains you have, but so far, we > reclock 9 domains. > > What we could want to expose: > - 1) Several performance profiles (boot, 0, 1 ,2 ,3 , dynamic, custom) > - 2) Selectable performance profile for battery/sector (arguable) > - 3) Clocks for each performance profile > - 4) Voltage for the performance profile (there may be voltage domains too) > - 5) The custom performance profile should allow the user to set clocks and > voltage > > = Performance profile representation = > > I think that exposing one sysfs per clock per perflvl is insane, at least on > Nouveau (that would result in 63 files). At the moment, we expose some > clocks of a perflvl in one readable single line (c: core 405MHz shader > 810MHz memory 405MHz voltage 900mV) > However, this is kind of against the sysfs rule that sysfs is not a human > interface. We didn't pay attention to it but we'll have to do it soon. > > IMO, we should use one sysfs file per performance profile and then display > clocks as a csv. Each column meaning a different domain. If a domain is not > available on a given card, then the advertised clock should be 0. That > should allow us to add new domains when needed. > > The custom performance level could be constructed in the same way. > > However, I'm not sure about what should be done for voltage. At the moment, > we have only one adjustable voltage domain. It may however change in the > future. The solution may be to have 2 sysfs files per performance profile, > one exposing clocks and one exposing voltages. > > = Setting clocks = > > The user can only select between a few performance profiles: > - the boot clocks > - the performance levels as found in the vbios > - the dynamic profile that switches between the vbios perflvls according to > the load > - the custom profile, for tweakers > > Currently, we allow the user to set 2 performances profiles, one will be > used when on battery and one is used when on sector. If the user sets only > one performance profile, then it is used in both cases. > > Example: Both values are specified in one write: > echo 0,2 > /sys/class/drm/card0/device/performance_level > > = Reading clocks = > > I see 3 important informations we need to export: > - The current performance profile > - The current clocks & voltages > - The settings actually set by the user (battery/sector perflvl) > > = Anything else ? = > > What do you think? Did I forgot anything? How would this idea map to your > hardware/drivers? > > Martin > I don't think sysfs is the way to go, i am pretty sure that power management will change drasticly again in the future especialy btw discret and integrated GPU. I would rather have hardware specific ioctl. Cheers, Jerome _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
