Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934699AbbGVQGa (ORCPT ); Wed, 22 Jul 2015 12:06:30 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([207.82.80.143]:7932 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934467AbbGVQG2 convert rfc822-to-8bit (ORCPT ); Wed, 22 Jul 2015 12:06:28 -0400 Date: Wed, 22 Jul 2015 17:06:25 +0100 From: Liviu Dudau To: Sudeep Holla Cc: "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-clk@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Lorenzo Pieralisi , "Jon Medhurst (Tixy)" , Arnd Bergmann , Kevin Hilman , Olof Johansson Subject: Re: [PATCH v4 6/8] arm64: dts: add SRAM, MHU mailbox and SCPI support on Juno Message-ID: <20150722160625.GJ14923@e106497-lin.cambridge.arm.com> References: <1433760002-24120-1-git-send-email-sudeep.holla@arm.com> <1433760002-24120-7-git-send-email-sudeep.holla@arm.com> <20150722132809.GG14923@e106497-lin.cambridge.arm.com> <55AFB96E.1050406@arm.com> MIME-Version: 1.0 In-Reply-To: <55AFB96E.1050406@arm.com> User-Agent: Mutt/1.5.22 (2013-10-16) X-OriginalArrivalTime: 22 Jul 2015 16:06:25.0725 (UTC) FILETIME=[5C5A76D0:01D0C498] X-MC-Unique: fAhBWeN2RPKyNfOv79rnxg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3608 Lines: 100 On Wed, Jul 22, 2015 at 04:40:30PM +0100, Sudeep Holla wrote: > > > On 22/07/15 14:28, Liviu Dudau wrote: > > On Mon, Jun 08, 2015 at 11:40:00AM +0100, Sudeep Holla wrote: > >> This patch adds support for the MHU mailbox peripheral used on Juno by > >> application processors to communicate with remote SCP handling most of > >> the CPU/system power management. It also adds the SRAM reserving the > >> shared memory and SCPI message protocol using that shared memory. > >> > >> Cc: Liviu Dudau > >> Cc: Jon Medhurst (Tixy) > >> Signed-off-by: Sudeep Holla > >> --- > >> arch/arm64/boot/dts/arm/juno-base.dtsi | 31 +++++++++++++++++++++++++++++++ > >> arch/arm64/boot/dts/arm/juno-clocks.dtsi | 23 +++++++++++++++++++++++ > >> 2 files changed, 54 insertions(+) > >> > > [..] > > >> diff --git a/arch/arm64/boot/dts/arm/juno-clocks.dtsi b/arch/arm64/boot/dts/arm/juno-clocks.dtsi > >> index 25352ed943e6..64af7370815a 100644 > >> --- a/arch/arm64/boot/dts/arm/juno-clocks.dtsi > >> +++ b/arch/arm64/boot/dts/arm/juno-clocks.dtsi > >> @@ -42,3 +42,26 @@ > >> clock-frequency = <400000000>; > >> clock-output-names = "faxi_clk"; > >> }; > >> + > >> + scpi { > >> + compatible = "arm,scpi"; > >> + mboxes = <&mailbox 1>; > >> + shmem = <&cpu_scp_hpri>; > >> + > >> + clocks { > >> + compatible = "arm,scpi-clocks"; > >> + > >> + scpi_dvfs: scpi_clocks@0 { > >> + compatible = "arm,scpi-dvfs-clocks"; > >> + #clock-cells = <1>; > >> + clock-indices = <0>, <1>, <2>; > >> + clock-output-names = "vbig", "vlittle", "vgpu"; > >> + }; > >> + scpi_clk: scpi_clocks@3 { > >> + compatible = "arm,scpi-variable-clocks"; > >> + #clock-cells = <1>; > >> + clock-indices = <3>, <4>; > > > > Subject to you addressing Mark's comments regarding the indices values (maybe choose > > a different property to show the fact that the index is actually an SCPI index > > rather than the clock's), you can add my > > > > I don't understand why we need to do that. I will anyway follow up on > that thread. Because indices are per clock node, i.e. spi_clk should have clock-indices = <0>, <1>. Of course, you could have a gap in the indices, but that is both awkard and not clearly explained in this documentation. The index that you declare here is actually what you pass to SCPI. But the way the device tree is presented it declares that there are two clock blocks, one for DVFS and one for PXLCLK. As far as SCPI is concerned there is only one block of clocks, with 3 of them having a discrete set of values, so we are at the intersection of two concepts. BTW, for what is worth, the PXLCLK is not really that smooth in its coverage of the range. It might have more accepted frequency values, but the way it is implemented it tends to favour VESA clock values and falls back to a really slow algorithm to generate all other values. Even so, it can fail to find the correct parameters for the PLLs so it will generate a frequency that is different from the requested one. Best regards, Liviu > > > Acked-by: Liviu Dudau > > Thanks for all the ACKs. > > Regards, > Sudeep > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/