Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Mikko Perttunen]

On 02/28/2018 08:12 AM, Rajkumar Rampelli wrote:


On Wednesday 28 February 2018 11:28 AM, Guenter Roeck wrote:

On 02/27/2018 09:38 PM, Rajkumar Rampelli wrote:


On Wednesday 21 February 2018 08:20 PM, Guenter Roeck wrote:

On 02/20/2018 10:58 PM, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
  Documentation/hwmon/generic-pwm-tachometer |  17 +
  drivers/hwmon/Kconfig  |  10 +++
  drivers/hwmon/Makefile |   1 +
  drivers/hwmon/generic-pwm-tachometer.c | 112 
+

  4 files changed, 140 insertions(+)
  create mode 100644 Documentation/hwmon/generic-pwm-tachometer
  create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer

new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It 
uses the
+generic PWM interface and can be used on SoCs as along as the SoC 
supports

+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan 
speed using
+PWM module and Tachometer controller. It requests period value 
through PWM
+capture interface to Tachometer and measures the Rotations per 
minute using
+received period value. It exposes the Fan speed in RPM to the user 
space by

+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
    If you say yes here you get support for the temperature
    and power sensors for APM X-Gene SoC.
  +config GENERIC_PWM_TACHOMETER
+    tristate "Generic PWM based tachometer driver"
+    depends on PWM
+    help
+  Enables a driver to use PWM signal from motor to use
+  for measuring the motor speed. The RPM is captured by
+  PWM modules which has PWM capture capability and this
+  drivers reads the captured data from PWM IP to convert
+  it to speed in RPM.
+
  if ACPI
    comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)    += wm8350-hwmon.o
  obj-$(CONFIG_SENSORS_XGENE)    += xgene-hwmon.o
    obj-$(CONFIG_PMBUS)    += pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
    ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
  diff --git a/drivers/hwmon/generic-pwm-tachometer.c 
b/drivers/hwmon/generic-pwm-tachometer.c

new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pwm_hwmon_tach {
+    struct device    *dev;
+    struct pwm_device    *pwm;
+    struct device    *hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct 
device_attribute *attr,

+    char *buf)
+{
+    struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+    struct pwm_device *pwm = ptt->pwm;
+    struct pwm_capture result;
+    int err;
+    unsigned int rpm = 0;
+
+    err = pwm_capture(pwm, , 0);
+    if (err < 0) {
+    dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+    return err;
+    }
+
+    if (result.period)
+    rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+    result.period);
+
+    return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);
+
+static struct attribute *pwm_tach_attrs[] = {
+    _dev_attr_rpm.dev_attr.attr,
+    NULL,
+};


"rpm" is not a standard hwmon sysfs attribute. If you don't provide
a single 

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Rajkumar Rampelli]

On Wednesday 28 February 2018 11:28 AM, Guenter Roeck wrote:

On 02/27/2018 09:38 PM, Rajkumar Rampelli wrote:


On Wednesday 21 February 2018 08:20 PM, Guenter Roeck wrote:

On 02/20/2018 10:58 PM, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
  Documentation/hwmon/generic-pwm-tachometer |  17 +
  drivers/hwmon/Kconfig  |  10 +++
  drivers/hwmon/Makefile |   1 +
  drivers/hwmon/generic-pwm-tachometer.c | 112 
+

  4 files changed, 140 insertions(+)
  create mode 100644 Documentation/hwmon/generic-pwm-tachometer
  create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer

new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It 
uses the
+generic PWM interface and can be used on SoCs as along as the SoC 
supports

+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan 
speed using
+PWM module and Tachometer controller. It requests period value 
through PWM
+capture interface to Tachometer and measures the Rotations per 
minute using
+received period value. It exposes the Fan speed in RPM to the user 
space by

+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
If you say yes here you get support for the temperature
and power sensors for APM X-Gene SoC.
  +config GENERIC_PWM_TACHOMETER
+tristate "Generic PWM based tachometer driver"
+depends on PWM
+help
+  Enables a driver to use PWM signal from motor to use
+  for measuring the motor speed. The RPM is captured by
+  PWM modules which has PWM capture capability and this
+  drivers reads the captured data from PWM IP to convert
+  it to speed in RPM.
+
  if ACPI
comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)+= wm8350-hwmon.o
  obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o
obj-$(CONFIG_PMBUS)+= pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
  diff --git a/drivers/hwmon/generic-pwm-tachometer.c 
b/drivers/hwmon/generic-pwm-tachometer.c

new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pwm_hwmon_tach {
+struct device*dev;
+struct pwm_device*pwm;
+struct device*hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct 
device_attribute *attr,

+char *buf)
+{
+struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+struct pwm_device *pwm = ptt->pwm;
+struct pwm_capture result;
+int err;
+unsigned int rpm = 0;
+
+err = pwm_capture(pwm, , 0);
+if (err < 0) {
+dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+return err;
+}
+
+if (result.period)
+rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+result.period);
+
+return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);
+
+static struct attribute *pwm_tach_attrs[] = {
+_dev_attr_rpm.dev_attr.attr,
+NULL,
+};


"rpm" is not a standard hwmon sysfs attribute. If you don't provide
a single standard hwmon sysfs attribute, having a hwmon driver is 

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Guenter Roeck]

On 02/27/2018 09:38 PM, Rajkumar Rampelli wrote:


On Wednesday 21 February 2018 08:20 PM, Guenter Roeck wrote:

On 02/20/2018 10:58 PM, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
  Documentation/hwmon/generic-pwm-tachometer |  17 +
  drivers/hwmon/Kconfig  |  10 +++
  drivers/hwmon/Makefile |   1 +
  drivers/hwmon/generic-pwm-tachometer.c | 112 +
  4 files changed, 140 insertions(+)
  create mode 100644 Documentation/hwmon/generic-pwm-tachometer
  create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer
new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It uses the
+generic PWM interface and can be used on SoCs as along as the SoC supports
+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan speed using
+PWM module and Tachometer controller. It requests period value through PWM
+capture interface to Tachometer and measures the Rotations per minute using
+received period value. It exposes the Fan speed in RPM to the user space by
+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
    If you say yes here you get support for the temperature
    and power sensors for APM X-Gene SoC.
  +config GENERIC_PWM_TACHOMETER
+    tristate "Generic PWM based tachometer driver"
+    depends on PWM
+    help
+  Enables a driver to use PWM signal from motor to use
+  for measuring the motor speed. The RPM is captured by
+  PWM modules which has PWM capture capability and this
+  drivers reads the captured data from PWM IP to convert
+  it to speed in RPM.
+
  if ACPI
    comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)    += wm8350-hwmon.o
  obj-$(CONFIG_SENSORS_XGENE)    += xgene-hwmon.o
    obj-$(CONFIG_PMBUS)    += pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
    ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
  diff --git a/drivers/hwmon/generic-pwm-tachometer.c 
b/drivers/hwmon/generic-pwm-tachometer.c
new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pwm_hwmon_tach {
+    struct device    *dev;
+    struct pwm_device    *pwm;
+    struct device    *hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,
+    char *buf)
+{
+    struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+    struct pwm_device *pwm = ptt->pwm;
+    struct pwm_capture result;
+    int err;
+    unsigned int rpm = 0;
+
+    err = pwm_capture(pwm, , 0);
+    if (err < 0) {
+    dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+    return err;
+    }
+
+    if (result.period)
+    rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+    result.period);
+
+    return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);
+
+static struct attribute *pwm_tach_attrs[] = {
+    _dev_attr_rpm.dev_attr.attr,
+    NULL,
+};


"rpm" is not a standard hwmon sysfs attribute. If you don't provide
a single standard hwmon sysfs attribute, having a hwmon driver is pointless.

Guenter Roeck,
I will define a new hwmon sysfs attribute node called 

Re: [PATCH v2 6/6] kconfig: rename silentoldconfig to syncconfig

[Ulf Magnusson]

