Received: by 10.223.176.5 with SMTP id f5csp2430870wra; Thu, 1 Feb 2018 00:03:56 -0800 (PST) X-Google-Smtp-Source: AH8x227Q2x5fgQOzxdfYqkY9ewnHRFqF6vpB2lqWReh7f7jAnbKBlGY37K2VdGA+ODABp3aUjbpn X-Received: by 10.98.224.10 with SMTP id f10mr2042662pfh.205.1517472236498; Thu, 01 Feb 2018 00:03:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517472236; cv=none; d=google.com; s=arc-20160816; b=Bw8BL3lEwy7XhF/Qeprh/9Y9ZSqyKCY8LqaSDWRZQFJYbCfuQg5obCTmzVaUy1qQwb +MLeyI3itF8SkLLYN3kb5qQPEB6IXpmY0AIjQiYzi09R7976X8ugjRQVcBLe6rqzUszy d9V6b1X5Oq9tZk3SoZ6PDtaTr65n8/T2xcOu4DQs5ghMJfQJvBf6LNtgr1hV++xU+Y97 vfG4ECqqZlKl0kEh9IZIHgGpFSzCIt7Y0NKYBzsHcLXDWTWYyAFL0IaPKoOdpSRGqVOy 7L5LW7gjiAIPhyMtMCUScYNnhFaP9wjQFtXES9jPfo86rkQKiUF28qkxbBreBqMNp1vC 6fHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=DxJYu74E4K3myolcHSNcUBqaNL8pbFfWbdCxF1zfxdM=; b=JHYLMEaXFz6AZh8UFnqTIntG7lVfsRiiCjWUZKmyxbLt+91nawvs5NoSvNpzkrflUE tMBmKbUTE6+6UW0id7N5El24+EOC8uatL1TaMZuJQVE/geFiKi1jiKbDjOm1rJIU03Jo OUcJhLioCHnn1rCAnPEvRVdzO9MjNr3TZZGVLNd9/8yyCBq8mf8NOysG//CeNSNnJSe7 6YHs5XFD1qfGPF1olyrYeAi+EdswaYsjeh+pDAzMZqvGMoeUGaEUwsYyhPJVDs351imr H4WrPBeWFY9gL736xyszdfIRicDwPK8ff9Mt2/dVax/ornHLXEC/xCrva2urLzqSXv8A YEKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=imBVL6dr; 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; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j25si1170725pgn.600.2018.02.01.00.03.41; Thu, 01 Feb 2018 00:03:56 -0800 (PST) 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=@ti.com header.s=ti-com-17Q1 header.b=imBVL6dr; 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; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751811AbeBAICh (ORCPT + 99 others); Thu, 1 Feb 2018 03:02:37 -0500 Received: from fllnx209.ext.ti.com ([198.47.19.16]:23727 "EHLO fllnx209.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751650AbeBAICe (ORCPT ); Thu, 1 Feb 2018 03:02:34 -0500 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by fllnx209.ext.ti.com (8.15.1/8.15.1) with ESMTP id w11818Pe026521; Thu, 1 Feb 2018 02:01:08 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1517472068; bh=Mzlo64krLXdPJFSH4YpcuWdfxg4Jv2iqRxMuF8oE/kE=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=imBVL6drb1JuV6aLMQSWi46V9VP4aapcY3RAudi1EhvABw83EiV5tPCCxxRV9YZVP TGyaQtyoNB40hNrNN/sUDnCmVwc5YJwuEJpPyNZ5qpRmqvCvPCusCibo9NWb1H/WhT f5hBLghHNcaHHrOoZa6lpb87fkn+vSLIGYW53g9M= Received: from DLEE104.ent.ti.com (dlee104.ent.ti.com [157.170.170.34]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id w11818kP017481; Thu, 1 Feb 2018 02:01:08 -0600 Received: from DLEE108.ent.ti.com (157.170.170.38) by DLEE104.ent.ti.com (157.170.170.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Thu, 1 Feb 2018 02:01:07 -0600 Received: from dflp33.itg.ti.com (10.64.6.16) by DLEE108.ent.ti.com (157.170.170.38) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Thu, 1 Feb 2018 02:01:07 -0600 Received: from [172.24.190.171] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp33.itg.ti.com (8.14.3/8.13.8) with ESMTP id w118128L013827; Thu, 1 Feb 2018 02:01:04 -0600 Subject: Re: [PATCH v6 02/41] clk: davinci: New driver for davinci PLL clocks To: David Lechner , , , CC: Michael Turquette , Stephen Boyd , Rob Herring , Mark Rutland , Kevin Hilman , Bartosz Golaszewski , Adam Ford , References: <1516468460-4908-1-git-send-email-david@lechnology.com> <1516468460-4908-3-git-send-email-david@lechnology.com> From: Sekhar Nori Message-ID: Date: Thu, 1 Feb 2018 13:31:02 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1516468460-4908-3-git-send-email-david@lechnology.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Saturday 20 January 2018 10:43 PM, David Lechner wrote: > This adds a new driver for mach-davinci PLL clocks. This is porting the > code from arch/arm/mach-davinci/clock.c to the common clock framework. > Additionally, it adds device tree support for these clocks. > > The ifeq ($(CONFIG_COMMON_CLK), y) in the Makefile is needed to prevent > compile errors until the clock code in arch/arm/mach-davinci is removed. > > Note: although there are similar clocks for TI Keystone we are not able > to share the code for a few reasons. The keystone clocks are device tree > only and use legacy one-node-per-clock bindings. Also the register > layouts are a bit different, which would add even more if/else mess > to the keystone clocks. And the keystone PLL driver doesn't support > setting clock rates. > > Signed-off-by: David Lechner Looks nice and clean to me. There is still some feedback though. One thing missing is DIV4.5 clock. It will be nice to add that too, mostly just because it will make the binding complete. > +void of_davinci_pll_init(struct device_node *node, > + const struct davinci_pll_clk_info *info, > + const struct davinci_pll_obsclk_info *obsclk_info, > + const struct davinci_pll_sysclk_info *div_info, > + u8 max_sysclk_id) > +{ > + struct device_node *child; > + const char *parent_name; > + void __iomem *base; > + struct clk *clk; > + > + base = of_iomap(node, 0); > + if (!base) { > + pr_err("ioremap failed"); > + return; > + } > + > + if (info->flags & PLL_HAS_OSCIN) > + parent_name = of_clk_get_parent_name(node, 0); > + else > + parent_name = OSCIN_CLK_NAME; I don't think the reference clock input handling is fully correct/flexible. There are two ways to provide input clock (ref_clk) to PLL. Either use the internal oscillator with a crystal connected between OSCIN and OSCOUT (CLKMODE = 0) or a clean clock input (CLKMODE = 1) connected to OSCIN (OSCOUT disconnected). This is a board specific decision. On the LogicPD EVM, the former option is used, on the LCDK board, the later. So, I think what we need is a DT property like "ti,davinci-use-internal-osc" for the PLL. Boards can set or ignore it and you can switch CLKMODE on or off based on that. Setting CLKMODE = 1 will switch off the internal oscillator (and presumably save power), but it does not act as a mux. This explains why not worrying about setting this correctly in current mainline still works. I am also not sure if we really need PLL_HAS_OSCIN since all DaVinci SoCs set it anyway. Thanks, Sekhar