Re: Kernel panic during drm/nouveau init 5.3.0-rc7-next-20190903
On Mon, Sep 9, 2019 at 1:21 PM Stephen Rothwell wrote: > > Hi, > > On Mon, 9 Sep 2019 20:11:59 +1000 Stephen Rothwell > wrote: > > > > If you are bisecting linux-next, I will suggest bisecting between the > > stable branch on linux-next (which is just Linus' tree when I started > > that day) and the top of the first linux-next that fails. (Assuming > > that the stable branch is good). > > Actually (since you won't be bisecting the latest linux-next), you > probably want to use > > git merge-base stable next-20190903 > (or whatever linux-next you are bisecting) > > as your first good commit (assuming it id good :-)). > > -- > Cheers, > Stephen Rothwell Hi Stephen, Thanks very much for the tips. I'll go ahead and give those a try. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] FBTFT: fb_agm1264k: usleep_range is preferred over udelay
On Mon, Sep 09, 2019 at 10:56:25AM +0100, Greg KH wrote: > On Sun, Sep 08, 2019 at 08:26:05PM -0500, Sreeram Veluthakkal wrote: > > This patch fixes the issue: > > FILE: drivers/staging/fbtft/fb_agm1264k-fl.c:88: > > CHECK: usleep_range is preferred over udelay; see > > Documentation/timers/timers-howto.rst > > + udelay(20); > > > > Signed-off-by: Sreeram Veluthakkal > > --- > > drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c > > b/drivers/staging/fbtft/fb_agm1264k-fl.c > > index ec97ad27..2dece71fd3b5 100644 > > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c > > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c > > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par) > > dev_dbg(par->info->device, "%s()\n", __func__); > > > > gpiod_set_value(par->gpio.reset, 0); > > - udelay(20); > > + usleep_range(20, 40); > > Is it "safe" to wait 40? This kind of change you can only do if you > know this is correct. Have you tested this with hardware? > > thanks, > > greg k-h Hi Greg, No I haven't tested it, I don't have the hw. I dug depeer in to the usleep_range https://github.com/torvalds/linux/blob/master/kernel/time/timer.c#L1993 u64 delta = (u64)(max - min) * NSEC_PER_USEC; * The @delta argument gives the kernel the freedom to schedule the * actual wakeup to a time that is both power and performance friendly. * The kernel give the normal best effort behavior for "@expires+@delta", * but may decide to fire the timer earlier, but no earlier than @expires. My understanding is that keeping delta 0 (min=max=20) would be equivalent. I can revise the patch to usleep_range(20, 20) or usleep_range(20, 21) for a 1 usec delta. What do you suggest? thanks, Sreeram ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Xorg indefinitely hangs in kernelspace
On Mon, 9 Sep 2019 from Gerd Hoffmann
>
> Hmm, I think the patch is wrong.
Hmm...it should have added change only in the error path, leaving locks
for drivers to release if job is done with no error returned.
> As far I know it is the qxl drivers's
> job to call ttm_eu_backoff_reservation().
Like other drivers, qxl is currently doing the right.
> Doing that automatically in
> ttm will most likely break other ttm users.
>
You are right. They are responsible for doing backoff if error happens
while validating buffers afterwards.
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -111,8 +111,10 @@ int ttm_eu_reserve_buffers(struct ww_acq
list_for_each_entry(entry, list, head) {
struct ttm_buffer_object *bo = entry->bo;
+ bool lockon;
ret = __ttm_bo_reserve(bo, intr, (ticket == NULL), ticket);
+ lockon = !ret;
if (!ret && unlikely(atomic_read(&bo->cpu_writers) > 0)) {
reservation_object_unlock(bo->resv);
@@ -151,6 +153,7 @@ int ttm_eu_reserve_buffers(struct ww_acq
ret = 0;
}
}
+ lockon = !ret;
if (!ret && entry->num_shared)
ret = reservation_object_reserve_shared(bo->resv,
@@ -163,6 +166,8 @@ int ttm_eu_reserve_buffers(struct ww_acq
ww_acquire_done(ticket);
ww_acquire_fini(ticket);
}
+ if (lockon)
+ ttm_eu_backoff_reservation_reverse(list, entry);
return ret;
}
--
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Xorg indefinitely hangs in kernelspace
Hi, On Mon, 9 Sep 2019 from Gerd Hoffmann > > Hmm, I think the patch is wrong. As far I know it is the qxl drivers's > job to call ttm_eu_backoff_reservation(). Doing that automatically in > ttm will most likely break other ttm users. > Perhaps. >So I guess the call is missing in the qxl driver somewhere, most likely >in some error handling code path given that this bug is a relatively >rare event. > >There is only a single ttm_eu_reserve_buffers() call in qxl. >So how about this? > No preference in either way if it is a right cure. BTW a quick peep at the mainline tree shows not every ttm_eu_reserve_buffers() pairs with ttm_eu_backoff_reservation() without qxl being taken in account. Hillf ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111622] VAAPI vaDeriveImage returns VA_STATUS_ERROR_OPERATION_FAILED
https://bugs.freedesktop.org/show_bug.cgi?id=111622 Bug ID: 111622 Summary: VAAPI vaDeriveImage returns VA_STATUS_ERROR_OPERATION_FAILED Product: Mesa Version: 19.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: reject5...@naver.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 145311 --> https://bugs.freedesktop.org/attachment.cgi?id=145311&action=edit Sample C code to reproduce error Operating System: archlinux 5.2.13-arch1-1-ARCH GPU: Radeon RX 570 Mesa version: 19.1.6 Libva version: 2.5.0 vaDeriveImage() VAAPI returns VA_STATUS_ERROR_OPERATION_FAILED when radeonsi_drv_video.so used as driver. It runs successfully with i965_drv_video.so on intel integrated GPU. https://bugs.freedesktop.org/show_bug.cgi?id=110850 related to this. I found by debugging that error return occurs in the vlVaDeriveImage function. //vlVaDeriveImage function is in src/gallium/state_trackers/va/image.c if (surf->buffer->interlaced) return VA_STATUS_ERROR_OPERATION_FAILED; Is there a problem with interlaced video in Mesa? I don't know much about computer graphics and how Mesa works, but Intel driver has no problem about it, so I think it's a bug. Sample C code attached to reproduce error. This code was written by referring to the VLC's VAAPI source code. Compile command: gcc -o va va.c -lX11 -lva -lva-x11 -g Result on Radeon GPU system: libva info: VA-API version 1.5.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_5 libva info: va_openDriver() returns 0 vendor string : Mesa Gallium driver 19.1.6 for Radeon RX 570 Series (POLARIS10, DRM 3.32.0, 5.2.13-arch1-1-ARCH, LLVM 8.0.1) vaDeriveImage error : operation failed Result on Intel GPU system: libva info: VA-API version 1.5.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_1_3 libva info: va_openDriver() returns 0 vendor string : Intel i965 driver for Intel(R) Broadwell - 2.3.0 vaDeriveImage : success (no error) -- 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: [Lima] [PATCH] drm/lima: fix lima_gem_wait() return value
I've pushed this patch to drm-misc-fixes: https://cgit.freedesktop.org/drm/drm-misc/commit/?h=drm-misc-fixes&id=21670bd78a25001cf8ef2679b378c73fb73b904f There is a conflict when drm-tip merge process which has been solved by following the doc: https://drm.pages.freedesktop.org/maintainer-tools/drm-tip.html drm_gem_reservation_object_wait() has been renamed to drm_gem_dma_resv_wait() in drm-misc-next and drm-next. Please let me know if I have to also push this fix to drm-misc-next by my own. Thanks, Qiang On Tue, Sep 10, 2019 at 9:16 AM Qiang Yu wrote: > > Thanks Heiko, I'll push this patch to drm-misc-fixes. > > I can add the Fixes tag before push. > > Thanks, > Qiang > > On Tue, Sep 10, 2019 at 12:23 AM Vasily Khoruzhick wrote: > > > > On Mon, Sep 9, 2019 at 5:18 AM Heiko Stübner wrote: > > > > > > Hi Qiang, > > > > > > Am Montag, 9. September 2019, 04:30:43 CEST schrieb Qiang Yu: > > > > Oh, I was miss leading by the drm_gem_reservation_object_wait > > > > comments. Patch is: > > > > Reviewed-by: Qiang Yu > > > > > > > > I'll apply this patch to drm-misc-next. > > > > > > > > Current kernel release is 5.3-rc8, is it too late for this fix to go > > > > into the mainline 5.3 release? > > > > I'd like to know how to apply this fix for current rc kernels, by > > > > drm-misc-fixes? Can I push > > > > to drm-misc-fixes by dim or I can only push to drm-misc-next and > > > > drm-misc maintainer will > > > > pick fixes from it to drm-misc-fixes? > > > > > > drm-misc-fixes gets merged into drm-misc-next by maintainers regularly, > > > so I _think_ you should apply the fix-patch to drm-misc-fixes first. > > > [I also always have to read the documentation ;-) ] > > > > > > In any case you might want to add a "Fixes: ." tag as well as a > > > "Cc: sta...@vger.kernel.org" tag, so it can be backported to stable > > > kernels if applicable. > > > > Cc: stable is already here, but I think it still needs "Fixes: " tag. > > > > Qiang, can you add it at your side or you want me to resend the patch? > > > > > > > > Heiko > > > > > > > On Sun, Sep 8, 2019 at 10:48 AM Vasily Khoruzhick > > > > wrote: > > > > > > > > > > drm_gem_reservation_object_wait() returns 0 if it succeeds and -ETIME > > > > > if it timeouts, but lima driver assumed that 0 is error. > > > > > > > > > > Cc: sta...@vger.kernel.org > > > > > Signed-off-by: Vasily Khoruzhick > > > > > --- > > > > > drivers/gpu/drm/lima/lima_gem.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/lima/lima_gem.c > > > > > b/drivers/gpu/drm/lima/lima_gem.c > > > > > index 477c0f73..b609dc030d6c 100644 > > > > > --- a/drivers/gpu/drm/lima/lima_gem.c > > > > > +++ b/drivers/gpu/drm/lima/lima_gem.c > > > > > @@ -342,7 +342,7 @@ int lima_gem_wait(struct drm_file *file, u32 > > > > > handle, u32 op, s64 timeout_ns) > > > > > timeout = drm_timeout_abs_to_jiffies(timeout_ns); > > > > > > > > > > ret = drm_gem_reservation_object_wait(file, handle, write, > > > > > timeout); > > > > > - if (ret == 0) > > > > > + if (ret == -ETIME) > > > > > ret = timeout ? -ETIMEDOUT : -EBUSY; > > > > > > > > > > return ret; > > > > > -- > > > > > 2.23.0 > > > > > > > > > ___ > > > > lima mailing list > > > > l...@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/lima > > > > > > > > > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Lima] [PATCH] drm/lima: fix lima_gem_wait() return value
Thanks Heiko, I'll push this patch to drm-misc-fixes. I can add the Fixes tag before push. Thanks, Qiang On Tue, Sep 10, 2019 at 12:23 AM Vasily Khoruzhick wrote: > > On Mon, Sep 9, 2019 at 5:18 AM Heiko Stübner wrote: > > > > Hi Qiang, > > > > Am Montag, 9. September 2019, 04:30:43 CEST schrieb Qiang Yu: > > > Oh, I was miss leading by the drm_gem_reservation_object_wait > > > comments. Patch is: > > > Reviewed-by: Qiang Yu > > > > > > I'll apply this patch to drm-misc-next. > > > > > > Current kernel release is 5.3-rc8, is it too late for this fix to go > > > into the mainline 5.3 release? > > > I'd like to know how to apply this fix for current rc kernels, by > > > drm-misc-fixes? Can I push > > > to drm-misc-fixes by dim or I can only push to drm-misc-next and > > > drm-misc maintainer will > > > pick fixes from it to drm-misc-fixes? > > > > drm-misc-fixes gets merged into drm-misc-next by maintainers regularly, > > so I _think_ you should apply the fix-patch to drm-misc-fixes first. > > [I also always have to read the documentation ;-) ] > > > > In any case you might want to add a "Fixes: ." tag as well as a > > "Cc: sta...@vger.kernel.org" tag, so it can be backported to stable > > kernels if applicable. > > Cc: stable is already here, but I think it still needs "Fixes: " tag. > > Qiang, can you add it at your side or you want me to resend the patch? > > > > > Heiko > > > > > On Sun, Sep 8, 2019 at 10:48 AM Vasily Khoruzhick > > > wrote: > > > > > > > > drm_gem_reservation_object_wait() returns 0 if it succeeds and -ETIME > > > > if it timeouts, but lima driver assumed that 0 is error. > > > > > > > > Cc: sta...@vger.kernel.org > > > > Signed-off-by: Vasily Khoruzhick > > > > --- > > > > drivers/gpu/drm/lima/lima_gem.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/lima/lima_gem.c > > > > b/drivers/gpu/drm/lima/lima_gem.c > > > > index 477c0f73..b609dc030d6c 100644 > > > > --- a/drivers/gpu/drm/lima/lima_gem.c > > > > +++ b/drivers/gpu/drm/lima/lima_gem.c > > > > @@ -342,7 +342,7 @@ int lima_gem_wait(struct drm_file *file, u32 > > > > handle, u32 op, s64 timeout_ns) > > > > timeout = drm_timeout_abs_to_jiffies(timeout_ns); > > > > > > > > ret = drm_gem_reservation_object_wait(file, handle, write, > > > > timeout); > > > > - if (ret == 0) > > > > + if (ret == -ETIME) > > > > ret = timeout ? -ETIMEDOUT : -EBUSY; > > > > > > > > return ret; > > > > -- > > > > 2.23.0 > > > > > > > ___ > > > lima mailing list > > > l...@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/lima > > > > > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111591] [radeonsi/Navi] The Bard's Tale IV causes a GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=111591 --- Comment #4 from Shmerl --- Uploaded the trace here (should be valid for 30 days): https://ufile.io/kvf9t1eu Sorry for huge size, there is an unskippable cutscene in the beginning. Compressed with pixz, so should be decompressible using all CPU cores (compatible with regular single threaded decompressing xz as well). -- 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 V5] drm: Add definitions for link training repeaters
This change adds definitions required for Link Training-tunable PHY Repeater, which was introduced in the DP 1.3 specification, and incremented with new features in the DP 1.4*. Changes since V4: - Update commit message - Fix misleading comments related to the spec version Changes since V3: - Replace spaces by tabs Changes since V2: - Drop the kernel-doc comment - Reorder LTTPR according to register offset Changes since V1: - Adjusts registers names to be aligned with spec and the rest of the file - Update spec comment from 1.4 to 1.4a Cc: Abdoulaye Berthe Cc: Harry Wentland Cc: Leo Li Cc: Jani Nikula Cc: Manasi Navare Cc: Ville Syrjälä Signed-off-by: Rodrigo Siqueira Signed-off-by: Abdoulaye Berthe Reviewed-by: Harry Wentland --- include/drm/drm_dp_helper.h | 25 + 1 file changed, 25 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 7972b925a952..b1a9a0dcc177 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -966,6 +966,31 @@ #define DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET 0x69494 #define DP_HDCP_2_2_REG_DBG_OFFSET 0x69518 +/* Link Training (LT)-tunable PHY Repeaters */ +#define DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV 0xf /* 1.3 */ +#define DP_MAX_LINK_RATE_PHY_REPEATER 0xf0001 /* 1.4a */ +#define DP_PHY_REPEATER_CNT0xf0002 /* 1.3 */ +#define DP_PHY_REPEATER_MODE 0xf0003 /* 1.3 */ +#define DP_MAX_LANE_COUNT_PHY_REPEATER 0xf0004 /* 1.4a */ +#define DP_PHY_REPEATER_EXTENDED_WAIT_TIMEOUT 0xf0005 /* 1.4a */ +#define DP_TRAINING_PATTERN_SET_PHY_REPEATER1 0xf0010 /* 1.3 */ +#define DP_TRAINING_LANE0_SET_PHY_REPEATER10xf0011 /* 1.3 */ +#define DP_TRAINING_LANE1_SET_PHY_REPEATER10xf0012 /* 1.3 */ +#define DP_TRAINING_LANE2_SET_PHY_REPEATER10xf0013 /* 1.3 */ +#define DP_TRAINING_LANE3_SET_PHY_REPEATER10xf0014 /* 1.3 */ +#define DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1 0xf0020 /* 1.4a */ +#define DP_TRANSMITTER_CAPABILITY_PHY_REPEATER10xf0021 /* 1.4a */ +#define DP_LANE0_1_STATUS_PHY_REPEATER10xf0030 /* 1.3 */ +#define DP_LANE2_3_STATUS_PHY_REPEATER10xf0031 /* 1.3 */ +#define DP_LANE_ALIGN_STATUS_UPDATED_PHY_REPEATER1 0xf0032 /* 1.3 */ +#define DP_ADJUST_REQUEST_LANE0_1_PHY_REPEATER10xf0033 /* 1.3 */ +#define DP_ADJUST_REQUEST_LANE2_3_PHY_REPEATER10xf0034 /* 1.3 */ +#define DP_SYMBOL_ERROR_COUNT_LANE0_PHY_REPEATER1 0xf0035 /* 1.3 */ +#define DP_SYMBOL_ERROR_COUNT_LANE1_PHY_REPEATER1 0xf0037 /* 1.3 */ +#define DP_SYMBOL_ERROR_COUNT_LANE2_PHY_REPEATER1 0xf0039 /* 1.3 */ +#define DP_SYMBOL_ERROR_COUNT_LANE3_PHY_REPEATER1 0xf003b /* 1.3 */ +#define DP_FEC_STATUS_PHY_REPEATER10xf0290 /* 1.4 */ + /* DP HDCP message start offsets in DPCD address space */ #define DP_HDCP_2_2_AKE_INIT_OFFSETDP_HDCP_2_2_REG_RTX_OFFSET #define DP_HDCP_2_2_AKE_SEND_CERT_OFFSET DP_HDCP_2_2_REG_CERT_RX_OFFSET -- 2.23.0 signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V5] drm: Add link training repeaters addresses
Please, ignore this patch. I just noticed that I sent the wrong version. I resend the correct patch with the title: [PATCH V5] drm: Add definitions for link training repeaters Sorry for this mistake. On 09/09, Siqueira, Rodrigo wrote: > DP 1.3 specification introduces the Link Training-tunable PHY Repeater, > and DP 1.4* supplemented it with new features. In the 1.4a spec, it was > introduced some innovations to make handy to add support for systems > with Thunderbolt or other repeater devices. > > It is important to highlight that DP specification had some updates from > 1.3 through 1.4a. In particular, DP 1.4 defines Repeater_FEC_CAPABILITY > at the address 0xf0004, and DP 1.4a redefined the address 0xf0004 to > DP_MAX_LANE_COUNT_PHY_REPEATER. > > Changes since V4: > - Update commit message > - Fix misleading comments related to the spec version > Changes since V3: > - Replace spaces by tabs > Changes since V2: > - Drop the kernel-doc comment > - Reorder LTTPR according to register offset > Changes since V1: > - Adjusts registers names to be aligned with spec and the rest of the > file > - Update spec comment from 1.4 to 1.4a > > Cc: Abdoulaye Berthe > Cc: Harry Wentland > Cc: Leo Li > Cc: Jani Nikula > Cc: Manasi Navare > Cc: Ville Syrjälä > Signed-off-by: Rodrigo Siqueira > Signed-off-by: Abdoulaye Berthe > Reviewed-by: Harry Wentland > --- > include/drm/drm_dp_helper.h | 26 ++ > 1 file changed, 26 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 7972b925a952..fddcd84601f8 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -966,6 +966,32 @@ > #define DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET 0x69494 > #define DP_HDCP_2_2_REG_DBG_OFFSET 0x69518 > > +/* Link Training (LT)-tunable PHY Repeaters */ > +#define DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV 0xf /* 1.3 */ > +#define DP_MAX_LINK_RATE_PHY_REPEATER0xf0001 /* > 1.4a */ > +#define DP_PHY_REPEATER_CNT 0xf0002 /* 1.3 */ > +#define DP_PHY_REPEATER_MODE 0xf0003 /* 1.3 */ > +#define DP_MAX_LANE_COUNT_PHY_REPEATER 0xf0004 /* > 1.4a */ > +#define DP_Repeater_FEC_CAPABILITY 0xf0004 /* 1.4 */ > +#define DP_PHY_REPEATER_EXTENDED_WAIT_TIMEOUT0xf0005 /* > 1.4a */ > +#define DP_TRAINING_PATTERN_SET_PHY_REPEATER10xf0010 /* > 1.3 */ > +#define DP_TRAINING_LANE0_SET_PHY_REPEATER1 0xf0011 /* 1.3 */ > +#define DP_TRAINING_LANE1_SET_PHY_REPEATER1 0xf0012 /* 1.3 */ > +#define DP_TRAINING_LANE2_SET_PHY_REPEATER1 0xf0013 /* 1.3 */ > +#define DP_TRAINING_LANE3_SET_PHY_REPEATER1 0xf0014 /* 1.3 */ > +#define DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER10xf0020 /* 1.4a */ > +#define DP_TRANSMITTER_CAPABILITY_PHY_REPEATER1 0xf0021 /* > 1.4a */ > +#define DP_LANE0_1_STATUS_PHY_REPEATER1 0xf0030 /* > 1.3 */ > +#define DP_LANE2_3_STATUS_PHY_REPEATER1 0xf0031 /* > 1.3 */ > +#define DP_LANE_ALIGN_STATUS_UPDATED_PHY_REPEATER1 0xf0032 /* 1.3 */ > +#define DP_ADJUST_REQUEST_LANE0_1_PHY_REPEATER1 0xf0033 /* > 1.3 */ > +#define DP_ADJUST_REQUEST_LANE2_3_PHY_REPEATER1 0xf0034 /* > 1.3 */ > +#define DP_SYMBOL_ERROR_COUNT_LANE0_PHY_REPEATER10xf0035 /* 1.3 */ > +#define DP_SYMBOL_ERROR_COUNT_LANE1_PHY_REPEATER10xf0037 /* 1.3 */ > +#define DP_SYMBOL_ERROR_COUNT_LANE2_PHY_REPEATER10xf0039 /* 1.3 */ > +#define DP_SYMBOL_ERROR_COUNT_LANE3_PHY_REPEATER10xf003b /* 1.3 */ > +#define DP_FEC_STATUS_PHY_REPEATER1 0xf0290 /* 1.4 */ > + > /* DP HDCP message start offsets in DPCD address space */ > #define DP_HDCP_2_2_AKE_INIT_OFFSET DP_HDCP_2_2_REG_RTX_OFFSET > #define DP_HDCP_2_2_AKE_SEND_CERT_OFFSET DP_HDCP_2_2_REG_CERT_RX_OFFSET > -- > 2.23.0 -- Rodrigo Siqueira Software Engineer, Advanced Micro Devices (AMD) https://siqueira.tech signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111591] [radeonsi/Navi] The Bard's Tale IV causes a GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=111591 --- Comment #3 from Shmerl --- Is there any way to postpone tracing kick in, to avoid massive size of the file? -- 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 libdrm] meson: Fix sys/mkdev.h detection on Solaris
On Solaris, sys/sysmacros.h has long-deprecated copies of major() & minor()
but not makedev(). sys/mkdev.h has all three and is the preferred choice.
So we check for sys/mkdev.h first, as autoconf's AC_HEADER_MAJOR does.
Fixes build failure with error:
../xf86drm.c: In function ‘drmOpenMinor’:
../xf86drm.c:454:30: error: implicit declaration of function ‘makedev’
[-Werror=implicit-function-declaration]
454 | return drmOpenDevice(makedev(DRM_MAJOR, minor), minor, type);
| ^~~
Signed-off-by: Alan Coopersmith
---
meson.build | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meson.build b/meson.build
index bc5cfc58..a3363c32 100644
--- a/meson.build
+++ b/meson.build
@@ -183,10 +183,10 @@ foreach header : ['sys/sysctl.h', 'sys/select.h',
'alloca.h']
config.set('HAVE_' + header.underscorify().to_upper(),
cc.compiles('#include <@0@>'.format(header), name : '@0@
works'.format(header)))
endforeach
-if cc.has_header_symbol('sys/sysmacros.h', 'major')
- config.set10('MAJOR_IN_SYSMACROS', true)
-elif cc.has_header_symbol('sys/mkdev.h', 'major')
+if cc.has_header_symbol('sys/mkdev.h', 'major')
config.set10('MAJOR_IN_MKDEV', true)
+elif cc.has_header_symbol('sys/sysmacros.h', 'major')
+ config.set10('MAJOR_IN_SYSMACROS', true)
endif
config.set10('HAVE_OPEN_MEMSTREAM', cc.has_function('open_memstream'))
--
2.15.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111591] [radeonsi/Navi] The Bard's Tale IV causes a GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=111591 --- Comment #2 from Shmerl --- I'll try to make a trace. The error message looks like this one: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c?h=v5.3-rc8#n5703 -- 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] drm/tilcdc: include linux/pinctrl/consumer.h again
Hi Arnd,
Thank you for the patch.
On Mon, Sep 09, 2019 at 10:33:57PM +0200, Arnd Bergmann wrote:
> This was apparently dropped by accident in a recent
> cleanup, causing a build failure in some configurations now:
>
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:296:12: error: implicit declaration of
> function 'devm_pinctrl_get_select_default'
> [-Werror,-Wimplicit-function-declaration]
>
> Fixes: fcb57664172e ("drm/tilcdc: drop use of drmP.h")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> index 525dc1c0f1c1..9edcdd7f2b96 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
I'd put this before platform_device.h to keep the headers alphabetically
ordered. Apart from that,
Reviewed-by: Laurent Pinchart
> #include
> #include
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V5] drm: Add link training repeaters addresses
DP 1.3 specification introduces the Link Training-tunable PHY Repeater, and DP 1.4* supplemented it with new features. In the 1.4a spec, it was introduced some innovations to make handy to add support for systems with Thunderbolt or other repeater devices. It is important to highlight that DP specification had some updates from 1.3 through 1.4a. In particular, DP 1.4 defines Repeater_FEC_CAPABILITY at the address 0xf0004, and DP 1.4a redefined the address 0xf0004 to DP_MAX_LANE_COUNT_PHY_REPEATER. Changes since V4: - Update commit message - Fix misleading comments related to the spec version Changes since V3: - Replace spaces by tabs Changes since V2: - Drop the kernel-doc comment - Reorder LTTPR according to register offset Changes since V1: - Adjusts registers names to be aligned with spec and the rest of the file - Update spec comment from 1.4 to 1.4a Cc: Abdoulaye Berthe Cc: Harry Wentland Cc: Leo Li Cc: Jani Nikula Cc: Manasi Navare Cc: Ville Syrjälä Signed-off-by: Rodrigo Siqueira Signed-off-by: Abdoulaye Berthe Reviewed-by: Harry Wentland --- include/drm/drm_dp_helper.h | 26 ++ 1 file changed, 26 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 7972b925a952..fddcd84601f8 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -966,6 +966,32 @@ #define DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET 0x69494 #define DP_HDCP_2_2_REG_DBG_OFFSET 0x69518 +/* Link Training (LT)-tunable PHY Repeaters */ +#define DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV 0xf /* 1.3 */ +#define DP_MAX_LINK_RATE_PHY_REPEATER 0xf0001 /* 1.4a */ +#define DP_PHY_REPEATER_CNT0xf0002 /* 1.3 */ +#define DP_PHY_REPEATER_MODE 0xf0003 /* 1.3 */ +#define DP_MAX_LANE_COUNT_PHY_REPEATER 0xf0004 /* 1.4a */ +#define DP_Repeater_FEC_CAPABILITY 0xf0004 /* 1.4 */ +#define DP_PHY_REPEATER_EXTENDED_WAIT_TIMEOUT 0xf0005 /* 1.4a */ +#define DP_TRAINING_PATTERN_SET_PHY_REPEATER1 0xf0010 /* 1.3 */ +#define DP_TRAINING_LANE0_SET_PHY_REPEATER10xf0011 /* 1.3 */ +#define DP_TRAINING_LANE1_SET_PHY_REPEATER10xf0012 /* 1.3 */ +#define DP_TRAINING_LANE2_SET_PHY_REPEATER10xf0013 /* 1.3 */ +#define DP_TRAINING_LANE3_SET_PHY_REPEATER10xf0014 /* 1.3 */ +#define DP_TRAINING_AUX_RD_INTERVAL_PHY_REPEATER1 0xf0020 /* 1.4a */ +#define DP_TRANSMITTER_CAPABILITY_PHY_REPEATER10xf0021 /* 1.4a */ +#define DP_LANE0_1_STATUS_PHY_REPEATER10xf0030 /* 1.3 */ +#define DP_LANE2_3_STATUS_PHY_REPEATER10xf0031 /* 1.3 */ +#define DP_LANE_ALIGN_STATUS_UPDATED_PHY_REPEATER1 0xf0032 /* 1.3 */ +#define DP_ADJUST_REQUEST_LANE0_1_PHY_REPEATER10xf0033 /* 1.3 */ +#define DP_ADJUST_REQUEST_LANE2_3_PHY_REPEATER10xf0034 /* 1.3 */ +#define DP_SYMBOL_ERROR_COUNT_LANE0_PHY_REPEATER1 0xf0035 /* 1.3 */ +#define DP_SYMBOL_ERROR_COUNT_LANE1_PHY_REPEATER1 0xf0037 /* 1.3 */ +#define DP_SYMBOL_ERROR_COUNT_LANE2_PHY_REPEATER1 0xf0039 /* 1.3 */ +#define DP_SYMBOL_ERROR_COUNT_LANE3_PHY_REPEATER1 0xf003b /* 1.3 */ +#define DP_FEC_STATUS_PHY_REPEATER10xf0290 /* 1.4 */ + /* DP HDCP message start offsets in DPCD address space */ #define DP_HDCP_2_2_AKE_INIT_OFFSETDP_HDCP_2_2_REG_RTX_OFFSET #define DP_HDCP_2_2_AKE_SEND_CERT_OFFSET DP_HDCP_2_2_REG_CERT_RX_OFFSET -- 2.23.0 signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"
On Thu, Sep 5, 2019 at 5:26 PM Rafael J. Wysocki wrote: > > On Thursday, September 5, 2019 5:51:23 PM CEST Karol Herbst wrote: > > is there any update on the testing with my patches? On the hardware I > > had access to those patches helped, but I can't know if it also helped > > on the hardware for which those workarounds where actually added. > > Alex Hung and Mario need to answer this question I think. Sorry for taking a long time. I don't have full testing results yet but we found at least a regression occurred with _OSI string removed - it is not on nVidia hardware but on AMD PX one. I will try to collect and share more details. > > > On Mon, Aug 19, 2019 at 11:52 AM Rafael J. Wysocki > > wrote: > > > > > > On Thursday, August 15, 2019 12:47:35 AM CEST Dave Airlie wrote: > > > > On Thu, 15 Aug 2019 at 07:31, Karol Herbst wrote: > > > > > > > > > > This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c. > > > > > > > > > > The original commit message didn't even make sense. AMD _does_ > > > > > support it and > > > > > it works with Nouveau as well. > > > > > > > > > > Also what was the issue being solved here? No references to any bugs > > > > > and not > > > > > even explaining any issue at all isn't the way we do things. > > > > > > > > > > And even if it means a muxed design, then the fix is to make it work > > > > > inside the > > > > > driver, not adding some hacky workaround through ACPI tricks. > > > > > > > > > > And what out of tree drivers do or do not support we don't care one > > > > > bit anyway. > > > > > > > > > > > > > I think the reverts should be merged via Rafael's tree as the original > > > > patches went in via there, and we should get them in asap. > > > > > > > > Acked-by: Dave Airlie > > > > > > The _OSI strings are to be dropped when all of the needed support is > > > there in > > > drivers, so they should go away along with the requisite driver changes. > > > > > > > that goes beside the point. firmware level workarounds for GPU driver > > issues were pushed without consulting with upstream GPU developers. > > That's something which shouldn't have happened in the first place. And > > yes, I am personally annoyed by the fact, that people know about > > issues, but instead of contacting the proper persons and working on a > > proper fix, we end up with stupid firmware level workarounds. I can't > > see why we ever would have wanted such workarounds in the first place. > > > > And I would be much happier if the next time something like that comes > > up, that the drm mailing list will be contacted as well or somebody > > involved. > > > > We could have also just disable the feature inside the driver (and > > probably we should have done that a long time ago, so that is > > essentially our fault, but still) > > > > > I'm all for dropping then when that's the case, so please feel free to > > > add ACKs > > > from me to the patches in question at that point. > > > > > > Cheers, > > > Rafael > > > > > > > > > > > > > > > -- Cheers, Alex Hung
[PATCH] drm/tilcdc: include linux/pinctrl/consumer.h again
This was apparently dropped by accident in a recent
cleanup, causing a build failure in some configurations now:
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:296:12: error: implicit declaration of
function 'devm_pinctrl_get_select_default'
[-Werror,-Wimplicit-function-declaration]
Fixes: fcb57664172e ("drm/tilcdc: drop use of drmP.h")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index 525dc1c0f1c1..9edcdd7f2b96 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
--
2.20.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] backlight: lm3630a: add an enable gpio for the HWEN pin
On Mon, 9 Sep 2019 11:57:29 +0100
Daniel Thompson wrote:
> On Sun, Sep 08, 2019 at 10:37:03PM +0200, Andreas Kemnade wrote:
> > For now just enable it in the probe function to allow i2c
> > access and disable it on remove. Disabling also means resetting
> > the register values to default.
> >
> > Tested on Kobo Clara HD.
> >
> > Signed-off-by: Andreas Kemnade
> > ---
> > drivers/video/backlight/lm3630a_bl.c | 18 ++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/video/backlight/lm3630a_bl.c
> > b/drivers/video/backlight/lm3630a_bl.c
> > index b04b35d007a2..3b45a1733198 100644
> > --- a/drivers/video/backlight/lm3630a_bl.c
> > +++ b/drivers/video/backlight/lm3630a_bl.c
> > @@ -12,6 +12,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #include
> > #include
> >
> > @@ -48,6 +50,7 @@ struct lm3630a_chip {
> > struct lm3630a_platform_data *pdata;
> > struct backlight_device *bleda;
> > struct backlight_device *bledb;
> > + struct gpio_desc *enable_gpio;
> > struct regmap *regmap;
> > struct pwm_device *pwmd;
> > };
> > @@ -506,6 +509,14 @@ static int lm3630a_probe(struct i2c_client *client,
> > return -ENOMEM;
> > pchip->dev = &client->dev;
> >
> > + pchip->enable_gpio = devm_gpiod_get_optional(&client->dev, "enable",
> > + GPIOD_ASIS);
>
> Initializing GPIOD_ASIS doesn't look right to me.
>
> If you initialize ASIS then the driver must configure the pin as an
> output... far easier just to set GPIOD_OUT_HIGH during the get.
>
> Note also that the call to this function should also be moved *below*
> the calls parse the DT.
>
oops, must have forgotten that, and had good luck here.
>
> > + if (IS_ERR(pchip->enable_gpio)) {
> > + rval = PTR_ERR(pchip->enable_gpio);
> > + return rval;
> > + }
> > +
> > +
> > pchip->regmap = devm_regmap_init_i2c(client, &lm3630a_regmap);
> > if (IS_ERR(pchip->regmap)) {
> > rval = PTR_ERR(pchip->regmap);
> > @@ -535,6 +546,10 @@ static int lm3630a_probe(struct i2c_client *client,
> > }
> > pchip->pdata = pdata;
> >
> > + if (pchip->enable_gpio) {
> > + gpiod_set_value_cansleep(pchip->enable_gpio, 1);
>
> Not needed, use GPIOD_OUT_HIGH instead.
>
>
> > + usleep_range(1000, 2000);
>
> Not needed, this sleep is already part of lm3630a_chip_init().
>
you are right.
>
> > + }
> > /* chip initialize */
> > rval = lm3630a_chip_init(pchip);
> > if (rval < 0) {
> > @@ -586,6 +601,9 @@ static int lm3630a_remove(struct i2c_client *client)
> > if (rval < 0)
> > dev_err(pchip->dev, "i2c failed to access register\n");
> >
> > + if (pchip->enable_gpio)
> > + gpiod_set_value_cansleep(pchip->enable_gpio, 0);
> > +
>
> Is this needed?
>
> This is a remove path, not a power management path, and we have no idea
> what the original status of the pin was anyway?
>
Looking at Ishdn on page 5 of the datasheet, switching it off everytime
possible seems not needed. We would need to call chip_init() everytime
we enable the gpio or live with default values.
Therefore I did decide to not put it into any power management path. But
switching it on and not switching it off feels so unbalanced.
Regards,
Andreas
[Bug 111527] obs-studio + latest mesa on amdgpu/vega64 leaks kernel memory rapidly
https://bugs.freedesktop.org/show_bug.cgi?id=111527 --- Comment #4 from tele4...@hotmail.com --- I reproduced the issue with 7d28e9ddd62eeccf6c528beee6b1a58fdfb7f5a0 + merge request 1907. No visible effect. -- 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] drm: Bump encoder limit from 32 to 64
Finally got a chance to look at this again, some notes below
On Wed, 2019-08-21 at 14:53 +0300, Ville Syrjälä wrote:
> On Tue, Aug 20, 2019 at 08:16:55PM -0400, Lyude Paul wrote:
> > Assuming that GPUs would never have even close to 32 separate video
> > encoders is quite honestly a pretty reasonable assumption. Unfortunately
> > we do not live in a reasonable world, as it looks like it is actually
> > possible to find devices that will create more drm_encoder objects then
> > this. Case in point: the ThinkPad P71's discrete GPU, which exposes 1
> > eDP port and 5 DP ports. On the P71, nouveau attempts to create one
> > encoder for the eDP port, and two encoders for each DP++/USB-C port
> > along with 4 MST encoders for each DP port. This comes out to 35
> > different encoders. Unfortunately, this can't really be optimized to
> > make less encoders either.
> >
> > So, what if we bumped the limit to 64? Unfortunately this has one very
> > awkward drawback: we already expose 32-bit bitmasks for encoders to
> > userspace in drm_encoder->possible_clones. Yikes. While cloning is still
> > (rarely) used in certain modern video hardware, it's mostly used in
> > situations where memory bandwidth is so limited that it's not possible
> > to scan out from 2 CRTCs at once.
> >
> > So, let's try to compromise here: allow encoders with indexes <32 to
> > have non-zero values in drm_encoder->possible_clones, and don't allow
> > encoders with higher indexes to set drm_encoder->possible_clones to a
> > non-zero value. This allows us to avoid breaking UAPI and keep things
> > working sanely for hardware which still uses cloning, while still being
> > able to bump up the encoder limit.
> >
> > This also fixes driver probing for nouveau on the ThinkPad P71.
> >
> > Changes since v1:
> > * Move index+possible_clones check out of drm_encoder_init() and into
> > drm_encoder_register_all(), since encoder->possible_clones can get
> > changed any time before registration - Daniel Vetter
> > * Update the commit message a bit to accurately reflect modern day usage
> > of hardware cloning, which as Daniel Stone pointed out is apparently a
> > thing
> >
> > Signed-off-by: Lyude Paul
> > Cc: nouv...@lists.freedesktop.org
> > ---
> > drivers/gpu/drm/drm_atomic.c | 2 +-
> > drivers/gpu/drm/drm_encoder.c | 12 ++--
> > include/drm/drm_crtc.h| 2 +-
> > include/drm/drm_encoder.h | 20 +++-
> > 4 files changed, 27 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 419381abbdd1..27ce988ef0cc 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -392,7 +392,7 @@ static void drm_atomic_crtc_print_state(struct
> > drm_printer *p,
> > drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed);
> > drm_printf(p, "\tplane_mask=%x\n", state->plane_mask);
> > drm_printf(p, "\tconnector_mask=%x\n", state->connector_mask);
> > - drm_printf(p, "\tencoder_mask=%x\n", state->encoder_mask);
> > + drm_printf(p, "\tencoder_mask=%llx\n", state->encoder_mask);
> > drm_printf(p, "\tmode: " DRM_MODE_FMT "\n", DRM_MODE_ARG(&state-
> > >mode));
> >
> > if (crtc->funcs->atomic_print_state)
> > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> > index 7fb47b7b8b44..9d443b45ebba 100644
> > --- a/drivers/gpu/drm/drm_encoder.c
> > +++ b/drivers/gpu/drm/drm_encoder.c
> > @@ -71,6 +71,14 @@ int drm_encoder_register_all(struct drm_device *dev)
> > int ret = 0;
> >
> > drm_for_each_encoder(encoder, dev) {
> > + /*
> > +* Since possible_clones has been exposed to userspace as a
> > +* 32bit bitmask, we don't allow creating encoders with an
> > +* index >=32 which are capable of cloning
> > +*/
> > + if (WARN_ON(encoder->index >= 32 && encoder->possible_clones))
> > + return -EINVAL;
>
> I believe possible_clones was supposed to include the encoder itself. Not
> really sure why though. I guess we've now decided that it's OK not to do
> that?
>
> git grep tells me drm_atomic_helper.c has some uses of drm_encoder_mask()
> that need to be looked at.
ughh
you're completely right :(, it seems that there are some legacy drivers that
do this. An excerpt from sti_tvout.c:
static void sti_tvout_create_encoders(struct drm_device *dev,
struct sti_tvout *tvout)
{
tvout->hdmi = sti_tvout_create_hdmi_encoder(dev, tvout);
tvout->hda = sti_tvout_create_hda_encoder(dev, tvout);
tvout->dvo = sti_tvout_create_dvo_encoder(dev, tvout);
tvout->hdmi->possible_clones = drm_encoder_mask(tvout->hdmi) |
drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo);
tvout->hda->possible_clones = drm_encoder_mask(tvout->hdmi) |
drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo)
[Bug 111487] AMD vega - display off/on -> solid green display
https://bugs.freedesktop.org/show_bug.cgi?id=111487 --- Comment #6 from bzz --- New kernel, problem still here: [ 242.669782] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:854 dcn10_verify_allow_pstate_change_high.cold+0xc/0x229 [amdgpu] [ 242.669782] Modules linked in: vhost_net vhost tap fuse tun ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables bpfilter scsi_transport_iscsi af_packet br_netfilter bridge stp llc iscsi_ibft iscsi_boot_sysfs msr raid1 dm_raid raid456 md_mod async_raid6_recov async_memcpy async_pq async_xor async_tx nls_iso8859_1 nls_cp437 vfat fat edac_mce_amd kvm_amd ccp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel snd_hda_codec_realtek snd_hda_codec_generic aes_x86_64 crypto_simd ledtrig_audio snd_hda_codec_hdmi cryptd glue_helper eeepc_wmi snd_hda_intel asus_wmi pcspkr sparse_keymap rfkill snd_hda_codec sp5100_tco wmi_bmof k10temp i2c_piix4 snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore r8169 joydev realtek libphy gpio_amdpt gpio_generic pcc_cpufreq button acpi_cpufreq hid_logitech_hidpp btrfs libcrc32c xor uas usb_storage raid6_pq hid_logitech_dj hid_generic usbhid amdgpu crc32c_intel amd_iommu_v2 gpu_sched i2c_algo_bit ttm [ 242.669793] drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm xhci_pci xhci_hcd usbcore wmi video pinctrl_amd sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua efivarfs [ 242.669796] CPU: 2 PID: 183 Comm: kworker/u64:10 Tainted: GW 5.2.11-1-default #1 openSUSE Tumbleweed (unreleased) [ 242.669797] Hardware name: System manufacturer System Product Name/PRIME B450M-A, BIOS 1804 07/29/2019 [ 242.669801] Workqueue: events_unbound commit_work [drm_kms_helper] [ 242.669841] RIP: 0010:dcn10_verify_allow_pstate_change_high.cold+0xc/0x229 [amdgpu] [ 242.669842] Code: 83 c8 ff e9 59 c9 f9 ff 48 c7 c7 b8 4a 7e c0 e8 bc 2c fb e0 0f 0b 83 c8 ff e9 43 c9 f9 ff 48 c7 c7 b8 4a 7e c0 e8 a6 2c fb e0 <0f> 0b 80 bb 93 01 00 00 00 75 05 e9 29 ed f9 ff 48 8b 83 80 02 00 [ 242.669843] RSP: 0018:a7744350bb18 EFLAGS: 00010286 [ 242.669843] RAX: 0024 RBX: 8b6be7aa1000 RCX: 0006 [ 242.669844] RDX: 0007 RSI: 0092 RDI: 8b712ea99a10 [ 242.669844] RBP: 8b6be7aa1000 R08: 0001a53c R09: 0001 [ 242.669844] R10: R11: 0001 R12: 8b6f046181b8 [ 242.669845] R13: R14: 8b6be7aa1000 R15: 8b6f04619318 [ 242.669845] FS: () GS:8b712ea8() knlGS: [ 242.669846] CS: 0010 DS: ES: CR0: 80050033 [ 242.669846] CR2: 000804158a48 CR3: 0007b62f4000 CR4: 003406e0 [ 242.669847] Call Trace: [ 242.669887] dcn10_pipe_control_lock.part.0+0x69/0x70 [amdgpu] [ 242.669925] dc_commit_updates_for_stream+0x901/0xbe0 [amdgpu] [ 242.669963] amdgpu_dm_commit_planes.constprop.0+0x6b4/0x880 [amdgpu] [ 242.670001] amdgpu_dm_atomic_commit_tail+0x9be/0xd30 [amdgpu] [ 242.670002] ? __switch_to_asm+0x40/0x70 [ 242.670003] ? __switch_to_asm+0x34/0x70 [ 242.670003] ? __switch_to_asm+0x40/0x70 [ 242.670004] ? __switch_to_asm+0x34/0x70 [ 242.670004] ? __switch_to_asm+0x40/0x70 [ 242.670005] ? __switch_to_asm+0x34/0x70 [ 242.670005] ? __switch_to_asm+0x40/0x70 [ 242.670006] ? __switch_to_asm+0x34/0x70 [ 242.670006] ? __switch_to_asm+0x40/0x70 [ 242.670008] ? trace_hardirqs_off_thunk+0x1a/0x33 [ 242.670009] ? wait_for_completion_timeout+0xf3/0x110 [ 242.670010] ? finish_task_switch+0x7d/0x290 [ 242.670014] ? commit_tail+0x3c/0x70 [drm_kms_helper] [ 242.670017] commit_tail+0x3c/0x70 [drm_kms_helper] [ 242.670019] process_one_work+0x1df/0x3c0 [ 242.670020] worker_thread+0x4d/0x400 [ 242.670021] kthread+0xf9/0x130 [ 242.670021] ? process_one_work+0x3c0/0x3c0 [ 242.670022] ? kthread_park+0x80/0x80 [ 242.670023] ret_from_fork+0x27/0x50 [ 242.670024] ---[ end trace 253676aaf03c94d7 ]--- [ 242.670609] [drm] pstate TEST_DEBUG_DATA: 0x36F6 [ 242.670610] [ cut here ] [ 242.670658] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer.c:854 dcn10_verify_allow_pstate_change_high.cold+0xc/0x229 [amdgpu] [ 242.670658] Modules linked in: vhost_net vhost tap fuse tun ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables bpfilter scsi_transport_iscsi af_packet br_netfilter bridge stp llc iscsi_ibft iscsi_boot_sysfs msr raid1 dm_raid raid456 md_mod async_raid6_recov async_memcpy async_pq async_xor async_tx nls_iso8859_1 nls_cp437 vfat fat edac_mce_amd kvm_amd ccp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel snd_hda_codec_realtek snd_hda_codec_generic aes_x86_64 crypto_simd ledtrig_audio snd_hda_codec_hdmi cryptd glue_helper eeepc_wmi snd_hda_intel asus_wmi pcspkr sparse_keymap r
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 tempel.jul...@gmail.com changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #80 from tempel.jul...@gmail.com --- Oh my. I've tried the oldest Proton build offered by Steam, which is based on Wine 3.7, and indeed it doesn't show the issue (neither in Oblivion with wined3d OGL nor Hitman 2 DXVK Vulkan). I tried with the older Proton 3.16 version before, which unfortunately is the one that started showing the issue. I don't know why I didn't try 3.7 in the first place. I'm sorry for the time you have invested into this issue. :( Though it would appear to me that the old non-atomic DC is very resilient toward such issues. To be sure, I also tested with untouched Arch 5.2.13 kernel: Without that Wine commit, it is totally free of that stutter issue as well. Pierre-Eric, I reverted that commit c6b6935bb433dbbd30f5ba122a7c45ad3a2d6eed, and indeed, it introduced this issue. Should I create a Wine bug ticket for this? Closing now. Big thanks @ Michel and Nicholas for their great support. AMD's kernel and Linux windowing support is simply outstanding, a dam good reason to stay with team (former) red. :) -- 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 111077] link_shader and deserialize_glsl_program suddenly consume huge amount of RAM
https://bugs.freedesktop.org/show_bug.cgi?id=111077 --- Comment #31 from Matt Turner --- (In reply to rol...@rptd.ch from comment #30) > How I best test this? Just check out the branch and build it or apply it > somehow to the mesa branch I have here from bisecting? wget 'https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1852.patch' and store it in /etc/portage/patches/media-libs/mesa/ Then just rebuild (with portage) a version of Mesa that is known to have the 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
[Bug 111620] [regression][bisected] Virtual Reality HMDs fail to power off when SteamVR closes
https://bugs.freedesktop.org/show_bug.cgi?id=111620 Bug ID: 111620 Summary: [regression][bisected] Virtual Reality HMDs fail to power off when SteamVR closes Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: major Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: andre...@gmail.com When SteamVR is closed the attached HMD no longer powers off. This is due to the display still being driven by the GPU. The first bad commit for this behaviour is: "drm/amd/display: Allow commits with no planes active" https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bc92c06525e5865c94256ef0227bfe870c095823 My understanding is that the commit above does fix a bug in amdgpu/dc. However, due to current Xorg versions failing to shut down outputs after re-claiming a drm lease, this commit ends up breaking userspace. Following is the x server patch to help illustrate what X is doing incorrectly: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/279 Additional reference: https://github.com/ValveSoftware/SteamVR-for-Linux/issues/235 -- 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] drm/virtio: Use vmalloc for command buffer allocations.
On Thu, Sep 5, 2019 at 10:18 PM Gerd Hoffmann wrote:
>
> > +/* How many bytes left in this page. */
> > +static unsigned int rest_of_page(void *data)
> > +{
> > + return PAGE_SIZE - offset_in_page(data);
> > +}
>
> Not needed.
>
> > +/* Create sg_table from a vmalloc'd buffer. */
> > +static struct sg_table *vmalloc_to_sgt(char *data, uint32_t size, int
> > *sg_ents)
> > +{
> > + int nents, ret, s, i;
> > + struct sg_table *sgt;
> > + struct scatterlist *sg;
> > + struct page *pg;
> > +
> > + *sg_ents = 0;
> > +
> > + sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
> > + if (!sgt)
> > + return NULL;
> > +
> > + nents = DIV_ROUND_UP(size, PAGE_SIZE) + 1;
>
> Why +1?
This is part of handling offsets within the vmalloc buffer and to
maintain parity with the !is_vmalloc_addr/existing case (sg_init_one
handles offsets within pages internally). I had left it in because
this is being used for all sg/descriptor generation and I wasn't sure
if someone in the future might do something like:
buf = vmemdup_user()
offset = find_interesting(buf)
queue(buf + offset)
To respond specifically to your question, if we handle offsets, a
vmalloc_to_sgt(size = PAGE_SIZE + 2) could end up with 3 sg_ents with
the +1 being to account for that extra page.
I'll just remove all support for offsets in v3 of the patch and
comment that functionality will be different based on where the buffer
was originally allocated from.
>
> > + ret = sg_alloc_table(sgt, nents, GFP_KERNEL);
> > + if (ret) {
> > + kfree(sgt);
> > + return NULL;
> > + }
> > +
> > + for_each_sg(sgt->sgl, sg, nents, i) {
> > + pg = vmalloc_to_page(data);
> > + if (!pg) {
> > + sg_free_table(sgt);
> > + kfree(sgt);
> > + return NULL;
> > + }
> > +
> > + s = rest_of_page(data);
> > + if (s > size)
> > + s = size;
>
> vmalloc memory is page aligned, so:
As per above, will remove with v3.
>
> s = min(PAGE_SIZE, size);
>
> > + sg_set_page(sg, pg, s, offset_in_page(data));
>
> Offset is always zero.
As per above, will remove with v3.
>
> > +
> > + size -= s;
> > + data += s;
> > + *sg_ents += 1;
>
> sg_ents isn't used anywhere.
It's used for outcnt.
>
> > +
> > + if (size) {
> > + sg_unmark_end(sg);
> > + } else {
> > + sg_mark_end(sg);
> > + break;
> > + }
>
> That looks a bit strange. I guess you need only one of the two because
> the other is the default?
I was being overly paranoid and not wanting to make assumptions about
the initial state of the table. I'll simplify.
>
> > static int virtio_gpu_queue_fenced_ctrl_buffer(struct virtio_gpu_device
> > *vgdev,
> > struct virtio_gpu_vbuffer
> > *vbuf,
> > struct virtio_gpu_ctrl_hdr
> > *hdr,
> > struct virtio_gpu_fence *fence)
> > {
> > struct virtqueue *vq = vgdev->ctrlq.vq;
> > + struct scatterlist *vout = NULL, sg;
> > + struct sg_table *sgt = NULL;
> > int rc;
> > + int outcnt = 0;
> > +
> > + if (vbuf->data_size) {
> > + if (is_vmalloc_addr(vbuf->data_buf)) {
> > + sgt = vmalloc_to_sgt(vbuf->data_buf, vbuf->data_size,
> > + &outcnt);
> > + if (!sgt)
> > + return -ENOMEM;
> > + vout = sgt->sgl;
> > + } else {
> > + sg_init_one(&sg, vbuf->data_buf, vbuf->data_size);
> > + vout = &sg;
> > + outcnt = 1;
>
> outcnt must be set in both cases.
outcnt is set by vmalloc_to_sgt.
>
> > +static int virtio_gpu_queue_ctrl_buffer(struct virtio_gpu_device *vgdev,
> > + struct virtio_gpu_vbuffer *vbuf)
> > +{
> > + return virtio_gpu_queue_fenced_ctrl_buffer(vgdev, vbuf, NULL, NULL);
> > +}
>
> Changing virtio_gpu_queue_ctrl_buffer to call
> virtio_gpu_queue_fenced_ctrl_buffer should be done in a separate patch.
Will do.
Thanks,
David
[Bug 111077] link_shader and deserialize_glsl_program suddenly consume huge amount of RAM
https://bugs.freedesktop.org/show_bug.cgi?id=111077 --- Comment #30 from rol...@rptd.ch --- How I best test this? Just check out the branch and build it or apply it somehow to the mesa branch I have here from bisecting? -- 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] drm/panfrost: Fix regulator_get_optional() misuse
On 09/09/2019 16:41, Rob Herring wrote:
> On Fri, Sep 6, 2019 at 4:23 PM Steven Price wrote:
>>
>> On 04/09/2019 13:30, Mark Brown wrote:
>>> The panfrost driver requests a supply using regulator_get_optional()
>>> but both the name of the supply and the usage pattern suggest that it is
>>> being used for the main power for the device and is not at all optional
>>> for the device for function, there is no meaningful handling for absent
>>> supplies. Such regulators should use the vanilla regulator_get()
>>> interface, it will ensure that even if a supply is not described in the
>>> system integration one will be provided in software.
>>>
>>> Signed-off-by: Mark Brown
>>
>> Tested-by: Steven Price
>>
>> Looks like my approach to this was wrong - so we should also revert the
>> changes I made previously.
>>
>> 8<
>> From fe20f8abcde8444bb41a8f72fb35de943a27ec5c Mon Sep 17 00:00:00 2001
>> From: Steven Price
>> Date: Fri, 6 Sep 2019 15:20:53 +0100
>> Subject: [PATCH] drm/panfrost: Revert changes to cope with NULL regulator
>>
>> Handling a NULL return from devm_regulator_get_optional() doesn't seem
>> like the correct way of handling this. Instead revert the changes in
>> favour of switching to using devm_regulator_get() which will return a
>> dummy regulator instead.
>>
>> Reverts commit 52282163dfa6 ("drm/panfrost: Add missing check for
>> pfdev->regulator")
>> Reverts commit e21dd290881b ("drm/panfrost: Enable devfreq to work without
>> regulator")
>
> Does a straight revert of these 2 patches not work? If it does work,
> can you do that and send to the list. I don't want my hand slapped
> again reverting things.
I wasn't sure what was best here - 52282163dfa6 is a bug fix, so
reverting that followed by e21dd290881b would (re-)introduce a
regression for that one commit (i.e. not completely bisectable).
Reverting in the other order would work, but seems a little odd.
Squashing the reverts seemed the neatest option - but it's not my hand
at risk... :)
Perhaps it would be best to simply apply Mark's change followed by
something like the following. That way it's not actually a revert!
It also avoids (re-)adding the now redundant check in
panfrost_devfreq_init().
Steve
---8<
From fb2956acdf46ca04095ef11363c136dc94a1ab18 Mon Sep 17 00:00:00 2001
From: Steven Price
Date: Fri, 6 Sep 2019 15:20:53 +0100
Subject: [PATCH] drm/panfrost: Remove NULL checks for regulator
devm_regulator_get() is now used to populate pfdev->regulator which
ensures that this cannot be NULL (a dummy regulator will be returned if
necessary). So remove the checks in panfrost_devfreq_target().
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index a1f5fa6a742a..12ff77dacc95 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -39,7 +39,7 @@ static int panfrost_devfreq_target(struct device *dev,
unsigned long *freq,
* If frequency scaling from low to high, adjust voltage first.
* If frequency scaling from high to low, adjust frequency first.
*/
- if (old_clk_rate < target_rate && pfdev->regulator) {
+ if (old_clk_rate < target_rate) {
err = regulator_set_voltage(pfdev->regulator, target_volt,
target_volt);
if (err) {
@@ -53,14 +53,12 @@ static int panfrost_devfreq_target(struct device *dev,
unsigned long *freq,
if (err) {
dev_err(dev, "Cannot set frequency %lu (%d)\n", target_rate,
err);
- if (pfdev->regulator)
- regulator_set_voltage(pfdev->regulator,
- pfdev->devfreq.cur_volt,
- pfdev->devfreq.cur_volt);
+ regulator_set_voltage(pfdev->regulator, pfdev->devfreq.cur_volt,
+ pfdev->devfreq.cur_volt);
return err;
}
- if (old_clk_rate > target_rate && pfdev->regulator) {
+ if (old_clk_rate > target_rate) {
err = regulator_set_voltage(pfdev->regulator, target_volt,
target_volt);
if (err)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Lima] [PATCH] drm/lima: fix lima_gem_wait() return value
On Mon, Sep 9, 2019 at 5:18 AM Heiko Stübner wrote: > > Hi Qiang, > > Am Montag, 9. September 2019, 04:30:43 CEST schrieb Qiang Yu: > > Oh, I was miss leading by the drm_gem_reservation_object_wait > > comments. Patch is: > > Reviewed-by: Qiang Yu > > > > I'll apply this patch to drm-misc-next. > > > > Current kernel release is 5.3-rc8, is it too late for this fix to go > > into the mainline 5.3 release? > > I'd like to know how to apply this fix for current rc kernels, by > > drm-misc-fixes? Can I push > > to drm-misc-fixes by dim or I can only push to drm-misc-next and > > drm-misc maintainer will > > pick fixes from it to drm-misc-fixes? > > drm-misc-fixes gets merged into drm-misc-next by maintainers regularly, > so I _think_ you should apply the fix-patch to drm-misc-fixes first. > [I also always have to read the documentation ;-) ] > > In any case you might want to add a "Fixes: ." tag as well as a > "Cc: sta...@vger.kernel.org" tag, so it can be backported to stable > kernels if applicable. Cc: stable is already here, but I think it still needs "Fixes: " tag. Qiang, can you add it at your side or you want me to resend the patch? > > Heiko > > > On Sun, Sep 8, 2019 at 10:48 AM Vasily Khoruzhick > > wrote: > > > > > > drm_gem_reservation_object_wait() returns 0 if it succeeds and -ETIME > > > if it timeouts, but lima driver assumed that 0 is error. > > > > > > Cc: sta...@vger.kernel.org > > > Signed-off-by: Vasily Khoruzhick > > > --- > > > drivers/gpu/drm/lima/lima_gem.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/lima/lima_gem.c > > > b/drivers/gpu/drm/lima/lima_gem.c > > > index 477c0f73..b609dc030d6c 100644 > > > --- a/drivers/gpu/drm/lima/lima_gem.c > > > +++ b/drivers/gpu/drm/lima/lima_gem.c > > > @@ -342,7 +342,7 @@ int lima_gem_wait(struct drm_file *file, u32 handle, > > > u32 op, s64 timeout_ns) > > > timeout = drm_timeout_abs_to_jiffies(timeout_ns); > > > > > > ret = drm_gem_reservation_object_wait(file, handle, write, > > > timeout); > > > - if (ret == 0) > > > + if (ret == -ETIME) > > > ret = timeout ? -ETIMEDOUT : -EBUSY; > > > > > > return ret; > > > -- > > > 2.23.0 > > > > > ___ > > lima mailing list > > l...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/lima > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111588] Framebuffer corruption when a fb which is not being scanned out gets removed
https://bugs.freedesktop.org/show_bug.cgi?id=111588 --- Comment #2 from Michel Dänzer --- (In reply to Hans de Goede from comment #0) > 5) Plymouth internally calls src/plugins/renderers/drm/plugin.c: >ply_renderer_buffer_free() this does: > drmModeRmFB(...); > munmap (buffer->map_address, buffer->map_size); > destroy_dumb_buffer_request.handle = buffer->handle; > drmIoctl (fd, DRM_IOCTL_MODE_DESTROY_DUMB, &destroy_dumb_buffer_request); >Followed by calling close() on the fd. > 6) Plymouth exits > 7) 5 and/or 6 cause the gdm framebuffer being all messed up, it looks like a >wrong pitch or tiling setting Would be interesting if you could further narrow down which step (or even sub-step of 5) exactly triggers the problem. -- 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
HDCP Content Type Interface
Hi all, This is regarding the recent hdcp content type patch that was merged into drm-misc. (https://patchwork.freedesktop.org/patch/320958/?series=57233&rev=11) There are displays on the market that advertise HDCP 2.2 support and will pass authentication and encryption but will then show a corrupted/blue/black screen (the driver cannot detect this). These displays work with HDCP 1.4 without any issues. Due to the large number of HDCP-supporting devices on the market we might not be able to catch them with a blacklist. From the user modes perspective, HDCP1.4 and HDCP2.2 Type0 are the same thing. Meaning that this interface doesn't allow us to force the hdcp version. Due to the problems mentioned above we might want to expose the ability for a user to force an HDCP downgrade to a certain level (e.g. 1.4) in case they experience problems. What are your thoughts? and what would be a good way to deal with it? Thanks, Bhawan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH] drm/panfrost: Reduce the amount of logs on deferred probe
There is no point to print deferred probe (and its failures to get resources) as an error. In case of multiple probe tries this would pollute the dmesg. Signed-off-by: Krzysztof Kozlowski --- drivers/gpu/drm/panfrost/panfrost_device.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c b/drivers/gpu/drm/panfrost/panfrost_device.c index 46b0b02e4289..2252147bc285 100644 --- a/drivers/gpu/drm/panfrost/panfrost_device.c +++ b/drivers/gpu/drm/panfrost/panfrost_device.c @@ -95,7 +95,9 @@ static int panfrost_regulator_init(struct panfrost_device *pfdev) pfdev->regulator = NULL; if (ret == -ENODEV) return 0; - dev_err(pfdev->dev, "failed to get regulator: %d\n", ret); + if (ret != -EPROBE_DEFER) + dev_err(pfdev->dev, "failed to get regulator: %d\n", + ret); return ret; } -- 2.17.1
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #79 from Pierre-Eric Pelloux-Prayer
---
(In reply to Michel Dänzer from comment #76)
> (In reply to tempel.julian from comment #75)
> > Is it possible that Wine or the affected programs in Wine are the clients
> > that are at fault for this?
>
> Certainly. It looks like the intention is to prevent the monitors from
> entering power saving mode.
Maybe the code from this wine patch
https://www.winehq.org/pipermail/wine-devel/2018-July/129014.html
("winex11.drv: Wake up the display on user input") is causing this?
(adding a breakpoint in wine for the XResetScreenSaver function should confirm)
--
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] drm/panfrost: Fix regulator_get_optional() misuse
On Fri, Sep 6, 2019 at 4:23 PM Steven Price wrote:
>
> On 04/09/2019 13:30, Mark Brown wrote:
> > The panfrost driver requests a supply using regulator_get_optional()
> > but both the name of the supply and the usage pattern suggest that it is
> > being used for the main power for the device and is not at all optional
> > for the device for function, there is no meaningful handling for absent
> > supplies. Such regulators should use the vanilla regulator_get()
> > interface, it will ensure that even if a supply is not described in the
> > system integration one will be provided in software.
> >
> > Signed-off-by: Mark Brown
>
> Tested-by: Steven Price
>
> Looks like my approach to this was wrong - so we should also revert the
> changes I made previously.
>
> 8<
> From fe20f8abcde8444bb41a8f72fb35de943a27ec5c Mon Sep 17 00:00:00 2001
> From: Steven Price
> Date: Fri, 6 Sep 2019 15:20:53 +0100
> Subject: [PATCH] drm/panfrost: Revert changes to cope with NULL regulator
>
> Handling a NULL return from devm_regulator_get_optional() doesn't seem
> like the correct way of handling this. Instead revert the changes in
> favour of switching to using devm_regulator_get() which will return a
> dummy regulator instead.
>
> Reverts commit 52282163dfa6 ("drm/panfrost: Add missing check for
> pfdev->regulator")
> Reverts commit e21dd290881b ("drm/panfrost: Enable devfreq to work without
> regulator")
Does a straight revert of these 2 patches not work? If it does work,
can you do that and send to the list. I don't want my hand slapped
again reverting things.
Rob
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #78 from Michel Dänzer --- (In reply to tempel.julian from comment #77) > I turned DPMS off in Xorg config which leaves the issue unchanged. Is this > to be expected? Yeah, this isn't directly related to X's DPMS functionality. -- 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 AUTOSEL 4.19 044/167] drm/amdgpu: validate user pitch alignment
On 2019-09-07 4:58 p.m., Alex Deucher wrote: > > The patch shuffling doesn't help, but regardless, the same thing could > happen even with a direct committer tree if someone missed the tag when > committing. True, but in the latter case it would at least be possible to add tags referencing persistent commit hashes regardless of when fix-ups happen, whereas with the former this isn't possible before the original change makes it to Linus or at least Dave. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #77 from tempel.jul...@gmail.com --- (In reply to Michel Dänzer from comment #76) > Certainly. It looks like the intention is to prevent the monitors from > entering power saving mode. I turned DPMS off in Xorg config which leaves the issue unchanged. Is this to be expected? I'll open a ticket for the issue on the Wine tracker, but I'd still be happy to try out any patch for Xorg or 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
[Bug 111527] obs-studio + latest mesa on amdgpu/vega64 leaks kernel memory rapidly
https://bugs.freedesktop.org/show_bug.cgi?id=111527 --- Comment #3 from Michel Dänzer --- Does https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1907 help by any chance? -- 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 109246] HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=109246 Jean Delvare changed: What|Removed |Added CC||jdelv...@suse.de --- Comment #28 from Jean Delvare --- Same problem here. Radeon RX 550 with 2 identical Lenovo P27h-10 displays configured in side-by-side mode, one over DisplayPort and one over HDMI, kernel 5.2.11. When the displays go to sleep, the multi-display configuration is lost, displays are in mirror mode when waking up, and I must configure them again. Booting with amdgpu.dc=0 works around the problem (thanks Michel for the hint!) -- 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: [LKP] [drm/mgag200] 90f479ae51: vm-scalability.median -18.8% regression
Hi Am 04.09.19 um 08:27 schrieb Feng Tang: > Hi Thomas, > > On Wed, Aug 28, 2019 at 12:51:40PM +0200, Thomas Zimmermann wrote: >> Hi >> >> Am 28.08.19 um 11:37 schrieb Rong Chen: >>> Hi Thomas, >>> >>> On 8/28/19 1:16 AM, Thomas Zimmermann wrote: Hi Am 27.08.19 um 14:33 schrieb Chen, Rong A: > Both patches have little impact on the performance from our side. Thanks for testing. Too bad they doesn't solve the issue. There's another patch attached. Could you please tests this as well? Thanks a lot! The patch comes from Daniel Vetter after discussing the problem on IRC. The idea of the patch is that the old mgag200 code might display much less frames that the generic code, because mgag200 only prints from non-atomic context. If we simulate this with the generic code, we should see roughly the original performance. >>> >>> It's cool, the patch "usecansleep.patch" can fix the issue. >> >> Thank you for testing. But don't get too excited, because the patch >> simulates a bug that was present in the original mgag200 code. A >> significant number of frames are simply skipped. That is apparently the >> reason why it's faster. > > Thanks for the detailed info, so the original code skips time-consuming > work inside atomic context on purpose. Is there any space to optmise it? > If 2 scheduled update worker are handled at almost same time, can one be > skipped? We discussed ideas on IRC and decided that screen updates could be synchronized with vblank intervals. This may give some rate limiting to the output. If you like, you could try the patch set at [1]. It adds the respective code to console and mgag200. Best regards Thomas [1] https://lists.freedesktop.org/archives/dri-devel/2019-September/234850.html > > Thanks, > Feng > >> >> Best regards >> Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/mgag200: Add vblank support
Support for vblank requires VSYNC to signal an interrupt, which is broken
on Matrox chipsets. The workaround that is used here and in other free
Matrox drivers is to program to the value of and
enable the VLINE interrupt. This triggers an interrupt at the same time
when VSYNC begins.
VLINE uses separate registers for enabling and clearing pending interrupts.
No extra syncronization between irq handler and the rest of the driver is
required.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 1 +
drivers/gpu/drm/mgag200/mgag200_drv.h | 1 +
drivers/gpu/drm/mgag200/mgag200_main.c | 33
drivers/gpu/drm/mgag200/mgag200_mode.c | 42 +++---
4 files changed, 73 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index 4f9df3b93598..cff265973154 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -67,6 +67,7 @@ static struct drm_driver driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET,
.load = mgag200_driver_load,
.unload = mgag200_driver_unload,
+ .irq_handler = mgag200_irq_handler,
.fops = &mgag200_driver_fops,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 1c93f8dc08c7..88cf256d135f 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -195,6 +195,7 @@ void mgag200_modeset_fini(struct mga_device *mdev);
/* mgag200_main.c */
int mgag200_driver_load(struct drm_device *dev, unsigned long flags);
void mgag200_driver_unload(struct drm_device *dev);
+irqreturn_t mgag200_irq_handler(int irq, void *arg);
/* mgag200_i2c.c */
struct mga_i2c_chan *mgag200_i2c_create(struct drm_device *dev);
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index a9773334dedf..5941607796e8 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -10,7 +10,9 @@
#include
#include
+#include
#include
+#include
#include "mgag200_drv.h"
@@ -186,10 +188,18 @@ int mgag200_driver_load(struct drm_device *dev, unsigned
long flags)
}
mdev->cursor.pixels_current = NULL;
+ r = drm_vblank_init(dev, 1);
+ if (r)
+ goto err_modeset;
+
r = drm_fbdev_generic_setup(mdev->dev, 0);
if (r)
goto err_modeset;
+ r = drm_irq_install(dev, dev->pdev->irq);
+ if (r)
+ goto err_modeset;
+
return 0;
err_modeset:
@@ -207,8 +217,31 @@ void mgag200_driver_unload(struct drm_device *dev)
if (mdev == NULL)
return;
+ drm_irq_uninstall(dev);
mgag200_modeset_fini(mdev);
drm_mode_config_cleanup(dev);
mgag200_mm_fini(mdev);
dev->dev_private = NULL;
}
+
+irqreturn_t mgag200_irq_handler(int irq, void *arg)
+{
+ struct drm_device *dev = arg;
+ struct mga_device *mdev = dev->dev_private;
+ struct drm_crtc *crtc;
+ u32 status, iclear;
+
+ status = RREG32(0x1e14);
+
+ if (status & 0x0020) { /* test */
+ drm_for_each_crtc(crtc, dev) {
+ drm_crtc_handle_vblank(crtc);
+ }
+ iclear = RREG32(0x1e18);
+ iclear |= 0x0020; /* set */
+ WREG32(0x1e18, iclear);
+ return IRQ_HANDLED;
+ }
+
+ return IRQ_NONE;
+};
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 5e778b5f1a10..ffe5f15d0a7d 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -905,6 +905,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
const struct drm_framebuffer *fb = crtc->primary->fb;
int hdisplay, hsyncstart, hsyncend, htotal;
int vdisplay, vsyncstart, vsyncend, vtotal;
+ int linecomp;
int pitch;
int option = 0, option2 = 0;
int i;
@@ -1042,6 +1043,13 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
vsyncend = mode->vsync_end - 1;
vtotal = mode->vtotal - 2;
+ /* The VSYNC interrupt is broken on Matrox chipsets. We use
+* the VLINE interrupt instead. It triggers when the current
+* linecomp has been reached. Therefore keep in
+* sync with .
+*/
+ linecomp = vdisplay;
+
WREG_GFX(0, 0);
WREG_GFX(1, 0);
WREG_GFX(2, 0);
@@ -1063,12 +1071,12 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
((vdisplay & 0x100) >> 7) |
((vsyncstart & 0x100) >> 6) |
((vdisplay & 0x100) >> 5) |
-((vdisplay & 0x100) >> 4) | /* linecomp */
+
[PATCH 0/2] Rate-limit shadow-FB-to-console-update to screen refresh
A full-screen memcpy() moves the console's shadow buffer to hardware; with possibly significant runtime overhead. [1] The console's dirty worker now waits for the vblank to rate limit the output frequency. Screen output can pile up while waiting and there's a chance that multiple screen updates can be handled with a single memcpy(). Note that this has no effect on tearing: while the dirty worker updates the hardware buffer, new data can still arrive in the shadow buffer. This can create a tearing effcet, even though console output is synchronized to vblank. The patchset adds vblank support to mgag200, because the problem was first reported with Matrox hardware. [1] https://lists.freedesktop.org/archives/dri-devel/2019-July/228663.html Thomas Zimmermann (2): drm/fb-helper: Synchronize dirty worker with vblank drm/mgag200: Add vblank support drivers/gpu/drm/drm_fb_helper.c| 12 drivers/gpu/drm/mgag200/mgag200_drv.c | 1 + drivers/gpu/drm/mgag200/mgag200_drv.h | 1 + drivers/gpu/drm/mgag200/mgag200_main.c | 33 drivers/gpu/drm/mgag200/mgag200_mode.c | 42 +++--- 5 files changed, 85 insertions(+), 4 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/fb-helper: Synchronize dirty worker with vblank
Before updating the display from the console's shadow buffer, the dirty
worker now waits for vblank. This allows several screen updates to pile
up and acts as a rate limiter.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a7ba5b4902d6..017e2f6bd1b9 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -402,8 +402,20 @@ static void drm_fb_helper_dirty_work(struct work_struct
*work)
dirty_work);
struct drm_clip_rect *clip = &helper->dirty_clip;
struct drm_clip_rect clip_copy;
+ struct drm_crtc *crtc;
unsigned long flags;
void *vaddr;
+ int ret;
+
+ /* rate-limit update frequency */
+ mutex_lock(&helper->lock);
+ crtc = helper->client.modesets[0].crtc;
+ ret = drm_crtc_vblank_get(crtc);
+ if (!ret) {
+ drm_crtc_wait_one_vblank(crtc);
+ drm_crtc_vblank_put(crtc);
+ }
+ mutex_unlock(&helper->lock);
spin_lock_irqsave(&helper->dirty_lock, flags);
clip_copy = *clip;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110659] pageflipping seems to cause jittering on mouse input when running Hitman 2 in Wine/DXVK with amdgpu.dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=110659 --- Comment #76 from Michel Dänzer --- (In reply to tempel.julian from comment #75) > Is it possible that Wine or the affected programs in Wine are the clients > that are at fault for this? Certainly. It looks like the intention is to prevent the monitors from entering power saving mode. -- 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 0/5] Add HDMI jack support on RK3288
On Mon, Sep 09, 2019 at 09:37:14AM +0200, Neil Armstrong wrote: > I'd like some review from ASoC people and other drm bridge reviewers, > Jernej, Jonas & Andrzej. > Jonas could have some comments on the overall patchset. The ASoC bits look basically fine, I've gone ahead and applied patch 1 as is since we're just before the merge window and that way we reduce potential cross tree issues. I know there's a lot of discussion on the DRM side about how they want to handle things with jacks, I'm not 100% sure what the latest thinking is there. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: include: fix W=1 warnings in struct drm_dsc_config
Change scale_increment_interval and nfl_bpg_offset fields to
u32 to avoid W=1 warnings because we are testing them against
65535.
Signed-off-by: Benjamin Gaignard
---
include/drm/drm_dsc.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/drm/drm_dsc.h b/include/drm/drm_dsc.h
index 887954cbfc60..e495024e901c 100644
--- a/include/drm/drm_dsc.h
+++ b/include/drm/drm_dsc.h
@@ -207,11 +207,13 @@ struct drm_dsc_config {
* Number of group times between incrementing the scale factor value
* used at the beginning of a slice.
*/
- u16 scale_increment_interval;
+ u32 scale_increment_interval;
+
/**
* @nfl_bpg_offset: Non first line BPG offset to be used
*/
- u16 nfl_bpg_offset;
+
+ u32 nfl_bpg_offset;
/**
* @slice_bpg_offset: BPG offset used to enforce slice bit
*/
--
2.15.0
[PATCH] drm: atomic helper: fix W=1 warnings
Fix warnings with W=1.
Few for_each macro set variables that are never used later.
Prevent warning by marking these variables as __maybe_unused.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/drm_atomic_helper.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index aa16ea17ff9b..b69d17b0b9bd 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -262,7 +262,7 @@ steal_encoder(struct drm_atomic_state *state,
struct drm_encoder *encoder)
{
struct drm_crtc_state *crtc_state;
- struct drm_connector *connector;
+ struct drm_connector __maybe_unused *connector;
struct drm_connector_state *old_connector_state, *new_connector_state;
int i;
@@ -412,7 +412,7 @@ mode_fixup(struct drm_atomic_state *state)
{
struct drm_crtc *crtc;
struct drm_crtc_state *new_crtc_state;
- struct drm_connector *connector;
+ struct drm_connector __maybe_unused *connector;
struct drm_connector_state *new_conn_state;
int i;
int ret;
@@ -608,7 +608,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
{
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
- struct drm_connector *connector;
+ struct drm_connector __maybe_unused *connector;
struct drm_connector_state *old_connector_state, *new_connector_state;
int i, ret;
unsigned connectors_mask = 0;
@@ -984,7 +984,7 @@ crtc_needs_disable(struct drm_crtc_state *old_state,
static void
disable_outputs(struct drm_device *dev, struct drm_atomic_state *old_state)
{
- struct drm_connector *connector;
+ struct drm_connector __maybe_unused *connector;
struct drm_connector_state *old_conn_state, *new_conn_state;
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
@@ -1173,7 +1173,7 @@ crtc_set_mode(struct drm_device *dev, struct
drm_atomic_state *old_state)
{
struct drm_crtc *crtc;
struct drm_crtc_state *new_crtc_state;
- struct drm_connector *connector;
+ struct drm_connector __maybe_unused *connector;
struct drm_connector_state *new_conn_state;
int i;
@@ -1294,7 +1294,7 @@ void drm_atomic_helper_commit_modeset_enables(struct
drm_device *dev,
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state;
struct drm_crtc_state *new_crtc_state;
- struct drm_connector *connector;
+ struct drm_connector __maybe_unused *connector;
struct drm_connector_state *new_conn_state;
int i;
@@ -1384,7 +1384,7 @@ int drm_atomic_helper_wait_for_fences(struct drm_device
*dev,
struct drm_atomic_state *state,
bool pre_swap)
{
- struct drm_plane *plane;
+ struct drm_plane __maybe_unused *plane;
struct drm_plane_state *new_plane_state;
int i, ret;
@@ -1431,7 +1431,7 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
struct drm_atomic_state *old_state)
{
struct drm_crtc *crtc;
- struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+ struct drm_crtc_state __maybe_unused *old_crtc_state, *new_crtc_state;
int i, ret;
unsigned crtc_mask = 0;
@@ -1621,7 +1621,7 @@ static void commit_work(struct work_struct *work)
int drm_atomic_helper_async_check(struct drm_device *dev,
struct drm_atomic_state *state)
{
- struct drm_crtc *crtc;
+ struct drm_crtc __maybe_unused *crtc;
struct drm_crtc_state *crtc_state;
struct drm_plane *plane = NULL;
struct drm_plane_state *old_plane_state = NULL;
@@ -1982,9 +1982,9 @@ int drm_atomic_helper_setup_commit(struct
drm_atomic_state *state,
{
struct drm_crtc *crtc;
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
- struct drm_connector *conn;
+ struct drm_connector __maybe_unused *conn;
struct drm_connector_state *old_conn_state, *new_conn_state;
- struct drm_plane *plane;
+ struct drm_plane __maybe_unused *plane;
struct drm_plane_state *old_plane_state, *new_plane_state;
struct drm_crtc_commit *commit;
int i, ret;
@@ -2214,7 +2214,7 @@ EXPORT_SYMBOL(drm_atomic_helper_fake_vblank);
*/
void drm_atomic_helper_commit_hw_done(struct drm_atomic_state *old_state)
{
- struct drm_crtc *crtc;
+ struct drm_crtc __maybe_unused *crtc;
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct drm_crtc_commit *commit;
int i;
@@ -2300,7 +2300,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_cleanup_done);
int drm_atomic_helper_prepare_planes(struct drm_device *dev,
struct drm_atomic_
[RFC PATCH] drm:- Add a modifier to denote 'protected' framebuffer
Add a modifier 'DRM_FORMAT_MOD_ARM_PROTECTED' which denotes that the framebuffer
is allocated in a protected system memory.
Essentially, we want to support EGL_EXT_protected_content in our komeda driver.
Signed-off-by: Ayan Kumar Halder
/-- Note to reviewer
Komeda driver is capable of rendering DRM (Digital Rights Management) protected
content. The DRM content is stored in a framebuffer allocated in system memory
(which needs some special hardware signals for access).
Let us ignore how the protected system memory is allocated and for the scope of
this discussion, we want to figure out the best way possible for the userspace
to communicate to the drm driver to turn the protected mode on (for accessing
the
framebuffer with the DRM content) or off.
The possible ways by which the userspace could achieve this is via:-
1. Modifiers :- This looks to me the best way by which the userspace can
communicate to the kernel to turn the protected mode on for the komeda driver
as it is going to access one of the protected framebuffers. The only problem is
that the current modifiers describe the tiling/compression format. However, it
does not hurt to extend the meaning of modifiers to denote other attributes of
the framebuffer as well.
The other reason is that on Android, we get an info from Gralloc
(GRALLOC_USAGE_PROTECTED) which tells us that the buffer is protected. This can
be used to set up the modifier/s (AddFB2) during framebuffer creation.
2. Framebuffer flags :- As of today, this can be one of the two values
ie (DRM_MODE_FB_INTERLACED/DRM_MODE_FB_MODIFIERS). Unlike modifiers, the drm
framebuffer flags are generic to the drm subsystem and ideally we should not
introduce any driver specific constraint/feature.
3. Connector property:- I could see the following properties used for DRM
protected content:-
DRM_MODE_CONTENT_PROTECTION_DESIRED / ENABLED :- "This property is used by
userspace to request the kernel protect future content communicated over
the link". Clearly, we are not concerned with the protection attributes of the
transmitter. So, we cannot use this property for our case.
4. DRM plane property:- Again, we want to communicate that the framebuffer(which
can be attached to any plane) is protected. So introducing a new plane property
does not help.
5. DRM crtc property:- For the same reason as above, introducing a new crtc
property does not help.
--/
---
include/uapi/drm/drm_fourcc.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 3feeaa3f987a..38e5e81d11fe 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -742,6 +742,15 @@ extern "C" {
*/
#define AFBC_FORMAT_MOD_BCH (1ULL << 11)
+/*
+ * Protected framebuffer
+ *
+ * The framebuffer is allocated in a protected system memory which can be
accessed
+ * via some special hardware signals from the dpu. This is used to support
+ * 'GRALLOC_USAGE_PROTECTED' in our framebuffer for EGL_EXT_protected_content.
+ */
+#define DRM_FORMAT_MOD_ARM_PROTECTED fourcc_mod_code(ARM, (1ULL << 55))
+
/*
* Allwinner tiled modifier
*
--
2.23.0
Re: [PATCH] gpu/drm: fix a -Wstringop-truncation warning
Emil, this seems has been stalled again from DRM maintainers. Just to see if you have some "magic" to unsilence it like the last time... On Fri, 2019-08-23 at 14:37 -0400, Qian Cai wrote: > In file included from ./include/linux/bitmap.h:9, > from ./include/linux/cpumask.h:12, > from ./arch/x86/include/asm/cpumask.h:5, > from ./arch/x86/include/asm/msr.h:11, > from ./arch/x86/include/asm/processor.h:21, > from ./arch/x86/include/asm/cpufeature.h:5, > from ./arch/x86/include/asm/thread_info.h:53, > from ./include/linux/thread_info.h:38, > from ./arch/x86/include/asm/preempt.h:7, > from ./include/linux/preempt.h:78, > from ./include/linux/rcupdate.h:27, > from ./include/linux/rculist.h:11, > from ./include/linux/pid.h:5, > from ./include/linux/sched.h:14, > from ./include/linux/uaccess.h:5, > from drivers/gpu/drm/drm_property.c:24: > In function 'strncpy', > inlined from 'drm_property_create' at > drivers/gpu/drm/drm_property.c:130:2: > ./include/linux/string.h:305:9: warning: '__builtin_strncpy' specified > bound 32 equals destination size [-Wstringop-truncation] > return __builtin_strncpy(p, q, size); > ^ > > Fix it by using strscpy() which will always return a valid string, and > doesn't unnecessarily force the tail of the destination buffer to be > zeroed. > > Signed-off-by: Qian Cai > --- > drivers/gpu/drm/drm_property.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c > index 892ce636ef72..66ec2cc7a559 100644 > --- a/drivers/gpu/drm/drm_property.c > +++ b/drivers/gpu/drm/drm_property.c > @@ -127,8 +127,7 @@ struct drm_property *drm_property_create(struct > drm_device *dev, > property->num_values = num_values; > INIT_LIST_HEAD(&property->enum_list); > > - strncpy(property->name, name, DRM_PROP_NAME_LEN); > - property->name[DRM_PROP_NAME_LEN-1] = '\0'; > + strscpy(property->name, name, DRM_PROP_NAME_LEN); > > list_add_tail(&property->head, &dev->mode_config.property_list); >
[PATCH 3/4] drm/vram: Unexport internal functions of VRAM MM
The init, cleanup and mmap functions of VRAM MM are only used internally.
Remove them from the public interface.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 38 ---
include/drm/drm_gem_vram_helper.h | 7 -
2 files changed, 5 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index ed1ffbec5d02..73e81e3a8724 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -844,19 +844,8 @@ static struct ttm_bo_driver bo_driver = {
* struct drm_vram_mm
*/
-/**
- * drm_vram_mm_init() - Initialize an instance of VRAM MM.
- * @vmm: the VRAM MM instance to initialize
- * @dev: the DRM device
- * @vram_base: the base address of the video memory
- * @vram_size: the size of the video memory in bytes
- *
- * Returns:
- * 0 on success, or
- * a negative error code otherwise.
- */
-int drm_vram_mm_init(struct drm_vram_mm *vmm, struct drm_device *dev,
-uint64_t vram_base, size_t vram_size)
+static int drm_vram_mm_init(struct drm_vram_mm *vmm, struct drm_device *dev,
+ uint64_t vram_base, size_t vram_size)
{
int ret;
@@ -875,34 +864,17 @@ int drm_vram_mm_init(struct drm_vram_mm *vmm, struct
drm_device *dev,
return 0;
}
-EXPORT_SYMBOL(drm_vram_mm_init);
-/**
- * drm_vram_mm_cleanup() - Cleans up an initialized instance of VRAM MM.
- * @vmm: the VRAM MM instance to clean up
- */
-void drm_vram_mm_cleanup(struct drm_vram_mm *vmm)
+static void drm_vram_mm_cleanup(struct drm_vram_mm *vmm)
{
ttm_bo_device_release(&vmm->bdev);
}
-EXPORT_SYMBOL(drm_vram_mm_cleanup);
-/**
- * drm_vram_mm_mmap() - Helper for implementing &struct file_operations.mmap()
- * @filp: the mapping's file structure
- * @vma: the mapping's memory area
- * @vmm: the VRAM MM instance
- *
- * Returns:
- * 0 on success, or
- * a negative error code otherwise.
- */
-int drm_vram_mm_mmap(struct file *filp, struct vm_area_struct *vma,
-struct drm_vram_mm *vmm)
+static int drm_vram_mm_mmap(struct file *filp, struct vm_area_struct *vma,
+ struct drm_vram_mm *vmm)
{
return ttm_bo_mmap(filp, vma, &vmm->bdev);
}
-EXPORT_SYMBOL(drm_vram_mm_mmap);
/*
* Helpers for integration with struct drm_device
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index 52e3f2aff490..3c204f17a0b8 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -169,13 +169,6 @@ static inline struct drm_vram_mm *drm_vram_mm_of_bdev(
return container_of(bdev, struct drm_vram_mm, bdev);
}
-int drm_vram_mm_init(struct drm_vram_mm *vmm, struct drm_device *dev,
-uint64_t vram_base, size_t vram_size);
-void drm_vram_mm_cleanup(struct drm_vram_mm *vmm);
-
-int drm_vram_mm_mmap(struct file *filp, struct vm_area_struct *vma,
-struct drm_vram_mm *vmm);
-
/*
* Helpers for integration with struct drm_device
*/
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] Merge VRAM MM and GEM VRAM source files
VRAM MM and GEM VRAM are only used with each other. This patch set moves VRAM MM into GEM VRAM source files and cleans up the helper's public interface. Thomas Zimmermann (4): drm/vram: Move VRAM memory manager to GEM VRAM implementation drm/vram: Have VRAM MM call GEM VRAM functions directly drm/vram: Unexport internal functions of VRAM MM drm/vram: Unconditonally set BO call-back functions Documentation/gpu/drm-mm.rst | 12 - drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/ast/ast_drv.c | 1 - drivers/gpu/drm/ast/ast_main.c| 1 - drivers/gpu/drm/ast/ast_ttm.c | 3 +- drivers/gpu/drm/bochs/bochs.h | 1 - drivers/gpu/drm/bochs/bochs_mm.c | 3 +- drivers/gpu/drm/drm_gem_vram_helper.c | 361 ++ drivers/gpu/drm/drm_vram_helper_common.c | 8 +- drivers/gpu/drm/drm_vram_mm_helper.c | 309 --- .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 1 - drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 3 +- drivers/gpu/drm/mgag200/mgag200_drv.h | 1 - drivers/gpu/drm/mgag200/mgag200_ttm.c | 3 +- drivers/gpu/drm/vboxvideo/vbox_drv.h | 2 - drivers/gpu/drm/vboxvideo/vbox_ttm.c | 3 +- include/drm/drm_gem_vram_helper.h | 90 - include/drm/drm_vram_mm_helper.h | 108 -- 18 files changed, 375 insertions(+), 538 deletions(-) delete mode 100644 drivers/gpu/drm/drm_vram_mm_helper.c delete mode 100644 include/drm/drm_vram_mm_helper.h -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/vram: Unconditonally set BO call-back functions
The statement's condition is always true. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_gem_vram_helper.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c index 73e81e3a8724..13717ae65da5 100644 --- a/drivers/gpu/drm/drm_gem_vram_helper.c +++ b/drivers/gpu/drm/drm_gem_vram_helper.c @@ -91,8 +91,7 @@ static int drm_gem_vram_init(struct drm_device *dev, int ret; size_t acc_size; - if (!gbo->bo.base.funcs) - gbo->bo.base.funcs = &drm_gem_vram_object_funcs; + gbo->bo.base.funcs = &drm_gem_vram_object_funcs; ret = drm_gem_object_init(dev, &gbo->bo.base, size); if (ret) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/vram: Have VRAM MM call GEM VRAM functions directly
VRAM MM and GEM VRAM buffer objects are only used with each other;
connected via 3 function pointers. Simplifiy this code by making the
memory manager call the rsp. functions from the BOs directly; and
remove the functions from he BO's public interface.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_ttm.c | 2 +-
drivers/gpu/drm/bochs/bochs_mm.c| 3 +-
drivers/gpu/drm/drm_gem_vram_helper.c | 119 ++--
drivers/gpu/drm/drm_vram_helper_common.c| 8 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c | 3 +-
drivers/gpu/drm/vboxvideo/vbox_ttm.c| 3 +-
include/drm/drm_gem_vram_helper.h | 24 +---
include/drm/drm_vram_mm_helper.h| 32 --
9 files changed, 44 insertions(+), 152 deletions(-)
delete mode 100644 include/drm/drm_vram_mm_helper.h
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 08ba0a917593..fad34106083a 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -41,7 +41,7 @@ int ast_mm_init(struct ast_private *ast)
vmm = drm_vram_helper_alloc_mm(
dev, pci_resource_start(dev->pdev, 0),
- ast->vram_size, &drm_gem_vram_mm_funcs);
+ ast->vram_size);
if (IS_ERR(vmm)) {
ret = PTR_ERR(vmm);
DRM_ERROR("Error initializing VRAM MM; %d\n", ret);
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 8f9bb886f7ad..1b74f530b07c 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -11,8 +11,7 @@ int bochs_mm_init(struct bochs_device *bochs)
struct drm_vram_mm *vmm;
vmm = drm_vram_helper_alloc_mm(bochs->dev, bochs->fb_base,
- bochs->fb_size,
- &drm_gem_vram_mm_funcs);
+ bochs->fb_size);
return PTR_ERR_OR_ZERO(vmm);
}
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 202f74453580..ed1ffbec5d02 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -5,7 +5,6 @@
#include
#include
#include
-#include
#include
static const struct drm_gem_object_funcs drm_gem_vram_object_funcs;
@@ -462,68 +461,25 @@ static bool drm_is_gem_vram(struct ttm_buffer_object *bo)
return (bo->destroy == ttm_buffer_object_destroy);
}
-/**
- * drm_gem_vram_bo_driver_evict_flags() - \
- Implements &struct ttm_bo_driver.evict_flags
- * @bo:TTM buffer object. Refers to &struct drm_gem_vram_object.bo
- * @pl:TTM placement information.
- */
-void drm_gem_vram_bo_driver_evict_flags(struct ttm_buffer_object *bo,
- struct ttm_placement *pl)
+static void drm_gem_vram_bo_driver_evict_flags(struct drm_gem_vram_object *gbo,
+ struct ttm_placement *pl)
{
- struct drm_gem_vram_object *gbo;
-
- /* TTM may pass BOs that are not GEM VRAM BOs. */
- if (!drm_is_gem_vram(bo))
- return;
-
- gbo = drm_gem_vram_of_bo(bo);
drm_gem_vram_placement(gbo, TTM_PL_FLAG_SYSTEM);
*pl = gbo->placement;
}
-EXPORT_SYMBOL(drm_gem_vram_bo_driver_evict_flags);
-/**
- * drm_gem_vram_bo_driver_verify_access() - \
- Implements &struct ttm_bo_driver.verify_access
- * @bo:TTM buffer object. Refers to &struct
drm_gem_vram_object.bo
- * @filp: File pointer.
- *
- * Returns:
- * 0 on success, or
- * a negative errno code otherwise.
- */
-int drm_gem_vram_bo_driver_verify_access(struct ttm_buffer_object *bo,
-struct file *filp)
+static int drm_gem_vram_bo_driver_verify_access(struct drm_gem_vram_object
*gbo,
+ struct file *filp)
{
- struct drm_gem_vram_object *gbo = drm_gem_vram_of_bo(bo);
-
return drm_vma_node_verify_access(&gbo->bo.base.vma_node,
filp->private_data);
}
-EXPORT_SYMBOL(drm_gem_vram_bo_driver_verify_access);
-/**
- * drm_gem_vram_bo_driver_move_notify() -
- * Implements &struct ttm_bo_driver.move_notify
- * @bo:TTM buffer object. Refers to &struct
drm_gem_vram_object.bo
- * @evict: True, if the BO is being evicted from graphics memory;
- * false otherwise.
- * @new_mem: New memory region, or NULL on destruction
- */
-void drm_gem_vram_bo_driver_move_notify(struct ttm_buffer_object *bo,
- bool evict,
- struct ttm_mem_reg *new_mem)
+static void drm_gem_vram_bo_driver_move_notify(struct drm_gem_vram_object *gbo,
+ bool evict,
+
[PATCH 1/4] drm/vram: Move VRAM memory manager to GEM VRAM implementation
The separation between GEM VRAM objects and and the memory manager
is artificial, as they are only used with each other. Copying both
implementations into the same file is a first step to simplifying
the code.
This patch only moves code without functional changes.
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/drm-mm.rst | 12 -
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/ast/ast_drv.c | 1 -
drivers/gpu/drm/ast/ast_main.c| 1 -
drivers/gpu/drm/ast/ast_ttm.c | 1 -
drivers/gpu/drm/bochs/bochs.h | 1 -
drivers/gpu/drm/drm_gem_vram_helper.c | 303 +
drivers/gpu/drm/drm_vram_mm_helper.c | 309 --
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 1 -
drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 1 -
drivers/gpu/drm/mgag200/mgag200_drv.h | 1 -
drivers/gpu/drm/vboxvideo/vbox_drv.h | 2 -
include/drm/drm_gem_vram_helper.h | 85 +
include/drm/drm_vram_mm_helper.h | 76 -
14 files changed, 389 insertions(+), 408 deletions(-)
delete mode 100644 drivers/gpu/drm/drm_vram_mm_helper.c
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index b664f054c259..9e61fef3cf5b 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -400,18 +400,6 @@ GEM VRAM Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c
:export:
-VRAM MM Helper Functions Reference
---
-
-.. kernel-doc:: drivers/gpu/drm/drm_vram_mm_helper.c
- :doc: overview
-
-.. kernel-doc:: include/drm/drm_vram_mm_helper.h
- :internal:
-
-.. kernel-doc:: drivers/gpu/drm/drm_vram_mm_helper.c
- :export:
-
VMA Offset Manager
==
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 82ff826b33cc..bb8cf02a604b 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -33,8 +33,7 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
drm_vram_helper-y := drm_gem_vram_helper.o \
-drm_vram_helper_common.o \
-drm_vram_mm_helper.o
+drm_vram_helper_common.o
obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o
drm_probe_helper.o \
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 6ed6ff49efc0..e0e8770462bc 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -35,7 +35,6 @@
#include
#include
#include
-#include
#include "ast_drv.h"
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 50de8e47659c..21715d6a9b56 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -33,7 +33,6 @@
#include
#include
#include
-#include
#include "ast_drv.h"
diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index c52d92294171..08ba0a917593 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -30,7 +30,6 @@
#include
#include
-#include
#include "ast_drv.h"
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index 68483a2fc12c..917767173ee6 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -10,7 +10,6 @@
#include
#include
#include
-#include
/* -- */
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 0990f0e03213..202f74453580 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -2,6 +2,7 @@
#include
#include
+#include
#include
#include
#include
@@ -14,6 +15,11 @@ static const struct drm_gem_object_funcs
drm_gem_vram_object_funcs;
*
* This library provides a GEM buffer object that is backed by video RAM
* (VRAM). It can be used for framebuffer devices with dedicated memory.
+ *
+ * The data structure &struct drm_vram_mm and its helpers implement a memory
+ * manager for simple framebuffer devices with dedicated video memory. Buffer
+ * objects are either placed in video RAM or evicted to system memory. The rsp.
+ * buffer object is provided by &struct drm_gem_vram_object.
*/
/*
@@ -734,3 +740,300 @@ static const struct drm_gem_object_funcs
drm_gem_vram_object_funcs = {
.vmap = drm_gem_vram_object_vmap,
.vunmap = drm_gem_vram_object_vunmap
};
+
+/*
+ * VRAM memory manager
+ */
+
+/*
+ * TTM TT
+ */
+
+static void backend_func_destroy(struct ttm_tt *tt)
+{
+ ttm_tt_fini(tt);
+ kfree(tt);
+}
+
+static struct ttm_backend_func backend_func = {
+ .destroy = backend_func_destroy
+};
+
+/*
+ * TTM BO device
+ */
+
+static struct ttm_tt
Re: [PATCH v3 7/7] drm/vram: fix Kconfig
Am 04.09.19 um 07:47 schrieb Gerd Hoffmann: > select isn't recursive, so we can't turn on DRM_TTM + DRM_TTM_HELPER > in config DRM_VRAM_HELPER, we have to select them on the vram users > instead. > > Signed-off-by: Gerd Hoffmann > --- > drivers/gpu/drm/Kconfig | 2 -- > drivers/gpu/drm/ast/Kconfig | 2 ++ > drivers/gpu/drm/bochs/Kconfig | 2 ++ > drivers/gpu/drm/hisilicon/hibmc/Kconfig | 3 ++- > drivers/gpu/drm/mgag200/Kconfig | 2 ++ > drivers/gpu/drm/vboxvideo/Kconfig | 2 ++ > 6 files changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 1be8ad30d8fe..cd11a3bde19c 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -168,8 +168,6 @@ config DRM_TTM > config DRM_VRAM_HELPER > tristate > depends on DRM > - select DRM_TTM > - select DRM_TTM_HELPER > help > Helpers for VRAM memory management > > diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig > index 829620d5326c..fbcf2f45cef5 100644 > --- a/drivers/gpu/drm/ast/Kconfig > +++ b/drivers/gpu/drm/ast/Kconfig > @@ -4,6 +4,8 @@ config DRM_AST > depends on DRM && PCI && MMU > select DRM_KMS_HELPER > select DRM_VRAM_HELPER > + select DRM_TTM > + select DRM_TTM_HELPER > help >Say yes for experimental AST GPU driver. Do not enable >this driver without having a working -modesetting, > diff --git a/drivers/gpu/drm/bochs/Kconfig b/drivers/gpu/drm/bochs/Kconfig > index 32b043abb668..7bcdf294fed8 100644 > --- a/drivers/gpu/drm/bochs/Kconfig > +++ b/drivers/gpu/drm/bochs/Kconfig > @@ -4,6 +4,8 @@ config DRM_BOCHS > depends on DRM && PCI && MMU > select DRM_KMS_HELPER > select DRM_VRAM_HELPER > + select DRM_TTM > + select DRM_TTM_HELPER > help > Choose this option for qemu. > If M is selected the module will be called bochs-drm. > diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig > b/drivers/gpu/drm/hisilicon/hibmc/Kconfig > index f20eedf0073a..8ad9a5b12e40 100644 > --- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig > +++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig > @@ -4,7 +4,8 @@ config DRM_HISI_HIBMC > depends on DRM && PCI && MMU > select DRM_KMS_HELPER > select DRM_VRAM_HELPER > - > + select DRM_TTM > + select DRM_TTM_HELPER > help > Choose this option if you have a Hisilicon Hibmc soc chipset. > If M is selected the module will be called hibmc-drm. > diff --git a/drivers/gpu/drm/mgag200/Kconfig b/drivers/gpu/drm/mgag200/Kconfig > index 76fee0fbdcae..aed11f4f4c55 100644 > --- a/drivers/gpu/drm/mgag200/Kconfig > +++ b/drivers/gpu/drm/mgag200/Kconfig > @@ -4,6 +4,8 @@ config DRM_MGAG200 > depends on DRM && PCI && MMU > select DRM_KMS_HELPER > select DRM_VRAM_HELPER > + select DRM_TTM > + select DRM_TTM_HELPER > help >This is a KMS driver for the MGA G200 server chips, it > does not support the original MGA G200 or any of the desktop > diff --git a/drivers/gpu/drm/vboxvideo/Kconfig > b/drivers/gpu/drm/vboxvideo/Kconfig > index 56ba510f21a2..45fe135d6e43 100644 > --- a/drivers/gpu/drm/vboxvideo/Kconfig > +++ b/drivers/gpu/drm/vboxvideo/Kconfig > @@ -4,6 +4,8 @@ config DRM_VBOXVIDEO > depends on DRM && X86 && PCI > select DRM_KMS_HELPER > select DRM_VRAM_HELPER > + select DRM_TTM > + select DRM_TTM_HELPER > select GENERIC_ALLOCATOR > help > This is a KMS driver for the virtual Graphics Card used in > Thanks for fixing the Kconfigs for VRAM helpers. Acked-by: Thomas Zimmermann -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 1/7] drm: add drm_print_bits
Am 04.09.19 um 07:47 schrieb Gerd Hoffmann:
> New helper to print named bits of some value (think flags fields).
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_print.h | 3 +++
> drivers/gpu/drm/drm_print.c | 33 +
> 2 files changed, 36 insertions(+)
>
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 112165d3195d..12d4916254b4 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -89,6 +89,9 @@ __printf(2, 3)
> void drm_printf(struct drm_printer *p, const char *f, ...);
> void drm_puts(struct drm_printer *p, const char *str);
> void drm_print_regset32(struct drm_printer *p, struct debugfs_regset32
> *regset);
> +void drm_print_bits(struct drm_printer *p,
> + unsigned long value, const char *bits[],
> + unsigned int from, unsigned int to);
>
> __printf(2, 0)
> /**
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index ad302d71..dfa27367ebb8 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -185,6 +185,39 @@ void drm_printf(struct drm_printer *p, const char *f,
> ...)
> }
> EXPORT_SYMBOL(drm_printf);
>
> +/**
> + * drm_print_bits - print bits to a &drm_printer stream
> + *
> + * Print bits (in flag fields for example) in human readable form.
> + * The first name in the @bits array is for the bit indexed by @from.
> + *
> + * @p: the &drm_printer
> + * @value: field value.
> + * @bits: Array with bit names.
> + * @from: start of bit range to print (inclusive).
> + * @to: end of bit range to print (exclusive).
> + */
> +void drm_print_bits(struct drm_printer *p,
> + unsigned long value, const char *bits[],
> + unsigned int from, unsigned int to)
> +{
> + bool first = true;
> + unsigned int i;
> +
> + for (i = from; i < to; i++) {
> + if (!(value & (1 << i)))
> + continue;
> + if (WARN_ON_ONCE(!bits[i-from]))
> + continue;
> + drm_printf(p, "%s%s", first ? "" : ",",
> +bits[i-from]);
> + first = false;
> + }
> + if (first)
> + drm_printf(p, "(none)");
> +}
> +EXPORT_SYMBOL(drm_print_bits);
> +
> void drm_dev_printk(const struct device *dev, const char *level,
> const char *format, ...)
> {
>
Acked-by: Thomas Zimmermann
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
[Bug 109303] [CI][SHARDS] igt@i915_query@query-topology-known-pci-ids - skip - Test requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) || IS_SKYLAKE(devid) || IS_KABYLAKE(devid) || IS_COFFEELAKE(de
https://bugs.freedesktop.org/show_bug.cgi?id=109303
--- Comment #6 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- CML ICL: igt@i915_query@query-topology-known-pci-ids - skip - Test
requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) || IS_SKYLAKE(devid) ||
-}
{+ CML ICL TGL: igt@i915_query@query-topology-known-pci-ids - skip - Test
requirement: IS_HASWELL(devid) || IS_BROADWELL(devid) || IS_SKYLAKE(devid) ||
+}
New failures caught by the filter:
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@i915_qu...@query-topology-known-pci-ids.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@i915_qu...@query-topology-known-pci-ids.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_364/fi-tgl-u/igt@i915_qu...@query-topology-known-pci-ids.html
--
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: [Lima] [PATCH] drm/lima: fix lima_gem_wait() return value
Hi Qiang, Am Montag, 9. September 2019, 04:30:43 CEST schrieb Qiang Yu: > Oh, I was miss leading by the drm_gem_reservation_object_wait > comments. Patch is: > Reviewed-by: Qiang Yu > > I'll apply this patch to drm-misc-next. > > Current kernel release is 5.3-rc8, is it too late for this fix to go > into the mainline 5.3 release? > I'd like to know how to apply this fix for current rc kernels, by > drm-misc-fixes? Can I push > to drm-misc-fixes by dim or I can only push to drm-misc-next and > drm-misc maintainer will > pick fixes from it to drm-misc-fixes? drm-misc-fixes gets merged into drm-misc-next by maintainers regularly, so I _think_ you should apply the fix-patch to drm-misc-fixes first. [I also always have to read the documentation ;-) ] In any case you might want to add a "Fixes: ." tag as well as a "Cc: sta...@vger.kernel.org" tag, so it can be backported to stable kernels if applicable. Heiko > On Sun, Sep 8, 2019 at 10:48 AM Vasily Khoruzhick wrote: > > > > drm_gem_reservation_object_wait() returns 0 if it succeeds and -ETIME > > if it timeouts, but lima driver assumed that 0 is error. > > > > Cc: sta...@vger.kernel.org > > Signed-off-by: Vasily Khoruzhick > > --- > > drivers/gpu/drm/lima/lima_gem.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/lima/lima_gem.c > > b/drivers/gpu/drm/lima/lima_gem.c > > index 477c0f73..b609dc030d6c 100644 > > --- a/drivers/gpu/drm/lima/lima_gem.c > > +++ b/drivers/gpu/drm/lima/lima_gem.c > > @@ -342,7 +342,7 @@ int lima_gem_wait(struct drm_file *file, u32 handle, > > u32 op, s64 timeout_ns) > > timeout = drm_timeout_abs_to_jiffies(timeout_ns); > > > > ret = drm_gem_reservation_object_wait(file, handle, write, timeout); > > - if (ret == 0) > > + if (ret == -ETIME) > > ret = timeout ? -ETIMEDOUT : -EBUSY; > > > > return ret; > > -- > > 2.23.0 > > > ___ > lima mailing list > l...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/lima ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204227] Visual artefacts and crash from suspend on amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204227 --- Comment #12 from Mirek Kratochvil (exa@gmail.com) --- That sounds great, thank you very much for the information and confirmation. I will try to update the BIOS and confirm ASAP. -- 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 v4 0/4] Add a generic driver for LED-based backlight
On Sun, Sep 08, 2019 at 06:17:50PM +0200, Jacek Anaszewski wrote: > On 7/22/19 11:23 PM, Jacek Anaszewski wrote: > > On 7/22/19 9:06 AM, Lee Jones wrote: > >> On Thu, 18 Jul 2019, Jacek Anaszewski wrote: > >> > >>> On 7/17/19 4:15 PM, Jean-Jacques Hiblot wrote: > This series aims to add a led-backlight driver, similar to pwm-backlight, > but using a LED class device underneath. > > A few years ago (2015), Tomi Valkeinen posted a series implementing a > backlight driver on top of a LED device: > https://patchwork.kernel.org/patch/7293991/ > https://patchwork.kernel.org/patch/7294001/ > https://patchwork.kernel.org/patch/7293981/ > > The discussion stopped because Tomi lacked the time to work on it. > > changes in v4: > - fix dev_err() messages and commit logs following the advices of Pavel > - cosmetic changes (indents, getting rid of "? 1 : 0" in > led_match_led_node()) > > changes in v3: > - dt binding: don't limit the brightness range to 0-255. Use the range of > the underlying LEDs. as a side-effect, all LEDs must now have the same > range > - driver: Adapt to dt binding update. > - driver: rework probe() for clarity and remove the remaining goto. > > changes in v2: > - handle more than one LED. > - don't make the backlight device a child of the LED controller. > - make brightness-levels and default-brightness-level optional > - removed the option to use a GPIO enable. > - removed the option to use a regulator. It should be handled by the LED > core > - don't make any change to the LED core (not needed anymore) > > Jean-Jacques Hiblot (2): > leds: Add managed API to get a LED from a device driver > dt-bindings: backlight: Add led-backlight binding > > Tomi Valkeinen (2): > leds: Add of_led_get() and led_put() > backlight: add led-backlight driver > > .../bindings/leds/backlight/led-backlight.txt | 28 ++ > drivers/leds/led-class.c | 92 ++ > drivers/video/backlight/Kconfig | 7 + > drivers/video/backlight/Makefile | 1 + > drivers/video/backlight/led_bl.c | 268 ++ > include/linux/leds.h | 6 + > 6 files changed, 402 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/leds/backlight/led-backlight.txt > create mode 100644 drivers/video/backlight/led_bl.c > > >>> > >>> For the whole set: > >>> > >>> Acked-by: Jacek Anaszewski > >>> > >>> Lee - we need to create immutable branch for this set since there will > >>> be some interfering changes in the LED core in this cycle. > >>> > >>> I can create the branch and send the pull request once we will > >>> obtain the ack from Rob for DT bindings, unless you have other > >>> preference. > >> > >> We also require a review to be conducted by Daniel Thompson. > >> > >> After which, an immutable branch sounds like a good idea. I'd like to > >> create this myself if you don't mind. > > > > Sure, thanks. > > Unfortunately that hasn't happened and it will miss 5.4 merge window. > > Daniel, we need your ack for this patch set. Sorry for dropping the ball here. I'm afraid I couldn't ack since I spotted a bug but I have shared review feedback now! Daniel.
[Bug 204227] Visual artefacts and crash from suspend on amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204227 --- Comment #11 from tones...@hotmail.com --- Some good news. After a bios update to Lenovo's E485/E585 1.54 I no longer need to provide additional boot arguments in order for the machine to come up and the visual artifacts have gone away. I would see issues with some fonts in Firefox that looked similar to your screenshot. The easiest way for me to reproduce the problem was to resize my terminal (Alacritty) or scroll around in gitk or gvim. After a few days running on the new bios I haven't seen the artifacts, so this bug looks to be resolved for me since kernel 5.2.11. Thanks! -- 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 2/2] dt-bindings: backlight: lm3630a: add enable_gpios
On Sun, Sep 08, 2019 at 10:37:04PM +0200, Andreas Kemnade wrote: > add enable-gpios to describe HWEN pin > > Signed-off-by: Andreas Kemnade Looks like patches are in the wrong order. Changes to bindings must appear in patchsets *before* the Linux implementation of the bindings. > --- > .../devicetree/bindings/leds/backlight/lm3630a-backlight.yaml | 4 > 1 file changed, 4 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml > b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml > index dc129d9a329e..a9656d72b668 100644 > --- a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml > +++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml > @@ -29,6 +29,10 @@ properties: >'#size-cells': > const: 0 > > + enable-gpios: > +description: GPIO to use to enable/disable the backlight (HWEN pin). > +maxItems: 1 > + > required: >- compatible >- reg Please add enable-gpios to one of the examples. Daniel.
Re: [PATCH 1/2] backlight: lm3630a: add an enable gpio for the HWEN pin
On Sun, Sep 08, 2019 at 10:37:03PM +0200, Andreas Kemnade wrote:
> For now just enable it in the probe function to allow i2c
> access and disable it on remove. Disabling also means resetting
> the register values to default.
>
> Tested on Kobo Clara HD.
>
> Signed-off-by: Andreas Kemnade
> ---
> drivers/video/backlight/lm3630a_bl.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/video/backlight/lm3630a_bl.c
> b/drivers/video/backlight/lm3630a_bl.c
> index b04b35d007a2..3b45a1733198 100644
> --- a/drivers/video/backlight/lm3630a_bl.c
> +++ b/drivers/video/backlight/lm3630a_bl.c
> @@ -12,6 +12,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
>
> @@ -48,6 +50,7 @@ struct lm3630a_chip {
> struct lm3630a_platform_data *pdata;
> struct backlight_device *bleda;
> struct backlight_device *bledb;
> + struct gpio_desc *enable_gpio;
> struct regmap *regmap;
> struct pwm_device *pwmd;
> };
> @@ -506,6 +509,14 @@ static int lm3630a_probe(struct i2c_client *client,
> return -ENOMEM;
> pchip->dev = &client->dev;
>
> + pchip->enable_gpio = devm_gpiod_get_optional(&client->dev, "enable",
> + GPIOD_ASIS);
Initializing GPIOD_ASIS doesn't look right to me.
If you initialize ASIS then the driver must configure the pin as an
output... far easier just to set GPIOD_OUT_HIGH during the get.
Note also that the call to this function should also be moved *below*
the calls parse the DT.
> + if (IS_ERR(pchip->enable_gpio)) {
> + rval = PTR_ERR(pchip->enable_gpio);
> + return rval;
> + }
> +
> +
> pchip->regmap = devm_regmap_init_i2c(client, &lm3630a_regmap);
> if (IS_ERR(pchip->regmap)) {
> rval = PTR_ERR(pchip->regmap);
> @@ -535,6 +546,10 @@ static int lm3630a_probe(struct i2c_client *client,
> }
> pchip->pdata = pdata;
>
> + if (pchip->enable_gpio) {
> + gpiod_set_value_cansleep(pchip->enable_gpio, 1);
Not needed, use GPIOD_OUT_HIGH instead.
> + usleep_range(1000, 2000);
Not needed, this sleep is already part of lm3630a_chip_init().
> + }
> /* chip initialize */
> rval = lm3630a_chip_init(pchip);
> if (rval < 0) {
> @@ -586,6 +601,9 @@ static int lm3630a_remove(struct i2c_client *client)
> if (rval < 0)
> dev_err(pchip->dev, "i2c failed to access register\n");
>
> + if (pchip->enable_gpio)
> + gpiod_set_value_cansleep(pchip->enable_gpio, 0);
> +
Is this needed?
This is a remove path, not a power management path, and we have no idea
what the original status of the pin was anyway?
> if (pchip->irq) {
> free_irq(pchip->irq, pchip);
> flush_workqueue(pchip->irqthread);
> --
> 2.20.1
>
Re: [PATCH v4 3/7] drm: Add DisplayPort colorspace property
On Sat, Sep 07, 2019 at 11:19:55PM +, Mun, Gwan-gyeong wrote: > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote: > > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä > > wrote: > > > On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote: > > > > > > > > > -Original Message- > > > > > From: Ilia Mirkin > > > > > Sent: Tuesday, September 3, 2019 6:12 PM > > > > > To: Mun, Gwan-gyeong > > > > > Cc: Intel Graphics Development > > > > >; Shankar, Uma > > > > > ; dri-devel < > > > > > dri-devel@lists.freedesktop.org> > > > > > Subject: Re: [PATCH v4 3/7] drm: Add DisplayPort colorspace > > > > > property > > > > > > > > > > So how would this work with a DP++ connector? Should it list > > > > > the HDMI or DP > > > > > properties? Or do we need a custom property checker which is > > > > > aware of what is > > > > > currently plugged in to validate the values? > > > > > > > > AFAIU For DP++ cases, we detect what kind of sink its driving DP > > > > or HDMI (with a passive dongle). > > > > Based on the type of sink detected, we should expose DP or HDMI > > > > colorspaces to userspace. > > > > > > For i915 DP connector always drives DP mode, HDMI connector always > > > drives > > > HDMI mode, even when the physical connector is DP++. > > > > Right, i915 creates 2 connectors, while nouveau, radeon, and amdgpu > > create 1 connector (not sure about other drivers) for a single > > physical DP++ socket. Since we supply the list of valid values at the > > time of creating the connector, we can't know at that point whether > > in > > the future a HDMI or DP will be plugged into it. > > > > -ilia > Ilia, does it mean that the drm_connector type is > DRM_MODE_CONNECTOR_DisplayPort and protocol is DP++ mode? > > And Ville and Uma, when we are useing dp active dongle (DP to HDMI > dongle and DP branch device is HDMI) should we expose HDMI colorspace? We still set it up via DP MSA/VSC no? In that case it should follow the DP spec I think. LSPCON is probably different because we manually generate the AVI infoframe for it. But I'm not sure how we're going to reconcile that with the DP stuff we also set up for it. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel panic during drm/nouveau init 5.3.0-rc7-next-20190903
Hi, On Mon, 9 Sep 2019 20:11:59 +1000 Stephen Rothwell wrote: > > If you are bisecting linux-next, I will suggest bisecting between the > stable branch on linux-next (which is just Linus' tree when I started > that day) and the top of the first linux-next that fails. (Assuming > that the stable branch is good). Actually (since you won't be bisecting the latest linux-next), you probably want to use git merge-base stable next-20190903 (or whatever linux-next you are bisecting) as your first good commit (assuming it id good :-)). -- Cheers, Stephen Rothwell pgpRrx1x_E8AE.pgp Description: OpenPGP digital signature
Re: [PATCH] drm: add drm device name
On Sat, 07 Sep 2019, Daniel Vetter wrote:
> On Sat, Sep 7, 2019 at 3:18 AM Rob Clark wrote:
>>
>> On Fri, Sep 6, 2019 at 3:16 PM Marek Olšák wrote:
>> >
>> > + dri-devel
>> >
>> > On Tue, Sep 3, 2019 at 5:41 PM Jiang, Sonny wrote:
>> >>
>> >> Add DRM device name and use DRM_IOCTL_VERSION ioctl drmVersion::desc
>> >> passing it to user space
>> >> instead of unused DRM driver name descriptor.
>> >>
>> >> Change-Id: I809f6d3e057111417efbe8fa7cab8f0113ba4b21
>> >> Signed-off-by: Sonny Jiang
>> >> ---
>> >> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
>> >> drivers/gpu/drm/drm_drv.c | 17 +
>> >> drivers/gpu/drm/drm_ioctl.c| 2 +-
>> >> include/drm/drm_device.h | 3 +++
>> >> include/drm/drm_drv.h | 1 +
>> >> 5 files changed, 24 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> >> index 67b09cb2a9e2..8f0971cea363 100644
>> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> >> @@ -2809,6 +2809,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>> >> /* init the mode config */
>> >> drm_mode_config_init(adev->ddev);
>> >>
>> >> + drm_dev_set_name(adev->ddev, amdgpu_asic_name[adev->asic_type]);
>> >> +
>> >> r = amdgpu_device_ip_init(adev);
>> >> if (r) {
>> >> /* failed in exclusive mode due to timeout */
>> >> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> >> index 862621494a93..6c33879bb538 100644
>> >> --- a/drivers/gpu/drm/drm_drv.c
>> >> +++ b/drivers/gpu/drm/drm_drv.c
>> >> @@ -802,6 +802,7 @@ void drm_dev_fini(struct drm_device *dev)
>> >> mutex_destroy(&dev->struct_mutex);
>> >> drm_legacy_destroy_members(dev);
>> >> kfree(dev->unique);
>> >> + kfree(dev->name);
>> >> }
>> >> EXPORT_SYMBOL(drm_dev_fini);
>> >>
>> >> @@ -1078,6 +1079,22 @@ int drm_dev_set_unique(struct drm_device *dev,
>> >> const char *name)
>> >> }
>> >> EXPORT_SYMBOL(drm_dev_set_unique);
>> >>
>> >> +/**
>> >> + * drm_dev_set_name - Set the name of a DRM device
>> >> + * @dev: device of which to set the name
>> >> + * @name: name to be set
>> >> + *
>> >> + * Return: 0 on success or a negative error code on failure.
>> >> + */
>> >> +int drm_dev_set_name(struct drm_device *dev, const char *name)
>> >> +{
>> >> + kfree(dev->name);
>> >> + dev->name = kstrdup(name, GFP_KERNEL);
>> >> +
>> >> + return dev->name ? 0 : -ENOMEM;
>> >> +}
>> >> +EXPORT_SYMBOL(drm_dev_set_name);
>> >> +
>> >> /*
>> >> * DRM Core
>> >> * The DRM core module initializes all global DRM objects and makes them
>> >> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
>> >> index 2263e3ddd822..61f02965106b 100644
>> >> --- a/drivers/gpu/drm/drm_ioctl.c
>> >> +++ b/drivers/gpu/drm/drm_ioctl.c
>> >> @@ -506,7 +506,7 @@ int drm_version(struct drm_device *dev, void *data,
>> >> dev->driver->date);
>> >> if (!err)
>> >> err = drm_copy_field(version->desc, &version->desc_len,
>> >> - dev->driver->desc);
>> >> + dev->name);
>>
>> I suspect this needs to be something like dev->name ? dev->name :
>> dev->driver->desc
>>
>> Or somewhere something needs to arrange for dev->name to default to
>> dev->driver->desc
>>
>> And maybe this should be dev->desc instead of dev->name.. that at
>> least seems less confusing to me.
>>
>> other than that, I don't see a big problem
>
> (recap from irc)
>
> I thought we're using this as essentially an uapi identifier, so that
> you know which kind of ioctl set a driver supports. Not so big deal on
> pci, where we match against pci ids anyway, kinda bigger deal where
> that's not around. Listing codenames and or something else that
> changes all the time feels a bit silly for that. Imo if you just want
> to expose this to userspace, stuff it into an amdgpu info/query ioctl.
>
> So what do you need this for exactly, where's the userspace that needs
> this?
Indeed; using this e.g. for changing userspace behaviour would seem
wrong.
BR,
Jani.
> -Daniel
>
>>
>> BR,
>> -R
>>
>> >>
>> >> return err;
>> >> }
>> >> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
>> >> index 7f9ef709b2b6..e29912c484e4 100644
>> >> --- a/include/drm/drm_device.h
>> >> +++ b/include/drm/drm_device.h
>> >> @@ -123,6 +123,9 @@ struct drm_device {
>> >> /** @unique: Unique name of the device */
>> >> char *unique;
>> >>
>> >> + /** @name: device name */
>> >> + char *name;
>> >> +
>> >> /**
>> >> * @struct_mutex:
>> >> *
>> >> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
>> >> index 68ca736c548d..f742e2bde467 100644
>> >> --- a/include/drm/drm_drv
[PATCH] drm: sti: fix W=1 warnings
Fix warnings when W=1.
No code changes, only clean up in sti internal structures and functions
descriptions.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_cursor.c | 2 +-
drivers/gpu/drm/sti/sti_dvo.c| 2 +-
drivers/gpu/drm/sti/sti_gdp.c| 2 +-
drivers/gpu/drm/sti/sti_hda.c| 2 +-
drivers/gpu/drm/sti/sti_hdmi.c | 4 ++--
drivers/gpu/drm/sti/sti_tvout.c | 10 +-
drivers/gpu/drm/sti/sti_vtg.c| 2 +-
7 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c
index 0bf7c332cf0b..ea64c1dcaf63 100644
--- a/drivers/gpu/drm/sti/sti_cursor.c
+++ b/drivers/gpu/drm/sti/sti_cursor.c
@@ -47,7 +47,7 @@ struct dma_pixmap {
void *base;
};
-/**
+/*
* STI Cursor structure
*
* @sti_plane:sti_plane structure
diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
index 9e6d5d8b7030..c33d0aaee82b 100644
--- a/drivers/gpu/drm/sti/sti_dvo.c
+++ b/drivers/gpu/drm/sti/sti_dvo.c
@@ -65,7 +65,7 @@ static struct dvo_config rgb_24bit_de_cfg = {
.awg_fwgen_fct = sti_awg_generate_code_data_enable_mode,
};
-/**
+/*
* STI digital video output structure
*
* @dev: driver device
diff --git a/drivers/gpu/drm/sti/sti_gdp.c b/drivers/gpu/drm/sti/sti_gdp.c
index 8e926cd6a1c8..11595c748844 100644
--- a/drivers/gpu/drm/sti/sti_gdp.c
+++ b/drivers/gpu/drm/sti/sti_gdp.c
@@ -103,7 +103,7 @@ struct sti_gdp_node_list {
dma_addr_t btm_field_paddr;
};
-/**
+/*
* STI GDP structure
*
* @sti_plane: sti_plane structure
diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 94e404f13234..3512a94a0fca 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -230,7 +230,7 @@ static const struct sti_hda_video_config
hda_supported_modes[] = {
AWGi_720x480p_60, NN_720x480p_60, VID_ED}
};
-/**
+/*
* STI hd analog structure
*
* @dev: driver device
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index f03d617edc4c..87e34f7a6cfe 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -333,7 +333,6 @@ static void hdmi_infoframe_reset(struct sti_hdmi *hdmi,
* Helper to concatenate infoframe in 32 bits word
*
* @ptr: pointer on the hdmi internal structure
- * @data: infoframe to write
* @size: size to write
*/
static inline unsigned int hdmi_infoframe_subpack(const u8 *ptr, size_t size)
@@ -543,13 +542,14 @@ static int hdmi_vendor_infoframe_config(struct sti_hdmi
*hdmi)
return 0;
}
+#define HDMI_TIMEOUT_SWRESET 100 /*milliseconds */
+
/**
* Software reset of the hdmi subsystem
*
* @hdmi: pointer on the hdmi internal structure
*
*/
-#define HDMI_TIMEOUT_SWRESET 100 /*milliseconds */
static void hdmi_swreset(struct sti_hdmi *hdmi)
{
u32 val;
diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c
index e1b3c8cb7287..b1fc77b150da 100644
--- a/drivers/gpu/drm/sti/sti_tvout.c
+++ b/drivers/gpu/drm/sti/sti_tvout.c
@@ -157,9 +157,9 @@ static void tvout_write(struct sti_tvout *tvout, u32 val,
int offset)
*
* @tvout: tvout structure
* @reg: register to set
- * @cr_r:
- * @y_g:
- * @cb_b:
+ * @cr_r: red chroma or red order
+ * @y_g: y or green order
+ * @cb_b: blue chroma or blue order
*/
static void tvout_vip_set_color_order(struct sti_tvout *tvout, int reg,
u32 cr_r, u32 y_g, u32 cb_b)
@@ -214,7 +214,7 @@ static void tvout_vip_set_rnd(struct sti_tvout *tvout, int
reg, u32 rnd)
* @tvout: tvout structure
* @reg: register to set
* @main_path: main or auxiliary path
- * @sel_input: selected_input (main/aux + conv)
+ * @video_out: selected_input (main/aux + conv)
*/
static void tvout_vip_set_sel_input(struct sti_tvout *tvout,
int reg,
@@ -251,7 +251,7 @@ static void tvout_vip_set_sel_input(struct sti_tvout *tvout,
*
* @tvout: tvout structure
* @reg: register to set
- * @in_vid_signed: used video input format
+ * @in_vid_fmt: used video input format
*/
static void tvout_vip_set_in_vid_fmt(struct sti_tvout *tvout,
int reg, u32 in_vid_fmt)
diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c
index ef4009f11396..0b17ac8a3faa 100644
--- a/drivers/gpu/drm/sti/sti_vtg.c
+++ b/drivers/gpu/drm/sti/sti_vtg.c
@@ -121,7 +121,7 @@ struct sti_vtg_sync_params {
u32 vsync_off_bot;
};
-/**
+/*
* STI VTG structure
*
* @regs: register mapping
--
2.15.0
Re: Kernel panic during drm/nouveau init 5.3.0-rc7-next-20190903
Hi Alexander, On Sun, 8 Sep 2019 17:13:07 +0300 Alexander Kapshuk wrote: > > This is my first bisect. Here's what I've tried so far and based on the > output I got, I seem to be taken in the opposit direction. > > git bisect start > git bisect bad# 7dc4585e0378:next-20190903 > git bisect good next-20190730 #70f4b4ac1655 If you are bisecting linux-next, I will suggest bisecting between the stable branch on linux-next (which is just Linus' tree when I started that day) and the top of the first linux-next that fails. (Assuming that the stable branch is good). so git bisect start git bisect good stable git bisect bad next-20190903 and go from there. It will (unfortunately) be quite a few commits to test :-( -- Cheers, Stephen Rothwell pgpCMv6bnNJFj.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/17] drm: add mmap() to drm_gem_object_funcs
Hi, > > + vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | > > VM_DONTDUMP; > > + vma->vm_page_prot = > > pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); > > + vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); > > + } > > Totally unrelated discussion around HMM lead me to a bit a chase, and > realizing that we probably want a > > WARN_ON(!(vma->vm_flags & VM_SPECIAL)); > > here, to make sure drivers set at least one of the "this is a special > vma, don't try to treat it like pagecache/anon memory". Just to be on > the safe side. Maybe we also want to keep the entire vma->vm_flags > assignment in the common code, but at least the WARN_ON would be a > good check I think. Maybe also check for VM_DONTEXPAND while at it Hmm. VM_SPECIAL is this: #define VM_SPECIAL (VM_IO | VM_DONTEXPAND | VM_PFNMAP | VM_MIXEDMAP) Requiring VM_DONTEXPAND makes sense for sure. Dunno about the other ones. For drm_gem_vram_helper VM_IO + VM_PFNMAP are needed. But we also have drm_gem_shmem_helper which backs objects with normal pages. In fact drm_gem_shmem_mmap does this: /* VM_PFNMAP was set by drm_gem_mmap() */ vma->vm_flags &= ~VM_PFNMAP; vma->vm_flags |= VM_MIXEDMAP; include/linux/mm.h isn't very helpful in explaining how VM_MIXEDMAP should be used, only saying can be both "struct page" and pfnmap, so I'm not sure why VM_MIXEDMAP is set here, it should always be "struct page" for shmem, no? cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] FBTFT: fb_agm1264k: usleep_range is preferred over udelay
On Sun, Sep 08, 2019 at 08:26:05PM -0500, Sreeram Veluthakkal wrote: > This patch fixes the issue: > FILE: drivers/staging/fbtft/fb_agm1264k-fl.c:88: > CHECK: usleep_range is preferred over udelay; see > Documentation/timers/timers-howto.rst > + udelay(20); > > Signed-off-by: Sreeram Veluthakkal > --- > drivers/staging/fbtft/fb_agm1264k-fl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c > b/drivers/staging/fbtft/fb_agm1264k-fl.c > index ec97ad27..2dece71fd3b5 100644 > --- a/drivers/staging/fbtft/fb_agm1264k-fl.c > +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c > @@ -85,7 +85,7 @@ static void reset(struct fbtft_par *par) > dev_dbg(par->info->device, "%s()\n", __func__); > > gpiod_set_value(par->gpio.reset, 0); > - udelay(20); > + usleep_range(20, 40); Is it "safe" to wait 40? This kind of change you can only do if you know this is correct. Have you tested this with hardware? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 4/4] backlight: add led-backlight driver
On Wed, Jul 17, 2019 at 04:15:14PM +0200, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> This patch adds a led-backlight driver (led_bl), which is similar to
> pwm_bl except the driver uses a LED class driver to adjust the
> brightness in the HW. Multiple LEDs can be used for a single backlight.
>
> Signed-off-by: Tomi Valkeinen
> Signed-off-by: Jean-Jacques Hiblot
> Acked-by: Pavel Machek
> ---
> drivers/video/backlight/Kconfig | 7 +
> drivers/video/backlight/Makefile | 1 +
> drivers/video/backlight/led_bl.c | 268 +++
> 3 files changed, 276 insertions(+)
> create mode 100644 drivers/video/backlight/led_bl.c
>
> diff --git a/drivers/video/backlight/led_bl.c
> b/drivers/video/backlight/led_bl.c
> new file mode 100644
> index ..ac5ff78e7859
> --- /dev/null
> +++ b/drivers/video/backlight/led_bl.c
> @@ -0,0 +1,268 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2015-2019 Texas Instruments Incorporated -
> http://www.ti.com/
> + * Author: Tomi Valkeinen
> + *
> + * Based on pwm_bl.c
> + */
> +
> +#include
> +#include
Why do we need this header file?
> +#include
> +#include
> +#include
> +#include
> +
> +#define BKL_FULL_BRIGHTNESS 255
If we really need to have a full intensity constant then shouldn't we
use LED_FULL directly.
> +
> +struct led_bl_data {
> + struct device *dev;
> + struct backlight_device *bl_dev;
> + struct led_classdev **leds;
> + boolenabled;
> + int nb_leds;
> + unsigned int*levels;
> + unsigned intdefault_brightness;
> + unsigned intmax_brightness;
> +};
> +
> +static int to_led_brightness(struct led_classdev *led, int value)
> +{
> + return (value * led->max_brightness) / BKL_FULL_BRIGHTNESS;
This code looks broken.
For example led->max_brightness is 127 then the value this
function will pick values is in the interval 0..63 which is
wrong since we are not using the full range of the LED.
Similarly led->max_brightness is > 255 then we'll generate values
that are out-of-range
Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/4] Implement lazy unmapping for GEM VRAM buffers
On Fri, Sep 06, 2019 at 02:20:52PM +0200, Thomas Zimmermann wrote: > Generic fbdev emulation maps and unmaps the console BO for updating it's > content from the shadow buffer. If this involves an actual mapping > operation (instead of reusing an existing mapping), lots of debug messages > may be printed, such as > > x86/PAT: Overlap at 0xd000-0xd100 > x86/PAT: reserve_memtype added [mem 0xd000-0xd02f], track > write-combining, req write-combining, ret write-combining > x86/PAT: free_memtype request [mem 0xd000-0xd02f] > > as reported at [1]. Drivers using VRAM helpers may also see reduced > performance as the mapping operations can create overhead. > > In v3 and later of the patch set, this problem is being solved by lazily > unmapping the buffer as suggested by Gerd. Unmapping with > drm_gem_vram_kunmap() > only changes a reference counter. VRAM helpers later perform the unmapping > operation when TTM evicts the buffer object from its current location. If > the buffer is never evicted, the existing mapping is reused by later calls > to drm_gem_vram_kmap(). > > v4: > * lock kmap with ttm_bo_reserve() > * acquire lock only once for vmap() > * warn about stale mappings during buffer cleanup > v3: > * implement lazy unmapping > v2: > * fixed comment typos > > [1] > https://lists.freedesktop.org/archives/dri-devel/2019-September/234308.html > > Thomas Zimmermann (4): > drm/vram: Add kmap ref-counting to GEM VRAM objects > drm/vram: Acquire lock only once per call to vmap()/vunmap() > drm/vram: Add infrastructure for move_notify() > drm/vram: Implement lazy unmapping for GEM VRAM buffers Reviewed-by: Gerd Hoffmann cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8] drm/ttm: remove embedded vma_offset_manager
On Mon, Sep 09, 2019 at 07:02:33AM +, Koenig, Christian wrote: > Am 05.09.19 um 09:05 schrieb Gerd Hoffmann: > > No users left. Drivers either setup vma_offset_manager themself > > (vmwgfx) or pass the gem vma_offset_manager to ttm_bo_device_init > > (all other drivers). > > > > Signed-off-by: Gerd Hoffmann > > Patches #4, #5 and #8 in this series are Reviewed-by: Christian König > > > I can't see the rest in my inbox anywhere. Have you send all of them to > dri-devel? Yes, they are all on dri-devel, but only a subset is Cc'ed to you. Patches 2-7 switch drivers one-by-one, and I guess you only got the ones where you are listed as driver maintainer/reviewer in MAINTAINERS. cheers, Gerd
Re: [PATCH] drm/stm: ltdc: add pinctrl for DPI encoder mode
Le ven. 6 sept. 2019 à 11:22, Yannick Fertré a écrit :
>
> The implementation of functions encoder_enable and encoder_disable
> make possible to control the pinctrl according to the encoder type.
> The pinctrl must be activated only if the encoder type is DPI.
> This helps to move the DPI-related pinctrl configuration from
> all the panel or bridge to the LTDC dt node.
>
> Reviewed-by: Philippe Cornu
>
> Signed-off-by: Yannick Fertré
Applied on drm-misc-next,
Thanks,
Benjamin
> ---
> drivers/gpu/drm/stm/ltdc.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 3ab4fbf..1c4fde0 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1040,6 +1041,36 @@ static const struct drm_encoder_funcs
> ltdc_encoder_funcs = {
> .destroy = drm_encoder_cleanup,
> };
>
> +static void ltdc_encoder_disable(struct drm_encoder *encoder)
> +{
> + struct drm_device *ddev = encoder->dev;
> +
> + DRM_DEBUG_DRIVER("\n");
> +
> + /* Set to sleep state the pinctrl whatever type of encoder */
> + pinctrl_pm_select_sleep_state(ddev->dev);
> +}
> +
> +static void ltdc_encoder_enable(struct drm_encoder *encoder)
> +{
> + struct drm_device *ddev = encoder->dev;
> +
> + DRM_DEBUG_DRIVER("\n");
> +
> + /*
> +* Set to default state the pinctrl only with DPI type.
> +* Others types like DSI, don't need pinctrl due to
> +* internal bridge (the signals do not come out of the chipset).
> +*/
> + if (encoder->encoder_type == DRM_MODE_ENCODER_DPI)
> + pinctrl_pm_select_default_state(ddev->dev);
> +}
> +
> +static const struct drm_encoder_helper_funcs ltdc_encoder_helper_funcs = {
> + .disable = ltdc_encoder_disable,
> + .enable = ltdc_encoder_enable,
> +};
> +
> static int ltdc_encoder_init(struct drm_device *ddev, struct drm_bridge
> *bridge)
> {
> struct drm_encoder *encoder;
> @@ -1055,6 +1086,8 @@ static int ltdc_encoder_init(struct drm_device *ddev,
> struct drm_bridge *bridge)
> drm_encoder_init(ddev, encoder, DRM_MODE_ENCODER_DPI, NULL);
>
> + drm_encoder_helper_add(encoder, +
> ret = drm_bridge_attach(encoder, bridge, NULL);
> if (ret) {
> drm_encoder_cleanup(encoder);
> @@ -1280,6 +1313,8 @@ int ltdc_load(struct drm_device *ddev)
>
> clk_disable_unprepare(ldev->pixel_clk);
>
> + pinctrl_pm_select_sleep_state(ddev->dev);
> +
> pm_runtime_enable(ddev->dev);
>
> return 0;
> --
> 2.7.4
>
> ___
> 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: gnome-shell stuck because of amdgpu driver [5.3 RC5]
I agree with Daniels analysis. It looks like the problem is simply that PM turns of a block before all work is done on that block. Have you opened a bug report yet? If not then that would certainly help cause it is really hard to extract all necessary information from that mail thread. Regards, Christian. Am 08.09.19 um 23:24 schrieb Mikhail Gavrilov: > On Thu, 5 Sep 2019 at 12:58, Daniel Vetter wrote: >> I think those fences are only emitted for CS, not display related. >> Adding Christian König. > More fresh kernel log with 5.3RC7 - the issue still happens. > https://pastebin.com/tyxkWJYV > > > -- > Best Regards, > Mike Gavrilov. > > On Thu, 5 Sep 2019 at 12:58, Daniel Vetter wrote: >> On Thu, Sep 5, 2019 at 12:27 AM Mikhail Gavrilov >> wrote: >>> On Wed, 4 Sep 2019 at 13:37, Daniel Vetter wrote: Extend your backtrac warning slightly like WARN(r, "we're stuck on fence %pS\n", fence->ops); Also adding Harry and Alex, I'm not really working on amdgpu ... >>> [ 3511.998320] [ cut here ] >>> [ 3511.998714] we're stuck on fence >>> amdgpu_fence_ops+0x0/0xc220 [amdgpu]$ >> I think those fences are only emitted for CS, not display related. >> Adding Christian König. >> -Daniel >> >>> [ 3511.998991] WARNING: CPU: 10 PID: 1811 at >>> drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:332 >>> amdgpu_fence_wait_empty+0x1c6/0x240 [amdgpu] >>> [ 3511.999009] Modules linked in: rfcomm fuse xt_CHECKSUM >>> xt_MASQUERADE nf_nat_tftp nf_conntrack_tftp tun bridge stp llc >>> nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_REJECT >>> nf_reject_ipv6 ip6t_rpfilter ipt_REJECT nf_reject_ipv4 xt_conntrack >>> ebtable_nat ip6table_nat ip6table_mangle ip6table_raw >>> ip6table_security iptable_nat nf_nat iptable_mangle iptable_raw >>> iptable_security nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c >>> ip_set nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables >>> iptable_filter cmac bnep sunrpc vfat fat edac_mce_amd kvm_amd >>> snd_hda_codec_realtek rtwpci snd_hda_codec_generic kvm ledtrig_audio >>> snd_hda_codec_hdmi uvcvideo rtw88 videobuf2_vmalloc snd_hda_intel >>> videobuf2_memops videobuf2_v4l2 irqbypass snd_usb_audio snd_hda_codec >>> videobuf2_common crct10dif_pclmul snd_usbmidi_lib crc32_pclmul >>> mac80211 snd_rawmidi videodev snd_hda_core ghash_clmulni_intel btusb >>> snd_hwdep btrtl snd_seq btbcm btintel snd_seq_device eeepc_wmi >>> bluetooth xpad joydev mc snd_pcm >>> [ 3511.999076] asus_wmi ff_memless cfg80211 sparse_keymap video >>> wmi_bmof ecdh_generic snd_timer ecc sp5100_tco k10temp snd i2c_piix4 >>> ccp rfkill soundcore libarc4 gpio_amdpt gpio_generic acpi_cpufreq >>> binfmt_misc ip_tables hid_logitech_hidpp hid_logitech_dj amdgpu >>> amd_iommu_v2 gpu_sched ttm drm_kms_helper drm crc32c_intel igb dca >>> nvme i2c_algo_bit nvme_core wmi pinctrl_amd >>> [ 3511.999126] CPU: 10 PID: 1811 Comm: Xorg Not tainted >>> 5.3.0-0.rc6.git2.1c.fc32.x86_64 #1 >>> [ 3511.999131] Hardware name: System manufacturer System Product >>> Name/ROG STRIX X470-I GAMING, BIOS 2703 08/20/2019 >>> [ 3511.999253] RIP: 0010:amdgpu_fence_wait_empty+0x1c6/0x240 [amdgpu] >>> [ 3511.999278] Code: fe ff ff 31 c0 c3 48 89 ef e8 36 29 04 cb 84 c0 >>> 74 08 48 89 ef e8 8a a9 21 cb 48 8b 75 08 48 c7 c7 2c 16 86 c0 e8 82 >>> b8 b9 ca <0f> 0b b8 ea ff ff ff 5d c3 e8 ec 57 c3 ca 84 c0 0f 85 6f ff >>> ff ff >>> [ 3511.999282] RSP: 0018:b9c04170f798 EFLAGS: 00210282 >>> [ 3511.999288] RAX: RBX: 8d2ce5205a80 RCX: >>> 0006 >>> [ 3511.999292] RDX: 0007 RSI: 8d2c5bea4070 RDI: >>> 8d2cfb5d9e00 >>> [ 3511.999296] RBP: 8d28becae480 R08: 0331b36fd503 R09: >>> >>> [ 3511.999299] R10: R11: R12: >>> 8d2ce520 >>> [ 3511.999303] R13: R14: R15: >>> 8d2ce154 >>> [ 3511.999308] FS: 7f59a5bc6f00() GS:8d2cfb40() >>> knlGS: >>> [ 3511.999311] CS: 0010 DS: ES: CR0: 80050033 >>> [ 3511.999315] CR2: 1108bc475960 CR3: 00075bf32000 CR4: >>> 003406e0 >>> [ 3511.999319] Call Trace: >>> [ 3511.999394] amdgpu_pm_compute_clocks+0x70/0x5f0 [amdgpu] >>> [ 3511.999503] dm_pp_apply_display_requirements+0x1a8/0x1c0 [amdgpu] >>> [ 3511.999609] dce12_update_clocks+0xd8/0x110 [amdgpu] >>> [ 3511.999712] dc_commit_state+0x414/0x590 [amdgpu] >>> [ 3511.999725] ? find_held_lock+0x32/0x90 >>> [ 3511.999832] amdgpu_dm_atomic_commit_tail+0xd18/0x1cf0 [amdgpu] >>> [ 3511.999844] ? reacquire_held_locks+0xed/0x210 >>> [ 3511.999859] ? ttm_eu_backoff_reservation+0xa5/0x160 [ttm] >>> [ 3511.999866] ? find_held_lock+0x32/0x90 >>> [ 3511.999872] ? find_held_lock+0x32/0x90 >>> [ 3511.999881] ? __lock_acquire+0x247/0x1910 >>> [ 3511.999893] ? find_held_lock+0x32/0x90 >>> [ 3511.01] ? mark_held_locks+0x50/0x80 >>> [ 3511.07] ? _raw_spin_unlock_irq+0
[Bug 111236] VA-API radeonsi SIGSEGV __memmove_avx_unaligned
https://bugs.freedesktop.org/show_bug.cgi?id=111236 --- Comment #13 from Michel Dänzer --- Note that my patch is just a proof of concept pointing at where the issue lies. I hope it helps someone else come up with a proper fix. -- 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 111599] [CI][RESUME] igt@gem_ctx_isolation@* - skip - Test requirement: !(gen > LAST_KNOWN_GEN), SKIP
https://bugs.freedesktop.org/show_bug.cgi?id=111599 Bug ID: 111599 Summary: [CI][RESUME] igt@gem_ctx_isolation@* - skip - Test requirement: !(gen > LAST_KNOWN_GEN), SKIP Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: not set Priority: not set Component: IGT Assignee: dri-devel@lists.freedesktop.org Reporter: martin.pe...@free.fr https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_isolat...@bcs0-dirty-switch.html Test requirement not met in function __real_main808, file ../tests/i915/gem_ctx_isolation.c:827: Test requirement: !(gen > LAST_KNOWN_GEN) Subtest bcs0-dirty-switch: SKIP -- 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 111599] [CI][RESUME] igt@gem_ctx_isolation@* - skip - Test requirement: !(gen > LAST_KNOWN_GEN), SKIP
https://bugs.freedesktop.org/show_bug.cgi?id=111599 --- Comment #1 from CI Bug Log --- The CI Bug Log issue associated to this bug has been updated. ### New filters associated * TGL: igt@gem_ctx_isolation@* - skip - Test requirement: !(gen > LAST_KNOWN_GEN), SKIP - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_isolat...@bcs0-dirty-switch.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_isolat...@vecs0-clean.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_isolat...@vcs1-clean.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_isolat...@vcs1-s3.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_isolat...@vcs1-dirty-switch.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_isolat...@vcs2-s3.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_isolat...@bcs0-clean.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_isolat...@vecs0-dirty-create.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_isolat...@vcs2-clean.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_isolat...@vcs1-reset.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_isolat...@vcs0-dirty-create.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_isolat...@vcs0-reset.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_362/fi-tgl-u/igt@gem_ctx_isolat...@rcs0-none.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs2-none.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@bcs0-dirty-switch.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs2-dirty-switch.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs2-dirty-create.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@bcs0-dirty-create.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs1-s3.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@rcs0-nonpriv.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@bcs0-none.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs1-none.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs1-dirty-create.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vecs0-s3.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@bcs0-reset.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs0-s3.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs2-reset.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vecs0-dirty-create.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vecs0-nonpriv.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@rcs0-clean.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs2-s3.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vecs0-none.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs0-dirty-switch.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs0-reset.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs0-none.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs1-nonpriv.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs0-dirty-create.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vcs2-nonpriv.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@bcs0-clean.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@vecs0-reset.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@rcs0-dirty-create.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_363/fi-tgl-u/igt@gem_ctx_isolat...@rcs0-reset.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_364/fi-tgl-u/igt@gem_ctx_isolat...@vcs2-none.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_364/fi-tgl-u/igt@gem_ctx_isolat...@bcs0-dirty-switch.html - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_364/fi-tgl-u/igt@gem_ctx_isolat...@vcs2-dirty-switch.html
[Bug 111599] [CI][RESUME] igt@gem_ctx_isolation@* - skip - Test requirement: !(gen > LAST_KNOWN_GEN), SKIP
https://bugs.freedesktop.org/show_bug.cgi?id=111599 Martin Peres changed: What|Removed |Added Priority|not set |high -- 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 204227] Visual artefacts and crash from suspend on amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204227 Mirek Kratochvil (exa@gmail.com) changed: What|Removed |Added CC||exa@gmail.com --- Comment #10 from Mirek Kratochvil (exa@gmail.com) --- Hello everyone, would the artefacts look like on this picture, or am I having a different issue? http://e-x-a.org/stuff/amdgpu-artefacts.jpg (Taken with a phone, as the artefacts are not screenshottable.) The squares appear around small stuff that changes (esp. terminal text) and disappear in around half a second. Notably, they are only seen in xfce (suspect compositor is needed); not in LightDM (which does not do composition) nor around any frequently refreshed/accelerated surface (glxgears and animations in forefox are clean.) Mine is: 05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev c3) (prog-if 00 [VGA controller]) Subsystem: Lenovo Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] Flags: bus master, fast devsel, latency 0, IRQ 58 Memory at b000 (64-bit, prefetchable) [size=256M] Memory at c000 (64-bit, prefetchable) [size=2M] I/O ports at 1000 [size=256] Memory at c080 (32-bit, non-prefetchable) [size=512K] Capabilities: [48] Vendor Specific Information: Len=08 Capabilities: [50] Power Management version 3 Capabilities: [64] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/4 Maskable- 64bit+ Capabilities: [c0] MSI-X: Enable- Count=3 Masked- Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [200] Resizable BAR Capabilities: [270] Secondary PCI Express Capabilities: [2b0] Address Translation Service (ATS) Capabilities: [2c0] Page Request Interface (PRI) Capabilities: [2d0] Process Address Space ID (PASID) Capabilities: [320] Latency Tolerance Reporting Kernel driver in use: amdgpu Kernel modules: amdgpu The problem happens on all 5.2 kernels I tried (from debian). "Debian stable" 4.19 and one 5.1 I tried are OK. If this is a different kind of artifacts, please let me know (I'd open a different kind of bug.) Thanks in advance! -mk -- 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] mm, notifier: Fix early return case for new lockdep annotations
On 06.09.19 19:47, Daniel Vetter wrote:
> I missed that when extending the lockdep annotations to the
> nonblocking case.
>
> I missed this while testing since in the i915 mmu notifiers is hitting
> a nice lockdep splat already before the point of going into oom killer
> mode :-/
>
> Reported-by: syzbot+aaedc50d99a03250f...@syzkaller.appspotmail.com
> Fixes: d2b219ed03d4 ("mm/mmu_notifiers: add a lockdep map for
> invalidate_range_start/end")
> Cc: Jason Gunthorpe
> Cc: Daniel Vetter
> Cc: Andrew Morton
> Cc: "Jérôme Glisse"
> Cc: Ralph Campbell
> Cc: Jason Gunthorpe
> Cc: Ira Weiny
> Cc: Michal Hocko
> Cc: Daniel Vetter
> Cc: Sean Christopherson
> Cc: Jean-Philippe Brucker
> Cc: linux...@kvack.org
> Signed-off-by: Daniel Vetter
> ---
> include/linux/mmu_notifier.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> index 5a03417e5bf7..4edd98b06834 100644
> --- a/include/linux/mmu_notifier.h
> +++ b/include/linux/mmu_notifier.h
> @@ -356,13 +356,14 @@ mmu_notifier_invalidate_range_start(struct
> mmu_notifier_range *range)
> static inline int
> mmu_notifier_invalidate_range_start_nonblock(struct mmu_notifier_range
> *range)
> {
> + int ret = 0;
> lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
> if (mm_has_notifiers(range->mm)) {
> range->flags &= ~MMU_NOTIFIER_RANGE_BLOCKABLE;
> - return __mmu_notifier_invalidate_range_start(range);
> + ret = __mmu_notifier_invalidate_range_start(range);
> }
> lock_map_release(&__mmu_notifier_invalidate_range_start_map);
> - return 0;
> + return ret;
> }
>
> static inline void
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
Re: [PATCH v5 0/5] Add HDMI jack support on RK3288
Hi, On 08/09/2019 15:51, Cheng-yi Chiang wrote: > On Fri, Aug 30, 2019 at 10:55 AM Cheng-yi Chiang > wrote: >> >> On Wed, Jul 17, 2019 at 6:28 PM Tzung-Bi Shih wrote: >>> >>> On Wed, Jul 17, 2019 at 4:33 PM Cheng-Yi Chiang >>> wrote: This patch series supports HDMI jack reporting on RK3288, which uses DRM dw-hdmi driver and hdmi-codec codec driver. The previous discussion about reporting jack status using hdmi-notifier and drm_audio_component is at https://lore.kernel.org/patchwork/patch/1083027/ The new approach is to use a callback mechanism that is specific to hdmi-codec. Changes from v4 to v5: - synopsys/Kconfig: Remove the incorrect dependency change in v4. - rockchip/Kconfig: Add dependency of hdmi-codec when it is really need for jack support. Cheng-Yi Chiang (5): ASoC: hdmi-codec: Add an op to set callback function for plug event drm: bridge: dw-hdmi: Report connector status using callback drm: dw-hdmi-i2s: Use fixed id for codec device ASoC: rockchip_max98090: Add dai_link for HDMI ASoC: rockchip_max98090: Add HDMI jack support >>> LGTM. >>> >>> Reviewed-by: Tzung-Bi Shih >> >> Hi Daniel, >> Do you have further concern on this patch series related to hdmi-codec >> and drm part ? >> We would like to merge this patch series if possible. >> They will be needed in many future chrome projects for HDMI audio jack >> detection. >> Thanks a lot! > > Hi Neil, > I am not sure if this patch series is under your radar. > Would you mind taking a look ? > This patch series has been following great suggestions from various > reviewers, so I hope it is fine now. I'd like some review from ASoC people and other drm bridge reviewers, Jernej, Jonas & Andrzej. Jonas could have some comments on the overall patchset. > > Audio jack reporting for HDMI might not be needed for other OS, but it > is a must on ChromeOS. > We have many previous projects using different local patch sets to > achieve HDMI jack reporting. > I hope that we can achieve a proper way and really get the patches > merged to mainline. > Thanks a lot! > Sure, Don't forget to put Jernej, Jonas, and Jerome Brunet who is working on integrating audio on the Amlogic SoCs. Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/powerplay: Remove unnecessary comparison statement
Reviewed-by: Kevin Wang
Best Regards,
Kevin
From: amd-gfx on behalf of Austin Kim
Sent: Monday, September 9, 2019 12:31 PM
To: Deucher, Alexander ; airl...@linux.ie
; dan...@ffwll.ch
Cc: Zhou, David(ChunMing) ; amd-...@lists.freedesktop.org
; linux-ker...@vger.kernel.org
; dri-devel@lists.freedesktop.org
; Koenig, Christian
Subject: [PATCH] drm/amd/powerplay: Remove unnecessary comparison statement
size contain non-negative value since it is declared as uint32_t.
So below statement is always false.
if (size < 0)
Remove unnecessary comparison.
Signed-off-by: Austin Kim
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index 12c0e46..3c7c68e 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -1134,9 +1134,6 @@ static int navi10_set_power_profile_mode(struct
smu_context *smu, long *input, u
}
if (smu->power_profile_mode == PP_SMC_POWER_PROFILE_CUSTOM) {
- if (size < 0)
- return -EINVAL;
-
ret = smu_update_table(smu,
SMU_TABLE_ACTIVITY_MONITOR_COEFF,
WORKLOAD_PPLIB_CUSTOM_BIT,
(void *)(&activity_monitor), false);
--
2.6.2
___
amd-gfx mailing list
amd-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/4] Implement lazy unmapping for GEM VRAM buffers
On Fri, 06 Sep 2019, Thomas Zimmermann wrote: Generic fbdev emulation maps and unmaps the console BO for updating it's content from the shadow buffer. If this involves an actual mapping operation (instead of reusing an existing mapping), lots of debug messages may be printed, such as x86/PAT: Overlap at 0xd000-0xd100 x86/PAT: reserve_memtype added [mem 0xd000-0xd02f], track write-combining, req write-combining, ret write-combining x86/PAT: free_memtype request [mem 0xd000-0xd02f] as reported at [1]. Drivers using VRAM helpers may also see reduced performance as the mapping operations can create overhead. In v3 and later of the patch set, this problem is being solved by lazily unmapping the buffer as suggested by Gerd. Unmapping with drm_gem_vram_kunmap() only changes a reference counter. VRAM helpers later perform the unmapping operation when TTM evicts the buffer object from its current location. If the buffer is never evicted, the existing mapping is reused by later calls to drm_gem_vram_kmap(). v4: * lock kmap with ttm_bo_reserve() * acquire lock only once for vmap() * warn about stale mappings during buffer cleanup v3: * implement lazy unmapping v2: * fixed comment typos [1] https://lists.freedesktop.org/archives/dri-devel/2019-September/234308.html Thomas Zimmermann (4): drm/vram: Add kmap ref-counting to GEM VRAM objects drm/vram: Acquire lock only once per call to vmap()/vunmap() drm/vram: Add infrastructure for move_notify() drm/vram: Implement lazy unmapping for GEM VRAM buffers drivers/gpu/drm/drm_gem_vram_helper.c | 229 ++ drivers/gpu/drm/drm_vram_mm_helper.c | 12 ++ include/drm/drm_gem_vram_helper.h | 18 ++ include/drm/drm_vram_mm_helper.h | 4 + 4 files changed, 198 insertions(+), 65 deletions(-) Thanks for the prompt fix, feel free to add my: Reported-and-tested-by: Davidlohr Bueso ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] backlight_lm3630a: add enable_gpios property
To be able to handle the HWEN pin of the lm3630a, add an enable gpio to the driver and a property. Tested on Kobo Clara HD Andreas Kemnade (2): backlight: lm3630a: add an enable gpio for the HWEN pin dt-bindings: backlight: lm3630a: add enable_gpios .../leds/backlight/lm3630a-backlight.yaml | 4 drivers/video/backlight/lm3630a_bl.c | 18 ++ 2 files changed, 22 insertions(+) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Revert "ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware."
Since release of the new BCM2835 PM driver there has been several reports
of V3D probing issues. This is caused by timeouts during powering-up the
GRAFX PM domain:
bcm2835-power: Timeout waiting for grafx power OK
I was able to reproduce this reliable on my Raspberry Pi 3B+ after setting
force_turbo=1 in the firmware configuration. Since there are no issues
using the firmware PM driver with the same setup, there must be an issue
in the BCM2835 PM driver.
Unfortunately there hasn't been much progress in identifying the root cause
since June (mostly in the lack of documentation), so i decided to switch
back until the issue in the BCM2835 PM driver is fixed.
Link: https://github.com/raspberrypi/linux/issues/3046
Fixes: e1dc2b2e1bef (" ARM: bcm283x: Switch V3D over to using the PM driver
instead of firmware.")
Cc: sta...@vger.kernel.org
Signed-off-by: Stefan Wahren
---
arch/arm/boot/dts/bcm2835-rpi.dtsi | 4
arch/arm/boot/dts/bcm283x.dtsi | 4 +---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 6c6a7f6..b909e3b 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -67,6 +67,10 @@
power-domains = <&power RPI_POWER_DOMAIN_USB>;
};
+&v3d {
+ power-domains = <&power RPI_POWER_DOMAIN_V3D>;
+};
+
&vec {
power-domains = <&power RPI_POWER_DOMAIN_VEC>;
status = "okay";
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 2d191fc..b238567 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -3,7 +3,6 @@
#include
#include
#include
-#include
/* firmware-provided startup stubs live here, where the secondary CPUs are
* spinning.
@@ -121,7 +120,7 @@
#interrupt-cells = <2>;
};
- pm: watchdog@7e10 {
+ watchdog@7e10 {
compatible = "brcm,bcm2835-pm", "brcm,bcm2835-pm-wdt";
#power-domain-cells = <1>;
#reset-cells = <1>;
@@ -641,7 +640,6 @@
compatible = "brcm,bcm2835-v3d";
reg = <0x7ec0 0x1000>;
interrupts = <1 10>;
- power-domains = <&pm BCM2835_POWER_DOMAIN_GRAFX_V3D>;
};
vc4: gpu {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Kernel panic during drm/nouveau init 5.3.0-rc7-next-20190903
On Sat, Sep 07, 2019 at 12:32:41PM +0200, Daniel Vetter wrote: > On Sat, Sep 7, 2019 at 11:05 AM Alexander Kapshuk > wrote: > > > > To Whom It May Concern > > > > Every kernel I have built since 5.3.0-rc2-next-20190730 and up to > > 5.3.0-rc7-next-20190903 has resulted in the kernel panic described below. > > > > The panic occurs early on in the boot process, so no records of it get > > written on disk. I resourted to taking photos and videos to get the info > > for debugging. > > > > [Kernel panic] > > Code: 00 48 83 bb f0 00 00 00 00 74 16 48 83 c3 18 b9 17 00 00 00 31 c0 48 > > 89 df f3 48 ab 5b 41 5c 5d c3 4c 89 a3 f0 00 00 00 eb e1 <0f> 0b 0f 1f 40 > > 00 55 48 89 e5 41 54 49 89 d4 53 48 89 f3 e8 7e ff > > > > Kernel panic - Not syncing: Attempted to kill init! exitcode=0x000b. > > > > Top of call stack: > > __drm_fb_helper_initial_config_and_unlock > > drm_fb_helper_initial_config > > > > > Code: 00 48 83 bb f0 00 00 00 00 74 16 48 83 c3 18 b9 17 00 00 00 31 c0 48 > > 89 df f3 48 ab 5b 41 5c 5d c3 4c 89 a3 f0 00 00 00 eb e1 <0f> 0b 0f 1f 40 > > 00 55 48 89 e5 41 54 49 89 d4 53 48 89 f3 e8 7e ff > > All code > > > >0: 00 48 83add%cl,-0x7d(%rax) > >3: bb f0 00 00 00 mov$0xf0,%ebx > >8: 00 74 16 48 add%dh,0x48(%rsi,%rdx,1) > >c: 83 c3 18add$0x18,%ebx > >f: b9 17 00 00 00 mov$0x17,%ecx > > 14: 31 c0 xor%eax,%eax > > 16: 48 89 dfmov%rbx,%rdi > > 19: f3 48 abrep stos %rax,%es:(%rdi) > > 1c: 5b pop%rbx > > 1d: 41 5c pop%r12 > > 1f: 5d pop%rbp > > 20: c3 retq > > 21: 4c 89 a3 f0 00 00 00mov%r12,0xf0(%rbx) > > 28: eb e1 jmp0xb > > 2a:* 0f 0b ud2 <-- trapping instruction > > 2c: 0f 1f 40 00 nopl 0x0(%rax) > > 30: 55 push %rbp > > 31: 48 89 e5mov%rsp,%rbp > > 34: 41 54 push %r12 > > 36: 49 89 d4mov%rdx,%r12 > > 39: 53 push %rbx > > 3a: 48 89 f3mov%rsi,%rbx > > 3d: e8 .byte 0xe8 > > 3e: 7e ff jle0x3f > > > > Code starting with the faulting instruction > > === > >0: 0f 0b ud2 > >2: 0f 1f 40 00 nopl 0x0(%rax) > >6: 55 push %rbp > >7: 48 89 e5mov%rsp,%rbp > >a: 41 54 push %r12 > >c: 49 89 d4mov%rdx,%r12 > >f: 53 push %rbx > > 10: 48 89 f3mov%rsi,%rbx > > 13: e8 .byte 0xe8 > > 14: 7e ff jle0x15 > > > > The panic occurs after the 'Driver supports precise vblank timestamp > > query.' line gets printed to console: > > [2.858970] Linux agpgart interface v0.103 > > [2.859308] nouveau :01:00.0: NVIDIA G84 (084300a2) > > [2.968950] nouveau :01:00.0: bios: version 60.84.68.00.19 > > [2.989923] nouveau :01:00.0: bios: M0203T not found > > [2.990010] nouveau :01:00.0: bios: M0203E not matched! > > [2.990096] nouveau :01:00.0: fb: 512 MiB DDR2 > > [3.062362] [TTM] Zone kernel: Available graphics memory: 2015014 KiB > > [3.062494] [TTM] Initializing pool allocator > > [3.062581] [TTM] Initializing DMA pool allocator > > [3.062683] nouveau :01:00.0: DRM: VRAM: 512 MiB > > [3.062769] nouveau :01:00.0: DRM: GART: 1048576 MiB > > [3.062859] nouveau :01:00.0: DRM: TMDS table version 2.0 > > [3.062944] nouveau :01:00.0: DRM: DCB version 4.0 > > [3.063030] nouveau :01:00.0: DRM: DCB outp 00: 02000300 0028 > > [3.063117] nouveau :01:00.0: DRM: DCB outp 01: 01000302 0030 > > [3.063203] nouveau :01:00.0: DRM: DCB outp 02: 04011310 0028 > > [3.063290] nouveau :01:00.0: DRM: DCB outp 03: 02011312 00c000b0 > > [3.063377] nouveau :01:00.0: DRM: DCB conn 00: 1030 > > [3.063462] nouveau :01:00.0: DRM: DCB conn 01: 2130 > > [3.065982] nouveau :01:00.0: DRM: MM: using CRYPT for buffer copies > > [3.066622] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > [3.066754] [drm] Driver supports precise vblank timestamp query. > > > > I was not able to capture the value of RIP for this crash. > > > > With drm_kms_helper.fbdev_emulation=0 enabled, as documented in > > the commentary to function drm_fb_helper_initial_config defined in > > drivers/gpu/drm/drm_fb_helper.c, I get the following output: > > > > RIP: 0010: _raw_spin_lock+0x7/0x20 > > Code: ba ff 00 00 00 f0 0f b1 17 75 01 c3 55 48 89 e5 e8 2
[PATCH 2/2] dt-bindings: backlight: lm3630a: add enable_gpios
add enable-gpios to describe HWEN pin Signed-off-by: Andreas Kemnade --- .../devicetree/bindings/leds/backlight/lm3630a-backlight.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml index dc129d9a329e..a9656d72b668 100644 --- a/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml @@ -29,6 +29,10 @@ properties: '#size-cells': const: 0 + enable-gpios: +description: GPIO to use to enable/disable the backlight (HWEN pin). +maxItems: 1 + required: - compatible - reg -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] backlight: lm3630a: add an enable gpio for the HWEN pin
For now just enable it in the probe function to allow i2c
access and disable it on remove. Disabling also means resetting
the register values to default.
Tested on Kobo Clara HD.
Signed-off-by: Andreas Kemnade
---
drivers/video/backlight/lm3630a_bl.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/video/backlight/lm3630a_bl.c
b/drivers/video/backlight/lm3630a_bl.c
index b04b35d007a2..3b45a1733198 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -12,6 +12,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -48,6 +50,7 @@ struct lm3630a_chip {
struct lm3630a_platform_data *pdata;
struct backlight_device *bleda;
struct backlight_device *bledb;
+ struct gpio_desc *enable_gpio;
struct regmap *regmap;
struct pwm_device *pwmd;
};
@@ -506,6 +509,14 @@ static int lm3630a_probe(struct i2c_client *client,
return -ENOMEM;
pchip->dev = &client->dev;
+ pchip->enable_gpio = devm_gpiod_get_optional(&client->dev, "enable",
+ GPIOD_ASIS);
+ if (IS_ERR(pchip->enable_gpio)) {
+ rval = PTR_ERR(pchip->enable_gpio);
+ return rval;
+ }
+
+
pchip->regmap = devm_regmap_init_i2c(client, &lm3630a_regmap);
if (IS_ERR(pchip->regmap)) {
rval = PTR_ERR(pchip->regmap);
@@ -535,6 +546,10 @@ static int lm3630a_probe(struct i2c_client *client,
}
pchip->pdata = pdata;
+ if (pchip->enable_gpio) {
+ gpiod_set_value_cansleep(pchip->enable_gpio, 1);
+ usleep_range(1000, 2000);
+ }
/* chip initialize */
rval = lm3630a_chip_init(pchip);
if (rval < 0) {
@@ -586,6 +601,9 @@ static int lm3630a_remove(struct i2c_client *client)
if (rval < 0)
dev_err(pchip->dev, "i2c failed to access register\n");
+ if (pchip->enable_gpio)
+ gpiod_set_value_cansleep(pchip->enable_gpio, 0);
+
if (pchip->irq) {
free_irq(pchip->irq, pchip);
flush_workqueue(pchip->irqthread);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: bridge/dw_hdmi: add audio sample channel status setting
Dne četrtek, 05. september 2019 ob 11:43:25 CEST je Cheng-Yi Chiang
napisal(a):
> From: Yakir Yang
>
> When transmitting IEC60985 linear PCM audio, we configure the
> Aduio Sample Channel Status information of all the channel
> status bits in the IEC60958 frame.
> Refer to 60958-3 page 10 for frequency, original frequency, and
> wordlength setting.
>
> This fix the issue that audio does not come out on some monitors
> (e.g. LG 22CV241)
>
> Note that these registers are only for interfaces:
> I2S audio interface, General Purpose Audio (GPA), or AHB audio DMA
> (AHBAUDDMA).
> For S/PDIF interface this information comes from the stream.
>
> Currently this function dw_hdmi_set_channel_status is only called
> from dw-hdmi-i2s-audio in I2S setup.
>
> Signed-off-by: Yakir Yang
> Signed-off-by: Cheng-Yi Chiang
> ---
> Original patch by Yakir Yang is at
>
> https://lore.kernel.org/patchwork/patch/539653/
>
> Change from v1 to v2:
> 1. Remove the version check because this will only be called by
> dw-hdmi-i2s-audio, and the registers are available in I2S setup.
> 2. Set these registers in dw_hdmi_i2s_hw_params.
> 3. Fix the sample width setting so it can use 16 or 24 bits.
>
> .../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 1 +
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 70 +++
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 20 ++
> include/drm/bridge/dw_hdmi.h | 2 +
> 4 files changed, 93 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index
> 34d8e837555f..b801a28b0f17 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> @@ -102,6 +102,7 @@ static int dw_hdmi_i2s_hw_params(struct device *dev,
> void *data, }
>
> dw_hdmi_set_sample_rate(hdmi, hparms->sample_rate);
> + dw_hdmi_set_channel_status(hdmi, hparms->sample_width);
> dw_hdmi_set_channel_count(hdmi, hparms->channels);
> dw_hdmi_set_channel_allocation(hdmi, hparms-
>cea.channel_allocation);
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index
> bd65d0479683..d1daa369c8ae 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -582,6 +582,76 @@ static unsigned int hdmi_compute_n(unsigned int freq,
> unsigned long pixel_clk) return n;
> }
>
> +/*
> + * When transmitting IEC60958 linear PCM audio, these registers allow to
> + * configure the channel status information of all the channel status
> + * bits in the IEC60958 frame. For the moment this configuration is only
> + * used when the I2S audio interface, General Purpose Audio (GPA),
> + * or AHB audio DMA (AHBAUDDMA) interface is active
> + * (for S/PDIF interface this information comes from the stream).
> + */
> +void dw_hdmi_set_channel_status(struct dw_hdmi *hdmi,
> + unsigned int sample_width)
> +{
> + u8 aud_schnl_samplerate;
> + u8 aud_schnl_8;
> + u8 word_length_bits;
> +
> + switch (hdmi->sample_rate) {
> + case 32000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_32K;
> + break;
> + case 44100:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_44K1;
> + break;
> + case 48000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_48K;
> + break;
> + case 88200:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_88K2;
> + break;
> + case 96000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_96K;
> + break;
> + case 176400:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_176K4;
> + break;
> + case 192000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_192K;
> + break;
> + case 768000:
> + aud_schnl_samplerate = HDMI_FC_AUDSCHNLS7_SMPRATE_768K;
> + break;
> + default:
> + dev_warn(hdmi->dev, "Unsupported audio sample rate (%u)
\n",
> + hdmi->sample_rate);
> + return;
> + }
> +
> + /* set channel status register */
> + hdmi_modb(hdmi, aud_schnl_samplerate,
HDMI_FC_AUDSCHNLS7_SMPRATE_MASK,
> + HDMI_FC_AUDSCHNLS7);
> +
> + /*
> + * Set original frequency to be the same as frequency.
> + * Use one-complement value as stated in IEC60958-3 page 13.
> + */
> + aud_schnl_8 = (~aud_schnl_samplerate) <<
> + HDMI_FC_AUDSCHNLS8_ORIGSAMPFREQ_OFFSET;
> +
> + /*
> + * Refer to IEC60958-3 page 12. We can accept 16 bits or 24 bits.
> + * Otherwise, set the register to 0t o indicate using default
value.
Nit: "0t 0" -> "0 to"
With that fixed, this patch is:
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> +
[PATCH] drm/amd/powerplay: Remove unnecessary comparison statement
size contain non-negative value since it is declared as uint32_t.
So below statement is always false.
if (size < 0)
Remove unnecessary comparison.
Signed-off-by: Austin Kim
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
index 12c0e46..3c7c68e 100644
--- a/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
+++ b/drivers/gpu/drm/amd/powerplay/navi10_ppt.c
@@ -1134,9 +1134,6 @@ static int navi10_set_power_profile_mode(struct
smu_context *smu, long *input, u
}
if (smu->power_profile_mode == PP_SMC_POWER_PROFILE_CUSTOM) {
- if (size < 0)
- return -EINVAL;
-
ret = smu_update_table(smu,
SMU_TABLE_ACTIVITY_MONITOR_COEFF,
WORKLOAD_PPLIB_CUSTOM_BIT,
(void *)(&activity_monitor), false);
--
2.6.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Spice-devel] Xorg indefinitely hangs in kernelspace
>From Frediano Ziglio > > Where does it came this patch? My fingers tapping the keyboard. > Is it already somewhere? No idea yet. > Is it supposed to fix this issue? It may do nothing else as far as I can tell. > Does it affect some other card beside QXL? Perhaps. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111236] VA-API radeonsi SIGSEGV __memmove_avx_unaligned
https://bugs.freedesktop.org/show_bug.cgi?id=111236 --- Comment #12 from Víctor Jáquez --- Hi Michel, The patch also worked for me! :) Thanks! In the case of totem, there's a work in progress https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/merge_requests/122 but it requires a lot more work. -- 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/8] drm/vram: switch to gem vma offset manager
Am 05.09.19 um 09:05 schrieb Gerd Hoffmann: > Pass gem vma_offset_manager to ttm_bo_device_init(), so ttm uses it > instead of its own embedded struct. This makes some gem functions > (specifically drm_gem_object_lookup) work on ttm objects. > > Signed-off-by: Gerd Hoffmann > --- > drivers/gpu/drm/drm_vram_mm_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_vram_mm_helper.c > b/drivers/gpu/drm/drm_vram_mm_helper.c > index 56fd1519eb35..3b2552bec4e6 100644 > --- a/drivers/gpu/drm/drm_vram_mm_helper.c > +++ b/drivers/gpu/drm/drm_vram_mm_helper.c > @@ -172,7 +172,7 @@ int drm_vram_mm_init(struct drm_vram_mm *vmm, struct > drm_device *dev, > > ret = ttm_bo_device_init(&vmm->bdev, &bo_driver, >dev->anon_inode->i_mapping, > - NULL, > + dev->vma_offset_manager, >true); > if (ret) > return ret; > Acked-by: Thomas Zimmermann -- Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) signature.asc Description: OpenPGP digital signature
Re: [PATCH 8/8] drm/ttm: remove embedded vma_offset_manager
Am 05.09.19 um 09:05 schrieb Gerd Hoffmann:
> No users left. Drivers either setup vma_offset_manager themself
> (vmwgfx) or pass the gem vma_offset_manager to ttm_bo_device_init
> (all other drivers).
>
> Signed-off-by: Gerd Hoffmann
Patches #4, #5 and #8 in this series are Reviewed-by: Christian König
I can't see the rest in my inbox anywhere. Have you send all of them to
dri-devel?
Christian.
> ---
> include/drm/ttm/ttm_bo_driver.h | 4 +---
> drivers/gpu/drm/ttm/ttm_bo.c| 9 ++---
> 2 files changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index e365434f92b3..4e307f65f497 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -442,7 +442,6 @@ extern struct ttm_bo_global {
>* @driver: Pointer to a struct ttm_bo_driver struct setup by the driver.
>* @man: An array of mem_type_managers.
>* @vma_manager: Address space manager (pointer)
> - * @_vma_manager: Address space manager (enbedded)
>* lru_lock: Spinlock that protects the buffer+device lru lists and
>* ddestroy lists.
>* @dev_mapping: A pointer to the struct address_space representing the
> @@ -466,7 +465,6 @@ struct ttm_bo_device {
>* Protected by internal locks.
>*/
> struct drm_vma_offset_manager *vma_manager;
> - struct drm_vma_offset_manager _vma_manager;
>
> /*
>* Protected by the global:lru lock.
> @@ -587,7 +585,7 @@ int ttm_bo_device_release(struct ttm_bo_device *bdev);
>* @glob: A pointer to an initialized struct ttm_bo_global.
>* @driver: A pointer to a struct ttm_bo_driver set up by the caller.
>* @mapping: The address space to use for this bo.
> - * @vma_manager: A pointer to a vma manager or NULL.
> + * @vma_manager: A pointer to a vma manager.
>* @file_page_offset: Offset into the device address space that is available
>* for buffer data. This ensures compatibility with other users of the
>* address space.
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 8dc26babc5cb..881cf26d698e 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1704,8 +1704,6 @@ int ttm_bo_device_release(struct ttm_bo_device *bdev)
> pr_debug("Swap list %d was clean\n", i);
> spin_unlock(&glob->lru_lock);
>
> - drm_vma_offset_manager_destroy(&bdev->_vma_manager);
> -
> if (!ret)
> ttm_bo_global_release();
>
> @@ -1722,8 +1720,8 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
> struct ttm_bo_global *glob = &ttm_bo_glob;
> int ret;
>
> - if (!vma_manager)
> - vma_manager = &bdev->_vma_manager;
> + if (WARN_ON(vma_manager == NULL))
> + return -EINVAL;
>
> ret = ttm_bo_global_init();
> if (ret)
> @@ -1742,9 +1740,6 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
> goto out_no_sys;
>
> bdev->vma_manager = vma_manager;
> - drm_vma_offset_manager_init(&bdev->_vma_manager,
> - DRM_FILE_PAGE_OFFSET_START,
> - DRM_FILE_PAGE_OFFSET_SIZE);
> INIT_DELAYED_WORK(&bdev->wq, ttm_bo_delayed_workqueue);
> INIT_LIST_HEAD(&bdev->ddestroy);
> bdev->dev_mapping = mapping;
