Re: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'

On Wed, May 13, 2020 at 06:13:17AM +, Ashwin H wrote: > This patch fixes CVE-2018-20669 in 4.19 tree. Ok, but what does that mean for us? You need to say why you are sending a patch, otherwise we will guess wrong. greg k-h ___ dri-devel mailing lis

Re: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'

This patch fixes CVE-2018-20669 in 4.19 tree. On 13/05/20, 11:36 AM, "Greg KH" wrote: On Wed, May 13, 2020 at 07:19:21AM +0530, ashwin-h wrote: > From: Linus Torvalds > > commit 594cc251fdd0d231d342d88b2fdff4bc42fb0690 upstream. > > Originally, the rule used to be tha

Re: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'

On Wed, May 13, 2020 at 07:19:21AM +0530, ashwin-h wrote: > From: Linus Torvalds > > commit 594cc251fdd0d231d342d88b2fdff4bc42fb0690 upstream. > > Originally, the rule used to be that you'd have to do access_ok() > separately, and then user_access_begin() before actually doing the > direct (opti

Re: [RFC 16/17] drm/amdgpu: gpu recovery does full modesets

On Tue, May 12, 2020 at 10:10 PM Kazlauskas, Nicholas wrote: > > On 2020-05-12 12:12 p.m., Daniel Vetter wrote: > > On Tue, May 12, 2020 at 4:24 PM Alex Deucher wrote: > >> > >> On Tue, May 12, 2020 at 9:45 AM Daniel Vetter > >> wrote: > >>> > >>> On Tue, May 12, 2020 at 3:29 PM Alex Deucher

[PATCH v5 3/3] drm/i915/dp: Expose connector VRR info via debugfs

From: Bhanuprakash Modem [Why] It's useful to know the min and max vrr range for IGT testing. [How] Expose the min and max vfreq for the connector via a debugfs file on the connector, "i915_vrr_info". Example usage: cat /sys/kernel/debug/dri/0/DP-1/i915_vrr_info v5: * Rename to vrr_range to ma

[PATCH v5 1/3] drm/dp: DRM DP helper for reading Ignore MSA from DPCD

DP sink device sets the Ignore MSA bit in its DP_DOWNSTREAM_PORT_COUNT register to indicate its ability to ignore the MSA video timing parameters and its ability to support seamless video timing change over a range of timing exposed by DisplayID and EDID. This is required for the sink to indicate t

[PATCH v5 2/3] drm/i915/dp: Attach and set drm connector VRR property

From: Aditya Swarup This function sets the VRR property for connector based on the platform support, EDID monitor range and DP sink DPCD capability of outputing video without msa timing information. v5: * Fix the vrr prop not being set in kernel (Manasi) * Unset the prop on connector disconnect

Re: [PATCH] drm/exynos: dsi: Remove bridge node reference in error handling path in probe function

Hi, 20. 5. 11. 오전 12:48에 Christophe JAILLET 이(가) 쓴 글: > 'exynos_dsi_parse_dt()' takes a reference to 'dsi->in_bridge_node'. > This must be released in the error handling path. > > This patch is similar to commit 70505c2ef94b ("drm/exynos: dsi: Remove bridge > node reference in removal") > which

Re: [PATCH] docs: dt: fix broken links due to txt->yaml renames

On Mon, May 04, 2020 at 11:30:20AM +0200, Mauro Carvalho Chehab wrote: > There are some new broken doc links due to yaml renames > at DT. Developers should really run: > > ./scripts/documentation-file-ref-check > > in order to solve those issues while submitting patches. > This tool can eve

[pull] amdgpu, amdkfd drm-next-5.8

Hi Dave, Daniel, More stuff for 5.8. The following changes since commit b8020b0304c8f44e5e29f0b1a04d31e0bf68d26a: drm/amdkfd: Enable over-subscription with >1 GWS queue (2020-04-28 16:20:30 -0400) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux tags/amd-d

Re: [RFC v2] drm/connector: Add support for privacy-screen properties (v2)

Hi, On 5/12/20 10:44 PM, mario.limoncie...@dell.com wrote: -Original Message- From: Hans de Goede Sent: Monday, May 11, 2020 12:47 PM To: Maarten Lankhorst; Maxime Ripard; Thomas Zimmermann; Daniel Vetter; David Airlie; Rajat Jain; Jani Nikula Cc: Hans de Goede; Pekka Paalanen; Limoncie

Re: [Nouveau] [PATCH 1/3] drm/radeon: remove AGP support

On Tue, May 12, 2020 at 4:52 PM Roy Spliet wrote: > > Op 12-05-2020 om 14:36 schreef Alex Deucher: > > On Tue, May 12, 2020 at 4:16 AM Michel Dänzer wrote: > >> > >> On 2020-05-11 10:12 p.m., Alex Deucher wrote: > >>> On Mon, May 11, 2020 at 1:17 PM Christian König > >>> wrote: > > AGP

Re: [PATCH v10 0/2] Panel rotation patches

On Thu, Apr 16, 2020 at 7:03 PM Dmitry Osipenko wrote: > > 15.04.2020 00:32, dbasehore . пишет: > > On Tue, Apr 14, 2020 at 2:18 PM Dmitry Osipenko wrote: > >> > >> 14.04.2020 22:32, dbasehore . пишет: > >>> Hi Dmitry, sorry for the late reply. > >>> > >>> On Sun, Mar 8, 2020 at 12:25 PM Dmitry O

Re: [PATCH v4 38/38] videobuf2: use sgtable-based scatterlist wrappers

Hi Michael, On 12.05.2020 19:52, Ruhl, Michael J wrote: >> -Original Message- >> From: dri-devel On Behalf Of >> Marek Szyprowski >> Sent: Tuesday, May 12, 2020 5:01 AM >> To: dri-devel@lists.freedesktop.org; io...@lists.linux-foundation.org; >> linaro-mm-...@lists.linaro.org; linux-ker..

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Wed, 13 May 2020 at 04:21, Alex Deucher wrote: > > On Tue, May 12, 2020 at 1:02 PM Rui Salvaterra wrote: > > > > On Tue, 12 May 2020 at 17:38, Daniel Vetter wrote: > > > > > > Otherwise all agree, agp is a mighty mess and essentially just > > > crapshot outside of x86. It kinda worked for the

Re: [RFC 16/17] drm/amdgpu: gpu recovery does full modesets

On 2020-05-12 12:12 p.m., Daniel Vetter wrote: On Tue, May 12, 2020 at 4:24 PM Alex Deucher wrote: On Tue, May 12, 2020 at 9:45 AM Daniel Vetter wrote: On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote: On Tue, May 12, 2020 at 9:17 AM Daniel Vetter wrote: On Tue, May 12, 2020 at 3:12

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, May 12, 2020 at 3:10 PM Thomas Zimmermann wrote: > > Hi Alex > > Am 12.05.20 um 20:32 schrieb Alex Deucher: > > On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann > > wrote: > >> > >> Hi > >> > >> Am 11.05.20 um 19:17 schrieb Christian König: > >>> Hi guys, > >>> > >>> Well let's face it

Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780

Hello, On and off over the past few months, I have been looking at getting the Synopsys DesignWare HDMI peripheral used in the Ingenic JZ4780 SoC working with a recent kernel. Unfortunately, what probably should be a straightforward task is proving more difficult than it seems, and I have been

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

Hi Alex Am 12.05.20 um 20:32 schrieb Alex Deucher: > On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann wrote: >> >> Hi >> >> Am 11.05.20 um 19:17 schrieb Christian König: >>> Hi guys, >>> >>> Well let's face it AGP is a total headache to maintain and dead for at >>> least 10+ years. >>> >>> We h

Re: [PATCH v2 00/15] drm/mgag200: Convert to atomic modesetting

Hi Thomas. On Tue, May 12, 2020 at 10:42:43AM +0200, Thomas Zimmermann wrote: > This patchset converts mgag200 to atomic modesetting. It uses simple > KMS helpers and SHMEM. > > Patch 1 removes cursor support. The HW cursor is not usable with the > way universal planes work. > > Patches 2 to 11

Re: [PATCH v2 15/15] drm/mgag200: Replace VRAM helpers with SHMEM helpers

Hi Am 12.05.20 um 12:30 schrieb Emil Velikov: > On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote: >> >> The VRAM helpers managed the framebuffer memory for mgag200. This came >> with several problems, as some MGA device require the scanout address >> to be located at VRAM offset 0. It's inco

Re: [PATCH v2 02/15] drm/mgag200: Clean up mga_set_start_address()

Hi Thomas. On Tue, May 12, 2020 at 10:42:45AM +0200, Thomas Zimmermann wrote: > All register names and fields are now named according to the > MGA programming manuals. The function doesn't need the CRTC, so > callers pass in the device structure directly. The logging now > uses device-specific mac

Re: [PATCH v2 12/15] drm/mgag200: Remove out-commented suspend/resume helpers

Hi Am 12.05.20 um 12:14 schrieb Emil Velikov: > Hi Thomas, > > On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote: >> >> The suspend/resume helpers are unused. Also remove associated state >> from struct mga_device. >> > Although DPMS in it's traditional sense is no longer a thing, would it >

Re: [PATCH v2 13/15] drm/mgag200: Use simple-display data structures

Hi Am 12.05.20 um 12:16 schrieb Emil Velikov: > Hi Thomas, > > On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote: > >> static void mga_crtc_init(struct mga_device *mdev) >> { >> struct drm_device *dev = mdev->dev; >> - struct mga_crtc *mga_crtc; >> - >> - mga_crtc = kz

Re: [PATCH v2 07/15] drm/mgag200: Set pitch in a separate helper function

Hi Emil Am 12.05.20 um 12:27 schrieb Emil Velikov: > Hi Thomas, > > On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote: > >> @@ -1143,20 +1178,15 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc, >> WREG_CRT(13, 0); >> WREG_CRT(14, 0); >> WREG_CRT(15, 0); >> -

Re: [RFC 10/17] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code

On Tue, May 12, 2020 at 7:31 PM Christian König wrote: > > Ah! > > So we can't allocate memory while scheduling anything because it could > be that memory reclaim is waiting for the scheduler to finish pushing > things to the hardware, right? Yup, that's my understanding. But like with all things

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann wrote: > > Hi > > Am 11.05.20 um 19:17 schrieb Christian König: > > Hi guys, > > > > Well let's face it AGP is a total headache to maintain and dead for at > > least 10+ years. > > > > We have a lot of x86 specific stuff in the architecture indepe

Re: [PATCH 1/3] drm/radeon: remove AGP support

On Tue, May 12, 2020 at 2:20 PM Thomas Zimmermann wrote: > > Hi Christian > > Am 11.05.20 um 19:17 schrieb Christian König: > > AGP is deprecated for 10+ years now and not used any more on modern > > hardware. > > > > Old hardware should continue to work in PCI mode. > > > > Signed-off-by: Christ

Re: [Nouveau] [RFC] Remove AGP support from Radeon/Nouveau/TTM

Hi Am 11.05.20 um 19:17 schrieb Christian König: > Hi guys, > > Well let's face it AGP is a total headache to maintain and dead for at least > 10+ years. > > We have a lot of x86 specific stuff in the architecture independent graphics > memory management to get the caching right, abusing the D

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, May 12, 2020 at 12:38 PM Daniel Vetter wrote: > > On Tue, May 12, 2020 at 3:22 PM Alex Deucher wrote: > > > > On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR) > > wrote: > > > > > > Hi, > > > > > > On Tue, 12 May 2020, Rui Salvaterra wrote: > > > > > > > > FWIW, on my last-gen

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, May 12, 2020 at 1:02 PM Rui Salvaterra wrote: > > On Tue, 12 May 2020 at 17:38, Daniel Vetter wrote: > > > > Otherwise all agree, agp is a mighty mess and essentially just > > crapshot outside of x86. It kinda worked for the much more static > > allocations for dri1, but with in-kernel me

Re: [PATCH 1/3] drm/radeon: remove AGP support

Hi Christian Am 11.05.20 um 19:17 schrieb Christian König: > AGP is deprecated for 10+ years now and not used any more on modern hardware. > > Old hardware should continue to work in PCI mode. > > Signed-off-by: Christian König > --- > drivers/gpu/drm/radeon/Makefile| 4 +- > drivers

[PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'

From: Linus Torvalds commit 594cc251fdd0d231d342d88b2fdff4bc42fb0690 upstream. Originally, the rule used to be that you'd have to do access_ok() separately, and then user_access_begin() before actually doing the direct (optimized) user access. But experience has shown that people then decide no

RE: [PATCH v4 38/38] videobuf2: use sgtable-based scatterlist wrappers

>-Original Message- >From: dri-devel On Behalf Of >Marek Szyprowski >Sent: Tuesday, May 12, 2020 5:01 AM >To: dri-devel@lists.freedesktop.org; io...@lists.linux-foundation.org; >linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org >Cc: Pawel Osciak ; Bartlomiej Zolnierkiewicz >;

Re: [RFC 10/17] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code

Ah! So we can't allocate memory while scheduling anything because it could be that memory reclaim is waiting for the scheduler to finish pushing things to the hardware, right? Indeed a nice problem, haven't noticed that one. Christian. Am 12.05.20 um 18:27 schrieb Daniel Vetter: On Tue, Ma

Re: [RFC][PATCH 3/4] dma-buf: cma_heap: Extend logic to export CMA regions tagged with "linux,cma-heap"

On Mon, May 04, 2020 at 10:06:28AM +0100, Brian Starkey wrote: > On Fri, May 01, 2020 at 12:01:40PM -0700, John Stultz wrote: > > On Fri, May 1, 2020 at 4:08 AM Robin Murphy wrote: > > > > > > On 2020-05-01 11:21 am, Brian Starkey wrote: > > > > Hi John, > > > > > > > > On Fri, May 01, 2020 at 07:

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, May 12, 2020 at 3:22 PM Alex Deucher wrote: > > On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR) > wrote: > > > > Hi, > > > > On Tue, 12 May 2020, Rui Salvaterra wrote: > > > > > > FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a > > > > big performance diff

Re: [RFC 10/17] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code

On Tue, May 12, 2020 at 6:20 PM Daniel Vetter wrote: > > On Tue, May 12, 2020 at 5:56 PM Christian König > wrote: > > > > Hui what? Of hand that doesn't looks correct to me. > > It's not GFP_ATOMIC, it's just that GFP_ATOMIC is the only shotgun we > have to avoid direct reclaim. And direct reclai

Re: [RFC 10/17] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code

On Tue, May 12, 2020 at 5:56 PM Christian König wrote: > > Hui what? Of hand that doesn't looks correct to me. It's not GFP_ATOMIC, it's just that GFP_ATOMIC is the only shotgun we have to avoid direct reclaim. And direct reclaim might need to call into your mmu notifier, which might need to wait

Re: [RFC 16/17] drm/amdgpu: gpu recovery does full modesets

On Tue, May 12, 2020 at 4:24 PM Alex Deucher wrote: > > On Tue, May 12, 2020 at 9:45 AM Daniel Vetter wrote: > > > > On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote: > > > > > > On Tue, May 12, 2020 at 9:17 AM Daniel Vetter > > > wrote: > > > > > > > > On Tue, May 12, 2020 at 3:12 PM Alex D

Re: [RFC v2 0/1] drm/connector: Add support for privacy-screen properties

Hi, On 5/12/20 4:20 PM, Pekka Paalanen wrote: On Tue, 12 May 2020 10:18:31 +0200 Hans de Goede wrote: Hi, On 5/11/20 9:55 PM, Rajat Jain wrote: Hi Hans, On Mon, May 11, 2020 at 10:47 AM Hans de Goede mailto:hdego...@redhat.com>> wrote: Hi All, This RFC takes Rajat's earlier pat

Re: [RFC 10/17] drm/amdgpu: s/GFP_KERNEL/GFP_ATOMIC in scheduler code

Hui what? Of hand that doesn't looks correct to me. Why the heck should this be an atomic context? If that's correct allocating memory is the least of the problems we have. Regards, Christian. Am 12.05.20 um 10:59 schrieb Daniel Vetter: My dma-fence lockdep annotations caught an inversion be

Re: [PATCH][next] drm/amdgpu: remove redundant assignment to variable ret

On Tue, May 12, 2020 at 8:48 AM Colin King wrote: > > From: Colin Ian King > > The variable ret is being initializeed with a value that is never read > and it is being updated later with a new value. The initialization > is redundant and can be removed. > > Addresses-Coverity: ("Unused value") >

Re: [RFC 16/17] drm/amdgpu: gpu recovery does full modesets

On Tue, May 12, 2020 at 9:45 AM Daniel Vetter wrote: > > On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote: > > > > On Tue, May 12, 2020 at 9:17 AM Daniel Vetter > > wrote: > > > > > > On Tue, May 12, 2020 at 3:12 PM Alex Deucher > > > wrote: > > > > > > > > On Tue, May 12, 2020 at 8:58 AM D

Re: [RFC v2 0/1] drm/connector: Add support for privacy-screen properties

On Tue, 12 May 2020 10:18:31 +0200 Hans de Goede wrote: > Hi, > > On 5/11/20 9:55 PM, Rajat Jain wrote: > > Hi Hans, > > > > On Mon, May 11, 2020 at 10:47 AM Hans de Goede > > wrote: > > > > Hi All, > > > > This RFC takes Rajat's earlier patch for adding p

Re: [RFC v2] drm/connector: Add support for privacy-screen properties (v2)

On Tue, 12 May 2020 10:02:12 +0200 Hans de Goede wrote: > Hi, > > On 5/12/20 9:49 AM, Pekka Paalanen wrote: > > On Mon, 11 May 2020 19:47:24 +0200 > > Hans de Goede wrote: > > > >> From: Rajat Jain > >> > >> Add support for generic electronic privacy screen properties, that > >> can be adde

Re: [RFC 16/17] drm/amdgpu: gpu recovery does full modesets

On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote: > > On Tue, May 12, 2020 at 9:17 AM Daniel Vetter wrote: > > > > On Tue, May 12, 2020 at 3:12 PM Alex Deucher wrote: > > > > > > On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote: > > > > > > > > On Tue, May 12, 2020 at 08:54:45AM -0400, Ale

Re: [PATCH 1/3] drm/radeon: remove AGP support

On Tue, May 12, 2020 at 4:16 AM Michel Dänzer wrote: > > On 2020-05-11 10:12 p.m., Alex Deucher wrote: > > On Mon, May 11, 2020 at 1:17 PM Christian König > > wrote: > >> > >> AGP is deprecated for 10+ years now and not used any more on modern > >> hardware. > >> > >> Old hardware should continu

Re: [RFC 16/17] drm/amdgpu: gpu recovery does full modesets

On Tue, May 12, 2020 at 9:17 AM Daniel Vetter wrote: > > On Tue, May 12, 2020 at 3:12 PM Alex Deucher wrote: > > > > On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote: > > > > > > On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote: > > > > On Tue, May 12, 2020 at 5:00 AM Daniel Vette

[Bug 207693] amdgpu: RX 5500 XT boost frequency out of spec

https://bugzilla.kernel.org/show_bug.cgi?id=207693 --- Comment #2 from Jan Ziak (http://atom-symbol.net) (0xe2.0x9a.0...@gmail.com) --- (In reply to Alex Deucher from comment #1) > The vbios defines the clock frequencies and nominal voltages, not the > driver. The voltage is changed dynamically

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

