[PATCHv3 0/3] ftm-pwm: Convert to direct regmap API usage

[PATCHv3 0/3] ftm-pwm: Convert to direct regmap API usage

[Xiubo Li]

This is depended on the following patches, which has been applied by
Mark into his Regmap-Tree:
https://lkml.org/lkml/2014/7/15/6
https://lkml.org/lkml/2014/7/15/5
https://lkml.org/lkml/2014/7/15/7


Changes in V3:
- Use the regmap framework's endianness method instead of its own.

Changes in V2:
- Adds detail descriptions of these patches.
 





Xiubo Li (3):
  pwm: ftm-pwm: Clean up the code.
  pwm: ftm-pwm: Convert to direct regmap API usage.
  pwm: documentation: Add 'big-endian' property for FTM PWM.

 .../devicetree/bindings/pwm/pwm-fsl-ftm.txt        | 22 +++++-
 drivers/pwm/pwm-fsl-ftm.c                          | 90 +++++++++++-----------
 2 files changed, 68 insertions(+), 44 deletions(-)

-- 
1.8.5

[PATCHv3 1/3] pwm: ftm-pwm: Clean up the code.

[Xiubo Li]

This patch intends to prepare for converting to direct regmap
API usage.

Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
---
 drivers/pwm/pwm-fsl-ftm.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/pwm/pwm-fsl-ftm.c b/drivers/pwm/pwm-fsl-ftm.c
index a18bc8f..96982da 100644
--- a/drivers/pwm/pwm-fsl-ftm.c
+++ b/drivers/pwm/pwm-fsl-ftm.c
@@ -21,11 +21,10 @@
 #include <linux/slab.h>
 
 #define FTM_SC		0x00
-#define FTM_SC_CLK_MASK	0x3
-#define FTM_SC_CLK_SHIFT	3
-#define FTM_SC_CLK(c)	(((c) + 1) << FTM_SC_CLK_SHIFT)
+#define FTM_SC_CLK_MASK_SHIFT	3
+#define FTM_SC_CLK_MASK	(3 << FTM_SC_CLK_MASK_SHIFT)
+#define FTM_SC_CLK(c)	(((c) + 1) << FTM_SC_CLK_MASK_SHIFT)
 #define FTM_SC_PS_MASK	0x7
-#define FTM_SC_PS_SHIFT	0
 
 #define FTM_CNT		0x04
 #define FTM_MOD		0x08
@@ -258,7 +257,7 @@ static int fsl_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 		}
 
 		val = readl(fpc->base + FTM_SC);
-		val &= ~(FTM_SC_PS_MASK << FTM_SC_PS_SHIFT);
+		val &= ~FTM_SC_PS_MASK;
 		val |= fpc->clk_ps;
 		writel(val, fpc->base + FTM_SC);
 		writel(period - 1, fpc->base + FTM_MOD);
@@ -305,7 +304,7 @@ static int fsl_counter_clock_enable(struct fsl_pwm_chip *fpc)
 
 	/* select counter clock source */
 	val = readl(fpc->base + FTM_SC);
-	val &= ~(FTM_SC_CLK_MASK << FTM_SC_CLK_SHIFT);
+	val &= ~FTM_SC_CLK_MASK;
 	val |= FTM_SC_CLK(fpc->cnt_select);
 	writel(val, fpc->base + FTM_SC);
 
@@ -357,7 +356,7 @@ static void fsl_counter_clock_disable(struct fsl_pwm_chip *fpc)
 
 	/* no users left, disable PWM counter clock */
 	val = readl(fpc->base + FTM_SC);
-	val &= ~(FTM_SC_CLK_MASK << FTM_SC_CLK_SHIFT);
+	val &= ~FTM_SC_CLK_MASK;
 	writel(val, fpc->base + FTM_SC);
 
 	clk_disable_unprepare(fpc->clk[FSL_PWM_CLK_CNTEN]);
