Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754918AbbBPDuH (ORCPT ); Sun, 15 Feb 2015 22:50:07 -0500 Received: from mx0a-0016f401.pphosted.com ([67.231.148.174]:51963 "EHLO mx0a-0016f401.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751600AbbBPDuF (ORCPT ); Sun, 15 Feb 2015 22:50:05 -0500 Date: Mon, 16 Feb 2015 11:46:58 +0800 From: Jisheng Zhang To: Antoine Tenart CC: "sebastian.hesselbarth@gmail.com" , "mturquette@linaro.org" , "sboyd@codeaurora.org" , Jimmy Xu , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 0/7] ARM: berlin: refactor the clock Message-ID: <20150216114658.4c37aac1@xhacker> In-Reply-To: <20150216113738.281f226a@xhacker> References: <1423845781-7480-1-git-send-email-antoine.tenart@free-electrons.com> <20150216113738.281f226a@xhacker> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-02-16_01:2015-02-13,2015-02-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1502160040 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2720 Lines: 69 Hi all, On Sun, 15 Feb 2015 19:37:38 -0800 Jisheng Zhang wrote: > Hi all, > > On Fri, 13 Feb 2015 08:42:54 -0800 > Antoine Tenart wrote: > > > Hi, > > > > Marvell Berlin SoCs have a chip control register set providing several > > individual registers dealing with various controllers (pinctrl, reset, > > clk). This chip controller is described by a single DT node since the > > individual registers are spread among the chip control register bank. > > > > Marvell Berlin also have a system control register set providing several > > individual registers for pinctrl or adc. > > There's no chip control IP. The HW just put some HW registers into the so > called "chip control" address space, the registers in this space are mostly > used for "control" purpose, but some are not. Take the clk as an example, > some clocks' registers are put into the system control register space, some > clocks' are not. > > So far, there are five type of clocks in Berlin (from the driver > programmer's point of view): > > 1. gate clocks. The clocks may share register. The clocks can only be gated > or ungated. > > 2. individual clocks. The clock doesn't share registers with each other. > The gate/ungate, clock source selection, clock divider etc. bits of each > clock are put into one individual register. one register per clock. > > 3. group clocks. The gate/ungate bits of these clocks are grouped into one > register, the clock source selection, clock divider bits of these clocks > are grouped into another one or two register. > > 4. plls. The pll doesn't share registers with each other. For example, > syspll, cpupll etc. one or two register per pll > > 5. fixed clock. the oscillator used for reference clock. > > In newer chips, there are no group clocks any more. So the driver code can > be more simpler and clean. > > So I think we'd better to implement drivers without the "chip control" > concept in mind. The previous clock patches reflect what the HW really does. > > https://lkml.org/lkml/2014/3/21/413 > > https://lkml.org/lkml/2014/4/24/624 To be honest, these two patches are what mrvl used internally. And for newer linux kernel version, we replaced the mainline clk driver with this mrvl specific one. > > > The above is just my humble opinions and the current berlin clk driver is > different with the previous one I dunno how can we handle this situation > now. I really need help! -- 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/