- 21 1月, 2021 3 次提交
-
-
由 Jake Wang 提交于
[WHY] dram clock change latencies get updated using ddr4 latency table, but that update does not happen before validation. This value should not be the default and should be number received from df for better mode support. This may cause a PState hang on high refresh panels with short vblanks such as on 1080p 360hz or 300hz panels. [HOW] Update latency from 23.84 to 11.72. Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: NJake Wang <haonan.wang2@amd.com> Reviewed-by: NSung Lee <Sung.Lee@amd.com> Acked-by: NAnson Jacob <anson.jacob@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Huang Rui 提交于
The ip discovery is supported on green sardine, it doesn't need gpu info firmware anymore. Signed-off-by: NHuang Rui <ray.huang@amd.com> Reviewed-by: NPrike Liang <Prike.Liang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.10.x
-
由 Sung Lee 提交于
[WHY] Previously as MPO + ODM Combine was not supported, finding secondary pipes for each case was mutually exclusive. Now that both are supported at the same time, both cases should be taken into account when finding a secondary pipe. [HOW] If a secondary pipe cannot be found based on previous bottom pipe, search for a second pipe using next_odm_pipe instead. Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: NSung Lee <sung.lee@amd.com> Reviewed-by: NDmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by: NAnson Jacob <anson.jacob@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.10.x
-
- 15 1月, 2021 12 次提交
-
-
由 Ben Skeggs 提交于
VRAM offset 0 is a valid address, triggered on GA102. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Noticed while debugging GA102. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
RM does this around transactions, and it seemed to help while debugging AUXCH issues on GA102. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
No functional changes here yet. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
Whatever it is that we were doing before doesn't work on Ampere. Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Ben Skeggs 提交于
This issue has generally been covered up by the presence of additional expansion ROMs after the ones we're interested in, with header fetches of subsequent images loading enough of the ROM to hide the issue. Noticed on GA102, which lacks a type 0x70 image compared to TU102,. [ 906.364197] nouveau 0000:09:00.0: bios: 00000000: type 00, 65024 bytes [ 906.381205] nouveau 0000:09:00.0: bios: 0000fe00: type 03, 91648 bytes [ 906.405213] nouveau 0000:09:00.0: bios: 00026400: type e0, 22016 bytes [ 906.410984] nouveau 0000:09:00.0: bios: 0002ba00: type e0, 366080 bytes vs [ 22.961901] nouveau 0000:09:00.0: bios: 00000000: type 00, 60416 bytes [ 22.984174] nouveau 0000:09:00.0: bios: 0000ec00: type 03, 71168 bytes [ 23.010446] nouveau 0000:09:00.0: bios: 00020200: type e0, 48128 bytes [ 23.028220] nouveau 0000:09:00.0: bios: 0002be00: type e0, 140800 bytes [ 23.080196] nouveau 0000:09:00.0: bios: 0004e400: type 70, 7168 bytes Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Wayne Lin 提交于
[Why] Find out when we try to disable CRC calculation, crc generation is still enabled. Main reason is that dc_stream_configure_crc() will never get called when the source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE. [How] Add checking condition that when source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE, we should also call dc_stream_configure_crc() to disable crc calculation. Acked-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: NWayne Lin <Wayne.Lin@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Rodrigo Siqueira 提交于
This reverts commit c920888c. Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Harry Wentland <Harry.Wentland@amd.com> Cc: Roman Li <Roman.Li@amd.com> Cc: Bindu R <Bindu.R@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NWayne Lin <Wayne.Lin@amd.com> Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Rodrigo Siqueira 提交于
This reverts commit 6ae09fa4. Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Harry Wentland <Harry.Wentland@amd.com> Cc: Roman Li <Roman.Li@amd.com> Cc: Bindu R <Bindu.R@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Rodrigo Siqueira 提交于
This reverts commit f01afd1e. Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Alexander Deucher <Alexander.Deucher@amd.com> Cc: Harry Wentland <Harry.Wentland@amd.com> Cc: Roman Li <Roman.Li@amd.com> Cc: Bindu R <Bindu.R@amd.com> Cc: Daniel Vetter <daniel@ffwll.ch> Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Likun Gao 提交于
Add function to set power brake sequence. Signed-off-by: NLikun Gao <Likun.Gao@amd.com> Reviewed-by: NKenneth Feng <kenneth.feng@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 14 1月, 2021 12 次提交
-
-
由 mengwang 提交于
add DID 0x164C into pciidlist under CHIP_RENOIR family. Signed-off-by: Nmengwang <mengbing.wang@amd.com> Reviewed-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.10.x
-
由 Prike Liang 提交于
Add green_sardine PCI id support and map it to renoir asic type. v2: add apu flag Signed-off-by: NPrike Liang <Prike.Liang@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NHuang Rui <ray.huang@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 5.10.x
-
由 Huang Rui 提交于
This patch is to update atomfirmware parser for the memory type and bandwidth of DDR5 and DDR4. Signed-off-by: NHuang Rui <ray.huang@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 chen gong 提交于
The address of the GOLDEN_TSC_COUNT_UPPER/GOLDEN_TSC_COUNT_LOWER for Vnagogh are different from the others. The offset of the GOLDEN_TSC_COUNT_UPPER for Vangogh is 0x0025 by calculation. The offset of the GOLDEN_TSC_COUNT_LOWER for Vangogh is 0x0026 by calculation. Signed-off-by: Nchen gong <curry.gong@amd.com> Acked-by: NEvan Quan <evan.quan@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Jeremy Cline 提交于
KASAN reported a slab-out-of-bounds read of size 1 in kdf_create_vcrat_image_cpu(). This occurs when, for example, when on an x86_64 with a single NUMA node because kfd_fill_iolink_info_for_cpu() is a no-op, but afterwards the sub_type_hdr->length, which is out-of-bounds, is read and multiplied by entries. Fortunately, entries is 0 in this case so the overall crat_table->length is still correct. Check if there were any entries before de-referencing sub_type_hdr which may be pointing to out-of-bounds memory. Fixes: b7b6c385 ("drm/amdkfd: Calculate CPU VCRAT size dynamically (v2)") Suggested-by: NFelix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: NJeremy Cline <jcline@redhat.com> Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: NFelix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Rodrigo Siqueira 提交于
commit a861736d ("drm/amd/display: Fixed Intermittent blue screen on OLED panel") causes power regression for many users. It seems that this change causes the MCLK to get forced high; this creates a regression for many users since their devices were not able to drop to a low state after this change. For this reason, this reverts commit a861736d. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1407 Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Naveed Ashfaq <Naveed.Ashfaq@amd.com> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Roman Li <roman.li@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Li, Roman 提交于
[Why] The initial purpose of dcn10 pipe split is to support some high bandwidth mode which requires dispclk greater than max dispclk. By initial bring up power measurement data, it showed power consumption is less with pipe split for dcn block. This could be reason for enable pipe split by default. By battery life measurement of some Chromebooks, result shows battery life is longer with pipe split disabled. [How] Disable pipe split by default. Pipe split could be still enabled when required dispclk is greater than max dispclk. Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: NHersen Wu <hersenxs.wu@amd.com> Signed-off-by: NRoman Li <Roman.Li@amd.com> Reviewed-by: NRoman Li <Roman.Li@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Nikola Cornij 提交于
[why] Required for DSC MST Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: NNikola Cornij <nikola.cornij@amd.com> Reviewed-by: NZhan Liu <Zhan.Liu@amd.com> Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Wesley Chalmers 提交于
[WHY] The stack variable "val" is potentially unpopulate it, so initialize it with the value 0xf (indicating an invalid mux) Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: NWesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by: NMartin Leung <Martin.Leung@amd.com> Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Qingqing Zhuo 提交于
[Why] In dc_link_dp_set_test_pattern, we assume all pipes have a stream, which can cause null pointer dereference. [How] Add a null pointer check before accessing stream. Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: NQingqing Zhuo <qingqing.zhuo@amd.com> Reviewed-by: NNicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Victor Zhao 提交于
psp GFX_CTRL_CMD_ID_CONSUME_CMD different for windows and linux, according to psp, linux cmds are not correct. v2: only correct GFX_CTRL_CMD_ID_CONSUME_CMD. Signed-off-by: NVictor Zhao <Victor.Zhao@amd.com> Reviewed-by: NEmily.Deng <Emily.Deng@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alexandre Demers 提交于
This fix bug 210921 where DRM_INFO floods log when hitting an unsupported ASIC in amdgpu_device_asic_has_dc_support(). This info should be only called once. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=210921Signed-off-by: NAlexandre Demers <alexandre.f.demers@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 13 1月, 2021 3 次提交
-
-
由 Chris Wilson 提交于
The clear-residuals mitigation is a relatively heavy hammer and under some circumstances the user may wish to forgo the context isolation in order to meet some performance requirement. Introduce a generic module parameter to allow selectively enabling/disabling different mitigations. To disable just the clear-residuals mitigation (on Ivybridge, Baytrail, or Haswell) use the module parameter: i915.mitigations=auto,!residuals Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1858 Fixes: 47f8253d ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: stable@vger.kernel.org # v5.7 Reviewed-by: NJon Bloomfield <jon.bloomfield@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-3-chris@chris-wilson.co.uk (cherry picked from commit f7452c7c) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
The mitigation is required for all gen7 platforms, now that it does not cause GPU hangs, restore it for Ivybridge and Baytrail. Fixes: 47f8253d ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Bloomfield Jon <jon.bloomfield@intel.com> Reviewed-by: NAkeem G Abodunrin <akeem.g.abodunrin@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-2-chris@chris-wilson.co.uk (cherry picked from commit 008ead6e) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the range [0, n-1] where n is #EU * (#threads/EU) with the number of threads based on plaform and the number of EU based on the number of slices and subslices. This is a fixed number per platform/gt, so appropriately limit the number of threads we spawn to match the device. v2: Oversaturate the system with tasks to force execution on every HW thread; if the thread idles it is returned to the pool and may be reused again before an unused thread. v3: Fix more state commands, which was causing Baytrail to barf. v4: STATE_CACHE_INVALIDATE requires a stall on Ivybridge Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2024 Fixes: 47f8253d ("drm/i915/gen7: Clear all EU/L3 residual contexts") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Randy Wright <rwright@hpe.com> Cc: stable@vger.kernel.org # v5.7+ Reviewed-by: NAkeem G Abodunrin <akeem.g.abodunrin@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-1-chris@chris-wilson.co.uk (cherry picked from commit eebfb32e) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 12 1月, 2021 4 次提交
-
-
由 Christian König 提交于
set_pages_wb() might sleep and so we can't do this in an atomic context. Signed-off-by: NChristian König <christian.koenig@amd.com> Reported-by: NMikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Tested-by: NMikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Fixes: d099fc8f ("drm/ttm: new TT backend allocation pool v3") Reviewed-by: NHuang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/413409/
-
由 Bas Nieuwenhuizen 提交于
With modifiers one can actually have different format_info structs for the same format, which now matters for AMDGPU since we convert implicit modifiers to explicit modifiers with multiple planes. I checked other drivers and it doesn't look like they end up triggering this case so I think this is safe to relax. Signed-off-by: NBas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NZhan Liu <zhan.liu@amd.com> Acked-by: NChristian König <christian.koenig@amd.com> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Fixes: 816853f9 ("drm/amd/display: Set new format info for converted metadata.") Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210110021142.28221-1-bas@basnieuwenhuizen.nl
-
由 Jeremy Cline 提交于
check_unmap() is producing a warning about a missing map error check. The return value from dma_map_page() should be checked for an error, not the caller-provided dma_addr. Fixes: d099fc8f ("drm/ttm: new TT backend allocation pool v3") Signed-off-by: NJeremy Cline <jcline@redhat.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/413432/Signed-off-by: NChristian König <christian.koenig@amd.com>
-
由 Imre Deak 提交于
For an enabled DSC during HW readout the corresponding power reference is taken along the CRTC power domain references in get_crtc_power_domains(). Remove the incorrect get ref from the DSI encoder hook. Fixes: 2b68392e ("drm/i915/dsi: add support for DSC") Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201209153952.3397959-1-imre.deak@intel.com (cherry picked from commit 3a9ec563) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 11 1月, 2021 4 次提交
-
-
由 Jani Nikula 提交于
The pch_get_backlight(), lpt_get_backlight(), and lpt_set_backlight() functions operate directly on the hardware registers. If inverting the value is needed, using intel_panel_compute_brightness(), it should only be done in the interface between hardware registers and panel->backlight.level. The CPU mode takeover code added in commit 5b1ec9ac ("drm/i915/backlight: Fix backlight takeover on LPT, v3.") reads the hardware register and converts to panel->backlight.level correctly, however the value written back should remain in the hardware register "domain". This hasn't been an issue, because GM45 machines are the only known users of i915.invert_brightness and the brightness invert quirk, and without one of them no conversion is made. It's likely nobody's ever hit the problem. Fixes: 5b1ec9ac ("drm/i915/backlight: Fix backlight takeover on LPT, v3.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lyude Paul <lyude@redhat.com> Cc: <stable@vger.kernel.org> # v5.1+ Reviewed-by: NLyude Paul <lyude@redhat.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210108152841.6944-1-jani.nikula@intel.com (cherry picked from commit 0d4ced1c) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
As with the regular suspend paths, also disable the wakeref assertions as we disable the driver during shutdown. Reported-by: NHans de Goede <hdegoede@redhat.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2899 Fixes: fe0f1e3b ("drm/i915: Shut down displays gracefully on reboot") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Tested-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210104203905.19248-1-chris@chris-wilson.co.uk (cherry picked from commit 19fe4ac6) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Hans de Goede 提交于
drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence Commit 25b4620e ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode") added an intel_dsi_msleep() helper which skips sleeping if the MIPI-sequences have a version of 3 or newer and the panel is in vid-mode; and it moved a bunch of msleep-s over to this new helper. This was based on my reading of the big comment around line 730 which starts with "Panel enable/disable sequences from the VBT spec.", where the "v3 video mode seq" column does not have any wait t# entries. Given that this code has been used on a lot of different devices without issues until now, it seems that my interpretation of the spec here is mostly correct. But now I have encountered one device, an Acer Aspire Switch 10 E SW3-016, where the panel will not light up unless we do actually honor the panel_on_delay after exexuting the MIPI_SEQ_PANEL_ON sequence. What seems to set this model apart is that it is lacking a MIPI_SEQ_DEASSERT_RESET sequence, which is where the power-on delay usually happens. Fix the panel not lighting up on this model by using an unconditional msleep(panel_on_delay) instead of intel_dsi_msleep() when there is no MIPI_SEQ_DEASSERT_RESET sequence. Fixes: 25b4620e ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode") Signed-off-by: NHans de Goede <hdegoede@redhat.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201118124058.26021-1-hdegoede@redhat.com (cherry picked from commit 6fdb335f) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 John Stultz 提交于
Bing Song noticed the CMA heap was leaking memory due to a flub I made in commit a5d2d29e ("dma-buf: heaps: Move heap-helper logic into the cma_heap implementation"), and provided this fix which ensures the pagelist is also freed on release. Cc: Bing Song <bing.song@nxp.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Liam Mark <lmark@codeaurora.org> Cc: Laura Abbott <labbott@kernel.org> Cc: Brian Starkey <Brian.Starkey@arm.com> Cc: Hridya Valsaraju <hridya@google.com> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Sandeep Patil <sspatil@google.com> Cc: Daniel Mentz <danielmentz@google.com> Cc: Chris Goldsworthy <cgoldswo@codeaurora.org> Cc: Ørjan Eide <orjan.eide@arm.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Ezequiel Garcia <ezequiel@collabora.com> Cc: Simon Ser <contact@emersion.fr> Cc: James Jones <jajones@nvidia.com> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Reported-by: NBing Song <bing.song@nxp.com> Fixes: a5d2d29e ("dma-buf: heaps: Move heap-helper logic into the cma_heap implementation") Signed-off-by: NJohn Stultz <john.stultz@linaro.org> Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210107202616.75170-1-john.stultz@linaro.org
-
- 10 1月, 2021 2 次提交
-
-
由 Coly Li 提交于
If BCH_FEATURE_INCOMPAT_OBSO_LARGE_BUCKET is set in incompat feature set, it means the cache device is created with obsoleted layout with obso_bucket_site_hi. Now bcache does not support this feature bit, a new BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE incompat feature bit is added for a better layout to support large bucket size. For the legacy compatibility purpose, if a cache device created with obsoleted BCH_FEATURE_INCOMPAT_OBSO_LARGE_BUCKET feature bit, all bcache devices attached to this cache set should be set to read-only. Then the dirty data can be written back to backing device before re-create the cache device with BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE feature bit by the latest bcache-tools. This patch checks BCH_FEATURE_INCOMPAT_OBSO_LARGE_BUCKET feature bit when running a cache set and attach a bcache device to the cache set. If this bit is set, - When run a cache set, print an error kernel message to indicate all following attached bcache device will be read-only. - When attach a bcache device, print an error kernel message to indicate the attached bcache device will be read-only, and ask users to update to latest bcache-tools. Such change is only for cache device whose bucket size >= 32MB, this is for the zoned SSD and almost nobody uses such large bucket size at this moment. If you don't explicit set a large bucket size for a zoned SSD, such change is totally transparent to your bcache device. Fixes: ffa47032 ("bcache: add bucket_size_hi into struct cache_sb_disk for large bucket") Signed-off-by: NColy Li <colyli@suse.de> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Coly Li 提交于
When large bucket feature was added, BCH_FEATURE_INCOMPAT_LARGE_BUCKET was introduced into the incompat feature set. It used bucket_size_hi (which was added at the tail of struct cache_sb_disk) to extend current 16bit bucket size to 32bit with existing bucket_size in struct cache_sb_disk. This is not a good idea, there are two obvious problems, - Bucket size is always value power of 2, if store log2(bucket size) in existing bucket_size of struct cache_sb_disk, it is unnecessary to add bucket_size_hi. - Macro csum_set() assumes d[SB_JOURNAL_BUCKETS] is the last member in struct cache_sb_disk, bucket_size_hi was added after d[] which makes csum_set calculate an unexpected super block checksum. To fix the above problems, this patch introduces a new incompat feature bit BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE, when this bit is set, it means bucket_size in struct cache_sb_disk stores the order of power-of-2 bucket size value. When user specifies a bucket size larger than 32768 sectors, BCH_FEATURE_INCOMPAT_LOG_LARGE_BUCKET_SIZE will be set to incompat feature set, and bucket_size stores log2(bucket size) more than store the real bucket size value. The obsoleted BCH_FEATURE_INCOMPAT_LARGE_BUCKET won't be used anymore, it is renamed to BCH_FEATURE_INCOMPAT_OBSO_LARGE_BUCKET and still only recognized by kernel driver for legacy compatible purpose. The previous bucket_size_hi is renmaed to obso_bucket_size_hi in struct cache_sb_disk and not used in bcache-tools anymore. For cache device created with BCH_FEATURE_INCOMPAT_LARGE_BUCKET feature, bcache-tools and kernel driver still recognize the feature string and display it as "obso_large_bucket". With this change, the unnecessary extra space extend of bcache on-disk super block can be avoided, and csum_set() may generate expected check sum as well. Fixes: ffa47032 ("bcache: add bucket_size_hi into struct cache_sb_disk for large bucket") Signed-off-by: NColy Li <colyli@suse.de> Cc: stable@vger.kernel.org # 5.9+ Signed-off-by: NJens Axboe <axboe@kernel.dk>
-