Re: [PATCH 0/3] led: ledtrig-transient: add support for hrtimer

2017-05-09 Thread Jacek Anaszewski
On 05/08/2017 11:06 PM, Pavel Machek wrote:
> On Sun 2017-04-30 14:36:58, David Lin wrote:
>> Hi,
>>
>> These patch series add the LED_BRIGHTNESS_FAST flag support for
>> ledtrig-transient to use hrtimer so that platforms with high-resolution timer
>> support can have better accuracy in the trigger duration timing. The need for
>> this support is driven by the fact that Android has removed the timed_ouput 
>> [1]
>> and is now using led-trigger for handling vibrator control which requires the
>> timer to be accurate up to a millisecond. However, this flag support would 
>> also
>> allow hrtimer to co-exist with the ktimer without causing warning to the
>> existing drivers [2].
> 
> Yes, and objection still stands: You are misusing LED subsystem for
> vibration motors. We already have support for haptic feedback in input
> subsystem.

Regardless of whether it is a misuse or not (ledtrig-transient
documentation suggests that it is one of use cases) we have to keep
it as it has been around for a long time and it has userspace users [0].

Moreover there seems to be broad consensus about it among kernel
people [1].


[0]
https://android.googlesource.com/platform%2Fhardware%2Flibhardware/+/61701df363310a5cbd95e3e1638baa9526e42c9b
[1] https://patchwork.kernel.org/patch/8664831/

-- 
Best regards,
Jacek Anaszewski
--
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: [PATCHv3] docs: update references to the device io book

2017-05-09 Thread Jonathan Corbet
On Wed, 3 May 2017 11:51:46 +0200
Helmut Grohne  wrote:

> While converting the deviceiobook from DocBook to RST, dangling
> references were left behind. This commit updates all remaining
> references to the new location. SeongJae Park improved the ko_KR
> translation.

Applied to the docs tree, thanks.

jon
--
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] Documentation: earlycon: fix Marvell Armada 3700 UART name

2017-05-09 Thread Jonathan Corbet
On Thu,  4 May 2017 00:49:36 +0100
Andre Przywara  wrote:

> The Marvell Armada 3700 UART uses "ar3700_uart" for its earlycon name.
> Adjust documentation to match the code.

Applied to the docs tree, thanks.

jon
--
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] docs-rst: add input docs at main index and use kernel-figure

2017-05-09 Thread Jonathan Corbet
On Tue, 11 Apr 2017 07:01:19 -0300
Mauro Carvalho Chehab  wrote:

> The input subsystem documentation got converted into ReST.
> 
> Add it to the main documentation index and use kernel-figure
> for the two svg images there.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
> 
> Jon/Dmitry,
> 
> This patch contains the final bits of the input documentation
> conversion. The linux-input tree has already the ReST conversion
> patches, but it doesn't have the
> Documentation/sphinx/load_config.py script with implements
> the kernel-figure directive, as it got merged via docs tree.
> 
> So, either one of you should merge from the other tree or this
> patch should be sent in separate upstream after both trees
> gets merged. What do you prefer?

This is now applied.

I do reserve the right to break apart and reorganize this documentation,
a bit; it's got the classic problem of jumbling stuff for different
audiences into one big document.  But that's for another day when I have
some time...2022 or so...

Thanks,

jon
--
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 1/2] drivers: pwm: core: implement pwm mode

2017-05-09 Thread Claudiu Beznea
Extends PWM framework to support PWM modes. The currently
implemented PWM modes were called PWM complementary mode
and PWM push-pull mode. For devices that have more than one
output per PWM channel:
- PWM complementary mode is standard working mode; in PWM
complementary mode the rising and falling edges of the
channels outputs have opposite levels, same duration and
same starting time.
- in PWM push-pull mode the channles outputs has same levels,
same duration and the rising edges are delayed until the
beginning of the next period.
A new member was added in pwm_state structure in order to
keep the new PWM argument.
For PWM channels with inputs in DT, the mode could also be
passed via DT. No new extra field need to be added in device
tree; since the signal polarity is passed as a flag via DT,
the field used to pass information for PWM channel polarity
via DT is also used by PWM mode. Since, for the moment, only
the complementary and push-pull modes are implemented, only
one bit in flags used to pass polarity could also be used for
PWM mode. The other drivers are not affected by this change.