On Tue, May 12, 2020 at 5:40 AM Karoly Balogh (Charlie/SGR) wrote: > > Hi, > > On Tue, 12 May 2020, Rui Salvaterra wrote: > > > > FWIW, on my last-generation PowerBook with RV350 (IIRC), there was a > > > big performance difference between AGP and PCI GART. The latter was > > > sort of usable for

Re: [PATCH v4 01/38] dma-mapping: add generic helpers for mapping sgtable objects

Hi Christoph, On 12.05.2020 15:09, Christoph Hellwig wrote: > On Tue, May 12, 2020 at 03:00:31PM +0200, Marek Szyprowski wrote: >>> if (n <= 0) >>> return -EINVAL; >>> sgt->nents = n; >>> return 0; >>> >> Indeed this version looks much better. I will resend it in a few minu

Re: [RFC 16/17] drm/amdgpu: gpu recovery does full modesets

On Tue, May 12, 2020 at 3:12 PM Alex Deucher wrote: > > On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote: > > > > On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote: > > > On Tue, May 12, 2020 at 5:00 AM Daniel Vetter > > > wrote: > > > > > > > > ... > > > > > > > > I think it's ti

Re: [RFC 16/17] drm/amdgpu: gpu recovery does full modesets

On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote: > > On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote: > > On Tue, May 12, 2020 at 5:00 AM Daniel Vetter > > wrote: > > > > > > ... > > > > > > I think it's time to stop this little exercise. > > > > > > The lockdep splat, for the r

Re: [PATCH -next] drm/mcde: dsi: Fix return value check in dev_err()

Hi all, On Tue, 12 May 2020 at 12:49, Linus Walleij wrote: > > On Tue, Apr 28, 2020 at 4:13 PM Wei Yongjun wrote: > > > In case of error, the function of_drm_find_bridge() returns NULL pointer > > not ERR_PTR(). The IS_ERR() test in the return value check should be > > replaced with NULL test. >

Re: [PATCH v4 01/38] dma-mapping: add generic helpers for mapping sgtable objects

Hi Christoph, On 12.05.2020 14:18, Christoph Hellwig wrote: > On Tue, May 12, 2020 at 11:00:21AM +0200, Marek Szyprowski wrote: >> struct sg_table is a common structure used for describing a memory >> buffer. It consists of a scatterlist with memory pages and DMA addresses >> (sgl entry), as well

Re: [RFC 16/17] drm/amdgpu: gpu recovery does full modesets

On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote: > On Tue, May 12, 2020 at 5:00 AM Daniel Vetter wrote: > > > > ... > > > > I think it's time to stop this little exercise. > > > > The lockdep splat, for the record: > > > > [ 132.583381] ===

Re: [RFC 02/17] dma-fence: basic lockdep annotations

On Tue, May 12, 2020 at 09:09:52AM -0300, Jason Gunthorpe wrote: > On Tue, May 12, 2020 at 10:59:29AM +0200, Daniel Vetter wrote: > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > > index 6802125349fb..d5c0fd2efc70 100644 > > +++ b/drivers/dma-buf/dma-fence.c > > @@ -110,

Re: [RFC 16/17] drm/amdgpu: gpu recovery does full modesets

On Tue, May 12, 2020 at 5:00 AM Daniel Vetter wrote: > > ... > > I think it's time to stop this little exercise. > > The lockdep splat, for the record: > > [ 132.583381] == > [ 132.584091] WARNING: possible circular locking dependency detected

[PATCH][next] drm/amdgpu: remove redundant assignment to variable ret

From: Colin Ian King The variable ret is being initializeed with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King --- drivers/gpu/drm/amd/amdgpu/amdg

