Honour display's request for min engine clock/memory clock.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Revert "drm/amd/display: Remove call to amdgpu_pm_compute_clocks"
This reverts commit dcd473770e86517543691bdb227103d6c781cd0a.
when display configuration changes, dc need to update the changes
to powerplay, also need to trigger a power state task.
amdgpu_pm_compute_clocks is the interface to set power state task
either dpm enabled or powerplay enabled
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
one fix to get a proper DMA configuration in place for the etnaviv
virtual device. I'm sending this as a fix, as a dma-mapping change at
the ARC architecture side during the 4.19 cycle broke etnaviv on this
platform, which gets remedied with this patch, but it also enables
ARM64.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Lucas Stach <l.stach@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/ea1f712bf09bf9439c6b092bf2c2bde7bb01cf5e.camel@pengutronix.de
This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180926114312.23097-1-tzimmermann@suse.de
The lcdif block is only powered on when display is active so plane
updates when not enabled are not valid. Writing to an unpowered IP block
is mostly ignored but can trigger bus errors on some chips.
Prevent this situation by switching to drm_atomic_helper_commit_tail_rpm
and having the drm core ensure atomic_plane_update is only called while
the crtc is active. This avoids having to keep track of "enabled" bits
inside the mxsfb driver.
This also requires handling the vblank event for disable from
mxsfb_pipe_disable.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Suggested-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/c19c0c00ed42e8e8f7965aa4821ac295abc5cd05.1537191359.git.leonard.crestez@nxp.com
Adding lcdif nodes to a power domain currently results in
black/corrupted screens or hangs because power is not correctly enabled
when required.
Ensure power is on when display is active by adding
pm_runtime_get/put_sync to mxsfb_pipe_enable/disable.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/ee88148399c63494cda4129b05444b0ac331b7a7.1537191359.git.leonard.crestez@nxp.com
LCDIF will repeatedly display data from CUR_BUF and set CUR_BUF to
NEXT_BUF when done. Since we are only ever writing to NEXT_BUF the
display will show an initial corrupt frame.
Fix by writing the FB paddr to both CUR_BUF and NEXT_BUF when
activating the CRTC.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/7cdac9c064cc2b8a3d237934f186da98cefe6cb3.1537191359.git.leonard.crestez@nxp.com
The main axi clk is disabled at the end of mxsfb_crtc_mode_set_nofb and
immediately reenabled in mxsfb_enable_controller.
Avoid this by moving the handling of axi clk one level up to
mxsfb_crtc_enable. Do the same for mxsfb_crtc_disable for symmetry.
This shouldn't have any functional effect.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/985c1f1cad250bd9ca154b3e4b3f913c310eeabd.1537191359.git.leonard.crestez@nxp.com
All Tegra DRM devices are getting attached to an implicit IOMMU DMA
domain if CONFIG_ARM_DMA_USE_IOMMU=y. Since Tegra DRM driver manages IOMMU
by itself, the devices must be detached from the implicit domain using
arch-specific IOMMU-API. Note that this works only for arm32 and not for
arm64, which will remain broken if CONFIG_IOMMU_DMA is enabled.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Host1x is getting attached to an implicit IOMMU DMA domain if
CONFIG_ARM_DMA_USE_IOMMU=y. Since Host1x driver manages IOMMU by
itself, Host1x device must be detached from the implicit domain using
arch-specific IOMMU-API.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180926115640.24755-1-tzimmermann@suse.de
We attempt to get fences earlier in the hopes that everything will
already have fences and no callbacks will be needed. If we do succeed
in getting a fence, getting one a second time will result in a duplicate
ref with no unref. This is causing memory leaks in Vulkan applications
that create a lot of fences; playing for a few hours can, apparently,
bring down the system.
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107899
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180926071703.15257-1-jason.ekstrand@intel.com
All other assignments have a single space around the = sign, so remove
the spurious tab for consistency.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The SOR implemented in Tegra194 is subtly different from its predecessor
found in Tegra186. Most notably some registers have been moved around so
it is no longer compatible.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The display hub integrated into Tegra194 is almost identical to the one
found on Tegra186. However, it doesn't support DSC (display stream
compression) so it isn't fully compatible.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra194 contains a fourth display controller that does not own any
windows. Therefore, we cannot currently assign a primary plane to it
which causes KMS to eventually crash. Do not register the display
controller if it owns no windows to work around this.
Note that we still have to enable and probe the display controller
because for some reason all display controllers need to be powered
(and/or clocked) before any registers can be accessed in any of the
display controllers.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180926120212.25359-1-tzimmermann@suse.de
Implement vmap/vunmap so we can export dmabufs to
other drivers, such as video4linux.
Tested with a virtio-gpu / vivid (virtual capture driver)
pipeline, where the vivid driver imports the dmabufs exported
by virtio-gpu.
Note that dma_buf_vmap() does its own vmap counting, so
it's not needed to take care of it in the driver.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20180925161606.17980-4-ezequiel@collabora.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Currently, virtio_gpu_object_kmap() is only called by
virtio_gpufb_create(), when a DRM framebuffer is created.
Thus, instead of returning the vmap'ed address, emit a warning
if virtio_gpu_object_kmap is called on an already mapped
object. With this change, kmap/kunmap calls are now balanced.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20180925161606.17980-3-ezequiel@collabora.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The function ttm_bo_put releases a reference to a TTM buffer object. The
function's name is more aligned to the Linux kernel convention of naming
ref-counting function _get and _put.
A call to ttm_bo_unref takes the address of the TTM BO object's pointer and
clears the pointer's value to NULL. This is not necessary in most cases and
sometimes even worked around by the calling code. A call to ttm_bo_put only
releases the reference without clearing the pointer.
The current behaviour of cleaning the pointer is kept in the calling code,
but should be removed if not required in a later patch.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Xinliang Liu <z.liuxinliang@hisilicon.com>
Signed-off-by: Xinliang Liu <z.liuxinliang@hisilicon.com>
This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Xinliang Liu <z.liuxinliang@hisilicon.com>
Signed-off-by: Xinliang Liu <z.liuxinliang@hisilicon.com>
convert drm_atomic_helper_suspend/resume() to use
drm_mode_config_helper_suspend/resume().
Fixed one sparse warning by making hibmc_drm_interrupt
static.
Signed-off-by: Ajit Negi <ajitn.linux@gmail.com>
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Xinliang Liu <z.liuxinliang@hisilicon.com>
Signed-off-by: Xinliang Liu <z.liuxinliang@hisilicon.com>
Switch to use Huawei PCI vendor ID macro from pci_ids.h file.
In addition, switch to use PCI_VDEVICE() instead of open coding.
Signed-off-by: John Garry <john.garry@huawei.com>
Reviewed-by: Xinliang Liu <z.liuxinliang@hisilicon.com>
Signed-off-by: Xinliang Liu <z.liuxinliang@hisilicon.com>
Currently the driver overwrites the surface depth provided by the fb
helper to give an invalid bpp/surface depth combination.
This has been exposed by commit 70109354fe ("drm: Reject unknown legacy
bpp and depth for drm_mode_addfb ioctl"), which now causes the driver to
fail to probe.
Fix by not overwriting the surface depth.
Fixes: d1667b8679 ("drm/hisilicon/hibmc: Add support for frame buffer")
Signed-off-by: John Garry <john.garry@huawei.com>
Reviewed-by: Xinliang Liu <z.liuxinliang@hisilicon.com>
Signed-off-by: Xinliang Liu <z.liuxinliang@hisilicon.com>
Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Both DRM_FORMAT_* and VIRTIO_GPU_FORMAT_* are defined to be little
endian, so using a different mapping on bigendian machines is wrong.
It's there because of broken drm_mode_addfb() behavior. So with
drm_mode_addfb() being fixed we can fix this too.
While wading through the code I've noticed we have a little issue in
virtio: We attach a format to the bo when it is created
(DRM_IOCTL_MODE_CREATE_DUMB), not when we map it as framebuffer
(DRM_IOCTL_MODE_ADDFB). Easy way out: Support a single format only.
Pick DRM_FORMAT_HOST_XRGB8888, it is the only one actually used in
practice. Drop unused mappings in virtio_gpu_translate_format().
With this patch applied both ADDFB and ADDFB2 ioctls work correctly in
the virtio-gpu.ko driver on big endian machines. Without the patch only
ADDFB (which still seems to be used by the majority of userspace) works
correctly.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20180921134704.12826-6-kraxel@redhat.com
Add bochs_hw_set_*_endian() helper functions, to set the framebuffer
byteorder at mode set time. Support both DRM_FORMAT_XRGB8888 and
DRM_FORMAT_BGRX8888 framebuffer formats, no matter what the native
machine byte order is.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20180921134704.12826-5-kraxel@redhat.com
Use DRM_FORMAT_HOST_XRGB8888, so we are using the correct format code
on bigendian machines. Also set the quirk_addfb_prefer_host_byte_order
mode_config bit so drm_mode_addfb() asks for the correct format code.
Create our own plane and use drm_crtc_init_with_planes() instead of
depending on the default created by drm_crtc_init(). That way the plane
format list is correct on bigendian machines.
Also re-add the framebuffer format check dropped by "df2052cc92 bochs:
convert to drm_fb_helper_fbdev_setup/teardown".
With this patch applied both ADDFB and ADDFB2 ioctls work correctly in
the bochs-drm.ko driver on big endian machines. Without the patch only
ADDFB (which still seems to be used by the majority of userspace) works
correctly.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20180921134704.12826-4-kraxel@redhat.com
Creating framebuffers for fbdev emulation should use the correct format
code too, so switch drm_gem_fbdev_fb_create() over to use the new
drm_driver_legacy_fb_format() function.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20180921134704.12826-3-kraxel@redhat.com
Turns out we need the pixel format fixup not only for the addfb ioctl,
but also for fbdev emulation code.
Ideally we would place it in drm_mode_legacy_fb_format(). That would
create alot of churn though, and most drivers don't care because they
never ever run on a big endian platform. So add a new
drm_driver_legacy_fb_format() function instead which looks at the
mode_config->quirk_addfb_prefer_host_byte_order flag.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20180921134704.12826-2-kraxel@redhat.com
Pass virtio_gpu_object down to virtio_gpu_cmd_transfer_to_host_2d and
virtio_gpu_cmd_transfer_to_host_3d functions, instead of passing just
the virtio resource handle.
This is needed to lookup the scatter list of the object, for dma sync.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jiandi An <jiandi.an@amd.com>
Tested-by: Jiandi An <jiandi.an@amd.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20180920062924.6514-1-kraxel@redhat.com
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180908134648.2582-20-noralf@tronnes.org
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
drm_fbdev_generic_setup() handles mode_config.num_connector being zero.
In that case it retries fbdev setup on the next .output_poll_changed.
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20180908134648.2582-19-noralf@tronnes.org
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180908134648.2582-18-noralf@tronnes.org
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
If drm_fbdev_generic_setup() fails, an error is printed by the function.
drm_fbdev_generic_setup() handles mode_config.num_connector being zero.
In that case it retries fbdev setup on the next .output_poll_changed.
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180908134648.2582-14-noralf@tronnes.org
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20180908134648.2582-13-noralf@tronnes.org
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
CONFIG_DRM_FBDEV_EMULATION wasn't honoured by the CMA helper, but it is by
drm_fb_helper.
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180908134648.2582-12-noralf@tronnes.org
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180908134648.2582-10-noralf@tronnes.org
The CMA helper is already using the drm_fb_helper_generic_probe part of
the generic fbdev emulation. This patch makes full use of the generic
fbdev emulation by using its drm_client callbacks. This means that
drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
now handled by the emulation code. Additionally fbdev unregister happens
automatically on drm_dev_unregister().
The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
driver. This is done to highlight the fact that fbdev emulation is an
internal client that makes use of the driver, it is not part of the
driver as such. If fbdev setup fails, an error is printed, but the driver
succeeds probing.
Cc: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180908134648.2582-9-noralf@tronnes.org
Improve error reporting in drm_fb_helper_fbdev_setup() by printing the
error code. This is useful for drivers that choose to not fall over just
because fbdev doesen't work, but still wants clues to why it failed.
This way they don't have to provide an error message themselves.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180908134648.2582-2-noralf@tronnes.org
Add support for the R-Car D3 (R8A77995) and E3 (R8A77990) SoCs to the
R-Car DU driver. The two SoCs instantiate compatible DUs, so a single
information structure is enough.
Signed-off-by: Ulrich Hecht <uli+renesas@fpond.eu>
[Add support for R8A77990]
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
The official way to stop the display is to clear the display enable
(DEN) bit in the DSYSR register, but that operates at a group level and
affects the two channels in the group. To disable channels selectively,
the driver uses TV sync mode that stops display operation on the channel
and turns output signals into inputs.
While TV sync mode is available in all DU models currently supported,
the D3 and E3 DUs don't support it. We will thus need to find an
alternative way to turn channels off.
In the meantime, condition the switch to TV sync mode to the
availability of the feature, to avoid writing an invalid value to the
DSYSR register. When the feature is unavailable the display output will
turn blank as all planes are disabled when stopping the CRTC.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
DSYSR is a DU channel register that also contains group fields. It is
thus written to by both the group and CRTC code, using read-update-write
sequences. As the register isn't initialized explicitly at startup time,
this can lead to invalid or otherwise unexpected values being written to
some of the fields if they have been modified by the firmware or just
not reset properly.
To fix this we can write a fully known value to the DSYSR register when
turning a channel's functional clock on. However, the mix of group and
channel fields complicate this. A simpler solution is to cache the
register and initialize the cached value to the desired hardware
defaults.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
All Gen3 SoCs supported so far have a fixed association between DPAD0
and DU channels, which led to hardcoding that association when writing
the corresponding hardware register. The D3 and E3 will break that
mechanism as DPAD0 can be dynamically connected to either DU0 or DU1.
Make DPAD0 routing dynamic on Gen3. To ensure a valid hardware
configuration when the DU starts without the RGB output enabled, DPAD0
is associated at initialization time to the first DU channel that it can
be connected to. This makes no change on Gen2 as all Gen2 SoCs can
connected DPAD0 to DU0, which is the current implicit default value.
As the DPAD0 source is always 0 when a single source is possible on
Gen2, we can also simplify the Gen2 code in the same function to remove
a conditional check.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
On selected SoCs, the DU can use the clock output by the LVDS encoder
PLL as its input dot clock. This feature is optional, but on the D3 and
E3 SoC it is often the only way to obtain a precise dot clock frequency,
as the other available clocks (CPG-generated clock and external clock)
usually have fixed rates.
Add a DU model information field to describe which DU channels can use
the LVDS PLL output clock as their input clock, and configure clock
routing accordingly.
This feature is available on H2, M2-W, M2-N, D3 and E3 SoCs, with D3 and
E3 being the primary targets. It is left disabled in this commit, and
will be enabled per-SoC after careful testing.
At the hardware level, clock routing is configured at runtime in two
steps, first selecting an internal dot clock between the LVDS PLL clock
and the external DOTCLKIN clock, and then selecting between the internal
dot clock and the CPG-generated clock. The first part requires stopping
the whole DU group in order for the change to take effect, thus causing
flickering on the screen. For this reason we currently hardcode the
clock source to the LVDS PLL clock if available, and allow flicker-free
selection of the external DOTCLKIN clock or CPG-generated clock
otherwise. A more dynamic clock selection process can be implemented
later if the need arises.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
The rcar_du_crtc_get() function is always immediately followed by a call
to rcar_du_crtc_setup(). Call the later from the former to simplify the
code, and add a comment to explain how the get and put calls are
balanced.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
The LVDS encoders in the D3 and E3 SoCs differ significantly from those
in the other R-Car Gen3 family members:
- The LVDS PLL architecture is more complex and requires computing PLL
parameters manually.
- The PLL uses external clocks as inputs, which need to be retrieved
from DT.
- In addition to the different PLL setup, the startup sequence has
changed *again* (seems someone had trouble making his/her mind).
Supporting all this requires DT bindings extensions for external clocks,
brand new PLL setup code, and a few quirks to handle the differences in
the startup sequence.
The implementation doesn't support all hardware features yet, namely
- Using the LV[01] clocks generated by the CPG as PLL input.
- Providing the LVDS PLL clock to the DU for use with the RGB output.
Those features can be added later when the need will arise.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
The THC63LVD1024 is restricted to a pixel clock frequency in the range
of 8 to 135 MHz. Implement the bridge .mode_valid() operation
accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Tested-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Some of definitions in the code changed the meaning, unfortunately one
place missed the change.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When we want to writeback to memory in NV12 format we need to program
the RGB2YUV coefficients. Currently, we don't program the coefficients
and NV12 doesn't work at all.
This patchset fixes that by programming a sane default(bt709, limited
range) as rgb2yuv coefficients.
In the long run, probably we need to think of a way for userspace to
be able to program that, but for now I think this is better than not
working at all or not advertising NV12 as a supported format for
memwrite.
Changes since v1:
- Write the rgb2yuv coefficients only once, since we don't change
them at all, just write them the first time NV12 is programmed,
suggested by Brian Starkey, here [1]
[1] https://lists.freedesktop.org/archives/dri-devel/2018-August/186819.html
Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Currently, if userspace calls drm_wait_vblank before the crtc is
activated the crtc vblank_enable hook is called, which in case of
malidp driver triggers some warninngs. This happens because on
device init we don't inform the drm core about the vblank state
by calling drm_crtc_vblank_on/off/reset which together with
drm_vblank_get have some magic that prevents calling drm_vblank_enable
when crtc is off.
Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Both the .enable_signaling and .release of the null syncobj fence
can be replaced by the default callbacks for a small reduction in code
size. In particular the default callback for .release was changed in
commit e28bd101ae ("drm: rename null fence to stub fence in syncobj v2")
which neglected its RCU protection.
Fixes: e28bd101ae ("drm: rename null fence to stub fence in syncobj v2")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180920200530.2836-1-chris@chris-wilson.co.uk
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All DRM_CLIENT capabilities are tied to KMS support, so returning
-EOPNOTSUPP when KMS is not supported.
v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
in uapi) instead of -ENOTSUPP
v3: adding comments about the feature requirement about capabilities
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180918174809.17123-1-jose.souza@intel.com
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJbpDR8AAoJEAx081l5xIa+9doQAJGNbihlBJx9TSYjejuAW5SD
Rb0WQVCaHaHIzyaCTTcN+1GPryCUBPrEnF5DMic8WodWDIxxTGp0c4pjYRazVIqh
V7l+IeZAmUXYMlv5jTGMgYaCXDuxaKPA1kCVAGg/q//XxBR6RCMRweZiGjl/+oqX
Yt3N+nM2NWmzt6t96fYrDyHdPKsdAVB8ogkd4z/GBJ1xo1hU+MlDrJx4j+R/yGHk
WZ34ThPmACMnpnyskamJ2J8gmhmHPe7Qt7/izbsusLH1CYXnvwKL+iMkQ3YGvUuS
9cob6u9ar/8WgfaRevsU0L3t0e68UHiQiD0O4R3YGxl32Wumd7BPCY0uUW3Q+I64
1ikA6AtzdCz64LtWhulxKtnLKN/lekfG5qbSuKxGt/ppHY3PY0qWWUiG2CEIjtPh
OYFLg8/3lEhDAoyW0Qn9oUCQ6uWXUFAqaVV8L5d+zFZzKkJm4msyEVOf3MZXVTTw
EqcogCfNpqm/T5gsyZ4YSWPZhp+OlVJGEXTIgA4TBciKvDjlcD86BH9cdQx5MtnO
pLf1bCAJPVufU1zBa81CNbDzwGl475s0eY8NpFJztCn+43ews0bhTtpwSdn8F4BS
4pU4hlZPbCuAekDUXiDvVzQveXCU45wI2wL1tVqpTZS4MglOFz7nnFriI7I3eh1B
/Dh//KeQ0qDxu4P/XSlL
=56tH
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2018-09-21' of git://anongit.freedesktop.org/drm/drm
David writes:
"drm fixes for 4.19-rc5:
- core: fix debugfs for atomic, fix the check for atomic for
non-modesetting drivers
- amdgpu: adds a new PCI id, some kfd fixes and a sdma fix
- i915: a bunch of GVT fixes.
- vc4: scaling fix
- vmwgfx: modesetting fixes and a old buffer eviction fix
- udl: framebuffer destruction fix
- sun4i: disable on R40 fix until next kernel
- pl111: NULL termination on table fix"
* tag 'drm-fixes-2018-09-21' of git://anongit.freedesktop.org/drm/drm: (21 commits)
drm/amdkfd: Fix ATS capablity was not reported correctly on some APUs
drm/amdkfd: Change the control stack MTYPE from UC to NC on GFX9
drm/amdgpu: Fix SDMA HQD destroy error on gfx_v7
drm/vmwgfx: Fix buffer object eviction
drm/vmwgfx: Don't impose STDU limits on framebuffer size
drm/vmwgfx: limit mode size for all display unit to texture_max
drm/vmwgfx: limit screen size to stdu_max during check_modeset
drm/vmwgfx: don't check for old_crtc_state enable status
drm/amdgpu: add new polaris pci id
drm: sun4i: drop second PLL from A64 HDMI PHY
drm: fix drm_drv_uses_atomic_modeset on non modesetting drivers.
drm/i915/gvt: clear ggtt entries when destroy vgpu
drm/i915/gvt: request srcu_read_lock before checking if one gfn is valid
drm/i915/gvt: Add GEN9_CLKGATE_DIS_4 to default BXT mmio handler
drm/i915/gvt: Init PHY related registers for BXT
drm/atomic: Use drm_drv_uses_atomic_modeset() for debugfs creation
drm/fb-helper: Remove set but not used variable 'connector_funcs'
drm: udl: Destroy framebuffer only if it was initialized
drm/sun4i: Remove R40 display pipeline compatibles
drm/pl111: Make sure of_device_id tables are NULL terminated
...
This is a new pull for drm-next on top of last weeks with the following
changes:
- Fixed 64 bit divide
- Fixed vram type on vega20
- Misc vega20 fixes
- Misc DC fixes
- Fix GDS/GWS/OA domain handling
Previous changes from last week:
amdgpu/kfd:
- Picasso (new APU) support
- Raven2 (new APU) support
- Vega20 enablement
- ACP powergating improvements
- Add ABGR/XBGR display support
- VCN JPEG engine support
- Initial xGMI support
- Use load balancing for engine scheduling
- Lots of new documentation
- Rework and clean up i2c and aux handling in DC
- Add DP YCbCr 4:2:0 support in DC
- Add DMCU firmware loading for Raven (used for ABM and PSR)
- New debugfs features in DC
- LVDS support in DC
- Implement wave kill for gfx/compute (light weight reset for shaders)
- Use AGP aperture to avoid gart mappings when possible
- GPUVM performance improvements
- Bulk moves for more efficient GPUVM LRU handling
- Merge amdgpu and amdkfd into one module
- Enable gfxoff and stutter mode on Raven
- Misc cleanups
Scheduler:
- Load balancing support
- Bug fixes
ttm:
- Bulk move functionality
- Bug fixes
radeon:
- Misc cleanups
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180920150438.12693-1-alexander.deucher@amd.com
Fix up the error unwind for logical_ring_init() failing by moving the
cleanup into the callers who own the various bits of state during
initialisation, so we don't forget to free the state allocated by the
caller.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180920195948.16448-1-chris@chris-wilson.co.uk
Once we have flushed the first request through the system to both load a
context and record the default state; tell the GPU to park and idle
itself, putting itself immediately (hopefully at least) into a
powersaving state, and allowing ourselves to start from known state
after setting up all our bookkeeping.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180920161343.1117-1-chris@chris-wilson.co.uk
It really wants dev_priv anyway, also now matches i915_gem_init_stolen.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180920142707.19659-2-matthew.auld@intel.com
If we copy all the contents of the sg across and not just the page link,
we can then also put it to work in fake_get_huge_pages and beyond.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180920142707.19659-1-matthew.auld@intel.com
Because CRAT_CU_FLAGS_IOMMU_PRESENT was not set in some BIOS crat, we
need to workaround this.
For future compatibility, we also overwrite the bit in capability according
to the value of needs_iommu_device.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Yong Zhao <Yong.Zhao@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
CWSR fails on Raven if the control stack is MTYPE_UC, which is used
for regular GART mappings. As a workaround we map it using MTYPE_NC.
The MEC firmware expects the control stack at one page offset from the
start of the MQD so it is part of the MQD allocation on GFXv9. AMDGPU
added a memory allocation flag just for this purpose.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Yong Zhao <yong.zhao@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
A wrong register bit was examinated for checking SDMA status so it reports
false failures. This typo only appears on gfx_v7. gfx_v8 checks the correct
bit.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Amber Lin <Amber.Lin@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Planes without an alpha property, using __drm_atomic_helper_plane_reset
will have their plane state alpha initialised as zero, which represents
a transparent alpha.
If this value is then used for the plane, it may not be visible by
default, and thus doesn't represent a good initialisation state.
Update the default state->alpha value to DRM_BLEND_ALPHA_OPAQUE
unconditionally when the plane is reset.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180919155700.10342-2-kieran.bingham+renesas@ideasonboard.com
Stolen memory is lost across S4 (hibernate) or S3-RST as it is a portion
of ordinary volatile RAM. As we allocate our rings from stolen, this may
include the rings used for our preempt context and their breadcrumb
instructions. In order to allow preemption following hibernation and
loss of stolen memory, we therefore need to repopulate the instructions
inside the lost ring upon resume. To handle both module load and resume,
we simply defer constructing the ring to first use.
Testcase: igt/drv_selftest/live_gem
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180919205432.18394-1-chris@chris-wilson.co.uk
We need to exercise the HW and submission paths for switching contexts
rapidly to check that features such as execlists' wa_tail are adequate.
Plus it's an interesting baseline latency metric.
v2: Check the initial request for allocation errors
v3: Use finite waits for more robust handling of broken code
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180920105809.1872-1-chris@chris-wilson.co.uk
convert drm_atomic_helper_suspend/resume() to use
drm_mode_config_helper_suspend/resume().
exynos_drm_fbdev_suspend/resume can be removed
as drm_mode_config_helper_suspend/resume has
implement the same in generic way.
Remove suspend_state from exynos_drm_private
struct as it is no more useful.
Signed-off-by: Ajit Negi <ajitn.linux@gmail.com>
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
As the out bridge will not be enabled directly by the framework,
it should be enabled by DSI. exynos_dsi_enable() should handle a case,
when there is an out_bridge connected as a DSI peripheral.
Changed in v5:
- fixed error path in exynos_dsi_enable
Signed-off-by: Maciej Purski <m.purski@samsung.com>
[ a.hajda@samsung.com: v5 ]
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The current implementation assumes that the only possible peripheral
device for DSIM is a panel. Using an output bridge child device
should also be possible.
If an output bridge is available, don't create a new connector.
Instead, call drm_bridge_attach() and set encoder's bridge to NULL
in order to avoid an out bridge from being visible by the framework, as
the DSI bus needs control on enabling its child output bridge.
Such sequence is required by Toshiba TC358764 bridge, which is a DSI
peripheral bridge device.
changed in v5:
- detach bridge in mipi_dsi detach callback
Signed-off-by: Maciej Purski <m.purski@samsung.com>
[ a.hajda@samsung.com: v5 ]
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Manually merged due to merge conflict.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Driver uses bridge_node to refer to bridge on input side of DSI.
Since we want to add support for bridges on output side lets add
"in" prefix to avoid confusion with out bridges.
Changes in v5:
- replace mic_ prefix with in_
Signed-off-by: Maciej Purski <m.purski@samsung.com>
[ a.hajda@samsuung.com: v5 ]
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
here comes a collection of various fixes, mostly for stable-tree
or regression fixes.
Two relatively high LOCs are about the (rather simple) conversion of
uapi integer types in topology API, and a regression fix about HDMI
hotplug notification on AMD HD-audio. The rest are all small
individual fixes like ASoC Intel Skylake race condition, minor
uninitialized page leak in emu10k1 ioctl, Firewire audio error paths,
and so on.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAluhankOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8hRxAAtMnqlbnld2ihoENWWwDPD1RedUhICP3ItOUB
8t5QXhzLlZ1fHKiDy8XAE7bljdEk8VJJDkva1umGztaAe9vxFzqjIvYn2yYvdX0d
M9qxrJtY8V65Tsq9s1hUYdbONGGveXOabWEa+PwQOQdsIq4O+kwvyOvjWShvcdHQ
vwKyaeC3E3pM0BIwna6O35E7GEEAauNhC/7ejdVNOD53Gn+gD3aREQqmiQvpFpqU
6/uhptM6Pp5Q18WOoKgVyDojPe2kNUDZ3SqMIyX90CDiIzVOvT8arB+19Ne5cnb+
lKItWDaVqzGX+hdG2WwsGNKrxVrAgZpETmeVjlvfyUIH+fcfierpiNuQi++v1hAH
VMHAYUF8ks9wS0FzmEX98PtlkPb2y1AyrcxrhWcZjfItmAFihXu+mE4EIG+4mTk6
JvqewxFegVgQxK3ohwkl5+dv01HV3BJJ/1W5hYq+qmXzRqU0XIrOt9wBOwXJPREo
BDQBbsWNejZYbJYuR3N2b7GCDK3u7wt1KoSfehN3t1ueSqJkq07BHw81RpC1uZ4h
q6DWOfS5XZf+fDSwCabddYzlZwR9R/dFbYC+LogW0eRhMIMga0HSc2sSNNQjBE3I
I7wgiU3NhRt6bGSg3B8/za52TaWD61QigXNmKSxRqgw1l1y+VeMkVoIjgxz9it8j
GWDFG3g=
=Qk/8
-----END PGP SIGNATURE-----
Merge tag 'sound-4.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Takashi writes:
"sound fixes for 4.19-rc5
here comes a collection of various fixes, mostly for stable-tree
or regression fixes.
Two relatively high LOCs are about the (rather simple) conversion of
uapi integer types in topology API, and a regression fix about HDMI
hotplug notification on AMD HD-audio. The rest are all small
individual fixes like ASoC Intel Skylake race condition, minor
uninitialized page leak in emu10k1 ioctl, Firewire audio error paths,
and so on."
* tag 'sound-4.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (33 commits)
ALSA: fireworks: fix memory leak of response buffer at error path
ALSA: oxfw: fix memory leak of discovered stream formats at error path
ALSA: oxfw: fix memory leak for model-dependent data at error path
ALSA: bebob: fix memory leak for M-Audio FW1814 and ProjectMix I/O at error path
ALSA: hda - Enable runtime PM only for discrete GPU
ALSA: oxfw: fix memory leak of private data
ALSA: firewire-tascam: fix memory leak of private data
ALSA: firewire-digi00x: fix memory leak of private data
sound: don't call skl_init_chip() to reset intel skl soc
sound: enable interrupt after dma buffer initialization
Revert "ASoC: Intel: Skylake: Acquire irq after RIRB allocation"
ALSA: emu10k1: fix possible info leak to userspace on SNDRV_EMU10K1_IOCTL_INFO
ASoC: cs4265: fix MMTLR Data switch control
ASoC: AMD: Ensure reset bit is cleared before configuring
ALSA: fireface: fix memory leak in ff400_switch_fetching_mode()
ALSA: bebob: use address returned by kmalloc() instead of kernel stack for streaming DMA mapping
ASoC: rsnd: don't fallback to PIO mode when -EPROBE_DEFER
ASoC: rsnd: adg: care clock-frequency size
ASoC: uniphier: change status to orphan
ASoC: rsnd: fixup not to call clk_get/set under non-atomic
...
Commit 19be557010 ("drm/ttm: add operation ctx to ttm_bo_validate v2")
introduced a regression where the vmwgfx driver refused to evict a
buffer that was still busy instead of waiting for it to become idle.
Fix this.
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
If framebuffers are larger, we create bounce surfaces that are within
STDU limits.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
For all display units, limit mode size exposed to texture_max_width/
height as this is the maximum framebuffer size that virtual device can
create.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
For STDU individual screen target size is limited by
SVGA_REG_SCREENTARGET_MAX_WIDTH/HEIGHT registers so add that limit
during atomic check_modeset.
An additional limit is placed in the update_layout ioctl to avoid
requesting layouts that current user-space typically can't support.
Also modified the comments to reflect current limitation on topology.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
During atomic check to prepare the new topology no need to check if
old_crtc_state was enabled or not. This will cause atomic_check to fail
because due to connector routing a crtc can be in atomic_state even if
there was no change to enable status.
Detected this issue with igt run.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
-----BEGIN PGP SIGNATURE-----
iQJWBAABCgBAFiEEvZRkio5H7O2/GZsYYiVdKZ4oCyQFAludFyoiHGxhdXJlbnQu
cGluY2hhcnRAaWRlYXNvbmJvYXJkLmNvbQAKCRBiJV0pnigLJC13D/9ZgG8Oga8f
iT+jRgru0al7Bl4IW1zE46ew54ohZF+OgRDpfab67mjNw/zmp7SGGWa59fKOj4GL
kPUTbAaUploe9Njqyaf71bi/9och7Yt+m3QlhVPIuN4HdDYCg87hbHkv6SRuIGvK
Rz2Z/mVW8VXTG69i9+ypxUW3eEYE0hB4kqCUqQmhvTfZOplp2YgQyzfdhNRyMZt6
nc08XT89R0oCtQEDAO4MVzD9/RJdWWk65PanqrkEcRK4LrtO1PGDGK8soV6gvj2/
pMtYKnNjB8KZQS2XCZhoHA4R5sUhmDx+fp1ayWE6/VKB8I7jLTuA6eiwZ342eWlY
n30ifFzhabcLTqMy2v63fCx1Ynp84CXH8YO4wxaGFVBqL9ASrB2w7IWWG+gBUJ0B
S+tcsbOPhctPGmgzqQAHFvFxmWlsc8eiTPt1UGwqjTRyoT+4UyqQVAH2ZLo/lIUt
TRM0ROx/Bhh1Tbbg7HuEpcxrMEOa/MqdwBnqv1vf2ugRj4bt55yho5AzJs/vdpmr
ojnjPxUIvE3QNmufFg1lLIfOcSMNEsimBg/OCLJB5ZkcuctjHugjHEu2VeFsDPJ+
c3fGWvVusTqPSWd6g3wvl4AY+404Zyp3rl29m8sZJU1cyF4Xx/uDP7iXodjueTXn
GkAYLzn/2NjB3v7N5d/mjuA2iqeyJM4JYA==
=vSV4
-----END PGP SIGNATURE-----
Merge tag 'du-next-20180914' of git://linuxtv.org/pinchartl/media into drm-next
R-Car DU changes for v4.20
The pull request mostly contains updates to the R-Car DU driver, notably
support for interlaced modes on Gen3 hardware, support for the LVDS output on
R8A77980, and a set of miscellaneous bug fixes. There are also two SPDX
conversion patches for the drm shmobile and panel-lvds drivers, as well as an
update to MAINTAINERS to add Kieran Bingham as a co-maintainer for the DU
driver.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3273568.LdoAI77IYW@avalon
Temporary disable UVD/VCE block if is virtual device
Signed-off-by: Frank Min <Frank.Min@amd.com>
Signed-off-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add sriov capability detection for vega20, then can check if device is
virtual device.
Signed-off-by: Frank Min <Frank.Min@amd.com>
Signed-off-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
UAPI Changes:
- None
Cross-subsystem Changes:
- None
Core Changes:
- Allow drivers to disable features with per-device granularity (Ville)
- Use EOPNOTSUPP when iface/feature is unsupported instead of
EINVAL/errno soup (Chris)
- Simplify M/N DP quirk by using constant N to limit size of M/N (Shawn)
- add quirk for LG LP140WF6-SPM1 eDP panel (Shawn)
Driver Changes:
- i915/amdgpu: Disable DRIVER_ATOMIC for older/unsupported devices (Ville)
- sun4i: add support for R40 HDMI PHY (Icenowy)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Icenowy Zheng <icenowy@aosc.io>
Cc: Lee, Shawn C <shawn.c.lee@intel.com>
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEfxcpfMSgdnQMs+QqlvcN/ahKBwoFAluiqZAACgkQlvcN/ahK
BwrD7gf+O9hI1+sWAKs9/D2xz5G0Ap/wTUtPZprVx+UMg833T4E3q5esSTvlKd5q
QdijWWFZ3Eu7osQB5QTvCHpJ1F1Q9DScYdD5rd0WRhZBGnBd2guFziFRhleXpQH1
CTo/xjS4Y1l1wEildvZdjPaDfXE0Q+uK8kl11AIVoYQvW6V28/pwCW+mmfMfQG4D
lC9Lj5iPTDGLmbT3DZcH9ZUU8CZreJVPDn+mi8XsAOGt55YlCphl5XsOabNRzpCh
5VYZbauJqrlfa3/cbVuFpTqjqR5XRlMvzgdYH2Wa+9JreiReNCDs3CVL4YnLWe0p
PIfE6ZC2ucX831aZOodV7KtwtLYc/Q==
=oPPq
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2018-09-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 4.20:
UAPI Changes:
- None
Cross-subsystem Changes:
- None
Core Changes:
- Allow drivers to disable features with per-device granularity (Ville)
- Use EOPNOTSUPP when iface/feature is unsupported instead of
EINVAL/errno soup (Chris)
- Simplify M/N DP quirk by using constant N to limit size of M/N (Shawn)
- add quirk for LG LP140WF6-SPM1 eDP panel (Shawn)
Driver Changes:
- i915/amdgpu: Disable DRIVER_ATOMIC for older/unsupported devices (Ville)
- sun4i: add support for R40 HDMI PHY (Icenowy)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Icenowy Zheng <icenowy@aosc.io>
Cc: Lee, Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20180919200218.GA186644@art_vandelay
one srcu locking fix and one fix for GGTT clear when destroy vGPU."
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJbomjjAAoJEPpiX2QO6xPKlaMH/0sp97hPs11qVzYNrKk3Znh8
DJaI9IzRWfmSwLbfnpyywK7VqqErUltRSwUW+R8X2FqLXeG4shni154/jRdIMy1a
zx7Or/8fIyvVbCEJteMvn+Lv+8ucm8tTG3YL9JqQj7blyo3T1JbtA8zsIoVgug3T
pf4niyqcoO1plpZUsrnGKHmdrhUG+oGUkG6AWOBS8NlGgobvFY5nviyfVhdLEyG1
JZRjruFRnVNmyIgyUCHwSN9ILO6DDykMW6xpqv7CIm8eLcImetHQvwfgEsl8mMUq
SCT5EoUEnzSJrlRHkzoso4X7slM35wJ/JNnCN3NsmznWSs3FoIuFt3R3qsD8GlE=
=XeR4
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-fixes-2018-09-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
Only fixes coming from gvt containing "Two more BXT fixes from Colin,
one srcu locking fix and one fix for GGTT clear when destroy vGPU."
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180919151915.GA6309@intel.com
- Fix crash in vgem in drm_drv_uses_atomic_modeset.
- Allow atomic drivers that don't set DRIVER_ATOMIC to create debugfs entries.
- Fix compiler warning for unused connector_funcs.
- Fix null pointer deref on UDL unplug.
- Disable DRM support for sun4i's R40 for now.
(Not all patches went in for v4.19, so it has to wait a cycle.)
- NULL-terminate the of_device_id table in pl111.
- Make sure vc4 NV12 planar format works when displaying an unscaled fb.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAluiXbsACgkQ/lWMcqZw
E8P9MBAAjmltMZr9KbmtksYSDFHVldiTqwiToPDl4iZPmMDKCQQP14apJhqwFqdO
pa+N3n7zrbR9PTUcPxt2pfT3I8J7vCGARMc66wnlPbrKDes+dkKm7KqCRFJGcyrD
faN++FGfTBn3rsLo1iM7mLOMVE+72B5gdjcxIqewEXSxWjX9ED6N7JaVR7krcQbs
MVT/ENvLZTRVCYla+eey+wQoZR/bh/E7HtuvqsLRaQOGSk6Go2gBzEiZiWfT+6sS
BzEXaYKL61AKhsh68oiPB2elxVWrnPyf3liLAzoTF0MhXuGxmlu9F50jByQvDuz8
lAzm53Hg5uFj6Ca1E81I1UDy2i5IAgaiRXGfVikeWwTsBiLgxhcRDGbQPki2rHRu
1Cs+D/F1gE94WqWhu9ydV2rU5X/5/NdDvYH0LkeD5jI9VcB8KtK89r3zXkxh3f9B
BfhVOGq3RTVgdAFFPujRrZCTQyyNW8zo51mYmncVykB//9awWE5nQcK3HGLh2wvL
0Oar5oJE3UlHa5No91zMyxmJIxZVp7SE/4A7+ih1LGTu5SyaT9K718pAgv2lpakd
HMhgF+338rCqMfL7TFqYJ2N+srXTzNRruHXdElcSg1wHbfEFejyMt0KRtv0x32qE
9IJ1CFuJVWgQ5pXu5zbj+NLKo5kR4ow0BCvsk7HCWiqkJ5N+pY8=
=bZgz
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2018-09-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
drm-misc-fixes for v4.19-rc5:
- Fix crash in vgem in drm_drv_uses_atomic_modeset.
- Allow atomic drivers that don't set DRIVER_ATOMIC to create debugfs entries.
- Fix compiler warning for unused connector_funcs.
- Fix null pointer deref on UDL unplug.
- Disable DRM support for sun4i's R40 for now.
(Not all patches went in for v4.19, so it has to wait a cycle.)
- NULL-terminate the of_device_id table in pl111.
- Make sure vc4 NV12 planar format works when displaying an unscaled fb.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/dda393bb-f13f-8d36-711b-cacfc578e5a3@linux.intel.com
We don't need that in the per ASIC code.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Stops crashing on SI.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
That only worked by pure coincident. Completely remove the shifting and
always apply correct PAGE_SHIFT.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Don't grab the reservation lock any more and simplify the handling quite
a bit.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It shouldn't add much overhead and we should make sure that critical
VRAM content is always restored.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
They aren't directly used by the hardware.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Even when GPU recovery is disabled we could run into a manually
triggered recovery.
v2: keep accidental removed comments
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Emily Deng <Emily.Deng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We are going to need this for recoverable page fault handling and it
makes shadow handling during GPU reset much more easier.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
DC doesn't seem to have a fallback path either.
So when interrupts doesn't work any more we are pretty much busted no
matter what.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
With OD settings applied, the clock table will be updated accordingly.
We need to retrieve the new clock tables then.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
With the latest SMC fw, we are able to get the voltage value for
specific frequency point. So, we update the OD relates to take
absolute voltage instead of offset.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Update the conditions to judge whether an OD feature
should be supported on vega20.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
vega20 should use umc_info v3_3 instead of v3_1. There are
serveral versions of umc_info for vega series. Compared to
various versions of these structures, vram_info strucure is
unified for vega series. The patch switch to query mem_type
from vram_info structure for all the vega series dGPU.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
atomfirmware has structure changes in varm_info. Updated it
to the latest one.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
In function ‘radeon_process_i2c_ch’ a comparison of a u8 value against
255 is done. Since it is always false, change the signature of this
function to use an `int` instead, which match the type used in caller:
`radeon_atom_hw_i2c_xfer`.
Fix the following warning triggered with W=1:
CC [M] drivers/gpu/drm/radeon/atombios_i2c.o
drivers/gpu/drm/radeon/atombios_i2c.c: In function ‘radeon_process_i2c_ch’:
drivers/gpu/drm/radeon/atombios_i2c.c:71:11: warning: comparison is always false due to limited range of data type [-Wtype-limits]
if (num > ATOM_MAX_HW_I2C_READ) {
^
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
adev->gfx.rlc has the values from rlc_hdr already processed by
le32_to_cpu. Using the rlc_hdr values on big-endian machines causes
a kernel Oops due to writing well outside of the array (0x24000000
instead of 0x24).
Signed-off-by: A. Wilcox <AWilcox@Wilcox-Tech.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We no don't allocate zero sized kernel BOs any longer.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Just free the BO if the size should be zero.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Simply ignore any copying here.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Additional to the existing files for VRAM and GTT.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The function was modified without updating the documentation.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We can't get the mask for the root directory from the number of entries.
So add a new function to avoid that problem.
v2: fix typo in mask
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The N value was computed by kernel driver that based on synchronous clock
mode. But only specific N value (0x8000) would be acceptable for
LG LP140WF6-SPM1 eDP panel which is running at asynchronous clock mode.
With the other N value, Tcon will enter BITS mode and display black screen.
Add this panel into quirk database and give particular N value when
calculate M/N divider.
v2: no update
v3: add lost commit messages back for version 2
v4: send patch to both intel-gfx and dri-devel
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Lee, Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1536733371-25004-4-git-send-email-shawn.c.lee@intel.com
Some DP dongles in particular seem to be fussy about too large
link M/N values. Set specific value for N divider can resolve
this issue per dongle vendor's comment. So configure N as
constant value (0x8000) to instead of reduce M/N formula when
specific DP dongle connected.
v2: add more comments for issue description and fix typo.
v3: add lost commit messages back for version 2
v4: send patch to both intel-gfx and dri-devel
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Tested-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Lee, Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1536733371-25004-3-git-send-email-shawn.c.lee@intel.com
DP quirk list just compare sink or branch device's OUI so far.
That means particular vendor's products will be applied specific
change. This change would confirm device_id the same or not.
Then driver can implement some changes for branch/sink device
that really need additional WA.
v2: use sizeof instead of hard coded '6'
v3: add lost commit messages back for version 2
v4: send patch to both intel-gfx and dri-devel
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Tested-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Lee, Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1536733371-25004-2-git-send-email-shawn.c.lee@intel.com
The A64 HDMI PHY seems to be not able to use the second video PLL as
clock parent in experiments.
Drop the support for the second PLL from A64 HDMI PHY driver.
Fixes: b46e2c9f5f ("drm/sun4i: Add support for A64 HDMI PHY")
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180916043409.62374-2-icenowy@aosc.io
PSR requires AUX IO power well to be enabled. This was already in place
for CNL, extend this for ICL too. Not enabling the power well results in
the aux error interrupts when the hardware exits PSR.
Reported-by: Casey G Bowman <casey.g.bowman@intel.com>
Reported-by: Jyoti R Yadav <jyoti.r.yadav@intel.com>
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: Jyoti R Yadav <jyoti.r.yadav@intel.com>
Cc: Casey G Bowman <casey.g.bowman@intel.com>
Tested-by: Casey G Bowman <casey.g.bowman@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180914001822.2503-1-dhinakaran.pandiyan@intel.com
SDVO encoders can have multiple different types of outputs hanging off
them. Currently the code tries to muck around with various is_foo
flags in the encoder to figure out which type its driving. That doesn't
work with atomic and other stuff, so let's nuke those flags and just
look at which type of connector we're actually dealing with.
The is_hdmi we'll need as that's not discoverable via the output flags,
but we'll just move it under the connector.
We'll also move the sdvo fixed mode handling out from the .get_modes()
hook into the sdvo lvds init function so that we can bail out properly
if there is no fixed mode to be found.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180917151504.8754-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Smatch reports:
../drivers/gpu/drm/i915/intel_sprite.c:1192 skl_plane_check_fb() warn: was || intended here instead of &&?
Obviously smatch is correct here since we're trying to check if we're
using either of the ccs modifiers. Since we now have is_ccs_modifier()
let's use it to fix this.
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: e21c2d3310 ("drm/i915: Move skl plane fb related checks into a better place")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180918131059.793-1-ville.syrjala@linux.intel.com
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
convert drm_atomic_helper_suspend/resume() to use
drm_mode_config_helper_suspend/resume().
With this conversion, tegra_drm_fb_suspend() and
tegra_drm_fb_resume() will not be used anymore.
Both of these functions can be removed.
Also, in tegra_drm struct's member state will not be
used anymore. So this can be removed forever.
Fixed one sparse warning.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Signed-off-by: Ajit Negi <ajitn.linux@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Clean up some cases where we're dealing with GTT pages instead of
system pages to use I915_GTT_PAGE_SIZE instead of PAGE_SHIT. So
just replace the the shifts with mul/div as appropriate. These
are the easy ones, the rest probably need some actual thought.
No real changes in the generated asm. Only gen8_ppgtt_insert_4lvl()
was affected as gcc decided to do the following change:
- be9: 89 d9 mov %ebx,%ecx
- beb: c1 e1 0c shl $0xc,%ecx
- bee: 48 63 c9 movslq %ecx,%rcx
+ be9: 48 63 cb movslq %ebx,%rcx
+ bec: 48 c1 e1 0c shl $0xc,%rcx
and that then shifted a bunch of the offset by one byte. I presume
the sign extensions in the asm are due to integer promotions from
u16 etc. Hopefully someone has confirmed that those don't end up
doing the wrong thing for us.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180917171414.19220-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
When one vgpu is destroyed, its ggtt entries are not cleared.
This patch clears ggtt entries to avoid information leak.
v2: add 'Fixes' tag (Zhenyu)
Fixes: 2707e44466 ("drm/i915/gvt: vGPU graphics memory virtualization")
Signed-off-by: Zhipeng Gong <zhipeng.gong@intel.com>
Reviewed-by: Hang Yuan <hang.yuan@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Host prints lots of untracked MMIO at 0x4653c when creating linux guest.
"gvt: vgpu 2: untracked MMIO 0004653c len 4"
GEN9_CLKGATE_DIS_4 (0x4653c) is accessed by i915 for gmbus clockgating.
However vgpu doesn't support any clockgating powergating operations
on related mmio access trap so need add it to default handler.
GEN9_CLKGATE_DIS_4 is accessed in bxt_gmbus_clock_gating() which only
applies to GEN9_LP so doens't show the warning on other platforms.
The solution is to add it to default handler init_bxt_mmio_info().
Reviewed-by: He, Min <min.he@intel.com>
Signed-off-by: Colin Xu <colin.xu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Recent patch fixed the call trace
"ERROR Port B enabled but PHY powered down? (PHY_CTL 00000000)".
but introduced another similar call trace shown as:
"ERROR Port C enabled but PHY powered down? (PHY_CTL 00000200)".
The call trace will appear when host and guest enabled different ports,
i.e. host using PORT C or neither PORT is enabled, while guest is always
using PORT B as simulated by gvt. The issue is actually covered previously
before the commit and reverals now when the commit do the right thing.
On BXT, some PHY registers are initialized by vbios, before i915 loaded.
Later i915 will re-program some, or skip some based on the implementation.
The initialized mmio for guest i915 is done by gvt, based on the snapshot
taken from host. If host and guest have different PORT enabled, some
DPIO PHY mmios that gvt initialized for guest i915 will not match the
simualted monitor for guest, which leads to guest i915 print the calltrace
when it's trying to enable PHY and PORT.
The solution is to init these DPIO PHY registers to default value, then
guest i915 will program them to reasonable value based on the default
powerwell table and enabled PORT. Together with the old patch, all similar
call trace in guest kernel on BXT can be resolved.
v2: Move PHY register init to intel_vgpu_reset_mmio (Min)
v3: Do not delete empty line in issue fix patch. (zhenyu)
Fixes: c8ab5ac30c ("drm/i915/gvt: Make correct handling to vreg
BXT_PHY_CTL_FAMILY")
Reviewed-by: He, Min <min.he@intel.com>
Signed-off-by: Colin Xu <colin.xu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
As pointed out by Daniel Vetter, we should be usinng
drm_drv_uses_atomic_modeset() for determining whether or not we want to
make the debugfs nodes for atomic instead of checking DRIVER_ATOMIC, as
the former isn't an accurate representation of whether or not the driver
is actually using atomic modesetting internally (even though it might
not be exposing atomic capabilities).
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180917173733.21293-1-lyude@redhat.com
The Gen3 VSP used by the DU for display does not support the packed VYUY
pixel format. Gen2 VSP hardware is able to process this format, but
DU + VSP operation isn't enabled on Gen2, and VYUY isn't a strategic
format, so it can be ignored.
Remove the format from the capabilities of the DU driver.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The framebuffer pitch and alignment constraints reflect the limitations
of the Gen2 DU hardware. On Gen3, the DU has no memory interface and
thus doesn't impose any constraint. The limitations come instead from
the VSP that has a limit of 65535 bytes for the pitch and no alignment
constraint. Update the checks accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
This patch supports pixel format of RGB332, ARGB4444, XRGB4444,
BGR888, RGB888, BGRA8888, BGRX8888 and YVYU.
VYUY pixel format is not supported by H/W specification.
Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
[Reordered formats with RGB first]
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The R-Car Gen3 DU utilises the VSP1 hardware for memory access. The
limits on the RPF and WPF in this pipeline are 8190x8190.
Update the supported maximum sizes accordingly.
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Add support for the R-Car V3H (R8A77980) SoC to the LVDS encoder driver.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The ESCR and OTAR registers exist in each DU channel, but at different
offsets for odd and even channels. This led to usage of the group
register access API to write them, with offsets macros named ESCR/OTAR
and ESCR2/OTAR2 for the first and second ESCR/OTAR register in the group
respectively.
The names are confusing as it suggests that the ESCR/OTAR registers for
DU0 and DU2 are taken into account, especially with writes performed to
the group register access API.
Rename the offsets to ESCR/OTAR02 and ESCR/OTAR13, and use the CRTC
register access API to clarify the code. The offsets values are updated
accordingly.
Cosmetic patch, no functional changes intended.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
[Squashed ESCR and OTAR changes in a single commit]
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Document and re-name the 'dpll_ch' field to a more precise 'dpll_mask' for
consistency with the 'channels_mask' field defined in 'struct
rcar_du_device_info'.
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
DU channels not equipped with a DPLL use an SoC internal (provided by
the CPG) or external clock source combined with a DU internal divider to
generate the desired output dot clock frequency.
The current clock selection procedure does not fully exploit the ability
of external clock sources to generate the exact dot clock frequency by
themselves, but relies instead on tuning the internal DU clock divider
only, resulting in a less precise clock generation process.
When possible, and desirable, ask the external clock source for the
exact output dot clock frequency, and select the clock source that
produces the frequency closest to the desired output dot clock.
This patch specifically targets platforms (like Salvator-X[S] and ULCBs)
where the DU's input dotclock.in is generated by the versaclock VC5
clock source, which is capable of generating the exact rate the DU needs
as pixel clock output.
This patch fixes higher resolution modes which requires an high pixel
clock output currently not working on non-HDMI DU channel (such as
1920x1080@60Hz on the VGA output).
Fixes: 1b30dbde85 ("drm: rcar-du: Add support for external pixel clock")
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
[Factor out code to a helper function]
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
The DU channels that have a display PLL (DPLL) can only use external
clock sources, and don't have an internal clock divider (with the
exception of H3 ES1.x where the post-divider is present and needs to be
used as a workaround for a DPLL silicon issue).
Rework the clock configuration to take this into account, avoiding
selection of non-existing clock sources or usage of a missing
post-divider.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
[Why]
It's not being used
[How]
Nuke it
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
It's not being used anymore.
[How]
Nuke it
Signed-off-by: Leo Li <sunpeng.li@amd.com>
Reviewed-by: David Francis <David.Francis@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
current dc_link_detect function is not only detection but also update some link data.
[How]
added a pure get HPD state function.
Signed-off-by: Chiawen Huang <chiawen.huang@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Tony Cheng <tony.cheng@amd.com>
Reviewed-by: Steven Chiu <Steven.Chiu@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
support i2c transition event log
[How]
refined aux REQ and REP events in aux flow.
commented REQ and REP events in i2c flow.
note: i2c event log is currently commented out. more work is required
to find an portocol parser to and generate event for the parser
Signed-off-by: Chiawen Huang <chiawen.huang@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Clock sources currently have support for asic specific
function pointers. But actual separation into functions
was never performed, leaving us with giant functions that
rely on switch.
This change creates separate functions, removing switch use.
Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Reviewed-by: Tony Cheng <Tony.Cheng@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We were not providing the correct pixel clocks to DML for marks
calculation.
Signed-off-by: Charlene Liu <charlene.liu@amd.com>
Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The etnaviv device is a virtual device backing the DRM device, which may
drive multiple hardware GPU core devices. As most of the dma-mapping handling
is done through the virtual device, we need to make sure that a proper DMA
setup is in place. The easiest way to get a reasonable configuration is
to let the virtual device share the DMA configuration with one of the GPU
devices, so call of_dma_configure() with the right parameters manually.
This assumes that all etnaviv driven GPU devices in the system share the
same DMA configuration. If we ever encounter a SoC where the GPUs are on
busses with different offsets or behind different IOMMUs that will require
much deeper changes to the driver, as we would need to implement etnaviv
specific versions of most of the DRM helper functions.
For now we should be fine with this solution.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Guido Günther <agx@sigxcpu.org>
Tested-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
If the ioctl is not supported on a particular piece of HW/driver
combination, report ENOTSUP (aka EOPNOTSUPP) so that it can be easily
distinguished from both the lack of the ioctl and from a regular invalid
parameter.
v2: Across all the kms ioctls we had a mixture of reporting EINVAL,
ENODEV and a few ENOTSUPP (most where EINVAL) for a failed
drm_core_check_feature(). Update everybody to report ENOTSUPP.
v3: ENOTSUPP is an internal errno! It's value (524) does not correspond
to a POSIX errno, the one we want is ENOTSUP. However,
uapi/asm-generic/errno.h doesn't include ENOTSUP but man errno says
"ENOTSUP and EOPNOTSUPP have the same value on Linux,
but according to POSIX.1 these error values should be
distinct."
so use EOPNOTSUPP as its equivalent.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> #v2
Link: https://patchwork.freedesktop.org/patch/msgid/20180913192050.24812-1-chris@chris-wilson.co.uk
Turned out the commit is incomplete and since we remove using the AGP
mapping from the GTT manager it is also not necessary any more.
This reverts commit 22d8bfafcc.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: James Zhu <James.Zhu@amd.com>
Tested-by: James Zhu <James.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need to mask the lower bits not the upper one.
Fixes: ec210e3226 drm/amdgpu: put GART away from VRAM v2
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: James Zhu <James.Zhu@amd.com>
Tested-by: James Zhu <James.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Treat them all as Raven rather than adding a new picasso
asic type. This simplifies a lot of code and also handles the
case of rv2 chips with the 0x15d8 pci id. It also fixes dmcu
fw handling for picasso.
Acked-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
DMCU firmware version can be read using the AMDGPU_INFO ioctl
or the amdgpu_firmware_info debugfs entry
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Read the version number from the common firmware header and store
it in the dm struct
Signed-off-by: David Francis <David.Francis@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* Use consistent capitalization in the description of function arguments
* Define and consistently use the BO acronym for buffer objects
* Some minor wording improvements
Signed-off-by: Vijetha Malkai <vijetha.malkai@amd.com>
[ Michel Dänzer: Made commit log more specific ]
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The entries were only initialized once in amdgpu_sa_bo_new. If a fence
wasn't signalled yet in the first amdgpu_sa_bo_next_hole call, but then
got signalled before a later amdgpu_sa_bo_next_hole call, it could
destroy the fence but leave its pointer in the array, resulting in
use-after-free in amdgpu_sa_bo_new.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Raven2 does not enable all of the CG flags that raven1 does.
v2: rebase (Alex)
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Feifei Xu <Feifei.Xu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It's not supported yet.
v2: rebase (Alex)
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Since the clock value there may be like 29999 10Khz.
v2: rebase (Alex)
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Check the raven2 version number as well.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add DRM_AMD_DC_DCN1_01 config flag for Raven2
v2: Make DC select DRM_AMD_DC_DCN1_01 (Alex)
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add Raven2 definitions in the dc code
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Raven2 has a HW issue that it is unable to use the vram which is out of
MC_VM_SYSTEM_APERTURE_HIGH_ADDR. So here is the workaround that increase system
aperture high address to get rid of the VM fault and hardware hang.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Golden register settings from the hw team.
Signed-off-by: Feifei Xu <Feifei.Xu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Golden register settings from the hw team.
Signed-off-by: Feifei Xu <Feifei.Xu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Modified for using raven2_asd.bin to replace raven_asd.bin for raven2
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Rev id is used for identifying Raven2 series of chips. So we would better to
initialize it at first.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Rather than checking the asic type, check whether the UVD
or VCE IP blocks exist. This way we don't have to update
the check with new asics that use VCN.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
enable gfxoff in non-sriov and stutter mode by default
Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This patch is to add new pci device for raven series.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Remove some functions due to the design change.
All the mmhub power gating sequence is moved to
smu fw.Driver sends the message to enable mmhub
powergating.We can also skip the fw version check
since the old fw version is in a very early stage
and we don't use that fw for release.
Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Same as raven.
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Treat it the same as raven for now.
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Same as raven.
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Same as raven for now.
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
add powerplay support for picasso, treat it the same as raven now.
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add support for picasso to the display manager.
Signed-off-by: Likun Gao <Likun.Gao@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
