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

[bdevos]

Hi,

Thanks for your feedback.

To take some shortcut's, in the end you mentioned properly what i meant: my device driver was reaching it's initcall.

Second, what driver is associated with this compatibility string of "atmel,sama5d3-hsmc", which I cannot find in the 3.10-at91 source code?

You're right, according to the logs, this driver has been developed in-house, some time ago, by someone who already left ...
Off course this has put me on the wrong track ...

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.

Can it be the case that I would need 2 nodes in my board's device tree:
1) in the ebi node, a subnode to setup the bus-timings for CS1 (the one being used by the FPGA)
2) and another node as subnode in hsmc node, which would than contain my compatible string, which will invoke my initcall?

In the case that makes sense, is there any example available?
I'm struggling with assigning a subnode from hsmc to the required chip select.

Did you review the kernel boot log for any error messages?

I played around with the nodes in the device tree, sometimes revealing errors, sometimes without finding the rootfs on the nand, and there has been situations in which I got my initcall, but than failed to get the proper resources. I have a strong believe that the root cause is in my device tree, but I can't hit the nail.

btw; meanwhile I have switched to 4.19.25 from the kernel/stable branch. I assume the sama5d3 is fully supported there in mainline. Can someone confirm this please?

Thanks in advance,

Kr,
Bart.