On Mon, Aug 19, 2019 at 2:10 AM Amit Kucheria <amit.kucheria@xxxxxxxxxx> wrote: > > On Sun, Aug 18, 2019 at 12:55 AM Rob Herring <robh@xxxxxxxxxx> wrote: > > > > On Fri, Aug 16, 2019 at 5:02 PM Amit Kucheria <amit.kucheria@xxxxxxxxxx> wrote: > > > > > > On Sat, Aug 17, 2019 at 3:06 AM Rob Herring <robh@xxxxxxxxxx> wrote: > > > > > > > > On Fri, Jul 26, 2019 at 03:48:42AM +0530, Amit Kucheria wrote: > > > > > Define two new required properties to define interrupts and > > > > > interrupt-names for tsens. > > > > > > > > > > Signed-off-by: Amit Kucheria <amit.kucheria@xxxxxxxxxx> > > > > > --- > > > > > Documentation/devicetree/bindings/thermal/qcom-tsens.txt | 5 +++++ > > > > > 1 file changed, 5 insertions(+) > > > > > > > > > > diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt > > > > > index 673cc1831ee9..3d3dd5dc6d36 100644 > > > > > --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt > > > > > +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt > > > > > @@ -22,6 +22,8 @@ Required properties: > > > > > > > > > > - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description. > > > > > - #qcom,sensors: Number of sensors in tsens block > > > > > +- interrupts: Interrupts generated from Always-On subsystem (AOSS) > > > > > +- interrupt-names: The name of the interrupt e.g. "tsens0", "tsens1" > > > > > > > > How many interrupts? A name with just indices isn't too useful. > > > > > > Depending on the version of the tsens IP, there can be 1 (upper/lower > > > threshold), 2 (upper/lower + critical threshold) or 3 (upper/lower + > > > critical + zero degree) interrupts. This patch series only introduces > > > support for a single interrupt (upper/lower). > > > > I would expect a different compatible for each possibility. > > We're currently using the 'qcom,tsens-v1' and 'qcom,tsens-v2' > compatibles to broadly capture the feature (and register map) > differences. > > By defining the following, I should be able to check at runtime (using > platform_get_irq_by_name() as suggested) if a particular interrupt > type is available on the platform, no? So do we really require three > different compatibles? Yes and no. I would assume the SoC specific compatibles would meet this, but the driver can ignore that and just use platform_get_irq_by_name() or count the number of interrupts. > interrupt-names = "uplow", "crit", "cold" > > [1] Respin of older SoC with a newer version of IP > > > > I used the names tsens0, tsens1 to encapsulate the controller instance > > > since some SoCs have 1 controller, others have two. So we'll end up > > > with something like the following in DT: > > > > That's not really how *-names is supposed to work. The name is for > > identifying what is at each index. Or to put it another way, a driver > > should be able to use platform_get_irq_by_name(). So 'critical', > > 'zero' and something for the first one. > > Fair point. I'll rework it to use "uplow", "crit" and "cold" or > something to the effect. > > Is there another way I get the controller instance index in the name > in /proc/interrupts? Not sure offhand. Add the dev_name() into the IRQ name perhaps. Rob
