On 25/01/2021 15:51, AngeloGioacchino Del Regno wrote:
> Il 25/01/21 11:40, Hans Verkuil ha scritto:
>> On 18/01/2021 18:45, AngeloGioacchino Del Regno wrote:
>>> Il 18/01/21 18:21, Stanimir Varbanov ha scritto:
>>>> Hi Angelo,
>>>>
>>>> Thanks for the patch!
>>>>
>>>> On 1/15/21 8:52 PM, AngeloGioacchino Del Regno wrote:
>>>>> Add the SDM660 DT compatible and its resource structure, also
>>>>> including support for the Venus pmdomains, in order to support
>>>>> the Venus block in SDM630, SDM636, SDM660 and SDA variants.
>>>>>
>>>>> This SoC features Venus 4.4 (HFI3XX), with one vcodec used for
>>>>> both encoding and decoding, switched on through two GDSCs.
>>>>> The core clock for this Venus chip is powered by the RPM VDD_CX
>>>>> power domain.
>>>>>
>>>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@xxxxxxxxxxxxxx>
>>>>> ---
>>>>> drivers/media/platform/qcom/venus/core.c | 66 ++++++++++++++++++++++++
>>>>> 1 file changed, 66 insertions(+)
>>>>>
>>>>> diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c
>>>>> index bdd293faaad0..83ca86a63241 100644
>>>>> --- a/drivers/media/platform/qcom/venus/core.c
>>>>> +++ b/drivers/media/platform/qcom/venus/core.c
>>>>> @@ -565,6 +565,71 @@ static const struct venus_resources sdm845_res_v2 = {
>>>>> .fwname = "qcom/venus-5.2/venus.mdt",
>>>>> };
>>>>>
>>>>> +static const struct freq_tbl sdm660_freq_table[] = {
>>>>> + { 0, 518400000 },
>>>>> + { 0, 441600000 },
>>>>> + { 0, 404000000 },
>>>>> + { 0, 320000000 },
>>>>> + { 0, 269330000 },
>>>>> + { 0, 133330000 },
>>>>> +};
>>>>> +
>>>>> +static const struct reg_val sdm660_reg_preset[] = {
>>>>> + { 0x80010, 0x001f001f },
>>>>> + { 0x80018, 0x00000156 },
>>>>> + { 0x8001C, 0x00000156 },
>>>>> +};
>>>>> +
>>>>> +static const struct bw_tbl sdm660_bw_table_enc[] = {
>>>>> + { 979200, 1044000, 0, 2446336, 0 }, /* 4k UHD @ 30 */
>>>>> + { 864000, 887000, 0, 2108416, 0 }, /* 720p @ 240 */
>>>>> + { 489600, 666000, 0, 1207296, 0 }, /* 1080p @ 60 */
>>>>> + { 432000, 578000, 0, 1058816, 0 }, /* 720p @ 120 */
>>>>> + { 244800, 346000, 0, 616448, 0 }, /* 1080p @ 30 */
>>>>> + { 216000, 293000, 0, 534528, 0 }, /* 720p @ 60 */
>>>>> + { 108000, 151000, 0, 271360, 0 }, /* 720p @ 30 */
>>>>> +};
>>>>> +
>>>>> +static const struct bw_tbl sdm660_bw_table_dec[] = {
>>>>> + { 979200, 2365000, 0, 1892000, 0 }, /* 4k UHD @ 30 */
>>>>> + { 864000, 1978000, 0, 1554000, 0 }, /* 720p @ 240 */
>>>>> + { 489600, 1133000, 0, 895000, 0 }, /* 1080p @ 60 */
>>>>> + { 432000, 994000, 0, 781000, 0 }, /* 720p @ 120 */
>>>>> + { 244800, 580000, 0, 460000, 0 }, /* 1080p @ 30 */
>>>>> + { 216000, 501000, 0, 301000, 0 }, /* 720p @ 60 */
>>>>> + { 108000, 255000, 0, 202000, 0 }, /* 720p @ 30 */
>>>>> +};
>>>>> +
>>>>> +static const struct venus_resources sdm660_res = {
>>>>> + .freq_tbl = sdm660_freq_table,
>>>>> + .freq_tbl_size = ARRAY_SIZE(sdm660_freq_table),
>>>>> + .reg_tbl = sdm660_reg_preset,
>>>>> + .reg_tbl_size = ARRAY_SIZE(sdm660_reg_preset),
>>>>> + .bw_tbl_enc = sdm660_bw_table_enc,
>>>>> + .bw_tbl_enc_size = ARRAY_SIZE(sdm660_bw_table_enc),
>>>>> + .bw_tbl_dec = sdm660_bw_table_dec,
>>>>> + .bw_tbl_dec_size = ARRAY_SIZE(sdm660_bw_table_dec),
>>>>> + .clks = {"core", "iface", "bus_throttle", "bus" },
>>>>> + .clks_num = 4,
>>>>> + .vcodec0_clks = { "vcodec0_core" },
>>>>> + .vcodec_clks_num = 1,
>>>>> + .vcodec_pmdomains = { "venus", "vcodec0" },
>>>>> + .vcodec_pmdomains_num = 2,
>>>>> + .opp_pmdomain = (const char *[]) { "cx", NULL },
>>>>> + .vcodec_num = 1,
>>>>> + .max_load = 1036800,
>>>>> + .hfi_version = HFI_VERSION_3XX,
>>>>> + .vmem_id = VIDC_RESOURCE_NONE,
>>>>> + .vmem_size = 0,
>>>>> + .vmem_addr = 0,
>>>>> + .cp_start = 0,
>>>>> + .cp_size = 0x79000000,
>>>>> + .cp_nonpixel_start = 0x1000000,
>>>>> + .cp_nonpixel_size = 0x28000000,
>>>>> + .dma_mask = 0xd9000000 - 1,
>>>>> + .fwname = "qcom/venus-4.4/venus.mdt",
>>>>
>>>> Did you try venus-4.2 firmware from linux-firmware tree [1] ?
>>>>
>>>
>>> No I haven't.. and I can't... my Sony devices (but I think that this is
>>> a practice of all OEMs/ODMs) are using a Sony signed venus firmware, so
>>> I am totally limited to use the firmware that comes with the device.
>>>
>>> Besides that, the version is still different so, even if I had any
>>> possibility to try that, I don't think that it would work anyway...
>
> Hello!
>
>>
>> I'm a bit confused. "qcom/venus-4.4/venus.mdt" is the Sony signed FW?
>>
>
> In my case it is, but this follows the generic firmware path as was done
> for all the other Venus firmwares, so my code is not pointing at Sony
> specific things, but just generic ones.
>
> Every Qualcomm-powered consumer device (smartphones, tablets etc) have
> got a double sigcheck: one for qcom, one for OEM specific and most of
> the times the TZ is configured to accept only firmwares that also have
> the OEM signature.
>
> This is not true for all the firmwares - for example, Adreno has this
> mechanism only for the ZAP part - but unfortunately I'm not aware of
> any consumer device accepting a Venus firmware with the "generic"
> Qualcomm signature only (so - without the OEM signature).
>
> Short answer:
> 1. qcom/venus-4.4/venus.mdt is a generic firmware for Venus
So can this FW be made available in the linux-firmware repo? Stanimir?
> 2. 99% of the people needs a different firmware for signature issues
>
>
>> This patch can't be merged unless there is a corresponding firmware available
>> in linux-firmware. Is the current 4.2 firmware in linux-firmware signed by
>> Qualcomm? Can they provided 4.4 firmware as well?
>>
>
> If there is such issue, then maybe we should do "something" about it: I
> would then propose to remove all references to fwname and just get this
> done in DT, where every qcom board already specifies its own path for
> its own firmware.
>
> In any case, the issue that you're raising here has been raised multiple
> times on LKML, I don't precisely remember, but I recall seeing this for
> something like 4 years (or even more) being raised every now and then...
>
>> I have no idea how this works for the venus driver, but I hope Stanimir does.
>>
>
> As far as I've understood, this driver just uses the firmware which
> path is hardcoded in fwname, even though at this point I would like
> to get an opinion from Stanimir.
>
> Would you be ok if we start parsing firmware-name from DT for this
> driver? The flow would be something like:
>
> Is firmware-name DT property present?
> Yes -> Use FW path from firmware-name property
> No -> Use the FW path from the fwname field of struct
> venus_resources
>
> This is a common flow in at least freedreno and remoteproc (modem).
I would have no problem with this, but it is up to Stanimir to decide.
Regards,
Hans
>
> -- Angelo
>
>> Regards,
>>
>> Hans
>>
>>>
>>>>> +};
>>>>> +
>>>>> static const struct freq_tbl sc7180_freq_table[] = {
>>>>> { 0, 500000000 },
>>>>> { 0, 434000000 },
>>>>> @@ -613,6 +678,7 @@ static const struct venus_resources sc7180_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,sdm660-venus", .data = &sdm660_res, },
>>>>> { .compatible = "qcom,sdm845-venus", .data = &sdm845_res, },
>>>>> { .compatible = "qcom,sdm845-venus-v2", .data = &sdm845_res_v2, },
>>>>> { .compatible = "qcom,sc7180-venus", .data = &sc7180_res, },
>>>>>
>>>>
>>>> Reviewed-by: Stanimir Varbanov <stanimir.varbanov@xxxxxxxxxx>
>>>>
>>>
>>> Thank you!
>>> - Angelo
>>>
>>
>
