mbox series

[v2,0/2] pinctrl: qcom: Add sm8250 lpass lpi pinctrl support

Message ID 20201105120410.18305-1-srinivas.kandagatla@linaro.org
Headers show
Series pinctrl: qcom: Add sm8250 lpass lpi pinctrl support | expand

Message

Srinivas Kandagatla Nov. 5, 2020, 12:04 p.m. UTC 
This patch adds support for LPASS (Low Power Audio SubSystem)
LPI (Low Power Island) pinctrl on SM8250.

This patch has been tested on support to Qualcomm Robotics RB5 Development
Kit based on QRB5165 Robotics SoC. This board has 2 WSA881X smart speakers
with onboard DMIC connected to internal LPASS codec via WSA  and VA macros
respectively.

Most of the work is derived from downstream Qualcomm kernels.
Credits to various Qualcomm authors from Patrick Lai's team who have
contributed to this code.

Changes since v1:
	- updated bindings to use '-pins$' instead of wild card matching as
	 suggested by Rob.

Srinivas Kandagatla (2):
  pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver
  dt-bindings: pinctrl: qcom: Add sm8250 lpass lpi pinctrl bindings

 .../pinctrl/qcom,lpass-lpi-pinctrl.yaml       | 129 +++
 drivers/pinctrl/qcom/Kconfig                  |   8 +
 drivers/pinctrl/qcom/Makefile                 |   1 +
 drivers/pinctrl/qcom/pinctrl-lpass-lpi.c      | 781 ++++++++++++++++++
 4 files changed, 919 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml
 create mode 100644 drivers/pinctrl/qcom/pinctrl-lpass-lpi.c

Comments

Linus Walleij Nov. 6, 2020, 9:50 a.m. UTC | #1 
Hi Srinivas,

thanks for your patch!

On Thu, Nov 5, 2020 at 1:04 PM Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:

> Add initial pinctrl driver to support pin configuration for
> LPASS (Low Power Audio SubSystem) LPI (Low Power Island) pinctrl
> on SM8250.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>

So this is in essence a completely new pin controller that shares
nothing with the previous Qcom SoC pin control hardware?

I'd still like Bjorn to review it of course, but if you are going to
maintain this driver an entry to the MAINTAINERS file would
be nice.

I'd like some more talk in the commit message about how this
driver is engineered so I point those things out below.

> +config PINCTRL_LPASS_LPI
> +       tristate "Qualcomm Technologies Inc LPASS LPI pin controller driver"
> +       depends on GPIOLIB && OF

These days you can actually just
select GPIOLIB
but no big deal.

> +#include <linux/bitops.h>
> +#include <linux/clk.h>
> +#include <linux/gpio.h>

Do not use this legacy header for new GPIO drivers.
#include <linux/gpio/driver.h>
should work.

> +#define LPI_GPIO_REG_VAL_CTL             0x00
> +#define LPI_GPIO_REG_DIR_CTL             0x04
> +#define LPI_SLEW_REG_VAL_CTL             0x00
> +#define LPI_SLEW_RATE_MAX                0x03
> +#define LPI_SLEW_BITS_SIZE               0x02
> +#define LPI_GPIO_REG_PULL_SHIFT                0x0
> +#define LPI_GPIO_REG_PULL_MASK         GENMASK(1, 0)
> +#define LPI_GPIO_REG_FUNCTION_SHIFT    0x2
> +#define LPI_GPIO_REG_FUNCTION_MASK     GENMASK(5, 2)
> +#define LPI_GPIO_REG_OUT_STRENGTH_SHIFT        0x6
> +#define LPI_GPIO_REG_OUT_STRENGTH_MASK GENMASK(8, 6)
> +#define LPI_GPIO_REG_OE_SHIFT          0x9
> +#define LPI_GPIO_REG_OE_MASK           BIT(9)
> +#define LPI_GPIO_REG_DIR_SHIFT         0x1
> +#define LPI_GPIO_REG_DIR_MASK          0x2
> +#define LPI_GPIO_BIAS_DISABLE          0x0
> +#define LPI_GPIO_PULL_DOWN             0x1
> +#define LPI_GPIO_KEEPER                        0x2
> +#define LPI_GPIO_PULL_UP               0x3

