[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171128182121.GA116479@google.com>
Date: Tue, 28 Nov 2017 10:21:23 -0800
From: Brian Norris <briannorris@...omium.org>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Archit Taneja <architt@...eaurora.org>,
Andrzej Hajda <a.hajda@...sung.com>,
David Airlie <airlied@...ux.ie>,
Yannick Fertre <yannick.fertre@...com>,
Philippe Cornu <philippe.cornu@...com>,
Benjamin Gaignard <benjamin.gaignard@...aro.org>,
Vincent Abriou <vincent.abriou@...com>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
Sean Paul <seanpaul@...omium.org>,
Nickey Yang <nickey.yang@...k-chips.com>, hl@...k-chips.com,
linux-rockchip@...ts.infradead.org, mka@...omium.org,
Jeffy Chen <jeffy.chen@...k-chips.com>,
Doug Anderson <dianders@...omium.org>
Subject: Re: [PATCH] drm/bridge/synopsis: stop clobbering drvdata
Hi Laurent,
On Tue, Nov 28, 2017 at 02:51:46PM +0200, Laurent Pinchart wrote:
> Hi Brian,
>
> Thank you for the patch.
>
> I'd mention dw-mipi-dsi in the subject line as the directory contains the dw-
> hdmi driver as well that this patch doesn't touch.
Yep. Does it need another tag in the subject? e.g., '.../dw-mipi-dsi:'?
> On Tuesday, 28 November 2017 03:05:38 EET Brian Norris wrote:
> > Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
> > parent driver might need to own this.
>
> By parent driver I assume you mean a glue driver that binds to the SoC-
> specific compatible string for the DSI transmitter.
Indeed. Nickey picked this up for his Rockchip driver submission, but
maybe we should reword the commit message a bit.
> > Instead, let's return our
> > 'dw_mipi_dsi' object and have callers pass that back to us for removal.
> >
> > Signed-off-by: Brian Norris <briannorris@...omium.org>
>
> Wouldn't it be cleaner to embed the dw_mipi_dsi structure in the parent-
> specific data structure (struct dw_mipi_dsi_stm and struct
> dw_mipi_dsi_rockchip when the "[PATCH v3 0/5] Update ROCKCHIP DSI driver that
> uses dw-mipi-dsi bridge" patch series will land) instead of allocating it
> dynamically ? We would then have a single object to track.
I suppose we could do that too. But that would require exposing the
whole layout of 'struct dw_mipi_dsi' to users. Do we want to sacrifice
the enforced separation for a little bit of nicer object handling?
Also, this was modeled a bit after the similar rework needed to untangle
the drvdata handling in the Rockchip analogix DP driver vs. the analogix
bridge DP code:
[PATCH v6 03/10] drm/bridge: analogix: Do not use device's drvdata
https://patchwork.kernel.org/patch/10015875/
Brian
Powered by blists - more mailing lists