Signed-off-by: Claudiu Beznea 
---
 Documentation/pwm.txt | 24 +---
 drivers/pwm/core.c| 13 +--
 drivers/pwm/sysfs.c   | 52 +++
 include/dt-bindings/pwm/pwm.h |  1 +
 include/linux/pwm.h   | 37 --
 5 files changed, 120 insertions(+), 7 deletions(-)

diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
index 789b27c..1b6fc59 100644
--- a/Documentation/pwm.txt
+++ b/Documentation/pwm.txt
@@ -59,9 +59,9 @@ In addition to the PWM state, the PWM API also exposes PWM 
arguments, which
 are the reference PWM config one should use on this PWM.
 PWM arguments are usually platform-specific and allows the PWM user to only
 care about dutycycle relatively to the full period (like, duty = 50% of the
-period). struct pwm_args contains 2 fields (period and polarity) and should
-be used to set the initial PWM config (usually done in the probe function
-of the PWM user). PWM arguments are retrieved with pwm_get_args().
+period). struct pwm_args contains 3 fields (period, polarity and mode) and
+should be used to set the initial PWM config (usually done in the probe
+function of the PWM user). PWM arguments are retrieved with pwm_get_args().
 
 Using PWMs with the sysfs interface
 ---
@@ -100,6 +100,24 @@ enable - Enable/disable the PWM signal (read/write).
0 - disabled
1 - enabled
 
+mode - Set PWM signal type (for channels with more than one output
+   per channel)
+   complementary - for an output signal as follow:
+ ________
+PWMH1 __|  |__|  |__|  |__|  |__
+  __________
+PWML1   |__|  |__|  |__|  |__|
+<--T-->
+   Where T is the signal period.
+
+   push-pull - for an output signal as follows:
+ __  __
+PWMH1 __|  ||  |
+   __  __
+PWML1 |  ||  |__
+<--T-->
+   Where T is the signal period.
+
 Implementing a PWM driver
 -
 
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index a0860b3..4efc92d 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -154,9 +154,14 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct 
of_phandle_args *args)
 
pwm->args.period = args->args[1];
pwm->args.polarity = PWM_POLARITY_NORMAL;
+   pwm->args.mode = PWM_MODE_COMPLEMENTARY;
 
-   if (args->args_count > 2 && args->args[2] & PWM_POLARITY_INVERTED)
-   pwm->args.polarity = PWM_POLARITY_INVERSED;
+   if (args->args_count > 2) {
+   if (args->args[2] & PWM_POLARITY_INVERTED)
+   pwm->args.polarity = PWM_POLARITY_INVERSED;
+   if (args->args[2] & PWM_MODE_PUSHPULL)
+   pwm->args.mode = PWM_MODE_PUSH_PULL;
+   }
 
return pwm;
 }
@@ -579,6 +584,8 @@ int pwm_adjust_config(struct pwm_device *pwm)
pwm_get_args(pwm, );
pwm_get_state(pwm, );
 
+   state.mode = pargs.mode;
+
/*
 * If the current period is zero it means that either the PWM driver
 * does not support initial state retrieval or the PWM has not yet
@@ -997,6 +1004,8 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct 
seq_file *s)
seq_printf(s, " duty: %u ns", state.duty_cycle);
seq_printf(s, " polarity: %s",
   state.polarity ? "inverse" : "normal");
+   seq_printf(s, " mode: %s",
+  state.mode ? "push-pull" : "complementary");
 
seq_puts(s, "\n");
}
diff 

[PATCH 2/2] drivers: pwm: pwm-atmel: add support for pwm modes

2017-05-09 Thread Claudiu Beznea
Implement pwm modes by adding PWM controller specific
configuration. Since this driver is used by controllers
which supports PWM push-pull mode and controllers which
doesn't, a new field was added in driver private data
structure. Also, the driver private data structure was
changed to adapt the new feature.

Signed-off-by: Claudiu Beznea 
---
 drivers/pwm/pwm-atmel.c | 103 +---
 1 file changed, 72 insertions(+), 31 deletions(-)

diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 530d7dc..9d93cca 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -33,8 +33,11 @@
 
 #define PWM_CMR0x0
 /* Bit field in CMR */
