Re: [PATCH v2 00/14] YCBCR 4:2:0 handling in DRM layer

Regards Shashank On 7/15/2017 12:32 AM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 09:03:06PM +0530, Shashank Sharma wrote: Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format, which is currently supported on HDMI 2.0 sources/sinks. Due to lower chroma sub-sampling rate,

Re: [PATCH v2 12/14] drm/i915: prepare csc unit for YCBCR420 output

Regards Shashank On 7/15/2017 12:06 AM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 09:03:18PM +0530, Shashank Sharma wrote: To support ycbcr output, we need a pipe CSC block to do RGB->YCBCR conversion. Current Intel platforms have only one pipe CSC unit, so we can either do color

Re: [PATCH v2 11/14] drm/i915: prepare pipe for YCBCR420 output

Regards Shashank On 7/15/2017 12:03 AM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 09:03:17PM +0530, Shashank Sharma wrote: To get HDMI YCBCR420 output, the PIPEMISC register should be programmed to: - Generate YCBCR output (bit 11) - In case of YCBCR420 outputs, it should be programmed in

Re: [PATCH v2 10/14] drm/i915: prepare scaler for YCBCR420 modeset

Regards Shahank On 7/15/2017 12:00 AM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 09:03:16PM +0530, Shashank Sharma wrote: To get a YCBCR420 output from intel platforms, we need one scaler to scale down YCBCR444 samples to YCBCR420 samples. This patch: - Does scaler allocation for HDMI

Re: [PATCH v2 09/14] drm/i915: add config function for YCBCR420 outputs

Regards Shashank On 7/15/2017 12:00 AM, Ville Syrjälä wrote: On Thu, Jul 13, 2017 at 09:03:15PM +0530, Shashank Sharma wrote: This patch checks encoder level support for YCBCR420 outputs. The logic goes as simple as this: If the input mode is YCBCR420-only mode: prepare HDMI for YCBCR420

Re: [PATCH 1/2] drm: Implement vm_operations_struct.access

On 15/07/17 04:47 AM, Felix Kuehling wrote: > On 17-07-13 11:26 PM, Michel Dänzer wrote: >> On 14/07/17 06:08 AM, Felix Kuehling wrote: >>> Allows gdb to access contents of user mode mapped BOs. VRAM access >>> requires the driver to implement a new callback in ttm_bo_driver. >> Thanks for doing

Re: [PATCH 6/8] drm: Allow DSI devices to be registered before the host registers.

Archit Taneja writes: > On 06/29/2017 04:09 PM, Andrzej Hajda wrote: >> On 29.06.2017 07:03, Archit Taneja wrote: >>> >>> On 06/28/2017 01:28 AM, Eric Anholt wrote: When a mipi_dsi_host is registered, the DT is walked to find any child nodes with compatible

Re: [PATCH 6/8] drm: Allow DSI devices to be registered before the host registers.

Archit Taneja writes: > On 06/28/2017 01:28 AM, Eric Anholt wrote: >> When a mipi_dsi_host is registered, the DT is walked to find any child >> nodes with compatible strings. Those get registered as DSI devices, >> and most DSI panel drivers are mipi_dsi_drivers that

[PATCH 1/3] drm/atomic-helper: Fix leak in disable_all

The legacy plane->fb pointer is refcounted by calling drm_atomic_clean_old_fb(). In practice this isn't a real problem because: - The caller in the i915 gpu reset code restores the original state again, which means the plane->fb pointer won't change, hence can't leak. - Drivers using

[PATCH 3/3] drm/i915: unregister interfaces first in unload

We first need to make sure no one else can get at us anymore, before we can proceed to tear down all the datastructures. Just a small step towards eventually the perfect unload code ... Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter ---

[PATCH 2/3] drm/i915: Fix fbdev unload sequence

First thing we need to do is unregister the fbdev instance, but we can't just go ahead and kfree it. That must wait until the hotplug and polling work are stopped, since they can race with the with the teardown. That means we need to split up the fbdev teardown into the unregister part and the

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler wrote: > On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula > wrote: >> On Thu, 13 Jul 2017, Stéphane Marchesin wrote: >>> So, if you think this is wrong, can you fix this

Re: [PATCH] drm/vc4: Fix VBLANK handling in crtc->enable() path

Boris Brezillon writes: > When we are enabling a CRTC, drm_crtc_vblank_get() is called before > drm_crtc_vblank_on(), which is not supposed to happen (hence the > WARN_ON() in the code). To solve the problem, we delay the 'update > display list' operation

