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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 12E98CA9EC0 for ; Mon, 28 Oct 2019 22:34:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D5A9B21835 for ; Mon, 28 Oct 2019 22:34:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=amarulasolutions.com header.i=@amarulasolutions.com header.b="n4p86Jog" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729119AbfJ1WeN (ORCPT ); Mon, 28 Oct 2019 18:34:13 -0400 Received: from mail-il1-f196.google.com ([209.85.166.196]:46705 "EHLO mail-il1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729099AbfJ1WeN (ORCPT ); Mon, 28 Oct 2019 18:34:13 -0400 Received: by mail-il1-f196.google.com with SMTP id m16so9598090iln.13 for ; Mon, 28 Oct 2019 15:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c2XX2oa9okl2tfpust4RUifahZHp7tb1+MoPm2u47Wc=; b=n4p86JogluIaUwX8lpVfKCl315ggHShPT/3PG9nmdvv6A+WmkcxoXlJ1p500UHclpZ V7orIaazLLn5Miq8ZaNeWiihu1+79cg9oAg+i/LcaIdcqZQ5iG4T4aVCMjo26c+Cdn97 r3IOx7w0Y6kNlL3cRfnacuWuUmSw1xh6YKtgE= 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=c2XX2oa9okl2tfpust4RUifahZHp7tb1+MoPm2u47Wc=; b=Dxai3oAQ6W9nzgVeYnCzq8rId/xeez8QDmLRGm7V0BaOryyFvZjY1fTkRBMIJbMBwp CNV6X132YMIuqgfiO/RHxy4kz8ic/ZhABpiiOmU1HQaE970MFTdDDxsHreXBR6984pne IisKQrgOiThwLTsKmPFyu6c7UIQl8e3OaHs9g5Wy2gH5Q+7aiEkJUqOj5SIZ7dkFB1Mz 9Sa7ZfLvDSin7hisLO4WFKL8fJe8hsxQC0pEdpeuKFpxpiq/AA0zeWU+48Lhl0pESK1L OLiLAzqv/+MjSXPRwbmsKUKDbIblVaD+E0T9Wl45+rl4Y4ndIecTOB6c90lzeZVpLPxO 5C5w== X-Gm-Message-State: APjAAAWJ9jEXuPLg62lUvErrP5P9k5XKFJfYP0BuggyXpPUEYR3QDqBO bfFMGe4tPKBlAYqx0EwqeNquk0JeLINri1aVhFehdQ== X-Google-Smtp-Source: APXvYqyCGJQl+HAm+sa8mYYJp4Wxr/m+y+g/6ntOZCrMubS4XyZUczCAk4EdzfbP8O6fyXYOHmttxwz3zGzyvqk0tc0= X-Received: by 2002:a92:99ca:: with SMTP id t71mr8413794ilk.61.1572302047950; Mon, 28 Oct 2019 15:34:07 -0700 (PDT) MIME-Version: 1.0 References: <20191025175625.8011-1-jagan@amarulasolutions.com> <20191025175625.8011-5-jagan@amarulasolutions.com> <20191028153427.pc3tnoz2d23filhx@hendrix> In-Reply-To: <20191028153427.pc3tnoz2d23filhx@hendrix> From: Jagan Teki Date: Tue, 29 Oct 2019 04:03:56 +0530 Message-ID: Subject: Re: [PATCH v11 4/7] drm/sun4i: dsi: Handle bus clock explicitly To: Maxime Ripard Cc: Chen-Yu Tsai , David Airlie , Daniel Vetter , Rob Herring , Mark Rutland , Michael Trimarchi , Icenowy Zheng , linux-sunxi , dri-devel , linux-arm-kernel , linux-kernel , devicetree , linux-amarula Content-Type: text/plain; charset="UTF-8" Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi Maxime, On Mon, Oct 28, 2019 at 9:06 PM Maxime Ripard wrote: > > On Fri, Oct 25, 2019 at 11:26:22PM +0530, Jagan Teki wrote: > > Usage of clocks are varies between different Allwinner > > DSI controllers. Clocking in A33 would need bus and > > mod clocks where as A64 would need only bus clock. > > > > To support this kind of clocking structure variants > > in the same dsi driver, > > There's no variance in the clock structure as far as the bus clock is > concerned. > > > explicit handling of common clock would require since the A64 > > doesn't need to mention the clock-names explicitly in dts since it > > support only one bus clock. > > > > Also pass clk_id NULL instead "bus" to regmap clock init function > > since the single clock variants no need to mention clock-names > > explicitly. > > You don't need explicit clock handling. Passing NULL as the argument > in regmap_init_mmio_clk will make it use the first clock, which is the > bus clock. Indeed I tried that, since NULL clk_id wouldn't enable the bus clock during regmap_mmio_gen_context code, passing NULL triggering vblank timeout.