[PATCH] usb: dwc3: remove extcon dependency
It is required by the OMAP glue driver, but it already depends on it. The core driver should not depend on it. This will allow the use of the PCI glue driver again. Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com --- drivers/usb/dwc3/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index f969ea2..3e225d5 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -1,7 +1,6 @@ config USB_DWC3 tristate DesignWare USB3 DRD Core Support depends on (USB || USB_GADGET) GENERIC_HARDIRQS HAS_DMA - depends on EXTCON select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD help Say Y or M here if your system has a Dual Role SuperSpeed -- 1.8.4.rc3 -- 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
[PATCH] usb: dwc3: pci: add support for BayTrail
Add PCI id for Intel BayTrail.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/usb/dwc3/dwc3-pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 9b13812..997ebe4 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -28,6 +28,7 @@
/* FIXME define these in linux/pci_ids.h */
#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
+#define PCI_DEVICE_ID_INTEL_BYT0x0f37
struct dwc3_pci {
struct device *dev;
@@ -187,6 +188,7 @@ static DEFINE_PCI_DEVICE_TABLE(dwc3_pci_id_table) = {
PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3),
},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
{ }/* Terminating Entry */
};
MODULE_DEVICE_TABLE(pci, dwc3_pci_id_table);
--
1.8.4.rc3
--
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
[PATCH] usb: remove intel_mid_otg.h
It's not used anymore.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
include/linux/usb/intel_mid_otg.h | 180 --
1 file changed, 180 deletions(-)
delete mode 100644 include/linux/usb/intel_mid_otg.h
diff --git a/include/linux/usb/intel_mid_otg.h
b/include/linux/usb/intel_mid_otg.h
deleted file mode 100644
index 756cf55..000
--- a/include/linux/usb/intel_mid_otg.h
+++ /dev/null
@@ -1,180 +0,0 @@
-/*
- * Intel MID (Langwell/Penwell) USB OTG Transceiver driver
- * Copyright (C) 2008 - 2010, Intel Corporation.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc.,
- * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
- *
- */
-
-#ifndef __INTEL_MID_OTG_H
-#define __INTEL_MID_OTG_H
-
-#include linux/pm.h
-#include linux/usb/otg.h
-#include linux/notifier.h
-
-struct intel_mid_otg_xceiv;
-
-/* This is a common data structure for Intel MID platform to
- * save values of the OTG state machine */
-struct otg_hsm {
- /* Input */
- int a_bus_resume;
- int a_bus_suspend;
- int a_conn;
- int a_sess_vld;
- int a_srp_det;
- int a_vbus_vld;
- int b_bus_resume;
- int b_bus_suspend;
- int b_conn;
- int b_se0_srp;
- int b_ssend_srp;
- int b_sess_end;
- int b_sess_vld;
- int id;
-/* id values */
-#define ID_B 0x05
-#define ID_A 0x04
-#define ID_ACA_C 0x03
-#define ID_ACA_B 0x02
-#define ID_ACA_A 0x01
- int power_up;
- int adp_change;
- int test_device;
-
- /* Internal variables */
- int a_set_b_hnp_en;
- int b_srp_done;
- int b_hnp_enable;
- int hnp_poll_enable;
-
- /* Timeout indicator for timers */
- int a_wait_vrise_tmout;
- int a_wait_bcon_tmout;
- int a_aidl_bdis_tmout;
- int a_bidl_adis_tmout;
- int a_bidl_adis_tmr;
- int a_wait_vfall_tmout;
- int b_ase0_brst_tmout;
- int b_bus_suspend_tmout;
- int b_srp_init_tmout;
- int b_srp_fail_tmout;
- int b_srp_fail_tmr;
- int b_adp_sense_tmout;
-
- /* Informative variables */
- int a_bus_drop;
- int a_bus_req;
- int a_clr_err;
- int b_bus_req;
- int a_suspend_req;
- int b_bus_suspend_vld;
-
- /* Output */
- int drv_vbus;
- int loc_conn;
- int loc_sof;
-
- /* Others */
- int vbus_srp_up;
-};
-
-/* must provide ULPI access function to read/write registers implemented in
- * ULPI address space */
-struct iotg_ulpi_access_ops {
- int (*read)(struct intel_mid_otg_xceiv *iotg, u8 reg, u8 *val);
- int (*write)(struct intel_mid_otg_xceiv *iotg, u8 reg, u8 val);
-};
-
-#define OTG_A_DEVICE 0x0
-#define OTG_B_DEVICE 0x1
-
-/*
- * the Intel MID (Langwell/Penwell) otg transceiver driver needs to interact
- * with device and host drivers to implement the USB OTG related feature. More
- * function members are added based on usb_phy data structure for this
- * purpose.
- */
-struct intel_mid_otg_xceiv {
- struct usb_phy otg;
- struct otg_hsm hsm;
-
- /* base address */
- void __iomem*base;
-
- /* ops to access ulpi */
- struct iotg_ulpi_access_ops ulpi_ops;
-
- /* atomic notifier for interrupt context */
- struct atomic_notifier_head iotg_notifier;
-
- /* start/stop USB Host function */
- int (*start_host)(struct intel_mid_otg_xceiv *iotg);
- int (*stop_host)(struct intel_mid_otg_xceiv *iotg);
-
- /* start/stop USB Peripheral function */
- int (*start_peripheral)(struct intel_mid_otg_xceiv *iotg);
- int (*stop_peripheral)(struct intel_mid_otg_xceiv *iotg);
-
- /* start/stop ADP sense/probe function */
- int (*set_adp_probe)(struct intel_mid_otg_xceiv *iotg,
- bool enabled, int dev);
- int (*set_adp_sense)(struct intel_mid_otg_xceiv *iotg,
- bool enabled);
-
-#ifdef CONFIG_PM
- /* suspend/resume USB host function */
- int (*suspend_host)(struct intel_mid_otg_xceiv *iotg,
- pm_message_t message);
- int (*resume_host)(struct intel_mid_otg_xceiv *iotg);
-
- int (*suspend_peripheral)(struct intel_mid_otg_xceiv *iotg
[PATCH 2/3] usb: phy: generic: clean up the probe function
Remove an extra return from the bottom. Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com --- drivers/usb/phy/phy-generic.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c index 68c5548..2b96311 100644 --- a/drivers/usb/phy/phy-generic.c +++ b/drivers/usb/phy/phy-generic.c @@ -271,8 +271,6 @@ static int usb_phy_gen_xceiv_probe(struct platform_device *pdev) platform_set_drvdata(pdev, nop); return 0; - - return err; } static int usb_phy_gen_xceiv_remove(struct platform_device *pdev) -- 1.8.4.3 -- 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
[PATCH 0/3] usb: phy: generic: fix for dwc3-pci
Hi, phy-generic broke dwc3-pci after the gpio support was added. The last patch is fixing that issue. The other two are just cleanups. Thanks, Heikki Krogerus (3): usb: phy: generic: fix a compiler warning usb: phy: generic: clean up the probe function usb: dwc3: fix the glue drivers using the nop phy drivers/usb/dwc3/dwc3-exynos.c | 1 + drivers/usb/dwc3/dwc3-pci.c| 1 + drivers/usb/phy/phy-generic.c | 4 +--- 3 files changed, 3 insertions(+), 3 deletions(-) -- 1.8.4.3 -- 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
[PATCH 1/3] usb: phy: generic: fix a compiler warning
Just because it annoys me.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/usb/phy/phy-generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-generic.c b/drivers/usb/phy/phy-generic.c
index fce3a9e..68c5548 100644
--- a/drivers/usb/phy/phy-generic.c
+++ b/drivers/usb/phy/phy-generic.c
@@ -234,7 +234,7 @@ static int usb_phy_gen_xceiv_probe(struct platform_device
*pdev)
if (dev-of_node) {
struct device_node *node = dev-of_node;
- enum of_gpio_flags flags;
+ enum of_gpio_flags flags = 0;
if (of_property_read_u32(node, clock-frequency, clk_rate))
clk_rate = 0;
--
1.8.4.3
--
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: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
Hi, On Mon, Jan 27, 2014 at 10:05:20AM -0600, Felipe Balbi wrote: Why would you need to know if the PHY drivers are needed or not explicitly in your controller driver? because, one way or another, they all do need it. Except for quirky ones like AM437x where a USB3 IP was hardwired into USB2-only mode, so it really lacks a USB3 PHY. The Baytrail board I deal with has completely autonomous PHYs. But my question is, why would you need to care about the PHYs in your controller driver? Why can't you leave the responsibility of them to the upper layers and trust what they tell you? If there is no USB3 PHY for dwc3 then, the driver gets something like -ENODEV and just continues. There is no need to know about the details. For the controller drivers the PHYs are just a resource like any other. The controller drivers can't have any responsibility of them. They should not care if PHY drivers are available for them or not, or even if the PHY framework is available or not. But I really want to see the argument against using no-op. As far as I could see, everybody needs a PHY driver one way or another, some platforms just haven't sent any PHY driver upstream and have their own hacked up solution to avoid using the PHY layer. Not true in our case. Platforms using Intel's SoCs and chip sets may or may not have controllable USB PHY. Quite often they don't. The Baytrails have usually ULPI PHY for USB2, but that does not mean they provide any vendor specific functions or any need for a driver in any case. that's different from what I heard. I don't know where you got that impression, but it's not true. The Baytrail SoCs for example don't have internal USB PHYs, which means the manufacturers using it can select what they want. So we have boards where PHY driver(s) is needed and boards where it isn't. The problem is that we just don't always know all the details about the platform. If the PHY is ULPI PHY, we can do runtime detection, but we can't even rely on always having ULPI. Are we talking about the old USB PHY library or the new PHY framework with the no-op PHY driver? Well, in any case, I don't understand what is the purpose of the no-op PHY driver. What are you drying to achieve with that? I'm trying to avoid supporting 500 different combinations for a single driver. We already support old USB PHY layer and generic PHY layer, now they both need to be made optional. This is really good to get. We have some projects where we are dealing with more embedded environments, like IVI, where the kernel should be stripped of everything useless. Since the PHYs are autonomous, we should be able to disable the PHY libraries/frameworks. But I still don't understand what is the benefit in the no-op? You really need to explain this. What you have now in dwc3 is expectations regarding the PHY, which put a lot of pressure on upper layers to satisfy the driver. The no-op is just an extra thing that you have to provide when you fail to determine if the system requires a PHY driver or not, or if you know that it doesn't, plus an additional check for the case where the PHY lib/framework is not enabled. I don't see the value in it. The old USB PHY layer also provides a no-op, now called phy-generic, which is actually pretty useful. On top of all that, I'm sure you'll subscribe to the idea of preventing dwc3 from becoming another MUSB which supports several different configurations and none work correctly. I much prefer to take baby steps which are well thought-out and very well exercised, so I'll be very pedantic about proof of testing. I think our goals are the same. I just want to also minimize the need for any platform specific extra work from the upper layers regarding the PHYs. Thanks, -- heikki -- 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: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
Hi, On Tue, Jan 28, 2014 at 10:30:36AM -0600, Felipe Balbi wrote: On Tue, Jan 28, 2014 at 05:32:30PM +0200, Heikki Krogerus wrote: On Mon, Jan 27, 2014 at 10:05:20AM -0600, Felipe Balbi wrote: For the controller drivers the PHYs are just a resource like any other. The controller drivers can't have any responsibility of them. They should not care if PHY drivers are available for them or not, or even if the PHY framework is available or not. huh? If memory isn't available you don't continue probing, right ? If your IORESOURCE_MEM is missing, you also don't continue probing, if your IRQ line is missing, you bail too. Those are also nothing but resources to the driver, what you're asking here is to treat PHY as a _different_ resource; which might be fine, but we need to make sure we don't continue probing when a PHY is missing in a platform that certainly needs a PHY. Yes, true. In my head I was comparing the PHY only to resources like gpios, clocks, dma channels, etc. that are often optional to the drivers. But I really want to see the argument against using no-op. As far as I could see, everybody needs a PHY driver one way or another, some platforms just haven't sent any PHY driver upstream and have their own hacked up solution to avoid using the PHY layer. Not true in our case. Platforms using Intel's SoCs and chip sets may or may not have controllable USB PHY. Quite often they don't. The Baytrails have usually ULPI PHY for USB2, but that does not mean they provide any vendor specific functions or any need for a driver in any case. that's different from what I heard. I don't know where you got that impression, but it's not true. The Baytrail SoCs for example don't have internal USB PHYs, which means the manufacturers using it can select what they want. So we have boards where PHY driver(s) is needed and boards where it isn't. alright, that explains it ;-) So you have external USB2 and USB3 PHYs ? You have an external PIPE3 interface ? That's quite an achievement, kudos to your HW designers. Getting timing closure on PIPE3 is a difficult task. No, only the USB2 PHY is external. I'm giving you wrong information, I'm sorry about that. Need to concentrate on what I'm writing. snip This is really good to get. We have some projects where we are dealing with more embedded environments, like IVI, where the kernel should be stripped of everything useless. Since the PHYs are autonomous, we should be able to disable the PHY libraries/frameworks. hmmm, in that case it's a lot easier to treat. We can use ERR_PTR(-ENXIO) as an indication that the framework is disabled, or something like that. The difficult is really reliably supporting e.g. OMAP5 (which won't work without a PHY) and your BayTrail with autonomous PHYs. What can we use as an indication ? OMAP has it's own glue driver, so shouldn't it depend on the PHY layer? I mean, I need to know that a particular platform depends on a PHY driver before I decide to return -EPROBE_DEFER or just assume the PHY isn't needed ;-) I don't think dwc3 (core) should care about that. The PHY layer needs to tell us that. If the PHY driver that the platform depends is not available yet, the PHY layer returns -EPROBE_DEFER and dwc3 ends up returning -EPROBE_DEFER. snip I think our goals are the same. I just want to also minimize the need for any platform specific extra work from the upper layers regarding the PHYs. I'll agree to that, but let's not apply patches until we're 100% sure there will be no regressions. Looking at $subject, I don't think it satisfies that condition ;-) Agreed. Let's think this through carefully. Cheers, -- heikki -- 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
[PATCH] xhci: Add BayTrail to list of Intel switchable hosts
From: Chew, Chiau Ee chiau.ee.c...@intel.com
Like the xHCI controller on Intel Panther Point and Lynx Point
chipsets, the xHCI controller on Intel BayTrail has also ports that
can be switched between the EHCI host controller.
This patch should be backported to stable kernels as old as 3.0,
that contain commit 69e848c2090aebba5698a1620604c7dccb448684
Intel xhci: Support EHCI/xHCI port switching.
Signed-off-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: sta...@vger.kernel.org
---
drivers/usb/host/ehci-pci.c |3 ++-
drivers/usb/host/pci-quirks.c | 12 +++-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 595d210..a5708d9 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -322,7 +322,8 @@ static bool usb_is_intel_switchable_ehci(struct pci_dev
*pdev)
(pdev-device == 0x1E26 ||
pdev-device == 0x8C2D ||
pdev-device == 0x8C26 ||
-pdev-device == 0x9C26);
+pdev-device == 0x9C26 ||
+pdev-device == 0x0F34);
}
static void ehci_enable_xhci_companion(void)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 4c338ec..6062822 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -724,6 +724,7 @@ static int handshake(void __iomem *ptr, u32 mask, u32 done,
#define PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI0x8C31
#define PCI_DEVICE_ID_INTEL_LYNX_POINT_LP_XHCI 0x9C31
+#define PCI_DEVICE_ID_INTEL_BYT_XHCI 0x0F35
bool usb_is_intel_ppt_switchable_xhci(struct pci_dev *pdev)
{
@@ -741,10 +742,19 @@ bool usb_is_intel_lpt_switchable_xhci(struct pci_dev
*pdev)
pdev-device == PCI_DEVICE_ID_INTEL_LYNX_POINT_LP_XHCI);
}
+/* And so does the Intel BayTrail. */
+bool usb_is_intel_byt_switchable_xhci(struct pci_dev *pdev)
+{
+ return pdev-class == PCI_CLASS_SERIAL_USB_XHCI
+ pdev-vendor == PCI_VENDOR_ID_INTEL
+ pdev-device == PCI_DEVICE_ID_INTEL_BYT_XHCI;
+}
+
bool usb_is_intel_switchable_xhci(struct pci_dev *pdev)
{
return usb_is_intel_ppt_switchable_xhci(pdev) ||
- usb_is_intel_lpt_switchable_xhci(pdev);
+ usb_is_intel_lpt_switchable_xhci(pdev) ||
+ usb_is_intel_byt_switchable_xhci(pdev);
}
EXPORT_SYMBOL_GPL(usb_is_intel_switchable_xhci);
--
1.7.10.4
--
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] xhci: Add BayTrail to list of Intel switchable hosts
On Tue, May 21, 2013 at 10:37:55AM -0400, Alan Stern wrote:
On Tue, 21 May 2013, Heikki Krogerus wrote:
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 595d210..a5708d9 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -322,7 +322,8 @@ static bool usb_is_intel_switchable_ehci(struct pci_dev
*pdev)
(pdev-device == 0x1E26 ||
pdev-device == 0x8C2D ||
pdev-device == 0x8C26 ||
-pdev-device == 0x9C26);
+pdev-device == 0x9C26 ||
+pdev-device == 0x0F34);
The entries should be kept sorted in numerical order. In fact, you
might even interchange the 0x8C2D and 0x8C26 entries.
OK.
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 4c338ec..6062822 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -724,6 +724,7 @@ static int handshake(void __iomem *ptr, u32 mask, u32
done,
#define PCI_DEVICE_ID_INTEL_LYNX_POINT_XHCI0x8C31
#define PCI_DEVICE_ID_INTEL_LYNX_POINT_LP_XHCI 0x9C31
+#define PCI_DEVICE_ID_INTEL_BYT_XHCI 0x0F35
bool usb_is_intel_ppt_switchable_xhci(struct pci_dev *pdev)
{
@@ -741,10 +742,19 @@ bool usb_is_intel_lpt_switchable_xhci(struct pci_dev
*pdev)
pdev-device == PCI_DEVICE_ID_INTEL_LYNX_POINT_LP_XHCI);
}
+/* And so does the Intel BayTrail. */
+bool usb_is_intel_byt_switchable_xhci(struct pci_dev *pdev)
+{
+ return pdev-class == PCI_CLASS_SERIAL_USB_XHCI
+ pdev-vendor == PCI_VENDOR_ID_INTEL
+ pdev-device == PCI_DEVICE_ID_INTEL_BYT_XHCI;
+}
+
bool usb_is_intel_switchable_xhci(struct pci_dev *pdev)
{
return usb_is_intel_ppt_switchable_xhci(pdev) ||
- usb_is_intel_lpt_switchable_xhci(pdev);
+ usb_is_intel_lpt_switchable_xhci(pdev) ||
+ usb_is_intel_byt_switchable_xhci(pdev);
}
EXPORT_SYMBOL_GPL(usb_is_intel_switchable_xhci);
This code cries out for refactoring. Why test pdev-class and
pdev-vendor in the same way in three different places? Those two
tests should be moved directly into usb_is_intel_switchable_xhci().
The other helper functions then become simple comparisons. As far as
I'm concerned, they also could be moved inline into
usb_is_intel_switchable_xhci(). Sarah may disagree, however.
Sarah what do you think?
--
heikki
--
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] xhci: Add BayTrail to list of Intel switchable hosts
On Tue, May 21, 2013 at 04:26:43PM +0400, Sergei Shtylyov wrote: Like the xHCI controller on Intel Panther Point and Lynx Point chipsets, the xHCI controller on Intel BayTrail has also ports that can be switched between the EHCI host controller. s/between/to/ OK. Thanks, -- heikki -- 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] xhci: Add BayTrail to list of Intel switchable hosts
Hi Sarah, On Fri, May 24, 2013 at 09:55:25AM -0700, Sarah Sharp wrote: At this point the port switchover quirk is getting unwieldy. I know of at least two more platforms that will need the switchover quirk, and it's silly to keep adding them to the list. Heikki, can you change the code to always try to switchover the ports from EHCI to xHCI if an Intel xHCI host is found, and fail gracefully if there isn't an EHCI host controller on board? I suspect Intel will include the port switchover mechanism until they decide to only include xHCI hosts and no EHCI hosts. In the meantime, we can avoid breaking USB 3.0 new platforms by always attempting to do the switchover. OK, makes sense. I or Mathias will make the patch for you. Thanks, -- heikki -- 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 v2 06/11] USB: mxs-phy: add basic otg support
Hi,
On Tue, Aug 28, 2012 at 03:03:12PM +0800, Richard Zhao wrote:
+static int mxs_phy_set_host(struct usb_otg *otg, struct usb_bus *host)
+{
Shouldn't you at least save the host pointer?
otg-host = host;
+ return 0;
+}
+
+static int mxs_phy_set_peripheral(struct usb_otg *otg,
+ struct usb_gadget *gadget)
+{
And the same with the gadget?
+ return 0;
+}
--
heikki
--
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
[PATCH] phy: don't return error from the stubs
Returning 0 from the stubs for the functions that are used
for PHY controlling. The interface should not appear to be
failing with every operation when the framework is not
enabled.
This fixes an issue in dwc3 driver, where the driver fails
the moment first phy_*() call is made when the framework is
not enabled.
Reported-by: Chew, Chiau Ee chiau.ee.c...@intel.com
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
include/linux/phy/phy.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e2f5ca9..00d6949 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -174,22 +174,22 @@ void devm_of_phy_provider_unregister(struct device *dev,
#else
static inline int phy_pm_runtime_get(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline int phy_pm_runtime_get_sync(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline int phy_pm_runtime_put(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline int phy_pm_runtime_put_sync(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline void phy_pm_runtime_allow(struct phy *phy)
@@ -204,27 +204,27 @@ static inline void phy_pm_runtime_forbid(struct phy *phy)
static inline int phy_init(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline int phy_exit(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline int phy_power_on(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline int phy_power_off(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline int phy_get_bus_width(struct phy *phy)
{
- return -ENOSYS;
+ return 0;
}
static inline void phy_set_bus_width(struct phy *phy, int bus_width)
--
1.9.1
--
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 RFC 3/4] xhci: Tune PHY for the DWC3-Exynos host controller
Hi,
On Tue, Apr 15, 2014 at 06:24:11PM +0530, Vivek Gautam wrote:
I had seen your patches in the mailing list, but i don't see any
updated version of these patches.
Are you planning to work on this above mentioned patch-series any time soon ?
I'm sorry, I forgot this completely. I have not prepared new version
of those patches as the drivers I need them for are not ready yet, but
I guess I can also use this case as justification for them.
Or, should i try to find a different approach for handling the phy
from the host controller (child of DWC3 in this case, which has the
phys).
Well, there is now an issue with the lookup method I'm suggesting in
this case. Since the device ID is now generated automatically for
xhci-hcd in dwc3, we don't know the xhci-hcd device name before
platform_device_add(), and that is too late. I don't see why the
device could not be named when platform_device_alloc() is called, so I
think I'll suggest something like the attached patch to fix this
issue.
In any case, I'll send an updated version of the phy patches soon.
Thanks,
--
heikki
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index e714709..13f8edb 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -169,11 +169,47 @@ struct platform_object {
*/
void platform_device_put(struct platform_device *pdev)
{
- if (pdev)
- put_device(pdev-dev);
+ if (!pdev)
+ return;
+
+ if (pdev-id_auto) {
+ ida_simple_remove(platform_devid_ida, pdev-id);
+ pdev-id = PLATFORM_DEVID_AUTO;
+ }
+
+ put_device(pdev-dev);
}
EXPORT_SYMBOL_GPL(platform_device_put);
+static int pdev_set_name(struct platform_device *pdev)
+{
+ int ret;
+
+ switch (pdev-id) {
+ default:
+ dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
+ break;
+ case PLATFORM_DEVID_NONE:
+ dev_set_name(pdev-dev, %s, pdev-name);
+ break;
+ case PLATFORM_DEVID_AUTO:
+ /*
+ * Automatically allocated device ID. We mark it as such so
+ * that we remember it must be freed, and we append a suffix
+ * to avoid namespace collision with explicit IDs.
+ */
+ ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
+ if (ret 0)
+ return ret;
+ pdev-id = ret;
+ pdev-id_auto = true;
+ dev_set_name(pdev-dev, %s.%d.auto, pdev-name, pdev-id);
+ break;
+ }
+
+ return 0;
+}
+
static void platform_device_release(struct device *dev)
{
struct platform_object *pa = container_of(dev, struct platform_object,
@@ -206,6 +242,10 @@ struct platform_device *platform_device_alloc(const char *name, int id)
device_initialize(pa-pdev.dev);
pa-pdev.dev.release = platform_device_release;
arch_setup_pdev_archdata(pa-pdev);
+ if (pdev_set_name(pa-pdev)) {
+ kfree(pa);
+ return NULL;
+ }
}
return pa ? pa-pdev : NULL;
@@ -286,28 +326,6 @@ int platform_device_add(struct platform_device *pdev)
pdev-dev.bus = platform_bus_type;
- switch (pdev-id) {
- default:
- dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
- break;
- case PLATFORM_DEVID_NONE:
- dev_set_name(pdev-dev, %s, pdev-name);
- break;
- case PLATFORM_DEVID_AUTO:
- /*
- * Automatically allocated device ID. We mark it as such so
- * that we remember it must be freed, and we append a suffix
- * to avoid namespace collision with explicit IDs.
- */
- ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
- if (ret 0)
- goto err_out;
- pdev-id = ret;
- pdev-id_auto = true;
- dev_set_name(pdev-dev, %s.%d.auto, pdev-name, pdev-id);
- break;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *p, *r = pdev-resource[i];
@@ -350,7 +368,6 @@ int platform_device_add(struct platform_device *pdev)
release_resource(r);
}
- err_out:
return ret;
}
EXPORT_SYMBOL_GPL(platform_device_add);
@@ -370,11 +387,6 @@ void platform_device_del(struct platform_device *pdev)
if (pdev) {
device_del(pdev-dev);
- if (pdev-id_auto) {
- ida_simple_remove(platform_devid_ida, pdev-id);
- pdev-id = PLATFORM_DEVID_AUTO;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *r = pdev-resource[i];
unsigned long type = resource_type(r);
@@ -392,8 +404,15 @@ EXPORT_SYMBOL_GPL(platform_device_del);
*/
int platform_device_register(struct platform_device *pdev)
{
+ int ret;
+
device_initialize(pdev-dev);
arch_setup_pdev_archdata(pdev);
+
+ ret = pdev_set_name(pdev);
+ if (ret)
+ return ret;
+
return platform_device_add(pdev);
}
EXPORT_SYMBOL_GPL(platform_device_register);
[PATCHv2 5/6] base: platform: name the device already during allocation
This allows resources such as GPIOs and clocks, which can be
matched based on the device name when requested, to be
assigned even when PLATFORM_DEVID_AUTO is used.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/base/platform.c | 77 ++---
1 file changed, 47 insertions(+), 30 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 9e9227e..e856bc4 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -177,11 +177,45 @@ struct platform_object {
*/
void platform_device_put(struct platform_device *pdev)
{
- if (pdev)
- put_device(pdev-dev);
+ if (!pdev)
+ return;
+
+ if (pdev-id_auto) {
+ ida_simple_remove(platform_devid_ida, pdev-id);
+ pdev-id = PLATFORM_DEVID_AUTO;
+ }
+
+ put_device(pdev-dev);
}
EXPORT_SYMBOL_GPL(platform_device_put);
+static int pdev_set_name(struct platform_device *pdev)
+{
+ int ret;
+
+ switch (pdev-id) {
+ default:
+ return dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
+ case PLATFORM_DEVID_NONE:
+ return dev_set_name(pdev-dev, %s, pdev-name);
+ case PLATFORM_DEVID_AUTO:
+ /*
+* Automatically allocated device ID. We mark it as such so
+* that we remember it must be freed, and we append a suffix
+* to avoid namespace collision with explicit IDs.
+*/
+ ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
+ if (ret 0)
+ return ret;
+ pdev-id = ret;
+ pdev-id_auto = true;
+ return dev_set_name(pdev-dev, %s.%d.auto, pdev-name,
+ pdev-id);
+ }
+
+ return 0;
+}
+
static void platform_device_release(struct device *dev)
{
struct platform_object *pa = container_of(dev, struct platform_object,
@@ -214,6 +248,10 @@ struct platform_device *platform_device_alloc(const char
*name, int id)
device_initialize(pa-pdev.dev);
pa-pdev.dev.release = platform_device_release;
arch_setup_pdev_archdata(pa-pdev);
+ if (pdev_set_name(pa-pdev)) {
+ kfree(pa);
+ return NULL;
+ }
}
return pa ? pa-pdev : NULL;
@@ -294,28 +332,6 @@ int platform_device_add(struct platform_device *pdev)
pdev-dev.bus = platform_bus_type;
- switch (pdev-id) {
- default:
- dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
- break;
- case PLATFORM_DEVID_NONE:
- dev_set_name(pdev-dev, %s, pdev-name);
- break;
- case PLATFORM_DEVID_AUTO:
- /*
-* Automatically allocated device ID. We mark it as such so
-* that we remember it must be freed, and we append a suffix
-* to avoid namespace collision with explicit IDs.
-*/
- ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
- if (ret 0)
- goto err_out;
- pdev-id = ret;
- pdev-id_auto = true;
- dev_set_name(pdev-dev, %s.%d.auto, pdev-name, pdev-id);
- break;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *p, *r = pdev-resource[i];
@@ -358,7 +374,6 @@ int platform_device_add(struct platform_device *pdev)
release_resource(r);
}
- err_out:
return ret;
}
EXPORT_SYMBOL_GPL(platform_device_add);
@@ -378,11 +393,6 @@ void platform_device_del(struct platform_device *pdev)
if (pdev) {
device_del(pdev-dev);
- if (pdev-id_auto) {
- ida_simple_remove(platform_devid_ida, pdev-id);
- pdev-id = PLATFORM_DEVID_AUTO;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *r = pdev-resource[i];
unsigned long type = resource_type(r);
@@ -400,8 +410,15 @@ EXPORT_SYMBOL_GPL(platform_device_del);
*/
int platform_device_register(struct platform_device *pdev)
{
+ int ret;
+
device_initialize(pdev-dev);
arch_setup_pdev_archdata(pdev);
+
+ ret = pdev_set_name(pdev);
+ if (ret)
+ return ret;
+
return platform_device_add(pdev);
}
EXPORT_SYMBOL_GPL(platform_device_register);
--
2.0.0.rc4
--
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
[PATCHv2 6/6] usb: dwc3: host: convey the PHYs to xhci
On some platforms a PHY may need to be handled also in the
host controller driver. Exynos5420 SoC requires some PHY
tuning based on the USB speed. This patch delivers dwc3's
PHYs to the xhci platform device when it's created.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/host.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index 32db328..8387564 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -27,8 +27,7 @@ int dwc3_host_init(struct dwc3 *dwc)
xhci = platform_device_alloc(xhci-hcd, PLATFORM_DEVID_AUTO);
if (!xhci) {
dev_err(dwc-dev, couldn't allocate xHCI device\n);
- ret = -ENOMEM;
- goto err0;
+ return -ENOMEM;
}
dma_set_coherent_mask(xhci-dev, dwc-dev-coherent_dma_mask);
@@ -46,22 +45,33 @@ int dwc3_host_init(struct dwc3 *dwc)
goto err1;
}
+ phy_create_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(xhci-dev));
+ phy_create_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(xhci-dev));
+
ret = platform_device_add(xhci);
if (ret) {
dev_err(dwc-dev, failed to register xHCI device\n);
- goto err1;
+ goto err2;
}
return 0;
-
+err2:
+ phy_remove_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(xhci-dev));
+ phy_remove_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(xhci-dev));
err1:
platform_device_put(xhci);
-
-err0:
return ret;
}
void dwc3_host_exit(struct dwc3 *dwc)
{
+ phy_remove_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(dwc-xhci-dev));
+ phy_remove_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(dwc-xhci-dev));
platform_device_unregister(dwc-xhci);
}
--
2.0.0.rc4
--
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
[PATCHv2 4/6] phy: remove the old lookup method
The users of the old method are now converted to the new one.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/phy/phy-bcm-kona-usb2.c | 2 +-
drivers/phy/phy-core.c | 45 +++--
drivers/phy/phy-exynos-dp-video.c | 2 +-
drivers/phy/phy-exynos-mipi-video.c | 2 +-
drivers/phy/phy-exynos5-usbdrd.c| 3 +--
drivers/phy/phy-exynos5250-sata.c | 2 +-
drivers/phy/phy-mvebu-sata.c| 2 +-
drivers/phy/phy-omap-usb2.c | 2 +-
drivers/phy/phy-samsung-usb2.c | 2 +-
drivers/phy/phy-sun4i-usb.c | 2 +-
drivers/phy/phy-ti-pipe3.c | 2 +-
drivers/phy/phy-twl4030-usb.c | 4 +---
drivers/phy/phy-xgene.c | 2 +-
include/linux/phy/phy.h | 37 --
14 files changed, 19 insertions(+), 90 deletions(-)
diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
index e94f5a6..47d810f 100644
--- a/drivers/phy/phy-bcm-kona-usb2.c
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -117,7 +117,7 @@ static int bcm_kona_usb2_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, phy);
- gphy = devm_phy_create(dev, ops, NULL);
+ gphy = devm_phy_create(dev, ops);
if (IS_ERR(gphy))
return PTR_ERR(gphy);
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 38034fd..74d4346 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -54,36 +54,6 @@ static int devm_phy_match(struct device *dev, void *res,
void *match_data)
return res == match_data;
}
-static struct phy *phy_lookup(struct device *device, const char *port)
-{
- unsigned int count;
- struct phy *phy;
- struct device *dev;
- struct phy_consumer *consumers;
- struct class_dev_iter iter;
-
- class_dev_iter_init(iter, phy_class, NULL, NULL);
- while ((dev = class_dev_iter_next(iter))) {
- phy = to_phy(dev);
-
- if (!phy-init_data)
- continue;
- count = phy-init_data-num_consumers;
- consumers = phy-init_data-consumers;
- while (count--) {
- if (!strcmp(consumers-dev_name, dev_name(device))
- !strcmp(consumers-port, port)) {
- class_dev_iter_exit(iter);
- return phy;
- }
- consumers++;
- }
- }
-
- class_dev_iter_exit(iter);
- return ERR_PTR(-ENODEV);
-}
-
/**
* phy_register_lookup() - register PHY/device association
* @pl: association to register
@@ -209,10 +179,6 @@ static struct phy *phy_find(struct device *dev, const char
*con_id)
}
class_dev_iter_exit(iter);
}
-
- /* fall-back to the old lookup method for now */
- if (IS_ERR(phy))
- phy = phy_lookup(dev, con_id);
return phy;
}
@@ -696,12 +662,10 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
* phy_create() - create a new phy
* @dev: device that is creating the new phy
* @ops: function pointers for performing phy operations
- * @init_data: contains the list of PHY consumers or NULL
*
* Called to create a phy using phy framework.
*/
-struct phy *phy_create(struct device *dev, const struct phy_ops *ops,
- struct phy_init_data *init_data)
+struct phy *phy_create(struct device *dev, const struct phy_ops *ops)
{
int ret;
int id;
@@ -729,7 +693,6 @@ struct phy *phy_create(struct device *dev, const struct
phy_ops *ops,
phy-dev.of_node = dev-of_node;
phy-id = id;
phy-ops = ops;
- phy-init_data = init_data;
ret = dev_set_name(phy-dev, phy-%s.%d, dev_name(dev), id);
if (ret)
@@ -759,15 +722,13 @@ EXPORT_SYMBOL_GPL(phy_create);
* devm_phy_create() - create a new phy
* @dev: device that is creating the new phy
* @ops: function pointers for performing phy operations
- * @init_data: contains the list of PHY consumers or NULL
*
* Creates a new PHY device adding it to the PHY class.
* While at that, it also associates the device with the phy using devres.
* On driver detach, release function is invoked on the devres data,
* then, devres data is freed.
*/
-struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops,
- struct phy_init_data *init_data)
+struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops)
{
struct phy **ptr, *phy;
@@ -775,7 +736,7 @@ struct phy *devm_phy_create(struct device *dev, const
struct phy_ops *ops,
if (!ptr)
return ERR_PTR(-ENOMEM);
- phy = phy_create(dev, ops, init_data);
+ phy = phy_create(dev, ops);
if (!IS_ERR(phy)) {
*ptr = phy;
devres_add(dev, ptr);
diff --git a/drivers/phy/phy-exynos-dp-video.c
b
[PATCHv2 3/6] arm: omap3: twl: use the new lookup method with usb phy
Provide complete association for the phy and it's user
(musb) with the new phy lookup method.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/twl-common.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index b0d54da..b78383c 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -91,18 +91,14 @@ void __init omap_pmic_late_init(void)
}
#if defined(CONFIG_ARCH_OMAP3)
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
-};
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
+static struct phy_lookup twl4030_usb_lookup = {
+ .phy_name = phy-twl4030_usb.0,
+ .dev_id = musb-hdrc.0,
+ .con_id = usb,
};
static struct twl4030_usb_data omap3_usb_pdata = {
- .usb_mode = T2_USB_MODE_ULPI,
- .init_data = init_data,
+ .usb_mode = T2_USB_MODE_ULPI,
};
static int omap3_batt_table[] = {
@@ -225,8 +221,10 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
}
/* Common platform data configurations */
- if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
+ if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb) {
+ phy_register_lookup(twl4030_usb_lookup);
pmic_data-usb = omap3_usb_pdata;
+ }
if (pdata_flags TWL_COMMON_PDATA_BCI !pmic_data-bci)
pmic_data-bci = omap3_bci_pdata;
--
2.0.0.rc4
--
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
[PATCHv2 0/6] phy: simplified phy lookup
Hi, So the idea with these is that they should help to make it possible to request phys without caring about how they are mapped to the consumers, meaning, was is the mapping done in DT, ACPI, etc. Mapping phys to consumers can be now done with lookups similarly how clocks can be mapped in clkdev.c. Vivek needs to handle the phys of dwc3 also in xhci driver on Exynos5420 SoC, so I'm resending these now. Heikki Krogerus (6): phy: safer to_phy() macro phy: improved lookup method arm: omap3: twl: use the new lookup method with usb phy phy: remove the old lookup method base: platform: name the device already during allocation usb: dwc3: host: convey the PHYs to xhci Documentation/phy.txt | 66 +-- arch/arm/mach-omap2/twl-common.c| 18 ++--- drivers/base/platform.c | 77 +++--- drivers/phy/phy-bcm-kona-usb2.c | 2 +- drivers/phy/phy-core.c | 156 +--- drivers/phy/phy-exynos-dp-video.c | 2 +- drivers/phy/phy-exynos-mipi-video.c | 2 +- drivers/phy/phy-exynos5-usbdrd.c| 3 +- drivers/phy/phy-exynos5250-sata.c | 2 +- drivers/phy/phy-mvebu-sata.c| 2 +- drivers/phy/phy-omap-usb2.c | 2 +- drivers/phy/phy-samsung-usb2.c | 2 +- drivers/phy/phy-sun4i-usb.c | 2 +- drivers/phy/phy-ti-pipe3.c | 2 +- drivers/phy/phy-twl4030-usb.c | 4 +- drivers/phy/phy-xgene.c | 2 +- drivers/usb/dwc3/host.c | 22 +++-- include/linux/phy/phy.h | 60 +++--- 18 files changed, 259 insertions(+), 167 deletions(-) -- 2.0.0.rc4 -- 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
[PATCHv2 1/6] phy: safer to_phy() macro
This makes to_phy() macro work with other variable names
besides dev.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
include/linux/phy/phy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 2760744..10d9714 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -108,7 +108,7 @@ struct phy_init_data {
.port = _port,\
}
-#defineto_phy(dev) (container_of((dev), struct phy, dev))
+#defineto_phy(a) (container_of((a), struct phy, dev))
#defineof_phy_provider_register(dev, xlate)\
__of_phy_provider_register((dev), THIS_MODULE, (xlate))
--
2.0.0.rc4
--
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
[PATCHv2 2/6] phy: improved lookup method
Removes the need for the phys to be aware of their users
even when not using DT. The method is copied from clkdev.c.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
Documentation/phy.txt | 66 ---
drivers/phy/phy-core.c | 135 +++-
include/linux/phy/phy.h | 27 ++
3 files changed, 183 insertions(+), 45 deletions(-)
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
index ebff6ee..441dc10 100644
--- a/Documentation/phy.txt
+++ b/Documentation/phy.txt
@@ -53,17 +53,13 @@ unregister 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, const struct phy_ops *ops,
-struct phy_init_data *init_data);
-struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops,
- struct phy_init_data *init_data);
+struct phy *phy_create(struct device *dev, const struct phy_ops *ops);
+struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops);
The PHY drivers can use one of the above 2 APIs to create the PHY by passing
-the device pointer, phy ops and init_data.
+the device pointer and phy ops.
phy_ops is a set of function pointers for performing PHY operations such as
-init, exit, power_on and power_off. *init_data* is mandatory to get a reference
-to the PHY in the case of non-dt boot. See section *Board File Initialization*
-on how init_data should be used.
+init, exit, power_on and power_off.
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
@@ -135,42 +131,24 @@ 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. Board File Initialization
-
-Certain board file initialization is necessary in order to get a reference
-to the PHY in the case of non-dt boot.
-Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe,
-then in the board file the following initialization should be done.
-
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(dwc3.0, usb),
- PHY_CONSUMER(pcie.0, pcie),
- PHY_CONSUMER(sata.0, sata),
-};
-PHY_CONSUMER takes 2 parameters, first is the device name of the controller
-(PHY consumer) and second is the port name.
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
-};
-
-static const struct platform_device pipe3_phy_dev = {
- .name = pipe3-phy,
- .id = -1,
- .dev = {
- .platform_data = {
- .init_data = init_data,
- },
- },
-};
-
-then, while doing phy_create, the PHY driver should pass this init_data
- phy_create(dev, ops, pdata-init_data);
-
-and the controller driver (phy consumer) should pass the port name along with
-the device to get a reference to the PHY
- phy_get(dev, pcie);
+8. PHY Mappings
+
+In order to get reference to a PHY without help from DeviceTree, the framework
+offers lookups which can be compared to clkdev that allow clk structures to be
+bound to devices. A lookup can be made statically by directly registering
+phy_lookup structure which contains the name of the PHY device, the name of the
+device which the PHY will be bind to and Connection ID string. Alternatively a
+lookup can be made during runtime when a handle to the struct phy already
+exists.
+
+The framework offers the following APIs for registering and unregistering the
+lookups.
+
+void phy_register_lookup(struct phy_lookup *pl);
+int phy_create_lookup(struct phy *phy, const char *con_id, const char *dev_id);
+
+void phy_unregister_lookup(struct phy_lookup *pl);
+void phy_remove_lookup(struct phy *phy, const char *con_id, const char
*dev_id);
9. DeviceTree Binding
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index c64a2f3..38034fd 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -25,6 +25,7 @@
static struct class *phy_class;
static DEFINE_MUTEX(phy_provider_mutex);
static LIST_HEAD(phy_provider_list);
+static LIST_HEAD(phys);
static DEFINE_IDA(phy_ida);
static void devm_phy_release(struct device *dev, void *res)
@@ -83,6 +84,138 @@ static struct phy *phy_lookup(struct device *device, const
char *port)
return ERR_PTR(-ENODEV);
}
+/**
+ * phy_register_lookup() - register PHY/device association
+ * @pl: association to register
+ */
+void phy_register_lookup(struct phy_lookup *pl)
+{
+ mutex_lock(phy_provider_mutex);
+ list_add_tail(pl-node, phys);
+ mutex_unlock(phy_provider_mutex);
+}
+
+/**
+ * phy_unregister_lookup() - remove PHY/device association
+ * @pl: association to be removed
+ */
+void
[RFC PATH 3/3] phy: ulpi: add support for NXP ISP170X USB PHY
This driver is based on drivers/power/isp1704_power.c. It
simply converts the original driver to ulpi driver.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/phy/ulpi/Kconfig| 10 +
drivers/phy/ulpi/Makefile | 1 +
drivers/phy/ulpi/isp1704_ulpi.c | 446
3 files changed, 457 insertions(+)
create mode 100644 drivers/phy/ulpi/isp1704_ulpi.c
diff --git a/drivers/phy/ulpi/Kconfig b/drivers/phy/ulpi/Kconfig
index 3211aaa..1340df7 100644
--- a/drivers/phy/ulpi/Kconfig
+++ b/drivers/phy/ulpi/Kconfig
@@ -9,3 +9,13 @@ config ULPI_PHY
If unsure, say Y.
+if ULPI_PHY
+
+config ULPI_ISP170X
+ tristate NXP ISP170X USB PHY module
+ depends on POWER_SUPPLY
+ select USB_PHY
+ help
+ Support for NXP ISP170X ULPI PHY.
+
+endif
diff --git a/drivers/phy/ulpi/Makefile b/drivers/phy/ulpi/Makefile
index 7ed0895..d873e37 100644
--- a/drivers/phy/ulpi/Makefile
+++ b/drivers/phy/ulpi/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_ULPI_PHY) += ulpi.o
+obj-$(CONFIG_ULPI_ISP170X) += isp1704_ulpi.o
diff --git a/drivers/phy/ulpi/isp1704_ulpi.c b/drivers/phy/ulpi/isp1704_ulpi.c
new file mode 100644
index 000..301fe9b
--- /dev/null
+++ b/drivers/phy/ulpi/isp1704_ulpi.c
@@ -0,0 +1,446 @@
+/**
+ * ISP1704 USB ULPI PHY driver
+ *
+ * Copyright (C) 2013 Intel Corporation
+ *
+ * Author: Heikki Krogerus heikki.kroge...@linux.intel.com
+ *
+ * The code is based on drivers/power/isp1704_charger.c
+ * Copyright (C) 2010 Nokia Corporation
+ * Copyright (C) 2012 - 2013 Pali Rohár pali.ro...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/module.h
+#include linux/phy/phy.h
+#include linux/phy/ulpi.h
+#include linux/gpio/consumer.h
+#include linux/power_supply.h
+#include linux/usb/otg.h
+#include linux/usb/gadget.h
+
+/* Vendor specific Power Control register */
+#define ISP1704_PWR_CTRL 0x3d
+#define ISP1704_PWR_CTRL_SWCTRL(1 0)
+#define ISP1704_PWR_CTRL_DET_COMP (1 1)
+#define ISP1704_PWR_CTRL_BVALID_RISE (1 2)
+#define ISP1704_PWR_CTRL_BVALID_FALL (1 3)
+#define ISP1704_PWR_CTRL_DP_WKPU_EN(1 4)
+#define ISP1704_PWR_CTRL_VDAT_DET (1 5)
+#define ISP1704_PWR_CTRL_DPVSRC_EN (1 6)
+#define ISP1704_PWR_CTRL_HWDETECT (1 7)
+
+#define NXP_VENDOR_ID 0x04cc
+
+struct isp1704_phy {
+ struct notifier_block nb;
+ struct power_supply psy;
+ struct work_struct work;
+ struct gpio_desc *gpio;
+ struct usb_phy phy;
+ struct usb_otg otg;
+ struct device *dev;
+
+ /* properties */
+ char model[8];
+ unsigned present:1;
+ unsigned online:1;
+ unsigned current_max;
+};
+
+static inline int isp1704_read(struct isp1704_phy *isp, u8 addr)
+{
+ return ulpi_read(to_ulpi_dev(isp-dev), addr);
+}
+
+static inline int isp1704_write(struct isp1704_phy *isp, u8 addr, u8 val)
+{
+ return ulpi_write(to_ulpi_dev(isp-dev), addr, val);
+}
+
+/* --
*/
+
+/**
+ * Determine is the charging port DCP (dedicated charger) or CDP (Host/HUB
+ * chargers).
+ *
+ * REVISIT: The method is defined in Battery Charging Specification and is
+ * applicable to any ULPI transceiver. Nothing isp170x specific here.
+ */
+static inline int isp1704_type(struct isp1704_phy *isp)
+{
+ int type = POWER_SUPPLY_TYPE_USB_DCP;
+ u8 func_ctrl;
+ u8 otg_ctrl;
+ u8 val;
+
+ func_ctrl = isp1704_read(isp, ULPI_FUNC_CTRL);
+ otg_ctrl = isp1704_read(isp, ULPI_OTG_CTRL);
+
+ /* disable pulldowns */
+ val = ULPI_OTG_CTRL_DM_PULLDOWN | ULPI_OTG_CTRL_DP_PULLDOWN;
+ isp1704_write(isp, ULPI_CLR(ULPI_OTG_CTRL), val);
+
+ /* full speed */
+ isp1704_write(isp, ULPI_CLR(ULPI_FUNC_CTRL),
+ ULPI_FUNC_CTRL_XCVRSEL_MASK);
+ isp1704_write(isp, ULPI_SET(ULPI_FUNC_CTRL),
+ ULPI_FUNC_CTRL_FULL_SPEED);
+
+ /* Enable strong pull-up on DP (1.5K) and reset */
+ val = ULPI_FUNC_CTRL_TERMSELECT | ULPI_FUNC_CTRL_RESET;
+ isp1704_write(isp, ULPI_SET(ULPI_FUNC_CTRL), val);
+ usleep_range(1000, 2000);
+
+ val = isp1704_read(isp, ULPI_DEBUG);
+ if ((val 3) != 3)
+ type = POWER_SUPPLY_TYPE_USB_CDP;
+
+ /* recover original state */
+ isp1704_write(isp, ULPI_FUNC_CTRL, func_ctrl);
+ isp1704_write(isp, ULPI_OTG_CTRL, otg_ctrl);
+
+ return type;
+}
+
+/**
+ * ISP1704 detects PS/2 adapters as charger. To make sure the detected charger
+ * is actually a dedicated charger, the following steps need to be taken.
+ */
+static inline int isp1704_verify(struct isp1704_phy
[RFC PATH 2/3] usb: dwc3: add ULPI interface support
Registers ULPI interface with the ULPI abstraction layer if
the HSPHY type is ULPI, which will create phy instance for
usb2.
Depends on Kishon's patch set adding support for generic PHY
framework.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/usb/dwc3/Kconfig | 7 +++
drivers/usb/dwc3/Makefile | 4 ++
drivers/usb/dwc3/core.c | 8
drivers/usb/dwc3/core.h | 21 +
drivers/usb/dwc3/ulpi.c | 110 ++
5 files changed, 150 insertions(+)
create mode 100644 drivers/usb/dwc3/ulpi.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 64eed6f..a97b294 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -13,6 +13,13 @@ config USB_DWC3
if USB_DWC3
+config USB_DWC3_ULPI
+ bool Provide ULPI PHY Interface
+ depends on ULPI_PHY=y || ULPI_PHY=USB_DWC3
+ help
+ Select this if you have ULPI type PHY attached to your DWC3
+ controller.
+
choice
bool DWC3 Mode Selection
default USB_DWC3_DUAL_ROLE if (USB USB_GADGET)
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index dd17601..8bb82bc 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -13,6 +13,10 @@ ifneq ($(filter y,$(CONFIG_USB_DWC3_GADGET)
$(CONFIG_USB_DWC3_DUAL_ROLE)),)
dwc3-y += gadget.o ep0.o
endif
+ifneq ($(CONFIG_USB_DWC3_ULPI),)
+ dwc3-y += ulpi.o
+endif
+
ifneq ($(CONFIG_DEBUG_FS),)
dwc3-y += debugfs.o
endif
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 1c0a69a..94927b2 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -505,6 +505,12 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-regs_size = resource_size(res);
dwc-dev= dev;
+ if (!dwc-usb2_generic_phy) {
+ ret = dwc3_ulpi_init(dwc);
+ if (ret)
+ return ret;
+ }
+
dev-dma_mask = dev-parent-dma_mask;
dev-dma_parms = dev-parent-dma_parms;
dma_set_coherent_mask(dev, dev-parent-coherent_dma_mask);
@@ -613,6 +619,7 @@ err1:
err0:
dwc3_free_event_buffers(dwc);
+ dwc3_ulpi_exit(dwc);
return ret;
}
@@ -653,6 +660,7 @@ static int dwc3_remove(struct platform_device *pdev)
dwc3_event_buffers_cleanup(dwc);
dwc3_free_event_buffers(dwc);
dwc3_core_exit(dwc);
+ dwc3_ulpi_exit(dwc);
return 0;
}
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 01ec7d7..6df398a 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -169,6 +169,14 @@
#define DWC3_GUSB2PHYCFG_PHYSOFTRST(1 31)
#define DWC3_GUSB2PHYCFG_SUSPHY(1 6)
+/* Global USB2 PHY Vendor Control Register */
+#define DWC3_GUSB2PHYACC_NEWREGREQ (1 25)
+#define DWC3_GUSB2PHYACC_BUSY (1 23)
+#define DWC3_GUSB2PHYACC_WRITE (1 22)
+#define DWC3_GUSB2PHYACC_ADDR(n) (n 16)
+#define DWC3_GUSB2PHYACC_EXTEND_ADDR(n)(n 8)
+#define DWC3_GUSB2PHYACC_DATA(n) (n 0xff)
+
/* Global USB3 PIPE Control Register */
#define DWC3_GUSB3PIPECTL_PHYSOFTRST (1 31)
#define DWC3_GUSB3PIPECTL_SUSPHY (1 17)
@@ -557,6 +565,7 @@ struct dwc3_hwparams {
#define DWC3_NUM_INT(n)(((n) (0x3f 15)) 15)
/* HWPARAMS3 */
+#define DWC3_ULPI_HSPHY(1 3)
#define DWC3_NUM_IN_EPS_MASK (0x1f 18)
#define DWC3_NUM_EPS_MASK (0x3f 12)
#define DWC3_NUM_EPS(p)(((p)-hwparams3 \
@@ -672,6 +681,8 @@ struct dwc3 {
struct phy *usb2_generic_phy;
struct phy *usb3_generic_phy;
+ struct ulpi_interface *ulpi;
+
void __iomem*regs;
size_t regs_size;
@@ -922,4 +933,14 @@ static inline int dwc3_gadget_resume(struct dwc3 *dwc)
}
#endif /* !IS_ENABLED(CONFIG_USB_DWC3_HOST) */
+#if IS_ENABLED(CONFIG_USB_DWC3_ULPI)
+int dwc3_ulpi_init(struct dwc3 *dwc);
+void dwc3_ulpi_exit(struct dwc3 *dwc);
+#else
+static inline int dwc3_ulpi_init(struct dwc3 *dwc)
+{ return 0; }
+static inline void dwc3_ulpi_exit(struct dwc3 *dwc)
+{ }
+#endif
+
#endif /* __DRIVERS_USB_DWC3_CORE_H */
diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c
new file mode 100644
index 000..e1f152b
--- /dev/null
+++ b/drivers/usb/dwc3/ulpi.c
@@ -0,0 +1,110 @@
+/**
+ * ulpi.c - DesignWare USB3 ULPI PHY interface
+ *
+ * Copyright (C) 2013 Intel Corporation
+ *
+ * Author: Heikki Krogerus heikki.kroge...@linux.intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux
[RFC PATH 0/3] USB PHYs and PCI
Hi guys, PCI does not give any information about the PHY but we still need to be able to take advantage of any possible vendor specific features, such as custom PM operations, charger detection, ADP probing and sensing, etc. the PHY provides. Since ULPI provides a way to do runtime detection, I'm introducing this layer on top of Kishon's generic phy framework. It gives us means to detect the ULPI product and bind it to a driver without need for nasty platform/device specific quirks in case of ULPI PHYs. I trust nobody has a problem with this approach, but I would like to get your feedback at this stage, before I make any drivers on top of this thing. The isp1704_ulpi.c I made just as an example for now. Thanks, Heikki Krogerus (3): phy: add USB ULPI abstraction layer usb: dwc3: add ULPI interface support phy: ulpi: add support for NXP ISP170X USB PHY drivers/phy/Kconfig | 2 + drivers/phy/Makefile| 1 + drivers/phy/ulpi/Kconfig| 21 ++ drivers/phy/ulpi/Makefile | 2 + drivers/phy/ulpi/isp1704_ulpi.c | 446 drivers/phy/ulpi/ulpi.c | 273 drivers/usb/dwc3/Kconfig| 7 + drivers/usb/dwc3/Makefile | 4 + drivers/usb/dwc3/core.c | 8 + drivers/usb/dwc3/core.h | 21 ++ drivers/usb/dwc3/ulpi.c | 110 ++ include/linux/phy/ulpi.h| 105 ++ 12 files changed, 1000 insertions(+) create mode 100644 drivers/phy/ulpi/Kconfig create mode 100644 drivers/phy/ulpi/Makefile create mode 100644 drivers/phy/ulpi/isp1704_ulpi.c create mode 100644 drivers/phy/ulpi/ulpi.c create mode 100644 drivers/usb/dwc3/ulpi.c create mode 100644 include/linux/phy/ulpi.h -- 1.8.4.4 -- 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
[RFC PATH 1/3] phy: add USB ULPI abstraction layer
ULPI PHY is an USB2 PHY that is accessed from the USB
controller. ULPI PHYs allow discovery based on vendor and
product ids which allows binding the PHY to a driver.
For USB controllers that are enumerated from buses such as
PCI, that do not provide any information about the PHY, ULPI
abstraction layer allows runtime detection. This makes it
possible to take advantage of vendor specific functions of
the PHYs with product specific drivers without the need for
platform or device specific quirks.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/phy/Kconfig | 2 +
drivers/phy/Makefile | 1 +
drivers/phy/ulpi/Kconfig | 11 ++
drivers/phy/ulpi/Makefile | 1 +
drivers/phy/ulpi/ulpi.c | 273 ++
include/linux/phy/ulpi.h | 105 ++
6 files changed, 393 insertions(+)
create mode 100644 drivers/phy/ulpi/Kconfig
create mode 100644 drivers/phy/ulpi/Makefile
create mode 100644 drivers/phy/ulpi/ulpi.c
create mode 100644 include/linux/phy/ulpi.h
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a344f3d..6c03824 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -51,4 +51,6 @@ config PHY_EXYNOS_DP_VIDEO
help
Support for Display Port PHY found on Samsung EXYNOS SoCs.
+source drivers/phy/ulpi/Kconfig
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..d6af605 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
+obj-$(CONFIG_ULPI_PHY) += ulpi/
diff --git a/drivers/phy/ulpi/Kconfig b/drivers/phy/ulpi/Kconfig
new file mode 100644
index 000..3211aaa
--- /dev/null
+++ b/drivers/phy/ulpi/Kconfig
@@ -0,0 +1,11 @@
+
+config ULPI_PHY
+ tristate USB ULPI PHY interface support
+ depends on USB || USB_GADGET
+ select GENERIC_PHY
+ help
+ Say yes if you have ULPI PHY attached to your USB controller. If no
+ vendor modules are selected, the driver will act as NOP PHY driver.
+
+ If unsure, say Y.
+
diff --git a/drivers/phy/ulpi/Makefile b/drivers/phy/ulpi/Makefile
new file mode 100644
index 000..7ed0895
--- /dev/null
+++ b/drivers/phy/ulpi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ULPI_PHY) += ulpi.o
diff --git a/drivers/phy/ulpi/ulpi.c b/drivers/phy/ulpi/ulpi.c
new file mode 100644
index 000..7aa2f5d
--- /dev/null
+++ b/drivers/phy/ulpi/ulpi.c
@@ -0,0 +1,273 @@
+/**
+ * ulpi.c - USB ULPI PHY abstraction module
+ *
+ * Copyright (C) 2013 Intel Corporation
+ *
+ * Author: Heikki Krogerus heikki.kroge...@linux.intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/phy/ulpi.h
+#include linux/phy/phy.h
+#include linux/module.h
+#include linux/slab.h
+
+/* --
*/
+
+static struct phy_consumer phy_consumer[] = {
+ { .port = ULPI_PORT_NAME, },
+};
+
+static struct phy_init_data phy_data = {
+ .num_consumers = 1,
+ .consumers = phy_consumer,
+};
+
+static int ulpi_power_on(struct phy *phy)
+{
+ struct ulpi_dev *ulpi = phy_get_drvdata(phy);
+ struct ulpi_driver *drv = to_ulpi_driver(ulpi-dev.driver);
+
+ if (drv drv-phy_ops drv-phy_ops-power_on)
+ return drv-phy_ops-power_on(phy);
+
+ return 0;
+}
+
+static int ulpi_power_off(struct phy *phy)
+{
+ struct ulpi_dev *ulpi = phy_get_drvdata(phy);
+ struct ulpi_driver *drv = to_ulpi_driver(ulpi-dev.driver);
+
+ if (drv drv-phy_ops drv-phy_ops-power_off)
+ return drv-phy_ops-power_off(phy);
+
+ return 0;
+}
+
+static struct phy_ops phy_ops = {
+ .owner = THIS_MODULE,
+ .power_on = ulpi_power_on,
+ .power_off = ulpi_power_off,
+};
+
+/* --
*/
+
+static int ulpi_match(struct device *dev, struct device_driver *driver)
+{
+ struct ulpi_driver *drv = to_ulpi_driver(driver);
+ struct ulpi_dev *ulpi = to_ulpi_dev(dev);
+ const struct ulpi_device_id *id;
+
+ for (id = drv-id_table; id-vendor; id++)
+ if (id-vendor == ulpi-id.vendor
+ id-product == ulpi-id.product)
+ return 1;
+
+ return 0;
+}
+
+static int ulpi_probe(struct device *dev)
+{
+ struct ulpi_driver *drv = to_ulpi_driver(dev-driver);
+
+ return drv-probe(to_ulpi_dev(dev));
+}
+
+static int ulpi_remove(struct device
Re: [RFC PATH 1/3] phy: add USB ULPI abstraction layer
Hi,
On Mon, Dec 02, 2013 at 04:20:51PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Thursday 28 November 2013 09:29 PM, Heikki Krogerus wrote:
ULPI PHY is an USB2 PHY that is accessed from the USB
controller. ULPI PHYs allow discovery based on vendor and
product ids which allows binding the PHY to a driver.
For USB controllers that are enumerated from buses such as
PCI, that do not provide any information about the PHY, ULPI
abstraction layer allows runtime detection. This makes it
possible to take advantage of vendor specific functions of
the PHYs with product specific drivers without the need for
platform or device specific quirks.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/phy/Kconfig | 2 +
drivers/phy/Makefile | 1 +
drivers/phy/ulpi/Kconfig | 11 ++
drivers/phy/ulpi/Makefile | 1 +
drivers/phy/ulpi/ulpi.c | 273
++
include/linux/phy/ulpi.h | 105 ++
6 files changed, 393 insertions(+)
create mode 100644 drivers/phy/ulpi/Kconfig
create mode 100644 drivers/phy/ulpi/Makefile
create mode 100644 drivers/phy/ulpi/ulpi.c
create mode 100644 include/linux/phy/ulpi.h
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a344f3d..6c03824 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -51,4 +51,6 @@ config PHY_EXYNOS_DP_VIDEO
help
Support for Display Port PHY found on Samsung EXYNOS SoCs.
+source drivers/phy/ulpi/Kconfig
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..d6af605 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
+obj-$(CONFIG_ULPI_PHY) += ulpi/
diff --git a/drivers/phy/ulpi/Kconfig b/drivers/phy/ulpi/Kconfig
new file mode 100644
index 000..3211aaa
--- /dev/null
+++ b/drivers/phy/ulpi/Kconfig
@@ -0,0 +1,11 @@
+
+config ULPI_PHY
+ tristate USB ULPI PHY interface support
+ depends on USB || USB_GADGET
+ select GENERIC_PHY
+ help
+ Say yes if you have ULPI PHY attached to your USB controller. If no
+ vendor modules are selected, the driver will act as NOP PHY driver.
+
+ If unsure, say Y.
+
diff --git a/drivers/phy/ulpi/Makefile b/drivers/phy/ulpi/Makefile
new file mode 100644
index 000..7ed0895
--- /dev/null
+++ b/drivers/phy/ulpi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ULPI_PHY) += ulpi.o
diff --git a/drivers/phy/ulpi/ulpi.c b/drivers/phy/ulpi/ulpi.c
new file mode 100644
index 000..7aa2f5d
--- /dev/null
+++ b/drivers/phy/ulpi/ulpi.c
@@ -0,0 +1,273 @@
+/**
+ * ulpi.c - USB ULPI PHY abstraction module
+ *
+ * Copyright (C) 2013 Intel Corporation
+ *
+ * Author: Heikki Krogerus heikki.kroge...@linux.intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/phy/ulpi.h
+#include linux/phy/phy.h
+#include linux/module.h
+#include linux/slab.h
+
+/*
--
*/
+
+static struct phy_consumer phy_consumer[] = {
+ { .port = ULPI_PORT_NAME, },
We had to introduce the entire phy_consumer stuff to support legacy pdata. Not
sure if it is a good idea to use it here.
Well, maybe we can improve it at least a bit. I don't see how it's
possible to get rid of the device name matching, but at least the port
name dependency could be replaced with possibility to use index
instead. Check how they made the gpiod lookup to work in gpiolib.
Let's get back to this one.
+};
+
+static struct phy_init_data phy_data = {
+ .num_consumers = 1,
+ .consumers = phy_consumer,
+};
+
+static int ulpi_power_on(struct phy *phy)
+{
+ struct ulpi_dev *ulpi = phy_get_drvdata(phy);
+ struct ulpi_driver *drv = to_ulpi_driver(ulpi-dev.driver);
+
+ if (drv drv-phy_ops drv-phy_ops-power_on)
+ return drv-phy_ops-power_on(phy);
+
+ return 0;
+}
+
+static int ulpi_power_off(struct phy *phy)
+{
+ struct ulpi_dev *ulpi = phy_get_drvdata(phy);
+ struct ulpi_driver *drv = to_ulpi_driver(ulpi-dev.driver);
+
+ if (drv drv-phy_ops drv-phy_ops-power_off)
+ return drv-phy_ops-power_off(phy);
+
+ return 0;
+}
+
+static struct phy_ops phy_ops = {
+ .owner = THIS_MODULE,
+ .power_on = ulpi_power_on,
+ .power_off
Re: [RFC PATH 2/3] usb: dwc3: add ULPI interface support
Hi,
On Mon, Dec 02, 2013 at 04:24:31PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Thursday 28 November 2013 09:29 PM, Heikki Krogerus wrote:
snip
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index dd17601..8bb82bc 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -13,6 +13,10 @@ ifneq ($(filter y,$(CONFIG_USB_DWC3_GADGET)
$(CONFIG_USB_DWC3_DUAL_ROLE)),)
dwc3-y += gadget.o ep0.o
endif
+ifneq ($(CONFIG_USB_DWC3_ULPI),)
+ dwc3-y += ulpi.o
+endif
+
ifneq ($(CONFIG_DEBUG_FS),)
dwc3-y += debugfs.o
endif
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 1c0a69a..94927b2 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -505,6 +505,12 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-regs_size = resource_size(res);
dwc-dev= dev;
+ if (!dwc-usb2_generic_phy) {
+ ret = dwc3_ulpi_init(dwc);
shouldn't this be called from dwc3-pci (or any other dwc3 glue)?
It's not going to be possible to put it to the dwc3-pci, but my
motivation for that is actually up and coming ACPI support. I do not
want to create glue driver for it just because this. With ACPI DSDT
there is no guarantee to get device entries for PHYs I'm afraid. You
will have them on some platforms, but on others you don't :(.
The issue with PCI is the device name, which is used when matching the
phy. We don't know it before the device is registered. We can't live
with the assumption there is only one instance in case of PCI. The
damn thing can be hotpluged from some weird dock, like exchangeable
back cover or something similar. So you will be able to register the
phy only after the core.c has probed, and requested the phys, which is
too late.
And besides. The glue drivers should only have platform specific code.
This is definitely platform agnostic feature of the controller.
+ if (ret)
+ return ret;
+ }
+
dev-dma_mask = dev-parent-dma_mask;
dev-dma_parms = dev-parent-dma_parms;
dma_set_coherent_mask(dev, dev-parent-coherent_dma_mask);
snip
+{
+ int ret;
+
+ /* First check if there is ULPI PHY */
+ ret = dwc3_readl(dwc-regs, DWC3_GHWPARAMS3);
+ if (!(ret DWC3_ULPI_HSPHY))
+ return 0;
+
+ /* Register the interface */
+ dwc-ulpi = ulpi_new_interface(dwc-dev,
+ dwc3_ulpi_read, dwc3_ulpi_write, dwc);
+ if (IS_ERR(dwc-ulpi)) {
+ dev_err(dwc-dev, failed to register ULPI interface);
+ return PTR_ERR(dwc-ulpi);
+ }
+
+ /* Get the ULPI phy instance
+* REVISIT: There should be no need to get it separately here.
+*/
+ dwc-usb2_generic_phy = devm_phy_get(dwc-dev, ULPI_PORT_NAME);
You shouldn't be needing this. It should get the phy from dwc3 core probe
itself.
You don't need this here. I made it like this now just because we
don't yet have your final version of the patches where you introduce
the generic phy support in dwc3.
I want to change the core.c so it set's the dwc-dev and maps the
iomem before requesting the phys. And of course put dwc3_ulpi_init in
between.
Thanks,
--
heikki
--
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: [RFC PATH 0/3] USB PHYs and PCI
Hi, On Mon, Dec 02, 2013 at 04:33:26PM +0530, Kishon Vijay Abraham I wrote: Hi, On Thursday 28 November 2013 09:29 PM, Heikki Krogerus wrote: Hi guys, PCI does not give any information about the PHY but we still need to be able to take advantage of any possible vendor specific features, such as custom PM operations, charger detection, ADP probing and sensing, etc. the PHY provides. Since ULPI provides a way to do runtime detection, I'm introducing this layer on top of Kishon's generic phy framework. It gives us means to detect the ULPI product and bind it to a driver without need for nasty platform/device specific quirks in case of ULPI PHYs. nice :-) Clearly there's a shortcoming in the current PHY framework to discover PHY's behind a pci. Thanks for attempting to solve it. But I think it needs a few modification like the ULPI device should be created by the glue (dwc3-pci?) and phy create should be done in phy driver. We should think of a better way for the controller to find the PHY (lets try and not use PHY CONSUMER or device name). Man I don't see any way to avoid the device name matching. We should drop the init_data thing so the phy drivers don't need to know about their users even when using platform data. You should have separate phy_lookup_add() function for that which, the platform code can call. I would also add support for matching based on index on top of the port name. I think it's fare to assume index 0 is always usb2 type. We could then have phy_get_index() and wrapper like gpiod_get() (phy_get) that tries to get the phy with index 0, that the usb2 controllers can use. Those two changes would make it look exactly like clk framework and gpiolib are now. The small benefit with those changes is that the phy drivers and the users, both don't need to know about each other in any case (DT, platform). So the device name matching would still be there. Though I'm not sure if it's such a huge problem to have it. At least the drivers don't need to care about it. If you like this idea, I can prepare the patches. Br, -- heikki -- 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 3/3] usb: phy-generic: Add ULPI VBUS support
On Mon, Dec 02, 2013 at 03:05:19PM +0800, Chris Ruehl wrote:
@@ -154,6 +164,27 @@ int usb_phy_gen_create_phy(struct device *dev, struct
usb_phy_gen_xceiv *nop,
{
int err;
+ if (nop-ulpi_vbus 0) {
+ unsigned int flags = 0;
+
+ if (nop-ulpi_vbus 0x1)
+ flags |= ULPI_OTG_DRVVBUS;
+ if (nop-ulpi_vbus 0x2)
+ flags |= ULPI_OTG_DRVVBUS_EXT;
+ if (nop-ulpi_vbus 0x4)
+ flags |= ULPI_OTG_EXTVBUSIND;
+ if (nop-ulpi_vbus 0x8)
+ flags |= ULPI_OTG_CHRGVBUS;
+
+ nop-ulpi = otg_ulpi_create(ulpi_viewport_access_ops, flags);
+ if (!nop-ulpi) {
+ dev_err(dev, Failed create ULPI Phy\n);
+ return -ENOMEM;
+ }
+ dev_dbg(dev, Create ULPI Phy\n);
+ nop-ulpi-io_priv = nop-viewport;
+ }
This is so wrong. You are registering one kind of usb phy driver from
an other. Change drivers/usb/phy/ulpi.c to be a platform device. The
whole flag system in it is pretty horrid. While you are at it, change
that so it sets the values based on boolean flags from OF properties
or platform data.
NAK for the whole set.
--
heikki
--
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 v2 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY's
Hi, On Thu, Oct 17, 2013 at 09:54:26AM -0500, Felipe Balbi wrote: On Wed, Oct 16, 2013 at 04:27:26PM +0300, Roger Quadros wrote: On 10/16/2013 04:10 PM, Kishon Vijay Abraham I wrote: Do you know if there are users of dwc3 other than exynos5250 and omap5? If not, we should get rid of the old USB PHY altogether. Intel's Baytrail, at least. But they don't use DT. I don't see any use for the generic-phy when the device is enumerated from PCI. If dwc3 can live without phys, there should not be any problem dropping the old USB PHY support. Br, -- heikki -- 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 v2 2/7] usb: dwc3: adapt dwc3 core to use Generic PHY Framework
Hi Kishon,
On Wed, Oct 16, 2013 at 01:24:12AM +0530, Kishon Vijay Abraham I wrote:
+ count = of_property_match_string(node, phy-names, usb2-phy);
+ if (count = 0 || (pdata pdata-usb2_generic_phy)) {
+ dwc-usb2_generic_phy = devm_phy_get(dev, usb2-phy);
+ if (IS_ERR(dwc-usb2_generic_phy)) {
+ dev_err(dev, no usb2 phy configured yet);
+ return PTR_ERR(dwc-usb2_generic_phy);
+ }
+ dwc-usb2_phy = NULL;
+ }
+
+ count = of_property_match_string(node, phy-names, usb3-phy);
+ if (count = 0 || (pdata pdata-usb3_generic_phy)) {
+ dwc-usb3_generic_phy = devm_phy_get(dev, usb3-phy);
+ if (IS_ERR(dwc-usb3_generic_phy)) {
+ dev_err(dev, no usb3 phy configured yet);
+ return PTR_ERR(dwc-usb3_generic_phy);
+ }
+ dwc-usb3_phy = NULL;
+ }
Is there some specific reason for these checks? The driver should not
need to care about the platform (DT, ACPI, platform based).
Just get the phys and check the return value. In case ERR_PTR(-ENODEV)
leave the phy as NULL and let the driver continue normally. With other
errors you make the dwc3 probe fail.
Thanks,
--
heikki
--
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 3/3] usb: phy-generic: Add ULPI VBUS support
Hi Chris,
On Wed, Dec 04, 2013 at 03:16:21PM +0800, Chris Ruehl wrote:
On Tuesday, December 03, 2013 04:15 PM, Heikki Krogerus wrote:
On Mon, Dec 02, 2013 at 03:05:19PM +0800, Chris Ruehl wrote:
@@ -154,6 +164,27 @@ int usb_phy_gen_create_phy(struct device *dev, struct
usb_phy_gen_xceiv *nop,
{
int err;
+ if (nop-ulpi_vbus 0) {
+ unsigned int flags = 0;
+
+ if (nop-ulpi_vbus 0x1)
+ flags |= ULPI_OTG_DRVVBUS;
+ if (nop-ulpi_vbus 0x2)
+ flags |= ULPI_OTG_DRVVBUS_EXT;
+ if (nop-ulpi_vbus 0x4)
+ flags |= ULPI_OTG_EXTVBUSIND;
+ if (nop-ulpi_vbus 0x8)
+ flags |= ULPI_OTG_CHRGVBUS;
+
+ nop-ulpi = otg_ulpi_create(ulpi_viewport_access_ops, flags);
+ if (!nop-ulpi) {
+ dev_err(dev, Failed create ULPI Phy\n);
+ return -ENOMEM;
+ }
+ dev_dbg(dev, Create ULPI Phy\n);
+ nop-ulpi-io_priv = nop-viewport;
+ }
This is so wrong. You are registering one kind of usb phy driver from
an other. Change drivers/usb/phy/ulpi.c to be a platform device. The
whole flag system in it is pretty horrid. While you are at it, change
that so it sets the values based on boolean flags from OF properties
or platform data.
NAK for the whole set.
Heikki,
Thanks for your comments, even not much positive to me.. any how.
My intention on the horrid path was to reduce kernel code where
one of_read32 vs. four of_boolean. And mentioned logic is simple.
But that's history.
I should probable explain why I have problems with them. First of all,
things like driving the vbus should be a function that can be called
from upper layers. struct usb_otg has the set_vbus hook for that. You
can call it for example from your host controller's init routine. I'm
assuming you have a host controller since you are driving vbus.
You don't need to set the ULPI_OTG_CHRGVBUS. It's used for the VBUS
pulsing of SRP, which btw. is not anymore supported in OTGEH2.0 spec,
so just don't use that bit even if you want to start SRP.
The only of_booleans you should need are for the DRV_VBUS_EXT and
USE_EXT_VBUS_IND. In my case I could not use even those. My controller
provides it's own control for them, so even if I set them to my ULPI
phy, the controller would simply override the values.
Secondly, why those silly flags in the first place. Those flags are
just bits in the registers. It would have been much easier and cleaner
to deliver a small struct with default values for the registers
instead.
On my way to find a solution for my board I'd look around and found using of
phy-ulpi.c functions in phy-tegra-usb.c and don't mind to use them too.
OK, IC. I have not followed what is happening with USB in linux for a
while.
The whole otg_ulpi_create() thing, and the flags with it, were
originally planned to be used from platform code. It's evil and it
should have never been accepted into upstream kernel. The time it was
introduced I was on vacation and nobody else seemed to care :(. All I
was able to do was to protest afterwards.
I accept your NAK and will work on a patch to make phy-ulpi.c
working as platform device.
Last question to you. What you don't like on the patch to support
chip-select gpio of my patch-set.. I ask because you NAK the whole
set.
I really need the ChipSelect function to make my hardware work!
OK, I did not explain my problem with that patch. I'm sorry about
that. It also looks like I made wrong assumption with it. I thought
that your phy (is was ISP1504 right) is just like isp1704 that I have
worked with. On isp1704 you only have the chip_sel pin (no reset pin),
so I thought you can not have any reason to add handler for an other
gpio to this driver. After a quick look at isp1504 data sheet, it
looks like you have both reset and chip_sel pins on it, which I guess
are both connected to gpios on your platform.
So I don't have a problem with that. Though I'm not sure is this
driver the right place to handle things like these gpios, which are
pretty phy specific, in the first place. The phy-generic was
originally meant to be pure NOP phy driver.
One comment about how to handle the gpios. You should move to the new
gpio descriptor API. The legacy gpio API is now just a wrapper on top
of it.
Chris
Thanks,
--
heikki
--
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 04/10] usb: dwc3: use quirks to know if a particualr platform doesn't have PHY
Hi guys, Kishon, sorry I did not see this v3 set. On Mon, Nov 25, 2013 at 03:31:24PM +0530, Kishon Vijay Abraham I wrote: There can be systems which does not have an external phy, so get phy only if no quirks are added that indicates the PHY is not present. Introduced two quirk flags to indicate the *absence* of usb2 phy and usb3 phy. Also remove checking if return value is -ENXIO since it's now changed to always enable usb_phy layer. Can you guys explain why is something like this needed? Like with clocks and gpios, the device drivers shouldn't need to care any more if the platform has the phys or not. -ENODEV tells you your platform does not have them, so go ahead and continue when getting the phy. I just tested removing the phy registering from dwc3-pci.c and all I had to do was to add IS_ERR(phy) checks where the old usb phys were used and everything worked fine? What am I missing? Br, -- heikki -- 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 04/10] usb: dwc3: use quirks to know if a particualr platform doesn't have PHY
Hi, On Thu, Dec 05, 2013 at 12:04:46PM +0530, Kishon Vijay Abraham I wrote: On Wednesday 04 December 2013 08:10 PM, Heikki Krogerus wrote: On Mon, Nov 25, 2013 at 03:31:24PM +0530, Kishon Vijay Abraham I wrote: There can be systems which does not have an external phy, so get phy only if no quirks are added that indicates the PHY is not present. Introduced two quirk flags to indicate the *absence* of usb2 phy and usb3 phy. Also remove checking if return value is -ENXIO since it's now changed to always enable usb_phy layer. Can you guys explain why is something like this needed? Like with clocks and gpios, the device drivers shouldn't need to care any more if the platform has the phys or not. -ENODEV tells you your platform Shouldn't we report if a particular platform needs a PHY and not able to get it. How will a user know if a particular controller is not working because it's not able to get and initialize the PHYs? Don't you think in such cases it's better to fail (and return from probe) because the controller will not work anyway without the PHY? My point is that you do not need to separately tell this to the driver like you do with the quirks (if you did, then you would need to fix your framework and not hack the drivers). Like I said, ENODEV tells you that there is no phy on this platform for you, allowing you to safely continue. If your phy driver is not loaded, the framework already returns EPROBE_DEFER, right. Any other error when getting the phy you can consider critical. They are the errors telling you that you do need a phy on this platform, but something actually went wrong when getting it. Those quirks should always be avoided, and I don't see any use for them here. Thanks Kishon Thanks, -- heikki -- 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 v2 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY's
Hi, On Fri, Dec 06, 2013 at 02:15:30PM -0600, Felipe Balbi wrote: On Tue, Dec 03, 2013 at 12:39:50PM +0200, Heikki Krogerus wrote: On Thu, Oct 17, 2013 at 09:54:26AM -0500, Felipe Balbi wrote: On Wed, Oct 16, 2013 at 04:27:26PM +0300, Roger Quadros wrote: On 10/16/2013 04:10 PM, Kishon Vijay Abraham I wrote: Do you know if there are users of dwc3 other than exynos5250 and omap5? If not, we should get rid of the old USB PHY altogether. Intel's Baytrail, at least. But they don't use DT. I don't see any use for the generic-phy when the device is enumerated from PCI. If dwc3 can live without phys, there should not be any problem dropping the old USB PHY support. yeah, I don't want to drop PHY support, I want to require everybody to provide a PHY, otherwise we have too many options to handle and that's never clean. I have to clarify in case there was a misunderstanding. When I said generic-phy I meant drivers/usb/phy/phy-generic.c and I was not talking about Kishon's new generic PHY framework. So I was only saying that if the dwc3-pci.c is the only thing that needs the old usb phy support, then there should not be any problem dropping the support for it. Thanks, -- heikki -- 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 04/10] usb: dwc3: use quirks to know if a particualr platform doesn't have PHY
Hi, On Mon, Dec 09, 2013 at 12:43:37PM +0530, Kishon Vijay Abraham I wrote: On Thursday 05 December 2013 01:28 PM, Heikki Krogerus wrote: On Thu, Dec 05, 2013 at 12:04:46PM +0530, Kishon Vijay Abraham I wrote: On Wednesday 04 December 2013 08:10 PM, Heikki Krogerus wrote: On Mon, Nov 25, 2013 at 03:31:24PM +0530, Kishon Vijay Abraham I wrote: There can be systems which does not have an external phy, so get phy only if no quirks are added that indicates the PHY is not present. Introduced two quirk flags to indicate the *absence* of usb2 phy and usb3 phy. Also remove checking if return value is -ENXIO since it's now changed to always enable usb_phy layer. Can you guys explain why is something like this needed? Like with clocks and gpios, the device drivers shouldn't need to care any more if the platform has the phys or not. -ENODEV tells you your platform Shouldn't we report if a particular platform needs a PHY and not able to get it. How will a user know if a particular controller is not working because it's not able to get and initialize the PHYs? Don't you think in such cases it's better to fail (and return from probe) because the controller will not work anyway without the PHY? My point is that you do not need to separately tell this to the driver like you do with the quirks (if you did, then you would need to fix your framework and not hack the drivers). Like I said, ENODEV tells you that there is no phy on this platform for you, allowing you to safely continue. If your phy driver is not loaded, the framework already returns EPROBE_DEFER, right. Any other right. but that doesn't consider broken dt data. With quirks we'll able to tell if a controller in a particular platform has PHY or not without depending on the dt data. Broken dt data? What kind of scenario are you thinking here? Do you mean case where the dt does not describe the phy on a platform that depends on it? Shouldn't that problem be fixed in the dt and not hacked in the drivers? Or are you thinking about something else? Is there a case where something like that is actually happening? Br, -- heikki -- 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 RFC 3/4] xhci: Tune PHY for the DWC3-Exynos host controller
Hi,
On Tue, Dec 10, 2013 at 04:25:25PM +0530, Vivek Gautam wrote:
@@ -170,6 +189,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
}
/*
+ * The parent of the xhci-plat device may pass in a PHY via
+ * platform data. If it exists, store it in our struct usb_hcd
+ * so that we can use it later.
+ */
+ phy_generic = dev_get_platdata(pdev-dev);
+ if (phy_generic)
+ xhci-shared_hcd-phy_generic = *phy_generic;
Getting the handle to the phy from platform data like this is not
going to work for long. It should be possible to get it normally with
phy_get(). It's not going to be possible to get the handle from the
platform data like this if the xhci-hcd platform device is created
from ACPI or DT. You are also not considering case where you have two
phys.
Vivek, I have made a patch set for the phy framework allowing
associations between the phys and their users to be made in same way
gpios and clk make them. With those you should be able to create a
lookup entry to the phy framework in drivers/usb/dwc3/host.c. Then we
could use phy_get() here already. Please check them. Subject of the
thread:
phy: remove the need for the phys to know about their users
The lookup table can then be added in drivers/usb/dwc3/host.c with
something like this:
int dwc3_host_init(struct dwc3 *dwc)
{
struct platform_device *xhci;
struct phy_lookup_table *table;
...
table-dev_id = dev_name(xhci-dev);
if (dwc-usb2_generic_phy)
table-table[0].phy_name =
dev_name(dwc-usb2_generic_phy-dev);
if (dwc-usb3_generic_phy)
table-table[1].phy_name =
dev_name(dwc-usb3_generic_phy-dev);
phy_add_lookup_table(table);
...
Br,
--
heikki
--
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 RFC 1/4] phy: Add provision for tuning phy.
Hi,
On Tue, Dec 10, 2013 at 04:25:23PM +0530, Vivek Gautam wrote:
Some PHY controllers may need to tune PHY post-initialization,
so that the PHY consumers can call phy-tuning at appropriate
point of time.
Signed-off-by: vivek Gautam gautam.vi...@samsung.com
---
drivers/phy/phy-core.c | 20
include/linux/phy/phy.h |7 +++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 03cf8fb..68dbb90 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -239,6 +239,26 @@ out:
}
EXPORT_SYMBOL_GPL(phy_power_off);
+int phy_tune(struct phy *phy)
+{
+ int ret = -ENOTSUPP;
+
+ mutex_lock(phy-mutex);
+ if (phy-ops-tune) {
+ ret = phy-ops-tune(phy);
+ if (ret 0) {
+ dev_err(phy-dev, phy tuning failed -- %d\n, ret);
+ goto out;
+ }
+ }
+
+out:
+ mutex_unlock(phy-mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_tune);
I think setup instead of tune is much more clear and reusable.
Thanks,
--
heikki
--
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 RFC 1/4] phy: Add provision for tuning phy.
Hi, On Wed, Dec 11, 2013 at 12:08:04PM +0530, Vivek Gautam wrote: On Tue, Dec 10, 2013 at 7:31 PM, Heikki Krogerus I think setup instead of tune is much more clear and reusable. I think setup will look more like first time setting up the phy, which is rather served by init callback. This i thought would serve the purpose of over-riding certain PHY parameters, which would not have been possible at init time. Please correct my thinking if i am unable to understand your point here. OK, sorry I was not clear on this. I'm thinking the same, that this is something that is called later, for example when the controller is ready. Some ULPI phys need to be initialized, but since the controller provides the interface, it's usually not possible during init time. This hook could be used in that case as well. All I'm saying is that tune is a poor expression. You will need to add a comment explaining what the hook does in any case, so you'll have something like this is something that is called when the controller is ready or something similar. That will make it clear what it's meant for. Thanks, -- heikki -- 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 04/10] usb: dwc3: use quirks to know if a particualr platform doesn't have PHY
Hi, On Mon, Dec 09, 2013 at 11:26:04AM +0200, Heikki Krogerus wrote: Can you guys explain why is something like this needed? Like with clocks and gpios, the device drivers shouldn't need to care any more if the platform has the phys or not. -ENODEV tells you your platform Shouldn't we report if a particular platform needs a PHY and not able to get it. How will a user know if a particular controller is not working because it's not able to get and initialize the PHYs? Don't you think in such cases it's better to fail (and return from probe) because the controller will not work anyway without the PHY? My point is that you do not need to separately tell this to the driver like you do with the quirks (if you did, then you would need to fix your framework and not hack the drivers). Like I said, ENODEV tells you that there is no phy on this platform for you, allowing you to safely continue. If your phy driver is not loaded, the framework already returns EPROBE_DEFER, right. Any other right. but that doesn't consider broken dt data. With quirks we'll able to tell if a controller in a particular platform has PHY or not without depending on the dt data. Broken dt data? What kind of scenario are you thinking here? Do you mean case where the dt does not describe the phy on a platform that depends on it? Shouldn't that problem be fixed in the dt and not hacked in the drivers? Or are you thinking about something else? Is there a case where something like that is actually happening? I'm guessing I'm not getting an answer to this one. Look, this patch will not work with ACPI enumerated devices. We will have a platform providing a single ACPI id, but there is a whole bunch of boards based on it and we have no way of telling which of them need/have phys to deal with and which ones don't. Thanks, -- heikki -- 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
[RESEND PATCH] usb: dwc3: fix the glue drivers using the nop phy
The reset_gpio member of the usb_phy_gen_xceiv_platform_data structure needs the have negative value or phy-generic's probe will fail unless DT is used. 0 is a valid gpio number. This fixes an issue where phy-generic fails to probe with message: usb_phy_gen_xceiv.0: Error requesting RESET GPIO 0. Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com --- drivers/usb/dwc3/dwc3-exynos.c | 1 + drivers/usb/dwc3/dwc3-pci.c| 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c index 8b20c70..28c8ad7 100644 --- a/drivers/usb/dwc3/dwc3-exynos.c +++ b/drivers/usb/dwc3/dwc3-exynos.c @@ -50,6 +50,7 @@ static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos) exynos-usb2_phy = pdev; pdata.type = USB_PHY_TYPE_USB2; + pdata.gpio_reset = -1; ret = platform_device_add_data(exynos-usb2_phy, pdata, sizeof(pdata)); if (ret) diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index 665686e..f393c18 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -52,6 +52,7 @@ static int dwc3_pci_register_phys(struct dwc3_pci *glue) glue-usb2_phy = pdev; pdata.type = USB_PHY_TYPE_USB2; + pdata.gpio_reset = -1; ret = platform_device_add_data(glue-usb2_phy, pdata, sizeof(pdata)); if (ret) -- 1.8.5.1 -- 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: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
Hi Felipe, On Tue, Jan 21, 2014 at 08:47:25AM -0600, Felipe Balbi wrote: On Tue, Jan 21, 2014 at 03:41:38PM +0530, Kishon Vijay Abraham I wrote: Since PHYs for dwc3 is optional (not all SoCs that have DWC3 use PHYs), do not return from probe if the USB PHY library returns -ENODEV as that this isn't correct, they all have PHYs, some of them might not be controllable. indicates the platform does not have PHY. not really, that indicates the current platform tried to grab a PHY and the PHY doesn't exist. If there's anybody with a non-controllable PHY and someone gives me a really good reason for not using the generic no-op PHY, then we should add a flag and we could: if (!likely(dwc-flags DWC3_USB2PHY_DRIVER_NOT_NEEDED)) dwc3_grab_phys(dwc); Why would you need to know if the PHY drivers are needed or not explicitly in your controller driver? But I really want to see the argument against using no-op. As far as I could see, everybody needs a PHY driver one way or another, some platforms just haven't sent any PHY driver upstream and have their own hacked up solution to avoid using the PHY layer. Not true in our case. Platforms using Intel's SoCs and chip sets may or may not have controllable USB PHY. Quite often they don't. The Baytrails have usually ULPI PHY for USB2, but that does not mean they provide any vendor specific functions or any need for a driver in any case. Are we talking about the old USB PHY library or the new PHY framework with the no-op PHY driver? Well, in any case, I don't understand what is the purpose of the no-op PHY driver. What are you drying to achieve with that? Thanks, -- heikki -- 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: [PATCHv2 5/6] base: platform: name the device already during allocation
On Mon, Jul 14, 2014 at 07:55:43AM -0700, Greg Kroah-Hartman wrote:
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 9e9227e..e856bc4 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -177,11 +177,45 @@ struct platform_object {
*/
void platform_device_put(struct platform_device *pdev)
{
- if (pdev)
- put_device(pdev-dev);
+ if (!pdev)
+ return;
+
+ if (pdev-id_auto) {
+ ida_simple_remove(platform_devid_ida, pdev-id);
+ pdev-id = PLATFORM_DEVID_AUTO;
+ }
+
+ put_device(pdev-dev);
}
EXPORT_SYMBOL_GPL(platform_device_put);
Why would a single call to this function remove an id? That seems
really wrong, you should be able to call get and put on a device
numerous times, only the last reference should cause the device to be
cleaned up.
Shouldn't this be in the release function instead?
I'll fix this.
Thanks Greg.
--
heikki
--
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
[PATCH 4/6] phy: remove the old lookup method
The users of the old method are now converted to the new one.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/phy/phy-bcm-kona-usb2.c | 2 +-
drivers/phy/phy-core.c | 45 +++--
drivers/phy/phy-exynos-dp-video.c | 2 +-
drivers/phy/phy-exynos-mipi-video.c | 2 +-
drivers/phy/phy-exynos5-usbdrd.c| 3 +--
drivers/phy/phy-exynos5250-sata.c | 2 +-
drivers/phy/phy-mvebu-sata.c| 2 +-
drivers/phy/phy-omap-usb2.c | 2 +-
drivers/phy/phy-samsung-usb2.c | 3 +--
drivers/phy/phy-sun4i-usb.c | 2 +-
drivers/phy/phy-ti-pipe3.c | 2 +-
drivers/phy/phy-twl4030-usb.c | 4 +---
drivers/phy/phy-xgene.c | 2 +-
include/linux/phy/phy.h | 38 ---
14 files changed, 19 insertions(+), 92 deletions(-)
diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
index 894fe74..3463983 100644
--- a/drivers/phy/phy-bcm-kona-usb2.c
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -117,7 +117,7 @@ static int bcm_kona_usb2_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, phy);
- gphy = devm_phy_create(dev, NULL, ops, NULL);
+ gphy = devm_phy_create(dev, NULL, ops);
if (IS_ERR(gphy))
return PTR_ERR(gphy);
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 67a8c726..834b337 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -55,36 +55,6 @@ static int devm_phy_match(struct device *dev, void *res,
void *match_data)
return res == match_data;
}
-static struct phy *phy_lookup(struct device *device, const char *port)
-{
- unsigned int count;
- struct phy *phy;
- struct device *dev;
- struct phy_consumer *consumers;
- struct class_dev_iter iter;
-
- class_dev_iter_init(iter, phy_class, NULL, NULL);
- while ((dev = class_dev_iter_next(iter))) {
- phy = to_phy(dev);
-
- if (!phy-init_data)
- continue;
- count = phy-init_data-num_consumers;
- consumers = phy-init_data-consumers;
- while (count--) {
- if (!strcmp(consumers-dev_name, dev_name(device))
- !strcmp(consumers-port, port)) {
- class_dev_iter_exit(iter);
- return phy;
- }
- consumers++;
- }
- }
-
- class_dev_iter_exit(iter);
- return ERR_PTR(-ENODEV);
-}
-
/**
* phy_register_lookup() - register PHY/device association
* @pl: association to register
@@ -210,10 +180,6 @@ static struct phy *phy_find(struct device *dev, const char
*con_id)
}
class_dev_iter_exit(iter);
}
-
- /* fall-back to the old lookup method for now */
- if (IS_ERR(phy))
- phy = phy_lookup(dev, con_id);
return phy;
}
@@ -721,13 +687,11 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
* @dev: device that is creating the new phy
* @node: device node of the phy
* @ops: function pointers for performing phy operations
- * @init_data: contains the list of PHY consumers or NULL
*
* Called to create a phy using phy framework.
*/
struct phy *phy_create(struct device *dev, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data)
+ const struct phy_ops *ops)
{
int ret;
int id;
@@ -765,7 +729,6 @@ struct phy *phy_create(struct device *dev, struct
device_node *node,
phy-dev.of_node = node ?: dev-of_node;
phy-id = id;
phy-ops = ops;
- phy-init_data = init_data;
ret = dev_set_name(phy-dev, phy-%s.%d, dev_name(dev), id);
if (ret)
@@ -800,7 +763,6 @@ EXPORT_SYMBOL_GPL(phy_create);
* @dev: device that is creating the new phy
* @node: device node of the phy
* @ops: function pointers for performing phy operations
- * @init_data: contains the list of PHY consumers or NULL
*
* Creates a new PHY device adding it to the PHY class.
* While at that, it also associates the device with the phy using devres.
@@ -808,8 +770,7 @@ EXPORT_SYMBOL_GPL(phy_create);
* then, devres data is freed.
*/
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data)
+ const struct phy_ops *ops)
{
struct phy **ptr, *phy;
@@ -817,7 +778,7 @@ struct phy *devm_phy_create(struct device *dev, struct
device_node *node,
if (!ptr)
return ERR_PTR(-ENOMEM);
- phy = phy_create(dev, node, ops, init_data);
+ phy = phy_create(dev, node, ops
[PATCH 5/6] base: platform: name the device already during allocation
The device name is needed when assigning resources like
clocks or GPIOs to devices using lookups. If
PLATFORM_DEVICE_AUTO is used, the device name is not know
before platform_device_add is called after which it's too
late to assign that kind of resources as the drivers most
likely have already requested them.
By naming the device already in platform_device_alloc, the
resources can be assigned before platform_device_add is
called.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/base/platform.c | 69 +
1 file changed, 41 insertions(+), 28 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index ab4f4ce..d3a7022 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -194,11 +194,41 @@ void platform_device_put(struct platform_device *pdev)
}
EXPORT_SYMBOL_GPL(platform_device_put);
+static int pdev_set_name(struct platform_device *pdev)
+{
+ int ret;
+
+ switch (pdev-id) {
+ default:
+ return dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
+ case PLATFORM_DEVID_NONE:
+ return dev_set_name(pdev-dev, %s, pdev-name);
+ case PLATFORM_DEVID_AUTO:
+ /*
+* Automatically allocated device ID. We mark it as such so
+* that we remember it must be freed, and we append a suffix
+* to avoid namespace collision with explicit IDs.
+*/
+ ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
+ if (ret 0)
+ return ret;
+ pdev-id = ret;
+ pdev-id_auto = true;
+ return dev_set_name(pdev-dev, %s.%d.auto, pdev-name,
+ pdev-id);
+ }
+
+ return 0;
+}
+
static void platform_device_release(struct device *dev)
{
struct platform_object *pa = container_of(dev, struct platform_object,
pdev.dev);
+ if (pa-pdev.id_auto)
+ ida_simple_remove(platform_devid_ida, pa-pdev.id);
+
of_device_node_put(pa-pdev.dev);
kfree(pa-pdev.dev.platform_data);
kfree(pa-pdev.mfd_cell);
@@ -227,6 +257,10 @@ struct platform_device *platform_device_alloc(const char
*name, int id)
device_initialize(pa-pdev.dev);
pa-pdev.dev.release = platform_device_release;
arch_setup_pdev_archdata(pa-pdev);
+ if (pdev_set_name(pa-pdev)) {
+ kfree(pa);
+ return NULL;
+ }
}
return pa ? pa-pdev : NULL;
@@ -307,28 +341,6 @@ int platform_device_add(struct platform_device *pdev)
pdev-dev.bus = platform_bus_type;
- switch (pdev-id) {
- default:
- dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
- break;
- case PLATFORM_DEVID_NONE:
- dev_set_name(pdev-dev, %s, pdev-name);
- break;
- case PLATFORM_DEVID_AUTO:
- /*
-* Automatically allocated device ID. We mark it as such so
-* that we remember it must be freed, and we append a suffix
-* to avoid namespace collision with explicit IDs.
-*/
- ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
- if (ret 0)
- goto err_out;
- pdev-id = ret;
- pdev-id_auto = true;
- dev_set_name(pdev-dev, %s.%d.auto, pdev-name, pdev-id);
- break;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *p, *r = pdev-resource[i];
@@ -371,7 +383,6 @@ int platform_device_add(struct platform_device *pdev)
release_resource(r);
}
- err_out:
return ret;
}
EXPORT_SYMBOL_GPL(platform_device_add);
@@ -391,11 +402,6 @@ void platform_device_del(struct platform_device *pdev)
if (pdev) {
device_del(pdev-dev);
- if (pdev-id_auto) {
- ida_simple_remove(platform_devid_ida, pdev-id);
- pdev-id = PLATFORM_DEVID_AUTO;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *r = pdev-resource[i];
unsigned long type = resource_type(r);
@@ -413,8 +419,15 @@ EXPORT_SYMBOL_GPL(platform_device_del);
*/
int platform_device_register(struct platform_device *pdev)
{
+ int ret;
+
device_initialize(pdev-dev);
arch_setup_pdev_archdata(pdev);
+
+ ret = pdev_set_name(pdev);
+ if (ret)
+ return ret;
+
return platform_device_add(pdev);
}
EXPORT_SYMBOL_GPL(platform_device_register);
--
2.1.0
--
To unsubscribe from
[PATCH 2/6] phy: improved lookup method
Removes the need for the phys to be aware of their users
even when not using DT. The method is copied from clkdev.c.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
---
Documentation/phy.txt | 66 ---
drivers/phy/phy-core.c | 135 +++-
include/linux/phy/phy.h | 27 ++
3 files changed, 183 insertions(+), 45 deletions(-)
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
index c6594af..8add515 100644
--- a/Documentation/phy.txt
+++ b/Documentation/phy.txt
@@ -54,18 +54,14 @@ 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, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data);
+ const struct phy_ops *ops);
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data);
+ const struct phy_ops *ops);
The PHY drivers can use one of the above 2 APIs to create the PHY by passing
-the device pointer, phy ops and init_data.
+the device pointer and phy ops.
phy_ops is a set of function pointers for performing PHY operations such as
-init, exit, power_on and power_off. *init_data* is mandatory to get a reference
-to the PHY in the case of non-dt boot. See section *Board File Initialization*
-on how init_data should be used.
+init, exit, power_on and power_off.
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
@@ -137,42 +133,24 @@ 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. Board File Initialization
-
-Certain board file initialization is necessary in order to get a reference
-to the PHY in the case of non-dt boot.
-Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe,
-then in the board file the following initialization should be done.
-
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(dwc3.0, usb),
- PHY_CONSUMER(pcie.0, pcie),
- PHY_CONSUMER(sata.0, sata),
-};
-PHY_CONSUMER takes 2 parameters, first is the device name of the controller
-(PHY consumer) and second is the port name.
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
-};
-
-static const struct platform_device pipe3_phy_dev = {
- .name = pipe3-phy,
- .id = -1,
- .dev = {
- .platform_data = {
- .init_data = init_data,
- },
- },
-};
-
-then, while doing phy_create, the PHY driver should pass this init_data
- phy_create(dev, ops, pdata-init_data);
-
-and the controller driver (phy consumer) should pass the port name along with
-the device to get a reference to the PHY
- phy_get(dev, pcie);
+8. PHY Mappings
+
+In order to get reference to a PHY without help from DeviceTree, the framework
+offers lookups which can be compared to clkdev that allow clk structures to be
+bound to devices. A lookup can be made statically by directly registering
+phy_lookup structure which contains the name of the PHY device, the name of the
+device which the PHY will be bind to and Connection ID string. Alternatively a
+lookup can be made during runtime when a handle to the struct phy already
+exists.
+
+The framework offers the following APIs for registering and unregistering the
+lookups.
+
+void phy_register_lookup(struct phy_lookup *pl);
+int phy_create_lookup(struct phy *phy, const char *con_id, const char *dev_id);
+
+void phy_unregister_lookup(struct phy_lookup *pl);
+void phy_remove_lookup(struct phy *phy, const char *con_id, const char
*dev_id);
9. DeviceTree Binding
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index ff5eec5..67a8c726 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -26,6 +26,7 @@
static struct class *phy_class;
static DEFINE_MUTEX(phy_provider_mutex);
static LIST_HEAD(phy_provider_list);
+static LIST_HEAD(phys);
static DEFINE_IDA(phy_ida);
static void devm_phy_release(struct device *dev, void *res)
@@ -84,6 +85,138 @@ static struct phy *phy_lookup(struct device *device, const
char *port)
return ERR_PTR(-ENODEV);
}
+/**
+ * phy_register_lookup() - register PHY/device association
+ * @pl: association to register
+ */
+void phy_register_lookup(struct phy_lookup *pl)
+{
+ mutex_lock(phy_provider_mutex);
+ list_add_tail(pl-node, phys);
+ mutex_unlock(phy_provider_mutex
[PATCH 6/6] usb: dwc3: host: convey the PHYs to xhci
On some platforms a PHY may need to be handled also in the
host controller driver. Exynos5420 SoC requires some PHY
tuning based on the USB speed. This patch delivers dwc3's
PHYs to the xhci platform device when it's created.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/host.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index dcb8ca0..12bfd3c 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -29,8 +29,7 @@ int dwc3_host_init(struct dwc3 *dwc)
xhci = platform_device_alloc(xhci-hcd, PLATFORM_DEVID_AUTO);
if (!xhci) {
dev_err(dwc-dev, couldn't allocate xHCI device\n);
- ret = -ENOMEM;
- goto err0;
+ return -ENOMEM;
}
dma_set_coherent_mask(xhci-dev, dwc-dev-coherent_dma_mask);
@@ -60,22 +59,33 @@ int dwc3_host_init(struct dwc3 *dwc)
goto err1;
}
+ phy_create_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(xhci-dev));
+ phy_create_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(xhci-dev));
+
ret = platform_device_add(xhci);
if (ret) {
dev_err(dwc-dev, failed to register xHCI device\n);
- goto err1;
+ goto err2;
}
return 0;
-
+err2:
+ phy_remove_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(xhci-dev));
+ phy_remove_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(xhci-dev));
err1:
platform_device_put(xhci);
-
-err0:
return ret;
}
void dwc3_host_exit(struct dwc3 *dwc)
{
+ phy_remove_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(dwc-xhci-dev));
+ phy_remove_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(dwc-xhci-dev));
platform_device_unregister(dwc-xhci);
}
--
2.1.0
--
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
[PATCH 3/6] arm: omap3: twl: use the new lookup method with usb phy
Provide complete association for the phy and it's user
(musb) with the new phy lookup method.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
arch/arm/mach-omap2/twl-common.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index b0d54da..b78383c 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -91,18 +91,14 @@ void __init omap_pmic_late_init(void)
}
#if defined(CONFIG_ARCH_OMAP3)
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
-};
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
+static struct phy_lookup twl4030_usb_lookup = {
+ .phy_name = phy-twl4030_usb.0,
+ .dev_id = musb-hdrc.0,
+ .con_id = usb,
};
static struct twl4030_usb_data omap3_usb_pdata = {
- .usb_mode = T2_USB_MODE_ULPI,
- .init_data = init_data,
+ .usb_mode = T2_USB_MODE_ULPI,
};
static int omap3_batt_table[] = {
@@ -225,8 +221,10 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
}
/* Common platform data configurations */
- if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
+ if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb) {
+ phy_register_lookup(twl4030_usb_lookup);
pmic_data-usb = omap3_usb_pdata;
+ }
if (pdata_flags TWL_COMMON_PDATA_BCI !pmic_data-bci)
pmic_data-bci = omap3_bci_pdata;
--
2.1.0
--
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
[PATCH 1/6] phy: safer to_phy() macro
This makes to_phy() macro work with other variable names
besides dev.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
---
include/linux/phy/phy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 8cb6f81..9fda683 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -110,7 +110,7 @@ struct phy_init_data {
.port = _port,\
}
-#defineto_phy(dev) (container_of((dev), struct phy, dev))
+#defineto_phy(a) (container_of((a), struct phy, dev))
#defineof_phy_provider_register(dev, xlate)\
__of_phy_provider_register((dev), THIS_MODULE, (xlate))
--
2.1.0
--
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 4/6] phy: remove the old lookup method
On Mon, Aug 25, 2014 at 01:11:34PM +0530, Vivek Gautam wrote: Please squash the attached diff which removes the 'init_data' field from some of the other instances of devm_phy_create() in few other drivers. This should prevent any build errors that i could see with multi_v7_defconfig. OK, I'll add those changes into this patch, and it seems there is now at least one more new driver on top of those calling devm_phy_create. Thanks! -- heikki -- 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
[PATCHv4 4/6] phy: remove the old lookup method
The users of the old method are now converted to the new one.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/phy/phy-bcm-kona-usb2.c | 2 +-
drivers/phy/phy-berlin-sata.c| 2 +-
drivers/phy/phy-core.c | 45 +++-
drivers/phy/phy-exynos-dp-video.c| 2 +-
drivers/phy/phy-exynos-mipi-video.c | 2 +-
drivers/phy/phy-exynos5-usbdrd.c | 3 +--
drivers/phy/phy-exynos5250-sata.c| 2 +-
drivers/phy/phy-hix5hd2-sata.c | 2 +-
drivers/phy/phy-miphy365x.c | 2 +-
drivers/phy/phy-mvebu-sata.c | 2 +-
drivers/phy/phy-omap-usb2.c | 2 +-
drivers/phy/phy-qcom-apq8064-sata.c | 3 +--
drivers/phy/phy-qcom-ipq806x-sata.c | 3 +--
drivers/phy/phy-samsung-usb2.c | 3 +--
drivers/phy/phy-spear1310-miphy.c| 2 +-
drivers/phy/phy-spear1340-miphy.c| 2 +-
drivers/phy/phy-sun4i-usb.c | 2 +-
drivers/phy/phy-ti-pipe3.c | 2 +-
drivers/phy/phy-twl4030-usb.c| 4 +---
drivers/phy/phy-xgene.c | 2 +-
drivers/pinctrl/pinctrl-tegra-xusb.c | 4 ++--
include/linux/phy/phy.h | 38 --
22 files changed, 28 insertions(+), 103 deletions(-)
diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
index 894fe74..3463983 100644
--- a/drivers/phy/phy-bcm-kona-usb2.c
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -117,7 +117,7 @@ static int bcm_kona_usb2_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, phy);
- gphy = devm_phy_create(dev, NULL, ops, NULL);
+ gphy = devm_phy_create(dev, NULL, ops);
if (IS_ERR(gphy))
return PTR_ERR(gphy);
diff --git a/drivers/phy/phy-berlin-sata.c b/drivers/phy/phy-berlin-sata.c
index 5c3a042..010c463 100644
--- a/drivers/phy/phy-berlin-sata.c
+++ b/drivers/phy/phy-berlin-sata.c
@@ -239,7 +239,7 @@ static int phy_berlin_sata_probe(struct platform_device
*pdev)
if (!phy_desc)
return -ENOMEM;
- phy = devm_phy_create(dev, NULL, phy_berlin_sata_ops, NULL);
+ phy = devm_phy_create(dev, NULL, phy_berlin_sata_ops);
if (IS_ERR(phy)) {
dev_err(dev, failed to create PHY %d\n, phy_id);
return PTR_ERR(phy);
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 67a8c726..834b337 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -55,36 +55,6 @@ static int devm_phy_match(struct device *dev, void *res,
void *match_data)
return res == match_data;
}
-static struct phy *phy_lookup(struct device *device, const char *port)
-{
- unsigned int count;
- struct phy *phy;
- struct device *dev;
- struct phy_consumer *consumers;
- struct class_dev_iter iter;
-
- class_dev_iter_init(iter, phy_class, NULL, NULL);
- while ((dev = class_dev_iter_next(iter))) {
- phy = to_phy(dev);
-
- if (!phy-init_data)
- continue;
- count = phy-init_data-num_consumers;
- consumers = phy-init_data-consumers;
- while (count--) {
- if (!strcmp(consumers-dev_name, dev_name(device))
- !strcmp(consumers-port, port)) {
- class_dev_iter_exit(iter);
- return phy;
- }
- consumers++;
- }
- }
-
- class_dev_iter_exit(iter);
- return ERR_PTR(-ENODEV);
-}
-
/**
* phy_register_lookup() - register PHY/device association
* @pl: association to register
@@ -210,10 +180,6 @@ static struct phy *phy_find(struct device *dev, const char
*con_id)
}
class_dev_iter_exit(iter);
}
-
- /* fall-back to the old lookup method for now */
- if (IS_ERR(phy))
- phy = phy_lookup(dev, con_id);
return phy;
}
@@ -721,13 +687,11 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
* @dev: device that is creating the new phy
* @node: device node of the phy
* @ops: function pointers for performing phy operations
- * @init_data: contains the list of PHY consumers or NULL
*
* Called to create a phy using phy framework.
*/
struct phy *phy_create(struct device *dev, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data)
+ const struct phy_ops *ops)
{
int ret;
int id;
@@ -765,7 +729,6 @@ struct phy *phy_create(struct device *dev, struct
device_node *node,
phy-dev.of_node = node ?: dev-of_node;
phy-id = id;
phy-ops = ops;
- phy-init_data = init_data;
ret = dev_set_name(phy-dev, phy-%s.%d, dev_name(dev), id
Re: [PATCH 3/6] arm: omap3: twl: use the new lookup method with usb phy
On Thu, Sep 11, 2014 at 08:56:15PM +0530, Kishon Vijay Abraham I wrote:
+static struct phy_lookup twl4030_usb_lookup = {
+ .phy_name = phy-twl4030_usb.0,
+ .dev_id = musb-hdrc.0,
+ .con_id = usb,
};
Can use PHY_LOOKUP no?
I'll fix this.
Thanks,
--
heikki
--
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 2/6] phy: improved lookup method
On Thu, Sep 11, 2014 at 09:03:06PM +0530, Kishon Vijay Abraham I wrote:
+static struct phy *phy_find(struct device *dev, const char *con_id)
+{
+ const char *dev_id = dev ? dev_name(dev) : NULL;
+ int match, best_found = 0, best_possible = 0;
+ struct phy *phy = ERR_PTR(-ENODEV);
+ struct phy_lookup *p, *pl = NULL;
+
+ if (dev_id)
+ best_possible += 2;
+ if (con_id)
+ best_possible += 1;
+
+ list_for_each_entry(p, phys, node) {
+ match = 0;
+ if (p-dev_id) {
+ if (!dev_id || strcmp(p-dev_id, dev_id))
+ continue;
+ match += 2;
+ }
+ if (p-con_id) {
+ if (!con_id || strcmp(p-con_id, con_id))
+ continue;
+ match += 1;
+ }
+
+ if (match best_found) {
+ pl = p;
+ if (match != best_possible)
+ best_found = match;
+ else
+ break;
+ }
+ }
+
+ if (pl) {
+ struct class_dev_iter iter;
+ struct device *phy_dev;
+
+ class_dev_iter_init(iter, phy_class, NULL, NULL);
+ while ((phy_dev = class_dev_iter_next(iter))) {
+ if (!strcmp(dev_name(phy_dev), pl-phy_name)) {
I'm not sure how it'll work with systems which has multiple PHYs since the
id
component of the device is determined purely in runtime.
I'd assume we'll be constantly patching the lookup data for non-dt boot :-/
I'm sorry but I don't think I understand (I must be a bit tired
today)? Could you please elaborate?
Have a nice weekend!
--
heikki
--
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 6/6] usb: dwc3: host: convey the PHYs to xhci
On Fri, Sep 12, 2014 at 07:41:56PM +0530, Kishon Vijay Abraham I wrote: I don't think create lookup should be in host init. If it's dt boot, the binding should be in dt data or for other boot modes the bindig should be done in the board file. This just seems hacky to me. So are you now suggesting that instead of using platform independent solution of sharing the PHYs here, you would have us add platform specific quirks? That would be totally wrong! No. The binding between the controller and the PHY is done in hardware design and it would be wrong to create such a binding in drivers/* IMO. And kernel of course always knows the hardware design when it's being booted, wrong! Firstly, don't assume this kind of controllers are always part of some SoC or chip set. They could easily be on a PCI card for example. Secondly, don't assume we could tell all the details about the board based on some identifiers. Fox example, at least with our SoCs we won't be able to differentiate the boards. And it's not like every board using the same SoC uses the same USB2 PHY for example. That kind of things are up to the manufacturers. By default we have to rely on hardware descriptions like DT and ACPI tables or being able to runtime detect (ULPI). If those things don't work, we live without PHY in this case. We add board specific quirks _only_ in case of exceptions, where we simply have no other way. If it's possible to avoid them, especially with something as simple as this, we avoid them! And please don't even consider use of board files especially if there is an option. They are the one thing that we are meant to avoid if possible! No? For dt yes, I'm not sure about other modes. So in the case of dt boot, I'd prefer giving the binding in dt file than anywhere else. I don't know how dt works, but at least in case of ACPI we still need to deliver the PHY to xHCI here, even when dwc3 is provided bindings to a PHY(s). -- heikki -- 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 2/6] phy: improved lookup method
On Fri, Sep 12, 2014 at 08:16:01PM +0530, Kishon Vijay Abraham I wrote:
Assume you have 2 phys in your system..
static struct phy_lookup usb_lookup = {
.phy_name = phy-usb.0,
.dev_id = usb.0,
.con_id = usb,
};
static struct phy_lookup sata_lookup = {
.phy_name = sata-usb.1,
.dev_id = sata.0,
.con_id = sata,
};
First you do modprobe phy-usb, the probe of USB PHY driver gets invoked and it
creates the PHY. The phy-core will find a free id (now it will be 0) and then
name the phy as phy-usb.0.
Then with modprobe phy-sata, the phy-core will create phy-sata.1.
This is an ideal case where the .phy_name in phy_lookup matches.
Consider if the order is flipped and the user does modprobe phy-sata first.
The
phy_names won't match anymore (the sata phy device name would be
sata-usb.0).
True!
So we can't accept statically created lookups. Which is probable the
best thing to do in any case even if there wasn't this issue.
I think we already talked about this. I know I was going to create the
lookup for twl4030 in twl-core.c instead of the board file at one
point, but forgot about it. I need to do that now.
In any case, I'll fix this by dropping the possibility of creating the
lookups statically. I'll prepare new version of the whole set.
Thanks,
--
heikki
--
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 6/6] usb: dwc3: host: convey the PHYs to xhci
On Tue, Sep 16, 2014 at 12:07:00PM +0530, Kishon Vijay Abraham I wrote: Hi, On Monday 15 September 2014 05:36 PM, Heikki Krogerus wrote: On Fri, Sep 12, 2014 at 07:41:56PM +0530, Kishon Vijay Abraham I wrote: I don't think create lookup should be in host init. If it's dt boot, the binding should be in dt data or for other boot modes the bindig should be done in the board file. This just seems hacky to me. So are you now suggesting that instead of using platform independent solution of sharing the PHYs here, you would have us add platform specific quirks? That would be totally wrong! No. The binding between the controller and the PHY is done in hardware design and it would be wrong to create such a binding in drivers/* IMO. And kernel of course always knows the hardware design when it's being booted, wrong! Exactly my point. By creating the binding in drivers/*, you are directly telling the driver of the hardware design whereas it should have come from dt or platform data or .. (ACPI?). Man, you are not getting this... We want to avoid the damn platform data!!! If you are not using devicetree it doesn't mean the same as something like board files or some other platform specific quirks are suddenly acceptable. I'm giving you a way of avoiding those things, basically a way ignoring the platform completely in this case, but you are saying no no no, we need to have board files. C'mon! And I'm pretty sure you misspelled this sentence ..you are directly telling the driver of the hardware design... I believe you meant to say Wau! With this we newer have to care about the hardware design with this driver!. Note. That and some other things that we can always simply ignore here with this approach include: - How were we enumerated (DT, ACPI, PCI...) - Do some other bindings exist (DT) - Do we even have PHYs to convey - Does xHCI have any use for the PHYs - What is the platform we are running on in general Firstly, don't assume this kind of controllers are always part of some SoC or chip set. They could easily be on a PCI card for example. Agreed. Not convinced the current phy-core could handle it well. If there is ever a PHY that needs OS control in this case, it will almost certainly be possible to runtime detected somehow like ULPI PHYs can be. Secondly, don't assume we could tell all the details about the board based on some identifiers. Fox example, at least with our SoCs we won't be able to differentiate the boards. And it's not like every board using the same SoC uses the same USB2 PHY for example. That kind of things are up to the manufacturers. right. In dt, generally we have different dt files for different boards, similarly we have different board files for different boards where those bindings can be created. Again not sure about ACPI. I'll repeat what I said below - If we don't have description of the hardware from something like DT or ACPI, and that includes the bindings, or we can't runtime detect the underlying hardware, by default it means we live without PHYs. Quirks you add only in case of exceptions, but I actually think there will never be need for them... If we are not using ACPI, we are using devicetree and otherwise we can runtime detect the PHYs one way or the other. And again, if no PHY is found it simply means the PHYs are autonomous. So as you can see, it's possible we will newer need any kind of platform data in order to provide dwc3 the correct PHYs, no matter what kind of platform we are running on, so it makes no sense of having them just for dwc3 host. Do you not agree? I don't know how dt works, but at least in case of ACPI we still need to deliver the PHY to xHCI here, even when dwc3 is provided bindings to a PHY(s). Agreed. But can't we have the bindings for xHCI in ACPI itself? No. ACPI will never provide separate object for the xHCI that is part of DWC3. There is nothing the PHYs could be bound to. -- heikki -- 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 2/6] phy: improved lookup method
On Mon, Sep 15, 2014 at 03:35:08PM +0300, Heikki Krogerus wrote:
On Fri, Sep 12, 2014 at 08:16:01PM +0530, Kishon Vijay Abraham I wrote:
Assume you have 2 phys in your system..
static struct phy_lookup usb_lookup = {
.phy_name = phy-usb.0,
.dev_id = usb.0,
.con_id = usb,
};
static struct phy_lookup sata_lookup = {
.phy_name = sata-usb.1,
.dev_id = sata.0,
.con_id = sata,
};
First you do modprobe phy-usb, the probe of USB PHY driver gets invoked and
it
creates the PHY. The phy-core will find a free id (now it will be 0) and
then
name the phy as phy-usb.0.
Then with modprobe phy-sata, the phy-core will create phy-sata.1.
This is an ideal case where the .phy_name in phy_lookup matches.
Consider if the order is flipped and the user does modprobe phy-sata first.
The
phy_names won't match anymore (the sata phy device name would be
sata-usb.0).
Actually, I don't think there would be this problem if we used the
name of the actual device which is the parent of phy devices, right?
Cheers,
--
heikki
--
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 2/6] phy: improved lookup method
On Mon, Sep 22, 2014 at 05:07:55PM +0530, Kishon Vijay Abraham I wrote:
On Thursday 18 September 2014 03:55 PM, Heikki Krogerus wrote:
On Mon, Sep 15, 2014 at 03:35:08PM +0300, Heikki Krogerus wrote:
On Fri, Sep 12, 2014 at 08:16:01PM +0530, Kishon Vijay Abraham I wrote:
Assume you have 2 phys in your system..
static struct phy_lookup usb_lookup = {
.phy_name = phy-usb.0,
.dev_id = usb.0,
.con_id = usb,
};
static struct phy_lookup sata_lookup = {
.phy_name = sata-usb.1,
.dev_id = sata.0,
.con_id = sata,
};
First you do modprobe phy-usb, the probe of USB PHY driver gets invoked
and it
creates the PHY. The phy-core will find a free id (now it will be 0) and
then
name the phy as phy-usb.0.
Then with modprobe phy-sata, the phy-core will create phy-sata.1.
This is an ideal case where the .phy_name in phy_lookup matches.
Consider if the order is flipped and the user does modprobe phy-sata
first. The
phy_names won't match anymore (the sata phy device name would be
sata-usb.0).
Actually, I don't think there would be this problem if we used the
name of the actual device which is the parent of phy devices, right?
hmm.. but if the parent is a multi-phy phy provider (like pipe3 PHY driver),
we
might end up with the same problem.
I'm not completely sure what you mean? If you are talking about
platforms with multiple instances of a single phy, I don't see how
there could ever be a scenario where we did not know the order in
which they were enumerated. Can you give an example again?
Thanks,
--
heikki
--
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 2/6] phy: improved lookup method
On Tue, Sep 23, 2014 at 04:33:09PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 23 September 2014 04:23 PM, Heikki Krogerus wrote:
On Mon, Sep 22, 2014 at 05:07:55PM +0530, Kishon Vijay Abraham I wrote:
On Thursday 18 September 2014 03:55 PM, Heikki Krogerus wrote:
On Mon, Sep 15, 2014 at 03:35:08PM +0300, Heikki Krogerus wrote:
On Fri, Sep 12, 2014 at 08:16:01PM +0530, Kishon Vijay Abraham I wrote:
Assume you have 2 phys in your system..
static struct phy_lookup usb_lookup = {
.phy_name = phy-usb.0,
.dev_id = usb.0,
.con_id = usb,
};
static struct phy_lookup sata_lookup = {
.phy_name = sata-usb.1,
.dev_id = sata.0,
.con_id = sata,
};
First you do modprobe phy-usb, the probe of USB PHY driver gets invoked
and it
creates the PHY. The phy-core will find a free id (now it will be 0)
and then
name the phy as phy-usb.0.
Then with modprobe phy-sata, the phy-core will create phy-sata.1.
This is an ideal case where the .phy_name in phy_lookup matches.
Consider if the order is flipped and the user does modprobe phy-sata
first. The
phy_names won't match anymore (the sata phy device name would be
sata-usb.0).
Actually, I don't think there would be this problem if we used the
name of the actual device which is the parent of phy devices, right?
hmm.. but if the parent is a multi-phy phy provider (like pipe3 PHY
driver), we
might end up with the same problem.
I'm not completely sure what you mean? If you are talking about
platforms with multiple instances of a single phy, I don't see how
there could ever be a scenario where we did not know the order in
which they were enumerated. Can you give an example again?
If a single IP implements multiple PHYs (phy-miphy365x.c in linux-phy next),
the parent for all the phy devices would be the same.
OK, got it. So I guess we need to match to the phy dev and to the phy
name. First to the dev and then in case the phy name is defined in the
lookup, to that as well. That should cover both cases.
Thanks,
--
heikki
--
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
[resend PATCH] usb: dwc3: pci: Add PCI ID for Intel Braswell
From: Alan Cox a...@linux.intel.com
The device controller is the same but it has different PCI ID. Add this new
ID to the driver's list of supported IDs.
Signed-off-by: Alan Cox a...@linux.intel.com
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/usb/dwc3/dwc3-pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 436fb08..a36cf66 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -30,6 +30,7 @@
#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
#define PCI_DEVICE_ID_INTEL_BYT0x0f37
#define PCI_DEVICE_ID_INTEL_MRFLD 0x119e
+#define PCI_DEVICE_ID_INTEL_BSW0x22B7
struct dwc3_pci {
struct device *dev;
@@ -181,6 +182,7 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3),
},
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BSW), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
{ }/* Terminating Entry */
--
2.1.0
--
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
[resend PATCH 2/3] usb: dwc3: core: only setting the dma_mask when needed
If the probe drivers have already set the dma_mask, not
replacing the value.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/usb/dwc3/core.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..d08cac5 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -708,9 +708,11 @@ static int dwc3_probe(struct platform_device *pdev)
spin_lock_init(dwc-lock);
platform_set_drvdata(pdev, dwc);
- dev-dma_mask = dev-parent-dma_mask;
- dev-dma_parms = dev-parent-dma_parms;
- dma_set_coherent_mask(dev, dev-parent-coherent_dma_mask);
+ if (!dev-dma_mask) {
+ dev-dma_mask = dev-parent-dma_mask;
+ dev-dma_parms = dev-parent-dma_parms;
+ dma_set_coherent_mask(dev, dev-parent-coherent_dma_mask);
+ }
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
--
2.1.0
--
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
[resend PATCH 1/3] ACPI / platform: provide default DMA mask
Most devices are configured for 32-bit DMA addresses. Setting the mask to 32-bit here removes the need for the drivers to do it separately. Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com Cc: Rafael J. Wysocki r...@rjwysocki.net --- drivers/acpi/acpi_platform.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c index 2bf9082..8d099e6 100644 --- a/drivers/acpi/acpi_platform.c +++ b/drivers/acpi/acpi_platform.c @@ -16,6 +16,7 @@ #include linux/err.h #include linux/kernel.h #include linux/module.h +#include linux/dma-mapping.h #include linux/platform_device.h #include internal.h @@ -102,6 +103,7 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev) pdevinfo.res = resources; pdevinfo.num_res = count; pdevinfo.acpi_node.companion = adev; + pdevinfo.dma_mask = DMA_BIT_MASK(32); pdev = platform_device_register_full(pdevinfo); if (IS_ERR(pdev)) dev_err(adev-dev, platform device creation failed: %ld\n, -- 2.1.0 -- 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
[resend PATCH 0/3] usb: dwc3: ACPI support
Hi, The original series included patch that adds Braswell PCI ID, but I send it separately. The DMA mask caused a problem as our acpi platform code does not provide anything for us. Instead of trying to fix it in dwc3 I decided to suggest the first patch in this series where I provide default DMA mask for all the ACPI platform devices. Heikki Krogerus (3): ACPI / platform: provide default DMA mask usb: dwc3: core: only setting the dma_mask when needed usb: dwc3: add ACPI support drivers/acpi/acpi_platform.c | 2 ++ drivers/usb/dwc3/core.c | 18 +++--- 2 files changed, 17 insertions(+), 3 deletions(-) -- 2.1.0 -- 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
[resend PATCH 3/3] usb: dwc3: add ACPI support
Adds ACPI ID used on newer Intel SoCs.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/usb/dwc3/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index d08cac5..c2cf2d8 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -32,6 +32,7 @@
#include linux/delay.h
#include linux/dma-mapping.h
#include linux/of.h
+#include linux/acpi.h
#include linux/usb/ch9.h
#include linux/usb/gadget.h
@@ -960,12 +961,21 @@ static const struct of_device_id of_dwc3_match[] = {
MODULE_DEVICE_TABLE(of, of_dwc3_match);
#endif
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id dwc3_acpi_match[] = {
+ { 808622B7, 0 },
+ { },
+};
+MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match);
+#endif
+
static struct platform_driver dwc3_driver = {
.probe = dwc3_probe,
.remove = dwc3_remove,
.driver = {
.name = dwc3,
.of_match_table = of_match_ptr(of_dwc3_match),
+ .acpi_match_table = ACPI_PTR(dwc3_acpi_match),
.pm = DWC3_PM_OPS,
},
};
--
2.1.0
--
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 2/6] phy: improved lookup method
Assume you have 2 phys in your system..
static struct phy_lookup usb_lookup = {
.phy_name = phy-usb.0,
.dev_id = usb.0,
.con_id = usb,
};
static struct phy_lookup sata_lookup = {
.phy_name = sata-usb.1,
.dev_id = sata.0,
.con_id = sata,
};
First you do modprobe phy-usb, the probe of USB PHY driver gets
invoked and it
creates the PHY. The phy-core will find a free id (now it will be 0)
and then
name the phy as phy-usb.0.
Then with modprobe phy-sata, the phy-core will create phy-sata.1.
This is an ideal case where the .phy_name in phy_lookup matches.
Consider if the order is flipped and the user does modprobe phy-sata
first. The
phy_names won't match anymore (the sata phy device name would be
sata-usb.0).
Actually, I don't think there would be this problem if we used the
name of the actual device which is the parent of phy devices, right?
hmm.. but if the parent is a multi-phy phy provider (like pipe3 PHY
driver), we
might end up with the same problem.
I'm not completely sure what you mean? If you are talking about
platforms with multiple instances of a single phy, I don't see how
there could ever be a scenario where we did not know the order in
which they were enumerated. Can you give an example again?
If a single IP implements multiple PHYs (phy-miphy365x.c in linux-phy
next),
the parent for all the phy devices would be the same.
Hold on...
Let's take a step back here. Where could we actually have a scenario
where the phy device, the dev_id (consumer) and the con_id would all
be the same? There can't be such a case.
It's not like you could ever have a driver requesting multiple phys
with the same con_id. You would just get the same phy handle even if
you used dt.
phy1 = phy_get(dev, phy);
...
phy2 = phy_get(dev, phy);
And if the drivers requesting those phys are different, your consumers
are different.
Isn't making the PHY to be aware of it's user much simpler?
No it's not. I'm not going into this again. We have already gone
through this in the past.
Cheers,
--
heikki
--
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
[PATCHv2 3/3] usb: dwc3: add ACPI support
Adding ACPI ID used on newer Intel SoCs.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/usb/dwc3/core.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index d08cac5..88e29f5 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -32,6 +32,7 @@
#include linux/delay.h
#include linux/dma-mapping.h
#include linux/of.h
+#include linux/acpi.h
#include linux/usb/ch9.h
#include linux/usb/gadget.h
@@ -960,12 +961,24 @@ static const struct of_device_id of_dwc3_match[] = {
MODULE_DEVICE_TABLE(of, of_dwc3_match);
#endif
+#ifdef CONFIG_ACPI
+
+#define ACPI_ID_INTEL_BSW 808622B7
+
+static const struct acpi_device_id dwc3_acpi_match[] = {
+ { ACPI_ID_INTEL_BSW, 0 },
+ { },
+};
+MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match);
+#endif
+
static struct platform_driver dwc3_driver = {
.probe = dwc3_probe,
.remove = dwc3_remove,
.driver = {
.name = dwc3,
.of_match_table = of_match_ptr(of_dwc3_match),
+ .acpi_match_table = ACPI_PTR(dwc3_acpi_match),
.pm = DWC3_PM_OPS,
},
};
--
2.1.0
--
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: [RFC PATCH 3/4] usb: dwc3: add quirk to be compatible for AMD NL
A question, the dwc3 controller is the PCI-E device in my platform,
but the class code of PCI header is 0x0c0330, the same with xHC.
That's because it need to meet the windows enviroment. The dwc3
controller acted as only host mode to bind with windows xhci driver.
But on linux, sometimes, we auto-bind with xhci driver as well (class
code 0x0c0330) despite we use Pid/Vid on dwc3 driver. Then I need
rmmod xhci_hcd module and modprobe dwc3_pci module manually.
Any idea to resolve this issue?
Declare a fixup quirk. I'm not a pci expert, but I think something
like this should work..
static void dwc3_fix_amd_nl_class(struct pci_dev *pdev)
{
pdev-class = 0x0c03fe;
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL,
dwc3_fix_amd_nl_class);
Heikki, can you confirm if your DWC3 incarnations present this same
feature ? :-)
The DWC3 is not given xHCI class code on our boards.
Cheers,
--
heikki
--
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
[PATCHv4 4/6] phy: remove the old lookup method
The users of the old method are now converted to the new one.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
---
drivers/phy/phy-bcm-kona-usb2.c | 2 +-
drivers/phy/phy-berlin-sata.c| 2 +-
drivers/phy/phy-core.c | 45 +++-
drivers/phy/phy-exynos-dp-video.c| 2 +-
drivers/phy/phy-exynos-mipi-video.c | 2 +-
drivers/phy/phy-exynos5-usbdrd.c | 3 +--
drivers/phy/phy-exynos5250-sata.c| 2 +-
drivers/phy/phy-hix5hd2-sata.c | 2 +-
drivers/phy/phy-miphy365x.c | 2 +-
drivers/phy/phy-mvebu-sata.c | 2 +-
drivers/phy/phy-omap-usb2.c | 2 +-
drivers/phy/phy-qcom-apq8064-sata.c | 3 +--
drivers/phy/phy-qcom-ipq806x-sata.c | 3 +--
drivers/phy/phy-rcar-gen2.c | 2 +-
drivers/phy/phy-samsung-usb2.c | 3 +--
drivers/phy/phy-spear1310-miphy.c| 2 +-
drivers/phy/phy-spear1340-miphy.c| 2 +-
drivers/phy/phy-stih407-usb.c| 2 +-
drivers/phy/phy-stih41x-usb.c| 2 +-
drivers/phy/phy-sun4i-usb.c | 2 +-
drivers/phy/phy-ti-pipe3.c | 2 +-
drivers/phy/phy-twl4030-usb.c| 4 +---
drivers/phy/phy-xgene.c | 2 +-
drivers/pinctrl/pinctrl-tegra-xusb.c | 4 ++--
include/linux/phy/phy.h | 38 --
25 files changed, 31 insertions(+), 106 deletions(-)
diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
index c1e0ca3..ef2dc1a 100644
--- a/drivers/phy/phy-bcm-kona-usb2.c
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -117,7 +117,7 @@ static int bcm_kona_usb2_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, phy);
- gphy = devm_phy_create(dev, NULL, ops, NULL);
+ gphy = devm_phy_create(dev, NULL, ops);
if (IS_ERR(gphy))
return PTR_ERR(gphy);
diff --git a/drivers/phy/phy-berlin-sata.c b/drivers/phy/phy-berlin-sata.c
index 69ced52..99bbf91 100644
--- a/drivers/phy/phy-berlin-sata.c
+++ b/drivers/phy/phy-berlin-sata.c
@@ -239,7 +239,7 @@ static int phy_berlin_sata_probe(struct platform_device
*pdev)
if (!phy_desc)
return -ENOMEM;
- phy = devm_phy_create(dev, NULL, phy_berlin_sata_ops, NULL);
+ phy = devm_phy_create(dev, NULL, phy_berlin_sata_ops);
if (IS_ERR(phy)) {
dev_err(dev, failed to create PHY %d\n, phy_id);
return PTR_ERR(phy);
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index c8d0f66..0b279d3 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -55,36 +55,6 @@ static int devm_phy_match(struct device *dev, void *res,
void *match_data)
return res == match_data;
}
-static struct phy *phy_lookup(struct device *device, const char *port)
-{
- unsigned int count;
- struct phy *phy;
- struct device *dev;
- struct phy_consumer *consumers;
- struct class_dev_iter iter;
-
- class_dev_iter_init(iter, phy_class, NULL, NULL);
- while ((dev = class_dev_iter_next(iter))) {
- phy = to_phy(dev);
-
- if (!phy-init_data)
- continue;
- count = phy-init_data-num_consumers;
- consumers = phy-init_data-consumers;
- while (count--) {
- if (!strcmp(consumers-dev_name, dev_name(device))
- !strcmp(consumers-port, port)) {
- class_dev_iter_exit(iter);
- return phy;
- }
- consumers++;
- }
- }
-
- class_dev_iter_exit(iter);
- return ERR_PTR(-ENODEV);
-}
-
/**
* phy_register_lookup() - register PHY/device association
* @pl: association to register
@@ -210,10 +180,6 @@ static struct phy *phy_find(struct device *dev, const char
*con_id)
}
class_dev_iter_exit(iter);
}
-
- /* fall-back to the old lookup method for now */
- if (IS_ERR(phy))
- phy = phy_lookup(dev, con_id);
return phy;
}
@@ -721,13 +687,11 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
* @dev: device that is creating the new phy
* @node: device node of the phy
* @ops: function pointers for performing phy operations
- * @init_data: contains the list of PHY consumers or NULL
*
* Called to create a phy using phy framework.
*/
struct phy *phy_create(struct device *dev, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data)
+ const struct phy_ops *ops)
{
int ret;
int id;
@@ -765,7 +729,6 @@ struct phy *phy_create(struct device *dev, struct
device_node *node,
phy-dev.of_node = node ?: dev-of_node;
phy
[PATCHv4 6/6] usb: dwc3: host: convey the PHYs to xhci
On some platforms a PHY may need to be handled also in the
host controller driver. Exynos5420 SoC requires some PHY
tuning based on the USB speed. This patch delivers dwc3's
PHYs to the xhci platform device when it's created.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/host.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index dcb8ca0..12bfd3c 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -29,8 +29,7 @@ int dwc3_host_init(struct dwc3 *dwc)
xhci = platform_device_alloc(xhci-hcd, PLATFORM_DEVID_AUTO);
if (!xhci) {
dev_err(dwc-dev, couldn't allocate xHCI device\n);
- ret = -ENOMEM;
- goto err0;
+ return -ENOMEM;
}
dma_set_coherent_mask(xhci-dev, dwc-dev-coherent_dma_mask);
@@ -60,22 +59,33 @@ int dwc3_host_init(struct dwc3 *dwc)
goto err1;
}
+ phy_create_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(xhci-dev));
+ phy_create_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(xhci-dev));
+
ret = platform_device_add(xhci);
if (ret) {
dev_err(dwc-dev, failed to register xHCI device\n);
- goto err1;
+ goto err2;
}
return 0;
-
+err2:
+ phy_remove_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(xhci-dev));
+ phy_remove_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(xhci-dev));
err1:
platform_device_put(xhci);
-
-err0:
return ret;
}
void dwc3_host_exit(struct dwc3 *dwc)
{
+ phy_remove_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(dwc-xhci-dev));
+ phy_remove_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(dwc-xhci-dev));
platform_device_unregister(dwc-xhci);
}
--
2.1.1
--
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
[PATCHv4 0/6] phy: simplified phy lookup
Hi, So the idea with these is that they should help to make it possible to request phys without caring about how they are mapped to the consumers, meaning, was is the mapping done in DT, ACPI, etc. Mapping phys to consumers can be now done with lookups similarly how clocks can be mapped in clkdev.c. Vivek needs to handle the phys of dwc3 also in xhci driver on Exynos5420 SoC, so I'm resending these now. Changes since v3: - We can't rely on the order in which the phys are registered, so using the name of the parent of the phy instance for matching instead of the phy itself. The parent device is always the actual physical device. - Using PHY_LOOKUP macro in twl-common.c as suggested by Kishon. Changes since v2: - Calling ida_simple_remove in release function as pointed out by Greg Heikki Krogerus (6): phy: safer to_phy() macro phy: improved lookup method arm: omap3: twl: use the new lookup method with usb phy phy: remove the old lookup method base: platform: name the device already during allocation usb: dwc3: host: convey the PHYs to xhci Documentation/phy.txt| 66 +-- arch/arm/mach-omap2/twl-common.c | 17 ++-- drivers/base/platform.c | 69 +--- drivers/phy/phy-bcm-kona-usb2.c | 2 +- drivers/phy/phy-berlin-sata.c| 2 +- drivers/phy/phy-core.c | 156 --- drivers/phy/phy-exynos-dp-video.c| 2 +- drivers/phy/phy-exynos-mipi-video.c | 2 +- drivers/phy/phy-exynos5-usbdrd.c | 3 +- drivers/phy/phy-exynos5250-sata.c| 2 +- drivers/phy/phy-hix5hd2-sata.c | 2 +- drivers/phy/phy-miphy365x.c | 2 +- drivers/phy/phy-mvebu-sata.c | 2 +- drivers/phy/phy-omap-usb2.c | 2 +- drivers/phy/phy-qcom-apq8064-sata.c | 3 +- drivers/phy/phy-qcom-ipq806x-sata.c | 3 +- drivers/phy/phy-rcar-gen2.c | 2 +- drivers/phy/phy-samsung-usb2.c | 3 +- drivers/phy/phy-spear1310-miphy.c| 2 +- drivers/phy/phy-spear1340-miphy.c| 2 +- drivers/phy/phy-stih407-usb.c| 2 +- drivers/phy/phy-stih41x-usb.c| 2 +- drivers/phy/phy-sun4i-usb.c | 2 +- drivers/phy/phy-ti-pipe3.c | 2 +- drivers/phy/phy-twl4030-usb.c| 4 +- drivers/phy/phy-xgene.c | 2 +- drivers/pinctrl/pinctrl-tegra-xusb.c | 4 +- drivers/usb/dwc3/host.c | 22 +++-- include/linux/phy/phy.h | 61 +++--- 29 files changed, 263 insertions(+), 182 deletions(-) -- 2.1.1 -- 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
[PATCHv4 5/6] base: platform: name the device already during allocation
The device name is needed when assigning resources like
clocks or GPIOs to devices using lookups. If
PLATFORM_DEVICE_AUTO is used, the device name is not know
before platform_device_add is called after which it's too
late to assign that kind of resources as the drivers most
likely have already requested them.
By naming the device already in platform_device_alloc, the
resources can be assigned before platform_device_add is
called.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/base/platform.c | 69 +
1 file changed, 41 insertions(+), 28 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b2afc29..97b6da3 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -195,11 +195,41 @@ void platform_device_put(struct platform_device *pdev)
}
EXPORT_SYMBOL_GPL(platform_device_put);
+static int pdev_set_name(struct platform_device *pdev)
+{
+ int ret;
+
+ switch (pdev-id) {
+ default:
+ return dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
+ case PLATFORM_DEVID_NONE:
+ return dev_set_name(pdev-dev, %s, pdev-name);
+ case PLATFORM_DEVID_AUTO:
+ /*
+* Automatically allocated device ID. We mark it as such so
+* that we remember it must be freed, and we append a suffix
+* to avoid namespace collision with explicit IDs.
+*/
+ ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
+ if (ret 0)
+ return ret;
+ pdev-id = ret;
+ pdev-id_auto = true;
+ return dev_set_name(pdev-dev, %s.%d.auto, pdev-name,
+ pdev-id);
+ }
+
+ return 0;
+}
+
static void platform_device_release(struct device *dev)
{
struct platform_object *pa = container_of(dev, struct platform_object,
pdev.dev);
+ if (pa-pdev.id_auto)
+ ida_simple_remove(platform_devid_ida, pa-pdev.id);
+
of_device_node_put(pa-pdev.dev);
kfree(pa-pdev.dev.platform_data);
kfree(pa-pdev.mfd_cell);
@@ -228,6 +258,10 @@ struct platform_device *platform_device_alloc(const char
*name, int id)
device_initialize(pa-pdev.dev);
pa-pdev.dev.release = platform_device_release;
arch_setup_pdev_archdata(pa-pdev);
+ if (pdev_set_name(pa-pdev)) {
+ kfree(pa);
+ return NULL;
+ }
}
return pa ? pa-pdev : NULL;
@@ -308,28 +342,6 @@ int platform_device_add(struct platform_device *pdev)
pdev-dev.bus = platform_bus_type;
- switch (pdev-id) {
- default:
- dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
- break;
- case PLATFORM_DEVID_NONE:
- dev_set_name(pdev-dev, %s, pdev-name);
- break;
- case PLATFORM_DEVID_AUTO:
- /*
-* Automatically allocated device ID. We mark it as such so
-* that we remember it must be freed, and we append a suffix
-* to avoid namespace collision with explicit IDs.
-*/
- ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
- if (ret 0)
- goto err_out;
- pdev-id = ret;
- pdev-id_auto = true;
- dev_set_name(pdev-dev, %s.%d.auto, pdev-name, pdev-id);
- break;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *p, *r = pdev-resource[i];
@@ -372,7 +384,6 @@ int platform_device_add(struct platform_device *pdev)
release_resource(r);
}
- err_out:
return ret;
}
EXPORT_SYMBOL_GPL(platform_device_add);
@@ -392,11 +403,6 @@ void platform_device_del(struct platform_device *pdev)
if (pdev) {
device_del(pdev-dev);
- if (pdev-id_auto) {
- ida_simple_remove(platform_devid_ida, pdev-id);
- pdev-id = PLATFORM_DEVID_AUTO;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *r = pdev-resource[i];
unsigned long type = resource_type(r);
@@ -414,8 +420,15 @@ EXPORT_SYMBOL_GPL(platform_device_del);
*/
int platform_device_register(struct platform_device *pdev)
{
+ int ret;
+
device_initialize(pdev-dev);
arch_setup_pdev_archdata(pdev);
+
+ ret = pdev_set_name(pdev);
+ if (ret)
+ return ret;
+
return platform_device_add(pdev);
}
EXPORT_SYMBOL_GPL(platform_device_register);
--
2.1.1
--
To unsubscribe from
[PATCHv4 1/6] phy: safer to_phy() macro
This makes to_phy() macro work with other variable names
besides dev.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
---
include/linux/phy/phy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 8cb6f81..9fda683 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -110,7 +110,7 @@ struct phy_init_data {
.port = _port,\
}
-#defineto_phy(dev) (container_of((dev), struct phy, dev))
+#defineto_phy(a) (container_of((a), struct phy, dev))
#defineof_phy_provider_register(dev, xlate)\
__of_phy_provider_register((dev), THIS_MODULE, (xlate))
--
2.1.1
--
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
[PATCHv4 2/6] phy: improved lookup method
Removes the need for the phys to be aware of their users
even when not using DT. The method is copied from clkdev.c.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
---
Documentation/phy.txt | 66 ---
drivers/phy/phy-core.c | 135 +++-
include/linux/phy/phy.h | 27 ++
3 files changed, 183 insertions(+), 45 deletions(-)
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
index c6594af..8add515 100644
--- a/Documentation/phy.txt
+++ b/Documentation/phy.txt
@@ -54,18 +54,14 @@ 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, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data);
+ const struct phy_ops *ops);
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data);
+ const struct phy_ops *ops);
The PHY drivers can use one of the above 2 APIs to create the PHY by passing
-the device pointer, phy ops and init_data.
+the device pointer and phy ops.
phy_ops is a set of function pointers for performing PHY operations such as
-init, exit, power_on and power_off. *init_data* is mandatory to get a reference
-to the PHY in the case of non-dt boot. See section *Board File Initialization*
-on how init_data should be used.
+init, exit, power_on and power_off.
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
@@ -137,42 +133,24 @@ 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. Board File Initialization
-
-Certain board file initialization is necessary in order to get a reference
-to the PHY in the case of non-dt boot.
-Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe,
-then in the board file the following initialization should be done.
-
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(dwc3.0, usb),
- PHY_CONSUMER(pcie.0, pcie),
- PHY_CONSUMER(sata.0, sata),
-};
-PHY_CONSUMER takes 2 parameters, first is the device name of the controller
-(PHY consumer) and second is the port name.
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
-};
-
-static const struct platform_device pipe3_phy_dev = {
- .name = pipe3-phy,
- .id = -1,
- .dev = {
- .platform_data = {
- .init_data = init_data,
- },
- },
-};
-
-then, while doing phy_create, the PHY driver should pass this init_data
- phy_create(dev, ops, pdata-init_data);
-
-and the controller driver (phy consumer) should pass the port name along with
-the device to get a reference to the PHY
- phy_get(dev, pcie);
+8. PHY Mappings
+
+In order to get reference to a PHY without help from DeviceTree, the framework
+offers lookups which can be compared to clkdev that allow clk structures to be
+bound to devices. A lookup can be made statically by directly registering
+phy_lookup structure which contains the name of the PHY device, the name of the
+device which the PHY will be bind to and Connection ID string. Alternatively a
+lookup can be made during runtime when a handle to the struct phy already
+exists.
+
+The framework offers the following APIs for registering and unregistering the
+lookups.
+
+void phy_register_lookup(struct phy_lookup *pl);
+int phy_create_lookup(struct phy *phy, const char *con_id, const char *dev_id);
+
+void phy_unregister_lookup(struct phy_lookup *pl);
+void phy_remove_lookup(struct phy *phy, const char *con_id, const char
*dev_id);
9. DeviceTree Binding
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index ff5eec5..c8d0f66 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -26,6 +26,7 @@
static struct class *phy_class;
static DEFINE_MUTEX(phy_provider_mutex);
static LIST_HEAD(phy_provider_list);
+static LIST_HEAD(phys);
static DEFINE_IDA(phy_ida);
static void devm_phy_release(struct device *dev, void *res)
@@ -84,6 +85,138 @@ static struct phy *phy_lookup(struct device *device, const
char *port)
return ERR_PTR(-ENODEV);
}
+/**
+ * phy_register_lookup() - register PHY/device association
+ * @pl: association to register
+ */
+void phy_register_lookup(struct phy_lookup *pl)
+{
+ mutex_lock(phy_provider_mutex);
+ list_add_tail(pl-node, phys);
+ mutex_unlock(phy_provider_mutex
[PATCHv4 3/6] arm: omap3: twl: use the new lookup method with usb phy
Provide complete association for the phy and it's user
(musb) with the new phy lookup method.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
arch/arm/mach-omap2/twl-common.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index b0d54da..0e4f3e3 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -91,18 +91,11 @@ void __init omap_pmic_late_init(void)
}
#if defined(CONFIG_ARCH_OMAP3)
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
-};
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
-};
+static struct phy_lookup twl4030_usb_lookup = PHY_LOOKUP(twl4030_usb,
+musb-hdrc.0, usb);
static struct twl4030_usb_data omap3_usb_pdata = {
- .usb_mode = T2_USB_MODE_ULPI,
- .init_data = init_data,
+ .usb_mode = T2_USB_MODE_ULPI,
};
static int omap3_batt_table[] = {
@@ -225,8 +218,10 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
}
/* Common platform data configurations */
- if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
+ if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb) {
+ phy_register_lookup(twl4030_usb_lookup);
pmic_data-usb = omap3_usb_pdata;
+ }
if (pdata_flags TWL_COMMON_PDATA_BCI !pmic_data-bci)
pmic_data-bci = omap3_bci_pdata;
--
2.1.1
--
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: [PATCHv4 2/6] phy: improved lookup method
Hi Vivek, On Thu, Nov 13, 2014 at 07:03:01PM +0530, Vivek Gautam wrote: Hi Heikki, Kishon, How about adding the change in attached patch [1] on top of this patch. Just introduced the phy pointer in phy_lookup structure, and modified phy_find() accordingly. [1] Attachment: 0001-phy-core-Use-phy-pointer-with-phy_lookup_table.patch Just to let you know, I'm finally able to work on this again. I was actually thinking that we should just roll back to the previous version where I didn't yet use the parent name, and rethink how to solve the problem Kishon pointed out. But, I'll take a look at this properly on Monday. Cheers, -- heikki -- 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: [PATCHv4 2/6] phy: improved lookup method
On Thu, Nov 13, 2014 at 07:03:01PM +0530, Vivek Gautam wrote: How about adding the change in attached patch [1] on top of this patch. Just introduced the phy pointer in phy_lookup structure, and modified phy_find() accordingly. I would be fine if we used the phy pointer to match, but if we have the pointer to the phy in the lookup, then I would say we need to remove the phy_name member. Otherwise we would have to support two ways of finding the lookups (one for the static lookups where we match to the phy_name and other where we match to the pointer). That means we will also not be able to create static lookups, but those would be only needed if we wanted to create them in board files. I don't think there will ever be need to create the lookups in board files, so I'm more then happy to remove the static way of creating the lookups. Kishon, if you are OK with this change, I'll prepare new version of this set and use the idea. Vivek, you'll get the credit for it. Thanks! -- heikki -- 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: [PATCHv4 2/6] phy: improved lookup method
On Tue, Nov 18, 2014 at 10:49:18AM +0530, Kishon Vijay Abraham I wrote: On Monday 17 November 2014 09:10 PM, Heikki Krogerus wrote: On Thu, Nov 13, 2014 at 07:03:01PM +0530, Vivek Gautam wrote: How about adding the change in attached patch [1] on top of this patch. Just introduced the phy pointer in phy_lookup structure, and modified phy_find() accordingly. I would be fine if we used the phy pointer to match, but if we have the pointer to the phy in the lookup, then I would say we need to remove the phy_name member. Otherwise we would have to support two ways of finding the lookups (one for the static lookups where we match to the phy_name and other where we match to the pointer). That means we will also not be able to create static lookups, but those would be only needed if we wanted to create them in board files. I don't think there will ever be need to create the lookups in board files, so I'm more then happy to remove the static way of creating the lookups. Just using the phy pointer sounds good. But interested to know where the phy pointer will be added to the lookup table. I'm making assumption that there will not be any (new) platforms where the bindings are not provided in HW descriptions like dt or ACPI tables. That leaves the lookups to be useful only in cases where a driver has to, for whatever reason, pass it's phy's forward, like dwc3 host. ULPI will be an other case where we will need to use them. Now the only user for the lookups is twl4030-usb, but since it's actually just ULPI type PHY in cases where we have platform data to deal with (please correct me if I'm wrong), I think we could later remove it's need for platform data completely with the help of the ULPI bus I'm working with. Cheers, -- heikki -- 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
[PATCHv5 5/7] phy: remove the old lookup method
The users of the old method are now converted to the new one.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/phy/phy-bcm-kona-usb2.c | 2 +-
drivers/phy/phy-berlin-sata.c| 2 +-
drivers/phy/phy-core.c | 49 +++-
drivers/phy/phy-exynos-dp-video.c| 2 +-
drivers/phy/phy-exynos-mipi-video.c | 2 +-
drivers/phy/phy-exynos5-usbdrd.c | 3 +--
drivers/phy/phy-exynos5250-sata.c| 2 +-
drivers/phy/phy-hix5hd2-sata.c | 2 +-
drivers/phy/phy-miphy365x.c | 2 +-
drivers/phy/phy-mvebu-sata.c | 2 +-
drivers/phy/phy-omap-usb2.c | 2 +-
drivers/phy/phy-qcom-apq8064-sata.c | 3 +--
drivers/phy/phy-qcom-ipq806x-sata.c | 3 +--
drivers/phy/phy-rcar-gen2.c | 2 +-
drivers/phy/phy-samsung-usb2.c | 3 +--
drivers/phy/phy-spear1310-miphy.c| 2 +-
drivers/phy/phy-spear1340-miphy.c| 2 +-
drivers/phy/phy-stih407-usb.c| 2 +-
drivers/phy/phy-stih41x-usb.c| 2 +-
drivers/phy/phy-sun4i-usb.c | 2 +-
drivers/phy/phy-ti-pipe3.c | 2 +-
drivers/phy/phy-twl4030-usb.c| 2 +-
drivers/phy/phy-xgene.c | 2 +-
drivers/pinctrl/pinctrl-tegra-xusb.c | 4 +--
include/linux/phy/phy.h | 38 +++-
25 files changed, 32 insertions(+), 107 deletions(-)
diff --git a/drivers/phy/phy-bcm-kona-usb2.c b/drivers/phy/phy-bcm-kona-usb2.c
index c1e0ca3..ef2dc1a 100644
--- a/drivers/phy/phy-bcm-kona-usb2.c
+++ b/drivers/phy/phy-bcm-kona-usb2.c
@@ -117,7 +117,7 @@ static int bcm_kona_usb2_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, phy);
- gphy = devm_phy_create(dev, NULL, ops, NULL);
+ gphy = devm_phy_create(dev, NULL, ops);
if (IS_ERR(gphy))
return PTR_ERR(gphy);
diff --git a/drivers/phy/phy-berlin-sata.c b/drivers/phy/phy-berlin-sata.c
index 69ced52..99bbf91 100644
--- a/drivers/phy/phy-berlin-sata.c
+++ b/drivers/phy/phy-berlin-sata.c
@@ -239,7 +239,7 @@ static int phy_berlin_sata_probe(struct platform_device
*pdev)
if (!phy_desc)
return -ENOMEM;
- phy = devm_phy_create(dev, NULL, phy_berlin_sata_ops, NULL);
+ phy = devm_phy_create(dev, NULL, phy_berlin_sata_ops);
if (IS_ERR(phy)) {
dev_err(dev, failed to create PHY %d\n, phy_id);
return PTR_ERR(phy);
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 9c3f0dc..e7d93f2 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -55,36 +55,6 @@ static int devm_phy_match(struct device *dev, void *res,
void *match_data)
return res == match_data;
}
-static struct phy *phy_lookup(struct device *device, const char *port)
-{
- unsigned int count;
- struct phy *phy;
- struct device *dev;
- struct phy_consumer *consumers;
- struct class_dev_iter iter;
-
- class_dev_iter_init(iter, phy_class, NULL, NULL);
- while ((dev = class_dev_iter_next(iter))) {
- phy = to_phy(dev);
-
- if (!phy-init_data)
- continue;
- count = phy-init_data-num_consumers;
- consumers = phy-init_data-consumers;
- while (count--) {
- if (!strcmp(consumers-dev_name, dev_name(device))
- !strcmp(consumers-port, port)) {
- class_dev_iter_exit(iter);
- return phy;
- }
- consumers++;
- }
- }
-
- class_dev_iter_exit(iter);
- return ERR_PTR(-ENODEV);
-}
-
/**
* phy_create_lookup() - allocate and register PHY/device association
* @phy: the phy of the association
@@ -148,7 +118,6 @@ static struct phy *phy_find(struct device *dev, const char
*con_id)
{
const char *dev_id = dev_name(dev);
struct phy_lookup *p, *pl = NULL;
- struct phy *phy;
mutex_lock(phy_provider_mutex);
list_for_each_entry(p, phys, node)
@@ -158,12 +127,7 @@ static struct phy *phy_find(struct device *dev, const char
*con_id)
}
mutex_unlock(phy_provider_mutex);
- phy = pl ? pl-phy : ERR_PTR(-ENODEV);
-
- /* fall-back to the old lookup method for now */
- if (IS_ERR(phy))
- phy = phy_lookup(dev, con_id);
- return phy;
+ return pl ? pl-phy : ERR_PTR(-ENODEV);
}
static struct phy_provider *of_phy_provider_lookup(struct device_node *node)
@@ -670,13 +634,11 @@ EXPORT_SYMBOL_GPL(devm_of_phy_get);
* @dev: device that is creating the new phy
* @node: device node of the phy
* @ops: function pointers for performing phy operations
- * @init_data: contains the list of PHY consumers or NULL
*
* Called to create a phy using phy framework
[PATCHv5 6/7] base: platform: name the device already during allocation
The device name is usually required when assigning resources
like clocks to platform devices. The problem is that the
device name is not know before platform_device_add is called
and that can be too late as the drivers may have already
requested the resources when the function returns. By naming
the device already in platform_device_alloc, the resources
can be assigned before platform_device_add is called.
This change allows different kinds of probe drivers to pass
forward their resources to the actual driver. The first
place where we need it is dwc3 controllers host glue code
(drivers/usb/dwc3/host.c) to pass the phy's to xhci.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/base/platform.c | 69 +
1 file changed, 41 insertions(+), 28 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index cdb6c07..d2217f3 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -195,11 +195,41 @@ void platform_device_put(struct platform_device *pdev)
}
EXPORT_SYMBOL_GPL(platform_device_put);
+static int pdev_set_name(struct platform_device *pdev)
+{
+ int ret;
+
+ switch (pdev-id) {
+ default:
+ return dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
+ case PLATFORM_DEVID_NONE:
+ return dev_set_name(pdev-dev, %s, pdev-name);
+ case PLATFORM_DEVID_AUTO:
+ /*
+* Automatically allocated device ID. We mark it as such so
+* that we remember it must be freed, and we append a suffix
+* to avoid namespace collision with explicit IDs.
+*/
+ ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
+ if (ret 0)
+ return ret;
+ pdev-id = ret;
+ pdev-id_auto = true;
+ return dev_set_name(pdev-dev, %s.%d.auto, pdev-name,
+ pdev-id);
+ }
+
+ return 0;
+}
+
static void platform_device_release(struct device *dev)
{
struct platform_object *pa = container_of(dev, struct platform_object,
pdev.dev);
+ if (pa-pdev.id_auto)
+ ida_simple_remove(platform_devid_ida, pa-pdev.id);
+
of_device_node_put(pa-pdev.dev);
kfree(pa-pdev.dev.platform_data);
kfree(pa-pdev.mfd_cell);
@@ -228,6 +258,10 @@ struct platform_device *platform_device_alloc(const char
*name, int id)
device_initialize(pa-pdev.dev);
pa-pdev.dev.release = platform_device_release;
arch_setup_pdev_archdata(pa-pdev);
+ if (pdev_set_name(pa-pdev)) {
+ kfree(pa);
+ return NULL;
+ }
}
return pa ? pa-pdev : NULL;
@@ -308,28 +342,6 @@ int platform_device_add(struct platform_device *pdev)
pdev-dev.bus = platform_bus_type;
- switch (pdev-id) {
- default:
- dev_set_name(pdev-dev, %s.%d, pdev-name, pdev-id);
- break;
- case PLATFORM_DEVID_NONE:
- dev_set_name(pdev-dev, %s, pdev-name);
- break;
- case PLATFORM_DEVID_AUTO:
- /*
-* Automatically allocated device ID. We mark it as such so
-* that we remember it must be freed, and we append a suffix
-* to avoid namespace collision with explicit IDs.
-*/
- ret = ida_simple_get(platform_devid_ida, 0, 0, GFP_KERNEL);
- if (ret 0)
- goto err_out;
- pdev-id = ret;
- pdev-id_auto = true;
- dev_set_name(pdev-dev, %s.%d.auto, pdev-name, pdev-id);
- break;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *p, *r = pdev-resource[i];
@@ -372,7 +384,6 @@ int platform_device_add(struct platform_device *pdev)
release_resource(r);
}
- err_out:
return ret;
}
EXPORT_SYMBOL_GPL(platform_device_add);
@@ -392,11 +403,6 @@ void platform_device_del(struct platform_device *pdev)
if (pdev) {
device_del(pdev-dev);
- if (pdev-id_auto) {
- ida_simple_remove(platform_devid_ida, pdev-id);
- pdev-id = PLATFORM_DEVID_AUTO;
- }
-
for (i = 0; i pdev-num_resources; i++) {
struct resource *r = pdev-resource[i];
unsigned long type = resource_type(r);
@@ -414,8 +420,15 @@ EXPORT_SYMBOL_GPL(platform_device_del);
*/
int platform_device_register(struct platform_device *pdev)
{
+ int ret;
+
device_initialize(pdev-dev);
arch_setup_pdev_archdata(pdev
[PATCHv5 7/7] usb: dwc3: host: convey the PHYs to xhci
On some platforms a PHY may need to be handled also in the
host controller driver. Exynos5420 SoC requires some PHY
tuning based on the USB speed. This patch delivers dwc3's
PHYs to the xhci platform device when it's created.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/host.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index dcb8ca0..12bfd3c 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -29,8 +29,7 @@ int dwc3_host_init(struct dwc3 *dwc)
xhci = platform_device_alloc(xhci-hcd, PLATFORM_DEVID_AUTO);
if (!xhci) {
dev_err(dwc-dev, couldn't allocate xHCI device\n);
- ret = -ENOMEM;
- goto err0;
+ return -ENOMEM;
}
dma_set_coherent_mask(xhci-dev, dwc-dev-coherent_dma_mask);
@@ -60,22 +59,33 @@ int dwc3_host_init(struct dwc3 *dwc)
goto err1;
}
+ phy_create_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(xhci-dev));
+ phy_create_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(xhci-dev));
+
ret = platform_device_add(xhci);
if (ret) {
dev_err(dwc-dev, failed to register xHCI device\n);
- goto err1;
+ goto err2;
}
return 0;
-
+err2:
+ phy_remove_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(xhci-dev));
+ phy_remove_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(xhci-dev));
err1:
platform_device_put(xhci);
-
-err0:
return ret;
}
void dwc3_host_exit(struct dwc3 *dwc)
{
+ phy_remove_lookup(dwc-usb2_generic_phy, usb2-phy,
+ dev_name(dwc-xhci-dev));
+ phy_remove_lookup(dwc-usb3_generic_phy, usb3-phy,
+ dev_name(dwc-xhci-dev));
platform_device_unregister(dwc-xhci);
}
--
2.1.3
--
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
[PATCHv5 2/7] phy: improved lookup method
Separates registration of the phy and the lookup. The method
is copied from clkdev.c,
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
Documentation/phy.txt | 60 ++-
drivers/phy/phy-core.c | 84 -
include/linux/phy/phy.h | 16 ++
3 files changed, 115 insertions(+), 45 deletions(-)
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
index c6594af..371361c 100644
--- a/Documentation/phy.txt
+++ b/Documentation/phy.txt
@@ -54,18 +54,14 @@ 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, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data);
+ const struct phy_ops *ops);
struct phy *devm_phy_create(struct device *dev, struct device_node *node,
- const struct phy_ops *ops,
- struct phy_init_data *init_data);
+ const struct phy_ops *ops);
The PHY drivers can use one of the above 2 APIs to create the PHY by passing
-the device pointer, phy ops and init_data.
+the device pointer and phy ops.
phy_ops is a set of function pointers for performing PHY operations such as
-init, exit, power_on and power_off. *init_data* is mandatory to get a reference
-to the PHY in the case of non-dt boot. See section *Board File Initialization*
-on how init_data should be used.
+init, exit, power_on and power_off.
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
@@ -137,42 +133,18 @@ 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. Board File Initialization
-
-Certain board file initialization is necessary in order to get a reference
-to the PHY in the case of non-dt boot.
-Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe,
-then in the board file the following initialization should be done.
-
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(dwc3.0, usb),
- PHY_CONSUMER(pcie.0, pcie),
- PHY_CONSUMER(sata.0, sata),
-};
-PHY_CONSUMER takes 2 parameters, first is the device name of the controller
-(PHY consumer) and second is the port name.
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
-};
-
-static const struct platform_device pipe3_phy_dev = {
- .name = pipe3-phy,
- .id = -1,
- .dev = {
- .platform_data = {
- .init_data = init_data,
- },
- },
-};
-
-then, while doing phy_create, the PHY driver should pass this init_data
- phy_create(dev, ops, pdata-init_data);
-
-and the controller driver (phy consumer) should pass the port name along with
-the device to get a reference to the PHY
- phy_get(dev, pcie);
+8. PHY Mappings
+
+In order to get reference to a PHY without help from DeviceTree, the framework
+offers lookups which can be compared to clkdev that allow clk structures to be
+bound to devices. A lookup can be made be made during runtime when a handle to
+the struct phy already exists.
+
+The framework offers the following API for registering and unregistering the
+lookups.
+
+int phy_create_lookup(struct phy *phy, const char *con_id, const char *dev_id);
+void phy_remove_lookup(struct phy *phy, const char *con_id, const char
*dev_id);
9. DeviceTree Binding
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index ff5eec5..9c3f0dc 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -26,6 +26,7 @@
static struct class *phy_class;
static DEFINE_MUTEX(phy_provider_mutex);
static LIST_HEAD(phy_provider_list);
+static LIST_HEAD(phys);
static DEFINE_IDA(phy_ida);
static void devm_phy_release(struct device *dev, void *res)
@@ -84,6 +85,87 @@ static struct phy *phy_lookup(struct device *device, const
char *port)
return ERR_PTR(-ENODEV);
}
+/**
+ * phy_create_lookup() - allocate and register PHY/device association
+ * @phy: the phy of the association
+ * @con_id: connection ID string on device
+ * @dev_id: the device of the association
+ *
+ * Creates and registers phy_lookup entry.
+ */
+int phy_create_lookup(struct phy *phy, const char *con_id, const char *dev_id)
+{
+ struct phy_lookup *pl;
+
+ if (!phy || !dev_id || !con_id)
+ return -EINVAL;
+
+ pl = kzalloc(sizeof(*pl), GFP_KERNEL);
+ if (!pl)
+ return -ENOMEM;
+
+ pl-dev_id = dev_id;
+ pl-con_id = con_id;
+ pl-phy = phy;
+
+ mutex_lock(phy_provider_mutex
[PATCHv5 3/7] phy: twl4030: use the new lookup method
Creates the lookup separately. Hard coding the consumer as
it can't be anything else except musb.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/phy/phy-twl4030-usb.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index e2698d29..0d20fe0 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -644,7 +644,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
struct usb_otg *otg;
struct device_node *np = pdev-dev.of_node;
struct phy_provider *phy_provider;
- struct phy_init_data*init_data = NULL;
twl = devm_kzalloc(pdev-dev, sizeof(*twl), GFP_KERNEL);
if (!twl)
@@ -655,7 +654,6 @@ static int twl4030_usb_probe(struct platform_device *pdev)
(enum twl4030_usb_mode *)twl-usb_mode);
else if (pdata) {
twl-usb_mode = pdata-usb_mode;
- init_data = pdata-init_data;
} else {
dev_err(pdev-dev, twl4030 initialized without pdata\n);
return -EINVAL;
@@ -680,7 +678,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
otg-set_host = twl4030_set_host;
otg-set_peripheral = twl4030_set_peripheral;
- phy = devm_phy_create(twl-dev, NULL, ops, init_data);
+ phy = devm_phy_create(twl-dev, NULL, ops, NULL);
if (IS_ERR(phy)) {
dev_dbg(pdev-dev, Failed to create PHY\n);
return PTR_ERR(phy);
@@ -733,6 +731,11 @@ static int twl4030_usb_probe(struct platform_device *pdev)
return status;
}
+ if (pdata)
+ err = phy_create_lookup(phy, usb, musb-hdrc.0);
+ if (err)
+ return err;
+
pm_runtime_mark_last_busy(pdev-dev);
pm_runtime_put_autosuspend(twl-dev);
--
2.1.3
--
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
[PATCHv5 4/7] arm: omap3: twl: remove usb phy init data
The driver does no use it any more.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
arch/arm/mach-omap2/twl-common.c | 12 +---
include/linux/i2c/twl.h | 2 --
2 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index b0d54da..4457e73 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -91,18 +91,8 @@ void __init omap_pmic_late_init(void)
}
#if defined(CONFIG_ARCH_OMAP3)
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
-};
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
-};
-
static struct twl4030_usb_data omap3_usb_pdata = {
- .usb_mode = T2_USB_MODE_ULPI,
- .init_data = init_data,
+ .usb_mode = T2_USB_MODE_ULPI,
};
static int omap3_batt_table[] = {
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 8cfb50f..0bc03f1 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -26,7 +26,6 @@
#define __TWL_H_
#include linux/types.h
-#include linux/phy/phy.h
#include linux/input/matrix_keypad.h
/*
@@ -634,7 +633,6 @@ enum twl4030_usb_mode {
struct twl4030_usb_data {
enum twl4030_usb_mode usb_mode;
unsigned long features;
- struct phy_init_data*init_data;
int (*phy_init)(struct device *dev);
int (*phy_exit)(struct device *dev);
--
2.1.3
--
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
[PATCHv5 0/7] phy: simplified phy lookup
This set will in practice just separate the creation of a phy and binding of it to the consumer. Mapping phys to consumers can be now done with lookups similarly how clocks can be mapped in clkdev.c. Vivek needs to handle the phys of dwc3 also in xhci driver on Exynos5420 SoC, so I'm resending these now. Changes since v4: - Support for static lookups is dropped. The lookups can be now only be created with phy_create_lookup() Changes since v3: - We can't rely on the order in which the phys are registered, so using the name of the parent of the phy instance for matching instead of the phy itself. The parent device is always the actual physical device. - Using PHY_LOOKUP macro in twl-common.c as suggested by Kishon. Changes since v2: - Calling ida_simple_remove in release function as pointed out by Greg Heikki Krogerus (7): phy: safer to_phy() macro phy: improved lookup method phy: twl4030: use the new lookup method arm: omap3: twl: remove usb phy init data phy: remove the old lookup method base: platform: name the device already during allocation usb: dwc3: host: convey the PHYs to xhci Documentation/phy.txt| 60 ++-- arch/arm/mach-omap2/twl-common.c | 12 +--- drivers/base/platform.c | 69 +-- drivers/phy/phy-bcm-kona-usb2.c | 2 +- drivers/phy/phy-berlin-sata.c| 2 +- drivers/phy/phy-core.c | 105 --- drivers/phy/phy-exynos-dp-video.c| 2 +- drivers/phy/phy-exynos-mipi-video.c | 2 +- drivers/phy/phy-exynos5-usbdrd.c | 3 +- drivers/phy/phy-exynos5250-sata.c| 2 +- drivers/phy/phy-hix5hd2-sata.c | 2 +- drivers/phy/phy-miphy365x.c | 2 +- drivers/phy/phy-mvebu-sata.c | 2 +- drivers/phy/phy-omap-usb2.c | 2 +- drivers/phy/phy-qcom-apq8064-sata.c | 3 +- drivers/phy/phy-qcom-ipq806x-sata.c | 3 +- drivers/phy/phy-rcar-gen2.c | 2 +- drivers/phy/phy-samsung-usb2.c | 3 +- drivers/phy/phy-spear1310-miphy.c| 2 +- drivers/phy/phy-spear1340-miphy.c| 2 +- drivers/phy/phy-stih407-usb.c| 2 +- drivers/phy/phy-stih41x-usb.c| 2 +- drivers/phy/phy-sun4i-usb.c | 2 +- drivers/phy/phy-ti-pipe3.c | 2 +- drivers/phy/phy-twl4030-usb.c| 9 ++- drivers/phy/phy-xgene.c | 2 +- drivers/pinctrl/pinctrl-tegra-xusb.c | 4 +- drivers/usb/dwc3/host.c | 22 ++-- include/linux/i2c/twl.h | 2 - include/linux/phy/phy.h | 52 +++-- 30 files changed, 195 insertions(+), 186 deletions(-) -- 2.1.3 -- 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
[PATCHv5 1/7] phy: safer to_phy() macro
This makes to_phy() macro work with other variable names
besides dev.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Tested-by: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Felipe Balbi ba...@ti.com
---
include/linux/phy/phy.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 8cb6f81..9fda683 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -110,7 +110,7 @@ struct phy_init_data {
.port = _port,\
}
-#defineto_phy(dev) (container_of((dev), struct phy, dev))
+#defineto_phy(a) (container_of((a), struct phy, dev))
#defineof_phy_provider_register(dev, xlate)\
__of_phy_provider_register((dev), THIS_MODULE, (xlate))
--
2.1.3
--
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
[PATCH] usb: dwc3: pci: add support for Intel Sunrise Point PCH
Add PCI IDs for Intel Sunrise Point PCH.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/usb/dwc3/dwc3-pci.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 7c4faf7..b642a2f 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -33,6 +33,8 @@
#define PCI_DEVICE_ID_INTEL_BYT0x0f37
#define PCI_DEVICE_ID_INTEL_MRFLD 0x119e
#define PCI_DEVICE_ID_INTEL_BSW0x22B7
+#define PCI_DEVICE_ID_INTEL_SPTLP 0x9d30
+#define PCI_DEVICE_ID_INTEL_SPTH 0xa130
struct dwc3_pci {
struct device *dev;
@@ -219,6 +221,8 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BSW), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SPTLP), },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SPTH), },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL_USB), },
{ }/* Terminating Entry */
};
--
2.1.3
--
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 8/8] phy: add driver for TI TUSB1210 ULPI PHY
Hi David,
On Sat, Jan 24, 2015 at 03:58:11PM -0800, David Cohen wrote:
+static int tusb1210_power_on(struct phy *phy)
+{
+ struct tusb1210 *tusb = phy_get_drvdata(phy);
+
+ gpiod_set_value_cansleep(tusb-gpio_reset, 1);
+ gpiod_set_value_cansleep(tusb-gpio_cs, 1);
+
+ /* Restore eye diagram optimisation value */
+ ulpi_write(tusb-ulpi, TUSB1210_VENDOR_SPECIFIC2,
+ tusb-eye_diagram_tuning);
After you power on phy, ulpi bus may not be available right away. In
intel case, phy power on happens during dwc3 power on. ULPI bus is not
available until OTG controller and phy are in sync.
In resume, you can't restore eye diagram from here.
I'm sorry but I don't think I understand? Where do we power on the phy
before dwc3 is powered on? Or is this a Baytrail-CR specific problem?
I can't see any problems with the hardware I have.
In any case, this sounds like purely dwc3 issue and not tusb1210
issue.
+static int tusb1210_probe(struct ulpi *ulpi)
+{
+ struct gpio_desc *gpio;
+ struct tusb1210 *tusb;
+ int ret;
+
+ tusb = devm_kzalloc(ulpi-dev, sizeof(*tusb), GFP_KERNEL);
+ if (!tusb)
+ return -ENOMEM;
+
+ gpio = devm_gpiod_get(ulpi-dev, reset);
+ if (!IS_ERR(gpio)) {
+ ret = gpiod_direction_output(gpio, 0);
+ if (ret)
+ return ret;
+ tusb-gpio_reset = gpio;
+ }
You cannot proceed with probe if gpio reset is not available. Different
from CS, it's a mandatory pin to toggle in order to power on/off phy and
get it in sync with OTG controller.
Well, let's check -ENOENT and -ENODEV return values separately. The
reset pin is not used on all platforms so getting this gpio is
optional. This is the case even with some Intel's platforms using
TUSB1210.
+
+ gpio = devm_gpiod_get(ulpi-dev, cs);
+ if (!IS_ERR(gpio)) {
+ ret = gpiod_direction_output(gpio, 0);
+ if (ret)
+ return ret;
+ tusb-gpio_cs = gpio;
+ }
+
+ /* Store initial eye diagram optimisation value */
+ ret = ulpi_read(ulpi, TUSB1210_VENDOR_SPECIFIC2);
It's unclear if ulpi is accessible at this point. You can't read it at
this point.
We wouldn't have reached this point if ulpi wasn't accessible.
Registering the ulpi interface would have already failed so no driver
would have been probed.
Thanks!
--
heikki
--
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 8/8] phy: add driver for TI TUSB1210 ULPI PHY
Hi David, What exactly are we breaking here? The USB on BYT-CR does not work yet with the mainline kernel, or does it? To enable it, I already suggested the BYT quirk (attached again). It used to work with mainline with minor restrictions. It stopped working (and I failed to catch it during patch review) when NOP phy enumeration was removed from dwc3-pci.c (but my understanding is that Felipe is expecting to add it back as default phy in case no phy is found by dwc3). BYT-CR worked well except for operations that needed to access phy's registers via ULPI bus (e.g. eye optimization). But to power on i.e. TUSB1210 all you need it to toggle GPIOs, which is done by generic phy. The need for ULPI bus was to complement this missing features, but instead we're breaking BYT-CR :/ So what you are saying that if I get one of those devices you mentioned and try vanilla kernel on it, the USB will work without any modifications to the kernel? You're misunderstanding BYT-CR SoC and external board components. The only reason that prevents most of BYT-CR boards' USB device work out-of-the-box is a switch device muxing D+/D- between host and device controllers (they depend on a single GPIO level to be toggled to get USB device working). I started discussion on how to upstream this case, but this is board related, not BYT-CR related. Some boards have also an i2c switch which requires extra i2c driver to get USB device working. But it doesn't mean the phy/otg controllers aren't fully functional with dwc3 + generic phy drivers. OK, so after we add driver for the mux, are you saying that USB device mode works without need for any patches to dwc3 or the nop phy driver for example with v3.18? In the code that we had in v3.18, the nop phy platform data had the reset gpio value set to -1 (invalid) by the dwc3-pci, so there was nothing toggling the reset gpio yet and the cs gpio was not handled at all. So unless you are saying we don't need to toggle the gpios before the USB became operational, you would have had to patch both dwc3-pci and phy-generic in order to get it operational. And of course if we didn't need to toggle them, there would not be any need for the nop phy at all. FWIW if you test a board without such switch (e.g. a reference BYT-T board called FFRD8 - BYT-CR is a derivation of BYT-T) it will work out-of-the-box. And it continues to work out-of-the-box even after we removed the creation of the PHY platform device because it does not need to toggle the gpios, right? BYT-T boards are actually one of the reason why we would really need the ulpi bus, because most them have tusb1211 (so not tusb1210) as the phy and they use it to detect the charger among other things. You missed my question. Have you tried to remove and reload dwc3 and phy modules with your test case? I do test unloading all the modules and reloading them back every time, and with the hack I suggested everything works just fine. We really can't go back to what we had. Please keep in mind that it tied us to the USB PHY framework, possibly forever, and we shouldn't have to depend on two different PHY frameworks. If we have to register the PHY device in dwc3-pci.c then you should create new nop phy for the generic phy framework and use that instead. But before you do that, we better be damn sure there is no way to make ulpi bus work, and we are not there yet. You have a point. But the transition should happen without creating regressions. You cannot remove previous design while we don't have the next one merged and functional. But I still don't see any regressions? Thanks, -- heikki -- 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 8/8] phy: add driver for TI TUSB1210 ULPI PHY
You can't really compare a bus like i2c, which can't enumerate devices natively, to ULPI which can. why not ? The BIOS might not need to use the PHY (or USB) at all, it can very well decide to never turn it on, right ? If ULPI was seen as a bus, then no. BIOS would have definitely left the PHY on. In fact, if we would have just asked the BIOS writers to leave it on, they would not have any problem with that, even without the bus. That's a really wrong assumption. ULPI bus depends on dwc3 to be functional and dwc3 depends on phy to be functional to complete its power on sequence. We can't ask BIOS to let both up and running all the time. FWIW we *cannot* rely on ULPI bus enumeration to probe ULPI devices, because it requires the ULPI device to be previously functional which can't happen before the enumeration. Even if we ask BIOS to let phy functional after boot, what happens when we remove modules and load it again? Should we ask BIOS to power on the components again in order to probe and power it on? It's a circular dependency you're creating. I don't think the other boards we have which use TUSB1210, like the BYT-I ones and I think some Merrifield based boards, expect any less from PM efficiency then BYT-CR, but we don't need to do any tricks with them in order to use ULPI bus. That is what I mean when I say this is BYT-CR specific problem. perhaps because firmware on those other boards are powering up the PHY ? Yes. And that's wrong assumption. Not all fw will power on PHY. Maybe we should stop all of other discussions and concentrate on this one: BIOS will not guarantee phy will be functional after boot. And if we remove modules and load again, it won't be functional regardless what BIOS did during boot. I was wrong when I talked about BIOS powering the PHY before bootup. I admit it. I'm saying this again as a reminder to myself: We can't mix BIOS (or any FW) and ACPI. I mix them constantly. And I definitely need to stop talking about bootup. How this is handled is by letting the ACPI Power State methods of the dwc3 device take care of the toggling of the gpios. It is done with the help of something called GPIO OperationRegion. In case you are not familiar with ACPI, then if you send me ACPI dump of one of those devices (or just copy /sys/firmware/acpi/tables/DSDT), I can try to modify the DSDT for you so you can use to test it, and provide you with the ASL snippet. You will see that the PHY is indeed in reset after bootup like it is now (BIOS does nothing differently), but the gpios are automatically toggled by the DSDT code. So every time you load dwc3 module, the PHY will be operational when we need it, and when you unload dwc3, it will be left in reset again. The OS does not have to do anything. I really think that this BYT-CR case will be one of really rare exception we will see, especially if we manage to put together the ACPI table review that has been though about. I don't agree with PM arguments if it means that we should be ready to accept loosing possibility for a generic solution in OS with a single device like our PHY. I seriously doubt it would prevent the products using these boards of achieving their PM requirements. But this conversation is outside our topic. we're not loosing anything. We're just considering what's the best way to tackle that ulpi_read() inside probe(). TUSB1210 driver _has_ to cope with situations where reset_gpio/cs_gpio are in unexpected state. Saying we will just fix the firmware, as if that was a simple feat, is counter-productive. You know guys, we shouldn't always just lay down and say, we just have to accept it can be anything or we just have to try to prepare for everything. We can influence these things, and we should. We can influence these things inside our own companies before any products is launched using our SoCs, and since more and more companies are releasing their code into the public before their product are launched, we even have a change to influence others. Lack of standards does not mean we should not try to achieve consistency. For example, now I should probable write to Documentation that ULPI PHY needs to be in condition where it's register can be accessed before the interface is registered., and I'm pretty sure it would be enough to have an effect on many of the new platforms that use ULPI PHYs. In order for phy to be functional, it does not depend only on toggling GPIOs. It depends on DWC3 going to reset state, then phy executes power on sequence, then DWC3 going out of reset state to sync clocks with phy. You're saying we should tell BIOS is concurrently mess with dwc3 together with dwc3 driver? I don't understand what you are saying here? Because of the need to write to the ULPI registers, I don't think we should try anything else except to use ULPI bus
Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY
Hi David, Felipe, why would you have dwc3 mess around with the PHY's gpios ? Doesn't look very good. ..but unfortunately we can't use the bus without it :(. We depend on being able to read the vendor and product id's in the bus driver. Doesn't the ugly platform device case look less ugly than this? The platform device would in any case need to be created only for this case. We can't any more just create the phy device unconditionally for every PCI platform like it was created before, as it's clear now the PHY device can be be created from other sources. It was a risk always. But the big problem is that since the PHY on your board is ULPI PHY, it will make it really difficult to add the ULPI bus support. And like I said in my previous mail, we would really need it for the boards that expect the PHY driver to provide functions like charger detection. We don't need it only for BYT based boards. So on top of the above, since the GPIO resources are given to dwc3, I actually think that my hack is better then the platform device. So what do you guys think we should do? I can't figure out how would we make the platform device work with ulpi bus. If we think about handling this in ulpi bus driver by setting setting the gpios before attempting to access the phy, which I'm not completely against, we have couple of problems. Firstly, the gpio resources are given to the dwc3 in this case, while normally they will be given to separate device object for the phy. Secondly, these gpios were not labeled in DSDT, but apparently requesting the gpios with index will be deprecated and not acceptable any more. With the remaining platforms that have not labeled the gpios we have to bind the gpios to labels separately in the drivers. With ACPI platforms the labels are introduced in struct acpi_gpio_mapping which needs to be registered with acpi_dev_add_driver_gpios(). Check net/rfkill/rfkill-gpio.c as an example how to use it. I think those points would make this too platform specific case to be handled in the ulpi bus driver. Suggestions? I still think the correct thing to do is to handle this in the quirk in dwc3-pci.c. Cheers, -- heikki -- 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
[PATCH 2/3] usb: dwc3: add ULPI interface support
Registers ULPI interface with the ULPI bus if HSPHY type is
ULPI.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/Kconfig | 7
drivers/usb/dwc3/Makefile | 4 ++
drivers/usb/dwc3/core.c | 9 +++-
drivers/usb/dwc3/core.h | 22 ++
drivers/usb/dwc3/ulpi.c | 102 ++
5 files changed, 143 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/dwc3/ulpi.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 58b5b2c..6d0c5e6 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -11,6 +11,13 @@ config USB_DWC3
if USB_DWC3
+config USB_DWC3_ULPI
+ bool Provide ULPI PHY Interface
+ depends on ULPI_PHY=y || ULPI_PHY=USB_DWC3
+ help
+ Select this if you have ULPI type PHY attached to your DWC3
+ controller.
+
choice
bool DWC3 Mode Selection
default USB_DWC3_DUAL_ROLE if (USB USB_GADGET)
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index bb34fbc..2fc44e0 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -16,6 +16,10 @@ ifneq ($(filter y,$(CONFIG_USB_DWC3_GADGET)
$(CONFIG_USB_DWC3_DUAL_ROLE)),)
dwc3-y += gadget.o ep0.o
endif
+ifneq ($(CONFIG_USB_DWC3_ULPI),)
+ dwc3-y += ulpi.o
+endif
+
ifneq ($(CONFIG_DEBUG_FS),)
dwc3-y += debugfs.o
endif
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 25ddc39..5219bc7 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -876,12 +876,17 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-hird_threshold = hird_threshold
| (dwc-is_utmi_l1_suspend 4);
+ platform_set_drvdata(pdev, dwc);
+
+ ret = dwc3_ulpi_init(dwc);
+ if (ret)
+ return ret;
+
ret = dwc3_core_get_phy(dwc);
if (ret)
return ret;
spin_lock_init(dwc-lock);
- platform_set_drvdata(pdev, dwc);
if (!dev-dma_mask) {
dev-dma_mask = dev-parent-dma_mask;
@@ -965,6 +970,7 @@ err1:
err0:
dwc3_free_event_buffers(dwc);
+ dwc3_ulpi_exit(dwc);
return ret;
}
@@ -984,6 +990,7 @@ static int dwc3_remove(struct platform_device *pdev)
phy_power_off(dwc-usb3_generic_phy);
dwc3_core_exit(dwc);
+ dwc3_ulpi_exit(dwc);
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 0842aa8..f6881a6 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -32,6 +32,7 @@
#include linux/usb/otg.h
#include linux/phy/phy.h
+#include linux/phy/ulpi/interface.h
#define DWC3_MSG_MAX 500
@@ -174,6 +175,14 @@
#define DWC3_GUSB2PHYCFG_PHYSOFTRST(1 31)
#define DWC3_GUSB2PHYCFG_SUSPHY(1 6)
+/* Global USB2 PHY Vendor Control Register */
+#define DWC3_GUSB2PHYACC_NEWREGREQ (1 25)
+#define DWC3_GUSB2PHYACC_BUSY (1 23)
+#define DWC3_GUSB2PHYACC_WRITE (1 22)
+#define DWC3_GUSB2PHYACC_ADDR(n) (n 16)
+#define DWC3_GUSB2PHYACC_EXTEND_ADDR(n)(n 8)
+#define DWC3_GUSB2PHYACC_DATA(n) (n 0xff)
+
/* Global USB3 PIPE Control Register */
#define DWC3_GUSB3PIPECTL_PHYSOFTRST (1 31)
#define DWC3_GUSB3PIPECTL_U2SSINP3OK (1 29)
@@ -590,6 +599,7 @@ struct dwc3_hwparams {
#define DWC3_NUM_INT(n)(((n) (0x3f 15)) 15)
/* HWPARAMS3 */
+#define DWC3_ULPI_HSPHY(1 3)
#define DWC3_NUM_IN_EPS_MASK (0x1f 18)
#define DWC3_NUM_EPS_MASK (0x3f 12)
#define DWC3_NUM_EPS(p)(((p)-hwparams3 \
@@ -739,6 +749,8 @@ struct dwc3 {
struct phy *usb2_generic_phy;
struct phy *usb3_generic_phy;
+ struct ulpi *ulpi;
+
void __iomem*regs;
size_t regs_size;
@@ -1035,4 +1047,14 @@ static inline int dwc3_gadget_resume(struct dwc3 *dwc)
}
#endif /* !IS_ENABLED(CONFIG_USB_DWC3_HOST) */
+#if IS_ENABLED(CONFIG_USB_DWC3_ULPI)
+int dwc3_ulpi_init(struct dwc3 *dwc);
+void dwc3_ulpi_exit(struct dwc3 *dwc);
+#else
+static inline int dwc3_ulpi_init(struct dwc3 *dwc)
+{ return 0; }
+static inline void dwc3_ulpi_exit(struct dwc3 *dwc)
+{ }
+#endif
+
#endif /* __DRIVERS_USB_DWC3_CORE_H */
diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c
new file mode 100644
index 000..ee3ebbe
--- /dev/null
+++ b/drivers/usb/dwc3/ulpi.c
@@ -0,0 +1,102 @@
+/**
+ * ulpi.c - DesignWare USB3 Controller's ULPI PHY interface
+ *
+ * Copyright (C) 2015 Intel Corporation
+ *
+ * Author: Heikki Krogerus heikki.kroge...@linux.intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public
[PATCH] usb: phy: never defer probe in non-OF case
In practice failure to find phy when requested in non-OF case means it will never become available, so __usb_find_phy() must return -ENODEV and not -EPROBE_DEFER. This fixes a regression caused by commit 9c9d82492b73991e8e13a6c0af06e44816c31438, where the USB controller driver is left infinitely into deferred probe when there are no phys. Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com --- drivers/usb/phy/phy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c index ccfdfb2..2f9735b 100644 --- a/drivers/usb/phy/phy.c +++ b/drivers/usb/phy/phy.c @@ -34,7 +34,7 @@ static struct usb_phy *__usb_find_phy(struct list_head *list, return phy; } - return ERR_PTR(-EPROBE_DEFER); + return ERR_PTR(-ENODEV); } static struct usb_phy *__usb_find_phy_dev(struct device *dev, -- 2.1.4 -- 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 3/3] phy: ulpi: add driver for TI TUSB1210
Hi, On Wed, Jan 21, 2015 at 11:17:49AM +0200, Heikki Krogerus wrote: On Tue, Jan 20, 2015 at 09:45:39AM -0600, Felipe Balbi wrote: diff --git a/drivers/phy/ulpi/tusb1210.c b/drivers/phy/ulpi/tusb1210.c new file mode 100644 index 000..ac77f98 --- /dev/null +++ b/drivers/phy/ulpi/tusb1210.c do you really need this extra ulpi directory ? I wonder if phy-tusb1210.c as a name would be enough. IMO grouping the ULPI PHY drivers and other ULPI bus code into separate folder from the start is the right thing to do. A correction to this comment. I probable don't need this folder. Like you said, phy-tusb1210.c should be enough.. snip In fact, we might decide to add an entire ULPI bus, eventually, though I'm still considering if there's any benefit to that. I don't think I understand this comment? ULPI bus is what I'm introducing in this set (the first patch in it)? ..I talked with Alex about this :). So I think the bus belongs under drivers/usb/core/ instead of driver/phy/. It's not really tied to the Generic PHY framework in any way, but ULPI is of course USB specific. Cheers, -- heikki -- 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 2/3] usb: dwc3: add ULPI interface support
On Tue, Jan 20, 2015 at 09:23:37AM -0600, Felipe Balbi wrote:
Hi,
On Tue, Jan 20, 2015 at 11:18:21AM +0200, Heikki Krogerus wrote:
Registers ULPI interface with the ULPI bus if HSPHY type is
ULPI.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
Cc: Felipe Balbi ba...@ti.com
you're doing quite a bit in a single patch...
---
drivers/usb/dwc3/Kconfig | 7
drivers/usb/dwc3/Makefile | 4 ++
drivers/usb/dwc3/core.c | 9 +++-
drivers/usb/dwc3/core.h | 22 ++
drivers/usb/dwc3/ulpi.c | 102
++
5 files changed, 143 insertions(+), 1 deletion(-)
create mode 100644 drivers/usb/dwc3/ulpi.c
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 58b5b2c..6d0c5e6 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -11,6 +11,13 @@ config USB_DWC3
if USB_DWC3
+config USB_DWC3_ULPI
+ bool Provide ULPI PHY Interface
+ depends on ULPI_PHY=y || ULPI_PHY=USB_DWC3
+ help
+ Select this if you have ULPI type PHY attached to your DWC3
+ controller.
+
choice
bool DWC3 Mode Selection
default USB_DWC3_DUAL_ROLE if (USB USB_GADGET)
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index bb34fbc..2fc44e0 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -16,6 +16,10 @@ ifneq ($(filter y,$(CONFIG_USB_DWC3_GADGET)
$(CONFIG_USB_DWC3_DUAL_ROLE)),)
dwc3-y += gadget.o ep0.o
endif
+ifneq ($(CONFIG_USB_DWC3_ULPI),)
+ dwc3-y += ulpi.o
+endif
+
ifneq ($(CONFIG_DEBUG_FS),)
dwc3-y += debugfs.o
endif
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 25ddc39..5219bc7 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -876,12 +876,17 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-hird_threshold = hird_threshold
| (dwc-is_utmi_l1_suspend 4);
+ platform_set_drvdata(pdev, dwc);
+
+ ret = dwc3_ulpi_init(dwc);
+ if (ret)
+ return ret;
+
ret = dwc3_core_get_phy(dwc);
if (ret)
return ret;
spin_lock_init(dwc-lock);
- platform_set_drvdata(pdev, dwc);
why do you need to move this ? Looks like this should be a cleanup and
split into a single patch.
OK.
it also appears that you need another patch moving dwc3_cache_hwparams()
before all of these other calls, so you can use it from
dwc3_ulpi_init().
OK.
@@ -965,6 +970,7 @@ err1:
err0:
dwc3_free_event_buffers(dwc);
+ dwc3_ulpi_exit(dwc);
return ret;
}
@@ -984,6 +990,7 @@ static int dwc3_remove(struct platform_device *pdev)
phy_power_off(dwc-usb3_generic_phy);
dwc3_core_exit(dwc);
+ dwc3_ulpi_exit(dwc);
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 0842aa8..f6881a6 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -32,6 +32,7 @@
#include linux/usb/otg.h
#include linux/phy/phy.h
+#include linux/phy/ulpi/interface.h
#define DWC3_MSG_MAX 500
@@ -174,6 +175,14 @@
#define DWC3_GUSB2PHYCFG_PHYSOFTRST(1 31)
#define DWC3_GUSB2PHYCFG_SUSPHY(1 6)
+/* Global USB2 PHY Vendor Control Register */
+#define DWC3_GUSB2PHYACC_NEWREGREQ (1 25)
+#define DWC3_GUSB2PHYACC_BUSY (1 23)
+#define DWC3_GUSB2PHYACC_WRITE (1 22)
+#define DWC3_GUSB2PHYACC_ADDR(n) (n 16)
+#define DWC3_GUSB2PHYACC_EXTEND_ADDR(n)(n 8)
+#define DWC3_GUSB2PHYACC_DATA(n) (n 0xff)
separate patch
OK.
@@ -590,6 +599,7 @@ struct dwc3_hwparams {
#define DWC3_NUM_INT(n)(((n) (0x3f 15)) 15)
/* HWPARAMS3 */
+#define DWC3_ULPI_HSPHY(1 3)
you also need a patch which defines this bit of HWPARAMS3. This is also
the wrong definition. Which core revision do you have ? I can see that
bit 3 is part of a 2 bit field called:
DWC_USB3_HSPHY_INTERFACE
I have the same in my databook. I agree, it's not good like that.
moreover, there are systems which have both ULPI and UTMI enabled and
you can't really know which one the PHY is using.
This needs a bit more thought.
Sure, I'll think of something better for this.
#define DWC3_NUM_IN_EPS_MASK (0x1f 18)
#define DWC3_NUM_EPS_MASK (0x3f 12)
#define DWC3_NUM_EPS(p)(((p)-hwparams3 \
@@ -739,6 +749,8 @@ struct dwc3 {
struct phy *usb2_generic_phy;
struct phy *usb3_generic_phy;
+ struct ulpi *ulpi;
+
void __iomem*regs;
size_t regs_size;
@@ -1035,4 +1047,14 @@ static inline int dwc3_gadget_resume
Re: [PATCH 3/3] phy: ulpi: add driver for TI TUSB1210
On Tue, Jan 20, 2015 at 09:45:39AM -0600, Felipe Balbi wrote:
Hi,
On Tue, Jan 20, 2015 at 11:18:22AM +0200, Heikki Krogerus wrote:
TUSB1210 ULPI PHY has vendor specific register for eye
diagram tuning. On some platforms the system firmware has
set optimized value to it. In order to not loose the
optimized value, the driver stores it during probe and
restores it every time the PHY is powered back on.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/phy/ulpi/Kconfig| 11
drivers/phy/ulpi/Makefile | 2 +
drivers/phy/ulpi/tusb1210.c | 131
3 files changed, 144 insertions(+)
create mode 100644 drivers/phy/ulpi/tusb1210.c
diff --git a/drivers/phy/ulpi/Kconfig b/drivers/phy/ulpi/Kconfig
index 8007df2..7cd6f82 100644
--- a/drivers/phy/ulpi/Kconfig
+++ b/drivers/phy/ulpi/Kconfig
@@ -7,3 +7,14 @@ config ULPI_PHY
Say yes if you have ULPI PHY attached to your USB controller.
If unsure, say N.
+
+if ULPI_PHY
+
+config ULPI_TUSB1210
+ tristate TI TUSB1210 USB PHY module
+ depends on POWER_SUPPLY
+ select USB_PHY
+ help
+ Support for TI TUSB1210 USB ULPI PHY.
+
+endif
diff --git a/drivers/phy/ulpi/Makefile b/drivers/phy/ulpi/Makefile
index 59e61cb..7ee6679 100644
--- a/drivers/phy/ulpi/Makefile
+++ b/drivers/phy/ulpi/Makefile
@@ -1,2 +1,4 @@
ulpiphy-y := ulpi.o
obj-$(CONFIG_ULPI_PHY) += ulpiphy.o
+
+obj-$(CONFIG_ULPI_TUSB1210)+= tusb1210.o
diff --git a/drivers/phy/ulpi/tusb1210.c b/drivers/phy/ulpi/tusb1210.c
new file mode 100644
index 000..ac77f98
--- /dev/null
+++ b/drivers/phy/ulpi/tusb1210.c
do you really need this extra ulpi directory ?
I wonder if phy-tusb1210.c as a name would be enough.
IMO grouping the ULPI PHY drivers and other ULPI bus code into
separate folder from the start is the right thing to do.
@@ -0,0 +1,131 @@
+/**
+ * tusb1210.c - TUSB1210 USB ULPI PHY driver
+ *
+ * Copyright (C) 2015 Intel Corporation
+ *
+ * Author: Heikki Krogerus heikki.kroge...@linux.intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include linux/module.h
+#include linux/phy/ulpi/driver.h
+#include linux/phy/ulpi/regs.h
+#include linux/gpio/consumer.h
+
+#include ulpi_phy.h
+
+struct tusb1210 {
+ struct ulpi *ulpi;
+ struct phy *phy;
+ struct gpio_desc *gpio_reset;
+ struct gpio_desc *gpio_cs;
+ u8 ctx[1];
+};
+
+static int tusb1210_power_on(struct phy *phy)
+{
+ struct tusb1210 *tusb = phy_get_drvdata(phy);
+
+ gpiod_set_value_cansleep(tusb-gpio_reset, 1);
+ gpiod_set_value_cansleep(tusb-gpio_cs, 1);
+
+ /* Restore eye optimisation value */
+ ulpi_write(tusb-ulpi, ULPI_EXT_VENDOR_SPECIFIC, tusb-ctx[0]);
+
+ return 0;
+}
+
+static int tusb1210_power_off(struct phy *phy)
+{
+ struct tusb1210 *tusb = phy_get_drvdata(phy);
+
+ gpiod_set_value_cansleep(tusb-gpio_reset, 0);
+ gpiod_set_value_cansleep(tusb-gpio_cs, 0);
+
+ return 0;
+}
+
+static struct phy_ops phy_ops = {
+ .power_on = tusb1210_power_on,
+ .power_off = tusb1210_power_off,
+ .init = tusb1210_power_on,
+ .exit = tusb1210_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int tusb1210_probe(struct ulpi *ulpi)
+{
+ struct gpio_desc *gpio;
+ struct tusb1210 *tusb;
+ int ret;
+
+ tusb = devm_kzalloc(ulpi-dev, sizeof(*tusb), GFP_KERNEL);
+ if (!tusb)
+ return -ENOMEM;
+
+ gpio = devm_gpiod_get(ulpi-dev, reset);
+ if (!IS_ERR(gpio)) {
+ ret = gpiod_direction_output(gpio, 0);
+ if (ret)
+ return ret;
+ tusb-gpio_reset = gpio;
+ }
+
+ gpio = devm_gpiod_get(ulpi-dev, cs);
+ if (!IS_ERR(gpio)) {
+ ret = gpiod_direction_output(gpio, 0);
+ if (ret)
+ return ret;
+ tusb-gpio_cs = gpio;
+ }
+
+ /* Store initial eye diagram optimisation value */
+ ret = ulpi_read(ulpi, ULPI_EXT_VENDOR_SPECIFIC);
do they *all* use this register for eye diagram optimization or is this
something that Intel decided to do ?
(sorry, don't know much about tusb1210 other than it sucks like hell :-)
All I know that somebody needs to save the value. The ones using this
PHY who don't need to save it can most likely live without the driver.
+ if (ret 0)
+ return ret;
+
+ tusb-ctx[0] = ret;
+
+ tusb-phy = ulpi_phy_create(ulpi, phy_ops);
+ if (IS_ERR(tusb-phy))
+ return PTR_ERR(tusb-phy);
+
+ tusb-ulpi = ulpi;
+
+ phy_set_drvdata(tusb-phy, tusb);
+ dev_set_drvdata(ulpi-dev, tusb
Re: [PATCH 6/8] usb: dwc3: add ULPI interface support
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index a8c9062..66cbf38 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -879,6 +879,10 @@ static int dwc3_probe(struct platform_device *pdev) platform_set_drvdata(pdev, dwc); dwc3_cache_hwparams(dwc); + ret = dwc3_ulpi_init(dwc); If I understood correctly, this call will result in enumerating the phy via ULPI bus, then registering the correct ULPI device. Can you guarantee ULPI will be always accessible at this point if we remove dwc3 module and load it again? OK, got it. So yes, I can guarantee that ULPI will be acessible at this point. If we are in a state where we could soft reset dwc3, we know we can access ULPI. The fact that dwc3 itself expects to be able to write to the ULPI registers at that point guarantees it for us. So in practice when ever dwc3 is powered we will be able to access ULPI for as long as the USB2 PHY interface is not suspended separately with GUSB2PHYCFG SusPHY bit. And even then we would only need to resume it with the same bit and ULPI is accessible again. Cheers, -- heikki -- 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/8] usb: add bus type for USB ULPI
On Thu, Feb 12, 2015 at 05:44:20PM -0800, Stephen Boyd wrote:
On 01/23/15 07:12, Heikki Krogerus wrote:
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index e614ef6..753cb08 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -1176,6 +1176,19 @@ static int do_rio_entry(const char *filename,
}
ADD_TO_DEVTABLE(rapidio, rio_device_id, do_rio_entry);
+/* Looks like: mei:S */
This comment doesn't look right.
Oops. Thanks for catching that one.
+static int do_ulpi_entry(const char *filename, void *symval,
+char *alias)
+{
+ DEF_FIELD(symval, ulpi_device_id, vendor);
+ DEF_FIELD(symval, ulpi_device_id, product);
+
+ sprintf(alias, ulpi:v%04xp%04x, vendor, product);
+
+ return 1;
+}
+ADD_TO_DEVTABLE(ulpi, ulpi_device_id, do_ulpi_entry);
--
heikki
--
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 8/8] phy: add driver for TI TUSB1210 ULPI PHY
On Mon, Jan 26, 2015 at 11:23:37AM -0800, David Cohen wrote:
On Mon, Jan 26, 2015 at 02:55:03PM +0200, Heikki Krogerus wrote:
On Sat, Jan 24, 2015 at 03:58:11PM -0800, David Cohen wrote:
+static int tusb1210_power_on(struct phy *phy)
+{
+ struct tusb1210 *tusb = phy_get_drvdata(phy);
+
+ gpiod_set_value_cansleep(tusb-gpio_reset, 1);
+ gpiod_set_value_cansleep(tusb-gpio_cs, 1);
+
+ /* Restore eye diagram optimisation value */
+ ulpi_write(tusb-ulpi, TUSB1210_VENDOR_SPECIFIC2,
+ tusb-eye_diagram_tuning);
After you power on phy, ulpi bus may not be available right away. In
intel case, phy power on happens during dwc3 power on. ULPI bus is not
available until OTG controller and phy are in sync.
In resume, you can't restore eye diagram from here.
I'm sorry but I don't think I understand? Where do we power on the phy
before dwc3 is powered on? Or is this a Baytrail-CR specific problem?
I can't see any problems with the hardware I have.
You can't see in single accesses. But you may see when running stability
tests overnight.
Anyway, look for dwc3_core_soft_reset() function:
- dwc3 goes to reset state
- phy is initialized (or at least gets ready to sync clocks)
- dwc3 goes out or reset state
And if you look at dwc3_probe, you'll notice that it calls
phy_power_on after that, and ulpi will most definitely be accessible
at that point.
I'm only using the init and exit hooks instead of just
power_on/power_off because I'm not sure which the controllers will
use. For example, now dwc3 calls phy_init() in it's resume routine and
not phy_power_on() like I would expect. I know the problem has been
pointed out by others, so I'm expecting we'll get guidelines for it
later. But before we do, I see no harm in having both init and
power_on hooks in this driver.
During tusb1210 phy init from dwc3, you shouldn't access ulpi bus.
We will end up executing one failed write followed by write that we
know will succeed. Ideally we didn't have to do the first one at all,
but I don't see any risk here.
+ gpio = devm_gpiod_get(ulpi-dev, cs);
+ if (!IS_ERR(gpio)) {
+ ret = gpiod_direction_output(gpio, 0);
+ if (ret)
+ return ret;
+ tusb-gpio_cs = gpio;
+ }
+
+ /* Store initial eye diagram optimisation value */
+ ret = ulpi_read(ulpi, TUSB1210_VENDOR_SPECIFIC2);
It's unclear if ulpi is accessible at this point. You can't read it at
this point.
We wouldn't have reached this point if ulpi wasn't accessible.
Registering the ulpi interface would have already failed so no driver
would have been probed.
You have a chicken/egg problem here:
- dwc3 needs phy to complete soft reset during probe
- tusb1210 needs dwc3 soft reset completed to be accessible via ULPI
Can you share how tusb1210 is connected on the platform you're using as
test for this patch? I don't think this driver would work reliably with
this device:
http://liliputing.com/2014/11/trekstor-launches-first-android-tablet-based-intels-irda-reference-design.html
The only reason why that board doesn't work is because of very much
Baytrail-CR specific problems. These are are two issues, but the first
one is critical for getting it working. Both will be handled, but
separately from this set:
1) The firmware leaves the PHY in reset, forcing us to enable it
somehow in OS before accessing ulpi. Unless we can get a firmware fix
for that (it's starting to look like it's not going to happen; please
correct me if you know something else!), we need to add a quirk for
Baytrails (attached), which is probable still OK. But IMO this really
should be fixed in the firmware.
2) Since the gpio resources are given to the controller device in ACPI
tables and there isn't separate device object for the PHY at all, we
need to deliver the gpios somehow separately to the phy driver. There
is a thread where we are talking about how to do that:
https://lkml.org/lkml/2014/12/18/82
Thanks,
--
heikki
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 8d95056..53902ea 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -21,6 +21,7 @@
#include linux/slab.h
#include linux/pci.h
#include linux/platform_device.h
+#include linux/gpio/consumer.h
#include platform_data.h
@@ -35,6 +36,24 @@
static int dwc3_pci_quirks(struct pci_dev *pdev)
{
+ if (pdev-vendor == PCI_VENDOR_ID_INTEL
+ pdev-device == PCI_DEVICE_ID_INTEL_BYT) {
+ struct gpio_desc *gpio;
+
+ gpio = gpiod_get_index(pdev-dev, reset, 0);
+ if (!IS_ERR(gpio)) {
+ gpiod_direction_output(gpio, 0);
+ gpiod_set_value_cansleep(gpio, 1);
+ gpiod_put(gpio
Re: [PATCH 6/8] usb: dwc3: add ULPI interface support
look at your patch again. In case DWC3_ULPI isn't enabled, this file won't be linked at all. You're using stubs, so taht's fine. In case it _is_ enabled, you're breaking out early if you can't register ulpi interface, meaning you're exitting probe() (which, in fact, seems wrong as I want to be able to run dwc3 with ULPI enabled on a platform that was configured with ULPI+UTMI, but uses UTMI PHY). I still think this patch won't work in all cases. OK. So in case of ULPI+UTMI we'll try the ulpi interface, and if it fails, fall back to UTMI. Or can we use some other method to determine to which interface the PHY is really attached to in that case? Thanks, -- heikki -- 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
