On Aug 29, 2014, at 4:20 PM, Narinder Dhillon <[email protected]> wrote:
> Hi Andrew,
>
> You are correct, Once the hardware block is initialized, the controller is
> XHCI mode. Hence I was referring to the
> 'MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf' driver, this is exactly what I
> need. If the support and start methods of the driver binding protocol for
> this driver are called, it will quickly set everything up, as long as I can
> initialize the hardware before this.
>
> I was trying to avoid putting it in gEfiPciRootBridgeIoProtocolGuid driver
> because I would like to drop the driver if a board does not have any USB
> support. This way I don't touch the USB controller at all, if the driver for
> it is not included in UEFI image.
>
You can use a PCD feature flag in the driver to control the feature from the
platform .DSC file.
Thanks,
Andrew Fish
> Thank You.
>
>
> On Fri, Aug 29, 2014 at 4:06 PM, Andrew Fish <[email protected]> wrote:
>
> On Aug 29, 2014, at 3:48 PM, Narinder Dhillon <[email protected]> wrote:
>
>> Hi Andrew,
>>
>> We have a driver that implements gEfiPciRootBridgeIoProtocolGuid. So the
>> PCIe bus is being enumerated and the connect controller call is coming in.
>> Since there is a ready implementation of xHCI available, I am trying to
>> figure how to do it.
>>
>> If I implement a DXE driver, what protocol would I consume and what would I
>> produce so that the connect controller will go looking for protocols in the
>> USB stack ?
>> I apologize if the question sounds odd, just started working on UEFI
>> firmware.
>>
>
> It seems your hardware setup is putting the PCIe device into XHCI mode. Thus
> to me it seems like part of the driver for the SoC. The driver for the SoC
> would be driver producing gEfiPciRootBridgeIoProtocolGuid. So I would put it
> in the driver that produces gEfiPciRootBridgeIoProtocolGuid.
>
> I can’t give you a better answer unless you tell me what kind of setup is
> being done to the device.
>
> Thanks,
>
> Andrew Fish
>
>> Thank You.
>>
>>
>> On Fri, Aug 29, 2014 at 3:32 PM, Andrew Fish <[email protected]> wrote:
>>
>> On Aug 29, 2014, at 3:22 PM, Narinder Dhillon <[email protected]> wrote:
>>
>>> Hi All,
>>>
>>> I am trying to implement a USB driver for a xHCI controller that is sitting
>>> on a PCIe bus, on a ARM SoC. I was looking at the current implementations
>>> and saw that Beagle board has a similar implementation. Ideally, I would
>>> like to add these lines to my project files and it should work:
>>>
>>> INF MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
>>> INF MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
>>> INF MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
>>>
>>> The only issue is that I need to initialize the hardware block before this
>>> driver stack can use the hardware.
>>>
>>> My question is, where/how do I add this initialization sequence so that
>>> when connect controller call comes to this driver stack, it will recognize
>>> the xHCI controller and set everything up ?
>>>
>>
>> The generic answer is a DXE driver. A INF file with no [Depex] means wait
>> for all the EFI services are available before you load. The connect will
>> happen in the BDS, so after all the drivers have been dispatched. In the
>> driver model the 1st protocol in a connect sequence is always produced by a
>> DXE driver, as you need an existing handle to do the
>> gBS->ConnectController() on.
>>
>> What driver do you use to produce gEfiPciRootBridgeIoProtocolGuid? That is
>> the DXE driver that should be abstracting your PCIe bus. You could do it
>> there if it has a platform specific component, or build a DXE driver that
>> depends on gEfiPciRootBridgeIoProtocolGuid.
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>> Thank You.
>>> ------------------------------------------------------------------------------
>>> Slashdot TV.
>>> Video for Nerds. Stuff that matters.
>>> http://tv.slashdot.org/_______________________________________________
>>> edk2-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.
>> Video for Nerds. Stuff that matters.
>> http://tv.slashdot.org/
>> _______________________________________________
>> edk2-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.
>> Video for Nerds. Stuff that matters.
>> http://tv.slashdot.org/_______________________________________________
>> edk2-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds. Stuff that matters.
> http://tv.slashdot.org/_______________________________________________
> edk2-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
