All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Li Xiubo <Li.Xiubo@freescale.com>
Cc: Shawn Guo <Shawn.Guo@freescale.com>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"swarren@wwwdotorg.org" <swarren@wwwdotorg.org>,
	"t.figa@samsung.com" <t.figa@samsung.com>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"rob@landley.net" <rob@landley.net>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"pawel.moll@arm.com" <pawel.moll@arm.com>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Huan Wang <Huan.Wang@freescale.com>,
	Jingchan
Subject: Re: [PATCHv6 1/4] pwm: Add Freescale FTM PWM driver support
Date: Fri, 29 Nov 2013 10:22:24 +0100	[thread overview]
Message-ID: <20131129092224.GB22771@ulmo.nvidia.com> (raw)
In-Reply-To: <1DD289F6464F0949A2FCA5AA6DC23F828DD76C@039-SN2MPN1-011.039d.mgd.msft.net>

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

On Fri, Nov 29, 2013 at 06:42:06AM +0000, Li Xiubo wrote:
> > > +#define FTM_CNTIN_VAL       0x00
> > 
> > Do we really need this?
> > 
> 
> Maybe not, I think that the initial value maybe modified in the future.
> And this can be more easy to ajust it. 

Why would it need to be modified?

> > > +	writel(period_cycles + cntin - 1, fpc->base + FTM_MOD);
> > > +	writel(duty_cycles + cntin, fpc->base + FTM_CV(pwm->hwpwm));
> > 
> > And these:
> > 
> > 	writel(period - 1, fpc->base + FTM_MOD);
> > 	writel(duty, fpc->base + FTM_CV(pwm->hwpwm));
> > 
> > Although now that I think about it, this seems broken. The period is set
> > in a global register, so I assume it is valid for all channels. What if
> > you want to use different periods for individual channels? The way I
> > read this the last one to be configured will win and change the period
> > to whatever it wants. Other channels won't even notice.
> > 
> 
> That's right. And all the 8 channels share the same period settings.
> 
> > Is there a way to set the period per channel?
> > 
> 
> Not yet. Only could we do is to set the duty value individually for each
> channel. So here is a limitation for the cusumers that all the 8 channels'
> period values should be the same.

That will need to be handled some way. Perhaps the easiest would be to
check whether or not another channel is already running and check that
indeed the period as requested by the new channel matches that of any
running channels. If it doesn't match, then pwm_config() should fail.

When you do that you can also optimize this a bit by only setting the
frequency once. Whenever a new channel is configured it will have the
same period and therefore the register doesn't need to be reprogrammed.

> > > +static void fsl_pwm_disable(struct pwm_chip *chip, struct pwm_device
> > *pwm)
> > > +{
> > > +	struct fsl_pwm_chip *fpc;
> > > +
> > > +	fpc = to_fsl_chip(chip);
> > > +
> > > +	fsl_counter_clock_disable(fpc);
> > > +}
> > 
> > Same here. Since you can't propagate the error, perhaps an error message
> > would be appropriate here?
> > 
> 
> Well, in fsl_counter_clock_disable(fpc); only '0' could be returned, maybe
> let it a void type value to return is better.
> Just like:
> static void fsl_counter_clock_disable(struct fsl_pwm_chip *fpc) {}

Yes, that sounds good.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv6 1/4] pwm: Add Freescale FTM PWM driver support
Date: Fri, 29 Nov 2013 10:22:24 +0100	[thread overview]
Message-ID: <20131129092224.GB22771@ulmo.nvidia.com> (raw)
In-Reply-To: <1DD289F6464F0949A2FCA5AA6DC23F828DD76C@039-SN2MPN1-011.039d.mgd.msft.net>

On Fri, Nov 29, 2013 at 06:42:06AM +0000, Li Xiubo wrote:
> > > +#define FTM_CNTIN_VAL       0x00
> > 
> > Do we really need this?
> > 
> 
> Maybe not, I think that the initial value maybe modified in the future.
> And this can be more easy to ajust it. 

Why would it need to be modified?

> > > +	writel(period_cycles + cntin - 1, fpc->base + FTM_MOD);
> > > +	writel(duty_cycles + cntin, fpc->base + FTM_CV(pwm->hwpwm));
> > 
> > And these:
> > 
> > 	writel(period - 1, fpc->base + FTM_MOD);
> > 	writel(duty, fpc->base + FTM_CV(pwm->hwpwm));
> > 
> > Although now that I think about it, this seems broken. The period is set
> > in a global register, so I assume it is valid for all channels. What if
> > you want to use different periods for individual channels? The way I
> > read this the last one to be configured will win and change the period
> > to whatever it wants. Other channels won't even notice.
> > 
> 
> That's right. And all the 8 channels share the same period settings.
> 
> > Is there a way to set the period per channel?
> > 
> 
> Not yet. Only could we do is to set the duty value individually for each
> channel. So here is a limitation for the cusumers that all the 8 channels'
> period values should be the same.