On Wed, Feb 28, 2018 at 6:41 AM, Ulf Magnusson  wrote:
> On Wed, Feb 28, 2018 at 09:15:26AM +0900, Masahiro Yamada wrote:
>> As commit cedd55d49dee ("kconfig: Remove silentoldconfig from help
>> and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a
>> historical misnomer.  That commit removed it from help and docs since
>> it is an internal interface.  If so, it should be allowed to rename
>> it to something more intuitive.  'syncconfig' is the one I came up
>> with because it updates the .config if necessary, then synchronize
>> other files with it.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> Changes in v2:
>>   - newly added
>>
>>  Documentation/kbuild/kconfig.txt |  2 +-
>>  Makefile |  2 +-
>>  scripts/kconfig/Makefile |  4 ++--
>>  scripts/kconfig/conf.c   | 20 ++--
>>  4 files changed, 14 insertions(+), 14 deletions(-)
>>
>> diff --git a/Documentation/kbuild/kconfig.txt 
>> b/Documentation/kbuild/kconfig.txt
>> index bbc99c0..7233118 100644
>> --- a/Documentation/kbuild/kconfig.txt
>> +++ b/Documentation/kbuild/kconfig.txt
>> @@ -119,7 +119,7 @@ Examples:
>>   15% of tristates will be set to 'y', 15% to 'm', 70% to 'n'
>>
>>  __
>> -Environment variables for 'silentoldconfig'
>> +Environment variables for 'syncconfig'
>>
>>  KCONFIG_NOSILENTUPDATE
>>  --
>> diff --git a/Makefile b/Makefile
>> index 8706bf2..ea23d9b 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -598,7 +598,7 @@ $(KCONFIG_CONFIG) include/config/auto.conf.cmd: ;
>>  # include/generated/ and include/config/. Update them if .config is newer 
>> than
>>  # include/config/auto.conf (which mirrors .config).
>>  include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
>> - $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
>> + $(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
>>  else
>>  # external modules needs include/generated/autoconf.h and 
>> include/config/auto.conf
>>  # but do not care if they are up-to-date. Use auto.conf to trigger the test
>> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
>> index bf9289a..988258a 100644
>> --- a/scripts/kconfig/Makefile
>> +++ b/scripts/kconfig/Makefile
>> @@ -3,7 +3,7 @@
>>  # Kernel configuration targets
>>  # These targets are used from top-level makefile
>>
>> -PHONY += xconfig gconfig menuconfig config silentoldconfig update-po-config 
>> \
>> +PHONY += xconfig gconfig menuconfig config syncconfig update-po-config \
>>   localmodconfig localyesconfig
>>
>>  ifdef KBUILD_KCONFIG
>> @@ -36,7 +36,7 @@ nconfig: $(obj)/nconf
>>
>>  # This has become an internal implementation detail and is now deprecated
>>  # for external use.
>> -silentoldconfig: $(obj)/conf
>> +syncconfig: $(obj)/conf
>>   $(Q)mkdir -p include/config include/generated
>>   $(Q)test -e include/generated/autoksyms.h || \
>>   touch   include/generated/autoksyms.h
>> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
>> index 11a4e45..4e08121 100644
>> --- a/scripts/kconfig/conf.c
>> +++ b/scripts/kconfig/conf.c
>> @@ -23,7 +23,7 @@ static void check_conf(struct menu *menu);
>>
>>  enum input_mode {
>>   oldaskconfig,
>> - silentoldconfig,
>> + syncconfig,
>>   oldconfig,
>>   allnoconfig,
>>   allyesconfig,
>> @@ -100,7 +100,7 @@ static int conf_askvalue(struct symbol *sym, const char 
>> *def)
>>
>>   switch (input_mode) {
>>   case oldconfig:
>> - case silentoldconfig:
>> + case syncconfig:
>>   if (sym_has_value(sym)) {
>>   printf("%s\n", def);
>>   return 0;
>> @@ -293,7 +293,7 @@ static int conf_choice(struct menu *menu)
>>   printf("[1-%d?]: ", cnt);
>>   switch (input_mode) {
>>   case oldconfig:
>> - case silentoldconfig:
>> + case syncconfig:
>>   if (!is_new) {
>>   cnt = def;
>>   printf("%d\n", cnt);
>> @@ -441,7 +441,7 @@ static void check_conf(struct menu *menu)
>>  static struct option long_opts[] = {
>>   {"oldaskconfig",no_argument,   NULL, oldaskconfig},
>>   {"oldconfig",   no_argument,   NULL, oldconfig},
>> - {"silentoldconfig", no_argument,   NULL, silentoldconfig},
>> + {"syncconfig",  no_argument,   NULL, syncconfig},
>>   {"defconfig",   optional_argument, NULL, defconfig},
>>   {"savedefconfig",   required_argument, NULL, savedefconfig},
>>   {"allnoconfig", no_argument,   NULL, allnoconfig},
>> @@ -468,8 +468,8 @@ static void conf_usage(const char *progname)
>>   printf("  --listnewconfig List new options\n");
>>   printf("  --oldaskconfig  Start a new 

Re: [PATCH v2 6/6] kconfig: rename silentoldconfig to syncconfig

[Ulf Magnusson]

On Wed, Feb 28, 2018 at 09:15:26AM +0900, Masahiro Yamada wrote:
> As commit cedd55d49dee ("kconfig: Remove silentoldconfig from help
> and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a
> historical misnomer.  That commit removed it from help and docs since
> it is an internal interface.  If so, it should be allowed to rename
> it to something more intuitive.  'syncconfig' is the one I came up
> with because it updates the .config if necessary, then synchronize
> other files with it.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
> Changes in v2:
>   - newly added
> 
>  Documentation/kbuild/kconfig.txt |  2 +-
>  Makefile |  2 +-
>  scripts/kconfig/Makefile |  4 ++--
>  scripts/kconfig/conf.c   | 20 ++--
>  4 files changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/Documentation/kbuild/kconfig.txt 
> b/Documentation/kbuild/kconfig.txt
> index bbc99c0..7233118 100644
> --- a/Documentation/kbuild/kconfig.txt
> +++ b/Documentation/kbuild/kconfig.txt
> @@ -119,7 +119,7 @@ Examples:
>   15% of tristates will be set to 'y', 15% to 'm', 70% to 'n'
>  
>  __
> -Environment variables for 'silentoldconfig'
> +Environment variables for 'syncconfig'
>  
>  KCONFIG_NOSILENTUPDATE
>  --
> diff --git a/Makefile b/Makefile
> index 8706bf2..ea23d9b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -598,7 +598,7 @@ $(KCONFIG_CONFIG) include/config/auto.conf.cmd: ;
>  # include/generated/ and include/config/. Update them if .config is newer 
> than
>  # include/config/auto.conf (which mirrors .config).
>  include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
> - $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> + $(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
>  else
>  # external modules needs include/generated/autoconf.h and 
> include/config/auto.conf
>  # but do not care if they are up-to-date. Use auto.conf to trigger the test
> diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
> index bf9289a..988258a 100644
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
> @@ -3,7 +3,7 @@
>  # Kernel configuration targets
>  # These targets are used from top-level makefile
>  
> -PHONY += xconfig gconfig menuconfig config silentoldconfig update-po-config \
> +PHONY += xconfig gconfig menuconfig config syncconfig update-po-config \
>   localmodconfig localyesconfig
>  
>  ifdef KBUILD_KCONFIG
> @@ -36,7 +36,7 @@ nconfig: $(obj)/nconf
>  
>  # This has become an internal implementation detail and is now deprecated
>  # for external use.
> -silentoldconfig: $(obj)/conf
> +syncconfig: $(obj)/conf
>   $(Q)mkdir -p include/config include/generated
>   $(Q)test -e include/generated/autoksyms.h || \
>   touch   include/generated/autoksyms.h
> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
> index 11a4e45..4e08121 100644
> --- a/scripts/kconfig/conf.c
> +++ b/scripts/kconfig/conf.c
> @@ -23,7 +23,7 @@ static void check_conf(struct menu *menu);
>  
>  enum input_mode {
>   oldaskconfig,
> - silentoldconfig,
> + syncconfig,
>   oldconfig,
>   allnoconfig,
>   allyesconfig,
> @@ -100,7 +100,7 @@ static int conf_askvalue(struct symbol *sym, const char 
> *def)
>  
>   switch (input_mode) {
>   case oldconfig:
> - case silentoldconfig:
> + case syncconfig:
>   if (sym_has_value(sym)) {
>   printf("%s\n", def);
>   return 0;
> @@ -293,7 +293,7 @@ static int conf_choice(struct menu *menu)
>   printf("[1-%d?]: ", cnt);
>   switch (input_mode) {
>   case oldconfig:
> - case silentoldconfig:
> + case syncconfig:
>   if (!is_new) {
>   cnt = def;
>   printf("%d\n", cnt);
> @@ -441,7 +441,7 @@ static void check_conf(struct menu *menu)
>  static struct option long_opts[] = {
>   {"oldaskconfig",no_argument,   NULL, oldaskconfig},
>   {"oldconfig",   no_argument,   NULL, oldconfig},
> - {"silentoldconfig", no_argument,   NULL, silentoldconfig},
> + {"syncconfig",  no_argument,   NULL, syncconfig},
>   {"defconfig",   optional_argument, NULL, defconfig},
>   {"savedefconfig",   required_argument, NULL, savedefconfig},
>   {"allnoconfig", no_argument,   NULL, allnoconfig},
> @@ -468,8 +468,8 @@ static void conf_usage(const char *progname)
>   printf("  --listnewconfig List new options\n");
>   printf("  --oldaskconfig  Start a new configuration using a 
> line-oriented program\n");
>   printf("  --oldconfig Update a configuration using a 
> provided .config as base\n");
> - printf("  

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Rajkumar Rampelli]

On Wednesday 21 February 2018 08:20 PM, Guenter Roeck wrote:

On 02/20/2018 10:58 PM, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
  Documentation/hwmon/generic-pwm-tachometer |  17 +
  drivers/hwmon/Kconfig  |  10 +++
  drivers/hwmon/Makefile |   1 +
  drivers/hwmon/generic-pwm-tachometer.c | 112 
+

  4 files changed, 140 insertions(+)
  create mode 100644 Documentation/hwmon/generic-pwm-tachometer
  create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer

new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It 
uses the
+generic PWM interface and can be used on SoCs as along as the SoC 
supports

+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan 
speed using
+PWM module and Tachometer controller. It requests period value 
through PWM
+capture interface to Tachometer and measures the Rotations per 
minute using
+received period value. It exposes the Fan speed in RPM to the user 
space by

+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
If you say yes here you get support for the temperature
and power sensors for APM X-Gene SoC.
  +config GENERIC_PWM_TACHOMETER
+tristate "Generic PWM based tachometer driver"
+depends on PWM
+help
+  Enables a driver to use PWM signal from motor to use
+  for measuring the motor speed. The RPM is captured by
+  PWM modules which has PWM capture capability and this
+  drivers reads the captured data from PWM IP to convert
+  it to speed in RPM.
+
  if ACPI
comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)+= wm8350-hwmon.o
  obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o
obj-$(CONFIG_PMBUS)+= pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
  diff --git a/drivers/hwmon/generic-pwm-tachometer.c 
b/drivers/hwmon/generic-pwm-tachometer.c

new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct pwm_hwmon_tach {
+struct device*dev;
+struct pwm_device*pwm;
+struct device*hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct device_attribute 
*attr,

+char *buf)
+{
+struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+struct pwm_device *pwm = ptt->pwm;
+struct pwm_capture result;
+int err;
+unsigned int rpm = 0;
+
+err = pwm_capture(pwm, , 0);
+if (err < 0) {
+dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+return err;
+}
+
+if (result.period)
+rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+result.period);
+
+return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);
+
+static struct attribute *pwm_tach_attrs[] = {
+_dev_attr_rpm.dev_attr.attr,
+NULL,
+};


"rpm" is not a standard hwmon sysfs attribute. If you don't provide
a single standard hwmon sysfs attribute, having a hwmon driver is 
pointless.

Guenter Roeck,
I will define a new hwmon sysfs attribute node called 
"hwmon_tachometer_attributes" 

Re: [PATCH v2 6/6] kconfig: rename silentoldconfig to syncconfig

[Randy Dunlap]

On 02/27/2018 04:15 PM, Masahiro Yamada wrote:
> As commit cedd55d49dee ("kconfig: Remove silentoldconfig from help
> and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a
> historical misnomer.  That commit removed it from help and docs since
> it is an internal interface.  If so, it should be allowed to rename
> it to something more intuitive.  'syncconfig' is the one I came up
> with because it updates the .config if necessary, then synchronize
> other files with it.
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
> Changes in v2:
>   - newly added
> 
>  Documentation/kbuild/kconfig.txt |  2 +-
>  Makefile |  2 +-
>  scripts/kconfig/Makefile |  4 ++--
>  scripts/kconfig/conf.c   | 20 ++--
>  4 files changed, 14 insertions(+), 14 deletions(-)

It wouldn't hurt to update this line also: (I would just drop "silentoldconfig")

 Make oldconfig/silentoldconfig/menuconfig/etc.

in Documentation/networking/i40e.txt.


thanks,
-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/4] tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP

[Karthikeyan Ramasubramanian]

This driver supports GENI based UART Controller in the Qualcomm SOCs. The
Qualcomm Generic Interface (GENI) is a programmable module supporting a
wide range of serial interfaces including UART. This driver support console
operations using FIFO mode of transfer.

Signed-off-by: Girish Mahadevan 
Signed-off-by: Karthikeyan Ramasubramanian 
Signed-off-by: Sagar Dharia 
Signed-off-by: Doug Anderson 
---
 drivers/tty/serial/Kconfig|   11 +
 drivers/tty/serial/Makefile   |1 +
 drivers/tty/serial/qcom_geni_serial.c | 1181 +
 3 files changed, 1193 insertions(+)
 create mode 100644 drivers/tty/serial/qcom_geni_serial.c

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 3682fd3..c6b1500 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1104,6 +1104,17 @@ config SERIAL_MSM_CONSOLE
select SERIAL_CORE_CONSOLE
select SERIAL_EARLYCON
 
+config SERIAL_QCOM_GENI
+   bool "QCOM on-chip GENI based serial port support"
+   depends on ARCH_QCOM
+   depends on QCOM_GENI_SE
+   select SERIAL_CORE
+   select SERIAL_CORE_CONSOLE
+   select SERIAL_EARLYCON
+   help
+ Serial driver for Qualcomm Technologies Inc's GENI based QUP
+ hardware.
+
 config SERIAL_VT8500
bool "VIA VT8500 on-chip serial port support"
depends on ARCH_VT8500
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index 842d185..64a8d82 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_SERIAL_SGI_IOC3) += ioc3_serial.o
 obj-$(CONFIG_SERIAL_ATMEL) += atmel_serial.o
 obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
 obj-$(CONFIG_SERIAL_MSM) += msm_serial.o
+obj-$(CONFIG_SERIAL_QCOM_GENI) += qcom_geni_serial.o
 obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
 obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
 obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
diff --git a/drivers/tty/serial/qcom_geni_serial.c 
b/drivers/tty/serial/qcom_geni_serial.c
new file mode 100644
index 000..8536b7d
--- /dev/null
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -0,0 +1,1181 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017-2018, The Linux foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* UART specific GENI registers */
+#define SE_UART_TX_TRANS_CFG   0x25c
+#define SE_UART_TX_WORD_LEN0x268
+#define SE_UART_TX_STOP_BIT_LEN0x26c
+#define SE_UART_TX_TRANS_LEN   0x270
+#define SE_UART_RX_TRANS_CFG   0x280
+#define SE_UART_RX_WORD_LEN0x28c
+#define SE_UART_RX_STALE_CNT   0x294
+#define SE_UART_TX_PARITY_CFG  0x2a4
+#define SE_UART_RX_PARITY_CFG  0x2a8
+
+/* SE_UART_TRANS_CFG */
+#define UART_TX_PAR_EN BIT(0)
+#define UART_CTS_MASK  BIT(1)
+
+/* SE_UART_TX_WORD_LEN */
+#define TX_WORD_LEN_MSKGENMASK(9, 0)
+
+/* SE_UART_TX_STOP_BIT_LEN */
+#define TX_STOP_BIT_LEN_MSKGENMASK(23, 0)
+#define TX_STOP_BIT_LEN_1  0
+#define TX_STOP_BIT_LEN_1_51
+#define TX_STOP_BIT_LEN_2  2
+
+/* SE_UART_TX_TRANS_LEN */
+#define TX_TRANS_LEN_MSK   GENMASK(23, 0)
+
+/* SE_UART_RX_TRANS_CFG */
+#define UART_RX_INS_STATUS_BIT BIT(2)
+#define UART_RX_PAR_EN BIT(3)
+
+/* SE_UART_RX_WORD_LEN */
+#define RX_WORD_LEN_MASK   GENMASK(9, 0)
+
+/* SE_UART_RX_STALE_CNT */
+#define RX_STALE_CNT   GENMASK(23, 0)
+
+/* SE_UART_TX_PARITY_CFG/RX_PARITY_CFG */
+#define PAR_CALC_ENBIT(0)
+#define PAR_MODE_MSK   GENMASK(2, 1)
+#define PAR_MODE_SHFT  1
+#define PAR_EVEN   0x00
+#define PAR_ODD0x01
+#define PAR_SPACE  0x10
+#define PAR_MARK   0x11
+
+/* UART M_CMD OP codes */
+#define UART_START_TX  0x1
+#define UART_START_BREAK   0x4
+#define UART_STOP_BREAK0x5
+/* UART S_CMD OP codes */
+#define UART_START_READ0x1
+#define UART_PARAM 0x1
+
+#define UART_OVERSAMPLING  32
+#define STALE_TIMEOUT  16
+#define DEFAULT_BITS_PER_CHAR  10
+#define GENI_UART_CONS_PORTS   1
+#define DEF_FIFO_DEPTH_WORDS   16
+#define DEF_TX_WM  2
+#define DEF_FIFO_WIDTH_BITS32
+#define UART_CONSOLE_RX_WM 2
+
+#ifdef CONFIG_CONSOLE_POLL
+#define RX_BYTES_PW 1
+#else
+#define RX_BYTES_PW 4
+#endif
+
+struct qcom_geni_serial_port {
+   struct uart_port uport;
+   struct geni_se se;
+   char name[20];
+   u32 tx_fifo_depth;
+   u32 tx_fifo_width;
+   u32 rx_fifo_depth;
+   u32 tx_wm;
+   u32 rx_wm;
+   u32 rx_rfr;
+   int xfer_mode;
+   bool port_setup;
+   int (*handle_rx)(struct uart_port *uport,
+  

[PATCH v3 2/4] soc: qcom: Add GENI based QUP Wrapper driver

[Karthikeyan Ramasubramanian]

This driver manages the Generic Interface (GENI) firmware based Qualcomm
Universal Peripheral (QUP) Wrapper. GENI based QUP is the next generation
programmable module composed of multiple Serial Engines (SE) and supports
a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. This
driver also enables managing the serial interface independent aspects of
Serial Engines.

Signed-off-by: Karthikeyan Ramasubramanian 
Signed-off-by: Sagar Dharia 
Signed-off-by: Girish Mahadevan 
---
 drivers/soc/qcom/Kconfig|   9 +
 drivers/soc/qcom/Makefile   |   1 +
 drivers/soc/qcom/qcom-geni-se.c | 971 
 include/linux/qcom-geni-se.h| 247 ++
 4 files changed, 1228 insertions(+)
 create mode 100644 drivers/soc/qcom/qcom-geni-se.c
 create mode 100644 include/linux/qcom-geni-se.h

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index e050eb8..cc460d0 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -3,6 +3,15 @@
 #
 menu "Qualcomm SoC drivers"
 
+config QCOM_GENI_SE
+   tristate "QCOM GENI Serial Engine Driver"
+   depends on ARCH_QCOM
+   help
+ This module is used to manage Generic Interface (GENI) firmware based
+ Qualcomm Technologies, Inc. Universal Peripheral (QUP) Wrapper. This
+ module is also used to manage the common aspects of multiple Serial
+ Engines present in the QUP.
+
 config QCOM_GLINK_SSR
tristate "Qualcomm Glink SSR driver"
depends on RPMSG
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index dcebf28..959aa74 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_QCOM_GENI_SE) +=  qcom-geni-se.o
 obj-$(CONFIG_QCOM_GLINK_SSR) +=glink_ssr.o
 obj-$(CONFIG_QCOM_GSBI)+=  qcom_gsbi.o
 obj-$(CONFIG_QCOM_MDT_LOADER)  += mdt_loader.o
diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
new file mode 100644
index 000..61335b8
--- /dev/null
+++ b/drivers/soc/qcom/qcom-geni-se.c
@@ -0,0 +1,971 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: Overview
+ *
+ * Generic Interface (GENI) Serial Engine (SE) Wrapper driver is introduced
+ * to manage GENI firmware based Qualcomm Universal Peripheral (QUP) Wrapper
+ * controller. QUP Wrapper is designed to support various serial bus protocols
+ * like UART, SPI, I2C, I3C, etc.
+ */
+
+/**
+ * DOC: Hardware description
+ *
+ * GENI based QUP is a highly-flexible and programmable module for supporting
+ * a wide range of serial interfaces like UART, SPI, I2C, I3C, etc. A single
+ * QUP module can provide upto 8 Serial Interfaces, using its internal
+ * Serial Engines. The actual configuration is determined by the target
+ * platform configuration. The protocol supported by each interface is
+ * determined by the firmware loaded to the Serial Engine. Each SE consists
+ * of a DMA Engine and GENI sub modules which enable Serial Engines to
+ * support FIFO and DMA modes of operation.
+ *
+ *
+ *  +-+
+ *  |QUP Wrapper  |
+ *  | ++  |
+ *   --QUP & SE Clocks--> | Serial Engine N|  +-IO-->
+ *  | | ...|  | Interface
+ *   <---Clock Perf.+++---+|  |
+ * State Interface  || Serial Engine 1||  |
+ *  ||||  |
+ *  ||||  |
+ *   |||  |
+ *  ||++  |
+ *  |||   |
+ *  |||   |
+ *   <--SE IRQ--+++   |
+ *  | |
+ *  +-+
+ *
+ * Figure 1: GENI based QUP Wrapper
+ */
+
+/**
+ * DOC: Software description
+ *
+ * GENI SE Wrapper driver is structured into 2 parts:
+ *
+ * geni_wrapper represents QUP Wrapper controller. This part of the driver
+ * manages QUP Wrapper information such as hardware version, clock
+ * performance table that is common to all the internal Serial Engines.
+ *
+ * geni_se represents Serial Engine. This part of the driver manages Serial
+ * Engine information such as clocks, containing QUP Wrapper etc. This 

[PATCH v3 3/4] i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller

[Karthikeyan Ramasubramanian]

This bus driver supports the GENI based i2c hardware controller in the
Qualcomm SOCs. The Qualcomm Generic Interface (GENI) is a programmable
module supporting a wide range of serial interfaces including I2C. The
driver supports FIFO mode and DMA mode of transfer and switches modes
dynamically depending on the size of the transfer.

Signed-off-by: Karthikeyan Ramasubramanian 
Signed-off-by: Sagar Dharia 
Signed-off-by: Girish Mahadevan 
---
 drivers/i2c/busses/Kconfig |  11 +
 drivers/i2c/busses/Makefile|   1 +
 drivers/i2c/busses/i2c-qcom-geni.c | 626 +
 3 files changed, 638 insertions(+)
 create mode 100644 drivers/i2c/busses/i2c-qcom-geni.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index e2954fb..1ddf5cd 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -848,6 +848,17 @@ config I2C_PXA_SLAVE
  is necessary for systems where the PXA may be a target on the
  I2C bus.
 
+config I2C_QCOM_GENI
+   tristate "Qualcomm Technologies Inc.'s GENI based I2C controller"
+   depends on ARCH_QCOM
+   depends on QCOM_GENI_SE
+   help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Qualcomm Technologies Inc.'s SoCs.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-qcom-geni.
+
 config I2C_QUP
tristate "Qualcomm QUP based I2C controller"
depends on ARCH_QCOM
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 2ce8576..201fce1 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -84,6 +84,7 @@ obj-$(CONFIG_I2C_PNX) += i2c-pnx.o
 obj-$(CONFIG_I2C_PUV3) += i2c-puv3.o
 obj-$(CONFIG_I2C_PXA)  += i2c-pxa.o
 obj-$(CONFIG_I2C_PXA_PCI)  += i2c-pxa-pci.o
+obj-$(CONFIG_I2C_QCOM_GENI)+= i2c-qcom-geni.o
 obj-$(CONFIG_I2C_QUP)  += i2c-qup.o
 obj-$(CONFIG_I2C_RIIC) += i2c-riic.o
 obj-$(CONFIG_I2C_RK3X) += i2c-rk3x.o
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c 
b/drivers/i2c/busses/i2c-qcom-geni.c
new file mode 100644
index 000..e1e4268
--- /dev/null
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -0,0 +1,626 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SE_I2C_TX_TRANS_LEN0x26c
+#define SE_I2C_RX_TRANS_LEN0x270
+#define SE_I2C_SCL_COUNTERS0x278
+
+#define SE_I2C_ERR  (M_CMD_OVERRUN_EN | M_ILLEGAL_CMD_EN | M_CMD_FAILURE_EN |\
+   M_GP_IRQ_1_EN | M_GP_IRQ_3_EN | M_GP_IRQ_4_EN)
+#define SE_I2C_ABORT   BIT(1)
+
+/* M_CMD OP codes for I2C */
+#define I2C_WRITE  0x1
+#define I2C_READ   0x2
+#define I2C_WRITE_READ 0x3
+#define I2C_ADDR_ONLY  0x4
+#define I2C_BUS_CLEAR  0x6
+#define I2C_STOP_ON_BUS0x7
+/* M_CMD params for I2C */
+#define PRE_CMD_DELAY  BIT(0)
+#define TIMESTAMP_BEFORE   BIT(1)
+#define STOP_STRETCH   BIT(2)
+#define TIMESTAMP_AFTERBIT(3)
+#define POST_COMMAND_DELAY BIT(4)
+#define IGNORE_ADD_NACKBIT(6)
+#define READ_FINISHED_WITH_ACK BIT(7)
+#define BYPASS_ADDR_PHASE  BIT(8)
+#define SLV_ADDR_MSK   GENMASK(15, 9)
+#define SLV_ADDR_SHFT  9
+/* I2C SCL COUNTER fields */
+#define HIGH_COUNTER_MSK   GENMASK(29, 20)
+#define HIGH_COUNTER_SHFT  20
+#define LOW_COUNTER_MSKGENMASK(19, 10)
+#define LOW_COUNTER_SHFT   10
+#define CYCLE_COUNTER_MSK  GENMASK(9, 0)
+
+#define GP_IRQ00
+#define GP_IRQ11
+#define GP_IRQ22
+#define GP_IRQ33
+#define GP_IRQ44
+#define GP_IRQ55
+#define GENI_OVERRUN   6
+#define GENI_ILLEGAL_CMD   7
+#define GENI_ABORT_DONE8
+#define GENI_TIMEOUT   9
+
+#define I2C_NACK   GP_IRQ1
+#define I2C_BUS_PROTO  GP_IRQ3
+#define I2C_ARB_LOST   GP_IRQ4
+#define DM_I2C_CB_ERR  ((BIT(GP_IRQ1) | BIT(GP_IRQ3) | BIT(GP_IRQ4)) \
+   << 5)
+
+#define I2C_AUTO_SUSPEND_DELAY 250
+#define KHz(freq)  (1000 * freq)
+#define PACKING_BYTES_PW   4
+
+struct geni_i2c_dev {
+   struct geni_se se;
+   u32 tx_wm;
+   int irq;
+   int err;
+   struct i2c_adapter adap;
+   struct completion done;
+   struct i2c_msg *cur;
+   int cur_wr;
+   int cur_rd;
+   u32 clk_freq_out;
+   const struct geni_i2c_clk_fld *clk_fld;

[PATCH v3 0/4] Introduce GENI SE Controller Driver

[Karthikeyan Ramasubramanian]

Generic Interface (GENI) firmware based Qualcomm Universal Peripheral (QUP)
Wrapper is a next generation programmable module for supporting a wide
range of serial interfaces like UART, SPI, I2C, I3C, etc. A single QUP
module can provide upto 8 Serial Interfaces using its internal Serial
Engines (SE). The protocol supported by each interface is determined by
the firmware loaded to the Serial Engine.

This patch series introduces GENI SE Driver to manage the GENI based QUP
Wrapper and the common aspects of all SEs inside the QUP Wrapper. This
patch series also introduces the UART and I2C Controller drivers to
drive the SEs that are programmed with the respective protocols.

[v3]
 * Update the driver dependencies
 * Use the SPDX License Expression
 * Squash all the controller device tree bindings together
 * Use kernel doc format for documentation
 * Add additional documentation for packing configuration
 * Use clk_bulk_* API for related clocks
 * Remove driver references to pinctrl and their states
 * Replace magic numbers with appropriate macros
 * Update memory barrier usage and associated comments
 * Reduce interlacing of register reads/writes
 * Fix poll_get_char() operation in console UART driver under polling mode
 * Address other comments from Bjorn Andersson to improve code readability

[v2]
 * Updated device tree bindings to describe the hardware
 * Updated SE DT node as child node of QUP Wrapper DT node
 * Moved common AHB clocks to QUP Wrapper DT node
 * Use the standard "clock-frequency" I2C property
 * Update compatible field in UART Controller to reflect hardware manual
 * Addressed other device tree binding specific comments from Rob Herring

Karthikeyan Ramasubramanian (4):
  dt-bindings: soc: qcom: Add device tree binding for GENI SE
  soc: qcom: Add GENI based QUP Wrapper driver
  i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C
controller
  tty: serial: msm_geni_serial: Add serial driver support for GENI based
QUP

 .../devicetree/bindings/soc/qcom/qcom,geni-se.txt  |   89 ++
 drivers/i2c/busses/Kconfig |   11 +
 drivers/i2c/busses/Makefile|1 +
 drivers/i2c/busses/i2c-qcom-geni.c |  626 +++
 drivers/soc/qcom/Kconfig   |9 +
 drivers/soc/qcom/Makefile  |1 +
 drivers/soc/qcom/qcom-geni-se.c|  971 
 drivers/tty/serial/Kconfig |   11 +
 drivers/tty/serial/Makefile|1 +
 drivers/tty/serial/qcom_geni_serial.c  | 1181 
 include/linux/qcom-geni-se.h   |  247 
 11 files changed, 3148 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
 create mode 100644 drivers/i2c/busses/i2c-qcom-geni.c
 create mode 100644 drivers/soc/qcom/qcom-geni-se.c
 create mode 100644 drivers/tty/serial/qcom_geni_serial.c
 create mode 100644 include/linux/qcom-geni-se.h

-- 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/4] dt-bindings: soc: qcom: Add device tree binding for GENI SE

[Karthikeyan Ramasubramanian]

Add device tree binding support for the QCOM GENI SE driver.

Signed-off-by: Karthikeyan Ramasubramanian 
Signed-off-by: Sagar Dharia 
Signed-off-by: Girish Mahadevan 
---
 .../devicetree/bindings/soc/qcom/qcom,geni-se.txt  | 89 ++
 1 file changed, 89 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
new file mode 100644
index 000..fe6a0c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
@@ -0,0 +1,89 @@
+Qualcomm Technologies, Inc. GENI Serial Engine QUP Wrapper Controller
+
+Generic Interface (GENI) based Qualcomm Universal Peripheral (QUP) wrapper
+is a programmable module for supporting a wide range of serial interfaces
+like UART, SPI, I2C, I3C, etc. A single QUP module can provide upto 8 Serial
+Interfaces, using its internal Serial Engines. The GENI Serial Engine QUP
+Wrapper controller is modeled as a node with zero or more child nodes each
+representing a serial engine.
+
+Required properties:
+- compatible:  Must be "qcom,geni-se-qup".
+- reg: Must contain QUP register address and length.
+- clock-names: Must contain "m-ahb" and "s-ahb".
+- clocks:  AHB clocks needed by the device.
+
+Required properties if child node exists:
+- #address-cells:  Must be <1> for Serial Engine Address
+- #size-cells: Must be <1> for Serial Engine Address Size
+- ranges:  Must be present
+
+Properties for children:
+
+A GENI based QUP wrapper controller node can contain 0 or more child nodes
+representing serial devices.  These serial devices can be a QCOM UART, I2C
+controller, spi controller, or some combination of aforementioned devices.
+Please refer below the child node definitions for the supported serial
+interface protocols.
+
+Qualcomm Technologies Inc. GENI Serial Engine based I2C Controller
+
+Required properties:
+- compatible:  Must be "qcom,geni-i2c".
+- reg: Must contain QUP register address and length.
+- interrupts:  Must contain I2C interrupt.
+- clock-names: Must contain "se".
+- clocks:  Serial engine core clock needed by the device.
+- #address-cells:  Must be <1> for i2c device address.
+- #size-cells: Must be <0> as i2c addresses have no size component.
+
+Optional property:
+- clock-frequency: Desired I2C bus clock frequency in Hz.
+   When missing default to 40Hz.
+
+Child nodes should conform to i2c bus binding as described in i2c.txt.
+
+Qualcomm Technologies Inc. GENI Serial Engine based UART Controller
+
+Required properties:
+- compatible:  Must be "qcom,geni-debug-uart".
+- reg: Must contain UART register location and length.
+- interrupts:  Must contain UART core interrupts.
+- clock-names: Must contain "se".
+- clocks:  Serial engine core clock needed by the device.
+
+Example:
+   geniqup@8c {
+   compatible = "qcom,geni-se-qup";
+   reg = <0x8c 0x6000>;
+   clock-names = "m-ahb", "s-ahb";
+   clocks = <_gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
+   <_gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   i2c0: i2c@a94000 {
+   compatible = "qcom,geni-i2c";
+   reg = <0xa94000 0x4000>;
+   interrupts = ;
+   clock-names = "se";
+   clocks = <_gcc GCC_QUPV3_WRAP0_S5_CLK>;
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_1_i2c_5_active>;
+   pinctrl-1 = <_1_i2c_5_sleep>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   uart0: serial@a88000 {
+   compatible = "qcom,geni-debug-uart";
+   reg = <0xa88000 0x7000>;
+   interrupts = ;
+   clock-names = "se";
+   clocks = <_gcc GCC_QUPV3_WRAP0_S0_CLK>;
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_1_uart_3_active>;
+   pinctrl-1 = <_1_uart_3_sleep>;
+   };
+   }
-- 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 6/6] kconfig: rename silentoldconfig to syncconfig

[Masahiro Yamada]

As commit cedd55d49dee ("kconfig: Remove silentoldconfig from help
and docs; fix kconfig/conf's help") mentioned, 'silentoldconfig' is a
historical misnomer.  That commit removed it from help and docs since
it is an internal interface.  If so, it should be allowed to rename
it to something more intuitive.  'syncconfig' is the one I came up
with because it updates the .config if necessary, then synchronize
other files with it.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - newly added

 Documentation/kbuild/kconfig.txt |  2 +-
 Makefile |  2 +-
 scripts/kconfig/Makefile |  4 ++--
 scripts/kconfig/conf.c   | 20 ++--
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index bbc99c0..7233118 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt
@@ -119,7 +119,7 @@ Examples:
15% of tristates will be set to 'y', 15% to 'm', 70% to 'n'
 
 __
-Environment variables for 'silentoldconfig'
+Environment variables for 'syncconfig'
 
 KCONFIG_NOSILENTUPDATE
 --
diff --git a/Makefile b/Makefile
index 8706bf2..ea23d9b 100644
--- a/Makefile
+++ b/Makefile
@@ -598,7 +598,7 @@ $(KCONFIG_CONFIG) include/config/auto.conf.cmd: ;
 # include/generated/ and include/config/. Update them if .config is newer than
 # include/config/auto.conf (which mirrors .config).
 include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
-   $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
+   $(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
 else
 # external modules needs include/generated/autoconf.h and 
include/config/auto.conf
 # but do not care if they are up-to-date. Use auto.conf to trigger the test
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index bf9289a..988258a 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -3,7 +3,7 @@
 # Kernel configuration targets
 # These targets are used from top-level makefile
 
-PHONY += xconfig gconfig menuconfig config silentoldconfig update-po-config \
+PHONY += xconfig gconfig menuconfig config syncconfig update-po-config \
localmodconfig localyesconfig
 
 ifdef KBUILD_KCONFIG
@@ -36,7 +36,7 @@ nconfig: $(obj)/nconf
 
 # This has become an internal implementation detail and is now deprecated
 # for external use.
-silentoldconfig: $(obj)/conf
+syncconfig: $(obj)/conf
$(Q)mkdir -p include/config include/generated
$(Q)test -e include/generated/autoksyms.h || \
touch   include/generated/autoksyms.h
diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index 11a4e45..4e08121 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -23,7 +23,7 @@ static void check_conf(struct menu *menu);
 
 enum input_mode {
oldaskconfig,
-   silentoldconfig,
+   syncconfig,
oldconfig,
allnoconfig,
allyesconfig,
@@ -100,7 +100,7 @@ static int conf_askvalue(struct symbol *sym, const char 
*def)
 
switch (input_mode) {
case oldconfig:
-   case silentoldconfig:
+   case syncconfig:
if (sym_has_value(sym)) {
printf("%s\n", def);
return 0;
@@ -293,7 +293,7 @@ static int conf_choice(struct menu *menu)
printf("[1-%d?]: ", cnt);
switch (input_mode) {
case oldconfig:
-   case silentoldconfig:
+   case syncconfig:
if (!is_new) {
cnt = def;
printf("%d\n", cnt);
@@ -441,7 +441,7 @@ static void check_conf(struct menu *menu)
 static struct option long_opts[] = {
{"oldaskconfig",no_argument,   NULL, oldaskconfig},
{"oldconfig",   no_argument,   NULL, oldconfig},
-   {"silentoldconfig", no_argument,   NULL, silentoldconfig},
+   {"syncconfig",  no_argument,   NULL, syncconfig},
{"defconfig",   optional_argument, NULL, defconfig},
{"savedefconfig",   required_argument, NULL, savedefconfig},
{"allnoconfig", no_argument,   NULL, allnoconfig},
@@ -468,8 +468,8 @@ static void conf_usage(const char *progname)
printf("  --listnewconfig List new options\n");
printf("  --oldaskconfig  Start a new configuration using a 
line-oriented program\n");
printf("  --oldconfig Update a configuration using a 
provided .config as base\n");
-   printf("  --silentoldconfig   Similar to oldconfig but generates 
configuration in\n"
-  "  include/{generated/,config/} 
(oldconfig used to be more verbose)\n");
+   printf("  --syncconfig

[PATCH v2 0/6] kconfig: some clean-ups and rename silentoldconfig

[Masahiro Yamada]

Masahiro Yamada (6):
  kconfig: do not call check_conf() for olddefconfig
  kconfig: remove unneeded input_mode test in conf()
  kconfig: remove redundant input_mode test for check_conf() loop
  kconfig: hide irrelevant sub-menus for oldconfig
  kconfig: invoke oldconfig instead of silentoldconfig from local*config
  kconfig: rename silentoldconfig to syncconfig

 Documentation/kbuild/kconfig.txt |  2 +-
 Makefile |  2 +-
 scripts/kconfig/Makefile |  8 
 scripts/kconfig/conf.c   | 41 
 4 files changed, 27 insertions(+), 26 deletions(-)

-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/17] Include linux trace docs to Sphinx TOC tree

[Steven Rostedt]

On Tue, 27 Feb 2018 17:34:22 +0800
"Du, Changbin"  wrote:

> Hello Steven and Corbet,
> Ten days past, will you accept this serias? Thank you!
> 
> On Sat, Feb 17, 2018 at 01:39:33PM +0800, changbin...@intel.com wrote:
> > From: Changbin Du 
> > 
> > Hi All,
> > The linux tracers are so useful that I want to make the docs better. The 
> > kernel
> > now uses Sphinx to generate intelligent and beautiful documentation from
> > reStructuredText files. I converted most of the Linux trace docs to rst 
> > format
> > in this serias.
> > 
> > For you to preview, please visit below url:
> > http://docservice.askxiong.com/linux-kernel/trace/index.html
> > 
> > Thank you!

Currently I'm very overloaded with other code that needs to get done
ASAP, and I need to balance what is critical and what is not. I don't
have time to review this, as this isn't critical, and can wait.

If Jon can review it to make sure that it doesn't change the
readability of the text, then I'll trust his judgment. 

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Boris Brezillon]

On Tue, 27 Feb 2018 20:24:43 +
Przemyslaw Sroka  wrote:


> > > SETDASA is simply faster than ENTDAA, but only if there is no
> > > need to collect BCR/DCR/PID of such devices. I think most
> > > applications would like to have them as an status information so
> > > after all ENTDAA can be regarded as an generic approach (unless
> > > I'm mistaken).  
> > 
> > Actually, we could retrieve BCR/DCR/PID (and all other relevant
> > information, like MAXDS) even with the SETDASA approach. We just
> > need to send the according CCC commands after SETDASA.
> >   
> I agree, what I meant by "SETDASA is simply faster than ENTDAA, but
> only if there is no need to collect BCR/DCR/PID of such devices." Is
> that it is faster than DAA but only if not followed by GET CCC
> commands to gather BCR/DCR/PID. I think we are on the same page here.

Yes, but right now it's not the case, see my other reply ;-).

> 
> > But that's also my understanding that ENTDAA should always work, and
> > SETDASA usage is only needed if you want to reserve a dynamic
> > address and assign it to a device before DAA takes place. This way
> > you can enforce the device priority (WRT IBIs). But honestly,
> > that's the only use case I can think of, and to me, it sounds like
> > an advanced feature we may want to support at some point, but don't
> > need in the initial implementation. 
> Still ENTDAA seems to be sufficient for IBI prioritization but I can
> imagine some use cases where people would like to use it for such
> purposes. Note that SETDASA is applicable only for devices with SA so
> it is self-explanatory that it cannot be considered as utility to
> define priorities for all devices before ENTDAA. 

We have SETNEWDA for other use cases: say you want one of your device to
have an higher priority, you can just manually set a new dynamic
address that is lower than any other devices on the bus (I plan to
expose that through sysfs, by making the address file writable).

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Boris Brezillon]

Hi Przemek,

On Tue, 27 Feb 2018 17:06:37 +
Przemyslaw Sroka  wrote:

> > > >
> > > > Could you tell me why you think SETDASA is required?  
> > >
> > > Yes, you are right... But in my opinion it is required as it does part
> > > of DAA process.  
> > 
> > SETDASA is simply faster than ENTDAA, but only if there is no need to
> > collect BCR/DCR/PID of such devices. I think most applications would like to
> > have them as an status information so  after all ENTDAA can be regarded as
> > an generic approach (unless I'm mistaken).  
> 
> Below are 2 examples on how DAA can be executed:
> 1st:
> A1) SETDASA to devices with SA

I'm not even sure all devices with a static address needs to be
assigned a dynamic address with SETDASA (actually, I'm almost sure
it's not the case, since, according to section "5.1.9.3 CCC Command
Definitions" of the spec, all I3C slaves have to support ENTDAA). To me,
it looks like you'd want to do that only is you really need to reserve
a specific dynamic address and prevent the DAA step from assigning it
to another device.

> B1) DAA to remaining devices
> C1) GET BCR/DCR/PID to devices that initially had SA
> NOTES: C1 is optional and order of B1 and C1 can be changed

While that's true in principle, in Linux we'll always retrieve
BCR/DCR/PID (and more, like MAXDS), no matter how the device obtained
its dynamic address.

> 
> 2nd:
> A2) DAA to all devices
> NOTES: no need for any follow up steps as all information is collected during 
> DAA

As said above, that's not exactly how the Linux implementation works.
Right now I'm ignoring the information retrieved during DAA and forcing
a GETPID/GETBCR/GETDCR for every discovered device. This approach is
generating a bit more traffic on the bus, but it also makes the
implementation more generic, because we have a single function to add
an I3C device, no matter how it's been assigned a dynamic address.

> 
> As we can see 2nd approach is more generic and do not see any reason to add 
> special handling for SETDASA unless there is any reasonable reason to do 
> otherwise.

I agree on one thing: as long as you don't have to reserve a specific
dynamic address, SETDASA is not required. At least, that's my
understanding.

Regards,

Boris

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Przemyslaw Sroka]

Hi Boris

> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Tuesday, February 27, 2018 9:13 PM
> To: Przemyslaw Sroka 
> Cc: Vitor Soares ; Boris Brezillon
> ; Wolfram Sang  dreams.de>; linux-...@vger.kernel.org; Jonathan Corbet ;
> linux-doc@vger.kernel.org; Greg Kroah-Hartman
> ; Arnd Bergmann ;
> Arkadiusz Golec ; Alan Douglas
> ; Bartosz Folta ; Damian
> Kos ; Alicja Jurasik-Urbaniak ;
> Cyprian Wronka ; Suresh Punnoose
> ; Thomas Petazzoni  electrons.com>; Nishanth Menon ; Rob Herring
> ; Pawel Moll ; Mark Rutland
> ; Ian Campbell ;
> Kumar Gala ; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Geert Uytterhoeven ; Linus
> Walleij 
> Subject: Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
> 
> EXTERNAL MAIL
> 
> 
> Hi Przemek,
> 
> On Tue, 27 Feb 2018 16:43:27 +
> Przemyslaw Sroka  wrote:
> 
> > >
> > > >> Either important is the SETDASA for declared I3C devices. So the
> > > >> DAA process should start by send an SETDASA and them ENTDAA
> CCC
> > > command.
> > > > My understanding was that SETDASA was not mandatory, and was
> only
> > > > useful when one wants to assign a specific dynamic address to a
> > > > slave that has a static address (which is again not mandatory).
> > > > I've tested it, and even devices with a static address participate
> > > > to the DAA procedure if they've not been assigned a dynamic
> > > > address yet, so I don't see the need for this SETDASA step if you
> > > > don't need to assign a particular dynamic address to the device.
> > > >
> > > > Could you tell me why you think SETDASA is required?
> > >
> > > Yes, you are right... But in my opinion it is required as it does
> > > part of DAA process.
> >
> > SETDASA is simply faster than ENTDAA, but only if there is no need to
> > collect BCR/DCR/PID of such devices. I think most applications would
> > like to have them as an status information so  after all ENTDAA can be
> > regarded as an generic approach (unless I'm mistaken).
> 
> Actually, we could retrieve BCR/DCR/PID (and all other relevant
> information, like MAXDS) even with the SETDASA approach. We just need to
> send the according CCC commands after SETDASA.
> 
I agree, what I meant by "SETDASA is simply faster than ENTDAA, but only if 
there is no need to collect BCR/DCR/PID of such devices." Is that it is faster 
than DAA but only if not followed by GET CCC commands to gather BCR/DCR/PID. I 
think we are on the same page here.

> But that's also my understanding that ENTDAA should always work, and
> SETDASA usage is only needed if you want to reserve a dynamic address
> and assign it to a device before DAA takes place. This way you can enforce
> the device priority (WRT IBIs). But honestly, that's the only use case I can
> think of, and to me, it sounds like an advanced feature we may want to
> support at some point, but don't need in the initial implementation.
>
Still ENTDAA seems to be sufficient for IBI prioritization but I can imagine 
some use cases where people would like to use it for such purposes. Note that 
SETDASA is applicable only for devices with SA so it is self-explanatory that 
it cannot be considered as utility to define priorities for all devices before 
ENTDAA. 

> --
> Boris Brezillon, Bootlin (formerly Free Electrons) Embedded Linux and
> Kernel engineering https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__bootlin.com=DwICAg=aUq983L2pue2FqKFoP6PGHMJQyoJ7kl3s3G
> Z-_haXqY=b0WPdqYyu0KH4-vSatt-ViJE1riZ603zdXl3hHHp_TU=wM54-
> BGcSfHEklVRsw02O-bnyNkLTe9c0RyBP_ExzPA=pxQrogG-
> Nq4XOMU7SPZ2FZNbgnbnjdERtMm_h7ZcdCE=

Regards,
Przemek
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Boris Brezillon]

Hi Przemek,

On Tue, 27 Feb 2018 16:43:27 +
Przemyslaw Sroka  wrote:

> >   
> > >> Either important is the SETDASA for declared I3C devices. So the DAA
> > >> process should start by send an SETDASA and them ENTDAA CCC  
> > command.  
> > > My understanding was that SETDASA was not mandatory, and was only
> > > useful when one wants to assign a specific dynamic address to a slave
> > > that has a static address (which is again not mandatory).
> > > I've tested it, and even devices with a static address participate to
> > > the DAA procedure if they've not been assigned a dynamic address yet,
> > > so I don't see the need for this SETDASA step if you don't need to
> > > assign a particular dynamic address to the device.
> > >
> > > Could you tell me why you think SETDASA is required?  
> > 
> > Yes, you are right... But in my opinion it is required as it does part of 
> > DAA
> > process.  
> 
> SETDASA is simply faster than ENTDAA, but only if there is no need to
> collect BCR/DCR/PID of such devices. I think most applications would
> like to have them as an status information so  after all ENTDAA can 
> be regarded as an generic approach (unless I'm mistaken).

Actually, we could retrieve BCR/DCR/PID (and all other relevant
information, like MAXDS) even with the SETDASA approach. We just
need to send the according CCC commands after SETDASA.

But that's also my understanding that ENTDAA should always work, and
SETDASA usage is only needed if you want to reserve a dynamic address
and assign it to a device before DAA takes place. This way you can
enforce the device priority (WRT IBIs). But honestly, that's the only
use case I can think of, and to me, it sounds like an advanced feature
we may want to support at some point, but don't need in the initial
implementation.

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Boris Brezillon]

Hi Vitor,

On Tue, 27 Feb 2018 16:03:58 +
Vitor Soares  wrote:

> >>>
> >>> The speed R/W speed limitation is encoded in the device object, so, if
> >>> the controller has to configure that on a per-transfer basis, one
> >>> solution would be to pass the device to the ->priv_xfers().
> >> The speed R/W limitation is only for private transfers. Also the device 
> >> can have
> >> a limitation to write and not for read data.
> >> This information is obtained with the command GETMXDS which returns the 
> >> Maximum
> >> Sustained Data Rate for non-CCC messages.  
> > And that's exactly what I expose in i3c_device_info, which is embedded
> > in i3c_device, so you should have all the information you need to
> > determine the speed in the controller driver if ->priv_xfer() is passed
> > the device attached to those transfers. Would that be okay if we pass an
> > i3c_device object to ->priv_xfers()?  
> 
> If you pass the i3c_device to ->priv_xfer(), then you won't need the address 
> too.

That's true. So how about we pass the i3c_device to ->priv_xfer() and
drop the address field in i3c_priv_xfer. Or we could remove the address
field add an i3c_device pointer in i3c_priv_xfer, this way, if we ever
need to do cross-device sequence we'll be able to support it.

> 
> Maybe someone else can give other point of view.

That'd be great, but I'd like to hear your opinion, because it's not
clear to me what you think of my suggestion.


> >> Either important is the SETDASA for declared I3C devices. So the DAA 
> >> process
> >> should start by send an SETDASA and them ENTDAA CCC command.  
> > My understanding was that SETDASA was not mandatory, and was only useful
> > when one wants to assign a specific dynamic address to a slave that has
> > a static address (which is again not mandatory).
> > I've tested it, and even devices with a static address participate to
> > the DAA procedure if they've not been assigned a dynamic address yet,
> > so I don't see the need for this SETDASA step if you don't need to
> > assign a particular dynamic address to the device.
> >
> > Could you tell me why you think SETDASA is required?  
> 
> Yes, you are right... But in my opinion it is required as it does part of DAA
> process.

As Przemek said in his reply, I don't think it's required, at least not
for the initial implementation. I'm definitely not saying we should
never support the feature, but it can easily be added afterwards.

BTW, can you give me a scenario where you'll want to assign a specific
dynamic address to a device before DAA takes place (by DAA, I mean what
happens after ENTDAA, which AIUI is what DAA describes)? I know it's
described in the spec, and might become useful at some point, but right
now, for a general purpose OS like Linux, I don't see a good reason to
assign a dynamic address using SETDASA.

> 
> > +static u32 i3c_master_i2c_functionalities(struct i2c_adapter *adap)
> > +{
> > +   return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR;
> > +}  
>   Is I2C_FUNC_10BIT_ADDR allowed ?
> >>> According to "Table 4 I 2 C Features Allowed in I3C Slaves", yes (at
> >>> least that my understanding). And the Cadence controller supports it.
> >> The table say the oposite. The I2C extended address feature is not used on 
> >> I3C
> >> bus, thus this feature shall be disable.  
> > Actually, I was wrong when initially mentioning this table: it's about
> > I2C features supported on I3C slaves, so not really what we're looking
> > for. Here, we're wondering if I2C-only devices can have 10-bit
> > addresses. The Cadence controller supports that, so there's probably
> > nothing preventing use of 10-bit addresses for I2C transfers, but maybe
> > not all I3C master controllers support that, so we should probably
> > let the I3C master driver implement this method.  
> 
> The spec says that is "not used" so it will not interface with I3C bus.

Again, I should not have pointed you to this chapter, because it does
not describe what the I3C bus accept, but what I3C slave acting like
I2C devices accept (basically what they accept before being assigned a
dynamic address).

If you see in the I3C spec that I2C transfers using 10-bit addresses
is forbidden, could you tell me where it's stated, because I didn't
find it. 

> 
> >> BTW it is optional on I2C devices.  
> > You mean I2C controllers? When an I2C device has a 10bit address, the
> > controller has to support this mode to communicate with the device, at
> > least that's my understanding. But we're digressing a bit. The
> > question is not whether I2C devices can optionally use a 10 bit
> > address, but whether I3C master controller can support this mode for
> > I2C transfers to I2C-only devices.  
> 
> By the i2c spec the 10-bit address is optional, however the 7-bit address is
> mandatory.

The controller is not forced to support this feature, I think I already
said I agree on this aspect. But if 

RE: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Przemyslaw Sroka]

More detailed explanation...

> -Original Message-
> From: Przemyslaw Sroka
> Sent: Tuesday, February 27, 2018 5:43 PM
> To: 'Vitor Soares' ; Boris Brezillon
> 
> Cc: Boris Brezillon ; Wolfram Sang
> ; linux-...@vger.kernel.org; Jonathan Corbet
> ; linux-doc@vger.kernel.org; Greg Kroah-Hartman
> ; Arnd Bergmann ;
> Arkadiusz Golec ; Alan Douglas
> ; Bartosz Folta ; Damian
> Kos ; Alicja Jurasik-Urbaniak ;
> Cyprian Wronka ; Suresh Punnoose
> ; Thomas Petazzoni  electrons.com>; Nishanth Menon ; Rob Herring
> ; Pawel Moll ; Mark Rutland
> ; Ian Campbell ;
> Kumar Gala ; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Geert Uytterhoeven ; Linus
> Walleij 
> Subject: RE: [PATCH v2 2/7] i3c: Add core I3C infrastructure
> 
> Hi Boris and Vitor
> 
> Find below my comment on DAA procedure.
> 
> > -Original Message-
> > From: Vitor Soares [mailto:vitor.soa...@synopsys.com]
> > Sent: Tuesday, February 27, 2018 5:04 PM
> > To: Boris Brezillon ; Vitor Soares
> > 
> > Cc: Boris Brezillon ; Wolfram Sang
> > ; linux-...@vger.kernel.org; Jonathan Corbet
> > ; linux-doc@vger.kernel.org; Greg Kroah-Hartman
> > ; Arnd Bergmann ;
> > Przemyslaw Sroka ; Arkadiusz Golec
> > ; Alan Douglas ; Bartosz
> > Folta ; Damian Kos ; Alicja
> > Jurasik-Urbaniak ; Cyprian Wronka
> > ; Suresh Punnoose ;
> Thomas
> > Petazzoni ; Nishanth Menon
> > ; Rob Herring ; Pawel Moll
> > ; Mark Rutland ; Ian
> > Campbell ; Kumar Gala
> > ; devicet...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; Geert Uytterhoeven ;
> > Linus Walleij 
> > Subject: Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
> >
> > EXTERNAL MAIL
> >
> >
> > Hi Boris
> >
> >
> > Às 8:36 PM de 2/26/2018, Boris Brezillon escreveu:
> > > Hi Vitor,
> > >
> > > On Mon, 26 Feb 2018 18:58:15 +
> > > Vitor Soares  wrote:
> > >
> > > +/**
> > > + * i3c_device_do_priv_xfers() - do I3C SDR private transfers
> > > +directed
> > to a
> > > + *   specific device
> > > + *
> > > + * @dev: device with which the transfers should be done
> > > + * @xfers: array of transfers
> > > + * @nxfers: number of transfers
> > > + *
> > > + * Initiate one or several private SDR transfers with @dev.
> > > + *
> > > + * This function can sleep and thus cannot be called in atomic
> > context.
> > > + *
> > > + * Return: 0 in case of success, a negative error core otherwise.
> > > + */
> > > +int i3c_device_do_priv_xfers(struct i3c_device *dev,
> > > +  struct i3c_priv_xfer *xfers,
> > > +  int nxfers)
> > > +{
> > > + struct i3c_master_controller *master;
> > > + int i, ret;
> > > +
> > > + master = i3c_device_get_master(dev);
> > > + if (!master)
> > > + return -EINVAL;
> > > +
> > > + i3c_bus_normaluse_lock(master->bus);
> > > + for (i = 0; i < nxfers; i++)
> > > + xfers[i].addr = dev->info.dyn_addr;
> > > +
> > > + ret = i3c_master_do_priv_xfers_locked(master, xfers,
> > nxfers);
> > > + i3c_bus_normaluse_unlock(master->bus);
> > > +
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);
> >   The controller should know the speed mode for each xfer. The
> >  SDR0 mode is used by default but if any device have read or write
> >  speed limitations the controller can use SDRx.
> > >>> I might be wrong, but that's not my understanding of the spec. A
> > >>> device can express a speed limitation for SDR priv transfers, but
> > >>> this limitation applies to all SDR transfers.
> > >>>
> > >>> The speed R/W speed limitation is encoded in the device object,
> > >>> so, if the controller has to configure that on a per-transfer
> > >>> basis, one solution would be to pass the device to the 

RE: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Przemyslaw Sroka]

Hi Boris and Vitor

Find below my comment on DAA procedure.

> -Original Message-
> From: Vitor Soares [mailto:vitor.soa...@synopsys.com]
> Sent: Tuesday, February 27, 2018 5:04 PM
> To: Boris Brezillon ; Vitor Soares
> 
> Cc: Boris Brezillon ; Wolfram Sang
> ; linux-...@vger.kernel.org; Jonathan Corbet
> ; linux-doc@vger.kernel.org; Greg Kroah-Hartman
> ; Arnd Bergmann ;
> Przemyslaw Sroka ; Arkadiusz Golec
> ; Alan Douglas ; Bartosz
> Folta ; Damian Kos ; Alicja
> Jurasik-Urbaniak ; Cyprian Wronka
> ; Suresh Punnoose ;
> Thomas Petazzoni ; Nishanth
> Menon ; Rob Herring ; Pawel Moll
> ; Mark Rutland ; Ian
> Campbell ; Kumar Gala
> ; devicet...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Geert Uytterhoeven ; Linus
> Walleij 
> Subject: Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure
> 
> EXTERNAL MAIL
> 
> 
> Hi Boris
> 
> 
> Às 8:36 PM de 2/26/2018, Boris Brezillon escreveu:
> > Hi Vitor,
> >
> > On Mon, 26 Feb 2018 18:58:15 +
> > Vitor Soares  wrote:
> >
> > +/**
> > + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed
> to a
> > + * specific device
> > + *
> > + * @dev: device with which the transfers should be done
> > + * @xfers: array of transfers
> > + * @nxfers: number of transfers
> > + *
> > + * Initiate one or several private SDR transfers with @dev.
> > + *
> > + * This function can sleep and thus cannot be called in atomic
> context.
> > + *
> > + * Return: 0 in case of success, a negative error core otherwise.
> > + */
> > +int i3c_device_do_priv_xfers(struct i3c_device *dev,
> > +struct i3c_priv_xfer *xfers,
> > +int nxfers)
> > +{
> > +   struct i3c_master_controller *master;
> > +   int i, ret;
> > +
> > +   master = i3c_device_get_master(dev);
> > +   if (!master)
> > +   return -EINVAL;
> > +
> > +   i3c_bus_normaluse_lock(master->bus);
> > +   for (i = 0; i < nxfers; i++)
> > +   xfers[i].addr = dev->info.dyn_addr;
> > +
> > +   ret = i3c_master_do_priv_xfers_locked(master, xfers,
> nxfers);
> > +   i3c_bus_normaluse_unlock(master->bus);
> > +
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);
>   The controller should know the speed mode for each xfer. The SDR0
>  mode is used by default but if any device have read or write speed
>  limitations the controller can use SDRx.
> >>> I might be wrong, but that's not my understanding of the spec. A
> >>> device can express a speed limitation for SDR priv transfers, but
> >>> this limitation applies to all SDR transfers.
> >>>
> >>> The speed R/W speed limitation is encoded in the device object, so,
> >>> if the controller has to configure that on a per-transfer basis, one
> >>> solution would be to pass the device to the ->priv_xfers().
> >> The speed R/W limitation is only for private transfers. Also the
> >> device can have a limitation to write and not for read data.
> >> This information is obtained with the command GETMXDS which returns
> >> the Maximum Sustained Data Rate for non-CCC messages.
> > And that's exactly what I expose in i3c_device_info, which is embedded
> > in i3c_device, so you should have all the information you need to
> > determine the speed in the controller driver if ->priv_xfer() is
> > passed the device attached to those transfers. Would that be okay if
> > we pass an i3c_device object to ->priv_xfers()?
> 
> If you pass the i3c_device to ->priv_xfer(), then you won't need the address
> too.
> 
> Maybe someone else can give other point of view.
> 
> >>>
>  This could be also applied to i2c transfers.
> >>> Not really. The max SCL frequency is something that applies to the
> >>> whole bus, because all I2C devices have to decode the address when
> >>> messages are sent on the bus to determine if they should ignore or
> >>> process the message.
> >>>
> > +#endif /* I3C_INTERNAL_H */
> > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c new file
> > mode 100644 index ..1c85abac08d5
> > --- /dev/null
> > +++ b/drivers/i3c/master.c
> > @@ -0,0 +1,1433 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2017 Cadence Design 

Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

[Claudiu Beznea]

On 27.02.2018 17:38, Daniel Thompson wrote:
> On Tue, Feb 27, 2018 at 01:40:58PM +0200, Claudiu Beznea wrote:
>> On 27.02.2018 12:54, Daniel Thompson wrote:
>>> On Mon, Feb 26, 2018 at 04:24:15PM +0200, Claudiu Beznea wrote:
 On 26.02.2018 11:57, Jani Nikula wrote:
> On Thu, 22 Feb 2018, Daniel Thompson  wrote:
>> On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
>>> Add PWM mode to pwm_config() function. The drivers which uses 
>>> pwm_config()
>>> were adapted to this change.
>>>
>>> Signed-off-by: Claudiu Beznea 
>>> ---
>>>  arch/arm/mach-s3c24xx/mach-rx1950.c  | 11 +--
>>>  drivers/bus/ts-nbus.c|  2 +-
>>>  drivers/clk/clk-pwm.c|  3 ++-
>>>  drivers/gpu/drm/i915/intel_panel.c   | 17 ++---
>>>  drivers/hwmon/pwm-fan.c  |  2 +-
>>>  drivers/input/misc/max77693-haptic.c |  2 +-
>>>  drivers/input/misc/max8997_haptic.c  |  6 +-
>>>  drivers/leds/leds-pwm.c  |  5 -
>>>  drivers/media/rc/ir-rx51.c   |  5 -
>>>  drivers/media/rc/pwm-ir-tx.c |  5 -
>>>  drivers/video/backlight/lm3630a_bl.c |  4 +++-
>>>  drivers/video/backlight/lp855x_bl.c  |  4 +++-
>>>  drivers/video/backlight/lp8788_bl.c  |  5 -
>>>  drivers/video/backlight/pwm_bl.c | 11 +--
>>>  drivers/video/fbdev/ssd1307fb.c  |  3 ++-
>>>  include/linux/pwm.h  |  6 --
>>>  16 files changed, 70 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/video/backlight/lm3630a_bl.c 
>>> b/drivers/video/backlight/lm3630a_bl.c
>>> index 2030a6b77a09..696fa25dafd2 100644
>>> --- a/drivers/video/backlight/lm3630a_bl.c
>>> +++ b/drivers/video/backlight/lm3630a_bl.c
>>> @@ -165,8 +165,10 @@ static void lm3630a_pwm_ctrl(struct lm3630a_chip 
>>> *pchip, int br, int br_max)
>>>  {
>>> unsigned int period = pchip->pdata->pwm_period;
>>> unsigned int duty = br * period / br_max;
>>> +   struct pwm_caps caps = { };
>>>  
>>> -   pwm_config(pchip->pwmd, duty, period);
>>> +   pwm_get_caps(pchip->pwmd->chip, pchip->pwmd, );
>>> +   pwm_config(pchip->pwmd, duty, period, BIT(ffs(caps.modes) - 1));
>>
>> Well... I admit I've only really looked at the patches that impact 
>> backlight but dispersing this really odd looking bit twiddling 
>> throughout the kernel doesn't strike me a great API design.
>>
>> IMHO callers should not be required to find the first set bit in
>> some specially crafted set of capability bits simply to get sane 
>> default behaviour.
>
> Agreed. IMHO the regular use case becomes rather tedious, ugly, and
> error prone.

 Using simply PWM_MODE(NORMAL) instead of BIT(ffs(caps.modes) - 1) would be 
 OK
 from your side?

 Or, what about using a function like pwm_mode_first() to get the first 
 supported
 mode by PWM channel?

 Or, would you prefer to solve this inside pwm_config() function, let's 
 say, in
 case an invalid mode is passed as argument, to let pwm_config() to choose 
 the
 first available PWM mode for PWM channel passed as argument?
>>>
>>> What is it that actually needs solving?
>>>
>>> If a driver requests normal mode and the PWM driver cannot support it
>>> why not just return an error an move on.
>> Because, simply, I wasn't aware of what these PWM client drivers needs for.
> 
> I'm afraid you have confused me here.
> 
> Didn't you just *add* the whole concept of PWM caps with your patches?
> How could any existing call site expect anything except normal mode.
> Until now there has been no possiblity to request anything else.
Agree. And agree I was confusing in previous email, sorry about that. And
agree that there was nothing before and everything should work with PWM
normal mode.

When I choose to have BIT(ffs(caps.modes)) instead of PWM_MODE(NORMAL) I
was thinking at having these pwm_config() calls working all the time having
in mind that in future the PWM controllers that these drivers use, might
change in terms of PWM supported modes.

Thank you,
Claudiu Beznea

> 
> 
>>> Put another way, what is the use case for secretly adopting a mode the
>>> caller didn't want? Under what circumstances is this a good thing?
>> No one... But I wasn't aware of what the PWM clients needs for from their PWM
>> controllers. At this moment having BIT(ffs(caps.modes)) instead of
>> PWM_MODE(NORMAL) is mostly the same since all the driver that has not 
>> explicitly
>> registered PWM caps will use PWM normal mode.
>>
>> I will use PWM_MODE(NORMAL) instead of this in all the cases if this is OK 
>> from
>> your side.
>>
>> Thank you,
>> Claudiu Beznea
>>>
>>>
>>> Daniel.
>>>
> 
--
To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH v2 2/7] i3c: Add core I3C infrastructure

[Vitor Soares]

Hi Boris


Às 8:36 PM de 2/26/2018, Boris Brezillon escreveu:
> Hi Vitor,
>
> On Mon, 26 Feb 2018 18:58:15 +
> Vitor Soares  wrote:
>
> +/**
> + * i3c_device_do_priv_xfers() - do I3C SDR private transfers directed to 
> a
> + *   specific device
> + *
> + * @dev: device with which the transfers should be done
> + * @xfers: array of transfers
> + * @nxfers: number of transfers
> + *
> + * Initiate one or several private SDR transfers with @dev.
> + *
> + * This function can sleep and thus cannot be called in atomic context.
> + *
> + * Return: 0 in case of success, a negative error core otherwise.
> + */
> +int i3c_device_do_priv_xfers(struct i3c_device *dev,
> +  struct i3c_priv_xfer *xfers,
> +  int nxfers)
> +{
> + struct i3c_master_controller *master;
> + int i, ret;
> +
> + master = i3c_device_get_master(dev);
> + if (!master)
> + return -EINVAL;
> +
> + i3c_bus_normaluse_lock(master->bus);
> + for (i = 0; i < nxfers; i++)
> + xfers[i].addr = dev->info.dyn_addr;
> +
> + ret = i3c_master_do_priv_xfers_locked(master, xfers, nxfers);
> + i3c_bus_normaluse_unlock(master->bus);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(i3c_device_do_priv_xfers);
  The controller should know the speed mode for each xfer. The SDR0 mode 
 is used by default but if any device have read or write speed 
 limitations the controller can use SDRx.  
>>> I might be wrong, but that's not my understanding of the spec. A device
>>> can express a speed limitation for SDR priv transfers, but this
>>> limitation applies to all SDR transfers.
>>>
>>> The speed R/W speed limitation is encoded in the device object, so, if
>>> the controller has to configure that on a per-transfer basis, one
>>> solution would be to pass the device to the ->priv_xfers().  
>> The speed R/W limitation is only for private transfers. Also the device can 
>> have
>> a limitation to write and not for read data.
>> This information is obtained with the command GETMXDS which returns the 
>> Maximum
>> Sustained Data Rate for non-CCC messages.
> And that's exactly what I expose in i3c_device_info, which is embedded
> in i3c_device, so you should have all the information you need to
> determine the speed in the controller driver if ->priv_xfer() is passed
> the device attached to those transfers. Would that be okay if we pass an
> i3c_device object to ->priv_xfers()?

If you pass the i3c_device to ->priv_xfer(), then you won't need the address 
too.

Maybe someone else can give other point of view.

>>>  
 This could be also applied to i2c transfers.  
>>> Not really. The max SCL frequency is something that applies to the
>>> whole bus, because all I2C devices have to decode the address when
>>> messages are sent on the bus to determine if they should ignore or
>>> process the message.
>>>  
> +#endif /* I3C_INTERNAL_H */
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> new file mode 100644
> index ..1c85abac08d5
> --- /dev/null
> +++ b/drivers/i3c/master.c
> @@ -0,0 +1,1433 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2017 Cadence Design Systems Inc.
> + *
> + * Author: Boris Brezillon
> + */
> +
> +#include 
> +
> +#include "internals.h"
> +
> +/**
> + * i3c_master_entdaa_locked() - start a DAA (Dynamic Address Assignment)
> + *   procedure
> + * @master: master used to send frames on the bus
> + *
> + * Send a ENTDAA CCC command to start a DAA procedure.
> + *
> + * Note that this function only sends the ENTDAA CCC command, all the 
> logic
> + * behind dynamic address assignment has to be handled in the I3C master
> + * driver.
> + *
> + * This function must be called with the bus lock held in write mode.
> + *
> + * Return: 0 in case of success, a negative error code otherwise.
> + */
> +int i3c_master_entdaa_locked(struct i3c_master_controller *master)
> +{
> + struct i3c_ccc_cmd_dest dest = { };
> + struct i3c_ccc_cmd cmd = { };
> + int ret;
> +
> + dest.addr = I3C_BROADCAST_ADDR;
> + cmd.dests = 
> + cmd.ndests = 1;
> + cmd.rnw = false;
> + cmd.id = I3C_CCC_ENTDAA;
> +
> + ret = i3c_master_send_ccc_cmd_locked(master, );
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(i3c_master_entdaa_locked);
  can you explain the process?  
>>> Not sure what you mean. The ENTDAA is just a CCC command that is used
>>> to trigger a DAA procedure. What the master controller does when it
>>> sends such a command is likely to be controller 

Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

[Daniel Thompson]

On Tue, Feb 27, 2018 at 01:40:58PM +0200, Claudiu Beznea wrote:
> On 27.02.2018 12:54, Daniel Thompson wrote:
> > On Mon, Feb 26, 2018 at 04:24:15PM +0200, Claudiu Beznea wrote:
> >> On 26.02.2018 11:57, Jani Nikula wrote:
> >>> On Thu, 22 Feb 2018, Daniel Thompson  wrote:
>  On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
> > Add PWM mode to pwm_config() function. The drivers which uses 
> > pwm_config()
> > were adapted to this change.
> >
> > Signed-off-by: Claudiu Beznea 
> > ---
> >  arch/arm/mach-s3c24xx/mach-rx1950.c  | 11 +--
> >  drivers/bus/ts-nbus.c|  2 +-
> >  drivers/clk/clk-pwm.c|  3 ++-
> >  drivers/gpu/drm/i915/intel_panel.c   | 17 ++---
> >  drivers/hwmon/pwm-fan.c  |  2 +-
> >  drivers/input/misc/max77693-haptic.c |  2 +-
> >  drivers/input/misc/max8997_haptic.c  |  6 +-
> >  drivers/leds/leds-pwm.c  |  5 -
> >  drivers/media/rc/ir-rx51.c   |  5 -
> >  drivers/media/rc/pwm-ir-tx.c |  5 -
> >  drivers/video/backlight/lm3630a_bl.c |  4 +++-
> >  drivers/video/backlight/lp855x_bl.c  |  4 +++-
> >  drivers/video/backlight/lp8788_bl.c  |  5 -
> >  drivers/video/backlight/pwm_bl.c | 11 +--
> >  drivers/video/fbdev/ssd1307fb.c  |  3 ++-
> >  include/linux/pwm.h  |  6 --
> >  16 files changed, 70 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/video/backlight/lm3630a_bl.c 
> > b/drivers/video/backlight/lm3630a_bl.c
> > index 2030a6b77a09..696fa25dafd2 100644
> > --- a/drivers/video/backlight/lm3630a_bl.c
> > +++ b/drivers/video/backlight/lm3630a_bl.c
> > @@ -165,8 +165,10 @@ static void lm3630a_pwm_ctrl(struct lm3630a_chip 
> > *pchip, int br, int br_max)
> >  {
> > unsigned int period = pchip->pdata->pwm_period;
> > unsigned int duty = br * period / br_max;
> > +   struct pwm_caps caps = { };
> >  
> > -   pwm_config(pchip->pwmd, duty, period);
> > +   pwm_get_caps(pchip->pwmd->chip, pchip->pwmd, );
> > +   pwm_config(pchip->pwmd, duty, period, BIT(ffs(caps.modes) - 1));
> 
>  Well... I admit I've only really looked at the patches that impact 
>  backlight but dispersing this really odd looking bit twiddling 
>  throughout the kernel doesn't strike me a great API design.
> 
>  IMHO callers should not be required to find the first set bit in
>  some specially crafted set of capability bits simply to get sane 
>  default behaviour.
> >>>
> >>> Agreed. IMHO the regular use case becomes rather tedious, ugly, and
> >>> error prone.
> >>
> >> Using simply PWM_MODE(NORMAL) instead of BIT(ffs(caps.modes) - 1) would be 
> >> OK
> >> from your side?
> >>
> >> Or, what about using a function like pwm_mode_first() to get the first 
> >> supported
> >> mode by PWM channel?
> >>
> >> Or, would you prefer to solve this inside pwm_config() function, let's 
> >> say, in
> >> case an invalid mode is passed as argument, to let pwm_config() to choose 
> >> the
> >> first available PWM mode for PWM channel passed as argument?
> > 
> > What is it that actually needs solving?
> > 
> > If a driver requests normal mode and the PWM driver cannot support it
> > why not just return an error an move on.
> Because, simply, I wasn't aware of what these PWM client drivers needs for.

I'm afraid you have confused me here.

Didn't you just *add* the whole concept of PWM caps with your patches?
How could any existing call site expect anything except normal mode.
Until now there has been no possiblity to request anything else.


> > Put another way, what is the use case for secretly adopting a mode the
> > caller didn't want? Under what circumstances is this a good thing?
> No one... But I wasn't aware of what the PWM clients needs for from their PWM
> controllers. At this moment having BIT(ffs(caps.modes)) instead of
> PWM_MODE(NORMAL) is mostly the same since all the driver that has not 
> explicitly
> registered PWM caps will use PWM normal mode.
> 
> I will use PWM_MODE(NORMAL) instead of this in all the cases if this is OK 
> from
> your side.
> 
> Thank you,
> Claudiu Beznea
> > 
> > 
> > Daniel.
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 7/7] tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP

[Karthik Ramasubramanian]

On 1/19/2018 12:12 AM, Bjorn Andersson wrote:

On Fri 12 Jan 17:05 PST 2018, Karthikeyan Ramasubramanian wrote:


This driver supports GENI based UART Controller in the Qualcomm SOCs. The
Qualcomm Generic Interface (GENI) is a programmable module supporting a
wide range of serial interfaces including UART. This driver support console
operations using FIFO mode of transfer.

Signed-off-by: Girish Mahadevan 
Signed-off-by: Karthikeyan Ramasubramanian 
Signed-off-by: Sagar Dharia 


Please disregard my previous answer to this patch, I hit the wrong key
combo while stashing my reply.


---
  drivers/tty/serial/Kconfig|   10 +
  drivers/tty/serial/Makefile   |1 +
  drivers/tty/serial/qcom_geni_serial.c | 1414 +
  3 files changed, 1425 insertions(+)
  create mode 100644 drivers/tty/serial/qcom_geni_serial.c

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index b788fee..1be30e5 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1098,6 +1098,16 @@ config SERIAL_MSM_CONSOLE
select SERIAL_CORE_CONSOLE
select SERIAL_EARLYCON
  
+config SERIAL_QCOM_GENI

+   tristate "QCOM on-chip GENI based serial port support"
+   depends on ARCH_QCOM


depend on the GENI wrapper as well.

Ok.


[..]

diff --git a/drivers/tty/serial/qcom_geni_serial.c 
b/drivers/tty/serial/qcom_geni_serial.c
new file mode 100644
index 000..0dbd329
--- /dev/null
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -0,0 +1,1414 @@
+/*
+ * Copyright (c) 2017-2018, The Linux foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that 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.
+ */


SPDX license header.

Ok.



+
+#include 


Unused


+#include 


Unused?

Ok, I will remove the unused header files.



+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* UART specific GENI registers */
+#define SE_UART_TX_TRANS_CFG   (0x25C)


Drop the parenthesis

Ok.


[..]

+static int owr;
+module_param(owr, int, 0644);


What's this?

It is not required. I will drop it.



+
+struct qcom_geni_serial_port {
+   struct uart_port uport;
+   char name[20];
+   unsigned int tx_fifo_depth;


size_t is a good type for keeping track of sizes.

Since these are values read from registers, I will keep the type as u32.



+   unsigned int tx_fifo_width;
+   unsigned int rx_fifo_depth;
+   unsigned int tx_wm;
+   unsigned int rx_wm;
+   unsigned int rx_rfr;


size_t for sizes.


+   int xfer_mode;
+   bool port_setup;
+   unsigned int *rx_fifo;


The fifo is typeless, so it should be void *. It is however only ever
used as a local variable in handle_rx_console() so drop this.
I will drop it for now. It most likely will get re-introduced later with 
the non-console UART patch.



+   int (*handle_rx)(struct uart_port *uport,
+   unsigned int rx_fifo_wc,
+   unsigned int rx_last_byte_valid,
+   unsigned int rx_last,
+   bool drop_rx);
+   struct device *wrapper_dev;
+   struct geni_se_rsc serial_rsc;
+   unsigned int xmit_size;


In other drivers we read bytes of the xmit buffer at xmit->tail, write
to hardware FIFO and update xmit->tail. Why do you keep a going delta
between the tail and our real tail?
If the console log buffer size is very high, then updating the tail in a 
live manner leads to this driver getting flooded and extremely busy. 
Hence it does not yield the CPU for 10s of seconds. This approach 
introduces some sort of flow control between the console driver and this 
UART controller driver.



+   void *rx_buf;
+   unsigned int cur_baud;
+};
+

[..]

+
+#define GET_DEV_PORT(uport) \
+   container_of(uport, struct qcom_geni_serial_port, uport)


The idiomatic name for this macro would be something like "to_dev_port".

Ok.


The use of "uport" as macro parameter makes this only work if the
parameter is "uport", otherwise the macro will replace the last part of
the container_of as well.

Ok.


[..]

+static struct qcom_geni_serial_port *get_port_from_line(int line)
+{
+   struct qcom_geni_serial_port *port = NULL;
+
+   if ((line < 0) || (line >= GENI_UART_CONS_PORTS))
+   port = ERR_PTR(-ENXIO);


You need to return here as well...


+   port = _geni_console_port;
+   return port;


Drop the "port" 

[GIT PULL] Remove metag architecture

[James Hogan]

Hi Arnd,

On Fri, Feb 23, 2018 at 01:26:09PM +0100, Arnd Bergmann wrote:
> On Fri, Feb 23, 2018 at 12:02 PM, James Hogan  wrote:
> > I'm happy to put v2 in linux-next now (only patch 4 has changed, I just
> > sent an updated version), and send you a pull request early next week so
> > you can take it from there. The patches can't be directly applied with
> > git-am anyway thanks to the -D option to make them more concise.
> >
> > Sound okay?
> 
> Yes, sounds good, thanks!

As discussed, here is a tagged branch to remove arch/metag and dependent
drivers. Its basically v2 with some acks added.

Cheers
James

The following changes since commit 91ab883eb21325ad80f3473633f794c78ac87f51:

  Linux 4.16-rc2 (2018-02-18 17:29:42 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag.git 
tags/metag_remove

for you to fetch changes up to ef9fb83815db7d7e03da9a0904b4ef352e633922:

  i2c: img-scb: Drop METAG dependency (2018-02-26 14:58:09 +)


Remove metag architecture

These patches remove the metag architecture and tightly dependent
drivers from the kernel. With the 4.16 kernel the ancient gcc 4.2.4
based metag toolchain we have been using is hitting compiler bugs, so
now seems a good time to drop it altogether.


James Hogan (13):
  metag: Remove arch/metag/
  docs: Remove metag docs
  docs: Remove remaining references to metag
  Drop a bunch of metag references
  irqchip: Remove metag irqchip drivers
  clocksource: Remove metag generic timer driver
  tty: Remove metag DA TTY and console driver
  MAINTAINERS/CREDITS: Drop METAG ARCHITECTURE
  pinctrl: Drop TZ1090 drivers
  gpio: Drop TZ1090 drivers
  watchdog: imgpdc: Drop METAG dependency
  media: img-ir: Drop METAG dependency
  i2c: img-scb: Drop METAG dependency

 CREDITS|5 +
 Documentation/00-INDEX |2 -
 Documentation/admin-guide/kernel-parameters.txt|4 -
 Documentation/dev-tools/kmemleak.rst   |2 +-
 .../devicetree/bindings/gpio/gpio-tz1090-pdc.txt   |   45 -
 .../devicetree/bindings/gpio/gpio-tz1090.txt   |   88 -
 Documentation/devicetree/bindings/metag/meta.txt   |   30 -
 .../bindings/pinctrl/img,tz1090-pdc-pinctrl.txt|  127 --
 .../bindings/pinctrl/img,tz1090-pinctrl.txt|  227 ---
 .../features/core/BPF-JIT/arch-support.txt |1 -
 .../core/generic-idle-thread/arch-support.txt  |1 -
 .../features/core/jump-labels/arch-support.txt |1 -
 .../features/core/tracehook/arch-support.txt   |1 -
 .../features/debug/KASAN/arch-support.txt  |1 -
 .../debug/gcov-profile-all/arch-support.txt|1 -
 Documentation/features/debug/kgdb/arch-support.txt |1 -
 .../debug/kprobes-on-ftrace/arch-support.txt   |1 -
 .../features/debug/kprobes/arch-support.txt|1 -
 .../features/debug/kretprobes/arch-support.txt |1 -
 .../features/debug/optprobes/arch-support.txt  |1 -
 .../features/debug/stackprotector/arch-support.txt |1 -
 .../features/debug/uprobes/arch-support.txt|1 -
 .../debug/user-ret-profiler/arch-support.txt   |1 -
 .../features/io/dma-api-debug/arch-support.txt |1 -
 .../features/io/dma-contiguous/arch-support.txt|1 -
 .../features/io/sg-chain/arch-support.txt  |1 -
 .../features/lib/strncasecmp/arch-support.txt  |1 -
 .../locking/cmpxchg-local/arch-support.txt |1 -
 .../features/locking/lockdep/arch-support.txt  |1 -
 .../locking/queued-rwlocks/arch-support.txt|1 -
 .../locking/queued-spinlocks/arch-support.txt  |1 -
 .../locking/rwsem-optimized/arch-support.txt   |1 -
 .../features/perf/kprobes-event/arch-support.txt   |1 -
 .../features/perf/perf-regs/arch-support.txt   |1 -
 .../features/perf/perf-stackdump/arch-support.txt  |1 -
 .../sched/membarrier-sync-core/arch-support.txt|1 -
 .../features/sched/numa-balancing/arch-support.txt |1 -
 .../seccomp/seccomp-filter/arch-support.txt|1 -
 .../time/arch-tick-broadcast/arch-support.txt  |1 -
 .../features/time/clockevents/arch-support.txt |1 -
 .../time/context-tracking/arch-support.txt |1 -
 .../features/time/irq-time-acct/arch-support.txt   |1 -
 .../time/modern-timekeeping/arch-support.txt   |1 -
 .../features/time/virt-cpuacct/arch-support.txt|1 -
 .../features/vm/ELF-ASLR/arch-support.txt  |1 -
 .../features/vm/PG_uncached/arch-support.txt   |1 -
 Documentation/features/vm/THP/arch-support.txt |1 -
 Documentation/features/vm/TLB/arch-support.txt |1 -
 .../features/vm/huge-vmap/arch-support.txt |1 -
 

Re: [PATCH v2 6/7] dt-bindings: serial: Add bindings for GENI based UART Controller

[Karthik Ramasubramanian]

On 1/16/2018 11:35 PM, Bjorn Andersson wrote:

On Fri 12 Jan 17:05 PST 2018, Karthikeyan Ramasubramanian wrote:


Add device tree binding support for GENI based UART Controller in the
QUP Wrapper.

Signed-off-by: Karthikeyan Ramasubramanian 
Signed-off-by: Girish Mahadevan 
---
  .../devicetree/bindings/serial/qcom,geni-uart.txt  | 29 ++
  .../devicetree/bindings/soc/qcom/qcom,geni-se.txt  | 13 ++
  2 files changed, 42 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/serial/qcom,geni-uart.txt

diff --git a/Documentation/devicetree/bindings/serial/qcom,geni-uart.txt 
b/Documentation/devicetree/bindings/serial/qcom,geni-uart.txt
new file mode 100644
index 000..e7b9e24
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/qcom,geni-uart.txt
@@ -0,0 +1,29 @@
+Qualcomm Technologies Inc. GENI Serial Engine based UART Controller
+
+The Generic Interface (GENI) Serial Engine based UART controller supports
+console use-cases and is supported only by GENI based Qualcomm Universal
+Peripheral (QUP) cores.
+
+Required properties:
+- compatible: should contain "qcom,geni-debug-uart".


Why is this uart a _debug_ uart? Is there a separate binding for the
geni-uart?

Yes. It will be uploaded at a later point in time.


I like that your naming here matches my suggestion with qcom,geni-i2c.


+- reg: Should contain UART register location and length.
+- reg-names: Should contain "se-phys".


No need to specify reg-names for a single reg.

Ok.



+- interrupts: Should contain UART core interrupts.
+- clock-names: Should contain "se-clk".


Omit the "clk"

Ok.



+- clocks: clocks needed for UART, includes the core clock.


Be more specific.

Ok.



+- pinctrl-names/pinctrl-0/1: The GPIOs assigned to this core. The names
+  Should be "active" and "sleep" for the pin confuguration when core is active
+  or when entering sleep state.


Omit pinctrl information.

Ok.



+
+Example:
+uart0: qcom,serial@a88000 {


Don't use qcom, in node name. This should be named "serial".

Ok.



+   compatible = "qcom,geni-debug-uart";
+   reg = <0xa88000 0x7000>;
+   reg-names = "se-phys";
+   interrupts = <0 355 0>;




Ok.



+   clock-names = "se-clk";
+   clocks = <_gcc GCC_QUPV3_WRAP0_S0_CLK>;
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_1_uart_3_active>;
+   pinctrl-1 = <_1_uart_3_sleep>;
+};


Regards,
Bjorn


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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2, 7/7] tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP

[Karthik Ramasubramanian]

On 2/23/2018 11:06 AM, Guenter Roeck wrote:

On Fri, Jan 12, 2018 at 06:05:47PM -0700, Karthikeyan Ramasubramanian wrote:

This driver supports GENI based UART Controller in the Qualcomm SOCs. The
Qualcomm Generic Interface (GENI) is a programmable module supporting a
wide range of serial interfaces including UART. This driver support console
operations using FIFO mode of transfer.

Signed-off-by: Girish Mahadevan 
Signed-off-by: Karthikeyan Ramasubramanian 
Signed-off-by: Sagar Dharia 
---
  drivers/tty/serial/Kconfig|   10 +
  drivers/tty/serial/Makefile   |1 +
  drivers/tty/serial/qcom_geni_serial.c | 1414 +
  3 files changed, 1425 insertions(+)
  create mode 100644 drivers/tty/serial/qcom_geni_serial.c

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index b788fee..1be30e5 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1098,6 +1098,16 @@ config SERIAL_MSM_CONSOLE
select SERIAL_CORE_CONSOLE
select SERIAL_EARLYCON
  
+config SERIAL_QCOM_GENI

+   tristate "QCOM on-chip GENI based serial port support"
+   depends on ARCH_QCOM
+   select SERIAL_CORE
+   select SERIAL_CORE_CONSOLE


Serial console drivers have to be bool, not tristate.
Building a console driver as module doesn't make sense
(it is needed before modules are loaded). It also results
in a build failure due to a symbol which is not exported.

I will mark it as bool.



+   select SERIAL_EARLYCON
+   help
+ Serial driver for Qualcomm Technologies Inc's GENI based QUP
+ hardware.
+
  config SERIAL_VT8500
bool "VIA VT8500 on-chip serial port support"
depends on ARCH_VT8500
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index 842d185..64a8d82 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_SERIAL_SGI_IOC3) += ioc3_serial.o
  obj-$(CONFIG_SERIAL_ATMEL) += atmel_serial.o
  obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
  obj-$(CONFIG_SERIAL_MSM) += msm_serial.o
+obj-$(CONFIG_SERIAL_QCOM_GENI) += qcom_geni_serial.o
  obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
  obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
  obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
diff --git a/drivers/tty/serial/qcom_geni_serial.c 
b/drivers/tty/serial/qcom_geni_serial.c
new file mode 100644
index 000..0dbd329
--- /dev/null
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -0,0 +1,1414 @@
+/*
+ * Copyright (c) 2017-2018, The Linux foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* UART specific GENI registers */
+#define SE_UART_TX_TRANS_CFG   (0x25C)
+#define SE_UART_TX_WORD_LEN(0x268)
+#define SE_UART_TX_STOP_BIT_LEN(0x26C)
+#define SE_UART_TX_TRANS_LEN   (0x270)
+#define SE_UART_RX_TRANS_CFG   (0x280)
+#define SE_UART_RX_WORD_LEN(0x28C)
+#define SE_UART_RX_STALE_CNT   (0x294)
+#define SE_UART_TX_PARITY_CFG  (0x2A4)
+#define SE_UART_RX_PARITY_CFG  (0x2A8)
+
+/* SE_UART_TRANS_CFG */
+#define UART_TX_PAR_EN (BIT(0))
+#define UART_CTS_MASK  (BIT(1))
+
+/* SE_UART_TX_WORD_LEN */
+#define TX_WORD_LEN_MSK(GENMASK(9, 0))
+
+/* SE_UART_TX_STOP_BIT_LEN */
+#define TX_STOP_BIT_LEN_MSK(GENMASK(23, 0))
+#define TX_STOP_BIT_LEN_1  (0)
+#define TX_STOP_BIT_LEN_1_5(1)
+#define TX_STOP_BIT_LEN_2  (2)
+
+/* SE_UART_TX_TRANS_LEN */
+#define TX_TRANS_LEN_MSK   (GENMASK(23, 0))
+
+/* SE_UART_RX_TRANS_CFG */
+#define UART_RX_INS_STATUS_BIT (BIT(2))
+#define UART_RX_PAR_EN (BIT(3))
+
+/* SE_UART_RX_WORD_LEN */
+#define RX_WORD_LEN_MASK   (GENMASK(9, 0))
+
+/* SE_UART_RX_STALE_CNT */
+#define RX_STALE_CNT   (GENMASK(23, 0))
+
+/* SE_UART_TX_PARITY_CFG/RX_PARITY_CFG */
+#define PAR_CALC_EN(BIT(0))
+#define PAR_MODE_MSK   (GENMASK(2, 1))
+#define PAR_MODE_SHFT  (1)
+#define PAR_EVEN   (0x00)
+#define PAR_ODD(0x01)
+#define PAR_SPACE  (0x10)
+#define PAR_MARK   (0x11)
+
+/* UART M_CMD OP codes */
+#define UART_START_TX  (0x1)
+#define UART_START_BREAK   (0x4)
+#define UART_STOP_BREAK(0x5)

Re: [PATCH v2 5/7] i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller

[Karthik Ramasubramanian]

On 1/17/2018 10:23 PM, Bjorn Andersson wrote:

On Fri 12 Jan 17:05 PST 2018, Karthikeyan Ramasubramanian wrote:


This bus driver supports the GENI based i2c hardware controller in the
Qualcomm SOCs. The Qualcomm Generic Interface (GENI) is a programmable
module supporting a wide range of serial interfaces including I2C. The
driver supports FIFO mode and DMA mode of transfer and switches modes
dynamically depending on the size of the transfer.

Signed-off-by: Karthikeyan Ramasubramanian 
Signed-off-by: Sagar Dharia 
Signed-off-by: Girish Mahadevan 
---
  drivers/i2c/busses/Kconfig |  10 +
  drivers/i2c/busses/Makefile|   1 +
  drivers/i2c/busses/i2c-qcom-geni.c | 656 +
  3 files changed, 667 insertions(+)
  create mode 100644 drivers/i2c/busses/i2c-qcom-geni.c

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 009345d..caef309 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -838,6 +838,16 @@ config I2C_PXA_SLAVE
  is necessary for systems where the PXA may be a target on the
  I2C bus.
  
+config I2C_QCOM_GENI

+   tristate "Qualcomm Technologies Inc.'s GENI based I2C controller"
+   depends on ARCH_QCOM


Just depend on the GENI wrapper as well.

Ok.



+   help
+ If you say yes to this option, support will be included for the
+ built-in I2C interface on the Qualcomm Technologies Inc.'s SoCs.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-qcom-geni.
+
  config I2C_QUP
tristate "Qualcomm QUP based I2C controller"
depends on ARCH_QCOM
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 2ce8576..201fce1 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -84,6 +84,7 @@ obj-$(CONFIG_I2C_PNX) += i2c-pnx.o
  obj-$(CONFIG_I2C_PUV3)+= i2c-puv3.o
  obj-$(CONFIG_I2C_PXA) += i2c-pxa.o
  obj-$(CONFIG_I2C_PXA_PCI) += i2c-pxa-pci.o
+obj-$(CONFIG_I2C_QCOM_GENI)+= i2c-qcom-geni.o
  obj-$(CONFIG_I2C_QUP) += i2c-qup.o
  obj-$(CONFIG_I2C_RIIC)+= i2c-riic.o
  obj-$(CONFIG_I2C_RK3X)+= i2c-rk3x.o
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c 
b/drivers/i2c/busses/i2c-qcom-geni.c
new file mode 100644
index 000..59ad4da
--- /dev/null
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -0,0 +1,656 @@
+/*
+ * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that 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.
+ *
+ */


Use SPDX license header.

Ok.



+
+#include 
+#include 


Unused?

Ok, I will remove unused header files.



+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SE_I2C_TX_TRANS_LEN(0x26C)


Drop the parenthesis, when not needed.

Ok.



+#define SE_I2C_RX_TRANS_LEN(0x270)
+#define SE_I2C_SCL_COUNTERS(0x278)
+#define SE_GENI_IOS(0x908)
+
+#define SE_I2C_ERR  (M_CMD_OVERRUN_EN | M_ILLEGAL_CMD_EN | M_CMD_FAILURE_EN |\
+   M_GP_IRQ_1_EN | M_GP_IRQ_3_EN | M_GP_IRQ_4_EN)
+#define SE_I2C_ABORT (1U << 1)
+/* M_CMD OP codes for I2C */
+#define I2C_WRITE  (0x1)
+#define I2C_READ   (0x2)
+#define I2C_WRITE_READ (0x3)
+#define I2C_ADDR_ONLY  (0x4)
+#define I2C_BUS_CLEAR  (0x6)
+#define I2C_STOP_ON_BUS(0x7)
+/* M_CMD params for I2C */
+#define PRE_CMD_DELAY  (BIT(0))
+#define TIMESTAMP_BEFORE   (BIT(1))
+#define STOP_STRETCH   (BIT(2))
+#define TIMESTAMP_AFTER(BIT(3))
+#define POST_COMMAND_DELAY (BIT(4))
+#define IGNORE_ADD_NACK(BIT(6))
+#define READ_FINISHED_WITH_ACK (BIT(7))
+#define BYPASS_ADDR_PHASE  (BIT(8))
+#define SLV_ADDR_MSK   (GENMASK(15, 9))
+#define SLV_ADDR_SHFT  (9)
+
+#define I2C_CORE2X_VOTE(1)
+#define GP_IRQ00
+#define GP_IRQ11
+#define GP_IRQ22
+#define GP_IRQ33
+#define GP_IRQ44
+#define GP_IRQ55
+#define GENI_OVERRUN   6
+#define GENI_ILLEGAL_CMD   7
+#define GENI_ABORT_DONE8
+#define GENI_TIMEOUT   9
+
+#define I2C_NACK   GP_IRQ1
+#define I2C_BUS_PROTO  

Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

[Claudiu Beznea]

On 27.02.2018 12:54, Daniel Thompson wrote:
> On Mon, Feb 26, 2018 at 04:24:15PM +0200, Claudiu Beznea wrote:
>> On 26.02.2018 11:57, Jani Nikula wrote:
>>> On Thu, 22 Feb 2018, Daniel Thompson  wrote:
 On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
> Add PWM mode to pwm_config() function. The drivers which uses pwm_config()
> were adapted to this change.
>
> Signed-off-by: Claudiu Beznea 
> ---
>  arch/arm/mach-s3c24xx/mach-rx1950.c  | 11 +--
>  drivers/bus/ts-nbus.c|  2 +-
>  drivers/clk/clk-pwm.c|  3 ++-
>  drivers/gpu/drm/i915/intel_panel.c   | 17 ++---
>  drivers/hwmon/pwm-fan.c  |  2 +-
>  drivers/input/misc/max77693-haptic.c |  2 +-
>  drivers/input/misc/max8997_haptic.c  |  6 +-
>  drivers/leds/leds-pwm.c  |  5 -
>  drivers/media/rc/ir-rx51.c   |  5 -
>  drivers/media/rc/pwm-ir-tx.c |  5 -
>  drivers/video/backlight/lm3630a_bl.c |  4 +++-
>  drivers/video/backlight/lp855x_bl.c  |  4 +++-
>  drivers/video/backlight/lp8788_bl.c  |  5 -
>  drivers/video/backlight/pwm_bl.c | 11 +--
>  drivers/video/fbdev/ssd1307fb.c  |  3 ++-
>  include/linux/pwm.h  |  6 --
>  16 files changed, 70 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/video/backlight/lm3630a_bl.c 
> b/drivers/video/backlight/lm3630a_bl.c
> index 2030a6b77a09..696fa25dafd2 100644
> --- a/drivers/video/backlight/lm3630a_bl.c
> +++ b/drivers/video/backlight/lm3630a_bl.c
> @@ -165,8 +165,10 @@ static void lm3630a_pwm_ctrl(struct lm3630a_chip 
> *pchip, int br, int br_max)
>  {
>   unsigned int period = pchip->pdata->pwm_period;
>   unsigned int duty = br * period / br_max;
> + struct pwm_caps caps = { };
>  
> - pwm_config(pchip->pwmd, duty, period);
> + pwm_get_caps(pchip->pwmd->chip, pchip->pwmd, );
> + pwm_config(pchip->pwmd, duty, period, BIT(ffs(caps.modes) - 1));

 Well... I admit I've only really looked at the patches that impact 
 backlight but dispersing this really odd looking bit twiddling 
 throughout the kernel doesn't strike me a great API design.

 IMHO callers should not be required to find the first set bit in
 some specially crafted set of capability bits simply to get sane 
 default behaviour.
>>>
>>> Agreed. IMHO the regular use case becomes rather tedious, ugly, and
>>> error prone.
>>
>> Using simply PWM_MODE(NORMAL) instead of BIT(ffs(caps.modes) - 1) would be OK
>> from your side?
>>
>> Or, what about using a function like pwm_mode_first() to get the first 
>> supported
>> mode by PWM channel?
>>
>> Or, would you prefer to solve this inside pwm_config() function, let's say, 
>> in
>> case an invalid mode is passed as argument, to let pwm_config() to choose the
>> first available PWM mode for PWM channel passed as argument?
> 
> What is it that actually needs solving?
> 
> If a driver requests normal mode and the PWM driver cannot support it
> why not just return an error an move on.
Because, simply, I wasn't aware of what these PWM client drivers needs for.

> 
> Put another way, what is the use case for secretly adopting a mode the
> caller didn't want? Under what circumstances is this a good thing?
No one... But I wasn't aware of what the PWM clients needs for from their PWM
controllers. At this moment having BIT(ffs(caps.modes)) instead of
PWM_MODE(NORMAL) is mostly the same since all the driver that has not explicitly
registered PWM caps will use PWM normal mode.

I will use PWM_MODE(NORMAL) instead of this in all the cases if this is OK from
your side.

Thank you,
Claudiu Beznea
> 
> 
> Daniel.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

[Daniel Thompson]

On Mon, Feb 26, 2018 at 04:24:15PM +0200, Claudiu Beznea wrote:
> On 26.02.2018 11:57, Jani Nikula wrote:
> > On Thu, 22 Feb 2018, Daniel Thompson  wrote:
> >> On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
> >>> Add PWM mode to pwm_config() function. The drivers which uses pwm_config()
> >>> were adapted to this change.
> >>>
> >>> Signed-off-by: Claudiu Beznea 
> >>> ---
> >>>  arch/arm/mach-s3c24xx/mach-rx1950.c  | 11 +--
> >>>  drivers/bus/ts-nbus.c|  2 +-
> >>>  drivers/clk/clk-pwm.c|  3 ++-
> >>>  drivers/gpu/drm/i915/intel_panel.c   | 17 ++---
> >>>  drivers/hwmon/pwm-fan.c  |  2 +-
> >>>  drivers/input/misc/max77693-haptic.c |  2 +-
> >>>  drivers/input/misc/max8997_haptic.c  |  6 +-
> >>>  drivers/leds/leds-pwm.c  |  5 -
> >>>  drivers/media/rc/ir-rx51.c   |  5 -
> >>>  drivers/media/rc/pwm-ir-tx.c |  5 -
> >>>  drivers/video/backlight/lm3630a_bl.c |  4 +++-
> >>>  drivers/video/backlight/lp855x_bl.c  |  4 +++-
> >>>  drivers/video/backlight/lp8788_bl.c  |  5 -
> >>>  drivers/video/backlight/pwm_bl.c | 11 +--
> >>>  drivers/video/fbdev/ssd1307fb.c  |  3 ++-
> >>>  include/linux/pwm.h  |  6 --
> >>>  16 files changed, 70 insertions(+), 21 deletions(-)
> >>>
> >>> diff --git a/drivers/video/backlight/lm3630a_bl.c 
> >>> b/drivers/video/backlight/lm3630a_bl.c
> >>> index 2030a6b77a09..696fa25dafd2 100644
> >>> --- a/drivers/video/backlight/lm3630a_bl.c
> >>> +++ b/drivers/video/backlight/lm3630a_bl.c
> >>> @@ -165,8 +165,10 @@ static void lm3630a_pwm_ctrl(struct lm3630a_chip 
> >>> *pchip, int br, int br_max)
> >>>  {
> >>>   unsigned int period = pchip->pdata->pwm_period;
> >>>   unsigned int duty = br * period / br_max;
> >>> + struct pwm_caps caps = { };
> >>>  
> >>> - pwm_config(pchip->pwmd, duty, period);
> >>> + pwm_get_caps(pchip->pwmd->chip, pchip->pwmd, );
> >>> + pwm_config(pchip->pwmd, duty, period, BIT(ffs(caps.modes) - 1));
> >>
> >> Well... I admit I've only really looked at the patches that impact 
> >> backlight but dispersing this really odd looking bit twiddling 
> >> throughout the kernel doesn't strike me a great API design.
> >>
> >> IMHO callers should not be required to find the first set bit in
> >> some specially crafted set of capability bits simply to get sane 
> >> default behaviour.
> > 
> > Agreed. IMHO the regular use case becomes rather tedious, ugly, and
> > error prone.
> 
> Using simply PWM_MODE(NORMAL) instead of BIT(ffs(caps.modes) - 1) would be OK
> from your side?
>
> Or, what about using a function like pwm_mode_first() to get the first 
> supported
> mode by PWM channel?
> 
> Or, would you prefer to solve this inside pwm_config() function, let's say, in
> case an invalid mode is passed as argument, to let pwm_config() to choose the
> first available PWM mode for PWM channel passed as argument?

What is it that actually needs solving?

If a driver requests normal mode and the PWM driver cannot support it
why not just return an error an move on.

Put another way, what is the use case for secretly adopting a mode the
caller didn't want? Under what circumstances is this a good thing?


Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/17] Include linux trace docs to Sphinx TOC tree

[Du, Changbin]

Hello Steven and Corbet,
Ten days past, will you accept this serias? Thank you!

On Sat, Feb 17, 2018 at 01:39:33PM +0800, changbin...@intel.com wrote:
> From: Changbin Du 
> 
> Hi All,
> The linux tracers are so useful that I want to make the docs better. The 
> kernel
> now uses Sphinx to generate intelligent and beautiful documentation from
> reStructuredText files. I converted most of the Linux trace docs to rst format
> in this serias.
> 
> For you to preview, please visit below url:
> http://docservice.askxiong.com/linux-kernel/trace/index.html
> 
> Thank you!
> 
> Changbin Du (17):
>   Documentation: add Linux tracing to Sphinx TOC tree
>   trace doc: convert trace/ftrace-design.txt to rst format
>   trace doc: add ftrace-uses.rst to doc tree
>   trace doc: convert trace/tracepoint-analysis.txt to rst format
>   trace doc: convert trace/ftrace.txt to rst format
>   trace doc: convert trace/kprobetrace.txt to rst format
>   trace doc: convert trace/uprobetracer.txt to rst format
>   trace doc: convert trace/tracepoints.txt to rst format
>   trace doc: convert trace/events.txt to rst format
>   trace doc: convert trace/events-kmem.txt to rst format
>   trace doc: convert trace/events-power.txt to rst format
>   trace doc: convert trace/events-nmi.txt to rst format
>   trace doc: convert trace/events-msr.txt to rst format
>   trace doc: convert trace/mmiotrace.txt to rst format
>   trace doc: convert trace/hwlat_detector.txt to rst fromat
>   trace doc: convert trace/intel_th.txt to rst format
>   trace doc: convert trace/stm.txt to rst format
> 
>  Documentation/index.rst|1 +
>  .../trace/{events-kmem.txt => events-kmem.rst} |   50 +-
>  Documentation/trace/events-msr.rst |   40 +
>  Documentation/trace/events-msr.txt |   37 -
>  Documentation/trace/events-nmi.rst |   45 +
>  Documentation/trace/events-nmi.txt |   43 -
>  .../trace/{events-power.txt => events-power.rst}   |   52 +-
>  Documentation/trace/{events.txt => events.rst} |  669 ++--
>  .../trace/{ftrace-design.txt => ftrace-design.rst} |  252 +-
>  Documentation/trace/ftrace-uses.rst|   23 +-
>  Documentation/trace/ftrace.rst | 3332 
> 
>  Documentation/trace/ftrace.txt | 3220 ---
>  .../{hwlat_detector.txt => hwlat_detector.rst} |   26 +-
>  Documentation/trace/index.rst  |   23 +
>  Documentation/trace/{intel_th.txt => intel_th.rst} |   43 +-
>  .../trace/{kprobetrace.txt => kprobetrace.rst} |  100 +-
>  .../trace/{mmiotrace.txt => mmiotrace.rst} |   86 +-
>  Documentation/trace/{stm.txt => stm.rst}   |   23 +-
>  ...epoint-analysis.txt => tracepoint-analysis.rst} |   41 +-
>  .../trace/{tracepoints.txt => tracepoints.rst} |   77 +-
>  .../trace/{uprobetracer.txt => uprobetracer.rst}   |   44 +-
>  21 files changed, 4237 insertions(+), 3990 deletions(-)
>  rename Documentation/trace/{events-kmem.txt => events-kmem.rst} (76%)
>  create mode 100644 Documentation/trace/events-msr.rst
>  delete mode 100644 Documentation/trace/events-msr.txt
>  create mode 100644 Documentation/trace/events-nmi.rst
>  delete mode 100644 Documentation/trace/events-nmi.txt
>  rename Documentation/trace/{events-power.txt => events-power.rst} (65%)
>  rename Documentation/trace/{events.txt => events.rst} (82%)
>  rename Documentation/trace/{ftrace-design.txt => ftrace-design.rst} (74%)
>  create mode 100644 Documentation/trace/ftrace.rst
>  delete mode 100644 Documentation/trace/ftrace.txt
>  rename Documentation/trace/{hwlat_detector.txt => hwlat_detector.rst} (83%)
>  create mode 100644 Documentation/trace/index.rst
>  rename Documentation/trace/{intel_th.txt => intel_th.rst} (82%)
>  rename Documentation/trace/{kprobetrace.txt => kprobetrace.rst} (63%)
>  rename Documentation/trace/{mmiotrace.txt => mmiotrace.rst} (78%)
>  rename Documentation/trace/{stm.txt => stm.rst} (91%)
>  rename Documentation/trace/{tracepoint-analysis.txt => 
> tracepoint-analysis.rst} (93%)
>  rename Documentation/trace/{tracepoints.txt => tracepoints.rst} (74%)
>  rename Documentation/trace/{uprobetracer.txt => uprobetracer.rst} (86%)
> 
> -- 
> 2.7.4
> 

-- 
Thanks,
Changbin Du
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html