Re: [PATCH v1 2/4] pinctrl: geminilake: Add vGPIO pins

[Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>]

On Tue, Oct 16, 2018 at 10:12:22AM +0200, Linus Walleij wrote:
> On Tue, Oct 16, 2018 at 9:28 AM Mika Westerberg
> <mika.westerberg@xxxxxxxxxxxxxxx> wrote:
> > On Tue, Oct 16, 2018 at 09:25:02AM +0200, Linus Walleij wrote:
> > > On Thu, Oct 4, 2018 at 5:33 PM Andy Shevchenko
> > > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > >
> > > > Intel Gemini Lake provides vGPIO pins which are now missed from the list.
> > > > Add them here.
> > > >
> > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
> > >
> > > What does the "v" in "vGPIO" stand for?
> >
> > It stands for "virtual".
> (...)
> > These pins are not exposed externally (e.g there is no physical pin for
> > thse), just internal so there is no way to connect anything to them.
> 
> Ah but it is really pin control, because what you say is that on
> Gemini Lake there are several chips inside the package, and this
> pertains to pads bonded directly over to another chip, right?
> 
> Or even a line of polysilicon over to another part of the same chip
> die, but I doubt that since BT and GPS would give interesting
> radio interference with the CPU parts (no idea how smart your
> silicon people are though, I think they are pretty smart so who
> knows!)

I don't know how it is implemented inside the chip but I think probably
something like the above.

> In either case, none of that is "virtual" it's pretty physical. The
> electrons still pass through a medium. Virtual is a bad name
> for this.

Well, I did not invent the name ;-)

> I guess I would still add them if they had some interesting electronic
> properties that you have to change though, like setting drive strength,
> that BlueTooth of GPS needs.

Yes, in that case they would be needed but there is currently no
evidence that it is needed in Gemini Lake.

> I would assume that they are set up by either hardware defaults
> or ROM/BIOS, but you know: someone writing the ROM/BIOS
> will get it wrong and it needs to be reconfigured. Or reconfigured
> just to save power for some usecase. This always happens in
> my experience, I would not be surprised if some Intel customer
> has code for doing exactly that in their vendor tree (because I
> have seen so much of that stuff before).
> 
> But until proven wrong, I can agree to keep this out of tree.

OK.

> I just wanted to give Andy some credit for exposing this, in
> most cases it actually makes sense to just expose all buttons.

IMHO if there is a real need to expose those pins (say some pin is
misconfigured by the BIOS and need to be worked around in the kernel) we
should expose those. As of now there are no bug reports regarding this
so I think we should keep them unexposed.