Received: by 10.192.165.148 with SMTP id m20csp4329918imm; Tue, 24 Apr 2018 00:28:18 -0700 (PDT) X-Google-Smtp-Source: AIpwx49juZy/O0a+gsbN795BQ9TjeB8jI9w5lwVOeo0X6vx27yl212VoM23FLvgI9CX0NP/dSh0N X-Received: by 10.98.238.3 with SMTP id e3mr22856112pfi.232.1524554898778; Tue, 24 Apr 2018 00:28:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524554898; cv=none; d=google.com; s=arc-20160816; b=srLyQ1uLJvcS0Zv5L4SzBcLUWiDMWwcl8Hxd8cpE/AkygpG/9DlGY79SrBucfyWHra isYw0udjZhmepdYzn2UK+YZ71GLDbuO+AchpmPOxoF9/0N9LTy5GHFrgv8DV7+eZwjgg MYo8dXavW0w4WDtXx/jWbgVlr7Q4FXpzg93kDEv3FbFVmFHBL597EkKTSZbQ9scGi+sK 2+nbGElhQx1HBgoaipgyjoTLUQuWlBkxaQ+s1k98+YIw9yHEoJTU42nKQ/EqOJw5+kb6 unZsHt85C2jhhridtWp97zv/ito1rTV6detG+s9+pZw7hhGSca2SHAHc4L8r4yRxGLhe Dr+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=AuhnbuwFHQVKXS/ie/3HnQ7qVGGHq976YJQ4Nv6qN5c=; b=CyEko6bjg+6KKQMPTL0XDLvewWPgvjYcmta1trqqw8/o9U7yS2JXcUhlV75SG6UGvn JPC79fkeQ49PB/gb6Bg5LKlm7FW5QzTOajJossH9YIjramlO2NT2edcHNHILXZc2UFXZ MOyWLzQZNNMa0+aLljXfI6hsLFFziD6y0ZZ1c4d57QOt9iE3FabatZrYxwI0unX5Zk4E x0FTG/pBZTLRecXsJ6v0pXkQMTQ9UVYjXmRCNd8Cc5JT7zIcrVDGr4M6lXMbu5xtYKGn rh1rPosPCyrerRMmPQoTHedD6fknL509Ra4nz+PDtf9EEg57vzXF0dyhmvwNrzVxmYv/ MM2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=gAooYTtp; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x10-v6si13410386plv.563.2018.04.24.00.28.03; Tue, 24 Apr 2018 00:28:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@bgdev-pl.20150623.gappssmtp.com header.s=20150623 header.b=gAooYTtp; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756423AbeDXH0o (ORCPT + 99 others); Tue, 24 Apr 2018 03:26:44 -0400 Received: from mail-io0-f196.google.com ([209.85.223.196]:37720 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756372AbeDXH0j (ORCPT ); Tue, 24 Apr 2018 03:26:39 -0400 Received: by mail-io0-f196.google.com with SMTP id y128-v6so21518304iod.4 for ; Tue, 24 Apr 2018 00:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AuhnbuwFHQVKXS/ie/3HnQ7qVGGHq976YJQ4Nv6qN5c=; b=gAooYTtpg+kYzq/AuFdExhdmGoNaCH7bQvKoYRjXbaQtFsCgf6bOkEt7jrKpgDrFO8 HCmhOKA/aFW0i2jf3eHslyVCCHzD4M/Qo5NhhlhCocmlSQnEv3AFq3ZZcyFs/4SHSRAG 76Gg6dlZ9r+A0s4lU8n+cw87CJ4LUHqa0odCy2BheJwOlV2cMB1EuK7Gd6XTEardYk6A 99rscRpuyOE+qhL7Dos9C/pGTvIfhmv3pnWRO2lKLrv+UlwIZIZSX47DrQXQ7Ugr8Pwe AaEQkg1I+NBt8WCvAp2GRjX40v+jW4r5bvH+SUZyzCNTUJ03TekbUpkEpbOY+MlQmxpA l06A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AuhnbuwFHQVKXS/ie/3HnQ7qVGGHq976YJQ4Nv6qN5c=; b=UEZdHuVnXBgBs+pJuKEwzbgXLdORte3VwjXdFbIvmI+/+HJXB/IiXBGl+PQwmrMVPO OZG36nN8Qp9RnxTlRbBlfOm4k2D/+a09ZPYgLnmMbW4KH62Zon8cFFSKPUhGHp35Qsqd Fq0JnrK22el+uK/tb7RFB9nJ0tJ85Exky5L8SNT33GEW6sIK20pmCq52d1oRfh6Wfgrp id6wkE4AUUTogZvXBI7+P2GA2Xac3KKpibABrXRVFyAOBiIw1Ph0a67K2MDJR1Guwkj6 vyuSa2AF1abEeu3zHrxAaYJZNo+GNecXUVVpX7xy9WF2mIT03u0rgtqKLVjjI+r5BLnw 0rxQ== X-Gm-Message-State: ALQs6tCN432CPr7XmzUyA1VkTeLomXLsmlX0yRU3sifd1LVq9nYzWATW brV1o+BYxS5YoneOwpYfDATYut1g04UNSy/ezJ1L+A== X-Received: by 2002:a6b:c848:: with SMTP id y69-v6mr24946554iof.187.1524554798251; Tue, 24 Apr 2018 00:26:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.176.13 with HTTP; Tue, 24 Apr 2018 00:26:37 -0700 (PDT) In-Reply-To: References: <20180423183814.20615-1-brgl@bgdev.pl> From: Bartosz Golaszewski Date: Tue, 24 Apr 2018 09:26:37 +0200 Message-ID: Subject: Re: [RFC work-in-progress 0/7] of: platform: use early platform routines instead of OF_DECLARE To: David Lechner Cc: Sekhar Nori , Kevin Hilman , Michael Turquette , Arnd Bergmann , Greg Kroah-Hartman , Linux ARM , Linux Kernel Mailing List , Bartosz Golaszewski , Stephen Boyd Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2018-04-23 23:38 GMT+02:00 David Lechner : > FYI: It looks like the CC for Stephen and Arnd was messed up, so I > fixed. > Thanks! > On 04/23/2018 01:38 PM, Bartosz Golaszewski wrote: >> >> From: Bartosz Golaszewski >> >> Hi David, Sekhar, >> >> since platform devices are generally considered more desirable than >> CLK_OF_DECLARE, TIMER_OF_DECLARE etc. and we need to figure out how to >> handle the clocks that need to be initialized early in the boot >> process on DaVinci, I thought that I could give the early_platform >> mechanism a try. >> >> This API is only used on one architecture (sh) but seems to work just >> fine on ARM. It allows to register early platform drivers and then >> probe them early in the boot process. So far only machine code is >> supported but with a bit of hacking I was able to probe a DT device. >> >> This is a very dirty and far-from-upstream proof of concept that allows >> to probe the (so far dummy) davinci timer platform device during the >> call to init_time (from machine_desc). >> >> The idea is to have a special compatible fallback string: "earlydev" >> that similarily to "syscon" would be added to device nodes that need >> early probing. Then we'd call the of_early_platform_populate() >> function that would find all compatible nodes and populate them >> long before all the "normal" nodes. > > > FWIW, "earlydev" sounds like a driver implementation detail, so not > something that should be included in the device tree. We only need > this because Linux needs a clocksource early on, but that doesn't > mean that all device tree users need to do the same. > > I'm sure it makes things easier for a proof of concept though. :-) > We already have "syscon" which too is more an implementation detail than HW description. I should have probably Cc'ed Rob Herring. I'll do it with a more polished version I should have today. >> >> This would allow us to make the davinci timer a normal platform device >> and possibly also probe the psc and pll drivers earlier than we do now. >> >> The early platform API even allows us to check if we're being probed >> early in probe() so we can possibly probe the driver twice if needed: >> only doing the critical stuff first and then completing the process >> later. >> >> If you think this is a good idea, I would like to continue on that >> and eventually make it an alternative to OF_DECLARE macros. >> >> For a quick conversion of the davinci timer to a platform driver >> I image we'd need to use platform data lookup that would be passed >> to of_early_platform_populate(). > > > On the surface, it certainly sounds like a good idea to me. Do we have > access to struct device of the platform device when using this early > platform device? I remember when I was working on the clock drivers, I > tried registering a platform device in the init_time callback but the > kernel crashed because kobj stuff was not initialized yet. I'm guessing > that the early platform device somehow works around this. > Yes, it seems we do. I was getting kobj stack dumps too when trying to register a device using just platform_device_register() and it went away as soon as I switched to early platform. Best regards, Bartosz Golaszewski