"Jon Medhurst (Tixy)" <tixy@xxxxxxxxxx> writes: > On Mon, 2015-09-14 at 15:38 +0100, Punit Agrawal wrote: >> Mark Rutland <mark.rutland@xxxxxxx> writes: >> >> >> >> +Sensor bindings for the sensors based on SCPI Message Protocol >> >> >> +-------------------------------------------------------------- >> >> >> +SCPI provides an API to access the various sensors on the SoC. >> >> >> + >> >> >> +Required properties: >> >> >> +- compatible : should be "arm,scpi-sensors". >> >> >> +- #thermal-sensor-cells: should be set to 1. This property follows the >> >> >> + thermal device tree bindings[2]. >> >> > >> >> > You need to specify what the valid values for this cell are. >> >> >> >> The enumeration depends on the number of sensors exported by SCP >> >> firmware - which is platform dependent. I could add add something like >> >> if you think that is helpful - >> >> >> >> "Valid cell value is a number between 0..n-1, where n is the number >> >> of sensors exported by SCP firmware." >> > >> > Can the FW identifer space have holes? Or are they always contiguous? >> >> The way the SCP interface is defined, the sensor identifiers are >> contiguous, > > Is there any documentation other than DUI0922A? [1] From what I can seen > that just says it's a 16-bit value and doesn't put any particular > constraints on its value. Although not explicitly stated, if you look at the Get Sensor Capability [2] and Get Sensor Info [3] commands you can indirectly infer that the Sensor IDs are contiguous. Not the strongest guarantee I know. All platforms currently using SCP (Juno R0 and R1) do indeed expose contiguous identifiers. Maybe we can convince the authors to make it explicit. > > [1] http://community.arm.com/servlet/JiveServlet/download/8401-40-18262/DUI0922A_scp_message_interface.pdf [2] http://arminfo.emea.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/ch03s02s21.html [3] http://arminfo.emea.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/BABCCCJJ.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
