From: Mikko Perttunen <mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org"
<swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 1/3] of: Add descriptions of thermtrip properties to Tegra PMC bindings
Date: Wed, 13 Aug 2014 10:51:02 +0300 [thread overview]
Message-ID: <53EB18E6.3070203@nvidia.com> (raw)
In-Reply-To: <20140813073541.GA17466@ulmo>
On 13/08/14 10:35, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Aug 05, 2014 at 11:12:58AM +0300, Mikko Perttunen wrote:
>> Hardware-triggered thermal reset requires configuring the I2C
>> reset procedure. This configuration is read from the device tree,
>> so document the relevant properties in the binding documentation.
>>
>> Signed-off-by: Mikko Perttunen <mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>> ---
>> .../devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> index 68ac65f..140e2aa 100644
>> --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> @@ -38,6 +38,19 @@ Required properties when nvidia,suspend-mode is specified:
>> Core power good time in uS.
>> - nvidia,core-pwr-off-time : Core power off time in uS.
>>
>> +Required properties for hardware-triggered thermal reset:
>> + (only tegra30, tegra114, tegra124)
>> +- nvidia,thermtrip-pmu-i2c-addr : I2C address of the power management unit.
>> +- nvidia,thermtrip-i2c-controller : Index of the I2C controller the PMU is
>> + attached to.
>
> This duplicates information already associated with the PMU device. Can
> this be turned into something like:
>
> nvidia,thermtrip-pmu: phandle to Power Management Unit
>
> Then we can query the relevant information from the I2C client resolved
> from the phandle.
True, that would look nicer.
>
> One problem with that might be that the I2C controller index may not
> match the hardware ID.
Maybe we could resort to checking the controller address in this case.
This is a safety feature, so programming the wrong controller index
accidentally would be bad.
>
>> +- nvidia,thermtrip-reg-addr : Address (byte) to send reset command to.
>> +- nvidia,thermtrip-reg-data : Data (byte) to use as reset command.
>> +
>> +Optional properties for hardware-triggered thermal reset:
>> + (only tegra30, tegra114, tegra124)
>> +- nvidia,thermtrip-pinmux : Pinmux ID used for I2C access.
>
> I suppose this takes a phandle? If so the description should probably
> say so.
No, it takes a pinmux ID, described in the boot process (non-public in
T124 I guess..) section of the TRM. It seems, though, that all platforms
supported by the downstream kernel have pinmux == 0.
>
>> +- nvidia,thermtrip-pmu-16bit-ops : Use 16-bit operations.
>
> What exactly does "16-bit operations" mean? And isn't this a property of
> the I2C device, therefore could be queried from the I2C slave via the
> phandle?
That's how it's described in the TRM, but I just found a comment in the
downstream kernel about it. Apparently it controls the amount of data
sent to the PMIC. The downstream kernel says, though, that the option is
not supported and must always be left as zero, so I guess it could be
dropped.
>
> Thierry
>
> * Unknown Key
> * 0x7F3EB3A1
>
Cheers,
Mikko
WARNING: multiple messages have this Message-ID (diff)
From: mperttunen@nvidia.com (Mikko Perttunen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] of: Add descriptions of thermtrip properties to Tegra PMC bindings
Date: Wed, 13 Aug 2014 10:51:02 +0300 [thread overview]
Message-ID: <53EB18E6.3070203@nvidia.com> (raw)
In-Reply-To: <20140813073541.GA17466@ulmo>
On 13/08/14 10:35, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Aug 05, 2014 at 11:12:58AM +0300, Mikko Perttunen wrote:
>> Hardware-triggered thermal reset requires configuring the I2C
>> reset procedure. This configuration is read from the device tree,
>> so document the relevant properties in the binding documentation.
>>
>> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
>> ---
>> .../devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> index 68ac65f..140e2aa 100644
>> --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> @@ -38,6 +38,19 @@ Required properties when nvidia,suspend-mode is specified:
>> Core power good time in uS.
>> - nvidia,core-pwr-off-time : Core power off time in uS.
>>
>> +Required properties for hardware-triggered thermal reset:
>> + (only tegra30, tegra114, tegra124)
>> +- nvidia,thermtrip-pmu-i2c-addr : I2C address of the power management unit.
>> +- nvidia,thermtrip-i2c-controller : Index of the I2C controller the PMU is
>> + attached to.
>
> This duplicates information already associated with the PMU device. Can
> this be turned into something like:
>
> nvidia,thermtrip-pmu: phandle to Power Management Unit
>
> Then we can query the relevant information from the I2C client resolved
> from the phandle.
True, that would look nicer.
>
> One problem with that might be that the I2C controller index may not
> match the hardware ID.
Maybe we could resort to checking the controller address in this case.
This is a safety feature, so programming the wrong controller index
accidentally would be bad.
>
>> +- nvidia,thermtrip-reg-addr : Address (byte) to send reset command to.
>> +- nvidia,thermtrip-reg-data : Data (byte) to use as reset command.
>> +
>> +Optional properties for hardware-triggered thermal reset:
>> + (only tegra30, tegra114, tegra124)
>> +- nvidia,thermtrip-pinmux : Pinmux ID used for I2C access.
>
> I suppose this takes a phandle? If so the description should probably
> say so.
No, it takes a pinmux ID, described in the boot process (non-public in
T124 I guess..) section of the TRM. It seems, though, that all platforms
supported by the downstream kernel have pinmux == 0.
>
>> +- nvidia,thermtrip-pmu-16bit-ops : Use 16-bit operations.
>
> What exactly does "16-bit operations" mean? And isn't this a property of
> the I2C device, therefore could be queried from the I2C slave via the
> phandle?
That's how it's described in the TRM, but I just found a comment in the
downstream kernel about it. Apparently it controls the amount of data
sent to the PMIC. The downstream kernel says, though, that the option is
not supported and must always be left as zero, so I guess it could be
dropped.
>
> Thierry
>
> * Unknown Key
> * 0x7F3EB3A1
>
Cheers,
Mikko
WARNING: multiple messages have this Message-ID (diff)
From: Mikko Perttunen <mperttunen@nvidia.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: "swarren@wwwdotorg.org" <swarren@wwwdotorg.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH 1/3] of: Add descriptions of thermtrip properties to Tegra PMC bindings
Date: Wed, 13 Aug 2014 10:51:02 +0300 [thread overview]
Message-ID: <53EB18E6.3070203@nvidia.com> (raw)
In-Reply-To: <20140813073541.GA17466@ulmo>
On 13/08/14 10:35, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Aug 05, 2014 at 11:12:58AM +0300, Mikko Perttunen wrote:
>> Hardware-triggered thermal reset requires configuring the I2C
>> reset procedure. This configuration is read from the device tree,
>> so document the relevant properties in the binding documentation.
>>
>> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
>> ---
>> .../devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> index 68ac65f..140e2aa 100644
>> --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
>> @@ -38,6 +38,19 @@ Required properties when nvidia,suspend-mode is specified:
>> Core power good time in uS.
>> - nvidia,core-pwr-off-time : Core power off time in uS.
>>
>> +Required properties for hardware-triggered thermal reset:
>> + (only tegra30, tegra114, tegra124)
>> +- nvidia,thermtrip-pmu-i2c-addr : I2C address of the power management unit.
>> +- nvidia,thermtrip-i2c-controller : Index of the I2C controller the PMU is
>> + attached to.
>
> This duplicates information already associated with the PMU device. Can
> this be turned into something like:
>
> nvidia,thermtrip-pmu: phandle to Power Management Unit
>
> Then we can query the relevant information from the I2C client resolved
> from the phandle.
True, that would look nicer.
>
> One problem with that might be that the I2C controller index may not
> match the hardware ID.
Maybe we could resort to checking the controller address in this case.
This is a safety feature, so programming the wrong controller index
accidentally would be bad.
>
>> +- nvidia,thermtrip-reg-addr : Address (byte) to send reset command to.
>> +- nvidia,thermtrip-reg-data : Data (byte) to use as reset command.
>> +
>> +Optional properties for hardware-triggered thermal reset:
>> + (only tegra30, tegra114, tegra124)
>> +- nvidia,thermtrip-pinmux : Pinmux ID used for I2C access.
>
> I suppose this takes a phandle? If so the description should probably
> say so.
No, it takes a pinmux ID, described in the boot process (non-public in
T124 I guess..) section of the TRM. It seems, though, that all platforms
supported by the downstream kernel have pinmux == 0.
>
>> +- nvidia,thermtrip-pmu-16bit-ops : Use 16-bit operations.
>
> What exactly does "16-bit operations" mean? And isn't this a property of
> the I2C device, therefore could be queried from the I2C slave via the
> phandle?
That's how it's described in the TRM, but I just found a comment in the
downstream kernel about it. Apparently it controls the amount of data
sent to the PMIC. The downstream kernel says, though, that the option is
not supported and must always be left as zero, so I guess it could be
dropped.
>
> Thierry
>
> * Unknown Key
> * 0x7F3EB3A1
>
Cheers,
Mikko
next prev parent reply other threads:[~2014-08-13 7:51 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-05 8:12 [PATCH 0/3] Thermal reset support in PMC Mikko Perttunen
2014-08-05 8:12 ` Mikko Perttunen
2014-08-05 8:12 ` Mikko Perttunen
2014-08-05 8:12 ` [PATCH 1/3] of: Add descriptions of thermtrip properties to Tegra PMC bindings Mikko Perttunen
2014-08-05 8:12 ` Mikko Perttunen
2014-08-05 8:12 ` Mikko Perttunen
[not found] ` <1407226380-747-2-git-send-email-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-08-13 7:35 ` Thierry Reding
2014-08-13 7:35 ` Thierry Reding
2014-08-13 7:35 ` Thierry Reding
2014-08-13 7:51 ` Mikko Perttunen [this message]
2014-08-13 7:51 ` Mikko Perttunen
2014-08-13 7:51 ` Mikko Perttunen
2014-08-13 8:01 ` Thierry Reding
2014-08-13 8:01 ` Thierry Reding
2014-08-05 8:12 ` [PATCH 2/3] ARM: tegra: Add PMC thermtrip programming to Jetson TK1 device tree Mikko Perttunen
2014-08-05 8:12 ` Mikko Perttunen
2014-08-05 8:12 ` Mikko Perttunen
[not found] ` <1407226380-747-3-git-send-email-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-08-13 7:37 ` Thierry Reding
2014-08-13 7:37 ` Thierry Reding
2014-08-13 7:37 ` Thierry Reding
2014-08-13 7:52 ` Mikko Perttunen
2014-08-13 7:52 ` Mikko Perttunen
2014-08-13 7:52 ` Mikko Perttunen
2014-08-13 8:03 ` Thierry Reding
2014-08-13 8:03 ` Thierry Reding
2014-08-13 8:06 ` Mikko Perttunen
2014-08-13 8:06 ` Mikko Perttunen
2014-08-13 8:06 ` Mikko Perttunen
2014-08-05 8:13 ` [PATCH 3/3] ARM: tegra: Add thermal reset (thermtrip) support to PMC Mikko Perttunen
2014-08-05 8:13 ` Mikko Perttunen
2014-08-05 8:13 ` Mikko Perttunen
[not found] ` <1407226380-747-4-git-send-email-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-08-13 7:53 ` Thierry Reding
2014-08-13 7:53 ` Thierry Reding
2014-08-13 7:53 ` Thierry Reding
2014-08-13 8:05 ` Mikko Perttunen
2014-08-13 8:05 ` Mikko Perttunen
2014-08-13 10:10 ` Wei Ni
2014-08-13 10:10 ` Wei Ni
2014-08-13 10:10 ` Wei Ni
[not found] ` <1407226380-747-1-git-send-email-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-08-13 8:07 ` [PATCH 0/3] Thermal reset support in PMC Thierry Reding
2014-08-13 8:07 ` Thierry Reding
2014-08-13 8:07 ` Thierry Reding
2014-08-13 8:12 ` Mikko Perttunen
2014-08-13 8:12 ` Mikko Perttunen
2014-08-13 8:12 ` Mikko Perttunen
[not found] ` <53EB1DF5.301-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-08-13 8:42 ` Mikko Perttunen
2014-08-13 8:42 ` Mikko Perttunen
2014-08-13 8:42 ` Mikko Perttunen
[not found] ` <53EB250D.5070207-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-08-13 8:57 ` Thierry Reding
2014-08-13 8:57 ` Thierry Reding
2014-08-13 8:57 ` Thierry Reding
2014-08-13 9:52 ` Mikko Perttunen
2014-08-13 9:52 ` Mikko Perttunen
2014-08-13 9:52 ` Mikko Perttunen
2014-08-13 10:36 ` Thierry Reding
2014-08-13 10:36 ` Thierry Reding
2014-08-13 10:41 ` Mikko Perttunen
2014-08-13 10:41 ` Mikko Perttunen
2014-08-13 10:41 ` Mikko Perttunen
[not found] ` <53EB40F0.4000300-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-08-13 10:53 ` Thierry Reding
2014-08-13 10:53 ` Thierry Reding
2014-08-13 10:53 ` Thierry Reding
2014-08-13 10:59 ` Mikko Perttunen
2014-08-13 10:59 ` Mikko Perttunen
2014-08-13 10:59 ` Mikko Perttunen
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=53EB18E6.3070203@nvidia.com \
--to=mperttunen-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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.