tree 8fc7ed2e183e25da20699be045fc873ac250215d
parent f05912493278dbabab8ebcc43510867e59a72a50
author Douglas Anderson <dianders@chromium.org> 1553750110 -0700
committer Fabien Parent <parent.f@gmail.com> 1590746079 +0000

CHROMIUM: MALI: More properly handle missing regulators

The mali code makes some attempt to work without regulators but it's
definitely wonky.  Let's clean it up.  Specifically:

1. We'll use regulator_get() instead of regulator_get_optional().
   This causes the regulator framework to create a dummy regulator for
   us that we can safely enable/disable and is there specifically to
   avoid the need for special cases like this.  When the framework
   creates a dummy it nicely prints to the logs so you're aware of it,
   like: "ffa30000.gpu supply bogus not found, using dummy regulator"
2. We know regulator_get() won't return NULL so don't check for it.
   The old code wouldn't have worked right if regulator_get_optional()
   had returned NULL since the PTR_ERR() call below wouldn't have made
   sense.
3. In general we don't want to print about EPROBE_DEFER errors, so
   let's not do that.  ...and, in fact, now that we're using
   regulator_get() we no longer _expect_ any errors, so we end up
   totally inverting the old "if" test for when to print errors.
4. If a regulator is missing (or was replaced with a dummy) then
   dev_opp_table will fail to init.  When that happened we didn't
   crash but we'd keep spewing "core: dev_pm_opp_get_voltage_supply:
   Invalid supply index" all the time.  Let's fix it to just not init
   devfreq in this case since (I believe) devfreq makes no real sense
   without a regulator.

BUG=chromium:941638
TEST=devfreq works OK on veyron still
TEST=Add 'supply-names = "mali", "bogus";' to veyron and look at dmesg

Change-Id: Ie9b8b4d4281efaf738989a931e93abb513f37800
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1544030