[Intel-gfx] [PATCH 3/9] drm/i915: Use the CRC gpio for panel enable/disable

[Daniel Vetter]

On Wed, Mar 18, 2015 at 01:19:33PM +0100, Linus Walleij wrote:
> On Mon, Mar 16, 2015 at 5:42 AM, Shobhit Kumar <shobhit.kumar at intel.com> wrote:
> 
> > The CRC (Crystal Cove) PMIC, controls the panel enable and disable
> > signals for BYT for dsi panels. This is indicated in the VBT fields. Use
> > that to initialize and use GPIO based control for these signals.
> >
> > v2: Use the newer gpiod interface(Alexandre)
> > v3: Remove the redundant checks and unused code (Ville)
> >
> > CC: Samuel Ortiz <sameo at linux.intel.com>
> > Cc: Linus Walleij <linus.walleij at linaro.org>
> > Cc: Alexandre Courbot <gnurou at gmail.com>
> > Cc: Thierry Reding <thierry.reding at gmail.com>
> > Signed-off-by: Shobhit Kumar <shobhit.kumar at intel.com>
> 
> NACK.
> 
> This is not a GPIO but a special-purpose register as can be
> seen from other discussions.
> 
> Use a fixed voltage regulator spun from an MFD cell instead
> of shoehorning this into GPIO.

Hm, somehow my reply here got eaten. I've looked at the regulator stuff
and that doesn't make sense. The problem here is that i915.ko is in
control of the regulator crap like on/off delays and proper ordering with
everything else that must happen to enable/disable the panel without it
falling over. Also i915.ko is the only thing that actually knows which
gpio line to use (there's atm 3 different board designs afaik).

The crystalcove pmic thing here really is just a dumb gpio line that for
the reference design gets routed to the panel (and hence has that as the
usual name). And what we want to do here is get some reasonable way to
route that gpio line control between two totally different drivers.

Also please note that x86 is a lot shittier than arm for this kind of
inter-driver-depencies since we don't even have board files. Hence also
why this series has some patches to expose the board file init stuff to
the pmic driver for setup.

Anyway if you still think gpio is totally the wrong thing then we'll just
roll our own using the component framework. regulator is definitely a even
bigger mismatch at least for our usage. I just figured it would make sense
to reuse existing common infrastructure where it fits.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch