linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Rosin <peda@axentia.se>
To: Jyri Sarha <jsarha@ti.com>, linux-kernel@vger.kernel.org
Cc: Archit Taneja <architt@codeaurora.org>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH v2 10/26] drm/bridge: panel: provide an owner .odev device
Date: Tue, 8 May 2018 09:58:49 +0200	[thread overview]
Message-ID: <c446bdec-bf31-f192-c270-d672011d4503@axentia.se> (raw)
In-Reply-To: <5130ea2e-e1cd-53dd-25da-038deb91a13d@ti.com>

On 2018-05-08 08:51, Jyri Sarha wrote:
> On 05/04/18 16:51, Peter Rosin wrote:
>> It gets rid of an #ifdef and the .of_node member is going away.
>>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
>> ---
>>  drivers/gpu/drm/bridge/panel.c | 4 +---
>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
>> index 6d99d4a3beb3..f43d77b5ed20 100644
>> --- a/drivers/gpu/drm/bridge/panel.c
>> +++ b/drivers/gpu/drm/bridge/panel.c
>> @@ -169,10 +169,8 @@ struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
>>  	panel_bridge->connector_type = connector_type;
>>  	panel_bridge->panel = panel;
>>  
>> +	panel_bridge->bridge.odev = panel->dev;
> 
> I am afraid this approach will eventually conflict with my lately
> accepted patch[1].

I don't see how? The links are refcounted. So, if there is one link
each for the panel and bridge between the drm device and the panel
device that link will simply get two references. If/when the panel
device then goes away, the drm device will be brought down because
of that link (with two references, but that is irrelevant). When
the drm device is brought down, it will (presumably) bring down the
bridge as well (which will fix the refcount as the bridge link is
killed as part of that).

Or have you done some test and seen an actual problem?

> The panel already has a device pointer of its own, and technically the
> bridge element created here is created by the master drm device itself.

Not always, some bridges also call drm_panel_bridge_add for connecting
its output to either a panel or another bridge.

And by that line of argument, the devm_kzalloc in drm_panel_bridge_add
attaches the bridge memory to the wrong device as well. Maybe that
should be fixed? Seems orthogonal though, but it would introduce a
natural struct device in that function to assign to .odev. I think
the device owning the bridge memory should be the same as the .odev
device of the bridge.

> I suggest assigning odev here to NULL or to master drm device itself.

I'd rather not use NULL, since it is nice to be able to rely on the
.odev being there, and WARN if it isn't.

Cheers,
Peter

