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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 14AD6E743F9 for ; Fri, 29 Sep 2023 08:43:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ee/pWK40TSTc6ZdCdjVamOShH6v6yAM9Zev5EmTx73k=; b=iOIjz86qVpU5gXicDBzR5Wwvts iNc9iYgwOJFRFF7Pquf5ZTZULIfPeMj0hSx+tVePj9kvCMOFpzQi1UP+9BWRaOx9W1bNT2g9x9crx 3+z9ZaUv3DU9Ha+WWYqrpbWiQGT0PDK/rsyqoCEoGPp71tPBjsDSf6dhbI5rlmQnUgLdu6e9Y4JWZ iwR1iXkTbo7tTHMqFst9eKoRxwNPswok2Ao+qyp7/yGDWcG4kMDyYgwutf9Wfl2JG2/KRlH7VK62n RSMp2ydxV9f21u49V9tfFYMMOjbCo6J5qSzT0aciieEq5HIRclq6endne4K0G+eoqatkP1ZnGSQum rfXJlDrA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qm95Y-007OKv-23; Fri, 29 Sep 2023 08:43:08 +0000 Received: from madras.collabora.co.uk ([46.235.227.172]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qm95V-007OHx-0K; Fri, 29 Sep 2023 08:43:06 +0000 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 00D826607342; Fri, 29 Sep 2023 09:43:00 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1695976981; bh=uiFIr0QtcCv98GNZksTz1IxuKJn0A6If3Wrm+S+R9Dc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=eJoJRtp1NC059atmmhRsvEF31BihjtVtAugFx9dlHoCrFMBZh1jrGhteZOlo7RtkQ lnd8AHDTWkDdCIK+dU4OKIxtlycUe2lQzyaHoPniUsh9504Jfx5K2Q2Xo2ivAMIR5y lZ0Wgvy5icrDdyae2/OPe8IfKJm4NVH6i7Z1QfGsAo3HHSmGrpwsXVNCD1wt9pTl8W sfDdjupPGdPFFqDZcxRGfx1uIrxFP8kzYqO70uBvOtPFpvG+t9ZDwvJFv7jCFWuueV pD63I9XS/sLFkPbSWcXovtm+qQ7OQLva188CiILIbcZDUrtKapgfnyTyr0EWLfYlSD zzETDP2l5hs7A== Message-ID: <7dbadd86-f408-bc94-92fc-22f460eebb43@collabora.com> Date: Fri, 29 Sep 2023 10:42:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH v6 12/16] dt-bindings: display: mediatek: color: add compatible for MT8195 Content-Language: en-US To: Conor Dooley , =?UTF-8?B?TW91ZHkgSG8gKOS9leWul+WOnyk=?= Cc: "conor.dooley@microchip.com" , "linux-kernel@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , "robh+dt@kernel.org" , "linux-media@vger.kernel.org" , "chunkuang.hu@kernel.org" , "devicetree@vger.kernel.org" , "mchehab@kernel.org" , "daniel@ffwll.ch" , "p.zabel@pengutronix.de" , "conor+dt@kernel.org" , "dri-devel@lists.freedesktop.org" , "hverkuil-cisco@xs4all.nl" , "airlied@gmail.com" , "krzysztof.kozlowski+dt@linaro.org" , "matthias.bgg@gmail.com" , "linux-arm-kernel@lists.infradead.org" References: <20230922072116.11009-1-moudy.ho@mediatek.com> <20230922072116.11009-13-moudy.ho@mediatek.com> <20230922-zebra-modify-87ff23c70bb3@spud> <20230922-overhung-deception-e9b461ba0372@spud> <7c445195e17e15d5af5fcb30ae53f76c713e958b.camel@mediatek.com> <20230927-crunching-prancing-36fe3eb79607@wendy> <825ac03b692043d48563620ad9542a4ee43211e7.camel@mediatek.com> <20230928-keep-attractor-1e7cd0df03b2@spud> From: AngeloGioacchino Del Regno In-Reply-To: <20230928-keep-attractor-1e7cd0df03b2@spud> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230929_014305_394897_CD146A49 X-CRM114-Status: GOOD ( 29.65 ) 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: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org Il 28/09/23 18:49, Conor Dooley ha scritto: > On Thu, Sep 28, 2023 at 02:52:23AM +0000, Moudy Ho (何宗原) wrote: >> On Wed, 2023-09-27 at 10:47 +0100, Conor Dooley wrote: >>> On Wed, Sep 27, 2023 at 07:19:28AM +0000, Moudy Ho (何宗原) wrote: >>>> On Fri, 2023-09-22 at 16:51 +0100, Conor Dooley wrote: >>>>> On Fri, Sep 22, 2023 at 04:49:14PM +0100, Conor Dooley wrote: >>>>>> On Fri, Sep 22, 2023 at 03:21:12PM +0800, Moudy Ho wrote: >>>>>>> Add a compatible string for the COLOR block in MediaTek >>>>>>> MT8195 >>>>>>> that >>>>>>> is controlled by MDP3. >>>>>>> >>>>>>> Signed-off-by: Moudy Ho >>>>>>> --- >>>>>>> .../devicetree/bindings/display/mediatek/mediatek,color.yaml >>>>>>> >>>>>>> | 1 + >>>>>>> 1 file changed, 1 insertion(+) >>>>>>> >>>>>>> diff --git >>>>>>> a/Documentation/devicetree/bindings/display/mediatek/mediatek >>>>>>> ,col >>>>>>> or.yaml >>>>>>> b/Documentation/devicetree/bindings/display/mediatek/mediatek >>>>>>> ,col >>>>>>> or.yaml >>>>>>> index f21e44092043..b886ca0d89ea 100644 >>>>>>> --- >>>>>>> a/Documentation/devicetree/bindings/display/mediatek/mediatek >>>>>>> ,col >>>>>>> or.yaml >>>>>>> +++ >>>>>>> b/Documentation/devicetree/bindings/display/mediatek/mediatek >>>>>>> ,col >>>>>>> or.yaml >>>>>>> @@ -26,6 +26,7 @@ properties: >>>>>>> - mediatek,mt2701-disp-color >>>>>>> - mediatek,mt8167-disp-color >>>>>>> - mediatek,mt8173-disp-color >>>>>>> + - mediatek,mt8195-mdp3-color >>>>>> >>>>>> How come this one is a "mdp3" not a "disp"? >>>>> >>>>> I don't know what mdp3 means & googling gives me no answers. >>>>> What's >>>>> the >>>>> "disp" one controlled by, since it isn't controlled by mdp3? >>>>> > >>>> Mediatek's Media Data Path ver.3 (MDP3) is associated with MMSYS >>>> and >>>> acts as an independent driver that operates between VDEC and DISP. >>>> By controlling multiple components, it carries out tasks like >>>> converting color formats, resizing, and applying specific Picture >>>> Quality (PQ) effects. >>>> The driver can be found at "driver/media/platform/mediatek/mdp3". >>>> Since the same hardware components are configured in both MDP3 and >>>> DISP, considering previous discussions, I attemped to integrate >>>> into a >>>> single binding, named after the controlling user. >>> >>> I'm still kinda struggling to understand this. Do you mean that the >>> hardware can be controlled by either of the disp and mdp3 drivers, >>> and >>> a compatible containing "disp" would use one driver, and one >>> containing >>> "mdp3" would use another? >>> > >> Sorry for any confusion caused by the software information. In the >> video pipeline, after decoding, the data flows sequentially through two >> subsystems: MDP and DISP. Each subsystems has multiple IPs, with some >> serving the same functionality as COLOR mentioned here. However, these >> IPs cannot be controlled by different subsystems. Therefore, I included >> the name of the subsystem after SoC to identify the configuration's >> location. Is this approach feasible? > > I'll have to leave things to the likes of Laurent to comment here I > think. I don't understand this hardware well enough to have a useful > opinion. It would seem like a different part of the datapath is a > different device that should be documented separately, but I don't know > enough to say for sure, sorry. Hardware speaking, it's not a different device: those all reside in the same block, except they are configured to route their I/O *either* to the display pipeline, *or* to the MDP3 pipeline. I would agree though in that this could be more flexible, as in, not having a requirement to say "mdp3" or "disp", and managing the COLOR blocks generically and letting the drivers to choose the actual path transparently from what the devicetree compatible is, but there's no practical point in doing this in the end, because there is an enough number of (for example, COLOR) blocks such that one can be completely reserved to MDP3 and one completely reserved to DISP. So, we don't *need* this flexibility, but would be nice to have for different (unexistant, basically) usecases... The thing is, if we go for the maximum flexibility, the drawback is that we'd see a number of nodes like shared_block: something@somewhere { compatible = "mediatek,something"; } mdp3: dma-controller@14001000 { ...... mediatek,color = <&color0>; mediatek,stitch = <&stitch0>; mediatek,hdr = <&hdr0>; mediatek,aal = <&aal0>; .... long list of another 10 components } display: something@somewhere { ...... an even longer list than the MDP3 one } ...or perhaps even a graph, which is even longer in the end. I'm not against this kind of structure, but I wonder if it's worth it. Cheers, Angelo 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id E74F9E743F9 for ; Fri, 29 Sep 2023 08:43:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=TsbXXFug5lvGfhaiI/xvTO3qDZwxgD/MOvEngICuDeg=; b=XjcAgohJPtMGQw GUkuLLjVuA3/C3PqDfVcJSTBoMEE2KWLG9fH/7jVS/V9YJrFTH96UHgoZ9Pjm/whDwnqh4V+mL4GX HNTAM0+VbTXynYfC7e7RYG/xBb7GjAIxijwRaEEsM/34kNyuvdIj4xRMZLVl3nUWR8T5UZkQ72Z42 q+rbKN4WsUNlg4ZEseQXWSuB38WRo7KX4DWz+T6fQDm1oShem1YYRG7VQFhhKlRYXjWsFhqNcBuKX PU1FYsDKp0lPy73OZ9GPGn0FEXxMPOYvilBCwjaJ3AMmTSmfVdCVWzMaRaUOuaJrm+6iqBqonW9/G IE5WDGiwA3vBJI6oc2uA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qm95X-007OKC-33; Fri, 29 Sep 2023 08:43:07 +0000 Received: from madras.collabora.co.uk ([46.235.227.172]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qm95V-007OHx-0K; Fri, 29 Sep 2023 08:43:06 +0000 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 00D826607342; Fri, 29 Sep 2023 09:43:00 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1695976981; bh=uiFIr0QtcCv98GNZksTz1IxuKJn0A6If3Wrm+S+R9Dc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=eJoJRtp1NC059atmmhRsvEF31BihjtVtAugFx9dlHoCrFMBZh1jrGhteZOlo7RtkQ lnd8AHDTWkDdCIK+dU4OKIxtlycUe2lQzyaHoPniUsh9504Jfx5K2Q2Xo2ivAMIR5y lZ0Wgvy5icrDdyae2/OPe8IfKJm4NVH6i7Z1QfGsAo3HHSmGrpwsXVNCD1wt9pTl8W sfDdjupPGdPFFqDZcxRGfx1uIrxFP8kzYqO70uBvOtPFpvG+t9ZDwvJFv7jCFWuueV pD63I9XS/sLFkPbSWcXovtm+qQ7OQLva188CiILIbcZDUrtKapgfnyTyr0EWLfYlSD zzETDP2l5hs7A== Message-ID: <7dbadd86-f408-bc94-92fc-22f460eebb43@collabora.com> Date: Fri, 29 Sep 2023 10:42:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH v6 12/16] dt-bindings: display: mediatek: color: add compatible for MT8195 Content-Language: en-US To: Conor Dooley , =?UTF-8?B?TW91ZHkgSG8gKOS9leWul+WOnyk=?= Cc: "conor.dooley@microchip.com" , "linux-kernel@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , "robh+dt@kernel.org" , "linux-media@vger.kernel.org" , "chunkuang.hu@kernel.org" , "devicetree@vger.kernel.org" , "mchehab@kernel.org" , "daniel@ffwll.ch" , "p.zabel@pengutronix.de" , "conor+dt@kernel.org" , "dri-devel@lists.freedesktop.org" , "hverkuil-cisco@xs4all.nl" , "airlied@gmail.com" , "krzysztof.kozlowski+dt@linaro.org" , "matthias.bgg@gmail.com" , "linux-arm-kernel@lists.infradead.org" References: <20230922072116.11009-1-moudy.ho@mediatek.com> <20230922072116.11009-13-moudy.ho@mediatek.com> <20230922-zebra-modify-87ff23c70bb3@spud> <20230922-overhung-deception-e9b461ba0372@spud> <7c445195e17e15d5af5fcb30ae53f76c713e958b.camel@mediatek.com> <20230927-crunching-prancing-36fe3eb79607@wendy> <825ac03b692043d48563620ad9542a4ee43211e7.camel@mediatek.com> <20230928-keep-attractor-1e7cd0df03b2@spud> From: AngeloGioacchino Del Regno In-Reply-To: <20230928-keep-attractor-1e7cd0df03b2@spud> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230929_014305_394897_CD146A49 X-CRM114-Status: GOOD ( 29.65 ) 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-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org SWwgMjgvMDkvMjMgMTg6NDksIENvbm9yIERvb2xleSBoYSBzY3JpdHRvOgo+IE9uIFRodSwgU2Vw IDI4LCAyMDIzIGF0IDAyOjUyOjIzQU0gKzAwMDAsIE1vdWR5IEhvICjkvZXlrpfljp8pIHdyb3Rl Ogo+PiBPbiBXZWQsIDIwMjMtMDktMjcgYXQgMTA6NDcgKzAxMDAsIENvbm9yIERvb2xleSB3cm90 ZToKPj4+IE9uIFdlZCwgU2VwIDI3LCAyMDIzIGF0IDA3OjE5OjI4QU0gKzAwMDAsIE1vdWR5IEhv ICjkvZXlrpfljp8pIHdyb3RlOgo+Pj4+IE9uIEZyaSwgMjAyMy0wOS0yMiBhdCAxNjo1MSArMDEw MCwgQ29ub3IgRG9vbGV5IHdyb3RlOgo+Pj4+PiBPbiBGcmksIFNlcCAyMiwgMjAyMyBhdCAwNDo0 OToxNFBNICswMTAwLCBDb25vciBEb29sZXkgd3JvdGU6Cj4+Pj4+PiBPbiBGcmksIFNlcCAyMiwg MjAyMyBhdCAwMzoyMToxMlBNICswODAwLCBNb3VkeSBIbyB3cm90ZToKPj4+Pj4+PiBBZGQgYSBj b21wYXRpYmxlIHN0cmluZyBmb3IgdGhlIENPTE9SIGJsb2NrIGluIE1lZGlhVGVrCj4+Pj4+Pj4g TVQ4MTk1Cj4+Pj4+Pj4gdGhhdAo+Pj4+Pj4+IGlzIGNvbnRyb2xsZWQgYnkgTURQMy4KPj4+Pj4+ Pgo+Pj4+Pj4+IFNpZ25lZC1vZmYtYnk6IE1vdWR5IEhvIDxtb3VkeS5ob0BtZWRpYXRlay5jb20+ Cj4+Pj4+Pj4gLS0tCj4+Pj4+Pj4gICAuLi4vZGV2aWNldHJlZS9iaW5kaW5ncy9kaXNwbGF5L21l ZGlhdGVrL21lZGlhdGVrLGNvbG9yLnlhbWwKPj4+Pj4+PiAgICAgIAo+Pj4+Pj4+ICAgfCAxICsK Pj4+Pj4+PiAgIDEgZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKQo+Pj4+Pj4+Cj4+Pj4+Pj4g ZGlmZiAtLWdpdAo+Pj4+Pj4+IGEvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Rp c3BsYXkvbWVkaWF0ZWsvbWVkaWF0ZWsKPj4+Pj4+PiAsY29sCj4+Pj4+Pj4gb3IueWFtbAo+Pj4+ Pj4+IGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Rpc3BsYXkvbWVkaWF0ZWsv bWVkaWF0ZWsKPj4+Pj4+PiAsY29sCj4+Pj4+Pj4gb3IueWFtbAo+Pj4+Pj4+IGluZGV4IGYyMWU0 NDA5MjA0My4uYjg4NmNhMGQ4OWVhIDEwMDY0NAo+Pj4+Pj4+IC0tLQo+Pj4+Pj4+IGEvRG9jdW1l bnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Rpc3BsYXkvbWVkaWF0ZWsvbWVkaWF0ZWsKPj4+ Pj4+PiAsY29sCj4+Pj4+Pj4gb3IueWFtbAo+Pj4+Pj4+ICsrKwo+Pj4+Pj4+IGIvRG9jdW1lbnRh dGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL2Rpc3BsYXkvbWVkaWF0ZWsvbWVkaWF0ZWsKPj4+Pj4+ PiAsY29sCj4+Pj4+Pj4gb3IueWFtbAo+Pj4+Pj4+IEBAIC0yNiw2ICsyNiw3IEBAIHByb3BlcnRp ZXM6Cj4+Pj4+Pj4gICAgICAgICAgICAgLSBtZWRpYXRlayxtdDI3MDEtZGlzcC1jb2xvcgo+Pj4+ Pj4+ICAgICAgICAgICAgIC0gbWVkaWF0ZWssbXQ4MTY3LWRpc3AtY29sb3IKPj4+Pj4+PiAgICAg ICAgICAgICAtIG1lZGlhdGVrLG10ODE3My1kaXNwLWNvbG9yCj4+Pj4+Pj4gKyAgICAgICAgICAt IG1lZGlhdGVrLG10ODE5NS1tZHAzLWNvbG9yCj4+Pj4+Pgo+Pj4+Pj4gSG93IGNvbWUgdGhpcyBv bmUgaXMgYSAibWRwMyIgbm90IGEgImRpc3AiPwo+Pj4+Pgo+Pj4+PiBJIGRvbid0IGtub3cgd2hh dCBtZHAzIG1lYW5zICYgZ29vZ2xpbmcgZ2l2ZXMgbWUgbm8gYW5zd2Vycy4KPj4+Pj4gV2hhdCdz Cj4+Pj4+IHRoZQo+Pj4+PiAiZGlzcCIgb25lIGNvbnRyb2xsZWQgYnksIHNpbmNlIGl0IGlzbid0 IGNvbnRyb2xsZWQgYnkgbWRwMz8KPj4+Pj4KPiAKPj4+PiBNZWRpYXRlaydzIE1lZGlhIERhdGEg UGF0aCB2ZXIuMyAoTURQMykgaXMgYXNzb2NpYXRlZCB3aXRoIE1NU1lTCj4+Pj4gYW5kCj4+Pj4g YWN0cyBhcyBhbiBpbmRlcGVuZGVudCBkcml2ZXIgdGhhdCBvcGVyYXRlcyBiZXR3ZWVuIFZERUMg YW5kIERJU1AuCj4+Pj4gQnkgY29udHJvbGxpbmcgbXVsdGlwbGUgY29tcG9uZW50cywgaXQgY2Fy cmllcyBvdXQgdGFza3MgbGlrZQo+Pj4+IGNvbnZlcnRpbmcgY29sb3IgZm9ybWF0cywgcmVzaXpp bmcsIGFuZCBhcHBseWluZyBzcGVjaWZpYyBQaWN0dXJlCj4+Pj4gUXVhbGl0eSAoUFEpIGVmZmVj dHMuCj4+Pj4gVGhlIGRyaXZlciBjYW4gYmUgZm91bmQgYXQgImRyaXZlci9tZWRpYS9wbGF0Zm9y bS9tZWRpYXRlay9tZHAzIi4KPj4+PiBTaW5jZSB0aGUgc2FtZSBoYXJkd2FyZSBjb21wb25lbnRz IGFyZSBjb25maWd1cmVkIGluIGJvdGggTURQMyBhbmQKPj4+PiBESVNQLCBjb25zaWRlcmluZyBw cmV2aW91cyBkaXNjdXNzaW9ucywgSSBhdHRlbXBlZCB0byBpbnRlZ3JhdGUKPj4+PiBpbnRvIGEK Pj4+PiBzaW5nbGUgYmluZGluZywgbmFtZWQgYWZ0ZXIgdGhlIGNvbnRyb2xsaW5nIHVzZXIuCj4+ Pgo+Pj4gSSdtIHN0aWxsIGtpbmRhIHN0cnVnZ2xpbmcgdG8gdW5kZXJzdGFuZCB0aGlzLiBEbyB5 b3UgbWVhbiB0aGF0IHRoZQo+Pj4gaGFyZHdhcmUgY2FuIGJlIGNvbnRyb2xsZWQgYnkgZWl0aGVy IG9mIHRoZSBkaXNwIGFuZCBtZHAzIGRyaXZlcnMsCj4+PiBhbmQKPj4+IGEgY29tcGF0aWJsZSBj b250YWluaW5nICJkaXNwIiB3b3VsZCB1c2Ugb25lIGRyaXZlciwgYW5kIG9uZQo+Pj4gY29udGFp bmluZwo+Pj4gIm1kcDMiIHdvdWxkIHVzZSBhbm90aGVyPwo+Pj4KPiAKPj4gU29ycnkgZm9yIGFu eSBjb25mdXNpb24gY2F1c2VkIGJ5IHRoZSBzb2Z0d2FyZSBpbmZvcm1hdGlvbi4gSW4gdGhlCj4+ IHZpZGVvIHBpcGVsaW5lLCBhZnRlciBkZWNvZGluZywgdGhlIGRhdGEgZmxvd3Mgc2VxdWVudGlh bGx5IHRocm91Z2ggdHdvCj4+IHN1YnN5c3RlbXM6IE1EUCBhbmQgRElTUC4gRWFjaCBzdWJzeXN0 ZW1zIGhhcyBtdWx0aXBsZSBJUHMsIHdpdGggc29tZQo+PiBzZXJ2aW5nIHRoZSBzYW1lIGZ1bmN0 aW9uYWxpdHkgYXMgQ09MT1IgbWVudGlvbmVkIGhlcmUuIEhvd2V2ZXIsIHRoZXNlCj4+IElQcyBj YW5ub3QgYmUgY29udHJvbGxlZCBieSBkaWZmZXJlbnQgc3Vic3lzdGVtcy4gVGhlcmVmb3JlLCBJ IGluY2x1ZGVkCj4+IHRoZSBuYW1lIG9mIHRoZSBzdWJzeXN0ZW0gYWZ0ZXIgU29DIHRvIGlkZW50 aWZ5IHRoZSBjb25maWd1cmF0aW9uJ3MKPj4gbG9jYXRpb24uIElzIHRoaXMgYXBwcm9hY2ggZmVh c2libGU/Cj4gCj4gSSdsbCBoYXZlIHRvIGxlYXZlIHRoaW5ncyB0byB0aGUgbGlrZXMgb2YgTGF1 cmVudCB0byBjb21tZW50IGhlcmUgSQo+IHRoaW5rLiBJIGRvbid0IHVuZGVyc3RhbmQgdGhpcyBo YXJkd2FyZSB3ZWxsIGVub3VnaCB0byBoYXZlIGEgdXNlZnVsCj4gb3Bpbmlvbi4gSXQgd291bGQg c2VlbSBsaWtlIGEgZGlmZmVyZW50IHBhcnQgb2YgdGhlIGRhdGFwYXRoIGlzIGEKPiBkaWZmZXJl bnQgZGV2aWNlIHRoYXQgc2hvdWxkIGJlIGRvY3VtZW50ZWQgc2VwYXJhdGVseSwgYnV0IEkgZG9u J3Qga25vdwo+IGVub3VnaCB0byBzYXkgZm9yIHN1cmUsIHNvcnJ5LgoKSGFyZHdhcmUgc3BlYWtp bmcsIGl0J3Mgbm90IGEgZGlmZmVyZW50IGRldmljZTogdGhvc2UgYWxsIHJlc2lkZSBpbiB0aGUK c2FtZSBibG9jaywgZXhjZXB0IHRoZXkgYXJlIGNvbmZpZ3VyZWQgdG8gcm91dGUgdGhlaXIgSS9P ICplaXRoZXIqIHRvIHRoZQpkaXNwbGF5IHBpcGVsaW5lLCAqb3IqIHRvIHRoZSBNRFAzIHBpcGVs aW5lLgoKSSB3b3VsZCBhZ3JlZSB0aG91Z2ggaW4gdGhhdCB0aGlzIGNvdWxkIGJlIG1vcmUgZmxl eGlibGUsIGFzIGluLCBub3QKaGF2aW5nIGEgcmVxdWlyZW1lbnQgdG8gc2F5ICJtZHAzIiBvciAi ZGlzcCIsIGFuZCBtYW5hZ2luZyB0aGUgQ09MT1IKYmxvY2tzIGdlbmVyaWNhbGx5IGFuZCBsZXR0 aW5nIHRoZSBkcml2ZXJzIHRvIGNob29zZSB0aGUgYWN0dWFsIHBhdGgKdHJhbnNwYXJlbnRseSBm cm9tIHdoYXQgdGhlIGRldmljZXRyZWUgY29tcGF0aWJsZSBpcywgYnV0IHRoZXJlJ3Mgbm8KcHJh Y3RpY2FsIHBvaW50IGluIGRvaW5nIHRoaXMgaW4gdGhlIGVuZCwgYmVjYXVzZSB0aGVyZSBpcyBh biBlbm91Z2gKbnVtYmVyIG9mIChmb3IgZXhhbXBsZSwgQ09MT1IpIGJsb2NrcyBzdWNoIHRoYXQg b25lIGNhbiBiZSBjb21wbGV0ZWx5CnJlc2VydmVkIHRvIE1EUDMgYW5kIG9uZSBjb21wbGV0ZWx5 IHJlc2VydmVkIHRvIERJU1AuCgpTbywgd2UgZG9uJ3QgKm5lZWQqIHRoaXMgZmxleGliaWxpdHks IGJ1dCB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgZm9yCmRpZmZlcmVudCAodW5leGlzdGFudCwgYmFz aWNhbGx5KSB1c2VjYXNlcy4uLgoKVGhlIHRoaW5nIGlzLCBpZiB3ZSBnbyBmb3IgdGhlIG1heGlt dW0gZmxleGliaWxpdHksIHRoZSBkcmF3YmFjayBpcwp0aGF0IHdlJ2Qgc2VlIGEgbnVtYmVyIG9m IG5vZGVzIGxpa2UKCnNoYXJlZF9ibG9jazogc29tZXRoaW5nQHNvbWV3aGVyZSB7Cgljb21wYXRp YmxlID0gIm1lZGlhdGVrLHNvbWV0aGluZyI7Cn0KCm1kcDM6IGRtYS1jb250cm9sbGVyQDE0MDAx MDAwIHsKCS4uLi4uLgoJbWVkaWF0ZWssY29sb3IgPSA8JmNvbG9yMD47CgltZWRpYXRlayxzdGl0 Y2ggPSA8JnN0aXRjaDA+OwoJbWVkaWF0ZWssaGRyID0gPCZoZHIwPjsKCW1lZGlhdGVrLGFhbCA9 IDwmYWFsMD47CgkuLi4uCglsb25nIGxpc3Qgb2YgYW5vdGhlciAxMCBjb21wb25lbnRzCn0KCmRp c3BsYXk6IHNvbWV0aGluZ0Bzb21ld2hlcmUgewoJLi4uLi4uCglhbiBldmVuIGxvbmdlciBsaXN0 IHRoYW4gdGhlIE1EUDMgb25lCn0KCi4uLm9yIHBlcmhhcHMgZXZlbiBhIGdyYXBoLCB3aGljaCBp cyBldmVuIGxvbmdlciBpbiB0aGUgZW5kLgoKSSdtIG5vdCBhZ2FpbnN0IHRoaXMga2luZCBvZiBz dHJ1Y3R1cmUsIGJ1dCBJIHdvbmRlciBpZiBpdCdzIHdvcnRoIGl0LgoKQ2hlZXJzLApBbmdlbG8K Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFy bS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9y ZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1r ZXJuZWwK 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 4658DE743F9 for ; Fri, 29 Sep 2023 08:43:06 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8AA1810E6EF; Fri, 29 Sep 2023 08:43:05 +0000 (UTC) Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5863210E6E1 for ; Fri, 29 Sep 2023 08:43:03 +0000 (UTC) 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 00D826607342; Fri, 29 Sep 2023 09:43:00 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1695976981; bh=uiFIr0QtcCv98GNZksTz1IxuKJn0A6If3Wrm+S+R9Dc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=eJoJRtp1NC059atmmhRsvEF31BihjtVtAugFx9dlHoCrFMBZh1jrGhteZOlo7RtkQ lnd8AHDTWkDdCIK+dU4OKIxtlycUe2lQzyaHoPniUsh9504Jfx5K2Q2Xo2ivAMIR5y lZ0Wgvy5icrDdyae2/OPe8IfKJm4NVH6i7Z1QfGsAo3HHSmGrpwsXVNCD1wt9pTl8W sfDdjupPGdPFFqDZcxRGfx1uIrxFP8kzYqO70uBvOtPFpvG+t9ZDwvJFv7jCFWuueV pD63I9XS/sLFkPbSWcXovtm+qQ7OQLva188CiILIbcZDUrtKapgfnyTyr0EWLfYlSD zzETDP2l5hs7A== Message-ID: <7dbadd86-f408-bc94-92fc-22f460eebb43@collabora.com> Date: Fri, 29 Sep 2023 10:42:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: [PATCH v6 12/16] dt-bindings: display: mediatek: color: add compatible for MT8195 Content-Language: en-US To: Conor Dooley , =?UTF-8?B?TW91ZHkgSG8gKOS9leWul+WOnyk=?= References: <20230922072116.11009-1-moudy.ho@mediatek.com> <20230922072116.11009-13-moudy.ho@mediatek.com> <20230922-zebra-modify-87ff23c70bb3@spud> <20230922-overhung-deception-e9b461ba0372@spud> <7c445195e17e15d5af5fcb30ae53f76c713e958b.camel@mediatek.com> <20230927-crunching-prancing-36fe3eb79607@wendy> <825ac03b692043d48563620ad9542a4ee43211e7.camel@mediatek.com> <20230928-keep-attractor-1e7cd0df03b2@spud> From: AngeloGioacchino Del Regno In-Reply-To: <20230928-keep-attractor-1e7cd0df03b2@spud> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: , Cc: "chunkuang.hu@kernel.org" , "conor+dt@kernel.org" , "krzysztof.kozlowski+dt@linaro.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dri-devel@lists.freedesktop.org" , "matthias.bgg@gmail.com" , "conor.dooley@microchip.com" , "robh+dt@kernel.org" , "linux-mediatek@lists.infradead.org" , "hverkuil-cisco@xs4all.nl" , "mchehab@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-media@vger.kernel.org" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Il 28/09/23 18:49, Conor Dooley ha scritto: > On Thu, Sep 28, 2023 at 02:52:23AM +0000, Moudy Ho (何宗原) wrote: >> On Wed, 2023-09-27 at 10:47 +0100, Conor Dooley wrote: >>> On Wed, Sep 27, 2023 at 07:19:28AM +0000, Moudy Ho (何宗原) wrote: >>>> On Fri, 2023-09-22 at 16:51 +0100, Conor Dooley wrote: >>>>> On Fri, Sep 22, 2023 at 04:49:14PM +0100, Conor Dooley wrote: >>>>>> On Fri, Sep 22, 2023 at 03:21:12PM +0800, Moudy Ho wrote: >>>>>>> Add a compatible string for the COLOR block in MediaTek >>>>>>> MT8195 >>>>>>> that >>>>>>> is controlled by MDP3. >>>>>>> >>>>>>> Signed-off-by: Moudy Ho >>>>>>> --- >>>>>>> .../devicetree/bindings/display/mediatek/mediatek,color.yaml >>>>>>> >>>>>>> | 1 + >>>>>>> 1 file changed, 1 insertion(+) >>>>>>> >>>>>>> diff --git >>>>>>> a/Documentation/devicetree/bindings/display/mediatek/mediatek >>>>>>> ,col >>>>>>> or.yaml >>>>>>> b/Documentation/devicetree/bindings/display/mediatek/mediatek >>>>>>> ,col >>>>>>> or.yaml >>>>>>> index f21e44092043..b886ca0d89ea 100644 >>>>>>> --- >>>>>>> a/Documentation/devicetree/bindings/display/mediatek/mediatek >>>>>>> ,col >>>>>>> or.yaml >>>>>>> +++ >>>>>>> b/Documentation/devicetree/bindings/display/mediatek/mediatek >>>>>>> ,col >>>>>>> or.yaml >>>>>>> @@ -26,6 +26,7 @@ properties: >>>>>>> - mediatek,mt2701-disp-color >>>>>>> - mediatek,mt8167-disp-color >>>>>>> - mediatek,mt8173-disp-color >>>>>>> + - mediatek,mt8195-mdp3-color >>>>>> >>>>>> How come this one is a "mdp3" not a "disp"? >>>>> >>>>> I don't know what mdp3 means & googling gives me no answers. >>>>> What's >>>>> the >>>>> "disp" one controlled by, since it isn't controlled by mdp3? >>>>> > >>>> Mediatek's Media Data Path ver.3 (MDP3) is associated with MMSYS >>>> and >>>> acts as an independent driver that operates between VDEC and DISP. >>>> By controlling multiple components, it carries out tasks like >>>> converting color formats, resizing, and applying specific Picture >>>> Quality (PQ) effects. >>>> The driver can be found at "driver/media/platform/mediatek/mdp3". >>>> Since the same hardware components are configured in both MDP3 and >>>> DISP, considering previous discussions, I attemped to integrate >>>> into a >>>> single binding, named after the controlling user. >>> >>> I'm still kinda struggling to understand this. Do you mean that the >>> hardware can be controlled by either of the disp and mdp3 drivers, >>> and >>> a compatible containing "disp" would use one driver, and one >>> containing >>> "mdp3" would use another? >>> > >> Sorry for any confusion caused by the software information. In the >> video pipeline, after decoding, the data flows sequentially through two >> subsystems: MDP and DISP. Each subsystems has multiple IPs, with some >> serving the same functionality as COLOR mentioned here. However, these >> IPs cannot be controlled by different subsystems. Therefore, I included >> the name of the subsystem after SoC to identify the configuration's >> location. Is this approach feasible? > > I'll have to leave things to the likes of Laurent to comment here I > think. I don't understand this hardware well enough to have a useful > opinion. It would seem like a different part of the datapath is a > different device that should be documented separately, but I don't know > enough to say for sure, sorry. Hardware speaking, it's not a different device: those all reside in the same block, except they are configured to route their I/O *either* to the display pipeline, *or* to the MDP3 pipeline. I would agree though in that this could be more flexible, as in, not having a requirement to say "mdp3" or "disp", and managing the COLOR blocks generically and letting the drivers to choose the actual path transparently from what the devicetree compatible is, but there's no practical point in doing this in the end, because there is an enough number of (for example, COLOR) blocks such that one can be completely reserved to MDP3 and one completely reserved to DISP. So, we don't *need* this flexibility, but would be nice to have for different (unexistant, basically) usecases... The thing is, if we go for the maximum flexibility, the drawback is that we'd see a number of nodes like shared_block: something@somewhere { compatible = "mediatek,something"; } mdp3: dma-controller@14001000 { ...... mediatek,color = <&color0>; mediatek,stitch = <&stitch0>; mediatek,hdr = <&hdr0>; mediatek,aal = <&aal0>; .... long list of another 10 components } display: something@somewhere { ...... an even longer list than the MDP3 one } ...or perhaps even a graph, which is even longer in the end. I'm not against this kind of structure, but I wonder if it's worth it. Cheers, Angelo