Of all the gin joints in all the towns in all the world, Laszlo Ersek had to walk into mine at 11:58:29 on Thursday 30 June 2016 and say:
> On 06/30/16 20:14, Brian J. Johnson wrote: > > On 06/30/2016 11:47 AM, Laszlo Ersek wrote: > >> On 06/30/16 18:39, Marcel Apfelbaum wrote: > >>> On 06/30/2016 07:21 PM, Marcel Apfelbaum wrote: > >>>> On 06/30/2016 04:07 PM, Laszlo Ersek wrote: > >>>>> Hi, [snip] > > We can safely skip > > allocating IO ports to those cards, saving significant space in the > > overall IO port map. We've worked with the card vendors on cleaning up > > their PCIe advertisements and eliminating the use of IO ports, but it > > takes time. > > I surprisingly often hear about non-conformance or unjustified > behavior... I guess with huge, elaborate specs, this is unavoidable. No > single programmer might be able to internalize it all. This is one of my pet peeves. Things that've thrown me for a loop are: - Customers with their own special PCI devices that want _enormous_ amounts of MMIO space -- there was one case recently where the device wanted an 8GB window. (Even if this is legal according to the spec, it strikes me as a little unfriendly.) - Oddball PCI/PCIe controller implementations in SoCs. For example, some devices implement support for MSI but don't support the ability to dynamically allocate interrupt vectors for multiple MSI sources. This means there's often just one vector for MSI events and it's shared by all devices on the bus. (The Freescale/NXP i.MX6 is one example of this.) - FPGA-based PCIe controller logic blocks. To be fair, I've only worked with one of these, namely the Xilinx Zynq7k. Maybe that one is just particularly irritating. Out of the box, the Zynq doesn't support PCIe: you have to load a bitstream file into it to make the internal FPGA think it's a PCIe controller. I think it's the case that the customer can customize the logic to add or remove features, probably to optimize the use of the available logic gates in the FPGA. Unfortunately this can make driver development difficult because it makes the "hardware" a moving target. It also means the "hardware" design might be kept very simple and a lot of heavy lifting is deferred to the driver software. The Zynq PCIe controller has only one interrupt vector, and it uses it for _all_ events (INTx interrupts, MSI interrupts and controller errors). For the INTx interrupts, you have to implement level-triggered interrupt semantics in software. If you do it wrong, you could miss an event and get totally stuck. (And last time I looked at it, I wasn't 100% convinced that the Linux driver was doing it exactly right either.) If you only ever want to connect one PCIe device to the controller, you can get away with some fairly simple logic, but hardly any of our customers would be satisfied with that. Also, the documentation for the PCIe controller block says that it supports both MMIO and I/O space BARs, but the particular bitstream file that I was given to work with only seemed to support MMIO. (The registers documented to configure the outbound window for I/O transactions didn't seem to do anything.) While I realize that I/O space BARs and INTx interrupts are old and busted and MMIO and MSI are the new hotness, we sometimes have customers with highly specialized legacy hardware and I would prefer not to throw a spanner in their works if I can avoid it. -Bill > Thanks! > Laszlo > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, wp...@windriver.com | Master of Unix-Fu - Wind River Systems ============================================================================= "I put a dollar in a change machine. Nothing changed." - George Carlin ============================================================================= _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
