From xen-devel-bounces@lists.xen.org Wed Nov 12 10:17:51 2014 Received: (at maildrop) by bugs.xenproject.org; 12 Nov 2014 10:17:51 +0000 Received: from lists.xen.org ([50.57.142.19]) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1XoUzn-0007Vz-On for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Wed, 12 Nov 2014 10:17:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XoUqJ-00087f-Uk; Wed, 12 Nov 2014 10:08:03 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XoUqH-00087X-OH for xen-devel@lists.xen.org; Wed, 12 Nov 2014 10:08:03 +0000 Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id E1/3E-26740-18133645; Wed, 12 Nov 2014 10:08:01 +0000 X-Env-Sender: Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1415786879!10810291!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.12.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20710 invoked from network); 12 Nov 2014 10:08:00 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 12 Nov 2014 10:08:00 -0000 X-IronPort-AV: E=Sophos;i="5.07,367,1413244800"; d="scan'208";a="191902285" Message-ID: <1415786876.25176.49.camel@citrix.com> From: Ian Campbell To: Julien Grall Date: Wed, 12 Nov 2014 10:07:56 +0000 In-Reply-To: <54623E3D.4060803@linaro.org> References: <1414579268.29975.13.camel@citrix.com> <1414579302-6692-18-git-send-email-ian.campbell@citrix.com> <21585.6188.366311.80971@mariner.uk.xensource.com> <1414672390.2064.31.camel@citrix.com> <54623E3D.4060803@linaro.org> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.12.7-1 MIME-Version: 1.0 X-DLP: MIA2 Cc: xen-devel@lists.xen.org, Ian Jackson , Stefano Stabellini Subject: Re: [Xen-devel] [PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Tue, 2014-11-11 at 17:50 +0100, Julien Grall wrote: > Hi, > > Somehow I missed this email. > > On 30/10/2014 13:33, Ian Campbell wrote: > > create ! > > title it arm: domain 0 disables clocks which are in fact being used > > thanks > > > > On Wed, 2014-10-29 at 16:39 +0000, Ian Jackson wrote: > >> Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"): > >>> This stops dom0 from messing with clocks which it should and is required on > >>> some platforms. It's harmless even when not needed. > >> > >> This is pretty odd. Doesn't this correspond to some kind of bug, in > >> the dom0 kernel perhaps ? > > > > dom0 is not aware that some clocks are actually in use (e.g. by the > > hypervisor), so the bug is probably in the lack of some interface to > > communicate this from Xen to dom0, or some other mechanism to gate this. > > In reality, Xen is only using the clock of the UART. Even though, I > think this would also happen with platform device passthrough. > > For the latter, it would be fairly easy via a PV drivers. But for > UART... gating the clock could be a nightmare because every platform > have their own way to enable/disable the clock. Futhermore, the clock > could be shared with multiple device... > > I'm wondering if we could expose the UART to DOM0 without marking as > disabled. It would avoid DOM0 to mess up the clock while everything > would be catch via the vuart implementation in Xen. Perhaps we could propagate any clock related properties from the UART node into the Xen hypervisor node (or a subnode)? The Xen Linux code would then consume those and mark the relevant clocks as in use. I've not looked into the clock bindings to know how plausible this might be. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel