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 76D01C43334 for ; Wed, 8 Jun 2022 01:47:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1390264AbiFHBq4 (ORCPT ); Tue, 7 Jun 2022 21:46:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46146 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1574447AbiFGXZo (ORCPT ); Tue, 7 Jun 2022 19:25:44 -0400 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1AEB03798FF for ; Tue, 7 Jun 2022 14:36:18 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id u12-20020a17090a1d4c00b001df78c7c209so22043098pju.1 for ; Tue, 07 Jun 2022 14:36:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=+tlXHJz9kisGrwJfIL/WMzkc1MTPDPH2NkDRgofMQXA=; b=CAQl78ghMWdgJpqs5v1tnPv/lepLaq6E6vHOQGSNFpzq0er9j5lbI4PgArppRnxI1i OhUHFhwQFCvy16F1fowJJ0nOReoDaAayxdilL8hHuOdrtYQOZkulXHx7HI4Tqfp0C+OG Vq9dE/RfMBMoIXhW6yIroAQ9UKNnH2hPxxa8k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=+tlXHJz9kisGrwJfIL/WMzkc1MTPDPH2NkDRgofMQXA=; b=0pRA/yoGoOIbLO8On/j1kewG9hKy8YihdrTqwxiJbMmGGxJxwOskO5Pv81CHlI04XM ZMbL3FT9UFzYgdwzGV1xTxo5ayCHJ0qP/kQQymm81aaJJZ/NOZHDXurDCJfMOy8o0YPT D61Op/m6sH0zHSVrGiaALLmdw+5qGgaEoU7KLAnS7Pj51xt3GZLWDDxE/vcntUa0fV/A UmRzCtsRnYLZYH6FZeIAElsD0h82CsQPgCN4i7mc2acE8rgX0+beQT4X3mrcWcNiTSdr k+lRd2mp8hfSl7287hFT6W5POn5Z1vYIgR8BbLggVZGDAe/8eqCSgYMxmGKVoZc1/DpA bD4A== X-Gm-Message-State: AOAM533tW8EmFZMURwNpkJ522CTkI5r1svH7LcsFGn/A6Pdnt0H1jXY2 WX1ml0E3d9S0y4VuyTDaCSfiFw== X-Google-Smtp-Source: ABdhPJwOhl2xigdWsk9Ip1jYWJh9CMdZiN68xBIN0cOrLS7fUs1z4TCbxFVDM92Dxke6O0smj4+FAA== X-Received: by 2002:a17:902:9b8a:b0:163:d0ad:f9e8 with SMTP id y10-20020a1709029b8a00b00163d0adf9e8mr30304386plp.79.1654637777427; Tue, 07 Jun 2022 14:36:17 -0700 (PDT) Received: from google.com ([2620:15c:202:201:b689:cc5b:e6ad:930e]) by smtp.gmail.com with ESMTPSA id q21-20020a056a00085500b0051874318772sm5823056pfk.201.2022.06.07.14.36.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 14:36:16 -0700 (PDT) Date: Tue, 7 Jun 2022 14:36:14 -0700 From: Brian Norris To: Nicolas Dufresne Cc: Heiko Stuebner , linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, Hans Verkuil , Sebastian Fricke , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Ezequiel Garcia , stable@vger.kernel.org Subject: Re: [PATCH] arm64: dts: rockchip: Assign RK3399 VDU clock rate Message-ID: References: <20220607141535.1.Idafe043ffc94756a69426ec68872db0645c5d6e2@changeid> <253e2771abb13a3e62c07dfb0b420169bb572c2d.camel@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <253e2771abb13a3e62c07dfb0b420169bb572c2d.camel@collabora.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 07, 2022 at 05:20:41PM -0400, Nicolas Dufresne wrote: > Reviewed-by: Nicolas Dufresne Thanks! > My only doubt was if you really needed to duplicate that setting into gru- > scarlet.dtsi, but I've simply assumed the answer is yes, and that you already > checked that. I didn't explicitly test without modifying gru-scarlet.dtsi, but the unfortunate nature of these long monolithic assigned-clocks/assigned-clock-rates properties is that if you want to add or override one element in the array, you have to repeat (or override) all of them. And because rk3399-gru-scarlet.dtsi already overrides some of them, every additional change has to be reflected there. That's why it would be much nicer to be able to distribute the assignments to their various consumer nodes, but as noted in the commit message (because you mentioned it to me out-of-band ;) ), we can't do that. Regards, Brian