Re: [PATCH v6 3/6] drm/mediatek: Detect CMDQ execution timeout

On Thu, Oct 28, 2021 at 6:19 PM jason-jh.lin wrote: > > From: Chun-Kuang Hu > > CMDQ is used to update display register in vblank period, so > it should be execute in next 2 vblank. One vblank interrupt > before send message (occasionally) and one vblank interrupt > after cmdq done. If it fail

[PATCH v8, 08/17] media: mtk-vcodec: Use pure single core for MT8183

Separates different architecture for hardware: pure_sin_core and lat_sin_core. MT8183 is pure single core. Uses .hw_arch to distinguish. Signed-off-by: Yunfei Dong Reviewed-By: AngeloGioacchino Del Regno --- .../platform/mtk-vcodec/mtk_vcodec_dec_stateful.c | 1 +

[PATCH v8, 16/17] media: mtk-vcodec: Add core dec and dec end ipi msg

Add core dec and dec end ipi msg: AP_IPIMSG_DEC_CORE/AP_IPIMSG_DEC_CORE_END. Signed-off-by: Yunfei Dong Reviewed-By: AngeloGioacchino Del Regno --- .../media/platform/mtk-vcodec/vdec_ipi_msg.h | 4 .../media/platform/mtk-vcodec/vdec_vpu_if.c| 12

[PATCH v8, 12/17] media: mtk-vcodec: Add new interface to lock different hardware

For add new hardware, not only need to lock lat hardware, also need to lock core hardware in case of different instance start to decoder at the same time. Signed-off-by: Yunfei Dong Reviewed-By: AngeloGioacchino Del Regno --- drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 4 ++--

[PATCH v8, 15/17] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8192

Adds decoder dt-bindings for mt8192. Signed-off-by: Yunfei Dong --- v8: fix yaml file check fail --- .../media/mediatek,vcodec-comp-decoder.yaml | 273 ++ 1 file changed, 273 insertions(+) create mode 100644

[PATCH v8, 17/17] media: mtk-vcodec: Use codec type to separate different hardware

There are just one core thread, in order to separeate different hardware, using codec type to separeate it in scp driver. Signed-off-by: Yunfei Dong Reviewed-By: AngeloGioacchino Del Regno --- .../media/platform/mtk-vcodec/vdec_ipi_msg.h | 12 ---

[PATCH v8, 05/17] media: mtk-vcodec: Support MT8192

From: Yunfei Dong Adds MT8192's compatible "mediatek,mt8192-vcodec-dec". Adds MT8192's device private data mtk_lat_sig_core_pdata. Signed-off-by: Yunfei Dong --- v8: add patch to support 8192 --- .../media/platform/mtk-vcodec/mtk_vcodec_dec.h | 1 +

[PATCH v8, 11/17] media: mtk-vcodec: Generalize power and clock on/off interfaces

Generalizes power and clock on/off interfaces to support different hardware. Signed-off-by: Yunfei Dong --- .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 6 +- .../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 2 +- .../platform/mtk-vcodec/mtk_vcodec_dec_hw.h | 4 +

[PATCH v8, 14/17] media: mtk-vcodec: Support 34bits dma address for vdec

Use the dma_set_mask_and_coherent helper to set vdec DMA bit mask to support 34bits iova space(16GB) that the mt8192 iommu HW support. Whole the iova range separate to 0~4G/4G~8G/8G~12G/12G~16G, regarding which iova range VDEC actually locate, it depends on the dma-ranges property of vdec dtsi

[PATCH v8, 13/17] media: mtk-vcodec: Add work queue for core hardware decode

Add work queue to process core hardware information. First, get lat_buf from message queue, then call core hardware of each codec(H264/VP9/AV1) to decode, finally puts lat_buf back to the message. Signed-off-by: Yunfei Dong --- v8: using work queue for hardware decode instead of create thread.

[PATCH v8, 04/17] media: mtk-vcodec: Build decoder pm file as module

Need to build decoder pm file as module for master and comp use the same pm interface. Signed-off-by: Yunfei Dong --- v8: add new patch to build pm file as module --- drivers/media/platform/mtk-vcodec/Makefile| 6 -- drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 9

[PATCH v8, 10/17] media: mtk-vcodec: Add msg queue feature for lat and core architecture

For lat and core architecture, lat thread will send message to core thread when lat decode done. Core hardware will use the message from lat to decode, then free message to lat thread when decode done. Signed-off-by: Yunfei Dong --- v8: change some logic for using work queue instead of create

[PATCH v8, 06/17] media: mtk-vcodec: Manage multi hardware information

Manage each hardware information which includes irq/power/clk. The hardware includes LAT0, LAT1 and CORE. Signed-off-by: Yunfei Dong --- v8: fix many comments --- drivers/media/platform/mtk-vcodec/Makefile| 5 +- .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 119 +