-- 
1.8.5

[PATCHv3 2/3] pwm: ftm-pwm: Convert to direct regmap API usage.

[Xiubo Li]

Since the regmap core has already support rich endianness modes of
device, this patch convert to direct regmap API usage, preparing to
support big endianness for LS1 SoC.

Using the regmag framework will be more easy to support the endiannesses
switching of one same device driver on different SoCs.

Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
---
 drivers/pwm/pwm-fsl-ftm.c | 83 +++++++++++++++++++++++++----------------------
 1 file changed, 44 insertions(+), 39 deletions(-)

diff --git a/drivers/pwm/pwm-fsl-ftm.c b/drivers/pwm/pwm-fsl-ftm.c
index 96982da..f3298be 100644
--- a/drivers/pwm/pwm-fsl-ftm.c
+++ b/drivers/pwm/pwm-fsl-ftm.c
@@ -18,6 +18,7 @@
 #include <linux/of_address.h>
 #include <linux/platform_device.h>
 #include <linux/pwm.h>
+#include <linux/regmap.h>
 #include <linux/slab.h>
 
 #define FTM_SC		0x00
@@ -82,7 +83,7 @@ struct fsl_pwm_chip {
 	unsigned int cnt_select;
 	unsigned int clk_ps;
 
-	void __iomem *base;
+	struct regmap *regmap;
 
 	int period_ns;
 
@@ -218,10 +219,11 @@ static unsigned long fsl_pwm_calculate_duty(struct fsl_pwm_chip *fpc,
 					    unsigned long period_ns,
 					    unsigned long duty_ns)
 {
-	unsigned long long val, duty;
+	unsigned long long duty;
+	u32 val;
 
-	val = readl(fpc->base + FTM_MOD);
-	duty = duty_ns * (val + 1);
+	regmap_read(fpc->regmap, FTM_MOD, &val);
+	duty = (unsigned long long)duty_ns * (val + 1);
 	do_div(duty, period_ns);
 
 	return (unsigned long)duty;
@@ -231,7 +233,7 @@ static int fsl_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 			  int duty_ns, int period_ns)
 {
 	struct fsl_pwm_chip *fpc = to_fsl_chip(chip);
-	u32 val, period, duty;
+	u32 period, duty;
 
 	mutex_lock(&fpc->lock);
 
@@ -256,11 +258,9 @@ static int fsl_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 			return -EINVAL;
 		}
 
-		val = readl(fpc->base + FTM_SC);
-		val &= ~FTM_SC_PS_MASK;
-		val |= fpc->clk_ps;
-		writel(val, fpc->base + FTM_SC);
-		writel(period - 1, fpc->base + FTM_MOD);
+		regmap_update_bits(fpc->regmap, FTM_SC, FTM_SC_PS_MASK,
+				   fpc->clk_ps);
+		regmap_write(fpc->regmap, FTM_MOD, period - 1);
 
 		fpc->period_ns = period_ns;
 	}
@@ -269,8 +269,9 @@ static int fsl_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
 
 	duty = fsl_pwm_calculate_duty(fpc, period_ns, duty_ns);
 
-	writel(FTM_CSC_MSB | FTM_CSC_ELSB, fpc->base + FTM_CSC(pwm->hwpwm));
-	writel(duty, fpc->base + FTM_CV(pwm->hwpwm));
+	regmap_write(fpc->regmap, FTM_CSC(pwm->hwpwm),
+		     FTM_CSC_MSB | FTM_CSC_ELSB);
+	regmap_write(fpc->regmap, FTM_CV(pwm->hwpwm), duty);
 
 	return 0;
 }
