| Message ID | 20190315130825.9005-2-jagan@amarulasolutions.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-amarula+bncBD7MFH7A7EEBBWWHV3SAKGQEX4S6DLY@amarulasolutions.com> X-Original-To: linux-amarula@patchwork.amarulasolutions.com Delivered-To: linux-amarula@patchwork.amarulasolutions.com Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) by ganimede.amarulasolutions.com (Postfix) with ESMTPS id B33F93F033 for <linux-amarula@patchwork.amarulasolutions.com>; Fri, 15 Mar 2019 14:08:43 +0100 (CET) Received: by mail-pf1-f197.google.com with SMTP id v19sf8964799pfe.15 for <linux-amarula@patchwork.amarulasolutions.com>; Fri, 15 Mar 2019 06:08:43 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1552655322; cv=pass; d=google.com; s=arc-20160816; b=nb1x9y6mv9PkQlnI3wUJIBro36RkfVvMkj2pQURsjFZWRq5SRoHG0019lp95vsHT5w F2V4/BX8OxeZWVxbZIp1ygnUzaIF0SWBzFKKRLP1+uzoubT5YcdPQY8bHuA5MRhdFQv0 X0sj+PPInsjZynWtVE+qsuocVN8n7lvRxTlUiBHKATH3pmLFxOKAiE1DRjLc4wz5cZkZ xboPAwg+CCn0bGKZDNZob0+3VW+9AZ3/N7mPm0ZSIj9W0c8xuSkx40ZJgqmMu6uLeUS+ AxM3WXmJ0eODrAB/emtjWq2TEIr7etvbco7v/Fo4nLySFgEH1AM9fkUKpDegih71xHwX hCXA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-archive:list-help:list-post:list-id :mailing-list:precedence:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:dkim-signature; bh=VGiaU4qU51dWfbFLGJG+U4Q1vEoNswizfj0e6DKk9G0=; b=afSJNbBFymeuulb7xKm8P6SP/w1zjpgzIO6g67y09YAZx09/Oy4mfgHA53Abg+YjkU jgmrniuLVGvXzpcQl4fkBsk5ZT0kneGD5YsrR0uUMjnLsgVNmB1pWtZuPvwr9VfaWB8p Ri+eLX1JDVrgadFimRE9aOCGJQVe8B9Tk7V6uyFJPeiPpsPf0Am6Yvw5GcewL2cU7QOx RhurfP7mPP74sqpU6GRV8qX9XWZKMEjSNi3AUz2IIMKkHBZTJV75tEWV/mB2Co435d5M eowG4gduq+1j/srT8PvDcKrBOptyq54gKw8QWcP55XJ/s3grA2lp5J13i4nORcBgwr03 qf7A== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=EEr7kbm4; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:x-original-sender:x-original-authentication-results :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-unsubscribe; bh=VGiaU4qU51dWfbFLGJG+U4Q1vEoNswizfj0e6DKk9G0=; b=gD7vqscD9OkEUb3KsEgyKqAqcfJtsiiO5ekH1uWVGDkJxiehkoetAis3/SnkqDLodU cSQJ2m8mqtGrLwk7iyNE13UmyvRPaaawbDSGztsGGSRrocrfPuNIAMXFvZJhm9bMQ7hw 0C/JNZZiJPgaGi3JrjanCvdjrrto3RAhO3RNA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-unsubscribe; bh=VGiaU4qU51dWfbFLGJG+U4Q1vEoNswizfj0e6DKk9G0=; b=SfZeb0w828Vc4vxixR0RpDr39PM17e/7mp0uTu4+EJzPE5pKEnIC2+hpo/vUypgpGB usGlHzbkTtQf7Kmwwnl9DbtTAHMalydDvf/fHTj84kla2TJeYdvTUBYkaaSIH2VEfAcc 1VHN5lL5Jc/SdL3m7gVvuoIUJUE0jSWjXYi/Cp2VEnMsCrcmKHP3KmGijV62LgLFv5l5 UTFPbR30NtdrpNOm9KuXqDv5k3kMGcP3l9iEnS347zg32tJaXrsr7l6dzJfUBuQLs4Ap jF1xD9VZt9GPKQp2tHyZvP2cUOpMC7WAbVPZKIRUZWuzHLVtLZCcVPRf3ihK93TKFnD9 uy6g== X-Gm-Message-State: APjAAAV7Lau6s+XJWjmemnpdZeT+p0/SOcIuezFuO/6kCojeCpjoHmT6 MmkjnwPoootoy7Kz2L91xC2S+4eF X-Google-Smtp-Source: APXvYqwXIqeUm6oMFNBHf3xxYMQkag/eaGosKqGcIrNk6r8gxSY5aDtUcvctsEEHi/mAQjfDot13Ew== X-Received: by 2002:aa7:924f:: with SMTP id 15mr1381702pfp.44.1552655322568; Fri, 15 Mar 2019 06:08:42 -0700 (PDT) X-BeenThere: linux-amarula@amarulasolutions.com Received: by 2002:a65:430a:: with SMTP id j10ls3566803pgq.0.gmail; Fri, 15 Mar 2019 06:08:42 -0700 (PDT) X-Received: by 2002:a63:f113:: with SMTP id f19mr3293997pgi.141.1552655322178; Fri, 15 Mar 2019 06:08:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552655322; cv=none; d=google.com; s=arc-20160816; b=H6DsGMCJxsLr6AdPilJtn56gVmsVnqFBB8Dzfyzt2iXO1DvyXSd1sP4UKTvo7PSNLO ukPyArDFb5DoYja/WBtr5hcRYLUN44ZOVsdTU4qoQQ0j4sSnNY9goZAEpxgsc6Xn6hE+ 0xz1pLM4FJIy+4NfYJ5zyEXUT8hePrNWBkZB2NvzSKzv0NagdmEY5EHFHZK/9I8mF4j1 dlsv8mhP4tUfU3R6mGYOX0JH/3PfwFoFoIGMMPoGWKBjLoCwuRIvTvxKy+Wrhhb318wg 167WK9JDhElTlvOpP5vr8OhM1xQB+dcYFK7ge8ADIz3B7zqlim37g2LI0Mch1nV4Mshk hDbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:dkim-signature; bh=NP9T09HEiV9lz6LnHjqB2XMYT7hhusLm/ZYVSxXup6g=; b=TCndRg6jWyHannZ1uIt2pJebTpzAxdRkeRa9psU+d5IuR390jCHU2Yyibu8i6cQ+Uu HAASbERT3YLyncJW3erabG/89kVe+kL6pmxtCkraQBhSUHr9thtPJFWYSt/h+8Mg+gjL xrvO6NDcJKZk7hWePRTRFHEt1139y07LfwcvpYtCGBvme0jFMBWo7KCTndcqr4sIwBcw 0+5ZN/26MJV5DCyFf2+alpQjMhTpKD3ejk3Wxw2xxsLTx+kgdoIjPju69eF2naArLi+T nV/PBAYHOymf7DZYFH0D3Wn3pTlSxG/GY5qZJn418qPLZy6A7AAE0rhjV64YBLpnTm9P F9Tg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=EEr7kbm4; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id g7sor3210349pfi.48.2019.03.15.06.08.42 for <linux-amarula@amarulasolutions.com> (Google Transport Security); Fri, 15 Mar 2019 06:08:42 -0700 (PDT) Received-SPF: pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 2002:aa7:85cc:: with SMTP id z12mr4016902pfn.196.1552655321804; Fri, 15 Mar 2019 06:08:41 -0700 (PDT) Received: from localhost.localdomain ([183.82.230.185]) by smtp.gmail.com with ESMTPSA id e2sm854008pfa.64.2019.03.15.06.08.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Mar 2019 06:08:41 -0700 (PDT) From: Jagan Teki <jagan@amarulasolutions.com> To: Andrzej Hajda <a.hajda@samsung.com>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Chen-Yu Tsai <wens@csie.org>, Maxime Ripard <maxime.ripard@bootlin.com>, David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>, Rob Herring <robh+dt@kernel.org>, Mark Rutland <mark.rutland@arm.com> Cc: Michael Trimarchi <michael@amarulasolutions.com>, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@googlegroups.com, linux-amarula@amarulasolutions.com, Jagan Teki <jagan@amarulasolutions.com> Subject: [PATCH 1/6] drm/bridge: Export drm_bridge_detach Date: Fri, 15 Mar 2019 18:38:20 +0530 Message-Id: <20190315130825.9005-2-jagan@amarulasolutions.com> X-Mailer: git-send-email 2.18.0.321.gffc6fa0e3 In-Reply-To: <20190315130825.9005-1-jagan@amarulasolutions.com> References: <20190315130825.9005-1-jagan@amarulasolutions.com> MIME-Version: 1.0 X-Original-Sender: jagan@amarulasolutions.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=EEr7kbm4; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com Content-Type: text/plain; charset="UTF-8" Precedence: list Mailing-list: list linux-amarula@amarulasolutions.com; contact linux-amarula+owners@amarulasolutions.com List-ID: <linux-amarula.amarulasolutions.com> X-Spam-Checked-In-Group: linux-amarula@amarulasolutions.com X-Google-Group-Id: 476853432473 List-Post: <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/post>, <mailto:linux-amarula@amarulasolutions.com> List-Help: <https://support.google.com/a/amarulasolutions.com/bin/topic.py?topic=25838>, <mailto:linux-amarula+help@amarulasolutions.com> List-Archive: <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/> List-Unsubscribe: <mailto:googlegroups-manage+476853432473+unsubscribe@googlegroups.com>, <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/subscribe> |
| Series |
drm/bridge: Add ICN6211 MIPI-DSI/RGB bridge
|
|
Commit Message
Jagan Teki
March 15, 2019, 1:08 p.m. UTC
Export drm_bridge_detach from drm bridge core so-that it
can use on respective interface or bridge driver while
detaching the bridge.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/gpu/drm/drm_bridge.c | 1 +
include/drm/drm_bridge.h | 1 +
2 files changed, 2 insertions(+)
Comments
Hi Jakan, On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote: > Export drm_bridge_detach from drm bridge core so-that it > can use on respective interface or bridge driver while > detaching the bridge. I don't see why this change is required based on the commit log. The DRM bridge code clearly indicates that drm_bridge_attach should *not* be balanced with a drm_bridge_detach call in the driver, so this seems quite wrong. The DRM core itself should handle detaching the bridge, not the driver. Is there any reason why you need to do things differently for DSI? Cheers, Paul > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > --- > drivers/gpu/drm/drm_bridge.c | 1 + > include/drm/drm_bridge.h | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c > index 138b2711d389..569d4f345429 100644 > --- a/drivers/gpu/drm/drm_bridge.c > +++ b/drivers/gpu/drm/drm_bridge.c > @@ -159,6 +159,7 @@ void drm_bridge_detach(struct drm_bridge *bridge) > > bridge->dev = NULL; > } > +EXPORT_SYMBOL(drm_bridge_detach); > > /** > * DOC: bridge callbacks > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h > index 9da8c93f7976..4955e3e50fa4 100644 > --- a/include/drm/drm_bridge.h > +++ b/include/drm/drm_bridge.h > @@ -301,6 +301,7 @@ void drm_bridge_remove(struct drm_bridge *bridge); > struct drm_bridge *of_drm_find_bridge(struct device_node *np); > int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge, > struct drm_bridge *previous); > +void drm_bridge_detach(struct drm_bridge *bridge); > > bool drm_bridge_mode_fixup(struct drm_bridge *bridge, > const struct drm_display_mode *mode, > -- > 2.18.0.321.gffc6fa0e3 >
Hi Paul, On Fri, Mar 15, 2019 at 6:58 PM Paul Kocialkowski <paul.kocialkowski@bootlin.com> wrote: > > Hi Jakan, > > On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote: > > Export drm_bridge_detach from drm bridge core so-that it > > can use on respective interface or bridge driver while > > detaching the bridge. > > I don't see why this change is required based on the commit log. The > DRM bridge code clearly indicates that drm_bridge_attach should *not* > be balanced with a drm_bridge_detach call in the driver, so this seems > quite wrong. > > The DRM core itself should handle detaching the bridge, not the driver. > Is there any reason why you need to do things differently for DSI? Yes, you are correct the detach of bridge is being taking care via drm_encoder_cleanup. This patch exported explicitly, since we need to taken care bridge detach during unbind even exynos_drm_dsi in other patch seems using detach by explicitly pointing. so I think the better approach is to use drm_encoder_cleanup in unbind, what do you say? Jagan.
Hi, Le lundi 18 mars 2019 à 22:18 +0530, Jagan Teki a écrit : > Hi Paul, > > On Fri, Mar 15, 2019 at 6:58 PM Paul Kocialkowski > <paul.kocialkowski@bootlin.com> wrote: > > Hi Jakan, > > > > On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote: > > > Export drm_bridge_detach from drm bridge core so-that it > > > can use on respective interface or bridge driver while > > > detaching the bridge. > > > > I don't see why this change is required based on the commit log. The > > DRM bridge code clearly indicates that drm_bridge_attach should *not* > > be balanced with a drm_bridge_detach call in the driver, so this seems > > quite wrong. > > > > The DRM core itself should handle detaching the bridge, not the driver. > > Is there any reason why you need to do things differently for DSI? > > Yes, you are correct the detach of bridge is being taking care via > drm_encoder_cleanup. This patch exported explicitly, since we need to > taken care bridge detach during unbind even exynos_drm_dsi in other > patch seems using detach by explicitly pointing. I can see that from your patches, but you are not explaining why you need the change. And if the framework doesn't work for your case, you should certainly try and fix the framework instead of working around the issue. Anyway, you should probably look into using drm_panel_bridge_add, it might fix the underlying issue on its own. > so I think the better approach is to use drm_encoder_cleanup in > unbind, what do you say? I any case, you need to state what your problem is (in the commit log, and not even in subsequent discussions) so that we can have a chance to understand it and provide some feedback about what is an appropriate fix and what is not. We can't understand the fix if we can't understand the underlying issue. Cheers, Paul
On Mon, Mar 18, 2019 at 10:27 PM Paul Kocialkowski <paul.kocialkowski@bootlin.com> wrote: > > Hi, > > Le lundi 18 mars 2019 à 22:18 +0530, Jagan Teki a écrit : > > Hi Paul, > > > > On Fri, Mar 15, 2019 at 6:58 PM Paul Kocialkowski > > <paul.kocialkowski@bootlin.com> wrote: > > > Hi Jakan, > > > > > > On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote: > > > > Export drm_bridge_detach from drm bridge core so-that it > > > > can use on respective interface or bridge driver while > > > > detaching the bridge. > > > > > > I don't see why this change is required based on the commit log. The > > > DRM bridge code clearly indicates that drm_bridge_attach should *not* > > > be balanced with a drm_bridge_detach call in the driver, so this seems > > > quite wrong. > > > > > > The DRM core itself should handle detaching the bridge, not the driver. > > > Is there any reason why you need to do things differently for DSI? > > > > Yes, you are correct the detach of bridge is being taking care via > > drm_encoder_cleanup. This patch exported explicitly, since we need to > > taken care bridge detach during unbind even exynos_drm_dsi in other > > patch seems using detach by explicitly pointing. > > I can see that from your patches, but you are not explaining why you > need the change. And if the framework doesn't work for your case, you > should certainly try and fix the framework instead of working around > the issue. Please see below comments. > > Anyway, you should probably look into using drm_panel_bridge_add, it > might fix the underlying issue on its own. > > > so I think the better approach is to use drm_encoder_cleanup in > > unbind, what do you say? > > I any case, you need to state what your problem is (in the commit log, > and not even in subsequent discussions) so that we can have a chance to > understand it and provide some feedback about what is an appropriate > fix and what is not. We can't understand the fix if we can't understand > the underlying issue. True, if my intentions is trying to fix some issue, but as I said in previous mail since the other dsi (exynos_drm_dsi) driver is explicitly detaching I presume it require or missed the export, not thought about fix and neither I mentioned on the commit head. Anyway thanks for the review, will update the code accordingly in next version.
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index 138b2711d389..569d4f345429 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -159,6 +159,7 @@ void drm_bridge_detach(struct drm_bridge *bridge) bridge->dev = NULL; } +EXPORT_SYMBOL(drm_bridge_detach); /** * DOC: bridge callbacks diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h index 9da8c93f7976..4955e3e50fa4 100644 --- a/include/drm/drm_bridge.h +++ b/include/drm/drm_bridge.h @@ -301,6 +301,7 @@ void drm_bridge_remove(struct drm_bridge *bridge); struct drm_bridge *of_drm_find_bridge(struct device_node *np); int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge, struct drm_bridge *previous); +void drm_bridge_detach(struct drm_bridge *bridge); bool drm_bridge_mode_fixup(struct drm_bridge *bridge, const struct drm_display_mode *mode,