Hello all,
I'm working on a custom board based on a stm32mp157c & stpmic1 (connected on I2C4). We are using secure boot and have configured the I2C4 to work in secured mode. To control the stpmic1 from the unsecure / normal world, we use the scmi-regulator under linux.
The following configuration seems to work:
- i2c4 clock source: CLK_I2C46_PCLK5
- stpmic will be initialized in optee (stpmic will be detected and the various regulator entries will be created)
- regulator entries are created under linux
- regulator entries can be controlled by userspace consumers (echo "enabled" > /sys/devices/platform/userspace_consumer_vdd_xyz)
Changing the clock source to CLK_I2C46_PLL3Q (which is configured to provide the same frequency as PCLK5) results in the following behaviour:
- stpmic will be initialized in optee (stpmic will be detected and the various regulator entries will be created) - everything seems to be fine (communication with stpmic1 is working)
- regulator entries are created under linux
- controlling by userspace consumers does no longer work (I have added a panic if pmic can no longer being accessed)
echo "enabled" > /sys/devices/platform/userspace_consumer_vdd_xyz/state
F/TC:? 0 pta_scmi_ocall:178 Posting MSG message on channel 0u
F/TC:? 0 plat_scmi_voltd_get_config:180 (channel 0/domain 9) config 0
F/TC:? 0 pta_scmi_ocall:178 Posting MSG message on channel 0u
F/TC:? 0 plat_scmi_voltd_set_config:196 (channel 0/domain 9) set config to 7
F/TC:? 0 _regulator_enable:150 buck4
F/TC:? 0 pmic_set_state:196 buck4: set state to 1
F/TC:1 0 __clk_enable:1174 Clock 140 has been enabled
F/TC:1 0 __clk_disable:1187 Clock 140 has been disabled
E/TC:1 0 Panic 'Failed to access PMIC in pmic_set_state' at ?:0
Any idea why the I2C4 / pmic can no longer being accessed after the linux kernel has been started? The rcc information in the kernel dtb is empty - so a possible reconfiguration shouldn't be a problem.
Before we have moved I2C4 / stpmic1 to secure world we already have used these components in normal world with the following results:
i2c4 clock source: CLK_I2C46_PCLK5
- stpmic1 works without any problems
i2c4 clock source: CLK_I2C46_PLL3Q
- stpmic1 works and can be controlled but we have got a few imprecise aborts under linux (which has been catched by a custom abort handler)
Is there something special about the PLL3(Q) that we don't know about?
Best Regards,
florian
