> > > > > > Also, I was chatting in private with David and, apparently, there's > > > > > > a > > > > > > way to request for eye diagram data from BIOS straight. That's more > > > > > > in-line with what we would do for DT-based boots, passing that > > > > > > eye-diagram data as a DT attribute. > > > > > > > > > > > > Care to comment ? If that's the case, I'd rather use that BIOS hook > > > > > > and > > > > > > remove ulpi_read() from probe(). > > > > > > > > > > I'm not familiar with such method. But if there is one, I'm not > > > > > against it. I need to check it. > > > > > > > > David ? Care to comment ? > > > > > > I agree with Heikki's proposal to use BIOS hook and remove ulpi_read() > > > from probe(). That address one of my chicken/egg concerns. > > > > Oops. I misinterpreted the thread. Heikki didn't propose that :) > > Let me get things mature and reply to here. > > I talked to David Box (CC'ed him to this reply). > We can add an integer value to ACPI and request it during phy's probe > using ACPI's Device Specific Data (_DSD). That would end the need to > have phy functional during probe (being compatible to BYT-CR and to > module support) and would be more compatible to DT as well.
You can still make modifications to the DSDT?! I am familiar with _DSD, and it does not just allow us to add integer values, but complete named key to value properties compatible with dt, including strings. And in case you guys were not familiar with the unified device property interface, it's a wrapper for apci and dt, and should btw. be used instead of acpi_* or of_* to get properties in drivers from now on. So if we add these properties for the dwc3 device object: "ulpi,vendor", "ulpi,product", we can check them in ULPI bus driver as an alternative for reading the vendor and product registers, and indeed be able to bind the PHY to a driver before it's powered on! P.S. We should not mix BIOS to ACPI. Thanks! -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