-#define PWM_CMR_CPOL   (1 << 9)
-#define PWM_CMR_UPD_CDTY   (1 << 10)
+#define PWM_CMR_CPOL   BIT(9)
+#define PWM_CMR_UPD_CDTY   BIT(10)
+#define PWM_CMR_DTHI   BIT(17)
+#define PWM_CMR_DTLI   BIT(18)
+#define PWM_CMR_PPMBIT(19)
 #define PWM_CMR_CPRE_MSK   0xF
 
 /* The following registers for PWM v1 */
@@ -65,11 +68,16 @@ struct atmel_pwm_registers {
u8 duty_upd;
 };
 
+struct atmel_pwm_data {
+   struct atmel_pwm_registers regs;
+   bool ppm_supported;
+};
+
 struct atmel_pwm_chip {
struct pwm_chip chip;
struct clk *clk;
void __iomem *base;
-   const struct atmel_pwm_registers *regs;
+   const struct atmel_pwm_data *data;
 
unsigned int updated_pwms;
/* ISR is cleared when read, ensure only one thread does that */
@@ -150,15 +158,15 @@ static void atmel_pwm_update_cdty(struct pwm_chip *chip, 
struct pwm_device *pwm,
struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
u32 val;
 
-   if (atmel_pwm->regs->duty_upd ==
-   atmel_pwm->regs->period_upd) {
+   if (atmel_pwm->data->regs.duty_upd ==
+   atmel_pwm->data->regs.period_upd) {
val = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm, PWM_CMR);
val &= ~PWM_CMR_UPD_CDTY;
atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWM_CMR, val);
}
 
atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm,
-   atmel_pwm->regs->duty_upd, cdty);
+   atmel_pwm->data->regs.duty_upd, cdty);
 }
 
 static void atmel_pwm_set_cprd_cdty(struct pwm_chip *chip,
@@ -168,9 +176,9 @@ static void atmel_pwm_set_cprd_cdty(struct pwm_chip *chip,
struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
 
atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm,
-   atmel_pwm->regs->duty, cdty);
+   atmel_pwm->data->regs.duty, cdty);
atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm,
-   atmel_pwm->regs->period, cprd);
+   atmel_pwm->data->regs.period, cprd);
 }
 
 static void atmel_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -223,9 +231,10 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
if (state->enabled) {
if (cstate.enabled &&
cstate.polarity == state->polarity &&
-   cstate.period == state->period) {
+   cstate.period == state->period &&
+   cstate.mode == state->mode) {
cprd = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm,
- atmel_pwm->regs->period);
+ atmel_pwm->data->regs.period);
atmel_pwm_calculate_cdty(state, cprd, );
atmel_pwm_update_cdty(chip, pwm, cdty);
return 0;
@@ -258,6 +267,23 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
val &= ~PWM_CMR_CPOL;
else
val |= PWM_CMR_CPOL;
+
+   /* PWM mode. */
+   if (atmel_pwm->data->ppm_supported) {
+   if (state->mode == PWM_MODE_PUSH_PULL) {
+   val |= PWM_CMR_PPM;
+   if (state->polarity == PWM_POLARITY_NORMAL)
+   val = (val & ~PWM_CMR_DTHI) |
+ PWM_CMR_DTLI;
+   else
+   val = (val & ~PWM_CMR_DTLI) |
+ PWM_CMR_DTHI;
+   } else {
+   val &= ~(PWM_CMR_PPM | PWM_CMR_DTLI |
+PWM_CMR_DTHI);
+   }
+   }
+
atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWM_CMR, val);
atmel_pwm_set_cprd_cdty(chip, pwm, cprd, cdty);
mutex_lock(_pwm->isr_lock);
@@ -277,27 +303,42 @@ static const struct pwm_ops 

