[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #118 from Christopher Snowhill (kod...@gmail.com) --- Now experiencing this attempting to run Luxmark with literally any OpenCL runtime on my RX 480, be it ROCm, Clover, or AMDGPU Pro 20.45. Goody gumdrops, wlroots added support for adaptive sync / variable refresh rate 6 months ago, but Wayfire still hasn't added an option to control it, so it may or may not be in the mix. Happens with both 5.10.4 and 5.4.86 kernels. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: stop re-init the TTM page pool
On Wed, Jan 06, 2021 at 02:23:08AM +0800, Christian König wrote:
> Drivers are not supposed to init the page pool directly any more.
>
> Signed-off-by: Christian König
Series are Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index d4328ff57757..35b715f82ed8 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -729,9 +729,6 @@ int radeon_ttm_init(struct radeon_device *rdev)
> }
> rdev->mman.initialized = true;
>
> - ttm_pool_init(&rdev->mman.bdev.pool, rdev->dev, rdev->need_swiotlb,
> - dma_addressing_limited(&rdev->pdev->dev));
> -
> r = radeon_ttm_init_vram(rdev);
> if (r) {
> DRM_ERROR("Failed initializing VRAM heap.\n");
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
On Tue, 2021-01-05 at 12:30 +0100, Thomas Zimmermann wrote: > Hi > > Am 05.01.21 um 12:04 schrieb Gerd Hoffmann: > > Hi, > > > > > > It's not possible to do page flip with this virtual device. The > > > > call to > > > > SYNTHVID_VRAM_LOCATION is only honoured once. So unfortunately > > > > need to > > > > use SHMEM helpers. > > > > > > I was thinking about using struct > > > video_output_situation.vram_offset; in > > > case you want to tinker with that. There's a comment in the patch > > > that > > > vram_offset should always be 0. But this comment seems incorrect > > > for devices > > > with more than one output. > > > > Where does the comment come from? fbdev drivers support a single > > framebuffer only so for a fbdev driver it makes sense to set the > > offset > > to 0 unconditionally. With drm you probably can handle things > > differently ... > > I cannot find it in hyperv_fb.c; it must have gotten introduced here. > > Only one display is supported by this DRM driver, so the comment is > correct. In the future, having support for multiple displays might be > an > option. > > Beside that offset should be 0, another problem is that SYNTHVID_SITUATION_UPDATE will cause the whole screen to flicker (I suppose this call is more for changing resolution), so can't really use this for page-flip. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 4/4] drm/dp: Revert "drm/dp: Introduce EDID-based quirks"
This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that we know have working VESA backlight control interfaces
over DPCD. As well, it should be noted it was impossible to use the
normal sink OUI for recognizing these panels as none of them actually
filled out their OUIs, hence needing to resort to checking EDIDs.
At the time we weren't really sure why certain panels had issues with
DPCD backlight controls, but we eventually figured out that there was a
second interface that these problematic laptop panels actually did work
with and advertise properly: Intel's proprietary backlight interface for
HDR panels. So far the testing we've done hasn't brought any panels to
light that advertise this interface and don't support it properly, which
means we finally have a real solution to this problem.
As a result, we now have no need for the force DPCD backlight quirk, and
furthermore this also removes the need for any kind of EDID quirk
checking in DRM. So, let's just revert it for now since we were the only
driver using this.
v3:
* Rebase
v2:
* Fix indenting error picked up by checkpatch in
intel_edp_init_connector()
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
drivers/gpu/drm/drm_dp_helper.c | 83 +--
drivers/gpu/drm/drm_dp_mst_topology.c | 3 +-
.../drm/i915/display/intel_display_types.h| 1 -
drivers/gpu/drm/i915/display/intel_dp.c | 9 +-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +-
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
include/drm/drm_dp_helper.h | 21 +
7 files changed, 9 insertions(+), 113 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3ecde451f523..19dbdeb581cb 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1236,7 +1236,7 @@ bool drm_dp_read_sink_count_cap(struct drm_connector
*connector,
return connector->connector_type != DRM_MODE_CONNECTOR_eDP &&
dpcd[DP_DPCD_REV] >= DP_DPCD_REV_11 &&
dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT &&
- !drm_dp_has_quirk(desc, 0, DP_DPCD_QUIRK_NO_SINK_COUNT);
+ !drm_dp_has_quirk(desc, DP_DPCD_QUIRK_NO_SINK_COUNT);
}
EXPORT_SYMBOL(drm_dp_read_sink_count_cap);
@@ -1957,87 +1957,6 @@ drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident,
bool is_branch)
#undef DEVICE_ID_ANY
#undef DEVICE_ID
-struct edid_quirk {
- u8 mfg_id[2];
- u8 prod_id[2];
- u32 quirks;
-};
-
-#define MFG(first, second) { (first), (second) }
-#define PROD_ID(first, second) { (first), (second) }
-
-/*
- * Some devices have unreliable OUIDs where they don't set the device ID
- * correctly, and as a result we need to use the EDID for finding additional
- * DP quirks in such cases.
- */
-static const struct edid_quirk edid_quirk_list[] = {
- /* Optional 4K AMOLED panel in the ThinkPad X1 Extreme 2nd Generation
-* only supports DPCD backlight controls
-*/
- { MFG(0x4c, 0x83), PROD_ID(0x41, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- /*
-* Some Dell CML 2020 systems have panels support both AUX and PWM
-* backlight control, and some only support AUX backlight control. All
-* said panels start up in AUX mode by default, and we don't have any
-* support for disabling HDR mode on these panels which would be
-* required to switch to PWM backlight control mode (plus, I'm not
-* even sure we want PWM backlight controls over DPCD backlight
-* controls anyway...). Until we have a better way of detecting these,
-* force DPCD backlight mode on all of them.
-*/
- { MFG(0x06, 0xaf), PROD_ID(0x9b, 0x32),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- { MFG(0x06, 0xaf), PROD_ID(0xeb, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- { MFG(0x4d, 0x10), PROD_ID(0xc7, 0x14),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- { MFG(0x4d, 0x10), PROD_ID(0xe6, 0x14),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- { MFG(0x4c, 0x83), PROD_ID(0x47, 0x41),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
- { MFG(0x09, 0xe5), PROD_ID(0xde, 0x08),
BIT(DP_QUIRK_FORCE_DPCD_BACKLIGHT) },
-};
-
-#undef MFG
-#undef PROD_ID
-
-/**
- * drm_dp_get_edid_quirks() - Check the EDID of a DP device to find additional
- * DP-specific quirks
- * @edid: The EDID to check
- *
- * While OUIDs are meant to be used to recognize a DisplayPort device, a lot
- * of manufacturers don't seem to like following standards and neglect to fill
- * the dev-ID in, making it impossible to only use OUIDs for determining
- * quirks in some cases. This function can
[PATCH v4 3/4] drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight
Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting support for the Intel HDR interface.
So, this commit adds support for this by introducing two new
enable_dpcd_backlight options: 2 which forces i915 to only probe for the
VESA interface, and 3 which forces i915 to only probe for the Intel
backlight interface (might be useful if we find panels in the wild that
report the VESA interface in their VBT, but actually only support the
Intel backlight interface).
v3:
* Rebase
Signed-off-by: Lyude Paul
Reviewed-by: Jani Nikula
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
.../drm/i915/display/intel_dp_aux_backlight.c | 45 +--
drivers/gpu/drm/i915/i915_params.c| 2 +-
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 5eb472eb304f..94a9e3b1f24c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -611,15 +611,54 @@ static const struct intel_panel_bl_funcs
intel_dp_vesa_bl_funcs = {
.get = intel_dp_aux_vesa_get_backlight,
};
+enum intel_dp_aux_backlight_modparam {
+ INTEL_DP_AUX_BACKLIGHT_AUTO = -1,
+ INTEL_DP_AUX_BACKLIGHT_OFF = 0,
+ INTEL_DP_AUX_BACKLIGHT_ON = 1,
+ INTEL_DP_AUX_BACKLIGHT_FORCE_VESA = 2,
+ INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL = 3,
+};
+
int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
{
struct drm_device *dev = connector->base.dev;
struct intel_panel *panel = &connector->panel;
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ bool try_intel_interface = false, try_vesa_interface = false;
- if (i915->params.enable_dpcd_backlight == 0)
+ /* Check the VBT and user's module parameters to figure out which
+* interfaces to probe
+*/
+ switch (i915->params.enable_dpcd_backlight) {
+ case INTEL_DP_AUX_BACKLIGHT_OFF:
return -ENODEV;
+ case INTEL_DP_AUX_BACKLIGHT_AUTO:
+ switch (i915->vbt.backlight.type) {
+ case INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE:
+ try_vesa_interface = true;
+ break;
+ case INTEL_BACKLIGHT_DISPLAY_DDI:
+ try_intel_interface = true;
+ try_vesa_interface = true;
+ break;
+ default:
+ return -ENODEV;
+ }
+ break;
+ case INTEL_DP_AUX_BACKLIGHT_ON:
+ if (i915->vbt.backlight.type !=
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
+ try_intel_interface = true;
+
+ try_vesa_interface = true;
+ break;
+ case INTEL_DP_AUX_BACKLIGHT_FORCE_VESA:
+ try_vesa_interface = true;
+ break;
+ case INTEL_DP_AUX_BACKLIGHT_FORCE_INTEL:
+ try_intel_interface = true;
+ break;
+ }
/*
* A lot of eDP panels in the wild will report supporting both the
@@ -628,13 +667,13 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *connector)
* and will only work with the Intel interface. So, always probe for
* that first.
*/
- if (intel_dp_aux_supports_hdr_backlight(connector)) {
+ if (try_intel_interface &&
intel_dp_aux_supports_hdr_backlight(connector)) {
drm_dbg_kms(dev, "Using Intel proprietary eDP backlight
controls\n");
panel->backlight.funcs = &intel_dp_hdr_bl_funcs;
return 0;
}
- if (intel_dp_aux_supports_vesa_backlight(connector)) {
+ if (try_vesa_interface &&
intel_dp_aux_supports_vesa_backlight(connector)) {
drm_dbg_kms(dev, "Using VESA eDP backlight controls\n");
panel->backlight.funcs = &intel_dp_vesa_bl_funcs;
return 0;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 7f139ea4a90b..6939634e56ed 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -185,7 +185,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400,
i915_param_named(enable_dpcd_backlight, int, 0400,
"Enable support for DPCD backlight control"
- "(-1=use per-VBT LFP backlight type setting [default], 0=disabled,
1=enabled)");
+ "(-1=use per-VBT LFP backlight type setting [default], 0=disabled,
1=enable, 2=force VESA interface, 3=force Intel interface)");
#if IS_ENABLED(CONFIG_DRM_
[PATCH v4 2/4] drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.
Simply put-there's two main backlight interfaces Intel can see in the
wild. Intel's proprietary HDR backlight interface, and the standard VESA
backlight interface. Note that many panels have been observed to report
support for both backlight interfaces, but testing has shown far more
panels work with the Intel HDR backlight interface at the moment.
Additionally, the VBT appears to be capable of reporting support for the
VESA backlight interface but not the Intel HDR interface which needs to
be probed by setting the right magic OUI.
On top of that however, there's also actually two different variants of
the Intel HDR backlight interface. The first uses the AUX channel for
controlling the brightness of the screen in both SDR and HDR mode, and
the second only uses the AUX channel for setting the brightness level in
HDR mode - relying on PWM for setting the brightness level in SDR mode.
For the time being we've been using EDIDs to maintain a list of quirks
for panels that safely do support the VESA backlight interface. Adding
support for Intel's HDR backlight interface in addition however, should
finally allow us to auto-detect eDP backlight controls properly so long
as we probe like so:
* If the panel's VBT reports VESA backlight support, assume it really
does support it
* If the panel's VBT reports DDI backlight controls:
* First probe for Intel's HDR backlight interface
* If that fails, probe for VESA's backlight interface
* If that fails, assume no DPCD backlight control
* If the panel's VBT reports any other backlight type: just assume it
doesn't have DPCD backlight controls
Changes since v3:
* Stop using drm_device and use drm_i915_private instead
* Don't forget to return from intel_dp_aux_hdr_get_backlight() if we fail
to read the current backlight mode from the DPCD
* s/uint8_t/u8/
* Remove unneeded parenthesis in intel_dp_aux_hdr_enable_backlight()
* Use drm_dbg_kms() in intel_dp_aux_init_backlight_funcs()
Signed-off-by: Lyude Paul
Acked-by: Jani Nikula
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
.../drm/i915/display/intel_display_types.h| 9 +-
.../drm/i915/display/intel_dp_aux_backlight.c | 246 --
drivers/gpu/drm/i915/display/intel_panel.c| 42 ++-
drivers/gpu/drm/i915/display/intel_panel.h| 4 +
4 files changed, 269 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ee5c2d50b81a..b24d80ffd18b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -261,7 +261,14 @@ struct intel_panel {
struct pwm_state pwm_state;
/* DPCD backlight */
- u8 pwmgen_bit_count;
+ union {
+ struct {
+ u8 pwmgen_bit_count;
+ } vesa;
+ struct {
+ bool sdr_uses_aux;
+ } intel;
+ } edp;
struct backlight_device *device;
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 9775f33d1aac..5eb472eb304f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -22,8 +22,26 @@
*
*/
+/*
+ * Laptops with Intel GPUs which have panels that support controlling the
+ * backlight through DP AUX can actually use two different interfaces: Intel's
+ * proprietary DP AUX backlight interface, and the standard VESA backlight
+ * interface. Unfortunately, at the time of writing this a lot of laptops will
+ * advertise support for the standard VESA backlight interface when they
+ * don't properly support it. However, on these systems the Intel backlight
+ * interface generally does work properly. Additionally, these systems will
+ * usually just indicate that they use PWM backlight controls in their VBIOS
+ * for some reason.
+ */
+
#include "intel_display_types.h"
#include "intel_dp_aux_backlight.h"
+#include "intel_panel.h"
+
+/* TODO:
+ * Implement HDR, right now we just implement the bare minimum to bring us
back into SDR mode so we
+ * can make people's backlights work in the mean time
+ */
/*
* DP AUX registers for Intel's proprietary HDR backlight interface. We define
@@ -77,6 +95,177 @@
#define INTEL_EDP_BRIGHTNESS_OPTIMIZATION_10x359
+/* Intel EDP backlight callbacks */
+static bool
+intel_dp_aux_supports_hdr_backlight(struct intel_connector *connector)
+{
+ struct drm_i915_privat
[PATCH v4 1/4] drm/i915: Keep track of pwm-related backlight hooks separately
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.
HDR backlights, in particular VESA and Intel's HDR backlight
implementations, can end up being more complicated. With Intel's
proprietary interface, HDR backlight controls always run through the
DPCD. When the backlight is in SDR backlight mode however, the driver
may need to bypass the TCON and control the backlight directly through
PWM.
So, in order to support this we'll need to split our backlight callbacks
into two groups: a set of high-level backlight control callbacks in
intel_panel, and an additional set of pwm-specific backlight control
callbacks. This also implies a functional changes for how these
callbacks are used:
* We now keep track of two separate backlight level ranges, one for the
high-level backlight, and one for the pwm backlight range
* We also keep track of backlight enablement and PWM backlight
enablement separately
* Since the currently set backlight level might not be the same as the
currently programmed PWM backlight level, we stop setting
panel->backlight.level with the currently programmed PWM backlight
level in panel->backlight.pwm_funcs->setup(). Instead, we rely
on the higher level backlight control functions to retrieve the
current PWM backlight level (in this case, intel_pwm_get_backlight()).
Note that there are still a few PWM backlight setup callbacks that
do actually need to retrieve the current PWM backlight level, although
we no longer save this value in panel->backlight.level like before.
Additionally, we drop the call to lpt_get_backlight() in
lpt_setup_backlight(), and avoid unconditionally writing the PWM value that
we get from it and only write it back if we're in CPU mode, and switching
to PCH mode. The reason for this is because in the original codepath for
this, it was expected that the intel_panel_bl_funcs->setup() hook would be
responsible for fetching the initial backlight level. On lpt systems, the
only time we could ever be in PCH backlight mode is during the initial
driver load - meaning that outside of the setup() hook, lpt_get_backlight()
will always be the callback used for retrieving the current backlight
level. After this patch we still need to fetch and write-back the PCH
backlight value if we're switching from CPU mode to PCH, but because
intel_pwm_setup_backlight() will retrieve the backlight level after setup()
using the get() hook, which always ends up being lpt_get_backlight(). Thus
- an additional call to lpt_get_backlight() in lpt_setup_backlight() is
made redundant.
v4:
* Fix commit message
* Remove outdated comment in intel_panel.c
* Rename pwm_(min|max) to pwm_level_(min|max)
* Use intel_pwm_get_backlight() in intel_pwm_setup_backlight() instead of
indirection
* Don't move intel_dp_aux_init_bcklight_funcs() call to bottom of
intel_panel_init_backlight_funcs() quite yet
v3:
* Reuse intel_panel_bl_funcs() for pwm_funcs
* Explain why we drop lpt_get_backlight()
Signed-off-by: Lyude Paul
Cc: thay...@noraisin.net
Cc: Vasily Khoruzhick
---
.../drm/i915/display/intel_display_types.h| 4 +
drivers/gpu/drm/i915/display/intel_panel.c| 333 ++
2 files changed, 187 insertions(+), 150 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 1067bd073c95..ee5c2d50b81a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -252,6 +252,9 @@ struct intel_panel {
bool alternate_pwm_increment; /* lpt+ */
/* PWM chip */
+ u32 pwm_level_min;
+ u32 pwm_level_max;
+ bool pwm_enabled;
bool util_pin_active_low; /* bxt+ */
u8 controller; /* bxt+ only */
struct pwm_device *pwm;
@@ -263,6 +266,7 @@ struct intel_panel {
struct backlight_device *device;
const struct intel_panel_bl_funcs *funcs;
+ const struct intel_panel_bl_funcs *pwm_funcs;
void (*power)(struct intel_connector *, bool enable);
} backlight;
};
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index 67f81ae995c4..4469ce6760e9 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -511,25 +511,34 @@ static u32 scale_hw_to_user(struct intel_connector
*connector,
0, user_max);
}
-static u32 intel_panel_compute_brightness(struct intel_connector *connector,
- u32 val)
+static u32 intel_panel_sanitize_pwm_level(struct intel_connector *connector,
u32 val)
{
struct drm_i915_private *dev_
[Bug 211043] amdgpu: Mouse cursor freeze of external mouse after a while (after kernel crash?) (KDE Plasma)
https://bugzilla.kernel.org/show_bug.cgi?id=211043 --- Comment #2 from Daniel (kdeb...@staznosti.sk) --- No, no particular application, it happens in general in KDE Plasma. Anyway, I am not sure this is now related to the amdgpu crash. I think this is rather related to bluetooth suspend. I recently added btusb.enable_autosuspend=0 to GRUB_CMDLINE_LINUX_DEFAULT and haven't seen this issue so far. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8, 5/6] drm/mediatek: add RDMA fifo size error handle
Hi, Yongqiang: Yongqiang Niu 於 2021年1月5日 週二 下午2:36寫道： > > On Mon, 2020-12-14 at 22:54 +0800, Chun-Kuang Hu wrote: > > Hi, Yongqiang: > > > > Yongqiang Niu 於 2020年12月11日 週五 上午8:45寫道： > > > > > > On Thu, 2020-12-10 at 23:50 +0800, Chun-Kuang Hu wrote: > > > > Hi, Yongqiang: > > > > > > > > Yongqiang Niu 於 2020年12月10日 週四 下午5:08寫道： > > > > > > > > > > This patch add RDMA fifo size error handle > > > > > rdma fifo size will not always bigger than the calculated threshold > > > > > if that case happened, we need set fifo size as the threshold > > > > > > > > > > Signed-off-by: Yongqiang Niu > > > > > --- > > > > > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 4 > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > > > > > b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > > > > > index 794acc5..0508392 100644 > > > > > --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > > > > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > > > > > @@ -151,6 +151,10 @@ static void mtk_rdma_config(struct mtk_ddp_comp > > > > > *comp, unsigned int width, > > > > > * account for blanking, and with a pixel depth of 4 bytes: > > > > > */ > > > > > threshold = width * height * vrefresh * 4 * 7 / 100; > > > > > + > > > > > + if (threshold > rdma_fifo_size) > > > > > + threshold = rdma_fifo_size; > > > > > > > > If the formula is not correct, you should fix the formula not work > > > > around. > > > > > > > > Regards, > > > > Chun-Kuang. > > > > > > how about this: > > > threshold = max(width * height * vrefresh * 4 * 7 / 100, > > > rdma_fifo_size); > > > > When I use width = 1920, height = 1080, vrefresh = 60 to calculate, I > > get threshold = 2985. > > So I think set threshold to half of fifo size is OK for MAX_WIDTH, > > MAX_HEIGHT, MAX_VREFRESH (these three may be different in each SoC) > > > > threshold = RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) / 2; > > > > But I worry half fifo size is too big for small resolution and let > > small resolution too easy to trigger burst read DRAM. So let the > > formula to be this: > > > > threshold = RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) * width * height * > > vrefresh / 2 / MAX_WIDTH / MAX_HEIGHT / MAX_VREFRESH; > > > > How do you think about this? > > > > Regards, > > Chun-Kuang. > > how about remove this formula, and set threshold = rdma_fifo_size This means that RDMA would always trigger burst read. In normal case, I think no hardware would trigger burst read. Only the emergency occur, the hardware trigger burst read. RDMA always triggering burst read is good for RDMA, but it may hurt other hardware to read DRAM. So I think RDMA should trigger burst read only when fifo data is under a emergency threshold. Regards, Chun-Kuang. > > > > > > > > > > > + > > > > > reg = RDMA_FIFO_UNDERFLOW_EN | > > > > > RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) | > > > > > RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold); > > > > > -- > > > > > 1.8.1.1.dirty > > > > > ___ > > > > > Linux-mediatek mailing list > > > > > linux-media...@lists.infradead.org > > > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/8] drm/vmwgfx: Cleanup fifo mmio handling
Hi Zack,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip
linus/master v5.11-rc2 next-20210104]
[cannot apply to tegra-drm/drm/tegra/for-next drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Zack-Rusin/Misc-cleanups-and-fixes-for-vmwgfx/20210106-022755
base: https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
exynos-drm-next
config: i386-randconfig-a006-20210106 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/15c65b4940b46b333f5bd0ddd5377ca90250ef80
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Zack-Rusin/Misc-cleanups-and-fixes-for-vmwgfx/20210106-022755
git checkout 15c65b4940b46b333f5bd0ddd5377ca90250ef80
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from include/linux/printk.h:7,
from include/linux/kernel.h:16,
from arch/x86/include/asm/percpu.h:27,
from arch/x86/include/asm/current.h:6,
from include/linux/sched.h:12,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from include/linux/dma-mapping.h:7,
from drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:29:
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c: In function 'vmw_driver_load':
>> include/linux/kern_levels.h:5:18: warning: format '%llu' expects argument of
>> type 'long long unsigned int', but argument 2 has type 'resource_size_t'
>> {aka 'unsigned int'} [-Wformat=]
5 | #define KERN_SOH "\001" /* ASCII Start Of Header */
| ^~
include/linux/kern_levels.h:14:19: note: in expansion of macro 'KERN_SOH'
14 | #define KERN_INFO KERN_SOH "6" /* informational */
| ^~~~
include/drm/drm_print.h:481:15: note: in expansion of macro 'KERN_INFO'
481 | printk##once(KERN_##level "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
| ^
include/drm/drm_print.h:484:2: note: in expansion of macro '_DRM_PRINTK'
484 | _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
| ^~~
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:800:2: note: in expansion of macro
'DRM_INFO'
800 | DRM_INFO("Maximum display memory size is %llu kiB\n",
| ^~~~
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:800:46: note: format string is defined
here
800 | DRM_INFO("Maximum display memory size is %llu kiB\n",
| ~~~^
| |
| long long unsigned int
| %u
In file included from include/linux/printk.h:7,
from include/linux/kernel.h:16,
from arch/x86/include/asm/percpu.h:27,
from arch/x86/include/asm/current.h:6,
from include/linux/sched.h:12,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from include/linux/dma-mapping.h:7,
from drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:29:
include/linux/kern_levels.h:5:18: warning: format '%llx' expects argument of
type 'long long unsigned int', but argument 2 has type 'resource_size_t' {aka
'unsigned int'} [-Wformat=]
5 | #define KERN_SOH "\001" /* ASCII Start Of Header */
| ^~
include/linux/kern_levels.h:14:19: note: in expansion of macro 'KERN_SOH'
14 | #define KERN_INFO KERN_SOH "6" /* informational */
| ^~~~
include/drm/drm_print.h:481:15: note: in expansion of macro 'KERN_INFO'
481 | printk##once(KERN_##level "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
| ^
include/drm/drm_print.h:484:2: note: in expansion of macro '_DRM_PRINTK'
484 | _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
| ^~~
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:802:2: note: in expansion of macro
'DRM_INFO'
802 | DRM_INFO("VRAM at 0x%08llx size is %llu kiB\n",
| ^~~~
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:802:27: note: format string is defined
here
802 | DRM_INFO("VRAM at 0
Re: A PCI quirk for resizeable BAR 0 on Navi10
On Tue, Jan 05, 2021 at 02:44:00PM +0100, Christian König wrote:
> Hi Bjorn,
>
> Darren stumbled over an AMD GPU with nonsense in it's resizeable BAR
> capability dword.
>
> This is most likely fixable with a VBIOS update, but we already sold quite a
> bunch of those boards with the problem.
>
> The driver still loads without this, but the performance isn't the best.
>
> Do you have any objection to merge this through the drm branch?
I'm OK with this in general, but please pay attention to your commit
logs:
- Subject line prefix is "PCI: " (capitalized).
- First word of subject is capitalized ("Add ...", "Export ...").
- No period at end of subject ("4/4 ... XT Pulse.").
- No "v2" included in subject line ("PCI: Add BAR ... v2").
- Include parentheses after function names, e.g.,
"pci_rebar_get_possible_sizes()".
- Commit logs should say directly what the patch does using
imperative mood, not just "to assist with X". E.g., "Export
pci_rebar_get_possible_sizes() for use by modular drivers."
This should make sense even without reading the subject line.
- No "v2" verbiage included in commit log (you can include it after
the "---" line if you want). That verbiage in 2/4 also contains
two typos.
- 2/4 does two things, so split it into two patches. Then the
subject and commit logs will make more sense.
- Splitting 2/4 will also give you an opportunity to explain why we
need to change "static inline" to "static __always_inline". If we
don't need that change, don't change it.
If we *do* need it, that means we likely need it for many other
things in include/linux/pci.h, and I would want to fix all those
places at once in a separate patch.
- 4/4 should be more specific about what's wrong. Based on the
code, this device advertises support for BAR 0 being 256MB, 512MB,
or 1GB, but it actually supports 2GB, 4GB, 8GB, and 16GB as well.
Please spell that out in the commit log. "Otherwise the CPU can't
fully access the BAR" really doesn't tell me what the patch does.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/9] drm/i915: Keep track of pwm-related backlight hooks separately
On Wed, 2020-12-23 at 18:37 +0200, Jani Nikula wrote:
> On Fri, 04 Dec 2020, Lyude Paul wrote:
> > Currently, every different type of backlight hook that i915 supports is
> > pretty straight forward - you have a backlight, probably through PWM
> > (but maybe DPCD), with a single set of platform-specific hooks that are
> > used for controlling it.
> >
> > HDR backlights, in particular VESA and Intel's HDR backlight
> > implementations, can end up being more complicated. With Intel's
> > proprietary interface, HDR backlight controls always run through the
> > DPCD. When the backlight is in SDR backlight mode however, the driver
> > may need to bypass the TCON and control the backlight directly through
> > PWM.
> >
> > So, in order to support this we'll need to split our backlight callbacks
> > into two groups: a set of high-level backlight control callbacks in
> > intel_panel, and an additional set of pwm-specific backlight control
> > callbacks. This also implies a functional changes for how these
> > callbacks are used:
> >
> > * We now keep track of two separate backlight level ranges, one for the
> > high-level backlight, and one for the pwm backlight range
> > * We also keep track of backlight enablement and PWM backlight
> > enablement separately
> > * Since the currently set backlight level might not be the same as the
> > currently programmed PWM backlight level, we stop setting
> > panel->backlight.level with the currently programmed PWM backlight
> > level in panel->backlight.pwm_funcs->setup(). Instead, we rely
> > on the higher level backlight control functions to retrieve the
> > current PWM backlight level (in this case, intel_pwm_get_backlight()).
> > Note that there are still a few PWM backlight setup callbacks that
> > do actually need to retrieve the current PWM backlight level, although
> > we no longer save this value in panel->backlight.level like before.
> >
> > Additionally, we drop the call to lpt_get_backlight() in
> > lpt_setup_backlight(), and avoid unconditionally writing the PWM value
> > that
> > we get from it and only write it back if we're in PCH mode. The reason for
>
> Should be something like, "...only write it back if we're in CPU mode,
> and switching to PCH mode."
>
> > this is because in the original codepath for this, it was expected that
> > the
> > intel_panel_bl_funcs->setup() hook would be responsible for fetching the
> > initial backlight level. On lpt systems, the only time we could ever be in
> > PCH backlight mode is during the initial driver load - meaning that
> > outside
> > of the setup() hook, lpt_get_backlight() will always be the callback used
> > for retrieving the current backlight level. After this patch we still need
> > to fetch and write-back the PCH backlight value if we're in PCH mode, but
>
> Ditto here. We may probe at CPU mode, set up by BIOS/GOP, but we always
> switch to PCH override mode. (The pch_ prefixed function naming is
> misleading...)
>
> Historically there was a CPU register for pwm control. Then the
> functionality was moved to PCH but the register remained. Then there was
> a transition to PCH register, but the CPU register remained and used
> some low level internal messaging from CPU to PCH, unless PCH override
> was set. Finally the messaging was removed. Anyway, on the CPU+PCH
> combos where we can choose, we prefer using the PCH register directly
> ("PCH mode") and not use the CPU register with messaging. Simple made
> complex(tm).
>
> > because intel_pwm_setup_backlight() will retrieve the backlight level
> > after
> > setup() using the get() hook, which always ends up being
> > lpt_get_backlight(). Thus - an additional call to lpt_get_backlight() in
> > lpt_setup_backlight() is made redundant.
> >
> > v3:
> > * Reuse intel_panel_bl_funcs() for pwm_funcs
> > * Explain why we drop lpt_get_backlight()
> >
> > Signed-off-by: Lyude Paul
> > Cc: thay...@noraisin.net
> > Cc: Vasily Khoruzhick
> > ---
> > .../drm/i915/display/intel_display_types.h | 4 +
> > drivers/gpu/drm/i915/display/intel_panel.c | 344 ++
> > 2 files changed, 194 insertions(+), 154 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index a70d1bf29aa5..47ee565c49a2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -252,6 +252,9 @@ struct intel_panel {
> > bool alternate_pwm_increment; /* lpt+ */
> >
> > /* PWM chip */
> > + u32 pwm_min;
> > + u32 pwm_max;
> > + bool pwm_enabled;
> > bool util_pin_active_low; /* bxt+ */
> > u8 controller; /* bxt+ only */
> > struct pwm_device *pwm;
> > @@ -263,6 +266,7 @@ struct intel_panel {
> > struct backlight_device *device;
> >
>
[Bug 211033] [bisected][regression] amdgpu: *ERROR* Restoring old state failed with -12
https://bugzilla.kernel.org/show_bug.cgi?id=211033 Mike Old (south.of.hea...@gmx.at) changed: What|Removed |Added CC||south.of.hea...@gmx.at --- Comment #5 from Mike Old (south.of.hea...@gmx.at) --- Same problem on Arch (5.10.4), AMD RX580. In my case it works without issues if I set the monitor to 120hz instead of 144hz in GNOME settings. Can also be worked around by setting the monitor (monitor settings) to Display Port version 1.1 and thus a lower refresh rate or by using HDMI instead of DP. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/12] drm: Add dummy page per device or GEM object
On 11/23/20 3:01 AM, Christian König wrote:
Am 23.11.20 um 05:54 schrieb Andrey Grodzovsky:
On 11/21/20 9:15 AM, Christian König wrote:
Am 21.11.20 um 06:21 schrieb Andrey Grodzovsky:
Will be used to reroute CPU mapped BO's page faults once
device is removed.
Uff, one page for each exported DMA-buf? That's not something we can do.
We need to find a different approach here.
Can't we call alloc_page() on each fault and link them together so they are
freed when the device is finally reaped?
For sure better to optimize and allocate on demand when we reach this corner
case, but why the linking ?
Shouldn't drm_prime_gem_destroy be good enough place to free ?
I want to avoid keeping the page in the GEM object.
What we can do is to allocate a page on demand for each fault and link the
together in the bdev instead.
And when the bdev is then finally destroyed after the last application closed
we can finally release all of them.
Christian.
Hey, started to implement this and then realized that by allocating a page for
each fault indiscriminately
we will be allocating a new page for each faulting virtual address within a VA
range belonging the same BO
and this is obviously too much and not the intention. Should I instead use let's
say a hashtable with the hash
key being faulting BO address to actually keep allocating and reusing same dummy
zero page per GEM BO
(or for that matter DRM file object address for non imported BOs) ?
Andrey
Andrey
Regards,
Christian.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_file.c | 8
drivers/gpu/drm/drm_prime.c | 10 ++
include/drm/drm_file.h | 2 ++
include/drm/drm_gem.h | 2 ++
4 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 0ac4566..ff3d39f 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -193,6 +193,12 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
goto out_prime_destroy;
}
+ file->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!file->dummy_page) {
+ ret = -ENOMEM;
+ goto out_prime_destroy;
+ }
+
return file;
out_prime_destroy:
@@ -289,6 +295,8 @@ void drm_file_free(struct drm_file *file)
if (dev->driver->postclose)
dev->driver->postclose(dev, file);
+ __free_page(file->dummy_page);
+
drm_prime_destroy_file_private(&file->prime);
WARN_ON(!list_empty(&file->event_list));
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 1693aa7..987b45c 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -335,6 +335,13 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
ret = drm_prime_add_buf_handle(&file_priv->prime,
dma_buf, *handle);
+
+ if (!ret) {
+ obj->dummy_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+ if (!obj->dummy_page)
+ ret = -ENOMEM;
+ }
+
mutex_unlock(&file_priv->prime.lock);
if (ret)
goto fail;
@@ -1020,6 +1027,9 @@ void drm_prime_gem_destroy(struct drm_gem_object
*obj, struct sg_table *sg)
dma_buf_unmap_attachment(attach, sg, DMA_BIDIRECTIONAL);
dma_buf = attach->dmabuf;
dma_buf_detach(attach->dmabuf, attach);
+
+ __free_page(obj->dummy_page);
+
/* remove the reference */
dma_buf_put(dma_buf);
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 716990b..2a011fc 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -346,6 +346,8 @@ struct drm_file {
*/
struct drm_prime_file_private prime;
+ struct page *dummy_page;
+
/* private: */
#if IS_ENABLED(CONFIG_DRM_LEGACY)
unsigned long lock_count; /* DRI1 legacy lock count */
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 337a483..76a97a3 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -311,6 +311,8 @@ struct drm_gem_object {
*
*/
const struct drm_gem_object_funcs *funcs;
+
+ struct page *dummy_page;
};
/**
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Candrey.grodzovsky%40amd.com%7Ce08536eb5d514059a20108d88f85f7f1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637417152856369678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5Xpxivlggqknu%2FgVtpmrpYHT9g%2B%2Buj5JCPyJyoh%2B7V4%3D&reserved=0
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Candrey.grodzovsky%40amd.com%7Ce08536eb5d514059a20108d88f85f7f1%7C3dd8961fe4884e608e11a8
Re: [PATCH] dt-bindings: Add missing array size constraints
Hi Rob, On Tue, Jan 5, 2021 at 8:03 AM Rob Herring wrote: > > DT properties which can have multiple entries need to specify what the > entries are and define how many entries there can be. In the case of > only a single entry, just 'maxItems: 1' is sufficient. > > Add the missing entry constraints. These were found with a modified > meta-schema. Unfortunately, there are a few cases where the size > constraints are not defined such as common bindings, so the meta-schema > can't be part of the normal checks. > > Cc: Jens Axboe > Cc: Stephen Boyd > Cc: Thierry Reding > Cc: MyungJoo Ham > Cc: Chanwoo Choi > Cc: Linus Walleij > Cc: Bartosz Golaszewski > Cc: Jonathan Cameron > Cc: Dmitry Torokhov > Cc: Thomas Gleixner > Cc: Marc Zyngier > Cc: Mauro Carvalho Chehab > Cc: Chen-Yu Tsai > Cc: Ulf Hansson > Cc: "David S. Miller" > Cc: Jakub Kicinski > Cc: Sebastian Reichel > Cc: Ohad Ben-Cohen > Cc: Bjorn Andersson > Cc: Greg Kroah-Hartman > Signed-off-by: Rob Herring > --- > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-g...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-in...@vger.kernel.org > Cc: linux-me...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: net...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: linux-remotep...@vger.kernel.org > Cc: linux-ri...@lists.infradead.org > Cc: linux-ser...@vger.kernel.org > Cc: alsa-de...@alsa-project.org > Cc: linux-...@vger.kernel.org > Cc: linux-...@vger.kernel.org > --- > .../socionext,uniphier-system-cache.yaml | 4 ++-- > .../bindings/ata/sata_highbank.yaml | 1 + > .../bindings/clock/canaan,k210-clk.yaml | 1 + > .../bindings/display/brcm,bcm2711-hdmi.yaml | 1 + > .../bindings/display/brcm,bcm2835-hdmi.yaml | 1 + > .../display/panel/jdi,lt070me05000.yaml | 1 + > .../display/panel/mantix,mlaf057we51-x.yaml | 3 ++- > .../display/panel/novatek,nt36672a.yaml | 1 + > .../devicetree/bindings/dsp/fsl,dsp.yaml | 2 +- > .../devicetree/bindings/eeprom/at25.yaml | 3 +-- > .../bindings/extcon/extcon-ptn5150.yaml | 2 ++ For extcon part, Acked-by: Chanwoo Choi (snip) Best Regards, Chanwoo Choi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 210849] Black screen after resume from long suspend. Open/Close lid. AMDGPU
https://bugzilla.kernel.org/show_bug.cgi?id=210849 --- Comment #9 from xrootw...@gmail.com --- 'no_console_suspend' in boot options fix problem absolutely in my case. maybe this is temporally fix, but i hope it will be fixed normally. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: update radeon/amdgpu/amdkfd git trees
FDO is out of space, so move to gitlab. Signed-off-by: Alex Deucher --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index eb18459c1d16..e2877be6b10d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -907,7 +907,7 @@ AMD KFD M: Felix Kuehling L: amd-...@lists.freedesktop.org S: Supported -T: git git://people.freedesktop.org/~agd5f/linux +T: git https://gitlab.freedesktop.org/agd5f/linux.git F: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd*.[ch] F: drivers/gpu/drm/amd/amdkfd/ F: drivers/gpu/drm/amd/include/cik_structs.h @@ -14596,7 +14596,7 @@ M: Alex Deucher M: Christian König L: amd-...@lists.freedesktop.org S: Supported -T: git git://people.freedesktop.org/~agd5f/linux +T: git https://gitlab.freedesktop.org/agd5f/linux.git F: drivers/gpu/drm/amd/ F: drivers/gpu/drm/radeon/ F: include/uapi/drm/amdgpu_drm.h -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 28/31] PM / devfreq: imx8m-ddrc: convert to use devm_pm_opp_* API
Hi Yangtao,
On Tue, Jan 5, 2021 at 1:13 PM Chanwoo Choi wrote:
>
> On Sun, Jan 3, 2021 at 12:58 PM Yangtao Li wrote:
> >
> > Use devm_pm_opp_* API to simplify code.
> >
> > Signed-off-by: Yangtao Li
> > ---
> > drivers/devfreq/imx8m-ddrc.c | 15 ++-
> > 1 file changed, 2 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/devfreq/imx8m-ddrc.c b/drivers/devfreq/imx8m-ddrc.c
> > index bc82d3653bff..9383d6e5538b 100644
> > --- a/drivers/devfreq/imx8m-ddrc.c
> > +++ b/drivers/devfreq/imx8m-ddrc.c
> > @@ -370,11 +370,6 @@ static int imx8m_ddrc_check_opps(struct device *dev)
> > return 0;
> > }
> >
> > -static void imx8m_ddrc_exit(struct device *dev)
> > -{
> > - dev_pm_opp_of_remove_table(dev);
> > -}
> > -
> > static int imx8m_ddrc_probe(struct platform_device *pdev)
> > {
> > struct device *dev = &pdev->dev;
> > @@ -419,7 +414,7 @@ static int imx8m_ddrc_probe(struct platform_device
> > *pdev)
> > return ret;
> > }
> >
> > - ret = dev_pm_opp_of_add_table(dev);
> > + ret = devm_pm_opp_of_add_table(dev);
> > if (ret < 0) {
> > dev_err(dev, "failed to get OPP table\n");
> > return ret;
> > @@ -427,12 +422,11 @@ static int imx8m_ddrc_probe(struct platform_device
> > *pdev)
> >
> > ret = imx8m_ddrc_check_opps(dev);
> > if (ret < 0)
> > - goto err;
> > + return ret;
> >
> > priv->profile.polling_ms = 1000;
> > priv->profile.target = imx8m_ddrc_target;
> > priv->profile.get_dev_status = imx8m_ddrc_get_dev_status;
> > - priv->profile.exit = imx8m_ddrc_exit;
> > priv->profile.get_cur_freq = imx8m_ddrc_get_cur_freq;
> > priv->profile.initial_freq = clk_get_rate(priv->dram_core);
> >
> > @@ -441,13 +435,8 @@ static int imx8m_ddrc_probe(struct platform_device
> > *pdev)
> > if (IS_ERR(priv->devfreq)) {
> > ret = PTR_ERR(priv->devfreq);
> > dev_err(dev, "failed to add devfreq device: %d\n", ret);
> > - goto err;
> > }
> >
> > - return 0;
> > -
> > -err:
> > - dev_pm_opp_of_remove_table(dev);
> > return ret;
>
> devm_devfreq_add_device() doesn't return any integer value.
> Even if devm_devfreq_add_device() returns the right devfreq instance,
> the 'ret' value is not the return value of devm_devfreq_add_device().
>
> On this patch, 'ret' value of 'return ret' is from imx8m_ddrc_check_opps().
> Surely, it is well working with this modification. But, it is not code
> for exception handling.
> So, we need to remain the following codes:
>
> return 0;
> err:
> return ret;
>
'err' is not necessary. You better to edit it as following:
if (IS_ERR(priv->devfreq)) {
dev_err(dev, "failed to add devfreq device: %d\n", ret);
return PTR_ERR(priv->devfreq);
}
return 0;
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amdgpu: Add check to prevenet IH overflow
On Tue, Jan 5, 2021 at 11:49 AM Christian König
wrote:
>
> Am 05.01.21 um 17:06 schrieb Defang Bo:
> > Similar to commit ("drm/amdgpu: fix IH overflow on Vega10
> > v2").
> > When an ring buffer overflow happens the appropriate bit is set in the WPTR
> > register which is also written back to memory. But clearing the bit in the
> > WPTR doesn't trigger another memory writeback.
> >
> > So what can happen is that we end up processing the buffer overflow over and
> > over again because the bit is never cleared. Resulting in a random system
> > lockup because of an infinite loop in an interrupt handler.
> >
> > Signed-off-by: Defang Bo
>
> Reviewed-by: Christian König
>
> Thanks for the help,
> Christian.
Applied. Thanks!
Alex
>
> > ---
> > Changes since v1:
> > - Modify the subject and replace the wrong register.
> > ---
> > ---
> > drivers/gpu/drm/amd/amdgpu/cz_ih.c | 39
> > +
> > drivers/gpu/drm/amd/amdgpu/iceland_ih.c | 36
> > +++---
> > drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 37
> > ---
> > 3 files changed, 72 insertions(+), 40 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/cz_ih.c
> > b/drivers/gpu/drm/amd/amdgpu/cz_ih.c
> > index 1dca0cabc326..65361afb21ab 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/cz_ih.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/cz_ih.c
> > @@ -190,22 +190,33 @@ static u32 cz_ih_get_wptr(struct amdgpu_device *adev,
> > struct amdgpu_ih_ring *ih)
> > {
> > u32 wptr, tmp;
> > -
> > +
> > wptr = le32_to_cpu(*ih->wptr_cpu);
> >
> > - if (REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW)) {
> > - wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
> > - /* When a ring buffer overflow happen start parsing interrupt
> > - * from the last not overwritten vector (wptr + 16). Hopefully
> > - * this should allow us to catchup.
> > - */
> > - dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
> > 0x%08X)\n",
> > - wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
> > - ih->rptr = (wptr + 16) & ih->ptr_mask;
> > - tmp = RREG32(mmIH_RB_CNTL);
> > - tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
> > - WREG32(mmIH_RB_CNTL, tmp);
> > - }
> > + if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
> > + goto out;
> > +
> > + /* Double check that the overflow wasn't already cleared. */
> > + wptr = RREG32(mmIH_RB_WPTR);
> > +
> > + if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
> > + goto out;
> > +
> > + wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
> > +
> > + /* When a ring buffer overflow happen start parsing interrupt
> > + * from the last not overwritten vector (wptr + 16). Hopefully
> > + * this should allow us to catchup.
> > + */
> > + dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
> > 0x%08X)\n",
> > + wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
> > + ih->rptr = (wptr + 16) & ih->ptr_mask;
> > + tmp = RREG32(mmIH_RB_CNTL);
> > + tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
> > + WREG32(mmIH_RB_CNTL, tmp);
> > +
> > +
> > +out:
> > return (wptr & ih->ptr_mask);
> > }
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/iceland_ih.c
> > b/drivers/gpu/drm/amd/amdgpu/iceland_ih.c
> > index a13dd9a51149..8e4dae8addb9 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/iceland_ih.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/iceland_ih.c
> > @@ -193,19 +193,29 @@ static u32 iceland_ih_get_wptr(struct amdgpu_device
> > *adev,
> >
> > wptr = le32_to_cpu(*ih->wptr_cpu);
> >
> > - if (REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW)) {
> > - wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
> > - /* When a ring buffer overflow happen start parsing interrupt
> > - * from the last not overwritten vector (wptr + 16). Hopefully
> > - * this should allow us to catchup.
> > - */
> > - dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
> > 0x%08X)\n",
> > - wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
> > - ih->rptr = (wptr + 16) & ih->ptr_mask;
> > - tmp = RREG32(mmIH_RB_CNTL);
> > - tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
> > - WREG32(mmIH_RB_CNTL, tmp);
> > - }
> > + if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
> > + goto out;
> > +
> > + /* Double check that the overflow wasn't already cleared. */
> > + wptr = RREG32(mmIH_RB_WPTR);
> > +
> > + if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
> > + goto out;
> > +
> > + wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
> > + /* When a ring buffer overf
[kbuild] Re: [PATCH 4/4] PCI: add a REBAR size quirk for Sapphire RX 5600 XT Pulse.
Hi Christian,
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/pci-export-pci_rebar_get_possible_sizes/20210105-224446
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: x86_64-randconfig-m001-20210105 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
smatch warnings:
drivers/pci/pci.c:3611 pci_rebar_get_possible_sizes() warn: statement has no
effect 22
vim +3611 drivers/pci/pci.c
276b738deb5bf85 Christian König 2017-10-24 3596 u32
pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar)
276b738deb5bf85 Christian König 2017-10-24 3597 {
276b738deb5bf85 Christian König 2017-10-24 3598int pos;
276b738deb5bf85 Christian König 2017-10-24 3599u32 cap;
276b738deb5bf85 Christian König 2017-10-24 3600
276b738deb5bf85 Christian König 2017-10-24 3601pos =
pci_rebar_find_pos(pdev, bar);
276b738deb5bf85 Christian König 2017-10-24 3602if (pos < 0)
276b738deb5bf85 Christian König 2017-10-24 3603return 0;
276b738deb5bf85 Christian König 2017-10-24 3604
276b738deb5bf85 Christian König 2017-10-24 3605
pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap);
6838a45fc2394ec Christian König 2021-01-05 3606cap = (cap &
PCI_REBAR_CAP_SIZES) >> 4;
6838a45fc2394ec Christian König 2021-01-05 3607
6838a45fc2394ec Christian König 2021-01-05 3608/* Sapphire RX 5600 XT
Pulse has an invalid cap dword for BAR 0 */
6838a45fc2394ec Christian König 2021-01-05 3609if (pdev->vendor ==
PCI_VENDOR_ID_ATI && pdev->device == 0x731f &&
6838a45fc2394ec Christian König 2021-01-05 3610bar == 0 && cap ==
0x700)
6838a45fc2394ec Christian König 2021-01-05 @3611cap == 0x7f00;
== vs =.
6838a45fc2394ec Christian König 2021-01-05 3612
6838a45fc2394ec Christian König 2021-01-05 3613return cap;
276b738deb5bf85 Christian König 2017-10-24 3614 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
kbuild mailing list -- kbu...@lists.01.org
To unsubscribe send an email to kbuild-le...@lists.01.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/8] drm/vmwgfx: Cleanup the cmd/fifo split
Lets try to cleanup the usage of the term FIFO which we used for
both our MMIO based cmd queue processing and for general
command processing which could have been using command buffers
interface. We're going to rename the functions which are processing
commands (and work either via MMIO or command buffers) as _cmd_
and functions which operate on the MMIO based commands as FIFO
to match the SVGA device naming.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
---
drivers/gpu/drm/vmwgfx/Makefile | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_binding.c | 52 +--
.../vmwgfx/{vmwgfx_fifo.c => vmwgfx_cmd.c}| 40 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c| 14 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 40 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 12 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 30 +--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 16 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c | 8 +--
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 21
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 16 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 8 +--
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 24 -
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 24 -
drivers/gpu/drm/vmwgfx/vmwgfx_so.c| 8 +--
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 28 +-
drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c | 8 +--
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 40 +++---
23 files changed, 199 insertions(+), 207 deletions(-)
rename drivers/gpu/drm/vmwgfx/{vmwgfx_fifo.c => vmwgfx_cmd.c} (94%)
diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index ef455d6d7c3f..cc4cdca7176e 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
vmwgfx_fb.o vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
- vmwgfx_fifo.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
+ vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
vmwgfx_surface.o vmwgfx_prime.o vmwgfx_mob.o vmwgfx_shader.o \
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
index f41550797970..180f6dbc9460 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
@@ -555,7 +555,7 @@ static int vmw_binding_scrub_shader(struct vmw_ctx_bindinfo
*bi, bool rebind)
SVGA3dCmdSetShader body;
} *cmd;
- cmd = VMW_FIFO_RESERVE(dev_priv, sizeof(*cmd));
+ cmd = VMW_CMD_RESERVE(dev_priv, sizeof(*cmd));
if (unlikely(cmd == NULL))
return -ENOMEM;
@@ -564,7 +564,7 @@ static int vmw_binding_scrub_shader(struct vmw_ctx_bindinfo
*bi, bool rebind)
cmd->body.cid = bi->ctx->id;
cmd->body.type = binding->shader_slot + SVGA3D_SHADERTYPE_MIN;
cmd->body.shid = ((rebind) ? bi->res->id : SVGA3D_INVALID_ID);
- vmw_fifo_commit(dev_priv, sizeof(*cmd));
+ vmw_cmd_commit(dev_priv, sizeof(*cmd));
return 0;
}
@@ -587,7 +587,7 @@ static int vmw_binding_scrub_render_target(struct
vmw_ctx_bindinfo *bi,
SVGA3dCmdSetRenderTarget body;
} *cmd;
- cmd = VMW_FIFO_RESERVE(dev_priv, sizeof(*cmd));
+ cmd = VMW_CMD_RESERVE(dev_priv, sizeof(*cmd));
if (unlikely(cmd == NULL))
return -ENOMEM;
@@ -598,7 +598,7 @@ static int vmw_binding_scrub_render_target(struct
vmw_ctx_bindinfo *bi,
cmd->body.target.sid = ((rebind) ? bi->res->id : SVGA3D_INVALID_ID);
cmd->body.target.face = 0;
cmd->body.target.mipmap = 0;
- vmw_fifo_commit(dev_priv, sizeof(*cmd));
+ vmw_cmd_commit(dev_priv, sizeof(*cmd));
return 0;
}
@@ -626,7 +626,7 @@ static int vmw_binding_scrub_texture(struct
vmw_ctx_bindinfo *bi,
} body;
} *cmd;
- cmd = VMW_FIFO_RESERVE(dev_priv, sizeof(*cmd));
+ cmd = VMW_CMD_RESERVE(dev_priv, sizeof(*cmd));
if (unlikely(cmd == NULL))
return -ENOMEM;
@@ -636,7 +636,7 @@ static int vmw_binding_scrub_texture(struct
vmw_ctx_bindinfo *bi,
cmd->body.s1.stage = binding->texture_stage;
cmd->body.s1.name = SVGA3D_TS_BIND_TEXTURE;
cmd->body.s1.value = ((rebind) ? bi->res->id : SVGA3D_INVALID_ID);
- vmw_fifo_commit(dev_priv, sizeof(*cmd)
[PATCH v2 4/8] drm/vmwgfx: Cleanup fifo mmio handling
Going forward the svga device might reuse mmio for general
register accesses, in order to prepare for that we need to
cleanup our naming and handling of fifo specific mmio reads
and writes. As part of this work lets switch to managed
mapping of the fifo mmio to make the error handling cleaner.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
Reviewed-by: Roland Scheidegger
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 29 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 31 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 24
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 83 +--
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 13 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 9 +--
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 14 ++---
7 files changed, 94 insertions(+), 109 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 08402c203f52..d94ba065bb61 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -682,7 +682,7 @@ static int vmw_driver_load(struct vmw_private *dev_priv,
unsigned long chipset)
dev_priv->io_start = pci_resource_start(dev_priv->drm.pdev, 0);
dev_priv->vram_start = pci_resource_start(dev_priv->drm.pdev, 1);
- dev_priv->mmio_start = pci_resource_start(dev_priv->drm.pdev, 2);
+ dev_priv->fifo_mem_start = pci_resource_start(dev_priv->drm.pdev, 2);
dev_priv->assume_16bpp = !!vmw_assume_16bpp;
@@ -712,7 +712,7 @@ static int vmw_driver_load(struct vmw_private *dev_priv,
unsigned long chipset)
}
dev_priv->vram_size = vmw_read(dev_priv, SVGA_REG_VRAM_SIZE);
- dev_priv->mmio_size = vmw_read(dev_priv, SVGA_REG_MEM_SIZE);
+ dev_priv->fifo_mem_size = vmw_read(dev_priv, SVGA_REG_MEM_SIZE);
dev_priv->fb_max_width = vmw_read(dev_priv, SVGA_REG_MAX_WIDTH);
dev_priv->fb_max_height = vmw_read(dev_priv, SVGA_REG_MAX_HEIGHT);
@@ -796,19 +796,21 @@ static int vmw_driver_load(struct vmw_private *dev_priv,
unsigned long chipset)
DRM_INFO("Max dedicated hypervisor surface memory is %u kiB\n",
(unsigned)dev_priv->memory_size / 1024);
}
- DRM_INFO("Maximum display memory size is %u kiB\n",
+ DRM_INFO("Maximum display memory size is %llu kiB\n",
dev_priv->prim_bb_mem / 1024);
- DRM_INFO("VRAM at 0x%08x size is %u kiB\n",
+ DRM_INFO("VRAM at 0x%08llx size is %llu kiB\n",
dev_priv->vram_start, dev_priv->vram_size / 1024);
- DRM_INFO("MMIO at 0x%08x size is %u kiB\n",
-dev_priv->mmio_start, dev_priv->mmio_size / 1024);
+ DRM_INFO("MMIO at 0x%08llx size is %llu kiB\n",
+dev_priv->fifo_mem_start, dev_priv->fifo_mem_size / 1024);
- dev_priv->mmio_virt = memremap(dev_priv->mmio_start,
- dev_priv->mmio_size, MEMREMAP_WB);
+ dev_priv->fifo_mem = devm_memremap(dev_priv->drm.dev,
+ dev_priv->fifo_mem_start,
+ dev_priv->fifo_mem_size,
+ MEMREMAP_WB);
- if (unlikely(dev_priv->mmio_virt == NULL)) {
+ if (unlikely(dev_priv->fifo_mem == NULL)) {
ret = -ENOMEM;
- DRM_ERROR("Failed mapping MMIO.\n");
+ DRM_ERROR("Failed mapping the FIFO MMIO.\n");
goto out_err0;
}
@@ -818,7 +820,7 @@ static int vmw_driver_load(struct vmw_private *dev_priv,
unsigned long chipset)
!vmw_fifo_have_pitchlock(dev_priv)) {
ret = -ENOSYS;
DRM_ERROR("Hardware has no pitchlock\n");
- goto out_err4;
+ goto out_err0;
}
dev_priv->tdev = ttm_object_device_init(&ttm_mem_glob, 12,
@@ -827,7 +829,7 @@ static int vmw_driver_load(struct vmw_private *dev_priv,
unsigned long chipset)
if (unlikely(dev_priv->tdev == NULL)) {
DRM_ERROR("Unable to initialize TTM object management.\n");
ret = -ENOMEM;
- goto out_err4;
+ goto out_err0;
}
dev_priv->drm.dev_private = dev_priv;
@@ -987,8 +989,6 @@ static int vmw_driver_load(struct vmw_private *dev_priv,
unsigned long chipset)
pci_release_regions(dev_priv->drm.pdev);
out_no_device:
ttm_object_device_release(&dev_priv->tdev);
-out_err4:
- memunmap(dev_priv->mmio_virt);
out_err0:
for (i = vmw_res_context; i < vmw_res_max; ++i)
idr_destroy(&dev_priv->res_idr[i]);
@@ -1035,7 +1035,6 @@ static void vmw_driver_unload(struct drm_device *dev)
pci_release_regions(dev->pdev);
ttm_object_device_release(&dev_priv->tdev);
- memunmap(dev_priv->mmio_virt);
if (dev_priv->ctx.staged_bindings)
vmw_binding_state_free(dev_priv->ctx.staged_bindings);
diff --git a/
[PATCH v2 6/8] drm/vmwgfx: Remove the throttling code
Throttling was used before fencing to implement early vsync
support in the xorg state tracker a long time ago. The xorg
state tracker has been removed years ago and no one else
has ever used throttling. It's time to remove this code,
it hasn't been used or tested in years.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
Reviewed-by: Roland Scheidegger
---
drivers/gpu/drm/vmwgfx/Makefile | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 21
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 6 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c| 4 -
drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_marker.c | 155
6 files changed, 3 insertions(+), 188 deletions(-)
delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_marker.c
diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index 31f85f09f1fc..ef455d6d7c3f 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -2,8 +2,8 @@
vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
vmwgfx_fb.o vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
vmwgfx_fifo.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
- vmwgfx_overlay.o vmwgfx_marker.o vmwgfx_gmrid_manager.o \
- vmwgfx_fence.o vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
+ vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
+ vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
vmwgfx_surface.o vmwgfx_prime.o vmwgfx_mob.o vmwgfx_shader.o \
vmwgfx_cmdbuf_res.o vmwgfx_cmdbuf.o vmwgfx_stdu.o \
vmwgfx_cotable.o vmwgfx_so.o vmwgfx_binding.o vmwgfx_msg.o \
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 46ab748edb5d..f3775617a28c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -276,13 +276,6 @@ struct vmw_surface {
struct list_head view_list;
};
-struct vmw_marker_queue {
- struct list_head head;
- u64 lag;
- u64 lag_time;
- spinlock_t lock;
-};
-
struct vmw_fifo_state {
unsigned long reserved_size;
u32 *dynamic_buffer;
@@ -292,7 +285,6 @@ struct vmw_fifo_state {
uint32_t capabilities;
struct mutex fifo_mutex;
struct rw_semaphore rwsem;
- struct vmw_marker_queue marker_queue;
bool dx;
};
@@ -1120,19 +1112,6 @@ extern void vmw_generic_waiter_add(struct vmw_private
*dev_priv, u32 flag,
extern void vmw_generic_waiter_remove(struct vmw_private *dev_priv,
u32 flag, int *waiter_count);
-/**
- * Rudimentary fence-like objects currently used only for throttling -
- * vmwgfx_marker.c
- */
-
-extern void vmw_marker_queue_init(struct vmw_marker_queue *queue);
-extern void vmw_marker_queue_takedown(struct vmw_marker_queue *queue);
-extern int vmw_marker_push(struct vmw_marker_queue *queue,
- uint32_t seqno);
-extern int vmw_marker_pull(struct vmw_marker_queue *queue,
- uint32_t signaled_seqno);
-extern int vmw_wait_lag(struct vmw_private *dev_priv,
- struct vmw_marker_queue *queue, uint32_t us);
/**
* Kernel framebuffer - vmwgfx_fb.c
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 6c016001721d..69cf0973bf28 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -4046,11 +4046,7 @@ int vmw_execbuf_process(struct drm_file *file_priv,
}
if (throttle_us) {
- ret = vmw_wait_lag(dev_priv, &dev_priv->fifo.marker_queue,
- throttle_us);
-
- if (ret)
- goto out_free_fence_fd;
+ VMW_DEBUG_USER("Throttling is no longer supported.\n");
}
kernel_commands = vmw_execbuf_cmdbuf(dev_priv, user_commands,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index 4674bc1c32f0..f4b9af67551f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -157,7 +157,6 @@ int vmw_fifo_init(struct vmw_private *dev_priv, struct
vmw_fifo_state *fifo)
atomic_set(&dev_priv->marker_seq, dev_priv->last_read_seqno);
vmw_fifo_mem_write(dev_priv, SVGA_FIFO_FENCE,
dev_priv->last_read_seqno);
- vmw_marker_queue_init(&fifo->marker_queue);
return 0;
}
@@ -185,8 +184,6 @@ void vmw_fifo_release(struct vmw_private *dev_priv, struct
vmw_fifo_state *fifo)
vmw_write(dev_priv, SVGA_REG_TRACES,
dev_priv->traces_state);
- vmw_marker_queue_takedown(&fifo->marker_queue);
-
if (likely(fifo->static_buffer != NULL)) {
vfree(fifo->static_buffer);
fifo->static_buffer = NULL;
@@ -563,7 +560,6 @@ int vmw_fifo_send_fence(struct vmw_privat
[PATCH v2 5/8] drm/vmwgfx: Cleanup pci resource allocation
Instead of doing it in multiple spots lets centralize the code
to handle pci resources. This also cleans up the error
handling a bit and will make it a lot easier to add additional
svga versions to the driver.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
Reviewed-by: Roland Scheidegger
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 112 +---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 5 +-
2 files changed, 72 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index d94ba065bb61..d2adaf3e4e1e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -43,8 +43,6 @@
#include "vmwgfx_drv.h"
#define VMWGFX_DRIVER_DESC "Linux drm driver for VMware graphics devices"
-#define VMWGFX_CHIP_SVGAII 0
-#define VMW_FB_RESERVATION 0
#define VMW_MIN_INITIAL_WIDTH 800
#define VMW_MIN_INITIAL_HEIGHT 600
@@ -253,8 +251,8 @@ static const struct drm_ioctl_desc vmw_ioctls[] = {
};
static const struct pci_device_id vmw_pci_id_list[] = {
- {0x15ad, 0x0405, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VMWGFX_CHIP_SVGAII},
- {0, 0, 0}
+ { PCI_DEVICE(0x15ad, VMWGFX_PCI_ID_SVGA2) },
+ { }
};
MODULE_DEVICE_TABLE(pci, vmw_pci_id_list);
@@ -644,18 +642,81 @@ static void vmw_vram_manager_fini(struct vmw_private
*dev_priv)
#endif
}
-static int vmw_driver_load(struct vmw_private *dev_priv, unsigned long chipset)
+static int vmw_setup_pci_resources(struct vmw_private *dev,
+ unsigned long pci_id)
{
+ resource_size_t fifo_start;
+ resource_size_t fifo_size;
int ret;
+
+ pci_set_master(dev->drm.pdev);
+
+ ret = pci_request_regions(dev->drm.pdev, "vmwgfx probe");
+ if (ret)
+ return ret;
+
+ dev->io_start = pci_resource_start(dev->drm.pdev, 0);
+ dev->vram_start = pci_resource_start(dev->drm.pdev, 1);
+ dev->vram_size = pci_resource_len(dev->drm.pdev, 1);
+ fifo_start = pci_resource_start(dev->drm.pdev, 2);
+ fifo_size = pci_resource_len(dev->drm.pdev, 2);
+
+ DRM_INFO("FIFO at 0x%llx size is %llu kiB\n",
+fifo_start, fifo_size / 1024);
+ dev->fifo_mem = devm_memremap(dev->drm.dev,
+ fifo_start,
+ fifo_size,
+ MEMREMAP_WB);
+
+ if (unlikely(dev->fifo_mem == NULL)) {
+ DRM_ERROR("Failed mapping FIFO memory.\n");
+ return -ENOMEM;
+ }
+
+ /*
+* This is approximate size of the vram, the exact size will only
+* be known after we read SVGA_REG_VRAM_SIZE. The PCI resource
+* size will be equal to or bigger than the size reported by
+* SVGA_REG_VRAM_SIZE.
+*/
+ DRM_INFO("VRAM at 0x%llx size is %llu kiB\n",
+dev->vram_start, dev->vram_size / 1024);
+
+ return 0;
+}
+
+static int vmw_detect_version(struct vmw_private *dev)
+{
uint32_t svga_id;
+
+ vmw_write(dev, SVGA_REG_ID, SVGA_ID_2);
+ svga_id = vmw_read(dev, SVGA_REG_ID);
+ if (svga_id != SVGA_ID_2) {
+ DRM_ERROR("Unsupported SVGA ID 0x%x on chipset 0x%x\n",
+ svga_id, dev->vmw_chipset);
+ return -ENOSYS;
+ }
+ return 0;
+}
+
+static int vmw_driver_load(struct vmw_private *dev_priv, u32 pci_id)
+{
+ int ret;
enum vmw_res_type i;
bool refuse_dma = false;
char host_log[100] = {0};
- pci_set_master(dev_priv->drm.pdev);
-
- dev_priv->vmw_chipset = chipset;
+ dev_priv->vmw_chipset = pci_id;
dev_priv->last_read_seqno = (uint32_t) -100;
+ dev_priv->drm.dev_private = dev_priv;
+
+ ret = vmw_setup_pci_resources(dev_priv, pci_id);
+ if (ret)
+ return ret;
+ ret = vmw_detect_version(dev_priv);
+ if (ret)
+ return ret;
+
mutex_init(&dev_priv->cmdbuf_mutex);
mutex_init(&dev_priv->release_mutex);
mutex_init(&dev_priv->binding_mutex);
@@ -680,21 +741,10 @@ static int vmw_driver_load(struct vmw_private *dev_priv,
unsigned long chipset)
dev_priv->used_memory_size = 0;
- dev_priv->io_start = pci_resource_start(dev_priv->drm.pdev, 0);
- dev_priv->vram_start = pci_resource_start(dev_priv->drm.pdev, 1);
- dev_priv->fifo_mem_start = pci_resource_start(dev_priv->drm.pdev, 2);
-
dev_priv->assume_16bpp = !!vmw_assume_16bpp;
dev_priv->enable_fb = enable_fbdev;
- vmw_write(dev_priv, SVGA_REG_ID, SVGA_ID_2);
- svga_id = vmw_read(dev_priv, SVGA_REG_ID);
- if (svga_id != SVGA_ID_2) {
- ret = -ENOSYS;
- DRM_ERROR("Unsupported SVGA ID 0x%x\n", svga_id);
- goto out_err0;
- }
dev_priv->capabilities = vmw_read(dev_priv, SVGA_REG_CAPABILITIES);
@@ -798,21 +8
[PATCH v2 8/8] drm/vmwgfx: Fix display register usage for some older configs
We can't be setting the display_id register to an invalid value
because that makes our device reset the fb which causes nasty
flicker (due to destruction and creation of a new fb).
Also we can't be using the BITS_PER_PIXEL register if the
8BIT_EMULATION is not supported.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
Reviewed-by: Roland Scheidegger
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 1 -
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index f2a9188d0b7d..9a89f658e501 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1875,7 +1875,8 @@ int vmw_kms_write_svga(struct vmw_private *vmw_priv,
vmw_fifo_mem_write(vmw_priv, SVGA_FIFO_PITCHLOCK, pitch);
vmw_write(vmw_priv, SVGA_REG_WIDTH, width);
vmw_write(vmw_priv, SVGA_REG_HEIGHT, height);
- vmw_write(vmw_priv, SVGA_REG_BITS_PER_PIXEL, bpp);
+ if ((vmw_priv->capabilities & SVGA_CAP_8BIT_EMULATION) != 0)
+ vmw_write(vmw_priv, SVGA_REG_BITS_PER_PIXEL, bpp);
if (vmw_read(vmw_priv, SVGA_REG_DEPTH) != depth) {
DRM_ERROR("Invalid depth %u for %u bpp, host expects %u\n",
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index ac806ae78894..9a9508edbc9e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -125,7 +125,6 @@ static int vmw_ldu_commit_list(struct vmw_private *dev_priv)
vmw_write(dev_priv, SVGA_REG_DISPLAY_POSITION_Y, crtc->y);
vmw_write(dev_priv, SVGA_REG_DISPLAY_WIDTH,
crtc->mode.hdisplay);
vmw_write(dev_priv, SVGA_REG_DISPLAY_HEIGHT,
crtc->mode.vdisplay);
- vmw_write(dev_priv, SVGA_REG_DISPLAY_ID, SVGA_ID_INVALID);
i++;
}
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/8] drm/vmwgfx: add Zack Rusin as maintainer
From: Roland Scheidegger Reviewed-by: Zack Rusin Signed-off-by: Roland Scheidegger --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 17b92e6a0f06..f07dec22121c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5739,6 +5739,7 @@ F:drivers/gpu/drm/vboxvideo/ DRM DRIVER FOR VMWARE VIRTUAL GPU M: "VMware Graphics" M: Roland Scheidegger +M: Zack Rusin L: dri-devel@lists.freedesktop.org S: Supported T: git git://people.freedesktop.org/~sroland/linux -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/8] drm/vmwgfx: Switch to a managed drm device
To cleanup some of the error handling and prepare for some
other work lets switch to a managed drm device. It will
let us get a better handle on some of the error paths.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
Reviewed-by: Roland Scheidegger
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 85 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 10 +--
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 36 -
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c| 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 6 +-
10 files changed, 73 insertions(+), 90 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
index 9a9fe10d829b..6a88c7d64719 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
@@ -1230,7 +1230,7 @@ int vmw_cmdbuf_set_pool_size(struct vmw_cmdbuf_man *man,
/* First, try to allocate a huge chunk of DMA memory */
size = PAGE_ALIGN(size);
- man->map = dma_alloc_coherent(&dev_priv->dev->pdev->dev, size,
+ man->map = dma_alloc_coherent(&dev_priv->drm.pdev->dev, size,
&man->handle, GFP_KERNEL);
if (man->map) {
man->using_mob = false;
@@ -1313,7 +1313,7 @@ struct vmw_cmdbuf_man *vmw_cmdbuf_man_create(struct
vmw_private *dev_priv)
man->num_contexts = (dev_priv->capabilities & SVGA_CAP_HP_CMD_QUEUE) ?
2 : 1;
man->headers = dma_pool_create("vmwgfx cmdbuf",
- &dev_priv->dev->pdev->dev,
+ &dev_priv->drm.pdev->dev,
sizeof(SVGACBHeader),
64, PAGE_SIZE);
if (!man->headers) {
@@ -1322,7 +1322,7 @@ struct vmw_cmdbuf_man *vmw_cmdbuf_man_create(struct
vmw_private *dev_priv)
}
man->dheaders = dma_pool_create("vmwgfx inline cmdbuf",
- &dev_priv->dev->pdev->dev,
+ &dev_priv->drm.pdev->dev,
sizeof(struct vmw_cmdbuf_dheader),
64, PAGE_SIZE);
if (!man->dheaders) {
@@ -1387,7 +1387,7 @@ void vmw_cmdbuf_remove_pool(struct vmw_cmdbuf_man *man)
ttm_bo_put(man->cmd_space);
man->cmd_space = NULL;
} else {
- dma_free_coherent(&man->dev_priv->dev->pdev->dev,
+ dma_free_coherent(&man->dev_priv->drm.pdev->dev,
man->size, man->map, man->handle);
}
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 279f6854e8a3..08402c203f52 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -609,7 +609,7 @@ static int vmw_dma_select_mode(struct vmw_private *dev_priv)
*/
static int vmw_dma_masks(struct vmw_private *dev_priv)
{
- struct drm_device *dev = dev_priv->dev;
+ struct drm_device *dev = &dev_priv->drm;
int ret = 0;
ret = dma_set_mask_and_coherent(dev->dev, DMA_BIT_MASK(64));
@@ -644,24 +644,16 @@ static void vmw_vram_manager_fini(struct vmw_private
*dev_priv)
#endif
}
-static int vmw_driver_load(struct drm_device *dev, unsigned long chipset)
+static int vmw_driver_load(struct vmw_private *dev_priv, unsigned long chipset)
{
- struct vmw_private *dev_priv;
int ret;
uint32_t svga_id;
enum vmw_res_type i;
bool refuse_dma = false;
char host_log[100] = {0};
- dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
- if (unlikely(!dev_priv)) {
- DRM_ERROR("Failed allocating a device private struct.\n");
- return -ENOMEM;
- }
+ pci_set_master(dev_priv->drm.pdev);
- pci_set_master(dev->pdev);
-
- dev_priv->dev = dev;
dev_priv->vmw_chipset = chipset;
dev_priv->last_read_seqno = (uint32_t) -100;
mutex_init(&dev_priv->cmdbuf_mutex);
@@ -688,9 +680,9 @@ static int vmw_driver_load(struct drm_device *dev, unsigned
long chipset)
dev_priv->used_memory_size = 0;
- dev_priv->io_start = pci_resource_start(dev->pdev, 0);
- dev_priv->vram_start = pci_resource_start(dev->pdev, 1);
- dev_priv->mmio_start = pci_resource_start(dev->pdev, 2);
+ dev_priv->io_start = pci_resource_start(dev_priv->drm.pdev, 0);
+ dev_priv->vram_start = pci_resource_start(dev_priv->drm.pdev, 1);
+ dev_priv->mmio_start = pci_resource_start(dev_priv->drm.pdev, 2);
dev_priv->assume_16bpp = !!vmw_assume_16bpp;
@@ -794,7 +786,
[PATCH v2 2/8] drm/vmwgfx: Remove stealth mode
Before drm got helpers for removing conflicting pci framebuffer devices
we implemented something known as "stealth" mode which allowed vmwgfx
to run even if it couldn't reserve pci resources. We can just switch
to regular drm helpers instead of keeping the stealth mode alive as
it makes our code a lot cleaner.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
Reviewed-by: Roland Scheidegger
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 31 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 5 -
2 files changed, 10 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 0008be02d31c..279f6854e8a3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -32,6 +32,7 @@
#include
#include
+#include
#include
#include
#include
@@ -840,19 +841,9 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
dev->dev_private = dev_priv;
ret = pci_request_regions(dev->pdev, "vmwgfx probe");
- dev_priv->stealth = (ret != 0);
- if (dev_priv->stealth) {
- /**
-* Request at least the mmio PCI resource.
-*/
-
- DRM_INFO("It appears like vesafb is loaded. "
-"Ignore above error if any.\n");
- ret = pci_request_region(dev->pdev, 2, "vmwgfx stealth probe");
- if (unlikely(ret != 0)) {
- DRM_ERROR("Failed reserving the SVGA MMIO resource.\n");
- goto out_no_device;
- }
+ if (ret) {
+ DRM_ERROR("Failed reserving PCI regions.\n");
+ goto out_no_device;
}
if (dev_priv->capabilities & SVGA_CAP_IRQMASK) {
@@ -1001,10 +992,7 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
if (dev_priv->capabilities & SVGA_CAP_IRQMASK)
vmw_irq_uninstall(dev_priv->dev);
out_no_irq:
- if (dev_priv->stealth)
- pci_release_region(dev->pdev, 2);
- else
- pci_release_regions(dev->pdev);
+ pci_release_regions(dev->pdev);
out_no_device:
ttm_object_device_release(&dev_priv->tdev);
out_err4:
@@ -1052,10 +1040,7 @@ static void vmw_driver_unload(struct drm_device *dev)
vmw_fence_manager_takedown(dev_priv->fman);
if (dev_priv->capabilities & SVGA_CAP_IRQMASK)
vmw_irq_uninstall(dev_priv->dev);
- if (dev_priv->stealth)
- pci_release_region(dev->pdev, 2);
- else
- pci_release_regions(dev->pdev);
+ pci_release_regions(dev->pdev);
ttm_object_device_release(&dev_priv->tdev);
memunmap(dev_priv->mmio_virt);
@@ -1509,6 +1494,10 @@ static int vmw_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
struct drm_device *dev;
int ret;
+ ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev,
"svgadrmfb");
+ if (ret)
+ return ret;
+
ret = pci_enable_device(pdev);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 5b9a28157dd3..5509f9b66bfd 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -590,11 +590,6 @@ struct vmw_private {
struct mutex cmdbuf_mutex;
struct mutex binding_mutex;
- /**
-* Operating mode.
-*/
-
- bool stealth;
bool enable_fb;
spinlock_t svga_lock;
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/8] Misc cleanups and fixes for vmwgfx
I've been off in December and just now I finally rebased those on top
drm-misc-next. I'd like to move our developlement to drm-misc so
getting commit rights to drm-misc for both me and Roland would be great
("zack" and "sroland" accounts on fdo).
Roland Scheidegger (1):
drm/vmwgfx: add Zack Rusin as maintainer
Zack Rusin (7):
drm/vmwgfx: Remove stealth mode
drm/vmwgfx: Switch to a managed drm device
drm/vmwgfx: Cleanup fifo mmio handling
drm/vmwgfx: Cleanup pci resource allocation
drm/vmwgfx: Remove the throttling code
drm/vmwgfx: Cleanup the cmd/fifo split
drm/vmwgfx: Fix display register usage for some older configs
MAINTAINERS | 1 +
drivers/gpu/drm/vmwgfx/Makefile | 6 +-
drivers/gpu/drm/vmwgfx/vmwgfx_binding.c | 52 ++---
.../vmwgfx/{vmwgfx_fifo.c => vmwgfx_cmd.c}| 127 +-
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c| 22 +-
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 40 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 12 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 216 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 92 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 22 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fb.c| 12 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 28 +--
drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c | 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 15 +-
drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 10 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 74 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 9 +-
drivers/gpu/drm/vmwgfx/vmwgfx_marker.c| 155 -
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 16 +-
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 28 +--
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 24 +-
drivers/gpu/drm/vmwgfx/vmwgfx_so.c| 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 32 +--
drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c | 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 40 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 6 +-
28 files changed, 431 insertions(+), 644 deletions(-)
rename drivers/gpu/drm/vmwgfx/{vmwgfx_fifo.c => vmwgfx_cmd.c} (82%)
delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_marker.c
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/ttm: unexport ttm_pool_init/fini
Drivers are not supposed to use this directly any more. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_pool.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c index c81e6eb72da1..9089a047cb51 100644 --- a/drivers/gpu/drm/ttm/ttm_pool.c +++ b/drivers/gpu/drm/ttm/ttm_pool.c @@ -526,7 +526,6 @@ void ttm_pool_init(struct ttm_pool *pool, struct device *dev, pool, i, j); } } -EXPORT_SYMBOL(ttm_pool_init); /** * ttm_pool_fini - Cleanup a pool @@ -546,7 +545,6 @@ void ttm_pool_fini(struct ttm_pool *pool) ttm_pool_type_fini(&pool->caching[i].orders[j]); } } -EXPORT_SYMBOL(ttm_pool_fini); /* As long as pages are available make sure to release at least one */ static unsigned long ttm_pool_shrinker_scan(struct shrinker *shrink, -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/radeon: stop re-init the TTM page pool
Drivers are not supposed to init the page pool directly any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index d4328ff57757..35b715f82ed8 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -729,9 +729,6 @@ int radeon_ttm_init(struct radeon_device *rdev)
}
rdev->mman.initialized = true;
- ttm_pool_init(&rdev->mman.bdev.pool, rdev->dev, rdev->need_swiotlb,
- dma_addressing_limited(&rdev->pdev->dev));
-
r = radeon_ttm_init_vram(rdev);
if (r) {
DRM_ERROR("Failed initializing VRAM heap.\n");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Remove pinned bos from LRU in ttm_bo_move_to_lru_tail() v2
Am 05.01.21 um 19:12 schrieb Lyude Paul:
Reviewed-by: Lyude Paul
Guessing it's fine if I push this with your sob and review added?
Works for me, just take care that you pick the right branch.
I always seem to push my stuff into the wrong one.
Christian.
On Tue, 2021-01-05 at 12:45 +0100, Christian König wrote:
From: Lyude Paul
Recently a regression was introduced which caused TTM's buffer eviction to
attempt to evict already-pinned BOs, causing issues with buffer eviction
under memory pressure along with suspend/resume:
nouveau :1f:00.0: DRM: evicting buffers...
nouveau :1f:00.0: DRM: Moving pinned object c428c3ff!
nouveau :1f:00.0: fifo: fault 00 [READ] at 0020 engine 04
[BAR1] client 07 [HUB/HOST_CPU] reason 02 [PTE] on channel -1 [00ffeaa000
unknown]
nouveau :1f:00.0: fifo: DROPPED_MMU_FAULT 1000
nouveau :1f:00.0: fifo: fault 01 [WRITE] at 0002 engine
0c [HOST6] client 07 [HUB/HOST_CPU] reason 02 [PTE] on channel 1
[00ffb28000 DRM]
nouveau :1f:00.0: fifo: channel 1: killed
nouveau :1f:00.0: fifo: runlist 0: scheduled for recovery
[TTM] Buffer eviction failed
nouveau :1f:00.0: DRM: waiting for kernel channels to go idle...
nouveau :1f:00.0: DRM: failed to idle channel 1 [DRM]
nouveau :1f:00.0: DRM: resuming display...
After some bisection and investigation, it appears this resulted from the
recent changes to ttm_bo_move_to_lru_tail(). Previously when a buffer was
pinned, the buffer would be removed from the LRU once ttm_bo_unreserve
to maintain the LRU list when pinning or unpinning BOs. However, since:
commit 3d1a88e1051f ("drm/ttm: cleanup LRU handling further")
We've been exiting from ttm_bo_move_to_lru_tail() at the very beginning of
the function if the bo we're looking at is pinned, resulting in the pinned
BO never getting removed from the lru and as a result - causing issues when
it eventually becomes time for eviction.
So, let's fix this by calling ttm_bo_del_from_lru() from
ttm_bo_move_to_lru_tail() in the event that we're dealing with a pinned
buffer.
v2 (chk): reduce to only the fixing one liner since we always want to
call the callback whenever we would move on the LRU.
Signed-off-by: Lyude Paul
Fixes: 3d1a88e1051f ("drm/ttm: cleanup LRU handling further")
Cc: Christian König
Cc: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 31e8b3da5563..b65f4b12f986 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -138,8 +138,10 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object
*bo,
dma_resv_assert_held(bo->base.resv);
- if (bo->pin_count)
+ if (bo->pin_count) {
+ ttm_bo_del_from_lru(bo);
return;
+ }
man = ttm_manager_type(bdev, mem->mem_type);
list_move_tail(&bo->lru, &man->lru[bo->priority]);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Remove pinned bos from LRU in ttm_bo_move_to_lru_tail() v2
Reviewed-by: Lyude Paul
Guessing it's fine if I push this with your sob and review added?
On Tue, 2021-01-05 at 12:45 +0100, Christian König wrote:
> From: Lyude Paul
>
> Recently a regression was introduced which caused TTM's buffer eviction to
> attempt to evict already-pinned BOs, causing issues with buffer eviction
> under memory pressure along with suspend/resume:
>
> nouveau :1f:00.0: DRM: evicting buffers...
> nouveau :1f:00.0: DRM: Moving pinned object c428c3ff!
> nouveau :1f:00.0: fifo: fault 00 [READ] at 0020 engine 04
> [BAR1] client 07 [HUB/HOST_CPU] reason 02 [PTE] on channel -1 [00ffeaa000
> unknown]
> nouveau :1f:00.0: fifo: DROPPED_MMU_FAULT 1000
> nouveau :1f:00.0: fifo: fault 01 [WRITE] at 0002 engine
> 0c [HOST6] client 07 [HUB/HOST_CPU] reason 02 [PTE] on channel 1
> [00ffb28000 DRM]
> nouveau :1f:00.0: fifo: channel 1: killed
> nouveau :1f:00.0: fifo: runlist 0: scheduled for recovery
> [TTM] Buffer eviction failed
> nouveau :1f:00.0: DRM: waiting for kernel channels to go idle...
> nouveau :1f:00.0: DRM: failed to idle channel 1 [DRM]
> nouveau :1f:00.0: DRM: resuming display...
>
> After some bisection and investigation, it appears this resulted from the
> recent changes to ttm_bo_move_to_lru_tail(). Previously when a buffer was
> pinned, the buffer would be removed from the LRU once ttm_bo_unreserve
> to maintain the LRU list when pinning or unpinning BOs. However, since:
>
> commit 3d1a88e1051f ("drm/ttm: cleanup LRU handling further")
>
> We've been exiting from ttm_bo_move_to_lru_tail() at the very beginning of
> the function if the bo we're looking at is pinned, resulting in the pinned
> BO never getting removed from the lru and as a result - causing issues when
> it eventually becomes time for eviction.
>
> So, let's fix this by calling ttm_bo_del_from_lru() from
> ttm_bo_move_to_lru_tail() in the event that we're dealing with a pinned
> buffer.
>
> v2 (chk): reduce to only the fixing one liner since we always want to
> call the callback whenever we would move on the LRU.
>
> Signed-off-by: Lyude Paul
> Fixes: 3d1a88e1051f ("drm/ttm: cleanup LRU handling further")
> Cc: Christian König
> Cc: Dave Airlie
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 31e8b3da5563..b65f4b12f986 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -138,8 +138,10 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object
> *bo,
>
> dma_resv_assert_held(bo->base.resv);
>
> - if (bo->pin_count)
> + if (bo->pin_count) {
> + ttm_bo_del_from_lru(bo);
> return;
> + }
>
> man = ttm_manager_type(bdev, mem->mem_type);
> list_move_tail(&bo->lru, &man->lru[bo->priority]);
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: Add missing array size constraints
On Tue, Jan 05, 2021 at 10:40:08AM -0700, Rob Herring wrote: > On Tue, Jan 05, 2021 at 02:04:14PM +0100, Greg Kroah-Hartman wrote: > > On Mon, Jan 04, 2021 at 04:02:53PM -0700, Rob Herring wrote: > > > DT properties which can have multiple entries need to specify what the > > > entries are and define how many entries there can be. In the case of > > > only a single entry, just 'maxItems: 1' is sufficient. > > > > > > Add the missing entry constraints. These were found with a modified > > > meta-schema. Unfortunately, there are a few cases where the size > > > constraints are not defined such as common bindings, so the meta-schema > > > can't be part of the normal checks. > > > > > > Cc: Jens Axboe > > > Cc: Stephen Boyd > > > Cc: Thierry Reding > > > Cc: MyungJoo Ham > > > Cc: Chanwoo Choi > > > Cc: Linus Walleij > > > Cc: Bartosz Golaszewski > > > Cc: Jonathan Cameron > > > Cc: Dmitry Torokhov > > > Cc: Thomas Gleixner > > > Cc: Marc Zyngier > > > Cc: Mauro Carvalho Chehab > > > Cc: Chen-Yu Tsai > > > Cc: Ulf Hansson > > > Cc: "David S. Miller" > > > Cc: Jakub Kicinski > > > Cc: Sebastian Reichel > > > Cc: Ohad Ben-Cohen > > > Cc: Bjorn Andersson > > > Cc: Greg Kroah-Hartman > > > Signed-off-by: Rob Herring > > > > > > > > > diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml > > > b/Documentation/devicetree/bindings/usb/generic-ehci.yaml > > > index 247ef00381ea..f76b25f7fc7a 100644 > > > --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml > > > +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml > > > @@ -83,6 +83,7 @@ properties: > > >Phandle of a companion. > > > > > >phys: > > > +maxItems: 1 > > > description: PHY specifier for the USB PHY > > > > > >phy-names: > > > diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml > > > b/Documentation/devicetree/bindings/usb/generic-ohci.yaml > > > index 2178bcc401bc..8e2bd61f2075 100644 > > > --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml > > > +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml > > > @@ -71,6 +71,7 @@ properties: > > >Overrides the detected port count > > > > > >phys: > > > +maxItems: 1 > > > description: PHY specifier for the USB PHY > > > > > >phy-names: > > > diff --git a/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > > > b/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > > > index 678396eeeb78..f506225a4d57 100644 > > > --- a/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > > > +++ b/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > > > @@ -40,7 +40,7 @@ properties: > > >- const: mc > > > > > >phys: > > > -description: PHY specifier for the USB PHY > > > +maxItems: 1 > > > > > >usb-role-switch: > > > type: boolean > > > > Any reason you dropped the description for this entry, but not the other > > ones above? > > No, I should have dropped those too. I dropped cases of genericish > descriptions on common properties. There's nothing specific to this > binding here really. > > > > > > diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > > > b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > > > index 388245b91a55..adce36e48bc9 100644 > > > --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > > > +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > > > @@ -15,13 +15,14 @@ properties: > > >- const: ti,j721e-usb > > > > > >reg: > > > -description: module registers > > > +maxItems: 1 > > > > > >power-domains: > > > description: > > >PM domain provider node and an args specifier containing > > >the USB device id value. See, > > >Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt > > > +maxItems: 1 > > > > > >clocks: > > > description: Clock phandles to usb2_refclk and lpm_clk > > > > Same here, why remove the description? > > Really, the question is why keep 'description' on power-domains. Perhaps > there's a little value in the reference to sci-pm-domain.txt, so I left > it. Ok, if you are fine with this, that's ok with me, just didn't look very consistent :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211043] amdgpu: Mouse cursor freeze of external mouse after a while (after kernel crash?) (KDE Plasma)
https://bugzilla.kernel.org/show_bug.cgi?id=211043 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your full dmesg output. Is this specific to a particular application? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] PCI: add a REBAR size quirk for Sapphire RX 5600 XT Pulse.
Am 05.01.21 um 17:11 schrieb Ilia Mirkin: On Tue, Jan 5, 2021 at 8:44 AM Christian König wrote: Otherwise the CPU can't fully access the BAR. Signed-off-by: Christian König --- drivers/pci/pci.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 16216186b51c..b66e4703c214 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3577,7 +3577,14 @@ u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar) return 0; pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap); - return (cap & PCI_REBAR_CAP_SIZES) >> 4; + cap = (cap & PCI_REBAR_CAP_SIZES) >> 4; + + /* Sapphire RX 5600 XT Pulse has an invalid cap dword for BAR 0 */ + if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x731f && + bar == 0 && cap == 0x700) + cap == 0x7f00; Perhaps you meant cap = 0x7f00? Ups, indeed! Thanks for pointing that out. Christian. + + return cap; } EXPORT_SYMBOL(pci_rebar_get_possible_sizes); -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: Add missing array size constraints
On Tue, Jan 05, 2021 at 02:04:14PM +0100, Greg Kroah-Hartman wrote: > On Mon, Jan 04, 2021 at 04:02:53PM -0700, Rob Herring wrote: > > DT properties which can have multiple entries need to specify what the > > entries are and define how many entries there can be. In the case of > > only a single entry, just 'maxItems: 1' is sufficient. > > > > Add the missing entry constraints. These were found with a modified > > meta-schema. Unfortunately, there are a few cases where the size > > constraints are not defined such as common bindings, so the meta-schema > > can't be part of the normal checks. > > > > Cc: Jens Axboe > > Cc: Stephen Boyd > > Cc: Thierry Reding > > Cc: MyungJoo Ham > > Cc: Chanwoo Choi > > Cc: Linus Walleij > > Cc: Bartosz Golaszewski > > Cc: Jonathan Cameron > > Cc: Dmitry Torokhov > > Cc: Thomas Gleixner > > Cc: Marc Zyngier > > Cc: Mauro Carvalho Chehab > > Cc: Chen-Yu Tsai > > Cc: Ulf Hansson > > Cc: "David S. Miller" > > Cc: Jakub Kicinski > > Cc: Sebastian Reichel > > Cc: Ohad Ben-Cohen > > Cc: Bjorn Andersson > > Cc: Greg Kroah-Hartman > > Signed-off-by: Rob Herring > > > > > diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml > > b/Documentation/devicetree/bindings/usb/generic-ehci.yaml > > index 247ef00381ea..f76b25f7fc7a 100644 > > --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml > > +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml > > @@ -83,6 +83,7 @@ properties: > >Phandle of a companion. > > > >phys: > > +maxItems: 1 > > description: PHY specifier for the USB PHY > > > >phy-names: > > diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml > > b/Documentation/devicetree/bindings/usb/generic-ohci.yaml > > index 2178bcc401bc..8e2bd61f2075 100644 > > --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml > > +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml > > @@ -71,6 +71,7 @@ properties: > >Overrides the detected port count > > > >phys: > > +maxItems: 1 > > description: PHY specifier for the USB PHY > > > >phy-names: > > diff --git a/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > > b/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > > index 678396eeeb78..f506225a4d57 100644 > > --- a/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > > +++ b/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > > @@ -40,7 +40,7 @@ properties: > >- const: mc > > > >phys: > > -description: PHY specifier for the USB PHY > > +maxItems: 1 > > > >usb-role-switch: > > type: boolean > > Any reason you dropped the description for this entry, but not the other > ones above? No, I should have dropped those too. I dropped cases of genericish descriptions on common properties. There's nothing specific to this binding here really. > > > diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > > b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > > index 388245b91a55..adce36e48bc9 100644 > > --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > > +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > > @@ -15,13 +15,14 @@ properties: > >- const: ti,j721e-usb > > > >reg: > > -description: module registers > > +maxItems: 1 > > > >power-domains: > > description: > >PM domain provider node and an args specifier containing > >the USB device id value. See, > >Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt > > +maxItems: 1 > > > >clocks: > > description: Clock phandles to usb2_refclk and lpm_clk > > Same here, why remove the description? Really, the question is why keep 'description' on power-domains. Perhaps there's a little value in the reference to sci-pm-domain.txt, so I left it. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] PCI: add a REBAR size quirk for Sapphire RX 5600 XT Pulse.
Hi "Christian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on pci/next]
[also build test WARNING on linus/master v5.11-rc2 next-20210104]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/pci-export-pci_rebar_get_possible_sizes/20210105-224446
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: arm64-randconfig-r006-20210105 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
5c951623bc8965fa1e89660f2f5f4a2944e4981a)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://github.com/0day-ci/linux/commit/6838a45fc2394ec88455e1fb3998ac865a077168
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Christian-K-nig/pci-export-pci_rebar_get_possible_sizes/20210105-224446
git checkout 6838a45fc2394ec88455e1fb3998ac865a077168
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/pci/pci.c:3611:7: warning: equality comparison result unused
>> [-Wunused-comparison]
cap == 0x7f00;
^
drivers/pci/pci.c:3611:7: note: use '=' to turn this equality comparison
into an assignment
cap == 0x7f00;
^~
=
1 warning generated.
vim +3611 drivers/pci/pci.c
3587
3588 /**
3589 * pci_rebar_get_possible_sizes - get possible sizes for BAR
3590 * @pdev: PCI device
3591 * @bar: BAR to query
3592 *
3593 * Get the possible sizes of a resizable BAR as bitmask defined in the
spec
3594 * (bit 0=1MB, bit 19=512GB). Returns 0 if BAR isn't resizable.
3595 */
3596 u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar)
3597 {
3598 int pos;
3599 u32 cap;
3600
3601 pos = pci_rebar_find_pos(pdev, bar);
3602 if (pos < 0)
3603 return 0;
3604
3605 pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap);
3606 cap = (cap & PCI_REBAR_CAP_SIZES) >> 4;
3607
3608 /* Sapphire RX 5600 XT Pulse has an invalid cap dword for BAR 0
*/
3609 if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x731f
&&
3610 bar == 0 && cap == 0x700)
> 3611 cap == 0x7f00;
3612
3613 return cap;
3614 }
3615 EXPORT_SYMBOL(pci_rebar_get_possible_sizes);
3616
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/48] Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs
On Thu, Dec 17, 2020 at 09:05:50PM +0300, Dmitry Osipenko wrote: > Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces > power consumption and heating of the Tegra chips. Tegra SoC has multiple > hardware units which belong to a core power domain of the SoC and share > the core voltage. The voltage must be selected in accordance to a minimum > requirement of every core hardware unit. > > The minimum core voltage requirement depends on: > > 1. Clock enable state of a hardware unit. > 2. Clock frequency. > 3. Unit's internal idling/active state. > > This series is tested on Acer A500 (T20), AC100 (T20), Nexus 7 (T30), > Ouya (T30), TK1 (T124) and some others. I also added voltage scaling to > the Ventana (T20) and Cardhu (T30) boards which are tested by NVIDIA's CI > farm. Tegra30 is now couple degrees cooler on Nexus 7 and stays cool on > Ouya (instead of becoming burning hot) while system is idling. It should > be possible to improve this further by implementing a more advanced power > management features for the kernel drivers. > > The DVFS support is opt-in for all boards, meaning that older DTBs will > continue to work like they did it before this series. It should be possible > to easily add the core voltage scaling support for Tegra114+ SoCs based on > this grounding work later on, if anyone will want to implement it. The same comment as for your interconnect work: for sets touching multiple systems please mention the dependencies between patches in the cover letter. Not as a reply to such remark like I make here, but as a separate entry in the cover letter. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 3/5] memory: tegra124: Support interconnect framework
On Mon, Dec 28, 2020 at 06:49:18PM +0300, Dmitry Osipenko wrote: > Now Internal and External memory controllers are memory interconnection > providers. This allows us to use interconnect API for tuning of memory > configuration. EMC driver now supports OPPs and DVFS. > > Tested-by: Nicolas Chauvet > Acked-by: Georgi Djakov > Signed-off-by: Dmitry Osipenko > --- > drivers/memory/tegra/Kconfig| 1 + > drivers/memory/tegra/tegra124-emc.c | 320 +++- > drivers/memory/tegra/tegra124.c | 82 ++- > 3 files changed, 391 insertions(+), 12 deletions(-) Thanks, applied. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 2/5] memory: tegra124-emc: Continue probing if timings are missing in device-tree
On Mon, Dec 28, 2020 at 06:49:17PM +0300, Dmitry Osipenko wrote: > EMC driver will become mandatory after turning it into interconnect > provider because interconnect users, like display controller driver, will > fail to probe using newer device-trees that have interconnect properties. > Thus make EMC driver to probe even if timings are missing in device-tree. > > Tested-by: Nicolas Chauvet > Signed-off-by: Dmitry Osipenko > --- > drivers/memory/tegra/tegra124-emc.c | 26 +- > 1 file changed, 9 insertions(+), 17 deletions(-) Thanks, applied. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v12 1/5] memory: tegra124-emc: Make driver modular
On Mon, Dec 28, 2020 at 06:49:16PM +0300, Dmitry Osipenko wrote: > Add modularization support to the Tegra124 EMC driver, which now can be > compiled as a loadable kernel module. > > Note that EMC clock must be registered at clk-init time, otherwise PLLM > will be disabled as unused clock at boot time if EMC driver is compiled > as a module. Hence add a prepare/complete callbacks. similarly to what is > done for the Tegra20/30 EMC drivers. > > Tested-by: Nicolas Chauvet > Signed-off-by: Dmitry Osipenko > --- > drivers/clk/tegra/Kconfig| 3 ++ > drivers/clk/tegra/Makefile | 2 +- > drivers/clk/tegra/clk-tegra124-emc.c | 41 > drivers/clk/tegra/clk-tegra124.c | 26 -- > drivers/clk/tegra/clk.h | 18 > drivers/memory/tegra/Kconfig | 3 +- > drivers/memory/tegra/tegra124-emc.c | 31 ++--- > include/linux/clk/tegra.h| 8 ++ > include/soc/tegra/emc.h | 16 --- > 9 files changed, 106 insertions(+), 42 deletions(-) > delete mode 100644 include/soc/tegra/emc.h Thanks, applied. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amdgpu: Add check to prevenet IH overflow
Am 05.01.21 um 17:06 schrieb Defang Bo:
Similar to commit ("drm/amdgpu: fix IH overflow on Vega10 v2").
When an ring buffer overflow happens the appropriate bit is set in the WPTR
register which is also written back to memory. But clearing the bit in the
WPTR doesn't trigger another memory writeback.
So what can happen is that we end up processing the buffer overflow over and
over again because the bit is never cleared. Resulting in a random system
lockup because of an infinite loop in an interrupt handler.
Signed-off-by: Defang Bo
Reviewed-by: Christian König
Thanks for the help,
Christian.
---
Changes since v1:
- Modify the subject and replace the wrong register.
---
---
drivers/gpu/drm/amd/amdgpu/cz_ih.c | 39 +
drivers/gpu/drm/amd/amdgpu/iceland_ih.c | 36 +++---
drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 37 ---
3 files changed, 72 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/cz_ih.c
b/drivers/gpu/drm/amd/amdgpu/cz_ih.c
index 1dca0cabc326..65361afb21ab 100644
--- a/drivers/gpu/drm/amd/amdgpu/cz_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/cz_ih.c
@@ -190,22 +190,33 @@ static u32 cz_ih_get_wptr(struct amdgpu_device *adev,
struct amdgpu_ih_ring *ih)
{
u32 wptr, tmp;
-
+
wptr = le32_to_cpu(*ih->wptr_cpu);
- if (REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW)) {
- wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
- /* When a ring buffer overflow happen start parsing interrupt
-* from the last not overwritten vector (wptr + 16). Hopefully
-* this should allow us to catchup.
-*/
- dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
- wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
- ih->rptr = (wptr + 16) & ih->ptr_mask;
- tmp = RREG32(mmIH_RB_CNTL);
- tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
- WREG32(mmIH_RB_CNTL, tmp);
- }
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+ /* Double check that the overflow wasn't already cleared. */
+ wptr = RREG32(mmIH_RB_WPTR);
+
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+ wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
+
+ /* When a ring buffer overflow happen start parsing interrupt
+* from the last not overwritten vector (wptr + 16). Hopefully
+* this should allow us to catchup.
+*/
+ dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
+ wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
+ ih->rptr = (wptr + 16) & ih->ptr_mask;
+ tmp = RREG32(mmIH_RB_CNTL);
+ tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
+ WREG32(mmIH_RB_CNTL, tmp);
+
+
+out:
return (wptr & ih->ptr_mask);
}
diff --git a/drivers/gpu/drm/amd/amdgpu/iceland_ih.c b/drivers/gpu/drm/amd/amdgpu/iceland_ih.c
index a13dd9a51149..8e4dae8addb9 100644
--- a/drivers/gpu/drm/amd/amdgpu/iceland_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/iceland_ih.c
@@ -193,19 +193,29 @@ static u32 iceland_ih_get_wptr(struct amdgpu_device *adev,
wptr = le32_to_cpu(*ih->wptr_cpu);
- if (REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW)) {
- wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
- /* When a ring buffer overflow happen start parsing interrupt
-* from the last not overwritten vector (wptr + 16). Hopefully
-* this should allow us to catchup.
-*/
- dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
-wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
- ih->rptr = (wptr + 16) & ih->ptr_mask;
- tmp = RREG32(mmIH_RB_CNTL);
- tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
- WREG32(mmIH_RB_CNTL, tmp);
- }
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+ /* Double check that the overflow wasn't already cleared. */
+ wptr = RREG32(mmIH_RB_WPTR);
+
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+ wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
+ /* When a ring buffer overflow happen start parsing interrupt
+* from the last not overwritten vector (wptr + 16). Hopefully
+* this should allow us to catchup.
+*/
+ dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
+ wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
+ ih->rptr = (wptr + 16) & ih->ptr_mask;
+ tmp = RREG32(mmIH_RB_CNTL);
+ tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OV
Re: [PATCH 19/31] drm/panfrost: convert to use devm_pm_opp_* API
On 01/01/2021 16:54, Yangtao Li wrote:
Use devm_pm_opp_* API to simplify code, and remove opp_table
from panfrost_devfreq.
Signed-off-by: Yangtao Li
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 34 ++---
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 1 -
2 files changed, 10 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index f44d28fad085..c42fa9eb43b1 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -92,25 +92,26 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct thermal_cooling_device *cooling;
struct panfrost_devfreq *pfdevfreq = &pfdev->pfdevfreq;
- opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
+ opp_table = devm_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
pfdev->comp->num_supplies);
if (IS_ERR(opp_table)) {
ret = PTR_ERR(opp_table);
/* Continue if the optional regulator is missing */
if (ret != -ENODEV) {
DRM_DEV_ERROR(dev, "Couldn't set OPP regulators\n");
- goto err_fini;
+ return ret;
}
- } else {
- pfdevfreq->regulators_opp_table = opp_table;
}
- ret = dev_pm_opp_of_add_table(dev);
+ ret = devm_pm_opp_of_add_table(dev);
if (ret) {
+ if (!IS_ERR(opp_table))
+ devm_pm_opp_put_regulators(dev, opp_table);
+
/* Optional, continue without devfreq */
if (ret == -ENODEV)
ret = 0;
- goto err_fini;
+ return ret;
}
pfdevfreq->opp_of_table_added = true;
@@ -121,10 +122,8 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
cur_freq = clk_get_rate(pfdev->clock);
opp = devfreq_recommended_opp(dev, &cur_freq, 0);
- if (IS_ERR(opp)) {
- ret = PTR_ERR(opp);
- goto err_fini;
- }
+ if (IS_ERR(opp))
+ return PTR_ERR(opp);
panfrost_devfreq_profile.initial_freq = cur_freq;
dev_pm_opp_put(opp);
@@ -133,8 +132,7 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
if (IS_ERR(devfreq)) {
DRM_DEV_ERROR(dev, "Couldn't initialize GPU devfreq\n");
- ret = PTR_ERR(devfreq);
- goto err_fini;
+ return PTR_ERR(devfreq);
}
pfdevfreq->devfreq = devfreq;
@@ -145,10 +143,6 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
pfdevfreq->cooling = cooling;
return 0;
-
-err_fini:
- panfrost_devfreq_fini(pfdev);
- return ret;
}
void panfrost_devfreq_fini(struct panfrost_device *pfdev)
@@ -159,14 +153,6 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
devfreq_cooling_unregister(pfdevfreq->cooling);
pfdevfreq->cooling = NULL;
}
-
- if (pfdevfreq->opp_of_table_added) {
- dev_pm_opp_of_remove_table(&pfdev->pdev->dev);
- pfdevfreq->opp_of_table_added = false;
- }
-
- dev_pm_opp_put_regulators(pfdevfreq->regulators_opp_table);
- pfdevfreq->regulators_opp_table = NULL;
}
void panfrost_devfreq_resume(struct panfrost_device *pfdev)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index db6ea48e21f9..a51854cc8c06 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -15,7 +15,6 @@ struct panfrost_device;
struct panfrost_devfreq {
struct devfreq *devfreq;
- struct opp_table *regulators_opp_table;
struct thermal_cooling_device *cooling;
bool opp_of_table_added;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"
On Tue, Jan 5, 2021 at 8:05 AM Will Deacon wrote: > > On Mon, Jan 04, 2021 at 11:27:24AM -0500, Alex Deucher wrote: > > On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel wrote: > > > > > > On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel wrote: > > > > > > > > On Wed, 16 Dec 2020 at 19:00, Alex Deucher > > > > wrote: > > > > > > > > > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel > > > > > wrote: > > > > > > > > > > > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa. > > > > > > > > > > > > Simply disabling -mgeneral-regs-only left and right is risky, given > > > > > > that > > > > > > the standard AArch64 ABI permits the use of FP/SIMD registers > > > > > > anywhere, > > > > > > and GCC is known to use SIMD registers for spilling, and may invent > > > > > > other uses of the FP/SIMD register file that have nothing to do > > > > > > with the > > > > > > floating point code in question. Note that putting > > > > > > kernel_neon_begin() > > > > > > and kernel_neon_end() around the code that does use FP is not > > > > > > sufficient > > > > > > here, the problem is in all the other code that may be emitted with > > > > > > references to SIMD registers in it. > > > > > > > > > > > > So the only way to do this properly is to put all floating point > > > > > > code in > > > > > > a separate compilation unit, and only compile that unit with > > > > > > -mgeneral-regs-only. But perhaps the use of floating point here is > > > > > > something that should be reconsidered entirely. > > > > > > > > > > > > Cc: Catalin Marinas > > > > > > Cc: Will Deacon > > > > > > Cc: Dave Martin > > > > > > Cc: Rob Herring > > > > > > Cc: Leo Li > > > > > > Cc: Alex Deucher > > > > > > Cc: "Christian König" > > > > > > Cc: David Airlie > > > > > > Cc: Daniel Vetter > > > > > > Cc: Daniel Kolesa > > > > > > Cc: amd-...@lists.freedesktop.org > > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > > Signed-off-by: Ard Biesheuvel > > > > > > > > > > Can rebase this on Linus' master branch? There were a number of new > > > > > asics added which copy pasted the ARM64 support. > > > > > > > > > > > > > Not sure what you are asking me here. Reverting commit c38d444e44badc5 > > > > on top of mainline is not going to fix the other code that was added. > > > > Or are you asking me to go and find the patches (how many?) that added > > > > new ASICs and fix them for arm64? > > > > > > > > Note that this code is critically broken, as it may corrupt user > > > > process state arbitrarily. So if new code was added that contains the > > > > same bug, it should be reverted so that the respective authors can fix > > > > it and resubmit. > > > > > > > > > > Is this simply about dropping the newly added references to > > > $(dml_rcflags) from the Makefile? Because that is quite trivial ... > > > > Yes, I was thinking something like the attached patch. > > > > Alex > > > From fbc93ca7d7739861ce63f6b483cf23d7cf1d69fb Mon Sep 17 00:00:00 2001 > > From: Alex Deucher > > Date: Mon, 4 Jan 2021 11:24:20 -0500 > > Subject: [PATCH] drm/amdgpu/display: drop DCN support for aarch64 > > > > From Ard: > > > > "Simply disabling -mgeneral-regs-only left and right is risky, given that > > the standard AArch64 ABI permits the use of FP/SIMD registers anywhere, > > and GCC is known to use SIMD registers for spilling, and may invent > > other uses of the FP/SIMD register file that have nothing to do with the > > floating point code in question. Note that putting kernel_neon_begin() > > and kernel_neon_end() around the code that does use FP is not sufficient > > here, the problem is in all the other code that may be emitted with > > references to SIMD registers in it. > > > > So the only way to do this properly is to put all floating point code in > > a separate compilation unit, and only compile that unit with > > -mgeneral-regs-only." > > > > Disable support until the code can be properly refactored to support this > > properly on aarch64. > > > > Reported-by: Ard Biesheuvel > > Signed-off-by: Alex Deucher > > --- > > drivers/gpu/drm/amd/display/Kconfig | 2 +- > > drivers/gpu/drm/amd/display/dc/calcs/Makefile | 4 > > .../gpu/drm/amd/display/dc/clk_mgr/Makefile | 21 --- > > drivers/gpu/drm/amd/display/dc/dcn10/Makefile | 7 --- > > .../drm/amd/display/dc/dcn10/dcn10_resource.c | 7 --- > > drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 4 > > drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 4 > > drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 5 - > > .../gpu/drm/amd/display/dc/dcn301/Makefile| 4 > > .../gpu/drm/amd/display/dc/dcn302/Makefile| 4 > > drivers/gpu/drm/amd/display/dc/dml/Makefile | 4 > > drivers/gpu/drm/amd/display/dc/dsc/Makefile | 4 > > drivers/gpu/drm/amd/display/dc/os_types.h | 4 > > 13 files changed, 1 insertion(+), 73 deletions(-) > > Acked-by: Will Deacon Applied. Thanks! Alex ___
Re: [PATCH 4/4] PCI: add a REBAR size quirk for Sapphire RX 5600 XT Pulse.
On Tue, Jan 5, 2021 at 8:44 AM Christian König wrote: > > Otherwise the CPU can't fully access the BAR. > > Signed-off-by: Christian König > --- > drivers/pci/pci.c | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index 16216186b51c..b66e4703c214 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -3577,7 +3577,14 @@ u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, > int bar) > return 0; > > pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap); > - return (cap & PCI_REBAR_CAP_SIZES) >> 4; > + cap = (cap & PCI_REBAR_CAP_SIZES) >> 4; > + > + /* Sapphire RX 5600 XT Pulse has an invalid cap dword for BAR 0 */ > + if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x731f && > + bar == 0 && cap == 0x700) > + cap == 0x7f00; Perhaps you meant cap = 0x7f00? > + > + return cap; > } > EXPORT_SYMBOL(pci_rebar_get_possible_sizes); > > -- > 2.25.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 5.11-rc1 TTM list corruption
Am 05.01.21 um 13:20 schrieb Huang Rui: On Tue, Jan 05, 2021 at 07:43:51PM +0800, Borislav Petkov wrote: On Tue, Jan 05, 2021 at 07:08:52PM +0800, Huang Rui wrote: Ah, this asic is a bit old and still use radeon driver. So we didn't reproduce it on amdgpu driver. I don't have such the old asic in my hand. May we know whether this issue can be duplicated after SI which is used amdgpu module (not sure whether you have recent APU or GPU)? The latest I have (I think it is the latest) is: [1.826102] [drm] initializing kernel modesetting (RENOIR 0x1002:0x1636 0x17AA:0x5099 0xD1). and so far that hasn't triggered it. Which makes sense because that thing uses amdgpu: [1.810260] [drm] amdgpu kernel modesetting enabled. Yes! Renoir is late enough for amdgpu kernel module. :-) Please let us know if you still encounter the issue. Thanks for the hints guys. You need a rather specific configuration, but I can reproduce this now. Let's see what the problem is here. Thanks, Christian. Thanks, Ray ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 4/4] NOTFORMERGE: drm/logicvc: Add plane colorkey support
Hi, On Wed 23 Dec 20, 18:31, Ilia Mirkin wrote: > FWIW this is something I added, hoping it was going to get used at > some point, but I never followed up with support in xf86-video-nouveau > for Xv. At this point, I'm not sure I ever will. I encoded the > "enabled" part into the value with a high bit (1<<24) -- not sure that > was such a great idea. All NVIDIA hardware supports colorkey (and not > actual alpha, until the very latest GPUs - Volta/Turing families), > although my implementation only covers the pre-G80 series (i.e. DX9 > and earlier GPUs - pre-2008). Should a determination of usefulness be > reached, it would be easy to implement on the remainder though. Interesting to know! Regarding a generic colorkey property, there was a discussion under thread: drm: Add generic colorkey properties for display planes and the latest proposal (RFC v4) can be found here: https://patchwork.ozlabs.org/project/linux-tegra/patch/20180807172202.1961-2-dig...@gmail.com/ It looks like this was much more complex than anticipated and the series was more or less abandonned. I didn't feel like picking it up in my logicvc series so I kept the colorkey patch as not for merge. If someone's up for picking the proposal and continuing the discussion, I could provide insight on how it would fit with logicvc though! Cheers, Paul > On Wed, Dec 23, 2020 at 5:20 PM Simon Ser wrote: > > > > nouveau already has something for colorkey: > > https://drmdb.emersion.fr/properties/4008636142/colorkey > > > > I know this is marked "not for merge", but it would be nice to discuss > > with them and come up with a standardized property. -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3] drm/vkms: Decouple config data for configfs
Currently, data for the device instance is held by vkms_device.
Add a separate type, vkms_config to contain configuration details
for the device and various modes to be later used by configfs.
This config data stays constant once the device is created.
Accordingly, add vkms_create and vkms_destroy to initialize/destroy
device through configfs. Currently, they are being called from vkms_init
and vkms_exit, but will be evoked from configfs later on. When configfs
is added, device configuration will be tracked by configfs and only vkms
device lifetime will be handled by vkms_init and vkms_exit functions.
Modify usage of enable_cursor feature to reflect the changes in
relevant files.
Add enable_writeback_connector feature to vkms_config type.
Co-developed-by: Daniel Vetter
Signed-off-by: Daniel Vetter
Signed-off-by: Sumera Priyadarsini
---
Changes in v2:
- add Co-developed-by tag
Changes in v3:
- correct usage of Co-developed by tag(Melissa)
- add enable_writeback_feature(Melissa)
- modify commit message(Melissa)
---
drivers/gpu/drm/vkms/vkms_drv.c| 45 --
drivers/gpu/drm/vkms/vkms_drv.h| 12 ++--
drivers/gpu/drm/vkms/vkms_output.c | 13 +
3 files changed, 54 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index aef29393b811..fab964900dce 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -34,12 +34,16 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-static struct vkms_device *vkms_device;
+static struct vkms_config *default_config;
-bool enable_cursor = true;
+static bool enable_cursor = true;
module_param_named(enable_cursor, enable_cursor, bool, 0444);
MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
+static bool enable_writeback_connector = true;
+module_param_named(enable_writeback_connector, enable_writeback_connector,
bool, 0444);
+MODULE_PARM_DESC(enable_writeback_connector, "Enable/Disable writeback
connector support");
+
DEFINE_DRM_GEM_FOPS(vkms_driver_fops);
static void vkms_release(struct drm_device *dev)
@@ -122,10 +126,11 @@ static int vkms_modeset_init(struct vkms_device *vkmsdev)
return vkms_output_init(vkmsdev, 0);
}
-static int __init vkms_init(void)
+static int vkms_create(struct vkms_config *config)
{
int ret;
struct platform_device *pdev;
+ struct vkms_device *vkms_device;
pdev = platform_device_register_simple(DRIVER_NAME, -1, NULL, 0);
if (IS_ERR(pdev))
@@ -143,6 +148,8 @@ static int __init vkms_init(void)
goto out_devres;
}
vkms_device->platform = pdev;
+ vkms_device->config = config;
+ config->dev = vkms_device;
ret = dma_coerce_mask_and_coherent(vkms_device->drm.dev,
DMA_BIT_MASK(64));
@@ -179,21 +186,43 @@ static int __init vkms_init(void)
return ret;
}
-static void __exit vkms_exit(void)
+static int __init vkms_init(void)
+{
+ struct vkms_config *config = kmalloc(sizeof(*config), GFP_KERNEL);
+
+ default_config = config;
+
+ config->cursor = enable_cursor;
+ config->writeback = enable_writeback_connector;
+
+ return vkms_create(config);
+}
+
+static void vkms_destroy(struct vkms_config *config)
{
struct platform_device *pdev;
- if (!vkms_device) {
+ if (!config->dev) {
DRM_INFO("vkms_device is NULL.\n");
return;
}
- pdev = vkms_device->platform;
+ pdev = config->dev->platform;
- drm_dev_unregister(&vkms_device->drm);
- drm_atomic_helper_shutdown(&vkms_device->drm);
+ drm_dev_unregister(&config->dev->drm);
+ drm_atomic_helper_shutdown(&config->dev->drm);
devres_release_group(&pdev->dev, NULL);
platform_device_unregister(pdev);
+
+ config->dev = NULL;
+}
+
+static void __exit vkms_exit(void)
+{
+ if (default_config->dev)
+ vkms_destroy(default_config);
+
+ kfree(default_config);
}
module_init(vkms_init);
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 5ed91ff08cb3..caa1fafb6ca7 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -19,8 +19,6 @@
#define XRES_MAX 8192
#define YRES_MAX 8192
-extern bool enable_cursor;
-
struct vkms_composer {
struct drm_framebuffer fb;
struct drm_rect src, dst;
@@ -82,10 +80,18 @@ struct vkms_output {
spinlock_t composer_lock;
};
+struct vkms_device;
+struct vkms_config {
+ bool writeback;
+ bool cursor;
+ /* only set when instantiated */
+ struct vkms_device *dev;
+};
struct vkms_device {
struct drm_device drm;
struct platform_device *platform;
struct vkms_output output;
+ const struct vkms_config *config;
};
#define drm_crtc_to_vkms_output(target) \
@@ -123,4 +129
Re: [PATCH v2 2/2] drm/bridge: anx7625: add MIPI DPI input feature support
On Thu, Dec 31, 2020 at 10:22:36AM +0800, Xin Ji wrote:
> static int anx7625_read_ctrl_status_p0(struct anx7625_data *ctx)
> {
> return anx7625_reg_read(ctx, ctx->i2c.rx_p0_client, AP_AUX_CTRL_STATUS);
> @@ -189,10 +203,64 @@ static int wait_aux_op_finish(struct anx7625_data *ctx)
> AP_AUX_CTRL_STATUS);
> if (val < 0 || (val & 0x0F)) {
> DRM_DEV_ERROR(dev, "aux status %02x\n", val);
> - val = -EIO;
> + return -EIO;
> }
>
> - return val;
> + return 0;
This s/val/0/ change seems like a bug fix. Could you please send that
as a separate patch at the start of the patch set?
> +}
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209987] Memory leak in amdgpu_dm_update_connector_after_detect
https://bugzilla.kernel.org/show_bug.cgi?id=209987 Oleksandr Natalenko (oleksa...@natalenko.name) changed: What|Removed |Added CC||oleksa...@natalenko.name --- Comment #9 from Oleksandr Natalenko (oleksa...@natalenko.name) --- This change caused a regression that leads to inability to light up the display after powering it off. See: * https://lore.kernel.org/lkml/e5d9703f-42a4-f154-cf13-55a3eba10...@tomt.net/ * https://bugzilla.kernel.org/show_bug.cgi?id=211033 * https://bugs.archlinux.org/task/69202 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] PCI: add a REBAR size quirk for Sapphire RX 5600 XT Pulse.
Otherwise the CPU can't fully access the BAR. Signed-off-by: Christian König --- drivers/pci/pci.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 16216186b51c..b66e4703c214 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3577,7 +3577,14 @@ u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar) return 0; pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap); - return (cap & PCI_REBAR_CAP_SIZES) >> 4; + cap = (cap & PCI_REBAR_CAP_SIZES) >> 4; + + /* Sapphire RX 5600 XT Pulse has an invalid cap dword for BAR 0 */ + if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x731f && + bar == 0 && cap == 0x700) + cap == 0x7f00; + + return cap; } EXPORT_SYMBOL(pci_rebar_get_possible_sizes); -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] amdgpu: resize BAR0 to the maximum available size, even if it doesn't cover VRAM (v6)
From: Darren Salt
This allows BAR0 resizing to be done for cards which don't advertise support
for a size large enough to cover the VRAM but which do advertise at least
one size larger than the default. For example, my RX 5600 XT, which
advertises 256MB, 512MB and 1GB.
[v6] (chk) Reduce to only the necessary functionality
[v5] Drop the retry loop…
[v4] Use bit ops to find sizes to try.
[v3] Don't use pci_rebar_get_current_size().
[v2] Rewritten to use PCI helper functions; some extra log text.
Signed-off-by: Darren Salt
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 70acd673e3f2..da78746174f5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1089,7 +1089,7 @@ void amdgpu_device_wb_free(struct amdgpu_device *adev,
u32 wb)
*/
int amdgpu_device_resize_fb_bar(struct amdgpu_device *adev)
{
- u32 rbar_size = pci_rebar_bytes_to_size(adev->gmc.real_vram_size);
+ int rbar_size = pci_rebar_bytes_to_size(adev->gmc.real_vram_size);
struct pci_bus *root;
struct resource *res;
unsigned i;
@@ -1120,6 +1120,10 @@ int amdgpu_device_resize_fb_bar(struct amdgpu_device
*adev)
if (!res)
return 0;
+ /* Limit the BAR size to what is available */
+ rbar_size = min(fls(pci_rebar_get_possible_sizes(adev->pdev, 0)) - 1,
+ rbar_size);
+
/* Disable memory decoding while we change the BAR addresses and size */
pci_read_config_word(adev->pdev, PCI_COMMAND, &cmd);
pci_write_config_word(adev->pdev, PCI_COMMAND,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] pci: add BAR bytes->size helper & expose size->bytes helper v2
From: Darren Salt
This is to assist driver modules which do BAR resizing.
v2 (chk): Use ilog2 and make the new funtion extra defensive.
Also use the new function on the two existing ocassions.
Signed-off-by: Darren Salt
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +--
drivers/pci/pci.c | 2 +-
drivers/pci/pci.h | 4
include/linux/pci.h| 12
4 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index dce0e66b2364..70acd673e3f2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1089,8 +1089,7 @@ void amdgpu_device_wb_free(struct amdgpu_device *adev,
u32 wb)
*/
int amdgpu_device_resize_fb_bar(struct amdgpu_device *adev)
{
- u64 space_needed = roundup_pow_of_two(adev->gmc.real_vram_size);
- u32 rbar_size = order_base_2(((space_needed >> 20) | 1)) - 1;
+ u32 rbar_size = pci_rebar_bytes_to_size(adev->gmc.real_vram_size);
struct pci_bus *root;
struct resource *res;
unsigned i;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index ef80ed451415..16216186b51c 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1648,7 +1648,7 @@ static void pci_restore_rebar_state(struct pci_dev *pdev)
pci_read_config_dword(pdev, pos + PCI_REBAR_CTRL, &ctrl);
bar_idx = ctrl & PCI_REBAR_CTRL_BAR_IDX;
res = pdev->resource + bar_idx;
- size = ilog2(resource_size(res)) - 20;
+ size = pci_rebar_bytes_to_size(resource_size(res));
ctrl &= ~PCI_REBAR_CTRL_BAR_SIZE;
ctrl |= size << PCI_REBAR_CTRL_BAR_SHIFT;
pci_write_config_dword(pdev, pos + PCI_REBAR_CTRL, ctrl);
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 640ae7d74fc3..0fa31ff3d4e4 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -610,10 +610,6 @@ int acpi_get_rc_resources(struct device *dev, const char
*hid, u16 segment,
int pci_rebar_get_current_size(struct pci_dev *pdev, int bar);
int pci_rebar_set_size(struct pci_dev *pdev, int bar, int size);
-static inline u64 pci_rebar_size_to_bytes(int size)
-{
- return 1ULL << (size + 20);
-}
struct device_node;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 040cfad9..673606f871b7 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1226,6 +1226,18 @@ void pci_update_resource(struct pci_dev *dev, int resno);
int __must_check pci_assign_resource(struct pci_dev *dev, int i);
int __must_check pci_reassign_resource(struct pci_dev *dev, int i,
resource_size_t add_size, resource_size_t align);
void pci_release_resource(struct pci_dev *dev, int resno);
+
+static __always_inline int pci_rebar_bytes_to_size(u64 bytes)
+{
+ bytes = roundup_pow_of_two(bytes);
+ return max(ilog2(bytes), 20) - 20;
+}
+
+static __always_inline u64 pci_rebar_size_to_bytes(int size)
+{
+ return 1ULL << (size + 20);
+}
+
u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar);
int __must_check pci_resize_resource(struct pci_dev *dev, int i, int size);
int pci_select_bars(struct pci_dev *dev, unsigned long flags);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] pci: export pci_rebar_get_possible_sizes
From: Darren Salt This is to assist driver modules which do BAR resizing. Signed-off-by: Darren Salt --- drivers/pci/pci.c | 1 + drivers/pci/pci.h | 1 - include/linux/pci.h | 1 + 3 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index e578d34095e9..ef80ed451415 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -3579,6 +3579,7 @@ u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar) pci_read_config_dword(pdev, pos + PCI_REBAR_CAP, &cap); return (cap & PCI_REBAR_CAP_SIZES) >> 4; } +EXPORT_SYMBOL(pci_rebar_get_possible_sizes); /** * pci_rebar_get_current_size - get the current size of a BAR diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index f86cae9aa1f4..640ae7d74fc3 100644 --- a/drivers/pci/pci.h +++ b/drivers/pci/pci.h @@ -608,7 +608,6 @@ int acpi_get_rc_resources(struct device *dev, const char *hid, u16 segment, struct resource *res); #endif -u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar); int pci_rebar_get_current_size(struct pci_dev *pdev, int bar); int pci_rebar_set_size(struct pci_dev *pdev, int bar, int size); static inline u64 pci_rebar_size_to_bytes(int size) diff --git a/include/linux/pci.h b/include/linux/pci.h index 22207a79762c..040cfad9 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -1226,6 +1226,7 @@ void pci_update_resource(struct pci_dev *dev, int resno); int __must_check pci_assign_resource(struct pci_dev *dev, int i); int __must_check pci_reassign_resource(struct pci_dev *dev, int i, resource_size_t add_size, resource_size_t align); void pci_release_resource(struct pci_dev *dev, int resno); +u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar); int __must_check pci_resize_resource(struct pci_dev *dev, int i, int size); int pci_select_bars(struct pci_dev *dev, unsigned long flags); bool pci_device_is_present(struct pci_dev *pdev); -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
A PCI quirk for resizeable BAR 0 on Navi10
Hi Bjorn, Darren stumbled over an AMD GPU with nonsense in it's resizeable BAR capability dword. This is most likely fixable with a VBIOS update, but we already sold quite a bunch of those boards with the problem. The driver still loads without this, but the performance isn't the best. Do you have any objection to merge this through the drm branch? Thanks in advance, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/display: Revert "add DCN support for aarch64"
On Mon, Jan 04, 2021 at 11:27:24AM -0500, Alex Deucher wrote: > On Tue, Dec 29, 2020 at 8:17 AM Ard Biesheuvel wrote: > > > > On Wed, 16 Dec 2020 at 23:26, Ard Biesheuvel wrote: > > > > > > On Wed, 16 Dec 2020 at 19:00, Alex Deucher wrote: > > > > > > > > On Mon, Dec 14, 2020 at 12:53 PM Ard Biesheuvel wrote: > > > > > > > > > > This reverts commit c38d444e44badc557cf29fdfdfb823604890ccfa. > > > > > > > > > > Simply disabling -mgeneral-regs-only left and right is risky, given > > > > > that > > > > > the standard AArch64 ABI permits the use of FP/SIMD registers > > > > > anywhere, > > > > > and GCC is known to use SIMD registers for spilling, and may invent > > > > > other uses of the FP/SIMD register file that have nothing to do with > > > > > the > > > > > floating point code in question. Note that putting kernel_neon_begin() > > > > > and kernel_neon_end() around the code that does use FP is not > > > > > sufficient > > > > > here, the problem is in all the other code that may be emitted with > > > > > references to SIMD registers in it. > > > > > > > > > > So the only way to do this properly is to put all floating point code > > > > > in > > > > > a separate compilation unit, and only compile that unit with > > > > > -mgeneral-regs-only. But perhaps the use of floating point here is > > > > > something that should be reconsidered entirely. > > > > > > > > > > Cc: Catalin Marinas > > > > > Cc: Will Deacon > > > > > Cc: Dave Martin > > > > > Cc: Rob Herring > > > > > Cc: Leo Li > > > > > Cc: Alex Deucher > > > > > Cc: "Christian König" > > > > > Cc: David Airlie > > > > > Cc: Daniel Vetter > > > > > Cc: Daniel Kolesa > > > > > Cc: amd-...@lists.freedesktop.org > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > Signed-off-by: Ard Biesheuvel > > > > > > > > Can rebase this on Linus' master branch? There were a number of new > > > > asics added which copy pasted the ARM64 support. > > > > > > > > > > Not sure what you are asking me here. Reverting commit c38d444e44badc5 > > > on top of mainline is not going to fix the other code that was added. > > > Or are you asking me to go and find the patches (how many?) that added > > > new ASICs and fix them for arm64? > > > > > > Note that this code is critically broken, as it may corrupt user > > > process state arbitrarily. So if new code was added that contains the > > > same bug, it should be reverted so that the respective authors can fix > > > it and resubmit. > > > > > > > Is this simply about dropping the newly added references to > > $(dml_rcflags) from the Makefile? Because that is quite trivial ... > > Yes, I was thinking something like the attached patch. > > Alex > From fbc93ca7d7739861ce63f6b483cf23d7cf1d69fb Mon Sep 17 00:00:00 2001 > From: Alex Deucher > Date: Mon, 4 Jan 2021 11:24:20 -0500 > Subject: [PATCH] drm/amdgpu/display: drop DCN support for aarch64 > > From Ard: > > "Simply disabling -mgeneral-regs-only left and right is risky, given that > the standard AArch64 ABI permits the use of FP/SIMD registers anywhere, > and GCC is known to use SIMD registers for spilling, and may invent > other uses of the FP/SIMD register file that have nothing to do with the > floating point code in question. Note that putting kernel_neon_begin() > and kernel_neon_end() around the code that does use FP is not sufficient > here, the problem is in all the other code that may be emitted with > references to SIMD registers in it. > > So the only way to do this properly is to put all floating point code in > a separate compilation unit, and only compile that unit with > -mgeneral-regs-only." > > Disable support until the code can be properly refactored to support this > properly on aarch64. > > Reported-by: Ard Biesheuvel > Signed-off-by: Alex Deucher > --- > drivers/gpu/drm/amd/display/Kconfig | 2 +- > drivers/gpu/drm/amd/display/dc/calcs/Makefile | 4 > .../gpu/drm/amd/display/dc/clk_mgr/Makefile | 21 --- > drivers/gpu/drm/amd/display/dc/dcn10/Makefile | 7 --- > .../drm/amd/display/dc/dcn10/dcn10_resource.c | 7 --- > drivers/gpu/drm/amd/display/dc/dcn20/Makefile | 4 > drivers/gpu/drm/amd/display/dc/dcn21/Makefile | 4 > drivers/gpu/drm/amd/display/dc/dcn30/Makefile | 5 - > .../gpu/drm/amd/display/dc/dcn301/Makefile| 4 > .../gpu/drm/amd/display/dc/dcn302/Makefile| 4 > drivers/gpu/drm/amd/display/dc/dml/Makefile | 4 > drivers/gpu/drm/amd/display/dc/dsc/Makefile | 4 > drivers/gpu/drm/amd/display/dc/os_types.h | 4 > 13 files changed, 1 insertion(+), 73 deletions(-) Acked-by: Will Deacon Will ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: Add missing array size constraints
On Mon, Jan 04, 2021 at 04:02:53PM -0700, Rob Herring wrote: > DT properties which can have multiple entries need to specify what the > entries are and define how many entries there can be. In the case of > only a single entry, just 'maxItems: 1' is sufficient. > > Add the missing entry constraints. These were found with a modified > meta-schema. Unfortunately, there are a few cases where the size > constraints are not defined such as common bindings, so the meta-schema > can't be part of the normal checks. > > Cc: Jens Axboe > Cc: Stephen Boyd > Cc: Thierry Reding > Cc: MyungJoo Ham > Cc: Chanwoo Choi > Cc: Linus Walleij > Cc: Bartosz Golaszewski > Cc: Jonathan Cameron > Cc: Dmitry Torokhov > Cc: Thomas Gleixner > Cc: Marc Zyngier > Cc: Mauro Carvalho Chehab > Cc: Chen-Yu Tsai > Cc: Ulf Hansson > Cc: "David S. Miller" > Cc: Jakub Kicinski > Cc: Sebastian Reichel > Cc: Ohad Ben-Cohen > Cc: Bjorn Andersson > Cc: Greg Kroah-Hartman > Signed-off-by: Rob Herring > diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml > b/Documentation/devicetree/bindings/usb/generic-ehci.yaml > index 247ef00381ea..f76b25f7fc7a 100644 > --- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml > +++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml > @@ -83,6 +83,7 @@ properties: >Phandle of a companion. > >phys: > +maxItems: 1 > description: PHY specifier for the USB PHY > >phy-names: > diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml > b/Documentation/devicetree/bindings/usb/generic-ohci.yaml > index 2178bcc401bc..8e2bd61f2075 100644 > --- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml > +++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml > @@ -71,6 +71,7 @@ properties: >Overrides the detected port count > >phys: > +maxItems: 1 > description: PHY specifier for the USB PHY > >phy-names: > diff --git a/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > b/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > index 678396eeeb78..f506225a4d57 100644 > --- a/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > +++ b/Documentation/devicetree/bindings/usb/ingenic,musb.yaml > @@ -40,7 +40,7 @@ properties: >- const: mc > >phys: > -description: PHY specifier for the USB PHY > +maxItems: 1 > >usb-role-switch: > type: boolean Any reason you dropped the description for this entry, but not the other ones above? > diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > index 388245b91a55..adce36e48bc9 100644 > --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml > @@ -15,13 +15,14 @@ properties: >- const: ti,j721e-usb > >reg: > -description: module registers > +maxItems: 1 > >power-domains: > description: >PM domain provider node and an args specifier containing >the USB device id value. See, >Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt > +maxItems: 1 > >clocks: > description: Clock phandles to usb2_refclk and lpm_clk Same here, why remove the description? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amdgpu: Do not change amdgpu framebuffer format during page flip
Hi Zhan,
url:
https://github.com/0day-ci/linux/commits/Zhan-Liu/drm-amdgpu-Do-not-change-amdgpu-framebuffer-format-during-page-flip/20201230-051134
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
dea8dcf2a9fa8cc540136a6cd885c3beece16ec3
config: x86_64-randconfig-m031-20201229 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
New smatch warnings:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:831
convert_tiling_flags_to_modifier() warn: variable dereferenced before check
'afb->base.format' (see line 826)
vim +831 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 678 static int
convert_tiling_flags_to_modifier(struct amdgpu_framebuffer *afb)
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 679 {
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 680 struct amdgpu_device
*adev = drm_to_adev(afb->base.dev);
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 681 uint64_t modifier = 0;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 682
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 683 if (!afb->tiling_flags
|| !AMDGPU_TILING_GET(afb->tiling_flags, SWIZZLE_MODE)) {
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 684 modifier =
DRM_FORMAT_MOD_LINEAR;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 685 } else {
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 686 int swizzle =
AMDGPU_TILING_GET(afb->tiling_flags, SWIZZLE_MODE);
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 687 bool has_xor =
swizzle >= 16;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 688 int
block_size_bits;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 689 int version;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 690 int
pipe_xor_bits = 0;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 691 int
bank_xor_bits = 0;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 692 int packers = 0;
1331e6304f5d924a Bas Nieuwenhuizen 2020-11-11 693 int rb = 0;
1331e6304f5d924a Bas Nieuwenhuizen 2020-11-11 694 int pipes =
ilog2(adev->gfx.config.gb_addr_config_fields.num_pipes);
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 695 uint32_t
dcc_offset = AMDGPU_TILING_GET(afb->tiling_flags, DCC_OFFSET_256B);
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 696
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 697 switch (swizzle
>> 2) {
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 698 case 0: /* 256B
*/
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 699
block_size_bits = 8;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 700 break;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 701 case 1: /* 4KiB
*/
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 702 case 5: /* 4KiB
_X */
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 703
block_size_bits = 12;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 704 break;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 705 case 2: /*
64KiB */
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 706 case 4: /* 64
KiB _T */
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 707 case 6: /* 64
KiB _X */
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 708
block_size_bits = 16;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 709 break;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 710 default:
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 711 /*
RESERVED or VAR */
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 712 return
-EINVAL;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 713 }
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 714
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 715 if
(adev->asic_type >= CHIP_SIENNA_CICHLID)
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 716 version
= AMD_FMT_MOD_TILE_VER_GFX10_RBPLUS;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 717 else if
(adev->family == AMDGPU_FAMILY_NV)
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 718 version
= AMD_FMT_MOD_TILE_VER_GFX10;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 719 else
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 720 version
= AMD_FMT_MOD_TILE_VER_GFX9;
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 721
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 722 switch (swizzle
& 3) {
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 723 case 0: /* Z
microtiling */
08d769151dc9690a Bas Nieuwenhuizen 2020-09-02 724 return
-EINVAL;
08d769151dc9690a Bas Nieuwenhuize
Re: 5.11-rc1 TTM list corruption
On Tue, Jan 05, 2021 at 07:43:51PM +0800, Borislav Petkov wrote: > On Tue, Jan 05, 2021 at 07:08:52PM +0800, Huang Rui wrote: > > Ah, this asic is a bit old and still use radeon driver. So we didn't > > reproduce it on amdgpu driver. I don't have such the old asic in my hand. > > May we know whether this issue can be duplicated after SI which is used > > amdgpu module (not sure whether you have recent APU or GPU)? > > The latest I have (I think it is the latest) is: > > [1.826102] [drm] initializing kernel modesetting (RENOIR 0x1002:0x1636 > 0x17AA:0x5099 0xD1). > > and so far that hasn't triggered it. Which makes sense because that > thing uses amdgpu: > > [1.810260] [drm] amdgpu kernel modesetting enabled. Yes! Renoir is late enough for amdgpu kernel module. :-) Please let us know if you still encounter the issue. Thanks, Ray ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211033] [bisected][regression] amdgpu: *ERROR* Restoring old state failed with -12
https://bugzilla.kernel.org/show_bug.cgi?id=211033 --- Comment #4 from Oleg Serytsan (oseryt...@gmail.com) --- Got the same problem with 5.4.86 and AMD RX560. Reverting the following commit fixed the issue: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.4.y&id=e1b1f10c3404c8d40c45c3a6846d304fd403fa2c -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/12] vgacon: drop BROKEN_GRAPHICS_PROGRAMS
BROKEN_GRAPHICS_PROGRAMS is defined when CONFIG_VGA_CONSOLE=y. And
vgacon.c is built exclusively in that case too. So the check for
BROKEN_GRAPHICS_PROGRAMS is pointless in vgacon.c as it is always true.
So remove the test and BROKEN_GRAPHICS_PROGRAMS completely.
This also eliminates the need for vga_font_is_default global as it is
only set and never read.
Signed-off-by: Jiri Slaby
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
---
drivers/video/console/vgacon.c | 19 ---
include/linux/vt_kern.h| 12
2 files changed, 31 deletions(-)
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 17876f0179b5..962c12be9774 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -90,7 +90,6 @@ static unsigned int vga_video_num_lines;
/* Number of text lines */
static boolvga_can_do_color; /* Do we
support colors? */
static unsigned intvga_default_font_height __read_mostly; /* Height of
default screen font */
static unsigned char vga_video_type __read_mostly; /* Card type */
-static boolvga_font_is_default = true;
static int vga_vesa_blanked;
static boolvga_palette_blanked;
static boolvga_is_gfx;
@@ -878,7 +877,6 @@ static int vgacon_do_font_op(struct vgastate *state, char
*arg, int set,
beg = 0x0a;
}
-#ifdef BROKEN_GRAPHICS_PROGRAMS
/*
* All fonts are loaded in slot 0 (0:1 for 512 ch)
*/
@@ -886,24 +884,7 @@ static int vgacon_do_font_op(struct vgastate *state, char
*arg, int set,
if (!arg)
return -EINVAL; /* Return to default font not supported */
- vga_font_is_default = false;
font_select = ch512 ? 0x04 : 0x00;
-#else
- /*
-* The default font is kept in slot 0 and is never touched.
-* A custom font is loaded in slot 2 (256 ch) or 2:3 (512 ch)
-*/
-
- if (set) {
- vga_font_is_default = !arg;
- if (!arg)
- ch512 = false; /* Default font is always 256 */
- font_select = arg ? (ch512 ? 0x0e : 0x0a) : 0x00;
- }
-
- if (!vga_font_is_default)
- charmap += 4 * cmapsz;
-#endif
raw_spin_lock_irq(&vga_lock);
/* First, the Sequencer */
diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
index 349e39c3ab60..94e7a315479c 100644
--- a/include/linux/vt_kern.h
+++ b/include/linux/vt_kern.h
@@ -16,18 +16,6 @@
#include
#include
-/*
- * Presently, a lot of graphics programs do not restore the contents of
- * the higher font pages. Defining this flag will avoid use of them, but
- * will lose support for PIO_FONTRESET. Note that many font operations are
- * not likely to work with these programs anyway; they need to be
- * fixed. The linux/Documentation directory includes a code snippet
- * to save and restore the text font.
- */
-#ifdef CONFIG_VGA_CONSOLE
-#define BROKEN_GRAPHICS_PROGRAMS 1
-#endif
-
void kd_mksound(unsigned int hz, unsigned int ticks);
int kbd_rate(struct kbd_repeat *rep);
--
2.30.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211043] New: amdgpu: Mouse cursor freeze of external mouse after a while (after kernel crash?) (KDE Plasma)
https://bugzilla.kernel.org/show_bug.cgi?id=211043 Bug ID: 211043 Summary: amdgpu: Mouse cursor freeze of external mouse after a while (after kernel crash?) (KDE Plasma) Product: Drivers Version: 2.5 Kernel Version: 5.6.0-1036-oem Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: kdeb...@staznosti.sk Regression: No [91295.652772] WARNING: CPU: 0 PID: 88314 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c:1555 dcn20_program_front_end_for_ctx+0x574/0x580 [amdgpu] [91295.652773] Modules linked in: uhid usbhid uas usb_storage snd_seq_dummy snd_hrtimer ccm rfcomm snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel cmac snd_intel_dspcfg soundwire_intel algif_hash soundwire_generic_allocation soundwire_cadence algif_skcipher snd_hda_codec af_alg bnep snd_hda_core snd_hwdep soundwire_bus snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_pcm snd_seq_midi snd_seq_midi_event iwlmvm snd_rawmidi joydev binfmt_misc mac80211 nls_iso8859_1 libarc4 snd_seq btusb edac_mce_amd snd_seq_device iwlwifi snd_timer uvcvideo btrtl btbcm videobuf2_vmalloc btintel videobuf2_memops snd input_leds videobuf2_v4l2 bluetooth videobuf2_common videodev kvm_amd ecdh_generic asus_wmi mc hid_multitouch ecc serio_raw sparse_keymap snd_rn_pci_acp3x wmi_bmof soundcore cfg80211 snd_pci_acp3x kvm ccp mac_hid sch_fq_codel msr parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs blake2b_generic xor zstd_compress raid6_pq libcrc32c dm_mirror [91295.652807] dm_region_hash dm_log hid_generic amdgpu amd_iommu_v2 gpu_sched crct10dif_pclmul i2c_algo_bit crc32_pclmul ttm ghash_clmulni_intel drm_kms_helper aesni_intel syscopyarea sysfillrect sysimgblt fb_sys_fops crypto_simd cec cryptd glue_helper rc_coredrm ahci nvme libahci i2c_piix4 r8169 nvme_core realtek wmi video i2c_hid hid [91295.652828] CPU: 0 PID: 88314 Comm: Xorg Tainted: GW 5.6.0-1036-oem #39-Ubuntu [91295.652829] Hardware name: SLIMBOOK PROX14-AMD/PROX14-AMD, BIOS N.1.06GRP01 07/06/2020 [91295.652940] RIP: 0010:dcn20_program_front_end_for_ctx+0x574/0x580 [amdgpu] [91295.652944] Code: c0 74 cb 4c 89 e2 48 89 df e8 78 97 d9 c5 eb be 49 8b 45 00 8b 90 e4 01 00 00 85 d2 75 d5 8b 86 4c 04 00 00 85c0 75 cb eb a4 <0f> 0b e9 14 fb ff ff 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 [91295.652945] RSP: 0018:ade74478f810 EFLAGS: 00010202 [91295.652947] RAX: 890a8af1f400 RBX: 890a76f4 RCX: 0008 [91295.652948] RDX: 0001 RSI: 8906868e RDI: 890a76f4 [91295.652949] RBP: ade74478f848 R08: 0001 R09: [91295.652949] R10: 0001 R11: 0004 R12: 8906868e [91295.652950] R13: 8906868e01b8 R14: 8906868e01b8 R15: [91295.652952] FS: 7f4c921a7a80() GS:890a8ee0() knlGS: [91295.652953] CS: 0010 DS: ES: CR0: 80050033 [91295.652954] CR2: 55d14c7c5734 CR3: 00075a518000 CR4: 00340ef0 [91295.652955] Call Trace: [91295.653063] dc_commit_state_no_check+0x4bc/0x8a0 [amdgpu] [91295.653162] dc_commit_state+0x96/0xb0 [amdgpu] [91295.653266] amdgpu_dm_atomic_commit_tail+0x344/0x11d0 [amdgpu] [91295.653359] ? amdgpu_cgs_read_register+0x14/0x20 [amdgpu] [91295.653450] ? dm_read_reg_func+0x40/0xc0 [amdgpu] [91295.653536] ? generic_reg_get+0x22/0x40 [amdgpu] [91295.653541] ? _cond_resched+0x19/0x30 [91295.653612] ? amdgpu_bo_pin_restricted+0x64/0x2b0 [amdgpu] [91295.653620] ? ttm_bo_move_to_lru_tail+0x2d/0xc0 [ttm] [91295.653622] ? ww_mutex_unlock+0x26/0x30 [91295.653627] ? ttm_eu_backoff_reservation+0x49/0x70 [ttm] [91295.653697] ? amdgpu_bo_gpu_offset+0x23/0xa0 [amdgpu] [91295.653794] ? dm_plane_helper_prepare_fb+0x143/0x270 [amdgpu] [91295.653797] ? _cond_resched+0x19/0x30 [91295.653799] ? wait_for_completion_timeout+0x3a/0x120 [91295.653801] ? _cond_resched+0x19/0x30 [91295.653803] ? wait_for_completion_interruptible+0x37/0x160 [91295.653816] commit_tail+0x99/0x130 [drm_kms_helper] [91295.653825] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] [91295.653920] amdgpu_dm_atomic_commit+0x95/0xa0 [amdgpu] [91295.653942] drm_atomic_commit+0x4a/0x50 [drm] [91295.653959] drm_atomic_connector_commit_dpms+0xdf/0x100 [drm] [91295.653978] drm_mode_obj_set_property_ioctl+0x156/0x2d0 [drm] [91295.653996] ? drm_connector_set_obj_prop+0x90/0x90 [drm] [91295.654011] drm_connector_property_set_ioctl+0x3b/0x60 [drm] [91295.654026] drm_ioctl_kernel+0xae/0xf0 [drm] [91295.654042] drm_ioctl+0x234/0x3d0 [drm] [91295.654056] ? drm_connector_set_obj_prop+0x90/0x90 [drm] [91295.654060] ? sock_poll+0x7c/0xc0 [91295.654063] ? ep_item
Re: [PATCH v2 3/6] dt-bindings: display: imx: hdmi: Convert binding to YAML
Hi Philipp,
On Tue, Jan 05, 2021 at 10:32:01AM +0100, Philipp Zabel wrote:
> On Tue, 2021-01-05 at 07:49 +0200, Laurent Pinchart wrote:
> > On Mon, Jan 04, 2021 at 04:30:36PM +0100, Philipp Zabel wrote:
> > > On Sun, 2020-12-20 at 21:50 +0200, Laurent Pinchart wrote:
> > > > Convert the i.MX6 HDMI TX text binding to YAML.
> > > >
> > > > Signed-off-by: Laurent Pinchart
> > > >
> > > > ---
> > > > Changes since v1:
> > > >
> > > > - Only specify maxItems for clocks
> > > > - Drop reg and interrupts as they're checked in the base schema
> > > > - Rebase on top of OF graph schema, dropped redundant properties
> > > > - Fix identation for enum entries
> > > > - Drop clock-names items, use maxItems only
> > > > ---
> > > > .../bindings/display/imx/fsl,imx6-hdmi.yaml | 130 ++
> > > > .../devicetree/bindings/display/imx/hdmi.txt | 65 -
> > > > 2 files changed, 130 insertions(+), 65 deletions(-)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
> > > > delete mode 100644
> > > > Documentation/devicetree/bindings/display/imx/hdmi.txt
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
> > > > b/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
> > > > new file mode 100644
> > > > index ..f9b131bb3339
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
> > > > @@ -0,0 +1,130 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/display/imx/fsl,imx6-hdmi.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Freescale i.MX6 DWC HDMI TX Encoder
> > > > +
> > > > +maintainers:
> > > > + - Philipp Zabel
> > > > +
> > > > +description: |
> > > > + The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller
> > > > IP
> > > > + with a companion PHY IP.
> > > > +
> > > > +allOf:
> > > > + - $ref: ../bridge/synopsys,dw-hdmi.yaml#
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > +enum:
> > > > + - fsl,imx6dl-hdmi
> > > > + - fsl,imx6q-hdmi
> > > > +
> > > > + reg-io-width:
> > > > +const: 1
> > > > +
> > > > + clocks:
> > > > +maxItems: 2
> > > > +
> > > > + clock-names:
> > > > +maxItems: 2
> > > > +
> > > > + ddc-i2c-bus:
> > > > +$ref: /schemas/types.yaml#/definitions/phandle
> > > > +description:
> > > > + The HDMI DDC bus can be connected to either a system I2C master
> > > > or the
> > > > + functionally-reduced I2C master contained in the DWC HDMI. When
> > > > connected
> > > > + to a system I2C master this property contains a phandle to that
> > > > I2C
> > > > + master controller.
> > > > +
> > > > + gpr:
> > > > +$ref: /schemas/types.yaml#/definitions/phandle
> > > > +description:
> > > > + phandle to the iomuxc-gpr region containing the HDMI multiplexer
> > > > control
> > > > + register.
> > > > +
> > > > + ports:
> > > > +$ref: /schemas/graph.yaml#/properties/ports
> > > > +description: |
> > > > + This device has four video ports, corresponding to the four
> > > > inputs of the
> > > > + HDMI multiplexer. Each port shall have a single endpoint.
> > > > +
> > > > +properties:
> > > > + port@0:
> > > > +$ref: /schemas/graph.yaml#/$defs/port-base
> > > > +unevaluatedProperties: false
> > > > +description: First input of the HDMI multiplexer
> > > > +
> > > > + port@1:
> > > > +$ref: /schemas/graph.yaml#/$defs/port-base
> > > > +unevaluatedProperties: false
> > > > +description: Second input of the HDMI multiplexer
> > > > +
> > > > + port@2:
> > > > +$ref: /schemas/graph.yaml#/$defs/port-base
> > > > +unevaluatedProperties: false
> > > > +description: Third input of the HDMI multiplexer
> > > > +
> > > > + port@3:
> > > > +$ref: /schemas/graph.yaml#/$defs/port-base
> > > > +unevaluatedProperties: false
> > > > +description: Fourth input of the HDMI multiplexer
> > > > +
> > > > +anyOf:
> > > > + - required:
> > > > + - port@0
> > > > + - required:
> > > > + - port@1
> > > > + - required:
> > > > + - port@2
> > > > + - required:
> > > > + - port@3
> > > > +
> > > > +required:
> > > > + - compatible
> > > > + - reg
> > > > + - clocks
> > > > + - clock-names
> > > > + - gpr
> > > > + - interrupts
> > > > + - ports
>
> The binding marks the "ports" container node as required.
>
> > > Won't this break validation of current i.MX6 DTs, which don't use the
> > > ports node (in imx6q(dl).dtsi)?
> >
> > I may be missing something, but in imx6qdl.dtsi, we have
>
> [...]
>
> > and in imx6q.dtsi,
> >
> > &hdmi {
> > compatible = "fsl,imx6q-hdmi";
> >
> > por
Re: [PATCH] drm/ttm: Remove pinned bos from LRU in ttm_bo_move_to_lru_tail()
Am 04.01.21 um 22:06 schrieb Christian König:
Am 05.01.21 um 00:13 schrieb Lyude Paul:
Recently a regression was introduced which caused TTM's buffer
eviction to
attempt to evict already-pinned BOs, causing issues with buffer eviction
under memory pressure along with suspend/resume:
nouveau :1f:00.0: DRM: evicting buffers...
nouveau :1f:00.0: DRM: Moving pinned object c428c3ff!
nouveau :1f:00.0: fifo: fault 00 [READ] at 0020
engine 04
[BAR1] client 07 [HUB/HOST_CPU] reason 02 [PTE] on channel -1
[00ffeaa000
unknown]
nouveau :1f:00.0: fifo: DROPPED_MMU_FAULT 1000
nouveau :1f:00.0: fifo: fault 01 [WRITE] at 0002
engine
0c [HOST6] client 07 [HUB/HOST_CPU] reason 02 [PTE] on channel 1
[00ffb28000 DRM]
nouveau :1f:00.0: fifo: channel 1: killed
nouveau :1f:00.0: fifo: runlist 0: scheduled for recovery
[TTM] Buffer eviction failed
nouveau :1f:00.0: DRM: waiting for kernel channels to go idle...
nouveau :1f:00.0: DRM: failed to idle channel 1 [DRM]
nouveau :1f:00.0: DRM: resuming display...
After some bisection and investigation, it appears this resulted from
the
recent changes to ttm_bo_move_to_lru_tail(). Previously when a buffer
was
pinned, the buffer would be removed from the LRU once ttm_bo_unreserve
to maintain the LRU list when pinning or unpinning BOs. However, since:
commit 3d1a88e1051f ("drm/ttm: cleanup LRU handling further")
We've been exiting from ttm_bo_move_to_lru_tail() at the very
beginning of
the function if the bo we're looking at is pinned, resulting in the
pinned
BO never getting removed from the lru and as a result - causing
issues when
it eventually becomes time for eviction.
So, let's fix this by calling ttm_bo_del_from_lru() from
ttm_bo_move_to_lru_tail() in the event that we're dealing with a pinned
buffer.
As well, add back the hunks in ttm_bo_del_from_lru() that were
removed which checked whether we want to call
bdev->driver->del_from_lru_notify() or not. We do this last part to
avoid
calling the hook when the bo in question was already removed from the
LRU.
It turned out that this is not correct, we always want to call the
callback whenever we would move the BO on the LRU.
I've modified the patch and send it out once more, please review.
Thanks,
Christian.
Signed-off-by: Lyude Paul
Fixes: 3d1a88e1051f ("drm/ttm: cleanup LRU handling further")
Cc: Christian König
Cc: Dave Airlie
I was already working on a fix as well, but you have been faster than
me :)
Reviewed-by: Christian König
Going to pick this up for drm-misc-next or drm-misc-fixes in a few
minutes.
Thanks,
Christian.
---
drivers/gpu/drm/ttm/ttm_bo.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 31e8b3da5563..0f373b78e7fa 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -113,11 +113,18 @@ static struct kobj_type ttm_bo_glob_kobj_type = {
static void ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
{
struct ttm_bo_device *bdev = bo->bdev;
+ bool notify = false;
- list_del_init(&bo->swap);
- list_del_init(&bo->lru);
+ if (!list_empty(&bo->swap)) {
+ notify = true;
+ list_del_init(&bo->swap);
+ }
+ if (!list_empty(&bo->lru)) {
+ notify = true;
+ list_del_init(&bo->lru);
+ }
- if (bdev->driver->del_from_lru_notify)
+ if (notify && bdev->driver->del_from_lru_notify)
bdev->driver->del_from_lru_notify(bo);
}
@@ -138,8 +145,13 @@ void ttm_bo_move_to_lru_tail(struct
ttm_buffer_object *bo,
dma_resv_assert_held(bo->base.resv);
- if (bo->pin_count)
+ /* Pinned bos will have been added to the LRU before they were
pinned, so make sure we
+ * always remove them here
+ */
+ if (bo->pin_count) {
+ ttm_bo_del_from_lru(bo);
return;
+ }
man = ttm_manager_type(bdev, mem->mem_type);
list_move_tail(&bo->lru, &man->lru[bo->priority]);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: Remove pinned bos from LRU in ttm_bo_move_to_lru_tail() v2
From: Lyude Paul
Recently a regression was introduced which caused TTM's buffer eviction to
attempt to evict already-pinned BOs, causing issues with buffer eviction
under memory pressure along with suspend/resume:
nouveau :1f:00.0: DRM: evicting buffers...
nouveau :1f:00.0: DRM: Moving pinned object c428c3ff!
nouveau :1f:00.0: fifo: fault 00 [READ] at 0020 engine 04
[BAR1] client 07 [HUB/HOST_CPU] reason 02 [PTE] on channel -1 [00ffeaa000
unknown]
nouveau :1f:00.0: fifo: DROPPED_MMU_FAULT 1000
nouveau :1f:00.0: fifo: fault 01 [WRITE] at 0002 engine
0c [HOST6] client 07 [HUB/HOST_CPU] reason 02 [PTE] on channel 1
[00ffb28000 DRM]
nouveau :1f:00.0: fifo: channel 1: killed
nouveau :1f:00.0: fifo: runlist 0: scheduled for recovery
[TTM] Buffer eviction failed
nouveau :1f:00.0: DRM: waiting for kernel channels to go idle...
nouveau :1f:00.0: DRM: failed to idle channel 1 [DRM]
nouveau :1f:00.0: DRM: resuming display...
After some bisection and investigation, it appears this resulted from the
recent changes to ttm_bo_move_to_lru_tail(). Previously when a buffer was
pinned, the buffer would be removed from the LRU once ttm_bo_unreserve
to maintain the LRU list when pinning or unpinning BOs. However, since:
commit 3d1a88e1051f ("drm/ttm: cleanup LRU handling further")
We've been exiting from ttm_bo_move_to_lru_tail() at the very beginning of
the function if the bo we're looking at is pinned, resulting in the pinned
BO never getting removed from the lru and as a result - causing issues when
it eventually becomes time for eviction.
So, let's fix this by calling ttm_bo_del_from_lru() from
ttm_bo_move_to_lru_tail() in the event that we're dealing with a pinned
buffer.
v2 (chk): reduce to only the fixing one liner since we always want to
call the callback whenever we would move on the LRU.
Signed-off-by: Lyude Paul
Fixes: 3d1a88e1051f ("drm/ttm: cleanup LRU handling further")
Cc: Christian König
Cc: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 31e8b3da5563..b65f4b12f986 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -138,8 +138,10 @@ void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
dma_resv_assert_held(bo->base.resv);
- if (bo->pin_count)
+ if (bo->pin_count) {
+ ttm_bo_del_from_lru(bo);
return;
+ }
man = ttm_manager_type(bdev, mem->mem_type);
list_move_tail(&bo->lru, &man->lru[bo->priority]);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 5.11-rc1 TTM list corruption
On Tue, Jan 05, 2021 at 07:08:52PM +0800, Huang Rui wrote: > Ah, this asic is a bit old and still use radeon driver. So we didn't > reproduce it on amdgpu driver. I don't have such the old asic in my hand. > May we know whether this issue can be duplicated after SI which is used > amdgpu module (not sure whether you have recent APU or GPU)? The latest I have (I think it is the latest) is: [1.826102] [drm] initializing kernel modesetting (RENOIR 0x1002:0x1636 0x17AA:0x5099 0xD1). and so far that hasn't triggered it. Which makes sense because that thing uses amdgpu: [1.810260] [drm] amdgpu kernel modesetting enabled. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 5.11-rc1 TTM list corruption
Am 05.01.21 um 12:08 schrieb Huang Rui: On Tue, Jan 05, 2021 at 06:31:38PM +0800, Borislav Petkov wrote: Hi, On Tue, Jan 05, 2021 at 12:12:13PM +0800, Huang Rui wrote: I am reproducing this issue as well, are you using a Raven board? I have no clue what Raven is. The workstation I triggered it once on, has: [7.563968] [drm] radeon kernel modesetting enabled. [7.581417] [drm] initializing kernel modesetting (CAICOS 0x1002:0x6779 0x174B:0xE164 0x00). Ah, this asic is a bit old and still use radeon driver. So we didn't reproduce it on amdgpu driver. I don't have such the old asic in my hand. May we know whether this issue can be duplicated after SI which is used amdgpu module (not sure whether you have recent APU or GPU)? Ah! Thanks Ray for pointing this out. I have SI based hardware here. Going to try this in a few minutes. Thanks, Christian. Thanks, Ray [7.609217] [drm] Detected VRAM RAM=2048M, BAR=256M [7.614031] [drm] RAM width 64bits DDR [7.639665] [drm] radeon: 2048M of VRAM memory ready [7.644557] [drm] radeon: 1024M of GTT memory ready. [7.649451] [drm] Loading CAICOS Microcode [7.653548] [drm] Internal thermal controller without fan control [7.661221] [drm] radeon: dpm initialized [7.665227] [drm] GART: num cpu pages 262144, num gpu pages 262144 [7.671821] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [7.703858] [drm] PCIE GART of 1024M enabled (table at 0x00162000). [7.749689] [drm] radeon: irq initialized. [7.769826] [drm] ring test on 0 succeeded in 1 usecs [7.774797] [drm] ring test on 3 succeeded in 3 usecs [7.955500] [drm] ring test on 5 succeeded in 1 usecs [7.960468] [drm] UVD initialized successfully. [7.965047] [drm] ib test on ring 0 succeeded in 0 usecs [7.970316] [drm] ib test on ring 3 succeeded in 0 usecs [8.626877] [drm] ib test on ring 5 succeeded [8.631376] [drm] Radeon Display Connectors [8.635496] [drm] Connector 0: [8.638503] [drm] HDMI-A-1 [8.641339] [drm] HPD2 [8.643835] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [8.651102] [drm] Encoders: [8.654022] [drm] DFP1: INTERNAL_UNIPHY1 [8.658224] [drm] Connector 1: [8.661232] [drm] DVI-D-1 [8.663982] [drm] HPD4 [8.666479] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [8.673745] [drm] Encoders: [8.676665] [drm] DFP2: INTERNAL_UNIPHY [8.680782] [drm] Connector 2: [8.683789] [drm] VGA-1 [8.686369] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [8.693636] [drm] Encoders: [8.696555] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [8.788923] [drm] fb mappable at 0xE0363000 [8.793036] [drm] vram apper at 0xE000 [8.797064] [drm] size 9216000 [8.800071] [drm] fb depth is 24 [8.803249] [drm]pitch is 7680 [8.807106] fbcon: radeondrmfb (fb0) is primary device [8.918927] radeon :1d:00.0: [drm] fb0: radeondrmfb frame buffer device [8.938461] [drm] Initialized radeon 2.50.0 20080528 for :1d:00.0 on minor 0 HTH. -- Regards/Gruss, Boris. https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeople.kernel.org%2Ftglx%2Fnotes-about-netiquette&data=04%7C01%7Cray.huang%40amd.com%7C31b8dcd4040e4a49380e08d8b16517ad%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637454395066317813%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=al4lLGA%2BCdHK4HzO8M5VJthY8Iv71xQ0TsDGwJpgs1A%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi Am 05.01.21 um 12:04 schrieb Gerd Hoffmann: Hi, It's not possible to do page flip with this virtual device. The call to SYNTHVID_VRAM_LOCATION is only honoured once. So unfortunately need to use SHMEM helpers. I was thinking about using struct video_output_situation.vram_offset; in case you want to tinker with that. There's a comment in the patch that vram_offset should always be 0. But this comment seems incorrect for devices with more than one output. Where does the comment come from? fbdev drivers support a single framebuffer only so for a fbdev driver it makes sense to set the offset to 0 unconditionally. With drm you probably can handle things differently ... I cannot find it in hyperv_fb.c; it must have gotten introduced here. Only one display is supported by this DRM driver, so the comment is correct. In the future, having support for multiple displays might be an option. Best regards Thomas take care, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: Add missing array size constraints
Hi Rob, On Mon, Jan 04, 2021 at 04:02:53PM -0700, Rob Herring wrote: > DT properties which can have multiple entries need to specify what the > entries are and define how many entries there can be. In the case of > only a single entry, just 'maxItems: 1' is sufficient. > > Add the missing entry constraints. These were found with a modified > meta-schema. Unfortunately, there are a few cases where the size > constraints are not defined such as common bindings, so the meta-schema > can't be part of the normal checks. > > [...] > .../bindings/power/supply/bq25980.yaml| 1 + > [...] Acked-by: Sebastian Reichel -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 5.11-rc1 TTM list corruption
On Tue, Jan 05, 2021 at 06:31:38PM +0800, Borislav Petkov wrote: > Hi, > > On Tue, Jan 05, 2021 at 12:12:13PM +0800, Huang Rui wrote: > > I am reproducing this issue as well, are you using a Raven board? > > I have no clue what Raven is. The workstation I triggered it once on, has: > > [7.563968] [drm] radeon kernel modesetting enabled. > [7.581417] [drm] initializing kernel modesetting (CAICOS 0x1002:0x6779 > 0x174B:0xE164 0x00). Ah, this asic is a bit old and still use radeon driver. So we didn't reproduce it on amdgpu driver. I don't have such the old asic in my hand. May we know whether this issue can be duplicated after SI which is used amdgpu module (not sure whether you have recent APU or GPU)? Thanks, Ray > [7.609217] [drm] Detected VRAM RAM=2048M, BAR=256M > [7.614031] [drm] RAM width 64bits DDR > [7.639665] [drm] radeon: 2048M of VRAM memory ready > [7.644557] [drm] radeon: 1024M of GTT memory ready. > [7.649451] [drm] Loading CAICOS Microcode > [7.653548] [drm] Internal thermal controller without fan control > [7.661221] [drm] radeon: dpm initialized > [7.665227] [drm] GART: num cpu pages 262144, num gpu pages 262144 > [7.671821] [drm] enabling PCIE gen 2 link speeds, disable with > radeon.pcie_gen2=0 > [7.703858] [drm] PCIE GART of 1024M enabled (table at 0x00162000). > [7.749689] [drm] radeon: irq initialized. > [7.769826] [drm] ring test on 0 succeeded in 1 usecs > [7.774797] [drm] ring test on 3 succeeded in 3 usecs > [7.955500] [drm] ring test on 5 succeeded in 1 usecs > [7.960468] [drm] UVD initialized successfully. > [7.965047] [drm] ib test on ring 0 succeeded in 0 usecs > [7.970316] [drm] ib test on ring 3 succeeded in 0 usecs > [8.626877] [drm] ib test on ring 5 succeeded > [8.631376] [drm] Radeon Display Connectors > [8.635496] [drm] Connector 0: > [8.638503] [drm] HDMI-A-1 > [8.641339] [drm] HPD2 > [8.643835] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c > 0x644c > [8.651102] [drm] Encoders: > [8.654022] [drm] DFP1: INTERNAL_UNIPHY1 > [8.658224] [drm] Connector 1: > [8.661232] [drm] DVI-D-1 > [8.663982] [drm] HPD4 > [8.666479] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c > 0x646c > [8.673745] [drm] Encoders: > [8.676665] [drm] DFP2: INTERNAL_UNIPHY > [8.680782] [drm] Connector 2: > [8.683789] [drm] VGA-1 > [8.686369] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c > 0x643c > [8.693636] [drm] Encoders: > [8.696555] [drm] CRT1: INTERNAL_KLDSCP_DAC1 > [8.788923] [drm] fb mappable at 0xE0363000 > [8.793036] [drm] vram apper at 0xE000 > [8.797064] [drm] size 9216000 > [8.800071] [drm] fb depth is 24 > [8.803249] [drm]pitch is 7680 > [8.807106] fbcon: radeondrmfb (fb0) is primary device > [8.918927] radeon :1d:00.0: [drm] fb0: radeondrmfb frame buffer device > [8.938461] [drm] Initialized radeon 2.50.0 20080528 for :1d:00.0 on > minor 0 > > HTH. > > -- > Regards/Gruss, > Boris. > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeople.kernel.org%2Ftglx%2Fnotes-about-netiquette&data=04%7C01%7Cray.huang%40amd.com%7C31b8dcd4040e4a49380e08d8b16517ad%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637454395066317813%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=al4lLGA%2BCdHK4HzO8M5VJthY8Iv71xQ0TsDGwJpgs1A%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Hi, > > It's not possible to do page flip with this virtual device. The call to > > SYNTHVID_VRAM_LOCATION is only honoured once. So unfortunately need to > > use SHMEM helpers. > > I was thinking about using struct video_output_situation.vram_offset; in > case you want to tinker with that. There's a comment in the patch that > vram_offset should always be 0. But this comment seems incorrect for devices > with more than one output. Where does the comment come from? fbdev drivers support a single framebuffer only so for a fbdev driver it makes sense to set the offset to 0 unconditionally. With drm you probably can handle things differently ... take care, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211033] [bisected][regression] amdgpu: *ERROR* Restoring old state failed with -12
https://bugzilla.kernel.org/show_bug.cgi?id=211033 Jindrich Makovicka (makov...@gmail.com) changed: What|Removed |Added CC||makov...@gmail.com --- Comment #3 from Jindrich Makovicka (makov...@gmail.com) --- On Tue, 5 Jan 2021 07:54:02 +0100, Greg Kroah-Hartman wrote: > Can you test 5.11-rc to see if this issue is there as well? Tested with 5.11.0-rc2 and 5600 XT, same issue. "xset dpms force off" turns the display off and it won't come back, with the same error in the syslog. Jan 5 11:11:54 holly kernel: [drm:dm_restore_drm_connector_state [amdgpu]] *ERROR* Restoring old state failed with -12 Can be worked around by 1) turning display power off completely 2) switching to console 3) turning display power on - linux console shows up 4) switching back to X -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 5.11-rc1 TTM list corruption
Hi, On Tue, Jan 05, 2021 at 12:12:13PM +0800, Huang Rui wrote: > I am reproducing this issue as well, are you using a Raven board? I have no clue what Raven is. The workstation I triggered it once on, has: [7.563968] [drm] radeon kernel modesetting enabled. [7.581417] [drm] initializing kernel modesetting (CAICOS 0x1002:0x6779 0x174B:0xE164 0x00). [7.609217] [drm] Detected VRAM RAM=2048M, BAR=256M [7.614031] [drm] RAM width 64bits DDR [7.639665] [drm] radeon: 2048M of VRAM memory ready [7.644557] [drm] radeon: 1024M of GTT memory ready. [7.649451] [drm] Loading CAICOS Microcode [7.653548] [drm] Internal thermal controller without fan control [7.661221] [drm] radeon: dpm initialized [7.665227] [drm] GART: num cpu pages 262144, num gpu pages 262144 [7.671821] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [7.703858] [drm] PCIE GART of 1024M enabled (table at 0x00162000). [7.749689] [drm] radeon: irq initialized. [7.769826] [drm] ring test on 0 succeeded in 1 usecs [7.774797] [drm] ring test on 3 succeeded in 3 usecs [7.955500] [drm] ring test on 5 succeeded in 1 usecs [7.960468] [drm] UVD initialized successfully. [7.965047] [drm] ib test on ring 0 succeeded in 0 usecs [7.970316] [drm] ib test on ring 3 succeeded in 0 usecs [8.626877] [drm] ib test on ring 5 succeeded [8.631376] [drm] Radeon Display Connectors [8.635496] [drm] Connector 0: [8.638503] [drm] HDMI-A-1 [8.641339] [drm] HPD2 [8.643835] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [8.651102] [drm] Encoders: [8.654022] [drm] DFP1: INTERNAL_UNIPHY1 [8.658224] [drm] Connector 1: [8.661232] [drm] DVI-D-1 [8.663982] [drm] HPD4 [8.666479] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [8.673745] [drm] Encoders: [8.676665] [drm] DFP2: INTERNAL_UNIPHY [8.680782] [drm] Connector 2: [8.683789] [drm] VGA-1 [8.686369] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [8.693636] [drm] Encoders: [8.696555] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [8.788923] [drm] fb mappable at 0xE0363000 [8.793036] [drm] vram apper at 0xE000 [8.797064] [drm] size 9216000 [8.800071] [drm] fb depth is 24 [8.803249] [drm]pitch is 7680 [8.807106] fbcon: radeondrmfb (fb0) is primary device [8.918927] radeon :1d:00.0: [drm] fb0: radeondrmfb frame buffer device [8.938461] [drm] Initialized radeon 2.50.0 20080528 for :1d:00.0 on minor 0 HTH. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/amdgpu:fix IH overflow on Cz
Am 05.01.21 um 08:32 schrieb Defang Bo:
Similar to commit ("drm/amdgpu: fix IH overflow on Vega10 v2").
When an ring buffer overflow happens the appropriate bit is set in the WPTR
register which is also written back to memory. But clearing the bit in the
WPTR doesn't trigger another memory writeback.
So what can happen is that we end up processing the buffer overflow over and
over again because the bit is never cleared. Resulting in a random system
lockup because of an infinite loop in an interrupt handler.
Really good point. I haven't had time to look into other generations
since fixing this for Vega.
One major typo below which needs to be fixed.
Signed-off-by: Defang Bo
---
Changes since v1:
- Modify the code and correct the wrong fix.
---
---
drivers/gpu/drm/amd/amdgpu/cz_ih.c | 38 --
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/cz_ih.c
b/drivers/gpu/drm/amd/amdgpu/cz_ih.c
index 1dca0cabc326..45dd47f45fa2 100644
--- a/drivers/gpu/drm/amd/amdgpu/cz_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/cz_ih.c
@@ -190,22 +190,32 @@ static u32 cz_ih_get_wptr(struct amdgpu_device *adev,
struct amdgpu_ih_ring *ih)
{
u32 wptr, tmp;
-
+
wptr = le32_to_cpu(*ih->wptr_cpu);
- if (REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW)) {
- wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
- /* When a ring buffer overflow happen start parsing interrupt
-* from the last not overwritten vector (wptr + 16). Hopefully
-* this should allow us to catchup.
-*/
- dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
- wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
- ih->rptr = (wptr + 16) & ih->ptr_mask;
- tmp = RREG32(mmIH_RB_CNTL);
- tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
- WREG32(mmIH_RB_CNTL, tmp);
- }
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+ wptr = RREG32(mmIH_RB_CNTL);
That's the wrong register, you need to read the write pointer and not
the control register.
Same problem in all other patches.
Regards,
Christian.
+
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+ wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
+
+ /* When a ring buffer overflow happen start parsing interrupt
+* from the last not overwritten vector (wptr + 16). Hopefully
+* this should allow us to catchup.
+*/
+ dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
+ wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
+ ih->rptr = (wptr + 16) & ih->ptr_mask;
+ tmp = RREG32(mmIH_RB_CNTL);
+ tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
+ WREG32(mmIH_RB_CNTL, tmp);
+
+
+out:
return (wptr & ih->ptr_mask);
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/6] dt-bindings: display: imx: hdmi: Convert binding to YAML
On Tue, 2021-01-05 at 07:49 +0200, Laurent Pinchart wrote:
> Hi Philipp,
>
> On Mon, Jan 04, 2021 at 04:30:36PM +0100, Philipp Zabel wrote:
> > On Sun, 2020-12-20 at 21:50 +0200, Laurent Pinchart wrote:
> > > Convert the i.MX6 HDMI TX text binding to YAML.
> > >
> > > Signed-off-by: Laurent Pinchart
> > >
> > > ---
> > > Changes since v1:
> > >
> > > - Only specify maxItems for clocks
> > > - Drop reg and interrupts as they're checked in the base schema
> > > - Rebase on top of OF graph schema, dropped redundant properties
> > > - Fix identation for enum entries
> > > - Drop clock-names items, use maxItems only
> > > ---
> > > .../bindings/display/imx/fsl,imx6-hdmi.yaml | 130 ++
> > > .../devicetree/bindings/display/imx/hdmi.txt | 65 -
> > > 2 files changed, 130 insertions(+), 65 deletions(-)
> > > create mode 100644
> > > Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
> > > delete mode 100644 Documentation/devicetree/bindings/display/imx/hdmi.txt
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
> > > b/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
> > > new file mode 100644
> > > index ..f9b131bb3339
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml
> > > @@ -0,0 +1,130 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/display/imx/fsl,imx6-hdmi.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Freescale i.MX6 DWC HDMI TX Encoder
> > > +
> > > +maintainers:
> > > + - Philipp Zabel
> > > +
> > > +description: |
> > > + The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> > > + with a companion PHY IP.
> > > +
> > > +allOf:
> > > + - $ref: ../bridge/synopsys,dw-hdmi.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > +enum:
> > > + - fsl,imx6dl-hdmi
> > > + - fsl,imx6q-hdmi
> > > +
> > > + reg-io-width:
> > > +const: 1
> > > +
> > > + clocks:
> > > +maxItems: 2
> > > +
> > > + clock-names:
> > > +maxItems: 2
> > > +
> > > + ddc-i2c-bus:
> > > +$ref: /schemas/types.yaml#/definitions/phandle
> > > +description:
> > > + The HDMI DDC bus can be connected to either a system I2C master or
> > > the
> > > + functionally-reduced I2C master contained in the DWC HDMI. When
> > > connected
> > > + to a system I2C master this property contains a phandle to that I2C
> > > + master controller.
> > > +
> > > + gpr:
> > > +$ref: /schemas/types.yaml#/definitions/phandle
> > > +description:
> > > + phandle to the iomuxc-gpr region containing the HDMI multiplexer
> > > control
> > > + register.
> > > +
> > > + ports:
> > > +$ref: /schemas/graph.yaml#/properties/ports
> > > +description: |
> > > + This device has four video ports, corresponding to the four inputs
> > > of the
> > > + HDMI multiplexer. Each port shall have a single endpoint.
> > > +
> > > +properties:
> > > + port@0:
> > > +$ref: /schemas/graph.yaml#/$defs/port-base
> > > +unevaluatedProperties: false
> > > +description: First input of the HDMI multiplexer
> > > +
> > > + port@1:
> > > +$ref: /schemas/graph.yaml#/$defs/port-base
> > > +unevaluatedProperties: false
> > > +description: Second input of the HDMI multiplexer
> > > +
> > > + port@2:
> > > +$ref: /schemas/graph.yaml#/$defs/port-base
> > > +unevaluatedProperties: false
> > > +description: Third input of the HDMI multiplexer
> > > +
> > > + port@3:
> > > +$ref: /schemas/graph.yaml#/$defs/port-base
> > > +unevaluatedProperties: false
> > > +description: Fourth input of the HDMI multiplexer
> > > +
> > > +anyOf:
> > > + - required:
> > > + - port@0
> > > + - required:
> > > + - port@1
> > > + - required:
> > > + - port@2
> > > + - required:
> > > + - port@3
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - clocks
> > > + - clock-names
> > > + - gpr
> > > + - interrupts
> > > + - ports
The binding marks the "ports" container node as required.
> > Won't this break validation of current i.MX6 DTs, which don't use the
> > ports node (in imx6q(dl).dtsi)?
>
> I may be missing something, but in imx6qdl.dtsi, we have
[...]
> and in imx6q.dtsi,
>
> &hdmi {
> compatible = "fsl,imx6q-hdmi";
>
> port@2 {
> reg = <2>;
>
> hdmi_mux_2: endpoint {
> remote-endpoint = <&ipu2_di0_hdmi>;
> };
> };
>
> port@3 {
> reg = <3>;
>
> hdmi_mux_3: endpoint {
> remote-endpoint = <&ipu2_di1_hdmi>;
> };
> };
> };
>
> There are no o
[PATCH RESEND 2/7] iommu/io-pgtable: Add refcounting for io-pgtable format modules
In preparation for modularizing io-pgtable formats, add support
for reference counting the io-pgtable format modules to ensure
that the modules are not unloaded while they are in use.
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/io-pgtable-arm-v7s.c | 1 +
drivers/iommu/io-pgtable-arm.c | 5 +
drivers/iommu/io-pgtable.c | 12 ++--
include/linux/io-pgtable.h | 2 ++
4 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index 080881b..7e81135 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -839,6 +839,7 @@ static struct io_pgtable *arm_v7s_alloc_pgtable(struct
io_pgtable_cfg *cfg,
static struct io_pgtable_init_fns io_pgtable_arm_v7s_init_fns = {
.alloc = arm_v7s_alloc_pgtable,
.free = arm_v7s_free_pgtable,
+ .owner = THIS_MODULE,
};
#ifdef CONFIG_IOMMU_IO_PGTABLE_ARMV7S_SELFTEST
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index e1f8d54..8ed52a0 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -1054,26 +1054,31 @@ static struct arm_lpae_io_pgtable_init_fns
arm_lpae_init_fns_table[] = {
.fmt= ARM_32_LPAE_S1,
.init_fns.alloc = arm_32_lpae_alloc_pgtable_s1,
.init_fns.free = arm_lpae_free_pgtable,
+ .init_fns.owner = THIS_MODULE,
},
{
.fmt= ARM_32_LPAE_S2,
.init_fns.alloc = arm_32_lpae_alloc_pgtable_s2,
.init_fns.free = arm_lpae_free_pgtable,
+ .init_fns.owner = THIS_MODULE,
},
{
.fmt= ARM_64_LPAE_S1,
.init_fns.alloc = arm_64_lpae_alloc_pgtable_s1,
.init_fns.free = arm_lpae_free_pgtable,
+ .init_fns.owner = THIS_MODULE,
},
{
.fmt= ARM_64_LPAE_S2,
.init_fns.alloc = arm_64_lpae_alloc_pgtable_s2,
.init_fns.free = arm_lpae_free_pgtable,
+ .init_fns.owner = THIS_MODULE,
},
{
.fmt= ARM_MALI_LPAE,
.init_fns.alloc = arm_mali_lpae_alloc_pgtable,
.init_fns.free = arm_lpae_free_pgtable,
+ .init_fns.owner = THIS_MODULE,
},
};
diff --git a/drivers/iommu/io-pgtable.c b/drivers/iommu/io-pgtable.c
index 95e872d..9792e25 100644
--- a/drivers/iommu/io-pgtable.c
+++ b/drivers/iommu/io-pgtable.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
static struct io_pgtable_init_fns *io_pgtable_init_table[IO_PGTABLE_NUM_FMTS];
@@ -28,9 +29,14 @@ struct io_pgtable_ops *alloc_io_pgtable_ops(enum
io_pgtable_fmt fmt,
if (!fns)
return NULL;
+ if (!try_module_get(fns->owner))
+ return NULL;
+
iop = fns->alloc(cfg, cookie);
- if (!iop)
+ if (!iop) {
+ module_put(fns->owner);
return NULL;
+ }
iop->fmt= fmt;
iop->cookie = cookie;
@@ -55,8 +61,10 @@ void free_io_pgtable_ops(struct io_pgtable_ops *ops)
iop = io_pgtable_ops_to_pgtable(ops);
io_pgtable_tlb_flush_all(iop);
fns = io_pgtable_init_table[iop->fmt];
- if (fns)
+ if (fns) {
fns->free(iop);
+ module_put(fns->owner);
+ }
}
EXPORT_SYMBOL_GPL(free_io_pgtable_ops);
diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
index a460ae1..bdf0a01 100644
--- a/include/linux/io-pgtable.h
+++ b/include/linux/io-pgtable.h
@@ -168,10 +168,12 @@ struct io_pgtable_ops {
*
* @alloc: Allocate a set of page tables described by cfg.
* @free: Free the page tables associated with iop.
+ * @owner: Driver module providing these ops.
*/
struct io_pgtable_init_fns {
struct io_pgtable *(*alloc)(struct io_pgtable_cfg *cfg, void *cookie);
void (*free)(struct io_pgtable *iop);
+ struct module *owner;
};
/**
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu:fix IH overflow on Cz
Similar to commit ("drm/amdgpu: fix IH overflow on Vega10 v2")
When an ring buffer overflow happens the appropriate bit is set in the WPTR
register which is also written back to memory. But clearing the bit in the
WPTR doesn't trigger another memory writeback.
So what can happen is that we end up processing the buffer overflow over and
over again because the bit is never cleared. Resulting in a random system
lockup because of an infinite loop in an interrupt handler.
Signed-off-by: Defang Bo
---
drivers/gpu/drm/amd/amdgpu/cz_ih.c | 39 --
1 file changed, 25 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/cz_ih.c
b/drivers/gpu/drm/amd/amdgpu/cz_ih.c
index 1dca0cabc326..345987d45ff6 100644
--- a/drivers/gpu/drm/amd/amdgpu/cz_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/cz_ih.c
@@ -190,22 +190,33 @@ static u32 cz_ih_get_wptr(struct amdgpu_device *adev,
struct amdgpu_ih_ring *ih)
{
u32 wptr, tmp;
-
+
wptr = le32_to_cpu(*ih->wptr_cpu);
- if (REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW)) {
- wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
- /* When a ring buffer overflow happen start parsing interrupt
-* from the last not overwritten vector (wptr + 16). Hopefully
-* this should allow us to catchup.
-*/
- dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
- wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
- ih->rptr = (wptr + 16) & ih->ptr_mask;
- tmp = RREG32(mmIH_RB_CNTL);
- tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
- WREG32(mmIH_RB_CNTL, tmp);
- }
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+ wptr = WREG32(mmIH_RB_CNTL, tmp);
+
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+
+
+ wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
+ /* When a ring buffer overflow happen start parsing interrupt
+* from the last not overwritten vector (wptr + 16). Hopefully
+* this should allow us to catchup.
+*/
+ dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
+ wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
+ ih->rptr = (wptr + 16) & ih->ptr_mask;
+ tmp = RREG32(mmIH_RB_CNTL);
+ tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
+ WREG32(mmIH_RB_CNTL, tmp);
+
+
+out:
return (wptr & ih->ptr_mask);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4, 04/10] soc: mediatek: mmsys: Use function call for setting the routing registers
Actually, setting the registers for routing, use multiple 'if-else' for
different
routes, but this code would be more and more complicated while we
support more and more SoCs. Change that and use a function call per SoC so the
code will be more portable and clear.
Signed-off-by: Yongqiang Niu
---
drivers/soc/mediatek/mmsys/Makefile | 1 +
drivers/soc/mediatek/mmsys/mt2701-mmsys.c | 254
drivers/soc/mediatek/mmsys/mtk-mmsys.c| 266 +++---
include/linux/soc/mediatek/mtk-mmsys.h| 16 ++
4 files changed, 295 insertions(+), 242 deletions(-)
create mode 100644 drivers/soc/mediatek/mmsys/mt2701-mmsys.c
diff --git a/drivers/soc/mediatek/mmsys/Makefile
b/drivers/soc/mediatek/mmsys/Makefile
index f44eadc..ac03025 100644
--- a/drivers/soc/mediatek/mmsys/Makefile
+++ b/drivers/soc/mediatek/mmsys/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_MTK_MMSYS) += mt2701-mmsys.o
obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
diff --git a/drivers/soc/mediatek/mmsys/mt2701-mmsys.c
b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c
new file mode 100644
index 000..6bcc5f2
--- /dev/null
+++ b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c
@@ -0,0 +1,254 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: James Liao
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040
+#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044
+#define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048
+#define DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN 0x04c
+#define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050
+#define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084
+#define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088
+#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4
+#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8
+#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
+#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8
+#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4
+#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8
+#define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100
+
+#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030
+#define DISP_REG_CONFIG_OUT_SEL0x04c
+#define DISP_REG_CONFIG_DSI_SEL0x050
+#define DISP_REG_CONFIG_DPI_SEL0x064
+
+#define OVL0_MOUT_EN_COLOR00x1
+#define OD_MOUT_EN_RDMA0 0x1
+#define OD1_MOUT_EN_RDMA1 BIT(16)
+#define UFOE_MOUT_EN_DSI0 0x1
+#define COLOR0_SEL_IN_OVL0 0x1
+#define OVL1_MOUT_EN_COLOR10x1
+#define GAMMA_MOUT_EN_RDMA10x1
+#define RDMA0_SOUT_DPI00x2
+#define RDMA0_SOUT_DPI10x3
+#define RDMA0_SOUT_DSI10x1
+#define RDMA0_SOUT_DSI20x4
+#define RDMA0_SOUT_DSI30x5
+#define RDMA1_SOUT_DPI00x2
+#define RDMA1_SOUT_DPI10x3
+#define RDMA1_SOUT_DSI10x1
+#define RDMA1_SOUT_DSI20x4
+#define RDMA1_SOUT_DSI30x5
+#define RDMA2_SOUT_DPI00x2
+#define RDMA2_SOUT_DPI10x3
+#define RDMA2_SOUT_DSI10x1
+#define RDMA2_SOUT_DSI20x4
+#define RDMA2_SOUT_DSI30x5
+#define DPI0_SEL_IN_RDMA1 0x1
+#define DPI0_SEL_IN_RDMA2 0x3
+#define DPI1_SEL_IN_RDMA1 (0x1 << 8)
+#define DPI1_SEL_IN_RDMA2 (0x3 << 8)
+#define DSI0_SEL_IN_RDMA1 0x1
+#define DSI0_SEL_IN_RDMA2 0x4
+#define DSI1_SEL_IN_RDMA1 0x1
+#define DSI1_SEL_IN_RDMA2 0x4
+#define DSI2_SEL_IN_RDMA1 (0x1 << 16)
+#define DSI2_SEL_IN_RDMA2 (0x4 << 16)
+#define DSI3_SEL_IN_RDMA1 (0x1 << 16)
+#define DSI3_SEL_IN_RDMA2 (0x4 << 16)
+#define COLOR1_SEL_IN_OVL1 0x1
+
+#define OVL_MOUT_EN_RDMA 0x1
+#define BLS_TO_DSI_RDMA1_TO_DPI1 0x8
+#define BLS_TO_DPI_RDMA1_TO_DSI0x2
+#define DSI_SEL_IN_BLS 0x0
+#define DPI_SEL_IN_BLS 0x0
+#define DSI_SEL_IN_RDMA0x1
+
+static void mtk_mmsys_ddp_mout_en(void __iomem *config_regs,
+ enum mtk_ddp_comp_id cur,
+ enum mtk_ddp_comp_id next,
+ bool enable)
+{
+ unsi
[PATCH v4, 00/10] soc: mediatek: mmsys: Use function call for setting the routing registers
The following series are intended to prepare the mtk-mmsys driver to allow different DDP (Data Display Path) function call per SoC. base 5.11-rc1 change since v3: - move register operation into mmsys path select function Yongqiang Niu (10): soc: mediatek: mmsys: create mmsys folder soc: mediatek: mmsys: Create struct mtk_mmsys to store context data soc: mediatek: mmsys: move register operation into mmsys path select function soc: mediatek: mmsys: Use function call for setting the routing registers soc: mediatek: mmsys: add mt8183 function call for setting the routing registers soc: mediatek: mmsys: add component OVL_2L2 soc: mediatek: mmsys: add component POSTMASK soc: mediatek: mmsys: add component RDMA4 soc: mediatek: mmsys: Use function call for setting mmsys ovl mout register soc: mediatek: mmsys: add mt8192 mmsys support drivers/soc/mediatek/Makefile | 2 +- drivers/soc/mediatek/mmsys/Makefile | 5 + drivers/soc/mediatek/mmsys/mt2701-mmsys.c | 254 drivers/soc/mediatek/mmsys/mt8183-mmsys.c | 110 + drivers/soc/mediatek/mmsys/mt8192-mmsys.c | 149 drivers/soc/mediatek/mmsys/mtk-mmsys.c| 180 ++ drivers/soc/mediatek/mtk-mmsys.c | 373 -- include/linux/soc/mediatek/mtk-mmsys.h| 25 ++ 8 files changed, 724 insertions(+), 374 deletions(-) create mode 100644 drivers/soc/mediatek/mmsys/Makefile create mode 100644 drivers/soc/mediatek/mmsys/mt2701-mmsys.c create mode 100644 drivers/soc/mediatek/mmsys/mt8183-mmsys.c create mode 100644 drivers/soc/mediatek/mmsys/mt8192-mmsys.c create mode 100644 drivers/soc/mediatek/mmsys/mtk-mmsys.c delete mode 100644 drivers/soc/mediatek/mtk-mmsys.c -- 1.8.1.1.dirty ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 6/7] drm/panfrost: Add dependency on io-pgtable-arm format module
The Panfrost DRM driver depends on the availability of the ARM LPAE
io-pgtable format code to work properly. In preparation for having the
io-pgtable formats as modules, add a "pre" dependency with
MODULE_SOFTDEP() to ensure that the io-pgtable-arm format module is loaded
before loading the Panfrost DRM driver module.
Signed-off-by: Isaac J. Manjarres
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 83a461b..7294622 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -704,3 +704,4 @@ module_platform_driver(panfrost_driver);
MODULE_AUTHOR("Panfrost Project Developers");
MODULE_DESCRIPTION("Panfrost DRM Driver");
MODULE_LICENSE("GPL v2");
+MODULE_SOFTDEP("pre: io-pgtable-arm");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 7/7] iommu/io-pgtable-arm: Allow building modular io-pgtable formats
Now that everything is in place for modular io-pgtable formats,
allow the ARM LPAE and ARMV7S io-pgtable formats to be built
as modules, and allow the io-pgtable framework to be enabled,
without having to explicitly enable an io-pgtable format.
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/Kconfig | 11 +++
drivers/iommu/io-pgtable-arm-v7s.c | 2 ++
drivers/iommu/io-pgtable-arm.c | 2 ++
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 192ef8f..d3c4e9a 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -25,12 +25,15 @@ if IOMMU_SUPPORT
menu "Generic IOMMU Pagetable Support"
-# Selected by the actual pagetable implementations
config IOMMU_IO_PGTABLE
- bool
+ bool "IOMMU Pagetable support"
+ help
+ Enable support for using IOMMU pagetables. This option enables
+ the generic IOMMU pagetable framework for registering IOMMU
+ pagetable formats, as well as managing IOMMU pagetable instances.
config IOMMU_IO_PGTABLE_LPAE
- bool "ARMv7/v8 Long Descriptor Format"
+ tristate "ARMv7/v8 Long Descriptor Format"
select IOMMU_IO_PGTABLE
depends on ARM || ARM64 || (COMPILE_TEST && !GENERIC_ATOMIC64)
help
@@ -49,7 +52,7 @@ config IOMMU_IO_PGTABLE_LPAE_SELFTEST
If unsure, say N here.
config IOMMU_IO_PGTABLE_ARMV7S
- bool "ARMv7/v8 Short Descriptor Format"
+ tristate "ARMv7/v8 Short Descriptor Format"
select IOMMU_IO_PGTABLE
depends on ARM || ARM64 || COMPILE_TEST
help
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index 7e81135..69dbf86 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -1014,3 +1014,5 @@ static void __exit arm_v7s_exit(void)
io_pgtable_ops_unregister(ARM_V7S);
}
module_exit(arm_v7s_exit);
+
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 8ed52a0..8d4805f 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -1306,3 +1306,5 @@ static void __exit arm_lpae_exit(void)
io_pgtable_ops_unregister(arm_lpae_init_fns_table[i].fmt);
}
module_exit(arm_lpae_exit);
+
+MODULE_LICENSE("GPL v2");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4, 08/10] soc: mediatek: mmsys: add component RDMA4
This patch add component RDMA4
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
---
include/linux/soc/mediatek/mtk-mmsys.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
b/include/linux/soc/mediatek/mtk-mmsys.h
index 13546e9..2c11617 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -38,6 +38,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_RDMA0,
DDP_COMPONENT_RDMA1,
DDP_COMPONENT_RDMA2,
+ DDP_COMPONENT_RDMA4,
DDP_COMPONENT_UFOE,
DDP_COMPONENT_WDMA0,
DDP_COMPONENT_WDMA1,
--
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 3/4] drm/panfrost: devfreq: Disable devfreq when num_supplies > 1
> GPUs with more than a single regulator (e.g. G-57 on MT8183) will G72 signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] arm64: dts: mt8192: Add node for the Mali GPU
Add a basic GPU node for mt8192.
Signed-off-by: Nick Fan
---
This patch depends on Mediatek power and regulator support.
Listed as following.
[1]https://lore.kernel.org/patchwork/patch/1336293/
[2]https://patchwork.kernel.org/project/linux-mediatek/list/?series=374013
[3]https://lore.kernel.org/patchwork/patch/1356037/
[4]https://patchwork.kernel.org/project/linux-mediatek/list/?series=405777
[5]https://lore.kernel.org/patchwork/patch/1356175/
[6]https://patchwork.kernel.org/project/linux-mediatek/patch/1605700894-32699-6-git-send-email-hsin-hsiung.w...@mediatek.com/
[7]https://patchwork.kernel.org/project/linux-mediatek/patch/1608104827-7937-10-git-send-email-hsin-hsiung.w...@mediatek.com/
---
---
arch/arm64/boot/dts/mediatek/mt8192-evb.dts | 7 +
arch/arm64/boot/dts/mediatek/mt8192.dtsi| 176
2 files changed, 183 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
index 6c1e2b3e8a60..48c0e240dd92 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8192-evb.dts
@@ -5,6 +5,7 @@
*/
/dts-v1/;
#include "mt8192.dtsi"
+#include "mt6359.dtsi"
/ {
model = "MediaTek MT8192 evaluation board";
@@ -70,6 +71,12 @@
};
};
+&gpu {
+ supply-names = "mali","sram";
+ mali-supply = <&mt6315_7_vbuck1>;
+ sram-supply = <&mt6359_vsram_others_ldo_reg>;
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index d6a4ad242a33..de166ea750af 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -822,6 +822,182 @@
#clock-cells = <1>;
};
+ gpu: mali@1300 {
+ compatible = "mediatek,mt8192-mali", "arm,mali-valhall";
+ reg = <0 0x1300 0 0x4000>;
+ interrupts =
+ ,
+ ,
+ ,
+ ,
+ ;
+ interrupt-names =
+ "GPU",
+ "MMU",
+ "JOB",
+ "EVENT",
+ "PWR";
+
+ clocks =
+ <&apmixedsys CLK_APMIXED_MFGPLL>,
+ <&topckgen CLK_TOP_MFG_PLL_SEL>,
+ <&topckgen CLK_TOP_MFG_REF_SEL>,
+ <&mfgcfg CLK_MFG_BG3D>;
+ clock-names =
+ "clk_main_parent",
+ "clk_mux",
+ "clk_sub_parent",
+ "subsys_mfg_cg";
+
+ power-domains =
+ <&scpsys MT8192_POWER_DOMAIN_MFG2>,
+ <&scpsys MT8192_POWER_DOMAIN_MFG3>,
+ <&scpsys MT8192_POWER_DOMAIN_MFG4>,
+ <&scpsys MT8192_POWER_DOMAIN_MFG5>,
+ <&scpsys MT8192_POWER_DOMAIN_MFG6>;
+ power-domain-names = "core0",
+"core1",
+"core2",
+"core3",
+"core4";
+
+ operating-points-v2 = <&gpu_opp_table>;
+ #cooling-cells = <2>;
+ };
+
+ gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-35800 {
+ opp-hz = /bits/ 64 <35800>;
+ opp-hz-real = /bits/ 64 <35800>,
+ /bits/ 64 <35800>;
+ opp-microvolt = <606250>,
+ <75>;
+ };
+
+ opp-39900 {
+ opp-hz = /bits/ 64 <39900>;
+ opp-hz-real = /bits/ 64 <39900>,
+ /bits/ 64 <39900>;
+ opp-microvolt = <618750>,
+ <75>;
+ };
+
+ opp-44000 {
+ opp-hz = /bits/ 64 <44000>;
+ opp-hz-real = /bits/ 64 <44000>,
+ /bits/ 64 <44000>;
+ opp-microvolt = <631250>,
+ <75>;
+
[PATCH RESEND 0/7] iommu: Permit modular builds of io-pgtable drivers
The goal of the Generic Kernel Image (GKI) effort is to have a common kernel image that works across multiple Android devices. This involves generating a kernel image that has core features integrated into it, while SoC specific functionality can be added to the kernel for the device as a module. Along with modularizing IOMMU drivers, this also means building the io-pgtable code as modules, which allows for SoC vendors to only include the io-pgtable implementations that they use. For example, GKI for arm64 must include support for both the IOMMU ARM LPAE/V7S formats at the moment. Having the code for both formats as modules allows SoC vendors to only provide the page table format that they use, along with their IOMMU driver. The patches are split into 4 parts: 1) Modularizing io-pgtable-arm[-v7s].c, while leaving the io-pgtable.c code as part of the core kernel, requires removing the references to the ARM LPAE and ARM V7S io-pgtable init functions, and using a dynamic method for formats to register their io-pgtable init functions. 2) Taking references to the io-pgtable format drivers to ensure that they cannot be unloaded while in use. 3) Adding pre MODULE_SOFTDEP() dependencies to drivers in the kernel that are tristate, and invoke [alloc/free]_io_pgtable_ops(). This makes it so that the io-pgtable format drivers are loaded before the driver that needs them. 4) Changing the Kconfig options for the ARM LPAE nad ARM V7S to tristate and allowing the io-pgtable code to be enabled without having to select either page table format. The reason for doing this is so that a kernel can be built, such that it only provides the interface for io-pgtable formats to be registered as modules, as would be the case for the GKI. Thanks, Isaac Isaac J. Manjarres (7): iommu/io-pgtable: Introduce dynamic io-pgtable format registration iommu/io-pgtable: Add refcounting for io-pgtable format modules iommu/arm-smmu: Add dependency on io-pgtable format modules iommu/arm-smmu-v3: Add dependency on io-pgtable-arm format module drm/msm: Add dependency on io-pgtable-arm format module drm/panfrost: Add dependency on io-pgtable-arm format module iommu/io-pgtable-arm: Allow building modular io-pgtable formats drivers/gpu/drm/msm/msm_drv.c | 1 + drivers/gpu/drm/panfrost/panfrost_drv.c | 1 + drivers/iommu/Kconfig | 11 +-- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 + drivers/iommu/arm/arm-smmu/arm-smmu.c | 1 + drivers/iommu/io-pgtable-arm-v7s.c | 36 +- drivers/iommu/io-pgtable-arm.c | 104 +--- drivers/iommu/io-pgtable.c | 54 ++- include/linux/io-pgtable.h | 52 +- 9 files changed, 196 insertions(+), 65 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 4/4] drm/panfrost: Add mt8183-mali compatible string
> Add support for MT8183's G-57 Bifrost. G72 signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: amdgpu does not support 3840x2160@30Hz on kaveri apu
Hello. This resolution is supported by the Apu and the motherboard specs. Will try what you suggest and let you know Il Lun 4 Gen 2021, 12:10 Christian König ha scritto: > Hi Davide, > > adding a few of our AMD display people. > > In general as already suggested by others opening a bug report to track > this is the right thing to do. > > In the past we had a few bug reports like this because amdgpu is more > strict in checking hardware limitations. > > For example it can be that your HDMI port on the board can only handle a > certain maximum pixel clock, but radeon is ignoring this while amdgpu isn't. > > What you can try to do is to manually override the used mode, e.g. copy > the modeline used when radeon is active and manually add that using xrandr > when amdgpu is active and see if it works or not. > > Regards, > Christian. > > Am 02.01.21 um 19:50 schrieb Davide Corrado: > > hello, I'd like to report this issue that I am having since I updated my > display (samsung U28E590). The amdgpu does not support the native > resolution of my new monitor, which is 3840x2160*.* Using a HDMI or DVI > connection (I tried both, same results), the maximum supported refresh is > 30Hz, so I'm stuck with that (don't have a displayport). The radeon module > works fine, I'm having this issue just when I use amdgpu (which I'd like > to, because performance is better). > > Some info of my hardware: > > cpu: AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G > kernel version (I tried different ones and different linux distros, same > results!): 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 2020 > x86_64 x86_64 x86_64 GNU/Linux > Monitor: Samsung U28E590. > > description: > If I boot the system using amdgpu and no video mode selection, the system > boots but I don't get a screen during boot and in wayland. I can connect > using ssh, so the system is running fine, just no display; If I force a > full HD resolution with "video:" in the kernel line, I can see the boot > process but the screen disappears when wayland starts (because the default > resolution is 3840x2160@30Hz). Using a full HD monitor results in no > issues, so it must be related to this very 4k resolution. > > As I have already stated, radeon module works with the same > software/hardware configuration. > thanks you so much for your time :-) > > -- > Davide Corrado > UNIX Team Leader > > Via Abramo Lincoln, 25 > 20129 Milano > > Tel +39 3474259950 > > ___ > amd-gfx mailing > listamd-gfx@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/amd-gfx > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2] drm/bridge/tc358775: Fixes bus formats read
Laurent,
Please review the patch, so that we can push the input_format to the
mainline, which completes the overall features handled wrt bridge.
On Thu, Dec 17, 2020 at 10:39 AM Vinay Simha B N wrote:
> Laurent,
>
> Please review the patch, so that we can push the input_format to the
> mainline, which completes the overall features handled wrt bridge.
>
> On Sun, Nov 8, 2020 at 3:47 PM Sam Ravnborg wrote:
>
>> Hi Laurent,
>>
>> On Thu, Oct 22, 2020 at 12:15:47PM +0530, Vinay Simha BN wrote:
>> > - atomic_check removed
>> > - video data input and output formats added
>> > - bus formats read from drm_bridge_state.output_bus_cfg.format
>> > and .atomic_get_input_bus_fmts() instead of connector
>> >
>> > Signed-off-by: Vinay Simha BN
>>
>> could you try to find time to review this patch?
>>
>> You already provided valuable feedback and it looks fine to me.
>> But it would be perfect if you could find time to take a look.
>>
>> Thanks in advance,
>>
>> Sam
>>
>> >
>> > ---
>> > v1:
>> > * Laurent Pinchart review comments incorporated
>> >drm_bridge_state.output_bus_cfg.format
>> >instead of connector
>> > v2:
>> > * Laurent Pinchart review comments incorporated
>> >atomic_check removed
>> >video data input and output formats added
>> > ---
>> > drivers/gpu/drm/bridge/tc358775.c | 75
>> ++-
>> > 1 file changed, 58 insertions(+), 17 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/bridge/tc358775.c
>> b/drivers/gpu/drm/bridge/tc358775.c
>> > index 2272adc..cc27570 100644
>> > --- a/drivers/gpu/drm/bridge/tc358775.c
>> > +++ b/drivers/gpu/drm/bridge/tc358775.c
>> > @@ -271,6 +271,20 @@ struct tc_data {
>> > struct gpio_desc*stby_gpio;
>> > u8 lvds_link; /* single-link or dual-link */
>> > u8 bpc;
>> > + u32 output_bus_fmt;
>> > +};
>> > +
>> > +static const u32 tc_lvds_in_bus_fmts[] = {
>> > + MEDIA_BUS_FMT_RGB565_1X16,
>> > + MEDIA_BUS_FMT_RGB666_1X18,
>> > + MEDIA_BUS_FMT_RGB666_1X24_CPADHI,
>> > + MEDIA_BUS_FMT_RBG888_1X24,
>> > +};
>> > +
>> > +static const u32 tc_lvds_out_bus_fmts[] = {
>> > + MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
>> > + MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
>> > + MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
>> > };
>> >
>> > static inline struct tc_data *bridge_to_tc(struct drm_bridge *b)
>> > @@ -359,19 +373,6 @@ static void d2l_write(struct i2c_client *i2c, u16
>> addr, u32 val)
>> > ret, addr);
>> > }
>> >
>> > -/* helper function to access bus_formats */
>> > -static struct drm_connector *get_connector(struct drm_encoder *encoder)
>> > -{
>> > - struct drm_device *dev = encoder->dev;
>> > - struct drm_connector *connector;
>> > -
>> > - list_for_each_entry(connector, &dev->mode_config.connector_list,
>> head)
>> > - if (connector->encoder == encoder)
>> > - return connector;
>> > -
>> > - return NULL;
>> > -}
>> > -
>> > static void tc_bridge_enable(struct drm_bridge *bridge)
>> > {
>> > struct tc_data *tc = bridge_to_tc(bridge);
>> > @@ -380,7 +381,10 @@ static void tc_bridge_enable(struct drm_bridge
>> *bridge)
>> > u32 val = 0;
>> > u16 dsiclk, clkdiv, byteclk, t1, t2, t3, vsdelay;
>> > struct drm_display_mode *mode;
>> > - struct drm_connector *connector = get_connector(bridge->encoder);
>> > + struct drm_bridge_state *state =
>> > + drm_priv_to_bridge_state(bridge->base.state);
>> > +
>> > + tc->output_bus_fmt = state->output_bus_cfg.format;
>> >
>> > mode = &bridge->encoder->crtc->state->adjusted_mode;
>> >
>> > @@ -451,14 +455,13 @@ static void tc_bridge_enable(struct drm_bridge
>> *bridge)
>> > d2l_write(tc->i2c, LVPHY0, LV_PHY0_PRBS_ON(4) | LV_PHY0_ND(6));
>> >
>> > dev_dbg(tc->dev, "bus_formats %04x bpc %d\n",
>> > - connector->display_info.bus_formats[0],
>> > + tc->output_bus_fmt,
>> > tc->bpc);
>> > /*
>> >* Default hardware register settings of tc358775 configured
>> >* with MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA jeida-24 format
>> >*/
>> > - if (connector->display_info.bus_formats[0] ==
>> > - MEDIA_BUS_FMT_RGB888_1X7X4_SPWG) {
>> > + if (tc->output_bus_fmt == MEDIA_BUS_FMT_RGB888_1X7X4_SPWG) {
>> > /* VESA-24 */
>> > d2l_write(tc->i2c, LV_MX0003, LV_MX(LVI_R0, LVI_R1,
>> LVI_R2, LVI_R3));
>> > d2l_write(tc->i2c, LV_MX0407, LV_MX(LVI_R4, LVI_R7,
>> LVI_R5, LVI_G0));
>> > @@ -590,6 +593,40 @@ static int tc358775_parse_dt(struct device_node
>> *np, struct tc_data *tc)
>> > return 0;
>> > }
>> >
>> > +static u32 *
>> > +tc_bridge_get_input_bus_fmts(struct drm_bridge *bridge,
>> > + struct drm_bridge_state *bridge_state,
>> > + struct drm_crtc_state *crtc_state,
>> > +
[PATCH RESEND 4/7] iommu/arm-smmu-v3: Add dependency on io-pgtable-arm format module
The SMMUv3 driver depends on the availability of the ARM LPAE io-pgtable
format code to work properly. In preparation for having the io-pgtable
formats as modules, add a "pre" dependency with MODULE_SOFTDEP() to
ensure that the io-pgtable-arm format module is loaded before loading
the ARM SMMUv3 driver module.
Signed-off-by: Isaac J. Manjarres
---
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index 8ca7415..c498ac8 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -3650,3 +3650,4 @@ MODULE_DESCRIPTION("IOMMU API for ARM architected SMMUv3
implementations");
MODULE_AUTHOR("Will Deacon ");
MODULE_ALIAS("platform:arm-smmu-v3");
MODULE_LICENSE("GPL v2");
+MODULE_SOFTDEP("pre: io-pgtable-arm");
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/amdgpu:fix IH overflow on Cz
Similar to commit ("drm/amdgpu: fix IH overflow on Vega10 v2").
When an ring buffer overflow happens the appropriate bit is set in the WPTR
register which is also written back to memory. But clearing the bit in the
WPTR doesn't trigger another memory writeback.
So what can happen is that we end up processing the buffer overflow over and
over again because the bit is never cleared. Resulting in a random system
lockup because of an infinite loop in an interrupt handler.
Signed-off-by: Defang Bo
---
Changes since v1:
- Modify the code and correct the wrong fix.
---
---
drivers/gpu/drm/amd/amdgpu/cz_ih.c | 38 --
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/cz_ih.c
b/drivers/gpu/drm/amd/amdgpu/cz_ih.c
index 1dca0cabc326..45dd47f45fa2 100644
--- a/drivers/gpu/drm/amd/amdgpu/cz_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/cz_ih.c
@@ -190,22 +190,32 @@ static u32 cz_ih_get_wptr(struct amdgpu_device *adev,
struct amdgpu_ih_ring *ih)
{
u32 wptr, tmp;
-
+
wptr = le32_to_cpu(*ih->wptr_cpu);
- if (REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW)) {
- wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
- /* When a ring buffer overflow happen start parsing interrupt
-* from the last not overwritten vector (wptr + 16). Hopefully
-* this should allow us to catchup.
-*/
- dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
- wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
- ih->rptr = (wptr + 16) & ih->ptr_mask;
- tmp = RREG32(mmIH_RB_CNTL);
- tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
- WREG32(mmIH_RB_CNTL, tmp);
- }
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+ wptr = RREG32(mmIH_RB_CNTL);
+
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+ wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
+
+ /* When a ring buffer overflow happen start parsing interrupt
+* from the last not overwritten vector (wptr + 16). Hopefully
+* this should allow us to catchup.
+*/
+ dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
+ wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
+ ih->rptr = (wptr + 16) & ih->ptr_mask;
+ tmp = RREG32(mmIH_RB_CNTL);
+ tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
+ WREG32(mmIH_RB_CNTL, tmp);
+
+
+out:
return (wptr & ih->ptr_mask);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4, 05/10] soc: mediatek: mmsys: add mt8183 function call for setting the routing registers
add mt8183 function call for setting the routing registers
Signed-off-by: Yongqiang Niu
---
drivers/soc/mediatek/mmsys/Makefile | 1 +
drivers/soc/mediatek/mmsys/mt8183-mmsys.c | 110 ++
drivers/soc/mediatek/mmsys/mtk-mmsys.c| 1 +
include/linux/soc/mediatek/mtk-mmsys.h| 1 +
4 files changed, 113 insertions(+)
create mode 100644 drivers/soc/mediatek/mmsys/mt8183-mmsys.c
diff --git a/drivers/soc/mediatek/mmsys/Makefile
b/drivers/soc/mediatek/mmsys/Makefile
index ac03025..25eeb9e5 100644
--- a/drivers/soc/mediatek/mmsys/Makefile
+++ b/drivers/soc/mediatek/mmsys/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_MTK_MMSYS) += mt2701-mmsys.o
+obj-$(CONFIG_MTK_MMSYS) += mt8183-mmsys.o
obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
diff --git a/drivers/soc/mediatek/mmsys/mt8183-mmsys.c
b/drivers/soc/mediatek/mmsys/mt8183-mmsys.c
new file mode 100644
index 000..8311f89
--- /dev/null
+++ b/drivers/soc/mediatek/mmsys/mt8183-mmsys.c
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2020 MediaTek Inc.
+
+#include
+#include
+#include
+#include
+#include
+
+#define DISP_OVL0_MOUT_EN 0xf00
+#define DISP_OVL0_2L_MOUT_EN 0xf04
+#define DISP_OVL1_2L_MOUT_EN 0xf08
+#define DISP_DITHER0_MOUT_EN 0xf0c
+#define DISP_PATH0_SEL_IN 0xf24
+#define DISP_DSI0_SEL_IN 0xf2c
+#define DISP_DPI0_SEL_IN 0xf30
+#define DISP_RDMA0_SOUT_SEL_IN 0xf50
+#define DISP_RDMA1_SOUT_SEL_IN 0xf54
+
+#define OVL0_MOUT_EN_OVL0_2L BIT(4)
+#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
+#define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
+#define DITHER0_MOUT_IN_DSI0 BIT(0)
+#define DISP_PATH0_SEL_IN_OVL0_2L 0x1
+#define DSI0_SEL_IN_RDMA0 0x1
+#define DSI0_SEL_IN_RDMA1 0x3
+#define DPI0_SEL_IN_RDMA0 0x1
+#define DPI0_SEL_IN_RDMA1 0x2
+#define RDMA0_SOUT_COLOR0 0x1
+#define RDMA1_SOUT_DSI00x1
+
+static void mtk_mmsys_ddp_mout_en(void __iomem *config_regs,
+ enum mtk_ddp_comp_id cur,
+ enum mtk_ddp_comp_id next,
+ bool enable)
+{
+ unsigned int addr, value, reg;
+
+ if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_OVL_2L0) {
+ addr = DISP_OVL0_MOUT_EN;
+ value = OVL0_MOUT_EN_OVL0_2L;
+ } else if (cur == DDP_COMPONENT_OVL_2L0 && next == DDP_COMPONENT_RDMA0)
{
+ addr = DISP_OVL0_2L_MOUT_EN;
+ value = OVL0_2L_MOUT_EN_DISP_PATH0;
+ } else if (cur == DDP_COMPONENT_OVL_2L1 && next == DDP_COMPONENT_RDMA1)
{
+ addr = DISP_OVL1_2L_MOUT_EN;
+ value = OVL1_2L_MOUT_EN_RDMA1;
+ } else if (cur == DDP_COMPONENT_DITHER && next == DDP_COMPONENT_DSI0) {
+ addr = DISP_DITHER0_MOUT_EN;
+ value = DITHER0_MOUT_IN_DSI0;
+ } else {
+ value = 0;
+ }
+
+ if (value) {
+ reg = readl_relaxed(config_regs + addr);
+
+ if (enable)
+ reg |= value;
+ else
+ reg &= ~value;
+
+ writel_relaxed(reg, config_regs + addr);
+ }
+}
+
+static void mtk_mmsys_ddp_sel_in(void __iomem *config_regs,
+enum mtk_ddp_comp_id cur,
+enum mtk_ddp_comp_id next,
+bool enable)
+{
+ unsigned int addr, value, reg;
+
+ if (cur == DDP_COMPONENT_OVL_2L0 && next == DDP_COMPONENT_RDMA0) {
+ addr = DISP_PATH0_SEL_IN;
+ value = DISP_PATH0_SEL_IN_OVL0_2L;
+ } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
+ addr = DISP_DPI0_SEL_IN;
+ value = DPI0_SEL_IN_RDMA1;
+ } else {
+ value = 0;
+ }
+
+ if (value) {
+ reg = readl_relaxed(config_regs + addr);
+
+ if (enable)
+ reg |= value;
+ else
+ reg &= ~value;
+
+ writel_relaxed(reg, config_regs + addr);
+ }
+}
+
+static void mtk_mmsys_ddp_sout_sel(void __iomem *config_regs,
+ enum mtk_ddp_comp_id cur,
+ enum mtk_ddp_comp_id next)
+{
+ if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_COLOR0) {
+ writel_relaxed(RDMA0_SOUT_COLOR0, config_regs +
DISP_RDMA0_SOUT_SEL_IN);
+ }
+}
+
+struct mtk_mmsys_conn_funcs mt8183_mmsys_funcs = {
+ .mout_en = mtk_mmsys_ddp_mout_en,
+ .sel_in = mtk_mmsys_ddp_sel_in,
+ .sout_sel = mtk_mmsys_ddp_sout_sel,
+};
diff --git a/drivers/soc/mediat
[PATCH] drm/amdgpu:fix IH overflow on Tonga
Similar to commit ("drm/amdgpu: fix IH overflow on Vega10 v2").
When an ring buffer overflow happens the appropriate bit is set in the WPTR
register which is also written back to memory. But clearing the bit in the
WPTR doesn't trigger another memory writeback.
So what can happen is that we end up processing the buffer overflow over and
over again because the bit is never cleared. Resulting in a random system
lockup because of an infinite loop in an interrupt handler.
Signed-off-by: Defang Bo
---
drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 35 ++-
1 file changed, 22 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
b/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
index e40140bf6699..9c5947976717 100644
--- a/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/tonga_ih.c
@@ -195,19 +195,28 @@ static u32 tonga_ih_get_wptr(struct amdgpu_device *adev,
wptr = le32_to_cpu(*ih->wptr_cpu);
- if (REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW)) {
- wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
- /* When a ring buffer overflow happen start parsing interrupt
-* from the last not overwritten vector (wptr + 16). Hopefully
-* this should allow us to catchup.
-*/
- dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
-wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
- ih->rptr = (wptr + 16) & ih->ptr_mask;
- tmp = RREG32(mmIH_RB_CNTL);
- tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
- WREG32(mmIH_RB_CNTL, tmp);
- }
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+ wptr = RREG32(mmIH_RB_CNTL);
+
+ if (!REG_GET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW))
+ goto out;
+
+ wptr = REG_SET_FIELD(wptr, IH_RB_WPTR, RB_OVERFLOW, 0);
+
+ /* When a ring buffer overflow happen start parsing interrupt
+* from the last not overwritten vector (wptr + 16). Hopefully
+* this should allow us to catchup.
+*/
+ dev_warn(adev->dev, "IH ring buffer overflow (0x%08X, 0x%08X,
0x%08X)\n",
+ wptr, ih->rptr, (wptr + 16) & ih->ptr_mask);
+ ih->rptr = (wptr + 16) & ih->ptr_mask;
+ tmp = RREG32(mmIH_RB_CNTL);
+ tmp = REG_SET_FIELD(tmp, IH_RB_CNTL, WPTR_OVERFLOW_CLEAR, 1);
+ WREG32(mmIH_RB_CNTL, tmp);
+
+out:
return (wptr & ih->ptr_mask);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: Only enable A6xx LLCC code on A6xx
Using this code on A5xx (and probably older too) causes a
smmu bug.
Fixes: 474dadb8b0d5 ("drm/msm/a6xx: Add support for using system cache(LLC)")
Signed-off-by: Konrad Dybcio
Tested-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 21 -
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 +
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 6cf9975e951e..f09175698827 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -191,8 +191,6 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
struct platform_device *pdev)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
- struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
- struct io_pgtable_domain_attr pgtbl_cfg;
struct iommu_domain *iommu;
struct msm_mmu *mmu;
struct msm_gem_address_space *aspace;
@@ -202,13 +200,18 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
if (!iommu)
return NULL;
- /*
-* This allows GPU to set the bus attributes required to use system
-* cache on behalf of the iommu page table walker.
-*/
- if (!IS_ERR(a6xx_gpu->htw_llc_slice)) {
- pgtbl_cfg.quirks = IO_PGTABLE_QUIRK_ARM_OUTER_WBWA;
- iommu_domain_set_attr(iommu, DOMAIN_ATTR_IO_PGTABLE_CFG,
&pgtbl_cfg);
+
+ if (adreno_is_a6xx(adreno_gpu)) {
+ struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
+ struct io_pgtable_domain_attr pgtbl_cfg;
+ /*
+ * This allows GPU to set the bus attributes required to use
system
+ * cache on behalf of the iommu page table walker.
+ */
+ if (!IS_ERR(a6xx_gpu->htw_llc_slice)) {
+ pgtbl_cfg.quirks = IO_PGTABLE_QUIRK_ARM_OUTER_WBWA;
+ iommu_domain_set_attr(iommu,
DOMAIN_ATTR_IO_PGTABLE_CFG, &pgtbl_cfg);
+ }
}
mmu = msm_iommu_new(&pdev->dev, iommu);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 4574d85c5680..08421fa54a50 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -226,6 +226,11 @@ static inline int adreno_is_a540(struct adreno_gpu *gpu)
return gpu->revn == 540;
}
+static inline bool adreno_is_a6xx(struct adreno_gpu *gpu)
+{
+ return ((gpu->revn < 700 && gpu->revn > 599));
+}
+
static inline int adreno_is_a618(struct adreno_gpu *gpu)
{
return gpu->revn == 618;
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8, 5/6] drm/mediatek: add RDMA fifo size error handle
On Mon, 2020-12-14 at 22:54 +0800, Chun-Kuang Hu wrote: > Hi, Yongqiang: > > Yongqiang Niu 於 2020年12月11日 週五 上午8:45寫道： > > > > On Thu, 2020-12-10 at 23:50 +0800, Chun-Kuang Hu wrote: > > > Hi, Yongqiang: > > > > > > Yongqiang Niu 於 2020年12月10日 週四 下午5:08寫道： > > > > > > > > This patch add RDMA fifo size error handle > > > > rdma fifo size will not always bigger than the calculated threshold > > > > if that case happened, we need set fifo size as the threshold > > > > > > > > Signed-off-by: Yongqiang Niu > > > > --- > > > > drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 4 > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > > > > b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > > > > index 794acc5..0508392 100644 > > > > --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > > > > +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c > > > > @@ -151,6 +151,10 @@ static void mtk_rdma_config(struct mtk_ddp_comp > > > > *comp, unsigned int width, > > > > * account for blanking, and with a pixel depth of 4 bytes: > > > > */ > > > > threshold = width * height * vrefresh * 4 * 7 / 100; > > > > + > > > > + if (threshold > rdma_fifo_size) > > > > + threshold = rdma_fifo_size; > > > > > > If the formula is not correct, you should fix the formula not work around. > > > > > > Regards, > > > Chun-Kuang. > > > > how about this: > > threshold = max(width * height * vrefresh * 4 * 7 / 100, > > rdma_fifo_size); > > When I use width = 1920, height = 1080, vrefresh = 60 to calculate, I > get threshold = 2985. > So I think set threshold to half of fifo size is OK for MAX_WIDTH, > MAX_HEIGHT, MAX_VREFRESH (these three may be different in each SoC) > > threshold = RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) / 2; > > But I worry half fifo size is too big for small resolution and let > small resolution too easy to trigger burst read DRAM. So let the > formula to be this: > > threshold = RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) * width * height * > vrefresh / 2 / MAX_WIDTH / MAX_HEIGHT / MAX_VREFRESH; > > How do you think about this? > > Regards, > Chun-Kuang. how about remove this formula, and set threshold = rdma_fifo_size > > > > > > > > + > > > > reg = RDMA_FIFO_UNDERFLOW_EN | > > > > RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) | > > > > RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold); > > > > -- > > > > 1.8.1.1.dirty > > > > ___ > > > > Linux-mediatek mailing list > > > > linux-media...@lists.infradead.org > > > > http://lists.infradead.org/mailman/listinfo/linux-mediatek > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4, 06/10] soc: mediatek: mmsys: add component OVL_2L2
This patch add component OVL_2L2
Signed-off-by: Yongqiang Niu
Reviewed-by: Chun-Kuang Hu
---
include/linux/soc/mediatek/mtk-mmsys.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/soc/mediatek/mtk-mmsys.h
b/include/linux/soc/mediatek/mtk-mmsys.h
index 7e2c0fe..ed99122 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -29,6 +29,7 @@ enum mtk_ddp_comp_id {
DDP_COMPONENT_OVL0,
DDP_COMPONENT_OVL_2L0,
DDP_COMPONENT_OVL_2L1,
+ DDP_COMPONENT_OVL_2L2,
DDP_COMPONENT_OVL1,
DDP_COMPONENT_PWM0,
DDP_COMPONENT_PWM1,
--
1.8.1.1.dirty
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4, 10/10] soc: mediatek: mmsys: add mt8192 mmsys support
add mt8192 mmsys support
Signed-off-by: Yongqiang Niu
---
drivers/soc/mediatek/mmsys/Makefile | 1 +
drivers/soc/mediatek/mmsys/mt8192-mmsys.c | 149 ++
drivers/soc/mediatek/mmsys/mtk-mmsys.c| 9 ++
include/linux/soc/mediatek/mtk-mmsys.h| 1 +
4 files changed, 160 insertions(+)
create mode 100644 drivers/soc/mediatek/mmsys/mt8192-mmsys.c
diff --git a/drivers/soc/mediatek/mmsys/Makefile
b/drivers/soc/mediatek/mmsys/Makefile
index 25eeb9e5..7508cd3 100644
--- a/drivers/soc/mediatek/mmsys/Makefile
+++ b/drivers/soc/mediatek/mmsys/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
obj-$(CONFIG_MTK_MMSYS) += mt2701-mmsys.o
obj-$(CONFIG_MTK_MMSYS) += mt8183-mmsys.o
+obj-$(CONFIG_MTK_MMSYS) += mt8192-mmsys.o
obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
diff --git a/drivers/soc/mediatek/mmsys/mt8192-mmsys.c
b/drivers/soc/mediatek/mmsys/mt8192-mmsys.c
new file mode 100644
index 000..2e350d1
--- /dev/null
+++ b/drivers/soc/mediatek/mmsys/mt8192-mmsys.c
@@ -0,0 +1,149 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2020 MediaTek Inc.
+
+#include
+#include
+#include
+#include
+#include
+
+#define MMSYS_OVL_MOUT_EN 0xf04
+#define DISP_OVL0_GO_BLEND BIT(0)
+#define DISP_OVL0_GO_BGBIT(1)
+#define DISP_OVL0_2L_GO_BLEND BIT(2)
+#define DISP_OVL0_2L_GO_BG BIT(3)
+#define DISP_OVL1_2L_MOUT_EN 0xf08
+#define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
+#define DISP_OVL0_2L_MOUT_EN 0xf18
+#define DISP_OVL0_MOUT_EN 0xf1c
+#define OVL0_MOUT_EN_DISP_RDMA0BIT(0)
+#define OVL0_MOUT_EN_OVL0_2L BIT(4)
+#define DISP_RDMA0_SEL_IN 0xf2c
+#define RDMA0_SEL_IN_OVL0_2L 0x3
+#define DISP_RDMA0_SOUT_SEL0xf30
+#define RDMA0_SOUT_COLOR0 0x1
+#define DISP_CCORR0_SOUT_SEL 0xf34
+#define CCORR0_SOUT_AAL0 0x1
+#define DISP_AAL0_SEL_IN 0xf38
+#define AAL0_SEL_IN_CCORR0 0x1
+#define DISP_DITHER0_MOUT_EN 0xf3c
+#define DITHER0_MOUT_DSI0 BIT(0)
+#define DISP_DSI0_SEL_IN 0xf40
+#define DSI0_SEL_IN_DITHER00x1
+#define DISP_OVL2_2L_MOUT_EN 0xf4c
+#define OVL2_2L_MOUT_RDMA4 BIT(0)
+
+static void mtk_mmsys_ddp_mout_en(void __iomem *config_regs,
+ enum mtk_ddp_comp_id cur,
+ enum mtk_ddp_comp_id next,
+ bool enable)
+{
+ unsigned int addr, value, reg;
+
+ if (cur == DDP_COMPONENT_OVL_2L0 && next == DDP_COMPONENT_RDMA0) {
+ addr = DISP_OVL0_2L_MOUT_EN;
+ value = OVL0_MOUT_EN_DISP_RDMA0;
+ } else if (cur == DDP_COMPONENT_OVL_2L2 && next == DDP_COMPONENT_RDMA4)
{
+ addr = DISP_OVL2_2L_MOUT_EN;
+ value = OVL2_2L_MOUT_RDMA4;
+ } else if (cur == DDP_COMPONENT_DITHER && next == DDP_COMPONENT_DSI0) {
+ addr = DISP_DITHER0_MOUT_EN;
+ value = DITHER0_MOUT_DSI0;
+ } else {
+ value = 0;
+ }
+
+ if (value) {
+ reg = readl_relaxed(config_regs + addr);
+
+ if (enable)
+ reg |= value;
+ else
+ reg &= ~value;
+
+ writel_relaxed(reg, config_regs + addr);
+ }
+}
+
+static void mtk_mmsys_ddp_sel_in(void __iomem *config_regs,
+enum mtk_ddp_comp_id cur,
+enum mtk_ddp_comp_id next,
+bool enable)
+{
+ unsigned int addr, value, reg;
+
+ if (cur == DDP_COMPONENT_OVL_2L0 && next == DDP_COMPONENT_RDMA0) {
+ addr = DISP_RDMA0_SEL_IN;
+ value = RDMA0_SEL_IN_OVL0_2L;
+ } else if (cur == DDP_COMPONENT_CCORR && next == DDP_COMPONENT_AAL0) {
+ addr = DISP_AAL0_SEL_IN;
+ value = AAL0_SEL_IN_CCORR0;
+ } else if (cur == DDP_COMPONENT_DITHER && next == DDP_COMPONENT_DSI0) {
+ addr = DISP_DSI0_SEL_IN;
+ value = DSI0_SEL_IN_DITHER0;
+ } else {
+ value = 0;
+ }
+
+ if (value) {
+ reg = readl_relaxed(config_regs + addr);
+
+ if (enable)
+ reg |= value;
+ else
+ reg &= ~value;
+
+ writel_relaxed(reg, config_regs + addr);
+ }
+}
+
+static void mtk_mmsys_ddp_sout_sel(void __iomem *config_regs,
+ enum mtk_ddp_comp_id cur,
+ enum mtk_ddp_comp_id next)
+{
+ if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_COLOR0) {
+ writel_relaxed(RDMA0_SOUT_COLOR0, config
[PATCH v4, 03/10] soc: mediatek: mmsys: move register operation into mmsys path select function
move register operation into mmsys path select function
Signed-off-by: Yongqiang Niu
---
drivers/soc/mediatek/mmsys/mtk-mmsys.c | 140 +
1 file changed, 71 insertions(+), 69 deletions(-)
diff --git a/drivers/soc/mediatek/mmsys/mtk-mmsys.c
b/drivers/soc/mediatek/mmsys/mtk-mmsys.c
index 6c03282..64c8030 100644
--- a/drivers/soc/mediatek/mmsys/mtk-mmsys.c
+++ b/drivers/soc/mediatek/mmsys/mtk-mmsys.c
@@ -106,141 +106,161 @@ struct mtk_mmsys {
.clk_driver = "clk-mt8183-mm",
};
-static unsigned int mtk_mmsys_ddp_mout_en(enum mtk_ddp_comp_id cur,
- enum mtk_ddp_comp_id next,
- unsigned int *addr)
+static void mtk_mmsys_ddp_mout_en(void __iomem *config_regs,
+ enum mtk_ddp_comp_id cur,
+ enum mtk_ddp_comp_id next,
+ bool enable)
{
- unsigned int value;
+ unsigned int addr, value, reg;
if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_COLOR0) {
- *addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_OVL0_MOUT_EN;
value = OVL0_MOUT_EN_COLOR0;
} else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_RDMA0) {
- *addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_OVL_MOUT_EN;
value = OVL_MOUT_EN_RDMA;
} else if (cur == DDP_COMPONENT_OD0 && next == DDP_COMPONENT_RDMA0) {
- *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD_MOUT_EN_RDMA0;
} else if (cur == DDP_COMPONENT_UFOE && next == DDP_COMPONENT_DSI0) {
- *addr = DISP_REG_CONFIG_DISP_UFOE_MOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_UFOE_MOUT_EN;
value = UFOE_MOUT_EN_DSI0;
} else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
- *addr = DISP_REG_CONFIG_DISP_OVL1_MOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_OVL1_MOUT_EN;
value = OVL1_MOUT_EN_COLOR1;
} else if (cur == DDP_COMPONENT_GAMMA && next == DDP_COMPONENT_RDMA1) {
- *addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN;
value = GAMMA_MOUT_EN_RDMA1;
} else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
- *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD1_MOUT_EN_RDMA1;
} else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI0) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
value = RDMA0_SOUT_DPI0;
} else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DPI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
value = RDMA0_SOUT_DPI1;
} else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
value = RDMA0_SOUT_DSI1;
} else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI2) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
value = RDMA0_SOUT_DSI2;
} else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI3) {
- *addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN;
value = RDMA0_SOUT_DSI3;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
value = RDMA1_SOUT_DSI1;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI2) {
- *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
value = RDMA1_SOUT_DSI2;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
- *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
value = RDMA1_SOUT_DSI3;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
- *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
+ addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
value = RDMA1_SOUT_DPI0;
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
- *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
+ addr
Re: amdgpu does not support 3840x2160@30Hz on kaveri apu
Btw, should the driver switch to the lower supported resolution then? Il Lun 4 Gen 2021, 13:04 Davide Corrado ha scritto: > Hello. This resolution is supported by the Apu and the motherboard specs. > Will try what you suggest and let you know > > Il Lun 4 Gen 2021, 12:10 Christian König > ha scritto: > >> Hi Davide, >> >> adding a few of our AMD display people. >> >> In general as already suggested by others opening a bug report to track >> this is the right thing to do. >> >> In the past we had a few bug reports like this because amdgpu is more >> strict in checking hardware limitations. >> >> For example it can be that your HDMI port on the board can only handle a >> certain maximum pixel clock, but radeon is ignoring this while amdgpu isn't. >> >> What you can try to do is to manually override the used mode, e.g. copy >> the modeline used when radeon is active and manually add that using xrandr >> when amdgpu is active and see if it works or not. >> >> Regards, >> Christian. >> >> Am 02.01.21 um 19:50 schrieb Davide Corrado: >> >> hello, I'd like to report this issue that I am having since I updated my >> display (samsung U28E590). The amdgpu does not support the native >> resolution of my new monitor, which is 3840x2160*.* Using a HDMI or DVI >> connection (I tried both, same results), the maximum supported refresh is >> 30Hz, so I'm stuck with that (don't have a displayport). The radeon module >> works fine, I'm having this issue just when I use amdgpu (which I'd like >> to, because performance is better). >> >> Some info of my hardware: >> >> cpu: AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G >> kernel version (I tried different ones and different linux distros, same >> results!): 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 2020 >> x86_64 x86_64 x86_64 GNU/Linux >> Monitor: Samsung U28E590. >> >> description: >> If I boot the system using amdgpu and no video mode selection, the system >> boots but I don't get a screen during boot and in wayland. I can connect >> using ssh, so the system is running fine, just no display; If I force a >> full HD resolution with "video:" in the kernel line, I can see the boot >> process but the screen disappears when wayland starts (because the default >> resolution is 3840x2160@30Hz). Using a full HD monitor results in no >> issues, so it must be related to this very 4k resolution. >> >> As I have already stated, radeon module works with the same >> software/hardware configuration. >> thanks you so much for your time :-) >> >> -- >> Davide Corrado >> UNIX Team Leader >> >> Via Abramo Lincoln, 25 >> 20129 Milano >> >> Tel +39 3474259950 >> >> ___ >> amd-gfx mailing >> listamd-gfx@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/amd-gfx >> >> >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4, 01/10] soc: mediatek: mmsys: create mmsys folder
the mmsys will more and more complicated after support more and more SoCs, add an independent folder will be more clear Signed-off-by: Yongqiang Niu --- drivers/soc/mediatek/Makefile | 2 +- drivers/soc/mediatek/mmsys/Makefile| 2 + drivers/soc/mediatek/mmsys/mtk-mmsys.c | 373 + drivers/soc/mediatek/mtk-mmsys.c | 373 - 4 files changed, 376 insertions(+), 374 deletions(-) create mode 100644 drivers/soc/mediatek/mmsys/Makefile create mode 100644 drivers/soc/mediatek/mmsys/mtk-mmsys.c delete mode 100644 drivers/soc/mediatek/mtk-mmsys.c diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile index b6908db..eca9774 100644 --- a/drivers/soc/mediatek/Makefile +++ b/drivers/soc/mediatek/Makefile @@ -5,4 +5,4 @@ obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o obj-$(CONFIG_MTK_SCPSYS_PM_DOMAINS) += mtk-pm-domains.o -obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o +obj-$(CONFIG_MTK_MMSYS) += mmsys/ diff --git a/drivers/soc/mediatek/mmsys/Makefile b/drivers/soc/mediatek/mmsys/Makefile new file mode 100644 index 000..f44eadc --- /dev/null +++ b/drivers/soc/mediatek/mmsys/Makefile @@ -0,0 +1,2 @@ +# SPDX-License-Identifier: GPL-2.0-only +obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o diff --git a/drivers/soc/mediatek/mmsys/mtk-mmsys.c b/drivers/soc/mediatek/mmsys/mtk-mmsys.c new file mode 100644 index 000..18f9397 --- /dev/null +++ b/drivers/soc/mediatek/mmsys/mtk-mmsys.c @@ -0,0 +1,373 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (c) 2014 MediaTek Inc. + * Author: James Liao + */ + +#include +#include +#include +#include +#include + +#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040 +#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044 +#define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048 +#define DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN 0x04c +#define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050 +#define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084 +#define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088 +#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4 +#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8 +#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8 +#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4 +#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8 +#define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100 + +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030 +#define DISP_REG_CONFIG_OUT_SEL0x04c +#define DISP_REG_CONFIG_DSI_SEL0x050 +#define DISP_REG_CONFIG_DPI_SEL0x064 + +#define OVL0_MOUT_EN_COLOR00x1 +#define OD_MOUT_EN_RDMA0 0x1 +#define OD1_MOUT_EN_RDMA1 BIT(16) +#define UFOE_MOUT_EN_DSI0 0x1 +#define COLOR0_SEL_IN_OVL0 0x1 +#define OVL1_MOUT_EN_COLOR10x1 +#define GAMMA_MOUT_EN_RDMA10x1 +#define RDMA0_SOUT_DPI00x2 +#define RDMA0_SOUT_DPI10x3 +#define RDMA0_SOUT_DSI10x1 +#define RDMA0_SOUT_DSI20x4 +#define RDMA0_SOUT_DSI30x5 +#define RDMA1_SOUT_DPI00x2 +#define RDMA1_SOUT_DPI10x3 +#define RDMA1_SOUT_DSI10x1 +#define RDMA1_SOUT_DSI20x4 +#define RDMA1_SOUT_DSI30x5 +#define RDMA2_SOUT_DPI00x2 +#define RDMA2_SOUT_DPI10x3 +#define RDMA2_SOUT_DSI10x1 +#define RDMA2_SOUT_DSI20x4 +#define RDMA2_SOUT_DSI30x5 +#define DPI0_SEL_IN_RDMA1 0x1 +#define DPI0_SEL_IN_RDMA2 0x3 +#define DPI1_SEL_IN_RDMA1 (0x1 << 8) +#define DPI1_SEL_IN_RDMA2 (0x3 << 8) +#define DSI0_SEL_IN_RDMA1 0x1 +#define DSI0_SEL_IN_RDMA2 0x4 +#define DSI1_SEL_IN_RDMA1 0x1 +#define DSI1_SEL_IN_RDMA2 0x4 +#define DSI2_SEL_IN_RDMA1 (0x1 << 16) +#define DSI2_SEL_IN_RDMA2 (0x4 << 16) +#define DSI3_SEL_IN_RDMA1 (0x1 << 16) +#define DSI3_SEL_IN_RDMA2 (0x4 << 16) +#define COLOR1_SEL_IN_OVL1 0x1 + +#define OVL_MOUT_EN_RDMA 0x1 +#define BLS_TO_DSI_RDMA1_TO_DPI1 0x8 +#define BLS_TO_DPI_RDMA1_TO_DSI0x2 +#define DSI_SEL_IN_BLS 0x0 +#define