That will need to be handled some way. Perhaps the easiest would be to
check whether or not another channel is already running and check that
indeed the period as requested by the new channel matches that of any
running channels. If it doesn't match, then pwm_config() should fail.

When you do that you can also optimize this a bit by only setting the
frequency once. Whenever a new channel is configured it will have the
same period and therefore the register doesn't need to be reprogrammed.

> > > +static void fsl_pwm_disable(struct pwm_chip *chip, struct pwm_device
> > *pwm)
> > > +{
> > > +	struct fsl_pwm_chip *fpc;
> > > +
> > > +	fpc = to_fsl_chip(chip);
> > > +
> > > +	fsl_counter_clock_disable(fpc);
> > > +}
> > 
> > Same here. Since you can't propagate the error, perhaps an error message
> > would be appropriate here?
> > 
> 
> Well, in fsl_counter_clock_disable(fpc); only '0' could be returned, maybe
> let it a void type value to return is better.
> Just like:
> static void fsl_counter_clock_disable(struct fsl_pwm_chip *fpc) {}

Yes, that sounds good.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131129/fe887954/attachment.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Li Xiubo <Li.Xiubo@freescale.com>
Cc: Shawn Guo <Shawn.Guo@freescale.com>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"swarren@wwwdotorg.org" <swarren@wwwdotorg.org>,
	"t.figa@samsung.com" <t.figa@samsung.com>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"rob@landley.net" <rob@landley.net>,
	"ian.campbell@citrix.com" <ian.campbell@citrix.com>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"pawel.moll@arm.com" <pawel.moll@arm.com>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	Huan Wang <Huan.Wang@freescale.com>,
	Jingchang Lu <jingchang.lu@freescale.com>
Subject: Re: [PATCHv6 1/4] pwm: Add Freescale FTM PWM driver support
Date: Fri, 29 Nov 2013 10:22:24 +0100	[thread overview]
Message-ID: <20131129092224.GB22771@ulmo.nvidia.com> (raw)
In-Reply-To: <1DD289F6464F0949A2FCA5AA6DC23F828DD76C@039-SN2MPN1-011.039d.mgd.msft.net>

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

On Fri, Nov 29, 2013 at 06:42:06AM +0000, Li Xiubo wrote:
> > > +#define FTM_CNTIN_VAL       0x00
> > 
> > Do we really need this?
> > 
> 
> Maybe not, I think that the initial value maybe modified in the future.
> And this can be more easy to ajust it. 

Why would it need to be modified?

> > > +	writel(period_cycles + cntin - 1, fpc->base + FTM_MOD);
> > > +	writel(duty_cycles + cntin, fpc->base + FTM_CV(pwm->hwpwm));
> > 
> > And these:
> > 
> > 	writel(period - 1, fpc->base + FTM_MOD);
> > 	writel(duty, fpc->base + FTM_CV(pwm->hwpwm));
> > 
> > Although now that I think about it, this seems broken. The period is set
> > in a global register, so I assume it is valid for all channels. What if
> > you want to use different periods for individual channels? The way I
> > read this the last one to be configured will win and change the period
> > to whatever it wants. Other channels won't even notice.
> > 
> 
> That's right. And all the 8 channels share the same period settings.
> 
> > Is there a way to set the period per channel?
> > 
> 
> Not yet. Only could we do is to set the duty value individually for each
> channel. So here is a limitation for the cusumers that all the 8 channels'
> period values should be the same.

That will need to be handled some way. Perhaps the easiest would be to
check whether or not another channel is already running and check that
indeed the period as requested by the new channel matches that of any
running channels. If it doesn't match, then pwm_config() should fail.

When you do that you can also optimize this a bit by only setting the
frequency once. Whenever a new channel is configured it will have the
same period and therefore the register doesn't need to be reprogrammed.

> > > +static void fsl_pwm_disable(struct pwm_chip *chip, struct pwm_device
> > *pwm)
> > > +{
> > > +	struct fsl_pwm_chip *fpc;
> > > +
> > > +	fpc = to_fsl_chip(chip);
> > > +
> > > +	fsl_counter_clock_disable(fpc);
> > > +}
> > 
> > Same here. Since you can't propagate the error, perhaps an error message
> > would be appropriate here?
> > 
> 
> Well, in fsl_counter_clock_disable(fpc); only '0' could be returned, maybe
> let it a void type value to return is better.
> Just like:
> static void fsl_counter_clock_disable(struct fsl_pwm_chip *fpc) {}

