On 10/31/2013 03:36 AM, Valentine wrote:
On 10/30/2013 06:12 PM, Greg KH wrote:
On Wed, Oct 30, 2013 at 01:56:25PM +0400, Valentine wrote:
On 10/30/2013 03:57 AM, Greg KH wrote:
On Tue, Oct 29, 2013 at 09:19:09PM +0400, Valentine wrote:
On 10/29/2013 09:00 PM, Laurent Pinchart wrote:
Hi Valentine,
Thank you for the patch.
On Tuesday 29 October 2013 20:21:06 Valentine Barshak wrote:
USB phy controls USB channels 0 and 2 which are shared between
PCI USB host controllers and USBHS/USBSS respectively.
This Initializes USB phy driver earlier because we need it
before PCI USB host controllers are initialized.
Can't you use deferred probing ?
No, unfortunately this doesn't work with PCI.
We need the USB PHY set up before the PCI driver starts.
PCI controllers should be initialized via subsys_initcall and can't be built as
a module.
Deferred probing is done at late_initcall and that's far too late in this case.
The MXS USB phy uses the similar approach, initializing the driver via
postcore_initcall.
I _HATE_ this "make this driver later than the others" mess. I'll not
This is actually "make this driver before the others" mess.
take patches that move drivers to different initcalls, sorry. Please
fix up the link order, or use deferred probing, as that is why it was
created.
This is needed for the PCI EHCI/OHCI drivers to operate correctly on R-Car Gen
platform
since it has built-in PCI host controllers that share USB I/O with USBHS/USBSS
devices.
The phy has to be configured before the PCI EHCI/OHCI devices are probed.
I'd really appreciate if you could give me a hint on how to fix the PCI
EHCI/OHCI driver
to use deferred probing, or fix the link order without creating a bigger mess.
Just change the PCI driver to use deferred probing, it isn't that hard
to do so.
Do you mean to change usb_hcd_pci_probe() to return -EPROBE_DEFER if the phy is
not ready?
Or should I defer the whole PCI subsystem initialization (pci_common_int)?
Greg,
the reason I ask is that it doesn't seem that simple to me.
Here's some details:
The h/w is an ARM SoC that has 3 internal PCI controllers with a single
EHCI/OHCI on each one.
This gives us 3 USB channels as this is called in the h/w manual.
Channel 0 is shared with USBHS (USB function) device.
Channel 2 is shared with USBSS (USB3.0 host).
Both channels are configured by a single USB phy.
USB PHY is a platform device, while EHCI/OCHI are located on the PCI busses.
If PCI USB host is probed before USB phy, the EHCI/OHCI device is detected, but
nothing works.
We could change the USB HDC PCI driver and make usb_hcd_pci_probe() return
-EPROBE_DEFER,
but I'm not sure how the condition for that should be phrased.
We could check the PCI vendor/device id, but there's no guarantee the same PCI
device
is not used on other Renesas h/w which do not require any PHY setup. More over
we only need
to setup the phy for the USB hosts connected to PCI controller 0/2.
We could try to defer the PCI driver and call pci_common_init() after the USB
phy is initialized.
However, it seems that it's gonna be a bigger mess.
1. We need to add custom PCI bus scan callback to the hw_pci structure.
We can't use default (pci_scan_root_bus) because it will try to probe/enable
pci devices before
their resources are fixed up when called late (after the PCI USB host drivers
are registered).
2. All of the internal PCI controllers are initialized using a single call to
the pci_common_init_dev().
So we can't easily defer just PCI controller 0/2. Even if we try to defer the
whole PCI subsystem
initialization, we probably need some sort of a dummy device that will defer
pci_common_init_dev call
untill USB phy is initialized.
3. The data structures and functions that are used to setup PCI are called at
subsys_init() and
marked __initdata/__init, so that we can easily get rid of them once the PCI is
registered.
Using deferred probe we'd need to keep them forever.
Using late_initcall() instead of subsys_initcall() for the PCI registration
might work
if we implement custom PCI bus scan callback,
But that's just doing the same thing that I've tried to do with USB phy here
with additional PCI bus scan quirk.
On the other hand, postcore_initcall is used in drivers/usb/phy/phy-mxs-usb.c
which is in your tree.
I agree that it's not that pretty, but it doesn't seem that bad considering
other options we have.
good luck,
Thanks,
Val.
Please, let me know if you see better options.
Thanks,
Val.
greg k-h
--
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
