[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)
https://bugs.freedesktop.org/show_bug.cgi?id=97879 Kenneth Graunke changed: What|Removed |Added QA Contact|mesa-dev at lists.freedesktop. |dri-devel at lists.freedesktop |org |.org Component|Other |Drivers/Gallium/radeonsi Assignee|mesa-dev at lists.freedesktop. |dri-devel at lists.freedesktop |org |.org -- 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/20160920/78e57974/attachment-0001.html>
[Bug 172381] New: nouveau kernel module leaks memory on hibernate.
https://bugzilla.kernel.org/show_bug.cgi?id=172381 Bug ID: 172381 Summary: nouveau kernel module leaks memory on hibernate. Product: Drivers Version: 2.5 Kernel Version: 4.8rc6 Hardware: All 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: me at hussam.eu.org Regression: No On hibernate, it seems that nouveau pushes vram into physical ram instead of swap (possibly on the assumption that it is going to be swaped to disk on hibernation). In my case, I have 4GB physical ram and vram = 2GB. - Hibernate only works if amount of physical ram in use is less than 2G (4 - 2 = 2), otherwise I get an "error -12 creating hibernation image" "PM: Not enough free memory". - If hibernate works, on resume, vram is not freed from physical memory. rmmoding nouveau frees 500+ MB of physical ram. - So far, I have reproduced this on kernels 4.4 to 4.8rc6 (I have not attempted older kernels). - Cards tested are 630GT (fermi) and 730GT (kepler). -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 5/6] GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()
On Tue, Sep 20, 2016 at 2:08 PM, Jani Nikula wrote: > On Tue, 20 Sep 2016, Dan Carpenter wrote: >> Don't be a dummy... This is easy to review an it fixes a bug. In this particular case it might not be clear that an unknown GCT version causes a complete GCT failure so both messages are useful. >> >> I'm fine with you NAKing all these patches based on who they are from. >> I mostly just delete these without responding because the guy has >> history of introducing bugs and never listens to feedback. But asking >> pointless rhetorical questions is not helpful. >> >> A lot of people are CC'd and you're wasting everyone's time by asking >> questions where you know the answer. > > Fair enough, sorry for the noise. > > To be honest, I did only look at the patches, not who they were from. We > have CI for drm/i915, but I don't think it's constructive to keep > changing drivers like this where the upstream isn't actively developed > and tested. But I digress. It's up to Patrik anyway. Nothing in this series is very helpful so NAK. In general I'm not fond of trivial changes like this since it's hard to say what motivates the author. In theory it shouldn't matter but so far it's been directly related to the quality of the patches. I can help test changes for gma500 if needed but please make it worth my while. Best regards Patrik > > BR, > Jani. > > > > -- > Jani Nikula, Intel Open Source Technology Center
[Bug 141741] drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM
https://bugzilla.kernel.org/show_bug.cgi?id=141741 --- Comment #14 from Jose Barros --- Created attachment 239331 --> https://bugzilla.kernel.org/attachment.cgi?id=239331&action=edit dmesg | egrep 'drm|radeon' on 4.6.0-kali1-amd64 -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state
Hi I've bisected back to this commit in the drm-intel-nightly branch 05a76d3d6ad1ee9f9814f88949cc9305fc165460 is the first bad commit commit 05a76d3d6ad1ee9f9814f88949cc9305fc165460 Author: Lyude Date: Wed Aug 17 15:55:57 2016 -0400 drm/i915/skl: Ensure pipes with changed wms get added to the state If we're enabling a pipe, we'll need to modify the watermarks on all active planes. Since those planes won't be added to the state on their own, we need to add them ourselves. Signed-off-by: Lyude Reviewed-by: Matt Roper Cc: stable at vger.kernel.org Cc: Ville Syrjälä Cc: Daniel Vetter Cc: Radhakrishna Sripada Cc: Hans de Goede Signed-off-by: Maarten Lankhorst Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-6-git-send-email-cpaul at redhat.com The symptoms I'm seeing look like tearing at the top of the screen and it's especially noticeable in Chrome - reverting this commit makes the issue go away Let me know if you'd like me to raise a bug Cheers Mike (Re-sending from Gmail - as Inbox doesn't let me send as plain text) On 17 August 2016 at 20:55, Lyude wrote: > If we're enabling a pipe, we'll need to modify the watermarks on all > active planes. Since those planes won't be added to the state on > their own, we need to add them ourselves. > > Signed-off-by: Lyude > Reviewed-by: Matt Roper > Cc: stable at vger.kernel.org > Cc: Ville Syrjälä > Cc: Daniel Vetter > Cc: Radhakrishna Sripada > Cc: Hans de Goede > --- > drivers/gpu/drm/i915/intel_pm.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 849f039..a3d24cb 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -4117,6 +4117,10 @@ skl_compute_ddb(struct drm_atomic_state *state) > ret = skl_allocate_pipe_ddb(cstate, ddb); > if (ret) > return ret; > + > + ret = drm_atomic_add_affected_planes(state, > &intel_crtc->base); > + if (ret) > + return ret; > } > > return 0; > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v12 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state
Hi I've bisected back to this commit in the drm-intel-nightly branch 05a76d3d6ad1ee9f9814f88949cc9305fc165460 is the first bad commit commit 05a76d3d6ad1ee9f9814f88949cc9305fc165460 Author: Lyude Date: Wed Aug 17 15:55:57 2016 -0400 drm/i915/skl: Ensure pipes with changed wms get added to the state If we're enabling a pipe, we'll need to modify the watermarks on all active planes. Since those planes won't be added to the state on their own, we need to add them ourselves. Signed-off-by: Lyude Reviewed-by: Matt Roper Cc: stable at vger.kernel.org Cc: Ville Syrjälä Cc: Daniel Vetter Cc: Radhakrishna Sripada Cc: Hans de Goede Signed-off-by: Maarten Lankhorst Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-6-git-send-email-cpaul at redhat.com The symptoms I'm seeing look like tearing at the top of the screen and it's especially noticeable in Chrome - reverting this commit makes the issue go away Let me know if you'd like me to raise a bug Cheers Mike On Wed, 17 Aug 2016 at 20:56 Lyude wrote: > If we're enabling a pipe, we'll need to modify the watermarks on all > active planes. Since those planes won't be added to the state on > their own, we need to add them ourselves. > > Signed-off-by: Lyude > Reviewed-by: Matt Roper > Cc: stable at vger.kernel.org > Cc: Ville Syrjälä > Cc: Daniel Vetter > Cc: Radhakrishna Sripada > Cc: Hans de Goede > --- > drivers/gpu/drm/i915/intel_pm.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > b/drivers/gpu/drm/i915/intel_pm.c > index 849f039..a3d24cb 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -4117,6 +4117,10 @@ skl_compute_ddb(struct drm_atomic_state *state) > ret = skl_allocate_pipe_ddb(cstate, ddb); > if (ret) > return ret; > + > + ret = drm_atomic_add_affected_planes(state, > &intel_crtc->base); > + if (ret) > + return ret; > } > > return 0; > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/1ee00b89/attachment-0001.html>
[PATCH v3] dma-buf/sync_file: Increment refcount of fence when all are signaled.
Hi Rafael, On 16 September 2016 at 00:44, Rafael Antognolli wrote: > When we merge several fences, if all of them are signaled already, we > still keep one of them. So instead of using add_fence(), which will not > increase the refcount of signaled fences, we should explicitly call > fence_get() for the fence we are keeping. > > This patch fixes a kernel panic that can be triggered by creating a fence that > is expired (or increasing the timeline until it expires), then creating a > merged fence out of it, and deleting the merged fence. This will make the > original expired fence's refcount go to zero. > > Testcase: igt/sw_sync/sync_expired_merge > Signed-off-by: Rafael Antognolli > Reviewed-by: Chris Wilson > Reviewed-by: Gustavo Padovan Thanks for the patch; applied via drm-misc. > --- > drivers/dma-buf/sync_file.c | 6 ++ Best, Sumit.
[PATCH] dma-buf/sync_file: fix documentation error
Hi Emilio, On 19 September 2016 at 17:40, Gustavo Padovan wrote: > Hi Emilio, > > 2016-09-19 Emilio López : > >> The ioctl name and description on the documentation block don't >> match the ioctl being defined. This was probably overlooked while >> renaming the ioctls during the sync file destaging. This patch >> provides a more accurate description of what the ioctl actually does. >> >> Signed-off-by: Emilio López >> --- > > Reviewed-by: Gustavo Padovan > Thanks; applied to drm-misc. > Gustavo > Best, Sumit.
[PATCH] dma-buf/sw_sync: mark sync_timeline_create() static
Hi Baoyou, On 20 September 2016 at 16:43, Gustavo Padovan wrote: > 2016-09-18 Baoyou Xie : > >> We get 1 warning when building kernel with W=1: >> drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for >> 'sync_timeline_create' [-Wmissing-prototypes] >> >> In fact, this function is only used in the file in which it is >> declared and don't need a declaration, but can be made static. >> So this patch marks it 'static'. >> >> Signed-off-by: Baoyou Xie >> --- >> drivers/dma-buf/sw_sync.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > Thanks for finding this. Thanks for the patch; this doesn't apply to mainline yet, since the de-staging of sw_sync code is queued for 4.9 via Greg-KH's tree. CC'ing him. Greg, would it be possible to please take this via your tree? > > Reviewed-by: Gustavo Padovan > Acked-by: Sumit Semwal > Gustavo > Best regards, Sumi
[PATCH xf86-video-ati] Use local implementation of RegionDuplicate for older xserver
From: Michel Dänzer It was only added in xserver 1.15. Fixes build against older xserver. Reported-by: Pali Rohár Signed-off-by: Michel Dänzer --- configure.ac | 6 ++ src/radeon.h | 19 +++ 2 files changed, 25 insertions(+) diff --git a/configure.ac b/configure.ac index 394f45a..8dc55d8 100644 --- a/configure.ac +++ b/configure.ac @@ -137,6 +137,12 @@ else fi AM_CONDITIONAL(GLAMOR, test x$GLAMOR != xno) +AC_CHECK_DECL(RegionDuplicate, + [AC_DEFINE(HAVE_REGIONDUPLICATE, 1, + [Have RegionDuplicate API])], [], + [#include + #include ]) + AC_CHECK_DECL(fbGlyphs, [AC_DEFINE(HAVE_FBGLYPHS, 1, [Have fbGlyphs API])], [], [#include diff --git a/src/radeon.h b/src/radeon.h index f3a3e1c..590966f 100644 --- a/src/radeon.h +++ b/src/radeon.h @@ -96,6 +96,25 @@ struct _SyncFence; +#ifndef HAVE_REGIONDUPLICATE + +static inline RegionPtr +RegionDuplicate(RegionPtr pOld) +{ +RegionPtr pNew; + +pNew = RegionCreate(&pOld->extents, 0); +if (!pNew) + return NULL; +if (!RegionCopy(pNew, pOld)) { + RegionDestroy(pNew); + return NULL; +} +return pNew; +} + +#endif + #ifndef MAX #define MAX(a,b) ((a)>(b)?(a):(b)) #endif -- 2.9.3
[PATCH] Add drmModeAddFB2WithModifiers() which takes format modifiers
On 09/14/2016 07:07 AM, Kristian H. Kristensen wrote: > The only current user of this open codes the ioctl. Let's add an entry > point for this to libdrm. Tested-by: Alexandre Courbot Replaced one custom (staging) ioctl on Tegra with FB modifiers, noticed this was missing! > > Signed-off-by: Kristian H. Kristensen > --- > xf86drmMode.c | 21 + > xf86drmMode.h | 7 +++ > 2 files changed, 24 insertions(+), 4 deletions(-) > > diff --git a/xf86drmMode.c b/xf86drmMode.c > index f7b5948..2907c5c 100644 > --- a/xf86drmMode.c > +++ b/xf86drmMode.c > @@ -270,10 +270,10 @@ int drmModeAddFB(int fd, uint32_t width, uint32_t > height, uint8_t depth, > return 0; > } > > -int drmModeAddFB2(int fd, uint32_t width, uint32_t height, > - uint32_t pixel_format, uint32_t bo_handles[4], > - uint32_t pitches[4], uint32_t offsets[4], > - uint32_t *buf_id, uint32_t flags) > +int drmModeAddFB2WithModifiers(int fd, uint32_t width, uint32_t height, > + uint32_t pixel_format, uint32_t bo_handles[4], > + uint32_t pitches[4], uint32_t offsets[4], > + uint64_t modifier[4], uint32_t *buf_id, > uint32_t flags) > { > struct drm_mode_fb_cmd2 f; > int ret; > @@ -286,6 +286,8 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t height, > memcpy(f.handles, bo_handles, 4 * sizeof(bo_handles[0])); > memcpy(f.pitches, pitches, 4 * sizeof(pitches[0])); > memcpy(f.offsets, offsets, 4 * sizeof(offsets[0])); > +if (modifier) > + memcpy(f.modifier, modifier, 4 * sizeof(modifier[0])); > > if ((ret = DRM_IOCTL(fd, DRM_IOCTL_MODE_ADDFB2, &f))) > return ret; > @@ -294,6 +296,17 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t > height, > return 0; > } > > +int drmModeAddFB2(int fd, uint32_t width, uint32_t height, > + uint32_t pixel_format, uint32_t bo_handles[4], > + uint32_t pitches[4], uint32_t offsets[4], > + uint32_t *buf_id, uint32_t flags) > +{ > + return drmModeAddFB2WithModifiers(fd, width, height, > +pixel_format, bo_handles, > +pitches, offsets, NULL, > +buf_id, flags); > +} > + > int drmModeRmFB(int fd, uint32_t bufferId) > { > return DRM_IOCTL(fd, DRM_IOCTL_MODE_RMFB, &bufferId); > diff --git a/xf86drmMode.h b/xf86drmMode.h > index 4de7bbb..02190ea 100644 > --- a/xf86drmMode.h > +++ b/xf86drmMode.h > @@ -369,6 +369,13 @@ extern int drmModeAddFB2(int fd, uint32_t width, > uint32_t height, >uint32_t pixel_format, uint32_t bo_handles[4], >uint32_t pitches[4], uint32_t offsets[4], >uint32_t *buf_id, uint32_t flags); > + > +/* ...with format modifiers */ > +int drmModeAddFB2WithModifiers(int fd, uint32_t width, uint32_t height, > + uint32_t pixel_format, uint32_t bo_handles[4], > + uint32_t pitches[4], uint32_t offsets[4], > + uint64_t modifier[4], uint32_t *buf_id, > uint32_t flags); > + > /** > * Destroies the given framebuffer. > */ >
[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled
https://bugs.freedesktop.org/show_bug.cgi?id=97840 --- Comment #12 from Mike Lothian --- Created attachment 126668 --> https://bugs.freedesktop.org/attachment.cgi?id=126668&action=edit Dmesg with issues This is the dmesg, when the system is still semi-responsive -- 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/20160920/16594dcc/attachment-0001.html>
[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled
https://bugs.freedesktop.org/show_bug.cgi?id=97840 --- Comment #11 from Mike Lothian --- Created attachment 126667 --> https://bugs.freedesktop.org/attachment.cgi?id=126667&action=edit Glxgears corrupted -- 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/20160920/dada5c3f/attachment-0001.html>
[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled
https://bugs.freedesktop.org/show_bug.cgi?id=97840 --- Comment #10 from Mike Lothian --- Even with this reverted things aren't working correctly if I do a DRI_PRIME=1 glxgears the image is highly messed up -- 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/20160920/c35eac93/attachment-0001.html>
[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled
https://bugs.freedesktop.org/show_bug.cgi?id=97840 --- Comment #9 from Mike Lothian --- The first bad commit is: abd0a5ee7a25d108e9d709a4f61ef58754b60919 is the first bad commit commit abd0a5ee7a25d108e9d709a4f61ef58754b60919 Author: Monk Liu Date: Wed Sep 14 19:10:33 2016 +0800 drm/amdgpu:correct smc fw version error original method get wrong smc fw version. Signed-off-by: Monk Liu Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Reverting this one allows X to start again -- 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/20160920/70d06f45/attachment-0001.html>
[PATCH v3 11/20] drm: omapdrm: Check DSS manager state in the enable/disable helpers
On 19/09/16 15:27, Laurent Pinchart wrote: > The omapdrm DSS manager enable/disable operations check the DSS manager > state to avoid double enabling/disabling. Move that code to the DSS > manager to decrease the dependency of the DRM layer to the DSS layer. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/omapdrm/dss/dispc.c | 1 - > drivers/gpu/drm/omapdrm/dss/output.c | 6 ++ > drivers/gpu/drm/omapdrm/omap_crtc.c | 3 --- > 3 files changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c > b/drivers/gpu/drm/omapdrm/dss/dispc.c > index 535240fba671..ab150bf21dd8 100644 > --- a/drivers/gpu/drm/omapdrm/dss/dispc.c > +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c > @@ -2911,7 +2911,6 @@ bool dispc_mgr_is_enabled(enum omap_channel channel) > { > return !!mgr_fld_read(channel, DISPC_MGR_FLD_ENABLE); > } > -EXPORT_SYMBOL(dispc_mgr_is_enabled); > > void dispc_wb_enable(bool enable) > { > diff --git a/drivers/gpu/drm/omapdrm/dss/output.c > b/drivers/gpu/drm/omapdrm/dss/output.c > index 24f859488201..f0be621895fa 100644 > --- a/drivers/gpu/drm/omapdrm/dss/output.c > +++ b/drivers/gpu/drm/omapdrm/dss/output.c > @@ -217,12 +217,18 @@ EXPORT_SYMBOL(dss_mgr_set_lcd_config); > > int dss_mgr_enable(enum omap_channel channel) > { > + if (dispc_mgr_is_enabled(channel)) > + return 0; > + > return dss_mgr_ops->enable(channel); > } > EXPORT_SYMBOL(dss_mgr_enable); > > void dss_mgr_disable(enum omap_channel channel) > { > + if (!dispc_mgr_is_enabled(channel)) > + return; > + > dss_mgr_ops->disable(channel); > } > EXPORT_SYMBOL(dss_mgr_disable); > diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c > b/drivers/gpu/drm/omapdrm/omap_crtc.c > index 4b7e16786e1e..a0c26592fc69 100644 > --- a/drivers/gpu/drm/omapdrm/omap_crtc.c > +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c > @@ -141,9 +141,6 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, > bool enable) > return; > } > > - if (dispc_mgr_is_enabled(channel) == enable) > - return; > - > if (omap_crtc->channel == OMAP_DSS_CHANNEL_DIGIT) { > /* >* Digit output produces some sync lost interrupts during the > With this change omap_crtc_set_enabled() will do extra work if the output is already enabled/disabled, and, if I'm not mistaken, will do omap_irq_wait() there which might lead to issues. If you remove the check, then I think the driver should make sure that omap_crtc_set_enabled() is not called if the output is already enabled/disabled. Maybe that can be done in omap_crtc_dss_enable/disable, using the new enabled flag. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/2974e9b7/attachment-0001.sig>
[PATCH v3 10/20] drm: omapdrm: Only commit planes on active CRTCs
On 19/09/16 15:27, Laurent Pinchart wrote: > The DRM core supports skipping plane update for inactive CRTCs for > hardware that don't need it or can't cope with it. That's our case, so > use the DRM core infrastructure instead of reinventing it. I don't follow this desc. What is omapdrm reinventing? At least this patch does not remove any of the "reinvention". What does DRM_PLANE_COMMIT_ACTIVE_ONLY do? Skips plane HW configuration for planes on crtcs that are disabled? The plane HW config will still be done when the crtc is about to be enabled, right? Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/fb515fbd/attachment-0001.sig>
[PATCH][V2] drm/amdgpu: avoid out of bounds access on array interrupt_status_offsets
From: Colin Ian King The check for an out of bound index into array interrupt_status_offsets is off-by-one. Fix this and also don't compared to a hard coded array size but use adev->mode_info.num_hpd instead. Signed-off-by: Colin Ian King --- drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c index d3512f3..4ce4c1a 100644 --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c @@ -2782,7 +2782,7 @@ static int dce_v6_0_hpd_irq(struct amdgpu_device *adev, uint32_t disp_int, mask, int_control, tmp; unsigned hpd; - if (entry->src_data > 6) { + if (entry->src_data >= adev->mode_info.num_hpd) { DRM_DEBUG("Unhandled interrupt: %d %d\n", entry->src_id, entry->src_data); return 0; } -- 2.9.3
[PATCH v3 09/20] drm: omapdrm: Replace DSS manager state check with omapdrm CRTC state
On 19/09/16 15:27, Laurent Pinchart wrote: > Instead of conditioning planes update based on the DD manager state, use s/DD/DSS/ Maybe "manager HW state" to highlight that the status is read from a HW register. > the enabled field newly added to the omap_crtc structure. This reduces > the dependency from the DRM layer to the DSS layer. > > The enabled field is a transitory measure, the implementation should use > the CRTC atomic state instead. However, given that CRTCs are currently > not enabled/disabled through their .enable() and .disable() operations > but through a convoluted code paths starting at the associated encoder > operations, there is not clear guarantee that the atomic state always > matches the hardware state. This will be refactored later, at which > point the enabled field will be removed. > > Signed-off-by: Laurent Pinchart > --- > Changes since v2: > > - Use enabled field in struct omap_crtc instead of CRTC atomic state > --- > drivers/gpu/drm/omapdrm/omap_crtc.c | 22 +- > 1 file changed, 13 insertions(+), 9 deletions(-) > > diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c > b/drivers/gpu/drm/omapdrm/omap_crtc.c > index cdcfda31043e..f41a638c8d65 100644 > --- a/drivers/gpu/drm/omapdrm/omap_crtc.c > +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c > @@ -40,6 +40,7 @@ struct omap_crtc { > > bool ignore_digit_sync_lost; > > + bool enabled; > bool pending; > wait_queue_head_t pending_wait; > }; > @@ -136,6 +137,7 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, > bool enable) > > if (omap_crtc_output[channel]->output_type == OMAP_DISPLAY_TYPE_HDMI) { > dispc_mgr_enable(channel, enable); > + omap_crtc->enabled = enable; > return; > } > > @@ -172,6 +174,7 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, > bool enable) > } > > dispc_mgr_enable(channel, enable); > + omap_crtc->enabled = enable; omap_crtc_set_enabled() is only called from omap_crtc_dss_enable() and omap_crtc_dss_disable(). It's probably a bit cleaner to set the omap_crtc->enabled in those functions. Btw, omap_crtc_set_enabled() has a comment: /* Called only from the encoder enable/disable and suspend/resume handlers. */ which doesn't seem to hold true... Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/473f9457/attachment-0001.sig>
[PATCH] drm/amdgpu: avoid out of bounds access on array interrupt_status_offsets
On 20/09/16 16:39, Alex Deucher wrote: > On Tue, Sep 20, 2016 at 11:16 AM, Colin King > wrote: >> From: Colin Ian King >> >> The check for an out of bound index into array interrupt_status_offsets >> is off-by-one. Fix this and also don't compared to a hard coded array >> size but use ARRAY_SIZE instead. >> >> Signed-off-by: Colin Ian King >> --- >> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c >> b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c >> index d3512f3..4ce4c1a 100644 >> --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c >> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c >> @@ -2782,7 +2782,7 @@ static int dce_v6_0_hpd_irq(struct amdgpu_device *adev, >> uint32_t disp_int, mask, int_control, tmp; >> unsigned hpd; >> >> - if (entry->src_data > 6) { >> + if (entry->src_data >= ARRAY_SIZE(interrupt_status_offsets)) { > > This should actually be adev->mode_info.num_hpd as some asic variants > may not have 6 hpd lines. Thanks for catching this. > > Alex Ah, that's a better way, so: if (entry->src_data >= adev->mode_info.num_hpd) { ... I'll send V2 > >> DRM_DEBUG("Unhandled interrupt: %d %d\n", entry->src_id, >> entry->src_data); >> return 0; >> } >> -- >> 2.9.3 >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 08/20] drm: omapdrm: Handle OCP error IRQ directly
On 19/09/16 15:27, Laurent Pinchart wrote: > Instead of going through a complicated registration mechanism, just > call the OCP error IRQ handler directly from the main IRQ handler. > > Signed-off-by: Laurent Pinchart > --- > Changes since v1: > > - Rename IRQ handler to omap_irq_ocp_error_handler() > - Replace hex error value with "OCP error" message > --- > drivers/gpu/drm/omapdrm/omap_drv.h | 1 - > drivers/gpu/drm/omapdrm/omap_irq.c | 28 ++-- > 2 files changed, 10 insertions(+), 19 deletions(-) > > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h > b/drivers/gpu/drm/omapdrm/omap_drv.h > index 7a1d8384147c..05375bc40091 100644 > --- a/drivers/gpu/drm/omapdrm/omap_drv.h > +++ b/drivers/gpu/drm/omapdrm/omap_drv.h > @@ -103,7 +103,6 @@ struct omap_drm_private { > /* irq handling: */ > struct list_head irq_list;/* list of omap_drm_irq */ > uint32_t irq_mask; /* enabled irqs in addition to irq_list > */ > - struct omap_drm_irq error_handler; > > /* atomic commit */ > struct { > diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c > b/drivers/gpu/drm/omapdrm/omap_irq.c > index f0f110faf1e6..257c1f3c76f3 100644 > --- a/drivers/gpu/drm/omapdrm/omap_irq.c > +++ b/drivers/gpu/drm/omapdrm/omap_irq.c > @@ -21,12 +21,6 @@ > > static DEFINE_SPINLOCK(list_lock); > > -static void omap_irq_error_handler(struct omap_drm_irq *irq, > - uint32_t irqstatus) > -{ > - DRM_ERROR("errors: %08x\n", irqstatus); > -} > - > /* call with list_lock and dispc runtime held */ > static void omap_irq_update(struct drm_device *dev) > { > @@ -224,6 +218,14 @@ static void omap_irq_fifo_underflow(struct > omap_drm_private *priv, > pr_cont("(0x%08x)\n", irqstatus); > } > > +static void omap_irq_ocp_error_handler(u32 irqstatus) > +{ > + if (!(irqstatus & DISPC_IRQ_OCP_ERR)) > + return; > + > + DRM_ERROR("OCP error\n"); > +} > + > static irqreturn_t omap_irq_handler(int irq, void *arg) > { > struct drm_device *dev = (struct drm_device *) arg; > @@ -250,6 +252,7 @@ static irqreturn_t omap_irq_handler(int irq, void *arg) > omap_crtc_error_irq(crtc, irqstatus); > } > > + omap_irq_ocp_error_handler(irqstatus); > omap_irq_fifo_underflow(priv, irqstatus); > > spin_lock_irqsave(&list_lock, flags); > @@ -282,7 +285,6 @@ static const u32 error_irqs[] = { > int omap_drm_irq_install(struct drm_device *dev) > { > struct omap_drm_private *priv = dev->dev_private; > - struct omap_drm_irq *error_handler = &priv->error_handler; > unsigned int num_mgrs = dss_feat_get_num_mgrs(); > unsigned int max_planes; > unsigned int i; > @@ -290,7 +292,7 @@ int omap_drm_irq_install(struct drm_device *dev) > > INIT_LIST_HEAD(&priv->irq_list); > > - priv->irq_mask = 0; > + priv->irq_mask = DISPC_IRQ_OCP_ERR; > > max_planes = min(ARRAY_SIZE(priv->planes), ARRAY_SIZE(error_irqs)); > for (i = 0; i < max_planes; ++i) { > @@ -309,16 +311,6 @@ int omap_drm_irq_install(struct drm_device *dev) > if (ret < 0) > return ret; > > - error_handler->irq = omap_irq_error_handler; > - error_handler->irqmask = DISPC_IRQ_OCP_ERR; > - > - /* for now ignore DISPC_IRQ_SYNC_LOST_DIGIT.. really I think > - * we just need to ignore it while enabling tv-out > - */ > - error_handler->irqmask &= ~DISPC_IRQ_SYNC_LOST_DIGIT; > - > - omap_irq_register(dev, error_handler); > - > dev->irq_enabled = true; > > return 0; > The removal of DISPC_IRQ_SYNC_LOST_DIGIT code above feels a bit out of place for this patch. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/0156bcb1/attachment-0001.sig>
[RFC 2/2] drm/exynos: mixer: configure layers once in mixer_atomic_flush()
On 20.09.2016 16:09, Tobias Jakobi wrote: > Hi Andrzej, > > > Andrzej Hajda wrote: >> On 20.09.2016 14:34, Andrzej Hajda wrote: >>> On 20.09.2016 13:23, Tobias Jakobi wrote: Hello Andrzej, first of all, I've noticed an error myself. mixer_disable() calls mixer_disable_plane(), so it should also be modified. I'll send a v2 later. Now to your points... Andrzej Hajda wrote: > On 19.09.2016 16:16, Tobias Jakobi wrote: >> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once >> in mixer_cfg_layer(). >> Trigger this via atomic flush. >> >> Signed-off-by: Tobias Jakobi >> --- >> drivers/gpu/drm/exynos/exynos_mixer.c | 104 >> ++ >> drivers/gpu/drm/exynos/regs-mixer.h | 2 + >> 2 files changed, 69 insertions(+), 37 deletions(-) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c >> b/drivers/gpu/drm/exynos/exynos_mixer.c >> index 1e78d57..d4efd9c 100644 >> --- a/drivers/gpu/drm/exynos/exynos_mixer.c >> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c >> @@ -99,6 +99,7 @@ struct mixer_context { >> struct drm_device *drm_dev; >> struct exynos_drm_crtc *crtc; >> struct exynos_drm_plane planes[MIXER_WIN_NR]; >> +unsigned long state_cache; > The name of the variable is cryptic. Yes, I'll try to come up with something better. It would probably be easier if struct mixer_context had a documentation for its fields. Anyway, any suggestions? >>> (active|enabled)_(planes|windows), or sth similar? > Thanks, I think I'll go with the 'window' terminology then. > > >> int pipe; >> unsigned long flags; >> >> @@ -418,37 +419,68 @@ static void mixer_cfg_rgb_fmt(struct mixer_context >> *ctx, unsigned int height) >> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK); >> } >> >> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win, >> -unsigned int priority, bool enable) >> +static void mixer_cfg_layer(struct mixer_context *ctx) >> { >> struct mixer_resources *res = &ctx->mixer_res; >> -u32 val = enable ? ~0 : 0; >> - >> -switch (win) { >> -case 0: >> -mixer_reg_writemask(res, MXR_CFG, val, >> MXR_CFG_GRP0_ENABLE); >> -mixer_reg_writemask(res, MXR_LAYER_CFG, >> -MXR_LAYER_CFG_GRP0_VAL(priority), >> -MXR_LAYER_CFG_GRP0_MASK); >> -break; >> -case 1: >> -mixer_reg_writemask(res, MXR_CFG, val, >> MXR_CFG_GRP1_ENABLE); >> -mixer_reg_writemask(res, MXR_LAYER_CFG, >> -MXR_LAYER_CFG_GRP1_VAL(priority), >> -MXR_LAYER_CFG_GRP1_MASK); >> +unsigned int win; >> >> -break; >> -case VP_DEFAULT_WIN: >> -if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) { >> -vp_reg_writemask(res, VP_ENABLE, val, >> VP_ENABLE_ON); >> -mixer_reg_writemask(res, MXR_CFG, val, >> -MXR_CFG_VP_ENABLE); >> -mixer_reg_writemask(res, MXR_LAYER_CFG, >> - >> MXR_LAYER_CFG_VP_VAL(priority), >> -MXR_LAYER_CFG_VP_MASK); >> +struct exynos_drm_plane_state *state; >> +struct drm_framebuffer *fb; >> +unsigned int priority; >> +u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0; >> +bool enable; >> + >> +for (win = 0; win < MIXER_WIN_NR; ++win) { >> +state = >> to_exynos_plane_state(ctx->planes[win].base.state); >> +fb = state->fb; >> + >> +priority = state->base.normalized_zpos + 1; >> +enable = test_bit(win, &ctx->state_cache); >> + >> +if (!enable) >> +continue; >> + >> +switch (win) { >> +case 0: >> +mxr_cfg |= MXR_CFG_GRP0_ENABLE; >> +mxr_layer_cfg |= >> MXR_LAYER_CFG_GRP0_VAL(priority); >> +break; >> + >> +case 1: >> +mxr_cfg |= MXR_CFG_GRP1_ENABLE; >> +mxr_layer_cfg |= >> MXR_LAYER_CFG_GRP1_VAL(priority); >> +break; >> + >> +case VP_DEFAULT_WIN: >> +
[PATCH v3 06/20] drm: omapdrm: Handle FIFO underflow IRQs internally
On 19/09/16 15:27, Laurent Pinchart wrote: > As the FIFO underflow IRQ handler just prints an error message to the > kernel log, simplify the code by not registering one IRQ handler per > plane but print the messages directly from the main IRQ handler. > > Signed-off-by: Laurent Pinchart > --- > Changes since v1: > > - Only register error IRQs that exist on the HW > --- > +static const u32 error_irqs[] = { > + [OMAP_DSS_GFX] = DISPC_IRQ_GFX_FIFO_UNDERFLOW, > + [OMAP_DSS_VIDEO1] = DISPC_IRQ_VID1_FIFO_UNDERFLOW, > + [OMAP_DSS_VIDEO2] = DISPC_IRQ_VID2_FIFO_UNDERFLOW, > + [OMAP_DSS_VIDEO3] = DISPC_IRQ_VID3_FIFO_UNDERFLOW, > +}; Actually, one comment: "error_irqs" is perhaps not a good name for this. "omap_underflow_irqs"? Or actually, maybe it would make sense to move this into dispc, and have a similar func to dispc_mgr_get_sync_lost_irq(). Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/7411a729/attachment-0001.sig>
[PATCH v3 06/20] drm: omapdrm: Handle FIFO underflow IRQs internally
On 19/09/16 15:27, Laurent Pinchart wrote: > As the FIFO underflow IRQ handler just prints an error message to the > kernel log, simplify the code by not registering one IRQ handler per > plane but print the messages directly from the main IRQ handler. > > Signed-off-by: Laurent Pinchart > --- > Changes since v1: > > - Only register error IRQs that exist on the HW > --- > drivers/gpu/drm/omapdrm/omap_drv.c | 4 +-- > drivers/gpu/drm/omapdrm/omap_drv.h | 2 +- > drivers/gpu/drm/omapdrm/omap_irq.c | 66 > ++-- > drivers/gpu/drm/omapdrm/omap_plane.c | 24 - > 4 files changed, 66 insertions(+), 30 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/0d488b54/attachment-0001.sig>
[PATCH] drm/amdgpu: avoid out of bounds access on array interrupt_status_offsets
From: Colin Ian King The check for an out of bound index into array interrupt_status_offsets is off-by-one. Fix this and also don't compared to a hard coded array size but use ARRAY_SIZE instead. Signed-off-by: Colin Ian King --- drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c index d3512f3..4ce4c1a 100644 --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c @@ -2782,7 +2782,7 @@ static int dce_v6_0_hpd_irq(struct amdgpu_device *adev, uint32_t disp_int, mask, int_control, tmp; unsigned hpd; - if (entry->src_data > 6) { + if (entry->src_data >= ARRAY_SIZE(interrupt_status_offsets)) { DRM_DEBUG("Unhandled interrupt: %d %d\n", entry->src_id, entry->src_data); return 0; } -- 2.9.3
[RFC 2/2] drm/exynos: mixer: configure layers once in mixer_atomic_flush()
Hi Andrzej, Andrzej Hajda wrote: > On 20.09.2016 14:34, Andrzej Hajda wrote: >> On 20.09.2016 13:23, Tobias Jakobi wrote: >>> Hello Andrzej, >>> >>> first of all, I've noticed an error myself. mixer_disable() calls >>> mixer_disable_plane(), so it should also be modified. I'll send a v2 later. >>> >>> Now to your points... >>> >>> >>> Andrzej Hajda wrote: On 19.09.2016 16:16, Tobias Jakobi wrote: > Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once > in mixer_cfg_layer(). > Trigger this via atomic flush. > > Signed-off-by: Tobias Jakobi > --- > drivers/gpu/drm/exynos/exynos_mixer.c | 104 > ++ > drivers/gpu/drm/exynos/regs-mixer.h | 2 + > 2 files changed, 69 insertions(+), 37 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c > b/drivers/gpu/drm/exynos/exynos_mixer.c > index 1e78d57..d4efd9c 100644 > --- a/drivers/gpu/drm/exynos/exynos_mixer.c > +++ b/drivers/gpu/drm/exynos/exynos_mixer.c > @@ -99,6 +99,7 @@ struct mixer_context { > struct drm_device *drm_dev; > struct exynos_drm_crtc *crtc; > struct exynos_drm_plane planes[MIXER_WIN_NR]; > + unsigned long state_cache; The name of the variable is cryptic. >>> Yes, I'll try to come up with something better. It would probably be >>> easier if struct mixer_context had a documentation for its fields. >>> >>> Anyway, any suggestions? >> (active|enabled)_(planes|windows), or sth similar? Thanks, I think I'll go with the 'window' terminology then. > int pipe; > unsigned long flags; > > @@ -418,37 +419,68 @@ static void mixer_cfg_rgb_fmt(struct mixer_context > *ctx, unsigned int height) > mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK); > } > > -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win, > - unsigned int priority, bool enable) > +static void mixer_cfg_layer(struct mixer_context *ctx) > { > struct mixer_resources *res = &ctx->mixer_res; > - u32 val = enable ? ~0 : 0; > - > - switch (win) { > - case 0: > - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE); > - mixer_reg_writemask(res, MXR_LAYER_CFG, > - MXR_LAYER_CFG_GRP0_VAL(priority), > - MXR_LAYER_CFG_GRP0_MASK); > - break; > - case 1: > - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE); > - mixer_reg_writemask(res, MXR_LAYER_CFG, > - MXR_LAYER_CFG_GRP1_VAL(priority), > - MXR_LAYER_CFG_GRP1_MASK); > + unsigned int win; > > - break; > - case VP_DEFAULT_WIN: > - if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) { > - vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON); > - mixer_reg_writemask(res, MXR_CFG, val, > - MXR_CFG_VP_ENABLE); > - mixer_reg_writemask(res, MXR_LAYER_CFG, > - MXR_LAYER_CFG_VP_VAL(priority), > - MXR_LAYER_CFG_VP_MASK); > + struct exynos_drm_plane_state *state; > + struct drm_framebuffer *fb; > + unsigned int priority; > + u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0; > + bool enable; > + > + for (win = 0; win < MIXER_WIN_NR; ++win) { > + state = to_exynos_plane_state(ctx->planes[win].base.state); > + fb = state->fb; > + > + priority = state->base.normalized_zpos + 1; > + enable = test_bit(win, &ctx->state_cache); > + > + if (!enable) > + continue; > + > + switch (win) { > + case 0: > + mxr_cfg |= MXR_CFG_GRP0_ENABLE; > + mxr_layer_cfg |= MXR_LAYER_CFG_GRP0_VAL(priority); > + break; > + > + case 1: > + mxr_cfg |= MXR_CFG_GRP1_ENABLE; > + mxr_layer_cfg |= MXR_LAYER_CFG_GRP1_VAL(priority); > + break; > + > + case VP_DEFAULT_WIN: > + vp_enable = VP_ENABLE_ON; > + mxr_cfg |= MXR_CFG_VP_ENABLE; > + mxr_layer_cfg |= MXR_LAYER_CFG_VP_VAL(priority); > + break; > + } > + > + if (!fb) > + continue; > + > + /* > + * TODO: Don't enable alpha blending for the bottom window. > + */ > + switch (win) { > + case 0: > + case 1: > + mixer_cfg_gfx_blend(ctx, win, > is_alpha_format(fb->pixel_format)); > +
[PATCH v3 04/20] drm: omapdrm: fb: Simplify mode command checks when creating framebuffer
On 19/09/16 15:27, Laurent Pinchart wrote: > The hardware requires all planes to have an identical pitch in number of > pixels. Given that all supported formats use the same number of bytes > per pixel in all planes, framebuffer creation checks can be simplified. > The implementations assumes that no format use more than two planes > which is true with the existing hardware. > > Signed-off-by: Laurent Pinchart > --- > Changes since v1: > > - Clarify commit message and mention explicitly in the code that only > one and two planes formats are supported. > - Rebase on top of the switch to drm_format_info() > --- > drivers/gpu/drm/omapdrm/omap_fb.c | 58 > +-- > 1 file changed, 31 insertions(+), 27 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/cf4f7ff1/attachment-0001.sig>
[Bug 97806] GPU lockup with mesa-git and llvm-svn with rx 470 on Unigine Heaven and TombRaider 2013
https://bugs.freedesktop.org/show_bug.cgi?id=97806 --- Comment #7 from Laurent carlier --- I have the gpu lockup with Unigine Heaven only when tesselation is enabled regardless of the level -- 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/20160920/4ccad3e7/attachment-0001.html>
[PATCH v3 02/20] drm: omapdrm: fb: Use format information provided by the DRM core
On 19/09/16 15:27, Laurent Pinchart wrote: > The driver stores in a custom structure named format several pieces of > information about the format that are available in the DRM core. Remove > them and get the information from the DRM core instead. > > Signed-off-by: Laurent Pinchart > --- > @@ -128,13 +122,13 @@ static const struct drm_framebuffer_funcs > omap_framebuffer_funcs = { > }; > > static uint32_t get_linear_addr(struct plane *plane, > - const struct format *format, int n, int x, int y) > + const struct drm_format_info *format, int n, int x, int y) > { > uint32_t offset; > > - offset = plane->offset + > - (x * format->planes[n].stride_bpp) + > - (y * plane->pitch / format->planes[n].sub_y); > + offset = plane->offset > ++ (x * format->cpp[n] / (n == 1 ? 1 : format->hsub)) > ++ (y * plane->pitch / (n == 1 ? 1 : format->vsub)); n is the plane number? Shouldn't the above be (n == 0 ? 1 : format->hsub)? > @@ -413,28 +410,32 @@ struct drm_framebuffer *omap_framebuffer_init(struct > drm_device *dev, > > fb = &omap_fb->base; > omap_fb->format = format; > + omap_fb->dss_format = dss_format; > mutex_init(&omap_fb->lock); > > - for (i = 0; i < n; i++) { > + for (i = 0; i < format->num_planes; i++) { > struct plane *plane = &omap_fb->planes[i]; > - int size, pitch = mode_cmd->pitches[i]; > + unsigned int pitch = mode_cmd->pitches[i]; > + unsigned int hsub = i == 0 ? 1 : format->hsub; > + unsigned int vsub = i == 0 ? 1 : format->vsub; This makes me wonder... Will all drivers do something like the above? It's a bit laborious way to get the pixel subsampling factor, and I presume something like above is quite common so that all the calculations can be more generic (and not specific to a UV plane). Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/3b233bda/attachment-0001.sig>
[PATCH 6/6] GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data()
On Tue, Sep 20, 2016 at 01:08:12PM +0300, Jani Nikula wrote: > On Tue, 20 Sep 2016, SF Markus Elfring > wrote: > > From: Markus Elfring > > Date: Tue, 20 Sep 2016 10:40:22 +0200 > > > > * Adjust a jump target. > > Please don't. > Also there is nothing in CodingStyle that prohibits out: labels. I wrote that section and I wrote it in a deliberately way because no one wants to see a bunch of "cleanup" patches that change the label names for no reason. People have been complaining about this in the kernel-summit mailing list as if CodingStyle bans out labels and that it's my fault. Neither of these complaints are accurate. regards, dan carpenter
[PULL] sti-drm-next-2016-09-20
Hi Dave, Here are some patches for drm-next. It contains: - minor fixes for typo and warning. - sparse and coccicheck warning fixes - bunch of patches fixing issues found while testing drm/sti with an atomic version of weston - the removal of the support of stih415-416 sti platform Regards, Vincent The following changes since commit d27cd40addc06d34236bf818abcbe76f3527a69d: drm: sti: Replace drm_fb_get_bpp_depth() with drm_format_plane_cpp() (2016-09-20 11:32:04 +0200) are available in the git repository at: https://github.com/vinceab/linux.git sti-drm-next-2016-09-20 for you to fetch changes up to b4bba92dfbe23ccc4f1f6c93db88c39c10aa075a: drm/sti: remove stih415-416 platform support (2016-09-20 15:03:33 +0200) Benjamin Gaignard (1): drm: sti: fix coccicheck warnings Fabien Dessenne (8): drm/sti: fix debug logs drm/sti: run hqvdp init sequence only once drm/sti: run gdp init sequence only once drm/sti: fix atomic_disable check drm/sti: use different notifier_block for each pipe drm/sti: use vtg array instead of vtg_main/aux drm/sti: in crtc_atomic_flush, enable only planes of this crtc drm/sti: use valid video mode Ville Syrjälä (1): drm/sti: Fix sparse warnings Vincent Abriou (3): drm/sti: dpms function missing for HDMI connector drm/sti: fix compositor debugfs creation drm/sti: remove stih415-416 platform support drivers/gpu/drm/sti/Kconfig| 6 +- drivers/gpu/drm/sti/Makefile | 1 - drivers/gpu/drm/sti/sti_compositor.c | 51 ++--- drivers/gpu/drm/sti/sti_compositor.h | 14 +- drivers/gpu/drm/sti/sti_crtc.c | 26 +-- drivers/gpu/drm/sti/sti_cursor.c | 8 +- drivers/gpu/drm/sti/sti_drv.c | 2 +- drivers/gpu/drm/sti/sti_dvo.c | 3 +- drivers/gpu/drm/sti/sti_gdp.c | 29 ++- drivers/gpu/drm/sti/sti_hda.c | 39 +--- drivers/gpu/drm/sti/sti_hdmi.c | 31 +-- drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 336 - drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h | 14 -- drivers/gpu/drm/sti/sti_hqvdp.c| 25 +-- drivers/gpu/drm/sti/sti_mixer.c| 19 -- drivers/gpu/drm/sti/sti_tvout.c| 41 +--- drivers/gpu/drm/sti/sti_vid.c | 4 +- drivers/gpu/drm/sti/sti_vtac.c | 2 + drivers/gpu/drm/sti/sti_vtg.c | 3 +- 19 files changed, 96 insertions(+), 558 deletions(-) delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h
Kernel stability on baytrail machines
Hi, I think there might be another clue on this one. One of the comments is also mentioning an unfixed erratum of certain Baytrail processors, named as "EOI Transaction May Not be Sent if Software Enters Core C6 During an Interrupt Service Routine". This erratum can be found on several different processors, even on several non-baytrails, like Inte Xeon 3400 and similar. I also came across a patch that was created for SUSE and that seems to be adressing this issue in pre 4.X kernels: https://build.opensuse.org/package/view_file?file=22160-Intel-C6-EOI.patch&package=xen&project=home%3Acharlesa%3AopenSUSE11.3&rev=7 --- Michal Dne 18.7.2016 15:30, One Thousand Gnomes napsal: > On Tue, 12 Jul 2016 16:41:58 -0300 > Ezequiel Garcia wrote: > >> Hi Alan, >> >> (Adding interested people to this thread) >> >> On 09 Apr 08:14 PM, One Thousand Gnomes wrote: >> > > > I do feel that the importance of the mentioned bug is currently >> > > > underestimated. Can anyone here give a note, how much current linux >> > > > kernel is supposed to be stable on general baytrail machines? >> > > >> > > If you did not get any replies... you might want to check MAINTAINERS >> > > file, and >> > > put Intel x86 maintainers on Cc list. >> > > >> > > I'm sure someone cares :-). >> > >> > Yes we care, and there are people looking at the various reports. >> > >> >> Are there any updates on the status of this issue? >> >> The current bugzilla report [1] marks this as a power management >> issue. However, many reports indicate that it would only freeze >> when running X, so it's not completely clear if it's related to >> the gfx driver too. > > There are two things we are currently tracking. One of them was merged > which seems to have made my machine stable at least and fixes a problem > related to the MMC. The second one we may need is a power related > changed > to SPI to hold the CPU in C0/C1 whenever the ACPI _SEM is held. > > Graphics shows these problems up because of the way the GPU causes > power > state changes. > > Alan
[PATCH 5/6] GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()
On Tue, 20 Sep 2016, Dan Carpenter wrote: > Don't be a dummy... This is easy to review an it fixes a bug. > > I'm fine with you NAKing all these patches based on who they are from. > I mostly just delete these without responding because the guy has > history of introducing bugs and never listens to feedback. But asking > pointless rhetorical questions is not helpful. > > A lot of people are CC'd and you're wasting everyone's time by asking > questions where you know the answer. Fair enough, sorry for the noise. To be honest, I did only look at the patches, not who they were from. We have CI for drm/i915, but I don't think it's constructive to keep changing drivers like this where the upstream isn't actively developed and tested. But I digress. It's up to Patrik anyway. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[RFC 2/2] drm/exynos: mixer: configure layers once in mixer_atomic_flush()
On 20.09.2016 14:34, Andrzej Hajda wrote: > On 20.09.2016 13:23, Tobias Jakobi wrote: >> Hello Andrzej, >> >> first of all, I've noticed an error myself. mixer_disable() calls >> mixer_disable_plane(), so it should also be modified. I'll send a v2 later. >> >> Now to your points... >> >> >> Andrzej Hajda wrote: >>> On 19.09.2016 16:16, Tobias Jakobi wrote: Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once in mixer_cfg_layer(). Trigger this via atomic flush. Signed-off-by: Tobias Jakobi --- drivers/gpu/drm/exynos/exynos_mixer.c | 104 ++ drivers/gpu/drm/exynos/regs-mixer.h | 2 + 2 files changed, 69 insertions(+), 37 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 1e78d57..d4efd9c 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -99,6 +99,7 @@ struct mixer_context { struct drm_device *drm_dev; struct exynos_drm_crtc *crtc; struct exynos_drm_plane planes[MIXER_WIN_NR]; + unsigned long state_cache; >>> The name of the variable is cryptic. >> Yes, I'll try to come up with something better. It would probably be >> easier if struct mixer_context had a documentation for its fields. >> >> Anyway, any suggestions? > (active|enabled)_(planes|windows), or sth similar? > >> int pipe; unsigned long flags; @@ -418,37 +419,68 @@ static void mixer_cfg_rgb_fmt(struct mixer_context *ctx, unsigned int height) mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK); } -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win, - unsigned int priority, bool enable) +static void mixer_cfg_layer(struct mixer_context *ctx) { struct mixer_resources *res = &ctx->mixer_res; - u32 val = enable ? ~0 : 0; - - switch (win) { - case 0: - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE); - mixer_reg_writemask(res, MXR_LAYER_CFG, - MXR_LAYER_CFG_GRP0_VAL(priority), - MXR_LAYER_CFG_GRP0_MASK); - break; - case 1: - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE); - mixer_reg_writemask(res, MXR_LAYER_CFG, - MXR_LAYER_CFG_GRP1_VAL(priority), - MXR_LAYER_CFG_GRP1_MASK); + unsigned int win; - break; - case VP_DEFAULT_WIN: - if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) { - vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON); - mixer_reg_writemask(res, MXR_CFG, val, - MXR_CFG_VP_ENABLE); - mixer_reg_writemask(res, MXR_LAYER_CFG, - MXR_LAYER_CFG_VP_VAL(priority), - MXR_LAYER_CFG_VP_MASK); + struct exynos_drm_plane_state *state; + struct drm_framebuffer *fb; + unsigned int priority; + u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0; + bool enable; + + for (win = 0; win < MIXER_WIN_NR; ++win) { + state = to_exynos_plane_state(ctx->planes[win].base.state); + fb = state->fb; + + priority = state->base.normalized_zpos + 1; + enable = test_bit(win, &ctx->state_cache); + + if (!enable) + continue; + + switch (win) { + case 0: + mxr_cfg |= MXR_CFG_GRP0_ENABLE; + mxr_layer_cfg |= MXR_LAYER_CFG_GRP0_VAL(priority); + break; + + case 1: + mxr_cfg |= MXR_CFG_GRP1_ENABLE; + mxr_layer_cfg |= MXR_LAYER_CFG_GRP1_VAL(priority); + break; + + case VP_DEFAULT_WIN: + vp_enable = VP_ENABLE_ON; + mxr_cfg |= MXR_CFG_VP_ENABLE; + mxr_layer_cfg |= MXR_LAYER_CFG_VP_VAL(priority); + break; + } + + if (!fb) + continue; + + /* + * TODO: Don't enable alpha blending for the bottom window. + */ + switch (win) { + case 0: + case 1: + mixer_cfg_gfx_blend(ctx, win, is_alpha_format(fb->pixel_format)); + break; + + case VP_DEFAULT_WIN: + mixer_cfg_vp_blend(ctx); + break;
[PATCH v2] drm/sti: remove stih415-416 platform support
Acked-by: Benjamin Gaignard 2016-09-20 11:25 GMT+02:00 Vincent Abriou : > stih415 and stih416 platform are obsolete and no more supported. > Only stih407 and stih410 platform are maintained. > > Signed-off-by: Vincent Abriou > --- > drivers/gpu/drm/sti/Kconfig| 6 +- > drivers/gpu/drm/sti/Makefile | 1 - > drivers/gpu/drm/sti/sti_compositor.c | 19 -- > drivers/gpu/drm/sti/sti_hda.c | 39 +--- > drivers/gpu/drm/sti/sti_hdmi.c | 20 -- > drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 336 > - > drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h | 14 -- > drivers/gpu/drm/sti/sti_mixer.c| 19 -- > drivers/gpu/drm/sti/sti_tvout.c| 40 +--- > 9 files changed, 14 insertions(+), 480 deletions(-) > delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c > delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h > > diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig > index 494ab25..acd7286 100644 > --- a/drivers/gpu/drm/sti/Kconfig > +++ b/drivers/gpu/drm/sti/Kconfig > @@ -1,6 +1,6 @@ > config DRM_STI > - tristate "DRM Support for STMicroelectronics SoC stiH41x Series" > - depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM) > + tristate "DRM Support for STMicroelectronics SoC stiH4xx Series" > + depends on DRM && (ARCH_STI || ARCH_MULTIPLATFORM) > select RESET_CONTROLLER > select DRM_KMS_HELPER > select DRM_GEM_CMA_HELPER > @@ -9,4 +9,4 @@ config DRM_STI > select FW_LOADER > select SND_SOC_HDMI_CODEC if SND_SOC > help > - Choose this option to enable DRM on STM stiH41x chipset > + Choose this option to enable DRM on STM stiH4xx chipset > diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile > index b805762..d20f7c0 100644 > --- a/drivers/gpu/drm/sti/Makefile > +++ b/drivers/gpu/drm/sti/Makefile > @@ -9,7 +9,6 @@ sti-drm-y := \ > sti_crtc.o \ > sti_plane.o \ > sti_hdmi.o \ > - sti_hdmi_tx3g0c55phy.o \ > sti_hdmi_tx3g4c28phy.o \ > sti_dvo.o \ > sti_awg_utils.o \ > diff --git a/drivers/gpu/drm/sti/sti_compositor.c > b/drivers/gpu/drm/sti/sti_compositor.c > index a6f391b..f62041f 100644 > --- a/drivers/gpu/drm/sti/sti_compositor.c > +++ b/drivers/gpu/drm/sti/sti_compositor.c > @@ -39,22 +39,6 @@ static const struct sti_compositor_data > stih407_compositor_data = { > }, > }; > > -/* > - * stiH416 compositor properties > - * Note: > - * on stih416 MIXER_AUX has a different base address from MIXER_MAIN > - * Moreover, GDPx is different for Main and Aux Mixer. So this subdev map > does > - * not fit for stiH416 if we want to enable the MIXER_AUX. > - */ > -static const struct sti_compositor_data stih416_compositor_data = { > - .nb_subdev = 3, > - .subdev_desc = { > - {STI_GPD_SUBDEV, (int)STI_GDP_0, 0x100}, > - {STI_GPD_SUBDEV, (int)STI_GDP_1, 0x200}, > - {STI_MIXER_MAIN_SUBDEV, STI_MIXER_MAIN, 0xC00} > - }, > -}; > - > int sti_compositor_debugfs_init(struct sti_compositor *compo, > struct drm_minor *minor) > { > @@ -179,9 +163,6 @@ static const struct component_ops sti_compositor_ops = { > > static const struct of_device_id compositor_of_match[] = { > { > - .compatible = "st,stih416-compositor", > - .data = &stih416_compositor_data, > - }, { > .compatible = "st,stih407-compositor", > .data = &stih407_compositor_data, > }, { > diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c > index a225c4d..e7c243f 100644 > --- a/drivers/gpu/drm/sti/sti_hda.c > +++ b/drivers/gpu/drm/sti/sti_hda.c > @@ -62,14 +62,8 @@ > #define SCALE_CTRL_CR_DFLT 0x00DB0249 > > /* Video DACs control */ > -#define VIDEO_DACS_CONTROL_MASK 0x0FFF > -#define VIDEO_DACS_CONTROL_SYSCFG2535 0x085C /* for stih416 */ > -#define DAC_CFG_HD_OFF_SHIFT5 > -#define DAC_CFG_HD_OFF_MASK (0x7 << DAC_CFG_HD_OFF_SHIFT) > -#define VIDEO_DACS_CONTROL_SYSCFG5072 0x0120 /* for stih407 */ > #define DAC_CFG_HD_HZUVW_OFF_MASK BIT(1) > > - > /* Upsampler values for the alternative 2X Filter */ > #define SAMPLER_COEF_NB 8 > #define HDA_ANA_SRC_Y_CFG_ALT_2X0x0113 > @@ -300,28 +294,14 @@ static bool hda_get_mode_idx(struct drm_display_mode > mode, int *idx) > */ > static void hda_enable_hd_dacs(struct sti_hda *hda, bool enable) > { > - u32 mask; > - > if (hda->video_dacs_ctrl) { > u32 val; > > - switch ((u32)hda->video_dacs_ctrl & VIDEO_DACS_CONTROL_MASK) { > - case VIDEO_DACS_CONTROL_SYSCFG2535: > - mask = DAC_CFG_HD_OFF_MASK; > - b
[RFC 2/2] drm/exynos: mixer: configure layers once in mixer_atomic_flush()
On 20.09.2016 13:23, Tobias Jakobi wrote: > Hello Andrzej, > > first of all, I've noticed an error myself. mixer_disable() calls > mixer_disable_plane(), so it should also be modified. I'll send a v2 later. > > Now to your points... > > > Andrzej Hajda wrote: >> On 19.09.2016 16:16, Tobias Jakobi wrote: >>> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once >>> in mixer_cfg_layer(). >>> Trigger this via atomic flush. >>> >>> Signed-off-by: Tobias Jakobi >>> --- >>> drivers/gpu/drm/exynos/exynos_mixer.c | 104 >>> ++ >>> drivers/gpu/drm/exynos/regs-mixer.h | 2 + >>> 2 files changed, 69 insertions(+), 37 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c >>> b/drivers/gpu/drm/exynos/exynos_mixer.c >>> index 1e78d57..d4efd9c 100644 >>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c >>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c >>> @@ -99,6 +99,7 @@ struct mixer_context { >>> struct drm_device *drm_dev; >>> struct exynos_drm_crtc *crtc; >>> struct exynos_drm_plane planes[MIXER_WIN_NR]; >>> + unsigned long state_cache; >> The name of the variable is cryptic. > Yes, I'll try to come up with something better. It would probably be > easier if struct mixer_context had a documentation for its fields. > > Anyway, any suggestions? (active|enabled)_(planes|windows), or sth similar? > > >>> int pipe; >>> unsigned long flags; >>> >>> @@ -418,37 +419,68 @@ static void mixer_cfg_rgb_fmt(struct mixer_context >>> *ctx, unsigned int height) >>> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK); >>> } >>> >>> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win, >>> - unsigned int priority, bool enable) >>> +static void mixer_cfg_layer(struct mixer_context *ctx) >>> { >>> struct mixer_resources *res = &ctx->mixer_res; >>> - u32 val = enable ? ~0 : 0; >>> - >>> - switch (win) { >>> - case 0: >>> - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE); >>> - mixer_reg_writemask(res, MXR_LAYER_CFG, >>> - MXR_LAYER_CFG_GRP0_VAL(priority), >>> - MXR_LAYER_CFG_GRP0_MASK); >>> - break; >>> - case 1: >>> - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE); >>> - mixer_reg_writemask(res, MXR_LAYER_CFG, >>> - MXR_LAYER_CFG_GRP1_VAL(priority), >>> - MXR_LAYER_CFG_GRP1_MASK); >>> + unsigned int win; >>> >>> - break; >>> - case VP_DEFAULT_WIN: >>> - if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) { >>> - vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON); >>> - mixer_reg_writemask(res, MXR_CFG, val, >>> - MXR_CFG_VP_ENABLE); >>> - mixer_reg_writemask(res, MXR_LAYER_CFG, >>> - MXR_LAYER_CFG_VP_VAL(priority), >>> - MXR_LAYER_CFG_VP_MASK); >>> + struct exynos_drm_plane_state *state; >>> + struct drm_framebuffer *fb; >>> + unsigned int priority; >>> + u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0; >>> + bool enable; >>> + >>> + for (win = 0; win < MIXER_WIN_NR; ++win) { >>> + state = to_exynos_plane_state(ctx->planes[win].base.state); >>> + fb = state->fb; >>> + >>> + priority = state->base.normalized_zpos + 1; >>> + enable = test_bit(win, &ctx->state_cache); >>> + >>> + if (!enable) >>> + continue; >>> + >>> + switch (win) { >>> + case 0: >>> + mxr_cfg |= MXR_CFG_GRP0_ENABLE; >>> + mxr_layer_cfg |= MXR_LAYER_CFG_GRP0_VAL(priority); >>> + break; >>> + >>> + case 1: >>> + mxr_cfg |= MXR_CFG_GRP1_ENABLE; >>> + mxr_layer_cfg |= MXR_LAYER_CFG_GRP1_VAL(priority); >>> + break; >>> + >>> + case VP_DEFAULT_WIN: >>> + vp_enable = VP_ENABLE_ON; >>> + mxr_cfg |= MXR_CFG_VP_ENABLE; >>> + mxr_layer_cfg |= MXR_LAYER_CFG_VP_VAL(priority); >>> + break; >>> + } >>> + >>> + if (!fb) >>> + continue; >>> + >>> + /* >>> +* TODO: Don't enable alpha blending for the bottom window. >>> +*/ >>> + switch (win) { >>> + case 0: >>> + case 1: >>> + mixer_cfg_gfx_blend(ctx, win, >>> is_alpha_format(fb->pixel_format)); >>> + break; >>> + >>> + case VP_DEFAULT_WIN: >>> + mixer_cfg_vp_blend(ctx); >>> + break; >>> } >>> - break; >>> } >>> + >>> + if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags))
GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()
On Tue, Sep 20, 2016 at 01:03:06PM +0200, SF Markus Elfring wrote: > Are you looking for any special information to improve > a corresponding discussion? If you restricted yourself to only sending bug fixes and not sending any more cleanups that would be good. Please stop sending clean up patches. regards, dan carpenter
[STLinux Kernel] [PATCH v2] drm/sti: remove stih415-416 platform support
Hi Vincent, On Tue, 20 Sep 2016, Vincent Abriou wrote: > stih415 and stih416 platform are obsolete and no more supported. > Only stih407 and stih410 platform are maintained. > > Signed-off-by: Vincent Abriou Subject should have a v2, but apart from that: - Acked-by: Peter Griffin Peter.
[PATCH 5/6] GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()
On Tue, Sep 20, 2016 at 01:07:35PM +0300, Jani Nikula wrote: > On Tue, 20 Sep 2016, SF Markus Elfring > wrote: > > From: Markus Elfring > > Date: Tue, 20 Sep 2016 10:36:19 +0200 > > > > A single error message should be sufficient to inform about > > the detection of an unknown GCT revision at the end. > > Thus return after the logging call in this case directly. > > Did you test this? > Don't be a dummy... This is easy to review an it fixes a bug. I'm fine with you NAKing all these patches based on who they are from. I mostly just delete these without responding because the guy has history of introducing bugs and never listens to feedback. But asking pointless rhetorical questions is not helpful. A lot of people are CC'd and you're wasting everyone's time by asking questions where you know the answer. regards, dan carpenter
[PATCH 04/14] drm/arm: Fix sparse warnings
On Tue, Sep 20, 2016 at 09:06:24AM +0100, Liviu Dudau wrote: > On Mon, Sep 19, 2016 at 04:33:45PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrjälä > > > > drm/arm/malidp_planes.c:49:24: warning: symbol > > 'malidp_duplicate_plane_state' was not declared. Should it be static? > > drm/arm/malidp_planes.c:66:6: warning: symbol 'malidp_destroy_plane_state' > > was not declared. Should it be static? > > > > Cc: Liviu Dudau > BTW, I have already acked this patch when Baoyou Xie submitted it! https://lists.freedesktop.org/archives/dri-devel/2016-September/117624.html Maybe you should acknowledge his contribution if that was the case? Best regards, Liviu > Acked-by: Liviu Dudau > > Thanks for cleaning it up! > > Liviu > > > Cc: Brian Starkey > > Cc: Mali DP Maintainers > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/arm/malidp_planes.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/arm/malidp_planes.c > > b/drivers/gpu/drm/arm/malidp_planes.c > > index 82c193e5e0d6..cc9b8e02904d 100644 > > --- a/drivers/gpu/drm/arm/malidp_planes.c > > +++ b/drivers/gpu/drm/arm/malidp_planes.c > > @@ -46,7 +46,7 @@ static void malidp_de_plane_destroy(struct drm_plane > > *plane) > > devm_kfree(plane->dev->dev, mp); > > } > > > > -struct drm_plane_state *malidp_duplicate_plane_state(struct drm_plane > > *plane) > > +static struct drm_plane_state *malidp_duplicate_plane_state(struct > > drm_plane *plane) > > { > > struct malidp_plane_state *state, *m_state; > > > > @@ -63,8 +63,8 @@ struct drm_plane_state > > *malidp_duplicate_plane_state(struct drm_plane *plane) > > return &state->base; > > } > > > > -void malidp_destroy_plane_state(struct drm_plane *plane, > > - struct drm_plane_state *state) > > +static void malidp_destroy_plane_state(struct drm_plane *plane, > > + struct drm_plane_state *state) > > { > > struct malidp_plane_state *m_state = to_malidp_plane_state(state); > > > > -- > > 2.7.4 > > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ã)_/¯
GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()
> If you restricted yourself to only sending bug fixes and not sending > any more cleanups that would be good. Thanks for another bit of constructive feedback. > Please stop sending clean up patches. This will not happen for a while. I am in the process of informing various developers about some software update opportunities. The proposed changes will belong to a mixture of error categories as you observe them so far usually. The involved static source code analysis will point more details out for further considerations, won't it? Regards, Markus
[RFC 2/2] drm/exynos: mixer: configure layers once in mixer_atomic_flush()
Hello Andrzej, first of all, I've noticed an error myself. mixer_disable() calls mixer_disable_plane(), so it should also be modified. I'll send a v2 later. Now to your points... Andrzej Hajda wrote: > On 19.09.2016 16:16, Tobias Jakobi wrote: >> Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once >> in mixer_cfg_layer(). >> Trigger this via atomic flush. >> >> Signed-off-by: Tobias Jakobi >> --- >> drivers/gpu/drm/exynos/exynos_mixer.c | 104 >> ++ >> drivers/gpu/drm/exynos/regs-mixer.h | 2 + >> 2 files changed, 69 insertions(+), 37 deletions(-) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c >> b/drivers/gpu/drm/exynos/exynos_mixer.c >> index 1e78d57..d4efd9c 100644 >> --- a/drivers/gpu/drm/exynos/exynos_mixer.c >> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c >> @@ -99,6 +99,7 @@ struct mixer_context { >> struct drm_device *drm_dev; >> struct exynos_drm_crtc *crtc; >> struct exynos_drm_plane planes[MIXER_WIN_NR]; >> +unsigned long state_cache; > > The name of the variable is cryptic. Yes, I'll try to come up with something better. It would probably be easier if struct mixer_context had a documentation for its fields. Anyway, any suggestions? > >> int pipe; >> unsigned long flags; >> >> @@ -418,37 +419,68 @@ static void mixer_cfg_rgb_fmt(struct mixer_context >> *ctx, unsigned int height) >> mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK); >> } >> >> -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win, >> -unsigned int priority, bool enable) >> +static void mixer_cfg_layer(struct mixer_context *ctx) >> { >> struct mixer_resources *res = &ctx->mixer_res; >> -u32 val = enable ? ~0 : 0; >> - >> -switch (win) { >> -case 0: >> -mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE); >> -mixer_reg_writemask(res, MXR_LAYER_CFG, >> -MXR_LAYER_CFG_GRP0_VAL(priority), >> -MXR_LAYER_CFG_GRP0_MASK); >> -break; >> -case 1: >> -mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE); >> -mixer_reg_writemask(res, MXR_LAYER_CFG, >> -MXR_LAYER_CFG_GRP1_VAL(priority), >> -MXR_LAYER_CFG_GRP1_MASK); >> +unsigned int win; >> >> -break; >> -case VP_DEFAULT_WIN: >> -if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) { >> -vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON); >> -mixer_reg_writemask(res, MXR_CFG, val, >> -MXR_CFG_VP_ENABLE); >> -mixer_reg_writemask(res, MXR_LAYER_CFG, >> -MXR_LAYER_CFG_VP_VAL(priority), >> -MXR_LAYER_CFG_VP_MASK); >> +struct exynos_drm_plane_state *state; >> +struct drm_framebuffer *fb; >> +unsigned int priority; >> +u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0; >> +bool enable; >> + >> +for (win = 0; win < MIXER_WIN_NR; ++win) { >> +state = to_exynos_plane_state(ctx->planes[win].base.state); >> +fb = state->fb; >> + >> +priority = state->base.normalized_zpos + 1; >> +enable = test_bit(win, &ctx->state_cache); >> + >> +if (!enable) >> +continue; >> + >> +switch (win) { >> +case 0: >> +mxr_cfg |= MXR_CFG_GRP0_ENABLE; >> +mxr_layer_cfg |= MXR_LAYER_CFG_GRP0_VAL(priority); >> +break; >> + >> +case 1: >> +mxr_cfg |= MXR_CFG_GRP1_ENABLE; >> +mxr_layer_cfg |= MXR_LAYER_CFG_GRP1_VAL(priority); >> +break; >> + >> +case VP_DEFAULT_WIN: >> +vp_enable = VP_ENABLE_ON; >> +mxr_cfg |= MXR_CFG_VP_ENABLE; >> +mxr_layer_cfg |= MXR_LAYER_CFG_VP_VAL(priority); >> +break; >> +} >> + >> +if (!fb) >> +continue; >> + >> +/* >> + * TODO: Don't enable alpha blending for the bottom window. >> + */ >> +switch (win) { >> +case 0: >> +case 1: >> +mixer_cfg_gfx_blend(ctx, win, >> is_alpha_format(fb->pixel_format)); >> +break; >> + >> +case VP_DEFAULT_WIN: >> +mixer_cfg_vp_blend(ctx); >> +break; >> } >> -break; >> } >> + >> +if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) >> +vp_reg_writemask(res, VP_ENABLE, vp_enable, VP_ENABLE_ON); >> + >> +mixer_reg_writemask(res, MXR_CFG, mxr_cfg, MXR_CFG_ENABLE_MASK
[PATCH] dma-buf/sw_sync: mark sync_timeline_create() static
2016-09-18 Baoyou Xie : > We get 1 warning when building kernel with W=1: > drivers/dma-buf/sw_sync.c:87:23: warning: no previous prototype for > 'sync_timeline_create' [-Wmissing-prototypes] > > In fact, this function is only used in the file in which it is > declared and don't need a declaration, but can be made static. > So this patch marks it 'static'. > > Signed-off-by: Baoyou Xie > --- > drivers/dma-buf/sw_sync.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks for finding this. Reviewed-by: Gustavo Padovan Gustavo
[PATCH 6/6] GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data()
On Tue, 20 Sep 2016, SF Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 20 Sep 2016 10:40:22 +0200 > > * Adjust a jump target. Please don't. BR, Jani. > > * Delete the explicit initialisation for the local variable "ret" > which became unnecessary with this refactoring. > > Signed-off-by: Markus Elfring > --- > drivers/gpu/drm/gma500/mid_bios.c | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/gma500/mid_bios.c > b/drivers/gpu/drm/gma500/mid_bios.c > index e5cece0..602d16f 100644 > --- a/drivers/gpu/drm/gma500/mid_bios.c > +++ b/drivers/gpu/drm/gma500/mid_bios.c > @@ -284,7 +284,7 @@ static void mid_get_vbt_data(struct drm_psb_private > *dev_priv) > u8 __iomem *vbt_virtual; > struct mid_vbt_header vbt_header; > struct pci_dev *pci_gfx_root = pci_get_bus_and_slot(0, PCI_DEVFN(2, 0)); > - int ret = -1; > + int ret; > > /* Get the address of the platform config vbt */ > pci_read_config_dword(pci_gfx_root, 0xFC, &addr); > @@ -293,18 +293,18 @@ static void mid_get_vbt_data(struct drm_psb_private > *dev_priv) > dev_dbg(dev->dev, "drm platform config address is %x\n", addr); > > if (!addr) > - goto out; > + goto report_failure; > > /* get the virtual address of the vbt */ > vbt_virtual = ioremap(addr, sizeof(vbt_header)); > if (!vbt_virtual) > - goto out; > + goto report_failure; > > memcpy_fromio(&vbt_header, vbt_virtual, sizeof(vbt_header)); > iounmap(vbt_virtual); > > if (memcmp(&vbt_header.signature, "$GCT", 4)) > - goto out; > + goto report_failure; > > dev_dbg(dev->dev, "GCT revision is %02x\n", vbt_header.revision); > > @@ -322,9 +322,8 @@ static void mid_get_vbt_data(struct drm_psb_private > *dev_priv) > dev_err(dev->dev, "Unknown revision of GCT!\n"); > return; > } > - > -out: > if (ret) > + report_failure: > dev_err(dev->dev, "Unable to read GCT!"); > else > dev_priv->has_gct = true; -- Jani Nikula, Intel Open Source Technology Center
[PATCH 5/6] GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()
On Tue, 20 Sep 2016, SF Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 20 Sep 2016 10:36:19 +0200 > > A single error message should be sufficient to inform about > the detection of an unknown GCT revision at the end. > Thus return after the logging call in this case directly. Did you test this? BR, Jani. > > Signed-off-by: Markus Elfring > --- > drivers/gpu/drm/gma500/mid_bios.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/gma500/mid_bios.c > b/drivers/gpu/drm/gma500/mid_bios.c > index 9004d30..e5cece0 100644 > --- a/drivers/gpu/drm/gma500/mid_bios.c > +++ b/drivers/gpu/drm/gma500/mid_bios.c > @@ -320,6 +320,7 @@ static void mid_get_vbt_data(struct drm_psb_private > *dev_priv) > break; > default: > dev_err(dev->dev, "Unknown revision of GCT!\n"); > + return; > } > > out: -- Jani Nikula, Intel Open Source Technology Center
[PATCH 1/6] GPU-DRM-GMA500: Use kmalloc_array() in mid_get_vbt_data_r10()
On Tue, 20 Sep 2016, SF Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 20 Sep 2016 08:54:07 +0200 > > A multiplication for the size determination of a memory allocation > indicated that an array data structure should be processed. > Thus use the corresponding function "kmalloc_array". > > This issue was detected by using the Coccinelle software. Did you test this running on the hardware? BR, Jani. > > Signed-off-by: Markus Elfring > --- > drivers/gpu/drm/gma500/mid_bios.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/gma500/mid_bios.c > b/drivers/gpu/drm/gma500/mid_bios.c > index d75ecb3..a833568 100644 > --- a/drivers/gpu/drm/gma500/mid_bios.c > +++ b/drivers/gpu/drm/gma500/mid_bios.c > @@ -235,7 +235,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private > *dev_priv, u32 addr) > if (read_vbt_r10(addr, &vbt)) > return -1; > > - gct = kmalloc(sizeof(*gct) * vbt.panel_count, GFP_KERNEL); > + gct = kmalloc_array(vbt.panel_count, sizeof(*gct), GFP_KERNEL); > if (!gct) > return -1; -- Jani Nikula, Intel Open Source Technology Center
[PATCH 2/6] GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data_r10()
On Tue, 20 Sep 2016, SF Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 20 Sep 2016 09:09:10 +0200 > > Adjust a jump label according to the current Linux coding style convention. Generally, please don't send patches to fix checkpatch issues in existing code. Moreover, this particular "convention" is just something someone sneaked into CodingStyle, it's subjective, and it's probably going to be removed soon. NAK. BR, Jani. > > Signed-off-by: Markus Elfring > --- > drivers/gpu/drm/gma500/mid_bios.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/gma500/mid_bios.c > b/drivers/gpu/drm/gma500/mid_bios.c > index a833568..cf4e605 100644 > --- a/drivers/gpu/drm/gma500/mid_bios.c > +++ b/drivers/gpu/drm/gma500/mid_bios.c > @@ -242,7 +242,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private > *dev_priv, u32 addr) > gct_virtual = ioremap(addr + sizeof(vbt), > sizeof(*gct) * vbt.panel_count); > if (!gct_virtual) > - goto out; > + goto free_gct; > memcpy_fromio(gct, gct_virtual, sizeof(*gct)); > iounmap(gct_virtual); > > @@ -270,7 +270,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private > *dev_priv, u32 addr) > dp_ti->vsync_pulse_width_lo = ti->vsync_pulse_width_lo; > > ret = 0; > -out: > + free_gct: > kfree(gct); > return ret; > } -- Jani Nikula, Intel Open Source Technology Center
GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()
>>> A single error message should be sufficient to inform about >>> the detection of an unknown GCT revision at the end. >>> Thus return after the logging call in this case directly. >> >> Did you test this? >> > > Don't be a dummy... This is easy to review an it fixes a bug. Thanks for this kind of constructive feedback. > I'm fine with you NAKing all these patches based on who they are from. Would you like to clarify such an information a bit more? > I mostly just delete these without responding because the guy has > history of introducing bugs and never listens to feedback. I admit that I'll stumble on programming mistakes again occasionally as another ordinary free software developer who is struggling various open issues. I am listening to various feedback. My responses might not be pleasing enough for you. Are you looking for any special information to improve a corresponding discussion? Regards, Markus
[PATCH RESEND] drm/ast: free correct pointer in astfb_create() error paths
On 20/09/16 11:56, Andrew Donnellan wrote: > In the err_free_vram and err_release_fbi error paths in astfb_create(), we > attempt to free afbdev->sysram. The only jumps to these error paths occur > before we assign afbdev->sysram = sysram. Free sysram instead. > > Signed-off-by: Andrew Donnellan > > --- > > Found by Coverity Scan. Compile tested only. > > Resending as it looks like this didn't hit dri-devel. It did show up after all :) -- Andrew Donnellan OzLabs, ADL Canberra andrew.donnellan at au1.ibm.com IBM Australia Limited
[PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
On Tue, 20 Sep 2016, Peter Griffin wrote: > Hi Emil, > > On Tue, 20 Sep 2016, Emil Velikov wrote: > >> On 5 September 2016 at 14:16, Peter Griffin >> wrote: >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following >> > recursive dependency. > > >> > >> From a humble skim through remoteproc, drm and a few other subsystems >> I think the above is wrong. All the drivers (outside of remoteproc), >> that I've seen, depend on the core component, they don't select it. > > I will let Bjorn comment on the remoteproc subsystem Kconfig design, and > why it is like it is. > > For this particular SLIM_RPROC I have added it to Kconfig in keeping with all > the other drivers in the remoteproc subsystem which has exposed this recursive > dependency issue. > > For this particular kconfig symbol a quick grep reveals more drivers in > the kernel using 'select', than 'depend on' > > git grep "select VIRTIO" | wc -l > 14 > > git grep "depends on VIRTIO" | wc -l > 10 > > >> Furthermore most places explicitly hide the drivers from the menu if >> the core component isn't enabled. > > Remoteproc subsystem takes a different approach, the core code is only enabled > if a driver which relies on it is enabled. This IMHO makes sense, as > remoteproc is not widely used (only a few particular ARM SoC's). > > It is true that for subsystems which rely on the core component being > explicitly enabled, they often tend to hide drivers which depend on it > from the menu unless it is. This also makes sense. > >> >> Is there something that requires such a different/unusual behaviour in >> remoteproc ? >> > > I'm not sure it is that unusual...looking at config USB, it selects > USB_COMMON in > mfd subsystem, client drivers select MFD_CORE. > > I've added Arnd to this thread, as I've seen lots of Kconfig patches from him > recently, maybe he has some thoughts on whether this is the correct fix or > not? Documentation/kbuild/kconfig-language.txt: Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. People tend to abuse select because it's "convenient". If you depend, but some of your dependencies aren't met, you're in for some digging through Kconfig to find the missing deps. Just to make the option you want visible in menuconfig. If you instead select something with dependencies, it'll be right most of the time, and it's "convenient", until it breaks. (And hey, it usually breaks for someone else with some other config, so it's still convenient for you.) Perhaps kconfig should complain about selecting visible symbols and symbols with dependencies. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()
>> A single error message should be sufficient to inform about >> the detection of an unknown GCT revision at the end. >> Thus return after the logging call in this case directly. > > Did you test this? What is your software development opinion for this update suggestion? Regards, Markus
GPU-DRM-GMA500: Use kmalloc_array() in mid_get_vbt_data_r10()
>> A multiplication for the size determination of a memory allocation >> indicated that an array data structure should be processed. >> Thus use the corresponding function "kmalloc_array". >> >> This issue was detected by using the Coccinelle software. > > Did you test this running on the hardware? No. - My "test computer" does not provide the corresponding hardware for the affected driver source files. Regards, Markus
[Bug 93456] Intel D845GVAD2 ubuntu 15.10 GPU Hangs - stuck on render ring
https://bugs.freedesktop.org/show_bug.cgi?id=93456 yann changed: What|Removed |Added Product|DRI |Mesa Version|XOrg git|10.6 QA Contact|intel-gfx-bugs at lists.freede |dri-devel at lists.freedesktop |sktop.org |.org Assignee|intel-gfx-bugs at lists.freede |dri-devel at lists.freedesktop |sktop.org |.org Component|DRM/Intel |Drivers/DRI/i830 --- Comment #1 from yann --- There were improvements pushed in kernel and Mesa that will benefit to your system, so please re-test with latest kernel & Mesa to see if this issue is still occurring (including new installer in https://01.org/linuxgraphics/downloads) Kernel: 4.2.0-16-generic Platform: 82845G/GL[Brookdale-G]/GE - (pci id: 0x2562) Mesa: 10.6.0 [Please confirm your mesa version] In the meantime, assigning to Mesa product (please let me know if I am mistaken with this GPU Hang). >From this error dump, hung is happening in render ring batch with active head at 0x0154, with 0x4190 (2D UNKNOWN) as IPEHR. Batch extract (around 0x0154): 0x0128: 0x7d030081: 3DSTATE_LOAD_STATE_IMMEDIATE_2 0x012c: 0x82000180:TB0C 0x0130: 0x02000180:TB0A 0x0134: 0x7d030804: 3DSTATE_LOAD_STATE_IMMEDIATE_2 0x0138: 0x01481000:TM0S0: offset=0x01481000, 0x013c: 0x02205cc0:TM0S1: height=17, width=23, 0x0140: 0x7c08c088:TM0S2: pitch=3972, 0x0144: 0x7f1c000b:TM0S3 0x0148: 0x41c0:TM0S4: dflt color 0x014c: 0x4190: 2D UNKNOWN 0x0150: 0x4455c000: XY_SETUP_MONO_PATTERN_SL_BLT (rgb enabled, alpha disabled, src tile 1, dst tile 0) Bad count in XY_SETUP_MONO_PATTERN_SL_BLT 0x0154: 0x3f80:format , pitch 0, rop 0x80, clipping disabled, 0x0158: 0x:cliprect (0,0) 0x015c: 0x4190:cliprect (0,16784) 0x0160: 0x444fc000:setup dst offset 0x444fc000 0x0164: 0x3f80:setup background color 0x0168: 0x:setup foreground color 0x016c: 0x:mono pattern dw0 0x0170: 0x444fc000:mono pattern dw1 0x0158: 0x: MI_NOOP -- 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/20160920/c820904e/attachment-0001.html>
[PATCH] drm/omap: fix return value check in dsi_bind()
On 09/17/16 18:53, Wei Yongjun wrote: > From: Wei Yongjun > > Fix the retrn value check which testing the wrong variable > in dsi_bind(). Reviewed-by: Peter Ujfalusi > > Signed-off-by: Wei Yongjun > --- > drivers/gpu/drm/omapdrm/dss/dsi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c > b/drivers/gpu/drm/omapdrm/dss/dsi.c > index e1be5e7..a567ebd 100644 > --- a/drivers/gpu/drm/omapdrm/dss/dsi.c > +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c > @@ -5342,7 +5342,7 @@ static int dsi_bind(struct device *dev, struct device > *master, void *data) > > dsi->phy_base = devm_ioremap(&dsidev->dev, res->start, > resource_size(res)); > - if (!dsi->proto_base) { > + if (!dsi->phy_base) { > DSSERR("can't ioremap DSI PHY\n"); > return -ENOMEM; > } > @@ -5362,7 +5362,7 @@ static int dsi_bind(struct device *dev, struct device > *master, void *data) > > dsi->pll_base = devm_ioremap(&dsidev->dev, res->start, > resource_size(res)); > - if (!dsi->proto_base) { > + if (!dsi->pll_base) { > DSSERR("can't ioremap DSI PLL\n"); > return -ENOMEM; > } > > > -- Péter
Kernel error causing display issues.
On Tue, 20 Sep 2016, Edward Bartolo wrote: > I am experiencing display issues on HP Probook 4540s ( i5 based > laptop). Reading /var/log/kern.log I found the cause is probably > rooted in: > > [drm] Wrong MCH_SSKPD value: 0x16040307 Maybe, maybe not. Please file a bug at [1], attaching the dmesg with drm.debug=14 module parameter set. BR, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel -- Jani Nikula, Intel Open Source Technology Center
[RFC 2/2] drm/exynos: mixer: configure layers once in mixer_atomic_flush()
On 19.09.2016 16:16, Tobias Jakobi wrote: > Only manipulate the MXR_CFG and MXR_LAYER_CFG registers once > in mixer_cfg_layer(). > Trigger this via atomic flush. > > Signed-off-by: Tobias Jakobi > --- > drivers/gpu/drm/exynos/exynos_mixer.c | 104 > ++ > drivers/gpu/drm/exynos/regs-mixer.h | 2 + > 2 files changed, 69 insertions(+), 37 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c > b/drivers/gpu/drm/exynos/exynos_mixer.c > index 1e78d57..d4efd9c 100644 > --- a/drivers/gpu/drm/exynos/exynos_mixer.c > +++ b/drivers/gpu/drm/exynos/exynos_mixer.c > @@ -99,6 +99,7 @@ struct mixer_context { > struct drm_device *drm_dev; > struct exynos_drm_crtc *crtc; > struct exynos_drm_plane planes[MIXER_WIN_NR]; > + unsigned long state_cache; The name of the variable is cryptic. > int pipe; > unsigned long flags; > > @@ -418,37 +419,68 @@ static void mixer_cfg_rgb_fmt(struct mixer_context > *ctx, unsigned int height) > mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_RGB_FMT_MASK); > } > > -static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win, > - unsigned int priority, bool enable) > +static void mixer_cfg_layer(struct mixer_context *ctx) > { > struct mixer_resources *res = &ctx->mixer_res; > - u32 val = enable ? ~0 : 0; > - > - switch (win) { > - case 0: > - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE); > - mixer_reg_writemask(res, MXR_LAYER_CFG, > - MXR_LAYER_CFG_GRP0_VAL(priority), > - MXR_LAYER_CFG_GRP0_MASK); > - break; > - case 1: > - mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE); > - mixer_reg_writemask(res, MXR_LAYER_CFG, > - MXR_LAYER_CFG_GRP1_VAL(priority), > - MXR_LAYER_CFG_GRP1_MASK); > + unsigned int win; > > - break; > - case VP_DEFAULT_WIN: > - if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) { > - vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON); > - mixer_reg_writemask(res, MXR_CFG, val, > - MXR_CFG_VP_ENABLE); > - mixer_reg_writemask(res, MXR_LAYER_CFG, > - MXR_LAYER_CFG_VP_VAL(priority), > - MXR_LAYER_CFG_VP_MASK); > + struct exynos_drm_plane_state *state; > + struct drm_framebuffer *fb; > + unsigned int priority; > + u32 mxr_cfg = 0, mxr_layer_cfg = 0, vp_enable = 0; > + bool enable; > + > + for (win = 0; win < MIXER_WIN_NR; ++win) { > + state = to_exynos_plane_state(ctx->planes[win].base.state); > + fb = state->fb; > + > + priority = state->base.normalized_zpos + 1; > + enable = test_bit(win, &ctx->state_cache); > + > + if (!enable) > + continue; > + > + switch (win) { > + case 0: > + mxr_cfg |= MXR_CFG_GRP0_ENABLE; > + mxr_layer_cfg |= MXR_LAYER_CFG_GRP0_VAL(priority); > + break; > + > + case 1: > + mxr_cfg |= MXR_CFG_GRP1_ENABLE; > + mxr_layer_cfg |= MXR_LAYER_CFG_GRP1_VAL(priority); > + break; > + > + case VP_DEFAULT_WIN: > + vp_enable = VP_ENABLE_ON; > + mxr_cfg |= MXR_CFG_VP_ENABLE; > + mxr_layer_cfg |= MXR_LAYER_CFG_VP_VAL(priority); > + break; > + } > + > + if (!fb) > + continue; > + > + /* > + * TODO: Don't enable alpha blending for the bottom window. > + */ > + switch (win) { > + case 0: > + case 1: > + mixer_cfg_gfx_blend(ctx, win, > is_alpha_format(fb->pixel_format)); > + break; > + > + case VP_DEFAULT_WIN: > + mixer_cfg_vp_blend(ctx); > + break; > } > - break; > } > + > + if (test_bit(MXR_BIT_VP_ENABLED, &ctx->flags)) > + vp_reg_writemask(res, VP_ENABLE, vp_enable, VP_ENABLE_ON); > + > + mixer_reg_writemask(res, MXR_CFG, mxr_cfg, MXR_CFG_ENABLE_MASK); > + mixer_reg_writemask(res, MXR_LAYER_CFG, mxr_layer_cfg, > MXR_LAYER_CFG_MASK); What about enabled planes which are not updated? Corresponding bit in ctx->state_cache will be 0. It looks like this routine will disable them in hardware, am I right? Regards Andrzej > } > > static void mixer_run(struct mixer_context *ctx) > @@ -478,7 +510,6 @@ static void vp_video_buffer(struct mixer_context *ctx, >
[PATCH 4/6] drm/radeon: Provide page_flip_target hook
On 17/09/16 09:41 PM, Mario Kleiner wrote: > Hi Michel, > > all your patches, both the already merged kernel bits in radeon/amdgpu > and also all the userspace bits in libdrm/ati-ddx/amdgpu-ddx are all > > Reviewed-and-tested-by: Mario Kleiner > > I successfully tested with old/current userspace and the new userspace > patches from your own libdrm/ati-ddx/amdgpu-ddx repos, under radeon-kms > with HD-5770 and amdgpu-kms with R9 380, under DRI2 and DRI3/Present > with the new userspace and at least DRI3/Present with the old/current > userspace (can't quite remember if i also tested with DRI2 on > old/current userspace, but probably). Hardware measured timing tests all > work fine. > > So all is good, except for pre-DCE4 without pflip irqs, but for that see > the patchset i just sent out, which should make those old asics work > well as well. Thanks for the testing and patches! -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH 1/2] drm/radeon: Slightly more robust flip completion handling for < DCE-4
On 17/09/16 09:25 PM, Mario Kleiner wrote: > Pre DCE4 hardware doesn't have (reliable) pageflip completion > irqs, therefore we have to use the old polling method for flip > completion handling in vblank irq. > > As vblank irqs fire a bit before start of vblank (when the > linebuffer fifo read position reaches end of scanout), we > have some fudge for flip completion handling in the last > lines of active scanout. Old code assumed the threshold to > be 99% of active scanout height, a ballpark estimate which > worked ok. Since we know since a while how to calculate the > actual threshold from linebuffer size, lets make use of it > to get a more accurate threshold. > > This completion path is still prone to some races in corner > cases, especially on pre-AVIVO hardware, so document them > a bit better in the code comments. > > Signed-off-by: Mario Kleiner [...] > + * Note that this method of completion handling is still not 100% race > + * free, as we could execute before the radeon_flip_work_func managed > + * to run and set the RADEON_FLIP_SUBMITTED status, thereby we no-op, > + * but the flip still gets programmed into hw and completed during > + * vblank, leading to a delayed emission of the flip completion event. > + * This applies at least to pre-AVIVO hardware, where flips are always > + * completing inside vblank, not only at leading edge of vblank. Does this part of the comment still apply with patch 2? Anyway, Acked-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH RESEND] drm/ast: free correct pointer in astfb_create() error paths
In the err_free_vram and err_release_fbi error paths in astfb_create(), we attempt to free afbdev->sysram. The only jumps to these error paths occur before we assign afbdev->sysram = sysram. Free sysram instead. Signed-off-by: Andrew Donnellan --- Found by Coverity Scan. Compile tested only. Resending as it looks like this didn't hit dri-devel. --- drivers/gpu/drm/ast/ast_fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c index c017a93..0fef8ea 100644 --- a/drivers/gpu/drm/ast/ast_fb.c +++ b/drivers/gpu/drm/ast/ast_fb.c @@ -254,7 +254,7 @@ static int astfb_create(struct drm_fb_helper *helper, err_release_fbi: drm_fb_helper_release_fbi(helper); err_free_vram: - vfree(afbdev->sysram); + vfree(sysram); return ret; } -- Andrew Donnellan OzLabs, ADL Canberra andrew.donnellan at au1.ibm.com IBM Australia Limited
[PATCH 2/2] drm/radeon: Prevent races on pre DCE4 between flip submission and completion.
On 17/09/16 09:25 PM, Mario Kleiner wrote: > Pre DCE4 hw doesn't have reliable pageflip completion > interrupts, so instead polling for flip completion is > used from within the vblank irq handler to complete > page flips. > > This causes a race if pageflip ioctl is called close to > vblank: > > 1. pageflip ioctl queues execution of radeon_flip_work_func. > > 2. vblank irq fires, radeon_crtc_handle_vblank checks for >flip_status == FLIP_SUBMITTED finds none, no-ops. > > 3. radeon_flip_work_func runs inside vblank, decides to >set flip_status == FLIP_SUBMITTED and programs the >flip into hw. > > 4. hw executes flip immediately (because in vblank), but >as 2 already happened, the flip completion routine only >emits the flip completion event one refresh later -> >wrong vblank count/timestamp for completion and no >performance gain, as instead of delaying the flip until >next vblank, we now delay the next flip by 1 refresh >while waiting for the delayed flip completion event. > > Given we often don't gain anything due to this race, but > lose precision, prevent the programmed flip from executing > in vblank on pre DCE4 asics to avoid this race. > > On pre-AVIVO hw we can't program the hw for edge-triggered > flips, they always execute anywhere in vblank. Therefore delay > the actual flip programming until after vblank on pre-AVIVO. > > Signed-off-by: Mario Kleiner Reviewed-by: Michel Dänzer P.S. Please send radeon (and amdgpu) driver patches to the amd-gfx mailing list (as well). -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[PATCH][V2] drm/amdgpu: avoid out of bounds access on array interrupt_status_offsets
On Tue, Sep 20, 2016 at 11:49 AM, Colin King wrote: > From: Colin Ian King > > The check for an out of bound index into array interrupt_status_offsets > is off-by-one. Fix this and also don't compared to a hard coded array > size but use adev->mode_info.num_hpd instead. > > Signed-off-by: Colin Ian King Applied! thanks, Alex > --- > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c > b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c > index d3512f3..4ce4c1a 100644 > --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c > @@ -2782,7 +2782,7 @@ static int dce_v6_0_hpd_irq(struct amdgpu_device *adev, > uint32_t disp_int, mask, int_control, tmp; > unsigned hpd; > > - if (entry->src_data > 6) { > + if (entry->src_data >= adev->mode_info.num_hpd) { > DRM_DEBUG("Unhandled interrupt: %d %d\n", entry->src_id, > entry->src_data); > return 0; > } > -- > 2.9.3 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdgpu: avoid out of bounds access on array interrupt_status_offsets
On Tue, Sep 20, 2016 at 11:16 AM, Colin King wrote: > From: Colin Ian King > > The check for an out of bound index into array interrupt_status_offsets > is off-by-one. Fix this and also don't compared to a hard coded array > size but use ARRAY_SIZE instead. > > Signed-off-by: Colin Ian King > --- > drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c > b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c > index d3512f3..4ce4c1a 100644 > --- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c > +++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c > @@ -2782,7 +2782,7 @@ static int dce_v6_0_hpd_irq(struct amdgpu_device *adev, > uint32_t disp_int, mask, int_control, tmp; > unsigned hpd; > > - if (entry->src_data > 6) { > + if (entry->src_data >= ARRAY_SIZE(interrupt_status_offsets)) { This should actually be adev->mode_info.num_hpd as some asic variants may not have 6 hpd lines. Thanks for catching this. Alex > DRM_DEBUG("Unhandled interrupt: %d %d\n", entry->src_id, > entry->src_data); > return 0; > } > -- > 2.9.3 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/sti: remove stih415-416 platform support
stih415 and stih416 platform are obsolete and no more supported. Only stih407 and stih410 platform are maintained. Signed-off-by: Vincent Abriou --- drivers/gpu/drm/sti/Kconfig| 6 +- drivers/gpu/drm/sti/Makefile | 1 - drivers/gpu/drm/sti/sti_compositor.c | 19 -- drivers/gpu/drm/sti/sti_hda.c | 39 +--- drivers/gpu/drm/sti/sti_hdmi.c | 20 -- drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 336 - drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h | 14 -- drivers/gpu/drm/sti/sti_mixer.c| 19 -- drivers/gpu/drm/sti/sti_tvout.c| 40 +--- 9 files changed, 14 insertions(+), 480 deletions(-) delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig index 494ab25..acd7286 100644 --- a/drivers/gpu/drm/sti/Kconfig +++ b/drivers/gpu/drm/sti/Kconfig @@ -1,6 +1,6 @@ config DRM_STI - tristate "DRM Support for STMicroelectronics SoC stiH41x Series" - depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM) + tristate "DRM Support for STMicroelectronics SoC stiH4xx Series" + depends on DRM && (ARCH_STI || ARCH_MULTIPLATFORM) select RESET_CONTROLLER select DRM_KMS_HELPER select DRM_GEM_CMA_HELPER @@ -9,4 +9,4 @@ config DRM_STI select FW_LOADER select SND_SOC_HDMI_CODEC if SND_SOC help - Choose this option to enable DRM on STM stiH41x chipset + Choose this option to enable DRM on STM stiH4xx chipset diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile index b805762..d20f7c0 100644 --- a/drivers/gpu/drm/sti/Makefile +++ b/drivers/gpu/drm/sti/Makefile @@ -9,7 +9,6 @@ sti-drm-y := \ sti_crtc.o \ sti_plane.o \ sti_hdmi.o \ - sti_hdmi_tx3g0c55phy.o \ sti_hdmi_tx3g4c28phy.o \ sti_dvo.o \ sti_awg_utils.o \ diff --git a/drivers/gpu/drm/sti/sti_compositor.c b/drivers/gpu/drm/sti/sti_compositor.c index a6f391b..f62041f 100644 --- a/drivers/gpu/drm/sti/sti_compositor.c +++ b/drivers/gpu/drm/sti/sti_compositor.c @@ -39,22 +39,6 @@ static const struct sti_compositor_data stih407_compositor_data = { }, }; -/* - * stiH416 compositor properties - * Note: - * on stih416 MIXER_AUX has a different base address from MIXER_MAIN - * Moreover, GDPx is different for Main and Aux Mixer. So this subdev map does - * not fit for stiH416 if we want to enable the MIXER_AUX. - */ -static const struct sti_compositor_data stih416_compositor_data = { - .nb_subdev = 3, - .subdev_desc = { - {STI_GPD_SUBDEV, (int)STI_GDP_0, 0x100}, - {STI_GPD_SUBDEV, (int)STI_GDP_1, 0x200}, - {STI_MIXER_MAIN_SUBDEV, STI_MIXER_MAIN, 0xC00} - }, -}; - int sti_compositor_debugfs_init(struct sti_compositor *compo, struct drm_minor *minor) { @@ -179,9 +163,6 @@ static const struct component_ops sti_compositor_ops = { static const struct of_device_id compositor_of_match[] = { { - .compatible = "st,stih416-compositor", - .data = &stih416_compositor_data, - }, { .compatible = "st,stih407-compositor", .data = &stih407_compositor_data, }, { diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c index a225c4d..e7c243f 100644 --- a/drivers/gpu/drm/sti/sti_hda.c +++ b/drivers/gpu/drm/sti/sti_hda.c @@ -62,14 +62,8 @@ #define SCALE_CTRL_CR_DFLT 0x00DB0249 /* Video DACs control */ -#define VIDEO_DACS_CONTROL_MASK 0x0FFF -#define VIDEO_DACS_CONTROL_SYSCFG2535 0x085C /* for stih416 */ -#define DAC_CFG_HD_OFF_SHIFT5 -#define DAC_CFG_HD_OFF_MASK (0x7 << DAC_CFG_HD_OFF_SHIFT) -#define VIDEO_DACS_CONTROL_SYSCFG5072 0x0120 /* for stih407 */ #define DAC_CFG_HD_HZUVW_OFF_MASK BIT(1) - /* Upsampler values for the alternative 2X Filter */ #define SAMPLER_COEF_NB 8 #define HDA_ANA_SRC_Y_CFG_ALT_2X0x0113 @@ -300,28 +294,14 @@ static bool hda_get_mode_idx(struct drm_display_mode mode, int *idx) */ static void hda_enable_hd_dacs(struct sti_hda *hda, bool enable) { - u32 mask; - if (hda->video_dacs_ctrl) { u32 val; - switch ((u32)hda->video_dacs_ctrl & VIDEO_DACS_CONTROL_MASK) { - case VIDEO_DACS_CONTROL_SYSCFG2535: - mask = DAC_CFG_HD_OFF_MASK; - break; - case VIDEO_DACS_CONTROL_SYSCFG5072: - mask = DAC_CFG_HD_HZUVW_OFF_MASK; - break; - default: - DRM_INFO("Video DACS control register not supported\n"); - return; - } -
drm: NULL pointer dereference in drm_mode_object_find()
On Tue, Sep 20, 2016 at 11:21 AM, David Herrmann wrote: > Hi > > On Mon, Sep 5, 2016 at 10:30 AM, Dmitry Vyukov wrote: >> On Fri, Aug 19, 2016 at 7:10 PM, Alexander Potapenko >> wrote: >>> Hello, >>> >>> the program below triggers a NULL deref in DRM code when ran on QEMU: >>> >>> === >>> BUG: unable to handle kernel NULL pointer dereference at (null) >>> IP: [< inline >] __list_add ./include/linux/list.h:44 >>> IP: [< inline >] list_add_tail ./include/linux/list.h:77 >>> IP: [< inline >] __mutex_lock_common kernel/locking/mutex.c:543 >>> IP: [] __mutex_lock_slowpath+0x6f/0x100 >>> kernel/locking/mutex.c:824 >>> PGD 1c555067 PUD 1c554067 PMD 0 >>> Oops: 0002 [#1] SMP >>> Modules linked in: >>> CPU: 0 PID: 2517 Comm: crash_drm_mode_ Not tainted 4.8.0-rc2+ #1157 >>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >>> task: 88001c40a700 task.stack: 88001c984000 >>> RIP: 0010:[] [] >>> __mutex_lock_slowpath+0x6f/0x100 >>> RSP: 0018:88001c987cb0 EFLAGS: 00010282 >>> RAX: RBX: 88001d5212a0 RCX: c100 >>> RDX: 0001 RSI: 88001c40a700 RDI: 88001d5212a4 >>> RBP: 88001c987cf8 R08: 88001c984000 R09: >>> R10: R11: R12: 88001c40a700 >>> R13: 88001d5212a4 R14: R15: 88001d5212a8 >>> FS: 00dc9880() GS:88001f00() knlGS: >>> CS: 0010 DS: ES: CR0: 80050033 >>> CR2: CR3: 1c8a9000 CR4: 000406f0 >>> Stack: >>> 88001d5212a8 811a398f >>> 88001d5212a0 88001d5212a0 >>> 81a6eb20 88001c987d10 818e85ba 88001d521000 >>> Call Trace: >>> [< inline >] __mutex_fastpath_lock >>> ./arch/x86/include/asm/mutex_64.h:28 >>> [] mutex_lock+0x1a/0x30 kernel/locking/mutex.c:102 >>> [] _object_find+0x23/0xc0 drivers/gpu/drm/drm_crtc.c:329 >>> [< inline >] drm_mode_object_find drivers/gpu/drm/drm_crtc.c:360 >>> [< inline >] drm_crtc_find ./include/drm/drm_crtc.h:2999 >>> [] drm_mode_page_flip_ioctl+0x4e/0x300 >>> drivers/gpu/drm/drm_crtc.c:5414 >>> [] drm_ioctl+0x2a2/0x460 drivers/gpu/drm/drm_ioctl.c:721 >>> [< inline >] vfs_ioctl fs/ioctl.c:43 >>> [] do_vfs_ioctl+0x8d/0x580 fs/ioctl.c:675 >>> [< inline >] SYSC_ioctl fs/ioctl.c:690 >>> [] SyS_ioctl+0x74/0x80 fs/ioctl.c:681 >>> [] entry_SYSCALL_64_fastpath+0x13/0x8f >>> arch/x86/entry/entry_64.S:207 >>> Code: e8 37 23 00 00 8b 03 83 f8 01 0f 84 95 00 00 00 48 8b 43 10 4c >>> 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48> >>> 89 20 4c 89 64 24 10 eb 19 49 c7 04 24 02 00 00 00 c6 43 04 >>> RIP [< inline >] __list_add ./include/linux/list.h:44 >>> RIP [< inline >] list_add_tail ./include/linux/list.h:77 >>> RIP [< inline >] __mutex_lock_common kernel/locking/mutex.c:543 >>> RIP [] __mutex_lock_slowpath+0x6f/0x100 >>> kernel/locking/mutex.c:824 >>> RSP >>> CR2: >>> ---[ end trace 3cef4eb618ac6bb6 ]--- >>> === >>> >>> // autogenerated by syzkaller (http://github.com/google/syzkaller) >>> #include >>> #include >>> #include >>> >>> int main() >>> { >>> int fd = open("/dev/dri/card0", 0); >>> mmap(0x20036000ul, 0x1000ul, 0x3ul, 0x32ul, 0xul, 0x0ul); >>> memcpy((void*)0x20036ad7, >>> "\x1e\xa4\x45\xdc\xca\x11\xff\x25\x72\x65\x7e\x4a\x56\x54\x35" >>> "\x67\xe3\x8b\x41\x5c\x6d\x69\xa5\xf9\x88\x29\xb8\xc9\x6a\x45" >>> "\x76\xa9\xe7\x14\xd1\xf6\xa3\x59\x07\x4d\xe5\xc8\x39\xbf\x33" >>> "\xb9\x3d\x21\xd1\xaf\x16\x4d\xbc\xbf\xb1\x0a\x92\x97\xd9\x91" >>> "\x4d\xd8\xf8\xa1\xa6\xa3\x20\x02\x2c\x5e\x8f\x87\x05\x8b\xeb" >>> "\x9a\xb9\xbc\xa6\x60\x45\x8d\x19\x01\x7d\xb7\xef\x64\x62\x2e" >>> "\x5e\x3d\xfe\x65\xbf\xe2\x80\x89\x36\x48\x73\xc6\xa2\x6e\xe2" >>> "\x1a\x8f\x1b\x11\x6f\x49\x20\xeb\x74\x2d\x41\xb9\x8b\xb4\x8e" >>> "\x8b\xf5\x6d\xb7\xb1\xa3\xcb\xc4\xc2\x7f\x6d\xef\x32\xef\xa7" >>> "\x1c\x17\x03\x60\x7b\x31\x1f\x66", >>> 143); >>> ioctl(fd, 0xbb0ul, 0x20036ad7ul, 0, 0, 0); >>> return 0; >>> } >>> >>> I build the ToT kernel (commit >>> 952b159f2919a8d514f13999f9f463bddcc1dae7, Aug 18) with defconfig and >>> CONFIG_DRM_VGEM=y. >> >> +dri-devel >> >> I am also hitting this on 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of >> linux-next. > > Can you tell us which DRM driver this is? vgem does not specify > DRIVER_MODESET, so the page-flip ioctl should not be hooked up. Also, > the mmap() operation should fail on any GEM driver. *confused* How do I check that? > Thanks > David > > -- > You received this message because you are subscribed to the Google Groups > "s
drm: NULL pointer dereference in drm_mode_object_find()
Hi On Mon, Sep 5, 2016 at 10:30 AM, Dmitry Vyukov wrote: > On Fri, Aug 19, 2016 at 7:10 PM, Alexander Potapenko > wrote: >> Hello, >> >> the program below triggers a NULL deref in DRM code when ran on QEMU: >> >> === >> BUG: unable to handle kernel NULL pointer dereference at (null) >> IP: [< inline >] __list_add ./include/linux/list.h:44 >> IP: [< inline >] list_add_tail ./include/linux/list.h:77 >> IP: [< inline >] __mutex_lock_common kernel/locking/mutex.c:543 >> IP: [] __mutex_lock_slowpath+0x6f/0x100 >> kernel/locking/mutex.c:824 >> PGD 1c555067 PUD 1c554067 PMD 0 >> Oops: 0002 [#1] SMP >> Modules linked in: >> CPU: 0 PID: 2517 Comm: crash_drm_mode_ Not tainted 4.8.0-rc2+ #1157 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >> task: 88001c40a700 task.stack: 88001c984000 >> RIP: 0010:[] [] >> __mutex_lock_slowpath+0x6f/0x100 >> RSP: 0018:88001c987cb0 EFLAGS: 00010282 >> RAX: RBX: 88001d5212a0 RCX: c100 >> RDX: 0001 RSI: 88001c40a700 RDI: 88001d5212a4 >> RBP: 88001c987cf8 R08: 88001c984000 R09: >> R10: R11: R12: 88001c40a700 >> R13: 88001d5212a4 R14: R15: 88001d5212a8 >> FS: 00dc9880() GS:88001f00() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: CR3: 1c8a9000 CR4: 000406f0 >> Stack: >> 88001d5212a8 811a398f >> 88001d5212a0 88001d5212a0 >> 81a6eb20 88001c987d10 818e85ba 88001d521000 >> Call Trace: >> [< inline >] __mutex_fastpath_lock >> ./arch/x86/include/asm/mutex_64.h:28 >> [] mutex_lock+0x1a/0x30 kernel/locking/mutex.c:102 >> [] _object_find+0x23/0xc0 drivers/gpu/drm/drm_crtc.c:329 >> [< inline >] drm_mode_object_find drivers/gpu/drm/drm_crtc.c:360 >> [< inline >] drm_crtc_find ./include/drm/drm_crtc.h:2999 >> [] drm_mode_page_flip_ioctl+0x4e/0x300 >> drivers/gpu/drm/drm_crtc.c:5414 >> [] drm_ioctl+0x2a2/0x460 drivers/gpu/drm/drm_ioctl.c:721 >> [< inline >] vfs_ioctl fs/ioctl.c:43 >> [] do_vfs_ioctl+0x8d/0x580 fs/ioctl.c:675 >> [< inline >] SYSC_ioctl fs/ioctl.c:690 >> [] SyS_ioctl+0x74/0x80 fs/ioctl.c:681 >> [] entry_SYSCALL_64_fastpath+0x13/0x8f >> arch/x86/entry/entry_64.S:207 >> Code: e8 37 23 00 00 8b 03 83 f8 01 0f 84 95 00 00 00 48 8b 43 10 4c >> 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48> >> 89 20 4c 89 64 24 10 eb 19 49 c7 04 24 02 00 00 00 c6 43 04 >> RIP [< inline >] __list_add ./include/linux/list.h:44 >> RIP [< inline >] list_add_tail ./include/linux/list.h:77 >> RIP [< inline >] __mutex_lock_common kernel/locking/mutex.c:543 >> RIP [] __mutex_lock_slowpath+0x6f/0x100 >> kernel/locking/mutex.c:824 >> RSP >> CR2: >> ---[ end trace 3cef4eb618ac6bb6 ]--- >> === >> >> // autogenerated by syzkaller (http://github.com/google/syzkaller) >> #include >> #include >> #include >> >> int main() >> { >> int fd = open("/dev/dri/card0", 0); >> mmap(0x20036000ul, 0x1000ul, 0x3ul, 0x32ul, 0xul, 0x0ul); >> memcpy((void*)0x20036ad7, >> "\x1e\xa4\x45\xdc\xca\x11\xff\x25\x72\x65\x7e\x4a\x56\x54\x35" >> "\x67\xe3\x8b\x41\x5c\x6d\x69\xa5\xf9\x88\x29\xb8\xc9\x6a\x45" >> "\x76\xa9\xe7\x14\xd1\xf6\xa3\x59\x07\x4d\xe5\xc8\x39\xbf\x33" >> "\xb9\x3d\x21\xd1\xaf\x16\x4d\xbc\xbf\xb1\x0a\x92\x97\xd9\x91" >> "\x4d\xd8\xf8\xa1\xa6\xa3\x20\x02\x2c\x5e\x8f\x87\x05\x8b\xeb" >> "\x9a\xb9\xbc\xa6\x60\x45\x8d\x19\x01\x7d\xb7\xef\x64\x62\x2e" >> "\x5e\x3d\xfe\x65\xbf\xe2\x80\x89\x36\x48\x73\xc6\xa2\x6e\xe2" >> "\x1a\x8f\x1b\x11\x6f\x49\x20\xeb\x74\x2d\x41\xb9\x8b\xb4\x8e" >> "\x8b\xf5\x6d\xb7\xb1\xa3\xcb\xc4\xc2\x7f\x6d\xef\x32\xef\xa7" >> "\x1c\x17\x03\x60\x7b\x31\x1f\x66", >> 143); >> ioctl(fd, 0xbb0ul, 0x20036ad7ul, 0, 0, 0); >> return 0; >> } >> >> I build the ToT kernel (commit >> 952b159f2919a8d514f13999f9f463bddcc1dae7, Aug 18) with defconfig and >> CONFIG_DRM_VGEM=y. > > +dri-devel > > I am also hitting this on 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of > linux-next. Can you tell us which DRM driver this is? vgem does not specify DRIVER_MODESET, so the page-flip ioctl should not be hooked up. Also, the mmap() operation should fail on any GEM driver. *confused* Thanks David
[Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3
On Mon, 19 Sep 2016, James Bottomley wrote: > On Mon, 2016-09-19 at 08:09 -0700, James Bottomley wrote: >> On Sun, 2016-09-18 at 13:35 +0200, Thorsten Leemhuis wrote: >> > Hi! James & Paulo: What's the current status of this? >> >> No, the only interaction has been the suggestion below for a revert, >> which didn't fix the problem. >> >> > Was this issue discussed elsewhere or even fixed in between? Just >> > asking, because this issue is on the list of regressions for 4.8. >> >> >> I'm just about to try out -rc7, but it's not fixed so far. > > OK, with -rc7 and the i915 fixes, there seems to be a marked > improvement. I can no longer crash the crtc by using lots of xrandr > switches, which was the principal problem. > > I've so far only got one of these in the logs > > [14858.635035] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* > CPU pipe B FIFO underrun > > And the only residual problem seems to be that the monitor goes blank > periodically, but this can be fixed by switching resolution a couple of > times. > > I haven't seen any of the link training errors so far and I've run > through my usual battery of be nasty to the external monitor tests. Thanks for the update. We still have fixes for the underruns in the pipeline. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[PATCH 6/6] GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data()
From: Markus Elfring Date: Tue, 20 Sep 2016 10:40:22 +0200 * Adjust a jump target. * Delete the explicit initialisation for the local variable "ret" which became unnecessary with this refactoring. Signed-off-by: Markus Elfring --- drivers/gpu/drm/gma500/mid_bios.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/gma500/mid_bios.c b/drivers/gpu/drm/gma500/mid_bios.c index e5cece0..602d16f 100644 --- a/drivers/gpu/drm/gma500/mid_bios.c +++ b/drivers/gpu/drm/gma500/mid_bios.c @@ -284,7 +284,7 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv) u8 __iomem *vbt_virtual; struct mid_vbt_header vbt_header; struct pci_dev *pci_gfx_root = pci_get_bus_and_slot(0, PCI_DEVFN(2, 0)); - int ret = -1; + int ret; /* Get the address of the platform config vbt */ pci_read_config_dword(pci_gfx_root, 0xFC, &addr); @@ -293,18 +293,18 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv) dev_dbg(dev->dev, "drm platform config address is %x\n", addr); if (!addr) - goto out; + goto report_failure; /* get the virtual address of the vbt */ vbt_virtual = ioremap(addr, sizeof(vbt_header)); if (!vbt_virtual) - goto out; + goto report_failure; memcpy_fromio(&vbt_header, vbt_virtual, sizeof(vbt_header)); iounmap(vbt_virtual); if (memcmp(&vbt_header.signature, "$GCT", 4)) - goto out; + goto report_failure; dev_dbg(dev->dev, "GCT revision is %02x\n", vbt_header.revision); @@ -322,9 +322,8 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv) dev_err(dev->dev, "Unknown revision of GCT!\n"); return; } - -out: if (ret) + report_failure: dev_err(dev->dev, "Unable to read GCT!"); else dev_priv->has_gct = true; -- 2.10.0
[PATCH 5/6] GPU-DRM-GMA500: One error message less for a GCT revision mismatch in mid_get_vbt_data()
From: Markus Elfring Date: Tue, 20 Sep 2016 10:36:19 +0200 A single error message should be sufficient to inform about the detection of an unknown GCT revision at the end. Thus return after the logging call in this case directly. Signed-off-by: Markus Elfring --- drivers/gpu/drm/gma500/mid_bios.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/gma500/mid_bios.c b/drivers/gpu/drm/gma500/mid_bios.c index 9004d30..e5cece0 100644 --- a/drivers/gpu/drm/gma500/mid_bios.c +++ b/drivers/gpu/drm/gma500/mid_bios.c @@ -320,6 +320,7 @@ static void mid_get_vbt_data(struct drm_psb_private *dev_priv) break; default: dev_err(dev->dev, "Unknown revision of GCT!\n"); + return; } out: -- 2.10.0
[PATCH 4/6] GPU-DRM-GMA500: Fix indentation for a function call parameter in mid_get_vbt_data_r10()
From: Markus Elfring Date: Tue, 20 Sep 2016 10:34:28 +0200 Adjust the indentation for a single function call parameter here. Signed-off-by: Markus Elfring --- drivers/gpu/drm/gma500/mid_bios.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/mid_bios.c b/drivers/gpu/drm/gma500/mid_bios.c index 3caee42..9004d30 100644 --- a/drivers/gpu/drm/gma500/mid_bios.c +++ b/drivers/gpu/drm/gma500/mid_bios.c @@ -240,7 +240,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr) return -1; gct_virtual = ioremap(addr + sizeof(vbt), - sizeof(*gct) * vbt.panel_count); + sizeof(*gct) * vbt.panel_count); if (!gct_virtual) { ret = -1; goto free_gct; -- 2.10.0
[PATCH 3/6] GPU-DRM-GMA500: Move a variable assignment in mid_get_vbt_data_r10()
From: Markus Elfring Date: Tue, 20 Sep 2016 10:32:12 +0200 One local variable was set to an error code before a concrete error situation was detected. Thus move the corresponding assignment into an if branch to indicate a software failure there. Signed-off-by: Markus Elfring --- drivers/gpu/drm/gma500/mid_bios.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/mid_bios.c b/drivers/gpu/drm/gma500/mid_bios.c index cf4e605..3caee42 100644 --- a/drivers/gpu/drm/gma500/mid_bios.c +++ b/drivers/gpu/drm/gma500/mid_bios.c @@ -230,7 +230,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr) struct gct_r10 *gct; struct oaktrail_timing_info *dp_ti = &dev_priv->gct_data.DTD; struct gct_r10_timing_info *ti; - int ret = -1; + int ret; if (read_vbt_r10(addr, &vbt)) return -1; @@ -241,8 +241,10 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr) gct_virtual = ioremap(addr + sizeof(vbt), sizeof(*gct) * vbt.panel_count); - if (!gct_virtual) + if (!gct_virtual) { + ret = -1; goto free_gct; + } memcpy_fromio(gct, gct_virtual, sizeof(*gct)); iounmap(gct_virtual); -- 2.10.0
[PATCH 2/6] GPU-DRM-GMA500: Rename a jump label in mid_get_vbt_data_r10()
From: Markus Elfring Date: Tue, 20 Sep 2016 09:09:10 +0200 Adjust a jump label according to the current Linux coding style convention. Signed-off-by: Markus Elfring --- drivers/gpu/drm/gma500/mid_bios.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gma500/mid_bios.c b/drivers/gpu/drm/gma500/mid_bios.c index a833568..cf4e605 100644 --- a/drivers/gpu/drm/gma500/mid_bios.c +++ b/drivers/gpu/drm/gma500/mid_bios.c @@ -242,7 +242,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr) gct_virtual = ioremap(addr + sizeof(vbt), sizeof(*gct) * vbt.panel_count); if (!gct_virtual) - goto out; + goto free_gct; memcpy_fromio(gct, gct_virtual, sizeof(*gct)); iounmap(gct_virtual); @@ -270,7 +270,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr) dp_ti->vsync_pulse_width_lo = ti->vsync_pulse_width_lo; ret = 0; -out: + free_gct: kfree(gct); return ret; } -- 2.10.0
[PATCH 1/6] GPU-DRM-GMA500: Use kmalloc_array() in mid_get_vbt_data_r10()
From: Markus Elfring Date: Tue, 20 Sep 2016 08:54:07 +0200 A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus use the corresponding function "kmalloc_array". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/gpu/drm/gma500/mid_bios.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/mid_bios.c b/drivers/gpu/drm/gma500/mid_bios.c index d75ecb3..a833568 100644 --- a/drivers/gpu/drm/gma500/mid_bios.c +++ b/drivers/gpu/drm/gma500/mid_bios.c @@ -235,7 +235,7 @@ static int mid_get_vbt_data_r10(struct drm_psb_private *dev_priv, u32 addr) if (read_vbt_r10(addr, &vbt)) return -1; - gct = kmalloc(sizeof(*gct) * vbt.panel_count, GFP_KERNEL); + gct = kmalloc_array(vbt.panel_count, sizeof(*gct), GFP_KERNEL); if (!gct) return -1; -- 2.10.0
[PATCH 0/6] GPU-DRM-GMA500: Fine-tuning for two function implementations
From: Markus Elfring Date: Tue, 20 Sep 2016 10:48:04 +0200 A few update suggestions were taken into account from static source code analysis. Markus Elfring (6): Use kmalloc_array() in mid_get_vbt_data_r10() Rename a jump label in mid_get_vbt_data_r10() Move a variable assignment in mid_get_vbt_data_r10() Fix indentation for a function call parameter in mid_get_vbt_data_r10() One error message less for a GCT revision mismatch in mid_get_vbt_data() Rename a jump label in mid_get_vbt_data() drivers/gpu/drm/gma500/mid_bios.c | 26 ++ 1 file changed, 14 insertions(+), 12 deletions(-) -- 2.10.0
[RFC 1/2] drm/exynos: mixer: convert booleans to flags in mixer context
On 19.09.2016 15:53, Tobias Jakobi wrote: > The mixer context struct already has a 'flags' field, so > we can use it to store the 'interlace', 'vp_enabled' and > 'has_sclk' booleans. > We use the non-atomic helper functions to access these bits. > > Signed-off-by: Tobias Jakobi Reviewed-by: Andrzej Hajda -- Regards Andrzej
[PATCH] drm/exynos: mark exynos_dp_crtc_clock_enable() static
On 18.09.2016 15:58, Baoyou Xie wrote: > We get 1 warning when building kernel with W=1: > drivers/gpu/drm/exynos/exynos_dp.c:46:5: warning: no previous prototype for > 'exynos_dp_crtc_clock_enable' [-Wmissing-prototypes] > > In fact, this function is only used in the file in which it is > declared and don't need a declaration, but can be made static. > So this patch marks it 'static'. > > Signed-off-by: Baoyou Xie Reviewed-by: Andrzej Hajda -- Regards Andrzej
Kernel error causing display issues.
Hi, I am experiencing display issues on HP Probook 4540s ( i5 based laptop). Reading /var/log/kern.log I found the cause is probably rooted in: [drm] Wrong MCH_SSKPD value: 0x16040307 Just after the kernel takes control of the machine, I cannot read the boot text. Successive pixel lines are shifted left relative to the user (reader). The shift is always by the same amount. While using Firefox in XFCE 4.10, horizontal distortions occur as I scroll text in a web page. Help is much appreciated. Edward lspci listing follows: $ lspci 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) 00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4) 00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4) 00:1c.5 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 6 (rev c4) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) 02:00.0 System peripheral: JMicron Technology Corp. SD/MMC Host Controller (rev 30) 02:00.2 SD Host controller: JMicron Technology Corp. Standard SD Host Controller (rev 30) 02:00.3 System peripheral: JMicron Technology Corp. MS Host Controller (rev 30) 03:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01) 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07) System: Linux edbarx-pc3 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux Kernel error during boot: Sep 18 06:58:03 edbarx-pc3 kernel: [7.471266] [drm] Wrong MCH_SSKPD value: 0x16040307 Sep 18 06:58:03 edbarx-pc3 kernel: [7.471269] [drm] This can cause pipe underruns and display issues. Sep 18 06:58:03 edbarx-pc3 kernel: [7.471270] [drm] Please upgrade your BIOS to fix this. Sep 18 06:58:03 edbarx-pc3 kernel: [7.489912] fbcon: inteldrmfb (fb0) is primary device Sep 18 06:58:03 edbarx-pc3 kernel: [7.598128] EFI Variables Facility v0.08 2004-May-17 Sep 18 06:58:03 edbarx-pc3 kernel: [7.724203] hp_accel: laptop model unknown, using default axes configuration Sep 18 06:58:03 edbarx-pc3 kernel: [7.729494] jmb38x_ms :02:00.3: enabling device ( -> 0002) Sep 18 06:58:03 edbarx-pc3 kernel: [7.757025] [drm:ilk_display_irq_handler] *ERROR* Pipe A FIFO underrun Sep 18 06:58:03 edbarx-pc3 kernel: [7.759849] [drm:cpt_set_fifo_underrun_reporting] *ERROR* uncleared pch fifo underrun on pch transcoder A Sep 18 06:58:03 edbarx-pc3 kernel: [7.759851] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun --- Module Information: --- # modinfo i915 filename: /lib/modules/3.16.0-4-amd64/kernel/drivers/gpu/drm/i915/i915.ko license:GPL and additional rights description:Intel Graphics author: Tungsten Graphics, Inc. alias: pci:v8086d22B3sv*sd*bc03sc*i* alias: pci:v8086d22B2sv*sd*bc03sc*i* alias: pci:v8086d22B1sv*sd*bc03sc*i* alias: pci:v8086d22B0sv*sd*bc03sc*i* alias: pci:v8086d162Dsv*sd*bc03sc*i* alias: pci:v8086d162Asv*sd*bc03sc*i* alias: pci:v8086d162Esv*sd*bc03sc*i* alias: pci:v8086d162Bsv*sd*bc03sc*i* alias: pci:v8086d1626sv*sd*bc03sc*i* alias: pci:v8086d1622sv*sd*bc03sc*i* alias: pci:v8086d161Dsv*sd*bc03sc*i* alias: pci:v8086d161Asv*sd*bc03sc*i* alias: pci:v8086d160Dsv*sd*bc03sc*i* alias: pci:v8086d160Asv*sd*bc03sc*i* alias: pci:v8086d161Esv*sd*bc03sc*i* alias: pci:v8086d161Bsv*sd*bc03sc*i* alias: pci:v8086d16
[PATCH v3 3/3] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR
Hi Sean, On 09/12/2016 09:52 PM, Sean Paul wrote: > On Fri, Sep 9, 2016 at 5:45 AM, Yakir Yang wrote: >> Make sure the request PSR state takes effect in analogix_dp_send_psr_spd() >> function, or print the sink PSR error state if we failed to apply the >> requested PSR setting. >> >> Signed-off-by: Yakir Yang >> --- >> Changes in v3: >> - Update commit message >> - Add DP_TIMEOUT_PSR_LOOP_MS marcos >> - Correct the return values of analogix_dp_send_psr_spd() >> >> Changes in v2: >> - A bunch of good fixes from Sean >> >> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 ++ >> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 5 +++-- >> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 25 >> -- >> 3 files changed, 28 insertions(+), 8 deletions(-) >> >> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c >> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c >> index 5fe3982..c0ce16a 100644 >> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c >> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c >> @@ -116,8 +116,7 @@ int analogix_dp_enable_psr(struct device *dev) >> psr_vsc.DB0 = 0; >> psr_vsc.DB1 = EDP_VSC_PSR_STATE_ACTIVE | >> EDP_VSC_PSR_CRC_VALUES_VALID; >> >> - analogix_dp_send_psr_spd(dp, &psr_vsc); >> - return 0; >> + return analogix_dp_send_psr_spd(dp, &psr_vsc); >> } >> EXPORT_SYMBOL_GPL(analogix_dp_enable_psr); >> >> @@ -139,8 +138,7 @@ int analogix_dp_disable_psr(struct device *dev) >> psr_vsc.DB0 = 0; >> psr_vsc.DB1 = 0; >> >> - analogix_dp_send_psr_spd(dp, &psr_vsc); >> - return 0; >> + return analogix_dp_send_psr_spd(dp, &psr_vsc); >> } >> EXPORT_SYMBOL_GPL(analogix_dp_disable_psr); >> >> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h >> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h >> index d564e90..a27f1e3 100644 >> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h >> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h >> @@ -20,6 +20,7 @@ >> #define MAX_EQ_LOOP 5 >> >> #define DP_TIMEOUT_LOOP_MS msecs_to_jiffies(1) >> +#define DP_TIMEOUT_PSR_LOOP_MS msecs_to_jiffies(300) > Same comment here re: units. > > 300ms seems like a really long time. Why does it take this long? This magic number '300ms' just come from my test, I haven't found the description in eDP 1.4a Spec about what exact time should Sink take to entry PSR. - Yakir > Sean > > >> /* DP_MAX_LANE_COUNT */ >> #define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1) >> @@ -248,8 +249,8 @@ void analogix_dp_config_video_slave_mode(struct >> analogix_dp_device *dp); >> void analogix_dp_enable_scrambling(struct analogix_dp_device *dp); >> void analogix_dp_disable_scrambling(struct analogix_dp_device *dp); >> void analogix_dp_enable_psr_crc(struct analogix_dp_device *dp); >> -void analogix_dp_send_psr_spd(struct analogix_dp_device *dp, >> - struct edp_vsc_psr *vsc); >> +int analogix_dp_send_psr_spd(struct analogix_dp_device *dp, >> +struct edp_vsc_psr *vsc); >> ssize_t analogix_dp_transfer(struct analogix_dp_device *dp, >> struct drm_dp_aux_msg *msg); >> #endif /* _ANALOGIX_DP_CORE_H */ >> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c >> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c >> index 15a4cf0..7fd4ed0 100644 >> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c >> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c >> @@ -1004,10 +1004,12 @@ void analogix_dp_enable_psr_crc(struct >> analogix_dp_device *dp) >> writel(PSR_VID_CRC_ENABLE, dp->reg_base + ANALOGIX_DP_CRC_CON); >> } >> >> -void analogix_dp_send_psr_spd(struct analogix_dp_device *dp, >> - struct edp_vsc_psr *vsc) >> +int analogix_dp_send_psr_spd(struct analogix_dp_device *dp, >> +struct edp_vsc_psr *vsc) >> { >> + unsigned long timeout; >> unsigned int val; >> + u8 sink; >> >> /* don't send info frame */ >> val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL); >> @@ -1048,6 +1050,25 @@ void analogix_dp_send_psr_spd(struct >> analogix_dp_device *dp, >> val = readl(dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL); >> val |= IF_EN; >> writel(val, dp->reg_base + ANALOGIX_DP_PKT_SEND_CTL); >> + >> + timeout = jiffies + DP_TIMEOUT_PSR_LOOP_MS; >> + while (time_before(jiffies, timeout)) { >> + val = drm_dp_dpcd_readb(&dp->aux, DP_PSR_STATUS, &sink); >> + if (val != 1) { >> + dev_err(dp->dev, "PSR_STATUS read failed ret=%d", >> val); >> + return -EBUSY; >> + } >> + >> + if ((vsc->DB1 && sink == DP_PSR_SINK_ACTIVE_RFB) || >> + (!vsc->DB1 && sink == DP_
[PATCH v3 2/3] drm/bridge: analogix_dp: use jiffies to simulate timeout loop
Hi Sean, On 09/12/2016 09:51 PM, Sean Paul wrote: > On Fri, Sep 9, 2016 at 5:44 AM, Yakir Yang wrote: >> Signed-off-by: Yakir Yang >> --- >> Changes in v3: >> - Suggested by Sean >> >> Changes in v2: None >> >> drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 3 ++- >> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 18 +- >> 2 files changed, 11 insertions(+), 10 deletions(-) >> >> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h >> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h >> index a15f076..d564e90 100644 >> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h >> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h >> @@ -16,10 +16,11 @@ >> #include >> #include >> >> -#define DP_TIMEOUT_LOOP_COUNT 100 >> #define MAX_CR_LOOP 5 >> #define MAX_EQ_LOOP 5 >> >> +#define DP_TIMEOUT_LOOP_MS msecs_to_jiffies(1) > The name suggests the units here are ms, but you're storing jiffies. > Do the msecs_to_jiffies conversion down below. I suddenly realized that 'analogix_dp_core.c' also used the 'DP_TIMEOUT_LOOP_COUNT' macros, and 'analogix_dp_core.c' have four kinds of timeout, - DP_TIMEOUT_LOOP_COUNT * 1us - DP_TIMEOUT_LOOP_COUNT * 10us - DP_TIMEOUT_LOOP_COUNT * 100us - DP_TIMEOUT_LOOP_COUNT * 1000us I may guess it's not necessary to replace the 'DP_TIMEOUT_LOOP_COUNT' now :-) - Yakir > >> + >> /* DP_MAX_LANE_COUNT */ >> #define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1) >> #define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f) >> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c >> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c >> index a4d17b8..15a4cf0 100644 >> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c >> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c >> @@ -335,7 +335,7 @@ void analogix_dp_set_analog_power_down(struct >> analogix_dp_device *dp, >> void analogix_dp_init_analog_func(struct analogix_dp_device *dp) >> { >> u32 reg; >> - int timeout_loop = 0; >> + unsigned long timeout; >> >> analogix_dp_set_analog_power_down(dp, POWER_ALL, 0); >> >> @@ -350,9 +350,9 @@ void analogix_dp_init_analog_func(struct >> analogix_dp_device *dp) >> if (analogix_dp_get_pll_lock_status(dp) == PLL_UNLOCKED) { >> analogix_dp_set_pll_power_down(dp, 0); >> >> + timeout = jiffies + DP_TIMEOUT_LOOP_MS; > timeout = jiffies + msecs_to_jiffies(DP_TIMEOUT_LOOP_MS); > >> while (analogix_dp_get_pll_lock_status(dp) == PLL_UNLOCKED) >> { >> - timeout_loop++; >> - if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) { >> + if (time_after(jiffies, timeout)) { >> dev_err(dp->dev, "failed to get pll lock >> status\n"); >> return; >> } >> @@ -501,7 +501,7 @@ int analogix_dp_start_aux_transaction(struct >> analogix_dp_device *dp) >> { >> int reg; >> int retval = 0; >> - int timeout_loop = 0; >> + unsigned long timeout; >> >> /* Enable AUX CH operation */ >> reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2); >> @@ -509,10 +509,10 @@ int analogix_dp_start_aux_transaction(struct >> analogix_dp_device *dp) >> writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2); >> >> /* Is AUX CH command reply received? */ >> + timeout = jiffies + DP_TIMEOUT_LOOP_MS; >> reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA); >> while (!(reg & RPLY_RECEIV)) { >> - timeout_loop++; >> - if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) { >> + if (time_after(jiffies, timeout)) { >> dev_err(dp->dev, "AUX CH command reply failed!\n"); >> return -ETIMEDOUT; >> } >> @@ -1055,7 +1055,7 @@ ssize_t analogix_dp_transfer(struct analogix_dp_device >> *dp, >> { >> u32 reg; >> u8 *buffer = msg->buffer; >> - int timeout_loop = 0; >> + unsigned long timeout; >> unsigned int i; >> int num_transferred = 0; >> >> @@ -1123,10 +1123,10 @@ ssize_t analogix_dp_transfer(struct >> analogix_dp_device *dp, >> >> /* Is AUX CH command reply received? */ >> /* TODO: Wait for an interrupt instead of looping? */ >> + timeout = jiffies + DP_TIMEOUT_LOOP_MS; >> reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA); >> while (!(reg & RPLY_RECEIV)) { >> - timeout_loop++; >> - if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) { >> + if (time_after(jiffies, timeout)) { >> dev_err(dp->dev, "AUX CH command reply failed!\n"); >> return -ETIMEDOUT; >> } >> -- >> 1.9.1 >> >> > >
[PATCH] drm/sti: remove stih415-416 platform support
stih415 and stih416 platform are obsolete and no more supported. Only stih407 and stih410 platform are maintained. Signed-off-by: Vincent Abriou --- drivers/gpu/drm/sti/Kconfig| 6 +- drivers/gpu/drm/sti/sti_compositor.c | 19 -- drivers/gpu/drm/sti/sti_hda.c | 39 +--- drivers/gpu/drm/sti/sti_hdmi.c | 20 -- drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c | 336 - drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h | 14 -- drivers/gpu/drm/sti/sti_mixer.c| 19 -- drivers/gpu/drm/sti/sti_tvout.c| 40 +--- 8 files changed, 14 insertions(+), 479 deletions(-) delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.c delete mode 100644 drivers/gpu/drm/sti/sti_hdmi_tx3g0c55phy.h diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig index 494ab25..acd7286 100644 --- a/drivers/gpu/drm/sti/Kconfig +++ b/drivers/gpu/drm/sti/Kconfig @@ -1,6 +1,6 @@ config DRM_STI - tristate "DRM Support for STMicroelectronics SoC stiH41x Series" - depends on DRM && (SOC_STIH415 || SOC_STIH416 || ARCH_MULTIPLATFORM) + tristate "DRM Support for STMicroelectronics SoC stiH4xx Series" + depends on DRM && (ARCH_STI || ARCH_MULTIPLATFORM) select RESET_CONTROLLER select DRM_KMS_HELPER select DRM_GEM_CMA_HELPER @@ -9,4 +9,4 @@ config DRM_STI select FW_LOADER select SND_SOC_HDMI_CODEC if SND_SOC help - Choose this option to enable DRM on STM stiH41x chipset + Choose this option to enable DRM on STM stiH4xx chipset diff --git a/drivers/gpu/drm/sti/sti_compositor.c b/drivers/gpu/drm/sti/sti_compositor.c index a6f391b..f62041f 100644 --- a/drivers/gpu/drm/sti/sti_compositor.c +++ b/drivers/gpu/drm/sti/sti_compositor.c @@ -39,22 +39,6 @@ static const struct sti_compositor_data stih407_compositor_data = { }, }; -/* - * stiH416 compositor properties - * Note: - * on stih416 MIXER_AUX has a different base address from MIXER_MAIN - * Moreover, GDPx is different for Main and Aux Mixer. So this subdev map does - * not fit for stiH416 if we want to enable the MIXER_AUX. - */ -static const struct sti_compositor_data stih416_compositor_data = { - .nb_subdev = 3, - .subdev_desc = { - {STI_GPD_SUBDEV, (int)STI_GDP_0, 0x100}, - {STI_GPD_SUBDEV, (int)STI_GDP_1, 0x200}, - {STI_MIXER_MAIN_SUBDEV, STI_MIXER_MAIN, 0xC00} - }, -}; - int sti_compositor_debugfs_init(struct sti_compositor *compo, struct drm_minor *minor) { @@ -179,9 +163,6 @@ static const struct component_ops sti_compositor_ops = { static const struct of_device_id compositor_of_match[] = { { - .compatible = "st,stih416-compositor", - .data = &stih416_compositor_data, - }, { .compatible = "st,stih407-compositor", .data = &stih407_compositor_data, }, { diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c index a225c4d..e7c243f 100644 --- a/drivers/gpu/drm/sti/sti_hda.c +++ b/drivers/gpu/drm/sti/sti_hda.c @@ -62,14 +62,8 @@ #define SCALE_CTRL_CR_DFLT 0x00DB0249 /* Video DACs control */ -#define VIDEO_DACS_CONTROL_MASK 0x0FFF -#define VIDEO_DACS_CONTROL_SYSCFG2535 0x085C /* for stih416 */ -#define DAC_CFG_HD_OFF_SHIFT5 -#define DAC_CFG_HD_OFF_MASK (0x7 << DAC_CFG_HD_OFF_SHIFT) -#define VIDEO_DACS_CONTROL_SYSCFG5072 0x0120 /* for stih407 */ #define DAC_CFG_HD_HZUVW_OFF_MASK BIT(1) - /* Upsampler values for the alternative 2X Filter */ #define SAMPLER_COEF_NB 8 #define HDA_ANA_SRC_Y_CFG_ALT_2X0x0113 @@ -300,28 +294,14 @@ static bool hda_get_mode_idx(struct drm_display_mode mode, int *idx) */ static void hda_enable_hd_dacs(struct sti_hda *hda, bool enable) { - u32 mask; - if (hda->video_dacs_ctrl) { u32 val; - switch ((u32)hda->video_dacs_ctrl & VIDEO_DACS_CONTROL_MASK) { - case VIDEO_DACS_CONTROL_SYSCFG2535: - mask = DAC_CFG_HD_OFF_MASK; - break; - case VIDEO_DACS_CONTROL_SYSCFG5072: - mask = DAC_CFG_HD_HZUVW_OFF_MASK; - break; - default: - DRM_INFO("Video DACS control register not supported\n"); - return; - } - val = readl(hda->video_dacs_ctrl); if (enable) - val &= ~mask; + val &= ~DAC_CFG_HD_HZUVW_OFF_MASK; else - val |= mask; + val |= DAC_CFG_HD_HZUVW_OFF_MASK; writel(val, hda->video_dacs_ctrl); } @@ -352,24 +332,11 @@ static void hda_dbg_awg_microcode(struct seq_file *s, void __iome
[PATCH 02/14] drm/blend: Fix sparse warnings
Hi Ville, Thank you for the patch. On Monday 19 Sep 2016 16:33:43 ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > drm/drm_blend.c:207:5: warning: symbol 'drm_atomic_normalize_zpos' was not > declared. Should it be static? > > Cc: Marek Szyprowski > Cc: Benjamin Gaignard > Cc: Laurent Pinchart > Signed-off-by: Ville Syrjälä Acked-by: Laurent Pinchart > --- > drivers/gpu/drm/drm_blend.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > index 0813b7e021be..0a0b9357db35 100644 > --- a/drivers/gpu/drm/drm_blend.c > +++ b/drivers/gpu/drm/drm_blend.c > @@ -30,7 +30,7 @@ > #include > #include > > -#include "drm_internal.h" > +#include "drm_crtc_internal.h" > > /** > * drm_plane_create_zpos_property - create mutable zpos property -- Regards, Laurent Pinchart
[PATCH 2/8] drm/rockchip: Get rid of some unnecessary code
On 2016å¹´09æ18æ¥ 12:01, Tomasz Figa wrote: > Hi Mark, > > On Sun, Sep 18, 2016 at 10:50 AM, Mark yao wrote: >> On 2016å¹´09æ14æ¥ 20:54, Tomasz Figa wrote: >>> Current code implements prepare_fb and cleanup_fb callbacks only to >>> grab/release fb references, which is already done by atomic framework >>> when creating/destryoing plane state. Let's remove these >>> unused bits. >>> >>> Signed-off-by: Tomasz Figa >>> --- >>>drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 -- >>>1 file changed, 18 deletions(-) >> >> Hi Tomasz >> >> I think we can't get rid of the prepare_fb and cleanup_fb > I think I have to disagree. Please see below for detailed explanation. > >> see the reason: >> commit 44d0237a26395ac94160cf23f32769013b365590 >> Author: Mark Yao >> Date: Fri Apr 29 11:37:20 2016 +0800 >> >> drm/rockchip: vop: fix iommu crash with async atomic >> >> After async atomic_commit callback, drm_atomic_clean_old_fb will >> clean all old fb, but because async, the old fb may be also on >> the vop hardware, dma will access the old fb buffer, clean old >> fb will cause iommu page fault. > I think the above is not quite right. Atomic plane state holds a > reference to its fb and old state is not supposed to be destroyed > until the flip completes. > > Indeed current rockchip_atomic_commit implementation has following > order of calls: rockchip_atomic_wait_for_complete(), > drm_atomic_helper_cleanup_planes(), drm_atomic_state_free(). This > means that .cleanup_fb() is called from > drm_atomic_helper_cleanup_planes() just before drm_atomic_state_free() > will release references by destroying old plane states. Note that both > are called already after rockchip_atomic_wait_for_complete(), so it > should be already safe to free the old fbs. > > So the above fix doesn't really do anything, possibly just covers the > race condition of the original wait for vblank function by delaying > drm_atomic_state_free() a bit. > > Moreover, the whole series has been thoroughly tested in Chrome OS 4.4 > kernel, including async commits. (There is still a possibility some > newer upstream changes slightly modified the semantics, but I couldn't > find such difference. Actually one of the advantages of atomic helpers > was to avoid manually refcounting the fbs from the driver.) > > Best regards, > Tomasz > Hi Tomasz You are right, plane_duplicate_state/plane_destroy_state already protect the old fbs. we can get rid of prepare_fb and cleanup_fb. -- ï¼ark Yao
[PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
Hi Emil, On Tue, 20 Sep 2016, Emil Velikov wrote: > On 5 September 2016 at 14:16, Peter Griffin > wrote: > > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following > > recursive dependency. > > > From a humble skim through remoteproc, drm and a few other subsystems > I think the above is wrong. All the drivers (outside of remoteproc), > that I've seen, depend on the core component, they don't select it. I will let Bjorn comment on the remoteproc subsystem Kconfig design, and why it is like it is. For this particular SLIM_RPROC I have added it to Kconfig in keeping with all the other drivers in the remoteproc subsystem which has exposed this recursive dependency issue. For this particular kconfig symbol a quick grep reveals more drivers in the kernel using 'select', than 'depend on' git grep "select VIRTIO" | wc -l 14 git grep "depends on VIRTIO" | wc -l 10 > Furthermore most places explicitly hide the drivers from the menu if > the core component isn't enabled. Remoteproc subsystem takes a different approach, the core code is only enabled if a driver which relies on it is enabled. This IMHO makes sense, as remoteproc is not widely used (only a few particular ARM SoC's). It is true that for subsystems which rely on the core component being explicitly enabled, they often tend to hide drivers which depend on it from the menu unless it is. This also makes sense. > > Is there something that requires such a different/unusual behaviour in > remoteproc ? > I'm not sure it is that unusual...looking at config USB, it selects USB_COMMON in mfd subsystem, client drivers select MFD_CORE. I've added Arnd to this thread, as I've seen lots of Kconfig patches from him recently, maybe he has some thoughts on whether this is the correct fix or not? regards, Peter.
[PATCH 25/38] drm: Add reference counting to drm_atomic_state
drm_atomic_state has a complicated single owner model that tracks the single reference from allocation through to destruction on another thread - or perhaps on a local error path. We can simplify this tracking by using reference counting (at a cost of a few more atomics). This is even more beneficial when the lifetime of the state becomes more convoluted than being passed to a single worker thread for the commit. v2: Double check !intel atomic_commit functions for missing gets v3: Update kerneldocs Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: dri-devel at lists.freedesktop.org Reviewed-by: Eric Engestrom --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 3 +- drivers/gpu/drm/drm_atomic.c | 25 +++ drivers/gpu/drm/drm_atomic_helper.c | 98 +++- drivers/gpu/drm/drm_fb_helper.c | 9 +-- drivers/gpu/drm/exynos/exynos_drm_drv.c | 3 +- drivers/gpu/drm/i915/i915_debugfs.c | 3 +- drivers/gpu/drm/i915/intel_display.c | 31 + drivers/gpu/drm/i915/intel_sprite.c | 4 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 +- drivers/gpu/drm/msm/msm_atomic.c | 3 +- drivers/gpu/drm/omapdrm/omap_drv.c | 3 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c| 3 +- drivers/gpu/drm/sti/sti_drv.c| 3 +- drivers/gpu/drm/tegra/drm.c | 3 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 - drivers/gpu/drm/vc4/vc4_kms.c| 3 +- include/drm/drm_atomic.h | 28 +++- include/drm/drm_crtc.h | 3 + 18 files changed, 101 insertions(+), 129 deletions(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c index 8e7483d90c47..c9e645fa1233 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c @@ -464,7 +464,7 @@ atmel_hlcdc_dc_atomic_complete(struct atmel_hlcdc_dc_commit *commit) drm_atomic_helper_cleanup_planes(dev, old_state); - drm_atomic_state_free(old_state); + drm_atomic_state_put(old_state); /* Complete the commit, wake up any waiter. */ spin_lock(&dc->commit.wait.lock); @@ -521,6 +521,7 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device *dev, /* Swap the state, this is the point of no return. */ drm_atomic_helper_swap_state(state, true); + drm_atomic_state_get(state); if (async) queue_work(dc->wq, &commit->work); else diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 23739609427d..5dd70540219c 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -74,6 +74,8 @@ EXPORT_SYMBOL(drm_atomic_state_default_release); int drm_atomic_state_init(struct drm_device *dev, struct drm_atomic_state *state) { + kref_init(&state->ref); + /* TODO legacy paths should maybe do a better job about * setting this appropriately? */ @@ -215,22 +217,16 @@ void drm_atomic_state_clear(struct drm_atomic_state *state) EXPORT_SYMBOL(drm_atomic_state_clear); /** - * drm_atomic_state_free - free all memory for an atomic state - * @state: atomic state to deallocate + * __drm_atomic_state_free - free all memory for an atomic state + * @ref: This atomic state to deallocate * * This frees all memory associated with an atomic state, including all the * per-object state for planes, crtcs and connectors. */ -void drm_atomic_state_free(struct drm_atomic_state *state) +void __drm_atomic_state_free(struct kref *ref) { - struct drm_device *dev; - struct drm_mode_config *config; - - if (!state) - return; - - dev = state->dev; - config = &dev->mode_config; + struct drm_atomic_state *state = container_of(ref, typeof(*state), ref); + struct drm_mode_config *config = &state->dev->mode_config; drm_atomic_state_clear(state); @@ -243,7 +239,7 @@ void drm_atomic_state_free(struct drm_atomic_state *state) kfree(state); } } -EXPORT_SYMBOL(drm_atomic_state_free); +EXPORT_SYMBOL(__drm_atomic_state_free); /** * drm_atomic_get_crtc_state - get crtc state @@ -1742,7 +1738,7 @@ retry: if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) { /* * Unlike commit, check_only does not clean up state. -* Below we call drm_atomic_state_free for it. +* Below we call drm_atomic_state_put for it. */ ret = drm_atomic_check_only(state); } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) { @@ -1775,8 +1771,7 @@ out: goto retry; } - if (ret || arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) - drm_atomic_state_free(state); + drm_atomic_state_put(state); drm_modeset_drop_locks(&ctx); drm_modeset_acqu
[PATCH 4/4] drm/sun4i: dotclock: Round to closest clock rate
On Mon, Sep 19, 2016 at 11:36:18PM +0800, Chen-Yu Tsai wrote: > On Mon, Sep 19, 2016 at 3:16 AM, Maxime Ripard > wrote: > > Hi, > > > > On Thu, Sep 15, 2016 at 11:14:02PM +0800, Chen-Yu Tsai wrote: > >> With display pixel clocks we want to have the closest possible clock > >> rate, to minimize timing and refresh rate skews. Whether the actual > >> clock rate is higher or lower than the requested rate is less important. > >> > >> Also check candidates against the requested rate, rather than the > >> ideal parent rate, the varying dividers also influence the difference > >> between the requested rate and the rounded rate. > >> > >> Signed-off-by: Chen-Yu Tsai > >> --- > >> drivers/gpu/drm/sun4i/sun4i_dotclock.c | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/sun4i/sun4i_dotclock.c > >> b/drivers/gpu/drm/sun4i/sun4i_dotclock.c > >> index 3eb99784f371..d401156490f3 100644 > >> --- a/drivers/gpu/drm/sun4i/sun4i_dotclock.c > >> +++ b/drivers/gpu/drm/sun4i/sun4i_dotclock.c > >> @@ -90,7 +90,8 @@ static long sun4i_dclk_round_rate(struct clk_hw *hw, > >> unsigned long rate, > >> goto out; > >> } > >> > >> - if ((rounded < ideal) && (rounded > best_parent)) { > >> + if (abs(rate - rounded / i) < > >> + abs(rate - best_parent / best_div)) { > > > > I'm not sure what you're trying to do here. Why is the divider involved? > > Say you want the dotclock at X, so you try Y = 6 ~ 127 for the divider. > Now you're asking the CCF to round (X*Y). > > In the original code, you were comparing the result of rounding (X * Y). > > if ((rounded < ideal) && (rounded > best_parent)) { > best_parent = rounded; > best_div = i; > } > > where ideal = X * Y (i in the code). Given the divider increases in > the loop, you are actually not closing in on the best divider, but the > highest divider that doesn't give a higher rate than the ideal rate. > > Including the divider makes it compare the actual dot clock frequency > if a given divider was used. > > Does this makes sense? Explaining this kind of makes my head spin... Yes, sorry, I didn't remember rounded was actually the rounded parent rate. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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/20160920/40c61675/attachment-0001.sig>
[PATCH 4/4] drm/sun4i: dotclock: Round to closest clock rate
On Thu, Sep 15, 2016 at 11:14:02PM +0800, Chen-Yu Tsai wrote: > With display pixel clocks we want to have the closest possible clock > rate, to minimize timing and refresh rate skews. Whether the actual > clock rate is higher or lower than the requested rate is less important. > > Also check candidates against the requested rate, rather than the > ideal parent rate, the varying dividers also influence the difference > between the requested rate and the rounded rate. > > Signed-off-by: Chen-Yu Tsai Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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/20160920/81bddca7/attachment-0001.sig>
[PATCH 04/14] drm/arm: Fix sparse warnings
On Mon, Sep 19, 2016 at 04:33:45PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > drm/arm/malidp_planes.c:49:24: warning: symbol 'malidp_duplicate_plane_state' > was not declared. Should it be static? > drm/arm/malidp_planes.c:66:6: warning: symbol 'malidp_destroy_plane_state' > was not declared. Should it be static? > > Cc: Liviu Dudau Acked-by: Liviu Dudau Thanks for cleaning it up! Liviu > Cc: Brian Starkey > Cc: Mali DP Maintainers > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/arm/malidp_planes.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/arm/malidp_planes.c > b/drivers/gpu/drm/arm/malidp_planes.c > index 82c193e5e0d6..cc9b8e02904d 100644 > --- a/drivers/gpu/drm/arm/malidp_planes.c > +++ b/drivers/gpu/drm/arm/malidp_planes.c > @@ -46,7 +46,7 @@ static void malidp_de_plane_destroy(struct drm_plane *plane) > devm_kfree(plane->dev->dev, mp); > } > > -struct drm_plane_state *malidp_duplicate_plane_state(struct drm_plane *plane) > +static struct drm_plane_state *malidp_duplicate_plane_state(struct drm_plane > *plane) > { > struct malidp_plane_state *state, *m_state; > > @@ -63,8 +63,8 @@ struct drm_plane_state *malidp_duplicate_plane_state(struct > drm_plane *plane) > return &state->base; > } > > -void malidp_destroy_plane_state(struct drm_plane *plane, > - struct drm_plane_state *state) > +static void malidp_destroy_plane_state(struct drm_plane *plane, > +struct drm_plane_state *state) > { > struct malidp_plane_state *m_state = to_malidp_plane_state(state); > > -- > 2.7.4 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ã)_/¯
[PATCH 5/5] drm/imx: add exclusive fence to plane state
Am Montag, den 19.09.2016, 22:48 +0200 schrieb Daniel Vetter: > On Thu, Aug 11, 2016 at 11:18 AM, Lucas Stach > wrote: > > This allows the atomic helper to wait on them, instead of open-coding > > the same in the imx-drm driver. > > > > Signed-off-by: Lucas Stach > > --- > > drivers/gpu/drm/imx/imx-drm-core.c | 63 > > +- > > 1 file changed, 28 insertions(+), 35 deletions(-) > > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > > b/drivers/gpu/drm/imx/imx-drm-core.c > > index 66b3556f7b79..2d3f32f1b13b 100644 > > --- a/drivers/gpu/drm/imx/imx-drm-core.c > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > > @@ -152,50 +152,43 @@ static void imx_drm_output_poll_changed(struct > > drm_device *drm) > > drm_fbdev_cma_hotplug_event(imxdrm->fbhelper); > > } > > > > +static int imx_drm_atomic_commit(struct drm_device *dev, > > +struct drm_atomic_state *state, > > +bool nonblock) > > +{ > > + struct drm_plane_state *plane_state; > > + struct drm_plane *plane; > > + struct dma_buf *dma_buf; > > + int i; > > + > > + /* > > +* If the plane fb has an dma-buf attached, fish out the exclusive > > +* fence for the atomic helper to wait on. > > +*/ > > + for_each_plane_in_state(state, plane, plane_state, i) { > > + if ((plane->state->fb != plane_state->fb) && > > plane_state->fb) { > > + dma_buf = drm_fb_cma_get_gem_obj(plane_state->fb, > > +0)->base.dma_buf; > > + if (!dma_buf) > > + continue; > > + plane_state->fence = > > + > > reservation_object_get_excl_rcu(dma_buf->resv); > > + } > > + } > > Just an fyi, but the idea was that you could do this in youre > prepare_plane hook, assuming that only when userspace flips is it > interested in syncing (for backwards compat reasons). But this gets > the job done too. > > The upshot of doing this consistently in a prepare_plane hook is that > it would then allow us to have a shared implementation for all cma > based kms drivers. If you feel bored, I'd be happy to take a look at a > refactor patch which would extract that helper (and wire it up for > imx). > Thanks for letting me know. As our original flight to XDC has been canceled and we are re-routed to the evening flight the boredom might actually kick in. :) Regards, Lucas
[PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
On Tuesday, 20 September 2016, Emil Velikov wrote: > Did you miss my earlier question/suggestion that mentions that ? > Please scratch that. Just noticed the timestamps. Emil -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/70146c43/attachment.html>
[PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.
On Monday, 19 September 2016, Peter Griffin wrote: > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following > recursive dependency. > > It must not select, it must depend? Did you miss my earlier question/suggestion that mentions that ? Regards, Emil -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160920/65ca951e/attachment.html>
[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1
https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #83 from Michel Dänzer --- (In reply to Weber K. from comment #81) > And since I put this in grub.cfg and fstab, never had a black screen again: > rootflags=relatime,lazytime,commit=60 iommu=noagp radeon.dpm=1 It could be iommu=noagp, at least that would make more sense than filesystem flags... -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled
https://bugs.freedesktop.org/show_bug.cgi?id=97840 --- Comment #8 from Mike Lothian --- I'm headed off to work now, will test tonight -- 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/20160920/7a070355/attachment.html>
[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled
https://bugs.freedesktop.org/show_bug.cgi?id=97840 --- Comment #7 from Michel Dänzer --- (In reply to Mike Lothian from comment #6) > I've just tested the latest wip-4.9 branch and now X won't even start Can you bisect which change caused that? -- 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/20160920/6da7c42c/attachment.html>
[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled
https://bugs.freedesktop.org/show_bug.cgi?id=97840 --- Comment #6 from Mike Lothian --- Created attachment 126643 --> https://bugs.freedesktop.org/attachment.cgi?id=126643&action=edit Error I've just tested the latest wip-4.9 branch and now X won't even start -- 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/20160920/94274066/attachment.html>
[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1
https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #82 from Weber K. --- Ooops... Forgot to mention... I appreciate your good work supporting kernel! Thank all of you very much! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1
https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #81 from Weber K. --- I think so as well... Anyway before, I had to put this in kernel parameters, or else, black screen and hang up during boot: radeon.dpm=0 And since I put this in grub.cfg and fstab, never had a black screen again: rootflags=relatime,lazytime,commit=60 iommu=noagp radeon.dpm=1 I don't understand why, but it worked... I have pcie XFX HD6850 AMD 1055T FOSS drivers, kernel 4.4.14 . Maybe it could help you to troubleshoot this error too. I think it's worth a try, if you have spare time. If this don't help you... Then I'm sorry... -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 97840] [regression] [tonga] Freeze since new memory manager enabled
https://bugs.freedesktop.org/show_bug.cgi?id=97840 Michel Dänzer changed: What|Removed |Added CC||deathsimple at vodafone.de --- Comment #5 from Michel Dänzer --- Mike, have you tested https://patchwork.freedesktop.org/patch/110851/ and possibly the more recent patches on https://patchwork.freedesktop.org/project/amd-xorg-ddx/patches/?submitter=11066 ? -- 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/20160920/803654ff/attachment.html>
[RFC PATCH v3 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite
On 09/20/2016 03:12 AM, Fabio Estevam wrote: > On Mon, Sep 19, 2016 at 4:02 PM, Randy Li wrote: > >> + vcc_sys_lcd: sys-lcd { >> + compatible = "regulator-fixed"; >> + regulator-name = "vcc_5v"; >> + regulator-min-microvolt = <500>; >> + regulator-max-microvolt = <500>; >> + gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>; > Is this really active high? If so, you should add the > 'enable-active-high' property. I see, thank you. Btw, let me make it clearly, it is really an independentTransistor, not be controlled by PMIC.
[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1
https://bugzilla.kernel.org/show_bug.cgi?id=68571 --- Comment #80 from Alex Deucher --- dpm has nothing to do with the filesystem. -- You are receiving this mail because: You are watching the assignee of the bug.
[RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel
The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be supported by the simple panel driver. Signed-off-by: Randy Li --- .../display/panel/chunghwa,claa070wp03xg.txt | 7 ++ drivers/gpu/drm/panel/panel-simple.c | 27 ++ 2 files changed, 34 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt diff --git a/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt new file mode 100644 index 000..dd22685 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt @@ -0,0 +1,7 @@ +Chunghwa Picture Tubes Ltd. 7" WXGA TFT LCD panel + +Required properties: +- compatible: should be "chunghwa,claa070wp03xg" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index f178998..3204e6b 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -583,6 +583,30 @@ static const struct panel_desc avic_tm070ddh03 = { }, }; +static const struct drm_display_mode chunghwa_claa070wp03xg_mode = { + .clock = 66770, + .hdisplay = 800, + .hsync_start = 800 + 49, + .hsync_end = 800 + 49 + 33, + .htotal = 800 + 49 + 33 + 17, + .vdisplay = 1280, + .vsync_start = 1280 + 1, + .vsync_end = 1280 + 1 + 7, + .vtotal = 1280 + 1 + 7 + 15, + .vrefresh = 60, + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC, +}; + +static const struct panel_desc chunghwa_claa070wp03xg = { + .modes = &chunghwa_claa070wp03xg_mode, + .num_modes = 1, + .bpc = 6, + .size = { + .width = 94, + .height = 150, + }, +}; + static const struct drm_display_mode chunghwa_claa101wa01a_mode = { .clock = 72070, .hdisplay = 1366, @@ -1544,6 +1568,9 @@ static const struct of_device_id platform_of_match[] = { .compatible = "avic,tm070ddh03", .data = &avic_tm070ddh03, }, { + .compatible = "chunghwa,claa070wp03xg", + .data = &chunghwa_claa070wp03xg, + }, { .compatible = "chunghwa,claa101wa01a", .data = &chunghwa_claa101wa01a }, { -- 2.7.4
[RFC PATCH v3 1/2] ARM: dts: samsung: add rga-lvds panel in itop elite
It is actually a lvds panel connected through a rga-lvds bridge. The touchscreen is communicated with i2c bus but the driver is not support now. Signed-off-by: Randy Li --- arch/arm/boot/dts/exynos4412-itop-elite.dts | 54 +++-- 1 file changed, 52 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/exynos4412-itop-elite.dts b/arch/arm/boot/dts/exynos4412-itop-elite.dts index b08705e..5153522 100644 --- a/arch/arm/boot/dts/exynos4412-itop-elite.dts +++ b/arch/arm/boot/dts/exynos4412-itop-elite.dts @@ -138,6 +138,36 @@ assigned-clocks = <&clock CLK_MOUT_CAM0>; assigned-clock-parents = <&clock CLK_XUSBXTI>; }; + + vcc_sys_lcd: sys-lcd { + compatible = "regulator-fixed"; + regulator-name = "vcc_5v"; + regulator-min-microvolt = <500>; + regulator-max-microvolt = <500>; + gpio = <&gpl0 4 GPIO_ACTIVE_HIGH>; + }; + + panel: panel at 0 { + compatible = "chunghwa,claa070wp03xg"; + + power-supply = <&vcc_sys_lcd>; + enable-gpios = <&gpl0 2 GPIO_ACTIVE_HIGH>; + backlight = <&bl>; + + port { + lcd_ep: endpoint { + remote-endpoint = <&rga_lvds>; + }; + }; + }; + + bl: backlight { + compatible = "pwm-backlight"; + pwms = <&pwm 1 500 PWM_POLARITY_INVERTED>; + brightness-levels = <0 5 12 16 32 64 128 255>; + default-brightness-level = <5>; + power-supply = <&vcc_sys_lcd>; + }; }; &adc { @@ -171,11 +201,31 @@ assigned-clock-rates = <0>, <17600>; }; +&fimd { + pinctrl-0 = <&lcd_clk &lcd_data24>; + pinctrl-names = "default"; + status = "okay"; + ports { + #address-cells = <1>; + #size-cells = <0>; + port at 3 { + reg = <3>; + rga_lvds: endpoint { + remote-endpoint = <&lcd_ep>; + }; + }; + }; +}; + &hsotg { dr_mode = "peripheral"; status = "okay"; }; +&i2c_3 { + status = "okay"; +}; + &i2c_4 { samsung,i2c-sda-delay = <100>; samsung,i2c-slave-addr = <0x10>; @@ -215,9 +265,9 @@ &pwm { status = "okay"; - pinctrl-0 = <&pwm0_out>; + pinctrl-0 = <&pwm0_out &pwm1_out>; pinctrl-names = "default"; - samsung,pwm-outputs = <0>; + samsung,pwm-outputs = <0>, <1>; }; &sdhci_2 { -- 2.7.4