Re: [PATCH v3 3/4] dt-bindings: display: imx: add bindings for DCSS

Hi Lucas, On Mon, Feb 24, 2020 at 06:21:57PM +0100, Lucas Stach wrote: > On Fr, 2019-12-06 at 11:52 +0200, Laurentiu Palcu wrote: > > Add bindings for iMX8MQ Display Controller Subsystem. > > > > Signed-off-by: Laurentiu Palcu > > Reviewed-by: Rob Herring > > --- > >

Re: [PATCH v3 2/4] drm/imx: Add initial support for DCSS on iMX8MQ

Hi Lucas, Thanks for taking some time to look over this series. On Mon, Feb 24, 2020 at 06:27:25PM +0100, Lucas Stach wrote: > Hi Laurentiu, > > just a first drive-by comment, more in-depth review tomorrow. > > On Fr, 2019-12-06 at 11:52 +0200, Laurentiu Palcu wrote: > > This adds initial

Re: RFC: drm/virtio: Dummy virtio GPU

> > No. > > > > First, what is wrong with vkms? > The total lines of vkms driver is 1.2k+. Which is small for a drm driver. > I think it doesn't work along > itself to provide things like mmap on prime fd? (I tried it months > ago). Seems vkms only supports prime import, not prime export.

Re: [Bug] virtio-gpu broken with qemu/kvm on arm64 on kernel 5.5+

Hi, > > Perhaps try the entire series? > > > > https://patchwork.kernel.org/cover/11300619/ Latest version is at: https://git.kraxel.org/cgit/linux/log/?h=drm-virtio-no-wc > Applied entire series on top of 5.5.6, but still the same problem. Can you double-check? Cherry-picking the shmem

Re: [PATCH 0/3] Add separate non-KMS state; constify struct drm_driver

Hi Am 25.02.20 um 18:44 schrieb Daniel Vetter: > On Tue, Feb 25, 2020 at 04:58:59PM +0100, Thomas Zimmermann wrote: >> This patchset moves legacy, non-KMS driver state from struct drm_driver >> into struct drm_legacy_state. Only non-KMS drivers provide an instance >> of the latter structure. One

[PATCH v9 0/5] mt8183 dpi supports dual edge and pin mode swap

Changes since v8: - drop pclk-sample redefine in mediatek,dpi.txt - only get the gpiomode and dpimode when dpi->pinctrl is successful. Changes since v7: - separate dt-bindings to independent patches. - move dpi dual edge to one patch. Changes since v6: - change dual_edge to pclk-sample -

[PATCH v9 4/5] drm/mediatek: dpi sample mode support

DPI can sample on falling, rising or both edge. When DPI sample the data both rising and falling edge. It can reduce half data io pins. Reviewed-by: CK Hu Signed-off-by: Jitao Shi --- drivers/gpu/drm/mediatek/mtk_dpi.c | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-)

[PATCH v9 3/5] dt-bindings: display: mediatek: dpi sample data in dual edge support

Add property "pclk-sample" to config the dpi sample on falling (0), rising (1), both falling and rising (2). Signed-off-by: Jitao Shi --- .../devicetree/bindings/display/mediatek/mediatek,dpi.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git

Re: [PATCH v8 0/6] arm/arm64: mediatek: Fix mmsys device probing

Hi, Enric: On Tue, 2020-02-25 at 11:56 +0100, Enric Balletbo i Serra wrote: > > On 24/2/20 6:52, CK Hu wrote: > > > > Hi, > > > > On Fri, 2020-02-21 at 18:10 +0100, Enric Balletbo i Serra wrote: > >> Hi, > >> > >> On 21/2/20 12:53, Matthias Brugger wrote: > >>> > >>> > >>> On 21/02/2020 12:37,

[PATCH v9 2/5] dt-bindings: display: mediatek: control dpi pins mode to avoid leakage

Add property "pinctrl-names" to swap pin mode between gpio and dpi mode. Set pin mode to gpio oupput-low to avoid leakage current when dpi disable. Reviewed-by: CK Hu Signed-off-by: Jitao Shi --- .../devicetree/bindings/display/mediatek/mediatek,dpi.txt | 7 +++ 1 file changed, 7

[PATCH v9 5/5] drm/mediatek: set dpi pin mode to gpio low to avoid leakage current

Config dpi pins mode to output and pull low when dpi is disabled. Aovid leakage current from some dpi pins (Hsync Vsync DE ... ). Signed-off-by: Jitao Shi --- drivers/gpu/drm/mediatek/mtk_dpi.c | 31 ++ 1 file changed, 31 insertions(+) diff --git

[PATCH v9 1/5] dt-bindings: media: add pclk-sample dual edge property

Some chips's sample mode are rising, falling and dual edge (both falling and rising edge). Extern the pclk-sample property to support dual edge. Reviewed-by: CK Hu Signed-off-by: Jitao Shi --- Documentation/devicetree/bindings/media/video-interfaces.txt | 4 ++-- 1 file changed, 2

Re: [Nouveau] [PATCH 1/3] drm: Add separate state structure for legacy, non-KMS drivers

Hi Emil Am 25.02.20 um 18:37 schrieb Emil Velikov: > Hi Thomas, > > On Tuesday, 25 February 2020, Thomas Zimmermann > wrote: > > Non-KMS drivers store state in struct drm_driver. This bloats the > structure for KMS drivers and prevents it from being declared

Re: + dma-buf-free-dmabuf-name-in-dma_buf_release.patch added to -mm tree

Hello Andrew, On Wed, 26 Feb 2020 at 07:25, Andrew Morton wrote: > > > The patch titled > Subject: dma-buf: free dmabuf->name in dma_buf_release() > has been added to the -mm tree. Its filename is > dma-buf-free-dmabuf-name-in-dma_buf_release.patch Thanks for taking this patch via

Re: [PATCH 6/7] drm/sun4i: de2: Don't return de2_fmt_info struct

On Wed, Feb 26, 2020 at 2:50 AM Jernej Škrabec wrote: > > Hi! > > Dne torek, 25. februar 2020 ob 09:52:18 CET je Chen-Yu Tsai napisal(a): > > On Tue, Feb 25, 2020 at 4:35 PM Maxime Ripard wrote: > > > Hi, > > > > > > On Mon, Feb 24, 2020 at 06:39:00PM +0100, Jernej Skrabec wrote: > > > > Now

Re: [PATCH v8 7/7] drm/mediatek: set dpi pin mode to gpio low to avoid leakage current

Hi, Jitao: On Tue, 2020-02-25 at 17:40 +0800, Jitao Shi wrote: > Config dpi pins mode to output and pull low when dpi is disabled. > Aovid leakage current from some dpi pins (Hsync Vsync DE ... ). > > Signed-off-by: Jitao Shi > --- > drivers/gpu/drm/mediatek/mtk_dpi.c | 30

Re: [PATCH v8 5/7] drm/mediatek: dpi sample mode support

On Tue, 2020-02-25 at 17:40 +0800, Jitao Shi wrote: > DPI can sample on falling, rising or both edge. > When DPI sample the data both rising and falling edge. > It can reduce half data io pins. > Reviewed-by: CK Hu > Signed-off-by: Jitao Shi > --- > drivers/gpu/drm/mediatek/mtk_dpi.c | 18

Re: [PATCH v8 4/7] dt-bindings: display: mediatek: dpi sample data in dual edge support

Hi, Jitao: On Tue, 2020-02-25 at 17:40 +0800, Jitao Shi wrote: > Add property "pclk-sample" to config the dpi sample on falling (0), > rising (1), both falling and rising (2). > > Signed-off-by: Jitao Shi > --- > .../devicetree/bindings/display/mediatek/mediatek,dpi.txt | 4 > 1 file

Re: [PATCH] dma-buf: free dmabuf->name in dma_buf_release()

On Tue, 25 Feb 2020 12:44:46 -0800 Cong Wang wrote: > dma-buff name can be set via DMA_BUF_SET_NAME ioctl, but once set > it never gets freed. > > Free it in dma_buf_release(). > > ... > > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -108,6 +108,7 @@ static int

Re: [PATCH/RFC 3/3] drm: rcar_du: Constify drm_driver

Hi Emil, On Mon, Feb 24, 2020 at 03:26:05PM +, Emil Velikov wrote: > Thanks Laurent for sorting this out. You're welcome. It's been bothering me for some time :-) > On Sat, 22 Feb 2020 at 17:59, Daniel Vetter wrote: > > On Sat, Feb 22, 2020 at 05:24:30PM +0200, Laurent Pinchart wrote: > >

Re: [PATCH v8 3/7] dt-bindings: display: mediatek: control dpi pins mode to avoid leakage

On Tue, 2020-02-25 at 17:40 +0800, Jitao Shi wrote: > Add property "pinctrl-names" to swap pin mode between gpio and dpi mode. Set > pin mode to gpio oupput-low to avoid leakage current when dpi disable. > Reviewed-by: CK Hu > Signed-off-by: Jitao Shi > --- >

Re: [PATCH v8 1/7] dt-bindings: media: add pclk-sample dual edge property

On Tue, 2020-02-25 at 17:40 +0800, Jitao Shi wrote: > Some chips's sample mode are rising, falling and dual edge (both > falling and rising edge). > Extern the pclk-sample property to support dual edge. > Reviewed-by: CK Hu > Signed-off-by: Jitao Shi > --- >

Re: [PATCH v3] drm: shmobile: Reduce include dependencies

Hi Andy, Thank you for the patch, and sorry for the delay. On Mon, Feb 24, 2020 at 11:04:30AM +0200, Andy Shevchenko wrote: > On Thu, Feb 06, 2020 at 01:12:32PM +0200, Andy Shevchenko wrote: > > This file doesn't need everything provided by . s/everything/anything/ > > All it needs are some

Re: [PATCH v8 6/7] drm/mediatek: add mt8183 dpi clock factor

