So, as might have been obvious from an answer in another post I'm trying to help a little with restoring and improving the BeagleBone Black & possiblye other TI processors support.
One of the things that I've been wanting to have ever since using FreeBSD (on the BBB) is dynamic frequency & voltage control through cpufreq(4). As far as I can tell from viewing the code a few other platforms support this (e.g. RockChip 3288 & 3399 using RK808) and I'm trying to do the same for the AM335x/TPS65217x.
Some context: there's a driver, cpufreq_dt, which reads OPP-values & voltages from the device tree (DT). This is loaded right after the CPU is attached and sits in the DT on the cpu-bus. It requires regulator(9) instances. These regulators - on both RockChip & TI platforms - can be found on a PMIC which is located on the I²C-bus/iicbus.
So I'm looking how I could possibly either:
* have my own driver (on iicbus) loaded before the cpufreq_dt driver so it could register regulators in time
* delay the cpufreq_dt driver until after iicbus devices
I have not succeeded in doing either but I don't know if it's even possible. I'm quite convinced that once I achieve any of these I'll be able to tackle the next problem (setting or filtering opp values).
I've tried quite a lot unsuccessfully but I don't know if I did all of it correctly: changing devices to other busses, trying EARLY_DRIVER_MODULE, literal copy/paste from rk808 driver & mostly emptying the driver. The only thing I didn't try is mess with the device tree because I want to keep it original.
I do not have any of the RockChip platforms to compare the dmesg output, I'd be grateful if someone who does could post the relevant parts (egrep "cpu|pmu|regulator") in the order these currently appear. My current dmesg (including some debug messages I added) is below. Note that pmu0 isn't (but should be?) related to the PMIC, but is still loaded after cpufreq_dt anyway:
For those who're wondering if I'll ever bring UE(5) support up to date: most likely yes, but many issues are blocking me from spending time on it.
One of the things that I've been wanting to have ever since using FreeBSD (on the BBB) is dynamic frequency & voltage control through cpufreq(4). As far as I can tell from viewing the code a few other platforms support this (e.g. RockChip 3288 & 3399 using RK808) and I'm trying to do the same for the AM335x/TPS65217x.
Some context: there's a driver, cpufreq_dt, which reads OPP-values & voltages from the device tree (DT). This is loaded right after the CPU is attached and sits in the DT on the cpu-bus. It requires regulator(9) instances. These regulators - on both RockChip & TI platforms - can be found on a PMIC which is located on the I²C-bus/iicbus.
So I'm looking how I could possibly either:
* have my own driver (on iicbus) loaded before the cpufreq_dt driver so it could register regulators in time
* delay the cpufreq_dt driver until after iicbus devices
I have not succeeded in doing either but I don't know if it's even possible. I'm quite convinced that once I achieve any of these I'll be able to tackle the next problem (setting or filtering opp values).
I've tried quite a lot unsuccessfully but I don't know if I did all of it correctly: changing devices to other busses, trying EARLY_DRIVER_MODULE, literal copy/paste from rk808 driver & mostly emptying the driver. The only thing I didn't try is mess with the device tree because I want to keep it original.
I do not have any of the RockChip platforms to compare the dmesg output, I'd be grateful if someone who does could post the relevant parts (egrep "cpu|pmu|regulator") in the order these currently appear. My current dmesg (including some debug messages I added) is below. Note that pmu0 isn't (but should be?) related to the PMIC, but is still loaded after cpufreq_dt anyway:
Code:
cpu0: <Open Firmware CPU> on cpulist0
cpu0: Nominal frequency 1000Mhz
cpu0: cpufreq_dt: IDENTIFY
cpufreq_dt0: cpufreq_dt: PROBE
cpufreq_dt0: PROBING FOR CPUFREQ_DT
cpufreq_dt0: cpufreq_dt: PROBE
cpufreq_dt0: PROBING FOR CPUFREQ_DT
cpufreq_dt0: <Generic cpufreq driver> on cpu0
cpufreq_dt0: cpufreq_dt: ATTACH
cpufreq_dt0: cpufreq_dt: cpu=0
cpufreq_dt0: No regulator found ALTHOUGH cpu0 has cpu0-supply property as expected ...
cpufreq_dt0: Only opp-shared is supported
cpufreq_dt0: 300.000 Mhz (950000 uV)
cpufreq_dt0: 275.000 Mhz (1100000 uV)
cpufreq_dt0: 300.000 Mhz (1100000 uV)
cpufreq_dt0: 500.000 Mhz (1100000 uV)
cpufreq_dt0: 600.000 Mhz (1100000 uV)
cpufreq_dt0: 600.000 Mhz (1200000 uV)
cpufreq_dt0: 720.000 Mhz (1200000 uV)
cpufreq_dt0: 720.000 Mhz (1260000 uV)
cpufreq_dt0: 800.000 Mhz (1260000 uV)
cpufreq_dt0: 1000.000 Mhz (1325000 uV)
cpufreq_dt0: cpufreq_dt: Skipping our cpu
cpufreq_dt0: cpufreq_dt: NOTIFY
ofwbus0: <opp-table> compat operating-points-v2-ti-cpu (no driver attached)
pmu0: <Performance Monitoring Unit> irq 0 on ti_sysc1
//much later (note: am335x_pmic is renamed to tps65217_pmu)
iicbus0: <OFW I2C bus> on iichb0
iic0: <I2C generic I/O> on iicbus0
tps65217_pmu0: <TPS65217 PMIC> at addr 0x48 irq 43 on iicbus0
tps65217_pmu0: tps65217_regnode_get_voltage: Regulator dcdc1 is at 1500000 uvolt
tps65217_pmu0: Regulator vdds_dpr: voltage: 1500000 uV
// other regulators snippedFor those who're wondering if I'll ever bring UE(5) support up to date: most likely yes, but many issues are blocking me from spending time on it.
Last edited: