On Jul 24, 2013, at 5:59 PM, "Tian, Feng" <feng.t...@intel.com> wrote:
> Sorry, Andrew.
>
> I don’t understand your point, where of XhciDxe current implementation is
> disobeying UEFI spec? Do I miss something?
>
> 2.6.3 Driver-Specific Elements:
> 12. If a driver is written for a PCI root bridge, then the
> EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL and the EFI_PCI_IO_PROTOCOL must be
> implemented.
>
> This sentence is from UEFI spec. My understanding is it defines the behavior
> of PCI_IO & PCI_ROOT_BRIDGE’s producer rather than the user.
I think there may be a missing requirement in the UEFI section 2.6.3 that if a
driver uses PCI it must use EFI_PCI_IO_PROTOCOL for IO. I was surprised there
was not a stronger statement about this that I could find. I'll take this issue
up with the UEFI Spec committee.
>
> I agree we should use PciIo->map schematic, it’s in our plan.
OK Thanks.
Andrew Fish
>
> Thanks
> Feng
>
> From: Andrew Fish [mailto:af...@apple.com]
> Sent: Thursday, July 25, 2013 8:41 AM
> To: Tian, Feng
> Cc: Cohen, Eugene; edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] XHCI DMA Buffer Issues
>
>
> On Jul 24, 2013, at 5:27 PM, "Tian, Feng" <feng.t...@intel.com> wrote:
>
>
> Hi, Eugene
>
> The EDKII XhciDxe driver doesn’t use PciIo.AllocateBuffer()/Map() to allocate
> DMA buffers. It’s mainly because EDKII is 1:1 mapping on Pci physical address
> and Cpu logical address for IA architecture. AllocateBuffer() is enough for
> current case.
>
>
> So as long as code runs an edk2 Intel/AMD CPU system it does not need to
> follow the UEFI spec? So if you had a uninitialized variable or a buffer that
> was just a random memory address you would not fix it if you were lucky and
> it worked on an edk2 Intel/AMD test system?
>
>
> We only implement this feature at EHCI driver as Andrew from Apple was trying
> to use this driver at an ARM based board “Beagle Board”.
>
> For which buffers to be mapped, I think all MMIO buffers specified in XHCI
> spec are required. For how to do this, please refer to EhciDxe driver.
>
> We ever constructed an non 1:1 mapping env at DUET, we mapped 0~1M to
> FFF00000~FFFFFFFF, other memory regions are shifted downwards with 1M offset.
> You can try this way.
>
>
> This is a violation of the UEFI 2.4 (all the way back to EFI 1.10)
> specification. Seems like we need to add an SCT for this.... Since folks seem
> to confuse passing the SCTs with following the spec.
>
> At a minimum you should update the comments in the driver to tell people that
> this is not a UEFI 2.4 (or even EFI 1.10) compatible driver.
>
> 2.6.3 Driver-Specific Elements:
> 12. If a driver is written for a PCI root bridge, then the
> EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL and the EFI_PCI_IO_PROTOCOL must be
> implemented.
>
> The driver needs to use the DMA scheme defined in the EFI_PCI_IO_PROTOCOL, it
> is not legal for a driver to makeup its own way to do DMA.
>
> Thanks,
>
> Andrew Fish
>
>
>
>
> Thanks
> Feng
>
> From: Cohen, Eugene [mailto:eug...@hp.com]
> Sent: Thursday, July 25, 2013 4:29 AM
> To: edk2-devel@lists.sourceforge.net
> Subject: [edk2] XHCI DMA Buffer Issues
>
> Dear XhciDxe Maintainer,
>
> I’m currently reviewing the XhciDxe driver and I’m trying to figure out how
> DMA buffers are allocated. I see a number of pool and page allocations but I
> do not see any called to PCI_IO Map()/Unmap() or to
> AllocateBuffer()/FreeBuffer().
>
> This appears to be violating the rules for PCI DMA buffers since they are not
> being mapped (and if common buffers are desired then they are also not being
> allocated with AllocateBuffer as required).
>
> Can someone more familiar with XHCI help me determine which buffers need to
> be mapped and how (BusMasterRead, BusMasterWrite, CommonBuffer)?
>
> It would be useful if we had a test environment that could catch driver DMA
> buffer mapping issues earlier. I think one way to do this would be set up
> the MMU in a non-identity mode so that anyone trying to use a processor
> virtual address for DMA would see a failure.
>
> Thanks,
>
> Eugene
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
