Linux on ARM based TI OMAP SoCs
 help / color / mirror / Atom feed
From: "Péter Ujfalusi" <peter.ujfalusi@ti.com>
To: Grazvydas Ignotas <notasas@gmail.com>
Cc: Thierry Reding <thierry.reding@avionic-design.de>,
	Tero Kristo <t-kristo@ti.com>,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/3] pwm: New driver to support PWMs on TWL4030/6030 series of PMICs
Date: Thu, 8 Nov 2012 08:14:36 +0100	[thread overview]
Message-ID: <509B5BDC.3030005@ti.com> (raw)
In-Reply-To: <CANOLnOM7sp+O+KBKjiRk2drWh_63D6-bY86dx+upWkrvs7pp9w@mail.gmail.com>

On 11/07/2012 06:50 PM, Grazvydas Ignotas wrote:
>> +static int twl4030_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
>> +{
>> +       int ret;
>> +       u8 val;
>> +
>> +       ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, &val, TWL4030_GPBR1_REG);
>> +       if (ret < 0) {
>> +               dev_err(chip->dev, "%s: Failed to read GPBR1\n", pwm->label);
>> +               return ret;
>> +       }
>> +
>> +       val |= TWL4030_PWM_TOGGLE(pwm->hwpwm, TWL4030_PWMX_BITS);
> 
> In my experience doing it like this doesn't work reliably, i.e.
> sometimes it just won't enable. I had to first set CLK_ENABLE bit, and
> then ENABLE bit with separate i2c write. Perhaps it needs a cycle or
> two of 32k clock or something (that doesn't seem to be documented
> though).

Thanks, I'll change to the reliable sequence. I do not have HW where I can
test the twl4030 PWMs.

> 
>> +
>> +       ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
>> +       if (ret < 0)
>> +               dev_err(chip->dev, "%s: Failed to enable PWM\n", pwm->label);
>> +
>> +       return ret;
>> +}
>> +
>> +static void twl4030_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
>> +{
>> +       int ret;
>> +       u8 val;
>> +
>> +       ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, &val, TWL4030_GPBR1_REG);
>> +       if (ret < 0) {
>> +               dev_err(chip->dev, "%s: Failed to read GPBR1\n", pwm->label);
>> +               return;
>> +       }
>> +
>> +       val &= ~TWL4030_PWM_TOGGLE(pwm->hwpwm, TWL4030_PWMX_BITS);
> 
> Same problem here, I would sometimes get LED stuck at full brightness
> after this, first clearing ENABLE and then CLK_ENABLE fixed it (we
> have charger LED connected to PWM1 on pandora).

I would guessed that if we need special care we should have turned off CLK
followed by disabling the PWM.
I'll use the sequence you described in the next version.

> 
>> +
>> +       ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, val, TWL4030_GPBR1_REG);
>> +       if (ret < 0)
>> +               dev_err(chip->dev, "%s: Failed to disable PWM\n", pwm->label);
>> +}
>> +
>> +static int twl4030_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
>> +{
>> +       struct twl_pwm_chip *twl = container_of(chip, struct twl_pwm_chip,
>> +                                               chip);
>> +       int ret;
>> +       u8 val, mask, bits;
>> +
>> +       ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, &val, TWL4030_PMBR1_REG);
>> +       if (ret < 0) {
>> +               dev_err(chip->dev, "%s: Failed to read PMBR1\n", pwm->label);
>> +               return ret;
>> +       }
>> +
>> +       if (pwm->hwpwm) {
>> +               /* PWM 1 */
>> +               mask = TWL4030_GPIO7_VIBRASYNC_PWM1_MASK;
>> +               bits = TWL4030_GPIO7_VIBRASYNC_PWM1_PWM1;
>> +       } else {
>> +               /* PWM 0 */
>> +               mask = TWL4030_GPIO6_PWM0_MUTE_MASK;
>> +               bits = TWL4030_GPIO6_PWM0_MUTE_PWM0;
>> +       }
>> +
>> +       /* Save the current MUX configuration for the PWM */
>> +       twl->twl4030_pwm_mux &= ~mask;
>> +       twl->twl4030_pwm_mux |= (val & mask);
> 
> Do we really need this mask clearing here? After probe twl4030_pwm_mux
> should be zero, and if twl4030_pwm_request is called twice you don't
> clear the important bits before |=, I think 'twl4030_pwm_mux = val &
> mask' would be better here.

I'm storing both PWM's state in the same variable, but in different offsets:
PWM0: bits 2-3
PWM1: bits 4-5
Probably it is over engineering to clear the relevant bits in the backup
storage, but better to be safe IMHO.
I would leave this part as it is.

-- 
Péter

  reply	other threads:[~2012-11-08  7:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-07 14:44 [PATCH 0/3] pwm: Drivers for twl4030/6030 PWMs and LEDs Peter Ujfalusi
2012-11-07 14:44 ` [PATCH 1/3] pwm: Remove pwm-twl6030 driver Peter Ujfalusi
2012-11-07 14:44 ` [PATCH 2/3] pwm: New driver to support PWMs on TWL4030/6030 series of PMICs Peter Ujfalusi
2012-11-07 17:50   ` Grazvydas Ignotas
2012-11-08  7:14     ` Péter Ujfalusi [this message]
2012-11-08 11:53       ` Grazvydas Ignotas
2012-11-07 14:44 ` [PATCH 3/3] pwm: New driver to support PWM driven LEDs " Peter Ujfalusi
2012-11-07 18:12   ` Grazvydas Ignotas
2012-11-08  7:34     ` Péter Ujfalusi
2012-11-08 12:29       ` Grazvydas Ignotas
2012-11-08 12:55         ` Péter Ujfalusi

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=509B5BDC.3030005@ti.com \
    --to=peter.ujfalusi@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=notasas@gmail.com \
    --cc=t-kristo@ti.com \
    --cc=thierry.reding@avionic-design.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