On Fri, 8 Apr 2022 at 03:26, Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > Hi, > > On Thu, Apr 7, 2022 at 4:46 PM Dmitry Baryshkov > <dmitry.baryshkov@xxxxxxxxxx> wrote: > > > > > The way I'm arguing it should work is that: > > > > > > 1. A whole bunch of the DP init code should move to the DP driver's > > > probe function. This includes parsing the DT, acquiring clocks, > > > getting a handle to our PHY, and IO mapping registers. As far as I > > > know, there's no reason to wait on all the components being probed in > > > order to do this stuff. > > > > Yes. And that's one of the reasons I tried to stay away from the DP > > driver. Each time I open the source code, my hands itch to start > > refactoring the code. > > > > > > > > 2. Once we have done the above things, it should be possible to do AUX > > > transfers, correct? ...and then we can populate the AUX bus from the > > > probe function too. > > > > No. In the DP case the AUX bus is inaccessible until the dongle is > > plugged (see all the HPD handling, phy_init()/phy_power_on() is hidden > > somewhere in that path) > > I guess my thought was that in DP you could still create the AUX bus > at probe time. Then for DP you just return an instant "transfer > failed" from the AUX bus if HPD isn't asserted. For eDP (as discussed > elsewhere) when we try to do an AUX transfer then we delay until HPD > is there. I think panel-edp would already handle the delay, so we do not need to have this logic in the DP driver. > So we can still acquire resources (clocks, PHY, io maps, etc) at probe > time for DP and create the AUX bus, right? It will just return > "-ENODEV" if HPD isn't asserted and you're DP? Yes, please. I still suppose that we'd need a separate case to power_on eDP's PHY during the probe time. Maybe I'm mistaken here. -- With best wishes Dmitry