[PATCH v8, 03/17] media: mtk-vcodec: Refactor vcodec pm interface

Using the needed param for pm init/release function and remove unused param mtkdev in 'struct mtk_vcodec_pm'. Reviewed-by: Tzung-Bi Shih Reviewed-By: AngeloGioacchino Del Regno Signed-off-by: Yunfei Dong --- .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 6 ++---

[PATCH v8, 07/17] dt-bindings: media: mtk-vcodec: Separate video encoder and decoder dt-bindings

Decoder will use component framework to manage hardware, it is big difference with encoder. Reviewed-by: Rob Herring Signed-off-by: Yunfei Dong --- .../media/mediatek,vcodec-decoder.yaml| 176 + .../media/mediatek,vcodec-encoder.yaml| 187 ++

[PATCH v8, 09/17] media: mtk-vcodec: Add irq interface for multi hardware

Adds irq interface for multi hardware. Signed-off-by: Yunfei Dong --- .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 33 +-- .../platform/mtk-vcodec/mtk_vcodec_dec_hw.c | 2 +- .../platform/mtk-vcodec/mtk_vcodec_drv.h | 25 ++

[PATCH v8, 01/17] media: mtk-vcodec: Get numbers of register bases from DT

Different platform may has different numbers of register bases. Gets the numbers of register bases from DT (sizeof(u32) * 4 bytes for each). Reviewed-by: Tzung-Bi Shih Signed-off-by: Yunfei Dong --- .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 37 ++- 1 file changed, 28

[PATCH v8, 02/17] media: mtk-vcodec: Align vcodec wake up interrupt interface

Vdec and venc can use the same function to wake up interrupt event. Reviewed-by: Tzung-Bi Shih Reviewed-By: AngeloGioacchino Del Regno Signed-off-by: Yunfei Dong --- drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 9 + drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |

[PATCH v8, 00/17] Support multi hardware decode using of_platform_populate

This series adds support for multi hardware decode into mtk-vcodec, by first adding use of_platform_populate to manage each hardware information: interrupt, clock, register bases and power. Secondly add core work queue to deal with core hardware message, at the same time, add msg queue for

Re: [PATCH v7, 03/15] media: mtk-vcodec: Refactor vcodec pm interface

Hi Dafna, Thanks for your suggestion. On Thu, 2021-10-14 at 15:44 +0200, Dafna Hirschfeld wrote: > > On 11.10.21 09:02, Yunfei Dong wrote: > > Using the needed param for pm init/release function and remove > > unused > > param mtkdev in 'struct mtk_vcodec_pm'. > > > > I see that there is a

[PATCH v3 05/10] drm/i915: Prepare for multiple gts

From: Tvrtko Ursulin Add some basic plumbing to support more than one dynamically allocated struct intel_gt. Up to four gts are supported in i915->gts[], with slot zero shadowing the existing i915->gt to enable source compatibility with legacy driver paths. A for_each_gt macro is added to

[PATCH v3 08/10] drm/i915/xehp: Make IRQ reset and postinstall multi-tile aware

From: Paulo Zanoni Loop through all the tiles when initializing and resetting interrupts. v2: - Access tile0 registers through dev_priv->uncore rather than dev_priv->gt.uncore for clarity. Signed-off-by: Paulo Zanoni Signed-off-by: Tvrtko Ursulin Signed-off-by: Matt Roper Reviewed-by:

[PATCH v3 10/10] drm/i915/xehpsdv: Initialize multi-tiles

From: Tvrtko Ursulin Check how many extra GT tiles are available on the system and setup register access for all of them. We can detect how may GT tiles are available by reading a register on the root tile. The same register returns the tile ID on all tiles. v2: - Include some additional

[PATCH v3 06/10] drm/i915: Initial support for per-tile uncore

From: Daniele Ceraolo Spurio Initialization and suspend/resume is replicated per-tile. Signed-off-by: Daniele Ceraolo Spurio Signed-off-by: Tvrtko Ursulin Signed-off-by: Matt Roper Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/gt/intel_gt.c | 1 + drivers/gpu/drm/i915/i915_debugfs.c |

[PATCH v3 04/10] drm/i915: Store backpointer to GT in uncore

From: Michał Winiarski We now support a per-gt uncore, yet we're not able to infer which GT we're operating upon. Let's store a backpointer for now. Signed-off-by: Michał Winiarski Signed-off-by: Matt Roper Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-

[PATCH v3 07/10] drm/i915/xehp: Determine which tile raised an interrupt

From: Paulo Zanoni The first step of interrupt handling is to read a tile0 register that tells us in which tile the interrupt happened; we can then read the usual interrupt registers from the appropriate tile. Note that this is just the first step of handling interrupts properly on multi-tile

[PATCH v3 09/10] drm/i915/guc: Update CT debug macro for multi-tile

