On 1/25/21 5:01 PM, Hans Verkuil wrote:
> 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.
>
I sent a patch for that. Thanks for raising this issue.
--
regards,
Stan
