linux-kernel - Re: [PATCH v4 2/2] arm64: dts: Add Mediatek SoC MT2712 and evaluation board dts and Makefile

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 21 Jul 2017 13:52:39 +0200
From:   Matthias Brugger <matthias.bgg@...il.com>
To:     YT Shen <yt.shen@...iatek.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Marc Zyngier <marc.zyngier@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Mars Cheng <mars.cheng@...iatek.com>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-serial@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, srv_heupstream@...iatek.com
Subject: Re: [PATCH v4 2/2] arm64: dts: Add Mediatek SoC MT2712 and evaluation
 board dts and Makefile



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@...0f000 {
>>>>> +			compatible = "mediatek,mt2712-uart",
>>>>> +				     "mediatek,mt6577-uart";
>>>>> +			reg = <0 0x1000f000 0 0x400>;
>>>>> +			interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_LOW>;
>>>>> +			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@...02000 {
> [...]
>                  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