Hi, Jitao: On Tue, 2020-02-25 at 17:40 +0800, Jitao Shi wrote: > The factor depends on the divider of DPI in MT8183, therefore, > we should fix this factor to the right and new one. > Applied to mediatek-drm-next-5.7 [1], thanks. [1]

Re: [PATCH v8 2/7] dt-bindings: display: mediatek: update dpi supported chips

On Tue, 2020-02-25 at 11:10 -0600, Rob Herring wrote: > On Tue, 25 Feb 2020 17:40:52 +0800, Jitao Shi wrote: > > Add descriptions about supported chips, including MT2701 & MT8173 & > > mt8183 > > > > Signed-off-by: Jitao Shi > > --- > > .../devicetree/bindings/display/mediatek/mediatek,dpi.txt

Re: [PATCH v2 4/4] drm/msm/a6xx: Use the DMA API for GMU memory objects

On Tue, Feb 25, 2020 at 3:54 PM John Stultz wrote: > > On Thu, Feb 20, 2020 at 10:27 AM Jordan Crouse wrote: > > > > The GMU has very few memory allocations and uses a flat memory space so > > there is no good reason to go out of our way to bypass the DMA APIs which > > were basically designed

Re: [PATCH v4 1/7] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183

+Nick Fan +Sj Huang @ MTK On Wed, Feb 26, 2020 at 1:16 AM Rob Herring wrote: > > On Fri, Feb 07, 2020 at 01:26:21PM +0800, Nicolas Boichat wrote: > > Define a compatible string for the Mali Bifrost GPU found in > > Mediatek's MT8183 SoCs. > > > > Signed-off-by: Nicolas Boichat > > Reviewed-by:

[PATCH] RFC: dma-buf: Add an API for importing and exporting sync files

Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of

Re: [PATCH v2 4/4] drm/msm/a6xx: Use the DMA API for GMU memory objects

On Thu, Feb 20, 2020 at 10:27 AM Jordan Crouse wrote: > > The GMU has very few memory allocations and uses a flat memory space so > there is no good reason to go out of our way to bypass the DMA APIs which > were basically designed for this exact scenario. > > v2: Pass force_dma false to

Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel

Hi, On Tue, Feb 25, 2020 at 03:09:37PM -0800, Tony Lindgren wrote: > * Sebastian Reichel [200225 23:03]: > > Hi, > > > > On Tue, Feb 25, 2020 at 07:42:37AM -0800, Tony Lindgren wrote: > > > * Sebastian Reichel [200225 02:29]: > > > > On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren

Re: [PATCH 7/7] docs: gpu: i915.rst: fix warnings due to file renames

On Sat, Feb 22, 2020 at 10:00:07AM +0100, Mauro Carvalho Chehab wrote: > Fix two warnings due to file rename: > > WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function > csr support for dmc ./drivers/gpu/drm/i915/intel_csr.c' failed with return > code 1 > WARNING:

Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel

Hi Sebastian, On Wed, Feb 26, 2020 at 12:01:24AM +0100, Sebastian Reichel wrote: > On Tue, Feb 25, 2020 at 07:42:37AM -0800, Tony Lindgren wrote: > > * Sebastian Reichel [200225 02:29]: > > > On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren wrote: > > > > BTW, I think there's also some

Re: [PATCHv2 00/56] drm/omap: Convert DSI code to use drm_mipi_dsi and drm_panel

Hi, On Tue, Feb 25, 2020 at 07:42:37AM -0800, Tony Lindgren wrote: > * Sebastian Reichel [200225 02:29]: > > On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren wrote: > > > BTW, I think there's also some refcount issue in general where > > > the omapdrm related modules cannot be unloaded

Re: [PATCH 04/12] drm: Nuke mode->vrefresh

On Tue, Feb 25, 2020 at 8:27 PM Ville Syrjälä wrote: > OK, so I went ahead a wrote a bit of cocci [1] to find the bad apples. That's impressive :D > Unfortunately it found a lot of strange stuff: I will answer for the weirdness I caused. I have long suspected that a whole bunch of the

[Bug 206393] amdgpu: garbled screen after resume

https://bugzilla.kernel.org/show_bug.cgi?id=206393 --- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) --- The SAD message is harmless and unrelated. The issue is with the patch in comment 5. -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 206393] amdgpu: garbled screen after resume

https://bugzilla.kernel.org/show_bug.cgi?id=206393 Alexander Jones (acjon...@hawaii.edu) changed: What|Removed |Added CC|

[Bug 204241] amdgpu fails to resume from suspend

https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #55 from Alexander Jones (acjon...@hawaii.edu) --- Thank you very much for that link, Mr. Franke! That bug report much more closely approximates my situation, down to a T. I tried the older kernel suggestion listed there, I still have

Re: [PATCH v3 4/4] drm/panfrost: Register to the Energy Model with devfreq device

On Fri, Feb 21, 2020 at 1:48 PM Lukasz Luba wrote: > > Add device to the Energy Model framework. It will create a dedicated > and unified data structures used i.e. in the thermal framework. > The power model used in dev_pm_opp subsystem is simplified and created > based on DT

