RE: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
From: Sergei Shtylyov It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. Doesn't something like that already happen for the companion USB1 controllers for USB2 ports? That also doesn't sound like you are changing the PHY. I'd have thought that would happen if you had a single controller that select between multiply PHY. David -- 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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 10/04/14 11:49, Sergei Shtylyov wrote: On 10-04-2014 13:20, David Laight wrote: It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. Doesn't something like that already happen for the companion USB1 controllers for USB2 ports? Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2? That also doesn't sound like you are changing the PHY. I am changing one of the PHY registers that controls USB port (Renesas calls it channel) multiplexing. I'd have thought that would happen if you had a single controller that select between multiply PHY. No, it's not the case. There is an interesting case, the USB3 shares a PHY with a SATA and the PCIE and SATA also share a PHY on the R8A7790. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- 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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
From: Ben Dooks On 10/04/14 11:49, Sergei Shtylyov wrote: On 10-04-2014 13:20, David Laight wrote: It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. Doesn't something like that already happen for the companion USB1 controllers for USB2 ports? Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2? Yes. Why do you care which USB controller is driving the pins? That also doesn't sound like you are changing the PHY. I am changing one of the PHY registers that controls USB port (Renesas calls it channel) multiplexing. I'd have thought that would happen if you had a single controller that select between multiply PHY. No, it's not the case. I realised that wasn't what you were doing, but at first it did seem to be what you were doing. There is an interesting case, the USB3 shares a PHY with a SATA and the PCIE and SATA also share a PHY on the R8A7790. Some of those look like pcb design decisions - so there is no dynamic changing, just config time plumbing. OTOH we are carrying PCIe using two SATA cables (the second carries the clock) so I suspect some SoC system pcbs may be able to support SATA or PCIe on the same connector). David -- 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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 10/04/14 12:14, David Laight wrote: From: Ben Dooks On 10/04/14 11:49, Sergei Shtylyov wrote: On 10-04-2014 13:20, David Laight wrote: It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. Doesn't something like that already happen for the companion USB1 controllers for USB2 ports? Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2? Yes. Why do you care which USB controller is driving the pins? That also doesn't sound like you are changing the PHY. I am changing one of the PHY registers that controls USB port (Renesas calls it channel) multiplexing. I'd have thought that would happen if you had a single controller that select between multiply PHY. No, it's not the case. I realised that wasn't what you were doing, but at first it did seem to be what you were doing. There is an interesting case, the USB3 shares a PHY with a SATA and the PCIE and SATA also share a PHY on the R8A7790. Some of those look like pcb design decisions - so there is no dynamic changing, just config time plumbing. OTOH we are carrying PCIe using two SATA cables (the second carries the clock) so I suspect some SoC system pcbs may be able to support SATA or PCIe on the same connector). Yes, which means we will probably want to support the case where the USB3 is routed out of the PCIe lanes. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- 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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 10-04-2014 15:14, David Laight wrote: It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. Doesn't something like that already happen for the companion USB1 controllers for USB2 ports? Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2? Yes. Why do you care which USB controller is driving the pins? Because the controllers the driver switches between are not companions. The multiplexing is between PCI EHCI/OHCI and Renesas USBHS (high speed device controller in this case) controllers on port 0 and between PCI EHCI/OHCI and non-PCI xHCI controller on port 2. That also doesn't sound like you are changing the PHY. I am changing one of the PHY registers that controls USB port (Renesas calls it channel) multiplexing. I'd have thought that would happen if you had a single controller that select between multiply PHY. No, it's not the case. I realised that wasn't what you were doing, but at first it did seem to be what you were doing. The PHY really does belong to the USBHS controller but that multiplexing register inside it controls routing of the ports 0 and 2; USBHS itself is on port 0. There is an interesting case, the USB3 shares a PHY with a SATA and the PCIE and SATA also share a PHY on the R8A7790. Some of those look like pcb design decisions - so there is no dynamic changing, just config time plumbing. No, there are also host/device mode DIP switches on the boards which control port 0 signals (and the port 0 connector is micro-AB, so both a host and device can be connected). The second board also has OTG chip on port 0 thru which USB ID pin can be read from the micro-AB connector. David WBR, Sergei -- 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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 04/09/2014 07:57 AM, Sergei Shtylyov wrote: Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'. This is in preparation to adding the generic PHY support. Surely if the correct term is transceiver, we should be adding generic transceiver support not generic PHY support? To be honest, this rename feels like churn, especially since the APIs and DT bindings all still include the work phy so now everything will be inconsistent. -- 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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
Hello. On 04/09/2014 07:31 PM, Stephen Warren wrote: Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'. This is in preparation to adding the generic PHY support. Surely if the correct term is transceiver, we should be adding generic transceiver support not generic PHY support? To be honest, this rename feels like churn, especially since the APIs and DT bindings all still include the work phy so now everything will be inconsistent. How about 'usb_phy'? WBR, Sergei -- 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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 04/09/2014 10:27 AM, Sergei Shtylyov wrote: Hello. On 04/09/2014 07:31 PM, Stephen Warren wrote: Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'. This is in preparation to adding the generic PHY support. Surely if the correct term is transceiver, we should be adding generic transceiver support not generic PHY support? To be honest, this rename feels like churn, especially since the APIs and DT bindings all still include the work phy so now everything will be inconsistent. How about 'usb_phy'? That certainly would make things more consistent, but I wonder why usb_phy is better than phy when the code/struct in question is something USB-specific; the usb_ prefix seems implicit to me due to context. -- 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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 04/09/2014 08:48 PM, Stephen Warren wrote: Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'. This is in preparation to adding the generic PHY support. Surely if the correct term is transceiver, we should be adding generic transceiver support not generic PHY support? To be honest, this rename feels like churn, especially since the APIs and DT bindings all still include the work phy so now everything will be inconsistent. How about 'usb_phy'? That certainly would make things more consistent, but I wonder why usb_phy is better than phy when the code/struct in question is something USB-specific; the usb_ prefix seems implicit to me due to context. I tend to agree. However, I need to name the new field of stype 'struct phy *' somehow... perhaps something like 'gen_phy' for it would do? WBR, Sergei -- 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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 04/09/2014 10:53 AM, Sergei Shtylyov wrote: On 04/09/2014 08:48 PM, Stephen Warren wrote: Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'. This is in preparation to adding the generic PHY support. Surely if the correct term is transceiver, we should be adding generic transceiver support not generic PHY support? To be honest, this rename feels like churn, especially since the APIs and DT bindings all still include the work phy so now everything will be inconsistent. How about 'usb_phy'? That certainly would make things more consistent, but I wonder why usb_phy is better than phy when the code/struct in question is something USB-specific; the usb_ prefix seems implicit to me due to context. I tend to agree. However, I need to name the new field of stype 'struct phy *' somehow... perhaps something like 'gen_phy' for it would do? Ok, the existing field is being replaced by something? I didn't get that from the patch description; I thought the new name in this patch was going to be it. In that case, a temporary name of usb_phy for the existing field, or adding the new field as gen_phy sound reasonable. -- 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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 04/09/2014 09:37 PM, Stephen Warren wrote: Return to the 'phy' field of 'struct usb_hcd' its historic name 'transceiver'. This is in preparation to adding the generic PHY support. Surely if the correct term is transceiver, we should be adding generic transceiver support not generic PHY support? To be honest, this rename feels like churn, especially since the APIs and DT bindings all still include the work phy so now everything will be inconsistent. How about 'usb_phy'? That certainly would make things more consistent, but I wonder why usb_phy is better than phy when the code/struct in question is something USB-specific; the usb_ prefix seems implicit to me due to context. I tend to agree. However, I need to name the new field of stype 'struct phy *' somehow... perhaps something like 'gen_phy' for it would do? Ok, the existing field is being replaced by something? I didn't get that No, not replaced. I'm adding the support for generic PHY to the existing USB PHY support. I thought that was clear from the changelog. from the patch description; I thought the new name in this patch was going to be it. In that case, a temporary name of usb_phy for the existing field, or adding the new field as gen_phy sound reasonable. OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1. WBR, Sergei -- 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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On Wed, 9 Apr 2014, Sergei Shtylyov wrote: Ok, the existing field is being replaced by something? I didn't get that No, not replaced. I'm adding the support for generic PHY to the existing USB PHY support. I thought that was clear from the changelog. from the patch description; I thought the new name in this patch was going to be it. In that case, a temporary name of usb_phy for the existing field, or adding the new field as gen_phy sound reasonable. OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1. What is the reason for all of this? That is, can you explain the difference between USB PHY support and general PHY support, and why we need both? Alan Stern -- 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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
Hello. On 04/09/2014 09:56 PM, Alan Stern wrote: Ok, the existing field is being replaced by something? I didn't get that No, not replaced. I'm adding the support for generic PHY to the existing USB PHY support. I thought that was clear from the changelog. from the patch description; I thought the new name in this patch was going to be it. In that case, a temporary name of usb_phy for the existing field, or adding the new field as gen_phy sound reasonable. OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1. What is the reason for all of this? That is, can you explain the difference between USB PHY support and general PHY support, and why we need both? The generic PHY framework (drivers/phy/phy-core.c) supports multifunction complex PHYs (some functions of which may be related to USB). My case is a Renesas R-Car generation 2 PHY that can switch two USB ports between different USB controllers (one PCI and one non-PCI on each port); I just haven't CCed linux-usb on my driver submission. Though there's already drivers/phy/usb/ driver for that hardware, it failed to meet the expectations (dynamic setting of the port multiplexing depending on what USB host/gadget drivers are loaded), so I had to write a new driver. I guess I don't need to describe drivers/phy/usb/ framework in detail, do I? It only provides for single-function simple USB PHYs... Alan Stern WBR, Sergei -- 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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 04/09/2014 12:16 PM, Sergei Shtylyov wrote: Hello. On 04/09/2014 09:56 PM, Alan Stern wrote: Ok, the existing field is being replaced by something? I didn't get that No, not replaced. I'm adding the support for generic PHY to the existing USB PHY support. I thought that was clear from the changelog. from the patch description; I thought the new name in this patch was going to be it. In that case, a temporary name of usb_phy for the existing field, or adding the new field as gen_phy sound reasonable. OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1. What is the reason for all of this? That is, can you explain the difference between USB PHY support and general PHY support, and why we need both? The generic PHY framework (drivers/phy/phy-core.c) supports multifunction complex PHYs (some functions of which may be related to USB). My case is a Renesas R-Car generation 2 PHY that can switch two USB ports between different USB controllers (one PCI and one non-PCI on each port); I just haven't CCed linux-usb on my driver submission. Though there's already drivers/phy/usb/ driver for that hardware, it failed to meet the expectations (dynamic setting of the port multiplexing depending on what USB host/gadget drivers are loaded), so I had to write a new driver. I guess I don't need to describe drivers/phy/usb/ framework in detail, do I? It only provides for single-function simple USB PHYs... Naively, it sounds like the complex PHY driver should also be a pinctrl driver, since it sounds like the main feature it has beyond a simple PHY is the ability to do pin muxing. -- 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 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 04/09/2014 11:01 PM, Stephen Warren wrote: Ok, the existing field is being replaced by something? I didn't get that No, not replaced. I'm adding the support for generic PHY to the existing USB PHY support. I thought that was clear from the changelog. from the patch description; I thought the new name in this patch was going to be it. In that case, a temporary name of usb_phy for the existing field, or adding the new field as gen_phy sound reasonable. OK, I'll respin the patch #2 with 'gen_phy' and remove the patch #1. What is the reason for all of this? That is, can you explain the difference between USB PHY support and general PHY support, and why we need both? The generic PHY framework (drivers/phy/phy-core.c) supports multifunction complex PHYs (some functions of which may be related to USB). My case is a Renesas R-Car generation 2 PHY that can switch two USB ports between different USB controllers (one PCI and one non-PCI on each port); I just haven't CCed linux-usb on my driver submission. Though there's already drivers/phy/usb/ driver for that hardware, it failed to meet the expectations (dynamic setting of the port multiplexing depending on what USB host/gadget drivers are loaded), so I had to write a new driver. I guess I don't need to describe drivers/phy/usb/ framework in detail, do I? It only provides for single-function simple USB PHYs... Naively, it sounds like the complex PHY driver should also be a pinctrl driver, since it sounds like the main feature it has beyond a simple PHY is the ability to do pin muxing. It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. WBR, Sergei -- 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
