1. 01 Mar, 2016 11 commits
  2. 27 Feb, 2016 3 commits
    • Oded Gabbay's avatar
      drm/amdgpu: Return -EPROBE_DEFER when amdkfd not loaded · efb1c658
      Oded Gabbay authored
      amdgpu must load only after amdkfd's loading has been completed. If that
      is not enforced, then amdgpu's call into amdkfd's functions will cause a
      kernel BUG.
      
      When amdgpu and amdkfd are built as kernel modules, that rule is enforced
      by the kernel's modules loading mechanism. When amdgpu and amdkfd are
      built inside the kernel image, that rule is enforced by ordering in the
      drm Makefile (amdkfd before amdgpu).
      
      Instead of using drm Makefile ordering, we can now use deferred loading
      as amdkfd now returns -EPROBE_DEFER in kgd2kfd_init() when it is not yet
      loaded.
      
      This patch defers amdgpu loading by propagating -EPROBE_DEFER to the
      kernel's drivers loading infrastructure. That will put amdgpu into the
      pending drivers list (see description in dd.c). Once amdkfd is loaded,
      a call to kgd2kfd_init() will return successfully and amdgpu will be able
      to load.
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@gmail.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      efb1c658
    • Oded Gabbay's avatar
      drm/radeon: Return -EPROBE_DEFER when amdkfd not loaded · 412c8f7d
      Oded Gabbay authored
      radeon must load only after amdkfd's loading has been completed. If that
      is not enforced, then radeon's call into amdkfd's functions will cause a
      kernel BUG.
      
      When radeon and amdkfd are built as kernel modules, that rule is
      enforced by the kernel's modules loading mechanism. When radeon and
      amdkfd are built inside the kernel image, that rule is enforced by
      ordering in the drm Makefile (amdkfd before radeon).
      
      Instead of using drm Makefile ordering, we can now use deferred
      loading as amdkfd now returns -EPROBE_DEFER in kgd2kfd_init() when it is
      not yet loaded.
      
      This patch defers radeon loading by propagating -EPROBE_DEFER to the
      kernel's drivers loading infrastructure. That will put radeon into the
      pending drivers list (see description in dd.c). Once amdkfd is loaded,
      a call to kgd2kfd_init() will return successfully and radeon will be
      able to load.
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@gmail.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      412c8f7d
    • Oded Gabbay's avatar
      drm/amdkfd: Track when module's init is complete · c68f4528
      Oded Gabbay authored
      Current dependencies between amdkfd and radeon/amdgpu force the loading
      of amdkfd _before_ radeon and/or amdgpu are loaded. When all these kernel
      drivers are built as modules, this ordering is enforced by the kernel
      built-in mechanism of loading dependent modules.
      
      However, there is no such mechanism in case where all these drivers are
      compiled inside the kernel image (not as modules). The current way to
      enforce loading of amdkfd before radeon/amdgpu, is to put amdkfd before
      radeon/amdgpu in the drm Makefile, but that method is way too fragile.
      
      In addition, there is no kernel mechanism to check whether a kernel
      driver that is built inside the kernel image, has already been loaded.
      
      To solve this, this patch adds to kfd_module.c a new static variable,
      amdkfd_init_completed, that is set to 1 only when amdkfd's
      module initialization function has been completed (successfully).
      
      kgd2kfd_init(), which is the initialization function of the
      kgd-->kfd interface, and which is the first function in amdkfd called by
      radeon/amdgpu, will return successfully only if amdkfd_init_completed is
      equal 1.
      
      If amdkfd_init_completed is not equal to 1, kgd2kfd_init() will
      return -EPROBE_DEFER to signal radeon/amdgpu they need to defer
      their loading until amdkfd is loaded.
      Signed-off-by: default avatarOded Gabbay <oded.gabbay@gmail.com>
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      c68f4528
  3. 26 Feb, 2016 11 commits
  4. 25 Feb, 2016 1 commit
    • Dave Airlie's avatar
      Merge branch 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev into drm-next · 0041ee4d
      Dave Airlie authored
      rcar-du updates.
      
      * 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev: (281 commits)
        drm: rcar-du: Add tri-planar memory formats support
        drm: rcar-du: Add probe deferral debug messages
        drm: rcar-du: lvds: Add R-Car Gen3 support
        drm: rcar-du: lvds: Rename PLLEN bit to PLLON
        drm: rcar-du: lvds: Fix PLL frequency-related configuration
        drm: rcar-du: lvds: Avoid duplication of clock clamp code
        drm: rcar-du: Add R8A7795 device support
        drm: rcar-du: Output the DISP signal on the ODDF pin
        drm: rcar-du: Output the DISP signal on the DISP pin
        drm: rcar-du: Support up to 4 CRTCs
        drm: rcar-du: Drop LVDS double dependency on OF
        drm: rcar-du: Enable compilation on ARM64
        drm: rcar-du: Fix compile warning on 64-bit platforms
        drm: rcar-du: Expose the VSP1 compositor through KMS planes
        drm: rcar-du: Move plane allocator to rcar_du_plane.c
        drm: rcar-du: Restart the DU group when a plane source changes
        drm: rcar-du: Add VSP1 compositor support
        drm: rcar-du: Add VSP1 support to the planes allocator
        drm: rcar-du: Refactor plane setup
        drm: rcar-du: Compute plane DDCR4 register value directly
        ...
      0041ee4d
  5. 23 Feb, 2016 14 commits