Re: [PATCH v4 0/7] Add dts for mt8183 GPU (and misc panfrost patches)

On Thu, Feb 6, 2020 at 11:26 PM Nicolas Boichat wrote: > > Hi! > > Follow-up on the v3: https://patchwork.kernel.org/cover/11331343/. > > The main purpose of this series is to upstream the dts change and the > binding document, but I wanted to see how far I could probe the GPU, to > check that

Re: [PATCH 2/4] drm/msm/dpu: Refactor rm iterator

On Tue, Feb 25, 2020 at 11:33 AM Stephen Boyd wrote: > > Quoting Drew Davenport (2020-02-19 09:42:25) > > Make iterator implementation private, and add function to > > query resources assigned to an encoder. > > > > Signed-off-by: Drew Davenport > > > diff --git

Re: [PATCH 04/12] drm: Nuke mode->vrefresh

On Tue, Feb 25, 2020 at 05:45:06PM +0200, Ville Syrjälä wrote: > On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote: > > On 25.02.2020 12:21, Ville Syrjälä wrote: > > > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote: > > >> On 19.02.2020 21:35, Ville Syrjala wrote: > >

Re: [PATCH] drm/ttm: fix leaking fences via ttm_buffer_object_transfer

Am 25.02.20 um 20:11 schrieb Alex Deucher: On Tue, Feb 25, 2020 at 2:09 PM Christian König wrote: Am 25.02.20 um 19:56 schrieb Alex Deucher: From: Ahzo Set the drm_device to NULL, so that the newly created buffer object doesn't appear to use the embedded gem object. This is necessary,

Re: [PATCH] dma-buf: Fix missing excl fence waiting

Am 25.02.20 um 18:23 schrieb Daniel Vetter: On Sun, Feb 23, 2020 at 01:04:15PM +0100, Christian König wrote: Am 23.02.20 um 12:56 schrieb Pan, Xinhui: If shared fence list is not empty, even we want to test all fences, excl fence is ignored. That is abviously wrong, so fix it. Yeah that is a

Re: [PATCH] drm/ttm: fix leaking fences via ttm_buffer_object_transfer

On Tue, Feb 25, 2020 at 2:09 PM Christian König wrote: > > Am 25.02.20 um 19:56 schrieb Alex Deucher: > > From: Ahzo > > > > Set the drm_device to NULL, so that the newly created buffer object > > doesn't appear to use the embedded gem object. > > > > This is necessary, because otherwise no

Re: [PATCH v2 3/4] drm/mediatek: add the mipitx driving control

On 25/02/2020 12:47, Jitao Shi wrote: > Add a property in device tree to control the driving by different > board. > > Signed-off-by: Jitao Shi Reviewed-by: Matthias Brugger > --- > drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 6 ++ > drivers/gpu/drm/mediatek/mtk_mipi_tx.h|

Re: [PATCH] drm/ttm: fix leaking fences via ttm_buffer_object_transfer

Am 25.02.20 um 19:56 schrieb Alex Deucher: From: Ahzo Set the drm_device to NULL, so that the newly created buffer object doesn't appear to use the embedded gem object. This is necessary, because otherwise no corresponding dma_resv_fini for the dma_resv_init is called, resulting in a memory

RE: [PATCH 13/15] drm/amdgpu/display: split dp connector registration (v3)

[AMD Official Use Only - Internal Distribution Only] Hi Alex: The patch set is verified on Ubuntu, and I'll try it out on Chrome as well. Thanks a lot! Regards, Jerry -Original Message- From: Alex Deucher Sent: February 25, 2020 1:42 PM To: Zuo, Jerry Cc: Liu, Zhan ;

[PULL] drm-intel-next

R_DATE to 20200225 (2020-02-25 10:41:22 -0800) - A backmerge of drm-next solving conflicts on i915/gt/intel_lrc.c - Clean up shadow batch after I915_EXEC_SECURE - Drop assertion that active->fence is

[PATCH] drm/ttm: fix leaking fences via ttm_buffer_object_transfer

From: Ahzo Set the drm_device to NULL, so that the newly created buffer object doesn't appear to use the embedded gem object. This is necessary, because otherwise no corresponding dma_resv_fini for the dma_resv_init is called, resulting in a memory leak. The dma_resv_fini in

Re: [PATCH v2 2/4] dt-bindings: display: msm: Add required dma-range property

On Thu, Feb 20, 2020 at 12:27 PM Jordan Crouse wrote: > > The GMU node now requires a specific dma-range property so that the driver s/dma-range/dma-ranges/ here and the subject. > can use the DMA API to do the few memory allocations required by the GMU. > This sets the IOMMU iova allocator to

Re: [PATCH 13/15] drm/amdgpu/display: split dp connector registration (v3)

On Tue, Feb 25, 2020 at 1:32 PM Alex Deucher wrote: > > On Tue, Feb 25, 2020 at 1:30 PM Zuo, Jerry wrote: > > > > [AMD Official Use Only - Internal Distribution Only] > > > > Hi Alex: > > > > It happened when a MST monitor is attached, either in driver load or > > hotplug later. > > I

