From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DA87C6FD1D for ; Thu, 30 Mar 2023 11:15:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231571AbjC3LPh (ORCPT ); Thu, 30 Mar 2023 07:15:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231565AbjC3LPd (ORCPT ); Thu, 30 Mar 2023 07:15:33 -0400 Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D577116 for ; Thu, 30 Mar 2023 04:15:32 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id q16so24014871lfe.10 for ; Thu, 30 Mar 2023 04:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680174930; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=WwvbvPXxPR5P20tad4wCr/Qfgy5335Pq0zA9tfCxpKA=; b=bkwQUmdxhpi3uUU2Y7ja2F5fdp36Y7SeDu1dPbTtby9zQ0qSkBTwFD07jJpv9NZjHz gGe0IGcRJlBporhV+Z7MFmrhZuOatgn533LRXq1l17e1mdaqYcyFBZoVGJjuGsy7rbVp tjuzhLD9OEkwDlvxoNwVymXmdbSdwzx/CSQhQ008qPqgdP9TnEBkedk10kh1W93eiHfE 7V88RcMkuCrmsHr8gmvuXHl3h8RitZuTb94MVmtpey0Vg1CSVXPcEhrZuVjsYz3YpTR8 ooQfexdx/5Gr7jEdNzj4/cAATF2XbZg2YNKhYDll85BhcrF2tc/EUz+De3pUJVABxFBr uWGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680174930; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WwvbvPXxPR5P20tad4wCr/Qfgy5335Pq0zA9tfCxpKA=; b=oYhI18nej8EwwP790ODS0QzybcicG1oz9+pBVJzsLqIB/zfVCBLvvbtxTWmCu6yBKp xFD2TYSf14fR04kaKZPlONGMeRSjqvB1jDWnM37KYbkGDtubuxT8yk8cZpBa7atAOgLD 8ONBt6VV9Zj6fywptYxMK75qjlnPsnP9beRrNfSE0vSAQGzLHX7xNX1LwxXE1TUSQQYN +L4bApsaNpbhP0TgX24FuW+oHMmbMANcDDa4Oh8f5mzqUbL/SCH8hm48umN1TjAhkFsO LSKa5ms0l11yHgjrhmNlhBe3notmhcFnI+IeLZeS/kdb3pO04bpnquRFyRzYV15aVU3+ Q1Tg== X-Gm-Message-State: AAQBX9fKMvFLR41Z5cPiVKvxfTXR4j6Fnato/WvVWz/Xn+/ck5Nec3ec edJVf9Ap7MzyyCBrjocoYBTnpw== X-Google-Smtp-Source: AKy350bTOJ6lsUvwVh84YWuxK0Emo+2xVWmF9qOLHP6Qocwsnd7NzOt+vZ6c9SDIhu9IYzkj9Q6Iiw== X-Received: by 2002:ac2:482d:0:b0:4dd:9f86:859d with SMTP id 13-20020ac2482d000000b004dd9f86859dmr6189857lft.13.1680174930341; Thu, 30 Mar 2023 04:15:30 -0700 (PDT) Received: from [192.168.1.101] (abxj225.neoplus.adsl.tpnet.pl. [83.9.3.225]) by smtp.gmail.com with ESMTPSA id y28-20020ac255bc000000b004e846990cf0sm5864650lfg.11.2023.03.30.04.15.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Mar 2023 04:15:29 -0700 (PDT) Message-ID: <58b9c5bb-e70c-67b3-e0d9-9aaaa4d4caf5@linaro.org> Date: Thu, 30 Mar 2023 13:15:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH 02/18] media: venus: Introduce VPU version distinction Content-Language: en-US To: Vikash Garodia , Dikshita Agarwal , Stanimir Varbanov , Andy Gross , Bjorn Andersson , Mauro Carvalho Chehab , Dikshita Agarwal , Bryan O'Donoghue , Dikshita Agarwal , Mansur Alisha Shaik , Jonathan Marek Cc: Mauro Carvalho Chehab , Stanimir Varbanov , linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Vikash Garodia References: <20230228-topic-venus-v1-0-58c2c88384e9@linaro.org> <20230228-topic-venus-v1-2-58c2c88384e9@linaro.org> <0e85caec-f6ec-fbd4-1815-8df9769bffcf@quicinc.com> From: Konrad Dybcio In-Reply-To: <0e85caec-f6ec-fbd4-1815-8df9769bffcf@quicinc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 30.03.2023 13:02, Vikash Garodia wrote: > On 3/2/2023 5:07 PM, Konrad Dybcio wrote: >> >> On 2.03.2023 08:12, Dikshita Agarwal wrote: >>> On 2/28/2023 8:54 PM, Konrad Dybcio wrote: >>>> The Video Processing Unit hardware version is the differentiator, >>>> based on which we should decide which code paths to take in hw >>>> init. Up until now, we've relied on HFI versions, but that was >>>> just a happy accident between recent SoCs. Add a field in the >>>> res struct and add correlated definitions that will be used to >>>> account for the aforementioned differences. >>>> >>>> Signed-off-by: Konrad Dybcio >>>> --- >>>>    drivers/media/platform/qcom/venus/core.h | 15 +++++++++++++++ >>>>    1 file changed, 15 insertions(+) >>>> >>>> diff --git a/drivers/media/platform/qcom/venus/core.h b/drivers/media/platform/qcom/venus/core.h >>>> index 32551c2602a9..4b785205c5b1 100644 >>>> --- a/drivers/media/platform/qcom/venus/core.h >>>> +++ b/drivers/media/platform/qcom/venus/core.h >>>> @@ -48,6 +48,14 @@ struct bw_tbl { >>>>        u32 peak_10bit; >>>>    }; >>>>    +enum vpu_version { >>>> +    VPU_VERSION_AR50, /* VPU4 */ >>>> +    VPU_VERSION_AR50_LITE, /* VPU4.4 */ >>>> +    VPU_VERSION_IRIS1, /* VPU5 */ > > There was Venus3X, followed by a different generation of video hardware. Driver just extended the versions for next generation incrementally. > > Existing versions in driver are not the VPU versions, so we can drop them from comments. Ack! > >>>> +    VPU_VERSION_IRIS2, >>>> +    VPU_VERSION_IRIS2_1, >>>> +}; >>>> + >>>>    struct venus_resources { >>>>        u64 dma_mask; >>>>        const struct freq_tbl *freq_tbl; >>>> @@ -71,6 +79,7 @@ struct venus_resources { >>>>        const char * const resets[VIDC_RESETS_NUM_MAX]; >>>>        unsigned int resets_num; >>>>        enum hfi_version hfi_version; >>>> +    enum vpu_version vpu_version; >>>>        u8 num_vpp_pipes; >>>>        u32 max_load; >>>>        unsigned int vmem_id; >>>> @@ -473,6 +482,12 @@ struct venus_inst { >>>>    #define IS_V4(core)    ((core)->res->hfi_version == HFI_VERSION_4XX) >>>>    #define IS_V6(core)    ((core)->res->hfi_version == HFI_VERSION_6XX) >>>>    +#define IS_AR50(core)        ((core)->res->vpu_version == VPU_VERSION_AR50) >>>> +#define IS_AR50_LITE(core)    ((core)->res->vpu_version == VPU_VERSION_AR50_LITE) >>>> +#define IS_IRIS1(core)        ((core)->res->vpu_version == VPU_VERSION_IRIS1) >>>> +#define IS_IRIS2(core)        ((core)->res->vpu_version == VPU_VERSION_IRIS2) >>>> +#define IS_IRIS2_1(core)    ((core)->res->vpu_version == VPU_VERSION_IRIS2_1) >>>> + >>>>    #define ctrl_to_inst(ctrl)    \ >>>>        container_of((ctrl)->handler, struct venus_inst, ctrl_handler) >>>>    >>> Adding VPU version check seems a good idea to me. Can we remove HFI Version checks now? >> If all implementations using VPU x.y *always* use the >> same HFI generation for given x, y, we could. > > HFIs generally does not change, so we can be sure that they would always use the same HFI. > > We might add a new interface (HFI) for a feature requirement, but always support the existing ones. Okay, will do. Thanks! Konrad > >> >> That said, I think keeping it as-is would be convenient >> from the maintainability standpoint if nothing else.. For >> example functions that only appear in ancient msm-3.10 >> releases can be easily guarded with IS_V1 or what have you >> without having to dig up all n VPU revisions. >> >> Konrad