Re: [RFC WIP PATCH] venus: add qcom,no-low-power property

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 26/02/2024 15:30, Vikash Garodia wrote:

> On 2/26/2024 6:39 PM, Marc Gonzalez wrote:
>
>> On 23/02/2024 14:48, Vikash Garodia wrote:
>>
>>> On 2/20/2024 8:15 PM, Marc Gonzalez wrote:
>>>
>>>> On 20/02/2024 14:53, Vikash Garodia wrote:
>>>>
>>>>> msm8998 supports configuring the VCodec (venus core0) GDSC in HW power control
>>>>> mode. Could you please check and confirm if the driver is configuring only the
>>>>> VCodec GDSC and not the venus GDSC. Look for the attribute
>>>>> "qcom,support-hw-trigger" in vendor dt file.
>>>>
>>>> [ Vendor DTS for easy reference: ]
>>>> [ https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/arch/arm/boot/dts/qcom/msm8998.dtsi ]
>>>>
>>>> In the queue, we have a patch enabling the Venus Decoder (VDEC) in mainline.
>>>> (It is using the previously proposed "qcom,no-low-power" mechanism, but that
>>>> might not be necessary, if I understand correctly?)
>>>>
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi
>>>> index 2793cc22d381a..5084191be1446 100644
>>>> --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
>>>> @@ -3000,6 +3000,56 @@ mdss_dsi1_phy: phy@c996400 {
>>>>  			};
>>>>  		};
>>>>  
>>>> +		venus: video-codec@cc00000 {
>>>> +			compatible = "qcom,msm8998-venus";
>>>> +			reg = <0x0cc00000 0xff000>;
>>>> +			interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
>>>> +			power-domains = <&mmcc VIDEO_TOP_GDSC>;
>>>> +			clocks = <&mmcc VIDEO_CORE_CLK>,
>>>> +				 <&mmcc VIDEO_AHB_CLK>,
>>>> +				 <&mmcc VIDEO_AXI_CLK>,
>>>> +				 <&mmcc VIDEO_MAXI_CLK>;
>>>> +			clock-names = "core", "iface", "bus", "mbus";
>>>> +			iommus = <&mmss_smmu 0x400>,
>>>> +				 <&mmss_smmu 0x401>,
>>>> +				 <&mmss_smmu 0x40a>,
>>>> +				 <&mmss_smmu 0x407>,
>>>> +				 <&mmss_smmu 0x40e>,
>>>> +				 <&mmss_smmu 0x40f>,
>>>> +				 <&mmss_smmu 0x408>,
>>>> +				 <&mmss_smmu 0x409>,
>>>> +				 <&mmss_smmu 0x40b>,
>>>> +				 <&mmss_smmu 0x40c>,
>>>> +				 <&mmss_smmu 0x40d>,
>>>> +				 <&mmss_smmu 0x410>,
>>>> +				 <&mmss_smmu 0x411>,
>>>> +				 <&mmss_smmu 0x421>,
>>>> +				 <&mmss_smmu 0x428>,
>>>> +				 <&mmss_smmu 0x429>,
>>>> +				 <&mmss_smmu 0x42b>,
>>>> +				 <&mmss_smmu 0x42c>,
>>>> +				 <&mmss_smmu 0x42d>,
>>>> +				 <&mmss_smmu 0x411>,
>>>> +				 <&mmss_smmu 0x431>;
>>>> +			memory-region = <&venus_mem>;
>>>> +			status = "disabled";
>>>> +			qcom,no-low-power; /*** WORK AROUND LOW-POWER ISSUE ***/
>>>> +
>>>> +			video-decoder {
>>>> +				compatible = "venus-decoder";
>>>> +				clocks = <&mmcc VIDEO_SUBCORE0_CLK>;
>>>> +				clock-names = "core";
>>>> +				power-domains = <&mmcc VIDEO_SUBCORE0_GDSC>;
>>>> +			};
>>>> +
>>>> +			video-encoder {
>>>> +				compatible = "venus-encoder";
>>>> +				clocks = <&mmcc VIDEO_SUBCORE1_CLK>;
>>>> +				clock-names = "core";
>>>> +				power-domains = <&mmcc VIDEO_SUBCORE1_GDSC>;
>>>> +			};
>>>> +		};
>>>> +
>>>>  		mmss_smmu: iommu@cd00000 {
>>>>  			compatible = "qcom,msm8998-smmu-v2", "qcom,smmu-v2";
>>>>  			reg = <0x0cd00000 0x40000>;
>>>> diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
>>>> index a712dd4f02a5b..ad1705e510312 100644
>>>> --- a/drivers/media/platform/qcom/venus/core.c
>>>> +++ b/drivers/media/platform/qcom/venus/core.c
>>>> @@ -585,6 +585,43 @@ static const struct venus_resources msm8996_res = {
>>>>  	.fwname = "qcom/venus-4.2/venus.mbn",
>>>>  };
>>>>  
>>>> +static const struct freq_tbl msm8998_freq_table[] = {
>>>> +	{ 1944000, 520000000 },	/* 4k UHD @ 60 (decode only) */
>>>> +	{  972000, 520000000 },	/* 4k UHD @ 30 */
>>>> +	{  489600, 346666667 },	/* 1080p @ 60 */
>>>> +	{  244800, 150000000 },	/* 1080p @ 30 */
>>>> +	{  108000,  75000000 },	/* 720p @ 30 */
>>>> +};
>>>> +
>>>> +static const struct reg_val msm8998_reg_preset[] = {
>>>> +    { 0x80124, 0x00000003 },
>>>> +    { 0x80550, 0x01111111 },
>>>> +    { 0x80560, 0x01111111 },
>>>> +    { 0x80568, 0x01111111 },
>>>> +    { 0x80570, 0x01111111 },
>>>> +    { 0x80580, 0x01111111 },
>>>> +    { 0xe2010, 0x00000000 },
>>>> +};
>>>> +
>>>> +static const struct venus_resources msm8998_res = {
>>>> +	.freq_tbl = msm8998_freq_table,
>>>> +	.freq_tbl_size = ARRAY_SIZE(msm8998_freq_table),
>>>> +	.reg_tbl = msm8998_reg_preset,
>>>> +	.reg_tbl_size = ARRAY_SIZE(msm8998_reg_preset),
>>>> +	.clks = {"core", "iface", "bus", "mbus"},
>>>> +	.clks_num = 4,
>>>> +	.vcodec0_clks = { "core" },
>>>> +	.vcodec1_clks = { "core" },
>>>> +	.vcodec_clks_num = 1,
>>>> +	.max_load = 2563200,
>>>> +	.hfi_version = HFI_VERSION_3XX,
>>>> +	.vmem_id = VIDC_RESOURCE_NONE,
>>>> +	.vmem_size = 0,
>>>> +	.vmem_addr = 0,
>>>> +	.dma_mask = 0xddc00000 - 1,
>>>> +	.fwname = "qcom/venus-4.4/venus.mbn",
>>>> +};
>>>> +
>>>>  static const struct freq_tbl sdm660_freq_table[] = {
>>>>  	{ 979200, 518400000 },
>>>>  	{ 489600, 441600000 },
>>>> @@ -891,6 +928,7 @@ static const struct venus_resources sc7280_res = {
>>>>  static const struct of_device_id venus_dt_match[] = {
>>>>  	{ .compatible = "qcom,msm8916-venus", .data = &msm8916_res, },
>>>>  	{ .compatible = "qcom,msm8996-venus", .data = &msm8996_res, },
>>>> +	{ .compatible = "qcom,msm8998-venus", .data = &msm8998_res, },
>>>>  	{ .compatible = "qcom,sdm660-venus", .data = &sdm660_res, },
>>>>  	{ .compatible = "qcom,sdm845-venus", .data = &sdm845_res, },
>>>>  	{ .compatible = "qcom,sdm845-venus-v2", .data = &sdm845_res_v2, },
>>>>
>>>>
>>>>
>>>> @Vikash, are you saying that perhaps the DTS for video-codec@cc00000
>>>> needs to be written slightly differently?
>>>
>>>
>>> Certainly yes. For ex, in the clock list, i do not see the core clocks listed
>>> i.e clk_mmss_video_subcore0_clk and clk_mmss_video_subcore1_clk. You can refer
>>> the downstream video DT node [1] and then align it as per venus driver
>>> [1]
>>> https://git.codelinaro.org/clo/la/kernel/msm-4.4/-/blob/caf_migration/kernel.lnx.4.4.r38-rel/arch/arm/boot/dts/qcom/msm8998-vidc.dtsi
>>
>> If I understand correctly (which is far from certain),
>> we should base the "qcom,msm8998-venus" DT node on
>> "qcom,sdm845-venus-v2" rather than "qcom,msm8996-venus" ?
>
> That's correct, but that's just another way to do the configuration. With the
> existing node, is video decode as well as encode working ?

Errr, there is currently no existing node for msm8998-venus?

With the proposed node above (based on msm8996-venus)
AND the proposed work-around disabling low-power mode,
decoding works correctly.

Encoding does not work, but it has never been used/tested on our device.

[h264_v4l2m2m @ 0xaaaaec9c44a0] Using device /dev/video1
[h264_v4l2m2m @ 0xaaaaec9c44a0] driver 'qcom-venus' on card 'Qualcomm Venus video encoder' in mplane mode
[h264_v4l2m2m @ 0xaaaaec9c44a0] requesting formats: output=NV12/yuv420p capture=H264/none
[h264_v4l2m2m @ 0xaaaaec9c44a0] output VIDIOC_REQBUFS failed: Invalid argument
[h264_v4l2m2m @ 0xaaaaec9c44a0] no v4l2 output context's buffers
[h264_v4l2m2m @ 0xaaaaec9c44a0] can't configure encoder
[vost#0:0/h264_v4l2m2m @ 0xaaaaec9c4160] Error while opening encoder - maybe incorrect parameters such as bit_rate, rate, width or height.

Regards





[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux