RE: [PATCH 4/5] drm: rcar-du: Add R8A7744 support
Hello Laurent,
> From: Laurent Pinchart
> Sent: 15 October 2018 23:25
> Subject: Re: [PATCH 4/5] drm: rcar-du: Add R8A7744 support
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Friday, 21 September 2018 21:08:30 EEST Fabrizio Castro wrote:
> > From: Biju Das
> >
> > Add support for the R8A7744 DU (which is very similar to the R8A7743 DU);
> > it has 1 DPAD (RGB) output and 1 LVDS output.
> >
> > Signed-off-by: Biju Das
> > Reviewed-by: Fabrizio Castro
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index c07d3f1..2c3d0e5 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > @@ -321,6 +321,7 @@ static const struct rcar_du_device_info
> > rcar_du_r8a77970_info = {
> >
> > static const struct of_device_id rcar_du_of_table[] = {
> > { .compatible = "renesas,du-r8a7743", .data = _du_r8a7743_info },
> > +{ .compatible = "renesas,du-r8a7744", .data = _du_r8a7743_info },
> > { .compatible = "renesas,du-r8a7745", .data = _du_r8a7745_info },
> > { .compatible = "renesas,du-r8a77470", .data = _du_r8a77470_info },
> > { .compatible = "renesas,du-r8a7779", .data = _du_r8a7779_info },
>
> This looks good to me. I would also apply this change:
>
> @@ -41,7 +41,7 @@ static const struct rcar_du_device_info rzg1_du_r8a7743_info
> = {
> .channels_mask = BIT(1) | BIT(0),
> .routes = {
> /*
> -* R8A7743 has one RGB output and one LVDS output
> +* R8A774[34] has one RGB output and one LVDS output
> */
> [RCAR_DU_OUTPUT_DPAD0] = {
> .possible_crtcs = BIT(1) | BIT(0),
>
> With this,
>
> Reviewed-by: Laurent Pinchart
>
> There's no need to resubmit, I've applied the patch to my tree with the above
> change.
I was expecting to see this patch at least on linux-next by now but it looks
like it's not in there, could you please double check what happened to it?
Thanks,
Fab
>
> --
> Regards,
>
> Laurent Pinchart
>
>
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display/amdgpu_dm/amdgpu_dm.c: Remove duplicate header
Remove dm_services_types.h which is included more than once Signed-off-by: Brajeswar Ghosh --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index e224f23e2215..62a96c683584 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -38,7 +38,6 @@ #include "amd_shared.h" #include "amdgpu_dm_irq.h" #include "dm_helpers.h" -#include "dm_services_types.h" #include "amdgpu_dm_mst_types.h" #if defined(CONFIG_DEBUG_FS) #include "amdgpu_dm_debugfs.h" -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: set is_master to 0 upon drm_new_set_master() failure
When drm_new_set_master() fails, set is_master to 0, to prevent a possible NULL pointer deref. Here is a problematic flow: we check is_master in drm_is_current_master(), then proceed to call drm_lease_owner() passing master. If we do not restore is_master status when drm_new_set_master() fails, we may have a situation in which is_master will be 1 and master itself, NULL, leading to the deref of a NULL pointer in drm_lease_owner(). This fixes the following OOPS, observed on an ArchLinux running a 4.19.2 kernel: [ 97.804282] BUG: unable to handle kernel NULL pointer dereference at 0080 [ 97.807224] PGD 0 P4D 0 [ 97.807224] Oops: [#1] PREEMPT SMP NOPTI [ 97.807224] CPU: 0 PID: 1348 Comm: xfwm4 Tainted: P OE 4.19.2-arch1-1-ARCH #1 [ 97.807224] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./AB350 Pro4, BIOS P5.10 10/16/2018 [ 97.807224] RIP: 0010:drm_lease_owner+0xd/0x20 [drm] [ 97.807224] Code: 83 c4 18 5b 5d c3 b8 ea ff ff ff eb e2 b8 ed ff ff ff eb db e8 b4 ca 68 fb 0f 1f 40 00 0f 1f 44 00 00 48 89 f8 eb 03 48 89 d0 <48> 8b 90 80 00 00 00 48 85 d2 75 f1 c3 66 0f 1f 44 00 00 0f 1f 44 [ 97.807224] RSP: 0018:b8cf08e07bb0 EFLAGS: 00010202 [ 97.807224] RAX: RBX: 9cf0f2586c00 RCX: 9cf0f2586c88 [ 97.807224] RDX: 9cf0ddbd8000 RSI: RDI: [ 97.807224] RBP: 9cf1040e9800 R08: R09: [ 97.807224] R10: deb30fd5d680 R11: deb30f5d6808 R12: 9cf1040e9888 [ 97.807224] R13: R14: dead0200 R15: 9cf0f2586cc8 [ 97.807224] FS: 7f4145513180() GS:9cf10ea0() knlGS: [ 97.807224] CS: 0010 DS: ES: CR0: 80050033 [ 97.807224] CR2: 0080 CR3: 0003d7548000 CR4: 003406f0 [ 97.807224] Call Trace: [ 97.807224] drm_is_current_master+0x1a/0x30 [drm] [ 97.807224] drm_master_release+0x3e/0x130 [drm] [ 97.807224] drm_file_free.part.0+0x2be/0x2d0 [drm] [ 97.807224] drm_open+0x1ba/0x1e0 [drm] [ 97.807224] drm_stub_open+0xaf/0xe0 [drm] [ 97.807224] chrdev_open+0xa3/0x1b0 [ 97.807224] ? cdev_put.part.0+0x20/0x20 [ 97.807224] do_dentry_open+0x132/0x340 [ 97.807224] path_openat+0x2d1/0x14e0 [ 97.807224] ? mem_cgroup_commit_charge+0x7a/0x520 [ 97.807224] do_filp_open+0x93/0x100 [ 97.807224] ? __check_object_size+0x102/0x189 [ 97.807224] ? _raw_spin_unlock+0x16/0x30 [ 97.807224] do_sys_open+0x186/0x210 [ 97.807224] do_syscall_64+0x5b/0x170 [ 97.807224] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 97.807224] RIP: 0033:0x7f4147b07976 [ 97.807224] Code: 89 54 24 08 e8 7b f4 ff ff 8b 74 24 0c 48 8b 3c 24 41 89 c0 44 8b 54 24 08 b8 01 01 00 00 89 f2 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff 77 30 44 89 c7 89 44 24 08 e8 a6 f4 ff ff 8b 44 [ 97.807224] RSP: 002b:7ffcced96ca0 EFLAGS: 0293 ORIG_RAX: 0101 [ 97.807224] RAX: ffda RBX: 5619d5037f80 RCX: 7f4147b07976 [ 97.807224] RDX: 0002 RSI: 5619d46b969c RDI: ff9c [ 98.040039] RBP: 0024 R08: R09: [ 98.040039] R10: R11: 0293 R12: 0024 [ 98.040039] R13: 0012 R14: 5619d5035950 R15: 0012 [ 98.040039] Modules linked in: nct6775 hwmon_vid algif_skcipher af_alg nls_iso8859_1 nls_cp437 vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common arc4 videodev media snd_usb_audio snd_hda_codec_hdmi snd_usbmidi_lib snd_rawmidi snd_seq_device mousedev input_leds iwlmvm mac80211 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec edac_mce_amd kvm_amd snd_hda_core kvm iwlwifi snd_hwdep r8169 wmi_bmof cfg80211 snd_pcm irqbypass snd_timer snd libphy soundcore pinctrl_amd rfkill pcspkr sp5100_tco evdev gpio_amdpt k10temp mac_hid i2c_piix4 wmi pcc_cpufreq acpi_cpufreq vboxnetflt(OE) vboxnetadp(OE) vboxpci(OE) vboxdrv(OE) msr sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto uas usb_storage dm_crypt hid_generic usbhid hid [ 98.040039] dm_mod raid1 md_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc ahci libahci aesni_intel aes_x86_64 libata crypto_simd cryptd glue_helper ccp xhci_pci rng_core scsi_mod xhci_hcd nvidia_drm(POE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm agpgart nvidia_uvm(POE) nvidia_modeset(POE) nvidia(POE) ipmi_devintf ipmi_msghandler [ 98.040039] CR2: 0080 [ 98.040039] ---[ end trace 3b65093b6fe62b2f ]--- [ 98.040039] RIP: 0010:drm_lease_owner+0xd/0x20 [drm] [ 98.040039] Code: 83 c4 18 5b 5d c3 b8 ea ff ff ff eb e2 b8 ed ff ff ff eb db e8 b4 ca 68 fb 0f 1f 40 00 0f 1f 44 00 00 48 89 f8 eb 03 48 89 d0 <48> 8b 90 80 00 00 00 48 85 d2 75 f1 c3 66 0f 1f 44 00 00 0f 1f 44 [ 98.040039] RSP:
[PATCH] drm/amd/amdgpu: Remove duplicate header
Remove gca/gfx_8_0_sh_mask.h which is included more than once Signed-off-by: Brajeswar Ghosh --- drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c index 64e875d528dd..6a0fcd67662a 100644 --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c @@ -37,7 +37,6 @@ #include "gmc/gmc_8_2_sh_mask.h" #include "oss/oss_3_0_d.h" #include "oss/oss_3_0_sh_mask.h" -#include "gca/gfx_8_0_sh_mask.h" #include "dce/dce_10_0_d.h" #include "dce/dce_10_0_sh_mask.h" #include "smu/smu_7_1_3_d.h" -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/display: Remove duplicate header
Remove dce/dce_mem_input.h which is included more than once Signed-off-by: Brajeswar Ghosh --- drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c index d68f951f9869..c41408c3eaf1 100644 --- a/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c +++ b/drivers/gpu/drm/amd/display/dc/dce80/dce80_resource.c @@ -40,7 +40,6 @@ #include "dce/dce_mem_input.h" #include "dce/dce_link_encoder.h" #include "dce/dce_stream_encoder.h" -#include "dce/dce_mem_input.h" #include "dce/dce_ipp.h" #include "dce/dce_transform.h" #include "dce/dce_opp.h" -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/9] drm/msm/adreno: add a2xx
derived from the a3xx driver and tested on the following hardware:
imx51-zii-rdu1 (a200 with 128kb gmem)
imx53-qsrb (a200)
msm8060-tenderloin (a220)
Signed-off-by: Jonathan Marek
Reviewed-by: Jordan Crouse
---
v2:
-fail when MMU is not present (instead of just a warning, matches a3xx)
-removed whitespace and removed "XXX" in comments
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 446 +
drivers/gpu/drm/msm/adreno/a2xx_gpu.h | 21 +
drivers/gpu/drm/msm/adreno/adreno_device.c | 33 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 27 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 15 +
6 files changed, 535 insertions(+), 8 deletions(-)
create mode 100644 drivers/gpu/drm/msm/adreno/a2xx_gpu.c
create mode 100644 drivers/gpu/drm/msm/adreno/a2xx_gpu.h
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 19ab521d4c3a..0170766393ea 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -6,6 +6,7 @@ ccflags-$(CONFIG_DRM_MSM_DSI) += -Idrivers/gpu/drm/msm/dsi
msm-y := \
adreno/adreno_device.o \
adreno/adreno_gpu.o \
+ adreno/a2xx_gpu.o \
adreno/a3xx_gpu.o \
adreno/a4xx_gpu.o \
adreno/a5xx_gpu.o \
diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
new file mode 100644
index ..936242f69f08
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -0,0 +1,446 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018 The Linux Foundation. All rights reserved. */
+
+#include "a2xx_gpu.h"
+
+extern bool hang_debug;
+
+static void a2xx_dump(struct msm_gpu *gpu);
+static bool a2xx_idle(struct msm_gpu *gpu);
+
+static bool a2xx_me_init(struct msm_gpu *gpu)
+{
+ struct msm_ringbuffer *ring = gpu->rb[0];
+
+ OUT_PKT3(ring, CP_ME_INIT, 18);
+
+ /* All fields present (bits 9:0) */
+ OUT_RING(ring, 0x03ff);
+ /* Disable/Enable Real-Time Stream processing (present but ignored) */
+ OUT_RING(ring, 0x);
+ /* Enable (2D <-> 3D) implicit synchronization (present but ignored) */
+ OUT_RING(ring, 0x);
+
+ OUT_RING(ring, REG_A2XX_RB_SURFACE_INFO - 0x2000);
+ OUT_RING(ring, REG_A2XX_PA_SC_WINDOW_OFFSET - 0x2000);
+ OUT_RING(ring, REG_A2XX_VGT_MAX_VTX_INDX - 0x2000);
+ OUT_RING(ring, REG_A2XX_SQ_PROGRAM_CNTL - 0x2000);
+ OUT_RING(ring, REG_A2XX_RB_DEPTHCONTROL - 0x2000);
+ OUT_RING(ring, REG_A2XX_PA_SU_POINT_SIZE - 0x2000);
+ OUT_RING(ring, REG_A2XX_PA_SC_LINE_CNTL - 0x2000);
+ OUT_RING(ring, REG_A2XX_PA_SU_POLY_OFFSET_FRONT_SCALE - 0x2000);
+
+ /* Vertex and Pixel Shader Start Addresses in instructions
+* (3 DWORDS per instruction) */
+ OUT_RING(ring, 0x8180);
+ /* Maximum Contexts */
+ OUT_RING(ring, 0x0001);
+ /* Write Confirm Interval and The CP will wait the
+* wait_interval * 16 clocks between polling */
+ OUT_RING(ring, 0x);
+ /* NQ and External Memory Swap */
+ OUT_RING(ring, 0x);
+ /* protected mode error checking (0x1f2 is REG_AXXX_CP_INT_CNTL) */
+ OUT_RING(ring, 0x21f2);
+ /* Disable header dumping and Header dump address */
+ OUT_RING(ring, 0x);
+ /* Header dump size */
+ OUT_RING(ring, 0x);
+
+ /* enable protected mode */
+ OUT_PKT3(ring, CP_SET_PROTECTED_MODE, 1);
+ OUT_RING(ring, 1);
+
+ gpu->funcs->flush(gpu, ring);
+ return a2xx_idle(gpu);
+}
+
+static int a2xx_hw_init(struct msm_gpu *gpu)
+{
+ struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ uint32_t *ptr, len;
+ int i, ret;
+
+ DBG("%s", gpu->name);
+
+ gpu_write(gpu, REG_A2XX_RBBM_PM_OVERRIDE1, 0xfffe);
+ gpu_write(gpu, REG_A2XX_RBBM_PM_OVERRIDE2, 0x);
+
+ /* note: kgsl uses 0x0001 after first reset on a22x */
+ gpu_write(gpu, REG_A2XX_RBBM_SOFT_RESET, 0x);
+ msleep(30);
+ gpu_write(gpu, REG_A2XX_RBBM_SOFT_RESET, 0x);
+
+ if (adreno_is_a225(adreno_gpu))
+ gpu_write(gpu, REG_A2XX_SQ_FLOW_CONTROL, 0x1800);
+
+ /* note: kgsl uses 0x for a20x */
+ gpu_write(gpu, REG_A2XX_RBBM_CNTL, 0x4442);
+
+ gpu_write(gpu, REG_A2XX_MH_MMU_CONFIG, 0);
+ gpu_write(gpu, REG_A2XX_MH_MMU_MPU_BASE, 0);
+ gpu_write(gpu, REG_A2XX_MH_MMU_MPU_END, 0xf000);
+ gpu_write(gpu, REG_A2XX_MH_ARBITER_CONFIG,
+ A2XX_MH_ARBITER_CONFIG_SAME_PAGE_LIMIT(16) |
+ A2XX_MH_ARBITER_CONFIG_L1_ARB_ENABLE |
+ A2XX_MH_ARBITER_CONFIG_L1_ARB_HOLD_ENABLE |
+ A2XX_MH_ARBITER_CONFIG_PAGE_SIZE(1) |
+ A2XX_MH_ARBITER_CONFIG_TC_REORDER_ENABLE |
+ A2XX_MH_ARBITER_CONFIG_TC_ARB_HOLD_ENABLE |
+
Re: [PATCH 1/9] mm: Introduce new vm_insert_range API
On Wed, Nov 21, 2018 at 04:19:11AM -0700, William Kucharski wrote: > Could you add a line to the description explicitly stating that a failure > to insert any page in the range will fail the entire routine, something > like: > > > * This allows drivers to insert range of kernel pages they've allocated > > * into a user vma. This is a generic function which drivers can use > > * rather than using their own way of mapping range of kernel pages into > > * user vma. > > * > > * A failure to insert any page in the range will fail the call as a whole. > > It's obvious when reading the code, but it would be self-documenting to > state it outright. It's probably better to be more explicit and answer Randy's question: * If we fail to insert any page into the vma, the function will return * immediately leaving any previously-inserted pages present. Callers * from the mmap handler may immediately return the error as their * caller will destroy the vma, removing any successfully-inserted pages. * Other callers should make their own arrangements for calling unmap_region(). Although unmap_region() is static so there clearly isn't any code in the kernel today other than in mmap handlers (or fault handlers) that needs to insert pages into a VMA. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 8/9] phy: Add Cadence D-PHY support
Hi,
On 21/11/18 7:17 PM, Maxime Ripard wrote:
> Hi Kishon,
>
> On Wed, Nov 21, 2018 at 03:59:43PM +0530, Kishon Vijay Abraham I wrote:
>> On 21/11/18 3:41 PM, Maxime Ripard wrote:
>>> Hi Kishon,
>>>
>>> On Tue, Nov 20, 2018 at 11:02:34AM +0530, Kishon Vijay Abraham I wrote:
>> +static int cdns_dphy_config_from_opts(struct phy *phy,
>> + struct
>> phy_configure_opts_mipi_dphy *opts,
>> + struct cdns_dphy_cfg *cfg)
>> +{
>> +struct cdns_dphy *dphy = phy_get_drvdata(phy);
>> +unsigned int dsi_hfp_ext = 0;
>> +int ret;
>> +
>> +ret = phy_mipi_dphy_config_validate(opts);
>> +if (ret)
>> +return ret;
>> +
>> +ret = cdns_dsi_get_dphy_pll_cfg(dphy, cfg,
>> +opts, _hfp_ext);
>> +if (ret)
>> +return ret;
>> +
>> +opts->wakeup = cdns_dphy_get_wakeup_time_ns(dphy);
Is the wakeup populated here used by the consumer driver?
>>>
>>> It's supposed to, if it can yes.
>>
>> But I guess right now it's not using. I'm thinking the usefulness of validate
>> callback (only from this series point of view). Why should a consumer driver
>> invoke validate if it doesn't intend to configure the PHY?
>>
>> The 3 steps required are
>> * The consumer driver gets the default config
>> * The consumer driver changes some of the configuration and
>> * The consumer driver invokes phy configure callback.
>>
>> phy_configure anyways can validate the config before actually configuring
>> the phy.
>
> If you only want to configure the PHY, then yes, sure.
>
> However, the point here is that validate helps negotiating what the
> source device (DSI controller for example) and what the sink device
> (say a panel) are capable of.
>
> A panel for example might very well have multiple resolutions that it
> supports, and the DSI controller will have some as well. And the PHY
> will only be able to operate within certain boundaries too. However,
> they don't necessarily match, since there's so many panels, and so
> many SoCs.
>
> Let's say our (very weird) panel is able to do 640x480, 1024x768 and
> 1280x800. Our DSI driver can only operate with 1024 pixels in both
> dimensions, and the PHY can only reach the bus frequency needed for
> around 800x600.
>
> We'll want to filter out 1280x800 (because the DSI controller can't
> provide that) and 1024x768 (because the PHY can go fast enough), to
> only provide the 640x480 option to the user.
>
> That's what validate bring you. The option to test whether a given
> configuration *would* work, without actually wanting to apply it right
> now.
>
> Does that make sense?
Thank you for the explanation. It's clear now.
Thanks
Kishon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [[PATCH v2]] drm/ast: fixed reading monitor EDID not stable issue
Hi Dave,
Thanks for your feedback. No issue found actually if I remove "volatile" on
my platform. In my experience, if the value is volatile, adding "volatile"
will be safer and no harm, that is why I add it by default. If you think it
is not necessary, it's ok for me to remove it.
Regards,
Y.C. Chen
Dave Airlie 於 2018年11月22日 週四 上午9:15寫道：
> On Wed, 31 Oct 2018 at 18:12, Y.C. Chen wrote:
> >
> > From: "Y.C. Chen"
> >
> > v1: over-sample data to increase the stability with some specific
> monitors
> > v2: refine to avoid infinite loop
>
> This contains at least 4 whitespace breakages (val =) in a few
> places, also why the volatiles, I don't think they make much sense
> here, have you verified they are required?
>
> Dave.
>
> >
> > Signed-off-by: Y.C. Chen
> > ---
> > drivers/gpu/drm/ast/ast_mode.c | 34 --
> > 1 file changed, 28 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ast/ast_mode.c
> b/drivers/gpu/drm/ast/ast_mode.c
> > index 5e77d45..092e9a7 100644
> > --- a/drivers/gpu/drm/ast/ast_mode.c
> > +++ b/drivers/gpu/drm/ast/ast_mode.c
> > @@ -972,9 +972,20 @@ static int get_clock(void *i2c_priv)
> > {
> > struct ast_i2c_chan *i2c = i2c_priv;
> > struct ast_private *ast = i2c->dev->dev_private;
> > - uint32_t val;
> > + volatile uint32_t val, val2, count, pass;
> > +
> > + count = 0;
> > + pass = 0;
> > + val = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7,
> 0x10) >> 4) & 0x01;
> > + do {
> > + val2 = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT,
> 0xb7, 0x10) >> 4) & 0x01;
> > + if (val == val2) pass++;
> > + else {
> > + pass = 0;
> > + val = (ast_get_index_reg_mask(ast,
> AST_IO_CRTC_PORT, 0xb7, 0x10) >> 4) & 0x01;
>
>
>
>
> > + }
> > + } while ((pass < 5) && (count++ < 0x1));
> >
> > - val = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7, 0x10)
> >> 4;
> > return val & 1 ? 1 : 0;
> > }
> >
> > @@ -982,9 +993,20 @@ static int get_data(void *i2c_priv)
> > {
> > struct ast_i2c_chan *i2c = i2c_priv;
> > struct ast_private *ast = i2c->dev->dev_private;
> > - uint32_t val;
> > + volatile uint32_t val, val2, count, pass;
> > +
> > + count = 0;
> > + pass = 0;
> > + val = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7,
> 0x20) >> 5) & 0x01;
> > + do {
> > + val2 = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT,
> 0xb7, 0x20) >> 5) & 0x01;
> > + if (val == val2) pass++;
> > + else {
> > + pass = 0;
> > + val = (ast_get_index_reg_mask(ast,
> AST_IO_CRTC_PORT, 0xb7, 0x20) >> 5) & 0x01;
> > + }
> > + } while ((pass < 5) && (count++ < 0x1));
> >
> > - val = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7, 0x20)
> >> 5;
> > return val & 1 ? 1 : 0;
> > }
> >
> > @@ -997,7 +1019,7 @@ static void set_clock(void *i2c_priv, int clock)
> >
> > for (i = 0; i < 0x1; i++) {
> > ujcrb7 = ((clock & 0x01) ? 0 : 1);
> > - ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7,
> 0xfe, ujcrb7);
> > + ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7,
> 0xf4, ujcrb7);
> > jtemp = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT,
> 0xb7, 0x01);
> > if (ujcrb7 == jtemp)
> > break;
> > @@ -1013,7 +1035,7 @@ static void set_data(void *i2c_priv, int data)
> >
> > for (i = 0; i < 0x1; i++) {
> > ujcrb7 = ((data & 0x01) ? 0 : 1) << 2;
> > - ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7,
> 0xfb, ujcrb7);
> > + ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7,
> 0xf1, ujcrb7);
> > jtemp = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT,
> 0xb7, 0x04);
> > if (ujcrb7 == jtemp)
> > break;
> > --
> > 1.8.3.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
[PATCH v2 8/9] drm/msm/mdp5: add config for msm8917
Add the mdp5_cfg_hw entry for MDP5 version v1.15 found on msm8917.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 86
1 file changed, 86 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 824067d2d427..05ad159b6261 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -553,6 +553,91 @@ const struct mdp5_cfg_hw msm8x96_config = {
.max_clk = 41250,
};
+const struct mdp5_cfg_hw msm8917_config = {
+ .name = "msm8917",
+ .mdp = {
+ .count = 1,
+ .caps = MDP_CAP_CDM,
+ },
+ .ctl = {
+ .count = 3,
+ .base = { 0x01000, 0x01200, 0x01400 },
+ .flush_hw_mask = 0x,
+ },
+ .pipe_vig = {
+ .count = 1,
+ .base = { 0x04000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SCALE |
+ MDP_PIPE_CAP_CSC|
+ MDP_PIPE_CAP_DECIMATION |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_rgb = {
+ .count = 2,
+ .base = { 0x14000, 0x16000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_DECIMATION |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_dma = {
+ .count = 1,
+ .base = { 0x24000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ 0,
+ },
+ .pipe_cursor = {
+ .count = 1,
+ .base = { 0x34000 },
+ .caps = MDP_PIPE_CAP_HFLIP |
+ MDP_PIPE_CAP_VFLIP |
+ MDP_PIPE_CAP_SW_PIX_EXT |
+ MDP_PIPE_CAP_CURSOR |
+ 0,
+ },
+
+ .lm = {
+ .count = 2,
+ .base = { 0x44000, 0x45000 },
+ .instances = {
+ { .id = 0, .pp = 0, .dspp = 0,
+ .caps = MDP_LM_CAP_DISPLAY, },
+ { .id = 1, .pp = -1, .dspp = -1,
+ .caps = MDP_LM_CAP_WB },
+},
+ .nb_stages = 8,
+ .max_width = 2048,
+ .max_height = 0x,
+ },
+ .dspp = {
+ .count = 1,
+ .base = { 0x54000 },
+
+ },
+ .pp = {
+ .count = 1,
+ .base = { 0x7 },
+ },
+ .cdm = {
+ .count = 1,
+ .base = { 0x79200 },
+ },
+ .intf = {
+ .base = { 0x6a000, 0x6a800 },
+ .connect = {
+ [0] = INTF_DISABLED,
+ [1] = INTF_DSI,
+ },
+ },
+ .max_clk = 32000,
+};
+
static const struct mdp5_cfg_handler cfg_handlers[] = {
{ .revision = 0, .config = { .hw = _config } },
{ .revision = 2, .config = { .hw = _config } },
@@ -560,6 +645,7 @@ static const struct mdp5_cfg_handler cfg_handlers[] = {
{ .revision = 6, .config = { .hw = _config } },
{ .revision = 9, .config = { .hw = _config } },
{ .revision = 7, .config = { .hw = _config } },
+ { .revision = 15, .config = { .hw = _config } },
};
static struct mdp5_cfg_platform *mdp5_get_config(struct platform_device *dev);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] Use vm_insert_range
On 11/21/18 1:24 AM, Souptick Joarder wrote: > On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder wrote: >> Previouly drivers have their own way of mapping range of >> kernel pages/memory into user vma and this was done by >> invoking vm_insert_page() within a loop. >> >> As this pattern is common across different drivers, it can >> be generalized by creating a new function and use it across >> the drivers. >> >> vm_insert_range is the new API which will be used to map a >> range of kernel memory/pages to user vma. >> >> All the applicable places are converted to use new vm_insert_range >> in this patch series. >> >> Souptick Joarder (9): >> mm: Introduce new vm_insert_range API >> arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range >> drivers/firewire/core-iso.c: Convert to use vm_insert_range >> drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range >> drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range >> iommu/dma-iommu.c: Convert to use vm_insert_range >> videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range >> xen/gntdev.c: Convert to use vm_insert_range >> xen/privcmd-buf.c: Convert to use vm_insert_range > Any further comment on driver changes ? Xen drivers (the last two patches) look fine to me. -boris >> arch/arm/mm/dma-mapping.c | 21 ++--- >> drivers/firewire/core-iso.c | 15 ++-- >> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 20 ++-- >> drivers/gpu/drm/xen/xen_drm_front_gem.c | 20 +--- >> drivers/iommu/dma-iommu.c | 12 ++ >> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 23 ++- >> drivers/xen/gntdev.c | 11 - >> drivers/xen/privcmd-buf.c | 8 ++- >> include/linux/mm_types.h | 3 +++ >> mm/memory.c | 28 >> +++ >> mm/nommu.c| 7 ++ >> 11 files changed, 70 insertions(+), 98 deletions(-) >> >> -- >> 1.9.1 >> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ast: change resolution may cause screen blurred
On Wed, 3 Oct 2018 14:57:47 +0800, Y.C. Chen wrote: > From: "Y.C. Chen" > > The value of pitches is not correct while calling mode_set. > The issue we found so far on following system: > - Debian8 with XFCE Desktop > - Ubuntu with KDE Desktop > - SUSE15 with KDE Desktop > > Signed-off-by: Y.C. Chen > --- > drivers/gpu/drm/ast/ast_mode.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c > index 5e77d45..f06aae7 100644 > --- a/drivers/gpu/drm/ast/ast_mode.c > +++ b/drivers/gpu/drm/ast/ast_mode.c > @@ -568,6 +568,7 @@ static int ast_crtc_do_set_base(struct drm_crtc *crtc, > } > ast_bo_unreserve(bo); > > + ast_set_offset_reg(crtc); > ast_set_start_address_crt1(crtc, (u32)gpu_addr); > > return 0; Tested-by: Jean Delvare Reviewed-by: Jean Delvare I did experience the mentioned display corruption on resolution change on an ASPEED 1100/2050 chipset, under Plasma (KDE). I can confirm that the patch above prevents it. There is also a report in openSUSE's bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=1112963 where the user tested the patch above successfully on an ASPEED 2500 chipset. Can we get the fix merged now? Thanks, -- Jean Delvare SUSE L3 Support ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 6/6] drm/omap: add support for manually updated displays
This adds the required infrastructure for manually updated displays,
such as DSI command mode panels. While those panels often support
partial updates we currently always do a full refresh.
The display will be refreshed when something calls the dirty callback,
such as libdrm's drmModeDirtyFB(). This is currently being done at least
by the kernel console and Xorg (with modesetting driver) in their
default configuration. Weston does not implement this and the fbdev
backend does not work (display will not update). Weston's DRM backend
uses double buffering and the page flip will trigger a display refresh
and seems to work as expected.
Acked-by: Pavel Machek
Tested-by: Tony Lindgren
Tested-by: Pavel Machek
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 117 ++--
drivers/gpu/drm/omapdrm/omap_crtc.h | 1 +
drivers/gpu/drm/omapdrm/omap_fb.c | 41 ++
3 files changed, 154 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 59ee2399f2e9..aed8d61d2783 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -33,6 +33,7 @@ struct omap_crtc_state {
/* Shadow values for legacy userspace support. */
unsigned int rotation;
unsigned int zpos;
+ bool manually_updated;
};
#define to_omap_crtc(x) container_of(x, struct omap_crtc, base)
@@ -52,6 +53,7 @@ struct omap_crtc {
bool pending;
wait_queue_head_t pending_wait;
struct drm_pending_vblank_event *event;
+ struct delayed_work update_work;
void (*framedone_handler)(void *);
void *framedone_handler_data;
@@ -106,21 +108,18 @@ int omap_crtc_wait_pending(struct drm_crtc *crtc)
/*
* Manager-ops, callbacks from output when they need to configure
* the upstream part of the video pipe.
- *
- * Most of these we can ignore until we add support for command-mode
- * panels.. for video-mode the crtc-helpers already do an adequate
- * job of sequencing the setup of the video pipe in the proper order
*/
-/* we can probably ignore these until we support command-mode panels: */
static void omap_crtc_dss_start_update(struct omap_drm_private *priv,
enum omap_channel channel)
{
+ priv->dispc_ops->mgr_enable(priv->dispc, channel, true);
}
/* Called only from the encoder enable/disable and suspend/resume handlers. */
static void omap_crtc_set_enabled(struct drm_crtc *crtc, bool enable)
{
+ struct omap_crtc_state *omap_state = to_omap_crtc_state(crtc->state);
struct drm_device *dev = crtc->dev;
struct omap_drm_private *priv = dev->dev_private;
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
@@ -132,6 +131,12 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc,
bool enable)
if (WARN_ON(omap_crtc->enabled == enable))
return;
+ if (omap_state->manually_updated) {
+ omap_irq_enable_framedone(crtc, enable);
+ omap_crtc->enabled = enable;
+ return;
+ }
+
if (omap_crtc->pipe->output->output_type == OMAP_DISPLAY_TYPE_HDMI) {
priv->dispc_ops->mgr_enable(priv->dispc, channel, enable);
omap_crtc->enabled = enable;
@@ -353,6 +358,54 @@ void omap_crtc_framedone_irq(struct drm_crtc *crtc,
uint32_t irqstatus)
wake_up(_crtc->pending_wait);
}
+void omap_crtc_flush(struct drm_crtc *crtc)
+{
+ struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+ struct omap_crtc_state *omap_state = to_omap_crtc_state(crtc->state);
+
+ if (!omap_state->manually_updated)
+ return;
+
+ if (!delayed_work_pending(_crtc->update_work))
+ schedule_delayed_work(_crtc->update_work, 0);
+}
+
+static void omap_crtc_manual_display_update(struct work_struct *data)
+{
+ struct omap_crtc *omap_crtc =
+ container_of(data, struct omap_crtc, update_work.work);
+ struct omap_dss_device *dssdev = omap_crtc->pipe->display;
+ struct drm_device *dev = omap_crtc->base.dev;
+ const struct omap_dss_driver *dssdrv;
+ struct videomode vm = {0};
+ int ret;
+
+ if (!dssdev) {
+ dev_err_once(dev->dev, "missing display dssdev!");
+ return;
+ }
+
+ dssdrv = dssdev->driver;
+ if (!dssdrv || !dssdrv->update) {
+ dev_err_once(dev->dev, "missing or incorrect dssdrv!");
+ return;
+ }
+
+ if (dssdrv->sync)
+ dssdrv->sync(dssdev);
+
+ if (dssdev->ops->get_timings)
+ dssdev->ops->get_timings(dssdev, );
+
+ ret = dssdrv->update(dssdev, 0, 0, vm.hactive, vm.vactive);
+ if (ret < 0) {
+ spin_lock_irq(>event_lock);
+ omap_crtc->pending = false;
+ spin_unlock_irq(>event_lock);
+
[PATCHv5 3/6] drm/omap: don't check dispc timings for DSI
While most display types only forward their VM to the DISPC, this
is not true for DSI. DSI calculates the VM for DISPC based on its
own, but it's not identical. Actually the DSI VM is not even a valid
DISPC VM making this check fail. Let's restore the old behaviour
and avoid checking the DISPC VM for DSI here.
Fixes: 7c27fa57ef31 ("drm/omap: Call dispc timings check operation directly")
Acked-by: Pavel Machek
Tested-by: Tony Lindgren
Tested-by: Pavel Machek
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_connector.c | 8 +---
drivers/gpu/drm/omapdrm/omap_encoder.c | 8 +---
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
b/drivers/gpu/drm/omapdrm/omap_connector.c
index b81302c4bf9e..5c776d6211e1 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -280,9 +280,11 @@ static int omap_connector_mode_valid(struct drm_connector
*connector,
drm_display_mode_to_videomode(mode, );
mode->vrefresh = drm_mode_vrefresh(mode);
- r = priv->dispc_ops->mgr_check_timings(priv->dispc, channel, );
- if (r)
- goto done;
+ if (omap_connector->display->type != OMAP_DISPLAY_TYPE_DSI) {
+ r = priv->dispc_ops->mgr_check_timings(priv->dispc, channel,
);
+ if (r)
+ goto done;
+ }
for (dssdev = omap_connector->output; dssdev; dssdev = dssdev->next) {
if (!dssdev->ops->check_timings)
diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c
b/drivers/gpu/drm/omapdrm/omap_encoder.c
index 452e625f6ce3..32bbe3a80e7d 100644
--- a/drivers/gpu/drm/omapdrm/omap_encoder.c
+++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
@@ -170,9 +170,11 @@ static int omap_encoder_atomic_check(struct drm_encoder
*encoder,
drm_display_mode_to_videomode(_state->mode, );
- ret = priv->dispc_ops->mgr_check_timings(priv->dispc, channel, );
- if (ret)
- goto done;
+ if (omap_encoder->display->type != OMAP_DISPLAY_TYPE_DSI) {
+ ret = priv->dispc_ops->mgr_check_timings(priv->dispc, channel,
);
+ if (ret)
+ goto done;
+ }
for (dssdev = omap_encoder->output; dssdev; dssdev = dssdev->next) {
if (!dssdev->ops->check_timings)
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 08/12] dt-bindings: mediatek: Change the binding for mmsys clocks
On 21/11/2018 17:46, Stephen Boyd wrote:
> Quoting Rob Herring (2018-11-19 11:15:16)
>> On Sun, Nov 18, 2018 at 11:12 AM Matthias Brugger
>> wrote:
>>> On 11/17/18 12:15 AM, Rob Herring wrote:
On Fri, Nov 16, 2018 at 01:54:45PM +0100, matthias@kernel.org wrote:
> -#clock-cells = <1>;
> +
> +mmsys_clk: clock-controller@1400 {
> +compatible = "mediatek,mt2712-mmsys-clk";
> +#clock-cells = <1>;
This goes against the general direction of not defining separate nodes
for providers with no resources.
Why do you need this and what does it buy if you have to continue to
support the existing chips?
>>>
>>> It would show explicitly that the mmsys block is used to probe two
>>> drivers, one for the gpu and one for the clocks. Otherwise that is
>>> hidden in the drm driver code. I think it is cleaner to describe that in
>>> the device tree.
>>
>> No, that's maybe cleaner for the driver implementation in the Linux
>> kernel. What about other OS's or when Linux drivers and subsystems
>> needs change? Cleaner for DT is design bindings that reflect the h/w.
>> Hardware is sometimes just messy.
>>
>
> I agree. I fail to see what this patch series is doing besides changing
> driver probe and device creation methods and making a backwards
> incompatible change to DT. Is there any other benefit here?
>
You are referring whole series?
Citing the cover letter:
"MMSYS in Mediatek SoCs has some registers to control clock gates (which is
used in the clk driver) and some registers to set the routing and enable
the differnet (sic!) blocks of the display subsystem.
Up to now both drivers, clock and drm are probed with the same device tree
compatible. But only the first driver get probed, which in effect breaks
graphics on mt8173 and mt2701.
This patch uses a platform device registration in the DRM driver, which
will trigger the probe of the corresponding clock driver. It was tested on the
bananapi-r2 and the Acer R13 Chromebook."
DT is broken right now, because two drivers rely on the same node, which gets
consumed just once. The new DT introduced does not break anything because it is
only used for boards that: "[..] are not available to the general public
(mt2712e) or only have the mmsys clock driver part implemented (mt6797)."
Anyway, I'll send a new version which uses the platform device in the DRM driver
for all SoCs.
Regards,
Matthias
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/9] drm/msm/mdp4: only use lut_clk on mdp4.2+
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index ae25d763cd8c..8f765f284d11 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -206,7 +206,8 @@ int mdp4_disable(struct mdp4_kms *mdp4_kms)
clk_disable_unprepare(mdp4_kms->clk);
if (mdp4_kms->pclk)
clk_disable_unprepare(mdp4_kms->pclk);
- clk_disable_unprepare(mdp4_kms->lut_clk);
+ if (mdp4_kms->lut_clk)
+ clk_disable_unprepare(mdp4_kms->lut_clk);
if (mdp4_kms->axi_clk)
clk_disable_unprepare(mdp4_kms->axi_clk);
@@ -220,7 +221,8 @@ int mdp4_enable(struct mdp4_kms *mdp4_kms)
clk_prepare_enable(mdp4_kms->clk);
if (mdp4_kms->pclk)
clk_prepare_enable(mdp4_kms->pclk);
- clk_prepare_enable(mdp4_kms->lut_clk);
+ if (mdp4_kms->lut_clk)
+ clk_prepare_enable(mdp4_kms->lut_clk);
if (mdp4_kms->axi_clk)
clk_prepare_enable(mdp4_kms->axi_clk);
@@ -472,12 +474,13 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
if (IS_ERR(mdp4_kms->pclk))
mdp4_kms->pclk = NULL;
- // XXX if (rev >= MDP_REV_42) { ???
- mdp4_kms->lut_clk = devm_clk_get(>dev, "lut_clk");
- if (IS_ERR(mdp4_kms->lut_clk)) {
- dev_err(dev->dev, "failed to get lut_clk\n");
- ret = PTR_ERR(mdp4_kms->lut_clk);
- goto fail;
+ if (mdp4_kms->rev >= 2) {
+ mdp4_kms->lut_clk = devm_clk_get(>dev, "lut_clk");
+ if (IS_ERR(mdp4_kms->lut_clk)) {
+ dev_err(dev->dev, "failed to get lut_clk\n");
+ ret = PTR_ERR(mdp4_kms->lut_clk);
+ goto fail;
+ }
}
mdp4_kms->axi_clk = devm_clk_get(>dev, "bus_clk");
@@ -488,7 +491,8 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
}
clk_set_rate(mdp4_kms->clk, config->max_clk);
- clk_set_rate(mdp4_kms->lut_clk, config->max_clk);
+ if (mdp4_kms->lut_clk)
+ clk_set_rate(mdp4_kms->lut_clk, config->max_clk);
pm_runtime_enable(dev->dev);
mdp4_kms->rpm_enabled = true;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] mm: Introduce new vm_insert_range API
> On Nov 21, 2018, at 5:35 AM, Matthew Wilcox wrote: > > It's probably better to be more explicit and answer Randy's question: > > * If we fail to insert any page into the vma, the function will return > * immediately leaving any previously-inserted pages present. Callers > * from the mmap handler may immediately return the error as their > * caller will destroy the vma, removing any successfully-inserted pages. > * Other callers should make their own arrangements for calling unmap_region(). That works for me as well. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and managed_pages to atomic.
On 2018-10-22 1:23 p.m., Arun KS wrote: > Remove managed_page_count_lock spinlock and instead use atomic > variables. > > Suggested-by: Michal Hocko > Suggested-by: Vlastimil Babka > Signed-off-by: Arun KS Acked-by: Felix Kuehling Regards, Felix > > --- > As discussed here, > https://patchwork.kernel.org/patch/10627521/#22261253 > --- > --- > arch/csky/mm/init.c | 4 +- > arch/powerpc/platforms/pseries/cmm.c | 11 ++-- > arch/s390/mm/init.c | 2 +- > arch/um/kernel/mem.c | 4 +- > arch/x86/kernel/cpu/microcode/core.c | 5 +- > drivers/char/agp/backend.c| 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +- > drivers/gpu/drm/i915/i915_gem.c | 2 +- > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +- > drivers/hv/hv_balloon.c | 19 +++ > drivers/md/dm-bufio.c | 5 +- > drivers/md/dm-crypt.c | 4 +- > drivers/md/dm-integrity.c | 4 +- > drivers/md/dm-stats.c | 3 +- > drivers/media/platform/mtk-vpu/mtk_vpu.c | 3 +- > drivers/misc/vmw_balloon.c| 2 +- > drivers/parisc/ccio-dma.c | 5 +- > drivers/parisc/sba_iommu.c| 5 +- > drivers/staging/android/ion/ion_system_heap.c | 2 +- > drivers/xen/xen-selfballoon.c | 7 +-- > fs/ceph/super.h | 3 +- > fs/file_table.c | 9 ++-- > fs/fuse/inode.c | 4 +- > fs/nfs/write.c| 3 +- > fs/nfsd/nfscache.c| 3 +- > fs/ntfs/malloc.h | 2 +- > fs/proc/base.c| 3 +- > include/linux/highmem.h | 2 +- > include/linux/mm.h| 2 +- > include/linux/mmzone.h| 10 +--- > include/linux/swap.h | 2 +- > kernel/fork.c | 6 +-- > kernel/kexec_core.c | 5 +- > kernel/power/snapshot.c | 2 +- > lib/show_mem.c| 3 +- > mm/highmem.c | 2 +- > mm/huge_memory.c | 2 +- > mm/kasan/quarantine.c | 4 +- > mm/memblock.c | 6 +-- > mm/memory_hotplug.c | 4 +- > mm/mm_init.c | 3 +- > mm/oom_kill.c | 2 +- > mm/page_alloc.c | 75 > ++- > mm/shmem.c| 12 +++-- > mm/slab.c | 3 +- > mm/swap.c | 3 +- > mm/util.c | 2 +- > mm/vmalloc.c | 4 +- > mm/vmstat.c | 4 +- > mm/workingset.c | 2 +- > mm/zswap.c| 2 +- > net/dccp/proto.c | 6 +-- > net/decnet/dn_route.c | 2 +- > net/ipv4/tcp_metrics.c| 2 +- > net/netfilter/nf_conntrack_core.c | 6 +-- > net/netfilter/xt_hashlimit.c | 4 +- > net/sctp/protocol.c | 6 +-- > security/integrity/ima/ima_kexec.c| 2 +- > 58 files changed, 171 insertions(+), 143 deletions(-) > > diff --git a/arch/csky/mm/init.c b/arch/csky/mm/init.c > index dc07c07..3f4d35e 100644 > --- a/arch/csky/mm/init.c > +++ b/arch/csky/mm/init.c > @@ -71,7 +71,7 @@ void free_initrd_mem(unsigned long start, unsigned long end) > ClearPageReserved(virt_to_page(start)); > init_page_count(virt_to_page(start)); > free_page(start); > - totalram_pages++; > + atomic_long_inc(_pages); > } > } > #endif > @@ -88,7 +88,7 @@ void free_initmem(void) > ClearPageReserved(virt_to_page(addr)); > init_page_count(virt_to_page(addr)); > free_page(addr); > - totalram_pages++; > + atomic_long_inc(_pages); > addr += PAGE_SIZE; > } > > diff --git a/arch/powerpc/platforms/pseries/cmm.c > b/arch/powerpc/platforms/pseries/cmm.c > index 25427a4..85fe503 100644 > --- a/arch/powerpc/platforms/pseries/cmm.c > +++ b/arch/powerpc/platforms/pseries/cmm.c > @@ -208,7 +208,7 @@ static long cmm_alloc_pages(long nr) > > pa->page[pa->index++] = addr; > loaned_pages++; > - totalram_pages--; > + atomic_long_dec(_pages); >
[PATCH v2 5/9] drm/msm: add headless gpu device (for imx5)
This patch allows using drm/msm without qcom display hardware. This is
especially useful for iMX5 hardware, which has a a2xx GPU but uses the
imx-drm driver for display.
Signed-off-by: Jonathan Marek
---
v2: added commit message and removed unnecessary comment
drivers/gpu/drm/msm/Kconfig | 4 ++--
drivers/gpu/drm/msm/msm_debugfs.c | 2 +-
drivers/gpu/drm/msm/msm_drv.c | 21 +++--
3 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 843a9d40c05e..cf549f1ed403 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -2,7 +2,7 @@
config DRM_MSM
tristate "MSM DRM"
depends on DRM
- depends on ARCH_QCOM || (ARM && COMPILE_TEST)
+ depends on ARCH_QCOM || SOC_IMX5 || (ARM && COMPILE_TEST)
depends on OF && COMMON_CLK
depends on MMU
select QCOM_MDT_LOADER if ARCH_QCOM
@@ -11,7 +11,7 @@ config DRM_MSM
select DRM_PANEL
select SHMEM
select TMPFS
- select QCOM_SCM
+ select QCOM_SCM if ARCH_QCOM
select WANT_DEV_COREDUMP
select SND_SOC_HDMI_CODEC if SND_SOC
select SYNC_FILE
diff --git a/drivers/gpu/drm/msm/msm_debugfs.c
b/drivers/gpu/drm/msm/msm_debugfs.c
index f0da0d3c8a80..1ca99ca356a4 100644
--- a/drivers/gpu/drm/msm/msm_debugfs.c
+++ b/drivers/gpu/drm/msm/msm_debugfs.c
@@ -235,7 +235,7 @@ int msm_debugfs_init(struct drm_minor *minor)
debugfs_create_file("gpu", S_IRUSR, minor->debugfs_root,
dev, _gpu_fops);
- if (priv->kms->funcs->debugfs_init) {
+ if (priv->kms && priv->kms->funcs->debugfs_init) {
ret = priv->kms->funcs->debugfs_init(priv->kms, minor);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9f219e02f3c7..3f35e57202ef 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -344,6 +344,7 @@ static int msm_drm_uninit(struct device *dev)
return 0;
}
+#define KMS_HEADLESS 1
#define KMS_MDP4 4
#define KMS_MDP5 5
#define KMS_DPU 3
@@ -495,6 +496,9 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
msm_gem_shrinker_init(ddev);
switch (get_mdp_ver(pdev)) {
+ case KMS_HEADLESS:
+ priv->kms = kms = NULL;
+ break;
case KMS_MDP4:
kms = mdp4_kms_init(ddev);
priv->kms = kms;
@@ -512,12 +516,6 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
}
if (IS_ERR(kms)) {
- /*
-* NOTE: once we have GPU support, having no kms should not
-* be considered fatal.. ideally we would still support gpu
-* and (for example) use dmabuf/prime to share buffers with
-* imx drm driver on iMX5
-*/
dev_err(dev, "failed to load kms\n");
ret = PTR_ERR(kms);
goto err_msm_uninit;
@@ -633,7 +631,7 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
drm_mode_config_reset(ddev);
#ifdef CONFIG_DRM_FBDEV_EMULATION
- if (fbdev)
+ if (kms && fbdev)
priv->fbdev = msm_fbdev_init(ddev);
#endif
@@ -1315,9 +1313,11 @@ static int msm_pdev_probe(struct platform_device *pdev)
struct component_match *match = NULL;
int ret;
- ret = add_display_components(>dev, );
- if (ret)
- return ret;
+ if (get_mdp_ver(pdev) != KMS_HEADLESS) {
+ ret = add_display_components(>dev, );
+ if (ret)
+ return ret;
+ }
ret = add_gpu_components(>dev, );
if (ret)
@@ -1342,6 +1342,7 @@ static int msm_pdev_remove(struct platform_device *pdev)
}
static const struct of_device_id dt_match[] = {
+ { .compatible = "qcom,adreno-headless", .data = (void *)KMS_HEADLESS },
{ .compatible = "qcom,mdp4", .data = (void *)KMS_MDP4 },
{ .compatible = "qcom,mdss", .data = (void *)KMS_MDP5 },
{ .compatible = "qcom,sdm845-mdss", .data = (void *)KMS_DPU },
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] mm: Introduce new vm_insert_range API
Could you add a line to the description explicitly stating that a failure to insert any page in the range will fail the entire routine, something like: > * This allows drivers to insert range of kernel pages they've allocated > * into a user vma. This is a generic function which drivers can use > * rather than using their own way of mapping range of kernel pages into > * user vma. > * > * A failure to insert any page in the range will fail the call as a whole. It's obvious when reading the code, but it would be self-documenting to state it outright. Thanks! -- Bill ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and managed_pages to atomic.
On Mon, Oct 22, 2018 at 10:53:22PM +0530, Arun KS wrote: > Remove managed_page_count_lock spinlock and instead use atomic > variables. > > Suggested-by: Michal Hocko > Suggested-by: Vlastimil Babka > Signed-off-by: Arun KS > > --- > As discussed here, > https://patchwork.kernel.org/patch/10627521/#22261253 > --- > --- > arch/csky/mm/init.c | 4 +- > arch/powerpc/platforms/pseries/cmm.c | 11 ++-- > arch/s390/mm/init.c | 2 +- > arch/um/kernel/mem.c | 4 +- > arch/x86/kernel/cpu/microcode/core.c | 5 +- > drivers/char/agp/backend.c| 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +- > drivers/gpu/drm/i915/i915_gem.c | 2 +- > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +- > drivers/hv/hv_balloon.c | 19 +++ > drivers/md/dm-bufio.c | 5 +- > drivers/md/dm-crypt.c | 4 +- > drivers/md/dm-integrity.c | 4 +- > drivers/md/dm-stats.c | 3 +- > drivers/media/platform/mtk-vpu/mtk_vpu.c | 3 +- > drivers/misc/vmw_balloon.c| 2 +- > drivers/parisc/ccio-dma.c | 5 +- > drivers/parisc/sba_iommu.c| 5 +- > drivers/staging/android/ion/ion_system_heap.c | 2 +- > drivers/xen/xen-selfballoon.c | 7 +-- > fs/ceph/super.h | 3 +- > fs/file_table.c | 9 ++-- > fs/fuse/inode.c | 4 +- > fs/nfs/write.c| 3 +- > fs/nfsd/nfscache.c| 3 +- > fs/ntfs/malloc.h | 2 +- > fs/proc/base.c| 3 +- > include/linux/highmem.h | 2 +- > include/linux/mm.h| 2 +- > include/linux/mmzone.h| 10 +--- > include/linux/swap.h | 2 +- > kernel/fork.c | 6 +-- > kernel/kexec_core.c | 5 +- > kernel/power/snapshot.c | 2 +- > lib/show_mem.c| 3 +- > mm/highmem.c | 2 +- > mm/huge_memory.c | 2 +- > mm/kasan/quarantine.c | 4 +- > mm/memblock.c | 6 +-- > mm/memory_hotplug.c | 4 +- > mm/mm_init.c | 3 +- > mm/oom_kill.c | 2 +- > mm/page_alloc.c | 75 > ++- > mm/shmem.c| 12 +++-- > mm/slab.c | 3 +- > mm/swap.c | 3 +- > mm/util.c | 2 +- > mm/vmalloc.c | 4 +- > mm/vmstat.c | 4 +- > mm/workingset.c | 2 +- > mm/zswap.c| 2 +- > net/dccp/proto.c | 6 +-- > net/decnet/dn_route.c | 2 +- > net/ipv4/tcp_metrics.c| 2 +- > net/netfilter/nf_conntrack_core.c | 6 +-- > net/netfilter/xt_hashlimit.c | 4 +- > net/sctp/protocol.c | 6 +-- > security/integrity/ima/ima_kexec.c| 2 +- > 58 files changed, 171 insertions(+), 143 deletions(-) > > diff --git a/arch/csky/mm/init.c b/arch/csky/mm/init.c > index dc07c07..3f4d35e 100644 > --- a/arch/csky/mm/init.c > +++ b/arch/csky/mm/init.c > @@ -71,7 +71,7 @@ void free_initrd_mem(unsigned long start, unsigned long end) > ClearPageReserved(virt_to_page(start)); > init_page_count(virt_to_page(start)); > free_page(start); > - totalram_pages++; > + atomic_long_inc(_pages); > } > } > #endif > @@ -88,7 +88,7 @@ void free_initmem(void) > ClearPageReserved(virt_to_page(addr)); > init_page_count(virt_to_page(addr)); > free_page(addr); > - totalram_pages++; > + atomic_long_inc(_pages); > addr += PAGE_SIZE; > } For csky part, it's OK. Guo Ren ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm: msm: Replace dma_map_sg with dma_sync_sg*
Hi Tomasz, Jordan,
On 11/21/2018 9:18 AM, Tomasz Figa wrote:
Hi Jordan, Vivek,
On Wed, Nov 21, 2018 at 12:41 AM Jordan Crouse wrote:
On Tue, Nov 20, 2018 at 03:24:37PM +0530, Vivek Gautam wrote:
dma_map_sg() expects a DMA domain. However, the drm devices
have been traditionally using unmanaged iommu domain which
is non-dma type. Using dma mapping APIs with that domain is bad.
Replace dma_map_sg() calls with dma_sync_sg_for_device{|cpu}()
to do the cache maintenance.
Signed-off-by: Vivek Gautam
Suggested-by: Tomasz Figa
---
Tested on an MTP sdm845:
https://github.com/vivekgautam1/linux/tree/v4.19/sdm845-mtp-display-working
drivers/gpu/drm/msm/msm_gem.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 00c795ced02c..d7a7af610803 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -81,6 +81,8 @@ static struct page **get_pages(struct drm_gem_object *obj)
struct drm_device *dev = obj->dev;
struct page **p;
int npages = obj->size >> PAGE_SHIFT;
+ struct scatterlist *s;
+ int i;
if (use_pages(obj))
p = drm_gem_get_pages(obj);
@@ -107,9 +109,19 @@ static struct page **get_pages(struct drm_gem_object *obj)
/* For non-cached buffers, ensure the new pages are clean
* because display controller, GPU, etc. are not coherent:
*/
- if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
- dma_map_sg(dev->dev, msm_obj->sgt->sgl,
- msm_obj->sgt->nents, DMA_BIDIRECTIONAL);
+ if (msm_obj->flags & (MSM_BO_WC | MSM_BO_UNCACHED)) {
+ /*
+ * Fake up the SG table so that dma_sync_sg_*()
+ * can be used to flush the pages associated with it.
+ */
We aren't really faking. The table is real, we are just slightly abusing the
sg_dma_address() which makes this comment a bit misleading. Instead I would
probably say something like:
/* dma_sync_sg_* flushes pages using sg_dma_address() so point it at the
* physical page for the right behavior */
Or something like that.
It's actually quite complicated, but I agree that the comment isn't
very precise. The cases are as follows:
- arm64 iommu_dma_ops use sg_phys()
https://elixir.bootlin.com/linux/v4.20-rc3/source/arch/arm64/mm/dma-mapping.c#L599
- swiotlb_dma_ops used on arm64 if no IOMMU is available use
sg->dma_address directly:
https://elixir.bootlin.com/linux/v4.20-rc3/source/kernel/dma/swiotlb.c#L832
- arm_dma_ops use sg_dma_address():
https://elixir.bootlin.com/linux/v4.20-rc3/source/arch/arm/mm/dma-mapping.c#L1130
- arm iommu_ops use sg_page():
https://elixir.bootlin.com/linux/v4.20-rc3/source/arch/arm/mm/dma-mapping.c#L1869
Sounds like a mess...
Thanks for the review.
Technically with the below assignment we address all of the above. How
about an even
simpler version of the suggested comment:
/* dma_sync_sg_* flushes physical pages, so point sg->dma_address to
* the physical one for the right behavior.
*/
+ for_each_sg(msm_obj->sgt->sgl, s,
+ msm_obj->sgt->nents, i)
+ sg_dma_address(s) = sg_phys(s);
+
I'm wondering - wouldn't we want to do this association for cached buffers to so
we could sync them correctly in cpu_prep and cpu_fini? Maybe it wouldn't hurt
to put this association in the main path (obviously the sync should stay inside
the conditional for uncached buffers).
Sure, I will move this out of the conditional check.
I guess it wouldn't hurt indeed. Note that cpu_prep/fini seem to be
missing the sync call currently.
I can't say I understand the usage of cpu_prep and cpu_fini(). But I can add
the necessary support if you can point me in the right direction.
Thanks
Best regards
Vivek
P.S. Jordan, not sure if it's my Gmail or your email client, but your
message had all the recipients in a Reply-to header, except you, so
pressing Reply to all in my case led to a message that didn't have you
in recipients anymore...
Best regards,
Tomasz
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/rockchip: update cursors asynchronously through atomic.
On Fri, 2018-11-23 at 11:27 +0900, Tomasz Figa wrote: > > The point here is not about setting and resetting the plane->fb > pointer. It's about what happens inside > drm_atomic_set_fb_for_plane(). > > It calls drm_framebuffer_get() for the new fb and > drm_framebuffer_put() for the old fb. In result, if the fb changes, > the old fb, which had its reference count incremented in the atomic > commit that set it to the plane before, has its reference count > decremented. Moreover, if the new reference count becomes 0, > drm_framebuffer_put() will immediately free the buffer. > > Freeing a buffer when the hardware is still scanning out of it isn't > a > good idea, is it? No, it's not. But the board I submitted the patch for doesn't have anything like hot swapable ram. The ram access is still going to work, just it might display something it shouldn't. Say for example if that frame buffer got reused by somethig else and filled with new data in the very small window. But yes, I agree the best solution would be to not release the buffer until the next vblank. Perhaps a good solution would be for the DRM api to have the concept of a deferred release? Meaning if the put() call just added the frame buffer to a list that DRM core could walk during the vblank. That might be better then every single driver trying to work up a custom solution. > The vc4 driver seems to be able to program the hardware to switch the > scanout to the new buffer immediately: > > https://elixir.bootlin.com/linux/v4.20-rc3/source/drivers/gpu/drm/vc4/vc4_plane.c#L794 > > Although I wonder if there isn't still a tiny race there - the > hardware may have just started refilling the FIFO from the old > address. Still, if the FIFO is small, the FIFO refill operation may > be > much shorter than it takes for the kernel code to actually free the > buffer. Eric and Michael, could you confirm? > I don't have those boards anymore, and I don't have access to any technical documentation on the GPU so I can't really add much here. Eric can probably provide the best information. I submitted the patch because I was working on arm64 support for fun and was becomming very annoyed by desktop lockups for long periods of time on the desktop enviroment of my choice due to the driver being flooded with curser animation updates. I sent the patch to Eric who was kind enough to review it and suggest some improvements. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/9] drm/msm: implement a2xx mmu
A2XX has its own very simple MMU.
Added a msm_use_mmu() function because we can't rely on iommu_present to
decide to use MMU or not.
Signed-off-by: Jonathan Marek
---
v2:
-tlb flush from cpu every time the page table is updated
-keep missing MMU error path, in case MMU init fails
-small cleanup in msm_gpu_create_address_space changes
-fixed whitespace issue
drivers/gpu/drm/msm/Makefile | 3 +-
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 50 -
drivers/gpu/drm/msm/adreno/adreno_device.c | 3 +
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 3 +
drivers/gpu/drm/msm/msm_drv.c | 11 +-
drivers/gpu/drm/msm/msm_drv.h | 8 ++
drivers/gpu/drm/msm/msm_gem.c | 4 +-
drivers/gpu/drm/msm/msm_gem_vma.c | 23
drivers/gpu/drm/msm/msm_gpu.c | 31 --
drivers/gpu/drm/msm/msm_gpummu.c | 122 +
drivers/gpu/drm/msm/msm_mmu.h | 3 +
11 files changed, 241 insertions(+), 20 deletions(-)
create mode 100644 drivers/gpu/drm/msm/msm_gpummu.c
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 0170766393ea..004574bc9bd3 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -91,7 +91,8 @@ msm-y := \
msm_perf.o \
msm_rd.o \
msm_ringbuffer.o \
- msm_submitqueue.o
+ msm_submitqueue.o \
+ msm_gpummu.o
msm-$(CONFIG_DEBUG_FS) += adreno/a5xx_debugfs.o \
disp/dpu1/dpu_dbg.o
diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index 936242f69f08..963dd699cddd 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -2,6 +2,8 @@
/* Copyright (c) 2018 The Linux Foundation. All rights reserved. */
#include "a2xx_gpu.h"
+#include "msm_gem.h"
+#include "msm_mmu.h"
extern bool hang_debug;
@@ -58,9 +60,12 @@ static bool a2xx_me_init(struct msm_gpu *gpu)
static int a2xx_hw_init(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+ dma_addr_t pt_base, tran_error;
uint32_t *ptr, len;
int i, ret;
+ msm_gpummu_params(gpu->aspace->mmu, _base, _error);
+
DBG("%s", gpu->name);
gpu_write(gpu, REG_A2XX_RBBM_PM_OVERRIDE1, 0xfffe);
@@ -77,9 +82,34 @@ static int a2xx_hw_init(struct msm_gpu *gpu)
/* note: kgsl uses 0x for a20x */
gpu_write(gpu, REG_A2XX_RBBM_CNTL, 0x4442);
- gpu_write(gpu, REG_A2XX_MH_MMU_CONFIG, 0);
- gpu_write(gpu, REG_A2XX_MH_MMU_MPU_BASE, 0);
+ /* MPU: physical range */
+ gpu_write(gpu, REG_A2XX_MH_MMU_MPU_BASE, 0x);
gpu_write(gpu, REG_A2XX_MH_MMU_MPU_END, 0xf000);
+
+ gpu_write(gpu, REG_A2XX_MH_MMU_CONFIG, A2XX_MH_MMU_CONFIG_MMU_ENABLE |
+ A2XX_MH_MMU_CONFIG_RB_W_CLNT_BEHAVIOR(BEH_TRAN_RNG) |
+ A2XX_MH_MMU_CONFIG_CP_W_CLNT_BEHAVIOR(BEH_TRAN_RNG) |
+ A2XX_MH_MMU_CONFIG_CP_R0_CLNT_BEHAVIOR(BEH_TRAN_RNG) |
+ A2XX_MH_MMU_CONFIG_CP_R1_CLNT_BEHAVIOR(BEH_TRAN_RNG) |
+ A2XX_MH_MMU_CONFIG_CP_R2_CLNT_BEHAVIOR(BEH_TRAN_RNG) |
+ A2XX_MH_MMU_CONFIG_CP_R3_CLNT_BEHAVIOR(BEH_TRAN_RNG) |
+ A2XX_MH_MMU_CONFIG_CP_R4_CLNT_BEHAVIOR(BEH_TRAN_RNG) |
+ A2XX_MH_MMU_CONFIG_VGT_R0_CLNT_BEHAVIOR(BEH_TRAN_RNG) |
+ A2XX_MH_MMU_CONFIG_VGT_R1_CLNT_BEHAVIOR(BEH_TRAN_RNG) |
+ A2XX_MH_MMU_CONFIG_TC_R_CLNT_BEHAVIOR(BEH_TRAN_RNG) |
+ A2XX_MH_MMU_CONFIG_PA_W_CLNT_BEHAVIOR(BEH_TRAN_RNG));
+
+ /* same as parameters in adreno_gpu */
+ gpu_write(gpu, REG_A2XX_MH_MMU_VA_RANGE, SZ_16M |
+ A2XX_MH_MMU_VA_RANGE_NUM_64KB_REGIONS(0xfff));
+
+ gpu_write(gpu, REG_A2XX_MH_MMU_PT_BASE, pt_base);
+ gpu_write(gpu, REG_A2XX_MH_MMU_TRAN_ERROR, tran_error);
+
+ gpu_write(gpu, REG_A2XX_MH_MMU_INVALIDATE,
+ A2XX_MH_MMU_INVALIDATE_INVALIDATE_ALL |
+ A2XX_MH_MMU_INVALIDATE_INVALIDATE_TC);
+
gpu_write(gpu, REG_A2XX_MH_ARBITER_CONFIG,
A2XX_MH_ARBITER_CONFIG_SAME_PAGE_LIMIT(16) |
A2XX_MH_ARBITER_CONFIG_L1_ARB_ENABLE |
@@ -106,9 +136,21 @@ static int a2xx_hw_init(struct msm_gpu *gpu)
/* note: gsl doesn't set this */
gpu_write(gpu, REG_A2XX_RBBM_DEBUG, 0x0008);
- gpu_write(gpu, REG_A2XX_RBBM_INT_CNTL, 0);
- gpu_write(gpu, REG_AXXX_CP_INT_CNTL, 0x8000); /* RB INT */
+ gpu_write(gpu, REG_A2XX_RBBM_INT_CNTL,
+ A2XX_RBBM_INT_CNTL_RDERR_INT_MASK);
+ gpu_write(gpu, REG_AXXX_CP_INT_CNTL,
+ AXXX_CP_INT_CNTL_T0_PACKET_IN_IB_MASK |
+ AXXX_CP_INT_CNTL_OPCODE_ERROR_MASK |
+ AXXX_CP_INT_CNTL_PROTECTED_MODE_ERROR_MASK |
+ AXXX_CP_INT_CNTL_RESERVED_BIT_ERROR_MASK |
+ AXXX_CP_INT_CNTL_IB_ERROR_MASK |
+
[PATCH] drm/meson: add support for 1080p25 mode
This essential mode for PAL users is missing, so add it.
Signed-off-by: Christian Hewitt
---
drivers/gpu/drm/meson/meson_venc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/meson/meson_venc.c
b/drivers/gpu/drm/meson/meson_venc.c
index acbbad3..ab16046 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++ b/drivers/gpu/drm/meson/meson_venc.c
@@ -714,6 +714,7 @@ struct meson_hdmi_venc_vic_mode {
{ 5, _hdmi_encp_mode_1080i60 },
{ 20, _hdmi_encp_mode_1080i50 },
{ 32, _hdmi_encp_mode_1080p24 },
+ { 33, _hdmi_encp_mode_1080p50 },
{ 34, _hdmi_encp_mode_1080p30 },
{ 31, _hdmi_encp_mode_1080p50 },
{ 16, _hdmi_encp_mode_1080p60 },
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/rockchip: update cursors asynchronously through atomic.
Hi Tomasz,
On 11/20/18 4:48 AM, Tomasz Figa wrote:
> Hi Helen,
>
> On Tue, Nov 20, 2018 at 4:08 AM Helen Koike wrote:
>>
>> From: Enric Balletbo i Serra
>>
>> Add support to async updates of cursors by using the new atomic
>> interface for that.
>>
>> Signed-off-by: Enric Balletbo i Serra
>> [updated for upstream]
>> Signed-off-by: Helen Koike
>>
>> ---
>> Hello,
>>
>> This is the third version of the async-plane update suport to the
>> Rockchip driver.
>>
>
> Thanks for a quick respin. Please see my comments inline. (I'll try to
> be better at responding from now on...)
>
>> I tested running igt kms_cursor_legacy and kms_atomic tests using a 96Boards
>> Ficus.
>>
>> Note that before the patch, the following igt tests failed:
>>
>> basic-flip-before-cursor-atomic
>> basic-flip-before-cursor-legacy
>> cursor-vs-flip-atomic
>> cursor-vs-flip-legacy
>> cursor-vs-flip-toggle
>> flip-vs-cursor-atomic
>> flip-vs-cursor-busy-crc-atomic
>> flip-vs-cursor-busy-crc-legacy
>> flip-vs-cursor-crc-atomic
>> flip-vs-cursor-crc-legacy
>> flip-vs-cursor-legacy
>>
>> Full log: https://people.collabora.com/~koike/results-4.20/html/
>>
>> Now with the patch applied the following were fixed:
>> basic-flip-before-cursor-atomic
>> basic-flip-before-cursor-legacy
>> flip-vs-cursor-atomic
>> flip-vs-cursor-legacy
>>
>> Full log: https://people.collabora.com/~koike/results-4.20-async/html/
>
> Could you also test modetest, with the -C switch to test the legacy
> cursor API? I remember it triggering crashes due to synchronization
> issues easily.
Sure. I tested with
$ modetest -M rockchip -s 37:1920x1080 -C
I also vary the mode but I couldn't trigger any crashes.
>
>>
>> Tomasz, as you mentined in v2 about waiting the hardware before updating
>> the framebuffer, now I call the loop you pointed out in the async path,
>> was that what you had in mind? Or do you think I would make sense to
>> call the vop_crtc_atomic_flush() instead of just exposing that loop?
>>
>> Thanks
>> Helen
>>
>> Changes in v3:
>> - Rebased on top of drm-misc
>> - Fix missing include in rockchip_drm_vop.c
>> - New function vop_crtc_atomic_commit_flush
>>
>> Changes in v2:
>> - v2: https://patchwork.freedesktop.org/patch/254180/
>> - Change the framebuffer as well to cover jumpy cursor when hovering
>> text boxes or hyperlink. (Tomasz)
>> - Use the PSR inhibit mechanism when accessing VOP hardware instead of
>> PSR flushing (Tomasz)
>>
>> Changes in v1:
>> - Rebased on top of drm-misc
>> - In async_check call drm_atomic_helper_check_plane_state to check that
>> the desired plane is valid and update various bits of derived state
>> (clipped coordinates etc.)
>> - In async_check allow to configure new scaling in the fast path.
>> - In async_update force to flush all registered PSR encoders.
>> - In async_update call atomic_update directly.
>> - In async_update call vop_cfg_done needed to set the vop registers and take
>> effect.
>>
>> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 36 ---
>> drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 37 +++
>> drivers/gpu/drm/rockchip/rockchip_drm_psr.h | 3 +
>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 108 +---
>> 4 files changed, 131 insertions(+), 53 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> index ea18cb2a76c0..08bec50d9c5d 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> @@ -127,42 +127,6 @@ rockchip_user_fb_create(struct drm_device *dev, struct
>> drm_file *file_priv,
>> return ERR_PTR(ret);
>> }
>>
>> -static void
>> -rockchip_drm_psr_inhibit_get_state(struct drm_atomic_state *state)
>> -{
>> - struct drm_crtc *crtc;
>> - struct drm_crtc_state *crtc_state;
>> - struct drm_encoder *encoder;
>> - u32 encoder_mask = 0;
>> - int i;
>> -
>> - for_each_old_crtc_in_state(state, crtc, crtc_state, i) {
>> - encoder_mask |= crtc_state->encoder_mask;
>> - encoder_mask |= crtc->state->encoder_mask;
>> - }
>> -
>> - drm_for_each_encoder_mask(encoder, state->dev, encoder_mask)
>> - rockchip_drm_psr_inhibit_get(encoder);
>> -}
>> -
>> -static void
>> -rockchip_drm_psr_inhibit_put_state(struct drm_atomic_state *state)
>> -{
>> - struct drm_crtc *crtc;
>> - struct drm_crtc_state *crtc_state;
>> - struct drm_encoder *encoder;
>> - u32 encoder_mask = 0;
>> - int i;
>> -
>> - for_each_old_crtc_in_state(state, crtc, crtc_state, i) {
>> - encoder_mask |= crtc_state->encoder_mask;
>> - encoder_mask |= crtc->state->encoder_mask;
>> - }
>> -
>> - drm_for_each_encoder_mask(encoder, state->dev, encoder_mask)
>> -
RE: [PATCH v2 3/5] drm: rcar-du: Add r8a77470 support
Hello Laurent,
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 17 October 2018 07:52
> Subject: Re: [PATCH v2 3/5] drm: rcar-du: Add r8a77470 support
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Tuesday, 16 October 2018 19:58:59 EEST Fabrizio Castro wrote:
> > Add RZ/G1C (a.k.a. r8a77470) support to the R-Car DU driver.
> >
> > Signed-off-by: Fabrizio Castro
> > Reviewed-by: Laurent Pinchart
> >
> > ---
> > v1->v2:
> > * Added flags RCAR_DU_FEATURE_INTERLACED and RCAR_DU_FEATURE_TVM_SYNC
> > * Reworked comment
>
> This looks all good, applied to my tree.
It looks like I can't find the patch, which tree is it?
Thanks,
Fab
>
> > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 28
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 084f58d..d8a02c4 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > @@ -77,6 +77,33 @@ static const struct rcar_du_device_info
> > rzg1_du_r8a7745_info = { },
> > };
> >
> > +static const struct rcar_du_device_info rzg1_du_r8a77470_info = {
> > +.gen = 2,
> > +.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
> > + | RCAR_DU_FEATURE_EXT_CTRL_REGS
> > + | RCAR_DU_FEATURE_INTERLACED
> > + | RCAR_DU_FEATURE_TVM_SYNC,
> > +.channels_mask = BIT(1) | BIT(0),
> > +.routes = {
> > +/*
> > + * R8A77470 has two RGB outputs, one LVDS output, and
> > + * one (currently unsupported) analog video output
> > + */
> > +[RCAR_DU_OUTPUT_DPAD0] = {
> > +.possible_crtcs = BIT(0),
> > +.port = 0,
> > +},
> > +[RCAR_DU_OUTPUT_DPAD1] = {
> > +.possible_crtcs = BIT(1),
> > +.port = 1,
> > +},
> > +[RCAR_DU_OUTPUT_LVDS0] = {
> > +.possible_crtcs = BIT(0) | BIT(1),
> > +.port = 2,
> > +},
> > +},
> > +};
> > +
> > static const struct rcar_du_device_info rcar_du_r8a7779_info = {
> > .gen = 2,
> > .features = RCAR_DU_FEATURE_INTERLACED
> > @@ -342,6 +369,7 @@ static const struct rcar_du_device_info
> > rcar_du_r8a7799x_info = { static const struct of_device_id
> > rcar_du_of_table[] = {
> > { .compatible = "renesas,du-r8a7743", .data = _du_r8a7743_info },
> > { .compatible = "renesas,du-r8a7745", .data = _du_r8a7745_info },
> > +{ .compatible = "renesas,du-r8a77470", .data = _du_r8a77470_info },
> > { .compatible = "renesas,du-r8a7779", .data = _du_r8a7779_info },
> > { .compatible = "renesas,du-r8a7790", .data = _du_r8a7790_info },
> > { .compatible = "renesas,du-r8a7791", .data = _du_r8a7791_info },
>
>
> --
> Regards,
>
> Laurent Pinchart
>
>
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] Use vm_insert_range
On Thu, Nov 22, 2018 at 1:08 AM Boris Ostrovsky wrote: > > On 11/21/18 1:24 AM, Souptick Joarder wrote: > > On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder > > wrote: > >> Previouly drivers have their own way of mapping range of > >> kernel pages/memory into user vma and this was done by > >> invoking vm_insert_page() within a loop. > >> > >> As this pattern is common across different drivers, it can > >> be generalized by creating a new function and use it across > >> the drivers. > >> > >> vm_insert_range is the new API which will be used to map a > >> range of kernel memory/pages to user vma. > >> > >> All the applicable places are converted to use new vm_insert_range > >> in this patch series. > >> > >> Souptick Joarder (9): > >> mm: Introduce new vm_insert_range API > >> arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range > >> drivers/firewire/core-iso.c: Convert to use vm_insert_range > >> drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range > >> drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range > >> iommu/dma-iommu.c: Convert to use vm_insert_range > >> videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range > >> xen/gntdev.c: Convert to use vm_insert_range > >> xen/privcmd-buf.c: Convert to use vm_insert_range > > Any further comment on driver changes ? > > Xen drivers (the last two patches) look fine to me. Thanks, can I considered this as Reviewed-by ? > > -boris > > > >> arch/arm/mm/dma-mapping.c | 21 ++--- > >> drivers/firewire/core-iso.c | 15 ++-- > >> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 20 ++-- > >> drivers/gpu/drm/xen/xen_drm_front_gem.c | 20 +--- > >> drivers/iommu/dma-iommu.c | 12 ++ > >> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 23 ++- > >> drivers/xen/gntdev.c | 11 - > >> drivers/xen/privcmd-buf.c | 8 ++- > >> include/linux/mm_types.h | 3 +++ > >> mm/memory.c | 28 > >> +++ > >> mm/nommu.c| 7 ++ > >> 11 files changed, 70 insertions(+), 98 deletions(-) > >> > >> -- > >> 1.9.1 > >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 9/9] drm/msm: set priv->kms to NULL before uninit
otherwise, priv->kms is non-NULL and msm_drm_uninit will cause a panic.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 5d7304b5f399..fd5769e4c42a 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -527,6 +527,7 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
if (IS_ERR(kms)) {
dev_err(dev, "failed to load kms\n");
ret = PTR_ERR(kms);
+ priv->kms = NULL;
goto err_msm_uninit;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] mm: Introduce new vm_insert_range API
On Mon, Nov 19, 2018 at 11:15:15PM +0530, Souptick Joarder wrote: > On Mon, Nov 19, 2018 at 9:56 PM Mike Rapoport wrote: > > > > On Mon, Nov 19, 2018 at 08:43:09PM +0530, Souptick Joarder wrote: > > > Hi Mike, > > > > > > On Sat, Nov 17, 2018 at 8:07 PM Matthew Wilcox > > > wrote: > > > > > > > > On Sat, Nov 17, 2018 at 12:26:38PM +0530, Souptick Joarder wrote: > > > > > On Fri, Nov 16, 2018 at 11:59 PM Mike Rapoport > > > > > wrote: > > > > > > > + * vm_insert_range - insert range of kernel pages into user vma > > > > > > > + * @vma: user vma to map to > > > > > > > + * @addr: target user address of this page > > > > > > > + * @pages: pointer to array of source kernel pages > > > > > > > + * @page_count: no. of pages need to insert into user vma > > > > > > > + * > > > > > > > + * This allows drivers to insert range of kernel pages they've > > > > > > > allocated > > > > > > > + * into a user vma. This is a generic function which drivers can > > > > > > > use > > > > > > > + * rather than using their own way of mapping range of kernel > > > > > > > pages into > > > > > > > + * user vma. > > > > > > > > > > > > Please add the return value and context descriptions. > > > > > > > > > > > > > > > > Sure I will wait for some time to get additional review comments and > > > > > add all of those requested changes in v2. > > > > > > > > You could send your proposed wording now which might remove the need > > > > for a v3 if we end up arguing about the wording. > > > > > > Does this description looks good ? > > > > > > /** > > > * vm_insert_range - insert range of kernel pages into user vma > > > * @vma: user vma to map to > > > * @addr: target user address of this page > > > * @pages: pointer to array of source kernel pages > > > * @page_count: number of pages need to insert into user vma > > > * > > > * This allows drivers to insert range of kernel pages they've allocated > > > * into a user vma. This is a generic function which drivers can use > > > * rather than using their own way of mapping range of kernel pages into > > > * user vma. > > > * > > > * Context - Process context. Called by mmap handlers. > > > > Context: > > > > > * Return - int error value > > > > Return: > > > > > * 0- OK > > > * -EINVAL - Invalid argument > > > * -ENOMEM - No memory > > > * -EFAULT - Bad address > > > * -EBUSY - Device or resource busy > > > > I don't think that elaborate description of error values is needed, just "0 > > on success and error code otherwise" would be sufficient. > > /** > * vm_insert_range - insert range of kernel pages into user vma > * @vma: user vma to map to > * @addr: target user address of this page > * @pages: pointer to array of source kernel pages > * @page_count: number of pages need to insert into user vma > * > * This allows drivers to insert range of kernel pages they've allocated > * into a user vma. This is a generic function which drivers can use > * rather than using their own way of mapping range of kernel pages into > * user vma. > * > * Context: Process context. Called by mmap handlers. > * Return: 0 on success and error code otherwise > */ Looks good to me. -- Sincerely yours, Mike. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 4/6] drm/omap: fix incorrect union usage
The DSI encoder sets dssdev->ops->dsi.set_config, which is stored at the
same offset as dssdev->ops->hdmi.set_hdmi_mode. The code in omap_encoder
only checks if dssdev->ops->hdmi.set_hdmi_mode is NULL. Due to the way
union works, it won't be NULL if dsi.set_config is set. This means
dsi_set_config will be called with config=hdmi_mode=false=NULL parameter
resulting in a NULL dereference. Also the dereference happens while
console is locked, so kernel hangs without any debug output without
"fb.lockless_register_fb=1" parameter.
This restructures the code, so that the HDMI mode is only configured
for HDMI output types. The new function also has a safe-guard directly
before accessing the union, that can be optimized away by the compiler
when the function is inlined and HDMI type has already been checked.
Fixes: 83910ad3f51fb ("drm/omap: Move most omap_dss_driver operations to
omap_dss_device_ops")
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_encoder.c | 62 +++---
1 file changed, 37 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c
b/drivers/gpu/drm/omapdrm/omap_encoder.c
index 32bbe3a80e7d..f356821cd078 100644
--- a/drivers/gpu/drm/omapdrm/omap_encoder.c
+++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
@@ -52,17 +52,48 @@ static const struct drm_encoder_funcs omap_encoder_funcs = {
.destroy = omap_encoder_destroy,
};
+static void omap_encoder_hdmi_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct drm_device *dev = encoder->dev;
+ struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
+ struct omap_dss_device *dssdev = omap_encoder->output;
+ struct drm_connector *connector;
+ bool hdmi_mode;
+
+ hdmi_mode = false;
+ list_for_each_entry(connector, >mode_config.connector_list, head) {
+ if (connector->encoder == encoder) {
+ hdmi_mode = omap_connector_get_hdmi_mode(connector);
+ break;
+ }
+ }
+
+ /* safe-guard for accessing dssdev->ops->hdmi union */
+ if (dssdev->output_type != OMAP_DISPLAY_TYPE_HDMI)
+ return;
+
+ if (dssdev->ops->hdmi.set_hdmi_mode)
+ dssdev->ops->hdmi.set_hdmi_mode(dssdev, hdmi_mode);
+
+ if (hdmi_mode && dssdev->ops->hdmi.set_infoframe) {
+ struct hdmi_avi_infoframe avi;
+ int r;
+
+ r = drm_hdmi_avi_infoframe_from_display_mode(,
adjusted_mode,
+false);
+ if (r == 0)
+ dssdev->ops->hdmi.set_infoframe(dssdev, );
+ }
+}
+
static void omap_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
- struct drm_device *dev = encoder->dev;
struct omap_encoder *omap_encoder = to_omap_encoder(encoder);
- struct drm_connector *connector;
struct omap_dss_device *dssdev;
struct videomode vm = { 0 };
- bool hdmi_mode;
- int r;
drm_display_mode_to_videomode(adjusted_mode, );
@@ -112,27 +143,8 @@ static void omap_encoder_mode_set(struct drm_encoder
*encoder,
}
/* Set the HDMI mode and HDMI infoframe if applicable. */
- hdmi_mode = false;
- list_for_each_entry(connector, >mode_config.connector_list, head) {
- if (connector->encoder == encoder) {
- hdmi_mode = omap_connector_get_hdmi_mode(connector);
- break;
- }
- }
-
- dssdev = omap_encoder->output;
-
- if (dssdev->ops->hdmi.set_hdmi_mode)
- dssdev->ops->hdmi.set_hdmi_mode(dssdev, hdmi_mode);
-
- if (hdmi_mode && dssdev->ops->hdmi.set_infoframe) {
- struct hdmi_avi_infoframe avi;
-
- r = drm_hdmi_avi_infoframe_from_display_mode(,
adjusted_mode,
-false);
- if (r == 0)
- dssdev->ops->hdmi.set_infoframe(dssdev, );
- }
+ if (omap_encoder->output->output_type == OMAP_DISPLAY_TYPE_HDMI)
+ omap_encoder_hdmi_mode_set(encoder, adjusted_mode);
}
static void omap_encoder_disable(struct drm_encoder *encoder)
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING in vkms_plane_duplicate_state
Hello, syzbot found the following crash on: HEAD commit:92b419289cee Merge tag 'riscv-for-linus-4.20-rc4' of git:/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=17ed377b40 kernel config: https://syzkaller.appspot.com/x/.config?x=73e2bc0cb6463446 dashboard link: https://syzkaller.appspot.com/bug?extid=eb6e5365f23c02517dda compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1507d53340 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=113be77b40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+eb6e5365f23c02517...@syzkaller.appspotmail.com RDX: 2080 RSI: ffb7 RDI: 0003 RBP: 7ffecec49940 R08: 0001 R09: R10: R11: 0246 R12: R13: 0004 R14: R15: WARNING: CPU: 0 PID: 8437 at drivers/gpu/drm/vkms/vkms_plane.c:26 vkms_plane_duplicate_state+0x9f/0x120 drivers/gpu/drm/vkms/vkms_plane.c:26 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 8437 Comm: syz-executor513 Not tainted 4.20.0-rc3+ #344 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 panic+0x2ad/0x55c kernel/panic.c:188 __warn.cold.8+0x20/0x45 kernel/panic.c:540 report_bug+0x254/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271 do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:969 RIP: 0010:vkms_plane_duplicate_state+0x9f/0x120 drivers/gpu/drm/vkms/vkms_plane.c:26 Code: 00 0f 85 86 00 00 00 48 8b 3d fd aa db 04 ba f8 00 00 00 be c0 80 60 00 e8 de fc 76 fd 48 85 c0 49 89 c5 75 13 e8 11 fb 33 fd <0f> 0b 48 c7 c7 80 20 7b 88 e8 17 47 1a fd e8 fe fa 33 fd 48 8d bb RSP: 0018:8881afd2f6f8 EFLAGS: 00010293 RAX: 8881b7360040 RBX: 8881d781b900 RCX: 0004 RDX: RSI: 844b8fdf RDI: 0286 RBP: 8881afd2f710 R08: 8881b7360040 R09: ed103b5c5b67 R10: ed103b5c5b67 R11: 8881dae2db3b R12: 8881d1eb3680 R13: R14: R15: 8881afd2f860 drm_atomic_get_plane_state+0x225/0x560 drivers/gpu/drm/drm_atomic.c:465 drm_atomic_helper_disable_plane+0x7b/0x200 drivers/gpu/drm/drm_atomic_helper.c:2776 __setplane_atomic+0x2a3/0x330 drivers/gpu/drm/drm_plane.c:715 setplane_internal+0x127/0x370 drivers/gpu/drm/drm_plane.c:754 drm_mode_setplane+0x567/0x830 drivers/gpu/drm/drm_plane.c:814 drm_ioctl_kernel+0x278/0x330 drivers/gpu/drm/drm_ioctl.c:757 drm_ioctl+0x57e/0xb00 drivers/gpu/drm/drm_ioctl.c:853 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x444dc9 Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b ce fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffecec49928 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: RCX: 00444dc9 RDX: 2080 RSI: ffb7 RDI: 0003 RBP: 7ffecec49940 R08: 0001 R09: R10: R11: 0246 R12: R13: 0004 R14: R15: Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm: Add panel support for PDA 91-00156-A0
Hello, This patch series adds support for PDA (Precision Design Associates, Inc.) vendor, and for the PDA 91-00156-A0 simple panel, together with the bindings. The series is on top of http://anongit.freedesktop.org/git/drm/drm.git drm-next branch. Cristian Birsan (1): dt-bindings: drm/panel: simple: add support for PDA 91-00156-A0 Eugen Hristev (2): dt-bindings: add vendor prefix for PDA Precision Design Associates, Inc. drm/panel: simple: add support for PDA 91-00156-A0 panel .../bindings/display/panel/pda,91-00156-a0.txt | 7 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/gpu/drm/panel/panel-simple.c | 27 ++ 3 files changed, 35 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/9] drm/msm/mdp4: allocate blank_cursor_no with MSM_BO_SCANOUT flag
For allocation in contiguous memory when the GPU has MMU but not mdp4.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 8f765f284d11..484d2fc2f415 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -534,7 +534,7 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
goto fail;
}
- mdp4_kms->blank_cursor_bo = msm_gem_new(dev, SZ_16K, MSM_BO_WC);
+ mdp4_kms->blank_cursor_bo = msm_gem_new(dev, SZ_16K, MSM_BO_WC |
MSM_BO_SCANOUT);
if (IS_ERR(mdp4_kms->blank_cursor_bo)) {
ret = PTR_ERR(mdp4_kms->blank_cursor_bo);
dev_err(dev->dev, "could not allocate blank-cursor bo: %d\n",
ret);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] dt-bindings: add vendor prefix for PDA Precision Design Associates, Inc.
Precision Design Associates, Inc. (PDA) manufactures standard and custom capacitive touch screens, LCD's embedded controllers and custom embedded software. They specialize in industrial, rugged and outdoor applications. Website: http://www.pdaatl.com/ Signed-off-by: Eugen Hristev --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index a2f4451..4e0a81c 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -295,6 +295,7 @@ ovtiOmniVision Technologies oxsemi Oxford Semiconductor, Ltd. panasonic Panasonic Corporation parade Parade Technologies Inc. +pdaPrecision Design Associates, Inc. pericomPericom Technology Inc. pervasive Pervasive Displays, Inc. phytec PHYTEC Messtechnik GmbH -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 2/6] drm/omap: populate DSI platform bus earlier
After the changes from 4.20 the DSI encoder tries to find the
attached panel before populating the DSI bus. If the panel is
not found -EPROBE_DEFER is returned, so the DSI bus is never
populated and the panel never added.
Fix this by populating the DSI bus before searching for the
video sink in dsi_init_output().
Fixes: 27d624527d992 ("drm/omap: dss: Acquire next dssdev at probe time")
Acked-by: Pavel Machek
Tested-by: Tony Lindgren
Tested-by: Pavel Machek
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/dsi.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 0a485c5b982e..00a9c2ab9e6c 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -5418,9 +5418,15 @@ static int dsi_probe(struct platform_device *pdev)
dsi->num_lanes_supported = 3;
}
+ r = of_platform_populate(dev->of_node, NULL, NULL, dev);
+ if (r) {
+ DSSERR("Failed to populate DSI child devices: %d\n", r);
+ goto err_pm_disable;
+ }
+
r = dsi_init_output(dsi);
if (r)
- goto err_pm_disable;
+ goto err_of_depopulate;
r = dsi_probe_of(dsi);
if (r) {
@@ -5428,22 +5434,16 @@ static int dsi_probe(struct platform_device *pdev)
goto err_uninit_output;
}
- r = of_platform_populate(dev->of_node, NULL, NULL, dev);
- if (r) {
- DSSERR("Failed to populate DSI child devices: %d\n", r);
- goto err_uninit_output;
- }
-
r = component_add(>dev, _component_ops);
if (r)
- goto err_of_depopulate;
+ goto err_uninit_output;
return 0;
-err_of_depopulate:
- of_platform_depopulate(dev);
err_uninit_output:
dsi_uninit_output(dsi);
+err_of_depopulate:
+ of_platform_depopulate(dev);
err_pm_disable:
pm_runtime_disable(dev);
return r;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 8/9] phy: Add Cadence D-PHY support
Hi Maxime,
On 21/11/18 3:41 PM, Maxime Ripard wrote:
> Hi Kishon,
>
> On Tue, Nov 20, 2018 at 11:02:34AM +0530, Kishon Vijay Abraham I wrote:
+static int cdns_dphy_config_from_opts(struct phy *phy,
+struct phy_configure_opts_mipi_dphy *opts,
+struct cdns_dphy_cfg *cfg)
+{
+ struct cdns_dphy *dphy = phy_get_drvdata(phy);
+ unsigned int dsi_hfp_ext = 0;
+ int ret;
+
+ ret = phy_mipi_dphy_config_validate(opts);
+ if (ret)
+ return ret;
+
+ ret = cdns_dsi_get_dphy_pll_cfg(dphy, cfg,
+ opts, _hfp_ext);
+ if (ret)
+ return ret;
+
+ opts->wakeup = cdns_dphy_get_wakeup_time_ns(dphy);
>>
>> Is the wakeup populated here used by the consumer driver?
>
> It's supposed to, if it can yes.
But I guess right now it's not using. I'm thinking the usefulness of validate
callback (only from this series point of view). Why should a consumer driver
invoke validate if it doesn't intend to configure the PHY?
The 3 steps required are
* The consumer driver gets the default config
* The consumer driver changes some of the configuration and
* The consumer driver invokes phy configure callback.
phy_configure anyways can validate the config before actually configuring the
phy.
Thanks
Kishon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 1/6] drm/omap: use DRM_DEBUG_DRIVER instead of CORE
This macro is only used by omapdrm, which should print debug messages using the DRIVER category instead of the default CORE category. Acked-by: Pavel Machek Tested-by: Tony Lindgren Tested-by: Pavel Machek Signed-off-by: Sebastian Reichel --- drivers/gpu/drm/omapdrm/omap_drv.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h b/drivers/gpu/drm/omapdrm/omap_drv.h index bd7f2c227a25..3b4af517c92b 100644 --- a/drivers/gpu/drm/omapdrm/omap_drv.h +++ b/drivers/gpu/drm/omapdrm/omap_drv.h @@ -38,8 +38,8 @@ #include "omap_irq.h" #include "omap_plane.h" -#define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__) -#define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose debug */ +#define DBG(fmt, ...) DRM_DEBUG_DRIVER(fmt"\n", ##__VA_ARGS__) +#define VERB(fmt, ...) if (0) DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__) /* verbose debug */ #define MODULE_NAME "omapdrm" -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] Use vm_insert_range
On 11/21/18 2:56 PM, Souptick Joarder wrote: > On Thu, Nov 22, 2018 at 1:08 AM Boris Ostrovsky > wrote: >> On 11/21/18 1:24 AM, Souptick Joarder wrote: >>> On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder >>> wrote: Previouly drivers have their own way of mapping range of kernel pages/memory into user vma and this was done by invoking vm_insert_page() within a loop. As this pattern is common across different drivers, it can be generalized by creating a new function and use it across the drivers. vm_insert_range is the new API which will be used to map a range of kernel memory/pages to user vma. All the applicable places are converted to use new vm_insert_range in this patch series. Souptick Joarder (9): mm: Introduce new vm_insert_range API arch/arm/mm/dma-mapping.c: Convert to use vm_insert_range drivers/firewire/core-iso.c: Convert to use vm_insert_range drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range drm/xen/xen_drm_front_gem.c: Convert to use vm_insert_range iommu/dma-iommu.c: Convert to use vm_insert_range videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range xen/gntdev.c: Convert to use vm_insert_range xen/privcmd-buf.c: Convert to use vm_insert_range >>> Any further comment on driver changes ? >> Xen drivers (the last two patches) look fine to me. > Thanks, can I considered this as Reviewed-by ? Reviewed-by: Boris Ostrovsky ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/amdkfd: Remove duplicate header
Remove gca/gfx_8_0_enum.h which is included more than once Signed-off-by: Brajeswar Ghosh --- drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c index fd60a116be37..c3a5dcfe877a 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_vi.c @@ -24,7 +24,6 @@ #include "kfd_device_queue_manager.h" #include "gca/gfx_8_0_enum.h" #include "gca/gfx_8_0_sh_mask.h" -#include "gca/gfx_8_0_enum.h" #include "oss/oss_3_0_sh_mask.h" static bool set_cache_memory_policy_vi(struct device_queue_manager *dqm, -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] dt-bindings: drm/panel: simple: add support for PDA 91-00156-A0
From: Cristian Birsan PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel. This panel with backlight is found in PDA 5" LCD screen (TM5000 series or AC320005-5). Adding Device Tree bindings for this panel. Signed-off-by: Cristian Birsan --- .../devicetree/bindings/display/panel/pda,91-00156-a0.txt | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt diff --git a/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt new file mode 100644 index 000..52f0da9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt @@ -0,0 +1,7 @@ +PDA 91-00156-A0 5.0" WVGA TFT LCD panel + +Required properties: +- compatible: should be "pda,91-00156-a0" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/ast: fixed reading monitor EDID not stable issue
From: "Y.C. Chen"
v1: over-sample data to increase the stability with some specific monitors
v2: refine to avoid infinite loop
v3: remove un-necessary "volatile" declaration
Signed-off-by: Y.C. Chen
---
drivers/gpu/drm/ast/ast_mode.c | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 5e77d45..843e2f9 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -972,9 +972,20 @@ static int get_clock(void *i2c_priv)
{
struct ast_i2c_chan *i2c = i2c_priv;
struct ast_private *ast = i2c->dev->dev_private;
- uint32_t val;
+ uint32_t val, val2, count, pass;
+
+ count = 0;
+ pass = 0;
+ val = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7, 0x10) >> 4)
& 0x01;
+ do {
+ val2 = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7,
0x10) >> 4) & 0x01;
+ if (val == val2) pass++;
+ else {
+ pass = 0;
+ val = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT,
0xb7, 0x10) >> 4) & 0x01;
+ }
+ } while ((pass < 5) && (count++ < 0x1));
- val = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7, 0x10) >> 4;
return val & 1 ? 1 : 0;
}
@@ -982,9 +993,20 @@ static int get_data(void *i2c_priv)
{
struct ast_i2c_chan *i2c = i2c_priv;
struct ast_private *ast = i2c->dev->dev_private;
- uint32_t val;
+ uint32_t val, val2, count, pass;
+
+ count = 0;
+ pass = 0;
+ val = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7, 0x20) >> 5)
& 0x01;
+ do {
+ val2 = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7,
0x20) >> 5) & 0x01;
+ if (val == val2) pass++;
+ else {
+ pass = 0;
+ val = (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT,
0xb7, 0x20) >> 5) & 0x01;
+ }
+ } while ((pass < 5) && (count++ < 0x1));
- val = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7, 0x20) >> 5;
return val & 1 ? 1 : 0;
}
@@ -997,7 +1019,7 @@ static void set_clock(void *i2c_priv, int clock)
for (i = 0; i < 0x1; i++) {
ujcrb7 = ((clock & 0x01) ? 0 : 1);
- ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7, 0xfe,
ujcrb7);
+ ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7, 0xf4,
ujcrb7);
jtemp = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7,
0x01);
if (ujcrb7 == jtemp)
break;
@@ -1013,7 +1035,7 @@ static void set_data(void *i2c_priv, int data)
for (i = 0; i < 0x1; i++) {
ujcrb7 = ((data & 0x01) ? 0 : 1) << 2;
- ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7, 0xfb,
ujcrb7);
+ ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7, 0xf1,
ujcrb7);
jtemp = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb7,
0x04);
if (ujcrb7 == jtemp)
break;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 0/6] omapdrm: DSI command mode panel support
Hi, Here is another round of the DSI command mode panel patchset integrating the feedback from PATCHv4. The patches are based on 4.20-rc1 + fixes from Laurent and Tony. I dropped the patches for OMAP3 support (it needs a workaround for a hardware bug) and for automatic display rotation. They should get their own series, once this patchset has landed. Tested on Droid 4: * Framebuffer Console, updated at 1Hz due to blinking cursor * Display blanking * Xorg 1.19 with modesetting driver * Weston 5.0 with DRM backend * kmstest (static image) * No updates send when nothing needs to be sent Known issues: * OMAP3 is untested and most likely broken due to missing workaround(s) for hardware bugs. * Weston 5.0 with fbdev backend does not work, since it uses neither page flip nor dirty ioctl. You need to use the drm backend. Changes since PATCHv4: * Apply Acked-/Tested-by received from Tony and Pavel * Fix spelling/wording in commit messagess * Use proper multi-line comments * Restructure patch 4: move the whole HDMI block into a static sub-function, that is only called when output type is HDMI. Also drop the incorrect check for DVI. Changes since PATCHv3: * Drop all Tested/Acked-by tags * Drop the rotation patches for now * Rebase to 4.20-rc1 + fixes from Laurent and Tony * Add fixes for DSI regressions introduced in 4.20-rc1 * Store info update manual update mode in omap_crtc_state * Lock modesetting in omap_framebuffer_dirty * Directly loop through CRTCs instead of connectors in dirty function * Properly refresh display during page flips and get Weston working * Add more comments about implementation details Changes since PATCHv2: * Drop omap3 quirk patch (OMAP3 should get its own mini-series) * Rebase to current linux-next * Use existing 'rotation' DT property to set DRM orientation hint * Add Tested-by from Tony Changes since PATCHv1: * Drop patches, that were queued by Tomi * Rebase to current master * Rework the omap3 workaround patch to only affect omap3 * Add orientation DRM property support -- Sebastian Sebastian Reichel (6): drm/omap: use DRM_DEBUG_DRIVER instead of CORE drm/omap: populate DSI platform bus earlier drm/omap: don't check dispc timings for DSI drm/omap: fix incorrect union usage drm/omap: add framedone interrupt support drm/omap: add support for manually updated displays drivers/gpu/drm/omapdrm/dss/dsi.c| 20 +-- drivers/gpu/drm/omapdrm/omap_connector.c | 8 +- drivers/gpu/drm/omapdrm/omap_crtc.c | 167 ++- drivers/gpu/drm/omapdrm/omap_crtc.h | 2 + drivers/gpu/drm/omapdrm/omap_drv.h | 4 +- drivers/gpu/drm/omapdrm/omap_encoder.c | 70 ++ drivers/gpu/drm/omapdrm/omap_fb.c| 41 ++ drivers/gpu/drm/omapdrm/omap_irq.c | 25 drivers/gpu/drm/omapdrm/omap_irq.h | 1 + 9 files changed, 290 insertions(+), 48 deletions(-) -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/panel: simple: add support for PDA 91-00156-A0 panel
PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel.
This panel with backlight is found in PDA 5" LCD screen (TM5000 series or
AC320005-5).
Signed-off-by: Eugen Hristev
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 5fbee83..3fc9d0b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1984,6 +1984,30 @@ static const struct panel_desc ortustech_com43h4m85ulc =
{
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
};
+static const struct drm_display_mode pda_91_00156_a0_mode = {
+ .clock = 33300,
+ .hdisplay = 800,
+ .hsync_start = 800 + 1,
+ .hsync_end = 800 + 1 + 64,
+ .htotal = 800 + 1 + 64 + 64,
+ .vdisplay = 480,
+ .vsync_start = 480 + 1,
+ .vsync_end = 480 + 1 + 23,
+ .vtotal = 480 + 1 + 23 + 22,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc pda_91_00156_a0 = {
+ .modes = _91_00156_a0_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
+
static const struct drm_display_mode qd43003c0_40_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -2659,6 +2683,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "ortustech,com43h4m85ulc",
.data = _com43h4m85ulc,
}, {
+ .compatible = "pda,91-00156-a0",
+ .data = _91_00156_a0,
+ }, {
.compatible = "qiaodian,qd43003c0-40",
.data = _40,
}, {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/9] drm/msm: use contiguous vram for MSM_BO_SCANOUT when possible
Makes it possible to have MMU for GPU but not display.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/msm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index d97f6ecb0531..6657453a3a58 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -914,7 +914,7 @@ static struct drm_gem_object *_msm_gem_new(struct
drm_device *dev,
if (!iommu_present(_bus_type))
use_vram = true;
- else if ((flags & MSM_BO_STOLEN) && priv->vram.size)
+ else if ((flags & (MSM_BO_STOLEN | MSM_BO_SCANOUT)) && priv->vram.size)
use_vram = true;
printk("_msm_gem_new %u bytes use_vram=%u\n", size, use_vram);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ASPEED graphics card: ast_pci_probe causes RCU stalls
Hi, we have on-board ASPEED Graphics card on PCIe. kernel version: 4.16 I select following drive to enable ast graphics support. Symbol: DRM_AST [=y] \u2502 AST server chips \u2502 Location: \u2502 -> Device Drivers \u2502 -> Graphics support \u2502 Defined at drivers/gpu/drm/ast/Kconfig:1 \u2502 Depends on: HAS_IOMEM [=y] && DRM [=y] && PCI [=y] && MMU [=y] \u2502 Selects: DRM_TTM [=y] && DRM_KMS_HELPER [=y] && DRM_TTM [=y] lspci -vvv output. - 0007:02:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 41) (prog-if 00 [VGA controller]) Subsystem: ASPEED Technology, Inc. ASPEED Graphics Family Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Latency: 0 Interrupt: pin A routed to IRQ 255 Region 0: Memory at e7010100 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at e7010080 (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at 6 [size=128] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/2 Maskable- 64bit+ Address: Data: it seems to me that; ast_pci_probe seems to stuck in set_clock [ 38.293239] INFO: rcu_sched self-detected stall on CPU [ 38.300808] 0-: (35 ticks this GP) idle=256/1/4611686018427387906 softirq=183/183 fqs=187 [ 38.313653] (t=421 jiffies g=-232 c=-233 q=322) [ 38.320592] Task dump for CPU 0: [ 38.325566] kworker/0:0 R running task0 3 2 0x0002 [ 38.335989] Workqueue: events work_for_cpu_fn [ 38.342409] Call trace: [ 38.346025] dump_backtrace+0x0/0x170 [ 38.351413] show_stack+0x14/0x20 [ 38.356297] sched_show_task+0x104/0x128 [ 38.362173] dump_cpu_task+0x40/0x50 [ 38.367441] rcu_dump_cpu_stacks+0x94/0xd4 [ 38.373480] rcu_check_callbacks+0x574/0x7b0 [ 38.379785] update_process_times+0x2c/0x58 [ 38.385946] tick_sched_handle.isra.5+0x30/0x50 [ 38.393830] tick_sched_timer+0x40/0x90 [ 38.399480] __hrtimer_run_queues+0x120/0x1b8 [ 38.405895] hrtimer_interrupt+0xd4/0x250 [ 38.411815] arch_timer_handler_phys+0x28/0x40 [ 38.418361] handle_percpu_devid_irq+0x80/0x138 [ 38.425152] generic_handle_irq+0x24/0x38 [ 38.431057] __handle_domain_irq+0x5c/0xb0 [ 38.437104] gic_handle_irq+0x7c/0x184 [ 38.442639] el1_irq+0xb0/0x140 [ 38.447265] ast_get_index_reg_mask+0x4/0x38 [ 38.453553] __i2c_bit_add_bus+0x54/0x3e0 [ 38.459532] i2c_bit_add_bus+0x14/0x20 [ 38.465057] ast_mode_init+0x230/0x358 [ 38.470584] ast_driver_load+0x5a4/0x968 [ 38.476368] drm_dev_register+0x154/0x1d8 [ 38.482283] drm_get_pci_dev+0x94/0x160 [ 38.488047] ast_pci_probe+0x18/0x20 [ 38.493318] local_pci_probe+0x28/0x80 [ 38.498830] work_for_cpu_fn+0x18/0x28 [ 38.504367] process_one_work+0x1d4/0x310 [ 38.510271] worker_thread+0x230/0x470 [ 38.515804] kthread+0x128/0x130 [ 38.520777] ret_from_fork+0x10/0x18 Regards, Oza. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amd/amdgpu: Remove duplicate header
Remove drm/drm_fb_helper.h which is included more than once Signed-off-by: Brajeswar Ghosh --- drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h index b9e9e8b02fb7..1cac12a26a4e 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h @@ -38,7 +38,6 @@ #include #include #include -#include #include #include #include -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/9] drm/msm/mdp4: add lcdc-align-lsb flag to control lane alignment
Controls which of the 8 lanes are used for 6 bit color. Signed-off-by: Jonathan Marek --- .../gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c | 22 --- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c index e19ab2ab63f7..7d8d11c8150a 100644 --- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c +++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_lcdc_encoder.c @@ -377,20 +377,26 @@ static void mdp4_lcdc_encoder_enable(struct drm_encoder *encoder) unsigned long pc = mdp4_lcdc_encoder->pixclock; struct mdp4_kms *mdp4_kms = get_kms(encoder); struct drm_panel *panel; + uint32_t config; int i, ret; if (WARN_ON(mdp4_lcdc_encoder->enabled)) return; /* TODO: hard-coded for 18bpp: */ - mdp4_crtc_set_config(encoder->crtc, - MDP4_DMA_CONFIG_R_BPC(BPC6) | - MDP4_DMA_CONFIG_G_BPC(BPC6) | - MDP4_DMA_CONFIG_B_BPC(BPC6) | - MDP4_DMA_CONFIG_PACK_ALIGN_MSB | - MDP4_DMA_CONFIG_PACK(0x21) | - MDP4_DMA_CONFIG_DEFLKR_EN | - MDP4_DMA_CONFIG_DITHER_EN); + config = + MDP4_DMA_CONFIG_R_BPC(BPC6) | + MDP4_DMA_CONFIG_G_BPC(BPC6) | + MDP4_DMA_CONFIG_B_BPC(BPC6) | + MDP4_DMA_CONFIG_PACK(0x21) | + MDP4_DMA_CONFIG_DEFLKR_EN | + MDP4_DMA_CONFIG_DITHER_EN; + + if (!of_find_property(dev->dev->of_node, "lcdc-align-lsb", NULL)) + config |= MDP4_DMA_CONFIG_PACK_ALIGN_MSB; + + + mdp4_crtc_set_config(encoder->crtc, config); mdp4_crtc_set_intf(encoder->crtc, INTF_LCDC_DTV, 0); bs_set(mdp4_lcdc_encoder, 1); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/pl111: add of_node_put()
of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. bl_idle_init() doesn't do that, so fix it. Signed-off-by: Yangtao Li --- drivers/gpu/drm/pl111/pl111_vexpress.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.c b/drivers/gpu/drm/pl111/pl111_vexpress.c index 5fa0441bb6df..38c938c9adda 100644 --- a/drivers/gpu/drm/pl111/pl111_vexpress.c +++ b/drivers/gpu/drm/pl111/pl111_vexpress.c @@ -55,6 +55,8 @@ int pl111_vexpress_clcd_init(struct device *dev, } } + of_node_put(root); + /* * If there is a coretile HDLCD and it has a driver, * do not mux the CLCD on the motherboard to the DVI. -- 2.17.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 5/6] drm/omap: add framedone interrupt support
This prepares framedone interrupt handling for
manual display update support.
Acked-by: Pavel Machek
Tested-by: Tony Lindgren
Tested-by: Pavel Machek
Signed-off-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/omap_crtc.c | 50 +
drivers/gpu/drm/omapdrm/omap_crtc.h | 1 +
drivers/gpu/drm/omapdrm/omap_irq.c | 25 +++
drivers/gpu/drm/omapdrm/omap_irq.h | 1 +
4 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index caffc547ef97..59ee2399f2e9 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -52,6 +52,9 @@ struct omap_crtc {
bool pending;
wait_queue_head_t pending_wait;
struct drm_pending_vblank_event *event;
+
+ void (*framedone_handler)(void *);
+ void *framedone_handler_data;
};
/*
-
@@ -231,6 +234,18 @@ static int omap_crtc_dss_register_framedone(
struct omap_drm_private *priv, enum omap_channel channel,
void (*handler)(void *), void *data)
{
+ struct drm_crtc *crtc = priv->channels[channel]->crtc;
+ struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+ struct drm_device *dev = omap_crtc->base.dev;
+
+ if (omap_crtc->framedone_handler)
+ return -EBUSY;
+
+ dev_dbg(dev->dev, "register framedone %s", omap_crtc->name);
+
+ omap_crtc->framedone_handler = handler;
+ omap_crtc->framedone_handler_data = data;
+
return 0;
}
@@ -238,6 +253,17 @@ static void omap_crtc_dss_unregister_framedone(
struct omap_drm_private *priv, enum omap_channel channel,
void (*handler)(void *), void *data)
{
+ struct drm_crtc *crtc = priv->channels[channel]->crtc;
+ struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+ struct drm_device *dev = omap_crtc->base.dev;
+
+ dev_dbg(dev->dev, "unregister framedone %s", omap_crtc->name);
+
+ WARN_ON(omap_crtc->framedone_handler != handler);
+ WARN_ON(omap_crtc->framedone_handler_data != data);
+
+ omap_crtc->framedone_handler = NULL;
+ omap_crtc->framedone_handler_data = NULL;
}
static const struct dss_mgr_ops mgr_ops = {
@@ -303,6 +329,30 @@ void omap_crtc_vblank_irq(struct drm_crtc *crtc)
DBG("%s: apply done", omap_crtc->name);
}
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus)
+{
+ struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+
+ if (!omap_crtc->framedone_handler) {
+ dev_warn(omap_crtc->base.dev->dev, "no framedone handler?");
+ return;
+ }
+
+ omap_crtc->framedone_handler(omap_crtc->framedone_handler_data);
+
+ spin_lock(>dev->event_lock);
+ /* Send the vblank event if one has been requested. */
+ if (omap_crtc->event) {
+ drm_crtc_send_vblank_event(crtc, omap_crtc->event);
+ omap_crtc->event = NULL;
+ }
+ omap_crtc->pending = false;
+ spin_unlock(>dev->event_lock);
+
+ /* Wake up omap_atomic_complete. */
+ wake_up(_crtc->pending_wait);
+}
+
static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
{
struct omap_drm_private *priv = crtc->dev->dev_private;
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.h
b/drivers/gpu/drm/omapdrm/omap_crtc.h
index d9de437ba9dd..d33bbb7a4f90 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.h
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.h
@@ -41,5 +41,6 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
int omap_crtc_wait_pending(struct drm_crtc *crtc);
void omap_crtc_error_irq(struct drm_crtc *crtc, u32 irqstatus);
void omap_crtc_vblank_irq(struct drm_crtc *crtc);
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus);
#endif /* __OMAPDRM_CRTC_H__ */
diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 329ad26d6d50..01dda84ca2ee 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -85,6 +85,28 @@ int omap_irq_wait(struct drm_device *dev, struct
omap_irq_wait *wait,
return ret == 0 ? -1 : 0;
}
+int omap_irq_enable_framedone(struct drm_crtc *crtc, bool enable)
+{
+ struct drm_device *dev = crtc->dev;
+ struct omap_drm_private *priv = dev->dev_private;
+ unsigned long flags;
+ enum omap_channel channel = omap_crtc_channel(crtc);
+ int framedone_irq =
+ priv->dispc_ops->mgr_get_framedone_irq(priv->dispc, channel);
+
+ DBG("dev=%p, crtc=%u, enable=%d", dev, channel, enable);
+
+ spin_lock_irqsave(>wait_lock, flags);
+ if (enable)
+ priv->irq_mask |= framedone_irq;
+ else
+ priv->irq_mask &= ~framedone_irq;
+ omap_irq_update(dev);
+ spin_unlock_irqrestore(>wait_lock, flags);
+
+ return 0;
+}
+
Re: [PATCH] drm: restore is_master upon failure in drm_new_set_master()
On Wed, Nov 21, 2018 at 6:55 AM Daniel Vetter wrote: > > On Sun, Nov 18, 2018 at 08:57:20PM -0300, Sergio Correia wrote: > > When drm_new_set_master() fails, we restore the old master, however we may > > have changed the is_master flag to 1, before failing, and it may be the > > case it was 0 previously. Restore also this flag to its original state, in > > case of failure. > > > > Here is a problematic flow: we check is_master in drm_is_current_master(), > > then proceed to call drm_lease_owner() passing master. If we do not restore > > is_master status when drm_new_set_master() fails, we may have a situation > > in which is_master will be 1 and master itself, NULL, leading to the deref > > of a NULL pointer in drm_lease_owner(). > > > > This fixes the following OOPS, observed on an ArchLinux running a 4.19.2 > > kernel: > > > > [ 97.804282] BUG: unable to handle kernel NULL pointer dereference at > > 0080 > > [ 97.807224] PGD 0 P4D 0 > > [ 97.807224] Oops: [#1] PREEMPT SMP NOPTI > > [ 97.807224] CPU: 0 PID: 1348 Comm: xfwm4 Tainted: P OE > > 4.19.2-arch1-1-ARCH #1 > > [ 97.807224] Hardware name: To Be Filled By O.E.M. To Be Filled By > > O.E.M./AB350 Pro4, BIOS P5.10 10/16/2018 > > [ 97.807224] RIP: 0010:drm_lease_owner+0xd/0x20 [drm] > > [ 97.807224] Code: 83 c4 18 5b 5d c3 b8 ea ff ff ff eb e2 b8 ed ff ff ff > > eb db e8 b4 ca 68 fb 0f 1f 40 00 0f 1f 44 00 00 48 89 f8 eb 03 48 89 d0 > > <48> 8b 90 80 00 00 00 48 85 d2 75 f1 c3 66 0f 1f 44 00 00 0f 1f 44 > > [ 97.807224] RSP: 0018:b8cf08e07bb0 EFLAGS: 00010202 > > [ 97.807224] RAX: RBX: 9cf0f2586c00 RCX: > > 9cf0f2586c88 > > [ 97.807224] RDX: 9cf0ddbd8000 RSI: RDI: > > > > [ 97.807224] RBP: 9cf1040e9800 R08: R09: > > > > [ 97.807224] R10: deb30fd5d680 R11: deb30f5d6808 R12: > > 9cf1040e9888 > > [ 97.807224] R13: R14: dead0200 R15: > > 9cf0f2586cc8 > > [ 97.807224] FS: 7f4145513180() GS:9cf10ea0() > > knlGS: > > [ 97.807224] CS: 0010 DS: ES: CR0: 80050033 > > [ 97.807224] CR2: 0080 CR3: 0003d7548000 CR4: > > 003406f0 > > [ 97.807224] Call Trace: > > [ 97.807224] drm_is_current_master+0x1a/0x30 [drm] > > [ 97.807224] drm_master_release+0x3e/0x130 [drm] > > [ 97.807224] drm_file_free.part.0+0x2be/0x2d0 [drm] > > [ 97.807224] drm_open+0x1ba/0x1e0 [drm] > > [ 97.807224] drm_stub_open+0xaf/0xe0 [drm] > > [ 97.807224] chrdev_open+0xa3/0x1b0 > > [ 97.807224] ? cdev_put.part.0+0x20/0x20 > > [ 97.807224] do_dentry_open+0x132/0x340 > > [ 97.807224] path_openat+0x2d1/0x14e0 > > [ 97.807224] ? mem_cgroup_commit_charge+0x7a/0x520 > > [ 97.807224] do_filp_open+0x93/0x100 > > [ 97.807224] ? __check_object_size+0x102/0x189 > > [ 97.807224] ? _raw_spin_unlock+0x16/0x30 > > [ 97.807224] do_sys_open+0x186/0x210 > > [ 97.807224] do_syscall_64+0x5b/0x170 > > [ 97.807224] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > [ 97.807224] RIP: 0033:0x7f4147b07976 > > [ 97.807224] Code: 89 54 24 08 e8 7b f4 ff ff 8b 74 24 0c 48 8b 3c 24 41 > > 89 c0 44 8b 54 24 08 b8 01 01 00 00 89 f2 48 89 fe bf 9c ff ff ff 0f 05 > > <48> 3d 00 f0 ff ff 77 30 44 89 c7 89 44 24 08 e8 a6 f4 ff ff 8b 44 > > [ 97.807224] RSP: 002b:7ffcced96ca0 EFLAGS: 0293 ORIG_RAX: > > 0101 > > [ 97.807224] RAX: ffda RBX: 5619d5037f80 RCX: > > 7f4147b07976 > > [ 97.807224] RDX: 0002 RSI: 5619d46b969c RDI: > > ff9c > > [ 98.040039] RBP: 0024 R08: R09: > > > > [ 98.040039] R10: R11: 0293 R12: > > 0024 > > [ 98.040039] R13: 0012 R14: 5619d5035950 R15: > > 0012 > > [ 98.040039] Modules linked in: nct6775 hwmon_vid algif_skcipher af_alg > > nls_iso8859_1 nls_cp437 vfat fat uvcvideo videobuf2_vmalloc > > videobuf2_memops videobuf2_v4l2 videobuf2_common arc4 videodev media > > snd_usb_audio snd_hda_codec_hdmi snd_usbmidi_lib snd_rawmidi snd_seq_device > > mousedev input_leds iwlmvm mac80211 snd_hda_codec_realtek > > snd_hda_codec_generic snd_hda_intel snd_hda_codec edac_mce_amd kvm_amd > > snd_hda_core kvm iwlwifi snd_hwdep r8169 wmi_bmof cfg80211 snd_pcm > > irqbypass snd_timer snd libphy soundcore pinctrl_amd rfkill pcspkr > > sp5100_tco evdev gpio_amdpt k10temp mac_hid i2c_piix4 wmi pcc_cpufreq > > acpi_cpufreq vboxnetflt(OE) vboxnetadp(OE) vboxpci(OE) vboxdrv(OE) msr sg > > crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 > > fscrypto uas usb_storage dm_crypt hid_generic usbhid hid > > [ 98.040039] dm_mod raid1 md_mod sd_mod crct10dif_pclmul crc32_pclmul > > crc32c_intel ghash_clmulni_intel pcbc ahci libahci aesni_intel aes_x86_64 > >
Re: [linux-sunxi] [PATCH] drm/sun4i: wait on implicit fence before display
Hi,
Dne ponedeljek, 19. november 2018 ob 15:33:11 CET je Qiang Yu napisal(a):
> Render like lima will attach a fence to the framebuffer
> dma_buf, display like sun4i should wait it finish before
> show the framebuffer. Otherwise tearing will be observed.
Please resend this patch to all emails listed when running "scripts/
get_maintainer.pl" on this patch. You are missing at least sunxi maintainers.
Best regards,
Jernej
>
> Signed-off-by: Qiang Yu
> ---
> drivers/gpu/drm/sun4i/sun4i_layer.c| 2 ++
> drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 2 ++
> drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 2 ++
> 3 files changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c
> b/drivers/gpu/drm/sun4i/sun4i_layer.c index 750ad24de1d7..d68e663df9a0
> 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
> @@ -12,6 +12,7 @@
>
> #include
> #include
> +#include
> #include
>
> #include "sun4i_backend.h"
> @@ -114,6 +115,7 @@ static void sun4i_backend_layer_atomic_update(struct
> drm_plane *plane, }
>
> static const struct drm_plane_helper_funcs sun4i_backend_layer_helper_funcs
> = { + .prepare_fb = drm_gem_fb_prepare_fb,
> .atomic_disable = sun4i_backend_layer_atomic_disable,
> .atomic_update = sun4i_backend_layer_atomic_update,
> };
> diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c index 28c15c6ef1ef..7bc2ca2bd0c3
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -287,6 +288,7 @@ static void sun8i_ui_layer_atomic_update(struct
> drm_plane *plane, }
>
> static struct drm_plane_helper_funcs sun8i_ui_layer_helper_funcs = {
> + .prepare_fb = drm_gem_fb_prepare_fb,
> .atomic_check = sun8i_ui_layer_atomic_check,
> .atomic_disable = sun8i_ui_layer_atomic_disable,
> .atomic_update = sun8i_ui_layer_atomic_update,
> diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c index f4fe97813f94..815895795afd
> 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -315,6 +316,7 @@ static void sun8i_vi_layer_atomic_update(struct
> drm_plane *plane, }
>
> static struct drm_plane_helper_funcs sun8i_vi_layer_helper_funcs = {
> + .prepare_fb = drm_gem_fb_prepare_fb,
> .atomic_check = sun8i_vi_layer_atomic_check,
> .atomic_disable = sun8i_vi_layer_atomic_disable,
> .atomic_update = sun8i_vi_layer_atomic_update,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108845] login button not working as expected
https://bugs.freedesktop.org/show_bug.cgi?id=108845 Tapani Pälli changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/rockchip: update cursors asynchronously through atomic.
Hi Michael, On Fri, Nov 23, 2018 at 1:58 PM Michael Zoran wrote: > > On Fri, 2018-11-23 at 11:27 +0900, Tomasz Figa wrote: > > > > The point here is not about setting and resetting the plane->fb > > pointer. It's about what happens inside > > drm_atomic_set_fb_for_plane(). > > > > It calls drm_framebuffer_get() for the new fb and > > drm_framebuffer_put() for the old fb. In result, if the fb changes, > > the old fb, which had its reference count incremented in the atomic > > commit that set it to the plane before, has its reference count > > decremented. Moreover, if the new reference count becomes 0, > > drm_framebuffer_put() will immediately free the buffer. > > > > Freeing a buffer when the hardware is still scanning out of it isn't > > a > > good idea, is it? > > No, it's not. But the board I submitted the patch for doesn't have > anything like hot swapable ram. The ram access is still going to work, > just it might display something it shouldn't. Say for example if that > frame buffer got reused by somethig else and filled with new data in > the very small window. Thanks for a quick reply! To clarify, on the Rockchip platform this patch is for (and many other arm/arm64 SoCs) the display controller is behind an IOMMU. Freeing the buffer would mean unmapping the related IOVAs from the IOMMU. If the hardware is still scanning out from the unmapped addresses, it would cause IOMMU page faults. We don't have any good IOMMU page fault handling in the kernel, so on most platforms that would likely end up stalling the display controller completely (on Rockchip it does). > > But yes, I agree the best solution would be to not release the buffer > until the next vblank. > > Perhaps a good solution would be for the DRM api to have the concept of > a deferred release? Meaning if the put() call just added the frame > buffer to a list that DRM core could walk during the vblank. That > might be better then every single driver trying to work up a custom > solution. Agreed. Best regards, Tomasz ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108845] login button not working as expected
https://bugs.freedesktop.org/show_bug.cgi?id=108845 jyotiba changed: What|Removed |Added URL||http://www.newtours.demoaut ||.com Whiteboard||hfgfghf Keywords||love -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108845] login button not working as expected
https://bugs.freedesktop.org/show_bug.cgi?id=108845 Bug ID: 108845 Summary: login button not working as expected Product: DRI Version: DRI git Hardware: All OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: jyotibaingal...@gmail.com don't dare to come,you buggy fellow. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108844] not a crical prblem
https://bugs.freedesktop.org/show_bug.cgi?id=108844 Bug ID: 108844 Summary: not a crical prblem Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: All Status: NEW Severity: minor Priority: medium Component: General Assignee: dri-devel@lists.freedesktop.org Reporter: jyotibaingal...@gmail.com Created attachment 142584 --> https://bugs.freedesktop.org/attachment.cgi?id=142584=edit attached good to read and learn. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/7] drm/syncobj: use the timeline point in drm_syncobj_find_fence
On 2018年11月22日 19:30, Christian König wrote:
Am 22.11.18 um 07:52 schrieb zhoucm1:
On 2018年11月15日 19:12, Christian König wrote:
Implement finding the right timeline point in drm_syncobj_find_fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c
b/drivers/gpu/drm/drm_syncobj.c
index 589d884ccd58..d42c51520da4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -307,9 +307,17 @@ int drm_syncobj_find_fence(struct drm_file
*file_private,
return -ENOENT;
*fence = drm_syncobj_fence_get(syncobj);
- if (!*fence) {
+ if (!*fence)
ret = -EINVAL;
+
+ if (!ret && point) {
+ dma_fence_chain_for_each(*fence) {
+ if (!to_dma_fence_chain(*fence) ||
+ (*fence)->seqno <= point)
+ break;
This condition isn't enough to find proper point.
For two examples:
a. No garbage collection happens, the points in chain are
136912---18---20, if user wants to get point17, then
we should return node 18.
And that is exactly what's wrong in the original logic. In this case
we need to return 12, not 18 because point 17 could have already been
garbage collected.
I don't think so, the 'a' case I already assume there isn't garbage
collection. If user wants to get point17, then we should return node 18.
timeline means point[N] must be signaled later than point[N-1].
Point[12] just can make sure point[1] ~point[12] are signaled.
Point[18] signal can make sure point[17] is signaled.
So this case we need to return 18, not 12, which is key timeline concept.
-David
b. garbage collection happens on point6, chain would be updated to
1---3---9---12---18---20, if user wants to get point5, then we should
return node 3, but if user wants to get point 7, then we should
return node 9.
Why? That doesn't seem to make any sense to me.
I still have no idea how to satisfy all these requirements with your
current chain-fence. All these logic just are same we encountered
before, we're walking them again. After solving these problems, I
guess all design is similar as before.
In fact, I don't know what problem previous design has, maybe there
are some bugs, can't we fix these bugs by time going? Who can make
sure his implementation never have bugs?
Well there where numerous problems with the original design. For
example we need to reject the requirement that timeline fences are in
order because that doesn't make sense in the kernel.
When userspace does something like submitting fences in the order 1,
5, 3 then it is broken and can keep the pieces. In other words the
kernel should not care about that, but rather make sure that it never
looses any synchronization no matter what.
Regards,
Christian.
-David
+ }
}
+
drm_syncobj_put(syncobj);
return ret;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/rockchip: update cursors asynchronously through atomic.
Hi Helen,
On Fri, Nov 23, 2018 at 8:31 AM Helen Koike wrote:
>
> Hi Tomasz,
>
> On 11/20/18 4:48 AM, Tomasz Figa wrote:
> > Hi Helen,
> >
> > On Tue, Nov 20, 2018 at 4:08 AM Helen Koike
> > wrote:
> >>
> >> From: Enric Balletbo i Serra
> >>
> >> Add support to async updates of cursors by using the new atomic
> >> interface for that.
> >>
> >> Signed-off-by: Enric Balletbo i Serra
> >> [updated for upstream]
> >> Signed-off-by: Helen Koike
> >>
> >> ---
> >> Hello,
> >>
> >> This is the third version of the async-plane update suport to the
> >> Rockchip driver.
> >>
> >
> > Thanks for a quick respin. Please see my comments inline. (I'll try to
> > be better at responding from now on...)
> >
> >> I tested running igt kms_cursor_legacy and kms_atomic tests using a
> >> 96Boards Ficus.
> >>
> >> Note that before the patch, the following igt tests failed:
> >>
> >> basic-flip-before-cursor-atomic
> >> basic-flip-before-cursor-legacy
> >> cursor-vs-flip-atomic
> >> cursor-vs-flip-legacy
> >> cursor-vs-flip-toggle
> >> flip-vs-cursor-atomic
> >> flip-vs-cursor-busy-crc-atomic
> >> flip-vs-cursor-busy-crc-legacy
> >> flip-vs-cursor-crc-atomic
> >> flip-vs-cursor-crc-legacy
> >> flip-vs-cursor-legacy
> >>
> >> Full log: https://people.collabora.com/~koike/results-4.20/html/
> >>
> >> Now with the patch applied the following were fixed:
> >> basic-flip-before-cursor-atomic
> >> basic-flip-before-cursor-legacy
> >> flip-vs-cursor-atomic
> >> flip-vs-cursor-legacy
> >>
> >> Full log: https://people.collabora.com/~koike/results-4.20-async/html/
> >
> > Could you also test modetest, with the -C switch to test the legacy
> > cursor API? I remember it triggering crashes due to synchronization
> > issues easily.
>
> Sure. I tested with
> $ modetest -M rockchip -s 37:1920x1080 -C
>
> I also vary the mode but I couldn't trigger any crashes.
>
> >
> >>
> >> Tomasz, as you mentined in v2 about waiting the hardware before updating
> >> the framebuffer, now I call the loop you pointed out in the async path,
> >> was that what you had in mind? Or do you think I would make sense to
> >> call the vop_crtc_atomic_flush() instead of just exposing that loop?
> >>
> >> Thanks
> >> Helen
> >>
> >> Changes in v3:
> >> - Rebased on top of drm-misc
> >> - Fix missing include in rockchip_drm_vop.c
> >> - New function vop_crtc_atomic_commit_flush
> >>
> >> Changes in v2:
> >> - v2: https://patchwork.freedesktop.org/patch/254180/
> >> - Change the framebuffer as well to cover jumpy cursor when hovering
> >> text boxes or hyperlink. (Tomasz)
> >> - Use the PSR inhibit mechanism when accessing VOP hardware instead of
> >> PSR flushing (Tomasz)
> >>
> >> Changes in v1:
> >> - Rebased on top of drm-misc
> >> - In async_check call drm_atomic_helper_check_plane_state to check that
> >> the desired plane is valid and update various bits of derived state
> >> (clipped coordinates etc.)
> >> - In async_check allow to configure new scaling in the fast path.
> >> - In async_update force to flush all registered PSR encoders.
> >> - In async_update call atomic_update directly.
> >> - In async_update call vop_cfg_done needed to set the vop registers and
> >> take effect.
> >>
> >> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 36 ---
> >> drivers/gpu/drm/rockchip/rockchip_drm_psr.c | 37 +++
> >> drivers/gpu/drm/rockchip/rockchip_drm_psr.h | 3 +
> >> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 108 +---
> >> 4 files changed, 131 insertions(+), 53 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> >> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> >> index ea18cb2a76c0..08bec50d9c5d 100644
> >> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> >> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
> >> @@ -127,42 +127,6 @@ rockchip_user_fb_create(struct drm_device *dev,
> >> struct drm_file *file_priv,
> >> return ERR_PTR(ret);
> >> }
> >>
> >> -static void
> >> -rockchip_drm_psr_inhibit_get_state(struct drm_atomic_state *state)
> >> -{
> >> - struct drm_crtc *crtc;
> >> - struct drm_crtc_state *crtc_state;
> >> - struct drm_encoder *encoder;
> >> - u32 encoder_mask = 0;
> >> - int i;
> >> -
> >> - for_each_old_crtc_in_state(state, crtc, crtc_state, i) {
> >> - encoder_mask |= crtc_state->encoder_mask;
> >> - encoder_mask |= crtc->state->encoder_mask;
> >> - }
> >> -
> >> - drm_for_each_encoder_mask(encoder, state->dev, encoder_mask)
> >> - rockchip_drm_psr_inhibit_get(encoder);
> >> -}
> >> -
> >> -static void
> >> -rockchip_drm_psr_inhibit_put_state(struct drm_atomic_state *state)
> >> -{
> >> - struct drm_crtc *crtc;
> >> - struct drm_crtc_state *crtc_state;
> >> - struct drm_encoder *encoder;
> >> - u32 encoder_mask = 0;
> >> - int
[git pull] drm fixes for 4.20-rc4
Hi Linus, Regular drm fixes pull for rc4. amdgpu: Vega20 fixes, firmware loading fix, panel display fix, override fix i915: Sandybridge lockup fix, fastboot DSI panel fix, GPU hang on Broxton, GPU reloc fixes on pineview/bearlake ast: screen blurring fix, cursor appearance fix udmabuf: mmap fix vc4: NULL deref fix, async cursor update fix. All seems pretty normal at this stage, Thanks, Dave. drm-fixes-2018-11-23: drm i915, amdgpu, ast, vc4, udmabuf fixes The following changes since commit 9ff01193a20d391e8dbce4403dd5ef87c7eaaca6: Linux 4.20-rc3 (2018-11-18 13:33:44 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2018-11-23 for you to fetch changes up to 98c9cdfd34fbb62886e4c5a07e33661aa3352ef5: Merge tag 'drm-intel-fixes-2018-11-22' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-11-23 11:03:21 +1000) drm i915, amdgpu, ast, vc4, udmabuf fixes Boris Brezillon (2): drm/vc4: Fix NULL pointer dereference in the async update path drm/vc4: Set ->legacy_cursor_update to false when doing non-async updates Chris Wilson (2): drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture drm/i915: Write GPU relocs harder with gen3 Dave Airlie (3): Merge tag 'drm-misc-fixes-2018-11-21' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Merge branch 'drm-fixes-4.20' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2018-11-22' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes Evan Quan (1): drm/amd/powerplay: disable Vega20 DS related features Felix Kuehling (1): drm/amdgpu: Fix oops when pp_funcs->switch_power_profile is unset Gerd Hoffmann (1): udmabuf: set read/write flag when exporting Greathouse, Joseph (1): drm/amd/pp: handle negative values when reading OD Kenneth Feng (1): drm/amdgpu: Enable HDP memory light sleep Nicholas Kazlauskas (2): drm/amdgpu: Add amdgpu "max bpc" connector property (v2) drm/amd/display: Support amdgpu "max bpc" connector property (v2) Paul Kocialkowski (1): drm/fb-helper: Blacklist writeback when adding connectors to fbdev Takashi Iwai (1): drm/amdgpu: Add missing firmware entry for HAINAN Thomas Zimmermann (1): drm/ast: Remove existing framebuffers before loading driver Ville Syrjälä (3): drm/i915: Disable LP3 watermarks on all SNB machines drm/i915: Force a LUT update in intel_initial_commit() drm/i915: Add rotation readout for plane initial config Y.C. Chen (2): drm/ast: change resolution may cause screen blurred drm/ast: fixed cursor may disappear sometimes drivers/dma-buf/udmabuf.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 7 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 ++ drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 1 + drivers/gpu/drm/amd/amdgpu/soc15.c | 39 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 16 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 + drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 20 +-- drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 25 ++--- drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 23 ++-- drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c | 30 +++- drivers/gpu/drm/ast/ast_drv.c | 21 +++ drivers/gpu/drm/ast/ast_mode.c | 3 +- drivers/gpu/drm/drm_fb_helper.c| 3 ++ drivers/gpu/drm/i915/i915_gem_execbuffer.c | 7 +++- drivers/gpu/drm/i915/i915_gem_gtt.c| 5 +++ drivers/gpu/drm/i915/i915_gpu_error.c | 15 +++- drivers/gpu/drm/i915/i915_gpu_error.h | 8 - drivers/gpu/drm/i915/intel_display.c | 39 drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c| 41 +- drivers/gpu/drm/vc4/vc4_kms.c | 6 drivers/gpu/drm/vc4/vc4_plane.c| 15 ++-- 24 files changed, 273 insertions(+), 63 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108843] Laptop with ATI RX 580 doesn't turn the screen on when resuming.
https://bugs.freedesktop.org/show_bug.cgi?id=108843 --- Comment #1 from alex14...@yahoo.com --- Created attachment 142583 --> https://bugs.freedesktop.org/attachment.cgi?id=142583=edit Kernel config file -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108843] Laptop with ATI RX 580 doesn't turn the screen on when resuming.
https://bugs.freedesktop.org/show_bug.cgi?id=108843 Bug ID: 108843 Summary: Laptop with ATI RX 580 doesn't turn the screen on when resuming. Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: alex14...@yahoo.com Created attachment 142582 --> https://bugs.freedesktop.org/attachment.cgi?id=142582=edit dmesg When I close the laptop lid, the screen turns off, and the following appears in dmesg: [ 5802.486819] [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* displayport link status failed [ 5802.486840] [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed [ 5803.077555] [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* displayport link status failed [ 5803.077576] [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed When I open the lid, the screen stays blank. I'm running Slackware Current with a kernel built from drm-next-4.21-wip. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
AMDGPU with 4.19.x kernel - cannot enable DPM
Hi, I have recently tried to use dpm=1 with the amdgpu driver for the 4.19.x kernel, but unfortunately the screen just went black. This is a regression from the 4.18.x kernel. I have attached the full dmesg log, but the relevant section look to be: [8.958679] WARNING: CPU: 0 PID: 320 at drivers/gpu/drm/drm_mm.c:950 drm_mm_takedown+0x1f/0x30 [drm] [9.010509] Code: f6 c3 48 8d 41 c0 eb bb 0f 1f 00 66 66 66 66 90 48 8b 47 38 48 83 c7 38 48 39 c7 75 01 c3 48 c7 c7 a0 68 26 c0 e8 6b 4d e8 d9 <0f> 0b c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 [9.029395] RSP: 0018:ae0681e8f9e8 EFLAGS: 00010282 [9.034681] RAX: RBX: 91febbb9f900 RCX: [9.041875] RDX: 91fec3a1cf00 RSI: 91fec3a16868 RDI: 91fec3a16868 [9.049068] RBP: 91feb92b29a0 R08: R09: 91fb800bb480 [9.056260] R10: 9a4e7560 R11: 9b9b616d R12: 91feb92b2980 [9.063454] R13: R14: 0170 R15: 91feb938aee0 [9.070647] FS: 7f71200ee180() GS:91fec3a0() knlGS: [9.078821] CS: 0010 DS: ES: CR0: 80050033 [9.084625] CR2: 7f8be0615020 CR3: 00033b014000 CR4: 06f0 Cheers, Chris [0.00] microcode: microcode updated early to revision 0x1d, date = 2018-05-11 [0.00] Linux version 4.19.2-200.fc28.x86_64 (mockbu...@bkernel04.phx2.fedoraproject.org) (gcc version 8.2.1 20181105 (Red Hat 8.2.1-5) (GCC)) #1 SMP Wed Nov 14 20:58:35 UTC 2018 [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.19.2-200.fc28.x86_64 root=UUID=7bc6553b-42ee-439d-93fc-9a3677687624 ro rd.md=0 rd.lvm=0 rd.dm=0 console=ttyS0,115200n8 console=tty0 LANG=en_GB.UTF-8 vconsole.font=latarcyrheb-sun16 vconsole.keymap=uk rd.luks=0 pcie_aspm=force amdgpu.aspm=1 amdgpu.dpm=1 amdgpu.si_support=1 amdgpu.cik_support=1 radeon.si_support=0 radeon.cik_support=0 [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable [0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xafed] usable [0.00] BIOS-e820: [mem 0xafee-0xafee1fff] ACPI NVS [0.00] BIOS-e820: [mem 0xafee2000-0xafee] ACPI data [0.00] BIOS-e820: [mem 0xafef-0xafef] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00034fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: Gigabyte Technology Co., Ltd. EX58-UD3R/EX58-UD3R, BIOS FB 05/04/2009 [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 2664.805 MHz processor [0.004502] e820: update [mem 0x-0x0fff] usable ==> reserved [0.004504] e820: remove [mem 0x000a-0x000f] usable [0.004510] last_pfn = 0x35 max_arch_pfn = 0x4 [0.004514] MTRR default type: uncachable [0.004515] MTRR fixed ranges enabled: [0.004516] 0-9 write-back [0.004517] A-B uncachable [0.004518] C-C write-protect [0.004519] D-E uncachable [0.004520] F-F write-through [0.004521] MTRR variable ranges enabled: [0.004522] 0 base 0 mask F write-back [0.004523] 1 base 0C000 mask FC000 uncachable [0.004524] 2 base 0B000 mask FF000 uncachable [0.004526] 3 base 1 mask F write-back [0.004527] 4 base 2 mask E write-back [0.004528] 5 base 3 mask F8000 write-back [0.004529] 6 base 36000 mask FE000 uncachable [0.004530] 7 base 35000 mask FF000 uncachable [0.005245] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.005582] e820: update [mem 0xb000-0x] usable ==> reserved [0.005586] e820: update [mem 0x35000-0x37fff] usable ==> reserved [0.005590] last_pfn = 0xafee0 max_arch_pfn = 0x4 [0.011108] found SMP MP-table at [mem 0x000f5c20-0x000f5c2f] mapped at [(ptrval)] [0.021866] Base memory trampoline at [(ptrval)] 98000 size 24576 [0.021872] BRK [0x32de01000, 0x32de01fff] PGTABLE [0.021874] BRK [0x32de02000, 0x32de02fff] PGTABLE [0.021875] BRK [0x32de03000, 0x32de03fff] PGTABLE [0.021902] BRK [0x32de04000, 0x32de04fff] PGTABLE [0.021904] BRK [0x32de05000, 0x32de05fff] PGTABLE [0.021993] BRK [0x32de06000, 0x32de06fff] PGTABLE [0.022005] BRK [0x32de07000, 0x32de07fff] PGTABLE [0.022021]
linux-next: manual merge of the drm-misc tree with the drm tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/Makefile
between commit:
2bb42410b1bd ("drm: Remove drm_global.{c,h} v2")
from the drm tree and commit:
c6fdea6e1a19 ("drm: Merge drm_info.c into drm_debugfs.c")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/Makefile
index 7f3be3506057,7c88f12096c5..
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@@ -10,8 -10,8 +10,8 @@@ drm-y :=drm_auth.o drm_bufs.o dr
drm_scatter.o drm_pci.o \
drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
- drm_info.o drm_encoder_slave.o \
+ drm_encoder_slave.o \
- drm_trace_points.o drm_global.o drm_prime.o \
+ drm_trace_points.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
pgpKzVkfdvFzf.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #66 from Brandon Wright --- (In reply to bmilreu from comment #65) > Is there an easy way to backport this to 4.19 mainline? Would be very useful > to integrate the fix into stable kernels. > > As it is currently it wont work on 4.19 because it uses > which isnt mainlined yet. Brandon's hack works on > 4.19 just in case it matters. Just remove the header include. There was some refactoring, and the functions needed in that file are in the others included. > Last question, is this patch https://patchwork.freedesktop.org/patch/263412/ > you just submitted related to this issue? Looks like it's related. Thanks for taking on our issue, Nicholas. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #65 from bmil...@gmail.com --- (In reply to Nicholas Kazlauskas from comment #64) > Created attachment 142574 [details] [review] > 0001-drm-amd-display-Add-fast-path-for-legacy-cursor-plan.patch > > This patch is similar to the async_update one but it takes care to lock if > anything is modifying the plane. It's very close to what i915 does with a > few minor differences with framebuffer handling. > > I've tested it for compton with Gallium HUD up and I no longer see the issue > on mouse movement (cursor fb changes are still a bit slow, so you'll still > probably see spikes on cursor changes). > > You can try this on top of amd-staging-drm-next and I'd imagine it'd fix > your problems. Patch does work for me. Is there an easy way to backport this to 4.19 mainline? Would be very useful to integrate the fix into stable kernels. As it is currently it wont work on 4.19 because it uses which isnt mainlined yet. Brandon's hack works on 4.19 just in case it matters. Last question, is this patch https://patchwork.freedesktop.org/patch/263412/ you just submitted related to this issue? Thanks a LOT for tackling this Nicholas and Brandon -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 28/36] drm/amdgpu: fix bug with IH ring setup
From: Philip Yang [ Upstream commit c837243ff4017f493c7d6f4ab57278d812a86859 ] The bug limits the IH ring wptr address to 40bit. When the system memory is bigger than 1TB, the bus address is more than 40bit, this causes the interrupt cannot be handled and cleared correctly. Reviewed-by: Christian König Signed-off-by: Philip Yang Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/vega10_ih.c b/drivers/gpu/drm/amd/amdgpu/vega10_ih.c index 5ae5ed2e62d6..21bc12e02311 100644 --- a/drivers/gpu/drm/amd/amdgpu/vega10_ih.c +++ b/drivers/gpu/drm/amd/amdgpu/vega10_ih.c @@ -129,7 +129,7 @@ static int vega10_ih_irq_init(struct amdgpu_device *adev) else wptr_off = adev->wb.gpu_addr + (adev->irq.ih.wptr_offs * 4); WREG32_SOC15(OSSSYS, 0, mmIH_RB_WPTR_ADDR_LO, lower_32_bits(wptr_off)); - WREG32_SOC15(OSSSYS, 0, mmIH_RB_WPTR_ADDR_HI, upper_32_bits(wptr_off) & 0xFF); + WREG32_SOC15(OSSSYS, 0, mmIH_RB_WPTR_ADDR_HI, upper_32_bits(wptr_off) & 0x); /* set rptr, wptr to 0 */ WREG32_SOC15(OSSSYS, 0, mmIH_RB_RPTR, 0); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #64 from Nicholas Kazlauskas --- Created attachment 142574 --> https://bugs.freedesktop.org/attachment.cgi?id=142574=edit 0001-drm-amd-display-Add-fast-path-for-legacy-cursor-plan.patch This patch is similar to the async_update one but it takes care to lock if anything is modifying the plane. It's very close to what i915 does with a few minor differences with framebuffer handling. I've tested it for compton with Gallium HUD up and I no longer see the issue on mouse movement (cursor fb changes are still a bit slow, so you'll still probably see spikes on cursor changes). You can try this on top of amd-staging-drm-next and I'd imagine it'd fix your problems. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #53 from fin4...@hotmail.com --- Created attachment 142573 --> https://bugs.freedesktop.org/attachment.cgi?id=142573=edit AMD wip kernel config with 1000Hz timer -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #52 from fin4...@hotmail.com --- To prevent random kernel lock ups with Ryzen, fix this with bios, set to Typical Current Idle in the bios Advanced/AMD CBS menu. Use latest AMD wip kernel and Oibaf ppa Mesa. Disable display composting and vsync with Xfce. Use 300Hz kernel timer. Working kernel config file for my system as attachment. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #63 from bmil...@gmail.com --- (In reply to Brandon Wright from comment #62) > (In reply to tempel.julian from comment #61) > > I just noticed that it works fine with xf86-video-amdgpu driver, but with > > modesetting driver, xorg or the driver freezes when starting/logging in. Not > > sure if this is related to latest 4.21-wip-changes or the cursor patch > > though. > I'm getting the modesetting freeze, too, on 4.20-rc3, so it's likely the > cursor patch. I called it a "fix", in quotation marks for a reason. I've > barely looked at the KMS/DRM stuff for an hour, so I have no clue what I'm > doing. I just wanted to show the AMD guys that we have pinpointed the > problem, give them something that we can confirm no longer produces the > problem, and hope that they'd go ahead and do things correctly. Probably easy to make the workaround only activate on xf86-video-amdgpu. I luckily don't need the modesetting driver for anything that I'm aware off, what do you guys use that driver for ? Is it for GPU switching? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108781] 4.19 Regression - Hawaii (R9 390) boot failure - Invalid PCC GPIO / invalid powerlevel state / Fatal error during GPU init
https://bugs.freedesktop.org/show_bug.cgi?id=108781 --- Comment #19 from Jim Haddad --- This happened to me 7 days ago when Fedora replaced kernel-4.18.18-300.fc29 with kernel-4.19.2-300.fc29. Also on kernel-4.19.3-300.fc29 from yesterday. On a different hard drive I tried rawhide and kernel-4.20.0-0.rc3.git1.1.fc30. Same thing. I have also been using radeon.cik_support=0 amdgpu.cik_support=1 amdgpu.dpm=1 amdgpu.dc=1 because it crashes without it. Removing amdgpu.dpm=1 didn't fix this. Removing all of these didn't fix this. I have a Sapphire R9 290. Fedora says downgrading the kernel isn't supported but downgrading to kernel-4.18.18-300.fc29 seems to work. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #17 from Shmerl --- (In reply to Nicholas Kazlauskas from comment #13) > > This does help narrow down the problem, thanks. Is there any chance of fixing this in 4.20? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable
Am 22.11.18 um 17:51 schrieb Daniel Vetter:
> We need to make sure implementations don't cheat and don't have a
> possible schedule/blocking point deeply burried where review can't
> catch it.
>
> I'm not sure whether this is the best way to make sure all the
> might_sleep() callsites trigger, and it's a bit ugly in the code flow.
> But it gets the job done.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: David Rientjes
> Cc: "Christian König"
> Cc: Daniel Vetter
> Cc: "Jérôme Glisse"
> Cc: linux...@kvack.org
> Signed-off-by: Daniel Vetter
> ---
> mm/mmu_notifier.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> index 59e102589a25..4d282cfb296e 100644
> --- a/mm/mmu_notifier.c
> +++ b/mm/mmu_notifier.c
> @@ -185,7 +185,13 @@ int __mmu_notifier_invalidate_range_start(struct
> mm_struct *mm,
> id = srcu_read_lock();
> hlist_for_each_entry_rcu(mn, >mmu_notifier_mm->list, hlist) {
> if (mn->ops->invalidate_range_start) {
> - int _ret = mn->ops->invalidate_range_start(mn, mm,
> start, end, blockable);
> + int _ret;
> +
> + if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP) && !blockable)
> + preempt_disable();
> + _ret = mn->ops->invalidate_range_start(mn, mm, start,
> end, blockable);
> + if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP) && !blockable)
> + preempt_enable();
Just for the sake of better documenting this how about adding this to
include/linux/kernel.h right next to might_sleep():
#define disallow_sleeping_if(cond) for((cond) ? preempt_disable() :
(void)0; (cond); preempt_disable())
(Just from the back of my head, might contain peanuts and/or hints of
errors).
Christian.
> if (_ret) {
> pr_info("%pS callback failed with %d in
> %sblockable context.\n",
>
> mn->ops->invalidate_range_start, _ret,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail
Am 22.11.18 um 17:51 schrieb Daniel Vetter:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Cc: Andrew Morton
> Cc: Michal Hocko
> Cc: "Christian König"
> Cc: David Rientjes
> Cc: Daniel Vetter
> Cc: "Jérôme Glisse"
> Cc: linux...@kvack.org
> Cc: Paolo Bonzini
> Signed-off-by: Daniel Vetter
Acked-by: Christian König
> ---
> mm/mmu_notifier.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> index 5119ff846769..59e102589a25 100644
> --- a/mm/mmu_notifier.c
> +++ b/mm/mmu_notifier.c
> @@ -190,6 +190,8 @@ int __mmu_notifier_invalidate_range_start(struct
> mm_struct *mm,
> pr_info("%pS callback failed with %d in
> %sblockable context.\n",
>
> mn->ops->invalidate_range_start, _ret,
> !blockable ? "non-" : "");
> + WARN(blockable,"%pS callback failure not
> allowed\n",
> + mn->ops->invalidate_range_start);
> ret = _ret;
> }
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #62 from Brandon Wright --- (In reply to tempel.julian from comment #61) > I just noticed that it works fine with xf86-video-amdgpu driver, but with > modesetting driver, xorg or the driver freezes when starting/logging in. Not > sure if this is related to latest 4.21-wip-changes or the cursor patch > though. I'm getting the modesetting freeze, too, on 4.20-rc3, so it's likely the cursor patch. I called it a "fix", in quotation marks for a reason. I've barely looked at the KMS/DRM stuff for an hour, so I have no clue what I'm doing. I just wanted to show the AMD guys that we have pinpointed the problem, give them something that we can confirm no longer produces the problem, and hope that they'd go ahead and do things correctly. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #51 from Allan --- Tried to install the RX480 on the other PC : the card is too big that it touches the RAM slot's tabs. Can't install it. In time, seems like the errors delay a little bit when setting randomize_va_space=0. Was testing it for the CPU and noticed that amdgpu delayed to fail, but it still failed. What happened : - the screen got granulated with pinkish colors as usual - desktop extended this behavior - but I could operate the system - tty was black and white (normal) - I could restart x server - colors got normal after restarting - tried the same application again - crashed and froze the system Main difference : - now sometimes I can kill the tasks/restart xserver I registered the times of each event, here follows: (Firefox was opened in background while I tried to play Left for Dead 2 through steam) 1. Recoverable delay with granulated colors (l4d2 begins 11:48, occurs 11:50 after some delay while loading the game menu) > [Thu Nov 22 11:48:03 2018] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring > sdma0 timeout, signaled seq=11477, emitted seq=11480 > [Thu Nov 22 11:48:03 2018] amdgpu :09:00.0: GPU reset begin! > [Thu Nov 22 11:48:03 2018] amdgpu :09:00.0: GPU pci config reset > [Thu Nov 22 11:48:03 2018] amdgpu :09:00.0: GPU reset succeeded, trying > to resume > [Thu Nov 22 11:48:03 2018] [drm] PCIE GART of 256M enabled (table at > 0x00F40030). > [Thu Nov 22 11:48:03 2018] [drm:amdgpu_device_gpu_recover [amdgpu]] *ERROR* > VRAM is lost! > [Thu Nov 22 11:48:04 2018] amdgpu :09:00.0: [drm:amdgpu_ring_test_helper > [amdgpu]] *ERROR* ring comp_1.3.1 test failed (-110) > [Thu Nov 22 11:48:04 2018] [drm] UVD and UVD ENC initialized successfully. > [Thu Nov 22 11:48:04 2018] [drm] VCE initialized successfully. > [Thu Nov 22 11:48:04 2018] [drm] recover vram bo from shadow start > [Thu Nov 22 11:48:04 2018] [drm] recover vram bo from shadow done > [Thu Nov 22 11:48:04 2018] [drm] Skip scheduling IBs! > [Thu Nov 22 11:48:04 2018] [drm] Skip scheduling IBs! > [Thu Nov 22 11:48:04 2018] amdgpu :09:00.0: GPU reset(1) succeeded! > [Thu Nov 22 11:48:04 2018] [drm] Skip scheduling IBs! > [Thu Nov 22 11:48:04 2018] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to > initialize parser -125! > [Thu Nov 22 11:48:04 2018] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to > initialize parser -125! > [Thu Nov 22 11:48:04 2018] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to > initialize parser -125! > [Thu Nov 22 11:48:04 2018] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to > initialize parser -125! > [Thu Nov 22 11:48:06 2018] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to > initialize parser -125! > [Thu Nov 22 11:50:46 2018] show_signal_msg: 9 callbacks suppressed > [Thu Nov 22 11:50:46 2018] Chrome_~dThread[1734]: segfault at 0 ip > 7f7926c4c181 sp 7f792493aad0 error 6 in > libxul.so[7f7926c38000+3a2c000] > [Thu Nov 22 11:50:46 2018] Code: 15 dc f2 5f 04 48 89 10 c7 04 25 00 00 00 00 > 7c 09 00 00 e8 21 60 ff ff 90 48 8b 05 f9 2a 9b 05 48 8d 0d 22 f3 5f 04 48 89 > 08 04 25 00 00 00 00 02 0a 00 00 e8 ff 5f ff ff e8 0a f3 ff ff 48 > [Thu Nov 22 11:50:46 2018] Chrome_~dThread[1885]: segfault at 0 ip > 7f7fa150a181 sp 7f7f9f1f8ad0 error 6 in > libxul.so[7f7fa14f6000+3a2c000] > [Thu Nov 22 11:50:46 2018] Chrome_~dThread[8072]: segfault at 0 ip > 7fffededa181 sp 7fffebbc8ad0 error 6 > [Thu Nov 22 11:50:46 2018] Code: 15 dc f2 5f 04 48 89 10 c7 04 25 00 00 00 00 > 7c 09 00 00 e8 21 60 ff ff 90 48 8b 05 f9 2a 9b 05 48 8d 0d 22 f3 5f 04 48 89 > 08 04 25 00 00 00 00 02 0a 00 00 e8 ff 5f ff ff e8 0a f3 ff ff 48 > [Thu Nov 22 11:50:46 2018] in libxul.so[7fffedec6000+3a2c000] > [Thu Nov 22 11:50:46 2018] Code: 15 dc f2 5f 04 48 89 10 c7 04 25 00 00 00 00 > 7c 09 00 00 e8 21 60 ff ff 90 48 8b 05 f9 2a 9b 05 48 8d 0d 22 f3 5f 04 48 89 > 08 04 25 00 00 00 00 02 0a 00 00 e8 ff 5f ff ff e8 0a f3 ff ff 48 > [Thu Nov 22 11:50:46 2018] Chrome_~dThread[1931]: segfault at 0 ip > 7f8dc581f181 sp 7f8dc350dad0 error 6 in > libxul.so[7f8dc580b000+3a2c000] > [Thu Nov 22 11:50:46 2018] Code: 15 dc f2 5f 04 48 89 10 c7 04 25 00 00 00 00 > 7c 09 00 00 e8 21 60 ff ff 90 48 8b 05 f9 2a 9b 05 48 8d 0d 22 f3 5f 04 48 89 > 08 04 25 00 00 00 00 02 0a 00 00 e8 ff 5f ff ff e8 0a f3 ff ff 48 kern.log = dmesg 2. Unrecoverable crash (l4d2 begins 12:00, goes well until 12:55 when crashes everything) dmesg: > [Thu Nov 22 12:55:04 2018] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring > gfx timeout, signaled seq=1688198, emitted seq=1688200 > [Thu Nov 22 12:55:04 2018] amdgpu :09:00.0: GPU reset begin! > [Thu Nov 22 12:55:14 2018] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* > [CRTC:46:crtc-0] hw_done or flip_done timed out kern.log = dmesg Xorg log is not reporting anything useful. (In reply to russianneuromancer from comment #50) > Can't tell you about RX480, but I know for
Re: [PATCH v3 1/3] drm/connector: Add generic underscan properties
Hi Boris,
Just because I happened to read the docs in here, one typo below:
On Thu, Nov 22, 2018 at 12:23:29PM +0100, Boris Brezillon wrote:
>We have 3 drivers defining the "underscan", "underscan hborder" and
>"underscan vborder" properties (radeon, amd and nouveau) and we are
>about to add the same kind of thing in VC4.
>
>Define generic underscan props and add new fields to the drm_connector
>state so that the property parsing logic can be shared by all DRM
>drivers.
>
>A driver can now attach underscan properties to its connector through
>the drm_connector_attach_underscan_properties() helper, and can
>check/apply the underscan setup based on the
>drm_connector_state->underscan fields.
>
>Signed-off-by: Boris Brezillon
>---
>Changes in v3:
>- None
>
>Changes in v2:
>- Add a new section in the connector props doc to describe underscan
> props
>- Fix description of auto mode (auto means apply underscan for HDMI
> monitors only)
>- Fix description of vborder/hborder:
>right_border = left_border = hborder
>top_border = bottom_border = vborder
> not
>right_border = left_border = hborder / 2
>top_border = bottom_border = vborder / 2
>- Rename drm_underscan into drm_underscan_state
>---
> drivers/gpu/drm/drm_atomic_uapi.c | 12 +++
> drivers/gpu/drm/drm_connector.c | 127 ++
> include/drm/drm_connector.h | 80 +++
> 3 files changed, 219 insertions(+)
>
>diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>b/drivers/gpu/drm/drm_atomic_uapi.c
>index d5b7f315098c..39db6e31c565 100644
>--- a/drivers/gpu/drm/drm_atomic_uapi.c
>+++ b/drivers/gpu/drm/drm_atomic_uapi.c
>@@ -740,6 +740,12 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>
> return set_out_fence_for_connector(state->state, connector,
> fence_ptr);
>+ } else if (property == connector->underscan_mode_property) {
>+ state->underscan.mode = val;
>+ } else if (property == connector->underscan_hborder_property) {
>+ state->underscan.hborder = val;
>+ } else if (property == connector->underscan_vborder_property) {
>+ state->underscan.vborder = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
>@@ -799,6 +805,12 @@ drm_atomic_connector_get_property(struct drm_connector
>*connector,
> *val = state->scaling_mode;
> } else if (property == connector->content_protection_property) {
> *val = state->content_protection;
>+ } else if (property == connector->underscan_mode_property) {
>+ *val = state->underscan.mode;
>+ } else if (property == connector->underscan_hborder_property) {
>+ *val = state->underscan.hborder;
>+ } else if (property == connector->underscan_vborder_property) {
>+ *val = state->underscan.vborder;
> } else if (property == config->writeback_fb_id_property) {
> /* Writeback framebuffer is one-shot, write and forget */
> *val = 0;
>diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>index c555e17ab8d7..170317248da6 100644
>--- a/drivers/gpu/drm/drm_connector.c
>+++ b/drivers/gpu/drm/drm_connector.c
>@@ -971,6 +971,38 @@ DRM_ENUM_NAME_FN(drm_get_content_protection_name,
>drm_cp_enum_list)
> *can also expose this property to external outputs, in which case they
> *must support "None", which should be the default (since external screens
> *have a built-in scaler).
>+ *
>+ * Connectors for non-analog outputs may also have standardized underscan
>+ * properties (drivers can set this up by calling
>+ * drm_connector_attach_content_protection_property() on initialization):
Should be drm_connector_attach_underscan_properties()
Cheers,
-Brian
>+ *
>+ * underscan:
>+ *This properties defines whether underscan is activated or not, and when
>+ *it is activated, how the horizontal and vertical borders are calculated:
>+ *
>+ *off:
>+ *Underscan is disabled. The output image shouldn't be scaled to
>+ *take screen borders into account.
>+ *on:
>+ *Underscan is activated and horizontal and vertical borders are
>+ *specified through the "underscan hborder" and
>+ *"underscan vborder" properties.
>+ *auto:
>+ *Underscan is activated only for HDMI monitors.
>+ *
>+ * underscan hborder:
>+ *Horizontal border expressed in pixels. The border is symmetric, which
>+ *means you'll have a border of 'hborder' pixels on the left and on the
>+ *same border on the right.
>+ *When this value is 0 and underscan is "on" or "auto", the driver will
>+ *pick a default value (the default value is driver dependent).
>+ *
>+ * underscan vborder:
>+ *
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #61 from tempel.jul...@gmail.com --- Thanks a lot @ Brandon Wright, your patch really does the trick. I also totally agree on your opinion that it should be mainlined as at least a temporary solution (and also get backported to older kernels). I just noticed that it works fine with xf86-video-amdgpu driver, but with modesetting driver, xorg or the driver freezes when starting/logging in. Not sure if this is related to latest 4.21-wip-changes or the cursor patch though. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108781] 4.19 Regression - Hawaii (R9 390) boot failure - Invalid PCC GPIO / invalid powerlevel state / Fatal error during GPU init
https://bugs.freedesktop.org/show_bug.cgi?id=108781 --- Comment #18 from freedesk...@nuclearsunshine.com --- I just hit this as well with 4.19 on Fedora and a R9 390X - Grub shows fine, then no video output after that (monitor goes into power save), and boot doesn't seem to continue (no disk activity etc.) I removed amdgpu.dpm=1 from my kernel params and was able to boot with 4.19.x - I noticed that everyone who mentions kernel params on this bug has this param present too - try without it? This is a regression vs. 4.18.x - with that kernel series I was able to boot with amdgpu.dpm=1 without issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail
Quoting Daniel Vetter (2018-11-22 16:51:04) > Just a bit of paranoia, since if we start pushing this deep into > callchains it's hard to spot all places where an mmu notifier > implementation might fail when it's not allowed to. Most callers could handle the failure correctly. It looks like the failure was not propagated for convenience. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] mm: Check if mmu notifier callbacks are allowed to fail
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: "Christian König"
Cc: David Rientjes
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: Paolo Bonzini
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 5119ff846769..59e102589a25 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -190,6 +190,8 @@ int __mmu_notifier_invalidate_range_start(struct mm_struct
*mm,
pr_info("%pS callback failed with %d in
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
!blockable ? "non-" : "");
+ WARN(blockable,"%pS callback failure not
allowed\n",
+mn->ops->invalidate_range_start);
ret = _ret;
}
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] mm, notifier: Catch sleeping/blocking for !blockable
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
I'm not sure whether this is the best way to make sure all the
might_sleep() callsites trigger, and it's a bit ugly in the code flow.
But it gets the job done.
Cc: Andrew Morton
Cc: Michal Hocko
Cc: David Rientjes
Cc: "Christian König"
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 59e102589a25..4d282cfb296e 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -185,7 +185,13 @@ int __mmu_notifier_invalidate_range_start(struct mm_struct
*mm,
id = srcu_read_lock();
hlist_for_each_entry_rcu(mn, >mmu_notifier_mm->list, hlist) {
if (mn->ops->invalidate_range_start) {
- int _ret = mn->ops->invalidate_range_start(mn, mm,
start, end, blockable);
+ int _ret;
+
+ if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP) && !blockable)
+ preempt_disable();
+ _ret = mn->ops->invalidate_range_start(mn, mm, start,
end, blockable);
+ if (IS_ENABLED(CONFIG_DEBUG_ATOMIC_SLEEP) && !blockable)
+ preempt_enable();
if (_ret) {
pr_info("%pS callback failed with %d in
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] RFC: mmu notifier debug checks
Hi all, We're having some good fun with the i915 mmu notifier (it deadlocks), and I think it'd be very useful to have a bunch more runtime debug checks to catch screw-ups. I'm also working on some lockdep improvements in gpu code (better annotations and stuff like that). Together with this series here this seems to catch a lot of bugs pretty much instantly, which previously took hours/days of CI workloads to reproduce. Plus now you get nice backtraces and the kernel keeps working, whereas without this it's real deadlocks with piles of stuck processes (the deadlock needed at least 3 processes, but generally it took more to close the loop, plus everyone piling in on top). If this looks like a good idea I'm happy to polish it for merging. Thanks, Daniel Daniel Vetter (3): mm: Check if mmu notifier callbacks are allowed to fail mm, notifier: Catch sleeping/blocking for !blockable mm, notifier: Add a lockdep map for invalidate_range_start include/linux/mmu_notifier.h | 7 +++ mm/mmu_notifier.c| 17 - 2 files changed, 23 insertions(+), 1 deletion(-) -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] mm, notifier: Add a lockdep map for invalidate_range_start
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them. But both at the
same time is really hard to reliable hit, especially when you want to
exercise paths like direct reclaim or compaction, where it's not
easy to control what exactly will be unmapped.
By introducing a lockdep map to tie them all together we allow lockdep
to see a lot more dependencies, without having to actually hit them
in a single challchain while testing.
Aside: Since I typed this to test i915 mmu notifiers I've only rolled
this out for the invaliate_range_start callback. If there's
interest, we should probably roll this out to all of them. But my
undestanding of core mm is seriously lacking, and I'm not clear on
whether we need a lockdep map for each callback, or whether some can
be shared.
Cc: Andrew Morton
Cc: David Rientjes
Cc: "Jérôme Glisse"
Cc: Michal Hocko
Cc: "Christian König"
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: Mike Rapoport
Cc: linux...@kvack.org
Signed-off-by: Daniel Vetter
---
include/linux/mmu_notifier.h | 7 +++
mm/mmu_notifier.c| 7 +++
2 files changed, 14 insertions(+)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 9893a6432adf..a39ba218dbbe 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -12,6 +12,10 @@ struct mmu_notifier_ops;
#ifdef CONFIG_MMU_NOTIFIER
+#ifdef CONFIG_LOCKDEP
+extern struct lockdep_map __mmu_notifier_invalidate_range_start_map;
+#endif
+
/*
* The mmu notifier_mm structure is allocated and installed in
* mm->mmu_notifier_mm inside the mm_take_all_locks() protected
@@ -267,8 +271,11 @@ static inline void mmu_notifier_change_pte(struct
mm_struct *mm,
static inline void mmu_notifier_invalidate_range_start(struct mm_struct *mm,
unsigned long start, unsigned long end)
{
+ mutex_acquire(&__mmu_notifier_invalidate_range_start_map, 0, 0,
+ _RET_IP_);
if (mm_has_notifiers(mm))
__mmu_notifier_invalidate_range_start(mm, start, end, true);
+ mutex_release(&__mmu_notifier_invalidate_range_start_map, 1, _RET_IP_);
}
static inline int mmu_notifier_invalidate_range_start_nonblock(struct
mm_struct *mm,
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 4d282cfb296e..c6e797927376 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -23,6 +23,13 @@
/* global SRCU for all MMs */
DEFINE_STATIC_SRCU(srcu);
+#ifdef CONFIG_LOCKDEP
+struct lockdep_map __mmu_notifier_invalidate_range_start_map = {
+ .name = "mmu_notifier_invalidate_range_start"
+};
+EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_start_map);
+#endif
+
/*
* This function allows mmu_notifier::release callback to delay a call to
* a function that will free appropriate resources. The function must be
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/7] mm, devm_memremap_pages: Mark devm_memremap_pages() EXPORT_SYMBOL_GPL
On Thu, Nov 22, 2018 at 02:30:13PM +0100, Michal Hocko wrote: > Whoever needs a wrapper around arch_add_memory can do so because this > symbol has no restriction for the usage. arch_add_memory is not exported, and it really should not be. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/7] mm, devm_memremap_pages: Mark devm_memremap_pages() EXPORT_SYMBOL_GPL
On Thu, Nov 22, 2018 at 05:38:58PM +0100, Christoph Hellwig wrote: > On Thu, Nov 22, 2018 at 02:30:13PM +0100, Michal Hocko wrote: > > Whoever needs a wrapper around arch_add_memory can do so because this > > symbol has no restriction for the usage. > > arch_add_memory is not exported, and it really should not be. And in some older trees it oddly has an EXPORY_SYMBOL_GPL on x86 and sh, but no actual modular users.. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102637] Radeon 9600 Pro (Mac Version) shows funky colours on console and X (ppc64)
https://bugs.freedesktop.org/show_bug.cgi?id=102637 erhar...@mailbox.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from erhar...@mailbox.org --- Can no longer reproduce. Colours are looking good on kernel 4.14.78 and 4.19.2. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #60 from Brandon Wright --- > There are larger problems within amdgpu_dm's commit tail that if addressed > should resolve this issue for compton I'd imagine. Honestly, I don't care about compton. I don't think you realize the effects of this issue. It seriously affects performance when the cursor is in motion with any page-flipping application. GNOME and KDE, while the window motion is less affected, stutter in composited client applications. > This is a nice attempt but it only resolves the problem because it relies on > the blocking behavior in atomic check that amdgpu_dm currently does > (and shouldn't be doing). > > Asynchronous updates can and will occur in parallel with other commits on > worker threads. Without the wait in atomic_check you'll see the IGT legacy > cursor tests break with this patch (and there will probably be system faults > as well). You'd have to point this out to me, because I didn't see anything that would obviously block, unless it's buried in dc_validate_plane. Since, as you say, atomic_check is blocking for now, why not work around this issue with a tiny change. If someone ever gets around to doing things the correct way it's no big deal to remove. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/meson: Fixes for drm_crtc_vblank_on/off support
Since Linux 4.17, calls to drm_crtc_vblank_on/off are mandatory, and we get
a warning when ctrc is disabled :
" driver forgot to call drm_crtc_vblank_off()"
But, the vsync IRQ was not totally disabled due the transient hardware
state and specific interrupt line, thus adding proper IRQ masking from
the HHI system control registers.
The last change fixes a race condition introduced by calling the added
drm_crtc_vblank_on/off when an HPD event occurs from the HDMI connector,
triggering a WARN_ON() in the _atomic_begin() callback when the CRTC
is disabled, thus also triggering a WARN_ON() in drm_vblank_put() :
WARNING: CPU: 0 PID: 1185 at drivers/gpu/drm/meson/meson_crtc.c:157
meson_crtc_atomic_begin+0x78/0x80
[...]
Call trace:
meson_crtc_atomic_begin+0x78/0x80
drm_atomic_helper_commit_planes+0x140/0x218
drm_atomic_helper_commit_tail+0x38/0x80
commit_tail+0x7c/0x80
drm_atomic_helper_commit+0xdc/0x150
drm_atomic_commit+0x54/0x60
restore_fbdev_mode_atomic+0x198/0x238
restore_fbdev_mode+0x6c/0x1c0
drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xf0
drm_fb_helper_set_par+0x34/0x60
drm_fb_helper_hotplug_event.part.28+0xb8/0xc8
drm_fbdev_client_hotplug+0xa4/0xe0
drm_client_dev_hotplug+0x90/0xe0
drm_kms_helper_hotplug_event+0x3c/0x48
drm_helper_hpd_irq_event+0x134/0x168
dw_hdmi_top_thread_irq+0x3c/0x50
[...]
WARNING: CPU: 0 PID: 1185 at drivers/gpu/drm/drm_vblank.c:1026
drm_vblank_put+0xb4/0xc8
[...]
Call trace:
drm_vblank_put+0xb4/0xc8
drm_crtc_vblank_put+0x24/0x30
drm_atomic_helper_wait_for_vblanks.part.9+0x130/0x2b8
drm_atomic_helper_commit_tail+0x68/0x80
[...]
The issue is that vblank need to be enabled in any occurence of :
- atomic_enable()
- atomic_begin() and state->enable == true, which was not the case
Moving the CRTC enable code to a common function and calling in one
of these occurence solves this race condition and makes sure vblank
is enabled in each call to _atomic_begin() from the HPD event leading
to drm_atomic_helper_commit_planes().
To Summarize :
- Make sure that the CRTC code will call the drm_crtc_vblank_on()/off()
- *Really* mask the Vsync IRQ
- Initialize and enable vblank at the first _atomic_begin()/_atomic_enable()
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 27 +--
drivers/gpu/drm/meson/meson_venc.c | 3 +++
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index d78168f979db..75d97f1b2e8f 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -46,6 +46,7 @@ struct meson_crtc {
struct drm_crtc base;
struct drm_pending_vblank_event *event;
struct meson_drm *priv;
+ bool enabled;
};
#define to_meson_crtc(x) container_of(x, struct meson_crtc, base)
@@ -81,8 +82,7 @@ static const struct drm_crtc_funcs meson_crtc_funcs = {
};
-static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
-struct drm_crtc_state *old_state)
+static void meson_crtc_enable(struct drm_crtc *crtc)
{
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
struct drm_crtc_state *crtc_state = crtc->state;
@@ -106,6 +106,22 @@ static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
writel_bits_relaxed(VPP_POSTBLEND_ENABLE, VPP_POSTBLEND_ENABLE,
priv->io_base + _REG(VPP_MISC));
+ drm_crtc_vblank_on(crtc);
+
+ meson_crtc->enabled = true;
+}
+
+static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
+struct drm_crtc_state *old_state)
+{
+ struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
+ struct meson_drm *priv = meson_crtc->priv;
+
+ DRM_DEBUG_DRIVER("\n");
+
+ if (!meson_crtc->enabled)
+ meson_crtc_enable(crtc);
+
priv->viu.osd1_enabled = true;
}
@@ -117,6 +133,8 @@ static void meson_crtc_atomic_disable(struct drm_crtc *crtc,
DRM_DEBUG_DRIVER("\n");
+ drm_crtc_vblank_off(crtc);
+
priv->viu.osd1_enabled = false;
priv->viu.osd1_commit = false;
@@ -135,6 +153,8 @@ static void meson_crtc_atomic_disable(struct drm_crtc *crtc,
crtc->state->event = NULL;
}
+
+ meson_crtc->enabled = false;
}
static void meson_crtc_atomic_begin(struct drm_crtc *crtc,
@@ -143,6 +163,9 @@ static void meson_crtc_atomic_begin(struct drm_crtc *crtc,
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
unsigned long flags;
+ if (crtc->state->enable && !meson_crtc->enabled)
+ meson_crtc_enable(crtc);
+
if (crtc->state->event) {
WARN_ON(drm_crtc_vblank_get(crtc) != 0);
diff --git a/drivers/gpu/drm/meson/meson_venc.c
b/drivers/gpu/drm/meson/meson_venc.c
index 9be0376e0329..ab72ddda242d 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++
Re: [PATCH AUTOSEL 4.9 08/17] drm/edid: Add 6 bpc quirk for BOE panel.
On Wed, Nov 21, 2018 at 10:33:18AM +0100, Daniel Vetter wrote: On Wed, Nov 21, 2018 at 10:31 AM Daniel Vetter wrote: On Tue, Nov 13, 2018 at 12:52:14AM -0500, Sasha Levin wrote: > From: "Lee, Shawn C" > > [ Upstream commit 922dceff8dc1fb4dafc9af78139ba65671408103 ] > > BOE panel (ID: 0x0771) that reports "DFP 1.x compliant TMDS". > But it's 6bpc panel only instead of 8 bpc. > > Add panel ID to edid quirk list and set 6 bpc as default to > work around this issue. > > Cc: Jani Nikula > Cc: Maarten Lankhorst > Cc: Gustavo Padovan > Cc: Cooper Chiou > Signed-off-by: Lee, Shawn C > > Signed-off-by: Daniel Vetter > Link: https://patchwork.freedesktop.org/patch/msgid/1540792173-7288-1-git-send-email-shawn.c@intel.com > Signed-off-by: Sasha Levin Given that I'm not a fan of AUTOSEL at all: This one here is correctly cherry-picked for stable, ack. An idea that just crossed my mind: Could we integrate this into 0day and suggest cc: stable before the patch even gets merged? Or is the heuristics not good enough for that kind of automation? Yes! I've actually tried it before but it seemed that the response rate was quite low (even for commits that are obviously stable material) so I turned it off to avoid spamming too much. If you'd like to be the guinea pig for this, I could enable it for drivers/gpu/drm/i915/ which I currently completely ignore. If at any point you want it back off that's easy to do. If this works well we can extend it to more subsystems where maintainers might find it useful. -- Thanks, Sasha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201763] amdgpu: [powerplay] VBIOS did not find boot engine clock value in dependency table. Using Memory DPM level 0!
https://bugzilla.kernel.org/show_bug.cgi?id=201763 --- Comment #2 from Michel Dänzer (mic...@daenzer.net) --- From the dmesg output, it looks like the AMD GPU is powered off most of the time. Do the freezes happen when you explicitly use it for something, e.g. for a game via DRI_PRIME=1? -- 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: [alsa-devel] [Xen-devel][PATCH 3/3] ALSA: xen-front: Use Xen common shared buffer implementation
On Thu, 22 Nov 2018 11:02:30 +0100,
Oleksandr Andrushchenko wrote:
>
> @@ -214,12 +221,19 @@ static void stream_clear(struct
> xen_snd_front_pcm_stream_info *stream)
> stream->out_frames = 0;
> atomic_set(>hw_ptr, 0);
> xen_snd_front_evtchnl_pair_clear(stream->evt_pair);
> - xen_snd_front_shbuf_clear(>sh_buf);
> + memset(>shbuf, 0, sizeof(stream->shbuf));
> + stream->buffer = NULL;
> + stream->buffer_sz = 0;
> + stream->pages = NULL;
> + stream->num_pages = 0;
> }
>
> static void stream_free(struct xen_snd_front_pcm_stream_info *stream)
> {
> - xen_snd_front_shbuf_free(>sh_buf);
> + xen_front_pgdir_shbuf_unmap(>shbuf);
> + xen_front_pgdir_shbuf_free(>shbuf);
> + free_pages_exact(stream->buffer, stream->buffer_sz);
> + kfree(stream->pages);
> stream_clear(stream);
> }
>
> @@ -421,10 +435,34 @@ static int alsa_close(struct snd_pcm_substream
> *substream)
> return 0;
> }
>
> +static int shbuf_setup_backstore(struct xen_snd_front_pcm_stream_info
> *stream,
> + size_t buffer_sz)
> +{
> + int i;
> +
> + stream->buffer_sz = buffer_sz;
> + stream->buffer = alloc_pages_exact(stream->buffer_sz, GFP_KERNEL);
> + if (!stream->buffer)
> + return -ENOMEM;
This keeps the NULL stream->buffer, and then the caller goes to the
error path via stream_free() which will lead to an Oops due to the
unconditional call of free_pages_exact().
thanks,
Takashi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #59 from bmil...@gmail.com --- (In reply to Nicholas Kazlauskas from comment #58) > (In reply to Brandon Wright from comment #55) > > Created attachment 142558 [details] [review] [review] > > Patch that "fixes" the problem. > > > > I've attached a patch that fixes the problem for me. It copies parts from > > the intel patch and uses the existing async infrastructure for the cursor. > > > > It's really tiny, so I hope this is helpful enough to get this problem fixed > > quick. > > This is a nice attempt but it only resolves the problem because it relies on > the blocking behavior in atomic check that amdgpu_dm currently does (and > shouldn't be doing). > > Asynchronous updates can and will occur in parallel with other commits on > worker threads. Without the wait in atomic_check you'll see the IGT legacy > cursor tests break with this patch (and there will probably be system faults > as well). > > There are larger problems within amdgpu_dm's commit tail that if addressed > should resolve this issue for compton I'd imagine. Since you've been working on Freesync, you should know your patches are also affected by this bug on some wine games. Any chance you could you kindly try to tackle this? btw, I don't have igt on my system atm, nor got any system fault yet with the patch. I really need dc for the extra headphone jack, mine is broken atm :( -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/atomic-helper: Complete fake_commit->flip_done potentially earlier
Op 22-11-18 om 15:34 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> Consider the following scenario:
> 1. nonblocking enable crtc
> 2. wait for the event
> 3. nonblocking disable crtc
>
> On i915 this can lead to a spurious -EBUSY from step 3 on
> account of non-enabled planes getting the fake_commit in step 1
> and we don't complete the fake_commit-> flip_done until
> drm_atomic_helper_commit_hw_done() which can happen a long
> time after the flip event was sent out.
>
> This will become somewhat easy to hit on SKL+ once we start
> to add all the planes for the crtc to every modeset commit
> for the purposes of forcing a watermark register programming
> [1].
>
> To make the race a little less pronounced let's complete
> fake_commit->flip_done after drm_atomic_helper_wait_for_flip_done().
> For the single crtc case this should make the race quite
> theoretical, assuming drm_atomic_helper_wait_for_flip_done()
> actually has to wait for the real commit flip_done. In case
> the real commit flip_done gets completed singificantly before
> drm_atomic_helper_wait_for_flip_done(), or we are dealing with
> multiple crtcs whose vblanks don't line up nicely the race still
> exists.
>
> [1] https://patchwork.freedesktop.org/patch/262670/
>
> Cc: Maarten Lankhorst
> Fixes: 080de2e5be2d ("drm/atomic: Check for busy planes/connectors before
> setting the commit")
> Testcase: igt/kms_cursor_legacy/*nonblocking-modeset-vs-cursor-atomic
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index fa95f9974f6d..47398662b895 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1460,6 +1460,9 @@ void drm_atomic_helper_wait_for_flip_done(struct
> drm_device *dev,
> DRM_ERROR("[CRTC:%d:%s] flip_done timed out\n",
> crtc->base.id, crtc->name);
> }
> +
> + if (old_state->fake_commit)
> + complete_all(_state->fake_commit->flip_done);
> }
> EXPORT_SYMBOL(drm_atomic_helper_wait_for_flip_done);
>
Yeah as long as we don't enable hw_done sooner, this should be fine.
For both patches:
Reviewed-by: Maarten Lankhorst
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/prime: Fix drm_gem_prime_mmap() stack use
Den 22.11.2018 10.06, skrev Daniel Vetter:
On Wed, Nov 21, 2018 at 07:02:15PM +0100, Noralf Trønnes wrote:
drivers/gpu/drm/drm_prime.c: In function 'drm_gem_prime_mmap':
drivers/gpu/drm/drm_prime.c:688:1: warning: the frame size of 1592 bytes is
larger than 1024 bytes [-Wframe-larger-than=]
Fix by allocating on the heap.
Fixes: 7698799f9554 ("drm/prime: Add drm_gem_prime_mmap()")
Reported-by: kbuild test robot
Cc: Daniel Vetter
Cc: Christian König
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
Thanks Daniel, applied to drm-misc-next.
Noralf.
---
drivers/gpu/drm/drm_prime.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 5737cb8c6f03..231e3f6d5f41 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -663,24 +663,33 @@ EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
*/
int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
{
- /* Used by drm_gem_mmap() to lookup the GEM object */
- struct drm_file priv = {
- .minor = obj->dev->primary,
- };
- struct file fil = {
- .private_data = ,
- };
+ struct drm_file *priv;
+ struct file *fil;
int ret;
- ret = drm_vma_node_allow(>vma_node, );
+ priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+ fil = kzalloc(sizeof(*fil), GFP_KERNEL);
+ if (!priv || !fil) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ /* Used by drm_gem_mmap() to lookup the GEM object */
+ priv->minor = obj->dev->primary;
+ fil->private_data = priv;
+
+ ret = drm_vma_node_allow(>vma_node, priv);
if (ret)
- return ret;
+ goto out;
vma->vm_pgoff += drm_vma_node_start(>vma_node);
- ret = obj->dev->driver->fops->mmap(, vma);
+ ret = obj->dev->driver->fops->mmap(fil, vma);
- drm_vma_node_revoke(>vma_node, );
+ drm_vma_node_revoke(>vma_node, priv);
+out:
+ kfree(priv);
+ kfree(fil);
return ret;
}
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/atomic-helper: WARN if fake_commit->hw_done is not completed as expected
From: Ville Syrjälä
For real commits we WARN if ->hw_done hasn't been completed by the time
drm_atomic_helper_commit_cleanup_done() is called. Let's do the same for
the fake commit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 47398662b895..bc9fc9665614 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2220,8 +2220,10 @@ void drm_atomic_helper_commit_cleanup_done(struct
drm_atomic_state *old_state)
spin_unlock(>commit_lock);
}
- if (old_state->fake_commit)
+ if (old_state->fake_commit) {
complete_all(_state->fake_commit->cleanup_done);
+
WARN_ON(!try_wait_for_completion(_state->fake_commit->hw_done));
+ }
}
EXPORT_SYMBOL(drm_atomic_helper_commit_cleanup_done);
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/atomic-helper: Complete fake_commit->flip_done potentially earlier
From: Ville Syrjälä
Consider the following scenario:
1. nonblocking enable crtc
2. wait for the event
3. nonblocking disable crtc
On i915 this can lead to a spurious -EBUSY from step 3 on
account of non-enabled planes getting the fake_commit in step 1
and we don't complete the fake_commit-> flip_done until
drm_atomic_helper_commit_hw_done() which can happen a long
time after the flip event was sent out.
This will become somewhat easy to hit on SKL+ once we start
to add all the planes for the crtc to every modeset commit
for the purposes of forcing a watermark register programming
[1].
To make the race a little less pronounced let's complete
fake_commit->flip_done after drm_atomic_helper_wait_for_flip_done().
For the single crtc case this should make the race quite
theoretical, assuming drm_atomic_helper_wait_for_flip_done()
actually has to wait for the real commit flip_done. In case
the real commit flip_done gets completed singificantly before
drm_atomic_helper_wait_for_flip_done(), or we are dealing with
multiple crtcs whose vblanks don't line up nicely the race still
exists.
[1] https://patchwork.freedesktop.org/patch/262670/
Cc: Maarten Lankhorst
Fixes: 080de2e5be2d ("drm/atomic: Check for busy planes/connectors before
setting the commit")
Testcase: igt/kms_cursor_legacy/*nonblocking-modeset-vs-cursor-atomic
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index fa95f9974f6d..47398662b895 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1460,6 +1460,9 @@ void drm_atomic_helper_wait_for_flip_done(struct
drm_device *dev,
DRM_ERROR("[CRTC:%d:%s] flip_done timed out\n",
crtc->base.id, crtc->name);
}
+
+ if (old_state->fake_commit)
+ complete_all(_state->fake_commit->flip_done);
}
EXPORT_SYMBOL(drm_atomic_helper_wait_for_flip_done);
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel][PATCH 2/3] drm/xen-front: Use Xen common shared buffer implementation
On Thu, Nov 22, 2018 at 12:02:29PM +0200, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Use page directory based shared buffer implementation
> now available as common code for Xen frontend drivers.
>
> Signed-off-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/xen/Kconfig | 1 +
> drivers/gpu/drm/xen/Makefile | 1 -
> drivers/gpu/drm/xen/xen_drm_front.c | 60 ++--
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 1 -
> drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 414 --
> drivers/gpu/drm/xen/xen_drm_front_shbuf.h | 64
> 6 files changed, 30 insertions(+), 511 deletions(-)
> delete mode 100644 drivers/gpu/drm/xen/xen_drm_front_shbuf.c
> delete mode 100644 drivers/gpu/drm/xen/xen_drm_front_shbuf.h
>
> diff --git a/drivers/gpu/drm/xen/Kconfig b/drivers/gpu/drm/xen/Kconfig
> index 4cca160782ab..f969d486855d 100644
> --- a/drivers/gpu/drm/xen/Kconfig
> +++ b/drivers/gpu/drm/xen/Kconfig
> @@ -12,6 +12,7 @@ config DRM_XEN_FRONTEND
> select DRM_KMS_HELPER
> select VIDEOMODE_HELPERS
> select XEN_XENBUS_FRONTEND
> + select XEN_FRONT_PGDIR_SHBUF
> help
> Choose this option if you want to enable a para-virtualized
> frontend DRM/KMS driver for Xen guest OSes.
> diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile
> index 712afff5ffc3..825905f67faa 100644
> --- a/drivers/gpu/drm/xen/Makefile
> +++ b/drivers/gpu/drm/xen/Makefile
> @@ -4,7 +4,6 @@ drm_xen_front-objs := xen_drm_front.o \
> xen_drm_front_kms.o \
> xen_drm_front_conn.o \
> xen_drm_front_evtchnl.o \
> - xen_drm_front_shbuf.o \
> xen_drm_front_cfg.o \
> xen_drm_front_gem.o
>
> diff --git a/drivers/gpu/drm/xen/xen_drm_front.c
> b/drivers/gpu/drm/xen/xen_drm_front.c
> index 6b6d5ab82ec3..9597544fecc1 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front.c
> @@ -19,6 +19,7 @@
> #include
> #include
>
> +#include
> #include
>
> #include "xen_drm_front.h"
> @@ -26,28 +27,20 @@
> #include "xen_drm_front_evtchnl.h"
> #include "xen_drm_front_gem.h"
> #include "xen_drm_front_kms.h"
> -#include "xen_drm_front_shbuf.h"
>
> struct xen_drm_front_dbuf {
> struct list_head list;
> u64 dbuf_cookie;
> u64 fb_cookie;
> - struct xen_drm_front_shbuf *shbuf;
> +
> + struct xen_front_pgdir_shbuf shbuf;
> };
>
> -static int dbuf_add_to_list(struct xen_drm_front_info *front_info,
> - struct xen_drm_front_shbuf *shbuf, u64 dbuf_cookie)
> +static void dbuf_add_to_list(struct xen_drm_front_info *front_info,
> + struct xen_drm_front_dbuf *dbuf, u64 dbuf_cookie)
> {
> - struct xen_drm_front_dbuf *dbuf;
> -
> - dbuf = kzalloc(sizeof(*dbuf), GFP_KERNEL);
> - if (!dbuf)
> - return -ENOMEM;
> -
> dbuf->dbuf_cookie = dbuf_cookie;
> - dbuf->shbuf = shbuf;
> list_add(>list, _info->dbuf_list);
> - return 0;
> }
>
> static struct xen_drm_front_dbuf *dbuf_get(struct list_head *dbuf_list,
> @@ -64,11 +57,14 @@ static struct xen_drm_front_dbuf *dbuf_get(struct
> list_head *dbuf_list,
>
> static void dbuf_flush_fb(struct list_head *dbuf_list, u64 fb_cookie)
> {
> +#if IS_ENABLED(CONFIG_X86)
> struct xen_drm_front_dbuf *buf, *q;
>
> list_for_each_entry_safe(buf, q, dbuf_list, list)
> if (buf->fb_cookie == fb_cookie)
> - xen_drm_front_shbuf_flush(buf->shbuf);
> + drm_clflush_pages(buf->shbuf.pages,
> + buf->shbuf.num_pages);
> +#endif
Why do we need to clflush here only on x86? Feels fairly fishy, but I
think we've discussed this problem for long time with the original
submission already.
Anyway, I'm all for code duplication removal, so if the Xen folks are
happy with patch 1, this one here has my ack. Might also be best to merge
all three through the Xen tree. Fallback would be xen folks sending a
topic pull request with these 3 patches to drm-misc and takashi's sound
tree.
-Daniel
> }
>
> static void dbuf_free(struct list_head *dbuf_list, u64 dbuf_cookie)
> @@ -78,8 +74,8 @@ static void dbuf_free(struct list_head *dbuf_list, u64
> dbuf_cookie)
> list_for_each_entry_safe(buf, q, dbuf_list, list)
> if (buf->dbuf_cookie == dbuf_cookie) {
> list_del(>list);
> - xen_drm_front_shbuf_unmap(buf->shbuf);
> - xen_drm_front_shbuf_free(buf->shbuf);
> + xen_front_pgdir_shbuf_unmap(>shbuf);
> + xen_front_pgdir_shbuf_free(>shbuf);
> kfree(buf);
> break;
> }
> @@ -91,8 +87,8 @@ static void dbuf_free_all(struct list_head *dbuf_list)
>
>
[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #58 from Nicholas Kazlauskas --- (In reply to Brandon Wright from comment #55) > Created attachment 142558 [details] [review] > Patch that "fixes" the problem. > > I've attached a patch that fixes the problem for me. It copies parts from > the intel patch and uses the existing async infrastructure for the cursor. > > It's really tiny, so I hope this is helpful enough to get this problem fixed > quick. This is a nice attempt but it only resolves the problem because it relies on the blocking behavior in atomic check that amdgpu_dm currently does (and shouldn't be doing). Asynchronous updates can and will occur in parallel with other commits on worker threads. Without the wait in atomic_check you'll see the IGT legacy cursor tests break with this patch (and there will probably be system faults as well). There are larger problems within amdgpu_dm's commit tail that if addressed should resolve this issue for compton I'd imagine. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
