Re: [PATCH v2 3/3] dt-bindings: display: rockchip,dw-hdmi: Fix sound-dai-cells warning
On 2024-04-14 20:41, Johan Jonker wrote:
> On 4/14/24 17:11, Jonas Karlman wrote:
>> The rockchip,dw-hdmi node can be used as a sound dai codec, however,
>> dtbs_check may report the following issue:
>>
>> hdmi@fe0a: Unevaluated properties are not allowed ('#sound-dai-cells'
>> was unexpected)
>> from schema $id:
>> http://devicetree.org/schemas/display/rockchip/rockchip,dw-hdmi.yaml#
>>
>> Add a reference to dai-common.yaml and add the #sound-dai-cells prop to
>> resolve this warning.
>>
>> Signed-off-by: Jonas Karlman
>> ---
>
>> v2: New patch to fix #sound-dai-cells warning
>
> Hi,
>
> You are #4 that does an attempt on this subject.
> Coincidence with my patches??
> If other notifications could be fixed with the same amount of interest?
> Please be welcome to pick some other random Rockchip related ones.
Hehe, I should have looked deeper at what existing patches was out there.
Will send a v3 without this patch and instead reference your patch.
Regards,
Jonas
>
> Johan
>
> ===
>
> [PATCH v1 1/3] dt-bindings: display: add #sound-dai-cells property to
> rockchip dw hdmi
> https://lore.kernel.org/linux-rockchip/3a035c16-75b5-471d-aa9d-e91c2bb9f...@gmail.com/
>
> [PATCH] dt-bindings: display: rockchip: add missing #sound-dai-cells to
> dw-hdmi
> https://lore.kernel.org/linux-rockchip/20240326172801.1163200-1-he...@sntech.de/
>
> [PATCH 6/6] dt-bindings: display: rockchip: dw-hdmi: Add missing
> sound-dai-cells property
> https://lore.kernel.org/linux-rockchip/20231222-pinetab2-v1-6-e148a7f61...@mecka.net/
>
>> ---
>> .../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>> b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>> index af638b6c0d21..3285fff54416 100644
>> ---
>> a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>> +++
>> b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
>> @@ -15,6 +15,7 @@ description: |
>>
>> allOf:
>>- $ref: ../bridge/synopsys,dw-hdmi.yaml#
>> + - $ref: /schemas/sound/dai-common.yaml#
>>
>> properties:
>>compatible:
>> @@ -124,6 +125,9 @@ properties:
>> description:
>>phandle to the GRF to mux vopl/vopb.
>>
>> + "#sound-dai-cells":
>> +const: 0
>> +
>> required:
>>- compatible
>>- reg
[PATCH v2 3/3] dt-bindings: display: rockchip, dw-hdmi: Fix sound-dai-cells warning
The rockchip,dw-hdmi node can be used as a sound dai codec, however,
dtbs_check may report the following issue:
hdmi@fe0a: Unevaluated properties are not allowed ('#sound-dai-cells' was
unexpected)
from schema $id:
http://devicetree.org/schemas/display/rockchip/rockchip,dw-hdmi.yaml#
Add a reference to dai-common.yaml and add the #sound-dai-cells prop to
resolve this warning.
Signed-off-by: Jonas Karlman
---
v2: New patch to fix #sound-dai-cells warning
---
.../bindings/display/rockchip/rockchip,dw-hdmi.yaml | 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index af638b6c0d21..3285fff54416 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -15,6 +15,7 @@ description: |
allOf:
- $ref: ../bridge/synopsys,dw-hdmi.yaml#
+ - $ref: /schemas/sound/dai-common.yaml#
properties:
compatible:
@@ -124,6 +125,9 @@ properties:
description:
phandle to the GRF to mux vopl/vopb.
+ "#sound-dai-cells":
+const: 0
+
required:
- compatible
- reg
--
2.43.2
Re: [PATCH v3 4/4] arm64: dts: rockchip: Add devicetree for Pine64 PineTab2
Hi Manuel,
On 2024-01-03 14:40, Manuel Traut wrote:
> Hi Jonas and Ondřej,
>
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_dual_io_pins>;
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2400>;
>>>
>>> That's a bit on the low side. The flash chip should work for all commands
>>> up to
>>> 80MHz https://megous.com/dl/tmp/b428ad9b85ac4633.png and SGM3157YC6 switch
>>> for the FSPI-CLK should have high enough bandwidth, too.
>>
>> I agree that this is a little bit on the low side, it was a safe rate
>> that I used for U-Boot. U-Boot required an exact rate of the supported
>> sfc clk rates: 24, 50, 75, 100, 125 or 150 MHz.
>>
>> Please also note that the SPI NOR flash chip used in PineTab2 is not a
>> GigaDevice GD25LQ128E, it should be a SiliconKaiser SK25LP128, same as
>> found in the Pine64 PinePhone Pro.
>
> The schematics for v2.0 reference a GD25LQ128EWIGR. I never checked the jedec
> id. How did you retrieve this information, or is it maybe a difference in v0.1
> and 2.0?
This was when working on mainline U-Boot for the PineTab2 (and other
rk356x devices). See [1] for a pending U-Boot patch that is waiting on a
proper mainline linux devicetree for the PT2.
The JEDEC ID is reported as 0x257018 on my v2.0 production unit, and
does not match the JEDEC ID for GD25LQ128E (0xc86018) referenced in
the schematics.
I found that the JEDEC ID 0x257018 was referenced in prior patches
related to the SK25LP128 SPI NOR flash chip used in Pine64 PinePhone Pro.
I have only ever tested the 24 MHz rate, but I am expecting that e.g.
100 MHz also should work. Will not be able to test on my PT2 until at
earliest next week.
[1]
https://github.com/Kwiboo/u-boot-rockchip/commit/66562d6eaf2c11a9f97fcdba379d3ceda8aa70ef
Regards,
Jonas
>
+ spi-rx-bus-width = <2>;
>>>
>>> GD25LQ128E supports quad I/O. Maybe try 4 if it will work.
>>
>> The schematic only shows fspi D0 and D1 connected, and use the D2 line
>> for eMMC_RSTn, so spi-rx-bus-width = <2> should be correct.
>
> ack
>
> Since it is only needed for bootloader updates and environment its maybe
> better
> to stay on the safe side?
>
> But I can test faster frequency if you want me to do..
>
> Regards
> Manuel
Re: [PATCH v3 4/4] arm64: dts: rockchip: Add devicetree for Pine64 PineTab2
Hi Manuel and Ondřej,
On 2024-01-02 19:07, Ondřej Jirman wrote:
> Hello Manuel,
[...]
>> +
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_dual_io_pins>;
>> +status = "okay";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +flash@0 {
>> +compatible = "jedec,spi-nor";
>> +reg = <0>;
>> +spi-max-frequency = <2400>;
>
> That's a bit on the low side. The flash chip should work for all commands up
> to
> 80MHz https://megous.com/dl/tmp/b428ad9b85ac4633.png and SGM3157YC6 switch
> for the FSPI-CLK should have high enough bandwidth, too.
I agree that this is a little bit on the low side, it was a safe rate
that I used for U-Boot. U-Boot required an exact rate of the supported
sfc clk rates: 24, 50, 75, 100, 125 or 150 MHz.
Please also note that the SPI NOR flash chip used in PineTab2 is not a
GigaDevice GD25LQ128E, it should be a SiliconKaiser SK25LP128, same as
found in the Pine64 PinePhone Pro.
>
>> +spi-rx-bus-width = <2>;
>
> GD25LQ128E supports quad I/O. Maybe try 4 if it will work.
The schematic only shows fspi D0 and D1 connected, and use the D2 line
for eMMC_RSTn, so spi-rx-bus-width = <2> should be correct.
>
>> +spi-tx-bus-width = <1>;
>> +};
>> +};
>> +
Regards,
Jonas
Re: [PATCH v2 4/4] arm64: dts: rockchip: Add devicetree for Pine64 Pinetab2
Hi Manuel,
On 2023-12-23 16:20, Manuel Traut wrote:
> From: Alexander Warnecke
>
> This includes support for both the v0.1 units that were sent to developers and
> the v2.0 units from production.
>
> v1.0 is not included as no units are known to exist.
>
> Working/Tested:
> - SDMMC
> - UART
> - Buttons
> - Charging/Battery/PMIC
> - Audio
> - USB
> - Display
>
> WiFi is not added, since the driver is not ready for mainline.
>
> Signed-off-by: Alexander Warnecke
> Signed-off-by: Manuel Traut
> ---
> arch/arm64/boot/dts/rockchip/Makefile | 2 +
> .../boot/dts/rockchip/rk3566-pinetab2-v0.1.dts | 26 +
> .../boot/dts/rockchip/rk3566-pinetab2-v2.0.dts | 46 +
> arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi | 979
> +
> 4 files changed, 1053 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> b/arch/arm64/boot/dts/rockchip/Makefile
> index a18f33bf0c0e..ef66c0937a9b 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -77,6 +77,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg353vs.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg503.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v0.1.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v2.0.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb30.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-a.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-b.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
> b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
> new file mode 100644
> index ..8b110186a3eb
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
> @@ -0,0 +1,26 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3566-pinetab2.dtsi"
> +
> +/ {
> + model = "Pine64 PineTab2 v0.1";
> + compatible = "pine64,pinetab2-v0.1", "pine64,pinetab2",
> "rockchip,rk3566";
> +};
> +
> + {
> + reset-gpios = < RK_PA6 GPIO_ACTIVE_LOW>;
> +};
> +
> + {
> + lcd0 {
> + lcd0_rst_l: lcd0-rst-l {
> + rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO _pull_none>;
> + };
> + };
> +};
> +
> + {
> + vmmc-supply = <_sys>;
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
> b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
> new file mode 100644
> index ..6f80446b5802
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3566-pinetab2.dtsi"
> +
> +/ {
> + model = "Pine64 PineTab2 v2.0";
> + compatible = "pine64,pinetab2-v2.0", "pine64,pinetab2",
> "rockchip,rk3566";
> +};
> +
> +_keys {
> + pinctrl-0 = <_id_det>, <_int_l>;
> +
> + event-hall-sensor {
> + debounce-interval = <20>;
> + gpios = < RK_PA6 GPIO_ACTIVE_LOW>;
> + label = "Hall Sensor";
> + linux,code = ;
> + linux,input-type = ;
> + wakeup-event-action = ;
> + wakeup-source;
> + };
> +};
> +
> + {
> + reset-gpios = < RK_PC6 GPIO_ACTIVE_LOW>;
> +};
> +
> + {
> + lcd0 {
> + lcd0_rst_l: lcd0-rst-l {
> + rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO _pull_none>;
> + };
> + };
> +
> + hall {
> + hall_int_l: hall-int-l {
> + rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO _pull_none>;
> + };
> + };
> +};
> +
> + {
> + vmmc-supply = <_sys>;
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> new file mode 100644
> index ..3ab7d8dbe1ec
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> @@ -0,0 +1,979 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "rk3566.dtsi"
> +
> +/ {
> + chassis-type = "tablet";
> +
> + aliases {
> + mmc0 =
> + mmc1 =
I would have expected to see sdhci as mmc0 and sdmmc0 as mmc1 here
because the emmc is on-board and the sd-card is optional/secondary.
Also please be consistent with product name and use PineTab2 instead of
Pinetab2 in commit subject/messages.
Regards,
Jonas
> + };
> +
> + chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + adc-keys {
> + compatible = "adc-keys";
> + io-channels = < 0>;
> + io-channel-names = "buttons";
> + keyup-threshold-microvolt = <180>;
> + poll-interval = <25>;
> +
> + button-vol-up {
> +
Re: [PATCH 09/11] drm/rockchip: vop2: Add support for rk3588
On 2023-11-14 12:28, Andy Yan wrote:
> From: Andy Yan
>
> VOP2 on rk3588:
>
> Four video ports:
> VP0 Max 4096x2160
> VP1 Max 4096x2160
> VP2 Max 4096x2160
> VP3 Max 2048x1080
>
> 4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support
> 4 4K Esmart windows with line RGB/YUV support
>
> Signed-off-by: Andy Yan
> ---
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 324 ++-
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 57
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 215
> include/dt-bindings/soc/rockchip,vop2.h | 4 +
> 4 files changed, 593 insertions(+), 7 deletions(-)
>
[...]
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> index 22288ad7f326..4745a9260cf8 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> @@ -34,6 +34,28 @@ static const uint32_t formats_cluster[] = {
> DRM_FORMAT_Y210, /* yuv422_10bit non-Linear mode only */
> };
>
> +static const uint32_t formats_esmart[] = {
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_ARGB,
> + DRM_FORMAT_XBGR,
> + DRM_FORMAT_ABGR,
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_BGR888,
> + DRM_FORMAT_RGB565,
> + DRM_FORMAT_BGR565,
> + DRM_FORMAT_NV12, /* yuv420_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV21, /* yvu420_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV16, /* yuv422_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV61, /* yvu422_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV24, /* yuv444_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV42, /* yvu444_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV15, /* yuv420_10bit linear mode, 2 plane, no padding */
NV20 and NV30 drm format have now been merged into mainline linux,
please add these missing formats. The patch below adds support for them
to rk356x part of vop2 driver.
drm/rockchip: vop2: Add NV20 and NV30 support
https://lore.kernel.org/linux-rockchip/20231025213248.2641962-1-jo...@kwiboo.se/
NV15/NV20/NV30 formats can be tested using modetest from latest main
of libdrm.
modetest: add support for DRM_FORMAT_NV{15,20,30}
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/329
Regards,
Jonas
> + DRM_FORMAT_YVYU, /* yuv422_8bit[YVYU] linear mode */
> + DRM_FORMAT_VYUY, /* yuv422_8bit[VYUY] linear mode */
> + DRM_FORMAT_YUYV, /* yuv422_8bit[YUYV] linear mode */
> + DRM_FORMAT_UYVY, /* yuv422_8bit[UYVY] linear mode */
> +};
> +
> static const uint32_t formats_rk356x_esmart[] = {
> DRM_FORMAT_XRGB,
> DRM_FORMAT_ARGB,
[...]
Re: [PATCH v2] drm/rockchip: vop: Fix color for RGB888/BGR888 format on VOP full
Hi Chris,
On 2023-10-26 22:02, Christopher Obbard wrote:
> Hi Jonas,
>
> On Thu, 2023-10-26 at 19:14 +0000, Jonas Karlman wrote:
>> Use of DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888 on e.g. RK3288, RK3328
>> and RK3399 result in wrong colors being displayed.
>>
>> The issue can be observed using modetest:
>>
>> modetest -s @:1920x1080-60@RG24
>> modetest -s @:1920x1080-60@BG24
>>
>> Vendor 4.4 kernel apply an inverted rb swap for these formats on VOP
>> full framework (IP version 3.x) compared to VOP little framework (2.x).
>>
>> Fix colors by applying different rb swap for VOP full framework (3.x)
>> and VOP little framework (2.x) similar to vendor 4.4 kernel.
>>
>> Fixes: 85a359f25388 ("drm/rockchip: Add BGR formats to VOP")
>> Signed-off-by: Jonas Karlman
>
> Reviewed-by: Christopher Obbard
> Tested-by: Christopher Obbard
>
> Since you missed adding my *-by tags in v2.
>
Thanks, and sorry about that ;-)
Regards,
Jonas
[PATCH v2] drm/rockchip: vop: Fix color for RGB888/BGR888 format on VOP full
Use of DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888 on e.g. RK3288, RK3328
and RK3399 result in wrong colors being displayed.
The issue can be observed using modetest:
modetest -s @:1920x1080-60@RG24
modetest -s @:1920x1080-60@BG24
Vendor 4.4 kernel apply an inverted rb swap for these formats on VOP
full framework (IP version 3.x) compared to VOP little framework (2.x).
Fix colors by applying different rb swap for VOP full framework (3.x)
and VOP little framework (2.x) similar to vendor 4.4 kernel.
Fixes: 85a359f25388 ("drm/rockchip: Add BGR formats to VOP")
Signed-off-by: Jonas Karlman
---
Changes in v2:
- Add comment about different rb swap for IP version 3.x and 2.x
- Add fixes tag
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index b3d0b6ae9294..ed2ed25959a2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -247,14 +247,22 @@ static inline void vop_cfg_done(struct vop *vop)
VOP_REG_SET(vop, common, cfg_done, 1);
}
-static bool has_rb_swapped(uint32_t format)
+static bool has_rb_swapped(uint32_t version, uint32_t format)
{
switch (format) {
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ABGR:
- case DRM_FORMAT_BGR888:
case DRM_FORMAT_BGR565:
return true;
+ /*
+* full framework (IP version 3.x) only need rb swapped for RGB888 and
+* little framework (IP version 2.x) only need rb swapped for BGR888,
+* check for 3.x to also only rb swap BGR888 for unknown vop version
+*/
+ case DRM_FORMAT_RGB888:
+ return VOP_MAJOR(version) == 3;
+ case DRM_FORMAT_BGR888:
+ return VOP_MAJOR(version) != 3;
default:
return false;
}
@@ -1035,7 +1043,7 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
VOP_WIN_SET(vop, win, dsp_info, dsp_info);
VOP_WIN_SET(vop, win, dsp_st, dsp_st);
- rb_swap = has_rb_swapped(fb->format->format);
+ rb_swap = has_rb_swapped(vop->data->version, fb->format->format);
VOP_WIN_SET(vop, win, rb_swap, rb_swap);
/*
--
2.42.0
[PATCH] drm/rockchip: vop2: Add NV20 and NV30 support
Add support for the 10-bit 4:2:2 and 4:4:4 formats NV20 and NV30.
These formats can be tested using modetest [1]:
modetest -P @:1920x1080@
e.g. on a ROCK 3 Model A (rk3568):
modetest -P 43@67:1920x1080@NV20 -F tiles,tiles
modetest -P 43@67:1920x1080@NV30 -F smpte,smpte
[1] https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/329
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 5 +
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index ab944010fe14..592f9d726f2e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -326,11 +326,14 @@ static enum vop2_data_format vop2_convert_format(u32
format)
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV61:
return VOP2_FMT_YUV422SP;
+ case DRM_FORMAT_NV20:
case DRM_FORMAT_Y210:
return VOP2_FMT_YUV422SP_10;
case DRM_FORMAT_NV24:
case DRM_FORMAT_NV42:
return VOP2_FMT_YUV444SP;
+ case DRM_FORMAT_NV30:
+ return VOP2_FMT_YUV444SP_10;
case DRM_FORMAT_YUYV:
case DRM_FORMAT_YVYU:
return VOP2_FMT_VYUY422;
@@ -415,6 +418,8 @@ static bool vop2_win_uv_swap(u32 format)
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV24:
case DRM_FORMAT_NV15:
+ case DRM_FORMAT_NV20:
+ case DRM_FORMAT_NV30:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_UYVY:
return true;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
index fdb48571efce..0b4280218a59 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
@@ -48,8 +48,10 @@ static const uint32_t formats_rk356x_esmart[] = {
DRM_FORMAT_NV15, /* yuv420_10bit linear mode, 2 plane, no padding */
DRM_FORMAT_NV16, /* yuv422_8bit linear mode, 2 plane */
DRM_FORMAT_NV61, /* yuv422_8bit linear mode, 2 plane */
+ DRM_FORMAT_NV20, /* yuv422_10bit linear mode, 2 plane, no padding */
DRM_FORMAT_NV24, /* yuv444_8bit linear mode, 2 plane */
DRM_FORMAT_NV42, /* yuv444_8bit linear mode, 2 plane */
+ DRM_FORMAT_NV30, /* yuv444_10bit linear mode, 2 plane, no padding */
DRM_FORMAT_YVYU, /* yuv422_8bit[YVYU] linear mode */
DRM_FORMAT_VYUY, /* yuv422_8bit[VYUY] linear mode */
};
--
2.42.0
Re: [PATCH] drm/rockchip: vop: Fix color for RGB888/BGR888 format on VOP full
On 2023-10-24 14:41, Andy Yan wrote:
> Hi:
>
> On 10/24/23 16:49, Christopher Obbard wrote:
>> Hi Jonas,
>>
>> On Mon, 2023-10-23 at 21:11 +, Jonas Karlman wrote:
>>> Use of DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888 on e.g. RK3288, RK3328
>>> and RK3399 result in wrong colors being displayed.
>>>
>>> The issue can be observed using modetest:
>>>
>>> modetest -s @:1920x1080-60@RG24
>>> modetest -s @:1920x1080-60@BG24
>>>
>>> Vendor 4.4 kernel apply an inverted rb swap for these formats on VOP
>>> full (major = 3).
>>>
>>> Fix colors by applying rb swap similar to vendor 4.4 kernel.
>>>
>>> Signed-off-by: Jonas Karlman
>> How about a fixes tag? Seems like this was introduced in commit 85a359f25388
>> ("drm/rockchip: Add BGR formats to VOP")
That commit added BGR888 format, the RGB888 format goes back to from
when driver was initially added. This patch depend on a macro that was
introduced later, in commit eb5cb6aa9a72 ("drm/rockchip: vop: add a
series of vop support"). Still think commit 85a359f25388 is best commit
to use in a fixes tag.
Will include a fixes tag for 85a359f25388 in v2.
>>
>>> ---
>>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 9 ++---
>>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> index b3d0b6ae9294..a1ce09a22f83 100644
>>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>> @@ -247,14 +247,17 @@ static inline void vop_cfg_done(struct vop *vop)
>>> VOP_REG_SET(vop, common, cfg_done, 1);
>>> }
>>>
>>> -static bool has_rb_swapped(uint32_t format)
>>> +static bool has_rb_swapped(uint32_t version, uint32_t format)
>>> {
>>> switch (format) {
>>> case DRM_FORMAT_XBGR:
>>> case DRM_FORMAT_ABGR:
>>> - case DRM_FORMAT_BGR888:
>>> case DRM_FORMAT_BGR565:
>>> return true;
>>> + case DRM_FORMAT_RGB888:
>>> + return VOP_MAJOR(version) == 3;
>>> + case DRM_FORMAT_BGR888:
>>> + return VOP_MAJOR(version) != 3;
>> The hardcoded bits are quite scary as it applies to all hardware variants
>> ;-).
>> Is it worth adding an inline comment to describe what is going on and how it
>> relates to VOPL and VOPH? Or would it be even better to add this as a quirk
>> in
>> the various vop_data structs?
>
I will add a comment in v2.
It would be a quirk that apply for all VOP full framework, IP version 3.x,
SoCs so checking VOP_MAJOR seem like a good option.
See commit eb5cb6aa9a72 ("drm/rockchip: vop: add a series of vop support")
for a list of SoCs that use VOP full framework:
Vop Full framework now has following vops:
IP versionchipname
3.1 rk3288
3.2 rk3368
3.4 rk3366
3.5 rk3399 big
3.6 rk3399 lit
3.7 rk3228
3.8 rk3328
major version: used for IP structure, Vop full framework is 3,
vop little framework is 2.
There are currently three struct vop_data that is missing version declaration:
- rk3036_vop should use VOP_VERSION(2, 2)
- rk3126_vop should use VOP_VERSION(2, 4)
- rk3188_vop guessing is 2.0/2.1 (same/similar as rk3066)
Since none of them are 3.x / VOP full framework, this patch should only
fix/change behavior for affected 3.x / VOP full framework SoCs.
Regards,
Jonas
>
> Every vop hardware has a version(including VOPB/VOPL), so I think use
> VOP_MAJOR to distinguish is ok. Of course it's better
>
> to add some comments. As for adding some quirk in vop_data, I have the
> idea of adding a table to describe the drm format and it's (rb/uv swap,
> afbc)
>
> capability, but I think this is can be done in the future.
>
>>
>>
>> Cheers!
>>
>> Chris
>>
>>> default:
>>> return false;
>>> }
>>> @@ -1035,7 +1038,7 @@ static void vop_plane_atomic_update(struct drm_plane
>>> *plane,
>>> VOP_WIN_SET(vop, win, dsp_info, dsp_info);
>>> VOP_WIN_SET(vop, win, dsp_st, dsp_st);
>>>
>>> - rb_swap = has_rb_swapped(fb->format->format);
>>> + rb_swap = has_rb_swapped(vop->data->version, fb->format->format);
>>> VOP_WIN_SET(vop, win, rb_swap, rb_swap);
>>>
>>> /*
Re: [PATCH v5 0/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support
Hi Chris, On 2023-10-23 19:52, Christopher Obbard wrote: > Hi Jonas, > > On Mon, 2023-10-23 at 17:37 +0000, Jonas Karlman wrote: >> This series add support for displaying 10-bit 4:2:0 and 4:2:2 formats >> produced >> by the Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399. >> Also include 10-bit 4:4:4 support since VOP can support that also. >> >> First patch adds new fourcc 10-bit YUV formats with 4:2:2/4:4:4 sub- >> sampling. >> Second patch adds support for displaying the new fourcc formats. >> >> These patches have been in use by LibreELEC and other distros for the >> past 3+ years, hoping they can be merged this time around. >> >> A rough libdrm/modetest patch [2] have been used to validate use of >> NV15, NV20 and NV30 formats on RK3288, RK3328 and RK3399 boards. >> >> modetest -s @:-@ >> >> Tinker Board R2.0 (rk3288w): >> modetest -s 50:1920x1080-60@NV15 >> >> Rock Pi 4 (rk3399): >> modetest -s 52@44:1920x1080-60@NV15 >> >> Rock64 (rk3328): >> modetest -s 42:1920x1080-60@NV15 >> >> Changes in v5: >> - Use drm_format_info_min_pitch() for correct bpp >> - Add missing NV21, NV61 and NV42 formats >> >> Changes in v4: >> - Rework RK3328/RK3399 win0/1 data to not affect RK3368 >> >> Changes in v3: >> - No changes, rebased on next-20230616 >> - R-B tags was collected >> >> Changes in v2: >> - Add NV30 format >> - R-B tags was not collected due to NV30 changes >> >> This series is also available at [1] and libdrm/modetest patch at [2]. >> >> [1] https://github.com/Kwiboo/linux-rockchip/commits/v6.6-rc7-vop-nv15 >> [2] https://github.com/Kwiboo/libdrm/commits/nv15 > > Could you open a draft merge request for libdrm upstream at > https://gitlab.freedesktop.org/mesa/drm pointing to this series? If there are > subsequent revisions of this series, it'd be great to link that merge request > in the cover letter. Have created a draft merge reguest for libdrm/modetest changes now. https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/329 The pattern code could really need some improvements/refactoring, in current form it should at least be enough to create a test pattern to help test/validate this series :-) Regards, Jonas > > > Cheers! > > Chris > >> >> Jonas Karlman (2): >> drm/fourcc: Add NV20 and NV30 YUV formats >> drm/rockchip: vop: Add NV15, NV20 and NV30 support >> >> drivers/gpu/drm/drm_fourcc.c | 8 +++ >> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 36 --- >> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + >> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 66 + >> include/uapi/drm/drm_fourcc.h | 2 + >> 5 files changed, 96 insertions(+), 17 deletions(-) >>
[PATCH] drm/rockchip: vop: Fix color for RGB888/BGR888 format on VOP full
Use of DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888 on e.g. RK3288, RK3328
and RK3399 result in wrong colors being displayed.
The issue can be observed using modetest:
modetest -s @:1920x1080-60@RG24
modetest -s @:1920x1080-60@BG24
Vendor 4.4 kernel apply an inverted rb swap for these formats on VOP
full (major = 3).
Fix colors by applying rb swap similar to vendor 4.4 kernel.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index b3d0b6ae9294..a1ce09a22f83 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -247,14 +247,17 @@ static inline void vop_cfg_done(struct vop *vop)
VOP_REG_SET(vop, common, cfg_done, 1);
}
-static bool has_rb_swapped(uint32_t format)
+static bool has_rb_swapped(uint32_t version, uint32_t format)
{
switch (format) {
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ABGR:
- case DRM_FORMAT_BGR888:
case DRM_FORMAT_BGR565:
return true;
+ case DRM_FORMAT_RGB888:
+ return VOP_MAJOR(version) == 3;
+ case DRM_FORMAT_BGR888:
+ return VOP_MAJOR(version) != 3;
default:
return false;
}
@@ -1035,7 +1038,7 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
VOP_WIN_SET(vop, win, dsp_info, dsp_info);
VOP_WIN_SET(vop, win, dsp_st, dsp_st);
- rb_swap = has_rb_swapped(fb->format->format);
+ rb_swap = has_rb_swapped(vop->data->version, fb->format->format);
VOP_WIN_SET(vop, win, rb_swap, rb_swap);
/*
--
2.42.0
[PATCH v5 1/2] drm/fourcc: Add NV20 and NV30 YUV formats
DRM_FORMAT_NV20 and DRM_FORMAT_NV30 formats is the 2x1 and non-subsampled
variant of NV15, a 10-bit 2-plane YUV format that has no padding between
components. Instead, luminance and chrominance samples are grouped into 4s
so that each group is packed into an integer number of bytes:
= UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '20' and '30' suffix refers to the optimum effective bits per pixel
which is achieved when the total number of luminance samples is a multiple
of 4.
V2: Added NV30 format
Signed-off-by: Jonas Karlman
Reviewed-by: Sandy Huang
---
drivers/gpu/drm/drm_fourcc.c | 8
include/uapi/drm/drm_fourcc.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 0f17dfa8702b..193cf8ed7912 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -299,6 +299,14 @@ const struct drm_format_info *__drm_format_info(u32 format)
.num_planes = 2, .char_per_block = { 5, 5, 0 },
.block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
.vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_NV20,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
+ .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_NV30,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 1,
+ .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Q410,.depth = 0,
.num_planes = 3, .char_per_block = { 2, 2, 2 },
.block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 1,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8db7fd3f743e..3151f1fc7ebb 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -323,6 +323,8 @@ extern "C" {
* index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
*/
#define DRM_FORMAT_NV15fourcc_code('N', 'V', '1', '5') /* 2x2
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV20fourcc_code('N', 'V', '2', '0') /* 2x1
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV30fourcc_code('N', 'V', '3', '0') /*
non-subsampled Cr:Cb plane */
/*
* 2 plane YCbCr MSB aligned
--
2.42.0
[PATCH v5 0/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support
This series add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399. Also include 10-bit 4:4:4 support since VOP can support that also. First patch adds new fourcc 10-bit YUV formats with 4:2:2/4:4:4 sub-sampling. Second patch adds support for displaying the new fourcc formats. These patches have been in use by LibreELEC and other distros for the past 3+ years, hoping they can be merged this time around. A rough libdrm/modetest patch [2] have been used to validate use of NV15, NV20 and NV30 formats on RK3288, RK3328 and RK3399 boards. modetest -s @:-@ Tinker Board R2.0 (rk3288w): modetest -s 50:1920x1080-60@NV15 Rock Pi 4 (rk3399): modetest -s 52@44:1920x1080-60@NV15 Rock64 (rk3328): modetest -s 42:1920x1080-60@NV15 Changes in v5: - Use drm_format_info_min_pitch() for correct bpp - Add missing NV21, NV61 and NV42 formats Changes in v4: - Rework RK3328/RK3399 win0/1 data to not affect RK3368 Changes in v3: - No changes, rebased on next-20230616 - R-B tags was collected Changes in v2: - Add NV30 format - R-B tags was not collected due to NV30 changes This series is also available at [1] and libdrm/modetest patch at [2]. [1] https://github.com/Kwiboo/linux-rockchip/commits/v6.6-rc7-vop-nv15 [2] https://github.com/Kwiboo/libdrm/commits/nv15 Jonas Karlman (2): drm/fourcc: Add NV20 and NV30 YUV formats drm/rockchip: vop: Add NV15, NV20 and NV30 support drivers/gpu/drm/drm_fourcc.c| 8 +++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 36 --- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 66 + include/uapi/drm/drm_fourcc.h | 2 + 5 files changed, 96 insertions(+), 17 deletions(-) -- 2.42.0
[PATCH v5 2/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support
Add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by
the Rockchip Video Decoder on RK322X, RK3288, RK3328 and RK3399.
Also add support for 10-bit 4:4:4 format while at it.
V5: Use drm_format_info_min_pitch() for correct bpp
Add missing NV21, NV61 and NV42 formats
V4: Rework RK3328/RK3399 win0/1 data to not affect RK3368
V2: Added NV30 support
Signed-off-by: Jonas Karlman
Reviewed-by: Sandy Huang
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 36 ---
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 66 +
3 files changed, 86 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 14320bc73e5b..b3d0b6ae9294 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -272,6 +272,18 @@ static bool has_uv_swapped(uint32_t format)
}
}
+static bool is_fmt_10(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV15:
+ case DRM_FORMAT_NV20:
+ case DRM_FORMAT_NV30:
+ return true;
+ default:
+ return false;
+ }
+}
+
static enum vop_data_format vop_convert_format(uint32_t format)
{
switch (format) {
@@ -287,12 +299,15 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV15:
case DRM_FORMAT_NV21:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV20:
case DRM_FORMAT_NV61:
return VOP_FMT_YUV422SP;
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV30:
case DRM_FORMAT_NV42:
return VOP_FMT_YUV444SP;
default:
@@ -944,7 +959,12 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (fb->format->char_per_block[0])
+ offset = drm_format_info_min_pitch(fb->format, 0,
+ src->x1 >> 16);
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -970,6 +990,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
}
VOP_WIN_SET(vop, win, format, format);
+ VOP_WIN_SET(vop, win, fmt_10, is_fmt_10(fb->format->format));
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, y2r_en, is_yuv);
@@ -979,15 +1000,16 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
(new_state->rotation & DRM_MODE_REFLECT_X) ? 1 : 0);
if (is_yuv) {
- int hsub = fb->format->hsub;
- int vsub = fb->format->vsub;
- int bpp = fb->format->cpp[1];
-
uv_obj = fb->obj[1];
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
- offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
+ if (fb->format->char_per_block[1])
+ offset = drm_format_info_min_pitch(fb->format, 1,
+ src->x1 >> 16);
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[1];
+ offset /= fb->format->hsub;
+ offset += (src->y1 >> 16) * fb->pitches[1] / fb->format->vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
VOP_WIN_SET(vop, win, uv_vir, DIV_ROUND_UP(fb->pitches[1], 4));
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 5f56e0597df8..4b2daefeb8c1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -186,6 +186,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg uv_swap;
struct vop_reg act_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 7b2805006776..f8cef0cb7bff 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_v
Re: [PATCH v2 3/4] drm/rockchip: fix the plane format defination of rk3568/6
Hi Andy,
On 2023-10-13 14:21, Andy Yan wrote:
> From: Andy Yan
>
> Add the missing 10 bit RGB format for cluster window.
> The cluster windows on rk3568/6 only support afbc format,
> so change the linear yuv format NV12/16/24 to non-Linear
> YUV420_8BIT/YUV420_10BIT/YUYV/Y210.
>
> Add NV15 for esmart windows.
>
> Also add some comments.
>
> Signed-off-by: Andy Yan
>
> ---
>
> Changes in v2:
> - split rename to another patch
>
> drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 22 +---
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> index 62b573f282a7..05aee588e8c9 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
> @@ -16,6 +16,10 @@
> #include "rockchip_drm_vop2.h"
>
> static const uint32_t formats_win_full_10bit[] = {
> + DRM_FORMAT_XRGB2101010,
> + DRM_FORMAT_ARGB2101010,
> + DRM_FORMAT_XBGR2101010,
> + DRM_FORMAT_ABGR2101010,
atomic_check() will fail for these formats due to missing support for
these formats in the vop2 driver. Support for these formats should be
added to vop2 driver before being exposed as a supported pixel format.
vop2_convert_format() return -EINVAL for these and below formats.
> DRM_FORMAT_XRGB,
> DRM_FORMAT_ARGB,
> DRM_FORMAT_XBGR,
> @@ -24,9 +28,10 @@ static const uint32_t formats_win_full_10bit[] = {
> DRM_FORMAT_BGR888,
> DRM_FORMAT_RGB565,
> DRM_FORMAT_BGR565,
> - DRM_FORMAT_NV12,
> - DRM_FORMAT_NV16,
> - DRM_FORMAT_NV24,
> + DRM_FORMAT_YUV420_8BIT, /* yuv420_8bit non-Linear mode only */
> + DRM_FORMAT_YUV420_10BIT, /* yuv420_10bit non-Linear mode only */
Same for YUV420_8BIT and YUV420_10BIT.
> + DRM_FORMAT_YUYV, /* yuv422_8bit non-Linear mode only*/
> + DRM_FORMAT_Y210, /* yuv422_10bit non-Linear mode only */
Same for Y210.
> };
>
> static const uint32_t formats_win_full_10bit_yuyv[] = {
> @@ -38,11 +43,12 @@ static const uint32_t formats_win_full_10bit_yuyv[] = {
> DRM_FORMAT_BGR888,
> DRM_FORMAT_RGB565,
> DRM_FORMAT_BGR565,
> - DRM_FORMAT_NV12,
> - DRM_FORMAT_NV16,
> - DRM_FORMAT_NV24,
> - DRM_FORMAT_YVYU,
> - DRM_FORMAT_VYUY,
> + DRM_FORMAT_NV12, /* yuv420_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV15, /* yuv420_10bit linear mode, 2 plane, no padding */
Same for NV15.
Regards,
Jonas
> + DRM_FORMAT_NV16, /* yuv422_8bit linear mode, 2 plane */
> + DRM_FORMAT_NV24, /* yuv444_8bit linear mode, 2 plane */
> + DRM_FORMAT_YVYU, /* yuv422_8bit[YVYU] linear mode */
> + DRM_FORMAT_VYUY, /* yuv422_8bit[VYUY] linear mode */
> };
>
> static const uint32_t formats_win_lite[] = {
Re: [PATCH v2 0/5] drm/rockchip: Fix crtc duplicate state and crtc reset funcs
Hi Heiko, Please consider reviewing and merging this series [2], and also [3]. drm/rockchip: Fix crtc duplicate state and crtc reset funcs [2] https://lore.kernel.org/all/20230621223311.2239547-1-jo...@kwiboo.se/ drm/rockchip: vop: Add NV15, NV20 and NV30 support [3] https://lore.kernel.org/all/20230618220122.3911297-1-jo...@kwiboo.se/ Regards, Jonas On 2023-06-22 00:33, Jonas Karlman wrote: > This series fixes a reset of state in duplicate state crtc funcs for VOP > driver, a possible crash and ensure crtc reset helper is called in VOP2 > driver. > > Patch 1 use kmemdup instead of kzalloc to duplicate the crtc state. > Patch 2 change to use crtc and plane cleanup helpers directly. > Patch 3 adds a null guard for allocation failure. > Patch 4 adds a crash guard for empty crtc state. > Patch 5 adds a missing call to crtc reset helper. > > This is the next part of an ongoing effort to upstream HDMI 2.0 support > used in LibreELEC for the past 3+ years. > > Changes in v2: > - Handle possible allocation failure in crtc reset funcs > - Collect r-b tags > > This series is also available at [1]. > > [1] > https://github.com/Kwiboo/linux-rockchip/commits/next-20230621-duplicate-state > > Jonas Karlman (5): > drm/rockchip: vop: Fix reset of state in duplicate state crtc funcs > drm/rockchip: vop: Use cleanup helper directly as destroy funcs > drm/rockchip: vop: Fix call to crtc reset helper > drm/rockchip: vop2: Don't crash for invalid duplicate_state > drm/rockchip: vop2: Add missing call to crtc reset helper > > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 24 +--- > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 39 ++-- > 2 files changed, 28 insertions(+), 35 deletions(-) >
[PATCH v2 5/5] drm/rockchip: vop2: Add missing call to crtc reset helper
Add missing call to crtc reset helper to properly vblank reset.
Also move vop2_crtc_reset and call vop2_crtc_destroy_state to simplify
and remove duplicated code.
Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
Signed-off-by: Jonas Karlman
---
v2:
- Add check for allocation failure (Sascha)
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 31 +---
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index f725487d02ef..5ba83121a1b9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -2080,23 +2080,6 @@ static const struct drm_crtc_helper_funcs
vop2_crtc_helper_funcs = {
.atomic_disable = vop2_crtc_atomic_disable,
};
-static void vop2_crtc_reset(struct drm_crtc *crtc)
-{
- struct rockchip_crtc_state *vcstate =
to_rockchip_crtc_state(crtc->state);
-
- if (crtc->state) {
- __drm_atomic_helper_crtc_destroy_state(crtc->state);
- kfree(vcstate);
- }
-
- vcstate = kzalloc(sizeof(*vcstate), GFP_KERNEL);
- if (!vcstate)
- return;
-
- crtc->state = >base;
- crtc->state->crtc = crtc;
-}
-
static struct drm_crtc_state *vop2_crtc_duplicate_state(struct drm_crtc *crtc)
{
struct rockchip_crtc_state *vcstate;
@@ -2123,6 +2106,20 @@ static void vop2_crtc_destroy_state(struct drm_crtc
*crtc,
kfree(vcstate);
}
+static void vop2_crtc_reset(struct drm_crtc *crtc)
+{
+ struct rockchip_crtc_state *vcstate =
+ kzalloc(sizeof(*vcstate), GFP_KERNEL);
+
+ if (crtc->state)
+ vop2_crtc_destroy_state(crtc, crtc->state);
+
+ if (vcstate)
+ __drm_atomic_helper_crtc_reset(crtc, >base);
+ else
+ __drm_atomic_helper_crtc_reset(crtc, NULL);
+}
+
static const struct drm_crtc_funcs vop2_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
--
2.41.0
[PATCH v2 4/5] drm/rockchip: vop2: Don't crash for invalid duplicate_state
It's possible for users to try to duplicate the CRTC state even when the
state doesn't exist. drm_atomic_helper_crtc_duplicate_state() (and other
users of __drm_atomic_helper_crtc_duplicate_state()) already guard this
with a WARN_ON() instead of crashing, so let's do that here too.
Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
Signed-off-by: Jonas Karlman
Reviewed-by: Sascha Hauer
---
v2:
- Collect r-b tag
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index ca73b8ccc29f..f725487d02ef 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -2099,11 +2099,13 @@ static void vop2_crtc_reset(struct drm_crtc *crtc)
static struct drm_crtc_state *vop2_crtc_duplicate_state(struct drm_crtc *crtc)
{
- struct rockchip_crtc_state *vcstate, *old_vcstate;
+ struct rockchip_crtc_state *vcstate;
- old_vcstate = to_rockchip_crtc_state(crtc->state);
+ if (WARN_ON(!crtc->state))
+ return NULL;
- vcstate = kmemdup(old_vcstate, sizeof(*old_vcstate), GFP_KERNEL);
+ vcstate = kmemdup(to_rockchip_crtc_state(crtc->state),
+ sizeof(*vcstate), GFP_KERNEL);
if (!vcstate)
return NULL;
--
2.41.0
[PATCH v2 3/5] drm/rockchip: vop: Fix call to crtc reset helper
Allocation of crtc_state may fail in vop_crtc_reset, causing an invalid
pointer to be passed to __drm_atomic_helper_crtc_reset.
Fix this by adding a NULL check of crtc_state, similar to other drivers.
Fixes: 01e2eaf40c9d ("drm/rockchip: Convert to using
__drm_atomic_helper_crtc_reset() for reset.")
Signed-off-by: Jonas Karlman
---
v2:
- New patch
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 25c873d4ff53..23bc79064e78 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1630,7 +1630,10 @@ static void vop_crtc_reset(struct drm_crtc *crtc)
if (crtc->state)
vop_crtc_destroy_state(crtc, crtc->state);
- __drm_atomic_helper_crtc_reset(crtc, _state->base);
+ if (crtc_state)
+ __drm_atomic_helper_crtc_reset(crtc, _state->base);
+ else
+ __drm_atomic_helper_crtc_reset(crtc, NULL);
}
#ifdef CONFIG_DRM_ANALOGIX_DP
--
2.41.0
[PATCH v2 1/5] drm/rockchip: vop: Fix reset of state in duplicate state crtc funcs
struct rockchip_crtc_state members such as output_type, output_bpc and
enable_afbc is always reset to zero in the atomic_duplicate_state crtc
funcs.
Fix this by using kmemdup on the subclass rockchip_crtc_state struct.
Fixes: 4e257d9eee23 ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config")
Signed-off-by: Jonas Karlman
Reviewed-by: Sascha Hauer
---
v2:
- Collect r-b tag
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index a530ecc4d207..60b23636a3fe 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1614,7 +1614,8 @@ static struct drm_crtc_state
*vop_crtc_duplicate_state(struct drm_crtc *crtc)
if (WARN_ON(!crtc->state))
return NULL;
- rockchip_state = kzalloc(sizeof(*rockchip_state), GFP_KERNEL);
+ rockchip_state = kmemdup(to_rockchip_crtc_state(crtc->state),
+sizeof(*rockchip_state), GFP_KERNEL);
if (!rockchip_state)
return NULL;
--
2.41.0
[PATCH v2 2/5] drm/rockchip: vop: Use cleanup helper directly as destroy funcs
vop_plane_destroy and vop_crtc_destroy are plain wrappers around
drm_plane_cleanup and drm_crtc_cleanup. Use them directly as plane and
crtc funcs to closer match VOP2 driver.
Signed-off-by: Jonas Karlman
Reviewed-by: Sascha Hauer
---
v2:
- Collect r-b tag
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 60b23636a3fe..25c873d4ff53 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -766,11 +766,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
}
}
-static void vop_plane_destroy(struct drm_plane *plane)
-{
- drm_plane_cleanup(plane);
-}
-
static inline bool rockchip_afbc(u64 modifier)
{
return modifier == ROCKCHIP_AFBC_MOD;
@@ -1131,7 +1126,7 @@ static const struct drm_plane_helper_funcs
plane_helper_funcs = {
static const struct drm_plane_funcs vop_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
- .destroy = vop_plane_destroy,
+ .destroy = drm_plane_cleanup,
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
@@ -1602,11 +1597,6 @@ static const struct drm_crtc_helper_funcs
vop_crtc_helper_funcs = {
.atomic_disable = vop_crtc_atomic_disable,
};
-static void vop_crtc_destroy(struct drm_crtc *crtc)
-{
- drm_crtc_cleanup(crtc);
-}
-
static struct drm_crtc_state *vop_crtc_duplicate_state(struct drm_crtc *crtc)
{
struct rockchip_crtc_state *rockchip_state;
@@ -1711,7 +1701,7 @@ vop_crtc_verify_crc_source(struct drm_crtc *crtc, const
char *source_name,
static const struct drm_crtc_funcs vop_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
- .destroy = vop_crtc_destroy,
+ .destroy = drm_crtc_cleanup,
.reset = vop_crtc_reset,
.atomic_duplicate_state = vop_crtc_duplicate_state,
.atomic_destroy_state = vop_crtc_destroy_state,
@@ -1962,7 +1952,7 @@ static void vop_destroy_crtc(struct vop *vop)
*/
list_for_each_entry_safe(plane, tmp, _dev->mode_config.plane_list,
head)
- vop_plane_destroy(plane);
+ drm_plane_cleanup(plane);
/*
* Destroy CRTC after vop_plane_destroy() since vop_disable_plane()
--
2.41.0
[PATCH v2 0/5] drm/rockchip: Fix crtc duplicate state and crtc reset funcs
This series fixes a reset of state in duplicate state crtc funcs for VOP driver, a possible crash and ensure crtc reset helper is called in VOP2 driver. Patch 1 use kmemdup instead of kzalloc to duplicate the crtc state. Patch 2 change to use crtc and plane cleanup helpers directly. Patch 3 adds a null guard for allocation failure. Patch 4 adds a crash guard for empty crtc state. Patch 5 adds a missing call to crtc reset helper. This is the next part of an ongoing effort to upstream HDMI 2.0 support used in LibreELEC for the past 3+ years. Changes in v2: - Handle possible allocation failure in crtc reset funcs - Collect r-b tags This series is also available at [1]. [1] https://github.com/Kwiboo/linux-rockchip/commits/next-20230621-duplicate-state Jonas Karlman (5): drm/rockchip: vop: Fix reset of state in duplicate state crtc funcs drm/rockchip: vop: Use cleanup helper directly as destroy funcs drm/rockchip: vop: Fix call to crtc reset helper drm/rockchip: vop2: Don't crash for invalid duplicate_state drm/rockchip: vop2: Add missing call to crtc reset helper drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 24 +--- drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 39 ++-- 2 files changed, 28 insertions(+), 35 deletions(-) -- 2.41.0
Re: [PATCH 4/4] drm/rockchip: vop2: Add missing call to crtc reset helper
On 2023-06-21 10:11, Sascha Hauer wrote:
> On Tue, Jun 20, 2023 at 06:47:39AM +0000, Jonas Karlman wrote:
>> Add missing call to crtc reset helper to properly vblank reset.
>>
>> Also move vop2_crtc_reset and call vop2_crtc_destroy_state to simplify
>> and remove duplicated code.
>>
>> Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
>> Signed-off-by: Jonas Karlman
>> ---
>> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 28
>> 1 file changed, 11 insertions(+), 17 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> index f725487d02ef..1be84fe0208f 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
>> @@ -2080,23 +2080,6 @@ static const struct drm_crtc_helper_funcs
>> vop2_crtc_helper_funcs = {
>> .atomic_disable = vop2_crtc_atomic_disable,
>> };
>>
>> -static void vop2_crtc_reset(struct drm_crtc *crtc)
>> -{
>> -struct rockchip_crtc_state *vcstate =
>> to_rockchip_crtc_state(crtc->state);
>> -
>> -if (crtc->state) {
>> -__drm_atomic_helper_crtc_destroy_state(crtc->state);
>> -kfree(vcstate);
>> -}
>> -
>> -vcstate = kzalloc(sizeof(*vcstate), GFP_KERNEL);
>> -if (!vcstate)
>> -return;
>> -
>> -crtc->state = >base;
>> -crtc->state->crtc = crtc;
>> -}
>> -
>> static struct drm_crtc_state *vop2_crtc_duplicate_state(struct drm_crtc
>> *crtc)
>> {
>> struct rockchip_crtc_state *vcstate;
>> @@ -2123,6 +2106,17 @@ static void vop2_crtc_destroy_state(struct drm_crtc
>> *crtc,
>> kfree(vcstate);
>> }
>>
>> +static void vop2_crtc_reset(struct drm_crtc *crtc)
>> +{
>> +struct rockchip_crtc_state *vcstate =
>> +kzalloc(sizeof(*vcstate), GFP_KERNEL);
>> +
>> +if (crtc->state)
>> +vop2_crtc_destroy_state(crtc, crtc->state);
>> +
>> +__drm_atomic_helper_crtc_reset(crtc, >base);
>> +}
>
> You missed to check for allocation failures before using vcstate.
Good catch, I will fix for both vop and vop2 driver in v2.
Regards,
Jonas
>
> Sascha
>
Re: [PATCH 2/3] drm/rockchip: Resolve dependency in GEM DMA helpers
Hi Thomas, On 2023-06-20 14:03, Thomas Zimmermann wrote: > Remove the dependency on the GEM DMA helper library. Rockchip comes > with its own implementation of the GEM interface. It only uses the VM > callbacks in drm_gem_dma_vm_ops from the GEM DMA helpers. These are > not DMA specific. > > Duplicate drm_gem_dma_vm_ops in rockchip and remove all dependencies on > the GEM DMA helper library. I have intentions to remove the entire custom implementation of the GEM interface and replace it with use of GEM DMA helpers in a future series. Current custom implementation break import of video framebuffers located in memory beyond 4GB. Switching to use pure GEM DMA helpers solved that issue but requires reworking IOMMU integration for full support of multiple VOPs on e.g., RK3288 and RK3399. I have no ETA on when such series can be ready so this is more of a heads up that I will revert this removal of dependency on GEM DMA helper library in a future series. Regards, Jonas > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/rockchip/Kconfig| 1 - > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 8 ++-- > 3 files changed, 7 insertions(+), 4 deletions(-) > [snip]
[PATCH 4/4] drm/rockchip: vop2: Add missing call to crtc reset helper
Add missing call to crtc reset helper to properly vblank reset.
Also move vop2_crtc_reset and call vop2_crtc_destroy_state to simplify
and remove duplicated code.
Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 28
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index f725487d02ef..1be84fe0208f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -2080,23 +2080,6 @@ static const struct drm_crtc_helper_funcs
vop2_crtc_helper_funcs = {
.atomic_disable = vop2_crtc_atomic_disable,
};
-static void vop2_crtc_reset(struct drm_crtc *crtc)
-{
- struct rockchip_crtc_state *vcstate =
to_rockchip_crtc_state(crtc->state);
-
- if (crtc->state) {
- __drm_atomic_helper_crtc_destroy_state(crtc->state);
- kfree(vcstate);
- }
-
- vcstate = kzalloc(sizeof(*vcstate), GFP_KERNEL);
- if (!vcstate)
- return;
-
- crtc->state = >base;
- crtc->state->crtc = crtc;
-}
-
static struct drm_crtc_state *vop2_crtc_duplicate_state(struct drm_crtc *crtc)
{
struct rockchip_crtc_state *vcstate;
@@ -2123,6 +2106,17 @@ static void vop2_crtc_destroy_state(struct drm_crtc
*crtc,
kfree(vcstate);
}
+static void vop2_crtc_reset(struct drm_crtc *crtc)
+{
+ struct rockchip_crtc_state *vcstate =
+ kzalloc(sizeof(*vcstate), GFP_KERNEL);
+
+ if (crtc->state)
+ vop2_crtc_destroy_state(crtc, crtc->state);
+
+ __drm_atomic_helper_crtc_reset(crtc, >base);
+}
+
static const struct drm_crtc_funcs vop2_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
--
2.41.0
[PATCH 2/4] drm/rockchip: vop: Use cleanup helper directly as destroy funcs
vop_plane_destroy and vop_crtc_destroy are plain wrappers around
drm_plane_cleanup and drm_crtc_cleanup. Use them directly as plane and
crtc funcs to closer match VOP2 driver.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 60b23636a3fe..25c873d4ff53 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -766,11 +766,6 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc,
}
}
-static void vop_plane_destroy(struct drm_plane *plane)
-{
- drm_plane_cleanup(plane);
-}
-
static inline bool rockchip_afbc(u64 modifier)
{
return modifier == ROCKCHIP_AFBC_MOD;
@@ -1131,7 +1126,7 @@ static const struct drm_plane_helper_funcs
plane_helper_funcs = {
static const struct drm_plane_funcs vop_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
- .destroy = vop_plane_destroy,
+ .destroy = drm_plane_cleanup,
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
@@ -1602,11 +1597,6 @@ static const struct drm_crtc_helper_funcs
vop_crtc_helper_funcs = {
.atomic_disable = vop_crtc_atomic_disable,
};
-static void vop_crtc_destroy(struct drm_crtc *crtc)
-{
- drm_crtc_cleanup(crtc);
-}
-
static struct drm_crtc_state *vop_crtc_duplicate_state(struct drm_crtc *crtc)
{
struct rockchip_crtc_state *rockchip_state;
@@ -1711,7 +1701,7 @@ vop_crtc_verify_crc_source(struct drm_crtc *crtc, const
char *source_name,
static const struct drm_crtc_funcs vop_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
- .destroy = vop_crtc_destroy,
+ .destroy = drm_crtc_cleanup,
.reset = vop_crtc_reset,
.atomic_duplicate_state = vop_crtc_duplicate_state,
.atomic_destroy_state = vop_crtc_destroy_state,
@@ -1962,7 +1952,7 @@ static void vop_destroy_crtc(struct vop *vop)
*/
list_for_each_entry_safe(plane, tmp, _dev->mode_config.plane_list,
head)
- vop_plane_destroy(plane);
+ drm_plane_cleanup(plane);
/*
* Destroy CRTC after vop_plane_destroy() since vop_disable_plane()
--
2.41.0
[PATCH 3/4] drm/rockchip: vop2: Don't crash for invalid duplicate_state
It's possible for users to try to duplicate the CRTC state even when the
state doesn't exist. drm_atomic_helper_crtc_duplicate_state() (and other
users of __drm_atomic_helper_crtc_duplicate_state()) already guard this
with a WARN_ON() instead of crashing, so let's do that here too.
Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver")
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index ca73b8ccc29f..f725487d02ef 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -2099,11 +2099,13 @@ static void vop2_crtc_reset(struct drm_crtc *crtc)
static struct drm_crtc_state *vop2_crtc_duplicate_state(struct drm_crtc *crtc)
{
- struct rockchip_crtc_state *vcstate, *old_vcstate;
+ struct rockchip_crtc_state *vcstate;
- old_vcstate = to_rockchip_crtc_state(crtc->state);
+ if (WARN_ON(!crtc->state))
+ return NULL;
- vcstate = kmemdup(old_vcstate, sizeof(*old_vcstate), GFP_KERNEL);
+ vcstate = kmemdup(to_rockchip_crtc_state(crtc->state),
+ sizeof(*vcstate), GFP_KERNEL);
if (!vcstate)
return NULL;
--
2.41.0
[PATCH 1/4] drm/rockchip: vop: Fix reset of state in duplicate state crtc funcs
struct rockchip_crtc_state members such as output_type, output_bpc and
enable_afbc is always reset to zero in the atomic_duplicate_state crtc
funcs.
Fix this by using kmemdup on the subclass rockchip_crtc_state struct.
Fixes: 4e257d9eee23 ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config")
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index a530ecc4d207..60b23636a3fe 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1614,7 +1614,8 @@ static struct drm_crtc_state
*vop_crtc_duplicate_state(struct drm_crtc *crtc)
if (WARN_ON(!crtc->state))
return NULL;
- rockchip_state = kzalloc(sizeof(*rockchip_state), GFP_KERNEL);
+ rockchip_state = kmemdup(to_rockchip_crtc_state(crtc->state),
+sizeof(*rockchip_state), GFP_KERNEL);
if (!rockchip_state)
return NULL;
--
2.41.0
[PATCH 0/4] drm/rockchip: Fix crtc duplicate state and crtc reset funcs
This series fixes a reset of state in duplicate state crtc funcs for VOP driver, a possible crash and ensure crtc reset helper is called in VOP2 driver. Patch 1 use kmemdup instead of kzalloc to duplicate the crtc state. Patch 2 change to use crtc and plane cleanup helpers directly. Patch 3 adds a crash guard for empty crtc state. Patch 4 adds a missing call to crtc reset helper. This is the next part of an ongoing effort to upstream HDMI 2.0 support used in LibreELEC for the past 3+ years. This series is also available at [1]. [1] https://github.com/Kwiboo/linux-rockchip/commits/next-20230619-duplicate-state Jonas Karlman (4): drm/rockchip: vop: Fix crtc duplicate state drm/rockchip: vop: User cleanup helpers directly as destroy ops drm/rockchip: vop2: Don't crash for invalid duplicate_state drm/rockchip: vop2: Add missing call to crtc reset helper drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 19 +++ drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 36 +--- 2 files changed, 21 insertions(+), 34 deletions(-) -- 2.41.0
[PATCH v4 1/2] drm/fourcc: Add NV20 and NV30 YUV formats
DRM_FORMAT_NV20 and DRM_FORMAT_NV30 formats is the 2x1 and non-subsampled
variant of NV15, a 10-bit 2-plane YUV format that has no padding between
components. Instead, luminance and chrominance samples are grouped into 4s
so that each group is packed into an integer number of bytes:
= UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '20' and '30' suffix refers to the optimum effective bits per pixel
which is achieved when the total number of luminance samples is a multiple
of 4.
V2: Added NV30 format
Signed-off-by: Jonas Karlman
Reviewed-by: Sandy Huang
---
drivers/gpu/drm/drm_fourcc.c | 8
include/uapi/drm/drm_fourcc.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 0f17dfa8702b..193cf8ed7912 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -299,6 +299,14 @@ const struct drm_format_info *__drm_format_info(u32 format)
.num_planes = 2, .char_per_block = { 5, 5, 0 },
.block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
.vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_NV20,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
+ .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_NV30,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 1,
+ .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Q410,.depth = 0,
.num_planes = 3, .char_per_block = { 2, 2, 2 },
.block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 1,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8db7fd3f743e..3151f1fc7ebb 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -323,6 +323,8 @@ extern "C" {
* index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
*/
#define DRM_FORMAT_NV15fourcc_code('N', 'V', '1', '5') /* 2x2
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV20fourcc_code('N', 'V', '2', '0') /* 2x1
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV30fourcc_code('N', 'V', '3', '0') /*
non-subsampled Cr:Cb plane */
/*
* 2 plane YCbCr MSB aligned
--
2.40.1
[PATCH v4 2/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support
Add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by
the Rockchip Video Decoder on RK322X, RK3288, RK3328 and RK3399.
Also add support for 10-bit 4:4:4 format while at it.
V4: Rework RK3328/RK3399 win0/1 data to not affect RK3368
V2: Added NV30 support
Signed-off-by: Jonas Karlman
Reviewed-by: Sandy Huang
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 29 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 63 +
3 files changed, 81 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index a530ecc4d207..fa0405ad0acf 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -273,6 +273,18 @@ static bool has_uv_swapped(uint32_t format)
}
}
+static bool is_fmt_10(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV15:
+ case DRM_FORMAT_NV20:
+ case DRM_FORMAT_NV30:
+ return true;
+ default:
+ return false;
+ }
+}
+
static enum vop_data_format vop_convert_format(uint32_t format)
{
switch (format) {
@@ -288,12 +300,15 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV15:
case DRM_FORMAT_NV21:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV20:
case DRM_FORMAT_NV61:
return VOP_FMT_YUV422SP;
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV30:
case DRM_FORMAT_NV42:
return VOP_FMT_YUV444SP;
default:
@@ -944,7 +959,12 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (fb->format->block_w[0])
+ offset = (src->x1 >> 16) * fb->format->char_per_block[0] /
+fb->format->block_w[0];
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -970,6 +990,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
}
VOP_WIN_SET(vop, win, format, format);
+ VOP_WIN_SET(vop, win, fmt_10, is_fmt_10(fb->format->format));
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, y2r_en, is_yuv);
@@ -986,7 +1007,11 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = fb->obj[1];
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (fb->format->block_w[1])
+ offset = (src->x1 >> 16) * bpp /
+fb->format->block_w[1] / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 5f56e0597df8..4b2daefeb8c1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -186,6 +186,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg uv_swap;
struct vop_reg act_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 20ac7811c5eb..4f1134010498 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -53,6 +53,23 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV42,
};
+static const uint32_t formats_win_full_10[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_BGR565,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_NV16,
+ DRM_FORMAT_NV24,
+ DRM_FORMAT_NV15,
+ DRM_FORMAT_NV20,
+ DRM_FORMAT_NV30,
+};
+
static const uint64_t format_modifiers_win_full[] = {
DRM_FORMAT_MOD_LINEAR,
DRM_FORMA
[PATCH v4 0/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support
This series add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399. Also include 10-bit 4:4:4 support since VOP can support that also. First patch adds new fourcc 10-bit YUV formats with 4:2:2/4:4:4 sub-sampling. Second patch adds support for displaying the new fourcc formats. These patches has been in use by LibreELEC and other distros for the past 3+ years, hoping they can be merged this time around :-) Changes in v4: - Rework RK3328/RK3399 win0/1 data to not affect RK3368 Changes in v3: - No changes, rebased on next-20230616 - R-B tags was collected Changes in v2: - Add NV30 format - R-B tags was not collected due to NV30 changes This series is also available at [1]. [1] https://github.com/Kwiboo/linux-rockchip/commits/next-20230616-vop-nv15 Jonas Karlman (2): drm/fourcc: Add NV20 and NV30 YUV formats drm/rockchip: vop: Add NV15, NV20 and NV30 support drivers/gpu/drm/drm_fourcc.c| 8 +++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 29 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 63 + include/uapi/drm/drm_fourcc.h | 2 + 5 files changed, 91 insertions(+), 12 deletions(-) -- 2.40.1
[PATCH v3 1/2] drm/fourcc: Add NV20 and NV30 YUV formats
DRM_FORMAT_NV20 and DRM_FORMAT_NV30 formats is the 2x1 and non-subsampled
variant of NV15, a 10-bit 2-plane YUV format that has no padding between
components. Instead, luminance and chrominance samples are grouped into 4s
so that each group is packed into an integer number of bytes:
= UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '20' and '30' suffix refers to the optimum effective bits per pixel
which is achieved when the total number of luminance samples is a multiple
of 4.
V2: Added NV30 format
Signed-off-by: Jonas Karlman
Reviewed-by: Sandy Huang
---
drivers/gpu/drm/drm_fourcc.c | 8
include/uapi/drm/drm_fourcc.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 0f17dfa8702b..193cf8ed7912 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -299,6 +299,14 @@ const struct drm_format_info *__drm_format_info(u32 format)
.num_planes = 2, .char_per_block = { 5, 5, 0 },
.block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
.vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_NV20,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
+ .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_NV30,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 1,
+ .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Q410,.depth = 0,
.num_planes = 3, .char_per_block = { 2, 2, 2 },
.block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 1,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8db7fd3f743e..3151f1fc7ebb 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -323,6 +323,8 @@ extern "C" {
* index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
*/
#define DRM_FORMAT_NV15fourcc_code('N', 'V', '1', '5') /* 2x2
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV20fourcc_code('N', 'V', '2', '0') /* 2x1
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV30fourcc_code('N', 'V', '3', '0') /*
non-subsampled Cr:Cb plane */
/*
* 2 plane YCbCr MSB aligned
--
2.40.1
[PATCH v3 2/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support
Add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the
Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399.
Also add support for 10-bit 4:4:4 format while at it.
V2: Added NV30 support
Signed-off-by: Jonas Karlman
Reviewed-by: Sandy Huang
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 29 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 32 +
3 files changed, 54 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 60b23636a3fe..3984265a6d8f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -273,6 +273,18 @@ static bool has_uv_swapped(uint32_t format)
}
}
+static bool is_fmt_10(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV15:
+ case DRM_FORMAT_NV20:
+ case DRM_FORMAT_NV30:
+ return true;
+ default:
+ return false;
+ }
+}
+
static enum vop_data_format vop_convert_format(uint32_t format)
{
switch (format) {
@@ -288,12 +300,15 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV15:
case DRM_FORMAT_NV21:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV20:
case DRM_FORMAT_NV61:
return VOP_FMT_YUV422SP;
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV30:
case DRM_FORMAT_NV42:
return VOP_FMT_YUV444SP;
default:
@@ -944,7 +959,12 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (fb->format->block_w[0])
+ offset = (src->x1 >> 16) * fb->format->char_per_block[0] /
+fb->format->block_w[0];
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -970,6 +990,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
}
VOP_WIN_SET(vop, win, format, format);
+ VOP_WIN_SET(vop, win, fmt_10, is_fmt_10(fb->format->format));
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, y2r_en, is_yuv);
@@ -986,7 +1007,11 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = fb->obj[1];
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (fb->format->block_w[1])
+ offset = (src->x1 >> 16) * bpp /
+fb->format->block_w[1] / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 5f56e0597df8..4b2daefeb8c1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -186,6 +186,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg uv_swap;
struct vop_reg act_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 20ac7811c5eb..7f72dcac6f0e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -53,6 +53,23 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV42,
};
+static const uint32_t formats_win_full_10[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_BGR565,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_NV16,
+ DRM_FORMAT_NV24,
+ DRM_FORMAT_NV15,
+ DRM_FORMAT_NV20,
+ DRM_FORMAT_NV30,
+};
+
static const uint64_t format_modifiers_win_full[] = {
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID,
@@ -627,11 +644,12 @@ st
[PATCH v3 0/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support
This is a revival of a 3 year old series that never got picked up, see [1]. This series add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399. Also include 10-bit 4:4:4 support since VOP can support that also. First patch adds new fourcc 10-bit YUV formats with 4:2:2/4:4:4 sub-sampling. Second patch adds support for displaying the new fourcc formats. These patches has been in use by LibreELEC and other distros for the past 3+ years, hoping they can be merged this time around :-) Changes in v3: - No changes, rebased on next-20230616 - R-B tags was collected Changes in v2: - Add NV30 format - R-B tags was not collected due to NV30 changes This series is also available at [2]. [1] https://lore.kernel.org/all/20200706223009.1200-1-jo...@kwiboo.se/ [2] https://github.com/Kwiboo/linux-rockchip/commits/next-20230616-vop-nv15 Jonas Karlman (2): drm/fourcc: Add NV20 and NV30 YUV formats drm/rockchip: vop: Add NV15, NV20 and NV30 support drivers/gpu/drm/drm_fourcc.c| 8 ++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 29 +-- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 32 + include/uapi/drm/drm_fourcc.h | 2 ++ 5 files changed, 64 insertions(+), 8 deletions(-) -- 2.40.1
Re: [PATCH v4 4/4] drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks
Hi Sascha,
On 2023-02-07 13:51, Sascha Hauer wrote:
> On Tue, Feb 07, 2023 at 11:01:26AM +0000, Jonas Karlman wrote:
>> Hi Sascha,
>>
>> On 2023-02-07 09:44, Sascha Hauer wrote:
>>> The Rockchip PLL drivers are currently table based and support only
>>> the most common pixelclocks. Discard all modes we cannot achieve
>>> at all. Normally the desired pixelclocks have an exact match in the
>>> PLL driver, nevertheless allow for a 0.1% error just in case.
>>>
>>> Tested-by: Nicolas Frattaroli
>>> Tested-by: Michael Riesch
>>> Tested-by: Dan Johansen
>>> Link:
>>> https://lore.kernel.org/r/20230118132213.2911418-4-s.ha...@pengutronix.de>>>>
>>> Signed-off-by: Sascha Hauer
>>> ---
>>> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 +-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>>> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>>> index feba6b9becd6c..725952811752b 100644
>>> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
>>> @@ -256,10 +256,14 @@ dw_hdmi_rockchip_mode_valid(struct dw_hdmi *dw_hdmi,
>>> void *data,
>>> {
>>> struct rockchip_hdmi *hdmi = data;
>>> const struct dw_hdmi_mpll_config *mpll_cfg = rockchip_mpll_cfg;
>>> - int pclk = mode->clock * 1000;
>>> + int rpclk, pclk = mode->clock * 1000;
>>> bool exact_match = hdmi->plat_data->phy_force_vendor;
>>> int i;
>>>
>>> + rpclk = clk_round_rate(hdmi->ref_clk, pclk);
>>> + if (abs(rpclk - pclk) > pclk / 1000)
>>> + return MODE_NOCLOCK;
>>
>> The ref_clk is optional and rk3228/rk3328 dts do not supply a ref or vpll
>> clock.
>
> That's a bit unfortunate as we can't do this check then on these SoCs.
>
> The clock is likely actually there in the system and maybe even in the
> clock driver, just not wired up to the HDMI. I don't know which one it
> is though, so I am afraid there's not much I can do about it other than
> just skipping the check when the clock is not there.
For rk3228/rk3328 I think just skipping the rate check when there is
no ref_clk should be fine.
The clock is provided by phy-rockchip-inno-hdmi.c for rk3228/rk3328. And
I recall we used to add ref/vpll clock to device tree to do something
similar in LibreELEC with our initial work-in-progress HDMI2.0 patches.
We have since then opted to just filter modes based on clk_round_rate
for !phy_force_vendor and instead extend the inno-hdmi pll table with
common hdmi/dvi clock rates, see [1] for the current state of RK HDMI2.0
related patches we use in LibreELEC.
Hopefully I can find some time in coming weeks to restart the work of
testing and sending those patches upstream, rebased on top of this series.
[1]
https://github.com/Kwiboo/linux-rockchip/compare/v6.2-rc7...rockchip-6.2-hdmi2.0
Regards,
Jonas
>
> Sascha
>
Re: [PATCH v4 4/4] drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks
Hi Sascha,
On 2023-02-07 09:44, Sascha Hauer wrote:
> The Rockchip PLL drivers are currently table based and support only
> the most common pixelclocks. Discard all modes we cannot achieve
> at all. Normally the desired pixelclocks have an exact match in the
> PLL driver, nevertheless allow for a 0.1% error just in case.
>
> Tested-by: Nicolas Frattaroli
> Tested-by: Michael Riesch
> Tested-by: Dan Johansen
> Link:
> https://lore.kernel.org/r/20230118132213.2911418-4-s.ha...@pengutronix.de
> Signed-off-by: Sascha Hauer
> ---
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index feba6b9becd6c..725952811752b 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -256,10 +256,14 @@ dw_hdmi_rockchip_mode_valid(struct dw_hdmi *dw_hdmi,
> void *data,
> {
> struct rockchip_hdmi *hdmi = data;
> const struct dw_hdmi_mpll_config *mpll_cfg = rockchip_mpll_cfg;
> - int pclk = mode->clock * 1000;
> + int rpclk, pclk = mode->clock * 1000;
> bool exact_match = hdmi->plat_data->phy_force_vendor;
> int i;
>
> + rpclk = clk_round_rate(hdmi->ref_clk, pclk);
> + if (abs(rpclk - pclk) > pclk / 1000)
> + return MODE_NOCLOCK;
The ref_clk is optional and rk3228/rk3328 dts do not supply a ref or vpll clock.
Regards,
Jonas
> +
> for (i = 0; mpll_cfg[i].mpixelclock != (~0UL); i++) {
> /*
>* For vendor specific phys force an exact match of the
> pixelclock
Re: [PATCH v4 1/4] drm/rockchip: vop: limit maximium resolution to hardware capabilities
Hi Sascha,
On 2023-02-07 09:44, Sascha Hauer wrote:
> The different VOP variants support different maximum resolutions. Reject
> resolutions that are not supported by a specific variant.
>
> This hasn't been a problem in the upstream driver so far as 1920x1080
> has been the maximum resolution supported by the HDMI driver and that
> resolution is supported by all VOP variants. Now with higher resolutions
> supported in the HDMI driver we have to limit the resolutions to the
> ones supported by the VOP.
>
> The actual maximum resolutions are taken from the Rockchip downstream
> Kernel.
>
> Signed-off-by: Sascha Hauer
> ---
>
> Notes:
> Changes since v3:
> - new patch
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 ++
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 ++
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 31 +
> 3 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index fa1f4ee6d1950..96b6bd8d17803 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -1174,6 +1174,20 @@ static void vop_crtc_disable_vblank(struct drm_crtc
> *crtc)
> spin_unlock_irqrestore(>irq_lock, flags);
> }
>
> +static enum drm_mode_status vop_crtc_mode_valid(struct drm_crtc *crtc,
> + const struct drm_display_mode
> *mode)
> +{
> + struct vop *vop = to_vop(crtc);
> +
> + if (vop->data->max_xres && mode->hdisplay > vop->data->max_xres)
> + return MODE_BAD_HVALUE;
> +
> + if (vop->data->max_yres && mode->vdisplay > vop->data->max_yres)
> + return MODE_BAD_VVALUE;
> +
> + return MODE_OK;
> +}
> +
> static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
> @@ -1585,6 +1599,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
> }
>
> static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
> + .mode_valid = vop_crtc_mode_valid,
> .mode_fixup = vop_crtc_mode_fixup,
> .atomic_check = vop_crtc_atomic_check,
> .atomic_begin = vop_crtc_atomic_begin,
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> index 8502849833d93..5c4875ca3f270 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> @@ -225,6 +225,8 @@ struct vop_data {
> const struct vop_win_data *win;
> unsigned int win_size;
> unsigned int lut_size;
> + unsigned int max_xres;
> + unsigned int max_yres;
I would suggest using the same struct vop_rect max_input/output as the
vop2 driver instead of handling this differently between the two.
Regards,
Jonas
>
> #define VOP_FEATURE_OUTPUT_RGB10 BIT(0)
> #define VOP_FEATURE_INTERNAL_RGB BIT(1)
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> index 014f99e8928e3..dc1a703d9d1a8 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> @@ -181,6 +181,8 @@ static const struct vop_data rk3036_vop = {
> .output = _output,
> .win = rk3036_vop_win_data,
> .win_size = ARRAY_SIZE(rk3036_vop_win_data),
> + .max_xres = 1920,
> + .max_yres = 1080,
> };
>
> static const struct vop_win_phy rk3126_win1_data = {
> @@ -213,6 +215,8 @@ static const struct vop_data rk3126_vop = {
> .output = _output,
> .win = rk3126_vop_win_data,
> .win_size = ARRAY_SIZE(rk3126_vop_win_data),
> + .max_xres = 1920,
> + .max_yres = 1080,
> };
>
> static const int px30_vop_intrs[] = {
> @@ -340,6 +344,8 @@ static const struct vop_data px30_vop_big = {
> .output = _output,
> .win = px30_vop_big_win_data,
> .win_size = ARRAY_SIZE(px30_vop_big_win_data),
> + .max_xres = 1920,
> + .max_yres = 1080,
> };
>
> static const struct vop_win_data px30_vop_lit_win_data[] = {
> @@ -356,6 +362,8 @@ static const struct vop_data px30_vop_lit = {
> .output = _output,
> .win = px30_vop_lit_win_data,
> .win_size = ARRAY_SIZE(px30_vop_lit_win_data),
> + .max_xres = 1920,
> + .max_yres = 1080,
> };
>
> static const struct vop_scl_regs rk3066_win_scl = {
> @@ -479,6 +487,8 @@ static const struct vop_data rk3066_vop = {
> .output = _output,
> .win = rk3066_vop_win_data,
> .win_size = ARRAY_SIZE(rk3066_vop_win_data),
> + .max_xres = 1920,
> + .max_yres = 1080,
> };
>
> static const struct vop_scl_regs rk3188_win_scl = {
> @@ -585,6 +595,8 @@ static const struct vop_data rk3188_vop = {
> .win = rk3188_vop_win_data,
> .win_size = ARRAY_SIZE(rk3188_vop_win_data),
> .feature =
Re: [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support
Hi, On 2023-02-03 14:09, Sascha Hauer wrote: > Hi, > > On Wed, Feb 01, 2023 at 09:23:56AM +0900, FUKAUMI Naoki wrote: >> hi, >> >> I'm trying this patch series with 6.1.x kernel. it works fine on rk356x >> based boards (ROCK 3), but it has a problem on rk3399 boards (ROCK 4). >> >> on rk3399 with this patch, I can see large noise area (about one third right >> side of the screen) at 4k@30. 1080p works fine as same as before. >> >> can someone reproduce this problem on rk3399? > > I have a RK339 board here, I can try to reproduce this next week. Of > course I have no idea what the issue might be, in the downstream Kernel > I can't find anything that is handled specially for the RK3399. > > What might be worth checking is the VOP clock rate. Does the VOP clock > in /sys/kernel/debug/clk/clk_summary (I don't know which one it is > though) match the pixelclock? > > If nothing else helps I can change the code to only allow the higher > resolutions on RK3568 where we know it works. This series only seem to pick up part of the dw-hdmi related changes that originates from an old chromium 4.4 kernel. Maybe that is the reason this cause issues on other SoCs? I have very recently resumed kernel coding after being away for the last 2-3 years and was planning on resuming work on a HDMI 2.0 series based on old work at [1], [2] and [3]. Those patches never got any traction last time around, maybe there is more interest now, seeing this series :-) I was planning on basing such series on top of this, but seeing how this seem to have issues on other SoCs I am not sure how to proceed. With the patches at [3] (and related patches) HDMI 2.0 modes (4K@60hz) is possible with at least RK3288, RK3328, RK3399 and RK3568 SoCs. However, those patches needs to be cleaned up a bit before they will hit the mailing list. [1] https://lore.kernel.org/all/20200108210740.28769-1-jo...@kwiboo.se/ [2] https://lore.kernel.org/all/20200922205933.5540-1-jo...@kwiboo.se/ [3] https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Rockchip/patches/linux/default/linux-1000-drm-rockchip.patch Regards, Jonas > > Sascha > >> >> -- >> FUKAUMI Naoki >> >> On 1/31/23 17:09, Sascha Hauer wrote: >>> Heiko, Sandy, >>> >>> Ok to apply these patches? >>> >>> Sascha >>> >>> On Wed, Jan 18, 2023 at 02:22:10PM +0100, Sascha Hauer wrote: It's been some time since I last sent this series. This version fixes a regression Dan Johansen reported. The reason turned out to be simple, I used the YUV420 register values instead of the RGB ones. I realized that we cannot achieve several modes offered by my monitor as these require pixelclocks that are slightly below the standard pixelclocks. As these are lower than the standard clock rates the PLL driver offers the clk driver falls back to a way lower frequency which results in something the monitor can't display, so this series now contains a patch to discard these unachievable modes. Sascha Changes since v2: - Use correct register values for mpll_cfg - Add patch to discard modes we cannot achieve Changes since v1: - Allow non standard clock rates only on Synopsys phy as suggested by Robin Murphy Sascha Hauer (3): drm/rockchip: dw_hdmi: relax mode_valid hook drm/rockchip: dw_hdmi: Add support for 4k@30 resolution drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 40 - 1 file changed, 32 insertions(+), 8 deletions(-) -- 2.30.2 >>> >> >> >
Re: [PATCH v2 14/14] phy/rockchip: inno-hdmi: Support more pre-pll configuration
On 2020-07-07 21:53, Johan Jonker wrote:
>
> Hi,
>
> What's the status for this patch?
> This is just what I needed for A95X Z2 to get the vop+hdmi and monitor
> working. ;)
>
> Could this become applied to mainline already?
> The ack is already there.
I will send a v3 of the phy/rockchip parts of this series later
tonight/tomorrow.
The drm side still need work and I have some pending patches that also
improve rk3288/rk3399 hdmi support for up to 4k@30hz, should make its way
onto the list in a few days.
Regards,
Jonas
>
> Thanks,
>
> Johan Jonker
>
> https://lore.kernel.org/lkml/20200620134659.4592-1-jbx6...@gmail.com/
>
> On 1/8/20 10:07 PM, Jonas Karlman wrote:
>> From: Algea Cao
>>
>> Adding the following freq cfg in 8-bit and 10-bit color depth:
>>
>> {
>> 4000, 6500, 7100, 8350, 8575,
>> 8875, 10800, 11900, 16200
>> }
>>
>> New freq has been validated by quantumdata 980.
>>
>> For some freq which can't be got by only using integer freq div,
>> frac freq div is needed, Such as 88.75Mhz 10-bit. But The actual
>> freq is different from the target freq, We must try to narrow
>> the gap between them. RK322X only support integer freq div.
>>
>> The VCO of pre-PLL must be more than 2Ghz, otherwise PLL may be
>> unlocked.
>>
>> Signed-off-by: Algea Cao
>> Signed-off-by: Jonas Karlman
>> Acked-by: Heiko Stuebner
>> ---
>> drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 74 ---
>> 1 file changed, 49 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
>> b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
>> index 3719309ad0d0..bb8bdf5e3301 100644
>> --- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
>> +++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
>> @@ -291,32 +291,56 @@ struct inno_hdmi_phy_drv_data {
>> const struct phy_config *phy_cfg_table;
>> };
>>
>> +/*
>> + * If only using integer freq div can't get frequency we want, frac
>> + * freq div is needed. For example, pclk 88.75 Mhz and tmdsclk
>> + * 110.9375 Mhz must use frac div 0xF0. The actual frequency is
>> different
>> + * from the target frequency. Such as the tmds clock 110.9375 Mhz,
>> + * the actual tmds clock we get is 110.93719 Mhz. It is important
>> + * to note that RK322X platforms do not support frac div.
>> + */
>> static const struct pre_pll_config pre_pll_cfg_table[] = {
>> -{ 2700, 2700, 1, 90, 3, 2, 2, 10, 3, 3, 4, 0, 0},
>> -{ 2700, 3375, 1, 90, 1, 3, 3, 10, 3, 3, 4, 0, 0},
>> -{ 4000, 4000, 1, 80, 2, 2, 2, 12, 2, 2, 2, 0, 0},
>> -{ 59341000, 59341000, 1, 98, 3, 1, 2, 1, 3, 3, 4, 0, 0xE6AE6B},
>> -{ 5940, 5940, 1, 99, 3, 1, 1, 1, 3, 3, 4, 0, 0},
>> -{ 59341000, 74176250, 1, 98, 0, 3, 3, 1, 3, 3, 4, 0, 0xE6AE6B},
>> -{ 5940, 7425, 1, 99, 1, 2, 2, 1, 3, 3, 4, 0, 0},
>> -{ 74176000, 74176000, 1, 98, 1, 2, 2, 1, 2, 3, 4, 0, 0xE6AE6B},
>> -{ 7425, 7425, 1, 99, 1, 2, 2, 1, 2, 3, 4, 0, 0},
>> -{ 74176000, 9272, 4, 494, 1, 2, 2, 1, 3, 3, 4, 0, 0x816817},
>> -{ 7425, 92812500, 4, 495, 1, 2, 2, 1, 3, 3, 4, 0, 0},
>> -{148352000, 148352000, 1, 98, 1, 1, 1, 1, 2, 2, 2, 0, 0xE6AE6B},
>> -{14850, 14850, 1, 99, 1, 1, 1, 1, 2, 2, 2, 0, 0},
>> -{148352000, 18544, 4, 494, 0, 2, 2, 1, 3, 2, 2, 0, 0x816817},
>> -{14850, 185625000, 4, 495, 0, 2, 2, 1, 3, 2, 2, 0, 0},
>> -{296703000, 296703000, 1, 98, 0, 1, 1, 1, 0, 2, 2, 0, 0xE6AE6B},
>> -{29700, 29700, 1, 99, 0, 1, 1, 1, 0, 2, 2, 0, 0},
>> -{296703000, 370878750, 4, 494, 1, 2, 0, 1, 3, 1, 1, 0, 0x816817},
>> -{29700, 37125, 4, 495, 1, 2, 0, 1, 3, 1, 1, 0, 0},
>> -{593407000, 296703500, 1, 98, 0, 1, 1, 1, 0, 2, 1, 0, 0xE6AE6B},
>> -{59400, 29700, 1, 99, 0, 1, 1, 1, 0, 2, 1, 0, 0},
>> -{593407000, 370879375, 4, 494, 1, 2, 0, 1, 3, 1, 1, 1, 0x816817},
>> -{59400, 37125, 4, 495, 1, 2, 0, 1, 3, 1, 1, 1, 0},
>> -{593407000, 593407000, 1, 98, 0, 2, 0, 1, 0, 1, 1, 0, 0xE6AE6B},
>> -{59400, 59400, 1, 99, 0, 2, 0, 1, 0, 1, 1, 0, 0},
>> +{ 2700, 2700, 1, 90, 3, 2, 2, 10, 3, 3, 4, 0, 0},
>> +{ 2700, 3375, 1, 90, 1, 3, 3, 10, 3, 3, 4, 0, 0},
>> +{ 4000, 4000, 1, 80, 2, 2, 2, 12, 2, 2, 2, 0, 0},
>> +{ 4000, 5000, 1, 100, 2, 2, 2, 1, 0, 0, 15, 0, 0},
>> +{ 5934
[PATCH v2 2/2] drm: rockchip: add NV15, NV20 and NV30 support
Add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the
Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399.
Also add support for 10-bit 4:4:4 format while at it.
V2: Added NV30 support
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 29 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 32 +
3 files changed, 54 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c80f7d9fd13f..eb663e25ad9e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -261,6 +261,18 @@ static bool has_rb_swapped(uint32_t format)
}
}
+static bool is_fmt_10(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV15:
+ case DRM_FORMAT_NV20:
+ case DRM_FORMAT_NV30:
+ return true;
+ default:
+ return false;
+ }
+}
+
static enum vop_data_format vop_convert_format(uint32_t format)
{
switch (format) {
@@ -276,10 +288,13 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV15:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV20:
return VOP_FMT_YUV422SP;
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV30:
return VOP_FMT_YUV444SP;
default:
DRM_ERROR("unsupported format[%08x]\n", format);
@@ -922,7 +937,12 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (fb->format->block_w[0])
+ offset = (src->x1 >> 16) * fb->format->char_per_block[0] /
+fb->format->block_w[0];
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -948,6 +968,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
}
VOP_WIN_SET(vop, win, format, format);
+ VOP_WIN_SET(vop, win, fmt_10, is_fmt_10(fb->format->format));
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, y2r_en, is_yuv);
@@ -964,7 +985,11 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = fb->obj[1];
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (fb->format->block_w[1])
+ offset = (src->x1 >> 16) * bpp /
+fb->format->block_w[1] / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 4a2099cb582e..eab055d9b56d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -154,6 +154,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg act_info;
struct vop_reg dsp_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 80053d91a301..2c55e1852c3d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -50,6 +50,23 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV24,
};
+static const uint32_t formats_win_full_10[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_BGR565,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_NV16,
+ DRM_FORMAT_NV24,
+ DRM_FORMAT_NV15,
+ DRM_FORMAT_NV20,
+ DRM_FORMAT_NV30,
+};
+
static const uint64_t format_modifiers_win_full[] = {
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID,
@@ -579,11 +596,12 @@ static const struct vop_scl_regs rk3288_win
[PATCH v2 0/2] drm: rockchip: add NV15, NV20 and NV30 support
Hi, This series adds support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399. Also include 10-bit 4:4:4 support since VOP can support that also. First patch adds new fourcc 10-bit YUV formats with 4:2:2/4:4:4 sub-sampling. Second patch adds support for displaying the the new fourcc formats. Changes in v2: - Add NV30 format - R-B tags was not collected due to NV30 changes This series has been tested on RK3399 using a Rockchip Video Decoder series at [1] together with ffmpeg at [2] and kodi-gbm or mpv. [3] contains all patches needed on top of linux-media master for easy testing. [1] https://patchwork.linuxtv.org/project/linux-media/list/?series=2859 [2] https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.3-rkvdec-high-10 [3] https://github.com/Kwiboo/linux-rockchip/commits/linuxtv-rkvdec-high-10-v2 Regards, Jonas Jonas Karlman (2): drm: drm_fourcc: add NV20 and NV30 YUV formats drm: rockchip: add NV15, NV20 and NV30 support drivers/gpu/drm/drm_fourcc.c| 8 ++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 29 +-- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 32 + include/uapi/drm/drm_fourcc.h | 2 ++ 5 files changed, 64 insertions(+), 8 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm: drm_fourcc: add NV20 and NV30 YUV formats
DRM_FORMAT_NV20 and DRM_FORMAT_NV30 formats is the 2x1 and non-subsampled
variant of NV15, a 10-bit 2-plane YUV format that has no padding between
components. Instead, luminance and chrominance samples are grouped into 4s
so that each group is packed into an integer number of bytes:
= UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '20' and '30' suffix refers to the optimum effective bits per pixel
which is achieved when the total number of luminance samples is a multiple
of 4.
V2: Added NV30 format
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/drm_fourcc.c | 8
include/uapi/drm/drm_fourcc.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 722c7ebe4e88..2daf8a304b53 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -278,6 +278,14 @@ const struct drm_format_info *__drm_format_info(u32 format)
.num_planes = 2, .char_per_block = { 5, 5, 0 },
.block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
.vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_NV20,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
+ .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_NV30,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 1,
+ .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Q410,.depth = 0,
.num_planes = 3, .char_per_block = { 2, 2, 2 },
.block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index cbf92fdf2712..c8695673295c 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -242,6 +242,8 @@ extern "C" {
* index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
*/
#define DRM_FORMAT_NV15fourcc_code('N', 'V', '1', '5') /* 2x2
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV20fourcc_code('N', 'V', '2', '0') /* 2x1
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV30fourcc_code('N', 'V', '3', '0') /*
non-subsampled Cr:Cb plane */
/*
* 2 plane YCbCr MSB aligned
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: drm_fourcc: add NV20 YUV format【请注意，邮件由linux-rockchip-bounces+sandy.huang=rock-chips....@lists.infradead.org代发】
On 2020-06-17 14:07, Huang Jiachai wrote:
> Hi Jonas Karlman,
>
> Is there an another yuv 10bit format with 4:4:4 sub-simpling but
> has no padding?
>
> Maybe we can call it DRM_FORMAT_NV30:
>
> { .format = DRM_FORMAT_NV30, .depth = 0,
>.num_planes = 2, .char_per_block = { 5, 5, 0 },
>.block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 1,
>.vsub = 1, .is_yuv = true },
>
> this format can supported by rockchip rk3288/rk3399... platform, can you
> add this format at this series patches?
I will send a v2 including this 4:4:4 format later this weekend.
Is there any hw block on rk3288/rk3399 that can produce a buffer in such format?
If I am not mistaken rkvdec only support 10-bit h264 in 4:2:0/4:2:2 and
hevc 4:2:0 10-bit, those are the formats I have been able to test so far.
Regards,
Jonas
>
> 在 2020/6/8 4:25, Jonas Karlman 写道:
>> DRM_FORMAT_NV20 is a 2 plane format suitable for linear memory layout.
>> The format is similar to P210 with 4:2:2 sub-sampling but has no padding
>> between components. Instead, luminance and chrominance samples are grouped
>> into 4s so that each group is packed into an integer number of bytes:
>>
>> = UVUV = 4 * 10 bits = 40 bits = 5 bytes
>>
>> The '20' suffix refers to the optimum effective bits per pixel which is
>> achieved when the total number of luminance samples is a multiple of 4.
>>
>> Signed-off-by: Jonas Karlman
>> ---
>> drivers/gpu/drm/drm_fourcc.c | 4
>> include/uapi/drm/drm_fourcc.h | 1 +
>> 2 files changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>> index 722c7ebe4e88..2a9c8ae719ed 100644
>> --- a/drivers/gpu/drm/drm_fourcc.c
>> +++ b/drivers/gpu/drm/drm_fourcc.c
>> @@ -278,6 +278,10 @@ const struct drm_format_info *__drm_format_info(u32
>> format)
>>.num_planes = 2, .char_per_block = { 5, 5, 0 },
>>.block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
>>.vsub = 2, .is_yuv = true },
>> +{ .format = DRM_FORMAT_NV20,.depth = 0,
>> + .num_planes = 2, .char_per_block = { 5, 5, 0 },
>> + .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
>> + .vsub = 1, .is_yuv = true },
>> { .format = DRM_FORMAT_Q410,.depth = 0,
>>.num_planes = 3, .char_per_block = { 2, 2, 2 },
>>.block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>> index b5bf1c0e630e..244d32433a67 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -242,6 +242,7 @@ extern "C" {
>>* index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
>>*/
>> #define DRM_FORMAT_NV15fourcc_code('N', 'V', '1', '5') /* 2x2
>> subsampled Cr:Cb plane */
>> +#define DRM_FORMAT_NV20 fourcc_code('N', 'V', '2', '0') /* 2x1
>> subsampled Cr:Cb plane */
>>
>> /*
>>* 2 plane YCbCr MSB aligned
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm: rockchip: add NV15 and NV20 support
Hi, This series adds support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399. First patch adds a new fourcc 10-bit YUV format with 4:2:2 sub-sampling. Second patch adds support for using the the two new fourcc formats. Both depend on "drm: drm_fourcc: add NV15, Q410, Q401 YUV formats" at [1]. This series can also be found at [2], and can be tested on RK3399 using an upcoming rkvdec series at [3] together with ffmpeg at [4] and kodi-gbm or mpv. [1] https://patchwork.freedesktop.org/series/76326/ [2] https://github.com/Kwiboo/linux-rockchip/commits/next-20200605-fmt_10 [3] https://github.com/Kwiboo/linux-rockchip/commits/next-20200605-rkvdec [4] https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.2.2-rkvdec Regards, Jonas Jonas Karlman (2): drm: drm_fourcc: add NV20 YUV format drm: rockchip: add NV15 and NV20 support drivers/gpu/drm/drm_fourcc.c| 4 +++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 -- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 31 + include/uapi/drm/drm_fourcc.h | 1 + 5 files changed, 56 insertions(+), 8 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: rockchip: add NV15 and NV20 support
Add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the
Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 27 --
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 31 +
3 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 33463b79a37b..13a0682d438b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -261,6 +261,17 @@ static bool has_rb_swapped(uint32_t format)
}
}
+static bool is_fmt_10(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV15:
+ case DRM_FORMAT_NV20:
+ return true;
+ default:
+ return false;
+ }
+}
+
static enum vop_data_format vop_convert_format(uint32_t format)
{
switch (format) {
@@ -276,8 +287,10 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV15:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV20:
return VOP_FMT_YUV422SP;
case DRM_FORMAT_NV24:
return VOP_FMT_YUV444SP;
@@ -922,7 +935,12 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (fb->format->block_w[0])
+ offset = (src->x1 >> 16) * fb->format->char_per_block[0] /
+fb->format->block_w[0];
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -948,6 +966,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
}
VOP_WIN_SET(vop, win, format, format);
+ VOP_WIN_SET(vop, win, fmt_10, is_fmt_10(fb->format->format));
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, y2r_en, is_yuv);
@@ -964,7 +983,11 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = fb->obj[1];
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (fb->format->block_w[1])
+ offset = (src->x1 >> 16) * bpp /
+fb->format->block_w[1] / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index d03bdb531ef2..db1138da2bd4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -154,6 +154,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg act_info;
struct vop_reg dsp_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 2413deded22c..503736c8b6c4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -50,6 +50,22 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV24,
};
+static const uint32_t formats_win_full_10[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_BGR565,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_NV16,
+ DRM_FORMAT_NV24,
+ DRM_FORMAT_NV15,
+ DRM_FORMAT_NV20,
+};
+
static const uint64_t format_modifiers_win_full[] = {
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID,
@@ -570,11 +586,12 @@ static const struct vop_scl_regs rk3288_win_full_scl = {
static const struct vop_win_phy rk3288_win01_data = {
.scl = _win_full_scl,
- .data_formats = formats_win_full,
- .nformats = ARRAY_SIZE(formats_win_full),
+ .data_formats = formats_win_full_10,
+ .nformats = ARRA
[PATCH 1/2] drm: drm_fourcc: add NV20 YUV format
DRM_FORMAT_NV20 is a 2 plane format suitable for linear memory layout.
The format is similar to P210 with 4:2:2 sub-sampling but has no padding
between components. Instead, luminance and chrominance samples are grouped
into 4s so that each group is packed into an integer number of bytes:
= UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '20' suffix refers to the optimum effective bits per pixel which is
achieved when the total number of luminance samples is a multiple of 4.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/drm_fourcc.c | 4
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 722c7ebe4e88..2a9c8ae719ed 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -278,6 +278,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
.num_planes = 2, .char_per_block = { 5, 5, 0 },
.block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
.vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_NV20,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
+ .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Q410,.depth = 0,
.num_planes = 3, .char_per_block = { 2, 2, 2 },
.block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index b5bf1c0e630e..244d32433a67 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -242,6 +242,7 @@ extern "C" {
* index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
*/
#define DRM_FORMAT_NV15fourcc_code('N', 'V', '1', '5') /* 2x2
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV20fourcc_code('N', 'V', '2', '0') /* 2x1
subsampled Cr:Cb plane */
/*
* 2 plane YCbCr MSB aligned
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Dynamically change enumeration list of DRM enumeration property
Hi, On 2020-06-03 11:12, Pekka Paalanen wrote: > On Wed, 3 Jun 2020 10:50:28 +0530 > Yogish Kulkarni wrote: > >> Inline.. >> >> On Mon, Jun 1, 2020 at 2:19 PM Pekka Paalanen wrote: >> >>> On Mon, 1 Jun 2020 09:22:27 +0530 >>> Yogish Kulkarni wrote: >>> Hi, For letting DRM clients to select output encoding: Sink can support certain display timings with high output bit-depths >>> using multiple output encodings, e.g. sink can support a particular timing with RGB 10-bit, YCbCr422 10-bit and YCbCr420 10-bit. So DRM client may want >>> to select YCbCr422 10-bit over RBG 10-bit output to reduce the link >>> bandwidth (and in turn reduce power/voltage). If DRM driver automatically selects output encoding then we are restricting DRM clients from making >>> appropriate choice. >>> >>> Hi, >>> >>> right, that seems to be another reason. >>> For selectable output color range: Certain applications (typically graphics) usually rendered in full range while some applications (typically video) have limited range content. >>> Since content can change dynamically, DRM driver does not have enough >>> information to choose correct quantization. Only DRM client can correctly select >>> which quantization to set (to preserve artist's intent). >>> >>> Now this is an interesting topic for me. As far as I know, there is no >>> window system protocol to tell the display server whether the >>> application provided content is using full or limited range. This means >>> that the display server cannot tell DRM about full vs. limited range >>> either. It also means that when not fullscreen, the display server >>> cannot show the limited range video content correctly, because it would >>> have to be converted to full-range (or vice versa). >>> >> Right, but there could be DRM client which doesn't use window system (e.g. >> Gstreamer video sink) and wants to select between full/limited color range. >> I agree that there is no window system protocol yet but maybe Wayland >> protocol could be added/extended for this purpose once we finalize things >> that needs to be done in DRM. > > Hi, > > right. If you have that use case and a userspace project welcomes such > feature, you're good. Kodi is a userspace application that is very interested in being able to control or set preferred HDMI output format (rgb444/yuv444/422/420) and quantization range (full/limited). Main reason is to allow end-users to make overrides when sink EDID don't fully match the TV/AVR features or when drm driver makes a bad automatic choice. Hans Verkuil's conclusion in HDMI RGB Quantization Range Lessons at [1] hold ture, it is total chaos. Right now, Kodi set the COLOR_ENCODING and COLOR_RANGE plane properties to let kernel know color encoding and color range of a YUV framebuffer. A single active plane showing a YUV framebuffer with limited range could hint a drm driver that end-user might want to use YUV and limited range output to prevent any banding effect when watching a movie. But in the case of when there is a second overlay plane for OSD or subtitles it may become very hard to guess what configuration works best for end-user. I have piggybacked on the "content type" connector property in [2] for my personal use to signal my drm driver if YUV (Movie) or RGB (Graphics) output is preferred this far but proper drm properties would really help :-) [1] https://elinux.org/images/5/53/Elce2017_0-hdmi.pdf [2] https://github.com/xbmc/xbmc/pull/14358 > > If you propose a KMS property for this, I would hope the patches > document or have links pointing to answers to all my questions here. > That would help both driver and userspace implementations to get into > the same mindset. > >>> But why would an application produce limited range pixels anyway? Is it >>> common that hardware video decoders are unable to produce full-range >>> pixels? >>> >> >> The primary reason for why content producer masters video/gfx content as >> limited range is for compatibility with sinks which only support limited >> range, and not because video decoders are not capable of decoding >> full-range content. > > What I was asking is, even if the video content is limited range, why > would one not decode it into full-range pixels always and if the sink > need limited range, then convert again in hardware? When done right, it > makes no difference in output compared to using limited range > through-out if both content and sink use limited range. For the Allwinner/Amlogic/Rockchip arm devices I mainly play with the video decoder does not support range conversion (to my knowledge) and will produce NV12/YU12 framebuffers in the range the video was encoded in. These devices typically lack a high-performance GPU/3D-accelerator and may have limited CSC capabilities in the display controller. The HDMI block can usually do simple RGB/YUV and full/limited conversions,
Re: [PATCH] drm: drm_fourcc: add NV15, Q410, Q401 YUV formats
Hi Brian,
On 2020-05-26 15:52, Brian Starkey wrote:
> Hi Jonas,
>
> On Mon, May 25, 2020 at 11:08:11AM +0000, Jonas Karlman wrote:
>> Hi,
>>
>> On 2020-05-15 15:37, Brian Starkey wrote:
>>> Hi Ben,
>>>
>>> On Wed, May 06, 2020 at 03:41:26PM +0100, Ben Davis wrote:
>>>> Hi all, any feedback on this patch?
>>>> Thanks, Ben
>>>> On Wed, Apr 22, 2020 at 12:13:49PM +0100, Ben Davis wrote:
>>>>> DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
>>>>> block-linear memory layouts. The format is similar to P010 with 4:2:0
>>>>> sub-sampling but has no padding between components. Instead, luminance
>>>>> and chrominance samples are grouped into 4s so that each group is packed
>>>>> into an integer number of bytes:
>>>>>
>>>>> = UVUV = 4 * 10 bits = 40 bits = 5 bytes
>>>>>
>>>>> The '15' suffix refers to the optimum effective bits per pixel which is
>>>>> achieved when the total number of luminance samples is a multiple of 8.
>>>>>
>>>>> Q410 and Q401 are both 3 plane non-subsampled formats with 16 bits per
>>>>> component, but only 10 bits are used and 6 are padded. 'Q' is chosen
>>>>> as the first letter to denote 3 plane YUV444, (and is the next letter
>>>>> along from P which is usually 2 plane).
>>>>>
>>>>> Signed-off-by: Ben Davis
>>>
>>> The descriptions match my understanding of the formats and the
>>> format_info struct, so feel free to add my r-b:
>>>
>>> Reviewed-by: Brian Starkey
>>>
>>> Can anyone else pass comment on the approach and/or naming? I feel
>>> like we should have some non-Arm eyes on this before we merge it.
>>
>> This pixel format seem to match the memory layout used for 10-bit 4:2:0 by
>> the
>> Rockchip Video Decoder, for the rkvdec a 4:2:2 format is also needed (maybe
>> NV20?).
>>
>> From what I can tell the rockchip specific pixel format has previously been
>> submitted in [1]
>> and GStreamer use NV12_10LE40 (fourcc RK20) for this pixel format.
>>
>> [1] https://patchwork.freedesktop.org/patch/276029/
>>
>
> Yeah you're right, this is the same as the Rockchip version. I see
> Randy's submission has `block_w = { 4, 2, 0 }`... more on that below.
>
> The comment on block_w says "in pixels" - but what's a pixel in a
> subsampled chroma plane? For a 2-plane 4:2:0 format, is one pair of
> chroma samples a single pixel, or one pair of chroma samples is two
> pixels?
>
> Looks like Randy assumed the former and us the latter.
>
>>>
>>> Thanks,
>>> -Brian
>>>
>>>>> ---
>>>>> drivers/gpu/drm/drm_fourcc.c | 12
>>>>> include/uapi/drm/drm_fourcc.h | 24
>>>>> 2 files changed, 36 insertions(+)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>>>>> index b234bfaeda06..0c0a65481afd 100644
>>>>> --- a/drivers/gpu/drm/drm_fourcc.c
>>>>> +++ b/drivers/gpu/drm/drm_fourcc.c
>>>>> @@ -274,6 +274,18 @@ const struct drm_format_info *__drm_format_info(u32
>>>>> format)
>>>>> { .format = DRM_FORMAT_YUV420_10BIT,.depth = 0,
>>>>> .num_planes = 1, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 2,
>>>>> .is_yuv = true },
>>>>> + { .format = DRM_FORMAT_NV15,.depth = 0,
>>>>> + .num_planes = 2, .char_per_block = { 5, 5, 0 },
>>>>> + .block_w = { 4, 4, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
>>>>> + .vsub = 2, .is_yuv = true },
>>
>> For a 4:2:0 format I wonder if the char_per_block value is correct for the
>> second plane,
>> using the following formula to calculate the pitch seem to result in only
>> half expected width.
>> Maybe .char_per_block { 5, 10, 0 } could be correct?
>>
>> pitch = (width * char_per_block[1]) / block_w[1] / hsub
>>
>> for 16x16 this would be
>>
>> pitch[1] = (16 * 5) / 4 / 2 = 10 bytes
>> vs
>> pitch[1] = (16 * 10) / 4 / 2 = 20 bytes
>>
>> height[1] = 16 / 2 = 8
>>
>
> I've talked myself round in circles, I don't know what to think any
> more.
>
> drm_format_info_min_pitch() does:
>
> pitch[1] = width * char_per_block[1] / (block_w[1] * block_h[1])
>
Re: [PATCH 23/27] drm: bridge: dw-hdmi: Attach to next bridge if available
On 2020-05-26 14:50, Neil Armstrong wrote:
> On 26/05/2020 03:15, Laurent Pinchart wrote:
>> On all platforms except i.MX and Rockchip, the dw-hdmi DT bindings
>> require a video output port connected to an HDMI sink (most likely an
>> HDMI connector, in rare cases another bridges converting HDMI to another
>> protocol). For those platforms, retrieve the next bridge and attach it
>> from the dw-hdmi bridge attach handler.
>>
>> Signed-off-by: Laurent Pinchart
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 52 ++-
>> include/drm/bridge/dw_hdmi.h | 2 +
>> 2 files changed, 53 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 6148a022569a..512e67bb1c32 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -143,6 +143,7 @@ struct dw_hdmi_phy_data {
>> struct dw_hdmi {
>> struct drm_connector connector;
>> struct drm_bridge bridge;
>> +struct drm_bridge *next_bridge;
>>
>> unsigned int version;
>>
>> @@ -2797,7 +2798,8 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
>> *bridge,
>> struct dw_hdmi *hdmi = bridge->driver_private;
>>
>> if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
>> -return 0;
>> +return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
>> + bridge, flags);
>>
>> return dw_hdmi_connector_create(hdmi);
>> }
>> @@ -3179,6 +3181,50 @@ static void dw_hdmi_init_hw(struct dw_hdmi *hdmi)
>> hdmi->phy.ops->setup_hpd(hdmi, hdmi->phy.data);
>> }
>>
>> +static int dw_hdmi_parse_dt(struct dw_hdmi *hdmi)
>> +{
>> +struct device_node *endpoint;
>> +struct device_node *remote;
>> +
>> +if (!hdmi->plat_data->output_port)
>> +return 0;
>> +
>> +endpoint = of_graph_get_endpoint_by_regs(hdmi->dev->of_node,
>> + hdmi->plat_data->output_port,
>> + -1);
>> +if (!endpoint) {
>> +/*
>> + * Don't treat this as a fatal error as the Rockchip DW-HDMI
>> + * binding doesn't make the output port mandatory.
>> + */
>> +dev_dbg(hdmi->dev, "Missing endpoint in port@%u\n",
>> +hdmi->plat_data->output_port);
>> +return 0;
After this series only rcar-du set output_port so this block should only
run for rcar-du, for platforms without output_port the if-statement
for !hdmi->plat_data->output_port already return success so you can
probably return fatal error here.
The comment is a little bit misleading because of the if-statement above
or am I missing something?
Regards,
Jonas
>> +}
>> +
>> +remote = of_graph_get_remote_port_parent(endpoint);
>> +of_node_put(endpoint);
>> +if (!remote) {
>> +dev_err(hdmi->dev, "Endpoint in port@%u unconnected\n",
>> +hdmi->plat_data->output_port);
>> +return -ENODEV;
>> +}
>> +
>> +if (!of_device_is_available(remote)) {
>> +dev_err(hdmi->dev, "port@%u remote device is disabled\n",
>> +hdmi->plat_data->output_port);
>> +of_node_put(remote);
>> +return -ENODEV;
>> +}
>> +
>> +hdmi->next_bridge = of_drm_find_bridge(remote);
>> +of_node_put(remote);
>> +if (!hdmi->next_bridge)
>> +return -EPROBE_DEFER;
>
> I'll be safer to print a warn for now until all platforms has been tested.
>
>> +
>> +return 0;
>> +}
>> +
>> static struct dw_hdmi *
>> __dw_hdmi_probe(struct platform_device *pdev,
>> const struct dw_hdmi_plat_data *plat_data)
>> @@ -3216,6 +3262,10 @@ __dw_hdmi_probe(struct platform_device *pdev,
>> mutex_init(>cec_notifier_mutex);
>> spin_lock_init(>audio_lock);
>>
>> +ret = dw_hdmi_parse_dt(hdmi);
>> +if (ret < 0)
>> +return ERR_PTR(ret);
>> +
>> ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
>> if (ddc_node) {
>> hdmi->ddc = of_get_i2c_adapter_by_node(ddc_node);
>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
>> index ea34ca146b82..8ebeb65d6371 100644
>> --- a/include/drm/bridge/dw_hdmi.h
>> +++ b/include/drm/bridge/dw_hdmi.h
>> @@ -126,6 +126,8 @@ struct dw_hdmi_phy_ops {
>> struct dw_hdmi_plat_data {
>> struct regmap *regm;
>>
>> +unsigned int output_port;
>> +
>> unsigned long input_bus_encoding;
>> bool use_drm_infoframe;
>> bool ycbcr_420_allowed;
>>
>
> I must check on meson, since I'm not sure for now if the connector probes.
>
> Anyway, this looks fine.
>
> Reviewed-by: Neil Armstrong
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: drm_fourcc: add NV15, Q410, Q401 YUV formats
Hi,
On 2020-05-15 15:37, Brian Starkey wrote:
> Hi Ben,
>
> On Wed, May 06, 2020 at 03:41:26PM +0100, Ben Davis wrote:
>> Hi all, any feedback on this patch?
>> Thanks, Ben
>> On Wed, Apr 22, 2020 at 12:13:49PM +0100, Ben Davis wrote:
>>> DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
>>> block-linear memory layouts. The format is similar to P010 with 4:2:0
>>> sub-sampling but has no padding between components. Instead, luminance
>>> and chrominance samples are grouped into 4s so that each group is packed
>>> into an integer number of bytes:
>>>
>>> = UVUV = 4 * 10 bits = 40 bits = 5 bytes
>>>
>>> The '15' suffix refers to the optimum effective bits per pixel which is
>>> achieved when the total number of luminance samples is a multiple of 8.
>>>
>>> Q410 and Q401 are both 3 plane non-subsampled formats with 16 bits per
>>> component, but only 10 bits are used and 6 are padded. 'Q' is chosen
>>> as the first letter to denote 3 plane YUV444, (and is the next letter
>>> along from P which is usually 2 plane).
>>>
>>> Signed-off-by: Ben Davis
>
> The descriptions match my understanding of the formats and the
> format_info struct, so feel free to add my r-b:
>
> Reviewed-by: Brian Starkey
>
> Can anyone else pass comment on the approach and/or naming? I feel
> like we should have some non-Arm eyes on this before we merge it.
This pixel format seem to match the memory layout used for 10-bit 4:2:0 by the
Rockchip Video Decoder, for the rkvdec a 4:2:2 format is also needed (maybe
NV20?).
>From what I can tell the rockchip specific pixel format has previously been
>submitted in [1]
and GStreamer use NV12_10LE40 (fourcc RK20) for this pixel format.
[1] https://patchwork.freedesktop.org/patch/276029/
>
> Thanks,
> -Brian
>
>>> ---
>>> drivers/gpu/drm/drm_fourcc.c | 12
>>> include/uapi/drm/drm_fourcc.h | 24
>>> 2 files changed, 36 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>>> index b234bfaeda06..0c0a65481afd 100644
>>> --- a/drivers/gpu/drm/drm_fourcc.c
>>> +++ b/drivers/gpu/drm/drm_fourcc.c
>>> @@ -274,6 +274,18 @@ const struct drm_format_info *__drm_format_info(u32
>>> format)
>>> { .format = DRM_FORMAT_YUV420_10BIT,.depth = 0,
>>> .num_planes = 1, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 2,
>>> .is_yuv = true },
>>> + { .format = DRM_FORMAT_NV15,.depth = 0,
>>> + .num_planes = 2, .char_per_block = { 5, 5, 0 },
>>> + .block_w = { 4, 4, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
>>> + .vsub = 2, .is_yuv = true },
For a 4:2:0 format I wonder if the char_per_block value is correct for the
second plane,
using the following formula to calculate the pitch seem to result in only half
expected width.
Maybe .char_per_block { 5, 10, 0 } could be correct?
pitch = (width * char_per_block[1]) / block_w[1] / hsub
for 16x16 this would be
pitch[1] = (16 * 5) / 4 / 2 = 10 bytes
vs
pitch[1] = (16 * 10) / 4 / 2 = 20 bytes
height[1] = 16 / 2 = 8
Regards,
Jonas
>>> + { .format = DRM_FORMAT_Q410,.depth = 0,
>>> + .num_planes = 3, .char_per_block = { 2, 2, 2 },
>>> + .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
>>> + .vsub = 0, .is_yuv = true },
>>> + { .format = DRM_FORMAT_Q401,.depth = 0,
>>> + .num_planes = 3, .char_per_block = { 2, 2, 2 },
>>> + .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
>>> + .vsub = 0, .is_yuv = true },
>>> };
>>>
>>> unsigned int i;
>>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>>> index 8bc0b31597d8..232b9ad3534d 100644
>>> --- a/include/uapi/drm/drm_fourcc.h
>>> +++ b/include/uapi/drm/drm_fourcc.h
>>> @@ -236,6 +236,12 @@ extern "C" {
>>> #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
>>> subsampled Cb:Cr plane */
>>> #define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
>>> non-subsampled Cr:Cb plane */
>>> #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
>>> non-subsampled Cb:Cr plane */
>>> +/*
>>> + * 2 plane YCbCr
>>> + * index 0 = Y plane, [39:0] Y3:Y2:Y1:Y0 little endian
>>> + * index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
>>> + */
>>> +#define DRM_FORMAT_NV15fourcc_code('N', 'V', '1', '5') /* 2x2
>>> subsampled Cr:Cb plane */
>>>
>>> /*
>>> * 2 plane YCbCr MSB aligned
>>> @@ -265,6 +271,24 @@ extern "C" {
>>> */
>>> #define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
>>> subsampled Cr:Cb plane 16 bits per channel */
>>>
>>> +
>>> +/* 3 plane non-subsampled (444) YCbCr
>>> + * 16 bits per component, but only 10 bits are used and 6 bits are padded
>>> + * index 0: Y plane, [15:0] Y:x [10:6] little endian
>>> + * index 1: Cb plane, [15:0] Cb:x [10:6]
Re: [PATCH v4 04/11] drm/bridge: synopsys: dw-hdmi: add bus format negociation
On 2020-02-29 12:07, Jernej Škrabec wrote: > Dne sobota, 29. februar 2020 ob 11:09:14 CET je Jonas Karlman napisal(a): >> Hi Jernej, >> >> On 2020-02-29 08:42, Jernej Škrabec wrote: >>> Hi Neil! >>> >>> Dne četrtek, 06. februar 2020 ob 20:18:27 CET je Neil Armstrong > napisal(a): >>>> Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to >>>> negociate >>>> the possible output and input formats for the current mode and monitor, >>>> and use the negotiated formats in a basic atomic_check callback. >>>> >>>> Signed-off-by: Neil Armstrong >>>> --- >>>> >>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 272 +- >>>> 1 file changed, 268 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index >>>> fec4a4bcd1fe..15048ad694bc 100644 >>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>>> @@ -2095,11 +2095,10 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, >>>> struct drm_display_mode *mode) >>>> hdmi->hdmi_data.video_mode.mpixelrepetitionoutput = 0; >>>> >>>>hdmi->hdmi_data.video_mode.mpixelrepetitioninput = 0; >>>> >>>> - /* TOFIX: Get input format from plat data or fallback to RGB888 */ >>>> >>>>if (hdmi->plat_data->input_bus_format) >>>> >>>>hdmi->hdmi_data.enc_in_bus_format = >>>> >>>>hdmi->plat_data->input_bus_format; >>>> >>>> - else >>>> + else if (hdmi->hdmi_data.enc_in_bus_format == MEDIA_BUS_FMT_FIXED) >>>> >>>>hdmi->hdmi_data.enc_in_bus_format = >>> >>> MEDIA_BUS_FMT_RGB888_1X24; >>> >>>>/* TOFIX: Get input encoding from plat data or fallback to none */ >>>> >>>> @@ -2109,8 +2108,8 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, >>>> struct >>>> drm_display_mode *mode) else >>>> >>>>hdmi->hdmi_data.enc_in_encoding = >>> >>> V4L2_YCBCR_ENC_DEFAULT; >>> >>>> - /* TOFIX: Default to RGB888 output format */ >>>> - hdmi->hdmi_data.enc_out_bus_format = MEDIA_BUS_FMT_RGB888_1X24; >>>> + if (hdmi->hdmi_data.enc_out_bus_format == MEDIA_BUS_FMT_FIXED) >>>> + hdmi->hdmi_data.enc_out_bus_format = >>> >>> MEDIA_BUS_FMT_RGB888_1X24; >>> >>>>hdmi->hdmi_data.pix_repet_factor = 0; >>>>hdmi->hdmi_data.hdcp_enable = 0; >>>> >>>> @@ -2388,6 +2387,267 @@ static const struct drm_connector_helper_funcs >>>> dw_hdmi_connector_helper_funcs = .atomic_check = >>>> dw_hdmi_connector_atomic_check, >>>> >>>> }; >>>> >>>> +/* >>>> + * Possible output formats : >>>> + * - MEDIA_BUS_FMT_UYYVYY16_0_5X48, >>>> + * - MEDIA_BUS_FMT_UYYVYY12_0_5X36, >>>> + * - MEDIA_BUS_FMT_UYYVYY10_0_5X30, >>>> + * - MEDIA_BUS_FMT_UYYVYY8_0_5X24, >>>> + * - MEDIA_BUS_FMT_YUV16_1X48, >>>> + * - MEDIA_BUS_FMT_RGB161616_1X48, >>>> + * - MEDIA_BUS_FMT_UYVY12_1X24, >>>> + * - MEDIA_BUS_FMT_YUV12_1X36, >>>> + * - MEDIA_BUS_FMT_RGB121212_1X36, >>>> + * - MEDIA_BUS_FMT_UYVY10_1X20, >>>> + * - MEDIA_BUS_FMT_YUV10_1X30, >>>> + * - MEDIA_BUS_FMT_RGB101010_1X30, >>>> + * - MEDIA_BUS_FMT_UYVY8_1X16, >>>> + * - MEDIA_BUS_FMT_YUV8_1X24, >>>> + * - MEDIA_BUS_FMT_RGB888_1X24, >>>> + */ >>>> + >>>> +/* Can return a maximum of 12 possible output formats for a >>>> mode/connector >>>> */ +#define MAX_OUTPUT_SEL_FORMATS 12 >>>> + >>>> +static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge >>>> *bridge, + struct >>> >>> drm_bridge_state *bridge_state, >>> >>>> + struct drm_crtc_state >>> >>> *crtc_state, >>> >>>> + struct >>> >>> drm_connector_state *conn_state, >>> >>>> + unsigned int >>&
Re: [PATCH v4 04/11] drm/bridge: synopsys: dw-hdmi: add bus format negociation
Hi Jernej,
On 2020-02-29 08:42, Jernej Škrabec wrote:
> Hi Neil!
>
> Dne četrtek, 06. februar 2020 ob 20:18:27 CET je Neil Armstrong napisal(a):
>> Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negociate
>> the possible output and input formats for the current mode and monitor,
>> and use the negotiated formats in a basic atomic_check callback.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 272 +-
>> 1 file changed, 268 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
>> fec4a4bcd1fe..15048ad694bc 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -2095,11 +2095,10 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi,
>> struct drm_display_mode *mode)
>> hdmi->hdmi_data.video_mode.mpixelrepetitionoutput = 0;
>> hdmi->hdmi_data.video_mode.mpixelrepetitioninput = 0;
>>
>> -/* TOFIX: Get input format from plat data or fallback to RGB888 */
>> if (hdmi->plat_data->input_bus_format)
>> hdmi->hdmi_data.enc_in_bus_format =
>> hdmi->plat_data->input_bus_format;
>> -else
>> +else if (hdmi->hdmi_data.enc_in_bus_format == MEDIA_BUS_FMT_FIXED)
>> hdmi->hdmi_data.enc_in_bus_format =
> MEDIA_BUS_FMT_RGB888_1X24;
>>
>> /* TOFIX: Get input encoding from plat data or fallback to none */
>> @@ -2109,8 +2108,8 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct
>> drm_display_mode *mode) else
>> hdmi->hdmi_data.enc_in_encoding =
> V4L2_YCBCR_ENC_DEFAULT;
>>
>> -/* TOFIX: Default to RGB888 output format */
>> -hdmi->hdmi_data.enc_out_bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>> +if (hdmi->hdmi_data.enc_out_bus_format == MEDIA_BUS_FMT_FIXED)
>> +hdmi->hdmi_data.enc_out_bus_format =
> MEDIA_BUS_FMT_RGB888_1X24;
>>
>> hdmi->hdmi_data.pix_repet_factor = 0;
>> hdmi->hdmi_data.hdcp_enable = 0;
>> @@ -2388,6 +2387,267 @@ static const struct drm_connector_helper_funcs
>> dw_hdmi_connector_helper_funcs = .atomic_check =
>> dw_hdmi_connector_atomic_check,
>> };
>>
>> +/*
>> + * Possible output formats :
>> + * - MEDIA_BUS_FMT_UYYVYY16_0_5X48,
>> + * - MEDIA_BUS_FMT_UYYVYY12_0_5X36,
>> + * - MEDIA_BUS_FMT_UYYVYY10_0_5X30,
>> + * - MEDIA_BUS_FMT_UYYVYY8_0_5X24,
>> + * - MEDIA_BUS_FMT_YUV16_1X48,
>> + * - MEDIA_BUS_FMT_RGB161616_1X48,
>> + * - MEDIA_BUS_FMT_UYVY12_1X24,
>> + * - MEDIA_BUS_FMT_YUV12_1X36,
>> + * - MEDIA_BUS_FMT_RGB121212_1X36,
>> + * - MEDIA_BUS_FMT_UYVY10_1X20,
>> + * - MEDIA_BUS_FMT_YUV10_1X30,
>> + * - MEDIA_BUS_FMT_RGB101010_1X30,
>> + * - MEDIA_BUS_FMT_UYVY8_1X16,
>> + * - MEDIA_BUS_FMT_YUV8_1X24,
>> + * - MEDIA_BUS_FMT_RGB888_1X24,
>> + */
>> +
>> +/* Can return a maximum of 12 possible output formats for a mode/connector
>> */ +#define MAX_OUTPUT_SEL_FORMATS 12
>> +
>> +static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge
>> *bridge, + struct
> drm_bridge_state *bridge_state,
>> +struct drm_crtc_state
> *crtc_state,
>> +struct
> drm_connector_state *conn_state,
>> +unsigned int
> *num_output_fmts)
>> +{
>> +struct drm_connector *conn = conn_state->connector;
>> +struct drm_display_info *info = >display_info;
>> +struct drm_display_mode *mode = _state->mode;
>> +u8 max_bpc = conn_state->max_requested_bpc;
>> +bool is_hdmi2_sink = info->hdmi.scdc.supported ||
>> + (info->color_formats &
> DRM_COLOR_FORMAT_YCRCB420);
>> +u32 *output_fmts;
>> +int i = 0;
>> +
>> +*num_output_fmts = 0;
>> +
>> +output_fmts = kcalloc(MAX_OUTPUT_SEL_FORMATS, sizeof(*output_fmts),
>> + GFP_KERNEL);
>> +if (!output_fmts)
>> +return NULL;
>> +
>> +/*
>> + * If the current mode enforces 4:2:0, force the output but format
>> + * to 4:2:0 and do not add the YUV422/444/RGB formats
>> + */
>> +if (conn->ycbcr_420_allowed &&
>> +(drm_mode_is_420_only(info, mode) ||
>> + ())) {
>> +
>> +/* Order bus formats from 16bit to 8bit if supported */
>> +if (max_bpc >= 16 && info->bpc == 16 &&
>> +(info->hdmi.y420_dc_modes &
> DRM_EDID_YCBCR420_DC_48))
>> +output_fmts[i++] =
> MEDIA_BUS_FMT_UYYVYY16_0_5X48;
>> +
>> +if (max_bpc >= 12 && info->bpc >= 12 &&
>> +(info->hdmi.y420_dc_modes &
> DRM_EDID_YCBCR420_DC_36))
>> +output_fmts[i++] =
> MEDIA_BUS_FMT_UYYVYY12_0_5X36;
>> +
>> +if (max_bpc >= 10 && info->bpc >= 10 &&
>> +(info->hdmi.y420_dc_modes &
> DRM_EDID_YCBCR420_DC_30))
>> +output_fmts[i++] =
> MEDIA_BUS_FMT_UYYVYY10_0_5X30;
>> +
Re: [PATCH v7 06/12] drm/bridge: Add the necessary bits to support bus format negotiation
On 2020-01-23 08:39, Boris Brezillon wrote:
> On Wed, 22 Jan 2020 23:44:28 + (UTC)
> Jonas Karlman wrote:
>
>>> +static int
>>> +drm_atomic_bridge_chain_select_bus_fmts(struct drm_bridge *bridge,
>>> + struct drm_crtc_state *crtc_state,
>>> + struct drm_connector_state *conn_state)
>>> +{
>>> + struct drm_connector *conn = conn_state->connector;
>>> + struct drm_encoder *encoder = bridge->encoder;
>>> + struct drm_bridge_state *last_bridge_state;
>>> + unsigned int i, num_out_bus_fmts;
>>> + struct drm_bridge *last_bridge;
>>> + u32 *out_bus_fmts;
>>> + int ret = 0;
>>> +
>>> + last_bridge = list_last_entry(>bridge_chain,
>>> + struct drm_bridge, chain_node);
>>> + last_bridge_state = drm_atomic_get_new_bridge_state(crtc_state->state,
>>> + last_bridge);
>>> +
>>> + if (last_bridge->funcs->atomic_get_output_bus_fmts) {
>>> + const struct drm_bridge_funcs *funcs = last_bridge->funcs;
>>> +
>>> + /*
>>> +* If the driver implements ->atomic_get_output_bus_fmts() it
>>> +* should also implement the atomic state hooks.
>>> +*/
>>> + if (WARN_ON(last_bridge_state))
>>
>> This looks wrong, with this changed to WARN_ON(!last_bridge_state)
>> my RK3328 HDMI2.0/YUV444/YUV420/10-bit branch at [1] starts working.
>>
>> With WARN_ON(last_bridge_state) I get:
>>
>> [6.606658] WARNING: CPU: 0 PID: 167 at drivers/gpu/drm/drm_bridge.c:746
>> drm_atomic_bridge_chain_check+0x2b8/0x308
>> [6.606673] Hardware name: Pine64 Rock64 (DT)
>>
>> [6.606754] Call trace:
>> [6.606759] drm_atomic_bridge_chain_check+0x2b8/0x308
>> [6.606764] drm_atomic_helper_check_modeset+0x89c/0xab8
>> [6.606768] drm_atomic_helper_check+0x1c/0xa0
>> [6.606772] drm_atomic_check_only+0x464/0x708
>> [6.606777] drm_atomic_commit+0x18/0x58
>
> Add
>
> const drm_bridge_funcs ... = {
> ...
> .atomic_reset = drm_atomic_helper_bridge_reset,
> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
> ...
> };
>
> and that should work.
That is what I added and what made that this warning is being triggered.
The comment state that atomic state is needed, but the check warns when there
is a state.
I have this:
static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
...
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_get_output_bus_fmts = dw_hdmi_bridge_atomic_get_output_bus_fmts,
.atomic_get_input_bus_fmts = dw_hdmi_bridge_atomic_get_input_bus_fmts,
.atomic_check = dw_hdmi_bridge_atomic_check,
.atomic_reset = drm_atomic_helper_bridge_reset,
...
};
and
static const struct drm_bridge_funcs dw_hdmi_rockchip_bridge_funcs = {
...
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_get_input_bus_fmts = dw_hdmi_rockchip_get_input_bus_fmts,
.atomic_check = dw_hdmi_rockchip_bridge_atomic_check,
.atomic_reset = drm_atomic_helper_bridge_reset,
};
after applying the following I got a hdmi signal again
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 0c28816146ba..7e7b0fac8f4f 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -743,7 +743,7 @@ drm_atomic_bridge_chain_select_bus_fmts(struct drm_bridge
*bridge,
* If the driver implements ->atomic_get_output_bus_fmts() it
* should also implement the atomic state hooks.
*/
- if (WARN_ON(last_bridge_state))
+ if (WARN_ON(!last_bridge_state))
return -EINVAL;
out_bus_fmts = funcs->atomic_get_output_bus_fmts(last_bridge,
Regards,
Jonas
>
>>
>> [1] https://github.com/Kwiboo/linux-rockchip/commits/next-20200122-bus-format
>>
>> Regards,
>> Jonas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 06/12] drm/bridge: Add the necessary bits to support bus format negotiation
On 2020-01-22 12:16, Boris Brezillon wrote:
> drm_bridge_state is extended to describe the input and output bus
> configurations. These bus configurations are exposed through the
> drm_bus_cfg struct which encodes the configuration of a physical
> bus between two components in an output pipeline, usually between
> two bridges, an encoder and a bridge, or a bridge and a connector.
>
> The bus configuration is stored in drm_bridge_state separately for
> the input and output buses, as seen from the point of view of each
> bridge. The bus configuration of a bridge output is usually identical
> to the configuration of the next bridge's input, but may differ if
> the signals are modified between the two bridges, for instance by an
> inverter on the board. The input and output configurations of a
> bridge may differ if the bridge modifies the signals internally,
> for instance by performing format conversion, or*modifying signals
> polarities.
>
> Bus format negotiation is automated by the core, drivers just have
> to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
> want to take part to this negotiation. Negotiation happens in reverse
> order, starting from the last element of the chain (the one directly
> connected to the display) up to the first element of the chain (the one
> connected to the encoder).
> During this negotiation all supported formats are tested until we find
> one that works, meaning that the formats array should be in decreasing
> preference order (assuming the driver has a preference order).
>
> Note that the bus format negotiation works even if some elements in the
> chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
> In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
> the previous bridge element decide what to do (most of the time, bridge
> drivers will pick a default bus format or extract this piece of
> information from somewhere else, like a FW property).
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Neil Armstrong
> [narmstrong: fixed doc in include/drm/drm_bridge.h:69 fmt->format]
> Reviewed by: Jernej Skrabec
> Tested-by: Jonas Karlman
> ---
> Changes in v7:
> * Adapt the code to deal with the fact that not all bridges in the
> chain have a bridge state
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 41 +
> drivers/gpu/drm/drm_bridge.c| 253 +++-
> include/drm/drm_atomic.h| 42 +
> include/drm/drm_atomic_helper.h | 8 +
> include/drm/drm_bridge.h| 82 +
> 5 files changed, 425 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index afe14f72a824..ea1926b5bb80 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3528,3 +3528,44 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc
> *crtc,
> return ret;
> }
> EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
> +
> +/**
> + * drm_atomic_helper_bridge_propagate_bus_fmt() - Propagate output format to
> + * the input end of a bridge
> + * @bridge: bridge control structure
> + * @bridge_state: new bridge state
> + * @crtc_state: new CRTC state
> + * @conn_state: new connector state
> + * @output_fmt: tested output bus format
> + * @num_input_fmts: will contain the size of the returned array
> + *
> + * This helper is a pluggable implementation of the
> + * _bridge_funcs.atomic_get_input_bus_fmts operation for bridges that
> don't
> + * modify the bus configuration between their input and their output. It
> + * returns an array of input formats with a single element set to
> @output_fmt.
> + *
> + * RETURNS:
> + * a valid format array of size @num_input_fmts, or NULL if the allocation
> + * failed
> + */
> +u32 *
> +drm_atomic_helper_bridge_propagate_bus_fmt(struct drm_bridge *bridge,
> + struct drm_bridge_state *bridge_state,
> + struct drm_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state,
> + u32 output_fmt,
> + unsigned int *num_input_fmts)
> +{
> + u32 *input_fmts;
> +
> + input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
> + if (!input_fmts) {
> + *num_input_fmts = 0;
> + return NULL;
> + }
> +
> + *num_input_fmts = 1;
> + input_fmts[0] = output_fmt;
> + return input_fmts;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_bridge_propagate_bus_fmt);
Re: [PATCH v2 00/14] Support more HDMI modes on RK3228/RK3328
On 2020-01-10 12:01, Kishon Vijay Abraham I wrote: > > > On 09/01/20 2:37 AM, Jonas Karlman wrote: >> This series make it possible to use more HDMI modes on RK3328, >> and presumably also on RK3228. It also prepares for a future YUV420 and >> 10-bit output series. >> >> Part of this has been reworked from vendor BSP 4.4 kernel commits. >> >> Patch 1-5 fixes issues and shortcomings in the inno hdmi phy driver. >> >> Patch 6 prepares for use of high TMDS bit rates used with HDMI 2.0 and >> 10-bit output modes. >> >> Patch 7-13 changes rk3228/rk3328 to use mode_valid functions suited for >> the inno hdmi phy instead of the dw-hdmi phy. These changes allows for >> more CEA modes to be usable, e.g. some 4K and fractal modes. >> >> Patch 14 adds support for more pixel clock rates in order to support >> common DMT modes in addition to CEA modes. > > Is it possible to split the series targeted for different subsystems or > is it required for all the patches to be merged together? I think it should be possible to split the patches without any issue. The phy changes mainly targets HDMI mode rates that is currently not in use, filtered out by current mode_valid or YUV420/Deep Color modes not yet supported. And the drm changes should not have a hard requirement on the phy changes in this series, but I have not tested them separately. I will split this series and re-run some tests before sending independent series. Regards, Jonas > > Thanks > Kishon >> >> Note: I have only been able to build test RK322x related changes >> as I do not have any RK322x device to test on. >> >> All modes, including fractal modes, has been tested with modetest on >> a RK3328 Rock64 device using e.g. >> >> modetest -M rockchip -s 39:3840x2160-29.97 >> >> Changes in v2: >> - collect acked-by tag >> - drop the limit resolution width to 3840 patch >> >> This series is also available at [1] and the early work on YUV420 and >> 10-bit output is available at [2]. >> >> [1] >> https://github.com/Kwiboo/linux-rockchip/commits/next-20200108-inno-hdmi-phy >> [2] https://github.com/Kwiboo/linux-rockchip/commits/next-20200108-bus-format >> >> Regards, >> Jonas >> >> Algea Cao (1): >> phy/rockchip: inno-hdmi: Support more pre-pll configuration >> >> Huicong Xu (1): >> phy/rockchip: inno-hdmi: force set_rate on power_on >> >> Jonas Karlman (11): >> phy/rockchip: inno-hdmi: use correct vco_div_5 macro on rk3328 >> phy/rockchip: inno-hdmi: remove unused no_c from rk3328 recalc_rate >> phy/rockchip: inno-hdmi: do not power on rk3328 post pll on reg write >> drm/rockchip: dw-hdmi: allow high tmds bit rates >> drm/rockchip: dw-hdmi: require valid vpll clock rate on rk3228/rk3328 >> clk: rockchip: set parent rate for DCLK_VOP clock on rk3228 >> arm64: dts: rockchip: increase vop clock rate on rk3328 >> arm64: dts: rockchip: add vpll clock to hdmi node on rk3328 >> ARM: dts: rockchip: add vpll clock to hdmi node on rk3228 >> drm/rockchip: dw-hdmi: limit tmds to 340mhz on rk3228/rk3328 >> drm/rockchip: dw-hdmi: remove unused plat_data on rk3228/rk3328 >> >> Zheng Yang (1): >> phy/rockchip: inno-hdmi: round fractal pixclock in rk3328 recalc_rate >> >> arch/arm/boot/dts/rk322x.dtsi | 4 +- >> arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 +- >> drivers/clk/rockchip/clk-rk3228.c | 2 +- >> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 47 ++-- >> drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 110 -- >> 5 files changed, 120 insertions(+), 49 deletions(-) >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 14/14] phy/rockchip: inno-hdmi: Support more pre-pll configuration
From: Algea Cao
Adding the following freq cfg in 8-bit and 10-bit color depth:
{
4000, 6500, 7100, 8350, 8575,
8875, 10800, 11900, 16200
}
New freq has been validated by quantumdata 980.
For some freq which can't be got by only using integer freq div,
frac freq div is needed, Such as 88.75Mhz 10-bit. But The actual
freq is different from the target freq, We must try to narrow
the gap between them. RK322X only support integer freq div.
The VCO of pre-PLL must be more than 2Ghz, otherwise PLL may be
unlocked.
Signed-off-by: Algea Cao
Signed-off-by: Jonas Karlman
Acked-by: Heiko Stuebner
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 74 ---
1 file changed, 49 insertions(+), 25 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 3719309ad0d0..bb8bdf5e3301 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -291,32 +291,56 @@ struct inno_hdmi_phy_drv_data {
const struct phy_config *phy_cfg_table;
};
+/*
+ * If only using integer freq div can't get frequency we want, frac
+ * freq div is needed. For example, pclk 88.75 Mhz and tmdsclk
+ * 110.9375 Mhz must use frac div 0xF0. The actual frequency is different
+ * from the target frequency. Such as the tmds clock 110.9375 Mhz,
+ * the actual tmds clock we get is 110.93719 Mhz. It is important
+ * to note that RK322X platforms do not support frac div.
+ */
static const struct pre_pll_config pre_pll_cfg_table[] = {
- { 2700, 2700, 1, 90, 3, 2, 2, 10, 3, 3, 4, 0, 0},
- { 2700, 3375, 1, 90, 1, 3, 3, 10, 3, 3, 4, 0, 0},
- { 4000, 4000, 1, 80, 2, 2, 2, 12, 2, 2, 2, 0, 0},
- { 59341000, 59341000, 1, 98, 3, 1, 2, 1, 3, 3, 4, 0, 0xE6AE6B},
- { 5940, 5940, 1, 99, 3, 1, 1, 1, 3, 3, 4, 0, 0},
- { 59341000, 74176250, 1, 98, 0, 3, 3, 1, 3, 3, 4, 0, 0xE6AE6B},
- { 5940, 7425, 1, 99, 1, 2, 2, 1, 3, 3, 4, 0, 0},
- { 74176000, 74176000, 1, 98, 1, 2, 2, 1, 2, 3, 4, 0, 0xE6AE6B},
- { 7425, 7425, 1, 99, 1, 2, 2, 1, 2, 3, 4, 0, 0},
- { 74176000, 9272, 4, 494, 1, 2, 2, 1, 3, 3, 4, 0, 0x816817},
- { 7425, 92812500, 4, 495, 1, 2, 2, 1, 3, 3, 4, 0, 0},
- {148352000, 148352000, 1, 98, 1, 1, 1, 1, 2, 2, 2, 0, 0xE6AE6B},
- {14850, 14850, 1, 99, 1, 1, 1, 1, 2, 2, 2, 0, 0},
- {148352000, 18544, 4, 494, 0, 2, 2, 1, 3, 2, 2, 0, 0x816817},
- {14850, 185625000, 4, 495, 0, 2, 2, 1, 3, 2, 2, 0, 0},
- {296703000, 296703000, 1, 98, 0, 1, 1, 1, 0, 2, 2, 0, 0xE6AE6B},
- {29700, 29700, 1, 99, 0, 1, 1, 1, 0, 2, 2, 0, 0},
- {296703000, 370878750, 4, 494, 1, 2, 0, 1, 3, 1, 1, 0, 0x816817},
- {29700, 37125, 4, 495, 1, 2, 0, 1, 3, 1, 1, 0, 0},
- {593407000, 296703500, 1, 98, 0, 1, 1, 1, 0, 2, 1, 0, 0xE6AE6B},
- {59400, 29700, 1, 99, 0, 1, 1, 1, 0, 2, 1, 0, 0},
- {593407000, 370879375, 4, 494, 1, 2, 0, 1, 3, 1, 1, 1, 0x816817},
- {59400, 37125, 4, 495, 1, 2, 0, 1, 3, 1, 1, 1, 0},
- {593407000, 593407000, 1, 98, 0, 2, 0, 1, 0, 1, 1, 0, 0xE6AE6B},
- {59400, 59400, 1, 99, 0, 2, 0, 1, 0, 1, 1, 0, 0},
+ { 2700, 2700, 1, 90, 3, 2, 2, 10, 3, 3, 4, 0, 0},
+ { 2700, 3375, 1, 90, 1, 3, 3, 10, 3, 3, 4, 0, 0},
+ { 4000, 4000, 1, 80, 2, 2, 2, 12, 2, 2, 2, 0, 0},
+ { 4000, 5000, 1, 100, 2, 2, 2, 1, 0, 0, 15, 0, 0},
+ { 59341000, 59341000, 1, 98, 3, 1, 2, 1, 3, 3, 4, 0, 0xE6AE6B},
+ { 5940, 5940, 1, 99, 3, 1, 1, 1, 3, 3, 4, 0, 0},
+ { 59341000, 74176250, 1, 98, 0, 3, 3, 1, 3, 3, 4, 0, 0xE6AE6B},
+ { 5940, 7425, 1, 99, 1, 2, 2, 1, 3, 3, 4, 0, 0},
+ { 6500, 6500, 1, 130, 2, 2, 2, 1, 0, 0, 12, 0, 0},
+ { 6500, 8125, 3, 325, 0, 3, 3, 1, 0, 0, 10, 0, 0},
+ { 7100, 7100, 3, 284, 0, 3, 3, 1, 0, 0, 8, 0, 0},
+ { 7100, 8875, 3, 355, 0, 3, 3, 1, 0, 0, 10, 0, 0},
+ { 74176000, 74176000, 1, 98, 1, 2, 2, 1, 2, 3, 4, 0, 0xE6AE6B},
+ { 7425, 7425, 1, 99, 1, 2, 2, 1, 2, 3, 4, 0, 0},
+ { 74176000, 9272, 4, 494, 1, 2, 2, 1, 3, 3, 4, 0, 0x816817},
+ { 7425, 92812500, 4, 495, 1, 2, 2, 1, 3, 3, 4, 0, 0},
+ { 8350, 8350, 2, 167, 2, 1, 1, 1, 0, 0, 6, 0, 0},
+ { 8350, 104375000, 1, 104, 2, 1, 1, 1, 1, 0, 5, 0, 0x60},
+ { 8575, 8575, 3, 343, 0, 3, 3, 1, 0, 0, 8, 0, 0},
+ { 8875, 8875, 3, 355, 0, 3, 3, 1, 0, 0, 8, 0, 0},
+ { 8875, 110937500, 1, 110, 2, 1, 1, 1, 1, 0, 5, 0, 0xF0},
+ {10800, 10800, 1, 90, 3, 0, 0, 1, 0, 0, 5, 0, 0},
+ {10800, 13500, 1, 90, 0, 2
[PATCH v2 11/14] ARM: dts: rockchip: add vpll clock to hdmi node on rk3228
Add the hdmiphy clock as the vpll in hdmi node. Signed-off-by: Jonas Karlman --- arch/arm/boot/dts/rk322x.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi index 340ed6ccb08f..16ad240d5f7f 100644 --- a/arch/arm/boot/dts/rk322x.dtsi +++ b/arch/arm/boot/dts/rk322x.dtsi @@ -639,8 +639,8 @@ interrupts = ; assigned-clocks = < SCLK_HDMI_PHY>; assigned-clock-parents = <_phy>; - clocks = < SCLK_HDMI_HDCP>, < PCLK_HDMI_CTRL>, < SCLK_HDMI_CEC>; - clock-names = "isfr", "iahb", "cec"; + clocks = < SCLK_HDMI_HDCP>, < PCLK_HDMI_CTRL>, <_phy>, < SCLK_HDMI_CEC>; + clock-names = "isfr", "iahb", "vpll", "cec"; pinctrl-names = "default"; pinctrl-0 = <_xfer _hpd _cec>; resets = < SRST_HDMI_P>; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/14] arm64: dts: rockchip: add vpll clock to hdmi node on rk3328
Add the hdmiphy clock as the vpll in hdmi node. Signed-off-by: Jonas Karlman --- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi index fee896338cc1..5d8807aca62e 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi @@ -720,9 +720,11 @@ ; clocks = < PCLK_HDMI>, < SCLK_HDMI_SFC>, +<>, < SCLK_RTC32K>; clock-names = "iahb", "isfr", + "vpll", "cec"; phys = <>; phy-names = "hdmi"; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 12/14] drm/rockchip: dw-hdmi: limit tmds to 340mhz on rk3228/rk3328
RK3228/RK3328 does not provide a stable hdmi signal at TMDS rates
above 371.25MHz (340MHz pixel clock).
Limit the pixel clock rate to 340MHz to provide a stable signal.
Also limit the pixel clock to the display reported max tmds clock.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 22 +++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 45fcdce3f27f..66c14df4a680 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -237,6 +237,24 @@ dw_hdmi_rockchip_mode_valid(struct drm_connector
*connector,
return (valid) ? MODE_OK : MODE_BAD;
}
+static enum drm_mode_status
+dw_hdmi_rk3228_mode_valid(struct drm_connector *connector,
+ const struct drm_display_mode *mode)
+{
+ struct drm_display_info *info = >display_info;
+ int max_tmds_clock = max(info->max_tmds_clock, 165000);
+ int clock = mode->clock;
+
+ if (connector->ycbcr_420_allowed && drm_mode_is_420(info, mode) &&
+ (info->color_formats & DRM_COLOR_FORMAT_YCRCB420))
+ clock /= 2;
+
+ if (clock > max_tmds_clock || clock > 34)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
static const struct drm_encoder_funcs dw_hdmi_rockchip_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
@@ -424,7 +442,7 @@ static struct rockchip_hdmi_chip_data rk3228_chip_data = {
};
static const struct dw_hdmi_plat_data rk3228_hdmi_drv_data = {
- .mode_valid = dw_hdmi_rockchip_mode_valid,
+ .mode_valid = dw_hdmi_rk3228_mode_valid,
.mpll_cfg = rockchip_mpll_cfg,
.cur_ctr = rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
@@ -461,7 +479,7 @@ static struct rockchip_hdmi_chip_data rk3328_chip_data = {
};
static const struct dw_hdmi_plat_data rk3328_hdmi_drv_data = {
- .mode_valid = dw_hdmi_rockchip_mode_valid,
+ .mode_valid = dw_hdmi_rk3228_mode_valid,
.mpll_cfg = rockchip_mpll_cfg,
.cur_ctr = rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/14] phy/rockchip: inno-hdmi: remove unused no_c from rk3328 recalc_rate
no_c is not used in any calculation, lets remove it.
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 093d2334e8cd..06db69c8373e 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -714,7 +714,7 @@ unsigned long inno_hdmi_phy_rk3328_clk_recalc_rate(struct
clk_hw *hw,
{
struct inno_hdmi_phy *inno = to_inno_hdmi_phy(hw);
unsigned long frac;
- u8 nd, no_a, no_b, no_c, no_d;
+ u8 nd, no_a, no_b, no_d;
u64 vco;
u16 nf;
@@ -737,9 +737,6 @@ unsigned long inno_hdmi_phy_rk3328_clk_recalc_rate(struct
clk_hw *hw,
no_b = inno_read(inno, 0xa5) & RK3328_PRE_PLL_PCLK_DIV_B_MASK;
no_b >>= RK3328_PRE_PLL_PCLK_DIV_B_SHIFT;
no_b += 2;
- no_c = inno_read(inno, 0xa6) & RK3328_PRE_PLL_PCLK_DIV_C_MASK;
- no_c >>= RK3328_PRE_PLL_PCLK_DIV_C_SHIFT;
- no_c = 1 << no_c;
no_d = inno_read(inno, 0xa6) & RK3328_PRE_PLL_PCLK_DIV_D_MASK;
do_div(vco, (nd * (no_a == 1 ? no_b : no_a) * no_d * 2));
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/14] arm64: dts: rockchip: increase vop clock rate on rk3328
The VOP on RK3328 needs to run at higher rate in order to produce a proper 3840x2160 signal. Signed-off-by: Jonas Karlman --- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi index c9ff1188bd7b..fee896338cc1 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi @@ -803,8 +803,8 @@ <0>, <2400>, <2400>, <2400>, <1500>, <1500>, - <1>, <1>, - <1>, <1>, + <3>, <1>, + <4>, <1>, <5000>, <1>, <1>, <1>, <5000>, <5000>, -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/14] clk: rockchip: set parent rate for DCLK_VOP clock on rk3228
Signed-off-by: Jonas Karlman
---
drivers/clk/rockchip/clk-rk3228.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3228.c
b/drivers/clk/rockchip/clk-rk3228.c
index d17cfb7a3ff4..25f79af22cb8 100644
--- a/drivers/clk/rockchip/clk-rk3228.c
+++ b/drivers/clk/rockchip/clk-rk3228.c
@@ -410,7 +410,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[]
__initdata = {
RK2928_CLKSEL_CON(29), 0, 3, DFLAGS),
DIV(0, "sclk_vop_pre", "sclk_vop_src", 0,
RK2928_CLKSEL_CON(27), 8, 8, DFLAGS),
- MUX(DCLK_VOP, "dclk_vop", mux_dclk_vop_p, 0,
+ MUX(DCLK_VOP, "dclk_vop", mux_dclk_vop_p, CLK_SET_RATE_PARENT |
CLK_SET_RATE_NO_REPARENT,
RK2928_CLKSEL_CON(27), 1, 1, MFLAGS),
FACTOR(0, "xin12m", "xin24m", 0, 1, 2),
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/14] phy/rockchip: inno-hdmi: do not power on rk3328 post pll on reg write
inno_write is used to configure 0xaa reg, that also hold the
POST_PLL_POWER_DOWN bit.
When POST_PLL_REFCLK_SEL_TMDS is configured the power down bit is not
taken into consideration.
Fix this by keeping the power down bit until configuration is complete.
Also reorder the reg write order for consistency.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 06db69c8373e..3a59a6da0440 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -1020,9 +1020,10 @@ inno_hdmi_phy_rk3328_power_on(struct inno_hdmi_phy *inno,
inno_write(inno, 0xac, RK3328_POST_PLL_FB_DIV_7_0(cfg->fbdiv));
if (cfg->postdiv == 1) {
- inno_write(inno, 0xaa, RK3328_POST_PLL_REFCLK_SEL_TMDS);
inno_write(inno, 0xab, RK3328_POST_PLL_FB_DIV_8(cfg->fbdiv) |
RK3328_POST_PLL_PRE_DIV(cfg->prediv));
+ inno_write(inno, 0xaa, RK3328_POST_PLL_REFCLK_SEL_TMDS |
+ RK3328_POST_PLL_POWER_DOWN);
} else {
v = (cfg->postdiv / 2) - 1;
v &= RK3328_POST_PLL_POST_DIV_MASK;
@@ -1030,7 +1031,8 @@ inno_hdmi_phy_rk3328_power_on(struct inno_hdmi_phy *inno,
inno_write(inno, 0xab, RK3328_POST_PLL_FB_DIV_8(cfg->fbdiv) |
RK3328_POST_PLL_PRE_DIV(cfg->prediv));
inno_write(inno, 0xaa, RK3328_POST_PLL_POST_DIV_ENABLE |
- RK3328_POST_PLL_REFCLK_SEL_TMDS);
+ RK3328_POST_PLL_REFCLK_SEL_TMDS |
+ RK3328_POST_PLL_POWER_DOWN);
}
for (v = 0; v < 14; v++)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 13/14] drm/rockchip: dw-hdmi: remove unused plat_data on rk3228/rk3328
mpll_cfg/cur_ctr/phy_config is not used when phy_force_vendor is true,
lets remove them.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 66c14df4a680..a813299e97a2 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -443,9 +443,6 @@ static struct rockchip_hdmi_chip_data rk3228_chip_data = {
static const struct dw_hdmi_plat_data rk3228_hdmi_drv_data = {
.mode_valid = dw_hdmi_rk3228_mode_valid,
- .mpll_cfg = rockchip_mpll_cfg,
- .cur_ctr = rockchip_cur_ctr,
- .phy_config = rockchip_phy_config,
.phy_data = _chip_data,
.phy_ops = _hdmi_phy_ops,
.phy_name = "inno_dw_hdmi_phy2",
@@ -480,9 +477,6 @@ static struct rockchip_hdmi_chip_data rk3328_chip_data = {
static const struct dw_hdmi_plat_data rk3328_hdmi_drv_data = {
.mode_valid = dw_hdmi_rk3228_mode_valid,
- .mpll_cfg = rockchip_mpll_cfg,
- .cur_ctr = rockchip_cur_ctr,
- .phy_config = rockchip_phy_config,
.phy_data = _chip_data,
.phy_ops = _hdmi_phy_ops,
.phy_name = "inno_dw_hdmi_phy2",
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/14] drm/rockchip: dw-hdmi: require valid vpll clock rate on rk3228/rk3328
RK3228/RK3328 can only support clock rates defined in the pre pll table.
Lets validate the mode clock rate against the pre pll config and filter
out any mode with a clock rate returning error from clk_round_rate().
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index fae38b323a0c..45fcdce3f27f 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -245,6 +245,22 @@ static void dw_hdmi_rockchip_encoder_disable(struct
drm_encoder *encoder)
{
}
+static enum drm_mode_status
+dw_hdmi_rockchip_encoder_mode_valid(struct drm_encoder *encoder,
+ const struct drm_display_mode *mode)
+{
+ struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
+ long rate;
+
+ if (hdmi->vpll_clk) {
+ rate = clk_round_rate(hdmi->vpll_clk, mode->clock * 1000);
+ if (rate < 0)
+ return MODE_CLOCK_RANGE;
+ }
+
+ return MODE_OK;
+}
+
static bool
dw_hdmi_rockchip_encoder_mode_fixup(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
@@ -306,6 +322,7 @@ dw_hdmi_rockchip_encoder_atomic_check(struct drm_encoder
*encoder,
}
static const struct drm_encoder_helper_funcs
dw_hdmi_rockchip_encoder_helper_funcs = {
+ .mode_valid = dw_hdmi_rockchip_encoder_mode_valid,
.mode_fixup = dw_hdmi_rockchip_encoder_mode_fixup,
.mode_set = dw_hdmi_rockchip_encoder_mode_set,
.enable = dw_hdmi_rockchip_encoder_enable,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/14] drm/rockchip: dw-hdmi: allow high tmds bit rates
Prepare support for High TMDS Bit Rates used by HDMI2.0 display modes.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 7f56d8c3491d..fae38b323a0c 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -318,6 +318,8 @@ static int dw_hdmi_rockchip_genphy_init(struct dw_hdmi
*dw_hdmi, void *data,
{
struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+ dw_hdmi_set_high_tmds_clock_ratio(dw_hdmi);
+
return phy_power_on(hdmi->phy);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/14] phy/rockchip: inno-hdmi: use correct vco_div_5 macro on rk3328
inno_hdmi_phy_rk3328_clk_set_rate() is using the RK3228 macro
when configuring vco_div_5 on RK3328.
Fix this by using correct vco_div_5 macro for RK3328.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 9ca20c947283..b0ac1d3ee390 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -790,8 +790,8 @@ static int inno_hdmi_phy_rk3328_clk_set_rate(struct clk_hw
*hw,
RK3328_PRE_PLL_POWER_DOWN);
/* Configure pre-pll */
- inno_update_bits(inno, 0xa0, RK3228_PCLK_VCO_DIV_5_MASK,
-RK3228_PCLK_VCO_DIV_5(cfg->vco_div_5_en));
+ inno_update_bits(inno, 0xa0, RK3328_PCLK_VCO_DIV_5_MASK,
+RK3328_PCLK_VCO_DIV_5(cfg->vco_div_5_en));
inno_write(inno, 0xa1, RK3328_PRE_PLL_PRE_DIV(cfg->prediv));
val = RK3328_SPREAD_SPECTRUM_MOD_DISABLE;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/14] phy/rockchip: inno-hdmi: force set_rate on power_on
From: Huicong Xu
Regular 8-bit and Deep Color video formats mainly differ in TMDS rate and
not in pixel clock rate.
When the hdmiphy clock is configured with the same pixel clock rate using
clk_set_rate() the clock framework do not signal the hdmi phy driver
to set_rate when switching between 8-bit and Deep Color.
This result in pre/post pll not being re-configured when switching between
regular 8-bit and Deep Color video formats.
Fix this by calling set_rate in power_on to force pre pll re-configuration.
Signed-off-by: Huicong Xu
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 3a59a6da0440..3719309ad0d0 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -245,6 +245,7 @@ struct inno_hdmi_phy {
struct clk_hw hw;
struct clk *phyclk;
unsigned long pixclock;
+ unsigned long tmdsclock;
};
struct pre_pll_config {
@@ -485,6 +486,8 @@ static int inno_hdmi_phy_power_on(struct phy *phy)
dev_dbg(inno->dev, "Inno HDMI PHY Power On\n");
+ inno->plat_data->clk_ops->set_rate(>hw, inno->pixclock, 2400);
+
ret = clk_prepare_enable(inno->phyclk);
if (ret)
return ret;
@@ -509,6 +512,8 @@ static int inno_hdmi_phy_power_off(struct phy *phy)
clk_disable_unprepare(inno->phyclk);
+ inno->tmdsclock = 0;
+
dev_dbg(inno->dev, "Inno HDMI PHY Power Off\n");
return 0;
@@ -628,6 +633,9 @@ static int inno_hdmi_phy_rk3228_clk_set_rate(struct clk_hw
*hw,
dev_dbg(inno->dev, "%s rate %lu tmdsclk %lu\n",
__func__, rate, tmdsclock);
+ if (inno->pixclock == rate && inno->tmdsclock == tmdsclock)
+ return 0;
+
cfg = inno_hdmi_phy_get_pre_pll_cfg(inno, rate);
if (IS_ERR(cfg))
return PTR_ERR(cfg);
@@ -670,6 +678,7 @@ static int inno_hdmi_phy_rk3228_clk_set_rate(struct clk_hw
*hw,
}
inno->pixclock = rate;
+ inno->tmdsclock = tmdsclock;
return 0;
}
@@ -781,6 +790,9 @@ static int inno_hdmi_phy_rk3328_clk_set_rate(struct clk_hw
*hw,
dev_dbg(inno->dev, "%s rate %lu tmdsclk %lu\n",
__func__, rate, tmdsclock);
+ if (inno->pixclock == rate && inno->tmdsclock == tmdsclock)
+ return 0;
+
cfg = inno_hdmi_phy_get_pre_pll_cfg(inno, rate);
if (IS_ERR(cfg))
return PTR_ERR(cfg);
@@ -820,6 +832,7 @@ static int inno_hdmi_phy_rk3328_clk_set_rate(struct clk_hw
*hw,
}
inno->pixclock = rate;
+ inno->tmdsclock = tmdsclock;
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/14] phy/rockchip: inno-hdmi: round fractal pixclock in rk3328 recalc_rate
From: Zheng Yang
inno_hdmi_phy_rk3328_clk_recalc_rate() is returning a rate not found
in the pre pll config table when the fractal divider is used.
This can prevent proper power_on because a tmdsclock for the new rate
is not found in the pre pll config table.
Fix this by saving and returning a rounded pixel rate that exist
in the pre pll config table.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Zheng Yang
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index b0ac1d3ee390..093d2334e8cd 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -745,10 +745,12 @@ unsigned long inno_hdmi_phy_rk3328_clk_recalc_rate(struct
clk_hw *hw,
do_div(vco, (nd * (no_a == 1 ? no_b : no_a) * no_d * 2));
}
- inno->pixclock = vco;
- dev_dbg(inno->dev, "%s rate %lu\n", __func__, inno->pixclock);
+ inno->pixclock = DIV_ROUND_CLOSEST((unsigned long)vco, 1000) * 1000;
- return vco;
+ dev_dbg(inno->dev, "%s rate %lu vco %llu\n",
+ __func__, inno->pixclock, vco);
+
+ return inno->pixclock;
}
static long inno_hdmi_phy_rk3328_clk_round_rate(struct clk_hw *hw,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/14] Support more HDMI modes on RK3228/RK3328
This series make it possible to use more HDMI modes on RK3328, and presumably also on RK3228. It also prepares for a future YUV420 and 10-bit output series. Part of this has been reworked from vendor BSP 4.4 kernel commits. Patch 1-5 fixes issues and shortcomings in the inno hdmi phy driver. Patch 6 prepares for use of high TMDS bit rates used with HDMI 2.0 and 10-bit output modes. Patch 7-13 changes rk3228/rk3328 to use mode_valid functions suited for the inno hdmi phy instead of the dw-hdmi phy. These changes allows for more CEA modes to be usable, e.g. some 4K and fractal modes. Patch 14 adds support for more pixel clock rates in order to support common DMT modes in addition to CEA modes. Note: I have only been able to build test RK322x related changes as I do not have any RK322x device to test on. All modes, including fractal modes, has been tested with modetest on a RK3328 Rock64 device using e.g. modetest -M rockchip -s 39:3840x2160-29.97 Changes in v2: - collect acked-by tag - drop the limit resolution width to 3840 patch This series is also available at [1] and the early work on YUV420 and 10-bit output is available at [2]. [1] https://github.com/Kwiboo/linux-rockchip/commits/next-20200108-inno-hdmi-phy [2] https://github.com/Kwiboo/linux-rockchip/commits/next-20200108-bus-format Regards, Jonas Algea Cao (1): phy/rockchip: inno-hdmi: Support more pre-pll configuration Huicong Xu (1): phy/rockchip: inno-hdmi: force set_rate on power_on Jonas Karlman (11): phy/rockchip: inno-hdmi: use correct vco_div_5 macro on rk3328 phy/rockchip: inno-hdmi: remove unused no_c from rk3328 recalc_rate phy/rockchip: inno-hdmi: do not power on rk3328 post pll on reg write drm/rockchip: dw-hdmi: allow high tmds bit rates drm/rockchip: dw-hdmi: require valid vpll clock rate on rk3228/rk3328 clk: rockchip: set parent rate for DCLK_VOP clock on rk3228 arm64: dts: rockchip: increase vop clock rate on rk3328 arm64: dts: rockchip: add vpll clock to hdmi node on rk3328 ARM: dts: rockchip: add vpll clock to hdmi node on rk3228 drm/rockchip: dw-hdmi: limit tmds to 340mhz on rk3228/rk3328 drm/rockchip: dw-hdmi: remove unused plat_data on rk3228/rk3328 Zheng Yang (1): phy/rockchip: inno-hdmi: round fractal pixclock in rk3328 recalc_rate arch/arm/boot/dts/rk322x.dtsi | 4 +- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 +- drivers/clk/rockchip/clk-rk3228.c | 2 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 47 ++-- drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 110 -- 5 files changed, 120 insertions(+), 49 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/4] drm/bridge: Add the necessary bits to support bus format negotiation
On 2020-01-06 15:34, Neil Armstrong wrote:
> From: Boris Brezillon
>
> drm_bridge_state is extended to describe the input and output bus
> configurations. These bus configurations are exposed through the
> drm_bus_cfg struct which encodes the configuration of a physical
> bus between two components in an output pipeline, usually between
> two bridges, an encoder and a bridge, or a bridge and a connector.
>
> The bus configuration is stored in drm_bridge_state separately for
> the input and output buses, as seen from the point of view of each
> bridge. The bus configuration of a bridge output is usually identical
> to the configuration of the next bridge's input, but may differ if
> the signals are modified between the two bridges, for instance by an
> inverter on the board. The input and output configurations of a
> bridge may differ if the bridge modifies the signals internally,
> for instance by performing format conversion, or*modifying signals
> polarities.
>
> Bus format negotiation is automated by the core, drivers just have
> to implement the ->atomic_get_{output,input}_bus_fmts() hooks if they
> want to take part to this negotiation. Negotiation happens in reverse
> order, starting from the last element of the chain (the one directly
> connected to the display) up to the first element of the chain (the one
> connected to the encoder).
> During this negotiation all supported formats are tested until we find
> one that works, meaning that the formats array should be in decreasing
> preference order (assuming the driver has a preference order).
>
> Note that the bus format negotiation works even if some elements in the
> chain don't implement the ->atomic_get_{output,input}_bus_fmts() hooks.
> In that case, the core advertises only MEDIA_BUS_FMT_FIXED and lets
> the previous bridge element decide what to do (most of the time, bridge
> drivers will pick a default bus format or extract this piece of
> information from somewhere else, like a FW property).
I have tested this series on a Rockchip RK3328 Rock64 device along with early
work
on rockchip dw-hdmi bus format negotiation at [1]. All output modes supported
on RK3328 works (RGB444, YUV420/444, 8/10-bit).
So for this entire series:
Tested-by: Jonas Karlman
[1] https://github.com/Kwiboo/linux-rockchip/commits/next-20200106-bus-format
Regards,
Jonas
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Neil Armstrong
> ---
> Changes in v6:
> * None
>
> Changes in v5:
> * None
>
> Changes in v4:
> * Enhance the doc
> * Fix typos
> * Rename some parameters/fields
> * Reword the commit message
>
> Changes in v3:
> * Fix the commit message (Reported by Laurent)
> * Document the fact that bus formats should not be directly modified by
> drivers (Suggested by Laurent)
> * Document the fact that format order matters (Suggested by Laurent)
> * Propagate bus flags by default
> * Document the fact that drivers can tweak bus flags if needed
> * Let ->atomic_get_{output,input}_bus_fmts() allocate the bus format
> array (Suggested by Laurent)
> * Add a drm_atomic_helper_bridge_propagate_bus_fmt()
> * Mandate that bridge drivers return accurate input_fmts even if they
> are known to be the first element in the bridge chain
>
> Changes in v2:
> * Rework things to support more complex use cases
> ---
> drivers/gpu/drm/drm_bridge.c | 267 ++-
> include/drm/drm_bridge.h | 124
> 2 files changed, 390 insertions(+), 1 deletion(-)
>
> (...)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/15] drm/rockchip: vop: limit resolution width to 3840
On 2020-01-06 22:18, Heiko Stübner wrote:
> Hi Jonas,
>
> Am Montag, 6. Januar 2020, 21:48:25 CET schrieb Jonas Karlman:
>> Using a destination width that is more then 3840 pixels
>> is not supported in scl_vop_cal_scl_fac().
>>
>> Work around this limitation by filtering all modes with
>> a width above 3840 pixels.
> could you try to send the whole series to people? I only get this patch6
> of a series of 15 and that is way confusing not knowing what you want
> to actually achieve.
Very strange, you are the recipient of all patches, and they where delivered to
patchworks at [1] and [2], I also have a copy of this series at [3].
This is part of a series for adding support for more HDMI modes on the
RK3228/RK3328.
Also preparation for adding bus format negotiation for YUV420 and 10-bit output
mode,
early bus format work is located at [4].
[1] https://patchwork.kernel.org/cover/11320061/
[2] https://patchwork.freedesktop.org/series/71675/
[3] https://github.com/Kwiboo/linux-rockchip/commits/next-20200106-inno-hdmi-phy
[4] https://github.com/Kwiboo/linux-rockchip/commits/next-20200106-bus-format
>
> Hence I can also just point to rk3229, rk3328, rk3368 and rk3399 that
> report a max output of 4096x2160 , which would be larger than that
> 3840 value?
Currently the scaling code in rockchip drm driver is limiting the use of large
framebuffers at [5].
This scaling limitation made it impossible for me to use any 4096x mode that my
TV supports.
if (dst_w > 3840) {
DRM_DEV_ERROR(vop->dev, "Maximum dst width (3840) exceeded\n");
[5]
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#L329-L332
Regards,
Jonas
>
>
> Heiko
>
>
>> Signed-off-by: Jonas Karlman
>> ---
>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index d04b3492bdac..f181897cbfad 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -1036,6 +1036,15 @@ static void vop_crtc_disable_vblank(struct drm_crtc
>> *crtc)
>> spin_unlock_irqrestore(>irq_lock, flags);
>> }
>>
>> +enum drm_mode_status vop_crtc_mode_valid(struct drm_crtc *crtc,
>> + const struct drm_display_mode *mode)
>> +{
>> +if (mode->hdisplay > 3840)
>> +return MODE_BAD_HVALUE;
>> +
>> +return MODE_OK;
>> +}
>> +
>> static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
>> const struct drm_display_mode *mode,
>> struct drm_display_mode *adjusted_mode)
>> @@ -1377,6 +1386,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc
>> *crtc,
>> }
>>
>> static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
>> +.mode_valid = vop_crtc_mode_valid,
>> .mode_fixup = vop_crtc_mode_fixup,
>> .atomic_check = vop_crtc_atomic_check,
>> .atomic_begin = vop_crtc_atomic_begin,
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/15] drm/rockchip: dw-hdmi: remove unused plat_data on rk3228/rk3328
mpll_cfg/cur_ctr/phy_config is not used when phy_force_vendor is true,
lets remove them.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 66c14df4a680..a813299e97a2 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -443,9 +443,6 @@ static struct rockchip_hdmi_chip_data rk3228_chip_data = {
static const struct dw_hdmi_plat_data rk3228_hdmi_drv_data = {
.mode_valid = dw_hdmi_rk3228_mode_valid,
- .mpll_cfg = rockchip_mpll_cfg,
- .cur_ctr = rockchip_cur_ctr,
- .phy_config = rockchip_phy_config,
.phy_data = _chip_data,
.phy_ops = _hdmi_phy_ops,
.phy_name = "inno_dw_hdmi_phy2",
@@ -480,9 +477,6 @@ static struct rockchip_hdmi_chip_data rk3328_chip_data = {
static const struct dw_hdmi_plat_data rk3328_hdmi_drv_data = {
.mode_valid = dw_hdmi_rk3228_mode_valid,
- .mpll_cfg = rockchip_mpll_cfg,
- .cur_ctr = rockchip_cur_ctr,
- .phy_config = rockchip_phy_config,
.phy_data = _chip_data,
.phy_ops = _hdmi_phy_ops,
.phy_name = "inno_dw_hdmi_phy2",
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 13/15] drm/rockchip: dw-hdmi: limit tmds to 340mhz on rk3228/rk3328
RK3228/RK3328 does not provide a stable hdmi signal at TMDS rates
above 371.25MHz (340MHz pixel clock).
Limit the pixel clock rate to 340MHz to provide a stable signal.
Also limit the pixel clock to the display reported max tmds clock.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 22 +++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 45fcdce3f27f..66c14df4a680 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -237,6 +237,24 @@ dw_hdmi_rockchip_mode_valid(struct drm_connector
*connector,
return (valid) ? MODE_OK : MODE_BAD;
}
+static enum drm_mode_status
+dw_hdmi_rk3228_mode_valid(struct drm_connector *connector,
+ const struct drm_display_mode *mode)
+{
+ struct drm_display_info *info = >display_info;
+ int max_tmds_clock = max(info->max_tmds_clock, 165000);
+ int clock = mode->clock;
+
+ if (connector->ycbcr_420_allowed && drm_mode_is_420(info, mode) &&
+ (info->color_formats & DRM_COLOR_FORMAT_YCRCB420))
+ clock /= 2;
+
+ if (clock > max_tmds_clock || clock > 34)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
static const struct drm_encoder_funcs dw_hdmi_rockchip_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
@@ -424,7 +442,7 @@ static struct rockchip_hdmi_chip_data rk3228_chip_data = {
};
static const struct dw_hdmi_plat_data rk3228_hdmi_drv_data = {
- .mode_valid = dw_hdmi_rockchip_mode_valid,
+ .mode_valid = dw_hdmi_rk3228_mode_valid,
.mpll_cfg = rockchip_mpll_cfg,
.cur_ctr = rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
@@ -461,7 +479,7 @@ static struct rockchip_hdmi_chip_data rk3328_chip_data = {
};
static const struct dw_hdmi_plat_data rk3328_hdmi_drv_data = {
- .mode_valid = dw_hdmi_rockchip_mode_valid,
+ .mode_valid = dw_hdmi_rk3228_mode_valid,
.mpll_cfg = rockchip_mpll_cfg,
.cur_ctr = rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 15/15] phy/rockchip: inno-hdmi: Support more pre-pll configuration
From: Algea Cao
Adding the following freq cfg in 8-bit and 10-bit color depth:
{
4000, 6500, 7100, 8350, 8575,
8875, 10800, 11900, 16200
}
New freq has been validated by quantumdata 980.
For some freq which can't be got by only using integer freq div,
frac freq div is needed, Such as 88.75Mhz 10-bit. But The actual
freq is different from the target freq, We must try to narrow
the gap between them. RK322X only support integer freq div.
The VCO of pre-PLL must be more than 2Ghz, otherwise PLL may be
unlocked.
Signed-off-by: Algea Cao
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 74 ---
1 file changed, 49 insertions(+), 25 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 3719309ad0d0..bb8bdf5e3301 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -291,32 +291,56 @@ struct inno_hdmi_phy_drv_data {
const struct phy_config *phy_cfg_table;
};
+/*
+ * If only using integer freq div can't get frequency we want, frac
+ * freq div is needed. For example, pclk 88.75 Mhz and tmdsclk
+ * 110.9375 Mhz must use frac div 0xF0. The actual frequency is different
+ * from the target frequency. Such as the tmds clock 110.9375 Mhz,
+ * the actual tmds clock we get is 110.93719 Mhz. It is important
+ * to note that RK322X platforms do not support frac div.
+ */
static const struct pre_pll_config pre_pll_cfg_table[] = {
- { 2700, 2700, 1, 90, 3, 2, 2, 10, 3, 3, 4, 0, 0},
- { 2700, 3375, 1, 90, 1, 3, 3, 10, 3, 3, 4, 0, 0},
- { 4000, 4000, 1, 80, 2, 2, 2, 12, 2, 2, 2, 0, 0},
- { 59341000, 59341000, 1, 98, 3, 1, 2, 1, 3, 3, 4, 0, 0xE6AE6B},
- { 5940, 5940, 1, 99, 3, 1, 1, 1, 3, 3, 4, 0, 0},
- { 59341000, 74176250, 1, 98, 0, 3, 3, 1, 3, 3, 4, 0, 0xE6AE6B},
- { 5940, 7425, 1, 99, 1, 2, 2, 1, 3, 3, 4, 0, 0},
- { 74176000, 74176000, 1, 98, 1, 2, 2, 1, 2, 3, 4, 0, 0xE6AE6B},
- { 7425, 7425, 1, 99, 1, 2, 2, 1, 2, 3, 4, 0, 0},
- { 74176000, 9272, 4, 494, 1, 2, 2, 1, 3, 3, 4, 0, 0x816817},
- { 7425, 92812500, 4, 495, 1, 2, 2, 1, 3, 3, 4, 0, 0},
- {148352000, 148352000, 1, 98, 1, 1, 1, 1, 2, 2, 2, 0, 0xE6AE6B},
- {14850, 14850, 1, 99, 1, 1, 1, 1, 2, 2, 2, 0, 0},
- {148352000, 18544, 4, 494, 0, 2, 2, 1, 3, 2, 2, 0, 0x816817},
- {14850, 185625000, 4, 495, 0, 2, 2, 1, 3, 2, 2, 0, 0},
- {296703000, 296703000, 1, 98, 0, 1, 1, 1, 0, 2, 2, 0, 0xE6AE6B},
- {29700, 29700, 1, 99, 0, 1, 1, 1, 0, 2, 2, 0, 0},
- {296703000, 370878750, 4, 494, 1, 2, 0, 1, 3, 1, 1, 0, 0x816817},
- {29700, 37125, 4, 495, 1, 2, 0, 1, 3, 1, 1, 0, 0},
- {593407000, 296703500, 1, 98, 0, 1, 1, 1, 0, 2, 1, 0, 0xE6AE6B},
- {59400, 29700, 1, 99, 0, 1, 1, 1, 0, 2, 1, 0, 0},
- {593407000, 370879375, 4, 494, 1, 2, 0, 1, 3, 1, 1, 1, 0x816817},
- {59400, 37125, 4, 495, 1, 2, 0, 1, 3, 1, 1, 1, 0},
- {593407000, 593407000, 1, 98, 0, 2, 0, 1, 0, 1, 1, 0, 0xE6AE6B},
- {59400, 59400, 1, 99, 0, 2, 0, 1, 0, 1, 1, 0, 0},
+ { 2700, 2700, 1, 90, 3, 2, 2, 10, 3, 3, 4, 0, 0},
+ { 2700, 3375, 1, 90, 1, 3, 3, 10, 3, 3, 4, 0, 0},
+ { 4000, 4000, 1, 80, 2, 2, 2, 12, 2, 2, 2, 0, 0},
+ { 4000, 5000, 1, 100, 2, 2, 2, 1, 0, 0, 15, 0, 0},
+ { 59341000, 59341000, 1, 98, 3, 1, 2, 1, 3, 3, 4, 0, 0xE6AE6B},
+ { 5940, 5940, 1, 99, 3, 1, 1, 1, 3, 3, 4, 0, 0},
+ { 59341000, 74176250, 1, 98, 0, 3, 3, 1, 3, 3, 4, 0, 0xE6AE6B},
+ { 5940, 7425, 1, 99, 1, 2, 2, 1, 3, 3, 4, 0, 0},
+ { 6500, 6500, 1, 130, 2, 2, 2, 1, 0, 0, 12, 0, 0},
+ { 6500, 8125, 3, 325, 0, 3, 3, 1, 0, 0, 10, 0, 0},
+ { 7100, 7100, 3, 284, 0, 3, 3, 1, 0, 0, 8, 0, 0},
+ { 7100, 8875, 3, 355, 0, 3, 3, 1, 0, 0, 10, 0, 0},
+ { 74176000, 74176000, 1, 98, 1, 2, 2, 1, 2, 3, 4, 0, 0xE6AE6B},
+ { 7425, 7425, 1, 99, 1, 2, 2, 1, 2, 3, 4, 0, 0},
+ { 74176000, 9272, 4, 494, 1, 2, 2, 1, 3, 3, 4, 0, 0x816817},
+ { 7425, 92812500, 4, 495, 1, 2, 2, 1, 3, 3, 4, 0, 0},
+ { 8350, 8350, 2, 167, 2, 1, 1, 1, 0, 0, 6, 0, 0},
+ { 8350, 104375000, 1, 104, 2, 1, 1, 1, 1, 0, 5, 0, 0x60},
+ { 8575, 8575, 3, 343, 0, 3, 3, 1, 0, 0, 8, 0, 0},
+ { 8875, 8875, 3, 355, 0, 3, 3, 1, 0, 0, 8, 0, 0},
+ { 8875, 110937500, 1, 110, 2, 1, 1, 1, 1, 0, 5, 0, 0xF0},
+ {10800, 10800, 1, 90, 3, 0, 0, 1, 0, 0, 5, 0, 0},
+ {10800, 13500, 1, 90, 0, 2, 2, 1, 0, 0, 5, 0, 0
[PATCH 10/15] arm64: dts: rockchip: increase vop clock rate on rk3328
The VOP on RK3328 needs to run at higher rate in order to produce a proper 3840x2160 signal. Signed-off-by: Jonas Karlman --- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi index 91306ebed4da..ee4b6170a9e6 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi @@ -786,8 +786,8 @@ <0>, <2400>, <2400>, <2400>, <1500>, <1500>, - <1>, <1>, - <1>, <1>, + <3>, <1>, + <4>, <1>, <5000>, <1>, <1>, <1>, <5000>, <5000>, -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/15] arm64: dts: rockchip: add vpll clock to hdmi node on rk3328
Add the hdmiphy clock as the vpll in hdmi node. Signed-off-by: Jonas Karlman --- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi index ee4b6170a9e6..987c04abb387 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi @@ -703,9 +703,11 @@ ; clocks = < PCLK_HDMI>, < SCLK_HDMI_SFC>, +<>, < SCLK_RTC32K>; clock-names = "iahb", "isfr", + "vpll", "cec"; phys = <>; phy-names = "hdmi"; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/15] ARM: dts: rockchip: add vpll clock to hdmi node on rk3228
Add the hdmiphy clock as the vpll in hdmi node. Signed-off-by: Jonas Karlman --- arch/arm/boot/dts/rk322x.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi index 340ed6ccb08f..16ad240d5f7f 100644 --- a/arch/arm/boot/dts/rk322x.dtsi +++ b/arch/arm/boot/dts/rk322x.dtsi @@ -639,8 +639,8 @@ interrupts = ; assigned-clocks = < SCLK_HDMI_PHY>; assigned-clock-parents = <_phy>; - clocks = < SCLK_HDMI_HDCP>, < PCLK_HDMI_CTRL>, < SCLK_HDMI_CEC>; - clock-names = "isfr", "iahb", "cec"; + clocks = < SCLK_HDMI_HDCP>, < PCLK_HDMI_CTRL>, <_phy>, < SCLK_HDMI_CEC>; + clock-names = "isfr", "iahb", "vpll", "cec"; pinctrl-names = "default"; pinctrl-0 = <_xfer _hpd _cec>; resets = < SRST_HDMI_P>; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/15] clk: rockchip: set parent rate for DCLK_VOP clock on rk3228
Signed-off-by: Jonas Karlman
---
drivers/clk/rockchip/clk-rk3228.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3228.c
b/drivers/clk/rockchip/clk-rk3228.c
index d17cfb7a3ff4..25f79af22cb8 100644
--- a/drivers/clk/rockchip/clk-rk3228.c
+++ b/drivers/clk/rockchip/clk-rk3228.c
@@ -410,7 +410,7 @@ static struct rockchip_clk_branch rk3228_clk_branches[]
__initdata = {
RK2928_CLKSEL_CON(29), 0, 3, DFLAGS),
DIV(0, "sclk_vop_pre", "sclk_vop_src", 0,
RK2928_CLKSEL_CON(27), 8, 8, DFLAGS),
- MUX(DCLK_VOP, "dclk_vop", mux_dclk_vop_p, 0,
+ MUX(DCLK_VOP, "dclk_vop", mux_dclk_vop_p, CLK_SET_RATE_PARENT |
CLK_SET_RATE_NO_REPARENT,
RK2928_CLKSEL_CON(27), 1, 1, MFLAGS),
FACTOR(0, "xin12m", "xin24m", 0, 1, 2),
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/15] drm/rockchip: dw-hdmi: require valid vpll clock rate on rk3228/rk3328
RK3228/RK3328 can only support clock rates defined in the pre pll table.
Lets validate the mode clock rate against the pre pll config and filter
out any mode with a clock rate returning error from clk_round_rate().
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index fae38b323a0c..45fcdce3f27f 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -245,6 +245,22 @@ static void dw_hdmi_rockchip_encoder_disable(struct
drm_encoder *encoder)
{
}
+static enum drm_mode_status
+dw_hdmi_rockchip_encoder_mode_valid(struct drm_encoder *encoder,
+ const struct drm_display_mode *mode)
+{
+ struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
+ long rate;
+
+ if (hdmi->vpll_clk) {
+ rate = clk_round_rate(hdmi->vpll_clk, mode->clock * 1000);
+ if (rate < 0)
+ return MODE_CLOCK_RANGE;
+ }
+
+ return MODE_OK;
+}
+
static bool
dw_hdmi_rockchip_encoder_mode_fixup(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
@@ -306,6 +322,7 @@ dw_hdmi_rockchip_encoder_atomic_check(struct drm_encoder
*encoder,
}
static const struct drm_encoder_helper_funcs
dw_hdmi_rockchip_encoder_helper_funcs = {
+ .mode_valid = dw_hdmi_rockchip_encoder_mode_valid,
.mode_fixup = dw_hdmi_rockchip_encoder_mode_fixup,
.mode_set = dw_hdmi_rockchip_encoder_mode_set,
.enable = dw_hdmi_rockchip_encoder_enable,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/15] drm/rockchip: dw-hdmi: allow high tmds bit rates
Prepare support for High TMDS Bit Rates used by HDMI2.0 display modes.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 7f56d8c3491d..fae38b323a0c 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -318,6 +318,8 @@ static int dw_hdmi_rockchip_genphy_init(struct dw_hdmi
*dw_hdmi, void *data,
{
struct rockchip_hdmi *hdmi = (struct rockchip_hdmi *)data;
+ dw_hdmi_set_high_tmds_clock_ratio(dw_hdmi);
+
return phy_power_on(hdmi->phy);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/15] phy/rockchip: inno-hdmi: remove unused no_c from rk3328 recalc_rate
no_c is not used in any calculation, lets remove it.
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 093d2334e8cd..06db69c8373e 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -714,7 +714,7 @@ unsigned long inno_hdmi_phy_rk3328_clk_recalc_rate(struct
clk_hw *hw,
{
struct inno_hdmi_phy *inno = to_inno_hdmi_phy(hw);
unsigned long frac;
- u8 nd, no_a, no_b, no_c, no_d;
+ u8 nd, no_a, no_b, no_d;
u64 vco;
u16 nf;
@@ -737,9 +737,6 @@ unsigned long inno_hdmi_phy_rk3328_clk_recalc_rate(struct
clk_hw *hw,
no_b = inno_read(inno, 0xa5) & RK3328_PRE_PLL_PCLK_DIV_B_MASK;
no_b >>= RK3328_PRE_PLL_PCLK_DIV_B_SHIFT;
no_b += 2;
- no_c = inno_read(inno, 0xa6) & RK3328_PRE_PLL_PCLK_DIV_C_MASK;
- no_c >>= RK3328_PRE_PLL_PCLK_DIV_C_SHIFT;
- no_c = 1 << no_c;
no_d = inno_read(inno, 0xa6) & RK3328_PRE_PLL_PCLK_DIV_D_MASK;
do_div(vco, (nd * (no_a == 1 ? no_b : no_a) * no_d * 2));
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/15] phy/rockchip: inno-hdmi: use correct vco_div_5 macro on rk3328
inno_hdmi_phy_rk3328_clk_set_rate() is using the RK3228 macro
when configuring vco_div_5 on RK3328.
Fix this by using correct vco_div_5 macro for RK3328.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 9ca20c947283..b0ac1d3ee390 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -790,8 +790,8 @@ static int inno_hdmi_phy_rk3328_clk_set_rate(struct clk_hw
*hw,
RK3328_PRE_PLL_POWER_DOWN);
/* Configure pre-pll */
- inno_update_bits(inno, 0xa0, RK3228_PCLK_VCO_DIV_5_MASK,
-RK3228_PCLK_VCO_DIV_5(cfg->vco_div_5_en));
+ inno_update_bits(inno, 0xa0, RK3328_PCLK_VCO_DIV_5_MASK,
+RK3328_PCLK_VCO_DIV_5(cfg->vco_div_5_en));
inno_write(inno, 0xa1, RK3328_PRE_PLL_PRE_DIV(cfg->prediv));
val = RK3328_SPREAD_SPECTRUM_MOD_DISABLE;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/15] drm/rockchip: vop: limit resolution width to 3840
Using a destination width that is more then 3840 pixels
is not supported in scl_vop_cal_scl_fac().
Work around this limitation by filtering all modes with
a width above 3840 pixels.
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index d04b3492bdac..f181897cbfad 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1036,6 +1036,15 @@ static void vop_crtc_disable_vblank(struct drm_crtc
*crtc)
spin_unlock_irqrestore(>irq_lock, flags);
}
+enum drm_mode_status vop_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode *mode)
+{
+ if (mode->hdisplay > 3840)
+ return MODE_BAD_HVALUE;
+
+ return MODE_OK;
+}
+
static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
@@ -1377,6 +1386,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
}
static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
+ .mode_valid = vop_crtc_mode_valid,
.mode_fixup = vop_crtc_mode_fixup,
.atomic_check = vop_crtc_atomic_check,
.atomic_begin = vop_crtc_atomic_begin,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/15] phy/rockchip: inno-hdmi: force set_rate on power_on
From: Huicong Xu
Regular 8-bit and Deep Color video formats mainly differ in TMDS rate and
not in pixel clock rate.
When the hdmiphy clock is configured with the same pixel clock rate using
clk_set_rate() the clock framework do not signal the hdmi phy driver
to set_rate when switching between 8-bit and Deep Color.
This result in pre/post pll not being re-configured when switching between
regular 8-bit and Deep Color video formats.
Fix this by calling set_rate in power_on to force pre pll re-configuration.
Signed-off-by: Huicong Xu
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 3a59a6da0440..3719309ad0d0 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -245,6 +245,7 @@ struct inno_hdmi_phy {
struct clk_hw hw;
struct clk *phyclk;
unsigned long pixclock;
+ unsigned long tmdsclock;
};
struct pre_pll_config {
@@ -485,6 +486,8 @@ static int inno_hdmi_phy_power_on(struct phy *phy)
dev_dbg(inno->dev, "Inno HDMI PHY Power On\n");
+ inno->plat_data->clk_ops->set_rate(>hw, inno->pixclock, 2400);
+
ret = clk_prepare_enable(inno->phyclk);
if (ret)
return ret;
@@ -509,6 +512,8 @@ static int inno_hdmi_phy_power_off(struct phy *phy)
clk_disable_unprepare(inno->phyclk);
+ inno->tmdsclock = 0;
+
dev_dbg(inno->dev, "Inno HDMI PHY Power Off\n");
return 0;
@@ -628,6 +633,9 @@ static int inno_hdmi_phy_rk3228_clk_set_rate(struct clk_hw
*hw,
dev_dbg(inno->dev, "%s rate %lu tmdsclk %lu\n",
__func__, rate, tmdsclock);
+ if (inno->pixclock == rate && inno->tmdsclock == tmdsclock)
+ return 0;
+
cfg = inno_hdmi_phy_get_pre_pll_cfg(inno, rate);
if (IS_ERR(cfg))
return PTR_ERR(cfg);
@@ -670,6 +678,7 @@ static int inno_hdmi_phy_rk3228_clk_set_rate(struct clk_hw
*hw,
}
inno->pixclock = rate;
+ inno->tmdsclock = tmdsclock;
return 0;
}
@@ -781,6 +790,9 @@ static int inno_hdmi_phy_rk3328_clk_set_rate(struct clk_hw
*hw,
dev_dbg(inno->dev, "%s rate %lu tmdsclk %lu\n",
__func__, rate, tmdsclock);
+ if (inno->pixclock == rate && inno->tmdsclock == tmdsclock)
+ return 0;
+
cfg = inno_hdmi_phy_get_pre_pll_cfg(inno, rate);
if (IS_ERR(cfg))
return PTR_ERR(cfg);
@@ -820,6 +832,7 @@ static int inno_hdmi_phy_rk3328_clk_set_rate(struct clk_hw
*hw,
}
inno->pixclock = rate;
+ inno->tmdsclock = tmdsclock;
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/15] phy/rockchip: inno-hdmi: do not power on rk3328 post pll on reg write
inno_write is used to configure 0xaa reg, that also hold the
POST_PLL_POWER_DOWN bit.
When POST_PLL_REFCLK_SEL_TMDS is configured the power down bit is not
taken into consideration.
Fix this by keeping the power down bit until configuration is complete.
Also reorder the reg write order for consistency.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 06db69c8373e..3a59a6da0440 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -1020,9 +1020,10 @@ inno_hdmi_phy_rk3328_power_on(struct inno_hdmi_phy *inno,
inno_write(inno, 0xac, RK3328_POST_PLL_FB_DIV_7_0(cfg->fbdiv));
if (cfg->postdiv == 1) {
- inno_write(inno, 0xaa, RK3328_POST_PLL_REFCLK_SEL_TMDS);
inno_write(inno, 0xab, RK3328_POST_PLL_FB_DIV_8(cfg->fbdiv) |
RK3328_POST_PLL_PRE_DIV(cfg->prediv));
+ inno_write(inno, 0xaa, RK3328_POST_PLL_REFCLK_SEL_TMDS |
+ RK3328_POST_PLL_POWER_DOWN);
} else {
v = (cfg->postdiv / 2) - 1;
v &= RK3328_POST_PLL_POST_DIV_MASK;
@@ -1030,7 +1031,8 @@ inno_hdmi_phy_rk3328_power_on(struct inno_hdmi_phy *inno,
inno_write(inno, 0xab, RK3328_POST_PLL_FB_DIV_8(cfg->fbdiv) |
RK3328_POST_PLL_PRE_DIV(cfg->prediv));
inno_write(inno, 0xaa, RK3328_POST_PLL_POST_DIV_ENABLE |
- RK3328_POST_PLL_REFCLK_SEL_TMDS);
+ RK3328_POST_PLL_REFCLK_SEL_TMDS |
+ RK3328_POST_PLL_POWER_DOWN);
}
for (v = 0; v < 14; v++)
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/15] phy/rockchip: inno-hdmi: round fractal pixclock in rk3328 recalc_rate
From: Zheng Yang
inno_hdmi_phy_rk3328_clk_recalc_rate() is returning a rate not found
in the pre pll config table when the fractal divider is used.
This can prevent proper power_on because a tmdsclock for the new rate
is not found in the pre pll config table.
Fix this by saving and returning a rounded pixel rate that exist
in the pre pll config table.
Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy")
Signed-off-by: Zheng Yang
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index b0ac1d3ee390..093d2334e8cd 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -745,10 +745,12 @@ unsigned long inno_hdmi_phy_rk3328_clk_recalc_rate(struct
clk_hw *hw,
do_div(vco, (nd * (no_a == 1 ? no_b : no_a) * no_d * 2));
}
- inno->pixclock = vco;
- dev_dbg(inno->dev, "%s rate %lu\n", __func__, inno->pixclock);
+ inno->pixclock = DIV_ROUND_CLOSEST((unsigned long)vco, 1000) * 1000;
- return vco;
+ dev_dbg(inno->dev, "%s rate %lu vco %llu\n",
+ __func__, inno->pixclock, vco);
+
+ return inno->pixclock;
}
static long inno_hdmi_phy_rk3328_clk_round_rate(struct clk_hw *hw,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/15] Support more HDMI modes on RK3228/RK3328
This series make it possible to use more HDMI modes on RK3328, and presumably also on RK3228. It also prepares for a future YUV420 and 10-bit output series. Part of this has been reworked from vendor BSP 4.4 kernel commits. Patch 1-5 fixes issues and shortcomings in the inno hdmi phy driver. Patch 6 filter out any mode having larger width then 3840 pixels, e.g 4096x2304 modes, since limitations in the scaler code trigger an error for a large console framebuffer. Patch 7 prepares for use of high TMDS bit rates used with HDMI2.0 and 10-bit output modes. Patch 8-14 changes rk3228/rk3328 to use mode_valid functions suited for the inno hdmi phy instead of the dw-hdmi phy. This Patch 15 adds support for more pixel clock rates in order to support common DMT modes in addition to CEA modes. Note: I have only been able to build test RK322x related changes as I do not have any RK322x device to test on. All modes, including fractal modes, has been tested with modetest on a RK3328 Rock64 device. modetest -M rockchip -s 39:3840x2160-29.97 Regards, Jonas Algea Cao (1): phy/rockchip: inno-hdmi: Support more pre-pll configuration Huicong Xu (1): phy/rockchip: inno-hdmi: force set_rate on power_on Jonas Karlman (12): phy/rockchip: inno-hdmi: use correct vco_div_5 macro on rk3328 phy/rockchip: inno-hdmi: remove unused no_c from rk3328 recalc_rate phy/rockchip: inno-hdmi: do not power on rk3328 post pll on reg write drm/rockchip: vop: limit resolution width to 3840 drm/rockchip: dw-hdmi: allow high tmds bit rates drm/rockchip: dw-hdmi: require valid vpll clock rate on rk3228/rk3328 clk: rockchip: set parent rate for DCLK_VOP clock on rk3228 arm64: dts: rockchip: increase vop clock rate on rk3328 arm64: dts: rockchip: add vpll clock to hdmi node on rk3328 ARM: dts: rockchip: add vpll clock to hdmi node on rk3228 drm/rockchip: dw-hdmi: limit tmds to 340mhz on rk3228/rk3328 drm/rockchip: dw-hdmi: remove unused plat_data on rk3228/rk3328 Zheng Yang (1): phy/rockchip: inno-hdmi: round fractal pixclock in rk3328 recalc_rate arch/arm/boot/dts/rk322x.dtsi | 4 +- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 +- drivers/clk/rockchip/clk-rk3228.c | 2 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 47 ++-- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 ++ drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 110 -- 6 files changed, 130 insertions(+), 49 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH for 5.5] phy/rockchip: inno-hdmi: round clock rate down to closest 1000 Hz
Commit 287422a95fe2 ("drm/rockchip: Round up _before_ giving to the clock
framework")
changed what rate clk_round_rate() is called with, an additional 999 Hz
added to the requsted mode clock. This has caused a regression on RK3328
and presumably also on RK3228 because the inno-hdmi-phy clock requires an
exact match of the requested rate in the pre pll config table.
When an exact match is not found the parent clock rate (24MHz) is returned
to the clk_round_rate() caller. This cause wrong pixel clock to be used and
result in no-signal when configuring a mode on RK3328.
Fix this by rounding the rate down to closest 1000 Hz in round_rate func,
this allows an exact match to be found in pre pll config table.
Fixes: 287422a95fe2 ("drm/rockchip: Round up _before_ giving to the clock
framework")
Signed-off-by: Jonas Karlman
---
drivers/phy/rockchip/phy-rockchip-inno-hdmi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
index 2b97fb1185a0..9ca20c947283 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-hdmi.c
@@ -603,6 +603,8 @@ static long inno_hdmi_phy_rk3228_clk_round_rate(struct
clk_hw *hw,
{
const struct pre_pll_config *cfg = pre_pll_cfg_table;
+ rate = (rate / 1000) * 1000;
+
for (; cfg->pixclock != 0; cfg++)
if (cfg->pixclock == rate && !cfg->fracdiv)
break;
@@ -755,6 +757,8 @@ static long inno_hdmi_phy_rk3328_clk_round_rate(struct
clk_hw *hw,
{
const struct pre_pll_config *cfg = pre_pll_cfg_table;
+ rate = (rate / 1000) * 1000;
+
for (; cfg->pixclock != 0; cfg++)
if (cfg->pixclock == rate)
break;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/meson: Enable DRM InfoFrame support on GXL, GXM and G12A
This patch enables Dynamic Range and Mastering InfoFrame on GXL, GXM and G12A. Cc: Neil Armstrong Signed-off-by: Jonas Karlman Reviewed-by: Neil Armstrong --- drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c b/drivers/gpu/drm/meson/meson_dw_hdmi.c index 022286dc6ab2..3bb7ffe5fc39 100644 --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c @@ -977,6 +977,11 @@ static int meson_dw_hdmi_bind(struct device *dev, struct device *master, dw_plat_data->input_bus_format = MEDIA_BUS_FMT_YUV8_1X24; dw_plat_data->input_bus_encoding = V4L2_YCBCR_ENC_709; + if (dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxl-dw-hdmi") || + dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxm-dw-hdmi") || + dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-g12a-dw-hdmi")) + dw_plat_data->use_drm_infoframe = true; + platform_set_drvdata(pdev, meson_dw_hdmi); meson_dw_hdmi->hdmi = dw_hdmi_bind(pdev, encoder, -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] drm/sun4i: Enable DRM InfoFrame support on H6
This patch enables Dynamic Range and Mastering InfoFrame on H6.
Cc: Maxime Ripard
Cc: Jernej Skrabec
Signed-off-by: Jonas Karlman
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 ++
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index a44dca4b0219..e8a317d5ba19 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -226,6 +226,7 @@ static int sun8i_dw_hdmi_bind(struct device *dev, struct
device *master,
sun8i_hdmi_phy_init(hdmi->phy);
plat_data->mode_valid = hdmi->quirks->mode_valid;
+ plat_data->use_drm_infoframe = hdmi->quirks->use_drm_infoframe;
sun8i_hdmi_phy_set_ops(hdmi->phy, plat_data);
platform_set_drvdata(pdev, hdmi);
@@ -300,6 +301,7 @@ static const struct sun8i_dw_hdmi_quirks sun8i_a83t_quirks
= {
static const struct sun8i_dw_hdmi_quirks sun50i_h6_quirks = {
.mode_valid = sun8i_dw_hdmi_mode_valid_h6,
+ .use_drm_infoframe = true,
};
static const struct of_device_id sun8i_dw_hdmi_dt_ids[] = {
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
index d707c9171824..8e64945167e9 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -179,6 +179,7 @@ struct sun8i_dw_hdmi_quirks {
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
const struct drm_display_mode *mode);
unsigned int set_rate : 1;
+ unsigned int use_drm_infoframe : 1;
};
struct sun8i_dw_hdmi {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/rockchip: Enable DRM InfoFrame support on RK3328 and RK3399
This patch enables Dynamic Range and Mastering InfoFrame on RK3328 and RK3399.
Cc: Sandy Huang
Cc: Heiko Stuebner
Signed-off-by: Jonas Karlman
Reviewed-by: Heiko Stuebner
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 906891b03a38..7f56d8c3491d 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -450,6 +450,7 @@ static const struct dw_hdmi_plat_data rk3328_hdmi_drv_data
= {
.phy_ops = _hdmi_phy_ops,
.phy_name = "inno_dw_hdmi_phy2",
.phy_force_vendor = true,
+ .use_drm_infoframe = true,
};
static struct rockchip_hdmi_chip_data rk3399_chip_data = {
@@ -464,6 +465,7 @@ static const struct dw_hdmi_plat_data rk3399_hdmi_drv_data
= {
.cur_ctr= rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
.phy_data = _chip_data,
+ .use_drm_infoframe = true,
};
static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm/bridge: dw-hdmi: Add Dynamic Range and Mastering InfoFrame support
Add support for configuring Dynamic Range and Mastering InfoFrame from
the hdr_output_metadata connector property.
This patch adds a use_drm_infoframe flag to dw_hdmi_plat_data that platform
drivers use to signal when Dynamic Range and Mastering infoframes is supported.
This flag is needed because Amlogic GXBB and GXL report same DW-HDMI version,
and only GXL support DRM InfoFrame.
These changes were based on work done by Zheng Yang
to support DRM InfoFrame on the Rockchip 4.4 BSP kernel at [1] and [2]
[1] https://github.com/rockchip-linux/kernel/tree/develop-4.4
[2]
https://github.com/rockchip-linux/kernel/commit/d1943fde81ff41d7cca87f4a42f03992e90bddd5
Cc: Zheng Yang
Signed-off-by: Jonas Karlman
Reviewed-by: Neil Armstrong
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 81 +++
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 37 +++
include/drm/bridge/dw_hdmi.h | 1 +
3 files changed, 119 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a15fbf71b9d7..fdc29869d75a 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1743,6 +1744,41 @@ static void hdmi_config_vendor_specific_infoframe(struct
dw_hdmi *hdmi,
HDMI_FC_DATAUTO0_VSD_MASK);
}
+static void hdmi_config_drm_infoframe(struct dw_hdmi *hdmi)
+{
+ const struct drm_connector_state *conn_state = hdmi->connector.state;
+ struct hdmi_drm_infoframe frame;
+ u8 buffer[30];
+ ssize_t err;
+ int i;
+
+ if (!hdmi->plat_data->use_drm_infoframe)
+ return;
+
+ hdmi_modb(hdmi, HDMI_FC_PACKET_TX_EN_DRM_DISABLE,
+ HDMI_FC_PACKET_TX_EN_DRM_MASK, HDMI_FC_PACKET_TX_EN);
+
+ err = drm_hdmi_infoframe_set_hdr_metadata(, conn_state);
+ if (err < 0)
+ return;
+
+ err = hdmi_drm_infoframe_pack(, buffer, sizeof(buffer));
+ if (err < 0) {
+ dev_err(hdmi->dev, "Failed to pack drm infoframe: %zd\n", err);
+ return;
+ }
+
+ hdmi_writeb(hdmi, frame.version, HDMI_FC_DRM_HB0);
+ hdmi_writeb(hdmi, frame.length, HDMI_FC_DRM_HB1);
+
+ for (i = 0; i < frame.length; i++)
+ hdmi_writeb(hdmi, buffer[4 + i], HDMI_FC_DRM_PB0 + i);
+
+ hdmi_writeb(hdmi, 1, HDMI_FC_DRM_UP);
+ hdmi_modb(hdmi, HDMI_FC_PACKET_TX_EN_DRM_ENABLE,
+ HDMI_FC_PACKET_TX_EN_DRM_MASK, HDMI_FC_PACKET_TX_EN);
+}
+
static void hdmi_av_composer(struct dw_hdmi *hdmi,
const struct drm_display_mode *mode)
{
@@ -2064,6 +2100,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct
drm_display_mode *mode)
/* HDMI Initialization Step F - Configure AVI InfoFrame */
hdmi_config_AVI(hdmi, mode);
hdmi_config_vendor_specific_infoframe(hdmi, mode);
+ hdmi_config_drm_infoframe(hdmi);
} else {
dev_dbg(hdmi->dev, "%s DVI mode\n", __func__);
}
@@ -2230,6 +2267,45 @@ static int dw_hdmi_connector_get_modes(struct
drm_connector *connector)
return ret;
}
+static bool hdr_metadata_equal(const struct drm_connector_state *old_state,
+ const struct drm_connector_state *new_state)
+{
+ struct drm_property_blob *old_blob = old_state->hdr_output_metadata;
+ struct drm_property_blob *new_blob = new_state->hdr_output_metadata;
+
+ if (!old_blob || !new_blob)
+ return old_blob == new_blob;
+
+ if (old_blob->length != new_blob->length)
+ return false;
+
+ return !memcmp(old_blob->data, new_blob->data, old_blob->length);
+}
+
+static int dw_hdmi_connector_atomic_check(struct drm_connector *connector,
+ struct drm_atomic_state *state)
+{
+ struct drm_connector_state *old_state =
+ drm_atomic_get_old_connector_state(state, connector);
+ struct drm_connector_state *new_state =
+ drm_atomic_get_new_connector_state(state, connector);
+ struct drm_crtc *crtc = new_state->crtc;
+ struct drm_crtc_state *crtc_state;
+
+ if (!crtc)
+ return 0;
+
+ if (!hdr_metadata_equal(old_state, new_state)) {
+ crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state);
+
+ crtc_state->mode_changed = true;
+ }
+
+ return 0;
+}
+
static void dw_hdmi_connector_force(struct drm_connector *connector)
{
struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
@@ -2254,6 +2330,7 @@ static const struct drm_connector_funcs
dw_hdmi_connector_funcs = {
static
[PATCH v2 0/4] drm/bridge: dw-hdmi: Add support for HDR metadata
Add support for HDR metadata using the hdr_output_metadata connector property, configure Dynamic Range and Mastering InfoFrame accordingly. A use_drm_infoframe flag is added to dw_hdmi_plat_data that platform drivers can use to signal when Dynamic Range and Mastering infoframes is supported. This flag is needed because Amlogic GXBB and GXL report same DW-HDMI version, and only GXL support DRM InfoFrame. The first patch add functionality to configure DRM InfoFrame based on the hdr_output_metadata connector property. The remaining patches sets the use_drm_infoframe flag on some SoCs supporting Dynamic Range and Mastering InfoFrame. v2 has been runtime tested on a Rock64 (RK3328) and Rock Pi 4 (RK3399), only build tested for Amlogic and Allwinner. Changes in v2: * address comments from Andrzej Hajda - renamed blob_equal to hdr_metadata_equal - renamed drm_infoframe flag to use_drm_infoframe - use hdmi_drm_infoframe_pack and a loop to write regs - remove hdmi version check in hdmi_config_drm_infoframe Jonas Karlman (4): drm/bridge: dw-hdmi: Add Dynamic Range and Mastering InfoFrame support drm/rockchip: Enable DRM InfoFrame support on RK3328 and RK3399 drm/meson: Enable DRM InfoFrame support on GXL, GXM and G12A drm/sun4i: Enable DRM InfoFrame support on H6 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 81 + drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 37 ++ drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 ++ drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 + drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 + drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 + include/drm/bridge/dw_hdmi.h| 1 + 7 files changed, 129 insertions(+) -- 2.17.1
Re: [PATCH 0/4] drm/bridge: dw-hdmi: Add support for HDR metadata
Hi Neil, On 2019-09-18 10:05, Neil Armstrong wrote: > Hi Jonas, > > On 26/05/2019 23:18, Jonas Karlman wrote: >> Add support for HDR metadata using the hdr_output_metadata connector >> property, >> configure Dynamic Range and Mastering InfoFrame accordingly. >> >> A drm_infoframe flag is added to dw_hdmi_plat_data that platform drivers >> can use to signal when Dynamic Range and Mastering infoframes is supported. >> This flag is needed because Amlogic GXBB and GXL report same DW-HDMI version, >> and only GXL support DRM InfoFrame. >> >> The first patch add functionality to configure DRM InfoFrame based on the >> hdr_output_metadata connector property. >> >> The remaining patches sets the drm_infoframe flag on some SoCs supporting >> Dynamic Range and Mastering InfoFrame. >> >> Note that this was based on top of drm-misc-next and Neil Armstrong's >> "drm/meson: Add support for HDMI2.0 YUV420 4k60" series at [1] > Do you plan to resend this serie ? Thanks for reminding me, I will send a v2 rebased on drm-misc-next as soon as I have some free time (next week). Regards, Jonas > > The "drm/meson: Add support for HDMI2.0 YUV420 4k60" serie is no more > valid with the format negociation work from boris, so you should rebase > on drm-misc-next ! > > Thanks, > > Neil > >> [1] https://patchwork.freedesktop.org/series/58725/#rev2 >> >> Jonas Karlman (4): >> drm/bridge: dw-hdmi: Add Dynamic Range and Mastering InfoFrame support >> drm/rockchip: Enable DRM InfoFrame support on RK3328 and RK3399 >> drm/meson: Enable DRM InfoFrame support on GXL, GXM and G12A >> drm/sun4i: Enable DRM InfoFrame support on H6 >> >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 109 >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 37 +++ >> drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 + >> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 + >> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 + >> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 1 + >> include/drm/bridge/dw_hdmi.h| 1 + >> 7 files changed, 157 insertions(+) >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: bridge/dw_hdmi: add audio sample channel status setting
mi.h >>>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index >>>> 6988f12d89d9..fcff5059db24 100644 >>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h >>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h >>>> @@ -158,6 +158,8 @@ >>>> >>>> #define HDMI_FC_SPDDEVICEINF0x1062 >>>> #define HDMI_FC_AUDSCONF0x1063 >>>> #define HDMI_FC_AUDSSTAT0x1064 >>>> >>>> +#define HDMI_FC_AUDSCHNLS7 0x106e >>>> +#define HDMI_FC_AUDSCHNLS8 0x106f >>>> >>>> #define HDMI_FC_DATACH0FILL 0x1070 >>>> #define HDMI_FC_DATACH1FILL 0x1071 >>>> #define HDMI_FC_DATACH2FILL 0x1072 >>>> >>>> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h >>>> index cf528c289857..4b3e863c4f8a 100644 >>>> --- a/include/drm/bridge/dw_hdmi.h >>>> +++ b/include/drm/bridge/dw_hdmi.h >>>> @@ -156,6 +156,7 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool >>>> hpd, bool rx_sense);> >>>> void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate); >>>> void dw_hdmi_set_channel_count(struct dw_hdmi *hdmi, unsigned int cnt); >>>> >>>> +void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi, u8 >>>> *channel_status); >>>> >>>> void dw_hdmi_set_channel_allocation(struct dw_hdmi *hdmi, unsigned int >>>> ca); >>>> void dw_hdmi_audio_enable(struct dw_hdmi *hdmi); >>>> void dw_hdmi_audio_disable(struct dw_hdmi *hdmi); >>> Looks fine for me: >>> Reviewed-by: Neil Armstrong >>> >>> Jonas ? Jernej ? Russell ? >> Patch itself is fine, I'm just wondering if more information should be copied >> from status array to registers. But I think they are not 1:1 mapping so some >> more work would be needed. Anyway, patch is: > Hi Jernej, > Yes you are right. I was thinking about the same thing. > But there are also some fields in the IEC60958 spec not mapped to the > registers on dw-hdmi. > So I ended up just writing the two registers in the original ykk's > patch, and ignoring "original sampling frequency" like pcm_iec958. > It turns out that audio plays fine on my LG monitor. So I suggest we > can keep this patch as simple as it is, and add more register setting > if we find issue. > Thanks! In my old multi-channel lpcm patch [1] I only wrote sample rate to FC_AUDSCHNLS7. This is much cleaner and simpler, and setting FC_AUDSCHNLS8 does not cause any problems when I tested on ASUS Tinker Board S (RK3288). Reviewed-by: Jonas Karlman [1] https://github.com/Kwiboo/linux-rockchip/commit/4af9ebc567ccf0a0851fa260097021c27aebbb6b Regards, Jonas > >> >> Reviewed-by: Jernej Skrabec >> >> Best regards, >> Jernej >> >>> If it's ok for you I'll apply it. >>> >>> Neil >>>
Re: [PATCH] drm: bridge/dw_hdmi: add audio sample channel status setting
On 2019-09-03 20:08, Jernej Škrabec wrote:
> Hi!
>
> Dne torek, 03. september 2019 ob 20:00:33 CEST je Neil Armstrong napisal(a):
>> Hi,
>>
>> Le 03/09/2019 à 11:53, Neil Armstrong a écrit :
>>> Hi,
>>>
>>> On 03/09/2019 07:51, Cheng-Yi Chiang wrote:
From: Yakir Yang
When transmitting IEC60985 linear PCM audio, we configure the
Audio Sample Channel Status information of all the channel
status bits in the IEC60958 frame.
Refer to 60958-3 page 10 for frequency, original frequency, and
wordlength setting.
This fix the issue that audio does not come out on some monitors
(e.g. LG 22CV241)
Signed-off-by: Yakir Yang
Signed-off-by: Cheng-Yi Chiang
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 59 +++
drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20
2 files changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
bd65d0479683..34d46e25d610 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -582,6 +582,63 @@ static unsigned int hdmi_compute_n(unsigned int
freq, unsigned long pixel_clk)>>
return n;
}
+static void hdmi_set_schnl(struct dw_hdmi *hdmi)
+{
+ u8 aud_schnl_samplerate;
+ u8 aud_schnl_8;
+
+ /* These registers are on RK3288 using version 2.0a. */
+ if (hdmi->version != 0x200a)
+ return;
>>> Are these limited to the 2.0a version *in* RK3288, or 2.0a version on all
>>> SoCs ?
>> After investigations, Amlogic sets these registers on their 2.0a version
>> aswell, and Jernej (added in Cc) reported me Allwinner sets them on their
>> < 2.0a and > 2.0a IPs versions.
>>
>> Can you check on the Rockchip IP versions in RK3399 ?
>>
>> For reference, the HDMI 1.4a IP version allwinner setups is:
>> https://github.com/Allwinner-Homlet/H3-BSP4.4-linux/blob/master/drivers/vide
>> o/fbdev/sunxi/disp2/hdmi/hdmi_bsp_sun8iw7.c#L531-L539 (registers a
>> "scrambled" but a custom bit can reset to the original mapping, 0x1066 ...
>> 0x106f)
> For easier reading, here is similar, but annotated version: http://ix.io/1Ub6
> Check function bsp_hdmi_audio().
>
> Unless there is a special reason, you can just remove that check.
Agree, this check should not be needed, AUDSCHNLS7 used to be configured in my
old
multi-channel patches that have seen lot of testing on Amlogic, Allwinner and
Rockchip SoCs.
>
> Best regards,
> Jernej
>
>> Neil
>>
+
+ switch (hdmi->sample_rate) {
+ case 32000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
+ break;
+ case 44100:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
+ break;
+ case 48000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
+ break;
+ case 88200:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
+ break;
+ case 96000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
+ break;
+ case 176400:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
+ break;
+ case 192000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
+ break;
+ case 768000:
+ aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
+ break;
+ default:
+ dev_warn(hdmi->dev, "Unsupported audio sample rate (%u)\n",
+ hdmi->sample_rate);
+ return;
+ }
+
+ /* set channel status register */
+ hdmi_modb(hdmi, aud_schnl_samplerate, HDMI_FC_AUDSCHNLS7_SMPRATE_MASK,
+HDMI_FC_AUDSCHNLS7);
+
+ /*
+ * Set original frequency to be the same as frequency.
+ * Use one-complement value as stated in IEC60958-3 page 13.
+ */
+ aud_schnl_8 = (~aud_schnl_samplerate) <<
+ HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_OFFSET;
+
+ /* This means word length is 16 bit. Refer to IEC60958-3 page 12. */
+ aud_schnl_8 |= 2 << HDMI_FC_AUDSCHNLS8_WORDLEGNTH_OFFSET;
This looks wrong, user can use 16 and 24 bit wide audio streams.
+
+ hdmi_writeb(hdmi, aud_schnl_8, HDMI_FC_AUDSCHNLS8);
+}
+
static void hdmi_set_clk_regenerator(struct dw_hdmi *hdmi,
unsigned long pixel_clk, unsigned int sample_rate)
{
@@ -620,6 +677,8 @@ static void hdmi_set_clk_regenerator(struct dw_hdmi
*hdmi,>>
hdmi->audio_cts = cts;
hdmi_set_cts_n(hdmi, cts, hdmi->audio_enable ? n : 0);
spin_unlock_irq(>audio_lock);
+
+ hdmi_set_schnl(hdmi);
I will suggest this function is called from or merged with
Re: [PATCH 3/5] drm: dw-hdmi: update CEC phys addr and EDID on HPD event
On 2019-09-02 10:10, Neil Armstrong wrote:
> On 01/09/2019 18:14, Jonas Karlman wrote:
>> Update CEC phys addr and EDID on HPD event, fixes lost CEC phys addr and
>> stale EDID when HDMI cable is unplugged/replugged or AVR is powered on/off.
>>
>> Signed-off-by: Jonas Karlman
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 16 +---
>> 1 file changed, 9 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 91d86ddd6624..0f07be1b5914 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -2189,6 +2189,7 @@ static int dw_hdmi_connector_update_edid(struct
>> drm_connector *connector,
>> static enum drm_connector_status
>> dw_hdmi_connector_detect(struct drm_connector *connector, bool force)
>> {
>> +enum drm_connector_status status;
>> struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
>> connector);
>>
>> @@ -2198,7 +2199,14 @@ dw_hdmi_connector_detect(struct drm_connector
>> *connector, bool force)
>> dw_hdmi_update_phy_mask(hdmi);
>> mutex_unlock(>mutex);
>>
>> -return hdmi->phy.ops->read_hpd(hdmi, hdmi->phy.data);
>> +status = hdmi->phy.ops->read_hpd(hdmi, hdmi->phy.data);
>> +
>> +if (status == connector_status_connected)
>> +dw_hdmi_connector_update_edid(connector, false);
>> +else
>> +cec_notifier_phys_addr_invalidate(hdmi->cec_notifier);
>> +
>> +return status;
>> }
>>
>> static int dw_hdmi_connector_get_modes(struct drm_connector *connector)
>> @@ -2438,12 +2446,6 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>> dw_hdmi_setup_rx_sense(hdmi,
>> phy_stat & HDMI_PHY_HPD,
>> phy_stat & HDMI_PHY_RX_SENSE);
>> -
>> -if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0) {
>> -mutex_lock(>cec_notifier_mutex);
>> -cec_notifier_phys_addr_invalidate(hdmi->cec_notifier);
>> -mutex_unlock(>cec_notifier_mutex);
>> -}
>> }
>>
>> if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
>>
> Won't it possibly trigger twice edid readouts on each HPD event,
> one for CEC and one for modes ? It seems sane but not very efficient to me...
Yes there may be EDID readout twice with this change in case both detect and
get_modes gets called.
Guess we could save the EDID readout in detect and reuse it in get_modes or
similar?
The issue observed is that CEC phys addr never gets updated after an
invalidation (HPD)
until get_modes is called, when TV/AVR triggers an EDID refresh using a 100ms
HPD pulse
or an AVR is powered on/off the CEC phys addr, EDID and ELD never gets
refreshed as
only detect is called and not get_modes.
Regards,
Jonas
>
> Anyway:
> Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
