Re: [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value

Hi, On 7/7/20 9:34 AM, Uwe Kleine-König wrote: On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote: Hi, Thank you for your review and sorry for the slow reply. No problem for me, I didn't hold my breath :-) diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c index 43b

Re: Panic booting qemu-system-sparc64 with bochs_drm

> Thanks Gerd - I've just tested the diff below with memcpy_toio() and that > works too: > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 5609e164805f..4d05b0ab1592 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @

[RFC PATCH] drm/msm: Add vblank timestamp support for dpu1

add vblank timestamp support via drm helpers [RFC] some questions about modern vblank timestamp handling in context of this patch: 1. When a driver is using output polling with no console defined and fb helpers trigger an atomic mode set during initial output detection, existing vblank->hwmode.cr

Re: [PATCH 12/20] Documentation: maintainer-entry-profile: eliminate duplicated word

On Tue, Jul 7, 2020 at 11:07 AM Randy Dunlap wrote: > > Drop the doubled word "have". > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Dan Williams > --- > Documentation/maintainer/maintainer-entry-profile.rst |2 +- > 1 file changed, 1 insertion(

Re: [PATCH 04/20] Documentation: kgdb: eliminate duplicated word

Hi, On Tue, Jul 7, 2020 at 11:05 AM Randy Dunlap wrote: > > Drop the doubled word "driver". > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Jason Wessel > Cc: Daniel Thompson > Cc: Douglas Anderson > Cc: kgdb-bugrep...@lists.sourceforge.net > --- >

Re: [PATCH 1/2] drm/vgem: Do not allocate backing shmemfs file for an import dmabuf object

Quoting lepton (2020-07-07 19:17:51) > On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote: > > > > Quoting lepton (2020-07-07 18:05:21) > > > On Tue, Jul 7, 2020 at 9:00 AM Chris Wilson > > > wrote: > > > > > > > > If we assign obj->filp, we believe that the create vgem bo is native and > > > >

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #47 from Duncan (1i5t5.dun...@cox.net) --- (In reply to Duncan from comment #39) > 28 candidates ATM, several of which are OCFS2 or spelling > fixes neither of which should affect this bug. Excluding those there are > eleven left; the

Re: [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value

Hello Hans, On Tue, Jul 07, 2020 at 07:31:29PM +0200, Hans de Goede wrote: > On 7/7/20 9:34 AM, Uwe Kleine-König wrote: > > On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote: > > > But if we do then I think closest to the truth would be: > > > > > > state->period = UINT_MAX; > > >

RE: [PATCH 1/2] drm/ttm: further cleanup ttm_mem_reg handling

[AMD Public Use] -Original Message- From: amd-gfx On Behalf Of Christian König Sent: Monday, July 6, 2020 11:18 PM To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org Subject: [PATCH 1/2] drm/ttm: further cleanup ttm_mem_reg handling Stop touching the backend private poin

Re: [PATCH v3 15/15] drm/i915: panel: Use atomic PWM API for devs with an external PWM controller

Hi Uwe, On 7/7/20 9:50 AM, Uwe Kleine-König wrote: Hello Hans, On Sat, Jun 20, 2020 at 02:17:58PM +0200, Hans de Goede wrote: Now that the PWM drivers which we use have been converted to the atomic PWM API, we can move the i915 panel code over to using the atomic PWM API. Note that there is

Re: [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value

Hi, On 7/7/20 9:09 PM, Uwe Kleine-König wrote: Hello Hans, On Tue, Jul 07, 2020 at 07:31:29PM +0200, Hans de Goede wrote: On 7/7/20 9:34 AM, Uwe Kleine-König wrote: On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote: But if we do then I think closest to the truth would be: stat

Re: [PATCH 20/20] Documentation: vm/memory-model: eliminate duplicated word

On Tue, Jul 07, 2020 at 11:04:13AM -0700, Randy Dunlap wrote: > Drop the doubled word "the". > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: Andrew Morton > Cc: linux...@kvack.org Reviewed-by: Mike Rapoport > --- > Documentation/vm/memory-model.rs

Re: Panic booting qemu-system-sparc64 with bochs_drm

Hi Gerd. On Tue, Jul 07, 2020 at 09:03:41AM +0200, Gerd Hoffmann wrote: > > Yes, that's correct - I can confirm that the simplified diff below works: > > > > diff --git a/drivers/gpu/drm/drm_fb_helper.c > > b/drivers/gpu/drm/drm_fb_helper.c > > index 5609e164805f..83af05fac604 100644 > > --- a/d

Re: [PATCH v4 17/20] backlight: use backligt_get_brightness()

On Tue, Jul 07, 2020 at 07:48:20AM +0200, Daniel Vetter wrote: > On Fri, Jul 03, 2020 at 08:45:43PM +0200, Sam Ravnborg wrote: > > Introduce the backlight_get_brightness() helper in all > > video/backlight/* drivers. > > This simplifies the code and align the implementation of the > > update_status

[PATCH 00/25] dma-fence annotations, round 3

Hi all, Bunch of changes that might matter: - Clarification that dma_fences are for drivers/gpu, requested by Jason Gunthorpe. - New patch to list all the past discussions around indefinite/future/whatever fences, and why this (sadly) still just plain doesn't work. Came up again when discu

[PATCH 01/25] dma-fence: basic lockdep annotations

Design is similar to the lockdep annotations for workers, but with some twists: - We use a read-lock for the execution/worker/completion side, so that this explicit annotation can be more liberally sprinkled around. With read locks lockdep isn't going to complain if the read-side isn't neste

[PATCH 04/25] drm/vkms: Annotate vblank timer

This is needed to signal the fences from page flips, annotate it accordingly. We need to annotate entire timer callback since if we get stuck anywhere in there, then the timer stops, and hence fences stop. Just annotating the top part that does the vblank handling isn't enough. Cc: linux-me...@vge

[PATCH 05/25] drm/vblank: Annotate with dma-fence signalling section

This is rather overkill since currently all drivers call this from hardirq (or at least timers). But maybe in the future we're going to have thread irq handlers and what not, doesn't hurt to be prepared. Plus this is an easy start for sprinkling these fence annotations into shared code. Cc: linux-

[PATCH 08/25] drm/malidp: Annotate dma-fence critical section in commit path

Again needs to be put right after the call to drm_atomic_helper_commit_hw_done(), since that's the last thing which can hold up a subsequent atomic commit. No surprises here. Signed-off-by: Daniel Vetter Cc: "James (Qian) Wang" Cc: Liviu Dudau Cc: Mihail Atanassov --- drivers/gpu/drm/arm/mal

[PATCH 02/25] dma-fence: prime lockdep annotations

Two in one go: - it is allowed to call dma_fence_wait() while holding a dma_resv_lock(). This is fundamental to how eviction works with ttm, so required. - it is allowed to call dma_fence_wait() from memory reclaim contexts, specifically from shrinker callbacks (which i915 does), and from mm

[PATCH 12/25] drm/rcar-du: Annotate dma-fence critical section in commit path

Ends right after drm_atomic_helper_commit_hw_done(), absolutely nothing fancy going on here. Signed-off-by: Daniel Vetter Cc: Laurent Pinchart Cc: Kieran Bingham Cc: linux-renesas-...@vger.kernel.org --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH 09/25] drm/atmel: Use drm_atomic_helper_commit

One of these drivers that predates the nonblocking support in helpers, and hand-rolled its own thing. Entirely not anything specific here, we can just delete it all and replace it with the helper version. Could also perhaps use the drm_mode_config_helper_suspend/resume stuff, for another few lines

[PATCH 15/25] drm/tilcdc: Use standard drm_atomic_helper_commit

Gives us proper nonblocking support for free, and a pile of other things. The tilcdc code is simply old enough that it was never converted over, but was stuck forever with the copypasta from when it was initially merged. The riskiest thing with this conversion is maybe that there's an issue with t

[PATCH 07/25] drm/komdea: Annotate dma-fence critical section in commit path

Like the helpers, nothing special. Well except not, because we the critical section extends until after hw_done(), since that's the last thing which could hold up a subsequent atomic commit. That means the wait_for_flip_done is included, but that's not a problem, we're allowed to call dma_fence_wai

[PATCH 14/25] drm/tidss: Annotate dma-fence critical section in commit path

Ends right after hw_done(), totally standard case. Signed-off-by: Daniel Vetter Cc: Jyri Sarha Cc: Tomi Valkeinen --- drivers/gpu/drm/tidss/tidss_kms.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/tidss/tidss_kms.c b/drivers/gpu/drm/tidss/tidss_kms.c index b6e61d6cf

[PATCH 03/25] dma-buf.rst: Document why idenfinite fences are a bad idea

Comes up every few years, gets somewhat tedious to discuss, let's write this down once and for all. What I'm not sure about is whether the text should be more explicit in flat out mandating the amdkfd eviction fences for long running compute workloads or workloads where userspace fencing is allowe

[PATCH 16/25] drm/atomic-helper: Add dma-fence annotations

This is a bit disappointing since we need to split the annotations over all the different parts. I was considering just leaking the critical section into the ->atomic_commit_tail callback of each driver. But that would mean we need to pass the fence_cookie into each driver (there's a total of 13 i

[PATCH 13/25] drm/tegra: Annotate dma-fence critical section in commit path

Again ends just after drm_atomic_helper_commit_hw_done(), but with the twist that we need to make sure we're only annotate the custom version. And not the other clause which just calls drm_atomic_helper_commit_tail_rpm(), which is already annotated. Signed-off-by: Daniel Vetter Cc: Thierry Reding

[PATCH 22/25] drm/scheduler: use dma-fence annotations in tdr work

In the face of unpriviledged userspace being able to submit bogus gpu workloads the kernel needs gpu timeout and reset (tdr) to guarantee that dma_fences actually complete. Annotate this worker to make sure we don't have any accidental locking inversions or other problems lurking. Originally this

[PATCH 10/25] drm/imx: Annotate dma-fence critical section in commit path

drm_atomic_helper_commit_hw_done() is the last thing (no plane cleanup apparrently), so it's the entire function. And a nice comment explaining why thw wait_for_flip_done is ahead, unlike the usual sequence. Aside, I think since the atomic helpers do track plane disabling now separately this might

[PATCH 19/25] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code

My dma-fence lockdep annotations caught an inversion because we allocate memory where we really shouldn't: kmem_cache_alloc+0x2b/0x6d0 amdgpu_fence_emit+0x30/0x330 [amdgpu] amdgpu_ib_schedule+0x306/0x550 [amdgpu] amdgpu_job_run+0x10f/0x260 [amdgpu] drm_sched

[PATCH 06/25] drm/amdgpu: add dma-fence annotations to atomic commit path

I need a canary in a ttm-based atomic driver to make sure the dma_fence_begin/end_signalling annotations actually work. Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-...@lists.freedesktop.org Cc: Chris

[PATCH 11/25] drm/omapdrm: Annotate dma-fence critical section in commit path

Nothing special, just put the end right after hw_done(). Note that in one path there's a wait for the flip/update to complete. But as far as I understand from comments and code that's only relevant for modesets, and skipped if there wasn't a modeset done on a given crtc. For a bit more clarity pul

[PATCH 17/25] drm/scheduler: use dma-fence annotations in main thread

If the scheduler rt thread gets stuck on a mutex that we're holding while waiting for gpu workloads to complete, we have a problem. Add dma-fence annotations so that lockdep can check this for us. I've tried to quite carefully review this, and I think it's at the right spot. But obviosly no exper

[PATCH 21/25] drm/amdgpu/dc: Stop dma_resv_lock inversion in commit_tail

Trying to grab dma_resv_lock while in commit_tail before we've done all the code that leads to the eventual signalling of the vblank event (which can be a dma_fence) is deadlock-y. Don't do that. Here the solution is easy because just grabbing locks to read something races anyway. We don't need to

[PATCH 24/25] Revert "drm/amdgpu: add fbdev suspend/resume on gpu reset"

This is one from the department of "maybe play lottery if you hit this, karma compensation might work". Or at least lockdep ftw! This reverts commit 565d1941557756a584ac357d945bc374d5fcd1d0. It's not quite as low-risk as the commit message claims, because this grabs console_lock, which might be h

[PATCH 20/25] drm/amdgpu: DC also loves to allocate stuff where it shouldn't

Not going to bother with a complete&pretty commit message, just offending backtrace: kvmalloc_node+0x47/0x80 dc_create_state+0x1f/0x60 [amdgpu] dc_commit_state+0xcb/0x9b0 [amdgpu] amdgpu_dm_atomic_commit_tail+0xd31/0x2010 [amdgpu] commit_tail+0xa4/0x140 [drm

[PATCH 25/25] drm/amdgpu: gpu recovery does full modesets

... I think it's time to stop this little exercise. The lockdep splat, for the record: [ 132.583381] == [ 132.584091] WARNING: possible circular locking dependency detected [ 132.584775] 5.7.0-rc3+ #346 Tainted: GW [ 132.585461] ---

[PATCH 18/25] drm/amdgpu: use dma-fence annotations in cs_submit()

This is a bit tricky, since ->notifier_lock is held while calling dma_fence_wait we must ensure that also the read side (i.e. dma_fence_begin_signalling) is on the same side. If we mix this up lockdep complaints, and that's again why we want to have these annotations. A nice side effect of this is

[PATCH 23/25] drm/amdgpu: use dma-fence annotations for gpu reset code

To improve coverage also annotate the gpu reset code itself, since that's called from other places than drm/scheduler (which is already annotated). Annotations nests, so this doesn't break anything, and allows easier testing. Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: l

Re: [PATCH v4 17/20] backlight: use backligt_get_brightness()

On Tue, Jul 7, 2020 at 9:59 PM Sam Ravnborg wrote: > > On Tue, Jul 07, 2020 at 07:48:20AM +0200, Daniel Vetter wrote: > > On Fri, Jul 03, 2020 at 08:45:43PM +0200, Sam Ravnborg wrote: > > > Introduce the backlight_get_brightness() helper in all > > > video/backlight/* drivers. > > > This simplifie

Re: [PATCH v4 17/20] backlight: use backligt_get_brightness()

Hi Daniel > > > > When I stop doing backlight stuff I will compose a proper > > todo entry. Right now I hope to get first batch included in upstream. > > Sounds all good to me. > > > I hope this set can hit upstream. > > Next it to convert backlight stuff in gpu/drm/ - let me see how that > > al

[PATCH 2/2] drm/msm/adreno: un-open-code some packets

From: Rob Clark Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 5 +++-- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 11 +++ 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c i

[PATCH 0/2] drm/msm/adreno: cleanup some packet building

From: Rob Clark Resync generated headers, which we haven't done in a while, and cleanup some open coded packet building. Rob Clark (2): drm/msm: sync generated headers drm/msm/adreno: un-open-code some packets drivers/gpu/drm/msm/adreno/a2xx.xml.h | 1102 +++- drivers/gpu/drm/m

Re: [PATCH 09/25] drm/atmel: Use drm_atomic_helper_commit

Hi Daniel. On Tue, Jul 07, 2020 at 10:12:13PM +0200, Daniel Vetter wrote: > One of these drivers that predates the nonblocking support in helpers, > and hand-rolled its own thing. Entirely not anything specific here, we > can just delete it all and replace it with the helper version. > > Could al

[PATCH][next] fbdev: Use fallthrough pseudo-keyword

Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fal

Re: [PATCH v2 14/14] phy/rockchip: inno-hdmi: Support more pre-pll configuration

On 2020-07-07 21:53, Johan Jonker wrote: > > Hi, > > What's the status for this patch? > This is just what I needed for A95X Z2 to get the vop+hdmi and monitor > working. ;) > > Could this become applied to mainline already? > The ack is already there. I will send a v3 of the phy/rockchip parts

Re: Panic booting qemu-system-sparc64 with bochs_drm

On 07/07/2020 20:52, Sam Ravnborg wrote: > Hi Gerd. > > On Tue, Jul 07, 2020 at 09:03:41AM +0200, Gerd Hoffmann wrote: >>> Yes, that's correct - I can confirm that the simplified diff below works: >>> >>> diff --git a/drivers/gpu/drm/drm_fb_helper.c >>> b/drivers/gpu/drm/drm_fb_helper.c >>> inde

[Bug 208489] New: amdgpu: kernel oops when overclocking Vega M GPU (i7-8809G)

https://bugzilla.kernel.org/show_bug.cgi?id=208489 Bug ID: 208489 Summary: amdgpu: kernel oops when overclocking Vega M GPU (i7-8809G) Product: Drivers Version: 2.5 Kernel Version: 5.7.7 Hardware: x86-64

[PATCH] drm/atmel: Use drm_atomic_helper_commit

One of these drivers that predates the nonblocking support in helpers, and hand-rolled its own thing. Entirely not anything specific here, we can just delete it all and replace it with the helper version. Could also perhaps use the drm_mode_config_helper_suspend/resume stuff, for another few lines

Re: [PATCH v4 20/20] backlight: make of_find_backlight_by_node() static

Hi Sam, I love your patch! Yet something to improve: [auto build test ERROR on backlight/for-backlight-next] [also build test ERROR on tegra-drm/drm/tegra/for-next pwm/for-next linus/master v5.8-rc4] [cannot apply to next-20200707] [If your patch is applied to the wrong git tree, kindly drop us

RE: [RFC PATCH v2 0/3] RDMA: add dma-buf support

> -Original Message- > From: Christian König > Am 03.07.20 um 15:14 schrieb Jason Gunthorpe: > > On Fri, Jul 03, 2020 at 02:52:03PM +0200, Daniel Vetter wrote: > > > >> So maybe I'm just totally confused about the rdma model. I thought: > >> - you bind a pile of memory for various transac

Re: [PATCH 1/2] drm/probe_helper: Add drm_connector_helper_funcs.mode_valid_ctx

Sorry for the delay, the review as I promised: On Tue, May 26, 2020 at 02:23:09PM -0400, Lyude Paul wrote: > This is just an atomic version of mode_valid, which is intended to be > used for situations where a driver might need to check the atomic state > of objects other than the connector itself.

Re: [PATCH v3 9/9] drm/mediatek: reduce clear event

Hi, Dennis: Dennis YC Hsieh 於 2020年7月7日 週二 下午11:47寫道： > > No need to clear event again since event always clear before wait. > This fix depend on patch: > "soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api" Acked-by: Chun-Kuang Hu > > Fixes: 2f965be7f9008 ("drm/mediatek: apply CMDQ c

Re: [PATCH v3 8/9] soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api

Hi, Dennis: Dennis YC Hsieh 於 2020年7月7日 週二 下午11:47寫道： > > Add clear parameter to let client decide if > event should be clear to 0 after GCE receive it. For DRM part, Acked-by: Chun-Kuang Hu > > Change since v2: > - Keep behavior in drm crtc driver and > separate bug fix code into another p

Re: [Intel-gfx] [PATCH 2/2] drm/i915/mst: filter out the display mode exceed sink's capability

On Tue, May 26, 2020 at 02:23:10PM -0400, Lyude Paul wrote: > From: Lee Shawn C > > So far, max dot clock rate for MST mode rely on physcial > bandwidth limitation. It would caused compatibility issue > if source display resolution exceed MST hub output ability. > > For example, source DUT had D

Re: [PATCH 12/25] drm/rcar-du: Annotate dma-fence critical section in commit path

Hi Daniel, Thank you for the patch. On Tue, Jul 07, 2020 at 10:12:16PM +0200, Daniel Vetter wrote: > Ends right after drm_atomic_helper_commit_hw_done(), absolutely > nothing fancy going on here. Just looking at this patch and the commit message, I have no idea what this does, and why. It would

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #48 from Duncan (1i5t5.dun...@cox.net) --- (In reply to Duncan from comment #47) > > [I]dea to just try patch-reverting them on top of > > 5.7 or current 5.8-rc, thus eliminating the apparently unrelated > > kernel-panics I''ve twice t

[radeon-alex:amd-staging-drm-next 9971/9999] drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:2280:5: warning: no previous prototype for 'parse_ta_bin_descriptor'

tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 6b7ad8618edbe6aecf1122e654d08a8237471800 commit: be165aab3d558e3b8573d0e2699c42af5b0f62c8 [9971/] drm/amdgpu: updated ta ucode loading config: alpha-allyesconfig (attached as .config) compiler: alpha-linux-gcc (

[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail

https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #49 from Christopher Snowhill (kod...@gmail.com) --- One possibility that I hadn't considered when I was originally testing this. I use the GNOME 3 desktop on Arch, and have two monitors, one 3840x2160@60Hz, one 1920x1080@60Hz, both Di

[radeon-alex:amd-staging-drm-next 9971/9999] drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c:2280:5: warning: no previous prototype for function 'parse_ta_bin_descriptor'

tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 6b7ad8618edbe6aecf1122e654d08a8237471800 commit: be165aab3d558e3b8573d0e2699c42af5b0f62c8 [9971/] drm/amdgpu: updated ta ucode loading config: x86_64-allyesconfig (attached as .config) compiler: clang version 11

Re: [PATCH][next] drm/nouveau: Use fallthrough pseudo-keyword

On Wed, 8 Jul 2020 at 03:31, Gustavo A. R. Silva wrote: > > Replace the existing /* fall through */ comments and its variants with > the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary > fall-through markings when it is the case. I really like this! I was not a fan of explicitly

Re: [PATCH][next] drm/nouveau: Use fallthrough pseudo-keyword

On Wed, 2020-07-08 at 13:22 +1000, Ben Skeggs wrote: > On Wed, 8 Jul 2020 at 03:31, Gustavo A. R. Silva > wrote: > > Replace the existing /* fall through */ comments and its variants with > > the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary > > fall-through markings when it i

[PULL] nouveau-fixes 5.8

The following changes since commit dcb7fd82c75ee2d6e6f9d8cc71c52519ed52e258: Linux 5.8-rc4 (2020-07-05 16:20:22 -0700) are available in the Git repository at: git://github.com/skeggsb/linux linux-5.8 for you to fetch changes up to ed710a6ed797430026aa5116dd0ab22378798b69: drm/nouveau/nou

Re: [PATCH] staging: android: ion: Skip sync if not mapped

On Fri, Jul 3, 2020 at 12:03 AM Greg Kroah-Hartman wrote: > On Tue, Apr 21, 2020 at 10:05:44AM +0200, Greg Kroah-Hartman wrote: > > On Mon, Apr 20, 2020 at 01:03:39PM -0700, John Stultz wrote: > > > The dmabuf heaps have been in an official kernel now for all of three > > > weeks. So yea, we can "

Re: [PATCH 06/20] Documentation: gpu/komeda-kms: eliminate duplicated word

Hi Randy On Tue, Jul 07, 2020 at 11:04:00AM -0700, Randy Dunlap wrote: > Drop the doubled word "and". > > Signed-off-by: Randy Dunlap > Cc: Jonathan Corbet > Cc: linux-...@vger.kernel.org > Cc: James (Qian) Wang > Cc: Liviu Dudau > Cc: Mihail Atanassov > Cc: Mali DP Maintainers > --- > Doc

Re: [PATCH 07/25] drm/komdea: Annotate dma-fence critical section in commit path

On Tue, Jul 07, 2020 at 10:12:11PM +0200, Daniel Vetter wrote: > Like the helpers, nothing special. Well except not, because we the > critical section extends until after hw_done(), since that's the last > thing which could hold up a subsequent atomic commit. That means the > wait_for_flip_done is

Re: [PATCH 3/4] drm: edid: Convert logging to drm_* functions.

Thanks! Am 07.07.20 um 18:36 schrieb Suraj Upadhyay: > Change logging of warnings to drm_warn() form dev_warn(). > > Signed-off-by: Suraj Upadhyay Reviewed-by: Thomas Zimmermann > --- > drivers/gpu/drm/drm_edid.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git

Re: [PATCH 4/4] drm: fb-helper: Convert logging to drm_* functions.

Am 07.07.20 um 18:37 schrieb Suraj Upadhyay: > Change logging information from dev_info() to drm_info(). > > Signed-off-by: Suraj Upadhyay Reviewed-by: Thomas Zimmermann > --- > drivers/gpu/drm/drm_fb_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers

Re: [RFC PATCH 3/4] gpu/drm: Add TinyDRM for DSI/DBI panels

Hi paul,     After add this driver, the followinig usage scenarios can be supported?     panel 1. crtc->encoder->connector[edp/hdmi/mipi dsi] -> panel     panel 2. Panel setup/control and framebuffer upload over SPI     the two panel maybe display same/different conctent at same time. 在 2020

[PATCH v4 0/4] Add LT9611 DSI to HDMI bridge

Hi, This series adds driver and bindings for Lontium LT9611 bridge chip which takes MIPI DSI as input and HDMI as output. This chip can be found in 96boards RB3 platform [1] commonly called DB845c. [1]: https://www.96boards.org/product/rb3-platform/ Changes in v4: - Add msm/dsi patch to create

Re: [PATCH v13 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP

On Tue, Jun 9, 2020 at 3:20 PM Xin Ji wrote: > > The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed > for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K. > > Signed-off-by: Xin Ji > --- > drivers/gpu/drm/bridge/analogix/Kconfig |9 + > drivers/gpu/drm/brid

Re: Panic booting qemu-system-sparc64 with bochs_drm

> Yes, that's correct - I can confirm that the simplified diff below works: > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 5609e164805f..83af05fac604 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -399,7 +399,

Re: [PATCH v3 11/15] pwm: crc: Implement get_state() method

Hello Hans, On Mon, Jul 06, 2020 at 11:05:20PM +0200, Hans de Goede wrote: > Before I post a new version of this patch-set, you have only responded > to some of the PWM patches in this set. Do you have any remarks on the > other PWM patches ? I stopped looking at them as I hoped someone would app

Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)

On Monday, 6 July 2020 14:12:24 CEST Neil Armstrong wrote: > > On 06/07/2020 01:57, Paul Boddie wrote: > > > > It also seems to be appropriate to set the input_bus_format on the > > platform- specific HDMI driver; otherwise, I doubt that appropriate bus > > encodings will be chosen in the Synopsy

Re: [PATCH] drm/panfrost: fix ref count leak in panfrost_job_hw_submit

Acked-by: Alyssa Rosenzweig On Sun, Jun 14, 2020 at 01:27:30AM -0500, Navid Emamdoost wrote: > in panfrost_job_hw_submit, pm_runtime_get_sync is called which > increments the counter even in case of failure, leading to incorrect > ref count. In case of failure, decrement the ref count before retu

Re: [PATCH] drm/panfrost: perfcnt: fix ref count leak in panfrost_perfcnt_enable_locked

Acked-by: Alyssa Rosenzweig On Sun, Jun 14, 2020 at 01:36:19AM -0500, Navid Emamdoost wrote: > in panfrost_perfcnt_enable_locked, pm_runtime_get_sync is called which > increments the counter even in case of failure, leading to incorrect > ref count. In case of failure, decrement the ref count bef

[PATCH] fbdev: sm712fb: set error code in probe

If smtcfb_pci_probe() does not detect a valid chip it cleans up everything and returns 0. This can result in various bad things later. The patch sets the error code on the corresponding path. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov --- driver

[PATCH] drm/of: Consider the state in which the ep is disabled

don't mask possible_crtcs if remote-point is disabled. Signed-off-by: Sandy Huang --- drivers/gpu/drm/drm_of.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c index fdb05fbf72a0..f5f250435add 100644 --- a/drivers/gpu/drm/drm_of.c +++ b

Re: [PATCH v3 09/15] pwm: crc: Enable/disable PWM output on enable/disable

Hello, On Sat, Jun 20, 2020 at 02:17:52PM +0200, Hans de Goede wrote: > The pwm-crc code is using 2 different enable bits: > 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE) > 2. bit 0 of the BACKLIGHT_EN register > > So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM, > this

Re: [PATCH v2 00/14] Add regulator devfreq support to Panfrost

Hello Clément, On Sat, Jul 04, 2020 at 12:25:21PM +0200, Clément Péron wrote: > Hi, > > This serie cleans and adds regulator support to Panfrost devfreq. > This is mostly based on comment for the freshly introduced lima > devfreq. I tried to test the series, but I'm unsure what it's meant to be

Re: [PATCH v2 1/8] soc: mediatek: cmdq: add address shift in jump

Hi Matthias, thanks for your comment On Mon, 2020-07-06 at 16:03 +0200, Matthias Brugger wrote: > > On 05/07/2020 08:48, Dennis YC Hsieh wrote: > > Add address shift when compose jump instruction > > to compatible with 35bit format. > > > > Signed-off-by: Dennis YC Hsieh > > You are missing B

Re: [PATCH] drm/dbi: Fix SPI Type 1 (9-bit) transfer

Hi Noralf, Le dim. 5 juil. 2020 à 17:58, Noralf Trønnes a écrit : Den 03.07.2020 16.13, skrev Paul Cercueil: The function mipi_dbi_spi1_transfer() will transfer its payload as 9-bit data, the 9th (MSB) bit being the data/command bit. In order to do that, it unpacks the 8-bit values into

[PATCH] drm/hisilicon/hibmc: Move drm_fbdev_generic_setup() down to avoid the splat

The HiSilicon hibmc driver triggers a splat at boot time as below [ 14.137806] [ cut here ] [ 14.142405] hibmc-drm :0a:00.0: Device has not been registered. [ 14.148661] WARNING: CPU: 0 PID: 496 at drivers/gpu/drm/drm_fb_helper.c:2233 drm_fbdev_generic_setup+0x15

Re: [PATCH v6 2/4] driver core: add deferring probe reason to devices_deferred property

On Thu, Jul 02, 2020 at 08:57:55AM +0200, Andrzej Hajda wrote: > > On 30.06.2020 20:00, Dmitry Torokhov wrote: > > On Tue, Jun 30, 2020 at 8:42 AM Andrzej Hajda wrote: > >> > >> On 30.06.2020 10:59, Grygorii Strashko wrote: > >>> Hi > >>> > >>> On 29/06/2020 14:28, Andrzej Hajda wrote: > Hi

[PATCH v2] drm/hisilicon: Fixed the warning: Assignment of 0/1 to bool variable

fixed the following warning: hibmc_drm_drv.c:296:1-18:WARNING: Assignment of 0/1 to bool variable. hibmc_drm_drv.c:301:2-19: WARNING: Assignment of 0/1 to bool variable. v2: using the pci_dev.msi_enabled instead of priv->msi_enabled. Signed-off-by: Tian Tao --- drivers/gpu/drm/hisilicon/hibmc/h

Re: [PATCH] drm/lima: Expose job_hang_limit module parameter

Hello guys, What is the status of this patch? Was this committed to any branch? Is it pending for merge to the mainline? Do I have to do anything in order to make it mergeable? On 6/19/20 10:58 AM, Andrey Lebedev wrote: From: Andrey Lebedev Some pp or gp jobs can be successfully repeated e

[Proposal] drm: amd: Convert logging to drm_* functions with drm_device parameter

Hii Maintainers, I recently came across this list of janatorial tasks for starters on DRM subsystem [1]. One of the tasks is replacing conventional dmesg macros (like dev_info(), dev_warn() and dev_err()) with DRM dmesg macros [2]. And I need your input whether the conversions to DRM dmesg

[RFC] drm/vgem: Don't use get_page in fault handler.

For pages which are allocated in ttm with transparent huge pages, tail pages have zero as reference count. The current vgem code use get_page on them and it will trigger BUG when release_pages get called on those pages later. Here I attach the minimal code to trigger this bug on a qemu VM which en

Re: [PATCH v2 8/8] soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api

Hi CK, Thanks for your comment. On Tue, 2020-07-07 at 07:46 +0800, Chun-Kuang Hu wrote: > Hi, Dennis: > > Dennis YC Hsieh 於 2020年7月6日 週一 下午3:20寫道： > > > > Add clear parameter to let client decide if > > event should be clear to 0 after GCE receive it. > > > > Fixes: 2f965be7f9008 ("drm/mediatek

Re: [PATCH v2 00/14] Add regulator devfreq support to Panfrost

Patches 1-12 are Reviewed-by: Alyssa Rosenzweig Thank you! On Sat, Jul 04, 2020 at 12:25:21PM +0200, Clément Péron wrote: > Hi, > > This serie cleans and adds regulator support to Panfrost devfreq. > This is mostly based on comment for the freshly introduced lima > devfreq. > > We ne

[PATCH v1] drm/i915: Fix spelling mistake in i915_reg.h

Fix typo: "TRIGER" --> "TRIGGER" The two misplelled macros: 1) OAREPORTTRIG1_EDGE_LEVEL_TRIGER_SELECT_MASK 2) OAREPORTTRIG5_EDGE_LEVEL_TRIGER_SELECT_MASK are not used in any other sources of the kernel, so this change can be consider only a local change for the i915_reg.h file. Signed-off-by: F

Re: [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value

On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote: > Hi, > > Thank you for your review and sorry for the slow reply. No problem for me, I didn't hold my breath :-) > > > diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c > > > index 43b1fc634af1..80d0f9c64f9d 100644 > > >

Re: [PATCH v3 15/15] drm/i915: panel: Use atomic PWM API for devs with an external PWM controller

Hello Hans, On Sat, Jun 20, 2020 at 02:17:58PM +0200, Hans de Goede wrote: > Now that the PWM drivers which we use have been converted to the atomic > PWM API, we can move the i915 panel code over to using the atomic PWM API. Note that there is no hard dependency, the atomic API should work just

Re: [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value

Hi, On 7/7/20 9:34 AM, Uwe Kleine-König wrote: On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote: Hi, Thank you for your review and sorry for the slow reply. No problem for me, I didn't hold my breath :-) diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c index 43b

Re: [RFC] drm/vgem: Don't use get_page in fault handler.

Quoting Lepton Wu (2020-07-07 05:21:00) > For pages which are allocated in ttm with transparent huge pages, > tail pages have zero as reference count. The current vgem code use > get_page on them and it will trigger BUG when release_pages get called > on those pages later. > > Here I attach the mi

[PATCH 7/7] drm/mgag200: Inline mga_crtc_{prepare, commit}() into enable function

There's only trivial code left in mga_crtc_{prepare,commit}(). Merge the functions into the simple pipe's enable function. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/mgag200/mgag200_mode.c | 39 +- 1 file changed, 7 insertions(+), 32 deletions(-) diff --git a/d

[PATCH 3/7] drm/mgag200: Don't set or clear field during modeset

The simple pipe's disable function disables the screen by calling mgag200_disable_screen(). The simple pipe's enable function enables the screen by calling mgag200_enable_display(). During modeset operations the screen is off and remains off. It's only enabled after the modeset has been completed.

[PATCH 4/7] drm/mgag200: Split DPMS function into helpers

Of the DPMS code, only ON and OFF states are used. Simplify mode setting by moving both into separate functions and removing the rest. The DPMS code also set the LUT before enabling the screen. The patch moves this code into the simple-display pipe's enable function. Signed-off-by: Thomas Zimmerm

[PATCH 0/7] drm/mgag200: Inline prepare/commit helpers

Mgag200's modesetting still utilizes the prepare and commit functions that were part of the non-atomic interface. This patchset integrates them into the simple-display's enable function. Patch 1 disables CRTC write protection once when initializing the registers. Before, CRTC registers were tempor

  1   2   >