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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx> > > Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> > > Cc: Alexandre Courbot <gnurou@xxxxxxxxx> > > Cc: Thierry Reding <thierry.reding@xxxxxxxxx> > > Signed-off-by: Shobhit Kumar <shobhit.kumar@xxxxxxxxx> > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