Yes, that sounds good.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2013-11-29  9:22 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-12  1:36 [PATCHv6 0/4] Add Freescale FTM PWM driver Xiubo Li
2013-11-12  1:36 ` Xiubo Li
2013-11-12  1:36 ` Xiubo Li
2013-11-12  1:36 ` Xiubo Li
2013-11-12  1:36 ` [PATCHv6 1/4] pwm: Add Freescale FTM PWM driver support Xiubo Li
2013-11-12  1:36   ` Xiubo Li
2013-11-12  1:36   ` Xiubo Li
2013-11-12  1:36   ` Xiubo Li
2013-11-28 21:25   ` Thierry Reding
2013-11-28 21:25     ` Thierry Reding
2013-11-28 22:37     ` Thierry Reding
2013-11-28 22:37       ` Thierry Reding
2013-12-02 11:02       ` Mark Rutland
2013-12-02 11:02         ` Mark Rutland
2013-12-02 11:02         ` Mark Rutland
2013-12-02 11:02         ` Mark Rutland
2013-12-04  6:01         ` Li Xiubo
2013-12-04  6:01           ` Li Xiubo
2013-12-04  6:01           ` Li Xiubo
2013-11-29  5:58     ` Li Xiubo
2013-11-29  5:58       ` Li Xiubo
2013-11-29  5:58       ` Li Xiubo
2013-11-29  6:42     ` Li Xiubo
2013-11-29  6:42       ` Li Xiubo
2013-11-29  6:42       ` Li Xiubo
2013-11-29  9:22       ` Thierry Reding [this message]
2013-11-29  9:22         ` Thierry Reding
2013-11-29  9:22         ` Thierry Reding
2013-12-02  2:45         ` Li Xiubo
2013-12-02  2:45           ` Li Xiubo
2013-12-02  2:45           ` Li Xiubo
2013-12-13  9:30     ` Li.Xiubo
2013-12-13  9:30       ` Li.Xiubo
2013-12-13  9:30       ` Li.Xiubo at freescale.com
2013-12-19 21:55   ` Bill Pringlemeir
2013-12-19 21:55     ` Bill Pringlemeir
2013-12-20  7:47     ` Li.Xiubo
2013-12-20  7:47       ` Li.Xiubo at freescale.com
2013-11-12  1:36 ` [PATCHv6 2/4] ARM: dts: Add Freescale FTM PWM node for VF610 Xiubo Li
2013-11-12  1:36   ` Xiubo Li
2013-11-12  1:36   ` Xiubo Li
2013-11-28 21:26   ` Thierry Reding
2013-11-28 21:26     ` Thierry Reding
2013-11-12  1:36 ` [PATCHv6 3/4] ARM: dts: Enables FTM PWM device for Vybrid VF610 TOWER board Xiubo Li
2013-11-12  1:36   ` Xiubo Li
2013-11-12  1:36   ` Xiubo Li
2013-11-12  1:36 ` [PATCHv6 4/4] Documentation: Add device tree bindings for Freescale FTM PWM Xiubo Li
2013-11-12  1:36   ` Xiubo Li
2013-11-12  1:36   ` Xiubo Li
2013-11-28 21:32   ` Thierry Reding
2013-11-28 21:32     ` Thierry Reding
2013-12-02  7:17     ` Li Xiubo
2013-12-02  7:17       ` Li Xiubo
2013-12-03  6:56     ` Li Xiubo
2013-12-03  6:56       ` Li Xiubo
2013-12-03  6:56       ` Li Xiubo
2013-11-22  7:18 ` [PATCHv6 0/4] Add Freescale FTM PWM driver Li Xiubo
2013-11-22  7:18   ` Li Xiubo
2013-11-22  7:18   ` Li Xiubo

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=20131129092224.GB22771@ulmo.nvidia.com \
    --to=thierry.reding@gmail.com \
    --cc=Huan.Wang@freescale.com \
    --cc=Li.Xiubo@freescale.com \
    --cc=Shawn.Guo@freescale.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=ian.campbell@citrix.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=rob.herring@calxeda.com \
    --cc=rob@landley.net \
    --cc=s.hauer@pengutronix.de \
    --cc=swarren@wwwdotorg.org \
    --cc=t.figa@samsung.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
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.