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. 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? -Doug
