openbmc / linux

OpenBMC Linux kernel source tree

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Pinmux regression in v6.1

shenki opened this issue · comments

The commit cf517fe ("pinctrl: aspeed: Force to disable the function's signal") exposed a problem with fetching the regmap for reading the GFX register.

The Romulus machine the device tree contains a gpio hog for GPIO S7. With the patch applied:

  Muxing pin 151 for GPIO
  Disabling signal VPOB9 for VPO 
  aspeed-g5-pinctrl 1e6e2080.pinctrl: Failed to acquire regmap for IP block 1
  aspeed-g5-pinctrl 1e6e2080.pinctrl: request() failed for pin 151 

The code path is aspeed-gpio -> pinmux-g5 -> regmap -> clk, and the of_clock code returns an error as it doesn't have a valid struct clk_hw pointer. The regmap call happens because pinmux wants to check the GFX node (IP block 1) to query bits there.

For reference, before the offending patch:

  Muxing pin 151 for GPIO
  Disabling signal VPOB9 for VPO 
  Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000
  Disabling signal VPOB9 for VPOOFF1
  Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000
  Disabling signal VPOB9 for VPOOFF2
  Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000
  Enabling signal GPIOS7 for GPIOS7
  Muxed pin 151 as GPIOS7
  gpio-943 (seq_cont): hogged as output/low

We can't skip the clock check to allow pinmux to proceed, because the write to disable VPOB9 will try to set a bit in the GFX register space which will not stick when the IP is in reset. However, we do not want to enable the IP just so pinmux can do a disable-enable dance for the pin.

I think GFX issue was always present but we never triggered it as no device had a pinmux configuration that disabled the VPO pin.

The offending patch results in changes of this kind (v6.1, plus patches that add a bit more debugging on top of DEBUG_PINMUX):

 aspeed-g6-pinctrl 1e6e2000.syscon:pinctrl: request pin 39 (B24) for 1e690000.ftgmac
 Muxing pin 28 for RGMII4
 Disabling signal NCTS3 for NCTS3
-Setting (0) signal NCTS3 for NCTS3
 Evaling signal NCTS3 for NCTS3
-Want SCU410[0x10000000]=0x0, got 0x0 from 0x0FFF300F
-raw & desc->mask: 00000000, __ffs(desc->mask): 0000001c, want 00000000
+Want SCU410[0x10000000]=0x1, got 0x0 from 0x0FFF300F
+raw & desc->mask: 00000000, __ffs(desc->mask): 0000001c, want 00000001

The full diff when booting v6.1 on an ast2600-evb hardware