Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751911AbdGULwq (ORCPT ); Fri, 21 Jul 2017 07:52:46 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:37389 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750777AbdGULwo (ORCPT ); Fri, 21 Jul 2017 07:52:44 -0400 Subject: Re: [PATCH v4 2/2] arm64: dts: Add Mediatek SoC MT2712 and evaluation board dts and Makefile To: YT Shen Cc: Rob Herring , Mark Rutland , Thomas Gleixner , Jason Cooper , Marc Zyngier , Greg Kroah-Hartman , Catalin Marinas , Will Deacon , Mars Cheng , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, srv_heupstream@mediatek.com References: <1498123975-9748-1-git-send-email-yt.shen@mediatek.com> <1498123975-9748-3-git-send-email-yt.shen@mediatek.com> <1500446884.14021.12.camel@mtksdaap41> <1500618746.14868.13.camel@mtksdaap41> From: Matthias Brugger Message-ID: <727069a0-7dd0-9d90-15bd-9005ecc793f7@gmail.com> Date: Fri, 21 Jul 2017 13:52:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1500618746.14868.13.camel@mtksdaap41> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2834 Lines: 95 On 07/21/2017 08:32 AM, YT Shen wrote: > On Wed, 2017-07-19 at 11:26 +0200, Matthias Brugger wrote: >> >> On 07/19/2017 08:48 AM, YT Shen wrote: >>> On Tue, 2017-07-18 at 18:29 +0200, Matthias Brugger wrote: >>>> >>>> On 06/22/2017 11:32 AM, YT Shen wrote: >>>>> This adds basic chip support for Mediatek 2712 >> >> [...] >> >>>>> + >>>>> + uart_clk: dummy26m { >>>>> + compatible = "fixed-clock"; >>>>> + clock-frequency = <26000000>; >>>>> + #clock-cells = <0>; >>>>> + }; >>>>> + >> >> [...] >> >>>>> + >>>>> + soc { >>>>> + #address-cells = <2>; >>>>> + #size-cells = <2>; >>>>> + compatible = "simple-bus"; >>>>> + ranges; >>>>> + >>>>> + uart5: serial@1000f000 { >>>>> + compatible = "mediatek,mt2712-uart", >>>>> + "mediatek,mt6577-uart"; >>>>> + reg = <0 0x1000f000 0 0x400>; >>>>> + interrupts = ; >>>>> + clocks = <&uart_clk>, <&uart_clk>; >>>>> + clock-names = "baud", "bus"; >>>>> + status = "disabled"; >>>>> + }; >>>> >>>> So baud and bus clock are both 26 MHz? >>> We didn't have CCF clock support in this series. >>> After we have clock source support, we could use the correct clocks to >>> the UARTs and drop the 26MHz fixed rate UART clock. >>> >>> The bus clock is 26MHz. The baud clock could be from another clock >>> source, using the same 26MHz fixed clock works also. >>> >>> >>> [1] https://patchwork.kernel.org/patch/9670877/ >>> [2] https://patchwork.kernel.org/patch/6436021/ >>> >> >> Yes, just using one 26 MHz clock works, but it uses an deprecated >> binding, so we should not do this, as through copying from the source of >> other SoCs we will keep it alive forever. Anyway that's not your case, >> as you defined the two clocks. >> >> The device tree should reflect the HW, that's why I asked for the clock >> frequency of both clocks. I searched the git history and it was never >> done right before. So you could be the first :) >> >> Thanks, >> Matthias > Ok, I want to make it clear. The following example > > baud_clk: dummy26m { > compatible = "fixed-clock"; > clock-frequency = <26000000>; > #clock-cells = <0>; > }; > > sys_clk: dummyclk { > compatible = "fixed-clock"; > clock-frequency = <26000000>; > #clock-cells = <0>; > }; > > uart0: serial@11002000 { > [...] > clocks = <&baud_clk>, <&sys_clk>; > [...] > } > > Do you think it is clear to reflect the HW that the baud clock and sys > clock can be different source or we need to choose another frequency? > Thanks. > Best would be to choose the frequency you expect from both clocks. E.g. the frequency set by the bootloader. If the clock is the same, then we can leave the patch as-is. Thanks, Matthias