PORT_TX_DFLEXDPMLE1 is a FIA register so move it to intel_tc.c where we
access other FIA registers. In Tiger Lake we have multiple/modular FIAs
so it makes sense to start moving all access to their registers to a
common place.
While at it, make it clear that we will only ever call this function
for ports with TC phy. Previously we were relying on tc_mode being
TC_PORT_TBT_ALT for combo phy ports. However it's confusing since in
this same function we have checks for is_tc_port. Also, if we manage to
make each phy access only their own field, we may in future add them as
a union inside intel_digital_port.
v2: Fix coding style while moving the code
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190708172815.6814-4-lucas.demarchi@intel.com
Only dynamic mode objects, i.e. those which are refcounted and have a free
callback, can be added while the overall drm_device is visible to
userspace. All others must be added before drm_dev_register and
removed after drm_dev_unregister.
Small issue around drivers still using the load/unload callbacks, we
need to make sure we set dev->registered so that load/unload code in
these callbacks doesn't trigger false warnings. Only a small
adjustement in drm_dev_register was needed.
Motivated by some irc discussions about object ids of dynamic objects
like blobs become invalid, and me going on a bit an audit spree.
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190614061723.1173-1-daniel.vetter@ffwll.ch
The named mode could be invalid and then cmdline parser misses to validate
mode's dimensions, happily adding 0x0 mode as a valid mode. One case where
this happens is NVIDIA Tegra devices that are using downstream bootloader
which adds "video=tegrafb" to the kernel's cmdline and thus upstream Tegra
DRM driver fails to probe because of the invalid mode.
Fixes: 3aeeb13d89 ("drm/modes: Support modes names on the command line")
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190709145151.23086-1-digetx@gmail.com
We need to serialize access to the psp ring if there are multiple
callers at runtime.
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This RELEASE_MEM use has the Release semantic, which means we should write
back but not invalidate. Invalidations only make sense with the Acquire
semantic (ACQUIRE_MEM), or when RELEASE_MEM is used to do the combined
Acquire-Release semantic, which is a barrier, not a fence.
The undesirable side effect of doing invalidations for the Release semantic
is that it invalidates caches while shaders are running, because the Release
can execute in the middle of the next IB.
UMDs should use ACQUIRE_MEM at the beginning of IBs. Doing cache
invalidations for a fence (like in this case) doesn't do anything
for correctness.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Pull Documentation updates from Jonathan Corbet:
"It's been a relatively busy cycle for docs:
- A fair pile of RST conversions, many from Mauro. These create more
than the usual number of simple but annoying merge conflicts with
other trees, unfortunately. He has a lot more of these waiting on
the wings that, I think, will go to you directly later on.
- A new document on how to use merges and rebases in kernel repos,
and one on Spectre vulnerabilities.
- Various improvements to the build system, including automatic
markup of function() references because some people, for reasons I
will never understand, were of the opinion that
:c:func:``function()`` is unattractive and not fun to type.
- We now recommend using sphinx 1.7, but still support back to 1.4.
- Lots of smaller improvements, warning fixes, typo fixes, etc"
* tag 'docs-5.3' of git://git.lwn.net/linux: (129 commits)
docs: automarkup.py: ignore exceptions when seeking for xrefs
docs: Move binderfs to admin-guide
Disable Sphinx SmartyPants in HTML output
doc: RCU callback locks need only _bh, not necessarily _irq
docs: format kernel-parameters -- as code
Doc : doc-guide : Fix a typo
platform: x86: get rid of a non-existent document
Add the RCU docs to the core-api manual
Documentation: RCU: Add TOC tree hooks
Documentation: RCU: Rename txt files to rst
Documentation: RCU: Convert RCU UP systems to reST
Documentation: RCU: Convert RCU linked list to reST
Documentation: RCU: Convert RCU basic concepts to reST
docs: filesystems: Remove uneeded .rst extension on toctables
scripts/sphinx-pre-install: fix out-of-tree build
docs: zh_CN: submitting-drivers.rst: Remove a duplicated Documentation/
Documentation: PGP: update for newer HW devices
Documentation: Add section about CPU vulnerabilities for Spectre
Documentation: platform: Delete x86-laptop-drivers.txt
docs: Note that :c:func: should no longer be used
...
Pull sound updates from Takashi Iwai:
"Many updates in this development cycle are found in ASoC where it got
a wide range of changes for the continued refactoring.
Some highlights are below.
ASoC:
- Continued refactoring work by Morimoto-san toward the full
componentization; the changes are seen allover the places
- Support for force disconnecting muxes in DAPM
- Continued development of ASoC Intel SOF stuff
- New drivers for Cirrus Logic CS47L35, CS47L85 and CS47L90, Conexant
CX2072X, Realtek RT1011 and RT1308
HD-audio:
- More fixes and adjustments for ASoC SOF HD-audio
- Fix for resume problem on some Realtek codecs
USB-audio:
- A few fixes for the issues reported by syzbot USB fuzzer
- Fix for UAC2 extension unit parser
- Quirks for Line6 Helix, Emgaic Unitor 8
FireWire:
- Lots of code refactoring and fixes in most of its components"
* tag 'sound-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (626 commits)
ALSA: firewire-lib: code refactoring for local variables
ALSA: firewire-lib: code refactoring for post operation to data block counter
ALSA: firewire-lib: code refactoring for error path of parser for CIP header
ALSA: firewire-lib: fix different data block counter between probed event and transferred isochronous packet
ALSA: firewire-lib: fix initial value of data block count for IR context without CIP_DBC_IS_END_EVENT
ALSA: firewire-lib/fireface: fix initial value of data block counter for IR context with CIP_NO_HEADER
ALSA: firewire-lib: fix invalid length of rx packet payload for tracepoint events
ALSA: usb-audio: fix Line6 Helix audio format rates
firewire-motu: fix wrong reference count for stream functionality at error path of rawmidi interface
ALSA: firewire-digi00x: fix wrong reference count for stream functionality at error path of rawmidi interface
ALSA: dice: fix wrong reference count for stream functionality at error path of rawmidi interface
ALSA: oxfw: fix wrong reference count for stream functionality at error path of rawmidi interface
ALSA: fireworks: fix wrong reference count for stream functionality at error path of rawmidi interface
ALSA: bebob: fix wrong reference count for stream functionality at error path of rawmidi interface
ASoC: SOF: Intel: implement runtime idle for CNL/APL
ASoC: SOF: add runtime idle callback
ASoC: hdac_hdmi: report codec link up/down status to bus
ASoC: SOF: debug: fix possible memory leak in sof_dfsentry_write()
ASoC: sunxi: sun50i-codec-analog: Add earpiece
ASoC: rt5665: remove redundant assignment to variable idx
...
For consistency clear the icl_port_dplls from the new crtc state, when
releasing the DPLLs from the old crtc state. Leaving them set could
result in releasing the same PLLs multiple times from the same CRTC
state incorrectly (if the same CRTC was first used for a TypeC port then
for a combo PHY port).
Leaving the stale pointers behind happens not to cause a problem atm
(since the incorrect releasing will be a NOP), but we need to fix that
for consistency.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190708140735.20198-2-imre.deak@intel.com
The function drm_client_close is declared as static and marked as
EXPORT_SYMBOL. It's a bit confusing for an internal function to be
exported. The area of visibility for such function is its .c file
and all other modules. Other *.c files of the same module can't use it,
despite all other modules can. Relying on the fact that this is the
internal function and it's not a crucial part of the API, the patch
removes the EXPORT_SYMBOL marking of drm_client_close.
Signed-off-by: Denis Efremov <efremov@linux.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190703170150.32548-1-efremov@linux.com
This patch replaces mgag200's framebuffer console with DRM's generic
implememtation. All respective code is being removed from the driver.
The console is set up with a shadow buffer. The actual buffer object is
not permanently pinned in video ram, but just another buffer object that
the driver moves in and out of vram as necessary. The driver's function
mga_crtc_do_set_base() used to contain special handling for the framebuffer
console. With the new generic framebuffer, the driver does not need this
code an longer.
For consistency, this patch also changes the preferred framebuffer depth.
The original code used 24 bpp by default and 32 bpp for the framebuffer. As
24 bpp is not well supported by userspace anyway, setting 32 bpp as default
makes sense.
v2:
* rely on fbdev helpers error messages
* document changes to preferred depth
* dirty function no longer required
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/315832/
The bochs driver (and virtual hardware) requires buffer objects to
reside in video ram to display them to the screen. So it can not
display the framebuffer console because the respective buffer object
is permanently pinned in system memory.
Using a shadow buffer for the console solves this problem. The console
emulation will pin the buffer object only during updates from the shadow
buffer. Otherwise, the bochs driver can freely relocated the buffer
between system memory and video ram.
v2:
* select shadow FB via struct drm_mode_config.prefer_shadow_fbdev
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/315833/
This patch replaces ast's framebuffer console with DRM's generic
implememtation. All respective code is being removed from the driver.
The console is set up with a shadow buffer. The actual buffer object is
not permanently pinned in video ram, but just another buffer object that
the driver moves in and out of vram as necessary. The driver's function
ast_crtc_do_set_base() used to contain special handling for the framebuffer
console. With the new generic framebuffer, the driver does not need this
code an longer.
v2:
* use drm_fb_helper_set_suspend_unlocked() in ast_drm_{thaw,freeze}()
* dirty function no longer required
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/315835/
Generic framebuffer emulation uses a shadow buffer for framebuffers with
dirty() function. If drivers want to use the shadow FB without such a
function, they can now set prefer_shadow or prefer_shadow_fbdev in their
mode_config structures. The former flag is exported to userspace, the
latter flag is fbdev-only.
v3:
* only schedule dirty worker if fbdev uses shadow fb
* test shadow fb settings with boolean operators
* use bool for struct drm_mode_config.prefer_shadow_fbdev
* fix documentation comments
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Tested-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/315834/
This patch changes DRM clients to not map the buffer by default. The
buffer, like any buffer object, should be mapped and unmapped when
needed.
An unmapped buffer object can be evicted to system memory and does
not consume video ram until displayed. This allows to use generic fbdev
emulation with drivers for low-memory devices, such as ast and mgag200.
This change affects the generic framebuffer console. HW-based consoles
map their console buffer once and keep it mapped. Userspace can mmap this
buffer into its address space. The shadow-buffered framebuffer console
only needs the buffer object to be mapped during updates. While not being
updated from the shadow buffer, the buffer object can remain unmapped.
Userspace will always mmap the shadow buffer.
v2:
* change DRM client to not map buffer by default
* manually map client buffer for fbdev with HW framebuffer
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/315830/
DRM clients, such as the fbdev emulation, have their buffer objects
mapped by default. Mapping a buffer implicitly prevents its relocation.
Hence, the buffer may permanently consume video memory while it's
allocated. This is a problem for drivers of low-memory devices, such as
ast, mgag200 or older framebuffer hardware, which will then not have
enough memory to display other content (e.g., X11).
This patch introduces drm_client_buffer_vmap() and _vunmap(). Internal
DRM clients can use these functions to unmap and remap buffer objects
as needed.
There's no reference counting for vmap operations. Callers are expected
to either keep buffers mapped (as it is now), or call vmap and vunmap
in pairs around code that accesses the mapped memory.
v2:
* remove several duplicated NULL-pointer checks
v3:
* style and typo fixes
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Link: https://patchwork.freedesktop.org/patch/315831/
On 32-bit architectures, dividing a 64-bit integer in the kernel
leads to a link error:
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Change the two recently introduced instances to a multiply+shift
operation that is also much cheaper on 32-bit architectures.
We can do that here, since both of them are really 32-bit numbers
that change a few percent.
Fixes: bedbbe6af4 ("drm/amd/display: Move link functions from dc to dc_link")
Fixes: f18bc4e53a ("drm/amd/display: update calculated bounding box logic for NV")
Acked-by: Slava Abramov <slava.abramov@amd.com>
Tested-by: Slava Abramov <slava.abramov@amd.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If smu_get_current_rpm() fails, we can't use the output,
as that may be uninitialized:
drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:3023:8: error: variable 'current_rpm' is used uninitialized whenever '?:' condition is false [-Werror,-Wsometimes-uninitialized]
ret = smu_get_current_rpm(smu, ¤t_rpm);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:735:3: note: expanded from macro 'smu_get_current_rpm'
((smu)->funcs->get_current_rpm ? (smu)->funcs->get_current_rpm((smu), (speed)) : 0)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:3024:12: note: uninitialized use occurs here
percent = current_rpm * 100 / pptable->FanMaximumRpm;
^~~~~~~~~~~
drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:3023:8: note: remove the '?:' if its condition is always true
ret = smu_get_current_rpm(smu, ¤t_rpm);
^
drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:735:3: note: expanded from macro 'smu_get_current_rpm'
((smu)->funcs->get_current_rpm ? (smu)->funcs->get_current_rpm((smu), (speed)) : 0)
^
drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:3020:22: note: initialize the variable 'current_rpm' to silence this warning
uint32_t current_rpm;
Propagate the error code in that case.
Fixes: ee0db82027 ("drm/amd/powerplay: move PPTable_t uses into asic level")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
