Re: Adding OTG support to xHCI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sarah and Felipe,

> On Tue, Feb 14, 2012 at 06:15:38PM +0200, Felipe Balbi wrote:
>> Hi,
>>
>> On Tue, Feb 14, 2012 at 07:28:51AM -0800, Ido Shayevitz wrote:
>> > I am adding an otg driver for dwc3 core (hope that I will release it
>> for
>> > RFC soon) and I have some questions about the xHCI driver, since I
>> guess I
>> > need to do some changes in the xHCI to regirtser itself to the otg.
>>
>> xHCI should not register itself to the OTG, I think you're taking the
>> wrong approach. See the latest patch I sent creating the xHCI device for
>> use by the xhci-plat.c file.
>>
>> > First, I understand that there is secondary and primary hcd ? can you
>> give
>> > me more insight on this ?
>>
>> every USB3 roothub is composed of a SuperSpeed hub and a HS/FS/LS hub.
>
> That's how external USB 3.0 hubs work, but the roothub is really just
> one PCI device that handles both speeds.  We just had to break up the
> roothub into the HS and SS portions in order to allow khubd to treat it
> exactly like an external hub.
>
>> > Second, I see that in the xHCI-pci-probe the usb_add_hcd is called on
>> the
>> > secondary (right?) while the irq are set only if the hcd is primary
>> (so
>> > how it works?)
>
> The two roothubs are just a software abstraction layer, with one PCI
> device under it.  That's why we need to register just one IRQ (or one
> set of MSI-X interrupt vectors) for the PCI device.
>
>> > Do I need to change in the xhci-pci-probe to be something like this:
>> >
>> > otg = usb_get_transceiver();
>> > if (otg) {
>> >     retval = otg_set_host(otg, hcd_to_bus(xhci->shared_hcd));
>> > }
>>
>> this should not be added to xhci driver, not at all. You need to change
>> this mode waaaaay before when ID pin is grounded.
>>
>> I really wouldn't like seeing this kind of code added to the core xHCI
>> driver and I think Sarah wouldn't like it either.
>
> Felipe's right.  The xHCI driver should really be a general purpose
> driver, with embedded hosts that need to add functionality just calling
> the generic xHCI functions.  I don't want platform-specific code added
> to the xHCI host driver.  Otherwise we'll end up in the ifdeferry mess
> that EHCI grew over the years.

No problem, this is why I advice you, before I do this.
However , this is not a platform specific code, it is done also in ehci.
I mean, the "set_host" API is a generic one defined in otg.h as part of
the general otg framework, no pltaform specific.
Actually it will serve any otg driver, on any core that supports xHCI
interface, not just for the dwc3 core.
How do you suggest to do this otherwise?

> Sarah Sharp
>

Thanks,
Ido
-- 
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux