On 28/08/2019 08:05, Andrzej Hajda wrote: > On 27.08.2019 22:03, John Stultz wrote: >> On Mon, Aug 19, 2019 at 3:27 PM John Stultz <john.stultz@xxxxxxxxxx> wrote: >>> On Thu, Jun 27, 2019 at 8:18 AM Matt Redfearn <matt.redfearn@xxxxxxxxxx> wrote: >>>> In contrast to all of the DSI panel drivers in drivers/gpu/drm/panel >>>> which attach to the DSI host via mipi_dsi_attach() at probe time, the >>>> ADV7533 bridge device does not. Instead it defers this to the point that >>>> the upstream device connects to its bridge via drm_bridge_attach(). >>>> The generic Synopsys MIPI DSI host driver does not register it's own >>>> drm_bridge until the MIPI DSI has attached. But it does not call >>>> drm_bridge_attach() on the downstream device until the upstream device >>>> has attached. This leads to a chicken and the egg failure and the DRM >>>> pipeline does not complete. >>>> Since all other mipi_dsi_device drivers call mipi_dsi_attach() in >>>> probe(), make the adv7533 mipi_dsi_device do the same. This ensures that >>>> the Synopsys MIPI DSI host registers it's bridge such that it is >>>> available for the upstream device to connect to. >>>> >>>> Signed-off-by: Matt Redfearn <matt.redfearn@xxxxxxxxxx> >>>> >>>> --- >>> As a heads up, I just did some testing on drm-misc-next and this patch >>> seems to be breaking the HiKey board. On bootup, I'm seeing: >>> [ 4.209615] adv7511 2-0039: 2-0039 supply avdd not found, using >>> dummy regulator >>> [ 4.217075] adv7511 2-0039: 2-0039 supply dvdd not found, using >>> dummy regulator >>> [ 4.224453] adv7511 2-0039: 2-0039 supply pvdd not found, using >>> dummy regulator >>> [ 4.231804] adv7511 2-0039: 2-0039 supply a2vdd not found, using >>> dummy regulator >>> [ 4.239242] adv7511 2-0039: 2-0039 supply v3p3 not found, using >>> dummy regulator >>> [ 4.246615] adv7511 2-0039: 2-0039 supply v1p2 not found, using >>> dummy regulator >>> [ 4.272970] adv7511 2-0039: failed to find dsi host >>> >>> over and over. The dummy regulator messages are normal, but usually >>> [ 4.444315] kirin-drm f4100000.ade: bound f4107800.dsi (ops dsi_ops) >>> >>> Starts up right afterward. >> Hey Matt, Andrzej, >> I just wanted to follow up on this as this patch is breaking a >> couple of boards. Any sense of what might be missing, or is this >> something we should revert? >> >> I'm happy to test any patch ideas you have. > > > I guess this is circular dependency issue: > > - adv waits for dsi-host, then it creates drm_bridge, > > - dsi-driver waits for drm_bridge, then it creates dsi host. > > > The patch introduces proper order: > > - 1st we should register devices buses, > > - then we should wait for drm components. > > > So the best solution would be to fix f4107800.dsi driver - it shouldn't > look for drm_bridge in probe, instead it should register dsi_host, and > in dsi host attach callback look for drm_bridge, then call component_add > (if all required resources are gathered), see > dw_mipi_dsi_rockchip_host_attach for example. Hi all, Sorry that my patch seems to have broken things. It was using the generic synopsys dsi driver (drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c) that I found the circular dependency fixed by my patch. It appears that the patch has broken things for the platform specific synopsys dsi driver for Kirin. So another approach (though a lot more work) would be to switch Kirin over to using the generic synopsys dsi driver so that we have less redundancy in the tree. Thanks, Matt > > > Regards > > Andrzej > > > >> >> thanks >> -john >> >> > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
