linux-stable.git/drivers/pinctrl, branch v3.16.57

pinctrl: Really force states during suspend/resume

2018-06-16T21:21:45+00:00

commit 981ed1bfbc6c4660b2ddaa8392893e20a6255048 upstream.

In case a platform only defaults a "default" set of pins, but not a
"sleep" set of pins, and this particular platform suspends and resumes
in a way that the pin states are not preserved by the hardware, when we
resume, we would call pinctrl_single_resume() -> pinctrl_force_default()
-> pinctrl_select_state() and the first thing we do is check that the
pins state is the same as before, and do nothing.

In order to fix this, decouple the actual state change from
pinctrl_select_state() and move it pinctrl_commit_state(), while keeping
the p->state == state check in pinctrl_select_state() not to change the
caller assumptions. pinctrl_force_sleep() and pinctrl_force_default()
are updated to bypass the state check by calling pinctrl_commit_state().

[Linus Walleij]
The forced pin control states are currently only used in some pin
controller drivers that grab their own reference to their own pins.
This is equal to the pin control hogs: pins taken by pin control
devices since there are no corresponding device in the Linux device
hierarchy, such as memory controller lines or unused GPIO lines,
or GPIO lines that are used orthogonally from the GPIO subsystem
but pincontrol-wise managed as hogs (non-strict mode, allowing
simultaneous use by GPIO and pin control). For this case forcing
the state from the drivers' suspend()/resume() callbacks makes
sense and should semantically match the name of the function.

Fixes: 6e5e959dde0d ("pinctrl: API changes to support multiple states per device")
Signed-off-by: Florian Fainelli 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Linus Walleij 
Signed-off-by: Ben Hutchings

pinctrl: sunxi: add a missing function of A10/A20 pinctrl driver

2017-11-11T13:33:11+00:00

commit d81ece747d8727bb8b1cfc9a20dbe62f09a4e35a upstream.

The PH16 pin has a function with mux id 0x5, which is the DET pin of the
"sim" (smart card reader) IP block.

This function is missing in old versions of A10/A20 SoCs' datasheets and
user manuals, so it's also missing in the old drivers. The newest A10
Datasheet V1.70 and A20 Datasheet V1.41 contain this pin function, and
it's discovered during implementing R40 pinctrl driver.

Add it to the driver. As we now merged A20 pinctrl driver to the A10
one, we need to only fix the A10 driver now.

