Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp340305pxk; Thu, 17 Sep 2020 04:41:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy3akUBDfgu6GUhDgUHvCsLR/FvZ2hwfrizpKzVj44Tw728UR6bmTpCaANDOvdEoBko6a77 X-Received: by 2002:a17:906:fa81:: with SMTP id lt1mr29938588ejb.459.1600342910206; Thu, 17 Sep 2020 04:41:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600342910; cv=none; d=google.com; s=arc-20160816; b=DScHg/MN/NGxvNtF1mwbm8FrrvW6v37Xiff3S0RGJ/gOb3BQJ1CfNcyMO90A+WQru7 rty6GcLAZxUg6807SeMunPHZ5tIFH2/o3+fx4qvLNVa5rJ1auWfwz4vL0AFST+IDNDG7 yV+LE+u7WTBv2aJCcfHQxsR0bzrIya4mcm4dmK9jrpCK4HH4o9F4dmP66bM/c54xtVKJ VfyI8BjMw1ggT5uqsMKZdUZc1nbH+yDnH1AXA2OCBquBo8gODN8pzWSIb6jzt+dhZIi2 BJaBxRmebMXoeAfKwuBDOmxG5xg6pWz0rR5WYJLVQaOaE6PQ6XrzvGDJYk2CIoNJDPPG JbRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:mail-followup-to:message-id:subject:cc:to:from:date :dkim-signature; bh=IxLMX6sTB/GNb4jmEc2vdwY4UjgoylZEvOJT6UWqMUo=; b=r5e9uMEBuhMzaUsc+RELBUYi3C/AqDgWML7ssdoEmaowP44atwUoPCtJzfWCZf/2vh r/GZqTMnIkky41YvAk/saIil3bq/vfMUknuE0VJL1/dUId3iRNhmD+Lbd2jxp15xKCYe RWuclFR6k8MsGUvIvArWeJePPZOrXZf99sq846EIysTgA30G+0ZECjTc0vpXeL8jNSUH yCx9L3l2/srXRiX2s7WGjZFXajhCE6P7XJjTeJOsO/KiCH6Me6VuJJPi/eDpIdDZHgFC dpmi9FXoHaK4L5jW11Cg25UDQ/J6JoqY+RGpUYbeCiSUY1/vUgCAnaZvhNpDz040FkUP 7VIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=V0YNKofX; 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 lf11si13395814ejb.48.2020.09.17.04.41.26; Thu, 17 Sep 2020 04:41:50 -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=@ffwll.ch header.s=google header.b=V0YNKofX; 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 S1726737AbgIQLht (ORCPT + 99 others); Thu, 17 Sep 2020 07:37:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726677AbgIQLc0 (ORCPT ); Thu, 17 Sep 2020 07:32:26 -0400 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 183ACC061756 for ; Thu, 17 Sep 2020 04:32:25 -0700 (PDT) Received: by mail-wr1-x441.google.com with SMTP id g4so1676462wrs.5 for ; Thu, 17 Sep 2020 04:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=IxLMX6sTB/GNb4jmEc2vdwY4UjgoylZEvOJT6UWqMUo=; b=V0YNKofXmptrpy/+ZY6ScZ7Zyvjdo4aDl1hyE1Kau8G/G0CEZTtXW2SsXIUXVuTyj+ dHd5rNr44sZKh8RuBCy8B7uDGm0YYHOOVehAInhqaAyhZukgztlM2NBLIkelK456T6xQ S5b50im87ErdgHjYi7VoLY2lUS6TzqqDvF6uk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=IxLMX6sTB/GNb4jmEc2vdwY4UjgoylZEvOJT6UWqMUo=; b=iCJkSGC3GcHosisWa3xvoc88Zvmf3/U28OowoOIpWhvMxu0EtT/m1Mv5akFe6nufgT R0plPxvczA7oF3OlOC7hpyP7cQkjix1+eq0M9VJM7g3CAz6ivAkIX1uML8RlGRrk5DCN t7lWfuWf04wE+1fsXxExUDjoD5wO6CJ0TT9GuEzoOQugbH9FoAWRfILrPtFSO36NMo6A XVIrxSyjDCUD9ZKWtaMeuM4YNiUP+EMbSXWaWwczkWwoS17bkpocoBNhMhWJncy8Ibd2 4q2PEqu2S2b+3HSW3IwqnJWQ5B6tXyG0ZW/4VOF87CYIg0lKEp35nWtmuPG6rgtHEdVW Vm3w== X-Gm-Message-State: AOAM530ingwNyEMefKeXeIjx1nExCQnAMaaPQnDMOA5Ykv4NQYNk2hho bSLynxAHc+KkGB1w5OPgxXW4AQ== X-Received: by 2002:a5d:69cd:: with SMTP id s13mr30627796wrw.379.1600342343455; Thu, 17 Sep 2020 04:32:23 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id u17sm33351550wri.45.2020.09.17.04.32.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Sep 2020 04:32:22 -0700 (PDT) Date: Thu, 17 Sep 2020 13:32:20 +0200 From: Daniel Vetter To: Neil Armstrong Cc: dri-devel@lists.freedesktop.org, linux-amlogic@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver Message-ID: <20200917113220.GS438822@phenom.ffwll.local> Mail-Followup-To: Neil Armstrong , 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> <3de1ceee-edcd-067e-be26-a9399d539301@baylibre.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3de1ceee-edcd-067e-be26-a9399d539301@baylibre.com> X-Operating-System: Linux phenom 5.7.0-1-amd64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 17, 2020 at 09:14:33AM +0200, Neil Armstrong wrote: > 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. Yeah I guess getting rid of all of them doesn't make that much sense. > > - 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. Well we'd need something that's gradual, i.e. new stuff works like a pure bridge without component interactions or other stuff. > > - 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. You don't have to, I guess you can have them all separately if that's desired. Just feels like that'll make things more complicated. > 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 ? The overall idea that I at least discussed with Laurent and Sam (who've probably done most of the drm_bridge refactoring) is that we should push for drm_bridge as the abstraction and interface point. So no component.c, and the entire bridge in drm/bridge/ folder. I guess the fundamental question is whether the dw-* drivers should be drm_bridges, or just their own private stuff. And everyone doing their own private stuff for integrating these things kinda defeats the point. The other thing is that this is roughly bridge addition no 3 or so where this gets discussed, and everyone is "nah this isn't my problem, I just want to merge my code". -Daniel > > 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