[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53B56588.6090703@nvidia.com>
Date: Thu, 3 Jul 2014 17:15:36 +0300
From: Mikko Perttunen <mperttunen@...dia.com>
To: Stephen Warren <swarren@...dotorg.org>,
"rui.zhang@...el.com" <rui.zhang@...el.com>,
"edubezval@...il.com" <edubezval@...il.com>,
"thierry.reding@...il.com" <thierry.reding@...il.com>,
Peter De Schrijver <pdeschrijver@...dia.com>,
Matthew Longnecker <MLongnecker@...dia.com>
CC: "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 1/6] thermal: of: Add support for hardware-tracked trip
points
On 01/07/14 21:15, Stephen Warren wrote:
>> The thermal core only supports a fixed number of trip points for each
>> driver and the core informs the driver of any changes to those, so
>> drivers using the core framework can already have hardware trip points,
>> but just a fixed number of them.
>>
>> The way of-thermal works, is it reads all the trip points from the
>> device tree, registers a new thermal_zone_device with that number of
>> trip points and then handles the trip points completely independently.
>> Of course, if we're just polling, this is fine, since the thermal core
>> also knows about those trip points and will trigger cooling when polling
>> the each zone. However, the driver doesn't, so it cannot setup any
>> interrupts to call thermal_zone_device_update.
>
> Is there any possibility of cleaning that up? It's obviously horribly
> inconsistent if core driver functionality works completely differently
> simply because the list of trip-points comes from DT rather than a
> static table in the driver. of_thermal should be limited to DT parsing
> and related device instantiation/lookup, not introducing a completely
> different functionality model.
I guess the smallest possible change would be to add a
#hardware-trip-cells property to the thermal driver node (this would
need to designate both the thermal zone and the trip point) and a
hardware-trip-point phandle node to trip points. Then trip points could
point to a hardware trip point that would get programmed. Since this is
just adding properties, it would be backwards-compatible as well.
This is starting to sound like a good idea. Will have to give think
about it some more.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists