Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp1050202ybg; Sat, 26 Oct 2019 11:59:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqy8uLDbab6Bp/Firzv66ufOuAugGuhpziB6s37lNFTDXkQmuSUU/O1JoVmseirUPR6G9MZT X-Received: by 2002:a17:906:9418:: with SMTP id q24mr9096735ejx.28.1572116360218; Sat, 26 Oct 2019 11:59:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572116360; cv=none; d=google.com; s=arc-20160816; b=elHvpDeS+I9WmezvnTExpwqb4N0JfDapf7Voll3wPuE5h/u5rJJVgw2qBc0RVwsGLO iPPpdpyXyWBWM/C2yKv+w/q29hQvc975sE7wBb3snoNMDaxTPk/bapidBTP1RJgQGIoW HjdQHtdm/G/iJf80PfLvZuORjsASSo3pSrPsSc4IQi//WmsnzVnTozKEaR33vQmCcmM3 KfYb9nTVEBzbcC0WdHEI66D+gxN5ERLInB8uVOPF5ZfkwXsZjugHALEqId7+xuoY7ZCZ dRtiPAODGHrU/XtjzJAaJhTjbyeFd+0VpZUvo4vmDd/zMAa02SN24wBgoOjm8Mg/zBqZ abDw== 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 :in-reply-to:references:mime-version:dkim-signature; bh=x7cDLkomUpCufb0t+qyZB5k3lTMumkzgQK5hQePCbK8=; b=iG4dbwpJIOmRo9KDQzRTJw0WnPJrP29fBs4xjD/Rc06lpcVOCz37AvSqnHEiyKg4Ws r0A/Ty4QSoEu5mZGCXjqWpZQVDOE1VhfPhluKi7oopqc8AqZRlSEVmPjTrP+ihJ5tb9p efgm89ohXAkmtfQTXutAe69Xd8RXc6xLtLjnoylL4L9IOECFJOcMlHIF1fn2V3CUfJ2v hktMeyGtMmx4u3RBu2PntlYodZuthV0/FcJShmE9rhEHJ4pxyd7p/k4YVud/HlHspzWR vUT6yyLxo5wSsmaDEfmzFIh7yvOcTQ03IvmYQAu0fHtbgU57x7fvUaqwFkvC1AiCaOQQ 74nQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IiNuPZq9; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id oq14si3490711ejb.76.2019.10.26.11.58.56; Sat, 26 Oct 2019 11:59:20 -0700 (PDT) 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=pass header.i=@gmail.com header.s=20161025 header.b=IiNuPZq9; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726494AbfJZS4P (ORCPT + 99 others); Sat, 26 Oct 2019 14:56:15 -0400 Received: from mail-io1-f68.google.com ([209.85.166.68]:38391 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726179AbfJZS4P (ORCPT ); Sat, 26 Oct 2019 14:56:15 -0400 Received: by mail-io1-f68.google.com with SMTP id u8so6140872iom.5; Sat, 26 Oct 2019 11:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x7cDLkomUpCufb0t+qyZB5k3lTMumkzgQK5hQePCbK8=; b=IiNuPZq9yOuXf1VfOCRxN3XTRjVfgIswJpmackxKJ+RenfnfpCjtW1Ud7cxLQ/lBxr VpI6Sb4Mno24tjICFANt0nuXewNbHbnxYmwxMWhhsOiRrWBVY9I4wIjxsxiBXNaWV5rk rCmzNvFfcIjLRR0ErYIbxMxsIKnNvawWFgc8sqXzEpAW9K0uIk0tfs+JvvFt3eXIx8NT 2BAUYTL7CuoU/KGV9bFCRpbr3RnjDJrVUvgeQreLI35JhfXU7sujKcKOtsNqCzmqtIC6 FV9QzTmoR8FXyR2d8s22Xy/UmGjxuB5FXFsPqdi+GmlVA3BtgHrnhrw4wjOdHOuXCU0W JALQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x7cDLkomUpCufb0t+qyZB5k3lTMumkzgQK5hQePCbK8=; b=JR9uF8kvDIVI5grA/93LgioO3br0eyr1VWKO5tu/cue0CUJNisg7/uioQTHBGmbc6R Ky7ejw7dJYccCi0YJLIkDUHhESlJ1z/9wzdvq6ylftav7WonC6Q2iAvz/D8SDmUruevX ueKwIxoXpGxderAnSN66A0INJhZD3oslPgCoPoo/MmA4K5/5LXEWzhkHquMyDkNWMPkT UWG14VnXlpEQ9OZ2wwIh0ouff1pWwmHVlUMeleJrJkNtDmud+XXRV+6FF+o8NmVwGG8n 5XqQMBb37Sl4XZpLhN7D4+ynEL2cQwmZtuciEVx0HivA+dL2hxqdwpzx7Zxs+nJ/Ku4T KTKw== X-Gm-Message-State: APjAAAXyTxVNd8wVWKQUNPc+aOG6SeVkBpZCRHbuFFfkRV/+S3x+lPY4 uAtVOEV4g7LWXW+2ROVVOUYwfbqsSGkN79UfHEQ= X-Received: by 2002:a05:6602:2428:: with SMTP id g8mr10205784iob.246.1572116174047; Sat, 26 Oct 2019 11:56:14 -0700 (PDT) MIME-Version: 1.0 References: <20191007131649.1768-1-linux.amoon@gmail.com> <20191007131649.1768-6-linux.amoon@gmail.com> <7hsgo4cgeg.fsf@baylibre.com> <1jwode9lba.fsf@starbuckisacylon.baylibre.com> <1a98c5f0-de8a-53bc-cfb7-c9b3255667c6@baylibre.com> In-Reply-To: From: Anand Moon Date: Sun, 27 Oct 2019 00:26:03 +0530 Message-ID: Subject: Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y To: Neil Armstrong Cc: Martin Blumenstingl , Jerome Brunet , Kevin Hilman , devicetree , linux-arm-kernel , linux-amlogic@lists.infradead.org, Linux Kernel 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 Neil, On Mon, 21 Oct 2019 at 21:11, Anand Moon wrote: > > Hi Neil, > > On Mon, 21 Oct 2019 at 19:55, Neil Armstrong wrote: > > > > Hi Anand, > > > > On 21/10/2019 16:11, Anand Moon wrote: > > > Hi Martin, > > > > > > On Fri, 18 Oct 2019 at 23:40, Martin Blumenstingl > > > wrote: > > >> > > >> Hi Anand, > > >> > > >> On Fri, Oct 18, 2019 at 4:04 PM Anand Moon wrote: > > >> [...] > > >>>> Next step it to try narrow down the clock causing the issue. > > >>>> Remove clk_ignore_unused from the command line and add CLK_INGORE_UNUSED > > >>>> to the flag of some clocks your clock controller (g12a I think) until > > >>>> > > >>>> The peripheral clock gates already have this flag (something we should > > >>>> fix someday) so don't bother looking there. > > >>>> > > >>>> Most likely the source of the pwm is getting disabled between the > > >>>> late_init call and the probe of the PWM module. Since the pwm is already > > >>>> active (w/o a driver), gating the clock source shuts dowm the power to > > >>>> the cores. > > >>>> > > >>>> Looking a the possible inputs in pwm driver, I'd bet on fdiv4. > > >>>> > > >>> > > >>> I had give this above steps a try but with little success. > > >>> I am still looking into this much close. > > >> it's not clear to me if you have only tested with the PWM and/or > > >> FCLK_DIV4 clocks. can you please describe what you have tested so far? > > >> > > > Sorry for delayed response. > > > > > > I had just looked into clk related to SD_EMMC_A/B/C, > > > with adding CLK_IGNORE/CRITICAL. > > > Also looked into clk_summary for eMMC and microSD card, > > > to identify the root cause, but I failed to move ahead. > > > > > >> for reference - my way of debugging this in the past was: > > >> 1. add some printks to clk_disable_unused_subtree (right after the > > >> clk_core_is_enabled check) to see which clocks are being disabled > > >> 2. add CLK_IGNORE_UNUSED or CLK_IS_CRITICAL to the clocks which are > > >> being disabled based on the information from step #1 > > >> 3. (at some point I had a working kernel with lots of clocks with > > >> CLK_IGNORE_UNUSED/CLK_IS_CRITICAL) > > >> 4. start dropping the CLK_IGNORE_UNUSED/CLK_IS_CRITICAL flags again > > >> until you have traced it down to the clocks that are the actual issue > > >> (so far I always had only one clock which caused issues, but it may be > > >> multiple) > > >> 5. investigate (and/or ask on the mailing list, Amlogic developers are > > >> reading the mails here as well) for the few clocks from step #4 > > >> > > > > > > Thanks for you valuable suggestion. I have your patch to debug this > > > [0] https://patchwork.kernel.org/patch/9725921/mbox/ > > > > > > So from the fist step I could identify that all the clk were getting closed > > > after some core cpu clk was failing. Here is the log. > > > > > > step1: [1] https://pastebin.com/p13F9HGG > > > > > > so I marked these clk as CLK_IGNORE_UNUSED and finally > > > I made it to boot using microSD card. > > > > > > After this just I converted these CLK to CLK_IS_CRITICAL > > > as mostly these are used the CPU clk for now. > > > Here is boot log successful for as of now. > > > > > > Finally: [2] https://pastebin.com/qB6pMyGQ > > > > > > I know clk maintainer are against marking flags as *CLK_IS_CRITICAL* > > > But this is just the step to move ahead. > > > > Thanks for the extensive debug. > > > > > > > > Attach is my local clk and dts patch.Just for testing. > > > [3] clk_critical.patch > > > > > > Could you test with only the following changes: > > diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c > > index ea4c791f106d..f49f5463363e 100644 > > --- a/drivers/clk/meson/g12a.c > > +++ b/drivers/clk/meson/g12a.c > > @@ -298,6 +298,7 @@ static struct clk_regmap g12a_fclk_div2 = { > > &g12a_fclk_div2_div.hw > > }, > > .num_parents = 1, > > + .flags = CLK_IS_CRITICAL, > > }, > > }; > > > > @@ -672,7 +673,7 @@ static struct clk_regmap g12b_cpub_clk = { > > &g12a_sys_pll.hw > > }, > > .num_parents = 2, > > - .flags = CLK_SET_RATE_PARENT, > > + .flags = CLK_SET_RATE_PARENT | CLK_IS_CRITICAL, > > }, > > }; > > > I am blocked with my eMMC is not working with latest u-boot so that I could not verify that nothing break with this changes. Could you send this patch upstream with adding my. Tested-by: Anand Moon Best Regards -Anand