Re: [PATCH v5 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux

On Thu, May 7, 2020 at 11:35 PM Douglas Anderson wrote: > The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can > be used as GPIOs in a system. Each pin can be configured as input, > output, or a special function for the bridge chip. These are: > - GPIO1: SUSPEND Input > - GPIO

Re: [PATCH v4 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux

On Thu, May 7, 2020 at 4:39 PM Doug Anderson wrote: > One suggestion that came off-list is to change the code to make the > numbering match up better with the datasheet. Right now if you want > GPIO 2 you have to refer to it like: > > hpd-gpios = <&sn65dsi86_bridge 1 GPIO_ACTIVE_HIGH>; > > That'

Re: [PATCH -next v2] drm/mcde: dsi: Fix return value check in mcde_dsi_bind()

On Thu, Apr 30, 2020 at 9:30 AM Wei Yongjun wrote: > The of_drm_find_bridge() function returns NULL on error, it doesn't return > error pointers so this check doesn't work. > > Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE") > Signed-off-by: Wei Yongjun > --- > v1 - > v2: a

Re: [PATCH -next] drm/mcde: dsi: Fix return value check in dev_err()

On Tue, Apr 28, 2020 at 4:13 PM Wei Yongjun wrote: > In case of error, the function of_drm_find_bridge() returns NULL pointer > not ERR_PTR(). The IS_ERR() test in the return value check should be > replaced with NULL test. > > Signed-off-by: Wei Yongjun Patch applied! Thanks Wei, sorry for the

Re: [PATCH V4 2/3] drm/vkms: Compute CRC without change input data

Hi Rodrigo, On Mon, 11 May 2020 at 12:55, Rodrigo Siqueira wrote: > > From: Rodrigo Siqueira > > The compute_crc() function is responsible for calculating the > framebuffer CRC value; due to the XRGB format, this function has to > ignore the alpha channel during the CRC computation. Therefore, >

Re: [PATCH v2 15/15] drm/mgag200: Replace VRAM helpers with SHMEM helpers

On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote: > > The VRAM helpers managed the framebuffer memory for mgag200. This came > with several problems, as some MGA device require the scanout address > to be located at VRAM offset 0. It's incompatible with the page-flip > semantics of DRM's atom

Re: [PATCH v2 07/15] drm/mgag200: Set pitch in a separate helper function

Hi Thomas, On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote: > @@ -1143,20 +1178,15 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc, > WREG_CRT(13, 0); > WREG_CRT(14, 0); > WREG_CRT(15, 0); > - WREG_CRT(19, pitch & 0xFF); > - This write has disappeared wi

Re: [PATCH v2 13/15] drm/mgag200: Use simple-display data structures

Hi Thomas, On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote: > static void mga_crtc_init(struct mga_device *mdev) > { > struct drm_device *dev = mdev->dev; > - struct mga_crtc *mga_crtc; > - > - mga_crtc = kzalloc(sizeof(struct mga_crtc) + > -

Re: [PATCH v2 12/15] drm/mgag200: Remove out-commented suspend/resume helpers

Hi Thomas, On Tue, 12 May 2020 at 09:43, Thomas Zimmermann wrote: > > The suspend/resume helpers are unused. Also remove associated state > from struct mga_device. > Although DPMS in it's traditional sense is no longer a thing, would it make sense to keep this around for documentation purposes? I

Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM

Hi David! On 5/12/20 7:04 AM, David VANTYGHEM wrote: > Im happy now that after your work, Debian and GRUB install fine on my > iMac G3. But Xserver doesn't start, I've got an AMD Rage 128 Pro AGP 4x > (see joined screenshot). This is an unrelated problem as the reason why you don't have a working

Re: [RFC 02/17] dma-fence: basic lockdep annotations

Quoting Daniel Vetter (2020-05-12 10:08:47) > On Tue, May 12, 2020 at 10:04:22AM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2020-05-12 09:59:29) > > > Design is similar to the lockdep annotations for workers, but with > > > some twists: > > > > > > - We use a read-lock for the execution

[PATCH v4 14/38] drm: mediatek: use common helper for a scatterlist contiguity check

Use common helper for checking the contiguity of the imported dma-buf and do this check before allocating resources, so the error path is simpler. Signed-off-by: Marek Szyprowski --- For more information, see '[PATCH v4 00/38] DRM: fix struct sg_table nents vs. orig_nents misuse' thread: https://

[PATCH v4 19/38] drm: panfrost: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 08/38] drm: armada: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 33/38] staging: tegra-vde: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 37/38] media: pci: fix common ALSA DMA-mapping related codes

