Re: Sparse GPIO maps with pinctrl-msm.c?

[Bjorn Andersson <bjorn.andersson@linaro.org>]

On Fri 16 Jun 09:26 PDT 2017, Timur Tabi wrote:

> On 6/16/17 11:21 AM, Andy Gross wrote:
> 
> > > 1) Approved by the XPU
> > 
> > How do you know what this is?  And this changes based on the TZ load.
> 
> An ACPI property in the TLMM node that lists the approved GPIOs by number.
> It currently looks like this:
> 
> Name (_DSD, Package ()
> {
> 	ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> 	Package ()
> 	{
> 		// Expose only the qdss_tracedata pins as GPIOs,
> 		// numbered sequentially, so that "gpio X" maps
> 		// to qdss_tracedata[X].  These can be used as
> 		// generic GPIOs.

But what does this actually mean?

I assume that on this platform the qdss_tracedata is an alternative
pinmux function (configured by someone else). Which normally means that
the pins are routed to some internal hardware block.

Or are you just running these in gpio-function and then have some
software to decode the data? Where is this piece of software?

> 		Package (2) {"gpios", Package ()
> 			{116, 117, 118, 119, 120, 121, 122, 123,
> 			 124, 125, 126, 127, 128, 129, 130, 131,
> 			 80, 81, 82, 83, 84, 85, 86, 87, 88, 89,
> 			 90, 50, 36, 37, 38, 39}}

Does these pins make up some sort of communication bus? Or is it 32
individual states? Does it really make sense to expose these as 32
"random" GPIOs - which on some platforms will be sequential in your
made-up GPIO controller and on others be scattered.

> 	}
> })
> 
> I'm not crazy about it, but it's a compromise that allows some GPIOs to be
> exposed without a lot of coding.  One idea we're debating is forgetting
> about pinctrl-msm altogether and rewrite the driver from scratch as a pure
> GPIO driver.  I'm hoping to avoid having to do that.
> 

I think that it would be nice to come up with a solution that works for
the other users of pinctrl-msm as well.

Regards,
Bjorn