On 01/19, Vivek Gautam wrote:
On 01/19/2017 06:10 AM, Stephen Boyd wrote:Hmm... maybe I was recalling the DSI phy binding. I think there
Didn't we already move away from subnodes for lanes in an earlierYea, we started out without having any sub-nodes and we
revision of these patches? I seem to recall we did that because
lanes are not devices and the whole "phy as a bus" concept not
making sense.
argued that we don't require them since the qmp device is
represented by the qmp node itself.
The lanes otoh are representative of gen_phys and related properties.
In the driver -
"struct qmp_phy " represents the lanes and holds "struct phy",
"struct qcom_qmp" represents the qmp block as a whole and holds
"struct device"
Does this make lanes qualify to be childs of qmp ?
are lanes there too but we decided to just have one node.
"phy as a bus" (just trying to understand here) -Typically in DT a subnode or collection of subnodes means there's
let's say a usb phy controller has one HSIC phy port and one USB2 phy port.
So, should this phy controller be a bus providing two ports (and so
we will have
couple of child nodes to the phy controller) ?
some sort of bus involved. Usually each node corresponds to a
struct device, and the parent node corresponds to the bus or
controller for the logical bus.
In this case (only PCIe though? not UFS or USB?) it seems like we
have multiple phys that share a common register space, but
otherwise they have their own register space and power
management. Would you have each PCIe controller point to a
different subnode for their associated phy? I'm trying to
understand the benefit of the subnodes if they aren't treated as
struct devices.
At the least, please get DT reviewers to ack the new binding
before rewriting the code.