- 12 Nov, 2021 13 commits
-
-
Lyude Paul authored
Noticed this while trying to figure out the bit that we need to set in order to get cursor CRCs to come up correctly on volta+: we never actually went and added these methods to gv100_disp_core_mthd_head in drm/nouveau/nvkm/engine/disp/coregv100.c which means we don't trace their values when disp tracing is enabled in nvkm. So, fix that. Cc: Martin Peres <martin.peres@free.fr> Cc: Jeremy Cline <jcline@redhat.com> Cc: Simon Ser <contact@emersion.fr> Signed-off-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Reviewed-by:
Karol Herbst <kherbst@redhat.com> Signed-off-by:
-
Lyude Paul authored
Something that didn't get noticed until I started running cursor tests: we're accidentally disabling an option for CRC calculation that's enabled by default: WidePipeCrc, which controls whether we use the full width of the data in the display pipe in order calculate CRCs. Having this disabled apparently causes frames with the cursor plane enabled to generate different CRCs than frames without the cursor plane enabled, even if the frames are pixel-equivalent. So, let's make sure to enable this and fix a bunch of cursor related tests in IGT. v2: * Nvidia added the specific bit we were using to fix this issues to open-gpu-docs, so pull in the actual macro definitions for it Cc: Martin Peres <martin.peres@free.fr> Cc: Jeremy Cline <jcline@redhat.com> Cc: Simon Ser <contact@emersion.fr> Signed-off-by:
-
Lyude Paul authored
Originally it was assumed based on Nvidia's open-gpu-docs and testing that NVDisplay required that at least one wndw which belongs to a given head to be used as the controlling channel (NVC37D_HEAD_SET_CRC_CONTROL_CONTROLLING_CHANNEL) in order for CRC capture to function. While this is the case on Volta, Turing actually adds the ability to instead use the core channel as the controlling channel. For Turing this is quite useful, as it means that we can always default to the core channel as the controlling channel and we don't need to be concerned about ensuring we have at least one wndw channel owned by a head with CRC output enabled. While Volta lacks this ability, Volta conveniently also lacks flexible wndw mapping - meaning that we can always rely on each head having four wndw channels mapped to it regardless of the atomic state. So, simply use the hard-coded wndw mappings we're guaranteed to have on Volta as the controlling channel, and use the core channel as the controlling channel for Turing+. As a result this also renders the plane ownership logic in nv50_crc_atomic_check() unnessecary, which gives us one less thing to implement when we get support for flexible wndw mapping. We also can entirely drop the wndw parameter from our set_src callbacks, and the atomic state. v2 (Karol): put prackets around complex macro definition removed spaces before :32 in structs Cc: Martin Peres <martin.peres@free.fr> Cc: Jeremy Cline <jcline@redhat.com> Cc: Simon Ser <contact@emersion.fr> Signed-off-by: -
Lyude Paul authored
While I haven't seen us take too long in nv50_crc_ctx_flip_work() outside of users with kernel logging on a serial port, it probably would be a good idea to check how long we take just in case we need to go faster in the future. Cc: Martin Peres <martin.peres@free.fr> Cc: Jeremy Cline <jcline@redhat.com> Cc: Simon Ser <contact@emersion.fr> Signed-off-by:
-
Lyude Paul authored
Cc: Martin Peres <martin.peres@free.fr> Cc: Jeremy Cline <jcline@redhat.com> Cc: Simon Ser <contact@emersion.fr> Signed-off-by:
Simon Ser <contact@emersion.fr> Signed-off-by:
-
Karol Herbst authored
Some side notes on this. Atm we do want to use gitlab for bug tracking and merge requests. But due to the nature of the current linux kernel development, we can only do so for nouveau internal changes. Everything else still needs to be sent as emails and this is also includes changes to UAPI etc. Anyway, if somebody wants to submit patches via gitlab, they are free to do so and this should just make this more official and documented. People listed as maintainers are such that have push access to drm-misc (where changes are pushed to after landing in gitlab) and are known nouveau developers. We did this already for some trivial changes and critical bug fixes already, we just weren't thinking about updating the MAINTAINERS file. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
-
Neil Armstrong authored
Drop the local connector and move all callback to bridge funcs in order to leverage the generic CVBS display connector. This will also permit adding custom cvbs connectors for ADC based HPD detection on some Amlogic SoC based boards. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> [narmstrong: fixed diplay typo in commit log] Link: https://patchwork.freedesktop.org/patch/msgid/20211020123947.2585572-7-narmstrong@baylibre.com
-
Neil Armstrong authored
Rename the cvbs encoder to match the newly introduced meson_encoder_hdmi. Signed-off-by:
-
Neil Armstrong authored
This implements the necessary change to no more use the embedded connector in dw-hdmi and use the dedicated bridge connector driver by passing DRM_BRIDGE_ATTACH_NO_CONNECTOR to the bridge attach call. The necessary connector properties are added to handle the same functionalities as the embedded dw-hdmi connector, i.e. the HDR metadata, the CEC notifier & other flags. The dw-hdmi output_port is set to 1 in order to look for a connector next bridge in order to get DRM_BRIDGE_ATTACH_NO_CONNECTOR working. Signed-off-by:
-
Neil Armstrong authored
This moves all the non-DW-HDMI code where it should be: an encoder in the drm/meson core driver. The bridge functions are copied as-is, except: - the encoder init uses the simple kms helper - the mode_set has been moved to atomic_enable() - debug prints are converted to dev_debg() For now the bridge attach flags is 0, DRM_BRIDGE_ATTACH_NO_CONNECTOR will be handled later. The meson dw-hdmi glue is slightly fixed to live without the encoder in the same driver. Signed-off-by:
-
Neil Armstrong authored
The initial design was recursive to cover all port/endpoints, but only the first layer of endpoints should be covered by the components list. This also breaks the MIPI-DSI init/bridge attach sequence, thus only parse the first endpoints instead of recursing. Signed-off-by:
-
Neil Armstrong authored
Since this bridge is tied to the connector, it acts like a passthrough, so concerning the output & input bus formats, either pass the bus formats from the previous bridge or return fallback data like done in the bridge function: drm_atomic_bridge_chain_select_bus_fmts() & select_bus_fmt_recursive. This permits avoiding skipping the negociation if the remaining bridge chain has all the bits in place. Without this bus fmt negociation breaks on drm/meson HDMI pipeline when attaching dw-hdmi with DRM_BRIDGE_ATTACH_NO_CONNECTOR, because the last bridge of the display-connector doesn't implement buf fmt callbacks and MEDIA_BUS_FMT_FIXED is used leading to select an unsupported default bus format from dw-hdmi. Signed-off-by:
-
Neil Armstrong authored
The current ELD handling takes the internal connector ELD buffer and shares it to the I2S and AHB sub-driver. But with DRM_BRIDGE_ATTACH_NO_CONNECTOR, the connector is created elsewhere (or not), and an eventual connector is known only if the bridge chain up to a connector is enabled. The current dw-hdmi code gets the current connector from atomic_enable() so use the already stored connector pointer and replace the buffer pointer with a callback returning the current connector ELD buffer. Since a connector is not always available, either pass an empty ELD to the alsa HDMI driver or don't call snd_pcm_hw_constraint_eld() in AHB driver. Reported-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211029135947.3022875-1-narmstrong@baylibre.com
-
- 11 Nov, 2021 17 commits
-
-
Philip Chen authored
Conventionally, panel is listed under the root of the device tree. When userland asks for display mode, ps8640 bridge is responsible for returning EDID when ps8640_bridge_get_edid() is called. Now enable a new option of listing panel under "aux-bus" of ps8640 bridge node in the device tree. In this case, panel driver can retrieve EDID by triggering AUX transactions, without ps8640_bridge_get_edid() calls at all. To prevent the "old" and "new" options from interfering with each other's logic flow, disable DRM_BRIDGE_OP_EDID when the new option is taken. Signed-off-by:
Philip Chen <philipchen@chromium.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Philip Chen authored
Fit ps8640 driver into runtime power management framework: First, break _poweron() to 3 parts: (1) turn on power and wait for ps8640's internal MCU to finish init (2) check panel HPD (which is proxied by GPIO9) (3) the other configs. As runtime_resume() can be called before panel is powered, we only add (1) to _resume() and leave (2)(3) to _pre_enable(). We also add (2) to _aux_transfer() as we want to ensure panel HPD is asserted before we start AUX CH transactions. Second, the original driver has a mysterious delay of 50 ms between (2) and (3). Since Parade's support can't explain what the delay is for, and we don't see removing the delay break any boards at hand, remove the delay to fit into this driver change. In addition, rename "powered" to "pre_enabled" and don't check for it in the pm_runtime calls. The pm_runtime calls are already refcounted so there's no reason to check there. The other user of "powered", _get_edid(), only cares if pre_enable() has already been called. Lastly, change some existing DRM_...() logging to dev_...() along the way, since DRM_...() seem to be deprecated in [1]. [1] https://patchwork.freedesktop.org/patch/454760/Signed-off-by:
-
Thomas Zimmermann authored
Add additional information on the semantics of the size fields in struct drm_mode_config. Also add a TODO to review all driver for correct usage of these fields. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211110103702.374-10-tzimmermann@suse.de
-
Thomas Zimmermann authored
Add constants for the maximum size of the shadow-plane surface size. Useful for shadow planes with virtual screen sizes. The current sizes are 4096 scanlines with 4096 pixels each. This seems reasonable for current hardware, but can be increased as necessary. In simpledrm, set the maximum framebuffer size from the constants for shadow planes. Implements support for virtual screen sizes and page flipping on the fbdev console. v3: * use decimal numbers for shadow-plane constants (Noralf) Signed-off-by:
-
Thomas Zimmermann authored
Enable the FB_DAMAGE_CLIPS property to reduce display-update overhead. Also fixes a warning in the kernel log. simple-framebuffer simple-framebuffer.0: [drm] drm_plane_enable_fb_damage_clips() not called Fix the computation of the blit rectangle. This wasn't an issue so far, as simpledrm always blitted the full framebuffer. The code now supports damage clipping and virtual screen sizes. v3: * fix drm_dev_enter() error path (Noralf) * remove unnecessary clipping from update function (Noralf) Signed-off-by:
-
Thomas Zimmermann authored
Allocating a shadow buffer of the height of the buffer object does not support fbdev overallocation. Use surface height instead. Signed-off-by:
-
Thomas Zimmermann authored
Move destination-buffer clipping from format-helper blit function into caller. Rename drm_fb_blit_rect_dstclip() to drm_fb_blit_toio(). Done for consistency with the rest of the interface. Remove drm_fb_blit_dstclip(), which isn't required. Signed-off-by:
-
Thomas Zimmermann authored
Move destination-buffer clipping from all format-helper conversion functions into callers. Support destination-buffer pitch. Only distinguish between system and I/O memory, but use same logic everywhere. Simply harmonize the interface and semantics of the existing code. Not all conversion helpers support all combinations of parameters. We have to add additional features when we need them. v2: * fix default destination pitch in drm_fb_xrgb8888_to_gray8() (Noralf) Signed-off-by:
-
Thomas Zimmermann authored
Add destination-buffer pitch as argument to drm_fb_swab(). Done for consistency with the rest of the interface. v2: * update documentation (Noralf) Signed-off-by:
-
Thomas Zimmermann authored
Move destination-buffer clipping from all format-helper memcpy function into callers. Support destination-buffer pitch. Only distinguish between system and I/O memory, but use same logic everywhere. Signed-off-by:
-
Thomas Zimmermann authored
Provide a function that computes the offset into a blit destination buffer. This will allow to move destination-buffer clipping into the format-helper callers. v4: * add missing '@' for parameter documentation * fix typo 'frambuffer' v2: * provide documentation (Sam) * return 'unsigned int' (Sam, Noralf) Signed-off-by:
-
Thomas Zimmermann authored
The hook gem_prime_mmap in struct drm_driver is deprecated. Document the new requirements. Signed-off-by:
-
Thomas Zimmermann authored
Moving the driver-specific mmap code into a GEM object function allows for using DRM helpers for various mmap callbacks. The respective xen functions are being removed. The file_operations structure fops is now being created by the helper macro DEFINE_DRM_GEM_FOPS(). Signed-off-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211108102846.309-3-tzimmermann@suse.de
-
Christian König authored
Instead of dumping the fence info manually. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211103081231.18578-4-christian.koenig@amd.com
-
Christian König authored
Instead of hand rolling pretty much the same code. Signed-off-by:
-
Christian König authored
Add functions to dump dma_fence and dma_resv objects into a seq_file and use them for printing the debugfs information. v2: fix missing include reported by test robot. Signed-off-by:
-
xinhui pan authored
After we move BO to a new memory region, we should put it to the new memory manager's lru list regardless we unlock the resv or not. Cc: stable@vger.kernel.org Reviewed-by:
xinhui pan <xinhui.pan@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211110043149.57554-1-xinhui.pan@amd.comSigned-off-by:
-
- 10 Nov, 2021 5 commits
-
-
Cai Huoqing authored
Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose operators ".runtime_suspend/.runtime_resume", because the SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought in to make code a little more concise. Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by:
-
Tomi Valkeinen authored
DSS5's maximum tv pclk rate (i.e. HDMI) is set to 186MHz, which comes from the TRM (DPLL_HDMI_CLK1 frequency must be lower than 186 MHz). To support DRA76's wide screen HDMI feature, we need to increase this maximum rate. Testing shows that the PLL seems to work fine even with ~240MHz clocks, and even the HDMI output at that clock is stable enough for monitors to show a picture. This holds true for all DRA7 and AM5 SoCs (and probably also for OMAP5). However, the highest we can go without big refactoring to the clocking code is 192MHz, as that is the DSS func clock we get from the PRCM. So, increase the max HDMI pixel clock to 192MHz for now, to allow some more 2k+ modes to work. This patch never had a clear confirmation from HW people, but this change stayed on production trees for multiple years without any report on an eventual breakage. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose operators ".runtime_suspend/.runtime_resume", because the SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought in to make code a little clearer, a little more concise. Signed-off-by:
-
Cai Huoqing authored
use SPDX-License-Identifier instead of a verbose license text Signed-off-by:
-
- 06 Nov, 2021 1 commit
-
-
Qiang Yu authored
Otherwise get following warning: DMA-API: lima 1c40000.gpu: mapping sg segment longer than device claims to support [len=4149248] [max=65536] See: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5496Reviewed-by:
Vasily Khoruzhick <anarsoul@gmail.com> Reported-by:
Roman Stratiienko <r.stratiienko@gmail.com> Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211031041604.187216-1-yuq825@gmail.com
-
- 05 Nov, 2021 4 commits
-
-
Maxime Ripard authored
We currently rely on two functions, vc4_hdmi_supports_scrambling() and vc4_hdmi_mode_needs_scrambling() to determine if we should enable and disable the scrambler for any given mode. Since we might need to disable the controller at boot, we also always run vc4_hdmi_disable_scrambling() and thus call those functions without a mode yet, which in turns need to make some special casing in order for it to work. Instead of duplicating the check for whether or not we need to take care of the scrambler in both vc4_hdmi_enable_scrambling() and vc4_hdmi_disable_scrambling(), we can do that check only when we enable it and store whether or not it's been enabled in our private structure. We also need to initialize that flag at true to make sure we disable the scrambler at boot since we can't really know its state yet. This allows to simplify a bit that part of the driver, and removes one user of our copy of the CRTC adjusted mode outside of KMS (since vc4_hdmi_disable_scrambling() might be called from the hotplug interrupt handler). It also removes our last user of the legacy encoder->crtc pointer. Link: https://lore.kernel.org/r/20211025141113.702757-10-maxime@cerno.techAcked-by:
Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
We currently poke at encoder->crtc in the ALSA code path to determine whether the HDMI output is enabled or not, and thus whether we should allow the audio output. However, that pointer is deprecated and shouldn't really be used by atomic drivers anymore. Since we have the infrastructure in place now, let's just create a flag that we toggle to report whether the controller is currently enabled and use that instead of encoder->crtc in ALSA. Link: https://lore.kernel.org/r/20211025141113.702757-9-maxime@cerno.techAcked-by:
-
Maxime Ripard authored
Even though we already check that the encoder->crtc pointer is there during in startup(), which is part of the open() path in ASoC, nothing guarantees that our encoder state won't change between the time when we open the device and the time we prepare it. Move the sanity checks we do in startup() to a helper and call it from prepare(). Link: https://lore.kernel.org/r/20211025141113.702757-8-maxime@cerno.tech Fixes: 91e99e11 ("drm/vc4: hdmi: Register HDMI codec") Acked-by:
-
Maxime Ripard authored
Accessing the crtc->state pointer from outside the modesetting context is not allowed. We thus need to copy whatever we need from the KMS state to our structure in order to access it. However, in the vc4 HDMI driver we do use that pointer in the ALSA code path, and potentially in the hotplug interrupt handler path. These paths both need access to the CRTC adjusted mode in order for the proper dividers to be set for ALSA, and the scrambler state to be reinstated properly for hotplug. Let's copy this mode into our private encoder structure and reference it from there when needed. Since that part is shared between KMS and other paths, we need to protect it using our mutex. Link: https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/ Link: https://lore.kernel.org/r/20211025141113.702757-7-maxime@cerno.tech Fixes: bb7d7856 ("drm/vc4: Add HDMI audio support") Acked-by:
-
