On 06/28/2017 02:12 PM, Bjorn Andersson wrote:
On Fri 23 Jun 05:33 PDT 2017, Linus Walleij wrote:
On Thu, Jun 22, 2017 at 10:54 PM, Timur Tabi <timur@xxxxxxxxxxxxxx> wrote:
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?).
It's the list of available physical GPIOs. Here's the table:
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 pins are configured
// as GPIOs (function 0) and wired externally
// to a header on the board, so it's safe to
// expose them to the HLOS driver.
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}}
}
})
I have not seen the Qualcomm server platforms, but I imagine that
customers can alter this list.
Not easily, as it requires recompiling the ACPI tables. I also don't
know how much control customers have over the XPU settings. The XPU is
supposed to block access to any GPIOs that have been muxed to other
purposes, but it's a hand-crafted list that could be anything.
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.
Is that not what my driver is doing? Or do I misunderstand you?
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.
Instead of a flag, I was thinking if npins == 0, then this GPIO should
be disabled.
[*] Except the reported case of gpiochip_add_data() looping over all
pins and calling get_direction() without first requesting the pin.
This is what triggered the problem in the first place. Every time the
kernel boots, it's queries all of the GPIOs. Ironically, I created that
feature because on server platforms, that was the only way to know the
current setting.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