Re: [PATCH 13/15] drm/amdgpu/display: split dp connector registration (v3)

On Tue, Feb 25, 2020 at 1:30 PM Zuo, Jerry wrote: > > [AMD Official Use Only - Internal Distribution Only] > > Hi Alex: > > It happened when a MST monitor is attached, either in driver load or > hotplug later. I think I found the issue. I'll send a patch shortly. Alex > > Regards, >

Re: [PATCH 88/89] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings

On Mon, Feb 24, 2020 at 10:07:30AM +0100, Maxime Ripard wrote: > The HDMI controllers found in the BCM2711 SoC need some adjustments to the > bindings, especially since the registers have been shuffled around in more > register ranges. > > Cc: Rob Herring > Cc: devicet...@vger.kernel.org >

Re: [PATCH 13/15] drm/amdgpu/display: split dp connector registration (v3)

On Tue, Feb 25, 2020 at 1:20 PM Liu, Zhan wrote: > > > > -Original Message- > > From: Liu, Zhan > > Sent: 2020/February/25, Tuesday 10:10 AM > > To: Alex Deucher ; Wentland, Harry > > > > Cc: amd-gfx list ; Maling list - DRI > > developers ; Deucher, Alexander > > ; Broadworth, Mark > >

RE: [PATCH 13/15] drm/amdgpu/display: split dp connector registration (v3)

> -Original Message- > From: Liu, Zhan > Sent: 2020/February/25, Tuesday 10:10 AM > To: Alex Deucher ; Wentland, Harry > > Cc: amd-gfx list ; Maling list - DRI > developers ; Deucher, Alexander > ; Broadworth, Mark > > Subject: RE: [PATCH 13/15] drm/amdgpu/display: split dp connector >

Re: [PATCH 33/89] dt-bindings: display: vc4: Document BCM2711 VC5

On Mon, 24 Feb 2020 10:06:35 +0100, Maxime Ripard wrote: > The BCM2711 comes with a new VideoCore. Add a compatible for it. > > Cc: Rob Herring > Cc: devicet...@vger.kernel.org > Signed-off-by: Maxime Ripard > --- > Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml | 1 + > 1

Re: [PATCH 59/89] dt-bindings: display: vc4: pv: Add BCM2711 pixel valves

On Mon, 24 Feb 2020 10:07:01 +0100, Maxime Ripard wrote: > The BCM2711 comes with other pixelvalves that have different requirements > and capabilities. Let's document their compatible. > > Cc: Rob Herring > Cc: devicet...@vger.kernel.org > Signed-off-by: Maxime Ripard > --- >

Re: [PATCH 30/89] dt-bindings: display: vc4: dpi: Add missing clock-names property

On Mon, 24 Feb 2020 10:06:32 +0100, Maxime Ripard wrote: > While the device tree and the driver expected a clock-names property, it > wasn't explicitly documented in the previous binding. Make sure it is now. > > Cc: Rob Herring > Cc: devicet...@vger.kernel.org > Signed-off-by: Maxime Ripard >

Re: [PATCH 32/89] dt-bindings: display: vc4: hdmi: Add missing clock-names property

On Mon, 24 Feb 2020 10:06:34 +0100, Maxime Ripard wrote: > While the device tree and the driver expected a clock-names property, it > wasn't explicitly documented in the previous binding. The documented order > was wrong too, so make sure clock-names is there and in the proper order. > > Cc: Rob

Re: [PATCH 31/89] dt-bindings: display: vc4: dsi: Add missing clock properties

On Mon, 24 Feb 2020 10:06:33 +0100, Maxime Ripard wrote: > While the device tree and the driver expected a clock-names and a > clock-cells properties, it wasn't explicitly documented in the previous > binding. Make sure it is now. > > Cc: Rob Herring > Cc: devicet...@vger.kernel.org >

Re: [PATCH 26/89] dt-bindings: clock: Add BCM2711 DVP binding

On Mon, 24 Feb 2020 10:06:28 +0100, Maxime Ripard wrote: > The BCM2711 has a unit controlling the HDMI0 and HDMI1 clock and reset > signals. Let's add a binding for it. > > Cc: Philipp Zabel > Cc: Rob Herring > Cc: devicet...@vger.kernel.org > Signed-off-by: Maxime Ripard > --- >

Re: [PATCH 06/89] dt-bindings: clock: Add a binding for the RPi Firmware clocks

On Mon, Feb 24, 2020 at 10:06:08AM +0100, Maxime Ripard wrote: > The firmare running on the RPi VideoCore can be used to discover and > change the various clocks running in the BCM2711. Since devices will > need to use them through the DT, let's add a pretty simple binding. > > Cc: Michael

Re: [PATCH 02/89] dt-bindings: i2c: brcmstb: Add BCM2711 BSC/AUTO-I2C binding

On Mon, 24 Feb 2020 10:06:04 +0100, Maxime Ripard wrote: > The HDMI blocks in the BCM2771 have an i2c controller to retrieve the > EDID. This block is split into two parts, the BSC and the AUTO_I2C, > lying in two separate register areas. > > The AUTO_I2C block has a mailbox-like interface and

