Hi, On Thu, Sep 28, 2023 at 1:12 PM Rob Herring <robh+dt@xxxxxxxxxx> wrote: > > > > Perhaps then this should be solved in userspace where it can learn > > > which device is actually present and save that information for > > > subsequent boots. > > > > Yeah, the thought occurred to me as well. I think there are a few > > problems, though: > > > > a) Userspace can't itself probe these devices effectively. While > > userspace could turn on GPIOs manually and query the i2c bus manually, > > it can't (I believe) turn on regulators nor can it turn on clocks, if > > they are needed. About the best userspace could do would be to blindly > > try binding an existing kernel driver, and in that case why did we > > need userspace involved anyway? > > > > b) While deferring to userspace can work for solutions like ChromeOS > > or Android where it's easy to ensure the userspace bits are there, > > it's less appealing as a general solution. I think in Johan's case > > he's taking a laptop that initially ran Windows and then is trying to > > run a generic Linux distro on it. For anyone in a similar situation, > > they'd either need to pick a Linux distro that has the magic userspace > > bits that are needed or they need to know that, on their laptop, they > > need to manually install some software. While requiring special > > userspace might make sense if you've got a special peripheral, like an > > LTE modem, it makes less sense to need special userspace just to get > > the right devices bound... > > I did not mean do it all in userspace, but for userspace to save off > what devices are actually present. For example, if userspace has > access to the dtb, it could just update the dtb to enable the right > nodes. Then after the first boot, boot time is faster. Or a driver > could try to load an overlay with the config enabling the right > devices. Though maybe waiting til userspace is available wouldn't > speed things up. At least for the ChromeOS boot flow userspace isn't able to make any changes to the dtb so I don't think this would help us unless I'm misunderstanding. > > Imagine that instead of the hated "hid-over-i2c" compatible we were > > using two other devices. Imagine that a given board could have a > > "elan,ekth6915" and a "goodix,gt7375p". Both of these devices have > > specific timing requirements on how to sequence their supplies and > > reset GPIOs. For Elan we power on the supplies, wait at least 1 ms, > > deassert reset, wait at least 300 ms, and then can talk i2c. For > > Goodix we power on the supply, wait at least 10 ms, deassert reset, > > wait at least 180 ms, and then can talk i2c. If we had a > > board-specific probing driver then it would power on the supplies, > > wait at least 10 ms (the max of the two), deassert reset, wait at > > least 300 ms (the max of the two), and then see which device talked. > > Then it would instantiate whichever of the two drivers. This could be > > done for any two devices that EEs have determined have "compatible" > > probing sequences. > > My point was that in the above example, all these delay times would > have to be defined in the kernel, not DT. In the case of using the actual "hid-over-i2c" driver and not one of the specialized ones, I think we'd still need to put the delay times in the DT for the individual "hid-over-i2c" nodes, right? The board-specific driver could still have an implicit delay depending on the board compatible, but if you set the "hid-over-i2c" node to "okay" then that driver is going to be expecting to read the delay from DT. It will use the delay it reads from the DT for powering on after suspend/resume... > > Ideally in the above situation we'd be able to avoid turning the > > device off and on again between the board-specific probe code and the > > normal driver. That optimization might need special code per-driver > > but it feels doable by passing some sort of hint to the child driver > > when it's instantiated. > > I think fixing regulators getting turned off on failed probes and > having a "regulator on time" would go a long way towards providing > that hint even if the on time was just since clocksource started. You're suggesting that when a touchscreen fails to probe because it didn't find the touchscreen on the i2c bus that it should leave its regulator on? That doesn't seem right to me. While we might find a way for it to help in the 2nd sourcing case, it doesn't seem right in the case of a device truly being missing... I'm also not sure that it truly solves the problem since the power sequencing of these devices is more than just a regulator but often involves several regulators being turned on (perhaps with delays in between) and some enable and/or reset GPIOs. In the case of many touchscreens the delay needed is actually the delay from after the reset GPIO is deasserted. In any case, we can talk more about this in my other response. -Doug