From: Michal Wajdeczko Update CT debug macros by including tile ID in all messages. Cc: Michał Winiarski Signed-off-by: Michal Wajdeczko Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH v3 02/10] drm/i915: split general MMIO setup from per-GT uncore init

From: Daniele Ceraolo Spurio In coming patches we'll be doing the actual tile initialization between these two uncore init phases. Signed-off-by: Daniele Ceraolo Spurio Signed-off-by: Matt Roper Reviewed-by: Lucas De Marchi Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/i915_drv.c |

[PATCH v3 03/10] drm/i915: Restructure probe to handle multi-tile platforms

On a multi-tile platform, each tile has its own registers + GGTT space, and BAR 0 is extended to cover all of them. Upcoming patches will start exposing the tiles as multiple GTs within a single PCI device. In preparation for supporting such setups, restructure the driver's probe code a bit.

[PATCH v3 00/10] i915: Initial multi-tile support

Some of our upcoming platforms, including the Xe_HP SDV, support a "multi-tile" design. A multi-tile platform is effectively a platform with multiple GT instances and local memory regions, all behind a single PCI device. From an i915 perspective, this translates to multiple intel_gt structures

[PATCH v3 01/10] drm/i915: rework some irq functions to take intel_gt as argument

From: Paulo Zanoni We'll be adding multi-tile support soon; on multi-tile platforms interrupts are per-tile and every tile has the full set of interrupt registers. In this commit we start passing intel_gt instead of dev_priv for the functions that are related to Xe_HP irq handling. Right now

Re: [PATCH v7, 11/15] media: mtk-vcodec: Add core thread

Hi Ezequiel, 1. Thanks for your suggestion. On Thu, 2021-10-14 at 09:29 -0300, Ezequiel Garcia wrote: > Hi Yunfei, > > On Mon, Oct 11, 2021 at 03:02:43PM +0800, Yunfei Dong wrote: > > Core thread: > > 1. Gets lat_buf from core msg queue. > > 2. Proceeds core decode. > > 3. Puts the lat_buf

Re: [PATCH v6, 00/15] Using component framework to support multi hardware decode

Hi Ezequiel, Thanks for your suggestion. On Thu, 2021-10-14 at 09:38 -0300, Ezequiel Garcia wrote: > Hi Yunfei, > > On Tue, 12 Oct 2021 at 22:17, yunfei.d...@mediatek.com > wrote: > > Hi Ezequiel, > > > > Thanks for your feedback, > > > > The driver can work well now according to your advice

Re: [PATCH v7, 04/15] media: mtk-vcodec: Manage multi hardware information

Hi AngeloGioacchino, Thanks for your suggestion. On Thu, 2021-10-14 at 11:20 +0200, AngeloGioacchino Del Regno wrote: > > Manage each hardware information which includes irq/power/clk. > > The hardware includes LAT0, LAT1 and CORE. > > > > Signed-off-by: Yunfei Dong > > --- > > v7: Using

Re: [Intel-gfx] [PATCH v3 1/3] drm: Rename lut check functions to lut channel checks

On Thu, Oct 28, 2021 at 8:42 PM Sean Paul wrote: > > On Tue, Oct 26, 2021 at 03:21:00PM -0400, Mark Yacoub wrote: > > From: Mark Yacoub > > > > [Why] > > This function and enum do not do generic checking on the luts but they > > test color channels in the LUTs. > > I'm not sure there's anything

Re: [PATCH v2] dma-buf: acquire name lock before read/write dma_buf.name

From: Guangming Cao On Fri, 2021-10-08 at 12:24 +0200, Christian König wrote: > Am 08.10.21 um 09:54 schrieb guangming@mediatek.com: > > From: Guangming Cao > > > > Because dma-buf.name can be freed in func: "dma_buf_set_name", > > so, we need to acquire lock first before we read/write

Re: [PATCH RESEND v2 1/2] dt-bindings: panel-simple-dsi: add Tianma TL057FVXP01

On Thu, 21 Oct 2021 17:34:44 -0400, Julian Braha wrote: > Adds the bindings for the Tianma TL057FVXP01 DSI panel, > found on the Motorola Moto G6. > > v2: > Fixed accidental whitespace deletion. > > Signed-off-by: Julian Braha > --- > .../devicetree/bindings/display/panel/panel-simple-dsi.yaml

Re: [PATCH] dt-bindings: display: tilcd: Fix endpoint adressing in example

On Thu, 21 Oct 2021 15:19:49 +0200, Geert Uytterhoeven wrote: > Remove the bogus unit addresses from the endpoints in the example. > > Signed-off-by: Geert Uytterhoeven > --- > Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2

Re: [Intel-gfx] [PATCH v3 2/3] drm: Add Gamma and Degamma LUT sizes props to drm_crtc to validate.

