Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753099AbbFHOfX (ORCPT ); Mon, 8 Jun 2015 10:35:23 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([207.82.80.143]:7141 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752052AbbFHOfQ convert rfc822-to-8bit (ORCPT ); Mon, 8 Jun 2015 10:35:16 -0400 Date: Mon, 8 Jun 2015 15:35:13 +0100 From: Liviu Dudau To: "Jon Medhurst (Tixy)" Cc: Sudeep Holla , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-clk@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Lorenzo Pieralisi , 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: <20150608143513.GI12807@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> <1433771479.2882.44.camel@linaro.org> MIME-Version: 1.0 In-Reply-To: <1433771479.2882.44.camel@linaro.org> User-Agent: Mutt/1.5.22 (2013-10-16) X-OriginalArrivalTime: 08 Jun 2015 14:35:14.0288 (UTC) FILETIME=[54F26F00:01D0A1F8] X-MC-Unique: WKJ6hzQpR8KYU2I0L4eQGQ-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: 2752 Lines: 76 On Mon, Jun 08, 2015 at 02:51:19PM +0100, Jon Medhurst (Tixy) wrote: > On Mon, 2015-06-08 at 11:40 +0100, Sudeep Holla wrote: > [...] > > + > > + 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"; > > From where do the clock names derive? They look more like names for > voltage domains rather than clocks. My (admittedly very old) Juno docs, > have the clocks as ATLCLK, APLCLK and GPUCLK. > > > + }; > > + scpi_clk: scpi_clocks@3 { > > + compatible = "arm,scpi-variable-clocks"; > > + #clock-cells = <1>; > > + clock-indices = <3>, <4>; > > + clock-output-names = "pxlclk0", "pxlclk1"; > > Can we also have clock index 5, name 'i2s_clk', for used by audio? > (I don't know what other clocks the SCP currently supports, but audio is > one being currently used by the out-of-tree code). > > Also, I believe that both display outputs share the same clock, and so > pxlclk0 and pxlclk1 can't be controlled independently. But I guess these > device-tree entries are for the interface to the SCP firmware, not the > hardware, and if that pretends the clocks are independent... Actually, they can be independent, but the other source for clock generation can only be used to drive a VGA resolution. We were just debating with Sudeep on how to expose this: at the moment the SCP is configured so that the request for a clock frequency always succeeds even if the other user of the clock is active. That means that if you have 2 monitors connected that have different resolutions or pixel clocks then one of the monitor will get out of sync (unless it is a VGA monitor). On the other hand the HDLCD driver (or more corectly the DRM KMS one) will default to 640x480 if no monitor is connected to an HDMI output, meaning the clock could already be used but by a driver that should really be inactive. It is very hard to detect in which situation we are, so the usual fix is "plug the monitor into the other HDMI output if you have problems with single monitors". Best regards, Liviu > > -- > Tixy > > -- ==================== | 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/