From: Guru Das Srinagesh <gurus@codeaurora.org>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: linux-pwm@vger.kernel.org,
Thierry Reding <thierry.reding@gmail.com>,
kernel-team@android.com, Mark Salyzyn <salyzyn@google.com>,
Sandeep Patil <sspatil@google.com>,
Subbaraman Narayanamurthy <subbaram@codeaurora.org>,
linux-kernel@vger.kernel.org,
Fenglin Wu <fenglinw@codeaurora.org>
Subject: Re: [PATCH 1/2] pwm: Add different PWM output types support
Date: Mon, 23 Sep 2019 23:01:49 -0700 [thread overview]
Message-ID: <20190924060149.GB12462@codeaurora.org> (raw)
In-Reply-To: <20190916182524.5ebby6pbsbkuahci@pengutronix.de>
On Mon, Sep 16, 2019 at 08:25:24PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On Fri, Sep 13, 2019 at 03:57:43PM -0700, Guru Das Srinagesh wrote:
> > From: Fenglin Wu <fenglinw@codeaurora.org>
> >
> > Normally, PWM channel has fixed output until software request to change
> > 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.
>
> I have problems to understand what your modulated mode does even after
> reading your commit log and the patch.
Hi Uwe,
I have posted a reply to Thierry's email in which I provide some
background and details about this patch for your review. Hopefully that
clarifies things - I can provide some more clarifications if necessary.
>
> Also you should note here what is the intended usage and add support for
> it for at least one (preferably more) drivers to make this actually
> usable.
The PWM_OUTPUT_MODULATED mode is useful for PWM peripherals like
Qualcomm's Light Pulse Generator (LPG) that can output a duty-cycle
pattern in hardware as well as output a fixed duty-cycle signal. All
this mode really does is to provide a way for drivers to carry out some
actions for the "pattern" mode of operation that are not required (or
relevant) for the "fixed" mode of operation.
>
> > Change-Id: Ia1f914a45ab4f4dd7be037a395eeb89d0e65a80e
>
> In Linux we don't use these. You're making it easier to apply your patch
> if you drop the change-id lines.
Sorry, forgot to strip these before sending out the patch.
>
> > diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
> > index 2389b86..ab703f2 100644
> > --- a/drivers/pwm/sysfs.c
> > +++ b/drivers/pwm/sysfs.c
> > @@ -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)
> > +{
> > + 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;
> > +}
>
> So in sysfs you cannot set a pattern. Doesn't that mean this makes using
> modulated mode hardly useful?
The pattern has to be set through the devicetree and not sysfs. Will
change the output type sysfs parameter to read-only.
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2019-09-24 6:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-13 22:57 [PATCH 1/2] pwm: Add different PWM output types support Guru Das Srinagesh
2019-09-13 22:57 ` [PATCH 2/2] pwm: core: Add option to config PWM duty/period with u64 data length Guru Das Srinagesh
2019-09-16 13:59 ` kbuild test robot
2019-09-16 14:00 ` Thierry Reding
2019-09-16 14:07 ` kbuild test robot
2019-09-16 14:01 ` [PATCH 1/2] pwm: Add different PWM output types support Thierry Reding
2019-09-24 5:43 ` Guru Das Srinagesh
2019-09-24 6:39 ` Uwe Kleine-König
2019-09-24 10:46 ` Thierry Reding
2019-09-16 18:25 ` Uwe Kleine-König
2019-09-24 6:01 ` Guru Das Srinagesh [this message]
2021-09-18 11:18 ` Greg KH
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=20190924060149.GB12462@codeaurora.org \
--to=gurus@codeaurora.org \
--cc=fenglinw@codeaurora.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=salyzyn@google.com \
--cc=sspatil@google.com \
--cc=subbaram@codeaurora.org \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).