Received: by 2002:a05:7412:d008:b0:f9:6acb:47ec with SMTP id bd8csp426764rdb; Wed, 20 Dec 2023 00:54:07 -0800 (PST) X-Google-Smtp-Source: AGHT+IERkCQajOBDEtOWNwAh/wNI+OFCYETd6EqayG3MxxKHG0/zxvyb3Y1LD+BylUgnnNG6KOel X-Received: by 2002:a05:620a:1207:b0:77f:b60b:7f53 with SMTP id u7-20020a05620a120700b0077fb60b7f53mr10522393qkj.115.1703062446948; Wed, 20 Dec 2023 00:54:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703062446; cv=none; d=google.com; s=arc-20160816; b=l+ZTgIrN0rUdM+WuOmAlmFxqGMz/Qbw4STXHtzhzEakfuBOtwGBMRnkNl8dGsS0Z+n cybq62op34ppZWzWyb1ImP4geo9y/98gOf+/vsW4NI76drvVu9yMaMLFSAXEg761Li6B k1quCq2L3cnZeHC+FvxKgvzVgcWNgfZptoMAtUBdg7q8rM9oS358bpMcCTKr08/VpCbT 2ccpcqedNTaEIRtVU4H2/ZoIM2QJXRc0+bkmM95eMN3phzJHupPi0fPUGff5N6qU5OxK Rt8HFnlpHQp4HUJUpZYnLgqpFhPfHJFrdQcLZz6Ss/wYLvUNm+uuska0rYBh4KCYvQ3M th+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=yOnlg2Ac6irbaNxerRIhvuqczLvTwnBbxwT/bxGJt/4=; fh=8GHzMFF3stwaHEZbiHcX8NI5cdDyoTqpa+hbgaNbxVs=; b=KRm7yaSyB37jfnb3tKylY5g775t0oJNdKzfmCBOBsdtNoezyre2Uimo//FgQbI9zQM LRsV5zsOyxP052yIFsB06OctFYCtB2Q0yXvUAx+v2QqUOMHtvuzR+YV7zhwDgnG21qYI 6HaXYt2Kir5gBA2x97/w65CofxNl2VflQhluaOL3rJCpnAskVPF1YUMOLMQOVWvR3O8a VCmjM7dvvyXhfAH/U0s1vfgZKHBhTBMocGSRku0R/lQweIEdUO2YbfUHH7ZF7tK8VEh2 45dRzzldZh+U6+DDW3tD3uUqeZTS9oxsu3P9fG8CmF188+pAhhStgjdDBPXQrLLHK70E 2o4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=JuVtfuaO; spf=pass (google.com: domain of linux-kernel+bounces-6606-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-6606-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id rv11-20020a05620a688b00b00778a6cdeefdsi28915199qkn.182.2023.12.20.00.54.06 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Dec 2023 00:54:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-6606-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=JuVtfuaO; spf=pass (google.com: domain of linux-kernel+bounces-6606-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-6606-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id A1C3D1C25866 for ; Wed, 20 Dec 2023 08:54:06 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id F01A81CF8F; Wed, 20 Dec 2023 08:53:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="JuVtfuaO" X-Original-To: linux-kernel@vger.kernel.org Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C6A391DA2A; Wed, 20 Dec 2023 08:53:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=quicinc.com Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.24/8.17.1.24) with ESMTP id 3BK5LJuv030251; Wed, 20 Dec 2023 08:53:50 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h= message-id:date:mime-version:subject:to:cc:references:from :in-reply-to:content-type:content-transfer-encoding; s= qcppdkim1; bh=yOnlg2Ac6irbaNxerRIhvuqczLvTwnBbxwT/bxGJt/4=; b=Ju VtfuaOL/Za3Mllx4o8KL0TcMgQjI5GByNJ9nm3FhDr/cPQhzVsEwI4LdEO6zlZ12 x2SuMc9utW1hEDezsZnpY29P2d2YDwr3by5R/FXBZJZGA5d1qcL3fdqfyR+oDBJI 4Uovz90jWGilpACCQJNGGPB/kv7srBo1FV/vZeXl1CfQBmcQ5owY2LMpb6OYv1uE 4AeAD5Dyoe1POWhLwyooE7A98cYrkABXfrVwpOKhKUvaXcsbBk8RJ/xzRCz/CS7l Rp6n/fO4/jhhkfOjnu4ZVdh3y95nIcpx42r4UZkMBwzZA08aeOUUR7VODXlfehn1 9B61YBexHxqUwQfmrwKg== Received: from nasanppmta01.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3v37vxu0yq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Dec 2023 08:53:50 +0000 (GMT) Received: from nasanex01a.na.qualcomm.com (nasanex01a.na.qualcomm.com [10.52.223.231]) by NASANPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 3BK8rnhs030181 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Dec 2023 08:53:49 GMT Received: from [10.216.20.45] (10.80.80.8) by nasanex01a.na.qualcomm.com (10.52.223.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Wed, 20 Dec 2023 00:53:45 -0800 Message-ID: Date: Wed, 20 Dec 2023 14:23:42 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v2 00/34] Qualcomm video encoder and decoder driver Content-Language: en-US To: Dmitry Baryshkov CC: Dikshita Agarwal , , , , , , , , , , References: <1702899149-21321-1-git-send-email-quic_dikshita@quicinc.com> <9d94317c-5da9-5494-26a2-12007761a1e5@quicinc.com> From: Vikash Garodia In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nasanex01a.na.qualcomm.com (10.52.223.231) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: l6lEi5ZRqvVCKmxdBjGCZ-W2ykIhv9be X-Proofpoint-GUID: l6lEi5ZRqvVCKmxdBjGCZ-W2ykIhv9be X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-12-09_02,2023-12-07_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=393 suspectscore=0 impostorscore=0 lowpriorityscore=0 malwarescore=0 bulkscore=0 phishscore=0 spamscore=0 clxscore=1015 mlxscore=0 adultscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2311290000 definitions=main-2312200061 On 12/20/2023 2:09 PM, Dmitry Baryshkov wrote: > On Wed, 20 Dec 2023 at 10:14, Vikash Garodia wrote: >> >> Hi, >> >> On 12/20/2023 1:07 PM, Dmitry Baryshkov wrote: >>> On Wed, 20 Dec 2023 at 08:32, Vikash Garodia wrote: >>>> >>>> Hi Dmitry, >>>> >>>> On 12/19/2023 12:08 AM, Dmitry Baryshkov wrote: >>>>> On 18/12/2023 13:31, Dikshita Agarwal wrote: >>>>>> This patch series introduces support for Qualcomm new video acceleration >>>>>> hardware architecture, used for video stream decoding/encoding. This driver >>>>>> is based on new communication protocol between video hardware and application >>>>>> processor. >>>>> >>>>> This doesn't answer one important point, you have been asked for v1. What is the >>>>> actual change point between Venus and Iris? What has been changed so much that >>>>> it demands a separate driver. This is the main question for the cover letter, >>>>> which has not been answered so far. >>>>> >>>>> From what I see from you bindings, the hardware is pretty close to what we see >>>>> in the latest venus generations. I asssme that there was a change in the vcodec >>>>> inteface to the firmware and other similar changes. Could you please point out, >>>>> which parts of Venus driver do no longer work or are not applicable for sm8550 >>>> >>>> The motivation behind having a separate IRIS driver was discussed earlier in [1] >>>> In the same discussion, it was ellaborated on how the impact would be with >>>> change in the new firmware interface and other video layers in the driver. I can >>>> add this in cover letter in the next revision. >>> >>> Ok. So the changes cover the HFI interface. Is that correct? >> Change wise, yes. >> >>>> We see some duplication of code and to handle the same, the series brings in a >>>> common code reusability between iris and venus. Aligning the common peices of >>>> venus and iris will be a work in progress, once we land the base driver for iris. >>> >>> This is not how it usually works. Especially not with the patches you >>> have posted. >>> >>> I have the following suggestion how this story can continue: >>> You can _start_ by reworking venus driver, separating the HFI / >>> firmware / etc interface to an internal interface in the driver. Then >>> implement Iris as a plug in for that interface. I might be mistaken >>> here, but I think this is the way how this can be beneficial for both >>> the video en/decoding on both old and new platforms. >> >> HFI/firmware interface is already confined to HFI layer in the existing venus >> driver. We explained in the previous discussion [1], on how the HFI change >> impacts the other layers by taking example of a DRC usecase. Please have a look >> considering the usecase and the impact it brings to other layers in the driver. > > I have looked at it. And I still see huge change in the interface > side, but it doesn't tell me about the hardware changes. I hope you noticed how the common layers like decoder, response, state layers are impacted in handling one of usecase. Now add that to all the different scenarios like seek, drain, DRC during seek, DRC during drain, etc. > Have you evaluated the other opportunity? > > To have a common platform interface and firmware-specific backend? > > You have already done a part of it, but from a different perspective. > You have tried to move common code out of the driver. Instead we are > asking you to do a different thing. Move non-common code within the > driver. Then add your code on top of that. For common platform - yes, we are bringing in common stuff like PIL. Other than that, abstraction to firmware interface is not that confined to one layer. It spreads over decoder/encoder/common layers. Now when majority of the layers/code is different, we planned to make it in parallel to venus and have a common layer having common things to both iris and venus. >> >> [1] https://lore.kernel.org/lkml/8c97d866-1cab-0106-4ab3-3ca070945ef7@quicinc.com/ >>> Short rationale: >>> The venus driver has a history of supported platforms. There is >>> already some kind of buffer management in place. Both developers and >>> testers have spent their effort on finding issues there. Sending new >>> driver means that we have to spend the same amount of efforts on this. >>> Moreover, even from the porter point of view. You are creating new >>> bindings for the new hardware. Which do not follow the >>> venus-common.yaml. And they do not follow the defined bindings for the >>> recent venus platforms. Which means that as a developer I have to care >>> about two different ways to describe nearly the same hardware.>> Again qualcomm video team does not have a plan to support sm8550/x1e80100 on >>>> venus as the changes are too interleaved to absorb in venus driver. And there is >>>> significant interest in community to start validating video driver on sm8550 or >>>> x1e80100. >>>> >>>> [1] https://lore.kernel.org/lkml/8c97d866-1cab-0106-4ab3-3ca070945ef7@quicinc.com/ >>>> >>>> Regards, >>>> Vikash >>> >>> >>> > > >