From: "Jason-JH.Lin" <redacted>
For previous MediaTek SoCs, such as MT8173, there are 2 display HW
pipelines binding to 1 mmsys with the same power domain, the same
clock driver and the same mediatek-drm driver.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines binding to
2 different power domains, different clock drivers and different
mediatek-drm drivers.
Moreover, Hardware pipeline of VDOSYS0 has these components: COLOR,
CCORR, AAL, GAMMA, DITHER. They are related to the PQ (Picture Quality)
and they makes VDOSYS0 supports PQ function while they are not
including in VDOSYS1.
Hardware pipeline of VDOSYS1 has the component ETHDR (HDR related
component). It makes VDOSYS1 supports the HDR function while it's not
including in VDOSYS0.
To summarize0:
Only VDOSYS0 can support PQ adjustment.
Only VDOSYS1 can support HDR adjustment.
Therefore, we need to separate these two different mmsys hardwares to
2 different compatibles for MT8195.
Fixes: 81c5a41d10b9 ("dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding")
Signed-off-by: Jason-JH.Lin <redacted>
Signed-off-by: Bo-Chen Chen <redacted>
---
Changes for v2:
1. Add hardware difference for VDOSYS0 and VDOSYS1 in commit message.
---
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Krzysztof Kozlowski <hidden> Date: 2022-08-25 10:18:27
On 25/08/2022 12:14, Bo-Chen Chen wrote:
From: "Jason-JH.Lin" <redacted>
For previous MediaTek SoCs, such as MT8173, there are 2 display HW
pipelines binding to 1 mmsys with the same power domain, the same
clock driver and the same mediatek-drm driver.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines binding to
2 different power domains, different clock drivers and different
mediatek-drm drivers.
Moreover, Hardware pipeline of VDOSYS0 has these components: COLOR,
CCORR, AAL, GAMMA, DITHER. They are related to the PQ (Picture Quality)
and they makes VDOSYS0 supports PQ function while they are not
including in VDOSYS1.
Hardware pipeline of VDOSYS1 has the component ETHDR (HDR related
component). It makes VDOSYS1 supports the HDR function while it's not
including in VDOSYS0.
To summarize0:
Only VDOSYS0 can support PQ adjustment.
Only VDOSYS1 can support HDR adjustment.
Therefore, we need to separate these two different mmsys hardwares to
2 different compatibles for MT8195.
Fixes: 81c5a41d10b9 ("dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding")
Signed-off-by: Jason-JH.Lin <redacted>
Signed-off-by: Bo-Chen Chen <redacted>
---
Acked-by: Krzysztof Kozlowski <redacted>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: "Jason-JH.Lin" <redacted>
For previous MediaTek SoCs, such as MT8173, there are 2 display HW
pipelines binding to 1 mmsys with the same power domain, the same
clock driver and the same mediatek-drm driver.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines binding to
2 different power domains, different clock drivers and different
mediatek-drm drivers.
Moreover, Hardware pipeline of VDOSYS0 has these components: COLOR,
CCORR, AAL, GAMMA, DITHER. They are related to the PQ (Picture Quality)
and they makes VDOSYS0 supports PQ function while they are not
including in VDOSYS1.
Hardware pipeline of VDOSYS1 has the component ETHDR (HDR related
component). It makes VDOSYS1 supports the HDR function while it's not
including in VDOSYS0.
To summarize0:
Only VDOSYS0 can support PQ adjustment.
Only VDOSYS1 can support HDR adjustment.
Therefore, we need to separate these two different mmsys hardwares to
2 different compatibles for MT8195.
Fixes: 81c5a41d10b9 ("dt-bindings: arm: mediatek: mmsys: add mt8195 SoC binding")
Signed-off-by: Jason-JH.Lin <redacted>
Signed-off-by: Bo-Chen Chen <redacted>
---
Changes for v2:
1. Add hardware difference for VDOSYS0 and VDOSYS1 in commit message.
---
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Thanks for you patch. As I mentioned on v1, I propose to set
mediatek,mt8195-mmsys as fallback for mediatek,mt8195-vdosys0 to not break
backwards compatibility.
Apart from that, the binding change will need some changes to support the new
binding. Please provide these together with this patch.
Regards,
Matthias
On Thu, 2022-08-25 at 22:57 +0800, Matthias Brugger wrote:
On 25/08/2022 11:14, Bo-Chen Chen wrote:
quoted
From: "Jason-JH.Lin" <redacted>
For previous MediaTek SoCs, such as MT8173, there are 2 display HW
pipelines binding to 1 mmsys with the same power domain, the same
clock driver and the same mediatek-drm driver.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines binding
to
2 different power domains, different clock drivers and different
mediatek-drm drivers.
Moreover, Hardware pipeline of VDOSYS0 has these components: COLOR,
CCORR, AAL, GAMMA, DITHER. They are related to the PQ (Picture
Quality)
and they makes VDOSYS0 supports PQ function while they are not
including in VDOSYS1.
Hardware pipeline of VDOSYS1 has the component ETHDR (HDR related
component). It makes VDOSYS1 supports the HDR function while it's
not
including in VDOSYS0.
To summarize0:
Only VDOSYS0 can support PQ adjustment.
Only VDOSYS1 can support HDR adjustment.
Therefore, we need to separate these two different mmsys hardwares
to
2 different compatibles for MT8195.
Fixes: 81c5a41d10b9 ("dt-bindings: arm: mediatek: mmsys: add mt8195
SoC binding")
Signed-off-by: Jason-JH.Lin <redacted>
Signed-off-by: Bo-Chen Chen <redacted>
---
Changes for v2:
1. Add hardware difference for VDOSYS0 and VDOSYS1 in commit
message.
---
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml |
3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
l
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
l
index 6ad023eec193..bfbdd30d2092 100644
---
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
l
+++
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
l
Thanks for you patch. As I mentioned on v1, I propose to set
mediatek,mt8195-mmsys as fallback for mediatek,mt8195-vdosys0 to not
break
backwards compatibility.
Apart from that, the binding change will need some changes to support
the new
binding. Please provide these together with this patch.
Regards,
Matthias
Hello Matthias,
Thanks for your comments.
The purpose of this patch is to confirm we can separate mt8195 mmsys
into two compatibles. I think this modification is accepted.
After this, I think Jason-JH will push another series with this binding
patch. In Jason-JH's series, we will modify mmsys driver based on this.
And I think we don't need to keep "mediatek,mt8195-mmsys" if we also
modify mmsys drivers in the same series.
Is it ok that postpones to pick this patch until we finish review
follow-up series?
BRs,
Bo-Chen
From: Krzysztof Kozlowski <hidden> Date: 2022-08-26 07:01:01
On 26/08/2022 05:07, Bo-Chen Chen wrote:
On Thu, 2022-08-25 at 22:57 +0800, Matthias Brugger wrote:
quoted
On 25/08/2022 11:14, Bo-Chen Chen wrote:
quoted
From: "Jason-JH.Lin" <redacted>
For previous MediaTek SoCs, such as MT8173, there are 2 display HW
pipelines binding to 1 mmsys with the same power domain, the same
clock driver and the same mediatek-drm driver.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines binding
to
2 different power domains, different clock drivers and different
mediatek-drm drivers.
Moreover, Hardware pipeline of VDOSYS0 has these components: COLOR,
CCORR, AAL, GAMMA, DITHER. They are related to the PQ (Picture
Quality)
and they makes VDOSYS0 supports PQ function while they are not
including in VDOSYS1.
Hardware pipeline of VDOSYS1 has the component ETHDR (HDR related
component). It makes VDOSYS1 supports the HDR function while it's
not
including in VDOSYS0.
To summarize0:
Only VDOSYS0 can support PQ adjustment.
Only VDOSYS1 can support HDR adjustment.
Therefore, we need to separate these two different mmsys hardwares
to
2 different compatibles for MT8195.
Fixes: 81c5a41d10b9 ("dt-bindings: arm: mediatek: mmsys: add mt8195
SoC binding")
Signed-off-by: Jason-JH.Lin <redacted>
Signed-off-by: Bo-Chen Chen <redacted>
---
Changes for v2:
1. Add hardware difference for VDOSYS0 and VDOSYS1 in commit
message.
---
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml |
3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
l
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
l
index 6ad023eec193..bfbdd30d2092 100644
---
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
l
+++
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yam
l
Thanks for you patch. As I mentioned on v1, I propose to set
mediatek,mt8195-mmsys as fallback for mediatek,mt8195-vdosys0 to not
break
backwards compatibility.
Apart from that, the binding change will need some changes to support
the new
binding. Please provide these together with this patch.
Regards,
Matthias
Hello Matthias,
Thanks for your comments.
The purpose of this patch is to confirm we can separate mt8195 mmsys
into two compatibles. I think this modification is accepted.
No, it is not accepted following Matthias comments. You received my ack
based on assumption that ABI break is perfectly ok for platform
maintainer, as he has decisive voice. If anyone is not happy with a ABI
break, then his concerns must be addressed.
So let it be specific:
NAK.
After this, I think Jason-JH will push another series with this binding
patch.
I don't know what do you mean here - another series on top of wrong patch?
In Jason-JH's series, we will modify mmsys driver based on this.
And I think we don't need to keep "mediatek,mt8195-mmsys" if we also
modify mmsys drivers in the same series.
This does not fux ABI break and broken bisectability.
Is it ok that postpones to pick this patch until we finish review
follow-up series?
On Fri, 2022-08-26 at 15:00 +0800, Krzysztof Kozlowski wrote:
On 26/08/2022 05:07, Bo-Chen Chen wrote:
quoted
On Thu, 2022-08-25 at 22:57 +0800, Matthias Brugger wrote:
quoted
On 25/08/2022 11:14, Bo-Chen Chen wrote:
quoted
From: "Jason-JH.Lin" <redacted>
For previous MediaTek SoCs, such as MT8173, there are 2 display
HW
pipelines binding to 1 mmsys with the same power domain, the
same
clock driver and the same mediatek-drm driver.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines
binding
to
2 different power domains, different clock drivers and
different
mediatek-drm drivers.
Moreover, Hardware pipeline of VDOSYS0 has these components:
COLOR,
CCORR, AAL, GAMMA, DITHER. They are related to the PQ (Picture
Quality)
and they makes VDOSYS0 supports PQ function while they are not
including in VDOSYS1.
Hardware pipeline of VDOSYS1 has the component ETHDR (HDR
related
component). It makes VDOSYS1 supports the HDR function while
it's
not
including in VDOSYS0.
To summarize0:
Only VDOSYS0 can support PQ adjustment.
Only VDOSYS1 can support HDR adjustment.
Therefore, we need to separate these two different mmsys
hardwares
to
2 different compatibles for MT8195.
Fixes: 81c5a41d10b9 ("dt-bindings: arm: mediatek: mmsys: add
mt8195
SoC binding")
Signed-off-by: Jason-JH.Lin <redacted>
Signed-off-by: Bo-Chen Chen <redacted>
---
Changes for v2:
1. Add hardware difference for VDOSYS0 and VDOSYS1 in commit
message.
---
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
|
3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
.yam
l
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
.yam
l
index 6ad023eec193..bfbdd30d2092 100644
---
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
.yam
l
+++
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
.yam
l
Thanks for you patch. As I mentioned on v1, I propose to set
mediatek,mt8195-mmsys as fallback for mediatek,mt8195-vdosys0 to
not
break
backwards compatibility.
Apart from that, the binding change will need some changes to
support
the new
binding. Please provide these together with this patch.
Regards,
Matthias
Hello Matthias,
Thanks for your comments.
The purpose of this patch is to confirm we can separate mt8195
mmsys
into two compatibles. I think this modification is accepted.
No, it is not accepted following Matthias comments. You received my
ack
based on assumption that ABI break is perfectly ok for platform
maintainer, as he has decisive voice. If anyone is not happy with a
ABI
break, then his concerns must be addressed.
So let it be specific:
NAK.
quoted
After this, I think Jason-JH will push another series with this
binding
patch.
I don't know what do you mean here - another series on top of wrong
patch?
Hello Krzysztof,
For this mt8195 mmsys binding separation, we still need to modify
driver for this. The reason I send this patch is to confirm we can do
this binding modification and I also think we can not pick this patch
here.
We will push another series and it contains modification of binding and
drivers. (The series will push by Jason-JH Lin)
Maybe I should use "RFC" for this series, and I think it's more
correct.
BRs,
Bo-Chen
quoted
In Jason-JH's series, we will modify mmsys driver based on this.
And I think we don't need to keep "mediatek,mt8195-mmsys" if we
also
modify mmsys drivers in the same series.
This does not fux ABI break and broken bisectability.
quoted
Is it ok that postpones to pick this patch until we finish review
follow-up series?
No. You got a clear review to fix.
Best regards,
Krzysztof
On Fri, 2022-08-26 at 15:00 +0800, Krzysztof Kozlowski wrote:
quoted
On 26/08/2022 05:07, Bo-Chen Chen wrote:
quoted
On Thu, 2022-08-25 at 22:57 +0800, Matthias Brugger wrote:
quoted
On 25/08/2022 11:14, Bo-Chen Chen wrote:
quoted
From: "Jason-JH.Lin" <redacted>
For previous MediaTek SoCs, such as MT8173, there are 2 display
HW
pipelines binding to 1 mmsys with the same power domain, the
same
clock driver and the same mediatek-drm driver.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines
binding
to
2 different power domains, different clock drivers and
different
mediatek-drm drivers.
Moreover, Hardware pipeline of VDOSYS0 has these components:
COLOR,
CCORR, AAL, GAMMA, DITHER. They are related to the PQ (Picture
Quality)
and they makes VDOSYS0 supports PQ function while they are not
including in VDOSYS1.
Hardware pipeline of VDOSYS1 has the component ETHDR (HDR
related
component). It makes VDOSYS1 supports the HDR function while
it's
not
including in VDOSYS0.
To summarize0:
Only VDOSYS0 can support PQ adjustment.
Only VDOSYS1 can support HDR adjustment.
Therefore, we need to separate these two different mmsys
hardwares
to
2 different compatibles for MT8195.
Fixes: 81c5a41d10b9 ("dt-bindings: arm: mediatek: mmsys: add
mt8195
SoC binding")
Signed-off-by: Jason-JH.Lin <redacted>
Signed-off-by: Bo-Chen Chen <redacted>
---
Changes for v2:
1. Add hardware difference for VDOSYS0 and VDOSYS1 in commit
message.
---
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
|
3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
.yam
l
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
.yam
l
index 6ad023eec193..bfbdd30d2092 100644
---
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
.yam
l
+++
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
.yam
l
Thanks for you patch. As I mentioned on v1, I propose to set
mediatek,mt8195-mmsys as fallback for mediatek,mt8195-vdosys0 to
not
break
backwards compatibility.
Apart from that, the binding change will need some changes to
support
the new
binding. Please provide these together with this patch.
Regards,
Matthias
Hello Matthias,
Thanks for your comments.
The purpose of this patch is to confirm we can separate mt8195
mmsys
into two compatibles. I think this modification is accepted.
No, it is not accepted following Matthias comments. You received my
ack
based on assumption that ABI break is perfectly ok for platform
maintainer, as he has decisive voice. If anyone is not happy with a
ABI
break, then his concerns must be addressed.
So let it be specific:
NAK.
quoted
After this, I think Jason-JH will push another series with this
binding
patch.
I don't know what do you mean here - another series on top of wrong
patch?
Hello Krzysztof,
For this mt8195 mmsys binding separation, we still need to modify
driver for this. The reason I send this patch is to confirm we can do
this binding modification and I also think we can not pick this patch
here.
We will push another series and it contains modification of binding and
drivers. (The series will push by Jason-JH Lin)
Sounds good. So lets wait for Jason-JH Lin to send this series and we can go on
with the review.
Thanks!
Matthias
Maybe I should use "RFC" for this series, and I think it's more
correct.
BRs,
Bo-Chen
quoted
quoted
In Jason-JH's series, we will modify mmsys driver based on this.
And I think we don't need to keep "mediatek,mt8195-mmsys" if we
also
modify mmsys drivers in the same series.
This does not fux ABI break and broken bisectability.
quoted
Is it ok that postpones to pick this patch until we finish review
follow-up series?
No. You got a clear review to fix.
Best regards,
Krzysztof
On Fri, 2022-08-26 at 15:00 +0800, Krzysztof Kozlowski wrote:
quoted
On 26/08/2022 05:07, Bo-Chen Chen wrote:
quoted
On Thu, 2022-08-25 at 22:57 +0800, Matthias Brugger wrote:
quoted
On 25/08/2022 11:14, Bo-Chen Chen wrote:
quoted
From: "Jason-JH.Lin" <redacted>
For previous MediaTek SoCs, such as MT8173, there are 2 display
HW
pipelines binding to 1 mmsys with the same power domain, the
same
clock driver and the same mediatek-drm driver.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines
binding
to
2 different power domains, different clock drivers and
different
mediatek-drm drivers.
Moreover, Hardware pipeline of VDOSYS0 has these components:
COLOR,
CCORR, AAL, GAMMA, DITHER. They are related to the PQ (Picture
Quality)
and they makes VDOSYS0 supports PQ function while they are not
including in VDOSYS1.
Hardware pipeline of VDOSYS1 has the component ETHDR (HDR
related
component). It makes VDOSYS1 supports the HDR function while
it's
not
including in VDOSYS0.
To summarize0:
Only VDOSYS0 can support PQ adjustment.
Only VDOSYS1 can support HDR adjustment.
Therefore, we need to separate these two different mmsys
hardwares
to
2 different compatibles for MT8195.
Fixes: 81c5a41d10b9 ("dt-bindings: arm: mediatek: mmsys: add
mt8195
SoC binding")
Signed-off-by: Jason-JH.Lin <redacted>
Signed-off-by: Bo-Chen Chen <redacted>
---
Changes for v2:
1. Add hardware difference for VDOSYS0 and VDOSYS1 in commit
message.
---
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
|
3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
.yam
l
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
.yam
l
index 6ad023eec193..bfbdd30d2092 100644
---
a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
.yam
l
+++
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys
.yam
l
Thanks for you patch. As I mentioned on v1, I propose to set
mediatek,mt8195-mmsys as fallback for mediatek,mt8195-vdosys0 to
not
break
backwards compatibility.
Apart from that, the binding change will need some changes to
support
the new
binding. Please provide these together with this patch.
Regards,
Matthias
Hello Matthias,
Thanks for your comments.
The purpose of this patch is to confirm we can separate mt8195
mmsys
into two compatibles. I think this modification is accepted.
No, it is not accepted following Matthias comments. You received my
ack
based on assumption that ABI break is perfectly ok for platform
maintainer, as he has decisive voice. If anyone is not happy with a
ABI
break, then his concerns must be addressed.
So let it be specific:
NAK.
quoted
After this, I think Jason-JH will push another series with this
binding
patch.
I don't know what do you mean here - another series on top of wrong
patch?
Hello Krzysztof,
For this mt8195 mmsys binding separation, we still need to modify
driver for this. The reason I send this patch is to confirm we can do
this binding modification and I also think we can not pick this patch
here.
We will push another series and it contains modification of binding and
drivers. (The series will push by Jason-JH Lin)
Sounds good. So lets wait for Jason-JH Lin to send this series and we can go on
with the review.
Just to be sure, this has not happened yet, correct?
Regards,
Matthias
Thanks!
Matthias
quoted
Maybe I should use "RFC" for this series, and I think it's more
correct.
BRs,
Bo-Chen
quoted
quoted
In Jason-JH's series, we will modify mmsys driver based on this.
And I think we don't need to keep "mediatek,mt8195-mmsys" if we
also
modify mmsys drivers in the same series.
This does not fux ABI break and broken bisectability.
quoted
Is it ok that postpones to pick this patch until we finish review
follow-up series?
No. You got a clear review to fix.
Best regards,
Krzysztof
From: Jason-JH Lin <hidden> Date: 2022-09-14 15:10:27
On Wed, 2022-09-14 at 16:32 +0200, Matthias Brugger wrote:
On 26/08/2022 17:39, Matthias Brugger wrote:
quoted
On 26/08/2022 09:13, Bo-Chen Chen wrote:
quoted
On Fri, 2022-08-26 at 15:00 +0800, Krzysztof Kozlowski wrote:
quoted
On 26/08/2022 05:07, Bo-Chen Chen wrote:
quoted
On Thu, 2022-08-25 at 22:57 +0800, Matthias Brugger wrote:
quoted
On 25/08/2022 11:14, Bo-Chen Chen wrote:
quoted
From: "Jason-JH.Lin" <redacted>
For previous MediaTek SoCs, such as MT8173, there are 2
display
HW
pipelines binding to 1 mmsys with the same power domain,
the
same
clock driver and the same mediatek-drm driver.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW
pipelines
binding
to
2 different power domains, different clock drivers and
different
mediatek-drm drivers.
Moreover, Hardware pipeline of VDOSYS0 has these
components:
COLOR,
CCORR, AAL, GAMMA, DITHER. They are related to the PQ
(Picture
Quality)
and they makes VDOSYS0 supports PQ function while they
are not
including in VDOSYS1.
Hardware pipeline of VDOSYS1 has the component ETHDR (HDR
related
component). It makes VDOSYS1 supports the HDR function
while
it's
not
including in VDOSYS0.
To summarize0:
Only VDOSYS0 can support PQ adjustment.
Only VDOSYS1 can support HDR adjustment.
Therefore, we need to separate these two different mmsys
hardwares
to
2 different compatibles for MT8195.
Fixes: 81c5a41d10b9 ("dt-bindings: arm: mediatek: mmsys:
add
mt8195
SoC binding")
Signed-off-by: Jason-JH.Lin <redacted>
Signed-off-by: Bo-Chen Chen <redacted>
---
Changes for v2:
1. Add hardware difference for VDOSYS0 and VDOSYS1 in
commit
message.
---
.../devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
quoted
3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/arm/mediatek/mediatek
,mmsys
.yam
l
b/Documentation/devicetree/bindings/arm/mediatek/mediatek
,mmsys
.yam
l
index 6ad023eec193..bfbdd30d2092 100644
---
a/Documentation/devicetree/bindings/arm/mediatek/mediatek
,mmsys
.yam
l
+++
b/Documentation/devicetree/bindings/arm/mediatek/mediatek
,mmsys
.yam
l
Thanks for you patch. As I mentioned on v1, I propose to
set
mediatek,mt8195-mmsys as fallback for mediatek,mt8195-
vdosys0 to
not
break
backwards compatibility.
Apart from that, the binding change will need some changes
to
support
the new
binding. Please provide these together with this patch.
Regards,
Matthias
Hello Matthias,
Thanks for your comments.
The purpose of this patch is to confirm we can separate
mt8195
mmsys
into two compatibles. I think this modification is accepted.
No, it is not accepted following Matthias comments. You
received my
ack
based on assumption that ABI break is perfectly ok for platform
maintainer, as he has decisive voice. If anyone is not happy
with a
ABI
break, then his concerns must be addressed.
So let it be specific:
NAK.
quoted
After this, I think Jason-JH will push another series with
this
binding
patch.
I don't know what do you mean here - another series on top of
wrong
patch?
Hello Krzysztof,
For this mt8195 mmsys binding separation, we still need to modify
driver for this. The reason I send this patch is to confirm we
can do
this binding modification and I also think we can not pick this
patch
here.
We will push another series and it contains modification of
binding and
drivers. (The series will push by Jason-JH Lin)
Sounds good. So lets wait for Jason-JH Lin to send this series and
we can go on
with the review.
Just to be sure, this has not happened yet, correct?
Regards,
Matthias
Yes, sorry for the late reply to you.
I'll start to send this series at 9/19.
Regards,
Jason-JH.Lin
quoted
Thanks!
Matthias
quoted
Maybe I should use "RFC" for this series, and I think it's more
correct.
BRs,
Bo-Chen
quoted
quoted
In Jason-JH's series, we will modify mmsys driver based on
this.
And I think we don't need to keep "mediatek,mt8195-mmsys" if
we
also
modify mmsys drivers in the same series.
This does not fux ABI break and broken bisectability.
quoted
Is it ok that postpones to pick this patch until we finish
review
follow-up series?
No. You got a clear review to fix.
Best regards,
Krzysztof