On Tue, Jul 2, 2024 at 6:31 PM Daniel Lezcano <daniel.lezcano@xxxxxxxxxx> wrote: > > On 02/07/2024 13:03, Rafael J. Wysocki wrote: > > [ ... ] > > >>> Trips cannot be created on the fly ATM. > >>> > >>> What can be done is to create trips that are invalid to start with and > >>> then set their temperature via sysfs. This has been done already for > >>> quite a while AFAICS. > >> > >> Yes, I remember that. > >> > >> I would like to avoid introducing more weirdness in the thermal > >> framework which deserve a clear ABI. > >> > >> What is missing to create new trip points on the fly ? > > > > A different data structure to store them (essentially, a list instead > > of an array). > > > > I doubt it's worth the hassle. > > > > What's wrong with the current approach mentioned above? It will need > > to be supported going forward anyway. > > So when the "user trip point" option will be set, a thermal zone will > have ~ten(?) user trip points initialized to an invalid temperature ? If a thermal zone is registered with 10 invalid trip points, htat can happen already today. Let's talk about the usage model, though. IIUC, this would be something like "triggers" I mentioned before: If a certain temperature level is reached, a notification is sent to user space, and there are multiple (possibly many) levels like this. They can be added and deleted at any time. There can be an interface for this, as simple as a pair of sysfs attributes under a thermal zone: add_trigger and remove_trigger. If root (or equivalent) writes a (valid) temperature value to add_trigger, a new trigger is added (up to a limit and provided that enough memory can be allocated). Conversely, if a temperature value is written to remove_trigger and there is a trigger with that temperature, it will be deleted. Internally, the triggers can be stored in a sorted list (with some optimizations, so it need not be walked every time the zone temperature changes) or a tree, independent of the trips table (if any). Every time the zone temperature changes, the triggers list is consulted (in addition to the trips table) and if any of them have been crossed, notifications are sent to user space. If polling is used, this would just work, but without polling the driver needs to support setting a pair (at least) of temperature levels causing an interrupt to occur. If a specific callback, say .set_triggers(), is provided by the driver, it can be used for setting those temperature levels to the triggers right above and right below the current zone temperature, in analogy with .set_trips(). Does this reflect what you are after?
