[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF+7xWnJo3VrZ+iH4BJHkTmo5+D9ttZ1n1Tm0KMPQqK1sKD7wQ@mail.gmail.com>
Date: Tue, 26 Jun 2012 17:27:26 +0800
From: Axel Lin <axel.lin@...il.com>
To: Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc: linux-kernel@...r.kernel.org, Liam Girdwood <lrg@...com>
Subject: Re: [PATCH] regulator: arizona-micsupp: Fix choosing selector in arizona_micsupp_map_voltage
2012/6/26 Mark Brown <broonie@...nsource.wolfsonmicro.com>:
> On Tue, Jun 26, 2012 at 04:01:47PM +0800, Axel Lin wrote:
>
>> + if (min_uV > 3300000)
>> + return -EINVAL;
>> +
>
> This is OK but I think we want to factor this out into the caller as
> we're implementing this limits check in a lot of places.
It seems most of the new code are calling list_voltage() in
map_voltage to ensure
the selected voltage are still in bound.
But in this case, current actually set selector to
ARIZONA_MICSUPP_MAX_SELECTOR in map_voltage() if
min_uV >= 3300000. calling list_voltage() still returns valid voltage
for this case looks wrong to me.
>
>> - if (min_uV >= 3300000)
>> + if (min_uV > 3200000)
>> selector = ARIZONA_MICSUPP_MAX_SELECTOR;
>> else
>> selector = DIV_ROUND_UP(min_uV - 1700000, 50000);
>
> This doesn't change anything; with version of the if statement will give
> 3.3V for a voltage between 3.2V and 3.3V as there's no gaps in the
> selector space so if we're over 3.2V we'll round up to 3.3V.
If min_uV is in the range of: 3250001~3269999,
current code uses the equation: selector = DIV_ROUND_UP(min_uV -
1700000, 50000);
Then selector will be 32.
Then arizona_micsupp_list_voltage returns -EINVAL for this case.
With this patch, the selector will be 31 for this case.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists