On 08/12/2023 13:35, Dmitry Baryshkov wrote: >>>>> Same applies to the displayport-controller. It can either drive the DP >>>>> or eDP output, hardware-wise it is the same. >>>> >>>> Therefore what I proposed was correct - the block which uses the phy >>>> configures its mode. Because this part: >>>> "this phy is of this type on this board". >>>> is not true. The phy is both types. >>> >>> But hopefully you don't mean using #phy-cells here. There are no >>> sub-PHYs or anything like that. >> >> I am exactly talking about phy-cells. Look at first example from Abel's >> code. > > I always had an impression that #foo-cells means that there are > different units within the major handler. I.e. #clock-cells mean that > there are several different clocks, #reset-cells mean that there are > several resets, etc. > Ok, maybe this is not a perfect description. We need cells to identify > a particular instance within the major block. Maybe that sounds more > correct. No, the cells have also meaning of additional arguments. See usage of phy-type (not the one here, but the correct one) and PWMs. > > For the USB+DP PHY we use #phy-cells to select between USB3 and DP > PHYs. But for these PHYs we do not have sub-devices, sub-blocks, etc. > There is a single PHY which works in either of the modes. Is it different than case here? > > Last, but not least, using #phy-cells in this way would create > asymmetry with all the other PHYs (and especially other QMP PHYs) > present on these platforms. OK. Is phy-type not something different? > > If you feel that phy-type is not an appropriate solution, I'd vote for > not having the type in DT at all, letting the DP controller determine > the proper mode on its own. Can we do it? That's BTW the best option. Best regards, Krzysztof
