[PATCH v2] sync_file: Return consistent status in SYNC_IOC_FILE_INFO
sync_file_ioctl_fence_info has a race between filling the status of the underlying fences and the overall status of the sync_file. If fence transitions in the time frame between its sync_fill_fence_info and the later dma_fence_is_signaled for the sync_file, the returned information is inconsistent showing non-signaled underlying fences but an overall signaled state. This patch changes sync_file_ioctl_fence_info to track what has been encoded and using that as the overall sync_file status. Tested-by: Vamsidhar Reddy GaddamSigned-off-by: John Einar Reitan Cc: Sumit Semwal Cc: Gustavo Padovan Cc: dri-devel@lists.freedesktop.org --- Changes since v1 (thanks Chris Wilson): - Replaced an unneeded local variable by writing directly to the struct drivers/dma-buf/sync_file.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c index 66fb40d0ebdb..03830634e141 100644 --- a/drivers/dma-buf/sync_file.c +++ b/drivers/dma-buf/sync_file.c @@ -383,7 +383,7 @@ static long sync_file_ioctl_merge(struct sync_file *sync_file, return err; } -static void sync_fill_fence_info(struct dma_fence *fence, +static int sync_fill_fence_info(struct dma_fence *fence, struct sync_fence_info *info) { strlcpy(info->obj_name, fence->ops->get_timeline_name(fence), @@ -399,6 +399,8 @@ static void sync_fill_fence_info(struct dma_fence *fence, test_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, >flags) ? ktime_to_ns(fence->timestamp) : ktime_set(0, 0); + + return info->status; } static long sync_file_ioctl_fence_info(struct sync_file *sync_file, @@ -424,8 +426,12 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, * sync_fence_info and return the actual number of fences on * info->num_fences. */ - if (!info.num_fences) + if (!info.num_fences) { + info.status = dma_fence_is_signaled(sync_file->fence); goto no_fences; + } else { + info.status = 1; + } if (info.num_fences < num_fences) return -EINVAL; @@ -435,8 +441,10 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, if (!fence_info) return -ENOMEM; - for (i = 0; i < num_fences; i++) - sync_fill_fence_info(fences[i], _info[i]); + for (i = 0; i < num_fences; i++) { + int status = sync_fill_fence_info(fences[i], _info[i]); + info.status = info.status <= 0 ? info.status : status; + } if (copy_to_user(u64_to_user_ptr(info.sync_fence_info), fence_info, size)) { @@ -446,7 +454,6 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, no_fences: sync_file_get_name(sync_file, info.name, sizeof(info.name)); - info.status = dma_fence_is_signaled(sync_file->fence); info.num_fences = num_fences; if (copy_to_user((void __user *)arg, , sizeof(info))) -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] sync_file: Return consistent status in SYNC_IOC_FILE_INFO
Quoting John Einar Reitan (2017-10-09 14:49:36) > sync_file_ioctl_fence_info has a race between filling the status > of the underlying fences and the overall status of the sync_file. > If fence transitions in the time frame between its sync_fill_fence_info > and the later dma_fence_is_signaled for the sync_file, the returned > information is inconsistent showing non-signaled underlying fences but > an overall signaled state. > > This patch changes sync_file_ioctl_fence_info to track what has been > encoded and using that as the overall sync_file status. > > Tested-by: Vamsidhar Reddy Gaddam> Signed-off-by: John Einar Reitan > Cc: Sumit Semwal > Cc: Gustavo Padovan > Cc: dri-devel@lists.freedesktop.org Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93301] ns2_linux32: radeon VM fault on Hawaii (+mmap errors)
https://bugs.freedesktop.org/show_bug.cgi?id=93301 Nicolai Hähnlechanged: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #30 from Nicolai Hähnle --- This seems to be fixed. If the high memory use is still an issue some place, it seems best to open a new bug. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hwc] drm_hwcomposer: remove NVIDIA importer
On Fri, Oct 06, 2017 at 05:02:03PM -0500, Rob Herring wrote: > There's no opensource implementation for the NVIDIA gralloc implementation, > so remove it as it is not testable. > > As all of the gralloc perform() operations are specific to it, they can be > removed, too. > > Signed-off-by: Rob Herring> --- > Android.mk | 5 - > drmhwcgralloc.h | 33 - > platformnv.cpp | 374 > > 3 files changed, 412 deletions(-) > delete mode 100644 platformnv.cpp This is in agreement with other parts of the open source graphics stack, so: Acked-by: Thierry Reding If anyone wants to revive this, they'd have to provide an open source implementation of gralloc first, and then this commit could always be reverted. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hwc] drm_hwcomposer: remove NVIDIA importer
Hey Thierry, On Mon, 2017-10-09 at 15:07 +0200, Thierry Reding wrote: > On Fri, Oct 06, 2017 at 05:02:03PM -0500, Rob Herring wrote: > > There's no opensource implementation for the NVIDIA gralloc > > implementation, > > so remove it as it is not testable. > > > > As all of the gralloc perform() operations are specific to it, they > > can be > > removed, too. > > > > Signed-off-by: Rob Herring> > --- > > Android.mk | 5 - > > drmhwcgralloc.h | 33 - > > platformnv.cpp | 374 > > > > 3 files changed, 412 deletions(-) > > delete mode 100644 platformnv.cpp > > This is in agreement with other parts of the open source graphics > stack, > so: > > Acked-by: Thierry Reding > > If anyone wants to revive this, they'd have to provide an open source > implementation of gralloc first, and then this commit could always be > reverted. > > Thierry Excellent, thanks for the quick reply. Rob. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hwc] drm_hwcomposer: use upstream DRM_MODE_{ROTATE, REFLECT} defines
Hey Thierry, On Sat, 2017-10-07 at 01:29 +0200, Thierry Reding wrote: > On Fri, Oct 06, 2017 at 04:46:48PM -0500, Rob Herring wrote: > > The DRM_REFLECT_* and DRM_ROTATE_* defines were not upstream, but > > now > > they are. Convert to using the upstream version which are defined > > as a > > bit mask rather than a bit position. > > > > Signed-off-by: Rob Herring> > --- > > drmdisplaycompositor.cpp | 10 +- > > 1 file changed, 5 insertions(+), 5 deletions(-) > > Reviewed-by: Thierry Reding I pushed this patch, but I slightly bungled it, and missed appending your r-b to the commit message. Sorry about that. Rob. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 1/3] backlight: Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
Den 09.10.2017 11.06, skrev Daniel Thompson: On 06/10/17 19:01, Noralf Trønnes wrote: Den 03.10.2017 11.04, skrev Daniel Vetter: On Tue, Oct 03, 2017 at 09:51:49AM +0100, Daniel Thompson wrote: On 03/10/17 09:03, Daniel Vetter wrote: On Mon, Oct 02, 2017 at 12:00:54PM +0300, Jani Nikula wrote: On Mon, 02 Oct 2017, Daniel Thompsonwrote: So I'm coming to this patchset cold but can you explain *why* something wants to call of_find_backlight_by_node() when there is no backlight support enabled. Why isn't the code that called is conditional on BACKLIGHT_CLASS_DEVICE? The undefined symbol issue is a pain but to be honest I'd rather solve the use of undefined symbols by avoiding declaring them; this making them into compile errors rather than link errors. Typically the kernel header files define static inline stubs of the functions when the actual functions aren't configured/built. The code using the functions looks the same regardless of the config option, and handles the -ENODEV or NULL or whatever returns from the stubs gracefully. With the inlines, the compiler can usually throw out much of the code anyway. In this regard, the backlight interface is an exception, forcing the callers to wrap the code around IS_ENABLED(BACKLIGHT_CLASS_DEVICE), not the rule. fwiw, I think it'd be great if we can move backlight over to the common pattern, like everyone else. It's pretty big pain as-is ... For sure, after Jani's mail yesterday I looked at the GMA500 driver and concluded I didn't want code related to backlight having to look like that! Currently the three main patterns of use are: 1. Standalone drivers simple depend on BACKLIGHT_CLASS_DEVICE, 2. Some compound drivers select BACKLIGHT_CLASS_DEVICE (the AMD DRM driver is an example of this), 3. Other compound drivers perform heroics with the pre-processor. The main reason I'm not just agreeing straight away is that, to adopt the static inline pattern for the whole API, we have to believe that #3 above is desirable. Given the size and scope of the compound drivers in #3 above, I don't entirely understand why they want to avoid the select. People love to over-configure their kernels and shave off a few bytes. And big gpu drivers might have backlight support, but not always need it (e.g. if you run without a panel as e.g. a tv set-top-box). Same with e.g. a driver that supports both OF/DT and pci to find its devices. On the desktop gpu driver side we don't really subscribe to this idea of making everything optional, hence select (mostly), except select is a huge pain. On the mobile/soc gpu side, #3 seems to be the desired outcome. Doing static inline helpers for backlights would make both easier (since in the end for desktop you just get a distro kernel that enables everything anyway). So yeah, imo if you think backlight should be a Kconfig, then it should have static inline dummy functions to make life simpler for everyone. Only exception are pure driver-only subsystem code which aren't ever called by anything outside of your subsystem. But since the point of the backlight subsystem is to provide backlight support to other drivers (there's still the dream that we don't offload this onto userspace, that just doesn't work well) we really should have these static inline helpers. I suggest we put all the backlight subsystem only functionality we need, into the backlight subsystem :-) I've put together a suggestion below and I've deliberately dropped the of_ infix in backlight_get() to make room for possible future additions that can make it possible to set the connection between device and backlight using platform table or ACPI, fashioned after gpiolib. Looks good to me. If I've read this right, other sub-systems can use these symbols with or without BACKLIGHT_CLASS_DEVICE and still compile OK? The code haven't seen a compiler, but that's the idea. Noralf. Daniel. include/linux/backlight.h: /** * backlight_enable - Enable backlight * @bd: the backlight device to enable */ static inline int backlight_enable(struct backlight_device *bd) { if (!bd) return 0; bd->props.power = FB_BLANK_UNBLANK; bd->props.state &= ~BL_CORE_FBBLANK; return backlight_update_status(bd); } /** * backlight_disable - Disable backlight * @bd: the backlight device to disable */ static inline int backlight_disable(struct backlight_device *bd) { if (!bd) return 0; bd->props.power = FB_BLANK_POWERDOWN; bd->props.state |= BL_CORE_FBBLANK; return backlight_update_status(bd); } /** * backlight_put - Drop backlight reference * @bd: the backlight device to put */ static inline void backlight_put(struct backlight_device *bd) { if (bd) put_device(bd->dev); } #if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE) struct backlight_device *backlight_get(struct device *dev); struct backlight_device
Re: [PATCH v2 1/3] dt-bindings: Add document for rockchip RGB output interface
On Mon, Oct 9, 2017 at 3:06 AM, Sandy Huangwrote: > Hi rob, > Thanks for your reply. > > 在 2017/10/4 5:56, Rob Herring 写道: >> >> On Fri, Sep 22, 2017 at 11:00:26AM +0800, Sandy Huang wrote: >>> >>> This path add support rv1108 rgb output interface driver. >>> >>> Signed-off-by: Sandy Huang >>> --- >>> Changes in v2: >>> 1. rename rockchip,rgb-mode to rgb-mode; >> >> >> You can't just drop the vendor. This needs to be documented in a common >> place that others will find and use. See panel-common.txt or >> panel-dpi.txt. >> >> Alternatively, you could just drop it and let the panel compatible imply >> what the mode is. >> >> > ok, get it, i will move the rgb-mode to panel and describe it at > panel-rgb.txt. the patches will be send soon later. Don't create yet another common panel file. We already have panel-dpi.txt which is for digital parallel interface. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Dynamically adding a PCI subfunction
Hello, As a bit of background, all NVIDIA GPUs since GT215 have an audio subfunction for HDMI(/DP) audio to be sent to the sink. This generally works. However some, especially laptop, devices come up with that function disabled. We have a quirk to enable it when coming back from runpm, but that doesn't help the init case. Basically we have to write a bit to the PCI config space: https://github.com/torvalds/linux/blob/v4.12/drivers/gpu/drm/nouveau/nouveau_drm.c#L783 (MMIO 0x88000 is an alias for the PCI config space) This works for runtime pm resume, since the device was originally there and we just have to make sure the underlying device agrees with it, but when it's missing on boot, we have to convince linux that it exists, bind a driver, etc. What's the best way of going about doing that? Thanks, -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103138] [regression, vega] BUG: Bad page state in process gnome-shell pfn:77cc33
https://bugs.freedesktop.org/show_bug.cgi?id=103138 --- Comment #4 from Christian König--- Created attachment 134764 --> https://bugs.freedesktop.org/attachment.cgi?id=134764=edit Possible fix No problem, does the attached patch help? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103168] [CI] igt@prime_mmap_coherency@write-and-fail - fai - Failed assertion: !(!stale)
https://bugs.freedesktop.org/show_bug.cgi?id=103168 Chris Wilsonchanged: What|Removed |Added Component|DRM/Intel |IGT QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org --- Comment #1 from Chris Wilson --- Just a silliness in the test to assume it was able to hit the cache coherency issue. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hwc] drm_hwcomposer: remove NVIDIA importer
Hey again, Just pushed this patch. Rob. On Mon, 2017-10-09 at 15:58 +0200, Robert Foss wrote: > Hey Thierry, > > On Mon, 2017-10-09 at 15:07 +0200, Thierry Reding wrote: > > On Fri, Oct 06, 2017 at 05:02:03PM -0500, Rob Herring wrote: > > > There's no opensource implementation for the NVIDIA gralloc > > > implementation, > > > so remove it as it is not testable. > > > > > > As all of the gralloc perform() operations are specific to it, > > > they > > > can be > > > removed, too. > > > > > > Signed-off-by: Rob Herring> > > --- > > > Android.mk | 5 - > > > drmhwcgralloc.h | 33 - > > > platformnv.cpp | 374 -- > > > -- > > > > > > 3 files changed, 412 deletions(-) > > > delete mode 100644 platformnv.cpp > > > > This is in agreement with other parts of the open source graphics > > stack, > > so: > > > > Acked-by: Thierry Reding > > > > If anyone wants to revive this, they'd have to provide an open > > source > > implementation of gralloc first, and then this commit could always > > be > > reverted. > > > > Thierry > > Excellent, thanks for the quick reply. > > > Rob. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 196615] amdgpu - resume from suspend is no longer working on rx480
https://bugzilla.kernel.org/show_bug.cgi?id=196615 --- Comment #19 from klavkala...@gmail.com --- The code is still there in 4.14-rc4. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] staging: ion: simplify ioctl args checking function
On 10/09/2017 02:21 AM, Benjamin Gaignard wrote: > 2017-09-27 15:20 GMT+02:00 Benjamin Gaignard: >> Make arguments checking more easy to read. >> > > Hi Laura, > > Even if we don't have found a solution for the second patch I believe > this one could be useful. > May I ask you your point of view on those few lines ? > > Benjamin > Yes, this looks better. Acked-by: Laura Abbott >> Signed-off-by: Benjamin Gaignard >> --- >> drivers/staging/android/ion/ion-ioctl.c | 11 +-- >> 1 file changed, 5 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/staging/android/ion/ion-ioctl.c >> b/drivers/staging/android/ion/ion-ioctl.c >> index d9f8b14..e26b786 100644 >> --- a/drivers/staging/android/ion/ion-ioctl.c >> +++ b/drivers/staging/android/ion/ion-ioctl.c >> @@ -27,19 +27,18 @@ union ion_ioctl_arg { >> >> static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg) >> { >> - int ret = 0; >> - >> switch (cmd) { >> case ION_IOC_HEAP_QUERY: >> - ret = arg->query.reserved0 != 0; >> - ret |= arg->query.reserved1 != 0; >> - ret |= arg->query.reserved2 != 0; >> + if (arg->query.reserved0 || >> + arg->query.reserved1 || >> + arg->query.reserved2) >> + return -EINVAL; >> break; >> default: >> break; >> } >> >> - return ret ? -EINVAL : 0; >> + return 0; >> } >> >> /* fix up the cases where the ioctl direction bits are incorrect */ >> -- >> 2.7.4 >> > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: don't use compound pages for now
From: Christian KönigWe need to figure out first how to correctly map them into the CPU page tables. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c index e5ef10d..96ad129 100644 --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c @@ -913,6 +913,7 @@ static gfp_t ttm_dma_pool_gfp_flags(struct ttm_dma_tt *ttm_dma, bool huge) if (huge) { gfp_flags |= GFP_TRANSHUGE; gfp_flags &= ~__GFP_MOVABLE; + gfp_flags &= ~__GFP_COMP; } return gfp_flags; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()
On Mon, Sep 25, 2017 at 08:19:12PM +0100, Chris Wilson wrote: > Quoting ville.syrj...@linux.intel.com (2016-04-01 19:48:50) > > From: Ville Syrjälä> > > > Eliminate the duplicate code for pipe timing readout in > > intel_crtc_mode_get() by using the functions we use for the normal state > > readout. > > > > v2: Store dotclock in adjusted_mode instead of the final mode > > > > Cc: dri-devel@lists.freedesktop.org > > Cc: Rob Kramer > > Cc: Daniel Vetter > > Signed-off-by: Ville Syrjälä > Reviewed-by: Chris Wilson Thanks for the review. Patches pushed to dinq. > > Fixes a pipe-state warn for me, > Tested-by: Chris Wilson However, now that I look at the code again I'm not 100% sure why this fixed anything. The readout still seems to fail at fully populating the mode flags. I'll post a more thorough solution that simply calls the normal state readout hooks for the crtc and encoder... -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103175] R9285 Unreal tournament perf regression with agd5f 4.15-wip kernels possibly CPU related
https://bugs.freedesktop.org/show_bug.cgi?id=103175 Bug ID: 103175 Summary: R9285 Unreal tournament perf regression with agd5f 4.15-wip kernels possibly CPU related Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: adf.li...@gmail.com Created attachment 134765 --> https://bugs.freedesktop.org/attachment.cgi?id=134765=edit good perf gallium hud on 4.14 kernel. R9285 Tonga, Compared to older kernels I have a perf regression with latest 4.14.0-rc3 based and previous 4.13-rc5 based agd5f 4.15-wip kernels. This doesn't seem to affect other things like xonotic or unigine demos. Issue = on fixes 4.14 and other older kernels I've tried, the game is OK ish perf wise, 25-60 fps. On 4.15-wip its 10fps. Using HUD one obvious difference is that the slow case is only mostly using one cpu core, on a good kernel all 4 of my old phenom 2 x4 are used - possible red herring of course, I'll upload some screenshots. The game is pre-alpha and doesn't always render properly - but it was vaguely playable fps wise until this kernel. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Dynamically adding a PCI subfunction
Am 09.10.2017 um 17:57 schrieb Ilia Mirkin: On Mon, Oct 9, 2017 at 11:45 AM, Christian Königwrote: Am 09.10.2017 um 16:41 schrieb Ilia Mirkin: Hello, As a bit of background, all NVIDIA GPUs since GT215 have an audio subfunction for HDMI(/DP) audio to be sent to the sink. This generally works. However some, especially laptop, devices come up with that function disabled. We have a quirk to enable it when coming back from runpm, but that doesn't help the init case. Basically we have to write a bit to the PCI config space: https://github.com/torvalds/linux/blob/v4.12/drivers/gpu/drm/nouveau/nouveau_drm.c#L783 (MMIO 0x88000 is an alias for the PCI config space) This works for runtime pm resume, since the device was originally there and we just have to make sure the underlying device agrees with it, but when it's missing on boot, we have to convince linux that it exists, bind a driver, etc. What's the best way of going about doing that? Sounds similar to my work about resizing BARs. I would just try to enable the device and then trigger a rescan of the BUS where it is attached (similar to echo 1 > /sys/bus/pci/devices/$pci_id_of_your_bus/rescan). There is certainly a function in the PCI subsystem you just need to call for that. I'm not exactly familiar with the pci subsystem. I know that hotplug is a thing, at least in theory. I figured it'd be something related to that, since this is in essence a random device appearing on the bus after the initial scan. Is a bus rescan safe on a fully initialized system? Either way, some specific functions to call or look at would be great. Well I would just try to use pci_rescan_bus(), as far as I know that should be save even when devices are already configured. Christian. Cheers, -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()
On Mon, Oct 09, 2017 at 05:24:29PM +0100, Chris Wilson wrote: > Quoting Ville Syrjälä (2017-10-09 17:18:17) > > On Mon, Sep 25, 2017 at 08:19:12PM +0100, Chris Wilson wrote: > > > Quoting ville.syrj...@linux.intel.com (2016-04-01 19:48:50) > > > > From: Ville Syrjälä> > > > > > > > Eliminate the duplicate code for pipe timing readout in > > > > intel_crtc_mode_get() by using the functions we use for the normal state > > > > readout. > > > > > > > > v2: Store dotclock in adjusted_mode instead of the final mode > > > > > > > > Cc: dri-devel@lists.freedesktop.org > > > > Cc: Rob Kramer > > > > Cc: Daniel Vetter > > > > Signed-off-by: Ville Syrjälä > > > Reviewed-by: Chris Wilson > > > > Thanks for the review. Patches pushed to dinq. > > > > > > > > Fixes a pipe-state warn for me, > > > Tested-by: Chris Wilson > > > > However, now that I look at the code again I'm not 100% sure why this > > fixed anything. The readout still seems to fail at fully populating the > > mode flags. I'll post a more thorough solution that simply calls the > > normal state readout hooks for the crtc and encoder... > > The first patch fixed up the implied A,B transcoder mixup. I just tested > both patches together. Do you want me to double check if it was just the > first patch that silenced the warnings? I'm just happy to have a clean > boot! I think the first patch should have been a nop for you since 845g only has the one pipe. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] sync_file: Return consistent status in SYNC_IOC_FILE_INFO
2017-10-09 Chris Wilson: > Quoting John Einar Reitan (2017-10-09 14:49:36) > > sync_file_ioctl_fence_info has a race between filling the status > > of the underlying fences and the overall status of the sync_file. > > If fence transitions in the time frame between its sync_fill_fence_info > > and the later dma_fence_is_signaled for the sync_file, the returned > > information is inconsistent showing non-signaled underlying fences but > > an overall signaled state. > > > > This patch changes sync_file_ioctl_fence_info to track what has been > > encoded and using that as the overall sync_file status. > > > > Tested-by: Vamsidhar Reddy Gaddam > > Signed-off-by: John Einar Reitan > > Cc: Sumit Semwal > > Cc: Gustavo Padovan > > Cc: dri-devel@lists.freedesktop.org > Reviewed-by: Chris Wilson Pushed to drm-misc-fixes. Gustavo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103175] R9285 Unreal tournament perf regression with agd5f 4.15-wip kernels possibly CPU related
https://bugs.freedesktop.org/show_bug.cgi?id=103175 --- Comment #2 from Andy Furniss--- Created attachment 134767 --> https://bugs.freedesktop.org/attachment.cgi?id=134767=edit bad on latest 4.15-wip cpu still different but not as obvious. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH hwc] drm_hwcomposer: fix return values for ValidateDisplay
According to the API documentation, if we've set num_types, then the return value should be HWC2::Error::HasChanges. Signed-off-by: Rob Herring--- drmhwctwo.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drmhwctwo.cpp b/drmhwctwo.cpp index 89399bf1ba33..0f258770a8bb 100644 --- a/drmhwctwo.cpp +++ b/drmhwctwo.cpp @@ -701,7 +701,7 @@ HWC2::Error DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t *num_types, break; } } - return HWC2::Error::None; + return *num_types ? HWC2::Error::HasChanges : HWC2::Error::None; } HWC2::Error DrmHwcTwo::HwcLayer::SetCursorPosition(int32_t x, int32_t y) { -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103175] R9285 Unreal tournament perf regression with agd5f 4.15-wip kernels possibly CPU related
https://bugs.freedesktop.org/show_bug.cgi?id=103175 --- Comment #1 from Andy Furniss--- Created attachment 134766 --> https://bugs.freedesktop.org/attachment.cgi?id=134766=edit bad on previous 4.15 kernel cpu load different. All tests done with both CPUs and GPU forced to perf. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]
Daniel Vetterwrites: > I just figured that -modesetting would be the simplest domenstration > vehicle, since the vulkan patches don't look ready yet. I need fully > reviewed userspace before we can land any kernel stuff. Doing > the quick modesetting conversion would unblock. I've provided a patch for the modesetting driver and the preliminary bits are merged, leaving only a fairly straightforward addition of the new ioctls to that code. I'm not sure how to make more progress there at this point; that code would need testing, and it requires a hand-patched kernel to test. I also posted IGT tests for the new functionality, again, getting those reviewed and tested depends on someone willing to build a patched kernel. Dave Airlie has started trying to get that done. >> (regarding FIRST_PIXEL_OUT): >> >> If the timestamp is the only important thing, it sounds like the kernel >> already satisfies that, which is cool. > > Would be good to confirm that. If it's not, we have a problem. Michel Dänzer says that the timestamp provided is computed to be first_pixel_out for all hardware. Given that, I suggest we specify that in the documentation and remove this bit from the API. Seem reasonable? -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND PATCH v5] ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board
On Mon, Oct 09, 2017 at 09:39:38AM +0200, Maciej Purski wrote: > Add HDMI and Sil9234 MHL converter to Trats2 board. > Following in SoC devices have been enabled: > - HDMI (HDMI signal encoder), > - Mixer (video buffer scanout device), > - I2C_5 bus (used for HDMI DDC) > - I2C_8 bus (used for HDMI_PHY control). > > Based on previous work by: > Tomasz Stanislawski> > Signed-off-by: Maciej Purski > Reviewed-by: Andrzej Hajda > --- > arch/arm/boot/dts/exynos4412-trats2.dts | 111 > > 1 file changed, 111 insertions(+) > Thanks, applied. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/3] drm/dp: WARN about invalid/unknown link rates and bw codes
> -Original Message- > From: Jani Nikula [mailto:jani.nik...@intel.com] > Sent: Monday, October 09, 2017 5:30 AM > To: intel-...@lists.freedesktop.org > Cc: jani.nik...@intel.com; Deucher, Alexander; Thierry Reding; Rob Clark; > Sean Paul; Manasi Navare; dri-devel@lists.freedesktop.org > Subject: [PATCH 1/3] drm/dp: WARN about invalid/unknown link rates and > bw codes > > Falling back to the lowest value is likely the only thing we can do, but > doing it silently seems like a bad thing to do. Catch it early and make > loud noises. > > Cc: Alex Deucher> Cc: Thierry Reding > Cc: Rob Clark > Cc: Sean Paul > Cc: Manasi Navare > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Jani Nikula Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/drm_dp_helper.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_dp_helper.c > b/drivers/gpu/drm/drm_dp_helper.c > index 08af8d6b844b..dca21b5a03ec 100644 > --- a/drivers/gpu/drm/drm_dp_helper.c > +++ b/drivers/gpu/drm/drm_dp_helper.c > @@ -137,8 +137,10 @@ > EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay); > u8 drm_dp_link_rate_to_bw_code(int link_rate) > { > switch (link_rate) { > - case 162000: > default: > + WARN(1, "unknown DP link rate %d, using %x\n", link_rate, > + DP_LINK_BW_1_62); > + case 162000: > return DP_LINK_BW_1_62; > case 27: > return DP_LINK_BW_2_7; > @@ -151,8 +153,9 @@ EXPORT_SYMBOL(drm_dp_link_rate_to_bw_code); > int drm_dp_bw_code_to_link_rate(u8 link_bw) > { > switch (link_bw) { > - case DP_LINK_BW_1_62: > default: > + WARN(1, "unknown DP link bw code %x, using 162000\n", > link_bw); > + case DP_LINK_BW_1_62: > return 162000; > case DP_LINK_BW_2_7: > return 27; > -- > 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3] drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()
On Mon, Oct 9, 2017 at 4:59 AM, Daniel Vetterwrote: > On Sun, Oct 08, 2017 at 03:43:35PM +0100, Chris Wilson wrote: >> Quoting Harsha Sharma (2017-10-08 15:04:07) >> > @@ -624,7 +624,7 @@ static bool intel_fbdev_init_bios(struct drm_device >> > *dev, >> > ifbdev->preferred_bpp = fb->base.format->cpp[0] * 8; >> > ifbdev->fb = fb; >> > >> > - drm_framebuffer_reference(>fb->base); >> > + drm_framebuffer_put(>fb->base); >> >> Whoops. > > Hm yeah, how did this happen? Does cocci really do this, or is that an > accident from manually fixing stuff up? Running the spatch from the commit message gives me the correct substitution: @@ -627,7 +627,7 @@ static bool intel_fbdev_init_bios(struct drm_device *dev, ifbdev->preferred_bpp = fb->base.format->cpp[0] * 8; ifbdev->fb = fb; - drm_framebuffer_reference(>fb->base); + drm_framebuffer_get(>fb->base); /* Final pass to check if any active pipes don't have fbs */ for_each_crtc(dev, crtc) { Probably just finger slip since this is the last chunk before the omitted selftests changes. Harsha: the "better" way to omit the selftests without hand tuning the patch would be to run the cocci spatch on i915 as normal, and then run "git checkout -- drivers/gpu/drm/i915/selftests/" before committing. It's dangerous to edit patches by hand, or to misrepresent a patch as being the result of a cocci spatch when it's not. Sean > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Outreachy kernel] Re: [PATCH v2] drm/tegra: Replace dev_* with DRM_DEV_*
On Mon, Sep 25, 2017 at 3:38 AM, Thierry Redingwrote: > On Sun, Sep 24, 2017 at 10:13:57PM +0530, Harsha Sharma wrote: >> Replace all occurences of dev_info/err/dbg with DRM_DEV_INFO/ >> ERROR/DEBUG as we have DRM_DEV_* variants of drm print macros >> Done using following coccinelle semantic patch >> >> @r@ >> @@ >> >> ( >> -dev_info >> +DRM_DEV_INFO >> | >> -dev_err >> +DRM_DEV_ERROR >> | >> -dev_dbg >> +DRM_DEV_DEBUG >> ) >> >> Signed-off-by: Harsha Sharma >> --- >> Changes in v2: >> -Break line over 80 characters >> -Changes in comments not required > > Please don't do this. Most of the functions that you're trying to > replace here are not DRM_DEV_*() for a very specific reason: none of > them have anything to do with DRM/KMS in particular. This is important, > in my opinion, because these messages are very device-specific and the > additional information added by the DRM format string aren't useful in > the context. Hey Thierry, It's likely not useful to a tegra expert such as yourself. However, when I'm switching between platforms or providing log-parsing instructions, it's very useful to say "grep for drm". Without the common drm prefix, the reader needs to know they're looking for tegra-sor, tegra-dc, etc as well. Not a big deal, I just wanted to provide color for why someone might want this. > > Perhaps the only ones I consider to be good candidates for this > conversion are the ones in drivers/gpu/drm/tegra/fb.c because they deal > with the DRM fbdev setup and hence are not device specific. And even in > those cases I'm not sure we gain very much by this conversion, > especially since most of the replacements now end up having to split up > argument lists. > > Sorry if this isn't documented anywhere. I also suspect other driver > maintainers will be less picky about this sort of thing, so you might > have more luck there. I think the TODO entry states that contributors should check with the driver maintainers before taking on this work, so it is documented :) Sean > > Thierry > > -- > You received this message because you are subscribed to the Google Groups > "outreachy-kernel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to outreachy-kernel+unsubscr...@googlegroups.com. > To post to this group, send email to outreachy-ker...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/outreachy-kernel/20170925073841.GA12494%40ulmo.fritz.box. > For more options, visit https://groups.google.com/d/optout. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm/vc4: remove bridge from driver internal structure
Benjamin Gaignardwrites: > With a call to drm_of_panel_bridge_remove() we could remove > the bridge without store it in vc4_dpi internal driver structure. > > Signed-off-by: Benjamin Gaignard Reviewed-by: Eric Anholt Thanks for doing this cleanup! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103102] Cannot wake-up with an AMD RX 480 on Linux 4.13 and Linux 4.14
https://bugs.freedesktop.org/show_bug.cgi?id=103102 --- Comment #6 from Hadrien--- I tried Phoronix kernel image from Alex Deucher's drm-next-4.15-dc Git branch. I still get the same problem with and without amdgpu.dc=1. Oct 9 21:29:12 c18 kernel: [ 32.199451] [drm:amdgpu_vce_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 14 test failed Oct 9 21:29:12 c18 kernel: [ 32.199461] [drm:amdgpu_resume_phase2 [amdgpu]] *ERROR* resume of IP block failed -110 Oct 9 21:29:12 c18 kernel: [ 32.199471] [drm:amdgpu_device_resume [amdgpu]] *ERROR* amdgpu_resume failed (-110). Oct 9 21:29:12 c18 kernel: [ 32.199474] dpm_run_callback(): pci_pm_resume+0x0/0xa0 returns -110 Oct 9 21:29:12 c18 kernel: [ 32.199474] PM: Device :01:00.0 failed to resume async: error -110 Oct 9 21:29:12 c18 kernel: [ 32.199498] PM: resume of devices complete after 539.171 msecs I've been looking at the changelog of kernel 4.12.6 but there isn't much changes in amdgpu. Maybe there are changes in another impacting amdgpu? I have these errors before amdgpu errors: Oct 9 21:29:12 c18 kernel: [ 32.035186] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20170531/psargs-364) Oct 9 21:29:12 c18 kernel: [ 32.035188] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.PRT0._GTF, AE_NOT_FOUND (20170531/psparse-550) Oct 9 21:29:12 c18 kernel: [ 32.035206] ata6: SATA link down (SStatus 4 SControl 300) Oct 9 21:29:12 c18 kernel: [ 32.035225] ata2: SATA link down (SStatus 4 SControl 300) Oct 9 21:29:12 c18 kernel: [ 32.035231] ata1.00: supports DRM functions and may not be fully accessible Oct 9 21:29:12 c18 kernel: [ 32.035901] ata1.00: disabling queued TRIM support Oct 9 21:29:12 c18 kernel: [ 32.037457] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20170531/psargs-364) Oct 9 21:29:12 c18 kernel: [ 32.037459] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.PRT0._GTF, AE_NOT_FOUND (20170531/psparse-550) Oct 9 21:29:12 c18 kernel: [ 32.037531] ata1.00: supports DRM functions and may not be fully accessible Oct 9 21:29:12 c18 kernel: [ 32.038084] ata1.00: disabling queued TRIM support Oct 9 21:29:12 c18 kernel: [ 32.038704] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20170531/psargs-364) Oct 9 21:29:12 c18 kernel: [ 32.038706] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.PRT4._GTF, AE_NOT_FOUND (20170531/psparse-550) Oct 9 21:29:12 c18 kernel: [ 32.039418] ata1.00: configured for UDMA/133 Oct 9 21:29:12 c18 kernel: [ 32.055252] ata4: SATA link down (SStatus 4 SControl 300) Oct 9 21:29:12 c18 kernel: [ 32.082715] ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20170531/psargs-364) Oct 9 21:29:12 c18 kernel: [ 32.082718] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.PRT4._GTF, AE_NOT_FOUND (20170531/psparse-550) Oct 9 21:29:12 c18 kernel: [ 32.114002] ata5.00: configured for UDMA/133 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103142] R600g+sb: optimizer apparently stuck in an endless loop
https://bugs.freedesktop.org/show_bug.cgi?id=103142 --- Comment #2 from Gert Wollny--- In summary, the optimizer gets stuck in an infinite loop in schedule_alu, because prepare_alu_group() does not find a proper scheduling. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] staging: ion: create one device entry per heap
On 10/05/2017 06:06 AM, Benjamin Gaignard wrote: > 2017-10-04 12:17 GMT+02:00 Mark Brown: >> On Tue, Oct 03, 2017 at 04:08:30PM -0700, Sandeep Patil wrote: >> >>> It is entirely possible and easy in android/ueventd to create those nodes >>> under "/dev/ion/". (assuming the heap 'subsystem' for these new devices >>> will >>> point to 'ion'). > > I think it is the same problem than for webcam under v4l framework. > Each time you plug a webcam you got a v4l node but android/uevent rules > the plug order doesn't have impact. > The same think will happen for ion nodes it may be even easier because > the heap will always being created in the smae order for a given product > configuration. > Relying on the heap being created in the same order seems troublesome. If for some reason it changes in the kernel we might break something in userspace. Anyway, to move this forward I think we need to see a proof of concept of using selinux to protect access to specific heaps. Thanks, Laura >> >> The reason I didn't say /dev/ion/foo initially is that if people want to >> keep the existing /dev/ion around for compatibility reasons then the >> /dev/ion name isn't available which might cause issues. Otherwise just >> dumping everything under a directory (perhaps with a different name) was >> my first thought as well. >> >>> (Also FWIW, the SELinux permissions are also possible with the current ion >>> implementation by adding rules to disallow specific ioctls instead of adding >>> permissions to access device node as this change would do) >> >> AIUI the request is to limit access to specific heaps, and obviously not >> everyone wants to deal with SELinux at all. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] staging: ion: create one device entry per heap
On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote: > Anyway, to move this forward I think we need to see a proof of concept > of using selinux to protect access to specific heaps. Aren't Unix permissions enough with separate files or am I misunderstanding what you're looking to see a proof of concept for? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu pre-reqs for stoney ACP audio support
Hi Dave, Mark, This branch against Linus' master contains the 3 pre-requisite patches for Stoney ACP audio. Mark needs these patches to apply the rest of the Stoney ACP patch set on the audio side. Please pull. Thanks! The following changes since commit 68ebe3cbe786a954481d6ded0dc83f7d551640bf: Merge tag 'nfs-for-4.14-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs (2017-10-09 10:55:37 -0700) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux linus-acp-prereq for you to fetch changes up to 1e4448648333a8fb7830a7a4b76c86e160a79b1e: drm/amdgpu Moving amdgpu asic types to a separate file (2017-10-09 17:54:24 -0400) Akshu Agrawal (1): drm/amdgpu Moving amdgpu asic types to a separate file Vijendar Mukunda (2): drm/amd/amdgpu: Added asic_type as ACP DMA driver platform data ASoC: AMD: Added asic_type as ACP DMA driver platform data drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 2 ++ drivers/gpu/drm/amd/include/amd_shared.h | 29 ++ include/drm/amd_asic_type.h | 52 sound/soc/amd/acp-pcm-dma.c | 8 ++--- sound/soc/amd/acp.h | 7 + 5 files changed, 65 insertions(+), 33 deletions(-) create mode 100644 include/drm/amd_asic_type.h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:for-linux-next-fixes 7/7] drivers/gpu/drm/i915/i915_gem_evict.c:318:3: note: in expansion of macro 'if'
tree: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes head: 72872c99b6dbc80362965cd30489c849f0663140 commit: 72872c99b6dbc80362965cd30489c849f0663140 [7/7] drm/i915: Check PIN_NONFAULT overlaps in evict_for_node config: x86_64-randconfig-x011-201741 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: git checkout 72872c99b6dbc80362965cd30489c849f0663140 # save the attached .config to linux build tree make ARCH=x86_64 All warnings (new ones prefixed by >>): In file included from include/uapi/linux/stddef.h:1:0, from include/linux/stddef.h:4, from include/uapi/linux/posix_types.h:4, from include/uapi/linux/types.h:13, from include/linux/types.h:5, from include/linux/list.h:4, from include/linux/agp_backend.h:33, from include/drm/drmP.h:35, from drivers/gpu/drm/i915/i915_gem_evict.c:29: drivers/gpu/drm/i915/i915_gem_evict.c: In function 'i915_gem_evict_for_node': drivers/gpu/drm/i915/i915_gem_evict.c:318:31: error: implicit declaration of function 'i915_vma_has_userfault' [-Werror=implicit-function-declaration] if (flags & PIN_NONFAULT && i915_vma_has_userfault(vma)) { ^ include/linux/compiler.h:156:30: note: in definition of macro '__trace_if' if (__builtin_constant_p(!!(cond)) ? !!(cond) : \ ^~~~ >> drivers/gpu/drm/i915/i915_gem_evict.c:318:3: note: in expansion of macro 'if' if (flags & PIN_NONFAULT && i915_vma_has_userfault(vma)) { ^~ cc1: some warnings being treated as errors vim +/if +318 drivers/gpu/drm/i915/i915_gem_evict.c 236 237 /** 238 * i915_gem_evict_for_vma - Evict vmas to make room for binding a new one 239 * @vm: address space to evict from 240 * @target: range (and color) to evict for 241 * @flags: additional flags to control the eviction algorithm 242 * 243 * This function will try to evict vmas that overlap the target node. 244 * 245 * To clarify: This is for freeing up virtual address space, not for freeing 246 * memory in e.g. the shrinker. 247 */ 248 int i915_gem_evict_for_node(struct i915_address_space *vm, 249 struct drm_mm_node *target, 250 unsigned int flags) 251 { 252 LIST_HEAD(eviction_list); 253 struct drm_mm_node *node; 254 u64 start = target->start; 255 u64 end = start + target->size; 256 struct i915_vma *vma, *next; 257 bool check_color; 258 int ret = 0; 259 260 lockdep_assert_held(>i915->drm.struct_mutex); 261 GEM_BUG_ON(!IS_ALIGNED(start, I915_GTT_PAGE_SIZE)); 262 GEM_BUG_ON(!IS_ALIGNED(end, I915_GTT_PAGE_SIZE)); 263 264 trace_i915_gem_evict_node(vm, target, flags); 265 266 /* Retire before we search the active list. Although we have 267 * reasonable accuracy in our retirement lists, we may have 268 * a stray pin (preventing eviction) that can only be resolved by 269 * retiring. 270 */ 271 if (!(flags & PIN_NONBLOCK)) 272 i915_gem_retire_requests(vm->i915); 273 274 check_color = vm->mm.color_adjust; 275 if (check_color) { 276 /* Expand search to cover neighbouring guard pages (or lack!) */ 277 if (start) 278 start -= I915_GTT_PAGE_SIZE; 279 280 /* Always look at the page afterwards to avoid the end-of-GTT */ 281 end += I915_GTT_PAGE_SIZE; 282 } 283 GEM_BUG_ON(start >= end); 284 285 drm_mm_for_each_node_in_range(node, >mm, start, end) { 286 /* If we find any non-objects (!vma), we cannot evict them */ 287 if (node->color == I915_COLOR_UNEVICTABLE) { 288 ret = -ENOSPC; 289 break; 290 } 291 292 GEM_BUG_ON(!node->allocated); 293 vma = container_of(node, typeof(*vma), node); 294 295 /* If we are using coloring to insert guard pages between 296 * different cache domains within the address space, we have 297 * to check whether the objects on either side of our range 298 * abutt and conflict. If they are in conflict, then we evict 299 * those as well to make room for our guard pages. 300 */ 301 if (check_color) { 302 if (node->start + node->size ==
[Bug 102800] DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer
https://bugs.freedesktop.org/show_bug.cgi?id=102800 --- Comment #7 from higu...@gmx.net --- I tried to downgrade the kernel to 4.11, 4.10 and 4.9 and i failed to enable DRI_PRIME on the dedicated card, always with the same error. I then tried to downgrade the mesa and libdrm to the distro original version and also, failed to enabled the card... So yes, the card worked in the past with DynPwr, but now i'm unable to enable it... Maybe some other update, firmware, whatever is also messing this. I do recall being able to boot one older kernel and have the card working, but booting with the more recent, it failed... all this around june I will try to boot from a liveCD, to try to get it working again and try to understand what else is causing this. Anyway, using runpm=0 works and the problems seems to be always with the kernel/atombios being unable to re-enable the card after shut it down -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:for-linux-next-fixes 7/7] drivers/gpu/drm/i915/i915_gem_evict.c:318:31: error: implicit declaration of function 'i915_vma_has_userfault'
tree: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes head: 72872c99b6dbc80362965cd30489c849f0663140 commit: 72872c99b6dbc80362965cd30489c849f0663140 [7/7] drm/i915: Check PIN_NONFAULT overlaps in evict_for_node config: x86_64-randconfig-x018-201741 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: git checkout 72872c99b6dbc80362965cd30489c849f0663140 # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/gpu/drm/i915/i915_gem_evict.c: In function 'i915_gem_evict_for_node': >> drivers/gpu/drm/i915/i915_gem_evict.c:318:31: error: implicit declaration of >> function 'i915_vma_has_userfault' [-Werror=implicit-function-declaration] if (flags & PIN_NONFAULT && i915_vma_has_userfault(vma)) { ^~ Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:variable_test_bit Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD Cyclomatic Complexity 1 include/linux/list.h:__list_add_valid Cyclomatic Complexity 1 include/linux/list.h:__list_del_entry_valid Cyclomatic Complexity 2 include/linux/list.h:__list_add Cyclomatic Complexity 1 include/linux/list.h:list_add Cyclomatic Complexity 1 include/linux/list.h:__list_del Cyclomatic Complexity 2 include/linux/list.h:__list_del_entry Cyclomatic Complexity 1 include/linux/list.h:list_del Cyclomatic Complexity 1 include/linux/list.h:list_move Cyclomatic Complexity 1 include/linux/list.h:list_empty Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR Cyclomatic Complexity 1 include/linux/err.h:IS_ERR Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:atomic_read Cyclomatic Complexity 1 include/linux/lockdep.h:lock_is_held Cyclomatic Complexity 1 include/linux/jump_label.h:static_key_count Cyclomatic Complexity 2 include/linux/jump_label.h:static_key_false Cyclomatic Complexity 2 include/linux/cpumask.h:cpumask_check Cyclomatic Complexity 1 include/linux/cpumask.h:cpumask_test_cpu Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_add Cyclomatic Complexity 1 arch/x86/include/asm/preempt.h:__preempt_count_dec_and_test Cyclomatic Complexity 1 include/linux/rcupdate.h:rcu_read_lock_sched_notrace Cyclomatic Complexity 2 include/linux/rcupdate.h:rcu_read_unlock_sched_notrace Cyclomatic Complexity 2 include/linux/kref.h:kref_put Cyclomatic Complexity 1 include/drm/drm_mm.h:drm_mm_node_allocated Cyclomatic Complexity 1 include/drm/drm_gem.h:__drm_gem_object_put Cyclomatic Complexity 1 include/drm/drm_gem.h:__drm_gem_object_unreference Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_gem_request.h:i915_gem_active_isset Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_gem_object.h:i915_gem_object_put Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_vma.h:i915_vma_get_active Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_vma.h:i915_vma_is_active Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_vma.h:i915_vma_pin_count Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_vma.h:i915_vma_is_pinned Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_vma.h:__i915_vma_pin Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_vma.h:__i915_vma_unpin Cyclomatic Complexity 1 drivers/gpu/drm/i915/i915_vma.h:i915_vma_unpin Cyclomatic Complexity 6 drivers/gpu/drm/i915/i915_trace.h:trace_i915_gem_evict Cyclomatic Complexity 6 drivers/gpu/drm/i915/i915_trace.h:trace_i915_gem_evict_vm Cyclomatic Complexity 6 drivers/gpu/drm/i915/i915_trace.h:trace_i915_gem_evict_node Cyclomatic Complexity 2 drivers/gpu/drm/i915/i915_drv.h:i915_gem_drain_freed_objects Cyclomatic Complexity 4 drivers/gpu/drm/i915/i915_gem_evict.c:ggtt_is_idle Cyclomatic Complexity 1 drivers/gpu/drm/i915/selftests/i915_gem_evict.c:mock_color_adjust Cyclomatic Complexity 4 drivers/gpu/drm/i915/i915_gem_evict.c:mark_free Cyclomatic Complexity 3 drivers/gpu/drm/i915/i915_gem_evict.c:ggtt_flush Cyclomatic Complexity 9 drivers/gpu/drm/i915/selftests/i915_gem_evict.c:populate_ggtt Cyclomatic Complexity 9 drivers/gpu/drm/i915/selftests/i915_gem_evict.c:cleanup_objects Cyclomatic Complexity 5 drivers/gpu/drm/i915/selftests/i915_gem_evict.c:igt_overcommit Cyclomatic Complexity 4 drivers/gpu/drm/i915/selftests/i915_gem_evict.c:unpin_ggtt Cyclomatic Complexity 34 drivers/gpu/drm/i915/i915_gem_evict.c:i915_gem_evict_something Cyclomatic Complexity 4 drivers/gpu/drm/i915/selftests/i915_gem_evict.c:igt_evict_something Cyclomatic Complexity 29 drivers/gpu/drm/i915/i915_gem_evict.c:i915_gem_evict_for_node Cyclomatic Complexity 7 drivers/gpu/drm/i915/selftests/i915_gem_evict.c:igt_evict_for_cache_color Cyclomatic Complexity 4
Re: [PATCH v5 2/2] staging: ion: create one device entry per heap
On 10/09/2017 03:08 PM, Mark Brown wrote: > On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote: > >> Anyway, to move this forward I think we need to see a proof of concept >> of using selinux to protect access to specific heaps. > > Aren't Unix permissions enough with separate files or am I > misunderstanding what you're looking to see a proof of concept for? > The goal is to be able to restrict heap access to certain services and selinux groups on Android so straight unix permissions aren't sufficient. Thanks, Laura ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Dynamically adding a PCI subfunction
Am 09.10.2017 um 16:41 schrieb Ilia Mirkin: Hello, As a bit of background, all NVIDIA GPUs since GT215 have an audio subfunction for HDMI(/DP) audio to be sent to the sink. This generally works. However some, especially laptop, devices come up with that function disabled. We have a quirk to enable it when coming back from runpm, but that doesn't help the init case. Basically we have to write a bit to the PCI config space: https://github.com/torvalds/linux/blob/v4.12/drivers/gpu/drm/nouveau/nouveau_drm.c#L783 (MMIO 0x88000 is an alias for the PCI config space) This works for runtime pm resume, since the device was originally there and we just have to make sure the underlying device agrees with it, but when it's missing on boot, we have to convince linux that it exists, bind a driver, etc. What's the best way of going about doing that? Sounds similar to my work about resizing BARs. I would just try to enable the device and then trigger a rescan of the BUS where it is attached (similar to echo 1 > /sys/bus/pci/devices/$pci_id_of_your_bus/rescan). There is certainly a function in the PCI subsystem you just need to call for that. Regards, Christian. Thanks, -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Dynamically adding a PCI subfunction
On Mon, Oct 9, 2017 at 11:45 AM, Christian Königwrote: > Am 09.10.2017 um 16:41 schrieb Ilia Mirkin: >> >> Hello, >> >> As a bit of background, all NVIDIA GPUs since GT215 have an audio >> subfunction for HDMI(/DP) audio to be sent to the sink. This generally >> works. >> >> However some, especially laptop, devices come up with that function >> disabled. We have a quirk to enable it when coming back from runpm, >> but that doesn't help the init case. Basically we have to write a bit >> to the PCI config space: >> >> >> https://github.com/torvalds/linux/blob/v4.12/drivers/gpu/drm/nouveau/nouveau_drm.c#L783 >> >> (MMIO 0x88000 is an alias for the PCI config space) >> >> This works for runtime pm resume, since the device was originally >> there and we just have to make sure the underlying device agrees with >> it, but when it's missing on boot, we have to convince linux that it >> exists, bind a driver, etc. >> >> What's the best way of going about doing that? > > > Sounds similar to my work about resizing BARs. > > I would just try to enable the device and then trigger a rescan of the BUS > where it is attached (similar to echo 1 > > /sys/bus/pci/devices/$pci_id_of_your_bus/rescan). > > There is certainly a function in the PCI subsystem you just need to call for > that. I'm not exactly familiar with the pci subsystem. I know that hotplug is a thing, at least in theory. I figured it'd be something related to that, since this is in essence a random device appearing on the bus after the initial scan. Is a bus rescan safe on a fully initialized system? Either way, some specific functions to call or look at would be great. Cheers, -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()
Quoting Ville Syrjälä (2017-10-09 17:18:17) > On Mon, Sep 25, 2017 at 08:19:12PM +0100, Chris Wilson wrote: > > Quoting ville.syrj...@linux.intel.com (2016-04-01 19:48:50) > > > From: Ville Syrjälä> > > > > > Eliminate the duplicate code for pipe timing readout in > > > intel_crtc_mode_get() by using the functions we use for the normal state > > > readout. > > > > > > v2: Store dotclock in adjusted_mode instead of the final mode > > > > > > Cc: dri-devel@lists.freedesktop.org > > > Cc: Rob Kramer > > > Cc: Daniel Vetter > > > Signed-off-by: Ville Syrjälä > > Reviewed-by: Chris Wilson > > Thanks for the review. Patches pushed to dinq. > > > > > Fixes a pipe-state warn for me, > > Tested-by: Chris Wilson > > However, now that I look at the code again I'm not 100% sure why this > fixed anything. The readout still seems to fail at fully populating the > mode flags. I'll post a more thorough solution that simply calls the > normal state readout hooks for the crtc and encoder... The first patch fixed up the implied A,B transcoder mixup. I just tested both patches together. Do you want me to double check if it was just the first patch that silenced the warnings? I'm just happy to have a clean boot! -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/atomic: Unref duplicated drm_atomic_state in drm_atomic_helper_resume()
Kmemleak reported memory leak after suspend and resume: unreferenced object 0xffc0e31d8880 (size 128): comm "bash", pid 181, jiffies 4294763583 (age 24.694s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 20 a2 eb c0 ff ff ff . .. 01 00 00 00 00 00 00 00 80 87 1d e3 c0 ff ff ff backtrace: [] __save_stack_trace+0x48/0x6c [] create_object+0x138/0x254 [] kmemleak_alloc+0x58/0x8c [] kmem_cache_alloc_trace+0x188/0x254 [] drm_atomic_state_alloc+0x3c/0x88 [] drm_atomic_helper_duplicate_state+0x28/0x158 [] drm_atomic_helper_suspend+0x5c/0xf0 Problem here is that we are duplicating the drm_atomic_state in drm_atomic_helper_suspend(), but not unreference it in the resume path. Fixes: 1494276000db ("drm/atomic-helper: Implement subsystem-level suspend/resume") Signed-off-by: Jeffy Chen--- Changes in v2: Unref duplicated drm_atomic_state in drm_atomic_helper_resume() instead of specific drivers. drivers/gpu/drm/drm_atomic_helper.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 01c34bc5b5b0..4a262380c631 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -3052,6 +3052,7 @@ int drm_atomic_helper_resume(struct drm_device *dev, drm_modeset_backoff(); } + drm_atomic_state_put(state); drm_modeset_drop_locks(); drm_modeset_acquire_fini(); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/rockchip: Fix memory leak in rockchip_drm_sys_resume()
Hi Sean, On 09/28/2017 11:16 AM, jeffy wrote: Hi Sean, On 09/28/2017 04:27 AM, Sean Paul wrote: >@@ -299,6 +300,7 @@ static int rockchip_drm_sys_resume(struct device *dev) > > priv = drm->dev_private; > drm_atomic_helper_resume(drm, priv->state); >+drm_atomic_state_put(priv->state); Won't this be freed for you eventually in commit_tail()? i think the drm_atomic_state_put in commit_tail is paired to the drm_atomic_state_get in drm_atomic_helper_commit. and the kmemleak shows(after a few suspend/resume): unreferenced object 0xffc0ce0fa400 (size 256): ... backtrace: [] __save_stack_trace+0x48/0x6c [] create_object+0x138/0x254 [] kmemleak_alloc+0x58/0x8c [] __kmalloc+0x1d4/0x2a0 [] usb_alloc_urb+0x30/0x60 [] alloc_ctrl_urb+0x38/0x120 [btusb] [] btusb_send_frame+0x64/0xf8 [btusb] oops, the log is wrong... it should be: unreferenced object 0xffc0c75fe600 (size 256): comm "bash", pid 168, jiffies 4294748032 (age 557.932s) hex dump (first 32 bytes): e0 4a 02 ce c0 ff ff ff 00 98 f2 c8 c0 ff ff ff .J.. 00 98 f2 c8 c0 ff ff ff 00 45 9f cb c0 ff ff ff .E.. backtrace: [] kmemleak_alloc+0x58/0x8c [] __kmalloc+0x1dc/0x2d4 [] drm_atomic_state_init+0xb8/0x114 [] drm_atomic_state_alloc+0x70/0xa4 [] drm_atomic_helper_duplicate_state+0x94/0x210 [] drm_atomic_helper_suspend+0xb4/0x160 [] rockchip_drm_sys_suspend+0x5c/0xa0 [] platform_pm_suspend+0x58/0x74 [] dpm_run_callback+0x13c/0x2f0 [] __device_suspend+0x28c/0x3fc [] dpm_suspend+0x1cc/0x50c [] dpm_suspend_start+0x8c/0xa4 [] suspend_devices_and_enter+0x12c/0xd84 [] pm_suspend+0xa38/0xb98 [] state_store+0xe0/0x108 [] kobj_attr_store+0x48/0x58 since it's allocated in the drm_atomic_helper_suspend(), maybe it would make more sense to unref it in drm_atomic_helper_resume(), i'll send a v2 patch for it :) checking the current code, i saw only i915/intel_display.c has this drm_atomic_state_put for the state allocated by drm_atomic_helper_suspend(), there're many drivers missing that(or maybe they free it in some other way?) Sean ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fix typo in drm_gem_get_pages() comment
On Wed, 04 Oct 2017, Daniel Vetterwrote: > On Tue, Oct 03, 2017 at 09:38:10AM -0600, Jordan Crouse wrote: >> I spent an embarrassingly long time looking for drm_gem_init_object() >> before I realized I was actually looking for drm_gem_object_init(). >> Fix the typo to keep other poor developers from suffering the same >> fate. >> >> Signed-off-by: Jordan Crouse > > Yeah would be nice if sphinx would complain a bit louder about symlinks it > can't find ... But if it did, we'd never have been able to do a gradual conversion to it! BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 09/11] drm/sun4i: hdmi: Add support for A31's HDMI controller
The HDMI controller found in the A31 SoCs is slightly different from the one already supported, which is found in the A10s: - Need different initial values for the PLL related registers - Different behavior of the DDC and TMDS clocks - Different register layout for the DDC portion - Separate DDC parent clock This patch adds support for it. Signed-off-by: Chen-Yu TsaiAcked-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_hdmi.h | 3 ++ drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 58 ++ 2 files changed, 61 insertions(+) diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h b/drivers/gpu/drm/sun4i/sun4i_hdmi.h index ee42ae7e5a21..9b97da39927e 100644 --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h @@ -59,10 +59,13 @@ #define SUN4I_HDMI_PAD_CTRL0_TXEN BIT(23) #define SUN4I_HDMI_PAD_CTRL1_REG 0x204 +#define SUN4I_HDMI_PAD_CTRL1_UNKNOWN BIT(24) /* set on A31 */ #define SUN4I_HDMI_PAD_CTRL1_AMP_OPT BIT(23) #define SUN4I_HDMI_PAD_CTRL1_AMPCK_OPT BIT(22) #define SUN4I_HDMI_PAD_CTRL1_EMP_OPT BIT(20) #define SUN4I_HDMI_PAD_CTRL1_EMPCK_OPT BIT(19) +#define SUN4I_HDMI_PAD_CTRL1_PWSCK BIT(18) +#define SUN4I_HDMI_PAD_CTRL1_PWSDT BIT(17) #define SUN4I_HDMI_PAD_CTRL1_REG_DEN BIT(15) #define SUN4I_HDMI_PAD_CTRL1_REG_DENCK BIT(14) #define SUN4I_HDMI_PAD_CTRL1_REG_EMP(n)(((n) & 7) << 10) diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c index 114cbe60b3e6..027b5608dbe6 100644 --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c @@ -324,6 +324,63 @@ static const struct sun4i_hdmi_variant sun5i_variant = { .ddc_fifo_has_dir = true, }; +static const struct sun4i_hdmi_variant sun6i_variant = { + .has_ddc_parent_clk = true, + .has_reset_control = true, + .pad_ctrl0_init_val = 0xff | + SUN4I_HDMI_PAD_CTRL0_TXEN | + SUN4I_HDMI_PAD_CTRL0_CKEN | + SUN4I_HDMI_PAD_CTRL0_PWENG | + SUN4I_HDMI_PAD_CTRL0_PWEND | + SUN4I_HDMI_PAD_CTRL0_PWENC | + SUN4I_HDMI_PAD_CTRL0_LDODEN | + SUN4I_HDMI_PAD_CTRL0_LDOCEN, + .pad_ctrl1_init_val = SUN4I_HDMI_PAD_CTRL1_REG_AMP(6) | + SUN4I_HDMI_PAD_CTRL1_REG_EMP(4) | + SUN4I_HDMI_PAD_CTRL1_REG_DENCK | + SUN4I_HDMI_PAD_CTRL1_REG_DEN | + SUN4I_HDMI_PAD_CTRL1_EMPCK_OPT | + SUN4I_HDMI_PAD_CTRL1_EMP_OPT | + SUN4I_HDMI_PAD_CTRL1_PWSDT | + SUN4I_HDMI_PAD_CTRL1_PWSCK | + SUN4I_HDMI_PAD_CTRL1_AMPCK_OPT | + SUN4I_HDMI_PAD_CTRL1_AMP_OPT | + SUN4I_HDMI_PAD_CTRL1_UNKNOWN, + .pll_ctrl_init_val = SUN4I_HDMI_PLL_CTRL_VCO_S(8) | + SUN4I_HDMI_PLL_CTRL_CS(3) | + SUN4I_HDMI_PLL_CTRL_CP_S(10) | + SUN4I_HDMI_PLL_CTRL_S(4) | + SUN4I_HDMI_PLL_CTRL_VCO_GAIN(4) | + SUN4I_HDMI_PLL_CTRL_SDIV2 | + SUN4I_HDMI_PLL_CTRL_LDO2_EN | + SUN4I_HDMI_PLL_CTRL_LDO1_EN | + SUN4I_HDMI_PLL_CTRL_HV_IS_33 | + SUN4I_HDMI_PLL_CTRL_PLL_EN, + + .ddc_clk_reg= REG_FIELD(SUN6I_HDMI_DDC_CLK_REG, 0, 6), + .ddc_clk_pre_divider= 1, + .ddc_clk_m_offset = 2, + + .tmds_clk_div_offset= 1, + + .field_ddc_en = REG_FIELD(SUN6I_HDMI_DDC_CTRL_REG, 0, 0), + .field_ddc_start= REG_FIELD(SUN6I_HDMI_DDC_CTRL_REG, 27, 27), + .field_ddc_reset= REG_FIELD(SUN6I_HDMI_DDC_CTRL_REG, 31, 31), + .field_ddc_addr_reg = REG_FIELD(SUN6I_HDMI_DDC_ADDR_REG, 1, 31), + .field_ddc_slave_addr = REG_FIELD(SUN6I_HDMI_DDC_ADDR_REG, 1, 7), + .field_ddc_int_status = REG_FIELD(SUN6I_HDMI_DDC_INT_STATUS_REG, 0, 8), + .field_ddc_fifo_clear = REG_FIELD(SUN6I_HDMI_DDC_FIFO_CTRL_REG, 18, 18), + .field_ddc_fifo_rx_thres = REG_FIELD(SUN6I_HDMI_DDC_FIFO_CTRL_REG, 4, 7), + .field_ddc_fifo_tx_thres = REG_FIELD(SUN6I_HDMI_DDC_FIFO_CTRL_REG, 0, 3), + .field_ddc_byte_count = REG_FIELD(SUN6I_HDMI_DDC_CMD_REG, 16, 25), + .field_ddc_cmd = REG_FIELD(SUN6I_HDMI_DDC_CMD_REG, 0, 2), + .field_ddc_sda_en =
[PATCH v4 01/11] drm/sun4i: tcon: Add variant callback for TCON output muxing
Different SoCs have different muxing options and values for the TCON outputs. Instead of stuffing every possibility in sun4i_tcon_set_mux(), add a callback pointer to sun4i_tcon_quirks that each TCON variant can use to provide muxing support. The current muxing options in sun4i_tcon_set_mux() for sun5i-a13 are moved to a new sun5i-specific callback function. Since the new callback replaces what the .has_unknown_mux field in tcon quirks did in the past, the field is removed. Signed-off-by: Chen-Yu Tsai--- drivers/gpu/drm/sun4i/sun4i_tcon.c | 44 +++--- drivers/gpu/drm/sun4i/sun4i_tcon.h | 6 +- 2 files changed, 32 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c index e853dfe51389..75124043d655 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -14,9 +14,12 @@ #include #include #include +#include #include #include +#include + #include #include #include @@ -112,23 +115,13 @@ EXPORT_SYMBOL(sun4i_tcon_enable_vblank); void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel, struct drm_encoder *encoder) { - u32 val; - - if (!tcon->quirks->has_unknown_mux) - return; + int ret = -ENOTSUPP; - if (channel != 1) - return; - - if (encoder->encoder_type == DRM_MODE_ENCODER_TVDAC) - val = 1; - else - val = 0; + if (tcon->quirks->set_mux) + ret = tcon->quirks->set_mux(tcon, encoder); - /* -* FIXME: Undocumented bits -*/ - regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, val); + DRM_DEBUG_DRIVER("Muxing encoder %s to CRTC %s: %d\n", +encoder->name, encoder->crtc->name, ret); } EXPORT_SYMBOL(sun4i_tcon_set_mux); @@ -767,9 +760,26 @@ static int sun4i_tcon_remove(struct platform_device *pdev) return 0; } +/* platform specific TCON muxing callbacks */ +static int sun5i_a13_tcon_set_mux(struct sun4i_tcon *tcon, + struct drm_encoder *encoder) +{ + u32 val; + + if (encoder->encoder_type == DRM_MODE_ENCODER_TVDAC) + val = 1; + else + val = 0; + + /* +* FIXME: Undocumented bits +*/ + return regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, val); +} + static const struct sun4i_tcon_quirks sun5i_a13_quirks = { - .has_unknown_mux = true, - .has_channel_1 = true, + .has_channel_1 = true, + .set_mux= sun5i_a13_tcon_set_mux, }; static const struct sun4i_tcon_quirks sun6i_a31_quirks = { diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h b/drivers/gpu/drm/sun4i/sun4i_tcon.h index 5a219d1ccc26..d9e1357cc8ae 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h @@ -145,10 +145,14 @@ #define SUN4I_TCON_MAX_CHANNELS2 +struct sun4i_tcon; + struct sun4i_tcon_quirks { - boolhas_unknown_mux; /* sun5i has undocumented mux */ boolhas_channel_1; /* a33 does not have channel 1 */ boolneeds_de_be_mux; /* sun6i needs mux to select backend */ + + /* callback to handle tcon muxing options */ + int (*set_mux)(struct sun4i_tcon *, struct drm_encoder *); }; struct sun4i_tcon { -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 05/11] drm/sun4i: hdmi: Allow using second PLL as TMDS clk parent
On SoCs with two display pipelines, it is possible that the two pipelines are active at the same time, with potentially incompatible dot clocks. Let the HDMI encoder's TMDS clock go through all of its parents when calculating possible clock rates. This allows usage of the second video PLL as its parent. Signed-off-by: Chen-Yu TsaiAcked-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 53 - 1 file changed, 29 insertions(+), 24 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c index 5cf2527bffc8..e8d4c311b80d 100644 --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c @@ -67,11 +67,11 @@ static unsigned long sun4i_tmds_calc_divider(unsigned long rate, static int sun4i_tmds_determine_rate(struct clk_hw *hw, struct clk_rate_request *req) { - struct clk_hw *parent; + struct clk_hw *parent = NULL; unsigned long best_parent = 0; unsigned long rate = req->rate; int best_div = 1, best_half = 1; - int i, j; + int i, j, p; /* * We only consider PLL3, since the TCON is very likely to be @@ -79,32 +79,37 @@ static int sun4i_tmds_determine_rate(struct clk_hw *hw, * clock, so we should not need to do anything. */ - parent = clk_hw_get_parent_by_index(hw, 0); - if (!parent) - return -EINVAL; - - for (i = 1; i < 3; i++) { - for (j = 1; j < 16; j++) { - unsigned long ideal = rate * i * j; - unsigned long rounded; - - rounded = clk_hw_round_rate(parent, ideal); - - if (rounded == ideal) { - best_parent = rounded; - best_half = i; - best_div = j; - goto out; - } - - if (abs(rate - rounded / i) < - abs(rate - best_parent / best_div)) { - best_parent = rounded; - best_div = i; + for (p = 0; p < clk_hw_get_num_parents(hw); p++) { + parent = clk_hw_get_parent_by_index(hw, p); + if (!parent) + continue; + + for (i = 1; i < 3; i++) { + for (j = 1; j < 16; j++) { + unsigned long ideal = rate * i * j; + unsigned long rounded; + + rounded = clk_hw_round_rate(parent, ideal); + + if (rounded == ideal) { + best_parent = rounded; + best_half = i; + best_div = j; + goto out; + } + + if (abs(rate - rounded / i) < + abs(rate - best_parent / best_div)) { + best_parent = rounded; + best_div = i; + } } } } + if (!parent) + return -EINVAL; + out: req->rate = best_parent / best_half / best_div; req->best_parent_rate = best_parent; -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 11/11] ARM: dts: sun6i: Enable HDMI support on some A31/A31s devices
All the A31/A31s devices I own have some kind of HDMI connector wired to the dedicated HDMI pins on the SoC: - A31 Hummingbird (standard HDMI connector, display already enabled) - Sinlinx SinA31s (standard HDMI connector) - MSI Primo81 tablet (micro HDMI connector) Enable the display pipeline (if needed) and HDMI output for them. Signed-off-by: Chen-Yu Tsai--- arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 21 + arch/arm/boot/dts/sun6i-a31s-primo81.dts| 25 + arch/arm/boot/dts/sun6i-a31s-sina31s.dts| 25 + 3 files changed, 71 insertions(+) diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts index 9ecb5f0b3f83..19e382a11297 100644 --- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts +++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts @@ -62,6 +62,17 @@ stdout-path = "serial0:115200n8"; }; + hdmi-connector { + compatible = "hdmi-connector"; + type = "a"; + + port { + hdmi_con_in: endpoint { + remote-endpoint = <_out_con>; + }; + }; + }; + vga-connector { compatible = "vga-connector"; @@ -162,6 +173,16 @@ }; }; + { + status = "okay"; +}; + +_out { + hdmi_out_con: endpoint { + remote-endpoint = <_con_in>; + }; +}; + { pinctrl-names = "default"; pinctrl-0 = <_pins_a>; diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts b/arch/arm/boot/dts/sun6i-a31s-primo81.dts index 4c10123509c4..0cdb38ab3377 100644 --- a/arch/arm/boot/dts/sun6i-a31s-primo81.dts +++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts @@ -52,17 +52,42 @@ / { model = "MSI Primo81 tablet"; compatible = "msi,primo81", "allwinner,sun6i-a31s"; + + hdmi-connector { + compatible = "hdmi-connector"; + type = "c"; + + port { + hdmi_con_in: endpoint { + remote-endpoint = <_out_con>; + }; + }; + }; }; { cpu-supply = <_dcdc3>; }; + { + status = "okay"; +}; + { /* rtl8188etv wifi is connected here */ status = "okay"; }; + { + status = "okay"; +}; + +_out { + hdmi_out_con: endpoint { + remote-endpoint = <_con_in>; + }; +}; + { /* pull-ups and device VDDIO use AXP221 DLDO3 */ pinctrl-names = "default"; diff --git a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts index b3d98222bd81..298476485bb4 100644 --- a/arch/arm/boot/dts/sun6i-a31s-sina31s.dts +++ b/arch/arm/boot/dts/sun6i-a31s-sina31s.dts @@ -53,6 +53,17 @@ stdout-path = "serial0:115200n8"; }; + hdmi-connector { + compatible = "hdmi-connector"; + type = "a"; + + port { + hdmi_con_in: endpoint { + remote-endpoint = <_out_con>; + }; + }; + }; + leds { compatible = "gpio-leds"; pinctrl-names = "default"; @@ -90,6 +101,10 @@ status = "okay"; }; + { + status = "okay"; +}; + { /* USB 2.0 4 port hub IC */ status = "okay"; @@ -112,6 +127,16 @@ }; }; + { + status = "okay"; +}; + +_out { + hdmi_out_con: endpoint { + remote-endpoint = <_con_in>; + }; +}; + { pinctrl-names = "default"; pinctrl-0 = <_pins_a>; -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 10/11] ARM: dts: sun6i: Add device node for HDMI controller
Now that we support the HDMI controller on the A31 SoC, we can add it to the device tree. This adds a device node for the HDMI controller, and the of_graph nodes connecting it to the 2 TCONs. Signed-off-by: Chen-Yu Tsai--- arch/arm/boot/dts/sun6i-a31.dtsi | 55 1 file changed, 55 insertions(+) diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi index 93209cda28db..48b2382a18a9 100644 --- a/arch/arm/boot/dts/sun6i-a31.dtsi +++ b/arch/arm/boot/dts/sun6i-a31.dtsi @@ -289,6 +289,12 @@ #address-cells = <1>; #size-cells = <0>; reg = <1>; + + tcon0_out_hdmi: endpoint@1 { + reg = <1>; + remote-endpoint = <_in_tcon0>; + allwinner,tcon-channel = <1>; + }; }; }; }; @@ -331,6 +337,12 @@ #address-cells = <1>; #size-cells = <0>; reg = <1>; + + tcon1_out_hdmi: endpoint@1 { + reg = <1>; + remote-endpoint = <_in_tcon1>; + allwinner,tcon-channel = <1>; + }; }; }; }; @@ -411,6 +423,49 @@ #size-cells = <0>; }; + hdmi: hdmi@01c16000 { + compatible = "allwinner,sun6i-a31-hdmi"; + reg = <0x01c16000 0x1000>; + interrupts = ; + clocks = < CLK_AHB1_HDMI>, < CLK_HDMI>, +< CLK_HDMI_DDC>, +< CLK_PLL_VIDEO0_2X>, +< CLK_PLL_VIDEO1_2X>; + clock-names = "ahb", "mod", "ddc", "pll-0", "pll-1"; + resets = < RST_AHB1_HDMI>; + reset-names = "ahb"; + dma-names = "ddc-tx", "ddc-rx", "audio-tx"; + dmas = < 13>, < 13>, < 14>; + status = "disabled"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + hdmi_in: port@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + + hdmi_in_tcon0: endpoint@0 { + reg = <0>; + remote-endpoint = <_out_hdmi>; + }; + + hdmi_in_tcon1: endpoint@1 { + reg = <1>; + remote-endpoint = <_out_hdmi>; + }; + }; + + hdmi_out: port@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + }; + }; + }; + usb_otg: usb@01c19000 { compatible = "allwinner,sun6i-a31-musb"; reg = <0x01c19000 0x0400>; -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 04/11] drm/sun4i: hdmi: create a regmap for later use
The HDMI driver is written with readl/writel I/O to the registers. However, to support the A31 variant, which has a different layout for the DDC registers, it was recommended to use regfields to have a cleaner implementation. To use regfields, we need to create an underlying regmap. This patch only adds the regmap. It does not convert the existing driver accesses to use regmap. Signed-off-by: Chen-Yu TsaiAcked-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_hdmi.h | 1 + drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 15 +++ 2 files changed, 16 insertions(+) diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h b/drivers/gpu/drm/sun4i/sun4i_hdmi.h index a1f8cba251a2..aef157d3b659 100644 --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h @@ -163,6 +163,7 @@ struct sun4i_hdmi { struct device *dev; void __iomem*base; + struct regmap *regmap; /* Parent clocks */ struct clk *bus_clk; diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c index 3cf1a6932fac..5ab811cda00e 100644 --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c @@ -22,6 +22,7 @@ #include #include #include +#include #include "sun4i_backend.h" #include "sun4i_crtc.h" @@ -267,6 +268,13 @@ static const struct cec_pin_ops sun4i_hdmi_cec_pin_ops = { }; #endif +static const struct regmap_config sun4i_hdmi_regmap_config = { + .reg_bits = 32, + .val_bits = 32, + .reg_stride = 4, + .max_register = 0x580, +}; + static int sun4i_hdmi_bind(struct device *dev, struct device *master, void *data) { @@ -321,6 +329,13 @@ static int sun4i_hdmi_bind(struct device *dev, struct device *master, goto err_disable_mod_clk; } + hdmi->regmap = devm_regmap_init_mmio(dev, hdmi->base, +_hdmi_regmap_config); + if (IS_ERR(hdmi->regmap)) { + dev_err(dev, "Couldn't create HDMI encoder regmap\n"); + return PTR_ERR(hdmi->regmap); + } + ret = sun4i_tmds_create(hdmi); if (ret) { dev_err(dev, "Couldn't create the TMDS clock\n"); -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 07/11] drm/sun4i: hdmi: Add support for controller hardware variants
The HDMI controller found in earlier Allwinner SoCs have slight differences between the A10, A10s, and the A31: - Need different initial values for the PLL related registers - Different behavior of the DDC and TMDS clocks - Different register layout for the DDC portion - Separate DDC parent clock on the A31 - Explicit reset control For the A31, the HDMI TMDS clock has a different value offset for the divider. The HDMI DDC block is different from the one in the other SoCs. As far as the DDC clock goes, it has no pre-divider, as it is clocked from a slower parent clock, not the TMDS clock. The divider offset from the register value is different. And the clock control register is at a different offset. A new variant data structure is created to store pointers to the above functions, structures, and the different initial values. Another flag notates whether there is a separate DDC parent clock. If not, the TMDS clock is passed to the DDC clock create function, as before. Regmap fields are used to deal with the different register layout of the DDC block. Signed-off-by: Chen-Yu TsaiAcked-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_hdmi.h | 72 + drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 38 +++-- drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 112 +++--- drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 227 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 17 ++- 5 files changed, 369 insertions(+), 97 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h b/drivers/gpu/drm/sun4i/sun4i_hdmi.h index aef157d3b659..3057e31219f6 100644 --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h @@ -14,6 +14,7 @@ #include #include +#include #include @@ -157,6 +158,55 @@ enum sun4i_hdmi_pkt_type { SUN4I_HDMI_PKT_END = 15, }; +struct sun4i_hdmi_variant { + bool has_ddc_parent_clk; + bool has_reset_control; + + u32 pad_ctrl0_init_val; + u32 pad_ctrl1_init_val; + u32 pll_ctrl_init_val; + + struct reg_field ddc_clk_reg; + u8 ddc_clk_pre_divider; + u8 ddc_clk_m_offset; + + u8 tmds_clk_div_offset; + + /* Register fields for I2C adapter */ + struct reg_fieldfield_ddc_en; + struct reg_fieldfield_ddc_start; + struct reg_fieldfield_ddc_reset; + struct reg_fieldfield_ddc_addr_reg; + struct reg_fieldfield_ddc_slave_addr; + struct reg_fieldfield_ddc_int_mask; + struct reg_fieldfield_ddc_int_status; + struct reg_fieldfield_ddc_fifo_clear; + struct reg_fieldfield_ddc_fifo_rx_thres; + struct reg_fieldfield_ddc_fifo_tx_thres; + struct reg_fieldfield_ddc_byte_count; + struct reg_fieldfield_ddc_cmd; + struct reg_fieldfield_ddc_sda_en; + struct reg_fieldfield_ddc_sck_en; + + /* DDC FIFO register offset */ + u32 ddc_fifo_reg; + + /* +* DDC FIFO threshold boundary conditions +* +* This is used to cope with the threshold boundary condition +* being slightly different on sun5i and sun6i. +* +* On sun5i the threshold is exclusive, i.e. does not include, +* the value of the threshold. ( > for RX; < for TX ) +* On sun6i the threshold is inclusive, i.e. includes, the +* value of the threshold. ( >= for RX; <= for TX ) +*/ + boolddc_fifo_thres_incl; + + boolddc_fifo_has_dir; +}; + struct sun4i_hdmi { struct drm_connectorconnector; struct drm_encoder encoder; @@ -165,9 +215,13 @@ struct sun4i_hdmi { void __iomem*base; struct regmap *regmap; + /* Reset control */ + struct reset_control*reset; + /* Parent clocks */ struct clk *bus_clk; struct clk *mod_clk; + struct clk *ddc_parent_clk; struct clk *pll0_clk; struct clk *pll1_clk; @@ -177,10 +231,28 @@ struct sun4i_hdmi { struct i2c_adapter *i2c; + /* Regmap fields for I2C adapter */ + struct regmap_field *field_ddc_en; + struct regmap_field *field_ddc_start; + struct regmap_field *field_ddc_reset; + struct regmap_field *field_ddc_addr_reg; + struct regmap_field *field_ddc_slave_addr; + struct regmap_field *field_ddc_int_mask; + struct regmap_field *field_ddc_int_status; + struct regmap_field *field_ddc_fifo_clear; + struct regmap_field *field_ddc_fifo_rx_thres; + struct regmap_field *field_ddc_fifo_tx_thres; + struct regmap_field *field_ddc_byte_count; + struct
[PATCH v4 06/11] dt-bindings: display: sun4i: Add binding for A31 HDMI controller
The HDMI controller in the A31 SoC is slightly different from the earlier version. In addition to the TMDS clock and DDC controls, this version now takes a second DDC clock input. Add a compatible string for it, and add the DDC clock input to the list of clocks required. Signed-off-by: Chen-Yu TsaiAcked-by: Rob Herring --- Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index 92441086caba..46df3b78ae9e 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -41,14 +41,17 @@ CEC. It is one end of the pipeline. Required properties: - compatible: value must be one of: * allwinner,sun5i-a10s-hdmi +* allwinner,sun6i-a31-hdmi - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - clocks: phandles to the clocks feeding the HDMI encoder * ahb: the HDMI interface clock * mod: the HDMI module clock +* ddc: the HDMI ddc clock (A31 only) * pll-0: the first video PLL * pll-1: the second video PLL - clock-names: the clock names mentioned above + - resets: phandle to the reset control for the HDMI encoder (A31 only) - dmas: phandles to the DMA channels used by the HDMI encoder * ddc-tx: The channel for DDC transmission * ddc-rx: The channel for DDC reception -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 00/11] drm/sun4i: hdmi: Support HDMI controller on A31
Hi everyone, This is v4 of my A31 HDMI support series. The DTS patches depend on the patch "clk: sunxi-ng: sun6i: Export video PLLs" alreay merged. The DRM patches depend on "regmap: add iopoll-like polling macro for regmap_field" already merged on a topic branch in the regmap repository. Changes since v3: - Renamed sun4i_get_first_tcon() to sun4i_get_tcon0() - Made sun4i_get_tcon0() return NULL when it fails, and sun6i_tcon_set_mux() will error out if that happens. - Removed has_unknown_mux field in tcon_quirks structure, as its function is replaced by the per-soc muxing function pointer. - Dropped clk and regmap patches that were merged. Changes since v2: - TCON muxing moved into functions for each platform, with pointers to them in the TCON quirks structure. - CCU "hdmi-ddc" clock renamed to "ddc". - Added Maxime's acks. Changes since v1: - Core changes to sun4i-drm to support two display pipelines have been merged into drm-misc and thus dropped from this version - Reworked DDC variant support onto new exposed I2C interface bits. - Reworked DDC variant support to use regmap_fields. - Patches to add variant support to various (TMDS, DDC, HDMI controller) sub-blocks have been merged into one patch. This series adds support for the HDMI controller found on Allwinner A31/A31s SoCs. It builds upon Maxime's work that added support for the HDMI controller on the Allwinner A10s SoC. The HDMI controllers in the older generation Allwinner SoCs is very similar. The A10/A10s/A20 all have the same hardware block, with the A10 having slightly different initial configuration values. The A31's variant splits out the DDC parent clock, has different formulas for the DDC and TMDS clocks, and a different register layout for the DDC block. Also, it does not expose the CEC pins outside of the SoC, which is unfortunate. Patch 1 moves the existing TCON muxing code for the A13 into a separate function, pointed to by by function pointer in the quirks structure. The existing sun4i_tcon_set_mux() function calls the function pointer if it is set. Patch 2 adds support for the TCON demuxing feature on the A31. This is needed if the user wants to output through HDMI from the second display pipeline. Patch 3 adds proper error path cleanup to the HDMI driver. Patch 4 adds a regmap for the HDMI driver, to be used in a subsequent patch. Patch 5 allows the HDMI TMDS clock to use the second PLL as its parent, in case the first PLL is driving an incompatible dot clock. Patch 6 adds the A31 HDMI controller variant to the device tree binding. Patch 7 adds support for different variants of the HDMI controller hardware, with the differences mentioned in the beginning of this letter. Patch 8 adds defines for the A31 specific DDC register offsets. Patch 9 adds support for the A31's HDMI controller variant. Patch 10 adds a device node for the HDMI controller on the A31. Patch 11 enable HDMI video output on three boards that I have. I also had simultaneous output on both display pipelines on the SinA31s, one with an LCD panel and the other using HDMI. After boot, both screens showed a proper console. The HDMI screen had higher resolution, so the console was limited to the upper left corner. Note that this series does not deal with conflicting pixel clocks. As I still don't have a freedesktop.org account [1] to access drm-misc, Maxime will have to apply the patches for me. Regards ChenYu [1] https://bugs.freedesktop.org/show_bug.cgi?id=102920 Chen-Yu Tsai (11): drm/sun4i: tcon: Add variant callback for TCON output muxing drm/sun4i: tcon: Add support for demuxing TCON output on A31 drm/sun4i: hdmi: Disable clks in bind function error path and unbind function drm/sun4i: hdmi: create a regmap for later use drm/sun4i: hdmi: Allow using second PLL as TMDS clk parent dt-bindings: display: sun4i: Add binding for A31 HDMI controller drm/sun4i: hdmi: Add support for controller hardware variants drm/sun4i: hdmi: Add A31 specific DDC register definitions drm/sun4i: hdmi: Add support for A31's HDMI controller ARM: dts: sun6i: Add device node for HDMI controller ARM: dts: sun6i: Enable HDMI support on some A31/A31s devices .../bindings/display/sunxi/sun4i-drm.txt | 3 + arch/arm/boot/dts/sun6i-a31-hummingbird.dts| 21 ++ arch/arm/boot/dts/sun6i-a31.dtsi | 55 + arch/arm/boot/dts/sun6i-a31s-primo81.dts | 25 +++ arch/arm/boot/dts/sun6i-a31s-sina31s.dts | 25 +++ drivers/gpu/drm/sun4i/sun4i_hdmi.h | 107 ++ drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 38 +++- drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 204 +++--- drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 227 +++-- drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c| 68 +++--- drivers/gpu/drm/sun4i/sun4i_tcon.c
[PATCH v4 03/11] drm/sun4i: hdmi: Disable clks in bind function error path and unbind function
The HDMI driver enables the bus and mod clocks in the bind function, but does not disable them if it then bails our due to any errors. Neither does it disable the clocks in the unbind function. Fix this by adding a proper error path to the bind function, and clk_disable_unprepare calls to the unbind function. Also rename the err_cleanup_connector label to err_cleanup_encoder, since it is the encoder that gets cleaned up. Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support") Signed-off-by: Chen-Yu TsaiAcked-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c index 9ea6cd5a1370..3cf1a6932fac 100644 --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c @@ -302,26 +302,29 @@ static int sun4i_hdmi_bind(struct device *dev, struct device *master, hdmi->mod_clk = devm_clk_get(dev, "mod"); if (IS_ERR(hdmi->mod_clk)) { dev_err(dev, "Couldn't get the HDMI mod clock\n"); - return PTR_ERR(hdmi->mod_clk); + ret = PTR_ERR(hdmi->mod_clk); + goto err_disable_bus_clk; } clk_prepare_enable(hdmi->mod_clk); hdmi->pll0_clk = devm_clk_get(dev, "pll-0"); if (IS_ERR(hdmi->pll0_clk)) { dev_err(dev, "Couldn't get the HDMI PLL 0 clock\n"); - return PTR_ERR(hdmi->pll0_clk); + ret = PTR_ERR(hdmi->pll0_clk); + goto err_disable_mod_clk; } hdmi->pll1_clk = devm_clk_get(dev, "pll-1"); if (IS_ERR(hdmi->pll1_clk)) { dev_err(dev, "Couldn't get the HDMI PLL 1 clock\n"); - return PTR_ERR(hdmi->pll1_clk); + ret = PTR_ERR(hdmi->pll1_clk); + goto err_disable_mod_clk; } ret = sun4i_tmds_create(hdmi); if (ret) { dev_err(dev, "Couldn't create the TMDS clock\n"); - return ret; + goto err_disable_mod_clk; } writel(SUN4I_HDMI_CTRL_ENABLE, hdmi->base + SUN4I_HDMI_CTRL_REG); @@ -362,7 +365,7 @@ static int sun4i_hdmi_bind(struct device *dev, struct device *master, ret = sun4i_hdmi_i2c_create(dev, hdmi); if (ret) { dev_err(dev, "Couldn't create the HDMI I2C adapter\n"); - return ret; + goto err_disable_mod_clk; } drm_encoder_helper_add(>encoder, @@ -422,6 +425,10 @@ static int sun4i_hdmi_bind(struct device *dev, struct device *master, drm_encoder_cleanup(>encoder); err_del_i2c_adapter: i2c_del_adapter(hdmi->i2c); +err_disable_mod_clk: + clk_disable_unprepare(hdmi->mod_clk); +err_disable_bus_clk: + clk_disable_unprepare(hdmi->bus_clk); return ret; } @@ -434,6 +441,8 @@ static void sun4i_hdmi_unbind(struct device *dev, struct device *master, drm_connector_cleanup(>connector); drm_encoder_cleanup(>encoder); i2c_del_adapter(hdmi->i2c); + clk_disable_unprepare(hdmi->mod_clk); + clk_disable_unprepare(hdmi->bus_clk); } static const struct component_ops sun4i_hdmi_ops = { -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 02/11] drm/sun4i: tcon: Add support for demuxing TCON output on A31
On systems with 2 TCONs such as the A31, it is possible to demux the output of the TCONs to one encoder. Add support for this for the A31. Signed-off-by: Chen-Yu Tsai--- drivers/gpu/drm/sun4i/sun4i_tcon.c | 47 ++ 1 file changed, 47 insertions(+) diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 75124043d655..68751b999877 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -112,6 +112,27 @@ void sun4i_tcon_enable_vblank(struct sun4i_tcon *tcon, bool enable) } EXPORT_SYMBOL(sun4i_tcon_enable_vblank); +/* + * This function is a helper for TCON output muxing. The TCON output + * muxing control register in earlier SoCs (without the TCON TOP block) + * are located in TCON0. This helper returns a pointer to TCON0's + * sun4i_tcon structure, or NULL if not found. + */ +static struct sun4i_tcon *sun4i_get_tcon0(struct drm_device *drm) +{ + struct sun4i_drv *drv = drm->dev_private; + struct sun4i_tcon *tcon; + + list_for_each_entry(tcon, >tcon_list, list) + if (tcon->id == 0) + return tcon; + + dev_warn(drm->dev, +"TCON0 not found, display output muxing may not work\n"); + + return NULL; +} + void sun4i_tcon_set_mux(struct sun4i_tcon *tcon, int channel, struct drm_encoder *encoder) { @@ -777,6 +798,31 @@ static int sun5i_a13_tcon_set_mux(struct sun4i_tcon *tcon, return regmap_write(tcon->regs, SUN4I_TCON_MUX_CTRL_REG, val); } +static int sun6i_tcon_set_mux(struct sun4i_tcon *tcon, + struct drm_encoder *encoder) +{ + struct sun4i_tcon *tcon0 = sun4i_get_tcon0(encoder->dev); + u32 shift; + + if (!tcon0) + return -EINVAL; + + switch (encoder->encoder_type) { + case DRM_MODE_ENCODER_TMDS: + /* HDMI */ + shift = 8; + break; + default: + /* TODO A31 has MIPI DSI but A31s does not */ + return -EINVAL; + } + + regmap_update_bits(tcon0->regs, SUN4I_TCON_MUX_CTRL_REG, + 0x3 << shift, tcon->id << shift); + + return 0; +} + static const struct sun4i_tcon_quirks sun5i_a13_quirks = { .has_channel_1 = true, .set_mux= sun5i_a13_tcon_set_mux, @@ -785,6 +831,7 @@ static const struct sun4i_tcon_quirks sun5i_a13_quirks = { static const struct sun4i_tcon_quirks sun6i_a31_quirks = { .has_channel_1 = true, .needs_de_be_mux= true, + .set_mux= sun6i_tcon_set_mux, }; static const struct sun4i_tcon_quirks sun6i_a31s_quirks = { -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 08/11] drm/sun4i: hdmi: Add A31 specific DDC register definitions
The DDC block for the HDMI controller is different on the A31. This patch adds the register definitions. Signed-off-by: Chen-Yu TsaiAcked-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_hdmi.h | 31 +++ 1 file changed, 31 insertions(+) diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h b/drivers/gpu/drm/sun4i/sun4i_hdmi.h index 3057e31219f6..ee42ae7e5a21 100644 --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h @@ -153,6 +153,37 @@ #define SUN4I_HDMI_DDC_FIFO_SIZE 16 +/* A31 specific */ +#define SUN6I_HDMI_DDC_CTRL_REG0x500 +#define SUN6I_HDMI_DDC_CTRL_RESET BIT(31) +#define SUN6I_HDMI_DDC_CTRL_START_CMD BIT(27) +#define SUN6I_HDMI_DDC_CTRL_SDA_ENABLE BIT(6) +#define SUN6I_HDMI_DDC_CTRL_SCL_ENABLE BIT(4) +#define SUN6I_HDMI_DDC_CTRL_ENABLE BIT(0) + +#define SUN6I_HDMI_DDC_CMD_REG 0x508 +#define SUN6I_HDMI_DDC_CMD_BYTE_COUNT(count) ((count) << 16) +/* command types in lower 3 bits are the same as sun4i */ + +#define SUN6I_HDMI_DDC_ADDR_REG0x50c +#define SUN6I_HDMI_DDC_ADDR_SEGMENT(seg) (((seg) & 0xff) << 24) +#define SUN6I_HDMI_DDC_ADDR_EDDC(addr) (((addr) & 0xff) << 16) +#define SUN6I_HDMI_DDC_ADDR_OFFSET(off)(((off) & 0xff) << 8) +#define SUN6I_HDMI_DDC_ADDR_SLAVE(addr)(((addr) & 0xff) << 1) + +#define SUN6I_HDMI_DDC_INT_STATUS_REG 0x514 +#define SUN6I_HDMI_DDC_INT_STATUS_TIMEOUT BIT(8) +/* lower 8 bits are the same as sun4i */ + +#define SUN6I_HDMI_DDC_FIFO_CTRL_REG 0x518 +#define SUN6I_HDMI_DDC_FIFO_CTRL_CLEAR BIT(15) +/* lower 9 bits are the same as sun4i */ + +#define SUN6I_HDMI_DDC_CLK_REG 0x520 +/* DDC CLK bit fields are the same, but the formula is not */ + +#define SUN6I_HDMI_DDC_FIFO_DATA_REG 0x580 + enum sun4i_hdmi_pkt_type { SUN4I_HDMI_PKT_AVI = 2, SUN4I_HDMI_PKT_END = 15, -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/msm/dsi: Use correct pm_runtime_put variant during host_init
On 10/06/2017 07:32 PM, Daniel Vetter wrote: On Fri, Oct 06, 2017 at 04:27:06PM +0530, Archit Taneja wrote: The DSI runtime PM suspend/resume callbacks check whether msm_host->cfg_hnd is non-NULL before trying to enable the bus clocks. This is done to accommodate early calls to these functions that may happen before the bus clocks are even initialized. Calling pm_runtime_put_autosuspend() in dsi_host_init() can result in racy behaviour since msm_host->cfg_hnd is set very soon after. If the suspend callback happens too late, we end up trying to disable clocks that were never enabled, resulting in a bunch of WARN_ON splats. Sounds like the correct fix here is to block autosuspend until after everything is set up, including bus clocks. This patch just makes the race harder to hit in practice ... Thanks for the review. pm_runtime_put_sync() ensures that the suspend handler is called in the same context as that of the caller, right? msm_host->cfg_hnd is set to a non-NULL value only when we return from dsi_get_config(). The race would never happen in this case. This call is a one time thing during DSI probe, we do a pm_runtime_get_sync() just so that we can read the block revision number. Once we have the revision number, we look at an internal table which maintains IP version specific resources, like what bus clocks to get, etc. Having pm_runtime_put_autosuspend() here didn't help much anyway. Archit -Daniel Use pm_runtime_put_sync() so that the suspend callback is called immediately. Reported-by: Nicolas DechesneSigned-off-by: Archit Taneja --- drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index dbb31a014419..deaf869374ea 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -248,7 +248,7 @@ static const struct msm_dsi_cfg_handler *dsi_get_config( clk_disable_unprepare(ahb_clk); disable_gdsc: regulator_disable(gdsc_reg); - pm_runtime_put_autosuspend(dev); + pm_runtime_put_sync(dev); put_clk: clk_put(ahb_clk); put_gdsc: -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/5] Simplify panel bridge cleanup
On 10/02/2017 03:02 PM, Benjamin Gaignard wrote: The goal of this series is to simplify driver code when they need to clean up a previously allocated panel bridge. Few drivers have "is_panel_bridge" flag to be able to distinguish a drm_panel_bridge from "simple" drm_bridge. To remove this flag I propose to - let drm_panel_bridge_remove() check if the bridge provided in parameter is really a drm_panel_bridge. - add drm_of_panel_bridge_remove() to remove a bridge given DT port and endpoint Finally that allow to remove drm_bridge structure and "is_panel_bridge" flag from stm driver internal structure. version 2: - does the same for vc4 and dw-mipi-dsi For the series: Reviewed-by: Archit TanejaFeel free to queue to drm-misc-next. Thanks, Archit Benjamin Gaignard (5): drm/bridge: make drm_panel_bridge_remove more robust drm/drm_of: add drm_of_panel_bridge_remove function drm/stm: ltdc: remove bridge from driver internal structure drm/vc4: remove bridge from driver internal structure drm/bridge/synopsys: dsi :remove is_panel_bridge drivers/gpu/drm/bridge/panel.c| 10 +++- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 5 +--- drivers/gpu/drm/drm_of.c | 33 +++ drivers/gpu/drm/stm/ltdc.c| 16 - drivers/gpu/drm/stm/ltdc.h| 2 -- drivers/gpu/drm/vc4/vc4_dpi.c | 17 +- include/drm/drm_of.h | 8 +++ 7 files changed, 62 insertions(+), 29 deletions(-) -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3 0/2] drm/bridge/adv7511: add CEC support
On 10/07/2017 04:16 PM, Hans Verkuil wrote: From: Hans VerkuilThis patch series adds CEC support to the drm adv7511/adv7533 drivers. I have tested this with the Qualcomm Dragonboard C410 (adv7533 based) and the Renesas R-Car Koelsch board (adv7511 based). I only have the Koelsch board to test with, but it looks like other R-Car boards use the same adv7511. It would be nice if someone can add CEC support to the other R-Car boards as well. The main thing to check is if they all use the same 12 MHz fixed CEC clock source. queued to drm-misc-next. Thanks, Archit Anyone who wants to test this will need the CEC utilities that are part of the v4l-utils git repository: git clone git://linuxtv.org/v4l-utils.git cd v4l-utils ./bootstrap.sh ./configure make sudo make install Now configure the CEC adapter as a Playback device: cec-ctl --playback Discover other CEC devices: cec-ctl -S Regards, Hans Changes since v2: - A small rewording of the 'clocks' property description in the bindings as per Sergei's comment. Changes since v1: - Incorporate Archit's comments: use defines for irq masks combine the adv7511/33 regmap_configs adv7511_cec_init now handles dt parsing & CEC registration - Use the new (4.14) CEC_CAP_DEFAULTS define Hans Verkuil (2): dt-bindings: adi,adv7511.txt: document cec clock drm: adv7511/33: add HDMI CEC support .../bindings/display/bridge/adi,adv7511.txt| 4 + drivers/gpu/drm/bridge/adv7511/Kconfig | 8 + drivers/gpu/drm/bridge/adv7511/Makefile| 1 + drivers/gpu/drm/bridge/adv7511/adv7511.h | 43 ++- drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 337 + drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 116 ++- drivers/gpu/drm/bridge/adv7511/adv7533.c | 38 +-- 7 files changed, 489 insertions(+), 58 deletions(-) create mode 100644 drivers/gpu/drm/bridge/adv7511/adv7511_cec.c -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93548] Grid Autosport causes a hard system crash
https://bugs.freedesktop.org/show_bug.cgi?id=93548 Timothy Arcerichanged: What|Removed |Added Resolution|--- |FIXED Status|NEEDINFO|RESOLVED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] dt-bindings: Add document for rockchip RGB output interface
在 2017/10/9 21:05, Rob Herring 写道: On Mon, Oct 9, 2017 at 3:06 AM, Sandy Huangwrote: Hi rob, Thanks for your reply. 在 2017/10/4 5:56, Rob Herring 写道: On Fri, Sep 22, 2017 at 11:00:26AM +0800, Sandy Huang wrote: This path add support rv1108 rgb output interface driver. Signed-off-by: Sandy Huang --- Changes in v2: 1. rename rockchip,rgb-mode to rgb-mode; You can't just drop the vendor. This needs to be documented in a common place that others will find and use. See panel-common.txt or panel-dpi.txt. Alternatively, you could just drop it and let the panel compatible imply what the mode is. ok, get it, i will move the rgb-mode to panel and describe it at panel-rgb.txt. the patches will be send soon later. Don't create yet another common panel file. We already have panel-dpi.txt which is for digital parallel interface. The panel-rgb.txt define different rgb output format and timing, this is the detail info: https://patchwork.kernel.org/patch/9992241/ do you think this need move to panel-dpi.txt? Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] headers: sync DRM_MODE_ROTATE/REFLECT defines from kernel v4.14-rc1
Hey Rob, This looks good to me, feel free to add my r-b. Rob. On Fri, 2017-10-06 at 16:31 -0500, Rob Herring wrote: > Add the new DRM_MODE_ROTATE_* and DRM_MODE_REFLECT_* defines from > v4.14-rc1 > kernel. > > Signed-off-by: Rob Herring> --- > include/drm/drm_mode.h | 47 > +++ > 1 file changed, 47 insertions(+) > > diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h > index 080779785eb8..e01f129c0204 100644 > --- a/include/drm/drm_mode.h > +++ b/include/drm/drm_mode.h > @@ -119,6 +119,53 @@ extern "C" { > #define DRM_MODE_LINK_STATUS_GOOD0 > #define DRM_MODE_LINK_STATUS_BAD 1 > > +/* > + * DRM_MODE_ROTATE_ > + * > + * Signals that a drm plane is been rotated degrees in > counter > + * clockwise direction. > + * > + * This define is provided as a convenience, looking up the property > id > + * using the name->prop id lookup is the preferred method. > + */ > +#define DRM_MODE_ROTATE_0 (1<<0) > +#define DRM_MODE_ROTATE_90 (1<<1) > +#define DRM_MODE_ROTATE_180 (1<<2) > +#define DRM_MODE_ROTATE_270 (1<<3) > + > +/* > + * DRM_MODE_ROTATE_MASK > + * > + * Bitmask used to look for drm plane rotations. > + */ > +#define DRM_MODE_ROTATE_MASK (\ > + DRM_MODE_ROTATE_0 | \ > + DRM_MODE_ROTATE_90 | \ > + DRM_MODE_ROTATE_180 | \ > + DRM_MODE_ROTATE_270) > + > +/* > + * DRM_MODE_REFLECT_ > + * > + * Signals that the contents of a drm plane is reflected in the > axis, > + * in the same way as mirroring. > + * > + * This define is provided as a convenience, looking up the property > id > + * using the name->prop id lookup is the preferred method. > + */ > +#define DRM_MODE_REFLECT_X (1<<4) > +#define DRM_MODE_REFLECT_Y (1<<5) > + > +/* > + * DRM_MODE_REFLECT_MASK > + * > + * Bitmask used to look for drm plane reflections. > + */ > +#define DRM_MODE_REFLECT_MASK (\ > + DRM_MODE_REFLECT_X | \ > + DRM_MODE_REFLECT_Y) > + > + > struct drm_mode_modeinfo { > __u32 clock; > __u16 hdisplay; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hwc] drm_hwcomposer: use upstream DRM_MODE_{ROTATE,REFLECT} defines
Hey Rob, This looks good to me, added r-b and pushed. Rob. On Fri, 2017-10-06 at 16:46 -0500, Rob Herring wrote: > The DRM_REFLECT_* and DRM_ROTATE_* defines were not upstream, but now > they are. Convert to using the upstream version which are defined as > a > bit mask rather than a bit position. > > Signed-off-by: Rob Herring> --- > drmdisplaycompositor.cpp | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drmdisplaycompositor.cpp b/drmdisplaycompositor.cpp > index a07d3588d1f5..036a45e8b88b 100644 > --- a/drmdisplaycompositor.cpp > +++ b/drmdisplaycompositor.cpp > @@ -572,15 +572,15 @@ int > DrmDisplayCompositor::CommitFrame(DrmDisplayComposition > *display_comp, > > rotation = 0; > if (layer.transform & DrmHwcTransform::kFlipH) > -rotation |= 1 << DRM_REFLECT_X; > +rotation |= DRM_MODE_REFLECT_X; > if (layer.transform & DrmHwcTransform::kFlipV) > -rotation |= 1 << DRM_REFLECT_Y; > +rotation |= DRM_MODE_REFLECT_Y; > if (layer.transform & DrmHwcTransform::kRotate90) > -rotation |= 1 << DRM_ROTATE_90; > +rotation |= DRM_MODE_ROTATE_90; > else if (layer.transform & DrmHwcTransform::kRotate180) > -rotation |= 1 << DRM_ROTATE_180; > +rotation |= DRM_MODE_ROTATE_180; > else if (layer.transform & DrmHwcTransform::kRotate270) > -rotation |= 1 << DRM_ROTATE_270; > +rotation |= DRM_MODE_ROTATE_270; > > if (fence_fd < 0) { > int prop_id = plane->in_fence_fd_property().id(); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hwc] drm_hwcomposer: remove NVIDIA importer
Hey Rob, +Thierry This looks good to me, does anyone have a strong opinion the other way? I'll let this one soak for a day or two more. Rob. On Fri, 2017-10-06 at 17:02 -0500, Rob Herring wrote: > There's no opensource implementation for the NVIDIA gralloc > implementation, > so remove it as it is not testable. > > As all of the gralloc perform() operations are specific to it, they > can be > removed, too. > > Signed-off-by: Rob Herring> --- > Android.mk | 5 - > drmhwcgralloc.h | 33 - > platformnv.cpp | 374 -- > -- > 3 files changed, 412 deletions(-) > delete mode 100644 platformnv.cpp > > diff --git a/Android.mk b/Android.mk > index 99bbcac3e984..d7dc6782e1e0 100644 > --- a/Android.mk > +++ b/Android.mk > @@ -71,7 +71,6 @@ LOCAL_SRC_FILES := \ > hwcutils.cpp \ > platform.cpp \ > platformdrmgeneric.cpp \ > - platformnv.cpp \ > separate_rects.cpp \ > virtualcompositorworker.cpp \ > vsyncworker.cpp > @@ -80,11 +79,7 @@ LOCAL_CPPFLAGS += \ > -DHWC2_USE_CPP11 \ > -DHWC2_INCLUDE_STRINGIFICATION > > -ifeq ($(strip $(BOARD_DRM_HWCOMPOSER_BUFFER_IMPORTER)),nvidia- > gralloc) > -LOCAL_CPPFLAGS += -DUSE_NVIDIA_IMPORTER > -else > LOCAL_CPPFLAGS += -DUSE_DRM_GENERIC_IMPORTER > -endif > > LOCAL_MODULE := hwcomposer.drm > LOCAL_MODULE_TAGS := optional > diff --git a/drmhwcgralloc.h b/drmhwcgralloc.h > index c4a42eaf1c54..759746a67949 100644 > --- a/drmhwcgralloc.h > +++ b/drmhwcgralloc.h > @@ -19,39 +19,6 @@ > > #include > > -enum { > - /* perform(const struct gralloc_module_t *mod, > - * int op, > - * int drm_fd, > - * buffer_handle_t buffer, > - * struct hwc_drm_bo *bo); > - */ > - GRALLOC_MODULE_PERFORM_DRM_IMPORT = 0xffeeff00, > - > - /* perform(const struct gralloc_module_t *mod, > - * int op, > - * buffer_handle_t buffer, > - * void (*free_callback)(void *), > - * void *priv); > - */ > - GRALLOC_MODULE_PERFORM_SET_IMPORTER_PRIVATE = 0xffeeff01, > - > - /* perform(const struct gralloc_module_t *mod, > - * int op, > - * buffer_handle_t buffer, > - * void (*free_callback)(void *), > - * void **priv); > - */ > - GRALLOC_MODULE_PERFORM_GET_IMPORTER_PRIVATE = 0xffeeff02, > - > - /* perform(const struct gralloc_module_t *mod, > - * int op, > - * buffer_handle_t buffer, > - * int *usage); > - */ > - GRALLOC_MODULE_PERFORM_GET_USAGE = 0xffeeff03, > -}; > - > typedef struct hwc_drm_bo { > uint32_t width; > uint32_t height; > diff --git a/platformnv.cpp b/platformnv.cpp > deleted file mode 100644 > index e7b6be3430a8.. > --- a/platformnv.cpp > +++ /dev/null > @@ -1,374 +0,0 @@ > -/* > - * Copyright (C) 2015 The Android Open Source Project > - * > - * Licensed under the Apache License, Version 2.0 (the "License"); > - * you may not use this file except in compliance with the License. > - * You may obtain a copy of the License at > - * > - * http://www.apache.org/licenses/LICENSE-2.0 > - * > - * Unless required by applicable law or agreed to in writing, > software > - * distributed under the License is distributed on an "AS IS" BASIS, > - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or > implied. > - * See the License for the specific language governing permissions > and > - * limitations under the License. > - */ > - > -#define LOG_TAG "hwc-platform-nv" > - > -#include "drmresources.h" > -#include "platform.h" > -#include "platformnv.h" > - > -#include > -#include > -#include > -#include > -#include > - > -#include > -#include > - > -#ifndef EGL_NATIVE_HANDLE_ANDROID_NVX > -#define EGL_NATIVE_HANDLE_ANDROID_NVX 0x322A > -#endif > - > -namespace android { > - > -#ifdef USE_NVIDIA_IMPORTER > -// static > -Importer *Importer::CreateInstance(DrmResources *drm) { > - NvImporter *importer = new NvImporter(drm); > - if (!importer) > -return NULL; > - > - int ret = importer->Init(); > - if (ret) { > -ALOGE("Failed to initialize the nv importer %d", ret); > -delete importer; > -return NULL; > - } > - return importer; > -} > -#endif > - > -NvImporter::NvImporter(DrmResources *drm) : drm_(drm) { > -} > - > -NvImporter::~NvImporter() { > -} > - > -int NvImporter::Init() { > - int ret = hw_get_module(GRALLOC_HARDWARE_MODULE_ID, > - (const hw_module_t **)_); > - if (ret) { > -ALOGE("Failed to open gralloc module %d", ret); > -return ret; > - } > - > - if (strcasecmp(gralloc_->common.author, "NVIDIA")) > -ALOGW("Using non-NVIDIA gralloc module: %s/%s\n", gralloc_- > >common.name, > - gralloc_->common.author); > - > - return 0; > -} > - > - > -EGLImageKHR NvImporter::ImportImage(EGLDisplay egl_display, > buffer_handle_t handle) { > - return eglCreateImageKHR( > - egl_display, EGL_NO_CONTEXT, EGL_NATIVE_HANDLE_ANDROID_NVX, > - (EGLClientBuffer)handle, NULL /*
Re: [PATCH v7 1/3] backlight: Add IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
On 06/10/17 19:01, Noralf Trønnes wrote: Den 03.10.2017 11.04, skrev Daniel Vetter: On Tue, Oct 03, 2017 at 09:51:49AM +0100, Daniel Thompson wrote: On 03/10/17 09:03, Daniel Vetter wrote: On Mon, Oct 02, 2017 at 12:00:54PM +0300, Jani Nikula wrote: On Mon, 02 Oct 2017, Daniel Thompsonwrote: So I'm coming to this patchset cold but can you explain *why* something wants to call of_find_backlight_by_node() when there is no backlight support enabled. Why isn't the code that called is conditional on BACKLIGHT_CLASS_DEVICE? The undefined symbol issue is a pain but to be honest I'd rather solve the use of undefined symbols by avoiding declaring them; this making them into compile errors rather than link errors. Typically the kernel header files define static inline stubs of the functions when the actual functions aren't configured/built. The code using the functions looks the same regardless of the config option, and handles the -ENODEV or NULL or whatever returns from the stubs gracefully. With the inlines, the compiler can usually throw out much of the code anyway. In this regard, the backlight interface is an exception, forcing the callers to wrap the code around IS_ENABLED(BACKLIGHT_CLASS_DEVICE), not the rule. fwiw, I think it'd be great if we can move backlight over to the common pattern, like everyone else. It's pretty big pain as-is ... For sure, after Jani's mail yesterday I looked at the GMA500 driver and concluded I didn't want code related to backlight having to look like that! Currently the three main patterns of use are: 1. Standalone drivers simple depend on BACKLIGHT_CLASS_DEVICE, 2. Some compound drivers select BACKLIGHT_CLASS_DEVICE (the AMD DRM driver is an example of this), 3. Other compound drivers perform heroics with the pre-processor. The main reason I'm not just agreeing straight away is that, to adopt the static inline pattern for the whole API, we have to believe that #3 above is desirable. Given the size and scope of the compound drivers in #3 above, I don't entirely understand why they want to avoid the select. People love to over-configure their kernels and shave off a few bytes. And big gpu drivers might have backlight support, but not always need it (e.g. if you run without a panel as e.g. a tv set-top-box). Same with e.g. a driver that supports both OF/DT and pci to find its devices. On the desktop gpu driver side we don't really subscribe to this idea of making everything optional, hence select (mostly), except select is a huge pain. On the mobile/soc gpu side, #3 seems to be the desired outcome. Doing static inline helpers for backlights would make both easier (since in the end for desktop you just get a distro kernel that enables everything anyway). So yeah, imo if you think backlight should be a Kconfig, then it should have static inline dummy functions to make life simpler for everyone. Only exception are pure driver-only subsystem code which aren't ever called by anything outside of your subsystem. But since the point of the backlight subsystem is to provide backlight support to other drivers (there's still the dream that we don't offload this onto userspace, that just doesn't work well) we really should have these static inline helpers. I suggest we put all the backlight subsystem only functionality we need, into the backlight subsystem :-) I've put together a suggestion below and I've deliberately dropped the of_ infix in backlight_get() to make room for possible future additions that can make it possible to set the connection between device and backlight using platform table or ACPI, fashioned after gpiolib. Looks good to me. If I've read this right, other sub-systems can use these symbols with or without BACKLIGHT_CLASS_DEVICE and still compile OK? Daniel. include/linux/backlight.h: /** * backlight_enable - Enable backlight * @bd: the backlight device to enable */ static inline int backlight_enable(struct backlight_device *bd) { if (!bd) return 0; bd->props.power = FB_BLANK_UNBLANK; bd->props.state &= ~BL_CORE_FBBLANK; return backlight_update_status(bd); } /** * backlight_disable - Disable backlight * @bd: the backlight device to disable */ static inline int backlight_disable(struct backlight_device *bd) { if (!bd) return 0; bd->props.power = FB_BLANK_POWERDOWN; bd->props.state |= BL_CORE_FBBLANK; return backlight_update_status(bd); } /** * backlight_put - Drop backlight reference * @bd: the backlight device to put */ static inline void backlight_put(struct backlight_device *bd) { if (bd) put_device(bd->dev); } #if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE) struct backlight_device *backlight_get(struct device *dev); struct backlight_device *devm_backlight_get(struct device *dev); #else static inline struct backlight_device *backlight_get(struct device *dev) { return NULL; }
[drm-intel:for-linux-next 18/27] drivers/gpu//drm/i915/i915_gem_gtt.c:1087: error: 'iter' is used uninitialized in this function
tree: git://anongit.freedesktop.org/drm-intel for-linux-next head: a883241c3922000b21b58b5740c55badfe09940f commit: 0a03852e049af91da9ae70326c44bb5d9b0d377a [18/27] drm/i915: support 2M pages for the 48b PPGTT config: x86_64-randconfig-b0-10091604 (attached as .config) compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7 reproduce: git checkout 0a03852e049af91da9ae70326c44bb5d9b0d377a # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): cc1: warnings being treated as errors drivers/gpu//drm/i915/i915_gem_gtt.c: In function 'intel_ppat_get': drivers/gpu//drm/i915/i915_gem_gtt.c:2969: error: 'entry' may be used uninitialized in this function drivers/gpu//drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_insert_3lvl': drivers/gpu//drm/i915/i915_gem_gtt.c:1007: error: 'iter.sg' is used uninitialized in this function drivers/gpu//drm/i915/i915_gem_gtt.c:1008: error: 'iter.dma' may be used uninitialized in this function drivers/gpu//drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_insert_4lvl': >> drivers/gpu//drm/i915/i915_gem_gtt.c:1087: error: 'iter' is used >> uninitialized in this function vim +/iter +1087 drivers/gpu//drm/i915/i915_gem_gtt.c 0a03852e0 Matthew Auld 2017-10-06 1078 894ccebee Chris Wilson 2017-02-15 1079 static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm, 4a234c5fa Matthew Auld 2017-06-22 1080 struct i915_vma *vma, 894ccebee Chris Wilson 2017-02-15 1081 enum i915_cache_level cache_level, 894ccebee Chris Wilson 2017-02-15 1082 u32 unused) 894ccebee Chris Wilson 2017-02-15 1083 { 894ccebee Chris Wilson 2017-02-15 1084 struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm); 894ccebee Chris Wilson 2017-02-15 1085 struct sgt_dma iter = { 4a234c5fa Matthew Auld 2017-06-22 1086 .sg = vma->pages->sgl, 894ccebee Chris Wilson 2017-02-15 @1087 .dma = sg_dma_address(iter.sg), 894ccebee Chris Wilson 2017-02-15 1088 .max = iter.dma + iter.sg->length, 894ccebee Chris Wilson 2017-02-15 1089 }; 894ccebee Chris Wilson 2017-02-15 1090 struct i915_page_directory_pointer **pdps = ppgtt->pml4.pdps; 0a03852e0 Matthew Auld 2017-10-06 1091 0a03852e0 Matthew Auld 2017-10-06 1092 if (vma->page_sizes.sg > I915_GTT_PAGE_SIZE) { 0a03852e0 Matthew Auld 2017-10-06 1093 gen8_ppgtt_insert_huge_entries(vma, pdps, , cache_level); 0a03852e0 Matthew Auld 2017-10-06 1094 } else { 4a234c5fa Matthew Auld 2017-06-22 1095 struct gen8_insert_pte idx = gen8_insert_pte(vma->node.start); 894ccebee Chris Wilson 2017-02-15 1096 0a03852e0 Matthew Auld 2017-10-06 1097 while (gen8_ppgtt_insert_pte_entries(ppgtt, pdps[idx.pml4e++], 0a03852e0 Matthew Auld 2017-10-06 1098 , , cache_level)) 9e89f9ee3 Chris Wilson 2017-02-25 1099 GEM_BUG_ON(idx.pml4e >= GEN8_PML4ES_PER_PML4); f9b5b782c Michel Thierry 2015-07-30 1100 } 0a03852e0 Matthew Auld 2017-10-06 1101 } f9b5b782c Michel Thierry 2015-07-30 1102 :: The code at line 1087 was first introduced by commit :: 894ccebee2b0e606ba9638d20dd87b33568482d7 drm/i915: Micro-optimise gen8_ppgtt_insert_entries() :: TO: Chris Wilson:: CC: Chris Wilson --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: Clear drvdata after component unbind
When components are unbound, DRM driver is unregistered and freed, so clear drvdata to avoid potential use-after-free issue in suspend/resume paths. Signed-off-by: Marek Szyprowski--- drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index aa770bb0153c..82b72425a42f 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -430,6 +430,7 @@ static void exynos_drm_unbind(struct device *dev) kfree(drm->dev_private); drm->dev_private = NULL; + dev_set_drvdata(dev, NULL); drm_dev_unref(drm); } -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3] drm/i915: Replace *_reference/unreference() or *_ref/unref with _get/put()
On Sun, Oct 08, 2017 at 03:43:35PM +0100, Chris Wilson wrote: > Quoting Harsha Sharma (2017-10-08 15:04:07) > > @@ -624,7 +624,7 @@ static bool intel_fbdev_init_bios(struct drm_device > > *dev, > > ifbdev->preferred_bpp = fb->base.format->cpp[0] * 8; > > ifbdev->fb = fb; > > > > - drm_framebuffer_reference(>fb->base); > > + drm_framebuffer_put(>fb->base); > > Whoops. Hm yeah, how did this happen? Does cocci really do this, or is that an accident from manually fixing stuff up? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] pci: Fix a possible sleep-in-atomic bug in pci_set_power_state
On Mon, Oct 09, 2017 at 04:16:20PM +0800, Jia-Ju Bai wrote: > The drivers vt6655 and gma500 call pci_set_power_state under a spinlock, > which may sleep. > The function call paths are: > gma_power_begin (acquire the spinlock) (drivers/gpu/drm/gma500/power.c) > gma_resume_pci > pci_set_power_state > __pci_start_power_transition (drivers/pci/pci.c) > msleep --> may sleep > > gma_power_begin (acquire the spinlock) (drivers/gpu/drm/gma500/power.c) > gma_resume_pci > pci_enable_device > pci_enable_device_flags (drivers/pci/pci.c) > do_pci_enable_device > pci_set_power_state > __pci_start_power_transition > msleep --> may sleep > > vt6655_suspend (acquire the spinlock) (drivers/staging/vt6655/device_main.c) > pci_set_power_state > __pci_start_power_transition (drivers/pci/pci.c) > msleep --> may sleep > > To fix these bugs, msleep is replaced with mdelay in > __pci_start_power_transition > > These bugs are found by my static analysis tool and my code review. Wait, no, why not fix the callers to not have a spinlock. Those are the only users of these calls that are doing so incorrectly, don't change the PCI core for the fault of 2 broken drivers. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v5] ARM: dts: exynos: Add HDMI and Sil9234 to Trats2 board
Add HDMI and Sil9234 MHL converter to Trats2 board. Following in SoC devices have been enabled: - HDMI (HDMI signal encoder), - Mixer (video buffer scanout device), - I2C_5 bus (used for HDMI DDC) - I2C_8 bus (used for HDMI_PHY control). Based on previous work by: Tomasz StanislawskiSigned-off-by: Maciej Purski Reviewed-by: Andrzej Hajda --- arch/arm/boot/dts/exynos4412-trats2.dts | 111 1 file changed, 111 insertions(+) diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts index bceb919..d7f77a6 100644 --- a/arch/arm/boot/dts/exynos4412-trats2.dts +++ b/arch/arm/boot/dts/exynos4412-trats2.dts @@ -18,6 +18,7 @@ #include #include #include +#include / { model = "Samsung Trats 2 based on Exynos4412"; @@ -97,6 +98,34 @@ gpio = < 5 GPIO_ACTIVE_HIGH>; enable-active-high; }; + + vsil12: voltage-regulator-6 { + compatible = "regulator-fixed"; + regulator-name = "VSIL_1.2V"; + regulator-min-microvolt = <120>; + regulator-max-microvolt = <120>; + gpio = < 4 GPIO_ACTIVE_HIGH>; + enable-active-high; + vin-supply = <_reg>; + }; + + vcc33mhl: voltage-regulator-7 { + compatible = "regulator-fixed"; + regulator-name = "VCC_3.3_MHL"; + regulator-min-microvolt = <330>; + regulator-max-microvolt = <330>; + gpio = < 4 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; + + vcc18mhl: voltage-regulator-8 { + compatible = "regulator-fixed"; + regulator-name = "VCC_1.8_MHL"; + regulator-min-microvolt = <180>; + regulator-max-microvolt = <180>; + gpio = < 4 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; }; gpio-keys { @@ -229,6 +258,36 @@ }; }; + i2c-mhl { + compatible = "i2c-gpio"; + gpios = < 4 GPIO_ACTIVE_HIGH>, < 6 GPIO_ACTIVE_HIGH>; + i2c-gpio,delay-us = <100>; + #address-cells = <1>; + #size-cells = <0>; + + pinctrl-0 = <_mhl_bus>; + pinctrl-names = "default"; + status = "okay"; + + sii9234: hdmi-bridge@39 { + compatible = "sil,sii9234"; + avcc33-supply = <>; + iovcc18-supply = <>; + avcc12-supply = <>; + cvcc12-supply = <>; + reset-gpios = < 4 GPIO_ACTIVE_LOW>; + interrupt-parent = <>; + interrupts = <5 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x39>; + + port { + mhl_to_hdmi: endpoint { + remote-endpoint = <_to_mhl>; + }; + }; + }; + }; + camera: camera { pinctrl-0 = <_port_a_clk_active _port_b_clk_active>; pinctrl-names = "default"; @@ -501,6 +560,29 @@ status = "okay"; }; + { + hpd-gpios = < 7 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <_hpd>; + vdd-supply = <_reg>; + vdd_osc-supply = <_reg>; + vdd_pll-supply = <_reg>; + ddc = <_5>; + status = "okay"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + hdmi_to_mhl: endpoint { + remote-endpoint = <_to_hdmi>; + }; + }; + }; +}; + { vusb_d-supply = <_reg>; vusb_a-supply = <_reg>; @@ -579,6 +661,10 @@ }; }; +_5 { + status = "okay"; +}; + _7 { samsung,i2c-sda-delay = <100>; samsung,i2c-slave-addr = <0x10>; @@ -873,12 +959,20 @@ }; }; +_8 { + status = "okay"; +}; + { pinctrl-0 = <_bus>; pinctrl-names = "default"; status = "okay"; }; + { + status = "okay"; +}; + _0 { broken-cd; non-removable; @@ -904,6 +998,18 @@ pinctrl-names = "default"; pinctrl-0 = <>; + mhl_int: mhl-int { + samsung,pins = "gpf3-5"; + samsung,pin-pud = ; + }; + + i2c_mhl_bus: i2c-mhl-bus { + samsung,pins = "gpf0-4", "gpf0-6"; +
[PATCH 1/3] drm/dp: WARN about invalid/unknown link rates and bw codes
Falling back to the lowest value is likely the only thing we can do, but doing it silently seems like a bad thing to do. Catch it early and make loud noises. Cc: Alex DeucherCc: Thierry Reding Cc: Rob Clark Cc: Sean Paul Cc: Manasi Navare Cc: dri-devel@lists.freedesktop.org Signed-off-by: Jani Nikula --- drivers/gpu/drm/drm_dp_helper.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 08af8d6b844b..dca21b5a03ec 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -137,8 +137,10 @@ EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay); u8 drm_dp_link_rate_to_bw_code(int link_rate) { switch (link_rate) { - case 162000: default: + WARN(1, "unknown DP link rate %d, using %x\n", link_rate, +DP_LINK_BW_1_62); + case 162000: return DP_LINK_BW_1_62; case 27: return DP_LINK_BW_2_7; @@ -151,8 +153,9 @@ EXPORT_SYMBOL(drm_dp_link_rate_to_bw_code); int drm_dp_bw_code_to_link_rate(u8 link_bw) { switch (link_bw) { - case DP_LINK_BW_1_62: default: + WARN(1, "unknown DP link bw code %x, using 162000\n", link_bw); + case DP_LINK_BW_1_62: return 162000; case DP_LINK_BW_2_7: return 27; -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/dp: WARN about invalid/unknown link rates and bw codes
On Mon, Oct 09, 2017 at 12:29:57PM +0300, Jani Nikula wrote: > Falling back to the lowest value is likely the only thing we can do, but > doing it silently seems like a bad thing to do. Catch it early and make > loud noises. > > Cc: Alex Deucher> Cc: Thierry Reding > Cc: Rob Clark > Cc: Sean Paul > Cc: Manasi Navare > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/drm_dp_helper.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c > index 08af8d6b844b..dca21b5a03ec 100644 > --- a/drivers/gpu/drm/drm_dp_helper.c > +++ b/drivers/gpu/drm/drm_dp_helper.c > @@ -137,8 +137,10 @@ EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay); > u8 drm_dp_link_rate_to_bw_code(int link_rate) > { > switch (link_rate) { > - case 162000: > default: > + WARN(1, "unknown DP link rate %d, using %x\n", link_rate, > + DP_LINK_BW_1_62); > + case 162000: > return DP_LINK_BW_1_62; > case 27: > return DP_LINK_BW_2_7; > @@ -151,8 +153,9 @@ EXPORT_SYMBOL(drm_dp_link_rate_to_bw_code); > int drm_dp_bw_code_to_link_rate(u8 link_bw) > { > switch (link_bw) { > - case DP_LINK_BW_1_62: > default: > + WARN(1, "unknown DP link bw code %x, using 162000\n", link_bw); Nit: "DP link BW" because it is an abbreviation. Otherwise looks good: Reviewed-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm/vc4: remove bridge from driver internal structure
2017-10-02 11:34 GMT+02:00 Benjamin Gaignard: > With a call to drm_of_panel_bridge_remove() we could remove > the bridge without store it in vc4_dpi internal driver structure. + Eric to get his point of view on that > > Signed-off-by: Benjamin Gaignard > --- > drivers/gpu/drm/vc4/vc4_dpi.c | 17 ++--- > 1 file changed, 6 insertions(+), 11 deletions(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c > index 519cefe..72c9dbd 100644 > --- a/drivers/gpu/drm/vc4/vc4_dpi.c > +++ b/drivers/gpu/drm/vc4/vc4_dpi.c > @@ -97,8 +97,6 @@ struct vc4_dpi { > > struct drm_encoder *encoder; > struct drm_connector *connector; > - struct drm_bridge *bridge; > - bool is_panel_bridge; > > void __iomem *regs; > > @@ -251,10 +249,11 @@ static int vc4_dpi_init_bridge(struct vc4_dpi *dpi) > { > struct device *dev = >pdev->dev; > struct drm_panel *panel; > + struct drm_bridge *bridge; > int ret; > > ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0, > - , >bridge); > + , ); > if (ret) { > /* If nothing was connected in the DT, that's not an > * error. > @@ -265,13 +264,10 @@ static int vc4_dpi_init_bridge(struct vc4_dpi *dpi) > return ret; > } > > - if (panel) { > - dpi->bridge = drm_panel_bridge_add(panel, > - DRM_MODE_CONNECTOR_DPI); > - dpi->is_panel_bridge = true; > - } > + if (panel) > + bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DPI); > > - return drm_bridge_attach(dpi->encoder, dpi->bridge, NULL); > + return drm_bridge_attach(dpi->encoder, bridge, NULL); > } > > static int vc4_dpi_bind(struct device *dev, struct device *master, void > *data) > @@ -352,8 +348,7 @@ static void vc4_dpi_unbind(struct device *dev, struct > device *master, > struct vc4_dev *vc4 = to_vc4_dev(drm); > struct vc4_dpi *dpi = dev_get_drvdata(dev); > > - if (dpi->is_panel_bridge) > - drm_panel_bridge_remove(dpi->bridge); > + drm_of_panel_bridge_remove(dev->of_node, 0, 0); > > drm_encoder_cleanup(dpi->encoder); > > -- > 2.7.4 > -- Benjamin Gaignard Graphic Study Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [dim PATCH] dim: allow a space separated list of URLs for each repo in drm_tip_repos
Hey, On 9 October 2017 at 11:30, Jani Nikulawrote: > On Tue, 03 Oct 2017, Jani Nikula wrote: >> I merged this last week with Daniel's IRC ack. We'll need to give people >> a little bit of time before updating nightly.conf. Sorry for the >> inconvenience in the mean time. > > Andrzej, all the bits and pieces for this have been pushed, so https:// > should just work for all repos *except* Dave's drm tree. I don't know > why, but [1] doesn't advertize https for it. Probably because it's not linked in from his public_html? He'd need to do that, and also make sure that git-update-server-info was run in a hook somewhere too. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hwc] platformdrmgeneric: get the gralloc usage directly from the handle
Hey Rob, I tested the patch on the imx6/etnaviv platform, and it all works. So I pushed the patch with t-b && r-b tags attached. Rob. On Fri, 2017-10-06 at 17:20 -0500, Rob Herring wrote: > There's no point in using a gralloc perform() op to retrieve the > usage as > it is already stored in the handle like width, height, format, etc. > So just > copy it to the hwc_drm_bo_t and get it directly. > > Signed-off-by: Rob Herring> --- > I was a bit quick on the trigger with the previous patch. This one is > a > dependency for it. > > drmhwcgralloc.h| 1 + > hwcutils.cpp | 8 ++-- > platformdrmgeneric.cpp | 1 + > 3 files changed, 4 insertions(+), 6 deletions(-) > > diff --git a/drmhwcgralloc.h b/drmhwcgralloc.h > index 765c8979d2df..c4a42eaf1c54 100644 > --- a/drmhwcgralloc.h > +++ b/drmhwcgralloc.h > @@ -56,6 +56,7 @@ typedef struct hwc_drm_bo { > uint32_t width; > uint32_t height; > uint32_t format; /* DRM_FORMAT_* from drm_fourcc.h */ > + uint32_t usage; > uint32_t pitches[4]; > uint32_t offsets[4]; > uint32_t gem_handles[4]; > diff --git a/hwcutils.cpp b/hwcutils.cpp > index 00915757469e..53a7d82889b8 100644 > --- a/hwcutils.cpp > +++ b/hwcutils.cpp > @@ -159,12 +159,8 @@ int DrmHwcLayer::ImportBuffer(Importer > *importer, > if (ret) > return ret; > > - ret = gralloc->perform(gralloc, GRALLOC_MODULE_PERFORM_GET_USAGE, > - handle.get(), _buffer_usage); > - if (ret) { > -ALOGE("Failed to get usage for buffer %p (%d)", handle.get(), > ret); > -return ret; > - } > + gralloc_buffer_usage = buffer.operator->()->usage; > + > return 0; > } > > diff --git a/platformdrmgeneric.cpp b/platformdrmgeneric.cpp > index aa3d0faee7c0..741d42b6ac33 100644 > --- a/platformdrmgeneric.cpp > +++ b/platformdrmgeneric.cpp > @@ -116,6 +116,7 @@ int > DrmGenericImporter::ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t > *bo) { > bo->width = gr_handle->width; > bo->height = gr_handle->height; > bo->format = ConvertHalFormatToDrm(gr_handle->format); > + bo->usage = gr_handle->usage; > bo->pitches[0] = gr_handle->stride; > bo->gem_handles[0] = gem_handle; > bo->offsets[0] = 0; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/exynos: Fix potential NULL pointer dereference in suspend/resume paths
The patch 6e8edf8a7d8d: "drm/exynos: Fix suspend/resume support" introduced a new code in suspend/resume paths. However it unconditionally dereference drm_dev pointer, which might be NULL if suspend/resume happens before Exynos DRM driver components bind. This patch fixes this issue. Reported-by: Dan CarpenterFixes: 6e8edf8a7d8d "drm/exynos: Fix suspend/resume support" Signed-off-by: Marek Szyprowski --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index e651a58c18cf..aa770bb0153c 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -168,11 +168,13 @@ static struct drm_driver exynos_drm_driver = { static int exynos_drm_suspend(struct device *dev) { struct drm_device *drm_dev = dev_get_drvdata(dev); - struct exynos_drm_private *private = drm_dev->dev_private; + struct exynos_drm_private *private; if (pm_runtime_suspended(dev) || !drm_dev) return 0; + private = drm_dev->dev_private; + drm_kms_helper_poll_disable(drm_dev); exynos_drm_fbdev_suspend(drm_dev); private->suspend_state = drm_atomic_helper_suspend(drm_dev); @@ -188,11 +190,12 @@ static int exynos_drm_suspend(struct device *dev) static int exynos_drm_resume(struct device *dev) { struct drm_device *drm_dev = dev_get_drvdata(dev); - struct exynos_drm_private *private = drm_dev->dev_private; + struct exynos_drm_private *private; if (pm_runtime_suspended(dev) || !drm_dev) return 0; + private = drm_dev->dev_private; drm_atomic_helper_resume(drm_dev, private->suspend_state); exynos_drm_fbdev_resume(drm_dev); drm_kms_helper_poll_enable(drm_dev); -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Fwd: linux video documentation ?
On Fri, Oct 06, 2017 at 01:44:48PM -0500, Brad Walker wrote: > I noticed this email address is listed as the relevant area for the > Documentation/devicetree/bindings/video/ directory in the Linux kernel. I > have a question about this. > > I noticed the Documentation/devicetree/bindings/video/ is no longer in the > Linux kernel repo. It was in release 4.3.6 but got dropped in release > v4.4-rc1. > > Is there a reason for this? I ask because I am using the > "simple-framebuffer" and wanted to possibly make some improvements to the > documentation. video/ moved to display/, it's all still there. -Daniel > > Thanks for any insight you can provide. > > -brad w. > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/etnaviv: reduce reset delay
After reset assertion, we only have to wait for the reset signals to propagate through the GPU before deasserting the reset again. A few hundred clock cycles should be more than enough. Replace the msleep(1), which can actually take about 30 ms on i.MX6Q in some configurations, with an usleep_range of a few microseconds. If the delay was too short, the FE would not be idle afterwards, and the reset would be retried. Signed-off-by: Philipp Zabel--- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c index fc9a6a83dfc77..9f7999552cc31 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c @@ -461,7 +461,7 @@ static int etnaviv_hw_reset(struct etnaviv_gpu *gpu) gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, control); /* wait for reset. */ - msleep(1); + usleep_range(10, 20); /* reset soft reset bit. */ control &= ~VIVS_HI_CLOCK_CONTROL_SOFT_RESET; -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/etnaviv: remove unnecessary clock stabilization delay
There is no reason to wait for clock stabilization here, as the clock framework guarantees that PLL clock sources are stable before clk_enable returns. Signed-off-by: Philipp Zabel--- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c index 9f7999552cc31..561a955ee4022 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c @@ -449,9 +449,6 @@ static int etnaviv_hw_reset(struct etnaviv_gpu *gpu) control = gpu_read(gpu, VIVS_HI_CLOCK_CONTROL); - /* Wait for stable clock. Vivante's code waited for 1ms */ - usleep_range(1000, 1); - /* isolate the GPU. */ control |= VIVS_HI_CLOCK_CONTROL_ISOLATE_GPU; gpu_write(gpu, VIVS_HI_CLOCK_CONTROL, control); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 1/4] dt-bindings: add bindings for USB physical connector
On 06.10.2017 19:23, Rob Herring wrote: > On Fri, Oct 6, 2017 at 6:10 AM, Andrzej Hajdawrote: >> Hi Rob, >> >> Thanks for review. >> >> On 06.10.2017 01:12, Rob Herring wrote: >>> On Thu, Sep 28, 2017 at 03:07:27PM +0200, Andrzej Hajda wrote: These bindings allows to describe most known standard USB connectors and it should be possible to extend it if necessary. USB connectors, beside USB can be used to route other protocols, for example UART, Audio, MHL. In such case every device passing data through the connector should have appropriate graph bindings. >>> Yay! >>> Signed-off-by: Andrzej Hajda --- There are few things for discussion (IMO): 1. vendor specific connectors, I have added them here, but maybe better is to place them in separate files. >>> I'd worry about the standard connectors first, but probably good to have >>> an idea of how vendor connectors need to be extended. >>> 2. physical connector description - I have split it to three properties: type(a,b,ab,c), max-mode(ls,fs,hs,ss,ss+), size(mini,micro,powered). This tripled is able to describe all USB-standard connectors, but there are also impossible combinations, for example(c, *, micro). Maybe better would be to just enumerate all possible connectors in include file. >>> We did "type" for hdmi-connector, but I think I'd really prefer >>> compatible be used to distinguish as least where it may matter to s/w. >>> In the HDMI case, they all are pretty much the same, just different >>> physical size. >> I guess that from S/W point of view only matters: >> - which IP is connected to which part of the connector, and this can be >> handled by port node(s), >> - Type: A, B, C >> - probably maximal supported speed of the connector - for example SS+ >> connectors have the same wires but different electrical characteristics >> than SS as I understand, >> >> With this in mind maybe we can drop 'type' and introduce following >> compatibles: >> - usb-a-connector, >> - usb-b-connector, >> - usb-c-connector. >> Encoding other properties in compatible would explode their number, so I >> would prefer to avoid it. >> I would leave other props: >> max-speed: hs, ss, ss+, >> (optional)size: micro, mini >> >> I would drop also unpopular/obsolete variants: type-ab, powered, they >> can be added later if necessary. >> >> Just for reference, list of connectors defined by USB (>= 2) specifications: >> 1. USB 2.0 (with later amendments): >> - Standard-A plug and receptacle >> - Standard-B plug and receptacle >> - Mini-B plug and receptacle >> - Micro-B plug and receptacle >> - Micro-AB receptacle >> - Micro-A plug >> 2. USB 3.0: >> - USB 3.0 Standard-A plug and receptacle >> - USB 3.0 Standard-B plug and receptacle >> - USB 3.0 Powered-B plug and receptacle >> - USB 3.0 Micro-B plug and receptacle >> - USB 3.0 Micro-A plug >> - USB 3.0 Micro-AB receptacle >> 3. USB 3.1: >> - Enhanced SuperSpeed Standard-A plug and receptacle >> - Enhanced SuperSpeed Standard-B plug and receptacle >> - Enhanced SuperSpeed Micro-B plug and receptacle >> - Enhanced SuperSpeed Micro-A plug >> - Enhanced SuperSpeed Micro-AB receptacle >> 4. USB-C (release 1.3): >> - USB Full-Featured Type-C receptacle >> - USB 2.0 Type-C receptacle >> - USB Full-Featured Type-C plug >> - USB 2.0 Type-C plug >> - USB Type-C Power-Only plug >> 3. Numbering of port/remote nodes, currently only 0 is assigned for Interface Controller. Maybe other functions should be also assigned: HS, SS, CC, SBU, ... whatever. Maybe functions should be described as an additional property of remote node? >>> child of the controller is also an option. There's already prec >> Shall we support both solutions or just make one mandatory? > Oops, I was just going to say for display, there's already precedent > that ports are used. So that means at least SS should just be > described with ports. Then HS probably should be a port too just to be > symmetrical. > > The connector being a child of the USB-PD (or other controller chip) > is probably the only thing that makes sense. I guess the question is > whether there are cases where that doesn't make sense. > --- .../bindings/connector/usb-connector.txt | 49 ++ 1 file changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/connector/usb-connector.txt diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt new file mode 100644 index ..f3a4e85122d5 --- /dev/null +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt @@ -0,0 +1,49 @@ +USB Connector += + +Required properties: +- compatible: "usb-connector" + connectors with vendor specific
Re: [PATCH v5 1/2] staging: ion: simplify ioctl args checking function
2017-09-27 15:20 GMT+02:00 Benjamin Gaignard: > Make arguments checking more easy to read. > Hi Laura, Even if we don't have found a solution for the second patch I believe this one could be useful. May I ask you your point of view on those few lines ? Benjamin > Signed-off-by: Benjamin Gaignard > --- > drivers/staging/android/ion/ion-ioctl.c | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) > > diff --git a/drivers/staging/android/ion/ion-ioctl.c > b/drivers/staging/android/ion/ion-ioctl.c > index d9f8b14..e26b786 100644 > --- a/drivers/staging/android/ion/ion-ioctl.c > +++ b/drivers/staging/android/ion/ion-ioctl.c > @@ -27,19 +27,18 @@ union ion_ioctl_arg { > > static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg) > { > - int ret = 0; > - > switch (cmd) { > case ION_IOC_HEAP_QUERY: > - ret = arg->query.reserved0 != 0; > - ret |= arg->query.reserved1 != 0; > - ret |= arg->query.reserved2 != 0; > + if (arg->query.reserved0 || > + arg->query.reserved1 || > + arg->query.reserved2) > + return -EINVAL; > break; > default: > break; > } > > - return ret ? -EINVAL : 0; > + return 0; > } > > /* fix up the cases where the ioctl direction bits are incorrect */ > -- > 2.7.4 > -- Benjamin Gaignard Graphic Study Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/atomic: Unref duplicated drm_atomic_state in drm_atomic_helper_resume()
Op 09-10-17 om 08:46 schreef Jeffy Chen: > Kmemleak reported memory leak after suspend and resume: > unreferenced object 0xffc0e31d8880 (size 128): > comm "bash", pid 181, jiffies 4294763583 (age 24.694s) > hex dump (first 32 bytes): > 01 00 00 00 00 00 00 00 00 20 a2 eb c0 ff ff ff . .. > 01 00 00 00 00 00 00 00 80 87 1d e3 c0 ff ff ff > backtrace: > [] __save_stack_trace+0x48/0x6c > [] create_object+0x138/0x254 > [] kmemleak_alloc+0x58/0x8c > [] kmem_cache_alloc_trace+0x188/0x254 > [] drm_atomic_state_alloc+0x3c/0x88 > [] drm_atomic_helper_duplicate_state+0x28/0x158 > [] drm_atomic_helper_suspend+0x5c/0xf0 > > Problem here is that we are duplicating the drm_atomic_state in > drm_atomic_helper_suspend(), but not unreference it in the resume path. > > Fixes: 1494276000db ("drm/atomic-helper: Implement subsystem-level > suspend/resume") > Signed-off-by: Jeffy Chen> --- > > Changes in v2: > Unref duplicated drm_atomic_state in drm_atomic_helper_resume() instead > of specific drivers. > > drivers/gpu/drm/drm_atomic_helper.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index 01c34bc5b5b0..4a262380c631 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -3052,6 +3052,7 @@ int drm_atomic_helper_resume(struct drm_device *dev, > drm_modeset_backoff(); > } > > + drm_atomic_state_put(state); > drm_modeset_drop_locks(); > drm_modeset_acquire_fini(); > Reviewed-by: Maarten Lankhorst Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state") Cc: # v4.10+ and pushed, thanks for finding it. :) The bug is probably older than that commit, but only happened on failure paths before. If resume fails we probably have bigger issues than leaking some memory. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103142] R600g+sb: optimizer apparently stuck in an endless loop
https://bugs.freedesktop.org/show_bug.cgi?id=103142 Gert Wollnychanged: What|Removed |Added Attachment #134738|0 |1 is obsolete|| --- Comment #1 from Gert Wollny --- Created attachment 134759 --> https://bugs.freedesktop.org/attachment.cgi?id=134759=edit Shader triggering the endless loop I think the last log was not correct, i.e. it was not the right shader. This new log shows different error messages. The the endless loop is happening in "post_scheduler". I've run the code with R600_DEBUG=nocw,sbdump in addition to the PSC_DUMP. I've also tried R600_DEBUG=sbsafemath, but to no avail. Snip of the log: # REGMAP : current_AR: R42.x.199||@R1.x current_AR is R42.x.199||@R1.x trying to use R41.x.235||@R0.z current_AR is R42.x.199||@R1.x trying to use R42.x.200@R10.w current_AR is R42.x.199||@R1.x trying to use R44.x.77@R7.z !! interf slot: 2 : ADD t116||@R2.z, A100.y[R41.x.235||@R0.z]_763F@R8.y, A100.y[R43.x.126@R2.z]_764F@R8.y rels: A100.y[R41.x.235||@R0.z]_763F@R8.y : <= R100.y.1F, R101.y.1F, R102.y.1F, R103.y.1F, R104.y.1F, R105.y.1F, R106.y.1F, R107.y.1F, R108.y.1F, R109.y.1F rels: A100.y[R43.x.126@R2.z]_764F@R8.y : <= R100.y.1F, R101.y.1F, R102.y.1F, R103.y.1F, R104.y.1F, R105.y.1F, R106.y.1F, R107.y.1F, R108.y.1F, R109.y.1F !! interf slot: 3 : MOV R43.z.49||@R10.w, A100.y[R42.x.200@R10.w]_759F@R8.y rels: A100.y[R42.x.200@R10.w]_759F@R8.y : <= R100.y.1F, R101.y.1F, R102.y.1F, R103.y.1F, R104.y.1F, R105.y.1F, R106.y.1F, R107.y.1F, R108.y.1F, R109.y.1F !! interf slot: 4 : MOV R43.y.48||@R12.z, A100.x[R44.x.77@R7.z]_755F@R8.x rels: A100.x[R44.x.77@R7.z]_755F@R8.x : <= R100.x.1F, R101.x.1F, R102.x.1F, R103.x.1F, R104.x.1F, R105.x.1F, R106.x.1F, R107.x.1F, R108.x.1F, R109.x.1F ci: discarding slots 28 discard_slots : packed_ops : 0 discarding slot 2 : ADD t116||@R2.z,A100.y[R41.x.235||@R0.z]_763F@R8.y, A100.y[R43.x.126@R2.z]_764F@R8.y rels: A100.y[R41.x.235||@R0.z]_763F@R8.y : <= R100.y.1F, R101.y.1F, R102.y.1F, R103.y.1F, R104.y.1F, R105.y.1F, R106.y.1F, R107.y.1F, R108.y.1F, R109.y.1F rels: A100.y[R43.x.126@R2.z]_764F@R8.y : <= R100.y.1F, R101.y.1F, R102.y.1F, R103.y.1F, R104.y.1F, R105.y.1F, R106.y.1F, R107.y.1F, R108.y.1F, R109.y.1F discarding slot 3 : MOV R43.z.49||@R10.w, A100.y[R42.x.200@R10.w]_759F@R8.y rels: A100.y[R42.x.200@R10.w]_759F@R8.y : <= R100.y.1F, R101.y.1F, R102.y.1F, R103.y.1F, R104.y.1F, R105.y.1F, R106.y.1F, R107.y.1F, R108.y.1F, R109.y.1F discarding slot 4 : MOV R43.y.48||@R12.z, A100.x[R44.x.77@R7.z]_755F@R8.x rels: A100.x[R44.x.77@R7.z]_755F@R8.x : <= R100.x.1F, R101.x.1F, R102.x.1F, R103.x.1F, R104.x.1F, R105.x.1F, R106.x.1F, R107.x.1F, R108.x.1F, R109.x.1F check_interferences: after: # REGMAP : current_AR: R42.x.199||@R1.x update_local_interferences : [R26.x.7F R26.y.7F R26.z.7F R27.x.7F R27.y.7F R27.z.7F R28.x.7F R28.y.7F R28.z.7F R100.x.1F R101.x.1F R100.y.1F R101.y.1F R102.x.1F R102.y.1F R103.x.1F R104.x.1F R103.y.1F R104.y.1F R105.x.1F R105.y.1F R106.x.1F R107.x.1F R106.y.1F R107.y.1F R108.x.1F R108.y.1F R109.x.1F R109.y.1F R4.x.410||@R6.w R41.x.194||@R4.y R42.x.184||@R2.y R43.x.112||@R12.y R43.y.43||@R14.w R41.x.202||@R0.w R42.x.188||@R1.z R43.x.114||@R13.w R43.y.44||@R7.w R4.x.423||@R5.w R41.x.213||@R2.w R42.x.195||@R3.y R43.x.119||@R17.w R43.y.48||@R12.z R43.z.48||@R10.w R41.x.221||@R0.y R42.x.199||@R1.x R44.x.78||@R3.x R43.z.49||@R10.w R4.x.436||@R4.w R40.x.206||@R1.y R41.x.231||@R1.w R42.x.206||@R16.z R42.y.71||@R10.z R42.z.71||@R8.w R40.x.214||@R0.x R41.x.235||@R0.z R42.x.208||@R9.z R42.y.72||@R3.z R42.z.72||@R8.w t111||@R8.z t112||@R13.z t113||@R7.z t114||@R3.x t115||@R3.w t116||@R2.z ] p_a_g: MOV R42.x.206||@R16.z,A100.x[R41.x.231||@R1.w]_760F@R8.x rels: A100.x[R41.x.231||@R1.w]_760F@R8.x : <= R100.x.1F, R101.x.1F, R102.x.1F, R103.x.1F, R104.x.1F, R105.x.1F, R106.x.1F, R107.x.1F, R108.x.1F, R109.x.1F slot: 2 current group: slot 2 : MOV R42.x.206||@R16.z,A100.x[R41.x.231||@R1.w]_760F@R8.x rels: A100.x[R41.x.231||@R1.w]_760F@R8.x : <= R100.x.1F, R101.x.1F, R102.x.1F, R103.x.1F, R104.x.1F, R105.x.1F, R106.x.1F, R107.x.1F, R108.x.1F, R109.x.1F p_a_g: MOV R43.z.48||@R10.w,A100.x[R42.x.196@R11.z]_756F@R8.x rels: A100.x[R42.x.196@R11.z]_756F@R8.x : <= R100.x.1F,
[PATCH v3 3/4] drm/rockchip: Add support for Rockchip Soc RGB output interface
Some Rockchip CRTCs, like rv1108, can directly output parallel and serial RGB data to panel or conversion chip, so we add this driver to probe encoder and connector. Signed-off-by: Sandy Huang--- Changes in v3: update for rgb-mode move to panel node. Changes in v2: 1. add error log when probe failed; 2. update name_to_output_mode() according to sean's suggest; 3. Fix uninitialized use of ret. drivers/gpu/drm/rockchip/Kconfig| 9 + drivers/gpu/drm/rockchip/Makefile | 1 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 + drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 + drivers/gpu/drm/rockchip/rockchip_rgb.c | 343 5 files changed, 356 insertions(+) create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig index 0c31f0a..85c7cc5 100644 --- a/drivers/gpu/drm/rockchip/Kconfig +++ b/drivers/gpu/drm/rockchip/Kconfig @@ -8,6 +8,7 @@ config DRM_ROCKCHIP select DRM_ANALOGIX_DP if ROCKCHIP_ANALOGIX_DP select DRM_DW_HDMI if ROCKCHIP_DW_HDMI select DRM_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI + select DRM_RGB if ROCKCHIP_RGB select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC help Choose this option if you have a Rockchip soc chipset. @@ -65,4 +66,12 @@ config ROCKCHIP_LVDS Rockchip rk3288 SoC has LVDS TX Controller can be used, and it support LVDS, rgb, dual LVDS output mode. say Y to enable its driver. + +config ROCKCHIP_RGB + bool "Rockchip RGB support" + help + Choose this option to enable support for Rockchip RGB output. + Some Rockchip CRTCs, like rv1108, can directly output parallel + and serial RGB format to panel or connect to a conversion chip. + say Y to enable its driver. endif diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile index a881d2c..f32a17f 100644 --- a/drivers/gpu/drm/rockchip/Makefile +++ b/drivers/gpu/drm/rockchip/Makefile @@ -13,5 +13,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o +rockchipdrm-$(CONFIG_ROCKCHIP_RGB) += rockchip_rgb.o obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index 76d63de..265597c 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -459,6 +459,8 @@ static int __init rockchip_drm_init(void) CONFIG_ROCKCHIP_LVDS); ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver, CONFIG_ROCKCHIP_ANALOGIX_DP); + ADD_ROCKCHIP_SUB_DRIVER(rockchip_rgb_driver, + CONFIG_ROCKCHIP_RGB); ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP); ADD_ROCKCHIP_SUB_DRIVER(dw_hdmi_rockchip_pltfm_driver, CONFIG_ROCKCHIP_DW_HDMI); diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h index 498dfbc..6b0ec7e 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h @@ -70,5 +70,6 @@ extern struct platform_driver dw_mipi_dsi_driver; extern struct platform_driver inno_hdmi_driver; extern struct platform_driver rockchip_dp_driver; extern struct platform_driver rockchip_lvds_driver; +extern struct platform_driver rockchip_rgb_driver; extern struct platform_driver vop_platform_driver; #endif /* _ROCKCHIP_DRM_DRV_H_ */ diff --git a/drivers/gpu/drm/rockchip/rockchip_rgb.c b/drivers/gpu/drm/rockchip/rockchip_rgb.c new file mode 100644 index 000..6227ed7 --- /dev/null +++ b/drivers/gpu/drm/rockchip/rockchip_rgb.c @@ -0,0 +1,343 @@ +/* + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd + * Author: + * Sandy Huang + * + * This software is licensed under the terms of the GNU General Public + * License version 2, as published by the Free Software Foundation, and + * may be copied, distributed, and modified under those terms. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include +#include +#include +#include +#include + +#include +#include + +#include "rockchip_drm_drv.h" +#include "rockchip_drm_vop.h" + +#define connector_to_rgb(c) container_of(c, struct rockchip_rgb, connector) +#define encoder_to_rgb(c) container_of(c, struct rockchip_rgb, encoder) + +struct rockchip_rgb { + struct device *dev; +
[PATCH v3 4/4] drm/rockchip: vop: Add more RGB output interface type
This patch add serial RGB output interface for rockchip vop, the more info about serial RGB output interface described at the following file: Documentation/devicetree/bindings/display/panel/panel-rgb.txt Signed-off-by: Sandy Huang--- Changes in v3: None Changes in v2: None drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h index 56bbd2e..59a01c3 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h @@ -209,6 +209,8 @@ struct vop_data { #define ROCKCHIP_OUT_MODE_P888 0 #define ROCKCHIP_OUT_MODE_P666 1 #define ROCKCHIP_OUT_MODE_P565 2 +#define ROCKCHIP_OUT_MODE_S888 8 +#define ROCKCHIP_OUT_MODE_S888_DUMMY 12 /* for use special outface */ #define ROCKCHIP_OUT_MODE_ 15 -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] dt-bindings: Add document for rockchip RGB output interface
Hi rob, Thanks for your reply. 在 2017/10/4 5:56, Rob Herring 写道: On Fri, Sep 22, 2017 at 11:00:26AM +0800, Sandy Huang wrote: This path add support rv1108 rgb output interface driver. Signed-off-by: Sandy Huang--- Changes in v2: 1. rename rockchip,rgb-mode to rgb-mode; You can't just drop the vendor. This needs to be documented in a common place that others will find and use. See panel-common.txt or panel-dpi.txt. Alternatively, you could just drop it and let the panel compatible imply what the mode is. ok, get it, i will move the rgb-mode to panel and describe it at panel-rgb.txt. the patches will be send soon later. 2. delete reg for signle endpoint; .../bindings/display/rockchip/rockchip-rgb.txt | 78 ++ 1 file changed, 78 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt new file mode 100644 index 000..86bd1ce --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt @@ -0,0 +1,78 @@ +Rockchip RV1108 RGB interface + + +Required properties: +- compatible: matching the soc type: + - "rockchip,rv1108-rgb"; + +Optional properties: +- pinctrl-names: must contain a "lcdc" entry. +- pinctrl-0: pin control group to be used for this interface. + +Required nodes: +- rgb-mode: should be "p888", "p666", "p565", "s888", "s888-dummy" + - p888: output r8-g8-b8 at each dclk cycle for per-pixel + - p666: output r6-g6-b6 at each dclk cycle for per-pixel + - p565: output r5-g6-b5 at each dclk cycle for per-pixel + - s888: output r8-g8-b8 in three dclk cycle for per-pixel + - s888-dmmy: output r8-g8-b8-dummy in four dclk cycle for per-pixel + +The rgb has two video ports described by: + Documentation/devicetree/bindings/media/video-interfaces.txt +Their connections are modeled using the OF graph bindings specified in + Documentation/devicetree/bindings/graph.txt. + +- video port 0 for the VOP input, the remote endpoint maybe vopb/vopl/vop +- video port 1 for either a panel or subsequent encoder + +the panel described by: + Documentation/devicetree/bindings/display/panel/simple-panel.txt +Panel other required properties: +- ports for remote rgb output. + +Example: + +panel: panel { + compatible = "auo,b101ean01"; + enable-gpios = < 21 GPIO_ACTIVE_HIGH>; + + ports { + panel_in_rgb: endpoint { + remote-endpoint = <_out_panel>; + }; + }; +}; + +For Rockchip RV1108: + + rgb: rgb { + compatible = "rockchip,rv1108-rgb"; + pinctrl-names = "lcdc"; + pinctrl-0 = <_ctl>; + rgb-mode = "p888"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + rgb_in: port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + rgb_in_vop: endpoint { + remote-endpoint = <_out_rgb>; + }; + }; + + rgb_out: port@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + rgb_out_panel: endpoint { + remote-endpoint = <_in_rgb>; + }; + }; + }; + }; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/4] devicetree/bindings: display: Add document for rockchip RGB output
This path add support rv1108 rgb output interface driver. Signed-off-by: Sandy Huang--- Changes in v3: move rgb-mode to panel node which describe at: Documentation/devicetree/bindings/display/panel/panel-rgb.txt Changes in v2: 1. rename rockchip,rgb-mode to rgb-mode; 2. delete reg for signle endpoint; .../bindings/display/rockchip/rockchip-rgb.txt | 72 ++ 1 file changed, 72 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt new file mode 100644 index 000..d91a7bf --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt @@ -0,0 +1,72 @@ +Rockchip RV1108 RGB interface + + +Required properties: +- compatible: matching the soc type: + - "rockchip,rv1108-rgb"; + +Optional properties: +- pinctrl-names: must contain a "lcdc" entry. +- pinctrl-0: pin control group to be used for this interface. + +The rgb has two video ports described by: + Documentation/devicetree/bindings/media/video-interfaces.txt +Their connections are modeled using the OF graph bindings specified in + Documentation/devicetree/bindings/graph.txt. + +- video port 0 for the VOP input, the remote endpoint maybe vopb/vopl/vop +- video port 1 for either a panel or subsequent encoder + +the panel described by: + Documentation/devicetree/bindings/display/panel/simple-panel.txt +rgb-mode nodes described by: + Documentation/devicetree/bindings/display/panel/panel-rgb.txt +Panel other required properties: +- ports for remote rgb output. + +Example: + +panel: panel { + compatible = "auo,b101ean01"; + enable-gpios = < 21 GPIO_ACTIVE_HIGH>; + rgb-mode = "p888"; + + ports { + panel_in_rgb: endpoint { + remote-endpoint = <_out_panel>; + }; + }; +}; + +For Rockchip RV1108: + + rgb: rgb { + compatible = "rockchip,rv1108-rgb"; + pinctrl-names = "lcdc"; + pinctrl-0 = <_ctl>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + rgb_in: port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + rgb_in_vop: endpoint { + remote-endpoint = <_out_rgb>; + }; + }; + + rgb_out: port@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + rgb_out_panel: endpoint { + remote-endpoint = <_in_rgb>; + }; + }; + }; + }; -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] devicetree/bindings: display: Add doucument for RGB panels
Describe the panel property rgb-mode for parallel and serial RGB output interface, include the connection relations for each mode. Signed-off-by: Sandy Huang--- .../bindings/display/panel/panel-rgb.txt | 116 + 1 file changed, 116 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/panel-rgb.txt diff --git a/Documentation/devicetree/bindings/display/panel/panel-rgb.txt b/Documentation/devicetree/bindings/display/panel/panel-rgb.txt new file mode 100644 index 000..0c5b054 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-rgb.txt @@ -0,0 +1,116 @@ +RGB Display Panel +== + +This describe the panel property rgb-mode for parallel and serial +RGB output interface. rgb-mode should be "p888", "p666", "p565", "s888" +and "s888-dummy", the following describe the connection relations. + +p888 mode: + ___ ___ ___ ___ ___ ___ ___ +dclk__/ \___/ \___/ \___/ \___/ \___/ \___/ \___ + __ __ __ __ __ __ __ +DATA23 ><__R7__><__R7__><__R7__><__R7__><__R7__><__R7__><__R7__>< +DATA22 ><__R6__><__R6__><__R6__><__R6__><__R6__><__R6__><__R6__>< +DATA21 ><__R5__><__R5__><__R5__><__R5__><__R5__><__R5__><__R5__>< +DATA20 ><__R4__><__R4__><__R4__><__R4__><__R4__><__R4__><__R4__>< +DATA19 ><__R3__><__R3__><__R3__><__R3__><__R3__><__R3__><__R3__>< +DATA18 ><__R2__><__R2__><__R2__><__R2__><__R2__><__R2__><__R2__>< +DATA17 ><__R1__><__R1__><__R1__><__R1__><__R1__><__R1__><__R1__>< +DATA16 ><__R0__><__R0__><__R0__><__R0__><__R0__><__R0__><__R0__>< + __ __ __ __ __ __ __ +DATA15 ><__G7__><__G7__><__G7__><__G7__><__G7__><__G7__><__G7__>< +DATA14 ><__G6__><__G6__><__G6__><__G6__><__G6__><__G6__><__G6__>< +DATA13 ><__G5__><__G5__><__G5__><__G5__><__G5__><__G5__><__G5__>< +DATA12 ><__G4__><__G4__><__G4__><__G4__><__G4__><__G4__><__G4__>< +DATA11 ><__G3__><__G3__><__G3__><__G3__><__G3__><__G3__><__G3__>< +DATA10 ><__G2__><__G2__><__G2__><__G2__><__G2__><__G2__><__G2__>< +DATA9 ><__G1__><__G1__><__G1__><__G1__><__G1__><__G1__><__G1__>< +DATA8 ><__G0__><__G0__><__G0__><__G0__><__G0__><__G0__><__G0__>< + __ __ __ __ __ __ __ +DATA7 ><__B7__><__B7__><__B7__><__B7__><__B7__><__B7__><__B7__>< +DATA6 ><__B6__><__B6__><__B6__><__B6__><__B6__><__B6__><__B6__>< +DATA5 ><__B5__><__B5__><__B5__><__B5__><__B5__><__B5__><__B5__>< +DATA4 ><__B4__><__B4__><__B4__><__B4__><__B4__><__B4__><__B4__>< +DATA3 ><__B3__><__B3__><__B3__><__B3__><__B3__><__B3__><__B3__>< +DATA2 ><__B2__><__B2__><__B2__><__B2__><__B2__><__B2__><__B2__>< +DATA1 ><__B1__><__B1__><__B1__><__B1__><__B1__><__B1__><__B1__>< +DATA0 ><__B0__><__B0__><__B0__><__B0__><__B0__><__B0__><__B0__>< +pixel | n | n+1 | n+3 | n+4 | n+5 | n+6 | n+7 | + +p666 mode: + ___ ___ ___ ___ ___ ___ ___ +dclk__/ \___/ \___/ \___/ \___/ \___/ \___/ \___ + __ __ __ __ __ __ __ +DATA17 ><__R5__><__R5__><__R5__><__R5__><__R5__><__R5__><__R5__>< +DATA16 ><__R4__><__R4__><__R4__><__R4__><__R4__><__R4__><__R4__>< +DATA15 ><__R3__><__R3__><__R3__><__R3__><__R3__><__R3__><__R3__>< +DATA14 ><__R2__><__R2__><__R2__><__R2__><__R2__><__R2__><__R2__>< +DATA13 ><__R1__><__R1__><__R1__><__R1__><__R1__><__R1__><__R1__>< +DATA12 ><__R0__><__R0__><__R0__><__R0__><__R0__><__R0__><__R0__>< + __ __ __ __ __ __ __ +DATA11 ><__G5__><__G5__><__G5__><__G5__><__G5__><__G5__><__G5__>< +DATA10 ><__G4__><__G4__><__G4__><__G4__><__G4__><__G4__><__G4__>< +DATA9 ><__G3__><__G3__><__G3__><__G3__><__G3__><__G3__><__G3__>< +DATA8 ><__G2__><__G2__><__G2__><__G2__><__G2__><__G2__><__G2__>< +DATA7 ><__G1__><__G1__><__G1__><__G1__><__G1__><__G1__><__G1__>< +DATA6 ><__G0__><__G0__><__G0__><__G0__><__G0__><__G0__><__G0__>< + __ __ __ __ __ __ __ +DATA5 ><__B5__><__B5__><__B5__><__B5__><__B5__><__B5__><__B5__>< +DATA4 ><__B4__><__B4__><__B4__><__B4__><__B4__><__B4__><__B4__>< +DATA3 ><__B3__><__B3__><__B3__><__B3__><__B3__><__B3__><__B3__>< +DATA2 ><__B2__><__B2__><__B2__><__B2__><__B2__><__B2__><__B2__>< +DATA1 ><__B1__><__B1__><__B1__><__B1__><__B1__><__B1__><__B1__>< +DATA0 ><__B0__><__B0__><__B0__><__B0__><__B0__><__B0__><__B0__>< +pixel | n | n+1 | n+3 | n+4 | n+5 | n+6 | n+7 | + +p565 mode: + ___ ___ ___ ___ ___ ___ ___ +dclk__/ \___/ \___/ \___/ \___/ \___/ \___/ \___ + __ __ __ __ __ __ __ +DATA15 ><__R4__><__R4__><__R4__><__R4__><__R4__><__R4__><__R4__>< +DATA14 ><__R3__><__R3__><__R3__><__R3__><__R3__><__R3__><__R3__>< +DATA13
[PATCH v3 0/4] Add support rockchip RGB output interface
This patches add support rockchip RGB output, Some Rockchip CRTCs, like rv1108, can directly output parallel and serial RGB data to panel or to conversion chip. So we add this driver to probe encoder and connector to support this case. Sandy Huang (4): devicetree/bindings: display: Add doucument for RGB panels devicetree/bindings: display: Add document for rockchip RGB output drm/rockchip: Add support for Rockchip Soc RGB output interface drm/rockchip: vop: Add more RGB output interface type .../bindings/display/panel/panel-rgb.txt | 116 +++ .../bindings/display/rockchip/rockchip-rgb.txt | 72 + drivers/gpu/drm/rockchip/Kconfig | 9 + drivers/gpu/drm/rockchip/Makefile | 1 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c| 2 + drivers/gpu/drm/rockchip/rockchip_drm_drv.h| 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.h| 2 + drivers/gpu/drm/rockchip/rockchip_rgb.c| 343 + 8 files changed, 546 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/panel-rgb.txt create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt create mode 100644 drivers/gpu/drm/rockchip/rockchip_rgb.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [dim PATCH] dim: allow a space separated list of URLs for each repo in drm_tip_repos
On Tue, 03 Oct 2017, Jani Nikulawrote: > I merged this last week with Daniel's IRC ack. We'll need to give people > a little bit of time before updating nightly.conf. Sorry for the > inconvenience in the mean time. Andrzej, all the bits and pieces for this have been pushed, so https:// should just work for all repos *except* Dave's drm tree. I don't know why, but [1] doesn't advertize https for it. BR, Jani. [1] https://cgit.freedesktop.org/~airlied/linux/ -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/12] radix-tree: split out struct radix_tree_root out to
The motivation of this series is to cut down unnecessary header dependency in terms of radix tree. Sub-systems or drivers that use radix-tree for data management typically embed struct radix_tree_root in their data structures, like this: struct foo { ... struct radix_tree_root foo_tree; ... }; So, needs to include , therefore, users of include a lot of bloat from . If you see the definition of radix_tree_root, struct radix_tree_root { gfp_tgfp_mask; struct radix_tree_node __rcu *rnode; }; it is a very simple structure. It only depends on for gfp_t and for __rcu. By splitting out the radix_tree_root definition, we can reduce the header file dependency. Reducing the header dependency will help for speeding the kernel build, suppressing unnecessary recompile of objects during git-bisect'ing, etc. The patch 1 is a trivial clean-up; it is just here to avoid conflict. The patch 2 is the main part of this series; split out struct radix_tree_root. The rest of the series replace with where appropriate. Please review if the idea is OK. If it is OK, I'd like to know how to apply the series. Perhaps, the first two for v4.15. Then, rest of series will be sent per-subsystem for v4.16? Or, can somebody take care of the whole series? I checked allmodconfig for x86 and arm64. I am expecting 0 day testing will check it too. Masahiro Yamada (12): radix-tree: replace with radix-tree: split struct radix_tree_root to irqdomain: replace with writeback: replace with iocontext.h: replace with fs: replace with blkcg: replace with fscache: include sh: intc: replace with net/mlx4: replace with net/mlx5: replace with drm/i915: replace with drivers/gpu/drm/i915/i915_gem.c| 1 + drivers/gpu/drm/i915/i915_gem_context.c| 1 + drivers/gpu/drm/i915/i915_gem_context.h| 2 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1 + drivers/gpu/drm/i915/i915_gem_object.h | 1 + drivers/net/ethernet/mellanox/mlx4/cq.c| 1 + drivers/net/ethernet/mellanox/mlx4/mlx4.h | 2 +- drivers/net/ethernet/mellanox/mlx4/qp.c| 1 + drivers/net/ethernet/mellanox/mlx4/srq.c | 1 + drivers/sh/intc/internals.h| 2 +- include/linux/backing-dev-defs.h | 2 +- include/linux/blk-cgroup.h | 2 +- include/linux/fs.h | 2 +- include/linux/fscache.h| 1 + include/linux/iocontext.h | 2 +- include/linux/irqdomain.h | 2 +- include/linux/mlx4/device.h| 2 +- include/linux/mlx4/qp.h| 1 + include/linux/mlx5/driver.h| 2 +- include/linux/mlx5/qp.h| 1 + include/linux/radix-tree-root.h| 24 include/linux/radix-tree.h | 8 ++-- 22 files changed, 46 insertions(+), 16 deletions(-) create mode 100644 include/linux/radix-tree-root.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/12] drm/i915: replace with
The header drivers/gpu/drm/i915/i915_gem_context.h requires the definition of struct radix_tree_root, but does not need to know anything about other radix tree stuff. Include instead of to reduce the number of included header files. While we are here, let's add missing where radix tree accessors are used. Signed-off-by: Masahiro Yamada--- drivers/gpu/drm/i915/i915_gem.c| 1 + drivers/gpu/drm/i915/i915_gem_context.c| 1 + drivers/gpu/drm/i915/i915_gem_context.h| 2 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1 + drivers/gpu/drm/i915/i915_gem_object.h | 1 + 5 files changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 19404c9..d2356eb 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -37,6 +37,7 @@ #include "intel_mocs.h" #include #include +#include #include #include #include diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index 58a2a44..34b2195 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -86,6 +86,7 @@ */ #include +#include #include #include #include "i915_drv.h" diff --git a/drivers/gpu/drm/i915/i915_gem_context.h b/drivers/gpu/drm/i915/i915_gem_context.h index 44688e2..0ebe11f 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.h +++ b/drivers/gpu/drm/i915/i915_gem_context.h @@ -27,7 +27,7 @@ #include #include -#include +#include struct pid; diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 92437f4..af9ee58 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -27,6 +27,7 @@ */ #include +#include #include #include #include diff --git a/drivers/gpu/drm/i915/i915_gem_object.h b/drivers/gpu/drm/i915/i915_gem_object.h index c30d8f8..a5a5506 100644 --- a/drivers/gpu/drm/i915/i915_gem_object.h +++ b/drivers/gpu/drm/i915/i915_gem_object.h @@ -25,6 +25,7 @@ #ifndef __I915_GEM_OBJECT_H__ #define __I915_GEM_OBJECT_H__ +#include #include #include -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: vc4: Fix race during binding
> Eric Anholthat am 8. Oktober 2017 um 19:09 geschrieben: > > > Stefan Wahren writes: > > > Hi Eric, > > > >> Eric Anholt hat am 6. Oktober 2017 um 21:42 geschrieben: > >> > >> > >> Stefan Wahren writes: > >> > >> > This fixes the race between vc4_overflow_mem_work and the init of the > >> > job lock. Otherwise we could trigger a NULL pointer dereference > >> > during VC4 binding. > >> > > >> > Link: https://github.com/anholt/linux/issues/114 > >> > Signed-off-by: Stefan Wahren > >> > Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.") > >> > --- > >> > drivers/gpu/drm/vc4/vc4_gem.c | 1 - > >> > drivers/gpu/drm/vc4/vc4_irq.c | 1 + > >> > 2 files changed, 1 insertion(+), 1 deletion(-) > >> > > >> > diff --git a/drivers/gpu/drm/vc4/vc4_gem.c > >> > b/drivers/gpu/drm/vc4/vc4_gem.c > >> > index d0c6bfb..47d964f 100644 > >> > --- a/drivers/gpu/drm/vc4/vc4_gem.c > >> > +++ b/drivers/gpu/drm/vc4/vc4_gem.c > >> > @@ -1088,7 +1088,6 @@ vc4_gem_init(struct drm_device *dev) > >> > INIT_LIST_HEAD(>render_job_list); > >> > INIT_LIST_HEAD(>job_done_list); > >> > INIT_LIST_HEAD(>seqno_cb_list); > >> > -spin_lock_init(>job_lock); > >> > > >> > INIT_WORK(>hangcheck.reset_work, vc4_reset_work); > >> > setup_timer(>hangcheck.timer, > >> > diff --git a/drivers/gpu/drm/vc4/vc4_irq.c > >> > b/drivers/gpu/drm/vc4/vc4_irq.c > >> > index 7d7af3a..d508d13 100644 > >> > --- a/drivers/gpu/drm/vc4/vc4_irq.c > >> > +++ b/drivers/gpu/drm/vc4/vc4_irq.c > >> > @@ -195,6 +195,7 @@ vc4_irq_preinstall(struct drm_device *dev) > >> > struct vc4_dev *vc4 = to_vc4_dev(dev); > >> > > >> > init_waitqueue_head(>job_wait_queue); > >> > +spin_lock_init(>job_lock); > >> > INIT_WORK(>overflow_mem_work, vc4_overflow_mem_work); > >> > > >> > /* Clear any pending interrupts someone might have left around > >> > >> Are you sure this is a fix? We don't attach the IRQ handler until V3D > >> bind, and vc4_gem_init happens before component_bind_all(), right? > > > > i agree i should have mark it as a RFC. But is it really impossible > > that vc4_overflow_mem_work is triggered before vc4_gem_init? > > As far as I can see, it gets queued from the IRQ handler, the IRQ > handler is added during V3D bind, and binding happens after GEM init. > > Hmm. If we fail out of component binding and try again, we'll end up > doing the job_wait_queue and overflow_mem_work initialization on the > same pointer twice. Will that cause any trouble? We cancel any pending > work during uninstall (V3D unbind path), but does drm_irq_uninstall() > make sure that the irq handler has finished? I cannot see an issue. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/12] radix-tree: split out struct radix_tree_root out to
2017-10-09 3:52 GMT+09:00 Leon Romanovsky: > On Mon, Oct 09, 2017 at 01:10:01AM +0900, Masahiro Yamada wrote: > > <...> >> >> By splitting out the radix_tree_root definition, >> we can reduce the header file dependency. >> >> Reducing the header dependency will help for speeding the kernel >> build, suppressing unnecessary recompile of objects during >> git-bisect'ing, etc. > > If we judge by the diffstat of this series, there won't be any > visible change in anything mentioned above. Of course, judging by the diffstat is wrong. -- Best Regards Masahiro Yamada ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/12] radix-tree: split out struct radix_tree_root out to
On Mon, Oct 09, 2017 at 01:10:01AM +0900, Masahiro Yamada wrote: <...> > > By splitting out the radix_tree_root definition, > we can reduce the header file dependency. > > Reducing the header dependency will help for speeding the kernel > build, suppressing unnecessary recompile of objects during > git-bisect'ing, etc. If we judge by the diffstat of this series, there won't be any visible change in anything mentioned above. <...> > > Masahiro Yamada (12): > radix-tree: replace with > radix-tree: split struct radix_tree_root to > irqdomain: replace with > writeback: replace with > iocontext.h: replace with > > fs: replace with > blkcg: replace with > fscache: include > sh: intc: replace with > net/mlx4: replace with > net/mlx5: replace with > drm/i915: replace with > > drivers/gpu/drm/i915/i915_gem.c| 1 + > drivers/gpu/drm/i915/i915_gem_context.c| 1 + > drivers/gpu/drm/i915/i915_gem_context.h| 2 +- > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1 + > drivers/gpu/drm/i915/i915_gem_object.h | 1 + > drivers/net/ethernet/mellanox/mlx4/cq.c| 1 + > drivers/net/ethernet/mellanox/mlx4/mlx4.h | 2 +- > drivers/net/ethernet/mellanox/mlx4/qp.c| 1 + > drivers/net/ethernet/mellanox/mlx4/srq.c | 1 + > drivers/sh/intc/internals.h| 2 +- > include/linux/backing-dev-defs.h | 2 +- > include/linux/blk-cgroup.h | 2 +- > include/linux/fs.h | 2 +- > include/linux/fscache.h| 1 + > include/linux/iocontext.h | 2 +- > include/linux/irqdomain.h | 2 +- > include/linux/mlx4/device.h| 2 +- > include/linux/mlx4/qp.h| 1 + > include/linux/mlx5/driver.h| 2 +- > include/linux/mlx5/qp.h| 1 + > include/linux/radix-tree-root.h| 24 > include/linux/radix-tree.h | 8 ++-- > 22 files changed, 46 insertions(+), 16 deletions(-) > create mode 100644 include/linux/radix-tree-root.h > > -- > 2.7.4 > signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/12] radix-tree: split out struct radix_tree_root out to
On Mon, Oct 09, 2017 at 02:58:58PM +0900, Masahiro Yamada wrote: > 2017-10-09 3:52 GMT+09:00 Leon Romanovsky: > > On Mon, Oct 09, 2017 at 01:10:01AM +0900, Masahiro Yamada wrote: > > > > <...> > >> > >> By splitting out the radix_tree_root definition, > >> we can reduce the header file dependency. > >> > >> Reducing the header dependency will help for speeding the kernel > >> build, suppressing unnecessary recompile of objects during > >> git-bisect'ing, etc. > > > > If we judge by the diffstat of this series, there won't be any > > visible change in anything mentioned above. > > > Of course, judging by the diffstat is wrong. > I'm more than happy to be wrong and you for sure can help me. Can you provide any quantitative support of your claims? Thanks > > > -- > Best Regards > Masahiro Yamada > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel