[RFC PATCH] drm/radeon: program auxch directly
From: Dave Airlie The atombios tables have an unfortunate restriction on only being able to write 12 bytes, MST really wants 16-bytes here, and since the hw can do it, we should just write directly to it. This uses a module option to allow for it now, and maybe we should provide the old code as a fallback for a while. Signed-off-by: Dave Airlie --- Just putting this out there for people to know I'm doing it, most likely I'd want to merge on by default for MST systems at least. TODO: testing, irq support? drivers/gpu/drm/radeon/Makefile | 2 +- drivers/gpu/drm/radeon/atombios_dp.c | 5 +- drivers/gpu/drm/radeon/radeon.h | 3 + drivers/gpu/drm/radeon/radeon_dp_auxch.c | 253 +++ drivers/gpu/drm/radeon/radeon_drv.c | 4 + 5 files changed, 265 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/radeon/radeon_dp_auxch.c diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile index 4605633..fa635f0 100644 --- a/drivers/gpu/drm/radeon/Makefile +++ b/drivers/gpu/drm/radeon/Makefile @@ -81,7 +81,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \ rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o \ trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \ ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o \ - radeon_sync.o radeon_audio.o + radeon_sync.o radeon_audio.o radeon_dp_auxch.o radeon-$(CONFIG_MMU_NOTIFIER) += radeon_mn.o diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c index db42a67..37594b2 100644 --- a/drivers/gpu/drm/radeon/atombios_dp.c +++ b/drivers/gpu/drm/radeon/atombios_dp.c @@ -223,7 +223,10 @@ void radeon_dp_aux_init(struct radeon_connector *radeon_connector) radeon_connector->ddc_bus->rec.hpd = radeon_connector->hpd.hpd; radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev; - radeon_connector->ddc_bus->aux.transfer = radeon_dp_aux_transfer; + if (radeon_auxch) + radeon_connector->ddc_bus->aux.transfer = radeon_dp_aux_transfer_native; + else + radeon_connector->ddc_bus->aux.transfer = radeon_dp_aux_transfer; ret = drm_dp_aux_register(&radeon_connector->ddc_bus->aux); if (!ret) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 5587603..bd4e8bd 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -111,6 +111,7 @@ extern int radeon_deep_color; extern int radeon_use_pflipirq; extern int radeon_bapm; extern int radeon_backlight; +extern int radeon_auxch; /* * Copy from radeon_drv.h so we don't have to include both and have conflicting @@ -3112,6 +3113,8 @@ int r600_cs_common_vline_parse(struct radeon_cs_parser *p, uint32_t *vline_start_end, uint32_t *vline_status); +ssize_t +radeon_dp_aux_transfer_native(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg); #include "radeon_object.h" #endif diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c b/drivers/gpu/drm/radeon/radeon_dp_auxch.c new file mode 100644 index 000..0cf94e6 --- /dev/null +++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c @@ -0,0 +1,253 @@ +/* + * Copyright 2015 Red Hat Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + * + * Authors: Dave Airlie + */ +#include +#include +#include "radeon.h" + +/* HW definitions */ +#define DP_AUX_CONTROL 0x6200 + +#define DP_AUX_CONTROL_AUX_EN (1 << 0) +#define DP_AUX_CONTROL_AUX_LS_READ_EN (1 << 8) +#define DP_AUX_CONTROL_AUX_LS_UPDATE_DISABLE(x) (((x) & 0x1) << 12) +#define DP_AUX_CONTROL_AUX_HPD_DISCON(x) (((x) & 0x1) << 16) +#define DP_AUX_CONTROL_AUX_DET_EN (1 << 18) +#define DP_AUX_CONTROL_AUX_HPD_SEL(x) (((x) & 0x7) << 20) +#define DP_AUX_CONTROL_AUX_IMPCAL_REQ_EN (1 << 24) +#define DP_A
[Bug 89015] [radeonsi] unvanquished & nexuiz crash after switching AA
https://bugs.freedesktop.org/show_bug.cgi?id=89015 --- Comment #12 from Arek RuÅniak --- and for 1->2 trigger is: 27c686309e035d211c7cf38d1c0902f1bf2886c5 is the first bad commit commit 27c686309e035d211c7cf38d1c0902f1bf2886c5 Author: Axel Davy Date: Wed Jun 18 23:27:30 2014 -0400 gallium: Add __DRIimageDriverExtension support to gallium __DRIimageDriverExtension is used by GLX DRI3 and Wayland. This patch is a rewrite of http://lists.freedesktop.org/archives/mesa-dev/2014-May/060318.html and http://lists.freedesktop.org/archives/mesa-dev/2014-May/060317.html Previous patches were: Signed-off-by: Ben Skeggs Signed-off-by: Keith Packard Signed-off-by: Axel Davy Reviewed-by: Marek Olšák Reviewed-by: Ben Skeggs Signed-off-by: Dave Airlie :04 04 bed5212b498ec77bf272f1caa433442a3e897601 d1b1be3159255a47c2fa21e2ad0735798cbc78b7 Msrc -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/81b4e67f/attachment.html>
[Bug 89198] Setting Refresh Rate on monitor causes flickering/artifacting
https://bugs.freedesktop.org/show_bug.cgi?id=89198 --- Comment #15 from andre35822 at yahoo.com --- Created attachment 113676 --> https://bugs.freedesktop.org/attachment.cgi?id=113676&action=edit xorg log with patch from comment 15 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/193b2d6a/attachment.html>
[Bug 89198] Setting Refresh Rate on monitor causes flickering/artifacting
https://bugs.freedesktop.org/show_bug.cgi?id=89198 --- Comment #16 from andre35822 at yahoo.com --- Created attachment 113677 --> https://bugs.freedesktop.org/attachment.cgi?id=113677&action=edit dmesg log with patch from comment 15 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/96179de7/attachment-0001.html>
[Bug 89198] Setting Refresh Rate on monitor causes flickering/artifacting
https://bugs.freedesktop.org/show_bug.cgi?id=89198 --- Comment #17 from andre35822 at yahoo.com --- (In reply to Alex Deucher from comment #14) > (In reply to andre35822 from comment #13) > > Just thought I would post a little update, I am in the process of getting my > > system to use the new kernel. Ive already compiled it with the patch and > > stuff, i am just having a bit of trouble creating a ramdisk (I am followeing > > the arch linux wiki) although I will figure it out. Will the fixes from > > comment 19 and 20 be implemented into the next release of video-ati or does > > it still need testing? I am asking this so that if I know it isn't I may as > > well compile another kernel with the patches from 19 and 20. Thank you btw > > for everything. > > FWIW, using make install in your kernel tree will usually handle the ramdisk > update, but I'm not that familiar with arch, so if you are comfortable with > that, I'd stick with that. > > As for the patches from 19 and 20, I'm pretty confident they will work, but > it would be nice to get some confirmation. Alright so I tried out the kernel I compiled with the patch from comment 15 on the other bug report, and either I didn't install the patch correctly (or it didnt install correctly) or the patch is not solving the problem. I am still getting the flickering/artifacts. I have attached an xorg log and dmesg log and added comment15_patch to each of their file names so they are easily distinguishable. Should I be compiling another kernel with the patches from comment 19 and 20? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/de8fe14c/attachment.html>
[Bug 89198] Setting Refresh Rate on monitor causes flickering/artifacting
https://bugs.freedesktop.org/show_bug.cgi?id=89198 --- Comment #18 from Alex Deucher --- (In reply to andre35822 from comment #17) > Alright so I tried out the kernel I compiled with the patch from comment 15 > on the other bug report, and either I didn't install the patch correctly (or > it didnt install correctly) or the patch is not solving the problem. I am > still getting the flickering/artifacts. I have attached an xorg log and > dmesg log and added comment15_patch to each of their file names so they are > easily distinguishable. Should I be compiling another kernel with the > patches from comment 19 and 20? The patch from comment 15 doesn't fix anything. It just adds some additional debugging output that might be useful in fine tuning the patches in comments 19 and 20. To fix the issue, use the patches in comments 19 and 20. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/04c56967/attachment.html>
[Bug 88978] [bisected] [SI Scheduler] Graphical corruption in Dota 2
https://bugs.freedesktop.org/show_bug.cgi?id=88978 --- Comment #9 from sarnex --- (In reply to Daniel Scharrer from comment #8) > The Mesa patch from bug 88561 comment 6 fixes this for me - at least the > glitches with the posted apitrace. Hi Daniel, Thanks for the information. The patch from Marek significantly reduces the number of artifacts in Dota 2, but it does not completely fix the issue and I still see a few artifacts per second. It seems that this bug and the Portal bug are related, but there is still an underlying bug somewhere. Thanks, sarnex -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/144683a2/attachment.html>
[Bug 89198] Setting Refresh Rate on monitor causes flickering/artifacting
https://bugs.freedesktop.org/show_bug.cgi?id=89198 --- Comment #19 from andre35822 at yahoo.com --- (In reply to Alex Deucher from comment #18) > (In reply to andre35822 from comment #17) > > Alright so I tried out the kernel I compiled with the patch from comment 15 > > on the other bug report, and either I didn't install the patch correctly (or > > it didnt install correctly) or the patch is not solving the problem. I am > > still getting the flickering/artifacts. I have attached an xorg log and > > dmesg log and added comment15_patch to each of their file names so they are > > easily distinguishable. Should I be compiling another kernel with the > > patches from comment 19 and 20? > > The patch from comment 15 doesn't fix anything. It just adds some > additional debugging output that might be useful in fine tuning the patches > in comments 19 and 20. To fix the issue, use the patches in comments 19 and > 20. Oh okay thats good then, that means I applied the patch correctly. Shall I apply the 19 and 20 patches now or would you prefer for a later date incase you fine-tune anything more? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/6113a5ee/attachment.html>
[Bug 89198] Setting Refresh Rate on monitor causes flickering/artifacting
https://bugs.freedesktop.org/show_bug.cgi?id=89198 --- Comment #20 from andre35822 at yahoo.com --- (In reply to andre35822 from comment #19) > (In reply to Alex Deucher from comment #18) > > (In reply to andre35822 from comment #17) > > > Alright so I tried out the kernel I compiled with the patch from comment > > > 15 > > > on the other bug report, and either I didn't install the patch correctly > > > (or > > > it didnt install correctly) or the patch is not solving the problem. I am > > > still getting the flickering/artifacts. I have attached an xorg log and > > > dmesg log and added comment15_patch to each of their file names so they > > > are > > > easily distinguishable. Should I be compiling another kernel with the > > > patches from comment 19 and 20? > > > > The patch from comment 15 doesn't fix anything. It just adds some > > additional debugging output that might be useful in fine tuning the patches > > in comments 19 and 20. To fix the issue, use the patches in comments 19 and > > 20. > Oh okay thats good then, that means I applied the patch correctly. Shall I > apply the 19 and 20 patches now or would you prefer for a later date incase > you fine-tune anything more? Sorry I misunderstood/forgot what patches 19 and 20 were. I will try them and see if they solve the issue. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/b390b60e/attachment.html>
[Bug 88561] [radeonsi][regression, bisected] Depth test/buffer issues in Portal
https://bugs.freedesktop.org/show_bug.cgi?id=88561 Daniel Scharrer changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=89228 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/7c06a4df/attachment-0001.html>
[Bug 89228] Regression with left for dead 2
https://bugs.freedesktop.org/show_bug.cgi?id=89228 Daniel Scharrer changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=88561 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/3ffc5c06/attachment.html>
[Bug 88561] [radeonsi][regression, bisected] Depth test/buffer issues in Portal
https://bugs.freedesktop.org/show_bug.cgi?id=88561 Daniel Scharrer changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=88978 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/edf63451/attachment.html>
[Bug 88978] [bisected] [SI Scheduler] Graphical corruption in Dota 2
https://bugs.freedesktop.org/show_bug.cgi?id=88978 Daniel Scharrer changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=88561 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/68a9710f/attachment.html>
[Bug 89198] Setting Refresh Rate on monitor causes flickering/artifacting
https://bugs.freedesktop.org/show_bug.cgi?id=89198 --- Comment #21 from andre35822 at yahoo.com --- I am actually having trouble c(In reply to Alex Deucher from comment #18) > (In reply to andre35822 from comment #17) > > Alright so I tried out the kernel I compiled with the patch from comment 15 > > on the other bug report, and either I didn't install the patch correctly (or > > it didnt install correctly) or the patch is not solving the problem. I am > > still getting the flickering/artifacts. I have attached an xorg log and > > dmesg log and added comment15_patch to each of their file names so they are > > easily distinguishable. Should I be compiling another kernel with the > > patches from comment 19 and 20? > > The patch from comment 15 doesn't fix anything. It just adds some > additional debugging output that might be useful in fine tuning the patches > in comments 19 and 20. To fix the issue, use the patches in comments 19 and > 20. Sorry for all of the messages. I am actually having trouble compiling the kernel with patches 19 and 20 and am getting radeon errors. Here is a pastebin of the errors incase you can help me http://pastebin.com/B2rFD9R0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/5d9a6822/attachment.html>
[Bug 62721] GPU lockup: radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec...
https://bugzilla.kernel.org/show_bug.cgi?id=62721 --- Comment #18 from Maciej Gluszek --- UPDATE: Seems i found a solution. So far almost 48h uptime on my laptop and no crash. What i did, is i added "radeon.hard_reset=1" to GRUB command line. GRUB_CMDLINE_LINUX_DEFAULT="quiet splash radeon.dpm=1 radeon.hard_reset=1" -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 89196] Radeon GPU crashes at random times (GPU lockup)
https://bugs.freedesktop.org/show_bug.cgi?id=89196 --- Comment #1 from Maciej Gluszek --- UPDATE: Seems i found a solution. So far almost 48h uptime on my laptop and no crash. What i did, is i added "radeon.hard_reset=1" to GRUB command line. GRUB_CMDLINE_LINUX_DEFAULT="quiet splash radeon.dpm=1 radeon.hard_reset=1" -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/9b736015/attachment-0001.html>
[patch] drm/exynos: IS_ERR() vs NULL bug
of_iomap() doesn't return error pointers, it returns NULL on error.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 63f02e2..9700461 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -888,8 +888,8 @@ static int decon_probe(struct platform_device *pdev)
of_node_put(i80_if_timings);
ctx->regs = of_iomap(dev->of_node, 0);
- if (IS_ERR(ctx->regs)) {
- ret = PTR_ERR(ctx->regs);
+ if (!ctx->regs) {
+ ret = -ENOMEM;
goto err_del_component;
}
[PATCH] drm/tegra: Remove unused .mode_set and .mode_set_base CRTC helpers
The two CRTC helper operations are called only for non-atomic mode
setting, by either the drm_crtc_helper_set_config() helper or the
drm_helper_resume_force_mode() helper. As the driver has switched to
atomic mode setting and neither of those helpers is used, the operations
are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/tegra/dc.c | 2 --
1 file changed, 2 deletions(-)
Hi Thierry,
I stumbled on this while trying to understand the atomic mode setting code
paths. Could you please test the patch ?
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 3aaa84ae2681..4476d6a35a0f 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1327,9 +1327,7 @@ static void tegra_crtc_atomic_flush(struct drm_crtc *crtc)
static const struct drm_crtc_helper_funcs tegra_crtc_helper_funcs = {
.disable = tegra_crtc_disable,
.mode_fixup = tegra_crtc_mode_fixup,
- .mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = tegra_crtc_mode_set_nofb,
- .mode_set_base = drm_helper_crtc_mode_set_base,
.prepare = tegra_crtc_prepare,
.commit = tegra_crtc_commit,
.atomic_check = tegra_crtc_atomic_check,
--
Regards,
Laurent Pinchart
[Bug 90851] radeonsi on pitcairn: nine and skyrim - unable to handle kernel paging request
https://bugzilla.kernel.org/show_bug.cgi?id=90851 Christoph Haag changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #5 from Christoph Haag --- I didn't answer for a while because I didn't have too much time, but also because it hasn't happened anymore. I think it has meanwhile been fixed, wherever the problem was. -- You are receiving this mail because: You are watching the assignee of the bug.
[patch] drm/exynos: IS_ERR() vs NULL bug
Hi Dan,
2015-02-20 Dan Carpenter :
> of_iomap() doesn't return error pointers, it returns NULL on error.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 63f02e2..9700461 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -888,8 +888,8 @@ static int decon_probe(struct platform_device *pdev)
> of_node_put(i80_if_timings);
>
> ctx->regs = of_iomap(dev->of_node, 0);
> - if (IS_ERR(ctx->regs)) {
> - ret = PTR_ERR(ctx->regs);
> + if (!ctx->regs) {
> + ret = -ENOMEM;
> goto err_del_component;
> }
Reviewed-by: Gustavo Padovan
Gustavo
[Bug 89241] A8-6410 APU with integrated R5 Mullins + dedicated R5 M240 Hainan graphics switching not working
https://bugs.freedesktop.org/show_bug.cgi?id=89241 Bug ID: 89241 Summary: A8-6410 APU with integrated R5 Mullins + dedicated R5 M240 Hainan graphics switching not working Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: linux5 at secure-mail.biz Switching graphics between the A8-6410 APU with integrated R5 Mullins + dedicated R5 M240 Hainan is not working(HP 355 G2 notebook). I think it's because the dedicated gpu for some reason can just not be activated, because "/sys/kernel/debug/vgaswitcheroo/switch" and the Radeon Profile tool show two gpus, but changing the gpu state from "off" to something else within Radeon Profile doesn't work for the dedicated one. I tried the gearsongallium livecd with very recent drivers/Xorg/etc. Versions included in the gearsongallium livedvd i tested: Mesa-git â 10.5_git2015.02.04 Kernel â 3.19-rc6 libdrm â 2.4.99_git2015.01.22 Mesa-demos â 9.1.0_git2014.07.06 xorg-server â 1.16.99.9 xf86-video-ati â 7.99.99_2015.01.15 I also tried in Kubuntu 14.10 to switch with DRI_PRIME=1. If i do that i get corrupt window and lower fps than with integrated gpu with es2gears. However "DRI_PRIME=1 glxinfo" says it's using the dedicated gpu. In gearsongallium i get the same output with or without "DRI_PRIME=1 glxinfo" so it seems to not switch at all with recent drivers/Xorg/etc. I can also post Xorg log and dmesg output, but i couldn't spot anything unusual there looking quickly through it. However "dmesg|grep -i vga" might be important: $ dmesg |grep -i vga [1.069056] vgaarb: setting as boot device: PCI::00:01.0 [1.069061] vgaarb: device added: PCI::00:01.0,decodes=io+mem,owns=io+mem,locks=none [1.069077] vgaarb: loaded [1.069080] vgaarb: bridge control possible :00:01.0 [1.763179] fb0: EFI VGA frame buffer device [2.029145] ACPI: Video Device [VGA] (multi-head: yes rom: no post: no) [2.115398] VGA switcheroo: detected switching method \_SB_.PCI0.VGA_.ATPX handle [2.191102] ACPI: Video Device [VGA1] (multi-head: yes rom: no post: no) [2.255714] fb: switching to radeondrmfb from EFI VGA [2.440405] [drm] VGA-1 [2.527423] vga_switcheroo: enabled -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/a4daf981/attachment.html>
[Bug 89196] Radeon GPU crashes at random times (GPU lockup)
https://bugs.freedesktop.org/show_bug.cgi?id=89196 --- Comment #2 from Alex Deucher --- (In reply to Maciej Gluszek from comment #1) > UPDATE: Seems i found a solution. So far almost 48h uptime on my laptop and > no crash. What i did, is i added "radeon.hard_reset=1" to GRUB command line. > > GRUB_CMDLINE_LINUX_DEFAULT="quiet splash radeon.dpm=1 radeon.hard_reset=1" Are you still getting GPU resets in your kernel log? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/e9487dc4/attachment.html>
[Bug 89196] Radeon GPU crashes at random times (GPU lockup)
https://bugs.freedesktop.org/show_bug.cgi?id=89196 --- Comment #3 from Maciej Gluszek --- Created attachment 113685 --> https://bugs.freedesktop.org/attachment.cgi?id=113685&action=edit GPU lockup syslog log - 2015-02-20 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/7e58952c/attachment-0001.html>
[Bug 89196] Radeon GPU crashes at random times (GPU lockup)
https://bugs.freedesktop.org/show_bug.cgi?id=89196 --- Comment #4 from Maciej Gluszek --- Couple of hours after posting an update here i got another lockup, i attached a syslog output with info when it happened. Seems like those lockups will be less likely to happen now, but i would have to see. PS. I checked Google Chrome issues tracker and some people also complained about it being Chrome bug with GPU. I would have to see if i get a lockup without Chrome running or it doesnt matter. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/5c56f2ea/attachment.html>
[PATCH 2/2] drm/msm: Support NV12MT format in mdp4
On Fri, Feb 20, 2015 at 9:42 AM, Beeresh Gopal
wrote:
> Using fb modifier flag, support NV12MT format
> in MDP4
>
> Change-Id: I3de92b0c3b6d0cb56647aed6e4e35e56eff7adab
> Signed-off-by: Beeresh Gopal
> Signed-off-by: Stephane Viau
on small comment below, and one open question at the end, but other
than that it looks good.
oh, and you should drop the Change-Id
> ---
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 9 +
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 ++
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 5 +
> drivers/gpu/drm/msm/msm_drv.c | 2 ++
> drivers/gpu/drm/msm/msm_kms.h | 1 +
> include/uapi/drm/drm_fourcc.h | 14 ++
> 6 files changed, 53 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> index d81e19d..24c38d4 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> @@ -157,6 +157,14 @@ static void mdp4_complete_commit(struct msm_kms *kms,
> struct drm_atomic_state *s
> mdp4_disable(mdp4_kms);
> }
>
> +static void mdp4_set_mode_config(struct msm_kms *kms)
> +{
> + struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(kms));
> + struct drm_device *dev = mdp4_kms->dev;
> +
> + dev->mode_config.allow_fb_modifiers = true;
why not just add this in mdp4_kms_init() or hw_init()? That would
avoid having to add a new vfunc and keep things a bit simpler
> +}
> +
> static long mdp4_round_pixclk(struct msm_kms *kms, unsigned long rate,
> struct drm_encoder *encoder)
> {
> @@ -197,6 +205,7 @@ static const struct mdp_kms_funcs kms_funcs = {
> .complete_commit = mdp4_complete_commit,
> .get_format = mdp_get_format,
> .round_pixclk= mdp4_round_pixclk,
> + .set_mode_config = mdp4_set_mode_config,
> .preclose= mdp4_preclose,
> .destroy = mdp4_destroy,
> },
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> index cde2500..2c2d6a5 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
> @@ -33,6 +33,21 @@ struct mdp4_plane {
> };
> #define to_mdp4_plane(x) container_of(x, struct mdp4_plane, base)
>
> +/* MDP format helper functions */
> +static inline
> +enum mdp4_frame_format mdp4_get_frame_format(struct drm_framebuffer *fb)
> +{
> + bool is_tile = false;
> +
> + if (fb->modifier[1] == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
> + is_tile = true;
> +
> + if (fb->pixel_format == DRM_FORMAT_NV12 && is_tile)
> + return FRAME_TILE_YCBCR_420;
> +
> + return FRAME_LINEAR;
> +}
> +
> static void mdp4_plane_set_scanout(struct drm_plane *plane,
> struct drm_framebuffer *fb);
> static int mdp4_plane_mode_set(struct drm_plane *plane,
> @@ -203,6 +218,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
> uint32_t op_mode = 0;
> uint32_t phasex_step = MDP4_VG_PHASE_STEP_DEFAULT;
> uint32_t phasey_step = MDP4_VG_PHASE_STEP_DEFAULT;
> + enum mdp4_frame_format frame_type = mdp4_get_frame_format(fb);
>
> if (!(crtc && fb)) {
> DBG("%s: disabled!", mdp4_plane->name);
> @@ -302,6 +318,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
>
> MDP4_PIPE_SRC_FORMAT_UNPACK_COUNT(format->unpack_count - 1) |
> MDP4_PIPE_SRC_FORMAT_FETCH_PLANES(format->fetch_type)
> |
>
> MDP4_PIPE_SRC_FORMAT_CHROMA_SAMP(format->chroma_sample) |
> + MDP4_PIPE_SRC_FORMAT_FRAME_FORMAT(frame_type) |
> COND(format->unpack_tight,
> MDP4_PIPE_SRC_FORMAT_UNPACK_TIGHT));
>
> mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRC_UNPACK(pipe),
> @@ -322,6 +339,11 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
> mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEX_STEP(pipe), phasex_step);
> mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEY_STEP(pipe), phasey_step);
>
> + if (frame_type != FRAME_LINEAR)
> + mdp4_write(mdp4_kms, REG_MDP4_PIPE_SSTILE_FRAME_SIZE(pipe),
> + MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH(src_w) |
> + MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT(src_h));
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> index 92b61db..9cb5a5d 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> @@ -80,6 +80,10 @@ static void mdp5_complete_commit(struct msm_kms *kms,
> struct drm_atomic_state *s
> mdp5_disable(mdp5_kms);
> }
>
> +static void mdp5_set_mode_config(struct msm_kms *kms)
> +{
> +}
> +
> static long mdp5_ro
[Bug 85508] spec/ARB_fragment_program/fp-long-alu: Crash in src/gallium/drivers/radeon/radeon_setup_tgsi_llvm.c:1153
https://bugs.freedesktop.org/show_bug.cgi?id=85508 smoki changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from smoki --- Closing this one, test passes now as bug 82477 had it fixed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/c4c6c20f/attachment.html>
r600 - NI/Turks: flickering with 'geom-outlining-150'
Hello Alex, I get _today_ flickering with Mesa-demo 'geom-outlining-150'. It worked OK last night and I've reseted Mesa git back to 5c1aac1 but NO success. Only thing is I've used LLVM git of today, too and for GOOD result LLVM from 18th. Any hints? For the record: 'geom-outlining-150' 'gsraytrace' (both Mesa-demo) and 'gl-320-primitive-shading' (ogl-samples) GS stuff works on r600 - NI/Turks nearly perfect (only the above flickering) which show corruption (first and last) or crash 'gsraytrace' with r600 - RV730 (AGP). Maybe I've to add this on the open bug reports... Great 'experience' with Evergreen+ on PCIE (Xeon X3430/16GB/all SSD/Fujitsu PRIMERGY TX150 S7 server-workstation) ;-) -Dieter PS I use ccache linked to /dev/shm/.ccache for LLVM as Michel suggested.
[Bug 89015] [radeonsi] unvanquished & nexuiz crash after switching AA
https://bugs.freedesktop.org/show_bug.cgi?id=89015 --- Comment #13 from smoki --- modesetting in dri2 mode is fine here :). Probably, but do you use xserver's modesetting driver in dri3 mode? There are whole bunch of piglit crashes and gpu lockups here with anything dri3 related - be it with xserver's modeseting or radeon ddx (i tried this patched radeon https://github.com/iXit/xf86-video-ati/commits/master and it suffer from the same issues like modesetting) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/bfafd8c1/attachment.html>
[GIT PULL]: few dma-buf updates for 3.20-rc1
Hi Linus, Could you please pull a few dma-buf changes for 3.20-rc1? Nothing fancy, minor cleanups. The following changes since commit b942c653ae265abbd31032f3b4f5f857e5c7c723: Merge tag 'trace-sh-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace (2015-01-22 06:26:07 +1200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/dma-buf-for-3.20 for you to fetch changes up to 817bd7253291fc69d83d4340a7e186f3e6933169: dma-buf: cleanup dma_buf_export() to make it easily extensible (2015-02-18 20:16:20 +0530) dma-buf pull request for 3.20 - minor timeout & other cleanups on reservation/fence - cleanup of dma_buf_export() Jammy Zhou (2): reservation: wait only with non-zero timeout specified (v3) dma-buf/fence: don't wait when specified timeout is zero Michel Dänzer (1): reservation: Remove shadowing local variable 'ret' Sumit Semwal (1): dma-buf: cleanup dma_buf_export() to make it easily extensible Documentation/dma-buf-sharing.txt | 23 +++-- drivers/dma-buf/dma-buf.c | 47 -- drivers/dma-buf/fence.c| 3 ++ drivers/dma-buf/reservation.c | 5 +-- drivers/gpu/drm/armada/armada_gem.c| 10 -- drivers/gpu/drm/drm_prime.c| 12 --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 9 +++-- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 -- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 9 - drivers/gpu/drm/tegra/gem.c| 10 -- drivers/gpu/drm/ttm/ttm_object.c | 9 +++-- drivers/gpu/drm/udl/udl_dmabuf.c | 9 - drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 - drivers/media/v4l2-core/videobuf2-dma-sg.c | 8 - drivers/media/v4l2-core/videobuf2-vmalloc.c| 8 - drivers/staging/android/ion/ion.c | 9 +++-- include/linux/dma-buf.h| 34 +++ 17 files changed, 158 insertions(+), 65 deletions(-) Thanks, and best regards, Sumit.
r600 - NI/Turks: flickering with 'geom-outlining-150'
On Fri, Feb 20, 2015 at 10:54 AM, Dieter Nützel wrote: > Hello Alex, > > I get _today_ flickering with Mesa-demo 'geom-outlining-150'. > It worked OK last night and I've reseted Mesa git back to 5c1aac1 but NO > success. > Only thing is I've used LLVM git of today, too and for GOOD result LLVM > from 18th. > Any hints? > Please narrow it down to what update caused the issue and then use git to bisect. Alex > For the record: > > 'geom-outlining-150' > 'gsraytrace' (both Mesa-demo) > and > 'gl-320-primitive-shading' (ogl-samples) > > GS stuff works on r600 - NI/Turks nearly perfect (only the above flickering) > which show corruption (first and last) or crash 'gsraytrace' with r600 - > RV730 (AGP). > > Maybe I've to add this on the open bug reports... > > Great 'experience' with Evergreen+ on PCIE (Xeon X3430/16GB/all SSD/Fujitsu > PRIMERGY TX150 S7 server-workstation) ;-) > > -Dieter > > PS I use ccache linked to /dev/shm/.ccache for LLVM as Michel suggested.
[PATCH] drm/radeon: fix atom aux payload size check for writes
The atom aux param interface only supports 4 bits for
the total write transfer size (header + payload). This
limits us to 12 bytes of payload rather than 16. Add a
check for this. Reads are not affected.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_dp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index 5bf825d..c57706e6 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -178,6 +178,13 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct
drm_dp_aux_msg *msg)
switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
+ /* The atom implementation only supports writes with a max
payload of
+* 12 bytes since it uses 4 bits for the total count (header +
payload)
+* in the parameter space. The atom interface supports 16 byte
+* payloads for reads. The hw itself supports up to 16 bytes of
payload.
+*/
+ if (WARN_ON(msg->size > 12))
+ return -E2BIG;
/* tx_size needs to be 4 even for bare address packets since
the atom
* table needs the info in tx_buf[3].
*/
--
1.8.3.1
[Bug 88717] [r300g] r300compiler error: Failed to translate rgb instruction - while running a game with gallium-nine
https://bugs.freedesktop.org/show_bug.cgi?id=88717 --- Comment #10 from Fabio Pedretti --- Tom, any news on this? Thanks! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/8145638c/attachment.html>
VM on GPUs
Hello radeon devs, I have been trying to find out more about VM implementation on SI+ hw, but unfortunately I could not find much in the public documents[0]. SI ISA manual suggests that there is a limited form of privileged mode on these chips, so I wondered if it could be used for VM management too (the docs only deal with numerical exceptions). Or does it always have to be handled by host (driver)? One of the older patches [1] mentions different page sizes, is there any public documentation on things like page table format, and GPU MMU hierarchy? I could only get limited picture going through the code and comments. thank you, Jan [0]http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/ [1]http://lists.freedesktop.org/archives/dri-devel/2014-May/058858.html -- Jan Vesely -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/ad8fe694/attachment.sig>
[RFC PATCH] drm/radeon: program auxch directly
WREG32(DPREG(DP_AUX_SW_INTERRUPT_CONTROL), DP_AUX_SW_DONE_ACK);
>> +
>> + /* write the size and GO bits */
>> + WREG32(DPREG(DP_AUX_SW_CONTROL),
>> + DP_AUX_SW_WR_BYTES(bytes) | DP_AUX_SW_GO);
>> +
>> + /* poll the status registers - TODO irq support */
>> + do {
>> + tmp = RREG32(DPREG(DP_AUX_SW_STATUS));
>> + if (tmp & DP_AUX_SW_DONE) {
>> + break;
>> + }
>> + usleep_range(100, 200);
>> + } while (retry_count++ < 1000);
>> +
>> + if (retry_count >= 1000) {
>> + DRM_ERROR("auxch hw never signalled completion, error
>> %08x\n", tmp);
>> + ret = -EIO;
>> + goto done;
>> + }
>> +
>> + if (tmp & DP_AUX_SW_RX_TIMEOUT) {
>> + DRM_DEBUG_KMS("dp_aux_ch timed out\n");
>> + ret = -ETIMEDOUT;
>> + goto done;
>> + }
>> + if (tmp & DP_AUX_RX_ERROR_FLAGS) {
>> + DRM_DEBUG_KMS("dp_aux_ch flags not zero: %08x\n", tmp);
>> + ret = -EIO;
>> + goto done;
>> + }
>> +
>> + bytes = DP_AUX_SW_REPLY_GET_BYTE_COUNT(tmp);
>> + if (bytes) {
>> + WREG32(DPREG(DP_AUX_SW_DATA),
>> + DP_AUX_SW_DATA_RW | DP_AUX_SW_AUTOINCREMENT_DISABLE);
>> +
>> + tmp = RREG32(DPREG(DP_AUX_SW_DATA));
>> + ack = (tmp >> 8) & 0xff;
>> +
>> + for (i = 0; i < bytes - 1; i++) {
>> + tmp = RREG32(DPREG(DP_AUX_SW_DATA));
>> + if (buf)
>> + buf[i] = (tmp >> 8) & 0xff;
>> + }
>> + if (buf)
>> + ret = bytes - 1;
>> + }
>> +
>> + WREG32(DPREG(DP_AUX_SW_INTERRUPT_CONTROL), DP_AUX_SW_DONE_ACK);
>> +
>> + if (is_write)
>> + ret = msg->size;
>> +done:
>> + mutex_unlock(&chan->mutex);
>> +
>> + if (ret >= 0)
>> + msg->reply = ack >> 4;
>> + return ret;
>> +}
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index 5d684be..0141ce3 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -190,6 +190,7 @@ int radeon_deep_color = 0;
>> int radeon_use_pflipirq = 2;
>> int radeon_bapm = -1;
>> int radeon_backlight = -1;
>> +int radeon_auxch = 0;
>>
>> MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch registers");
>> module_param_named(no_wb, radeon_no_wb, int, 0444);
>> @@ -275,6 +276,9 @@ module_param_named(bapm, radeon_bapm, int, 0444);
>> MODULE_PARM_DESC(backlight, "backlight support (1 = enable, 0 = disable, -1
>> = auto)");
>> module_param_named(backlight, radeon_backlight, int, 0444);
>>
>> +MODULE_PARM_DESC(auxch, "Use native auxch experimental support (1 = enable,
>> 0 = disable)");
>> +module_param_named(auxch, radeon_auxch, int, 0444);
>> +
>> static struct pci_device_id pciidlist[] = {
>> radeon_PCI_IDS
>> };
>> --
>> 2.1.0
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-program-auxch-directly-v2.patch
Type: text/x-diff
Size: 13804 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/9b39e4f8/attachment-0001.patch>
[PATCH] drm/msm/mdp5: fixup "drm/msm: fix fallout of atomic dpms changes"
Commit 0b776d457b94 ("drm/msm: fix fallout of atomic dpms
changes") has a typo in both mdp5_encoder_helper_funcs and
mdp5_crtc_helper_funcs definitions:
.dpms entry should be replaced by .disable and .enable
Also fixed a typo in mdp5_encoder_enable().
Note that these typos are only present for MDP5. MDP4 is fine.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c| 4 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 46fac54..946b71b 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -544,8 +544,8 @@ static const struct drm_crtc_funcs mdp5_crtc_funcs = {
static const struct drm_crtc_helper_funcs mdp5_crtc_helper_funcs = {
.mode_fixup = mdp5_crtc_mode_fixup,
.mode_set_nofb = mdp5_crtc_mode_set_nofb,
- .prepare = mdp5_crtc_disable,
- .commit = mdp5_crtc_enable,
+ .disable = mdp5_crtc_disable,
+ .enable = mdp5_crtc_enable,
.atomic_check = mdp5_crtc_atomic_check,
.atomic_begin = mdp5_crtc_atomic_begin,
.atomic_flush = mdp5_crtc_atomic_flush,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
index 549d9a8..a09fa58 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
@@ -267,14 +267,14 @@ static void mdp5_encoder_enable(struct drm_encoder
*encoder)
mdp5_write(mdp5_kms, REG_MDP5_INTF_TIMING_ENGINE_EN(intf), 1);
spin_unlock_irqrestore(&mdp5_encoder->intf_lock, flags);
- mdp5_encoder->enabled = false;
+ mdp5_encoder->enabled = true;
}
static const struct drm_encoder_helper_funcs mdp5_encoder_helper_funcs = {
.mode_fixup = mdp5_encoder_mode_fixup,
.mode_set = mdp5_encoder_mode_set,
- .prepare = mdp5_encoder_disable,
- .commit = mdp5_encoder_enable,
+ .disable = mdp5_encoder_disable,
+ .enable = mdp5_encoder_enable,
};
/* initialize encoder */
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
[PATCH RFC v9 01/20] clk: divider: Correct parent clk round rate if no bestdiv is normally found
On Fri, Feb 20, 2015 at 11:13:06AM -0800, Mike Turquette wrote: > Quoting Russell King - ARM Linux (2015-02-16 03:27:24) > > On Fri, Feb 13, 2015 at 07:57:13PM +0100, Sascha Hauer wrote: > > > I agree that it's a bit odd, but I think it has to be like this. > > > Consider that you request a rate of 100Hz, but the clock can only > > > produce 99.5Hz, so due to rounding clk_round_rate() returns 99Hz. > > > Now when you request 99Hz from clk_set_rate() the 99.5Hz value > > > can't be used because it's too high. > > > > Math rounding rules normally state that anything of .5 and greater > > should be rounded up, not rounded down. So, for 99.5Hz, you really > > ought to be returning 100Hz, not 99Hz. > > > > However, you do have a point for 99.4Hz, which would be returned as > > 99Hz, and when set, it would result in something which isn't 99.4Hz. > > More practically, this again raises the issue of whether or not unsigned > long rate should be in millihertz or something other than hertz. You still get the same issue if it's millihertz. Take 10 2/3rds Hz. Is 10.666 Hz less than 10 2/3rds Hz? -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
[Bug 86720] [radeon] Europa Universalis 4 freezing during game start (10.3.3)
https://bugs.freedesktop.org/show_bug.cgi?id=86720 --- Comment #18 from Felix Schwarz --- I created an API trace which reproduces the problem for me (https://dl.dropboxusercontent.com/s/hc6v7gdcshj4ljd/eu4.trace-lockup.xz?dl=0 , 120 MB, unfortunately trimming produces only invalid states). The shaders itself don't look to bad to me but I don't have any experience deducing a miminal testcase from an apitrace (pointers welcome). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/c9c8791c/attachment.html>
[Bug 86720] [radeon] Europa Universalis 4 freezing during game start (10.3.3)
https://bugs.freedesktop.org/show_bug.cgi?id=86720 Marek Olšák changed: What|Removed |Added CC|maraeo at gmail.com| --- Comment #19 from Marek Olšák --- (removing myself from the Cc list, already getting emails from dri-devel) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/89e65eed/attachment.html>
[PATCH] drm/atomic: Rename drm_atomic_helper_commit_pre_planes() state argument
The argument contains a pointer to the old state, rename it to old_state
like in all other commit helper functions.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_atomic_helper.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 7e3a52b97c7d..6c5bfa2bd18a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -770,18 +770,18 @@ crtc_set_mode(struct drm_device *dev, struct
drm_atomic_state *old_state)
/**
* drm_atomic_helper_commit_pre_planes - modeset commit before plane updates
* @dev: DRM device
- * @state: atomic state
+ * @old_state: atomic state object with old state structures
*
* This function commits the modeset changes that need to be committed before
* updating planes. It shuts down all the outputs that need to be shut down and
* prepares them (if required) with the new mode.
*/
void drm_atomic_helper_commit_pre_planes(struct drm_device *dev,
-struct drm_atomic_state *state)
+struct drm_atomic_state *old_state)
{
- disable_outputs(dev, state);
- set_routing_links(dev, state);
- crtc_set_mode(dev, state);
+ disable_outputs(dev, old_state);
+ set_routing_links(dev, old_state);
+ crtc_set_mode(dev, old_state);
}
EXPORT_SYMBOL(drm_atomic_helper_commit_pre_planes);
--
Regards,
Laurent Pinchart
[PATCH 0/2] drm/msm/mdp5: A couple of fixes
The 4th CRTC could not be accessed because of a missing case entry. Also, only flush registers when a CRTC is enabled (and thus a CTL is allocated). This shall fix the cursor move issue that Rob mentioned. Stephane Viau (2): drm/msm: update generated headers (add 6th lm.base entry) drm/msm/mdp5: Avoid flushing registers when CRTC is disabled drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 15 --- drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 26 +++--- 2 files changed, 23 insertions(+), 18 deletions(-) -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 1/2] drm/msm: update generated headers (add 6th lm.base entry)
Some target have up to 6 layer mixers (LM). Let the header file access the last LM's base address. Signed-off-by: Stephane Viau --- drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 15 --- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h index 09b4a25..c276624 100644 --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h @@ -8,17 +8,9 @@ http://github.com/freedreno/envytools/ git clone https://github.com/freedreno/envytools.git The rules-ng-ng source files this header was generated from are: -- /home/robclark/src/freedreno/envytools/rnndb/msm.xml ( 676 bytes, from 2014-12-05 15:34:49) -- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml ( 1453 bytes, from 2013-03-31 16:51:27) -- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp4.xml( 20908 bytes, from 2014-12-08 16:13:00) -- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp_common.xml ( 2357 bytes, from 2014-12-08 16:13:00) -- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp5.xml( 27208 bytes, from 2015-01-13 23:56:11) -- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml ( 11712 bytes, from 2013-08-17 17:13:43) -- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml( 344 bytes, from 2013-08-11 19:26:32) -- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml ( 1686 bytes, from 2014-10-31 16:48:57) -- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml ( 600 bytes, from 2013-07-05 19:21:12) -- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml ( 26848 bytes, from 2015-01-13 23:55:57) -- /home/robclark/src/freedreno/envytools/rnndb/edp/edp.xml ( 8253 bytes, from 2014-12-08 16:13:00) +- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp5.xml( 27229 bytes, from 2015-02-10 17:00:41) +- /local/mnt2/workspace2/sviau/envytools/rnndb/freedreno_copyright.xml ( 1453 bytes, from 2014-06-02 18:31:15) +- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp_common.xml ( 2357 bytes, from 2015-01-23 16:20:19) Copyright (C) 2013-2015 by the following authors: - Rob Clark (robclark) @@ -910,6 +902,7 @@ static inline uint32_t __offset_LM(uint32_t idx) case 2: return (mdp5_cfg->lm.base[2]); case 3: return (mdp5_cfg->lm.base[3]); case 4: return (mdp5_cfg->lm.base[4]); + case 5: return (mdp5_cfg->lm.base[5]); default: return INVALID_IDX(idx); } } -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 2/2] drm/msm/mdp5: Avoid flushing registers when CRTC is disabled
When a CRTC is disabled, no CTL is allocated to it (CRTC->ctl == NULL);
in that case we should not try to FLUSH registers and do nothing instead.
This can happen when we try to move a cursor but the CRTC's CTL
(CONTROL) has not been allocated yet (inactive CRTC).
It can also happens when we .atomic_check()/.atomic_flush() on a
disabled CRTC.
A CTL needs to be kept as long as the CRTC is alive. Releasing it
after the last VBlank is safer than in .atomic_flush().
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 946b71b..2aeae73 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -103,8 +103,8 @@ static void crtc_flush_all(struct drm_crtc *crtc)
struct drm_plane *plane;
uint32_t flush_mask = 0;
- /* we could have already released CTL in the disable path: */
- if (!mdp5_crtc->ctl)
+ /* this should not happen: */
+ if (WARN_ON(!mdp5_crtc->ctl))
return;
drm_atomic_crtc_for_each_plane(plane, crtc) {
@@ -143,6 +143,11 @@ static void complete_flip(struct drm_crtc *crtc, struct
drm_file *file)
drm_atomic_crtc_for_each_plane(plane, crtc) {
mdp5_plane_complete_flip(plane);
}
+
+ if (mdp5_crtc->ctl && !crtc->state->enable) {
+ mdp5_ctl_release(mdp5_crtc->ctl);
+ mdp5_crtc->ctl = NULL;
+ }
}
static void unref_cursor_worker(struct drm_flip_work *work, void *val)
@@ -386,14 +391,17 @@ static void mdp5_crtc_atomic_flush(struct drm_crtc *crtc)
mdp5_crtc->event = crtc->state->event;
spin_unlock_irqrestore(&dev->event_lock, flags);
+ /*
+* If no CTL has been allocated in mdp5_crtc_atomic_check(),
+* it means we are trying to flush a CRTC whose state is disabled:
+* nothing else needs to be done.
+*/
+ if (unlikely(!mdp5_crtc->ctl))
+ return;
+
blend_setup(crtc);
crtc_flush_all(crtc);
request_pending(crtc, PENDING_FLIP);
-
- if (mdp5_crtc->ctl && !crtc->state->enable) {
- mdp5_ctl_release(mdp5_crtc->ctl);
- mdp5_crtc->ctl = NULL;
- }
}
static int mdp5_crtc_set_property(struct drm_crtc *crtc,
@@ -495,6 +503,10 @@ static int mdp5_crtc_cursor_move(struct drm_crtc *crtc,
int x, int y)
uint32_t roi_h;
unsigned long flags;
+ /* In case the CRTC is disabled, just drop the cursor update */
+ if (unlikely(!crtc->state->enable))
+ return 0;
+
x = (x > 0) ? x : 0;
y = (y > 0) ? y : 0;
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project
[PATCH] rnndb: Add a 6th lm.base entry
Some target have up to 6 layer mixers (LM). Let the xml file access the last LM's base address. Signed-off-by: Stephane Viau --- rnndb/mdp/mdp5.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rnndb/mdp/mdp5.xml b/rnndb/mdp/mdp5.xml index cd3bf37..eaaec47 100644 --- a/rnndb/mdp/mdp5.xml +++ b/rnndb/mdp/mdp5.xml @@ -380,7 +380,7 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ rules-ng.xsd"> - + -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
VM on GPUs
On Fri, Feb 20, 2015 at 12:35 PM, Jan Vesely wrote: > Hello radeon devs, > > I have been trying to find out more about VM implementation on SI+ hw, > but unfortunately I could not find much in the public documents[0]. > > SI ISA manual suggests that there is a limited form of privileged mode > on these chips, so I wondered if it could be used for VM management too > (the docs only deal with numerical exceptions). Or does it always have > to be handled by host (driver)? These are related to trap/exception privilege for debugging for example. I'm not that familiar with how that stuff works. It's unrelated to GPUVM. > > One of the older patches [1] mentions different page sizes, is there any > public documentation on things like page table format, and GPU MMU > hierarchy? I could only get limited picture going through the code and > comments. There is not any public documentation on the VM hardware other than what is available in the driver. I can try and give you an overview of how it works. There are 16 VM contexts (8 on cayman/TN/RL) on the GPU that can be active at any given time. GPUVM supports a 40 bit address space. Each context has an id, we call them vmids. vmid 0 is a bit special. It's called the system context and behaves a bit differently to the other ones. It's designed to be for the kernel driver's view of GPU accessible memory. I can go into further detail if you want, but I don't think it's critical for this discussion. Just think of it as the context used by the kernel driver. So that leaves 16 contexts (7 on cayman and TN/RL) available for use by user clients. vmid 0 has one set of configuration registers and vmids 1-15 share the same configuration (other than the page tables). E.g., contexts 1-15 all have to use single or 2 level page tables for example. You select which VM context is used for a particular command buffer by a field in the command buffer packet. Some engines (e.g., UVD or the display hardware) do not support VM so they always use vmid 0. Right now only the graphics, compute, and DMA engines support VM. With single level page tables, you just have a big array of page table entries (PTEs) that represent the entire virtual address space. With multi-level page tables, the address space is represented by an array of page directory entries (PDEs) that point to page table blocks (PTBs) which are arrays of PTEs. PTEs and PDEs are 64 bits per entry. PDE: 39:12 - PTB address 0 - PDE valid (the entry is valid) PTE: 39:12 - page address 11:7 - fragment 6 - write 5 - read 2 - CPU cache snoop (for accessing cached system memory) 1 - system (page is in system memory rather than vram) 0 - PTE valid (the entry is valid) Fragment needs some explanation. The logical/physical fragment size in bytes = 2 ^ (12 + fragment). A fragment size of 0 means 4k, 1 means, 8k, etc. The logical address must be aligned to the fragment size and the memory backing it must be contiguous and at least as large as the fragment size. Larger fragment sizes reduce the pressure on the TLB since fewer entries are required for the same amount of memory. For system pages, the page address is the dma address of the page. The system bit must be set and the snoop bit can be optionally set depending on whether you are using cachable memory. For vram pages, the address is the GPU physical address of vram (starts at 0 on dGPUs, starts at MC_VM_FB_OFFSET (dma address of "vram" carve out) on APUs). You can also adjust the page table block size which controls the number of pages per PTB. I.e., how many PDEs you need to cover the address space. E.g., if you set the block size to 0, each PTB is 4k which holds 512 PTEs; if you set it to 1 each PTB is 8k which holds 1024 PTEs, etc. GPUVM is only concerned with memory management and protection. There are other protection features in other hw blocks for things beyond memory. For example, on CI and newer asics, the CP and SDMA blocks execute command buffers in a secure mode that limits them to accessing only registers that are relevant for those blocks (e.g., gfx or compute state registers, but not display registers) or only executing certain packets. I hope this helps. Let me know if you have any more questions. Alex > > > thank you, > Jan > > [0]http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/ > [1]http://lists.freedesktop.org/archives/dri-devel/2014-May/058858.html > > > -- > Jan Vesely
VM on GPUs
> GPUVM is only concerned with memory management and protection. There > are other protection features in other hw blocks for things beyond > memory. For example, on CI and newer asics, the CP and SDMA blocks > execute command buffers in a secure mode that limits them to accessing > only registers that are relevant for those blocks (e.g., gfx or > compute state registers, but not display registers) or only executing > certain packets. > > I hope this helps. Let me know if you have any more questions. > > Alex > > > > > > > thank you, > > Jan > > > > [0]http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/ > > [1]http://lists.freedesktop.org/archives/dri-devel/2014-May/058858.html > > > > > > -- > > Jan Vesely -- Jan Vesely -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150220/3dbff250/attachment.sig>
[PATCH 1/2] drm/msm: update generated headers
To avoid ambiguity rename FRAME_SIZE to
SSTILE_FRAME_SIZE
Change-Id: I2c1c763cec31acb6c860220c41a8b33bfad430a3
Signed-off-by: Beeresh Gopal
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h | 36 +
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
index 1d39174..2d0029d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
@@ -8,19 +8,11 @@ http://github.com/freedreno/envytools/
git clone https://github.com/freedreno/envytools.git
The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/freedreno/envytools/rnndb/msm.xml (
676 bytes, from 2014-12-05 15:34:49)
-- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml (
1453 bytes, from 2013-03-31 16:51:27)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp4.xml(
20908 bytes, from 2014-12-08 16:13:00)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp_common.xml (
2357 bytes, from 2014-12-08 16:13:00)
-- /home/robclark/src/freedreno/envytools/rnndb/mdp/mdp5.xml(
27208 bytes, from 2015-01-13 23:56:11)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml (
11712 bytes, from 2013-08-17 17:13:43)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml(
344 bytes, from 2013-08-11 19:26:32)
-- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml (
1686 bytes, from 2014-10-31 16:48:57)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml (
600 bytes, from 2013-07-05 19:21:12)
-- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml (
26848 bytes, from 2015-01-13 23:55:57)
-- /home/robclark/src/freedreno/envytools/rnndb/edp/edp.xml (
8253 bytes, from 2014-12-08 16:13:00)
-
-Copyright (C) 2013-2014 by the following authors:
+- /local/mnt/workspace/sandbox/envytools/rnndb/mdp/mdp4.xml(
20915 bytes, from 2015-02-06 15:25:51)
+- /local/mnt/workspace/sandbox/envytools/rnndb/freedreno_copyright.xml (
1453 bytes, from 2015-02-06 15:25:09)
+- /local/mnt/workspace/sandbox/envytools/rnndb/mdp/mdp_common.xml (
2357 bytes, from 2015-02-06 15:25:09)
+
+Copyright (C) 2013-2015 by the following authors:
- Rob Clark (robclark)
Permission is hereby granted, free of charge, to any person obtaining
@@ -680,18 +672,18 @@ static inline uint32_t MDP4_PIPE_SRC_STRIDE_B_P3(uint32_t
val)
return ((val) << MDP4_PIPE_SRC_STRIDE_B_P3__SHIFT) &
MDP4_PIPE_SRC_STRIDE_B_P3__MASK;
}
-static inline uint32_t REG_MDP4_PIPE_FRAME_SIZE(enum mdp4_pipe i0) { return
0x00020048 + 0x1*i0; }
-#define MDP4_PIPE_FRAME_SIZE_HEIGHT__MASK 0x
-#define MDP4_PIPE_FRAME_SIZE_HEIGHT__SHIFT 16
-static inline uint32_t MDP4_PIPE_FRAME_SIZE_HEIGHT(uint32_t val)
+static inline uint32_t REG_MDP4_PIPE_SSTILE_FRAME_SIZE(enum mdp4_pipe i0) {
return 0x00020048 + 0x1*i0; }
+#define MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT__MASK 0x
+#define MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT__SHIFT 16
+static inline uint32_t MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT(uint32_t val)
{
- return ((val) << MDP4_PIPE_FRAME_SIZE_HEIGHT__SHIFT) &
MDP4_PIPE_FRAME_SIZE_HEIGHT__MASK;
+ return ((val) << MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT__SHIFT) &
MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT__MASK;
}
-#define MDP4_PIPE_FRAME_SIZE_WIDTH__MASK 0x
-#define MDP4_PIPE_FRAME_SIZE_WIDTH__SHIFT 0
-static inline uint32_t MDP4_PIPE_FRAME_SIZE_WIDTH(uint32_t val)
+#define MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH__MASK
0x
+#define MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH__SHIFT 0
+static inline uint32_t MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH(uint32_t val)
{
- return ((val) << MDP4_PIPE_FRAME_SIZE_WIDTH__SHIFT) &
MDP4_PIPE_FRAME_SIZE_WIDTH__MASK;
+ return ((val) << MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH__SHIFT) &
MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH__MASK;
}
static inline uint32_t REG_MDP4_PIPE_SRC_FORMAT(enum mdp4_pipe i0) { return
0x00020050 + 0x1*i0; }
--
1.8.2.1
[PATCH 2/2] drm/msm: Support NV12MT format in mdp4
Using fb modifier flag, support NV12MT format
in MDP4
Change-Id: I3de92b0c3b6d0cb56647aed6e4e35e56eff7adab
Signed-off-by: Beeresh Gopal
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 9 +
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 ++
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 5 +
drivers/gpu/drm/msm/msm_drv.c | 2 ++
drivers/gpu/drm/msm/msm_kms.h | 1 +
include/uapi/drm/drm_fourcc.h | 14 ++
6 files changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index d81e19d..24c38d4 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -157,6 +157,14 @@ static void mdp4_complete_commit(struct msm_kms *kms,
struct drm_atomic_state *s
mdp4_disable(mdp4_kms);
}
+static void mdp4_set_mode_config(struct msm_kms *kms)
+{
+ struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(kms));
+ struct drm_device *dev = mdp4_kms->dev;
+
+ dev->mode_config.allow_fb_modifiers = true;
+}
+
static long mdp4_round_pixclk(struct msm_kms *kms, unsigned long rate,
struct drm_encoder *encoder)
{
@@ -197,6 +205,7 @@ static const struct mdp_kms_funcs kms_funcs = {
.complete_commit = mdp4_complete_commit,
.get_format = mdp_get_format,
.round_pixclk= mdp4_round_pixclk,
+ .set_mode_config = mdp4_set_mode_config,
.preclose= mdp4_preclose,
.destroy = mdp4_destroy,
},
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
index cde2500..2c2d6a5 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
@@ -33,6 +33,21 @@ struct mdp4_plane {
};
#define to_mdp4_plane(x) container_of(x, struct mdp4_plane, base)
+/* MDP format helper functions */
+static inline
+enum mdp4_frame_format mdp4_get_frame_format(struct drm_framebuffer *fb)
+{
+ bool is_tile = false;
+
+ if (fb->modifier[1] == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
+ is_tile = true;
+
+ if (fb->pixel_format == DRM_FORMAT_NV12 && is_tile)
+ return FRAME_TILE_YCBCR_420;
+
+ return FRAME_LINEAR;
+}
+
static void mdp4_plane_set_scanout(struct drm_plane *plane,
struct drm_framebuffer *fb);
static int mdp4_plane_mode_set(struct drm_plane *plane,
@@ -203,6 +218,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
uint32_t op_mode = 0;
uint32_t phasex_step = MDP4_VG_PHASE_STEP_DEFAULT;
uint32_t phasey_step = MDP4_VG_PHASE_STEP_DEFAULT;
+ enum mdp4_frame_format frame_type = mdp4_get_frame_format(fb);
if (!(crtc && fb)) {
DBG("%s: disabled!", mdp4_plane->name);
@@ -302,6 +318,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
MDP4_PIPE_SRC_FORMAT_UNPACK_COUNT(format->unpack_count
- 1) |
MDP4_PIPE_SRC_FORMAT_FETCH_PLANES(format->fetch_type) |
MDP4_PIPE_SRC_FORMAT_CHROMA_SAMP(format->chroma_sample)
|
+ MDP4_PIPE_SRC_FORMAT_FRAME_FORMAT(frame_type) |
COND(format->unpack_tight,
MDP4_PIPE_SRC_FORMAT_UNPACK_TIGHT));
mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRC_UNPACK(pipe),
@@ -322,6 +339,11 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEX_STEP(pipe), phasex_step);
mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEY_STEP(pipe), phasey_step);
+ if (frame_type != FRAME_LINEAR)
+ mdp4_write(mdp4_kms, REG_MDP4_PIPE_SSTILE_FRAME_SIZE(pipe),
+ MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH(src_w) |
+ MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT(src_h));
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 92b61db..9cb5a5d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -80,6 +80,10 @@ static void mdp5_complete_commit(struct msm_kms *kms, struct
drm_atomic_state *s
mdp5_disable(mdp5_kms);
}
+static void mdp5_set_mode_config(struct msm_kms *kms)
+{
+}
+
static long mdp5_round_pixclk(struct msm_kms *kms, unsigned long rate,
struct drm_encoder *encoder)
{
@@ -131,6 +135,7 @@ static const struct mdp_kms_funcs kms_funcs = {
.complete_commit = mdp5_complete_commit,
.get_format = mdp_get_format,
.round_pixclk= mdp5_round_pixclk,
+ .set_mode_config = mdp5_set_mode_config,
.preclose= mdp5_preclose,
.destroy = mdp5_destroy,
},
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/
[PATCH RFC v9 01/20] clk: divider: Correct parent clk round rate if no bestdiv is normally found
Quoting Russell King - ARM Linux (2015-02-16 03:27:24) > On Fri, Feb 13, 2015 at 07:57:13PM +0100, Sascha Hauer wrote: > > I agree that it's a bit odd, but I think it has to be like this. > > Consider that you request a rate of 100Hz, but the clock can only > > produce 99.5Hz, so due to rounding clk_round_rate() returns 99Hz. > > Now when you request 99Hz from clk_set_rate() the 99.5Hz value > > can't be used because it's too high. > > Math rounding rules normally state that anything of .5 and greater > should be rounded up, not rounded down. So, for 99.5Hz, you really > ought to be returning 100Hz, not 99Hz. > > However, you do have a point for 99.4Hz, which would be returned as > 99Hz, and when set, it would result in something which isn't 99.4Hz. More practically, this again raises the issue of whether or not unsigned long rate should be in millihertz or something other than hertz. And then that question again raises the issue of making rate 64-bit... Regards, Mike > > -- > FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up > according to speedtest.net.
[PATCH RFC v9 01/20] clk: divider: Correct parent clk round rate if no bestdiv is normally found
Quoting Russell King - ARM Linux (2015-02-20 11:20:43) > On Fri, Feb 20, 2015 at 11:13:06AM -0800, Mike Turquette wrote: > > Quoting Russell King - ARM Linux (2015-02-16 03:27:24) > > > On Fri, Feb 13, 2015 at 07:57:13PM +0100, Sascha Hauer wrote: > > > > I agree that it's a bit odd, but I think it has to be like this. > > > > Consider that you request a rate of 100Hz, but the clock can only > > > > produce 99.5Hz, so due to rounding clk_round_rate() returns 99Hz. > > > > Now when you request 99Hz from clk_set_rate() the 99.5Hz value > > > > can't be used because it's too high. > > > > > > Math rounding rules normally state that anything of .5 and greater > > > should be rounded up, not rounded down. So, for 99.5Hz, you really > > > ought to be returning 100Hz, not 99Hz. > > > > > > However, you do have a point for 99.4Hz, which would be returned as > > > 99Hz, and when set, it would result in something which isn't 99.4Hz. > > > > More practically, this again raises the issue of whether or not unsigned > > long rate should be in millihertz or something other than hertz. > > You still get the same issue if it's millihertz. Take 10 2/3rds Hz. > Is 10.666 Hz less than 10 2/3rds Hz? Millihertz won't solve rounding problems, I agree. But we currently do not support any fractional rates and we should. Regards, Mike > > -- > FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up > according to speedtest.net.