Fixes: f2821b1ca3a2 ("pinctrl: sunxi: Move Allwinner A10 pinctrl
driver to a driver of its own")

Signed-off-by: Icenowy Zheng 
Reviewed-by: Chen-Yu Tsai 
Signed-off-by: Linus Walleij 
Signed-off-by: Ben Hutchings

pinctrl: imx: fix debug message for SHARE_MUX_CONF_REG case

2017-10-12T14:27:43+00:00

commit 66b54e3a5a64925d9819eae86b8f36e90e60037f upstream.

The original implemented debug message does not work for
SHARE_MUX_CONF_REG case. This patch fixes it.

Fixes: bf5a530971af ("pinctrl: imx: add VF610 support to imx pinctrl framework")
Signed-off-by: Dong Aisheng 
Acked-by: Shawn Guo 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

pinctrl: mxs: atomically switch mux and drive strength config

2017-09-15T17:29:49+00:00

commit da6c2addf66d7ff7d0b090d6267d4292f951e4e6 upstream.

To set the mux mode of a pin two bits must be set. Up to now this is
implemented using the following idiom:

	writel(mask, reg + CLR);
	writel(value, reg + SET);

. This however results in the mux mode being 0 between the two writes.

On my machine there is an IC's reset pin connected to LCD_D20. The
bootloader configures this pin as GPIO output-high (i.e. not holding the
IC in reset). When Linux reconfigures the pin to GPIO the short time
LCD_D20 is muxed as LCD_D20 instead of GPIO_1_20 is enough to confuse
the connected IC.

The same problem is present for the pin's drive strength setting which is
reset to low drive strength before using the right value.

So instead of relying on the hardware to modify the register setting
using two writes implement the bit toggling using read-modify-write.

Fixes: 17723111e64f ("pinctrl: add pinctrl-mxs support")
Signed-off-by: Uwe Kleine-König 
Acked-by: Shawn Guo 
Signed-off-by: Linus Walleij 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings

pinctrl: sh-pfc: r8a7791: Fix IPSR comment typos

2017-08-26T01:14:27+00:00

commit 0cbdc11482d72ad164e33ef7cc57b01e8b61e40d upstream.

The IPSR field names in the comments have been fat-fingered in a couple
places --  fix those silly typos...

Fixes: 508845196238 ("pinctrl: sh-pfc: r8a7791 PFC support")
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Ben Hutchings

pinctrl: sh-pfc: r8a7791: Fix SCIF2 pinmux data

2017-08-26T01:14:27+00:00

commit 58439280f84e6b39fd7d61f25ab30489c1aaf0a9 upstream.

PINMUX_IPSR_MSEL() macro invocation for the TX2 signal has apparently wrong
1st argument -- most probably a result of cut&paste programming...

Fixes: 508845196238 ("pinctrl: sh-pfc: r8a7791 PFC support")
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Geert Uytterhoeven 
[bwh: Backported to 3.16:
 - Use PINMUX_IPSR_MODSEL_DATA() instead of PINMUX_IPSR_MSEL()
 - Adjust context]
Signed-off-by: Ben Hutchings

pinctrl: sh-pfc: r8a7791: Add missing DVC_MUTE signal

2017-08-26T01:14:27+00:00

commit 3908632fb829d73317c64c3d04f584b49f62e4ae upstream.

The R8A7791 PFC driver  was apparently based on the preliminary revisions
of  the user's  manual, which  omitted the DVC_MUTE signal  altogether in
the PFC section. The modern manual has the signal described,  so just add
the necassary data to the driver...

Fixes: 508845196238 ("pinctrl: sh-pfc: r8a7791 PFC support")
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Geert Uytterhoeven 
[bwh: Backported to 3.16:
 - Use PINMUX_IPSR_DATA() instead of PINMUX_IPSR_GPSR()
 - Adjust context]
Signed-off-by: Ben Hutchings

pinctrl: sh-pfc: r8a7791: Add missing HSCIF1 pinmux data

2017-08-26T01:14:27+00:00

commit da7a692fbbab07f4e9798b5b52798f6e3256dd8f upstream.

The R8A7791 PFC driver  was apparently based on the preliminary revisions
of  the  user's manual, which  omitted the HSCIF1 group E signals in  the
IPSR4 register description. This would cause HSCIF1's probe  to fail with
the messages like below:

sh-pfc e6060000.pfc: cannot locate data/mark enum_id for mark 1989
sh-sci e62c8000.serial: Error applying setting, reverse things back
sh-sci: probe of e62c8000.serial failed with error -22

Add the neceassary PINMUX_IPSR_MSEL() invocations for the HSCK1_E,
HCTS1#_E, and HRTS1#_E signals...

Fixes: 508845196238 ("pinctrl: sh-pfc: r8a7791 PFC support")
Signed-off-by: Sergei Shtylyov 
Signed-off-by: Geert Uytterhoeven 
[bwh: Backported to 3.16:
 - Use PINMUX_IPSR_MODSEL_DATA() instead of PINMUX_IPSR_MSEL()
 - Adjust context]
Signed-off-by: Ben Hutchings

pinctrl: sh-pfc: Update info pointer after SoC-specific init

2017-08-26T01:14:24+00:00

commit 3091ae775fae17084013021d01513bc1ad274e6a upstream.

Update the sh_pfc_soc_info pointer after calling the SoC-specific
initialization function, as it may have been updated to e.g. handle
different SoC revisions.  This makes sure the correct subdriver name is
printed later.

Fixes: 0c151062f32c9db8 ("sh-pfc: Add support for SoC-specific initialization")
Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Ben Hutchings

pinctrl: single: Fix missing flush of posted write for a wakeirq

2016-08-22T21:38:17+00:00

commit 0ac3c0a4025f41748a083bdd4970cb3ede802b15 upstream.

With many repeated suspend resume cycles, the pin specific wakeirq
may not always work on omaps. This is because the write to enable the
pin interrupt may not have reached the device over the interconnect
before suspend happens.

Let's fix the issue with a flush of posted write with a readback.

Reported-by: Nishanth Menon 
Signed-off-by: Tony Lindgren 
Signed-off-by: Linus Walleij 
Signed-off-by: Ben Hutchings