Re: [PATCH 01/89] dt-bindings: i2c: brcmstb: Convert the BRCMSTB binding to a schema

On Mon, 24 Feb 2020 10:06:03 +0100, Maxime Ripard wrote: > Switch the DT binding to a YAML schema to enable the DT validation. > > Cc: Kamal Dasu > Cc: Florian Fainelli > Cc: Rob Herring > Cc: Wolfram Sang > Cc: bcm-kernel-feedback-l...@broadcom.com > Cc: linux-...@vger.kernel.org > Cc:

Re: [PATCH 2/3 v2] drm/panel: Add DT bindings for Novatek NT35510-based panels

On Sun, 23 Feb 2020 13:18:40 +0100, Linus Walleij wrote: > This adds device tree bindings for the Novatek NT35510-based > family of panels. Since several such panels are in existence > we define bindings common for all, and define the compatible > string for one certain panel (Hydis HVA40WV1). >

Re: [PATCH 1/3 v2] dt-bindings: Add vendor prefix for Hydis technologies

On Sun, 23 Feb 2020 13:18:39 +0100, Linus Walleij wrote: > This vendor has produced a number of display panels, > including HVA40WV1. > > Cc: devicet...@vger.kernel.org > Cc: Stephan Gerhold > Signed-off-by: Linus Walleij > --- > ChangeLog v1->v2: > - New patch adding this vendor. > --- >

Re: [PATCH 0/3] Add separate non-KMS state; constify struct drm_driver

On Tue, Feb 25, 2020 at 04:58:59PM +0100, Thomas Zimmermann wrote: > This patchset moves legacy, non-KMS driver state from struct drm_driver > into struct drm_legacy_state. Only non-KMS drivers provide an instance > of the latter structure. One special case is nouveau, which supports > legacy

Re: [Nouveau] [PATCH 1/3] drm: Add separate state structure for legacy, non-KMS drivers

Hi Thomas, On Tuesday, 25 February 2020, Thomas Zimmermann wrote: > Non-KMS drivers store state in struct drm_driver. This bloats the > structure for KMS drivers and prevents it from being declared with > 'static const' qualifiers. Moving the non-KMS state into a separate > data structure

[Bug 204241] amdgpu fails to resume from suspend

https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #54 from Bjoern Franke (b...@nord-west.org) --- @Alexander Jones: Regarding the garbled screen after resume, there's another bugreport: https://bugzilla.kernel.org/show_bug.cgi?id=206393 -- You are receiving this mail because: You

Re: [PATCH] dma-buf: Fix missing excl fence waiting

On Sun, Feb 23, 2020 at 01:04:15PM +0100, Christian König wrote: > Am 23.02.20 um 12:56 schrieb Pan, Xinhui: > > If shared fence list is not empty, even we want to test all fences, excl > > fence is ignored. > > That is abviously wrong, so fix it. > > Yeah that is a known issue and I completely

Re: [PATCH v4 1/7] dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183

On Fri, Feb 07, 2020 at 01:26:21PM +0800, Nicolas Boichat wrote: > Define a compatible string for the Mali Bifrost GPU found in > Mediatek's MT8183 SoCs. > > Signed-off-by: Nicolas Boichat > Reviewed-by: Alyssa Rosenzweig > --- > > v4: > - Add power-domain-names description >(kept

