On 10/30/2021 12:35 AM, Stephen Boyd wrote:
Quoting Rajendra Nayak (2021-10-29 03:19:04)
On 10/29/2021 12:24 PM, Stephen Boyd wrote:
Quoting Rajendra Nayak (2021-10-26 05:07:35)
From: Prasad Sodagudi <psodagud@xxxxxxxxxxxxxx>
egpio is a scheme which allows special power Island Domain IOs
(LPASS,SSC) to be reused as regular chip GPIOs by muxing regular
TLMM functions with Island Domain functions.
With this scheme, an IO can be controlled both by the cpu running
linux and the Island processor. This provides great flexibility to
re-purpose the Island IOs for regular TLMM usecases.
2 new bits are added to ctl_reg, egpio_present is a read only bit
which shows if egpio feature is available or not on a given gpio.
egpio_enable is the read/write bit and only effective if egpio_present
is 1. Once its set, the Island IO is controlled from Chip TLMM.
egpio_enable when set to 0 means the GPIO is used as Island Domain IO.
To support this we add a new function 'egpio' which can be used to
set the egpio_enable to 0, for any other TLMM controlled functions
we set the egpio_enable to 1.
Signed-off-by: Prasad Sodagudi <psodagud@xxxxxxxxxxxxxx>
Signed-off-by: Rajendra Nayak <rnayak@xxxxxxxxxxxxxx>
---
Does this supersede adding support for lpass pinctrl in this series[1]?
No, the driver in [1] actually manages the LPASS TLMM instance, while this patch
makes it possible for the 'same' pins to be managed by the SoC TLMM instance.
On sc7280 SoC for instance GPIO144-158 maps to LPI-GPIO-0-14, and GPIO159-174
maps to SSC-GPIO-0-15.
How do we make sure that the LPASS pins are actually muxed out of the
SoC and not blocked by eGPIO in this driver muxing out the pin as a
gpio? Do they avoid conflicting with each other somehow?
No, currently they don't. The default value of egpio_enable is 0, so
if SoC TLMM grabs it first and sets it to 1 and then the LPASS TLMM tries
to grab it, perhaps it can find out and throw and error, though I don;t
think it does that today.
I am not sure how this can be caught when its the other way round (LPASS grabs it first)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation