On Thu, Jul 18, 2013 at 11:45:29AM -0700, Olof Johansson wrote: > Hi, > > On Thu, Jul 18, 2013 at 4:25 AM, Pavel Machek <pa...@denx.de> wrote: > > > It sound to me like keeping ammount of -EPROBE_DEFER to minimum is > > still preferred. > > Hand-crafting initcall level ordering of various drivers and subsystem > is probably an even greater evil though. We've done it in the past, > but now that we have deferred probe we have the option of not having > to do it every time, such as this. > > You're spending an awful lot of energy arguing over this, but nobody > has actually shown data of how much deferral is happening -- and that > it's a real problem. Until someone does so there's no reason to change > it from the default module init level at all, I'd say.
On imx6qdl-sabreauto board, there are 3 MAX7310 units as IO expanders to output 3 x 8 = 24 GPIOs. 18 of them are used for resets, enables and pin steering for various peripherals on the board. BACKLITE_ON SAT_SHUTDN_B CPU_PER_RST_B MAIN_PER_RST_B IPOD_RST_B MLB_RST_B SSI_STEERING GPS_RST_B GPS_PWREN VIDEO_ADC_PWRDN_B ENET_CAN1_STEER EIMD30_BTUART3_STEER CAN_STBY CAN_EN USB_H1_PWR USB_OTG_PWR_ON SAT_RST_B NAND_BT_WIFI_STEER Most of these GPIOs need to set up properly at client device driver's probe stage - module_init() time. So if we have all these service providers resets/enables/steering API registered at module_init() too, the probes of all these client device drivers stand a good chance to be deferred. Shawn _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
