All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@gmail.com>
To: Andy Green <andy@openmoko.com>
Cc: Balaji Rao <balajirrao@openmoko.org>,
	linux-kernel@vger.kernel.org, Samuel Ortiz <sameo@openedhand.com>
Subject: Re: [PATCH V2 2/7] mfd: PCF50633 adc driver
Date: Fri, 19 Dec 2008 12:51:24 +0000	[thread overview]
Message-ID: <494B98CC.4050700@gmail.com> (raw)
In-Reply-To: <494B9073.8070104@openmoko.com>

Andy Green wrote:
> Somebody in the thread at some point said:
>
> Hi Johnathan -
>
> | This needs a bit more explanation. Particularly as the data
> | sheet describes that accsw as 'for rationmetric measurement'.
>
> What's going on here is that ACCSW can be driven from the PMU to bias a
> resistor divider to scale what's being measured... we use it to detect
> resistor to 0V on ID pin of USB on our charger.
>
> You can power accsw / that divider "by hand" which is what we're doing
> here, or you can have the ratiometric state machine change the mux /
> bias automatically between the two measurements it takes, which we're
> not doing.
That makes sense. Thanks for the explanation.
>
> | Also, seeing as I assume this is the only driver that can touch
> | these registers and you don't change them else where, why can't
> | they be in initial setup code rather than here? (probably a good
> | reason, but be nice to have it document here!)
>
> ADCC2 setting concerned with ratiometric disable could indeed be moved
> to init, it was done like this before I did the queuing stuff and we
> took ADC measurement in two different places in the code.  But in fact
> for the best we should only enable accsw until the measurement completes
> and save a tiny bit of power.
Either way sounds fine to me as I'd be surprised if it is a significant
power
drain and anyway it would come at the cost of a couple more register writes
which, if the bus is slow, would be more of an issue.

>
> |> +    /* kill ratiometric, but enable ACCSW biasing */
> |> +    pcf50633_reg_write(pcf, PCF50633_REG_ADCC2, 0x00);
> |> +    pcf50633_reg_write(pcf, PCF50633_REG_ADCC3, 0x01);
> |> +
> |> +    /* start ADC conversion on selected channel */
> |> +    pcf50633_reg_write(pcf, PCF50633_REG_ADCC1, channel | avg |
> | ...
> |> +
> |> +static void pcf50633_adc_irq(int irq, void *data)
> |> +{
> |> +    struct pcf50633_adc *adc = data;
> |> +    struct pcf50633 *pcf = adc->pcf;
> |> +    struct pcf50633_adc_request *req;
> |> +    int head;
> |> +    mutex_lock(&adc->queue_mutex);
> |> +    head = adc->queue_head;
> |> +
> |> +    req = adc->queue[head];
> |> +    if (WARN_ON(!req)) {
> |> +        dev_err(pcf->dev, "pcf50633-adc irq: ADC queue empty!\n");
> |> +        mutex_unlock(&adc->queue_mutex);
> |> +        return;
> |> +    }
> |> +    adc->queue[head] = NULL;
> |
> | Weird formatting?
> |
> |> +    adc->queue_head = (head + 1) &
> |> +                      (PCF50633_MAX_ADC_FIFO_DEPTH - 1);
> |> +
> |> +    mutex_unlock(&adc->queue_mutex);
>
> This would save the power
>
> ~    pcf50633_reg_write(pcf, PCF50633_REG_ADCC3, 0x0);
>
> |> +    req->callback(pcf, req->callback_param, adc_result(pcf));
> |> +    kfree(req);
> |> +
> |> +    trigger_next_adc_job_if_any(pcf);
> |> +}
> |> +
> | Rest looks good to me.
> |
> | Acked-by: Jonathan Cameron
> |
>
> -Andy


  reply	other threads:[~2008-12-19 12:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-18  5:56 [PATCH V2 0/7] PCF50633 support Balaji Rao
2008-12-18  5:56 ` [PATCH V2 1/7] mfd: PCF50633 core driver Balaji Rao
2008-12-18  5:56 ` [PATCH V2 2/7] mfd: PCF50633 adc driver Balaji Rao
2008-12-19 11:18   ` Jonathan Cameron
2008-12-19 12:05     ` Mark Brown
2008-12-19 12:47       ` Jonathan Cameron
2008-12-19 12:15     ` Andy Green
2008-12-19 12:51       ` Jonathan Cameron [this message]
2008-12-22 16:23     ` Balaji Rao
2008-12-18  5:57 ` [PATCH V2 3/7] mfd: PCF50633 gpio support Balaji Rao
2008-12-18  5:57 ` [PATCH V2 4/7] rtc: PCF50633 rtc driver Balaji Rao
2008-12-18  9:03   ` Alessandro Zummo
2008-12-18 15:11     ` Balaji Rao
2008-12-18 16:52       ` Alessandro Zummo
2008-12-18  5:57 ` [PATCH V2 5/7] power_supply: PCF50633 battery charger driver Balaji Rao
2008-12-18 20:26   ` Balaji Rao
2008-12-25 15:45   ` Anton Vorontsov
2008-12-25 18:50     ` Balaji Rao
2008-12-18  5:58 ` [PATCH V2 6/7] input: PCF50633 input driver Balaji Rao
2008-12-18  5:58 ` [PATCH V2 7/7] regulator: PCF50633 pmic driver Balaji Rao
2008-12-18 10:08   ` Mark Brown
2008-12-18 15:14     ` Balaji Rao
2008-12-18 20:30       ` Liam Girdwood
2008-12-18 20:47         ` Balaji Rao
2008-12-18 20:54           ` Liam Girdwood
2008-12-22 10:50 ` [PATCH V2 0/7] PCF50633 support Samuel Ortiz

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=494B98CC.4050700@gmail.com \
    --to=jonathan.cameron@gmail.com \
    --cc=andy@openmoko.com \
    --cc=balajirrao@openmoko.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sameo@openedhand.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.