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

https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #105 from Duncan (1i5t5.dun...@cox.net) --- (In reply to Duncan from comment #102) > (In reply to Duncan from comment #101) > > (In reply to Nicholas Kazlauskas from comment #95) > > > 0001-drm-amd-display-Force-add-all-CRTCs-to-state-

[Linux-kernel-mentees] [PATCH] drm/bufs: Prevent kernel-infoleak in copy_one_buf()

copy_one_buf() is copying uninitialized stack memory to userspace due to the compiler not initializing holes in statically allocated structures. Fix it by initializing `v` with memset(). Cc: sta...@vger.kernel.org Fixes: 5c7640ab6258 ("switch compat_drm_infobufs() to drm_ioctl_kernel()") Suggested

Re: [PATCH] drm/ttm/nouveau: consolidate slowpath reserve

Am 28.07.20 um 08:24 schrieb Dave Airlie: From: Dave Airlie The WARN_ON in the non-underscore path is off questionable value (can we drop it from the non-slowpath?). At least for nouveau where it's just looked up the gem object we know the ttm object has a reference always so we can skip the ch

Re: [PATCH] ttm: ttm_bo_swapout_all doesn't use it's argument.

Am 28.07.20 um 05:42 schrieb Dave Airlie: From: Dave Airlie Just drop the argument from this. This does ask the question if this is the function vmwgfx should be using or should it be doing an evict all like the other drivers. Signed-off-by: Dave Airlie Reviewed-by: Christian König ---

Re: [PATCH v5 2/5] drm/i915: Add support for async flips in I915

On 7/25/2020 4:56 AM, Paulo Zanoni wrote: Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu: Set the Async Address Update Enable bit in plane ctl when async flip is requested. v2: -Move the Async flip enablement to individual patch (Paulo) v3: -Rebased. v4: -Add separate plane hook fo

Re: [PATCH] drm/ttm: make ttm_tt unbind function return void.

