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@chromium.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