summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2022-06-07drm/bridge: lt9611uxc: Cancel only driver's workBjorn Andersson
During device remove care needs to be taken that no work is pending before it removes the underlying DRM bridge etc, but this can be done on the specific work rather than waiting for the flush of the system-wide workqueue. Fixes: bc6fa8676ebb ("drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220601233818.1877963-1-bjorn.andersson@linaro.org
2022-06-07drm/meson: encoder_hdmi: Fix refcount leak in meson_encoder_hdmi_initMiaoqian Lin
of_graph_get_remote_node() returns remote device nodepointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: e67f6037ae1b ("drm/meson: split out encoder from meson_dw_hdmi") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601033927.47814-3-linmq006@gmail.com
2022-06-07drm/meson: encoder_cvbs: Fix refcount leak in meson_encoder_cvbs_initMiaoqian Lin
of_graph_get_remote_node() returns remote device nodepointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: 318ba02cd8a8 ("drm/meson: encoder_cvbs: switch to bridge with ATTACH_NO_CONNECTOR") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601033927.47814-2-linmq006@gmail.com
2022-06-07drm/mgag200: Store positions of I2C data and clock bits in device infoThomas Zimmermann
The bits for accessing I2C data and clock channels varies among models. Store them in the device-info structure for consumption by the DDC code. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-11-tzimmermann@suse.de
2022-06-07drm/mgag200: Store vidrst flag in device infoThomas Zimmermann
Set new vidrst flag in device info for models that synchronize with external sources (i.e., BMCs). In modesetting, set the corresponding bits from the device-info flag. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-10-tzimmermann@suse.de
2022-06-07drm/mgag200: Store maximum resolution and memory bandwidth in device infoThomas Zimmermann
The maximum resolution and memory bandwidth are model-specific limits. Both are used during display-mode validation. Store the values in struct mgag200_device_info and simplify the validation code. v2: * 'bandwith' -> 'bandwidth' in commit message Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-9-tzimmermann@suse.de
2022-06-07drm/mgag200: Store HW_BUG_NO_STARTADD flag in device infoThomas Zimmermann
Flag devices with broken handling of the startadd field in struct mgag200_device_info, instead of PCI driver data. This reduces the driver data to a simple type constant. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-8-tzimmermann@suse.de
2022-06-07drm/mgag200: Add struct mgag200_device_infoThomas Zimmermann
While currently empty, struct mgag200_device_info, will provide static, constant information on each device model. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-7-tzimmermann@suse.de
2022-06-07drm/mgag200: Implement new init logicThomas Zimmermann
Rework mgag200_regs_init() and mgag200_mm_init() into device preinit and init functions. The preinit function, mgag200_device_preinit(), requests and maps a device's I/O and video memory. The init function, mgag200_device_init() initializes the state of struct mga_device. Splitting the initialization between the two functions is necessary to perform per-model operations between the two calls, such as reading the unique revision ID on G200SEs. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-6-tzimmermann@suse.de
2022-06-07drm/mgag200: Call mgag200_device_probe_vram() from per-model initThomas Zimmermann
Call mgag200_device_probe_vram() from each model's initializer. The G200EW3 uses a special helper with additional instructions. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-5-tzimmermann@suse.de
2022-06-07drm/mgag200: Move PCI-option setup into model-specific codeThomas Zimmermann
Split the PCI code into a single call for each model. G200 and G200SE each contain a dedicated helper with additional instructions. Noteably, the G200ER has no code for PCI setup. In a later patch, the magic numbers should be replaced by descriptive constants. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-4-tzimmermann@suse.de
2022-06-07drm/mgag200: Initialize each model in separate functionThomas Zimmermann
Add a separate initializer function for each model. Add separate devic structures for G200 and G200SE, which require additional information. Also move G200's and G200SE's helpers for reading the BIOS and version id into model-specific code. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-3-tzimmermann@suse.de
2022-06-07drm/mgag200: Remove special case for G200SE with <2 MiBThomas Zimmermann
Remove old test for 32-bit vs 16-bit colors. Prefer 24-bit color depth on all devices. 32-bit color depth doesn't exist, it should have always been 24-bit. G200SE with less than 2 MiB of video memory have defaulted to 16-bit color depth, as the original revision of the G200SE had only 1.75 MiB of video memory. Using 16-bit colors enabled XGA resolution. But we now already limit these devices to VGA resolutions as the memory-bandwith test assumes 32-bit pixel size. So drop the special case from color-depth selection. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112522.5774-2-tzimmermann@suse.de
2022-06-06drm/probe-helper: Default to 640x480 if no EDID on DPDouglas Anderson
If we're unable to read the EDID for a display because it's corrupt / bogus / invalid then we'll add a set of standard modes for the display. Since we have no true information about the connected display, these modes are essentially guesses but better than nothing. At the moment, none of the modes returned is marked as preferred, but the modes are sorted such that the higher resolution modes are listed first. When userspace sees these modes presented by the kernel it needs to figure out which one to pick. At least one userspace, ChromeOS [1] seems to use the rules (which seem pretty reasonable): 1. Try to pick the first mode marked as preferred. 2. Try to pick the mode which matches the first detailed timing descriptor in the EDID. 3. If no modes were marked as preferred then pick the first mode. Unfortunately, userspace's rules combined with what the kernel is doing causes us to fail section 4.2.2.6 (EDID Corruption Detection) of the DP 1.4a Link CTS. That test case says that, while it's OK to allow some implementation-specific fall-back modes if the EDID is bad that userspace should _default_ to 640x480. Let's fix this by marking 640x480 as default for DP in the no-EDID case. NOTES: - In the discussion around v3 of this patch [2] there was talk about solving this in userspace and I even implemented a patch that would have solved this for ChromeOS, but then the discussion turned back to solving this in the kernel. - Also in the discussion of v3 [2] it was requested to limit this change to just DP since folks were worried that it would break some subtle corner case on VGA or HDMI. [1] https://source.chromium.org/chromium/chromium/src/+/a051f741d0a15caff2251301efe081c30e0f4a96:ui/ozone/platform/drm/common/drm_util.cc;l=488 [2] https://lore.kernel.org/r/20220513130533.v3.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112302.v4.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid
2022-06-03drm: bridge: Add TI DLPC3433 DSI to DMD bridgeJagan Teki
TI DLPC3433 is a MIPI DSI based display controller bridge for processing high resolution DMD based projectors. It has a flexible configuration of MIPI DSI and DPI signal input that produces a DMD output in RGB565, RGB666, RGB888 formats. It supports upto 720p resolution with 60 and 120 Hz refresh rates. Add bridge driver for it. Signed-off-by: Christopher Vollo <chris@renewoutreach.org> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220603140349.3563612-2-jagan@amarulasolutions.com
2022-06-03dt-bindings: display: bridge: Add TI DLPC3433 DSI to DMDJagan Teki
TI DLPC3433 is a MIPI DSI based display controller bridge for processing high resolution DMD based projectors. It has a flexible configuration of MIPI DSI and DPI signal input that produces a DMD output in RGB565, RGB666, RGB888 formats. It supports upto 720p resolution with 60 and 120 Hz refresh rates. Add dt-bingings for it. Signed-off-by: Christopher Vollo <chris@renewoutreach.org> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220603140349.3563612-1-jagan@amarulasolutions.com
2022-06-02drm/nouveau: fix another off-by-one in nvbios_addrTimur Tabi
This check determines whether a given address is part of image 0 or image 1. Image 1 starts at offset image0_size, so that address should be included. Fixes: 4d4e9907ff572 ("drm/nouveau/bios: guard against out-of-bounds accesses to image") Cc: <stable@vger.kernel.org> # v4.8+ Signed-off-by: Timur Tabi <ttabi@nvidia.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220511163716.3520591-1-ttabi@nvidia.com
2022-06-02drm/bridge: parade-ps8640: Handle DP AUX more properlyDouglas Anderson
While it works, for the most part, to assume that the panel has finished probing when devm_of_dp_aux_populate_ep_devices() returns, it's a bit fragile. This is talked about at length in commit a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev"). When reviewing the ps8640 code, I managed to convince myself that it was OK not to worry about it there and that maybe it wasn't really _that_ fragile. However, it turns out that it really is. Simply hardcoding panel_edp_probe() to return -EPROBE_DEFER was enough to put the boot process into an infinite loop. I believe this manages to trip the same issues that we used to trip with the main MSM code where something about our actions trigger Linux to re-probe previously deferred devices right away and each time we try again we re-trigger Linux to re-probe. Let's fix this using the callback introduced in the patch ("drm/dp: Callbacks to make it easier for drivers to use DP AUX bus properly"). When using the new callback, we have to be a little careful. The probe_done() callback is no longer always called in the context of our probe routine. That means we can't rely on being able to return -EPROBE_DEFER from it. We re-jigger the order of things a bit to account for that. With this change, the device still boots (though obviously the panel doesn't come up) if I force panel-edp to always return -EPROBE_DEFER. If I fake it and make the panel probe exactly once it also works. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220510122726.v3.4.Ia6324ebc848cd40b4dbd3ad3289a7ffb5c197779@changeid
2022-06-02drm/bridge: Add devm_drm_bridge_add()Douglas Anderson
This adds a devm managed version of drm_bridge_add(). Like other "devm" function listed in drm_bridge.h, this function takes an explicit "dev" to use for the lifetime management. A few notes: * In general we have a "struct device" for bridges that makes a good candidate for where the lifetime matches exactly what we want. * The "bridge->dev->dev" device appears to be the encoder device. That's not the right device to use for lifetime management. Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220510122726.v3.3.Iba4b9bf6c7a1ee5ea2835ad7bd5eaf84d7688520@changeid
2022-06-02drm/dp: Add callbacks to make using DP AUX bus properly easierDouglas Anderson
As talked about in this patch in the kerneldoc of of_dp_aux_populate_ep_device() and also in the past in commit a1e3667a9835 ("drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev"), it can be difficult for eDP controller drivers to know when the panel has finished probing when they're using of_dp_aux_populate_ep_devices(). The ti-sn65dsi86 driver managed to solve this because it was already broken up into a bunch of sub-drivers. That means we could solve the problem there by adding a new sub-driver to get the panel. We could use the traditional -EPROBE_DEFER retry mechansim to handle the case where the panel hadn't probed yet. In parade-ps8640 we didn't really solve this. The code just expects the panel to be ready right away. While reviewing the code originally I had managed to convince myself it was fine to just expect the panel right away, but additional testing has shown that not to be the case. We could fix parade-ps8640 like we did ti-sn65dsi86 but it's pretty cumbersome (since we're not already broken into multiple drivers) and requires a bunch of boilerplate code. After discussion [1] it seems like the best solution for most people is: - Accept that there's always at most one device that will probe as a result of the DP AUX bus (it may have sub-devices, but there will be one device _directly_ probed). - When that device finishes probing, we can just have a call back. This patch implements that idea. We'll now take a callback as an argument to the populate function. To make this easier to land in pieces, we'll make wrappers for the old functions. The functions with the new name (which make it clear that we only have one child) will take the callback and the functions with the old name will temporarily wrap. [1] https://lore.kernel.org/r/CAD=FV=Ur3afHhsXe7a3baWEnD=MFKFeKRbhFU+bt3P67G0MVzQ@mail.gmail.com Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220510122726.v3.2.I4182ae27e00792842cb86f1433990a0ef9c0a073@changeid
2022-06-02drm/gma500: Read EDID from the correct i2c adapterPatrik Jakobsson
Someone made the mistake to try reading EDID from the backlight i2c adapter. This has been wrong for a very long time but since we read out the modes correctly on init and don't hotplug lvds it has been working anyway. Correct this by using connector->ddc instead of encoder->i2c_bus. Both PSB and CDV are affected but this bug. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220601092311.22648-9-patrik.r.jakobsson@gmail.com
2022-06-02drm/gma500: Make oaktrail lvds use ddc adapter from drm_connectorPatrik Jakobsson
We're moving all uses of ddc_bus to drm_connector where they belong. The initialization of the gma_i2c_chan for Oaktrail is a bit backwards so it required improvements. Also cleanup the error handling in oaktrail_lvds_init(). Since this is the last user of gma_encoder->ddc_bus we can remove it. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220601092311.22648-8-patrik.r.jakobsson@gmail.com
2022-06-02drm/gma500: Make cdv crt use ddc adapter from drm_connectorPatrik Jakobsson
We're moving all uses of ddc_bus to drm_connector where they belong. Also cleanup the error handling in cdv_intel_crt_init(). Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220601092311.22648-7-patrik.r.jakobsson@gmail.com
2022-06-02drm/gma500: Make psb lvds use ddc adapter from drm_connectorPatrik Jakobsson
We're moving all uses of ddc_bus to drm_connector where they belong. Also cleanup the error handling in psb_intel_lvds_init() and remove unused ddc_bus in psb_intel_lvds_priv. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220601092311.22648-6-patrik.r.jakobsson@gmail.com
2022-06-02drm/gma500: Make cdv hdmi use ddc adapter from drm_connectorPatrik Jakobsson
We're moving all uses of ddc_bus from gma_encoder to drm_connector where they belong. Also, cleanup the error handling in cdv_hdmi_init() and remove unused i2c pointer in mid_intel_hdmi_priv. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220601092311.22648-5-patrik.r.jakobsson@gmail.com
2022-06-02drm/gma500: Make cdv lvds use ddc adapter from drm_connectorPatrik Jakobsson
We're moving all uses of ddc_bus to drm_connector where they belong. Also, add missing call to destroy ddc bus when destroying the connector and cleanup the error handling in cdv_intel_lvds_init(). Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220601092311.22648-4-patrik.r.jakobsson@gmail.com
2022-06-02drm/gma500: Make gma_i2c_chan a subclass of i2c_adapterPatrik Jakobsson
This makes it easier to get at the full gma_i2c_chan when having an i2c_adapter from eg. drm_connector->ddc. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220601092311.22648-3-patrik.r.jakobsson@gmail.com
2022-06-02drm/gma500: Use gma_ prefix for our i2c abstractionPatrik Jakobsson
psb_intel_i2c_chan is used by all chips so use the correct prefix. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220601092311.22648-2-patrik.r.jakobsson@gmail.com
2022-06-02drm/ssd130x: Only define a SPI device ID table when built as a moduleJavier Martinez Canillas
The kernel test robot reports a compile warning due the ssd130x_spi_table variable being defined but not used. This happen when ssd130x-spi driver is built-in instead of being built as a module, i.e: CC drivers/gpu/drm/solomon/ssd130x-spi.o AR drivers/base/firmware_loader/built-in.a AR drivers/base/built-in.a CC kernel/trace/trace.o drivers/gpu/drm/solomon/ssd130x-spi.c:155:35: warning: ‘ssd130x_spi_table’ defined but not used [-Wunused-const-variable=] 155 | static const struct spi_device_id ssd130x_spi_table[] = { | ^~~~~~~~~~~~~~~~~ The driver shouldn't need a SPI device ID table and only have an OF device ID table, but the former is needed to workaround an issue in the SPI core. This always reports a MODALIAS of the form "spi:<device>" even for devices registered through Device Trees. But the table is only needed when the driver built as a module to populate the .ko alias info. It's not needed when the driver is built-in the kernel. Fixes: 74373977d2ca ("drm/solomon: Add SSD130x OLED displays SPI support") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220530140246.742469-1-javierm@redhat.com
2022-05-31drm/nouveau/fifo/gv100-: set gv100_fifo_runlist storage-class to staticTom Rix
sparse reports drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.c:56:1: warning: symbol 'gv100_fifo_runlist' was not declared. Should it be static? gv100_fifo_runlist is only used in gv100.c, so change it to static. Signed-off-by: Tom Rix <trix@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220528141836.4155970-1-trix@redhat.com
2022-05-30drm/hyperv : Removing the restruction of VRAM allocation with PCI bar sizeSaurabh Sengar
There were two different approaches getting used in this driver to allocate vram: 1. VRAM allocation from PCI region for Gen1 2. VRAM alloaction from MMIO region for Gen2 First approach limilts the vram to PCI BAR size, which is 64 MB in most legacy systems. This limits the maximum resolution to be restricted to 64 MB size, and with recent conclusion on fbdev issue its concluded to have similar allocation strategy for both Gen1 and Gen2. This patch unifies the Gen1 and Gen2 vram allocation strategy. Signed-off-by: Saurabh Sengar <ssengar@linux.microsoft.com> Reviewed-by: Deepak Rawat <drawat.floss@gmail.com> Signed-off-by: Deepak Rawat <drawat.floss@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/1653143019-20032-1-git-send-email-ssengar@linux.microsoft.com
2022-05-30drm: use dma_fence_unwrap_merge() in drm_syncobjChristian König
The unwrap merge function is now intended for this use case. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220518135844.3338-6-christian.koenig@amd.com
2022-05-30dma-buf: generalize dma_fence unwrap & merging v3Christian König
Introduce a dma_fence_unwrap_merge() macro which allows to unwrap fences which potentially can be containers as well and then merge them back together into a flat dma_fence_array. v2: rename the function, add some more comments about how the wrapper is used, move filtering of signaled fences into the unwrap iterator, add complex selftest which covers more cases. v3: fix signaled fence filtering once more Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220518135844.3338-5-christian.koenig@amd.com
2022-05-30dma-buf: return only unsignaled fences in dma_fence_unwrap_for_each v3Christian König
dma_fence_chain containers cleanup signaled fences automatically, so filter those out from arrays as well. v2: fix missing walk over the array v3: massively simplify the patch and actually update the description. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220518135844.3338-4-christian.koenig@amd.com
2022-05-30dma-buf: cleanup dma_fence_unwrap implementationChristian König
Move the code from the inline functions into exported functions. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220518135844.3338-3-christian.koenig@amd.com
2022-05-30dma-buf: cleanup dma_fence_unwrap selftest v2Christian König
The selftests, fix the error handling, remove unused functions and stop leaking memory in failed tests. v2: fix the memory leak correctly. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220518135844.3338-2-christian.koenig@amd.com
2022-05-30drm/mipi-dbi: align max_chunk to 2 in spi_transferYunhao Tian
In __spi_validate, there's a validation that no partial transfers are accepted (xfer->len % w_size must be zero). When max_chunk is not a multiple of bpw (e.g. max_chunk = 65535, bpw = 16), the transfer will be rejected. This patch aligns max_chunk to 2 bytes (the maximum value of bpw is 16), so that no partial transfer will occur. Fixes: d23d4d4dac01 ("drm/tinydrm: Move tinydrm_spi_transfer()") Signed-off-by: Yunhao Tian <t123yh.xyz@gmail.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220510030219.2486687-1-t123yh.xyz@gmail.com
2022-05-30dma-buf: cleanup dma_fence_chain_walkChristian König
Use unrcu_pointer() instead of the manual cast. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220518085446.31338-1-christian.koenig@amd.com
2022-05-27drm/edid: Extract drm_edid_decode_mfg_id()Ville Syrjälä
Make the PNPID decoding available for other users. Cc: dri-devel@lists.freedesktop.org Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-15-ville.syrjala@linux.intel.com
2022-05-26drm/panfrost: Add arm,mali-valhall-jm compatibleAlyssa Rosenzweig
The most important Valhall-specific quirks have been handled, so add the Valhall compatible and probe. v2: Use arm,mali-valhall-jm compatible. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-10-alyssa.rosenzweig@collabora.com
2022-05-26drm/panfrost: Add Mali-G57 "Natt" supportAlyssa Rosenzweig
Add the features, issues, and GPU ID for Mali-G57, a first-generation Valhall GPU. Other first- and second-generation Valhall GPUs should be similar. v2: Split out issue list for r0p0 from newer Natt GPUs, as TTRX_3485 was fixed in r0p1. Unfortunately, MT8192 has a r0p0, so we do need to handle TTRX_3485. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-9-alyssa.rosenzweig@collabora.com
2022-05-26drm/panfrost: Don't set L2_MMU_CONFIG quirksAlyssa Rosenzweig
L2_MMU_CONFIG is an implementation-defined register. Different Mali GPUs define slightly different MAX_READS and MAX_WRITES fields, which throttle outstanding reads and writes when set to non-zero values. When left as zero, reads and writes are not throttled. Both kbase and panfrost always zero these registers. Per discussion with Steven Price, there are two reasons these quirks may be used: 1. Simulating slower memory subsystems. This use case is only of interest to system-on-chip designers; it is not relevant to mainline. 2. Working around broken memory subsystems. Hopefully we never see this case in mainline. If we do, we'll need to set this register based on an SoC-compatible, rather than generally matching on the GPU model. To the best of our knowledge, these fields are zero at reset, so the write is not necessary. Let's remove the write to aid porting to new Mali GPUs, which have different layouts for the L2_MMU_CONFIG register. Suggested-by: Steven Price <steven.price@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-8-alyssa.rosenzweig@collabora.com
2022-05-26drm/panfrost: Add "clean only safe" feature bitAlyssa Rosenzweig
Add the HW_FEATURE_CLEAN_ONLY_SAFE bit based on kbase. When I actually tried to port the logic from kbase, trivial jobs raised Data Invalid Faults, so this may depend on other coherency details. It's still useful to have the bit to record the feature bit when adding new models. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-7-alyssa.rosenzweig@collabora.com
2022-05-26drm/panfrost: Add HW_ISSUE_TTRX_3485 quirkAlyssa Rosenzweig
TTRX_3485 requires the infamous "dummy job" workaround. I have this workaround implemented in a local branch, but I have not yet hit a case that requires it so I cannot test whether the implementation is correct. In the mean time, add the quirk bit so we can document which platforms may need it in the future. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-6-alyssa.rosenzweig@collabora.com
2022-05-26drm/panfrost: Handle HW_ISSUE_TTRX_3076Alyssa Rosenzweig
Some Valhall GPUs require resets when encountering bus faults due to occlusion query writes. Add the issue bit for this and handle it. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-5-alyssa.rosenzweig@collabora.com
2022-05-26drm/panfrost: Constify argument to has_hw_issueAlyssa Rosenzweig
Logically, this function is free of side effects, so any pointers it takes should be const. Needed to avoid a warning in the next patch. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-4-alyssa.rosenzweig@collabora.com
2022-05-26drm/panfrost: Handle HW_ISSUE_TTRX_2968_TTRX_3162Alyssa Rosenzweig
Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported from kbase. kbase lists this workaround as used on Mali-G57. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-3-alyssa.rosenzweig@collabora.com
2022-05-26dt-bindings: Add compatible for Mali Valhall (JM)Alyssa Rosenzweig
From the kernel's perspective, (pre-CSF, "Job Manager") Valhall is more or less compatible with Bifrost, although they differ to userspace. Add a compatible for Valhall to the existing Bifrost bindings documentation. As the first SoC with a Valhall GPU receiving mainline support, add a specific compatible for the MediaTek MT8192, which instantiates a Mali-G57. v2: Change compatible to arm,mali-valhall-jm (Daniel Stone). CC: devicetree@vger.kernel.org Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-2-alyssa.rosenzweig@collabora.com
2022-05-26drm: bridge: icn6211: Adjust clock phase using SYS_CTRL_1Jonathan Liu
The code from [1] sets SYS_CTRL_1 to different values depending on the desired clock phase (0, 1/4, 1/2 or 3/4). A clock phase of 0 aligns the positive edge of the clock with the pixel data while other values delay the clock by a fraction of the clock period. A clock phase of 1/2 aligns the negative edge of the clock with the pixel data. The driver currently hard codes SYS_CTRL_1 to 0x88 which corresponds to aligning the positive edge of the clock with the pixel data. This won't work correctly for panels that require aligning the negative edge of the clock with the pixel data. Adjust the clock phase to 0 if DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE is present in bus_flags, otherwise adjust the clock phase to 1/2 as appropriate for DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE. [1] https://github.com/tdjastrzebski/ICN6211-Configurator Signed-off-by: Jonathan Liu <net147@gmail.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220523130144.444225-1-net147@gmail.com
2022-05-26dt-bindings: display: ingenic,jz4780-hdmi: Drop undocumented 'ddc-i2c-bus'Rob Herring
While 'ddc-i2c-bus' is a common property, it should be in a connector node rather than the HDMI bridge node as the I2C bus goes to a connector and not the HDMI block. Drop it from the example. Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220525205626.2482584-1-robh@kernel.org
generated by cgit (git 2.34.1) at 2025-04-16 18:52:43 +0000