From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] PWM: add pwm framework support
Date: Tue, 28 Jun 2011 14:27:04 +0200 [thread overview]
Message-ID: <201106281427.04373.arnd@arndb.de> (raw)
In-Reply-To: <1309255368-9775-2-git-send-email-s.hauer@pengutronix.de>
On Tuesday 28 June 2011, Sascha Hauer wrote:
> This patch adds framework support for PWM (pulse width modulation) devices.
>
> The is a barebone PWM API already in the kernel under include/linux/pwm.h,
> but it does not allow for multiple drivers as each of them implements the
> pwm_*() functions.
Hi Sascha,
This looks very nice.
I have only trivial comments, except for the suggestion to use idr.
> +PWM core
> +M: Sascha Hauer <s.hauer@pengutronix.de>
> +L: linux-kernel at vger.kernel.org
> +S: Maintained
I would add
F: drivers/pwm/
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> new file mode 100644
> index 0000000..93c1052
> --- /dev/null
> +++ b/drivers/pwm/Kconfig
> @@ -0,0 +1,12 @@
> +menuconfig PWM
> + bool "PWM Support"
> + help
> + This enables PWM support through the generic PWM framework.
> + You only need to enable this, if you also want to enable
> + one or more of the PWM drivers below.
Remove the comma.
> +
> +/*
> + * The next pwm id to assign. We do not bother to fill gaps which
> + * occur during dynamic registering/deregistering of pwms, but
> + * instead assign a uniq id to each new pwm.
unique
> + */
> +static int next_pwm_id;
How about using idr? It provides you a fast lookup and handles giving
out unique numbers.
> +
> +/**
> + * pwmchip_reserve() - reserve range of pwms to use with platform code only
> + * @npwms: number of pwms to reserve
> + * Context: platform init
> + *
> + * Maybe called only once. It reserves the first pwm_ids for platform use so
I assume you mean "May only be called once".
> +/**
> + * struct pwm_ops - PWM operations
> + * @request: optional hook for requesting a PWM
> + * @free: optional hook for freeing a PWM
> + * @config: configure duty cycles and period length for this PWM
> + * @enable: enable PWM output toggling
> + * @disable: disable PWM output toggling
> + */
> +struct pwm_ops {
> + int (*request)(struct pwm_chip *chip);
> + void (*free)(struct pwm_chip *chip);
> + int (*config)(struct pwm_chip *chip, int duty_ns,
> + int period_ns);
> + int (*enable)(struct pwm_chip *chip);
> + void (*disable)(struct pwm_chip *chip);
> +};
>
> +/**
> + * struct pwm_chip - abstract a PWM
> + * @label: for diagnostics
> + * @owner: helps prevent removal of modules exporting active PWMs
> + * @ops: The callbacks for this PWM
> + */
> +struct pwm_chip {
> + int pwm_id;
> + const char *label;
> + struct module *owner;
> + struct pwm_ops *ops;
> +};
I think the "owner" field should be in the pwm_ops, not in the pwm_chip,
because the pwm_ops is likely to be statically allocated, while the
pwm_chip is probably runtime allocated and cannot be preinitialized.
Should a pwm_chip contain a "struct device" so you can refer to it in
sysfs and add attributes?
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
viresh kumar <viresh.kumar@st.com>,
Shawn Guo <shawn.guo@linaro.org>,
Ryan Mallon <ryan@bluewatersys.com>
Subject: Re: [PATCH 1/2] PWM: add pwm framework support
Date: Tue, 28 Jun 2011 14:27:04 +0200 [thread overview]
Message-ID: <201106281427.04373.arnd@arndb.de> (raw)
In-Reply-To: <1309255368-9775-2-git-send-email-s.hauer@pengutronix.de>
On Tuesday 28 June 2011, Sascha Hauer wrote:
> This patch adds framework support for PWM (pulse width modulation) devices.
>
> The is a barebone PWM API already in the kernel under include/linux/pwm.h,
> but it does not allow for multiple drivers as each of them implements the
> pwm_*() functions.
Hi Sascha,
This looks very nice.
I have only trivial comments, except for the suggestion to use idr.
> +PWM core
> +M: Sascha Hauer <s.hauer@pengutronix.de>
> +L: linux-kernel@vger.kernel.org
> +S: Maintained
I would add
F: drivers/pwm/
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> new file mode 100644
> index 0000000..93c1052
> --- /dev/null
> +++ b/drivers/pwm/Kconfig
> @@ -0,0 +1,12 @@
> +menuconfig PWM
> + bool "PWM Support"
> + help
> + This enables PWM support through the generic PWM framework.
> + You only need to enable this, if you also want to enable
> + one or more of the PWM drivers below.
Remove the comma.
> +
> +/*
> + * The next pwm id to assign. We do not bother to fill gaps which
> + * occur during dynamic registering/deregistering of pwms, but
> + * instead assign a uniq id to each new pwm.
unique
> + */
> +static int next_pwm_id;
How about using idr? It provides you a fast lookup and handles giving
out unique numbers.
> +
> +/**
> + * pwmchip_reserve() - reserve range of pwms to use with platform code only
> + * @npwms: number of pwms to reserve
> + * Context: platform init
> + *
> + * Maybe called only once. It reserves the first pwm_ids for platform use so
I assume you mean "May only be called once".
> +/**
> + * struct pwm_ops - PWM operations
> + * @request: optional hook for requesting a PWM
> + * @free: optional hook for freeing a PWM
> + * @config: configure duty cycles and period length for this PWM
> + * @enable: enable PWM output toggling
> + * @disable: disable PWM output toggling
> + */
> +struct pwm_ops {
> + int (*request)(struct pwm_chip *chip);
> + void (*free)(struct pwm_chip *chip);
> + int (*config)(struct pwm_chip *chip, int duty_ns,
> + int period_ns);
> + int (*enable)(struct pwm_chip *chip);
> + void (*disable)(struct pwm_chip *chip);
> +};
>
> +/**
> + * struct pwm_chip - abstract a PWM
> + * @label: for diagnostics
> + * @owner: helps prevent removal of modules exporting active PWMs
> + * @ops: The callbacks for this PWM
> + */
> +struct pwm_chip {
> + int pwm_id;
> + const char *label;
> + struct module *owner;
> + struct pwm_ops *ops;
> +};
I think the "owner" field should be in the pwm_ops, not in the pwm_chip,
because the pwm_ops is likely to be statically allocated, while the
pwm_chip is probably runtime allocated and cannot be preinitialized.
Should a pwm_chip contain a "struct device" so you can refer to it in
sysfs and add attributes?
Arnd
next prev parent reply other threads:[~2011-06-28 12:27 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-28 10:02 [RFC] implement a generic PWM framework - once again Sascha Hauer
2011-06-28 10:02 ` Sascha Hauer
2011-06-28 10:02 ` [PATCH 1/2] PWM: add pwm framework support Sascha Hauer
2011-06-28 10:02 ` Sascha Hauer
2011-06-28 11:14 ` Kurt Van Dijck
2011-06-28 12:27 ` Arnd Bergmann [this message]
2011-06-28 12:27 ` Arnd Bergmann
2011-06-28 16:18 ` Sascha Hauer
2011-06-28 16:18 ` Sascha Hauer
2011-06-28 17:03 ` Arnd Bergmann
2011-06-28 17:03 ` Arnd Bergmann
2011-06-29 8:50 ` Sascha Hauer
2011-06-29 8:50 ` Sascha Hauer
2011-06-29 11:00 ` Arnd Bergmann
2011-06-29 11:00 ` Arnd Bergmann
2011-06-28 19:40 ` Matthias Kaehlcke
2011-06-28 19:40 ` Matthias Kaehlcke
2011-06-28 10:02 ` [PATCH 2/2] pwm: Add a i.MX23/28 pwm driver Sascha Hauer
2011-06-28 10:02 ` Sascha Hauer
2011-06-28 10:28 ` Lothar Waßmann
2011-06-28 10:28 ` Lothar Waßmann
2011-06-28 15:22 ` Arnd Bergmann
2011-06-28 15:22 ` Arnd Bergmann
2011-06-28 12:23 ` [RFC] implement a generic PWM framework - once again Dmitry Eremin-Solenikov
-- strict thread matches above, loose matches on Subject: below --
2011-06-29 9:03 [PATCH v2] implement a generic PWM framework Sascha Hauer
2011-06-29 9:03 ` [PATCH 1/2] PWM: add pwm framework support Sascha Hauer
2011-06-29 9:03 ` Sascha Hauer
2011-06-29 11:38 ` Kurt Van Dijck
2011-06-29 11:41 ` Arnd Bergmann
2011-06-29 11:41 ` Arnd Bergmann
2011-06-29 19:47 ` Matthias Kaehlcke
2011-06-29 19:47 ` Matthias Kaehlcke
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=201106281427.04373.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.