On Tue, Oct 26, 2021 at 03:21:01PM -0400, Mark Yacoub wrote: > From: Mark Yacoub > > [Why] > 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma > or Degamma props in the new CRTC state, allowing any invalid size to > be passed on. > 2. Each driver has its own LUT size,

Re: [PATCH 3/3] [RFC] dt-bindings: display: bridge: nxp,tda998x: Convert to json-schema

On Thu, Oct 21, 2021 at 03:18:53PM +0200, Geert Uytterhoeven wrote: > Convert the NXP TDA998x HDMI transmitter Device Tree binding > documentation to json-schema. > > Add missing "#sound-dai-cells" property. > Add ports hierarchy, as an alternative to port. > Drop pinctrl properties, as they do

Re: [PATCH] [RFC] dt-bindings: display: bridge: sil, sii9022: Convert to json-schema

On Thu, Oct 21, 2021 at 02:01:22PM +0200, Geert Uytterhoeven wrote: > Convert the Silicon Image sii902x HDMI bridge Device Tree binding > documentation to json-schema. > > Add missing sil,sii9022-cpi and sil,sii9022-tpi compatible values. > > Signed-off-by: Geert Uytterhoeven > --- > RFC as I

linux-next: manual merge of the drm tree with Linus' tree

Hi all, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/i915/i915_trace.h between commit: 9a4aa3a2f160 ("drm/i915: Revert 'guc_id' from i915_request tracepoint") from Linus' tree and commit: 3cb3e3434b9f ("drm/i915/guc: Move fields protected by

Re: [Intel-gfx] [PATCH v3 1/3] drm: Rename lut check functions to lut channel checks

On Tue, Oct 26, 2021 at 03:21:00PM -0400, Mark Yacoub wrote: > From: Mark Yacoub > > [Why] > This function and enum do not do generic checking on the luts but they > test color channels in the LUTs. I'm not sure there's anything inherently specific to channels, it seems like one could add a new

Re: [PATCH] MAINTAINERS: add reviewers for virtio-gpu

On Thu, 28 Oct 2021 at 22:35, Chia-I Wu wrote: > Add Gurchetan Singh and me as reviewers for virtio-gpu. Acked-by: Daniel Stone

Re: [Intel-gfx] [PATCH 08/11] drm/i915/xehp: Make IRQ reset and postinstall multi-tile aware

Hi Matt, > > > - dg1_master_intr_enable(uncore->regs); > > > - intel_uncore_posting_read(uncore, DG1_MSTR_TILE_INTR); > > > + dg1_master_intr_enable(dev_priv->gt.uncore->regs); > > > + intel_uncore_posting_read(dev_priv->gt.uncore, DG1_MSTR_TILE_INTR); > > > > I guess this should also go under a

Re: [PATCH] drm/i915/resets: Don't set / test for per-engine reset bits with GuC submission

On 10/28/2021 15:42, Matthew Brost wrote: Don't set, test for, or clear per-engine reset bits with GuC submission as the GuC owns the per engine resets not the i915. Setting, testing for, and clearing these bits is causing issues with the hangcheck selftest. Rather than change to test to not use

Re: [PATCH] drm: Add R10 and R12 FourCC

Hi Simon, On Thu, Oct 28, 2021 at 09:49:18PM +, Simon Ser wrote: > > +/* 10 bpp Red */ > > +#define DRM_FORMAT_R10 fourcc_code('R', '1', '0', ' ') /* > > [15:0] x:R 6:10 little endian */ > > + > > +/* 12 bpp Red */ > > +#define DRM_FORMAT_R12 fourcc_code('R', '1',

Re: [Intel-gfx] [PATCH 08/11] drm/i915/xehp: Make IRQ reset and postinstall multi-tile aware

On Thu, Oct 28, 2021 at 06:30:09PM +0200, Andi Shyti wrote: > Hi Paulo and Matt, > > [...] > > > @@ -3190,14 +3190,19 @@ static void dg1_irq_reset(struct drm_i915_private > > *dev_priv) > > mmmhhh... bad naming :/ Even though dg1 wasn't a multi-tile platform, it was the platform that

Re: [PATCH v3 2/3] drm/i915: Update error capture code to avoid using the current vma state

On Thu, Oct 28, 2021 at 02:01:27PM +0200, Thomas Hellström wrote: > With asynchronous migrations, the vma state may be several migrations > ahead of the state that matches the request we're capturing. > Address that by introducing an i915_vma_snapshot structure that > can be used to snapshot

[PATCH] drm/i915/resets: Don't set / test for per-engine reset bits with GuC submission

Don't set, test for, or clear per-engine reset bits with GuC submission as the GuC owns the per engine resets not the i915. Setting, testing for, and clearing these bits is causing issues with the hangcheck selftest. Rather than change to test to not use these bits, rip the use of these bits out

Re: [v1] drm/msm/disp/dpu1: set default group ID for CTL.

Quoting Kalyan Thota (2021-10-28 07:05:01) > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h > index 4ade44b..57b9be1 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h

[PATCH] drm/sun4i: fix unmet dependency on RESET_CONTROLLER for PHY_SUN6I_MIPI_DPHY

When PHY_SUN6I_MIPI_DPHY is selected, and RESET_CONTROLLER is not selected, Kbuild gives the following warning: WARNING: unmet direct dependencies detected for PHY_SUN6I_MIPI_DPHY Depends on [n]: (ARCH_SUNXI [=n] || COMPILE_TEST [=y]) && HAS_IOMEM [=y] && COMMON_CLK [=y] && RESET_CONTROLLER

Re: [PATCH] drm: Add R10 and R12 FourCC

On Thursday, October 28th, 2021 at 23:49, Simon Ser wrote: > Are these codes arbitrary, or are they taken from somewhere else? > If they are arbitrary, maybe it'd be better to pick XR10 and XR12 instead of > R10 and R12, to allow a future patch to add other format codes with the > padding > at

Re: [PATCH] drm: Add R10 and R12 FourCC

> +/* 10 bpp Red */ > +#define DRM_FORMAT_R10 fourcc_code('R', '1', '0', ' ') /* > [15:0] x:R 6:10 little endian */ > + > +/* 12 bpp Red */ > +#define DRM_FORMAT_R12 fourcc_code('R', '1', '2', ' ') /* > [15:0] x:R 4:12 little endian */ Are these codes arbitrary, or

Re: [PATCH v2 5/8] drm: drm_atomic_helper: Add a new helper to deal with the writeback connector validation

Hi, On 10/26/21 08:34, Igor Torrente wrote: > Add a helper function to validate the connector configuration receive in > the encoder atomic_check by the drivers. > > So the drivers don't need do these common validations themselves. > > Signed-off-by: Igor Torrente > --- > V2: Move the format

[PATCH] MAINTAINERS: add reviewers for virtio-gpu

Add Gurchetan Singh and me as reviewers for virtio-gpu. Signed-off-by: Chia-I Wu Acked-by: Gurchetan Singh Cc: David Airlie Cc: Gerd Hoffmann --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 3b79fd441dde..5474a0a708a8 100644 ---

Re: [PATCH v4 3/5] drm/dp: Disable unsupported features in DP_EDP_BACKLIGHT_MODE_SET_REGISTER

On Thu, 2021-10-28 at 11:27 -0700, Doug Anderson wrote: > Hi, > > On Tue, Oct 26, 2021 at 3:09 PM Lyude Paul wrote: > > > > As it turns out, apparently some machines will actually leave additional > > backlight functionality like dynamic backlight control on before the OS > > loads. Currently

Re: drm/virtio: not pin pages on demand

