- 11 Mar, 2019 6 commits
-
-
Hans de Goede authored
Add a MAINTAINERS entry for the vboxvideo driver, now that it has been moved out of staging. Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190311163522.22045-1-hdegoede@redhat.com
-
Hans de Goede authored
The vboxvideo driver has been converted to the atomic modesetting API and all FIXME and TODO items have been fixed, so it is time to move it out of staging. Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
-
Hans de Goede authored
Refactor vbox_update_mode_hints to no longer use the obsolete drm_modeset_lock_all() and switch it over to drm_connector_list_iter instead of directly accessing the list using list_for_each_entry. Acked-by:
-
Hans de Goede authored
Drop the initial_mode_queried workaround for kms clients which do not support hotplug, all kms clients should be able to deal with hotplug. Suggested-by:
-
Daniel Vetter authored
Found while grepping around. Signed-off-by:
-
Arnd Bergmann authored
The DRM_STM driver can be built independently of the framebuffer layer, but it causes a Kconfig warning: WARNING: unmet direct dependencies detected for FB_PROVIDE_GET_FB_UNMAPPED_AREA Depends on [n]: HAS_IOMEM [=y] && FB [=n] Selected by [y]: - DRM_STM [=y] && HAS_IOMEM [=y] && DRM [=y] && (ARCH_STM32 [=n] || ARCH_MULTIPLATFORM [=y]) Selecting FB_PROVIDE_GET_FB_UNMAPPED_AREA actually has no effect if CONFIG_FB is disabled, so we can make it a conditional 'select' instead. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190307155323.2949975-1-arnd@arndb.de
-
- 08 Mar, 2019 5 commits
-
-
Eric Anholt authored
No compatible string for it yet, just the version-dependent changes. They've now tied the hub and the core interrupt lines into a single interrupt line coming out of the block. It also turns out I made a mistake in modeling the V3D v3.3 and v4.1 bridge as a part of V3D itself -- the bridge is going away in favor of an external reset controller in a larger HW module. v2: Use consistent checks for whether we're on 4.2, and fix a leak in an error path. v3: Use more general means of determining if the current 4.2 changes are in place, as apparently other platforms may switch back (noted by Dave). Update the binding doc. v4: Improve error handling for IRQ init. Signed-off-by:Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190308174336.7866-2-eric@anholt.netReviewed-by:
Dave Emett <david.emett@broadcom.com>
-
Eric Anholt authored
Noted in review by Dave Emett for V3D 4.2 support. Signed-off-by:
-
Eric Anholt authored
You'll get garbage measurements if the registers always read back 0xdeadbeef Signed-off-by:
-
Eric Anholt authored
The old field is gone and the register now has a different field, QRMAXCNT for how many TMU requests get serviced before thread switch. We were accidentally reducing it from its default of 0x3 (4 requests) to 0x0 (1). v2: Skip setting the reg at all on 4.x, instead of trying to update only the old field. Signed-off-by: -
Sean Paul authored
Merge tag 'topic/hdr-formats-2019-03-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-misc-next Add support for Y21x and Y41x to drm core and i915, and P01x support to i915. Signed-off-by:
Sean Paul <seanpaul@chromium.org> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f2485309-d645-bed4-95f4-e66ff312aa05@linux.intel.com
-
- 07 Mar, 2019 6 commits
-
-
Qiang Yu authored
For other driver like lima usage. Cc: Rob Herring <robh@kernel.org> Signed-off-by:
Qiang Yu <yuq825@gmail.com> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190225140717.20586-2-yuq825@gmail.com
-
Maxime Ripard authored
The current code, since commit bb43d40d ("drm/sun4i: rgb: Validate the clock rate"), perform some validation on the pixel clock to filter out the EDID modes provided by monitors (through bridges) that we wouldn't be able to reach. For the usual modes, we're able to generate a perfect clock rate, so a strict check was enough. However, this had the side effect of preventing displays that would work otherwise to operate properly, since we would pretty much never be able to generate an exact rate for those displays, even though we would fall within that panel tolerance. This was also shown to happen for unusual modes exposed through EDIDs, for example on eDP panels. We can work around this by simplifying a bit the problem: no panels we've encountered so far actually needed that check. All of them are tied to a particular board when it is produced, and made to work with the Allwinner BSP. That pretty much guarantees that we never have a pixel clock out of reach. On the other hand, the EDIDs modes that needed to be validated have always been exposed through bridges. Let's just use that metric to instead of validating all modes, only validate modes when we have a bridge attached. It should be good enough for now, while we still have room for improvements or refinements using the display_timings structure for example for panels. We also add a tolerance for EDID-based modes instead of doing a strict check. This tolerance is of 0.5% which is the one advertised in the VESA DVT and CVT specs. If that needed to be extended in the future, we can add a custom module parameter to relax it a bit. Fixes: bb43d40d ("drm/sun4i: rgb: Validate the clock rate") Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> # tested on pinebook Reviewed-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/ec2dc2a7b3d4bd44f7a2a6e1c1813f92449a7310.1551191081.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
Our clock rate variables are getting pretty close to the LONG_MAX / ULONG_MAX limit, especially since we will start doing arithmetic on it. Move those types to unsigned long long to be sure we don't overflow their type. Signed-off-by:
-
Maxime Ripard authored
We'll need the bridge pointer, if any, in the mode_valid callback in addition to the init function. Store the pointer to the bridge in the rgb private structure. Signed-off-by:
-
Maxime Ripard authored
The TCON driver used to need the panel pointer in order to configure the tcon according to the various parameters of the panel. However, this has evolved over time (especially to support bridges), and therefore the panel pointer isn't needed anymore by the TCON driver. Move that pointer to the LVDS and RGB encoders drivers. Signed-off-by:
-
Maxime Ripard authored
The preferred bpp for the fbdev emulation buffer has been 32 so far, which means that by default we will allocate an 8MB buffer with a 1920x1080 resolution. Worse this memory will be allocated from the CMA pool, and will never be freed even if we don't use the fbdev emulation. Therefore, reducing it is a big deal, and switching to 16bpp by default will gain us around 4MB at 1920x1080, while keeping decent color depth. And users still have the option to switch to 32bpp using the kernel command line. Signed-off-by:
-
- 06 Mar, 2019 4 commits
-
-
Sean Paul authored
Picking up v5.0 + missed misc-fixes from last release Signed-off-by: -
Paul Kocialkowski authored
In order to test whether the load tracker is working as expected, we need the ability to compare the commit result with the underrun indication. With the load tracker always enabled, commits that are expected to trigger an underrun are always rejected, so userspace cannot get the actual underrun indication from the hardware. Add a debugfs entry to disable/enable the load tracker, so that a DRM commit expected to trigger an underrun can go through with the load tracker disabled. The underrun indication is then available to userspace and can be checked against the commit result with the load tracker enabled. Signed-off-by:
-
Boris Brezillon authored
The HVS block is supposed to fill the pixelvalve FIFOs fast enough to meet the requested framerate. The problem is, the HVS and memory bus bandwidths are limited, and if we don't take these limitations into account we might end up with HVS underflow errors. This patch is trying to model the per-plane HVS and memory bus bandwidth consumption and take a decision at atomic_check() time whether the estimated load will fit in the HVS and membus budget. Note that we take an extra margin on the memory bus consumption to let the system run smoothly when other blocks are doing heavy use of the memory bus. Same goes for the HVS limit, except the margin is smaller in this case, since the HVS is not used by external components. Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by:
-
Boris Brezillon authored
Add a debugfs entry and helper for reporting HVS underrun errors as well as helpers for masking and unmasking the underrun interrupts. Add an IRQ handler and initial IRQ configuration. Rework related register definitions to take the channel number. Signed-off-by:
-
- 05 Mar, 2019 9 commits
-
-
David Francis authored
The DP 1.4 spec defines the SDP header and SDP contents for a Picture Parameter Set (PPS) that must be sent in advance of DSC transmission to define the encoding characteristics. This was done in one struct, drm_dsc_pps_infoframe, which conatined the SDP header and PPS. Because the PPS is a property of DSC over any connector, not just DP, and because drm drivers may have their own SDP structs they wish to use, make the functions that initialise SDP and PPS headers take the components they operate on, not drm_dsc_pps_infoframe, Signed-off-by:
David Francis <David.Francis@amd.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190221202001.28430-4-David.Francis@amd.com
-
David Francis authored
Native 420 and 422 transfer modes are new in DSC1.2 In these modes, each two pixels of a slice are treated as one pixel, so the slice width is half as large (round down) for the purposes of calucating the groups per line and chunk size in bytes In native 422 mode, each pixel has four components, so the mux component of a group is larger by one additional mux word and one additional component Now that there is native 422 support, the configuration option previously called enable422 is renamed to simple_422 to avoid confusion Acked-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
David Francis authored
The function intel_compute_rc_parameters is part of the dsc spec and is not driver-specific. Other drm drivers might like to use it. The function is not changed; just moved and renamed. Reviewed-by:
-
Swati Sharma authored
Signed-off-by:
Swati Sharma <swati2.sharma@intel.com> Signed-off-by:
Vidya Srinivas <vidya.srinivas@intel.com> Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Swati Sharma authored
Added needed plane control flag definitions for Y2xx and Y4xx (10, 12 and 16 bits) Signed-off-by:
-
Swati Sharma authored
The following pixel formats are packed format that follows 4:2:2 chroma sampling. For memory represenation each component is allocated 16 bits each. Thus each pixel occupies 32bit. Y210: For each component, valid data occupies MSB 10 bits. LSB 6 bits are filled with zeroes. Y212: For each component, valid data occupies MSB 12 bits. LSB 4 bits are filled with zeroes. Y216: For each component valid data occupies 16 bits, doesn't require any padding bits. First 16 bits stores the Y value and the next 16 bits stores one of the chroma samples alternatively. The first luma sample will be accompanied by first U sample and second luma sample is accompanied by the first V sample. The following pixel formats are packed format that follows 4:4:4 chroma sampling. Channels are arranged in the order UYVA in increasing memory order. Y410: Each color component occupies 10 bits and X component takes 2 bits, thus each pixel occupies 32 bits. Y412: Each color component is 16 bits where valid data occupies MSB 12 bits. LSB 4 bits are filled with zeroes. Thus, each pixel occupies 64 bits. Y416: Each color component occupies 16 bits for valid data, doesn't require any padding bits. Thus, each pixel occupies 64 bits. v3: fixed missing tab for XYUV8888 (JP) Signed-off-by:
-
Juha-Pekka Heikkila authored
Enabling of P010, P012 and P016 formats. These formats will extend NV12 for larger bit depths. Signed-off-by:
-
Juha-Pekka Heikkila authored
Preparations for enabling P010, P012 and P016 formats. These formats will extend NV12 for larger bit depths. Signed-off-by:
-
Juha-Pekka Heikkila authored
Add needed plane control flag definitions for P010, P012 and P016 formats. Signed-off-by:
-
- 04 Mar, 2019 10 commits
-
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-fixes for v5.0: - Block fb changes for async atomic updates to prevent a use after free. - Fix ID mismatch error on load in bochs. - Fix memory leak when drm_setup fails. - Fixes around handling of DRM_AUTH. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/42113611-e2cd-6bdd-7de5-4f8ab5a0cbe6@linux.intel.com
-
Mario Kleiner authored
In VRR mode, keep track of the vblank count of the last completed pageflip in amdgpu_crtc->last_flip_vblank, as recorded in the pageflip completion handler after each completed flip. Use that count to prevent mmio programming a new pageflip within the same vblank in which the last pageflip completed, iow. to throttle pageflips to at most one flip per video frame, while at the same time allowing to request a flip not only before start of vblank, but also anywhere within vblank. The old logic did the same, and made sense for regular fixed refresh rate flipping, but in vrr mode it prevents requesting a flip anywhere inside the possibly huge vblank, thereby reducing framerate in vrr mode instead of improving it, by delaying a slightly delayed flip requests up to a maximum vblank duration + 1 scanout duration. This would limit VRR usefulness to only help applications with a very high GPU demand, which can submit the flip request before start of vblank, but then have to wait long for fences to complete. With this method a flip can be both requested and - after fences have completed - executed, ie. it doesn't matter if the request (amdgpu_dm_do_flip()) gets delayed until deep into the extended vblank due to cpu execution delays. This also allows clients which want to regulate framerate within the vrr range a much more fine-grained control of flip timing, a feature that might be useful for video playback, and is very useful for neuroscience/vision research applications. In regular non-VRR mode, retain the old flip submission behavior. This to keep flip scheduling for fullscreen X11/GLX OpenGL clients intact, if they use the GLX_OML_sync_control extensions glXSwapBufferMscOML(, ..., target_msc,...) function with a specific target_msc target vblank count. glXSwapBuffersMscOML() or DRI3/Present PresentPixmap() will not flip at the proper target_msc for a non-zero target_msc if VRR mode is active with this patch. They'd often flip one frame too early. However, this limitation should not matter much in VRR mode, as scheduling based on vblank counts is pretty futile/unusable under variable refresh duration anyway, so no real extra harm is done. According to some testing already done with this patch by Nicholas on top of my tests, IGT tests didn't report any problems. If fixes stuttering and flickering when flipping at rates below the minimum vrr refresh rate. Fixes: bb47de73 ("drm/amdgpu: Set FreeSync state using drm VRR properties") Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Cc: <stable@vger.kernel.org> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Michel Dänzer <michel@daenzer.net> Tested-by:
Bruno Filipe <bmilreu@gmail.com> Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in a DRM_NOTE message. Fix this. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Noralf Trønnes authored
This protects device resources from use after device removal. There are 3 ways for driver-device unbinding to happen: - The driver module is unloaded causing the driver to be unregistered. This can't happen as long as there are open file handles because a reference is taken on the module. - The device is removed (Device Tree overlay unloading). This can happen at any time. - The driver sysfs unbind file can be used to unbind the driver from the device. This can happen any time. v2: Since drm_atomic_helper_shutdown() has to be called after drm_dev_unplug() we don't want do block ->disable after unplug. Signed-off-by:Noralf Trønnes <noralf@tronnes.org> Acked-by:
Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190225144232.20761-8-noralf@tronnes.org
-
Noralf Trønnes authored
No more users left so it can go alongside its helpers. Update the tinydrm docs description and remove todo entry. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
-
Noralf Trønnes authored
Use devm_drm_dev_init() and drop using tinydrm_device. v2: devm_drm_dev_register() was dropped so add driver release callbacks. Signed-off-by:
-
Noralf Trønnes authored
Use devm_drm_dev_init() and drop using tinydrm_device. v2: devm_drm_dev_register() was dropped so add a driver release callback. Signed-off-by:
-
Noralf Trønnes authored
Add driver example that shows how devm_drm_dev_init() can be used. v2: Expand docs (Sam, Daniel) Signed-off-by:
-
Noralf Trønnes authored
This adds a resource managed (devres) version of drm_dev_init(). v2: Remove devm_drm_dev_register() since we can't touch hw in devm release functions and drivers want to disable hw on driver module unload (Daniel Vetter, Greg KH) Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Greg KH <gregkh@linuxfoundation.org> Signed-off-by: -
Noralf Trønnes authored
This makes it safe to access drm_device->dev after the parent device has been removed/unplugged. Signed-off-by:
-
