On 11/01/2013 07:55 PM, Alan Stern wrote:
On Fri, 1 Nov 2013, Valentine wrote:
The USB HDC PCI deferred probing could be used on R-Car. But I'm not sure how
to make a particular
PCI USB HDC device attached to a particular PCI host controller on a particular
SoC defer its probing
while
On 10/31/2013 08:54 PM, Alan Stern wrote:
On Thu, 31 Oct 2013, Valentine wrote:
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
On Fri, 1 Nov 2013, Valentine wrote:
You need to tell usb_hcd_pci_probe() to wait for the PHY. That seems
to be the proper solution to your problem.
The difficulty is that you have a discoverable device (the PCI EHCI
controller) which needs to wait for a platform device (the PHY). The
On Fri, Nov 01, 2013 at 05:59:40PM +0400, Valentine wrote:
I'm not sure how this problem should be addressed using USB HCD PCI deferred
probing.
However, at the same time I see that six usb phy drivers use subsys_initcall
and one
uses postcore_initcall to adjust the initialization order.
On 11/01/2013 06:17 PM, Alan Stern wrote:
On Fri, 1 Nov 2013, Valentine wrote:
You need to tell usb_hcd_pci_probe() to wait for the PHY. That seems
to be the proper solution to your problem.
The difficulty is that you have a discoverable device (the PCI EHCI
controller) which needs to wait
On 11/01/2013 06:32 PM, Greg KH wrote:
On Fri, Nov 01, 2013 at 05:59:40PM +0400, Valentine wrote:
I'm not sure how this problem should be addressed using USB HCD PCI deferred
probing.
However, at the same time I see that six usb phy drivers use subsys_initcall
and one
uses postcore_initcall
On Fri, Nov 01, 2013 at 07:26:51PM +0400, Valentine wrote:
On 11/01/2013 06:32 PM, Greg KH wrote:
On Fri, Nov 01, 2013 at 05:59:40PM +0400, Valentine wrote:
I'm not sure how this problem should be addressed using USB HCD PCI
deferred probing.
However, at the same time I see that six usb phy
On Fri, Nov 01, 2013 at 07:04:00PM +0400, Valentine wrote:
We should implement a proper solution. One that can be used
everywhere, not an initcall-order hack.
That would be great, but I don't think we can implement a universal solution
for all of those drivers.
The solution that may suit
On Fri, 1 Nov 2013, Valentine wrote:
The USB HDC PCI deferred probing could be used on R-Car. But I'm not sure how
to make a particular
PCI USB HDC device attached to a particular PCI host controller on a
particular SoC defer its probing
while waiting for the USB phy. At the same time
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
On Thu, Oct 31, 2013 at 12:43 PM, Valentine
valentine.bars...@cogentembedded.com wrote:
Please, let me know if you see better options.
How about disregarding the whole PCI aspect? I mean, yes, those are
PCI busses, but they are internal, with a fixed set of devices
attached, and as far as I can
On 10/31/2013 08:12 PM, Ulrich Hecht wrote:
On Thu, Oct 31, 2013 at 12:43 PM, Valentine
valentine.bars...@cogentembedded.com wrote:
Please, let me know if you see better options.
How about disregarding the whole PCI aspect? I mean, yes, those are
PCI busses, but they are internal, with a
On Thu, 31 Oct 2013, Valentine wrote:
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
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
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
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
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.
Signed-off-by: Valentine Barshak valentine.bars...@cogentembedded.com
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
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
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
20 matches
Mail list logo