On Wed, Oct 27, 2021 at 4:12 AM Gerd Hoffmann wrote: > > [ Cc'ing Gurchetan Singh ] > > > Can we follow up on this issue? > > > > The main pain point with your suggestion is the fact, > > that it will cause VirGL protocol breakage and we would > > like to avoid this. > > > > Extending execbuffer

Re: mmotm 2021-10-27-18-32 uploaded (drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c)

On 10/27/21 6:33 PM, a...@linux-foundation.org wrote: The mm-of-the-moment snapshot 2021-10-27-18-32 has been uploaded to https://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: https://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue.

Re: [PATCH v5 2/2] drm/bridge: parade-ps8640: Populate devices on aux-bus

Hi, On Thu, Oct 28, 2021 at 10:58 AM Philip Chen wrote: > > Conventionally, panel is listed under the root of the device tree. > When userland asks for display mode, ps8640 bridge is responsible > for returning EDID when ps8640_bridge_get_edid() is called. > > Now enable a new option of listing

Re: [PATCH v2] drm/ttm: Do not put non-struct page memory into PUD/PMDs

On Thu, Oct 28, 2021 at 05:14:52PM +0200, Daniel Vetter wrote: > Hm totally lost this, I'm trying to not be too responsible for mm changes > since it scares me :-) Plus dropping this very late in the release feels a > bit risky. > > Ok if I stuff this into drm-next instead? Sure Jason

Re: [PATCH v5 1/2] drm/bridge: parade-ps8640: Enable runtime power management

Hi, On Thu, Oct 28, 2021 at 11:02 AM Philip Chen wrote: > > Add "Sam Ravnborg " to cc list for vis. > Remove "Andrzej Hajda " from cc list as the > address can't be found. Looking at , it should be Andrzej Hajda .

Re: [git pull] drm fixes for 5.15 final

The pull request you sent on Fri, 29 Oct 2021 05:14:19 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-10-29 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/f31531e55495ca3746fb895ffdf73586be8259fa Thank you! -- Deet-doot-dot, I am a bot.

[git pull] drm fixes for 5.15 final

Hi Linus, Quiet but not too quiet, I blame Halloween. The first set of amdgpu fixes missed last week, hence why this has a few more of them, it's mostly display fixes for new GPUs and some debugfs OOB stuff. The i915 patches have one to remove a tracepoint possible issue before it's a real

Re: [PATCH v1] drm: import DMA_BUF module namespace

Hi Am 27.10.21 um 22:54 schrieb Marcel Ziswiler: Sali Thomas On Wed, 2021-10-27 at 20:30 +0200, Thomas Zimmermann wrote: Hi, thanks for the patch. You are very welcome. Am 27.10.21 um 17:25 schrieb Marcel Ziswiler: From: Marcel Ziswiler Today's -next fails building arm64 defconfig as

Re: [PATCH v4 3/5] drm/dp: Disable unsupported features in DP_EDP_BACKLIGHT_MODE_SET_REGISTER

Hi, On Tue, Oct 26, 2021 at 3:09 PM Lyude Paul wrote: > > As it turns out, apparently some machines will actually leave additional > backlight functionality like dynamic backlight control on before the OS > loads. Currently we don't take care to disable unsupported features when > writing back

[Bug 214859] New: drm-amdgpu-init-iommu~fd-device-init.patch introduce bug

https://bugzilla.kernel.org/show_bug.cgi?id=214859 Bug ID: 214859 Summary: drm-amdgpu-init-iommu~fd-device-init.patch introduce bug Product: Drivers Version: 2.5 Kernel Version: 5.14.15 Hardware: x86-64

Re: [PATCH v5 1/2] drm/bridge: parade-ps8640: Enable runtime power management

Add "Sam Ravnborg " to cc list for vis. Remove "Andrzej Hajda " from cc list as the address can't be found. On Thu, Oct 28, 2021 at 10:58 AM Philip Chen wrote: > > Fit ps8640 driver into runtime power management framework: > > First, break _poweron() to 3 parts: (1) turn on power and wait for >

[PATCH v5 2/2] drm/bridge: parade-ps8640: Populate devices on aux-bus

Conventionally, panel is listed under the root of the device tree. When userland asks for display mode, ps8640 bridge is responsible for returning EDID when ps8640_bridge_get_edid() is called. Now enable a new option of listing panel under "aux-bus" of ps8640 bridge node in the device tree. In

[PATCH v5 1/2] drm/bridge: parade-ps8640: Enable runtime power management

Fit ps8640 driver into runtime power management framework: First, break _poweron() to 3 parts: (1) turn on power and wait for ps8640's internal MCU to finish init (2) check panel HPD (which is proxied by GPIO9) (3) the other configs. As runtime_resume() can be called before panel is powered, we

Re: [PATCH] MAINTAINERS: dri-devel is for all of drivers/gpu

On Thu, Oct 28, 2021 at 1:09 PM Daniel Vetter wrote: > > Somehow we only have a list of subdirectories, which apparently made > it harder for folks to find the gpu maintainers. Fix that. > > References: > https://lore.kernel.org/dri-devel/YXrAAZlxxStNFG%2FK@phenom.ffwll.local/ > Signed-off-by:

Re: [PATCH][next] nouveau/svm: Use kvcalloc() instead of kvzalloc()

On Thu, Oct 21, 2021 at 10:03:19AM -0700, Kees Cook wrote: > On Wed, Sep 29, 2021 at 05:28:47AM +0200, Karol Herbst wrote: > > Lack of documentation inside Linux here is a bit annoying, but do I > > understand it correctly, that the main (and probably only) difference > > is that kvcalloc checks

Re: Lockdep spalt on killing a processes

On 2021-10-27 3:58 p.m., Andrey Grodzovsky wrote: On 2021-10-27 10:50 a.m., Christian König wrote: Am 27.10.21 um 16:47 schrieb Andrey Grodzovsky: On 2021-10-27 10:34 a.m., Christian König wrote: Am 27.10.21 um 16:27 schrieb Andrey Grodzovsky: [SNIP] Let me please know if I am still

Re: [PATCH] drm/bridge: sn65dsi86: ti_sn65dsi86_read_u16() __maybe_unused

Hey Bjorn, Thanks for fixing this quickly. On Thu, 28 Oct 2021 at 18:33, Bjorn Andersson wrote: > > When built without CONFIG_PWM there are no references to > ti_sn65dsi86_read_u16(), avoid the W=1 build warning by marking the > function as __maybe_unused. > > __maybe_unused is used insted of a

[PATCH] MAINTAINERS: dri-devel is for all of drivers/gpu

Somehow we only have a list of subdirectories, which apparently made it harder for folks to find the gpu maintainers. Fix that. References: https://lore.kernel.org/dri-devel/YXrAAZlxxStNFG%2FK@phenom.ffwll.local/ Signed-off-by: Daniel Vetter Cc: David Airlie Cc: Daniel Vetter Cc: Steven

Re: [PATCH v4 6/6] i915/display/dp: send a more fine-grained link-status uevent

On Mon, Oct 18, 2021 at 08:47:31AM +, Simon Ser wrote: > When link-status changes, send a hotplug uevent which contains the > connector ID. That way, user-space can more easily figure out that > only this connector has been updated. > > Changes in v4: avoid sending two uevents (Ville) > >

[PATCH] drm/bridge: sn65dsi86: ti_sn65dsi86_read_u16() __maybe_unused

When built without CONFIG_PWM there are no references to ti_sn65dsi86_read_u16(), avoid the W=1 build warning by marking the function as __maybe_unused. __maybe_unused is used insted of a #ifdef guard as it looks slighly cleaner and it avoids issues if in the future other permutations of the

Re: [Nouveau] [PATCH v4 2/5] drm/nouveau/kms/nv50-: Explicitly check DPCD backlights for aux enable/brightness

On Wed, Oct 27, 2021 at 12:09 AM Lyude Paul wrote: > > Since we don't support hybrid AUX/PWM backlights in nouveau right now, > let's add some explicit checks so that we don't break nouveau once we > enable support for these backlights in other drivers. > > Signed-off-by: Lyude Paul > --- >

Re: [Intel-gfx] [PATCH] drm/i195: Remove some dead struct fwd decl from i915_drv.h

On Fri, Oct 22, 2021 at 09:39:13AM +0100, Matthew Auld wrote: > On Fri, 22 Oct 2021 at 09:22, Daniel Vetter wrote: > > > > Gone with userptr rewrite by Maarten in ed29c2691188 ("drm/i915: Fix > > userptr so we do not have to worry about obj->mm.lock, v7.") > > > > Signed-off-by: Daniel Vetter >

Re: [PATCH] mm/migrate.c: Remove MIGRATE_PFN_LOCKED

Am 2021-10-27 um 9:42 p.m. schrieb Alistair Popple: > On Wednesday, 27 October 2021 3:09:57 AM AEDT Felix Kuehling wrote: >> Am 2021-10-25 um 12:16 a.m. schrieb Alistair Popple: >>> MIGRATE_PFN_LOCKED is used to indicate to migrate_vma_prepare() that a >>> source page was already locked during

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dmabuf: drop the flush on discrete

On Thu, Oct 21, 2021 at 01:53:32PM +0100, Matthew Auld wrote: > We were overzealous here; even though discrete is non-LLC, it should > still be always coherent. > > Signed-off-by: Matthew Auld > Cc: Thomas Hellström > --- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 3 ++- > 1 file changed,

Re: [Intel-gfx] [PATCH 02/28] drm/i915: use new iterator in i915_gem_object_wait_reservation

On Thu, Oct 28, 2021 at 10:41:38AM +0200, Christian König wrote: > Am 21.10.21 um 13:13 schrieb Tvrtko Ursulin: > > > > On 21/10/2021 12:06, Maarten Lankhorst wrote: > > > Op 21-10-2021 om 12:38 schreef Christian König: > > > > Am 21.10.21 um 12:35 schrieb Maarten Lankhorst: > > > > > From:

Re: [PATCH 26/28] drm/nouveau: use the new interator in nv50_wndw_prepare_fb

On Fri, Oct 22, 2021 at 03:17:17PM +0200, Christian König wrote: > Am 13.10.21 um 16:29 schrieb Daniel Vetter: > > On Tue, Oct 05, 2021 at 01:37:40PM +0200, Christian König wrote: > > > Makes the handling a bit more complex, but avoids the use of > > > dma_resv_get_excl_unlocked(). > > > > > >

Re: [PATCH] [RESEND] drm: fb_helper: fix CONFIG_FB dependency

On Wed, Oct 27, 2021 at 03:19:34PM +0200, Javier Martinez Canillas wrote: > On 10/27/21 14:18, Arnd Bergmann wrote: > > [snip] > > > Right, how about this change on top? > > > > --- a/drivers/gpu/drm/Kconfig > > +++ b/drivers/gpu/drm/Kconfig > > @@ -117,9 +117,8 @@ config DRM_DEBUG_MODESET_LOCK

Re: [RFC PATCH 1/8] tracing/gpu: modify gpu_mem_total

On Thu, Oct 21, 2021 at 09:07:15AM -0400, Steven Rostedt wrote: > On Thu, 21 Oct 2021 13:56:38 +0200 > Daniel Vetter wrote: > > > Yay, that patch is just impressive. Lands a new gpu tracepoints, never > > even showed up on the gpu subsystem discussion list. > > I'm guessing there was some

Re: [PATCH v2] drm/ttm: Do not put non-struct page memory into PUD/PMDs

On Fri, Oct 22, 2021 at 03:57:42PM -0300, Jason Gunthorpe wrote: > On Thu, Oct 21, 2021 at 01:41:39PM +0200, Daniel Vetter wrote: > > On Wed, Oct 20, 2021 at 04:37:02PM -0300, Jason Gunthorpe wrote: > > > On Wed, Oct 20, 2021 at 08:41:24AM +0200, Christian König wrote: > > > > > > > > I think the

Re: [Intel-gfx] [PULL] drm-intel-fixes

On Thu, 28 Oct 2021, Ville Syrjälä wrote: > On Thu, Oct 28, 2021 at 01:29:21PM +0300, Jani Nikula wrote: >> >> Hi Dave & Daniel - >> >> Certainly more than I'd like at this stage, but it's mostly Cc: stable >> material, and the tracepoint change is a last minute revert to dodge a >> potential

Re: [PATCH] drm: check drm_format_info hsub and vsub to avoid divide by zero

Maybe a self-test checking this would be more appropriate?

Re: [PATCH] drm: check drm_format_info hsub and vsub to avoid divide by zero

On Thu, Oct 28, 2021 at 08:57:17AM -0500, George Kennedy wrote: > Do a sanity check on struct drm_format_info hsub and vsub values to > avoid divide by zero. > > Syzkaller reported a divide error in framebuffer_check() when the > DRM_FORMAT_Q410 or DRM_FORMAT_Q401 pixel_format is passed in via >

[PATCH] drm: check drm_format_info hsub and vsub to avoid divide by zero

Do a sanity check on struct drm_format_info hsub and vsub values to avoid divide by zero. Syzkaller reported a divide error in framebuffer_check() when the DRM_FORMAT_Q410 or DRM_FORMAT_Q401 pixel_format is passed in via the DRM_IOCTL_MODE_ADDFB2 ioctl. The drm_format_info struct for the

[PATCH 6/6] drm/radeon: use dma_resv_wait_timeout() instead of manually waiting

Don't touch the exclusive fence manually here, but rather use the general dma_resv function. We did that for better hw reset handling but this doesn't necessary work correctly. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon_uvd.c | 13 + 1 file changed, 5

[PATCH 3/6] drm/etnaviv: stop getting the excl fence separately here

Just grab all fences in one go. Signed-off-by: Christian König --- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c index

[PATCH 4/6] dma-buf: drop excl_fence parameter from dma_resv_get_fences

Returning the exclusive fence separately is no longer used. Signed-off-by: Christian König --- drivers/dma-buf/dma-resv.c | 43 +++- drivers/dma-buf/st-dma-resv.c| 26 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 4 +-

[PATCH 2/6] drm/amdgpu: stop getting excl fence separately

Just grab all fences for the display flip in one go. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 +- 2 files changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h

[PATCH 5/6] RDMA: use dma_resv_wait() instead of extracting the fence

Use dma_resv_wait() instead of extracting the exclusive fence and waiting on it manually. Signed-off-by: Christian König --- drivers/infiniband/core/umem_dmabuf.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/infiniband/core/umem_dmabuf.c

[PATCH 1/6] dma-buf: move dma_resv_prune_unlocked into dma_resv.c

The i915 driver implements a prune function which is called when it is very likely that the fences inside the dma_resv object can be removed because they are all signaled. Move that function into the dma-resv.c code since the behavior of pruning fences is something internal to the object.

Re: [Intel-gfx] [PULL] drm-intel-fixes

On Thu, Oct 28, 2021 at 01:29:21PM +0300, Jani Nikula wrote: > > Hi Dave & Daniel - > > Certainly more than I'd like at this stage, but it's mostly Cc: stable > material, and the tracepoint change is a last minute revert to dodge a > potential "tracepoints are uabi" bullet before it hits the

[PATCH 11/11] drm/i915: Require object lock when freeing pages during destruction

From: Maarten Lankhorst TTM already requires this, and we require it for delayed destroy. Signed-off-by: Maarten Lankhorst Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_object.c | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH 09/11] drm/i915: Rework context handling in hugepages selftests

From: Maarten Lankhorst In the next commit, we don't evict when refcount = 0, so we need to call drain freed objects, because we want to pin new bo's in the same place, causing a test failure. Furthermore, since each subtest is separated, it's a lot better to use i915_live_selftests, so each

[PATCH 08/11] drm/i915: Remove resv from i915_vma

From: Maarten Lankhorst It's just an alias to vma->obj->base.resv, no need to duplicate it. Signed-off-by: Maarten Lankhorst Reviewed-by: Niranjana Vishwanathapura Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++-- drivers/gpu/drm/i915/i915_vma.c

  1   2   >