arm64/rockchip: add RK3399 support

[val_packett.cool]

Summary

This adds Rockchip RK3399 (e.g., Pine64 ROCKPro64) support:

• Ethernet works, ~500mbps. Can netboot like on RK3328 (ROCK64)
• I²C seems to work (rk805 PMIC driver (with 'rk808' name added) does not error)
• clocks/PLLs work

To actually reclock the CPU, extra hacks are required for now. (Basically, making cpufreq not require voltage control. On ROCKPro64, the default voltage is enough for the max clock. Actually the default voltage might be the highest one, since the heatsink gets rather hot when just idling in FreeBSD.)

To reclock properly, we'll need the rk8xx driver mentioned above. And, at least on the ROCKPro64, a driver for the "silergy,syr827" (aka "fcs,fan53555") which controls voltage for the big (Cortex-A72) cores. Other boards might use other chips for that voltage I guess.

(upd: trying to write that driver — the cpufreq isn't finding the regulator…)

[ganbold]

few style notes

sys/arm64/rockchip/clk/rk3399_cru.c

1049

maybe eliminate some empty lines?

1381

Is indentation correct here?

sys/arm64/rockchip/clk/rk3399_pmucru.c

875

same here

sys/arm64/rockchip/rk_pinctrl.c

92

This probably goes over 80 chars

245

Maybe you meant following?

static struct syscon *
rk3328_get_syscon(struct rk_pinctrl_softc *sc, uint32_t bank)

247

blank line before it and return (sc->grf);

387

same here as above

389

blank line before it

391

wrap return values with ()

399

comments rather with /* XXX */ style

[val_packett.cool]

changed style

[manu]

This looks good, just remove the pmu driver for now as we don't use it.

sys/arm64/rockchip/rk_pmu.c

52

Not sure we need a driver for this now, the generic syscon should work. Note that no nodes seems to use the device node, linux tend to add syscon to everything ...
(Also I have a patch for simple-mfd that will make the subnode probe).

[manu]

I meant to set this to "request changes", sorry.

[val_packett.cool]

removed pmu driver

[manu]

Currently building world for my rockpro64, will test and commit after.

[manu]

This doesn't work.
The PLL in the pmucru are wait different.

[val_packett.cool]

Only ppll is in pmucru.. you mean it has different rates?

What exactly doesn't work?

[manu]

In D16732#390513, @greg_unrelenting.technology wrote:

Only ppll is in pmucru.. you mean it has different rates?

What exactly doesn't work?

Just look at the TRM

[val_packett.cool]

In D16732#390517, @manu wrote:

Just look at the TRM

That's not very helpful ;)

Is it the gate_shift in ppll? Should be 1 instead of 0?

[manu]

In D16732#390557, @greg_unrelenting.technology wrote:

In D16732#390517, @manu wrote:

Just look at the TRM

That's not very helpful ;)

Just compare RK3328 and RK3399 TRM, you will see.

Is it the gate_shift in ppll? Should be 1 instead of 0?

No.
Every PLL is different in RK3399, I'm working on a patch.

[manu]

There is also problem with the pinctrl (I have this mostly worked out now).
I2C doesn't work (doesn't know why for now).
Some clocks IDs aren't correct.
I honestly don't know how this was tested.

[val_packett.cool]

In D16732#390886, @manu wrote:

I honestly don't know how this was tested.

I got it to boot to multiuser on NFS. And to reclock the CPU.

I2C doesn't work

hm, the rk805 driver was reporting something. I thought it wouldn't report anything without working i2c?

Some clocks IDs aren't correct.

IIRC they were different between the TRM and the Linux drivers and I picked the ones that Linux used, because I thought that would align with what's actually in the (rockchip, not mainline) device tree, or something.

[manu]

In D16732#390887, @greg_unrelenting.technology wrote:

In D16732#390886, @manu wrote:

I honestly don't know how this was tested.

I got it to boot to multiuser on NFS. And to reclock the CPU.

Not possible, the PLL weren't correctly defined.

I2C doesn't work

hm, the rk805 driver was reporting something. I thought it wouldn't report anything without working i2c?

It does since it's only added because of the compat string in the dtb.

Some clocks IDs aren't correct.

IIRC they were different between the TRM and the Linux drivers and I picked the ones that Linux used, because I thought that would align with what's actually in the (rockchip, not mainline) device tree, or something.

No some where different that in the dt-bindings (PCLK_ALIVE for example)

[val_packett.cool]

In D16732#390901, @manu wrote:

In D16732#390887, @greg_unrelenting.technology wrote:

I got it to boot to multiuser on NFS. And to reclock the CPU.

Not possible, the PLL weren't correctly defined.

Either they don't need to be, or they are actually correct enough ¯\_(ツ)_/¯

https://dmesgd.nycbug.org/index.cgi?do=view&id=4298

When you said

Every PLL is different in RK3399

Did you mean they are different between each other? I didn't find that anywhere, the TRM says

The chip uses 3.2GHz VCO PLL for all eight PLLs.

And like in section 2.9.1 "PLL usage" it even shows glob style wildcards like CRU_*PLL_CON0