Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp5161007pxb; Tue, 5 Oct 2021 19:28:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxbX7yo9bSG3cHOualxpvTuDENPNLsYIL2MwW9lBnZS+3K0ySOgcyofaJWRQb8Wp4vx641l X-Received: by 2002:a17:902:be0f:b0:13a:19b6:6870 with SMTP id r15-20020a170902be0f00b0013a19b66870mr8684639pls.64.1633487329116; Tue, 05 Oct 2021 19:28:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633487329; cv=none; d=google.com; s=arc-20160816; b=ORcs40qtv/w4wOhAnxU7gKt3U2RPWEkaLupGuKQF6CjJ8ydshfjOO2dtzcpYsJoweo foQNlZYRWbKKttJgK3PR4bcbIjjGGvd+TUNuLP9V2AsZbG8mU02ziO0PJS9a1oA7mxBz 93nBZ+ecYXPc7FfrgkZ/lLypnrGtt6tmnJ2jQns04CPhpCX+5bmj/EgyonmeZDA4L+nP rFT2ZcoqEuCZClT0qKO99zJyNYVqzSU8y2+XnkOlhqejAmTsJIhDkJH5x1bob+wLvuZ0 CwWit7cYY+/fSL8d/VLX5lGqHdy2NXTRm+HOno1a/3f0TklA9Ul4lkDlI1diWISh3ozY 4djw== 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:message-id:subject:cc:to:from:date:dkim-signature; bh=ctR1cokXAwmItjiMPfDRY881NbdQTs9Vf1LWVT6hHds=; b=00BjXgYsJlCl5zK7AG4Sy+MQfooJ8ODExUYa7hpFKqg0KvVz34tu5eI6hWQ7BI369M kFB/DXj2Xu7w5PHdLYb5YmBf98IvH70gsjFirbWMN5xJGpCsiGS6L3YSdhgcGq3ATsiG sWZ2PpgKQWWGO9jM4pQEE/PczHvetXg3KlA+wdxPgZl/mZi1vuhf/FSRi7zQZnaz+dEW pSGRb7m+49nKLD6qmTYXCOyFIoHYSDirZMcifEBkCuSGLgu0DHPVdnco+174cyxZBlYo rctmRZ9nyP1RWp3ZLn+jNmqndJV+ICghwVNQ5xl9jC/q6h37YQUCvWoV+Gs3g4wqmVnb 0EAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="airbaT/+"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f22si23314171pgv.464.2021.10.05.19.28.35; Tue, 05 Oct 2021 19:28:49 -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=@linaro.org header.s=google header.b="airbaT/+"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229908AbhJFC3h (ORCPT + 99 others); Tue, 5 Oct 2021 22:29:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42134 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230261AbhJFC3g (ORCPT ); Tue, 5 Oct 2021 22:29:36 -0400 Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0F7B8C06174E for ; Tue, 5 Oct 2021 19:27:45 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id 77-20020a9d0ed3000000b00546e10e6699so1393611otj.2 for ; Tue, 05 Oct 2021 19:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ctR1cokXAwmItjiMPfDRY881NbdQTs9Vf1LWVT6hHds=; b=airbaT/+5STqFzWVU9qMFiytHYONXy4ji+WgSNwUSkY/mvWRsfBeoNjIyhiI46MXBE OckyiNIaJO8Wc49P8E6N0kf1wzXra8U6QoJQUhek42tKs6HZdeircNeEohpyZbu92Pqr EFomM3kCdRIz5dv1uAFhpHtqOebAB2P30zWs+w3A+XyP4oihfUO06Xan/3jLRNtYOO77 9cuZEfKRhL8vg38kC9/iw7tZAOSY9vmcVzLq7hkuUf9fLdoN9OXr+Ey/PnkIs+J4ZgQL qRfzFB/ip7OOwEhkq616CO6hO208CGD+qgKWHNutGQ2Lbiv645qL1+B2vUQ9WKqxWXWh H6pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ctR1cokXAwmItjiMPfDRY881NbdQTs9Vf1LWVT6hHds=; b=KjPvWvKsI8DteEfoC9nYfSw4/oUV3sB1drXr8Hsqk9EWjDN+RH3PfKw2Wum/4kOpiC PSTTFT4HyPNZU7ZKLojCaOvV1i0dighmxtlRJIfzGiP6QoCYfKcHiMb8ZnfKpElCWLiQ rI4VBeHi8p/OY/FAM/M0ZmVgjVOKWF0DU/irifkNl0ASpU0EuXCUqjaTSNMne40x9tu5 UgO8KgkmLbYj4ph+r/A+93KJoDefcVWWE/RpMTLWQ21XHM7BYBPvGuqN1sd2PnHQB8Ul 0pXT5yqTolwVz7c4fcP5S/G/gEBchgW61TO8fNcFj31KzW+3H27+0HhznYAN/xHvYogO XfOQ== X-Gm-Message-State: AOAM533n8YMY484uQK4Twpgsb840Oj6M3Q7l1UVcrGiLL1oeZHvxcMT3 OoaL7pxkBu6o3u+e0lO3bk289w== X-Received: by 2002:a05:6830:40b0:: with SMTP id x48mr17273031ott.246.1633487264086; Tue, 05 Oct 2021 19:27:44 -0700 (PDT) Received: from ripper ([2600:1700:a0:3dc8:205:1bff:fec0:b9b3]) by smtp.gmail.com with ESMTPSA id g9sm467239otj.78.2021.10.05.19.27.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Oct 2021 19:27:43 -0700 (PDT) Date: Tue, 5 Oct 2021 19:29:25 -0700 From: Bjorn Andersson To: Doug Anderson Cc: Laurent Pinchart , Rob Clark , Sean Paul , David Airlie , Daniel Vetter , linux-arm-msm , LKML , Abhinav Kumar , Stephen Boyd , Kuogee Hsieh , dri-devel , Vara Reddy , freedreno Subject: Re: [RFC] drm/msm/dp: Allow attaching a drm_panel Message-ID: References: <20210726231351.655302-1-bjorn.andersson@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 05 Oct 16:09 PDT 2021, Doug Anderson wrote: > Hi, > > On Tue, Oct 5, 2021 at 10:33 AM Bjorn Andersson > wrote: > > > > On Tue 05 Oct 08:39 PDT 2021, Doug Anderson wrote: > > > > > Hi, > > > > > > On Mon, Oct 4, 2021 at 6:09 PM Bjorn Andersson > > > wrote: > > > > > > > > On Mon 04 Oct 17:36 PDT 2021, Doug Anderson wrote: > > > > > > > > > Hi, > > > > > > > > > > On Fri, Oct 1, 2021 at 2:00 PM Bjorn Andersson > > > > > wrote: > > > > > > > > > > > > On Fri 27 Aug 13:52 PDT 2021, Doug Anderson wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > On Mon, Jul 26, 2021 at 4:15 PM Bjorn Andersson > > > > > > > wrote: > > > > > > > > > > > > > > > > +static int dp_parser_find_panel(struct dp_parser *parser) > > > > > > > > +{ > > > > > > > > + struct device_node *np = parser->pdev->dev.of_node; > > > > > > > > + int rc; > > > > > > > > + > > > > > > > > + rc = drm_of_find_panel_or_bridge(np, 2, 0, &parser->drm_panel, NULL); > > > > > > > > > > > > > > Why port 2? Shouldn't this just be port 1 always? The yaml says that > > > > > > > port 1 is "Output endpoint of the controller". We should just use port > > > > > > > 1 here, right? > > > > > > > > > > > > > > > > > > > Finally got back to this, changed it to 1 and figured out why I left it > > > > > > at 2. > > > > > > > > > > > > drm_of_find_panel_or_bridge() on a DP controller will find the of_graph > > > > > > reference to the USB-C controller, scan through the registered panels > > > > > > and conclude that the of_node of the USB-C controller isn't a registered > > > > > > panel and return -EPROBE_DEFER. > > > > > > > > > > I'm confused, but maybe it would help if I could see something > > > > > concrete. Is there a specific board this was happening on? > > > > > > > > > > > > > Right, let's make this more concrete with a snippet from the actual > > > > SC8180x DT. > > > > > > > > > Under the DP node in the device tree I expect: > > > > > > > > > > ports { > > > > > port@1 { > > > > > reg = <1>; > > > > > edp_out: endpoint { > > > > > remote-endpoint = <&edp_panel_in>; > > > > > }; > > > > > }; > > > > > }; > > > > > > > > > > > > > /* We got a panel */ > > > > panel { > > > > ... > > > > ports { > > > > port { > > > > auo_b133han05_in: endpoint { > > > > remote-endpoint = <&mdss_edp_out>; > > > > }; > > > > }; > > > > }; > > > > }; > > > > > > > > /* And a 2-port USB-C controller */ > > > > type-c-controller { > > > > ... > > > > connector@0 { > > > > ports { > > > > port@0 { > > > > reg = <0>; > > > > ucsi_port_0_dp: endpoint { > > > > remote-endpoint = <&dp0_mode>; > > > > }; > > > > }; > > > > > > > > port@1 { > > > > reg = <1>; > > > > ucsi_port_0_switch: endpoint { > > > > remote-endpoint = <&primary_qmp_phy>; > > > > }; > > > > }; > > > > }; > > > > }; > > > > > > > > connector@1 { > > > > ports { > > > > port@0 { > > > > reg = <0>; > > > > ucsi_port_1_dp: endpoint { > > > > remote-endpoint = <&dp1_mode>; > > > > }; > > > > }; > > > > > > > > port@1 { > > > > reg = <1>; > > > > ucsi_port_1_switch: endpoint { > > > > remote-endpoint = <&second_qmp_phy>; > > > > }; > > > > }; > > > > }; > > > > }; > > > > }; > > > > > > > > /* And then our 2 DP and single eDP controllers */ > > > > &mdss_dp0 { > > > > ports { > > > > port@1 { > > > > reg = <1>; > > > > dp0_mode: endpoint { > > > > remote-endpoint = <&ucsi_port_0_dp>; > > > > }; > > > > }; > > > > }; > > > > }; > > > > > > > > &mdss_dp1 { > > > > ports { > > > > port@1 { > > > > reg = <1>; > > > > dp1_mode: endpoint { > > > > remote-endpoint = <&ucsi_port_1_dp>; > > > > }; > > > > }; > > > > }; > > > > }; > > > > > > > > &mdss_edp { > > > > ports { > > > > port@1 { > > > > reg = <1>; > > > > mdss_edp_out: endpoint { > > > > remote-endpoint = <&auo_b133han05_in>; > > > > }; > > > > }; > > > > }; > > > > }; > > > > > > > > > If you have "port@1" pointing to a USB-C controller but this instance > > > > > of the DP controller is actually hooked up straight to a panel then > > > > > you should simply delete the "port@1" that points to the typeC and > > > > > replace it with one that points to a panel, right? > > > > > > > > > > > > > As you can see, port 1 on &mdss_dp0 and &mdss_dp1 points to the two UCSI > > > > connectors and the eDP points to the panel, exactly like we agreed. > > > > > > > > So now I call: > > > > drm_of_find_panel_or_bridge(dev->of_node, 1, 0, &panel, NULL); > > > > > > > > which for the two DP nodes will pass respective UCSI connector to > > > > drm_find_panel() and get EPROBE_DEFER back - because they are not on > > > > panel_list. > > > > > > > > There's nothing indicating in the of_graph that the USB connectors > > > > aren't panels (or bridges), so I don't see a way to distinguish the two > > > > types remotes. > > To summarize where I think our out-of-band discussion went, I think > you're OK w/ keeping this at "port@1" for both the DP and eDP case and > we'll figure out _some_ way to make it work. > > > > > As far as I can tell the way this would be solved would be to actually > > > pass &bridge in and then make sure that a bridge would be in place for > > > the DP connector. In the full DP case you'll get an -EPROBE_DEFER if > > > the connector hasn't been probed but once it's probed then it should > > > register as a bridge and thus give you the info you need (AKA that > > > this isn't a panel). > > > > > > I haven't done the digging to see how all this works, but according to > > > Laurent [1]: "Physical connectors are already handled as bridges, see > > > drivers/gpu/drm/bridge/display-connector.c" > > > > > > > All this seems to make sense for both eDP and "native" DP. > > > > > So basically I think this is solvable in code and there's no reason to > > > mess with the devicetree bindings to solve this problem. Does that > > > sound right? > > > > > > > But I don't have a DisplayPort connector. > > > > I have a USB-C connector, that upon determining that it's time to play > > DisplayPort will use the typec_mux abstraction to tell someone on the > > other side of the of_graph about DisplayPort events (HPD). > > > > So where would I put this drm_bridge in the USB-C case? > > > > I don't see that it fits in the Type-C side of things and putting it on > > the DP side would leave us with exactly the problem we have here. So we > > would have to put a fake "DP connector" inbetween the DP node and the > > Type-C controller? > > > > > > For reference, this is how I thought one is supposed to tie the Type-C > > controller to the display driver: > > https://lore.kernel.org/all/20211005022451.2037405-1-bjorn.andersson@linaro.org/ > > OK, so I looked at that a bit. Fair warning that I've never looked at > the type C code before today so anything I say could be totally wrong! > :-) > > ...but I _think_ you're abusing the "mux" API for this. I think a type > C port can have exactly 1 mux, right? Right now you are claiming to be > _the_ mux in the DP driver, but what about for other alt modes? If > those wanted to be notified about similar things it would be > impossible because you're already _the_ mux, right? > I actually don't think so, because I acquire the typec_mux handle by the means of: mux_desc.svid = USB_TYPEC_DP_SID; mux_desc.mode = USB_TYPEC_DP_MODE; alt_port->mux = fwnode_typec_mux_get(fwnode, &mux_desc); And in the DisplayPort node I provide svid = /bits/ 16 <0xff01>; So I will be able to reference multiple different altmode implementors using this scheme. > I _think_ a mux is supposed to be something more like > `drivers/phy/rockchip/phy-rockchip-typec.c` (though that code predates > the type C framework we're looking at here). There the phy can do all > the work of remuxing things / flipping orientation / etc. I don't > think it's a requirement that every SoC be able to do this remuxing > itself but (if memory serves) rk3399 implemented it so we didn't have > to do it on the TCPC and could use a cheaper solution there. > I'm afraid I don't see how this interacts with a display controller. It seems more like it's the phy side of things, what we have split between the Type-C controller and the QMP phy to set the pins in the right state. > In any case, my point is that I think there is supposed to be a > _single_ mux per port that handles reassigning pins and that's what > this API is for. > If that's the case things such as typec_mux_match() is just completely backwards. > ...so I will still assert that the right thing to do is to have a > drm_bridge for the type c connector and _that's_ what should be > sending HPD. > That still implies that all the current typec_mux code got it all wrong and should be thrown out. If you instead consider that you have a Type-C controller that upon switching DisplayPort on/off calls typec_mux_set() to inform the functions that things has changed then all the current code makes sense. It also maps nicely to how the TypeC controller would call typec_switch_set() to inform, in our case the QMP phy that the orientation has switched. It seems reasonable to have some common helper code that registers the typec_mux and turn its notifications into HPD notifications to the display code, but I still think that should live in the DRM framework, separate from the USB code. Regards, Bjorn > > > I'm afraid I must be missing something in Laurent and yours proposal > > (although I think Laurent is talking about the native DP case?). > > > > Regards, > > Bjorn > > > > > [1] https://lore.kernel.org/r/YUvMv+Y8tFcWPEHd@pendragon.ideasonboard.com/