From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D76CC433E0 for ; Thu, 18 Mar 2021 19:59:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0FF1664F4D for ; Thu, 18 Mar 2021 19:59:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232942AbhCRT6q (ORCPT ); Thu, 18 Mar 2021 15:58:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41910 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232949AbhCRT6V (ORCPT ); Thu, 18 Mar 2021 15:58:21 -0400 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CEFDC06174A for ; Thu, 18 Mar 2021 12:58:21 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id w18so8235684edc.0 for ; Thu, 18 Mar 2021 12:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gateworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5sxinzDiN1la62MYlJRjehM8ue8AVlNm8Yb/YIglQZ0=; b=wNBlcxWA9mQA/cvqLRPAnDgqExhTkYWTTPacOw+r8FKUWUjv65szQJrrLj51woi5Il GFyKUOCV0uQwdnlw7ZZs6LbdvixIinRu4xWtZNfIs/4HLjmXV2VHFbBrPlX+J7yA+Kz2 IEgjXiKKgfO0yWl3fXv+8f2roVRA6kdVf98R2kRzDkSQiY2RV+cVHiM5gyCaoTep+snR MZmGmlCX3BXGsq8s1TugCiw7re/1ffgtOXZFAnCifza67rXn1iRcnATPCkcfCwLrcI5t 9kYRkGdg2V1Cj6T0fOzSWCjoaoQwVmu+H+Wb5Cy3BhL/rLsFkpDxTQeCR/jtE+NEPlI4 NRTA== 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=5sxinzDiN1la62MYlJRjehM8ue8AVlNm8Yb/YIglQZ0=; b=PvEd+AlAQoQgBSXcmjmkdxNhT8YDn+fy5dV2cZ7adTFDBq5MexLewvgpBadfDdsogA 5XZ/21gkxq3s5Syva6R2h3lC7QwpQ2CNL2zmr83aWZbCm+TpZtYAp6TiR+kfyTz9B/Jk 36IYdSRBaRTGJZPkS2YUCLblwYCbPpKtF8R6OxjencNZMmrOru7h6TNHiRptBjZPj045 z/d032859pIZtbjLpZLiNd/NGW1t1hTmFIy2RrvS6wSQZ5sikVa6vhUJV+Kx6NvF4Qr8 QADHkP+31NXG6tyXfDuMBwG95SiEcteAvxFhYAq8Dag5ebjt4b2dp+O2KVEOfRAZnQP4 i3Aw== X-Gm-Message-State: AOAM532PQCEIs7HZ8Gsgplc4KIPzD8fGVdlwdaSjbNePP18lGi2dQgbi dTlburvVHmqXGWAY73FRS6skJcF0Lav4pmULHMSmNA== X-Google-Smtp-Source: ABdhPJxvIpU0efzVUcaO5hMfj1b5ZbFhUJvZKQjAxCnIbCN+8TyQzvbaigH1LcZv1BjFi2UK1tSVXc1mdvdxdSCLORU= X-Received: by 2002:a05:6402:3550:: with SMTP id f16mr5666092edd.134.1616097499821; Thu, 18 Mar 2021 12:58:19 -0700 (PDT) MIME-Version: 1.0 References: <1604402306-5348-1-git-send-email-abel.vesa@nxp.com> <1604402306-5348-11-git-send-email-abel.vesa@nxp.com> <20201117144828.omlwhu5y7cwsf5ci@fsr-ub1664-175> <6ecf593d-bee6-b0c1-718f-edcee90650ad@kontron.de> In-Reply-To: From: Tim Harvey Date: Thu, 18 Mar 2021 12:58:08 -0700 Message-ID: Subject: Re: [PATCH v5 10/14] clk: imx: Add generic blk-ctl driver To: Jacky Bai Cc: Frieder Schrempf , Abel Vesa , Dong Aisheng , Aisheng Dong , Rob Herring , Peng Fan , Philipp Zabel , Anson Huang , devicetree , Stephen Boyd , Adam Ford , Mike Turquette , Linux Kernel Mailing List , Marek Vasut , dl-linux-imx , Sascha Hauer , Fabio Estevam , Shawn Guo , linux-clk , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Lucas Stach Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 25, 2021 at 12:28 AM Jacky Bai wrote: > > > > > -----Original Message----- > > From: Frieder Schrempf [mailto:frieder.schrempf@kontron.de] > > Sent: Thursday, February 25, 2021 4:23 PM > > To: Abel Vesa ; Dong Aisheng > > Cc: Aisheng Dong ; Rob Herring ; > > Peng Fan ; Jacky Bai ; Anson Huang > > ; devicetree ; > > Stephen Boyd ; Shawn Guo ; > > Mike Turquette ; Linux Kernel Mailing List > > ; Marek Vasut ; > > dl-linux-imx ; Sascha Hauer ; > > Fabio Estevam ; Philipp Zabel > > ; Adam Ford ; linux-clk > > ; moderated list:ARM/FREESCALE IMX / MXC > > ARM ARCHITECTURE ; Lucas Stach > > > > Subject: Re: [PATCH v5 10/14] clk: imx: Add generic blk-ctl driver > > > > Hi Abel, > > > > On 17.11.20 15:48, Abel Vesa wrote: > > > On 20-11-11 17:13:25, Dong Aisheng wrote: > > >> On Tue, Nov 3, 2020 at 7:22 PM Abel Vesa wrote: > > >> ... > > >>> +static int imx_blk_ctl_reset_set(struct reset_controller_dev *rcdev, > > >>> + unsigned long id, bool assert) { > > >>> + struct imx_blk_ctl_drvdata *drvdata = container_of(rcdev, > > >>> + struct imx_blk_ctl_drvdata, rcdev); > > >>> + unsigned int offset = drvdata->rst_hws[id].offset; > > >>> + unsigned int shift = drvdata->rst_hws[id].shift; > > >>> + unsigned int mask = drvdata->rst_hws[id].mask; > > >>> + void __iomem *reg_addr = drvdata->base + offset; > > >>> + unsigned long flags; > > >>> + u32 reg; > > >>> + > > >>> + if (!assert && !test_bit(1, &drvdata->rst_hws[id].asserted)) > > >>> + return -ENODEV; > > >> > > >> What if consumers call deassert first in probe which seems common in > > kernel? > > >> It seems will fail. > > >> e.g. > > >> probe() { > > >> reset_control_get() > > >> reset_control_deassert() > > >> } > > >> > > >> Regards > > >> Aisheng > > >> > > > > > > OK, I'm trying to explain here how I know the resets are supposed to > > > be working and how the BLK_CTL IP is working. > > > > > > > > > First of, the BLK_CTL bits (resets and clocks) all have the HW init > > > (default) values as 0. Basically, after the blk_ctl PD is powered on, > > > the resets are deasserted and clocks are gated by default. Since the > > > blk_ctl is not the parent of any of the consumers in devicetree (the > > > reg maps are entirely different anyway), there is no way of ordering > > > the runtime callbacks between the consumer and the blk_ctl. So we > > > might end up having the runtime resume callback after the one from > > > EARC (consumer), for example, which will basically overwrite the value > > written by EARC driver with whatever was saved on suspend. > > > > > > Now, about the usage of the reset bits. AFAICT, it would make more > > > sense to assert the reset, then enable the clock, then deassert. This > > > way, you're keeping the EARC (consumer) in reset (with the clocks on) > > > until you eventually release it out of reset by deasserting. This is > > > how the runtime resume should deal with the reset and the clock. As > > > for the runtime suspend, the reset can be entirely ignored as long as you're > > disabling the clock. > > > > > > This last part will allow the blk_ctl to make the following assumption: > > > if all the clocks are disabled and none of the reset bits are asserted, I can > > power off. > > > > > > Now, I know there are drivers outthere that do assert on suspend, but > > > as long as the clocks are disabled, the assert will have no impact. > > > But maybe in their case the reset controller cannot power down itself. > > > > > > As for the safekeeping of the register, I'll just drop it due to the following > > arguments: > > > 1. all the clocks are gated by default 2. all resets are deasserted by > > > default 3. when blk_ctl goes down, all the consumers go down. (all > > > have the same PD) > > > > > > From 1 and 2 results the IP will not be running and from 3 results > > > the HW state of every IP becomes HW init state. > > > > Are there any plans to continue this work? As BLK-CTL it is not only relevant > > for the i.MX8MP, but also for i.MX8MM and i.MX8MN, it would be nice to get > > this ready in order to prepare for proper graphics/display support. > > > > Before continuing this work, we need to find out a way to resolve the cycling dependency issue between power domain and blk-ctrl. > it is indeed introduced some troubles in NXP latest internal release when the blk-ctrl driver is added. > Jacky, Any update on this? This is still blocking several drivers and major functionality of the i.MX8 SoC's in mainline and I would hope this would be a top priority for NXP. Best regards, Tim