Hi Pali,
On 12/10/21 15:23, Pali Rohár wrote:
<snip>
So I think the correct behavior should be:
1. pci-mvebu.c configures all controller registers to correct values
2. PCIe port is enabled via SoC-specific register
3. pci-mvebu.c waits for link up
I guess that reset-controller does not help, as core release this reset
prior starting driver initialization.
Ok, it looks like that reset controller API allows to do this. It would
mean to define that "system-controller@18200" as reset controller,
exports from it for each PCIe port reset functionality and implements
assert and deassert functions which disable and enable port.
And because DTS for pci-mvebu.c driver is defined as multi-root-port,
"resets" property would need to be defined for each port separately.
Okay. Sounds like a plan to me.
I'm looking at this right now and it is even more complicated. For
example Armada XP has for some ports dedicated enable bits and for some
ports has just one shared enable bit.
And this HW design does not fit into current U-Boot PCI DM model where
for each PCIe port there is dedicated mvebu_pcie_probe() call which
should setup PCIe port, enable PCIe port and returns once PCIe port is
ready. In U-Boot PCI DM model is every PCIe port as separate DM device.
Any idea how to solve this issue?
Sorry, but I don't have clear "solution" for this in my mind right now.
Thanks,
Stefan
Just I'm not sure if this "enable port functionality" should be
implemented via Reset Controller API...
How else should / could this be done then? Do you have alterative ideas?
Thanks,
Stefan
Anyway, this A385 SoC Control 1 Register is at address 0x18204 which is
part of following device defined in kernel DTS file:
systemc: system-controller@18200 {
compatible =
"marvell,armada-380-system-controller",
"marvell,armada-370-xp-system-controller";
reg = <0x18200 0x100>;
};
Linux kernel has driver for this DTS device is file:
arch/arm/mach-mvebu/system-controller.c
U-Boot does not have any driver for this compatible string.
So PCIe port enable/disable should be in this driver. I can write simple
driver also for U-Boot which can control this register. But I really do
not know which interface should it use.
Has somebody else any idea?
I just looked into some Linux PCIe DT bindings and found e.g. this in
the mediatek spec:
Documentation/devicetree/bindings/pci/mediatek-pcie.txt
...
Required properties for MT7623/MT2701:
...
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the
number of root ports.
...
resets = <&hifsys MT2701_HIFSYS_PCIE0_RST>,
<&hifsys MT2701_HIFSYS_PCIE1_RST>,
<&hifsys MT2701_HIFSYS_PCIE2_RST>;
reset-names = "pcie-rst0", "pcie-rst1", "pcie-rst2";
phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>,
<&pcie2_phy PHY_TYPE_PCIE>;
phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2";
And make sure in the serdes code keeps (or actively sets?) these PCIe
ports into the reset state. The PCIe driver would then release the ports
out of reset after their configuration.
Or is some other serdes code missing in between "get PCIe port out of
reset" and the MVEBU PCIe driver taking over the control?
What do you think? I might be missing something here.
Thanks,
Stefan
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
