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 X-Spam-Level: X-Spam-Status: No, score=-14.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0DB8AC43461 for ; Thu, 17 Sep 2020 07:14:48 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4AC952083B for ; Thu, 17 Sep 2020 07:14:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mQaKaYX3"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=baylibre-com.20150623.gappssmtp.com header.i=@baylibre-com.20150623.gappssmtp.com header.b="fThCpk5D" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4AC952083B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe :List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=5tS1knLW3UiemuWknn92zdJwYZbOFLQd3JWMGOSulBs=; b=mQaKaYX3t8+GGCCybPJYcg7ATq A3QLmmvlueXicV4BZyr9M3+G63+LPAjYmoHckzI1DFwjafOD+Mf9uufxWo1D98W1BH5a6F6K3mOTA 577kAdVINABF9rM6tMHkv5lo90O633vun12ZQh5AngePApYsrKQJPRQh+CGsHB1zCV8PqW77LxyKt NFw86cKtpubAMQLTC8Z/3tG69BE+920cGhLMz9k3JjqPr+T5C/SAnVcCXWdpbQAWjpYQirkk+KLWo lGXr5KlM5YQTR4VlyE6zfDSkXW6iMMqDLjI7Ci2OK3b6gymOBYiPPv+yNqVKd4/rPos28KIXP+PD6 GT1E9myA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIo7r-0003Sb-R4; Thu, 17 Sep 2020 07:14:39 +0000 Received: from mail-wm1-x342.google.com ([2a00:1450:4864:20::342]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIo7o-0003RR-4Y for linux-amlogic@lists.infradead.org; Thu, 17 Sep 2020 07:14:38 +0000 Received: by mail-wm1-x342.google.com with SMTP id x23so875909wmi.3 for ; Thu, 17 Sep 2020 00:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:autocrypt:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KI/hxcLrGd8h4evhRQjVgB/gQiznnrjk5302Zir3i9s=; b=fThCpk5DmQ0EvkZfFF6ksJMr5lo9BE+ekcTQAnnAnDf0cos0c6+affHAVOpj3Hb+pM Zr3p/+GPi9GuA8nCbFXHVNMqAXfa/QJznEKiTLb13DgLtk4IIHlwnvHeBl3g22xrRHla dTNbfopcZTxoquD6Jvhs28ZfBjrix9c7w1ed6FR/vQdfAOvJV0YA6LjxJG1J5KReXHPo y37EjqLmvLJLqX0DQ7SFaCxs6FAYF6krVHCVTOTpHZk7CGI8khdMP9eooBYVgyX7uf6v CGU4EtqEXWYMhpEQmILJRsbdJlJdm8jHrgW7OUIlaR7E1StCx1ipZoM6XVx020p7dT3d 90Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=KI/hxcLrGd8h4evhRQjVgB/gQiznnrjk5302Zir3i9s=; b=Qo3gYRumRTTYsVBTeoPo/SVWp23in0IhHlY3Ju4huaQAvhVSMZ5s8HVCnagqHADXye hwDUBGjJ3Ewss/YHaOpclDY/erwHBMonir/JQOaFtvJUEFyRlPdjaI9Eky610ANV+P1L yB351Kt2HpaqXyPnKMn1DdVpsZAPO1vRm+Lagj/gaVZAfNMB86+RUBO29tkRZ1h6lJ3u j4CNaj6J4zD1zsu93FWyNnC59xA9grpvBsw6bsZGs1ipkeeF7EROaazFbijmYNB6W86u qqC1qqCalW7AbG+dxaRdpYDEMib33zGTfyO8SS54EthTvqAHAfzfnU7Ek2p0MKm8faj8 /RvQ== X-Gm-Message-State: AOAM533TchQA/uiRprR8VvyG64+4gjqtIMDN5/KaChpwQhImzov1jY/a 4qG0oHI+ItYxJQ4Vv9K6sqhr7g== X-Google-Smtp-Source: ABdhPJwDcMWiUBJXEOkofHg9rYoJMuhM/K31kJcjkFBTDa83gNR22hCKKyWRgkDYJPaFbOW5AAZwdg== X-Received: by 2002:a7b:c753:: with SMTP id w19mr8295330wmk.157.1600326874661; Thu, 17 Sep 2020 00:14:34 -0700 (PDT) Received: from [10.1.2.12] (laubervilliers-658-1-213-31.w90-63.abo.wanadoo.fr. [90.63.244.31]) by smtp.gmail.com with ESMTPSA id s12sm9203148wmd.20.2020.09.17.00.14.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Sep 2020 00:14:33 -0700 (PDT) Subject: Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver To: dri-devel@lists.freedesktop.org, linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org References: <20200907081825.1654-1-narmstrong@baylibre.com> <20200907081825.1654-7-narmstrong@baylibre.com> <20200907084351.GV2352366@phenom.ffwll.local> <20200907084423.GW2352366@phenom.ffwll.local> <20200907180315.GY2352366@phenom.ffwll.local> <20200908084642.GG2352366@phenom.ffwll.local> From: Neil Armstrong Autocrypt: addr=narmstrong@baylibre.com; prefer-encrypt=mutual; keydata= xsBNBE1ZBs8BCAD78xVLsXPwV/2qQx2FaO/7mhWL0Qodw8UcQJnkrWmgTFRobtTWxuRx8WWP GTjuhvbleoQ5Cxjr+v+1ARGCH46MxFP5DwauzPekwJUD5QKZlaw/bURTLmS2id5wWi3lqVH4 BVF2WzvGyyeV1o4RTCYDnZ9VLLylJ9bneEaIs/7cjCEbipGGFlfIML3sfqnIvMAxIMZrvcl9 qPV2k+KQ7q+aXavU5W+yLNn7QtXUB530Zlk/d2ETgzQ5FLYYnUDAaRl+8JUTjc0CNOTpCeik 80TZcE6f8M76Xa6yU8VcNko94Ck7iB4vj70q76P/J7kt98hklrr85/3NU3oti3nrIHmHABEB AAHNKE5laWwgQXJtc3Ryb25nIDxuYXJtc3Ryb25nQGJheWxpYnJlLmNvbT7CwHsEEwEKACUC GyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJXDO2CAhkBAAoJEBaat7Gkz/iubGIH/iyk RqvgB62oKOFlgOTYCMkYpm2aAOZZLf6VKHKc7DoVwuUkjHfIRXdslbrxi4pk5VKU6ZP9AKsN NtMZntB8WrBTtkAZfZbTF7850uwd3eU5cN/7N1Q6g0JQihE7w4GlIkEpQ8vwSg5W7hkx3yQ6 2YzrUZh/b7QThXbNZ7xOeSEms014QXazx8+txR7jrGF3dYxBsCkotO/8DNtZ1R+aUvRfpKg5 ZgABTC0LmAQnuUUf2PHcKFAHZo5KrdO+tyfL+LgTUXIXkK+tenkLsAJ0cagz1EZ5gntuheLD YJuzS4zN+1Asmb9kVKxhjSQOcIh6g2tw7vaYJgL/OzJtZi6JlIXOwU0EVid/pAEQAND7AFhr 5faf/EhDP9FSgYd/zgmb7JOpFPje3uw7jz9wFb28Cf0Y3CcncdElYoBNbRlesKvjQRL8mozV 9RN+IUMHdUx1akR/A4BPXNdL7StfzKWOCxZHVS+rIQ/fE3Qz/jRmT6t2ZkpplLxVBpdu95qJ YwSZjuwFXdC+A7MHtQXYi3UfCgKiflj4+/ITcKC6EF32KrmIRqamQwiRsDcUUKlAUjkCLcHL CQvNsDdm2cxdHxC32AVm3Je8VCsH7/qEPMQ+cEZk47HOR3+Ihfn1LEG5LfwsyWE8/JxsU2a1 q44LQM2lcK/0AKAL20XDd7ERH/FCBKkNVzi+svYJpyvCZCnWT0TRb72mT+XxLWNwfHTeGALE +1As4jIS72IglvbtONxc2OIid3tR5rX3k2V0iud0P7Hnz/JTdfvSpVj55ZurOl2XAXUpGbq5 XRk5CESFuLQV8oqCxgWAEgFyEapI4GwJsvfl/2Er8kLoucYO1Id4mz6N33+omPhaoXfHyLSy dxD+CzNJqN2GdavGtobdvv/2V0wukqj86iKF8toLG2/Fia3DxMaGUxqI7GMOuiGZjXPt/et/ qeOySghdQ7Sdpu6fWc8CJXV2mOV6DrSzc6ZVB4SmvdoruBHWWOR6YnMz01ShFE49pPucyU1h Av4jC62El3pdCrDOnWNFMYbbon3vABEBAAHCwn4EGAECAAkFAlYnf6QCGwICKQkQFpq3saTP +K7BXSAEGQECAAYFAlYnf6QACgkQd9zb2sjISdGToxAAkOjSfGxp0ulgHboUAtmxaU3viucV e2Hl1BVDtKSKmbIVZmEUvx9D06IijFaEzqtKD34LXD6fjl4HIyDZvwfeaZCbJbO10j3k7FJE QrBtpdVqkJxme/nYlGOVzcOiKIepNkwvnHVnuVDVPcXyj2wqtsU7VZDDX41z3X4xTQwY3SO1 9nRO+f+i4RmtJcITgregMa2PcB0LvrjJlWroI+KAKCzoTHzSTpCXMJ1U/dEqyc87bFBdc+DI k8mWkPxsccdbs4t+hH0NoE3Kal9xtAl56RCtO/KgBLAQ5M8oToJVatxAjO1SnRYVN1EaAwrR xkHdd97qw6nbg9BMcAoa2NMc0/9MeiaQfbgW6b0reIz/haHhXZ6oYSCl15Knkr4t1o3I2Bqr Mw623gdiTzotgtId8VfLB2Vsatj35OqIn5lVbi2ua6I0gkI6S7xJhqeyrfhDNgzTHdQVHB9/ 7jnM0ERXNy1Ket6aDWZWCvM59dTyu37g3VvYzGis8XzrX1oLBU/tTXqo1IFqqIAmvh7lI0Se gCrXz7UanxCwUbQBFjzGn6pooEHJYRLuVGLdBuoApl/I4dLqCZij2AGa4CFzrn9W0cwm3HCO lR43gFyz0dSkMwNUd195FrvfAz7Bjmmi19DnORKnQmlvGe/9xEEfr5zjey1N9+mt3//geDP6 clwKBkq0JggA+RTEAELzkgPYKJ3NutoStUAKZGiLOFMpHY6KpItbbHjF2ZKIU1whaRYkHpB2 uLQXOzZ0d7x60PUdhqG3VmFnzXSztA4vsnDKk7x2xw0pMSTKhMafpxaPQJf494/jGnwBHyi3 h3QGG1RjfhQ/OMTX/HKtAUB2ct3Q8/jBfF0hS5GzT6dYtj0Ci7+8LUsB2VoayhNXMnaBfh+Q pAhaFfRZWTjUFIV4MpDdFDame7PB50s73gF/pfQbjw5Wxtes/0FnqydfId95s+eej+17ldGp lMv1ok7K0H/WJSdr7UwDAHEYU++p4RRTJP6DHWXcByVlpNQ4SSAiivmWiwOt490+Ac7ATQRN WQbPAQgAvIoM384ZRFocFXPCOBir5m2J+96R2tI2XxMgMfyDXGJwFilBNs+fpttJlt2995A8 0JwPj8SFdm6FBcxygmxBBCc7i/BVQuY8aC0Z/w9Vzt3Eo561r6pSHr5JGHe8hwBQUcNPd/9l 2ynP57YTSE9XaGJK8gIuTXWo7pzIkTXfN40Wh5jeCCspj4jNsWiYhljjIbrEj300g8RUT2U0 FcEoiV7AjJWWQ5pi8lZJX6nmB0lc69Jw03V6mblgeZ/1oTZmOepkagwy2zLDXxihf0GowUif GphBDeP8elWBNK+ajl5rmpAMNRoKxpN/xR4NzBg62AjyIvigdywa1RehSTfccQARAQABwsBf BBgBAgAJBQJNWQbPAhsMAAoJEBaat7Gkz/iuteIH+wZuRDqK0ysAh+czshtG6JJlLW6eXJJR Vi7dIPpgFic2LcbkSlvB8E25Pcfz/+tW+04Urg4PxxFiTFdFCZO+prfd4Mge7/OvUcwoSub7 ZIPo8726ZF5/xXzajahoIu9/hZ4iywWPAHRvprXaim5E/vKjcTeBMJIqZtS4u/UK3EpAX59R XVxVpM8zJPbk535ELUr6I5HQXnihQm8l6rt9TNuf8p2WEDxc8bPAZHLjNyw9a/CdeB97m2Tr zR8QplXA5kogS4kLe/7/JmlDMO8Zgm9vKLHSUeesLOrjdZ59EcjldNNBszRZQgEhwaarfz46 BSwxi7g3Mu7u5kUByanqHyA= Organization: Baylibre Message-ID: <3de1ceee-edcd-067e-be26-a9399d539301@baylibre.com> Date: Thu, 17 Sep 2020 09:14:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200908084642.GG2352366@phenom.ffwll.local> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200917_031436_327254_A9217441 X-CRM114-Status: GOOD ( 43.33 ) X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org On 08/09/2020 10:46, Daniel Vetter wrote: > On Tue, Sep 08, 2020 at 10:06:03AM +0200, Neil Armstrong wrote: >> Hi, >> >> On 07/09/2020 20:03, Daniel Vetter wrote: >>> On Mon, Sep 07, 2020 at 11:03:29AM +0200, Neil Armstrong wrote: >>>> On 07/09/2020 10:44, Daniel Vetter wrote: >>>>> On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote: >>>>>> On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: >>>>>>> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), with a custom >>>>>>> glue managing the IP resets, clock and data input similar to the DW-HDMI Glue on other >>>>>>> Amlogic SoCs. >>>>>>> >>>>>>> This adds support for the Glue managing the transceiver, mimicing the init flow provided >>>>>>> by Amlogic to setup the ENCl encoder, the glue, the transceiver, the digital D-PHY and the >>>>>>> Analog PHY in the proper way. >>>>>>> >>>>>>> The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 clock, which pixel clock >>>>>>> is derived and feeds the ENCL encoder and the VIU pixel reader. >>>>>>> >>>>>>> An optional "MEAS" clock can be enabled to measure the delay between each vsync feeding the >>>>>>> DW-MIPI-DSI transceiver. >>>>>>> >>>>>>> Signed-off-by: Neil Armstrong >>>>>> >>>>>> More dw-hdmi drivers which aren't bridges but components, and the thing is >>>>>> still midlayer-y as heck :-/ >>>>> >>>>> *dw-dsi, but really they both work the same way and should both be fixed >>>>> ... >>>> >>>> They are bridges but since they have platform-dependent code due to theirs's generic IP >>>> nature, they need to be intanciated by components to sync with the platform code. >>> >>> Yeah that's how it currently works, but there's not much reason why it >>> needs to work like that. That platform glue code can also be put behind >>> the drm_bridge abstraction, and we could use the normal dt based bridge >>> lookup like for everything else. >>> >>> Afaiui the only reason dw-* bridge drivers work like that is because for >>> historical reasons we only had component.c at first, and none of the more >>> fancy dynamic bridge lookup. So would be really good to switch this all >>> over to a proper&clean bridge abstraction, and not leak everything around. >> >> Does it mean we should avoit using components, right ? > > Yup, at least when there's an established specific mechanism to handle > cross-driver interactions/EPROBE_DEFER. > > So if you want a drm_panel or drm_bridge or a clock or i2c or anything > else standardized like that, no component.c please. That's just for the > driver-specific glue when you have entirely IP-specific way of building up > a driver from components, which will never be reused outside of that > overall driver. > > Hence why dw-* using components is rather uncool. > >>> I've typed up what I think should be the way forward a few times already, >>> but thus far not even the todo.rst entry materialized: >>> >>> https://lore.kernel.org/dri-devel/20200430135841.GE10381@phenom.ffwll.local/ >>> >>> If everyone is always about "not in my patch series" it'll never happen. >> >> Today, the dw-mipi-dsi and dw-mipi-hdmi has mandatory callbacks to implement >> vendor specific features, like : >> - hdmi/dsi phy handling when mixed into the glue/custom/synopsys but with platform specific values >> - platform specific mode validation >> - hpd setup => could use laurent's work here with no_connector, but how do we handle rxsense ??? >> - dsi timings/lane mbps ? these are platform phy specific >> >> For amlogic, I can split the "component" code handling venc/vclk into a primary bridge and add a >> secondary driver only handling the glue around dw-mipi-dsi/dw-mipi-hdmi, would that be a good start ? > > I think what we should do here: > > - type up todo.rst with the overall structure we want to aim for, i.e. > where is the code, who sets up what, how are the bridges bound into the > overall driver. OK, sure, this can be a good start, but first I would like all the other bridge maintainers & reviewers to agree on the the wanted structure. > > - demidlayer dw-* enough so that the callbacks are gone, and it becomes > more a toolbox/library for building a dw-* driver. Maybe we're there > already. This is not really wanted, otherwise we would duplicate a large amount of code over all the platform glues, is this really wanted ? Today, they already are a toolbox, with different levels of callback neded depending on how deep the integration is. > > - All new drivers then need to use the toolbox and have everything behind > a drm_bridge driver in drm/bridge/, with just default binding exposed to > drivers, no EXPORT_SYMBOL at all. Also no exported symbols used, this > should all be directly linked into the dw-*.ko imo and treated as > internals. In theory this is cool, in practice, this is impossible for meson_dw_hdmi, the first reason is how the registers are accessed for GX family, we need to define custom regmap read/write functions. For dw-mipi-dsi, it may be feasible, but again I don't see why vendor glue code should live in drm/bridge/ ? The last point, this will impact multiple platforms support in a single patchset, I do not have enough time available to make such changes and check for non-regression. > > - We might need to split the header files to make that clean enough. > > - Once all existing dw-* users are converted, we ditch the EXPORT_SYMBOL > stuff completely (since I expect we'll just have one overall dw-dsi.ko > module with all bridge driver variants). ? why ? why load & add multiple vendor adaptation in a single module ? this sounds like a bad idea, sorry. In the meantime, I'd really like to have this upstream, should this really wait for multiple months for tractations and rework ? I can rework a little to only have the dw-mipi-dsi glue and the encoder stuff in an another file, is this fine for a first step ? Neil > > Cheers, Daniel > > > >> >> Neil >> >>> >>> Cheers, Daniel >>> >>> >>>> >>>> Neil >>>> >>>>> >>>>>> >>>>>> Can we try to fix this? There's a ton of this going on, and the more we >>>>>> add the old fashioned way the harder this gets to fix up for real. >>>>>> -Daniel >>>>>> >>>>>>> --- >>>>>>> drivers/gpu/drm/meson/Kconfig | 7 + >>>>>>> drivers/gpu/drm/meson/Makefile | 1 + >>>>>>> drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 562 ++++++++++++++++++++++ >>>>>>> 3 files changed, 570 insertions(+) >>>>>>> create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c >>>>>>> >>>>>>> diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig >>>>>>> index 9f9281dd49f8..385f6f23839b 100644 >>>>>>> --- a/drivers/gpu/drm/meson/Kconfig >>>>>>> +++ b/drivers/gpu/drm/meson/Kconfig >>>>>>> @@ -16,3 +16,10 @@ config DRM_MESON_DW_HDMI >>>>>>> default y if DRM_MESON >>>>>>> select DRM_DW_HDMI >>>>>>> imply DRM_DW_HDMI_I2S_AUDIO >>>>>>> + >>>>>>> +config DRM_MESON_DW_MIPI_DSI >>>>>>> + tristate "MIPI DSI Synopsys Controller support for Amlogic Meson Display" >>>>>>> + depends on DRM_MESON >>>>>>> + default y if DRM_MESON >>>>>>> + select DRM_DW_MIPI_DSI >>>>>>> + select GENERIC_PHY_MIPI_DPHY >>>>>>> diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile >>>>>>> index 28a519cdf66b..2cc870e91182 100644 >>>>>>> --- a/drivers/gpu/drm/meson/Makefile >>>>>>> +++ b/drivers/gpu/drm/meson/Makefile >>>>>>> @@ -5,3 +5,4 @@ meson-drm-y += meson_rdma.o meson_osd_afbcd.o >>>>>>> >>>>>>> obj-$(CONFIG_DRM_MESON) += meson-drm.o >>>>>>> obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o >>>>>>> +obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o >>>>>>> diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c >>>>>>> new file mode 100644 >>>>>>> index 000000000000..bbe1294fce7c >>>>>>> --- /dev/null >>>>>>> +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c >>>>>>> @@ -0,0 +1,562 @@ >>>>>>> +// SPDX-License-Identifier: GPL-2.0-or-later >>>>>>> +/* >>>>>>> + * Copyright (C) 2016 BayLibre, SAS >>>>>>> + * Author: Neil Armstrong >>>>>>> + * Copyright (C) 2015 Amlogic, Inc. All rights reserved. >>>>>>> + */ >>>>>>> + >>>>>>> +#include >>>>>>> +#include >>>>>>> +#include >>>>>>> +#include >>>>>>> +#include >>>>>>> +#include >>>>>>> +#include >>>>>>> +#include >>>>>>> + >>>>>>> +#include