On 7/14/23 13:21, Rodrigo Vivi wrote: [ ... ]
Hi Guenter, First of all sorry for jumping late here. I'm totally with you here and we should definitely only use the new API. For standard entries that will definitely reduce the code size. So, since we are talking about reducing code here, and looking to other DRM drivers, and thinking about the needs on this new Xe driver, I'm wondering if you would consider accepting 'frequency' as a standard hwmon attribute. We would need it to be RW so we could use to put freq requests as well, and possibly different types/domains and even throttle reasons on top. So we could then try to unify all the drm drivers in a common drm-hwmon layer putting an end in all abuses and deprecated users. But before moving fwd with any proposal I'd like to hear your thoughts on this 'frequency' block as standard attribute.
I really don't see how this would fit under "hardware monitoring". Making it writable would be even worse - this is most definitely not a limit but an actual value. The notion of limit actually shows that it is not a good fit as a monitoring attribute: I can not conceive the notion of a "maximum" or "minimum" frequency limit, or an "under" or "over" frequency. If this is about thermal control/management, you might want to consider registering with devfreq and the thermal subsystem (see devfreq_cooling_register() and friends for reference). Thanks, Guenter
