From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-pwm@vger.kernel.org,
Nicolas Ferre <nicolas.ferre@atmel.com>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
Alexandre Belloni <alexandre.belloni@free-electrons.com>,
Andrew Victor <linux@maxim.org.za>
Subject: Re: [PATCH] pwm: atmel-hlcdc: add at91sam9x5 and sama5d3 errata handling
Date: Tue, 18 Nov 2014 16:53:33 +0100 [thread overview]
Message-ID: <20141118165333.6d9ff951@bbrezillon> (raw)
In-Reply-To: <20141118150016.GB18586@ulmo>
Hi Thierry,
On Tue, 18 Nov 2014 16:00:23 +0100
Thierry Reding <thierry.reding@gmail.com> wrote:
> On Tue, Nov 18, 2014 at 01:40:53PM +0100, Boris Brezillon wrote:
> > at91sam9x5 has an errata forbidding the use of slow clk as a clk source and
> > sama5d3 SoCs has another errata forbidding the use of div1 prescaler.
> >
> > Take both of these erratas into account.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > ---
> > drivers/pwm/pwm-atmel-hlcdc.c | 28 +++++++++++++++++++++++-----
> > 1 file changed, 23 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
> > index eaf8b12..405f8a5 100644
> > --- a/drivers/pwm/pwm-atmel-hlcdc.c
> > +++ b/drivers/pwm/pwm-atmel-hlcdc.c
> > @@ -36,6 +36,8 @@ struct atmel_hlcdc_pwm {
> > struct pwm_chip chip;
> > struct atmel_hlcdc *hlcdc;
> > struct clk *cur_clk;
> > + bool slow_clk_errata;
> > + bool div1_clk_errata;
> > };
> >
> > static inline struct atmel_hlcdc_pwm *to_atmel_hlcdc_pwm(struct pwm_chip *chip)
> > @@ -56,20 +58,28 @@ static int atmel_hlcdc_pwm_config(struct pwm_chip *c,
> > u32 pwmcfg;
> > int pres;
> >
> > - clk_freq = clk_get_rate(new_clk);
> > - clk_period_ns = (u64)NSEC_PER_SEC * 256;
> > - do_div(clk_period_ns, clk_freq);
> > + if (!chip->slow_clk_errata) {
> > + clk_freq = clk_get_rate(new_clk);
> > + clk_period_ns = (u64)NSEC_PER_SEC * 256;
> > + do_div(clk_period_ns, clk_freq);
> > + }
> >
> > - if (clk_period_ns > period_ns) {
> > + /* Errata: cannot use slow clk on some IP revisions */
> > + if (chip->slow_clk_errata || clk_period_ns > period_ns) {
> > new_clk = hlcdc->sys_clk;
> > clk_freq = clk_get_rate(new_clk);
> > clk_period_ns = (u64)NSEC_PER_SEC * 256;
> > do_div(clk_period_ns, clk_freq);
> > }
> >
> > - for (pres = 0; pres <= ATMEL_HLCDC_PWMPS_MAX; pres++)
> > + for (pres = 0; pres <= ATMEL_HLCDC_PWMPS_MAX; pres++) {
> > + /* Errata: cannot divide by 1 on some IP revisions */
> > + if (!pres && chip->div1_clk_errata)
> > + continue;
> > +
> > if ((clk_period_ns << pres) >= period_ns)
> > break;
> > + }
> >
> > if (pres > ATMEL_HLCDC_PWMPS_MAX)
> > return -EINVAL;
> > @@ -204,6 +214,14 @@ static int atmel_hlcdc_pwm_probe(struct platform_device *pdev)
> > if (ret)
> > return ret;
> >
> > + if (of_device_is_compatible(dev->parent->of_node,
> > + "atmel,sama5d3-hlcdc"))
> > + chip->div1_clk_errata = true;
> > +
> > + if (of_device_is_compatible(dev->parent->of_node,
> > + "atmel,at91sam9x5-hlcdc"))
> > + chip->slow_clk_errata = true;
>
> Generally I'd prefer this to be done as "SoC data", where the idea is to
> not rely on these checks at probe time (because they don't scale very
> well in the long term). Somewhat like the following:
>
> struct atmel_hlcdc_soc {
> bool slow_clk_errata;
> bool div1_clk_errata;
> };
>
> static const struct atmel_hlcdc_soc sama5d3_hlcdc = {
> .slow_clk_errata = false,
> .div1_clk_errata = true,
> };
>
> static const struct atmel_hlcdc_soc at91sam9x5_hlcdc = {
> .slow_clk_errata = true,
> .div1_clk_errata = false,
> };
>
> Then put those into a struct of_device_id table and do the matching
> using of_match_device(). Then you can simply do something like:
>
> match = of_match_device(dev->parent, atmel_hlcdc_matches);
> if (match)
> chip->soc = match->data;
I'm perfectly with using device_id data field to achieve that.
I'll change that for my next version.
>
> And then check on the fields set therein. This works optimally if the
> device isn't a subdevice because you have most of that code anyway. In
> this particular case the lookup needs to happen on the parent, which
> isn't so nice.
>
> I'm willing to let this go for now, but if this list is going to grow
> I'll request that it be done differently so that .probe() doesn't need
> to be cluttered.
>
> Also I wonder if it would be better to just add these new compatibles to
> the PWM block binding, too, since it's obviously the IP blocks that have
> these errata rather than the HLCDC block. So technically I think you'd
> have to make the driver support atmel,at91sam9x5-hlcdc-pwm and
> atmel,sama5d3-hlcdc-pwm anyway, and then you could just as well move to
> the above matching and SoC data.
Well, actually I did it because the datasheet describe the HLCDC IP
not the HLCDC-PWM and HLCDC-DC IPs (I mean, IP revision is attached to
the HLCDC block, not the HLCDC-PWM and HLCDC-DC sub devices).
Anyway, I'm okay to move MFD compatible string to the sub-device nodes,
but if I do so, I'm not sure it makes sense to have a specific
compatible string for the parent device ("atmel-hlcdc" would do the
job).
Another point in favor of the "one compatible string for all sub-device
revisions" is that it limits the number of mfd cells declared in the MFD
driver.
Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
prev parent reply other threads:[~2014-11-18 15:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-18 12:40 [PATCH] pwm: atmel-hlcdc: add at91sam9x5 and sama5d3 errata handling Boris Brezillon
2014-11-18 14:35 ` Nicolas Ferre
2014-11-18 15:00 ` Thierry Reding
2014-11-18 15:53 ` Boris Brezillon [this message]
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=20141118165333.6d9ff951@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=alexandre.belloni@free-electrons.com \
--cc=linux-pwm@vger.kernel.org \
--cc=linux@maxim.org.za \
--cc=nicolas.ferre@atmel.com \
--cc=plagnioj@jcrosoft.com \
--cc=thierry.reding@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