On Fri, Jan 4, 2013 at 2:10 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote: > These are minor cleanups for drm_pcie_get_speed_cap_mask() to use > standard #defines and PCIe capability accessors. They depend on > a pci_regs.h change (130f1b8f35) that appeared in v3.8-rc2. > > They don't address the issue of DRM devices directly below a host > bridge that doesn't appear as a PCI device (the issue Lucas has > been working on). > > I'm a little skeptical about the premise of drm_pcie_get_speed_cap_mask() > to begin with. Link speed seems like something fairly generic that should > be handled in the core, not in individual drivers. Sec 6.11, "Link Speed > Management", in the PCIe 3.0 spec seems relevant and suggests that the > hardware should automatically use the highest speed supported by both ends > of the link unless software sets a lower maximum via Target Link Speed. > > But I can't match up the code, e.g., evergreen_pcie_gen2_enable(), to > anything in the generic PCIe specs, so maybe this driver code is > essentially quirks for misbehaving hardware? At least for radeon, there is an asic specific sequence required to change the PCIE gen link speed at runtime. Depending on the bios, the board may come up in the highest mode supported by either side or something lower. If it comes up at a lower speed than the hardware is capable of, we can increase it in the driver to improve performance. Additionally, you can select a lower link speed to save power. I don't know if there is a generic non-asic specific way to change the link speed of a device at runtime, but I'm not really a PCI expert. Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
