- 26 Jun, 2018 2 commits
-
-
Gustavo A. R. Silva authored
fb is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after fb has been properly null checked at line 74: if (!fb) Addresses-Coverity-ID: 1470169 ("Dereference before null check") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180625121844.GA12466@embeddedor.com
-
Thomas Zimmermann authored
This patch unifies the naming of DRM functions for reference counting of struct drm_gem_object. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by: Thomas Zimmermann <contact@tzimmermann.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180625152148.29555-1-contact@tzimmermann.org
-
- 25 Jun, 2018 6 commits
-
-
Maxime Ripard authored
The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is based on the Ilitek ILI9881c Controller. Add a driver for it, modelled after the other Ilitek controller drivers. Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/acb5453112ab7c7b801cf4f1669e351b391e77e8.1527587352.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
The LHR050H41 from BananaPi is a 1280x700 4-lanes DSI panel based on the ILI9881c from Ilitek. Acked-by: Rob Herring <robh@kernel.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/a348cdd07d3287e8203ee8d840ea279fe10a6204.1527587352.git-series.maxime.ripard@bootlin.com
-
John Stultz authored
The driver doesn't support scaling, but when an atomic test is done it repeatedly spits out this warning which isn't particularly useful. So just remove the error message. Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Chen Feng <puck.chen@hisilicon.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Peter Griffin <peter.griffin@linaro.org> Cc: dri-devel@lists.freedesktop.org Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1529622076-20386-1-git-send-email-john.stultz@linaro.org
-
Noralf Trønnes authored
Make ioctl wrappers for functions that will be used by the in-kernel API. The following functions are touched: - drm_mode_create_dumb_ioctl() - drm_mode_destroy_dumb_ioctl() - drm_mode_addfb() - drm_mode_rmfb() Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180618141739.48151-4-noralf@tronnes.org
-
Noralf Trønnes authored
It only makes sense for userspace clients. Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180618141739.48151-3-noralf@tronnes.org
-
David Herrmann authored
Rather than doing drm_file allocation/destruction right in the fops, lets provide separate helpers. This decouples drm_file management from the still-mandatory drm-fops. It prepares for use of drm_file without the fops, both by possible separate fops implementations and APIs (not that I am aware of any such plans), and more importantly from in-kernel use where no real file is available. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180618141739.48151-2-noralf@tronnes.org
-
- 22 Jun, 2018 2 commits
-
-
Eric Anholt authored
Drivers such as vc4 don't initialize mode_config.funcs until later in initialization, but we know they're atomic since they've got the flag set. This avoids oopsing on dereferencing funcs in the new atomic methods sanity checks. I moved the atomic check function down below the core flag check, to avoid needing a prototype. Signed-off-by: Eric Anholt <eric@anholt.net> Fixes: ba1f665f ("drm: Add checks for atomic_[duplicate/destroy]_state with atomic drivers") Link: https://patchwork.freedesktop.org/patch/msgid/20180621195428.17447-1-eric@anholt.netReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Christian König authored
Some functions are unused after removal of the kmap_atomic DMA-buf interface. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Fixes: f664a526 ("dma-buf: remove kmap_atomic interface") Link: https://patchwork.freedesktop.org/series/45245/
-
- 21 Jun, 2018 6 commits
-
-
Eric Anholt authored
Since our seqno value comes from a counter associated with the GPU ring, not the entity (aka client), they'll be completed out of order. There's actually no need for this code at all, since we don't have enable_signaling() and thus DMA_FENCE_SIGNALED_BIT will be set before we could be called. Signed-off-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180605190302.18279-2-eric@anholt.netReviewed-by: Lucas Stach <l.stach@pengutronix.de>
-
Eric Anholt authored
Between creation and queueing of a job, you need to prevent any other job from being created and queued. Otherwise the scheduler's fences may be signaled out of seqno order. v2: move mutex unlock to the error label. Signed-off-by: Eric Anholt <eric@anholt.net> Fixes: 57692c94 ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+") Link: https://patchwork.freedesktop.org/patch/msgid/20180606174851.12433-1-eric@anholt.netReviewed-by: Lucas Stach <l.stach@pengutronix.de>
-
Eric Anholt authored
This makes it more likely that the docs stay updated with the code. Signed-off-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20180606190431.1833-1-eric@anholt.netReviewed-by: Andrzej Hajda <a.hajda@samsung.com>
-
Souptick Joarder authored
Use new return type vm_fault_t for fault handler. Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net>
-
Ville Syrjälä authored
The meaning of the mode_config max_width/height fields has not been entirely clear. They are used both as the max framebuffer dimensions, and they are also used by drm_mode_getconnector() to filter out any mode whose hdisplay/vdisplay exceed those limits. Let's put it in writing that max_width/height only refrer to the max framebuffer dimensions, and should those be higher than the hardware limits for display timings the driver must validate the latter using some other means. We'll keep the max_width/height usage in drm_mode_getconnector() because setcrtc treats hdisplay/vdisplay also as the primary plane width, and having a plane bigger than the max fb size doesn't make much sense (if we ignore scaling that is). It all works out fine as long as the max fb dimensions are at least equal to the max timing limits. If the opposite were true we may want to rethink what drm_mode_getconnector() does. Maybe do the mode filtering only for non-atomic userspace? Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180615173939.11353-1-ville.syrjala@linux.intel.comReviewed-by: Manasi Navare <manasi.d.navare@intel.com>
-
Christian König authored
Fixup for "dma_buf: remove device parameter from attach callback v2". I missed this driver, sorry for the noise. Patch is not even compile tested. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/230641/
-
- 20 Jun, 2018 9 commits
-
-
Chris Wilson authored
Fix i915's CI build after the removal of the dmabuf->kmap interface that left the mock routines intact. In file included from drivers/gpu/drm/i915/i915_gem_dmabuf.c:335:0: drivers/gpu/drm/i915/selftests/mock_dmabuf.c:104:13: error: ‘mock_dmabuf_kunmap_atomic’ defined but not used [-Werror=unused-function] static void mock_dmabuf_kunmap_atomic(struct dma_buf *dma_buf, unsigned long page_num, void *addr) drivers/gpu/drm/i915/selftests/mock_dmabuf.c:97:14: error: ‘mock_dmabuf_kmap_atomic’ defined but not used [-Werror=unused-function] static void *mock_dmabuf_kmap_atomic(struct dma_buf *dma_buf, unsigned long page_num) Fixes: f664a526 ("dma-buf: remove kmap_atomic interface") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180620162152.1158-1-chris@chris-wilson.co.ukReviewed-by: Christian König <christian.koenig@amd.com>
-
Gustavo Padovan authored
We got a few conflicts in drm_atomic.c after merging the DRM writeback support, now we need a backmerge to unlock develop development on drm-misc-next. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
-
Liviu Dudau authored
Due to the fact that writeback connectors behave in a special way in DRM (they always report being disconnected) we might confuse some userspace. Add a client capability for writeback connectors that will filter them out for clients that don't understand the capability. Changelog: - only accept the capability if the client has already set the DRM_CLIENT_CAP_ATOMIC one. Cc: Sean Paul <seanpaul@chromium.org> Cc: Brian Starkey <brian.starkey@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Brian Starkey <brian.starkey@arm.com> Link: https://patchwork.freedesktop.org/patch/229038/
-
Brian Starkey authored
Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to enable userspace to get a fence which will signal once the writeback is complete. It is not allowed to request an out-fence without a framebuffer attached to the connector. A timeline is added to drm_writeback_connector for use by the writeback out-fences. In the case of a commit failure or DRM_MODE_ATOMIC_TEST_ONLY, the fence is set to -1. Changes from v2: - Rebase onto Gustavo Padovan's v9 explicit sync series - Change out_fence_ptr type to s32 __user * - Set *out_fence_ptr to -1 in drm_atomic_connector_set_property - Store fence in drm_writeback_job Gustavo Padovan: - Move out_fence_ptr out of connector_state - Signal fence from drm_writeback_signal_completion instead of in driver directly Changes from v3: - Rebase onto commit 7e9081c5 ("drm/fence: fix memory overwrite when setting out_fence fd") (change out_fence_ptr to s32 __user *, for real this time.) - Update documentation around WRITEBACK_OUT_FENCE_PTR Signed-off-by: Brian Starkey <brian.starkey@arm.com> [rebased and fixed conflicts] Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/229036/
-
Brian Starkey authored
Writeback connectors represent writeback engines which can write the CRTC output to a memory framebuffer. Add a writeback connector type and related support functions. Drivers should initialize a writeback connector with drm_writeback_connector_init() which takes care of setting up all the writeback-specific details on top of the normal functionality of drm_connector_init(). Writeback connectors have a WRITEBACK_FB_ID property, used to set the output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the supported writeback formats to userspace. When a framebuffer is attached to a writeback connector with the WRITEBACK_FB_ID property, it is used only once (for the commit in which it was included), and userspace can never read back the value of WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is attached to a CRTC. Changes since v1: - Added drm_writeback.c + documentation - Added helper to initialize writeback connector in one go - Added core checks - Squashed into a single commit - Dropped the client cap - Writeback framebuffers are no longer persistent Changes since v2: Daniel Vetter: - Subclass drm_connector to drm_writeback_connector - Relax check to allow CRTC to be set without an FB - Add some writeback_ prefixes - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary Gustavo Padovan: - Add drm_writeback_job to handle writeback signalling centrally Changes since v3: - Rebased - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS Chances since v4: - Embed a drm_encoder inside the drm_writeback_connector to reduce the amount of boilerplate code required from the drivers that are using it. Changes since v5: - Added Rob Clark's atomic_commit() vfunc to connector helper funcs, so that writeback jobs are committed from atomic helpers - Updated create_writeback_properties() signature to return an error code rather than a boolean false for failure. - Free writeback job with the connector state rather than when doing the cleanup_work() Changes since v7: - fix extraneous use of out_fence that is only introduced in a subsequent patch. Changes since v8: - whitespace changes pull from subsequent patch Changes since v9: - Revert the v6 changes that free the writeback job in the connector state cleanup and return to doing it in the cleanup_work() function Signed-off-by: Brian Starkey <brian.starkey@arm.com> [rebased and fixed conflicts] Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com> [rebased and added atomic_commit() vfunc for writeback jobs] Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/229037/
-
Christian König authored
Neither used nor correctly implemented anywhere. Just completely remove the interface. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/226645/
-
Christian König authored
The device parameter is completely unused because it is available in the attachment structure as well. v2: fix kerneldoc as well Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/226643/
-
Daniel Vetter authored
Same justification as for drm_gem_fb_prepare_fb. Cc: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-9-daniel.vetter@ffwll.ch Link: https://patchwork.freedesktop.org/patch/msgid/20180409085134.27321-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
I've done a lot of history digging. The first signs of this optimization was introduced in i915: commit 25067bfc Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Wed Sep 10 12:03:17 2014 -0300 drm/i915: pin sprite fb only if it changed without much justification. Pinning already pinned stuff is real cheap (it's just obj->pin_count++ really), and the missing implicit sync was entirely forgotten about it seems. It's at least not mentioned anywhere it the commit message. It was also promptly removed shortly afterwards in commit ea2c67bb Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Dec 23 10:41:52 2014 -0800 drm/i915: Move to atomic plane helpers (v9) again without really mentioning the side-effect that plane updates with the same fb now again obey implicit syncing. Note that this only ever applied to the plane_update hook, all other legacy entry points (set_base, page_flip) always obeyed implicit sync in the drm/i915 driver. The real source of this code here seems to be msm, copied to vc4, then copied to tinydrm. I've also tried to dig around in all available msm sources, but the corresponding check for fb != old_fb is present ever since the initial merge in commit cf3a7e4c Author: Rob Clark <robdclark@gmail.com> Date: Sat Nov 8 13:21:06 2014 -0500 drm/msm: atomic core bits The only older version I've found of msm atomic code predates the atomic helpers, and so didn't even use any of this. It also does not have a corresponding check (because it simply did no implicit sync at all). I've chatted with Rob on irc, and he didn't remember the reason for this either. Note we had epic amounts of fun with too much syncing against _vblank_, especially around cursor updates. But I don't ever discussing a need for less syncing against implicit fences. Also note that explicit fencing allows you to sidetrack all of this, at least for all the drivers correctly implemented using drm_atomic_set_fence_for_plane(). Given that it seems to be an accident of history, and that big drivers like i915 (and also nouveau it seems, I didn't follow the amdgpu/radeon sync code to figure this out properly there) never have done it, let's remove this. Cc: Rob Clark <robdclark@gmail.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: "Noralf Trønnes" <noralf@tronnes.org> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-8-daniel.vetter@ffwll.ch
-
- 18 Jun, 2018 3 commits
-
-
Sandy Huang authored
The vop irq is shared between vop and iommu and irq probing in the iommu driver moved to the probe function recently. This can in some cases lead to a stall if the irq is triggered while the vop driver still has it disabled, but the vop irq handler gets called. But there is no real need to disable the irq, as the vop can simply also track its enabled state and ignore irqs in that case. For this we can simply check the power-domain state of the vop, similar to how the iommu driver does it. So remove the enable/disable handling and add appropriate condition to the irq handler. changes in v2: - move to just check the power-domain state - add clock handling changes in v3: - clarify comment to speak of runtime-pm not power-domain changes in v4: - address Marc's comments (clk-enable WARN_ON and style improvement) Fixes: d0b912bd ("iommu/rockchip: Request irqs in rk_iommu_probe()") Cc: stable@vger.kernel.org Signed-off-by: Sandy Huang <hjc@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180612132028.27490-3-heiko@sntech.de
-
Heiko Stuebner authored
Judging from the iommu code, both the hclk and aclk are necessary for register access. Split them off into separate functions from the regular vop enablement, so that we can use them elsewhere as well. Fixes: d0b912bd ("iommu/rockchip: Request irqs in rk_iommu_probe()") [prerequisite change for the actual fix] Cc: stable@vger.kernel.org Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Tomasz Figa <tfiga@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180612132028.27490-2-heiko@sntech.de
-
Haneen Mohammed authored
This patch add checks for atomic_[duplicate/destroy]_state of drm_[connector/crtc/plane]_funcs for atomic drivers in the relevant drm_*_init functions since these callback are mandatory for atomic drivers. Update the kerneldoc comments for those callbacks. Signed-off-by: Haneen Mohammed <hamohammed.sa@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180525012555.GA8448@haneen-vb
-
- 16 Jun, 2018 2 commits
-
-
Lin Huang authored
We use jitter bypass mode for spdif, so do not need to set jitter mode related bit in SPDIF_CTRL_ADDR register. But of course we need to keep the SPDIF_ENABLE bit. Signed-off-by: Chris Zhong <zyw@rock-chips.com> Signed-off-by: Lin Huang <hl@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/1526979222-32478-1-git-send-email-hl@rock-chips.com
-
Julia Lawall authored
The device node iterators perform an of_node_get on each iteration, so a jump out of the loop requires an of_node_put. The semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr): // <smpl> @@ expression root,e; local idexpression child; iterator name for_each_child_of_node; @@ for_each_child_of_node(root, child) { ... when != of_node_put(child) when != e = child + of_node_put(child); ? break; ... } ... when != child // </smpl> Fixes: 34cc0aa2 ("drm/rockchip: Add support for Rockchip Soc LVDS") Cc: stable@vger.kernel.org Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/1527102436-13447-6-git-send-email-Julia.Lawall@lip6.fr
-
- 15 Jun, 2018 4 commits
-
-
Alexandru Gheorghe authored
drm_private_state has a back pointer to the drm_atomic_state, however that was not initialized in drm_atomic_get_private_obj_state after duplication, as it is the case for other drm atomic getters Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/1527701452-1934-1-git-send-email-alexandru-cosmin.gheorghe@arm.comSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Ville Syrjälä authored
Print out the modeline when we reject a bad user mode. Avoids having to guess why it was rejected. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611193403.16118-2-ville.syrjala@linux.intel.comReviewed-by: Harry Wentland <harry.wentland@amd.com>
-
Ville Syrjälä authored
Print the id/name of the object we're dealing with. Makes it easier to figure out what's going on. Also toss in a few extra debug prints that might be useful. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611193403.16118-1-ville.syrjala@linux.intel.comReviewed-by: Harry Wentland <harry.wentland@amd.com>
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Fixes for 4.18. Highlights: - Fixes for gfxoff on Raven - Remove an ATPX quirk now that the root cause is fixed - Runtime PM fixes - Vega20 register header update - Wattman fixes - Misc bug fixes Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180614141428.2909-1-alexander.deucher@amd.com
-
- 14 Jun, 2018 2 commits
-
-
Kenneth Feng authored
Fix the issue that SCLK&MCLK can't be set higher than dpm7 when OD is enabled in SMU7. v2: fix warning (Alex) Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Acked-by: Rex Zhu<rezhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Inki Dae authored
This patch makes RC_CORE to be selected with this driver. sil_sii8620 driver calls remote controller interfaces directly so RC_CORE should be enabled mandatorily. And some boards not using remote controller device don't really need to know that RC_CORE config should be enabled to use sil_sii8620 driver only for HDMI. Changelog v2: - select INPUT because compiling will fail without INPUT. Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1527154379-31886-1-git-send-email-inki.dae@samsung.com
-
- 13 Jun, 2018 4 commits
-
-
Evan Quan authored
Gfxoff is already enabled in amdgpu_device_ip_set_powergating_state. So, no need to enable it again in pp_late_init. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Evan Quan authored
WARN_ON possible buffer overflow and avoid unnecessary dereference. v2: change BUG_ON to WARN_ON Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Shaoyun Liu authored
The register field hsas been changed in df 3.6, update to correct setting Signed-off-by: Shaoyun Liu <Shaoyun.Liu@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-
Rex Zhu authored
As hw required, soc clock must large than mclk, So we set max soc clock to OD Max Memory clk. But on workstation, vbios do not support OD feature, the OD max memory clock is equal to 0. In this case, driver can support underclocking. and set od max memory clock to the value in highest memory dpm level. So the od max memory clock should be less than highest soc clock. and driver should not change the soc clock. caused by commit ca57b9b0a156 ("drm/amd/pp: Allow underclocking when od table is empty in vbios") Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
-