Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 3月, 2016 27 次提交
  3. 28 2月, 2016 3 次提交
    • O
      drm/amdgpu: Return -EPROBE_DEFER when amdkfd not loaded · efb1c658
      由 Oded Gabbay 提交于 
      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: NOded Gabbay <oded.gabbay@gmail.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      efb1c658
    • O
      drm/radeon: Return -EPROBE_DEFER when amdkfd not loaded · 412c8f7d
      由 Oded Gabbay 提交于 
      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: NOded Gabbay <oded.gabbay@gmail.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      412c8f7d
    • O
      drm/amdkfd: Track when module's init is complete · c68f4528
      由 Oded Gabbay 提交于 
      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: NOded Gabbay <oded.gabbay@gmail.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      c68f4528
  5. 26 2月, 2016 10 次提交
    • D
      Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into drm-next · 44ab4042
      由 Dave Airlie 提交于 
      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
    • S
      drm/fsl-dcu: fix register initialization · f76b9873
      由 Stefan Agner 提交于 
      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: NStefan Agner <stefan@agner.ch>
      f76b9873
    • S
      drm/fsl-dcu: use mode flags for hsync/vsync polarity · 4bc390c6
      由 Stefan Agner 提交于 
      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: NThierry Reding <treding@nvidia.com>
Signed-off-by: NStefan Agner <stefan@agner.ch>
      4bc390c6
    • S
      drm/fsl-dcu: fix alpha blending · 69855819
      由 Stefan Agner 提交于 
      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: NStefan Agner <stefan@agner.ch>
      69855819
    • S
      drm/fsl-dcu: mask all interrupts on initialization · 638c93f6
      由 Stefan Agner 提交于 
      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: NStefan Agner <stefan@agner.ch>
      638c93f6
    • S
      drm/fsl-dcu: handle initialization errors properly · 7566e247
      由 Stefan Agner 提交于 
      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: NStefan Agner <stefan@agner.ch>
      7566e247
    • S
      drm/fsl-dcu: avoid memory leak on errors · 72cc05a5
      由 Stefan Agner 提交于 
      Improve error handling during CRTC initialization. Especially avoid
memory leaks in the primary plane initialization error path.
Signed-off-by: NStefan Agner <stefan@agner.ch>
      72cc05a5
    • S
      drm/fsl-dcu: remove regmap return value checks · e291d298
      由 Stefan Agner 提交于 
      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: NStefan Agner <stefan@agner.ch>
      e291d298
    • S
      drm/fsl-dcu: specify volatile registers · efb8b491
      由 Stefan Agner 提交于 
      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: NStefan Agner <stefan@agner.ch>
      efb8b491
    • M
      drm: fsl-dcu: Fix no fb check bug · a36c9867
      由 Meng Yi 提交于 
      For state->fb or state->crtc may be NULL in fsl_dcu_drm_plane_atomic_check
function, if so, return 0.
Signed-off-by: NMeng Yi <meng.yi@nxp.com>
Signed-off-by: NJianwei Wang <jianwei.wang.chn@gmail.com>
Signed-off-by: NStefan Agner <stefan@agner.ch>
      a36c9867