Re: [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2

On Mon, Feb 24, 2020 at 07:46:59PM +0100, Christian König wrote: > Am 23.02.20 um 17:54 schrieb Thomas Hellström (VMware): > > On 2/23/20 4:45 PM, Christian König wrote: > > > Am 21.02.20 um 18:12 schrieb Daniel Vetter: > > > > [SNIP] > > > > Yeah the Great Plan (tm) is to fully rely on ww_mutex

Re: [PATCH v8 2/7] dt-bindings: display: mediatek: update dpi supported chips

On Tue, 25 Feb 2020 17:40:52 +0800, Jitao Shi wrote: > Add descriptions about supported chips, including MT2701 & MT8173 & > mt8183 > > Signed-off-by: Jitao Shi > --- > .../devicetree/bindings/display/mediatek/mediatek,dpi.txt| 1 + > 1 file changed, 1 insertion(+) > Please add

Re: [PATCH v2 1/2] drm/client: Dual licence the file in GPL-2 and MIT

On Tue, Feb 25, 2020 at 09:18:10AM +0100, Emmanuel Vadot wrote: > On Mon, 24 Feb 2020 11:40:38 + > Chris Wilson wrote: > > > Quoting Jani Nikula (2020-02-15 18:33:09) > > > On Sat, 15 Feb 2020, Emmanuel Vadot wrote: > > > > From: Emmanuel Vadot > > > > > > > > Contributors for this file

[PATCH] drm/pci: Unexport drm_get_pci_dev

Only user left is the shadow attach for legacy drivers. v2: Shift the #ifdef CONFIG_DRM_LEGACY to now also include drm_get_pci_dev() (Thomas) Cc: Thomas Zimmermann Cc: Emil Velikov Cc: Alex Deucher Reviewed-by: Thomas Zimmermann Reviewed-by: Emil Velikov Signed-off-by: Daniel Vetter ---

Re: [PATCHv2 13/56] drm/omap: dsi: switch dsi_vc_send_long/short to mipi_dsi_msg

Hi Sebastian, Thank you for the patch. On Tue, Feb 25, 2020 at 12:20:43AM +0100, Sebastian Reichel wrote: > Simplify the DSI encoder by using mipi_dsi_msg for > dsi_vc_send_long and dsi_vc_send_short. Further improvements > require cleaning up the channel allocation code first. > >

Re: [Nouveau] [PATCH 1/3] drm: Add separate state structure for legacy, non-KMS drivers

Hi Am 25.02.20 um 17:06 schrieb Ilia Mirkin: > On Tue, Feb 25, 2020 at 10:59 AM Thomas Zimmermann > wrote: >> >> Non-KMS drivers store state in struct drm_driver. This bloats the >> structure for KMS drivers and prevents it from being declared with >> 'static const' qualifiers. Moving the

Re: [PATCHv2 12/56] drm/omap: dsi: simplify read functions

Hi Sebastian, Thank you for the patch. On Tue, Feb 25, 2020 at 12:20:42AM +0100, Sebastian Reichel wrote: > Simplify the read related message handling by using the functionality > provided by CONFIG_DRM_MIPI_DSI. > > Signed-off-by: Sebastian Reichel > --- > drivers/gpu/drm/omapdrm/dss/dsi.c |

Re: [Nouveau] [PATCH 1/3] drm: Add separate state structure for legacy, non-KMS drivers

On Tue, Feb 25, 2020 at 10:59 AM Thomas Zimmermann wrote: > > Non-KMS drivers store state in struct drm_driver. This bloats the > structure for KMS drivers and prevents it from being declared with > 'static const' qualifiers. Moving the non-KMS state into a separate > data structure resolves

[PATCH 1/3] drm: Add separate state structure for legacy, non-KMS drivers

Non-KMS drivers store state in struct drm_driver. This bloats the structure for KMS drivers and prevents it from being declared with 'static const' qualifiers. Moving the non-KMS state into a separate data structure resolves this. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_drv.c

[PATCH 3/3] drm: Constify struct drm_driver in DRM core

Once used for creatign a DRM device, instances of struct drm_driver are not modified. So all related variables in the DRM core can be declared 'const'. In addition to the core interfaces, the patch also changes tdfx accordingly. The other non-KMS drivers set.num_ioctls outside of their instance's

[PATCH 0/3] Add separate non-KMS state; constify struct drm_driver

This patchset moves legacy, non-KMS driver state from struct drm_driver into struct drm_legacy_state. Only non-KMS drivers provide an instance of the latter structure. One special case is nouveau, which supports legacy interfaces. It also provides an instance of the legacy state if the legacy

[PATCH 2/3] drm: Move non-kms driver state into struct drm_legacy_state

All non-kms driver fields are now located in struct drm_legacy_state. A driver-wide instance is available via struct drm_driver.legacy. The call sites test if the driver is marked with DRIVER_LEGACY before accessing the fields. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/drm_bufs.c

Re: [PATCH 04/12] drm: Nuke mode->vrefresh

On Tue, Feb 25, 2020 at 04:19:27PM +0100, Andrzej Hajda wrote: > On 25.02.2020 12:21, Ville Syrjälä wrote: > > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote: > >> On 19.02.2020 21:35, Ville Syrjala wrote: > >>> From: Ville Syrjälä > >>> > >>> Get rid of mode->vrefresh and just

Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets

On Tue, Feb 25, 2020 at 04:09:26PM +0100, Daniel Vetter wrote: > On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä > wrote: > > > > On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter wrote: > > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > > > pull in arbitrary other

Re: [PATCHv2 11/56] drm/omap: dsi: simplify write function

Hi Sebastian, Thank you for the patch. On Tue, Feb 25, 2020 at 12:20:41AM +0100, Sebastian Reichel wrote: > Simplify the write related messages handling by using the functionality > provided by CONFIG_DRM_MIPI_DSI. > > Signed-off-by: Sebastian Reichel > --- >

Re: [PATCH v7 05/54] drm/bridge: Fix atomic state ops documentation

On Sat, 22 Feb 2020 17:00:17 +0200 Laurent Pinchart wrote: > The drm_bridge_funcs atomic_state_duplicate and atomic_state_destroy > operations are erroneously documented as having a default implementation > if not implemented in bridge drivers. This isn't correct, fix the > documentation. Oops,

Re: [PATCH 2/3] drm/radeon: Inline drm_get_pci_dev

On Sat, Feb 22, 2020 at 12:54 PM Daniel Vetter wrote: > > It's the last user, and more importantly, it's the last non-legacy > user of anything in drm_pci.c. > > The only tricky bit is the agp initialization. But a close look shows > that radeon does not use the drm_agp midlayer (the main use of

Re: [PATCH v7 04/54] drm/bridge: Document the drm_encoder.bridge_chain field as private

On Sat, 22 Feb 2020 17:00:16 +0200 Laurent Pinchart wrote: > The drm_encoder.bridge_chain is not meant to be touched manually by > drivers. Make this clear in the documentation. Thanks for this clarification: Reviewed-by: Boris Brezillon > > Signed-off-by: Laurent Pinchart > --- >

Re: [PATCH 04/12] drm: Nuke mode->vrefresh

On 25.02.2020 12:21, Ville Syrjälä wrote: > On Mon, Feb 24, 2020 at 03:14:54PM +0100, Andrzej Hajda wrote: >> On 19.02.2020 21:35, Ville Syrjala wrote: >>> From: Ville Syrjälä >>> >>> Get rid of mode->vrefresh and just calculate it on demand. Saves >>> a bit of space and avoids the cached value

Re: [PATCH 1/3] drm/amdgpu: Drop DRIVER_USE_AGP

On Mon, Feb 24, 2020 at 3:43 PM Daniel Vetter wrote: > > On Mon, Feb 24, 2020 at 5:10 PM Alex Deucher wrote: > > > > On Sat, Feb 22, 2020 at 12:54 PM Daniel Vetter > > wrote: > > > > > > This doesn't do anything except auto-init drm_agp support when you > > > call drm_get_pci_dev(). Which

Re: [PATCH -next] drm/amd/powerplay: Use bitwise instead of arithmetic operator for flags

On Sun, Feb 23, 2020 at 10:21 PM Quan, Evan wrote: > > Thanks. Reviewed-by: Evan Quan > Applied. Thanks! Alex > -Original Message- > From: Chen Zhou > Sent: Friday, February 21, 2020 8:22 PM > To: Quan, Evan ; Deucher, Alexander > ; Koenig, Christian ; > Zhou, David(ChunMing) ;

RE: [PATCH 13/15] drm/amdgpu/display: split dp connector registration (v3)

> -Original Message- > From: Alex Deucher > Sent: 2020/February/25, Tuesday 9:07 AM > To: Wentland, Harry > Cc: amd-gfx list ; Maling list - DRI > developers ; Deucher, Alexander > ; Broadworth, Mark > ; Liu, Zhan > Subject: Re: [PATCH 13/15] drm/amdgpu/display: split dp connector >

Re: [Intel-gfx] [PATCH] drm: avoid spurious EBUSY due to nonblocking atomic modesets

On Tue, Feb 25, 2020 at 3:48 PM Ville Syrjälä wrote: > > On Tue, Feb 25, 2020 at 12:50:24PM +0100, Daniel Vetter wrote: > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to > > pull in arbitrary other resources, including CRTCs (e.g. when > > reconfiguring global resources).

Re: [PATCH -next] drm/amd/display: remove set but not used variable 'mc_vm_apt_default'

On Fri, Feb 21, 2020 at 10:33 AM YueHaibing wrote: > > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_hubp.c: > In function hubp21_set_vm_system_aperture_settings: > drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_hubp.c:343:23: > warning: variable mc_vm_apt_default set but not used

Re: [PATCH][next] drm: Replace zero-length array with flexible-array member

Quoting Gustavo A. R. Silva (2020-02-25 14:03:47) > The current codebase makes use of the zero-length array language > extension to the C90 standard, but the preferred mechanism to declare > variable-length types such as these ones is a flexible array member[1][2], > introduced in C99: I remember

Re: [PATCH 03/51] drm: add managed resources tied to drm_device

On Tue, Feb 25, 2020 at 11:27 AM Andrzej Hajda wrote: > > Hi Daniel, > > > The patchset looks interesting. > > > On 21.02.2020 22:02, Daniel Vetter wrote: > > We have lots of these. And the cleanup code tends to be of dubious > > quality. The biggest wrong pattern is that developers use devm_,

Re: [PATCHv2 10/56] drm/omap: dsi: drop virtual channel logic

Hi Sebastian, Thank you for the patch. On Tue, Feb 25, 2020 at 12:20:40AM +0100, Sebastian Reichel wrote: > This drops the virtual channel logic. Afterwards DSI clients > request their channel number and get the virtual channel with > the same number or -EBUSY if already in use. I wonder why

Re: [PATCHv2 09/56] drm/omap: dsi: unexport specific data transfer functions

Hi Sebastian, Thank you for the patch. On Tue, Feb 25, 2020 at 12:20:39AM +0100, Sebastian Reichel wrote: > After converting all DSI drivers, unexport the specific transfer > functions. > > Signed-off-by: Sebastian Reichel Reviewed-by: Laurent Pinchart > --- >

Re: [PATCHv2 08/56] drm/omap: panel-dsi-cm: convert to transfer API

Hi Sebastian, Thank you for the patch. On Tue, Feb 25, 2020 at 12:20:38AM +0100, Sebastian Reichel wrote: > This converts the panel-dsi-cm driver to use the transfer > API instead of specific functions, so that the specific > functions can be unexported and squashed into the generic > transfer

  1   2   3   >