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 X-Spam-Level: X-Spam-Status: No, score=-11.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7FE99C433F5 for ; Fri, 3 Sep 2021 04:09:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5F8C060F3A for ; Fri, 3 Sep 2021 04:09:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231493AbhICEKs (ORCPT ); Fri, 3 Sep 2021 00:10:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38626 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229621AbhICEKr (ORCPT ); Fri, 3 Sep 2021 00:10:47 -0400 Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6C57C061757 for ; Thu, 2 Sep 2021 21:09:47 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id q21so7530641ljj.6 for ; Thu, 02 Sep 2021 21:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=joW/G6DY+txuyPmVNEIlO2p6pd362DkeC8kCVshvDTc=; b=ZIbvv2MoZCfOXe6LWEUxhC8fScArp+zt/1ot3m7EM6GACqj9dlCM7f5i4DhEqn8uYH d74b3ix3sflk7mxX6JPQVLBF7rgk4eCJy+wgpyUBhPBMnDB49i8UHC6Gxp//bkLuZ6OW 8hfk1vHOiK1XmbwACEuRIqpduzex9euGg7Wkg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=joW/G6DY+txuyPmVNEIlO2p6pd362DkeC8kCVshvDTc=; b=WDO/SXhmN66WiTQpvffqQJ5fKKaSYA2tClumCK7rGvrxrXAU7PYr17Er1iiOc3oseJ yp8DoHmfvrA7k3DUooGrNj1Mm/hKEwWD463PF4dusTjPtl8XFUyyPFTiYx2fRmfjSXL2 P/ntLbnJuV9ZJfPkUXqP8vHQCChMf8R71lVpVzM8E8yyIszQvPg03ohZcUmzceV+6SBY i2FD8QmAY8Bo8phN27t++zee7WvzwdrWM3NfkyGgHOVwrqJjekoGxnsh2riCOLymsqP0 MvFR811KSyi8VPuHc26hLsYEgpqMh80pK0Ro5b51xQ3zsxisloXl84HC5uI5aZIkwTBj DCrA== X-Gm-Message-State: AOAM530aK24AHV3qzHpC6d0teyafAMZRTQBPcNy3cQKqSKGNAy6nZReu JCiLu2adDUWu+Ypm2za7NWXyUCF41ESMIUno0vRUSw== X-Google-Smtp-Source: ABdhPJx4XKG0lvFDetGV90273eSD7bOwt7ysolxtpaJkRUK9uLWj4p8fL3g2ooVhI35FhJ7mJLx4mBVrJkVVhWz8scM= X-Received: by 2002:a2e:b16a:: with SMTP id a10mr1352765ljm.18.1630642185751; Thu, 02 Sep 2021 21:09:45 -0700 (PDT) MIME-Version: 1.0 References: <20210901083215.25984-1-yunfei.dong@mediatek.com> In-Reply-To: From: Chen-Yu Tsai Date: Fri, 3 Sep 2021 12:09:34 +0800 Message-ID: Subject: Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode To: Ezequiel Garcia Cc: Yunfei Dong , Alexandre Courbot , Hans Verkuil , Tzung-Bi Shih , Tiffany Lin , Andrew-CT Chen , Mauro Carvalho Chehab , Rob Herring , Matthias Brugger , Tomasz Figa , Laurent Pinchart , Daniel Vetter , dri-devel , Hsin-Yi Wang , Fritz Koenig , Irui Wang , linux-media , devicetree , Linux Kernel Mailing List , linux-arm-kernel , srv_heupstream , "moderated list:ARM/Mediatek SoC support" , Project_Global_Chrome_Upstream_Group Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 3, 2021 at 12:31 AM Ezequiel Garcia wrote: > > On Wed, 1 Sept 2021 at 05:32, Yunfei Dong wrote: > > > > This series adds support for multi hardware decode into mtk-vcodec, by first > > adding component framework to manage each hardware information: interrupt, > > clock, register bases and power. Secondly add core thread to deal with core > > hardware message, at the same time, add msg queue for different hardware > > share messages. Lastly, the architecture of different specs are not the same, > > using specs type to separate them. > > > > This series has been tested with both MT8183 and MT8173. Decoding was working > > for both chips. > > > > Patches 1~3 rewrite get register bases and power on/off interface. > > > > Patch 4 add component framework to support multi hardware. > > > > Patch 5 separate video encoder and decoder document > > > > Patches 6-15 add interfaces to support core hardware. > > ---- > > This patch dependents on : "media: mtk-vcodec: support for MT8183 decoder"[1] and > > "Mediatek MT8192 clock support"[2]. > > > > 1: Multi hardware decode is based on stateless decoder, MT8183 is the first time > > to add stateless decoder. Otherwise it will cause conflict. This patch will be > > accepted in 5.15[1]. > > > > 2: The definition of decoder clocks are in mt8192-clk.h, this patch already in clk tree[2]. > > > > [1]https://patchwork.linuxtv.org/project/linux-media/list/?series=5826 > > [2]https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/commit/?h=clk-next&id=f35f1a23e0e12e3173e9e9dedbc150d139027189 > > ---- > > Changes compared with v5: > > -Add decoder hardware block diagram for patch 13/15 > > > > > The discussion on v5 was still on-going, so sending this v6 > is not helpful. The context for v5's discussion is now harder to find. > > Please avoid sending a new version without properly > discussing all the feedback, and without reaching consensus. > This is very important, please keep it in mind. > > Specifically, the feedback on v5 was NAK, with the request to avoid > using any async framework, and instead try to find a simpler solution. > > For instance, you can model things with a bus-like pattern, > which ties all the devices together, under a parent node. > This pattern is common in the kernel, the parent > node can use of_platform_populate or similar > (git grep of_platform_populate, you will see plenty of examples). > > You will still have to do some work to have the proper > regs resources, but this is doable. Each child is a device, > so it can have its own resources (clocks, interrupts, iommus). AFAIK of_platform_populate doesn't guarantee the drivers actually probed (modules loaded late, missing modules, deferred probe, etc.), only that the devices are created, so you still need some sort of (async) mechanism to wait for the subdevices to be in operational state. Most of the examples using of_platform_populate are there to ensure that the parent device is operational before creating the sub-devices, not the other way around. ChenYu > You don't need any async framework. > > vcodec_dec: vcodec_dec@16000000 { > compatible = "mediatek,mt8192-vcodec-dec"; > reg = ; > mediatek,scp = <&scp>; > iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>; > dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; > > vcodec_lat@0x10000 { > compatible = "mediatek,mtk-vcodec-lat"; > reg = <0x10000 0x800>; /* VDEC_MISC */ > interrupts = ; > // etc > }; > > vcodec_core@0x25000 { > compatible = "mediatek,mtk-vcodec-core"; > reg = <0x25000 0x1000>; /* VDEC_CORE_MISC */ > interrupts = ; > // etc > }; > }; > > Thanks, > Ezequiel > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 X-Spam-Level: X-Spam-Status: No, score=-11.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58798C433EF for ; Fri, 3 Sep 2021 04:09:50 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1160460F3A for ; Fri, 3 Sep 2021 04:09:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 1160460F3A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6E2C06E82D; Fri, 3 Sep 2021 04:09:48 +0000 (UTC) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by gabe.freedesktop.org (Postfix) with ESMTPS id C9CB96E82D for ; Fri, 3 Sep 2021 04:09:47 +0000 (UTC) Received: by mail-lj1-x22f.google.com with SMTP id s12so7585424ljg.0 for ; Thu, 02 Sep 2021 21:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=joW/G6DY+txuyPmVNEIlO2p6pd362DkeC8kCVshvDTc=; b=ZIbvv2MoZCfOXe6LWEUxhC8fScArp+zt/1ot3m7EM6GACqj9dlCM7f5i4DhEqn8uYH d74b3ix3sflk7mxX6JPQVLBF7rgk4eCJy+wgpyUBhPBMnDB49i8UHC6Gxp//bkLuZ6OW 8hfk1vHOiK1XmbwACEuRIqpduzex9euGg7Wkg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=joW/G6DY+txuyPmVNEIlO2p6pd362DkeC8kCVshvDTc=; b=IguYdaZ2IbNQ7c656PFJwQ3n9mton4tB92t+GQABqUv1n01D9B6HwvHVgO7ort+LcS 81fw/PFO2BkakvciAezEznNl2dtjRA9+rU3QdMEkF0hWbco8f831y2N0v+lbDDPOT7tT Eer1ferVm74kWhmfckOmopL28kqLTSevx+wdog23XyTUhcZbTR9ocdGxdAf6V/OCjVgB c0YMAGTKpu3txa+bD+P+axEdUs8GFiwvCk1i+uJgf1ACG+GTEyoVX9JPBuSR0a4gteJ6 OPZFtJNZKt01z4s+FEDH6ExiEQL4cVgO983E0P7JRQEQttAFS+aXASTnJuFj1A8ZsdXF fcSw== X-Gm-Message-State: AOAM530ey7whq72AEFaZ4nlqArjpAm+fUvwa3rl+T2B3e4Uwq9IbpXux fqUoQPNvIlqLhJrQPbGpOt9tLgCnZ2O7v0LdJou8gw== X-Google-Smtp-Source: ABdhPJx4XKG0lvFDetGV90273eSD7bOwt7ysolxtpaJkRUK9uLWj4p8fL3g2ooVhI35FhJ7mJLx4mBVrJkVVhWz8scM= X-Received: by 2002:a2e:b16a:: with SMTP id a10mr1352765ljm.18.1630642185751; Thu, 02 Sep 2021 21:09:45 -0700 (PDT) MIME-Version: 1.0 References: <20210901083215.25984-1-yunfei.dong@mediatek.com> In-Reply-To: From: Chen-Yu Tsai Date: Fri, 3 Sep 2021 12:09:34 +0800 Message-ID: Subject: Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode To: Ezequiel Garcia Cc: Yunfei Dong , Alexandre Courbot , Hans Verkuil , Tzung-Bi Shih , Tiffany Lin , Andrew-CT Chen , Mauro Carvalho Chehab , Rob Herring , Matthias Brugger , Tomasz Figa , Laurent Pinchart , Daniel Vetter , dri-devel , Hsin-Yi Wang , Fritz Koenig , Irui Wang , linux-media , devicetree , Linux Kernel Mailing List , linux-arm-kernel , srv_heupstream , "moderated list:ARM/Mediatek SoC support" , Project_Global_Chrome_Upstream_Group Content-Type: text/plain; charset="UTF-8" X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Sep 3, 2021 at 12:31 AM Ezequiel Garcia wrote: > > On Wed, 1 Sept 2021 at 05:32, Yunfei Dong wrote: > > > > This series adds support for multi hardware decode into mtk-vcodec, by first > > adding component framework to manage each hardware information: interrupt, > > clock, register bases and power. Secondly add core thread to deal with core > > hardware message, at the same time, add msg queue for different hardware > > share messages. Lastly, the architecture of different specs are not the same, > > using specs type to separate them. > > > > This series has been tested with both MT8183 and MT8173. Decoding was working > > for both chips. > > > > Patches 1~3 rewrite get register bases and power on/off interface. > > > > Patch 4 add component framework to support multi hardware. > > > > Patch 5 separate video encoder and decoder document > > > > Patches 6-15 add interfaces to support core hardware. > > ---- > > This patch dependents on : "media: mtk-vcodec: support for MT8183 decoder"[1] and > > "Mediatek MT8192 clock support"[2]. > > > > 1: Multi hardware decode is based on stateless decoder, MT8183 is the first time > > to add stateless decoder. Otherwise it will cause conflict. This patch will be > > accepted in 5.15[1]. > > > > 2: The definition of decoder clocks are in mt8192-clk.h, this patch already in clk tree[2]. > > > > [1]https://patchwork.linuxtv.org/project/linux-media/list/?series=5826 > > [2]https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/commit/?h=clk-next&id=f35f1a23e0e12e3173e9e9dedbc150d139027189 > > ---- > > Changes compared with v5: > > -Add decoder hardware block diagram for patch 13/15 > > > > > The discussion on v5 was still on-going, so sending this v6 > is not helpful. The context for v5's discussion is now harder to find. > > Please avoid sending a new version without properly > discussing all the feedback, and without reaching consensus. > This is very important, please keep it in mind. > > Specifically, the feedback on v5 was NAK, with the request to avoid > using any async framework, and instead try to find a simpler solution. > > For instance, you can model things with a bus-like pattern, > which ties all the devices together, under a parent node. > This pattern is common in the kernel, the parent > node can use of_platform_populate or similar > (git grep of_platform_populate, you will see plenty of examples). > > You will still have to do some work to have the proper > regs resources, but this is doable. Each child is a device, > so it can have its own resources (clocks, interrupts, iommus). AFAIK of_platform_populate doesn't guarantee the drivers actually probed (modules loaded late, missing modules, deferred probe, etc.), only that the devices are created, so you still need some sort of (async) mechanism to wait for the subdevices to be in operational state. Most of the examples using of_platform_populate are there to ensure that the parent device is operational before creating the sub-devices, not the other way around. ChenYu > You don't need any async framework. > > vcodec_dec: vcodec_dec@16000000 { > compatible = "mediatek,mt8192-vcodec-dec"; > reg = ; > mediatek,scp = <&scp>; > iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>; > dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; > > vcodec_lat@0x10000 { > compatible = "mediatek,mtk-vcodec-lat"; > reg = <0x10000 0x800>; /* VDEC_MISC */ > interrupts = ; > // etc > }; > > vcodec_core@0x25000 { > compatible = "mediatek,mtk-vcodec-core"; > reg = <0x25000 0x1000>; /* VDEC_CORE_MISC */ > interrupts = ; > // etc > }; > }; > > Thanks, > Ezequiel > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D693C433F5 for ; Fri, 3 Sep 2021 04:10:24 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F2A7361058 for ; Fri, 3 Sep 2021 04:10:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org F2A7361058 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1X/drakGn0N3zm9JQQPn4nSP1KqZlZjefGho2/2sQ9s=; b=LBsxxUcm6BRyhV BPzn9LcT0UJbDY2S4OjnrJoCg4WCPQFjhzYsq3arl1aa1tQ9FzVh2V23iaanKeNR9l+Jr46DbtKb/ p8hvi8pQtpZXxaydarRJmG69bebrVk2QEzqWdMq9xCSkKtqBkwG5RjY55EPwzyT/jhyfs0pl6LcXk 50mq8NevQuCMazqg0Zo4ZnlrhdTU6HV3YrXFg7J6O73HP0dZZHkzWM6t6lHPV1Jb92pubEd9vKoDe cEds8FobWTbrE9fNHtdJI7zgnsRq2Wsuo+xaDyz4zvk73smrM6tiav1Tphi63I8XtcWxxIidgtC4i COubYoNba7WRa0RLbzUA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mM0Wg-00Aw89-7X; Fri, 03 Sep 2021 04:10:02 +0000 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mM0WR-00Aw4f-TV for linux-mediatek@lists.infradead.org; Fri, 03 Sep 2021 04:09:49 +0000 Received: by mail-lj1-x230.google.com with SMTP id l18so7503772lji.12 for ; Thu, 02 Sep 2021 21:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=joW/G6DY+txuyPmVNEIlO2p6pd362DkeC8kCVshvDTc=; b=ZIbvv2MoZCfOXe6LWEUxhC8fScArp+zt/1ot3m7EM6GACqj9dlCM7f5i4DhEqn8uYH d74b3ix3sflk7mxX6JPQVLBF7rgk4eCJy+wgpyUBhPBMnDB49i8UHC6Gxp//bkLuZ6OW 8hfk1vHOiK1XmbwACEuRIqpduzex9euGg7Wkg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=joW/G6DY+txuyPmVNEIlO2p6pd362DkeC8kCVshvDTc=; b=jSDbZjISRZrCCoohrTKK3pDewyNo+9FP7Um5PuCQ96huv9TSIsS6uwsVAVsNfodvyV R1HgjlwR9e35UXFzfbJ5ooSnoOcfuIHKqQ+X4jWio6oU1GQRbFMlrj3zrbkRd8W0AENp 8WIkDu+3hd6iXvyDSbVJpOf4xzR6Gt220d4qWstp7lkJN3ySWVISa4lwGiAUDLJ8kfLB BI0xV6pAM9ZMutwyeFDPVJZZsC6AuTnLZEfvZ0Kz180qkHJEzFdSRS0i8hayhyyUlFT3 BA1ki2FoICG8Mc9brywnMjYxlwsCByPW/t3quWlH5h3S+Sd4LsmgEZCp5T+J7HqFbvkC 4rxQ== X-Gm-Message-State: AOAM531qsct5qyT/JFvTdxonvmUfRAGb7WuRx2ULOzVGp05X79XGyhkS W84avBXjTqqQZzxSw6h5U21Y0mos96BHTGa/SPT4iw== X-Google-Smtp-Source: ABdhPJx4XKG0lvFDetGV90273eSD7bOwt7ysolxtpaJkRUK9uLWj4p8fL3g2ooVhI35FhJ7mJLx4mBVrJkVVhWz8scM= X-Received: by 2002:a2e:b16a:: with SMTP id a10mr1352765ljm.18.1630642185751; Thu, 02 Sep 2021 21:09:45 -0700 (PDT) MIME-Version: 1.0 References: <20210901083215.25984-1-yunfei.dong@mediatek.com> In-Reply-To: From: Chen-Yu Tsai Date: Fri, 3 Sep 2021 12:09:34 +0800 Message-ID: Subject: Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode To: Ezequiel Garcia Cc: Yunfei Dong , Alexandre Courbot , Hans Verkuil , Tzung-Bi Shih , Tiffany Lin , Andrew-CT Chen , Mauro Carvalho Chehab , Rob Herring , Matthias Brugger , Tomasz Figa , Laurent Pinchart , Daniel Vetter , dri-devel , Hsin-Yi Wang , Fritz Koenig , Irui Wang , linux-media , devicetree , Linux Kernel Mailing List , linux-arm-kernel , srv_heupstream , "moderated list:ARM/Mediatek SoC support" , Project_Global_Chrome_Upstream_Group X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210902_210948_039132_01D1D2FA X-CRM114-Status: GOOD ( 35.92 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org On Fri, Sep 3, 2021 at 12:31 AM Ezequiel Garcia wrote: > > On Wed, 1 Sept 2021 at 05:32, Yunfei Dong wrote: > > > > This series adds support for multi hardware decode into mtk-vcodec, by first > > adding component framework to manage each hardware information: interrupt, > > clock, register bases and power. Secondly add core thread to deal with core > > hardware message, at the same time, add msg queue for different hardware > > share messages. Lastly, the architecture of different specs are not the same, > > using specs type to separate them. > > > > This series has been tested with both MT8183 and MT8173. Decoding was working > > for both chips. > > > > Patches 1~3 rewrite get register bases and power on/off interface. > > > > Patch 4 add component framework to support multi hardware. > > > > Patch 5 separate video encoder and decoder document > > > > Patches 6-15 add interfaces to support core hardware. > > ---- > > This patch dependents on : "media: mtk-vcodec: support for MT8183 decoder"[1] and > > "Mediatek MT8192 clock support"[2]. > > > > 1: Multi hardware decode is based on stateless decoder, MT8183 is the first time > > to add stateless decoder. Otherwise it will cause conflict. This patch will be > > accepted in 5.15[1]. > > > > 2: The definition of decoder clocks are in mt8192-clk.h, this patch already in clk tree[2]. > > > > [1]https://patchwork.linuxtv.org/project/linux-media/list/?series=5826 > > [2]https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/commit/?h=clk-next&id=f35f1a23e0e12e3173e9e9dedbc150d139027189 > > ---- > > Changes compared with v5: > > -Add decoder hardware block diagram for patch 13/15 > > > > > The discussion on v5 was still on-going, so sending this v6 > is not helpful. The context for v5's discussion is now harder to find. > > Please avoid sending a new version without properly > discussing all the feedback, and without reaching consensus. > This is very important, please keep it in mind. > > Specifically, the feedback on v5 was NAK, with the request to avoid > using any async framework, and instead try to find a simpler solution. > > For instance, you can model things with a bus-like pattern, > which ties all the devices together, under a parent node. > This pattern is common in the kernel, the parent > node can use of_platform_populate or similar > (git grep of_platform_populate, you will see plenty of examples). > > You will still have to do some work to have the proper > regs resources, but this is doable. Each child is a device, > so it can have its own resources (clocks, interrupts, iommus). AFAIK of_platform_populate doesn't guarantee the drivers actually probed (modules loaded late, missing modules, deferred probe, etc.), only that the devices are created, so you still need some sort of (async) mechanism to wait for the subdevices to be in operational state. Most of the examples using of_platform_populate are there to ensure that the parent device is operational before creating the sub-devices, not the other way around. ChenYu > You don't need any async framework. > > vcodec_dec: vcodec_dec@16000000 { > compatible = "mediatek,mt8192-vcodec-dec"; > reg = ; > mediatek,scp = <&scp>; > iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>; > dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; > > vcodec_lat@0x10000 { > compatible = "mediatek,mtk-vcodec-lat"; > reg = <0x10000 0x800>; /* VDEC_MISC */ > interrupts = ; > // etc > }; > > vcodec_core@0x25000 { > compatible = "mediatek,mtk-vcodec-core"; > reg = <0x25000 0x1000>; /* VDEC_CORE_MISC */ > interrupts = ; > // etc > }; > }; > > Thanks, > Ezequiel > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek 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 X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF4FDC433F5 for ; Fri, 3 Sep 2021 04:13:17 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6AE5660F4B for ; Fri, 3 Sep 2021 04:13:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6AE5660F4B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=4KflpZadJEAKedNsw3YNW4Tko6Shkchp9eSsNeK7p4M=; b=JnOpAzEZOCVdj2 kG99D4me35dbB6V7M8Bxe9HljFFZHAjcX+mrsT3fefAKZgN7kAMp++eYaR8xOHsXQkLRGI6SZ1Cj6 +0XwiwYcUaezta/6oUcMTvS3iCYTZb+03KQuDsABjWucu+n0nZvW++MujGuMm+2nYq2D/qIusUpFF kuseo+Vi9W0rIisQZXA/eTfpvH70YhbtDn8epTD4+WhHfGk+4zAAg0iE7dr1NqJ4b8DCNrQo/1rQx LzonNxID3u33tJe5lfNMdTlMu8P4ifcakCkd2PXb7Bu35mIEwp5YLy/A9fukRUwgCb+J0RHyWM7Eg UX4xi+WUNsYzwK4iHE8A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mM0WW-00Aw5y-IV; Fri, 03 Sep 2021 04:09:52 +0000 Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mM0WR-00Aw4g-TW for linux-arm-kernel@lists.infradead.org; Fri, 03 Sep 2021 04:09:49 +0000 Received: by mail-lj1-x22d.google.com with SMTP id h1so7519259ljl.9 for ; Thu, 02 Sep 2021 21:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=joW/G6DY+txuyPmVNEIlO2p6pd362DkeC8kCVshvDTc=; b=ZIbvv2MoZCfOXe6LWEUxhC8fScArp+zt/1ot3m7EM6GACqj9dlCM7f5i4DhEqn8uYH d74b3ix3sflk7mxX6JPQVLBF7rgk4eCJy+wgpyUBhPBMnDB49i8UHC6Gxp//bkLuZ6OW 8hfk1vHOiK1XmbwACEuRIqpduzex9euGg7Wkg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=joW/G6DY+txuyPmVNEIlO2p6pd362DkeC8kCVshvDTc=; b=k2dkotGvbjtkNoHcbGW+GuS7EnHJ73yWEAVauUUTh4p5ZoTJO6YPs7Xg9T3IiJEYHL x3SzIAS+QeFCGUNBpXoP/VLJXstSLRs84rLGrMlgPDRg2Alm0OoQv/2xSyPQapx3/yI7 HBXYzUCkCM7Se+mC5zxvmXYCFiTIf+4e8CejmpPtUQYYxNCmtxowafHkBzB2asvvJ4Pz 13+JGIBf6+alWR5gTftiG0po+nSEgRmRoW0ldIDR4FT3J3e5xMZvXJomVirniXXlPoCl X4GYOad6EUmbelTzEdgk6sQZoZcDrKaQpm14qROplJl0pCtwzt79d84klAjQgfd9jawz q5iA== X-Gm-Message-State: AOAM533+wKvQNec6Wjmf9SyocV9SIdTzTFL/ZVwn/tduzC+dKfXXGeVF oQueoH8P1XSzIvt+hqoI6VtzNOoa9i4iLadsTcj8qw== X-Google-Smtp-Source: ABdhPJx4XKG0lvFDetGV90273eSD7bOwt7ysolxtpaJkRUK9uLWj4p8fL3g2ooVhI35FhJ7mJLx4mBVrJkVVhWz8scM= X-Received: by 2002:a2e:b16a:: with SMTP id a10mr1352765ljm.18.1630642185751; Thu, 02 Sep 2021 21:09:45 -0700 (PDT) MIME-Version: 1.0 References: <20210901083215.25984-1-yunfei.dong@mediatek.com> In-Reply-To: From: Chen-Yu Tsai Date: Fri, 3 Sep 2021 12:09:34 +0800 Message-ID: Subject: Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode To: Ezequiel Garcia Cc: Yunfei Dong , Alexandre Courbot , Hans Verkuil , Tzung-Bi Shih , Tiffany Lin , Andrew-CT Chen , Mauro Carvalho Chehab , Rob Herring , Matthias Brugger , Tomasz Figa , Laurent Pinchart , Daniel Vetter , dri-devel , Hsin-Yi Wang , Fritz Koenig , Irui Wang , linux-media , devicetree , Linux Kernel Mailing List , linux-arm-kernel , srv_heupstream , "moderated list:ARM/Mediatek SoC support" , Project_Global_Chrome_Upstream_Group X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210902_210948_040241_F1393157 X-CRM114-Status: GOOD ( 37.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Sep 3, 2021 at 12:31 AM Ezequiel Garcia wrote: > > On Wed, 1 Sept 2021 at 05:32, Yunfei Dong wrote: > > > > This series adds support for multi hardware decode into mtk-vcodec, by first > > adding component framework to manage each hardware information: interrupt, > > clock, register bases and power. Secondly add core thread to deal with core > > hardware message, at the same time, add msg queue for different hardware > > share messages. Lastly, the architecture of different specs are not the same, > > using specs type to separate them. > > > > This series has been tested with both MT8183 and MT8173. Decoding was working > > for both chips. > > > > Patches 1~3 rewrite get register bases and power on/off interface. > > > > Patch 4 add component framework to support multi hardware. > > > > Patch 5 separate video encoder and decoder document > > > > Patches 6-15 add interfaces to support core hardware. > > ---- > > This patch dependents on : "media: mtk-vcodec: support for MT8183 decoder"[1] and > > "Mediatek MT8192 clock support"[2]. > > > > 1: Multi hardware decode is based on stateless decoder, MT8183 is the first time > > to add stateless decoder. Otherwise it will cause conflict. This patch will be > > accepted in 5.15[1]. > > > > 2: The definition of decoder clocks are in mt8192-clk.h, this patch already in clk tree[2]. > > > > [1]https://patchwork.linuxtv.org/project/linux-media/list/?series=5826 > > [2]https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/commit/?h=clk-next&id=f35f1a23e0e12e3173e9e9dedbc150d139027189 > > ---- > > Changes compared with v5: > > -Add decoder hardware block diagram for patch 13/15 > > > > > The discussion on v5 was still on-going, so sending this v6 > is not helpful. The context for v5's discussion is now harder to find. > > Please avoid sending a new version without properly > discussing all the feedback, and without reaching consensus. > This is very important, please keep it in mind. > > Specifically, the feedback on v5 was NAK, with the request to avoid > using any async framework, and instead try to find a simpler solution. > > For instance, you can model things with a bus-like pattern, > which ties all the devices together, under a parent node. > This pattern is common in the kernel, the parent > node can use of_platform_populate or similar > (git grep of_platform_populate, you will see plenty of examples). > > You will still have to do some work to have the proper > regs resources, but this is doable. Each child is a device, > so it can have its own resources (clocks, interrupts, iommus). AFAIK of_platform_populate doesn't guarantee the drivers actually probed (modules loaded late, missing modules, deferred probe, etc.), only that the devices are created, so you still need some sort of (async) mechanism to wait for the subdevices to be in operational state. Most of the examples using of_platform_populate are there to ensure that the parent device is operational before creating the sub-devices, not the other way around. ChenYu > You don't need any async framework. > > vcodec_dec: vcodec_dec@16000000 { > compatible = "mediatek,mt8192-vcodec-dec"; > reg = ; > mediatek,scp = <&scp>; > iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>; > dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; > > vcodec_lat@0x10000 { > compatible = "mediatek,mtk-vcodec-lat"; > reg = <0x10000 0x800>; /* VDEC_MISC */ > interrupts = ; > // etc > }; > > vcodec_core@0x25000 { > compatible = "mediatek,mtk-vcodec-core"; > reg = <0x25000 0x1000>; /* VDEC_CORE_MISC */ > interrupts = ; > // etc > }; > }; > > Thanks, > Ezequiel > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel