From mboxrd@z Thu Jan 1 00:00:00 1970 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 A84302DF144 for ; Fri, 13 Mar 2026 09:25:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773393952; cv=none; b=R+USQ6XTKqvV1PYFlpY/ZEyxK3gcCFLEVKOamO1N9I8ji7wUJOkRsw79ToeZuGTQrzyHVai3GVdjRqzLW/FKLdIYF8rGmxse7Ykla8Ql728kwHfEoUblEB2UzFyTR+aoIY+0EC11v9YimBYHa0cpRIY1YEqOg9ItTaKhVeuYQ4k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773393952; c=relaxed/simple; bh=WslZKkKjX2fmc6FtOrAk0+WHsAO7sI5wt/oehGYntps=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pU5tjoGB+QHkW/j/k3X41l9RgviGDA173RRoqAvQd5tTJg0sRJwRa31Q1bMsSPPDn4Y2bDmGVxg6qgQb1eyHpzgNu+pPexTFvmeMMTcB7YKAsft2B+pmKUIq4aqObD0UCS6iBDMsjjW/qH2OPf2P0thzFH3gM2/Qha1mlnalfuY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=btpg47S4; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=AL/n5HR1; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="btpg47S4"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="AL/n5HR1" Received: from pps.filterd (m0279864.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 62D5tbnM1176353 for ; Fri, 13 Mar 2026 09:25:50 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= cjq4klxHx55B+VrcBTReIOP0ofQpmNCVPNUdh1XeIWc=; b=btpg47S4VA0xSBvA fNYqoM1Aw2UyZkGPoMNd22fB5nkg2y2/j4jv3bnSdaj/01aG1v+7s6ZrIWYQUTMw D3wm3/ElQ4oDpXuNURy+SrGwEChVdZ79Aa2HjkGDBhDQgFOThDr4rCkqMiPCb6kB OJap9+WR9pAvx1a/ujYDwS9xSLmIh3wTuKAI/cGxYEQn6JIc84R7Tzs9UNK3I5k3 K1ljtGXzuNM6vwzQFATXDkbv6h2uqtR4d8dRmdeKjtA9hwoWD/SH9obY2nXYK7i/ KPy+vKZ1dFwEJMe+WLUgxHBk1DCRLRhcGU88uZc/Tp1gt2BwJs0MSBr2GL2sGTfz WUGVEg== Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4cumvqcv2y-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 13 Mar 2026 09:25:49 +0000 (GMT) Received: by mail-pf1-f197.google.com with SMTP id d2e1a72fcca58-829942cf9deso1585791b3a.0 for ; Fri, 13 Mar 2026 02:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1773393949; x=1773998749; darn=vger.kernel.org; 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=cjq4klxHx55B+VrcBTReIOP0ofQpmNCVPNUdh1XeIWc=; b=AL/n5HR1iMn6sImsZMXLSxqmqCjJlqX3OautQ4NahXuY9jN8GzRDS3ngiXIKTgqKEO t+ZkXhY0vLsCz67JfoKvXGVKOgDZYh/x2kPVpd4scl/Bn82iI6nR+VrTdoMGEJ6KnO5R ABIU0nGqfXYfoNX+sT2pv8j71ndoBe31xZRogeKYx/Z9wPD2J5lZtc8h8oAREdH52uLW RaQ5HCGOhoApCUmzpytOMlkxNNdLiGqmzirnfOZ7wRn7JEVgGO3F6ZcueB6wR5UWoi06 PPz5JhDEvWJH7nHXyEkvUHUyLPFklPxXPd9nMaJCgj1HSIArC4w8wEB/v6sGW3kY69aV gYWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773393949; x=1773998749; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cjq4klxHx55B+VrcBTReIOP0ofQpmNCVPNUdh1XeIWc=; b=kj0sKSQbXUXBiYFnhzARqXBVJHSVyK/lnzzAExN6lbHVMGiJVPVbUfgWI6ix66qh1B 7MEw8Ku4Cl/EmBMxi38Gk9So95H3hmvwEMwcQKY+wdOaqTfRWrtslO6695QphedgnGar k0kG3Y2sW398P6Mo+IPZRS9QJeJFWdMG2MqnvyhoXRmP3V5BFW9DSIvAVV7VpO4ci9O1 nwN4e0AZWMRF6oYSEeilAfruNIk5Dd8WvzfLXi1jyD+/9GzANfIEmHVVoE+Q0CHmz8bW vlqoQoWRChxyku7gm089WbQnXZPwyXQ6jka0VE4n/KGj7hxK7X6cql5uuXQ4YHZZ96e7 FW+Q== X-Forwarded-Encrypted: i=1; AJvYcCV6jANv2daro0YFJ8cwYK+TDDPJ3cF0tYxFhoRZEFMQLtNNeSNVWsCp6TKkyY/u4vERa45OML8HeOEL2Sk=@vger.kernel.org X-Gm-Message-State: AOJu0YyWZ/Xs74AwKUDPKTgK8b6sIL2fW1IALoCAx3mLIpfp2Op0mAXG 89c/jF1mkCeStfvk0hIz+FfazXQROQEZJawJg2n3k8CEXgFbvGmMIe2UIZUeagBHWixerL/F59X X9/cQEDrvz/bLkhwSxFN+jRJMAaoiyXFLqYEn0QYq4LYrEsXYc7tqYnOOz2ZyHps1wM4= X-Gm-Gg: ATEYQzxZhZhTU4x4K5j3QQGxX2KeHd3eE5xsXM82UzuqAVDQwetyGPhujb/0TVjyIul KLQBjCzFTKSVn340zVjueUirCqgE5RN+CI6kAStIxt58vfq/EetoDA5PdZLUkhXx+iK9o4YlOlJ crfxYaPZUH5MnsoJsNT6DLnNofcaFbUbz/EICkv3djGo9yO72Jw2DwXqRBHoAQA53qChs49SfwV KRfSJIYscJDYOFQHuLXYqY7G3jufRYdZltimGnBF8LsfGxQCpOw5ltNtqm50uLMoUoy9pIPCYpD gBBDtvEcCuOe/RAvw3TOdupBA9jtp7/oZDeBeJBQbcZlc5pegOd/VOUUzAI5/NJjnIheOgTbhAe FXevM3n7jrMBKN0o8I5Jm4xDRzaqsf7MYEMRhMvZqOSZSyjeKXEvp X-Received: by 2002:a05:6a00:4189:b0:824:9451:c1f4 with SMTP id d2e1a72fcca58-82a198ce735mr2086218b3a.55.1773393949092; Fri, 13 Mar 2026 02:25:49 -0700 (PDT) X-Received: by 2002:a05:6a00:4189:b0:824:9451:c1f4 with SMTP id d2e1a72fcca58-82a198ce735mr2086183b3a.55.1773393948499; Fri, 13 Mar 2026 02:25:48 -0700 (PDT) Received: from [10.0.0.3] ([106.222.229.52]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82a0734199csm5520997b3a.36.2026.03.13.02.25.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Mar 2026 02:25:48 -0700 (PDT) Message-ID: <5a6a6979-ff3e-0885-ce88-5c9316b9bcad@oss.qualcomm.com> Date: Fri, 13 Mar 2026 14:55:43 +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.15.1 Subject: Re: [PATCH v4 7/8] media: qcom: iris: split firmware_data from raw platform data Content-Language: en-US To: Dmitry Baryshkov Cc: Vikash Garodia , Abhinav Kumar , Bryan O'Donoghue , Mauro Carvalho Chehab , linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260313-iris-platform-data-v4-0-14927df4906d@oss.qualcomm.com> <20260313-iris-platform-data-v4-7-14927df4906d@oss.qualcomm.com> <726439a7-cf5a-74e6-1768-1bc6fb907ffc@oss.qualcomm.com> <24oq4plyvburuufxs6vt2kt7e3mlwlis7dekszjnxson245amy@muyu5fpohhfu> From: Dikshita Agarwal In-Reply-To: <24oq4plyvburuufxs6vt2kt7e3mlwlis7dekszjnxson245amy@muyu5fpohhfu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-ORIG-GUID: CIXztrTEcLCoYyD-QxJhAMTOvscxVXpG X-Proofpoint-GUID: CIXztrTEcLCoYyD-QxJhAMTOvscxVXpG X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzEzMDA3MiBTYWx0ZWRfX2+Cu6gyvXk46 noKaL795ePFZGE6NlAqx9OnfN38jdg9JGf/i3xR2lAPeJkk20NWw8+aZ93ih3F3D/j6o6axPxOE xBSC4FYwrzOg9VmY6BHkXWZ7CFRuvx+I9Gv6IkxW104aSmQGlo/7z5mpbe8uMxbmq0NCzjSRmgu DDALXna5a48uW6k6QECbikkNLuISRLtVcSL6JVDE+ACT5SfDTRXLDxgs0t5ZKbWiym7NT7XXX07 iI78XM2nanIVp27XVV9KLN7X/LqcnA3vTQrPsNxOEDE3wbYZ/VgR0/RKPSkEcWcoZ77W2DxGS4u g2GfRdOP9aKn2sb/+sIzG/BgiqVhLWFZkiC5nNR0m9Rl8XtdLKuHLH+DJSe+AO69E7VPKzcXvPs 2SH1JikYlmnPut2eyHl5XQRKlbKgQw9HrcS09LxXEALyq8cj2LfOo6RxQZ5buzfRt4w5+sBhjgT GqkEvJ44Iys73dIDZHg== X-Authority-Analysis: v=2.4 cv=ccHfb3DM c=1 sm=1 tr=0 ts=69b3d81d cx=c_pps a=rEQLjTOiSrHUhVqRoksmgQ==:117 a=ndT/fs+coltRyMHftQWjTw==:17 a=IkcTkHD0fZMA:10 a=Yq5XynenixoA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=DJpcGTmdVt4CTyJn9g5Z:22 a=EUspDBNiAAAA:8 a=smf9p1qIHa2bQNuakXcA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=2VI0MkxyNR6bbpdq8BZq:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-13_01,2026-03-12_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 bulkscore=0 malwarescore=0 suspectscore=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 spamscore=0 adultscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2603050001 definitions=main-2603130072 On 3/13/2026 1:37 PM, Dmitry Baryshkov wrote: > On Fri, Mar 13, 2026 at 01:19:21PM +0530, Dikshita Agarwal wrote: > > I'm sorry, I've refreshed the series before receiving this email. I will > send new iteration after settling the discussion here. > >> On 3/13/2026 9:00 AM, Dmitry Baryshkov wrote: >>> Having firmware-related fields in platform data results in the tying >>> platform data to the HFI firmware data rather than the actual hardware. >>> For example, SM8450 uses Gen2 firmware, so currently its platform data >>> should be placed next to the other gen2 platforms, although it has the >>> VPU2.0 core, similar to the one found on SM8250 and SC7280 and so the >>> hardware-specific platform data is also close to those devices. >>> >>> Split firmware data to a separate struct, separating hardware-related >>> data from the firmware interfaces. >>> >>> Signed-off-by: Dmitry Baryshkov >>> --- >>> drivers/media/platform/qcom/iris/iris_buffer.c | 84 +++---- >>> drivers/media/platform/qcom/iris/iris_core.h | 1 + >>> drivers/media/platform/qcom/iris/iris_ctrls.c | 8 +- >>> .../platform/qcom/iris/iris_hfi_gen1_command.c | 10 +- >>> .../platform/qcom/iris/iris_hfi_gen2_command.c | 66 ++--- >>> .../platform/qcom/iris/iris_platform_common.h | 79 +++--- >>> .../media/platform/qcom/iris/iris_platform_gen1.c | 68 +++--- >>> .../media/platform/qcom/iris/iris_platform_gen2.c | 268 +++++++-------------- >>> drivers/media/platform/qcom/iris/iris_probe.c | 3 +- >>> drivers/media/platform/qcom/iris/iris_vidc.c | 10 +- >>> 10 files changed, 246 insertions(+), 351 deletions(-) >>> >> >> >> >>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h >>> index d1daef2d874b..1a870fec4f31 100644 >>> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h >>> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h >>> @@ -201,45 +201,16 @@ enum platform_pm_domain_type { >>> IRIS_APV_HW_POWER_DOMAIN, >>> }; >>> >>> -struct iris_platform_data { >>> +struct iris_firmware_data { >>> void (*init_hfi_ops)(struct iris_core *core); >>> + >>> u32 (*get_vpu_buffer_size)(struct iris_inst *inst, enum iris_buffer_type buffer_type); >> >> I still don't think it's right to keep vpu_buffer_size in firmware data as >> this would change mostly for every new VPU variant. >> >> The buffer sizing logic depends on VPU generation (vpu2, vpu3, vpu33, >> vpu35) / SoC constraints, not on whether the HFI is Gen1 vs Gen2. > > Okay, so how do we solve the SC7280 Gen1 vs Gen2 situation? I can keep > the function pointer in struct iris_platform_data for now, letting you > sort it out in your series. Thanks! that is SC7280 problem, since code evolved due to additional features and other things, we might need to increase the vpu2 buffer size to accommodate both Ge1 and Gen2 requirement, I will check that and address in my series. > >> >> >> >>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen2.c b/drivers/media/platform/qcom/iris/iris_platform_gen2.c >>> index 10a972f96cbe..a83f6910f8b7 100644 >>> --- a/drivers/media/platform/qcom/iris/iris_platform_gen2.c >>> +++ b/drivers/media/platform/qcom/iris/iris_platform_gen2.c >>> @@ -906,41 +906,15 @@ static const u32 sm8550_enc_op_int_buf_tbl[] = { >>> BUF_SCRATCH_2, >>> }; >>> >>> -const struct iris_platform_data sm8550_data = { >>> +const struct iris_firmware_data iris_hfi_gen2_data = { >>> .init_hfi_ops = iris_hfi_gen2_sys_ops_init, >>> .get_vpu_buffer_size = iris_vpu_buf_size, >>> - .vpu_ops = &iris_vpu3_ops, >>> - .icc_tbl = sm8550_icc_table, >>> - .icc_tbl_size = ARRAY_SIZE(sm8550_icc_table), >>> - .clk_rst_tbl = sm8550_clk_reset_table, >>> - .clk_rst_tbl_size = ARRAY_SIZE(sm8550_clk_reset_table), >>> - .bw_tbl_dec = sm8550_bw_table_dec, >>> - .bw_tbl_dec_size = ARRAY_SIZE(sm8550_bw_table_dec), >>> - .pmdomain_tbl = sm8550_pmdomain_table, >>> - .pmdomain_tbl_size = ARRAY_SIZE(sm8550_pmdomain_table), >>> - .opp_pd_tbl = sm8550_opp_pd_table, >>> - .opp_pd_tbl_size = ARRAY_SIZE(sm8550_opp_pd_table), >>> - .clk_tbl = sm8550_clk_table, >>> - .clk_tbl_size = ARRAY_SIZE(sm8550_clk_table), >>> - .opp_clk_tbl = sm8550_opp_clk_table, >>> - /* Upper bound of DMA address range */ >>> - .dma_mask = 0xe0000000 - 1, >>> - .fwname = "qcom/vpu/vpu30_p4.mbn", >> >> Should fw_name be in firmware_data? as this can be change based on HFI >> versions? > > That would fail because then each device will have to gain its own > struct iris_firmware_data. > > But... Maybe we can do something as simple as: > > struct iris_firmware_desc { > const char *fwname; > u32 (*get_vpu_buffer_size)(struct iris_inst *inst, enum iris_buffer_type buffer_type); > bool (*checK_fw_match)(u8 *buf, size_t size); > const struct iris_firmware_data *data; > }; > > and then > > struct iris_platform_data { > struct iris_firmware_desc *gen1, *gen2; > // .. the rest as usual; > }; > > > struct iris_core { > u32 (*get_vpu_buffer_size)(struct iris_inst *inst, enum iris_buffer_type buffer_type); > const struct iris_firmware_data *data; > // ... the rest as expected > }; > > During first open the driver will try loading firmware from DT and > identifying it using the check_fw_match() callback. If DT doesn't have > firmware-name the driver will try loading gen2 and, if not found, gen1. > When firmware loading succeeds, it will set the pointer and the callback > in iris_core, settling the interface between the driver and the > firmware. > > WDYT? This looks good to me. It handles the SC7280 Gen1 vs Gen2 buffer size differences as well. Thanks, Dikshita > >>> -const struct iris_platform_data sm8650_data = { >>> +const struct iris_firmware_data iris_hfi_gen2_vpu33_data = { >> >> This proves my above point. >> >> iris_hfi_gen2_data and iris_hfi_gen2_vpu33_data become identical except for >> get_vpu_buffer_size, which forces us to create multiple “firmware_data” >> variants just to carry a hardware-specific difference. >> >> Also, it will scale poorly going forward. When we introduce vpu4 / >> vpu5–based platforms, we would need to add more copies of essentially the >> same HFI Gen2 firmware_data, differing only in the buffer sizing callback. > > Yes. I'm not sure, if there is any difference between params / caps as > implremented by the firmware for those generations. >