- 12 Nov, 2021 21 commits
-
-
Lyude Paul authored
When it comes to gamma or degamma luts, nouveau will actually skip the calculation of certain LUTs depending on the head and plane states. For instance, when the head is disabled we don't perform any error checking on the gamma LUT, and likewise if no planes are present and enabled in our atomic state we will skip error checking the degamma LUT. This is a bit of a problem though, since the per-head gamma and degamma props in DRM can be changed even while a head is disabled - a situation which can be triggered by the igt testcase mentioned down below. Originally I thought this was a bit silly and was tempted to just fix the igt test to only set gamma/degamma with the head enabled. After a bit of thinking though I realized we should fix this in nouveau. This is because if a program decides to set an invalid LUT for a head before enabling the head, such a property change would succeed while also making it impossible to turn the head back on until the LUT is removed or corrected - something that could be painful for a user to figure out. So, fix this checking both degamma and gamma LUTs unconditionally during atomic checks. We start by calling nv50_head_atomic_check_lut() regardless of whether the head is active or not in nv50_head_atomic_check(). Then we move the ilut error checking into nv50_head_atomic_check_lut() and add a per-head hook for it, primarily because as a per-CRTC property DRM we want the LUT to be error checked by the head any time it's included in an atomic state. Of course though, actual programming of the degamma lut to hardware is still handled in each plane's atomic check and commit. Signed-off-by:
Lyude Paul <lyude@redhat.com> Testcase: igt/kms_color/pipe-invalid-*-lut-sizes Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Reviewed-by:
Karol Herbst <kherbst@redhat.com> Signed-off-by:
-
Lyude Paul authored
Since this is used in the atomic check, we should use the right debug macro for it. Signed-off-by:
-
Jiapeng Chong authored
Fix the following coccicheck warnings: ./drivers/gpu/drm/nouveau/nouveau_bios.c:2048:5-8: Unneeded variable: "ret". Return "0" on line 2061. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
Lyude Paul authored
Found this while trying to make some changes to the kms_cursor_crc test. curs507a_acquire checks that the width and height of the cursor framebuffer are equal (asyw->image.{w,h}). This isn't entirely correct though, as the height of the cursor can be larger than the size of the cursor, as long as the width is the same as the cursor size and there's no framebuffer offset. Note that I'm not entirely sure why this wasn't previously breaking kms_cursor_crc tests - they all set up cursors with the height being one pixel larger than the actual size of the cursor. But this seems to fix things, and the code before was definitely incorrect - so it's not really worth looking into further imho. Changes since v1: * Don't use crtc_w everywhere for determining cursor layout, just use fb size again * Change check so that we only check that the w/h of the cursor plane is the same, the width of the scanout surface is the same as the framebuffer width, and that there's no offset being used for the cursor surface. Signed-off-by: -
Bhaskar Chowdhury authored
s/conditon/condition/ Signed-off-by:
Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Zou Wei authored
Fix the following sparse warning: drivers/gpu/drm/nouveau/nvkm/core/client.c:64:1: warning: symbol 'nvkm_uclient_sclass' was not declared. Should it be static? Signed-off-by:
Zou Wei <zou_wei@huawei.com> Signed-off-by:
-
Ben Skeggs authored
Signed-off-by:
-
Ben Skeggs authored
There have been reports of the WFI timing out on some boards, and a patch was proposed to just remove it. This stuff is rather fragile, and I believe the WFI might be needed with our FW prior to GM200. However, we probably should not be touching PMU during init on GPUs where we depend on NVIDIA FW, outside of limited circumstances, so this should be a somewhat safer change that achieves the desired result. Reported-by:
Diego Viola <diego.viola@gmail.com> Signed-off-by:
-
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 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 2 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:
-
