On Wed, Mar 18, 2015 at 2:27 PM, Daniel Vetter <daniel@xxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
