Hi Konstantin, On 20 November 2016 at 04:33, Konstantin Porotchkin <kos...@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 <s...@chromium.org> wrote: >> >> Hi Konstantin, >> >> On 15 November 2016 at 06:56, Konstantin Porotchkin <kos...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot