Hi Adam, > Am 11.09.2019 um 02:41 schrieb Adam Ford <aford173@xxxxxxxxx>: >>>> >>>> The error message looks as if we have to enable multi_regulator. >>> >>> That will enable both vdd and vbb regulators from what I can tell in the driver. >>> >>>> And that may need to rename cpu0-supply to vdd-supply (unless the >>>> names can be configured). >>> >>> That is consistent with what I found. vdd-supply = <&vcc>; and >>> vbb-supply = <&abb_mpu_iva>; >>> I put them both under the cpu node. Unfortunately, when I did that, >>> my board crashed. >>> >>> I am thinking it has something to do with the abb_mpu_iva driver >>> because until this point, we've always operated at 800MHz or lower >>> which all have the same behavior in abb_mpu_iva. >>> >>> With the patch you posted for the regulator, without the update to >>> cpufreq, and with debugging enabled, I received the following in >>> dmesg: >>> >>> [ 1.112518] ti_abb 483072f0.regulator-abb-mpu: Missing >>> 'efuse-address' IO resource >>> [ 1.112579] ti_abb 483072f0.regulator-abb-mpu: [0]v=1012500 ABB=0 >>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 >>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [1]v=1200000 ABB=0 >>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 >>> [ 1.112609] ti_abb 483072f0.regulator-abb-mpu: [2]v=1325000 ABB=0 >>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 >>> [ 1.112640] ti_abb 483072f0.regulator-abb-mpu: [3]v=1375000 ABB=1 >>> ef=0x0 rbb=0x0 fbb=0x0 vset=0x0 >>> [ 1.112731] ti_abb 483072f0.regulator-abb-mpu: ti_abb_init_timings: >>> Clk_rate=13000000, sr2_cnt=0x00000032 >>> >> >> Using an unmodified kernel, I changed the device tree to make the abb >> regulator power the cpu instead of vcc. After doing so, I was able to >> read the microvolt value, and it matched the processor's desired OPP >> voltage, and the debug code showed the abb regulator was attempting to >> set the various index based on the needed voltage. I think the abb >> driver is working correctly. >> >> I think tomorrow, I will re-apply the patches and tweak it again to >> support both vdd and vbb regulators. If it crashes again, I'll look >> more closely at the logs to see if I can determine why. I think it's >> pretty close. I also need to go back and find the SmartReflex stuff >> as well. >> > Well, I couldn't give it up for the night, so I thought I'd show my data dump > > [ 9.807647] ------------[ cut here ]------------ > [ 9.812469] WARNING: CPU: 0 PID: 68 at drivers/opp/core.c:630 > dev_pm_opp_set_rate+0x3cc/0x480 > [ 9.821044] Modules linked in: sha256_generic sha256_arm cfg80211 > joydev mousedev evdev snd_soc_omap_twl4030(+) leds_gpio led_class > panel_simple pwm_omap_dmtimer gpio_keys pwm_bl cpufreq_dt omap3_isp v > ideobuf2_dma_contig videobuf2_memops videobuf2_v4l2 videobuf2_common > bq27xxx_battery_hdq v4l2_fwnode snd_soc_omap_mcbsp bq27xxx_battery > snd_soc_ti_sdma omap_wdt videodev mc omap_hdq wlcore_sdio wire cn ph > y_twl4030_usb hwmon omap2430 musb_hdrc omap_mailbox twl4030_wdt > watchdog udc_core rtc_twl snd_soc_twl4030 ohci_platform(+) > snd_soc_core snd_pcm_dmaengine ohci_hcd snd_pcm ehci_omap(+) > twl4030_pwrbutton sn > d_timer twl4030_charger snd pwm_twl_led pwm_twl ehci_hcd industrialio > soundcore twl4030_keypad matrix_keymap usbcore at24 tsc2004 > tsc200x_core usb_common omap_ssi hsi omapdss omapdss_base drm > drm_panel_or > ientation_quirks cec > [ 9.894470] CPU: 0 PID: 68 Comm: kworker/0:2 Not tainted > 5.3.0-rc3-00785-gfdfc7f21c6b7-dirty #5 > [ 9.903198] Hardware name: Generic OMAP36xx (Flattened Device Tree) > [ 9.909515] Workqueue: events dbs_work_handler > [ 9.914031] [<c01122d8>] (unwind_backtrace) from [<c010c8b8>] > (show_stack+0x10/0x14) > [ 9.921813] [<c010c8b8>] (show_stack) from [<c089e858>] > (dump_stack+0xb4/0xd4) > [ 9.929107] [<c089e858>] (dump_stack) from [<c0139eb0>] > (__warn.part.3+0xa8/0xd4) > [ 9.936614] [<c0139eb0>] (__warn.part.3) from [<c013a034>] > (warn_slowpath_null+0x40/0x4c) > [ 9.944854] [<c013a034>] (warn_slowpath_null) from [<c06d666c>] > (dev_pm_opp_set_rate+0x3cc/0x480) > [ 9.953796] [<c06d666c>] (dev_pm_opp_set_rate) from [<bf1790ac>] > (set_target+0x30/0x58 [cpufreq_dt]) > [ 9.963012] [<bf1790ac>] (set_target [cpufreq_dt]) from > [<c06db05c>] (__cpufreq_driver_target+0x188/0x514) > [ 9.972717] [<c06db05c>] (__cpufreq_driver_target) from > [<c06de050>] (od_dbs_update+0x130/0x15c) > [ 9.981567] [<c06de050>] (od_dbs_update) from [<c06deb08>] > (dbs_work_handler+0x28/0x58) > [ 9.989624] [<c06deb08>] (dbs_work_handler) from [<c0154ab0>] > (process_one_work+0x20c/0x500) > [ 9.998107] [<c0154ab0>] (process_one_work) from [<c0155e8c>] > (worker_thread+0x2c/0x5bc) > [ 10.006256] [<c0155e8c>] (worker_thread) from [<c015ab88>] > (kthread+0x134/0x148) > [ 10.013702] [<c015ab88>] (kthread) from [<c01010e8>] > (ret_from_fork+0x14/0x2c) > [ 10.020965] Exception stack(0xde63bfb0 to 0xde63bff8) > [ 10.026062] bfa0: 00000000 > 00000000 00000000 00000000 > [ 10.034271] bfc0: 00000000 00000000 00000000 00000000 00000000 > 00000000 00000000 00000000 > [ 10.042510] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 > [ 10.049224] ---[ end trace cf0e15fa4bd57700 ]--- > [ 10.053894] cpu cpu0: multiple regulators are not supported > [ 10.059509] cpufreq: __target_index: Failed to change cpu frequency: -22 I have the same: [ 4.701354] cpu cpu0: multiple regulators are not supported [ 4.707794] cpufreq: __target_index: Failed to change cpu frequency: -22 Comes from within dev_pm_opp_set_rate(). It appears that we also have to define opp_table->set_opp to make use of _set_opp_custom(). And I am not sure which custom-opp-setter we should use. Maybe ti_opp_supply_set_opp() is ok. Or not. BR, Nikolaus