[PATCH 0/2] extend PWM framework to support PWM dead-times

2017-05-09 Thread Claudiu Beznea
Hi all,

Please give feedback on these patches which extends the PWM
framework in order to support multiple PWM signal types.
Since I didn't receive any inputs on RFC series I'm resending it as
normal patch series.

The current patch series add the following PWM signal types:
- PWM complementary signals
- PWM push-pull signal

Definition of PWM complementary mode:
For a PWM controllers with more than one outputs per PWM channel,
e.g. with 2 outputs per PWM channels, the PWM complementary signals
have opposite levels, same duration and same starting times,
as in the following diagram:

________
PWMH __|  |__|  |__|  |__|  |__
 __________
PWML   |__|  |__|  |__|  |__|
   <--T-->
Where T is the signal period.

Definition of PWM push-pull mode:
For PWM controllers with more than one outputs per PWM channel,
e.g. with 2 outputs per PWM channel, the PWM push-pull signals
have same levels, same duration and are delayed until the begining
of the next period, as in the following diagram:

__  __
PWMH __|  ||  |
  __  __
PWML |  ||  |__
   <--T-->

Where T is the signal period.

These output signals could be configured by setting PWM mode
(a new input in sysfs has been added in order to support this
operation).

root@sama5d2-xplained:/sys/devices/platform/ahb/ahb:apb/f802c000.pwm/pwm/pwmchip0/pwm2#
 ls -l
-r--r--r--1 root root  4096 Feb  9 10:54 capture
-rw-r--r--1 root root  4096 Feb  9 10:54 duty_cycle
-rw-r--r--1 root root  4096 Feb  9 10:54 enable
-rw-r--r--1 root root  4096 Feb  9 10:54 mode
-rw-r--r--1 root root  4096 Feb  9 10:54 period
-rw-r--r--1 root root  4096 Feb  9 10:55 polarity
drwxr-xr-x2 root root 0 Feb  9 10:54 power
-rw-r--r--1 root root  4096 Feb  9 10:54 uevent

The PWM push-pull mode could be usefull in applications like
half bridge converters.

This series add support for PWM modes on atmel SAMA5D2 SoC.

Thank you,
Claudiu Beznea

Claudiu Beznea (2):
  drivers: pwm: core: implement pwm mode
  drivers: pwm: pwm-atmel: add support for pwm modes

 Documentation/pwm.txt |  24 --
 drivers/pwm/core.c|  13 +-
 drivers/pwm/pwm-atmel.c   | 103 +-
 drivers/pwm/sysfs.c   |  52 +
 include/dt-bindings/pwm/pwm.h |   1 +
 include/linux/pwm.h   |  37 ++-
 6 files changed, 192 insertions(+), 38 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


[PATCH v2 2/2] drivers: pwm: pwm-atmel: implement pwm dead-times

2017-05-09 Thread Claudiu Beznea
Implement PWM dead-times for atmel PWM controllers.
Since this driver is used by PWM controllers which
supports dead-times and PWM controllers which doesn't,
add specific input for dead-time register in atmel
register private data structure.

Signed-off-by: Claudiu Beznea 
---
 drivers/pwm/pwm-atmel.c | 61 +
 1 file changed, 57 insertions(+), 4 deletions(-)

diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
index 530d7dc..dababa6 100644
--- a/drivers/pwm/pwm-atmel.c
+++ b/drivers/pwm/pwm-atmel.c
@@ -33,8 +33,9 @@
 
 #define PWM_CMR0x0
 /* Bit field in CMR */
