From: Tyler Hall <tylerwhall@gmail.com> To: Eduardo Valentin <edubezval@gmail.com> Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>, Ezequiel Garcia <ezequiel.garcia@free-electrons.com>, linux-pm@vger.kernel.org, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, Zhang Rui <rui.zhang@intel.com> Subject: Re: [PATCH] thermal: armada: read stable temp on Armada XP Date: Wed, 25 Feb 2015 14:47:11 -0500 [thread overview] Message-ID: <CAOjnSCZa+H+KRDJ+rug4OoinYEVN_fRrh4-fd4u_zzMEVNzjbQ@mail.gmail.com> (raw) In-Reply-To: <20150225183901.GD2306@developer.amazonguestwifi.org> Hi Gregory, Eduardo, On Wed, Feb 25, 2015 at 05:10:14PM +0100, Gregory CLEMENT wrote: > By using it by default do you mean removing marvell,armadaxp-thermal > and adding armadaxp-filtered-thermal instead ? Yes, replacing it in device tree. For me, /sys/class/thermal/thermal_zone0/temp returns the same temperature but with less variability between samples. My intent was to switch the source of the data and not affect user space other than providing a more stable reading. > Tyler, > In the meantime could you double check your values? The temperature on my board > seemed broken on my board. If needed I can check on an other board. By the way > on which board/product did you try it? I'm on a custom board with the 4-core MV78460. In addition to my patch, this is new device tree entry. thermal@184c4 { compatible = "marvell,armadaxp-filtered-thermal"; reg = <0x184c4 0x4 0x184d0 0x4>; status = "okay"; }; I dumped some raw samples of the temperature fields in each of these registers. This CSV contains the raw values converted to decimal. http://pastebin.com/Umc3cy5L The first column is the current register at 0x182b0 27:19 and the second is the register at 0x184c4 9:1. Here's a quick plot of a larger sample size while the temperature was rising. https://imgur.com/E9HlSBx The blue value is the current 0x182b0 register which seems to bounce around the green value from 0x184c4. I'll try a test of instantiating both at the same time and comparing the final output of the driver. On Wed, Feb 25, 2015 at 1:39 PM, Eduardo Valentin <edubezval@gmail.com> wrote: >> Does that new thermal sensors only improve the stability or does it >> also modify the value? >> >> In the second case it will more or less break the user space expectation. > > Yeah, I agree here. We need to understand if this is: > (1) a fix of which register to use. In that case, the old dtbs are > essentially wrong, and the driver would need to adapt, I would say. > (2) a way to report better temperature extrapolations. then, this is > essentially a new temp sensor, and we should have two separated > compatible. in other words, just keep the patch the way it is. This *might* be a different physical sensor, or it could be from the same source with some averaging/filtering applied in hardware. The conversion formula is the same, however, and I get similar raw values from both. > Yes. Typically I ask to see the complete series, even if I am not taking > the DTS changes. That is, you send a complete series, with changes in > the kernel code and in the DTS, copying the required audience (from > kernel side and from DT side). Once the changes are accepted, the > patches will be picked by the correct tree maintainer. It is common that > DTS changes go via the platform tree, to avoid conflicts though. Thanks for the clarification. I'll send both in the next version as I suspect there will be a v2 of this change.
WARNING: multiple messages have this Message-ID (diff)
From: Tyler Hall <tylerwhall-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: Eduardo Valentin <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Cc: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>, Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Kernel Mailing List <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Subject: Re: [PATCH] thermal: armada: read stable temp on Armada XP Date: Wed, 25 Feb 2015 14:47:11 -0500 [thread overview] Message-ID: <CAOjnSCZa+H+KRDJ+rug4OoinYEVN_fRrh4-fd4u_zzMEVNzjbQ@mail.gmail.com> (raw) In-Reply-To: <20150225183901.GD2306-ld4jwAGwUXRveXEdyy5Li2QTnQI6vUnv7KzsFvvc4iU@public.gmane.org> Hi Gregory, Eduardo, On Wed, Feb 25, 2015 at 05:10:14PM +0100, Gregory CLEMENT wrote: > By using it by default do you mean removing marvell,armadaxp-thermal > and adding armadaxp-filtered-thermal instead ? Yes, replacing it in device tree. For me, /sys/class/thermal/thermal_zone0/temp returns the same temperature but with less variability between samples. My intent was to switch the source of the data and not affect user space other than providing a more stable reading. > Tyler, > In the meantime could you double check your values? The temperature on my board > seemed broken on my board. If needed I can check on an other board. By the way > on which board/product did you try it? I'm on a custom board with the 4-core MV78460. In addition to my patch, this is new device tree entry. thermal@184c4 { compatible = "marvell,armadaxp-filtered-thermal"; reg = <0x184c4 0x4 0x184d0 0x4>; status = "okay"; }; I dumped some raw samples of the temperature fields in each of these registers. This CSV contains the raw values converted to decimal. http://pastebin.com/Umc3cy5L The first column is the current register at 0x182b0 27:19 and the second is the register at 0x184c4 9:1. Here's a quick plot of a larger sample size while the temperature was rising. https://imgur.com/E9HlSBx The blue value is the current 0x182b0 register which seems to bounce around the green value from 0x184c4. I'll try a test of instantiating both at the same time and comparing the final output of the driver. On Wed, Feb 25, 2015 at 1:39 PM, Eduardo Valentin <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> Does that new thermal sensors only improve the stability or does it >> also modify the value? >> >> In the second case it will more or less break the user space expectation. > > Yeah, I agree here. We need to understand if this is: > (1) a fix of which register to use. In that case, the old dtbs are > essentially wrong, and the driver would need to adapt, I would say. > (2) a way to report better temperature extrapolations. then, this is > essentially a new temp sensor, and we should have two separated > compatible. in other words, just keep the patch the way it is. This *might* be a different physical sensor, or it could be from the same source with some averaging/filtering applied in hardware. The conversion formula is the same, however, and I get similar raw values from both. > Yes. Typically I ask to see the complete series, even if I am not taking > the DTS changes. That is, you send a complete series, with changes in > the kernel code and in the DTS, copying the required audience (from > kernel side and from DT side). Once the changes are accepted, the > patches will be picked by the correct tree maintainer. It is common that > DTS changes go via the platform tree, to avoid conflicts though. Thanks for the clarification. I'll send both in the next version as I suspect there will be a v2 of this change. -- 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
next prev parent reply other threads:[~2015-02-25 19:47 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-02-10 22:50 [PATCH] thermal: armada: read stable temp on Armada XP Tyler Hall 2015-02-10 22:50 ` Tyler Hall 2015-02-24 18:36 ` Eduardo Valentin 2015-02-24 18:36 ` Eduardo Valentin 2015-02-24 19:56 ` Tyler Hall 2015-02-24 19:56 ` Tyler Hall 2015-02-25 16:10 ` Gregory CLEMENT 2015-02-25 18:39 ` Eduardo Valentin 2015-02-25 19:47 ` Tyler Hall [this message] 2015-02-25 19:47 ` Tyler Hall 2015-02-25 22:39 ` Tyler Hall 2015-02-25 17:04 ` Gregory CLEMENT 2015-02-25 18:17 ` Ezequiel Garcia 2015-02-25 18:38 ` Gregory CLEMENT
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=CAOjnSCZa+H+KRDJ+rug4OoinYEVN_fRrh4-fd4u_zzMEVNzjbQ@mail.gmail.com \ --to=tylerwhall@gmail.com \ --cc=devicetree@vger.kernel.org \ --cc=edubezval@gmail.com \ --cc=ezequiel.garcia@free-electrons.com \ --cc=gregory.clement@free-electrons.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=rui.zhang@intel.com \ /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: linkBe 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.