Re: [GIT PULL 2/3] ARM: tegra: move fuse code out of arch/arm

[Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>]

On Mon, Jul 21, 2014 at 05:38:25PM +0100, Stephen Warren wrote:
> On 07/21/2014 09:54 AM, Catalin Marinas wrote:
> > On arm64, I really want to get away from any SoC specific early
> > initcall. One of the main reason is for things like SCU, interconnects,
> > system cache configurations (even certain clocks) to be enabled in
> > firmware before Linux starts (it's an education process but that's a way
> > for example to prevent people sending patches to enable SoC coherency
> > because they haven't thought about it before upstreaming).
> > 
> > It would be nice to be able to initialise SoC stuff at device_initcall()
> > level (and even keep such code as modules in initramfs) but one of the
> > problems we have is dependency on clocks (and the clock model which
> > doesn't follow the device/driver model). The of_platform_populate() is
> > called at arch_initcall_sync (after arch_initcall to still allow some
> > SoC code, if needed, to run at arch_initcall).
> 
> The main thing I want to avoid is a ton of separate drivers that all
> rely on each-other getting resolved by deferred probe. While that might
> work out, it seems pointless to make the kernel try and probe a bunch of
> stuff just to have it fail and get repeated, when we know exactly which
> order everything should get initialized in.

So of_platform_populate() is called at arch_initcall_sync() level on
arm64. This allows at least two levels of probing separation before
(e.g. drivers registered as arch_initcall) and after (device_initcall).
If you register a driver earlier than arch_initcall_sync (see for
example vexpress_osc_init), it will get probed when the platform devices
are populated. Any later device_initcalls will get probed when the
corresponding drivers are registered. If you need ordering between
device_initcalls, I would recommend deferred probing.

The tricky part is if you need more drivers to be initialised at
arch_initcall_sync() in a specific order. Here it looks like the node
ordering in DT has an effect on probing. I don't say the DT should list
them in the order they should be probed but maybe we can improve the
model and do some sorting during unflattening (as I suggested in my
reply to Olof). In the meantime, for vexpress we worked around it by
explicitly checking the compatible node during a pre-arch_initcall.

> Another issue is that we have SoCs which only differ in the CPU.

Do you mean ARMv7 vs ARMv8 CPUs?

> I want
> the code to work identically on both SoCs so the CPU has limited affect
> on the low-level IO code. If we're going to enforce a "no machine
> descriptors" rule on arch/arm64, I think we should do the same thing in
> arch/arm for consistency.

We've done this with vexpress thanks to Pawel. As he said, the difficult
part was converting the existing code to the Linux device model. The
32-bit v2m_dt_init() function simply calls of_platform_populate(). If
you don't have a machine_desc at all, this would be the default (see
customize_machine()). If you use PSCI, there is no need for SoC specific
smp_ops either. So you basically get the same code base with no
additional arch/arm/mach-* machine_desc.

> > We have a similar issue with arm64 vexpress (well, just on the model)
> > where vexpress_sysreg_init() is a core_initcall (should be fine as
> > arch_initcall) as it needs to be done before of_platform_populate().
> > Pawel on cc should know more of the history here.
> > 
> > I recall there were also some discussions about a SoC driver model which
> > hangs off the top compatible string in the DT (e.g. "arm,vexpress") and
> > allow (minimal) code to be run slightly earlier, though still not
> > earlier than arch_initcall.
> 
> I guess that would work out OK; if we force the driver that binds to a
> top-level compatible value of "nvidia,tegraNNN" to probe first, and it
> then calls out to all the low-level init code in a sane order, that
> would solve the problem. I'm not sure that's any better than having a
> machine descriptor with an "init" function though; wrapping all this in
> a driver just seems like overhead, but it would work out OK.

Looking at the tegra_init_early(), I think for arm64 as
pre-arch_initcall_sync you would only need:

	tegra_init_fuse();
	tegra_powergate_init();

(I'm not sure about trusted foundations but that's a 32-bit only project
for the time being)

From tegra_dt_init() you need clocks but isn't CLK_OF_DECLARE enough?
You also have PMC code and I'm not familiar with your implementation. A
lot of the functionality could be moved to PSCI-capable firmware.

-- 
Catalin