On Fri, Jun 09, 2017 at 10:43:07AM +0100, Jose Abreu wrote: > Hello, > > > On 09-06-2017 05:11, Archit Taneja wrote: > > Hi Philippe, Rob, > > > > On 06/08/2017 09:10 PM, Rob Herring wrote: > >> Seems strange there's not also a pixel or bit clock? Or this > >> gets driven > >> from the phy? > > > > Since you mention phy here, I wanted to share a concern with > > the bindings. > > These bindings don't have a separate PHY DT node. The PHY is > > assumed as a > > part of the IP when integrated by a SoC. There are already > > rockchip and > > hisil DSI bindings that use this IP but don't define a PHY node. > > > > It's a similar situation with the DW-HDMI bindings. > > > > For example, when the DW HDMI is integrated in rockchip or > > renesas SoC, the > > bindings "rockchip,rk3288-dw-hdmi" or "renesas,r8a7795-dw-hdmi" > > are used, > > and they don't have a separate PHY DT node. > > > > I wasn't sure whether this is the right way to proceed or not > > for such IPs. > > Some advice would help us here. > > > > Thanks, > > Archit > > > > I just want to add that read/writes from/to phy are done using > the controller (in HDMI and in MIPI DSI Host), so the only way to > have a phy driver is that if some custom callbacks are provided > or if the memory region is shared. > > Anyway, I agree with Archit in the sense that phy + controller > are highly tied. Also, these two "pieces" are SoC specific and > sometimes very different between SoC's because they can be > customized so I think a different compatible string suits well here. When the phy is integrated like this, I agree that it doesn't make sense to have a separate phy node. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
