diff options
author | Sylwester Nawrocki <s.nawrocki@samsung.com> | 2013-09-04 11:40:06 +0200 |
---|---|---|
committer | Chanho Park <chanho61.park@samsung.com> | 2014-11-18 11:44:39 +0900 |
commit | c5529b7705211ca74fecd2650ee25cd46e0260de (patch) | |
tree | d347cbeead96a98df5d319300034f0c44b6f984d /Documentation/phy.txt | |
parent | 4e6a68a9658929d05ecfd8edd23dfe660d620d92 (diff) | |
download | linux-3.10-c5529b7705211ca74fecd2650ee25cd46e0260de.tar.gz linux-3.10-c5529b7705211ca74fecd2650ee25cd46e0260de.tar.bz2 linux-3.10-c5529b7705211ca74fecd2650ee25cd46e0260de.zip |
Revert "drivers: phy: add generic PHY framework"
This reverts commit 528bac1d1f2a8bb10ebc3e56dd8f22e2d76f197f.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Diffstat (limited to 'Documentation/phy.txt')
-rw-r--r-- | Documentation/phy.txt | 129 |
1 files changed, 0 insertions, 129 deletions
diff --git a/Documentation/phy.txt b/Documentation/phy.txt deleted file mode 100644 index 05f8fdaa721..00000000000 --- a/Documentation/phy.txt +++ /dev/null @@ -1,129 +0,0 @@ - PHY SUBSYSTEM - Kishon Vijay Abraham I <kishon@ti.com> - -This document explains the Generic PHY Framework along with the APIs provided, -and how-to-use. - -1. Introduction - -*PHY* is the abbreviation for physical layer. It is used to connect a device -to the physical medium e.g., the USB controller has a PHY to provide functions -such as serialization, de-serialization, encoding, decoding and is responsible -for obtaining the required data transmission rate. Note that some USB -controllers have PHY functionality embedded into it and others use an external -PHY. Other peripherals that use PHY include Wireless LAN, Ethernet, -SATA etc. - -The intention of creating this framework is to bring the PHY drivers spread -all over the Linux kernel to drivers/phy to increase code re-use and for -better code maintainability. - -This framework will be of use only to devices that use external PHY (PHY -functionality is not embedded within the controller). - -2. Registering/Unregistering the PHY provider - -PHY provider refers to an entity that implements one or more PHY instances. -For the simple case where the PHY provider implements only a single instance of -the PHY, the framework provides its own implementation of of_xlate in -of_phy_simple_xlate. If the PHY provider implements multiple instances, it -should provide its own implementation of of_xlate. of_xlate is used only for -dt boot case. - -struct phy_provider *__of_phy_provider_register(struct device *dev, - struct module *owner, struct phy * (*of_xlate)(struct device *dev, - struct of_phandle_args *args)); -struct phy_provider *__devm_of_phy_provider_register(struct device *dev, - struct module *owner, struct phy * (*of_xlate)(struct device *dev, - struct of_phandle_args *args)) - -__of_phy_provider_register and __devm_of_phy_provider_register can be used to -register the phy_provider and it takes device, owner and of_xlate as -arguments. For the dt boot case, all PHY providers should use one of the above -2 APIs to register the PHY provider. - -void devm_of_phy_provider_unregister(struct device *dev, - struct phy_provider *phy_provider); -void of_phy_provider_unregister(struct phy_provider *phy_provider); - -devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to -unregister the PHY. - -3. Creating the PHY - -The PHY driver should create the PHY in order for other peripheral controllers -to make use of it. The PHY framework provides 2 APIs to create the PHY. - -struct phy *phy_create(struct device *dev, u8 id, const struct phy_ops *ops, - const char *label); -extern struct phy *devm_phy_create(struct device *dev, u8 id, - const struct phy_ops *ops, const char *label); - -The PHY drivers can use one of the above 2 APIs to create the PHY by passing -the device pointer, id, phy ops, label and a driver data. -phy_ops is a set of function pointers for performing PHY operations such as -init, exit, power_on and power_off. *label* is mandatory for non-dt boot case -and it should be unique as well. - -Inorder to dereference the private data (in phy_ops), the phy provider driver -can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in -phy_ops to get back the private data. - -4. Getting a reference to the PHY - -Before the controller can make use of the PHY, it has to get a reference to -it. This framework provides the following APIs to get a reference to the PHY. - -struct phy *phy_get(struct device *dev, const char *string); -struct phy *devm_phy_get(struct device *dev, const char *string); - -phy_get and devm_phy_get can be used to get the PHY. In the case of dt boot, -the string arguments should contain the phy name as given in the dt data and -in the case of non-dt boot, it should contain the label of the PHY. -The only difference between the two APIs is that devm_phy_get associates the -device with the PHY using devres on successful PHY get. On driver detach, -release function is invoked on the the devres data and devres data is freed. - -5. Releasing a reference to the PHY - -When the controller no longer needs the PHY, it has to release the reference -to the PHY it has obtained using the APIs mentioned in the above section. The -PHY framework provides 2 APIs to release a reference to the PHY. - -void phy_put(struct phy *phy); -void devm_phy_put(struct device *dev, struct phy *phy); - -Both these APIs are used to release a reference to the PHY and devm_phy_put -destroys the devres associated with this PHY. - -6. Destroying the PHY - -When the driver that created the PHY is unloaded, it should destroy the PHY it -created using one of the following 2 APIs. - -void phy_destroy(struct phy *phy); -void devm_phy_destroy(struct device *dev, struct phy *phy); - -Both these APIs destroy the PHY and devm_phy_destroy destroys the devres -associated with this PHY. - -7. PM Runtime - -This subsystem is pm runtime enabled. So while creating the PHY, -pm_runtime_enable of the phy device created by this subsystem is called and -while destroying the PHY, pm_runtime_disable is called. Note that the phy -device created by this subsystem will be a child of the device that calls -phy_create (PHY provider device). - -So pm_runtime_get_sync of the phy_device created by this subsystem will invoke -pm_runtime_get_sync of PHY provider device because of parent-child relationship. -It should also be noted that phy_power_on and phy_power_off performs -phy_pm_runtime_get_sync and phy_pm_runtime_put respectively. -There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync, -phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and -phy_pm_runtime_forbid for performing PM operations. - -8. DeviceTree Binding - -The documentation for PHY dt binding can be found @ -Documentation/devicetree/bindings/phy/phy-bindings.txt |