On 12.11.2020 15:55, Rafał Miłecki wrote:
*** PMB ***
It seems like PMB Master is reset controller on its own. Even though we don't
have actual driver for the (documented) "brcm,bcm63138-pmb" binding, arch code
treates it like a reset.
So it seems that a single PMB is capable at least of:
1. Resetting ARM CPU core (id by 8b addr)
2. Resetting devices (id by 8b addr) by (en|dis)abling zones
Above operations are performed in a different (programming) ways.
*** PMC ***
PMC seems to be a reset controller with firmware capable at least of:
1. Resetting devices (id by 8b addr) by (en|dis)abling zones
that fallback to using PMB blocks when needed / required.
This just got more complex as I started playing with PMC / PMB and PCIe
controller.
1. BPCM_CAPABILITIES reg for PCIe controller reports 0 num_zones
2. Enabling PCIe requires powering on zone 0 manually
3. After powering on zone, PCIe requires setting SR_CONTROL
It means that PMB driver (and so PMC one as it fallback to the PMB) needs to
know what type of device we're addressing.
Anything simple like:
resets = <&pmb0 14>;
resets = <&pmc 1 14>;
won't work (unless we hardcode ids in driver - which is unwanted for DTS).
So I guess that after all we'll need something like:
cpu@1 {
resets = <&pmb0 PMB_ARM 4>; /* ARM CPU */
}
foo {
resets = <&pmb1 PMB_USB_DEVICE 17>; /* Reset USB using PMB directly */
}
bar {
resets = <&pmb1 PMB_PCIE_DEVICE 15>; /* Reset PCIE using PMB directly */
}
and also
qux {
resets = <&pmc PMB_PCIE_DEVICE 1 15>; /* Reset PCIe using PMC */
}
