[Intel-gfx] [PATCH 1/2] gpio/crystalcove: Export Panel and backlight en/disable signals as GPIO

[Linus Walleij]

On Wed, Mar 18, 2015 at 2:27 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Wed, Mar 18, 2015 at 12:50:51PM +0100, Linus Walleij wrote:

>> This is not a GPIO, this is a special purpose thing and IMO
>> it should be modeled directly as a regulator.
>
> The idea behind reusing gpio was that we can reuse the dynamic lookup
> stuff so that i915 can find the gpio.

(Fixed) regulators also have dynamic lookups so they provide the
exact same mechanism of associating themselves to devices.

> And it is a gpio (there's lots more
> on that chip),

Well the other GPIO registers seem to have 8 GPIOs each, so one
register control 8 random lines.

In this case they obviously put a single bit to control a line out
of the PMIC. The register was intended to that purpose only,
the register is named PANEL_EN/DISABLE in the refman (right?)
and I bet a million to one that the pin on the PMIC and the rail
connected to it is also named PANEL_EN/DISABLE or similar.

So the hardware engineers had a special purpose in mind for
this. Not general purpose (GPIO).

> it's just that intel tends to hand you recommended board
> layouts. And there's different ones so only really i915.ko can tell you if
> it's indeed used to control the panel or not (after consulting a bunch of
> vbios tables).

What about the schematic or PMIC pinout. I suspect it
tells you a lot about the intended usage by calling that pin
PANEL_EN or so.

I'm not saying other usecases are impossible, all Rube Goldberg
machine variants are possible, but are other use cases really
realistic amongst implementers?

> Regulator seems way too overkill for this, especially since it tends to be
> a lie on systems where the panel is not connected to that gpio line. And
> afaiui the point of the regulator subsystem is that you just ask for the
> regulator for your IP block and then magically get handed the right bit
> (or a dummy one). This is very much not the case, hw descriptions on x86
> in this area are a kludge worse than board tables since we can't even fix
> up what the bios hands us anywhere.

Depends on the intended use case I would say.

Regulator isn't overkill if it fits the use case better. And I think you have
a power-on delay, typically so that the panel driver cannot immediately
start transmitting data to the panel after driving this line high. Probably
the panel needs to settle first.

This is referred to as a power-on-delay and the regulator framework
can handle it for you.

I strongly suspect that you would be planting some delay code in the
site enabling the GPIO instead maybe already now or when later
running into this while enabling suspend/resume or similar power
saving mechanisms. That is basically reimplementing some helpful
stuff from the regulator framework.

> So for me plan B is to just handroll our own thing using the component
> framework when reusing gpios isn't acceptable.

Let's just figure out if GPIO is the best fit first, or if you actually could
be helped by fixed regulators.

Yours,
Linus Walleij