[U-Boot] New UCLASS_PINCTRL driver - probe is not called for all nodes
Hi, All,
I am currently porting the Marvell (mvebu) pin control driver for Armada-8K family to the current u-boot sources. The Armada 8K SoC is a hybrid chip that contains several interconnected dies in a single package. Each such device (AP, CP0, CP1) has an independent pin controller with different memory mapping. The DTS for such configuration looks like the following: / { ap806 { config-space { pinctl: pinctl@6F4000 { ... }; }; }; cp110-master { config-space { cpm_pinctl: pinctl@44000 { ... }; }; }; cp110-slave { config-space { cps_pinctl: pinctl@44000 { ... }; }; }; };
I expect that my driver "probe" method will be called 3 times - one for every controller. However, according to my test, only the first controller is probed (pinctl@6F4000). Two others are listed in the DM tree, but are not active (not probed).
I can do a trick and sequentially call uclass_get_device() function for the UCLASS_PINCTRL type, causing all 3 controller to be probed and activated. However I think this is not the way it should work. Is my assumption wrong and such hybrid devices should use the above trick for bringing up all controllers in the package?
Thank you beforehand for your help Konstantin
Hi Konstantin,
On 15 November 2016 at 06:56, Konstantin Porotchkin kostap@gmail.com wrote:
Hi, All,
I am currently porting the Marvell (mvebu) pin control driver for Armada-8K family to the current u-boot sources. The Armada 8K SoC is a hybrid chip that contains several interconnected dies in a single package. Each such device (AP, CP0, CP1) has an independent pin controller with different memory mapping. The DTS for such configuration looks like the following: / { ap806 { config-space { pinctl: pinctl@6F4000 { ... }; }; }; cp110-master { config-space { cpm_pinctl: pinctl@44000 { ... }; }; }; cp110-slave { config-space { cps_pinctl: pinctl@44000 { ... }; }; }; };
I expect that my driver "probe" method will be called 3 times - one for every controller. However, according to my test, only the first controller is probed (pinctl@6F4000). Two others are listed in the DM tree, but are not active (not probed).
I can do a trick and sequentially call uclass_get_device() function for the UCLASS_PINCTRL type, causing all 3 controller to be probed and activated. However I think this is not the way it should work. Is my assumption wrong and such hybrid devices should use the above trick for bringing up all controllers in the package?
They should be activated automatically by devices that use them. This is the pinctrl-0 property in the device. Can you take a look at why that is not working?
Specifically, see pinctrl_select_state() in device_probe().
Regards, Simon
Hi, Simon,
Thank you for your reply. In order to activate pin control function using "pinctrl-0" property, the device driver itself has to be aware of the pin control existence, right? So if I put such property under SPI controller, the SPI controller driver has to handle call to the pin control driver methods, right?
However my current target is to trigger setup for all existent pin controllers regardless of the connected device entries. Unfortunately not all drivers are aware of the pin controller properties. For instance current SPI and I2C drivers does not trigger the pin controller "probe" method regardless of the "pinctrl-0" property presence in FDT.
Regards Konstantin
On Fri, Nov 18, 2016 at 3:14 AM, Simon Glass sjg@chromium.org wrote:
Hi Konstantin,
On 15 November 2016 at 06:56, Konstantin Porotchkin kostap@gmail.com wrote:
Hi, All,
I am currently porting the Marvell (mvebu) pin control driver for
Armada-8K
family to the current u-boot sources. The Armada 8K SoC is a hybrid chip that contains several interconnected dies in a single package. Each such device (AP, CP0, CP1) has an independent pin controller with different memory mapping. The DTS for such configuration looks like the following: / { ap806 { config-space { pinctl: pinctl@6F4000 { ... }; }; }; cp110-master { config-space { cpm_pinctl: pinctl@44000 { ... }; }; }; cp110-slave { config-space { cps_pinctl: pinctl@44000 { ... }; }; }; };
I expect that my driver "probe" method will be called 3 times - one for every controller. However, according to my test, only the first controller is probed (pinctl@6F4000). Two others are listed in the DM tree, but are not active (not probed).
I can do a trick and sequentially call uclass_get_device() function for the UCLASS_PINCTRL type, causing all 3 controller to be probed and activated. However I think this is not the way it should work. Is my assumption wrong and such hybrid devices should use the above trick for bringing up all controllers in the package?
They should be activated automatically by devices that use them. This is the pinctrl-0 property in the device. Can you take a look at why that is not working?
Specifically, see pinctrl_select_state() in device_probe().
Regards, Simon
Hi Konstantin,
On 20 November 2016 at 04:33, Konstantin Porotchkin kostap@gmail.com wrote:
Hi, Simon,
Thank you for your reply. In order to activate pin control function using "pinctrl-0" property, the device driver itself has to be aware of the pin control existence, right? So if I put such property under SPI controller, the SPI controller driver has to handle call to the pin control driver methods, right?
No, this happens automatically in device_probe().
However my current target is to trigger setup for all existent pin controllers regardless of the connected device entries. Unfortunately not all drivers are aware of the pin controller properties. For instance current SPI and I2C drivers does not trigger the pin controller "probe" method regardless of the "pinctrl-0" property presence in FDT.
Provided they have the correct properties in the DT, this should work without effort.
Regards Konstantin
On Fri, Nov 18, 2016 at 3:14 AM, Simon Glass sjg@chromium.org wrote:
Hi Konstantin,
On 15 November 2016 at 06:56, Konstantin Porotchkin kostap@gmail.com wrote:
Hi, All,
I am currently porting the Marvell (mvebu) pin control driver for Armada-8K family to the current u-boot sources. The Armada 8K SoC is a hybrid chip that contains several interconnected dies in a single package. Each such device (AP, CP0, CP1) has an independent pin controller with different memory mapping. The DTS for such configuration looks like the following: / { ap806 { config-space { pinctl: pinctl@6F4000 { ... }; }; }; cp110-master { config-space { cpm_pinctl: pinctl@44000 { ... }; }; }; cp110-slave { config-space { cps_pinctl: pinctl@44000 { ... }; }; }; };
I expect that my driver "probe" method will be called 3 times - one for every controller. However, according to my test, only the first controller is probed (pinctl@6F4000). Two others are listed in the DM tree, but are not active (not probed).
I can do a trick and sequentially call uclass_get_device() function for the UCLASS_PINCTRL type, causing all 3 controller to be probed and activated. However I think this is not the way it should work. Is my assumption wrong and such hybrid devices should use the above trick for bringing up all controllers in the package?
They should be activated automatically by devices that use them. This is the pinctrl-0 property in the device. Can you take a look at why that is not working?
Specifically, see pinctrl_select_state() in device_probe().
Regards, Simon
participants (2)
-
Konstantin Porotchkin -
Simon Glass