Received: by 2002:a05:7412:a9a2:b0:e2:908c:2ebd with SMTP id o34csp2737575rdh; Mon, 30 Oct 2023 06:26:30 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEQoDMyIeHQRg5lxPrMdMVpiKilngQaI8buMij6CDLmKgNO4jcq/vaT2pfEiLbw1oERqbYt X-Received: by 2002:a05:6a00:2b8b:b0:68f:c1e0:a2c4 with SMTP id dv11-20020a056a002b8b00b0068fc1e0a2c4mr15519660pfb.3.1698672390510; Mon, 30 Oct 2023 06:26:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698672390; cv=none; d=google.com; s=arc-20160816; b=bUMpO5Lywgtg/8hl9KmOktwQah0Nz7XPvzNJJEujImcvEiKz1cku5uFM0HBgEsrhr5 vojRj6LmITaoRkzpt0eqSdvX3MxkGPTtombAKa5zgqK2dfhlsYjrVOr+dd/f8oOuM9KD RH3Tlg2RmWIWuoyblf4xnF6bbaXyQtPC+Dblj8pcnuWDHCjQuX0xMH1FDN32hDID3FyW ilW2y8piBwgJ3EF2A8SwIhNMIdBf+kckFdaUdNj02eEhXfyVQEILuwYZY67opPmCxL4i 3cFwTAguJberLOfI4jTSxIJo+QP7MyAA73Nyx/GwrKXrCYTSwJN6f9pH5MgPQbDoYepV c4Gw== 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 :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id; bh=6r/mLaJMrSVibxDKy+d4xuVF7fmDwb/WJ3VoWjStRrE=; fh=J3rSMq2MhNzw4MeKUUoMMXOZ4B7HCQwnn+D7df0IsuI=; b=G02RLuS/Qc0hoIIeIh9Z73zY3E19eCRj3KvWfz2njp5B5oBtls7GuK32ABK6Ijfc+r onpWBQYHtS0c776TcxL/hvLeIO6nL8N1/Dptjy8lUaVi/L/HEKf74UGjQw1+KM7/N28U mmUTev4jRs3YGwiyqUdgnHwYT5UVop6h9cGAZgPxoc/NdvwOX7hlidcEPQb8IQqkwtgJ HusMtd2EOv/Wmuno+VfhLLSbrmemSFtUeLBMcUqYDswDjDk3xN8xDGNzwuLcbLZbon66 K3SP7gGWNAhCdswhZxS/IpmAt4FIRFU9mC5Toba+8GfVt/DP8vX8+PQihRJMQceouClh at+g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id z6-20020aa78886000000b0068e3efffe2csi4974745pfe.243.2023.10.30.06.26.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Oct 2023 06:26:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 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 howler.vger.email (Postfix) with ESMTP id 19EE5807D8D8; Mon, 30 Oct 2023 06:26:27 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233400AbjJ3N0N (ORCPT + 99 others); Mon, 30 Oct 2023 09:26:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232760AbjJ3N0M (ORCPT ); Mon, 30 Oct 2023 09:26:12 -0400 Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6DC5FD6 for ; Mon, 30 Oct 2023 06:26:07 -0700 (PDT) Received: from loongson.cn (unknown [10.20.42.43]) by gateway (Coremail) with SMTP id _____8CxNvHrrj9lTL41AA--.39219S3; Mon, 30 Oct 2023 21:26:03 +0800 (CST) Received: from [10.20.42.43] (unknown [10.20.42.43]) by localhost.localdomain (Coremail) with SMTP id AQAAf8CxeuTerj9lHgA3AA--.54640S3; Mon, 30 Oct 2023 21:26:00 +0800 (CST) Message-ID: Date: Mon, 30 Oct 2023 21:25:50 +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 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> Content-Language: en-US From: Sui Jingfeng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: AQAAf8CxeuTerj9lHgA3AA--.54640S3 X-CM-SenderInfo: xvxlyxpqjiv03j6o00pqjv00gofq/ X-Coremail-Antispam: 1Uk129KBj93XoW3JF1kKF13GFy3WFykZw4DWrX_yoW7Cr4fpa 17KFyYyrWkXrsFyrZIy3WUCFyrA393JFWfGrsxG3sY9rn8u34Iyr15KFW5Wry7Wr13Ca12 qrWDWFW7WF1jyagCm3ZEXasCq-sJn29KB7ZKAUJUUUU7529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUU9Yb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1Y6r17M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AK xVW8Jr0_Cr1UM2kKe7AKxVWUXVWUAwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07 AIYIkI8VC2zVCFFI0UMc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWU AVWUtwAv7VC2z280aVAFwI0_Cr0_Gr1UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwI xGrwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwCFI7km07C267AKxVWU XVWUAwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67 kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY 6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0x vEx4A2jsIE14v26F4j6r4UJwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIev Ja73UjIFyTuYvjxU7G-eUUUUU 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 howler.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 (howler.vger.email [0.0.0.0]); Mon, 30 Oct 2023 06:26:27 -0700 (PDT) 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, and in the end we still solve a easy problem by workaround. 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) It is not totally duplicating, I have rewrite part of them. 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. 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 >