[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAE-0n527T71LPe5R+S+YzEqiid2-QrFdvS2T7MWrakTccyG45w@mail.gmail.com>
Date: Wed, 15 Dec 2021 02:28:54 +0100
From: Stephen Boyd <swboyd@...omium.org>
To: Linus Walleij <linus.walleij@...aro.org>,
Srinivasa Rao Mandadapu <quic_srivasam@...cinc.com>,
agross@...nel.org, alsa-devel@...a-project.org,
bgoswami@...eaurora.org, bjorn.andersson@...aro.org,
broonie@...nel.org, devicetree@...r.kernel.org,
judyhsiao@...omium.org, lgirdwood@...il.com,
linux-arm-msm@...r.kernel.org, linux-gpio@...r.kernel.org,
linux-kernel@...r.kernel.org, perex@...ex.cz, plai@...eaurora.org,
robh+dt@...nel.org, rohitkr@...eaurora.org,
srinivas.kandagatla@...aro.org, tiwai@...e.com
Subject: Re: [PATCH v5 0/5] Add pin control support for lpass sc7280
Quoting Srinivasa Rao Mandadapu (2021-12-07 07:35:34)
> This patch series is to split lpass variant common pin control
> functions and SoC specific functions and to add lpass sc7280 pincontrol support.
> It also Adds dt-bindings for lpass sc7280 lpass lpi pincontrol.
What ensures that the LPI pins are being muxed out on the pads of the
SoC? There's the eGPIO support in the tlmm driver, which seems to let us
override the LPI pins and mux them away from this pinctrl device to the
tlmm pinctrl device. Should this driver be requesting gpios from tlmm
and making sure they're not muxed away to tlmm so we don't have
conflicts?
Powered by blists - more mailing lists