Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp203877rwb; Wed, 28 Sep 2022 01:16:25 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6MiwqbDzR/2eMyzPZRCF8s/W0B8bggrjex/w1Fjh2GqJa6Hw0BAcD1Le3qoEs64s03GEWV X-Received: by 2002:a17:903:41cb:b0:178:36c2:a98 with SMTP id u11-20020a17090341cb00b0017836c20a98mr30692743ple.47.1664352985480; Wed, 28 Sep 2022 01:16:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664352985; cv=none; d=google.com; s=arc-20160816; b=x2KtR+DybtdMHZOecspornSzJl3MM/ClfbuYmDgSxoxYyiKNcKKBsCwLti93xMFfCX 7h6le2Ue4RmnNemlF1SlxbDeF36+NNTz6dOi55DMFVSVgu6qCr9amOJjF9UqsKVCavuV cJGyXko7Z7Cijc5nXRW0KJ93FUqq6rgLjT9yw2FECgsFKEjbUESewCv4XlEVE08lDEbQ XeNfaRwbJpUczT5bHfsrNIjwZ6mylF2kU1hpUXSIVEra1ew8Pgq15ZSCnh43CFznJEP/ k9aHCefhNoZ8o/eN792XN60ctjGiZAetJxMHpYWUrztV4qES6R/FELgedvtMoZRk/KJz jy6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=B+e3lPKUMpN6ZdznFE96tvmFCRSiZtlu1w9xW7uURXY=; b=D4AawvQt4MiPk/QKpc/z+2lC1MW5gmWCalULRBB/7ZjJB6llVXnySiLvZ5un3hbG2L /fiimcsviv98xRMPauKXFfQlHtIExKhMLkGeLzkVn3dMjeqJCsZ4/W+aexJl8+fdq0Wg WowJzR5EsBto1ip9KZ1kIxVVe+kVLSYTKuEaXIozDlU7HVDZ2ZzHVKry5ke/P5a+5FWt iHaunAem/ev+erseW8tLJ9rHWsvPIJUduhpubrzHAdJJb41SO3lmE/tqCLmkgt+3iJ4k AQsoHiZSanmsPFf43Xji6yFRLOh81ABaFGAMej7cU6tfnsHZ9bR2gJUBMJNy1u+t0Xaw wn9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b="TYk/3bPR"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z22-20020a63b916000000b00439c6a5c3c4si4696852pge.533.2022.09.28.01.16.14; Wed, 28 Sep 2022 01:16:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b="TYk/3bPR"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233745AbiI1H60 (ORCPT + 99 others); Wed, 28 Sep 2022 03:58:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233549AbiI1H6Y (ORCPT ); Wed, 28 Sep 2022 03:58:24 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D76B4454E; Wed, 28 Sep 2022 00:58:23 -0700 (PDT) Received: from [192.168.1.100] (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: kholk11) by madras.collabora.co.uk (Postfix) with ESMTPSA id 3A9136601EB5; Wed, 28 Sep 2022 08:58:21 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1664351902; bh=e/mPVgGURMWxGYEIW4p02kZFhXBi5nXgg4F5k0bpy54=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=TYk/3bPREZ0ETnF9mVPkIiNQOTPa+nZHbNZ9uVIoH3AMlqd4wowy7Cq6bygwyXOEh Jffp9pu0jq7qJ4MUQb/0MUQTYYrMcxuFiwio7uXbmueISdOytGiLHcJeKm97yGNQv9 o5Qp5bgILa/SPkA3eQJRxIBMu+hIrHi8rClVnLbm2fq8CJB7tsCnwnJ5xmgj8ET4DQ npVFafytKPtTkcC0C6H3uDcPzpXkFpepY5O58WOI1qQ6aGC6WSvZKbCuU5D63wMtCH VJHLUZK+nuOT+S5aTH05Q2HyNxu7MWCMoxAjDYbGrzBaWnSZpBi9QPuiu3RZcaJ759 iptJdJSKqXaRA== Message-ID: <68e1c8b0-04cf-acf8-b6b6-97d9eb8a7c4a@collabora.com> Date: Wed, 28 Sep 2022 09:58:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: [PATCH v2] arm64: dts: mt8192: Add vcodec lat and core nodes Content-Language: en-US To: Krzysztof Kozlowski , =?UTF-8?B?QWxsZW4tS0ggQ2hlbmcgKOeoi+WGoOWLsyk=?= , "matthias.bgg@gmail.com" , "robh+dt@kernel.org" Cc: "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , Project_Global_Chrome_Upstream_Group , "devicetree@vger.kernel.org" References: <20220926105047.19419-1-allen-kh.cheng@mediatek.com> <4d1e8600-f73d-8d2b-2e7a-1b75be7624bd@collabora.com> <05ed341b-2db3-620f-7a70-dcebfaa66f1a@collabora.com> <172e10ee-22fd-ccec-1a5a-7bd0a29dbfc4@linaro.org> From: AngeloGioacchino Del Regno In-Reply-To: <172e10ee-22fd-ccec-1a5a-7bd0a29dbfc4@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Il 28/09/22 09:04, Krzysztof Kozlowski ha scritto: > On 27/09/2022 12:17, AngeloGioacchino Del Regno wrote: >>>> >>> >>> Sorry, my bad. I alsways run `make dtbs_check` to confirm dtb with >>> bindings. I just think we didn't limit node names in mtk-vodec >>> bindings. I will pay attention next time. >>> >>> >>> Since currently the vcodec lat and core nodes are absent from the mtk >>> dts, do you think the child node name should be changed to something >>> more general (ex: video-codec) in mediatek,vcodec-subdev-decoder >>> bindings? >> >> The video codec is mt8192-vcodec-dec, while the other nodes are describing >> the VPU instances (and/or vpu cores)... I'm not sure. >> >> Krzysztof, please, can you give your opinion on that? >> > > What's the difference between them? I understand parent device is entire > block of consisting of multiple processing units? If so, video-codec > actually could fit in both places. But feel free to call it a bit > different (video-codec-core, video-codec-lat, processing-unit, even > something less generic). Sometimes it's tricky to find nice name, so I > wouldn't worry too much in that case. Just not "mt8192-vcodec" :) > The parent device is the entire block consisting of multiple processing units and has "global" control registers; children are LAT(s) and processing cores. From my understanding, the processing cores are physical cores of one big VPU and, depending on the actual (current gen) SoC, the VPU may have one or two cores. Right now, the bindings want vcodec-latX@addr, vcodec-coreX@addr (where X is a number, like vcodec-core0, vcodec-core1) but, in my opinion, changing that to video-codec-lat@addr and video-codec-core@addr would be more descriptive. ...Or should we simply leave the bindings as they are and just go with the abbreviated "vcodec-(hwtype)" names? Regards, Angelo