Re: [PATCH v4 6/7] ARM: dts: Add support for emtrion emCON-MX6 series

On Fri, Apr 27, 2018 at 03:24:41PM +0200, jan.tu...@emtrion.com wrote: > From: Jan Tuerk > > This patch adds support for the emtrion GmbH emCON-MX6 modules. > They are available with imx.6 Solo, Dual-Lite, Dual and Quad > equipped with Memory from 512MB to 2GB (configured

Re: [PATCH v4 0/7] Add basic support for emtrion emCON-MX6 modules

On Fri, Apr 27, 2018 at 03:24:35PM +0200, jan.tu...@emtrion.com wrote: > From: Jan Tuerk > > Changes for v4: > - re-arrange the Patch-series to match the DT-submitting-patches > - Additional patch for the Documentation of the new DT-bindings > > [PATCH v4 1/7]

[Bug 106289] mupen64plus segfaults deep inside r300_dri.so

https://bugs.freedesktop.org/show_bug.cgi?id=106289 Bug ID: 106289 Summary: mupen64plus segfaults deep inside r300_dri.so Product: DRI Version: XOrg git Hardware: x86 (IA32) OS: Linux (All) Status: NEW

[Bug 106287] 18.0.1 introduced glitches in Dying Light

https://bugs.freedesktop.org/show_bug.cgi?id=106287 Bug ID: 106287 Summary: 18.0.1 introduced glitches in Dying Light Product: Mesa Version: 18.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

https://bugs.freedesktop.org/show_bug.cgi?id=104082 --- Comment #49 from Barto --- full log error, it seems related to ttm code, I use the radeon driver (not amdgpu) : [20021.576712] radeon :01:00.0: swiotlb buffer is full (sz: 2097152 bytes) [20021.576715]

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

https://bugs.freedesktop.org/show_bug.cgi?id=104082 --- Comment #48 from Barto --- the bug occurs also with radeon driver, and not only amdgpu : radeon :01:00.0: swiotlb buffer is full (sz: 2097152 bytes) radeon :01:00.0: swiotlb: coherent allocation failed,

Re: [PATCH v3 0/5] drm: rcar-du: r8a77965 DU support

Hi Kieran, Thank you for the patches. On Saturday, 28 April 2018 01:21:49 EEST Kieran Bingham wrote: > The r8a77965 M3-N platform supports a DPAD, HDMI and LVDS output, along > 3 DU channels. However, DU2 is not available in the hardware, with the > DPAD instead being routed through DU3. > >

[PATCH v3 1/5] dt-bindings: display: renesas: Add R-Car M3-N HDMI TX DT bindings

The M3-N HDMI TX controller is compatible with the M3-W and H3. No extension to the DT bindings are needed. Add an SoC-specific compatible string in case differences between the IP versions are found later and require model-specific handling. Signed-off-by: Kieran Bingham

[PATCH v3 0/5] drm: rcar-du: r8a77965 DU support

The r8a77965 M3-N platform supports a DPAD, HDMI and LVDS output, along 3 DU channels. However, DU2 is not available in the hardware, with the DPAD instead being routed through DU3. Provide support for this non-linear indexing with updates to the rcar-du driver, before adding the device info

[PATCH v3 3/5] drm: rcar-du: Split CRTC handling to support hardware indexing

The DU CRTC driver does not support distinguishing between a hardware index, and a software (CRTC) index in the event that a DU channel might not be populated by the hardware. Support this by adapting the rcar_du_device_info structure to store a bitmask of available channels rather than a count

[PATCH v3 2/5] pinctrl: sh-pfc: r8a77965: Add DU RGB output pins, groups and functions

This patch adds pins, groups and functions for parallel RGB output signals from DU. The HDMI and TCON pins are added to separate groups. Based on a similar patch of the R8A7796 PFC driver by Niklas Söderlund . Signed-off-by: Takeshi Kihara

[PATCH v3 4/5] drm: rcar-du: Allow DU groups to work with hardware indexing

The group objects assume linear indexing, and more so always assume that channel 0 of any active group is used. Now that the CRTC objects support non-linear indexing, adapt the groups to remove assumptions that channel 0 is utilised in each group by using the channel mask provided in the device

[PATCH v3 5/5] drm: rcar-du: Add R8A77965 support

The R8A77965 (M3-N) SoC provides RGB, HDMI and LVDS output. This platform is unusual in that the RGB is connected to DU3 leaving DU2 unpopulated. This is reflected by the channels_mask accordingly. Signed-off-by: Kieran Bingham Reviewed-by: Laurent

[Bug 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)

https://bugs.freedesktop.org/show_bug.cgi?id=104001 --- Comment #32 from Marek Olšák --- The patch is already backported in the 18.0 branch: https://cgit.freedesktop.org/mesa/mesa/log/?h=18.0 -- You are receiving this mail because: You are the assignee for the

Re: [PATCH v2 1/8] v4l: vsp1: Use SPDX license headers

Hi Kieran, On Saturday, 28 April 2018 00:25:51 EEST Kieran Bingham wrote: > Hi Laurent, > > Thank you for the patch, and going through the whole driver for this update. > On 22/04/18 23:34, Laurent Pinchart wrote: > > Adopt the SPDX license identifier headers to ease license compliance > >

Re: [PATCH v2 11/11] arm64: dts: r8a77965-salvator-xs: Enable DU external clocks and HDMI

Hi Laurent, On 27/04/18 22:32, Laurent Pinchart wrote: > Hi Kieran, > > Thank you for the patch. > > On Friday, 27 April 2018 19:57:22 EEST Kieran Bingham wrote: >> The DU1 external dot clock is provided by the fixed frequency clock >> generator X21, while the DU0 and DU3 clocks are provided by

Re: [PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI

Hi Kieran, Thank you for the patch. On Friday, 27 April 2018 19:57:21 EEST Kieran Bingham wrote: > The DU1 external dot clock is provided by the fixed frequency clock > generator X21, while the DU0 and DU3 clocks are provided by the > programmable Versaclock5 clock generator. > > Enable the

Re: [PATCH v2 11/11] arm64: dts: r8a77965-salvator-xs: Enable DU external clocks and HDMI

Hi Kieran, Thank you for the patch. On Friday, 27 April 2018 19:57:22 EEST Kieran Bingham wrote: > The DU1 external dot clock is provided by the fixed frequency clock > generator X21, while the DU0 and DU3 clocks are provided by the > programmable Versaclock6 clock generator. > > Enable the

Re: [PATCH v2 00/11] r8a77965: M3-N DU Enablement

Hi Kieran, On Friday, 27 April 2018 19:57:11 EEST Kieran Bingham wrote: > This series enables the DU for the M3-N R8A77965 SoC, and provides > output on the VGA and HDMI connectors. > > LVDS is not yet supported or tested. > > > Patch 9 has the following checkpatch.pl warnings of which I have

Re: [PATCH v2 1/8] v4l: vsp1: Use SPDX license headers

Hi Laurent, Thank you for the patch, and going through the whole driver for this update. On 22/04/18 23:34, Laurent Pinchart wrote: > Adopt the SPDX license identifier headers to ease license compliance > management. All files in the driver are licensed under the GPLv2+ except > for the

Re: [PATCH v2 03/11] drm: rcar-du: Split CRTC handling to support hardware indexing

Hi Kieran, Thank you for the patch. On Friday, 27 April 2018 19:57:14 EEST Kieran Bingham wrote: > The DU CRTC driver does not support distinguishing between a hardware > index, and a software (CRTC) index in the event that a DU channel might > not be populated by the hardware. > > Support this

Re: [PATCH v2 01/11] dt-bindings: display: renesas: Add R-Car M3-N HDMI TX DT bindings

Hi Kieran, Thank you for the patch. On Friday, 27 April 2018 19:57:12 EEST Kieran Bingham wrote: > The M3-N HDMI TX controller is compatible with the M3-W and H3. No > extension to the DT bindings are needed. > > Add an SoC-specific compatible string in case differences between the IP >

igt trouble with planes shared between multiple CRTCs (Re: [PATCH v2 0/8] R-Car DU: Support CRC calculation)

Hi Daniel, (Removing the linux-media mailing list from CC as it is out of scope) You enquired on IRC whether this patch series passes the igt CRC tests. # ./kms_pipe_crc_basic --run-subtest read-crc-pipe-A IGT-Version: 1.22-gf447f5fc531d (aarch64) (Linux: 4.17.0-rc1-00085-g56e849d93cc9

[Bug 106258] AMD Xorg start failes with non-4K page sizes

https://bugs.freedesktop.org/show_bug.cgi?id=106258 --- Comment #5 from Matt Corallo --- Just checked with today's linus/master (somwehere between 4.17-rc2 and 4.17-rc3) and the issue is still present. -- You are receiving this mail because: You are the assignee for

[PATCH] drm: rcar-du: lvds: Fix crash in .atomic_check when disabling connector

The connector .atomic_check() handler can be called with a NULL crtc pointer in the connector state when the connector gets disabled explicitly (through performing a legacy mode set or setting the connector's CRTC_ID property to 0). This causes a crash as the crtc pointer is dereferenced without

Re: [PATCH v2 1/4] drm/panel: simple: Add support for Rocktech RK070ER9427 LCD panel

On Fri, Apr 27, 2018 at 06:40:40PM +0530, Jagan Teki wrote: > This adds support for the Rocktech Display Ltd. RK070ER9427 > 800(RGB)x480 TFT LCD panel, which can be supported by the > simple panel driver. > > Signed-off-by: Jagan Teki > --- > Changes for v2: > -

[PATCH 2/2] ARM: dts: Modernize the Vexpress PL111 integration

The Versatile Express was submitted with the actual display bridges unconnected (but defined in the device tree) and mock "panels" encoded in the device tree node of the PL111 controller. This doesn't even remotely describe the actual Versatile Express hardware. Exploit the SiI9022 bridge by

Re: [PATCH v2 2/3] dt-bindings: Add a new binding for Broadcom V3D 3.x and newer GPUs.

On Mon, Apr 23, 2018 at 05:46:09PM -0700, Eric Anholt wrote: > These OpenGL ES GPUs are present in the 7268 and 7278 set top box > chips. > > Signed-off-by: Eric Anholt > --- > .../bindings/display/brcm,bcm-v3d.txt | 28 +++ Does this have display h/w?

Re: [PATCH v7 1/2] drm: content-type property for HDMI connector

On Mon, Apr 23, 2018 at 10:34:41AM +0300, StanLis wrote: > From: Stanislav Lisovskiy > > Added content_type property to drm_connector_state > in order to properly handle external HDMI TV content-type setting. > > v2: > * Moved helper function which attaches

[PATCH 1/2] ARM: dts: Restructure Vexpress motherboard includes

It is a bit unorthodox to just include a file in the middle of a another DTS file, it breaks the pattern from other device trees and also makes it really hard to reference things across the files with phandles. Restructure the include for the Versatile Express motherboards to happen at the top of

Re: [PATCH 1/2 v4] drm/pl111: Support the Versatile Express

On Fri, Apr 27, 2018 at 5:02 PM, Robin Murphy wrote: > I dug a little bit and it seems pl111_modeset_init() is deferring because it > can't find endpoint 0. And given that that's apparently pointing at some > non-existent panel rather than the DVI encoder as I would

[Bug 106188] Can't successfully set pstates in pp_od_clk_voltage

https://bugs.freedesktop.org/show_bug.cgi?id=106188 --- Comment #4 from tempel.jul...@gmail.com --- Ok, it's simple. To unlock higher clocks, I simply have to set "/sys/class/drm/card0/device/pp_sclk_od" as well. To sum up: For my 1209MHz 900mV I have to do the following: echo "2" >

Re: [PATCH] video: fbdev: omap2: remove rfbi

On Friday, April 27, 2018 08:47:14 PM Aaro Koskinen wrote: > Hi, > > On Fri, Apr 27, 2018 at 05:09:14PM +0200, Bartlomiej Zolnierkiewicz wrote: > > omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove rfbi"): > > > > The RFBI driver has not worked nor compiled for many years. There

[Bug 199545] New: Starting X-server leads to crash

https://bugzilla.kernel.org/show_bug.cgi?id=199545 Bug ID: 199545 Summary: Starting X-server leads to crash Product: Drivers Version: 2.5 Kernel Version: 4.9 Hardware: x86-64 OS: Linux Tree: Mainline

Re: [PATCH] drm/vmwgfx: Fix scatterlist unmapping

On 04/27/2018 06:56 PM, Robin Murphy wrote: Hi Thomas, On 25/04/18 14:21, Thomas Hellstrom wrote: Hi, Robin, Thanks for the patch. It was some time since I put together that code, but I remember hitting something similar to

[Bug 106285] Multiple Xorg restarts leads to `Surface: can not attach plane_state` (raven ridge)

https://bugs.freedesktop.org/show_bug.cgi?id=106285 Bug ID: 106285 Summary: Multiple Xorg restarts leads to `Surface: can not attach plane_state` (raven ridge) Product: DRI Version: unspecified Hardware: Other

[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g

https://bugs.freedesktop.org/show_bug.cgi?id=106225 --- Comment #12 from Francisco Pina Martins --- francisco@ZenBox [18:03:53] [/usr/lib/modules/4.16.5-1-kasan/build] -> $ scripts/faddr2line drivers/gpu/drm/amd/amdgpu/amdgpu.ko firmware_parser_create+0xa70/0xd90 ERROR:

Re: [[RFC]DPU PATCH 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings

On Fri, Apr 27, 2018 at 3:02 AM, wrote: > On 2018-04-27 08:43, Rob Herring wrote: >> >> On Wed, Apr 25, 2018 at 08:46:13PM -0400, Rob Clark wrote: >>> >>> On Wed, Apr 25, 2018 at 7:45 PM, Stephen Boyd >>> wrote: >>> > Quoting Sandeep Panda (2018-04-19

[PATCH v2 02/11] pinctrl: sh-pfc: r8a77965: Add DU RGB output pins, groups and functions

This patch adds pins, groups and functions for parallel RGB output signals from DU. The HDMI and TCON pins are added to separate groups. Based on a similar patch of the R8A7796 PFC driver by Niklas Söderlund . Signed-off-by: Takeshi Kihara

[PATCH v2 06/11] arm64: dts: r8a77965: Add FCPF and FCPV instances

The FCPs handle the interface between various IP cores and memory. Add the instances related to the FDPs and VSP2s. Based on a similar patch of the R8A7796 device tree by Laurent Pinchart . Signed-off-by: Takeshi Kihara

[PATCH v2 08/11] arm64: dts: r8a77965: Populate the DU instance placeholder

The DU entity node has been previously added but only as a placeholder. Populate the node with the properties to use the device. Signed-off-by: Kieran Bingham Reviewed-by: Laurent Pinchart --- v2: - Remove LVDS

[PATCH v2 11/11] arm64: dts: r8a77965-salvator-xs: Enable DU external clocks and HDMI

The DU1 external dot clock is provided by the fixed frequency clock generator X21, while the DU0 and DU3 clocks are provided by the programmable Versaclock6 clock generator. Enable the clocks, and the HDMI encoder for the M3-N Salvator-XS, and hook it up to the HDMI connector Based on patches

[PATCH v2 03/11] drm: rcar-du: Split CRTC handling to support hardware indexing

The DU CRTC driver does not support distinguishing between a hardware index, and a software (CRTC) index in the event that a DU channel might not be populated by the hardware. Support this by adapting the rcar_du_device_info structure to store a bitmask of available channels rather than a count

[PATCH v2 09/11] arm64: dts: r8a77965: Add HDMI encoder instance

Add the HDMI encoder to the R8A77965 DT in disabled state. Based on a similar patch of the R8A7796 device tree by Laurent Pinchart . Signed-off-by: Takeshi Kihara [Kieran: Rebase to top of tree] Signed-off-by: Kieran

[PATCH v2 05/11] drm: rcar-du: Add R8A77965 support

The R8A77965 (M3-N) SoC provides RGB, HDMI and LVDS output. This platform is unusual in that the RGB is connected to DU3 leaving DU2 unpopulated. This is reflected by the channels_mask accordingly. Signed-off-by: Kieran Bingham Reviewed-by: Laurent

[PATCH v2 04/11] drm: rcar-du: Allow DU groups to work with hardware indexing

The group objects assume linear indexing, and more so always assume that channel 0 of any active group is used. Now that the CRTC objects support non-linear indexing, adapt the groups to remove assumptions that channel 0 is utilised in each group by using the channel mask provided in the device

[PATCH v2 00/11] r8a77965: M3-N DU Enablement

This series enables the DU for the M3-N R8A77965 SoC, and provides output on the VGA and HDMI connectors. LVDS is not yet supported or tested. Patch 9 has the following checkpatch.pl warnings of which I have ignored: ===

[PATCH v2 10/11] arm64: dts: r8a77965-salvator-x: Enable DU external clocks and HDMI

The DU1 external dot clock is provided by the fixed frequency clock generator X21, while the DU0 and DU3 clocks are provided by the programmable Versaclock5 clock generator. Enable the clocks, and the HDMI encoder for the M3-N Salvator-X board and hook it up to the HDMI connector. Based on

[PATCH v2 01/11] dt-bindings: display: renesas: Add R-Car M3-N HDMI TX DT bindings

The M3-N HDMI TX controller is compatible with the M3-W and H3. No extension to the DT bindings are needed. Add an SoC-specific compatible string in case differences between the IP versions are found later and require model-specific handling. Signed-off-by: Kieran Bingham

[PATCH v2 07/11] arm64: dts: r8a77965: Add VSP instances

The r8a77965 has 4 VSP instances. Based on a similar patch of the R8A7796 device tree by Laurent Pinchart . Signed-off-by: Takeshi Kihara [Kieran: Rebased to top of tree, fixed sort orders] Signed-off-by: Kieran Bingham

Re: [PATCH] drm/vmwgfx: Fix scatterlist unmapping

Hi Thomas, On 25/04/18 14:21, Thomas Hellstrom wrote: Hi, Robin, Thanks for the patch. It was some time since I put together that code, but I remember hitting something similar to https://www.linuxquestions.org/questions/linux-kernel-70/%27nents%27-argument-of-dma_unmap_sg-4175621964/

[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g

https://bugs.freedesktop.org/show_bug.cgi?id=106225 --- Comment #11 from Michel Dänzer --- Please provide the output of the following in your kernel build tree: scripts/faddr2line drivers/gpu/drm/amd/amdgpu/amdgpu.ko firmware_parser_create+0xa70/0xd90 -- You are receiving

[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g

https://bugs.freedesktop.org/show_bug.cgi?id=106225 Francisco Pina Martins changed: What|Removed |Added Attachment #139178|0 |1

[Bug 104598] vkmark with kwin compositing: Page flip failed: Cannot allocate memory

https://bugs.freedesktop.org/show_bug.cgi?id=104598 --- Comment #5 from Michel Dänzer --- I can't reproduce this, is it still happening for you? Is it with vkmark in fullscreen or windowed mode? Which version of kwin, and what's selected for rendering method and tearing

Re: [PATCH] drm/i915: Promote .format_mod_supported() to the lead role

On Fri, Mar 30, 2018 at 12:06:11PM -0700, Eric Anholt wrote: > Ville Syrjala writes: > > > From: Ville Syrjälä > > > > Up to now we've used the plane's modifier list as the primary > > source of information for which modifiers are

[Bug 106260] raven ridge (2400g) shows artifacts instead in xorg

https://bugs.freedesktop.org/show_bug.cgi?id=106260 ojab changed: What|Removed |Added Attachment #139180|text/x-log |text/plain mime type|

[Bug 106260] raven ridge (2400g) shows artifacts instead in xorg

https://bugs.freedesktop.org/show_bug.cgi?id=106260 --- Comment #5 from ojab --- Created attachment 139180 --> https://bugs.freedesktop.org/attachment.cgi?id=139180=edit Xorg.0.log with "Accel" "off" yep, works correctly with "Accel" "off" -- You are receiving this mail

[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g

https://bugs.freedesktop.org/show_bug.cgi?id=106225 --- Comment #9 from Michel Dänzer --- Getting closer, please try again with kasan_multi_shot on the kernel command line, otherwise KASAN only reports the first thing it catches. -- You are receiving this mail because: You

Re: [PATCH v2 2/3] drm/amdgpu: Allow dma_map_sg() coalescing

On 25/04/18 21:44, Sinan Kaya wrote: On 4/17/2018 5:13 PM, Sinan Kaya wrote: Tested-by: Sinan Kaya using QDF2400 and XFX Vega64 GPU for the first two patches. ./builddir/tests/amdgpu/amdgpu_test -s 1 Suite: Basic Tests Test: Userptr Test ...passed Userptr Test

[PATCH] video: fbdev: omap2: remove rfbi

omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove rfbi"): The RFBI driver has not worked nor compiled for many years. There are very few boards out there that use RFBI, and no one has stepped up to fix it. So let's remove the RFBI code that doesn't even compile. Cc: Tomi

Re: [PATCH] video: fbdev: remove unused auo_k190xfb drivers

Am Freitag, 27. April 2018, 13:04:24 CEST schrieb Bartlomiej Zolnierkiewicz: > auo_k1900fb and auo_k1901fb drivers have been introduced six > years ago by following commits: > > commit 2c8304d3125b ("video: auo_k190x: add code shared by controller > drivers") > commit 96b1d500e028 ("video:

Re: [PATCH 1/2 v4] drm/pl111: Support the Versatile Express

On 26/04/18 08:52, Linus Walleij wrote: On Mon, Apr 23, 2018 at 2:04 PM, Robin Murphy wrote: I've given this a go on the nearest VExpress (with CA15_A7 tile) and sadly it doesn't quite work for me :( With the HDLCD driver configure out, the PL111 driver seems to

[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g

https://bugs.freedesktop.org/show_bug.cgi?id=106225 Francisco Pina Martins changed: What|Removed |Added Attachment #139154|0 |1

Re: [PATCH v4 5/7] dt-bindings: arm: Document emtrion emCON-MX6 bindings

On Fri, Apr 27, 2018 at 03:24:40PM +0200, jan.tu...@emtrion.com wrote: > From: Jan Tuerk > > Document the compatible strings for emtrion emCON-MX6 SoM's. > > Signed-off-by: Jan Tuerk > --- > For v4: > - separate patch for the emtrion emCON-MX6

Re: [PATCH v4 1/7] dt-bindings: display: Document the EDT et* displays in one file.

On Fri, Apr 27, 2018 at 03:24:36PM +0200, jan.tu...@emtrion.com wrote: > From: Jan Tuerk > > Document the Emerging Display Technology Corp. (EDT) using the > simple-panel binding in one single file. > > Signed-off-by: Jan Tuerk > --- > Changes for

Re: [PATCH v4 3/3] drm/panel: add support for Innolux TV123WAM panel

On Fri, Apr 27, 2018 at 03:09:42PM +0530, Sandeep Panda wrote: > Innolux TV123WAM is a 12.3" eDP display panel with > 2160x1440 resolution, which can be supported by simple > panel driver. > > Changes in v1: > - Make use of simple panel driver instead of creating >a new driver for this panel

Re: [PATCH v4 2/8] dt-bindings: display: atmel: optional video-interface of endpoints

On Mon, Apr 23, 2018 at 09:22:55AM +0200, Peter Rosin wrote: > With bus-type/bus-width properties in the endpoint nodes, the video- > interface of the connection can be specified for cases where the > heuristic fails to select the correct output mode. This can happen > e.g. if not all RGB pins are

Re: [PATCH v5] drm/panel: simple: Add TFC S9700RTWV43TR-01B 800x480 panel support

On Thu, Apr 26, 2018 at 10:48:22PM +0300, Jyri Sarha wrote: > Add support for Three Five displays TFC S9700RTWV43TR-01B 800x480 > panel with resistive touch found on TI's AM335X-EVM. > > Signed-off-by: Jyri Sarha > Reviewed-by: Tomi Valkeinen > cc: Thierry

[Bug 106263] amdgpu produces several stracktraces (Fiji, Bonaire) at boot since kernel 4.16.4

https://bugs.freedesktop.org/show_bug.cgi?id=106263 --- Comment #3 from erhar...@mailbox.org --- I did that once, so technically yes. Hope I got time for it the next few days. -- You are receiving this mail because: You are the assignee for the

[Bug 199407] Radeon night light/redshift flickers

https://bugzilla.kernel.org/show_bug.cgi?id=199407 --- Comment #6 from Dan (dan...@consultd.de) --- works fine for me on .17rc Dan On 27.04.2018 15:59, bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=199407 > > Cm (c...@mailinator.com) changed: > >

[Bug 106263] amdgpu produces several stracktraces (Fiji, Bonaire) at boot since kernel 4.16.4

https://bugs.freedesktop.org/show_bug.cgi?id=106263 --- Comment #2 from Harry Wentland --- Are you able to bisect? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

Re: [PATCH] drm/dp: Rename the edp_sdp_header as dp_sdp_header

On Thu, Apr 26, 2018 at 12:27:48PM -0700, Manasi Navare wrote: > No functional changes in this patch. > > The SDP Header is a generic header for secondary data packets for > both eDP and DP so call it dp_sdp_header. This header gets used for > different SDP types already defined. > Also header

Re: [PATCH] drm: Don't pass the index to drm_property_add_enum()

On Thu, Apr 26, 2018 at 12:45:13PM +, Lisovskiy, Stanislav wrote: > Reviewed-by: Stanislav Lisovskiy Thanks. Pushed to drm-misc-next. > > Best Regards, > > Lisovskiy Stanislav > > Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

Re: [PATCH v12 08/10] drm: Expose modes with aspect ratio, only if requested

On Fri, Apr 27, 2018 at 05:44:54PM +0530, Nautiyal, Ankit K wrote: > From: Ankit Nautiyal > > We parse the EDID and add all the modes in the connector's modelist. > This adds CEA modes with aspect ratio information too, regadless of > whether user space requested this

[Bug 199407] Radeon night light/redshift flickers

https://bugzilla.kernel.org/show_bug.cgi?id=199407 Cm (c...@mailinator.com) changed: What|Removed |Added CC||c...@mailinator.com ---

Re: [PATCH v12 07/10] drm: Handle aspect ratio info in legacy modeset path

On Fri, Apr 27, 2018 at 05:44:53PM +0530, Nautiyal, Ankit K wrote: > From: Ankit Nautiyal > > If the user-space does not support aspect-ratio, and requests for a > modeset with mode having aspect ratio bits set, then the given > user-mode must be rejected. Secondly,

Re: [PATCH v1] xf86drm: Add drmHandleMatch func

On 27 April 2018 at 12:31, Robert Foss wrote: > drmHandleMatch is intended to allow for userspace to filter out > devices that it does not want to open. > > Opening specific devices using paths alone is not a reliable due to > probing order. This function intends to

Re: [Patch v2 2/6] dt-bindings: display/ti: Move common dispc bindings to omap-dss.txt

Laurent Pinchart wrote on Wed [2018-Apr-04 17:29:59 +0300]: > Hi Benoit, > > Thank you for the patch. > > On Monday, 26 March 2018 19:21:24 EEST Benoit Parrot wrote: > > Add common DISPC bindings into the top level bindings file. > > Move common bindings here

[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g

https://bugs.freedesktop.org/show_bug.cgi?id=106225 --- Comment #7 from Francisco Pina Martins --- I had previously made a mistake in loading the kernel's .config file. I have now managed to compile the kernel with the options for KASAN set. However, booting this kernel

[PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE

From: Michel Dänzer Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled) try to allocate huge pages. However, not all drivers can take advantage of huge pages, but they would incur the overhead for allocating and freeing them anyway. Now, drivers which

Re: [PATCH] drm/stm: ltdc: fix warnings in ltdc_plane_create()

On 04/25/2018 09:13 AM, Yannick FERTRE wrote: > Hi Philippe, > > Reviewed-by: Yannick Fertré > Applied on drm-misc-next. Many thanks, Philippe :-) > > On 04/19/2018 03:28 PM, Philippe Cornu wrote: >> "make C=1" returns 2 warnings in ltdc_plane_create() >> ("Using

Re: [PATCH] drm/stm: ltdc: add mode_valid()

On 04/25/2018 09:12 AM, Yannick FERTRE wrote: > Hi Philippe, > > Reviewed-by: Yannick Fertré > Applied on drm-misc-next. Many thanks, Philippe :-) > On 04/17/2018 01:40 PM, Philippe Cornu wrote: >> Add mode_valid() function to filter modes according to available >>

Re: [PATCH] drm/stm: ltdc: fix deferred endpoint management

On 04/25/2018 09:12 AM, Yannick FERTRE wrote: > Hi Philippe, > > Reviewed-by: Yannick Fertré Applied on drm-misc-next. Many thanks, Philippe :-) > > > On 04/17/2018 01:34 PM, Philippe Cornu wrote: >> When a driver related to one of the endpoints is deferred >> due to

[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.

https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #12 from Allan --- My system started to power down for nothing sometimes, even using the GTX1070 (nvidia|nouveau) . Then I installed a Windows image just to be sure if the kernel was the problem. Well, for now

Re: [PATCH v4 2/3] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings

On Fri, Apr 27, 2018 at 4:39 AM, Sandeep Panda wrote: > Document the bindings used for the sn65dsi86 DSI to eDP bridge. > > Changes in v1: > - Rephrase the dt-binding descriptions to be more inline with existing >bindings (Andrzej Hajda). > - Add missing dt-binding

[PATCH v12 10/10] drm: Add and handle new aspect ratios in DRM layer

From: "Sharma, Shashank" HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch: - Adds new DRM flags for to represent these new aspect ratios. - Adds new cases to handle these aspect ratios while converting from user->kernel mode or vise

[PATCH v12 03/10] drm/edid: Fix cea mode aspect ratio handling

From: Ville Syrjälä commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer") cause us to not send out any VICs in the AVI infoframes. That commit was since reverted, but if and when we add aspect ratio handing back we need to be more careful. Let's

[PATCH v12 04/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

From: Ville Syrjälä If the user mode would specify an aspect ratio other than 4:3 or 16:9 we now silently ignore it. Maybe a better apporoach is to return an error? Let's try that. Also we must be careful that we don't try to send illegal picture aspect in the

[PATCH v12 09/10] drm: Add aspect ratio parsing in DRM layer

From: "Sharma, Shashank" Current DRM layer functions don't parse aspect ratio information while converting a user mode->kernel mode or vice versa. This causes modeset to pick mode with wrong aspect ratio, eventually causing failures in HDMI compliance test cases, due

[PATCH v12 08/10] drm: Expose modes with aspect ratio, only if requested

From: Ankit Nautiyal We parse the EDID and add all the modes in the connector's modelist. This adds CEA modes with aspect ratio information too, regadless of whether user space requested this information or not. This patch prunes the modes with aspect-ratio

[PATCH v12 07/10] drm: Handle aspect ratio info in legacy modeset path

From: Ankit Nautiyal If the user-space does not support aspect-ratio, and requests for a modeset with mode having aspect ratio bits set, then the given user-mode must be rejected. Secondly, while preparing a user-mode from kernel mode, the aspect-ratio info must not

[PATCH v12 00/10] Aspect ratio support in DRM layer

From: Ankit Nautiyal This patch series is a re-attempt to enable aspect ratio support in DRM layer. Currently the aspect ratio information gets lost in translation during a user->kernel mode or vice versa. The old patch series

[PATCH v12 01/10] drm/modes: Introduce drm_mode_match()

From: Ville Syrjälä Make mode matching less confusing by allowing the caller to specify which parts of the modes should match via some flags. Signed-off-by: Ville Syrjälä Reviewed-by: Shashank Sharma ---

[PATCH v12 05/10] video/hdmi: Reject illegal picture aspect ratios

From: Ville Syrjälä AVI infoframe can only carry none, 4:3, or 16:9 picture aspect ratios. Return an error if the user asked for something different. Cc: Shashank Sharma Cc: "Lin, Jia" Cc: Akashdeep Sharma

[PATCH v12 06/10] drm: Add DRM client cap for aspect-ratio

From: Ankit Nautiyal To enable aspect-ratio support in DRM, blindly exposing the aspect ratio information along with mode, can break things in existing non-atomic user-spaces which have no intention or support to use this aspect ratio information. To avoid this, a

[PATCH v12 02/10] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

From: Ville Syrjälä Use drm_mode_equal_no_clocks_no_stereo() in drm_match_hdmi_mode_clock_tolerance() for consistency as we also use it in drm_match_hdmi_mode() and the cea mode matching functions. This doesn't actually change anything since the input mode comes

Re: [PATCH hwc 4/4] drm_hwcomposer: Fall back to client compositon if the gl precompostior fails

This patch is: Acked-by: Robert Foss I'll push this series upstream in a few minutes. On 04/26/2018 09:05 PM, John Stultz wrote: If the gl precompositor isn't being used, we cannot accept every layer as a device composited layer. Thus this patch adds some extra

Re: [PATCH 0/3] fbdev/drm: sh_mobile: remove unused MERAM support

On Fri, Apr 27, 2018 at 1:36 PM, Laurent Pinchart wrote: > Hi Bartlomiej, > > On Friday, 27 April 2018 14:21:42 EEST Bartlomiej Zolnierkiewicz wrote: >> Hi, >> >> This patchset removes unused MERAM support (last user was removed >> 3 years ago) from shmobile

Re: [PATCH 0/3] fbdev/drm: sh_mobile: remove unused MERAM support

Hi Bartlomiej, On Friday, 27 April 2018 14:21:42 EEST Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patchset removes unused MERAM support (last user was removed > 3 years ago) from shmobile fbdev & drm drivers and then removes > MERAM driver itself. > > If it is okay to merge this patches I

[PATCH v1] xf86drm: Add drmHandleMatch func

drmHandleMatch is intended to allow for userspace to filter out devices that it does not want to open. Opening specific devices using paths alone is not a reliable due to probing order. This function intends to provide a mechanism for filtering out devices that don't fit what you need using an

  1   2   >