Skip to content

L
linux
Switch branch/tag
  1. 01 Mar, 2016 27 commits
  3. 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
  5. 26 Feb, 2016 10 commits
    • Dave Airlie's avatar
      Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into drm-next · 44ab4042
      Dave Airlie authored 
      As previously discussed, this is my first pull request for the DCU DRM
driver along with the change in MAINTAINERS.
https://lkml.org/lkml/2016/1/7/26

The pull contains some code cleanup changes (e.g. removing all error
handling for the regmap calls) and several fixes.

* 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu:
  drm/fsl-dcu: fix register initialization
  drm/fsl-dcu: use mode flags for hsync/vsync polarity
  drm/fsl-dcu: fix alpha blending
  drm/fsl-dcu: mask all interrupts on initialization
  drm/fsl-dcu: handle initialization errors properly
  drm/fsl-dcu: avoid memory leak on errors
  drm/fsl-dcu: remove regmap return value checks
  drm/fsl-dcu: specify volatile registers
  drm: fsl-dcu: Fix no fb check bug
  MAINTAINERS: update for Freescale DCU DRM driver
      44ab4042
    • Stefan Agner's avatar
      drm/fsl-dcu: fix register initialization · f76b9873
      Stefan Agner authored 
      The layer enumeration start with 0 (0-15 for LS1021a and 0-63 for
Vybrid) whereas the register enumeration start from 1 (1-10 for
LS1021a and 1-9 for Vybrid). The loop started off from 0 for both
iterations and initialized the number of layers inclusive, which
is one layer too many.

All extensively written registers seem to be unassigned, it seems
that the write to those registers did not do any harm in practice.
Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      f76b9873
    • Stefan Agner's avatar
      drm/fsl-dcu: use mode flags for hsync/vsync polarity · 4bc390c6
      Stefan Agner authored 
      The current default configuration is as follows:
- Invert VSYNC signal (active LOW)
- Invert HSYNC signal (active LOW)

The mode flags allow to specify the required polarity per
mode. Furthermore, none of the current driver settings is
actually a standard polarity.

This patch applies the current driver default polarities as
explicit flags to the display which has been introduced with
the driver (NEC WQVGA "nec,nl4827hc19-05b"). The driver now
also parses the flags field and applies the configuration
accordingly, by using the following values as standard
polarities: (e.g. when no flags are specified):
- VSYNC signal not inverted (active HIGH)
- HSYNC signal not inverted (active HIGH)
Acked-by: default avatarThierry Reding <treding@nvidia.com>
Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      4bc390c6
    • Stefan Agner's avatar
      drm/fsl-dcu: fix alpha blending · 69855819
      Stefan Agner authored 
      Fix alpha blending by enabling alpha blending for the whole frame if
a color mode with alpha channel is selected (DRM_FORMAT_ARGB*). Also
support color modes without alpha channel (DRM_FORMAT_XRGB*) by just
not enabling alpha blending on layer level.
Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      69855819
    • Stefan Agner's avatar
      drm/fsl-dcu: mask all interrupts on initialization · 638c93f6
      Stefan Agner authored 
      The state of the interrupt mask register on initialization is
unknown, e.g. U-Boot could already used the DCU. So depending on
the boot loader, the outcome of the interrupt mask register could
be different. A defined state is much more preferable. Also, there
is no value in keeping interrupts enabled which we don't need.
Therefor, mask all interrupts on initialization.
Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      638c93f6
    • Stefan Agner's avatar
      drm/fsl-dcu: handle initialization errors properly · 7566e247
      Stefan Agner authored 
      If initialization fails (e.g. due to missing panel node or deferred
probe) make sure to roll-back all operations and return the error
code.
Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      7566e247
    • Stefan Agner's avatar
      drm/fsl-dcu: avoid memory leak on errors · 72cc05a5
      Stefan Agner authored 
      Improve error handling during CRTC initialization. Especially avoid
memory leaks in the primary plane initialization error path.
Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      72cc05a5
    • Stefan Agner's avatar
      drm/fsl-dcu: remove regmap return value checks · e291d298
      Stefan Agner authored 
      It is not common to do regmap return value checks, especially not
for memory mapped device. We can rule out most error returns since
the conditions are static and we know they are ok (e.g. offset
aligned to register stride). Also without proper error handling
they are not really valuable for the user. Hence remove most of
them.

The check in the interrupt handler is worth keeping since a
volatile register won't be readable in case register caching is
still enabled.
Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      e291d298
    • Stefan Agner's avatar
      drm/fsl-dcu: specify volatile registers · efb8b491
      Stefan Agner authored 
      Since we are using cached registers, we need to specify volatile
registers explicitly to avoid reading their value from the cache.
This allows to read the correct interrupt status in fsl_dcu_drm_irq
and clear the asserted bits only.
Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      efb8b491
    • Meng Yi's avatar
      drm: fsl-dcu: Fix no fb check bug · a36c9867
      Meng Yi authored 
      For state->fb or state->crtc may be NULL in fsl_dcu_drm_plane_atomic_check
function, if so, return 0.
Signed-off-by: default avatarMeng Yi <meng.yi@nxp.com>
Signed-off-by: default avatarJianwei Wang <jianwei.wang.chn@gmail.com>
Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      a36c9867
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7