-#define PWM_CMR_CPOL   (1 << 9)
-#define PWM_CMR_UPD_CDTY   (1 << 10)
+#define PWM_CMR_CPOL   BIT(9)
+#define PWM_CMR_UPD_CDTY   BIT(10)
+#define PWM_CMR_DTEBIT(16)
 #define PWM_CMR_CPRE_MSK   0xF
 
 /* The following registers for PWM v1 */
@@ -47,6 +48,7 @@
 #define PWMV2_CDTYUPD  0x08
 #define PWMV2_CPRD 0x0C
 #define PWMV2_CPRDUPD  0x10
+#define PWMV2_DT   0x18
 
 /*
  * Max value for duty and period
@@ -63,6 +65,7 @@ struct atmel_pwm_registers {
u8 period_upd;
u8 duty;
u8 duty_upd;
+   u8 dt;
 };
 
 struct atmel_pwm_chip {
@@ -161,6 +164,31 @@ static void atmel_pwm_update_cdty(struct pwm_chip *chip, 
struct pwm_device *pwm,
atmel_pwm->regs->duty_upd, cdty);
 }
 
+static int atmel_pwm_calculate_deadtime(struct pwm_chip *chip,
+   struct pwm_state *state,
+   unsigned long cprd, unsigned long *dt)
+{
+   unsigned long long cycles;
+
+   if (state->deadtime_fe > state->duty_cycle ||
+   state->deadtime_re > state->period - state->duty_cycle)
+   return -EINVAL;
+
+   if (state->deadtime_fe) {
+   cycles = (unsigned long long)state->deadtime_fe * cprd;
+   do_div(cycles, state->period);
+   *dt = (cycles << 16);
+   }
+
+   if (state->deadtime_re) {
+   cycles = (unsigned long long)state->deadtime_re * cprd;
+   do_div(cycles, state->period);
+   *dt |= cycles;
+   }
+
+   return 0;
+}
+
 static void atmel_pwm_set_cprd_cdty(struct pwm_chip *chip,
struct pwm_device *pwm,
unsigned long cprd, unsigned long cdty)
@@ -214,7 +242,7 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
 {
struct atmel_pwm_chip *atmel_pwm = to_atmel_pwm_chip(chip);
struct pwm_state cstate;
-   unsigned long cprd, cdty;
+   unsigned long cprd, cdty, dt = 0;
u32 pres, val;
int ret;
 
@@ -223,7 +251,9 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
if (state->enabled) {
if (cstate.enabled &&
cstate.polarity == state->polarity &&
-   cstate.period == state->period) {
+   cstate.period == state->period &&
+   cstate.deadtime_re == state->deadtime_re &&
+   cstate.deadtime_fe == state->deadtime_fe) {
cprd = atmel_pwm_ch_readl(atmel_pwm, pwm->hwpwm,
  atmel_pwm->regs->period);
atmel_pwm_calculate_cdty(state, cprd, );
@@ -239,6 +269,16 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
return ret;
}
 
+   if (atmel_pwm->regs->dt) {
+   ret = atmel_pwm_calculate_deadtime(chip, state, cprd,
+  );
+   if (ret) {
+   dev_err(chip->dev,
+   "failed to calculate dead-time\n");
+   return ret;
+   }
+   }
+
atmel_pwm_calculate_cdty(state, cprd, );
 
if (cstate.enabled) {
@@ -258,8 +298,19 @@ static int atmel_pwm_apply(struct pwm_chip *chip, struct 
pwm_device *pwm,
val &= ~PWM_CMR_CPOL;
else
val |= PWM_CMR_CPOL;
+
+   if (atmel_pwm->regs->dt) {
+   if (dt)
+   val |= PWM_CMR_DTE;
+   else
+   val &= ~PWM_CMR_DTE;
+   }
+
atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm, PWM_CMR, val);
atmel_pwm_set_cprd_cdty(chip, pwm, cprd, cdty);
+   if (atmel_pwm->regs->dt)
+   atmel_pwm_ch_writel(atmel_pwm, pwm->hwpwm,
+   atmel_pwm->regs->dt, dt);
mutex_lock(_pwm->isr_lock);
  

[PATCH v2 0/2] extends PWM framework to support PWM dead-times

2017-05-09 Thread Claudiu Beznea
Hi all,

Please give feedback on these patches which extends PWM framework
in order to support PWM dead-times.
Since I didn't receive any inputs on RFC series I'm resending it as
normal patch series.

For a PWM controller with more than one output signals per PWM channel
dead-times are the delays introduced between the edges of the output
signals and the original signal introduced in dead-time generator
engine.
E.g. consider a PWM controller with a dead-time engine as in the following
diagram:

-
   | |---> PWMH
PWM signal --->| Dead-time engine|
   | |---> PWML
-

With no dead-time configured, the PWMH and PWML signals will be
complementary signals (rising and falling edges of PWMH and PWML
have opposite leves, same duration and same starting time) as
follows:

  0DP     
PWM signal __||||||||||___
          
  PWMH __||||||||||___
   __          ___
  PWML   ||||||||||

Where - 0 is the starting point of the signal
  - D is the starting point of the duty-cycle
  - P is the signal period

Based on the above diagram:
- rising edge dead-time - is the delay introduced in one of the
dead-time engine output signals; the delay is introduced after
rising edge of the original PWM signal
- falling edge dead-time - is the delay introduced in one of the
dead-time engine output signals; the delay is introduced after
the end of falling edge of the original PWM signal

The following diagram explain how PWM dead-times falls on some signals:

  0DP     
PWM signal __||||||||||___
__________
  PWMH |  |re|  |__|  |__|  |__|  |___
   ____________
  PWML   |__|  |fe|  |__|  |__|  |__|

In the upper diagram:
- re = rising edge = the delay between D point of the original PWM signal
(rising edge) and the starting point of the next edge of one of the PWM
dead-time engine output
- fe = falling edge = the delay between P point of the original PWM signal
(falling edge) and the starting point of the next edge of one of the PWM
dead-time engine output

To configure the PWM dead-times new inputs were added to sysfs,
in PWM subsystem, one for rising edge dead-time, one for falling
edge deadtime.

root@sama5d2-xplained:/sys/devices/platform/ahb/ahb:apb/f802c000.pwm/pwm/pwmchip0/pwm2#
 ls -l
-r--r--r--1 root root  4096 Feb 10 10:00 capture
-rw-r--r--1 root root  4096 Feb 10 10:01 deadtime_fe
-rw-r--r--1 root root  4096 Feb 10 10:02 deadtime_re
-rw-r--r--1 root root  4096 Feb 10 10:00 duty_cycle
-rw-r--r--1 root root  4096 Feb 10 10:00 enable
-rw-r--r--1 root root  4096 Feb 10 10:00 period
-rw-r--r--1 root root  4096 Feb 10 10:00 polarity
drwxr-xr-x2 root root 0 Feb 10 10:00 power
-rw-r--r--1 root root  4096 Feb 10 10:00 uevent

The PWM dead-times are used in half bridge converters applications.

Thank you,
Claudiu Beznea

Changes since v1:
- fixed compilation warning

Changes since RFC patches:
- corrected the Documentation/pwm.txt
- in atmel-pwm.c check atmel_pwm->regs->dt before computing
dead-times or setting specific registers since the driver is
used by controllers witch supports dead-time configuration and
controller which does not.

Claudiu Beznea (2):
  drivers: pwm: core: implement pwm dead-times
  drivers: pwm: pwm-atmel: implement pwm dead-times

 Documentation/pwm.txt   | 55 
 drivers/pwm/core.c  | 10 ++-
 drivers/pwm/pwm-atmel.c | 62 ++---
 drivers/pwm/sysfs.c | 74 +
 include/linux/pwm.h | 36 
 5 files changed, 232 insertions(+), 5 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