- 07 Jun, 2022 8 commits
-
-
Thomas Zimmermann authored
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:
-
Thomas Zimmermann authored
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 authored
While currently empty, struct mgag200_device_info, will provide static, constant information on each device model. Signed-off-by:
-
Thomas Zimmermann authored
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 authored
Call mgag200_device_probe_vram() from each model's initializer. The G200EW3 uses a special helper with additional instructions. Signed-off-by:
-
Thomas Zimmermann authored
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 authored
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 authored
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:
-
- 06 Jun, 2022 1 commit
-
-
Douglas Anderson authored
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@changeidSigned-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
-
- 03 Jun, 2022 2 commits
-
-
Jagan Teki authored
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
-
Jagan Teki authored
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:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 02 Jun, 2022 12 commits
-
-
Timur Tabi authored
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: 4d4e9907 ("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
-
Douglas Anderson authored
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 a1e3667a ("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 authored
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:
-
Douglas Anderson authored
As talked about in this patch in the kerneldoc of of_dp_aux_populate_ep_device() and also in the past in commit a1e3667a ("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.comSigned-off-by:
-
Patrik Jakobsson authored
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:
-
Patrik Jakobsson authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
psb_intel_i2c_chan is used by all chips so use the correct prefix. Signed-off-by:
-
- 01 Jun, 2022 1 commit
-
-
Javier Martinez Canillas authored
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: 74373977 ("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
-
- 31 May, 2022 1 commit
-
-
Tom Rix authored
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:
-
- 30 May, 2022 8 commits
-
-
Saurabh Sengar authored
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:
-
Christian König authored
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
-
Christian König authored
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 authored
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 authored
Move the code from the inline functions into exported functions. Signed-off-by:
-
Christian König authored
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:
-
Yunhao Tian authored
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: d23d4d4d ("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
-
Christian König authored
Use unrcu_pointer() instead of the manual cast. Signed-off-by:
-
- 27 May, 2022 1 commit
-
-
Ville Syrjälä authored
Make the PNPID decoding available for other users. Cc: dri-devel@lists.freedesktop.org Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-15-ville.syrjala@linux.intel.com
-
- 26 May, 2022 6 commits
-
-
Alyssa Rosenzweig authored
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
-
Alyssa Rosenzweig authored
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:
-
Alyssa Rosenzweig authored
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:
-
Alyssa Rosenzweig authored
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:
-
Alyssa Rosenzweig authored
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:
-
Alyssa Rosenzweig authored
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:
-
