Hi Michal, On Mon, 8 Aug 2022 at 14:27, Michal Suchánek <msucha...@suse.de> wrote: > > On Mon, Aug 08, 2022 at 01:26:23PM -0600, Simon Glass wrote: > > Hi Michal, > > > > On Sat, 6 Aug 2022 at 13:54, Michal Suchánek <msucha...@suse.de> wrote: > > > > > > On Sat, Aug 06, 2022 at 12:21:29PM -0600, Simon Glass wrote: > > > > Hi Michal, > > > > > > > > On Fri, 5 Aug 2022 at 14:07, Michal Suchánek <msucha...@suse.de> wrote: > > > > > > > > > > On Fri, Aug 05, 2022 at 10:48:26AM -0600, Simon Glass wrote: > > > > > > Hi Michal, > > > > > > > > > > > > On Fri, 5 Aug 2022 at 05:32, Michal Suchanek <msucha...@suse.de> > > > > > > wrote: > > > > > > > > > > > > > > When the sysreset is added as child of the pmic the pmic is probed > > > > > > > before relocation. That probe fails, and subsequent attempts to > > > > > > > probe > > > > > > > after reloaction fail as well. > > > > > > > > > > > > > > As a workaround do not bind the sysreset before relocation. > > > > > > > > > > > > > > Signed-off-by: Michal Suchanek <msucha...@suse.de> > > > > > > > --- > > > > > > > drivers/power/pmic/rk8xx.c | 2 +- > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/drivers/power/pmic/rk8xx.c > > > > > > > b/drivers/power/pmic/rk8xx.c > > > > > > > index a239a18674..d12263c4f2 100644 > > > > > > > --- a/drivers/power/pmic/rk8xx.c > > > > > > > +++ b/drivers/power/pmic/rk8xx.c > > > > > > > @@ -131,7 +131,7 @@ static int rk8xx_read(struct udevice *dev, > > > > > > > uint reg, uint8_t *buff, int len) > > > > > > > > > > > > > > static int rk8xx_bind(struct udevice *dev) > > > > > > > { > > > > > > > - if (CONFIG_IS_ENABLED(SYSRESET)) { > > > > > > > + if (CONFIG_IS_ENABLED(SYSRESET) && (gd->flags & > > > > > > > GD_FLG_RELOC)) { > > > > > > > device_bind_driver(dev, "rk8xx_sysreset", > > > > > > > "rk8xx_sysreset", NULL); > > > > > > > } > > > > > > > -- > > > > > > > 2.37.1 > > > > > > > > > > > > > > > > > > > I think it is OK to avoid starting a device before relocation, or > > > > > > make > > > > > > that device do something different. I really don't like the binding > > > > > > being optional though...we have the 'u-boot,dm-pre-reloc' for that. > > > > > > > > > > So perhaps the flag should be dropped from rk8xx then. > > > > > > > > > > > > > > > > > But missing from your commit message is exactly what fails? > > > > > > > > > > The pmic is an i2c device, all i2c tranferss fail if initialized > > > > > pre-relocation. I supect it's the i2c bus that fails if initialized > > > > > before reloc - the regulatorss that share the i2c bus also report i2c > > > > > transfer failure. > > > > > > > > OK, I wonder why i2c fails? It works OK on the rockchip devices I'm > > > > familiar with, e.g. chromebooks. > > > > > > It worksss fine here as well - so long as it is not initialized before > > > relocation. > > > > I wonder if the clock driver is doing something different then, or has > > a limited number of clocks? > > Looks like it is not the clocks. > > There is something slightly fishy going on there with them: > > In the broken case the i2c clock is not initialized before reloc > > TICE: BL31: v2.6(debug): > NOTICE: BL31: Built : 14:50:40, Jul 1 2022 > INFO: GICv3 with legacy support detected. > INFO: ARM GICv3 driver initialized in EL3 > INFO: Maximum SPI INTID supported: 287 > INFO: plat_rockchip_pmu_init(1624): pd status 3e > INFO: BL31: Initializing runtime services > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing! > INFO: BL31: Preparing for EL3 exit to normal world > INFO: Entry point address = 0x200000 > INFO: SPSR = 0x3c9 > rk8xx_bind > global flags 0 relocaddr 0 > rk8xx_sysreset_bind > rk8xx_bind: 'pmic@1b' - found regulators subnode > rk3399_clk_get_rate: clk clock-controller@ff760000 83 > clock-controller@ff760000 83: clock rate 24000000 > > > U-Boot 2022.07-00038-g61e11a8e9f-dirty (Aug 07 2022 - 19:53:20 +0200) > > U-Boot PLL at 00000000ff750000: fbdiv=112, refdiv=2, postdiv1=2, postdiv2=1, > vco=1344000 khz, output=672000 khz > i2c@ff3c0000: Got clock pmu-clock-controller@ff750000 9 > rockchip_i2c_probe: clk: pmu-clock-controller@ff750000 9 rate 0 count 0 flags > 0 > rockchip_i2c_set_bus_speed: 400000 > rk3399_i2c_get_pmuclk: clk 9, con 771, div 3 > rk3399_pmuclk_get_rate: clk pmu-clock-controller@ff750000 9 -> 169000000 <<< > different freqency > pmu-clock-controller@ff750000 9: clock rate 169000000 > rk_i2c_set_clk: clk pmu-clock-controller@ff750000 9, i2c rate = 169000000, > scl rate = 400000 > set i2c clk div = 51, divh = 26, divl = 25 > set clk(I2C_CLKDIV: 0x001a0019) > rk8xx_probe > original ID register > i2c_xfer: 2 messages > i2c_xfer: chip=0x1b, len=0x1 > rk_i2c_write: chip = 27, reg = 0, r_len = 0, b_len = 1 > I2c Send Start bit. > I2C Send Start Bit Timeout > i2c_con: 0x00010009 > i2c_clkdiv: 0x001a0019 > i2c_mrxaddr: 0x00000000 > i2c_mrxraddR: 0x00000000 > i2c_mtxcnt: 0x00000000 > i2c_mrxcnt: 0x00000000 > i2c_ien: 0x00000010 > i2c_ipd: 0x00000000 > i2c_fcnt: 0x00000000 > i2c_txdata0: 0x00000000 > i2c_txdata1: 0x00000000 > i2c_txdata2: 0x00000000 > i2c_txdata3: 0x00000000 > i2c_txdata4: 0x00000000 > i2c_txdata5: 0x00000000 > i2c_txdata6: 0x00000000 > i2c_txdata7: 0x00000000 > i2c_rxdata0: 0x00000000 > i2c_rxdata1: 0x00000000 > i2c_rxdata2: 0x00000000 > i2c_rxdata3: 0x00000000 > i2c_rxdata4: 0x00000000 > i2c_rxdata5: 0x00000000 > i2c_rxdata6: 0x00000000 > i2c_rxdata7: 0x00000000 > i2c_write: error sending > read from device: 00000000002fcff0 register: 0x17 -> -121 > SoC: Rockchip rk3399 > Reset cause: RST > Model: Pine64 Pinebook Pro > DRAM: 3.9 GiB > rk8xx_bind > global flags 301 relocaddr f6f1d000 > rk8xx_sysreset_bind > rk8xx_bind: 'pmic@1b' - found regulators subnode > U-Boot PLL at 00000000ff750000: fbdiv=112, refdiv=2, postdiv1=2, postdiv2=1, > vco=1344000 khz, output=672000 khz > i2c@ff3c0000: Got clock pmu-clock-controller@ff750000 9 > rk3399_i2c_set_pmuclk: clk 9, hz 200000000, div 3 > rk3399_pmuclk_set_rate: clk pmu-clock-controller@ff750000 9 rate 200000000 -> > 169000000 <<< here the old frequency is returned > rockchip_i2c_probe: clk: pmu-clock-controller@ff750000 9 rate 0 count 0 flags > 0 > rockchip_i2c_set_bus_speed: 400000 > rk3399_i2c_get_pmuclk: clk 9, con 770, div 2 > rk3399_pmuclk_get_rate: clk pmu-clock-controller@ff750000 9 -> 225333333 <<< > but here the frequency is reported higher > pmu-clock-controller@ff750000 9: clock rate 225333333 > rk_i2c_set_clk: clk pmu-clock-controller@ff750000 9, i2c rate = 225333333, > scl rate = 400000 > set i2c clk div = 69, divh = 35, divl = 34 > set clk(I2C_CLKDIV: 0x00230022) > rk8xx_probe > original ID register > i2c_xfer: 2 messages > i2c_xfer: chip=0x1b, len=0x1 > rk_i2c_write: chip = 27, reg = 0, r_len = 0, b_len = 1 > I2c Send Start bit. > I2C Send Start Bit Timeout > > Basically the old 169000000 and the new 225333333 frequency are both > different rounding of 200000000 for lower and higher divisor and > generally not all that different. > > It is fishy that get_clock_rate and set_clock_rate report different > frequency using the same frequency calcualtion macro. Nonetheless, > forcing the set_clock_rate call from the i2c driver does not help, the > i2c transfers fail anyway: > > rk8xx_bind > global flags 0 relocaddr 0 > rk8xx_sysreset_bind > rk8xx_bind: 'pmic@1b' - found regulators subnode > rk3399_clk_get_rate: clk clock-controller@ff760000 83 > > > U-Boot 2022.07-00043-g395bdd35fe-dirty (Aug 08 2022 - 22:09:19 +0200) > > U-Boot PLL at 00000000ff750000: fbdiv=112, refdiv=2, postdiv1=2, postdiv2=1, > vco=1344000 khz, output=672000 khz > i2c@ff3c0000: Got clock pmu-clock-controller@ff750000 9 > rk3399_i2c_get_pmuclk: clk 9, con 771, div 3 > rk3399_pmuclk_get_rate: clk pmu-clock-controller@ff750000 9 -> 169000000 > rockchip_i2c_probe: clk: pmu-clock-controller@ff750000 9 rate 0 count 0 flags > 0 > rk3399_i2c_set_pmuclk: clk 9, hz 200000000, div 3 > rk3399_pmuclk_set_rate: clk pmu-clock-controller@ff750000 9 rate 200000000 -> > 169000000 > rockchip_i2c_probe: clk: pmu-clock-controller@ff750000 9 rate 0 count 0 flags > 0 > rockchip_i2c_set_bus_speed: 400000 > rk3399_i2c_get_pmuclk: clk 9, con 770, div 2 > rk3399_pmuclk_get_rate: clk pmu-clock-controller@ff750000 9 -> 225333333 > rk_i2c_set_clk: clk pmu-clock-controller@ff750000 9, i2c rate = 225333333, > scl rate = 400000 > set i2c clk div = 69, divh = 35, divl = 34 > set clk(I2C_CLKDIV: 0x00230022) > rk8xx_probe > original ID register > i2c_xfer: 2 messages > i2c_xfer: chip=0x1b, len=0x1 > rk_i2c_write: chip = 27, reg = 0, r_len = 0, b_len = 1 > I2c Send Start bit. > I2C Send Start Bit Timeout > i2c_con: 0x00010009 > i2c_clkdiv: 0x00230022 > i2c_mrxaddr: 0x00000000 > i2c_mrxraddR: 0x00000000 > i2c_mtxcnt: 0x00000000 > i2c_mrxcnt: 0x00000000 > i2c_ien: 0x00000010 > i2c_ipd: 0x00000000 > i2c_fcnt: 0x00000000 > i2c_txdata0: 0x00000000 > i2c_txdata1: 0x00000000 > i2c_txdata2: 0x00000000 > i2c_txdata3: 0x00000000 > i2c_txdata4: 0x00000000 > i2c_txdata5: 0x00000000 > i2c_txdata6: 0x00000000 > i2c_txdata7: 0x00000000 > i2c_rxdata0: 0x00000000 > i2c_rxdata1: 0x00000000 > i2c_rxdata2: 0x00000000 > i2c_rxdata3: 0x00000000 > i2c_rxdata4: 0x00000000 > i2c_rxdata5: 0x00000000 > i2c_rxdata6: 0x00000000 > i2c_rxdata7: 0x00000000 > > It looks like it is not clock related after all, although the i2c clock > getting set post-relocation and not pre-relocation might be source of > problems if the frequency was significantly different without the > set_clock_rate call.
I suppose the other option is pinmux? Regards, Simon