Am 28.07.20 um 06:00 schrieb Dave Airlie: From: Dave Airlie The return value just led to BUG_ON, I think if a driver wants to BUG_ON here it can do it itself. (don't BUG_ON). Signed-off-by: Dave Airlie Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 5 ++--

[PATCH 11/13] drm/ast: Managed release of ast firmware

The ast driver loads firmware for the DP501 display encoder. The patch replaces the removal code with a managed release function. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/ast/ast_dp501.c | 23 ++- drivers/gpu/drm/ast/ast_drv.h | 1 - drivers/gpu/drm/ast/ast_mai

[PATCH 00/13] drm/ast: Convert to managed initialization

This is the final patchset for converting ast to managed initialization. Patches #1 to #4 address I2C helpers. The structures are being stored in struct ast_connector. The initialization and cleanups is being converted to managed release helpers. Patches #5 to #10 address modesetting and device s

[PATCH 01/13] drm/ast: Move I2C code within ast_mode.c

The I2C support feels slammed down to the end of ast_mode.c. Improve this by moving the code before it's callers, remove the declarations, rename the callbacks to match I2C's get/set sda/scl convention, and prefix all functions with ast_. No functional changes have been made. Signed-off-by: Thomas

[PATCH 04/13] drm/ast: Managed release of I2C adapter

Managed releases of the device's I2C adapter simplify the connector's release. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/ast/ast_mode.c | 21 ++--- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_

[PATCH 07/13] drm/ast: Replace driver load/unload functions with device create/destroy

The ast driver's load and unload functions are left-overs from when struct drm_driver.load/unload was still in use. The PCI probe helper allocated the DRM device and ran load to initialize it. This patch replaces this code with device create and destroy. The main difference is that the device's cr

[PATCH 05/13] drm/ast: Embed CRTC and connector in struct ast_private

Only single instances of CRTC and connector are supported per device. Embed both in ast's structure and remove the individual memory allocations. DRM's CRTC/connector cleanup helpers replace the rsp. destroy functions in ast. While at it, also convert to_ast_connector() to a function. Signed-off-

[PATCH 12/13] drm/ast: Manage release of firmware backup memory

The ast driver keeps a backup copy of the DP501 encoder's firmware. This patch adds managed release of the allocated memory. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/ast/ast_main.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_main

[PATCH 09/13] drm/ast: Don't use ast->dev if dev is available

Several places in ast use ast->dev, when a dev pointer is already available within the function. Remove the extra indirection. No functional changes made. This is just a small cleanup before embedding the DRM device instance in struct ast_private. Signed-off-by: Thomas Zimmermann --- drivers/gp

[PATCH 10/13] drm/ast: Embed struct drm_device in struct ast_private

Turns struct ast_private into a subclass of struct drm_device by embedding the latter. This allows for using DRM's managed device allocation. The use of struct drm_device.dev_private is deprecated. The patch converts the last remaining users to to_ast_private(). Signed-off-by: Thomas Zimmermann

[PATCH 08/13] drm/ast: Replace struct_drm_device.dev_private with to_ast_private()

The ast code still references dev_private in several place when looking up the ast device structure. Convert the remaining locations to use to_ast_private(). Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/ast/ast_cursor.c | 2 +- drivers/gpu/drm/ast/ast_mode.c | 2 +- 2 files changed, 2

[PATCH 02/13] drm/ast: Test if I2C support has been initialized

The ast driver is supposed to work without I2C support. This is tested by looking at the connector's i2c field being non-NULL. After embedding the I2C structure in the connector, the i2c field will not be a pointer. So change the test to look at the dev field in struct ast_i2c_chan. ast_get_modes

[PATCH 06/13] drm/ast: Separate DRM driver from PCI code

Putting the DRM driver to the top of the file and the PCI code to the bottom makes ast_drv.c more readable. While at it, the patch prefixes file-scope variables with ast_. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/ast/ast_drv.c | 59 ++- 1 file changed,

[PATCH 13/13] drm/ast: Managed device release

This turns the ast's device cleanup code into a managed release helper function. Note that the code uses devres helpers. The release function switches the device back to VGA mode and therefore runs during HW device cleanup; not at DRM device cleanup. Signed-off-by: Thomas Zimmermann --- drivers/

[PATCH 03/13] drm/ast: Embed I2C fields in struct ast_connector

With the I2C fields embedded in struct ast_connector, the related call to kzalloc() can be removed. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/ast/ast_drv.h | 3 +-- drivers/gpu/drm/ast/ast_mode.c | 33 ++--- 2 files changed, 11 insertions(+), 25 deletions

Re: [PATCH] drm/ttm/nouveau: don't call tt destroy callback on alloc failure.

Am 28.07.20 um 06:17 schrieb Dave Airlie: From: Dave Airlie This is confusing, and from my reading of all the drivers only nouveau got this right. Just make the API act under driver control of it's own allocation failing, and don't call destroy, if the page table fails to create there is nothi

Re: [PATCH] drm/ttm: drop unusued function declaration

Am 28.07.20 um 06:51 schrieb Dave Airlie: From: Dave Airlie This was removed in f5a9a9383f279de9da63296cb623a6418a66196b drm/ttm: remove TTM_MEMTYPE_FLAG_CMA but the the declaration was left dangling. Signed-off-by: Dave Airlie Reviewed-by: Christian König --- include/drm/ttm/ttm_bo_d

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

Hi Am 07.07.20 um 04:58 schrieb Tian Tao: > fixed the following warning: > hibmc_drm_drv.c:296:1-18:WARNING: Assignment of 0/1 to bool variable. > hibmc_drm_drv.c:301:2-19: WARNING: Assignment of 0/1 to bool variable. > > v2: > using the pci_dev.msi_enabled instead of priv->msi_enabled. > > Sign

Re: [PATCH] drm/ttm/nouveau: consolidate slowpath reserve

On Tue, 28 Jul 2020 at 17:30, Christian König wrote: > > Am 28.07.20 um 08:24 schrieb Dave Airlie: > > From: Dave Airlie > > > > The WARN_ON in the non-underscore path is off questionable value > > (can we drop it from the non-slowpath?). At least for nouveau > > where it's just looked up the gem

Re: [Linux-kernel-mentees] [PATCH] drm/bufs: Prevent kernel-infoleak in copy_one_buf()

On Tue, Jul 28, 2020 at 3:45 AM Peilin Ye wrote: > > copy_one_buf() is copying uninitialized stack memory to userspace due to > the compiler not initializing holes in statically allocated structures. > Fix it by initializing `v` with memset(). I would add 'potentially' somewhere in that descripti

Re: [Freedreno] [PATCH V2] drm: hold gem reference until object is no longer accessed

On Mon, Jul 27, 2020 at 05:54:59PM -0400, coh...@codeaurora.org wrote: > On 2020-07-27 16:11, dan...@ffwll.ch wrote: > > On Mon, Jul 27, 2020 at 09:55:07PM +0200, Greg KH wrote: > > > On Mon, Jul 20, 2020 at 06:30:50PM -0400, Steve Cohen wrote: > > > > A use-after-free in drm_gem_open_ioctl can hap

Re: [PATCH] drm/amd/display: Clear dm_state for fast updates

On Mon, Jul 27, 2020 at 10:49:48PM -0400, Kazlauskas, Nicholas wrote: > On 2020-07-27 5:32 p.m., Daniel Vetter wrote: > > On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk wrote: > > > > > > On Monday, July 27, 2020 4:29 PM, Daniel Vetter wrote: > > > > > > > On Mon, Jul 27, 2020 at 9:28 PM Christian

Re: [PATCH] ttm: ttm_bo_swapout_all doesn't use it's argument.

On Tue, Jul 28, 2020 at 01:42:54PM +1000, Dave Airlie wrote: > From: Dave Airlie > > Just drop the argument from this. > > This does ask the question if this is the function vmwgfx > should be using or should it be doing an evict all like > the other drivers. Yeah this looks a bit like ttm_bo_s

Re: [PATCH 11/13] drm/ast: Managed release of ast firmware

On Tue, Jul 28, 2020 at 09:44:23AM +0200, Thomas Zimmermann wrote: > The ast driver loads firmware for the DP501 display encoder. The > patch replaces the removal code with a managed release function. > > Signed-off-by: Thomas Zimmermann Hm a devm_request_firmware which does exactly this would b

Re: [PATCH 12/13] drm/ast: Manage release of firmware backup memory

On Tue, Jul 28, 2020 at 09:44:24AM +0200, Thomas Zimmermann wrote: > The ast driver keeps a backup copy of the DP501 encoder's firmware. This > patch adds managed release of the allocated memory. > > Signed-off-by: Thomas Zimmermann We can't really do anything with the firmware after the device

Re: ttm_tt_set_placement_caching on vram->ram transfers

Am 28.07.20 um 05:23 schrieb Dave Airlie: Hi Christian + Ben, Just been reviewing around driver TTM code, and found an inconsistency, amdgpu + radeon both call the above before binding the ttm and going gpu vram->ram copies, but I don't see nouveau doing it Not sure if it could cause any issues

Re: [PATCH 04/13] drm/ast: Managed release of I2C adapter

On Tue, Jul 28, 2020 at 09:44:16AM +0200, Thomas Zimmermann wrote: > Managed releases of the device's I2C adapter simplify the connector's > release. > > Signed-off-by: Thomas Zimmermann I think this breaks bisect, since at this point the release callback is called when the connector is already

Re: [PATCH 11/13] drm/ast: Managed release of ast firmware

Hi Am 28.07.20 um 11:17 schrieb dan...@ffwll.ch: > On Tue, Jul 28, 2020 at 09:44:23AM +0200, Thomas Zimmermann wrote: >> The ast driver loads firmware for the DP501 display encoder. The >> patch replaces the removal code with a managed release function. >> >> Signed-off-by: Thomas Zimmermann > >

Re: [Intel-gfx] [PATCH 0/6] vga-switcheroo: initial dynamic mux switch support

On Mon, Jul 27, 2020 at 03:51:06PM -0500, Daniel Dadap wrote: > Changes to allow vga-switcheroo to switch the mux while modesetting > clients remain active. There is existing support for switching the > mux without checking can_switch; however, this support also does not > reprobe after the mux swi

Re: [PATCH 04/13] drm/ast: Managed release of I2C adapter

Hi Am 28.07.20 um 11:23 schrieb dan...@ffwll.ch: > On Tue, Jul 28, 2020 at 09:44:16AM +0200, Thomas Zimmermann wrote: >> Managed releases of the device's I2C adapter simplify the connector's >> release. >> >> Signed-off-by: Thomas Zimmermann > > I think this breaks bisect, since at this point th

Re: [PATCH 11/13] drm/ast: Managed release of ast firmware

On Tue, Jul 28, 2020 at 11:32:04AM +0200, Thomas Zimmermann wrote: > Hi > > Am 28.07.20 um 11:17 schrieb dan...@ffwll.ch: > > On Tue, Jul 28, 2020 at 09:44:23AM +0200, Thomas Zimmermann wrote: > >> The ast driver loads firmware for the DP501 display encoder. The > >> patch replaces the removal cod

Re: [PATCH v4 10/78] drm/vc4: crtc: Rename HVS channel to output

Hi Maxime On Wed, 8 Jul 2020 at 18:42, Maxime Ripard wrote: > > In vc5, the HVS has 6 outputs and 3 FIFOs (or channels), with > pixelvalves each being assigned to a given output, but each output can > then be muxed to feed from multiple FIFOs. > > Since vc4 had that entirely static, both were pro

Re: linux-next: Fixes tag needs some work in the drm-fixes tree

On Mon, Jul 27, 2020 at 3:38 PM Stephen Rothwell wrote: > > Hi all, > > In commit > > 163d5446c37a ("drm/nouveau/disp/gm200-: fix regression from HDA SOR > selection changes") > > Fixes tag > > Fixes: 9b5ca547bb8 ("drm/nouveau/disp/gm200-: detect and potentially > disable HDA support on some

Re: [PATCH v4 11/78] drm/vc4: crtc: Use local chan variable

Hi Maxime On Wed, 8 Jul 2020 at 18:42, Maxime Ripard wrote: > > The vc4_crtc_handle_page_flip already has a local variable holding the > value of vc4_crtc->channel, so let's use it instead. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/drm/vc4/vc4_crtc.c |

Re: [PATCH v4 12/78] drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable

Hi Maxime On Wed, 8 Jul 2020 at 18:42, Maxime Ripard wrote: > > The VIDEN bit in the pixelvalve currently being used to enable or disable > the pixelvalve seems to not be enough in some situations, which whill end > up with the pixelvalve stalling. > > In such a case, even re-enabling VIDEN doesn

Re: [PATCH RFC v6 0/6] Add Unisoc's drm kms module

On Tue, Jul 28, 2020 at 12:08 PM Kevin Tang wrote: > > From: Kevin Tang Hm still no ack for dt bindings? We need that for merging. Also what's the maintainer plan here? Imo best would be to put this into the drm-misc group maintainer model, with commit rights and all: https://drm.pages.freedes

Re: [v7, PATCH 2/7] mtk-mmsys: add mmsys private data

Hi Yongqiang, Missatge de Yongqiang Niu del dia ds., 25 de jul. 2020 a les 5:29: > > On Thu, 2020-07-23 at 11:32 +0200, Enric Balletbo Serra wrote: > > Hi Yongqiang Niu, > > > > Thank you for your patch. > > > > Missatge de Yongqiang Niu del dia dj., 23 > > de jul. 2020 a les 4:05: > > > > > > a

Re: [PATCH v4 21/78] drm/vc4: crtc: Move PV dump to config_pv

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > Now that we only configure the PixelValve in vc4_crtc_config_pv, it doesn't > really make much sense to dump its register content in its caller. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/dr

Re: [PATCH v4 22/78] drm/vc4: crtc: Move HVS init and close to a function

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > In order to make further refactoring easier, let's move the HVS channel > setup / teardown to their own function. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/drm/vc4/vc4_hvs.c | 104 +

Re: [PATCH v4 24/78] drm/vc4: hvs: Make sure our channel is reset

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > In order to clear our intermediate FIFOs that might end up with a stale > pixel, let's make sure our FIFO channel is reset everytime our channel is > setup. Minor nit pick: s/everytime/every time > Signed-off-by: Maxime Ripard Re

Re: [PATCH v4 25/78] drm/vc4: crtc: Remove mode_set_nofb

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > On BCM2711 to avoid stale pixels getting stuck in intermediate FIFOs, the > pixelvalve needs to be setup each time there's a mode change or enable / > disable sequence. > > Therefore, we can't really use mode_set_nofb anymore to conf

Re: [PATCH v4 26/78] drm/vc4: crtc: Remove redundant pixelvalve reset

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > Since we moved the pixelvalve configuration to atomic_enable, we're now > first calling the function that resets the pixelvalve and then the one that > configures it. > > However, the first thing the latter is doing is calling the re

Re: [PATCH v4 27/78] drm/vc4: crtc: Move HVS channel init before the PV initialisation

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > In order to avoid stale pixels getting stuck in an intermediate FIFO > between the HVS and the pixelvalve on BCM2711, we need to configure the HVS > channel before the pixelvalve is reset and configured. > > Signed-off-by: Maxime Rip

[PULL] drm-misc-fixes

Hi Dave and Daniel, here's this week's PR for drm-misc-fixes. It's mostly driver stuff. There's one fix in the GEM ioctl code, but it has no impact on the UAPI. Best regards Thomas drm-misc-fixes-2020-07-28: * drm: fix possible use-after-free * dbi: fix SPI Type 1 transfer * drm_fb_helper: us

Re: [PATCH] drm/amd/display: Clear dm_state for fast updates

On Monday, July 27, 2020 5:32 PM, Daniel Vetter wrote: > On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk wrote: > > > > On Monday, July 27, 2020 4:29 PM, Daniel Vetter wrote: > > > > > On Mon, Jul 27, 2020 at 9:28 PM Christian König > > > wrote: > > > > > > > > Am 27.07.20 um 16:05 schrieb Kazlaus

Re: [PATCH] drm/amd/display: Clear dm_state for fast updates

On Monday, July 27, 2020 7:42 PM, Mazin Rezk wrote: > On Monday, July 27, 2020 5:32 PM, Daniel Vetter wrote: > > > On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk wrote: > > > > > > On Monday, July 27, 2020 4:29 PM, Daniel Vetter wrote: > > > > > > > On Mon, Jul 27, 2020 at 9:28 PM Christian König

Re: [PATCH v4 28/78] drm/vc4: encoder: Add finer-grained encoder callbacks

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > In the BCM2711, the setup of the HVS, pixelvalve and HDMI controller > requires very precise ordering and timing that the regular atomic callbacks > don't provide. Let's add new callbacks on top of the regular ones to be > able to sp

Re: [PATCH v4 30/78] drm/vc4: crtc: Clear the PixelValve FIFO on disable

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > In order to avoid a stale pixel getting stuck on mode change or a disable > / enable cycle, we need to make sure to flush the PV FIFO on disable. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/d

Re: [PATCH v4 31/78] drm/vc4: crtc: Clear the PixelValve FIFO during configuration

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > Even though it's not really clear why we need to flush the PV FIFO during > the configuration even though we started by flushing it, experience shows > that without it we get a stale pixel stuck in the FIFO between the HVS and > the

Re: [PATCH v4 40/78] drm/vc4: hdmi: rework connectors and encoders

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > the vc4_hdmi driver has some custom structures to hold the data it needs to > associate with the drm_encoder and drm_connector structures. > > However, it allocates them separately from the vc4_hdmi structure which > makes it more co

Re: [PATCH v4 47/78] drm/vc4: hdmi: Retrieve the vc4_hdmi at unbind using our device

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > The unbind function needs to retrieve a vc4_hdmi structure pointer through > the struct device that we're given since we want to support multiple HDMI > controllers. > > However, our optional ASoC support doesn't make that trivial si

Re: [PATCH v4 50/78] drm/vc4: hdmi: Introduce resource init and variant

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > The HDMI controllers found in the BCM2711 has a pretty different clock and > registers areas than found in the older BCM283x SoCs. > > Let's create a variant structure to store the various adjustments we'll > need later on, and a fun

Re: [PATCH v4 51/78] drm/vc4: hdmi: Implement a register layout abstraction

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > The HDMI controllers found in the BCM2711 have most of the registers > reorganized in multiple registers areas and at different offsets than > previously found. > > The logic however remains pretty much the same, so it doesn't really

Re: [PATCH v4 52/78] drm/vc4: hdmi: Add reset callback

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > The BCM2711 and BCM283x HDMI controllers use a slightly different reset > sequence, so let's add a callback to reset the controller. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/drm/vc4/vc4_hd

Re: [PATCH v4 53/78] drm/vc4: hdmi: Add PHY init and disable function

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > The HDMI PHY in the BCM2711 HDMI controller is significantly more > complicated to setup than in the older BCM283x SoCs. > > Let's add hooks to enable and disable the PHY. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenso

Re: [PATCH v4 54/78] drm/vc4: hdmi: Add PHY RNG enable / disable function

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > Let's continue the implementation of hooks for the parts that change in the > BCM2711 SoC with the PHY RNG setup. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/drm/vc4/vc4_hdmi.c | 15 +

Re: [PATCH v4 55/78] drm/vc4: hdmi: Add a CSC setup callback

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > Similarly to the previous patches, the CSC setup is slightly different in > the BCM2711 than in the previous generations. Let's add a callback for it. We've gained the set_timings callback in this patch as well as csc_setup. Was tha

Re: [PATCH v4 56/78] drm/vc4: hdmi: Store the encoder type in the variant structure

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > The vc4 CRTC will use the encoder type to control its output clock > muxing. However, this will be different from HDMI0 to HDMI1, so let's > store our type in the variant structure so that we can support multiple > controllers later

Re: [PATCH v4 57/78] drm/vc4: hdmi: Deal with multiple debugfs files

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > The HDMI driver was registering a single debugfs file so far with the name > hdmi_regs. > > Obviously, this is not going to work anymore when will have multiple HDMI > controllers since we will end up trying to register two files wit

Re: [PATCH v4 58/78] drm/vc4: hdmi: Move CEC init to its own function

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > The CEC init code was put directly into the bind function, which was quite > inconsistent with how the audio support was done, and would prevent us from > further changes to skip that initialisation entirely. > > Signed-off-by: Maxim

Re: [PATCH v4 59/78] drm/vc4: hdmi: Add CEC support flag

Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > Similarly to the audio support, CEC support is not there yet for the > BCM2711, so let's skip entirely the CEC initialization through a variant > flag. CEC is sorted now, but it's easier & cleaner to keep this patch and add a new pa

Re: [PATCH v4 60/78] drm/vc4: hdmi: Remove unused CEC_CLOCK_DIV define

Hi Maxime On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote: > > The CEC_CLOCK_DIV define is not used anywhere in the driver, let's remove > it. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/drm/vc4/vc4_hdmi.c | 1 - > 1 file changed, 1 deletion(-) > > diff

[PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv

GPU drivers need this in their shrinkers, to be able to throw out mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers, but that loop is resolved by trylocking in shrinkers. So full hierarchy is now (ignore some of the other branches we already have primed): mmap_read_lock -> dma_re

Re: [PATCH v4 61/78] drm/vc4: hdmi: Rename drm_encoder pointer in mode_valid

Hi Maxime On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote: > > The mode_valid hook on the encoder uses a pointer to a drm_encoder called > crtc, which is pretty confusing. Let's rename it to encoder to make it > clear what it is. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson >

Re: [PATCH v4 62/78] drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate

Hi Maxime On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote: > > The HSM clock needs to be setup at around 101% of the pixel rate. This > was done previously by setting the clock rate to 163.7MHz at probe time and > only check in mode_valid whether the mode pixel clock was under the pixel > clock

Re: [PATCH v4 63/78] drm/vc4: hdmi: Use clk_set_min_rate instead

Hi Maxime On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote: > > The HSM clock needs to be running at 101% the pixel clock of the HDMI > controller, however it's shared between the two HDMI controllers, which > means that if the resolutions are different between the two HDMI > controllers, and the

Re: [PATCH v4 68/78] drm/vc4: hdmi: Deal with multiple ALSA cards

Hi Maxime On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote: > > The HDMI driver was registering a single ALSA card so far with the name > vc4-hdmi. > > Obviously, this is not going to work anymore when will have multiple HDMI s/will/we > controllers since we will end up trying to register two f

Re: [PATCH v4 69/78] drm/vc4: hdmi: Remove register dumps in enable

Hi Maxime On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote: > > The current code has some logic, disabled by default, to dump the register > setup in the HDMI controller. > > However, since we're going to split those functions in multiple, shorter, > functions that only make sense where they are

Re: [PATCH v4 70/78] drm/vc4: hdmi: Always recenter the HDMI FIFO

Hi Maxime On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote: > > In order to avoid a pixel getting stuck in an unflushable FIFO, we need to > recenter the FIFO every time we're doing a modeset and not only if we're > connected to an HDMI monitor. > > Signed-off-by: Maxime Ripard Reviewed-by: Dav

Re: [PATCH v9 0/4] driver core: add probe error check helper

Hi Greg, Apparently the patchset has no more comments. Could you take the patches to your tree? At least 1st and 2nd. Regards Andrzej On 13.07.2020 16:43, Andrzej Hajda wrote: > Hi All, > > Thanks for comments. > > Changes since v8: > - fixed typo in function name, > - removed cocci script (

Re: [PATCH v4 71/78] drm/vc4: hdmi: Implement finer-grained hooks

Hi Maxime On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote: > > In order to prevent some pixels getting stuck in an unflushable FIFO on > bcm2711, we need to enable the HVS, the pixelvalve (the CRTC) and the HDMI > controller (the encoder) in an intertwined way, and with tight delays. > > However

Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset

On Fri, Jul 24, 2020 at 2:45 PM Jim Quinlan wrote: > > The new field 'dma_range_map' in struct device is used to facilitate the > use of single or multiple offsets between mapping regions of cpu addrs and > dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only > capable of holdi

Re: [PATCH v4 72/78] drm/vc4: hdmi: Do the VID_CTL configuration at once

Hi Maxime On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote: > > The VID_CTL setup is done in several places in the driver even though it's > not really required. Let's simplify it a bit to do the configuration in one > go. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- >

Re: [PATCH v4 73/78] drm/vc4: hdmi: Switch to blank pixels when disabled

Hi Maxime On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote: > > In order to avoid pixels getting stuck in an unflushable FIFO, we need when > we disable the HDMI controller to switch away from getting our pixels from > the pixelvalve and instead use blank pixels, and switch back to the > pixelval

Re: [PATCH v4 74/78] drm/vc4: hdmi: Support the BCM2711 HDMI controllers

Hi Maxime On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote: > > Now that the driver is ready for it, let's bring in the HDMI controllers > variants for the BCM2711. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/drm/vc4/vc4_hdmi.c | 278

Re: [PATCH v4 00/22] drm: mxsfb: Add i.MX7 support

On 2020-07-27 04:06, Laurent Pinchart wrote: > Hello, > > This patch series adds i.MX7 support to the mxsfb driver. The eLCDIF > instance found in the i.MX7 is backward-compatible with the already > supported LCDC v4, but has extended features amongst which the most > notable one is a second plane

Re: [PATCH v4 77/78] drm/vc4: drv: Support BCM2711

Hi Maxime On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote: > > The BCM2711 has a reworked display pipeline, and the load tracker needs > some adjustement to operate properly. Let's add a compatible for BCM2711 s/adjustement/adjustment > and disable the load tracker until properly supported. >

Re: [PATCH v4 78/78] ARM: dts: bcm2711: Enable the display pipeline

Hi Maxime On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote: > > Now that all the drivers have been adjusted for it, let's bring in the > necessary device tree changes. Possibly a comment to say that the VEC and PV3 are deliberately NOT enabled as the VEC requires further very specific clock setu

RE: [PATCH] nouveau: use ttm populate mapping functions. (v2)

>-Original Message- >From: dri-devel On Behalf Of >Dave Airlie >Sent: Monday, July 27, 2020 11:26 PM >To: dri-devel@lists.freedesktop.org >Cc: bske...@redhat.com >Subject: [PATCH] nouveau: use ttm populate mapping functions. (v2) > >From: Dave Airlie > >Instead of rolling driver copies of

Re: [PATCH] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush

On Sun, Jul 26, 2020 at 12:26:08PM +0200, Daniel Vetter wrote: > On Sat, Jul 25, 2020 at 9:29 PM Melissa Wen wrote: > > > > On Sat, Jul 25, 2020 at 4:19 PM Melissa Wen wrote: > > > > > > > No, this very first warning continues (only once) :( > > > > From here (drm_crtc_vblank_on): > > > >

Re: [PATCH 1/3] drm: Restore driver.preclose() for all to use

Quoting Daniel Vetter (2020-07-27 20:32:45) > On Thu, Jul 23, 2020 at 7:21 PM Chris Wilson wrote: > > > > An unfortunate sequence of events, but it turns out there is a valid > > usecase for being able to free/decouple the driver objects before they > > are freed by the DRM core. In particular, if

Re: [PATCH] amdgpu_dm: fix nonblocking atomic commit use-after-free

On 2020-07-28 5:22 a.m., Paul Menzel wrote: Dear Linux folks, Am 25.07.20 um 07:20 schrieb Mazin Rezk: On Saturday, July 25, 2020 12:59 AM, Duncan wrote: On Sat, 25 Jul 2020 03:03:52 + Mazin Rezk wrote: Am 24.07.20 um 19:33 schrieb Kees Cook: There was a fix to disable the async path

[PATCH 2/2] dma-buf: fence-chain: Document missing dma_fence_chain_init() parameter in kerneldoc

Fix W=1 compile warnings (invalid kerneldoc): drivers/dma-buf/dma-fence-chain.c:233: warning: Function parameter or member 'seqno' not described in 'dma_fence_chain_init' Signed-off-by: Krzysztof Kozlowski --- drivers/dma-buf/dma-fence-chain.c | 1 + 1 file changed, 1 insertion(+) diff --

[PATCH 1/2] dma-buf: Fix kerneldoc of dma_buf_set_name()

Fix W=1 compile warnings (invalid kerneldoc): drivers/dma-buf/dma-buf.c:328: warning: Function parameter or member 'dmabuf' not described in 'dma_buf_set_name' Signed-off-by: Krzysztof Kozlowski --- drivers/dma-buf/dma-buf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff

Re: [PATCH V2 3/3] drm/panel: simple: Add DT bindings for Powertip PH800480T013

On Tue, Jul 28, 2020 at 02:12:46PM +0200, Marek Vasut wrote: > Add support for Powertip PH800480T013 800x480 parallel LCD, this > one is used in the Raspberry Pi 7" touchscreen display unit. > > Signed-off-by: Marek Vasut > To: dri-devel@lists.freedesktop.org > Cc: Eric Anholt > Cc: Rob Herring

Re: [PATCH 02/13] drm/ast: Test if I2C support has been initialized

Hi Thomas. On Tue, Jul 28, 2020 at 09:44:14AM +0200, Thomas Zimmermann wrote: > The ast driver is supposed to work without I2C support. This is > tested by looking at the connector's i2c field being non-NULL. > > After embedding the I2C structure in the connector, the i2c field > will not be a po

Re: [PATCH 01/13] drm/ast: Move I2C code within ast_mode.c

Hi Thomas. A few comments related to the code - but not to this patch and not to this patch-set. But I noticed so here goes. Sam On Tue, Jul 28, 2020 at 09:44:13AM +0200, Thomas Zimmermann wrote: > The I2C support feels slammed down to the end of ast_mode.c. Improve > this by moving the

Re: [PATCH 04/13] drm/ast: Managed release of I2C adapter

On Tue, Jul 28, 2020 at 09:44:16AM +0200, Thomas Zimmermann wrote: > Managed releases of the device's I2C adapter simplify the connector's > release. > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/ast/ast_mode.c | 21 ++--- > 1 file changed, 10 insertions(+), 11 del

Re: [PATCH 00/13] drm/ast: Convert to managed initialization

Hi Thomas. On Tue, Jul 28, 2020 at 09:44:12AM +0200, Thomas Zimmermann wrote: > This is the final patchset for converting ast to managed initialization. > > Patches #1 to #4 address I2C helpers. The structures are being stored > in struct ast_connector. The initialization and cleanups is being co

[PATCH 1/1] drm/ttm: fix offset in VMAs with a pg_offs in ttm_bo_vm_access

VMAs with a pg_offs that's offset from the start of the vma_node need to adjust the offset within the BO accordingly. This matches the offset calculation in ttm_bo_vm_fault_reserved. Signed-off-by: Felix Kuehling Tested-by: Laurent Morichetti --- drivers/gpu/drm/ttm/ttm_bo_vm.c | 4 +++- 1 file

[PATCH] drm/ttm/amdgpu: consolidate ttm reserve paths

From: Dave Airlie Drop the WARN_ON and consolidate the two paths into one. Use the consolidate slowpath in the execbuf utils code. Signed-off-by: Dave Airlie --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +- drivers/gpu/drm/ttm/ttm_execbuf_util.c | 12 +-- include/drm/ttm/ttm_bo_dri

Re: [PATCH] dma-buf: heaps: Introduce dma_heap_add_cma() for non-default CMA heap

On Thu, Jul 16, 2020 at 6:10 PM Kunihiko Hayashi wrote: > > Current dma-buf heaps can handle only default CMA. This introduces > dma_heap_add_cma() function to attach CMA heaps that belongs to a device. > > At first, the driver calls of_reserved_mem_device_init() to set > memory-region property as

[PATCH 0/2] Small cleanups to ingenic-drm driver

Here are a few cleanups to the ingenic-drm driver. - some error paths were missing and have been added; - the mode validation has been moved to the .mode_valid helper callback. Cheers, -Paul Paul Cercueil (2): drm/ingenic: Handle errors of drm_atomic_get_plane_state drm/ingenic: Validate mode

Re: [PATCH RFC v6 2/6] drm/sprd: add Unisoc's drm kms master

On 7/28/20 3:07 AM, Kevin Tang wrote: > diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig > new file mode 100644 > index 000..b189a54 > --- /dev/null > +++ b/drivers/gpu/drm/sprd/Kconfig > @@ -0,0 +1,12 @@ > +config DRM_SPRD > + tristate "DRM Support for Unisoc SoCs P

[PATCH v2 0/5] make hdmi work on bananapi-r2

This Patch-Series adds missing Patches/Bugfixes to get hdmi working on BPI-R2 This is v2 of series https://patchwork.kernel.org/cover/10903309/ after getting mmsys done v1->v2: - using get_possible_crtc API instead of hardcoded - drop unused dts-nodes - refine commit-messages as far as i can :)

  1   2   >