linux-stable.git/drivers/pinctrl/qcom, branch v5.12.2

pinctrl: qcom: fix unintentional string concatenation

2021-03-25T09:45:11+00:00

clang is clearly correct to point out a typo in a silly
array of strings:

drivers/pinctrl/qcom/pinctrl-sdx55.c:426:61: error: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Werror,-Wstring-concatenation]
        "gpio14", "gpio15", "gpio16", "gpio17", "gpio18", "gpio19" "gpio20", "gpio21", "gpio22",
                                                                   ^
Add the missing comma that must have accidentally been removed.

Fixes: ac43c44a7a37 ("pinctrl: qcom: Add SDX55 pincontrol driver")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Bjorn Andersson 
Reviewed-by: Nathan Chancellor 
Link: https://lore.kernel.org/r/20210323131728.2702789-1-arnd@kernel.org
Signed-off-by: Linus Walleij

pinctrl: qcom: sc7280: Fix SDC1_RCLK configurations

2021-03-10T23:53:00+00:00

Fix SDC1_RCLK configurations which are in a different register so fix the
offset from 0xb3000 to 0xb3004.

Fixes: ecb454594c43: ("pinctrl: qcom: Add sc7280 pinctrl driver")
Reported-by: Veerabhadrarao Badiganti 
Signed-off-by: Rajendra Nayak 
Acked-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/1614662511-26519-2-git-send-email-rnayak@codeaurora.org
Signed-off-by: Linus Walleij

pinctrl: qcom: sc7280: Fix SDC_QDSD_PINGROUP and UFS_RESET offsets

2021-03-10T23:52:55+00:00

The offsets for SDC_QDSD_PINGROUP and UFS_RESET were off by 0x100000
due to an issue in the scripts generating the data.

Fixes: ecb454594c43: ("pinctrl: qcom: Add sc7280 pinctrl driver")
Reported-by: Veerabhadrarao Badiganti 
Signed-off-by: Rajendra Nayak 
Reviewed-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/1614662511-26519-1-git-send-email-rnayak@codeaurora.org
Signed-off-by: Linus Walleij

pinctrl: qcom: lpass lpi: use default pullup/strength values

2021-03-10T23:13:07+00:00

If these fields are not set in dts, the driver will use these variables
uninitialized to set the fields. Not only will it set garbage values for
these fields, but it can overflow into other fields and break those.

In the current sm8250 dts, the dmic01 entries do not have a pullup setting,
and might not work without this change.

Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Fixes: 6e261d1090d6 ("pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver")
Signed-off-by: Jonathan Marek 
Reviewed-by: Bjorn Andersson 
Reviewed-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20210304194816.3843-1-jonathan@marek.ca
Signed-off-by: Linus Walleij

Merge tag 'pinctrl-v5.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl

2021-02-23T02:39:11+00:00

Pull pin control updates from Linus Walleij:
 "This is the bulk of pin control changes for the v5.12 kernel.

  This time a calm set with no core changes.

  New drivers/subdrivers:

   - Renesas R8A7790A0 pin controller.

   - Allwinner H616 and H616-R pin controllers.

   - Qualcomm SM8350 and SC8180x pin controllers.

  Improvements:

   - Redo the DT bindings for Ralink RT2880.

   - A common Qualcomm TLMM DT binding in YAML.

   - Delete the unused drivers for U300, COH901, Sirf Atlas, and ZTE ZX"

* tag 'pinctrl-v5.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (71 commits)
  pinctrl: mediatek: Fix trigger type setting follow for unexpected interrupt
  dt-bindings: pinctrl: Group tuples in pin control properties
  pinctrl: nuvoton: npcm7xx: Fix alignment of table header comment
  pinctrl: at91-pio4: fix "Prefer 'unsigned int' to bare use of 'unsigned'"
  pinctrl: at91-pio4: add support for slew-rate
  dt-bindings: pinctrl: at91-pio4: add slew-rate
  pinctrl: actions: Add depends on || COMPILE_TEST
  pinctrl: single: set function name when adding function
  pinctrl: qcom: Add sc8180x TLMM driver
  dt-bindings: pinctrl: qcom: Add sc8180x binding
  dt-bindings: pinctrl: qcom: Define common TLMM binding
  pinctrl: qcom: Add SM8350 pinctrl driver
  dt-bindings: pinctrl: qcom: Add SM8350 pinctrl bindings
  pinctrl: samsung: use raw_spinlock for s3c64xx
  dt-bindings: mediatek: mt8192: Fix dt_binding_check warning
  pinctrl: qcom: spmi-mpp: Add PM8019 compatible
  pinctrl: pinmux: add function selector to pinmux-functions
  pinctrl: samsung: use raw_spinlock for locking
  pinctrl: clarify #pinctrl-cells for pinctrl-single,pins
  pinctrl: actions: Add the platform dependency to drivers
  ...

pinctrl: qcom: Add sc8180x TLMM driver

2021-02-12T07:52:31+00:00

Add pinctrl driver for the sc8180x TLMM block.

A noteworthy difference from previous TLMM blocks is that the registers
for GPIO 177 through 189 are for some reason offset from the typical
layout. Other than that the driver is same old...

Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20210126042650.1725176-3-bjorn.andersson@linaro.org
Signed-off-by: Linus Walleij

pinctrl: qcom: Add SM8350 pinctrl driver

