* Re: [PATCH v2] Documentation/CodingStyle: Add an example for braces
From: Jonathan Corbet @ 2018-03-21 15:17 UTC (permalink / raw)
To: Gary R Hook; +Cc: linux-doc, linux-kernel, Jani Nikula
In-Reply-To: <152114372879.3142.8833111074324091904.stgit@taos>
On Thu, 15 Mar 2018 15:04:02 -0500
Gary R Hook <gary.hook@amd.com> wrote:
> +Do use braces when a body is more complex than a single simple statement:
> +
> +.. code-block:: c
> +
> + if (condition) {
> + if (another_condition)
> + do_something();
> + }
Somebody is sure to complain at some point that this should really be:
if (condition && another_condition)
do_something();
To head that off, I think I'll apply your first version instead, sorry
Jani.
In general I'm pretty reluctant to apply coding-style patches for the
simple reason that I sure don't want to be the arbitrator of proper kernel
style. This one seems to fit well within the accepted norms, though.
Thanks,
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] docs/vm: update 00-INDEX
From: Jonathan Corbet @ 2018-03-21 15:10 UTC (permalink / raw)
To: Mike Rapoport; +Cc: linux-doc, linux-mm
In-Reply-To: <1521644723-19354-1-git-send-email-rppt@linux.vnet.ibm.com>
On Wed, 21 Mar 2018 17:05:23 +0200
Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> Several files were added to Documentation/vm without updates to 00-INDEX.
> Fill in the missing documents
Applied, thanks.
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] kernel-doc: Remove __sched markings
From: Jonathan Corbet @ 2018-03-21 15:09 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linux-doc
In-Reply-To: <20180315120623.GB9949@bombadil.infradead.org>
On Thu, 15 Mar 2018 05:06:23 -0700
Matthew Wilcox <willy@infradead.org> wrote:
> I find the __sched annotations unaesthetic in the kernel-doc. Remove
> them like we remove __inline, __weak, __init and so on.
Makes sense, applied, thanks.
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] docs/vm: update 00-INDEX
From: Mike Rapoport @ 2018-03-21 15:05 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: linux-doc, linux-mm, Mike Rapoport
Several files were added to Documentation/vm without updates to 00-INDEX.
Fill in the missing documents
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
---
Documentation/vm/00-INDEX | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/vm/00-INDEX b/Documentation/vm/00-INDEX
index 11d3d8d..0278f2c 100644
--- a/Documentation/vm/00-INDEX
+++ b/Documentation/vm/00-INDEX
@@ -10,6 +10,8 @@ frontswap.txt
- Outline frontswap, part of the transcendent memory frontend.
highmem.txt
- Outline of highmem and common issues.
+hmm.txt
+ - Documentation of heterogeneous memory management
hugetlbpage.txt
- a brief summary of hugetlbpage support in the Linux kernel.
hugetlbfs_reserv.txt
@@ -20,25 +22,41 @@ idle_page_tracking.txt
- description of the idle page tracking feature.
ksm.txt
- how to use the Kernel Samepage Merging feature.
+mmu_notifier.txt
+ - a note about clearing pte/pmd and mmu notifications
numa
- information about NUMA specific code in the Linux vm.
numa_memory_policy.txt
- documentation of concepts and APIs of the 2.6 memory policy support.
overcommit-accounting
- description of the Linux kernels overcommit handling modes.
+page_frags
+ - description of page fragments allocator
page_migration
- description of page migration in NUMA systems.
pagemap.txt
- pagemap, from the userspace perspective
+page_owner.txt
+ - tracking about who allocated each page
+remap_file_pages.txt
+ - a note about remap_file_pages() system call
slub.txt
- a short users guide for SLUB.
soft-dirty.txt
- short explanation for soft-dirty PTEs
split_page_table_lock
- Separate per-table lock to improve scalability of the old page_table_lock.
+swap_numa.txt
+ - automatic binding of swap device to numa node
transhuge.txt
- Transparent Hugepage Support, alternative way of using hugepages.
unevictable-lru.txt
- Unevictable LRU infrastructure
+userfaultfd.txt
+ - description of userfaultfd system call
+z3fold.txt
+ - outline of z3fold allocator for storing compressed pages
+zsmalloc.txt
+ - outline of zsmalloc allocator for storing compressed pages
zswap.txt
- Intro to compressed cache for swap pages
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] README: Improve documentation descriptions
From: Jonathan Corbet @ 2018-03-21 15:02 UTC (permalink / raw)
To: Martin Kepplinger; +Cc: linux-doc, linux-kernel
In-Reply-To: <20180316155707.28426-1-martink@posteo.de>
On Fri, 16 Mar 2018 16:57:07 +0100
Martin Kepplinger <martink@posteo.de> wrote:
> "This file" indeed was moved once, but at some point "this file", the
> top-level README, becomes a file in itself. Now that time has come :)
>
> Let's describe how things are, and suggest reading "this file" first,
> "this file" simply being a the admin-guide README file, not a file that
> was once moved.
OK, sure, applied.
Maybe I'll tack on something pointing to
https://www.kernel.org/doc/html/latest/ as well.
Thanks,
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus
From: Dou Liyang @ 2018-03-21 9:41 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, x86, linux-acpi, linux-doc, tglx, mingo, corbet,
rjw, lenb, hpa
In-Reply-To: <076196e1-c181-ba44-f912-61bd279b345b@cn.fujitsu.com>
At 03/21/2018 05:34 PM, Dou Liyang wrote:
> Hi Peter,
>
> At 03/21/2018 05:08 PM, Peter Zijlstra wrote:
>> On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote:
>>> How about:
>>>
>>> possible_cpus= [s390,x86_64] Set the number of possible CPUs which
>>> are determined by the ACPI tables MADT or mptables by
>>> default. possible_cpus=n : n >= 1 enforces the possible
>>> number to be 'n'.
>>> While nr_cpus is also be set: nr_cpus=m, choice the
>>> minimum one for the number of possible CPUs.
>>
>> So what is the exact difference between possible_cpus and nr_cpus ? I
>
> the possible_cpus= can reset the number of possible CPUs, even bigger
> than 'num_processors + disabled_cpus', But nr_cpus= can't.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the maximum number kernel gets from ACPI/mptables, no matter what
number nr_cpus= is, the number of possible CPUs will not bigger than it.
>
>> konw maxcpus= limits the number of CPUs we bring up, and possible_cpus
>> limits the possible_map, but I'm not entirely sure what nr_cpus does
>> here.
>>
>
> nr_cpus can limited the maximum CPUs that the kernel could support.
>
> Here is a double check in case of using them at the same time, even if I
> think just using possible_cpus= is enough. :-)
>
> Thanks,
> dou.
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus
From: Thomas Gleixner @ 2018-03-21 9:41 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Dou Liyang, linux-kernel, x86, linux-acpi, linux-doc, mingo,
corbet, rjw, lenb, hpa
In-Reply-To: <20180321090826.GW4043@hirez.programming.kicks-ass.net>
On Wed, 21 Mar 2018, Peter Zijlstra wrote:
> On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote:
> > How about:
> >
> > possible_cpus= [s390,x86_64] Set the number of possible CPUs which
> > are determined by the ACPI tables MADT or mptables by
> > default. possible_cpus=n : n >= 1 enforces the possible
> > number to be 'n'.
> > While nr_cpus is also be set: nr_cpus=m, choice the
> > minimum one for the number of possible CPUs.
>
> So what is the exact difference between possible_cpus and nr_cpus ? I
> konw maxcpus= limits the number of CPUs we bring up, and possible_cpus
> limits the possible_map, but I'm not entirely sure what nr_cpus does
> here.
nr_cpus limits the number of CPUs the kernel will handle. Think of it as a
boot time override of NR_CPUs.
Way too many commandline switches though.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus
From: Dou Liyang @ 2018-03-21 9:34 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, x86, linux-acpi, linux-doc, tglx, mingo, corbet,
rjw, lenb, hpa
In-Reply-To: <20180321090826.GW4043@hirez.programming.kicks-ass.net>
Hi Peter,
At 03/21/2018 05:08 PM, Peter Zijlstra wrote:
> On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote:
>> How about:
>>
>> possible_cpus= [s390,x86_64] Set the number of possible CPUs which
>> are determined by the ACPI tables MADT or mptables by
>> default. possible_cpus=n : n >= 1 enforces the possible
>> number to be 'n'.
>> While nr_cpus is also be set: nr_cpus=m, choice the
>> minimum one for the number of possible CPUs.
>
> So what is the exact difference between possible_cpus and nr_cpus ? I
the possible_cpus= can reset the number of possible CPUs, even bigger
than 'num_processors + disabled_cpus', But nr_cpus= can't.
> konw maxcpus= limits the number of CPUs we bring up, and possible_cpus
> limits the possible_map, but I'm not entirely sure what nr_cpus does
> here.
>
nr_cpus can limited the maximum CPUs that the kernel could support.
Here is a double check in case of using them at the same time, even if I
think just using possible_cpus= is enough. :-)
Thanks,
dou.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus
From: Peter Zijlstra @ 2018-03-21 9:08 UTC (permalink / raw)
To: Dou Liyang
Cc: linux-kernel, x86, linux-acpi, linux-doc, tglx, mingo, corbet,
rjw, lenb, hpa
In-Reply-To: <f64cb207-3851-9a26-2001-653fc0068540@cn.fujitsu.com>
On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote:
> How about:
>
> possible_cpus= [s390,x86_64] Set the number of possible CPUs which
> are determined by the ACPI tables MADT or mptables by
> default. possible_cpus=n : n >= 1 enforces the possible
> number to be 'n'.
> While nr_cpus is also be set: nr_cpus=m, choice the
> minimum one for the number of possible CPUs.
So what is the exact difference between possible_cpus and nr_cpus ? I
konw maxcpus= limits the number of CPUs we bring up, and possible_cpus
limits the possible_map, but I'm not entirely sure what nr_cpus does
here.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 5/6] arm64: dts: sdm845: Add serial console support
From: Rajendra Nayak @ 2018-03-21 8:37 UTC (permalink / raw)
To: Stephen Boyd, Karthikeyan Ramasubramanian, andy.gross, corbet,
david.brown, gregkh, mark.rutland, robh+dt, wsa
Cc: linux-doc, linux-arm-msm, devicetree, linux-i2c, linux-serial,
jslaby, evgreen, acourbot
In-Reply-To: <152157474508.187949.10348604942277810227@swboyd.mtv.corp.google.com>
On 3/21/2018 1:09 AM, Stephen Boyd wrote:
> Quoting Karthikeyan Ramasubramanian (2018-03-14 16:58:50)
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>> index 979ab49..ea3efc5 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
>> @@ -12,4 +12,43 @@
>> / {
>> model = "Qualcomm Technologies, Inc. SDM845 MTP";
>> compatible = "qcom,sdm845-mtp";
>> +
>> + aliases {
>> + serial0 = &uart2;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0";
>
> Also add :115200n8 ?
>
>
>> + };
>> +};
>> +
>> +&soc {
>
> I think the method is to put these inside soc node without using the
> phandle reference. So indent everything once more.
Some of this was discussed in the previous versions [1] and we arrived
at a consensus to follow this way of doing it.
Bjorn also said he was going to do a series to move all the existing
dts files to follow similar convention so its all consistent.
https://lkml.org/lkml/2018/2/6/676
>
>> + geniqup@ac0000 {
>> + serial@a84000 {
>> + status = "okay";
>> + };
>> + };
>> +
>> + pinctrl@3400000 {
>> + qup-uart2-default {
>> + pinconf_tx {
>> + pins = "gpio4";
>> + drive-strength = <2>;
>> + bias-disable;
>> + };
>> +
>> + pinconf_rx {
>> + pins = "gpio5";
>> + drive-strength = <2>;
>> + bias-pull-up;
>> + };
>> + };
>> +
>> + qup-uart2-sleep {
>> + pinconf {
>> + pins = "gpio4", "gpio5";
>> + bias-pull-down;
>> + };
>> + };
>> + };
>> };
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> index 32f8561..59334d9 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -6,6 +6,7 @@
>> */
>>
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/clock/qcom,gcc-sdm845.h>
>>
>> / {
>> interrupt-parent = <&intc>;
>> @@ -194,6 +195,20 @@
>> #gpio-cells = <2>;
>> interrupt-controller;
>> #interrupt-cells = <2>;
>> +
>> + qup_uart2_default: qup-uart2-default {
>> + pinmux {
>> + function = "qup9";
>> + pins = "gpio4", "gpio5";
>> + };
>> + };
>> +
>> + qup_uart2_sleep: qup-uart2-sleep {
>> + pinmux {
>> + function = "gpio";
>> + pins = "gpio4", "gpio5";
>> + };
>> + };
>
> Are these supposed to go to the board file?
Again, this was discussed in the previous versions, and we decided it
makes sense to have the pinmux (default) which rarely changes across
boards in the SoC file, and have boards specify the pinconf (electrical)
properties.
And get rid of all the soc-pins/board-pins/pmic-pins files.
https://lkml.org/lkml/2018/2/6/693
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 7/9] hwmon: pwm-fan: add sysfs node to read rpm of fan
From: Guenter Roeck @ 2018-03-21 6:09 UTC (permalink / raw)
To: Rajkumar Rampelli, robh+dt, mark.rutland, thierry.reding,
jonathanh, jdelvare, corbet, catalin.marinas, will.deacon,
kstewart, gregkh, pombredanne, mmaddireddy, mperttunen, arnd,
timur, andy.gross, xuwei5, elder, heiko, krzk, ard.biesheuvel
Cc: devicetree, linux-kernel, linux-pwm, linux-tegra, linux-hwmon,
linux-doc, linux-arm-kernel, ldewangan
In-Reply-To: <1521607244-29734-8-git-send-email-rrajk@nvidia.com>
On 03/20/2018 09:40 PM, Rajkumar Rampelli wrote:
> Add fan device attribute fan1_input in pwm-fan driver
> to read speed of fan in rotations per minute.
>
> Signed-off-by: Rajkumar Rampelli <rrajk@nvidia.com>
> ---
>
> V2: Removed generic-pwm-tachometer driver and using pwm-fan driver as per suggestions
> to read fan speed.
> Added fan device attribute to report speed of fan in rpms through hwmon sysfs.
>
> drivers/hwmon/pwm-fan.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
> index 70cc0d1..8dda209 100644
> --- a/drivers/hwmon/pwm-fan.c
> +++ b/drivers/hwmon/pwm-fan.c
> @@ -98,11 +98,34 @@ static ssize_t show_pwm(struct device *dev,
> return sprintf(buf, "%u\n", ctx->pwm_value);
> }
>
> +static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,
> + char *buf)
> +{
> + struct pwm_fan_ctx *ptt = dev_get_drvdata(dev);
> + struct pwm_device *pwm = ptt->pwm;
> + struct pwm_capture result;
> + unsigned int rpm = 0;
> + int ret;
> +
> + ret = pwm_capture(pwm, &result, 0);
> + if (ret < 0) {
> + pr_err("Failed to capture PWM: %d\n", ret);
> + return ret;
> + }
> +
> + if (result.period)
> + rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
> + result.period);
> +
> + return sprintf(buf, "%u\n", rpm);
> +}
>
> static SENSOR_DEVICE_ATTR(pwm1, S_IRUGO | S_IWUSR, show_pwm, set_pwm, 0);
> +static SENSOR_DEVICE_ATTR(fan1_input, 0444, show_rpm, NULL, 0);
>
> static struct attribute *pwm_fan_attrs[] = {
> &sensor_dev_attr_pwm1.dev_attr.attr,
> + &sensor_dev_attr_fan1_input.dev_attr.attr,
This doesn't make sense. The same pwm can not both control the fan speed
and report it.
Guenter
> NULL,
> };
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/5] x86/smpboot: Make the check code more clear in prefill_possible_map()
From: Dou Liyang @ 2018-03-21 5:38 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, x86, linux-acpi, linux-doc, tglx, mingo, corbet,
rjw, lenb, hpa
In-Reply-To: <20180320123918.GS4043@hirez.programming.kicks-ass.net>
Hi Peter,
At 03/20/2018 08:39 PM, Peter Zijlstra wrote:
> On Tue, Mar 20, 2018 at 07:04:30PM +0800, Dou Liyang wrote:
>> case 1: no | no | no | --> min (setup_possible_cpus, nr_cpu_ids, setup_max_cpus)
>> case 2: no | no | yes| --> min (setup_possible_cpus, nr_cpu_ids)
>> case 3: no | yes | no | --> 1
>> case 4: no | yes | yes| --> 1
>> case 5: yes | no | no | --> min (num_processors, nr_cpu_ids, setup_max_cpus)
>> case 6: yes | no | yes| --> min (num_processors + disabled_cpus, nr_cpu_ids)
>> case 7: yes | yes | no | --> 1
>> case 8: yes | yes | yes| --> 1
>
> The case number is off by one ;-)
>
I got it! ;-）
Thanks
dou
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus
From: Dou Liyang @ 2018-03-21 5:33 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, x86, linux-acpi, linux-doc, tglx, mingo, corbet,
rjw, lenb, hpa
In-Reply-To: <20180320123712.GR4043@hirez.programming.kicks-ass.net>
Hi Peter,
At 03/20/2018 08:37 PM, Peter Zijlstra wrote:
> On Tue, Mar 20, 2018 at 07:04:28PM +0800, Dou Liyang wrote:
>
>> + possible_cpus= [s390,x86_64] Use this to set hotpluggable cpus.
>> + This option sets possible_cpus bits in cpu_possible_map.
>> + Thus keeping the numbers of bits set constant even if
>> + the machine gets rebooted.
>
> That description, esp. the last sentence, doesn't make any kind of sense
> to me. What?
>
Ah, sure enough, I can't be lazy. :-) I stole that from the commit
3b11ce7f542e ("x86: use possible_cpus=NUM to extend the possible cpus
allowed")
How about:
possible_cpus= [s390,x86_64] Set the number of possible CPUs which
are determined by the ACPI tables MADT or mptables by
default. possible_cpus=n : n >= 1 enforces the possible
number to be 'n'.
While nr_cpus is also be set: nr_cpus=m, choice the
minimum one for the number of possible CPUs.
Thank,
dou
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V2 6/9] arm64: tegra: Add pwm based fan support on Tegra186
From: Rajkumar Rampelli @ 2018-03-21 4:40 UTC (permalink / raw)
To: robh+dt, mark.rutland, thierry.reding, jonathanh, jdelvare, linux,
corbet, catalin.marinas, will.deacon, kstewart, gregkh,
pombredanne, mmaddireddy, mperttunen, arnd, timur, andy.gross,
xuwei5, elder, heiko, krzk, ard.biesheuvel
Cc: devicetree, linux-kernel, linux-pwm, linux-tegra, linux-hwmon,
linux-doc, linux-arm-kernel, ldewangan, rrajk
In-Reply-To: <1521607244-29734-1-git-send-email-rrajk@nvidia.com>
Add pwm fan driver support on Tegra186 SoC.
Signed-off-by: Rajkumar Rampelli <rrajk@nvidia.com>
---
V2: Removed generic-pwm-tachometer driver dt node and using pwm-fan driver
for reading fan speed.
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 19e1afc..27ae73e 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1053,4 +1053,10 @@
reset-names = "tachometer";
status = "disabled";
};
+
+ pwm_fan {
+ compatible = "pwm-fan";
+ pwms = <&tegra_tachometer 0 1000000>;
+ status = "disabled";
+ };
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 0/9] Implementation of Tegra Tachometer driver
From: Rajkumar Rampelli @ 2018-03-21 4:40 UTC (permalink / raw)
To: robh+dt, mark.rutland, thierry.reding, jonathanh, jdelvare, linux,
corbet, catalin.marinas, will.deacon, kstewart, gregkh,
pombredanne, mmaddireddy, mperttunen, arnd, timur, andy.gross,
xuwei5, elder, heiko, krzk, ard.biesheuvel
Cc: devicetree, linux-kernel, linux-pwm, linux-tegra, linux-hwmon,
linux-doc, linux-arm-kernel, ldewangan, rrajk
The following patches adds support for PWM based Tegra Tachometer driver
which implements PWM capture interface to analyze the PWM signal of a
electronic fan and reports it in periods and duty cycles.
Added fan device attribute fan1_input in pwm-fan driver to monitor the
speed of fan in rotations per minute using PWM interface.
RPM of Fan will be exposed to user interface through HWMON sysfs interface
avialable at location: /sys/class/hwmon/hwmon0/fan1_input
Steps to validate Tachometer on Tegra186 SoC:
A. push modules pwm-tegra.ko, pwm-tegra-tachometer.ko and pwm-fan.ko to
linux device using scp command.
scp build/tegra186/drivers/pwm/pwm-tegra.ko ubuntu@10.19.65.176:/tmp/
scp build/tegra186/drivers/pwm/pwm-tegra-tachometer.ko ubuntu@10.19.65.176:/tmp/
scp build/tegra186/drivers/hwmon/pwm-fan.ko ubuntu@10.19.65.176:/tmp/
B. On Linux device console, insert these modules using insmod command.
insmod /tmp/pwm-tegra.ko
insmod /tmp/pwm-tegra-tachometer.ko
insmod /tmp/pwm-fan.ko
C. Read RPM value at below sysfs node
cat /sys/calss/hwmon/hwmon0/fan1_input
D. Change the FAN speed using PWM sysfs interface. Follow below steps for the same:
a. cd /sys/class/pwm/pwmchip0
b. ls -la (make sure pwm controller is c340000.pwm)
Output should be: device -> ../../../c340000.pwm
c. echo 0 > export
d. cd pwmchip0:0
e. echo 8000 > period
f. echo 1 > enable
g. echo 8000 > duty_cycle # change duty_cycles from 0 to 8000 for FAN speed variation
h. cat /sys/calss/hwmon/hwmon0/fan1_input
i. echo 4000 > duty_cycle
h. cat /sys/calss/hwmon/hwmon0/fan1_input
i. echo 2000 > duty_cycle
h. cat /sys/calss/hwmon/hwmon0/fan1_input
i. echo 0 > duty_cycle
h. cat /sys/calss/hwmon/hwmon0/fan1_input
Rajkumar Rampelli (9):
pwm: core: Add support for PWM HW driver with pwm capture only
arm64: tegra: Add PWM controller on Tegra186 soc
dt-bindings: Tegra186 tachometer device tree bindings
arm64: tegra: Add Tachometer Controller on Tegra186
pwm: tegra: Add PWM based Tachometer driver
arm64: tegra: Add pwm based fan support on Tegra186
hwmon: pwm-fan: add sysfs node to read rpm of fan
arm64: defconfig: enable Nvidia Tegra Tachometer as a module
arm64: defconfig: enable pwm-fan as a loadable module
.../bindings/pwm/pwm-tegra-tachometer.txt | 31 +++
arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts | 5 +
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 28 ++
arch/arm64/configs/defconfig | 2 +
drivers/hwmon/pwm-fan.c | 23 ++
drivers/pwm/Kconfig | 10 +
drivers/pwm/Makefile | 1 +
drivers/pwm/core.c | 21 +-
drivers/pwm/pwm-tegra-tachometer.c | 303 +++++++++++++++++++++
9 files changed, 418 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt
create mode 100644 drivers/pwm/pwm-tegra-tachometer.c
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V2 4/9] arm64: tegra: Add Tachometer Controller on Tegra186
From: Rajkumar Rampelli @ 2018-03-21 4:40 UTC (permalink / raw)
To: robh+dt, mark.rutland, thierry.reding, jonathanh, jdelvare, linux,
corbet, catalin.marinas, will.deacon, kstewart, gregkh,
pombredanne, mmaddireddy, mperttunen, arnd, timur, andy.gross,
xuwei5, elder, heiko, krzk, ard.biesheuvel
Cc: devicetree, linux-kernel, linux-pwm, linux-tegra, linux-hwmon,
linux-doc, linux-arm-kernel, ldewangan, rrajk
In-Reply-To: <1521607244-29734-1-git-send-email-rrajk@nvidia.com>
The NVIDIA Tegra186 SoC has a Tachometer Controller that analyzes the
PWM signal of a Fan and reports the period value through pwm interface.
Signed-off-by: Rajkumar Rampelli <rrajk@nvidia.com>
---
V2: Renamed clock-names/reset-names dt properties values to "tachometer"
Renamed compatible property value to "nvidia-tegra186-pwm-tachometer"
arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts | 5 +++++
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 11 +++++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts b/arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts
index bd5305a..13c3e59 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra186-p2771-0000.dts
@@ -172,4 +172,9 @@
vin-supply = <&vdd_5v0_sys>;
};
};
+
+ tachometer@39c0000 {
+ nvidia,pulse-per-rev = <2>;
+ nvidia,capture-window-len = <2>;
+ };
};
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 731cd01..19e1afc 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1042,4 +1042,15 @@
reset-names = "pwm";
status = "disabled";
};
+
+ tegra_tachometer: tachometer@39c0000 {
+ compatible = "nvidia,tegra186-pwm-tachometer";
+ reg = <0x0 0x039c0000 0x0 0x10>;
+ #pwm-cells = <2>;
+ clocks = <&bpmp TEGRA186_CLK_TACH>;
+ clock-names = "tachometer";
+ resets = <&bpmp TEGRA186_RESET_TACH>;
+ reset-names = "tachometer";
+ status = "disabled";
+ };
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 3/9] dt-bindings: Tegra186 tachometer device tree bindings
From: Rajkumar Rampelli @ 2018-03-21 4:40 UTC (permalink / raw)
To: robh+dt, mark.rutland, thierry.reding, jonathanh, jdelvare, linux,
corbet, catalin.marinas, will.deacon, kstewart, gregkh,
pombredanne, mmaddireddy, mperttunen, arnd, timur, andy.gross,
xuwei5, elder, heiko, krzk, ard.biesheuvel
Cc: devicetree, linux-kernel, linux-pwm, linux-tegra, linux-hwmon,
linux-doc, linux-arm-kernel, ldewangan, rrajk
In-Reply-To: <1521607244-29734-1-git-send-email-rrajk@nvidia.com>
Supply Device tree binding documentation for the NVIDIA
Tegra186 SoC's Tachometer Controller
Signed-off-by: Rajkumar Rampelli <rrajk@nvidia.com>
---
V2: Renamed compatible string to "nvidia,tegra186-pwm-tachometer"
Renamed dt property values of clock-names and reset-names to "tachometer"
from "tach"
.../bindings/pwm/pwm-tegra-tachometer.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt b/Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt
new file mode 100644
index 0000000..4a7ead4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt
@@ -0,0 +1,31 @@
+Bindings for a PWM based Tachometer driver
+
+Required properties:
+- compatible: Must be "nvidia,tegra186-pwm-tachometer"
+- reg: physical base addresses of the controller and length of
+ memory mapped region.
+- #pwm-cells: should be 2. See pwm.txt in this directory for a
+ description of the cells format.
+- clocks: phandle list of tachometer clocks
+- clock-names: should be "tachometer". See clock-bindings.txt in documentations
+- resets: phandle to the reset controller for the Tachometer IP
+- reset-names: should be "tachometer". See reset.txt in documentations
+- nvidia,pulse-per-rev: Integer, pulses per revolution of a Fan. This value
+ obtained from Fan specification document.
+- nvidia,capture-window-len: Integer, window of the Fan Tach monitor, it indicates
+ that how many period of the input fan tach signal will the FAN TACH logic
+ monitor. Valid values are 1, 2, 4 and 8 only.
+
+Example:
+ tegra_tachometer: tachometer@39c0000 {
+ compatible = "nvidia,tegra186-pwm-tachometer";
+ reg = <0x0 0x039c0000 0x0 0x10>;
+ #pwm-cells = <2>;
+ clocks = <&tegra_car TEGRA186_CLK_TACH>;
+ clock-names = "tachometer";
+ resets = <&tegra_car TEGRA186_RESET_TACH>;
+ reset-names = "tachometer";
+ nvidia,pulse-per-rev = <2>;
+ nvidia,capture-window-len = <2>;
+ status = "disabled";
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 2/9] arm64: tegra: Add PWM controller on Tegra186 soc
From: Rajkumar Rampelli @ 2018-03-21 4:40 UTC (permalink / raw)
To: robh+dt, mark.rutland, thierry.reding, jonathanh, jdelvare, linux,
corbet, catalin.marinas, will.deacon, kstewart, gregkh,
pombredanne, mmaddireddy, mperttunen, arnd, timur, andy.gross,
xuwei5, elder, heiko, krzk, ard.biesheuvel
Cc: devicetree, linux-kernel, linux-pwm, linux-tegra, linux-hwmon,
linux-doc, linux-arm-kernel, ldewangan, rrajk
In-Reply-To: <1521607244-29734-1-git-send-email-rrajk@nvidia.com>
The NVIDIA Tegra186 SoC has a PWM controller which is
used in FAN control use case.
Signed-off-by: Rajkumar Rampelli <rrajk@nvidia.com>
---
V2: no changes in this patch
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index b762227..731cd01 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1031,4 +1031,15 @@
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
interrupt-parent = <&gic>;
};
+
+ pwm@c340000 {
+ compatible = "nvidia,tegra186-pwm";
+ reg = <0x0 0xc340000 0x0 0x10000>;
+ clocks = <&bpmp TEGRA186_CLK_PWM4>;
+ clock-names = "pwm";
+ #pwm-cells = <2>;
+ resets = <&bpmp TEGRA186_RESET_PWM4>;
+ reset-names = "pwm";
+ status = "disabled";
+ };
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 1/9] pwm: core: Add support for PWM HW driver with pwm capture only
From: Rajkumar Rampelli @ 2018-03-21 4:40 UTC (permalink / raw)
To: robh+dt, mark.rutland, thierry.reding, jonathanh, jdelvare, linux,
corbet, catalin.marinas, will.deacon, kstewart, gregkh,
pombredanne, mmaddireddy, mperttunen, arnd, timur, andy.gross,
xuwei5, elder, heiko, krzk, ard.biesheuvel
Cc: devicetree, linux-kernel, linux-pwm, linux-tegra, linux-hwmon,
linux-doc, linux-arm-kernel, ldewangan, rrajk
In-Reply-To: <1521607244-29734-1-git-send-email-rrajk@nvidia.com>
Add support for pwm HW driver which has only capture functionality.
This helps to implement the PWM based Tachometer driver which reads
the PWM output signals from electronic fans.
PWM Tachometer captures the period and duty cycle of the PWM signal
Add conditional checks for callabacks enable(), disable(), config()
to check if they are supported by the client driver or not. Skip these
callbacks if they are not supported.
Signed-off-by: Rajkumar Rampelli <rrajk@nvidia.com>
---
V2: Added if conditional checks for pwm callbacks since drivers may
implements only pwm capture functionality.
drivers/pwm/core.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 1581f6a..f70fe68 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -246,6 +246,10 @@ static bool pwm_ops_check(const struct pwm_ops *ops)
if (ops->apply)
return true;
+ /* driver supports capture operation */
+ if (ops->capture)
+ return true;
+
return false;
}
@@ -495,7 +499,8 @@ int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state)
* ->apply().
*/
if (pwm->state.enabled) {
- pwm->chip->ops->disable(pwm->chip, pwm);
+ if (pwm->chip->ops->disable)
+ pwm->chip->ops->disable(pwm->chip, pwm);
pwm->state.enabled = false;
}
@@ -509,22 +514,26 @@ int pwm_apply_state(struct pwm_device *pwm, struct pwm_state *state)
if (state->period != pwm->state.period ||
state->duty_cycle != pwm->state.duty_cycle) {
- err = pwm->chip->ops->config(pwm->chip, pwm,
+ if (pwm->chip->ops->config) {
+ err = pwm->chip->ops->config(pwm->chip, pwm,
state->duty_cycle,
state->period);
- if (err)
- return err;
+ if (err)
+ return err;
+ }
pwm->state.duty_cycle = state->duty_cycle;
pwm->state.period = state->period;
}
if (state->enabled != pwm->state.enabled) {
- if (state->enabled) {
+ if (state->enabled && pwm->chip->ops->enable) {
err = pwm->chip->ops->enable(pwm->chip, pwm);
if (err)
return err;
- } else {
+ }
+
+ if (!state->enabled && pwm->chip->ops->disable) {
pwm->chip->ops->disable(pwm->chip, pwm);
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 9/9] arm64: defconfig: enable pwm-fan as a loadable module
From: Rajkumar Rampelli @ 2018-03-21 4:40 UTC (permalink / raw)
To: robh+dt, mark.rutland, thierry.reding, jonathanh, jdelvare, linux,
corbet, catalin.marinas, will.deacon, kstewart, gregkh,
pombredanne, mmaddireddy, mperttunen, arnd, timur, andy.gross,
xuwei5, elder, heiko, krzk, ard.biesheuvel
Cc: devicetree, linux-kernel, linux-pwm, linux-tegra, linux-hwmon,
linux-doc, linux-arm-kernel, ldewangan, rrajk
In-Reply-To: <1521607244-29734-1-git-send-email-rrajk@nvidia.com>
Enable pwm-fan driver to make use of a PWM interface to
read speed of a fan in rotations per minute.
Signed-off-by: Rajkumar Rampelli <rrajk@nvidia.com>
---
V2: Added pwm-fan driver support as a loadable module.
Removed generic-pwm-tachometer driver support which was added as part of v1
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8b2bda7..50aa3bce 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -320,6 +320,7 @@ CONFIG_SYSCON_REBOOT_MODE=y
CONFIG_BATTERY_BQ27XXX=y
CONFIG_SENSORS_ARM_SCPI=y
CONFIG_SENSORS_LM90=m
+CONFIG_SENSORS_PWM_FAN=m
CONFIG_SENSORS_INA2XX=m
CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
CONFIG_CPU_THERMAL=y
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 8/9] arm64: defconfig: enable Nvidia Tegra Tachometer as a module
From: Rajkumar Rampelli @ 2018-03-21 4:40 UTC (permalink / raw)
To: robh+dt, mark.rutland, thierry.reding, jonathanh, jdelvare, linux,
corbet, catalin.marinas, will.deacon, kstewart, gregkh,
pombredanne, mmaddireddy, mperttunen, arnd, timur, andy.gross,
xuwei5, elder, heiko, krzk, ard.biesheuvel
Cc: devicetree, linux-kernel, linux-pwm, linux-tegra, linux-hwmon,
linux-doc, linux-arm-kernel, ldewangan, rrajk
In-Reply-To: <1521607244-29734-1-git-send-email-rrajk@nvidia.com>
Tegra Tachometer driver implements PWM capture to measure
period. Enable this driver as a module in the ARM64 defconfig.
Signed-off-by: Rajkumar Rampelli <rrajk@nvidia.com>
---
V2: No changes in this patch
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 634b373..8b2bda7 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -550,6 +550,7 @@ CONFIG_PWM_MESON=m
CONFIG_PWM_ROCKCHIP=y
CONFIG_PWM_SAMSUNG=y
CONFIG_PWM_TEGRA=m
+CONFIG_PWM_TEGRA_TACHOMETER=m
CONFIG_PHY_RCAR_GEN3_USB2=y
CONFIG_PHY_HI6220_USB=y
CONFIG_PHY_QCOM_USB_HS=y
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 7/9] hwmon: pwm-fan: add sysfs node to read rpm of fan
From: Rajkumar Rampelli @ 2018-03-21 4:40 UTC (permalink / raw)
To: robh+dt, mark.rutland, thierry.reding, jonathanh, jdelvare, linux,
corbet, catalin.marinas, will.deacon, kstewart, gregkh,
pombredanne, mmaddireddy, mperttunen, arnd, timur, andy.gross,
xuwei5, elder, heiko, krzk, ard.biesheuvel
Cc: devicetree, linux-kernel, linux-pwm, linux-tegra, linux-hwmon,
linux-doc, linux-arm-kernel, ldewangan, rrajk
In-Reply-To: <1521607244-29734-1-git-send-email-rrajk@nvidia.com>
Add fan device attribute fan1_input in pwm-fan driver
to read speed of fan in rotations per minute.
Signed-off-by: Rajkumar Rampelli <rrajk@nvidia.com>
---
V2: Removed generic-pwm-tachometer driver and using pwm-fan driver as per suggestions
to read fan speed.
Added fan device attribute to report speed of fan in rpms through hwmon sysfs.
drivers/hwmon/pwm-fan.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 70cc0d1..8dda209 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -98,11 +98,34 @@ static ssize_t show_pwm(struct device *dev,
return sprintf(buf, "%u\n", ctx->pwm_value);
}
+static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct pwm_fan_ctx *ptt = dev_get_drvdata(dev);
+ struct pwm_device *pwm = ptt->pwm;
+ struct pwm_capture result;
+ unsigned int rpm = 0;
+ int ret;
+
+ ret = pwm_capture(pwm, &result, 0);
+ if (ret < 0) {
+ pr_err("Failed to capture PWM: %d\n", ret);
+ return ret;
+ }
+
+ if (result.period)
+ rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+ result.period);
+
+ return sprintf(buf, "%u\n", rpm);
+}
static SENSOR_DEVICE_ATTR(pwm1, S_IRUGO | S_IWUSR, show_pwm, set_pwm, 0);
+static SENSOR_DEVICE_ATTR(fan1_input, 0444, show_rpm, NULL, 0);
static struct attribute *pwm_fan_attrs[] = {
&sensor_dev_attr_pwm1.dev_attr.attr,
+ &sensor_dev_attr_fan1_input.dev_attr.attr,
NULL,
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 5/9] pwm: tegra: Add PWM based Tachometer driver
From: Rajkumar Rampelli @ 2018-03-21 4:40 UTC (permalink / raw)
To: robh+dt, mark.rutland, thierry.reding, jonathanh, jdelvare, linux,
corbet, catalin.marinas, will.deacon, kstewart, gregkh,
pombredanne, mmaddireddy, mperttunen, arnd, timur, andy.gross,
xuwei5, elder, heiko, krzk, ard.biesheuvel
Cc: devicetree, linux-kernel, linux-pwm, linux-tegra, linux-hwmon,
linux-doc, linux-arm-kernel, ldewangan, rrajk
In-Reply-To: <1521607244-29734-1-git-send-email-rrajk@nvidia.com>
PWM Tachometer driver capture the PWM signal which is output of FAN
in general and provide the period of PWM signal which is converted to
RPM by SW.
Add Tegra Tachometer driver which implements the pwm-capture to
measure period.
Signed-off-by: Rajkumar Rampelli <rrajk@nvidia.com>
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
---
V2: Renamed compatible string to "nvidia-tegra186-pwm-tachometer"
Renamed arguments of reset and clk apis to "tachometer" from "tach"
drivers/pwm/Kconfig | 10 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-tegra-tachometer.c | 303 +++++++++++++++++++++++++++++++++++++
3 files changed, 314 insertions(+)
create mode 100644 drivers/pwm/pwm-tegra-tachometer.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 763ee50..29aeeeb 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -454,6 +454,16 @@ config PWM_TEGRA
To compile this driver as a module, choose M here: the module
will be called pwm-tegra.
+config PWM_TEGRA_TACHOMETER
+ tristate "NVIDIA Tegra Tachometer PWM driver"
+ depends on ARCH_TEGRA
+ help
+ NVIDIA Tegra Tachometer reads the PWM signal and reports the PWM
+ signal periods. This helps in measuring the fan speed where Fan
+ output for speed is PWM signal.
+
+ This driver support the Tachometer driver in PWM framework.
+
config PWM_TIECAP
tristate "ECAP PWM support"
depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX || ARCH_KEYSTONE
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 0258a74..14c183e 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_PWM_STM32_LP) += pwm-stm32-lp.o
obj-$(CONFIG_PWM_STMPE) += pwm-stmpe.o
obj-$(CONFIG_PWM_SUN4I) += pwm-sun4i.o
obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o
+obj-$(CONFIG_PWM_TEGRA_TACHOMETER) += pwm-tegra-tachometer.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
obj-$(CONFIG_PWM_TIPWMSS) += pwm-tipwmss.o
diff --git a/drivers/pwm/pwm-tegra-tachometer.c b/drivers/pwm/pwm-tegra-tachometer.c
new file mode 100644
index 0000000..bcc44ce
--- /dev/null
+++ b/drivers/pwm/pwm-tegra-tachometer.c
@@ -0,0 +1,303 @@
+/*
+ * Tegra Tachometer Pulse-Width-Modulation driver
+ *
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pwm.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+
+/* Since oscillator clock (38.4MHz) serves as a clock source for
+ * the tach input controller, 1.0105263MHz (i.e. 38.4/38) has to be
+ * used as a clock value in the RPM calculations
+ */
+#define TACH_COUNTER_CLK 1010526
+
+#define TACH_FAN_TACH0 0x0
+#define TACH_FAN_TACH0_PERIOD_MASK 0x7FFFF
+#define TACH_FAN_TACH0_PERIOD_MAX 0x7FFFF
+#define TACH_FAN_TACH0_PERIOD_MIN 0x0
+#define TACH_FAN_TACH0_WIN_LENGTH_SHIFT 25
+#define TACH_FAN_TACH0_WIN_LENGTH_MASK 0x3
+#define TACH_FAN_TACH0_OVERFLOW_MASK BIT(24)
+
+#define TACH_FAN_TACH1 0x4
+#define TACH_FAN_TACH1_HI_MASK 0x7FFFF
+/*
+ * struct pwm_tegra_tach - Tegra tachometer object
+ * @dev: device providing the Tachometer
+ * @pulse_per_rev: Pulses per revolution of a Fan
+ * @capture_window_len: Defines the window of the FAN TACH monitor
+ * @regs: physical base addresses of the controller
+ * @clk: phandle list of tachometer clocks
+ * @rst: phandle to reset the controller
+ * @chip: PWM chip providing this PWM device
+ */
+struct pwm_tegra_tach {
+ struct device *dev;
+ void __iomem *regs;
+ struct clk *clk;
+ struct reset_control *rst;
+ u32 pulse_per_rev;
+ u32 capture_window_len;
+ struct pwm_chip chip;
+};
+
+static struct pwm_tegra_tach *to_tegra_pwm_chip(struct pwm_chip *chip)
+{
+ return container_of(chip, struct pwm_tegra_tach, chip);
+}
+
+static u32 tachometer_readl(struct pwm_tegra_tach *ptt, unsigned long reg)
+{
+ return readl(ptt->regs + reg);
+}
+
+static inline void tachometer_writel(struct pwm_tegra_tach *ptt, u32 val,
+ unsigned long reg)
+{
+ writel(val, ptt->regs + reg);
+}
+
+static int pwm_tegra_tach_set_wlen(struct pwm_tegra_tach *ptt,
+ u32 window_length)
+{
+ u32 tach0, wlen;
+
+ /*
+ * As per FAN Spec, the window length value should be greater than or
+ * equal to Pulses Per Revolution value to measure the time period
+ * values accurately.
+ */
+ if (ptt->pulse_per_rev > ptt->capture_window_len) {
+ dev_err(ptt->dev,
+ "Window length value < pulses per revolution value\n");
+ return -EINVAL;
+ }
+
+ if (hweight8(window_length) != 1) {
+ dev_err(ptt->dev,
+ "Valid value of window length is {1, 2, 4 or 8}\n");
+ return -EINVAL;
+ }
+
+ wlen = ffs(window_length) - 1;
+ tach0 = tachometer_readl(ptt, TACH_FAN_TACH0);
+ tach0 &= ~(TACH_FAN_TACH0_WIN_LENGTH_MASK <<
+ TACH_FAN_TACH0_WIN_LENGTH_SHIFT);
+ tach0 |= wlen << TACH_FAN_TACH0_WIN_LENGTH_SHIFT;
+ tachometer_writel(ptt, tach0, TACH_FAN_TACH0);
+
+ return 0;
+}
+
+static int pwm_tegra_tach_capture(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ struct pwm_capture *result,
+ unsigned long timeout)
+{
+ struct pwm_tegra_tach *ptt = to_tegra_pwm_chip(chip);
+ unsigned long period;
+ u32 tach;
+
+ tach = tachometer_readl(ptt, TACH_FAN_TACH1);
+ result->duty_cycle = tach & TACH_FAN_TACH1_HI_MASK;
+
+ tach = tachometer_readl(ptt, TACH_FAN_TACH0);
+ if (tach & TACH_FAN_TACH0_OVERFLOW_MASK) {
+ /* Fan is stalled, clear overflow state by writing 1 */
+ dev_dbg(ptt->dev, "Tachometer Overflow is detected\n");
+ tachometer_writel(ptt, tach, TACH_FAN_TACH0);
+ }
+
+ period = tach & TACH_FAN_TACH0_PERIOD_MASK;
+ if ((period == TACH_FAN_TACH0_PERIOD_MIN) ||
+ (period == TACH_FAN_TACH0_PERIOD_MAX)) {
+ dev_dbg(ptt->dev, "Period set to min/max 0x%lx, Invalid RPM\n",
+ period);
+ result->period = 0;
+ result->duty_cycle = 0;
+ return 0;
+ }
+
+ period = period + 1;
+
+ period = DIV_ROUND_CLOSEST_ULL(period * ptt->pulse_per_rev * 1000000ULL,
+ ptt->capture_window_len *
+ TACH_COUNTER_CLK);
+
+ /*
+ * period & duty cycle values are in units of micro seconds.
+ * Hence, convert them into nano seconds and store.
+ */
+ result->period = period * 1000;
+ result->duty_cycle = result->duty_cycle * 1000;
+
+ return 0;
+}
+
+static const struct pwm_ops pwm_tegra_tach_ops = {
+ .capture = pwm_tegra_tach_capture,
+ .owner = THIS_MODULE,
+};
+
+static int pwm_tegra_tach_read_platform_data(struct pwm_tegra_tach *ptt)
+{
+ struct device_node *np = ptt->dev->of_node;
+ u32 pval;
+ int err = 0;
+
+ err = of_property_read_u32(np, "nvidia,pulse-per-rev", &pval);
+ if (err < 0) {
+ dev_err(ptt->dev,
+ "\"nvidia,pulse-per-rev\" property is missing\n");
+ return err;
+ }
+ ptt->pulse_per_rev = pval;
+
+ err = of_property_read_u32(np, "nvidia,capture-window-len", &pval);
+ if (err < 0) {
+ dev_err(ptt->dev,
+ "\"nvidia,capture-window-len\" property is missing\n");
+ return err;
+ }
+ ptt->capture_window_len = pval;
+
+ return err;
+}
+
+static int pwm_tegra_tach_probe(struct platform_device *pdev)
+{
+ struct pwm_tegra_tach *ptt;
+ struct resource *res;
+ int err = 0;
+
+ ptt = devm_kzalloc(&pdev->dev, sizeof(*ptt), GFP_KERNEL);
+ if (!ptt)
+ return -ENOMEM;
+
+ ptt->dev = &pdev->dev;
+
+ err = pwm_tegra_tach_read_platform_data(ptt);
+ if (err < 0)
+ return err;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ ptt->regs = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(ptt->regs)) {
+ dev_err(&pdev->dev, "Failed to remap I/O memory\n");
+ return PTR_ERR(ptt->regs);
+ }
+
+ platform_set_drvdata(pdev, ptt);
+
+ ptt->clk = devm_clk_get(&pdev->dev, "tachometer");
+ if (IS_ERR(ptt->clk)) {
+ err = PTR_ERR(ptt->clk);
+ dev_err(&pdev->dev, "Failed to get Tachometer clk: %d\n", err);
+ return err;
+ }
+
+ ptt->rst = devm_reset_control_get(&pdev->dev, "tachometer");
+ if (IS_ERR(ptt->rst)) {
+ err = PTR_ERR(ptt->rst);
+ dev_err(&pdev->dev, "Failed to get reset handle: %d\n", err);
+ return err;
+ }
+
+ err = clk_prepare_enable(ptt->clk);
+ if (err < 0) {
+ dev_err(&pdev->dev, "Failed to prepare clock: %d\n", err);
+ return err;
+ }
+
+ err = clk_set_rate(ptt->clk, TACH_COUNTER_CLK);
+ if (err < 0) {
+ dev_err(&pdev->dev, "Failed to set clock rate %d: %d\n",
+ TACH_COUNTER_CLK, err);
+ goto clk_unprep;
+ }
+
+ reset_control_reset(ptt->rst);
+
+ ptt->chip.dev = &pdev->dev;
+ ptt->chip.ops = &pwm_tegra_tach_ops;
+ ptt->chip.base = -1;
+ ptt->chip.npwm = 1;
+
+ err = pwmchip_add(&ptt->chip);
+ if (err < 0) {
+ dev_err(&pdev->dev, "Failed to add tachometer PWM: %d\n", err);
+ goto reset_assert;
+ }
+
+ err = pwm_tegra_tach_set_wlen(ptt, ptt->capture_window_len);
+ if (err < 0) {
+ dev_err(ptt->dev, "Failed to set window length: %d\n", err);
+ goto pwm_remove;
+ }
+
+ return 0;
+
+pwm_remove:
+ pwmchip_remove(&ptt->chip);
+
+reset_assert:
+ reset_control_assert(ptt->rst);
+
+clk_unprep:
+ clk_disable_unprepare(ptt->clk);
+
+ return err;
+}
+
+static int pwm_tegra_tach_remove(struct platform_device *pdev)
+{
+ struct pwm_tegra_tach *ptt = platform_get_drvdata(pdev);
+
+ reset_control_assert(ptt->rst);
+
+ clk_disable_unprepare(ptt->clk);
+
+ return pwmchip_remove(&ptt->chip);
+}
+
+static const struct of_device_id pwm_tegra_tach_of_match[] = {
+ { .compatible = "nvidia,tegra186-pwm-tachometer" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, pwm_tegra_tach_of_match);
+
+static struct platform_driver tegra_tach_driver = {
+ .driver = {
+ .name = "pwm-tegra-tachometer",
+ .of_match_table = pwm_tegra_tach_of_match,
+ },
+ .probe = pwm_tegra_tach_probe,
+ .remove = pwm_tegra_tach_remove,
+};
+
+module_platform_driver(tegra_tach_driver);
+
+MODULE_DESCRIPTION("PWM based NVIDIA Tegra Tachometer driver");
+MODULE_AUTHOR("Rajkumar Rampelli <rrajk@nvidia.com>");
+MODULE_AUTHOR("Laxman Dewangan <ldewangan@nvidia.com>");
+MODULE_LICENSE("GPL v2");
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v4 6/6] arm64: dts: sdm845: Add I2C controller support
From: Doug Anderson @ 2018-03-21 3:47 UTC (permalink / raw)
To: Sagar Dharia
Cc: Karthikeyan Ramasubramanian, Jonathan Corbet, Andy Gross,
David Brown, Rob Herring, Mark Rutland, Wolfram Sang,
Greg Kroah-Hartman, linux-doc, linux-arm-msm, devicetree,
linux-i2c, linux-serial, Jiri Slaby, evgreen, acourbot, swboyd,
Bjorn Andersson
In-Reply-To: <c9e6f964-4e84-a5ed-77c4-e0a6655ee146@codeaurora.org>
Hi,
On Tue, Mar 20, 2018 at 3:16 PM, Sagar Dharia <sdharia@codeaurora.org> wrote:
>>>>> + pinconf {
>>>>> + pins = "gpio55", "gpio56";
>>>>> + drive-strength = <2>;
>>>>> + bias-disable;
>>>>> + };
>>>>> + };
>>>>> +
>>>>> + qup-i2c10-sleep {
>>>>> + pinconf {
>>>>> + pins = "gpio55", "gpio56";
>>>>> + bias-pull-up;
>>>>
>>>> Are you sure that you want pullups enabled for sleep here? There are
>>>> external pulls on this line (as there are on many i2c busses) so doing
>>>> this will double-enable pulls. It probably won't hurt, but I'm
>>>> curious if there's some sort of reason here.
>>>>
>>> 1. We need the lines to remain high to avoid slaves sensing a false
>>> start-condition (this can happen if the SDA goes down before SCL).
>>> 2. Disclaimer: I'm not a HW expert, but we were told that
>>> tri-state/bias-disabled lines can draw more current. I will find out
>>> more about that.
>>
>> Agreed that they need to remain high, but you've got very strong
>> pullups external to the SoC. Those will keep it high. You don't need
>> the internal ones too.
>>
>> As extra evidence that the external pullups _must_ be present on your
>> board: you specify bias-disable in the active state. That can only
>> work if there are external pullups (or if there were some special
>> extra secret internal pullups that were part of geni). i2c is an
>> open-drain bus and thus there must be pullups on the bus in order to
>> communicate.
>>
>
> You are right, I followed up about the pull-up recommendation and that
> was for a GPIO where there was no external pull-up (GPIO was not used
> for I2C). It's safe to assume I2C will always have external pullup.
It is even more safe to say that I2C will always have an external
pullup on the SDM845-MTP. Remember that the pullup config is in the
board device tree file, not the SoC one. So even if someone out there
decides that the internal pull is somehow good enough for their own
board and they don't stuff external ones, then it will be up to them
to turn the pull up on in their own board file.
> We
> will change sleep-config of I2C GPIOs to no-pull.
Even better IMHO: don't specify the bias in the sleep config. I don't
believe it's possible for the sleep config to take effect without the
default config since the default config applies at probe time. ...so
you'll always get the default config applied at probe time and you
don't need to touch the bias at sleep time.
>>>>> + i2c10: i2c@a88000 {
>>>>
>>>> Seems like it might be nice to add all the i2c busses into the main
>>>> sdm845.dtsi file. Sure, most won't be enabled, but it seems like it
>>>> would avoid churn later.
>>>>
>>>> ...if you're sure you want to add only one i2c controller, subject of
>>>> this patch should indicate that.
>>>>
>>>
>>> Yes, we typically have a "platform(sdm845 here)-qupv3.dtsi" defining
>>> most of the serial-bus instances (i2c, spi, and uart with
>>> status=disabled) that we include from the common header. The boards
>>> enable instances they need.
>>> Will that be okay?
>>
>> Unless you really feel the need to put these in a separate file I'd
>> just put them straight in sdm845.dtsi. Yeah, it'll get big, but
>> that's OK by me. I _think_ this matches what Bjorn was suggesting on
>> previous device tree patches, but CCing him just in case. I'm
>> personally OK with whatever Bjorn and other folks with more Qualcomm
>> history would like.
>>
>> ...but yeah, I'm asking for them all to be listed with status="disabled".
>>
>
> Sure, we will change the subject of this patch to indicate that we are
> adding 1 controller as of now. Later we will add all I2C controllers to
> dtsi as another patch since that will need pinctrl settings for GPIOs
> used by those instances and the wrappers devices needed by them.
Yeah, it's fine to just change the subject of this patch. It would be
nice to add all the other controllers in sooner rather than later, but
it doesn't have to be today.
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 4/6] tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP
From: Evan Green @ 2018-03-21 0:18 UTC (permalink / raw)
To: Karthikeyan Ramasubramanian
Cc: Jonathan Corbet, Andy Gross, David Brown, robh+dt, mark.rutland,
wsa, gregkh, linux-doc, linux-arm-msm, devicetree, linux-i2c,
linux-serial, jslaby, acourbot, swboyd, Girish Mahadevan,
Sagar Dharia, Doug Anderson
In-Reply-To: <1fa9262a-28bf-8432-5672-4f8c09898493@codeaurora.org>
On Tue, Mar 20, 2018 at 4:44 PM Karthik Ramasubramanian <
kramasub@codeaurora.org> wrote:
> On 3/20/2018 12:39 PM, Evan Green wrote:
> > Hi Karthik,
> >
> > On Wed, Mar 14, 2018 at 4:59 PM Karthikeyan Ramasubramanian <
> > kramasub@codeaurora.org> wrote:
> >
> >> +
> >> +static bool qcom_geni_serial_poll_bit(struct uart_port *uport,
> >> + int offset, int field, bool set)
> >> +{
> >> + u32 reg;
> >> + struct qcom_geni_serial_port *port;
> >> + unsigned int baud;
> >> + unsigned int fifo_bits;
> >> + unsigned long timeout_us = 20000;
> >> +
> >> + /* Ensure polling is not re-ordered before the prior
writes/reads
> > */
> >> + mb();
> >
> > These barriers sprinkled around everywhere are new. Did
> > you find that you needed them for something? In this case, the
> > readl_poll_timeout_atomic should already have a read barrier (nor do you
> > probably care about read reordering, right?) Perhaps this should
> > only be a mmiowb rather than a full barrier, because you really just
want
> > to say "make sure all my old writes got out to hardware before spinning"
> These barriers have been there from v3. Regarding this barrier - since
> readl_poll_timeout_atomic has a read barrier, this one can be converted
> to just write barrier.
Thanks. I must have missed them in v3. Is that mmiowb that would go there,
or wmb? I'm unsure.
> >
> >> +
> >> + if (uport->private_data) {
> >> + port = to_dev_port(uport, uport);
> >> + baud = port->baud;
> >> + if (!baud)
> >> + baud = 115200;
> >> + fifo_bits = port->tx_fifo_depth * port->tx_fifo_width;
> >> + /*
> >> + * Total polling iterations based on FIFO worth of
bytes
> > to be
> >> + * sent at current baud. Add a little fluff to the
wait.
> >> + */
> >> + timeout_us = ((fifo_bits * USEC_PER_SEC) / baud) + 500;
> >> + }
> >> +
> >> + return !readl_poll_timeout_atomic(uport->membase + offset, reg,
> >> + (bool)(reg & field) == set, 10, timeout_us);
> >> +}
> > [...]
> >> +
> >> +static void qcom_geni_serial_start_tx(struct uart_port *uport)
> >> +{
> >> + u32 irq_en;
> >> + struct qcom_geni_serial_port *port = to_dev_port(uport, uport);
> >> + u32 status;
> >> +
> >> + if (port->xfer_mode == GENI_SE_FIFO) {
> >> + status = readl_relaxed(uport->membase +
SE_GENI_STATUS);
> >> + if (status & M_GENI_CMD_ACTIVE)
> >> + return;
> >> +
> >> + if (!qcom_geni_serial_tx_empty(uport))
> >> + return;
> >> +
> >> + /*
> >> + * Ensure writing to IRQ_EN & watermark registers are
not
> >> + * re-ordered before checking the status of the Serial
> >> + * Engine and TX FIFO
> >> + */
> >> + mb();
> >
> > Here's another one. You should just be able to use a regular readl when
> > reading SE_GENI_STATUS and remove this barrier, since readl has an rmb
> > which orders your read of M_IRQ_EN below. I don't think you need to
worry
> > about the writes below going above the read above, since there's logic
in
> > between that needs the result of the read. Maybe that also saves you in
the
> > read case, too. Either way, this barrier seems heavy handed.
> Write to the watermark register does not have any dependency on the
> reads. Hence it can be re-ordered. But writing to that register alone
> without enabling the watermark interrupt will not have any impact. From
> that perspective, using readl while checking the GENI_STATUS is
> sufficient to maintain the required order. I will put a comment
> regarding the use of readl so that the reason is not lost.
Yes, I see what you mean, and without the branch I'd agree. My thinking
though was that you have a branch between the read and writes. So to
determine whether or not to even execute the writes, you must have
successfully evaluated the read, since program flow depends on it. I will
admit this is where my barrier knowledge gets fuzzy. Can speculative
execution perform register writes? (ie if that branch was guessed wrong
before the read actually completes, and then the writes happen before the
read? That seems like it couldn't possibly happen, as it would result in
weird spurious speculative writes to registers. Perhaps the mapping bits
prevent this sort of thing...)
If what I've said makes any sort of sense, and you still want to keep the
barriers here and below, then I'll let it go.
> >
> >> +
> >> + irq_en = readl_relaxed(uport->membase +
SE_GENI_M_IRQ_EN);
> >> + irq_en |= M_TX_FIFO_WATERMARK_EN | M_CMD_DONE_EN;
> >> +
> >> + writel_relaxed(port->tx_wm, uport->membase +
> >> +
SE_GENI_TX_WATERMARK_REG);
> >> + writel_relaxed(irq_en, uport->membase +
SE_GENI_M_IRQ_EN);
> >> + }
> >> +}
> >> +
> >> +static void qcom_geni_serial_stop_tx(struct uart_port *uport)
> >> +{
> >> + u32 irq_en;
> >> + u32 status;
> >> + struct qcom_geni_serial_port *port = to_dev_port(uport, uport);
> >> +
> >> + irq_en = readl_relaxed(uport->membase + SE_GENI_M_IRQ_EN);
> >> + irq_en &= ~M_CMD_DONE_EN;
> >> + if (port->xfer_mode == GENI_SE_FIFO) {
> >> + irq_en &= ~M_TX_FIFO_WATERMARK_EN;
> >> + writel_relaxed(0, uport->membase +
> >> + SE_GENI_TX_WATERMARK_REG);
> >> + }
> >> + port->xmit_size = 0;
> >> + writel_relaxed(irq_en, uport->membase + SE_GENI_M_IRQ_EN);
> >> + status = readl_relaxed(uport->membase + SE_GENI_STATUS);
> >> + /* Possible stop tx is called multiple times. */
> >> + if (!(status & M_GENI_CMD_ACTIVE))
> >> + return;
> >> +
> >> + /*
> >> + * Ensure cancel command write is not re-ordered before
checking
> >> + * the status of the Primary Sequencer.
> >> + */
> >> + mb();
> >
> > I don't see how what's stated in your comment could happen, as that
would
> > be a logic error. This barrier seems unneeded to me.
> Issuing a cancel command to the primary sequencer, makes the primary
> sequencer to go to inactive state. Even though they are 2 different
> registers, writing to one register impacts the other. From that
> perspective, we want to ensure that the order is maintained. Else if the
> cancel command goes through and then the GENI_STATUS is read, it might
> say that the primary sequencer is not active and the function might
> return prematurely. Same argument applies for the below mentioned cases.
> >
> >> +
> >> + geni_se_cancel_m_cmd(&port->se);
> >> + if (!qcom_geni_serial_poll_bit(uport, SE_GENI_M_IRQ_STATUS,
> >> + M_CMD_CANCEL_EN,
true)) {
> >> + geni_se_abort_m_cmd(&port->se);
> >> + qcom_geni_serial_poll_bit(uport, SE_GENI_M_IRQ_STATUS,
> >> + M_CMD_ABORT_EN, true);
> >> + writel_relaxed(M_CMD_ABORT_EN, uport->membase +
> >> +
> > SE_GENI_M_IRQ_CLEAR);
> >> + }
> >> + writel_relaxed(M_CMD_CANCEL_EN, uport->membase +
> > SE_GENI_M_IRQ_CLEAR);
> >> +}
> >> +
> >> +static void qcom_geni_serial_start_rx(struct uart_port *uport)
> >> +{
> >> + u32 irq_en;
> >> + u32 status;
> >> + struct qcom_geni_serial_port *port = to_dev_port(uport, uport);
> >> +
> >> + status = readl_relaxed(uport->membase + SE_GENI_STATUS);
> >> + if (status & S_GENI_CMD_ACTIVE)
> >> + qcom_geni_serial_stop_rx(uport);
> >> +
> >> + /*
> >> + * Ensure setup command write is not re-ordered before checking
> >> + * the status of the Secondary Sequencer.
> >> + */
> >> + mb();
> >
> > Also here, I think the reordering you're worried about would mean the
CPU
> > is executing incorrectly.
> >
> >> +
> >> + geni_se_setup_s_cmd(&port->se, UART_START_READ, 0);
> >> +
> >> + if (port->xfer_mode == GENI_SE_FIFO) {
> >> + irq_en = readl_relaxed(uport->membase +
SE_GENI_S_IRQ_EN);
> >> + irq_en |= S_RX_FIFO_WATERMARK_EN | S_RX_FIFO_LAST_EN;
> >> + writel_relaxed(irq_en, uport->membase +
SE_GENI_S_IRQ_EN);
> >> +
> >> + irq_en = readl_relaxed(uport->membase +
SE_GENI_M_IRQ_EN);
> >> + irq_en |= M_RX_FIFO_WATERMARK_EN | M_RX_FIFO_LAST_EN;
> >> + writel_relaxed(irq_en, uport->membase +
SE_GENI_M_IRQ_EN);
> >> + }
> >> +}
> >> +
> >> +static void qcom_geni_serial_stop_rx(struct uart_port *uport)
> >> +{
> >> + u32 irq_en;
> >> + u32 status;
> >> + struct qcom_geni_serial_port *port = to_dev_port(uport, uport);
> >> + u32 irq_clear = S_CMD_DONE_EN;
> >> +
> >> + if (port->xfer_mode == GENI_SE_FIFO) {
> >> + irq_en = readl_relaxed(uport->membase +
SE_GENI_S_IRQ_EN);
> >> + irq_en &= ~(S_RX_FIFO_WATERMARK_EN |
S_RX_FIFO_LAST_EN);
> >> + writel_relaxed(irq_en, uport->membase +
SE_GENI_S_IRQ_EN);
> >> +
> >> + irq_en = readl_relaxed(uport->membase +
SE_GENI_M_IRQ_EN);
> >> + irq_en &= ~(M_RX_FIFO_WATERMARK_EN |
M_RX_FIFO_LAST_EN);
> >> + writel_relaxed(irq_en, uport->membase +
SE_GENI_M_IRQ_EN);
> >> + }
> >> +
> >> + status = readl_relaxed(uport->membase + SE_GENI_STATUS);
> >> + /* Possible stop rx is called multiple times. */
> >> + if (!(status & S_GENI_CMD_ACTIVE))
> >> + return;
> >> +
> >> + /*
> >> + * Ensure cancel command write is not re-ordered before
checking
> >> + * the status of the Secondary Sequencer.
> >> + */
> >> + mb();
> >
> > Same deal here.
> >
> >> +
> >> + geni_se_cancel_s_cmd(&port->se);
> >> + qcom_geni_serial_poll_bit(uport, SE_GENI_S_CMD_CTRL_REG,
> >> + S_GENI_CMD_CANCEL, false);
> >> + status = readl_relaxed(uport->membase + SE_GENI_STATUS);
> >> + writel_relaxed(irq_clear, uport->membase +
SE_GENI_S_IRQ_CLEAR);
> >> + if (status & S_GENI_CMD_ACTIVE)
> >> + qcom_geni_serial_abort_rx(uport);
> >> +}
> >> +
> >
> > Sorry gmail decided to wrap some of the context lines.
> > -Evan
> > --
> > To unsubscribe from this list: send the line "unsubscribe
linux-arm-msm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> Regards,
> Karthik.
> --
> Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox