Received: by 2002:a05:7412:a9a2:b0:e2:908c:2ebd with SMTP id o34csp2776392rdh; Mon, 30 Oct 2023 07:26:47 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG69h/JWLU0fOOgZvEr6B72zCsCmNKJJDnVSWO9VUBW3ajLFFefn7heCiuxtWsIIHjYsREp X-Received: by 2002:a17:90a:fd8e:b0:27d:1c70:23d4 with SMTP id cx14-20020a17090afd8e00b0027d1c7023d4mr6577533pjb.44.1698676007439; Mon, 30 Oct 2023 07:26:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698676007; cv=none; d=google.com; s=arc-20160816; b=SZUoHSaOUdPEAfijDGN+DuNvZ7LL2XYxxBhDoA6t283euhl3s9PmXFV/sqzkCSNEnj LZsSSc5WiZVip59+KWMHErD8YG0Up4hmDd4hd/jJKMpjiEakVf/IAWx+fvtacdfq5fIi KZgYWYVFgb4FSMNBkOnTtRGHelqIXsF9ykX6cSbk5ttkduQO9+tL4hOGc1yQ0K8RbqkF laDu46nhybMiP0QRY/Mhcv1MzJZGaSSf/PJR40fakbCFWagGLCNpSg0JacmDcRCq7SVk gN9EnU2QyUCA9QFsbQTV0niRorRHojPxTd7S+TPlLMmBhtKSYe06Ti3l+EPYwdS0bklV UuEA== 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; bh=cdoTbgjTveTZAa2A1X+vzenSozOgs151EUY6u22NS04=; fh=J3rSMq2MhNzw4MeKUUoMMXOZ4B7HCQwnn+D7df0IsuI=; b=Gt8Lo+fdyHkX3BR9Xce22TO/NHwLAONL03ChcIOxat1voLu7OkmS1AoHQY97P95JU8 A06lQOKUaYEF9nVTijqYXgChyi3ax0Lkr7hhFDgX4Pf5zkZ3L4UaXdy8xOepiEV7F0y+ jQGzMa0scyFkU1B7Mw4rcxPErkKQjxplPHrOeuZQ7b9IQqXv//REod06aeevabK+PUH6 5XEhMc7kkmvdb98mJZPD0J7uGmkbNfi8pdhiIoCfjrz6VJQu33zaUZhW5NQ5mavNDxL0 vtzWqLntQ6RIL1Cxua/2I2uSagDskpC9d+NojKhMlFnz9XiUEAKSXwi9zfPBMrAFIcxY Xw2w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id my4-20020a17090b4c8400b00279020d1fb0si5057340pjb.129.2023.10.30.07.26.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Oct 2023 07:26:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id D9158805D6C5; Mon, 30 Oct 2023 07:26:43 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233602AbjJ3O0c (ORCPT + 99 others); Mon, 30 Oct 2023 10:26:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233436AbjJ3O0P (ORCPT ); Mon, 30 Oct 2023 10:26:15 -0400 Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C19AFD55 for ; Mon, 30 Oct 2023 07:25:52 -0700 (PDT) Received: from loongson.cn (unknown [10.20.42.43]) by gateway (Coremail) with SMTP id _____8Dx_+vuvD9l9MA1AA--.38290S3; Mon, 30 Oct 2023 22:25:50 +0800 (CST) Received: from [10.20.42.43] (unknown [10.20.42.43]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Bxni_pvD9lzAU3AA--.52834S3; Mon, 30 Oct 2023 22:25:47 +0800 (CST) Message-ID: <20cd9518-fee4-4a99-86f2-a5eea9abaa57@loongson.cn> Date: Mon, 30 Oct 2023 22:25:46 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/8] drm/loongson: Introduce a drm bridge driver for it66121 HDMI transmitter Content-Language: en-US To: Dmitry Baryshkov Cc: Maxime Ripard , Thomas Zimmermann , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org References: <20231029194607.379459-1-suijingfeng@loongson.cn> <20231029194607.379459-3-suijingfeng@loongson.cn> <3ccb9600-6990-4ec7-81de-0d7b4e1294eb@loongson.cn> From: Sui Jingfeng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf8Bxni_pvD9lzAU3AA--.52834S3 X-CM-SenderInfo: xvxlyxpqjiv03j6o00pqjv00gofq/ X-Coremail-Antispam: 1Uk129KBj93XoW3JF4UJr45GrW3Kw4xXF45XFc_yoWxtF43pF 4UKa4akrWDJr42y3yavw18CFyYy393JrWrWrnxG34F9r90934Iyr1xtFW5WF9rWr13Ca1j vrWDuFWxWF10yagCm3ZEXasCq-sJn29KB7ZKAUJUUUU5529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUvIb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r106r15M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx 1l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1Y6r17McIj6I8E87Iv 67AKxVWxJVW8Jr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxAIw28IcxkI7V AKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMxCIbckI1I0E14v26r126r1DMI8I3I0E5I8C rVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtw CIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x02 67AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Cr 0_Gr1UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07UM CJPUUUUU= X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Mon, 30 Oct 2023 07:26:44 -0700 (PDT) Hi, On 2023/10/30 21:48, Dmitry Baryshkov wrote: > On Mon, 30 Oct 2023 at 15:26, Sui Jingfeng wrote: >> Hi, >> >> >> On 2023/10/30 18:01, Dmitry Baryshkov wrote: >>> On Mon, 30 Oct 2023 at 11:42, Sui Jingfeng wrote: >>>> Hi, >>>> >>>> >>>> On 2023/10/30 06:53, Dmitry Baryshkov wrote: >>>>> On Sun, 29 Oct 2023 at 21:46, Sui Jingfeng wrote: >>>>>> The IT66121 is a DVO to HDMI converter, LS3A5000+LS7A1000 ML5A_MB use this >>>>>> chip to support HDMI output. Thus add a drm bridge based driver for it. >>>>>> This patch is developed with drivers/gpu/drm/bridge/ite-it66121.c as base. >>>>> Please use the original bridge driver instead of adding a new one. >>>> I'm agree with the spirit of code sharing, but this is nearly impossible for non-DT system. >>>> >>>> Because the original bridge driver(say it66121.ko) is fully dependent on the DT. >>> I can not agree here. It doesn't depend on DT. It has fully populated >>> i2c_device_id structures, so it will work with bare I2C buses. >>> Most likely you will have to change of calls into fwnode calls, that's it. >>> >>>> UEFI+ACPI based system can not use with it. >>>> >>>> Our I2C adapter is created by the drm/loongson.ko on the runtime. >>>> The potential problem is that *cyclic dependency* ! >>>> >>>> I2C adapter driver is depend on drm/loongson >>>> drm/loongson depend on drm bridge driver (say it66121.ko) >>>> drm bridge driver (say it66121.ko) depend on I2C adapter to setup. >>>> >>>> This plus the defer probe mechanism is totally a trap, >>>> incurring troubles and don't work. >>> Welcome. We had this kind of issue for DP AUX buses. >>> >>> I can suggest the following approach: >>> - In the root probe function you can create an i2c bus and populate it >>> with the i2c devices. >>> - I have not checked whether you use components or not. If not, please >>> use an auxiliary or a platform device for the main DRM functionality. >>> - In the subdevice probe / bind function you check for the next >>> bridge. Then you get one of the following:drm_bridge pointer, >>> -EPROBE_DEFER, or any other error case. Your driver can react >>> accordingly. >> I have similar way to solve this problem, and I have solved it one and a half years ago. >> See [1] for a reference. >> >> [1] https://patchwork.freedesktop.org/patch/478998/?series=99512&rev=11 >> >> When the PCI device get probed, we create the I2C bus first. >> This ensure that when drm/lsdc.ko get loaded, the I2C bus is presence >> and ready to be get by the drm_bridge driver. >> This is basically a PCI-to-GPIO-emulated-I2C adapter, >> then wait the display bridges driver get loaded and set up. >> >> I also need to create a virtual platform device for the display controller. >> which allow the drm drivers instance for this virtual platform device >> be able to probed due to defer probe mechanism. >> >> This solution made the framework of my driver distortion severely, > I don't think I could catch this phrase. Did you see distortions on the screen? I means that it destroy the my drm driver's framework. I means that we are all-in-one driver. The solution you mentioned have side effect also. That is because user-space will open the PCI device first, not your created virtual platform device. >> and in the end we still solve a easy problem by workaround. > No workarounds for the kernel subsystems are allowed. I means that the idea(solution) you told me is still a workaround. bring no benifits to the drm driver itself. >> I know how to use the component framework also, but the component framework just >> a wrapper. Similar with above approach, it brings no gains in the end. >> It does not make this driver better. I got trapped one years ago, >> and I don't want to got trapped another time. >> And I know how solve such a problem by workaround, but that's not worthy for the effort. >> >> I think my approach provide a solution, while still keep the bridges drivers >> to a modular at the same time. Despite simple, it indeed solve the problem. >> It simple because of explicit control of the loading order by myself, not by >> rely on the framework or something else (say component) > PCI media drivers have had this issue for ages. And all of them found > a way to work. I have said that PCI KMS display drivers is different,  because of user space open the PCI device. >> It is not totally duplicating, I have rewrite part of them. > This is even worse. Now one can not apply fixes to the second one. I don't need to either, I want to maintain this by myself. >> You can compare >> to see what I'm changed. It is just that it66162 was upstream-ed earlier than >> our solution. But I also have write display drivers for lt8618 and lt8619 >> completely by myself. >> >> >> Even though our local drm bridges driver will not be able to enjoy the updates. >> We will accept such a results(or pain). I can maintain our local drm bridges >> drivers by myself. > What happens if anybody wants to reuse your bridge driver for their > own platform? Copy and modify. > Linux kernel uses driver model and frameworks to improve code sharing, > not to reduce it. Well I don't think my patch actually reduce something. Please see i915, amdgpu, radeon and nouveau. Non of them use the DRM bridge drivers. It is just that the various DRM bridge drivers are not suitable to use for my driver. >> Sorry, on this technique point, we will not follow your idea. >> I'm sure that my approach is toward to right direction for our device at now. >> If someone invent a better solution to handle this problem, which make the >> various drm bridges drivers usable out of box, then I will follow and cooperate >> to test. >> >> >>> Basically duplicating the existing driver code is not really a way to >>> go. Consider somebody adding a new feature or fixing a bug in your >>> driver copy. Then they have to check if the fix applies to the driver >>> at drivers/gpu/drm/bridge/ite-it66121.c. And vice versa. After fixing >>> an issue in the standard driver one has to keep in mind to check your >>> private copy. >>> >>> So, please, use the OF code as an inspiration and register all your >>> devices in the device tree. Yes, this requires some effort from your >>> side. Yes, this pays off in the longer distance. >>> >>>>> If >>>>> it needs to be changed in any way, please help everyone else by >>>>> improving it instead of introducing new driver. >>>>> >>>>>> Signed-off-by: Sui Jingfeng >>>>>> --- >>>>>> drivers/gpu/drm/loongson/Kconfig | 1 + >>>>>> drivers/gpu/drm/loongson/Makefile | 2 + >>>>>> drivers/gpu/drm/loongson/ite_it66121.c | 749 ++++++++++++++++++++ >>>>>> drivers/gpu/drm/loongson/ite_it66121.h | 19 + >>>>>> drivers/gpu/drm/loongson/ite_it66121_regs.h | 268 +++++++ >>>>>> 5 files changed, 1039 insertions(+) >>>>>> create mode 100644 drivers/gpu/drm/loongson/ite_it66121.c >>>>>> create mode 100644 drivers/gpu/drm/loongson/ite_it66121.h >>>>>> create mode 100644 drivers/gpu/drm/loongson/ite_it66121_regs.h >