aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2019-07-25drm/tinydrm: Split struct mipi_dbi in twoNoralf Trønnes7-83/+84
Split struct mipi_dbi into an interface part and a display pipeline part. The interface part can be used by drivers that need to initialize the controller, but that won't upload the framebuffer over this interface. MIPI DBI supports 3 interface types: - A. Motorola 6800 type parallel bus - B. Intel 8080 type parallel bus - C. SPI type with 3 options: I've embedded the SPI type specifics in the mipi_dbi struct to avoid adding unnecessary complexity. If more interface types will be supported in the future, the type specifics might have to be split out. Rename functions to match the new struct mipi_dbi_dev: - drm_to_mipi_dbi() -> drm_to_mipi_dbi_dev(). - mipi_dbi_init*() -> mipi_dbi_dev_init*(). Cc: Eric Anholt <eric@anholt.net> Cc: David Lechner <david@lechnology.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: David Lechner <david@lechnology.com> Acked-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190722104312.16184-5-noralf@tronnes.org
2019-07-25drm/tinydrm: Rename remaining variable mipi -> dbidevNoralf Trønnes7-161/+161
struct mipi_dbi is going to be split into an interface part and a display pipeline part. The interface part can be used by drivers that need to initialize the controller, but that won't upload the framebuffer over this interface. tinydrm uses the variable name 'mipi' but this is not a good name since MIPI refers to a lot of standards. This patch changes the variable name to 'dbidev' where it refers to the pipeline part of struct mipi_dbi. Cc: Eric Anholt <eric@anholt.net> Cc: David Lechner <david@lechnology.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: David Lechner <david@lechnology.com> Acked-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190722104312.16184-4-noralf@tronnes.org
2019-07-25drm/tinydrm: Rename variable mipi -> dbiNoralf Trønnes7-259/+281
struct mipi_dbi is going to be split into an interface part and a display pipeline part. The interface part can be used by drivers that need to initialize the controller, but that won't upload the framebuffer over this interface. tinydrm uses the variable name 'mipi' but this is not a good name since MIPI refers to a lot of standards. This patch changes the variable name to 'dbi' where it refers to the interface part of struct mipi_dbi. Functions that use both future parts will have both variables temporarily pointing to the same structure. Cc: Eric Anholt <eric@anholt.net> Cc: David Lechner <david@lechnology.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: David Lechner <david@lechnology.com> Acked-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190722104312.16184-3-noralf@tronnes.org
2019-07-25drm/tinydrm/mipi-dbi: Move cmdlock mutex initNoralf Trønnes1-2/+2
cmdlock protects command execution so put it in mipi_dbi_spi_init() where it conceptually belongs. This is prep work for the splitting of struct mipi_dbi. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190722104312.16184-2-noralf@tronnes.org
2019-07-25drm/i915/uc: Unify uC firmware uploadDaniele Ceraolo Spurio4-155/+93
The way we load the firmwares is the same for both GuC and HuC, the only difference is in the wopcm destination address and the dma flags, so we easily can move the logic to a common function and pass in offset and flags. The only other difference in the uplaod path are some the extra steps that guc does before and after the xfer, but those don't require the guc fw to be pinned in ggtt and can safely be performed before calling the uc_upload function. Note that this patch re-introduces the dma xfer wait for guc loading that was removed with "drm/i915/guc: Propagate the fw xfer timeout". This is not going to slow us down on a successful load (the dma has to complete before fw init can start), but could slightly increase the timeout in case of a fw init error. v2: use _fw variants for uncore accesses (Chris), fix guc_fw status on failed wait. v3: use dev_err and print DMA_CTRL (Chris) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190725001813.4740-9-daniele.ceraolospurio@intel.com
2019-07-25drm/i915/uc: Plumb the gt through fw_uploadDaniele Ceraolo Spurio4-56/+48
The gt is our new central structure for uc-related code, so we can use that instead of jumping back to i915 via the fw object. Since we have it in the upload function it is easy to pass it through the lower levels of the xfer process instead of continuosly jumping via uc_fw->uc->gt, which will also make things a bit cleaner for the next patch. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190725001813.4740-8-daniele.ceraolospurio@intel.com
2019-07-25drm/i915/huc: Copy huc rsa only onceDaniele Ceraolo Spurio3-22/+23
The binary is perma-pinned and the rsa is not going to change, so copy it only once and not on every load. v2: onion unwind (Chris) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Fernando Pacheco <fernando.pacheco@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1 Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-7-daniele.ceraolospurio@intel.com
2019-07-25drm/i915/uc: Move xfer rsa logic to common functionDaniele Ceraolo Spurio4-9/+29
The way we copy the RSA is the same for GuC and HuC, so we can move the logic in a common function. this will also make any update needed for local memory easier. v2: return the number of copied bytes and check it (Chris) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1 Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-6-daniele.ceraolospurio@intel.com
2019-07-25drm/i915/uc: Unify uc_fw status trackingDaniele Ceraolo Spurio8-84/+92
We currently track fetch and load status separately, but the 2 are actually sequential in the uc lifetime (fetch must complete before we can attempt the load!). Unifying the 2 variables we can better follow the sequential states and improve our trackng of the uC state. Also, sprinkle some GEM_BUG_ON to make sure we transition correctly between states. v2: rename states, add the running state (Michal), drop some logs in the fetch path (Michal, Chris) v3: re-rename states, extend early status check to all helpers (Michal) Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-5-daniele.ceraolospurio@intel.com
2019-07-25drm/i915/uc: Unify uC FW selectionDaniele Ceraolo Spurio4-196/+164
Instead of having 2 identical functions for GuC and HuC firmware selection, we can unify the selection logic and just use different lists based on FW type. Note that the revid is not relevant for current blobs, but the upcoming CML will be identified as CFL rev 5, so by considering the revid we're ready for that. v2: rework blob list defs (Michal), add order check (Chris), fuse GuC and HuC lists into one. v3: remove difference between no uC HW and no uC FW, simplify related selection code, check the whole fw list (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v2 Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-4-daniele.ceraolospurio@intel.com
2019-07-25drm/i915: Fix handling of non-supported uCDaniele Ceraolo Spurio5-41/+31
There are 2 issues around handling of missing uC support: - We treat lack of uC HW and lack of uC FW definition as 2 different cases, but both of them mean that we don't support the uC on the platform we're running on. - We rely on the modparam to decide if we can take uC paths or not, but we don't sanitize it if it is set incorrectly on platform with no uC support. To fix both of them, unify the 2 cases in a single one and sanitize the modparam on invalid configuration (after printing an error message). The log has been adapted as well, since the user doesn't care why we don't support GuC/HuC (no HW or no FW), just that we do not. Developers can easily find the answer based on the platform, so we can simplify the log. Correcting the modparam has been preferred over failing the load since this is what we usually do for non-supported feature (e.g. the now gone enable_ppgtt would fall back to the highest supported PPGTT mode if the selected one was not available). Note that this patch purposely doesn't change the behavior for platforms that do have uC support, in which case we will still fail if enable_guc is set and the firmware is not available on the system. Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-3-daniele.ceraolospurio@intel.com
2019-07-25drm/i915/uc: Unify uC platform checkDaniele Ceraolo Spurio13-32/+21
We have several HAS_* checks for GuC and HuC but we mostly use HAS_GUC and HAS_HUC, with only 1 exception. Since our HW always has either both uC or neither of them, just replace all the checks with a unified HAS_UC. v2: use HAS_GT_UC (Michal) v3: fix comment (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-2-daniele.ceraolospurio@intel.com
2019-07-24iommu/io-pgtable: Rename iommu_gather_ops to iommu_flush_opsWill Deacon1-1/+1
In preparation for TLB flush gathering in the IOMMU API, rename the iommu_gather_ops structure in io-pgtable to iommu_flush_ops, which better describes its purpose and avoids the potential for confusion between different levels of the API. $ find linux/ -type f -name '*.[ch]' | xargs sed -i 's/gather_ops/flush_ops/g' Signed-off-by: Will Deacon <will@kernel.org>
2019-07-24drm/i915/guc: Set GuC init params only onceDaniele Ceraolo Spurio3-67/+83
All the GuC objects are perma-pinned, so their offset can't change at runtime. We can therefore set (and log!) the parameters only once during boot. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@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/20190724085849.18047-1-chris@chris-wilson.co.uk
2019-07-24drm/mgag200: Don't unpin the current cursor image's buffer.Thomas Zimmermann1-1/+0
Currently the displayed cursor buffer might be evicted from video memory. Not unpinning the BO fixes this problem. At this point, pixels_current also references the BO and it will be unpinned during the next cursor update. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Sam Ravnborg <sam@ravnborg.org> Fixes: 94dc57b10399 ("drm/mgag200: Rewrite cursor handling") Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190723075425.24028-4-tzimmermann@suse.de
2019-07-24drm/mgag200: Set cursor scanout address to correct BOThomas Zimmermann1-1/+1
The hardware requires the correct memory address of the buffer. Currently the same BO's address is programmed unconditionally, so only every second cursor update actually becomes visible. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Sam Ravnborg <sam@ravnborg.org> Fixes: 94dc57b10399 ("drm/mgag200: Rewrite cursor handling") Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190723075425.24028-3-tzimmermann@suse.de
2019-07-24drm/mgag200: Pin displayed cursor BO to video memoryThomas Zimmermann1-1/+1
The cursor BO has to be pinned to video ram while it's being displayed. With the current code, the BO might be pinned to system memory instead. The patch fixes this problem. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Sam Ravnborg <sam@ravnborg.org> Fixes: 94dc57b10399 ("drm/mgag200: Rewrite cursor handling") Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190723075425.24028-2-tzimmermann@suse.de
2019-07-23drm/amd/display: Set enabled to false at start of audio disableNicholas Kazlauskas1-2/+2
[Why] In an effort to stop redundant calls to dce110_disable_audio_stream the audio->enabled flag was added to the audio resource struct. While this state probably shouldn't have been tracked on the audio struct itself it still works fine for some sequences. However, it does not work for cases where we're freeing the audio resource (such as hotplugs) or when dynamic audio is enabled. In these cases the pipe_ctx->stream_res.audio = NULL before we can set audio->enabled = false. The next time we acquire the audio resource such as on hotplug the audio will not be enabled for the stream since DC thinks it's still enabled. Audio state tracking should cover this sequence. [How] Set audio->enabled = false at the start as long as we have pipe_ctx->stream_res.audio. Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Zhan Liu <Zhan.Liu@amd.com> Acked-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-23drm/i915: Use dev_get_drvdataChuhong Yuan1-8/+4
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by: Chuhong Yuan <hslester96@gmail.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/20190723103915.3964-1-hslester96@gmail.com
2019-07-23drm/i915/huc: fix status checkDaniele Ceraolo Spurio1-1/+1
Fix botched refactoring of the code that uncorrectly split a check on a bool, treating it as a u32. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 84b1ca2f0e68 ("drm/i915/uc: prefer intel_gt over i915 in GuC/HuC paths") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190723153733.19401-1-daniele.ceraolospurio@intel.com
2019-07-23drm/i915: Squelch nop wait-for-idle traceChris Wilson1-4/+4
If the system is already idle, omit the GEM_TRACE saying we are about to wait for idle. It looks confusing in the logs to see a continual stream of wait-for-idle, as one immediately assumes it is stuck in a loop. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190723091218.5886-1-chris@chris-wilson.co.uk
2019-07-23drm/tinydrm: Move tinydrm_display_pipe_init() to mipi-dbiNoralf Trønnes8-198/+81
tinydrm_display_pipe_init() has only one user now, so move it to mipi-dbi. Changes: - Remove drm_connector_helper_funcs.detect, it's always connected. - Store the connector and mode in mipi_dbi instead of it's own struct. Otherwise remove some leftover tinydrm-helpers.h inclusions. Cc: Eric Anholt <eric@anholt.net> Cc: David Lechner <david@lechnology.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-12-noralf@tronnes.org
2019-07-23drm/tinydrm/mipi-dbi: Add mipi_dbi_init_with_formats()Noralf Trønnes2-40/+54
The MIPI DBI standard support more pixel formats than what this helper supports. Add an init function that lets the driver use different format(s). This avoids open coding mipi_dbi_init() in st7586. st7586 sets preferred_depth but this is not necessary since it only supports one format. v2: Forgot to remove the mipi->rotation assignment in st7586, mipi_dbi_init_with_formats() handles it. Cc: David Lechner <david@lechnology.com> Acked-by: David Lechner <david@lechnology.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: David Lechner <david@lechnology.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-11-noralf@tronnes.org
2019-07-23drm/tinydrm/repaper: Don't use tinydrm_display_pipe_init()Noralf Trønnes1-5/+53
tinydrm.ko is going away so let's implement a connector. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-10-noralf@tronnes.org
2019-07-23drm/tinydrm: Move tinydrm_machine_little_endian()Noralf Trønnes1-3/+12
The tinydrm helper is going away so move it into the only user mipi-dbi. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-9-noralf@tronnes.org
2019-07-23drm/tinydrm: Move tinydrm_spi_transfer()Noralf Trønnes5-76/+54
This is only used by mipi-dbi drivers so move it there. The reason this isn't moved to the SPI subsystem is that it will in a later patch pass a dummy rx buffer for SPI controllers that need this. Low memory boards (64MB) can run into a problem allocating such a "large" contiguous buffer on every transfer after a long up time. This leaves a very specific use case, so we'll keep the function here. mipi-dbi will first go through a refactoring though, before this will be done. Remove SPI todo entry now that we're done with the tinydrm.ko SPI code. v2: Drop moving the mipi_dbi_spi_init() declaration (Sam) Cc: David Lechner <david@lechnology.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: : David Lechner <david@lechnology.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-8-noralf@tronnes.org
2019-07-23drm/tinydrm: Clean up tinydrm_spi_transfer()Noralf Trønnes3-40/+8
Prep work before moving the function to mipi-dbi. tinydrm_spi_transfer() was made to support one class of drivers in drivers/staging/fbtft that has not been converted to DRM yet, so strip away the unused functionality: - Start byte (header) is not used. - No driver relies on the automatic 16-bit byte swapping on little endian machines with SPI controllers only supporting 8 bits per word. Other changes: - No need to initialize ret - No need for the WARN since mipi-dbi only uses 8 and 16 bpw. - Use spi_message_init_with_transfers() Cc: David Lechner <david@lechnology.com> Acked-by: : David Lechner <david@lechnology.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-7-noralf@tronnes.org
2019-07-23drm/tinydrm: Remove tinydrm_spi_max_transfer_size()Noralf Trønnes2-44/+3
spi-bcm2835 can handle >64kB buffers now so there is no need to check ->max_dma_len. The tinydrm_spi_max_transfer_size() max_len argument is not used by any callers, so not needed. Then we have the spi_max module parameter. It was added because staging/fbtft has support for it and there was a report that someone used it to set a small buffer size to avoid popping on a USB soundcard on a Raspberry Pi. In hindsight it shouldn't have been added, I should have waited for it to become a problem first. I don't know it anyone is actually using it, but since tinydrm_spi_transfer() is being moved to mipi-dbi, I'm taking the opportunity to remove it. I'll add it back to mipi-dbi if someone complains. With that out of the way, spi_max_transfer_size() can be used instead. The chosen 16kB buffer size for Type C Option 1 (9-bit) interface is somewhat arbitrary, but a bigger buffer will have a miniscule impact on transfer speed, so it's probably fine. Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-6-noralf@tronnes.org
2019-07-23drm/tinydrm: Remove spi debug buffer dumpingNoralf Trønnes2-46/+0
The SPI event tracing can dump the buffer now so no need for this. Remove the debug print from tinydrm_spi_transfer() since this info can be gleaned from the trace event. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-5-noralf@tronnes.org
2019-07-23drm/tinydrm: Use spi_is_bpw_supported()Noralf Trønnes2-34/+3
This means that tinydrm_spi_bpw_supported() can be removed. Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-4-noralf@tronnes.org
2019-07-23drm/tinydrm: Use DRM_MODE_CONNECTOR_SPINoralf Trønnes3-4/+3
tinydrm drivers announce DRM_MODE_CONNECTOR_VIRTUAL for its SPI drivers. Use the new SPI connector type instead. X server will now list the connector as Unknown instead of Virtual: X.Org X Server 1.19.2 Release Date: 2017-03-02 <...> [ 53523.905] (II) modeset(0): Output Unknown19-1 has no monitor section [ 53523.908] (II) modeset(0): EDID for output Unknown19-1 [ 53523.910] (II) modeset(0): Printing probed modes for output Unknown19-1 [ 53523.911] (II) modeset(0): Modeline "320x240"x0.0 0.00 320 320 320 320 240 240 240 240 (0.0 kHz eP) [ 53523.911] (II) modeset(0): Output Unknown19-1 connected [ 53523.912] (II) modeset(0): Using exact sizes for initial modes [ 53523.912] (II) modeset(0): Output Unknown19-1 using initial mode 320x240 +0+0 I won't chase down and fix userspace, but the new connector type will trickle out to userspace eventually. v2: Split patch in core and driver changes, expand commit message (Daniel) Cc: David Lechner <david@lechnology.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: David Lechner <david@lechnology.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-3-noralf@tronnes.org
2019-07-23drm: Add SPI connector typeNoralf Trønnes1-0/+1
tinydrm drivers announce DRM_MODE_CONNECTOR_VIRTUAL for its SPI drivers. Add a SPI connector type to match the actual connector. X will list the connector as Unknown: X.Org X Server 1.19.2 Release Date: 2017-03-02 <...> [ 53523.905] (II) modeset(0): Output Unknown19-1 has no monitor section [ 53523.908] (II) modeset(0): EDID for output Unknown19-1 [ 53523.910] (II) modeset(0): Printing probed modes for output Unknown19-1 [ 53523.911] (II) modeset(0): Modeline "320x240"x0.0 0.00 320 320 320 320 240 240 240 240 (0.0 kHz eP) [ 53523.911] (II) modeset(0): Output Unknown19-1 connected [ 53523.912] (II) modeset(0): Using exact sizes for initial modes [ 53523.912] (II) modeset(0): Output Unknown19-1 using initial mode 320x240 +0+0 The weston source shows that it will be listed as UNNAMED. v2: Split patch in core and driver changes, expand commit message (Daniel) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: David Lechner <david@lechnology.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-2-noralf@tronnes.org
2019-07-23drm/i915/selftests: Let igt_vma_partial et al breatheChris Wilson1-0/+10
Give the scheduler a chance to breathe by calling cond_resched() as some of the loops may take some time on slower machines, and so catch the attention of the watchdogs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111196 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190723095800.2820-1-chris@chris-wilson.co.uk
2019-07-23drm/i915/uc: Sanitize uC when GT is sanitizedDaniele Ceraolo Spurio2-1/+2
The microcontrollers are part of GT so it makes logical sense to have them sanitized at the same time. This also fixed an issue with our status tracking where the FW load status is not reset around hibernation. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20190723091404.6449-2-chris@chris-wilson.co.uk
2019-07-23drm/i915/uc: Gt-fy uc resetDaniele Ceraolo Spurio1-3/+3
This was the last place in gt/uc that was still using I915_READ with the global dev_priv. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@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/20190723091404.6449-1-chris@chris-wilson.co.uk
2019-07-23drm/i915: Add HDCP capability info to i915_display_info.Anshuman Gupta1-12/+28
To identify the HDCP capability of the display connected to CI systems, we need to add the hdcp capability probing in i915_display_info. This will also help to populate the HDCP capability of the CI systems to CI H/W logs maintained at https://intel-gfx-ci.01.org/hardware/. It will facilitate to determine the kms_content_protection behavior on a particular CI system. v2: Reused the intel_hdcp_info() in i915_hdcp_sink_capability_show(). [Ram] Shifted intel_hdcp_info() to the end of intel_dp_info. [Ram] v3: used seq_puts() instead of seq_pritnf(). [Ram] Cc: daniel.vetter@intel.com Cc: ramalingam.c@intel.com Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190719055513.2089-1-anshuman.gupta@intel.com
2019-07-23drm/komeda: remove set but not used variable 'old'YueHaibing1-3/+1
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/arm/display/komeda/komeda_plane.c: In function komeda_plane_atomic_duplicate_state: drivers/gpu/drm/arm/display/komeda/komeda_plane.c:161:35: warning: variable old set but not used [-Wunused-but-set-variable It is not used since commit 990dee3aa456 ("drm/komeda: Computing image enhancer internally") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20190722055627.38008-1-yuehaibing@huawei.com
2019-07-23drm/i915: Rely on spinlock protection for GPU error captureChris Wilson3-318/+193
Trust that we now have adequate protection over the low level structures via the engine->active.lock to allow ourselves to capture the GPU error state without the heavy hammer of stop_machine(). Sadly this does mean that we have to forgo some of the lesser used information (not derived from the active state) that is not controlled by the active locks. This includes the list of buffers in the ppGTT and pinned globally in the GGTT. Originally this was used to manually verify relocations, but hasn't been required for sometime and modern mesa now has the habit of ensuring that all interesting buffers within a batch are captured in their entirety (that are the auxiliary state buffers, but not the textures). A useful side-effect is that this allows us to restore error capturing for Braswell and Broxton. v2: Use pagevec for a typical arbitrary number of preallocated pages 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/20190722222847.24178-1-chris@chris-wilson.co.uk
2019-07-22drm/i915/gt: Hook up intel_context_fini()Chris Wilson5-0/+11
Prior to freeing the struct, call the fini function to cleanup the common members. Currently this only calls the debug functions to mark the structs as destroyed, but may be extended to real work in future. 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/20190718070024.21781-2-chris@chris-wilson.co.uk
2019-07-22drm/i915: Remove obsolete engine cleanupChris Wilson1-13/+2
Remove the outer layer cleanup of engine stubs; as i915_drv itself no longer tries to preallocate and so is not responsible for either the allocation or free. By the time we call the cleanup function, we already have cleaned up the engines. v2: Lack of symmetry between mmio_probe and mmio_release for handling the error cleanup. engine->destroy() is a compound function that is called earlier in the normal release as it ties together other bits of state. 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/20190718070024.21781-6-chris@chris-wilson.co.uk
2019-07-22drm/i915: Fix up broken mergeDaniel Vetter4-747/+6
Maxime didn't really compile-test this :-/ We need to re-apply commit e4fa8457b2197118538a1400b75c898f9faaf164 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jun 14 22:35:25 2019 +0200 drm/prime: Align gem_prime_export with obj_funcs.export plus make sure i915_gem_dma_buf.c doesn't get zombie-resurrect. It moved in commit 10be98a77c558f8cfb823cd2777171fbb35040f6 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue May 28 10:29:49 2019 +0100 drm/i915: Move more GEM objects under gem/ v2: Remember the selftests (Chris). Fixes: 03b0f2ce735e ("Merge v5.3-rc1 into drm-misc-next") Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190722213759.26612-1-daniel.vetter@ffwll.ch
2019-07-22drm/i915/gtt: Fix rounding for 36bChris Wilson1-7/+10
The top-level page directory for 36b is a single entry, not multiple like 32b. Fix up the rounding on the calculation of the size of the top level so that we populate the 4th level correctly for 36b. Reported-by: Jose Souza <jose.souza@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 1eda701eace2 ("drm/i915/gtt: Recursive cleanup for gen8") Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Jose Souza <jose.souza@intel.com> Tested-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190719130737.5835-1-chris@chris-wilson.co.uk
2019-07-22drm/amdgpu/smu: move fan rpm query into the asic specific codeAlex Deucher5-29/+31
On vega20, there is an SMU message to query it. On navi, it's fetched from the metrics table. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-22drm/amd/powerplay: custom peak clock freq for navi10Kevin Wang4-33/+103
v2: add function smu_default_set_performance_level as default dpm level handler. change function name smu_set_performance_level to smu_asic_set_performance_level v1: 1.NAVI10_PEAK_SCLK_XTX 1830 Mhz 2.NAVI10_PEAK_SCLK_XT 1755 Mhz 3.NAVI10_PEAK_SCLK_XL 1625 Mhz Signed-off-by: Kevin Wang <kevin1.wang@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Jack Gui <Jack.Gui@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-22drm/bridge: Improve the help text for DRM_ANALOGIX_ANX78XXFabio Estevam1-1/+1
Improve the help text for DRM_ANALOGIX_ANX78XX by adding the missing "power" word. After this change the help text matches with the ANX7814 product description from the Analogix website: https://www.analogix.com/en/products/convertersbridges/anx7814 Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190722194049.20761-1-festevam@gmail.com
2019-07-22drm: silence variable 'conn' set but not usedQian Cai1-1/+1
The "struct drm_connector" iteration cursor from "for_each_new_connector_in_state" is never used in atomic_remove_fb() which generates a compilation warning, drivers/gpu/drm/drm_framebuffer.c: In function 'atomic_remove_fb': drivers/gpu/drm/drm_framebuffer.c:838:24: warning: variable 'conn' set but not used [-Wunused-but-set-variable] Silence it by marking "conn" __maybe_unused. Signed-off-by: Qian Cai <cai@lca.pw> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1563822886-13570-1-git-send-email-cai@lca.pw
2019-07-22drm/amdgpu/smu: move fan rpm query into the asic specific codeAlex Deucher5-29/+31
On vega20, there is an SMU message to query it. On navi, it's fetched from the metrics table. Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-22drm/amdgpu: set sdma irq src num according to sdma instancesHawking Zhang1-2/+15
Otherwise, it will cause driver access non-existing sdma registers in gpu reset code path Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <Le.Ma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-22drm/amd/powerplay: remove redundancy debug log in smuKevin Wang3-13/+0
remove redundacy debug log in smu. eg: [ 6897.969447] amdgpu: [powerplay] smu 11 clk dpm feature 1 is not enabled [ 6897.969448] amdgpu: [powerplay] smu 11 clk dpm feature 1 is not enabled [ 6897.969448] amdgpu: [powerplay] smu 11 clk dpm feature 1 is not enabled [ 6899.024114] amdgpu: [powerplay] Unsupported SMU message: 38 [ 6899.024151] amdgpu: [powerplay] smu 11 clk dpm feature 1 is not enabled [ 6899.024151] amdgpu: [powerplay] smu 11 clk dpm feature 1 is not enabled [ 6899.024152] amdgpu: [powerplay] smu 11 clk dpm feature 1 is not enabled [ 6900.078296] amdgpu: [powerplay] Unsupported SMU message: 38 [ 6900.078332] amdgpu: [powerplay] smu 11 clk dpm feature 1 is not enabled [ 6900.078332] amdgpu: [powerplay] smu 11 clk dpm feature 1 is not enabled [ 6900.078333] amdgpu: [powerplay] smu 11 clk dpm feature 1 is not enabled [ 6901.133230] amdgpu: [powerplay] Unsupported SMU message: 38 Signed-off-by: Kevin Wang <kevin1.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-22drm/amd/powerplay: custom peak clock freq for navi10Kevin Wang4-33/+103
v2: add function smu_default_set_performance_level as default dpm level handler. change function name smu_set_performance_level to smu_asic_set_performance_level v1: 1.NAVI10_PEAK_SCLK_XTX 1830 Mhz 2.NAVI10_PEAK_SCLK_XT 1755 Mhz 3.NAVI10_PEAK_SCLK_XL 1625 Mhz Signed-off-by: Kevin Wang <kevin1.wang@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Jack Gui <Jack.Gui@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.