From: "Jon Medhurst (Tixy)" <tixy@linaro.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Punit Agrawal <Punit.Agrawal@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Liviu Dudau <Liviu.Dudau@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
"edubezval@gmail.com" <edubezval@gmail.com>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"linux@roeck-us.net" <linux@roeck-us.net>,
Sudeep Holla <Sudeep.Holla@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 1/5] Documentation: add DT bindings for ARM SCPI sensors
Date: Tue, 15 Sep 2015 12:37:22 +0100 [thread overview]
Message-ID: <1442317042.2917.29.camel@linaro.org> (raw)
In-Reply-To: <20150915110330.GA6507@leverpostej>
On Tue, 2015-09-15 at 12:03 +0100, Mark Rutland wrote:
> On Tue, Sep 15, 2015 at 11:46:02AM +0100, Jon Medhurst (Tixy) wrote:
> > On Tue, 2015-09-15 at 10:37 +0100, Punit Agrawal wrote:
> > > "Jon Medhurst (Tixy)" <tixy@linaro.org> writes:
> > >
> > > > On Mon, 2015-09-14 at 15:38 +0100, Punit Agrawal wrote:
> > > >> Mark Rutland <mark.rutland@arm.com> writes:
> > > >>
> > [...]
> > > >> 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.
> >
> > I personally wouldn't even indirectly infer they are contiguous from
> > what the document says. If I were implementing the firmware I would feel
> > quite in my rights to, for example, use the top 8 bits of the ID for a
> > sensor type and the bottom 8 for an index, if that made dispatching of
> > requests more efficient. Or if some optional hardware was detected as
> > missing, leaving some holes in ID space.
> >
> > As a specification of a 'standard' the document seems to be rather
> > lacking. So, Sensor ID should be documented as being "an unsigned
> > integer less than then number of sensors returned by the Get Sensor
> > Capability command", or something like that. I guess clocks and other
> > devices suffer from similar lack of specificity.
>
> I think from the PoV of the binding, this doesn't matter. The value is
> just an arbitrary opaue token written down in a spec, that the FW
> understands how to interpret.
True, it's the Linux implementation in following patches that has
assumptions, e.g. for loops iterating over id's 0..N-1
>
> I only asked about how the IDs were organised because I thought there
> was additional translation in the kernel, but this is not the case.
>
> The only potential problem is bit-width. Punit, I assume the value is
> 32-bit (or less) in the messages to the FW?
It's 16 bit.
--
Tixy
WARNING: multiple messages have this Message-ID (diff)
From: "Jon Medhurst (Tixy)" <tixy-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Punit Agrawal <Punit.Agrawal-5wv7dgnIgG8@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org"
<lm-sensors-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org>,
"edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
<robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
"linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org"
<linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>,
Sudeep Holla <Sudeep.Holla-5wv7dgnIgG8@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v3 1/5] Documentation: add DT bindings for ARM SCPI sensors
Date: Tue, 15 Sep 2015 12:37:22 +0100 [thread overview]
Message-ID: <1442317042.2917.29.camel@linaro.org> (raw)
In-Reply-To: <20150915110330.GA6507@leverpostej>
On Tue, 2015-09-15 at 12:03 +0100, Mark Rutland wrote:
> On Tue, Sep 15, 2015 at 11:46:02AM +0100, Jon Medhurst (Tixy) wrote:
> > On Tue, 2015-09-15 at 10:37 +0100, Punit Agrawal wrote:
> > > "Jon Medhurst (Tixy)" <tixy-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> writes:
> > >
> > > > On Mon, 2015-09-14 at 15:38 +0100, Punit Agrawal wrote:
> > > >> Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> writes:
> > > >>
> > [...]
> > > >> 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.
> >
> > I personally wouldn't even indirectly infer they are contiguous from
> > what the document says. If I were implementing the firmware I would feel
> > quite in my rights to, for example, use the top 8 bits of the ID for a
> > sensor type and the bottom 8 for an index, if that made dispatching of
> > requests more efficient. Or if some optional hardware was detected as
> > missing, leaving some holes in ID space.
> >
> > As a specification of a 'standard' the document seems to be rather
> > lacking. So, Sensor ID should be documented as being "an unsigned
> > integer less than then number of sensors returned by the Get Sensor
> > Capability command", or something like that. I guess clocks and other
> > devices suffer from similar lack of specificity.
>
> I think from the PoV of the binding, this doesn't matter. The value is
> just an arbitrary opaue token written down in a spec, that the FW
> understands how to interpret.
True, it's the Linux implementation in following patches that has
assumptions, e.g. for loops iterating over id's 0..N-1
>
> I only asked about how the IDs were organised because I thought there
> was additional translation in the kernel, but this is not the case.
>
> The only potential problem is bit-width. Punit, I assume the value is
> 32-bit (or less) in the messages to the FW?
It's 16 bit.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: tixy@linaro.org (Jon Medhurst (Tixy))
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/5] Documentation: add DT bindings for ARM SCPI sensors
Date: Tue, 15 Sep 2015 12:37:22 +0100 [thread overview]
Message-ID: <1442317042.2917.29.camel@linaro.org> (raw)
In-Reply-To: <20150915110330.GA6507@leverpostej>
On Tue, 2015-09-15 at 12:03 +0100, Mark Rutland wrote:
> On Tue, Sep 15, 2015 at 11:46:02AM +0100, Jon Medhurst (Tixy) wrote:
> > On Tue, 2015-09-15 at 10:37 +0100, Punit Agrawal wrote:
> > > "Jon Medhurst (Tixy)" <tixy@linaro.org> writes:
> > >
> > > > On Mon, 2015-09-14 at 15:38 +0100, Punit Agrawal wrote:
> > > >> Mark Rutland <mark.rutland@arm.com> writes:
> > > >>
> > [...]
> > > >> 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.
> >
> > I personally wouldn't even indirectly infer they are contiguous from
> > what the document says. If I were implementing the firmware I would feel
> > quite in my rights to, for example, use the top 8 bits of the ID for a
> > sensor type and the bottom 8 for an index, if that made dispatching of
> > requests more efficient. Or if some optional hardware was detected as
> > missing, leaving some holes in ID space.
> >
> > As a specification of a 'standard' the document seems to be rather
> > lacking. So, Sensor ID should be documented as being "an unsigned
> > integer less than then number of sensors returned by the Get Sensor
> > Capability command", or something like that. I guess clocks and other
> > devices suffer from similar lack of specificity.
>
> I think from the PoV of the binding, this doesn't matter. The value is
> just an arbitrary opaue token written down in a spec, that the FW
> understands how to interpret.
True, it's the Linux implementation in following patches that has
assumptions, e.g. for loops iterating over id's 0..N-1
>
> I only asked about how the IDs were organised because I thought there
> was additional translation in the kernel, but this is not the case.
>
> The only potential problem is bit-width. Punit, I assume the value is
> 32-bit (or less) in the messages to the FW?
It's 16 bit.
--
Tixy
next prev parent reply other threads:[~2015-09-15 11:38 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 13:00 [PATCH v3 0/5] SCPI Sensor support Punit Agrawal
2015-09-14 13:00 ` Punit Agrawal
2015-09-14 13:00 ` [PATCH v3 1/5] Documentation: add DT bindings for ARM SCPI sensors Punit Agrawal
2015-09-14 13:00 ` Punit Agrawal
2015-09-14 13:00 ` Punit Agrawal
2015-09-14 13:14 ` Mark Rutland
2015-09-14 13:14 ` Mark Rutland
2015-09-14 13:14 ` Mark Rutland
2015-09-14 13:34 ` Punit Agrawal
2015-09-14 13:34 ` Punit Agrawal
2015-09-14 13:34 ` Punit Agrawal
2015-09-14 13:49 ` Mark Rutland
2015-09-14 13:49 ` Mark Rutland
2015-09-14 14:38 ` Punit Agrawal
2015-09-14 14:38 ` Punit Agrawal
2015-09-14 14:38 ` Punit Agrawal
2015-09-14 14:43 ` Mark Rutland
2015-09-14 14:43 ` Mark Rutland
2015-09-14 14:43 ` Mark Rutland
2015-09-14 15:01 ` Punit Agrawal
2015-09-14 15:01 ` Punit Agrawal
2015-09-14 15:01 ` Punit Agrawal
2015-09-14 15:15 ` Mark Rutland
2015-09-14 15:15 ` Mark Rutland
2015-09-14 16:03 ` Punit Agrawal
2015-09-14 16:03 ` Punit Agrawal
2015-09-14 16:03 ` Punit Agrawal
2015-09-14 17:18 ` Jon Medhurst (Tixy)
2015-09-14 17:18 ` Jon Medhurst (Tixy)
2015-09-14 17:18 ` Jon Medhurst (Tixy)
2015-09-15 9:37 ` Punit Agrawal
2015-09-15 9:37 ` Punit Agrawal
2015-09-15 9:37 ` Punit Agrawal
2015-09-15 10:46 ` Jon Medhurst (Tixy)
2015-09-15 10:46 ` Jon Medhurst (Tixy)
2015-09-15 11:03 ` Mark Rutland
2015-09-15 11:03 ` Mark Rutland
2015-09-15 11:03 ` Mark Rutland
2015-09-15 11:37 ` Jon Medhurst (Tixy) [this message]
2015-09-15 11:37 ` Jon Medhurst (Tixy)
2015-09-15 11:37 ` Jon Medhurst (Tixy)
2015-09-15 16:04 ` Punit Agrawal
2015-09-15 16:04 ` Punit Agrawal
2015-09-15 16:04 ` Punit Agrawal
2015-09-15 16:31 ` Jon Medhurst (Tixy)
2015-09-15 16:31 ` Jon Medhurst (Tixy)
2015-09-14 13:00 ` [PATCH v3 2/5] firmware: arm_scpi: Extend to support sensors Punit Agrawal
2015-09-14 13:00 ` Punit Agrawal
2015-09-14 13:00 ` [PATCH v3 3/5] hwmon: Support sensors exported via ARM SCP interface Punit Agrawal
2015-09-14 13:00 ` Punit Agrawal
2015-09-14 13:00 ` [Patch v3 4/5] hwmon: Support registration of thermal zones for SCP temperature sensors Punit Agrawal
2015-09-14 13:00 ` Punit Agrawal
2015-09-14 13:19 ` Punit Agrawal
2015-09-14 13:19 ` Punit Agrawal
2015-09-14 13:19 ` Punit Agrawal
2015-09-14 13:00 ` [PATCH v3 4/5] hwmon: Support thermal zones registration " Punit Agrawal
2015-09-14 13:00 ` Punit Agrawal
2015-09-14 13:00 ` [PATCH v3 5/5] arm64: dts: Add sensor node to Juno dt Punit Agrawal
2015-09-14 13:00 ` Punit Agrawal
2015-09-14 13:00 ` Punit Agrawal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1442317042.2917.29.camel@linaro.org \
--to=tixy@linaro.org \
--cc=Liviu.Dudau@arm.com \
--cc=Punit.Agrawal@arm.com \
--cc=Sudeep.Holla@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=edubezval@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lm-sensors@lm-sensors.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.