From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757483AbbJ2QGe (ORCPT ); Thu, 29 Oct 2015 12:06:34 -0400 Received: from mail-by2on0116.outbound.protection.outlook.com ([207.46.100.116]:11392 "EHLO na01-by2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750967AbbJ2QGc (ORCPT ); Thu, 29 Oct 2015 12:06:32 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=scottwood@freescale.com; Message-ID: <1446134778.701.374.camel@freescale.com> Subject: Re: [PATCH v6 22/22] of/platform: Defer probes of registered devices From: Scott Wood To: Tomeu Vizoso CC: Rob Herring , "linux-kernel@vger.kernel.org" , Stephen Warren , Javier Martinez Canillas , Greg Kroah-Hartman , Mark Brown , "Thierry Reding" , Alan Stern , "Rafael J. Wysocki" , "linux-arm-kernel@lists.infradead.org" , Dmitry Torokhov , "devicetree@vger.kernel.org" , Linus Walleij , "linux-acpi@vger.kernel.org" , Arnd Bergmann , linuxppc-dev , "Hu Mingkai-B21284" Date: Thu, 29 Oct 2015 11:06:18 -0500 In-Reply-To: References: <1442844182-27787-1-git-send-email-tomeu.vizoso@collabora.com> <1442844182-27787-23-git-send-email-tomeu.vizoso@collabora.com> <1445406845.701.55.camel@freescale.com> <1445467912.701.90.camel@freescale.com> <1445549230.701.116.camel@freescale.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.0-fta1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Originating-IP: [50.157.106.250] X-ClientProxiedBy: DM2PR21CA0036.namprd21.prod.outlook.com (25.161.137.174) To BLUPR03MB1476.namprd03.prod.outlook.com (25.163.81.18) X-Microsoft-Exchange-Diagnostics: 1;BLUPR03MB1476;2:QIrW4OJSYKWLXAUiHWmIo8eLp+sk4LRxO4pCOSHJ438Rf+sL9S5qfz1yCd1RXXdJNRcRp+4UnlWz5IQ/rmA+N7p9PK3RHq0tWttiLwIOU+EQHXYUmhMFPkl3MIu70UiQKKSV5vQVOPBIUsFLMrroN+WrdVoo0EXcpaKjzjcBAWA=;3:q2knmvVOtFRkMWtfaWocpTlePmYwxM21hDMyicwig7KcpsqTgLQL2QAuCU7f03tckSHAIjfDYDu1pJz1JuvF/TC0iVaCMmYQ9DE8O9WNH3S1zuCvPZQXdS9I91n383x9Fc8m5n6sVRudu7/QK83WWQ==;25:SPVT/xtq024+WsroZEiK8jWgovy+qX04pt6TsET2DXBwxaS9jk4B0CUUVmTNY1w0SoRu1KTamRNKC///c28gC2+c9uz0cFkk+UOrf1mZDZKoXqJlW04/z8eO/7OYAcZf4vHXrp7RQ1fKi2CrH0kWXSsoQvH6ZDC6n5Hax5aetoagC/ps/CGOoqeuH8Kx9xJwGLf8cJ726xh0Gp44saSWNQcC+7wh6oOkycpnlzdx4l2ajDr1SUTEwz66sS75qMFenn3WrDPo2NmI/NQM1TC3ww== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1476; X-Microsoft-Exchange-Diagnostics: 1;BLUPR03MB1476;20:xZUUwTmiL5eO+jtSX4bJoWu8lHdpd8MrU+5C7wqHFJptPDGBjgkUWMb5d2/Qwe20kjIggGrSC6k+OjRpy6UIf4KhW8QxYZNtB49Y3ZHiJBnQ25TaLeHzVLf9dt8Ez1POO72obwjqDg2drGNlfesqXdv6rzR/GfkyhLvzgaAfB3iz1L1sT6z8gIiMXTejOW9QbymL6K/SDh0uj1gH57MlYQhrXRasLaX7KJ3NSNOo6rGEwIMjz0XVnXvKtm1W6eqX3gj8ZxWeaY4BgFO0uKB0jh8vVJRLhXPswcBZXMeTAu50qrNVbVpTW3+MHspi3YUywLdn0eu6RECRNoDdFy2O4JUkdtYK3XaCt+H/4EJIHvLfKcrdOjvmpneqvppVRqi0nx6Zpx/SizpBlmPcpst36PtWFz7MBv9tdGYoXgD+0zJ/53Wdkzo+ZJ5Lruw5AKfPgH6rm39PU/CJr/Epa7N1frdbRJww0Gmw0eUaJll9mAedq9ctpjC5BdsHW3tF9hn4;4:jDTsIScaXN0yZS9GjUWpmRYdx4RgKNcvlMwLbPLDEMyoXY8EfYXYskeA+yiUpQkzg8PU8urOprnU76fbqN/5m5qwO2/GJvAF/IJs6cvHWwOvKD4cVxJ+OkpZ3osqc8XdqAJTXTy+YfrO64XnsecEfzjZjLkDcgd50GlncCzKfd8zzr/EDP7tD74L2yAjZYO0qjGuBvFuMyDiEFMkI3DsQVMIHtd/fo/tw17zTchFf99PmXC0fO8ZOceU5y5Er0srSYxEmdvfUZRSvbUd+nQiKEr9QR91+saZeRzh8xS2PR0rTjIbm0HlZdfS8Za7gugzxZ4vZZlNyLKzjL2pJliErbxfEb8mW2jxUNEcSZ5klw4M4U4Rr/3E9a+vMz8fHU9wTQMkQ90rrMRw//ZSfC1L6w== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(101931422205132); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(102215026);SRVR:BLUPR03MB1476;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1476; X-Forefront-PRVS: 0744CFB5E8 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(199003)(51914003)(24454002)(189002)(377454003)(377424004)(107886002)(5001960100002)(50466002)(33646002)(122386002)(47776003)(5008740100001)(66066001)(77096005)(189998001)(106356001)(110136002)(93886004)(2950100001)(40100003)(105586002)(4001150100001)(97736004)(42186005)(5820100001)(81156007)(19580395003)(103116003)(92566002)(86362001)(87976001)(36756003)(23676002)(50226001)(76176999)(5004730100002)(5007970100001)(50986999)(4001430100002)(101416001)(19580405001)(99106002);DIR:OUT;SFP:1102;SCL:1;SRVR:BLUPR03MB1476;H:snotra.local;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjAzTUIxNDc2OzIzOnB1K0c5SDJEazY5MWUvYUgyQkhJT3dKUFlT?= =?utf-8?B?bDh2WitZVjBUN1VsK1hWWVltY1l4a1U1UTA1WmhMWUJLWG9lZWNGclRPV3I0?= =?utf-8?B?VUFlRTJUb0w4Tml4TEF0dmkrY3dOTGxENk1KbnhUaDdmS09iN2MveG1uTzNl?= =?utf-8?B?OGo4aHdWVlJybTlVVmMrSWFnSG9aR0JXQTNYaFNQZy9ZMXN6UDVIbUd5b3RY?= =?utf-8?B?U1MwRXNVOXY5d1JzSTNLWGpzM0Q4TDdtSkZ2dzI4Um8rK095dDUrekdoQzFL?= =?utf-8?B?NU0rYTBJS0RRN2owWmM4Qk13bGJPQ2RQbDZXR01VRERLS0kydmxBN1A2cjlK?= =?utf-8?B?Y2tETjlHRFB5TEVvaHNqOXI5UEdhOHlvejlnWVI4a2toeU9qbkkyOUdrMDM3?= =?utf-8?B?UHJRVlpDVURCSmVOYklhczI2ZlEzM2gxRUdxNWpsbU5UQkV2S2FTVFUxcm9N?= =?utf-8?B?bS9iQUdrRE80ai9WTzlsK3ZKRWlMcTdCT01PaXR5Y082bXltcHY1ZU9iWm5W?= =?utf-8?B?dFNZMGhUQUFSb056UTNPZmQ0d3p0YXFBSHVRTlNyZGZaTHJGd3c0WmVYWHA2?= =?utf-8?B?SlhJbG5zS29YK0V3ODBVQm51aHFBOFBmZDdhcVJTWGkxUUp3NmhZMWpoelZo?= =?utf-8?B?czVYRDdmdHEyb1h3Ny92RytHNktJUUlVeEw2cEVSeHBJNDg2Z25yL3hSeEdy?= =?utf-8?B?dzZlcFZLTkJFRjROcHR0ZnJqYzE5aGlySXFxMDI1QlkvSUw2OEo0Q3FqdEM0?= =?utf-8?B?QXE4cy9hMEFhZkEvZ0d5ME8ybm82ZktkUUlTTjJqS2Rsd1hjTENjM2NhVXZS?= =?utf-8?B?Z0ovZGk0ZzZYUUl6R095VFZhVWlsUDFrejNNMFc2dThEWk5pZzFrTEN4WHR5?= =?utf-8?B?ZVZoQ210V1FaMWZNNUFNdE9QMzlxYVE5ZnZRd1pzS1R2OUNnclpIR3J4b1dF?= =?utf-8?B?RVdXbUwrYW5HSktwR2p6Z1BXOGovenJrMmJ0dWhzOVZIaURZVWp2VUpZZFNn?= =?utf-8?B?djcxSFo3VndwWjNlanhYLzV1L3JqY0JKbDFzcW9KK0xlN1oxY3RDSHI2SFVW?= =?utf-8?B?ZkU5b09RTG9jZU9PaEorN0FWT05kWUx1WDBjT1ZKeWJqcGUwSVEzMHVEYlZM?= =?utf-8?B?aGJscEJURHBIbGxrL3I1MmplMm1rQlBueUpJbGFGWWhtZG9aSVdyT0l0YUJl?= =?utf-8?B?VCtNTGNYbWFSSlc0QzAxdm9kUXM4Q3pDanl1dithTm9mQWVBRjJpWVU4MDVK?= =?utf-8?B?b2tzTzVIamtxQkNGR1ljSEI0UkhINmdPTGV6MlBTNjhFemFZWEEzbHg3Y2h0?= =?utf-8?B?eWlzT1BSTXJiNklZNnJxZklDZzZGc0ZaM2dVek8ybENQM0xrVFRCcm43WXdh?= =?utf-8?B?MG84c3dOSWJweWNBSVNHNWNGdTZRVUxIWEx0UWlHeVZCK3lZVm9UL3VhOG1a?= =?utf-8?B?cFZBUldPZktwb1lNdEU3dWErREcxSFJDTk92NEhXMFdBRll1N2RvekVKUkVj?= =?utf-8?B?QXVrT0hiUWJpeWMyWTFMU1NZQUxhYTVTRjBUZUY2SWoyVlBsTUZPejFRcW9W?= =?utf-8?B?eDdRQkpVcUhhV0VBRjVsNkF2cDN3UU4zeDh6MnNIZk95S0h1M00xUFlraDdN?= =?utf-8?Q?cDNgqWwt9mF/aN8ZG9J6?= X-Microsoft-Exchange-Diagnostics: 1;BLUPR03MB1476;5:RybZaWP5im2Xj2cdU/3nR0yPAwzrp9JMc0ULE1x4lwM5FiOBIx72Lx16FyLLpdfizrQGfF8nF1Qf2GkejxU7Dy1YCG2WC04FWY4i/OOXaLiYyCmjwIHrQtzzESGt+b354p4qLpN0+t6qMA488rJG5Q==;24:UatrWcg8AKQMs+MHV/JcQSTmc7fTmQVCWWG/JSMmtHkSzUlOJsKBpcrgtbYkNidCjmXMr3BgDijHvz6f3K+ORVa6OlIX8VtMirztn4ngFX8=;20:pCDc51qIga3L5SOxq1WAoSrt0dyipauP+vofacUaoN6MWQViv27oLo7nyTf9Rs/qCsGAy+/oD920bO298+k4kg== X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Oct 2015 16:06:27.7623 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1476 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2015-10-28 at 15:40 +0100, Tomeu Vizoso wrote: > On 22 October 2015 at 23:27, Scott Wood wrote: > > On Thu, 2015-10-22 at 15:04 +0200, Tomeu Vizoso wrote: > > > On 22 October 2015 at 00:51, Scott Wood wrote: > > > > On Wed, 2015-10-21 at 08:44 -0500, Rob Herring wrote: > > > > > On Wed, Oct 21, 2015 at 12:54 AM, Scott Wood < > > > > > scottwood@freescale.com> > > > > > wrote: > > > > > > On Mon, 2015-09-21 at 16:03 +0200, Tomeu Vizoso wrote: > > > > > > > Instead of trying to match and probe platform and AMBA devices > > > > > > > right > > > > > > > after each is registered, delay their probes until > > > > > > > device_initcall_sync. > > > > > > > > > > > > > > This means that devices will start probing once all built-in > > > > > > > drivers > > > > > > > have registered, and after all platform and AMBA devices from > > > > > > > the DT > > > > > > > have been registered already. > > > > > > > > > > > > > > This allows us to prevent deferred probes by probing > > > > > > > dependencies on > > > > > > > demand. > > > > > > > > > > > > > > Signed-off-by: Tomeu Vizoso > > > > > > > --- > > > > > > > > > > > > > > Changes in v4: > > > > > > > - Also defer probes of AMBA devices registered from the DT as > > > > > > > they > > > > > > > can > > > > > > > also request resources. > > > > > > > > > > > > > > drivers/of/platform.c | 11 ++++++++--- > > > > > > > 1 file changed, 8 insertions(+), 3 deletions(-) > > > > > > > > > > > > This breaks arch/powerpc/sysdev/fsl_pci.c. The PCI bus is an OF > > > > > > platform > > > > > > device, and it must be probed before pcibios_init() which is a > > > > > > subsys_initcall(), or else the PCI bus never gets scanned. > > > > > > > > > > Thanks for the report. This is probably getting dropped, but it > > > > > could > > > > > be disabled for PPC. > > > > > > > > I don't think that adding another arbitrary arch difference would be > > > > the > > > > right solution. > > > > > > I think Rob meant temporarily disable it while things get fixed. At > > > least, > > > > So, what is the permanent fix for the swiotlb issue (or more generally, > > the > > inability to have a late_initcall that runs after non-module, non-hotplug > > platform devices have been probed)? > > If the code in pcibios_init() depends on the PCI bus device having > probed, then I would recommend making that dependency explicit by > calling of_device_probe() on the OF node of the PCI controller when > looking it up. "when looking it up"? pcibios_init() doesn't do anything with the OF node or know any details about the particular PCI bus host implementation. > > > I don't see any reason why PPC wouldn't benefit from this > > > series. > > > > It's not clear to me what the benefit of this is at all, much less for > > PPC. > > What is the fundamental problem with deferred probes? In the cover letter > > you say this change saves 2.3 seconds, but where is that time being > > consumed? > > Are the drivers taking too long in their probe function trying to > > initialize > > and then deferring, rather than checking for dependencies up front? Or > > are > > there really so many devices and such a pessimal ordering that most of the > > time is spent iterating through and reordering the list, with each defer > > happening quickly? > > The problem is that a device that defers its probe is currently sent > to the back of the queue, and that's undesired in some use cases in > which there's a device that should be up as soon as possible during > boot (and boot takes a long time). So the goal is to change the order > in which devices with dependencies end up probing. That doesn't answer my question about where the time is being spent. Did you profile? -Scott