So the way I understand it, the GPIO lines have one register each and then the
functionality of each line is handled by different bits in that register, like
output is driven in bit 9.

This would be nice to have mentioned in the commit message.

> +static const unsigned int gpio0_pins[] = { 0 };
> +static const unsigned int gpio1_pins[] = { 1 };
> +static const unsigned int gpio2_pins[] = { 2 };
> +static const unsigned int gpio3_pins[] = { 3 };
> +static const unsigned int gpio4_pins[] = { 4 };
> +static const unsigned int gpio5_pins[] = { 5 };
> +static const unsigned int gpio6_pins[] = { 6 };
> +static const unsigned int gpio7_pins[] = { 7 };
> +static const unsigned int gpio8_pins[] = { 8 };
> +static const unsigned int gpio9_pins[] = { 9 };
> +static const unsigned int gpio10_pins[] = { 10 };
> +static const unsigned int gpio11_pins[] = { 11 };
> +static const unsigned int gpio12_pins[] = { 12 };
> +static const unsigned int gpio13_pins[] = { 13 };
> +static const char * const swr_tx_clk_groups[] = { "gpio0" };
> +static const char * const swr_tx_data1_groups[] = { "gpio1" };
> +static const char * const swr_tx_data2_groups[] = { "gpio2" };
> +static const char * const swr_rx_clk_groups[] = { "gpio3" };
> +static const char * const swr_rx_data1_groups[] = { "gpio4" };
> +static const char * const swr_tx_data3_groups[] = { "gpio5" };
> +static const char * const dmic1_clk_groups[] = { "gpio6" };
> +static const char * const dmic1_data_groups[] = { "gpio7" };
> +static const char * const dmic2_clk_groups[] = { "gpio8" };
> +static const char * const dmic2_data_groups[] = { "gpio9" };
> +static const char * const i2s2_clk_groups[] = { "gpio10" };
> +static const char * const i2s2_ws_groups[] = { "gpio11" };
> +static const char * const dmic3_clk_groups[] = { "gpio12" };
> +static const char * const dmic3_data_groups[] = { "gpio13" };
> +static const char * const qua_mi2s_sclk_groups[] = { "gpio0" };
> +static const char * const qua_mi2s_ws_groups[] = { "gpio1" };
> +static const char * const qua_mi2s_data0_groups[] = { "gpio2" };
> +static const char * const qua_mi2s_data1_groups[] = { "gpio3" };
> +static const char * const qua_mi2s_data2_groups[] = { "gpio4" };
> +static const char * const swr_rx_data2_groups[] = { "gpio5" };
> +static const char * const i2s1_clk_groups[] = { "gpio6" };
> +static const char * const i2s1_ws_groups[] = { "gpio7" };
> +static const char * const i2s1_data0_groups[] = { "gpio8" };
> +static const char * const i2s1_data1_groups[] = { "gpio9" };
> +static const char * const wsa_swr_clk_groups[] = { "gpio10" };
> +static const char * const wsa_swr_data_groups[] = { "gpio11" };
> +static const char * const i2s2_data0_groups[] = { "gpio12" };
> +static const char * const i2s2_data1_groups[] = { "gpio13" };

The driver appears to follow other qualcomm pin controllers in using
the "one group is one pin" approach. This is idiomatic and should be
mentioned in the commit message.

> +static int sm8250_slew_reg_offsets[] = {
> +               0x0, 0x2, 0x4, 0x8, 0xa,
> +               0xc, 0x0, 0x0, 0x0, 0x0,
> +               0x10, 0x12, 0x0, 0x0,
> +};

Maybe it is obvious to everyone what this array is about, but why so
many zeroes? I think it warrants a comment in the code if that
means for example that some pins do not support slew rate setting.

Overall this is a nice and self-contained driver that uses the abstractions
the right way and very straight-forward, so I think we can merge it
soon.

(Look into Andy's comments as well.)

Yours,
Linus Walleij
Srinivas Kandagatla Nov. 6, 2020, 11:07 a.m. UTC | #2 
Thanks Andy for the review,

On 05/11/2020 12:32, Andy Shevchenko wrote:
> On Thu, Nov 5, 2020 at 2:06 PM Srinivas Kandagatla
> <srinivas.kandagatla@linaro.org> wrote:
>>
>> Add initial pinctrl driver to support pin configuration for
>> LPASS (Low Power Audio SubSystem) LPI (Low Power Island) pinctrl
>> on SM8250.
> 
>> +config PINCTRL_LPASS_LPI
>> +       tristate "Qualcomm Technologies Inc LPASS LPI pin controller driver"
>> +       depends on GPIOLIB && OF
>> +       help
>> +         This is the pinctrl, pinmux, pinconf and gpiolib driver for the
>> +         Qualcomm Technologies Inc LPASS (Low Power Audio SubSystem) LPI
>> +         (Low Power Island) found on the Qualcomm Technologies Inc SoCs.
> 
>> +#include <linux/of_device.h>
>> +#include <linux/of.h>
> 

I agree with most of the style related comments! will fix them in next 
version!

> ...
> 
>> +#ifdef CONFIG_DEBUG_FS
>> +#include <linux/seq_file.h>
> 
>> +#else
>> +#define lpi_gpio_dbg_show NULL
>> +#endif
> 
> Hmm... Doesn't pin control provide a wrapper for this?
> 
I does, but the custom code can provide additional information (such as 
pullup/pulldown configuration) which default one does not provide.

Most of the pinctrl drivers have there own version of this!

> ...
> 
>> +       int ret, npins;
>> +       struct clk *core_vote = NULL;
>> +       struct clk *audio_vote = NULL;
>> +
>> +       struct lpi_pinctrl *pctrl;
>> +       const struct lpi_pinctrl_variant_data *data;
>> +       struct device *dev = &pdev->dev;
>> +       struct resource *res;
> 
> Redundant blank line. Can you keep them in reversed xmas tree order?
> 
> ...
> 
>> +       core_vote = devm_clk_get(&pdev->dev, "core");
>> +       if (IS_ERR(core_vote)) {
> 
>> +               dev_dbg(&pdev->dev, "%s: clk get %s failed %d\n",
>> +                       __func__, "core_vote", ret);
> 
> First of all you missed the deferred probe issue, second, __func__ is
> redundant for *_dbg() calls (okay, when Dynamic Debug is enabled).
> That said why not
>    return dev_err_probe();
> ?
It looks neat, I will use that!
Thanks for this hint, I never knew we had some function like that!


> 
>> +               return PTR_ERR(core_vote);
>> +       }
> 
> ...
> 
>> +       audio_vote = devm_clk_get(&pdev->dev, "audio");
>> +       if (IS_ERR(audio_vote)) {
>> +               dev_dbg(&pdev->dev, "%s: clk get %s failed %d\n",
>> +                       __func__, "audio_vote", ret);
>> +               return PTR_ERR(audio_vote);
> 
> Ditto/
> 
>> +       }
> 
> Why is it not a bulk?

I can try that!
> 
>> +       clk_prepare_enable(pctrl->core_vote);
>> +       clk_prepare_enable(pctrl->audio_vote);
> 
> Either from them may return an error. Also, when you go devm_*() the
> rule of thumb is either all or none. Because here you will have
> ordering issue on ->remove().
> 
>> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +       pctrl->tlmm_base = devm_ioremap_resource(&pdev->dev, res);
> 
> devm_platform_ioremap_resource()

make sense, I remember doing this! somehow I missed it in this version!

rest of the comments looks sensible to me, will make sure that those are 
fixed in next version.


thanks,
srini
Srinivas Kandagatla Nov. 6, 2020, 11:07 a.m. UTC | #3 
Thanks Linus for review!

On 06/11/2020 09:50, Linus Walleij wrote:
> Hi Srinivas,
> 
> thanks for your patch!
> 
> On Thu, Nov 5, 2020 at 1:04 PM Srinivas Kandagatla
> <srinivas.kandagatla@linaro.org> wrote:
> 
>> Add initial pinctrl driver to support pin configuration for
>> LPASS (Low Power Audio SubSystem) LPI (Low Power Island) pinctrl
>> on SM8250.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> 
> So this is in essence a completely new pin controller that shares
> nothing with the previous Qcom SoC pin control hardware?
> 
> I'd still like Bjorn to review it of course, but if you are going to
> maintain this driver an entry to the MAINTAINERS file would
> be nice.
> 
> I'd like some more talk in the commit message about how this
> driver is engineered so I point those things out below.
> 
>> +config PINCTRL_LPASS_LPI
>> +       tristate "Qualcomm Technologies Inc LPASS LPI pin controller driver"
>> +       depends on GPIOLIB && OF
> 
> These days you can actually just
> select GPIOLIB
> but no big deal.
Will take care of this!

> 
>> +#include <linux/bitops.h>
>> +#include <linux/clk.h>
>> +#include <linux/gpio.h>
> 
> Do not use this legacy header for new GPIO drivers.
> #include <linux/gpio/driver.h>
> should work.

Sure!

> 
>> +#define LPI_GPIO_REG_VAL_CTL             0x00
>> +#define LPI_GPIO_REG_DIR_CTL             0x04
>> +#define LPI_SLEW_REG_VAL_CTL             0x00
>> +#define LPI_SLEW_RATE_MAX                0x03
>> +#define LPI_SLEW_BITS_SIZE               0x02
>> +#define LPI_GPIO_REG_PULL_SHIFT                0x0
>> +#define LPI_GPIO_REG_PULL_MASK         GENMASK(1, 0)
>> +#define LPI_GPIO_REG_FUNCTION_SHIFT    0x2
>> +#define LPI_GPIO_REG_FUNCTION_MASK     GENMASK(5, 2)
>> +#define LPI_GPIO_REG_OUT_STRENGTH_SHIFT        0x6
>> +#define LPI_GPIO_REG_OUT_STRENGTH_MASK GENMASK(8, 6)
>> +#define LPI_GPIO_REG_OE_SHIFT          0x9
>> +#define LPI_GPIO_REG_OE_MASK           BIT(9)
>> +#define LPI_GPIO_REG_DIR_SHIFT         0x1
>> +#define LPI_GPIO_REG_DIR_MASK          0x2
>> +#define LPI_GPIO_BIAS_DISABLE          0x0
>> +#define LPI_GPIO_PULL_DOWN             0x1
>> +#define LPI_GPIO_KEEPER                        0x2
>> +#define LPI_GPIO_PULL_UP               0x3
> 
> So the way I understand it, the GPIO lines have one register each and then the
> functionality of each line is handled by different bits in that register, like
> output is driven in bit 9.
> 
Yes exactly!
> This would be nice to have mentioned in the commit message.

I will add more detailed commit message in next version.


> 
>> +static const unsigned int gpio0_pins[] = { 0 };
>> +static const unsigned int gpio1_pins[] = { 1 };
>> +static const unsigned int gpio2_pins[] = { 2 };
>> +static const unsigned int gpio3_pins[] = { 3 };
>> +static const unsigned int gpio4_pins[] = { 4 };
>> +static const unsigned int gpio5_pins[] = { 5 };
>> +static const unsigned int gpio6_pins[] = { 6 };
>> +static const unsigned int gpio7_pins[] = { 7 };
>> +static const unsigned int gpio8_pins[] = { 8 };
>> +static const unsigned int gpio9_pins[] = { 9 };
>> +static const unsigned int gpio10_pins[] = { 10 };
>> +static const unsigned int gpio11_pins[] = { 11 };
>> +static const unsigned int gpio12_pins[] = { 12 };
>> +static const unsigned int gpio13_pins[] = { 13 };
>> +static const char * const swr_tx_clk_groups[] = { "gpio0" };
>> +static const char * const swr_tx_data1_groups[] = { "gpio1" };
>> +static const char * const swr_tx_data2_groups[] = { "gpio2" };
>> +static const char * const swr_rx_clk_groups[] = { "gpio3" };
>> +static const char * const swr_rx_data1_groups[] = { "gpio4" };
>> +static const char * const swr_tx_data3_groups[] = { "gpio5" };
>> +static const char * const dmic1_clk_groups[] = { "gpio6" };
>> +static const char * const dmic1_data_groups[] = { "gpio7" };
>> +static const char * const dmic2_clk_groups[] = { "gpio8" };
>> +static const char * const dmic2_data_groups[] = { "gpio9" };
>> +static const char * const i2s2_clk_groups[] = { "gpio10" };
>> +static const char * const i2s2_ws_groups[] = { "gpio11" };
>> +static const char * const dmic3_clk_groups[] = { "gpio12" };
>> +static const char * const dmic3_data_groups[] = { "gpio13" };
>> +static const char * const qua_mi2s_sclk_groups[] = { "gpio0" };
>> +static const char * const qua_mi2s_ws_groups[] = { "gpio1" };
>> +static const char * const qua_mi2s_data0_groups[] = { "gpio2" };
>> +static const char * const qua_mi2s_data1_groups[] = { "gpio3" };
>> +static const char * const qua_mi2s_data2_groups[] = { "gpio4" };
>> +static const char * const swr_rx_data2_groups[] = { "gpio5" };
>> +static const char * const i2s1_clk_groups[] = { "gpio6" };
>> +static const char * const i2s1_ws_groups[] = { "gpio7" };
>> +static const char * const i2s1_data0_groups[] = { "gpio8" };
>> +static const char * const i2s1_data1_groups[] = { "gpio9" };
>> +static const char * const wsa_swr_clk_groups[] = { "gpio10" };
>> +static const char * const wsa_swr_data_groups[] = { "gpio11" };
>> +static const char * const i2s2_data0_groups[] = { "gpio12" };
>> +static const char * const i2s2_data1_groups[] = { "gpio13" };
> 
> The driver appears to follow other qualcomm pin controllers in using
> the "one group is one pin" approach. This is idiomatic and should be
> mentioned in the commit message.

Sure I will do that,

Some more detail of wiring of this additional pin-controller IP:

This IP is an additional pinctrl block on top the existing SoC TLMM 
pin-controller (Audio) pins.

The hw setup looks like:

TLMM GPIO[146 - 159] --> LPASS LPI GPIO [0 - 13]


However SoC TLMM pin-controller can only be touched for use of those 
pins in GPIO mode and non gpio mode is completely handled by the LPASS 
LPI pinctrl block. Apart from this slew rate is also available in this 
block for certain pins which are connected to SLIMbus or SoundWire Bus.

Normally we would not expect these pins to be touched by SoC TLMM 
pin-controller as these pins are used for audio usecase and the control 
is always with LPASS LPI controller. There are additional bits to 
configure/enforce this in SoC TLMM block!

> 
>> +static int sm8250_slew_reg_offsets[] = {
>> +               0x0, 0x2, 0x4, 0x8, 0xa,
>> +               0xc, 0x0, 0x0, 0x0, 0x0,
>> +               0x10, 0x12, 0x0, 0x0,
>> +};
> 
> Maybe it is obvious to everyone what this array is about, but why so
> many zeroes? I think it warrants a comment in the code if that
> means for example that some pins do not support slew rate setting.

Only pins that are connected to SLIMbus or SoundWire have slew rate 
settings available, rest of the pins which do not have this are marked 
as 0x0. I can add some comment in here to
> 
> Overall this is a nice and self-contained driver that uses the abstractions
> the right way and very straight-forward, so I think we can merge it
> soon.
> 
> (Look into Andy's comments as well.)

Thanks, I will address Andy's comments as well in next version!

--srini

> 
> Yours,
> Linus Walleij
>