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 waiting
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 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 ma
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 s
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 to
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 fo
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 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 P
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 seem
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.
>
> Her
On 10/31/2013 08:12 PM, Ulrich Hecht wrote:
On Thu, Oct 31, 2013 at 12:43 PM, Valentine
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
On Thu, Oct 31, 2013 at 12:43 PM, Valentine
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 tell there are no other PCI busses i
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 Vale
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 Tuesd
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
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 ar
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
> >>PC
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 dr
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 PC
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
---
drivers/usb/phy/phy-rcar-gen2-us
20 matches
Mail list logo
