[radeon-alex:amd-staging-drm-next 374/761] sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 'readl'; did you mean 'vread'?

tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 15c4159ae0335606479a673d2cf70ad574832435 commit: c1888183e1764d55d51ae051bd8651e634febe4d [374/761] ASoC: AMD: enable ACP3x drivers build config: arm-allmodconfig (attached as .config) compiler:

Re: [PATCH 2/2] drm/ttm: completely rework ttm_bo_delayed_delete

On 12/13/2017 09:55 PM, Thomas Hellstrom wrote: Hi, Christian, While this has probably already been committed, and looks like a nice cleanup there are two things below I think needs fixing. On 11/15/2017 01:31 PM, Christian König wrote: There is no guarantee that the next entry on the

Re: [PATCH v2] drm/drm_lease: Prevent deadlock in case drm_lease_create() fails

On Wed, Dec 13, 2017 at 08:10:48PM +0200, Marius Vlad wrote: > This case can been seen when creating the lease with the same objects passed. > > [ 605.515097] 2 locks held by testapp/3337: > [ 605.519027] #0: (>mode_config.idr_mutex){..}, at: > [] drm_mode_create_lease_ioctl+0x384/0x858

Re: [PATCH v2] drm/drm_lease: Prevent deadlock in case drm_lease_create() fails

On Wed, Dec 13, 2017 at 08:10:48PM +0200, Marius Vlad wrote: > This case can been seen when creating the lease with the same objects passed. > > [ 605.515097] 2 locks held by testapp/3337: > [ 605.519027] #0: (>mode_config.idr_mutex){..}, at: > [] drm_mode_create_lease_ioctl+0x384/0x858

[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)

https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #18 from Justin Mitzel --- I have tried using a different monitor and also using a DVI cable. Neither of these mitigated the problem in any way. I also tried setting the resolution of the monitor to 720p,

Re: [PATCH v4 13/15] ARM: dts: sun8i: a83t: Add the PWM pin group

On Thu, Dec 7, 2017 at 11:58 PM, Maxime Ripard wrote: > The A83T has a PWM that can be output from the SoC. Let's add a pinctrl > group for it. > > Reviewed-by: Chen-Yu Tsai > Signed-off-by: Maxime Ripard Might

Re: [PATCH v3 08/15] drm/sun4i: Add LVDS support

