[PATCH v4 04/11] drm/bridge: synopsys: dw-hdmi: add bus format negociation

2020-02-06 Thread Neil Armstrong
Add the atomic_get_output_bus_fmts, atomic_get_input_bus_fmts to negociate the possible output and input formats for the current mode and monitor, and use the negotiated formats in a basic atomic_check callback. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 272 ++

[PATCH 0/2] drm/virtio: rework command batching

2020-02-06 Thread Chia-I Wu
This series replaces the global disable_notify state by command-level bools to control vq kicks. When command batching is applied to more places, this prevents one process from affecting another process. ___ dri-devel mailing list dri-devel@lists.freedes

[PATCH 1/2] drm/virtio: remove the global pending_notify state

2020-02-06 Thread Chia-I Wu
Call virtqueue_kick_prepare once in virtio_gpu_enable_notify, not whenever a command is added. This should be more efficient since the intention is to batch commands. Signed-off-by: Chia-I Wu --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 - drivers/gpu/drm/virtio/virtgpu_vq.c | 28

[PATCH 2/2] drm/virtio: remove the global disable_notify state

2020-02-06 Thread Chia-I Wu
The global disable_notify state does not scale well when we start using it in more places and when there are multiple threads. Use command-level bools to control whether to notify or not. The naming conventions are virtio_gpu_cmd_foo -> add foo and commit is implied virtio_gpu_ctrl_bar -> ad

Re: [PATCH] drm/edid: fix building error

2020-02-06 Thread Ville Syrjälä
On Tue, Feb 04, 2020 at 04:41:16PM +0200, Ville Syrjälä wrote: > On Mon, Feb 03, 2020 at 10:31:13PM +0100, Mauro Rossi wrote: > > Fixes the following building error: > > > > CC [M]  drivers/gpu/drm/drm_edid.o > > ~/pie-x86_kernel/kernel/drivers/gpu/drm/drm_edid.c: In function > > 'cea_mode_altern

Re: [PATCH v4 1/2] dt-bindings: display: bridge: Add documentation for Toshiba tc358768

2020-02-06 Thread Rob Herring
On Fri, 31 Jan 2020 13:15:52 +0200, Peter Ujfalusi wrote: > TC358768/TC358778 is a Parallel RGB to MIPI DSI bridge. > > Signed-off-by: Peter Ujfalusi > --- > .../display/bridge/toshiba,tc358768.yaml | 159 ++ > 1 file changed, 159 insertions(+) > create mode 100644 > Docum

Re: [v1] dt-bindings: msm:disp: update dsi and dpu bindings

2020-02-06 Thread Rob Herring
On Tue, Feb 04, 2020 at 07:45:37PM +0530, Harigovindan P wrote: > Updating bindings of dsi and dpu by adding and removing certain > properties. Yes, the diff tells me that. The commit message should say why. This change breaks compatibility as well. > > Signed-off-by: Harigovindan P > --- > >

Re: [PATCH v3] dt-bindings: display: Convert etnaviv to json-schema

2020-02-06 Thread Rob Herring
On Wed, 29 Jan 2020 09:56:13 +0100, Benjamin Gaignard wrote: > Convert etnaviv bindings to yaml format. > Move bindings file from display to gpu folder. > > Signed-off-by: Benjamin Gaignard > --- > version 3: > - describe clock-names as enum to allow all possible mix > > version 2: > - move bind

Re: [PATCH v4 1/3] dt-bindings: one file of all simple DSI panels

2020-02-06 Thread Rob Herring
On Thu, 6 Feb 2020 14:33:42 +0100, Benjamin Gaignard wrote: > From: Sam Ravnborg > > To complement panel-simple.yaml, create panel-simple-dsi.yaml. > panel-simple-dsi-yaml are for all simple DSP panels with a single > power-supply and optional backlight / enable GPIO. > > Migrate panasonic,vvx10

Re: [PATCH v4 2/3] dt-bindings: panel: Convert raydium,rm68200 to json-schema

2020-02-06 Thread Rob Herring
On Thu, 6 Feb 2020 14:33:43 +0100, Benjamin Gaignard wrote: > Convert raydium,rm68200 to json-schema. > > Signed-off-by: Benjamin Gaignard > --- > .../bindings/display/panel/raydium,rm68200.txt | 25 -- > .../bindings/display/panel/raydium,rm68200.yaml| 56 >

Re: [PATCH v4 3/3] dt-bindings: panel: Convert orisetech, otm8009a to json-schema

2020-02-06 Thread Rob Herring
On Thu, 6 Feb 2020 14:33:44 +0100, Benjamin Gaignard wrote: > Convert orisetech,otm8009a to json-schema. > > Signed-off-by: Benjamin Gaignard > --- > .../bindings/display/panel/orisetech,otm8009a.txt | 23 -- > .../bindings/display/panel/orisetech,otm8009a.yaml | 53 > +

Re: [PATCH v2 5/7] drm/panfrost: Add support for multiple power domain support

