[Bug 97137] R7 M370 hangs with radeon.dpm=1 when running demanding graphical programs with DRI PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=97137 --- Comment #5 from Mauro Santos --- Created attachment 125429 --> https://bugs.freedesktop.org/attachment.cgi?id=125429&action=edit dmesg with radeon.runpm=0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/615a8099/attachment.html>
[Bug 97137] R7 M370 hangs with radeon.dpm=1 when running demanding graphical programs with DRI PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=97137 --- Comment #4 from Mauro Santos --- (In reply to Alex Deucher from comment #3) > Does setting radeon.runpm=0 on the kernel command line in grub help? No change. When running glmark2 I still get a hang when it gets to the texture test. I see the cube spin for maybe less than one second and then the test/gpu hangs. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/5b136edf/attachment.html>
[Bug 91281] Tonga VCE 2160p encode fails with BO to small for addr
https://bugs.freedesktop.org/show_bug.cgi?id=91281 --- Comment #1 from Andy Furniss --- Now that vaapi is enabled the situation with this is more mixed. omx still just always fails. ffmpeg vaapi always works. gatreamer vaapi fails or works depending on framerate, which is a bit confusing. For 2160p as long as I say framerate <=30 it works. For 4096x2160 it has to be <=26. Adding size to the kernel error message shows that the failing size = 2x raw framesize - [drm:amdgpu_vce_cs_reloc [amdgpu]] *ERROR* BO to small for addr 0x0108fde000 14 13 24883200 Adding debugging to vlVaCreateBuffer doesn't show any difference between working and failing cases - the size requested being one raw frame. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/51fd4cf2/attachment.html>
[Bug 150731] amdgpu: segfault on unbind in sysfs; card becomes nonresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=150731 --- Comment #2 from Jimi --- Another clarification: the behavior is the same if I don't bind the card to amdgpu myself and let it be bound to amdgpu on boot, automatically, which is how I usually test it. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 150731] amdgpu: segfault on unbind in sysfs; card becomes nonresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=150731 --- Comment #1 from Jimi --- Clarification: If I bind the card to amdgpu, X doesn't crash when I actually bind it to amdgpu. I never actually get to bind it to amdgpu. X crashes when I rescan PCI devices (after unbinding the card from whatever it was originally bound to, which in my case is always vfio-pci because I pass it into a QEMU/KVM virtual machine). When I log back in, the card has been automatically bound to amdgpu successfully. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 150731] New: amdgpu: segfault on unbind in sysfs; card becomes nonresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=150731 Bug ID: 150731 Summary: amdgpu: segfault on unbind in sysfs; card becomes nonresponsive Product: Drivers Version: 2.5 Kernel Version: 4.6.4 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: JimiJames.Bove at gmail.com Regression: No Full details here: https://www.reddit.com/r/linux_gaming/comments/4udupx/nvidiaamd_support_questions/d5ovipc Summary: I'm using an R9 380. Others confirmed having this issue on the R9 285 and RX 480 (so, Tonga & Polaris 10 at least). I can bind my video card to amdgpu, and that works. It crashes X, but when I log back in, it's properly connected and everything. However, if I try to unbind it, after waiting for a few seconds, I get a segfault. Any subsequent attempts to do anything with that card in sysfs--trying to unbind again, trying to bind to something else, etc.--will get stuck forever, never segfaulting, because the card is not responding. Removing the card (echo 1 > /sys/bus/pci/devices/:0X:00.0/remove) works, but after a rescan (echo 1 > /sys/bus/pci/rescan), the card is no longer in sysfs at all, as if it's been powered down. It can't be accessed by the system in any way after that, until the computer reboots. It may or may not be related to the "reset issues" bug: http://vfio.blogspot.de/2015/04/progress-on-amd-front.html https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg03128.html That bug officially only affects Hawaii and Bonaire, but Tonga cards (380, 285) exhibit the same behavior even if it may not be for the same reason. Whether it affects Polaris 10 (RX 480) is unknown. The RX 480 tester is currently finding that out. I also had this issue on 4.6.1, so it probably at least affects 4.6 in general. Maybe all kernel versions that have amdgpu? -- You are receiving this mail because: You are watching the assignee of the bug.
[Intel-gfx] [PATCH v4 0/6] Finally fix watermarks
On Fri, Jul 29, 2016 at 02:48:09PM -0400, Lyude wrote: > So I've been working on trying to fix this entirely again (e.g. writing > the ddb properly), since from bug reports it still doesn't sound like > we've got enough workarounds to make this tolerable. I've shown this to > matt roper, but I should probably post what I've been trying to do for > you as well. > > So the approach I came up with is here > > https://github.com/lyude/linux/tree/wip/skl-fix-wms-v5r2 > > My approach differs a little bit from what the bspec recommends, but I > think it's going to be a bit easier to implement. At the end of all the > changes I'm attempting it should look like this: > > * We no longer have a global watermark update for skl > * A new hook called "update_ddbs" is added to i915_display_funcs. This >gets called in intel_atomic_commit_tail() after we've disabled any >CRTCs that needed disabling, and before we begin enabling/updating >CRTCs > * Because pipe ddb allocations (not the inner-pipe ddb allocations >that apply to each pipe's planes) only change while >enabling/disabling crtcs: > * Pass 1: Find which pipe's new ddb allocation won't overlap with > another pipe's previous allocation, and update that pipe first > * Pass 2: Update the allocation of the remaining pipe > > Here's an illustration of what this looks like. Parts of the ddb not > being used by any CRTCs are marked out with 'x's: > > With pipe A enabled, we enable pipe B: > Initial DDB:   |      A      | > update_ddbs:   |   A   |xxx| Pass 1 > Enable pipe B:  |   A   |   B   | > > With pipes B and A active, we enable pipe C: > > Initial DDB:   |   B   |   A   | > update_ddbs:   |  B  |xxx|   A   | Pass 1 > update_ddbs:   |  B  |  A  |xxx| Pass 2 > Enable pipe C:  |  B  |  A  |  C  | > > With pipes A, B, and C active, we disable B: > Initial DDB:   |  A  |  B  |  C  | > Disable pipe B: |  A  |xxx|  C  | > update_ddbs:   |   A   |   C   | Pass 1 > Since neither pipe's new allocation overlapped, we skip pass 2 > > Another allocation with A, B, and C active, disabling A: > Initial DDB:   |  A  |  B  |  C  | > Disable pipe A: |xxx|  B  |  C  | > update_ddbs:   |   B   |xxx|  C  | Pass 1 > update_ddbs:   |   B   |   C   | Pass 2 > > This should ensure we can always move around the allocations of pipes > without them ever overlapping and exploding. That's what the current flush thing does, or at least that what it used to do at least. Not sure it's really doing it anymore, but I'm pretty sure the order in which it did things was sound at some point. > > This branch doesn't entirely fix underrun issues, but I'm mostly sure > that's the fault of still not having removed the global wm update hook > yet (which is leading to additional pipe flushes in places they > shouldn't be): Well it should basically boil down to s/update_wm/update_ddb/ Only DDB reallocation really warrants a global hook. Everything else should be handled via per-crtc hooks, on all platforms. > > https://github.com/lyude/linux/tree/wip/skl-fix-wms-v5r2 > > As for updating inner-pipe ddb allocations for each plane on a pipe, we > should be able to just do that at the same time we update each pipe's > watermarks Yes. None of that changes what I said before though. Either you need to lock down everything when the DDB needs to be repartitioned, or you do what I outlined in the previous mail. Otherwise a plane update etc. happening in parallel will still blow up on account of the DDB state changing underneath the plane update somewhere between compute and commit. I can't really think of third option that would work. > > Let me know what you think > Lyude > > On Fri, 2016-07-29 at 12:39 +0300, Ville Syrjälä wrote: > > On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote: > > > > > > This is completely untested (and probably horribly broken/buggy), > > > but > > > here's a quick mockup of the general approach I was thinking for > > > ensuring DDB & WM's can be updated together while ensuring the > > > three-step pipe flushing process is honored: > > > > > >         > > > https://github.com/mattrope/kernel/commits/experimental/lyu > > > de_ddb > > > > > > Basically the idea is to take note of what's happening to the > > > pipe's DDB > > > allocation (shrinking, growing, unchanged, etc.) during the atomic > > > check > > > phase; > > > > Didn't look too closely, but I think you can't actually do that > > unless > > you lock all the crtcs whenever the number of active pipes is goind > > to > > change. Meaning we'd essentially be back to the one-big-modeset-lock > > apporach, which will cause missed flips and whanot on the other > > pipes. > > > > The alternative I think would consist of: > > - ma
[Bug 97138] AMD 3650 flickering on linux 4.7
https://bugs.freedesktop.org/show_bug.cgi?id=97138 --- Comment #1 from Alex Deucher --- probably a duplicate of bug 97099 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/ddec73ce/attachment.html>
[Bug 97137] R7 M370 hangs with radeon.dpm=1 when running demanding graphical programs with DRI PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=97137 --- Comment #3 from Alex Deucher --- Does setting radeon.runpm=0 on the kernel command line in grub help? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/4487240b/attachment-0001.html>
[Bug 97138] AMD 3650 flickering on linux 4.7
https://bugs.freedesktop.org/show_bug.cgi?id=97138 pavol at klacansky.com changed: What|Removed |Added Version|XOrg git|unspecified -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/0afd89b6/attachment.html>
[Bug 97138] AMD 3650 flickering on linux 4.7
https://bugs.freedesktop.org/show_bug.cgi?id=97138 Bug ID: 97138 Summary: AMD 3650 flickering on linux 4.7 Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: pavol at klacansky.com The weird sine wave-like lines run across diagonal of the screen. On Linux 4.6.4 there is no such issue. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/59f13770/attachment.html>
[Bug 97137] R7 M370 hangs with radeon.dpm=1 when running demanding graphical programs with DRI PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=97137 --- Comment #2 from Mauro Santos --- Created attachment 125427 --> https://bugs.freedesktop.org/attachment.cgi?id=125427&action=edit lspci -vvnn -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/1a85d07d/attachment.html>
[Bug 97137] R7 M370 hangs with radeon.dpm=1 when running demanding graphical programs with DRI PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=97137 --- Comment #1 from Mauro Santos --- Created attachment 125426 --> https://bugs.freedesktop.org/attachment.cgi?id=125426&action=edit dmesg with gpu hang -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/d4c747ec/attachment.html>
[Bug 97137] R7 M370 hangs with radeon.dpm=1 when running demanding graphical programs with DRI PRIME
https://bugs.freedesktop.org/show_bug.cgi?id=97137 Bug ID: 97137 Summary: R7 M370 hangs with radeon.dpm=1 when running demanding graphical programs with DRI PRIME Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: registo.mailling at gmail.com I own a laptop (Thinkpad E560) with an Intel+Radeon gpu combo. When trying to run demanding graphical programs with the radeon gpu via dri prime it hangs. In this context, demanding programs are anything more demanding than glxgears (which runs fine). If I boot with radeon.dpm=0 everything runs fine but at the low default clock speeds. I have been unable to set faster clock speeds via the sysfs interface. I have tried drm-next from https://cgit.freedesktop.org/~airlied/linux/?h=drm-next together with the latest git linux-firmware but the problem is the same. The problem can be replicated by running 'glmark2 -b texture'. However 'glmark2 -b build' seems to work without any problems. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/f969e3af/attachment.html>
[PATCH -next] drm/amdgpu: use kmemdup rather than duplicating its implementation
> -Original Message- > From: Sean Paul [mailto:seanpaul at google.com] > Sent: Friday, July 29, 2016 3:35 PM > To: Wei Yongjun > Cc: Deucher, Alexander; Koenig, Christian; Dave Airlie; Jiang, Sonny; Liu, > Leo; > Nath, Arindam; Zhou, David(ChunMing); Zhou, Jammy; Liu, Monk; dri-devel; > Linux Kernel Mailing List > Subject: Re: [PATCH -next] drm/amdgpu: use kmemdup rather than > duplicating its implementation > > On Thu, Jul 28, 2016 at 12:18 PM, Wei Yongjun wrote: > > Use kmemdup rather than duplicating its implementation. > > > > Generated by: scripts/coccinelle/api/memdup.cocci > > > > Signed-off-by: Wei Yongjun > > > Thanks for the patch. I'll apply this to -misc once the merge window is > closed. > > Acked-by: Sean Paul Unless you've already applied this to the misc tree, I'd prefer to take it via the amdgpu tree. Alex > > > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c > > index a46a64c..b779b5f 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c > > @@ -296,12 +296,10 @@ int amdgpu_uvd_suspend(struct amdgpu_device > *adev) > > size = amdgpu_bo_size(adev->uvd.vcpu_bo); > > ptr = adev->uvd.cpu_addr; > > > > - adev->uvd.saved_bo = kmalloc(size, GFP_KERNEL); > > + adev->uvd.saved_bo = kmemdup(ptr, size, GFP_KERNEL); > > if (!adev->uvd.saved_bo) > > return -ENOMEM; > > > > - memcpy(adev->uvd.saved_bo, ptr, size); > > - > > return 0; > > } > > > > > > > >
[Bug 96326] Heavy screen flickering in OpenGL apps on R9 390
https://bugs.freedesktop.org/show_bug.cgi?id=96326 --- Comment #6 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> --- (In reply to Alex Deucher from comment #3) > Please attach your xorg log and dmesg output. Upstream Linux kernel does not support variable mclk on R9 390. I enabled variable mclk by patching some code in drivers/gpu/drm/amd/amdgpu/ (mostly ci_dpm.c). dmesg output contains some logging messages I added to my copy of Linux kernel source code. > What resolution and refresh rate are you using on your monitor? 1920x1080 60Hz > Also are you using radeon or amdgpu? Currently amdgpu.ko, radeon.ko in the past. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/b59330b4/attachment.html>
ATPX changes in drm-next-4.8 and D3cold handling
On Fri, Jul 29, 2016 at 03:45:50PM +, Deucher, Alexander wrote: > > -Original Message- > > From: Peter Wu [mailto:peter at lekensteyn.nl] > > Sent: Thursday, July 28, 2016 8:00 PM > > To: Lukas Wunner > > Cc: Deucher, Alexander; dri-devel at lists.freedesktop.org; Christoph Haag; > > Koenig, Christian; amd-gfx at lists.freedesktop.org; Zhang, Hawking > > Subject: Re: ATPX changes in drm-next-4.8 and D3cold handling > > > > On Thu, Jul 28, 2016 at 05:40:31PM +0200, Lukas Wunner wrote: > > > On Thu, Jul 28, 2016 at 03:33:25PM +, Deucher, Alexander wrote: > > > > > From: Peter Wu [mailto:peter at lekensteyn.nl] > > > > > Sent: Thursday, July 21, 2016 6:43 AM > > > > > In case you missed it, Dave's D3cold patches were succeeded by > > changes > > > > > in PCI core. Relevant commits in the pci/pm branch: > > > > > > > > > > 006d44e PCI: Add runtime PM support for PCIe ports > > > > > 16468c7 ACPI / hotplug / PCI: Runtime resume bridge before rescan > > > > > d963f65 PCI: Power on bridges before scanning new devices > > > > > 9d26d3a PCI: Put PCIe ports into D3 during suspend > > > > > 43f7f88 PCI: Don't clear d3cold_allowed for PCIe ports > > > > > > > > Did those get merged yet? > > > > > > They will go into 4.8. Should have gone into 4.7 already but were > > > dropped at the last minute. > > > > > > > > > > I just need to revert this commit once the d3cold patches land: > > > > https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next- > > 4.8&id=bdfb76040068d960cb9e226876be8a508d741c4a > > > > > > So you probably need to revert this now. > > > > > > Best regards, > > > Lukas > > > > It is better to revert it before the PCI/PM patches get merged, > > otherwise you risk that the device is already put in D3 before the > > bridge tries to do it again. This is currently happening with nouveau on > > -next. > > > > Do these AMD hw exist on BIOSes pre-2015? Currently the D3cold work in > > the PCI/PM branch only enable the D3cold handling via the bridge when > > the BIOS is >= 2015. > > Systems designed for windows 10 use d3 cold rather than the legacy > interfaces. Setting the ACPI OSI to windows10 will enable d3cold, > setting it to a previous version of windows will use the old method. > At least on AMD PX systems there is a bit in the ATPX information > block that indicates the current setting hybrid graphics (aka d3cold) > or the ATPX power control for dGPU power control. > > Alex Windows 10 is Windows 2015, so BIOS dates for new Windows 10 devices should be newer or equal to 2015 and no problem should occur. No worries! My initial concern was from the blacklist for ore-2015 BIOSes as can be seen in function pci_bridge_d3_possible in https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=pci/pm&id=9d26d3a8f1b0c442339a235f9508bdad8af91043 Kind regards, Peter
[Bug 96326] Heavy screen flickering in OpenGL apps on R9 390
https://bugs.freedesktop.org/show_bug.cgi?id=96326 --- Comment #5 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> --- Created attachment 125425 --> https://bugs.freedesktop.org/attachment.cgi?id=125425&action=edit Xorg.0.log (xorg-server-1.17.4, no custom patches) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/5c5ad48c/attachment.html>
[Bug 96326] Heavy screen flickering in OpenGL apps on R9 390
https://bugs.freedesktop.org/show_bug.cgi?id=96326 --- Comment #4 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> --- Created attachment 125424 --> https://bugs.freedesktop.org/attachment.cgi?id=125424&action=edit dmesg (linux kernel git 2016-jul-29 with custom patches) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/1dc694e8/attachment.html>
[PATCH 2/7] drm/mediatek: plane: Remove plane zpos/index
Hi, Bibby:
On Fri, 2016-07-29 at 17:04 +0800, Bibby Hsieh wrote:
> From: Daniel Kurtz
>
> It is not actually useful to a mtk plane to know its zpos/index, so just
> remove this field.
>
> This let's us completely remove struct mtk_drm_plane in a follow up patch.
'let's us'? My English is not as good as native English speaker.
Otherwise, this patch looks good to me.
>
> Signed-off-by: Daniel Kurtz
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c |2 +-
> drivers/gpu/drm/mediatek/mtk_drm_plane.c |4 +---
> drivers/gpu/drm/mediatek/mtk_drm_plane.h |4 +---
> 3 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 24aa3ba..18211ab 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -559,7 +559,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> (zpos == 1) ? DRM_PLANE_TYPE_CURSOR :
> DRM_PLANE_TYPE_OVERLAY;
> ret = mtk_plane_init(drm_dev, &mtk_crtc->planes[zpos],
> - BIT(pipe), type, zpos);
> + BIT(pipe), type);
> if (ret)
> goto unprepare;
> }
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index 093db07..d28db57 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -189,8 +189,7 @@ static const struct drm_plane_helper_funcs
> mtk_plane_helper_funcs = {
> };
>
> int mtk_plane_init(struct drm_device *dev, struct mtk_drm_plane *mtk_plane,
> -unsigned long possible_crtcs, enum drm_plane_type type,
> -unsigned int zpos)
> +unsigned long possible_crtcs, enum drm_plane_type type)
> {
> int err;
>
> @@ -203,7 +202,6 @@ int mtk_plane_init(struct drm_device *dev, struct
> mtk_drm_plane *mtk_plane,
> }
>
> drm_plane_helper_add(&mtk_plane->base, &mtk_plane_helper_funcs);
> - mtk_plane->idx = zpos;
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.h
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.h
> index 72a7b3e..74dbeda 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.h
> @@ -20,7 +20,6 @@
>
> struct mtk_drm_plane {
> struct drm_planebase;
> - unsigned intidx;
> };
>
> struct mtk_plane_pending_state {
> @@ -53,7 +52,6 @@ to_mtk_plane_state(struct drm_plane_state *state)
> }
>
> int mtk_plane_init(struct drm_device *dev, struct mtk_drm_plane *mtk_plane,
> -unsigned long possible_crtcs, enum drm_plane_type type,
> -unsigned int zpos);
> +unsigned long possible_crtcs, enum drm_plane_type type);
>
> #endif
Regards,
CK
[PATCH 7/7] drm/mediatek: Fix mtk_atomic_complete for runtime_pm
To properly implement atomic w/ runtime pm, we move drm_atomic_helper_commit_modeset_enables() above drm_atomic_helper_commit_planes() to ensure CRTCs are enabled before modifying plane registers, and set active_only to true to filter out plane update notifications when the CRTC is disabled. According to the document from linux kernel: Set the active_only parameters to true in order not to receive plane update notifications related to a disabled CRTC. This avoids the need to manually ignore plane updates in driver code when the driver and/or hardware can't or just don't need to deal with updates on disabled CRTCs, for example when supporting runtime PM. Signed-off-by: Bibby Hsieh Signed-off-by: Daniel Kurtz --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index b1223d5..507392a 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -61,10 +61,25 @@ static void mtk_atomic_complete(struct mtk_drm_private *private, mtk_atomic_wait_for_fences(state); + /* +* Mediatek drm supports runtime PM, so plane registers cannot be +* written when their crtc is disabled. +* +* The comment for drm_atomic_helper_commit states: +* For drivers supporting runtime PM the recommended sequence is +* +* drm_atomic_helper_commit_modeset_disables(dev, state); +* drm_atomic_helper_commit_modeset_enables(dev, state); +* drm_atomic_helper_commit_planes(dev, state, true); +* +* See the kerneldoc entries for these three functions for more details. +*/ drm_atomic_helper_commit_modeset_disables(drm, state); - drm_atomic_helper_commit_planes(drm, state, false); drm_atomic_helper_commit_modeset_enables(drm, state); + drm_atomic_helper_commit_planes(drm, state, true); + drm_atomic_helper_wait_for_vblanks(drm, state); + drm_atomic_helper_cleanup_planes(drm, state); drm_atomic_state_free(state); } -- 1.7.9.5
[PATCH 6/7] drm/mediatek: plane: Use FB's format's cpp to compute x offset
From: Daniel Kurtz Use the framebuffer's format to compute its cpp, and use it when calculating the address shift value. Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_plane.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c index b3ddb20..c461a23 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c @@ -135,7 +135,7 @@ static void mtk_plane_atomic_update(struct drm_plane *plane, pitch = fb->pitches[0]; format = fb->pixel_format; - addr += (plane->state->src.x1 >> 16) * 4; + addr += (plane->state->src.x1 >> 16) * drm_format_plane_cpp(format, 0); addr += (plane->state->src.y1 >> 16) * pitch; state->pending.enable = true; -- 1.7.9.5
[PATCH 5/7] drm/mediatek: plane: Merge mtk_plane_enable into mtk_plane_atomic_update
From: Daniel Kurtz
The mtk_plane_enable is just called once by mtk_plane_atomic_update.
So, merge mtk_plane_enable into mtk_plane_atomic_update.
While we are here, also clean up the function a bit by using an fb local
variables.
Signed-off-by: Bibby Hsieh
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 65 +++---
1 file changed, 23 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index 17172ba..b3ddb20 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -30,44 +30,6 @@ static const u32 formats[] = {
DRM_FORMAT_RGB565,
};
-static void mtk_plane_enable(struct drm_plane *plane,
-dma_addr_t addr)
-{
- struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
- unsigned int pitch, format;
- bool enable;
-
- if (WARN_ON(!plane->state))
- return;
-
- enable = state->base.visible;
-
- if (WARN_ON(enable && !plane->state->fb))
- return;
-
- if (plane->state->fb) {
- pitch = plane->state->fb->pitches[0];
- format = plane->state->fb->pixel_format;
- } else {
- pitch = 0;
- format = DRM_FORMAT_RGBA;
- }
-
- addr += (state->base.src.x1 >> 16) * 4;
- addr += (state->base.src.y1 >> 16) * pitch;
-
- state->pending.enable = enable;
- state->pending.pitch = pitch;
- state->pending.format = format;
- state->pending.addr = addr;
- state->pending.x = state->base.dst.x1;
- state->pending.y = state->base.dst.y1;
- state->pending.width = drm_rect_width(&state->base.dst);
- state->pending.height = drm_rect_height(&state->base.dst);
- wmb(); /* Make sure the above parameters are set before update */
- state->pending.dirty = true;
-}
-
static void mtk_plane_reset(struct drm_plane *plane)
{
struct mtk_plane_state *state;
@@ -157,16 +119,35 @@ static void mtk_plane_atomic_update(struct drm_plane
*plane,
struct drm_plane_state *old_state)
{
struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
- struct drm_crtc *crtc = state->base.crtc;
+ struct drm_crtc *crtc = plane->state->crtc;
+ struct drm_framebuffer *fb = plane->state->fb;
struct drm_gem_object *gem;
struct mtk_drm_gem_obj *mtk_gem;
+ unsigned int pitch, format;
+ dma_addr_t addr;
- if (!crtc)
+ if (!crtc || WARN_ON(!fb))
return;
- gem = mtk_fb_get_gem_obj(state->base.fb);
+ gem = mtk_fb_get_gem_obj(fb);
mtk_gem = to_mtk_gem_obj(gem);
- mtk_plane_enable(plane, mtk_gem->dma_addr);
+ addr = mtk_gem->dma_addr;
+ pitch = fb->pitches[0];
+ format = fb->pixel_format;
+
+ addr += (plane->state->src.x1 >> 16) * 4;
+ addr += (plane->state->src.y1 >> 16) * pitch;
+
+ state->pending.enable = true;
+ state->pending.pitch = pitch;
+ state->pending.format = format;
+ state->pending.addr = addr;
+ state->pending.x = plane->state->dst.x1;
+ state->pending.y = plane->state->dst.y1;
+ state->pending.width = drm_rect_width(&plane->state->dst);
+ state->pending.height = drm_rect_height(&plane->state->dst);
+ wmb(); /* Make sure the above parameters are set before update */
+ state->pending.dirty = true;
}
static void mtk_plane_atomic_disable(struct drm_plane *plane,
--
1.7.9.5
[PATCH 4/7] drm/mediatek: Use drm_atomic destroy_state helpers
Use the core destroy_state helpers to destroy core state to ensure we don't
leak if/when more fields get added later.
Signed-off-by: Daniel Kurtz
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c |3 +--
drivers/gpu/drm/mediatek/mtk_drm_plane.c |3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index d6fbefa..733b2a3 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -112,8 +112,7 @@ static void mtk_drm_crtc_reset(struct drm_crtc *crtc)
struct mtk_crtc_state *state;
if (crtc->state) {
- if (crtc->state->mode_blob)
- drm_property_unreference_blob(crtc->state->mode_blob);
+ __drm_atomic_helper_crtc_destroy_state(crtc->state);
state = to_mtk_crtc_state(crtc->state);
memset(state, 0, sizeof(*state));
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index 86b7aed..17172ba 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -73,8 +73,7 @@ static void mtk_plane_reset(struct drm_plane *plane)
struct mtk_plane_state *state;
if (plane->state) {
- if (plane->state->fb)
- drm_framebuffer_unreference(plane->state->fb);
+ __drm_atomic_helper_plane_destroy_state(plane->state);
state = to_mtk_plane_state(plane->state);
memset(state, 0, sizeof(*state));
--
1.7.9.5
[PATCH 3/7] drm/mediatek: Remove mtk_drm_plane
From: Daniel Kurtz
Now that mtk_drm_plane just contains its base struct drm_plane, we can
just remove it and use struct drm_plane everywhere.
Signed-off-by: Daniel Kurtz
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 16
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 10 --
drivers/gpu/drm/mediatek/mtk_drm_plane.h | 11 +--
3 files changed, 13 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 18211ab..d6fbefa 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -31,7 +31,7 @@
* struct mtk_drm_crtc - MediaTek specific crtc structure.
* @base: crtc object.
* @enabled: records whether crtc_enable succeeded
- * @planes: array of 4 mtk_drm_plane structures, one for each overlay plane
+ * @planes: array of 4 drm_plane structures, one for each overlay plane
* @pending_planes: whether any plane has pending changes to be applied
* @config_regs: memory mapped mmsys configuration register space
* @mutex: handle to one of the ten disp_mutex streams
@@ -45,7 +45,7 @@ struct mtk_drm_crtc {
boolpending_needs_vblank;
struct drm_pending_vblank_event *event;
- struct mtk_drm_planeplanes[OVL_LAYER_NR];
+ struct drm_planeplanes[OVL_LAYER_NR];
boolpending_planes;
void __iomem*config_regs;
@@ -272,7 +272,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc
*mtk_crtc)
/* Initially configure all planes */
for (i = 0; i < OVL_LAYER_NR; i++) {
- struct drm_plane *plane = &mtk_crtc->planes[i].base;
+ struct drm_plane *plane = &mtk_crtc->planes[i];
struct mtk_plane_state *plane_state;
plane_state = to_mtk_plane_state(plane->state);
@@ -351,7 +351,7 @@ static void mtk_drm_crtc_disable(struct drm_crtc *crtc)
/* Set all pending plane state to disabled */
for (i = 0; i < OVL_LAYER_NR; i++) {
- struct drm_plane *plane = &mtk_crtc->planes[i].base;
+ struct drm_plane *plane = &mtk_crtc->planes[i];
struct mtk_plane_state *plane_state;
plane_state = to_mtk_plane_state(plane->state);
@@ -397,7 +397,7 @@ static void mtk_drm_crtc_atomic_flush(struct drm_crtc *crtc,
if (mtk_crtc->event)
mtk_crtc->pending_needs_vblank = true;
for (i = 0; i < OVL_LAYER_NR; i++) {
- struct drm_plane *plane = &mtk_crtc->planes[i].base;
+ struct drm_plane *plane = &mtk_crtc->planes[i];
struct mtk_plane_state *plane_state;
plane_state = to_mtk_plane_state(plane->state);
@@ -471,7 +471,7 @@ void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct
mtk_ddp_comp *ovl)
if (mtk_crtc->pending_planes) {
for (i = 0; i < OVL_LAYER_NR; i++) {
- struct drm_plane *plane = &mtk_crtc->planes[i].base;
+ struct drm_plane *plane = &mtk_crtc->planes[i];
struct mtk_plane_state *plane_state;
plane_state = to_mtk_plane_state(plane->state);
@@ -564,8 +564,8 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
goto unprepare;
}
- ret = mtk_drm_crtc_init(drm_dev, mtk_crtc, &mtk_crtc->planes[0].base,
- &mtk_crtc->planes[1].base, pipe);
+ ret = mtk_drm_crtc_init(drm_dev, mtk_crtc, &mtk_crtc->planes[0],
+ &mtk_crtc->planes[1], pipe);
if (ret < 0)
goto unprepare;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index d28db57..86b7aed 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -33,7 +33,6 @@ static const u32 formats[] = {
static void mtk_plane_enable(struct drm_plane *plane,
dma_addr_t addr)
{
- struct drm_plane *plane = &mtk_plane->base;
struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
unsigned int pitch, format;
bool enable;
@@ -162,14 +161,13 @@ static void mtk_plane_atomic_update(struct drm_plane
*plane,
struct drm_crtc *crtc = state->base.crtc;
struct drm_gem_object *gem;
struct mtk_drm_gem_obj *mtk_gem;
- struct mtk_drm_plane *mtk_plane = to_mtk_plane(plane);
if (!crtc)
return;
gem = mtk_fb_get_gem_obj(state->base.fb);
mtk_gem = to_mtk_gem_obj(gem);
- mtk_plane_enable(mtk_plane, mtk_gem->dma_addr);
+ mtk_plane_enable(plane, mtk_gem->dma_addr);
}
static void mtk_plane_atomic_disable(struct drm_plane *plane,
@@ -188,12 +186,12 @@ static const struct drm_plane_helper_funcs
mtk_
[PATCH 2/7] drm/mediatek: plane: Remove plane zpos/index
From: Daniel Kurtz
It is not actually useful to a mtk plane to know its zpos/index, so just
remove this field.
This let's us completely remove struct mtk_drm_plane in a follow up patch.
Signed-off-by: Daniel Kurtz
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c |2 +-
drivers/gpu/drm/mediatek/mtk_drm_plane.c |4 +---
drivers/gpu/drm/mediatek/mtk_drm_plane.h |4 +---
3 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 24aa3ba..18211ab 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -559,7 +559,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
(zpos == 1) ? DRM_PLANE_TYPE_CURSOR :
DRM_PLANE_TYPE_OVERLAY;
ret = mtk_plane_init(drm_dev, &mtk_crtc->planes[zpos],
-BIT(pipe), type, zpos);
+BIT(pipe), type);
if (ret)
goto unprepare;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index 093db07..d28db57 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -189,8 +189,7 @@ static const struct drm_plane_helper_funcs
mtk_plane_helper_funcs = {
};
int mtk_plane_init(struct drm_device *dev, struct mtk_drm_plane *mtk_plane,
- unsigned long possible_crtcs, enum drm_plane_type type,
- unsigned int zpos)
+ unsigned long possible_crtcs, enum drm_plane_type type)
{
int err;
@@ -203,7 +202,6 @@ int mtk_plane_init(struct drm_device *dev, struct
mtk_drm_plane *mtk_plane,
}
drm_plane_helper_add(&mtk_plane->base, &mtk_plane_helper_funcs);
- mtk_plane->idx = zpos;
return 0;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.h
b/drivers/gpu/drm/mediatek/mtk_drm_plane.h
index 72a7b3e..74dbeda 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.h
@@ -20,7 +20,6 @@
struct mtk_drm_plane {
struct drm_planebase;
- unsigned intidx;
};
struct mtk_plane_pending_state {
@@ -53,7 +52,6 @@ to_mtk_plane_state(struct drm_plane_state *state)
}
int mtk_plane_init(struct drm_device *dev, struct mtk_drm_plane *mtk_plane,
- unsigned long possible_crtcs, enum drm_plane_type type,
- unsigned int zpos);
+ unsigned long possible_crtcs, enum drm_plane_type type);
#endif
--
1.7.9.5
[PATCH 1/7] drm/mediatek: Remove mtk_drm_crtc_check_flush
From: Daniel Kurtz This function no longer exists. Signed-off-by: Daniel Kurtz Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h index 81e5566..4d32cf1 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.h +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.h @@ -22,7 +22,6 @@ int mtk_drm_crtc_enable_vblank(struct drm_device *drm, unsigned int pipe); void mtk_drm_crtc_disable_vblank(struct drm_device *drm, unsigned int pipe); -void mtk_drm_crtc_check_flush(struct drm_crtc *crtc); void mtk_drm_crtc_commit(struct drm_crtc *crtc); void mtk_crtc_ddp_irq(struct drm_crtc *crtc, struct mtk_ddp_comp *ovl); int mtk_drm_crtc_create(struct drm_device *drm_dev, -- 1.7.9.5
[PATCH 0/7] drm/mediatek: cleaning up and refine
These patches based on 4.7-rc1 to clean up unused function & variable and use drm core function instead. The following patches are needed to cleanly apply on top of v4.7-rc1: - https://patchwork.kernel.org/patch/8044001/ (drm: Deal with rotation in drm_plane_helper_check_update()) - https://patchwork.kernel.org/patch/9248373/ (drm: Warn about negative sizes when calculating scale factor) - https://patchwork.kernel.org/patch/9248371/ (drm: Store clipped src/dst coordinatee in drm_plane_state) - https://patchwork.kernel.org/patch/9248363/ (drm/plane-helper: Add drm_plane_helper_check_state()) - https://patchwork.kernel.org/patch/9248361/ (drm/mediatek: Use drm_plane_helper_check_state()) Bibby Hsieh (2): drm/mediatek: Use drm_atomic destroy_state helpers drm/mediatek: Fix mtk_atomic_complete for runtime_pm Daniel Kurtz (5): drm/mediatek: Remove mtk_drm_crtc_check_flush drm/mediatek: plane: Remove plane zpos/index drm/mediatek: Remove mtk_drm_plane drm/mediatek: plane: Merge mtk_plane_enable into mtk_plane_atomic_update drm/mediatek: plane: Use FB's format's cpp to compute x offset drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 21 drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 - drivers/gpu/drm/mediatek/mtk_drm_drv.c | 17 ++- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 80 +++--- drivers/gpu/drm/mediatek/mtk_drm_plane.h | 15 +- 5 files changed, 56 insertions(+), 78 deletions(-) -- 1.7.9.5
[Bug 93050] Amdgpu, Tonga "IO_PAGE_FAULT" and "[amdgpu]] *ERROR* amdgpu: ring 0 test failed" result in Kernel Panic
https://bugs.freedesktop.org/show_bug.cgi?id=93050 --- Comment #2 from Alexander Tsoy --- These I/O page faults errors are quite annoying and delay boot for about 5 seconds. Should I open a separate bug report? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/09e407d0/attachment.html>
[PATCH v2] drm/fsl-dcu: Implement gamma_lut atomic crtc properties
Gamma correction is optional and can be used to adjust the color
output values to match the gamut of a particular TFT LCD panel
Gamma_R, Gamma_G and Gamma_B registers are little-endian registers
while the rest of the address-space in 2D-ACE is big-endian.
Signed-off-by: Meng Yi
---
Changes in V2:
-title "Add gamma set for crtc" changed
-use new atomic color management properties instead
-simplify the method for workaround by using val<<24
-add registers endianness info to comments
---
drivers/gpu/drm/fsl-dcu/Kconfig| 6 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 39 ++
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 8 ++
3 files changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/fsl-dcu/Kconfig b/drivers/gpu/drm/fsl-dcu/Kconfig
index b9c714d..ddfe3c4 100644
--- a/drivers/gpu/drm/fsl-dcu/Kconfig
+++ b/drivers/gpu/drm/fsl-dcu/Kconfig
@@ -16,3 +16,9 @@ config DRM_FSL_DCU
help
Choose this option if you have an Freescale DCU chipset.
If M is selected the module will be called fsl-dcu-drm.
+
+config DRM_FSL_DCU_GAMMA
+ bool "Gamma Correction Support for NXP/Freescale DCU"
+ depends on DRM_FSL_DCU
+ help
+ Enable support for gamma correction.
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index 3371635..f187992 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -22,6 +22,22 @@
#include "fsl_dcu_drm_drv.h"
#include "fsl_dcu_drm_plane.h"
+static void fsl_crtc_gamma_set(struct drm_crtc *crtc, struct drm_color_lut
*lut,
+ uint32_t size)
+{
+ struct fsl_dcu_drm_device *fsl_dev = crtc->dev->dev_private;
+ unsigned int i;
+
+ for (i = 0; i < size; i++) {
+ regmap_write(fsl_dev->regmap, FSL_GAMMA_R + 4 * i,
+lut[i].red << 24);
+ regmap_write(fsl_dev->regmap, FSL_GAMMA_G + 4 * i,
+lut[i].green << 24);
+ regmap_write(fsl_dev->regmap, FSL_GAMMA_B + 4 * i,
+lut[i].blue << 24);
+ }
+}
+
static void fsl_dcu_drm_crtc_atomic_flush(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state)
{
@@ -37,6 +53,11 @@ static void fsl_dcu_drm_crtc_atomic_flush(struct drm_crtc
*crtc,
drm_crtc_send_vblank_event(crtc, event);
spin_unlock_irq(&crtc->dev->event_lock);
}
+
+ if (crtc->state->color_mgmt_changed && crtc->state->gamma_lut)
+ fsl_crtc_gamma_set(crtc, (struct drm_color_lut *)
+ crtc->state->gamma_lut->data,
+ 256);
}
static void fsl_dcu_drm_disable_crtc(struct drm_crtc *crtc)
@@ -46,6 +67,11 @@ static void fsl_dcu_drm_disable_crtc(struct drm_crtc *crtc)
drm_crtc_vblank_off(crtc);
+ if (fsl_dev->enable_color_mgmt)
+ regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
+ DCU_MODE_EN_GAMMA_MASK,
+ DCU_MODE_GAMMA_DISABLE);
+
regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
DCU_MODE_DCU_MODE_MASK,
DCU_MODE_DCU_MODE(DCU_MODE_OFF));
@@ -58,6 +84,11 @@ static void fsl_dcu_drm_crtc_enable(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+ if (fsl_dev->enable_color_mgmt)
+ regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
+ DCU_MODE_EN_GAMMA_MASK,
+ DCU_MODE_GAMMA_ENABLE);
+
regmap_update_bits(fsl_dev->regmap, DCU_DCU_MODE,
DCU_MODE_DCU_MODE_MASK,
DCU_MODE_DCU_MODE(DCU_MODE_NORMAL));
@@ -135,6 +166,7 @@ static const struct drm_crtc_funcs fsl_dcu_drm_crtc_funcs =
{
.page_flip = drm_atomic_helper_page_flip,
.reset = drm_atomic_helper_crtc_reset,
.set_config = drm_atomic_helper_set_config,
+ .gamma_set = drm_atomic_helper_legacy_gamma_set,
};
int fsl_dcu_drm_crtc_create(struct fsl_dcu_drm_device *fsl_dev)
@@ -158,5 +190,12 @@ int fsl_dcu_drm_crtc_create(struct fsl_dcu_drm_device
*fsl_dev)
drm_crtc_helper_add(crtc, &fsl_dcu_drm_crtc_helper_funcs);
+#ifdef CONFIG_DRM_FSL_DCU_GAMMA
+ fsl_dev->enable_color_mgmt = true;
+
+ drm_crtc_enable_color_mgmt(crtc, 0, false, 256);
+ drm_mode_crtc_set_gamma_size(crtc, 256);
+#endif
+
return 0;
}
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
index 3b371fe7..a164e91 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
@@ -25,6 +25,9 @@
#define DCU_MODE_NORMAL
[PATCH v2 3/3] drm/mediatek: fix the wrong pixel clock when resolution is 4K
On Wed, Jul 27, 2016 at 04:31:32PM +0800, Bibby Hsieh wrote:
> From: Junzhi Zhao
>
> Pixel clock should be 297MHz when resolution is 4K.
>
> Signed-off-by: Junzhi Zhao
> Signed-off-by: Bibby Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_dpi.c | 149
> +++-
> 1 file changed, 96 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index d05ca79..fa390e0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -60,14 +60,25 @@ enum mtk_dpi_out_color_format {
> MTK_DPI_COLOR_FORMAT_YCBCR_422_FULL
> };
>
> +enum mtk_dpi_clk_id {
> + MTK_DPI_CLK_DPI_ENGINE,
> + MTK_DPI_CLK_DPI_PIXEL,
> + MTK_DPI_CLK_TVD_PLL,
> + MTK_DPI_CLK_COUNT,
> +};
> +
> +static const char * const mtk_dpi_clk_names[MTK_DPI_CLK_COUNT] = {
> + [MTK_DPI_CLK_DPI_ENGINE] = "engine",
> + [MTK_DPI_CLK_DPI_PIXEL] = "pixel",
> + [MTK_DPI_CLK_TVD_PLL] = "pll",
> +};
> +
> struct mtk_dpi {
> struct mtk_ddp_comp ddp_comp;
> struct drm_encoder encoder;
> void __iomem *regs;
> struct device *dev;
> - struct clk *engine_clk;
> - struct clk *pixel_clk;
> - struct clk *tvd_clk;
> + struct clk *clk[MTK_DPI_CLK_COUNT];
This looks to me like a step backwards. All accesses to these clocks are
now very clumsy and I don't see any advantage in using this array rather
than individually named clocks.
Also, that change seems completely unrelated to the description in the
commit message.
> int irq;
> struct drm_display_mode mode;
> enum mtk_dpi_out_color_format color_format;
> @@ -76,6 +87,7 @@ struct mtk_dpi {
> enum mtk_dpi_out_channel_swap channel_swap;
> bool power_sta;
> u8 power_ctl;
> + void *data;
This should probably be const. It's a bad idea to cast away the const
from the of_device_id.data that this is assigned from.
> +static const struct of_device_id mtk_dpi_of_ids[] = {
> + { .compatible = "mediatek,mt8173-dpi",
> + .data = &mt8173_conf,
> + },
Please align this in some standard way. It all fits on one line, so the
most obvious choice would've been:
{ .compatible = "mediatek,mt8173-dpi", .data = &mt8173_conf },
> + {}
> +};
> +
> static int mtk_dpi_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> struct mtk_dpi *dpi;
> struct resource *mem;
> + struct device_node *np = dev->of_node;
> struct device_node *ep, *bridge_node = NULL;
> int comp_id;
> + const struct of_device_id *match;
> + struct mtk_dpi_conf *conf;
> int ret;
>
> + match = of_match_node(mtk_dpi_of_ids, dev->of_node);
> + if (!match)
> + return -ENODEV;
You introduce a variable np = dev->of_node above, but then you add code
that uses dev->of_node directly?
That said, you should use of_device_get_match_data() anyway, so that you
can omit...
> +
> dpi = devm_kzalloc(dev, sizeof(*dpi), GFP_KERNEL);
> if (!dpi)
> return -ENOMEM;
>
> dpi->dev = dev;
> + dpi->data = (void *)match->data;
> + conf = (struct mtk_dpi_conf *)match->data;
... the dereferences here. Also, like I said before you should make
dpi->data and conf both const to avoid casting away the constness of the
data. If you do that you can even drop the casts because you'd be
casting from a const void * to a const foo *, which gets casted
automatically.
> @@ -754,11 +802,6 @@ static int mtk_dpi_remove(struct platform_device *pdev)
> return 0;
> }
>
> -static const struct of_device_id mtk_dpi_of_ids[] = {
> - { .compatible = "mediatek,mt8173-dpi", },
> - {}
> -};
Another advantage of using of_device_get_match_data() is that it doesn't
need direct access to the of_device_id table (it'll obtain it via an
indirect dev->driver->of_match_table), so you don't have to move this
around and make this patch overall less churn.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/de5bab71/attachment.sig>
[Intel-gfx] [PATCH 1/9] drm: Warn about negative sizes when calculating scale factor
On Tue, Jul 26, 2016 at 12:39 PM, Ville Syrjälä wrote: > On Tue, Jul 26, 2016 at 05:24:42PM +0100, Chris Wilson wrote: >> On Tue, Jul 26, 2016 at 07:06:56PM +0300, ville.syrjala at linux.intel.com >> wrote: >> > From: Ville Syrjälä >> > >> > Passing negative width/hight to scale factor calculations is not nit: s/hight/height/ >> > legal. Let's WARN if that happens. >> >> Does this get called with user controllable inputs? > > User controllable to a degree. width/height can only ever be positive > though. > I think the only risk is getting UINT_MAX from userspace, since drm_rect stores ints. However, it looks like check_src_coords() and the check in __setplane_internal() should ensure those values are pruned out. Reviewed-by: Sean Paul >> A quick grep leads >> me to drm_primary_helper_update() which suggests no. Did I miss a >> potential user controllable WARN->panic? > > I just landed in the BUG_ON in intel_sprite.c on account of a typo I > made in the user src/crtc coordinate -> drm_rect conversion. Should > probably replace the BUG_ON() with WARN_ON() in i915 as well... > > -- > Ville Syrjälä > Intel OTC > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Bug 95427] gem_userptr_blits@mlocked-* should skip due to memory pre-condition not met
https://bugs.freedesktop.org/show_bug.cgi?id=95427 --- Comment #6 from Chris Wilson --- (In reply to cprigent from comment #4) > (In reply to Emil Velikov from comment #3) > > Guys have you actually looked at the following line ? > > Aperture size is 268435456 MiB -- That is 256 TiB !!! > > > > That's rather impossible amount if you ask me. So there's either a bug in > > IGT's gem_aperture_size() or one of the two ioctls > > (I915_GEM_CONTEXT_GETPARAM I915_GEM_GET_APERTURE) that it uses. > > > > With a couple of print statements you should be able to quickly track the > > exact offender. Good luck ! > > Yes, we saw it. The bug is reported to IGT (not to DRM/Intel). We propose > the test should skip. Why? The test only allocates enough to fill RAM and then tests that the buffers are evicted for memory pressure. The messages are nothing to do with this test, just spam. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/67c1eee7/attachment.html>
[PATCH 2/2] dt-bindings: add simple-panel-dsi and simple-panel
On Thu, Jul 28, 2016 at 02:00:21PM -0500, Rob Herring wrote: > On Tue, Jul 26, 2016 at 4:02 AM, Thierry Reding > wrote: > > On Tue, Jul 26, 2016 at 10:01:32AM +0800, Mark yao wrote: > >> On 2016å¹´07æ25æ¥ 23:21, Thierry Reding wrote: > >> > >> On Wed, Jul 20, 2016 at 11:18:50AM +0800, Mark Yao wrote: > >> > >> Allow user add display timing on device tree with simple-panel-dsi > >> or simple-panel. > >> > >> Cc: Thierry Reding > >> Cc: Rob Herring > >> Cc: Mark Rutland > >> > >> Signed-off-by: Mark Yao > >> --- > >> .../bindings/display/panel/simple-panel.txt| 48 > >> ++ > >> 1 file changed, 48 insertions(+) > >> > >> Sorry, not going to happen. Read this for an explanation of why not: > >> > >> > >> https://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html > >> > >> Thierry > >> > >> > >> Hi Thierry > >> > >> The blog actually not persuade me why can't use display timing on > >> device tree. > > > > Okay, perhaps read it again, it addresses most of your points below. > > > >> 1, Binding panel as a simple string on device tree seems simple on device > >> tree, > >> but it's complex on kernel code, and kernel code would became bigger and > >> bigger. > > > > I don't think the video timings in the simple-panel driver are very > > complex. They also don't use very much space. And if you're really > > concerned about space you can always use conditional compilation and > > Kconfig symbols to remove timings for panels that you don't use. > > > > Also, panels are characterized by much more than just video timings. > > There were attempts, way back, to fully describe panels in device tree > > and that failed. What you propose here is a partial solution to a much > > more complex problem. > > > > This is all explained in the blog post. > > While I agree with everything Thierry has said in this thread, there > is an argument to be made for timing information in DT. > > Maybe most vendors have now learned that flexible clock frequencies > are needed to generate the correct timings, but I have worked on parts > without fine resolution (i.e. a dedicated pll). Even HiKey with HDMI > suffers from this. In that case you can be tuning the timings > (increasing the h and/or v blanks) to get the desired refresh rates. > So in that case, the panel compatible would not determine the display > timings and you could have the same panel with different timings on > different boards. That's maybe rare enough that putting timing info in > DT still wouldn't make sense. There's another mechanism, though not very popular (possibly because it is indeed a very rare usecase), that we introduced a while ago. The idea is that we don't specify the mode per panel, as we do now, but rather a range of values that are valid for the various video timing parameters. These set can usually be copied from some datasheet and are represented by (minimum, typical, maximum) triplets. So drivers for display hardware would query the timings in this way, try to establish a working mode from the typical values and tweak as necessary by adjusting the values within the limits given by (minimum, maximum). One disadvantage of this is that it becomes somewhat more complicated to write the display driver, but I think that's an easy problem to solve by adding some common helpers (I'm thinking one that takes as input the target clock frequency and the timing ranges and outputs a mode with the porches adjusted to match the target clock frequency as closely as possible). The big advantage is, of course, that device trees become trivial to write and people don't have to manually stitch together timings to get to the desired result. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/fd6558a0/attachment.sig>
virglrenderer regression in commit ad4f0f1941677c
Hi - Original Message - > Hi, > > This commit in virglrenderer causes a regression in Android for me. > The parameters that get passed in are last_level = 8, width = 1. I'm > not really sure if this is valid (I'm guessing there should be some > min width?), or where I should be looking to fix this. Any ideas? > > commit ad4f0f1941677c6cd78bcd14348cd99ae7dd7527 > Author: Marc-André Lureau > Date: Tue Jan 19 14:37:50 2016 +0100 > > renderer: reject large LOD values > > Or we could sit for a very long time in some further loops. > > Fix found thanks to american fuzzy lop. > > Signed-off-by: Marc-André Lureau I don't know whether a texture of 1x1 with a LOD of 8 is valid. I remember that fix was related to invalid virgl command stream found by afl, that would be able to loop millions of iterations in some code, such as vrend_renderer_resource_create(). I wonder if you could trace it back to some client code. Also worth if there is a valid opengl reproducer, that could be a new piglit test. Btw, there is a virglrenderer mailing list: virglrenderer-devel at lists.freedesktop.org
[Bug 95427] gem_userptr_blits@mlocked-* should skip due to memory pre-condition not met
https://bugs.freedesktop.org/show_bug.cgi?id=95427 --- Comment #5 from Chris Wilson --- (In reply to Emil Velikov from comment #3) > Guys have you actually looked at the following line ? > Aperture size is 268435456 MiB -- That is 256 TiB !!! > > That's rather impossible amount if you ask me. So there's either a bug in > IGT's gem_aperture_size() or one of the two ioctls It is correct. The GTT size is 1<<48 bytes. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/b6ec0f0c/attachment.html>
[PATCH v4 7/7] drm/rockchip: Add dmc notifier in vop driver
when in ddr frequency scaling process, vop can not do
enable or disable operation, since dcf will base on vop vblank
time to do frequency scaling and need to get vop irq if there
have vop enabled. So need register to devfreq notifier, and we can
get the dmc status. Also, when there have two vop enabled, we need
to disable dmc, since dcf only base on one vop vblank time, so the
other panel will flicker when do ddr frequency scaling.
Signed-off-by: Lin Huang
---
Changes in v4:
- register notifier to devfreq_register_notifier
- use DEVFREQ_PRECHANGE and DEVFREQ_POSTCHANGE to get dmc status
- when two vop enable, disable dmc
- when two vop back to one vop, enable dmc
Changes in v3:
- when do vop eanble/disable, dmc will wait until it finish
Changes in v2:
- None
Changes in v1:
- use wait_event instead usleep
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 124 ++--
1 file changed, 119 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c179933..3b251d1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -12,6 +12,8 @@
* GNU General Public License for more details.
*/
+#include
+#include
#include
#include
#include
@@ -127,6 +129,13 @@ struct vop {
const struct vop_data *data;
+ struct devfreq *devfreq;
+ struct devfreq_event_dev *devfreq_event_dev;
+ struct notifier_block dmc_nb;
+ int dmc_in_process;
+ int vop_switch_status;
+ wait_queue_head_t wait_dmc_queue;
+ wait_queue_head_t wait_vop_switch_queue;
uint32_t *regsbak;
void __iomem *regs;
@@ -500,24 +509,60 @@ static void vop_line_flag_irq_disable(struct vop *vop)
spin_unlock_irqrestore(&vop->irq_lock, flags);
}
+static int dmc_notify(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+ struct vop *vop = container_of(nb, struct vop, dmc_nb);
+
+ if (event == DEVFREQ_PRECHANGE) {
+
+ /*
+* check if vop in enable or disable process,
+* if yes, wait until it finish, use 200ms as
+* timeout.
+*/
+ if (!wait_event_timeout(vop->wait_vop_switch_queue,
+ !vop->vop_switch_status, HZ / 5))
+ dev_warn(vop->dev,
+"Timeout waiting for vop swtich status\n");
+ vop->dmc_in_process = 1;
+ } else if (event == DEVFREQ_POSTCHANGE) {
+ vop->dmc_in_process = 0;
+ wake_up(&vop->wait_dmc_queue);
+ }
+
+ return NOTIFY_OK;
+}
+
static void vop_enable(struct drm_crtc *crtc)
{
struct vop *vop = to_vop(crtc);
+ int num_enabled_crtc = 0;
int ret;
if (vop->is_enabled)
return;
+ /*
+* if in dmc scaling frequency process, wait until it finishes
+* use 100ms as timeout time.
+*/
+ if (!wait_event_timeout(vop->wait_dmc_queue,
+ !vop->dmc_in_process, HZ / 5))
+ dev_warn(vop->dev,
+"Timeout waiting for dmc when vop enable\n");
+
+ vop->vop_switch_status = 1;
ret = pm_runtime_get_sync(vop->dev);
if (ret < 0) {
dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
- return;
+ goto err;
}
ret = clk_enable(vop->hclk);
if (ret < 0) {
dev_err(vop->dev, "failed to enable hclk - %d\n", ret);
- return;
+ goto err;
}
ret = clk_enable(vop->dclk);
@@ -531,7 +576,6 @@ static void vop_enable(struct drm_crtc *crtc)
dev_err(vop->dev, "failed to enable aclk - %d\n", ret);
goto err_disable_dclk;
}
-
/*
* Slave iommu shares power, irq and clock with vop. It was associated
* automatically with this master device via common driver code.
@@ -560,6 +604,21 @@ static void vop_enable(struct drm_crtc *crtc)
drm_crtc_vblank_on(crtc);
+ vop->vop_switch_status = 0;
+ wake_up(&vop->wait_vop_switch_queue);
+
+ /* check how many vop we use now */
+ drm_for_each_crtc(crtc, vop->drm_dev) {
+ if (crtc->state->enable)
+ num_enabled_crtc++;
+ }
+
+ /* if enable two vop, need to disable dmc */
+ if ((num_enabled_crtc > 1) && vop->devfreq) {
+ if (vop->devfreq_event_dev)
+ devfreq_event_disable_edev(vop->devfreq_event_dev);
+ devfreq_suspend_device(vop->devfreq);
+ }
return;
err_disable_aclk:
@@ -568,17 +627,33 @@ err_disable_dclk:
clk_disable(vop->dclk);
err_disable_hclk:
clk_disable(vop->hclk);
+err:
+ vop->vop_switch_status = 0;
+ w
[PATCH v4 6/7] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc
base on dfi result, we do ddr frequency scaling, register
dmc driver to devfreq framework, and use simple-ondemand
policy.
Signed-off-by: Lin Huang
---
Changes in v4:
- use arm_smccc_smc() function talk to bl31
- delete rockchip_dmc.c file and config
- delete dmc_notify
- adjust probe order
Changes in v3:
- operate dram setting through sip call
- imporve set rate flow
Changes in v2:
- None
Changes in v1:
- move dfi controller to event
- fix set voltage sequence when set rate fail
- change Kconfig type from tristate to bool
- move unuse EXPORT_SYMBOL_GPL()
drivers/devfreq/Kconfig | 1 +
drivers/devfreq/Makefile | 1 +
drivers/devfreq/rockchip/Kconfig | 8 +
drivers/devfreq/rockchip/Makefile | 1 +
drivers/devfreq/rockchip/rk3399_dmc.c | 473 ++
5 files changed, 484 insertions(+)
create mode 100644 drivers/devfreq/rockchip/Kconfig
create mode 100644 drivers/devfreq/rockchip/Makefile
create mode 100644 drivers/devfreq/rockchip/rk3399_dmc.c
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 64281bb..acb2a57 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -99,5 +99,6 @@ config ARM_TEGRA_DEVFREQ
operating frequencies and voltages with OPP support.
source "drivers/devfreq/event/Kconfig"
+source "drivers/devfreq/rockchip/Kconfig"
endif # PM_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 5134f9e..d844e23 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o
obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos/
obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos/
obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
+obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
# DEVFREQ Event Drivers
obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/
diff --git a/drivers/devfreq/rockchip/Kconfig b/drivers/devfreq/rockchip/Kconfig
new file mode 100644
index 000..d8f9e66
--- /dev/null
+++ b/drivers/devfreq/rockchip/Kconfig
@@ -0,0 +1,8 @@
+config ARM_RK3399_DMC_DEVFREQ
+ tristate "ARM RK3399 DMC DEVFREQ Driver"
+ select PM_OPP
+ select DEVFREQ_GOV_SIMPLE_ONDEMAND
+ help
+ This adds the DEVFREQ driver for the RK3399 dmc. It sets the
frequency
+ for the memory controller and reads the usage counts from hardware.
+
diff --git a/drivers/devfreq/rockchip/Makefile
b/drivers/devfreq/rockchip/Makefile
new file mode 100644
index 000..c62c105
--- /dev/null
+++ b/drivers/devfreq/rockchip/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
diff --git a/drivers/devfreq/rockchip/rk3399_dmc.c
b/drivers/devfreq/rockchip/rk3399_dmc.c
new file mode 100644
index 000..527aa11
--- /dev/null
+++ b/drivers/devfreq/rockchip/rk3399_dmc.c
@@ -0,0 +1,473 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Lin Huang
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct dram_timing {
+ unsigned int ddr3_speed_bin;
+ unsigned int pd_idle;
+ unsigned int sr_idle;
+ unsigned int sr_mc_gate_idle;
+ unsigned int srpd_lite_idle;
+ unsigned int standby_idle;
+ unsigned int dram_dll_dis_freq;
+ unsigned int phy_dll_dis_freq;
+ unsigned int ddr3_odt_dis_freq;
+ unsigned int ddr3_drv;
+ unsigned int ddr3_odt;
+ unsigned int phy_ddr3_ca_drv;
+ unsigned int phy_ddr3_dq_drv;
+ unsigned int phy_ddr3_odt;
+ unsigned int lpddr3_odt_dis_freq;
+ unsigned int lpddr3_drv;
+ unsigned int lpddr3_odt;
+ unsigned int phy_lpddr3_ca_drv;
+ unsigned int phy_lpddr3_dq_drv;
+ unsigned int phy_lpddr3_odt;
+ unsigned int lpddr4_odt_dis_freq;
+ unsigned int lpddr4_drv;
+ unsigned int lpddr4_dq_odt;
+ unsigned int lpddr4_ca_odt;
+ unsigned int phy_lpddr4_ca_drv;
+ unsigned int phy_lpddr4_ck_cs_drv;
+ unsigned int phy_lpddr4_dq_drv;
+ unsigned int phy_lpddr4_odt;
+};
+
+struct rk3399_dmcfreq {
+ struct device *dev;
+ struct devfreq *devfreq;
+ struct devfreq_simple_ondemand_data ondemand_data;
+ struct clk *dmc_clk;
+ struct devfreq_event_dev *edev;
+ struct mutex lock;
+ struct dram_timing *timing;
+ wai
[PATCH v4 5/7] PM / devfreq: event: support rockchip dfi controller
on rk3399 platform, there is dfi conroller can monitor
ddr load, base on this result, we can do ddr freqency
scaling.
Signed-off-by: Lin Huang
Acked-by: Chanwoo Choi
---
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- use clk_disable_unprepare and clk_enable_prepare
- remove clk_enable_prepare in probe
- remove rockchip_dfi_remove function
Changes in v1:
- None
drivers/devfreq/event/Kconfig| 7 +
drivers/devfreq/event/Makefile | 1 +
drivers/devfreq/event/rockchip-dfi.c | 253 +++
3 files changed, 261 insertions(+)
create mode 100644 drivers/devfreq/event/rockchip-dfi.c
diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
index a11720a..ff9279f 100644
--- a/drivers/devfreq/event/Kconfig
+++ b/drivers/devfreq/event/Kconfig
@@ -22,4 +22,11 @@ config DEVFREQ_EVENT_EXYNOS_PPMU
(Platform Performance Monitoring Unit) counters to estimate the
utilization of each module.
+config DEVFREQ_EVENT_ROCKCHIP_DFI
+ tristate "ROCKCHIP DFI DEVFREQ event Driver"
+ depends on ARCH_ROCKCHIP
+ help
+ This add the devfreq-event driver for Rockchip SoC. It provides DFI
+ (DDR Monitor Module) driver to count ddr load.
+
endif # PM_DEVFREQ_EVENT
diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
index be146ea..e3f88fc 100644
--- a/drivers/devfreq/event/Makefile
+++ b/drivers/devfreq/event/Makefile
@@ -1,2 +1,3 @@
# Exynos DEVFREQ Event Drivers
obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
+obj-$(CONFIG_DEVFREQ_EVENT_ROCKCHIP_DFI) += rockchip-dfi.o
diff --git a/drivers/devfreq/event/rockchip-dfi.c
b/drivers/devfreq/event/rockchip-dfi.c
new file mode 100644
index 000..96a0307
--- /dev/null
+++ b/drivers/devfreq/event/rockchip-dfi.c
@@ -0,0 +1,253 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Lin Huang
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RK3399_DMC_NUM_CH 2
+
+/* DDRMON_CTRL */
+#define DDRMON_CTRL0x04
+#define CLR_DDRMON_CTRL(0x1f << 0)
+#define LPDDR4_EN (0x10001 << 4)
+#define HARDWARE_EN(0x10001 << 3)
+#define LPDDR3_EN (0x10001 << 2)
+#define SOFTWARE_EN(0x10001 << 1)
+#define TIME_CNT_EN(0x10001 << 0)
+
+#define DDRMON_CH0_COUNT_NUM 0x28
+#define DDRMON_CH0_DFI_ACCESS_NUM 0x2c
+#define DDRMON_CH1_COUNT_NUM 0x3c
+#define DDRMON_CH1_DFI_ACCESS_NUM 0x40
+
+/* pmu grf */
+#define PMUGRF_OS_REG2 0x308
+#define DDRTYPE_SHIFT 13
+#define DDRTYPE_MASK 7
+
+enum {
+ DDR3 = 3,
+ LPDDR3 = 6,
+ LPDDR4 = 7,
+ UNUSED = 0xFF
+};
+
+struct dmc_usage {
+ u32 access;
+ u32 total;
+};
+
+struct rockchip_dfi {
+ struct devfreq_event_dev *edev;
+ struct devfreq_event_desc *desc;
+ struct dmc_usage ch_usage[RK3399_DMC_NUM_CH];
+ struct device *dev;
+ void __iomem *regs;
+ struct regmap *regmap_pmu;
+ struct clk *clk;
+};
+
+static void rockchip_dfi_start_hardware_counter(struct devfreq_event_dev *edev)
+{
+ struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+ void __iomem *dfi_regs = info->regs;
+ u32 val;
+ u32 ddr_type;
+
+ /* get ddr type */
+ regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, &val);
+ ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
+
+ /* clear DDRMON_CTRL setting */
+ writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
+
+ /* set ddr type to dfi */
+ if (ddr_type == LPDDR3)
+ writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
+ else if (ddr_type == LPDDR4)
+ writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
+
+ /* enable count, use software mode */
+ writel_relaxed(SOFTWARE_EN, dfi_regs + DDRMON_CTRL);
+}
+
+static void rockchip_dfi_stop_hardware_counter(struct devfreq_event_dev *edev)
+{
+ struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+ void __iomem *dfi_regs = info->regs;
+ u32 val;
+
+ val = readl_relaxed(dfi_regs + DDRMON_CTRL);
+ val &= ~SOFTWARE_EN;
+ writel_relaxed(val, dfi_regs + DDRMON_CTRL);
+}
+
+static int rockchip_dfi_get_busier_ch(struct devfreq_event_dev *edev)
+{
+ struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+ u32 tmp, max = 0;
+ u32 i, busier_ch = 0;
+
[PATCH v4 4/7] clk: rockchip: rk3399: add ddrc clock support
add ddrc clock setting, so we can do ddr frequency
scaling on rk3399 platform in future.
Signed-off-by: Lin Huang
---
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- remove clk_ddrc_dpll_src from critical clock list
Changes in v1:
- remove ddrc source CLK_IGNORE_UNUSED flag
- move clk_ddrc and clk_ddrc_dpll_src to critical
drivers/clk/rockchip/clk-rk3399.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/clk/rockchip/clk-rk3399.c
b/drivers/clk/rockchip/clk-rk3399.c
index d4a1cf0..b7b42d9 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -118,6 +118,10 @@ PNAME(mux_armclkb_p) = {
"clk_core_b_lpll_src",
"clk_core_b_bpll_src",
"clk_core_b_dpll_src",
"clk_core_b_gpll_src" };
+PNAME(mux_ddrclk_p)= { "clk_ddrc_lpll_src",
+ "clk_ddrc_bpll_src",
+ "clk_ddrc_dpll_src",
+ "clk_ddrc_gpll_src" };
PNAME(mux_aclk_cci_p) = { "cpll_aclk_cci_src",
"gpll_aclk_cci_src",
"npll_aclk_cci_src",
@@ -1377,6 +1381,18 @@ static struct rockchip_clk_branch rk3399_clk_branches[]
__initdata = {
COMPOSITE_NOMUX(0, "clk_test", "clk_test_pre", CLK_IGNORE_UNUSED,
RK3368_CLKSEL_CON(58), 0, 5, DFLAGS,
RK3368_CLKGATE_CON(13), 11, GFLAGS),
+
+ /* ddrc */
+ GATE(0, "clk_ddrc_lpll_src", "lpll", 0, RK3399_CLKGATE_CON(3),
+0, GFLAGS),
+ GATE(0, "clk_ddrc_bpll_src", "bpll", 0, RK3399_CLKGATE_CON(3),
+1, GFLAGS),
+ GATE(0, "clk_ddrc_dpll_src", "dpll", 0, RK3399_CLKGATE_CON(3),
+2, GFLAGS),
+ GATE(0, "clk_ddrc_gpll_src", "gpll", 0, RK3399_CLKGATE_CON(3),
+3, GFLAGS),
+ COMPOSITE_DDRC(SCLK_DDRCLK, "clk_ddrc", mux_ddrclk_p, 0,
+ RK3399_CLKSEL_CON(6), 4, 2, MFLAGS, 0, 3, DFLAGS),
};
static struct rockchip_clk_branch rk3399_clk_pmu_branches[] __initdata = {
@@ -1487,6 +1503,9 @@ static const char *const rk3399_cru_critical_clocks[]
__initconst = {
"gpll_hclk_perilp1_src",
"gpll_aclk_perilp0_src",
"gpll_aclk_perihp_src",
+
+ /* ddrc */
+ "clk_ddrc"
};
static const char *const rk3399_pmucru_critical_clocks[] __initconst = {
--
1.9.1
[PATCH v4 3/7] clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc
Signed-off-by: Lin Huang --- Changes in v4: -None Changes in v3: -None Changes in v2: - None Changes in v1: - None include/dt-bindings/clock/rk3399-cru.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/clock/rk3399-cru.h b/include/dt-bindings/clock/rk3399-cru.h index 50a44cf..8a0f0442 100644 --- a/include/dt-bindings/clock/rk3399-cru.h +++ b/include/dt-bindings/clock/rk3399-cru.h @@ -131,6 +131,7 @@ #define SCLK_DPHY_RX0_CFG 165 #define SCLK_RMII_SRC 166 #define SCLK_PCIEPHY_REF100M 167 +#define SCLK_DDRCLK168 #define DCLK_VOP0 180 #define DCLK_VOP1 181 -- 1.9.1
[PATCH v4 2/7] clk: rockchip: add new clock-type for the ddrclk
On new rockchip platform(rk3399 etc), there have dcf controller to
do ddr frequency scaling, and this controller will implement in
arm-trust-firmware. We add a special clock-type to handle that.
Signed-off-by: Lin Huang
---
Changes in v4:
- use arm_smccc_smc() to set/read ddr rate
Changes in v3:
- use sip call to set/read ddr rate
Changes in v2:
- use GENMASK instead val_mask
- use divider_recalc_rate() instead DIV_ROUND_UP_ULL
- cleanup code
Changes in v1:
- None
drivers/clk/rockchip/Makefile | 1 +
drivers/clk/rockchip/clk-ddr.c | 146
drivers/clk/rockchip/clk.c | 9 +++
drivers/clk/rockchip/clk.h | 27 +++
include/soc/rockchip/rockchip_sip.h | 27 +++
5 files changed, 210 insertions(+)
create mode 100644 drivers/clk/rockchip/clk-ddr.c
create mode 100644 include/soc/rockchip/rockchip_sip.h
diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index f47a2fa..b5f2c8e 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -8,6 +8,7 @@ obj-y += clk-pll.o
obj-y += clk-cpu.o
obj-y += clk-inverter.o
obj-y += clk-mmc-phase.o
+obj-y += clk-ddr.o
obj-$(CONFIG_RESET_CONTROLLER) += softrst.o
obj-y += clk-rk3036.o
diff --git a/drivers/clk/rockchip/clk-ddr.c b/drivers/clk/rockchip/clk-ddr.c
new file mode 100644
index 000..dd657c6
--- /dev/null
+++ b/drivers/clk/rockchip/clk-ddr.c
@@ -0,0 +1,146 @@
+/*
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Lin Huang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "clk.h"
+
+struct rockchip_ddrclk {
+ struct clk_hw hw;
+ void __iomem*reg_base;
+ int mux_offset;
+ int mux_shift;
+ int mux_width;
+ int mux_flag;
+ int div_shift;
+ int div_width;
+ int div_flag;
+ spinlock_t *lock;
+};
+
+#define to_rockchip_ddrclk_hw(hw) container_of(hw, struct rockchip_ddrclk, hw)
+
+static int rockchip_ddrclk_set_rate(struct clk_hw *hw, unsigned long drate,
+ unsigned long prate)
+{
+ struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+ unsigned long flags;
+ struct arm_smccc_res res;
+
+ spin_lock_irqsave(ddrclk->lock, flags);
+ arm_smccc_smc(SIP_DDR_FREQ, drate, 0, CONFIG_DRAM_SET_RATE,
+ 0, 0, 0, 0, &res);
+ spin_unlock_irqrestore(ddrclk->lock, flags);
+
+ return res.a0;
+}
+
+static unsigned long
+rockchip_ddrclk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(SIP_DDR_FREQ, 0, 0, CONFIG_DRAM_GET_RATE,
+ 0, 0, 0, 0, &res);
+
+ return res.a0;
+}
+
+static long clk_ddrclk_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ return rate;
+}
+
+static u8 rockchip_ddrclk_get_parent(struct clk_hw *hw)
+{
+ struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+ int num_parents = clk_hw_get_num_parents(hw);
+ u32 val;
+
+ val = clk_readl(ddrclk->reg_base +
+ ddrclk->mux_offset) >> ddrclk->mux_shift;
+ val &= GENMASK(ddrclk->mux_width - 1, 0);
+
+ if (val >= num_parents)
+ return -EINVAL;
+
+ return val;
+}
+
+static const struct clk_ops rockchip_ddrclk_ops = {
+ .recalc_rate = rockchip_ddrclk_recalc_rate,
+ .set_rate = rockchip_ddrclk_set_rate,
+ .round_rate = clk_ddrclk_round_rate,
+ .get_parent = rockchip_ddrclk_get_parent,
+};
+
+struct clk *rockchip_clk_register_ddrclk(const char *name, int flags,
+const char *const *parent_names,
+u8 num_parents, int mux_offset,
+int mux_shift, int mux_width,
+int mux_flag, int div_shift,
+int div_width, int div_flag,
+void __iomem *reg_base,
+spinlock_t *lock)
+{
+ struct rockchip_ddrclk *ddrclk;
+ struct clk_init_data init;
+ struct clk *clk;
+
+ ddrclk = kzalloc(sizeof(*ddrclk), GFP_KERNEL);
[PATCH v4 1/7] clk: rockchip: add clock flag parameter when register pll
From: Heiko Stübner
add clock flag parameter so we can pass specific clock flag
(like CLK_GET_RATE_NOCACHE etc..)to pll driver.
Signed-off-by: Heiko Stübner
Signed-off-by: Lin Huang
---
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- None
Changes in v1:
- None
drivers/clk/rockchip/clk-pll.c | 4 ++--
drivers/clk/rockchip/clk.c | 2 +-
drivers/clk/rockchip/clk.h | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 8ac73bc..d824c36 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -864,7 +864,7 @@ struct clk *rockchip_clk_register_pll(struct
rockchip_clk_provider *ctx,
u8 num_parents, int con_offset, int grf_lock_offset,
int lock_shift, int mode_offset, int mode_shift,
struct rockchip_pll_rate_table *rate_table,
- u8 clk_pll_flags)
+ unsigned long flags, u8 clk_pll_flags)
{
const char *pll_parents[3];
struct clk_init_data init;
@@ -919,7 +919,7 @@ struct clk *rockchip_clk_register_pll(struct
rockchip_clk_provider *ctx,
init.name = pll_name;
/* keep all plls untouched for now */
- init.flags = CLK_IGNORE_UNUSED;
+ init.flags = flags | CLK_IGNORE_UNUSED;
init.parent_names = &parent_names[0];
init.num_parents = 1;
diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
index f0a8be1..9a046f1 100644
--- a/drivers/clk/rockchip/clk.c
+++ b/drivers/clk/rockchip/clk.c
@@ -390,7 +390,7 @@ void __init rockchip_clk_register_plls(struct
rockchip_clk_provider *ctx,
list->con_offset, grf_lock_offset,
list->lock_shift, list->mode_offset,
list->mode_shift, list->rate_table,
- list->pll_flags);
+ list->flags, list->pll_flags);
if (IS_ERR(clk)) {
pr_err("%s: failed to register clock %s\n", __func__,
list->name);
diff --git a/drivers/clk/rockchip/clk.h b/drivers/clk/rockchip/clk.h
index 1abb7d0..bac775d 100644
--- a/drivers/clk/rockchip/clk.h
+++ b/drivers/clk/rockchip/clk.h
@@ -238,7 +238,7 @@ struct clk *rockchip_clk_register_pll(struct
rockchip_clk_provider *ctx,
u8 num_parents, int con_offset, int grf_lock_offset,
int lock_shift, int mode_offset, int mode_shift,
struct rockchip_pll_rate_table *rate_table,
- u8 clk_pll_flags);
+ unsigned long flags, u8 clk_pll_flags);
struct rockchip_cpuclk_clksel {
int reg;
--
1.9.1
[PATCH v4 0/7] rk3399 support ddr frequency scaling
rk3399 platform have dfi controller can monitor ddr load, and dcf controller to handle ddr register so we can get the right ddr frequency and make ddr controller happy work(which will implement in bl31). So we do ddr frequency scaling with following flow: kernelbl31 monitor ddr load | | get_target_rate | | pass rate to bl31 clk_set_rate(ddr) ->run dcf flow | | | | wait dcf interrupt<---trigger dcf interrupt | | return Lin Huang (6): clk: rockchip: add new clock-type for the ddrclk clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc clk: rockchip: rk3399: add ddrc clock support PM / devfreq: event: support rockchip dfi controller PM / devfreq: rockchip: add devfreq driver for rk3399 dmc drm/rockchip: Add dmc notifier in vop driver Heiko Stübner (1): clk: rockchip: add clock flag parameter when register pll Lin Huang (6): clk: rockchip: add new clock-type for the ddrclk clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc clk: rockchip: rk3399: add ddrc clock support PM / devfreq: event: support rockchip dfi controller PM / devfreq: rockchip: add devfreq driver for rk3399 dmc drm/rockchip: Add dmc notifier in vop driver drivers/clk/rockchip/Makefile | 1 + drivers/clk/rockchip/clk-ddr.c | 146 + drivers/clk/rockchip/clk-pll.c | 4 +- drivers/clk/rockchip/clk-rk3399.c | 19 ++ drivers/clk/rockchip/clk.c | 11 +- drivers/clk/rockchip/clk.h | 29 +- drivers/devfreq/Kconfig | 1 + drivers/devfreq/Makefile| 1 + drivers/devfreq/event/Kconfig | 7 + drivers/devfreq/event/Makefile | 1 + drivers/devfreq/event/rockchip-dfi.c| 253 +++ drivers/devfreq/rockchip/Kconfig| 8 + drivers/devfreq/rockchip/Makefile | 1 + drivers/devfreq/rockchip/rk3399_dmc.c | 473 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 124 +++- include/dt-bindings/clock/rk3399-cru.h | 1 + include/soc/rockchip/rockchip_sip.h | 27 ++ 17 files changed, 1098 insertions(+), 9 deletions(-) create mode 100644 drivers/clk/rockchip/clk-ddr.c create mode 100644 drivers/devfreq/event/rockchip-dfi.c create mode 100644 drivers/devfreq/rockchip/Kconfig create mode 100644 drivers/devfreq/rockchip/Makefile create mode 100644 drivers/devfreq/rockchip/rk3399_dmc.c create mode 100644 include/soc/rockchip/rockchip_sip.h -- 1.9.1
[v8 PATCH 6/6] drm/rockchip: cdn-dp: add cdn DP support for rk3399
Add support for cdn DP controller which is embedded in the rk3399 SoCs. The DP is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware file to /lib/firmware/rockchip/dptx.bin. The uCPU in charge of aux communication and link training, the host use mailbox to communicate with the ucpu. The dclk pin_pol of vop must not be invert for DP. Signed-off-by: Chris Zhong Reviewed-by: Sean Paul Acked-by: Mark Yao --- Changes in v8: - optimization the err log Changes in v7: - support firmware standby when no dptx connection - optimization the calculation of tu size and valid symbol Changes in v6: - add a port struct - select SND_SOC_HDMI_CODEC - force reset the phy when hpd detected Changes in v5: - alphabetical order - do not use long, use u32 or u64 - return MODE_CLOCK_HIGH when requested > actual - Optimized Coding Style - add a formula to get better tu size and symbol value. - modify according to Sean Paul's comments - fixed the fw_wait always 0 Changes in v4: - use phy framework to control DP phy - support 2 phys Changes in v3: - use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state. - reset spdif before config it - modify the firmware clk to 100Mhz - retry load firmware if fw file is requested too early Changes in v2: - Alphabetic order - remove excess error message - use define clk_rate - check all return value - remove dev_set_name(dp->dev, "cdn-dp"); - use schedule_delayed_work - remove never-called functions - remove some unnecessary () Changes in v1: - use extcon API - use hdmi-codec for the DP Asoc - do not initialize the "ret" - printk a err log when drm_of_encoder_active_endpoint_id - modify the dclk pin_pol to a single line drivers/gpu/drm/rockchip/Kconfig| 10 + drivers/gpu/drm/rockchip/Makefile | 1 + drivers/gpu/drm/rockchip/cdn-dp-core.c | 867 + drivers/gpu/drm/rockchip/cdn-dp-core.h | 103 +++ drivers/gpu/drm/rockchip/cdn-dp-reg.c | 961 drivers/gpu/drm/rockchip/cdn-dp-reg.h | 482 ++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 9 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 + 9 files changed, 2445 insertions(+), 3 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index d30bdc3..20aaafe 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -25,6 +25,16 @@ config ROCKCHIP_ANALOGIX_DP for the Analogix Core DP driver. If you want to enable DP on RK3288 based SoC, you should selet this option. +config ROCKCHIP_CDN_DP +tristate "Rockchip cdn DP" +depends on DRM_ROCKCHIP + select SND_SOC_HDMI_CODEC if SND_SOC +help + This selects support for Rockchip SoC specific extensions + for the cdn DP driver. If you want to enable Dp on + RK3399 based SoC, you should select this + option. + config ROCKCHIP_DW_HDMI tristate "Rockchip specific extensions for Synopsys DW HDMI" depends on DRM_ROCKCHIP diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index 05d0713..abdecd5 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \ rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o +obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c new file mode 100644 index 000..f47f2c3 --- /dev/null +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c @@ -0,0 +1,867 @@ +/* + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd + * Author: Chris Zhong + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include
[v8 PATCH 5/6] Documentation: bindings: add dt documentation for cdn DP controller
This patch adds a binding that describes the cdn DP controller for
rk3399.
Signed-off-by: Chris Zhong
Acked-by: Rob Herring
---
Changes in v8: None
Changes in v7: None
Changes in v6:
- add assigned-clocks and assigned-clock-rates
- add power-domains
Changes in v5: None
Changes in v4:
- add a reset node
- support 2 phys
Changes in v3:
- add SoC specific compatible string
- remove reg = <1>;
Changes in v2: None
Changes in v1:
- add extcon node description
- add #sound-dai-cells description
.../bindings/display/rockchip/cdn-dp-rockchip.txt | 74 ++
1 file changed, 74 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
diff --git
a/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
new file mode 100644
index 000..af87dcc
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/cdn-dp-rockchip.txt
@@ -0,0 +1,74 @@
+Rockchip RK3399 specific extensions to the cdn Display Port
+
+
+Required properties:
+- compatible: must be "rockchip,rk3399-cdn-dp"
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+
+- clock-names: from common clock binding:
+ Required elements: "core-clk" "pclk" "spdif"
+
+- resets : a list of phandle + reset specifier pairs
+- reset-names : string reset name, must be:
+ "spdif"
+- power-domains : power-domain property defined with a phandle
+ to respective power domain.
+- assigned-clocks: main clock, should be <&cru SCLK_DP_CORE>
+- assigned-clock-rates : the DP core clk frequency, shall be: 1
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: contain a port nodes with endpoint definitions as defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+contained 2 endpoints, connecting to the output of vop.
+
+- phys: from general PHY binding: the phandle for the PHY device.
+
+- extcon: extcon specifier for the Power Delivery
+
+- #sound-dai-cells = it must be 1 if your system is using 2 DAIs: I2S, SPDIF
+
+---
+
+Example:
+ cdn_dp: dp at fec0 {
+ compatible = "rockchip,rk3399-cdn-dp";
+ reg = <0x0 0xfec0 0x0 0x10>;
+ interrupts = ;
+ clocks = <&cru SCLK_DP_CORE>, <&cru PCLK_DP_CTRL>,
+<&cru SCLK_SPDIF_REC_DPTX>;
+ clock-names = "core-clk", "pclk", "spdif";
+ assigned-clocks = <&cru SCLK_DP_CORE>;
+ assigned-clock-rates = <1>;
+ power-domains = <&power RK3399_PD_HDCP>;
+ phys = <&tcphy0>, <&tcphy1>;
+ resets = <&cru SRST_DPTX_SPDIF_REC>;
+ reset-names = "spdif";
+ extcon = <&fusb0>, <&fusb1>;
+ rockchip,grf = <&grf>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dp_in: port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dp_in_vopb: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&vopb_out_dp>;
+ };
+
+ dp_in_vopl: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint = <&vopl_out_dp>;
+ };
+ };
+ };
+ };
--
2.6.3
[v8 PATCH 0/6] Rockchip Type-C and DisplayPort driver
Hi all This series patch is for rockchip Type-C phy and DisplayPort controller driver. The USB Type-C PHY is designed to support the USB3 and DP applications. The PHY basically has two main components: USB3 and DisplyPort. USB3 operates in SuperSpeed mode and the DP can operate at RBR, HBR and HBR2 data rates. The Type-C cable orientation detection and Power Delivery (PD) is accomplished using a PD PHY or a exernal PD chip. The DP controller is compliant with DisplayPort Specification, Version 1.3, This IP is compatible with the rockchip type-c PHY IP. There is a uCPU in DP controller, it need a firmware to work, please put the firmware file[0] to /lib/firmware/rockchip/dptx.bin. The uCPU in charge of aux communication and link training, the host use mailbox to communicate with the ucpu. The DP contoller has register a notification with extcon API, to get the alt mode from PD, the PD driver need call the devm_extcon_dev_allocate to create a extcon device and use extcon_set_state to notify DP controller. And call extcon_set_cable_property to set orientation. About the DP audio, cdn-dp registered 2 DAIs: 0 is I2S, 1 is SPDIF. We can reference them in simple-card. This series is based on Mark Yao's branch[1] and Chanwoo Choi's extcon-test branch[2]. The extcon patch is base on a test branch, so please do not review the "1/6 extcon: Add Type-C and DP support". I test this patches on the rk3399-evb board, with a fusb302 driver, this branch has no rk3399.dtsi, so the patch about dts is not included in this series. [0] https://patchwork.kernel.org/patch/9249693/ [1] https://github.com/markyzq/kernel-drm-rockchip/tree/drm-rockchip-next-2016-05-23 [2] https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/log/?h=extcon-test - extcon: Add the extcon_type to gather each connector into five category - extcon: Add the support for extcon property according to extcon type - extcon: Add the support for the capability of each property - extcon: Rename the extcon_set/get_state() to maintain the function naming pattern - extcon: Add the synchronization extcon APIs to support the notification Changes in v8: - set the default cable id to EXTCON_USB_HOST - optimization Error log - optimization the err log Changes in v7: - support new API of extcon - support firmware standby when no dptx connection - optimization the calculation of tu size and valid symbol Changes in v6: - add assigned-clocks and assigned-clock-rates - delete the support of PIN_ASSIGN_A/B - set the default mode to MODE_DFP_USB - disable DP PLL at USB3 only mode - add assigned-clocks and assigned-clock-rates - add power-domains - add a port struct - select SND_SOC_HDMI_CODEC - force reset the phy when hpd detected Changes in v5: - support get property from extcon - remove PIN ASSIGN A/B support - alphabetical order - do not use long, use u32 or u64 - return MODE_CLOCK_HIGH when requested > actual - Optimized Coding Style - add a formula to get better tu size and symbol value. - modify according to Sean Paul's comments - fixed the fw_wait always 0 Changes in v4: - add a #phy-cells node - select EXTCON - use phy framework to control the USB3 and DP function - rename PIN_MAP_ to PIN_ASSIGN_ - add a reset node - support 2 phys - use phy framework to control DP phy - support 2 phys Changes in v3: - use compatible: rockchip,rk3399-typec-phy - use dashes instead of underscores. - remove the phy framework(Kishon Vijay Abraham I) - add parentheses around the macro - use a single space between type and name - add spaces after opening and before closing braces. - use u16 for register value - remove type-c phy header file - CodingStyle optimization - use some cable extcon to get type-c port information - add a extcon to notify Display Port - add SoC specific compatible string - remove reg = <1>; - use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state. - reset spdif before config it - modify the firmware clk to 100Mhz - retry load firmware if fw file is requested too early Changes in v2: - add some registers description - select RESET_CONTROLLER - alphabetic order - modify some spelling mistakes - make mode cleaner - use bool for enable/disable - check all of the return value - return a better err number - use more readx_poll_timeout() - clk_disable_unprepare(tcphy->clk_ref); - remove unuse functions, rockchip_typec_phy_power_on/off - remove unnecessary typecast from void * - use dts node to distinguish between phys. - Alphabetic order - remove excess error message - use define clk_rate - check all return value - remove dev_set_name(dp->dev, "cdn-dp"); - use schedule_delayed_work - remove never-called functions - remove some unnecessary () Changes in v1: - add extcon node description - move the registers in phy driver - remove the suffix of reset - update the licence note - init core clock to 50MHz - use extcon API - remove unused global - add some comments for magic num - change usleep_range(1000, 2000) tousleep_range(1000, 1050) - r
[Intel-gfx] [PATCH v4 0/6] Finally fix watermarks
On Fri, 2016-07-29 at 22:26 +0300, Ville Syrjälä wrote: > On Fri, Jul 29, 2016 at 02:48:09PM -0400, Lyude wrote: > > > > So I've been working on trying to fix this entirely again (e.g. > > writing > > the ddb properly), since from bug reports it still doesn't sound > > like > > we've got enough workarounds to make this tolerable. I've shown > > this to > > matt roper, but I should probably post what I've been trying to do > > for > > you as well. > > > > So the approach I came up with is here > > > > https://github.com/lyude/linux/tree/wip/skl-fix-wms-v5r2 > > > > My approach differs a little bit from what the bspec recommends, > > but I > > think it's going to be a bit easier to implement. At the end of all > > the > > changes I'm attempting it should look like this: > > > >  * We no longer have a global watermark update for skl > >  * A new hook called "update_ddbs" is added to i915_display_funcs. > > This > >    gets called in intel_atomic_commit_tail() after we've disabled > > any > >    CRTCs that needed disabling, and before we begin > > enabling/updating > >    CRTCs > >  * Because pipe ddb allocations (not the inner-pipe ddb allocations > >    that apply to each pipe's planes) only change while > >    enabling/disabling crtcs: > >     * Pass 1: Find which pipe's new ddb allocation won't overlap > > with > >       another pipe's previous allocation, and update that pipe > > first > >     * Pass 2: Update the allocation of the remaining pipe > > > > Here's an illustration of what this looks like. Parts of the ddb > > not > > being used by any CRTCs are marked out with 'x's: > > > > With pipe A enabled, we enable pipe B: > > Initial DDB:   |      A      | > > update_ddbs:   |   A   |xxx| Pass 1 > > Enable pipe B:  |   A   |   B   | > > > > With pipes B and A active, we enable pipe C: > > > > Initial DDB:   |   B   |   A   | > > update_ddbs:   |  B  |xxx|   A   | Pass 1 > > update_ddbs:   |  B  |  A  |xxx| Pass 2 > > Enable pipe C:  |  B  |  A  |  C  | > > > > With pipes A, B, and C active, we disable B: > > Initial DDB:   |  A  |  B  |  C  | > > Disable pipe B: |  A  |xxx|  C  | > > update_ddbs:   |   A   |   C   | Pass 1 > > Since neither pipe's new allocation overlapped, we skip pass 2 > > > > Another allocation with A, B, and C active, disabling A: > > Initial DDB:   |  A  |  B  |  C  | > > Disable pipe A: |xxx|  B  |  C  | > > update_ddbs:   |   B   |xxx|  C  | Pass 1 > > update_ddbs:   |   B   |   C   | Pass 2 > > > > This should ensure we can always move around the allocations of > > pipes > > without them ever overlapping and exploding. > > That's what the current flush thing does, or at least that what it > used > to do at least. Not sure it's really doing it anymore, but I'm pretty > sure the order in which it did things was sound at some point. > > > > > > > This branch doesn't entirely fix underrun issues, but I'm mostly > > sure > > that's the fault of still not having removed the global wm update > > hook > > yet (which is leading to additional pipe flushes in places they > > shouldn't be): > > Well it should basically boil down to s/update_wm/update_ddb/ > Only DDB reallocation really warrants a global hook. Everything else > should be handled via per-crtc hooks, on all platforms. > > > > > > > https://github.com/lyude/linux/tree/wip/skl-fix-wms-v5r2 > > > > As for updating inner-pipe ddb allocations for each plane on a > > pipe, we > > should be able to just do that at the same time we update each > > pipe's > > watermarks > > Yes. > > None of that changes what I said before though. Either you need to > lock down everything when the DDB needs to be repartitioned, or you > do what I outlined in the previous mail. Otherwise a plane update > etc. happening in parallel will still blow up on account of the DDB > state changing underneath the plane update somewhere between compute > and commit. I can't really think of third option that would work. > Bleh! I didn't even realize plane updates could happen in parallel like that. Suddenly your proposal makes a lot more sense... Anyway, your method definitely sounds like the right one. Unless Matt thinks there's something that could go wrong there, I'm going to start working that into the driver and repost the patchset once I've added that into the driver. Cheers, Lyude > > > > > > Let me know what you think > > Lyude > > > > On Fri, 2016-07-29 at 12:39 +0300, Ville Syrjälä wrote: > > > > > > On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote: > > > > > > > > > > > > This is completely untested (and probably horribly > > > > broken/buggy), > > > > but > > > > here's a quick mockup of the general approach I was thinking > > > > for > >
ATPX changes in drm-next-4.8 and D3cold handling
> -Original Message- > From: Peter Wu [mailto:peter at lekensteyn.nl] > Sent: Thursday, July 28, 2016 8:00 PM > To: Lukas Wunner > Cc: Deucher, Alexander; dri-devel at lists.freedesktop.org; Christoph Haag; > Koenig, Christian; amd-gfx at lists.freedesktop.org; Zhang, Hawking > Subject: Re: ATPX changes in drm-next-4.8 and D3cold handling > > On Thu, Jul 28, 2016 at 05:40:31PM +0200, Lukas Wunner wrote: > > On Thu, Jul 28, 2016 at 03:33:25PM +, Deucher, Alexander wrote: > > > > From: Peter Wu [mailto:peter at lekensteyn.nl] > > > > Sent: Thursday, July 21, 2016 6:43 AM > > > > In case you missed it, Dave's D3cold patches were succeeded by > changes > > > > in PCI core. Relevant commits in the pci/pm branch: > > > > > > > > 006d44e PCI: Add runtime PM support for PCIe ports > > > > 16468c7 ACPI / hotplug / PCI: Runtime resume bridge before rescan > > > > d963f65 PCI: Power on bridges before scanning new devices > > > > 9d26d3a PCI: Put PCIe ports into D3 during suspend > > > > 43f7f88 PCI: Don't clear d3cold_allowed for PCIe ports > > > > > > Did those get merged yet? > > > > They will go into 4.8. Should have gone into 4.7 already but were > > dropped at the last minute. > > > > > > > I just need to revert this commit once the d3cold patches land: > > > https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next- > 4.8&id=bdfb76040068d960cb9e226876be8a508d741c4a > > > > So you probably need to revert this now. > > > > Best regards, > > Lukas > > It is better to revert it before the PCI/PM patches get merged, > otherwise you risk that the device is already put in D3 before the > bridge tries to do it again. This is currently happening with nouveau on > -next. > > Do these AMD hw exist on BIOSes pre-2015? Currently the D3cold work in > the PCI/PM branch only enable the D3cold handling via the bridge when > the BIOS is >= 2015. Systems designed for windows 10 use d3 cold rather than the legacy interfaces. Setting the ACPI OSI to windows10 will enable d3cold, setting it to a previous version of windows will use the old method. At least on AMD PX systems there is a bit in the ATPX information block that indicates the current setting hybrid graphics (aka d3cold) or the ATPX power control for dGPU power control. Alex > -- > Kind regards, > Peter Wu > https://lekensteyn.nl
[PATCH 2/2] drm: mali-dp: Set the drm->irq_enabled flag to match driver's state.
Mali DP driver does not use drm_irq_{un,}install() function so the
drm->irq_enabled flag does not get managed automatically. Among other
DRM framework functions, drm_wait_vblank() checks the value of the
flag and return -EINVAL if not set.
Cc: Brian Starkey
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 87c9249..a1c01e4 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -377,6 +377,8 @@ static int malidp_bind(struct device *dev)
if (ret < 0)
goto irq_init_fail;
+ drm->irq_enabled = true;
+
ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
if (ret < 0) {
DRM_ERROR("failed to initialise vblank\n");
@@ -402,6 +404,7 @@ fbdev_fail:
vblank_fail:
malidp_se_irq_fini(drm);
malidp_de_irq_fini(drm);
+ drm->irq_enabled = false;
irq_init_fail:
component_unbind_all(dev, drm);
bind_fail:
@@ -439,6 +442,7 @@ static void malidp_unbind(struct device *dev)
drm_kms_helper_poll_fini(drm);
malidp_se_irq_fini(drm);
malidp_de_irq_fini(drm);
+ drm->irq_enabled = false;
drm_vblank_cleanup(drm);
component_unbind_all(dev, drm);
of_node_put(malidp->crtc.port);
--
2.9.0
[PATCH 1/2] drm: mali-dp: Clear the config_valid flag before using it in wait_event.
config_valid variable is used to signal the activation of the CVAL request when the vsync interrupt has fired. malidp_set_and_wait_config_valid() uses the variable in wait_event_interruptible_timeout without clearing it first, so the wait is skipped. Cc: Brian Starkey Signed-off-by: Liviu Dudau --- drivers/gpu/drm/arm/malidp_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index 82171d2..87c9249 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -42,6 +42,7 @@ static int malidp_set_and_wait_config_valid(struct drm_device *drm) struct malidp_hw_device *hwdev = malidp->dev; int ret; + atomic_set(&malidp->config_valid, 0); hwdev->set_config_valid(hwdev); /* don't wait for config_valid flag if we are in config mode */ if (hwdev->in_config_mode(hwdev)) -- 2.9.0
Cleanup patches for mali-dp driver
Hi, A couple of patches to fix issues that I have discovered during the development of more Mali DP features :) I would like to take these patches through drm-misc and don't go through the mali-dp tree as I will be going on holiday for a month. If anyone has patches for Mali DP driver (or HDLCD to an extent) please Cc Brian Starkey or use the formal Mali DP mailing list. Many thanks, Liviu
[PATCH -next] drm/amdgpu: use kmemdup rather than duplicating its implementation
On Fri, Jul 29, 2016 at 3:38 PM, Deucher, Alexander wrote: >> -Original Message- >> From: Sean Paul [mailto:seanpaul at google.com] >> Sent: Friday, July 29, 2016 3:35 PM >> To: Wei Yongjun >> Cc: Deucher, Alexander; Koenig, Christian; Dave Airlie; Jiang, Sonny; Liu, >> Leo; >> Nath, Arindam; Zhou, David(ChunMing); Zhou, Jammy; Liu, Monk; dri-devel; >> Linux Kernel Mailing List >> Subject: Re: [PATCH -next] drm/amdgpu: use kmemdup rather than >> duplicating its implementation >> >> On Thu, Jul 28, 2016 at 12:18 PM, Wei Yongjun wrote: >> > Use kmemdup rather than duplicating its implementation. >> > >> > Generated by: scripts/coccinelle/api/memdup.cocci >> > >> > Signed-off-by: Wei Yongjun >> >> >> Thanks for the patch. I'll apply this to -misc once the merge window is >> closed. >> >> Acked-by: Sean Paul > > Unless you've already applied this to the misc tree, I'd prefer to take it > via the amdgpu tree. > Nope, it's all yours. Sean > Alex > >> >> >> > --- >> > drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +--- >> > 1 file changed, 1 insertion(+), 3 deletions(-) >> > >> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c >> > index a46a64c..b779b5f 100644 >> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c >> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c >> > @@ -296,12 +296,10 @@ int amdgpu_uvd_suspend(struct amdgpu_device >> *adev) >> > size = amdgpu_bo_size(adev->uvd.vcpu_bo); >> > ptr = adev->uvd.cpu_addr; >> > >> > - adev->uvd.saved_bo = kmalloc(size, GFP_KERNEL); >> > + adev->uvd.saved_bo = kmemdup(ptr, size, GFP_KERNEL); >> > if (!adev->uvd.saved_bo) >> > return -ENOMEM; >> > >> > - memcpy(adev->uvd.saved_bo, ptr, size); >> > - >> > return 0; >> > } >> > >> > >> > >> >
[PATCH -next] drm/amdgpu: use kmemdup rather than duplicating its implementation
On Thu, Jul 28, 2016 at 12:18 PM, Wei Yongjun wrote: > Use kmemdup rather than duplicating its implementation. > > Generated by: scripts/coccinelle/api/memdup.cocci > > Signed-off-by: Wei Yongjun Thanks for the patch. I'll apply this to -misc once the merge window is closed. Acked-by: Sean Paul > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c > index a46a64c..b779b5f 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c > @@ -296,12 +296,10 @@ int amdgpu_uvd_suspend(struct amdgpu_device *adev) > size = amdgpu_bo_size(adev->uvd.vcpu_bo); > ptr = adev->uvd.cpu_addr; > > - adev->uvd.saved_bo = kmalloc(size, GFP_KERNEL); > + adev->uvd.saved_bo = kmemdup(ptr, size, GFP_KERNEL); > if (!adev->uvd.saved_bo) > return -ENOMEM; > > - memcpy(adev->uvd.saved_bo, ptr, size); > - > return 0; > } > > > >
[Intel-gfx] [PATCH v2] drm: BIT(DRM_ROTATE_?) -> DRM_ROTATE_?
On Fri, Jul 29, 2016 at 08:50:05AM +0300, Joonas Lahtinen wrote:
> Only property creation uses the rotation as an index, so convert the
> to figure the index when needed.
>
> v2: Use the new defines to build the _MASK defines (Sean)
>
> Cc: intel-gfx at lists.freedesktop.org
> Cc: linux-arm-msm at vger.kernel.org
> Cc: freedreno at lists.freedesktop.org
> Cc: malidp at foss.arm.com
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Liviu Dudau
> Cc: Sean Paul
> Acked-by: Liviu Dudau
> Reviewed-by: Ville Syrjälä (v1)
> Signed-off-by: Joonas Lahtinen
Thanks for respinning this, Joonas. I've added this to my queue for -misc after
the merge window is closed.
Acked-by: Sean Paul
> ---
> drivers/gpu/drm/arm/malidp_drv.h| 2 +-
> drivers/gpu/drm/arm/malidp_planes.c | 20 +-
> drivers/gpu/drm/armada/armada_overlay.c | 2 +-
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 22 +--
> drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
> drivers/gpu/drm/drm_crtc.c | 24 ++---
> drivers/gpu/drm/drm_fb_helper.c | 4 ++--
> drivers/gpu/drm/drm_plane_helper.c | 2 +-
> drivers/gpu/drm/drm_rect.c | 28
> -
> drivers/gpu/drm/i915/i915_debugfs.c | 12 +--
> drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
> drivers/gpu/drm/i915/intel_display.c| 28
> -
> drivers/gpu/drm/i915/intel_drv.h| 2 +-
> drivers/gpu/drm/i915/intel_fbc.c| 2 +-
> drivers/gpu/drm/i915/intel_fbdev.c | 6 +++---
> drivers/gpu/drm/i915/intel_sprite.c | 6 +++---
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 10 -
> drivers/gpu/drm/omapdrm/omap_drv.c | 6 +++---
> drivers/gpu/drm/omapdrm/omap_fb.c | 14 ++---
> drivers/gpu/drm/omapdrm/omap_plane.c| 10 -
> include/drm/drm_crtc.h | 17 ---
> 21 files changed, 112 insertions(+), 111 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.h
> b/drivers/gpu/drm/arm/malidp_drv.h
> index 95558fd..271d2fb 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.h
> +++ b/drivers/gpu/drm/arm/malidp_drv.h
> @@ -49,6 +49,6 @@ void malidp_de_planes_destroy(struct drm_device *drm);
> int malidp_crtc_init(struct drm_device *drm);
>
> /* often used combination of rotational bits */
> -#define MALIDP_ROTATED_MASK (BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_270))
> +#define MALIDP_ROTATED_MASK (DRM_ROTATE_90 | DRM_ROTATE_270)
>
> #endif /* __MALIDP_DRV_H__ */
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 725098d..82c193e 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -108,7 +108,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
> return -EINVAL;
>
> /* packed RGB888 / BGR888 can't be rotated or flipped */
> - if (state->rotation != BIT(DRM_ROTATE_0) &&
> + if (state->rotation != DRM_ROTATE_0 &&
> (state->fb->pixel_format == DRM_FORMAT_RGB888 ||
>state->fb->pixel_format == DRM_FORMAT_BGR888))
> return -EINVAL;
> @@ -188,9 +188,9 @@ static void malidp_de_plane_update(struct drm_plane
> *plane,
> /* setup the rotation and axis flip bits */
> if (plane->state->rotation & DRM_ROTATE_MASK)
> val = ilog2(plane->state->rotation & DRM_ROTATE_MASK) <<
> LAYER_ROT_OFFSET;
> - if (plane->state->rotation & BIT(DRM_REFLECT_X))
> + if (plane->state->rotation & DRM_REFLECT_X)
> val |= LAYER_V_FLIP;
> - if (plane->state->rotation & BIT(DRM_REFLECT_Y))
> + if (plane->state->rotation & DRM_REFLECT_Y)
> val |= LAYER_H_FLIP;
>
> /* set the 'enable layer' bit */
> @@ -255,12 +255,12 @@ int malidp_de_planes_init(struct drm_device *drm)
> goto cleanup;
>
> if (!drm->mode_config.rotation_property) {
> - unsigned long flags = BIT(DRM_ROTATE_0) |
> - BIT(DRM_ROTATE_90) |
> - BIT(DRM_ROTATE_180) |
> - BIT(DRM_ROTATE_270) |
> - BIT(DRM_REFLECT_X) |
> - BIT(DRM_REFLECT_Y);
> + unsigned long flags = DRM_ROTATE_0 |
> + DRM_ROTATE_90 |
> + DRM_ROTATE_180 |
> + DRM_ROTATE_270 |
> + DRM_REFLECT_X |
> + DRM_REFLECT_Y;
> drm->mode_confi
[PATCH v3] drm/atomic-helper: Add atomic_mode_set helper callback
On Fri, Jul 29, 2016 at 03:20:04PM +0200, Philipp Zabel wrote:
> Some encoders need more information from crtc and connector state or
> connector display info than just the mode during mode setting. This
> patch adds an atomic encoder mode setting variant that passes the crtc
> state (which contains the modes) and the connector state.
>
> atomic_enable/disable variants that additionally pass crtc and connector
> state don't seem to be necessary for any current driver. mode_fixup
> already has an atomic equivalent in atomic_check.
>
> Signed-off-by: Philipp Zabel
lgtm. Reviewed-by: Daniel Vetter
Also it probably makes sense to pull this in through your driver tree, so
Ack for merging through that. But please send out a pull request for
drm-next latest by -rc2 to avoid conflicts. There's other people who might
need these atomic_ versions of the hooks (I'm chatting with Ben Skeggs
about some similar problems he has in the nouveau conversion).
Thanks, Daniel
> ---
> Changes since v2:
> - Removed atomic_enable and atomic_disable hooks again, they are not useful
>to anyone for now
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 6 +-
> include/drm/drm_modeset_helper_vtables.h | 29 +
> 2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index de7fddc..a3c033f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -880,8 +880,12 @@ crtc_set_mode(struct drm_device *dev, struct
> drm_atomic_state *old_state)
>* Each encoder has at most one connector (since we always steal
>* it away), so we won't call mode_set hooks twice.
>*/
> - if (funcs && funcs->mode_set)
> + if (funcs && funcs->atomic_mode_set) {
> + funcs->atomic_mode_set(encoder, new_crtc_state,
> +connector->state);
> + } else if (funcs && funcs->mode_set) {
> funcs->mode_set(encoder, mode, adjusted_mode);
> + }
>
> drm_bridge_mode_set(encoder->bridge, mode, adjusted_mode);
> }
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> index b55f218..686feec 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -523,12 +523,41 @@ struct drm_encoder_helper_funcs {
>*
>* This callback is used both by the legacy CRTC helpers and the atomic
>* modeset helpers. It is optional in the atomic helpers.
> + *
> + * NOTE:
> + *
> + * If the driver uses the atomic modeset helpers and needs to inspect
> + * the connector state or connector display info during mode setting,
> + * @atomic_mode_set can be used instead.
>*/
> void (*mode_set)(struct drm_encoder *encoder,
>struct drm_display_mode *mode,
>struct drm_display_mode *adjusted_mode);
>
> /**
> + * @atomic_mode_set:
> + *
> + * This callback is used to update the display mode of an encoder.
> + *
> + * Note that the display pipe is completely off when this function is
> + * called. Drivers which need hardware to be running before they program
> + * the new display mode (because they implement runtime PM) should not
> + * use this hook, because the helper library calls it only once and not
> + * every time the display pipeline is suspended using either DPMS or the
> + * new "ACTIVE" property. Such drivers should instead move all their
> + * encoder setup into the ->enable() callback.
> + *
> + * This callback is used by the atomic modeset helpers in place of the
> + * @mode_set callback, if set by the driver. It is optional and should
> + * be used instead of @mode_set if the driver needs to inspect the
> + * connector state or display info, since there is no direct way to
> + * go from the encoder to the current connector.
> + */
> + void (*atomic_mode_set)(struct drm_encoder *encoder,
> + struct drm_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state);
> +
> + /**
>* @get_crtc:
>*
>* This callback is used by the legacy CRTC helpers to work around
> --
> 2.8.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PULL REQUEST] Generic zpos property
Hello Dave, This pull request is for z-pos feature. It include generic code for new z-pos property and functions to normalize it (in a new file named drm_blend.c) Three drivers (exynos, rcard-du and sti) have been modified to take benefit of this generic implementation of z-order. I have to warn you that thoses commits are rebased on top of drm-next branch where git://linuxtv.org/media_tree.git vsp1 branch has been merged. The following changes since commit 62c2cd0f49333a2bb53602ec23039ca99a19cb9d: Merge remote-tracking branch 'media_tree/vsp1' into generic-zpos-v8 (2016-07-29 09:38:55 +0200) are available in the git repository at: http://git.linaro.org/people/benjamin.gaignard/kernel.git generic-zpos-v8 for you to fetch changes up to 2fc4d838aaf2607216eda5ce9dba18fa14422a31: drm: rcar: use generic code for managing zpos plane property (2016-07-29 10:03:10 +0200) Benjamin Gaignard (2): drm: sti: use generic zpos for plane drm: rcar: use generic code for managing zpos plane property Marek Szyprowski (2): drm: add generic zpos property drm/exynos: use generic code for managing zpos plane property Documentation/gpu/kms-properties.csv | 1 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic.c | 4 + drivers/gpu/drm/drm_atomic_helper.c | 7 + drivers/gpu/drm/drm_blend.c | 238 ++ drivers/gpu/drm/drm_crtc_internal.h | 4 + drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 - drivers/gpu/drm/exynos/exynos_drm_plane.c | 67 ++--- drivers/gpu/drm/exynos/exynos_mixer.c | 6 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 2 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 - drivers/gpu/drm/rcar-du/rcar_du_kms.c | 5 - drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 +- drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 - drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 14 +- drivers/gpu/drm/sti/sti_cursor.c | 4 +- drivers/gpu/drm/sti/sti_gdp.c | 4 +- drivers/gpu/drm/sti/sti_hqvdp.c | 4 +- drivers/gpu/drm/sti/sti_mixer.c | 9 +- drivers/gpu/drm/sti/sti_plane.c | 78 -- drivers/gpu/drm/sti/sti_plane.h | 7 +- include/drm/drm_crtc.h| 20 +++ 22 files changed, 334 insertions(+), 156 deletions(-) create mode 100644 drivers/gpu/drm/drm_blend.c
[PATCH] drm/imx: Remove imx_drm_handle_vblank()
Am Freitag, den 29.07.2016, 14:00 +0800 schrieb Liu Ying: > imx_drm_handle_vblank() is just a simple wrapper of drm_crtc_handle_vblank() > without doing any thing fancy - drm_crtc_handle_vblank() can be called > directly. So, let's remove the wrapper. > > Signed-off-by: Liu Ying Applied, thank you. regards Philipp
[PATCH v3] drm/atomic-helper: Add atomic_mode_set helper callback
Some encoders need more information from crtc and connector state or
connector display info than just the mode during mode setting. This
patch adds an atomic encoder mode setting variant that passes the crtc
state (which contains the modes) and the connector state.
atomic_enable/disable variants that additionally pass crtc and connector
state don't seem to be necessary for any current driver. mode_fixup
already has an atomic equivalent in atomic_check.
Signed-off-by: Philipp Zabel
---
Changes since v2:
- Removed atomic_enable and atomic_disable hooks again, they are not useful
to anyone for now
---
drivers/gpu/drm/drm_atomic_helper.c | 6 +-
include/drm/drm_modeset_helper_vtables.h | 29 +
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index de7fddc..a3c033f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -880,8 +880,12 @@ crtc_set_mode(struct drm_device *dev, struct
drm_atomic_state *old_state)
* Each encoder has at most one connector (since we always steal
* it away), so we won't call mode_set hooks twice.
*/
- if (funcs && funcs->mode_set)
+ if (funcs && funcs->atomic_mode_set) {
+ funcs->atomic_mode_set(encoder, new_crtc_state,
+ connector->state);
+ } else if (funcs && funcs->mode_set) {
funcs->mode_set(encoder, mode, adjusted_mode);
+ }
drm_bridge_mode_set(encoder->bridge, mode, adjusted_mode);
}
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index b55f218..686feec 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -523,12 +523,41 @@ struct drm_encoder_helper_funcs {
*
* This callback is used both by the legacy CRTC helpers and the atomic
* modeset helpers. It is optional in the atomic helpers.
+*
+* NOTE:
+*
+* If the driver uses the atomic modeset helpers and needs to inspect
+* the connector state or connector display info during mode setting,
+* @atomic_mode_set can be used instead.
*/
void (*mode_set)(struct drm_encoder *encoder,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
/**
+* @atomic_mode_set:
+*
+* This callback is used to update the display mode of an encoder.
+*
+* Note that the display pipe is completely off when this function is
+* called. Drivers which need hardware to be running before they program
+* the new display mode (because they implement runtime PM) should not
+* use this hook, because the helper library calls it only once and not
+* every time the display pipeline is suspended using either DPMS or the
+* new "ACTIVE" property. Such drivers should instead move all their
+* encoder setup into the ->enable() callback.
+*
+* This callback is used by the atomic modeset helpers in place of the
+* @mode_set callback, if set by the driver. It is optional and should
+* be used instead of @mode_set if the driver needs to inspect the
+* connector state or display info, since there is no direct way to
+* go from the encoder to the current connector.
+*/
+ void (*atomic_mode_set)(struct drm_encoder *encoder,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state);
+
+ /**
* @get_crtc:
*
* This callback is used by the legacy CRTC helpers to work around
--
2.8.1
[PATCH] drm/analogix_dp: Ensure the panel is properly prepared/unprepared
Instead of just preparing the panel on bind, actually prepare/unprepare
during modeset/disable. The panel must be prepared in order to read hpd
status, so we need to refcount the prepares in order to ensure we don't
accidentally turn the panel off at the wrong time.
Signed-off-by: Sean Paul
---
Hi Yakir,
This is what I was talking about upthread. I've tested it and it seems to be
working.
What do you think?
Sean
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 48 +-
1 file changed, 37 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 32715da..7b764a4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -960,11 +960,27 @@ enum drm_connector_status
analogix_dp_detect(struct drm_connector *connector, bool force)
{
struct analogix_dp_device *dp = to_dp(connector);
+ enum drm_connector_status status = connector_status_disconnected;
+ int ret;
- if (analogix_dp_detect_hpd(dp))
- return connector_status_disconnected;
+ if (dp->plat_data->panel && dp->dpms_mode != DRM_MODE_DPMS_ON) {
+ ret = drm_panel_prepare(dp->plat_data->panel);
+ if (ret) {
+ DRM_ERROR("failed to setup panel (%d)\n", ret);
+ return connector_status_disconnected;
+ }
+ }
+
+ if (!analogix_dp_detect_hpd(dp))
+ status = connector_status_connected;
+
+ if (dp->plat_data->panel && dp->dpms_mode != DRM_MODE_DPMS_ON) {
+ ret = drm_panel_unprepare(dp->plat_data->panel);
+ if (ret)
+ DRM_ERROR("failed to setup the panel ret = %d\n", ret);
+ }
- return connector_status_connected;
+ return status;
}
static void analogix_dp_connector_destroy(struct drm_connector *connector)
@@ -1035,6 +1051,18 @@ static int analogix_dp_bridge_attach(struct drm_bridge
*bridge)
return 0;
}
+static void analogix_dp_bridge_pre_enable(struct drm_bridge *bridge)
+{
+ struct analogix_dp_device *dp = bridge->driver_private;
+ int ret;
+
+ if (dp->plat_data->panel) {
+ ret = drm_panel_prepare(dp->plat_data->panel);
+ if (ret)
+ DRM_ERROR("failed to setup the panel ret = %d\n", ret);
+ }
+}
+
static void analogix_dp_bridge_enable(struct drm_bridge *bridge)
{
struct analogix_dp_device *dp = bridge->driver_private;
@@ -1058,6 +1086,7 @@ static void analogix_dp_bridge_enable(struct drm_bridge
*bridge)
static void analogix_dp_bridge_disable(struct drm_bridge *bridge)
{
struct analogix_dp_device *dp = bridge->driver_private;
+ int ret;
if (dp->dpms_mode != DRM_MODE_DPMS_ON)
return;
@@ -1077,6 +1106,10 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
pm_runtime_put_sync(dp->dev);
+ ret = drm_panel_unprepare(dp->plat_data->panel);
+ if (ret)
+ DRM_ERROR("failed to setup the panel ret = %d\n", ret);
+
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
@@ -1165,9 +1198,9 @@ static void analogix_dp_bridge_nop(struct drm_bridge
*bridge)
}
static const struct drm_bridge_funcs analogix_dp_bridge_funcs = {
+ .pre_enable = analogix_dp_bridge_pre_enable,
.enable = analogix_dp_bridge_enable,
.disable = analogix_dp_bridge_disable,
- .pre_enable = analogix_dp_bridge_nop,
.post_disable = analogix_dp_bridge_nop,
.mode_set = analogix_dp_bridge_mode_set,
.attach = analogix_dp_bridge_attach,
@@ -1333,13 +1366,6 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
phy_power_on(dp->phy);
- if (dp->plat_data->panel) {
- if (drm_panel_prepare(dp->plat_data->panel)) {
- DRM_ERROR("failed to setup the panel\n");
- return -EBUSY;
- }
- }
-
analogix_dp_init_dp(dp);
ret = devm_request_threaded_irq(&pdev->dev, dp->irq,
--
2.8.0.rc3.226.g39d4020
[Bug 96721] radeon: unable to handle kernel paging request with counter strike: go
https://bugzilla.kernel.org/show_bug.cgi?id=96721 --- Comment #1 from Christoph Haag --- Created attachment 226841 --> https://bugzilla.kernel.org/attachment.cgi?id=226841&action=edit dmesg with stacktrace used for getting line numbers With 4.7 it's still happening. I finally built a kernel with debug symbols because on Intel graphics I also have something like this... I assume people have looked at the functions, but maybe some line numbers for the 4.7.0 release help. BUG: unable to handle kernel paging request at 80048f666920 IP: [] ttm_bo_del_from_lru+0x92/0xb0 [ttm] Line 89 of "include/linux/list.h" ... Call Trace: [] ttm_eu_reserve_buffers+0x2b9/0x370 [ttm] Line 53 of "drivers/gpu/drm/ttm/ttm_execbuf_util.c" [] radeon_bo_list_validate+0xa0/0x220 [radeon] Line 532 of "drivers/gpu/drm/radeon/radeon_object.c" [] ? __kmalloc+0x3d/0x240 [] radeon_cs_parser_relocs+0x356/0x440 [radeon] Line 187 of "drivers/gpu/drm/radeon/radeon_cs.c" [] radeon_cs_ioctl+0x28a/0x7c0 [radeon] Line 675 of "drivers/gpu/drm/radeon/radeon_cs.c" [] drm_ioctl+0x15e/0x550 [drm] [] ? futex_wake+0x9f/0x180 [] ? radeon_cs_parser_init+0x4f0/0x4f0 [radeon] [] ? do_futex+0x2f5/0xc10 [] radeon_drm_ioctl+0x62/0xa0 [radeon] [] do_vfs_ioctl+0xb2/0x5e0 [] ? __schedule+0x304/0x7b0 [] ? __fget+0x8a/0xc0 [] SyS_ioctl+0x88/0xa0 [] entry_SYSCALL_64_fastpath+0x1a/0xa4 -- You are receiving this mail because: You are watching the assignee of the bug.
virglrenderer regression in commit ad4f0f1941677c
Hi, This commit in virglrenderer causes a regression in Android for me. The parameters that get passed in are last_level = 8, width = 1. I'm not really sure if this is valid (I'm guessing there should be some min width?), or where I should be looking to fix this. Any ideas? commit ad4f0f1941677c6cd78bcd14348cd99ae7dd7527 Author: Marc-André Lureau Date: Tue Jan 19 14:37:50 2016 +0100 renderer: reject large LOD values Or we could sit for a very long time in some further loops. Fix found thanks to american fuzzy lop. Signed-off-by: Marc-André Lureau Thanks, Rob
[Intel-gfx] [PATCH v4 0/6] Finally fix watermarks
So I've been working on trying to fix this entirely again (e.g. writing the ddb properly), since from bug reports it still doesn't sound like we've got enough workarounds to make this tolerable. I've shown this to matt roper, but I should probably post what I've been trying to do for you as well. So the approach I came up with is here https://github.com/lyude/linux/tree/wip/skl-fix-wms-v5r2 My approach differs a little bit from what the bspec recommends, but I think it's going to be a bit easier to implement. At the end of all the changes I'm attempting it should look like this: * We no longer have a global watermark update for skl * A new hook called "update_ddbs" is added to i915_display_funcs. This gets called in intel_atomic_commit_tail() after we've disabled any CRTCs that needed disabling, and before we begin enabling/updating CRTCs * Because pipe ddb allocations (not the inner-pipe ddb allocations that apply to each pipe's planes) only change while enabling/disabling crtcs: * Pass 1: Find which pipe's new ddb allocation won't overlap with another pipe's previous allocation, and update that pipe first * Pass 2: Update the allocation of the remaining pipe Here's an illustration of what this looks like. Parts of the ddb not being used by any CRTCs are marked out with 'x's: With pipe A enabled, we enable pipe B: Initial DDB:   |      A      | update_ddbs:   |   A   |xxx| Pass 1 Enable pipe B:  |   A   |   B   | With pipes B and A active, we enable pipe C: Initial DDB:   |   B   |   A   | update_ddbs:   |  B  |xxx|   A   | Pass 1 update_ddbs:   |  B  |  A  |xxx| Pass 2 Enable pipe C:  |  B  |  A  |  C  | With pipes A, B, and C active, we disable B: Initial DDB:   |  A  |  B  |  C  | Disable pipe B: |  A  |xxx|  C  | update_ddbs:   |   A   |   C   | Pass 1 Since neither pipe's new allocation overlapped, we skip pass 2 Another allocation with A, B, and C active, disabling A: Initial DDB:   |  A  |  B  |  C  | Disable pipe A: |xxx|  B  |  C  | update_ddbs:   |   B   |xxx|  C  | Pass 1 update_ddbs:   |   B   |   C   | Pass 2 This should ensure we can always move around the allocations of pipes without them ever overlapping and exploding. This branch doesn't entirely fix underrun issues, but I'm mostly sure that's the fault of still not having removed the global wm update hook yet (which is leading to additional pipe flushes in places they shouldn't be): https://github.com/lyude/linux/tree/wip/skl-fix-wms-v5r2 As for updating inner-pipe ddb allocations for each plane on a pipe, we should be able to just do that at the same time we update each pipe's watermarks Let me know what you think Lyude On Fri, 2016-07-29 at 12:39 +0300, Ville Syrjälä wrote: > On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote: > > > > This is completely untested (and probably horribly broken/buggy), > > but > > here's a quick mockup of the general approach I was thinking for > > ensuring DDB & WM's can be updated together while ensuring the > > three-step pipe flushing process is honored: > > > >         https://github.com/mattrope/kernel/commits/experimental/lyu > > de_ddb > > > > Basically the idea is to take note of what's happening to the > > pipe's DDB > > allocation (shrinking, growing, unchanged, etc.) during the atomic > > check > > phase; > > Didn't look too closely, but I think you can't actually do that > unless > you lock all the crtcs whenever the number of active pipes is goind > to > change. Meaning we'd essentially be back to the one-big-modeset-lock > apporach, which will cause missed flips and whanot on the other > pipes. > > The alternative I think would consist of: > - make sure level 0 watermark never exceeds total_ddb_size/max_pipes, >  so that a modeset doesn't have to care about the wms for the other >  pipes not fitting in > - level 1+ watermarks would be checked against total_ddb_size > - protect the plane/pipe commit with the wm mutex whenever the wms >  need to be reprogrammed > - keep the flush_wm thing around for the case when ddb size does get >  changed, protect it with the wm lock > - when programming wms, we will first filter out any level that >  doesn't fit in with the current ddb size, and then program the >  rest in > - potentially introduce per-pipe wm locks if the one big lock looks >  like an issue, which it might if the flush_wm holds it all the way >  through > > > > > then during the commit phase, we loop over the CRTC's three times > > instead of just once, but only operate on a subset of the CRTC's in > > each > > loop.  While operating on each CRTC, the plane, WM, and DDB all get > > programmed together and have a single flush for all three. > > > > > > > > > > Mat
[pull] radeon and amdgpu drm-next-4.8
Hi Dave, A few more patches for amdgpu and radeon for 4.8. The big change is the additional power feature enablement for polaris that was pending the 4.7 back merge. The rest are mainly bug fixes and cleanups. The following changes since commit 162b20d2f9ef9dfa833cc329b1e8957beb672349: Merge branch 'drm-next-4.8' of git://people.freedesktop.org/~agd5f/linux into drm-next (2016-07-28 05:51:39 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.8 for you to fetch changes up to d4ccb71d7abbceb438b2b55c0606b14fb03f01df: drm/amd/powerplay: remove enable_clock_power_gatings_tasks from initialize and resume events (2016-07-29 14:37:13 -0400) Alex Deucher (6): drm/radeon: fix firmware info version checks drm/amdgpu: fix firmware info version checks drm/amdgpu: init atpx at switcheroo register time (v2) drm/radeon: init atpx at switcheroo register time v2 drm/radeon: drop confusing message about backlight control drm/amdgpu/powerplay: partial revert of endian fixes Bhaktipriya Shridhar (1): drm/radeon: Remove deprecated create_singlethread_workqueue Christian König (13): drm/amdgpu: implement UVD VM mode for Stoney v2 drm/amdgpu: increment driver minor drm/amdgpu: fix indentation in struct amdgpu_ring drm/amdgpu: remove fence_lock drm/amdgpu: add begin/end_use ring callbacks drm/amdgpu: use begin/end_use for UVD power/clock gating drm/amdgpu: use begin/end_use for VCE power/clock gating drm/amdgpu: move UVD IB test into common code v2 drm/amdgpu: add a fence timeout for the IB tests v2 drm/ttm: partial revert "cleanup ttm_tt_(unbind|destroy)" v3 drm/amdgpu: enable UVD VM only on polaris drm/amdgpu: fix default UVD context size drm/amdgpu: enable UVD context buffer for older HW Chunming Zhou (3): drm/amd: reset hw count when reset job drm/amd: fix deadlock of job_list_lock V2 drm/amdgpu: increase timeout of IB test Edward O'Callaghan (7): drivers/amdgpu: Remove spurious semicolons drivers/amdgpu: Use 'true/false' for bool typed variables drivers/amdgpu: Use canonical form in branch predicates drivers/amdgpu: Remove redundant NULL check before kfree() drivers/amdgpu: Remove redundant casts on kzalloc() calls drivers/amdgpu: Use canonical boolean form in various predicates drivers/amdgpu: Remove redundant itermediate return val Huang Rui (5): drm/amdgpu: make amdgpu_cgs_call_acpi_method as static drm/amdgpu: fix incorrect type of info_id drm/amd/powerplay: rename smum header guards drm/amdgpu: add new definition in bif header drm/amdgpu: add query device id and revision id into system info entry at CGS Leo Liu (1): drm/amdgpu: free handles after fini the context Lyude (1): drm/amdgpu: Disable RPM helpers while reprobing connectors on resume Markus Elfring (7): GPU-DRM-Radeon: Delete an unnecessary check before drm_gem_object_unreference_unlocked() drm/amdgpu: Delete an unnecessary check before drm_gem_object_unreference_unlocked() drm/amdgpu: One function call less in amdgpu_cgs_acpi_eval_object() after error detection drm/amdgpu: Delete a variable in amdgpu_cgs_acpi_eval_object() drm/amdgpu: Delete an unnecessary variable initialisation in amdgpu_cgs_acpi_eval_object() drm/amdgpu: Change assignment for a variable in amdgpu_cgs_acpi_eval_object() drm/amd/powerplay: Change assignment for a buffer variable in phm_dispatch_table() v2 Nicholas Mc Guire (1): drm/radeon/ci add comment to document intentionally unreachable code Nils Wallménius (2): drm/amd/powerplay: Mark functions of ppevvmath.h static drm/amd/powerplay: Delete unused functions in ppevvmath.h Rex Zhu (7): drm/amd/powerplay: populate SMC ACPI minimum voltage using VBIOS boot SCLK and MCLK drm/amd/powerplay: enable DiDt feature for polaris10/11. drm/amd/powerplay: fix typo error when set clock gate state. Revert "drm/amd/powerplay: workaround issue that when uvd dpm disabled," drm/amdgpu: add bypass mode for vce3.0 drm/amd/powerplay: fix issue can't enable vce dpm. drm/amdgpu: add destroy session when generate VCE destroy msg. SF Markus Elfring (1): drm/amd/powerplay: Delete an unnecessary variable initialisation in phm_dispatch_table() Slava Grigorev (1): drm/amdgpu: comment out unused defaults_staturn_pro static const structure to fix the build Tom St Denis (2): drm/amd/powerplay: move clockgating to after ungating power in pp for uvd/vce drm/amd/powerplay: remove enable_clock_power_gatings_tasks from initialize and resume events jimqu (1): drm/amdgpu: correct coding style drivers/gpu/drm/amd/amdgpu/amdgpu.h| 14 +- drivers/gpu/drm/am
[Bug 97128] Kernel hang when running out of memory
https://bugs.freedesktop.org/show_bug.cgi?id=97128 --- Comment #2 from Bas Nieuwenhuizen --- I can confirm that patch fixes the hang for me. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/b2ebe722/attachment.html>
[Bug 94249] Topaz GPU not working correctly
https://bugs.freedesktop.org/show_bug.cgi?id=94249 --- Comment #9 from Armin K --- Created attachment 125420 --> https://bugs.freedesktop.org/attachment.cgi?id=125420&action=edit dmesg output from the current system -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/7b29088e/attachment.html>
[Bug 94249] Topaz GPU not working correctly
https://bugs.freedesktop.org/show_bug.cgi?id=94249 --- Comment #8 from Armin K --- Created attachment 125419 --> https://bugs.freedesktop.org/attachment.cgi?id=125419&action=edit gdb backtrace glxinfo Here's the backtrace of glxinfo when trying to use DRI3 PRIME (not loading amdgpu, but running DRI_PRIME=1 glxinfo with xf86-video-intel using DRI3). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/110b6ee9/attachment.html>
[Bug 94249] Topaz GPU not working correctly
https://bugs.freedesktop.org/show_bug.cgi?id=94249 --- Comment #7 from Armin K --- Created attachment 125418 --> https://bugs.freedesktop.org/attachment.cgi?id=125418&action=edit gdb backtrace Xorg Here's the best backtrace I could obtain from the Xorg server. I used a core file stored in journal. I'm not sure where those missing symbols are from. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/72fc5fcf/attachment-0001.html>
[Bug 94249] Topaz GPU not working correctly
https://bugs.freedesktop.org/show_bug.cgi?id=94249 --- Comment #6 from Armin K --- Created attachment 125417 --> https://bugs.freedesktop.org/attachment.cgi?id=125417&action=edit Xorg log Here's the Xorg.log extracted from journal. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/2173ddd0/attachment-0001.html>
[Bug 94249] Topaz GPU not working correctly
https://bugs.freedesktop.org/show_bug.cgi?id=94249 --- Comment #5 from Armin K --- I'm using Mesa 12.1.0-devel (git-c98c732) and libdrm-2.4.70. I think that's quite recent. I'm also using linux-4.7.0 atm. You can find the requested information in the attached files. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/2c5906ab/attachment.html>
[Bug 96326] Heavy screen flickering in OpenGL apps on R9 390
https://bugs.freedesktop.org/show_bug.cgi?id=96326 Alex Deucher changed: What|Removed |Added QA Contact|dri-devel at lists.freedesktop | |.org| Product|Mesa|DRI Component|Drivers/Gallium/radeonsi|DRM/Radeon Version|git |unspecified --- Comment #3 from Alex Deucher --- Please attach your xorg log and dmesg output. What resolution and refresh rate are you using on your monitor? Also are you using radeon or amdgpu? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/f3874c1c/attachment.html>
[Bug 97128] Kernel hang when running out of memory
https://bugs.freedesktop.org/show_bug.cgi?id=97128 --- Comment #1 from Alex Deucher --- Should be fixed in this patch: https://lists.freedesktop.org/archives/amd-gfx/2016-July/000686.html -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/c3d27ec6/attachment.html>
[PATCH] drm/imx: Remove imx_drm_handle_vblank()
imx_drm_handle_vblank() is just a simple wrapper of drm_crtc_handle_vblank()
without doing any thing fancy - drm_crtc_handle_vblank() can be called
directly. So, let's remove the wrapper.
Signed-off-by: Liu Ying
---
drivers/gpu/drm/imx/imx-drm-core.c | 6 --
drivers/gpu/drm/imx/imx-drm.h | 2 --
drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +-
3 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index 1aefced..6dc0ef4 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -84,12 +84,6 @@ static int imx_drm_driver_unload(struct drm_device *drm)
return 0;
}
-void imx_drm_handle_vblank(struct imx_drm_crtc *imx_drm_crtc)
-{
- drm_crtc_handle_vblank(imx_drm_crtc->crtc);
-}
-EXPORT_SYMBOL_GPL(imx_drm_handle_vblank);
-
static int imx_drm_enable_vblank(struct drm_device *drm, unsigned int pipe)
{
struct imx_drm_device *imxdrm = drm->dev_private;
diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index bdaa381..5a91cb1 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -42,8 +42,6 @@ int imx_drm_init_drm(struct platform_device *pdev,
int preferred_bpp);
int imx_drm_exit_drm(void);
-void imx_drm_handle_vblank(struct imx_drm_crtc *imx_drm_crtc);
-
void imx_drm_mode_config_init(struct drm_device *drm);
struct drm_gem_cma_object *imx_drm_fb_get_obj(struct drm_framebuffer *fb);
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 08e188b..5950b12 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -134,7 +134,7 @@ static irqreturn_t ipu_irq_handler(int irq, void *dev_id)
{
struct ipu_crtc *ipu_crtc = dev_id;
- imx_drm_handle_vblank(ipu_crtc->imx_crtc);
+ drm_crtc_handle_vblank(&ipu_crtc->base);
return IRQ_HANDLED;
}
--
2.7.4
[Intel-gfx] [PATCH v4 0/6] Finally fix watermarks
On Fri, Jul 29, 2016 at 10:26:20PM +0300, Ville Syrjälä wrote: > On Fri, Jul 29, 2016 at 02:48:09PM -0400, Lyude wrote: > > So I've been working on trying to fix this entirely again (e.g. writing > > the ddb properly), since from bug reports it still doesn't sound like > > we've got enough workarounds to make this tolerable. I've shown this to > > matt roper, but I should probably post what I've been trying to do for > > you as well. > > > > So the approach I came up with is here > > > > https://github.com/lyude/linux/tree/wip/skl-fix-wms-v5r2 > > > > My approach differs a little bit from what the bspec recommends, but I > > think it's going to be a bit easier to implement. At the end of all the > > changes I'm attempting it should look like this: > > > > * We no longer have a global watermark update for skl > > * A new hook called "update_ddbs" is added to i915_display_funcs. This > >gets called in intel_atomic_commit_tail() after we've disabled any > >CRTCs that needed disabling, and before we begin enabling/updating > >CRTCs > > * Because pipe ddb allocations (not the inner-pipe ddb allocations > >that apply to each pipe's planes) only change while > >enabling/disabling crtcs: > > * Pass 1: Find which pipe's new ddb allocation won't overlap with > > another pipe's previous allocation, and update that pipe first > > * Pass 2: Update the allocation of the remaining pipe > > > > Here's an illustration of what this looks like. Parts of the ddb not > > being used by any CRTCs are marked out with 'x's: > > > > With pipe A enabled, we enable pipe B: > > Initial DDB:   |      A      | > > update_ddbs:   |   A   |xxx| Pass 1 > > Enable pipe B:  |   A   |   B   | > > > > With pipes B and A active, we enable pipe C: > > > > Initial DDB:   |   B   |   A   | > > update_ddbs:   |  B  |xxx|   A   | Pass 1 > > update_ddbs:   |  B  |  A  |xxx| Pass 2 > > Enable pipe C:  |  B  |  A  |  C  | > > > > With pipes A, B, and C active, we disable B: > > Initial DDB:   |  A  |  B  |  C  | > > Disable pipe B: |  A  |xxx|  C  | > > update_ddbs:   |   A   |   C   | Pass 1 > > Since neither pipe's new allocation overlapped, we skip pass 2 > > > > Another allocation with A, B, and C active, disabling A: > > Initial DDB:   |  A  |  B  |  C  | > > Disable pipe A: |xxx|  B  |  C  | > > update_ddbs:   |   B   |xxx|  C  | Pass 1 > > update_ddbs:   |   B   |   C   | Pass 2 > > > > This should ensure we can always move around the allocations of pipes > > without them ever overlapping and exploding. > > That's what the current flush thing does, or at least that what it used > to do at least. Not sure it's really doing it anymore, but I'm pretty > sure the order in which it did things was sound at some point. > > > > > This branch doesn't entirely fix underrun issues, but I'm mostly sure > > that's the fault of still not having removed the global wm update hook > > yet (which is leading to additional pipe flushes in places they > > shouldn't be): > > Well it should basically boil down to s/update_wm/update_ddb/ > Only DDB reallocation really warrants a global hook. Everything else > should be handled via per-crtc hooks, on all platforms. I don't think we want even update_ddb. We want *calculate_ddb* to be a global hook during the atomic check phase (and we do have that today), but when we get around to the commit phase and start writing stuff to hardware, we want to program the per-pipe DDB entries at the same time we program the WM's and regular plane registers (since they should be double buffered and flushed out the same way). We just need to make sure that the order we process pipes in follows the special flushing rules noted above, which is what my pseudo-patches were trying to describe. > > > > > https://github.com/lyude/linux/tree/wip/skl-fix-wms-v5r2 > > > > As for updating inner-pipe ddb allocations for each plane on a pipe, we > > should be able to just do that at the same time we update each pipe's > > watermarks > > Yes. > > None of that changes what I said before though. Either you need to > lock down everything when the DDB needs to be repartitioned, or you > do what I outlined in the previous mail. Otherwise a plane update > etc. happening in parallel will still blow up on account of the DDB > state changing underneath the plane update somewhere between compute > and commit. I can't really think of third option that would work. Yep, I agree with all of this as well (and we do lock everything down today for exactly this reason). It's unfortunate that we need a BKL-style mechanism for the DDB, but as I noted in the other message, using fixed pre-partitioning for level 0 breaks too many additional use cases. :-( Matt > > > > > Let me kno
[Bug 95427] gem_userptr_blits@mlocked-* should skip due to memory pre-condition not met
https://bugs.freedesktop.org/show_bug.cgi?id=95427 --- Comment #4 from cprigent --- (In reply to Emil Velikov from comment #3) > Guys have you actually looked at the following line ? > Aperture size is 268435456 MiB -- That is 256 TiB !!! > > That's rather impossible amount if you ask me. So there's either a bug in > IGT's gem_aperture_size() or one of the two ioctls > (I915_GEM_CONTEXT_GETPARAM I915_GEM_GET_APERTURE) that it uses. > > With a couple of print statements you should be able to quickly track the > exact offender. Good luck ! Yes, we saw it. The bug is reported to IGT (not to DRM/Intel). We propose the test should skip. I just checked on our IVB platform with 32 GB of memory. Looks like we would need now 2 TB. root at IVB102:/opt/X11R7/src/intel-gpu-tools/tests# ./gem_userptr_blits --run-subtest mlocked-normal-sync IGT-Version: 1.15-ge3abb20 (x86_64) (Linux: 4.7.0-nightly+ x86_64) Aperture size is 2048 MiB Total RAM is 31,945 MiB Testing unsynchronized mappings... Testing synchronized mappings... Killed -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/2e713770/attachment-0001.html>
[Intel-gfx] [PATCH v4 0/6] Finally fix watermarks
On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote: > On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote: > > This is completely untested (and probably horribly broken/buggy), but > > here's a quick mockup of the general approach I was thinking for > > ensuring DDB & WM's can be updated together while ensuring the > > three-step pipe flushing process is honored: > > > > https://github.com/mattrope/kernel/commits/experimental/lyude_ddb > > > > Basically the idea is to take note of what's happening to the pipe's DDB > > allocation (shrinking, growing, unchanged, etc.) during the atomic check > > phase; > > Didn't look too closely, but I think you can't actually do that unless > you lock all the crtcs whenever the number of active pipes is goind to > change. Meaning we'd essentially be back to the one-big-modeset-lock > apporach, which will cause missed flips and whanot on the other pipes. > > The alternative I think would consist of: > - make sure level 0 watermark never exceeds total_ddb_size/max_pipes, > so that a modeset doesn't have to care about the wms for the other > pipes not fitting in Unfortunately this part is the problem. You might get away with doing this on SKL/KBL which only have three planes max per pipe and a large (896 block) DDB, but on BXT you have up to four planes (we don't actually enable the topmost plane in a full-featured manner just yet, but need to soon), yet the total DDB is only 512 blocks. Sadly, the platform with more planes was given a smaller DDB... :-( We're already in trouble because users that are running setups like 3x 4K with most/all planes in use at large sizes can't find level 0 watermarks that satisfy their needs and we have to reject the whole configuration. If we further limit each pipe's usage to total/maxpipes (i.e., 170 blocks per pipe on BXT), then we're going to hit similar issues when only driving one or two displays with with all of the planes in use, even though we should have had more DDB space to work with. I guess serious plane usage isn't too common in desktop setups today, but it's a very critical feature in the embedded world; we can't really afford to cripple plane usage further. Unfortunately, as you point out above, this means that we have to follow the bspec's DDB allocation method, which in turn means we need to grab _all_ CRTC locks any time _any_ CRTC is being turned on or turned off which is a BKL-style way of doing things. Matt > - level 1+ watermarks would be checked against total_ddb_size > - protect the plane/pipe commit with the wm mutex whenever the wms > need to be reprogrammed > - keep the flush_wm thing around for the case when ddb size does get > changed, protect it with the wm lock > - when programming wms, we will first filter out any level that > doesn't fit in with the current ddb size, and then program the > rest in > - potentially introduce per-pipe wm locks if the one big lock looks > like an issue, which it might if the flush_wm holds it all the way > through > > > then during the commit phase, we loop over the CRTC's three times > > instead of just once, but only operate on a subset of the CRTC's in each > > loop. While operating on each CRTC, the plane, WM, and DDB all get > > programmed together and have a single flush for all three. > > > > > > > > > > Matt > > > > On Tue, Jul 26, 2016 at 01:34:36PM -0400, Lyude wrote: > > > Latest version of https://lkml.org/lkml/2016/7/26/290 . Resending the > > > whole > > > thing to keep it in one place. > > > > > > Lyude (5): > > > drm/i915/skl: Add support for the SAGV, fix underrun hangs > > > drm/i915/skl: Only flush pipes when we change the ddb allocation > > > drm/i915/skl: Fix extra whitespace in skl_flush_wm_values() > > > drm/i915/skl: Update plane watermarks atomically during plane updates > > > drm/i915/skl: Always wait for pipes to update after a flush > > > > > > Matt Roper (1): > > > drm/i915/gen9: Only copy WM results for changed pipes to skl_hw > > > > > > drivers/gpu/drm/i915/i915_drv.h | 3 + > > > drivers/gpu/drm/i915/i915_reg.h | 5 + > > > drivers/gpu/drm/i915/intel_display.c | 24 > > > drivers/gpu/drm/i915/intel_drv.h | 4 + > > > drivers/gpu/drm/i915/intel_pm.c | 240 > > > +++ > > > drivers/gpu/drm/i915/intel_sprite.c | 2 + > > > 6 files changed, 255 insertions(+), 23 deletions(-) > > > > > > -- > > > 2.7.4 > > > > > > ___ > > > Intel-gfx mailing list > > > Intel-gfx at lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > > Matt Roper > > Graphics Software Engineer > > IoTG Platform Enabling & Development > > Intel Corporation > > (916) 356-2795 > > -- > Ville Syrjälä > Intel OTC -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795
[Bug 97069] Radeon r600 glamor corruptions on ARM64
https://bugs.freedesktop.org/show_bug.cgi?id=97069 --- Comment #14 from Clemens Eisserer --- I was able to track the TTM issues down to a very small coherent dma memory pool setting (4MB). With the kernel options "coherent_pool=128M cma=256M" all the code stressing texture up-/download works fine at expected performance. I'll give it a try next week to see whether this also fixes the issues with GL_ARB_buffer_storage. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/38fda808/attachment.html>
[Intel-gfx] [PATCH v4 0/6] Finally fix watermarks
On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote: > This is completely untested (and probably horribly broken/buggy), but > here's a quick mockup of the general approach I was thinking for > ensuring DDB & WM's can be updated together while ensuring the > three-step pipe flushing process is honored: > > https://github.com/mattrope/kernel/commits/experimental/lyude_ddb > > Basically the idea is to take note of what's happening to the pipe's DDB > allocation (shrinking, growing, unchanged, etc.) during the atomic check > phase; Didn't look too closely, but I think you can't actually do that unless you lock all the crtcs whenever the number of active pipes is goind to change. Meaning we'd essentially be back to the one-big-modeset-lock apporach, which will cause missed flips and whanot on the other pipes. The alternative I think would consist of: - make sure level 0 watermark never exceeds total_ddb_size/max_pipes, so that a modeset doesn't have to care about the wms for the other pipes not fitting in - level 1+ watermarks would be checked against total_ddb_size - protect the plane/pipe commit with the wm mutex whenever the wms need to be reprogrammed - keep the flush_wm thing around for the case when ddb size does get changed, protect it with the wm lock - when programming wms, we will first filter out any level that doesn't fit in with the current ddb size, and then program the rest in - potentially introduce per-pipe wm locks if the one big lock looks like an issue, which it might if the flush_wm holds it all the way through > then during the commit phase, we loop over the CRTC's three times > instead of just once, but only operate on a subset of the CRTC's in each > loop. While operating on each CRTC, the plane, WM, and DDB all get > programmed together and have a single flush for all three. > > > > > Matt > > On Tue, Jul 26, 2016 at 01:34:36PM -0400, Lyude wrote: > > Latest version of https://lkml.org/lkml/2016/7/26/290 . Resending the whole > > thing to keep it in one place. > > > > Lyude (5): > > drm/i915/skl: Add support for the SAGV, fix underrun hangs > > drm/i915/skl: Only flush pipes when we change the ddb allocation > > drm/i915/skl: Fix extra whitespace in skl_flush_wm_values() > > drm/i915/skl: Update plane watermarks atomically during plane updates > > drm/i915/skl: Always wait for pipes to update after a flush > > > > Matt Roper (1): > > drm/i915/gen9: Only copy WM results for changed pipes to skl_hw > > > > drivers/gpu/drm/i915/i915_drv.h | 3 + > > drivers/gpu/drm/i915/i915_reg.h | 5 + > > drivers/gpu/drm/i915/intel_display.c | 24 > > drivers/gpu/drm/i915/intel_drv.h | 4 + > > drivers/gpu/drm/i915/intel_pm.c | 240 > > +++ > > drivers/gpu/drm/i915/intel_sprite.c | 2 + > > 6 files changed, 255 insertions(+), 23 deletions(-) > > > > -- > > 2.7.4 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx at lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Matt Roper > Graphics Software Engineer > IoTG Platform Enabling & Development > Intel Corporation > (916) 356-2795 -- Ville Syrjälä Intel OTC
[Bug 97128] Kernel hang when running out of memory
https://bugs.freedesktop.org/show_bug.cgi?id=97128 Bug ID: 97128 Summary: Kernel hang when running out of memory Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: bas at basnieuwenhuizen.nl If I allocate too much memory I get a kernel hang using the drm-next-4.8 branch from Alex Deucher. SSH stops working too. This has been tests by allocating GTT buffers in a loop using the winsys for the new radv vulkan driver. Just as radeonsi, the winsys has a 3 step allocation process: 1) allocate the buffer 2) Allocate an address range 3) Map the buffer to address range. This hang is a regression. Bisection pointed to the following patch as culprit: commit 089f16c55baacd5e8ae3745625efa82899b4b217 Author: Christian König Date: Mon Jun 6 10:17:50 2016 +0200 drm/ttm: cleanup ttm_tt_(unbind|destroy) ttm_tt_destroy should be the only one unbinding the object. Reviewed-by: Alex Deucher Signed-off-by: Christian König Signed-off-by: Alex Deucher -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/0483acc6/attachment.html>
[PATCH v8 4/4] drm: rcar: use generic code for managing zpos plane property
version 6:
rebased patch on top rcar-du changes for zpos
version 4:
fix null pointer issue while setting zpos in plane reset function
This patch replaces zpos property handling custom code in rcar DRM
driver with calls to generic DRM code.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Laurent Pinchart
Tested-by: Laurent Pinchart
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Marek Szyprowski
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 -
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 5 -
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 ++---
drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 --
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 14 +-
6 files changed, 8 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index e39fcef..7316fc7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -196,7 +196,7 @@ void rcar_du_crtc_route_output(struct drm_crtc *crtc,
static unsigned int plane_zpos(struct rcar_du_plane *plane)
{
- return to_rcar_plane_state(plane->plane.state)->zpos;
+ return plane->plane.state->normalized_zpos;
}
static const struct rcar_du_format_info *
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index ed35467..c843c31 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -92,7 +92,6 @@ struct rcar_du_device {
struct {
struct drm_property *alpha;
struct drm_property *colorkey;
- struct drm_property *zpos;
} props;
unsigned int dpad0_source;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 6bb032d..f03eb55 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -527,11 +527,6 @@ static int rcar_du_properties_init(struct rcar_du_device
*rcdu)
if (rcdu->props.colorkey == NULL)
return -ENOMEM;
- rcdu->props.zpos =
- drm_property_create_range(rcdu->ddev, 0, "zpos", 1, 7);
- if (rcdu->props.zpos == NULL)
- return -ENOMEM;
-
return 0;
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index bfe31ca..a74f8ed 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -652,7 +652,7 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
state->source = RCAR_DU_PLANE_MEMORY;
state->alpha = 255;
state->colorkey = RCAR_DU_COLORKEY_NONE;
- state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
+ state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
plane->state = &state->state;
plane->state->plane = plane;
@@ -670,8 +670,6 @@ static int rcar_du_plane_atomic_set_property(struct
drm_plane *plane,
rstate->alpha = val;
else if (property == rcdu->props.colorkey)
rstate->colorkey = val;
- else if (property == rcdu->props.zpos)
- rstate->zpos = val;
else
return -EINVAL;
@@ -690,8 +688,6 @@ static int rcar_du_plane_atomic_get_property(struct
drm_plane *plane,
*val = rstate->alpha;
else if (property == rcdu->props.colorkey)
*val = rstate->colorkey;
- else if (property == rcdu->props.zpos)
- *val = rstate->zpos;
else
return -EINVAL;
@@ -763,8 +759,7 @@ int rcar_du_planes_init(struct rcar_du_group *rgrp)
drm_object_attach_property(&plane->plane.base,
rcdu->props.colorkey,
RCAR_DU_COLORKEY_NONE);
- drm_object_attach_property(&plane->plane.base,
- rcdu->props.zpos, 1);
+ drm_plane_create_zpos_property(&plane->plane, 1, 1, 7);
}
return 0;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index b18b7b2..8b91dd3 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -51,7 +51,6 @@ static inline struct rcar_du_plane *to_rcar_plane(struct
drm_plane *plane)
* @hwindex: 0-based hardware plane index, -1 means unused
* @alpha: value of the plane alpha property
* @colorkey: value of the plane colorkey property
- * @zpos: value of the plane zpos property
*/
struct rcar_du_plane_state {
struct drm_plane_state state;
@@ -62,7 +61,6 @@ struct rcar_du_plane_state {
unsigned int alpha;
unsigned int colorkey;
- unsigned int zpos;
};
static inline struct rcar_du_plane_state *
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
i
[PATCH v8 3/4] drm/exynos: use generic code for managing zpos plane property
From: Marek Szyprowski
This patch replaces zpos property handling custom code in Exynos DRM
driver with calls to generic DRM code.
Signed-off-by: Marek Szyprowski
Signed-off-by: Benjamin Gaignard
Cc: Inki Dae
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Andrzej Hajda
Cc: Krzysztof Kozlowski
Cc: Bartlomiej Zolnierkiewicz
Cc: Tobias Jakobi
Cc: Gustavo Padovan
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 -
drivers/gpu/drm/exynos/exynos_drm_plane.c | 67 +--
drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++-
3 files changed, 13 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b39d521..7f1a49d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -64,7 +64,6 @@ struct exynos_drm_plane_state {
struct exynos_drm_rect src;
unsigned int h_ratio;
unsigned int v_ratio;
- unsigned int zpos;
};
static inline struct exynos_drm_plane_state *
@@ -221,7 +220,6 @@ struct exynos_drm_private {
* this array is used to be aware of which crtc did it request vblank.
*/
struct drm_crtc *crtc[MAX_CRTC];
- struct drm_property *plane_zpos_property;
struct device *dma_dev;
void *mapping;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index 77f12c0..7f32419 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -139,9 +139,9 @@ static void exynos_drm_plane_reset(struct drm_plane *plane)
exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
if (exynos_state) {
- exynos_state->zpos = exynos_plane->config->zpos;
plane->state = &exynos_state->base;
plane->state->plane = plane;
+ plane->state->zpos = exynos_plane->config->zpos;
}
}
@@ -157,7 +157,6 @@ exynos_drm_plane_duplicate_state(struct drm_plane *plane)
return NULL;
__drm_atomic_helper_plane_duplicate_state(plane, ©->base);
- copy->zpos = exynos_state->zpos;
return ©->base;
}
@@ -170,43 +169,6 @@ static void exynos_drm_plane_destroy_state(struct
drm_plane *plane,
kfree(old_exynos_state);
}
-static int exynos_drm_plane_atomic_set_property(struct drm_plane *plane,
- struct drm_plane_state *state,
- struct drm_property *property,
- uint64_t val)
-{
- struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
- struct exynos_drm_plane_state *exynos_state =
- to_exynos_plane_state(state);
- struct exynos_drm_private *dev_priv = plane->dev->dev_private;
- const struct exynos_drm_plane_config *config = exynos_plane->config;
-
- if (property == dev_priv->plane_zpos_property &&
- (config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS))
- exynos_state->zpos = val;
- else
- return -EINVAL;
-
- return 0;
-}
-
-static int exynos_drm_plane_atomic_get_property(struct drm_plane *plane,
- const struct drm_plane_state *state,
- struct drm_property *property,
- uint64_t *val)
-{
- const struct exynos_drm_plane_state *exynos_state =
- container_of(state, const struct exynos_drm_plane_state, base);
- struct exynos_drm_private *dev_priv = plane->dev->dev_private;
-
- if (property == dev_priv->plane_zpos_property)
- *val = exynos_state->zpos;
- else
- return -EINVAL;
-
- return 0;
-}
-
static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -215,8 +177,6 @@ static struct drm_plane_funcs exynos_plane_funcs = {
.reset = exynos_drm_plane_reset,
.atomic_duplicate_state = exynos_drm_plane_duplicate_state,
.atomic_destroy_state = exynos_drm_plane_destroy_state,
- .atomic_set_property = exynos_drm_plane_atomic_set_property,
- .atomic_get_property = exynos_drm_plane_atomic_get_property,
};
static int
@@ -304,23 +264,13 @@ static const struct drm_plane_helper_funcs
plane_helper_funcs = {
};
static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
- unsigned int zpos)
+ bool immutable)
{
- struct drm_device *dev = plane->dev;
- struct exynos_drm_private *dev_priv = dev->dev_private;
[PATCH v8 2/4] drm: sti: use generic zpos for plane
remove private zpos property and use instead the generic new.
zpos range is now fixed per plane type and normalized before
being using in mixer.
Signed-off-by: Benjamin Gaignard
Cc: Inki Dae
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Andrzej Hajda
Cc: Krzysztof Kozlowski
Cc: Bartlomiej Zolnierkiewicz
Cc: Tobias Jakobi
Cc: Gustavo Padovan
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart
---
drivers/gpu/drm/sti/sti_cursor.c | 4 +--
drivers/gpu/drm/sti/sti_gdp.c| 4 +--
drivers/gpu/drm/sti/sti_hqvdp.c | 4 +--
drivers/gpu/drm/sti/sti_mixer.c | 9 ++---
drivers/gpu/drm/sti/sti_plane.c | 78 +++-
drivers/gpu/drm/sti/sti_plane.h | 7 +---
6 files changed, 38 insertions(+), 68 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c
index a263bbb..3b53f7f 100644
--- a/drivers/gpu/drm/sti/sti_cursor.c
+++ b/drivers/gpu/drm/sti/sti_cursor.c
@@ -349,8 +349,8 @@ struct drm_plane_funcs sti_cursor_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = sti_cursor_destroy,
- .set_property = sti_plane_set_property,
- .reset = drm_atomic_helper_plane_reset,
+ .set_property = drm_atomic_helper_plane_set_property,
+ .reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
.late_register = sti_cursor_late_register,
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index bf63086..b8d942c 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -886,8 +886,8 @@ struct drm_plane_funcs sti_gdp_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = sti_gdp_destroy,
- .set_property = sti_plane_set_property,
- .reset = drm_atomic_helper_plane_reset,
+ .set_property = drm_atomic_helper_plane_set_property,
+ .reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
.late_register = sti_gdp_late_register,
diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index b032322..b5ee783 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1254,8 +1254,8 @@ struct drm_plane_funcs sti_hqvdp_plane_helpers_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = sti_hqvdp_destroy,
- .set_property = sti_plane_set_property,
- .reset = drm_atomic_helper_plane_reset,
+ .set_property = drm_atomic_helper_plane_set_property,
+ .reset = sti_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
.late_register = sti_hqvdp_late_register,
diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
index 1885c7a..7d9aea8 100644
--- a/drivers/gpu/drm/sti/sti_mixer.c
+++ b/drivers/gpu/drm/sti/sti_mixer.c
@@ -239,13 +239,10 @@ static void sti_mixer_set_background_area(struct
sti_mixer *mixer,
int sti_mixer_set_plane_depth(struct sti_mixer *mixer, struct sti_plane *plane)
{
- int plane_id, depth = plane->zorder;
+ int plane_id, depth = plane->drm_plane.state->normalized_zpos;
unsigned int i;
u32 mask, val;
- if ((depth < 1) || (depth > GAM_MIXER_NB_DEPTH_LEVEL))
- return 1;
-
switch (plane->desc) {
case STI_GDP_0:
plane_id = GAM_DEPTH_GDP0_ID;
@@ -278,8 +275,8 @@ int sti_mixer_set_plane_depth(struct sti_mixer *mixer,
struct sti_plane *plane)
break;
}
- mask |= GAM_DEPTH_MASK_ID << (3 * (depth - 1));
- plane_id = plane_id << (3 * (depth - 1));
+ mask |= GAM_DEPTH_MASK_ID << (3 * depth);
+ plane_id = plane_id << (3 * depth);
DRM_DEBUG_DRIVER("%s %s depth=%d\n", sti_mixer_to_str(mixer),
sti_plane_to_str(plane), depth);
diff --git a/drivers/gpu/drm/sti/sti_plane.c b/drivers/gpu/drm/sti/sti_plane.c
index 0cf3335..ca4b371 100644
--- a/drivers/gpu/drm/sti/sti_plane.c
+++ b/drivers/gpu/drm/sti/sti_plane.c
@@ -14,15 +14,6 @@
#include "sti_drv.h"
#include "sti_plane.h"
-/* (Background) < GDP0 < GDP1 < HQVDP0 < GDP2 < GDP3 < (ForeGround) */
-enum sti_plane_desc sti_plane_default_zorder[] = {
- STI_GDP_0,
- STI_GDP_1,
- STI_HQVDP_0,
- STI_GDP_2,
- STI_GDP_3,
-};
-
const char *sti_plane_to_str(struct sti_plane *plane)
{
switch (plane->desc) {
@@ -96,59 +87,46 @@
[PATCH v8 1/4] drm: add generic zpos property
From: Marek Szyprowski
version 8:
- move drm_blend.o from drm-y to drm_kms_helper-y to avoid
EXPORT_SYMBOL(drm_atomic_helper_normalize_zpos)
- remove dead function declarations in drm_crtc.h
version 7:
- remove useless EXPORT_SYMBOL()
- better z-order wording in Documentation
version 6:
- add zpos in gpu documentation file
- merge Ville patch about zpos initial value and API improvement.
I have split Ville patch between zpos core and drivers
version 5:
- remove zpos range check and comeback to 0 to N-1
normalization algorithm
version 4:
- make sure that normalized zpos value is stay
in the defined property range and warn user if not
This patch adds support for generic plane's zpos property property with
well-defined semantics:
- added zpos properties to plane and plane state structures
- added helpers for normalizing zpos properties of given set of planes
- well defined semantics: planes are sorted by zpos values and then plane
id value if zpos equals
Normalized zpos values are calculated automatically when generic
muttable zpos property has been initialized. Drivers can simply use
plane_state->normalized_zpos in their atomic_check and/or plane_update
callbacks without any additional calls to DRM core.
Signed-off-by: Marek Szyprowski
Compare to Marek's original patch zpos property is now specific to each
plane and no more to the core.
Normalize function take care of the range of per plane defined range
before set normalized_zpos.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Ville Syrjälä
Acked-by: Laurent Pinchart
Tested-by: Laurent Pinchart
Cc: Inki Dae
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Andrzej Hajda
Cc: Krzysztof Kozlowski
Cc: Bartlomiej Zolnierkiewicz
Cc: Tobias Jakobi
Cc: Gustavo Padovan
Cc: vincent.abriou at st.com
Cc: fabien.dessenne at st.com
Cc: Laurent Pinchart
---
Documentation/gpu/kms-properties.csv | 1 +
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_atomic.c | 4 +
drivers/gpu/drm/drm_atomic_helper.c | 7 ++
drivers/gpu/drm/drm_blend.c | 238 +++
drivers/gpu/drm/drm_crtc_internal.h | 4 +
include/drm/drm_crtc.h | 20 +++
7 files changed, 275 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_blend.c
diff --git a/Documentation/gpu/kms-properties.csv
b/Documentation/gpu/kms-properties.csv
index b6fcaf6..4c5ce3e 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ DRM,Generic,ârotationâ,BITMASK,"{ 0, ""rotate-0"" }, { 1,
""rotate-90"" }, {
,,âCRTC_Hâ,RANGE,"Min=0, Max=UINT_MAX",Plane,Scanout CRTC (destination)
height (atomic)
,,âFB_IDâ,OBJECT,DRM_MODE_OBJECT_FB,Plane,Scanout framebuffer (atomic)
,,âCRTC_IDâ,OBJECT,DRM_MODE_OBJECT_CRTC,Plane,CRTC that plane is attached
to (atomic)
+,,âzposâ,RANGE,"Min=0, Max=UINT_MAX","Plane,Z-order of the plane.Planes
with higher Z-order values are displayed on top, planes with identical Z-order
values are display in an undefined order"
,DVI-I,âsubconnectorâ,ENUM,"{ âUnknownâ, âDVI-Dâ, âDVI-Aâ
}",Connector,TBD
,,âselect subconnectorâ,ENUM,"{ âAutomaticâ, âDVI-Dâ, âDVI-Aâ
}",Connector,TBD
,TV,âsubconnectorâ,ENUM,"{ ""Unknown"", ""Composite"", ""SVIDEO"",
""Component"", ""SCART"" }",Connector,TBD
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e3dba6f..0238bf8 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -24,7 +24,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
- drm_simple_kms_helper.o
+ drm_simple_kms_helper.o drm_blend.o
drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8d2f111..fa39307 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -711,6 +711,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property) {
state->rotation = val;
+ } else if (property == plane->zpos_property) {
+ state->zpos = val;
} else if (plane->funcs->atomic_set_property) {
return plane->funcs->atomic_set_property(plane, state,
property, val);
@@ -767,6 +769,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
*val = state->src_h;
} else if (property == config->rotation_property) {
*val = state->rotation;
+ } else if (property == plane->zpos_property
[PATCH v8 0/4] Generic zpos property
version 8: move drm_blend.o from drm-y to drm_kms_helper-y to avoid EXPORT_SYMBOL(drm_atomic_helper_normalize_zpos) remove dead function declarations in drm_crtc.h rebased code on drm-next + merge of git://linuxtv.org/media_tree.git vsp1 branch. version 7: remove useless EXPORT_SYMBOL() better z-order wording in Documentation rebased code on drm-next + merge of git://linuxtv.org/media_tree.git vsp1 branch. vsp1 branch might be merged into 4.8-rc1 so conflits between rcar-du and zpos patches should be avoid in this version 7. version 6: add zpos in Documentation/gpu/kms-properties.csv merge Ville's patch (splitted between all the commits) it simplify the API and fix bug. Thanks version 5: rebased on drm-next where Documentation/DocBook/gpu.tmpl doesn't exist anymore. rework sti patch because some plane functions have changed since v4 version 4: make sure that normalized zpos value is stay in the defined property range and warn user if not. Fix NULL pointer bug in rcar-du while setting zpos value. No changes in the other drivers. version 3: use kmalloc_array instead of kmalloc. Correct normalize_zpos computation (comeback to Mareck original code) version 2: add a zpos property into drm_plane structure to simplify code. This allow to get/set zpos value in core and not in drivers code. Fix various remarks. version 1: refactor Marek's patches to have per plane zpos property instead of only one in core. Benjamin Gaignard (2): drm: sti: use generic zpos for plane drm: rcar: use generic code for managing zpos plane property Marek Szyprowski (2): drm: add generic zpos property drm/exynos: use generic code for managing zpos plane property Documentation/gpu/kms-properties.csv | 1 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic.c | 4 + drivers/gpu/drm/drm_atomic_helper.c | 7 + drivers/gpu/drm/drm_blend.c | 238 ++ drivers/gpu/drm/drm_crtc_internal.h | 4 + drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 - drivers/gpu/drm/exynos/exynos_drm_plane.c | 67 ++--- drivers/gpu/drm/exynos/exynos_mixer.c | 6 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 2 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 - drivers/gpu/drm/rcar-du/rcar_du_kms.c | 5 - drivers/gpu/drm/rcar-du/rcar_du_plane.c | 9 +- drivers/gpu/drm/rcar-du/rcar_du_plane.h | 2 - drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 14 +- drivers/gpu/drm/sti/sti_cursor.c | 4 +- drivers/gpu/drm/sti/sti_gdp.c | 4 +- drivers/gpu/drm/sti/sti_hqvdp.c | 4 +- drivers/gpu/drm/sti/sti_mixer.c | 9 +- drivers/gpu/drm/sti/sti_plane.c | 78 -- drivers/gpu/drm/sti/sti_plane.h | 7 +- include/drm/drm_crtc.h| 20 +++ 22 files changed, 334 insertions(+), 156 deletions(-) create mode 100644 drivers/gpu/drm/drm_blend.c -- 1.9.1
[PATCH v14 0/17] Add Analogix Core Display Port Driver
On 5 April 2016 at 04:06, Yakir Yang wrote:
> Hi Daniel,
>
>
> On 03/31/2016 06:15 PM, Daniel Vetter wrote:
>>
>> On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:
>>>
>>> Hi all,
>>>
>>>The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
>>> share the same IP, so a lot of parts can be re-used. I split the common
>>> code into bridge directory, then rk3288 and exynos only need to keep
>>> some platform code. Cause I can't find the exact IP name of exynos dp
>>> controller, so I decide to name dp core driver with "analogix" which I
>>> find in rk3288 eDP TRM
>>>
>>> But there are still three light registers setting different between
>>> exynos and rk3288.
>>> 1. RK3288 have five special pll registers which not indicate in exynos
>>> dp controller.
>>> 2. The address of DP_PHY_PD(dp phy power manager register) are different
>>> between rk3288 and exynos.
>>> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp
>>> debug
>>> register).
>>>
>>> Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so
>>> it's
>>> okay to use the ATOMIC helpers functions in connector_funcs. No need to
>>> splict
>>> the connector init to platform driver anymore, and this is the biggest
>>> change
>>> since version 11.
>>>
>>> This v14 didn't have lots of new changes which seems not the correct time
>>> to
>>> upgrade the version number, but I have changed ordering of patches
>>> (adding 2
>>> more, and removing 2 out). Especially to prevent confusing people, so I
>>> updated
>>> the whole series.
>>
>> So I'm jumping into this part way late, but just noticed (well Thierry
>> pointed this out to me) that the exynos dp driver reinvents all the dp and
>> dp-aux helpers we already. That's somewhat okish for a private driver (and
>> exynos has a reputation for that kind of stuff), but imo not ok for a
>> shared driver.
>>
>> Not saying this should block merging this patch, but it really needs to be
>> addressed. All the dp aux and edid read code in the current
>> exynos_dp_core/reg.c files needs to be replaced with dp helpers and the
>> core i2c edid reading code.
>>
>> Who's going to sign up to do this?
>
>
> Volunteer to that, after finish this thread, I would send new series to
> switch to take use of dp helper.
Hi Yakir,
do you have plans to do this work in the short term? If not, I can tackle it.
Regards,
Tomeu
> :-D
> - Yakir
>
>
>> -Daniel
>>
>>> Thanks,
>>> - Yakir
>>>
>>>
>>> Changes in v14:
>>> - Rebase the new changes in imx-dp driver
>>> - Split up this patch into 3 parts, make this easy to review (Heiko)
>>> - Remove the Rockchip DP PHY to an separate thread (Heiko)
>>> https://patchwork.kernel.org/patch/8312701/
>>>
>>> Changes in v13:
>>> - Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
>>> - Fix the missing parameters with drm_encoder_init() helper function.
>>> (Heiko)
>>>
>>> Changes in v12:
>>> - Move the connector init to analogix_dp driver, and using ATOMIC helper
>>> (Heiko)
>>> - Add the ack from Jingoo
>>> - Remove the enum link_rate_type struct, using the marcos in
>>> drm_dp_helper.h (Jingoo)
>>>
>>> Changes in v11:
>>> - Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
>>> - Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
>>> - Add the ack from Rob Herring
>>> - Revert parts of Gustavo Padovan's changes in commit:
>>> drm/exynos: do not start enabling DP at bind() phase
>>>Add dp phy poweron function in bind time.
>>> - Move the panel prepare from get_modes time to bind time, and move
>>>the panel unprepare from bridge->disable to unbind time. (Heiko)
>>>
>>> Changes in v10:
>>> - Add the ack from Rob Herring
>>> - Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here
>>> (Heiko)
>>> - Add the ack from Rob Herring
>>> - Remove the surplus "plat_data" check. (Heiko)
>>> - switch (dp->plat_data && dp->plat_data->dev_type) {
>>> + switch (dp->plat_data->dev_type) {
>>>
>>> Changes in v9:
>>> - Document more details for 'ports' property.
>>>
>>> Changes in v8:
>>> - Correct the right document path of display-timing.txt (Heiko)
>>> - Correct the misspell of 'from' to 'frm'. (Heiko)
>>> - Modify the commit subject name. (Heiko)
>>>
>>> Changes in v7:
>>> - Back to use the of_property_read_bool() interfacs to provoid backward
>>>compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
>>>to avoid -EOVERFLOW error (Krzysztof)
>>>
>>> Changes in v6:
>>> - Fix the Kconfig recursive dependency (Javier)
>>> - Fix Peach Pit hpd property name error:
>>> - hpd-gpio = <&gpx2 6 0>;
>>> + hpd-gpios = <&gpx2 6 0>;
>>>
>>> Changes in v5:
>>> - Correct the check condition of gpio_is_valid when driver try to get
>>>the "hpd-gpios" DT propery. (Heiko)
>>> - Move the platform attach callback in the front of core driver bridge
>>>attch function. Cause once platform failed at attach, core driver
>>> should
[Bug 96326] Heavy screen flickering in OpenGL apps on R9 390
https://bugs.freedesktop.org/show_bug.cgi?id=96326 --- Comment #2 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> --- The flickering disappears after switching from X11 to Linux console (Ctrl+Alt+F1) and back (Ctrl+Alt+F7). mclk transitions 150MHz <-> 1500MHz no longer cause monitor flickering after that. The code in the Linux kernel executed during the switch to Linux console and back fixes the issue, we just need to pinpoint the code lines responsible for the fix. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/24f7cc93/attachment-0001.html>
[RFC 0/3] drm: Add DRM text mode
Actually adding David. -Daniel On Fri, Jul 29, 2016 at 10:20:51AM +0200, Daniel Vetter wrote: > On Thu, Jul 28, 2016 at 04:15:04PM +0200, Noralf Trønnes wrote: > > This patchset explores the idea of adding a DRM text mode > > (like VGA text mode) to get an alternative to fbcon/fbdev. > > > > David Hermann has done alot of work on a fbcon replacement: > > - drm: add kernel-log renderer (Mar 2014)[1] > > - kmscon: > > development started Nov 2011 > > added to systemd Oct 2014 > > removed from systemd Jul 2015[2] > > > > Since this work seems to have stalled, I propose an alternative solution > > to this problem that will also give VT console support while we're waiting > > for a userspace console. > > > > The idea is that the driver provides a modeset like with the fbdev emulation > > code, and from this a text buffer representation is made. The console code > > can now write to this text buffer and ask for the text buffer to be > > flushed/rendered to the pixel buffer. > > > > In this hack/implementation of the idea, I have just hijacked a CMA backed > > fbdev framebuffer to keep it simple. > > I have reused the default buffer format that VT uses. > > Getting panic handling to actually work, seems to be a challenge as Daniel > > describes on the DRMJanitors page[3]. > > > > Is this idea of a DRM text mode worth developing further? > > I guess some simpler drm console with vt support which would allow us to > get rid of fbdev could make sense. And there's definitely going to be a > lot of overlap with a full userspace solution using something like kmscon. > > But we can't just add a new drm text console, there's a pile of prep work > needed that David started for either approach: > - Nuking fbdev means no more fbdev drivers for firmware consoles (uboot, > uefi, vga, ...). The simpledrm driver would cover this, would be great > to get that landed (especially now that we have the simple pipe > helpers!). > > - One nice benefit of fbdev is that it automatically gets rid of these > firmware-based display drivers when the real driver loads. Some drivers > do this properly even when fbdev isn't enabled (see i915_kick_out_vgacon > and i915_kick_out_firmware_fb), but pretty much all others fail in some > way or the other. David also had some code (iirc as part of simpledrm) > to solve this issue. > > - I think we need more than rbg565 render support, iirc David also had > some work in that area. > > - None of these approaches has a good answer yet to the configuration > question. For a full VT I think we definitely should share the setup > logic with the fbdev emulation code to make it useful, but as describe > in the DRMJanitors page handlings panics is an entierly different > problem. > > Definitely coordinate with David Herrmann here too, since if we do > something in this area it should be widely supported. > > Aside: Where's the pull request for your driver? ;-) > > Cheers, Daniel > > > > > > > Noralf. > > > > [1] https://lwn.net/Articles/589858/ > > [2] https://github.com/systemd/systemd/pull/747 > > [3] https://www.x.org/wiki/DRMJanitors/#makepanichandlingwork > > > > > > Noralf Trønnes (3): > > drm: Add support for text framebuffer > > drm/text: Add panic and boot console support > > drm/text: Add VT console support > > > > drivers/gpu/drm/Makefile| 1 + > > drivers/gpu/drm/drm-text/Makefile | 5 + > > drivers/gpu/drm/drm-text/drm-text-buffer.c | 340 > > > > drivers/gpu/drm/drm-text/drm-text-console.c | 205 + > > drivers/gpu/drm/drm-text/drm-text-debugfs.c | 295 > > drivers/gpu/drm/drm-text/drm-text-vt.c | 197 > > drivers/gpu/drm/drm-text/drm-text.h | 99 > > 7 files changed, 1142 insertions(+) > > create mode 100644 drivers/gpu/drm/drm-text/Makefile > > create mode 100644 drivers/gpu/drm/drm-text/drm-text-buffer.c > > create mode 100644 drivers/gpu/drm/drm-text/drm-text-console.c > > create mode 100644 drivers/gpu/drm/drm-text/drm-text-debugfs.c > > create mode 100644 drivers/gpu/drm/drm-text/drm-text-vt.c > > create mode 100644 drivers/gpu/drm/drm-text/drm-text.h > > > > -- > > 2.8.2 > > > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 97038] OpenArena couple times slower using llvm 3.9
https://bugs.freedesktop.org/show_bug.cgi?id=97038 smoki changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #11 from smoki --- I think i will reopen this one until it is fixed with llvm 3.9 or if someone commented that it would not be fixed in llvm 3.9. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/39f27ed4/attachment.html>
[RFC 0/3] drm: Add DRM text mode
On Thu, Jul 28, 2016 at 04:15:04PM +0200, Noralf Trønnes wrote: > This patchset explores the idea of adding a DRM text mode > (like VGA text mode) to get an alternative to fbcon/fbdev. > > David Hermann has done alot of work on a fbcon replacement: > - drm: add kernel-log renderer (Mar 2014)[1] > - kmscon: > development started Nov 2011 > added to systemd Oct 2014 > removed from systemd Jul 2015[2] > > Since this work seems to have stalled, I propose an alternative solution > to this problem that will also give VT console support while we're waiting > for a userspace console. > > The idea is that the driver provides a modeset like with the fbdev emulation > code, and from this a text buffer representation is made. The console code > can now write to this text buffer and ask for the text buffer to be > flushed/rendered to the pixel buffer. > > In this hack/implementation of the idea, I have just hijacked a CMA backed > fbdev framebuffer to keep it simple. > I have reused the default buffer format that VT uses. > Getting panic handling to actually work, seems to be a challenge as Daniel > describes on the DRMJanitors page[3]. > > Is this idea of a DRM text mode worth developing further? I guess some simpler drm console with vt support which would allow us to get rid of fbdev could make sense. And there's definitely going to be a lot of overlap with a full userspace solution using something like kmscon. But we can't just add a new drm text console, there's a pile of prep work needed that David started for either approach: - Nuking fbdev means no more fbdev drivers for firmware consoles (uboot, uefi, vga, ...). The simpledrm driver would cover this, would be great to get that landed (especially now that we have the simple pipe helpers!). - One nice benefit of fbdev is that it automatically gets rid of these firmware-based display drivers when the real driver loads. Some drivers do this properly even when fbdev isn't enabled (see i915_kick_out_vgacon and i915_kick_out_firmware_fb), but pretty much all others fail in some way or the other. David also had some code (iirc as part of simpledrm) to solve this issue. - I think we need more than rbg565 render support, iirc David also had some work in that area. - None of these approaches has a good answer yet to the configuration question. For a full VT I think we definitely should share the setup logic with the fbdev emulation code to make it useful, but as describe in the DRMJanitors page handlings panics is an entierly different problem. Definitely coordinate with David Herrmann here too, since if we do something in this area it should be widely supported. Aside: Where's the pull request for your driver? ;-) Cheers, Daniel > > > Noralf. > > [1] https://lwn.net/Articles/589858/ > [2] https://github.com/systemd/systemd/pull/747 > [3] https://www.x.org/wiki/DRMJanitors/#makepanichandlingwork > > > Noralf Trønnes (3): > drm: Add support for text framebuffer > drm/text: Add panic and boot console support > drm/text: Add VT console support > > drivers/gpu/drm/Makefile| 1 + > drivers/gpu/drm/drm-text/Makefile | 5 + > drivers/gpu/drm/drm-text/drm-text-buffer.c | 340 > > drivers/gpu/drm/drm-text/drm-text-console.c | 205 + > drivers/gpu/drm/drm-text/drm-text-debugfs.c | 295 > drivers/gpu/drm/drm-text/drm-text-vt.c | 197 > drivers/gpu/drm/drm-text/drm-text.h | 99 > 7 files changed, 1142 insertions(+) > create mode 100644 drivers/gpu/drm/drm-text/Makefile > create mode 100644 drivers/gpu/drm/drm-text/drm-text-buffer.c > create mode 100644 drivers/gpu/drm/drm-text/drm-text-console.c > create mode 100644 drivers/gpu/drm/drm-text/drm-text-debugfs.c > create mode 100644 drivers/gpu/drm/drm-text/drm-text-vt.c > create mode 100644 drivers/gpu/drm/drm-text/drm-text.h > > -- > 2.8.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 84156] Half of lighting gets broken in older apps
https://bugs.freedesktop.org/show_bug.cgi?id=84156 smoki changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from smoki --- No it does not work, so i guessed it is irrelevant after 2 years of no one else commennted on it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/0e83d4b4/attachment.html>
[Bug 97039] The Talos Principle and Serious Sam 3 GPU faults
https://bugs.freedesktop.org/show_bug.cgi?id=97039 smoki changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/e91cb499/attachment.html>
[Bug 97039] The Talos Principle and Serious Sam 3 GPU faults
https://bugs.freedesktop.org/show_bug.cgi?id=97039 --- Comment #7 from smoki --- Why i closed this, have not idea... please ignore Comment 4 Yes Nicolai, bug is still there with current git of mesa and llvm. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/2cc313dc/attachment.html>
[PATCH] drm: BIT(DRM_ROTATE_?) -> DRM_ROTATE_?
This can be disregarded. -- Joonas Lahtinen Open Source Technology Center Intel Corporation
[PATCH v2] drm: BIT(DRM_ROTATE_?) -> DRM_ROTATE_?
Only property creation uses the rotation as an index, so convert the
to figure the index when needed.
v2: Use the new defines to build the _MASK defines (Sean)
Cc: intel-gfx at lists.freedesktop.org
Cc: linux-arm-msm at vger.kernel.org
Cc: freedreno at lists.freedesktop.org
Cc: malidp at foss.arm.com
Cc: David Airlie
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Liviu Dudau
Cc: Sean Paul
Acked-by: Liviu Dudau
Reviewed-by: Ville Syrjälä (v1)
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/arm/malidp_drv.h| 2 +-
drivers/gpu/drm/arm/malidp_planes.c | 20 +-
drivers/gpu/drm/armada/armada_overlay.c | 2 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 22 +--
drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
drivers/gpu/drm/drm_crtc.c | 24 ++---
drivers/gpu/drm/drm_fb_helper.c | 4 ++--
drivers/gpu/drm/drm_plane_helper.c | 2 +-
drivers/gpu/drm/drm_rect.c | 28 -
drivers/gpu/drm/i915/i915_debugfs.c | 12 +--
drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
drivers/gpu/drm/i915/intel_display.c| 28 -
drivers/gpu/drm/i915/intel_drv.h| 2 +-
drivers/gpu/drm/i915/intel_fbc.c| 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 6 +++---
drivers/gpu/drm/i915/intel_sprite.c | 6 +++---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 10 -
drivers/gpu/drm/omapdrm/omap_drv.c | 6 +++---
drivers/gpu/drm/omapdrm/omap_fb.c | 14 ++---
drivers/gpu/drm/omapdrm/omap_plane.c| 10 -
include/drm/drm_crtc.h | 17 ---
21 files changed, 112 insertions(+), 111 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index 95558fd..271d2fb 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -49,6 +49,6 @@ void malidp_de_planes_destroy(struct drm_device *drm);
int malidp_crtc_init(struct drm_device *drm);
/* often used combination of rotational bits */
-#define MALIDP_ROTATED_MASK(BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_270))
+#define MALIDP_ROTATED_MASK(DRM_ROTATE_90 | DRM_ROTATE_270)
#endif /* __MALIDP_DRV_H__ */
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 725098d..82c193e 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -108,7 +108,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
return -EINVAL;
/* packed RGB888 / BGR888 can't be rotated or flipped */
- if (state->rotation != BIT(DRM_ROTATE_0) &&
+ if (state->rotation != DRM_ROTATE_0 &&
(state->fb->pixel_format == DRM_FORMAT_RGB888 ||
state->fb->pixel_format == DRM_FORMAT_BGR888))
return -EINVAL;
@@ -188,9 +188,9 @@ static void malidp_de_plane_update(struct drm_plane *plane,
/* setup the rotation and axis flip bits */
if (plane->state->rotation & DRM_ROTATE_MASK)
val = ilog2(plane->state->rotation & DRM_ROTATE_MASK) <<
LAYER_ROT_OFFSET;
- if (plane->state->rotation & BIT(DRM_REFLECT_X))
+ if (plane->state->rotation & DRM_REFLECT_X)
val |= LAYER_V_FLIP;
- if (plane->state->rotation & BIT(DRM_REFLECT_Y))
+ if (plane->state->rotation & DRM_REFLECT_Y)
val |= LAYER_H_FLIP;
/* set the 'enable layer' bit */
@@ -255,12 +255,12 @@ int malidp_de_planes_init(struct drm_device *drm)
goto cleanup;
if (!drm->mode_config.rotation_property) {
- unsigned long flags = BIT(DRM_ROTATE_0) |
- BIT(DRM_ROTATE_90) |
- BIT(DRM_ROTATE_180) |
- BIT(DRM_ROTATE_270) |
- BIT(DRM_REFLECT_X) |
- BIT(DRM_REFLECT_Y);
+ unsigned long flags = DRM_ROTATE_0 |
+ DRM_ROTATE_90 |
+ DRM_ROTATE_180 |
+ DRM_ROTATE_270 |
+ DRM_REFLECT_X |
+ DRM_REFLECT_Y;
drm->mode_config.rotation_property =
drm_mode_create_rotation_property(drm, flags);
}
@@ -268,7 +268,7 @@ int malidp_de_planes_init(struct drm_device *drm)
if (drm->mode_config.rotation_property && (id != DE_SMART))
drm_object_attach_property(&plane->base.base,
[PATCH] drm: BIT(DRM_ROTATE_?) -> DRM_ROTATE_?
Only property creation uses the rotation as an index, so convert the
to figure the index when needed.
v2: Use the new defines to build the _MASK defines (Sean)
Cc: intel-gfx at lists.freedesktop.org
Cc: linux-arm-msm at vger.kernel.org
Cc: freedreno at lists.freedesktop.org
Cc: malidp at foss.arm.com
Cc: David Airlie
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Liviu Dudau
Cc: Sean Paul
Acked-by: Liviu Dudau
Reviewed-by: Ville Syrjälä (v1)
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/arm/malidp_drv.h| 2 +-
drivers/gpu/drm/arm/malidp_planes.c | 20 +-
drivers/gpu/drm/armada/armada_overlay.c | 2 +-
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 22 +--
drivers/gpu/drm/drm_atomic_helper.c | 4 ++--
drivers/gpu/drm/drm_crtc.c | 24 ++---
drivers/gpu/drm/drm_fb_helper.c | 4 ++--
drivers/gpu/drm/drm_plane_helper.c | 2 +-
drivers/gpu/drm/drm_rect.c | 28 -
drivers/gpu/drm/i915/i915_debugfs.c | 12 +--
drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
drivers/gpu/drm/i915/intel_display.c| 28 -
drivers/gpu/drm/i915/intel_drv.h| 2 +-
drivers/gpu/drm/i915/intel_fbc.c| 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 6 +++---
drivers/gpu/drm/i915/intel_sprite.c | 6 +++---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 10 -
drivers/gpu/drm/omapdrm/omap_drv.c | 6 +++---
drivers/gpu/drm/omapdrm/omap_fb.c | 14 ++---
drivers/gpu/drm/omapdrm/omap_plane.c| 10 -
include/drm/drm_crtc.h | 17 ---
21 files changed, 112 insertions(+), 111 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index 95558fd..271d2fb 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -49,6 +49,6 @@ void malidp_de_planes_destroy(struct drm_device *drm);
int malidp_crtc_init(struct drm_device *drm);
/* often used combination of rotational bits */
-#define MALIDP_ROTATED_MASK(BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_270))
+#define MALIDP_ROTATED_MASK(DRM_ROTATE_90 | DRM_ROTATE_270)
#endif /* __MALIDP_DRV_H__ */
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 725098d..82c193e 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -108,7 +108,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
return -EINVAL;
/* packed RGB888 / BGR888 can't be rotated or flipped */
- if (state->rotation != BIT(DRM_ROTATE_0) &&
+ if (state->rotation != DRM_ROTATE_0 &&
(state->fb->pixel_format == DRM_FORMAT_RGB888 ||
state->fb->pixel_format == DRM_FORMAT_BGR888))
return -EINVAL;
@@ -188,9 +188,9 @@ static void malidp_de_plane_update(struct drm_plane *plane,
/* setup the rotation and axis flip bits */
if (plane->state->rotation & DRM_ROTATE_MASK)
val = ilog2(plane->state->rotation & DRM_ROTATE_MASK) <<
LAYER_ROT_OFFSET;
- if (plane->state->rotation & BIT(DRM_REFLECT_X))
+ if (plane->state->rotation & DRM_REFLECT_X)
val |= LAYER_V_FLIP;
- if (plane->state->rotation & BIT(DRM_REFLECT_Y))
+ if (plane->state->rotation & DRM_REFLECT_Y)
val |= LAYER_H_FLIP;
/* set the 'enable layer' bit */
@@ -255,12 +255,12 @@ int malidp_de_planes_init(struct drm_device *drm)
goto cleanup;
if (!drm->mode_config.rotation_property) {
- unsigned long flags = BIT(DRM_ROTATE_0) |
- BIT(DRM_ROTATE_90) |
- BIT(DRM_ROTATE_180) |
- BIT(DRM_ROTATE_270) |
- BIT(DRM_REFLECT_X) |
- BIT(DRM_REFLECT_Y);
+ unsigned long flags = DRM_ROTATE_0 |
+ DRM_ROTATE_90 |
+ DRM_ROTATE_180 |
+ DRM_ROTATE_270 |
+ DRM_REFLECT_X |
+ DRM_REFLECT_Y;
drm->mode_config.rotation_property =
drm_mode_create_rotation_property(drm, flags);
}
@@ -268,7 +268,7 @@ int malidp_de_planes_init(struct drm_device *drm)
if (drm->mode_config.rotation_property && (id != DE_SMART))
drm_object_attach_property(&plane->base.base,
[Bug 95528] BioShock Infinite graphical glitches on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=95528 --- Comment #20 from Mike Lothian --- I have a feeling https://reviews.llvm.org/D22032 fixed the issue where I could run the game at Ultra settings, certainly one of the changes in the last two days has fixed it for me -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/6ac500c2/attachment.html>
[Bug 94249] Topaz GPU not working correctly
https://bugs.freedesktop.org/show_bug.cgi?id=94249 --- Comment #4 from Michel Dänzer --- First of all, for Topaz / Iceland I think it's best to use current Git snapshots of Mesa and libdrm_amdgpu. Please attach the full Xorg log corresponding to the failure. A gdb backtrace would also be helpful, see https://www.x.org/wiki/Development/Documentation/ServerDebugging/ . -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/6c2da60c/attachment.html>
[Bug 97123] [AMDGPU][CIK] Suspend to disk deadlocks system on resume always (Linus master + drm-next-4.9-wip)
https://bugs.freedesktop.org/show_bug.cgi?id=97123 Bug ID: 97123 Summary: [AMDGPU][CIK] Suspend to disk deadlocks system on resume always (Linus master + drm-next-4.9-wip) Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: shawn.starr at rogers.com I've been testing AMDGPU with CIK (Bonaire), in drm-next-4.8-wip / drm-next-4.8, hibernation sometime worked sometime not. With drm-next-4.9-wip (with Linus master merged), hibernation works, resume fails after image is loaded, system is deadlocked. Is there any debugging I can do testing path? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/f5a5c591/attachment.html>
ATPX changes in drm-next-4.8 and D3cold handling
On Thu, Jul 28, 2016 at 05:40:31PM +0200, Lukas Wunner wrote: > On Thu, Jul 28, 2016 at 03:33:25PM +, Deucher, Alexander wrote: > > > From: Peter Wu [mailto:peter at lekensteyn.nl] > > > Sent: Thursday, July 21, 2016 6:43 AM > > > In case you missed it, Dave's D3cold patches were succeeded by changes > > > in PCI core. Relevant commits in the pci/pm branch: > > > > > > 006d44e PCI: Add runtime PM support for PCIe ports > > > 16468c7 ACPI / hotplug / PCI: Runtime resume bridge before rescan > > > d963f65 PCI: Power on bridges before scanning new devices > > > 9d26d3a PCI: Put PCIe ports into D3 during suspend > > > 43f7f88 PCI: Don't clear d3cold_allowed for PCIe ports > > > > Did those get merged yet? > > They will go into 4.8. Should have gone into 4.7 already but were > dropped at the last minute. > > > > I just need to revert this commit once the d3cold patches land: > > https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.8&id=bdfb76040068d960cb9e226876be8a508d741c4a > > So you probably need to revert this now. > > Best regards, > Lukas It is better to revert it before the PCI/PM patches get merged, otherwise you risk that the device is already put in D3 before the bridge tries to do it again. This is currently happening with nouveau on -next. Do these AMD hw exist on BIOSes pre-2015? Currently the D3cold work in the PCI/PM branch only enable the D3cold handling via the bridge when the BIOS is >= 2015. -- Kind regards, Peter Wu https://lekensteyn.nl
[Bug 64475] Euro Track Simulator II game slow in cabin with r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=64475 Bug 64475 depends on bug 27222, which changed state. Bug 27222 Summary: Gamma not working in 3D on xserver >= 1.6.99.900 https://bugs.freedesktop.org/show_bug.cgi?id=27222 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160729/ebbf0981/attachment.html>