> Best regards,
> Jyri
> 
>>  	panel_bridge->bridge.funcs = &panel_bridge_bridge_funcs;
>> -#ifdef CONFIG_OF
>> -	panel_bridge->bridge.of_node = panel->dev->of_node;
>> -#endif
>>  
>>  	drm_bridge_add(&panel_bridge->bridge);
>>  
>>
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2018-April/174559.html
> 

  reply	other threads:[~2018-05-08  7:58 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-04 13:51 [PATCH v2 00/26] device link, bridge supplier <-> drm device Peter Rosin
2018-05-04 13:51 ` [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device Peter Rosin
2018-05-09 15:08   ` Andrzej Hajda
2018-05-09 15:53     ` Peter Rosin
2018-05-09 22:21       ` Peter Rosin
2018-05-10  7:00         ` Andrzej Hajda
2018-05-04 13:51 ` [PATCH v2 02/26] drm/bridge: adv7511: provide " Peter Rosin
2018-05-04 13:51 ` [PATCH v2 03/26] drm/bridge/analogix: core: specify the owner .odev of the bridge Peter Rosin
2018-05-04 13:51 ` [PATCH v2 04/26] drm/bridge: analogix-anx78xx: provide an owner .odev device Peter Rosin
2018-05-04 13:51 ` [PATCH v2 05/26] drm/bridge: cdns-dsi: " Peter Rosin
2018-05-04 13:51 ` [PATCH v2 06/26] drm/bridge: vga-dac: " Peter Rosin
2018-05-04 13:51 ` [PATCH v2 07/26] drm/bridge: lvds-encoder: " Peter Rosin
2018-05-04 13:51 ` [PATCH v2 08/26] drm/bridge: megachips-stdpxxxx-ge-b850v3-fw: " Peter Rosin
2018-05-04 13:51 ` [PATCH v2 09/26] drm/bridge: nxp-ptn3460: " Peter Rosin
2018-05-04 13:51 ` [PATCH v2 10/26] drm/bridge: panel: " Peter Rosin
2018-05-08  6:51   ` Jyri Sarha
2018-05-08  7:58     ` Peter Rosin [this message]
2018-05-08 10:30       ` Daniel Vetter
2018-05-08 12:25       ` Jyri Sarha
2018-05-04 13:51 ` [PATCH v2 11/26] drm/bridge: ps8622: " Peter Rosin
2018-05-04 13:51 ` [PATCH v2 12/26] drm/bridge: sii902x: " Peter Rosin
2018-05-04 13:51 ` [PATCH v2 13/26] drm/bridge: sii9234: " Peter Rosin
2018-05-04 13:52 ` [PATCH v2 14/26] drm/bridge: sii8620: " Peter Rosin
2018-05-04 13:52 ` [PATCH v2 15/26] drm/bridge: synopsys: provide an owner .odev device for the bridges Peter Rosin
2018-05-04 13:52 ` [PATCH v2 16/26] drm/bridge: tc358767: provide an owner .odev device Peter Rosin
2018-05-04 13:52 ` [PATCH v2 17/26] drm/bridge: thc63lvd1024: " Peter Rosin
2018-05-04 13:52 ` [PATCH v2 18/26] drm/bridge: ti-tfp410: " Peter Rosin
2018-05-04 13:52 ` [PATCH v2 19/26] drm/exynos: mic: provide an owner .odev device for the bridge Peter Rosin
2018-05-04 13:52 ` [PATCH v2 20/26] drm/mediatek: hdmi: " Peter Rosin
2018-05-04 13:52 ` [PATCH v2 21/26] drm/msm: specify the owner .odev of the bridges Peter Rosin
2018-05-04 13:52 ` [PATCH v2 22/26] drm/rcar-du: lvds: provide an owner .odev device for the bridge Peter Rosin
2018-05-04 13:52 ` [PATCH v2 23/26] drm/sti: provide an owner .odev device for the bridges Peter Rosin
2018-05-04 13:52 ` [PATCH v2 24/26] drm/bridge: remove the .of_node member Peter Rosin
2018-05-04 13:52 ` [PATCH v2 25/26] drm/bridge: require the owner .odev to be filled in on drm_bridge_add/attach Peter Rosin
2018-05-10  7:13   ` Andrzej Hajda
2018-05-04 13:52 ` [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer Peter Rosin
2018-05-07 12:59   ` Andrzej Hajda
2018-05-07 13:43     ` Peter Rosin
2018-05-08  9:03       ` Andrzej Hajda
2018-05-07 13:53     ` Daniel Vetter
2018-05-08  6:36       ` Andrzej Hajda
2018-05-10  8:10   ` Andrzej Hajda
2018-05-11  7:37     ` Peter Rosin
2018-05-14 16:28       ` Daniel Vetter
2018-05-14 20:40         ` Peter Rosin
2018-05-15 10:22           ` Daniel Vetter
2018-05-15 11:09             ` Peter Rosin
2018-05-16  9:31               ` Daniel Vetter
2018-05-07 13:56 ` [PATCH v2 00/26] device link, bridge supplier <-> drm device Daniel Vetter
2018-05-07 14:09   ` Peter Rosin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c446bdec-bf31-f192-c270-d672011d4503@axentia.se \
    --to=peda@axentia.se \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=architt@codeaurora.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jsarha@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).