jenna
/
kernel_samsung_sm7125
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
690452 Commits
5 Branches
0 Tags
1.2 GiB
Tag: Branch: Tree: 832622e6bd
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '832622e6bd'
${ noResults }
kernel_samsung_sm7125/Documentation/devicetree/bindings/usb/ulpi.txt

21 lines
401 B
Raw Normal View History Unescape

usb: ulpi: Support device discovery via DT The qcom HSIC ULPI phy doesn't have any bits set in the vendor or product ID registers. This makes it impossible to make a ULPI driver match against the ID registers. Add support to discover the ULPI phys via DT help alleviate this problem. In the DT case, we'll look for a ULPI bus node underneath the device registering the ULPI viewport (or the parent of that device to support chipidea's device layout) and then match up the phy node underneath that with the ULPI device that's created. The side benefit of this is that we can use standard properties in the phy node like clks, regulators, gpios, etc. because we don't have firmware like ACPI to turn these things on for us. And we can use the DT phy binding to point our phy consumer to the phy provider. The ULPI bus code supports native enumeration by reading the vendor ID and product ID registers at device creation time, but we can't be certain that those register reads will succeed if the phy is not powered up. To avoid any problems with reading the ID registers before the phy is powered we fallback to DT matching when the ID reads fail. If the ULPI spec had some generic power sequencing for these registers we could put that into the ULPI bus layer and power up the device before reading the ID registers. Unfortunately this doesn't exist and the power sequence is usually device specific. By having the device matched up with DT we can avoid this problem. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: <devicetree@vger.kernel.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by: Peter Chen <peter.chen@nxp.com>
8 years ago
ULPI bus binding
----------------
Phys that are behind a ULPI connection can be described with the following
binding. The host controller shall have a "ulpi" named node as a child, and
that node shall have one enabled node underneath it representing the ulpi
device on the bus.
EXAMPLE
-------
usb {
compatible = "vendor,usb-controller";
ulpi {
phy {
compatible = "vendor,phy";
};
};
};