Re: [PATCH, RESEND 03/14] drm/vmwgfx: avoid gcc-7 parentheses warning

On Fri, Jul 14, 2017 at 9:23 PM, Linus Torvalds wrote: > On Fri, Jul 14, 2017 at 12:21 PM, Linus Torvalds > wrote: >> >> NAK. This takes unintentionally insane code and turns it intentionally >> insane. Any non-zero return is

Re: [PATCH 1/2] drm: Implement vm_operations_struct.access

On 17-07-13 11:26 PM, Michel Dänzer wrote: > On 14/07/17 06:08 AM, Felix Kuehling wrote: >> Allows gdb to access contents of user mode mapped BOs. VRAM access >> requires the driver to implement a new callback in ttm_bo_driver. > Thanks for doing this. Looks mostly good, but I still have some

Re: [PATCH 08/14] Input: adxl34x - fix gcc-7 -Wint-in-bool-context warning

On Fri, Jul 14, 2017 at 9:24 PM, Linus Torvalds wrote: > On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote: >> FIFO_MODE is an macro expression with a '<<' operator, which >> gcc points out could be misread as a '<': > > Yeah, no, NAK again. > >

Re: [PATCH 1/2] drm: Implement vm_operations_struct.access

On 17-07-14 06:06 AM, Christian König wrote: > Am 13.07.2017 um 23:08 schrieb Felix Kuehling: >> Allows gdb to access contents of user mode mapped BOs. VRAM access >> requires the driver to implement a new callback in ttm_bo_driver. > > One more comment additionally to what Michel already wrote

Re: [PATCH 2/2] drm/amdgpu: Implement ttm_bo_driver.access_vram callback

On 17-07-14 06:08 AM, Christian König wrote: > Am 13.07.2017 um 23:08 schrieb Felix Kuehling: >> Allows gdb to access contents of user mode mapped VRAM BOs. >> >> Signed-off-by: Felix Kuehling >> --- >> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 59 >>

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, Jul 14, 2017 at 06:33:01PM +0200, Mike Galbraith wrote: > On Fri, 2017-07-14 at 18:10 +0200, Peter Zijlstra wrote: > > On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote: > > > On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote: > > > > > > Urgh, is for some mysterious

Re: [Intel-gfx] [PATCH 3/3] drm/i915: unregister interfaces first in unload

Quoting Daniel Vetter (2017-07-14 20:14:39) > We first need to make sure no one else can get at us anymore, > before we can proceed to tear down all the datastructures. > > Just a small step towards eventually the perfect unload code ... > > Signed-off-by: Daniel Vetter

Re: [PATCH 2/3] drm/i915: Fix fbdev unload sequence

