On Tue, Jun 18, 2019 at 12:53 PM Chen-Yu Tsai <wens@xxxxxxxx> wrote: > > On Tue, Jun 18, 2019 at 3:12 PM Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Mon, Jun 17, 2019 at 6:31 PM Chen-Yu Tsai <wens@xxxxxxxx> wrote: > > > > > > On Mon, Jun 17, 2019 at 7:45 PM Maxime Ripard <maxime.ripard@xxxxxxxxxxx> wrote: > > > > > > > > On Fri, Jun 14, 2019 at 10:13:20PM +0530, Jagan Teki wrote: > > > > > TCON TOP have clock gates for TV0, TV1, dsi and right > > > > > now these are register during bind call. > > > > > > > > > > Of which, dsi clock gate would required during DPHY probe > > > > > but same can miss to get since tcon top is not bound at > > > > > that time. > > > > > > > > > > To solve, this circular dependency move the clock gate > > > > > registration from bind to probe so-that DPHY can get the > > > > > dsi gate clock on time. > > > > > > > > It's not really clear to me what the circular dependency is? > > > > > > > > if you have a chain that is: > > > > > > > > tcon-top +-> DSI > > > > +-> D-PHY > > > > > > > > There's no loop, right? > > > > > > Looking at how the DTSI patch structures things (without going into > > > whether it is correct or accurate): > > > > > > The D-PHY is not part of the component graph. However it requests > > > the DSI gate clock from the TCON-TOP. > > > > > > The TCON-TOP driver, in its current form, only registers the clocks > > > it provides at component bind time. Thus the D-PHY can't successfully > > > probe until the TCON-TOP has been bound. > > > > > > The DSI interface requires the D-PHY to bind. It will return -EPROBE_DEFER > > > if it cannot request it. This in turn goes into the error path of > > > component_bind_all, which unbinds all previous components. > > > > > > So it's actually > > > > > > D-PHY -> TCON-TOP -> DSI > > > ^ | > > > |-------------------- > > > > > > I've not checked, but I suspect there's no possibility of having other > > > drivers probe (to deal with deferred probing) within component_bind_all. > > > Otherwise we shouldn't run into this weird circular dependency issue. > > > > > > So the question for Jagan is that is this indeed the case? Does this > > > patch solve it, or at least work around it. > > > > Yes, this is what I was mentioned in initial version, since the "dsi" > > gate in tcon top is registering during bind, the dphy of dsi > > controller won't get the associated clock for "mod" so it is keep on > > returning -EPROBE_DEFER. By moving the clock gate registration to > > probe, everything bound as expected. > > I believe you failed to mention the DSI block, which is the part that > completes the circular dependency. Don't expect others to have full > awareness of the context. You have to provide it in your commit log. I have mentioned DPHY and yes it is possible to give more information will update in next version, no problem. thanks for mentioning that.
