Linux-LEDs Archive on lore.kernel.org
 help / color / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Martin Botka <martin.botka1@gmail.com>
Cc: Fenglin Wu <fenglinw@codeaurora.org>,
	Konrad Dybcio <konradybcio@gmail.com>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>, Dan Murphy <dmurphy@ti.com>,
	Rob Herring <robh+dt@kernel.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Lee Jones <lee.jones@linaro.org>,
	linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org
Subject: Re: [PATCH RCC 1/6] pwm: Add different PWM output types support
Date: Mon, 27 Jul 2020 22:10:34 +0200
Message-ID: <20200727201034.dkc6qkkbte6qeiba@pengutronix.de> (raw)
In-Reply-To: <20200724213659.273599-2-martin.botka1@gmail.com>


[-- Attachment #1: Type: text/plain, Size: 7779 bytes --]

Hello,

On Fri, Jul 24, 2020 at 11:36:51PM +0200, Martin Botka wrote:
> From: Fenglin Wu <fenglinw@codeaurora.org>
> 
> Normally, PWM channel has fixed output until software request to change

"fixed" in the sense of "periodic", not "constant", right?

> its settings. There are some PWM devices which their outputs could be
> changed autonomously according to a predefined pattern programmed in
> hardware. Add pwm_output_type enum type to identify these two different
> PWM types and add relevant helper functions to set and get PWM output
> types and pattern.

You write "some devices". Which do you have in mind?

> [...]
> diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
> index 2389b8669846..4ee1e81db0bc 100644
> --- a/drivers/pwm/sysfs.c
> +++ b/drivers/pwm/sysfs.c

adapting the sysfs stuff should be done in a separate step.

> @@ -215,11 +215,60 @@ static ssize_t capture_show(struct device *child,
>  	return sprintf(buf, "%u %u\n", result.period, result.duty_cycle);
>  }
>  
> +static ssize_t output_type_show(struct device *child,
> +							struct device_attribute *attr,
> +							char *buf)
> +{
> +	const struct pwm_device *pwm = child_to_pwm_device(child);
> +	const char *output_type = "unknown";
> +	struct pwm_state state;
> +
> +	pwm_get_state(pwm, &state);
> +	switch (state.output_type) {
> +	case PWM_OUTPUT_FIXED:
> +		output_type = "fixed";
> +		break;
> +	case PWM_OUTPUT_MODULATED:
> +		output_type = "modulated";
> +		break;
> +	default:
> +		break;
> +	}
> +
> +	return snprintf(buf, PAGE_SIZE, "%s\n", output_type);
> +}
> +
> +static ssize_t output_type_store(struct device *child,
> +								struct device_attribute *attr,
> +								const char *buf, size_t size)

Indention is broken here. Please align to the opening (.

> +{
> +	struct pwm_export *export = child_to_pwm_export(child);
> +	struct pwm_device *pwm = export->pwm;
> +	struct pwm_state state;
> +	int ret = -EINVAL;
> +
> +	mutex_lock(&export->lock);
> +	pwm_get_state(pwm, &state);
> +	if (sysfs_streq(buf, "fixed"))
> +		state.output_type = PWM_OUTPUT_FIXED;
> +	else if (sysfs_streq(buf, "modulated"))
> +		state.output_type = PWM_OUTPUT_MODULATED;
> +	else
> +		goto unlock;
> +
> +	ret = pwm_apply_state(pwm, &state);
> +unlock:
> +	mutex_unlock(&export->lock);
> +
> +	return ret ? : size;
> +}
> +
>  static DEVICE_ATTR_RW(period);
>  static DEVICE_ATTR_RW(duty_cycle);
>  static DEVICE_ATTR_RW(enable);
>  static DEVICE_ATTR_RW(polarity);
>  static DEVICE_ATTR_RO(capture);
> +static DEVICE_ATTR_RW(output_type);
>  
>  static struct attribute *pwm_attrs[] = {
>  	&dev_attr_period.attr,
> @@ -227,6 +276,7 @@ static struct attribute *pwm_attrs[] = {
>  	&dev_attr_enable.attr,
>  	&dev_attr_polarity.attr,
>  	&dev_attr_capture.attr,
> +	&dev_attr_output_type.attr,
>  	NULL
>  };
>  ATTRIBUTE_GROUPS(pwm);
> diff --git a/include/linux/pwm.h b/include/linux/pwm.h
> index 2635b2a55090..10a102efadc4 100644
> --- a/include/linux/pwm.h
> +++ b/include/linux/pwm.h
> @@ -48,6 +48,29 @@ enum {
>  	PWMF_EXPORTED = 1 << 1,
>  };
>  
> +/*
> + * enum pwm_output_type - output type of the PWM signal
> + * @PWM_OUTPUT_FIXED: PWM output is fixed until a change request
> + * @PWM_OUTPUT_MODULATED: PWM output is modulated in hardware
> + * autonomously with a predefined pattern
> + */
> +enum pwm_output_type {
> +	PWM_OUTPUT_FIXED = 1 << 0,
> +	PWM_OUTPUT_MODULATED = 1 << 1,
> +};
> +
> +/*
> + * struct pwm_output_pattern - PWM duty pattern for MODULATED duty type
> + * @duty_pattern: PWM duty cycles in the pattern for duty modulation
> + * @num_entries: number of entries in the pattern
> + * @cycles_per_duty: number of PWM period cycles an entry stays at
> + */
> +struct pwm_output_pattern {
> +	unsigned int *duty_pattern;
> +	unsigned int num_entries;
> +	unsigned int cycles_per_duty;
> +};

I don't understand the semantics here. (i.e. how does a given
pwm_output_pattern map to the intended wave form?)

> +
>  /*
>   * struct pwm_state - state of a PWM channel
>   * @period: PWM period (in nanoseconds)
> @@ -59,6 +82,8 @@ struct pwm_state {
>  	unsigned int period;
>  	unsigned int duty_cycle;
>  	enum pwm_polarity polarity;
> +	enum pwm_output_type output_type;
> +	struct pwm_output_pattern *output_pattern;
>  	bool enabled;
>  };
>  
> @@ -146,6 +171,26 @@ static inline enum pwm_polarity pwm_get_polarity(const struct pwm_device *pwm)
>  	return state.polarity;
>  }
>  
> +static inline enum pwm_output_type pwm_get_output_type(
> +				const struct pwm_device *pwm)
> +{
> +	struct pwm_state state;
> +
> +	pwm_get_state(pwm, &state);
> +
> +	return state.output_type;
> +}
> +
> +static inline struct pwm_output_pattern *pwm_get_output_pattern(
> +				struct pwm_device *pwm)
> +{
> +	struct pwm_state state;
> +
> +	pwm_get_state(pwm, &state);
> +
> +	return pwm->state.output_pattern ?: NULL;

Who is the owner of the data behind this pointer? Is it expected to be
valid only until the next call to change the output? What happens if the
caller modifies the data returned?

> +}
> +
>  static inline void pwm_get_args(const struct pwm_device *pwm,
>  				struct pwm_args *args)
>  {
> @@ -254,6 +299,9 @@ pwm_set_relative_duty_cycle(struct pwm_state *state, unsigned int duty_cycle,
>   * @set_polarity: configure the polarity of this PWM
>   * @enable: enable PWM output toggling
>   * @disable: disable PWM output toggling
> + * @get_output_type_supported: get the supported output type
> + * @set_output_type: set PWM output type
> + * @set_output_pattern: set the pattern for the modulated output
>   */
>  struct pwm_ops {
>  	int (*request)(struct pwm_chip *chip, struct pwm_device *pwm);
> @@ -273,6 +321,13 @@ struct pwm_ops {
>  			    enum pwm_polarity polarity);
>  	int (*enable)(struct pwm_chip *chip, struct pwm_device *pwm);
>  	void (*disable)(struct pwm_chip *chip, struct pwm_device *pwm);
> +	int (*get_output_type_supported)(struct pwm_chip *chip,
> +			    struct pwm_device *pwm);
> +	int (*set_output_type)(struct pwm_chip *chip, struct pwm_device *pwm,
> +			    enum pwm_output_type output_type);
> +	int (*set_output_pattern)(struct pwm_chip *chip,
> +			    struct pwm_device *pwm,
> +			    struct pwm_output_pattern *output_pattern);

This doesn't match the atomic approach that we're following since the
introduction of .apply. Please don't add new non-atomic callbacks.

>  };
>  
>  /**
> @@ -318,6 +373,20 @@ void pwm_free(struct pwm_device *pwm);
>  int pwm_apply_state(struct pwm_device *pwm, const struct pwm_state *state);
>  int pwm_adjust_config(struct pwm_device *pwm);
>  
> +/*
> + * pwm_output_type_support()
> + * @pwm: PWM device
> + *
> + * Returns:  output types supported by the PWM device
> + */
> +static inline int pwm_get_output_type_supported(struct pwm_device *pwm)
> +{
> +	if (pwm->chip->ops->get_output_type_supported != NULL)
> +		return pwm->chip->ops->get_output_type_supported(pwm->chip, pwm);
> +	else
> +		return PWM_OUTPUT_FIXED;
> +}

I don't like this "advertising" for specific functions. I'd prefer to
handle this in .apply(), fix all drivers to return -ESOMETHING when the
request cannot be fulfilled.

Having said that I wonder if this output pattern is a common enough
property to add support for it in the PWM framework.

If the only usage is to drive a LED this might maybe better be a
dedicated LED driver? (Though I'm not sure this is a good idea either.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply index

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24 21:36 [PATCH RFC 0/6] Add QCOM pwm-lpg and tri-led drivers Martin Botka
2020-07-24 21:36 ` [PATCH RCC 1/6] pwm: Add different PWM output types support Martin Botka
2020-07-27 20:10   ` Uwe Kleine-König [this message]
2020-07-27 20:56     ` Martin Botka
2020-07-28  7:52       ` Uwe Kleine-König
2020-07-27 21:46   ` Guru Das Srinagesh
2020-07-24 21:36 ` [PATCH RFC 2/6] pwm: core: Add option to config PWM duty/period with u64 data length Martin Botka
2020-07-25 14:55   ` Martin Botka
2020-07-25 15:24     ` Pavel Machek
2020-07-25 15:30       ` Martin Botka
2020-07-26  9:04   ` Andy Shevchenko
2020-07-26  9:12     ` Martin Botka
2020-07-27  7:29       ` Martin Botka
2020-07-27  7:32         ` Martin Botka
2020-07-27  7:52         ` Uwe Kleine-König
2020-07-27  7:58           ` Martin Botka
2020-07-27  8:34             ` Uwe Kleine-König
2020-07-24 21:36 ` [PATCH RFC 3/6] pwm: pwm-qti-lpg: Add PWM driver for QTI LPG module Martin Botka
2020-07-27 20:09   ` Uwe Kleine-König
2020-07-27 21:16     ` Martin Botka
2020-07-28  7:08       ` Uwe Kleine-König
2020-07-24 21:36 ` [PATCH RFC 4/6] leds: leds-qti-tri-led: Add LED driver for QTI TRI_LED module Martin Botka
2020-07-26 17:25   ` Martin Botka
2020-07-24 21:36 ` [PATCH RFC 5/6] Documentation: Add binding for qti-tri-led Martin Botka
2020-07-24 21:36 ` [PATCH RFC 6/6] Documentation: Add binding for pwm-qti-lpg Martin Botka
2020-07-24 22:05 ` [PATCH RFC 0/6] Add QCOM pwm-lpg and tri-led drivers Pavel Machek
2020-07-24 22:26   ` Martin Botka
2020-07-24 22:32     ` Pavel Machek
2020-07-24 22:48       ` Martin Botka
     [not found]   ` <CADQ2G_HbysJbiQKSRmA6HDRfjPYPiDjbZfeuUjM1mNV-BBBC-A@mail.gmail.com>
2020-07-24 22:31     ` Pavel Machek
2020-07-24 22:46       ` Martin Botka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200727201034.dkc6qkkbte6qeiba@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dmurphy@ti.com \
    --cc=fenglinw@codeaurora.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=konradybcio@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=martin.botka1@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-LEDs Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-leds/0 linux-leds/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-leds linux-leds/ https://lore.kernel.org/linux-leds \
		linux-leds@vger.kernel.org
	public-inbox-index linux-leds

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-leds


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git