Quoting Daniel Vetter (2017-07-14 20:14:38) Second nit: > +void intel_fbdev_fini(struct drm_i915_private *dev_priv) > +{ > + struct intel_fbdev *ifbdev = dev_priv->fbdev; > + > + if (!ifbdev) > + return; > + > intel_fbdev_destroy(ifbdev); >

Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

On Fri, Jul 14, 2017 at 3:09 PM, Dan Carpenter wrote: > On Fri, Jul 14, 2017 at 03:55:26PM +0300, Dan Carpenter wrote: >> I don't agree with it as a static analysis dev... > > What I mean is if it's a macro that returns -ENODEV or a function that > returns -ENODEV, they

Re: [PATCH 2/3] drm/i915: Fix fbdev unload sequence

Quoting Daniel Vetter (2017-07-14 20:14:38) > First thing we need to do is unregister the fbdev instance, but we > can't just go ahead and kfree it. That must wait until the hotplug and > polling work are stopped, since they can race with the with the > teardown. That means we need to split up the

Re: [PATCH 1/3] drm/atomic-helper: Fix leak in disable_all

Quoting Daniel Vetter (2017-07-14 20:14:37) > The legacy plane->fb pointer is refcounted by calling > drm_atomic_clean_old_fb(). > > In practice this isn't a real problem because: > - The caller in the i915 gpu reset code restores the original state > again, which means the plane->fb pointer

Re: [PATCH 08/14] Input: adxl34x - fix gcc-7 -Wint-in-bool-context warning

On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote: > FIFO_MODE is an macro expression with a '<<' operator, which > gcc points out could be misread as a '<': Yeah, no, NAK again. We don't make the code look worse just because gcc is being a f*cking moron about things. This

Re: [PATCH, RESEND 03/14] drm/vmwgfx: avoid gcc-7 parentheses warning

On Fri, Jul 14, 2017 at 12:21 PM, Linus Torvalds wrote: > > NAK. This takes unintentionally insane code and turns it intentionally > insane. Any non-zero return is considered an error. > > The right fix is almost certainly to just return -EINVAL unconditionally.

Re: [PATCH, RESEND 03/14] drm/vmwgfx: avoid gcc-7 parentheses warning

On Fri, Jul 14, 2017 at 2:25 AM, Arnd Bergmann wrote: > - return capable(CAP_SYS_ADMIN) ? : -EINVAL; > + return capable(CAP_SYS_ADMIN) ? 1 : -EINVAL; NAK. This takes unintentionally insane code and turns it intentionally insane. Any non-zero return is considered an

Re: [PATCH] dma-buf/fence: Avoid use of uninitialised timestamp

2017-07-11 Chris Wilson : > Quoting Chris Wilson (2017-02-14 12:40:01) > > [ 236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized > > memory (8802538683d0) > > [ 236.828642] > > 42001e7f0008 > >

[PATCH 3/3] drm/i915: unregister interfaces first in unload

We first need to make sure no one else can get at us anymore, before we can proceed to tear down all the datastructures. Just a small step towards eventually the perfect unload code ... Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_drv.c | 2 +- 1 file

[PATCH 2/3] drm/i915: Fix fbdev unload sequence

First thing we need to do is unregister the fbdev instance, but we can't just go ahead and kfree it. That must wait until the hotplug and polling work are stopped, since they can race with the with the teardown. That means we need to split up the fbdev teardown into the unregister part and the

[PATCH 1/3] drm/atomic-helper: Fix leak in disable_all

The legacy plane->fb pointer is refcounted by calling drm_atomic_clean_old_fb(). In practice this isn't a real problem because: - The caller in the i915 gpu reset code restores the original state again, which means the plane->fb pointer won't change, hence can't leak. - Drivers using

Re: [Intel-gfx] [PATCH 2/4] drm: Create a format/modifier blob

On Fri, Jul 14, 2017 at 11:41:49AM -0700, Ben Widawsky wrote: > On 17-06-29 22:49:44, Ville Syrjälä wrote: > > [snip] > > > > >... but here it's ALIGN(formats_offset+formats_size). I think we should > >be aligning the same thing in both cases, or we add a BUILD_BUG_ON to > >make sure the header

Re: [PATCH v2 00/14] YCBCR 4:2:0 handling in DRM layer

On Thu, Jul 13, 2017 at 09:03:06PM +0530, Shashank Sharma wrote: > Following YCBCR 4:4:4 and 4:2:2, YCBCR 4:2:0 is a new output format, > which is currently supported on HDMI 2.0 sources/sinks. Due to lower > chroma sub-sampling rate, YCBCR 4:2:0 can drive the video modes at half > the pixel clock

Re: [Intel-gfx] [PATCH 2/4] drm: Create a format/modifier blob

On 17-06-29 22:49:44, Ville Syrjälä wrote: [snip] ... but here it's ALIGN(formats_offset+formats_size). I think we should be aligning the same thing in both cases, or we add a BUILD_BUG_ON to make sure the header size always stays a multiple of 8 bytes. That's mainly because the design of

Re: [PATCH v2 12/14] drm/i915: prepare csc unit for YCBCR420 output

On Thu, Jul 13, 2017 at 09:03:18PM +0530, Shashank Sharma wrote: > To support ycbcr output, we need a pipe CSC block to do > RGB->YCBCR conversion. > > Current Intel platforms have only one pipe CSC unit, so > we can either do color correction using it, or we can perform > RGB->YCBCR conversion.

Re: [PATCH v2 11/14] drm/i915: prepare pipe for YCBCR420 output

On Thu, Jul 13, 2017 at 09:03:17PM +0530, Shashank Sharma wrote: > To get HDMI YCBCR420 output, the PIPEMISC register should be > programmed to: > - Generate YCBCR output (bit 11) > - In case of YCBCR420 outputs, it should be programmed in full > blend mode to use the scaler in 5x3 ratio (bits

Re: [PATCH v2 09/14] drm/i915: add config function for YCBCR420 outputs

On Thu, Jul 13, 2017 at 09:03:15PM +0530, Shashank Sharma wrote: > This patch checks encoder level support for YCBCR420 outputs. > The logic goes as simple as this: > If the input mode is YCBCR420-only mode: prepare HDMI for > YCBCR420 output, else continue with RGB output mode. > > It checks if

Re: [PATCH v2 10/14] drm/i915: prepare scaler for YCBCR420 modeset

On Thu, Jul 13, 2017 at 09:03:16PM +0530, Shashank Sharma wrote: > To get a YCBCR420 output from intel platforms, we need one > scaler to scale down YCBCR444 samples to YCBCR420 samples. > > This patch: > - Does scaler allocation for HDMI ycbcr420 outputs. > - Programs PIPE_MISC register for

Jetson TK1 & HDMI output in mainline kernel

Hi Mikko, Thierry, While setting up my Jetson TK1 using the mainline kernel I discovered that the HDMI output didn't work. After some more debugging I discovered that this commit 404bfb78daf3bedafb0bfab24947059575cbea3d (gpu: host1x: Add IOMMU support) was the culprit. As far as I understand

Re: [PATCH 3/3] drm/ttm: add transparent huge page support for DMA allocations

On Thu, Jul 13, 2017 at 9:56 AM, Christian König wrote: > From: Christian König > > Try to allocate huge pages when it makes sense. > > Signed-off-by: Christian König > --- > drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote: > On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote: > > Urgh, is for some mysterious reason the __bug_table section of modules > > ending up in RO memory? > > > > I forever get lost in that link magic :/ > > +1 > > drm.ko >

Re: Linux: Smooth splashscreen with system having weston with drm-backend

On Thu, Jul 13, 2017 at 03:50:56PM +0200, Daniel Vetter wrote: > On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil wrote: > > Dear All, > > > > I am looking for an solution to have early smooth splashscreen on the > > Linux system with Weston and drm-backend. > > > > I tried

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, Jul 14, 2017 at 11:20:01AM -0400, Ilia Mirkin wrote: > On Fri, Jul 14, 2017 at 11:19 AM, Tobias Klausmann > wrote: > > The conversion is a nice catch, but i'd like to have a bit more context, see > > below! > > > > With a better description: > > > >

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, Jul 14, 2017 at 03:36:08PM +0200, Mike Galbraith wrote: > Ok, a network outage gave me time to go hunting.  Indeed it is a bad > interaction with the tree DRM merged into.  All DRM did was to slip a > WARN_ON_ONCE() that nouveau triggers into a kernel module where such > things no longer

Re: [PATCH 2/3] drm/ttm: cleanup ttm_page_alloc_dma.c

On Thu, Jul 13, 2017 at 9:56 AM, Christian König wrote: > From: Christian König > > Remove unused defines and variables. Also stop computing the > gfp_flags when they aren't used. > > No intended functional change. > > Signed-off-by: Christian

Re: [PATCH 1/3] drm/ttm: add support for different pool sizes

On Thu, Jul 13, 2017 at 9:56 AM, Christian König wrote: > From: Christian König > > Correctly handle different page sizes in the memory accounting. > > Signed-off-by: Christian König I'd split this patch in two, one

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, Jul 14, 2017 at 11:19 AM, Tobias Klausmann wrote: > The conversion is a nice catch, but i'd like to have a bit more context, see > below! > > With a better description: > > Tobias Klausmann I don't think it was

[PATCH i-g-t v2 7/7] kms_writeback: Add tests using a cloned output

From: Brian Starkey Update the connector search to also optionally attempt to find a non-writeback connector to clone to. Add a subtest which is the same as writeback-check-output, but also clones to the second connector. Signed-off-by: Brian Starkey

[PATCH i-g-t v2 2/7] lib/igt_kms: Add writeback support in lib/

From: Brian Starkey Add support in igt_kms for Writeback connectors, with the ability to attach framebuffers and retrieve fences. Signed-off-by: Brian Starkey --- lib/igt_aux.c | 1 + lib/igt_kms.c | 76

[PATCH i-g-t v2 3/7] kms_writeback: Add initial writeback tests

From: Brian Starkey Add tests for the WRITEBACK_PIXEL_FORMATS, WRITEBACK_OUT_FENCE_PTR and WRITEBACK_FB_ID properties on writeback connectors, ensuring their behaviour is correct. Signed-off-by: Brian Starkey --- lib/igt_kms.c | 6 +-

[PATCH i-g-t v2 4/7] lib: Add function to hash a framebuffer

From: Brian Starkey To use writeback buffers as a CRC source, we need to be able to hash them. Implement a simple FVA-1a hashing routine for this purpose. Doing a bytewise hash on the framebuffer directly can be very slow if the memory is noncached. By making a copy of

[PATCH i-g-t v2 1/7] igt: lib/igt_crc: Split out CRC functionality

From: Brian Starkey Separate out the CRC code for better compartmentalisation. Should ease the addition of more/different CRC sources in the future. Signed-off-by: Brian Starkey --- lib/Makefile.sources | 2 + lib/igt_chamelium.h

[PATCH i-g-t v2 6/7] lib/igt_kms: Add igt_output_clone_pipe for cloning

From: Brian Starkey An output can be added as a clone of any other output(s) attached to a pipe using igt_output_clone_pipe() Signed-off-by: Brian Starkey --- lib/igt_kms.c | 90 +--

[PATCH i-g-t v2 5/7] kms_writeback: Add writeback-check-output

From: Brian Starkey Add a test which makes commits using the writeback connector, and checks the output buffer hash to make sure it is/isn't written as appropriate. Signed-off-by: Brian Starkey --- tests/kms_writeback.c | 123

[PATCH i-g-t v2 0/7] igt: Add support for testing writeback connectors

We're trying to introduce support for writeback connectors, a way to expose in DRM the hardware functionality from display engines that allows to write back into memory the result of the DE's composition of supported planes. Generic DRM support is available here [1] and will be merged once this

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, Jul 14, 2017 at 11:15 AM, Mike Galbraith wrote: > On Fri, 2017-07-14 at 17:10 +0200, Karol Herbst wrote: >> Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE >> usage we could convert to WARN_ONCE? > > Shooting the messenger is generally considered uncool

Re: [Intel-gfx] [PATCH v2 12/12] drm/atomic: Allow drm_atomic_helper_swap_state to fail

On Tue, Jul 11, 2017 at 04:33:14PM +0200, Maarten Lankhorst wrote: > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/drm_atomic_helper.c | 15 +++ > 1 file changed, 7 insertions(+), 8 deletions(-) > > diff --git

Re: [Intel-gfx] [PATCH v2 11/12] drm/atomic: Add __must_check to drm_atomic_helper_swap_state.

On Tue, Jul 11, 2017 at 04:33:13PM +0200, Maarten Lankhorst wrote: > Now that all drivers check the return value, convert swap_state to > __must_check. This is done separately to force build warnings if we > missed a driver. > > Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH v2 10/12] drm/vc4: Handle drm_atomic_helper_swap_state failure

On Tue, Jul 11, 2017 at 04:33:12PM +0200, Maarten Lankhorst wrote: > drm_atomic_helper_swap_state() will be changed to interruptible waiting > in the next few commits, so all drivers have to be changed to handling > failure. > > VC4 has its own nonblocking modeset tracking through the

Re: [Intel-gfx] [PATCH v2 08/12] drm/tegra: Handle drm_atomic_helper_swap_state failure

On Tue, Jul 11, 2017 at 04:33:10PM +0200, Maarten Lankhorst wrote: > drm_atomic_helper_swap_state() will be changed to interruptible waiting > in the next few commits, so all drivers have to be changed to handling > failure. > > Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH v2 07/12] drm/msm: Handle drm_atomic_helper_swap_state failure

On Tue, Jul 11, 2017 at 04:33:09PM +0200, Maarten Lankhorst wrote: > drm_atomic_helper_swap_state() will be changed to interruptible waiting > in the next few commits, so all drivers have to be changed to handling > failure. > > MSM has its own busy tracking, which means the swap_state call can

Re: [Intel-gfx] [PATCH v2 00/12] drm/atomic: Make drm_atomic_helper_swap_state waiting interruptible.

On Tue, Jul 11, 2017 at 04:33:02PM +0200, Maarten Lankhorst wrote: > drm_atomic_helper_swap_state could previously never fail, in order to still > continue it would set a limit of 10s on waiting for previous updates to > complete, > then it moved forward. This can be very bad when ignoring

Re: [Intel-gfx] [PATCH v2 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

On Fri, Jul 14, 2017 at 04:30:30PM +0200, Daniel Vetter wrote: > On Tue, Jul 11, 2017 at 04:33:04PM +0200, Maarten Lankhorst wrote: > > We want to change swap_state to wait indefinitely, but to do this > > swap_state should wait interruptibly. This requires propagating > > the error to each

[PATCH] drm/etnaviv: select CMA and DMA_CMA if available

While this is no build dependency, etnaviv will only work correctly on most systems if CMA and DMA_CMA are enabled. Select both options if available to avoid users ending up with a non-working GPU due to a lacking kernel config. Signed-off-by: Lucas Stach ---

Re: [Intel-gfx] [PATCH v2 02/12] drm/atomic: Change drm_atomic_helper_swap_state to return an error.

On Tue, Jul 11, 2017 at 04:33:04PM +0200, Maarten Lankhorst wrote: > We want to change swap_state to wait indefinitely, but to do this > swap_state should wait interruptibly. This requires propagating > the error to each driver. > > Cc: dri-devel@lists.freedesktop.org > Cc:

Re: [Intel-gfx] [PATCH v2 01/12] drm/nouveau: Fix error handling in nv50_disp_atomic_commit

On Tue, Jul 11, 2017 at 04:33:03PM +0200, Maarten Lankhorst wrote: > Make it more clear that post commit return ret is really return 0, > > and add a missing drm_atomic_helper_cleanup_planes when > drm_atomic_helper_wait_for_fences fails. > > Fixes: 839ca903f12e ("drm/nouveau/kms/nv50:

Re: [PATCH v2 2/2] drm/panel: simple: Add support for ddc-only panel

On Thu, Jul 13, 2017 at 6:04 AM, wrote: > From: Patrick Bruenn > > This is a fix for the CX9020 Embedded PC. On that device the 24-bit > parallel-display signal of the imx53 is combined with an I2C channel > and converted to DVI-D port.

[Bug 26345] [845G] CPU/GPU incoherency

https://bugs.freedesktop.org/show_bug.cgi?id=26345 Ленар changed: What|Removed |Added i915 platform||ALL

Re: [PATCH v5 12/14] drm: radeon: remove dead code and pointless local lut storage

On Thu, Jul 13, 2017 at 12:25 PM, Peter Rosin wrote: > The redundant fb helpers .load_lut, .gamma_set and .gamma_get are > no longer used. Remove the dead code and hook up the crtc .gamma_set > to use the crtc gamma_store directly instead of duplicating that > info locally. > >

Re: [PATCH v5 04/14] drm: amd: remove dead code and pointless local lut storage

On Thu, Jul 13, 2017 at 12:25 PM, Peter Rosin wrote: > The redundant fb helpers .load_lut, .gamma_set and .gamma_get are > no longer used. Remove the dead code and hook up the crtc .gamma_set > to use the crtc gamma_store directly instead of duplicating that > info locally. > >

Re: [RFC v2] drm/hdcp: drm enum property for HDCP State

On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote: > DRM connector property is created to represent the content protection > state of the connector and to configure the same. > > CP States defined: > DRM_CP_UNSUPPORTED - CP is not supported > DRM_CP_DISABLE -

Re: Linux: Smooth splashscreen with system having weston with drm-backend

On Fri, Jul 14, 2017 at 03:07:11PM +0530, Vikas Patil wrote: > On Thu, Jul 13, 2017 at 7:20 PM, Daniel Vetter wrote: > > On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil wrote: > >> Dear All, > >> > >> I am looking for an solution to have early smooth

Re: [PATCH v5 03/14] drm/fb-helper: separate the fb_setcmap helper into atomic and legacy paths

On Thu, Jul 13, 2017 at 06:25:27PM +0200, Peter Rosin wrote: > The legacy path implements setcmap in terms of crtc .gamma_set. > > The atomic path implements setcmap by directly updating the crtc gamma_lut > property. > > This has a couple of benefits: > - it makes the redundant fb helpers

Re: [PATCH 2/2] dim: Try to gc the rr-cache

On Fri, Jul 14, 2017 at 12:57:23PM +0300, Jani Nikula wrote: > On Thu, 13 Jul 2017, Sean Paul wrote: > > On Wed, Jul 12, 2017 at 02:12:24PM +0200, Daniel Vetter wrote: > >> The problem is that we have a distributed cache - every committer has > >> a copy. Which means even

Re: [Intel-gfx] [PATCH 1/5] drm/i915/fbdev: Always forward hotplug events

On Thu, Jul 06, 2017 at 03:05:19PM +0200, Maarten Lankhorst wrote: > Op 06-07-17 om 15:00 schreef Daniel Vetter: > > With deferred fbdev setup we always need to forward hotplug events, > > even if fbdev isn't fully set up yet. Otherwise the deferred setup > > will neer happen. > > > > Originally

Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

On Fri, Jul 14, 2017 at 03:55:26PM +0300, Dan Carpenter wrote: > I don't agree with it as a static analysis dev... What I mean is if it's a macro that returns -ENODEV or a function that returns -ENODEV, they should both be treated the same. The other warnings this check prints are quite clever.

Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

Ah... I see why it's complaining about these ones in particular... I don't agree with it as a static analysis dev, and I don't like the changes too much. But since it's only generating a hand full of warnings then I don't care. regards, dan carpenter

Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

On Fri, Jul 14, 2017 at 11:36:56AM +0200, Arnd Bergmann wrote: > @@ -1158,7 +1158,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc) >*/ > fmt_src.pad = pad->index; > fmt_src.which = V4L2_SUBDEV_FORMAT_ACTIVE; > - if (!v4l2_subdev_call(sensor, pad, get_fmt, NULL,

Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

On Fri, Jul 14, 2017 at 2:05 PM, Dan Carpenter wrote: > Changing: > > - if (!frob()) { > + if (frob() == 0) { > > is a totally pointless change. They're both bad, because they're doing > success testing instead of failure testing, but probably the second one > is

Re: [PATCH 14/14] [media] fix warning on v4l2_subdev_call() result interpreted as bool

Changing: - if (!frob()) { + if (frob() == 0) { is a totally pointless change. They're both bad, because they're doing success testing instead of failure testing, but probably the second one is slightly worse. This warning seems dumb. I can't imagine it has even a 10% success rate at finding

[Bug 101528] RX460 Memory clock stays high until card / display is "used"

https://bugs.freedesktop.org/show_bug.cgi?id=101528 Sverd Johnsen changed: What|Removed |Added Resolution|--- |FIXED

[Bug 101528] RX460 Memory clock stays high until card is "used"

https://bugs.freedesktop.org/show_bug.cgi?id=101528 --- Comment #5 from Sverd Johnsen --- Works for me on 4.11.10. Display off, MCLK is low and card temperature is 27°C as expected. Thanks. -- You are receiving this mail because: You are the assignee for the

[RFC v2] drm/hdcp: drm enum property for HDCP State

DRM connector property is created to represent the content protection state of the connector and to configure the same. CP States defined: DRM_CP_UNSUPPORTED - CP is not supported DRM_CP_DISABLE - CP is disabled DRM_CP_ENABLE - CP is enabled V2:

Re: [PATCH 13/18] dt-bindings: vendor: Add Huarui Lighting

On Thu, Jul 13, 2017 at 10:13 PM, Maxime Ripard wrote: > Huarui Lighting makes display panel, add it to the list of panels. I could not find any information on "Huarui Lighting" within the context of LCD panels. The company I found makes LED lighting fixtures,

Re: [PATCH 4/4] drm/sun4i: make sure we don't have a commit pending

Hi, On Thu, Jul 13, 2017 at 10:41 PM, Maxime Ripard wrote: > In the earlier display engine designs, any register access while a commit > is pending is forbidden. > > One of the symptoms is that reading a register will return another, random, > register value

drm/edid: api to register cea modes if no edid supported

Adding drm_add_modes_noedid_cea API for supporting cea modes for drm devices which does not have panel framework or edid support. Protocols like SDI whic have minimal support in linux kernel can benifit from this. There is already a API drm_add_modes_noedid, but that supports only dmt modes.

Re: [PATCH v2 08/14] v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and VSP2-D instances

On 14/07/17 00:31, Laurent Pinchart wrote: > Hi Kieran, > > On Thursday 13 Jul 2017 18:49:19 Kieran Bingham wrote: >> On 26/06/17 19:12, Laurent Pinchart wrote: >>> New Gen3 SoCs come with two new VSP2 variants names VSP2-BS and VSP2-DL, >>> as well as a new VSP2-D variant on V3M and V3H SoCs.

Re: Linux: Smooth splashscreen with system having weston with drm-backend

On Thu, Jul 13, 2017 at 7:20 PM, Daniel Vetter wrote: > On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil wrote: >> Dear All, >> >> I am looking for an solution to have early smooth splashscreen on the >> Linux system with Weston and drm-backend. >> >> I

Re: [RFC 1/3] clk: inherit display clocks enabled by bootloader

On Fri, Jul 14, 2017 at 12:52 AM, Rajendra Nayak wrote: > Hi Rob, > > On 07/11/2017 11:50 PM, Rob Clark wrote: >> The goal here is to support inheriting a display setup by bootloader, >> although there may also be some non-display related use-cases. >> >> Rough idea is to

Re: [Intel-gfx] [RFC v1 01/20] drm/hdcp: HDCP bitmask property for connectors

On Friday 14 July 2017 12:32 AM, Daniel Vetter wrote: On Thu, Jul 13, 2017 at 06:29:33PM +0530, Ramalingam C wrote: On Thursday 13 July 2017 04:06 PM, Daniel Vetter wrote: On Thu, Jul 13, 2017 at 12:15 PM, Ramalingam C wrote: On Thursday 13 July 2017 02:15 PM,

Re: [PATCH 05/14] isdn: isdnloop: suppress a gcc-7 warning

On Fri, Jul 14, 2017 at 12:08 PM, Joe Perches wrote: > On Fri, 2017-07-14 at 11:25 +0200, Arnd Bergmann wrote: >> We test whether a bit is set in a mask here, which is correct >> but gcc warns about it as it thinks it might be confusing: >> >>

[PATCH v8 06/14] drm/edid: parse YCBCR420 videomodes from EDID

HDMI 2.0 spec adds support for YCBCR420 sub-sampled output. CEA-861-F adds two new blocks in EDID's CEA extension blocks, to provide information about sink's YCBCR420 output capabilities. These blocks are: - YCBCR420vdb(YCBCR 420 video data block): This block contains VICs of video modes, which

Re: [PATCH 00/14] gcc-7 warnings

On Fri, Jul 14, 2017 at 11:25:12AM +0200, Arnd Bergmann wrote: > This series should shut up all warnings introduced by gcc-6 or gcc-7 on > today's linux-next, as observed in "allmodconfig" builds on x86, > arm and arm64. > > I have sent some of these before, but some others are new, as I had > at

Re: [PATCH 13/14] iopoll: avoid -Wint-in-bool-context warning

On Fri, Jul 14, 2017 at 11:55 AM, Joe Perches wrote: > On Fri, 2017-07-14 at 11:31 +0200, Arnd Bergmann wrote: >> When we pass the result of a multiplication as the timeout, we >> can get a warning: >> >> drivers/mmc/host/bcm2835.c:596:149: error: '*' in boolean context, suggest

Re: [PATCH 12/18] drm/sun4i: Add Allwinner A31 MIPI-DSI controller support

/linux/commits/Maxime-Ripard/drm-sun4i-Allwinner-MIPI-DSI-support/20170714-123103 config: arm-sunxi_defconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin

Re: [PATCH 05/14] isdn: isdnloop: suppress a gcc-7 warning

On Fri, 2017-07-14 at 11:25 +0200, Arnd Bergmann wrote: > We test whether a bit is set in a mask here, which is correct > but gcc warns about it as it thinks it might be confusing: > > drivers/isdn/isdnloop/isdnloop.c:412:37: error: ?: using integer constants in > boolean context, the expression

Re: [PATCH 2/2] drm/amdgpu: Implement ttm_bo_driver.access_vram callback

Am 13.07.2017 um 23:08 schrieb Felix Kuehling: Allows gdb to access contents of user mode mapped VRAM BOs. Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 59 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 2

Re: [PATCH 1/2] drm: Implement vm_operations_struct.access

Am 13.07.2017 um 23:08 schrieb Felix Kuehling: Allows gdb to access contents of user mode mapped BOs. VRAM access requires the driver to implement a new callback in ttm_bo_driver. One more comment additionally to what Michel already wrote below, apart from that it looks good to me.

Re: [PATCH, RESEND 03/14] drm/vmwgfx: avoid gcc-7 parentheses warning

On Fri, 14 Jul 2017, Arnd Bergmann wrote: > gcc-7 warns about slightly suspicious code in vmw_cmd_invalid: > > drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c: In function 'vmw_cmd_invalid': > drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:522:23: error: the omitted middle > operand in ?: will

Re: [PATCH 13/14] iopoll: avoid -Wint-in-bool-context warning

On Fri, 2017-07-14 at 11:31 +0200, Arnd Bergmann wrote: > When we pass the result of a multiplication as the timeout, we > can get a warning: > > drivers/mmc/host/bcm2835.c:596:149: error: '*' in boolean context, suggest > '&&' instead [-Werror=int-in-bool-context] >

  1   2   >