Re: [PATCH v3 0/6] Generic PHY Framework
Hi Kishon, On 3/20/2013 2:41 PM, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). From a top level what you are doing looks closely related to External connector (extcon). I understand a connector is not the same as a phy, but it will still be useful to know why extcon framework (or some extension of it) will not suffice your needs. You can probably note it in the cover-letter so folks like me get their answer. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] Generic PHY Framework
On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I kis...@ti.com wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). 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 to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on 3.9-rc3. Once the patch series gets finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree. [...] drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 574 This looks to be very specific for USB PHYs. Are you intending it to be used for other types of PHYs, like Ethernet PHYs? If not, then this infrastruction should be named something like usb-phy so that it isn't confused with other layers, and it really should live under drivers/usb. g. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] Generic PHY Framework
Hi, On Monday 15 April 2013 03:50 PM, Grant Likely wrote: On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I kis...@ti.com wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). 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 to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on 3.9-rc3. Once the patch series gets finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree. [...] drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 574 This looks to be very specific for USB PHYs. Are you intending it to be used for other types of PHYs, like Ethernet PHYs? If not, then this Not really. This can be used by USB, SATA and Sylwester was planning to use it for video PHY's. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] Generic PHY Framework
On 04/15/2013 12:36 PM, Kishon Vijay Abraham I wrote: On Monday 15 April 2013 03:50 PM, Grant Likely wrote: On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I kis...@ti.com wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). 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 to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on 3.9-rc3. Once the patch series gets finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree. [...] drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 574 This looks to be very specific for USB PHYs. Are you intending it to be used for other types of PHYs, like Ethernet PHYs? If not, then this Not really. This can be used by USB, SATA and Sylwester was planning to use it for video PHY's. Yes, I have already some RFC patches to handle the display and the camera interface DPHYs (MIPI DSI, MIPI CSI-2) with this API. I didn't post it, since this framework is not settled yet. Those DPHYs need very few operations, like disable/enable only and there was really not suitable API in the kernel until now to handle them. We had plans in the past to write something like this generic PHY framework for the Samsung SoCs. Some SoCs have plenty different PHYs: USB, SATA, MIPI CSI-2, MIPI DSI, HDMI... And some of them are simple enough to be covered by this generic PHY API. Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] Generic PHY Framework
On Mon, 15 Apr 2013 16:06:37 +0530, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Monday 15 April 2013 03:50 PM, Grant Likely wrote: On Wed, 20 Mar 2013 14:41:59 +0530, Kishon Vijay Abraham I kis...@ti.com wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). 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 to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. Making omap-usb2 and twl4030 to use this framework is provided as a sample. This patch series is developed on 3.9-rc3. Once the patch series gets finalised I'll resend omap-usb2 and twl4030 part based on Felipe's tree. [...] drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 13 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 574 This looks to be very specific for USB PHYs. Are you intending it to be used for other types of PHYs, like Ethernet PHYs? If not, then this Not really. This can be used by USB, SATA and Sylwester was planning to use it for video PHY's. So what are the common bits that are shared between those phys? Merely matching phys to controllers? Besides that, each of those devices have very different behaviour. You wouldn't be able to attach any interface logic to the generic struct phy. I don't think it makes a whole lot of sense to lump them all into the same type of registration. g. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
