Usual I2C configured DSI bridge drivers have drm_bridge_add
in probe and mipi_dsi_attach in bridge attach functions.
With, this approach the drm pipeline is unable to find the
dsi bridge in stm drm drivers since the dw-mipi-dsi bridge is
adding drm bridge during bridge attach operations instead of
the probe.
This specific issue may not encounter for rockchip drm dsi
drivers, since rockchip drm uses component binding operations,
unlike stm drm drivers.
So, possible solutions are
1. Move drm_bridge_add into the dw-mipi-dsi probe.
2. Add mipi_dsi_attach in the bridge drivers probe.
3. Add component binding operations for stm drm drivers.
Option 1 is a relatively possible solution as most of the
mainline drm dsi with bridge drivers have a similar approach
to their dsi host vs bridge registration.
Signed-off-by: Jagan Teki <[email protected]>
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 35 +++++++++----------
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 6b268f9445b3..8a535041f071 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -314,8 +314,6 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
{
struct dw_mipi_dsi *dsi = host_to_dsi(host);
const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data;
- struct drm_bridge *bridge;
- struct drm_panel *panel;
int ret;
if (device->lanes > dsi->plat_data->max_data_lanes) {
@@ -329,22 +327,6 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- ret = drm_of_find_panel_or_bridge(host->dev->of_node, 1, 0,
- &panel, &bridge);
- if (ret)
- return ret;
-
- if (panel) {
- bridge = drm_panel_bridge_add_typed(panel,
- DRM_MODE_CONNECTOR_DSI);
- if (IS_ERR(bridge))
- return PTR_ERR(bridge);
- }
-
- dsi->panel_bridge = bridge;
-
- drm_bridge_add(&dsi->bridge);
-
if (pdata->host_ops && pdata->host_ops->attach) {
ret = pdata->host_ops->attach(pdata->priv_data, device);
if (ret < 0)
@@ -1105,6 +1087,8 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
struct device *dev = &pdev->dev;
struct reset_control *apb_rst;
struct dw_mipi_dsi *dsi;
+ struct drm_bridge *bridge;
+ struct drm_panel *panel;
int ret;
dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
@@ -1167,6 +1151,20 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
dw_mipi_dsi_debugfs_init(dsi);
pm_runtime_enable(dev);
+ ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
+ &panel, &bridge);
+ if (ret)
+ return ERR_PTR(ret);
+
+ if (panel) {
+ bridge = drm_panel_bridge_add_typed(panel,
+ DRM_MODE_CONNECTOR_DSI);
+ if (IS_ERR(bridge))
+ return ERR_PTR(-ENODEV);
+ }
+
+ dsi->panel_bridge = bridge;
+
dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
dsi->dsi_host.dev = dev;
ret = mipi_dsi_host_register(&dsi->dsi_host);
@@ -1181,6 +1179,7 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
#ifdef CONFIG_OF
dsi->bridge.of_node = pdev->dev.of_node;
#endif
+ drm_bridge_add(&dsi->bridge);
return dsi;
}
--
2.25.1
Am Mittwoch, 3. Februar 2021, 10:13:06 CET schrieb Jagan Teki:
> Usual I2C configured DSI bridge drivers have drm_bridge_add
> in probe and mipi_dsi_attach in bridge attach functions.
>
> With, this approach the drm pipeline is unable to find the
> dsi bridge in stm drm drivers since the dw-mipi-dsi bridge is
> adding drm bridge during bridge attach operations instead of
> the probe.
Shouldn't the STM drm driver not simply defer if it's missing
a bridge that is referenced in the devicetree or somewhere?
> This specific issue may not encounter for rockchip drm dsi
> drivers, since rockchip drm uses component binding operations,
> unlike stm drm drivers.
>
> So, possible solutions are
> 1. Move drm_bridge_add into the dw-mipi-dsi probe.
> 2. Add mipi_dsi_attach in the bridge drivers probe.
> 3. Add component binding operations for stm drm drivers.
personally I'd like number (3) a lot ;-) .
With your approach, at least the component-based variants would
end up with multiple probe cycles, getting clocks etc until at some point
the panel has probed, where in the current way of things, the probe is
done once and we continue bringup once the panel has probed and called
dsi-attach to signal it is present.
Which was actually what Andrzej wished for, when I moved the Rockchip
dsi to the common driver.
Or at least make it configurable via a param to the common dw-dsi probe
function. Especially as I also need the dsi bridge-less when used as a
simple means for the configuring the internal dphy to rx-mode, see [0]
Heiko
[0] https://lore.kernel.org/dri-devel/[email protected]/
> Option 1 is a relatively possible solution as most of the
> mainline drm dsi with bridge drivers have a similar approach
> to their dsi host vs bridge registration.
>
> Signed-off-by: Jagan Teki <[email protected]>
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 35 +++++++++----------
> 1 file changed, 17 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 6b268f9445b3..8a535041f071 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -314,8 +314,6 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
> {
> struct dw_mipi_dsi *dsi = host_to_dsi(host);
> const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data;
> - struct drm_bridge *bridge;
> - struct drm_panel *panel;
> int ret;
>
> if (device->lanes > dsi->plat_data->max_data_lanes) {
> @@ -329,22 +327,6 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
> dsi->format = device->format;
> dsi->mode_flags = device->mode_flags;
>
> - ret = drm_of_find_panel_or_bridge(host->dev->of_node, 1, 0,
> - &panel, &bridge);
> - if (ret)
> - return ret;
> -
> - if (panel) {
> - bridge = drm_panel_bridge_add_typed(panel,
> - DRM_MODE_CONNECTOR_DSI);
> - if (IS_ERR(bridge))
> - return PTR_ERR(bridge);
> - }
> -
> - dsi->panel_bridge = bridge;
> -
> - drm_bridge_add(&dsi->bridge);
> -
> if (pdata->host_ops && pdata->host_ops->attach) {
> ret = pdata->host_ops->attach(pdata->priv_data, device);
> if (ret < 0)
> @@ -1105,6 +1087,8 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> struct device *dev = &pdev->dev;
> struct reset_control *apb_rst;
> struct dw_mipi_dsi *dsi;
> + struct drm_bridge *bridge;
> + struct drm_panel *panel;
> int ret;
>
> dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
> @@ -1167,6 +1151,20 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> dw_mipi_dsi_debugfs_init(dsi);
> pm_runtime_enable(dev);
>
> + ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
> + &panel, &bridge);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + if (panel) {
> + bridge = drm_panel_bridge_add_typed(panel,
> + DRM_MODE_CONNECTOR_DSI);
> + if (IS_ERR(bridge))
> + return ERR_PTR(-ENODEV);
> + }
> +
> + dsi->panel_bridge = bridge;
> +
> dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
> dsi->dsi_host.dev = dev;
> ret = mipi_dsi_host_register(&dsi->dsi_host);
> @@ -1181,6 +1179,7 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> #ifdef CONFIG_OF
> dsi->bridge.of_node = pdev->dev.of_node;
> #endif
> + drm_bridge_add(&dsi->bridge);
>
> return dsi;
> }
>
Hello Jagan, I tested your patch on the stm32mp1 board.
Unfortunately, the dsi panel does not probe well with this patch. The
problem is due to the panel which is placed in the node of the dsi
bridge (no problem with i2c devices).
Regarding component bindings for stm drivers, I am currently working on
a new version.
Best regards
Yannick
On 2/3/21 10:13 AM, Jagan Teki wrote:
> Usual I2C configured DSI bridge drivers have drm_bridge_add
> in probe and mipi_dsi_attach in bridge attach functions.
>
> With, this approach the drm pipeline is unable to find the
> dsi bridge in stm drm drivers since the dw-mipi-dsi bridge is
> adding drm bridge during bridge attach operations instead of
> the probe.
>
> This specific issue may not encounter for rockchip drm dsi
> drivers, since rockchip drm uses component binding operations,
> unlike stm drm drivers.
>
> So, possible solutions are
> 1. Move drm_bridge_add into the dw-mipi-dsi probe.
> 2. Add mipi_dsi_attach in the bridge drivers probe.
> 3. Add component binding operations for stm drm drivers.
>
> Option 1 is a relatively possible solution as most of the
> mainline drm dsi with bridge drivers have a similar approach
> to their dsi host vs bridge registration.
>
> Signed-off-by: Jagan Teki <[email protected]>
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 35 +++++++++----------
> 1 file changed, 17 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 6b268f9445b3..8a535041f071 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -314,8 +314,6 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
> {
> struct dw_mipi_dsi *dsi = host_to_dsi(host);
> const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data;
> - struct drm_bridge *bridge;
> - struct drm_panel *panel;
> int ret;
>
> if (device->lanes > dsi->plat_data->max_data_lanes) {
> @@ -329,22 +327,6 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
> dsi->format = device->format;
> dsi->mode_flags = device->mode_flags;
>
> - ret = drm_of_find_panel_or_bridge(host->dev->of_node, 1, 0,
> - &panel, &bridge);
> - if (ret)
> - return ret;
> -
> - if (panel) {
> - bridge = drm_panel_bridge_add_typed(panel,
> - DRM_MODE_CONNECTOR_DSI);
> - if (IS_ERR(bridge))
> - return PTR_ERR(bridge);
> - }
> -
> - dsi->panel_bridge = bridge;
> -
> - drm_bridge_add(&dsi->bridge);
> -
> if (pdata->host_ops && pdata->host_ops->attach) {
> ret = pdata->host_ops->attach(pdata->priv_data, device);
> if (ret < 0)
> @@ -1105,6 +1087,8 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> struct device *dev = &pdev->dev;
> struct reset_control *apb_rst;
> struct dw_mipi_dsi *dsi;
> + struct drm_bridge *bridge;
> + struct drm_panel *panel;
> int ret;
>
> dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
> @@ -1167,6 +1151,20 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> dw_mipi_dsi_debugfs_init(dsi);
> pm_runtime_enable(dev);
>
> + ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
> + &panel, &bridge);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + if (panel) {
> + bridge = drm_panel_bridge_add_typed(panel,
> + DRM_MODE_CONNECTOR_DSI);
> + if (IS_ERR(bridge))
> + return ERR_PTR(-ENODEV);
> + }
> +
> + dsi->panel_bridge = bridge;
> +
> dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
> dsi->dsi_host.dev = dev;
> ret = mipi_dsi_host_register(&dsi->dsi_host);
> @@ -1181,6 +1179,7 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> #ifdef CONFIG_OF
> dsi->bridge.of_node = pdev->dev.of_node;
> #endif
> + drm_bridge_add(&dsi->bridge);
>
> return dsi;
> }
>
Hi Heiko,
On Wed, Feb 03, 2021 at 01:05:43PM +0100, Heiko Stübner wrote:
> Am Mittwoch, 3. Februar 2021, 10:13:06 CET schrieb Jagan Teki:
> > Usual I2C configured DSI bridge drivers have drm_bridge_add
> > in probe and mipi_dsi_attach in bridge attach functions.
> >
> > With, this approach the drm pipeline is unable to find the
> > dsi bridge in stm drm drivers since the dw-mipi-dsi bridge is
> > adding drm bridge during bridge attach operations instead of
> > the probe.
>
> Shouldn't the STM drm driver not simply defer if it's missing
> a bridge that is referenced in the devicetree or somewhere?
>
> > This specific issue may not encounter for rockchip drm dsi
> > drivers, since rockchip drm uses component binding operations,
> > unlike stm drm drivers.
> >
> > So, possible solutions are
> > 1. Move drm_bridge_add into the dw-mipi-dsi probe.
> > 2. Add mipi_dsi_attach in the bridge drivers probe.
> > 3. Add component binding operations for stm drm drivers.
>
> personally I'd like number (3) a lot ;-) .
We have different opinions on this topic :-) The component framework
adds a layer of complexity that can be avoided with probe deferral in
most cases. The main reason why probe deferral isn't always enough is
circular dependencies, which unless I'm mistaken isn't an issue here.
> With your approach, at least the component-based variants would
> end up with multiple probe cycles, getting clocks etc until at some point
> the panel has probed, where in the current way of things, the probe is
> done once and we continue bringup once the panel has probed and called
> dsi-attach to signal it is present.
>
> Which was actually what Andrzej wished for, when I moved the Rockchip
> dsi to the common driver.
>
> Or at least make it configurable via a param to the common dw-dsi probe
> function. Especially as I also need the dsi bridge-less when used as a
> simple means for the configuring the internal dphy to rx-mode, see [0]
>
> Heiko
>
> [0] https://lore.kernel.org/dri-devel/[email protected]/
>
> > Option 1 is a relatively possible solution as most of the
> > mainline drm dsi with bridge drivers have a similar approach
> > to their dsi host vs bridge registration.
> >
> > Signed-off-by: Jagan Teki <[email protected]>
> > ---
> > drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 35 +++++++++----------
> > 1 file changed, 17 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> > index 6b268f9445b3..8a535041f071 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> > @@ -314,8 +314,6 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
> > {
> > struct dw_mipi_dsi *dsi = host_to_dsi(host);
> > const struct dw_mipi_dsi_plat_data *pdata = dsi->plat_data;
> > - struct drm_bridge *bridge;
> > - struct drm_panel *panel;
> > int ret;
> >
> > if (device->lanes > dsi->plat_data->max_data_lanes) {
> > @@ -329,22 +327,6 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host *host,
> > dsi->format = device->format;
> > dsi->mode_flags = device->mode_flags;
> >
> > - ret = drm_of_find_panel_or_bridge(host->dev->of_node, 1, 0,
> > - &panel, &bridge);
> > - if (ret)
> > - return ret;
> > -
> > - if (panel) {
> > - bridge = drm_panel_bridge_add_typed(panel,
> > - DRM_MODE_CONNECTOR_DSI);
> > - if (IS_ERR(bridge))
> > - return PTR_ERR(bridge);
> > - }
> > -
> > - dsi->panel_bridge = bridge;
> > -
> > - drm_bridge_add(&dsi->bridge);
> > -
> > if (pdata->host_ops && pdata->host_ops->attach) {
> > ret = pdata->host_ops->attach(pdata->priv_data, device);
> > if (ret < 0)
> > @@ -1105,6 +1087,8 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> > struct device *dev = &pdev->dev;
> > struct reset_control *apb_rst;
> > struct dw_mipi_dsi *dsi;
> > + struct drm_bridge *bridge;
> > + struct drm_panel *panel;
> > int ret;
> >
> > dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
> > @@ -1167,6 +1151,20 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> > dw_mipi_dsi_debugfs_init(dsi);
> > pm_runtime_enable(dev);
> >
> > + ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
> > + &panel, &bridge);
> > + if (ret)
> > + return ERR_PTR(ret);
> > +
> > + if (panel) {
> > + bridge = drm_panel_bridge_add_typed(panel,
> > + DRM_MODE_CONNECTOR_DSI);
> > + if (IS_ERR(bridge))
> > + return ERR_PTR(-ENODEV);
> > + }
> > +
> > + dsi->panel_bridge = bridge;
> > +
> > dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
> > dsi->dsi_host.dev = dev;
> > ret = mipi_dsi_host_register(&dsi->dsi_host);
> > @@ -1181,6 +1179,7 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> > #ifdef CONFIG_OF
> > dsi->bridge.of_node = pdev->dev.of_node;
> > #endif
> > + drm_bridge_add(&dsi->bridge);
> >
> > return dsi;
> > }
--
Regards,
Laurent Pinchart
Hi Yannick,
Thanks for testing this change.
On Mon, Feb 15, 2021 at 1:39 PM yannick Fertre
<[email protected]> wrote:
>
> Hello Jagan, I tested your patch on the stm32mp1 board.
> Unfortunately, the dsi panel does not probe well with this patch. The
> problem is due to the panel which is placed in the node of the dsi
> bridge (no problem with i2c devices).
>
> Regarding component bindings for stm drivers, I am currently working on
> a new version.
1. All non-I2C bridges are attaching dsi via mipi_dsi_attach during
the bridge controller probe and that would be expecting
panel_or_bridge need to be in DSI host attach.
2. I2C bridges are attaching dsi via mipi_dsi_attach during the bridge
attach function and that would be expecting panel_or_bridge need to be
in DSI probe.
I believe these types of DSI controllers followed by DSI panels,
bridges are not available in Mainline. if I'm not mistaken.
Adding component bindings in this regards never helps, this seems to
be common for component or non-components DSI host drivers.
One way to handle this issue can be during drm helper initialization,
like attaching the dsi host instead of calling directly from bridge or
panel drivers.
Laurent, Heiko - let me know your suggestions if it make sense, thanks.
Jagan.
Hi Jagan,
On Wed, 3 Feb 2021 at 09:13, Jagan Teki <[email protected]> wrote:
> @@ -1167,6 +1151,20 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> dw_mipi_dsi_debugfs_init(dsi);
> pm_runtime_enable(dev);
>
> + ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
> + &panel, &bridge);
> + if (ret)
> + return ERR_PTR(ret);
On RK3399 if the error is EPROBE_DEFER, __dw_mipi_dsi_probe can be
called again and result in the following errors:
[ 0.717589] debugfs: Directory 'ff960000.mipi' with parent '/'
already present!
[ 0.717601] dw-mipi-dsi-rockchip ff960000.mipi: failed to create debugfs root
[ 0.717606] dw-mipi-dsi-rockchip ff960000.mipi: Unbalanced pm_runtime_enable!
Regards,
Jonathan
Hi Jonathan,
On Fri, Jun 18, 2021 at 6:40 PM Jonathan Liu <[email protected]> wrote:
>
> Hi Jagan,
>
> On Wed, 3 Feb 2021 at 09:13, Jagan Teki <[email protected]> wrote:
> > @@ -1167,6 +1151,20 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> > dw_mipi_dsi_debugfs_init(dsi);
> > pm_runtime_enable(dev);
> >
> > + ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
> > + &panel, &bridge);
> > + if (ret)
> > + return ERR_PTR(ret);
>
> On RK3399 if the error is EPROBE_DEFER, __dw_mipi_dsi_probe can be
> called again and result in the following errors:
> [ 0.717589] debugfs: Directory 'ff960000.mipi' with parent '/'
> already present!
> [ 0.717601] dw-mipi-dsi-rockchip ff960000.mipi: failed to create debugfs root
> [ 0.717606] dw-mipi-dsi-rockchip ff960000.mipi: Unbalanced pm_runtime_enable!
Is this when you test bridge on rk3399 or panel?
Jagan.
Hi Jagan,
On Thu, 24 Jun 2021 at 22:34, Jagan Teki <[email protected]> wrote:
>
> Hi Jonathan,
>
> On Fri, Jun 18, 2021 at 6:40 PM Jonathan Liu <[email protected]> wrote:
> >
> > Hi Jagan,
> >
> > On Wed, 3 Feb 2021 at 09:13, Jagan Teki <[email protected]> wrote:
> > > @@ -1167,6 +1151,20 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> > > dw_mipi_dsi_debugfs_init(dsi);
> > > pm_runtime_enable(dev);
> > >
> > > + ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
> > > + &panel, &bridge);
> > > + if (ret)
> > > + return ERR_PTR(ret);
> >
> > On RK3399 if the error is EPROBE_DEFER, __dw_mipi_dsi_probe can be
> > called again and result in the following errors:
> > [ 0.717589] debugfs: Directory 'ff960000.mipi' with parent '/'
> > already present!
> > [ 0.717601] dw-mipi-dsi-rockchip ff960000.mipi: failed to create debugfs root
> > [ 0.717606] dw-mipi-dsi-rockchip ff960000.mipi: Unbalanced pm_runtime_enable!
>
> Is this when you test bridge on rk3399 or panel?
MIPI-DSI to LVDS bridge.
Regards,
Jonathan
CC'ing Maxime Ripard.
Maxime, is this similar to the issue we've recently discussed with the
VC4 DSI encoder ?
On Thu, Jun 24, 2021 at 10:39:48PM +1000, Jonathan Liu wrote:
> On Thu, 24 Jun 2021 at 22:34, Jagan Teki wrote:
> > On Fri, Jun 18, 2021 at 6:40 PM Jonathan Liu wrote:
> > > On Wed, 3 Feb 2021 at 09:13, Jagan Teki wrote:
> > > > @@ -1167,6 +1151,20 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> > > > dw_mipi_dsi_debugfs_init(dsi);
> > > > pm_runtime_enable(dev);
> > > >
> > > > + ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
> > > > + &panel, &bridge);
> > > > + if (ret)
> > > > + return ERR_PTR(ret);
> > >
> > > On RK3399 if the error is EPROBE_DEFER, __dw_mipi_dsi_probe can be
> > > called again and result in the following errors:
> > > [ 0.717589] debugfs: Directory 'ff960000.mipi' with parent '/' already present!
> > > [ 0.717601] dw-mipi-dsi-rockchip ff960000.mipi: failed to create debugfs root
> > > [ 0.717606] dw-mipi-dsi-rockchip ff960000.mipi: Unbalanced pm_runtime_enable!
> >
> > Is this when you test bridge on rk3399 or panel?
>
> MIPI-DSI to LVDS bridge.
--
Regards,
Laurent Pinchart
Hi,
On Thu, Jun 24, 2021 at 03:51:05PM +0300, Laurent Pinchart wrote:
> CC'ing Maxime Ripard.
>
> Maxime, is this similar to the issue we've recently discussed with the
> VC4 DSI encoder ?
>
> On Thu, Jun 24, 2021 at 10:39:48PM +1000, Jonathan Liu wrote:
> > On Thu, 24 Jun 2021 at 22:34, Jagan Teki wrote:
> > > On Fri, Jun 18, 2021 at 6:40 PM Jonathan Liu wrote:
> > > > On Wed, 3 Feb 2021 at 09:13, Jagan Teki wrote:
> > > > > @@ -1167,6 +1151,20 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> > > > > dw_mipi_dsi_debugfs_init(dsi);
> > > > > pm_runtime_enable(dev);
> > > > >
> > > > > + ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
> > > > > + &panel, &bridge);
> > > > > + if (ret)
> > > > > + return ERR_PTR(ret);
> > > >
> > > > On RK3399 if the error is EPROBE_DEFER, __dw_mipi_dsi_probe can be
> > > > called again and result in the following errors:
> > > > [ 0.717589] debugfs: Directory 'ff960000.mipi' with parent '/' already present!
> > > > [ 0.717601] dw-mipi-dsi-rockchip ff960000.mipi: failed to create debugfs root
> > > > [ 0.717606] dw-mipi-dsi-rockchip ff960000.mipi: Unbalanced pm_runtime_enable!
> > >
> > > Is this when you test bridge on rk3399 or panel?
> >
> > MIPI-DSI to LVDS bridge.
It looks more like a driver that doesn't free its resources properly on EPROBE_DEFER?
Maxime