On Fri, 8 Dec 2023 at 14:47, Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > 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. phy-type being used for the 7nm DSI PHY, where it specify exactly the same thing: whether the connected device uses D-PHY or C-PHY modes of the PHY. cdns,phy-type - selecs between PCIe, DP, USB3 or other modes of the PHY ti/emif.txt: phy-type specifies which PHY is attached / used in the controller xlnx,phy-type: deprecated in favour of phy-mode, selects MII mode for the PHY marvell,xenon-phy-type: I _think_ this specifies the actual PHY attached to the controller in hardware. > > 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? Hmm, I was not clear enough. USB+DP = two different PHYs in the same hardware block. DP-eDP = single PHY, working in one of the modes. > > > > > 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? No. It doesn't redefine what we already have for other QMP PHYs, it defines new property. > > > > > 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. That's a good question. We have separate -dp and -edp compatibles for the DP controller, but I think those also should go, at least for newer platforms. And the reason is the same, there is a single hardware block, just two modes of operation. See mdss_dp3 in the X13s's DT file. I had a thought of using aux-bus presence to determine whether the controller is working in the DP or eDP modes. But this might need additional care for older DT files. -- With best wishes Dmitry
