[PATCH] drm/hisilicon/hibmc: add gamma_set function
add gamma_set function, and we can also use it to adjust the brightness of the
display.
Signed-off-by: Zhihui Chen
---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 37 +++
.../gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h | 5 +++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index 24de937c1cb1..f1ce6cb099d0 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -456,6 +456,42 @@ static void hibmc_crtc_disable_vblank(struct drm_crtc
*crtc)
priv->mmio + HIBMC_RAW_INTERRUPT_EN);
}
+static void hibmc_crtc_load_lut(struct drm_crtc *crtc)
+{
+ struct hibmc_drm_private *priv = crtc->dev->dev_private;
+ void __iomem *mmio = priv->mmio;
+ u16 *r, *g, *b;
+ unsigned int reg;
+ int i;
+
+ r = crtc->gamma_store;
+ g = r + crtc->gamma_size;
+ b = g + crtc->gamma_size;
+
+ for (i = 0; i < crtc->gamma_size; i++) {
+ unsigned int offset = i << 2;
+ u8 red = *r++ >> 8;
+ u8 green = *g++ >> 8;
+ u8 blue = *b++ >> 8;
+ u32 rgb = (red << 16) | (green << 8) | blue;
+
+ writel(rgb, mmio + HIBMC_CRT_PALETTE + offset);
+ }
+
+ reg = readl(priv->mmio + HIBMC_CRT_DISP_CTL);
+ reg |= HIBMC_FIELD(HIBMC_CTL_DISP_CTL_GAMMA, 1);
+ writel(reg, priv->mmio + HIBMC_CRT_DISP_CTL);
+}
+
+static int hibmc_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
+ u16 *blue, uint32_t size,
+ struct drm_modeset_acquire_ctx *ctx)
+{
+ hibmc_crtc_load_lut(crtc);
+
+ return 0;
+}
+
static const struct drm_crtc_funcs hibmc_crtc_funcs = {
.page_flip = drm_atomic_helper_page_flip,
.set_config = drm_atomic_helper_set_config,
@@ -465,6 +501,7 @@ static const struct drm_crtc_funcs hibmc_crtc_funcs = {
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
.enable_vblank = hibmc_crtc_enable_vblank,
.disable_vblank = hibmc_crtc_disable_vblank,
+ .gamma_set = hibmc_crtc_gamma_set,
};
static const struct drm_crtc_helper_funcs hibmc_crtc_helper_funcs = {
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h
index b9e20cfcfb5a..9b7e85947113 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_regs.h
@@ -91,6 +91,9 @@
#define HIBMC_CRT_DISP_CTL_TIMING(x) ((x) << 8)
#define HIBMC_CRT_DISP_CTL_TIMING_MASK 0x100
+#define HIBMC_CTL_DISP_CTL_GAMMA(x)((x) << 3)
+#define HIBMC_CTL_DISP_CTL_GAMMA_MASK 0x08
+
#define HIBMC_CRT_DISP_CTL_PLANE(x)((x) << 2)
#define HIBMC_CRT_DISP_CTL_PLANE_MASK 4
@@ -193,5 +196,7 @@
#define CRT_PLL2_HS_148MHZ 0xB0CD
#define CRT_PLL2_HS_193MHZ 0xC0872B02
+#define HIBMC_CRT_PALETTE 0x80C00
+
#define HIBMC_FIELD(field, value) (field(value) & field##_MASK)
#endif
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [4/5] drm/i915: Auto detect DPCD backlight support by default
On 11/22/19 6:16 PM, Lyude Paul wrote: Turns out we actually already have some companies, such as Lenovo, shipping machines with AMOLED screens that don't allow controlling the backlight through the usual PWM interface and only allow controlling it through the standard EDP DPCD interface. One example of one of these laptops is the X1 Extreme 2nd Generation. Since we've got systems that need this turned on by default now to have backlight controls working out of the box, let's start auto-detecting it for systems by default based on what the VBT tells us. We do this by changing the default value for the enable_dpcd_backlight module param from 0 to -1. Signed-off-by: Lyude Paul Reviewed-by: Jani Nikula --- drivers/gpu/drm/i915/i915_params.c | 2 +- drivers/gpu/drm/i915/i915_params.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 1dd1f3652795..31eed60c167e 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -172,7 +172,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400, i915_param_named(enable_dpcd_backlight, int, 0600, "Enable support for DPCD backlight control" - "(-1=use per-VBT LFP backlight type setting, 0=disabled [default], 1=enabled)"); + "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 1=enabled)"); #if IS_ENABLED(CONFIG_DRM_I915_GVT) i915_param_named(enable_gvt, bool, 0400, diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 31b88f297fbc..a79d0867f77a 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -64,7 +64,7 @@ struct drm_printer; param(int, reset, 3) \ param(unsigned int, inject_probe_failure, 0) \ param(int, fastboot, -1) \ - param(int, enable_dpcd_backlight, 0) \ + param(int, enable_dpcd_backlight, -1) \ param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE) \ param(unsigned long, fake_lmem_start, 0) \ /* leave bools at the end to not create holes */ \ Tested-by:Perry Yuan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3/5] drm/i915: Fix DPCD register order in intel_dp_aux_enable_backlight()
On 11/22/19 6:16 PM, Lyude Paul wrote: For eDP panels, it appears it's expected that so long as the panel is in DPCD control mode that the brightness value is never set to 0. Instead, if the desired effect is to set the panel's backlight to 0 we're expected to simply turn off the backlight through the DP_EDP_DISPLAY_CONTROL_REGISTER. We already do the latter correctly in intel_dp_aux_disable_backlight(). But, we make the mistake of writing the DPCD registers in the wrong order when enabling the backlight in intel_dp_aux_enable_backlight() since we currently enable the backlight through DP_EDP_DISPLAY_CONTROL_REGISTER before writing the brightness level. On the X1 Extreme 2nd Generation, this appears to have the potential of confusing the panel in such a way that further attempts to set the brightness don't actually change the backlight as expected and leave it off. Presumably, this happens because the incorrect register writing order briefly leaves the panel with DPCD mode enabled and a 0 brightness level set. So, reverse the order we write the DPCD registers when enabling the panel backlight so that we write the brightness value first, and enable the backlight second. This fix appears to be the final bit needed to get the backlight on the ThinkPad X1 Extreme 2nd Generation's AMOLED screen working. Signed-off-by: Lyude Paul Reviewed-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) 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 0bf8772bc7bb..87b59db9ffe3 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c @@ -205,8 +205,9 @@ static void intel_dp_aux_enable_backlight(const struct intel_crtc_state *crtc_st } } + intel_dp_aux_set_backlight(conn_state, + connector->panel.backlight.level); set_aux_backlight_enable(intel_dp, true); - intel_dp_aux_set_backlight(conn_state, connector->panel.backlight.level); } static void intel_dp_aux_disable_backlight(const struct drm_connector_state *old_conn_state) Tested-by:Perry Yuan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v2] drm/i915: Assume 100% brightness when not in DPCD control mode
On 12/3/19 5:42 PM, Lyude Paul wrote:
Currently we always determine the initial panel brightness level by
simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This
seems wrong though, because if the panel is not currently in DPCD
control mode there's not really any reason why there would be any
brightness value programmed in the first place.
This appears to be the case on the Lenovo ThinkPad X1 Extreme 2nd
Generation, where the default value in these registers is always 0 on
boot despite the fact the panel runs at max brightness by default.
Getting the initial brightness value correct here is important as well,
since the panel on this laptop doesn't behave well if it's ever put into
DPCD control mode while the brightness level is programmed to 0.
So, let's fix this by checking what the current backlight control mode
is before reading the brightness level. If it's in DPCD control mode, we
return the programmed brightness level. Otherwise we assume 100%
brightness and return the highest possible brightness level. This also
prevents us from accidentally programming a brightness level of 0.
This is one of the many fixes that gets backlight controls working on
the ThinkPad X1 Extreme 2nd Generation with optional 4K AMOLED screen.
Changes since v1:
* s/DP_EDP_DISPLAY_CONTROL_REGISTER/DP_EDP_BACKLIGHT_MODE_SET_REGISTER/
- Jani
Signed-off-by: Lyude Paul
---
.../drm/i915/display/intel_dp_aux_backlight.c | 17 +
1 file changed, 17 insertions(+)
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 fad470553cf9..4d467e7d29eb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -59,8 +59,25 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector
*connector)
{
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
u8 read_val[2] = { 0x0 };
+ u8 mode_reg;
u16 level = 0;
+ if (drm_dp_dpcd_readb(_dp->aux,
+ DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
+ _reg) != 1) {
+ DRM_DEBUG_KMS("Failed to read the DPCD register 0x%x\n",
+ DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
+ return 0;
+ }
+
+ /*
+* If we're not in DPCD control mode yet, the programmed brightness
+* value is meaningless and we should assume max brightness
+*/
+ if ((mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
+ DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD)
+ return connector->panel.backlight.max;
+
if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
_val, sizeof(read_val)) < 0) {
DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
Tested-by:Perry Yuan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: change callback names
This patch changes Exynos specific 'disable' and 'enable'
callback names to 'atomic_disable/enable' for the consistency.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 10 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 8
drivers/gpu/drm/exynos/exynos_drm_drv.h | 8
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 8
drivers/gpu/drm/exynos/exynos_mixer.c | 8
7 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 2d5cbfd..8428ae1 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -510,7 +510,7 @@ static void decon_swreset(struct decon_context *ctx)
ctx->addr + DECON_CRCCTRL);
}
-static void decon_enable(struct exynos_drm_crtc *crtc)
+static void decon_atomic_enable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc->ctx;
@@ -523,7 +523,7 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
decon_commit(ctx->crtc);
}
-static void decon_disable(struct exynos_drm_crtc *crtc)
+static void decon_atomic_disable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc->ctx;
int i;
@@ -599,8 +599,8 @@ static enum drm_mode_status decon_mode_valid(struct
exynos_drm_crtc *crtc,
}
static const struct exynos_drm_crtc_ops decon_crtc_ops = {
- .enable = decon_enable,
- .disable= decon_disable,
+ .atomic_enable = decon_atomic_enable,
+ .atomic_disable = decon_atomic_disable,
.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
.atomic_begin = decon_atomic_begin,
@@ -651,7 +651,7 @@ static void decon_unbind(struct device *dev, struct device
*master, void *data)
{
struct decon_context *ctx = dev_get_drvdata(dev);
- decon_disable(ctx->crtc);
+ decon_atomic_disable(ctx->crtc);
/* detach this sub driver from iommu mapping if supported. */
exynos_drm_unregister_dma(ctx->drm_dev, ctx->dev);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index f064095..ff59c64 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -526,7 +526,7 @@ static void decon_init(struct decon_context *ctx)
writel(VIDCON1_VCLK_HOLD, ctx->regs + VIDCON1(0));
}
-static void decon_enable(struct exynos_drm_crtc *crtc)
+static void decon_atomic_enable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc->ctx;
@@ -546,7 +546,7 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
ctx->suspended = false;
}
-static void decon_disable(struct exynos_drm_crtc *crtc)
+static void decon_atomic_disable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc->ctx;
int i;
@@ -568,8 +568,8 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
}
static const struct exynos_drm_crtc_ops decon_crtc_ops = {
- .enable = decon_enable,
- .disable = decon_disable,
+ .atomic_enable = decon_atomic_enable,
+ .atomic_disable = decon_atomic_disable,
.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
.atomic_begin = decon_atomic_begin,
@@ -653,7 +653,7 @@ static void decon_unbind(struct device *dev, struct device
*master,
{
struct decon_context *ctx = dev_get_drvdata(dev);
- decon_disable(ctx->crtc);
+ decon_atomic_disable(ctx->crtc);
if (ctx->encoder)
exynos_dpi_remove(ctx->encoder);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 77ce789..1c03485 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -23,8 +23,8 @@ static void exynos_drm_crtc_atomic_enable(struct drm_crtc
*crtc,
{
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- if (exynos_crtc->ops->enable)
- exynos_crtc->ops->enable(exynos_crtc);
+ if (exynos_crtc->ops->atomic_enable)
+ exynos_crtc->ops->atomic_enable(exynos_crtc);
drm_crtc_vblank_on(crtc);
}
@@ -36,8 +36,8 @@ static void exynos_drm_crtc_atomic_disable(struct drm_crtc
*crtc,
drm_crtc_vblank_off(crtc);
- if (exynos_crtc->ops->disable)
- exynos_crtc->ops->disable(exynos_crtc);
+ if (exynos_crtc->ops->atomic_disable)
+ exynos_crtc->ops->atomic_disable(exynos_crtc);
if (crtc->state->event && !crtc->state->active) {
[PATCH] drm/hisilicon/hibmc: set obj[0] field when creating fb
without the obj[0] set, we can see the following panic:
[ 29.236764] pstate: 2049 (nzCv daif +PAN -UAO)
[ 29.241532] pc : drm_gem_vram_offset+0x10/0x28 [drm_vram_helper]
[ 29.247511] lr : hibmc_plane_atomic_update+0x30/0xe0 [hibmc_drm]
[ 29.253490] sp : 003fab713a50
[ 29.256789] x29: 003fab713a50 x28: 0028
[ 29.262077] x27: 0018 x26: ced52780
[ 29.267363] x25: 203f98dcde00 x24: 0001
[ 29.272650] x23: 0001 x22:
[ 29.277937] x21: x20: 002fb4899580
[ 29.283224] x19: 003fb8767c00 x18:
[ 29.288510] x17: x16:
[ 29.293797] x15: 0010 x14: 332d4341443a3433
[ 29.299084] x13: 3a5245444f434e45 x12: 5b206e6f20746573
[ 29.304371] x11: 65646f6d205d7365 x10: 6c62617369645f74
[ 29.309657] x9 : 88e4d650 x8 : 8000107241d0
[ 29.314944] x7 : x6 : 003fb8766400
[ 29.320231] x5 : 003fb8767c00 x4 : 88e4f320
[ 29.325517] x3 : 002fb3ae5080 x2 : 002fb3ae
[ 29.330804] x1 : x0 : 002fb07f5c00
[ 29.336090] Call trace:
[ 29.338528] drm_gem_vram_offset+0x10/0x28 [drm_vram_helper]
[ 29.344160] drm_atomic_helper_commit_planes+0x144/0x228
[ 29.349447] drm_atomic_helper_commit_tail+0x38/0x78
[ 29.354389] commit_tail+0xb4/0x160
[ 29.357861] drm_atomic_helper_commit+0x134/0x168
[ 29.362543] drm_atomic_commit+0x50/0x60
[ 29.366448] drm_mode_atomic_ioctl+0x724/0xb00
[ 29.370871] drm_ioctl_kernel+0x98/0xe8
[ 29.374690] drm_ioctl+0x26c/0x3d0
[ 29.378077] do_vfs_ioctl+0xafc/0xbb0
[ 29.381722] ksys_ioctl+0x64/0x98
[ 29.385022] __arm64_sys_ioctl+0x24/0x50
[ 29.388929] el0_svc_common.constprop.3+0xf0/0x158
[ 29.393697] el0_svc_handler+0x68/0x80
[ 29.397429] el0_sync_handler+0xa8/0x198
[ 29.401333] el0_sync+0x140/0x180
[ 29.404632] ---[ end trace 4ba9406972d937dd ]---
[ 29.409245] Unexpected kernel BRK exception at EL1
Signed-off-by: Zhihui Chen
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index 21b684eab5c9..19dc525a73b0 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -126,6 +126,7 @@ hibmc_framebuffer_init(struct drm_device *dev,
drm_helper_mode_fill_fb_struct(dev, _fb->fb, mode_cmd);
hibmc_fb->obj = obj;
+ hibmc_fb->fb.obj[0] = obj;
ret = drm_framebuffer_init(dev, _fb->fb, _fb_funcs);
if (ret) {
DRM_ERROR("drm_framebuffer_init failed: %d\n", ret);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Oops in amdgpu on Kernel 5.4.0
Hardware: X399 Taichi AMD Threadripper 1920X Asus Radeon 5700XT 16GB of RAM Software: Gentoo libdrm 2.4.100 mesa 19.2.7 amdgpudrmfb in use I'm getting a lot of these OOPS in the log as below. Is there anything I can do to help fix this? Thanks, Alex Dec 15 10:16:53 titanium kernel: [ cut here ] Dec 15 10:16:53 titanium kernel: WARNING: CPU: 3 PID: 13539 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c:1829 dcn20_setup_gsl_group_as_lock+0xc8/0x1a3 [amdgpu] Dec 15 10:16:53 titanium kernel: Modules linked in: nfsd cfg80211 rfkill 8021q ipv6 nf_defrag_ipv6 binfmt_misc snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio amdgpu snd_hda_intel snd_intel_nhlt joydev input_leds snd_hda_codec gpu_sched snd_hda_core drm_kms_helper kvm_amd snd_hwdep syscopyarea vboxnetadp(O) sysfillrect snd_pcm sysimgblt fb_sys_fops kvm ttm vboxnetflt(O) irqbypass efivars snd_timer pcspkr drm snd i2c_piix4 k10temp backlight vboxdrv(O) button acpi_cpufreq efivarfs xts ecb cbc sha512_generic sha256_generic libsha256 sha1_generic libiscsi scsi_transport_iscsi ixgb ixgbe tulip cxgb3 cxgb mdio macvlan tg3 sky2 r8169 libphy pcnet32 mii e1000 bnx2 fuse nfs lockd grace sunrpc multipath linear raid0 dm_snapshot dm_bufio dm_crypt dm_mirror dm_region_hash dm_log dm_mod dax hid_sunplus hid_sony hid_samsung hid_pl hid_petalynx hid_monterey hid_microsoft ff_memless hid_logitech hid_gyration hid_ezkey hid_cypress hid_chicony hid_cherry hid_belkin hid_apple hid_a4tech sl811_hcd xhci_plat_hcd ohci_pci Dec 15 10:16:53 titanium kernel: ohci_hcd uhci_hcd usb_storage ehci_pci ehci_hcd aic94xx libsas lpfc crc_t10dif crct10dif_common qla2xxx megaraid_sas megaraid_mbox megaraid_mm megaraid aacraid sx8 3w_9xxx 3w_ mptsas scsi_transport_sas mptfc scsi_transport_fc mptspi mptscsih mptbase atp870u dc395x qla1280 imm parport dmx3191d sym53c8xx gdth initio BusLogic arcmsr aic7xxx aic79xx scsi_transport_spi sg pdc_adma sata_inic162x sata_mv ata_piix sata_qstor sata_vsc sata_uli sata_sis sata_sx4 sata_nv sata_via sata_svw sata_sil24 sata_sil sata_promise pata_sl82c105 pata_via pata_jmicron pata_marvell pata_sis pata_netcell pata_pdc202xx_old pata_triflex pata_atiixp pata_opti pata_amd pata_ali pata_it8213 pata_pcmcia pcmcia pcmcia_core pata_ns87415 pata_ns87410 pata_serverworks pata_artop pata_it821x pata_optidma pata_hpt3x2n pata_hpt3x3 pata_hpt37x pata_hpt366 pata_cmd64x pata_efar pata_rz1000 pata_sil680 pata_radisys pata_pdc2027x pata_mpiix raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx Dec 15 10:16:53 titanium kernel: raid6_pq raid10 raid1 led_class usbhid igb xhci_pci ahci i2c_algo_bit xhci_hcd libahci i2c_core usbcore libata dca usb_common [last unloaded: cpuid] Dec 15 10:16:53 titanium kernel: CPU: 3 PID: 13539 Comm: kworker/u64:3 Tainted: G O 5.4.0-gentoo #1 Dec 15 10:16:53 titanium kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X399 Taichi, BIOS P3.80 08/27/2019 Dec 15 10:16:53 titanium kernel: Workqueue: events_unbound commit_work [drm_kms_helper] Dec 15 10:16:53 titanium kernel: RIP: 0010:dcn20_setup_gsl_group_as_lock+0xc8/0x1a3 [amdgpu] Dec 15 10:16:53 titanium kernel: Code: eb 31 a8 04 75 24 c6 83 60 02 00 00 03 49 8b 80 10 03 00 00 bd 03 00 00 00 c7 44 24 08 01 00 00 00 80 88 70 02 00 00 04 eb 09 <0f> 0b 0f 0b e9 b4 00 00 00 c7 44 24 0c 01 00 00 00 eb 5e 84 c0 0f Dec 15 10:16:53 titanium kernel: RSP: 0018:9f5a83fdfac0 EFLAGS: 00010202 Dec 15 10:16:53 titanium kernel: RAX: 8cce27ade807 RBX: 8df00658 RCX: Dec 15 10:16:53 titanium kernel: RDX: 0001 RSI: 9f5a83fdfac0 RDI: 9f5a83fdfae8 Dec 15 10:16:53 titanium kernel: RBP: 0001 R08: 8cce26a4 R09: 0001 Dec 15 10:16:53 titanium kernel: R10: 9f5a83fdfb28 R11: R12: 0001 Dec 15 10:16:53 titanium kernel: R13: 8df00658 R14: 8df01d78 R15: 8cce26a4 Dec 15 10:16:53 titanium kernel: FS: () GS:8cce3eac() knlGS: Dec 15 10:16:53 titanium kernel: CS: 0010 DS: ES: CR0: 80050033 Dec 15 10:16:53 titanium kernel: CR2: 7f7f8b069b30 CR3: 000466dda000 CR4: 003406e0 Dec 15 10:16:53 titanium kernel: Call Trace: Dec 15 10:16:53 titanium kernel: dcn20_pipe_control_lock+0x51/0x9d [amdgpu] Dec 15 10:16:53 titanium kernel: dc_commit_updates_for_stream+0xbde/0xe0f [amdgpu] Dec 15 10:16:53 titanium kernel: amdgpu_dm_atomic_commit_tail+0x1259/0x1506 [amdgpu] Dec 15 10:16:53 titanium kernel: ? update_cfs_rq_load_avg+0xf5/0x114 Dec 15 10:16:53 titanium kernel: ? __switch_to_asm+0x34/0x70 Dec 15 10:16:53 titanium kernel: ? __switch_to_asm+0x40/0x70 Dec 15 10:16:53 titanium kernel: ? __switch_to_asm+0x34/0x70 Dec 15 10:16:53 titanium kernel: ? __switch_to_asm+0x40/0x70 Dec 15 10:16:53 titanium kernel: ? __switch_to_asm+0x34/0x70 Dec 15 10:16:53 titanium kernel: ? __switch_to_asm+0x40/0x70 Dec 15
Re: [RFC v2 05/12] drm/i915/svm: Page table mirroring support
On Fri, Dec 20, 2019 at 01:45:33PM +, Jason Gunthorpe wrote:
On Wed, Dec 18, 2019 at 02:41:47PM -0800, Niranjana Vishwanathapura wrote:
> > +static u32 i915_svm_build_sg(struct i915_address_space *vm,
> > + struct hmm_range *range,
> > + struct sg_table *st)
> > +{
> > + struct scatterlist *sg;
> > + u32 sg_page_sizes = 0;
> > + u64 i, npages;
> > +
> > + sg = NULL;
> > + st->nents = 0;
> > + npages = (range->end - range->start) / PAGE_SIZE;
> > +
> > + /*
> > + * No need to dma map the host pages and later unmap it, as
> > + * GPU is not allowed to access it with SVM.
> > + * XXX: Need to dma map host pages for integrated graphics while
> > + * extending SVM support there.
> > + */
> > + for (i = 0; i < npages; i++) {
> > + u64 addr = range->pfns[i] & ~((1UL << range->pfn_shift) - 1);
> > +
> > + if (sg && (addr == (sg_dma_address(sg) + sg->length))) {
> > + sg->length += PAGE_SIZE;
> > + sg_dma_len(sg) += PAGE_SIZE;
> > + continue;
> > + }
> > +
> > + if (sg)
> > + sg_page_sizes |= sg->length;
> > +
> > + sg = sg ? __sg_next(sg) : st->sgl;
> > + sg_dma_address(sg) = addr;
> > + sg_dma_len(sg) = PAGE_SIZE;
>
> This still can't be like this - assigning pfn to 'dma_address' is
> fundamentally wrong.
>
> Whatever explanation you had, this needs to be fixed up first before we get
> to this patch.
>
The pfn is converted into a device address which goes into sg_dma_address.
Ok, let me think about what else we can do here.
If you combine this with the other function and make it so only
DEVICE_PRIVATE pages get converted toa dma_address with out dma_map,
then that would make sense.
Ok thanks, will do that.
> > +static int
> > +i915_svm_invalidate_range_start(struct mmu_notifier *mn,
> > + const struct mmu_notifier_range *update)
> > +{
> > + struct i915_svm *svm = container_of(mn, struct i915_svm, notifier);
> > + unsigned long length = update->end - update->start;
> > +
> > + DRM_DEBUG_DRIVER("start 0x%lx length 0x%lx\n", update->start, length);
> > + if (!mmu_notifier_range_blockable(update))
> > + return -EAGAIN;
> > +
> > + i915_gem_vm_unbind_svm_buffer(svm->vm, update->start, length);
> > + return 0;
> > +}
>
> I still think you should strive for a better design than putting a
> notifier across the entire address space..
>
Yah, thought it could be later optimization.
If I think about it, it has be be a new user API to set the range,
or an intermediate data structure for tracking the bound ranges.
Will look into it.
Well, there are lots of options. Like I said, implicit ODP uses a
level of the device page table to attach the notifier.
There are many performance trade offs here, it depends what works best
for your work load I suppose. But usually the fault path is the fast
thing, so I would think to avoid registering mmu_intervals on it and
accept the higher probability of collisions.
Ok thanks, yah, solution should tune for the performant path. Will look into it.
Thanks,
Niranjana
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH linux-next] drm/udl: udl_handle_damage() can be static
Fixes: a8109f5bc4bd ("drm/udl: Move udl_handle_damage() into udl_modeset.c")
Signed-off-by: kbuild test robot
---
udl_modeset.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/udl/udl_modeset.c
b/drivers/gpu/drm/udl/udl_modeset.c
index 22af179590536..0cc50fc2c2ab1 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -266,8 +266,8 @@ static int udl_aligned_damage_clip(struct drm_rect *clip,
int x, int y,
return 0;
}
-int udl_handle_damage(struct drm_framebuffer *fb, int x, int y,
- int width, int height)
+static int udl_handle_damage(struct drm_framebuffer *fb, int x, int y,
+int width, int height)
{
struct drm_device *dev = fb->dev;
struct dma_buf_attachment *import_attach = fb->obj[0]->import_attach;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[linux-next:master 2859/5337] drivers/gpu/drm/udl/udl_modeset.c:269:5: sparse: sparse: symbol 'udl_handle_damage' was not declared. Should it be static?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master head: 7ddd09fc4b745fb1d8942f95389583e08412e0cd commit: a8109f5bc4bd6dc037bd15651c6c7f1ac00ed235 [2859/5337] drm/udl: Move udl_handle_damage() into udl_modeset.c reproduce: # apt-get install sparse # sparse version: v0.6.1-129-g341daf20-dirty git checkout a8109f5bc4bd6dc037bd15651c6c7f1ac00ed235 make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag Reported-by: kbuild test robot sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/udl/udl_modeset.c:269:5: sparse: sparse: symbol >> 'udl_handle_damage' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 3/7] interconnect: Allow inter-provider pairs to be configured
Hi,
On Fri, Dec 20, 2019 at 9:03 PM Artur Świgoń wrote:
>
> In the exynos-bus devfreq driver every bus is probed separately and is
IMHO, the patch description should specify the more general cause
why have to be changed. Actually, almost people might not know
the 'exynos-bus'. So, firstly, you have to specify the general cause
why this patch is necessary without 'exynos-bus' word and then
add the real use-case with 'exynos-bus' example.
> assigned a separate interconnect provider. However, the interconnect
> framework does not call the '->set' callback for pairs of nodes which
> belong to different providers.
>
> This patch adds support for a new boolean 'inter_set' field in struct
> icc_provider. Setting it to 'true' enables calling '->set' for
> inter-provider node pairs. All existing users of the interconnect
> framework allocate this structure with kzalloc, and are therefore
> unaffected.
>
> Signed-off-by: Artur Świgoń
> ---
> drivers/interconnect/core.c | 11 +--
> include/linux/interconnect-provider.h | 2 ++
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> index 74c68898a350..a28bd0f8a497 100644
> --- a/drivers/interconnect/core.c
> +++ b/drivers/interconnect/core.c
> @@ -259,23 +259,22 @@ static int aggregate_requests(struct icc_node *node)
> static int apply_constraints(struct icc_path *path)
> {
> struct icc_node *next, *prev = NULL;
> + struct icc_provider *p;
> int ret = -EINVAL;
> int i;
>
> for (i = 0; i < path->num_nodes; i++) {
> next = path->reqs[i].node;
> + p = next->provider;
>
> - /*
> -* Both endpoints should be valid master-slave pairs of the
> -* same interconnect provider that will be configured.
> -*/
> - if (!prev || next->provider != prev->provider) {
> + /* both endpoints should be valid master-slave pairs */
> + if (!prev || (p != prev->provider && !p->inter_set)) {
> prev = next;
> continue;
> }
>
> /* set the constraints */
> - ret = next->provider->set(prev, next);
> + ret = p->set(prev, next);
> if (ret)
> goto out;
>
> diff --git a/include/linux/interconnect-provider.h
> b/include/linux/interconnect-provider.h
> index cc965b8fab53..b6ae0ee686c5 100644
> --- a/include/linux/interconnect-provider.h
> +++ b/include/linux/interconnect-provider.h
> @@ -41,6 +41,7 @@ struct icc_node *of_icc_xlate_onecell(struct
> of_phandle_args *spec,
> * @xlate: provider-specific callback for mapping nodes from phandle
> arguments
> * @dev: the device this interconnect provider belongs to
> * @users: count of active users
> + * @inter_set: whether inter-provider pairs will be configured with @set
> * @data: pointer to private data
> */
> struct icc_provider {
> @@ -53,6 +54,7 @@ struct icc_provider {
> struct icc_node* (*xlate)(struct of_phandle_args *spec, void *data);
> struct device *dev;
> int users;
> + boolinter_set;
> void*data;
> };
>
> --
> 2.17.1
>
--
Best Regards,
Chanwoo Choi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[DO NOT MERGE] [PATCH v14 7/7] arm64: dts: allwinner: bananapi-m64: Enable Bananapi S070WV20-CT16 DSI panel
This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M64 board.
DSI panel connected via board DSI port with,
- DLDO1 as VCC-DSI supply
- DCDC1 as VDD supply
- PD7 gpio for lcd enable pin
- PD6 gpio for lcd reset pin
- PD5 gpio for backlight enable pin
Signed-off-by: Jagan Teki
---
.../dts/allwinner/sun50i-a64-bananapi-m64.dts | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index 208373efee49..6beaecdd802a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -45,6 +45,7 @@
#include "sun50i-a64.dtsi"
#include
+#include
/ {
model = "BananaPi-M64";
@@ -56,6 +57,14 @@
serial1 =
};
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <1 2 4 8 16 32 64 128 255>;
+ default-brightness-level = <2>;
+ enable-gpios = < 3 5 GPIO_ACTIVE_HIGH>; /* LCD-BL-EN: PD5 */
+ };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -116,6 +125,24 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ vcc-dsi-supply = <_dldo1>; /* VCC3V3-DSI */
+ status = "okay";
+
+ panel@0 {
+ compatible = "bananapi,s070wv20-ct16-icn6211";
+ reg = <0>;
+ enable-gpios = < 3 7 GPIO_ACTIVE_HIGH>; /* LCD-PWR-EN: PD7
*/
+ reset-gpios = < 3 6 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD6 */
+ vdd-supply = <_dcdc1>;
+ backlight = <>;
+ };
+};
+
{
status = "okay";
};
@@ -206,6 +233,10 @@
status = "okay";
};
+_pwm {
+ status = "okay";
+};
+
_rsb {
status = "okay";
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v14 6/7] arm64: dts: allwinner: a64: Add MIPI DSI pipeline
Add MIPI DSI pipeline for Allwinner A64.
- dsi node, with A64 compatible since it doesn't support
DSI_SCLK gating unlike A33
- dphy node, with A64 compatible with A33 fallback since
DPHY on A64 and A33 is similar
- finally, attach the dsi_in to tcon0 for complete MIPI DSI
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
Changes for v14:
- none
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 37 +++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 27e48234f1c2..1db8378f59a4 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -382,6 +382,12 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+
+ tcon0_out_dsi: endpoint@1 {
+ reg = <1>;
+ remote-endpoint =
<_in_tcon0>;
+ allwinner,tcon-channel = <1>;
+ };
};
};
};
@@ -1014,6 +1020,37 @@
status = "disabled";
};
+ dsi: dsi@1ca {
+ compatible = "allwinner,sun50i-a64-mipi-dsi";
+ reg = <0x01ca 0x1000>;
+ interrupts = ;
+ clocks = < CLK_BUS_MIPI_DSI>;
+ resets = < RST_BUS_MIPI_DSI>;
+ phys = <>;
+ phy-names = "dphy";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port {
+ dsi_in_tcon0: endpoint {
+ remote-endpoint = <_out_dsi>;
+ };
+ };
+ };
+
+ dphy: d-phy@1ca1000 {
+ compatible = "allwinner,sun50i-a64-mipi-dphy",
+"allwinner,sun6i-a31-mipi-dphy";
+ reg = <0x01ca1000 0x1000>;
+ clocks = < CLK_BUS_MIPI_DSI>,
+< CLK_DSI_DPHY>;
+ clock-names = "bus", "mod";
+ resets = < RST_BUS_MIPI_DSI>;
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
hdmi: hdmi@1ee {
compatible = "allwinner,sun50i-a64-dw-hdmi",
"allwinner,sun8i-a83t-dw-hdmi";
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v14 4/7] drm/sun4i: dsi: Handle bus clock via regmap_mmio_attach_clk
regmap has special API to enable the controller bus clock while
initializing register space, and current driver is using
devm_regmap_init_mmio_clk which require to specify bus
clk_id argument as "bus"
But, the usage of clocks are varies between different Allwinner
DSI controllers. Clocking in A33 would need bus and mod clocks
where as A64 would need only bus clock.
Since A64 support only single bus clock, it is optional to
specify the clock-names on the controller device tree node.
So using NULL on clk_id would get the attached clock.
To support clk_id as "bus" and "NULL" during clock enablement
between controllers, this patch add generic code to handle
the bus clock using regmap_mmio_attach_clk with associated
regmap APIs.
Signed-off-by: Jagan Teki
---
Changes for v14:
- drop regmap_exit, clk_put
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 37 --
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 68b88a3dc4c5..2577b237d06a 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -1081,6 +1081,7 @@ static const struct component_ops sun6i_dsi_ops = {
static int sun6i_dsi_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
+ const char *bus_clk_name = NULL;
struct sun6i_dsi *dsi;
struct resource *res;
void __iomem *base;
@@ -1094,6 +1095,10 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
dsi->host.ops = _dsi_host_ops;
dsi->host.dev = dev;
+ if (of_device_is_compatible(dev->of_node,
+ "allwinner,sun6i-a31-mipi-dsi"))
+ bus_clk_name = "bus";
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(dev, res);
if (IS_ERR(base)) {
@@ -1107,25 +1112,35 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
return PTR_ERR(dsi->regulator);
}
- dsi->regs = devm_regmap_init_mmio_clk(dev, "bus", base,
- _dsi_regmap_config);
- if (IS_ERR(dsi->regs)) {
- dev_err(dev, "Couldn't create the DSI encoder regmap\n");
- return PTR_ERR(dsi->regs);
- }
-
dsi->reset = devm_reset_control_get_shared(dev, NULL);
if (IS_ERR(dsi->reset)) {
dev_err(dev, "Couldn't get our reset line\n");
return PTR_ERR(dsi->reset);
}
+ dsi->regs = devm_regmap_init_mmio(dev, base, _dsi_regmap_config);
+ if (IS_ERR(dsi->regs)) {
+ dev_err(dev, "Couldn't init regmap\n");
+ return PTR_ERR(dsi->regs);
+ }
+
+ dsi->bus_clk = devm_clk_get(dev, bus_clk_name);
+ if (IS_ERR(dsi->bus_clk)) {
+ dev_err(dev, "Couldn't get the DSI bus clock\n");
+ return PTR_ERR(dsi->bus_clk);
+ } else {
+ ret = regmap_mmio_attach_clk(dsi->regs, dsi->bus_clk);
+ if (ret)
+ return ret;
+ }
+
if (of_device_is_compatible(dev->of_node,
"allwinner,sun6i-a31-mipi-dsi")) {
dsi->mod_clk = devm_clk_get(dev, "mod");
if (IS_ERR(dsi->mod_clk)) {
dev_err(dev, "Couldn't get the DSI mod clock\n");
- return PTR_ERR(dsi->mod_clk);
+ ret = PTR_ERR(dsi->mod_clk);
+ goto err_attach_clk;
}
}
@@ -1164,6 +1179,9 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
pm_runtime_disable(dev);
err_unprotect_clk:
clk_rate_exclusive_put(dsi->mod_clk);
+err_attach_clk:
+ if (!IS_ERR(dsi->bus_clk))
+ regmap_mmio_detach_clk(dsi->regs);
return ret;
}
@@ -1177,6 +1195,9 @@ static int sun6i_dsi_remove(struct platform_device *pdev)
pm_runtime_disable(dev);
clk_rate_exclusive_put(dsi->mod_clk);
+ if (!IS_ERR(dsi->bus_clk))
+ regmap_mmio_detach_clk(dsi->regs);
+
return 0;
}
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v14 2/7] dt-bindings: sun6i-dsi: Add A64 DPHY compatible (w/ A31 fallback)
The MIPI DSI PHY controller on Allwinner A64 is similar on the one on A31. Add A64 compatible and append A31 compatible as fallback. Reviewed-by: Rob Herring Signed-off-by: Jagan Teki --- Changes for v14: - none .../bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml index fa46670de299..8841938050b2 100644 --- a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml +++ b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml @@ -15,7 +15,11 @@ properties: const: 0 compatible: -const: allwinner,sun6i-a31-mipi-dphy +oneOf: + - const: allwinner,sun6i-a31-mipi-dphy + - items: + - const: allwinner,sun50i-a64-mipi-dphy + - const: allwinner,sun6i-a31-mipi-dphy reg: maxItems: 1 -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v14 5/7] drm/sun4i: dsi: Add Allwinner A64 MIPI DSI support
The MIPI DSI controller in Allwinner A64 is similar to A33.
But unlike A33, A64 doesn't have DSI_SCLK gating so add compatible
for Allwinner A64 with uninitialized has_mod_clk driver.
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
Changes for v14:
- none
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index 2577b237d06a..4a024951aa11 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -1256,6 +1256,7 @@ static const struct dev_pm_ops sun6i_dsi_pm_ops = {
static const struct of_device_id sun6i_dsi_of_table[] = {
{ .compatible = "allwinner,sun6i-a31-mipi-dsi" },
+ { .compatible = "allwinner,sun50i-a64-mipi-dsi" },
{ }
};
MODULE_DEVICE_TABLE(of, sun6i_dsi_of_table);
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v14 3/7] drm/sun4i: dsi: Get the mod clock for A31
As per the user manual, look like mod clock is not mandatory
for all Allwinner MIPI DSI controllers, it is connected to
CLK_DSI_SCLK for A31 and not available in A64.
So, add compatible check for A31 and get mod clock accordingly.
Tested-by: Merlijn Wajer
Signed-off-by: Jagan Teki
---
Changes for v14:
- none
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index c958ca9bae63..68b88a3dc4c5 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -1120,10 +1120,13 @@ static int sun6i_dsi_probe(struct platform_device *pdev)
return PTR_ERR(dsi->reset);
}
- dsi->mod_clk = devm_clk_get(dev, "mod");
- if (IS_ERR(dsi->mod_clk)) {
- dev_err(dev, "Couldn't get the DSI mod clock\n");
- return PTR_ERR(dsi->mod_clk);
+ if (of_device_is_compatible(dev->of_node,
+ "allwinner,sun6i-a31-mipi-dsi")) {
+ dsi->mod_clk = devm_clk_get(dev, "mod");
+ if (IS_ERR(dsi->mod_clk)) {
+ dev_err(dev, "Couldn't get the DSI mod clock\n");
+ return PTR_ERR(dsi->mod_clk);
+ }
}
/*
--
2.18.0.321.gffc6fa0e3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v14 0/7] drm/sun4i: Allwinner A64 MIPI-DSI support
This is v14 version for Allwinner A64 MIPI-DSI support and here is the previous version set[1] Changes for v14: - drop explicit regmap_exit, clk_put Changes for v13: - update dt-bindings for A64 - drop has_mod_clk variant - use regmap bus clock properly Changes for v12: - use enum insted of oneOf+const - handle bus clock using regmap attach clk - tested on A64, A33 boards. Changes for v11: - fix dt-bindings for dphy - fix dt-bindings for dsi controller - add bus clock handling code - tested on A64, A33 boards. Changes for v10: - updated dt-bindings as per .yaml format - rebased on drm-misc/for-linux-next Changes for v9: - moved dsi fixes in separate series on top of A33 - rebase on linux-next Changes for v8: - rebased on drm-misc change along with linux-next - reworked video start delay patch - tested on 4 different dsi panels - reworked commit messages Changes for v7: - moved vcc-dsi binding to required filed. - drop quotes on fallback dphy bindings. - drop min_rate clock pll-mipi patches. - introduce dclk divider computation as like A64 BSP. - add A64 DSI quark patches. - fixed A64 DSI pipeline. - add proper commit messages. - collect Merlijn Wajer Tested-by credits. Changes for v6: - dropped unneeded changes, patches - fixed all burst mode patches as per previous version comments - rebase on master - update proper commit message - dropped unneeded comments - order the patches that make review easy Changes for v5: - collect Rob, Acked-by - droped "Fix VBP size calculation" patch - updated vblk timing calculation. - droped techstar, bananapi dsi panel drivers which may require bridge or other setup. it's under discussion. Changes for v4: - droppoed untested CCU_FEATURE_FIXED_POSTDIV check code in nkm min, max rate patches - create two patches for "Add Allwinner A64 MIPI DSI support" one for has_mod_clk quirk and other one for A64 support - use existing driver code construct for hblk computation - dropped "Increase hfp packet overhead" patch [2], though BSP added this but we have no issues as of now. (no issues on panel side w/o this change) - create separate function for vblk computation - enable vcc-dsi regulator in dsi_runtime_resume - collect Rob, Acked-by - update MAINTAINERS file for panel drivers - cleanup commit messages - fixed checkpatch warnings/errors [1] https://patchwork.freedesktop.org/series/71131/ Any inputs? Jagan. Jagan Teki (7): dt-bindings: sun6i-dsi: Document A64 MIPI-DSI controller dt-bindings: sun6i-dsi: Add A64 DPHY compatible (w/ A31 fallback) drm/sun4i: dsi: Get the mod clock for A31 drm/sun4i: dsi: Handle bus clock via regmap_mmio_attach_clk drm/sun4i: dsi: Add Allwinner A64 MIPI DSI support arm64: dts: allwinner: a64: Add MIPI DSI pipeline [DO NOT MERGE] arm64: dts: allwinner: bananapi-m64: Enable Bananapi S070WV20-CT16 DSI panel .../display/allwinner,sun6i-a31-mipi-dsi.yaml | 33 - .../phy/allwinner,sun6i-a31-mipi-dphy.yaml| 6 ++- .../dts/allwinner/sun50i-a64-bananapi-m64.dts | 31 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 37 +++ drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 47 ++- 5 files changed, 140 insertions(+), 14 deletions(-) -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v14 1/7] dt-bindings: sun6i-dsi: Document A64 MIPI-DSI controller
The MIPI DSI controller in Allwinner A64 is similar to A33. But unlike A33, A64 doesn't have DSI_SCLK gating so it is valid to have separate compatible for A64 on the same driver. DSI_SCLK uses mod clock-names on dt-bindings, so the same is not required for A64. On that note - A64 require minimum of 1 clock like the bus clock - A33 require minimum of 2 clocks like both bus, mod clocks So, update dt-bindings so-that it can document both A33, A64 bindings requirements. Reviewed-by: Rob Herring Signed-off-by: Jagan Teki --- Changes for v14: - none .../display/allwinner,sun6i-a31-mipi-dsi.yaml | 33 +-- 1 file changed, 31 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml index dafc0980c4fa..d41ecb5e7f7c 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml @@ -15,7 +15,9 @@ properties: "#size-cells": true compatible: -const: allwinner,sun6i-a31-mipi-dsi +enum: + - allwinner,sun6i-a31-mipi-dsi + - allwinner,sun50i-a64-mipi-dsi reg: maxItems: 1 @@ -24,6 +26,8 @@ properties: maxItems: 1 clocks: +minItems: 1 +maxItems: 2 items: - description: Bus Clock - description: Module Clock @@ -63,13 +67,38 @@ required: - reg - interrupts - clocks - - clock-names - phys - phy-names - resets - vcc-dsi-supply - port +allOf: + - if: + properties: + compatible: + contains: + const: allwinner,sun6i-a31-mipi-dsi + +then: +properties: + clocks: +minItems: 2 + +required: + - clock-names + + - if: + properties: + compatible: + contains: + const: allwinner,sun50i-a64-mipi-dsi + +then: +properties: + clocks: +minItems: 1 + additionalProperties: false examples: -- 2.18.0.321.gffc6fa0e3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 00/25] mm/gup: track dma-pinned pages: FOLL_PIN
On Fri, Dec 20, 2019 at 03:54:55PM -0800, John Hubbard wrote: > On 12/20/19 10:29 AM, Leon Romanovsky wrote: > ... > >> $ ./build.sh > >> $ build/bin/run_tests.py > >> > >> If you get things that far I think Leon can get a reproduction for you > > > > I'm not so optimistic about that. > > > > OK, I'm going to proceed for now on the assumption that I've got an overflow > problem that happens when huge pages are pinned. If I can get more > information, > great, otherwise it's probably enough. > > One thing: for your repro, if you know the huge page size, and the system > page size for that case, that would really help. Also the number of pins per > page, more or less, that you'd expect. Because Jason says that only 2M huge > pages are used... > > Because the other possibility is that the refcount really is going negative, > likely due to a mismatched pin/unpin somehow. > > If there's not an obvious repro case available, but you do have one (is it > easy > to repro, though?), then *if* you have the time, I could point you to a github > branch that reduces GUP_PIN_COUNTING_BIAS by, say, 4x, by applying this: > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index bb44c4d2ada7..8526fd03b978 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -1077,7 +1077,7 @@ static inline void put_page(struct page *page) > * get_user_pages and page_mkclean and other calls that race to set up page > * table entries. > */ > -#define GUP_PIN_COUNTING_BIAS (1U << 10) > +#define GUP_PIN_COUNTING_BIAS (1U << 8) > > void unpin_user_page(struct page *page); > void unpin_user_pages_dirty_lock(struct page **pages, unsigned long npages, > > If that fails to repro, then we would be zeroing in on the root cause. > > The branch is here (I just tested it and it seems healthy): > > g...@github.com:johnhubbard/linux.git pin_user_pages_tracking_v11_with_diags Hi, We tested the following branch and here comes results: [root@server consume_mtts]# (master) $ grep foll_pin /proc/vmstat nr_foll_pin_requested 0 nr_foll_pin_returned 0 [root@serer consume_mtts]# (master) $ dmesg [ 425.221459] [ cut here ] [ 425.225894] WARNING: CPU: 1 PID: 6738 at mm/gup.c:61 try_grab_compound_head+0x90/0xa0 [ 425.228021] Modules linked in: mlx5_ib mlx5_core mlxfw mlx4_ib mlx4_en ptp pps_core mlx4_core bonding ip6_gre ip6_tunnel tunnel6 ip_gre gre ip_tunnel rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm ib_uverbs ib_ipoib ib_umad ib_srp scsi_transport_srp rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core [last unloaded: mlxfw] [ 425.235266] CPU: 1 PID: 6738 Comm: consume_mtts Tainted: G O 5.5.0-rc2+ #1 [ 425.237480] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 425.239738] RIP: 0010:try_grab_compound_head+0x90/0xa0 [ 425.241170] Code: 06 48 8d 4f 34 f0 0f b1 57 34 74 cd 85 c0 74 cf 8d 14 06 f0 0f b1 11 74 c0 eb f1 8d 14 06 f0 0f b1 11 74 b5 85 c0 75 f3 eb b5 <0f> 0b 31 c0 c3 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 [ 425.245739] RSP: 0018:c96878a8 EFLAGS: 00010082 [ 425.247124] RAX: 8001 RBX: 7f780488a000 RCX: 0bb0 [ 425.248956] RDX: ea000e031087 RSI: 8a00 RDI: ea000dc58000 [ 425.250761] RBP: ea000e031080 R08: c9687974 R09: 000fffe0 [ 425.252661] R10: R11: 88836256 R12: 008a [ 425.254487] R13: 8003716000e7 R14: 7f780488a000 R15: c9687974 [ 425.256309] FS: 7f780d9d3740() GS:8883b1c8() knlGS: [ 425.258401] CS: 0010 DS: ES: CR0: 80050033 [ 425.259949] CR2: 02334048 CR3: 00039c68c001 CR4: 001606a0 [ 425.261884] Call Trace: [ 425.262735] gup_pgd_range+0x517/0x5a0 [ 425.263819] internal_get_user_pages_fast+0x210/0x250 [ 425.265193] ib_umem_get+0x298/0x550 [ib_uverbs] [ 425.266476] mr_umem_get+0xc9/0x260 [mlx5_ib] [ 425.267699] mlx5_ib_reg_user_mr+0xcc/0x7e0 [mlx5_ib] [ 425.269134] ? xas_load+0x8/0x80 [ 425.270074] ? xa_load+0x48/0x90 [ 425.271038] ? lookup_get_idr_uobject.part.10+0x12/0x70 [ib_uverbs] [ 425.272757] ib_uverbs_reg_mr+0x127/0x280 [ib_uverbs] [ 425.274120] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xc2/0xf0 [ib_uverbs] [ 425.276058] ib_uverbs_cmd_verbs.isra.6+0x5be/0xbe0 [ib_uverbs] [ 425.277657] ? uverbs_disassociate_api+0xd0/0xd0 [ib_uverbs] [ 425.279155] ? __alloc_pages_nodemask+0x148/0x2b0 [ 425.280445] ib_uverbs_ioctl+0xc0/0x120 [ib_uverbs] [ 425.281755] do_vfs_ioctl+0x9d/0x650 [ 425.282766] ksys_ioctl+0x70/0x80 [ 425.283745] __x64_sys_ioctl+0x16/0x20 [ 425.284912] do_syscall_64+0x42/0x130 [ 425.285973] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 425.287377] RIP: 0033:0x7f780d2df267 [ 425.288449] Code: b3 66 90 48 8b 05 19 3c 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01
[Bug 205915] AMDGPU: Screen flicker after resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=205915 --- Comment #4 from onil (o...@pm.me) --- Please disregard comment #3, flickering still occurs when performance level is "auto", after manually switching it to "low" or "high" flickering stops. -- 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