2020-02-06 Thread Nicolas Boichat
Hi Ulf, On Mon, Jan 27, 2020 at 3:55 PM Ulf Hansson wrote: > > On Fri, 10 Jan 2020 at 02:53, Nicolas Boichat wrote: > > > > +Ulf to keep me honest on the power domains > > > > On Thu, Jan 9, 2020 at 10:08 PM Steven Price wrote: > > > > > > On 08/01/2020 05:23, Nicolas Boichat wrote: > > > > Whe

Re: [PATCH v2 5/7] drm/panfrost: Add support for multiple power domain support

2020-02-06 Thread Nicolas Boichat
On Fri, Feb 7, 2020 at 10:04 AM Nicolas Boichat wrote: > > Hi Ulf, > > On Mon, Jan 27, 2020 at 3:55 PM Ulf Hansson wrote: > > > > On Fri, 10 Jan 2020 at 02:53, Nicolas Boichat wrote: > > > > > > +Ulf to keep me honest on the power domains > > > > > > On Thu, Jan 9, 2020 at 10:08 PM Steven Price

Re: [PATCH v3 5/7] drm/panfrost: Add support for multiple power domains

2020-02-06 Thread Nicolas Boichat
On Mon, Jan 20, 2020 at 10:53 PM Steven Price wrote: > > On 14/01/2020 07:16, Nicolas Boichat wrote: > [snip] > > > > + err = panfrost_pm_domain_init(pfdev); > > + if (err) { > > + dev_err(pfdev->dev, "pm_domain init failed %d\n", err); > > No need for this print - panfrost_pm_

[git pull] drm fixes for 5.6-rc1

2020-02-06 Thread Dave Airlie
Hi Linus, Just some fixes on top of the merge windows pull, the tegra changes fix some regressions in the merge, nouveau has a few modesetting fixes. The amdgpu fixes are bit bigger, but they contain a couple of weeks of fixes, and doesn't seem to contain anything that isn't really a fix. Regards

[PATCH v4 6/7] RFC: drm/panfrost: Add mt8183-mali compatible string

2020-02-06 Thread Nicolas Boichat
For testing only, the driver doesn't really work yet, AFAICT. Signed-off-by: Nicolas Boichat --- v4: - Add power domain names. v3: - Match mt8183-mali instead of bifrost, as we require special handling for the 2 regulators and 3 power domains. drivers/gpu/drm/panfrost/panfrost_drv.c | 11

[PATCH v4 5/7] drm/panfrost: Add support for multiple power domains

2020-02-06 Thread Nicolas Boichat
When there is a single power domain per device, the core will ensure the power domain is switched on (so it is technically equivalent to having not power domain specified at all). However, when there are multiple domains, as in MT8183 Bifrost GPU, we need to handle them in driver code. Signed-off

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

2020-02-06 Thread Nicolas Boichat
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 the binding is indeed correct. The rest of the patches are RFC/work-in-pr

[PATCH v4 2/7] arm64: dts: mt8183: Add node for the Mali GPU

2020-02-06 Thread Nicolas Boichat
Add a basic GPU node for mt8183. Signed-off-by: Nicolas Boichat Reviewed-by: Alyssa Rosenzweig --- Upstreaming what matches existing bindings from our Chromium OS tree: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/arch/arm64/boot/dts/mediatek/mt8183.dtsi#1348

[PATCH v4 3/7] drm/panfrost: Improve error reporting in panfrost_gpu_power_on

2020-02-06 Thread Nicolas Boichat
It is useful to know which component cannot be powered on. Signed-off-by: Nicolas Boichat Reviewed-by: Steven Price Reviewed-by: Alyssa Rosenzweig --- Was useful when trying to probe Bifrost GPU, to understand what issue we are facing. v4: - No change v3: - Rebased on https://patchwork.kern

[PATCH v4 7/7] RFC: drm/panfrost: devfreq: Add support for 2 regulators

2020-02-06 Thread Nicolas Boichat
The Bifrost GPU on MT8183 uses 2 regulators (core and SRAM) for devfreq, and provides OPP table with 2 sets of voltages. TODO: This is incomplete as we'll need add support for setting a pair of voltages as well. Signed-off-by: Nicolas Boichat --- drivers/gpu/drm/panfrost/panfrost_devfreq.c | 1

[PATCH v4 4/7] drm/panfrost: Add support for multiple regulators

2020-02-06 Thread Nicolas Boichat
Some GPUs, namely, the bifrost/g72 part on MT8183, have a second regulator for their SRAM, let's add support for that. We extend the framework in a generic manner so that we could support more than 2 regulators, if required. Signed-off-by: Nicolas Boichat --- v4: - nits: Run through latest ve

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

2020-02-06 Thread Nicolas Boichat
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 Alyssa's reviewed-by as the change is minor) v3: - No change .../bindings/gpu/arm,mali-bif

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

2020-02-06 Thread Tomeu Vizoso
On 2/7/20 6:26 AM, 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 the binding is indeed correct

Re: [PATCH] drm/virtio: fix ring free check

2020-02-06 Thread Gerd Hoffmann
Hi, > > + indirect = virtio_has_feature(vgdev->vdev, > > VIRTIO_RING_F_INDIRECT_DESC); > > + vqcnt = indirect ? 1 : elemcnt; > Is the feature dynamic and require the lock held? If not, the result > can be cached and the fixup can happen before grabbing the lock Not dynamic, so yes

[PATCH v2] drm/virtio: fix ring free check

2020-02-06 Thread Gerd Hoffmann
If the virtio device supports indirect ring descriptors we need only one ring entry for the whole command. Take that into account when checking whenever the virtqueue has enough free entries for our command. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_drv.h | 1 + driver

Re: [PATCH v2] drm/virtio: fix ring free check

2020-02-06 Thread Chia-I Wu
On Thu, Feb 6, 2020 at 10:47 PM Gerd Hoffmann wrote: > > If the virtio device supports indirect ring descriptors we need only one > ring entry for the whole command. Take that into account when checking > whenever the virtqueue has enough free entries for our command. > > Signed-off-by: Gerd Hoff

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

2020-02-06 Thread Nicolas Boichat
On Fri, Feb 7, 2020 at 2:18 PM Tomeu Vizoso wrote: > > On 2/7/20 6:26 AM, 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 se

[PATCH v2 0/4] drm/virtio: rework backing storage handling

2020-02-06 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann Gerd Hoffmann (4): drm/virtio: simplify virtio_gpu_alloc_cmd drm/virtio: resource teardown tweaks drm/virtio: move mapping teardown to virtio_gpu_cleanup_object() drm/virtio: move virtio_gpu_mem_entry initialization to new function drivers/gpu/drm/virtio/vir

[PATCH v2 2/4] drm/virtio: resource teardown tweaks

2020-02-06 Thread Gerd Hoffmann
Add new virtio_gpu_cleanup_object() helper function for object cleanup. Wire up callback function for resource unref, do cleanup from callback when we know the host stopped using the resource. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_drv.h| 4 +++- drivers/gpu/drm/vir

[PATCH v2 3/4] drm/virtio: move mapping teardown to virtio_gpu_cleanup_object()

2020-02-06 Thread Gerd Hoffmann
Stop sending DETACH_BACKING commands, that will happening anyway when releasing resources via UNREF. Handle guest-side cleanup in virtio_gpu_cleanup_object(), called when the host finished processing the UNREF command. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_drv.h|

[PATCH v2 1/4] drm/virtio: simplify virtio_gpu_alloc_cmd

2020-02-06 Thread Gerd Hoffmann
Just call virtio_gpu_alloc_cmd_resp with some fixed args instead of duplicating most of the function body. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_vq.c | 26 +- 1 file changed, 9 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/virtio/v

[PATCH v2 4/4] drm/virtio: move virtio_gpu_mem_entry initialization to new function

2020-02-06 Thread Gerd Hoffmann
Introduce new virtio_gpu_object_shmem_init() helper function which will create the virtio_gpu_mem_entry array, containing the backing storage information for the host. For the most path this just moves code from virtio_gpu_object_attach(). Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio

Re: [PATCH 1/3] fbdev/g364fb: Fix build failure

2020-02-06 Thread Philippe Mathieu-Daudé
On Sun, Feb 2, 2020 at 3:41 AM Finn Thain wrote: > > This patch resolves these compiler errors and warnings -- > > CC drivers/video/fbdev/g364fb.o > drivers/video/fbdev/g364fb.c: In function 'g364fb_cursor': > drivers/video/fbdev/g364fb.c:137:9: error: 'x' undeclared (first use in this > f

Re: [PATCH 0/3] drm/tegra: A couple of fixes for v5.6-rc1

2020-02-06 Thread Dmitry Osipenko
04.02.2020 16:59, Thierry Reding пишет: > From: Thierry Reding > > Hi, > > this contains a couple of fixes for a DMA API performance regression > that was introduced in v5.5 for older Tegra devices. Patches 1 and 2 > will likely have to be backported to v5.5. > > Thierry > > Thierry Reding (3)

Re: [PATCH 1/3] drm/tegra: Relax IOMMU usage criteria on old Tegra

2020-02-06 Thread Dmitry Osipenko
04.02.2020 16:59, Thierry Reding пишет: > From: Thierry Reding > > Older Tegra devices only allow addressing 32 bits of memory, so whether > or not the host1x is attached to an IOMMU doesn't matter. host1x IOMMU > attachment is only needed on devices that can address memory beyond the > 32-bit bo

[PATCH v2 09/12] drm/i915/dp_mst: convert to drm_device based logging macros.

2020-02-06 Thread Wambui Karuga
Conversion of instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_dp_mst.c. This also involves extracting the drm_i915_private device pointer from various intel types to use in the macros. Signed-off-by: Wambui Karuga --- drivers/g

[PATCH v2 11/12] drm/i915/hdmi: convert to struct drm_device based logging macros.

2020-02-06 Thread Wambui Karuga
Conversion of various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_hdmi.c. This also involves extraction of the drm_i915_private device from various intel/drm types for use in the logging macros. Note that this converts DRM_DE

[PATCH v2 01/12] drm/i915/dp: convert to struct drm_device based logging macros.

2020-02-06 Thread Wambui Karuga
Converts various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_dp.c. This also involves extracting the struct drm_i915_private device pointer from various intel types to be used in the macros. Signed-off-by: Wambui Karuga ---

[PATCH v2 08/12] drm/i915/combo_phy: convert to struct drm_device logging macros.

2020-02-06 Thread Wambui Karuga
Conversion of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_combo_phy.c. This transformation was achieved using the following coccinelle script that matches based on the existence of a drm_i915_private device pointer: @@ identifier fn, T; @@

Re: [PATCH 2/3] drm/tegra: Reuse IOVA mapping where possible

2020-02-06 Thread Dmitry Osipenko
04.02.2020 16:59, Thierry Reding пишет: > - sgt = host1x_bo_pin(host->dev, g->bo, NULL); > + /** ^ Although one nit: ^ the second asterisk isn't needed :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org

Re: [PATCH 1/3] fbdev/g364fb: Fix build failure

2020-02-06 Thread Finn Thain
On Wed, 5 Feb 2020, Philippe Mathieu-Daudé wrote: > On Sun, Feb 2, 2020 at 3:41 AM Finn Thain wrote: > > > > This patch resolves these compiler errors and warnings -- > > > > CC drivers/video/fbdev/g364fb.o > > drivers/video/fbdev/g364fb.c: In function 'g364fb_cursor': > > drivers/video/fb

[PATCH v2 00/12] drm/i915/display: convert to drm_device based logging macros.

2020-02-06 Thread Wambui Karuga
This patchset continues the conversion of the printk based drm logging macros in drm/i915 to use the struct drm_device based logging macros. This series was done both using coccinelle and manually. v2: rebase onto drm-tip to fix conflicts with new changes in drm/i915. Wambui Karuga (12): drm/i9

[PATCH v2] drm: shmobile: Reduce include dependencies

2020-02-06 Thread Andy Shevchenko
This file doesn't need everything provided by . All it needs are some types, which are provided by . Note, already includes , but not relying on implicit includes is indeed a good thing. Signed-off-by: Andy Shevchenko --- v2: Update commit message (Geert, Laurent) include/linux/platform_data/s

[PATCH v2 06/12] drm/i915/dp_aux_backlight: convert to drm_device based logging macros.

2020-02-06 Thread Wambui Karuga
Conversion of the printk based drm logging macros to the struct drm_device based logging macros in display/intel_dp_aux_backlight.c. This also involves extracting the drm_i915_private device pointer from various intel types to use in the macros. Note that this converts DRM_DEBUG_DRIVER to drm_dbg(

Re: [PATCH 3/3] gpu: host1x: Set DMA direction only for DMA-mapped buffer objects

2020-02-06 Thread Dmitry Osipenko
04.02.2020 16:59, Thierry Reding пишет: > From: Thierry Reding > > The DMA direction is only used by the DMA API, so there is no use in > setting it when a buffer object isn't mapped with the DMA API. > > Signed-off-by: Thierry Reding > --- > drivers/gpu/host1x/job.c | 2 +- > 1 file changed,

Re: [PATCH] drm/panfrost: Don't try to map on error faults

2020-02-06 Thread Alyssa Rosenzweig
Reviewed-by: Alyssa Rosenzweig Although it might be nice to #define TRANSLATION_FAULT_LEVEL1 0xC1 ... #define TRANSLATION_FAULT_LEVEL4 0xC4 and then use semantic names instead of magic values. Minimally maybe add a comment explaining that. On Wed, Feb 05, 2020 at 11:07

[PATCH v2 05/12] drm/i915/crt: automatic conversion to drm_device based logging macros.

2020-02-06 Thread Wambui Karuga
Replaces various instances of the printk based logging macros with the struct drm_device based logging macros in i915/display/intel_crt.c using the following coccinelle script that matches based on the existence of a drm_i915_private device pointer: @@ identifier fn, T; @@ fn(...,struct drm_i915_p

Re: [PATCH 2/3] drm/tegra: Reuse IOVA mapping where possible

2020-02-06 Thread Dmitry Osipenko
04.02.2020 16:59, Thierry Reding пишет: > From: Thierry Reding > > This partially reverts the DMA API support that was recently merged > because it was causing performance regressions on older Tegra devices. > Unfortunately, the cache maintenance performed by dma_map_sg() and > dma_unmap_sg() cau

[PATCHv3 0/2] Add support for rm69299 Visionox panel driver and add devicetree bindings for visionox panel

2020-02-06 Thread Harigovindan P
Adding support for visionox rm69299 panel driver and adding bindings for the same panel. Harigovindan P (2): dt-bindings: display: add visionox rm69299 panel variant drm/panel: add support for rm69299 visionox panel driver .../bindings/display/visionox,rm69299.yaml | 109 ++ dri

[PATCH v2 12/12] drm/i915/dpio_phy: convert to drm_device based logging macros.

2020-02-06 Thread Wambui Karuga
Conversion of the printk based logging macros to the struct drm_device based logging macros in i915/display/intel_dpio_phy.c. This was achieved using the following coccinelle semantic patch that matches based on the existence of a drm_i915_private device: @@ identifier fn, T; @@ fn(...,struct drm_

[PATCHv3 2/2] drm/panel: add support for rm69299 visionox panel driver

2020-02-06 Thread Harigovindan P
Add support for Visionox panel driver. Signed-off-by: Harigovindan P --- Changes in v1: - Split out panel driver patch from dsi config changes(Rob Clark). - Remove unrelated code(Stephen Boyd). - Remove static arrays to make regulator setup open coded in probe(Ste

[PATCH v4 1/3] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings.

2020-02-06 Thread Yuti Amonkar
Document the bindings used for the Cadence MHDP DPI/DP bridge in yaml format. Signed-off-by: Yuti Amonkar Reviewed-by: Rob Herring --- .../bindings/display/bridge/cdns,mhdp.yaml| 125 ++ 1 file changed, 125 insertions(+) create mode 100644 Documentation/devicetree/bindings

[PATCH v2 02/12] drm/i915/dp_link_training: convert to drm_device based logging macros.

2020-02-06 Thread Wambui Karuga
Converts various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_dp_link_training.c. This also involves extracting the drm_i915_private device pointer from the intel_dp type to use in the various macros. Signed-off-by: Wambui Kar

[PATCH v4 0/3] drm: Add support for Cadence MHDP DPI/DP bridge and J721E wrapper.

2020-02-06 Thread Yuti Amonkar
This patch series adds new DRM driver for Cadence Display Port. The Cadence Display Port is also referred as MHDP (Mobile High Definition Link, High-Definition Multimedia Interface Display Port) Cadence Display Port complies with VESA DisplayPort (DP) and embedded Display Port (eDP) standards. This

[PATCHv3 1/2] dt-bindings: display: add visionox rm69299 panel variant

2020-02-06 Thread Harigovindan P
Add bindings for visionox rm69299 panel. Signed-off-by: Harigovindan P --- Changes in v1: - Added a compatible string to support sc7180 panel version. Changes in v2: - Removed unwanted properties from description. - Creating source files without execute permissions(Rob He

Re: [PATCH 1/3] drm/tegra: Relax IOMMU usage criteria on old Tegra

2020-02-06 Thread Dmitry Osipenko
04.02.2020 16:59, Thierry Reding пишет: > From: Thierry Reding > > Older Tegra devices only allow addressing 32 bits of memory, so whether > or not the host1x is attached to an IOMMU doesn't matter. host1x IOMMU > attachment is only needed on devices that can address memory beyond the > 32-bit bo

[PATCH v4 3/3] drm: bridge: cdns-mhdp: add j721e wrapper

2020-02-06 Thread Yuti Amonkar
Add j721e wrapper for mhdp, which sets up the clock and data muxes. Signed-off-by: Yuti Amonkar --- drivers/gpu/drm/bridge/Kconfig | 12 drivers/gpu/drm/bridge/Makefile | 3 + drivers/gpu/drm/bridge/cdns-mhdp-core.c | 14 + drivers/gpu/drm/bridge/cdns-mhdp-core.h |

[PATCH v2 03/12] drm/i915/atomic: conversion to drm_device based logging macros.

2020-02-06 Thread Wambui Karuga
Conversion of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_atomic.c This change was achieved using the following coccinelle script that matches based on the existence of a drm_i915_private device pointer: @@ identifier fn, T; @@ fn(...,str

[PATCH v4 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge

2020-02-06 Thread Yuti Amonkar
This patch adds new DRM driver for Cadence MHDP DPTX IP used on J721e SoC. MHDP DPTX IP is the component that complies with VESA DisplayPort (DP) and embedded Display Port (eDP) standards. It integrates uCPU running the embedded Firmware(FW) interfaced over APB interface. Basically, it takes a DPI

Re: [PATCH 1/3] fbdev/g364fb: Fix build failure

2020-02-06 Thread Philippe Mathieu-Daudé
On 2/5/20 7:02 PM, Philippe Mathieu-Daudé wrote: > On Sun, Feb 2, 2020 at 3:41 AM Finn Thain wrote: >> >> This patch resolves these compiler errors and warnings -- >> >> CC drivers/video/fbdev/g364fb.o >> drivers/video/fbdev/g364fb.c: In function 'g364fb_cursor': >> drivers/video/fbdev/g364

[PATCH v2 07/12] drm/i915/dpll_mgr: convert to drm_device based logging macros.

2020-02-06 Thread Wambui Karuga
Conversion of instances of printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_dpll_mgr.c. This also involves extracting the struct drm_i915_private device pointer from various intel types to use in the drm_device based macros. Note that this convert

[PATCH v2 04/12] drm/i915/color: conversion to drm_device based logging macros.

2020-02-06 Thread Wambui Karuga
Initial conversion of the straightforward printk based logging macros to the struct drm_device based logging macros in i915/display/intel_color.c. Signed-off-by: Wambui Karuga --- drivers/gpu/drm/i915/display/intel_color.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dri

Re: [PATCH 1/3] fbdev/g364fb: Fix build failure

2020-02-06 Thread Finn Thain
On Wed, 5 Feb 2020, Philippe Mathieu-Daudé wrote: > Note, you need to rebase your series due to: > > commit 8a48ac339398f21282985bff16552447d41dcfb2 > Author: Jani Nikula > Date: Tue Dec 3 18:38:50 2019 +0200 > > video: constify fb ops across all drivers > OK. Thanks for your r

Re: [PATCH 3/3] gpu: host1x: Set DMA direction only for DMA-mapped buffer objects

2020-02-06 Thread Dmitry Osipenko
04.02.2020 16:59, Thierry Reding пишет: > From: Thierry Reding > > The DMA direction is only used by the DMA API, so there is no use in > setting it when a buffer object isn't mapped with the DMA API. > > Signed-off-by: Thierry Reding > --- > drivers/gpu/host1x/job.c | 2 +- > 1 file changed,

Re: [PATCH 2/3] drm/tegra: Reuse IOVA mapping where possible

2020-02-06 Thread Dmitry Osipenko
04.02.2020 16:59, Thierry Reding пишет: > From: Thierry Reding > > This partially reverts the DMA API support that was recently merged > because it was causing performance regressions on older Tegra devices. > Unfortunately, the cache maintenance performed by dma_map_sg() and > dma_unmap_sg() cau

[PATCH v2 10/12] drm/i915/dsi_vbt: convert to drm_device based logging macros.

2020-02-06 Thread Wambui Karuga
Convert various instances of the printk based drm logging macros to the struct drm_device based logging macros in i915/display/intel_dsi_vbt.c. This also involves extracting the drm_i915_private device from the intel_dsi type for use in the logging macros. This converts DRM_DEBUG/DRM_DEBUG_DRIVER

Re: [PATCH 4/4] drm/virtio: move virtio_gpu_mem_entry initialization to new function

2020-02-06 Thread Gerd Hoffmann
Hi, > > virtio_gpu_cmd_resource_attach_backing(vgdev, obj->hw_res_handle, > > - ents, nents, > > + obj->ents, obj->nents, > >fence); > > + obj->

Re: [PATCH 09/11] drm/virtio: avoid an infinite loop

2020-02-06 Thread Gerd Hoffmann
On Wed, Feb 05, 2020 at 10:19:53AM -0800, Chia-I Wu wrote: > Make sure elemcnt does not exceed the maximum element count in > virtio_gpu_queue_ctrl_sgs. We should improve our error handling or > impose a size limit on execbuffer, which are TODOs. Hmm, virtio supports indirect ring entries, so lar

[PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer

2020-02-06 Thread Thomas Zimmermann
After its cleanup, struct nouveau_framebuffer is only a wrapper around struct drm_framebuffer. Use the latter directly. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 26 +++ drivers/gpu/drm/nouveau/nouveau_display.c | 14 ++-- driver

[PATCH 1/4] drm/nouveau: Remove unused fields from struct nouveau_framebuffer

2020-02-06 Thread Thomas Zimmermann
Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/nouveau/nouveau_display.h | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.h b/drivers/gpu/drm/nouveau/nouveau_display.h index 6e8e66882e45..e397b3d246e5 100644 --- a/drivers/gpu/drm/nouveau/nouve

[PATCH 3/4] drm/nouveau: Remove field nvbo from struct nouveau_framebuffer

2020-02-06 Thread Thomas Zimmermann
The buffer object stored in nvbo is also available GEM object in obj[0] of struct drm_framebuffer. Therefore remove nvbo in favor obj[0] and replace all references accordingly. This may require an additional cast. With this change we can already replace nouveau_user_framebuffer_destroy() and nouve

[PATCH 2/4] drm/nouveau: Move struct nouveau_framebuffer.vma to struct nouveau_fbdev

2020-02-06 Thread Thomas Zimmermann
The vma field of struct nouveau_framebuffer is a special field for the the accelerated fbdev console. Hence there's at most one single instance for the active console. Moving it into struct nouveau_fbdev makes struct nouveau_framebuffer slightly smaller and brings it closer to struct drm_framebuffe

[PATCH 0/4] drm/nouveau: Remove struct nouveau_framebuffer

2020-02-06 Thread Thomas Zimmermann
All fields in struct nouveau_framebuffer appear to be obsolete. The data structure can be replaced by struct drm_framebuffer entirely. Patch 1 removes several unused fields from struct nouveau_framebuffer. Patch 2 moves the field vma to struct nouveau_fbdev. The information in vma is only relevan

[PATCH v3] drm/hdcp: optimizing the srm handling

2020-02-06 Thread Ramalingam C
As we are not using the sysfs infrastructure anymore, link to it is removed. And global srm data and mutex to protect it are removed, with required handling at revocation check function. v2: srm_data is dropped and few more comments are addressed. v3: ptr passing around is fixed with functiona

Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

2020-02-06 Thread Lucas Stach
Hi all, On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote: > Hi Andrey, > > This commit breaks all drivers, which may bail out of the timeout > processing as they wish to extend the timeout (etnaviv, v3d). > > Those drivers currently just return from the timeout handler before > calling drm_sc

[PATCH] drm/virtio: fix ring free check

2020-02-06 Thread Gerd Hoffmann
If the virtio device supports indirect ring descriptors we need only one ring entry for the whole command. Take that into account when checking whenever the virtqueue has enough free entries for our command. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/virtio/virtgpu_vq.c | 9 ++--- 1 f

Re: [PATCH 00/11] drm/virtio: fixes and cleanups for vbuf queuing

2020-02-06 Thread Gerd Hoffmann
On Wed, Feb 05, 2020 at 10:19:44AM -0800, Chia-I Wu wrote: > This series consists of fixes and cleanups for > virtio_gpu_queue_fenced_ctrl_buffer, except for the last patch. The fixes are > for corner cases that were overlooked. The cleanups make the last patch > easier, but they should be good i

Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

2020-02-06 Thread Christian König
Am 06.02.20 um 12:10 schrieb Lucas Stach: Hi all, On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote: Hi Andrey, This commit breaks all drivers, which may bail out of the timeout processing as they wish to extend the timeout (etnaviv, v3d). Those drivers currently just return from the timeou

Re: [PATCH] drm/mediatek: Ensure the cursor plane is on top of other overlays

2020-02-06 Thread Sean Paul
On Thu, Feb 06, 2020 at 05:59:51PM +1100, evanb...@google.com wrote: > From: Sean Paul > > Currently the cursor is placed on the first overlay plane, which means > it will be at the bottom of the stack when the hw does the compositing > with anything other than primary plane. Since mtk doesn't su

[PATCH] drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context

2020-02-06 Thread Boris Brezillon
We need to use the AS attached to the opened FD when dumping counters. Reported-by: Antonio Caggiano Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces") Cc: Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panfrost/panfrost_mmu.c | 7 ++- drivers/gpu/drm/panfrost/p

[Bug 206441] New: kernel crash when amdgpu reset while very high loading

2020-02-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206441 Bug ID: 206441 Summary: kernel crash when amdgpu reset while very high loading Product: Drivers Version: 2.5 Kernel Version: 5.3.15 Hardware: All OS: Linux Tr

Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

2020-02-06 Thread Alex Deucher
On Thu, Feb 6, 2020 at 6:50 AM Christian König wrote: > > Am 06.02.20 um 12:10 schrieb Lucas Stach: > > Hi all, > > > > On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote: > >> Hi Andrey, > >> > >> This commit breaks all drivers, which may bail out of the timeout > >> processing as they wish to e

Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

2020-02-06 Thread Christian König
Am 06.02.20 um 15:49 schrieb Alex Deucher: On Thu, Feb 6, 2020 at 6:50 AM Christian König wrote: Am 06.02.20 um 12:10 schrieb Lucas Stach: Hi all, On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote: Hi Andrey, This commit breaks all drivers, which may bail out of the timeout processing as

Re: [PATCH] drm/panfrost: perfcnt: Reserve/use the AS attached to the perfcnt MMU context

2020-02-06 Thread Steven Price
On 06/02/2020 14:13, Boris Brezillon wrote: > We need to use the AS attached to the opened FD when dumping counters. Indeed we do! Reviewed-by: Steven Price > > Reported-by: Antonio Caggiano > Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces") > Cc: > Signed-off-by: Boris

Re: [Nouveau] [PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer

2020-02-06 Thread James Jones
Note I'm adding some fields to nouveau_framebuffer in the series "drm/nouveau: Support NVIDIA format modifiers." I sent out v3 of that yesterday. It would probably still be possible to avoid them by re-extracting the relevant data from the format modifier on the fly when needed, but it is sim

Re: [Nouveau] [PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer

2020-02-06 Thread Thomas Zimmermann
Hi James Am 06.02.20 um 16:17 schrieb James Jones: > Note I'm adding some fields to nouveau_framebuffer in the series > "drm/nouveau: Support NVIDIA format modifiers."  I sent out v3 of that > yesterday.  It would probably still be possible to avoid them by > re-extracting the relevant data from t

Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

2020-02-06 Thread Andrey Grodzovsky
On 2/6/20 9:51 AM, Christian König wrote: Am 06.02.20 um 15:49 schrieb Alex Deucher: On Thu, Feb 6, 2020 at 6:50 AM Christian König wrote: Am 06.02.20 um 12:10 schrieb Lucas Stach: Hi all, On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote: Hi Andrey, This commit breaks all drivers, whic

Re: [Nouveau] [PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer

2020-02-06 Thread James Jones
Yes, that's certainly viable. If that's the general preference in direction, I'll rework that patches to do so. Thanks, -James On 2/6/20 7:49 AM, Thomas Zimmermann wrote: Hi James Am 06.02.20 um 16:17 schrieb James Jones: Note I'm adding some fields to nouveau_framebuffer in the series "drm

Re: [PATCH v3] drm/msm: Add syncobj support.

2020-02-06 Thread Bas Nieuwenhuizen
Hi, I'd appreciate if you could take a look at this patch. I believe I have accommodated the earlier review comments. Thank you, Bas On Fri, Jan 24, 2020 at 12:58 AM Bas Nieuwenhuizen wrote: > > This > > 1) Enables core DRM syncobj support. > 2) Adds options to the submission ioctl to wait/sign

Re: [Nouveau] [PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer

2020-02-06 Thread James Jones
Yes, that's certainly viable. If that's the general preference in direction, I'll rework that patches to do so. Thanks, -James On 2/6/20 7:49 AM, Thomas Zimmermann wrote: Hi James Am 06.02.20 um 16:17 schrieb James Jones: Note I'm adding some fields to nouveau_framebuffer in the series "drm

[GIT PULL] drm/tegra: Fixes for v5.6-rc1

2020-02-06 Thread Thierry Reding
Hi Dave, The following changes since commit 033ccdb7f6b11701623507339646013b4ce389d3: gpu: host1x: Remove dev_err() on platform_get_irq() failure (2020-01-10 17:05:12 +0100) are available in the Git repository at: git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-5.6-rc1-fixes

Re: [PATCH v4 libdrm 2/2] Add drmModeGetFB2

2020-02-06 Thread Li, Juston
On Wed, 2020-02-05 at 23:27 +, Eric Engestrom wrote: > On Wednesday, 2020-02-05 23:10:21 +, Li, Juston wrote: > > On Wed, 2020-02-05 at 22:25 +, Eric Engestrom wrote: > > > On Friday, 2020-01-31 13:41:09 -0800, Juston Li wrote: > > > > From: Daniel Stone > > > > > > > > Add a wrapper

[Bug 206225] nouveau: Screen distortion and lockup on resume

2020-02-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=206225 --- Comment #12 from Christoph Marz (derchiller-fo...@online.de) --- Follow-up: After a dist-upgrade, the error returned. I deleted the video acceleration firmware and it was ok again. When I installed 5.4.14, there were warnings about possibly

Re: [PATCH] drm/vgem: Close use-after-free race in vgem_gem_create

2020-02-06 Thread Daniel Vetter
On Sun, Feb 02, 2020 at 05:37:31PM +, Chris Wilson wrote: > Quoting Daniel Vetter (2020-02-02 13:21:33) > > There's two references floating around here (for the object reference, > > not the handle_count reference, that's a different thing): > > > > - The temporary reference held by vgem_gem_c

Re: [PATCH 09/11] drm/virtio: avoid an infinite loop

2020-02-06 Thread Chia-I Wu
On Thu, Feb 6, 2020 at 1:49 AM Gerd Hoffmann wrote: > > On Wed, Feb 05, 2020 at 10:19:53AM -0800, Chia-I Wu wrote: > > Make sure elemcnt does not exceed the maximum element count in > > virtio_gpu_queue_ctrl_sgs. We should improve our error handling or > > impose a size limit on execbuffer, which

Re: [PATCH] drm/virtio: fix ring free check

2020-02-06 Thread Chia-I Wu
On Thu, Feb 6, 2020 at 3:14 AM Gerd Hoffmann wrote: > > If the virtio device supports indirect ring descriptors we need only one > ring entry for the whole command. Take that into account when checking > whenever the virtqueue has enough free entries for our command. > > Signed-off-by: Gerd Hoffm

Re: [PATCH 2/4] drm/virtio: resource teardown tweaks

2020-02-06 Thread Chia-I Wu
On Wed, Feb 5, 2020 at 10:43 PM Gerd Hoffmann wrote: > > > > - > > > - drm_gem_shmem_free_object(obj); > > > + if (bo->created) { > > > + virtio_gpu_cmd_unref_resource(vgdev, bo); > > > + /* completion handler calls virtio_gpu_cleanup_object() */ > > nitpick

Re: [PATCH 4/4] drm/virtio: move virtio_gpu_mem_entry initialization to new function

2020-02-06 Thread Chia-I Wu
On Thu, Feb 6, 2020 at 12:55 AM Gerd Hoffmann wrote: > > Hi, > > > > virtio_gpu_cmd_resource_attach_backing(vgdev, obj->hw_res_handle, > > > - ents, nents, > > > + obj->ents, obj->nents, > > >

Re: [PATCH v2] drm/msm: Fix a6xx GMU shutdown sequence

2020-02-06 Thread Doug Anderson
Hi, On Wed, Feb 5, 2020 at 1:00 PM Rob Clark wrote: > > On Wed, Feb 5, 2020 at 12:48 PM Jordan Crouse wrote: > > > > Commit e812744c5f95 ("drm: msm: a6xx: Add support for A618") missed > > updating the VBIF flush in a6xx_gmu_shutdown and instead > > inserted the new sequence into a6xx_pm_suspend

  1   2   >