On Fri 23 Jun 05:33 PDT 2017, Linus Walleij wrote:

On Thu, Jun 22, 2017 at 10:54 PM, Timur Tabi [off-list ref] wrote:

quoted

On Qualcomm Technologies QDF2xxx platforms, only a subset of the GPIOs
are actually available to the HLOS.  The others are blocked by the XPU,
and any attempt to access them will cause an XPU violation that halts
the system.

That's a bummer. Looking for Bj?rn's review on this patch.

The TLMM block on this platform has N gpios, regardless of the XPU
configuration. The ACPI table provides the kernel with a list of
available "logical" GPIOs based on some system specification (or
reference design perhaps?).

I have not seen the Qualcomm server platforms, but I imagine that
customers can alter this list.


I think the numbering of the GPIOs should be that of the TLMM and the
"logical" names should be populated from ACPI by using gpio_chip->names.

The question left is how to represent the XPU locked gpios - a problem
we do share with in the mobile TLMM drivers.


It seems that if we extend the msm_pingroup with a flag to carry the XPU
lock information and then implement pinmux_ops->request() and deny any
requests on the locked pins, we should cover all[*] the normal GPIO code
paths.

[*] Except the reported case of gpiochip_add_data() looping over all
pins and calling get_direction() without first requesting the pin.

@Linus, do you see any flaws in this scheme?


PS. gpiochip_generic_request() ends up calling pinmux_ops->request()

Regards,
Bjorn