Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp205361pxk; Thu, 17 Sep 2020 00:16:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyeknXPcDfs3kYYtexyb5m7Xa7aRNp+5y/rhdq6inMA7VzO14u9iTDJ0uIFAkfVtgLlM/7Q X-Received: by 2002:a05:6402:1544:: with SMTP id p4mr30972433edx.346.1600326967729; Thu, 17 Sep 2020 00:16:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600326967; cv=none; d=google.com; s=arc-20160816; b=hMh11+QqKA6wiYuTTgs37uhok4xCtEkaFAZmvUtVs059p4y85rQwuFXmELpYg4pIpD EqWB3bfZ58JO3sMiicLVFMSVLRgmfaVGx8H9IBWnzM6118bw0IaStsQZgZJk3uczMmnD cTwkNJeDFIPZxzTrKsQRO32E/dWgN3F0fxGe/jEIPjEzVji3CcPczJ7nXezNPCejhjdr HHm+17OuONGoKXD44c3XQTHO021KsVpbKUU5wZwJfc0pMPR4z3OxZ1x4ji2Opx92Bsbz LRctqSc8OYJ35OAtk/8zDOuqxa0RyBe3VYYNva2CsTg/8EP3QvGJXSSxmeO8qPus+M7C VFFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :autocrypt:from:references:to:subject:dkim-signature; bh=KI/hxcLrGd8h4evhRQjVgB/gQiznnrjk5302Zir3i9s=; b=VnnGkt+IrVpEBqwa3dXTa6WlMnK1FPFl4Kcaz9eekLGngMT+sX29sCkGgcmi+OubNk RFYod7y5/S35Tg3FJuoDjusjjygWOhizXdu5FYmrkL7Uo0eGK/zkRpyM5kY96LynwM5e OnBgnsa/9GAInOVY84sw6bAoY3dR460yWNHmltCMC3v1Mmog6HG/jrC9DhVc1v1JwQ0N H4ohBVemRrLFACHdyqveG55ALePAgdMT2lDTlN+6qB21dvhdjF+qVdvmNy/1m6P5Rq0U 6VXHAR0wapo9b0JRpVcOxZJM7Q7L8u8RDqhnscTv7tn/M3E52gg43K9IVSsmc/QJHmAT iC0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=fThCpk5D; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c90si8517203edf.214.2020.09.17.00.15.42; Thu, 17 Sep 2020 00:16:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=fThCpk5D; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726191AbgIQHOj (ORCPT + 99 others); Thu, 17 Sep 2020 03:14:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47708 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726153AbgIQHOi (ORCPT ); Thu, 17 Sep 2020 03:14:38 -0400 Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4A161C06174A for ; Thu, 17 Sep 2020 00:14:37 -0700 (PDT) Received: by mail-wm1-x341.google.com with SMTP id k18so912736wmj.5 for ; Thu, 17 Sep 2020 00:14:37 -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=mquI0LabgrkT4vjcKORXFGRwxajJTcim+PWBZY337r5k+lHnbMK0E74xCWtsCvo5Cn 3PNqvBG0BDUAdsxKf+OwBJLOxWZx0az2leypMVbfUgDx86mHndq0hShIdz178l2RHnK9 eRDjxfnBjP95PchQHkM4qno1JZMlLN4dM6yNTEhxoAfjkY1s/Wwmvor+jwqH+W/V17h3 P2YLUONVzqzDVtK26v8Rdi20q1fs+wIO5/jTdGMivp/XM6i6l8WIxZj7vg97EsZle4tH RuKQfURDWTcyh1L6ENCC85r4iEydJBuoMOAJtYAyA2IfmLN2z5JalNDn/rxhVwGLkT/4 NJDQ== X-Gm-Message-State: AOAM530oXgPz2S2qmBtET0Hgl2Nqnc8rVjqnqOJ2HfeYx3hcqYBmc3PA li4kOmjCZKgjEh0AgTd8bvGcBDn1VD0hgbfl 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-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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