4.14 platform driver not loaded from ebi in device tree

[bdevos]

Hi,

We are migrating from linux 3.10 to 4.14.
On our custom board we have an FPGA connected via SMC in the EBI block.
The goal is to steer this from the device tree and from there load a platform driver. For some reason the platform driver is not loaded in 4.14, whereas it was in 3.10.

In 3.10 we used the following code (snippet):

Code: Select all

hsmc0: hsmc@ffffc600 { 
	compatible = "atmel,sama5d3-hsmc"; 
	reg = <0xffffc600 0x50>; 
	#address-cells = <2>; 
	#size-cells = <1>; 
	ranges = <0 0 0x10000000 0x01000000 
	1 0 0x40000000 0x01000000>; 
	status = "okay"; 

	p_s6@1,0 { 
	compatible = "agfa,p_s6"; 
	reg = <1 0 0x00000400>; 
	#address-cells = <2>; 
	#size-cells = <1>; 
	ranges; 

Whereas 'agfa,p_s6' is the compatible string to reflect the platform driver.
This is implemented in a file added in 'arch/arm/mach-at91' (with adapted Makefile to have it compiled into the kernel)

In the new device tree, there is a similar structure - full device tree available in patches

Code: Select all

ebi@ffffc600 { 
	compatible = "atmel,sama5d3-ebi"; 
	#address-cells = <2>; 
	#size-cells = <1>; 
	atmel,smc = <&hsmc>; 
	reg = <0xffffc600 0x50>; 
	ranges = < 
		0 0 0x10000000 0x01000000 
		1 0 0x40000000 0x01000000>; 
	clocks = <&mck>; 
	status = "okay"; 

	pinctrl-names = "default"; 
	pinctrl-0 = <&pinctrl_s6>; 

	p_s6@1,0 { 
		compatible = "agfa,p_s6"; 
		#address-cells = <2>; 
		#size-cells = <1>; 
		reg = <1 0 0x00000400>; 
		ranges; 

However in this case the platform driver is not loaded.

I did try to move the 'p_s6' node to somewhere else - being higher in the tree hierarchy and not a child of the 'ebi' node. The platform driver is at lease probed then, but it requires the parent's clock so later on it fails.

So my question is: what am I missing to load the platform driver correctly?
Any suggestions on how I could trace or debug this situation are welcome.

Some words on the patches :
The board we use is called 'conios', this might help in understanding some namings,
Some preliminary tests were done on the development board 'sama5d31ek'.
From an architecture point of view there is a platform driver as interface to the fpga, for each subsystem in the fpga a dedicated driver exist (which will have to come later).
There is also a character driver to load the fpga image.

Thanks in advance.

Kr,
Bart.

[blue_z]

The goal is to steer this from the device tree ...

"Steer this from the device tree "??!!
The DT does not control the loading (into memory) nor the order of initialization of any device drivers.
The Device Tree is only a data structure for describing the hardware and to provide configuration information.
The DT (through the compatibility string) does associate/specify a device driver to a device node.

... from there load a platform driver. For some reason the platform driver is not loaded in 4.14, whereas it was in 3.10.

What do you mean by "load"?
Is your driver a loadable module?
Or is your driver statically linked (aka built-in)?

In 3.10 we used the following code (snippet):

Code: Select all

hsmc0: hsmc@ffffc600 { 
	compatible = "atmel,sama5d3-hsmc"; 
        ...

First of all, a snippet of the DT with no context at all is not as informative as you think.
Second, what driver is associated with this compatibility string of "atmel,sama5d3-hsmc", which I cannot find in the 3.10-at91 source code?

This is implemented in a file added in 'arch/arm/mach-at91' (with adapted Makefile to have it compiled into the kernel)

That is definitely the wrong directory for your device driver.
Your FPGA is not integral to the SoC (i.e. it's a device external to the SoC), and is specific to just your board(s).
Also, if your driver is linked into the kernel, then there is no need to "load" it.

In the new device tree, there is a similar structure - full device tree available in patches

Code: Select all

ebi@ffffc600 { 
	compatible = "atmel,sama5d3-ebi"; 
	#address-cells = <2>; 
	#size-cells = <1>; 
	atmel,smc = <&hsmc>; 
	reg = <0xffffc600 0x50>; 
	ranges = < 
		0 0 0x10000000 0x01000000 
		1 0 0x40000000 0x01000000>; 
	clocks = <&mck>; 
	...

This DT node snippet has no context, but this is undoubtedly incorrect.
There should be no reason to subvert/replace the "ebi: ebi@10000000" (which already describes all four possible EBI chip selects) and "hsmc: hsmc@ffffc000" nodes in sama5d3.dtsi, which describes the generic SoC.
Depending on perspective, your node associates the wrong driver to the SMC peripheral or assigns the wrong attributes to the EBI driver.

So my question is: what am I missing to load the platform driver correctly?

A built-in driver does not need to be "loaded".
When the initcall of the (parent) EBI driver fails, the (child) node for your device would be invalidated. So there would be no initcall for your driver.
Did you review the kernel boot log for any error messages?

Any suggestions on how I could trace or debug this situation are welcome.

Apparently what you refer to as "load"ing is the sequence of invoking the initialization routine of drivers, aka the initcall phases of booting.
The Q&D debug mechanism to see the order of drivers called is to use the kernel command line parameter initcall_debug (along with something to ensure visibility, such as ignore_loglevel). See this topic.


Regards