On 06/07/2022 19:19, Krzysztof Kozlowski wrote:
On 06/07/2022 18:00, Dmitry Baryshkov wrote:
On 06/07/2022 18:50, Krzysztof Kozlowski wrote:
On 06/07/2022 16:52, Dmitry Baryshkov wrote:
The DT binding desribes using amd,imageon only for Imageon 2xx GPUs. We
have been using amd,imageon with newer (Adreno) GPUs to describe the
headless setup, when the platform does not (yet) have the display DT
Does not have "yet"? So later it will have and you drop a compatible?
Yes. For example see the arch/arm64/boot/dts/qcom/8150.dtsi, which
currently has only GPU node. Once we add MDSS/DPU/DSI/etc. nodes, we are
going to drop the compat string.
nodes (and no display support). Document this trick in the schema.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml
index 346aabdccf7b..e006da95462c 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.yaml
+++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml
@@ -16,9 +16,13 @@ properties:
- description: |
The driver is parsing the compat string for Adreno to
figure out the gpu-id and patch level.
+ Optional amd,imageon compatibility string enables using Adreno
+ without the display node.
items:
- pattern: '^qcom,adreno-[3-6][0-9][0-9]\.[0-9]$'
- const: qcom,adreno
+ - const: amd,imageon
+ minItems: 2
This is too unspecific. You allow any device to be and not to be
compatible with amd,imageon.
Yes, this is expected (kind of). Would you have any
alternatives/suggestions?
Using compatible for this kind of breaks the entire idea behind
compatibles, because the device does not stop being compatible with
amd,imageon. Either it is or it is not. I would understand that drop the
compatible per boards which physically do not have display, physically
are headless. But the comment in sm8250:
"make sure to remove it when display node is added"
is just confusing.
The typical solution would be to just check the properties of the device
and choose different mode if display is missing (via port graph or some
other way how the gpu is actually linked to the display).
The problem is that the gpu doesn't get linked to the display per se.
On imx5 platforms the GPU (compatible with amd,imageon) is a standalone
device. On qcom platforms the GPU (qcom,adreno) is used as a component
in multi-component device. By enlisting qmd,imageon for newer Adreno
devices we just enforce non-standard probing sequence, because all other
components just do not exist.
So, yes, this is hack around compatibles. However probably the only
viable alternative around it would be to check in probe path if there is
any device node compatible with "qcom,foo-mdss".
--
With best wishes
Dmitry
