From: Tomasz Figa <t.figa@samsung.com>
To: devicetree-discuss@lists.ozlabs.org
Cc: Xiubo Li-B47053 <B47053@freescale.com>,
Tomasz Figa <tomasz.figa@gmail.com>,
Guo Shawn-R65073 <r65073@freescale.com>,
"thierry.reding@gmail.com" <thierry.reding@gmail.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>,
"swarren@wwwdotorg.org" <swarren@wwwdotorg.org>,
"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>li
Subject: Re: [PATCH 4/4] Documentation: Add device tree bindings for Freescale FTM PWM
Date: Thu, 22 Aug 2013 14:17:53 +0200 [thread overview]
Message-ID: <1889970.nK93apnFQd@amdc1227> (raw)
In-Reply-To: <1DD289F6464F0949A2FCA5AA6DC23F827D2539@039-SN2MPN1-013.039d.mgd.msft.net>
On Thursday 22 of August 2013 09:52:42 Xiubo Li-B47053 wrote:
> Hi Tomasz,
>
> > > > If the meaning of flags cell is the same as in generic, default PWM
> > > > specifier format, then it should be noted here and generic PWM
> > > > binding documentation mentioned.
> > >
> > > OK, How about the following ?
> > > - #pwm-cells: Should be 3. See pwm.txt in this directory for a
> > >
> > > description of the cells format.
> >
> > I meant just the last cell, which stores flags, but actually this might
> > be a good idea, but with slightly extended description. Something among
> > those
> >
> > lines:
> > - #pwm-cells: Should be 3. The default three cell format specified by
> >
> > generic PWM bindings are used. Refer to the documentation of generic
> > PWM
> > bindings for more information about the meaning of cells.
>
> That's perfect.
OK.
> > > > > +- fsl,pwm-clk-ps: the ftm0 pwm clock's prescaler,
> > > > > divide-by 2^n(n = 0 ~ 7).
> > > >
> > > > Is it a hardware-specific property?
> > >
> > > Yes, I will revise it in v2.
> >
> > I'd like to hear a bit more elaborate description of this property.
> > What
> > are the factors that decide what value should be used here?
>
> Sorry, "the ftm0 pwm clock's prescaler" maybe also confuse you, it should
> be "the ftm pwm counter clock input prescaler".
>
> The ftm's counter clock can be selected as :
> System clock,
> Fixed frequency clock,
> External clock.
>
> And the ftm module clock has only system clock source.
>
> The fixed frequency clock is an alternative clock source for the FTM
> counter that allows the selection of a clock other than the system clock
> or an external clock. This clock input is defined by chip integration.
> Due to FTM hardware implementation limitations, the frequency of the
> fixed frequency clock must not exceed 1/2 of the system clock frequency.
>
> The external clock passes through a synchronizer clocked by the system
> clock to assure that counter transitions are properly aligned to system
> clock transitions.Therefore, to meet Nyquist criteria considering also
> jitter, the frequency of the external clock source must not exceed 1/4
> of the system clock frequency.
>
> So, if the fixed frequency clock or external clock equal or exceed the
> system clock...
Can't the driver check the frequency of fixed or external clock and
calculate optimal divisor value so that it is less than 1/4 of system clock
frequency?
> > > > > +- fsl,pwm-number: the number of PWM devices, and is must equal
> > > > > to
> > > > > the
> > > > > number + of "fsl,pwm-channels".
> > > >
> > > > This is redundant, because you can simply count how many entries
> > > > have been specified in fsl,pwm-channels.
> > >
> > > Yes, I will revise it in v2.
> > > And this would be renamed to " fsl,pwm-channel-number", which can be
> > > more Readable and understood.
> >
> > I meant that you don't need to specify how many entries other property
> > has in another property, because device tree provides information about
> > sizes of all properties. So, in parsing code, you would be able to
> > simply get the size of "fsl,pwm-channels" property in bytes, divide
> > that by sizeof(u32) and get the numer of cells specified.
>
> OK, I will revise it in v2.
As I noted below, it won't be needed anymore. I just commented on this as a
side note.
> > > > > +- fsl,pwm-channels: the channels' order which is be used for pwm
> > > > > +in
> > > > > ftm0 + module, and they must be one or some of 0 ~ 7, because
> > > > > the
> > > > > ftm0 only has + 8 channels can be used.
> > > >
> > > > Could you explain meaning of this property more precisely? I'm
> > > > interested especially how is this related to the PWM IP block and
> > > > boards.
> > >
> > > Yes.
> > > There are 8 channels most. While the pinctrls of 4th and 5th channels
> > > could be used by uart's Rx and Tx, then these 2 channels won't be
> > > used
> > > for pwm output, so there will be 6 channels available by the pwm.
> > > Thus, the pwm chip will register only 6 pwms(6 channels)
> > > most("fsl,pwm-channel-orders = {0 1 2 3 6 7}").And also the
> > > "fsl,pwm-channel-number" will be 6.
> > >
> > > If hasn't any other problems, I will revise It in v2.
> > > And this will be renamed to "fsl,pwm-channel-orders", which can be
> > > more readable and understood.
> >
> > As Sascha Hauer already suggested, you could get rid of both this and
> > "fsl,pwm-channel-number" properties and simply register all the
> > channels. This way you will have a deterministic 1:1 mapping of real
> > hardware channels to channels specified in device tree, which is
> > definitely the way to go.
> >
> > Now as a safety measure, you could simply move the specification of
> > pinctrl states from SoC family or SoC level dtsi file to board level
> > dts, where only pinctrl states of channels used by a particular board
> > would be specified, so nothing could break operation of other devices
> > that share pin muxes with remaining channels.
>
> Yes, I was also considering it, but not very be clear yet.
> Thanks very much for your and Sascha's help.
> I will try to implement it in v2.
OK, good.
Best regards,
Tomasz
next parent reply other threads:[~2013-08-22 12:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1377054462-6283-1-git-send-email-Li.Xiubo@freescale.com>
[not found] ` <1522215.zHEjdiga8V@flatron>
[not found] ` <1DD289F6464F0949A2FCA5AA6DC23F827D2539@039-SN2MPN1-013.039d.mgd.msft.net>
2013-08-22 12:17 ` Tomasz Figa [this message]
[not found] ` <1377054462-6283-3-git-send-email-Li.Xiubo@freescale.com>
[not found] ` <20130823091309.GH3535@ulmo>
2013-08-26 5:58 ` [PATCH 2/4] ARM: dts: Add Freescale ftm pwm node for VF610 Xiubo Li-B47053
[not found] ` <1377054462-6283-4-git-send-email-Li.Xiubo@freescale.com>
[not found] ` <20130823091331.GI3535@ulmo>
2013-08-26 6:00 ` [PATCH 3/4] ARM: dts: Enables ftm pwm device for Vybrid VF610 TOWER board Xiubo Li-B47053
[not found] ` <1377054462-6283-2-git-send-email-Li.Xiubo@freescale.com>
[not found] ` <20130823090523.GF3535@ulmo>
2013-08-26 7:32 ` [PATCH 1/4] pwm: add freescale ftm pwm driver support Xiubo Li-B47053
2013-08-27 7:40 ` Thierry Reding
2013-08-27 9:56 ` Xiubo Li-B47053
[not found] ` <1377054462-6283-5-git-send-email-Li.Xiubo@freescale.com>
[not found] ` <1473340.OXSHEp7d4P@flatron>
[not found] ` <1DD289F6464F0949A2FCA5AA6DC23F827D2244@039-SN2MPN1-013.039d.mgd.msft.net>
[not found] ` <20130822062610.GR31036@pengutronix.de>
[not found] ` <20130823073612.GB3535@ulmo>
[not found] ` <5217B807.7020800@wwwdotorg.org>
2013-08-26 5:35 ` [PATCH 4/4] Documentation: Add device tree bindings for Freescale FTM PWM Xiubo Li-B47053
2013-08-26 20:01 ` Stephen Warren
2013-08-27 3:48 ` Xiubo Li-B47053
2013-08-27 4:04 ` Stephen Warren
2013-08-26 5:46 ` Xiubo Li-B47053
2013-08-30 19:19 ` Kumar Gala
2013-08-30 20:11 ` Stephen Warren
2013-09-03 5:25 ` Xiubo Li-B47053
2013-09-02 2:18 ` Xiubo Li-B47053
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=1889970.nK93apnFQd@amdc1227 \
--to=t.figa@samsung.com \
--cc=B47053@freescale.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--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=r65073@freescale.com \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=swarren@wwwdotorg.org \
--cc=thierry.reding@gmail.com \
--cc=tomasz.figa@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
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).