| Message ID | 1368424303-10629-5-git-send-email-chao.xie@marvell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, 13 May 2013, Chao Xie wrote: > Originaly, ehci driver will call the callbacks in platform data > for PHY initialization and shut down. > With PHY driver, it will call the APIs provided by PHY driver > for PHY initialization and shutdown. It removes the callbacks > in platform data, and at same time it removes one block in the > way of enabling device tree for ehci driver. I wonder if this is the sort of thing that should be handled in ehci-hcd.c rather than in all the different platform glue drivers. Felipe, what do you think? Are the required actions now sufficiently generic that a single source file can take care of them? Alan Stern
Hi, On Mon, May 13, 2013 at 10:13:44AM -0400, Alan Stern wrote: > On Mon, 13 May 2013, Chao Xie wrote: > > > Originaly, ehci driver will call the callbacks in platform data > > for PHY initialization and shut down. > > With PHY driver, it will call the APIs provided by PHY driver > > for PHY initialization and shutdown. It removes the callbacks > > in platform data, and at same time it removes one block in the > > way of enabling device tree for ehci driver. > > I wonder if this is the sort of thing that should be handled in > ehci-hcd.c rather than in all the different platform glue drivers. > > Felipe, what do you think? Are the required actions now sufficiently > generic that a single source file can take care of them? Sorry for the delay, was on business trip and now on vacations. Anyway, I agree with you. Our PHY layer should be generic enough that it should be usable by ehci-hcd itself. If we have any missing method, let's add it generically. cheers ps: dropping this from my queue for now.
On Wed, May 29, 2013 at 12:24 AM, Felipe Balbi <balbi@ti.com> wrote: > Hi, > > On Mon, May 13, 2013 at 10:13:44AM -0400, Alan Stern wrote: >> On Mon, 13 May 2013, Chao Xie wrote: >> >> > Originaly, ehci driver will call the callbacks in platform data >> > for PHY initialization and shut down. >> > With PHY driver, it will call the APIs provided by PHY driver >> > for PHY initialization and shutdown. It removes the callbacks >> > in platform data, and at same time it removes one block in the >> > way of enabling device tree for ehci driver. >> >> I wonder if this is the sort of thing that should be handled in >> ehci-hcd.c rather than in all the different platform glue drivers. >> >> Felipe, what do you think? Are the required actions now sufficiently >> generic that a single source file can take care of them? > > Sorry for the delay, was on business trip and now on vacations. Anyway, > I agree with you. Our PHY layer should be generic enough that it should > be usable by ehci-hcd itself. If we have any missing method, let's add > it generically. > So what are your idea about making the PHY layer more generic? How ehci-hcd will make use of PHY layer? > cheers > > ps: dropping this from my queue for now. > > -- > balbi
Hi, On Wed, May 29, 2013 at 11:58:01AM +0800, Chao Xie wrote: > On Wed, May 29, 2013 at 12:24 AM, Felipe Balbi <balbi@ti.com> wrote: > > Hi, > > > > On Mon, May 13, 2013 at 10:13:44AM -0400, Alan Stern wrote: > >> On Mon, 13 May 2013, Chao Xie wrote: > >> > >> > Originaly, ehci driver will call the callbacks in platform data > >> > for PHY initialization and shut down. > >> > With PHY driver, it will call the APIs provided by PHY driver > >> > for PHY initialization and shutdown. It removes the callbacks > >> > in platform data, and at same time it removes one block in the > >> > way of enabling device tree for ehci driver. > >> > >> I wonder if this is the sort of thing that should be handled in > >> ehci-hcd.c rather than in all the different platform glue drivers. > >> > >> Felipe, what do you think? Are the required actions now sufficiently > >> generic that a single source file can take care of them? > > > > Sorry for the delay, was on business trip and now on vacations. Anyway, > > I agree with you. Our PHY layer should be generic enough that it should > > be usable by ehci-hcd itself. If we have any missing method, let's add > > it generically. > > > So what are your idea about making the PHY layer more generic? How > ehci-hcd will make use of PHY layer? on probe grab the phy and initialize it. On suspend/resume, suspend/resume the PHY and so on. Whatever you were going to do on your ehci glue, do it on generic ehci-hcd.
On 05/29/2013 08:37 PM, Felipe Balbi wrote: > Hi, > > On Wed, May 29, 2013 at 11:58:01AM +0800, Chao Xie wrote: >> On Wed, May 29, 2013 at 12:24 AM, Felipe Balbi <balbi@ti.com> wrote: >>> Hi, >>> >>> On Mon, May 13, 2013 at 10:13:44AM -0400, Alan Stern wrote: >>>> On Mon, 13 May 2013, Chao Xie wrote: >>>> >>>>> Originaly, ehci driver will call the callbacks in platform data >>>>> for PHY initialization and shut down. >>>>> With PHY driver, it will call the APIs provided by PHY driver >>>>> for PHY initialization and shutdown. It removes the callbacks >>>>> in platform data, and at same time it removes one block in the >>>>> way of enabling device tree for ehci driver. >>>> >>>> I wonder if this is the sort of thing that should be handled in >>>> ehci-hcd.c rather than in all the different platform glue drivers. >>>> >>>> Felipe, what do you think? Are the required actions now sufficiently >>>> generic that a single source file can take care of them? >>> >>> Sorry for the delay, was on business trip and now on vacations. Anyway, >>> I agree with you. Our PHY layer should be generic enough that it should >>> be usable by ehci-hcd itself. If we have any missing method, let's add >>> it generically. >>> >> So what are your idea about making the PHY layer more generic? How >> ehci-hcd will make use of PHY layer? > > > on probe grab the phy and initialize it. On suspend/resume, > suspend/resume the PHY and so on. Whatever you were going to do on your > ehci glue, do it on generic ehci-hcd. > These operations sound generic enough to be done at HCD layer, no? So no need to replicate the same stuff in ohci, ehci, xhci, etc. cheers, -roger
On Thu, 30 May 2013, Roger Quadros wrote: > >> So what are your idea about making the PHY layer more generic? How > >> ehci-hcd will make use of PHY layer? > > > > > > on probe grab the phy and initialize it. On suspend/resume, > > suspend/resume the PHY and so on. Whatever you were going to do on your > > ehci glue, do it on generic ehci-hcd. > > > > These operations sound generic enough to be done at HCD layer, no? So no need to > replicate the same stuff in ohci, ehci, xhci, etc. The HCD layer handles suspend and resume only for PCI host controllers. Not for other types. I don't know if the acquire/start and stop/release parts can be moved into the USB core. Maybe they can. Alan Stern
On Thu, May 30, 2013 at 10:23 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Thu, 30 May 2013, Roger Quadros wrote: > >> >> So what are your idea about making the PHY layer more generic? How >> >> ehci-hcd will make use of PHY layer? >> > >> > >> > on probe grab the phy and initialize it. On suspend/resume, >> > suspend/resume the PHY and so on. Whatever you were going to do on your >> > ehci glue, do it on generic ehci-hcd. >> > >> >> These operations sound generic enough to be done at HCD layer, no? So no need to >> replicate the same stuff in ohci, ehci, xhci, etc. > > The HCD layer handles suspend and resume only for PCI host controllers. > Not for other types. > > I don't know if the acquire/start and stop/release parts can be moved > into the USB core. Maybe they can. > > Alan Stern > hi The following is my understanding. I think for PHY initialization and shutdown part, it is generic for other parts. PHY initialization need to be called before hc_driver->reset is called. I think it can be added at usb_add_hcd. For PHY shutdown, it can be added at usb_remove_hcd. For suspend/resume, i do not know how to add it. For our EHCI driver, when system goes to deep idle states, we just directly shutdown the hcd and initialize it again when the system goes back.
On Thu, 13 Jun 2013, Chao Xie wrote: > >> These operations sound generic enough to be done at HCD layer, no? So no need to > >> replicate the same stuff in ohci, ehci, xhci, etc. > > > > The HCD layer handles suspend and resume only for PCI host controllers. > > Not for other types. > > > > I don't know if the acquire/start and stop/release parts can be moved > > into the USB core. Maybe they can. > > > > Alan Stern > > > hi > The following is my understanding. > I think for PHY initialization and shutdown part, it is generic for > other parts. > PHY initialization need to be called before hc_driver->reset is called. > I think it can be added at usb_add_hcd. > For PHY shutdown, it can be added at usb_remove_hcd. Yes, that should work. > For suspend/resume, i do not know how to add it. For our EHCI driver, > when system goes to deep idle states, we just directly shutdown the > hcd and initialize it again when the system goes back. You shut down the host controller? Then how does it detect wakeup events? And how does it know if a device was disconnected while the power was off? Alan Stern
On Thu, Jun 13, 2013 at 11:08 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Thu, 13 Jun 2013, Chao Xie wrote: > >> >> These operations sound generic enough to be done at HCD layer, no? So no need to >> >> replicate the same stuff in ohci, ehci, xhci, etc. >> > >> > The HCD layer handles suspend and resume only for PCI host controllers. >> > Not for other types. >> > >> > I don't know if the acquire/start and stop/release parts can be moved >> > into the USB core. Maybe they can. >> > >> > Alan Stern >> > >> hi >> The following is my understanding. >> I think for PHY initialization and shutdown part, it is generic for >> other parts. >> PHY initialization need to be called before hc_driver->reset is called. >> I think it can be added at usb_add_hcd. >> For PHY shutdown, it can be added at usb_remove_hcd. > > Yes, that should work. > Fine, i can add a patch for that. My usb phy patches are pending on it. >> For suspend/resume, i do not know how to add it. For our EHCI driver, >> when system goes to deep idle states, we just directly shutdown the >> hcd and initialize it again when the system goes back. > > You shut down the host controller? Then how does it detect wakeup > events? And how does it know if a device was disconnected while the > power was off? > Hi I think maybe my suspend/resume is not same as what you think. The suspend/resume i mean is the peripharal sub system suspend/resume states. When SOC enter this low power mode, the clock to usb, power to usb are all shut down. When the controller is shut down, i think that usb_remove_hcd will help to remove all the attached devices. We do not rely on usb host controller to wake up the whole sub system. If a device is disconnected while the power was off, when the host controller is powered again, it will do initialization again, and all the attached devices are susposed be removed already. > Alan Stern >
On Fri, Jun 14, 2013 at 9:31 AM, Chao Xie <xiechao.mail@gmail.com> wrote: > On Thu, Jun 13, 2013 at 11:08 PM, Alan Stern <stern@rowland.harvard.edu> wrote: >> On Thu, 13 Jun 2013, Chao Xie wrote: >> >>> >> These operations sound generic enough to be done at HCD layer, no? So no need to >>> >> replicate the same stuff in ohci, ehci, xhci, etc. >>> > >>> > The HCD layer handles suspend and resume only for PCI host controllers. >>> > Not for other types. >>> > >>> > I don't know if the acquire/start and stop/release parts can be moved >>> > into the USB core. Maybe they can. >>> > >>> > Alan Stern >>> > >>> hi >>> The following is my understanding. >>> I think for PHY initialization and shutdown part, it is generic for >>> other parts. >>> PHY initialization need to be called before hc_driver->reset is called. >>> I think it can be added at usb_add_hcd. >>> For PHY shutdown, it can be added at usb_remove_hcd. >> >> Yes, that should work. >> > Fine, i can add a patch for that. My usb phy patches are pending on it. > >>> For suspend/resume, i do not know how to add it. For our EHCI driver, >>> when system goes to deep idle states, we just directly shutdown the >>> hcd and initialize it again when the system goes back. >> >> You shut down the host controller? Then how does it detect wakeup >> events? And how does it know if a device was disconnected while the >> power was off? >> > Hi > I think maybe my suspend/resume is not same as what you think. > The suspend/resume i mean is the peripharal sub system suspend/resume > states. When SOC enter this low power mode, > the clock to usb, power to usb are all shut down. > When the controller is shut down, i think that usb_remove_hcd will > help to remove all the attached devices. > We do not rely on usb host controller to wake up the whole sub system. > If a device is disconnected while the power was off, when the host > controller is powered again, it will do initialization again, and all > the attached devices are susposed be removed already. > > hi I am sorry that i unerstand it wrong. I checked with the code in our 3.4 git. we really did a lot of things when suspend/resume, and at that point the patch for ehci_resume and ehci_suspend are not added. i think the driver can make use of ehci_resume/ehci_suspend. For PHY, we have to initialize it and shutdown it when do suspend/resume. Our PHY do not have any suspend states. I suppose these phy operation have to be handled by each ehci driver owner only, or you think it can be handled at ehci-hce level?. >> Alan Stern >>
On 06/13/2013 06:08 PM, Alan Stern wrote: > On Thu, 13 Jun 2013, Chao Xie wrote: > >>>> These operations sound generic enough to be done at HCD layer, no? So no need to >>>> replicate the same stuff in ohci, ehci, xhci, etc. >>> >>> The HCD layer handles suspend and resume only for PCI host controllers. >>> Not for other types. >>> >>> I don't know if the acquire/start and stop/release parts can be moved >>> into the USB core. Maybe they can. >>> >>> Alan Stern >>> >> hi >> The following is my understanding. >> I think for PHY initialization and shutdown part, it is generic for >> other parts. >> PHY initialization need to be called before hc_driver->reset is called. >> I think it can be added at usb_add_hcd. >> For PHY shutdown, it can be added at usb_remove_hcd. > > Yes, that should work. I don't think this will work with OMAP USB host controller when used in Transceiver-less mode (e.g. HSIC). In this mode we need to release the HSIC reset (mapped to PHY init), after the EHCI controller is up and running. On the other hand, in the PHY mode, the PHY needs to be initialized (brought out of reset) before the EHCI controller starts. This behavior might be different on other controllers. Generalization is good as long as there is an override available for the controllers to handle the PHY init/shutdown themselves. > >> For suspend/resume, i do not know how to add it. For our EHCI driver, >> when system goes to deep idle states, we just directly shutdown the >> hcd and initialize it again when the system goes back. > > You shut down the host controller? Then how does it detect wakeup > events? And how does it know if a device was disconnected while the > power was off? > On OMAP as well we are aiming to cut clocks to the host controller (state saved) during bus/system suspend. PHY is in low power mode capable of detecting wakeup events. The SoC is configured to wake up on any I/O activity on the PHY pins. Upon detection of PHY related I/O event, SoC wakes up, we restore the host controller state and proceed as normal. cheers, -roger
On Fri, 14 Jun 2013, Roger Quadros wrote: > >> hi > >> The following is my understanding. > >> I think for PHY initialization and shutdown part, it is generic for > >> other parts. > >> PHY initialization need to be called before hc_driver->reset is called. > >> I think it can be added at usb_add_hcd. > >> For PHY shutdown, it can be added at usb_remove_hcd. > > > > Yes, that should work. > > I don't think this will work with OMAP USB host controller when used in > Transceiver-less mode (e.g. HSIC). In this mode we need to release the HSIC > reset (mapped to PHY init), after the EHCI controller is up and running. > > On the other hand, in the PHY mode, the PHY needs to be initialized (brought out > of reset) before the EHCI controller starts. In other words, transceiver-less mode effectively works without using a software-controlled PHY? > This behavior might be different on other controllers. Generalization is good > as long as there is an override available for the controllers to handle the > PHY init/shutdown themselves. To avoid PHY init/shutdown, the platform driver should simply leave the generic PHY pointer (which has not yet been added to struct hcd) set to NULL. > >> For suspend/resume, i do not know how to add it. For our EHCI driver, > >> when system goes to deep idle states, we just directly shutdown the > >> hcd and initialize it again when the system goes back. > > > > You shut down the host controller? Then how does it detect wakeup > > events? And how does it know if a device was disconnected while the > > power was off? > > > > On OMAP as well we are aiming to cut clocks to the host controller (state saved) > during bus/system suspend. PHY is in low power mode capable of detecting wakeup events. > The SoC is configured to wake up on any I/O activity on the PHY pins. Upon > detection of PHY related I/O event, SoC wakes up, we restore the host controller state > and proceed as normal. Maybe it's just me, but turning off USB Vbus power during suspend seems like a bad idea. Except for the case where all the root-hub ports are disabled (such as when no devices are plugged in) -- in that case it's fine. But turning off power to an enabled device should be avoided, even though the kernel does a decent job of recovering when this happens. Not all devices respond well to this sort of treatment. Alan Stern
On Fri, 14 Jun 2013, Chao Xie wrote: > I checked with the code in our 3.4 git. we really did a lot of things > when suspend/resume, and at that point the patch for ehci_resume and > ehci_suspend are not added. > i think the driver can make use of ehci_resume/ehci_suspend. > For PHY, we have to initialize it and shutdown it when do > suspend/resume. Our PHY do not have any suspend states. > I suppose these phy operation have to be handled by each ehci driver > owner only, or you think it can be handled at ehci-hce level?. If the operations are the same for each platform, then yes -- they could be done in ehci-hcd. But if different platforms handle their PHYs differently then each glue module will need to do this on its own. Alan Stern
On Sat, Jun 15, 2013 at 4:01 AM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Fri, 14 Jun 2013, Roger Quadros wrote: > >> >> hi >> >> The following is my understanding. >> >> I think for PHY initialization and shutdown part, it is generic for >> >> other parts. >> >> PHY initialization need to be called before hc_driver->reset is called. >> >> I think it can be added at usb_add_hcd. >> >> For PHY shutdown, it can be added at usb_remove_hcd. >> > >> > Yes, that should work. >> >> I don't think this will work with OMAP USB host controller when used in >> Transceiver-less mode (e.g. HSIC). In this mode we need to release the HSIC >> reset (mapped to PHY init), after the EHCI controller is up and running. >> >> On the other hand, in the PHY mode, the PHY needs to be initialized (brought out >> of reset) before the EHCI controller starts. > > In other words, transceiver-less mode effectively works without using a > software-controlled PHY? > >> This behavior might be different on other controllers. Generalization is good >> as long as there is an override available for the controllers to handle the >> PHY init/shutdown themselves. > > To avoid PHY init/shutdown, the platform driver should simply leave the > generic PHY pointer (which has not yet been added to struct hcd) set to > NULL. > So does it mean that i need add adtional usb_phy to struct hcd? I think we can still make use of struct hcd->phy without add addtional members. For OMAP transceiver-less mode, you can still use your own phy init/shutdown and leave the hcd->phy to be NULL, and for the PHY mode, hcd->phy can be set. It will do ->init at usb_add_hcd and ->shutdown at usb_remove_hcd. > > Alan Stern >
On 06/14/2013 11:01 PM, Alan Stern wrote: > On Fri, 14 Jun 2013, Roger Quadros wrote: > >>>> hi >>>> The following is my understanding. >>>> I think for PHY initialization and shutdown part, it is generic for >>>> other parts. >>>> PHY initialization need to be called before hc_driver->reset is called. >>>> I think it can be added at usb_add_hcd. >>>> For PHY shutdown, it can be added at usb_remove_hcd. >>> >>> Yes, that should work. >> >> I don't think this will work with OMAP USB host controller when used in >> Transceiver-less mode (e.g. HSIC). In this mode we need to release the HSIC >> reset (mapped to PHY init), after the EHCI controller is up and running. >> >> On the other hand, in the PHY mode, the PHY needs to be initialized (brought out >> of reset) before the EHCI controller starts. > > In other words, transceiver-less mode effectively works without using a > software-controlled PHY? > Right. >> This behavior might be different on other controllers. Generalization is good >> as long as there is an override available for the controllers to handle the >> PHY init/shutdown themselves. > > To avoid PHY init/shutdown, the platform driver should simply leave the > generic PHY pointer (which has not yet been added to struct hcd) set to > NULL. > >>>> For suspend/resume, i do not know how to add it. For our EHCI driver, >>>> when system goes to deep idle states, we just directly shutdown the >>>> hcd and initialize it again when the system goes back. >>> >>> You shut down the host controller? Then how does it detect wakeup >>> events? And how does it know if a device was disconnected while the >>> power was off? >>> >> >> On OMAP as well we are aiming to cut clocks to the host controller (state saved) >> during bus/system suspend. PHY is in low power mode capable of detecting wakeup events. >> The SoC is configured to wake up on any I/O activity on the PHY pins. Upon >> detection of PHY related I/O event, SoC wakes up, we restore the host controller state >> and proceed as normal. > > Maybe it's just me, but turning off USB Vbus power during suspend seems > like a bad idea. Except for the case where all the root-hub ports are > disabled (such as when no devices are plugged in) -- in that case it's > fine. We don't turn off Vbus power at all. Just the USB controller IPs clocks (internal to our SoC) are cut off. cheers, -roger
On Mon, 17 Jun 2013, Chao Xie wrote: > > To avoid PHY init/shutdown, the platform driver should simply leave the > > generic PHY pointer (which has not yet been added to struct hcd) set to > > NULL. > > > So does it mean that i need add adtional usb_phy to struct hcd? Ah, I was wrong. There already is a PHY pointer in struct usb_hcd. You don't need to add another one. > I think we can still make use of struct hcd->phy without add addtional members. > For OMAP transceiver-less mode, you can still use your own phy init/shutdown and > leave the hcd->phy to be NULL, and for the PHY mode, hcd->phy can be > set. It will > do ->init at usb_add_hcd and ->shutdown at usb_remove_hcd. That's right. Alan Stern
diff --git a/drivers/usb/host/ehci-mv.c b/drivers/usb/host/ehci-mv.c index 6bad41a..adfc11f 100644 --- a/drivers/usb/host/ehci-mv.c +++ b/drivers/usb/host/ehci-mv.c @@ -15,17 +15,18 @@ #include <linux/clk.h> #include <linux/err.h> #include <linux/usb/otg.h> +#include <linux/usb/mv_usb2.h> #include <linux/platform_data/mv_usb.h> #define CAPLENGTH_MASK (0xff) struct ehci_hcd_mv { struct usb_hcd *hcd; + struct usb_phy *phy; /* Which mode does this ehci running OTG/Host ? */ int mode; - void __iomem *phy_regs; void __iomem *cap_regs; void __iomem *op_regs; @@ -48,22 +49,15 @@ static void ehci_clock_disable(struct ehci_hcd_mv *ehci_mv) static int mv_ehci_enable(struct ehci_hcd_mv *ehci_mv) { - int retval; - ehci_clock_enable(ehci_mv); - if (ehci_mv->pdata->phy_init) { - retval = ehci_mv->pdata->phy_init(ehci_mv->phy_regs); - if (retval) - return retval; - } - return 0; + return usb_phy_init(ehci_mv->phy); } static void mv_ehci_disable(struct ehci_hcd_mv *ehci_mv) { - if (ehci_mv->pdata->phy_deinit) - ehci_mv->pdata->phy_deinit(ehci_mv->phy_regs); + usb_phy_shutdown(ehci_mv->phy); + ehci_clock_disable(ehci_mv); } @@ -169,22 +163,7 @@ static int mv_ehci_probe(struct platform_device *pdev) goto err_clear_drvdata; } - r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phyregs"); - if (r == NULL) { - dev_err(&pdev->dev, "no phy I/O memory resource defined\n"); - retval = -ENODEV; - goto err_clear_drvdata; - } - - ehci_mv->phy_regs = devm_ioremap(&pdev->dev, r->start, - resource_size(r)); - if (ehci_mv->phy_regs == 0) { - dev_err(&pdev->dev, "failed to map phy I/O memory\n"); - retval = -EFAULT; - goto err_clear_drvdata; - } - - r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "capregs"); + r = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!r) { dev_err(&pdev->dev, "no I/O memory resource defined\n"); retval = -ENODEV; @@ -199,6 +178,14 @@ static int mv_ehci_probe(struct platform_device *pdev) goto err_clear_drvdata; } + ehci_mv->phy = devm_usb_get_phy_dev(&pdev->dev, MV_USB2_PHY_INDEX); + if (IS_ERR_OR_NULL(ehci_mv->phy)) { + retval = PTR_ERR(ehci_mv->phy); + if (retval != -EPROBE_DEFER) + dev_err(&pdev->dev, "failed to get the outer phy\n"); + goto err_clear_drvdata; + } + retval = mv_ehci_enable(ehci_mv); if (retval) { dev_err(&pdev->dev, "init phy error %d\n", retval); @@ -225,14 +212,15 @@ static int mv_ehci_probe(struct platform_device *pdev) ehci_mv->mode = pdata->mode; if (ehci_mv->mode == MV_USB_MODE_OTG) { - ehci_mv->otg = devm_usb_get_phy(&pdev->dev, USB_PHY_TYPE_USB2); + ehci_mv->otg = devm_usb_get_phy_dev(&pdev->dev, + MV_USB2_OTG_PHY_INDEX); if (IS_ERR(ehci_mv->otg)) { retval = PTR_ERR(ehci_mv->otg); if (retval == -ENXIO) dev_info(&pdev->dev, "MV_USB_MODE_OTG " "must have CONFIG_USB_PHY enabled\n"); - else + else if (retval != -EPROBE_DEFER) dev_err(&pdev->dev, "unable to find transceiver\n"); goto err_disable_clk; @@ -259,9 +247,6 @@ static int mv_ehci_probe(struct platform_device *pdev) } } - if (pdata->private_init) - pdata->private_init(ehci_mv->op_regs, ehci_mv->phy_regs); - dev_info(&pdev->dev, "successful find EHCI device with regs 0x%p irq %d" " working in %s mode\n", hcd->regs, hcd->irq,
Originaly, ehci driver will call the callbacks in platform data for PHY initialization and shut down. With PHY driver, it will call the APIs provided by PHY driver for PHY initialization and shutdown. It removes the callbacks in platform data, and at same time it removes one block in the way of enabling device tree for ehci driver. Signed-off-by: Chao Xie <chao.xie@marvell.com> --- drivers/usb/host/ehci-mv.c | 49 +++++++++++++++---------------------------- 1 files changed, 17 insertions(+), 32 deletions(-)