Compared to the previous generation IC, the MT8189 uses 34-bit iova
address-space (16GB) and requires a single clock configuration.
Therefore, add "mediatek,mt8189-jpgenc" compatible to the binding document.
Additionally, it corrects the inheritance for MT8188, aligning it
with MT8189 due to their shared architecture and 34-bit iova address
space (16GB) requirements.
Previously, MT8188 was incorrectly defined alongside SoCs with 32-bit
iova address-space (4GB), such as "mediatek,mtk-jpgenc". This mismatch
results in an ABI break, as MT8188 cannot function correctly under
the 32-bit iova address-space (4GB) configuration.
Key changes include:
- Introducing "mediatek,mt8189-jpgenc" as a new compatible string to
represent the correct architecture.
- Updating MT8188 to inherit from MT8189, ensuring proper support for
34-bit iova address-space (16GB).
- Add property "mediatek,larb" for MT8189 requirements.
- Improved formatting for better readability and consistency.
These changes ensure that both MT8188 and MT8189 are correctly supported
with the necessary 34-bit iova address-space (16GB), while maintaining
compatibility with their shared architecture.
Extensive internal review and testing have been conducted to validate
these changes and ensure compliance with DT binding standards.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-encoder.yaml | 29 ++++++++++++++-----
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
index 5b15f8977f67..3205ecbaa6c5 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
@@ -14,13 +14,24 @@ description: |-
properties:
compatible:
- items:
- - enum:
- - mediatek,mt2701-jpgenc
- - mediatek,mt8183-jpgenc
- - mediatek,mt8186-jpgenc
- - mediatek,mt8188-jpgenc
- - const: mediatek,mtk-jpgenc
+ oneOf:
+ - items:
+ - enum:
+ - mediatek,mtk-jpgenc
+ - items:
+ - enum:
+ - mediatek,mt8189-jpgenc
+ - items:
+ - enum:
+ - mediatek,mt2701-jpgenc
+ - mediatek,mt8183-jpgenc
+ - mediatek,mt8186-jpgenc
+ - const: mediatek,mtk-jpgenc
+ - items:
+ - enum:
+ - mediatek,mt8188-jpgenc
+ - const: mediatek,mt8189-jpgenc
+
reg:
maxItems: 1
@@ -34,6 +45,10 @@ properties:
items:
- const: jpgenc
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to the smi_larb node.
+
power-domains:
maxItems: 1
--
2.45.2
On Wed, Dec 24, 2025 at 11:17:20AM +0800, Jianhua Lin wrote: > Compared to the previous generation IC, the MT8189 uses 34-bit iova > address-space (16GB) and requires a single clock configuration. > Therefore, add "mediatek,mt8189-jpgenc" compatible to the binding document. > Additionally, it corrects the inheritance for MT8188, aligning it Two different issues. Don't mix them up. See submitting patches. > with MT8189 due to their shared architecture and 34-bit iova address > space (16GB) requirements. > Previously, MT8188 was incorrectly defined alongside SoCs with 32-bit > iova address-space (4GB), such as "mediatek,mtk-jpgenc". This mismatch > results in an ABI break, as MT8188 cannot function correctly under > the 32-bit iova address-space (4GB) configuration. > > Key changes include: How is this related to above? > - Introducing "mediatek,mt8189-jpgenc" as a new compatible string to > represent the correct architecture. Why are you repeating the same? > - Updating MT8188 to inherit from MT8189, ensuring proper support for > 34-bit iova address-space (16GB). > - Add property "mediatek,larb" for MT8189 requirements. > - Improved formatting for better readability and consistency. > > These changes ensure that both MT8188 and MT8189 are correctly supported > with the necessary 34-bit iova address-space (16GB), while maintaining > compatibility with their shared architecture. This is not a contest who writes the longest commit msg by repeating obvious things. > > Extensive internal review and testing have been conducted to validate > these changes and ensure compliance with DT binding standards. Really, no. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.