Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2370051iof; Wed, 8 Jun 2022 03:36:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwRci/jVrEAGsuubYhzBQRZvNp5TuGWPzOCZ+71kxZe8IrHqKdLrbfH/yVvGOXRPSdVANCi X-Received: by 2002:a05:6a00:ad0:b0:50a:51b3:1e3d with SMTP id c16-20020a056a000ad000b0050a51b31e3dmr34205462pfl.18.1654684572809; Wed, 08 Jun 2022 03:36:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654684572; cv=none; d=google.com; s=arc-20160816; b=TzxDUD8VeJlkx4CsOAKDX/22l9odtVYzsVKrbbmNeTpdX6Q8dkmb7xTcWUd/puT8b9 OdUflYGjPaX2CM4Gf7vtZT+mMBXmm/oOMx4BrmZkj2KXqb/KGVDRfkCcsDVPqajkxmVP pcLHT2FyLQgUKUHNnjJbSgyl0VQnCFNzX++3zN898RsUIO0tvDyXj3JpkAPqDwaiAnWI CqlN2CwEMNNkvm64XfEUGpyNWOtPHfAztjaIl1k48N44m/WInEHJCqI7LFa9mCllu2+I uGDJhkgFCo9vCbarbWMUcUM2FIb9VGCV+/YU08MUyuxf3a2lO60DzGMdcF9IY+S4bS0t xLXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=kOg3HvH8j+WVCx/lSSBrh7BoztwaXs9YDBC9IWClIgg=; b=uyBf+ICdtUuL/j69yOYo15m148no1+O0nziC+1fyd5ZxBuU2CpghJaNnC64xnTtMxD Zaz7zVEHWK5cXEjLvzbuQ5+UNgSWNN7T+kcRtxTOsvk5AGzbOCU57AlDZicHKAkg4LkE mT17dktivCGRFfXz4gUFHcXDF1D+ZNyAhRx6djqh2SMFcJoWN1MAyF1u8BGVdoi3o47k hN48eqR2c4VLSFN/d2LE/owZSw4Q9PFm5/qL+5jpndjJ121LhGJOpLfEpSsF7vmKpPG4 D9dYwB9R7WYXx/mbBekMhR6gPu0l/sAccgwF7fHDtea43PDvCy0fpUkLC+smldx+WRI4 Kfsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=BYg8e6tB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id y36-20020a056a001ca400b0051babb88d79si24727876pfw.277.2022.06.08.03.36.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jun 2022 03:36:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=BYg8e6tB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9B0A020B7C0; Wed, 8 Jun 2022 03:03:02 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235812AbiFHKBl (ORCPT + 99 others); Wed, 8 Jun 2022 06:01:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48656 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235934AbiFHKA2 (ORCPT ); Wed, 8 Jun 2022 06:00:28 -0400 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 98FCF344CC for ; Wed, 8 Jun 2022 02:35:54 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id h19so26310370edj.0 for ; Wed, 08 Jun 2022 02:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kOg3HvH8j+WVCx/lSSBrh7BoztwaXs9YDBC9IWClIgg=; b=BYg8e6tB+8azsKp0NbkOtO6Sv9a3zM9cNkEsd/Zvy4TRu7dIMeJRCubIXz1+yJEHSm eaj8rvMkrQbvG2tDfOe0Sb+HPi67Wwzb2u4p/W+mTgTdUSft07yDROB3L9RVu4HrhY1N HrwEILSRfLabHhKX7K/nAJ2mDJqbWxirI90B8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kOg3HvH8j+WVCx/lSSBrh7BoztwaXs9YDBC9IWClIgg=; b=DGzclGkp59KJuqpvCs7FirKbbsM1fL2zZeZ7eI9ntltdSYb7BH51wgwGyRWkmV/KAO m1xOwQWdof7dvnAwKMNpNWA3sUSWIs+2qZMsoW/VlVBn59gwx4iZBYqfZ5B/1DoTzMTK z6Bd0zF26LczV5xT2IAOorlFvIlQtz2WD5bzsavhGLFXCJMiWJX1a+Iw/4vS1Cenq51y Umht3VuXJkLbEzWtuYOoKwwtuj6n4nSaQlKyHBaaW2dN1HT0nFdqVxbBHmWmanswvZ40 jaZ4ontGjR/yPmyj1X1La8A4tBqMTTqRosj7sy/9k2x6T65dbXIaaPaVvo2/rhnBGYkx YAUQ== X-Gm-Message-State: AOAM5332goscnxvroXXTqB4BY/kD2XEuQ6dPxGSiZm4NxBSHiZRKDEVw 9S+yxEoDi3mY5QPeCi3vukQT02MBbjQLDsvTL2DEzQ== X-Received: by 2002:a05:6402:cab:b0:42d:c842:8369 with SMTP id cn11-20020a0564020cab00b0042dc8428369mr37949645edb.181.1654680952985; Wed, 08 Jun 2022 02:35:52 -0700 (PDT) MIME-Version: 1.0 References: <20220607090549.2345795-1-hsinyi@chromium.org> <20220607090549.2345795-9-hsinyi@chromium.org> In-Reply-To: From: Hsin-Yi Wang Date: Wed, 8 Jun 2022 17:35:27 +0800 Message-ID: Subject: Re: [PATCH v5 8/8] drm/mediatek: Config orientation property if panel provides it To: Doug Anderson Cc: Chun-Kuang Hu , Hans de Goede , Thierry Reding , Sam Ravnborg , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Philipp Zabel , David Airlie , Daniel Vetter , Matthias Brugger , dri-devel , "moderated list:ARM/Mediatek SoC support" , Rob Clark , Stephen Boyd , Rob Herring , Linux ARM , LKML Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 7, 2022 at 11:39 PM Doug Anderson wrote: > > Hi, > > On Tue, Jun 7, 2022 at 2:06 AM Hsin-Yi Wang wrote: > > > > Panel orientation property should be set before drm_dev_register(). > > Mediatek drm driver calls drm_dev_register() in .bind(). However, most > > panels sets orientation property relatively late, mostly in .get_modes() > > callback, since this is when they are able to get the connector and > > binds the orientation property to it, though the value should be known > > when the panel is probed. > > > > Let the drm driver check if the remote end point is a panel and if it > > contains the orientation property. If it does, set it before > > drm_dev_register() is called. > > > > Signed-off-by: Hsin-Yi Wang > > Reviewed-by: Hans de Goede > > Reviewed-by: AngeloGioacchino Del Regno > > --- > > v4->v5: > > - use the new function in v5. > > - don't use drm_of_find_panel_or_bridge(). > > --- > > drivers/gpu/drm/mediatek/mtk_dsi.c | 15 +++++++++++++++ > > 1 file changed, 15 insertions(+) > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c > > index d9f10a33e6fa..998b1237e193 100644 > > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c > > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c > > @@ -185,6 +185,7 @@ struct mtk_dsi { > > struct drm_encoder encoder; > > struct drm_bridge bridge; > > struct drm_bridge *next_bridge; > > + struct drm_panel *panel; > > struct drm_connector *connector; > > struct phy *phy; > > > > @@ -822,6 +823,10 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi) > > ret = PTR_ERR(dsi->connector); > > goto err_cleanup_encoder; > > } > > + > > + /* Read panel orientation */ > > + drm_connector_set_orientation_from_panel(dsi->connector, dsi->panel); > > + > > drm_connector_attach_encoder(dsi->connector, &dsi->encoder); > > > > return 0; > > @@ -836,6 +841,16 @@ static int mtk_dsi_bind(struct device *dev, struct device *master, void *data) > > int ret; > > struct drm_device *drm = data; > > struct mtk_dsi *dsi = dev_get_drvdata(dev); > > + struct device_node *panel_node; > > + > > + /* Get panel if existed */ > > + panel_node = of_graph_get_remote_node(dev->of_node, 0, 0); > > + if (panel_node) { > > + dsi->panel = of_drm_find_panel(panel_node); > > + if (IS_ERR(dsi->panel)) > > + dsi->panel = NULL; > > + of_node_put(panel_node); > > + } > > While the above works, it feels like we could do better. What about this? > > * We add _some_ way to determine if a bridge is actually a > panel_bridge. If nothing else maybe this could be > drm_bridge_is_panel() and it could just check if bridge.funcs == > panel_bridge_bridge_funcs > > * In drm_bridge_connector_init(), when we're looping through all the > bridges we find the panel_bridge if it's there. > > * At the end of drm_bridge_connector_init() if we found a panel_bridge > then we call a function like drm_panel_bridge_set_orientation(). > > > Then you can fully get rid of the mediatek patch, right? The above > will only work if you're using a panel_bridge / bridge_connector, but > that's "the future" anyway and we want to encourage people to > transition to that. > This also works with the mtk dsi, and it's more generic. I'll drop this patch and go with this implementation in the next version. Thanks for the suggestion. > -Doug