@@ -282,31 +283,28 @@ static int fsl_pwm_set_polarity(struct pwm_chip *chip,
 	struct fsl_pwm_chip *fpc = to_fsl_chip(chip);
 	u32 val;
 
-	val = readl(fpc->base + FTM_POL);
+	regmap_read(fpc->regmap, FTM_POL, &val);
 
 	if (polarity == PWM_POLARITY_INVERSED)
 		val |= BIT(pwm->hwpwm);
 	else
 		val &= ~BIT(pwm->hwpwm);
 
-	writel(val, fpc->base + FTM_POL);
+	regmap_write(fpc->regmap, FTM_POL, val);
 
 	return 0;
 }
 
 static int fsl_counter_clock_enable(struct fsl_pwm_chip *fpc)
 {
-	u32 val;
 	int ret;
 
 	if (fpc->use_count != 0)
 		return 0;
 
 	/* select counter clock source */
-	val = readl(fpc->base + FTM_SC);
-	val &= ~FTM_SC_CLK_MASK;
-	val |= FTM_SC_CLK(fpc->cnt_select);
-	writel(val, fpc->base + FTM_SC);
+	regmap_update_bits(fpc->regmap, FTM_SC, FTM_SC_CLK_MASK,
+			   FTM_SC_CLK(fpc->cnt_select));
 
 	ret = clk_prepare_enable(fpc->clk[fpc->cnt_select]);
 	if (ret)
@@ -326,13 +324,10 @@ static int fsl_counter_clock_enable(struct fsl_pwm_chip *fpc)
 static int fsl_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 {
 	struct fsl_pwm_chip *fpc = to_fsl_chip(chip);
-	u32 val;
 	int ret;
 
 	mutex_lock(&fpc->lock);
-	val = readl(fpc->base + FTM_OUTMASK);
-	val &= ~BIT(pwm->hwpwm);
-	writel(val, fpc->base + FTM_OUTMASK);
+	regmap_update_bits(fpc->regmap, FTM_OUTMASK, BIT(pwm->hwpwm), 0);
 
 	ret = fsl_counter_clock_enable(fpc);
 	mutex_unlock(&fpc->lock);
@@ -342,8 +337,6 @@ static int fsl_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 
 static void fsl_counter_clock_disable(struct fsl_pwm_chip *fpc)
 {
-	u32 val;
-
 	/*
 	 * already disabled, do nothing
 	 */
@@ -355,9 +348,7 @@ static void fsl_counter_clock_disable(struct fsl_pwm_chip *fpc)
 		return;
 
 	/* no users left, disable PWM counter clock */
-	val = readl(fpc->base + FTM_SC);
-	val &= ~FTM_SC_CLK_MASK;
-	writel(val, fpc->base + FTM_SC);
+	regmap_update_bits(fpc->regmap, FTM_SC, FTM_SC_CLK_MASK, 0);
 
 	clk_disable_unprepare(fpc->clk[FSL_PWM_CLK_CNTEN]);
 	clk_disable_unprepare(fpc->clk[fpc->cnt_select]);
@@ -369,14 +360,12 @@ static void fsl_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
 	u32 val;
 
 	mutex_lock(&fpc->lock);
-	val = readl(fpc->base + FTM_OUTMASK);
-	val |= BIT(pwm->hwpwm);
-	writel(val, fpc->base + FTM_OUTMASK);
+	regmap_update_bits(fpc->regmap, FTM_OUTMASK, BIT(pwm->hwpwm),
+			   BIT(pwm->hwpwm));
 
 	fsl_counter_clock_disable(fpc);
 
-	val = readl(fpc->base + FTM_OUTMASK);
-
+	regmap_read(fpc->regmap, FTM_OUTMASK, &val);
 	if ((val & 0xFF) == 0xFF)
 		fpc->period_ns = 0;
 
@@ -401,19 +390,28 @@ static int fsl_pwm_init(struct fsl_pwm_chip *fpc)
 	if (ret)
 		return ret;
 
-	writel(0x00, fpc->base + FTM_CNTIN);
-	writel(0x00, fpc->base + FTM_OUTINIT);
-	writel(0xFF, fpc->base + FTM_OUTMASK);
+	regmap_write(fpc->regmap, FTM_CNTIN, 0x00);
+	regmap_write(fpc->regmap, FTM_OUTINIT, 0x00);
+	regmap_write(fpc->regmap, FTM_OUTMASK, 0xFF);
 
 	clk_disable_unprepare(fpc->clk[FSL_PWM_CLK_SYS]);
 
 	return 0;
 }
 
+static struct regmap_config fsl_pwm_regmap_config = {
+	.reg_bits = 32,
+	.reg_stride = 4,
+	.val_bits = 32,
+
+	.max_register = FTM_PWMLOAD,
+};
+
 static int fsl_pwm_probe(struct platform_device *pdev)
 {
 	struct fsl_pwm_chip *fpc;
 	struct resource *res;
+	void __iomem *base;
 	int ret;
 
 	fpc = devm_kzalloc(&pdev->dev, sizeof(*fpc), GFP_KERNEL);
@@ -425,9 +423,16 @@ static int fsl_pwm_probe(struct platform_device *pdev)
 	fpc->chip.dev = &pdev->dev;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	fpc->base = devm_ioremap_resource(&pdev->dev, res);
-	if (IS_ERR(fpc->base))
-		return PTR_ERR(fpc->base);
+	base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	fpc->regmap = devm_regmap_init_mmio_clk(&pdev->dev, NULL, base,
+						&fsl_pwm_regmap_config);
+	if (IS_ERR(fpc->regmap)) {
+		dev_err(&pdev->dev, "regmap init failed\n");
+		return PTR_ERR(fpc->regmap);
+	}
 
 	fpc->clk[FSL_PWM_CLK_SYS] = devm_clk_get(&pdev->dev, "ftm_sys");
 	if (IS_ERR(fpc->clk[FSL_PWM_CLK_SYS])) {
-- 
1.8.5

[PATCHv3 3/3] pwm: documentation: Add 'big-endian' property for FTM PWM.

[Xiubo Li]

For the same FTM PWM device, which on different SoCs will in
differrent endian mode, using the same linux device driver need
one boolean properties to distingush this.

For now the FTM PWM is only applied to the ARM SoCs which are all
in LE mode.

So the DT binding for FTM PWM device endian:
SoC     |  FTM-PWM | 'big-endian' property is needed?
--------|----------|---------------------------------
Vybird  |    LE    |     No
LS1     |    BE    |     Yes
LS2     |    LE    |     No

Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
---
 .../devicetree/bindings/pwm/pwm-fsl-ftm.txt        | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
index 0bda229..67ed8d6 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
@@ -1,5 +1,23 @@
 Freescale FlexTimer Module (FTM) PWM controller
 
+For the same FTM PWM device, which on different SoCs will in
+differrent endian mode, using the same linux device driver need
+one boolean properties to distingush this.
+
+For now the FTM PWM is only applied to the ARM SoCs which are all
+in LE mode.
+
+So the DT binding for FTM PWM device endian:
+SoC     |  FTM-PWM | 'big-endian' property is needed?
+--------|----------|---------------------------------
+Vybird  |    LE    |     No
+LS1     |    BE    |     Yes
+LS2     |    LE    |     No
+
+Please see "Documentation/devicetree/bindings/regmap/regmap.txt" for more
+detail about the endianness.
+
+
 Required properties:
 - compatible: Should be "fsl,vf610-ftm-pwm".
 - reg: Physical base address and length of the controller's registers
@@ -16,7 +34,8 @@ Required properties:
 - pinctrl-names: Must contain a "default" entry.
 - pinctrl-NNN: One property must exist for each entry in pinctrl-names.
   See pinctrl/pinctrl-bindings.txt for details of the property values.
-
+- big-endian: One boolean property, for all the device registers, the BE mode
+  will be in use if it's present, or the LE mode will be in use.
 
 Example:
 
@@ -32,4 +51,5 @@ pwm0: pwm@40038000 {
 			<&clks VF610_CLK_FTM0_EXT_FIX_EN>;
 		pinctrl-names = "default";
 		pinctrl-0 = <&pinctrl_pwm0_1>;
+		big-endian;
 };
-- 
1.8.5

Re: [PATCHv3 0/3] ftm-pwm: Convert to direct regmap API usage

[Thierry Reding]

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

On Mon, Aug 18, 2014 at 11:32:32AM +0800, Xiubo Li wrote:
> 
> This is depended on the following patches, which has been applied by
> Mark into his Regmap-Tree:
> https://lkml.org/lkml/2014/7/15/6
> https://lkml.org/lkml/2014/7/15/5
> https://lkml.org/lkml/2014/7/15/7

This doesn't seem to have any build dependencies on the above patches.
So with only this applied to the PWM tree at worst the registers will be
accessed in the wrong endianess and the PWM won't work as expected. Does
that matter? Or should I request a stable branch from Mark to pull into
the PWM tree so that this doesn't happen?

In linux-next things should be fine since both branches will be merged.
I guess there could still be an issue depending on the order in which
Linus merges the trees for 3.18, in which case there could be a brief
period where Linus' tree runtime-breaks on platforms requiring this. But
I'm not sure if that's really an issue.

Thierry

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

Re: [PATCHv3 2/3] pwm: ftm-pwm: Convert to direct regmap API usage.

[Thierry Reding]

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

On Mon, Aug 18, 2014 at 11:32:34AM +0800, Xiubo Li wrote:
[...]
> diff --git a/drivers/pwm/pwm-fsl-ftm.c b/drivers/pwm/pwm-fsl-ftm.c
[...]
> +static struct regmap_config fsl_pwm_regmap_config = {

This can be static const, but since it's the only comment I can fix that
up myself when applying.

Thierry

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

RE: [PATCHv3 0/3] ftm-pwm: Convert to direct regmap API usage

[Li.Xiubo]

> -----Original Message-----
> From: Thierry Reding [mailto:thierry.reding@gmail.com]
> Sent: Monday, August 18, 2014 4:32 PM
> To: Xiubo Li-B47053
> Cc: linux-pwm@vger.kernel.org; robh+dt@kernel.org; pawel.moll@arm.com;
> rdunlap@infradead.org; devicetree@vger.kernel.org; linux-doc@vger.kernel.org
> Subject: Re: [PATCHv3 0/3] ftm-pwm: Convert to direct regmap API usage
> 
> On Mon, Aug 18, 2014 at 11:32:32AM +0800, Xiubo Li wrote:
> >
> > This is depended on the following patches, which has been applied by
> > Mark into his Regmap-Tree:
> > https://lkml.org/lkml/2014/7/15/6
> > https://lkml.org/lkml/2014/7/15/5
> > https://lkml.org/lkml/2014/7/15/7
> 
> This doesn't seem to have any build dependencies on the above patches.

Yes, you are right.


> So with only this applied to the PWM tree at worst the registers will be
> accessed in the wrong endianess and the PWM won't work as expected. Does
> that matter? 

No, I think it's okay, we'll only test our drivers in the Linus's stable branch.



> Or should I request a stable branch from Mark to pull into
> the PWM tree so that this doesn't happen?
> 
> In linux-next things should be fine since both branches will be merged.
> I guess there could still be an issue depending on the order in which
> Linus merges the trees for 3.18, in which case there could be a brief
> period where Linus' tree runtime-breaks on platforms requiring this. But
> I'm not sure if that's really an issue.
> 

The depended patches has been merged into the Linux-next tree just now already
today.

And then could we guarantee that these ftm-pwm patches to be in order after the
depended ones ?

Thanks,

BRs
Xiubo


> Thierry

RE: [PATCHv3 2/3] pwm: ftm-pwm: Convert to direct regmap API usage.

[Li.Xiubo-KZfg59tc24xl57MIdRCFDg]

> -----Original Message-----
> From: Thierry Reding [mailto:thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
> Sent: Monday, August 18, 2014 4:37 PM
> To: Xiubo Li-B47053
> Cc: linux-pwm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; pawel.moll-5wv7dgnIgG8@public.gmane.org;
> rdunlap-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: [PATCHv3 2/3] pwm: ftm-pwm: Convert to direct regmap API usage.
> 
> On Mon, Aug 18, 2014 at 11:32:34AM +0800, Xiubo Li wrote:
> [...]
> > diff --git a/drivers/pwm/pwm-fsl-ftm.c b/drivers/pwm/pwm-fsl-ftm.c
> [...]
> > +static struct regmap_config fsl_pwm_regmap_config = {
> 
> This can be static const, but since it's the only comment I can fix that
> up myself when applying.
> 

That's good, thanks very much.

BRs
Xiubo



> Thierry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 0/3] ftm-pwm: Convert to direct regmap API usage

[Thierry Reding]

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

On Mon, Aug 18, 2014 at 08:43:56AM +0000, Li.Xiubo@freescale.com wrote:
> > -----Original Message-----
> > From: Thierry Reding [mailto:thierry.reding@gmail.com]
> > Sent: Monday, August 18, 2014 4:32 PM
> > To: Xiubo Li-B47053
> > Cc: linux-pwm@vger.kernel.org; robh+dt@kernel.org; pawel.moll@arm.com;
> > rdunlap@infradead.org; devicetree@vger.kernel.org; linux-doc@vger.kernel.org
> > Subject: Re: [PATCHv3 0/3] ftm-pwm: Convert to direct regmap API usage
> > 
> > On Mon, Aug 18, 2014 at 11:32:32AM +0800, Xiubo Li wrote:
> > >
> > > This is depended on the following patches, which has been applied by
> > > Mark into his Regmap-Tree:
> > > https://lkml.org/lkml/2014/7/15/6
> > > https://lkml.org/lkml/2014/7/15/5
> > > https://lkml.org/lkml/2014/7/15/7
> > 
> > This doesn't seem to have any build dependencies on the above patches.
> 
> Yes, you are right.
> 
> 
> > So with only this applied to the PWM tree at worst the registers will be
> > accessed in the wrong endianess and the PWM won't work as expected. Does
> > that matter? 
> 
> No, I think it's okay, we'll only test our drivers in the Linus's stable branch.
> 
> 
> 
> > Or should I request a stable branch from Mark to pull into
> > the PWM tree so that this doesn't happen?
> > 
> > In linux-next things should be fine since both branches will be merged.
> > I guess there could still be an issue depending on the order in which
> > Linus merges the trees for 3.18, in which case there could be a brief
> > period where Linus' tree runtime-breaks on platforms requiring this. But
> > I'm not sure if that's really an issue.
> > 
> 
> The depended patches has been merged into the Linux-next tree just now already
> today.
> 
> And then could we guarantee that these ftm-pwm patches to be in order after the
> depended ones ?

I could merge Mark's regmap tree into the PWM tree to guarantee that.
I'm just wondering if it's worth the trouble since there's no compile-
time dependency so the issue will only show up when running a kernel
built directly from the PWM tree (or some tree that has the PWM tree
merged but not regmap). And even then it will only happen if there's a
device tree for a device that requires special endianess handling.

But it's really your call. If you think it's safer to merge them in the
correct order then I'll ask Mark for a stable regmap branch that I can
pull.

Thierry

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

RE: [PATCHv3 0/3] ftm-pwm: Convert to direct regmap API usage

[Li.Xiubo]

> -----Original Message-----
> From: Thierry Reding [mailto:thierry.reding@gmail.com]
> Sent: Monday, August 18, 2014 4:49 PM
> To: Xiubo Li-B47053
> Cc: linux-pwm@vger.kernel.org; robh+dt@kernel.org; pawel.moll@arm.com;
> rdunlap@infradead.org; devicetree@vger.kernel.org; linux-doc@vger.kernel.org
> Subject: Re: [PATCHv3 0/3] ftm-pwm: Convert to direct regmap API usage
> 
> On Mon, Aug 18, 2014 at 08:43:56AM +0000, Li.Xiubo@freescale.com wrote:
> > > -----Original Message-----
> > > From: Thierry Reding [mailto:thierry.reding@gmail.com]
> > > Sent: Monday, August 18, 2014 4:32 PM
> > > To: Xiubo Li-B47053
> > > Cc: linux-pwm@vger.kernel.org; robh+dt@kernel.org; pawel.moll@arm.com;
> > > rdunlap@infradead.org; devicetree@vger.kernel.org; linux-
> doc@vger.kernel.org
> > > Subject: Re: [PATCHv3 0/3] ftm-pwm: Convert to direct regmap API usage
> > >
> > > On Mon, Aug 18, 2014 at 11:32:32AM +0800, Xiubo Li wrote:
> > > >
> > > > This is depended on the following patches, which has been applied by
> > > > Mark into his Regmap-Tree:
> > > > https://lkml.org/lkml/2014/7/15/6
> > > > https://lkml.org/lkml/2014/7/15/5
> > > > https://lkml.org/lkml/2014/7/15/7
> > >
> > > This doesn't seem to have any build dependencies on the above patches.
> >
> > Yes, you are right.
> >
> >
> > > So with only this applied to the PWM tree at worst the registers will be
> > > accessed in the wrong endianess and the PWM won't work as expected. Does
> > > that matter?
> >
> > No, I think it's okay, we'll only test our drivers in the Linus's stable
> branch.
> >
> >
> >
> > > Or should I request a stable branch from Mark to pull into
> > > the PWM tree so that this doesn't happen?
> > >
> > > In linux-next things should be fine since both branches will be merged.
> > > I guess there could still be an issue depending on the order in which
> > > Linus merges the trees for 3.18, in which case there could be a brief
> > > period where Linus' tree runtime-breaks on platforms requiring this. But
> > > I'm not sure if that's really an issue.
> > >
> >
> > The depended patches has been merged into the Linux-next tree just now
> already
> > today.
> >
> > And then could we guarantee that these ftm-pwm patches to be in order after
> the
> > depended ones ?
> 
> I could merge Mark's regmap tree into the PWM tree to guarantee that.
> I'm just wondering if it's worth the trouble since there's no compile-
> time dependency so the issue will only show up when running a kernel
> built directly from the PWM tree (or some tree that has the PWM tree
> merged but not regmap). And even then it will only happen if there's a
> device tree for a device that requires special endianess handling.
> 
> But it's really your call. If you think it's safer to merge them in the
> correct order then I'll ask Mark for a stable regmap branch that I can
> pull.
> 

I think it okay, since the LS1 platform driver patches are still in process,
and only in LS1 SoC will depend this.

You can just merge this to PWM tree if everything is okay.

Thanks,

BRs
Xiubo



> Thierry

Re: [PATCHv3 3/3] pwm: documentation: Add 'big-endian' property for FTM PWM.

[Mark Rutland]

On Mon, Aug 18, 2014 at 04:32:35AM +0100, Xiubo Li wrote:
> For the same FTM PWM device, which on different SoCs will in
> differrent endian mode, using the same linux device driver need
> one boolean properties to distingush this.
> 
> For now the FTM PWM is only applied to the ARM SoCs which are all
> in LE mode.
> 
> So the DT binding for FTM PWM device endian:
> SoC     |  FTM-PWM | 'big-endian' property is needed?
> --------|----------|---------------------------------
> Vybird  |    LE    |     No
> LS1     |    BE    |     Yes
> LS2     |    LE    |     No
> 
> Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
> ---
>  .../devicetree/bindings/pwm/pwm-fsl-ftm.txt        | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
> index 0bda229..67ed8d6 100644
> --- a/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
> +++ b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
> @@ -1,5 +1,23 @@
>  Freescale FlexTimer Module (FTM) PWM controller
>  
> +For the same FTM PWM device, which on different SoCs will in
> +differrent endian mode, using the same linux device driver need
> +one boolean properties to distingush this.

There is absolutely no need to mention Linux if this is truly a HW
property.

> +
> +For now the FTM PWM is only applied to the ARM SoCs which are all
> +in LE mode.
> +
> +So the DT binding for FTM PWM device endian:
> +SoC     |  FTM-PWM | 'big-endian' property is needed?
> +--------|----------|---------------------------------
> +Vybird  |    LE    |     No
> +LS1     |    BE    |     Yes
> +LS2     |    LE    |     No
> +
> +Please see "Documentation/devicetree/bindings/regmap/regmap.txt" for more
> +detail about the endianness.

Surely all we need is:

The FTM PWM device can be integrated as little-endian or big-endian.
This endianness differs per SoC:

SoC     | FTM-PWM endianness
--------+-------------------
Vybrid  | LE
LS1     | BE
LS2     | LE

> +
> +
>  Required properties:
>  - compatible: Should be "fsl,vf610-ftm-pwm".
>  - reg: Physical base address and length of the controller's registers
> @@ -16,7 +34,8 @@ Required properties:
>  - pinctrl-names: Must contain a "default" entry.
>  - pinctrl-NNN: One property must exist for each entry in pinctrl-names.
>    See pinctrl/pinctrl-bindings.txt for details of the property values.
> -
> +- big-endian: One boolean property, for all the device registers, the BE mode
> +  will be in use if it's present, or the LE mode will be in use.

- big-endian: Boolean property, required if all the FTM_PWM registers
  are big-endian rather than little-endian.

Cheers,
Mark.

>  
>  Example:
>  
> @@ -32,4 +51,5 @@ pwm0: pwm@40038000 {
>  			<&clks VF610_CLK_FTM0_EXT_FIX_EN>;
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&pinctrl_pwm0_1>;
> +		big-endian;
>  };
> -- 
> 1.8.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: [PATCHv3 3/3] pwm: documentation: Add 'big-endian' property for FTM PWM.

[Li.Xiubo]

[...]
>>  Freescale FlexTimer Module (FTM) PWM controller
>>
>> +For the same FTM PWM device, which on different SoCs will in
>> +differrent endian mode, using the same linux device driver need
>> +one boolean properties to distingush this.
>
> There is absolutely no need to mention Linux if this is truly a HW
> property.

Okay.

[...]
>> +
>> +For now the FTM PWM is only applied to the ARM SoCs which are all
>> +in LE mode.
>> +
>> +So the DT binding for FTM PWM device endian:
>> +SoC     |  FTM-PWM | 'big-endian' property is needed?
>> +--------|----------|---------------------------------
>> +Vybird  |    LE    |     No
>> +LS1     |    BE    |     Yes
>> +LS2     |    LE    |     No
>> +
>> +Please see "Documentation/devicetree/bindings/regmap/regmap.txt" for more
>> +detail about the endianness.
>
> Surely all we need is:
>
> The FTM PWM device can be integrated as little-endian or big-endian.
> This endianness differs per SoC:
>
> SoC     | FTM-PWM endianness
> --------+-------------------
> Vybrid  | LE
> LS1     | BE
> LS2     | LE

I'll follow your advice.

[...]
>> +- big-endian: One boolean property, for all the device registers, the BE mode
>> +  will be in use if it's present, or the LE mode will be in use.
>
>- big-endian: Boolean property, required if all the FTM_PWM registers
>  are big-endian rather than little-endian.
>

See the next version.

Thanks very much for you comment and advice.

BRs
XIubo



> Cheers,
> Mark.