[PATCH 0/3] drm_pcie_get_speed_cap_mask() cleanups

[Alex Deucher]

On Fri, Jan 4, 2013 at 2:10 PM, Bjorn Helgaas <bhelgaas at google.com> 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