Re: [PATCH v7 0/2] Add initial support for slimport anx7625

On Tue, Feb 25, 2020 at 02:11:39PM +0800, Xin Ji wrote: > Hi all, > > The following series add initial support for the Slimport ANX7625 > transmitter, a > ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable > device. > > This is the initial version, any mistakes, please let

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

Hi Am 23.02.20 um 05:26 schrieb tang pengchuan: > > > On Sun, Feb 23, 2020 at 5:27 AM Sam Ravnborg > wrote: > > Hi Kevin/tang. > > Thanks for the quick and detailed feedback. > Your questions are addressed below. > >         Sam > > > > > >

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

Hi, Jitao: On Tue, 2020-02-25 at 14:46 +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 | 33

Re: [Intel-gfx] [RFC][PATCH 5/5] drm/i915/display: Add Nearest-neighbor based integer scaling support

Hi, On Tue, 25 Feb 2020 at 07:17, Pankaj Bharadiya wrote: > @@ -415,18 +415,26 @@ skl_program_scaler(struct intel_plane *plane, > u16 y_vphase, uv_rgb_vphase; > int hscale, vscale; > const struct drm_plane_state *state = _state->uapi; > + u32 src_w =

Re: [PATCH v2] drm/hisilicon: Fixed pcie resource conflict between drm and firmware

Hi Am 24.02.20 um 07:01 schrieb Tian Tao: > use the drm_fb_helper_remove_conflicting_pci_framebuffer to remove > the framebuffer initialized by fireware/bootloader to avoid resource > conflict. > > Signed-off-by: Tian Tao > > --- > v2: use the general API to remove the conflict resource

Re: [PATCH v7 1/4] dt-bindings: display: mediatek: update dpi supported chips

Hi, Jitao: On Tue, 2020-02-25 at 14:46 +0800, Jitao Shi wrote: > Add decriptions about supported chips, including MT2701 & MT8173 & > mt8183 descriptions > > 1. Add more chips support. ex. MT2701 & MT8173 & MT8183 > 2. Add property "pinctrl-names" to swap pin mode between gpio and dpi mode. >

[RFC][PATCH 5/5] drm/i915/display: Add Nearest-neighbor based integer scaling support

Integer scaling (IS) is a nearest-neighbor upscaling technique that simply scales up the existing pixels by an integer (i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest

[RFC][PATCH 2/5] drm/drm-kms.rst: Add Scaling filter property documentation

Add documentation for newly introduced KMS scaling filter property. Signed-off-by: Pankaj Bharadiya --- Documentation/gpu/drm-kms.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 906771e03103..7b71a1e3edda 100644

[RFC][PATCH 3/5] drm/i915: Enable scaling filter for plane and pipe

Attach scaling filter property for crtc and plane and program the scaler control register for the selected filter type. This is preparatory patch to enable Nearest-neighbor integer scaling. Signed-off-by: Pankaj Bharadiya Signed-off-by: Ankit Nautiyal ---

[RFC][PATCH 1/5] drm: Introduce scaling filter property

Introduce new scaling filter property to allow userspace to select the driver's default scaling filter or Nearest-neighbor(NN) filter for upscaling operations on crtc/plane. Drivers can set up this property for a plane by calling drm_plane_enable_scaling_filter() and for a CRTC by calling

[RFC][PATCH 4/5] drm/i915: Introduce scaling filter related registers and bit fields.

Introduce scaler registers and bit fields needed to configure the scaling filter in prgrammed mode and configure scaling filter coefficients. Signed-off-by: Pankaj Bharadiya Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/i915_reg.h | 20 1 file changed, 20

[RFC][PATCH 0/5] Introduce drm scaling filter property

Integer scaling (IS) is a nearest-neighbor upscaling technique that simply scales up the existing pixels by an integer (i.e., whole number) multiplier. Nearest-neighbor (NN) interpolation works by filling in the missing color values in the upscaled image with that of the coordinate-mapped nearest

[PATCH v7 3/4] drm/mediatek: add mt8183 dpi clock factor

The factor depends on the divider of DPI in MT8183, therefore, we should fix this factor to the right and new one. Signed-off-by: Jitao Shi Reviewed-by: CK Hu --- drivers/gpu/drm/mediatek/mtk_dpi.c | 18 ++ 1 file changed, 18 insertions(+) diff --git

[PATCH v7 1/4] dt-bindings: display: mediatek: update dpi supported chips

Add decriptions about supported chips, including MT2701 & MT8173 & mt8183 1. Add more chips support. ex. MT2701 & MT8173 & MT8183 2. 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. 3. Add

[PATCH v7 4/4] 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 | 33 -- 1 file changed, 31 insertions(+), 2 deletions(-) diff --git

[PATCH v7 0/4] add mt8183 dpi driver

Changes since v6: - change dual_edge to pclk-sample - remove dpi_pin_mode_swap and Changes since v5: - fine tune the dt-bindings commit message. Changes since v4: - move pin mode control and dual edge control to deveice tree. - update dt-bindings document for pin mode swap and dual edge

[PATCH v7 2/4] 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. Signed-off-by: Jitao Shi --- drivers/gpu/drm/mediatek/mtk_dpi.c | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git

Re: [PATCH 2/2] drm/virtio: Support virtgpu exported resources

Hi, > +struct dma_buf *virtgpu_gem_prime_export(struct drm_gem_object *obj, > + int flags) > +{ [ ... ] > +} > + > +struct drm_gem_object *virtgpu_gem_prime_import(struct drm_device *dev, > + struct dma_buf *buf) >

Re: [PATCH v10 08/12] drm/bridge: lvds-codec: Implement basic bus format negotiation

Hi Boris/Laurent. > > + > > + err = of_property_read_u32(np, "bus-width", _bus_width); > > + of_node_put(np); > > + > > + if (err) { > > + lvds_codec->input_fmt = MEDIA_BUS_FMT_FIXED; > > + } else if (input_bus_width == 18) { > > + lvds_codec->input_fmt =

Re: [PATCH 1/2] virtio: add dma-buf support for exported objects

On Wed, Feb 19, 2020 at 05:06:36PM +0900, David Stevens wrote: > This change adds a new flavor of dma-bufs that can be used by virtio > drivers to share exported objects. A virtio dma-buf can be queried by > virtio drivers to obtain the UUID which identifies the underlying > exported object. That

Re: [PATCH] drm/mediatek: component type MTK_DISP_OVL_2L is not correctly handled

Hi, Phong: On Thu, 2020-02-20 at 09:36 +0800, CK Hu wrote: > Hi, Phong: > > On Wed, 2020-02-19 at 15:13 +0100, Phong LE wrote: > > The larb device remains NULL if the type is MTK_DISP_OVL_2L. > > A kernel panic is raised when a crtc uses mtk_smi_larb_get or > > mtk_smi_larb_put. > > > >

[Bug 204241] amdgpu fails to resume from suspend

https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #53 from Alexander Jones (acjon...@hawaii.edu) --- (In reply to dimitris from comment #52) > This is a shot in the dark/cargo culting it, but in case it helps: > > I had a very similar problem on a T495 (Ryzen 3700U), running Fedora

Re: [PATCH v6 1/4] dt-bindings: display: mediatek: update dpi supported chips

On Tue, 2020-02-25 at 10:13 +0800, CK Hu wrote: > Hi, Jitao: > > On Tue, 2020-02-25 at 10:05 +0800, Jitao Shi wrote: > > On Mon, 2020-02-24 at 16:46 +0800, CK Hu wrote: > > > Hi, Jitao: > > > > > > On Fri, 2020-02-21 at 19:28 +0800, Jitao Shi wrote: > > > > Add decriptions about supported chips,

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

Hi, On Mon, Feb 24, 2020 at 04:10:11PM -0800, Tony Lindgren wrote: > * Sebastian Reichel [200224 23:22]: > > This updates the existing omapdrm DSI code, so that it uses > > common drm_mipi_dsi API and drm_panel. > > > > The patchset has been tested with Droid 4 using Linux console, X.org and >

Re: [PATCH v6 1/4] dt-bindings: display: mediatek: update dpi supported chips

On Mon, 2020-02-24 at 16:46 +0800, CK Hu wrote: > Hi, Jitao: > > On Fri, 2020-02-21 at 19:28 +0800, Jitao Shi wrote: > > Add decriptions about supported chips, including MT2701 & MT8173 & > > mt8183 > > > > 1. Add more chips support. ex. MT2701 & MT8173 & MT8183 > > 2. Add property

Re: [PATCH v6 1/4] dt-bindings: display: mediatek: update dpi supported chips

Hi, Jitao: On Tue, 2020-02-25 at 10:05 +0800, Jitao Shi wrote: > On Mon, 2020-02-24 at 16:46 +0800, CK Hu wrote: > > Hi, Jitao: > > > > On Fri, 2020-02-21 at 19:28 +0800, Jitao Shi wrote: > > > Add decriptions about supported chips, including MT2701 & MT8173 & > > > mt8183 > > > > > > 1. Add

Re: [PATCH v6 1/4] dt-bindings: display: mediatek: update dpi supported chips

On Mon, 2020-02-24 at 15:50 +0800, CK Hu wrote: > Hi, Jitao: > > On Fri, 2020-02-21 at 19:28 +0800, Jitao Shi wrote: > > Add decriptions about supported chips, including MT2701 & MT8173 & > > mt8183 > > > > 1. Add more chips support. ex. MT2701 & MT8173 & MT8183 > > 2. Add property

[Bug 204241] amdgpu fails to resume from suspend

https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #52 from dimit...@gmail.com --- This is a shot in the dark/cargo culting it, but in case it helps: I had a very similar problem on a T495 (Ryzen 3700U), running Fedora 31, which resolved itself when the 5.4 series was available in

RE: [RFC PATCH 0/3] KVM: x86: honor guest memory type

> From: Chia-I Wu > Sent: Saturday, February 22, 2020 2:21 AM > > On Fri, Feb 21, 2020 at 7:59 AM Sean Christopherson > wrote: > > > > On Thu, Feb 20, 2020 at 09:39:05PM -0800, Tian, Kevin wrote: > > > > From: Chia-I Wu > > > > Sent: Friday, February 21, 2020 12:51 PM > > > > If you think it

[Bug 204241] amdgpu fails to resume from suspend

https://bugzilla.kernel.org/show_bug.cgi?id=204241 --- Comment #51 from Alexander Jones (acjon...@hawaii.edu) --- For what it's worth, I believe I might be suffering from this bug. I have a ThinkPad A275, with an AMD A12 9800B CPU and an R7 integrated GPU, and I can reliably produce a crash on

Re: [PATCH 02/12] drm/exynos: Use mode->clock instead of reverse calculating it from the vrefresh

20. 2. 20. 오후 7:56에 Emil Velikov 이(가) 쓴 글: > On Wed, 19 Feb 2020 at 20:36, Ville Syrjala > wrote: >> >> From: Ville Syrjälä >> >> htotal*vtotal*vrefresh ~= clock. So just use say "clock" when we mean it. >> >> Cc: Inki Dae >> Cc: Joonyoung Shim >> Cc: Seung-Woo Kim >> Cc: Kyungmin Park >>

Re: [PATCH v3 3/7] drm/exynos: Use drm_encoder_mask()

20. 2. 17. 오전 11:27에 Inki Dae 이(가) 쓴 글: > > > 20. 2. 12. 오전 1:22에 Ville Syrjala 이(가) 쓴 글: >> From: Ville Syrjälä >> >> Replace the hand rolled encoder bitmask thing with drm_encoder_mask() >> >> Cc: Inki Dae >> Cc: Joonyoung Shim >> Cc: Seung-Woo Kim >> Cc: Kyungmin Park >> Acked-by:

[PATCH v7 3/4] drm/virtio: track whether or not a context has been initiated

Use an boolean variable to track whether a context has been initiated. v5: Fix possible race and sleep via mutex (olv) Reviewed-by: Chia-I Wu Reviewed-by: Emil Velikov Signed-off-by: Gurchetan Singh --- drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++ drivers/gpu/drm/virtio/virtgpu_ioctl.c | 8

[PATCH v7 2/4] drm/virtio: factor out context create hypercall

We currently create an OpenGL context when opening the DRM fd if 3D is available. We may need other context types (VK,..) in the future, and the plan is to have explicit initialization for that. For explicit initialization to work, we need to factor out virtio_gpu_create_context from driver

[PATCH v7 1/4] drm/virtio: use consistent names for drm_files

Minor cleanup, change: - file_priv--> file, - drm_file --> file. Reviewed-by: Chia-I Wu Reviewed-by: Emil Velikov Signed-off-by: Gurchetan Singh --- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git

[PATCH v7 4/4] drm/virtio: enqueue virtio_gpu_create_context after the first 3D ioctl

For old userspace, initialization will still be implicit. For backwards compatibility, enqueue virtio_gpu_cmd_context_create after the first 3D ioctl. v3: staticify virtio_gpu_create_context remove notify to batch vm-exit v6: Remove nested 3D checks (emil.velikov): - unify 3D check in

Re: [PATCHv2 01/56] ARM: dts: omap: add channel to DSI panels

Hi Laurent, On Tue, Feb 25, 2020 at 01:38:21AM +0200, Laurent Pinchart wrote: > Hi Sebastian, > > Thank you for the patch. > > On Tue, Feb 25, 2020 at 12:20:31AM +0100, Sebastian Reichel wrote: > > The standard binding for DSI requires, that the channel number > > of the panel is encoded in DT.

Re: [PATCHv2 02/56] ARM: dts: omap4-droid4: add panel compatible

Hi Laurent, On Tue, Feb 25, 2020 at 01:37:08AM +0200, Laurent Pinchart wrote: > Hi Sebastian, > > Thank you for the patch. Thanks for the review. > On Tue, Feb 25, 2020 at 12:20:32AM +0100, Sebastian Reichel wrote: > > Add Droid 4 specific compatible value in addition to the > > generic one,

Re: [PATCHv2 04/56] omap/drm: drop unused dsi.configure_pins

Hi Sebastian, Thank you for the patch. On Tue, Feb 25, 2020 at 12:20:34AM +0100, Sebastian Reichel wrote: > The panel-dsi-cm's ddata->pin_config is always NULL, so this > callback is never called. Instead the DSI encoder gets the pin > configuration directly from DT. > > Signed-off-by:

Re: [PATCHv2 01/56] ARM: dts: omap: add channel to DSI panels

Hi Sebastian, Thank you for the patch. On Tue, Feb 25, 2020 at 12:20:31AM +0100, Sebastian Reichel wrote: > The standard binding for DSI requires, that the channel number > of the panel is encoded in DT. This adds the channel number in > all OMAP3-5 boards, in preparation for using common

Re: [PATCHv2 02/56] ARM: dts: omap4-droid4: add panel compatible

Hi Sebastian, Thank you for the patch. On Tue, Feb 25, 2020 at 12:20:32AM +0100, Sebastian Reichel wrote: > Add Droid 4 specific compatible value in addition to the > generic one, so that we have the ability to add panel > specific quirks in the future. We need to document this compatible

Re: [PATCH 1/3] drm/omap: Prepare DSS for probing without legacy platform data

Hi, On Mon, Feb 24, 2020 at 11:12:28AM -0800, Tony Lindgren wrote: > In order to probe display subsystem (DSS) components with ti-sysc > interconnect target module without legacy platform data and using > devicetree, we need to update dss probing a bit. > > In the device tree, we will be

Re: [PATCH v10 08/12] drm/bridge: lvds-codec: Implement basic bus format negotiation

Hi Boris, Thank you for the patch. On Tue, Jan 28, 2020 at 02:55:10PM +0100, Boris Brezillon wrote: > Some DPI -> LVDS encoders might support several input bus width. Add a > DT property to describe the bus width used on a specific design. > > v10: > * Add changelog to the commit message > >

[PATCH] drm/bridge: lvds-codec: Constify the drm_bridge_funcs structure

The drm_bridge_funcs structure is never modified, make it const. Making it read-only can improve security as the structure contains function pointers. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/bridge/lvds-codec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] drm/bridge: lvds-codec: Add to_lvds_codec() functino

Factor out the manual container_of() uses to a common to_lvds_codec() macro to shorten lines (and provide better type safety, although that won't matter much in this case). Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/bridge/lvds-codec.c | 14 -- 1 file changed, 8

Re: [PATCH v10 10/12] drm/bridge: panel: Propage bus format/flags

Hi Boris, Thank you for the patch. On Fri, Jan 31, 2020 at 06:25:05PM +0100, Boris Brezillon wrote: > And the typo (Propage -> Propagate) is still there :-(. Fixing it right > now so I don't forget. > > On Tue, 28 Jan 2020 14:55:12 +0100 Boris Brezillon wrote: > > So that the previous bridge

Re: [PATCH v10 09/12] dt-bindings: display: bridge: lvds-codec: Add new bus-width prop

Hi Boris, Thank you for the patch. On Tue, Jan 28, 2020 at 02:55:11PM +0100, Boris Brezillon wrote: > Add the bus-width property to describe the input bus format. > > v10: > * Add changelog to the commit message > * Add Rob's R-b > > v8 -> v9: > * No changes > > v7: > * Rebase on top of

Re: [PATCH v7 06/13] media: mtk-mdp: Check return value of of_clk_get

On 24/02/2020 18:36, Hans Verkuil wrote: > Hi Matthias, > > On 2/13/20 9:19 PM, matthias@kernel.org wrote: >> From: Matthias Brugger >> >> Check the return value of of_clk_get and print an error >> message if not EPROBE_DEFER. >> >> Signed-off-by: Matthias Brugger > > This patch is

Re: [PATCH 1/3] drm/omap: Prepare DSS for probing without legacy platform data

Hi Tony, Thank you for the patch. On Mon, Feb 24, 2020 at 11:12:28AM -0800, Tony Lindgren wrote: > In order to probe display subsystem (DSS) components with ti-sysc > interconnect target module without legacy platform data and using > devicetree, we need to update dss probing a bit. > > In the

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

On 2/24/20 7:46 PM, 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 slowly degenerating into essentially a global

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

On 2020-02-07 4:17 p.m., Alex Deucher wrote: > Split into init and register functions to avoid a segfault > in some configs when the load/unload callbacks are removed. > Looks like MST is completely broken with this change with a NULL pointer dereference in drm_dp_aux_register. > v2: > - add

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

On Mon, Feb 24, 2020 at 9:46 PM Daniel Vetter wrote: > > On Mon, Feb 24, 2020 at 5:31 PM Emil Velikov wrote: > > > > On Sat, 22 Feb 2020 at 17:54, Daniel Vetter wrote: > > > > > > It's the last user, and more importantly, it's the last non-legacy > > > user of anything in drm_pci.c. > > > > > >

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

On Mon, Feb 24, 2020 at 5:31 PM Emil Velikov wrote: > > On Sat, 22 Feb 2020 at 17:54, 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 >

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

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 amdgpu stopped doing with > > > > commit

Re: [PATCH 37/51] drm/rockchip: Drop explicit drm_mode_config_cleanup call

On Mon, Feb 24, 2020 at 8:13 PM Francesco Lavra wrote: > > On Fri, Feb 21, 2020 at 10:04 PM Daniel Vetter wrote: > > > > It's (almost, there's some iommu stuff without significance) right > > above the drm_dev_put(). > > > > This is made possible by a preceeding patch which added a drmm_ > >

Re: [PATCH 22/89] clk: bcm: rpi: Discover the firmware clocks

Hi Maxime, I love your patch! Perhaps something to improve: [auto build test WARNING on clk/clk-next] [also build test WARNING on robh/for-next anholt/for-next v5.6-rc3 next-20200224] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also

[PATCH v5] drm/tidss: dispc: Fix broken plane positioning code

The old implementation of placing planes on the CRTC while configuring the planes was naive and relied on the order in which the planes were configured, enabled, and disabled. The situation where a plane's zpos was changed on the fly was completely broken. The usual symptoms of this problem was

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

On 06/02/2020 08:29, Yuti Amonkar wrote: > 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

Re: [PATCH 16/89] clk: bcm: rpi: Add clock id to data

Hi Maxime, Am 24.02.20 um 10:06 schrieb Maxime Ripard: > The driver has really only supported one clock so far and has hardcoded the > ID used in communications with the firmware in all the functions > implementing the clock framework hooks. Let's store that in the clock data > structure so that

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

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 slowly degenerating into essentially a global lock. But only when there's actual

Re: [PATCH 4/4 v6] drm/virtio: enqueue virtio_gpu_create_context after the first 3D ioctl

On Mon, Feb 24, 2020 at 5:24 AM Emil Velikov wrote: > > On Mon, 24 Feb 2020 at 11:06, Gerd Hoffmann wrote: > > > > On Fri, Feb 21, 2020 at 04:54:02PM -0800, Gurchetan Singh wrote: > > > On Fri, Feb 21, 2020 at 3:06 PM Chia-I Wu wrote: > > > > > > > > On Wed, Feb 19, 2020 at 2:34 PM Gurchetan

Re: [PATCH 29/89] dt-bindings: display: Convert VC4 bindings to schemas

On Mon, 24 Feb 2020 10:06:31 +0100, Maxime Ripard wrote: > The BCM283x SoCs have a display pipeline composed of several controllers > with device tree bindings that are supported by Linux. > > Now that we have the DT validation in place, let's split into separate > files and convert the device

Re: [PATCH 2/7] docs: dt: fix several broken references due to renames

On Sat, Feb 22, 2020 at 10:00:02AM +0100, Mauro Carvalho Chehab wrote: > Several DT references got broken due to txt->yaml conversion. > > Those are auto-fixed by running: > > scripts/documentation-file-ref-check --fix > > Signed-off-by: Mauro Carvalho Chehab > Reviewed-by: Dan Murphy >

Re: [PATCH v7 06/13] media: mtk-mdp: Check return value of of_clk_get

Hi Matthias, On 2/13/20 9:19 PM, matthias@kernel.org wrote: > From: Matthias Brugger > > Check the return value of of_clk_get and print an error > message if not EPROBE_DEFER. > > Signed-off-by: Matthias Brugger This patch is independent from the remainder of this series, right? It looks

[PATCH][next][V2] drm/tidss: fix spelling mistakes "bufer" and "requsted"

From: Colin Ian King There are two spelling mistakes in warning and debug messages. Fix them. Signed-off-by: Colin Ian King --- V2: Add spelling mistake fix for "requsted" --- drivers/gpu/drm/tidss/tidss_dispc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

NAK: [PATCH][next] drm/tidss: fix spelling mistake "bufer" -> "buffer"

On 24/02/2020 15:15, Colin King wrote: > From: Colin Ian King > > There is a spelling mistake in a dev_dbg message. Fix it. > > Signed-off-by: Colin Ian King > --- > drivers/gpu/drm/tidss/tidss_dispc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH RFC v3 4/6] drm/sprd: add Unisoc's drm display controller driver

On Fri, 21 Feb 2020 at 11:15, Kevin Tang wrote: > > Adds DPU(Display Processor Unit) support for the Unisoc's display subsystem. > It's support multi planes, scaler, rotation, PQ(Picture Quality) and more. > > Cc: Orson Zhai > Cc: Baolin Wang > Cc: Chunyan Zhang > Signed-off-by: Kevin Tang >

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

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 support for iMX8MQ's Display Controller Subsystem (DCSS). > Some of its capabilities include: > * 4K@60fps; > * HDR10; > * one graphics and

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

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 > --- > .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 86 > ++ > 1 file changed, 86

Re: [PATCH 2/7] docs: dt: fix several broken references due to renames

Mauro On 2/22/20 3:00 AM, Mauro Carvalho Chehab wrote: Several DT references got broken due to txt->yaml conversion. Those are auto-fixed by running: scripts/documentation-file-ref-check --fix Signed-off-by: Mauro Carvalho Chehab ---

Re: [PATCH 2/7] docs: dt: fix several broken references due to renames

On Sat, Feb 22, 2020 at 2:30 PM Mauro Carvalho Chehab wrote: > > Several DT references got broken due to txt->yaml conversion. > > Those are auto-fixed by running: > > scripts/documentation-file-ref-check --fix > > Signed-off-by: Mauro Carvalho Chehab > --- >

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

Acked-by: Alyssa Rosenzweig On Wed, Feb 12, 2020 at 02:22:36PM -0600, Rob Herring wrote: > From: Tomeu Vizoso > > If the exception type isn't a translation fault, don't try to map and > instead go straight to a terminal fault. > > Otherwise, we can get flooded by kernel warnings and further

[PATCH] Initialize ATA before graphics

From: Arjan van de Ven Date: Thu, 2 Jun 2016 23:36:32 -0500 ATA init is the long pole in the boot process, and its asynchronous. Move the graphics init after it, so that ATA and graphics initialize in parallel. Signed-off-by: Paul Menzel --- 1. Taken from Clear Linux:

[RESEND 1/2] drm: bridge: adv7511: Enable SPDIF DAI

ADV7511 support I2S or SPDIF as audio input interfaces. This commit enable support for SPDIF. Signed-off-by: Bogdan Togorean Reviewed-by: Andrzej Hajda --- drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 14 ++ 1 file changed, 14 insertions(+) diff --git

[PATCH 2/2] drm/vmwgfx: Remove a few unused functions

I noticed that there is a prototype for vmw_fifo_ping_host_locked() but no function. Then I looked further and noticed more functions which are not used anymore or functions protoypes which remained after the function was removed. Remove unused function (prototypes). Signed-off-by: Sebastian

[RESEND 2/2] drm: bridge: adv7511: Extend list of audio sample rates

ADV7511 support sample rates up to 192kHz. CTS and N parameters should be computed accordingly so this commit extend the list up to maximum supported sample rate. Signed-off-by: Bogdan Togorean --- drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 12 1 file changed, 12

[PATCH 1/2] drm/vmwgfx: Drop preempt_disable() in vmw_fifo_ping_host()

vmw_fifo_ping_host() disables preemption around a test and a register write via vmw_write(). The write function acquires a spinlock_t typed lock which is not allowed in a preempt_disable()ed section on PREEMPT_RT. This has been reported in the bugzilla. It has been explained by Thomas Hellstrom

Re: [PATCH 22/89] clk: bcm: rpi: Discover the firmware clocks

Hi Maxime, I love your patch! Perhaps something to improve: [auto build test WARNING on clk/clk-next] [also build test WARNING on robh/for-next anholt/for-next v5.6-rc3 next-20200224] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also

[PATCH] clk: bcm: rpi: fix noderef.cocci warnings

cover the firmware clocks") CC: Maxime Ripard Signed-off-by: kbuild test robot --- url: https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-vc4-Support-BCM2711-Display-Pipeline/20200224-172730 base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next clk-ras

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

Hi all, On Fri, 21 Feb 2020 at 11:15, Kevin Tang wrote: > > From: Kevin Tang > > Adds drm support for the Unisoc's display subsystem. > > This is drm device and gem driver. This driver provides support for the > Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. > > Cc: Orson

Re: [PATCH 3/3] drm/pci: Unexport drm_get_pci_dev

On Sat, 22 Feb 2020 at 17:54, Daniel Vetter wrote: > > Only user left is the shadow attach for legacy drivers. > > Signed-off-by: Daniel Vetter Going the extra step, as outlined in 2/3 would be great. But if the series goes as-is, 2/3 and 3/3 are: Reviewed-by: Emil Velikov -Emil

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

On Sat, 22 Feb 2020 at 17:54, 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 1/3] drm/amdgpu: Drop DRIVER_USE_AGP

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 amdgpu stopped doing with > > commit b58c11314a1706bf094c489ef5cb28f76478c704 > Author: Alex Deucher > Date: Fri Jun 2 17:16:31 2017

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

On Sat, 22 Feb 2020 at 17:54, Daniel Vetter wrote: > > This doesn't do anything except auto-init drm_agp support when you > call drm_get_pci_dev(). Which amdgpu stopped doing with > > commit b58c11314a1706bf094c489ef5cb28f76478c704 > Author: Alex Deucher > Date: Fri Jun 2 17:16:31 2017 -0400 >

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

Thanks Laurent for sorting this out. On Sat, 22 Feb 2020 at 17:59, Daniel Vetter wrote: > > On Sat, Feb 22, 2020 at 05:24:30PM +0200, Laurent Pinchart wrote: > > The drm_driver structure is never modified, make it const. The improves > > security by avoiding writable function pointers. > > > >

[PATCH][next] drm/tidss: fix spelling mistake "bufer" -> "buffer"

From: Colin Ian King There is a spelling mistake in a dev_dbg message. Fix it. Signed-off-by: Colin Ian King --- drivers/gpu/drm/tidss/tidss_dispc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c b/drivers/gpu/drm/tidss/tidss_dispc.c

Re: [PATCH v2] drm/virtio: fix resource id creation race

On Thu, Feb 20, 2020 at 02:53:19PM -0800, John Bates wrote: > The previous code was not thread safe and caused > undefined behavior from spurious duplicate resource IDs. > In this patch, an atomic_t is used instead. We no longer > see any duplicate IDs in tests with this change. > > Fixes:

Re: [PATCH 3/3] drm/panel: add panel driver for Elida KD35T133 panels

On 23/02/2020 3:07 pm, Heiko Stuebner wrote: [...] +#define dsi_generic_write_seq(dsi, cmd, seq...) do { \ + static const u8 d[] = { seq }; \ + int ret;\ + ret =

Re: [PATCH v4] drm/tidss: dispc: Rewrite naive plane positioning code

On 14/02/2020 13:20, Tomi Valkeinen wrote: > On 13/02/2020 21:37, Jyri Sarha wrote: >> The old implementation of placing planes on the CRTC while configuring >> the planes was naive and relied on the order in which the planes were >> configured, enabled, and disabled. The situation where a plane's

Re: [RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)

On Mon, Feb 24, 2020 at 01:54:00PM +0100, Geert Uytterhoeven wrote: > Hi Krzysztof, > > On Mon, Feb 24, 2020 at 1:47 PM Krzysztof Kozlowski wrote: > > On Thu, Feb 20, 2020 at 10:48:33AM +0100, Jiri Slaby wrote: > > > On 19. 02. 20, 18:50, Krzysztof Kozlowski wrote: > > > > The ioreadX() helpers

Re: [PATCH] backlight: lp855x: Ensure regulators are disabled on probe failure

tor/core.c:2051 > _regulator_put.part.28+0x158/0x160 > Modules linked in: tegra_xudc lp855x_bl(+) host1x pwm_tegra ip_tables > x_tables ipv6 nf_defrag_ipv6 > CPU: 1 PID: 289 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200224 #1 > Hardware name: NVIDIA Jetson TX1 Developer Kit (

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

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 getting out of sync > with reality. > > Mostly done with cocci, with the following manual fixups: > - Remove the now

[PATCH] backlight: lp855x: Ensure regulators are disabled on probe failure

pwm_tegra ip_tables x_tables ipv6 nf_defrag_ipv6 CPU: 1 PID: 289 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200224 #1 Hardware name: NVIDIA Jetson TX1 Developer Kit (DT) ... Call trace: _regulator_put.part.28+0x158/0x160 regulator_put+0x34/0x50 devm_regulator_release+0x10/0x18

Re: [PATCH] drm/arm: make hdlcd_debugfs_init return 0

Hi, On Tue, Feb 18, 2020 at 08:28:13PM +0300, Wambui Karuga wrote: > As drm_debugfs_create_files should return void, remove its use as a > return value in hdlcd_debugfs_init and have the latter function return 0 > directly. > > Signed-off-by: Wambui Karuga > --- >

[Bug 206475] amdgpu under load drop signal to monitor until hard reset

https://bugzilla.kernel.org/show_bug.cgi?id=206475 --- Comment #9 from Marco (rodomar...@protonmail.com) --- Created attachment 287575 --> https://bugzilla.kernel.org/attachment.cgi?id=287575=edit Latest log with a warning. -- You are receiving this mail because: You are watching the assignee

[Bug 206475] amdgpu under load drop signal to monitor until hard reset

https://bugzilla.kernel.org/show_bug.cgi?id=206475 Marco (rodomar...@protonmail.com) changed: What|Removed |Added Status|RESOLVED|REOPENED

Re: [PATCH 4/4 v6] drm/virtio: enqueue virtio_gpu_create_context after the first 3D ioctl

On Mon, 24 Feb 2020 at 11:06, Gerd Hoffmann wrote: > > On Fri, Feb 21, 2020 at 04:54:02PM -0800, Gurchetan Singh wrote: > > On Fri, Feb 21, 2020 at 3:06 PM Chia-I Wu wrote: > > > > > > On Wed, Feb 19, 2020 at 2:34 PM Gurchetan Singh > > > wrote: > > > > > > > > For old userspace, initialization

Re: [PATCH 11/12] drm: Shrink mode->private_flags

On Fri, Feb 21, 2020 at 05:15:20PM +0100, Sam Ravnborg wrote: > On Wed, Feb 19, 2020 at 10:35:43PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > gma500 needs 4 bits (to store a pixel multiplier) in the > > mode->private_flags, i915 currently has three bits defined. > > No one else

Re: [PATCH v2 0/6] update hwdw for gc400

gentle ping -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info/privacypolicy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

On Sat, Feb 22, 2020 at 01:32:40PM +0100, Sam Ravnborg wrote: > Hi Ville. > > Nice patch - and diffstat looks good: > > 63 files changed, 217 insertions(+), 392 deletions(-) > > There is an item in the Documentation/gpu/todo.rst that > describes this. > Could you drop this from todo.rst in this

  1   2   3   >