[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200514233759.GR4525@google.com>
Date: Thu, 14 May 2020 16:37:59 -0700
From: Matthias Kaehlcke <mka@...omium.org>
To: Sharat Masetty <smasetty@...eaurora.org>
Cc: freedreno@...ts.freedesktop.org, devicetree@...r.kernel.org,
dri-devel@...edesktop.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org, jcrouse@...eaurora.org,
georgi.djakov@...aro.org
Subject: Re: [PATCH 1/6] arm64: dts: qcom: sc7180: Add interconnect bindings
for GPU
Hi Sharat,
On Thu, May 14, 2020 at 04:24:14PM +0530, Sharat Masetty wrote:
> Subject: arm64: dts: qcom: sc7180: Add interconnect bindings for GPU
>
> This patch adds the interconnect bindings to the GPU node. This enables
> the GPU->DDR path bandwidth voting.
This patch doesn't add any bindings, it adds the interconnects/interconnect
configuration for the GPU
The order of the patches in this series is a bit odd. Typically you would
start with the binding changes ("dt-bindings: drm/msm/gpu: Document gpu
opp table" in this case), then the code needed to support these changes,
and finally the DT bits for the specific devices/platforms making use
of the new 'feature'.
It doesn't really matter once the series has landed since the end result
is exactly the same, however it's the logical order in which most
reviewers read your patches, and typically also the order in which the
patches land (especially when multiple trees are involved).
Powered by blists - more mailing lists