On 28/09/2022 09:58, AngeloGioacchino Del Regno wrote: > 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? video-codec-lat sounds better, but I am not sure if it is worth the churn, so I am fine with both. Best regards, Krzysztof
