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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2E62C6FA86 for ; Thu, 22 Sep 2022 13:27:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231426AbiIVN1r (ORCPT ); Thu, 22 Sep 2022 09:27:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52154 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231228AbiIVN1p (ORCPT ); Thu, 22 Sep 2022 09:27:45 -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 639B1E3EC2; Thu, 22 Sep 2022 06:27:43 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id x21so6524390edd.11; Thu, 22 Sep 2022 06:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=GfDOH3Jon3LZczj1G1VLJYGGbFNCEA02UiZeXWZy9+k=; b=hif0g0HseARCaUTv7LneolSToCeCpqwcD8FGLV/jJbP3gxyplN7LmjqI80BuO9Os9Q sswktMIzxvl/AVbE4k6P4qdrDa+/MdIYr2V5b5a5X3BZEuj7dONlbzOEeWORcNqAKqih 0iF1cRLKrthqqimysu9x8U05GYDaKiM4VKrUng7rC7R17nS4lucImmCQf7y17RbhDVnB vGjbQ6FbdYExu+be5WuTjg2CCxNwbXaAFzAyd60saH1doqta7PtD5CZjGjb04iACUL9q uPyAatDxEDIiwso2g+ubYr4ubEpG7N0wK1Bli2F9JrTIN/7B1OfRefvMvrTK8dJDvXt1 nNBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=GfDOH3Jon3LZczj1G1VLJYGGbFNCEA02UiZeXWZy9+k=; b=ymHaerePL76EDpTb3aJXXfPG44GTzHYHD3VQiO/x8Y7vpXB5JV5DyQ6ZvwHZ1T1L7o qA5jwWy7Jp7mI/G2XCvg3p4A5eWgGYOVbirIZ57z/l7uPWBP0CVnbjfwSepIjjhRt5W7 LLntUe0t+73aGOG83lBfMMu1xEowsVDIjGkgiANCSuPNOS676cjrKZa4gb3swW93bM+o B99D0iMfmngLhbGKM02OXBwktogeF9cpge8oil8qUwWFFjAulgAWKRLr6R6t8rJyOZKW 5Mbh6ruZQlqL0ysxB7NK4aKgH2hGcmo9eVxF5Bw2FFE/zsvs/35CfUxzhCQIOPNtmLm9 ZKAw== X-Gm-Message-State: ACrzQf1En7jC1FdczfJaqNfy4yj5YyQHKFUeRFpyfcxr+FnZ+n71FtyV YurwaH5Aoisi9aGEGkHYwk+luNiN4sMU/6kqL+E= X-Google-Smtp-Source: AMsMyM7ba5r7bm3C3G5a4yke+Lid3XcbkkD0mY3+g3iS/ETXCxmQqk09XieYxa+H5d0Rx3S6C1KgmoXrhfHfiW8b4y0= X-Received: by 2002:a05:6402:50d1:b0:452:899e:77c with SMTP id h17-20020a05640250d100b00452899e077cmr3385432edb.0.1663853261902; Thu, 22 Sep 2022 06:27:41 -0700 (PDT) MIME-Version: 1.0 References: <20220905230406.30801-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20220905230406.30801-4-prabhakar.mahadev-lad.rj@bp.renesas.com> In-Reply-To: From: "Lad, Prabhakar" Date: Thu, 22 Sep 2022 14:27:15 +0100 Message-ID: Subject: Re: [PATCH v2 3/4] media: platform: Add Renesas RZ/G2L MIPI CSI-2 receiver driver To: Geert Uytterhoeven Cc: Sakari Ailus , Laurent Pinchart , Lad Prabhakar , Mauro Carvalho Chehab , Rob Herring , Krzysztof Kozlowski , Philipp Zabel , Jacopo Mondi , =?UTF-8?Q?Niklas_S=C3=B6derlund?= , Hans Verkuil , linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Biju Das Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Geert, On Thu, Sep 22, 2022 at 1:51 PM Geert Uytterhoeven wrote: > > On Thu, Sep 22, 2022 at 2:34 PM Sakari Ailus > wrote: > > On Thu, Sep 22, 2022 at 01:08:33PM +0100, Lad, Prabhakar wrote: > > > > > * Switched to manually turn ON/OFF the clocks instead of pm_runtime so that > > > > > the mipi/dhpy initialization happens as per the HW manual > > > > > > > > That doesn't look right. The driver doesn't use runtime PM anymore, so > > > > power domains may not be handled properly. What was the problem with > > > > clock handling using runtime PM ? > > > > > > > If we use the runtime PM all the clocks will be turned ON when we call > > > pm_runtime_resume_and_get() which I dont want to. As per the "Starting > > > reception for MIPI CSI-2 Input" section 35.3.1 for example we first > > > need to turn ON all the clocks and later further down the line we need > > > to just turn OFF VCLK -> Enable Link -> turn ON VCLK. Due to such > > > cases I have switched to individual clock handling. > > > > If that is the case, then you should control just that clock directly, > > outside runtime PM callbacks. > > > > Runtime PM may be needed e.g. for resuming a parent device. > > Exactly. > So probably you should not consider R9A07G044_CRU_VCLK a PM clock, > i.e. you need changes to rzg2l_cpg_is_pm_clk() to exclude it. > Thanks for the pointer. In that case we will have to consider R9A07G044_CRU_VCLK and R9A07G044_CRU_SYSCLK as not PM clocks. Does the below sound good? - DEF_NO_PM() macro - bool is_pm_clk in struct rzg2l_mod_clk. I still have to implement it, just wanted your opinion beforehand. Cheers, Prabhakar