The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the numer of the created entries in the DMA address space. However the subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be called with the original number of entries passed to dma_map_sg. The sg_table->nents in

[PATCH v4 18/38] drm: omapdrm: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

Re: [RFC 02/17] dma-fence: basic lockdep annotations

On Tue, May 12, 2020 at 10:04:22AM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2020-05-12 09:59:29) > > Design is similar to the lockdep annotations for workers, but with > > some twists: > > > > - We use a read-lock for the execution/worker/completion side, so that > > this explicit ann

Re: [RFC 01/17] dma-fence: add might_sleep annotation to _wait()

Am 12.05.20 um 10:59 schrieb Daniel Vetter: But only for non-zero timeout, to avoid false positives. One question here is whether the might_sleep should be unconditional, or only for real timeouts. I'm not sure, so went with the more defensive option. But in the interest of locking down the cros

Re: [PATCH v3 02/25] drm: core: fix common struct sg_table related issues

Hi Christoph, On 08.05.2020 09:16, Christoph Hellwig wrote: > On Fri, May 08, 2020 at 09:12:13AM +0200, Marek Szyprowski wrote: >> Then we would just need one more helper to construct scatterlist, as the >> above two are read-only don't allow to modify scatterlist: >> >> #define for_each_sgtable_s

Re: [RFC 02/17] dma-fence: basic lockdep annotations

Quoting Daniel Vetter (2020-05-12 09:59:29) > Design is similar to the lockdep annotations for workers, but with > some twists: > > - We use a read-lock for the execution/worker/completion side, so that > this explicit annotation can be more liberally sprinkled around. > With read locks lockde

Re: [RFC 01/17] dma-fence: add might_sleep annotation to _wait()

Quoting Daniel Vetter (2020-05-12 09:59:28) > But only for non-zero timeout, to avoid false positives. > > One question here is whether the might_sleep should be unconditional, > or only for real timeouts. I'm not sure, so went with the more > defensive option. But in the interest of locking down

[PATCH v4 31/38] staging: ion: remove dead code

ion_heap_pages_zero() function is not used at all, so remove it to simplify the ion_heap_sglist_zero() function later. Signed-off-by: Marek Szyprowski --- For more information, see '[PATCH v4 00/38] DRM: fix struct sg_table nents vs. orig_nents misuse' thread: https://lore.kernel.org/dri-devel/20

[PATCH v4 34/38] misc: fastrpc: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 30/38] dmabuf: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 28/38] drm: host1x: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 36/38] samples: vfio-mdev/mbochs: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 23/38] drm: tegra: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 38/38] videobuf2: use sgtable-based scatterlist wrappers

Use recently introduced common wrappers operating directly on the struct sg_table objects and scatterlist page iterators to make the code a bit more compact, robust, easier to follow and copy/paste safe. No functional change, because the code already properly did all the scaterlist related calls.

[PATCH v4 35/38] rapidio: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 27/38] xen: gntdev: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 22/38] drm: rockchip: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 17/38] drm: omapdrm: use common helper for extracting pages array

Use common helper for converting a sg_table object into struct page pointer array. Signed-off-by: Marek Szyprowski --- For more information, see '[PATCH v4 00/38] DRM: fix struct sg_table nents vs. orig_nents misuse' thread: https://lore.kernel.org/dri-devel/20200512085710.14688-1-m.szyprow...@sa

[PATCH v4 20/38] drm: radeon: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 29/38] drm: rcar-du: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 25/38] drm: virtio: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 24/38] drm: v3d: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 02/38] scatterlist: add generic wrappers for iterating over sgtable objects

struct sg_table is a common structure used for describing a memory buffer. It consists of a scatterlist with memory pages and DMA addresses (sgl entry), as well as the number of scatterlist entries: CPU pages (orig_nents entry) and DMA mapped pages (nents entry). It turned out that it was a common

[PATCH v4 13/38] drm: lima: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

[PATCH v4 06/38] drm: core: fix common struct sg_table related issues

The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_

  1   2   >