On Thu, Dec 7, 2017 at 8:25 PM, Maxime Ripard wrote: > Hi, > > On Thu, Dec 07, 2017 at 02:05:47PM +0800, Chen-Yu Tsai wrote: >> > +static void sun4i_tcon_lvds_set_status(struct sun4i_tcon *tcon, >> > + const struct drm_encoder

Re: [PATCH v4 06/15] drm/sun4i: Force the mixer rate at 150MHz

On Thu, Dec 7, 2017 at 11:58 PM, Maxime Ripard wrote: > It seems like the mixer can only run properly when clocked at 150MHz. In > order to have something more robust than simply a fire-and-forget > assigned-clocks-rate, let's put that in the code. > >

Re: [PATCH v4 03/15] dt-bindings: display: sun4i-drm: Add LVDS properties

On Thu, Dec 7, 2017 at 11:58 PM, Maxime Ripard wrote: > Some clocks and resets supposed to drive the LVDS logic in the display > engine have been overlooked when the driver was first introduced. > > Add those additional resources to the binding, and we'll deal

[PATCH] drm/ttm: init locked again to prevent incorrect unlock

Change-Id: Icc8b5112570429f24e90d52484df2728c546f85b Signed-off-by: Roger He Reviewed-by: Christian König Cc: sta...@vger.kernel.org --- drivers/gpu/drm/ttm/ttm_bo.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c

linux-next: manual merge of the drm tree with the drm-misc-fixes tree

Hi all, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/drm_edid.c between commit: 4b4df570b41d ("drm: Update edid-derived drm_display_info fields at edid property set [v2]") from the drm-misc-fixes tree and commit: c945b8c14bb7 ("drm/edid: build ELD in

[PATCH/RFC v1.1] drm: rcar-du: Allow importing non-contiguous dma-buf with VSP

When the DU sources its frames from a VSP, it performs no memory access and thus has no requirements on imported dma-buf memory types. In particular the DU could import a physically non-contiguous buffer that would later be mapped contiguously through the VSP IOMMU. This use case isn't supported

[Bug 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.

https://bugs.freedesktop.org/show_bug.cgi?id=101483 FFAB changed: What|Removed |Added Attachment #135767|0 |1 is obsolete|

[Bug 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.

https://bugs.freedesktop.org/show_bug.cgi?id=101483 --- Comment #32 from FFAB --- Upstream kernel test - kernel 4.15-rc3 BIOS upgradedfrom F.41 to F.45 Installation, on which upstream kernel was installed: ubuntu 16.04.3, kernel 4.10.0-42, updated 2017-12-11 1. booting

Re: [PATCH] drm: rework delayed connector cleanup in connector_iter

On Wed, Dec 13, 2017 at 02:35:16PM +0100, Daniel Vetter wrote: > On Wed, Dec 13, 2017 at 01:05:49PM +, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-12-13 12:49:36) > > > diff --git a/drivers/gpu/drm/drm_mode_config.c > > > b/drivers/gpu/drm/drm_mode_config.c > > > index

Re: [PATCH] 4.15 vmgfx boot warning

Hi Woody, On Wed, Nov 22, 2017 at 04:05:50PM -0500, Woody Suwalski wrote: > The 4.15 vmwgfx driver shows a warning during boot (32 bit x86) > It is caused by a mismatch between the result of vmw_enable_vblank() and > what the drm_atomic_helper expects: >    /... >    ret =

[radeon-alex:amd-staging-drm-next 374/701] sound/soc//amd/raven/pci-acp3x.c:159:1: error: type defaults to 'int' in declaration of 'module_pci_driver'

tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 367a3d2bdc27fd1d23be9ea75cec34b52297184d commit: c1888183e1764d55d51ae051bd8651e634febe4d [374/701] ASoC: AMD: enable ACP3x drivers build config: sh-allmodconfig (attached as .config) compiler: sh4-linux-gnu-gcc

Re: [PATCH] vmwgfx: use monotonic event timestamps

This looks okay to me. Although we should change eaction->tv_* type to 64-bit as well. I'll roll this in to our next pull request. thanks, Sinclair On Mon, Nov 27, 2017 at 12:16:19PM +0100, Arnd Bergmann wrote: > DRM_VMW_EVENT_FENCE_SIGNALED (struct drm_vmw_event_fence) and >

Re: [RESEND PATCH v3 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

Hi HL, On Mon, Dec 04, 2017 at 03:17:48PM +0800, Lin Huang wrote: > Refactor Innolux P079ZCA panel driver, let it support > multi panel. > > Signed-off-by: Lin Huang > --- > Changes in v2: > - Change regulator property name to meet the panel datasheet > Changes in v3: > -

[PATCH] drm/msm: gpu: Only sync fences on rings that exist

The fault recovery code tries to sync fences on all possible rings instead of only the rings that actually exist which will fault the kernel when the number of rings are less than the maximum amount. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/msm_gpu.c | 2 +-

[RFC 2/2] drm/msm: add sudo flag to submit ioctl

This flags cause cmdstream to be executed from the ringbuffer (RB) instead of IB1. Normally not something you'd ever want to do, but it is super useful for firmware debugging. Hidden behind CAP_SYS_ADMIN and a default=n kconfig option, to prevent it from being used on accident. Signed-off-by:

[RFC 1/2] drm/msm: add a5xx specific debugfs

Add some debugfs to dump out PFP and ME microcontroller state, as well as some of the queues (MEQ and ROQ). Also add a debugfs file to trigger a GPU reset (and reloading the firmware on next submit). Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/Makefile |

[RFC 0/2] drm/msm: additions for firmware debugging

A couple patches aimed in particular at simplifying firmware debugging. The first patch adds some debugfs to dump out state, as well as a debugfs file that can be written to trigger GPU reset and firmware reloading. The second patch adds a new SUBMIT ioctl flag to allow userspace to submit

[PATCH v2] x86/gpu: add CFL to early quirks

CFL was missing from intel_early_ids[]. The PCI ID needs to be there to allow the memory region to be stolen, otherwise we could have RAM being arbitrarily overwritten if for example we keep using the UEFI framebuffer, depending on how BIOS has set up the e820 map. Fixes: b056f8f3d6b9

Re: [RFC PATCH v2 00/13] Kernel based bootsplash

Unfortunately I've forgotten to rebase this patchset to 4.15, so it still builds on top of 4.14. I'll rebase it for the next roll. Max ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH v2 11/13] bootsplash: sysfs entries to load and unload files

Users can use this to replace their splash screen at runtime by writing a path and filename to /sys/devices/platform/bootsplash.0/load_file and making sure the splash is enabled. Notes: - The path has to be a path in /lib/firmware since request_firmware() is used to fetch the data. - When

[RFC PATCH v2 08/13] sysrq: Disable bootsplash on SAK

When the user requests a clean TTY via the SAK SysRq, that means he really wants to use the console. Let's disable the bootsplash, even if the request is not on a VT, as the user probably knows what he's doing and it's more helpful to get out of his way. Signed-off-by: Max Staudt

[RFC PATCH v2 02/13] bootsplash: Add file reading and picture rendering

Load logo(s) from a file and render them in the center of the screen. This removes the "black screen" functionality, which can now be emulated by providing a splash file with no pictures and a black background. Signed-off-by: Max Staudt --- MAINTAINERS

[RFC PATCH v2 07/13] vt: Add keyboard hook to disable bootsplash

Let's disable the splash if the user presses ESC or F1-F12 on a VT. The F1-F12 check is to disable the splash on VT switches. Signed-off-by: Max Staudt --- drivers/tty/vt/keyboard.c | 24 1 file changed, 24 insertions(+) diff --git

[RFC PATCH v2 12/13] tools/bootsplash: Add a basic splash file creation tool

Signed-off-by: Max Staudt --- MAINTAINERS | 1 + tools/bootsplash/.gitignore | 1 + tools/bootsplash/Makefile| 9 + tools/bootsplash/bootsplash-packer.c | 471 +++ 4 files changed, 482

[RFC PATCH v2 03/13] bootsplash: Flush framebuffer after drawing

Framebuffers with deferred I/O need to be flushed to the screen explicitly, since we use neither the mmap nor the file I/O abstractions that handle this for userspace FB clients. Example: xenfb Some framebuffer drivers implement lazy access to the screen without actually exposing a fbdefio

[RFC PATCH v2 13/13] tools/bootsplash: Add script and data to create sample file

Also, mention this in the bootsplash documentation. Signed-off-by: Max Staudt --- Documentation/bootsplash.rst | 10 ++ tools/bootsplash/.gitignore| 3 ++ tools/bootsplash/ajax-loader.gif | Bin 0 -> 3208 bytes tools/bootsplash/bootsplash-tux.sh | 66

[RFC PATCH v2 05/13] bootsplash: Add animation support

Each 'picture' in the splash file can consist of multiple 'blobs'. If animation is enabled, these blobs become the frames of an animation, in the order in which they are stored in the file. Note: There is only one global timer, so all animations happen at the same frame rate. It doesn't

[RFC PATCH v2 10/13] Documentation: Add bootsplash main documentation

Signed-off-by: Max Staudt --- .../ABI/testing/sysfs-platform-bootsplash | 11 ++ Documentation/bootsplash.rst | 177 + MAINTAINERS| 2 + 3 files changed, 190 insertions(+) create mode

[RFC PATCH v2 01/13] bootsplash: Initial implementation showing black screen

This is the initial prototype for a lean Linux kernel bootsplash. It works by replacing fbcon's FB manipulation routines (such as bitblit, tileblit) with dummy functions, effectively disabling text output, and drawing the splash directly onto the FB device. As it is now, it will show a black

[RFC PATCH v2 09/13] fbcon: Disable bootsplash on oops

Signed-off-by: Max Staudt Reviewed-by: Oliver Neukum --- drivers/video/fbdev/core/fbcon.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 9a39a6fcfe98..8a9c67e1c5d8

[RFC PATCH v2 00/13] Kernel based bootsplash

Dear fbdev and fbcon developers, Thank you very much for your input for the first patch series. I've included your feedback into this second roll, and kindly ask for your opinion on the new patch series. Changes from v1 to v2: + Added a user space tool to create splash theme files + Bumped

[RFC PATCH v2 06/13] vt: Redraw bootsplash fully on console_unblank

After exiting a KD_GRAPHICS program and falling back to the text console, a previously enabled splash needs to be fully redrawn. This corner case was introduced with selective re-drawing while implementing animations. Without this patch, the following happens: 1. Switch to a text console 2.

[RFC PATCH v2 04/13] bootsplash: Add corner positioning

This allows showing multiple logos, each in its own position, relative to the eight screen corners. Signed-off-by: Max Staudt --- drivers/video/fbdev/core/bootsplash_render.c | 136 ++- include/uapi/linux/bootsplash_file.h | 45 - 2

[Bug 104248] Black screen after switching refresh rate from 144 Hz

https://bugs.freedesktop.org/show_bug.cgi?id=104248 --- Comment #2 from Thomas Lange --- Created attachment 136150 --> https://bugs.freedesktop.org/attachment.cgi?id=136150=edit Xorg log -- You are receiving this mail because: You are the assignee for the

Re: [PATCH 1/6] drm/ttm: add on_alloc_stage and reservation into ttm_operation_ctx

Hi, I think this series is quite poorly documented. We should have a log message explaining the purpose of the commit. Also since it's not obvious what the series is attempting to achieve, please add a 0/X series header message.. /Thomas On 12/12/2017 10:33 AM, Roger He wrote:

[Bug 104248] Black screen after switching refresh rate from 144 Hz

https://bugs.freedesktop.org/show_bug.cgi?id=104248 --- Comment #1 from Thomas Lange --- Created attachment 136149 --> https://bugs.freedesktop.org/attachment.cgi?id=136149=edit Output of xrandr If you need more information, let me know. -- You are receiving this mail

[Bug 104248] Black screen after switching refresh rate from 144 Hz

https://bugs.freedesktop.org/show_bug.cgi?id=104248 Bug ID: 104248 Summary: Black screen after switching refresh rate from 144 Hz Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

Re: Non-blocking commits on -ERESTARTSYS

On 2017-12-13 12:23 PM, Maarten Lankhorst wrote: Op 13-12-17 om 17:19 schreef Leo Li: Hi Daniel, Maarten, Just digging an old thread out of the grave: https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html It's suppose to fix a memory leak on the drm_commit object during

[PATCH v2] drm/drm_lease: Prevent deadlock in case drm_lease_create() fails

This case can been seen when creating the lease with the same objects passed. [ 605.515097] 2 locks held by testapp/3337: [ 605.519027] #0: (>mode_config.idr_mutex){..}, at: [] drm_mode_create_lease_ioctl+0x384/0x858 [ 605.530045] #1: (>mode_config.idr_mutex){..}, at: []

Re: [PATCH] drm/i915: properly init lockdep class

On Wed, Dec 13, 2017 at 06:36:33PM +0100, Sebastian Andrzej Siewior wrote: > +peterz > context: http://www.spinics.net/lists/intel-gfx/msg149011.html > > On 2017-12-13 17:37:21 [+0200], Joonas Lahtinen wrote: > > On Wed, 2017-12-13 at 16:06 +0100, Sebastian Andrzej Siewior wrote: > > > On

Re: Non-blocking commits on -ERESTARTSYS

Op 13-12-17 om 17:19 schreef Leo Li: > Hi Daniel, Maarten, > > Just digging an old thread out of the grave: > https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html > > It's suppose to fix a memory leak on the drm_commit object during > non-blocking commits. Within

Re: [PATCH 25/25] drm/armada: add iturbt_709 plane property to control YUV colorspace

On Wed, Dec 13, 2017 at 11:12:18AM -0500, Ilia Mirkin wrote: > On Wed, Dec 13, 2017 at 10:41 AM, Daniel Stone wrote: > > Hi Russell, > > > > On 8 December 2017 at 12:31, Russell King > > wrote: > >> Add the defacto-standard "iturbt_709" property

[PATCH libdrm] headers: Update drm_i915.h

Generated using make header_install. Generated from drm-intel-next-queued commit 53ff2641a817099e1c6d1aef409ba004c3a9f1ea Signed-off-by: Michał Winiarski --- include/drm/i915_drm.h | 215 ++--- 1 file changed, 202

Re: [PATCH 7/8] drm/sun4i: sun4i_layer: Add a custom atomic_check for the frontend

On 13/12/2017 16:33, Maxime Ripard wrote: > Now that we have everything in place, we can start enabling the frontend. > This is more difficult than one would assume since there can only be one > plane using the frontend per-backend. > > We therefore need to make sure that the userspace will not

Re: [PATCH 25/25] drm/armada: add iturbt_709 plane property to control YUV colorspace

On Wed, Dec 13, 2017 at 10:41 AM, Daniel Stone wrote: > Hi Russell, > > On 8 December 2017 at 12:31, Russell King wrote: >> Add the defacto-standard "iturbt_709" property to the overlay plane to >> control the YUV to RGB colorspace conversion.

Re: [PATCH 6/8] drm/sun4i: sun4i_layer: Wire in the frontend

On 13/12/2017 16:33, Maxime Ripard wrote: > Now that we have a driver, we can make use of it. This is done by > adding a flag to our custom plane state that will trigger whether we should > use the frontend on that particular plane or not. > > The rest is just plumbing to set up the backend to

[Bug 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit

https://bugs.freedesktop.org/show_bug.cgi?id=103277 --- Comment #10 from Jerry Zuo --- (In reply to dwagner from comment #9) > Bad news: Tried amd-staging-drm-next as of commit > 367a3d2bdc27fd1d23be9ea75cec34b52297184d, which does include the commit >

Re: [PATCH 5/8] drm/sun4i: Add a driver for the display frontend

On 13/12/2017 16:33, Maxime Ripard wrote: > The display frontend is an hardware block that can be used to implement > some more advanced features like hardware scaling or colorspace > conversions. It can also be used to implement the output format of the VPU. > > Let's create a minimal driver for

Re: [PATCH 4/8] drm/sun4i: crtc: Add a custom crtc atomic_check

On 13/12/2017 16:33, Maxime Ripard wrote: > We have some restrictions on what the planes and CRTC can provide that are > tied to only one generation of display engines. > > For example, on the first generation, we can only have one YUV plane or one > plane that uses the frontend output. > >

Re: [PATCH 3/8] drm/sun4i: sun4i_layer: Add a custom plane state

On 13/12/2017 16:33, Maxime Ripard wrote: > We will need to store some additional data in the future to the state. > Create a custom plane state that will embed those data, in order to store > the pipe or whether or not that plane should use the frontend. > > Signed-off-by: Maxime Ripard

Re: [PATCH 2/8] drm/sun4i: backend: Allow a NULL plane pointer to retrieve the format

On 13/12/2017 16:33, Maxime Ripard wrote: > The function converting the DRM format to its equivalent in the backend > registers was assuming that we were having a plane. > > However, we might want to use that function when setting up a plane using > the frontend, in which case we will not have a

Re: [PATCH 1/8] drm/sun4i: backend: Move line stride setup to buffer setup function

On 13/12/2017 16:33, Maxime Ripard wrote: > Setup the line stride in the buffer setup function, since it's tied to the > buffer itself, and is not needed when we do not set the buffer in the > backend. > > This is for example the case when using the frontend and then routing its > output to the

Re: [PATCH 25/25] drm/armada: add iturbt_709 plane property to control YUV colorspace

Hi Russell, On 8 December 2017 at 12:31, Russell King wrote: > Add the defacto-standard "iturbt_709" property to the overlay plane to > control the YUV to RGB colorspace conversion. This is mutually > exclusive with the CSC_YUV CRTC property - the last property to be

Re: [PATCH] drm/i915: properly init lockdep class

On Wed, 2017-12-13 at 16:06 +0100, Sebastian Andrzej Siewior wrote: > On 2017-12-13 16:00:49 [+0200], Joonas Lahtinen wrote: > > On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote: > > > The code has an ifdef and uses two functions to either init the bare > > > spinlock or init it

[PATCH 8/8] ARM: dts: sun8i: a33 Enable our display frontend

The display frontend can be used to do hardware scaling, colorspaces conversion or to implement the buffer format output by the Cedar VPU. Since we're starting to have some support for it in the DRM driver, let's enable its DT node. Signed-off-by: Maxime Ripard

[PATCH 0/8] drm/sun4i: Support the Display Engine frontend

Hi, This is a first serie to enable the display engine frontend. This hardware block is found in the first generation Display Engine from Allwinner. Its role is to implement more advanced features that the associated backend, even though the backend alone can be used (and was used so far) for

[PATCH 6/8] drm/sun4i: sun4i_layer: Wire in the frontend

Now that we have a driver, we can make use of it. This is done by adding a flag to our custom plane state that will trigger whether we should use the frontend on that particular plane or not. The rest is just plumbing to set up the backend to not perform the DMA but receive its data from the

[PATCH 1/8] drm/sun4i: backend: Move line stride setup to buffer setup function

Setup the line stride in the buffer setup function, since it's tied to the buffer itself, and is not needed when we do not set the buffer in the backend. This is for example the case when using the frontend and then routing its output to the backend. Signed-off-by: Maxime Ripard

[PATCH 4/8] drm/sun4i: crtc: Add a custom crtc atomic_check

We have some restrictions on what the planes and CRTC can provide that are tied to only one generation of display engines. For example, on the first generation, we can only have one YUV plane or one plane that uses the frontend output. Let's allow our engines to provide an atomic_check callback

[PATCH 3/8] drm/sun4i: sun4i_layer: Add a custom plane state

We will need to store some additional data in the future to the state. Create a custom plane state that will embed those data, in order to store the pipe or whether or not that plane should use the frontend. Signed-off-by: Maxime Ripard ---

[PATCH 2/8] drm/sun4i: backend: Allow a NULL plane pointer to retrieve the format

The function converting the DRM format to its equivalent in the backend registers was assuming that we were having a plane. However, we might want to use that function when setting up a plane using the frontend, in which case we will not have a plane associated to the backend's layer. Yet, we

[PATCH 7/8] drm/sun4i: sun4i_layer: Add a custom atomic_check for the frontend

Now that we have everything in place, we can start enabling the frontend. This is more difficult than one would assume since there can only be one plane using the frontend per-backend. We therefore need to make sure that the userspace will not try to setup multiple planes using it, since that

[PATCH 5/8] drm/sun4i: Add a driver for the display frontend

The display frontend is an hardware block that can be used to implement some more advanced features like hardware scaling or colorspace conversions. It can also be used to implement the output format of the VPU. Let's create a minimal driver for it that will only enable the hardware scaling

Re: [Intel-gfx] [PATCH v6 0/5] drm/i915: Expose more GPU properties through sysfs

On 13/12/17 13:35, Chris Wilson wrote: Quoting Daniel Vetter (2017-12-13 08:17:17) On Tue, Dec 12, 2017 at 02:33:38PM +, Lionel Landwerlin wrote: On 12/12/17 11:19, Tvrtko Ursulin wrote: On 11/12/2017 21:05, Daniel Vetter wrote: On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin

Re: [Intel-gfx] [PATCH v6 0/5] drm/i915: Expose more GPU properties through sysfs

On 13/12/17 08:17, Daniel Vetter wrote: On Tue, Dec 12, 2017 at 02:33:38PM +, Lionel Landwerlin wrote: On 12/12/17 11:19, Tvrtko Ursulin wrote: On 11/12/2017 21:05, Daniel Vetter wrote: On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote: On 11/12/2017 10:50, Joonas Lahtinen

Re: [PATCH 25/25] drm/armada: add iturbt_709 plane property to control YUV colorspace

On Fri, Dec 08, 2017 at 12:31:08PM +, Russell King wrote: > Add the defacto-standard "iturbt_709" property to the overlay plane to > control the YUV to RGB colorspace conversion. This is mutually > exclusive with the CSC_YUV CRTC property - the last property to be set > determines the

[PATCH] drm/panel: Add support for AUO G104SN02 V2 panel

This patch adds support for AUO G104SN02 V2 800x600 10.4" panel to DRM simple panel driver. Signed-off-by: Christoph Fritz Signed-off-by: Stefan Riedmueller --- .../bindings/display/panel/auo,g104sn02.txt| 7 ++

Re: [PATCH] drm/i915: properly init lockdep class

On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote: > The code has an ifdef and uses two functions to either init the bare > spinlock or init it and set a lock-class. It is possible to do the same > thing without an ifdef. > With this patch (in debug case) we first use the

Re: [PATCH] drm: Update edid-derived drm_display_info fields at edid property set [v2]

On Wed, Dec 13, 2017 at 12:44:26AM -0800, Keith Packard wrote: > There are a set of values in the drm_display_info structure for each > connector which hold information derived from EDID. These are computed > in drm_add_display_info. Before this patch, that was only called in > drm_add_edid_modes.

Re: [Intel-gfx] [PATCH v6 0/5] drm/i915: Expose more GPU properties through sysfs

Quoting Daniel Vetter (2017-12-13 08:17:17) > On Tue, Dec 12, 2017 at 02:33:38PM +, Lionel Landwerlin wrote: > > On 12/12/17 11:19, Tvrtko Ursulin wrote: > > > > > > On 11/12/2017 21:05, Daniel Vetter wrote: > > > > On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote: > > > > > On

Re: [PATCH] drm: rework delayed connector cleanup in connector_iter

On Wed, Dec 13, 2017 at 01:05:49PM +, Chris Wilson wrote: > Quoting Daniel Vetter (2017-12-13 12:49:36) > > PROBE_DEFER also uses system_wq to reprobe drivers, which means when > > that again fails, and we try to flush the overall system_wq (to get > > all the delayed connectore cleanup

Re: [PATCH 1/3] drm: drm_fourcc: Add scaling and padding factor to drm_format_info

On Wed, Dec 13, 2017 at 01:48:28AM +, Hyun Kwon wrote: > Hi Laurent, > > Thanks for the comment. > > > -Original Message- > > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > > Sent: Monday, December 11, 2017 6:02 AM > > To: Hyun Kwon > > Cc:

Re: [PATCH] drm: rework delayed connector cleanup in connector_iter

Quoting Daniel Vetter (2017-12-13 12:49:36) > PROBE_DEFER also uses system_wq to reprobe drivers, which means when > that again fails, and we try to flush the overall system_wq (to get > all the delayed connectore cleanup work_struct completed), we > deadlock. > > Fix this by using just a single

Re: [PATCH] drm: rework delayed connector cleanup in connector_iter

Hi Daniel, On 2017-12-13 13:49, Daniel Vetter wrote: PROBE_DEFER also uses system_wq to reprobe drivers, which means when that again fails, and we try to flush the overall system_wq (to get all the delayed connectore cleanup work_struct completed), we deadlock. Fix this by using just a single

[PATCH] drm: rework delayed connector cleanup in connector_iter

PROBE_DEFER also uses system_wq to reprobe drivers, which means when that again fails, and we try to flush the overall system_wq (to get all the delayed connectore cleanup work_struct completed), we deadlock. Fix this by using just a single cleanup work, so that we can only flush that one and

Re: [PATCH] drm: rework delayed connector cleanup in connector_iter

Hi Daniel, On 2017-12-13 11:45, Daniel Vetter wrote: PROBE_DEFER also uses system_wq to reprobe drivers, which means when that again fails, and we try to flush the overall system_wq (to get all the delayed connectore cleanup work_struct completed), we deadlock. Fix this by using just a single

Re: [PATCHv2] drm/sun4i: validate modes for HDMI

Hi, On 13-12-2017 11:05, Hans Verkuil wrote: > On 13/12/17 11:30, Maxime Ripard wrote: >> Hi Hans, >> >> On Fri, Dec 08, 2017 at 04:48:47PM +0100, Hans Verkuil wrote: >>> When I connected my cubieboard running 4.15-rc1 to my 4k display I got no >>> picture. Some >>> digging found that there is

Re: [PATCHv2] drm/sun4i: validate modes for HDMI

On 13/12/17 11:30, Maxime Ripard wrote: > Hi Hans, > > On Fri, Dec 08, 2017 at 04:48:47PM +0100, Hans Verkuil wrote: >> When I connected my cubieboard running 4.15-rc1 to my 4k display I got no >> picture. Some >> digging found that there is no check against the upper pixelclock limit of >> the

Re: [PATCH] drm: rework delayed connector cleanup in connector_iter

Quoting Daniel Vetter (2017-12-13 10:45:53) > PROBE_DEFER also uses system_wq to reprobe drivers, which means when > that again fails, and we try to flush the overall system_wq (to get > all the delayed connectore cleanup work_struct completed), we > deadlock. > > Fix this by using just a single

Re: [PATCH] MAINTAINERS: Remove Jani as drm-misc co-maintainer

On Wed, 29 Nov 2017, Gustavo Padovan wrote: > 2017-11-24 Sean Paul : > >> On Thu, Nov 23, 2017, 7:12 AM Jani Nikula wrote: >> >> > I'm juggling too many things, and drm-misc maintenance is one that I >> > keep dropping on the

[PATCH] drm: rework delayed connector cleanup in connector_iter

PROBE_DEFER also uses system_wq to reprobe drivers, which means when that again fails, and we try to flush the overall system_wq (to get all the delayed connectore cleanup work_struct completed), we deadlock. Fix this by using just a single cleanup work, so that we can only flush that one and

Re: [PATCH] drm: Fix possible deadlock in drm_mode_config_cleanup()

On Wed, Dec 13, 2017 at 09:57:20AM +0100, Marek Szyprowski wrote: > drm_mode_config_cleanup() might be called from a workqueue context (for > example in error path handling of deferred probe), so it must not call > flush_scheduled_work(), because it would deadlock in such case. Replace > that call

Re: [PATCH] drm/drm_lease: Do not call drm_master_put() twice in case drm_lease_create() fails

On Wed, Dec 13, 2017 at 09:18:55AM +, Marius-cristian Vlad wrote: > Well I don't have an igt test for it, but here's what happens when I try to > create a new lease which hasn't been revoked (so, it's currently created but > not revoked and > trying to create a new one): > > [ 210.347052]

Re: [PATCHv2] drm/sun4i: validate modes for HDMI

Hi Hans, On Fri, Dec 08, 2017 at 04:48:47PM +0100, Hans Verkuil wrote: > When I connected my cubieboard running 4.15-rc1 to my 4k display I got no > picture. Some > digging found that there is no check against the upper pixelclock limit of > the HDMI > output, so X selects a 4kp60 format at 594

Re: [PATCH 3/3] drm/ttm: enable eviction for Per-VM-BO

Am 13.12.2017 um 06:17 schrieb Roger He: Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62 Signed-off-by: Roger He --- drivers/gpu/drm/ttm/ttm_bo.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c

Re: [PATCH 2/3] drm/amd/amdgpu: init allow_reserved_eviction and resv when create a new bo

On 2017-12-13 06:17 AM, Roger He wrote: > Change-Id: I0c6571c2a64e6c5bdad80ccbcccb40eba1c20b4e > Signed-off-by: Roger He > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH 2/3] drm/amd/amdgpu: init allow_reserved_eviction and resv when create a new bo

Am 13.12.2017 um 06:17 schrieb Roger He: Change-Id: I0c6571c2a64e6c5bdad80ccbcccb40eba1c20b4e Signed-off-by: Roger He We should supply the resv object in amdgpu_cs_bo_validate() as well, or otherwise the deleted object handling won't work as desired any more. Apart from

Re: [PATCH 1/3] drm/ttm: add allow_reserved_eviction and resv into ttm_operation_ctx

Am 13.12.2017 um 06:17 schrieb Roger He: allow_reserved_eviction: Allow eviction of reserved BOs resv: Reservation object to allow reserved evictions with Change-Id: I01ea482e8c7470014196eb218e2ff8913306eef0 Signed-off-by: Roger He Reviewed-by: Christian König

Re: [PATCH v2 2/7] drm/i2c: tda998x: move CEC device initialisation later

On Tue, Dec 12, 2017 at 03:37:21PM +0100, Hans Verkuil wrote: > Hi Russell, > > On 08/12/17 12:59, Russell King - ARM Linux wrote: > > On Wed, Dec 06, 2017 at 02:54:04PM +0100, Hans Verkuil wrote: > >> On 12/06/17 13:35, Russell King wrote: > >>> We no longer use the CEC client to access the CEC

Re: [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()

On 12/12/2017 9:04 AM, Joonas Lahtinen wrote: > Hi, > > I sent this individual i915 patch to our CI, and it is passing on all > platforms: > > https://patchwork.freedesktop.org/series/34822/ > > Is it ok if I merge this to drm-tip already? As long as you have this change in your tree, it

Re: [PATCH] drm/i915/gvt/fb_decoder: Fix out-of-bounds read

Hi Zhenyu, Quoting Zhenyu Wang : On 2017.12.09 00:37:59 -0600, Gustavo A. R. Silva wrote: In case function skl_format_to_drm returns -EINVAL, fmt turns into a huge number as fmt is of type u32, hence there is an out-of-bounds read when using fmt as an index for array

[PATCH libdrm] android: make libdrm*.so available to the vendor partition

libdrm_.so are moved to the vendor partition (/vendor/lib or /system/vendor/lib if there is no dedicated vendor partition), since they are vendor-specific extension that must not be in the system partition which should be generic. libdrm.so (which is generic) is built/installed twice: once to

Re: UDL's fbdev doesn't work for user-space apps

Hi Pavel, On Sat, 2017-12-09 at 18:20 +0100, Pavel Machek wrote: > On Mon 2017-12-04 11:50:40, Jose Abreu wrote: > > > > Hi Alexey, > > > > On 04-12-2017 11:32, Alexey Brodkin wrote: > > > > > > My first [probably incorrect] assumption is Xserver requires fbdev > > > (/dev/fbX) > > > and it

Re: mmotm 2017-12-12-16-32 uploaded (drivers/gpu/drm/i915/)

On 12/12/2017 04:32 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2017-12-12-16-32 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of

  1   2   >