fu540_prci: Rename to sifive_prci and use ocd_data for FU540 specificity

[jrtc27]

Summary

The FU740 has a very similar controller and will reuse most of the
driver. This also drops the dependency on the device-tree include for
the binding indices; the header doesn't namespace its contents (and nor
does the FU740 one) so using both would require seperate translation
units which would be unnecessarily complicated just to avoid defining
local copies of the small number of constants.

Whilst here, add the missing l to gemgxlclk's name and drop the prci_
prefix from tlclk's name as we don't prefix any of the others and it's
entirely unnecessary.

[kp]

LGTM

[mhorne]

The odd naming for tlkclk was discussed in D23406. Assuming the clk framework can accept two clocks with the same name, I think we are better off with this rename.

The issue with headers in dt-bindings is disappointing. The Linux patches for pcri do indeed have separate translation units, iirc. Ideally we would fix this upstream but it is really not worth what I can only assume would become a big hassle.

[jrtc27]

In D31021#703923, @mhorne wrote:

The odd naming for tlkclk was discussed in D23406. Assuming the clk framework can accept two clocks with the same name, I think we are better off with this rename.

Our in-tree copy of the device tree should long have lost the old fixed clock node. For what it's worth, the Linux kernel also just names the PRCI's clock tlclk on both boards, but I don't know if they have the same global namespace issue. Our clk framework does just have a big global linked-list of clocks and so names need to be unique. But I'd be tempted to just say "don't use those ancient device trees for the FU540".

The issue with headers in dt-bindings is disappointing. The Linux patches for pcri do indeed have separate translation units, iirc. Ideally we would fix this upstream but it is really not worth what I can only assume would become a big hassle.

The other original motivation for this was I wrote the patches before a sufficiently new dt-bindings had been imported and thus had to define them myself anyway for the FU740. But yeah I don't think it's worth trying to namespace things upstream, it's a lot of hassle just to avoid defining a few constants ourselves.

[mhorne]

In D31021#703930, @jrtc27 wrote:

In D31021#703923, @mhorne wrote:

The odd naming for tlkclk was discussed in D23406. Assuming the clk framework can accept two clocks with the same name, I think we are better off with this rename.

Our in-tree copy of the device tree should long have lost the old fixed clock node. For what it's worth, the Linux kernel also just names the PRCI's clock tlclk on both boards, but I don't know if they have the same global namespace issue. Our clk framework does just have a big global linked-list of clocks and so names need to be unique. But I'd be tempted to just say "don't use those ancient device trees for the FU540".

They seem to no longer provide those old DTs in freedom-u-sdk (which was the case at the time), so I agree. @kp any feeling on if Axiado would get burnt by this? One would hope that if they are tracking FreeBSD upstream they will eventually update their bootloader...

[kp]

In D31021#703937, @mhorne wrote:

They seem to no longer provide those old DTs in freedom-u-sdk (which was the case at the time), so I agree. @kp any feeling on if Axiado would get burnt by this? One would hope that if they are tracking FreeBSD upstream they will eventually update their bootloader...

With the disclaimer that I'm not up to date on Axiado's plans, but it should be safe to make this change. Their setup had the device tree as part of the image, so whenever FreeBSD is updated they can update the device tree along with it, so this won't hurt. Or not significantly anyway.