Received: by 10.223.185.116 with SMTP id b49csp5834626wrg; Wed, 7 Mar 2018 19:44:51 -0800 (PST) X-Google-Smtp-Source: AG47ELtWAsRCRHktKV86EeynMIWSDkfdgymOLzh4eEPd280Ru6l9J2SZLTcmyWfRL/gL7kw64phF X-Received: by 10.99.125.79 with SMTP id m15mr19700064pgn.428.1520480691748; Wed, 07 Mar 2018 19:44:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520480691; cv=none; d=google.com; s=arc-20160816; b=VcXSjjuuw0bBo5dA8E3trl894CXA2Plv1s0I29krczYMGni3vMJBAiIi0b4Z5u0MgF IVSiFTg+IU1+LKpACJ2nOXs7DgpDde8ZOzBfySBO2N/9eEIMFXHGSXXkJuOV4A/HNzDs xKrJZ4HqnbA7VhX02S+wZq77+qKAfMlnqoQXaykxKLXoQxez2oN/KLvzhHT8i9aZ3OVm cz9anMvTInFRSUpbRbyNyvIdrCy3zvugO2pbnTZUl7KNZ1E62ITTKdHNMgwXJS1Yjn63 FDmcX3DmyZUho9aFRw1Ffhsv/b+0nuuYEGQomRsQbnct99pdJwyC2Q0yheSqYdIoe1lF EEpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=ZR7AtR4QudUlMrGe6b4OjGDQPA2MfuaQrzmH7l5+ga4=; b=A8okk7GC4ko/yoL2QOnjiJqsE7uo6K5oLpen5EBwugiC6qcwdxOW76RkcywOT/DKCi 8x6tFCcF20FqxZMyPs762usMu4qTJxGQo4SzmTT+CiA5REpZptloiBcgIxprjG3g88Ei XuV2rFbS2aRRFV++BKYJLT2PLPg18gmDME9P+Z1yzLq/hSfak2W+SXbGtpAO3/qiGXm9 hpkWmGnUAhbEtZYtvHVWeaIzOQ6Thn+2iGd4dUkDqt2N5tQMA0PQYIbJg4zOmvU/phSh DbKUnssW1RWBVTTdj0kCfL/+UqsKYuwSEHLGO7/CDbq5l6KQrfAuOCjfczADqT4vBIes /ghg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=mYCtuv9z; dkim=fail header.i=@jms.id.au header.s=google header.b=jabMPwTZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o11-v6si14082645pll.158.2018.03.07.19.44.37; Wed, 07 Mar 2018 19:44:51 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=mYCtuv9z; dkim=fail header.i=@jms.id.au header.s=google header.b=jabMPwTZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754946AbeCHDnM (ORCPT + 99 others); Wed, 7 Mar 2018 22:43:12 -0500 Received: from mail-qk0-f193.google.com ([209.85.220.193]:45547 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754577AbeCHDnK (ORCPT ); Wed, 7 Mar 2018 22:43:10 -0500 Received: by mail-qk0-f193.google.com with SMTP id r140so5294162qke.12; Wed, 07 Mar 2018 19:43:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZR7AtR4QudUlMrGe6b4OjGDQPA2MfuaQrzmH7l5+ga4=; b=mYCtuv9zqyfPPcBnI1NQoPBUuj9OvGO1M6HuthSrYJfnJUPzYxPcgaoJ9iDAuHt5J6 ZcoRchB7ZF123GN0IACXbq93BTPY6gi5I2/WGx8N3nCysslZCxoyxllMobuqsOxDEBQz SH/eSlp5hKqyvjpomteFWav5kvM/+zYdRqManJebnbfxCQ85/tVQogS0oamb+2aPZwUB 1djHF+biHqtwjWmAkk5X6S6PI7a8fDP9bxR7H1hnOT3mHpvTnsx2wmBtKd4VudgDOOoP YtDyWPaChqcuaGEXHKBkLmXQkhqiLaDSxjl04dUoTPDv38BN5bQPjPnqqSvAssthUTdq 0IrQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jms.id.au; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZR7AtR4QudUlMrGe6b4OjGDQPA2MfuaQrzmH7l5+ga4=; b=jabMPwTZminlErjcP1xG2ZSn2FJ9xFR/x0Bu6bCs30CD+MGyLmCxZwT2n05IxkBsHN VAnPT13LorK2rSAU8lUJCNymYIzpXao79mzkAVNJl3vCkVZ289htaR0NiB0Ow/BfqavT bM/msxJRcjQD6Ih7vMIcF8nS2FA/QWIalUB50= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZR7AtR4QudUlMrGe6b4OjGDQPA2MfuaQrzmH7l5+ga4=; b=NPNJBia4NER4k1ZvOah4kwn98kabmiZMy24KERpZGGCSfUCgj3aq+eRQ/kIdTdn84H o5cQmUF19CNRMN1bp9u5IXzW1mmRk3gub8Dxx06dtCBz3J898cLkjqhuikV7xuXGxNYf ydP7bV04gJOuucwcH3CIYZZfQ2NgBNYa39XV6/KwMLNeey0uuvHbURUT6/s8kC4jl915 ww+jutbtpUkVpjA3W7iw4ONpGnjoqGcQ7Sw7+fFOly0s5bLJvNDAzICHp7Ac7s7fhnX6 Pn3md7biRPGi/EAY1E5Zee6q4Zlx5fYqnNs5Eke3pKEp8Ci2fStF+R7zduCoaaFc1reT CMmQ== X-Gm-Message-State: AElRT7H8fitSE4ajb8cX0YwLKos+L0tZsZRkqf36vm+gcebDGF84FmZG 8QQCtDds5E4GWw+dh/xuJlSlT7qOm2DvigrrsSA= X-Received: by 10.55.187.199 with SMTP id l190mr37737529qkf.336.1520480589343; Wed, 07 Mar 2018 19:43:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.50.69 with HTTP; Wed, 7 Mar 2018 19:42:48 -0800 (PST) In-Reply-To: <1520440570-25280-1-git-send-email-eajames@linux.vnet.ibm.com> References: <1520440570-25280-1-git-send-email-eajames@linux.vnet.ibm.com> From: Joel Stanley Date: Thu, 8 Mar 2018 14:12:48 +1030 X-Google-Sender-Auth: Nu_Mnb4ZIm444V3iJ9g-iLaz54w Message-ID: Subject: Re: [PATCH] clk: aspeed: Prevent reset if clock is enabled To: Eddie James Cc: Linux Kernel Mailing List , linux-clk@vger.kernel.org, Michael Turquette , sboyd@kernel.org, Lei YU , Ryan Chen Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eddie, On Thu, Mar 8, 2018 at 3:06 AM, Eddie James wrote: > According to the Aspeed specification, the reset and enable sequence > should be done when the clock is stopped. The specification doesn't > define behavior if the reset is done while the clock is enabled. > > From testing on the AST2500, the LPC Controller has problems if the > clock is reset while enabled. > > Therefore, check whether the clock is enabled or not before performing > the reset and enable sequence in the Aspeed clock driver. > > Signed-off-by: Eddie James > --- > drivers/clk/clk-aspeed.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c > index 9f7f931..a13054d 100644 > --- a/drivers/clk/clk-aspeed.c > +++ b/drivers/clk/clk-aspeed.c > @@ -212,6 +212,12 @@ static int aspeed_clk_enable(struct clk_hw *hw) > u32 clk = BIT(gate->clock_idx); > u32 rst = BIT(gate->reset_idx); > u32 enval; > + u32 reg; > + > + /* Only reset/enable/unreset if clock is stopped */ > + regmap_read(gate->map, ASPEED_CLK_STOP_CTRL, ®); > + if (!(reg & clk)) > + return 0; This doesn't generalise to all of the clocks, as some clocks use set to disable. Perhaps we could do something like this: /* Only reset/enable/unreset if clock is stopped. The LPC clock on ast2500 has issues otherwise */ enval = (gate->flags & CLK_GATE_SET_TO_DISABLE) ? 0 : clk; regmap_read(gate->map, ASPEED_CLK_STOP_CTRL, ®); if ((reg & clk) == enval) { spin_unlock_irqrestore(gate->lock, flags); return 0; } I think we should also do this operation under the lock. Please cc Ryan Chen so he can confirm that this workaround is valid, and credit Lei who spent a lot of time investigating this issue. Perhaps "Root-caused-by". Cheers, Joel