On 12/7/21 1:46 PM, Ezequiel Garcia wrote: > Hi everyone, > > On Tue, 7 Dec 2021 at 09:37, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >> >> On 9/5/21 6:23 PM, houlong wei wrote: >>> Hi Ezequiel, >>> >>> Thank you for your attention to this series of patches. I answer partial of your questions below. >>> Regards, >>> Houlong >>> >>> On Sat, 2021-09-04 at 20:34 +0800, Ezequiel Garcia wrote: >>>> Hi Eizan, >>>> >>>> Sorry for seeing this series so late. >>>> >>>> On Wed, 25 Aug 2021 at 03:35, Eizan Miyamoto <eizan@xxxxxxxxxxxx> >>>> wrote: >>>>> >>>>> Broadly, this patch (1) adds a driver for various MTK MDP >>>>> components to >>>>> go alongside the main MTK MDP driver, and (2) hooks them all >>>>> together >>>>> using the component framework. >>>>> >>>>> (1) Up until now, the MTK MDP driver controls 8 devices in the >>>>> device >>>>> tree on its own. When running tests for the hardware video decoder, >>>>> we >>>>> found that the iommus and LARBs were not being properly configured. >>>> >>>> Why were not being properly configured? What was the problem? >>>> Why not fixing that instead? >>>> >>>> Does this mean the driver is currently broken and unusable? >>> >>> This series of patches are supplements to another series, please refer >>> to >>> https://patchwork.kernel.org/project/linux-mediatek/list/?series=515129c >>> , which add device link between the mtk-iommu consumer and the mtk-larb >>> devices. Without that series of patches, the mtk-mdp driver can work >>> well so far. >>> But with that series, it seems the device link only can be established >>> for the device which is registered as a platform driver. That's why >>> Eizan adds this series of patches to make all mdp components to be >>> registered as platform drivers. >> >> Hold on, so this means that if that iommu device-link series is merged, >> then the mtk-mdp driver breaks? I posted a PR for that iommu series, but >> I've just withdrawn that PR until this issue is clarified. >> >> Is it only mtk-mdp that is affected by this iommu device-link series, or >> others as well? >> > > Like I said before, I think it's a mistake to introduce the component > framework in V4L2. This whole idea looks like a hack to me. > > If we merge this, then we validate using the component framework > as a way to avoid fixing things properly. I agree with Ezequiel. Hans
