From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755460AbbBPJkP (ORCPT ); Mon, 16 Feb 2015 04:40:15 -0500 Received: from hqemgate15.nvidia.com ([216.228.121.64]:17067 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755256AbbBPJkO (ORCPT ); Mon, 16 Feb 2015 04:40:14 -0500 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Mon, 16 Feb 2015 01:39:35 -0800 Date: Mon, 16 Feb 2015 11:40:01 +0200 From: Peter De Schrijver To: Mikko Perttunen CC: , , , , , , , , , , , , , , Tuomas Tynkkynen Subject: Re: [PATCH v7 05/16] clk: tegra: Add DFLL DVCO reset control for Tegra124 Message-ID: <20150216094000.GD19839@tbergstrom-lnx.Nvidia.com> References: <1420723339-30735-1-git-send-email-mikko.perttunen@kapsi.fi> <1420723339-30735-6-git-send-email-mikko.perttunen@kapsi.fi> <20150212141944.GK20811@tbergstrom-lnx.Nvidia.com> <54DDD447.8000404@kapsi.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <54DDD447.8000404@kapsi.fi> X-NVConfidentiality: public User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [10.21.24.170] X-ClientProxiedBy: UKMAIL102.nvidia.com (10.26.138.15) To drukmail101.nvidia.com (10.25.59.19) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 13, 2015 at 12:39:03PM +0200, Mikko Perttunen wrote: > On 02/12/2015 04:19 PM, Peter De Schrijver wrote: > >On Thu, Jan 08, 2015 at 03:22:08PM +0200, Mikko Perttunen wrote: > >>From: Paul Walmsley > >> > >>The DVCO present in the DFLL IP block has a separate reset line, > >>exposed via the CAR IP block. This reset line is asserted upon SoC > >>reset. Unless something (such as the DFLL driver) deasserts this > >>line, the DVCO will not oscillate, although reads and writes to the > >>DFLL IP block will complete. > >> > >>Thanks to Aleksandr Frid for identifying this and > >>saving hours of debugging time. > >> > > > >Should this be done as a reset driver? > > Probably through the already existing CAR reset driver. This reset > doesn't fit well with the existing numbering scheme there, though. > Perhaps a magic high-valued constant that represents it. > Indeed. Just like only the lower part of the clock IDs map have a realtion with the hardware registers. The rest is just arbitrary numbers. Cheers, Peter.