2021-02-12T07:50:14+00:00

This adds pincontrol driver for tlmm block found in SM8350 SoC

This patch is based on initial code downstream by Raghavendra.

Reviewed-by: Bjorn Andersson 
Signed-off-by: Vinod Koul 
Link: https://lore.kernel.org/r/20210205140132.274242-3-vkoul@kernel.org
Signed-off-by: Linus Walleij

pinctrl: qcom: spmi-mpp: Add PM8019 compatible

2021-01-26T14:52:51+00:00

PM8019 provides 6 MPPs. Add a compatible to support them.

Signed-off-by: Konrad Dybcio 
Acked-by: Rob Herring 
Link: https://lore.kernel.org/r/20210115171115.123155-2-konrad.dybcio@somainline.org
Signed-off-by: Linus Walleij

pinctrl: qcom: Don't clear pending interrupts when enabling

2021-01-18T15:07:08+00:00

In Linux, if a driver does disable_irq() and later does enable_irq()
on its interrupt, I believe it's expecting these properties:
* If an interrupt was pending when the driver disabled then it will
still be pending after the driver re-enables.
* If an edge-triggered interrupt comes in while an interrupt is
disabled it should assert when the interrupt is re-enabled.

If you think that the above sounds a lot like the disable_irq() and
enable_irq() are supposed to be masking/unmasking the interrupt
instead of disabling/enabling it then you've made an astute
observation. Specifically when talking about interrupts, "mask"
usually means to stop posting interrupts but keep tracking them and
"disable" means to fully shut off interrupt detection. It's
unfortunate that this is so confusing, but presumably this is all the
way it is for historical reasons.

Perhaps more confusing than the above is that, even though clients of
IRQs themselves don't have a way to request mask/unmask
vs. disable/enable calls, IRQ chips themselves can implement both.
...and yet more confusing is that if an IRQ chip implements
disable/enable then they will be called when a client driver calls
disable_irq() / enable_irq().

It does feel like some of the above could be cleared up. However,
without any other core interrupt changes it should be clear that when
an IRQ chip gets a request to "disable" an IRQ that it has to treat it
like a mask of that IRQ.

In any case, after that long interlude you can see that the "unmask
and clear" can break things. Maulik tried to fix it so that we no
longer did "unmask and clear" in commit 71266d9d3936 ("pinctrl: qcom:
Move clearing pending IRQ to .irq_request_resources callback"), but it
only handled the PDC case and it had problems (it caused
sc7180-trogdor devices to fail to suspend). Let's fix.

>From my understanding the source of the phantom interrupt in the
were these two things:
1. One that could have been introduced in msm_gpio_irq_set_type()
(only for the non-PDC case).
2. Edges could have been detected when a GPIO was muxed away.

Fixing case #1 is easy. We can just add a clear in
msm_gpio_irq_set_type().

Fixing case #2 is harder. Let's use a concrete example. In
sc7180-trogdor.dtsi we configure the uart3 to have two pinctrl states,
sleep and default, and mux between the two during runtime PM and
system suspend (see geni_se_resources_{on,off}() for more
details). The difference between the sleep and default state is that
the RX pin is muxed to a GPIO during sleep and muxed to the UART
otherwise.

As per Qualcomm, when we mux the pin over to the UART function the PDC
(or the non-PDC interrupt detection logic) is still watching it /
latching edges. These edges don't cause interrupts because the
current code masks the interrupt unless we're entering suspend.
However, as soon as we enter suspend we unmask the interrupt and it's
counted as a wakeup.

Let's deal with the problem like this:
* When we mux away, we'll mask our interrupt. This isn't necessary in
the above case since the client already masked us, but it's a good
idea in general.
* When we mux back will clear any interrupts and unmask.

Fixes: 4b7618fdc7e6 ("pinctrl: qcom: Add irq_enable callback for msm gpio")
Fixes: 71266d9d3936 ("pinctrl: qcom: Move clearing pending IRQ to .irq_request_resources callback")
Signed-off-by: Douglas Anderson
Reviewed-by: Maulik Shah
Tested-by: Maulik Shah
Reviewed-by: Stephen Boyd
Link: https://lore.kernel.org/r/20210114191601.v7.4.I7cf3019783720feb57b958c95c2b684940264cd1@changeid
Signed-off-by: Linus Walleij

pinctrl: qcom: Properly clear "intr_ack_high" interrupts when unmasking

2021-01-18T15:07:08+00:00

In commit 4b7618fdc7e6 ("pinctrl: qcom: Add irq_enable callback for
msm gpio") we tried to Ack interrupts during unmask.  However, that
patch forgot to check "intr_ack_high" so, presumably, it only worked
for a certain subset of SoCs.

Let's add a small accessor so we don't need to open-code the logic in
both places.

This was found by code inspection.  I don't have any access to the
hardware in question nor software that needs the Ack during unmask.

Fixes: 4b7618fdc7e6 ("pinctrl: qcom: Add irq_enable callback for msm gpio")
Signed-off-by: Douglas Anderson 
Reviewed-by: Maulik Shah 
Tested-by: Maulik Shah 
Reviewed-by: Stephen Boyd 
Reviewed-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20210114191601.v7.3.I32d0f4e174d45363b49ab611a13c3da8f1e87d0f@changeid
Signed-off-by: Linus Walleij